数仓项目实施方案v0.1

数仓项目实施方案v0.1

编号	编写人	更新时间
1	leo	2025年4月10日

说明

该文档对数仓项目的实施流程和对应的里程碑结点和关键的交付物进行了简单的说明，也简单阐述了关于以业务驱动式的维度建模方法在数仓项目中的应用，旨在帮助初学者快速了解数仓架构以及项目流程，快速构建项目的实施体系。

文档面向人员

该文档适用用于初次了解数据仓库人员、数仓项目的项目经理、kimball式（维度建模式）的数仓项目人员

项目实施流程图

该项目实施流程总体由需求整理、模型设计和模型开发三个部分组成，从项目接入作为起始点、交付\运维作为结束点，构建出相对闭环的实施流程。

flowchart LR 项目接入 --> 需求整理 subgraph 需求整理 [需求整理] 行业信息 --> 当前数据建设现状 --> 部门架构及业务过程 --> 上下层的诉求与期望 --> 相关BI报表信息 上下层的诉求与期望 --> 相关PDM和ER图信息 end 需求整理 --> 模型设计* subgraph 模型设计* [模型设计*] 数据域与业务过程划分 --> 总线矩阵设计 --> 规范定义设计 --> 维度事实模型设计 --> 交付/确认模型蓝图 --再设计--> 总线矩阵设计 end 模型设计* --> 模型开发 subgraph 模型开发 [模型开发] 数仓架构方案选择 -->数仓模型设计 --> 数据同步方案 --> 数据清洗治理方案 --> 维度事实表开发 --> 数据市场开发 --> 确认/交付数据 --再开发--> 数仓模型设计 end 模型开发 --上线--> 项目运维/交付--运维-->模型开发

在该流程中，在需求整理环节，首先需明确该项目是否为一个数仓项目，确认之后，需要尽可能的与客户沟通分析场景而不是技术层面的事物，为模型设计环节提供充足的信息支持，以保证数据建模的准确性以及符合客户在当前业务场景下对数据分析的要求。在最关键的模型设计环节，应当基于kimball式（维度建模）的建模方法来进行建模，而模型设计的维度也应该满足对应部门的分析需求。该模型设计的环节产生的经过客户确认的成果物也应当转化为下一环节物理模型设计的依据。在模型开发环节，应该根据具体的需求来选择对应的数仓处理工具，并设计对应的数据层次，依据模型设计的蓝图来创建物理表，依据规范设计来生成对应的数据市场的数据。

项目实施里程碑结点与成果物

在项目数仓项目实施过程中，会有多个较为关键的结点，而对应每个结点也会产生若干个成果物，以作证该结点的完成。在该项目实施流程中，会达成的里程碑结点和对应成果物如下图所示：

timeline title 里程碑结点与成果物 需求整理 : 需求整理文档 业务及数据域划分: 业务与数据域划分示意图 : 业务过程链示意图 数仓架构方案设计 : 数仓架构说明文档 总线矩阵设计 : 总线矩阵设计图（系列） 规范定义设计 : 规定定义设计图（系列） 维度事实模型设计 : 维度表、事实表清单 : 关系模型图 数据清理与治理 : 数据治理规则文档 数据开发 : 实体与维度表清单 : 数据市场汇总表清单 项目交付 : 确认交付清单

需求整理文档：该文档是对需求整理环节各个部分的整理归纳，在该文档中应当写明客户所处的行业、公司部门架构以及对应的业务关系、各部门所要接入的数据库软件、客户对数据的分析方法、对现有BI报表和PDM文档的信息归纳。

业务及数据域划分：业务划分和数据域划分是对客户当前数据的逻辑划分，如果客户当前存在数据域或数据主题，可在一定程度上直接进行借鉴。一般来说，数据域大可依照部门来划分，而这样也可直接进一步将业务过程或业务过程对应的业务链划分至数据域。若数据域划分较为复杂，业务过程也需谨慎处理。在此结点，确立了业务过程，也就完成了KIMBALL式维度建模的第一个步骤（共四个步骤）。

数仓架构方案设计：数仓架构设计是物理建模的核心前提。但是在大多场景下可以直接套用其他厂商的方案，尤其是技术架构，将该部分交给非研发人员处理，显得较为残忍。但是对于模型架构，类似于数据域设计、数仓分层等内容，实施人员掌握较多的主动性，可根据实际情况进行微调。

