数据仓库建设指导说明

1、概念

数据仓库：是一种数据管理系统，旨在为整个组织的商务智能和分析提供支持。数据仓库通常包含大量数据，包括历史数据。数据仓库中的数据一般来自应用日志文件和事务应用等广泛来源。数据仓库存储结构化数据，其用途通常已明确定义。

数据湖：让组织存储大量结构化和非结构化数据（例如，来自社交媒体或点击流数据），并立即使其可用于实时分析、数据科学和机器学习用例。借助数据湖，无需进行更改，数据以原始形式摄取。

数据湖和数据仓库之间的主要区别在于，前者在没有预定义结构的情况下存储大量原始数据。组织不需要提前知道数据的用途。

数据集市：是一种简单的数据仓库形式，侧重于单个主题或业务线，例如销售、财务或营销。由于用途单一，数据集市从比数据仓库更少的来源中获取数据。 数据集市源可以包括内部操作系统、中央数据仓库和外部数据。数据集市源可以包括内部操作系统、中央数据仓库和外部数据。

脑图地址：https://www.processon.com/v/6498ed2d42fb7c0083371120

2、数仓特点

特点： 面向主题、继承性、稳定性
意义： 建议公司统一数据中心，为数据BP、运营人员提供数据支持，为领导提供决策支持

与传统数据库对比

3、数仓建模架构

3.1、数据集市

    早期数据集市也不是之前单独按照每个部门去搭建的，容易出现数据不一致的情况，且无法水平对比。从属数据集市基于搭建好的企业级数据仓库，可以有效消除各部门数据不一致的情况。

3.2、Inmon 架构（范式建模）

    Inmon架构，也称为Bill Inmon架构，是一种用于构建企业数据仓库（Enterprise Data Warehouse，简称EDW）的数据架构和方法论。它由Bill Inmon在20世纪80年代提出，并被广泛应用于数据仓库的设计和实施。

    Inmon架构的核心思想是将企业数据仓库视为一个集成的、一致的数据存储，用于支持企业级的数据分析和决策。它强调以主题为导向的数据建模，将数据组织成以业务主题为中心的维度模型（Dimensional Model），如星型模型（Star Schema）或雪花模型（Snowflake Schema）

    Inmon 架构的核心思想是以企业范围的一致性为基础，将数据仓库建设为一个集中式的、集成的数据存储和分析平台。以下是 Inmon 架构的一些关键特点：

• Inmon架构的数据仓库存储的是最细粒度的数据
• Inmon架构的数据仓库是符合三范式的
• Inmon架构的数据只能从数据集市获取，不能跨过数据集市直接从企业级数据仓库中获取。

3.3、Kimball 架构（维度建模）

    Kimball架构，也称为Ralph Kimball架构，是一种用于构建企业数据仓库（Enterprise Data Warehouse，简称EDW）的数据架构和方法论。它由Ralph Kimball在20世纪90年代提出，并被广泛应用于数据仓库的设计和实施。

    Kimball架构的核心思想是以业务过程为中心构建数据仓库，强调以维度建模为基础，通过维度模型（Dimensional Model）来组织数据。维度模型由事实表（Fact Table）和与之关联的维度表（Dimension Table）组成，通过共享维度表实现数据的集成和共享。

    如上图所示，可以发现 Kimball 架构使用多维模型设计，所以分为事实表和维表，我们在使用数据的时候，可以直接查询数据仓库里面的数据，Kimball 架构的数据仓库是没有实际存在数据集市的，如果非要区分，可以通过主题域划分获取自己的数据集市。

3.3.1、表分区

3.3.1.1、事实表

• 事物事实表
  定义：事务事实表保留的是最原始的数据，所以其实也叫做原子事实表。
  举例：比如下单，政府，发货等这些业务过程构建的一类事实表，由于是最细粒度的数据，所以我们可以根据这些数据做各种各样的数据分析。
  特性：多种方式表达粒度、稀疏（当天发生才会有数据）、事实完全可加、插入、可以每日分区白柳当天数据或全量快照表。

• 周期快照事实表
  定义：周期快照事实表的粒度和事物事实表不太一样，一般以维度属性进行声明，然后结合时间间隔。
  举例：比如历史到现在的订单量，昨天的好评数等，昨天浙江的支付总金额等，时间间隔不是固定不变的，可以是每天、每月、每周、近7天、近15天等。
  特性：维度+周期声明粒度、粘稠（重要特性，当天未发生，但是历史至今发生过，也会记录）、至少一个半可加事实（比如近7天的销售额不能相加，但是可以计算一下平均值）、插入、每日分区保留当天统计的该周期内的数据，之后不再修改，除非口径变动。

• 累计快照事实表
  定义：累计快照事实表，将需要分析的各个行业过程的事实放到一个表中进行分析。
  举例：比如：下单、支付、发货、签收等，我们会把这4个业务的事实放入到事实表中（包括每个过程发生的时间）。
  特性：多种方式表达粒度、事实完全可加、维度退化（数据探查、数据分析）、插入与更新、每天保留全量数据（全量快照表）

3.3.1.2、维度表

3.3.1.2.1、维表设计步骤

