关于数据仓库:数据仓库开发规范

数据仓库系列文章(继续更新)

1. 数仓架构发展史
2. 数仓建模方法论
3. 数仓建模分层实践
4. 数仓建模—宽表的设计
5. 数仓建模—指标体系
6. 数据仓库之拉链表
7. 数仓—数据集成
8. 数仓—数据集市
9. 数仓—商业智能零碎
10. 数仓—埋点设计与治理
11. 数仓—ID Mapping
12. 数仓—OneID
13. 数仓—AARRR海盗模型
14. 数仓—总线矩阵
15. 数仓—数据安全
16. 数仓—数据品质
17. 数仓—数仓建模和业务建模

关注公众号：大数据技术派，回复: 材料，支付1024G材料。

凡事无规矩不立，所以你会常常看到各种各样的标准，面对标准须要恪守，然而不能自觉，例如咱们开发人员最常看到的就是《Mysql 开发标准》、《Java 编程手册》、《Java 开发标准》 之类的货色，这些货色的出发点有三方面：

1. 进步性能
2. 防止谬误
3. 方便管理

其实很多标准都是这三方都相干的，然而咱们明天介绍的数仓标准次要是为了防止谬误和方便管理，其实方便管理这个话题咱们后面说了好屡次了，这里你能够参考后面的文章数仓建模—分层建设实践、数仓建模—数据集市 这些在肯定水平上来说都是为了方便管理。

数据档次的划分

具体仓库的分层状况须要联合业务场景、数据场景、零碎场景进行综合思考，上面咱们看一下常见的分层

• ODS：Operational Data Store，操作数据层，在结构上其与源零碎的增量或者全量数据根本保持一致。它相当于一个数据筹备区，同时又承当着根底数据的记录以及历史变动。其次要作用是把根底数据引入到数仓。

• CDM：Common Data Model，公共维度模型层，又细分为DWD和DWS。它的次要作用是实现数据加工与整合、建设一致性的维度、构建可复用的面向剖析和统计的明细事实表以及汇总公共粒度的指标。

  • DWD：Data Warehouse Detail，明细数据层。
  • DWS：Data Warehouse Summary，汇总数据层。
• ADS：Application Data Service，利用数据层。

数据分类架构

该数据分类架构在ODS层分为三局部：数据筹备区、离线数据和准实时数据区。在进入到CDM层后，由以下几局部组成：

• 公共维度层：基于维度建模理念思维，建设整个企业的一致性维度。
• 明细粒度事实层：以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。您能够联合企业的数据应用特点，将明细事实表的某些重要维度属性字段做适当的冗余，即宽表化解决。
• 公共汇总粒度事实层：以剖析的主题对象为建模驱动，基于下层的利用和产品的指标需要，构建公共粒度的汇总指标事实表，以宽表化伎俩来物理化模型。

数据划分及命名约定

请依据业务划分数据并约定命名，倡议针对业务名称联合数据档次约定相干命名的英文缩写，这样能够给后续数据开发过程中，对我的项目空间、表、字段等命名做为重要参照。

#### 数据划分

• 按业务划分：命名时按次要的业务划分，以领导物理模型的划分准则、命名准则及应用的ODS project。
• 按数据域划分：命名时依照CDM层的数据进行数据域划分，以便无效地对数据进行治理，以及领导数据表的命名。
• 按业务过程划分：当一个数据域由多个业务过程组成时，命名时能够按业务流程划分。业务过程是从数据分析角度看客观存在的或者形象的业务行为动作。

命名约定

如果公司业务线比拟多，咱们能够依照我的项目的模式进行划分，如果不是间接依照档次划分，project\_ods、project\_dwd

ODS层命名标准

表命名标准 表命名规定：{档次}{源零碎表名}{工夫单位与增全量},i示意增量，f示意全量 ,d 示意天, h示意小时

• 增量数据：{project_name}.s{源零碎表名}_di。
• 全量数据：{project_name}.s{源零碎表名}_df。
• ODS ETL过程的长期表：{project_name}.tmp{长期表所在过程的输出表}{从0开始的序号}。
• 按小时同步的增量表：{project_name}.s{源零碎表名}_hi。
• 按小时同步的全量表：{project_name}.s{源零碎表名}_hf。
• 当不同源零碎同步到同一个Project下的表命名抵触时，您须要给同步较晚的表名加上源零碎的dbname以解决抵触。
• 字段命名标准 字段默认应用源零碎的字段名。
• 字段名与关键字抵触时，在源字段名后加上\_col，即源字段名\_col。
• 同步工作命名标准 工作名：倡议和表名保持一致。

