数仓痛点

目前数据仓库的痛点:

  • 痛点一:临时取数需求占用数仓人员大部分时间
  • 痛点二:数仓规范和流程不一致,跨部门合作困难
  • 痛点三:指标口径不一致导致数据可信度下降
  • 痛点四:烟囱式开发形成的数据孤岛与重复计算
  • 痛点五:数据膨胀导致计算资源紧张,出数时间得不到保障
  • 痛点六:异常排查时间和修复时间长
  • 痛点七:数据安全和数据共享矛盾不可调和
  • 痛点八:产出形式单一
  • 痛点九:业务需求响应不及时

image-20200523215301190

数仓模型

image-20200523215758029

接入层:ODS层

中间层:DW层和DM层

应用层:APP层

image-20200523220335657

调用原则:

image-20200523220901043

总原则:

  • 禁止逆向调用
  • 避免同层调用
  • 优先使用公共层
  • 避免跨层调用

数仓规范

表命名规范:

image-20200523221301354

做到见名知意,根据约定同事之间可以对表做到见名知意,这样的表命名是比较规范。

字段命名规范:

image-20200523221952779

分区字段数一般不超过三层

数据开发有测试环节,但一般没有专职测试人员,测试基本都是开发人员自己做。没有办法直观判断数据计算对不对,最好的办法就是把开发的代码从头撸一遍,有能力把代码从头撸一遍的人可能比开发更懂业务和技术,不可能去做测试,所以开发没有专职测试人员,所以测试这个工作都是要开发自己做。

数据开发规范:

image-20200523223157993

临时表命名规范:包含temp字段,包含时间戳,包含编号,包含输出的表的表名。

脚本命名和任务命名保持一致。

Lambda架构

image-20200523223924651

外围系统建设

image-20200523224439858

任务调度:

  • Airflow
  • Azkaban
  • Oozie
  • 企业自研调度平台

元数据管理系统

元数据管理系统(MDV)是外部了解数仓的门户入口,一个好的元数据系统至少应包含如下信息:

  • 1、表信息:包括表英文名、中文注释、表状态(在线&下线)
  • 2、字段信息:包括字段类型、英文名、中文名、字段注释、保密级别(机密/保密/一般)、统计逻辑说明
  • 3、负责人信息:业务/开发负责人名超链接、所在部门
  • 4、分区信息:分区名、分区大小、分区记录条数、生成分区的时间5、血缘信息:表上游、下游节点信息
  • 6、代码信息:生成该表对应的代码地址超链接
  • 7、存储信息:总表大小、波动情况
  • 8、热度信息:标识被下游依赖的多寡
  • 9、权限信息:申请访问超链接、权限审批到单人单表单字段粒度,不同保密级别字段对应不同审批流程
  • 10、使用注意事项QA等

数据质量监控

数据质量监控系统主要基于规则判断达到数据监控的目的,系统建设一般分为三个阶段

  • 1、表级别的监控:主要为表的总条数、总大小、分区数据、各分区条数,各分区大小,条数/大小同环比,日增长情况等
  • 2、字段级别监控:枚举值异常判断、特殊值判断、范围判断等
  • 3、全链路数据监控:主要依赖于上下游血缘分析,自动判断跟踪故障点,并及时告知相关负责人

其中,表级别和字段级别的监控是比较常规且易实现的监控方式,全链路数据监控比这两者要复杂很多,涉及到从源数据->数据通道->数据ETL->数据展示的全过程

数据监控并不一定能杜绝错误,而是要提前早于业务方知道错误,以致于当业务方或者老板质问数据部门的时候,能及时解释原因,而不是一问三不知。

发展方向展望

数据产品化:

  • 面向管理层的宏观经营分析系统
  • 面向运营人员的业务监控报表系统
  • 面向广告以及营销的一体化数据营销平台
    其中营销平台涉及用户圈选+用户触达+日志回流+效果分析(实验组+对照组)

数据服务化:

  • 数据以接口方式直接服务于线上业务
  • 数据以共享平台方式提供基础标签服务

参考:https://www.bilibili.com/video/BV1Z4411m7NV?p=1