早在80年代，Inmon提出了“企业数据仓库”（Enterprise Data Warehouse，EDW）的概念。他强调了数据仓库应该是企业的中心数据存储，通过标准化建模和统一的元数据管理来实现一致性。这一理论奠定了数据仓库的基础，强调了对企业全局数据的集成和一致性，属于自顶向下建仓的经典范式。紧接着，在90年代初，Kimball提出了“维度建模”（Dimensional Modeling）的概念。他强调通过以业务过程为基础的维度模型来构建数据仓库，以更好地满足业务用户的需求。Kimball的方法注重快速开发和逐步构建，强调以业务需求为导向的建设过程，属于自底向上建仓经典范式。由于Inmon方法论和Kimball方法论建仓思想差异较大，在两种理论诞生之初就一直存在各种争论，直到如今，也没能真正分出两个思想哪种更好，更重要的是，建模方法近几十年也围绕这两种思想发展，并未出现更颠覆性的理论。相比于Inmon方法论首先强调数据集成性，需求周期长；Kimball方法论强调易用性，需求周期短的特点，目前被大部分数据仓库项目所采纳。

早期的ETL过程主要使用传统的关系型数据库技术和SQL语句，从源系统中提取、转换、加载数据到目标数据仓库。但是，这种方式受限于数据库性能和处理能力，难以处理大规模数据和复杂转换需求。随着大数据技术的兴起，ETL过程经历了重大变革。Hadoop和MapReduce等分布式计算模型使得处理海量数据成为可能。同时，Apache Spark等新兴的数据处理框架提供了更高效、更灵活的解决方案，显著提升了数据处理速度和效率。这些新兴的技术发展为更大规模的数据分析提供了可能。

而如今，实时数仓的出现变得日益必要。随着数字化转型的加速和数据产生速度的急剧增长，传统的批处理数据处理方式已经无法满足企业对实时数据分析和决策的需求。实时数仓的出现填补了这一空白，它能够在数据产生的同时进行实时的提取、转换和加载，使得企业可以及时获取最新的数据并进行实时的分析和洞察。这对于需要快速响应市场变化、进行实时监控和预测的行业尤为重要，例如金融、电商、物流等。实时数仓的建立不仅提升了数据处理的速度和效率，也使得企业能够更加灵活地应对竞争和挑战，更好地把握商机，实现持续创新和增长。因此，近年来实时数仓的出现已成为企业数字化转型的重要组成部分，对于提升企业的竞争力和战略决策能力具有重要意义。

一实时数仓架构目标

本节针对实时数仓目标从业务目标角度和技术目标角度进行详细分析。

一业务目标

实时数仓和离线数仓在服务业务目标上保持一致，均旨在支持决策分析需求。无论是实时数仓还是离线数仓，它们都致力于为企业提供即时、准确的数据分析和洞察，以帮助企业做出更加明智和迅速的决策。无论是在追踪市场趋势、优化运营流程还是实时监控业务状况方面，实时数仓和离线数仓都扮演着至关重要的角色。

二技术目标

模型目标

从数仓建模的角度来看，实时数仓和离线数仓在数据仓库建模上也需要保持一致。两者都需要依托于Kimball或Inmon等指导思想，以确保数据仓库的结构合理、易于理解和维护。Kimball的维度建模强调以业务过程为基础，将数据组织成易于理解的维度模型，适合于快速开发和逐步构建的需求。而Inmon的企业数据仓库理论则强调数据集成和一致性，通过标准化建模和统一的元数据管理来实现企业数据的一致性和准确性。由于目前离线数仓采用Kimball架构比较多，因此实时数仓建模也应该采用Kimball模型作为指导思想。

ETL 目标

在ETL目标方面，实时数仓和离线数仓存在明显的差异。离线数仓通常使用批处理方式进行数据提取、转换和加载，处理的数据量较大，但处理过程相对稳定。而实时数仓则需要实时地提取、处理和加载数据，因此需要更高效、更灵活的ETL手段，以确保数据的实时性和准确性。相比于离线数仓基于SQL实现，实时数仓则可能携带很多代码层面的开发，这种个性化的区别使得实时数仓开发和维护成为麻烦点。笔者更趋向于认同未来实时数仓ETL手段也要聚拢于SQL。

二实时架构演变过程

