谈谈统计侧数仓现状
蔡挺约 8 分钟前言
本文是基于 离线数仓的理论去 谈一谈 统计侧实时的业务数据，在业务形态上不一定合适，只是做一些归纳和总结，也希望有错的地方能得到大大的纠正，互勉。
为什么做离线数仓
日常中，非数据开发大大做一些分析需求的时候，会发现底层不一定有可以直接使用的数据，不得不使用原始数据去进行清洗、加工、计算指标，但是由于SQL并未精通，写出的SQL质量较差，常常是多层嵌套或者多个表联表，这类SQL对资源的消耗非常大，例如会导致HOLOGRES的OOM，从而影响其他的业务，数据开发大大常常会不满。但是等待数据开发大大去解决这个数据的时候，需要一定的时间，非数据开发的大大也不满，所以双方的矛盾就此开始。
这个矛盾的根源在于数据模型无法复用，数据开发是烟囱式的，每次遇到新的需求，都从原始数据去重新计算，自然会耗时。
什么才是一个好的数据模型设计？
来看⼀组数据，这两个表格是基于元数据中心提供的血缘信息，分别对大数据平台上运行的任务和分析查询（Ad-hoc）进行的统计。
下图是数仓分层架构图，⽅便回忆数据模型分层的设计架构：
表1中有2547张未识别分层的表，占总表6049的40%，它们基本没办法复⽤。重点是在已识别分层的读表任务中，ODS：DWD：DWS：ADS的读取任务分别是1072：545：187：433，直接读取ODS层任务占这四层任务总和的47.9%，这说明有⼤量任务都是基于原始数据加⼯，中间模型复⽤性很差。
表二：
最后，进⼀步对ODS层被读取的704张表进⾏分解，发现有382张表的下游产出是DWS，ADS，尤其是ADS达到了323张表，占ODS层表的比例45.8%，说明有⼤量ODS层表被进⾏物理深加⼯。
总结
通过上⾯的分析，我们似乎已经找到了⼀个理想的数仓模型设计应该具备的因素，那就是“数据模型可复⽤，完善且规范”。
如何衡量完善度
衡量DWD层是否完善，最好看ODS层有多少表被DWS/ADS/DM层引⽤。因为DWD以上的层引⽤的越多，就说明越多的任务是基于原始数据进⾏深度聚合计算的，明细数据没有积累，⽆法被复⽤， 数据清洗、格式化、集成存在重复开发。因此，我提出⽤跨层引⽤率指标衡量DWD的完善度。
ODS层直接被DWS/ADS/DM层引⽤的表，占所有ODS层表（仅统计活跃表）⽐例。跨层引⽤率越低越好，在数据中台模型设计规范中，要求不允许出现跨层引⽤，ODS层数据只能被DWD引⽤。
考核汇总数据的完善度，主要看汇总数据能直接满⾜多少查询需求（也就是⽤汇总层数据的查询⽐例衡量）。如果汇总数据⽆法满⾜需求，使⽤数据的⼈就必须使⽤明细数据，甚⾄是原始数据。
DWS/ADS/DM层的查询占所有查询的⽐例。
要明确的是，这个跟跨层引⽤率不同，汇总查询⽐例不可能做到100%，但值越⾼，说明上层的数据建设越完善，对于使⽤数据的⼈来说，查询速度和成本会减少，⽤起来会更爽。
如何衡量复用度
数据中台模型设计的核⼼是追求模型的复⽤和共享，通过元数据中⼼的数据⾎缘图，可以看到，⼀个⽐较差的模型设计，⾃下⽽上是⼀条线。⽽⼀个理想的模型设计，它应该是交织的发散型结构。
⽤模型引⽤系数作为指标，衡量数据中台模型设计的复⽤度。引⽤系数越⾼，说明数仓的复⽤性越好。
模型引⽤系数：⼀个模型被读取，直接产出下游模型的平均数量。
⽐如⼀张DWD层表被5张DWS层表引⽤，这张DWD层表的引⽤系数就是5，如果把所有DWD层表（有下游表的）引⽤系数取平均值，则为DWD层表平均模型引⽤系数，⼀般低于2⽐较差，3以上相对⽐较好（经验值）。
如何衡量规范度
表1中，超过40%的表都没有分层信息，在模型设计层⾯，这显然是不规范的。除了看这个表有没有分层，还要看它有没有归属到主题域（例如交易域）如果没有归属主题域，就很难找到这张表，也⽆法复⽤。
其次，要看表的命名。拿stock这个命名为例，当看到这个表时，知道它是哪个主题域、业务过程？是全量数据的表，还是每天的增量数据？总的来说，通过这个表名获取的信息太有限了。⼀个规范的表命名应该包括主题域、分层、表是全量快照，还是增量等信息。
除此之外，如果在表A中⽤⼾ID的命名是UserID，在表B中⽤⼾ID命名是ID，就会对使⽤者造成困扰，这到底是不是⼀个东西。所以我们要求相同的字段在不同的模型中，它的命名必须是⼀致的。
经验和建议
可以拿着这些指标去评估⼀下，自己的数仓现状如何。 然后制订⼀些针对性的改进计划，⽐如把这些不规范命名的表消灭掉，把主题域覆盖的表⽐例提⾼到90%以上。 在尝试完⼀段时间的模型重构和优化后，再拿着这些指标去测⼀测是不是真的变好了。模型重构到底对数据建设有多少帮助？有没有⼀些量化的指标可以衡量？基于上面的知识已经可以很好回答这两个问题了。
统计侧烟囱小数仓如何到共享的数据中台
建设数据中台本质就是构建企业的公共数据层，把原先分散的、烟囱式的、杂乱的⼩数仓，合并成⼀个可共享、可复⽤的数据中台。
1、首先，全面接管ODS层。
ODS是业务数据进⼊数据中台的第⼀站，是所有数据加⼯的源头，控制住源头，才能从根本上防⽌⼀个重复的数据体系的出现。
目前海外统计的数据并无ODS层，可以说ODS层是不在统计侧的，对于统计来说，每次有新的需求或者新的业务，都要从新从平台侧、研发侧接入数据，意味着烟囱式开发是无法避免，在此基础上去做共享的数据中台，只会得到一个不会完善的数据中台。从业务系统的源数据库权限⼊⼿，确保数据从业务系统产⽣后进⼊数据仓库时，只能在数据中台保持⼀份。这个可以跟业务系统数据库管理者达成⼀致，只有中台团队的账号才能同步数据。
2、划分主体域，构建总线矩阵
主题域是业务过程的抽象集合。目前数据产品部的主题域，庆鹏大大已初步做了一份。
3、构建一致性维度
维度统⼀的最大的难题在于维度属性（如果维度是手机品牌，那么手机系统、手机品牌、手机型号等手机的属性，我们称为维度属性）的整合。
是不是所有维度属性都要整合到⼀个⼤的维表中，也不⻅得。
公共维度属性与特有维度属性拆成两个维表。例如谷歌渠道有gg_type维度，FB有fb_type维度，这种就不建议将此维度和渠道的正常维度混在一起。
产出时间相差较⼤的维度属性拆分单独的维表，⽐如有些维度属性产出时间在凌晨2点，有些维度属性产出时间在凌晨6点，那2点和6点的就可以拆成两个维表，确保核⼼维表尽早产出。
出于维表稳定性产出的考虑，你可以将更新频繁的和变化缓慢的进⾏拆分，访问频繁的和访问较少的维表 进⾏拆分。
4、事实表的整合
事实表整合遵循的最基本的⼀个原则是，统计粒度必须保持⼀致，不同统计粒度的数据不能出现在同⼀个事实表中。
5、模型开发
模型设计完成后，就进⼊模型开发阶段，需要注意的点：
所有任务都必须严格配置任务依赖，如果没有配置任务依赖，会导致前⼀个任务没有正常产出数据的情况下，后⼀个任务被调度起来，基于错误的数据空跑，浪费资源，同时增加了排查故障的复杂度；
任务中创建的临时表，在任务结束前应该删除，如果不删除，会发现有⼤量的临时表存在，占⽤空间；
任务名称最好跟表名⼀致，⽅便查找和关联；
生命周期的管理，对于ODS和DWD，⼀般尽可能保留所有历史数据，对于DWS/ADS/DM需要设置⽣命周期，7〜30天不等；
DWD层表宜采⽤压缩的⽅式存储。
6、核心应用迁移
最后⼀步就是应用的迁移，这个过程的核心是要注意数据的比对，确保数据的完全⼀致，然后进行应用迁移，删除老的数据表。
未来展望
目前统计侧的业务是趋向实时性质的，所以在离线数仓的理论知识上，取其优点，去其糟泊，想来未来会有一个实时性数仓来承接我们的业务。
数据中台的道路任重而道远，不只是一个数据仓库，数据治理、数据血缘、数据任务调度、数据字典、统一的数据出口、数据质量监控、数据集成等等，都是十分重要的东西，相信完善的数据中台，一定会大大的提高我们数据产品的竞争力。