选择维度：指的是我们的事实表需要关联哪些维度，比如健身房的私教课事实表，我们可能需要确定教练维度。
确定主维表：选择了教练维度，我们就要确认教练维度的主维表了，这种情况一般是业务库抽过来的教练基本信息表。
确定关联维表：这个也不一定有，有的话就需要关联一下，比如教练的课时安排等。
确定维度属性：这个就比较重要了，涉及到我们最终的维表的属性值，这个不但需要自己进行权衡，也可能需要与业务方，需求方进行沟通，防止近期可预见的属性值缺失，到时候后期再进行迭代。

3.3.1.2.2、维度设计的建议

• 尽可能多给出一些维度属性避免后期频繁迭代。
• 尽量描述性的文字也给出，比如商品id，商品名称等。
• 区分数字类型的属性，如单价
• 沉淀出通用的维度属性，一般指不能直接获取，需要我们后期加工的属性，减少在使用过程中的重复开发或者维度不一致的情况，比如当前是否vip

3.3.1.2.3、主键设计

    在数据库设计中，主键是用于唯一标识表中每个记录的一列或一组列。它在表中具有唯一性和非空性的特征，用于确保数据的唯一性和有效性。主键可以帮助快速查找和关联表中的数据。

• 代理键（Surrogate Key）
  是一种人为创建的人工主键，与业务数据无直接关联。它通常采用自增长的整数或全局唯一标识符（GUID）等形式生成。代理键是通过引入一个新的列来实现，其目的是为了简化数据模型的设计和提高数据操作的效率。
  代理键的优点包括：
  唯一性：代理键保证了每个记录都有一个唯一的标识符，不会出现重复的情况。
  简化设计：使用代理键可以避免在主键中使用多个业务属性组合的复杂性，简化了数据模型的设计。
  效率：代理键通常采用简单的递增或随机生成方式，不依赖于业务数据的特性，能够提高数据插入和查询的效率。

• 自然键（Natural Key）
  是指已经存在于业务数据中的属性或组合，可以作为主键来唯一标识记录。自然键通常与业务实体的属性相关，如身份证号码、商品编号、订单号等。
  自然键的优点包括：
  业务相关性：自然键直接关联于业务实体，能够更直观地表示数据的含义。
  无需额外列：使用自然键作为主键，不需要额外引入代理键列，简化了数据模型的设计。
  数据一致性：自然键的值已经存在于业务数据中，能够确保数据的一致性和有效性。
  然而，自然键也存在一些潜在的问题：
  可变性：某些自然键的值可能会发生变化，如商品名称、手机号码等，这会对数据的引用完整性产生影响。
  复杂性：某些业务实体可能没有明确的自然键，或者自然键的组合可能很复杂，导致数据模型设计复杂化。
  性能问题：使用自然键作为主键可能会导致索引和关联操作的性能下降，特别是当自然键的长度较长时。

    在设计数据库表时，应根据具体业务需求和数据特点选择合适的主键策略，综合考虑代理键和自然键的优缺点，并权衡其对数据模型设计、数据操作效率和数据一致性的影响。

3.3.1.2.4、缓慢变化维 SCD

    缓慢变化维（Slowly Changing Dimension，SCD）是指在数据仓库或数据库中用于管理维度表中数据变化的一种方法。维度表包含描述业务实体的属性，如产品、客户、地理位置等。而 SCD 方法则用于处理这些维度表中数据的变化情况。
    在数据仓库中，维度数据可能会随着时间的推移发生变化。SCD 方法旨在处理这些变化，以便在查询和分析时能够准确地反映出历史数据和当前数据的状态。一般分为以下几种情况：

• 属性值不变
  什么都不用改，就用历史的维度属性值。
  

• 重写维度属性值
  只能反应最新的情况，无法保留维度属性的历史值，对于历史变化，这种方案是无法实现的。
  

• 拉链表
  拉链表（Zipper List）是一种用于实现缓慢变化维度（SCD）的数据结构，常用于数据仓库或数据库中的维度表设计。它的目的是有效地跟踪和记录维度数据的历史变化。拉链表通过在维度表中添加起始日期和结束日期列，以及一个标识当前记录的标志列（如“当前”或“有效”标志），来记录维度数据的有效时间段。每当维度数据发生变化时，会在维度表中添加新的记录，并更新前一个记录的结束日期。
  

• 增加维度行
  当某个维度表中的某个属性发生变化时，为了保留历史变化记录，需要向维度表中添加新的行来表示新的数据状态。
  

• 增加新属性
  这种方法是在维度表中增加新的属性列来表示维度数据的变化。当维度数据的某个属性发生变化时，不添加新的行，而是在维度表中添加一个新的列来存储新的属性值。旧的行和其他属性保持不变。
  

• 全量快照
  什么都不用改，每天保留一份全量快照表，这种方式是最简单最容易理解的，唯一缺点就是存储成本比较高。

3.3.1.2.5、维表的整合与拆分

3.3.1.2.5.1、整合

• 垂直整合
  选择一个主维度表，把其他的相关维度表的属性关联上去，可以丰富主维表的维度属性，方便使用，减少关联
• 水平整合
  把具有相同维度属性的相关表可以整合到一张表中，方便管理

3.3.1.2.5.2、拆分

