从0-1建设数据仓库

基于onedata，纯个人理解，不完善的会慢慢补充

整体流程

1. 业务调研
2. 数据调研
3. 划分数据域
4. 构建总线矩阵
5. 数仓模型设计
6. 数仓模型开发
7. 数仓模型质量保障以及运维

一、业务调研

业务调研有几个内容要做： 确定目标和范围、收集业务需求、梳理业务流程和数据流向、输出物

1.1 确定目标和范围

• 明确业务目标：为什么建设数仓？数仓要解决什么问题？要实现哪些业务目标？例如提升数据分析能力、提高经营效率、支持精准营销、预测风险等。

• 确定数仓范围：数仓要包含哪些业务领域？哪些数据需要纳入数仓？需要支持哪些业务场景？例如包含客户、产品、交易、营销、风险等领域，支持报表分析、用户画像、精准营销等场景。

1.2 收集业务需求

• 访谈业务人员:与业务部门负责人、关键用户进行访谈，了解业务流程、数据需求、痛点和期望。
• 分析现有报表: 收集现有业务报表、数据分析需求，了解业务指标体系和数据分析习惯。
• 研究行业趋势:了解行业发展趋势、竞争对手情况，为数仓建设提供参考。

1.3 梳理业务流程和数据流向

• 绘制业务流程图:将业务流程和数据流向清晰地展现出来，了解数据来源、数据处理过程、数据去向等。

• 识别关键数据:找出哪些数据是业务的关键指标，哪些数据是支持分析的关键要素，并记录其来源、定义、计算方式等。

1.4 输出物

• 业务需求文档:详细记录业务目标、业务需求、业务流程、数据流向等信息，作为数仓建设的依据。

• 数据需求清单: 列出需要纳入数仓的各个数据源，包括数据源名称、类型、格式、位置、字段定义、数据质量等信息。

• 业务流程图: 清晰地展示业务流程和数据流向，便于理解数据关系和数据依赖。

二、数据调研

数据调研分为几个阶段：调研目的、调研内容、调研对象、调研输出物

2.1 调研目的

• 全面了解业务系统架构：掌握公司业务系统的技术架构、部署方式、功能模块以及系统间交互等情况，为数据仓库的设计和集成提供依据。
• 明确数据来源与流向：确定业务系统中哪些数据可以作为数仓的数据来源，以及数仓处理后的数据如何为业务系统提供支持，确保数据的准确性和完整性。
• 评估技术可行性：与业务系统技术负责人探讨数据仓库建设过程中可能遇到的技术难题，评估技术解决方案的可行性，降低项目风险。
• 协调开发资源与进度：了解业务系统的开发计划和资源分配情况，合理安排数据仓库的开发进度，确保与业务系统的协同发展。

2.2 调研内容

1. 业务系统架构

   • 系统组成：了解业务系统包含哪些子系统，各子系统的功能和作用。
   • 技术栈：掌握业务系统所采用的技术框架、数据库类型、中间件等。
   • 部署方式：明确业务系统的部署环境，包括服务器类型、网络架构等。
   • 系统交互：了解业务系统之间以及与外部系统的数据交互方式和接口规范。

2. 数据现状

   • 数据存储：了解业务系统中数据的存储方式，包括数据库表结构、文件格式等。
   • 数据质量：评估业务系统中数据的准确性、完整性、一致性和时效性。
   • 数据更新机制：掌握业务系统中数据的更新频率和方式。

3. 技术挑战与解决方案

   • 数据集成难题：探讨如何将业务系统中的数据高效地集成到数据仓库中。
   • 数据处理性能：分析数据仓库在处理大规模数据时可能面临的性能问题及解决方案。
   • 数据安全与隐私：讨论数据仓库建设过程中的数据安全和隐私保护措施。

2.3 调研对象

• 业务系统架构师：了解业务系统的整体架构设计和技术选型。
• 数据库管理员：掌握业务系统数据库的结构和性能情况。
• 开发负责人：熟悉业务系统的开发流程和技术实现。
• 运维负责人：了解业务系统的部署和运维情况。

2.4 调研输出物

• 数据字典：记录业务系统中的数据表结构、字段含义、数据类型等信息，为数据仓库的数据采集和清洗提供参考。

