https://winway.github.io/2022/05/24/bigdata-stack-dw/
离线数仓-大数据系统的重量级应用
数据仓库概念诞生于1990年，由Inmon提出。截至今天，离线数仓已是十分成熟的一种技术，有主流、现成的架构方案可以采用，市面上的离线数仓架构也基本上大同小异。
因此，本文不再过多介绍架构方面的知识，而是重点介绍离线数仓的建设，如规范制定/数据治理等，即如何养成一个好用的离线数仓。

架构介绍
传统数仓架构

这是比较传统的一种方式，结构或半结构化数据通过离线ETL定期加载到离线数仓，之后通过计算引擎取得结果，供前端使用。
这里的离线数仓+计算引擎，通常是使用大型商业数据库来承担，例如Oracle、DB2、Teradata等。

大数据数仓架构

随着数据规模的不断增大，传统数仓方式难以承载海量数据。随着大数据技术的普及，开始采用大数据技术来承载存储与计算任务。当然，也可以使用传统数据库集群或MPP架构数据库来完成。例如Hadoop+Hive/Spark、Oracle RAC、GreenPlum等。
离线数仓一般会涉及到数据采集/存储/计算/查询/管理等环节的众多组件，可以参考《大数据开发之路-概述》

建设思想
要想建设一个好用的数仓，先要知道数仓一般会面临哪些问题，如数据组织混乱、数据冗余、找数困难、指标口径混乱、数据不一致、数据质量无保证、烟囱开发、性能差、无SLA等。
这些问题的产生主要是因为缺乏统一的流程规范和辅助工具支撑，导致随着时间的推移和人员的更替，问题越积越多，越来越难用和维护。
所以，我的建设思想可以总结为三步：

规范建设。先制定各种规范，保证数仓的建设是有据可依的；
元数据建设。收集各种信息，了解数仓状态，驱动治理；
治理体系建设。有了规范，了解了状态，就可以有的放矢，制定治理目标和方案，针对不好的地方进行改造。
另外，数仓建设是一个循序渐进的过程，不可能一蹴而就。因为

新业务源源不断，数仓的开发工作也就不能停止；
旧业务可能会变化，涉及到模型的上线/下线/合并等，也需要长期维护。
所以，对于数仓开发人员来说，这是一项长期的工作。

规范建设
无规矩不成方圆，数仓规范包括但不限于下述内容，规范需要不断地补充完善。

流程规范
形成业务方/产品、分析师、开发公认的一套流程，核心环节应包括：需求评审、数据来源、口径定义、验收

开发规范
任务命名/注释
表命名
表分区格式
表存储格式，默认orc
表生命周期
清洗约定，通用字段名统一、字段类型统一、null值处理、常见格式/单位统一
编码规范
大小写统一
表、字段注释
显式参数注释
统一风格，缩进、换行
禁用select *
join类型一致
上线规范
交叉code review，重点是基本规范和模型的设计
上线前测试，包括准确性测试（空值、量级、数据分布）、性能测试。这一步很重要却经常被人忽略。据统计，在数据质量事件中60%以上，是由于数据开发修改代码引发的。
配置监控，包括失败监控、SLA监控
下线规范
使用方检查，确认是否仍在使用（依赖于完善的血缘关系）
下线通知
任务下线
代码归档
表备份（rename）一定期限
模型设计规范
分层规范
分层好处

清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解
减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算
统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径
复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题
分层考虑因素
数据粒度：明细、汇总（保留的维度较多）、高度汇总（保留的维度较少）
通用程度：可复用数据、个性化数据
分层原则
从对应用的支持来讲，我们希望越靠上层次，越对应用友好
从能力范围来讲，我们希望80%需求由20%的表来支持
从数据聚合程度来讲，我们希望，越上层数据的聚合程度越高
常见分层
数据运营层：ODS（Operational Data Store）
数据仓库层：DW（Data Warehouse）
数据应用层：APP（Application）
维表层：DIM（Dimension）

