Hologres + Flink 流式湖仓建设

1 Flink + Hologres 特性

holo在实时数仓领域非常受欢迎，一般搭配flink+hologres来做实时数仓，中间分层用holo，上下游一般依赖于holo的binlog来下发数据

1.2 实时维表 Lookup

Hologres 作为 Flink 的实时维表，相比其他维表具有以下优势：

• 维表百万 RPS 查询。

通过 Hologres 行存表主键点查的能力，支持非常高 RPS 的查询，更容易达到百每秒百万单次查询，我们内部存在一些业务甚至可以到达几千万和上亿次的查询。

• 维表实时可更新。
  可以实现更新维表及其中的一部分字段，降低运维难度，提升效率。

• 支持1对N点查（Prefix Scan）。
  不仅支持一对一查询，更支持一对多查询。例如我们在保险客户里面，需要根据身份证查询有哪些保单，一个人可能会对应多张保单，这种一对 N 的查询 Hologres 可以非常友好的支持。

• 支持 InsertIfNotExist。
  在一般维表进行查询时，查到就返回，查不到就返回空，但通过这个能力，Hologres 可以做到在查询不到数据时插入一则数值，再把插入值返回。这个功能可以用来玩转流量分析场景的精确 UV 查询，通过 RoaringBitmap 画像方案，让千亿级别的画像分析从分钟级缩减到秒级。

1.3 高性能实时写入与更新

Flink 可以高性能实时写入 Hologres，数据写入即可查，右边是我们一年前的实测数据，可以看到在 128CU 的配置下，当写入表无主键，大概每秒钟能写 230 万条；当写入表有主键，主键冲突丢弃新行，每秒写入可达 200 万条；一般来说，表更新需要反查，那会随着数据量增大，更新性能会下降，Hologres 对已经拥有 20 亿条数据的表做更新，也能达到每秒钟 70 万条的更新性能。这种实时写入与更新的性能，非常合适结合 Flink 实现大量的更新和删除。

Hologres 具有很强的更新能力的同时，还支持宽表的局部列更新，在一定程度上替代 Flink 的多流 Join，于此同时，也针对更深的业务场景做了一系列细致的优化，满足业务更深入细致的需求。例如业务的上游数据有时候是乱序的，1 点钟生产数据与 1 点 05 分也会生产数据，我们希望 1 点 05 分生产的数据覆盖之前的数据，因为数据从业务时间上来说，肯定是希望后面的数据覆盖前面。但是因为整个计算链路的不确定性，它会使得有可能 1 点 05 分这个数据先到，1 点钟那个数据后到的，如果直接盲写就会变成把 1 点钟的数据覆盖了 1 点 05 分的数据。但 Hologres 在这种情况下不会做这个覆盖，即使上游乱序了，也能存储到最新的数据，保证上下游数据的一致性。

最后在 Flink 还未发布的 1.19 版本，Hologres 引入了一种称之为叫 Fixed Copy 的写入模式，这个模式相比于现在的写入模式，写入性能会更好，CPU 资源也省出更多。

Hologres 的存储架构基于分布式存储系统，并在其上构建了存储引擎。在底层，Hologres 使用了分布式存储系统来管理数据的存储和分布。在此之上，存储引擎包括一些关键组件，如 Block Cache、Shard ,每个 Shard 中包含了多个 Tablet 和 Write-Ahead Log（WAL）。

市面上主流的数据湖产品通常采用 LSM（Log-Structured Merge）架构。

主流数据主键模型更新模式有 Copy On Write 和 Merge On Read，这两种场景都有各自的问题：

• Copy On Write 具有写放大的问题，数据的延迟会比较高。
• Merge On Read（读时合并）模式在读取数据时需要进行大量的数据合并操作，因此读取性能可能较差。

在 Hologres 中，行存使用 Merge On Read 方式，列存主要基于 Merge On Write。

下面主要介绍下在基于 Merge On Write 这种模式时，一条数据在进入 Hologres 中，它首先到达 WAL Manager（Write-Ahead Log 管理器），同时也会进入到 Memtable（内存表）。在 Memtable 中，主要存储三类数据：数据文件、删除标志文件（例如基于 RoaringBitmap 的文件）和索引文件。当 Memtable 数据积累到一定阶段后，会生成不可变的 Memtable，并通过异步线程定期将其刷新（flush）到 Data File（数据文件）中。通过这种架构，Hologres 能够兼顾行存和列存的优势，并通过适当的数据合并策略来提高性能和存储效率。