传统离线数仓架构是一种经典的数据处理方式，它主要通过批处理的方式来处理数据和进行分析。这种架构包括数据采集、数据存储、数据处理和数据查询等核心组件，数据加载以T+1批处理为主。

1 LAMBDA架构

Lambda 架构（Lambda Architecture）是由 Twitter 工程师南森·马茨（Nathan Marz）提出的大数据处理架构。这一架构的提出基于马茨在 BackType 和 Twitter 上的分布式数据处理系统的经验。

Lambda架构在原来离线数仓的基础上增加了一个实时计算的链路，并对数据源做流式改造（即把数据发送到消息队列），实时计算去订阅消息队列，直接完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。Lambda 架构使开发人员能够构建大规模分布式数据处理系统，它具有很好的灵活性和可扩展性。

Lambda 架构总共由三层系统组成： 批处理层（Batch Layer） ， 实时处理层（Speed Layer ），以及用于响应查询的服务层（Serving Layer） 。

Batch Layer:批处理层使用可处理大量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的，能够修复任何错误，然后更新现有的数据视图。输出通常存储在只读数据库中，更新则完全取代现有的预先计算好的视图。
```
batch view = function(all data)
```
Speed Layer:速度层通过提供最新数据的实时视图来最小化延迟。速度层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整，但它们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后，在速度层的数据就可以被替代掉了。
```
realtime view = function(realtime view, new data)
```
Serving Layer:BatchLayer通过对历史数据执行查询获得BatchView，SpeedLayer通过增量计算实时数据提供RealtimeView。Lambda架构的ServingLayer用于响应用户的查询请求，合并Batch View和Realtime View中的结果数据集到最终的数据集。
```
query = function(batch view, realtime view)
```

2 Kappa架构

Kappa 架构是由LickedIn 的 Jay Kreps 提出的，Kappa 架构通过专注于流处理，提供了 Lambda 架构的简化替代方案，核心思想是“一个数据流，一个处理方式”。它包含不可变数据流的概念，无需维护单独的批处理层。在 Kappa 架构中，所有数据都作为无限的事件流引入和处理。数据流经系统并进行实时处理，从而实现近乎即时的洞察力。

Speed Layer: 实时处理层提供接收和存储流数据的消息队列，数据可以在某个需要限度内全量存储，并在必要时从头开始读取重新计算，从而获得可靠结果。
```
realtime view = function(all data)
```
Serving Layer: 保存流处理层结果，提供实时查询服务(OLAP)。
```
query = function(realtime view)
```

三实时数仓架构

数据仓库设计灵魂是通过优秀的数据建模统一数据输出规范(详情请看笔者《数据仓库前台功能介绍》文章)，传统离线数仓如此、实时数仓亦是如此，同时也应该保持结构上离线数仓和实时数仓的统一。从结构层面实时数仓应该包含两个组成部分:Realtime Process和OLAP。

本节将根据笔者的数据仓库建设经验和技术理解介绍通用实时数仓架构，这种架构旨在实现对实时数据的高效处理和分析。

实时数仓架构重要特点如下：

架构分层与离线数仓一致；

数仓结构要足够简单，越是简单的结构越是稳定；

数仓结构统一是数仓最重要的属性之一；

开发规范&命名规范与离线数仓一致；

ETL逻辑统一SQL处理；

实时数仓处理逻辑应首选SQL实现，降低代码量；

幂等性、容错性和可恢复性；

实时数仓ETL要考虑到重做一致；

实时数仓要考虑健壮性；

实时数仓要考虑故障后的恢复成本；

1 数据仓库架构介绍

1) ODS层

ODS（Operational Data Store，原始数据存储）层是数据仓库架构中的一个重要组成部分，主要用于存储来自操作性系统的原始、细节级别的数据，完整的ODS层可以分解成两个部分，一个是接入数据组件，另一个是持久存储组件。ODS数据不对外提供服务。

接入数据：承接数据源数据，数据格式和数据类型与数据源保持不变；通过消息队列保存数据，数据直接对下游可见；
持久存储：原始数据备份，数据格式和数据类型与数据源保持不变，对下游不可见，涉及数据修复可回流接入数据区；

2) EDW层

