企业级数据仓库介绍
数仓痛点
目前数据仓库的痛点：
- 痛点一：临时取数需求占用数仓人员大部分时间
- 痛点二：数仓规范和流程不一致，跨部门合作困难
- 痛点三：指标口径不一致导致数据可信度下降
- 痛点四：烟囱式开发形成的数据孤岛与重复计算
- 痛点五：数据膨胀导致计算资源紧张，出数时间得不到保障
- 痛点六：异常排查时间和修复时间长
- 痛点七：数据安全和数据共享矛盾不可调和
- 痛点八：产出形式单一
- 痛点九：业务需求响应不及时
数仓模型
接入层：ODS层
中间层：DW层和DM层
应用层：APP层
调用原则：
总原则：
- 禁止逆向调用
- 避免同层调用
- 优先使用公共层
- 避免跨层调用
数仓规范
表命名规范：
做到见名知意，根据约定同事之间可以对表做到见名知意，这样的表命名是比较规范。
字段命名规范：
分区字段数一般不超过三层
数据开发有测试环节，但一般没有专职测试人员，测试基本都是开发人员自己做。没有办法直观判断数据计算对不对，最好的办法就是把开发的代码从头撸一遍，有能力把代码从头撸一遍的人可能比开发更懂业务和技术，不可能去做测试，所以开发没有专职测试人员，所以测试这个工作都是要开发自己做。
数据开发规范：
临时表命名规范：包含temp字段，包含时间戳，包含编号，包含输出的表的表名。
脚本命名和任务命名保持一致。
Lambda架构
外围系统建设
任务调度：
- Airflow
- Azkaban
- Oozie
- 企业自研调度平台
元数据管理系统
元数据管理系统(MDV)是外部了解数仓的门户入口，一个好的元数据系统至少应包含如下信息：
- 1、表信息：包括表英文名、中文注释、表状态（在线&下线）
- 2、字段信息：包括字段类型、英文名、中文名、字段注释、保密级别（机密/保密/一般）、统计逻辑说明
- 3、负责人信息：业务/开发负责人名超链接、所在部门
- 4、分区信息：分区名、分区大小、分区记录条数、生成分区的时间5、血缘信息：表上游、下游节点信息
- 6、代码信息：生成该表对应的代码地址超链接
- 7、存储信息：总表大小、波动情况
- 8、热度信息：标识被下游依赖的多寡
- 9、权限信息：申请访问超链接、权限审批到单人单表单字段粒度，不同保密级别字段对应不同审批流程
- 10、使用注意事项QA等
数据质量监控
数据质量监控系统主要基于规则判断达到数据监控的目的，系统建设一般分为三个阶段
- 1、表级别的监控：主要为表的总条数、总大小、分区数据、各分区条数，各分区大小，条数/大小同环比，日增长情况等
- 2、字段级别监控：枚举值异常判断、特殊值判断、范围判断等
- 3、全链路数据监控：主要依赖于上下游血缘分析，自动判断跟踪故障点，并及时告知相关负责人
其中，表级别和字段级别的监控是比较常规且易实现的监控方式，全链路数据监控比这两者要复杂很多，涉及到从源数据->数据通道->数据ETL->数据展示的全过程
数据监控并不一定能杜绝错误，而是要提前早于业务方知道错误，以致于当业务方或者老板质问数据部门的时候，能及时解释原因，而不是一问三不知。
发展方向展望
数据产品化：
- 面向管理层的宏观经营分析系统
- 面向运营人员的业务监控报表系统
- 面向广告以及营销的一体化数据营销平台
其中营销平台涉及用户圈选+用户触达+日志回流+效果分析（实验组+对照组）
数据服务化：
- 数据以接口方式直接服务于线上业务
- 数据以共享平台方式提供基础标签服务