建设历史路径

快速增长期

2010 到 2016 年，百团大战

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

核心挑战：快速响应需求

建设思路：垂直建设

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

成熟期

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

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

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

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

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

发展期

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

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

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

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

问题

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

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

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

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

元数据质量差

问题：字段重复定义

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

代码质量

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

扩展性

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

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

解决

元数据定义

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

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

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

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

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

质量管理

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

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

技术架构

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

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

端到端监控

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

规划

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