EDW层存储通过清洗、转换和聚合后的结果数据，为企业提供一致、可信、高质量的数据集。通过将数据按照业务需求组织成维度模型，并提供多维分析能力，数据仓库层成为决策者获取深层次洞察、制定战略计划以及监控业务绩效的重要基础，推动企业智能决策和业务创新。完整的EDW层包含维度表部分和事实表部分两大组成元素，同时考虑复杂的数据集成及ETL场景，在EDW层要考虑集成层、临时区的设计，其中维度表部分可以细分为字典/码表部分和维表部分，而事实表又可以分为明细层、汇总层和视图层三个组成部分，这些预定义区域共同完成数据仓库的集成与服务工作。

集成层：用来保存复用率高，且没有对应明确业务过程的数据模型，他的主要作用是提前进行一定的ETL操作，降低下游的数据加工复杂度。
- 设计标准：非必要不设计。
- 作用域：面向数据工程师内部使用，不对外暴露数据。
DIM区：用来保存维度表模型，维度是数据仓库环境描述业务环境属性的模型，一般对应业务实体。这部分模型对外提供查询服务。
- 维度表：具备明确业务实体的，具有业务属性的模型。
- 字典/码表：存储转码表/字典数据。
FACT区：包含明细事实表和汇总事实表，不考虑计算非必要维度属性，以及未来得及设计且需求紧迫的直接针对ODS的视图实体，FACT数据均可对外提供查询服务。
- 明细层：包含了对业务过程中每个独立事件或事务的详细信息，捕捉了业务的原始细节。明细表的作用在于提供了对业务操作的全面、详尽的记录，为数据仓库提供了源头数据，不保存多余维度数据。
- 汇总层：是对明细层数据的上卷数据集。
- 视图层：明细事实表没有设计的数据，但需求依赖的数据，作为事实表妥协方案存在，针对ODS表直接原表直接接入OLAP供下游使用，视图表只是临时解决方案，长期规划要把视图表从ETL依赖中剔除掉。

3) ADS层

数据仓库ADS层是数据仓库架构中的重要组成部分，其主要功能在于提供直观、交互式的界面和工具，以便用户能够轻松访问、查询和分析存储在数据仓库中的数据。通过强大的报表生成、多维分析、数据挖掘和可视化工具，ADS层使业务用户能够快速获取关键业务指标、深入挖掘数据关系，从而支持决策制定、发现趋势并实现对企业数据的深入理解。这一层级的功能旨在使数据仓库的信息变得更加可视、可操作，为各级管理人员和业务分析师提供强大的工具，促进数据驱动的智能业务决策。

ADS层面向场景设计，聚拢场景，数据来自明细层&汇总层&视图层和维度表，设计要考虑场景可扩展性。

2 技术选型

这里会介绍几种常见的实时数仓技术选型方案，比如Doris架构和数据湖架构等常见方案，这里每个场景仅选取最热门、最适合的技术框架进行介绍，相关扩展服务请查阅其他资料学习。

1) 消息队列

Apache Kafka是一种流行的分布式消息中间件，被广泛用于构建实时数据管道和流处理应用。它具有高吞吐量、低延迟和水平可扩展性的特点。Kafka提供持久性、分区和副本机制，确保消息的可靠传递和高可用性。由于其与实时流处理引擎的集成紧密，如Apache Flink和Apache Spark，以及与Hadoop生态系统的整合，Kafka成为了构建实时数仓的首选消息中间件之一。

Apache Kafka可以用来承接接入数据，集成层，维度表，明细层，汇总层各层中间结果，用来支撑实时链路计算服务，其中维度表，明细层，汇总层结果数据也会考虑在存储引擎长期保存（集成层数据仅保存在消息队列，不需要落盘），以提供下游数据应用服务。

2) 计算引擎

Apache Flink是一种流行的实时数据处理引擎，被广泛应用于流式数据处理场景。它具有卓越的实时处理性能和低延迟特点，能够高效地处理无界数据流，并在保证高吞吐量的同时，实现较低的处理延迟。这使得Flink在实时数仓场景下能够快速、准确地处理大规模数据流，并及时输出结果。同时，Flink具有丰富的时间语义、可以支持处理时间和事件时间语义。Flink还提供了强大而灵活的状态管理功能。在实时数仓中，处理过程中产生的状态数据通常很大，Flink的状态管理机制能够高效地处理大规模状态数据，并保证状态的一致性和可靠性。这使得Flink能够处理复杂的实时计算逻辑，并支持窗口聚合、状态机管理等高级功能。不仅如此，Flink生态系统丰富，与多种数据存储和消息中间件（如Apache Kafka、Apache Hadoop、Elasticsearch等）集成紧密，能够满足不同实时数仓应用的需求。