• 垂直拆分
  定义：由于维度各属性的产出时间、热度、访问频率不一样，也有些维度经常变化，有些基本不会变化，所以在这种情况下，为了维表最优化，我们应该做一些垂直拆分的工作。
  场景再现：
  不常用属性：不常用属性或者访问频率非常低，一年难得访问一次。
  当前是否核心属性：比如爬虫数据，爬虫每天上午 7 点才产出数据，该维表整体产出时间需要到 8 点 30 分，所有核心报表延迟。
  活跃属性：当天是否活跃属性变化频率非常高。

• 水平拆分
  为什么需要水平拆分？可能由于历史原因，把不同产品下的相同维度强制性合并到同一张表里面了额，但是后来发现这张表并不太好用，业务相关性并不大，而且由于某个产品的维度属性经常改变，导致该表需要频繁迭代，稳定性差，直接影响其他业务。

3.3.2、三种模型

3.3.2.1、星型模型

    星型模型是一种常见的数据模型，用于设计和组织数据仓库或业务智能系统中的数据结构。它以中心的事实表（Fact Table）与周围的维度表（Dimension Tables）形成类似星型的结构，因此得名为星型模型。

    在星型模型中，事实表包含了业务过程中发生的事实或事件，例如销售订单、交易记录等，它通常包含数值型的度量或指标。维度表则包含与事实表相关的描述性属性，如时间、地点、产品、客户等。维度表通过主键与事实表进行关联，以提供对事实表数据的解释和分析。。

星型模型的特点包括：

1. 中心事实表：事实表是星型模型的核心，存储了业务过程中的事实或事件，并与维度表进行关联。

2. 维度表：维度表围绕事实表形成星型结构，每个维度表代表一个业务维度，如时间、地点、产品、客户等，提供了对事实数据的上下文和描述。

3. 明确的关系：维度表与事实表之间建立明确的关联关系，通常通过主键-外键的方式实现。

4. 简单性和易理解性：星型模型具有简单、直观的结构，易于理解和使用，适合于各种分析和查询需求。

    星型模型的设计和使用使得数据的分析和查询操作更加方便和高效，使得用户能够以直观的方式理解数据关系和进行多维分析。

    需要注意的是，星型模型在处理复杂的关系和多对多的关联时可能存在一些限制，这时可以考虑使用其他数据模型，如雪花模型或多维模型，来满足更复杂的数据建模需求。

3.3.2.2、雪花模型

    雪花模型（Snowflake Model）是一种用于设计和组织数据仓库或业务智能系统中的数据模型。它是在星型模型的基础上进一步发展而来的。

与星型模型不同，雪花模型通过规范化维度表来消除冗余数据，以达到更高的数据存储效率。在雪花模型中，维度表被分解为更小的规范化表，形成了维度表之间的多级关系，因此得名为雪花模型。

雪花模型的特点包括：

• 规范化维度表：维度表被规范化为多个表，以消除冗余数据。例如，一个维度表可能被分解为主表和多个子表，每个子表包含该维度的一部分属性。

• 多级关系：维度表之间形成多级关系，子表与主表通过主键-外键关系连接。这些关系导致维度表的结构呈现出类似雪花的形状，因此称为雪花模型。

• 更高的存储效率：通过规范化维度表，雪花模型减少了数据的冗余性，节省了存储空间。这对于大规模的数据仓库和复杂的维度结构尤为重要。

    雪花模型的设计使得数据仓库在存储和查询性能上具有一定的优势，特别适用于大型的数据仓库和复杂的维度关系。然而，相对于星型模型，雪花模型的查询复杂度可能会增加，因为需要在多个表之间进行关联查询。

    需要根据具体业务需求和数据关系来选择合适的数据模型，以满足数据存储、查询性能和分析需求。在某些情况下，也可以根据具体情况使用星型模型和雪花模型的组合，以兼顾存储效率和查询性能。

3.3.2.3、星座模型

星座模型是事实表与事实表通过维表相连接的模型，星座模型是对星型模型和雪花模型的综合称呼，用于表示两者的结合。在星座模型中，可以同时存在星型模型和雪花模型的特点。

星型模型（Star Schema）和雪花模型（Snowflake Schema）是用于组织和设计数据仓库的两种常见模型，它们有以下区别：

    选择使用星型模型还是雪花模型取决于具体的业务需求和数据特点。星型模型适用于简单的结构和查询，而雪花模型适用于复杂的维度关系和需要较高存储效率的情况。在实际应用中，可以根据具体情况灵活选择适合的模型。

3.4、Inmon 与 Kimball 架构对比（离线数仓架构）

Inmon 建模有以下特点：

• 也被称作范式建模，这种建模方式在范式理论上符合 3NF。这里的 3NF 与 OLTP 中的 3NF 还是有点区别的：关系数据库中的 3NF 是针对具体的业务流程的实体对象关系抽象，而数据仓库的 3NF 是站在企业角度面向主题的抽象；
• Inmon 模型从流程上看是自上而下的，自上而下指的是数据的流向，“上”即数据的上游，“下”即数据的下游，即从分散异构的数据源 -> 数据仓库 -> 数据集市；
• 以数据源头为导向，然后一步步探索获取尽量符合预期的数据，因为数据源往往是异构的，所以会更加强调数据的清洗工作，将数据抽取为实体-关系模型，并不强调事实表和维度表的概念；
• 数据集市是针对不同主题的聚集区域。

Kimball 建模有以下特点：