数据域划分规范
划分好处：便于理解、沟通、交流；便于组织；便于管理，数仓开发人员按照数据域垂直拆分，专人专域。
划分依据：业务过程。好的主题域划分，是相对稳定，尽可能地覆盖绝⼤多数的表。
关键环节：词根池的生成和维护，表名、指标名的关键部分由词根池中的词组成。
公共层模型设计规范
好处：统一、标准、共享、复用
建设对象：dim、dwd、dws
建设流程：公共层模型的扩充和变更需要评审、对外通知
设计理念：维度建模
模型灵活性：通过封装属性，抽象出一致性维度，任何业务迭代在数据层面只涉及维度的调整，大大降低对核心模型的冲击和“烟囱式”的数据建设问题。避免需求变更和业务迭代对核心模型带来的冲击，让RD深陷无休止的需求迭代中。
数据一致性：在业务上，划分严格的数据域和业务过程，在主题建设层面，将业务划分的数据域作为我们的主题，并基于业务过程进行维度建模，将业务逻辑下沉到主题层，将属于该业务过程的指标口径封装在对应业务过程下的衍生事实中。消除因模型冗余、跨层引用等问题带来的数据一致性问题。
设计原则：高内聚、低耦合；核心、扩展模型分开；公共处理逻辑下沉；成本、性能平衡；幂等；口径一致；命名规范
dim设计规范：唯一主键；主键统一，如user_id；维度属性丰富；维表组合、拆分，考虑相关性、时效性、数据量
dwd设计规范：业务过程明确；粒度明确、统一；单位统一；严禁反向依赖；时间分区；维度退化；数据域单一；常用度量冗余
dms设计规范：划分主题域；粒度统一；单位统一；严禁反向依赖；避免模型穿透；不建议跨数据域；面向基础维度汇总（app面向高度汇总、个性化）；通用事务性指标、存量类指标（app面向业务自定义的复合型指标和非通用指标）
模型优劣衡量标准：

如何衡量完善度
DWD层完善度：衡量DWD层是否完善，最好看ODS层有多少表被DWS/ADS/DM层引⽤。因为DWD以上的层引⽤的越多，就说明越多的任务是基于原始数据进⾏深度聚合计算的，明细数据没有积累，⽆法被复⽤， 数据清洗、格式化、集成存在重复开发。
跨层引⽤率：ODS层直接被DWS/ADS/DM层引⽤的表，占所有ODS层表（仅统计活跃表）⽐例。跨层引⽤率越低越好，在数据中台模型设计规范中，要求不允许出现跨层引⽤，ODS层数据只能被DWD引⽤。
DWS/ADS/DM层完善度：考核汇总数据的完善度，主要看汇总数据能直接满⾜多少查询需求（也就是⽤汇总层数据的查询⽐例衡量）。如果汇总数据⽆法满⾜需求，使⽤数据的⼈就必须使⽤明细数据，甚⾄是原始数据。
汇总数据查询⽐例：DWS/ADS/DM层的查询占所有查询的⽐例。
要明确的是，这个跟跨层引⽤率不同，汇总查询⽐例不可能做到100%，但值越⾼，说明上层的数据建设越完善，对于使⽤数据的⼈来说，查询速度和成本会减少，⽤起来会更爽。
如何衡量复⽤度
模型设计的核⼼是追求模型的复⽤和共享，⼀个⽐较差的模型设计，⾃下⽽上是⼀条线。⽽⼀个理想的模型设计，它应该是交织的发散型结构。