最重要的一点是Apache Flink具有完善的SQL处理实时数据的能力，这使得离线数仓ETL过程和实时数仓ETL过程更相似，对于数仓开发及维护友好。而利用Flink要优先保证SQL实现业务逻辑，如果当前场景不支持，要考虑扩展SQL或者开发工具予以支持。

Apache Kafka可以用来承接集成层，维度表，明细层，汇总层，视图层，持久存储区装载和抽取等各层的业务逻辑处理过程，用来支撑ETL实现。

3) 数据存储

截止目前为止，用于支撑实时数仓的主存储引擎包括OLAP系列和Data lake系列；同时如果涉及到数据备份，还需要借助裸HDFS && DB系列；

1) OLAP

Apache Doris是一种流行的MPP引擎，被广泛应用在OLAP场景中。DORIS 能够通过并行处理和优化查询计划等技术实现高性能的数据查询和分析，即使在处理大规模数据时也能够快速地获取查询结果。由于采用了分布式存储和数据冗余备份机制，DORIS 具有高度的可靠性，能够在节点故障或数据丢失的情况下保证系统的稳定运行。其丰富的表引擎提供了OLAP建模的多种选择，同时他的物化视图和rollup功能又能提升查询性能。

Apache Doris可以用来承接维度表，明细层，汇总层，视图层各层的业务逻辑处理过程，用来支撑OLAP即时查询实现。

2) Data lake

Apache Hudi是一种流行的MPP引擎，被广泛应用在湖仓一体建设场景中。主要用于构建和管理大规模的数据湖，以存储和处理大量的结构化和非结构化数据。它提供了用于数据管理的特性，包括数据版本控制、增量数据处理、数据合并等功能。通过 Apache Hudi，用户可以实现将数据湖和数据仓库结合起来，从而实现更高效的数据管理和分析效率。Hudi 广泛应用于数据湖一体建设场景中，帮助用户构建和管理大规模的数据湖，满足数据湖中的数据存储、管理和分析需求。

Apache Hudi可以用来承接接入数据区，集成层，维度表，明细层，汇总层，视图层，持久存储区各层的业务逻辑处理过程，用来支撑数据仓库实现。

3) HDFS && DB

Apache Hadoop

Apache Hadoop是一种流行数据管理和资源调度框架，被广泛应用在数据领域。其HDFS是一款优秀的数据存储框架，被广泛用来存储海量数据的场景。HDFS 是 Hadoop 的分布式文件系统，用于存储大规模数据集。它将数据划分成多个块，并将这些块分布式存储在集群的多个节点上，以提供高容错性和可扩展性。

Apache Doris可以用来承接持久存储区数据备份功能，用来保存原始数据明细，方便数仓出现问题后的数据修复难度，同时也降低了消息中间件中的数据体量。
Apache Cassandra

Apache Cassandra 是一个高度可扩展、分布式的 NoSQL 数据库系统，设计用于处理大规模数据集的分布式存储和管理。

Apache Cassandra可以用来承接维度表功能，用于支撑Flink实时计算能力。
Redis

Redis是一个开源的内存数据结构存储系统，以其高性能、丰富的数据结构支持和多种特性而闻名。作为一种数据缓存和实时数据处理工具，Redis被广泛应用于互联网、移动应用和游戏等领域，为构建高性能、可扩展的应用程序提供了强大支持。

Redis可以用来承接维度表功能，用于支撑Flink实时计算能力。

四构建实时数仓一般化问题

1 模型扩展

