数据仓库的构建

目录

一.数据仓库的定义

二.数仓构建规范

2.1数仓设计原则

2.2 数据层次划分

2.3 数仓层次调用规定

2.4 ODS层规范

2.5 CDW层规范

2.6 ADS层规范

三.数据仓库构建步骤

3.1 ODS层

3.2 CDW层

3.3 ADS层

四.总结

---

一.数据仓库的定义

关于数据仓库，在维基百科中将它定义为用于报表和数据分析的系统，是商务智能 Business Intelligence 的核心部分。在数据仓库诞生之初，它只被设计成面向管理层所需要的决策支持系统，并不对业务方（这里指各应用系统）提供数据支持。

然而在大数据环境的背景下，当 Hadoop 生态已然成为大数据现实意义上的载体，以 Hive 为基础的数据仓库已经不能仅仅只提供决策支持的需求了——它需要同时满足某些业务上对数据的统计需求。因此，当下的数据仓库应该有一个新的定义：大数据环境下的数据仓库是指对全局数据（包含时间和空间：历史的以及所有业务部门的）的存储及使用的一整套方法论。

二.数仓构建规范

2.1数仓设计原则

2.1.1 高内聚和低耦合

主要从数据业务特性和访问特性两个角度来考虑：

1)将业务相近或者相关的数据、粒度相同数据设计为一个逻辑或者物理模型；

2)将高概率同事访问的数据放一起，将低概率同时访问的数据分开存储。

2.1.2 数据可回滚

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

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

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

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

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

2.1.5 成本与性能平衡

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

2.1.6 开发过程规则

表命名清晰、一致，表名需易于使用者理解和使用，相同的字段含义在不同表中字段命名必须相同。

2.2 数据层次划分

如图所示，数据仓库分为三层，自下而上为：贴源数据层（ODS，Operation Data Store）、统一数仓层（CDW，Common Data Warehouse）和应用数据层（ADS，Application Data Service）。数据仓库的分层和各层级用途如下：

ODS层(Operational Data Store,贴源数据层)：数据通常和原始数据保持一致，目的是保持数据的完整性，不做任何数据方面的操作。因此ODS层的表结构会和原始数据保持一致。

CDW层(Common Data Warehouse,统一数仓层)：数据通常为我们所说的模型层，该层的数据通常会通过我们之前对业务的了解，对ODS层的数据进行清洗，转化等操作。同时，CDW层的数据类型会跟业务的数据类型保持一致。

ADS层(Application Data Service,应用数据层)：是在统一数仓层和贴源数据层都建设好的基础上，面向特定业务需求而准备的个性数据组装层。

数仓的建模或者分层，其实都是为了更好的去组织、管理、维护数据，所以当构建者站在更高的维度去看的话，所有的划分都是为了更好的管理。例如小到JVM 内存区域的划分，JVM 中堆空间的划分(年轻代、老年代、方法区等)，大到国家的省市区的划分，无一例外的都是为了更好的组织管理。 所以数仓分层是数据仓库设计中十分重要的一个环节，优秀的分层设计能够让整个数据体系更容易理解和使用。

2.3 数仓层次调用规定

应用层应优先调用统一数仓层(CDW层)数据，必须存在CDW层数据，不允许应用层跨过CDW层从ODS层重复加工数据。一方面，CDW层团队应该积极了解应用层数据的建设需求，将公用的数据沉淀到CDW层，为其他团队提供数据服务；另一方面，应用层团队也应积极配合CDW层团队进行持续的数据公共建设的改造。必须避免出现过度的引用ODS层、不合理的数据复制以及子集合冗余。

2.4 ODS层规范

2.4.1 命名规范

1.命名采用前缀+业务系统表名的方式

业务系统	表名
xx网	ODS_业务系统缩写_业务系统表名
外部爬虫数据	ODS_表名

2.字段名与业务系统字段名一致

3.字段类型尽可能保持一致

4.增量表利用后缀标识，如ODS__业务系统缩写_业务系统表名_delta

5.按小时同步的增量表，利用后缀标识hh，如ODS_业务系统表名_delta_hh

6.表名长度不超过三十个字符

2.4.2 数据同步规范

1.对于数据量较大的业务数据表，如果采用增量同步的方式，则需同时建立增量表和全量表

2.对于日志、文件等半结构化数据，不仅要存储原始数据，还要存储结构化后的数据

3.对于非结构化数据，不保留原始文件，只保留对原始数据文件的描述，比如地址、名称、类型、分辨率等

2.5 CDW层规范

2.5.1 命名规范

1.事实表

前缀+业务领域拼音缩写+事实表英文标识+表名的方式，前缀为CDW_，事实表英文标识为F_。

业务领域	表名
xx	CDW_xx_F_具体表名

2.维度表

前缀+业务领域拼音缩写+维度表英文标识+表名的方式，前缀为CDW_，维度表英文标识为D_。

业务领域	表名
xx	CDW_xx_D_具体表名

2.5.2 模型规范

采用星型模型建模，星型模型一般采用降维的操作，利用冗余来避免模型过于复杂，提高易用性和分析效率。核心是一个事实表及多个非正规化描述的维度表组成，维度表之间是没有关联的，维度表是直接关联到事实表上。当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型。

2.6 ADS层规范

2.6.1 命名规范

前缀+表名的方式，前缀为ADS_，表名为指标英文标识。

2.6.2 数据表规范