• 调研报告：详细记录调研过程中了解到的业务系统架构、数据现状、需求和技术挑战等内容，并提出相应的解决方案和建议。

• 数据集成方案：明确数据从业务系统到数据仓库的集成方式、数据清洗规则和数据转换流程。

• 技术选型建议：根据调研结果，提出数据仓库建设过程中的技术选型建议，包括数据库、ETL 工具、数据分析工具等。

• 业务系统数据变更通知机制方案：设计一种机制，当业务系统中的数据发生重大变更时，能够及时通知数据仓库开发团队，以便对数据仓库的相关处理流程和数据模型进行调整和优化，确保数据仓库中的数据始终与业务系统保持一致。

• 技术风险评估报告：对调研过程中发现的技术风险进行详细评估，包括技术架构的稳定性风险、数据集成的复杂性风险、数据处理性能的瓶颈风险等，并提出相应的风险应对措施和应急预案。

• 数据接口规范文档：明确数据仓库与业务系统之间的数据交互接口，包括接口的调用方式、参数格式、数据格式、返回值等，为后续的数据集成和数据交互提供标准化的规范。

三、划分数据域

数据仓库是面向主题的应用。数据仓库模型设计除横向的分层外，通常也需要根据业务情况纵向划分数据域。数据域是联系较为紧密的数据主题的集合，是业务对象高度概括的概念，目的是便于管理和应用数据。

数据域的构建是一个充满艺术的设计过程。但是数据域的划分没有完美的状态，只有不断接近于完美，在实践过程中以螺旋递进的方式进行优化，而这个依赖于数据产品经理不断地思考和实践。

3.1 划分数据域的作用

1. 提高数据管理效率

   • 明确数据归属：将数据按照不同的业务主题划分到特定的数据域中，使得数据的归属更加清晰。你可以快速确定某个数据项应该存储在哪个数据域中，避免数据混乱和重复存储。
   • 便于数据维护：每个数据域都有明确的业务含义和数据范围，这使得数据维护工作更加有针对性。当需要对数据进行更新、修正或清理时，你可以准确地找到相关数据所在的数据域，提高维护效率。

2. 支持业务分析

   • 聚焦业务主题：数据域的划分是基于业务主题进行的，这使得数据分析人员能够更加聚焦于特定的业务领域。你可以针对某个数据域进行深入分析，了解该业务领域的具体情况，为业务决策提供更有价值的支持。
   • 促进跨域分析：虽然数据被划分到不同的数据域中，但数据域之间并不是完全孤立的。通过合理的设计，你可以在不同数据域之间建立关联，进行跨域分析。这有助于发现不同业务领域之间的联系和影响，为企业的综合决策提供更全面的视角。

3. 方便数仓扩展和维护:

   • 灵活扩展：随着企业业务的发展和变化，数据需求也会不断发生变化。通过划分数据域，可以更加灵活地应对这些变化。当新的业务需求出现时，你可以在现有数据域的基础上进行扩展或创建新的数据域，而不会对整个数据仓库的架构造成重大影响。
   • 支持业务重组：如果企业进行业务重组或调整，数据域的划分可以为数据的重新组织和整合提供依据。你可以根据新的业务架构重新调整数据域的划分，确保数据能够更好地支持新的业务模式。

4. 方提升团队协作效率

   • 分工明确：数据域的划分可以使数据仓库开发团队的分工更加明确。不同的团队成员可以专注于特定的数据域，深入了解该数据域的业务需求和数据特点，提高开发效率和质量。
   • 沟通顺畅：由于每个数据域都有明确的业务主题和范围，团队成员之间的沟通也会更加顺畅。你可以更加准确地表达自己的需求和问题，避免因业务理解不一致而导致的沟通障碍。同时，在跨团队协作时，也可以通过数据域的划分更好地协调各方的工作，提高协作效率。

3.2 划分数据域的原则

1. 业务相关性原则

   • 以业务为导向：数据域的划分应该紧密围绕企业的业务需求和业务流程进行。需要深入了解企业的各个业务板块、业务流程和业务活动，将具有相似业务含义和业务用途的数据划分到同一个数据域中。
   • 体现业务逻辑：数据域的划分应该能够清晰地反映企业的业务逻辑和业务架构。每个数据域应该对应企业中的一个或多个业务领域。