• 也被称为维度建模；
• Kimball 模型从流程上看是自下而上的，即从数据集市-> 数据仓库 -> 分散异构的数据源；
• Kimball 是以最终任务为导向，将数据按照目标拆分出不同的表需求，数据会抽取为事实-维度模型，数据源经 ETL 转化为事实表和维度表导入数据集市，以星型模型或雪花模型等方式构建维度数据仓库;
• 架构体系中，数据集市与数据仓库是紧密结合的，数据集市是数据仓库中一个逻辑上的主题域。

Inmon 与 kimball 建模方式对比：

众所周知，互联网公司的业务一般是周期比较短需求变化快，并且迭代频繁，如果精心设计 Inmon 实体-关系的模式似乎并不能满足快速迭代的业务需要。所以，互联网公司更多场景下趋向于使用 Kimball 维度-事实的设计反而可以更快地完成任务。两种建模方式也可以混合使用，通过 ODS 的数据，利用范式建模方法，建设原子数据的数据仓库 EDW，然后基于 EDW，利用维度建模方法建设数据集市。建模方式没有好与坏之分，只有合适与不合适之分，在实际数仓建设中，需要灵活多变，不能全依赖建模理论，也不能不依赖。适时变通，才能建设一个好的数据仓库。

参考文章；
《通俗易懂数仓建模—Inmon 范式建模与 Kimball 维度建模》

3.5、Lambda 架构

随着大数据应用的发展，人们逐渐对系统的实时性提出了要求，为了计算一些实时指标，就在原来离线数仓的基础上增加了一个实时计算的链路，并对数据源做流式改造（即把数据发送到消息队列），实时计算去订阅消息队列，直接完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。

Lambda 架构（Lambda Architecture）是由 Twitter 工程师南森·马茨（Nathan Marz）提出的大数据处理架构。这一架构的提出基于马茨在 BackType 和 Twitter 上的分布式数据处理系统的经验。

Lambda 架构使开发人员能够构建大规模分布式数据处理系统。它具有很好的灵活性和可扩展性，也对硬件故障和人为失误有很好的容错性。

Lambda 架构总共由三层系统组成：批处理层（Batch Layer），速度处理层（Speed Layer），以及用于响应查询的服务层（Serving Layer）。

在 Lambda 架构中，每层都有自己所肩负的任务：

• 批处理层：使用分布式处理系统预先计算结果，可以处理非常大量的数据。批处理层的目标是通过能够处理所有可用数据来生成视图，从而达到完美的准确性。这意味着它可以通过基于完整数据集重新计算来修复任何错误，然后更新现有的视图。输出通常存储在只读数据库中，更新会完全替换现有的预计算视图。

• 速度处理层：实时地处理数据流，不需要修正或完整性的要求。这一层牺牲了吞吐量，因为它旨在通过提供最新数据的实时视图来最小化延迟。本质上，速度处理层负责填补批处理层在提供基于最新数据的视图时造成的“缺口”。这一层的视图可能不如批处理层最终产生的视图那样准确或完整，但它们在数据接收后几乎立即可用，并且可以在批处理层的视图可用时被替换。

• 服务层：负责响应查询。这一层将批处理层以批视图形式输出的结果和速度处理层以近实时视图形式输出的结果转发给服务层。这一层对批视图进行索引，以便可以在低延迟的情况下进行即席查询。

特点：

• 批流分离：Lambda 架构将数据处理层分为批处理层和速度处理层，分别使用批处理和流处理两种方法来处理大量的数据。这样可以兼顾数据的准确性和实时性，同时降低系统的复杂性和耦合性。
• 容错性和鲁棒性：Lambda 架构依赖于一个不可变的数据源，作为系统的记录。这样可以保证数据的一致性和完整性，以及系统的容错能力。即使出现错误或故障，也可以通过重新计算来修复问题（鲁棒性 robus 译为健壮性、稳健性或强健性）。
• 可扩展性：Lambda架构可以通过增加更多的机器来应对数据量或负载的增长，实现线性的可扩展性。Lambda架构也可以集成各种大数据组件，如Hadoop，Kafka，Storm，Spark，Hbase 等，提供更多的功能和灵活性。
• 通用性：Lambda架构可以适应广泛的应用场景，包括金融、社交、电商、数据分析等领域。Lambda 架构也可以支持各种类型的查询，包括批量查询、实时查询、即席查询等。

3.6、Kappa 架构

Lambda 架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着 Flink 等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn 的 Jay Kreps 提出了 Kappa 架构。

Kappa 架构可以认为是 Lambda 架构的简化版（只要移除 lambda 架构中的批处理部分即可）。在 Kappa 架构中，需求修改或历史数据重新处理都通过上游重放完成。Kappa 架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。

Kappa 架构的重新处理过程：

1. 选择一个具有重放功能的、能够保存历史数据并支持多消费者的消息队列，根据需求设置历史数据保存的时长，比如 Kafka，可以保存全部历史数据；
2. 当某个或某些指标有重新处理的需求时，按照新逻辑写一个新作业，然后从上游消息队列的最开始重新消费，把结果写到一个新的下游表中；
3. 当新作业赶上进度后，应用切换数据源，读取 2 中产生的新结果表；
4. 停止老的作业，删除老的结果表。

