微鲤实时数仓建设方案及整体规划

一、实时数仓建设背景

1. 实时需求日趋迫切

目前公司的产品需求和内部决策对于数据实时性的要求越来越迫切，需要实时数仓的能力来赋能。传统离线数仓的数据时效性是 T+1，调度频率以天为单位，无法支撑实时场景的数据需求。即使能将调度频率设置成小时，也只能解决部分时效性要求不高的场景，对于实效性要求很高的场景还是无法优雅的支撑。因此实时使用数据的问题必须得到有效解决。

2. 实时技术日趋成熟

实时计算框架已经经历了三代发展，分别是：Storm、SparkStreaming、Flink，计算框架越来越成熟。一方面，实时任务的开发已经能通过编写 SQL 的方式来完成，在技术层面能很好地继承离线数仓的架构设计思想；另一方面，在线数据开发平台所提供的功能对实时任务开发、调试、运维的支持也日渐趋于成熟，开发成本逐步降低，有助于去做这件事。

二、实时数仓建设目的

1. 解决传统数仓的问题

从目前数仓建设的现状来看，实时数仓是一个容易让人产生混淆的概念，根据传统经验分析，数仓有一个重要的功能，即能够记录历史。通常，数仓都是希望从业务上线的第一天开始有数据，然后一直记录到现在。但实时流处理技术，又是强调当前处理状态的一个技术，结合当前各大厂的建设经验的建设现状，我们尝试把公司内实时数仓建设的目的定位为，以数仓建设理论和实时技术，解决由于当前离线数仓数据时效性低解决不了的问题。

现阶段我们要建设实时数仓的主要原因是：

• 公司业务对于数据的实时性越来越迫切，需要有实时数据来辅助完成决策；

• 实时数据建设没有规范，数据可用性较差，无法形成数仓体系，资源大量浪费；

• 数据平台工具对整体实时开发的支持也日渐趋于成熟，开发成本降低。

2. 实时数仓的应用场景

• 实时 OLAP 分析/交互式查询；

• 实时数据看板；

• 实时业务数据监控；

• 实时指标统计；

• 实时数据接口服务。

三、实时数仓架构设计

数据仓库概念是 Inmon 于 1990 年提出并给出了完整的建设方法。随着互联网时代来临，数据量暴增，开始使用 大数据工具 来替代经典数仓中的传统工具。此时仅仅是工具的取代，架构上并没有根本的区别，可以把这个架构叫做离线大数据架构

后来随着业务实时性要求的不断提高，人们开始在 离线大数据架构 基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，这便是 Lambda 架构。

再后来，实时的业务越来越多，事件化的数据源也越来越多，实时处理从次要部分变成了主要部分，架构也做了相应调整，出现了以实时事件处理为核心的 Kappa 架构。

1. Lambda架构

随着大数据应用的发展，人们逐渐对系统的实时性提出了要求，为了计算一些实时指标，就在原来离线数仓的基础上增加了一个实时计算的链路，并对数据源做流式改造（即把数据发送到消息队列），实时计算去订阅消息队列，直接完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。

Lambda架构特点：

• 在离线大数据架构的基础上增加新链路用于实时数据处理，需要维护离线处理和实时处理两套代码

• 针对实时数据使用流式计算引擎进行计算（例如Flink），针对离线数据使用批量计算引擎（例如Spark）计算。然后分别将计算结果存储在不同的存储引擎上对外提供数据服务。

• 同样的逻辑计算两次，整体资源占用会增多（多出实时计算这部分）

• 会使用到大量的组件来建设Lambda。例如：Hadoop、Hive、spark、Oozie、Flink、kafka、kudu等。而针对不同类型的组件去开发，非常麻烦。运维难度也很大。

2. Kappa架构

接下来要讲的这种架构，它是基于Lambda架构上的优化版本，Kappa架构。这种架构将数据源的数据全部转换为流式数据，并将计算统一到流式计算引擎上。批流合一，离线处理和实时处理整合成一套代码，运维成本小，这就是现今flink之所以火的原因。Kappa架构已成为数据仓库架构的新趋势。

