小红书基于数据湖的流批一致存储通常

一、Lambda架构与实时数仓开发痛点

1、小红书的数据平台概览

首先来全体引见一下小红书的数据平台。

首先在最底层是一个个 Cloud，包含计算、存储等。在这一基础之上，是数据采集层，采集一些原始数据，比如用户行为日志数据、RDBMS 相关型数据库的增量日志数据，以及其余一些文件系统等。

而后基于源头数据层（ODS 层）之上是数据存储和加工层，关键分为两大块：一是偏离线的局部，关键经常使用 Hive、Spark 计算，经常使用 AWS S3 存储；二是偏实时的局部，关键经常使用 Flink 计算，经常使用 Kafka 存储。

再往上是一个数据共享层，咱们把一些聚合数据、Join 数据和宽表数据写入数据共享的一些剖析引擎中，比如 ClickHouse、StarRocks、TiDB、HBase 等等。这些都是作为数据共享层数据存储的底座，以及计算剖析引擎的一个入口。

最上方是运行层，咱们基于这一层做报表、即时查问等，还会对数据做封装，打造一些一致的数据产品。

2、典型的 Lambda 架构在小红书的通常现状

小红书驳回的是典型的 Lambda 架构。实时链路关键经常使用 Flink 和 Kafka；离线链路关键经常使用 S3、Spark 和 Hive。Lambda 的特点就是两条链路相互独立树立，互不影响。

Lambda 架构的痛点可以总结为三个方面：

① 实时和离线数据不分歧 ，形成数据不分歧的要素关键有三点：计算引擎不分歧，相反 SQL 定义也容易发生不同结果；作业不同，开发人员须要保养两套代码，技术门槛高；数据 TTL 不同，Join 剖析自然误差。

② Kafka 不足数据检索才干 ，对用户来说 Kafka 更像一个黑盒。不论 Kafka 中数据存储的是一些相似 protobuf 的数据还是 json 格局的数据，在做检索的时刻都十分艰巨。假设用户想要依据某个条件去检索数据，这个数据很难被查找。KSQL 产品更像是一个 streaming 的处置，更器重的是实时流处置才干，用来做离线大规模检索并不适宜。

③ 流存贮存数据有限，回溯效率低。 这一点最大的要素是老本高，数据不能有限存。而且假设要去回溯读，从历史上去回追数据，它读的性能也不迭批量读。

二、流批一致存储架构引见

基于 Lambda 带来的痛点，咱们萌生了去开发一个流批存储的产品的想法来处置 Lambda 的痛点。上方就来引见一些设计细节。

1、流批一致存储架构引见

如下是流批一致存储的全体架构：

咱们的流批一致存储叫 Morphing Server，对用户提供的 API 还是跟 Kafka 齐全兼容，都是经常使用流式的方式去写入和消费，这些接口都没有变，所以用户的经常使用方式不会有任何变动。

区别在于用户写入数据到 Kafka，Kafka 外部会有一个线程，异步将数据同步到数据湖中。咱们的数据湖是驳回的 Iceberg，当数据写入到 Kafka 中，外部线程会去抓取 Leader 数据，经过一些 Schema 数据解析转换为 Table Format 格局写入到 Iceberg 中，这个环节是异步的，对用户来说是无感的。

Kafka 的数据会被其余 Flink 作业消费，消费完之后可以写到下一个 Kafka 中，在下一个 Kafka 依然是以异步的方式将数据落地到数据湖中。数据湖中的数据就可以提供批读取和批存储的才干。关于 Iceberg 中的数据如何去读取的疑问，咱们会依据实践状况选取一些高性能的剖析引擎，比如 StarRocks、小红书自研的 RedCK 等来读取离线数据。

这里咱们总结了 6 点流批一致存储所提供的才干。

① 流批一致： 同时提供流存储和批存储的读写才干，构建多种运行场景。

② 无感写入： 对外提供的写入接口为原生 Kafka API，用户无需关注落数据湖环节，智能异步写湖。

③ Schema 解析： 数据在落湖前会提早启动 Schema 解析，以结构化、半结构化的 Table 方式提供查问。

④ 高速剖析： 借助 StarRocks 引擎的弱小湖上查问才干，能够提供向量化、CBO 等高速查问才干。

⑤ Exactly-Once： 流、批数据成功 Exactly-Once 语义，数据分歧性高。

⑥ 允许 Rollback： 允许批数据的 Rollback 才干，在 Schema 变卦不迭时下，回溯修双数据。

接下去，咱们引见一下技术选项是如何去考量？关于技术选项分为两个局部：智能落湖的环节如何选用；关于数据湖中的数据如何选取适宜的引擎去愈加高效读取