完全使用流计算处理所有的数据对开发和数据分析的方方面面都有影响。例如，在 Kappa 架构下，所有的数据以流计算的方式处理之后，都将以一种追加的方式写入目标位置，而之前写入的数据也没有机会再被改动，因而变成不可变的。这种处理模式和 Kafka 对待数据的方式是完全一致的，本质上都是受流计算这种计算模式的影响。Kappa 架构在技术选型上与 Lambda 架构在 Speed Layer 上选型是类似的，都以流计算框架为主。

3.7、Lambda 与 Kappa 架构对比（实时数仓架构）

• 在真实的场景中，很多时候并不是完全规范的 Lambda 架构或 Kappa 架构，可以是两者的混合，比如大部分实时指标使用 Kappa 架构完成计算，少量关键指标（比如金额相关）使用 Lambda 架构用批处理重新计算，增加一次校对过程；
  

• Kappa 架构并不是中间结果完全不落地，现在很多大数据系统都需要支持机器学习（离线训练），所以实时中间结果需要落地对应的存储引擎供机器学习使用，另外有时候还需要对明细数据查询，这种场景也需要把实时明细层写出到对应的引擎中。
  

4、开发流程

4.1、开发大体流程

1. 需求分析调研
   明确口径、评估排期、需求正规流程提交
2. 数据探查
   数据字段是否满足需求：了解数据表字段能不能满足需求方需求，看看字段有没有少，如果发现少了或者体用的数据源没办法满足需求，需要及时找对应的人员沟通；
   表的数据结构：看一下相关表的数据结构有没有 json 数据或者其他比较复杂的数据，便于数仓处理；
   表的数据内容（数据质量）：看一下数据内容，是不是有一些字段毫无意义，不需要存储在数仓，或者检查一下是不是有很多空值、脏数据情况，目的就是探查业务库的数据质量，通过这些我们可以大概判断在数仓会有多少清洗机制；
   表数据量：看一下数据量，方便我们在抽取的时候选择增量抽取或者全量抽取，甚至可以问一下业务方业务增长情况，更能准确决定数据抽取策略。
3. 指标管理
   完善指标命名规范、指标同名名义、指标与业务强相关、明确指标构成要素
4. 模型设计
   完善开发流程规范、标准化业务调研、知识库文档集中管理、建立模型评审机制
5. etl开发
   ODS -> DWD -> DWS -> ADS
6. 数据验证
   制定数据测试标准
7. 任务调度
   规范化调度参数配置
8. 上线管理

4.2、开发详细流程及规范

4.2.1、清洗规范

    数据清洗是数据预处理的一项重要任务，旨在去除数据中的噪声、错误、重复和不一致之处，以提高数据质量和准确性。以下是一些常见的数据清洗规范和建议：

• 处理缺失值
  • 检测和识别缺失值，并决定如何处理它们。可以选择删除含有缺失值的记录、插值填充缺失值或使用特定值（如平均值、中位数等）进行填充。
  • 注意处理不同类型数据（数值型、分类型等）的缺失值的方法可能不同。
• 处理重复数据
  • 检测和识别重复数据，可以根据一定的规则或关键字段判断数据是否重复。
  • 决定如何处理重复数据，可以选择删除重复数据、保留第一个出现的数据或进行合并操作。
• 格式一致性
  • 统一数据字段的命名规范，确保字段名在整个数据集中是一致的，避免不同的命名方式导致数据分析困难。
  • 统一数据字段的数据类型，例如将日期字段转换为统一的日期格式，确保数据类型一致性。
• 异常值处理
  • 检测和处理异常值，可以使用统计方法或业务规则来识别异常值，然后决定如何处理这些异常值，例如删除、修正或标记为特殊值。
• 数据标准化
  • 将数据转换为一致的标准格式，例如统一单位、货币符号、日期格式等，以便于后续分析和比较。
• 数据类型转换
  • 将数据转换为正确的数据类型，例如将文本型数据转换为数值型数据、日期型数据转换为日期类型等，确保数据类型与数据内容一致。
• 数据一致性
  • 确保数据在不同数据源之间的一致性，例如通过比较和验证来自不同系统的数据，解决不一致之处。
• 数据验证
  • 对数据进行验证，确保数据符合预期的业务规则、约束和逻辑关系，以确保数据的完整性和准确性。

    以上是一些常见的数据清洗规范和建议，具体的数据清洗步骤和规范应根据具体的数据和业务需求进行定制和调整。清洗后的高质量数据将为后续的数据分析和挖掘提供可靠的基础。

举例说明一些常见的清洗示例：

1. 单位：比如金额单位统一为 元/美元/分/美分
2. 字段类型：比如平台 id，统一为 int 或者 string，避免出现 2 个不同的表定义不同类型。product_id 统一定义为 string，不要出现 a 表定义为 string，b 表定义为 bigint
3. 注释：对没有注释的字段，需要及时补全，新建表的时候，一定要带上注释
4. 时间格式：如 2020-10-16，2020/10/16，20201016 统一格式为 20201016
5. 枚举值：A表 1:男，2:女；B表 0:男，1:女；统一为：1:男 2:女
6. 数据脱敏：比如身份证号，手机号，邮箱等需要用加密函数进行脱敏
7. 控制转换：string——-99，int/bigint/double/decimal——0，date—— 1700-01-01，datetime——1700-01-01 00:00:00

