企业数据仓库技术架构

数据仓库基本知识

什么是数据仓库

数据仓库简称数仓，其英文名为 Data Warehouse（简写为 DW 或 DWH）。按照数据仓库系统构造方面的领衔设计师 William H. Inmon 的说法，“数据仓库是个面向主题的、集成的、时变的、非易失的数据集合，支持管理者的决策过程”。这个简短而又全面的定义指出了数据仓库的主要特征。四个关键词，面向主题的、集成的、时变的、非易失的，将数据仓库与其他数据存储系统（如关系数据库系统、事务处理系统和文件系统）相区别。

• 面向主题的（subject oriented）：数据仓库围绕一些重要主题，如顾客、供应商、产品和销售组织。数据仓库关注决策者的数据建模与分析，而不是单位的日常操作和事务处理。因此，数据仓库通常排除对于决策无用的数据，提供特定主题的简明视图。
• 集成的（integrated）：通常，构造数据仓库是将多个异构数据源，如关系数据库、一般文件和联机事务处理记录集成在一起。使用数据清理和数据集成技术，确保命名约定、编码结构、属性度量等的一致性。
• 时变的（time-variant）：数据存储从历史的角度（例如，过去 5~10 年）提供信息。数据仓库中的关键结构都隐式或显式地包含时间元素
• 非易失的（nonvolatile）：数据仓库总是物理地分离存放数据，这些数据源于操作环境下的应用数据。由于这种分离，数据仓库不需要事务处理、恢复和并发控制机制。通常，它只需要两种数据访问操作：数据的初始化装入和数据访问。

数据仓库 VS 数据库

由于大多数人都熟悉商用关系数据库系统，将数据仓库与之比较，就容易理解什么是数据仓库。

联机操作数据库系统的主要任务是执行联机事务和查询处理，这种系统称做联机事务处理（Online Transaction Processing, OLTP）系统，它们涵盖了企业的大部分日常操作，如购物、库存、制造、银行、工资、注册、记账等。另一方面，数据仓库系统在数据分析和决策方面为用户或数据分析员提供服务，这种系统可以用不同的格式组织和提供数据，以便满足不同用户的形形色色的需求，这种系统称做联机分析处理（Online Analytical Process ing, OLAP）系统。

OLTP 和 OLAP 的主要区别概述如下：

• 用户和系统的面向性：OLTP 是面向顾客的，用于办事员、客户和信息技术专业人员的事务和査询处理。OLAP 是面向市场的，用于知识工人（包括经理、主管和分析人员）的数据分析。
• 数据内容：OLTP 系统管理当前数据，通常，这种数据太琐碎，很难用于决策。OLAP 系统管理大量历史数据，提供汇总和聚集机制，并在不同的粒度层上存储和管理信息，这些特点使得数据更容易用于有根据的决策。
• 数据库设计：通常，OLTP 系统采用实体一关系（ER）数据模型和面向应用的数据库设计，而 OLAP 系统通常采用星形或雪花模型和面向主题的数据库设计。
• 视图：OLTP 系统主要关注一个企业或部门内部的当前数据，而不涉及历史数据或不同单位的数据，相比之下，由于单位的演变，OLAP 系统常常跨越数据库模式的多个版本。OLAP 系统还处理来自不同单位的信息，以及由多个数据库集成的信息。由于数据量巨大，OLAP 数据也存放在多个存储介质上。
• 访问模式：OLTP 系统的访问主要由短的原子事务组成，这种系统需要并发控制和恢复机制。然而，对 OLAP 系统的访问大部分是只读操作（由于大部分数据仓库存放历史数据，而不是最新数据），尽管许多可能是复杂的查询。

OLTP 和 OLAP 的其他区别包括数据库大小、操作的频繁程度、性能度量等，详见下表。

特征	OLTP	OLAP
特性	操作处理	信息处理
面向	事务	分析
用户	办事员、DBA、数据库专业人员	知识工人（如经理、主管、分析人员）
功能	日常操作	长期信息需求、决策支持
数据库设计	原始的、高度详细	汇总的、统一的
数据	当前的，保证最新	历史的，随时间推移保持准确性
视图	详细的、一般关系	汇总的、多维的
工作单元	短的、简单事务	复杂查询
访问	读/写	大多为读
关注	数据进人	信息输出
操作	主键上索引/散列	大量扫描
访问记录数量	数十	数百万
用户数	数千	数百
数据库规模	﹤TB	≧TB
优先	高性能、高可用性	高灵活性、终端用户自治
度量	事务吞吐量	查询吞吐量、响应时间

数据仓库基本概念

数据仓库中的基本概念及其关系如下图所示：

