数仓理论知识

一：数仓

1.数据处理方式

OLTP:联机事务处理 Normalized:规格化---固定的格式

OLAP:联机分析处理--低并发 denormalized:规范化--某种要求（格式不固定）

OLTP：

ETL:抽取（Extract）、转换（Transform）、加载（Load）

第一种类型是报表，用于计算与业务相关的统计信息。

第二种类型是即席查询，旨在提供特定问题的答案并支持关键业务决策。

　而在 OLAP 领域，又可以根据具体技术实现分为：

MOLAP（多维 OLAP）---不支持事务。MOLAP 是基于多维分析的 OLAP 系统，一般对存储有优化，进行部分预计算，查询性能最高，但查询灵活性有限制。MOLAP 将 OLAP 分析所用到的多维数据物理上存储为多维数组的形式，形成“立方体”的结构。Kylin 就属于 MOLAP 系统。

ROLAP（关系 OLAP）。ROLAP 是更偏向传统关系型的 OLAP 系统，ROLAP 又分为两类：一类是 MPP 数据库，另一类是 SQL 引擎。MPP数据库是完整的数据库，一般需要把数据导入到库中进行 OLAP 分析，入库时对数据分布进行优化，进而获得后期查询性能的提升，提供灵活的即席查询能力，但无法支持超大数据量的查询。SQL 引擎只提供 SQL 执行能力，不负责具体的数据存储。

HOLAP（混合 OLAP）---支持事务：把 MOLAP 和 ROLAP 两种结构的优点结合起来。例如 HTAP(HTAP = OLTP + OLAP)，典型代表 PingCAP 的 TiDB；再或者 HSAP(Hybrid Serving/Analytical Processing)，典型代表 Alibaba 的 Hologres。

2.数仓 vs 数据库

数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定的、反映历史变化、粒度的数据集合，用于支持管理决策。　

面向主题：数据仓库可以高效分析关于特定主题或职能领域（例如销售）的数据。

集成：数据仓库可在不同来源的不同数据类型之间建立一致性。从不同的数据源采集数据到同一个数据源，此过程会有一些 ETL 操作。（ETL:抽取（Extract）、转换（Transform）、加载（Load））

相对稳定 Non-Volatile：进入数据仓库后，数据将保持稳定，不会发生改变。数据入仓以后一般只进行查询操作，没有传统数据库的增删改操作。

反映历史变化：数据仓库分析着眼于反映历史变化。关键数据隐式或显式的基于时间变化。

粒度：一条记录所表达的业务细节

用于支持管理决策 ：帮助高层管理者或者业务分析人员做出商业战略决策或者商业报表。

3.数据建模流程

a.通用数据模型

正向工程是指从需求到数字应用建设的过程，而逆向工程是指从当前的数字应用反推背后的业务逻辑的过程。

概念数据模型：确定系统的核心以及划清系统范围和边界，类似建筑规划图；

逻辑数据模型：梳理业务规则以及对概念模型的求精，类似建筑设计图；

物理数据模型：从性能、访问、开发等多方面考虑做系统的实现，类似建筑施工图。

b.数据仓库模型

业务建模：确定业务

领域概念建模：确定实体

逻辑建模：完善实体，确定关系

物理建模：落地执行(E-R 建模,维度建模等)

4.关系数据模型(E-R 建模)

---1.难度大，需要对数据了如指掌 2.表与表之间关系复杂

a.

第三范式：属性不依赖于其它非主属性。（列不可再分+主键+外键）

=====================================

第零范式：存在 Map 或数组结构的一类表

c.逆第三范式化（解决查询过慢）:

通过增加冗余或重复的数据，来提高数据库的读性能（为了性能和读取效率违反范式化的原则），是一种以空间换时间的策略。例如，逆范式化可以减少JOIN 。

5. 维度数据模型(维度建模)

1）维度表

a.维度：观察数据的角度

b.维度表

维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。

维度的作用一般是查询约束、分类汇总以及排序等。

主键（唯一性）：

c.维度设计方法

第一步：选择维度或新建维度。作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。

第二步：确定主维表。此处的主维表一般是 ODS 表，直接与业务系统同步。

第三步：确定相关维表。数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。

第四步：确定维度属性。本步骤主要包括两个阶段，其中第一个阶段是从主维表中选择维度属性或生成新的维度属性；

第二个阶段是从相关维表中选择维度属性或生成新的维度属性。

d.维度统一

e.维度拆分

1）水平拆分（数据层面）

2）垂直拆分（维度属性层面）

f.维度设计原则

原则一：尽可能生成丰富的维度属性。　　

原则二：尽可能多地给出包括一些富有意义的文字性描述。属性不应该是编码，而应该是真正的文字。　　

原则三：区分数值型属性和事实。数值型字段是作为事实还是维度属性，可以参考字段的一般用途。如果通常用于查询约束条件或分组统计，则是作为维度属性；如果通常用于参与度量的计算，则是作为事实。所以需要同时参考字段的具体用途。　　

原则四：尽量沉淀出通用的维度属性。一方面，可以提高下游使用的方便性，减少复杂度；另一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不一致。　　

原则五：退化维度。维度属性也可以存储到事实表中，这种存储到事实表中的维度列被称为“退化维度”。也可以用来进行事实表的过滤查询、实现聚合操作等。

原则六：缓慢变化维。数据仓库的重要特点之一是反映历史变化.

第一种处理方式：重写维度值。不保留历史数据，始终取最新数据。　　

第二种处理方式：插入新的维度行。不能将变化前后记录的事实归一为变化前的维度或者归一为变化后的维度。　　

一般采用第二种+拉链法

2）事实表

事实表是指：该业务过程有关的维度引用（维度表外键）以及该业务过程的度量（通常是可累加的数字类型）。

a.事实：在维度建模中，通常表示某个业务的度量。如订单中商品的数量、金额等。

b.事实类型(指度量值的类型，而非事实表的类型):

可加性事实：可以按照与事实表关联的任意维度进行汇总。

半可加性事实：只能按照特定维度汇总，不能对所有维度汇总。

不可加性事实：完全不具备可加性，比如订单的优惠率，应该分解为订单原价金额与订单优惠金额两个事实存储在事实表中。

c.事实表：该业务过程有关的维度引用（维度表外键）以及该业务过程的度量（通常是可累加的数字类型）。

事实表的特征：表里没有存放实际的内容，他是一堆主键的集合，这些 ID 分别能对应到维度表中的一条记录。事实表包含了与各维度表相关联的外键，可与维度表关联。事实表的度量通常是数值类型(条/个/次)，且记录数会不断增加，表数据规模增长迅速。

d.事实表设计原则　

原则一：尽可能包含所有与业务过程相关的事实。　　

原则二：只选择与业务过程相关的事实。　　

原则三：分解不可加性事实为可加的组件。事实表确定事实时，往往会遇到非可加性度量，比如分摊比例、利润率等。对于不具备可加性条件的事实，需要分解为可加的组件。比如订单的优惠率，应该**分解为订单原价金额与订单优惠金额两个事实存储在事实表中。　

原则四：在选择维度和事实之前必须先声明粒度。粒度定义得越细越好，建议从最低级别的原子粒度开始，因为原子粒度提供了最大限度的灵活性，可以支持无法预期的各种细节层次的用户需求。　　

原则五：在同一个事实表中不能有多种不同粒度的事实。事实表中的所有事实需要与表定义的粒度保持一致，在同一个事实表中不能有多种不同粒度的事实。　

原则六：事实的单位要保持一致。

原则七：对事实的 NULL 值要处理。建议用 0 值填充。　　

原则八：使用退化维度提高事实表的易用性。通过增加冗余存储的方式减少计算开销，提高使用效率。

e.事实表设计方法

业务过程：不可拆分的行为事件，而且是基于分析目标进行选定的。