2. 数据独立性原则（高内聚低耦合）

   • 数据高内聚：每个数据域中的数据应该具有较高的内聚性，即数据之间的关联度较高，共同服务于特定的业务需求。你应该避免将不相关的数据划分到同一个数据域中，以免造成数据混乱和管理困难。
   • 数据低耦合：不同数据域之间的数据应该具有较低的耦合度，即数据域之间的依赖关系较小。这样可以提高数据的独立性和可维护性，当一个数据域中的数据发生变化时，不会对其他数据域产生过大的影响。

3. 可扩展性原则

   • 适应业务变化：数据域的划分应该具有一定的灵活性和可扩展性，能够适应企业业务的发展和变化。你需要考虑到未来可能出现的新业务需求和业务场景，预留一定的扩展空间，以便在需要时能够方便地添加新的数据域或调整现有数据域的范围。
   • 便于数据集成：随着企业信息化建设的不断推进，可能会有新的数据源不断加入到数据仓库中。数据域的划分应该便于新数据源的集成，能够将新数据源中的数据合理地划分到现有的数据域中，或者根据需要创建新的数据域。

4. 稳定性原则

   • 避免频繁调整：数据域的划分一旦确定，应该尽量保持稳定，避免频繁调整。频繁调整数据域的划分会给数据仓库的建设和维护带来很大的困难，影响数据的一致性和可用性。你需要在划分数据域时进行充分的调研和分析，确保划分结果的合理性和稳定性。
   • 保证数据质量：数据域的稳定性对于保证数据质量也非常重要。如果数据域的划分经常变化，会导致数据的来源和处理方式不稳定，从而影响数据的准确性和完整性。因此，在划分数据域时，应该考虑到数据质量的要求，确保数据域的划分能够为数据质量的提升提供支持。

5. 易用性原则

   • 方便用户理解：数据域的划分应该易于用户理解和使用。你需要为每个数据域取一个简洁明了的名称，并对数据域的业务含义和数据范围进行清晰的描述，以便用户能够快速了解数据域的内容和用途。
   • 支持数据分析：数据域的划分应该能够方便地支持数据分析和数据挖掘等工作。你需要考虑到数据分析人员的需求，将相关的数据划分到同一个数据域中，以便他们能够更加方便地进行数据分析和数据探索。

3.3 划分数据域的方法

主要按照业务过程抽象划分：将企业的业务流程进行抽象化，提炼出核心业务活动和关键数据，将与特定业务活动相关的各种数据整合到一个数据域中。例如，信贷流程可以抽象出用户域、产品域、授信域、交易域、风控域等数据域。

当然也有别的方法：

• 按照业务系统划分：这种方法基于企业已有的信息化系统，每个系统对应一个数据域。例如，财务系统对应财务域，风控系统对应风控数据域，客户系统对应客户域，进件系统对应交易域。这种方法简单易行，能够充分利用现有的信息化基础。
• 按照业务分析主题划分：根据业务主题将数据划分为不同的数据域。每个数据域对应一个业务主题，包含该主题相关的所有数据。例如，可以划分出客户数据域、产品数据域、销售数据域、财务数据域等。
• 按照部门划分： 根据企业不同的业务部门进行划分。例如，财务管理部门对应财务域，风控部门对应风控域等。这种方法简单易懂，能够反映企业的组织结构。

四、构建总线矩阵

总线矩阵起到一个承上启下的作用，有点像地基，之前的都是建筑图纸，后续的设计开发都在这个地基之上。

4.1 总线矩阵的定义

总线矩阵（Bus Matrix）‌是一种用于‌数据仓库构建的理念，它由行和列组成，其中行代表数据仓库中的不同业务过程，列代表不同的维度。通过将不同的业务过程和维度组合在一起，可以构建出一个完整的数据仓库。

总线矩阵的组成包括：

-‌ 行‌：代表数据仓库中的不同业务过程。

‌- 列‌：代表数据仓库中的不同维度。

总线矩阵包含业务过程、公共一致性维度。每行代表一个业务过程，每列表示一个公共维度，还包括业务过程与维度间的联系，图中每个叉号表示该业务过程与维度具有关联关系，也就是我们通常说的外键。

