DataWarehouse 数据仓库

目录

• DataWarehouse 数据仓库
• • 1、数据处理方式
  • • 1.1. OLTP
    • 1.2. OLAP
    • • 1.2.1 OLAP基本操作
  • 2、数据建模
  • • 2.1. 关系建模
    • 2.2. 维度建模
  • 3、维度表分类
  • • 3.1. 维度表
    • 3.2. 事实表
  • 4、数据组织类型
  • • 4.1. 星型模型
    • 4.2. 雪花模型
    • 4.3. 星座模型
    • 4.4. 模型选择
  • 5、数仓特征
  • • 5.1. 面向主题
    • 5.2. 集成性
    • 5.3. 不可更新
    • 5.4. 时变性
  • 6、数据仓库分层
  • • 6.1. 数仓分层原因
    • 6.2. 数仓分层好处
    • 6.3. 数仓分层明细
    • • 6.3.1. ODS原始数据层
      • 6.3.2. DW数据仓库层
      • 6.3.3. ADS数据服务层
  • 7、阿里数仓五层
  • • 7.1. ODS 原始数据层
    • 7.2. DWD 明细数据层
    • 7.3. DWS 服务数据层
    • 7.4. DWT 主题数据层
    • 7.5. ADS 应用数据层
  • 8、数据仓库规范设计
  • • 8.1. 表命名规范
    • 8.2. 开发规范
    • 8.3. 流程规范
  • 9、常见概念描述
  • • 9.1. 数据仓库
    • 9.2. 数据集市
    • 9.3. 数据孤岛
    • 9.4. 数据湖
    • 9.5. 数据中台
    • 9.6. 宽表
    • 9.7. 窄表
  • 10、ETL
  • • 10.1. 概念：
    • 10.2. 模块介绍
    • 10.3. ETL工具
    • 10.4. 加载策略
  • 11、数据仓库元数据
  • • 11.1. 业务元数据
    • 11.2. 技术元数据
    • 11.3. 管理元数据
  • 12、数据治理
  • • 12.1. 概念
    • 12.2. 目的
    • 12.3. 方法
  • 13.、数仓的作用

​ 数仓是一种思想，数仓是一种规范，数仓是一种解决方案。

1、数据处理方式

数据处理大致可以分成两大类：

• 联机事务处理OLTP（on-line transaction processing）
• 联机分析处理OLAP（On-Line Analytical Processing）

1.1. OLTP

• OLTP的全称是On-line Transaction Processing，中文名称是联机事务处理。
• 其特点是会有高并发且数据量级不大的查询，是主要用于管理事务（transaction-oriented)的系统。
• 此类系统专注于 short on-line-tansactions 如INSERT, UPDATE, DELETE操作。通常存在此类系统中的数据都是以 实体对象模型来存储数据，并满足3NF(数据库第三范式)。
• 由于OLTP主要是为了操作数据而设计（操作系统），用于处理已知的任务和负载：常见的优化在 于主码索引和散列，检索特定的记录。去优化某一些特定的查询语句。

1.2. OLAP

• OLAP的全称是 On-line Analytical Processing,中文名称是联机分析处理。
• 其特点是查询频率较 OLTP系统更低，但通常会涉及到非常复杂的聚合计算。 OLAP系统以维度模型来存储历史数据，其 主要存储描述性的数据并且在结构上都是同质的。
• OLAP则是为了分析数据而设计（数据仓库)，其查询的方式往往是复杂且未知的，通常会涉及大量 数据在汇总后的计算，这种需要基于多维视图的数据操作在OLTP上执行的时候性能将是非常差 的，并且是也是极其危险的。
• 

1.2.1 OLAP基本操作

• 上卷:roll-up drill-up
  • 通过一个维的概念分层向上攀升或者通过维归约在数据立方体上进行聚集。 比如城市统计数据维度到省级统计数据维度。
• 下钻:drill-down
  • 下钻是上卷的逆操作，由不太详细的数据到更详细的数据。 下钻可以通过沿维的概念分层向下或引入附加的维来实现。
• 切片:slice
  • 在给定的立方体的一个维上进行选择，从而定义一个子立方体。
• 切块 dice
  • 通过两个或多个维上进行选择，定义一个子立方体。