• 业务板块：一个业务板块代表一条业务线，比如某集团公司下的电商业务和外卖业务，各自成为一个业务板块。
• 数据域：业务板块下可进一步划分数据领域，比如电商业务板块下包含交易域、仓储域等。
• 维度：维度建模由 Ralph Kimball 提出，主张从分析决策的需求出发构建模型，为分析需求服务。维度是度量的环境，是观察业务的角度，用来反映业务的一类属性。属性的集合构成维度，也可以称为实体对象。例如，在分析交易过程时，可以通过买家、卖家、商品和时间等维度描述交易发生的环境。
• 属性：维度的属性，是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键，比如买家的性别、职业等。
• 业务过程：业务过程是业务活动中不可拆分的事件，例如下单、支付和退款。
• 度量：在维度建模中，将度量称为事实，将环境描述为维度，维度是用于分析事实所需要的多样环境。度量通常为数值型数据，作为事实表的事实。
• 指标：指标分为原子指标和派生指标。原子指标是基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，是具有明确业务含义的名词，体现明确的业务统计口径和计算逻辑，例如支付金额。
  • 原子指标=业务过程+度量。
  • 派生指标=时间周期+修饰词+原子指标，派生指标可以理解为对原子指标业务统计范围的圈定。
• 修饰词：统计的业务范围，筛选出符合业务规则的记录（类似于 SQL 中 where 后的条件，不包括时间区间）。
• 时间周期：统计的时间范围，例如最近一天，最近 30 天等（类似于 SQL 中 where 后的时间条件）。
• 统计粒度：统计分析的对象或视角，定义数据需要汇总的程度，可理解为聚合运算时的分组条件（类似于 SQL 中的 group by 的对象）。粒度是维度的一个组合，指明您的统计范围。例如，某个指标是某个卖家在某个省份的成交额，则粒度就是卖家、地区这两个维度的组合。如果需要统计全表的数据，则粒度为全表。在指定粒度时，需要充分考虑到业务和维度的关系。统计粒度常作为派生指标的修饰词而存在。

数据仓库分层

数据仓库分层可以让数据结构更清晰，减少重复开发，并统一口径，一般来说自下而上分为三层：数据引入层（ODS，Operation Data Store）、数据公共层（CDM，Common Data Model）和数据应用层（ADS，Application Data Service）。

• 数据引入层（ODS）：存放未经过处理的原始数据至数据仓库，结构上与源系统保持一致，是数据仓库的数据准备区。主要完成基础数据引入到数据仓库的职责，同时记录基础数据的历史变化。
• 数据公共层（CDM）：包括维度层（DIM）、明细事实层（DWD）和汇总事实层（DWS），由 ODS 层数据加工得到。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总事实表。
  • 维度层（DIM）：基于维度建模理念思想，建立整个企业的一致性维度，降低数据计算口径和算法不统一风险。维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。
  • 明细事实层（DWD）：以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。明细事实层的表通常也被称为逻辑事实表，用于存放原子指标。
  • 汇总事实层（DWS）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标。汇总事实层的表通常也被称为汇总逻辑表，用于存放派生指标。
• 数据应用层（ADS）：存放数据产品个性化的统计指标，根据 CDM 和 ODS 层的数据加工得到。

各层之间的数据流向如下图所示。其中，DIM 层一般会同步到所有存储系统，ODS 层和 DWD 层通常会放在数据中间件中，供下游订阅使用，而 DWS 层和 ADS 层的数据往往会落地到在线存储系统中，下游通过接口调用来获取。

数据仓库技术架构

数据仓库自上世纪九十年代初出现，直到现在，其技术发展一直没有停止。特别是进入二十一世纪以来，随着大数据和云计算技术的兴起，其技术架构经历了几次大的升级，截止到目前仍然处于快速发展中。

传统数仓

这里把上世纪九十年代的数据仓库称为传统数仓，因其年代比较久远，技术架构完全过时，因此这里不再对其技术架构做详细介绍，只大概介绍一下其原理。

传统数仓采用离线批处理方式，定期从业务数据库同步数据，然后按批进行计算，结果存放到关系型数据库里。随着数据量的增长，单节点的关系型数据库难以满足存储和计算需求，因此出现了 MPP（Massively Parallel Processing）架构的数据库，典型的如 Grennplum。MPP 数据库将任务分解到多个节点上并行执行，每个节点使用本地数据来计算，最后将所有节点的结果汇总在一起。

大数据数仓

进入二十一世纪以来，随着各行各业数字化改革程度的不断加深，企业产生了越来越多的数据。传统数仓，即便使用了 MPP 数据库，也只能应对 TB 级别的数据，无法处理 PB 级别甚至更高的海量数据。此外，传统数仓只能处理结构化数据，然而企业中还存在大量半结构化和非结构化数据（比如图片、音视频等）需要处理。