4.2 总线矩阵的作用

构建业务总线矩阵是一个重要的数据仓库设计环节，它能够帮助企业更好地理解和管理数据，为后续的数据建模、ETL 开发和数据应用提供有力支持。

业务总线矩阵的作用主要体现在以下几个方面：

1. 明确数据关系

   • 梳理业务过程与维度：总线矩阵清晰地展示了企业各个业务过程以及与之相关的维度信息。你可以直观地了解到不同业务活动所涉及的数据内容和数据结构，从而更好地把握企业数据的全貌。
   • 建立数据关联：通过总线矩阵，能够明确各个业务过程之间以及业务过程与维度之间的关系。这有助于你在数据仓库的设计和建设过程中，合理地组织数据，确保数据的一致性和完整性。

2. 指导数据仓库设计

   • 确定数据模型：总线矩阵为数据仓库的数据模型设计提供了重要的指导。你可以根据矩阵中的业务过程和维度信息，设计出符合企业业务需求的星型或雪花型数据模型，提高数据的查询效率和分析能力。
   • 规划数据存储：基于总线矩阵，你可以合理规划数据在数据仓库中的存储方式。例如，对于频繁使用的业务过程和维度数据，可以采用优化的存储结构，以提高数据的访问速度。
   • 优化数据模型设计: 业务总线矩阵可以帮助企业更好地理解数据之间的关联关系，为后续的数据模型设计提供指导。例如，根据矩阵中的关联关系，可以设计出更加合理的数据模型，减少数据冗余和数据孤岛。

3. 支持数据分析与决策

   • 提供分析维度：总线矩阵中的维度信息为数据分析提供了丰富的角度。你可以从不同的维度对业务数据进行分析，深入了解企业的运营状况和业务趋势，为企业的决策提供有力支持。
   • 促进跨业务分析：通过总线矩阵，你可以发现不同业务过程之间的潜在联系，进行跨业务的数据分析。这有助于企业发现新的业务机会和风险，优化业务流程，提高企业的竞争力。
   • 促进数据共享: 业务总线矩阵可以帮助企业更好地理解数据之间的关系，促进数据共享和复用，避免重复建设和数据孤岛的产生。

4.3 如何构建总线矩阵

业务总线矩阵中包含维度模型所需的所有事实（业务过程）以及维度，以及各业务过程与各维度的关系。矩阵的行是一个个业务过程，矩阵的列是一个个的维度，行列的交点表示业务过程与维度的关系。

• 首先进行横向部分，即数据域划分与业务过程确立。数据域是对数据的抽象，将联系紧密的数据归为同一类数据域，便于数据的寻找和使用。例如在智能制造工厂中，可将数仓划分为生产、财务、人力、供应链、交付等域，每个数据下包含不同业务过程，如生产数据域下有生产计划、实际生产、设备停机等业务过程。通常先确定业务过程，再按规则将相关业务划分为同一数据域，常用规则有按业务相关性、按需求主题、按应用系统划分等。（也可划分为多级数据域，如先按部门划分一级数据域，再按业务划分二级数据域）。数据域划分无绝对对错，应根据实际情况进行，使数据归纳更清晰、易查找易用。划分数据域时可参考以下规则：数量不宜过多，建议不超过 10 个；不同数据域间无重叠业务过程；具有一定前瞻性，既能涵盖当前业务需求，又能在新业务进入时无影响地被纳入已有数据域或扩展新数据域。

• 其次完成纵向列，包括公共一致性维度的划分以及度量值的确定。维度是看世界的角度，度量形容指标水平，二者都是指标的重要组成部分。例如"四月交付 2000 辆车"，"四月"和"车"是维度，"2000"是度量值，"辆"是度量单位，维度和度量组合形成月度指标。若无维度，"交付 2000 辆"则无意义。维度划分具有行业共同性，如电商行业通常涉及买家、卖家、订单、广告、货运、支付等维度，智能工厂中有设备、产线、项目、物料、车型等维度，还有跨行业通用维度如城市、日期等。维度的一致性是数据一致性的关键，总线矩阵是一致性维度建设的重要文件，从讨论总线矩阵起，数仓数据一致性问题就解决了一半。总线矩阵中的度量通常是原子指标，即业务过程中最基本的原子指标，如生产计划业务过程中度量为"件数"，设备停机事件中度量为"停机时长"。总线矩阵中描述的度量能让分析人员直观了解目前数据具备的分析能力。

  最后确定业务过程同维度间的关联关系。应分析每个业务过程，尽可能多地关联维度与业务过程，而非仅考虑当前分析所需维度，以免陷入面向需求开发的陷阱。

