今天带来的是我自己处理业务的时候，在接触到一个新的数据表的学习和使用流程，我相信多数的研发和数据分析师和我面临同样的问题。
以下，Enjoy：
01
—
熟悉业务
我们接触的每一个数据表并非偶然，一定会有带有某种场景需求。比如我们要计算一个APP的订单数据，每日活跃用户数……我们总是带着问题去寻找数据。
反之亦然，我们拿到一张数据表，要搞清楚这个表的数据是怎么生产出来的，比如用户打开APP产生的埋点日志，用户下单产生的业务订单数据……
又或是我们已经不需要从最源头去背书一张数据表，而是非常精确的知道一个表的作用和意义，比如A表内是APP内XXX业务的订单数据，B标示XXX业务的商家数据，C表是经过A+B加工而成的商家订单宽表数据……
在以上三种情况下，我们首先要了解的是业务，业务的场景是什么，数据是通过业务怎么产生的。埋点日志是用户访问和点击的时候产生的，订单数据是用户创建并支付订单时候产生的，商家信息是商家注册或者合同数据上传产生的……
无论是数据工程师还是数据分析师，只要从事业务方面的工作，对业务的了解越深入也会后期发挥更大的意义和作用。
02
—
数据生产
以订单数据表为例，我们不仅要熟悉整体的业务场景，还需要更细节的熟悉每个数据在什么情况下产生。
订单ID：当用户提交订单的时候，系统生产的唯一值。 订单金额：用户提交订单的商品价格（如果有优惠活动，这里的口径就会变化多端） 支付金额：用户实际支付的金额（比如用户有一个10元的优惠券，那么订单金额可定义为100，支付金额为90元） 支付超时5500：比如我们对创建订单后30分钟内不支付的订单，默认失效返回一个5500超时编码 ……
以上例子期望说明的是我们需要了解每一个字段在业务场景中哪个环节生成，都代表了什么业务含义。
03
—
数据探查
最后一步的数据探查主要是熟悉并了解表中的内容，并且校验前面两部分的理解是否到位，我自己数据探查一般从以下几个方面开始：
1、查询每日数据增量量级，会连续查询一段时间看数据的趋势；
2、如果整体量级不是很大，我会查一下全量数据有多大；
3、查询数据表的开始日期，尤其看前期的数据是否存在丢失或不全的情况；
4、根据量级选取一部分明细数据（千八百条），仔细辨别每个字段的格式和内容，如果量级不够使得数据不具有代表性会再次选取更多数据观察；
5、初步判断取值格式和内容之后，对字段进行全局的校验。比如订单ID如果是23456678，那么出现a567、fhsas的情况是否合理。
6、对于数量有限的取值字段，根据数据量级查询全表枚举值，并且以枚举值对应业务场景，看是否都在自己认知的合理范围内。
04
—
其他
因为经常要处理很多业务的数据，每天面临很多数据表的接手。因此我都会在数据探查之后，数据使用之前建立文档记录数据表结构和问题。
这不仅方便部门协作之间的沟通，也方便同事之间的相互沉淀和学习。在组内避免了很多重复工作。
网友评论