1、概念

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

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

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

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

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）是用于组织和设计数据仓库的两种常见模型，它们有以下区别：

	星型模型（Star Schema）	雪花模型（Snowflake Schema）
结构	简单结构，维度表围绕事实表形成星型结构	规范化结构，维度表分解为多个规范化的子表
冗余	较高冗余，维度表包含完整的维度属性	较低冗余，规范化的子表消除部分数据冗余
关联	维度表与事实表之间直接关联，一对多关系	多级关联，维度表分解为多个子表形成雪花形状
存储效率	相对较低，冗余导致存储需求较大	相对较高，规范化减少了存储需求
查询性能	较高，结构简单，直接从表中获取属性值	略低，存在多级关联需要更多的表关联操作
可理解性	较高，简单直观的结构，易于理解和使用	略低，存在多级关联和规范化的结构，复杂度较高
适用场景	简单的维度关系和较小规模的数据仓库	复杂的维度关系和大规模的数据仓库

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

3.3.3、Kimball 架构特点

Kimball 架构有以下特点：

• 存储的数据有粗粒度的也有细粒度的
• 一般使用温度建模，不太考虑三范式
• 数据仓库可以直接对外提供数据
• 不存在真实数据集市，存在虚拟数据集市，以主题域进行划分
• 以需求为导向，自下而上进行开发建设

Inmon架构与kimball架构区别：

	Inmon架构	Kimball架构
定位	企业数据仓库架构	维度建模架构
数据存储	规范化（第三范式）	冗余和快照
导向	数据一致性和集成性	查询性能和用户友好性
模型	维度模型（Dimensional Model）	星型模型（Star Schema）
重点	ETL过程	业务驱动
查询性能	较低，需要较多的表关联操作	较高，通过冗余和预计算提高查询性能
数据更新	需要ETL过程进行数据转换和加载	可直接加载源数据
适用场景	复杂的数据集成和一致性要求	需要快速查询和分析的业务用户

以上是对Inmon架构和Kimball架构的一般比较。在实际应用中，您可能会根据具体情况进行适当的调整和自定义，以满足特定的业务需求和数据特点。

4、开发流程

4.1、开发大体流程

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

4.2、开发详细流程及规范

4.2.1、清洗规范

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

1、处理缺失值：

• 检测和识别缺失值，并决定如何处理它们。可以选择删除含有缺失值的记录、插值填充缺失值或使用特定值（如平均值、中位数等）进行填充。
• 注意处理不同类型数据（数值型、分类型等）的缺失值的方法可能不同。

2、处理重复数据：

• 检测和识别重复数据，可以根据一定的规则或关键字段判断数据是否重复。
• 决定如何处理重复数据，可以选择删除重复数据、保留第一个出现的数据或进行合并操作。

3、格式一致性：

• 统一数据字段的命名规范，确保字段名在整个数据集中是一致的，避免不同的命名方式导致数据分析困难。
• 统一数据字段的数据类型，例如将日期字段转换为统一的日期格式，确保数据类型一致性。

4、异常值处理：

• 检测和处理异常值，可以使用统计方法或业务规则来识别异常值，然后决定如何处理这些异常值，例如删除、修正或标记为特殊值。

5、数据标准化：

• 将数据转换为一致的标准格式，例如统一单位、货币符号、日期格式等，以便于后续分析和比较。

6、数据类型转换：

• 将数据转换为正确的数据类型，例如将文本型数据转换为数值型数据、日期型数据转换为日期类型等，确保数据类型与数据内容一致。

7、数据一致性：

• 确保数据在不同数据源之间的一致性，例如通过比较和验证来自不同系统的数据，解决不一致之处。

8、数据验证：

• 对数据进行验证，确保数据符合预期的业务规则、约束和逻辑关系，以确保数据的完整性和准确性。

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

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

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）人工介入

6.5、值班层面

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