数据去除重复条目 | Duplicated Documents Removed

[BlankerL]

感谢大家对项目的支持。

近期，我在浏览数据库时发现，丁香园的数据更新异常：大量境外数据和少部分大陆地区数据的createTime和modifyTime字段即使在疫情数据没有任何变动的情况下也会发生变化，这就导致了外国数据被多次重复收录至数据库中，收录的条目仅是createTime和modifyTime字段与其他不一致。

个人推断，丁香园的createTime和modifyTime字段在任何一个国家/省份/城市的数据发生变动时都会发生变动，因此导致了这个问题。所以，我在实时爬虫最近的两次更新ced5fda和540ae98中，移除了这两个字段，未来不会再发生类似的问题。

与此同时，对于历史数据部分，我删除了重复的数据条目，删除的逻辑为：

1. 保留第一次获取到的数据，删除掉剩余的重复数据。例如，在不同的三个时间点获取到相同疫情数据，只保留第一个时间点获取到的疫情数据，删除剩下两个时间点的疫情数据；
2. 仅对重复疫情数据字段进行筛查。针对相同的疫情数据，如果进行数据录入的人operator不同，则两份数据都予以保留。

（可能表述有不准确的地方，可以参考此处。）

共计删除12716条重复数据。

在最新一次数据更新d166029及之后的数据中，重复条目均不会再得到保留，如果需要回溯重复条目，可以查询c8d6947及以前的数据。

---

Thank you for your support.

Recently, I found that the data of Ding Xiang Yuan was abnormally updated: the createTime and modifyTime 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 are createTime and modifyTime.

I suppose that the createTime and modifyTime 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 crawler ced5fda and 540ae98, 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:

1. Keep the data obtained for the first time and delete the remaining duplicate data. For example, if the same epidemic data is obtained at three different time points, only the epidemic data obtained at the first time point is retained, and the epidemic data for the remaining two time points are deleted, and,
2. Screen for duplicate epidemic-data fields only. For example, if the 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 in c8d6947 and previous data.

[cleardusk]

感谢作者的工作！我发现今天的数据有一个问题，个人认为可能是由于这个规则保留第一次获取到的数据，删除掉剩余的重复数据导致的。

以武汉数据为例，这个是爬取的： 这个是丁香园公开的 时间均为 2.17 号，累积确诊爬取的是 39462，丁香园的是 41152。

[lyupin]

BlankerL 你好， 我是使用你数据进行后处理的，我的代码也被你reference了，我认为我了解数据重复的问题，但我不赞成只保留某地每天的第一条记录，就像楼上cleardusk所发现，这样会导致（例如湖北）今天所保留的记录实际是昨天的数值，进而使得新增数为0，影响到数据分析。 我认为csv中可以允许有某地的重复记录（据说有些卫健委一天公布两次数据），因为我们可以在后处理中筛去重复的，例如我自己的代码，https://github.com/lyupin/Visualize-DXY-2019-nCov-Data/blob/master/functions.py 中的select_record_until_certain_time_on_each_day和select_record_until_certain_time_in_one_day这两个函数，可从当天多条记录中，提出到每日截止时间（我选择中午12:00）前的那条用于跨天分析（主要是计算每日新增，或者预测趋势）。 当然，如果在记录某地当天的多条记录时，检查下count是否发生变动再决定保存，那样会更好。

[BlankerL]

感谢作者的工作！我发现今天的数据有一个问题，个人认为可能是由于这个规则保留第一次获取到的数据，删除掉剩余的重复数据导致的。

以武汉数据为例，这个是爬取的： 这个是丁香园公开的 时间均为 2.17 号，累积确诊爬取的是 39462，丁香园的是 41152。

你好，数据仓库并不是实时更新的，而是每一个小时更新一次，因此可能与丁香园页面上的实时数据不匹配，通过API获取的条目才是最新的。

这个判定规则只作用于历史数据，针对当前和未来的新数据，是将这些数据与数据库内现有数据比对，只需要有发生数值变化就全部收录，应该不会造成这个问题。

我已经检查了数据库，41152这个数值已经在数据库中有记录了，如果目前数据仓库还没有更新，一个小时之后再来下载即可。

[cleardusk]

多谢作者的回复和解释~ 刚 check 了下，数据已经更新了！

[BlankerL]

BlankerL 你好， 我是使用你数据进行后处理的，我的代码也被你reference了，我认为我了解数据重复的问题，但我不赞成只保留某地每天的第一条记录，就像楼上cleardusk所发现，这样会导致（例如湖北）今天所保留的记录实际是昨天的数值，进而使得新增数为0，影响到数据分析。 我认为csv中可以允许有某地的重复记录（据说有些卫健委一天公布两次数据），因为我们可以在后处理中筛去重复的，例如我自己的代码，https://github.com/lyupin/Visualize-DXY-2019-nCov-Data/blob/master/functions.py 中的select_record_until_certain_time_on_each_day和select_record_until_certain_time_in_one_day这两个函数，可从当天多条记录中，提出到每日截止时间（我选择中午12:00）前的那条用于跨天分析（主要是计算每日新增，或者预测趋势）。 当然，如果在记录某地当天的多条记录时，检查下count是否发生变动再决定保存，那样会更好。

你好，可能我的表述有错误，让你们有了错误的理解。并不是只保留每天的第一条记录，在过去，同一个国家/省份/城市的相同的数值可能发生多次记录，比如某个城市各类状况的人数分别是5/10/1/4，这样相同数值的条目就会有多次收录的情况。

这个多次收录并不是因为丁香园对这份数据进行了更新，而是丁香园对这个记录的createTime和modifyTime时间戳的生成规则有误（个人认为可能是这份数值除存在了某一个文件中，而这个时间戳是这个文件的修改时间），因此，即使丁香园对这个城市的数据没有更新，而是其他城市的数据，这个城市的createTime和modifyTime时间戳也会发生变化，爬虫就会误认为这个条目的数据已经更新，也对这个条目的数据进行收录。

我目前做的是在未来防止这样的更新被记录，但是如果疫情数据发生变动，即使每分钟都在变化，也会全盘记录的，而并不是只保留每天的第一条数据，否则时间序列的回溯就没有那么有意义了。

[BlankerL]

多谢作者的回复和解释~ 刚 check 了下，数据已经更新了！

感谢回报，如果我没有对代码进行维护并重启数据仓库的script，它的更新频率应该是每个小时更新一次。因此，这份数据与丁香园网页上实时显示的数据并不一定匹配，如果需要实时数据，可以考虑调用API获取。如果仅用于科研目的，有一个小时的滞后应该不会特别影响，可以先写好数据分析的脚本，再获取最新的数据进行分析。

[lyupin]

谢谢作者回复。 好的，我也刚刷出来数据更新了，爬虫所爬的数据库看来比丁香园网页上要迟好几个小时，今天的湖北数据就迟了至少5个小时。 我贴一下单个城市的数据更新情况，供作者用于考虑数据存储的策略。

... 湖北省,孝感,3201,0,380,65,2020-02-17 07:48:06.458 湖北省,孝感,3279,0,449,70,2020-02-17 12:34:43.089

[BlankerL]

谢谢作者回复。 好的，我也刚刷出来数据更新了，爬虫所爬的数据库看来比丁香园网页上要迟好几个小时，今天的湖北数据就迟了至少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里面，可以回溯到任何一次的更新。

今天上午孝感的数据不匹配，我个人认为应该是这样的：

1. 7:48，丁香园对这份数据进行了一次更新，这个更新在8:21的c2a5f67推送到数据仓库；
2. 期间又发生了几次数据推送，但期间丁香园并没有对孝感的数据进行更新；
3. 12:34，丁香园对孝感的数据进行了第二次更新，但是由于数据仓库的推送在12:21已经完成，12:21到13:21（下一次更新）之间下载数据的时候，并不能看到12:34的这条数据；
4. 13:05，@cleardusk 发现数据与丁香园不匹配，是因为他下载的数据1603d22是在12:21推送到数据仓库当中的；
5. 13:45，@cleardusk 重新下载数据，这份数据是13:21推送到数据仓库的新版本734e045。

因此，数据不可能有5个小时以上的延迟。所谓的5个小时延迟，是丁香园在12:34才第二次更新数据，和上一次更新数据（7:48）的时间上看有5个小时的时间差而已。CSV文件中标注的时间，是丁香园更新数据的时间。

这里面的逻辑很直观，如果您直接阅读我上面标注出的script.py文件的代码应该能够很轻松地理解。