这种方式的特点使架构变得更加简单，但是不足之处是需要保障数据都是实时的数据，如果数据是离线的话也需要转化为流式数据的架构进行数据处理，具体架构可结合这张图来看。

Kappa架构特点：

• Kappa 架构可以认为是 Lambda 架构的简化版（只要移除 lambda 架构中的批处理部分即可）

• Kappa 架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。

• 数据丢失的问题、数据乱序问题、Schema的同步与转换问题

• 遗留离线数仓数据的迁移问题

3. 混合架构

离线数仓是不断扩展的，大家普遍认知是离线数仓都是用来兜底的。而且，有很多的业务系统也需要依赖于离线数仓。要将成千上万的ETL作业迁往流处理系统，其工作量之大、成本之大、风险之大，几乎没有公司敢做这种一刀切的切换。

在真实的场景中，很多时候并不是完全规范的 Lambda 架构或 Kappa 架构，可以是两者的混合，比如大部分实时指标使用 Kappa 架构完成计算，少量关键指标（比如金额相关）使用 Lambda 架构用批处理重新计算，增加一次校对过程。

4. 深入实时数仓架构

实时数仓的查询需求

在正式讨论实时数仓前，我们先看下行业对实时数仓的主要需求，这有助于我们理解实时数仓各种方案设计的初衷，了解它是基于哪些需求应运而生的。

这也将帮助我们从更多维度上思考需求、条件、落地难点等等一些关键要素之间如何评估和权衡，最终实现是基于现有条件下的功能如何将其价值最大化。

传统意义上我们通常将数据处理分为离线的和实时的。对于实时处理场景，我们一般又可以分为两类：

一类诸如监控报警类、大屏展示类场景要求秒级甚至毫秒级；另一类诸如大部分实时报表的需求通常没有非常高的时效性要求，一般分钟级别，比如10分钟甚至30分钟以内都可接受。

基于以上查询需求，业界常见的实时数仓方案有这几种。

目前老的项目大部分还在使用的标准分层体现+流计算+批量计算的方案。未来大家可能都会迁移到标准分层体系+流计算+数据湖，和基于全场景MPP数据库实现的方案上。

方案 1：Kappa 架构

首先咱们看下Kappa架构，Kappa架构将多源数据（用户日志，系统日志，BinLog日志）实时地发送到Kafka。

然后通过Flink集群，按照不同的业务构建不同的流式计算任务，对数据进行数据分析和处理，并将计算结果输出到MySQL/ElasticSearch/HBase/Druid/KUDU等对应的数据源中，最终提供应用进行数据查询或者多维分析。

这种方案的好处有二，方案简单；数据实时。不过有两个缺点：

一个是用户每产生一个新的报表需求，都需要开发一个Flink流式计算任务，数据开发的人力成本和时间成本都较高。

第二个是对于每天需要接入近百亿的数据平台，如果要分析近一个月的数据，则需要的Flink集群规模要求很大，且需要将很多计算的中间数据存储在内存中以便多流Join。

方案 ２：基于标准分层 + 流计算

为了解决方案1中将所有数据放在一个层出现的开发维护成本高等问题，于是出现了基于标准分层+流计算的方案。

接下来咱们看下这种方案，在传统数仓的分层标准上构建实时数仓，将数据分为ODS、DWD、DWS、ADS层。首先将各种来源的数据接入ODS贴源数据层，再对ODS层的数据使用Flink的实时计算进行过滤、清洗、转化、关联等操作，形成针对不同业务主题的DWD数据明细层，并将数据发送到Kafka集群。

之后在DWD基础上，再使用Flink实时计算进行轻度的汇总操作，形成一定程度上方便查询的DWS轻度汇总层。最后再面向业务需求，在DWS层基础上进一步对数据进行组织进入ADS数据应用层，业务在数据应用层的基础上支持用户画像、用户报表等业务场景。

这种方案的优点是：各层数据职责清晰。缺点是多个Flink任务维护起来复杂，并且过多的数据驻留在Kafka集群内也会增大集群的负载，不支持upset操作，同时Schema维护麻烦。