• 转轴:pivot
  • 是一种目视操作，就像是一个二维表的行列转换，两个维度的互换。
• 钻过:drill-across
  • 其执行会涉及多个事实表的查询
• 钻透:drill-through
  • 下钻透过多维数据立方直达RDMS表

2、数据建模

​ 数据建模指的是对现实世界各类数据的抽象组织，确定数据库需管辖的范围、数据的组织形式等直至转 化成现实的数据库。

• 性能：良好的模型能帮我们快速查询需要的数据，减少数据的IO吞吐
• 成本：减少数据冗余、计算结果复用、从而降低存储和计算成本
• 效率：改善用户使用数据的体验，提高使用数据的效率
• 改善统计口径的不一致性，减少数据计算错误的可能性。

2.1. 关系建模

• 设计一个3NF模型的方法，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF。
• 它更多是面向数据的整合和一致性治理。
• 优点：规范性较好，冗余小，数据集成和数据一致性方面得到重视
• 缺点：需要全面了解企业业务、数据和关系；实施周期非常长，成本昂贵；对建模人员的能力要求也非常高，容易烂尾。

2.2. 维度建模

• 维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务。
• 因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能，更直接面向业务。
• 优点：技术要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析需求，较好的大规模 复杂查询的响应性能
• 缺点：维度表的冗余会较多，视野狭窄。

3、维度表分类

在维度建模中，将度量称为“事实” ， 将环境描述为“维度”。

3.1. 维度表

• 一般是对事实的描述信息。每一张维度表对应现实世界中的一个对象或者概念。
• 维度表特征
  • 1. 维度表的范围很宽（具有多个属性、列比较多）
  • 2. 跟事实表相比，行数较少，（通常小于10万条）
  • 3. 内容相对固定
• 维度建模四部曲
  • 选择业务处理过程 > 定义粒度 > 选择维度 > 确定事实
  • 选择业务：选择感兴趣的业务线，如下单，支付，退款，活动 。
  • 声明粒度：一行代表信息：一条订单？一天的订单？一周的订单？ 选择最小粒度
  • 确认维度：维度退化：谁 。 什么时间 什么地点
  • 确认事实：度量值：如个数，件数，金额
• 设计原则
  1. 维度属性尽量丰富，为数据使用打下基础
  2. 给出详实的、富有意义的文字描述
  3. 区分数值型属性和事实
  4. 沉淀出通用的维度属性，为建立一致性维度做好铺垫
  5. 退化维度（DegenerateDimension）
     • 是直接把一些简单的 维度放在事实表中。
     • 是维度建模领域中的一个非常重要的概念，退化维度一般在分析中可以用来做分组使用。
  6. 缓慢变化维（Slowly Changing Dimensions）
     • 维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，（SCD）
  7. 冗余维度：为了提升效率，把常用的维度冗余到事实表

3.2. 事实表

• 表中的每行数据代表一个业务事件。“事实”表示的是业务事件的度量值（可以统计次数、个数、金 额等）

• 事实表特征

  1. 非常的大
  2. 内容相对的窄
  3. 经常发生变化，每天新增很多。

• 事实表分类

  1. 事务型事实表
     • 以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的 一行数据。
     • 一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。
  2. 周期型快照事实表
     • 周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，以具有规律性的、可预见的时间间隔记录事实。
     • 例如每天或每月的总销售金额，或每月的账户余额等。
  3. 累积型快照事实表
     • 表用于跟踪业务事实的变化，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点。
     • 例如数据仓库中可能需要累积或者存储订单从下单开始，各个业务阶段的时间点数据，来跟踪订单生命周期的进展情况。
     • 当这个业务过程进行时，事实表的记录也要不断更新。

4、数据组织类型

​ 维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。

4.1. 星型模型

• 是一种多维的数据关系，它由一个事实表（Fact Table）和一组维表（Dimension Table）组成。 每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。
• 星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，所以数据有一定的冗余。
• 

4.2. 雪花模型

• 当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。
• 雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。
• 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。
• 

4.3. 星座模型

• 星座模型需要多个事实表共享维度表，因而可以视为星形模型的集合，故亦被称为星系模型。
• 星座模型是很多数据仓库的常态，因为很多数据仓库都是多个事实表的。所以星座模型只反映是否有多个事实表，他们之间是否共享一些维度表。
• 

