数据层次的划分

• ODS：Operational Data Store，操作数据层，在结构上其与源系统的增量或者全量数据基本保持一致。它相当于一个数据准备区，同时又承担着基础数据的记录以及历史变化。其主要作用是把基础数据引入到MaxCompute。

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

  • DWD：Data Warehouse Detail，明细数据层。

  • DWS：Data Warehouse Summary，汇总数据层。

• ADS：Application Data Service，应用数据层。

具体仓库的分层情况需要结合业务场景、数据场景、系统场景进行综合考虑。

数据分类架构

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

• 公共维度层：基于维度建模理念思想，建立整个企业的一致性维度。

• 明细粒度事实层：以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。您可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当的冗余，即宽表化处理。

• 公共汇总粒度事实层：以分析的主题对象为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段来物理化模型。

数据处理流程架构

数据划分及命名空间约定

请根据业务划分数据并约定命名，建议针对业务名称结合数据层次约定相关命名的英文缩写，这样可以给后续数据开发过程中，对项目空间、表、字段等命名做为重要参照。

• 按业务划分：命名时按主要的业务划分，以指导物理模型的划分原则、命名原则及使用的ODS project。例如，按业务定义英文缩写，阿里的“淘宝”英文缩写可以定义为“tb”。

• 按数据域划分：命名时按照CDM层的数据进行数据域划分，以便有效地对数据进行管理，以及指导数据表的命名。例如，“交易”数据的英文缩写可定义为“trd”。

• 按业务过程划分：当一个数据域由多个业务过程组成时，命名时可以按业务流程划分。业务过程是从数据分析角度看客观存在的或者抽象的业务行为动作。例如，交易数据域中的“退款”这个业务过程的英文缩写可约定命名为“rfd_ent”。

数据模型

模型是对现实事物的反映和抽象，能帮助我们更好地了解客观世界。数据模型定义了数据之间关系和结构，使得我们可以有规律地获取想要的数据。例如，在一个超市里，商品的布局都有特定的规范，商品摆放的位置是按照消费者的购买习惯以及人流走向进行摆放的。

• 数据模型的作用

  数据模型是在业务需求分析之后，数据仓库工作开始时的第一步。良好的数据模型可以帮助我们更好地存储数据，更有效率地获取数据，保证数据间的一致性。

• 模型设计的基本原则

  • 高内聚和低耦合

    一个逻辑和物理模型由哪些记录和字段组成，应该遵循最基本的软件设计方法论中的高内聚和低耦合原则。主要从数据业务特性和访问特性两个角度来考虑：将业务相近或者相关的数据、粒度相同数据设计为一个逻辑或者物理模型；将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储。

  • 核心模型与扩展模型分离

    建立核心模型与扩展模型体系，核心模型包括的字段支持常用核心的业务，扩展模型包括的字段支持个性化或是少量应用的需要。在必须让核心模型与扩展模型做关联时，不能让扩展字段过度侵入核心模型，以免破坏了核心模型的架构简洁性与可维护性。

  • 公共处理逻辑下沉及单一

    底层公用的处理逻辑应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑在多处同时存在。

  • 成本与性能平衡

    适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。

  • 数据可回滚

    处理逻辑不变，在不同时间多次运行数据的结果需确定不变。

  • 一致性

    相同的字段在不同表中的字段名必须相同。

  • 命名清晰可理解

    表命名规范需清晰、一致，表命名需易于下游的理解和使用。

编码规范

通过DataWorks进行数据开发时，在DataWorks的数据开发工作台上进行代码编辑的规范。

• 代码头部

  代码头部添加主题、功能描述、作者、日期等信息。并提供修改日志及标题栏的功能，以便后续修改人员添加修改记录。每一行不能超过80个字符。

  DataWorks中针对不同的任务类型提供了不同的代码头部模板，也可以在配置中心自定义头部模板。例如，SQL类型任务头部模板默认为如下。

  --odps sql 
  --********************************************************************--
  --author:${author}
  --create time:${createTime}
  --********************************************************************--