dim 层命名标准

命名规定：{project_name}.dim{业务/pub}{维度定义}[_{自定义命名标签}]，其中的pub与具体业务无关，各个业务部都能够共用，例如工夫维度。

• 公共区域维表dim_pub_area
• 公司社群板块的群成员全量表dim_group_member

dwd 层命名标准

通常须要遵循的命名标准为：dwd_{业务板块/pub}_{数据域缩写}_{业务过程缩写}[_{自定义表命名标签缩写}] _{单分区增量全量标识}，pub示意数据包含多个业务板块的数据。

单分区增量全量标识通常为：i示意增量，f示意全量。例如： dwd_group_create_inf_df（公司社群创立事实表，日刷新全量）及dwd_group_chat_di（公司社群发消息事实表，日刷新增量）。

dws 层命名标准

公共汇总事实表命名标准：dws_{业务板块缩写/pub}_{数据域缩写}_{数据粒度缩写}[_{自定义表命名标签缩写}]_{统计工夫周期范畴缩写}。

• 对于统计理论周期范畴缩写，缺省状况下，离线计算应该包含最近一天（_1d），最近N天（_nd）和历史截至当天（_td）三个表。
• 对于小时表（无论是天刷新还是小时刷新），都用_hh 来示意。
• 对于分钟表（无论是天刷新还是小时刷新），都用_mm来示意。

举例如下：

• dws_group_patient_join_1d（公司社群患者加群一日汇总事实表）
• dws_group_patient_exit_td（公司社群患者退群截至当日汇总表）

档次调用约定

应用层应优先调用公共层数据，必须存在中间层数据，不容许应用层跨过中间层从ODS层反复加工数据。一方面，中间层人员应该踊跃理解应用层数据的建设需要，将专用的数据积淀到公共层，为其余人员提供数据服务；另一方面，应用层人员也应踊跃配合中间层人员进行继续的数据公共建设的革新。必须避免出现适度的援用ODS层、不合理的数据复制以及子集合冗余。

• ODS层数据不能被应用层工作援用，中间层不能有积淀的ODS层数据，必须通过CDM层的视图拜访。CDM层视图必须应用调度程序进行封装，放弃视图的可维护性与可管理性。
• CDM层工作的深度不宜过大（倡议不超过10层）。
• 原则上一个计算刷新工作只容许一个输出表。
• 如果多个工作刷新输入一个表（不同工作插入不同的分区），DataWorks上须要建设一个依赖多个刷新工作的虚构工作，通常上游应该依赖此虚构工作。
• CDM汇总层应优先调用CDM明细层。在调用可累加类指标计算时，CDM汇总层尽量优先调用曾经产出的粗粒度汇总层，以防止大量汇总间接从海量的明细数据层计算。
• CDM明细层累计快照事实表优先调用CDM事务型事实表，以保持数据的一致性产出。
• 防止应用层适度援用和依赖CDM层明细数据，须要针对性地建设好CDM公共汇总层。

数据类型标准

ODS层的数据类型应基于源零碎数据类型转换。例如，源数据为MySQL时的转换规则如下。

MySQL数据类型Hive数据类型

CDM数据公共层如果是援用ODS层数据，则默认应用ODS层字段的数据类型。其衍生加工数据字段按以下规范执行：

• 金额类及其它小数点数据应用DOUBLE类型。
• 字符类数据应用STRING类型。
• ID类和整形数值应用BIGINT类型。
• 工夫类型数据应用STRING类型（如果有非凡的格局要求，能够选择性应用DATETIME类型）。
• 状态应用STRING类型。

公共字段定义标准

数据统计日期的分区字段按以下规范：

• 按天分区：ds(YYYYMMDD)。
• 按小时分区：hh(00-23)。
• 按分钟：mi (00-59)。
• is_{业务}：示意布尔型数据字段。以Y和N示意，不容许呈现空值域。
• 原则上不须要冗余分区字段。

数据冗余

一个表做宽表冗余维度属性时，应该遵循以下倡议准则：