4.4. 模型选择

• 模型的选择跟数据和需求有关系，跟设计没关系。
• 星型还是雪花，取决于性能优先，还是避免冗余、灵活更优先。
• 实际企业开发中，一般不会只选择一种，需要根据情况灵活组合，甚至并存（一层维度和多层维度都保存）。
• 整体来看，更倾向于维度更少的星型模型。尤其是大型数据仓库项目，减少表连接的次数，可以显著提升查询效率。

5、数仓特征

​ 英文名称为Data Warehouse，可简写为DW或DWH。数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持。它出于分析性报告和决策支持目的的创建。

​ 数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因

​ 数据仓库是决策支持系统（dss）和联机分析应用数据源的结构化数据环境。数据仓库研究和解决从数据库中获取信息的问题。数据仓库的特征在于面向主题、集成性、稳定性和时变性。

5.1. 面向主题

​ 数据仓库中的数据是按照一定的主题域进行组织。

​ 主题是一个抽象的概念，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。而操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离。

​ 每一个主题基本对应一个宏观分析领域。 主题(Subject)是对应企业中某一宏观分析领域所涉及的分析对象（重点是分析的对象，对象，仔细理解 一下对象的含义）。

5.2. 集成性

​ 数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。面向 事务处理的操作型数据库通常与某些特定的应用相关，数据库之间相互独立，并且往往是异构的。 这一步时数据仓库中最关键、最复杂的一步，所有完成的工作有：

​ 1. 要统一源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不统一、字长不一致，等等；

​ 2. 进行数据综合和计算，数据仓库中的数据综合工作可以在从源数据库中抽取时生成，但许多是在数据 仓库内部生成的。

5.3. 不可更新

​ 数据仓库的数据反应的是一段相当长的时间内的历史数据的内容，是不同时点的数据库快照的集合，以 及基于这些快照进行统计、综合和重组的导出数据。

​ 数据非易失性主要针对与应用而言，数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。

5.4. 时变性

​ 数据仓库中包含各种粒度的历史数据，数据仓库中的数据可能和特定的某个日期、星期、月份、季度和 年份有关。数据仓库的目的是根据企业过去一段时间里业务的经营状况，挖掘其中隐藏的模式。虽然数 据仓库的用户不能修改数据，但并不是说数据仓库中的数据是永远不变的。分析结果只是反应过去的情 况，当业务发生变化后，挖掘出的模式就会失去失效性。因此数据仓库中的数据需要更新，以适用决策的需要。从这个角度讲，数据仓库建设是一个项目，更是一个过程。数据仓库的数据随时间的变化表现 在以下几个方面：

​ 1. 数据仓库的数据时效一般要远远长于操作型数据库数据的时效。

​ 2. 操作性数据库存库的是当前数据，而数据仓库中存储的是历史数据。

​ 3. 数据仓库中的数据是按照时间顺序进行追加的，它们都带有时间属性。

6、数据仓库分层

按照数据流入流出的过程，数据仓库架构可以分为三层–源数据、数据仓库、数据应用。

6.1. 数仓分层原因

• 用空间换时间；通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量的冗余数据；
• 增强扩展性；不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大
• 分层管理；通过数据分层管理可以简化数据清洗的过程，因为把原来的一步工作分到了多个步骤去完成， 相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的 处理逻辑都相对简单和容易理解 ，这样我们比较容易保证每一个步骤的正确性，当数据发生错误时，往往我们只需要局部调整某个步骤即可。

6.2. 数仓分层好处

• 清晰数据结构： 每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
• 方便数据血缘追踪： 简单来说，我们最终给业务呈现的是一个能直接使用业务表，但是它的来源有很多，如果有一 张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。
• 减少重复开发： 规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
• 把复杂问题简单化： 将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。 而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问 题的步骤开始修复。
• 屏蔽原始数据: 屏蔽业务的影响，不必改一次业务就需要重新接入数据

6.3. 数仓分层明细

数据分层每个企业根据自己的业务需求可以分成不同的层次，但是最基础的分层思想，

理论上数据分为 三个层 1 ods 2 dw 3 ads。

6.3.1. ODS原始数据层