4.2.2、数据同步规范

    数据同步是将数据从一个源系统复制到另一个目标系统的过程。为了确保数据同步的准确性和一致性，以下是一些常见的数据同步规范：

• 数据一致性：确保源数据和目标数据的一致性，避免数据丢失、重复或错误。

• 同步频率：确定数据同步的频率，根据业务需求和数据变更的速度来选择实时同步、定期同步或按需同步。

• 增量同步和全量同步：根据数据源和目标系统的特点，选择适合的同步方式。增量同步只传输和同步发生变化的数据，而全量同步传输和同步全部数据。

• 错误处理和恢复：建立错误处理机制，监控同步过程中的错误，及时记录和处理。同时，确保有可靠的数据恢复机制，以防止数据同步失败或中断时的数据丢失。

• 同步顺序：如果数据之间存在依赖关系，确保数据按正确的顺序进行同步，避免数据不一致性和冲突。

• 数据转换和映射：对于不同数据源和目标系统之间的数据差异，进行必要的数据转换和映射，确保数据能够正确地在不同系统之间进行传递和匹配。

• 监控和报警：建立监控机制，监控数据同步的状态和性能。及时发现同步过程中的异常情况，并设置报警机制，以便及时采取措施进行处理。

• 安全性和权限控制：确保数据同步过程的安全性，采取适当的安全措施，包括数据加密、身份验证和访问权限控制，以保护敏感数据的安全。

    这些规范的具体实施取决于具体的业务需求、数据源和目标系统的特点，以及数据同步的复杂程度和重要性。根据实际情况，可以进一步细化和定制数据同步规范。

数据同步的思路参考如下：

4.2.3、数仓分层规范

    在数据仓库中，常见的分层规范包括原始数据层（ODS）、数据仓库层（DWD）、数据集市层（DWS）和应用数据层（ADS）。下面对这些层进行阐述：

• 原始数据层（ODS）：
  原始数据层是数据仓库的第一层，用于接收和存储来自各个业务系统的原始数据。在这一层中，数据被保留为接收时的原始形式，通常不进行大规模的数据清洗和转换。ODS层的主要目标是将源系统的数据进行备份和保留，确保数据的完整性和可追溯性。
• 数据仓库层（DWD）：
  数据仓库层是数据仓库的核心层，也是数据清洗、集成和整合的地方。在这一层中，对ODS层的数据进行清洗、去重、转换和整理，以满足数据质量和一致性要求。DWD层通常包含事实表和维度表，用于支持复杂的数据分析和报表需求。
• 数据集市层（DWS）：
  数据集市层是数据仓库中的进一步集成和加工层。在这一层中，根据特定的业务需求或数据应用场景，对数据进行加工、汇总和聚合，以产生更高层次的指标和洞察。数据集市层可以根据业务功能或数据主题进行划分，例如销售集市、客户集市、风险集市等。
• 应用数据层（ADS）：
  应用数据层是为特定的业务应用或分析需求定制的数据层。在这一层中，根据具体的业务场景和用户需求，构建预定义的报表、仪表板、数据挖掘模型等，以便用户可以快速访问和分析数据。ADS层可以根据不同的业务部门或用户角色进行划分，以提供定制化的数据服务和分析能力。

    这些层级的设计和规范可以根据实际的数据仓库需求进行调整和扩展。它们形成了一个逐步集成和加工的数据流水线，从原始数据到经过清洗和整合的数据，再到更高层次的数据集市和应用数据，为用户提供全面和准确的数据支持。通过明确的分层规范，数据仓库能够更好地管理和提供各种层次的数据需求，支持数据驱动的决策和业务创新。

数仓分层：

4.2.4、词根规范

    词根规范是在数据仓库中对数据字段命名的一种规范化方法。它旨在为数据字段赋予一致的含义和易于理解的命名约定，以提高数据的可读性、可维护性和可理解性。以下是一些常见的词根规范示例：

• 前缀词根：
  前缀词根通常用于表示字段的数据类型或属性，例如：
  "dt_"表示日期类型字段
  "str_"表示字符串类型字段
  "num_"表示数值类型字段
  "bool_"表示布尔类型字段

• 名词词根：
  名词词根用于描述字段的含义或数据所代表的实体，例如：
  "customer_"表示客户相关字段
  "order_"表示订单相关字段
  "product_"表示产品相关字段

• 动词词根：
  动词词根用于表示字段的操作或行为，例如：
  "total_"表示总计或汇总字段
  "avg_"表示平均值字段
  "count_"表示计数字段

• 后缀词根：
  后缀词根用于进一步描述字段的特性或用途，例如：
  "_id"表示唯一标识符字段
  "_name"表示名称字段
  "_desc"表示描述字段

    通过使用词根规范，可以使数据字段的命名更加一致、易于理解和遵循统一的命名约定。这样可以降低数据理解和解释的难度，减少歧义和混淆，提高数据管理和数据分析的效率。词根规范应根据具体的数据仓库需求和业务领域进行调整和扩展，以确保命名的准确性和实用性。

4.2.5、模型评审规范

4.2.6、开发规范

• 开发原则
  开发原则包含：支持重跑、数据声明周期合理、任务迭代不会严重影响任务产出时间