粒度：分析的范围，分析的细致程度。从数据表的角度来看，粒度则表示什么情况下增加一条记录。

维度：要进行分析的角度。

事实：描述客观事物的所有核心信息的所有数据的集合。

冗余维度：降低数据获取的复杂性，减少关联的表数量。

3)事实表分类

事务事实表和周期快照事实表:大部分情况会成对存在

事务事实表（粒度非常细）

总结

4）粒度

　分析的范围，分析的细致程度。从数据表的角度来看，粒度则表示什么情况下增加一条记录

5）拉链表

既维护历史状态，又存储了最新状态数据的表

a.缓慢变化维（SCD）

增加新行(历史拉链存储)---代理键

增加新属性

覆盖插入

从每天数据增量表中根据 dt 字段获取当天数据（新增和变化后的数据）；

将上一步查询的结果存入临时表 T，把开始日期置为当前日期（dt），结束日期置为最大日期；

将历史数据表中变化前和未变化的数据（历史数据表 LEFT JOIN T）存入临时表 H，并且要把变化前的数据的结束日期修改为当前日期（dt），即闭链；

将新增和变化后的数据（临时表 T）以及变化前和未变化的数据（临时表 H）覆盖插入（INSERT OVERWRITE TABLE）历史数据表中（H UNION ALL T），即开链。

　　

拉链表不是只能应用于维度表，事实表同样可以应用拉链表。

6. 数据组织类型

星型模型：

星座模型：基于多张事实表的，而且共享维度信息。

7. 数仓分层

DWS---S(服务)

DWS---宽表

分层优点：增强扩展性（解耦）,复杂的问题简单化,清晰数据结构,数据血缘追踪，减少重复开发，数据关系条理化，屏蔽原始数据的异常。

一：ODS 数据准备层：　　

数据运营层/原始数据层，也叫 ODS 层，是最接近数据源的一层，数据源中的数据，经过抽取、传输，也就是传说中的 ETL 之后，装入本层。

二：DW 数据仓库层：从 ODS 层中获得的数据会按照主题建立各种数据模。

1）DIM 公共维度层：　　

2）DWD ：明细数据层。该层一般保持和 ODS 层一样的数据粒度，并且提供一定的数据质量保证。对 ODS 层的数据进行清洗（去除空值，脏数据，和超范围数据），脱敏等操作。另外，在该层也会做一部分的数据关联，将相同主题的数据汇集到一张表中，提高数据的可用性，DWD 层是真正发力的层。DWD 层需构建维度模型，一般采用星型模型，最终呈现的状态一般为星座模型。

3）DWS/DWM/DWB 数据汇总层/数据中间层　　

DWS/DWM/DWB ：Data Warehouse Summary/Data WareHouse Middle/Data Warehouse Base，数据汇总层/数据中间层/基础数据层。该层会在 DWD 层的数据基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。如统计各个主题对象的当天行为，服务于 DWT 层的主题宽表，以及一些业务明细数据， 应对特殊需求（例如，购买行为，统计商品复购率）。直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。

4）DWT/DWS 数据服务层：　　

DWT/DWS ：数据主题层/数据服务层。以分析的主题对象为建模驱动，基于上层的应用和产品的指标需求，构建主题对象的全量宽表。（按照维度来决定分析者的角度，如用户→什么时间→下了什么单，支付了什么，购物车加入了什么）。一般来讲，该层的数据表会相对比较少，一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。

三.ADS 数据应用层：为数据产品提供可使用的结果数据。

8.数据仓库构建流程

指标

原子指标(粗粒度)：在 DWD 层（度量）。

派生指标：在 DWS、ADS 层。

复合指标/衍生指标：在 ADS 层。

9.ETL

抽取（Extract）、转换（Transform）、加载（Load）至目的端的过程。

第一个ETL：E-使用工具 T---此处为轻度的

第二个ETL：使用代码（Spark）T---此处为重度的