方案 3：标准分层体现+流计算+批量计算

为了解决方案2不支持upset和schema维护复杂等问题。我们在方案2的基础上加入基于HDFS加Spark离线的方案。也就是离线数仓和实时数仓并行流转的方案。

这种方案带来的优点是：既支持实时的OLAP查询，也支持离线的大规模数据分析。但是带来了问题这样的几个问题。

数据质量管理复杂：需要构建一套兼容离线数据和实时数据血缘关系的数据管理体系，本身就是一个复杂的工程问题。离线数据和实时数据Schema统一困难。架构不支持upset。

方案 4：标准分层体系+流计算+数据湖

随着技术的发展，为了解决数据质量管理和upset 问题。出现了流批一体架构，这种架构基于数据湖三剑客 Delta Lake / Hudi / Iceberg 实现 + Spark 实现。

我们以Iceberg为例介绍下这种方案的架构，从下图可以看到这方案和前面的方案2很相似，只是在数据存储层将Kafka换为了Iceberg。

它有这样的几个特点，其中第2、3点，尤为重要，需要特别关注下，这也是这个方案和其他方案的重要差别。

1. 在编程上将流计算和批计算统一到同一个SQL引擎上，基于同一个Flink SQL既可以进行流计算，也可以进行批计算。

2. 将流计算和批计算的存储进行了统一，也就是统一到Iceberg/HDFS上，这样数据的血缘关系的和数据质量体系的建立也变得简单了。

3. 由于存储层统一，数据的Schema也自然统一起来了，这样相对流批单独两条计算逻辑来说，处理逻辑和元数据管理的逻辑都得到了统一。

4. 数据中间的各层（ODS、DWD、DWS、ADS）数据，都支持OLAP的实时查询。

那么为什么 Iceberg 能承担起实时数仓的方案呢，主要原因是它解决了长久以来流批统一时的这些难题：

1. 同时支持流式写入和增量拉取。

2. 解决小文件多的问题。数据湖实现了相关合并小文件的接口，Spark / Flink上层引擎可以周期性地调用接口进行小文件合并。

3. 支持批量以及流式的 Upsert(Delete) 功能。批量Upsert / Delete功能主要用于离线数据修正。流式upsert场景前面介绍了，主要是流处理场景下经过窗口时间聚合之后有延迟数据到来的话会有更新的需求。这类需求是需要一个可以支持更新的存储系统的，而离线数仓做更新的话需要全量数据覆盖，这也是离线数仓做不到实时的关键原因之一，数据湖是需要解决掉这个问题的。

4. 同时 Iceberg 还支持比较完整的OLAP生态。比如支持Hive / Spark / Presto / Impala 等 OLAP 查询引擎，提供高效的多维聚合查询性能。

方案 5：基于全场景MPP数据库实现

前面的四种方案，是基于数仓方案的优化。方案仍然属于比较复杂的，如果我能提供一个数据库既能满足海量数据的存储，也能实现快速分析，那岂不是很方便。这时候便出现了以StartRocks、ClickHouse、Doris为代表的全场景MPP数据库。

1. 基于Doris或者ClickHouse构建实时数仓。来看下具体的实现方式：将数据源上的实时数据直接写入消费服务。

2. 对于数据源为离线文件的情况有两种处理方式，一种是将文件转为流式数据写入Kafka，另外一种情况是直接将文件通过SQL导入ClickHouse集群。

3. ClickHouse接入Kafka消息并将数据写入对应的原始表，基于原始表可以构建物化视图、Project等实现数据聚合和统计分析。

4. 应用服务基于ClickHouse数据对外提供BI、统计报表、告警规则等服务。

四、业界实时数仓建设方案

介绍了这么多实时数仓方案，大厂到底用的那种方案呢？其实每个大厂根据自己业务特点的不同，也会选择不同的解决方案。下面简要分享下OPPO和滴滴的方案，以便大家能够更好地理解这篇分享中五种架构的具体落地。