• 命名规范
  命名规范包含：表命名规范、任务命名规范
• sql 编写规范
  1、表连接时，使用表别名引用列，如 t1.user_id，t2.user_name
  2、表名前面需要加上项目名，一个是比较清晰的，另一个是如果需要把该任务整段代码移到其他项目跑的时候（比如分析查询项目），需要手动加上项目名，否则会报错
  3、不要出现 select * 这样的操作

5、数据治理

5.1、数据质量管理

5.1.1 评估维度

• 完整性
  数据完整性评估数据是否具有完整的记录，没有缺失或丢失数据。这包括检查是否有缺失的字段、记录或关键信息。
• 一致性
  数据一致性评估数据在不同数据源、数据表或数据集之间的一致性。这包括检查数据的定义、格式、命名约定等方面的一致性。
• 规范性
  数据规范性评估数据是否符合规定的数据标准、格式和约束。这包括检查数据类型、长度、范围、格式要求等。
• 及时性
  数据及时性评估数据的更新频率和可用性。这包括检查数据的更新时间、延迟和实时性要求。
• 安全性
  数据安全性评估数据的安全性和保密性。这包括检查数据的敏感性、访问控制、数据加密等安全措施。
• 准确性
  数据准确性评估数据的精确性和正确性。这包括检查数据的来源、收集方法和处理过程，以确保数据与实际情况一致。
• 唯一性
  数据唯一性评估数据是否具有唯一标识符或键值。这包括检查是否存在重复的记录或键值。

5.1.2 实施流程

• 事前
  （1）数据探查
  （2）梳理表字段
  （3）指定资产等级
  （4）制定检验规则

• 事中
  （1）数据质量稽核
  （2）非空性稽核
  （3）唯一性稽核

• 事后
  （1）全量稽核
  （2）数据质量模型设计
  （3）表评分算法
  （4）数据质量管理系统报表查询
  （5）订阅

5.2、数据成本治理

• 成本治理缘由
  减少企业成本

• 目前存在的问题
  （1）机器利用率低
  （2）存储周期长、存储资源增长过快
  （3）成本没有量化标准
  （4）降本意思薄弱
  （5）任务优化空间非常大，尤其是离线计算

• 目前存在的问题
  （1）延迟启动
  （2）任务下线
  （3）任务调优
  （4）修改执行周期
  （5）任务排名、促进优化

• 治理效果分析
  （1）总览
  （2）按照责任人
  （3）按照业务线
  （4）明细分析

5.3、数据安全

数据安全模块是用于处理数据安全方面的技术和措施，以确保数据的保密性、完整性和可用性。以下是常见的数据安全模块和处理方法：

• 访问控制
  通过身份验证和授权机制，限制对数据的访问权限，确保只有授权的用户或实体能够访问数据。这包括使用密码、令牌、角色和权限管理等措施。

• 数据加密
  使用加密算法对敏感数据进行加密，以防止未经授权的访问和窃取。这包括对数据在传输过程中的加密（传输加密）和在存储介质上的加密（数据加密）。

• 数据脱敏
  对敏感数据进行脱敏处理，以保护个人隐私和敏感信息。脱敏方法可以包括匿名化、掩码、加盐哈希等技术，使敏感数据无法直接关联到个人身份。

• 审计日志
  记录和监控对数据的访问和操作行为，以便后续审计和追踪。审计日志可以用于发现异常活动、追溯数据操作责任和识别安全漏洞。

• 数据备份和恢复
  定期备份数据，并确保备份数据的安全性。在发生数据丢失、破坏或灾难情况时，能够快速恢复数据，保证业务的连续性和数据的完整性。

• 安全培训和意识
  提供数据安全培训和意识活动，教育员工关于数据安全的重要性和最佳实践。这可以包括数据安全政策的宣传、安全意识培训和定期安全演习等。

• 异常检测和威胁防护
  使用安全监控系统和工具，对数据访问和操作进行实时监测，以及检测和预防潜在的安全威胁和异常行为。这包括入侵检测系统（IDS）、入侵防御系统（IPS）和安全信息和事件管理（SIEM）等。

• 物理安全措施
  采取物理安全措施，保护存储数据的设备和设施，防止物理攻击和意外损坏。这包括使用访问控制、监控摄像头、防火墙和报警系统等。

通过综合使用这些数据安全模块和处理方法，组织可以有效保护数据

5.4、元数据管理

    元数据管理是指对数据的元数据进行组织、维护和管理的过程。元数据是描述数据的数据，它提供了关于数据的结构、定义、属性、关系和上下文等信息，帮助用户理解和使用数据。元数据管理的目标是确保数据的准确性、一致性、可信度和可管理性，以支持数据的有效管理和利用。

5.4.1、元数据定义以及重要性

元数据可以包括以下内容：

• 数据定义
  描述数据的结构、格式、模式和约束条件。例如，数据表、字段、数据类型、主键、外键等。

• 数据源和来源：
  记录数据的来源和数据源的信息，包括数据提供方、数据采集方式、数据传输协议等。

• 数据质量指标：
  定义和记录数据质量指标和标准，例如数据准确性、完整性、一致性、时效性等。

• 数据变动历史：
  记录数据的变动历史，包括数据的创建时间、修改时间、版本号等信息。

