vivo基于Paimon的湖仓一体落地实践

Apache Flink

已于 2025-03-07 14:54:37 修改

阅读量769

点赞数 21

文章标签： flink 大数据

于 2025-03-06 20:04:32 首次发布

本文链接：https://blog.youkuaiyun.com/weixin_44904816/article/details/146084211

版权

摘要：本文整理自 vivo 互联网大数据专家、Apache Paimon Committer 徐昱老师在 Flink Forward Asia 2024 流式湖仓专场（一）中的分享。本次分享基于 vivo 的实际案例，展示在构建现代化数据湖仓过程中的一些关键决策和技术实践，包括组件选型、架构设计、性能优化以及数据迁移等方面的探索。内容分为以下几个部分：

组件选型及架构
离线加速
流批链路统一
消息组件平替
样本拼接
查询提速
元数据监控
数据迁移
未来展望

Tips：关注「公众号」回复 FFA 2024 查看会后资料～

组件选型及架构

1.1 组件选型

我们的技术栈以Flink作为主要计算引擎，结合StarRocks用于联邦查询加速，Paimon作为核心存储层覆盖所有湖仓场景。对于存储格式的选择，在较旧版本中推荐使用 ORC。自 1.0 版起，Parquet 提供了更强大的功能，支持复杂类型数据。因此，可以根据实际使用的版本灵活选择。

1.2 湖仓架构

湖仓一体架构在实时场景中有三大应用场景：离线加速、链路合并以及传统数据库数据分析优化。

离线加速：通过从 Kafka 等消息中间件获取数据，并采用追加方式或利用 Flink 的中间状态处理，实现类似 Spark 或其他框架的功能。这一过程生成准实时的操作数据存储 (ODS) 和数据仓库(DW)，最终通过 Flink 或 StarRocks 进行查询。这种方法提高了数据处理的速度和效率。
链路合并：针对 Lambda 架构中同时存在的实时与离线两套数据处理链路的问题，使用湖仓架构来统一这两条路径，旨在减少重复计算与存储成本，同时也简化了团队管理和维护工作。该方案允许在一个系统内完成所有操作，避免因补数需求而导致的数据不一致问题。例如，基于 Paimon 可以实现实时补数，在流处理和批处理之间保持一致性。
DB数据分析优化：对于传统的数据库到 Hive 的数据分析流程，采用 Paimon 加 Flink 组合替代原有方法后，能够显著降低数据延迟（从天级/小时级降至分钟级）。不过需要注意的是，过短的检查点间隔虽然能提供更低的延时，但也可能导致大量小文件产生，给 HDFS 带来压力。因此推荐设置至少 5分钟以上的检查点周期以确保文件管理的有效性。此外，利用 Paimon 支持的时间旅行功能，可以通过定期创建快照来高效管理历史数据，如每日凌晨自动创建快照并保留一周的历史记录，从而优化存储空间的使用。

离线加速

下面具体讲一下离线加速带来的收益，相较于传统数仓，采用湖仓一体架构的离线加速方案能够显著提升数据处理的时效性。具体来说，这种架构通过以下方式实现质变的时效提升：

数据源采集：数据源包括日志型数据（如服务日志、线上打点设备数据）和数据库数据。这些数据通过传感器或其他设备采集，并持续传输到服务日志中，然后通过离线方式写入 Hive。
实际生产链路示例：

传统数仓：例如，进行ETL处理并生成DM/DW数据，整个过程需要两个小时。
Paimon架构：采用Paimon后，由于整个链路是准实时的，可以将处理时间从小时级缩短到分钟级，通常控制在十分钟以内。

链路完整性与容灾：

Paimon对并发写操作有很好的支持。只要不写入相同的Bucket，就不会发生冲突。在实际生产中，通常是不同的分区，因此无需担心并发冲突问题，可以高效地并行处理数据。
数据复写机制也确保了链路的完整性和容灾能力。

应用场景：

对于需要高时效性的业务，如算法处理或实时报表，离线加速方案可以显著提升效率。通过这种方式，可以大幅提高数据处理的速度和响应时间，从而更好地支持业务需求。

流批链路统一

传统的数据处理架构通常包含两条链路：一条是基于Spark和Hive的离线处理链路，另一条是基于Kafka和Flink的实时处理链路。这种双链路设计虽然可以保证数据的准确性和实时性，但资源消耗较大且不够灵活。此外，由于 Kafka 的数据存储特性，写入 Kafka 的数据通常不易直接读取，增加了使用的复杂性。采用Paimon加Flink的架构后，所有数据处理链路完全统一，无论是实时还是离线数据都可以写入Paimon表并随时进行分析，提高了灵活性。此外，合并后的链路可以减少约30%的计算资源需求，并通过统一的内存和CPU核数等指标进行监控和对比，从而实现更高效的资源管理和优化。

消息组件平替

