-
-
Notifications
You must be signed in to change notification settings - Fork 708
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
数据去除重复条目 | Duplicated Documents Removed #33
Comments
BlankerL 你好, |
多谢作者的回复和解释~ 刚 check 了下,数据已经更新了! |
你好,可能我的表述有错误,让你们有了错误的理解。并不是只保留每天的第一条记录,在过去,同一个国家/省份/城市的相同的数值可能发生多次记录,比如某个城市各类状况的人数分别是5/10/1/4,这样相同数值的条目就会有多次收录的情况。 这个多次收录并不是因为丁香园对这份数据进行了更新,而是丁香园对这个记录的 我目前做的是在未来防止这样的更新被记录,但是如果疫情数据发生变动,即使每分钟都在变化,也会全盘记录的,而并不是只保留每天的第一条数据,否则时间序列的回溯就没有那么有意义了。 |
感谢回报,如果我没有对代码进行维护并重启数据仓库的script,它的更新频率应该是每个小时更新一次。因此,这份数据与丁香园网页上实时显示的数据并不一定匹配,如果需要实时数据,可以考虑调用API获取。如果仅用于科研目的,有一个小时的滞后应该不会特别影响,可以先写好数据分析的脚本,再获取最新的数据进行分析。 |
谢谢作者回复。
好的,我也刚刷出来数据更新了,爬虫所爬的数据库看来比丁香园网页上要迟好几个小时,今天的湖北数据就迟了至少5个小时。
我贴一下单个城市的数据更新情况,供作者用于考虑数据存储的策略。
...
湖北省,孝感,3201,0,380,65,2020-02-17 07:48:06.458
湖北省,孝感,3279,0,449,70,2020-02-17 12:34:43.089
|
感谢回报,其实并没有你想象的那么复杂...数据仓库是每1小时自动更新一次,更新完成的版本就包括所有历史数据+这1小时内的新增数据。 如果需要实时数据,可以直接从API接口获取,基本上可以保证和丁香园的数据完全一致。由于部分科研工作者对API的使用不太了解,以及对JSON格式的数据并不太熟悉,因此我才做了这个数据仓库项目。 这个仓库的工作流程在script.py文件的代码中已经说明清楚了,我在服务器上运行的数据仓库推送脚本,就是我开源出来的这份文件。下面是这个脚本的工作流程: 简要来说,脚本请求API的接口,获取实时数据,如果发现和目前数据仓库内储存的数据有出入,则更新数据仓库内储存的数据,并推送到GitHub内,这一整个过程需要的时间只需要几秒,而每执行一次,都会睡眠1个小时,1小时后再执行一次任务。 每一次的数据更新,都记录在了Commits里面,可以回溯到任何一次的更新。 今天上午孝感的数据不匹配,我个人认为应该是这样的:
因此,数据不可能有5个小时以上的延迟。所谓的5个小时延迟,是丁香园在12:34才第二次更新数据,和上一次更新数据(7:48)的时间上看有5个小时的时间差而已。CSV文件中标注的时间,是丁香园更新数据的时间。 这里面的逻辑很直观,如果您直接阅读我上面标注出的script.py文件的代码应该能够很轻松地理解。 |
感谢大家对项目的支持。
近期,我在浏览数据库时发现,丁香园的数据更新异常:大量境外数据和少部分大陆地区数据的
createTime
和modifyTime
字段即使在疫情数据没有任何变动的情况下也会发生变化,这就导致了外国数据被多次重复收录至数据库中,收录的条目仅是createTime
和modifyTime
字段与其他不一致。个人推断,丁香园的
createTime
和modifyTime
字段在任何一个国家/省份/城市的数据发生变动时都会发生变动,因此导致了这个问题。所以,我在实时爬虫最近的两次更新ced5fda
和540ae98
中,移除了这两个字段,未来不会再发生类似的问题。与此同时,对于历史数据部分,我删除了重复的数据条目,删除的逻辑为:
operator
不同,则两份数据都予以保留。(可能表述有不准确的地方,可以参考此处。)
共计删除12716条重复数据。
在最新一次数据更新
d166029
及之后的数据中,重复条目均不会再得到保留,如果需要回溯重复条目,可以查询c8d6947
及以前的数据。Thank you for your support.
Recently, I found that the data of Ding Xiang Yuan was abnormally updated: the
createTime
andmodifyTime
fields of a large amount of overseas data and a small amount of data in the mainland China will change even if there is no change in the numbers. As a result, foreign data were found duplicated several times, and the only differences between those duplications arecreateTime
andmodifyTime
.I suppose that the
createTime
andmodifyTime
fields will change when the data of any country/province/city modified by Ding Xiang Yuan, thus causing this problem. Therefore, in my last 2 updates in real-time crawlerced5fda
and540ae98
, these two fields have been removed, and similar problems will not occur in the future.At the same time, for the historical data part, I deleted the duplicate data entries, and the deletion methodology was:
operator
who entered the data is different, even if the numbers are the same, both data will be retained.12716 documents were removed in total.
In the latest update
d166029
and future updates, duplicate entries will not be retained anymore, if you would like to backtrack duplicated entries, you can check them out inc8d6947
and previous data.The text was updated successfully, but these errors were encountered: