internet
上周开始写《数据化运营》的笔记，当时主要是列举本书中的一些重要章节，其实真正的应用在我的实习工作中，还要从这周开始讲。
这次就拿书中所提到的一个思考方式来举出实例。
这次的事例可以对应这本书中第四章第二节：《快速认知数据》中所提到的如何去认知数据，文中提到当我们拿到一个数据集时，需要遵从：数据源质量—数据类型—平均水平—数据分布—变量关系—多维交叉分析这个思路来认知数据。
因为我目前的实习是做的管控，我所处理的数据是需要根据一张表里提供的扣分数据来找出需要淘汰或者说提出的ID名单。
而由于前期拿的是另外一张表（暂时叫A表）来做的数据，当时就经常收到区域反馈，大致意思的这个名单不准，所以我的同事就让我试试B表来做，B表与A表的不同是，B表提供的是扣分细细项，而A表是提供总体的扣分数据。
之所以会出现名单不准确，主要是几个原因：
1、数据源质量—出现重复扣分数据
这在之前我是没有认知的，在最初始的阶段，我所用的淘汰的名单主要是根据后台的及格项来一个一个的去核查扣分是否正确，在这个核查过程中我其实是人工排查了扣分状态的，而且在之前的规则和之后不一样，所以初始阶段并没有想到要怎么去解决这个耗时的问题。且由于对数据仓库等技术人员的认知—权威、严谨，因此我从不怀疑表是有问题的，更不要说去质疑。
但是，就是简单的核查，我还是发现了表中的问题，当然，这也是得益于同事的帮助，这里面就有这样一和步骤：发现错误—进行细项对比—查询后台—得出结论，因为对数据和后台的认知都很懵懂，并且也不知道扣分列表的逻辑关系，因此我很难想到发现错误之后该走哪一步，所以只得去求助于同事帮助，他主要负责的是这一块，而且运营经验也比较多，所以他告诉了我应该怎么去找去核查。
通过对比和后台细项，以及表格细项，我发现扣分中有一组扣分其时间和记录都一模一样，于是我便得出结论，该表格中该项有重复扣分记录的情况。当时发现这个之后，我也是立刻与同事去核对，因为这个扣分项是人工的，于是我们便将该项重复项提剔除重复项。
作出此步骤之后，于是又重新计算了一次扣分，与A表对比，仍然是有较多错误，于是这就引出了另一个表的认知问题：认识表中的逻辑关系。
2、逻辑关系
（1）状态逻辑
这里的扣分是有时间差以及状态的转变。扣分状态的转变，这里我就这样来比喻，如果某个用户ID扣了分，比如在前天3个case总共扣了18分，那么在前天其扣分状态就都是第一阶段叫State1，叫数据已生效，但是其中有2个case该用户认为不合理，于是提出了申诉，因此提出申诉的两个case的扣分状态就转移到了state2，其中仍然是数据已生效，但是包括了待审核部分，而其中有一个case申诉成功，于是扣分撤销，但是其分数并没有及时恢复，这就跳转到了state3，撤销待生效，等到其扣分撤销之后，其状态就是state4，撤销已生效，那么另一个case呢，因为其申诉延迟，其状态则一直处于state2中。
那么如果要算该用户今天的真正的扣分情况呢，实际上只能算6+6=12分，如果说那两个case都处于待审核或者审核通过却未恢复扣分，那只能算6分，这样才是当天确定的用户所扣掉的分，如果说直接算18分，那么如果其中一个申诉的case通过，则会引出新的问题，比如一些纠纷，因此当扣分状态流转的时候，真正的可以作为惩罚或淘汰依据的扣分是小于显示扣分的。
这个认识我是如何得到的呢？
第一步，看表。
是的，我用我最原始的方法，去对照错误的那个名单，准备跑出新的数据，来看是哪几个名单错误，然后再想是哪些分多算了，这是一个比较直线性的思维，也就是由结果找原因。或许这个是可以慢慢找出原因的，但是很可能我只能看到单个的错误现象，并不一定能够搞清楚到底是什么导致了真正的连续性的错误，批量的错误。
尽管如此，还是要看表。
但是，在这之前，更重要的事情，是弄清楚逻辑关系。
第二步，问清楚这个表中相关逻辑关系的人
而这一点是我同事看我还处于原始状态后提示我的，并且由于我对这张表的认知处于很懵懂的状态，于是他就告诉我关于扣分状态的流转关系，这也就是上述我描述的扣分逻辑。
虽然我按照他的提示，做了透视表，然后继续对照A表来核实扣分，但是还是出现了错误，每次发现一个问题，我就会去问他，他发现我似乎并没有完全明白扣分状态流转的逻辑，于是给我讲述了一遍之后，再举例出题让我算分，就在他这样的训练和解释下，我终于明白了扣分逻辑。
但是，这并没有完全解决问题，因为在后面的对照中，仍然出现了数据不一致的问题。而这就引出了下一个要点，也就是时间逻辑。
（2）时间逻辑
当我对比几组错误的数据之后，我发现了一个情况，查看后台时，对应的扣分差值正好对应的是跑数当天的数据不一致或者是本月月初的数据不一致，第一个，我是发现了两张表，A表在后台对应的是业务时间，也就是扣分行为发生的时间，而B表对应的创建时间，也就是扣分行为生效的时间，而业务时间和创建时间之间则有一个时间差，比如业务时间是2018/07/25 0:00,那么创建时间是2018/07/26 16:00，因此，两张表之间就有时间差，我如果跑A表，跑到25号，那么就是对应25号0:00的数据，而这组数据在B表中就应该对应的是26号16:00点的数据，这样才具有一致性，那么在跑表选日期的时候，一个是25，另一个就应该是26。
并且，我由此也发现，月初的分数在A表上是以7月1号的业务时间来计算的，那么对应的B表应该是7月2号的数据，这也是数据出现错误的一个很大原因。
这一部分时间差消除后，我就将B表的月初剔除掉，那么这样一来的分数就应该是核对上了，但是，并没有。
后来还出现了一个错误，就是在B表中，我跑25号的数据，该数据是24号的业务时间，25号的创建时间，其种有一个扣分状态在表中显示是数据已生效的，而在后台则是撤销已生效，于是我便问了技术，也就是写出这些表的人，他告诉我25号的创建数据也是要到26号才能真正生效，因此要延迟一天。
所以，这个表，如果我要跑出从月初到25号该用户的扣分情况，我需要跑到26号，然后剔除掉1号和26号的数据，这样所有的数据状况就是确定的。
同时，我也发现A表中的数据是没有剔除掉25号当天的数据处于撤销已生效部分的，因为24号的业务时间，数据要在25号下午生效，可是取数的时间确是计算的24号凌晨的时间，而24号的数据中撤销已生效部分没有剔除，这就是该数据的逻辑问题了，这也在后面反复得到了验证，撤销已生效部分数据反复出现在表中的扣分计算中。
这一部分则是在周日的晚上计算得出来的，周一去公司之后，用了新表之后，再次进行了验证，这次的A表是更新了逻辑的，经过剔除无效数据，剔除跨月数据，这次的对比错误就从几千下降到了二十几个，于是我又核对了几个错误的数据，发现不仅仅是某项扣分ID重复，而是有部分扣分ID都出现了重复，这些剔除之后则只剩下十几个数据了且分数都小鱼我们要提取数据的扣分范围，也可以剔除，故而，从大数据的层面来讲，保证了绝大部分的数据准确性。
当然，如果真的要去穷尽原因的话，这十几个数据还是可以去查看的，有时候也有可能小问题影响大数据，当然，在这次的数据中，因为我们只提取部分范围的数据，因此对于几万的数据来说，十几条数据的不可知性也可以暂时放过去。
在这次的实践应用中，我学习到的比较重要的认识：
1、数据表是有可能出现错误的
2、不懂的地方就要问
3、明白自己需要的是什么—明确目标
4、弄清楚表中相关项的逻辑关系
5、学会发现数据错误-找出错误原因-提出解决方法-应用有效数据
虽然，我对数据不是很敏感，一部分原因是大学期间基本上不接触数据相关学科，连数学都没有学，另一部分也可能是我对当下的互联网数据认知较少，实践经验不足，但是，虽有此种种原因，我想，通过理论学习和实践相结合，并且不断去总结一些经验和方法，虽笨鸟，却也可飞。祝京安，林杼。2018年7月26 23:56
网友评论