• 字段排列要求

  • SELECT语句选择的字段按每行一个字段方式编排。

  • SELECT单字后面一个缩进量后应直接跟首个选择的字段，即字段离首起二个缩进量。

  • 其它字段前导二个缩进量再跟一个逗号（，）后放置字段名。

  • 两个字段之间的逗号（，）分割符紧跟在第二个字段的前面。

  • AS语句应与相应的字段在同一行，多个字段的AS建议尽量对齐在同一列上。

    

    字段排列

• SELECT子句排列要求

  SELECT语句中所用到的FROM、WHERE、GROUP BY、HAVING、ORDER BY、JOIN、UNION等子句，需遵循如下要求：

  

  SELECT子句排列

  • 换行编写。

  • 与相应的SELECT语句左对齐编排。

  • 子句后续的代码离子句首字母二个缩进量起编写。

  • WHERE子句下的逻辑判断符AND、OR等与WHERE左对齐编排。

  • 超过两个缩进量长度的子句加一空格后编写后续代码。例如ORDER BY、GROUP BY等。

• 运算符前后间隔要求

  算术运算符、逻辑运算符的前后要保留一个空格。

  

  运算符前后间隔

• CASE语句的编写

  SELECT语句中对字段值进行判断取值的操作将用到CASE语句，正确的编排CASE语句对加强代码行的可读性也是很关键的一部分。对CASE语句编排的约定如下：

  

  CASE语句

  • WHEN子句在CASE语句的同一行并缩进一个缩进量后开始编写。

  • 每个WHEN子句单独一行编写，如果语句较长可换行编写。

  • CASE语句必须包含ELSE子语，ELSE子句与WHEN子句对齐。

• 子查询嵌套编写规范

  在数据仓库系统ETL开发中经常需要用到子查询嵌套，因此代码的分层编排变得非常重要。

  

  子查询嵌套

• 表别名定义约定

  建议对所有的表加上别名。一旦在SELECT语句中对表定义了别名，在整个语句中对此表的引用都必须以别名替代。考虑到编写代码的便捷性，约定别名尽量简洁，同时避免使用关键字。表别名定义约定如下：

  

  表别名

  • 表别名采用简单字符命名。

  • 多层次的嵌套子查询，在别名之前要体现层次关系。SQL语句别名或分层的命名，从第一层次至第四层次，分别用P、S、U、D表示，取意为Part，Segment，Unit，Detail。也可用a、b、c、d来表示第一层次到第四层次。对于同一层次的多个子句，可以在字母后加1、2、3、4区分。

  • 必要时，为表别名添加注释。

• SQL注释

  • 每条SQL语句均应添加注释说明。

  • 每条SQL语句的注释单独成行并置于语句前面。

  • 字段注释紧跟在字段后面。

  • 应为不易理解的分支条件表达式添加注释。

  • 应说明重要计算的功能。

  • 过长的函数实现，应将其语句按实现的功能分段加以概括性说明。

  • 常量及变量注释时，必须注释被保存值的含义，按需注释合法的取值范围 。

详解数仓中的数据分层：ODS、DWD、DWM、DWS、ADS

何为数仓DW

Data warehouse（可简写为DW或者DWH）数据仓库，是在数据库已经大量存在的情况下，它是一整套包括了etl、调度、建模在内的完整的理论体系。

数据仓库的方案建设的目的，是为前端查询和分析作为基础，主要应用于OLAP（on-line Analytical Processing），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。目前行业比较流行的有：AWS Redshift，Greenplum，Hive等。

数据仓库并不是数据的最终目的地，而是为数据最终的目的地做好准备，这些准备包含：清洗、转义、分类、重组、合并、拆分、统计等

为何要分层

数据仓库中涉及到的问题：

1. 为什么要做数据仓库？

2. 为什么要做数据质量管理？

3. 为什么要做元数据管理？

4. 数仓分层中每个层的作用是什么？

5. …...

