数仓相关知识点/笔记（OLTP和OLAP）

现在实时数仓是一个非常火的趋势，最近开始逐渐了解一些数仓相关的东西，从基础的理论知识包括架构，算一个基础总结和学习记录吧。包括OLTP和OLAP，基础表和数据湖相关概念。不定期补充更新

---

联机事务处理OLTP和联机分析处理OLAP

关键词 日常处理 业务分析

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

联机事务处理OLTP（on-line transaction processing） OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。通俗的讲，就是对数据的增删改查等操作。业务类系统主要供基层人员使用，进行一线业务操作，通常被称为OLTP（On-Line Transaction Processing，联机事务处理）。

联机分析处理OLAP（On-Line Analytical Processing）是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。通俗的讲，就是对数据按不同维度的聚合，维度的上钻，下卷等。数据分析的目标则是探索并挖掘数据价值，作为企业高层进行决策的参考，通常被称为OLAP（On-Line Analytical Processing，联机分析处理）。

从功能角度来看，OLTP负责基本业务的正常运转，而业务数据积累时所产生的价值信息则被OLAP不断呈现，企业高层通过参考这些信息会不断调整经营方针，也会促进基础业务的不断优化，这是OLTP与OLAP最根本的区别

OLAP分类

可以分为ROLAP，MOLAP和HOLAP

• ROLAP： 使用关系型数据库或者扩展的关系型数据库来管理数据仓库数据，而OLAP中间件支持其余的功能。ROLAP包含了每个后端关系型数据库的优化，聚合，维度操作逻辑的实现，附件的工具以及服务等。所以ROLAP比MOLAP有更好的可伸缩性。 比较典型的ROLAP有mondrian, Presto(facebook)。目前阿里的DRDS也可以看作是ROLAP的框架

• MOLAP： 通过基于数据立方体的多位存储引擎，支持数据的多位视图。即通过将多维视图直接映射到数据立方体上，使用数据立方体能够将预计算的汇总数据快速索引。比较典型的MOLAP框架有kylin(apache), Lylin(ebay)、pinot(linkedin)和druid

也就是说MOLAP是空间换时间，即把所有的分析情况都物化为物理表或者视图，查询的时候直接从相应的物化表中获取数据， 而ROLAP则通过按维度分库，分表等方式，实现单一维度下的快速查询，通过分布式框架，并行完成分析任务，来实现数据的分析功能。MOLAP 实现较简单，但当分析的维度很多时，数据量呈指数增长，而ROLAP在技术实现上要求更高，但扩展性也较好。

• HOLAP： 混合OLAP结合ROLAP和MOLAP，得益于ROLAP较大的可伸缩性和MOLAP的快速查询。

---

数仓基础表

维度表：维度表可以看成是用户用来分析一个事实的窗口，它里面的数据应该是对事实的各个方面描述，比如时间维度表，它里面的数据就是一些日，周，月，季，年，日期等数据，维度表只能是事实表的一个分析角度。

实体表：实体表就是一个实际对象的表，实体表它放的数据一定是一条条客观存在的事物数据，比如说设备 ，它就是客观存在的，所以可以将其设计一个实体表。

事实表：事实表其实质就是通过各种维度和一些指标值得组合来确定一个事实的，比如通过时间维度，地域组织维度，指标值可以去确定在某时某地的一些指标值怎么样的事实。事实表的每一条数据都是几条维度表的数据和指标值交汇而得到的。

---

数仓分层

关键词 原始 处理 分析

分层有多种方法，但是可以抓住原始数据，加工后数据和分析指标数据

• 数据引入层ODS（Operation Data Store）：存放未经过处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的数据准备区。主要完成基础数据引入到MaxCompute的职责，同时记录基础数据的历史变化。
• 数据公共层CDM（Common Data Model，又称通用数据模型层），包括DIM维度表、DWD和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。
  • 公共维度层（DIM）：基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。

    公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。

  • 公共汇总粒度事实层（DWS）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。

    公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。

  • 明细粒度事实层（DWD）：以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。

    明细粒度事实层的表通常也被称为逻辑事实表。

• 数据应用层ADS（Application Data Service）：存放数据产品个性化的统计指标数据。根据CDM与ODS层加工生成。
• 

该数据分类架构在ODS层分为三部分：数据准备区、离线数据和准实时数据区。整体数据分类架构如下图所示。

数据仓库的概念

数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。 为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。

为什么要对数仓进行分层

1 把复杂问题简单化
将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。
2 数据结构清晰
每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复
3 提高数据的复用性
规范数据分层，通过的中间层数据，能够减少极大的重复计算，增加一次计算结果的复用性。
4 隔离原始数据
不论是数据的异常还是数据的敏感性，使真实数据与统计数据解耦开。

关于区分数据集市和数据仓库

数据集市：Date Market