模型引⽤系数：⼀个模型被读取，直接产出下游模型的平均数量。⽤模型引⽤系数作为指标，衡量数据中台模型设计的复⽤度。引⽤系数越⾼，说明数仓的复⽤性越好。
⽐如⼀张DWD层表被5张DWS层表引⽤，这张DWD层表的引⽤系数就是5，如果把所有DWD层表（有下游表的）引⽤系数取平均值，则为DWD层表平均模型引⽤系数，⼀般低于2⽐较差，3以上相对⽐较好（经验值）。
如何衡量规范度
⼀个规范的表命名应该包括主题域、分层、表是全量快照，还是增量等信息。
除此之外，如果在表A中⽤⼾ID的命名是UserID，在表B中⽤⼾ID命名是ID，就会对使⽤者造成困扰，这到底是不是⼀个东西。所以我们要求相同的字段在不同的模型中，它的命名必须是⼀致的。
模型命名规则：表的命名进⾏规范化统⼀，表的名称中最好能够携带表的主题域、业务过程、分层以及分区信息
历史模型改造流程，参见《数仓建模浅谈》
接管ODS层，控制源头
划分主题域，构建总线矩阵
构建一致性维度
事实表整合
ETL开发
应用迁移
指标规范
目标：建立指标字典，保证全局口径定义、数据来源和计算逻辑一致性；相同聚合粒度的指标，在数仓里尽量只计算加工一次，避免重复建设
指标常见问题：
相同指标名称，口径不一致
相同口径，指标名称不一致
不同限定词，描述相同事实过程的两个指标，相同事实部分口径不一致
指标口径描述不清楚
指标口径描述错误
指标命名难于理解
指标数据来源和计算逻辑不清晰
核心思想：
⾯向主题域管理，指标中的主题域与数仓中的概念是⼀致的
拆分原⼦指标和派⽣指标，统计周期、统计粒度、业务限定、原⼦指标，组成派⽣指标，所以原⼦指标可以定义为不能够按照上述规则进⼀步拆分的指标。
指标命名规范，做到易懂/统一，重点要能体现主题/业务过程/维度限定/业务限定/时间周期
分等级管理
⼀级指标：数据中台直接产出，核⼼指标（提供给公司⾼层看的）、原⼦指标以及跨部⻔的派⽣指标。要确保指标按时、保证质量产出；
⼆级指标：基于中台提供的原⼦指标，业务部⻔创建的派⽣指标。允许业务⽅⾃⼰创建。
指标分类

原子指标
基于某一业务过程下的度量，是业务定义中不可再拆分的指标，具有明确的业务含义
例：活跃人数、支付金额、购买用户数
衍生指标
对原子指标在业务统计范围中圈定，统计范围包括维度、各类日期和业务修饰词根
例：活跃男用户人数、7日支付金额
复合指标
是由衍生指标或原子指标复合而成，分为三类：

比率类：衡量业务过程的效果，如点击率、转化率、功能留存率、活跃留存率等；
均分类：均值、中位数及其他各类分位数；
占比类：部分占整体的比例，采用百分比的形式；
例：活跃男用户人数占比、复购率

构成指标词根分类：
基础指标词根：用于表示原子指标、衍生指标的对象度量，通用，如cnt ,user_cnt, amt, pv, uv
维度限定词根：某个维度的修饰词，通用，如男、女
业务修饰词根：用于描述和修饰实体对象、业务过程等，属于业务域
日期修饰词根：用于描述和限定日期长度，通用
复合比率词根：用于对复合指标的比率内容的描述，通用，如click_rate, rebuy_rate
复合均分词根：用于对复合指标进行聚合限定，包括均值、分位数等，通用，如avg
复合占比词根：用于对复合指标进行占比类的描述，通用，如ratio
指标命名规则：
对于原⼦指标，指标名称适合⽤“动作+度量”的命名⽅式（⽐如注册⽤⼾数、购买⽤⼾数），标识的命名⽤英⽂简写或者汉语拼⾳缩写⽐较好。
对于派⽣指标，指标名称应该严格遵循“时间周期+统计粒度+修饰词+原⼦指标”的命名⽅式，标识命名要⽤“修饰词_原⼦指标_时间周期”的⽅式。

元数据建设
采集维护元数据信息，用于驱动治理。具体采集哪些信息以及采集的手段都是多种多样的，可根据自身情况决定。

采集信息包括：

库/表信息
分区信息
血缘关系
访问记录
任务运行状态，成功/失败，消耗时间/资源
占用存储
采集方式：

metastore元数据
解析sql引用
调度系统运行记录
yarn web ui
治理体系建设
做数据治理，需要奉⾏“效果可量化”的原则，否则这个治理做到什么程度，很难衡量。