1.4 多流合并

除了刚刚维表 Join 以外，在流计算里面另一个痛点就是双流 Join，如果每一路都要保证完整的状态，从理论上来说，它就是一个成本很高的事情。我们这个方案并不是完全替代双流 Join，而是对于例如用户画像场景，有一个明确的 ID，然后希望基于这一个已有的 ID 去关联若干流的数据。在这种场景下，Hologres 就可以很简单的替代掉双流 Join，来实现一个更低成本的这样一个关联。

在画像场景里，我们要描述一个用户的画像或者一个商品的画像，有很多个维度，例如说一个用户，他的浏览习惯是什么，他的履约习惯是什么，他的退货习惯是什么等等，可以从各种维度去看这个客户，然后我们要去给用户画一个画像，判断他到底属于哪一类用户。进行分类的时候，首先我们肯定希望知道这个用户的所有信息，会以用户 ID 作为粒度，把所有用户的信息全部放在一起，然后交给一个分类器去分类，判断这个用户到底属于哪一类，这就是用户画像的一种很经典的用法。

在没有 Hologres 产品加入之前，只能是 Flink 做双流 Join，用 Flink 形成这样一个宽的表，不同的维度有着不同的字段。但加入 Hologres 后，等于在 Hologres 里面建一张宽表，这张表里面它的主键就是用户 ID，然后不同的 Flink 任务去写不同的字段。这并不是指一个任务去写所有整一行，是指每个任务仅仅写各自的几个字段，同一张表有着不同字段，这样的话利用 Hologres 局部更新能力，相当于自动把用户的不同维度数据关联在了一起。

有了以上表现，Hologres 相对其他数仓产品比较有优势的一点是还支持了 Binlog。在这张宽表里面任何一个字段发生变化了以后，我们的 Binlog 里会把整个这一行的数据都给它吐出来，并在 Binlog 里显示出来，Flink 再去对接这个 Binlog，这时就知道这一行的最新情况是什么，可以为这个用户重新去计算画像。

1.5 Hologres 作为 Flink 的数据源

类似于传统数据库 MySQL 中的 Binlog 概念，Binlog 用来记录数据库中表数据的修改记录，比如 Insert/Delete/Update 的操作。在 Hologres 中，表的 Binlog 是一种强 Schema 格式的数据，Binlog 记录的序列号（BigInt），在单 shard 内单调递增，类似于 Kafka 中的 Offset 概念。通过 Flink 消费 Hologres Binlog，可以实现数仓分层间的全链路实时开发，在分层治理的前提下，缩短数据加工端到端延迟，同时提升实时数仓分层的开发效率。如上讲的画像分析场景，可以利用 Hologres 的逐步更新能力，加上 Flink 订阅 Hologres Binlog，可实现一个非常实时的用户画像分析，极大的降低分析成本。同时，当 Hologres 作为 Flink 的源表，Flink 通过流和批的模式都可以把这张表数据读出来。并且还可以自定义它的变化，例如全增量一体化读取，或者存量部分可以只读增量。

1.6 元数据自动发现与更新

Hologres 同时也对接了 Flink 的 catalog，直接可以读取元数据，Flink 的 create table as 和 create database as 这些语法，包括 schema evolution 都可以很好的适配。

2 传统实时数仓分层方案

2.1传统实时数仓分层方案 1：流式 ETL

第一种最经典的数仓分层方案是经过 Flink 加工后交给 Kafka，每加工一层就交给 Kafka，然后通过 Flink 再加工写到下一层 Kafka，写到最后通过 Flink 计算写到一个 KV 引擎对外提供服务，大家有时候不认为这是数仓分层，因为没有看见仓的概念，只存在一层层数仓数据加工。

