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

实时数仓建设背景

1. 实时需求日趋迫切

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

2. 实时技术日趋成熟

1. 在编程上将流计算和批计算统一到同一个SQL引擎上，基于同一个Flink SQL既可以进行流计算，也可以进行批计算。
2. 将流计算和批计算的存储进行了统一，也就是统一到Iceberg/HDFS上，这样数据的血缘关系的和数据质量体系的建立也变得简单了。
3. 由于存储层统一，数据的Schema也自然统一起来了，这样相对流批单独两条计算逻辑来说，处理逻辑和元数据管理的逻辑都得到了统一。
4. 数据中间的各层（ODS、DWD、DWS、ADS）数据，都支持OLAP的实时查询。

1. 同时支持流式写入和增量拉取。
2. 解决小文件多的问题。数据湖实现了相关合并小文件的接口，Spark / Flink上层引擎可以周期性地调用接口进行小文件合并。
3. 支持批量以及流式的 Upsert(Delete) 功能。批量Upsert / Delete功能主要用于离线数据修正。流式upsert场景前面介绍了，主要是流处理场景下经过窗口时间聚合之后有延迟数据到来的话会有更新的需求。这类需求是需要一个可以支持更新的存储系统的，而离线数仓做更新的话需要全量数据覆盖，这也是离线数仓做不到实时的关键原因之一，数据湖是需要解决掉这个问题的。
4. 同时 Iceberg 还支持比较完整的OLAP生态。比如支持Hive / Spark / Presto / Impala 等 OLAP 查询引擎，提供高效的多维聚合查询性能。

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

1. 基于Doris或者ClickHouse构建实时数仓。来看下具体的实现方式：将数据源上的实时数据直接写入消费服务。
2. 对于数据源为离线文件的情况有两种处理方式，一种是将文件转为流式数据写入Kafka，另外一种情况是直接将文件通过SQL导入ClickHouse集群。
3. ClickHouse接入Kafka消息并将数据写入对应的原始表，基于原始表可以构建物化视图、Project等实现数据聚合和统计分析。
4. 应用服务基于ClickHouse数据对外提供BI、统计报表、告警规则等服务。

业界实时数仓建设方案

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

• 从目前建设离线数仓的经验来看，数仓的数据明细层内容会非常丰富，处理明细数据外一般还会包含轻度汇总层的概念，另外离线数仓中应用层数据在数仓内部，但实时数仓中，app 应用层数据已经落入应用系统的存储介质中，可以把该层与数仓的表分离；
• 应用层少建设的好处：实时处理数据的时候，每建一个层次，数据必然会产生一定的延迟；
• 汇总层少建的好处：在汇总统计的时候，往往为了容忍一部分数据的延迟，可能会人为的制造一些延迟来保证数据的准确。举例，在统计跨天相关的订单事件中的数据时，可能会等到 00:00:05 或者 00:00:10 再统计，确保 00:00 前的数据已经全部接受到位了，再进行统计。所以，汇总层的层次太多的话，就会更大的加重人为造成的数据延迟。

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

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

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

微鲤实时数仓建设方案

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

数据湖方案改造计划

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

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

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

总结

• Kappa 架构，如Flink + HBase/Redis/Mysql：流计算 += 准确的实时预处理。
• 基于标准分层 + 流计算，如Flink + Kafka + Mysql/Redis，基于kafka数据分层，中间数据查询困难。
• 标准分层体现+流计算+批量计算，如Flink + OLAP：流计算 += 实时数仓，预处理和成本的权衡，高性能 OLAP 带来了一定的灵活度。
• 标准分层体系+流计算+数据湖，如Flink + 数据湖：流计算 += 离线数仓部分实时化。
• 基于全场景MPP数据库实现，如Flink + Doris/StarRocks，存储成本比较高的简易实时数仓

参考：

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

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

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

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

    [https://cloud.tencent.com/developer/article/2167527]

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

    [https://zhuanlan.zhihu.com/p/584255261]

9.数据湖技术选型参考_51CTO博客_数据湖技术选型

    [https://blog.51cto.com/wang/5008382]

作者 | 徐伟奇 大数据开发工程师