依据规范，对采集到的元数据进行加工，制定评估量化体系，产生可量化的指标，如归一化的具体分值，指导每个数仓开发进行数仓的规范化改造。

参与量化的因素可包括：

编码规范合规率
注释完善率
命名合规率
跨层依赖率
链路过长率
模型引用率（烟囱开发）
dqc通过率/覆盖率
sla达标率/覆盖率
无效计算/存储占比（访问热度）
异常计算/存储占比（数据倾斜/时间超长/占资源超多/小文件/数据未压缩等）
有了评估体系，就可以对数仓整体以及数据开发进行评分排名，对好的案例进行分享，坏的案例进行督促，使数仓逐渐向好的方向进化。
同时还可以对治理效果进行统计，如节省了多少资源/SLA提高了多少百分点，作为数仓治理的可量化产出成果。

配套工具建设
最后，好用的配套工具不仅可以使我们建设数仓事半功倍，还可以帮助我们建设更好的数仓。

指标管理工具
必须要有⼀个专⻔负责指标管理的⼈或者⼩组，经过评审的符合规范的指标口径通过专人录入指标管理系统，作为唯一官方口径出口。
指标管理系统中的指标，向下可以和物理的表或字段建立直接或间接关联；向上可以和使用该指标的平台、应用建立关联。

元数据管理系统
提供元数据的采集/存储/展示/获取工具和接口。

元数据一般可划为三类：数据字典、数据⾎缘和数据特征。

数据字典描述的是数据的结构信息，如

数据⾎缘是指⼀个表是直接通过哪些表加⼯⽽来，描述上下游关系。
数据⾎缘⼀般会帮我们做影响分析和故障溯源 。 ⽐如说有⼀天，⽼板看到某个指标的数据违反常识，需要去排查这个指标计算是否正确， ⾸先需要找到这个指标所在的表，然后顺着这个表的上游表逐个去排查校验数据，才能找到异常数据的根源。
⾎缘采集，⼀般可以通过三种⽅式：
通过静态解析SQL，获得输⼊表和输出表；
通过实时抓取正在执⾏的SQL，解析执⾏计划，获取输⼊表和输出表；
通过任务调度⽇志解析的⽅式，获取执⾏后的SQL输⼊表和输出表。
数据特征主要是指数据的属性信息，如

数据质量监控工具
“发现晚，排查慢，修复时间长”是令数据开发头疼的问题，做好数据质量监控，能最大限度解决“发现晚，排查慢”的问题。

核心功能：数据异常点发现；SLA监控预警。

在数据加⼯任务中，对产出表按照业务规则，设计⼀些校验逻辑，确保数据的完整性、⼀致性和准确性，这是提升数据质量最⾏之有效的⽅法。

对任务DAG中每个表增加稽核校验规则之后，当其中任何⼀个节点产出的数据出现异常时，我们能够第⼀时间发现，并⽴即修复，做到早发现、早修复。

数据质量也可以作为一个因素，加入到评估体系中。

生命周期管理工具
可以根据表的生命周期配置进行数据清理或存储迁移（冷热数据机制，如阿里的oss可以选择普通/低频/归档等存储策略）操作，也可以针对没有引用的表或低热度表进行提醒/处理。

⼀般原始数据和明细数据，会保留完整的历史数据。⽽在汇总层、集市层或者应⽤层，考虑到存储成本，数据建议按照⽣命周期来管理，通常保留⼏天的快照或者分区。如果存在⼤表没有设置⽣命周期，就会浪费存储资源。

成本管理工具
量化不同业务的成本，发现数据应⽤价值很低，成本却很⾼的报表/应用。

数据成本如何计算？

要对上图中财务分析报表核算成本，这个报表上游链路中涉及到a，b，c，3个任务，A，B，C，D， E，F， 6张表，那么：这张报表的成本=3个任务加⼯消耗的计算资源成本+6张表消耗的存储资源的成本。
另外，需要注意的是，如果⼀个表被多个下游应⽤复⽤，那这个表的存储资源成本以及产出任务消耗的成本，需要分摊给多个应⽤。