不过具体架构细节不会进行过多的介绍，有了前面的内容基础，相信再通过架构图就能很快了解每个架构的特点。这里只是希望大家能够通过大厂的经验，明白他们架构设计的初衷和要解决的具体问题，同时也给我们的架构设计提供一些思路。

1. 滴滴顺风车实时数仓案例

滴滴数据团队建设的实时数仓，基本满足了顺风车业务方在实时侧的各类业务需求，初步建立起顺风车实时数仓，完成了整体数据分层，包含明细数据和汇总数据，统一了 DWD 层，降低了大数据资源消耗，提高了数据复用性，可对外输出丰富的数据服务。

数仓具体架构如下图所示：

从数据架构图来看，顺风车实时数仓和对应的离线数仓有很多类似的地方。例如分层结构；比如 ODS 层，明细层，汇总层，乃至应用层，他们命名的模式可能都是一样的。但仔细比较不难发现，两者有很多区别：

1. 与离线数仓相比，实时数仓的层次更少一些：

• 从目前建设离线数仓的经验来看，数仓的数据明细层内容会非常丰富，处理明细数据外一般还会包含轻度汇总层的概念，另外离线数仓中应用层数据在数仓内部，但实时数仓中，app 应用层数据已经落入应用系统的存储介质中，可以把该层与数仓的表分离；

• 应用层少建设的好处：实时处理数据的时候，每建一个层次，数据必然会产生一定的延迟；

• 汇总层少建的好处：在汇总统计的时候，往往为了容忍一部分数据的延迟，可能会人为的制造一些延迟来保证数据的准确。举例，在统计跨天相关的订单事件中的数据时，可能会等到 00:00:05 或者 00:00:10 再统计，确保 00:00 前的数据已经全部接受到位了，再进行统计。所以，汇总层的层次太多的话，就会更大的加重人为造成的数据延迟。

1. 与离线数仓相比，实时数仓的数据源存储不同：

• 在建设离线数仓的时候，目前滴滴内部整个离线数仓都是建立在 Hive 表之上。但是，在建设实时数仓的时候，同一份表，会使用不同的方式进行存储。比如常见的情况下，明细数据或者汇总数据都会存在 Kafka 里面，但是像城市、渠道等维度信息需要借助 Hbase，mysql 或者其他 KV 存储等数据库来进行存储。

2. OPPO的实时计算平台架构

其方案其实类似于方案2的基于标准分层+流计算。

3. 滴滴的大数据平台架构

它的方案其实类似于方案2的基于标准分层+流计算。

五、微鲤实时数仓建设方案

看过以上实时数仓的建设方案后，结合目前公司的业务应用场景及现有的大数据架构，可以考虑标准分层体系+流计算+数据湖的实时数仓建设，先看下现有大数据架构及其优缺点。

1. 现有数仓架构

迁移华为云后的大数据架构

实时链路

存在的问题

• 与离线数仓割裂，造成数据孤岛

• 中间数据查询困难，出现错误难以定位

• 整体链路比较复杂，中间数据在kafka，回滚数据困难

• 采用 Apache Kudu 则面临跟 HDFS 和云端对象存储脱节的尴尬

离线链路

存在的问题

• 离线数仓延迟过高，且批量从业务库拉取数据同步容易影响业务

• 使用组件过多，运维成本比较大

• 更新数据困难，引入了kudu解决更新问题，但大部分还是使用insert overwrite方式

• 实时链路的数据还需要离线T+1覆盖，资源浪费

• 存储不统一，数据在hdfs/obs、hbase、druid、kudu造成存储浪费

2. 规划中数仓架构

新架构需求

结合以上的痛点，我们需要进行数仓架构调整，我们的业务需求主要有以下几点：