• Operate data store（操作数据-存储 ）
• 该层最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的ETL之后，装入ODS层。
• 本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。

6.3.2. DW数据仓库层

• Data warehouse（数据仓库）。
• 该层从ODS层中获得的数据按照主题建立各种数据模型。
• 四个概念：维（dimension）、事实（Fact）、指标（Index）和粒度（ Granularity）。

6.3.3. ADS数据服务层

• Application Data Service(应用数据服务)。
• 该层主要是提供数据产品和数据分析使用的数据，一般会存放在ES、MySQL等系统中供线上系统使用，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。

7、阿里数仓五层

• ODS (Operation Data Store) 原始数据层
• DW 数据仓库
  • DWD (Data Warehouse Detail) 明细数据层
  • DWS (Data Warehouse Service) 服务数据层
  • DWT (Data Warehouse Topic) 主题数据层
• ADS (Application Data Store) 应用数据层

7.1. ODS 原始数据层

• 功能：
  • ODS层是数据仓库准备区，为DWD层提供基础原始数据，可减少对业务系统的影响
• 建模方式及原则：
  • 从业务系统增量抽取、保留时间由业务需求决定、可分表进行周期存储、数据不做清洗转换与业务系统数据模型保持一致、按主题逻辑划分

7.2. DWD 明细数据层

• 功能：
  • 为DW层提供来源明细数据，提供业务系统细节数据的长期沉淀，为未来分析类需求的扩展提供历史数据支撑
• 建模方式及原则：
  • 数据 进一步细化。
  • 数据模型与ODS层一致，不做清洗转换处理、为支持数据重跑可额外增加数据业务日期字段、可按年月日进行分表、用增量ODS层数据和前一天DWD相关表进行merge处理

7.3. DWS 服务数据层

• 功能：
  • 为DW、ST层提供细粒度数据，细化成DWB和DWS；
  • DWB是根据DWD明细数据进行转换，如维度转代理键、身份证清洗、会员注册来源清晰、字 段合并、空值处理、脏数据处理、IP清晰转换、账号，余额清洗、资金来源清洗等；
  • DWS是根据DWB层数据按各个维度ID进行高粒度汇总聚合，如按交易来源，交易类型进行汇合
• 建模方式及原则：
  • 聚合、汇总增加派生事实；
  • 关联其它主题的事实表，DW层可能会跨主题域；
  • DWB保持低粒度汇总加工数据，DWS保持高粒度汇总数据；
  • 数据模型可能采用反范式设计，合并信息等。

7.4. DWT 主题数据层

• 功能：
  • 可以是一些宽表，是根据DW层数据按照各种维度或多种维度组合把需要查询的一些事实字段 进行汇总统计并作为单独的列进行存储；
  • 满足一些特定查询、数据挖掘应用
  • 应用集市数据存储
• 建模方式及原则：
  • 尽量减少数据访问时计算(优化检索)
  • 维度建模，星型模型；
  • 分表存储

7.5. ADS 应用数据层

• 功能：
  • ST层面向用户应用和分析需求，包括前端报表、分析图表、KPI、仪表盘、OLAP、专题等分 析，面向最终结果用户
  • 例如银行分析销售数据，可能会综合时间周期、产品类别、分销渠道、地理分布、客户群类等 多种因素来考量。
• 建模方式及原则：
• 保持数据量小
• 维度建模，星形模型
• 各位维度代理键+度量
• 增加数据业务日期字段，支持数据重跑；
• 不分表存储

8、数据仓库规范设计

​ 按照一个标准或流程进行开发，以保证数据一致性，流程清晰且稳定。 提高开发效率，提升质量，降低沟通对齐成本，降低运维成本等

8.1. 表命名规范

表名需要见名知意，通过表名就可以知道它是哪个业务域，干嘛用的，什么粒度的数据。

• 常规表
  • 常规表是我们需要固化的表，是正式使用的表，是目前一段时间内需要去维护去完善的表。
  • 规范：分层前缀[dwd|dws|ads|bi] _ 业务域 _ 主题域XXX _ 粒度
  • 例如: dwd_xxx_xxx_da（di ：每日增量，da：每日全量，mi：每月增量，ma：每月全 量）