• 冗余字段与表中其它字段高频率（大于3个上游利用SQL）同时拜访。
• 冗余字段的引入不应造成其自身的刷新实现工夫产生过多后延。
• 公共层数据不容许字段反复率大于60%的雷同粒度数据表冗余，能够抉择在原表根底上拓宽或者在上游利用中通过JOIN形式实现。

数据拆分

数据的程度和垂直拆分是依照拜访热度散布和数据表非空数据值、零数据值在行列二维空间上散布状况进行划分的。

• 在物理上划分外围模型和扩大模型，将其字段进行垂直划分。
• 将拜访相关度较高的列在一个表存储，将拜访相关度较低的字段离开存储。
• 将常常用到的Where条件按记录行进行程度切分或者冗余。程度切分能够思考二级分区伎俩，以防止多余的数据复制与冗余。
• 将呈现大量空值和零值的统计汇总表，根据其空值和零值散布情况能够做适当的程度和垂直切分，以缩小存储和上游的扫描数据量。

空值解决准则

• 汇总类指标的空值：空值解决，填充为零
• 维度属性值为空：在汇总到对应维度上时，对于无奈对应的统计事实，记录行会填充为-99（未知），对应维表会呈现一条-99（未知）的记录。

设计准则

• 一致性维度标准

  公共层的维度表中雷同维度属性在不同物理表中的字段名称、数据类型、数据内容必须保持一致。除了以下状况：

  • 在不同的理论物理表中，如果因为维度角色的差别，须要应用其余的名称，其余名称也必须是标准的维度属性的别名。例如，定义一个规范的会员ID时，如果在一个表中，别离要示意买家ID，卖家ID，那么设计规范阶段就事后对会员ID别离定义买家ID和卖家ID。
  • 如果因为历史起因，在临时不统一的状况下，必须在标准的维度定义一个规范维度属性，不同的物理名也必须是来自规范维度属性的别名。

• 维度的组合与拆分

  • 组合准则

    • 将维度所形容业务相关性强的字段在一个物理维表实现。相关性强是指常常须要一起查问或进行报表展示、两个维度属性间是否存在人造的关系等。例如，商品根本属性和所属品牌。
    • 无相关性的维度能够适当思考杂项维度（例如交易），能够构建一个交易杂项维度收集交易的非凡标记属性、业务分类等信息。也能够将杂项维度进化在事实表中解决，不过容易造成事实表绝对宏大，加工解决较为简单。
    • 所谓的行为维度是通过汇总计算的指标，在上游的利用应用时将其当维度解决。如果有须要，度量指标能够作为行为维度冗余到维度表中。

  • 拆分与冗余

    • 对于维度属性过多，波及源较多的维度表（例如会员表），能够做适当拆分：

      • 拆分为外围表和扩大表。外围表绝对字段较少，刷新产出工夫较早，优先应用。扩大表字段较多，且能够冗余外围表局部字段，刷新产出工夫较晚，适宜数据分析人员应用。
      • 依据维度属性的业务不相关性，将相关度不大的维度属性拆分为多个物理表存储。

    • 数据记录数较大的维度表（例如商品表），能够适当冗余一些子集合，以缩小上游扫描数据量：

      • 能够依据当天是否有行为，产出一个有沉闷行为的相干维表，以缩小利用的数据扫描量。
      • 可依据所属业务扫描数据范畴大小的不同，进行适当子集合冗余。

数据存储及生命周期治理标准

CDM公共维度层的表的类型为维度表，存储形式为按天分区。

模型设计者依据本身业务需要设置表的生命周期治理。您可根据3个月内的最大须要拜访的跨度设置保留策略，具体计算形式如下：

• 当3个月内的最大拜访跨度小于或等于4地利，倡议将保留天数设为7天。
• 当3个月内的最大拜访跨度小于或等于12地利，倡议将保留天数设为15天。
• 当3个月内的最大拜访跨度小于或等于30地利， 倡议将保留天数设为33天。
• 当3个月内的最大拜访跨度小于或等于90地利，倡议将保留天数设为93天。
• 当3个月内的最大拜访跨度小于或等于180地利， 倡议将保留天数设为183天。
• 当3个月内的最大拜访跨度小于或等于365地利，倡议将保留天数设为368天

总结

其实标准这个货色很重要，然而有时候它的设计不那么可续，例如咱们公司的天分区字段是ds而不是pt,然而这个货色只有大家认可就行，然而不能因为不认可就不恪守。

标准其实就是约定，所以须要大家独特去保护和恪守。