应用数据层的建设是强业务驱动的，业务部门需要参与到应用数据层的建设中来。推荐的方式是，了解业务的人员将业务需求告知开发人员，然后在建模过程中深入沟通，这样形成的应用数据层的表设计才能既满足业务需求又符合整体的规范。因此应用数据层的结构为：

1.应用场景是多维的即席分析，一般为了减少连接、提升性能，会采用大宽表的形式组织。

2.如果是特定指标的查询，可以采用K-V表形式组织。

三.数据仓库构建步骤

3.1 ODS层

3.1.1数据收集步骤

构建ODS层需要对原始业务系统的数据进行盘点，产出数据资产文档。可以从以下维度进行调研：

1.业务系统的数据库名称，表名称，字段名称，字段类型等，产出数据模型。

2.检查原始数据质量，记录问题详情，产出数据治理文档，作为数据治理工作的依据。

3.研究业务系统数据的更新方式以及更新频率，决定数据同步工具的更新方式。

3.1.2存储库介绍

3.1.2数据同步介绍

·原理

1.采用Binlog日志的方式进行数据同步

2.先全量同步，后续采用增量同步进行数据更新，由Kafka监控

·实现

1.确定业务系统源表与贴源数据层目标表

2.配置数据字段映射关系，目标表可能会增加采集日期、分区、原系统标识等信息，业务内容不做转换

3.如果是增量同步或者有条件地同步部分数据，则配置数据同步条件

4.清理目标表对应数据

5.启动同步任务，往贴源数据层目标表导入数据

6.验证任务是否可以正确运行，并且采集到准确数据

7.发布采集任务，加入生产调度，并配置相关限速、容错、质量监控、告警机制

3.2 CDW层

3.2.1数据来源与存储库

3.2.2业务调研与需求分析

在构建CDW层之前，首先进行全面的业务调研。需要请相关的业务人员介绍具体的业务，以便明确各个团队的分析员和运营人员的需求，沉淀出相关文档。可以通过调查表和访谈等形式详细了解以下信息：

1.用户的组织架构和分工界面。

例如，用户可能分为数据分析、运营和维护部门人员，各个部门对数据中台的需求不同，需要对不同部门分别进行调研。

2.用户的整体业务架构，各个业务板块之间的联系和信息流动的流程。需要梳理出整体的业务数据框架。

3.各个已有的业务板块的主要功能及获取的数据。

3.2.3事实表与维度表

在业务调研之后，构建CDW层需要对数据进行建模，采用星型模型设计维度模型，构建事实表和维度表，以订单下单为例，维度表包含用户信息、定价模型、优惠活动等，事实表采用拉链表结构存储订单事实，当订单状态发生变化时，在拉链表中增加一条记录表示该事实。

3.2.4事实表与维度表设计的过程

3.2.5 CDW层实现步骤

1.确定ODS层数据源以及存储库

2.进行业务调研与需求分析，产出业务结构等相关文档

3.根据调研结果，结合维度建模模型，进行CDW层的维度建模，设计事实表与维度表

4.选择某一业务线进行，CDW层事实表与维度表的构建，设计数据模型，确定事实表采用的结构以及维度表应该包含的信息

5.开启同步任务，进行数据定时同步，将ODS层数据定时导入CDW层

3.3 ADS层

3.3.1 指标体系的构建

1.识别核心业务场景

识别各方愿景及核心业务场景、流程。

2.摸清核心数据网络

深入分析业务场景、流程，摸清核心数据网络：

·有什么角色

·在什么系统

·做什么事情

·产生哪些数据

3.探索价值数据体系

从运营管控价值角度出发，将指标进行层级区分，并识别指标业务维度及业务场景

·指标分级：一级、二级、三级

·业务维度：企业经营环节、市场拓展环节（更多的消费端和供给端）、运营增长环节（更好的质量和用户粘性）

·业务场景：指标围绕不同场景细致分析

4.细化各级核心指标

根表指标体系，细化核心指标：

·指标等级

·业务领域

·指标维度

·指标名称

·指标计算公式

·指标目的

·数据来源

5.对齐/下发核心指标数据

征集客户意见，对齐核心指标设计。

6. 开发与持续迭代

根据细化的指标设计可视化界面，并进行指标开发：

·指标可视化设计（分析目的、选择图表、价值维度）

3.3.2 建设步骤

1.调研业务应用对数据内容、使用方式、性能的要求，需要明确业务应用需要哪些数据，数据是怎么交互的，对于请求的响应速度和吞吐量等有什么期望。

2.盘点现有数据是否满足需求；如果有个性化指标需求，统一数仓层数据无法满足，则进行个性化数据加工。

3.组装应用层数据。

四.总结

数据仓库通过对各业务系统数据的聚合，达到集中存储数据，消除数据孤岛，数据治理以及快速响应业务数据需求的目的。

1.数据集中存储

数据仓库的ODS层采用Doris数据库对各业务领域的数据进行存储，Doris架构如下图所示。

如上图，Doris 的整体架构分为两层。多个 FE (前端节点)组成第一层，提供 FE 的横向扩展和高可用，负责接收和返回客户端请求、元数据以及集群管理、查询计划生成等工作。多个 BE(后端节点) 组成第二层，负责数据存储与管理、查询计划执行等工作。

2.快速响应业务数据需求

数据仓库可以快速提供业务需求所需数据，支持业务需求，优势：

1）不同业务线的数据可以高效共享，打破业务线之间的组织壁垒

2）数据需求方无需了解原始数据的模型关系，业务含义，降低数据使用成本

3）通过授予权限的方式，限制对数据的访问，提高数据使用安全性。