在实际的工作中，我们都希望自己的数据能够有顺序地流转，设计者和使用者能够清晰地知道数据的整个声明周期，比如下面左图。

但是，实际情况下，我们所面临的数据状况很有可能是复杂性高、且层级混乱的，我们可能会做出一套表依赖结构混乱，且出现循环依赖的数据体系，比如下面的右图。

为了解决我们可能面临的问题，需要一套行之有效的数据组织、管理和处理方法，来让我们的数据体系更加有序，这就是数据分层。数据分层的好处：

• 清晰数据结构：让每个数据层都有自己的作用和职责，在使用和维护的时候能够更方便和理解

• 复杂问题简化：将一个复杂的任务拆解成多个步骤来分步骤完成，每个层只解决特定的问题

• 统一数据口径：通过数据分层，提供统一的数据出口，统一输出口径

• 减少重复开发：规范数据分层，开发通用的中间层，可以极大地减少重复计算的工作

数据分层

每个公司的业务都可以根据自己的业务需求分层不同的层次；目前比较流行的数据分层：数据运营层、数据仓库层、数据服务层。

数据运营层ODS

数据运营层：Operation Data Store 数据准备区，也称为贴源层。数据源中的数据，经过抽取、洗净、传输，也就是ETL过程之后进入本层。该层的主要功能：

• ODS是后面数据仓库层的准备区

• 为DWD层提供原始数据

• 减少对业务系统的影响

为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可

这层的数据是后续数据仓库加工数据的来源。数据来源的方式：

1. 业务库：sqoop定时抽取数据；实时方面考虑使用canal监听mysql的binlog日志，实时接入即可

2. 埋点日志：日志一般是以文件的形式保存，可以选择使用flume来定时同步；可以使用spark streaming或者Flink、Kafka来实时接入

3. 消息队列：来自ActiveMQ、Kafka的数据等

数据仓库层

数据仓库层从上到下，又可以分为3个层：数据细节层DWD、数据中间层DWM、数据服务层DWS。

数据细节层DWD

数据细节层：data warehouse details，DWD

该层是业务层和数据仓库的隔离层，保持和ODS层一样的数据颗粒度；主要是对ODS数据层做一些数据的清洗和规范化的操作，比如去除空数据、脏数据、离群值等。

为了提高数据明细层的易用性，该层通常会才采用一些维度退化方法，将维度退化至事实表中，减少事实表和维表的关联。

数据中间层DWM

数据中间层：Data Warehouse Middle，DWM；

该层是在DWD层的数据基础上，对数据做一些轻微的聚合操作，生成一些列的中间结果表，提升公共指标的复用性，减少重复加工的工作。

简答来说，对通用的核心维度进行聚合操作，算出相应的统计指标

数据服务层DWS

数据服务层：Data Warehouse Service，DWS；

该层是基于DWM上的基础数据，整合汇总成分析某一个主题域的数据服务层，一般是宽表，用于提供后续的业务查询，OLAP分析，数据分发等。

一般来说，该层的数据表会相对较少；一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。

数据应用层ADS

数据应用层：Application Data Service，ADS；

该层主要是提供给数据产品和数据分析使用的数据，一般会存放在ES、Redis、PostgreSql等系统中供线上系统使用；也可能存放在hive或者Druid中，供数据分析和数据挖掘使用，比如常用的数据报表就是存在这里的。

事实表 Fact Table

事实表是指存储有事实记录的表，比如系统日志、销售记录等。事实表的记录在不断地增长，比如电商的商品订单表，就是类似的情况，所以事实表的体积通常是远大于其他表。

维表层Dimension

维度表（Dimension Table）或维表，有时也称查找表（Lookup Table），是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联，相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。维度表主要是包含两个部分：

• 高基数维度数据：一般是用户资料表、商品资料表类似的资料表，数据量可能是千万级或者上亿级别

• 低基数维度数据：一般是配置表，比如枚举字段对应的中文含义，或者日期维表等；数据量可能就是个位数或者几千几万。