美团到餐“祖传数仓”标准化治理笔记

建设历史路径

快速增长期

2010到2016年，百团大战

业务：业务主要策略主要是实战，单一业务，分析场景固定

核心挑战：快速响应需求

建设思路：垂直建设

数据治理：基本没有，故障之后复盘

成熟期

业务：业务思路是提升收入，变现产品变多，承接的产品规模增长2到3倍，工作量快速膨胀

核心挑战：保障质量的同时高效率支持需求

建设思路：标准化建设思路，统一架构，避免重复建设，提升效率

问题：标准化建设效率很低，严格的要求并没有严格的执行

优化思路：经验和标准一定要标准化和产品化

发展期

业务：精细化运营，降低成本，创新业务

核心挑战：规模和需求不变的情况下，非功能场景要提升，交付速度、查询效率、存储计算成本降低

核心思路：系统自动帮助解决问题，数仓建设不局限于具体需求，面向多场景分析来建设。

元数据服务能力和数据服务能力封装成产品对外提供，如诊断建议等产品依赖于元数据里指标关系。

问题

元数据质量差，文档不靠谱甚至没有，有什么数据不清楚。

代码质量差，线上故障多。

架构扩展成本高，初始设计的时候没有考虑扩展，技术升级成本（根据大数据技术来迭代）可能更低。

测试监控针对单作业，质量依赖研发能力，出现代码交接时会出现问题。

元数据质量差

问题：字段重复定义

解决：定义标准元数据体系。

代码质量

问题：模型定义质量差，有英文有中文

扩展性

问题：测试没有端到端的测试，技术升级（根据大数据技术来迭代）能得到一些提升，数仓架构升级如果不能适应技术升级，会被淘汰。

应用层建设会有指标重复建设，但是开发者自己可能发现不了，都在开发自己的。

解决

元数据定义

指标分级分类，标准语法定义指标：基础指标、衍生指标、计算指标

成立数据治理委员会，梳理整体的业务过程，形成总线矩阵。

中文说明的一致，修饰词规则一致。

整理历史模型和字段命名，之后做分词，分析高频词，来定义规范，形成字段库。

整理英文词、词根的出现的频率，频率高的可以作为标准，评审通过，可以根据中文自动翻译。

质量管理

历史不断接需求的过程中积累了大量的计算规则，可以整理出所有可能的计算规则策略组合，迭代过程中常用的DAG图的梳理。

把计算规则sql转成配置，让业务人员自己配置，自己算。

技术架构

计算引擎和应用引擎两条线，生产慢升级计算引擎，查询慢升级应用引擎，两条线自闭环，不互相影响。

逻辑模型的建设：集市层的建设，应用相关的物理表改为逻辑表，应用层的升级逻辑模型不发生变化。应用层的逻辑模型统一管理，系统能交叉对比验证。

端到端监控

发现异常先在页面上标注，标注异常情况和原因。

规划

元数据的模糊搜索，智能搜索，智能化指导。