第三个ETL：使用SQL T---此处为业务逻辑转换

ETL 的处理分为五大模块，分别是：数据抽取、数据清洗、数据转换、规则检查、数据装载。

1）数据抽取:

确定数据源：需要确定从哪些源系统或源文件进行数据抽取；

定义数据接口：对每个源文件和源系统的每个字段进行详细说明；

确定数据抽取的方法：是主动抽取还是由源系统推送？是增量抽取还是全量抽取？是按照天抽取还是按照月抽取？

2）数据转换：从业务系统到 ODS 做清洗，将脏数据和不完整数据过滤掉，再从 ODS 到 DW 的过程中转换，进行一些业务规则的计算和聚合。

a.数据清洗：缺失值，异常值，不一致值，重复值

b.数据转换：不一致的数据转换，数据粒度的转换，业务规则的计算。

3）数据加载：

数据加载方式：全量加载，增量加载，事务性加载，批处理加载和流式加载。

数据加载策略：直接追加，直接覆盖，更新追加，历史表加载（建议）。

4）日志与告警

a. ETL日志:工具日志，执行过程日志，错误日志，总体日志。

b.警告发送

除了正常的 ETL 任务流程和调度系统外，还需要再有三大模块：ETL 运行情况监控、数据质量稽核、告警通知系统。

5)ETL 监控告警完整流程：

a.ETL 运行情况监控

b.数据质量稽核

c.告警通知系统

10.-----实战

实时离线一体架构

Maxwell: 用Java 编写的 MySQL实时抓取软件。实时读取MySQL 二进制日志 Binlog，并生成 JSON 格式的消息，作为生产者发送给 Kafka，Kinesis、RabbitMQ、Redis、Google cloud Pub/sub、文件或其它平台的应用程序。 Canal: 工作原理就是把自己伪装成 MySQL slave，模拟 MySQL slave 的交互协议向 MySQL master 发送 dump 协议，MySQL master 收到 canal 发送过来的 dump 请求，开始推送 binary log 给Canal，然后 Canal 解析 binary log，再发送到存储目的地，比如 MySQL，Kafka，Elasticsearch 等等

11.大数据平台

对海量数据从采集、存储、计算、应用、管理、运维的多方位、多维度的组合研究设计，从而建设合理、高效的大数据平台架构。

1）数据存储 & 计算

HDFS 是 Hadoop 提供的分布式存储框架，它可以用来存储海量数据，MapReduce 是 Hadoop 提供的分布式计算框架，它可以用来统计和分析 HDFS 上的海量数据，而 Hive 则是 SQL on Hadoop 计算引擎，提供了 SQL 接口，开发人员只需要编写简单易上手的 SQL 语句，Hive 负责把 SQL 翻译成 MapReduce，提交运行即可。　　

Hive 底层默认使用 MapReduce 作为执行引擎，执行效率并不高，为了解决这个问题，市面上出现了许多 SQL on Hadoop 的框架，目前主流的开源 OLAP 计算引擎包括：SparkSQL、Presto、Kylin等。这些框架的出现增加了数据计算层的多样性。

2）数据采集

Hadoop 框架自带的命令：HDFS API。

Sqoop：主要用于 Hadoop/Hive 与传统关系型数据库 Oracle/MySQL/SQLServer等之间进行数据交换的开源框架。就像 Hive 把 SQL 翻译成 MapReduce 一样，Sqoop 把你指定的参数翻译成MapReduce，提交到 Hadoop 运行，完成 Hadoop 与其他数据库之间的数据交换。

Flume：分布式的海量日志采集和传输框架，因为“采集和传输框架”，所以它并不适合关系型数据库的数据采集和传输。Flume 可以实时的从网络协议、消息系统、文件系统采集日志，并传输到 HDFS上。

DataX：DataX 是阿里云 DataWorks 数据集成的开源版本，在阿里巴巴集团内被广泛使用的离线数据同步工具/平台。DataX 实现了包括 MySQL、Oracle、OceanBase、SQLServer、Postgre SQL、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、Hologres、DRDS 等各种异构数据源之间高效的数据同步功能。