• 中间表
  • 中间表一般出现在Job中，是Job中临时存储的中间数据的表，中间表的作用域只限于当前Job 执行过程中，Job一旦执行完成，该中间表的使命就完成了，是可以删除的。
  • 规范：mid_table_name_[0~9|dim] table_name是我们任务中目标表的名字，通常来说一个任务只有一个目标表。通常会遇到需要补全维度的表，这里我喜欢使用dim结尾。
• 临时表
  • 临时表是临时测试的表，是临时使用一次的表，就是暂时保存下数据看看，后续一般不再使用 的表，是可以随时删除的表。
  • 规范：tmp_xxx 只要加上tmp开头即可，其他名字随意，注意tmp开头的表不要用来实际使用，只是测试验证 而已。
• 维度表
  • 维度表是基于底层数据，抽象出来的描述类的表。维度表可以自动从底层表抽象出来，也可以 手工来维护。
  • 规范：dim_xxx 维度表，统一以dim开头，后面加上，对该指标的描述，可以自由发挥。

8.2. 开发规范

8.3. 流程规范

• 需求阶段：数据产品经理应如何应对不断变化的业务需求。
• 设计阶段：数据产品经理、数据开发者应如何综合性能、成本、效率、质量等因素，更好地组织与存储数据。
• 开发阶段：数据研发者如何高效、规范地进行编码工作。
• 测试阶段：测试人员应如何准确地暴露代码问题与项目风险，提升产出质量。
• 发布阶段：如何将具备发布条件的程序平稳地发布到线上稳定产出。
• 运维阶段：运维人员应如何保障数据产出的时效性和稳定性。

9、常见概念描述

9.1. 数据仓库

• 概念： 数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理 中的决策制定。
• 特点： 首先，数据仓库用于支持决策，面向分析型数据处理，它不同于企业现有的操作型数据库; 其次，数据仓库是对多个异构的数据源有效集成，集成后按照主题进行了重组，并包含历史数据，而且存放在数据仓库中的数据一般不再修改。
• 应用场景： 一般都是作为商业智能系统、数据仪表盘等可视化报表服务的数据源。
• 数据仓库是一个功能概念，是将企业的各业务系统产生的基础数据，通过维度建模的方式，将业务数据划分为多个主题（集市统一存储，统一管理。

9.2. 数据集市

• 概念： 数据集市可以理解为是一种"小型数据仓库"，它只包含单个主题，且关注范围也非全局。
• 数据 集市可以分为两种分类： 独立数据集市，这类数据集市有自己的源数据库和ETL架构；
• 非独立数据集市，这种数据集市没有自己的源系统，它的数据来自数据仓库。
• 应用场景： 数据集市是数仓之上更聚焦的业务主题合集，更偏向于应对业务数据快速高效应用的需求，一 般用于商业智能系统中探索式和交互式数据分析应用。
• 数据集市是一个结构概念，它是企业级数据仓库的一个子集，主要面向部门级业务，并且只面向某 个特定的主题。

9.3. 数据孤岛

• 业务系统之间各自为政、相互独立造成的数据孤岛，体现在业务不集成、流程不互通、数据不共享。

9.4. 数据湖

• 概念： 2010年，Pentaho首席技术官James Dixon创造了“数据湖”一词。 他把数据集市描述成一瓶清洗过的、包装过的和结构化易于使用的水。 数据湖更像是未经处理和包装在自然状态下的水，数据流从源系统流向这个湖。用户可以在数据湖里校验，取 样或完全的使用数据。
• 特点： 从源系统导入所有的数据，没有数据流失。 数据存储时没有经过转换或只是简单的处理。 数据转换和定义schema 用于满足分析需求。
• 应用场景： 以大数据技术为基础有多样化数据结构海量大数据存储需求，也可作为数据仓库或者数据集市 的数据源。
• 数据湖是一种数据存储理念，存储企业各种各样的原始数据的大型仓库，包括结构化、非结构、二 进制图像、音频、视频等等。

9.5. 数据中台