随着 Hadoop 大数据技术的出现，鉴于其在处理海量数据方面的能力，大家很自然地会想到用其来构建数仓。Hadoop 生态中提供了众多的数据仓库构建工具，其中尤以顶层的 Hive 最为知名。Hive 最开始是 Facebook 开发出来，用于处理其海量日志数据的，后来 Facebook 将其捐献给了 Apache 软件基金会。经过多年的发展，Hive 已经发展得很成熟，成为企业构建数仓的首选。在没有 Hive 之前，处理数据必须开发复杂的 MapReduce 作业，但有了 Hive，只需要编写简单的 SQL，就可以实现 MapReduce 作业同样的功能。Hive 使用的查询语言为 HiveQL（HQL），跟 SQL 类似，因此只要熟悉 SQL，就能很快上手。基于 Hadoop 生态工具构建的数仓称为大数据数仓，由于 Hive 在其中的重要性，一般也称为 Hive 数仓。

Hive 数仓架构如下：

其中，Pig 是雅虎开发的用于简化 MapReduce 任务编写的工具，与 Hive 用途类似，只不过 Pig 是通过编写脚本而不是编写 SQL，其脚本语言为 Pig Latin。HBase 是一种 NoSQL 数据库，主要是为了弥补 Hive 在随机实时查询方面的性能问题。Hive 适用于批量读取，查询单条只能通过 MapReduce 任务扫表来实现，性能非常差，而 HBase 支持通过主键来快速查询。从图中可以看到，Hive 依赖 HDFS 来存储数据，以及 MapReduce 来处理数据，在某些场景下 Pig 可以作为 Hive 的替代工具，HBase 则用来提供数据实时访问。

Hive 数仓与传统数仓的对比如下：

	Hive 数仓	传统数仓
存储	HDFS，理论上可无限扩展	集群存储，存在容量上限。只能适应于数据量比较小的商业应用，对于超大规模、半结构和非结构化数据无能为力
执行引擎	有 MR/Tez/Spark 多种引擎可供选择	可以选择更加高效的算法来执行查询，也可以进行更多的优化措施来提高速度
使用方式	HQL（类似 SQL）	SQL
灵活性	元数据存储独立于数据存储之外，从而解耦元数据和数据	低，数据用途单一
分析速度	计算依赖于集群规模，易扩展，在大数据量情况下，远快于普通数据仓库，但复杂的关联交叉运算其速度很慢，宽表用 Hive 做比较低效	复杂查询性能高于 Hive，简单大规模查询性能较 Hive 弱
索引	低效，目前还不完善	高效
易用性	需要自行开发应用模型，灵活度较高，但易用性低	集成一整套成熟的的报表解决方案，可以较为方便的进行数据分析
可靠性	数据存储在 HDFS，可靠性高，容错性高	可靠性较低，一次查询失败需要重新开始。数据容错大部分依赖于硬件 Raid，软件角度不同产品差异较大
依赖环境	依赖硬件较低，可适应一般的普通机器	依赖于高性能的商业服务器，对 X86 服务器的配置统一性要求较高
价格	开源产品	商用比较昂贵

实时数仓

前面讨论的传统数仓和大数据数仓，都是通过定时任务按批处理数据，批处理任务调度周期一般为天（快的话可以做到小时级别），有比较大的延时，他们可以统称为离线数仓。在某些业务场景，比如监控报警、大屏显示，延时需要控制在分钟级甚至秒级，这种时候就需要实时数仓了。

实时数仓有两种典型架构，分别是 Lambda 和 Kappa。

Lambda 架构：

Lambda 架构在大数据数仓批处理层的基础上，增加了一个流处理层（也称为速度层）。批处理层处理今天之前的历史数据，延时以天计，但准确性高，计算逻辑和出错处理都比较简单，而流处理层处理当天实时数据，延时为分钟级或秒级，但容易出错，计算逻辑也比较复杂。注意，流处理层处理的当天数据，会在第二天被批处理层重新处理，这样即便流处理层计算有误，也会在批处理层被修正。

Lambda 架构兼顾了离线批处理和在线实时处理两种方式，适合以批处理为主，实时处理为辅的业务场景。这种架构的弊端在于，需要同时实现批处理和流处理两种方式，容易出现两边计算逻辑不一致，并且通常批处理和流处理使用的技术工具不同，在人员和技术上无法实现统一，造成冗余和浪费。

具体来说，Lambda 架构的痛点有：

1. 同时维护实时和离线两套引擎，运维成本高
2. 实时和离线两种处理需要维护两套框架不同但业务逻辑相同的代码，开发成本高
3. 数据有两条不同链路，容易造成数据的不一致性
4. 数据更新成本大，需要重跑链路

为了解决 Lambda 架构的问题，出现了批流一体的 Kappa 架构。

Kappa 架构：

Kappa 架构完全废弃了批处理层，即便是批处理也是通过消息队列回溯以流计算的方式来完成，这样就实现了批流一体，从而避免了冗余工作，并简化了技术栈。

但 Kappa 架构并非就是完美的，在实际落地时其痛点有：

1. 对消息队列的存储性能和稳定性要求高，消息队列的回溯能力不及离线存储
2. 消息队列中的数据有存储时效性，且当前无法使用 OLAP 引擎直接分析消息队列中的数据
3. 全链路依赖消息队列的实时计算，可能会因为数据的时序性导致结果不正确

湖仓一体

前面我们看到 Kappa 架构的痛点主要是因其使用的消息队列（比如 Kafka）在存储功能上的一些限制导致，那么是否存在一种存储技术，能够同时支持高效的数据回溯，数据更新，以及数据批流读写了？答案是数据湖。

什么是数据湖

数据湖是最近几年才兴起的一个概念，其在 Wikipedia 上的描述如下：

数据湖是一类存储数据自然/原始格式的系统或存储，通常是对象块或者文件。数据湖通常是企业中全量数据的单一存储。全量数据包括原始系统所产生的原始数据拷贝，以及为了各类任务而产生的转换数据，包括报表、可视化、高级分析和机器学习等。数据湖中包括结构化数据（通常来自于关系型数据库）、半结构化数据（CSV、日志、XML、JSON 等）、非结构化数据（Email、文档、PDF 等）和二进制数据（图像、音频、视频等）。

上面这段描述侧重于数据湖里存储的内容，站在实时数仓的角度，为了支持上层实时数仓构建，数据湖还需提供以下能力：

目前市面上有三大开源的数据湖方案，分别是 Delta Lake（Databricks 开源）、Apache Hudi（Uber 开源）和 Apache Iceberg（Netflix 开源）。其中 Iceberg 以自身独特的优势被越来越多开发者关注，其特点如下：

1. Iceberg 的架构和实现没有绑定到某一特定引擎，实现了通用的数据组织格式，利用此格式可以与不同引擎（Flink、Hive、Spark 等）对接。
2. Iceberg 拥有良好的架构和开放格式。相比于 Hudi、Delta Lake，Iceberg 的架构实现更为优雅，同时对于数据格式、类型系统有完备的定义和可进化的设计。
3. Iceberg 在数据组织方式上充分考虑了对象存储的特性，避免耗时的 listing 和 rename 操作，使其在基于对象存储的数据湖架构适配上更有优势。

什么是湖仓一体

对于企业来说，数据湖和数据仓库不是二选一，而是可以同时选择，数据仓库构建于数据湖之上，实现湖仓一体。湖仓一体架构下数据湖和数据仓库的关系如下：

1. 湖和仓的数据/元数据无缝打通，互相补充，数据仓库的模型反哺到数据湖，湖的结构化数据沉淀到数据仓库
2. 湖和仓有统一的开发体验，存储在不同系统的数据，可以通过一个统一的开发/管理平台操作
3. 数据湖与数据仓库的数据，系统可以根据规则自动决定哪些数据放在数仓，哪些保留在数据湖，进而形成一体化

基于数据湖的数据仓库架构

将前面 Kappa 架构中的 Kafka 消息队列替换成 Iceberg 存储之后，我们得到了新一代的湖仓一体架构：

注意图中批处理和流处理分别使用了 Spark 和 Flink，Spark 和 Flink 是当前批处理和流处理计算引擎的领头羊，虽然它们都在往批流一体化发展，但就目前来说还都不太完善和成熟。如果使用 Spark 或 Flink 之一就能满足企业的批流处理需求，那么完全可以选择其中一种。当然，未来也可能会出现其它更好的批流一体的计算引擎，得益于 Iceberg 的多引擎支持，对于企业来说切换成本会比较低。

具体来说，相比使用消息队列的 Kappa 架构，湖仓一体架构具有如下优点：

1. 可以解决消息队列存储数据量少的问题。无论数据湖底层存储是使用 HDFS，还是 S3、OSS 这样的对象存储服务，都能够存放海量数据。
2. DW 层数据支持 OLAP 查询。目前大部分的 OLAP 引擎都支持 HDFS 和对象存储，只需做一些简单适配就可以跟数据湖对接上。
3. 批流基于一套存储，因此可以复用一套相同的数据血缘、数据质量管理体系。
4. 支持 Update/Upsert，而消息队列（比如 Kafka）一般只支持 Append。实际场景中 DWS 层的数据很多时候都需要更新，DWD 层到 DWS 层一般会根据时间粒度和维度进行聚合，用于减少数据量，提升查询性能。假如原始数据是秒级数据，聚合窗口是 1 分钟，那就有可能出现某些延迟数据经过时间窗口聚合之后需要更新之前数据的需求。