写点什么

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

作者:Apache Flink
  • 2025-03-07
    陕西
  • 本文字数:3719 字

    阅读完需:约 12 分钟

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

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

  1. 组件选型及架构

  2. 离线加速

  3. 流批链路统一

  4. 消息组件平替

  5. 样本拼接

  6. 查询提速

  7. 元数据监控

  8. 数据迁移

  9. 未来展望

01、组件选型及架构

1.1 组件选型



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

1.2 湖仓架构



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

  1. 离线加速:通过从 Kafka 等消息中间件获取数据,并采用追加方式或利用 Flink 的中间状态处理,实现类似 Spark 或其他框架的功能。这一过程生成准实时的操作数据存储 (ODS) 和数据仓库(DW),最终通过 Flink 或 StarRocks 进行查询。这种方法提高了数据处理的速度和效率。

  2. 链路合并:针对 Lambda 架构中同时存在的实时与离线两套数据处理链路的问题,使用湖仓架构来统一这两条路径,旨在减少重复计算与存储成本,同时也简化了团队管理和维护工作。该方案允许在一个系统内完成所有操作,避免因补数需求而导致的数据不一致问题。例如,基于 Paimon 可以实现实时补数,在流处理和批处理之间保持一致性。

  3. DB 数据分析优化:对于传统的数据库到 Hive 的数据分析流程,采用 Paimon 加 Flink 组合替代原有方法后,能够显著降低数据延迟(从天级/小时级降至分钟级)。不过需要注意的是,过短的检查点间隔虽然能提供更低的延时,但也可能导致大量小文件产生,给 HDFS 带来压力。因此推荐设置至少 5 分钟以上的检查点周期以确保文件管理的有效性。此外,利用 Paimon 支持的时间旅行功能,可以通过定期创建快照来高效管理历史数据,如每日凌晨自动创建快照并保留一周的历史记录,从而优化存储空间的使用。

02、离线加速



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

  1. 数据源采集:数据源包括日志型数据(如服务日志、线上打点设备数据)和数据库数据。这些数据通过传感器或其他设备采集,并持续传输到服务日志中,然后通过离线方式写入 Hive。

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

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

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

03、流批链路统一



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

04、消息组件平替



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

05、样本拼接



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

06、查询提速



在查询提速方面,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 定期进行文件合并,从而确保读写性能的稳定性。

07、元数据监控



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

08、数据迁移



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

09、未来展望



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

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


更多内容




活动推荐

阿里云基于 Apache Flink 构建的企业级产品-实时计算 Flink 版现开启活动:新用户复制点击下方链接或者扫描二维码即可 0 元免费试用 Flink + Paimon实时计算 Flink 版(3000CU*小时,3 个月内)了解活动详情:https://free.aliyun.com/?utm_content=g_1000395379&productCode=sc



发布于: 刚刚阅读数: 3
用户头像

Apache Flink

关注

Apache Flink 中文社区 2020-04-29 加入

官方微信号:Ververica2019 微信公众号:Apache Flink 微信视频号:ApacheFlink Apache Flink 学习网站:https://flink-learning.org.cn/ Apache Flink 官方帐号,Flink PMC 维护

评论

发布
暂无评论
vivo基于Paimon的湖仓一体落地实践_大数据_Apache Flink_InfoQ写作社区