• 概念： 数据中台是指通过企业内外部多源异构的数据采集、治理、建模、分析，应用，使数据对内优化管理提高业务，对外可以数据合作价值释放，成为企业数据资产管理中枢。数据中台建立后，会形成数据API，为企业和客户提供高效各种数据服务。
• 特点： 利用大数据技术，对海量数据进行统一采集、计算、存储，并使用统一的数据规范进行管理， 将企业内部所有数据统一处理形成标准化数据，挖掘出对企业最有价值的数据，构建企业数据 资产库，提供一致的、高可用大数据服务。 数据中台不是一套软件，也不是一个信息系统，而是一系列数据组件的集合，企业基于自身的 信息化建设基础、数据基础以及业务特点对数据中台的能力进行定义，基于能力定义利用数据 组件搭建自己的数据中台。
• 应用场景： 是将数据服务化提供给业务系统，目的是将数据能力渗透到业务各个环节，不限于决策分析。
• 数据中台是一个逻辑概念，为业务提供服务的主要方式是数据API，它包括了数据仓库，大数据、 数据治理领域的内容。

9.6. 宽表

• 从字面意义上讲就是字段比较多的数据库表。
• 通常是指业务主题相关的指标、维度、属性关联在一起的一张数据库表。
• 由于把不同的内容都放在同一张表存储，宽表已经不符合三范式的模型设计规范，随之带来的主要坏处就是数据的大量冗余，与之相对应的好处就是查询性能的提高与便捷。
• 这种宽表的设计广泛应用于数据挖掘模型训练前的数据准备，通过把相关字段放在同一张表中，可 以大大提高数据挖掘模型训练过程中迭代计算时的效率问题。

9.7. 窄表

• 严格按照数据库设计三范式。尽量减少数据冗余，但是缺点是修改一个数据可能需要修改多张表。
• 方便扩展，能适应各种复杂的数据结构（树形、继承等），无论有多少配置，都不用修改表结构。 但代码逻辑可能需要包装一下。

10、ETL

10.1. 概念：

• ETL是将业务系统的数据经过抽取（Extract）、清洗转换（Transform）之后加载（Load）到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分 析依据。
• 五大模块： 数据抽取、数据清洗、库内转换、规则检查、数据加载。
• 各模块可灵活进行组合，形成ETL处理流程。

10.2. 模块介绍

• 数据抽取
  1. 确定数据源，需要确定从哪些源系统进行数据抽取
  2. 定义数据接口，对每个源文件及系统的每个字段进行详细说明
  3. 确定数据抽取的方法：是主动抽取还是由源系统推送？是增量抽取还是全量抽取？是按照每日 抽取还是按照每月抽取？
• 数据清洗
  1. 主要将不完整数据、错误数据、重复数据进行处理
• 数据转换
  1. 空值处理：可捕获字段空值，进行加载或替换为其他含义数据，或数据分流问题库
  2. 数据标准：统一元数据、统一标准字段、统一字段类型定义
  3. 数据拆分：依据业务需求做数据拆分，如身份证号，拆分区划、出生日期、性别等
  4. 数据验证：时间规则、业务规则、自定义规则
  5. 数据替换：对于因业务因素，可实现无效数据、缺失数据的替换
  6. 数据关联：关联其他数据或数学，保障数据完整性

10.3. ETL工具

• ETL工具（sqoop，DataX，Kettle，canal，StreamSets）

• sqoop： 是Apache开源的一款在Hadoop和关系数据库服务器之间传输数据的工具。

  • 将一个关系型数据库（MySQL ,Oracle等）的数据导入到Hadoop的HDFS中，也可以将HDFS 的数据导出到关系型数据库中。
  • sqoop命令的本质是转化为MapReduce程序。
  • sqoop分为导入（import）和导出（export）
  • 策略分为table和query 模式分为增量和全量。

• 

• DataX DataX

  • 是阿里巴巴集团内被广泛使用的离线数据同步工具/平台
  • 实现包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、 TableStore(OTS)、、DRDS 等各种异构数据源之间高效的数据同步功能。

• 

10.4. 加载策略