Flink+Kafka 的方案有个很严重的问题：每一层 Kafka 数据就是给 Flink 用，它几乎不能执行其他事情，当然可以说用 Presto 对接一下 Kafka 的数据源，然后去查询数据是否出错是可以的，但也就存在这点用处。所以一般大家的做法就是在下面再接一个实时数仓，把所有的中间数据再同步一遍到实时数仓里，大家要查询数据分析数据，请用实时数仓，然后 Flink 消费就用 Kafka，这是一个经典架构，也非常成熟。但它的不足之处在于：各种同步数据要存两份，资源消耗很大，整个处理链路也很复杂；中间数据 Kafka 出了问题不便于排查，数据订正都比较麻烦。有时上游想要加上字段，下游需要更改更多的字段，不易响应 schema 动态变化。

2.2 传统实时数仓分层方案 2：定时调度

第二个方法就是用离线的方法：Flink 负责数据的清洗关联，清洗后的明细数据实时写入实时数仓形成 DWD 层，再由高频调度（分钟级别）构建 DWS/ADS 层，实现分钟级增量更新。

这样的好处是方案成熟简单，成本较低。但它的不足之处就是时效性差。因为 Flink 写进的数据是实时的，但是调度任务其实很难做到很高频调度，因为再往下做调度，比方 5 分钟的调度，实现的技术难度就一下子上去了。而数据量大时，5 分钟可能无法跑完数据，只能增量调度，将会更加计算复杂。所以许多用户在实际使用时候往往选择小时级别调度，实时数仓反而退化成了准实时数仓。

2.3 传统实时数仓分层方案 3：物化视图

第三种是物化视图的方案。其实本质上来说是前面两个方案的一个结合，Flink 负责数据的清洗关联，清洗后的明细数据实时写入实时数仓形成 DWD 层。在实时数仓内通过物化视图来加工 DWS 或者 ADS。现在大家各自提供的产品能力，基本都以批量物化方式运行，本质上是将调度任务内置化。Hologres 现在也在做实时的物化，在集团内已经在使用了，后续会开放到公共云，但这种实时物化视图对于技术的挑战还是比较较大的。

对于以上 3 种数仓分仓方案分析后，如果通过 Hologres 将 Kafka 全部替换，并使用行列共存本进行存储，就可以实现了数据在 Flink 和 Hologres 之间的传输。在统一了架构基础上，数仓每一层的数据都可以被查询和修改，并利用 Flink 和 Hologres 的资源强隔离能力，整套系统在生产环境中是高可用的。下面介绍基于 Flink+Hologres 的 Streaming Warehouse 方案详细内容。

3 Hologres+Hologres 的 Streaming Warehouse 方案

我们将全部的 Kafka 换成 Hologres，将 KV 也替换成 Hologres，整个链路中，数据从 Flink 写进来以后就可以直接传入 Hologres 里。行列共存表同时会存两份数据，一份行存，一份列存，他们两份是强一致的，没有任何额外的管理开销，甚至性能有些场景还会提升一点。相比之前 Kafaka 架构，Flink+Hologres 具有以下优势：

• 解决传统中间层 Kafka 数据不易查、不易更新、不易修正的问题，每一层都可查、可修正。

• 中间层数据不仅供 Flink 消费，所有人都可查其数据，甚至同时可以直接对外提供服务，对接 OLAP/ 在线服务等消费。

• 架构统一，减少运维成本，增加业务效率，并且模型统一。
  
  基于 Flink+Hologres 的 Streaming Warehouse 方案，实时数仓 Hologres 主要提供了三大核心能力：

• Binlog，支持表更新事件的 Binlog 透出能力，通过 Flink 消费 Hologres Binlog，实现数仓层次间全链路实时开发，满足分层治理的前提下，缩短数据加工端到端延迟。

• 行列共存，实现了数据在 Flink 和 Hologres 之间的传输，并使每一层的数据可以被查询和修改。

• 资源强隔离，在多种计算之间资源隔离，实现写入和读取隔离，查询和服务隔离。

3.1 hologres特性

3.1.1 业务场景能力丰富

• 具备 OLAP 分析能力
• 具备高并发点查能力
• 具备半结构化日志分析能力
• 具备基于 PostGIS 的扩展能力，支持空间地理信息信息数据的分析与使用，对于曹操出行的业务属性来说非常重要。

3.1.2 一站式实时开发能力

• 契合数仓分层结构理念（可以像离线数仓一样去构建分层体系，数据实时流动，实时存储)
• Flink Streaming 生态高度融合 (Flink CDC 组件集成，Flink Catalog 集成)
• 统一的 Ad-hoc 能力，能以外表加载离线数仓中数据进行湖仓加速和联邦分析

