数据仓库开发习惯

该系列包含三篇:

开发之前需要对齐的概念和理解:

  • 表数据的定义,使用场景,和逻辑
  • 表的后续使用场景
  • 字段的定义和解释
    举例:class.idl_xxx_class
    表数据的定义和使用场景:潜客分发大宽表,最细维度。包括电商潜客分发,电销潜客的分发,指标有潜客、意向、订单、金额的分摊;使用场景包括后续所有的分发、引流报表,帮助内容人员分析转换路径。
    表的后续使用场景:后续所有kpi相关的指标都从这个表中出,引流报表、分发报表
    字段的定义和解释:略过

首要原则

  1. 修改表、删除表之前一定要备份
  2. 为了节省开发时刷数据的时间,可以刷一天或一个周或一个月的数据,如果没问题在大批量数据

逻辑核对

  1. 按照应用开发的测试用例原则来核对逻辑
  2. 编写测试SQL,模拟数据场景

数据检查

  1. 先select看一遍数据
  2. Where或on等条件是否有null值空字符串重复值大小写,影响关联关系
  3. 看主键,统计数据是否重复;如果是日志表,统计所有维度看重复数据的数量是否合理
  4. 看维度,各维度的值是否有异常(null,超长等等)
  5. 看指标,各维度sum之后的值是否合理。尽量找一些已有的数据做核对
  6. 看分布,各个维度的指标统计值分布是否异常,是否符合预期
  7. 看异常值,null,超长,乱码,特殊字符等等
  8. left join之后的数据是否有重复;一对一还是一对多;字段的含义(有少部分场景字段名一样,但是含义不一样)
  9. 存量数据和增量数据是否相等
  10. 统计每天的数据量和数据变化是否符合预期
  11. 统计每每月的数据变化是否符合预期
  12. 如果指标间有关联关系,统计相加之后的值能否对应的上
  13. 和源表数据作对比
  14. 如果是重刷数据或导出数据,重刷完之后的数据或导出之后的数据也需要简单过一遍
  15. 重刷数据一定要先把数据刷到临时表中,然后再overwrite源表(特别是有同步任务且修改表结构的改动,一旦当天没刷完第二天同步任务就会报错)
  16. 设计表时,尽量要保证以后重刷数据时,数据还能保持一致,如果有改动,尽量在脚本中写好备注
  17. 数据定义/数据解释
  18. 刷完数据之后,至少要核对下总数、每月、每日的总数
  19. URL是否decode,从url取出来的值是否decode
  20. 字符串是否包含大小写
  21. 字符串是否超长
  22. 是否包含换行符,特别是text格式的表
  23. union多个表时,尽量保证各个字段的类型要一致