• 系统日志分析方式 ：通过分析数据库自身的日志来判断变化的数据。
• 触发器方式： 直接进行数据加载 利用增量日志表进行增量加载
• 时间戳方式 ：在源表上增加一个时间戳字段，系统中更新修改表数据的时候，同时修改时间戳字段的值。
• 全表比对方式： 全表比对即在增量抽取时，ETL 进程逐条比较源表和目标表的记录，将新增和修改的记录读取 出来。
• 源系统增量：（delta）数据直接或者转换后加载 日常的 ETL 更新中，还会遇到目标表的数据来源来自于多张源表，通过关键字段的拼接进行更新操作。 如果多张源表都有时间戳字段，可以利用时间戳进行增量更新，另外还可以采用全表比对的方式进行增量更新。

11、数据仓库元数据

11.1. 业务元数据

• 描述 ”数据”背后的业务含义
• 主题定义：每段 ETL、表背后的归属业务主题。
• 业务描述：每段代码实现的具体业务逻辑。
• 标准指标：类似于 BI 中的语义层、数仓中的一致性事实；将分析中的指标进行规范化。
• 标准维度：同标准指标，对分析的各维度定义实现规范化、标准化。
• 不断的进行维护且与业务方进行沟通确认。

11.2. 技术元数据

• 数据源元数据
  • 例如：数据源的 IP、端口、数据库类型；数据获取的方式；数据存储的结构；原数据各列的 定义及 key 指对应的值。
• ETL 元数据
  • 根据 ETL 目的的不同，可以分为两类：数据清洗元数据；数据处理元数据。
    • 数据清洗，主要目的是为了解决掉脏数据及规范数据格式；因此此处元数据主要为：各表各列 的"正确"数据规则；默认数据类型的"正确"规则。
    • 数据处理，例如常见的表输入表输出；非结构化数据结构化；特殊字段的拆分等。源数据到数 仓、数据集市层的各类规则。比如内容、清理、数据刷新规则。
• 数据仓库元数据
  • 数据仓库结构的描述，包括仓库模式、视图、维、层次结构及数据集市的位置和内容；
  • 业务系 统、数据仓库和数据集市的体系结构和模式等。
• BI 元数据
  • 汇总用的算法、包括各类度量和维度定义算法。
  • 数据粒度、主题领域、聚集、汇总、预定义的 查询与报告。

11.3. 管理元数据

• 管理领域相关，包括管理流程、人员组织、角色职责等。

12、数据治理

12.1. 概念

1. 数据治理（Data Governance）是组织中涉及数据使用的一整套管理行为。由企业数据治理部门发 起并推行，关于如何制定和实施针对整个企业内部数据的商业应用和技术管理的一系列政策和流 程。
2. 数据的质量直接影响着数据的价值，并且直接影响着数据分析的结果以及我们以此做出的决策的质 量。我们常说，用数据说话，用数据支撑决策管理，但低质量的数据、甚至存在错误的数据，必然 会"说假话"！！！
3. 数据治理即提高数据的质量，发挥数据资产价值。

12.2. 目的

• 降低风险
• 建立数据使用内部规则
• 实施合规要求
• 改善内部和外部沟通
• 增加数据价值
• 方便数据管理
• 降低成本
• 通过风险管理和优化来帮助确保公司的持续生存

12.3. 方法

从技术实施角度看，数据治理包含“理”“采”“存”“管”“用”这五个步骤，即业务和数据资源梳理、数 据采集清洗、数据库设计和存储、数据管理、数据使用。

13.、数仓的作用

从上图可见，数据仓库包含来自许多操作源的数据有APP应用的数据，也有Oracle的数据。经过数仓以 后的结构它可用于分析数据，例如制作用户画像标签，推荐系统等。数据仓库不仅是分析工具，同时支 持跨多个部门的用户的决策和报告。也是档案，包含未在操作系统中维护的历史数据。

小结：为啥要懂数据仓库呢？

1. 因为需要我们产品经历设计的用户画像产品，推荐系统产品，自助报表产品，及其他可视化产品可 以通过数据仓库产品和模型更方便的读取。
2. 随着数据量从GB到TB再到PB甚至到EB、ZB的增大，如果不构建稳定干净能够快速可以利用的数据 仓库，对任何企业来说都是资产的损失。
3. 也许以后所以的产品经理都会成为数据产品经理，而对数据产品经理来说其核心技能是主导设计更 加优秀的数据仓库产品。

标签：数据仓库,业务,建模,DataWarehouse,维度,数据,事实
来源： https://blog.csdn.net/weixin_43660536/article/details/118770217