价值如何计算？

如果末端数据是⼀张应⽤层的表，它对接的是⼀个数据报表，那衡量这个数据的价值，主要是看报表的使⽤范围和使⽤频率。在计算使⽤范围时，通常⽤周活来评估，同时还要考虑不同管理级别的⼈权重，对于⽼板，他⼀个⼈的权重可以相当于1000个普通员⼯。之所以这样设计，是考虑到管理级别越⾼，做出的商业决策影响就越⼤，⾃然这个价值也就越⼤。使⽤频率⼀般使⽤单个⽤⼾每周查看报表的次数来衡量，次数越⾼，说明报表价值越⼤。
如果末端数据对接的不是⼀个数据报表，⽽是⾯向特定场景的数据应⽤（⽐如供应链分析决策系统，它⾯向的⼈群主要是供应链部⻔）。衡量这类产品的价值，主要考虑⽬标⼈群的覆盖率和直接业务价值产出。什么是直接业务价值产出呢？在供应链决策系统中，就是通过系统⾃动⽣成的采购订单占所有采购订单的⽐例。
除此之外，末端数据，可能还是⼀张集市层的表，它主要⽤于提供给分析师做探索式查询。这类表的价值主要看它被哪些分析师使⽤，使⽤频率如何。同样，在使⽤范围评估时，要对分析师按照级别进⾏加权。
知识库
日常任务失败/超时等异常问题自动/手动录入知识库，由开发人员进行登记解释，用于知识记录/分享

数据服务
统一对外数据提供接口，提高数据获取效率和复用率，并且方便数据权限管控和审计记录。

服务接⼝⼀⽅⾯对应⽤开发屏蔽了底层数据存储，使⽤统⼀标准的API接⼝查询数据，提⾼了数据接⼊的速度。另⼀⽅⾯，对于数据开发，提⾼了数据应⽤的管理效率，建⽴了表到应⽤的链路关系，解决“上线容易，下线难”的窘境。

数据服务核心功能：

屏蔽异构数据源：数据服务必须要能够⽀撑类型丰富的查询引擎，满⾜不同场景下数据的查询需求，常⻅的 有MySQL、HBase、Greenplum、Redis、Elasticsearch等。
数据⽹关：要实现包括权限、监控、流控、⽇志在内的⼀系列管控能⼒，哪个应⽤的哪个⻚⾯访问了哪个模型，要做到实时跟踪，如果有⼀些模型⻓时间没有被访问，应该予以下线。使⽤数据的每个应⽤都应该通过accesskey和secretkey实现⾝份认证和接⼝权限的管理。另外，访问⽇志可以⽅便在访问出现问题时，加快排查速度。
逻辑模型：从⽤⼾的视⻆出发，屏蔽底层的模型设计的实现，⾯向⽤⼾提供逻辑模型。什么是逻辑模型呢？熟悉数据库的同学应该知道，数据库中有⼀个视图的概念，视图本⾝并没有真实的数据，⼀个视图可以关联⼀张或者多张表，每次在查询的时候，动态地将不同表的查询结果聚合成视图的查询结果。逻辑模型可以类⽐视图，它可以帮助应⽤开发者屏蔽底层的数据物理实现，实现相同粒度的数据构造⼀个逻辑模型，简化了数据接⼊/变更的复杂度。
性能和稳定性：由于数据服务侵⼊到⽤⼾的访问链路，所以对服务的可⽤性和性能都有很⾼的要求，数据服务必须是⽆状态的，可以做到横向扩展。

参考资料
看完了这篇实时数仓建设，才发现以前的都白看了（内有美团案例）
数仓架构演进
网易严选数仓任务治理实践
元数据中⼼的关键⽬标和技术实现⽅案
如何统⼀管理纷繁杂乱的数据指标？
数据模型⽆法复⽤，归根结底还是设计问题
今天的数据怎么又不对？！
数据中台到底怎么建设呢？
交付速度和质量问题解决了，⽼板说还得“省”
（⼀）数据服务到底解决了什么问题？
（二）数据服务难道就是对外提供个API吗？