关于智能落湖环节咱们思考了两种方式，Builtin（内嵌）和 Extension（外挂插件），这两种方式其实都是可以的。

在 Builtin 的方式下，咱们看到只要一个独立的进程，在外面处置落日志之外，还会有一个异步的线程叫 Iceberg Syncer 去始终拉取日志中的数据，而后写入湖中，这种方式有长处也有劣势。

长处如下：

①产品外形完整，一致入口。

② 不须要额外保养外部组件。

③ 资源应用率高，共享进程。

劣势如下：

① 企业内生成集群版本难以更新，在企业中有一些集群并没有流批一体的配置，在更新中会十分艰巨。

② 进程隔离性弱，假设在异步线程中发生 bug，或者影响 Kafka 反常的读写配置。

针对 Builtin 方式的一些劣势，咱们现在思考了另外一种选项 - Extension，这个方式相对愈加直观。

Extension 方式，也存在着一些长处和劣势。

长处如下：

① 接入灵敏，集群不须要更新，咱们把 Kafka 落湖进程摘取到 Kafka 进程之外，是一个独自的进程，这是最大的一个好处。

② 流存储可交流，并不局限于 Kafka，可以交流成其余引擎。

劣势如下：

① 运维老本高，组件依赖过多，须要保养两套组件。

② 产品体验稍差，全体性弱。

目前咱们落地的是 Builtin 的方式，所面引见的一些细节方案都是基于 Builtin 方式的。

接上去引见查问剖析引擎的选型。咱们宿愿找到一款 OLAP 产品，具有以下 特点：

① MPP 架构、向量化和 CBO 来提高剖析性能。

② 允许多场景，能够在各种场景下满足咱们的需求。

③ 大规模，离线剖析数量大，数据种类多的状况下，在大规模数据量下性能不退步。

基于这些考量，有两大类选用：左边的是 Apache Doris 和 StarRocks 为代表的 OLAP 剖析引擎；左边是 ClickHouse 和小红书基于 ClickHouse 自研的 RedCK 剖析引擎。

左边的剖析引擎对散布式允许更好，对 SQL 协定兼容性高，提供愈加一站式的查问平台。左边的剖析引擎对单表性能愈加低劣，在超大规模下的数据承载才干更强，特意是咱们在 RedCK 上做了一些深度的定制化自研去满足更多运行场景。

上方引见咱们在散布式引擎上选用的 StarRocks。

StarRocks 允许湖上剖析才干。它自身允许读数据湖，不须要将数据以任何方式同步到 StarRocks 上，更像一种外表的方式，可以经过 Iceberg 的 Catalog 去查问数据，还会做一些 Cache 缓存来减速查问。

（2）StarRocks vs Persto 在流批一体（Iceberg）上的查问对比

咱们对 StarRocks 和 Presto 在流批一体上做了查问性能的对比，关键分为两大类，四小类的 SQL 启动比对。

左边关键是 Scan 全表扫描相关，在这一方面 Presto 的性能愈加优越，然而两者差距不大。左边关键是 GroupBy 相关的聚合场景，具有 MPP 架构的 StarRocks 在性能上显著愈加优于 Presto。这也是咱们选用 StarRocks 的要素。由于在这个运行场景下 Join 经常使用较少，所以这里没有启动对比。

还有一类剖析引擎就是之前提到的 ClickHouse 和 RedCK，如何去更好的剖析湖上的数据，这里引见一下咱们自研的 RedCK。

它是一个存算分别的架构，关键分为三个模块：Service、Query Processing 和 Storage。

Service关键提供 Gateway 网关和 Service Discovery 服务发现，能够让业务更好的接入；Query Processing是计算层，可以去解析 SQL 生成口头方案，分派这些义务去读写；Storage是存储层，允许文件存储比如 HDFS 和 Juice FS，还允许对象存储比如 OBS 和 COS。

接上去看一下 RedCK 和流批存储是如何联合的。

RedCK 经过 MergeTree 的格局跟其余查问引擎买通，比如 Spark、Flink 等计算可以间接读写 MergeTree 上的数据，而后经过 RedCK 在 MergeTree 上做 OLAP 剖析。这样的好处是经常使用 Spark 在写数据的时刻可以有一个更好的性能，做到了读和写两种引擎的解耦。

基于这个思考，咱们在 Kafka 流批一体的引擎在落湖的环节中，原本只允许传统的 Parquet 如今也允许写 MergeTree 格局，同时也去提交一些和 RedCK 相兼容的元数据消息。这样 RedCK 可以依据元数据消息间接找到 MergeTree 去做一些剖析。

全体上，落湖分为两大块：Commit 模块和 Broker 模块。