3.1.3 解决的痛点问题

• 全链路低时延
• 多流 Join 场景很好的提供数据打宽的能力，支持主键模型和行级，局部字段更新的能力
• Count Distinct 大状态精确去重场景的支持

3.2 Hologres Binlog 支持

在 Hologres 中 Binlog 也是一种物理表，其跟原表的主要区别是内置的几种自身结构，包含自身递增序列，数据修改类型以及数据修改时间，Binlog 本质上也是分 shard 进行存储，所以也为一种分布式表，并且在 WAL 之前生成，因此在数据上可以与原表保证强一致性。

其次 Hologres Binlog 修改类型也还原了 Flink 中四种 RowKind 类型。在数据更新过程中会产生两条更新记录（update_before，update_after），并且保证了更新记录是一个连续的存储。右边展示中，写入一个数据一个pk1，然后再写入一个 pk2 数据，pk2 的数据再做一次更新，那么在 Binlog 中它会产生4条数据结果。

3.3 Hologres 数据模型介绍

Hologres 主要分做行存引擎以及列存引擎，同时也支持行列共存场景。

• 在聚合场景中主要是用到列存的引擎，适合 OLAP 场景，复杂查询，统计以及关联等场景。同时也提供了非常丰富的索引，包括有：聚簇索引，位图索引，字典，以及基于时间序列的范围索引。

• 在 KV 场景中主要是用到行存的引擎，主要支持高并发组件查询。包括在 Flink 中做维表反查也是非常适合。

• 在订阅场景中主要是用到行存的引擎，主要在表属性中进行声明，比如说 Binlog 是否开启，Binlog 的 TTL。在订阅方的话，Hologres 支持 CDC 以及非 CDC 的模式。

• 在日志场景中针对聚合场景，主要是支持 JsonB 数据类型。JsonB 数据的写入过程中，Hologres 能够将其自动地平铺成列式的存储结构，同时它可以自动对数据内容做解析，对数据类型做泛化处理，数据格式的对齐，非常适合这种非稀疏场景，因此给聚合场景提供了分析的灵活性。

4 Hologres+实时数据湖

刚才我们主要讲的是实时数仓，也是当前我们客户使用最成熟的架构。随着流式湖仓需求的兴起，当前技术上主要分为两个发展方向。一方面是数据湖的存储，包括 Paimon 这样的新的流式数据湖存储，让数据入湖更加简单和高效。然后在查询分析层面，通过类似 Presto、Hologres 这样高效的查询分析引擎，进行更好的数据查询加速。Hologres 可以直接加速读写存储于 OSS 上的 Hudi、Delta、ORC、Parquet、CSV、SequenceFile 等格式类型的数据。

4.1 流式湖仓分层建模

回到我们刚才的数仓分层，Hologres、Paimon 都具备流式访问能力。如果基于 Hologres+Paimon 实现流式湖仓的分层，数仓各层都可以根据企业的存储成本、业务时效性进行灵活的调整。

• 数据存储 Paimon，Hologres 进行查询加速：提供分钟级时效性+秒级 OLAP 性能
  例如针对一些时效性不敏感的 ODS 层数据，数据放在 Paimon 做存储，Hologres 进行查询加速，Hologres 能提供达到分钟级别时效性，相对来说成本更低，而且在和 Paimon 结合的加速查询，我们还在不断持续优化提升性能。

• 数据从 Paimon 写入 Hologres：提供秒级时效性+极致 OLAP 性能
  例如针对一些对与查询性能要求比较高的 ADS 层，数据可以直接进入 Hologres，通过和 Flink 结合提供秒级时效性和极致的查询性能，查询时间可能为几十毫秒，这样成本相对更高一点，但是性能会快很多。

可以看到无论是和 Flink 深度集成构建企业级实时数仓，还是与 Paimon 结合在流式湖仓的探索优化，Hologres 在演进过程中始终紧紧围绕实时场景，不断提高实时数仓的性能、可用性、用户体验。未来，Hologres 也会持续通过一站式实时数仓的理念，替换企业纷繁芜杂的数仓架构，让实时数仓更加干净、友好、高效，并帮助企业不断降低成本，加速数字化转型升级。