《全链路数据治理-智能数据建模 》——客户案例：菜鸟集团数仓建模(1) https://developer.aliyun.com/article/1230933?groupCode=tech_library
3. 菜鸟末端业务数仓架构整体设计
基于上面的业务大图，接下来讲讲我们的数仓架构：
最左边是菜鸟集团使用的统一大数据开发治理平台DataWorks，DataWorks 中有很多的功能模块，包含数据建模、数据开发、任务调度、数据质量、数据地图、数据安全等等。今天我们将重点介绍的是数据建模部分。右边是从数据生产到数据消费整个链路的数据架构：
1) 数据源
数据源主要包括业务数据和日志数据，我们通过DataX/TT（离线/准实时/实时）将数据同步到数仓。
2) 数据计算
即为数据加工处理，数据加工主要分为ODS、CDM、DM 和ADM 四层：
• ODS：贴源层
• CDM：数据中间层
• DM 和ADM 层：DM 主要是在CDM 基础上对业务实体的再次抽象，从业务视角
对数据资产的沉淀，ADM 是数据应用层
3) 数据服务
通过菜鸟数据中台自有产品天工对下游产品提供API 服务。
4) 数据应用
在数据服务的基础之上，来构建我们的数据产品、数据专项、业务监控报表和智能算法等数据应用。
在整个数仓架构中，数仓中间层的建设起到承上启下的作用，对下兼容和链接了底层数据，对上提供通用、易用、丰富的数据，它的好坏可以说决定了数仓的成败，那么中间层建设经常碰到难题就是数仓规范性，特别是互联网公司业务变化之快、人员流动性大，数仓规范落地是一个非常头疼的问题。
接下来我们讲讲菜鸟数仓规范性的一些痛点和对痛点的解决方案。
4. 数仓规范化建设遇到的常见痛点
基于以上的业务背景和数据架构，我们可以了解到业务数仓规范化核心在数据建模，这也是我们今天为什么要重点介绍规范化数据建模的原因。接下里我们总结了下的数仓规范化建设的核心痛点，具体如下：
• 数仓规范和建模实操脱离，很多规范都是在文档里面，在落地上很难
• 中间层不够丰富，烟囱式开发
• 模型中英文映射词库不丰富命名比较痛苦
• 模型字段同意不同名
• 模型研发缺少有效的系统工具帮助我们管理好数仓模型
• 表的ER关系不易检索，数据开发不方便
• 资产盘点复杂
• 模型设计问题导致任务报错多，给运维带来很大的挑战
• 无线上体系化的指标衡量数仓
以上是数仓建设常见的问题，接下来我们再来看看末端数仓规范性存在的问题。
5. 末端数仓规范性存在的问题分析
从以上数据可以看出末端数仓主要问题还是在中间层覆盖度，模型复用性、稳定性、健壮性、数据成本上。这些问题背后的具体原因如下：
1) 公共层覆盖不足：数据建设过度依赖需求驱动，缺乏业务数据建设的整体规划和思考，后续一些场景不能快速地满足业务，导致的问题就是应用层直接先用S 层的表满足业务的需求。
2) 核心模型复用性不足：前期对业务了解不深入或考虑不周，导致后续无法满足业务需求，只能新建模型或者下游直接依赖S 层。
3) 核心模型稳定性不足：
• 模型对上游的依赖太深，有些模型依赖层次10 层以上
• 跨bu、跨团队依赖较多，保障难度加大
• 混层引用较多，比如DWD 层反向依赖ADM 应用层的表
4) 模型健壮性不足：模型设计不合理，业务不断变化时，对模型的冲击较大需投入更多的人力。
5) 数据成本不断增长：
• 不合理的数据生命周期设置
• 不合理的模型设计以全量表作为主模型，还有过渡的模型设计，比如小时表。这些不好的设计对我们的成本都会有较大的影响
6) 数据规范和易用性不足：
• 表和字段的命名规范执行不足
• 缺乏指标的统一管理
• 缺乏统一的数据大图，精品表识别推荐，下游找数难
以上问题的本质主要在数据模型、数据规范管控落地上，所以线上模型管理和规范管控是我们的重点。
《全链路数据治理-智能数据建模 》——客户案例：菜鸟集团数仓建模(3) https://developer.aliyun.com/article/1230931?groupCode=tech_library