早在数据仓库诞生之初，一同并存的就有数据集市的概念。
现在市面上的公司和书籍都对数据集市有不同的概念。
狭义上来讲数据集市，可以理解为数据仓库中为用户提供数据支撑的应用层，比如咱们前文说的ADS层。
广义上，数据集市，所有以主题划分的数据仓库中可供查阅的都可以成为数据集市，包括DWD,DWS,ADS层，甚至包括从hadoop中同步到RDS的数据都可以成为数据集市，
比如订单主题，我可以提供使用者，从明细，聚合统计，比率分析等全部数据，提供给某个部门查询。那么除了订单还有用户、商品、供应商等等主题分别可以供不同的人员部门使用，这都可以称之为数据集市。

 关于执行周期

大规模的数据往往无法通过一次或一个时间段计算完成，
比如我需要统计今年的总收入。那我们不希望把计算压力都集中在最后，要统计数据的时候才把全年数据进行计算。
我们要把计算压力分摊开，比如我们如果能提前把每个月的数据计算好，统计年的时候一加就可以了。要用月度或者周数据时候，就把每日算好的数据进行汇总。

所以作为离线数据我们计算的单位周期是日。
也就是每日进行一次计算，这样当日用户可以查看到截至前一日的数据的计算结果。

---

扩展 数据湖

Apache Hudi

Apache Hudi（简称Hudi）提供在DFS上存储超大规模数据集，同时使得流式处理如果批处理一样，该实现主要是通过如下两个原语实现。

• Update/Delete记录: Hudi支持更新/删除记录，使用文件/记录级别索引，同时对写操作提供事务保证。查询可获取最新提交的快照来产生结果。

• Change Streams: Hudi也支持增量获取表中所有更新/插入/删除的记录，从指定时间点开始进行增量查询。

   

上图说明了Hudi的原语，配合这些原语可以直接在DFS抽象之上解锁流/增量处理功能。这和直接从Kafka Topic消费事件，然后使用状态存储来增量计算临时结果类似，该架构有很多优点。

• 提升效率: 摄取数据经常需要处理更新（例如CDC），删除（法律隐私条例）以及强制主键约束来确保数据质量。然而由于缺乏标准工具，数据工程师往往需要使用批处理作业来重新处理整天的事件或者每次运行时重新加载上游所有数据，这会导致浪费大量的资源。由于Hudi支持记录级别更新，只需要重新处理表中更新/删除的记录，大大提升了处理效率，而无需重写表的所有分区或事件。

• 更快的ETL/派生管道: 还有一种普遍情况，即一旦从外部源摄取数据，就使用Apache Spark/Apache Hive或任何其他数据处理框架构建派生的数据管道，以便为各种用例（如数据仓库、机器学习功能提取，甚至仅仅是分析）构建派生数据管道。通常该过程再次依赖于以代码或SQL表示的批处理作业，批量处理所有输入数据并重新计算所有输出结果。通过使用增量查询（而不是常规快照查询）查询一个或多个输入表，从而只处理来自上游表的增量更改，然后对目标派生表执行upsert或delete操作，可以显著加快这种数据管道的速度，如第一个图所示。

• 更新鲜的数据访问: 通常我们会添加更多的资源（例如内存）来提高性能指标（例如查询延迟）。Hudi从根本上改变了数据集的传统管理方式，这可能是大数据时代出现以来的第一次。增量地进行批处理可以使得管道运行时间少得多。相比以前的数据湖，现在数据可更快地被查询。

• 统一存储: 基于以上三个优点，在现有数据湖上进行更快、更轻的处理意味着不需要仅为了获得接近实时数据的访问而使用专门存储或数据集市。

 Hudi表和查询类型

表类型

Hudi支持如下两种类型表

Copy On Write (COW): 使用列式存储格式（如parquet）存储数据，在写入时同步更新版本/重写数据。

Merge On Read (MOR): 使用列式存储格式（如parquet）+ 行存（如Avro）存储数据。更新被增量写入delta文件，后续会进行同步/异步压缩产生新的列式文件版本。

下表总结了两种表类型的trade-off。

Trade-off	CopyOnWrite	MergeOnRead
数据延迟	更高	更低
更新开销 (I/O)	高(重写整个parquet文件)	更低 (写入增量日志文件)
Parquet文件大小	更小(高update (I/0) 开销)	更大 (低updaet开销)
写放大	更低 (决定与Compaction策略)

查询类型

Hudi支持如下查询类型

快照查询: 查询给定commit/compaction的表的最新快照。对于Merge-On-Read表，通过合并基础文件和增量文件来提供近实时数据（分钟级）；对于Copy-On-Write表，对现有Parquet表提供了一个可插拔替换，同时提供了upsert/delete和其他特性。

增量查询: 查询给定commit/compaction之后新写入的数据，可为增量管道提供变更流。

读优化查询: 查询给定commit/compaction的表的最新快照。只提供最新版本的基础/列式数据文件，并可保证与非Hudi表相同的列式查询性能。

下表总结了不同查询类型之间的trade-off。

Trade-off	快照	读优化
数据延迟	更低	更高
查询延迟	COW: 与parquet表相同。MOR: 更高 (合并基础/列式文件和行存增量文件)	与COW快照查询有相同列式查询性能