• 业务矩阵编写完成后，应组织业务方、分析人员、架构师、产品经理等多方参与评审，以确定业务矩阵的最终版本。

五、模型设计阶段

模型设计主要包括三个小阶段：概念模型阶段、逻辑模型阶段、物理模型阶段

5.1 概念模型阶段

业务理解阶段为我们在业务理解、数仓未来的业务形态以及建设方向上做了一个铺垫。而当前这个阶段，更偏向于对业务源数据结构的理解，同时会带有一定的业务发展预期。

1. 首先，需要根据对源数据的数据字典解读业务结构。
2. 其次，根据业务形态抽象必要的数据分类。
3. 最后，结合对业务发展的预期，补充相应的数据分类。

至此，整理出来的数据分类就是我们对应的数据仓库概念模型。

个人理解：结合源数据，对业务过程进行梳理，主要是梳理出整个业务过程以及业务过程中的各个实体。

本阶段的产出应该包括：关键业务概念和实体、关键业务流程图。

5.2 逻辑建模阶段

个人理解，对梳理出的概念模型进行属性的补充，发现实体之间的关系。

逻辑设计过程中，需要定义特定数据的具体内容，数据之间的关系，支持数据仓库的系统环境等，本质是发现实体对象属性和实体对象之间的关系。

概念模型为我们稍微具体的逻辑模型圈定了各自的业务边界。包括各个主题域的业务边界、子主题域的业务边界、数据分层的业务边界。

这个阶段，我们需要根据真实可获取的数据进行数据角度的业务抽象。具体如何抽象会受到事实业务理解程度的影响，模型设计人的实际经验的影响等。

一般常用的抽象方法依据：

中间层尽量剥离来源业务系统的业务性，单纯的根据数据本身的数据特征以及更高层次的业务抽象逻辑来设计。

集市层则可以根据具体的业务需求进行更业务化的表结构设计。

同时本阶段，我们需要掌握的是维度建模的方法，包括星型模型、雪花模型的设计思路，缓慢变化维、急剧变化维的处理方法，同时也要能够考虑到如何满足后续业务上的多维度统计，包括上卷、下钻、切片、合并等操作。

本阶段的产出应该包括：ER图(不必须)、每个主题域的表结构设计，每个表的业务关联。

5.3 物理建模阶段

有了逻辑模型阶段，数仓建设, 我们更多关注以下工作内容实现，包含贴源层的字段mapping，中间层的数据清洗和标准化，集市层的数据加工，ETL任务调度频次的定义，ETL任务运维和管理、数据质量配置和任务监控等等。

最终的物理模型的落地，代表了数仓项目的阶段性交付。

构建数据仓库的核心是建模，在数据仓库的构建中，ETL贯穿于项目始终，它是整个数据仓库的生命线。从数据源中抽取数据，然后数仓重对这些数据进行转化，最终加载到目标数据库或者数据仓库中去，这也就是我们通常所说的 ETL 过程(Extract,Transform,Load)。

一个经典的分层数仓架构（如 ODS -> DWD/DIM -> DWS->ADS）中，ETL 是贯穿各层级之中：

1. 数据源层：‌ 各种源头系统。‌

2. 贴源层 / 操作数据存储：‌ 通常在这里进行首次 ‌E‌（提取），将源数据近乎原样地抽取进来，作为后续加工的"原材料基地"。

   ‌明细数据层 / 统一明细层：‌ 核心的 ‌T‌（转换）发生地之一：

   • 清洗脏数据。
   • 合并来自不同源的关联数据（如订单关联用户信息）。
   • 进行初步的业务解码（如将状态码翻译成状态描述）。
   • 标准化格式（如统一日期格式、单位）。
   • 建立一致性维度。
   • 生成代理键。
   • 打上时间戳（拉链表的起点）。
   • 最后 ‌L‌（加载）到明细层模型（如星型/雪花模型的事实表、维度表）。

