模型是整个数仓建设基石，规范是数仓建设的保障。为了避免出现指标重复建设和数据质量差的情况，我们统一按照最详细、可落地的方法进行规范建设。
(1) 词根
词根是维度和指标管理的基础，划分为普通词根与专有词根，提高词根的易用性和关联性。
- 普通词根：描述事物的最小单元体，如：交易-trade。
- 专有词根：具备约定成俗或行业专属的描述体，如：美元-USD。
(2) 表命名规范
通用规范
- 表名、字段名采用一个下划线分隔词根（示例：clienttype->client_type）。
- 每部分使用小写英文单词，属于通用字段的必须满足通用字段信息的定义。
- 表名、字段名需以字母为开头。
- 表名、字段名最长不超过64个英文字符。
- 优先使用词根中已有关键字（数仓标准配置中的词根管理），定期Review新增命名的不合理性。
- 在表名自定义部分禁止采用非标准的缩写。
表命名规则表名称 = 类型 + 业务主题 + 子主题 + 表含义 + 存储格式 + 更新频率 +结尾，如下图所示：
图6 统一的表命名规范
(3) 指标命名规范
结合指标的特性以及词根管理规范，将指标进行结构化处理。
A. 基础指标词根，即所有指标必须包含以下基础词根：
| 基础指标词根 | 英文全称 | Hive数据类型 | MySQL数据类型 | 长度 | 精度 | 词根 | 样例 |
|---|---|---|---|---|---|---|---|
| 数量 | count | Bigint | Bigint | 10 | 0 | cnt | |
| 金额类 | amout | Decimal | Decimal | 20 | 4 | amt | |
| 比率/占比 | ratio | Decimal | Decimal | 10 | 4 | ratio | 0.9818 |
| …… | …… | …… | …… | …… |
B.业务修饰词，用于描述业务场景的词汇，例如trade-交易。
C.日期修饰词，用于修饰业务发生的时间区间。
| 日期类型 | 全称 | 词根 | 备注 |
|---|---|---|---|
| 日 | daily | d | |
| 周 | weekly | w | |
| …… | …… | …… |
D.聚合修饰词，对结果进行聚集操作。
| 聚合类型 | 全称 | 词根 | 备注 |
|---|---|---|---|
| 平均 | average | avg | |
| 周累计 | wtd | wtd | 本周一截止到当天累计 |
| …… | …… | …… |
E.基础指标，单一的业务修饰词+基础指标词根构建基础指标 ，例如：交易金额-trade_amt。
F.派生指标，多修饰词+基础指标词根构建派生指标。派生指标继承基础指标的特性，例如：安装门店数量-install_poi_cnt。
G.普通指标命名规范，与字段命名规范一致，由词汇转换即可以。
图7 普通指标规范
H.日期类型指标命名规范，命名时要遵循：业务修饰词+基础指标词根+日期修饰词/聚合修饰词。将日期后缀加到名称后面，如下图所示：
图8 日期类型指标规范
I.聚合类型指标，命名时要遵循：业务修饰词+基础指标词根+聚合类型+日期修饰词。将累积标记加到名称后面，如下图所示：
图9 聚合类指标规范
(4) 清洗规范
确认了字段命名和指标命名之后，根据指标与字段的部分特性，我们整理出了整个数仓可预知的24条清洗规范：
| 数据类型 | 数据类别 | Hive类型 | MySQL类型 | 长度 | 精度 | 词根 | 格式说明 | 备注 |
|---|---|---|---|---|---|---|---|---|
| 日期类型 | 字符日期类 | string | varchar | 10 | date | YYYY-MM-DD | 日期清洗为相应的格式 | |
| 数据类型 | 数量类 | bigint | bigint | 10 | 0 | cnt | 活跃门店数量 | |
| …… | …… | …… | …… | …… | …… | …… | …… |
- 区分使用 TINYINT、SMALLINT、INT、BIGINT 数据类型,；建议使用 TINYINT 代替 BOOLEAN, 提高扩展性和类型转换兼容性；尽量使用低存储数据类型以提高运行效率；
- 金额字段统一使用DECIMAL，时间字段(精确到十分秒)字段统一使用TIMESTAMP以提升比较效率， 分区字段及日期字段（没有时分秒）使用 String（格式统一为 yyyyMMdd）。
(4) 编码规范
1、程序代码：每层一个代码目录，用于存放对应层的模型开发工程。
2、HQL代码：
(1) 使用 left semi join 代替 in/exists；
(2) join 时小表尽量放在左边，如小表足够小可使用 map join，hive 已支持自动判断大小表；
(3) 排序尽量使用 distribute+sort 组合，避免全表 order by；
(4) 尽量使用静态分区，提升运行效率；例行补数建议使用动态分区简化代码；
(5) 慎用笛卡尔积 join，卡历史数据建议使用日期维度表作笛卡尔积，以并行循环操作；
(6) 尽量使用窗口函数、udf 简化 sql 逻辑，提升代码可读性；
(7) join/group by/distinct 注意处理 NULL 值，尽量避免数据倾斜；
(8) union 会去重, 不用去重时使用 union all；
(9) 表查询如果是分区表, 尽量加上分区限制。
结合模型与规范，形成模型设计及模型评审两者的工作职责，如下图所示：
图10 模型设计和审计职责
统一应用归口
在对原有的应用支持流程进行梳理的时候，我们发现整个研发过程是烟囱式。如果不进行改善就会导致前面的建设”毁于一旦“，所以需对原有应用支持流程进行改造，如下图所示：
图11 应用归口
从图中可以看出，重构前一个应用存在多次迭代，每次迭代都各自维护自己的文档。烟囱式开发会导致业务信息混乱、应用无法与文档对齐、知识传递成本、维护成本和迭代成本大大增加等问题。重构后，应用与知识库相对应，保证一个应用只对应一份文档，且应用统一要求在一份文档上进行迭代，从根源上改变应用支持流程。同时，针对核心业务细节和所支撑的数据信息，进行了全局调研并归纳到知识库。综合统一的知识库，降低了知识传递、理解、维护和迭代成本。
统一归口策略包含业务归口统一、设计归口统一和应用归口统一，从底层保证了数仓建设的三特性和三效果。
统一数据出口
数仓建设不仅仅是为了数据内容而建设，同时也为了提高交付的数据质量与数据使用的便利性。如何保证数据质量以及推广数据的使用，我们提出了统一数据出口策略。在进行数据资产管理和统一数据出口之前，必须高质量地保障输出的数据质量，从而树立OneData数据服务体系的权威性。
1.交付标准化
如何保证数据质量，满足什么样的数据才是可交付的，是数据建设者一直探索的问题。为了保证交付的严谨性，在具体化测试方案之前，我们结合数仓的特点明确了数据交付标准的五个特性，如下图所示：
图12 交付标准化
《交付标准化》完善了整个交付细节，从根本上保证了数据的质量，如：业务测试保障数据的合理性、一致性；技术测试保障数据的唯一性、准确性；数据平台的稳定性和后期人工维护保障数据的及时性。
2.数据资产管理
针对如何解决数据质量中维度与指标一致性以及如何提高数据易用性的问题，我们提出数据资产的概念，借助公司内部平台工具“起源数据平台”实现了整个数据资产管理，它的功能如下图所示：
图13 起源功能体系
借用起源数据平台，我们实现了：
- 统一指标管理，保证了指标定义、计算口径、数据来源的一致性。
- 统一维度管理，保证了维度定义、维度值的一致性。
- 统一数据出口，实现了维度和指标元数据信息的唯一出口，维值和指标数据的唯一出口。
通过交付标准化和数据资产管理，保证了数据质量与数据的易用性，同时我们也构建出OneData数据体系中数据指标管理的核心。
转载自 https://tech.meituan.com/2019/10/17/meituan-saas-data-warehouse.html
真心感觉美团技术团队🐂🍺