Broker 模块关键担任的是数据湖写入，应用 Kafka 自身的 Fetch 机制，将 Leader 上的最新数据启动解析并且始终写入，依照 Partition 维度来做独自的线程写入数据。

Broker 的设计关键包含如下内容：

① Replica Leader：Kafka 原生局部，处置 Produce 恳求和 Consume 恳求。

② ReplicaRemoteFetcherThread：关键上班线程，异步 Fetch Leader 数据，经过 Schema 解析，写入 Iceberg。

③ DefultSchemaTransform：Schema 解析模块，提供写入 Schema Server 变卦。

④ IcebergRemoteLogStorageManager：封装 Iceberg 接口，提供写入 Iceberg 的 API 汇合。

② 与 Broker 交互：发送 Checkpoint 恳求，协调各 Broker Checkpoint 消息。

Exactly-once 语义关键附丽于两阶段提交来成功数据不丢不重，详细如下：

① 第一步，Committer 向一切 Broker 动员一个 RPC 恳求，也就是 Checkpoint 恳求。

② 第二步，Broker 在接遭到 Broker 恳求之后将目前为止还没 Flush 的数据 Flush 到 Iceberg，成功之后将 Checkpoint 消息记载到 Checkpoint Storage 中。

③ 第三步，Broker 向 Commiter 前往一个 ACK，通知 Commiter 曾经成功 Flush 上班。

④ 第四步，Commiter 等到一切 Broker 前往的 ACK 消息之后，动员第一阶段提交并且记载到 Checkpoint Storage 中，实践上做一个 Commiter 和 CheckpointID 关联。

⑤ 最后一步，等第一阶段成功之后，动员第二阶段提交，收回一个 Commit 提交通知 Iceberg 可以落盘。

实践消费中，常会发生一些缺点。接上去引见各种缺点状况下，如何保证数据的不丢不重。

缺点状况大略分为如下几类：

① Broker 缺点： 比如突然宕机，其实这个缺点没有太大相关，由于 Kafka 自身有 Leader 切换才干，Leader 切换到其余 Broker 之后，会在新的 Broker 拉起异步线程写 Iceberg。它会从 Checkpoint Storage 中读取上一次性 Checkpoint，从上一次性的 Checkpoint 复原这些数据去从新写操作。在一次性 Checkpoint 数据向 Iceberg 的数据，由于是 committer 还没有启动第二阶段提交，关于 Iceberg 来说是无法见的，可以间接摈弃这些无法见的数据。

② Controller 缺点： 在第一阶段提交的时刻失败，会被智能切换到别的机器上方去再起一个 Commiter 线程，会发现第一阶段还没成功，那么会从新向一切 Broker 动员一轮新的 RPC 恳求，从新做一次性 Checkpoint，这一次性其它 Broker 在接遭到 RPC 恳求之后会发现不须要做 flush 操作，就会立刻前往 ACK。在收到一切 ACK 之后，会从新做一次性第一阶段提交；第一阶段提交之后成功了，然而在第二阶段提交的时刻失败了，那么 Controller 切换到另外的一个机器首先会去 Checkpoint Storage 中查问，假设第一阶段提交消息曾经存在就会间接动员第二阶段提交上班。

③ Object Store 缺点/HMS 缺点： 咱们会做一个有限重试，并且将一些告警消息发送进去。

三、流批一致存储运行通常

流批一致存储在公司外部落地之后，可以处置一些 Lambda 架构带来的疑问，上方将从四个方面来引见。

在流批一体之前，开发同窗去检索 Kafka 数据比拟复杂，如左图显示：第一步须要去放开一个 topic，依照须要写数仓作业；第二步找 DBA 放开一个 OLAP 表；第三步再去写 Flink JOB 去解析 topic 数据写到刚刚放开的 OLAP 表中，这个表纯正是用来查问和排障，整个链路比拟长。在经常使用流批一体之后，开发同窗放开一个 Topic，而后往 Topic 中写作业，这个时刻开发同窗可以间接查问流批一致存储。

流批一致的存储，可作为数仓 ODS 层，树立下游链路。由于流批一致存储是 Excatly-once 语义，所以可以做到实时和离线存储齐全婚配，可以防止双链路带来的数据不分歧疑问。

3、批量分区回刷，优化Backfill效率

联合 Flink 提供的流批一致的计算才干，同时从批存储和流存储回刷数据，极大优化回刷性能。与 Kafka 相比，批存储提供更长的数据生命周期，数据 SLA 更有保证。

应用 StarRocks 良好的湖上剖析才干，充散施展向量化引擎和 CBO 长处，在一致的计算引擎上成功多业务多维剖析。例如用户行为剖析、用户画像、自助报表、跨域剖析等多种剖析场景，都可以在一站式平台上去成功。