维度与事实分离
1. 简化ETL：维度与事实分开装载，可以降低中间状态大小，同时降低维度表与事实表加工复杂度。
2. 数据模型清晰性：维度与事实分离可以使数据模型更加清晰和易于理解。
3. 灵活性与可维护性：维度与事实分离提高了数据仓库的灵活性和可维护性。因为维度表和事实表是独立的，所以可以分别对其进行修改、更新和扩展，而不会对整个数据模型产生影响。这样的设计使得数据仓库更容易适应业务需求的变化。
4. 数据一致性：维度与事实分离有助于确保数据一致性。维度表通常包含相对稳定的维度属性，而事实表包含的是变化的度量数据。将它们分开可以减少因维度属性变化而导致的数据不一致问题，提高数据的准确性和可信度。
5. 易于维护与更新：由于维度表通常包含相对静态的数据，如产品、客户等，而事实表包含的是变化的度量数据，如销售额、订单数量等，因此将它们分离可以使维护和更新变得更加简单和有效。
已有模型扩展
1. 在已存在维度表上通过添加字段扩展维度分析能力；
2. 新增事实与已有事实表粒度一致且业务属性相似，可以通过对已有事实表添加新列扩展事实；
3. 增加维度粒度不变的前提下，通过对现有事实表新增外键列，将新维度扩展到已存在事实表；
4. 通过向已有事实表添加维度列，将现有事实表透明扩展成粒度更细的事实表；
新增模型
1. 通过创建新的维度表扩展数据仓库分析能力；
2. 可以透明对现有维度进行拆分合并；
3. 通过拓展业务过程建模丰富分析事实；
4. 通过对已有业务过程进行模型类型扩展，创建新事实表提升业务过程分析性能和分析能力；
5. 通过灵活创建聚集事实表，提升数据仓库分析性能；

2 数据修复

数据备份
1. ODS原始数据留存必要性：对于数据仓库来说，数仓是保留历史的，但实际工作中会涉及到大量数仓历史指标修复场景，
状态复用
1. 合理设计状态可以保证数据流的健壮性；
2. 通过附流修复数据状态，提升运维效率；
3. 可以适当考虑状态的外部持久化存储，保持映射关系，分离状态与任务管理。
数据回溯
1. 合理设计任务的合并与拆分；
2. 上游触发，血缘传递；
3. 离线任务修复；

3 数据一致性

离线数仓与实时数仓一致性
1. 数据源一致性保证；
2. 业务处理逻辑一致性保证；
3. 数据质量监控及一致性校验；

如何保证离线数仓与实时数仓结合场景下的数据一致性语义
1. 明细模型一致
1. 使用离线数仓修复实时数仓历史数据

4 Replace与Update语义选择

数据模型的装载最终可以抽象成对数据的insert、update和delete的重放。不同的数据处理框架对DML的抽象实现略有不同，比如hive通过全表覆盖重写实现DML语义，而Clickhouse的mergetree通过insert实现DML语义；Hudi底层通过compaction通过行替换实现DML语义；Doris通过唯一主键,聚合模型及重复模型从不同的角度实现DML。对于实时数仓而言，合理设计数据装载语义就显得至关重要。在实时数仓加工领域，常见的数据处理抽象如下：

insert: 向下游模型不停的插入新数据，反向操作通过事实取反实现。
update：类似于RDBMS，通过主键对指定值进行替换实现；或者将一个update抽象成一个delete和一个insert变相实现。
delete：类似RDBMS，通过标识行删除声明不可见性，通过后台任务清理过期数据。

5 其他场景

迟到的事实

1. 延迟可接受，通过等待实现；

2. 延迟不可接受，通过附加逻辑处理，另一种思路是将延时数据打入延时消息队列，通过延时修复任务补偿迟到的数据；

迟到的维度

1. 实时数据丢弃，通过离线任务修复数据，保证最终一致性；

2. 延迟可接受，通过等待实现；

3. 延迟不可接受，通过附加逻辑处理，另一种思路是将延时数据打入延时消息队列，通过延时修复任务补偿迟到的数据；

五结语

笔者通过本文对构建实时数仓的一般性问题进行归纳总结，从数仓目标、实时架构演变(Lambda和Kappa)到实时数仓架构介绍，最后还对实时数仓构建的问题进行归纳，企图从整体到部分的脉络来描述实时数仓构建逻辑。由于笔者能力有限，肯定有地方整理尚不到位，如读者有更好的思路可以留言，好的方案笔者会及时采纳并更新到文档内容中，目标更多的帮助技术人员及解决企业对于构建数据仓库困惑。

后续笔者会整理基于具体技术选型的实时数仓架构方案，包括：

基于Flink和Doris构建实时数仓的《实时数仓架构(Doris)》
基于Flink和Hudi构建实时数仓的《实时数仓架构(Hudi)》

具体内容请持续关注博客更新。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/繁依Fanyi0/article/detail/526005

实时数仓之实时数仓架构(理论篇)

一 实时数仓架构目标

一 业务目标

二 技术目标

二 实时架构演变过程