总线矩阵、规范定义、维度事实设计：该部分内容为维度建模的规范步骤，同时揉杂了阿里巴巴的建模方法。该部分的具体方法应当参照 《阿里巴巴大数据之路》 和 《Data Warehouse Toolkit》(数据仓库工具箱)内关于维度建模的章节进行参考，完成该步骤之后，便完成了模型设计的步骤。

数据清理与治理：该结点的内容为对接入到数仓的数据进行处理的部分，通常为空值检查、枚举类型检查、值域检查等对字段值的校验处理，也有对数据特殊符号导致的数据错误的ETL处理。该结点的内容应当整理成文档进行归纳，或依据已有信息对当前数据进行校验和标记。

数据开发：该部分是对物理模型的操作结点，具体内容为ETL开发、维度表与事实表开发、宽表开发、汇总表开发等。而此环节的开发逻辑依据来自于在模型设计环节的维度与事实设计，因此维度设计环节的准确与否将直接影响数据开发的进度与效率。

数仓设计

数仓技术架构图（CDH为例）

CDH是基于Hadoop分布式架构的一套开源的发行版本，现在称为"PDH"且商用闭源。其中，HDFS作为数据的存储系统，对应的数据库为HIVE数据库，支持PB级别的数据批处理，非常适合离线作业处理,而spark也为数据查询处理提高了效率。在实时同步等操作中，有kafka、flinksql等软件提供支持。Yarn则负责hadoop分布式集群的任务调度与分配。
在通常情况下，也会集成atlas等元数据管理相关系统，用于对数据的上下游血缘分析以及业务信息管理提供支持。

数仓模型架构图

数据仓库模型架构，是数据开发的前提。一般情况下，数仓模型要确认数据来源、要有分层式的模型设计，大致为ODS、DWD、DWS、ADS等层次，要确认数据的消费方向。下图为数据仓库模型示意图：

在数仓中，接入的数据的类型和方式多种多样，通常会在中间添加一个数据中台的系统用于将各种数据接入到数仓。根据数据及时性的不同，可以分为实时同步和离线同步两种。在离线同步中，如何去做增量同步也是一个需要考虑的问题，解决方案可依据《阿里巴巴大数据之路》关于数据增量同步章节。而在CDM层中包含了DWD\DWS两个数据层次，以及表现了相对应的一些业务细节。

维度建模

业务过程链图

维度建模的四步中，确定业务过程是其中第一步。而业务过程的确认依据，来自需求确认结点和部门业务人员探讨的结论。下图为零售商业务部分价值链图：

--- titile: 零售商业务价值链子集 --- flowchart LR 向制造商发出购买订单-->接收仓库到货-->仓库库存产品-->接收商店存货-->商店存货产品-->零售

通过绘制价值链图，串联不同业务结点之间的，并发现其中的联系，并根据价值链图来确认业务过程。同时也可为事实表在设计累计快照事实表时提供思路。

规范定义示意图

下图为规范定义示意图，该图出自于阿里巴巴的数仓实施方案当中，其目的是以维度建模为基础，构建数仓总线矩阵、划分数据域、建立派生指标提供帮助。

总线矩阵图示意图

该图为数仓总线矩阵图，总线矩阵图为数仓项目 重要交付物 之一，也是在做模型设计时，首要需要完成的设计。该图在一定层面上，也非常直观呈现分析维度与各业务过程之间的关系，为了设计维度事实模型提供了较直观的逻辑参考。

在此基础上，可以对总线矩阵添加一些细节，并新增列来呈现，如每个业务过程的颗粒度，涉及到事实有哪些。若业务过程还需要细分，可以在业务过程下添加子行来进行呈现细节。
除此之外，可以将公共维度替换成相应的部门，构建出利益总线矩阵，来直观的呈现出部门之间与涉及到的业务过程相关利益。

维度事实模型示意图

在总线矩阵设计以及规范定义之后，再去设计维度表和事实表应该会减少很多在逻辑架构上的思考难度。但在该环节，也有需要事情需要考虑，如对于维度不一致如何去解决、桥接表的应用、太多维度导致的蜈蚣表、事实表与维度表的退化、非常用字段的处理，上述事情都是在维度建模的时候需要仔细考虑的细节问题。下图为维度事实模型示意图：

在和客户确认维度事实表且满足客户所需的数据分析要求和分析角度之后，就可以交付给实施人员进行开发作业。而开发人员，可直接依据维度事实表来进行ETL作业，以及SQL的逻辑处理。