Debezium：CDC（Change Data Capture）工具，通过抽取数据库日志来获取数据变更。

FlinkCDC：底层封装了 Debezium 并进行了优化，因此 Flink CDC 可以充分使用和发挥 Debezium 的能力，并且可以无缝对接 Flink 使用其 SQL API 和 DataStream API 的能力，最终写入各种数据源。

FineDataLink：数据集成平台（简写：FDL），企业级一站式数据集成平台产品，拥有实时同步和离线计算两大引擎，具备实时数据同步、ETL 和 ELT 定时数据计算等核心能力。

StreamSets：大数据采集工具（支持实时/离线），数据源支持包括结构化和半/非结构化，目标源支持 HDFS，HBase，Hive，Kudu，Cloudera Search，ElasticSearch 等。它包括一个拖拽式的可视化数据流程设计界面，定时任务调度等功能。

3）数据应用（一些大型公司的）

4）离线 & 实时

DORIS:包含事务（删除和修改）

第一个的Spark 为SparkCore 第二个的Spark 为SparkSQ

实时离线一体架构

5）任务调度

　　调度监控系统是整个数据平台的中枢系统，类似于 App Master，负责分配和监控任务。像这样的框架常用的有DolphinScheduler、Azkaban、Airflow 等。

6）监控预警 & 元数据管理

需要对数据进行全方位的管理，包括数据监控、数据质量检测、元数据管理、血缘关系管理、异常处理、版本控制等。这里涉及到监控预警的平台有 Promethus、Grafana 等。

涉及元数据管理、血缘关系管理、数据标准管理等的数据治理平台有Altas、DataHub 等。

7）数据安全

任何人可以对集群做任何操作。所以我们需要对用户访问权限、数据资源权限管理、审计等作出控制。目前市面上也有这样的框架，例如 Apache Ranger、Apache Sentry 等。Ranger 提供了一个集中式的安全管理框架，用户可以通过操作 Ranger 控制台来配置各种策略，从而实现对 Hadoop 生态组件如 HDFS、Hive、HBase、YARN 等进行细粒度的数据访问控制。

8）云基础设施

大大降低复杂性并提高运行效率。例如云基础架构 K8S。

============================================================================

12.大数据架构

1）Lambda 架构

========================================================================

2）Kappa 架构

相当于在 Lambda 架构上去掉了批处理层（Batch Layer），只留下单独的流处理层（Speed Layer）。

Kappa 架构在选型上，消息队列常选择 Kafka，因为它具有历史数据保存和重放的功能，并支持多消费者。

　　而流处理集群，一般选择 Flink，因为 Flink 支持流批一体的处理方式，并且对 SQL 的支持率较高，所以可以尽量减少流处理和批处理逻辑代码不一致的情况，且 Flink 流处理引擎又解决了事件乱序下计算结果的准确性问题，保证了 EOS 语义。配合 Kakfa，流处理引擎以一个更早的时间作为起点开始消费，还起到了批处理的作用。

　　对于数据服务，依然是需要实时随机读写的数据库产品，常见的有 HBase、Druid、ClickHouse、Doris 等。

但使用 Kafka 作为消息队列时要注意，Kafka 因为消息是先存储到内存中，然后再落盘，所以可能会存在数据丢失的情况发生。如果需要金融级别的数据可靠性，使用 RabbitMQ 或者 RocketMQ 这种支持数据直接持久化到磁盘中的消息队列，可能是更好的选择，但相应的会牺牲数据实时性和吞吐量。

　

Lambda 架构通过批处理层和速度层的组合，兼顾了低延迟和复杂分析，但系统较复杂，存在数据冗余和延迟不一致问题。Kappa 架构只通过流式系统实现所有处理，简化了架构，但历史数据分析相对复杂，需要流式系统保证精确一次语义。