1、支持 T+1 、小时级的批处理离线统计  
2、准实时需求 ，延迟可以在分钟级 （要求入湖端到端延迟控制在 1分钟左右）  
3、秒级延迟的实时需求 ，延迟要求在秒级  
4、存储成本低，存大量埋点和历史数据不肉疼  
5、能够快速查询湖仓中的数据（OLAP）  
6、部署升级简单，能快速迁移现有业务(或者与现有业务能够很快的集成)  
7、解决在 S3 中运行的 Hive 表的正确性问题(Hive表使用分区的中央元存储和单个文件的文件系统来跟踪数据文件。这使得对表内容进行原子更改是不可能的，并且由于使用列表文件来重建表的状态，最终一致的存储（如 S3）可能会返回不正确的结果)

结合业务需求，所以我们对存储和计算引擎的需求如下

1、较高的 CDC 摄入 及 更新能力  
2、支持 批写 、批读  
3、支持 流写 、流读  
4、端到端延迟 能够 在秒级  
5、支持 OSS 、S3、COS 等文件系统  
6、支持 OLAP 引擎  
7、社区活跃

数据湖技术选择

Apache Paimon

Apache Paimon 是一个支持高速数据摄取、变更数据跟踪和高效实时分析的流数据湖平台，底层存储利用 LSM 结构，支持多分布式存储系统，且兼容当下所有主流的计算引擎（Flink, Spark, Hive, Trino)，文件结构组织类似 Iceberg，相对 Hudi 来说更加简单和容易理解。  
同时涵盖了湖技术目前我们特别关注的几大特性：
    近实时高效更新
    局部更新
    增量流读
    全增量混合流读
    多云存储支持
    多查询引擎支持
    特别的Lookup能力
    CDC摄入（进行中）
    结构演进（进行中）

Apache Hudi

Apache Hudi 核心特性  
使用快速、可插入索引进行更新、删除
增量查询、记录级变更流
事务、回滚、并发控制
来自 Spark、Presto、Trino、Hive 等的 SQL 读/写
自动文件大小调整、数据聚类、压缩、清理
流摄取、内置 CDC 源和工具
用于可扩展存储访问的内置元数据跟踪
向后兼容的模式演变和执行

Apache Iceberg

Apache Iceberg 核心特性  
通用化标准设计
    完美解耦计算引擎
    Schema 标准化
    开放的数据格式
    支持 Java 和 Python
完善的 Table 语义
    Schema 定义与变更
    灵活的 Partition 策略
    ACID 语义
    Snapshot 语义
丰富的数据管理
    存储的流批统一
    可扩展的 META 设计支持
    批更新和 CDC
    支持文件加密
性价比
    计算下推设计
    低成本的元数据管理
    向量化计算
    轻量级索引

github现状

版本支持

优缺点汇总

选择paimon的原因

• 1、基于LSM ，具有很高的更新能力，默认的 Changelog 模型可以处理 CDC 采集的变更数据（实测入湖端到端延迟能控制在 1分钟左右）。另外Paimon 支持 Append Only 模型，可以覆盖没有更新的日志场景，该模型在写入和读取时不用耗费资源处理更新，可以带来更高的读写性能和更低的资源消耗。

• 2、支持 批写 、批读 ，并且支持 （Flink、Spark、Hive 等多种批处理引擎）

• 3、支持 流写、流读 （结合Flink 的批处理，我们希望后期能够建设流批一体的数据仓库）