• 数据访问权限：
  记录数据的访问权限和安全设置，包括数据的可访问范围、用户权限、角色权限等。

• 数据关系和依赖：
  描述数据之间的关系和依赖关系，包括表之间的关联关系、数据流程、数据转换逻辑等。

• 数据业务规则：
  记录数据的业务规则和逻辑，包括数据的计算规则、数据转换规则、数据验证规则等。

元数据管理的重要性体现在以下几个方面：

• 数据理解和使用
  元数据提供了数据的上下文和含义，帮助用户理解数据的结构和意义，从而更好地使用和分析数据。

• 数据一致性和准确性
  通过元数据管理，可以确保数据的定义和约束条件的一致性，从而提高数据的准确性和质量。

• 数据集成和共享
  元数据管理可以帮助识别和管理不同数据源和数据系统之间的关系，促进数据的集成和共享。

• 数据安全和权限控制
  元数据管理可以记录和管理数据的访问权限和安全设置，确保数据的安全性和合规性。

• 数据治理和数据血缘分析
  元数据管理为数据治理和数据血缘分析提供了基础，支持数据的追溯、追踪和管理。

通过有效的元数据管理，组织可以更好地管理和利用数据，提高数据的价值和效益。

5.4.2、元数据管理方式

• 元数据分类
  （1）技术元数据：存储元数据、运行元数据、调度元数据
  （2）业务元数据：维度及属性、业务过程、指标
• 元数据平台建设
  EXCEL、自研、商用（如datawroks）、开源组件（如Atlas）
• 元数据应用
  数据地图、数据血缘、数据开发规范、模型优化、成本治理

5、数据建模

5.1、 模型建设

5.1.1 什么是数据模型

• 基于对业务的理解，对各种数据进行整合和关联
• 增强数据可用性、可读性、让使用方可快速获取有价值的信息
• 数据模型一般使用星型模型
• 数据模型就是按照一定规则设计的表

5.1.2 为什么要数据建模

• 进行全面的业务梳理，改进业务流程
• 建立全方位的数据视角，消灭信息孤岛和数据差异
• 解决业务的变动和数据仓库的灵活性
• 帮助数据仓库系统本身的建设

5.1.3 建模工具

• PowerDesigner
• draw.io
• Visio
• ER/Studio

5.1.4 数据建模原则

• 高内聚和低耦合
• 核心模型与扩展模型分离
• 公共处理逻辑下沉及单一
• 成本与性能平衡
• 数据可回滚
• 一致性
• 命名清晰、可理解

5.1.5 建模阶段划分

• 业务模型——生成业务模型，主要解决业务层面的 分解和程序化
• 领域模型——生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型
• 逻辑模型——生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次 的逻辑化
• 物理模型——生成物理模型，主要解决逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。

5.1.6 建模步骤

• 选择需要进行分析决策的业务过程。比如下单。
• 选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。比如订单粒度，粒度是维度的一个组合。
• 识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。
• 选择事实。确定分析需要衡量的指标。

5.2、模型评判标准&模型优化策略

• 扩展性
  新增加的模型是否和老模型出现冲突。
• 时效性
  能否保证日常的sla（时效保障）。
• 准确性
  输出的指标数据质量能够保证。
• 低成本
  存储成本、计算成本。
• 健壮性
  业务快速更新迭代的情况下不会太影响底层模型。
• 规范度
  主题域归属、任务命名规范。
• 复用度
  （1）模型引用系数：模型被读取并产出下游模型的平均数量；
  （2）dwd、dws下游直接产出表的数量。
• 完善度
  （1）汇总数据能直接满足多少查询需求，即应用层访问汇总层数据的查询比例；
  （2）跨层层引用率：ODS 层直接被 DWS/ADM/DIM 层引用的表，占所有 ODS 层表（仅统计活跃表）比例；
  （3）同层 level>2 的占比等量化 指标；
  （4）快速响应业务方的需求；
  （5）比较好的模型，使用方是可以直接从该模型获取所有想要的数据的，如果 dws、ads、dim 层直接引用 ods 层的表比例太大，即跨层率太高，则模型不是最优，可以继续优化。

6、数据任务及时产出

6.1、模型层面

• 模型设计
  （1）开发规范
  （2）设计原则
• 模型新增&迭代
  （1）模型新增——试运行后上线
  （2）模型迭代——试运行后上线、评估对上下游任务的影响
• 模型优化
  （1）sql 调优
  （2）事实表维表的拆分与整合
• 模型优先级
  （1）设置优先级
  （2）合理评估优先级

6.2、调度层面

• 调度系统
  （1）调度系统调不起来任务
  （2）运行成功的任务状态一直不改变，下游无法运行
• 任务调度配置
  （1）没有配置依赖
  （2）任务互相依赖

6.3、大数据运维层面

• 资源
  （1）计算
  （2）存储
• 组件故障

6.4、监控层面

• 数据质量监控
  （1）数据量
  （2）唯一性
  （3）指标波动

• 任务延迟未产出监控
  （1）超时时间设置
  （2）人工介入文章来源地址https://www.toymoban.com/news/detail-659131.html

6.5、值班层面

• 人员安排
• 告警机制
• 问题处理机制
• 责任划分
• 故障等级报告

到了这里，关于数据仓库建设指导说明的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！