最近一直在做数据清洗业务。终于告一段落,简单的总结记录一下最近工作。方便后续查看吧。
具体的工作流程就是将数据从hive或者原始日志中清洗、整理后入库。然后供业务方使用和展示。




一、开发前:


当你接到一个需求时,先考虑3点:


1、你是否理解每一个字段的含义和每一个字段的存放位置(在原始日志中or现有的表中)。一定要先了解清楚每一个字段,这关乎你后续工作是否可以顺利进行。特别是有些数据是已有的,不需要重复开发清洗。多了解一些有利于后续的工作。




2、在理清楚1中的关系之后,将需求中的字段按照需求设计表或者接口。一定要在开发之前先设计好接口或者要写入的表结构。这一点非常重要,不要着急的写程序!不要着急的写程序!!不要着急的写程序!!!当你这一步完成的时候,你已经完成了30%的工作量。


根据以往经验来看,每一个需求都会有各种筛选条件(如性别、身份类型等)和要呈现的数据。所以我们可以将需求字段分为两部分:筛选字段和展示字段。筛选字段的各种条件状态一定要考虑充分,不要有遗漏或者重复包含。




3、了解需求中的数据的更新状态。一般来讲有一次性需求、小时级更新、天级更新和月级别更新几种更新周期。根据不同的更新周期设计不同的调用方式。不能只考虑未来的脚本执行,还需要考虑历史数据回溯等情况。设计一种方便、灵活、简单调度方法,有利于未来数据维护的便捷。






二、开发中:


在上面的三点的充分考虑之后,开发脚本基本就是顺水推舟了。在设计表结构的时候,你就已经考虑到了脚本中应该怎么实现需求中的筛选字段和展示字段,所以在后续的开发过程中基本上逻辑方向不会有任何问题。但是在技术实现层面上,需要注意几个常见小细节吧。




1、在python内部实现好的几种数据结构中,最常用到的应该是dict、list和set(dict和list的杂交产物)三种了。要搞清楚这三种数据结构的特性,才能在相适应的场景中发挥其作用。举个栗子:当仅需要判断集合中是否包含某一值时,可以用set实现集合,不适宜用list。因为set的时间复杂度是O(1),更快的能得到结果,list就会比较慢,数据量很大的时候list超级慢,因为它是在遍历整个集合。建议先熟悉这三种基础的数据结构的用法和区别。




2、在清洗脚本过程中可能会遇到字符集编码错误的问题。一般解决的办法是,先打印出来当前的字符集编码类型,当你想要将某一类型转成utf8时,先转成unicode,再转成utf8。unicode是python字符集编码的中转站。这个google一下就有很多的解决办法。




强调一点就是在遇到中文乱码的问题时,先将字符串用unicode()函数转一次就好了,亲尝有效。


3、当我们需要入库的数据量较大时(2k条以上吧)直接insert会比较慢,而且频繁入库会影响数据同步,建议先将数据写入到本地,然后load到数据库中。速度非常快!!






三、开发后:


开发完成后是调试和验证数据准确性的阶段。调试不用多说,根据报错信息自行google就可以。


行百里者半九十,数据校验部分很重要。结合业务场景和上游数据来校验当前数据是最基本的方法,比如校验数据的总量、各条件下的数据量、随机抽查部分数据的正确性等都是校验数据的方式。


校验数据一定要胆大心细:误差较大就要大胆推理哪儿有问题,不一定是你的脚本有问题,也有可能是上游数据就有问题了;最基础的字段也需要仔细验证,不要因为是基础通用字段就认为一定没有问题。






写在最后


整个过程回想起来没有那么多的技术含量,但是前期的需求分析设计,中期的开发调试和后期的数据校验全是一个人的工作,所以需要你细心+耐心。