3. 汇总数据层 / 主题宽表层：‌ 再次进行 ‌T‌（转换）：

   • 基于明细数据进行‌聚合计算‌（如按天、按地区、按品类汇总销售额、订单数）。
   • 构建宽表（将常用关联维度退化到事实表中）。
   • 进行更复杂的业务指标计算（如客户留存率、复购率）。
   • 最后 ‌L‌（加载）到汇总层表或Cube中。‌

4. 数据集市 / ADS层：‌ 面向特定部门或应用：

   • 可能从汇总层或明细层 ‌E‌（提取）必要数据。
   • 针对特定场景进行轻量级 ‌T‌（转换）（如过滤、简单计算、格式化）。
   • L‌（加载）到数据集市或API层，供BI工具、报表系统、AI应用直接消费。

5. 元数据管理：‌ 贯穿整个ETL过程，记录数据源的Schema、ETL任务的定义（转换规则、依赖关系、调度计划）、数据血缘关系、数据质量检查结果等。

6. 调度与监控：‌ 负责按计划（定时、事件触发）启动ETL作业，监控作业运行状态（成功/失败/耗时）、资源消耗（CPU、内存、I/O）、数据产出时效性、数据质量告警等。

六、数仓模型开发

接下来就是进入数据开发阶段了，此阶段要做的内容

• 冒烟测试‌：发布前做好各类数据验证，通过冒烟各类规则来验证数据是否符合预期, 包括验证任务运行时长是否满足要求。
• 监控配置‌：
  • 资源保障：通过配置任务基线来保障任务所需的计算资源,保障产出时间。
  • 任务监控：
    • 配置产出监控,比如9:00产出, 如果9:00没有产出, 就要发出邮件告警信息;
    • 配置任务失败监控,比如3:00任务失败, 就要电话通知到值班人处理;

七、数仓模型质量保障以及运维

数据质量是数据分析结论有效性和准确性的基础,也是这一切的前提。如何保障数据质量，确保数据可用性是数据仓库建设不容忽视的环节。接下来将通过数据质量原则逐一展开介绍数据质量建设的方法。

如何评估数据质量的好坏，业界有不同的标准，对数据仓库主要从四个方面进行评估，即完整性、准确性、一致性和及时性。并且通过DQC数据质量监控工具来保障数据质量

7.1 完整性

完整性是指数据的记录和信息是否完整，是否存在缺失的情况。数据的缺失主要包括记录的缺失和记录中某个字段信息的缺失，两者都会造成统计结果不准确，所以说完整性是数据质量最基础的保障。比如交易中每天支付订单数都在100万笔左右,如果某天支付订单数突然下降到1万笔，那么很可能就是记录缺失了。对于记录中某个字段信息的缺失，比如订单的商品ID、卖家ID都是必然存在的，这些字段的空值个数肯定是0，一旦大于0就必然违背了完整性约束。

7.2 准确性

准确性是指数据中记录的信息和数据是否准确，是否存在异常或者错误的信息。比如一笔订单如果出现确认收货金额为负值，或者下单时间在公司成立之前,或者订单没有买家信息等,这些必然都是有问题的。如何确保记录的准确性，也是保障数据质量必不可少的一个原则。

7.3 一致性

一致性一般体现在跨度很大的数据仓库体系中，比如阿里巴巴数据仓库，内部有很多业务数据仓库分支，对于同一份数据，必须保证一致性。例如用户ID，从在线业务库加工到数据仓库，再到各个消费节点，必须都是同一种类型，长度也需要保持一致。所以，在建设阿里巴巴数据仓库时，才有了公共层的加工，以确保数据的一致性。

7.4 及时性

在确保数据的完整性、准确性和一致性后，接下来就要保障数据能够及时产出，这样才能体现数据的价值。一般决策支持分析师都希望当天就能够看到前一天的数据，而不是等三五天才能看到某一个数据分析结果;否则就已经失去了数据及时性的价值，分析工作变得毫无意义。现在对时间要求更高了，越来越多的应用都希望数据是小时级别或者实时级别的。比如阿里巴巴"双11"的交易大屏数据，就做到了秒级，及时性同样是保障数据质量的一个重要原则。