• 4、Paimon 支持将一张表同时写入 Log System(如 kafka) 和 Lake Store (如 OSS 对象存储），结合 Log System 可以覆盖秒级延迟的业务场景，并且解决了 Kafka 不可查询分析的问题

• 5、支持 OSS 、S3、COS 等文件系统 ，且支持 FileSystem catalog ，可以完全与 Hadoop 、Hive 解耦

• 6、支持 Trino、presto OLAP 引擎。另外，Apache Doris、Apache Impala 已经开始对接 Paimon格式，相信不久之后Paimon的OLAP生态会更加丰富。

• 7、社区活跃，从2022年初开源 至 2022下半年，短短几个月，就已经发布几个大版本。0.3 的功能已经非常足够落地去解决一些生产问题，0.4 近期也快发布。

• 8、支持读取表快照的选择(Paimon supports time travel for Flink and Spark 3 (requires Spark 3.3+).)。

  虽然起步晚，但是后发优势非常明显，且没有历史包袱，抽象解耦非常合理。相比 Hudi等设计之初就捆绑 Spark 的背景，Paimon 一开始就定位支持多引擎，所以未来的潜力和扩展空间是巨大的。

结合数据湖新架构

3. 升级数据湖架构整体规划

整体升级计划华为云不支持，目前华为云数据湖方案只有hudi，并且要迁移现有MRS集群(需要先新建一个集群，把数据迁移过去，在下线老集群)，迁移代价比较大(两集群共存费用，所有业务迁移的人工成本)。

目前思路是自行搭建以paimon为核心的数据湖方案，只需要对mrs集群现有组件做一定的改造，业务可以慢慢迁移测试没问题再下线业务不会对业务造成影响，没有额外成本(有一些迁移时数据存储的成本)。整体迁移后测试下点查性能是否满足业务需求，满足即可和业务配合下线hbase集群。

• 历史数据如何迁移、现有任务如何迁移(考虑迁移实时任务，改造离线T+0任务，离线T+1任务不动)

• 可不可以替代hbase，尝试点查性能以及业务应用方面需要如何改造(目前有接口服务、wolves数据查询等、实时任务的去重等中间状态存储)

• 可不可以替代druid，druid作为一个实时分析型数据库(大多数查询场景为聚合查询和分组查询)，目前在业务方面实时、离线任务都有在跑，应用方面暂时不太清楚

• 现有组件spark2.x、impala3.4对paimon的支持不太好，需要考虑组件的升级

下线组件

• kudu

• hbase(待测试)

• druid(待测试)

• impala(要看后面支持的版本如何)

新增组件

• paimon(jar包方式管理)

• Presto/Doris/StarRocks(OLAP查询引擎)

数据湖方案改造计划

• 第一阶段：引入paimon，测试埋点数据、业务库(flink cdc)写入性能

• 第二阶段：迁移部分现有任务，老任务可随时恢复，线上环境验证paimon各种问题

• 第三阶段：迁移所有现有业务，完成整体实时数仓方案建设改造

六、总结

本文通过调研业界主流实时数仓建设方案，大致梳理了几种可行的离线数仓到实时数仓的改造措施：

• Kappa 架构，如Flink + HBase/Redis/Mysql：流计算 += 准确的实时预处理。

• 基于标准分层 + 流计算，如Flink + Kafka + Mysql/Redis，基于kafka数据分层，中间数据查询困难。

• 标准分层体现+流计算+批量计算，如Flink + OLAP：流计算 += 实时数仓，预处理和成本的权衡，高性能 OLAP 带来了一定的灵活度。

• 标准分层体系+流计算+数据湖，如Flink + 数据湖：流计算 += 离线数仓部分实时化。

• 基于全场景MPP数据库实现，如Flink + Doris/StarRocks，存储成本比较高的简易实时数仓

基于公司业务需求，微鲤实时数仓建设方案比较适合标准分层体系+流计算+数据湖，离线数仓到实时数仓的改造大致分为三个阶段去实施，当然未来我们希望达到以下目标：

1、数据全链路实时流动，同时沉淀所有数据，提供 AD-HOC 查询。

2、通用的离线数据实时化，流批融合的一套数仓

参考

Apache Paimon | Apache Paimon

Hello from Apache Hudi | Apache Hudi

Apache Iceberg

尘锋信息基于 Apache Paimon 的流批一体湖仓实践 (qq.com)

巴别时代基于 Apache Paimon 的 Streaming Lakehouse 的探索与实践 (qq.com)

Apache Paimon 在同程旅行的探索实践 (qq.com)

实时数仓方案五花八门，实际落地如何选型和构建！ - 腾讯云开发者社区-腾讯云 (tencent.com)

实时数仓之 Kappa 架构与 Lambda 架构（建议收藏！） - 知乎 (zhihu.com)

数据湖技术选型参考51CTO博客数据湖技术选型

作者介绍

• 徐伟奇 大数据开发工程师