在实时场景中，通常使用 Kafka 或 PSA 进行数据流转和实时数仓的摄取，但云上用户的 Kafka 资源宝贵且成本高，有时会遇到资源不足或负载过高的问题。Paimon 作为一种低成本的消息组件替代方案，可以通过其 Consumer 机制实现类似于 Kafka 的功能。尽管其时延为分钟级，相较于 Kafka 的秒级延迟稍高，但对于许多业务场景来说已经足够。通过将部分业务迁移到 Paimon，可以有效利用冗余的离线资源，提升存储利用率，并大幅降低计算和存储成本。在 vivo 内部的实际应用中，这种迁移不仅优化了数据链路的稳定性，还显著降低了整体资源成本，总体成本降幅可达 50%。

样本拼接

在样本拼接场景中，通常需要处理实时和离线两种拼接方式。离线拼接涉及全量数据下发和指定分区的插入操作，导致计算资源浪费且效率低下。实时拼接则面临大状态管理的问题，可能导致 TB 级状态数据，从而引发集群风险和稳定性问题。通过使用Paimon的Partial Update 功能，可以实现高效的增量更新，避免大状态问题。具体来说，A 数据和 B数据可以直接写入 Paimon 表，通过轻量级的 HASH 计算和增量写入，确保高吞吐写入，并在查询时进行合并。这种方案不仅减少了计算资源的消耗，还提高了系统的稳定性和性能。此外，Paimon 的延迟读能力可以在特殊场景下自动同步维表数据，保证数据的新鲜度。在实际应用中，这种方案可以将样本拼接时间从一两小时缩短到 5分钟，显著提升算法训练的效果和速度。

查询提速

在查询提速方面，Paimon 通过联邦查询和特定算法（如 Zorder 或 Hilbert）提供了显著的性能提升。例如，在不同时间对不同分区或字段进行查询时，Paimon 可以通过指定分区并使用 Procedure 合并字段来优化查询性能。与 Hive 相比，Paimon 不需要对所有分区进行去重和排序，从而降低了整体代价。在实际应用中，通过 Paimon 和 Spark、Flink 引擎，可以在几十亿条记录的表上实现秒级点查。结合 MPP 向量化查询技术，查询时间可以进一步压缩到毫秒级。然而，在高并发情况下，低版本的 Paimon（如 0.7 版本）由于缺少 Canny Catalog，会频繁与 Hive Metastore（HMS）进行冗余交互，从而影响查询性能。升级到 0.9 版本以上并包含 Canny Catalog 后，即使在 200 多个并发查询百亿级表时，也能保持毫秒级响应。此外，Paimon 支持实时数据写入后的文件治理。通过设置较短的 Checkpoint 时间，可能会生成大量小文件。为避免对 Hive Metastore（HMS）集群造成压力，Paimon 定期进行文件合并，从而确保读写性能的稳定性。

元数据监控

在湖仓元数据监控方面，为了确保高效的数据写入，Flink 任务中可能会关闭一些表的管理功能，如设置 Read Only 为 True，但这会导致快照清理等维护操作被忽略，从而在事后发现查询速度变慢和元数据膨胀等问题。为此，可以构建一个基于表级别的元数据监控系统。该系统在建表时自动开启监控，并提供默认规则。例如，当快照数量超过 200 时，系统会自动触发告警。监控系统基于 Paimon 的系统表，通过 Flink 和 StarRocks引擎定时查询这些系统表，并将数据导入 StarRocks 的内表。智能诊断系统根据用户配置或系统默认规则检查相关指标，一旦触发告警规则，会立即推送告警消息，使用户能够及时进行表管理和维护，如清理快照等操作。这种监控方案能够在问题发生前及时发现并处理，确保湖表的性能和稳定性。

数据迁移

数据迁移方面，Paimon 提供了简单有效的工具来将历史数据从 Hive 表迁移到 Paimon 表，以实现湖表能力。对于非 Paimon 表（如默认的 Hive 表），可以通过创建 Paimon 表，并使用 INSERT INTO 或其他数据导入工具完成迁移。Paimon 支持原地迁移和从 A 到 B 的迁移，后者通过将 Hive 文件移动到临时目录，再构建元数据（如 Schema、快照类型和 Manifest 文件）来完成。迁移完成后，将临时表重命名为现有表名，从而实现用户无感知的平滑迁移。这种迁移方法不仅高效，还能在几分钟内完成百亿级别表的迁移，且用户感知较少。迁移后，为了确保计算引擎（如 Spark 或 Flink）的兼容性，需要调整相关依赖和 Catalog 注入信息，以完成任务级别的迁移。整体过程包括数据和任务的迁移，最终实现在平台上一键或低感知地将 Hive 表迁移到 Paimon 表，从而激活流读流写能力，减少计算资源消耗。

未来展望

最后，我们共同展望未来。未来的工作将重点关注 AI 场景中的算法需求，尤其是在 AI 训练和推理场景中对非结构化和半结构化数据的存储、查询和处理能力的支持。我们将增强 Paimon 在处理复杂类型数据（如集成数据）方面的存储和查询性能。此外，我们计划提升 Merge Engine 的自定义能力，使用户能够根据自身特定需求灵活配置，突破现有固定功能的限制。通过这些改进更好地支持各种特殊场景（如算法行程等），从而创造更大的业务价值。

至此，本次的分享结束。希望通过以上内容，能为大家带来一些启发和帮助。感谢各位的阅读与支持！