引言
现代数据环境要求架构能够无缝融合数据湖的灵活性与传统数据仓库的性能特征。随着企业越来越多地采用实时分析来驱动业务决策，Apache Flink作为流处理引擎与Apache Paimon作为湖存储格式的结合，已成为构建强大实时湖仓平台的引人注目的解决方案。
本文整理自 Apache CommunityOverCode Asia 2025 大会上，阿里云技术专家，Apache Flink Committer 苏轩楠分享了基于 Paimon构建的 Flink 实时湖仓解决方案持续演进的深刻见解。这一技术深度解析探讨了为解决大规模流式分析平台实施过程中面临的现实挑战而开发的关键优化和架构改进。
随着需要处理日益增长的结构化和半结构化数据量，传统的数据处理方法在性能、成本效益和运营复杂性方面往往力不从心。所讨论的增强功能代表了在生产环境中经过测试和完善的实用解决方案，为寻求现代化数据基础设施的组织提供了具体的实施路径。
实时湖仓架构格局
在深入技术优化之前，有必要了解围绕Flink和Paimon集成而形成的典型架构模式。实时湖仓方法代表了从传统批处理导向的数据仓库模式的根本转变，拥抱了数据到达时连续处理的模型。
基础架构组件
基于Flink和Paimon构建的现代实时湖仓通常由几个相互连接的处理层组成，每个层都服务于不同的目的，同时在整个系统中保持无缝的数据流。在基础层，Flink CDC（变更数据捕获）在建立统一的全量和增量数据同步能力方面发挥着关键作用。
Flink CDC在弥合操作数据库和分析系统之间的差距方面已被证明特别有价值。与需要在固定时间表上运行的复杂ETL管道不同，Flink CDC使组织能够实时捕获来自MySQL等源系统的变更，并直接将其流式传输到Paimon的ODS（操作数据存储）层。这种方法不仅减少了延迟，还通过消除对中间暂存区和复杂协调机制的需要来简化整体架构。
这些能力超越了简单的数据复制。现代实现支持完整的数据库同步场景，其中整个数据库模式可以迁移到湖仓格式，并完整支持自动模式演化处理。这意味着当源系统模式发生变化时——无论是通过添加新列、修改数据类型还是重构关系——下游Paimon表都可以自动适应，无需手动干预或管道重建。
数据处理与转换层
一旦数据通过摄取层进入湖仓，它就会经历一系列处理阶段，逐步完善和丰富信息。数据仓库明细（DWD）层代表第一个主要转换阶段，原始操作数据在此经历清洗、标准化和丰富操作。
这些转换通常涉及复杂的数据连接操作，通过组合来自多个源系统的信息来创建"宽表"。例如，电子商务组织可能会将客户档案数据与交易历史、产品目录和营销活动信息连接起来，以创建全面的客户行为数据集。这种处理的实时特性意味着随着源数据的变化，这些丰富的视图保持最新，为分析师和应用程序提供新鲜的见解，而没有传统批处理方法固有的延迟。
处理继续进展到数据仓库汇总（DWS）层，聚合计算产生业务指标和关键绩效指标。与传统数据仓库中这些聚合可能每天或每小时计算一次不同，实时湖仓方法能够在事件发生时连续计算业务指标。这种能力对于需要实时监控业务绩效、快速响应运营问题或基于分析见解触发自动化操作的组织来说是变革性的。
湖仓管理与优化
湖仓内的数据管理带来了与传统数据仓库管理显著不同的独特挑战。Paimon通过一套全面的湖仓管理工具和优化技术来解决这些挑战，这些工具和技术透明地运行以维持系统性能和效率。
小文件管理代表了任何基于湖的存储系统中最关键的运营挑战之一。随着流数据的连续到达，自然倾向于创建大量小文件，这会降低读取性能并增加元数据开销。Paimon的自动文件合并功能通过基于可配置策略智能合并小文件来解决这一挑战，确保存储保持优化而无需手动干预。
这些功能协同工作，在保持查询性能的同时最大限度地降低存储成本，这对于处理大量历史数据和实时流的组织来说是特别重要的考虑因素。
技术演进：应对现实世界的挑战
Flink和Paimon生态系统的成熟导致了越来越复杂的优化，这些优化解决了生产部署中遇到的特定性能瓶颈和运营挑战。从这一演进中出现了两个特别重要的改进：半结构化数据的增强处理和优化的Lookup Join操作。
半结构化数据挑战
现代数据环境的特点是半结构化数据格式的激增，其中JSON是最普遍的。Web应用程序、移动设备、物联网传感器和API驱动集成的兴起使JSON在企业数据管道中无处不在。然而，在使用传统流处理方法时，这种普遍性带来了显著的性能影响。
根本挑战在于JSON的自描述特性。与结构化数据中模式信息与数据本身分离不同，JSON直接在数据有效负载中嵌入类型和结构信息。虽然这提供了巨大的灵活性并启用了动态模式演化，但在流环境中处理大量JSON数据时会创建大量的计算开销。
Flink中JSON处理的传统方法将半结构化数据视为简单的字符串值，每次需要访问任何字段时都需要完整的解析操作。这种架构决策虽然实现简单，但性能不太理想。即使访问JSON对象中的第一个字段也需要解析整个文档，由于数据作为字符串值在Flink的作业中分发，每个需要处理JSON的下游算子都必须重复完整的解析操作。
存储也有同样的问题。JSON的基于文本的格式虽然人类可读且广泛支持，但消耗的存储空间比等效的二进制表示形式多得多。这种增加的存储占用直接转化为更高的成本和在随机操作期间增加的网络带宽消耗，其中数据在流处理管道中的算子之间移动。
Variant数据类型解决方案
Variant数据类型的引入代表了Flink处理半结构化数据处理方法的根本转变。Variant不是将JSON视为不透明文本，而是提供了一种原生二进制表示，保持了半结构化数据的灵活性，同时提供了更接近结构化数据处理的性能特征。
Variant格式从更广泛的数据处理生态系统中的类似努力中汲取灵感，特别是Parquet提议的半结构化数据格式。通过采用开放标准方法，实现确保了与其他处理引擎的兼容性。
Variant采用的二进制编码策略通过几种机制实现性能改进。模式信息不是在整个数据中重复嵌入，而是在元数据部分中编码一次，显著减少存储开销。字段访问操作可以利用这些元数据直接导航到特定字段，而不解析数据结构的无关部分，大大提高了选择性查询的访问性能。
增强的开发者体验
除了性能改进之外，Variant在处理半结构化数据时为开发者体验引入了显著的增强。传统方法要求开发者使用复杂的SQL函数进行字段访问，创建冗长且容易出错的查询。Variant启用了更直观的语法模式，与开发者从其他编程环境的期望一致。
使用熟悉的括号表示法和点语法的直接字段访问简化了查询开发并使代码更易维护。数组元素访问遵循类似的模式，使开发者能够使用自然语法处理嵌套结构。类型转换功能允许与强类型下游处理的无缝集成，其中Variant字段可以根据需要转换为特定的数据类型。
JSON字符串和Variant类型之间的转换函数为现有系统提供了迁移路径，同时启用了新格式的渐进采用。PARSE_JSON和TRY_PARSE_JSON函数处理从基于文本的JSON到二进制Variant格式的转换，后者为格式错误的输入数据提供错误处理功能。JSON_STRING函数在与尚未采用Variant支持的系统接口时启用转换回文本格式。
Variant Shredding：针对现实世界模式的优化
Variant实现中最复杂的优化解决了半结构化数据中的一个常见模式：经常访问的公共字段与真正动态部分的存在。虽然JSON的灵活性允许完全任意的结构，但生产系统经常表现出某些字段在记录中一致出现的模式，即使数据结构的其他部分变化显著。
Variant Shredding通过将经常访问的字段作为单独的物理列存储在主Variant二进制结构之外来利用这一观察。这种混合方法结合了半结构化数据的灵活性与经常访问字段的列式存储性能特征。以这种方式 shredding 的字段可以以几乎与常规结构化列相同的性能进行访问。
这种优化的影响超越了简单的字段访问性能。shredding 字段可以完全参与Flink的查询优化，包括 projection 下推（其中仅从存储中读取所需列）和 filter 下推（其中谓词在尽可能接近数据源的地方进行评估）。这些优化可以大大减少I/O需求，在处理大型历史数据集和实时流时特别重要。
适合 shredding 的字段识别可以通过两种方法发生。手动配置允许开发者和数据工程师基于他们对数据访问模式和业务需求的理解明确指定 shredding 字段。对于处理多样化或不断发展的半结构化数据的组织，自动化发现机制可以分析传入的数据样本以识别出现频率足以从 shredding 优化中受益的字段。
Lookup Join优化：解决可扩展性瓶颈
第二个主要优化领域解决了实时分析中的一个常见架构模式：使用Lookup Join用存储在Paimon表中的维度信息来丰富流数据。
理解Lookup Join挑战
Lookup Join代表了流分析中的关键操作，其中实时事件数据需要用相对静态的维度信息进行丰富。常见示例包括用客户档案信息丰富交易事件、向购买事件添加产品详细信息或用配置数据增强日志条目。挑战在于高效访问可能分布在多个存储分区中的维度数据，同时保持实时处理所需的低延迟特征。
Flink中的Lookup Join通常涉及三个阶段：基于连接键分发事实表数据的随机操作、从远程存储检索维度数据的获取操作，以及维护维度数据本地副本以供快速访问的缓存操作。
这种方法在传统的维度数据存储如Redis中运行得相当不错，因为其中数据本质上不分区，所有的算子都需要读取完整的数据。然而，Paimon的数据存储分桶策略与这种方法产生了根本性的不匹配，导致性能的浪费。
分桶不匹配问题
Paimon使用分桶策略组织数据，其中记录基于基于键的哈希函数分布在多个分桶中。这种方法提供了出色的可扩展性并启用了高效的数据组织，但它在传统Lookup Join实现中创造了显著的低效率。
核心问题是Flink的 Lookup 算子不知道Paimon的分桶策略。每个并发 Lookup 算子假设它可能需要与维度表中的任何记录连接，导致每个算子需要维护所有维度数据的完整副本。这意味着无论有多少并行算子处理Lookup Join，每一个都需要读取整个Paimon表并在本地缓存所有维度数据。
这种方法的影响在大规模部署中变得严重。作业启动时间可能延长到数十分钟，因为每个算子拉取完整的维度数据集。内存消耗随算子并行度提高，因为每个算子维护所有维度数据的重复副本。由于管理这些大型本地缓存的开销和为每个查找操作搜索完整数据集的计算成本，整体Lookup Join性能受到影响。
自定义Shuffle策略解决方案
该解决方案涉及扩展Flink的Lookup Join架构以支持自定义 shuffle 策略。这确保了预期到特定Paimon分桶的记录由负责该分桶维度数据的相同 Lookup 算子处理。
有了这种对齐，每个 Lookup 算子可以专门关注其分配的分桶数据。算子只需要维护其分配分桶数据的本地副本，而不是读取和缓存整个维度表。这大大减少了每个算子需要管理的数据量，并消除了算子之间的冗余存储。
性能改进效果非常明显，在高并行性场景中，作业启动时间也可以从数十分钟减少到几秒钟。每个算子的内存消耗显著下降，允许更高效的资源利用。由于较小的本地缓存和更集中的数据访问模式，整体Lookup Join性能提高。
其他关键优化特性
除了Variant数据类型和Lookup Join优化这两个核心改进之外，Flink和Paimon的集成还包含了一系列其他重要的优化特性，这些功能共同构成了完整的实时湖仓解决方案优化体系。
Paimon Action/Procedure 易用性优化
Paimon Action和Procedure功能的易用性优化代表了用户体验的重大改进。传统的湖仓管理操作往往需要复杂的配置和深度的技术专业知识，这对于开发者和运维人员来说构成了显著的使用门槛。
新的易用性优化简化了常见的湖仓管理任务，包括表的创建、数据的压缩、快照的管理和元数据的维护等操作。用户可以通过简单的SQL语句完成复杂的湖仓管理任务。
Materialized Table 物化表支持
物化表（Materialized Table）是 Flink 新引入的功能，主要是为了让用户能够通过 Flink SQL 写业务的代码，Flink 会自动根据用户指定的数据新鲜度需求来决定启动流作业或者批作业来生成 materialized table，保证表中的数据符合新鲜度的需求。用户免去了配置作业，以及维护作业的工作。
Nested Projection Pushdown
Nested Projection Pushdown优化专门针对复杂嵌套数据结构的查询性能问题。在现代数据环境中，JSON、Avro、Parquet等格式经常包含深层嵌套的数据结构，传统的查询处理往往需要读取整个嵌套对象，即使查询只需要其中的少数几个字段。
Nested Projection Pushdown技术能够分析查询中对嵌套字段的访问模式，并将字段选择操作推送到数据读取的最早阶段。这意味着在从存储系统读取数据时，就可以只提取查询实际需要的嵌套字段，而不是读取完整的嵌套结构。
这种优化对于包含大量嵌套字段的数据特别有效。例如，对于包含数百个字段的用户行为事件数据，如果查询只需要其中的几个关键字段，Nested Projection Pushdown能够将I/O开销降低一个数量级。同时，这种优化还能减少网络传输的数据量和内存使用量，从而提升整个查询处理管道的效率。
Partial Update Sink Reuse 和性能优化
Paimon 的 partial update 也是非常常用的功能。但是在做 partial update 的时候，通常需要在一个作业中有多个数据源写入同一张 Paimon 表，当 Flink 作业做 checkpoint 的时候，会有 sink 同时做 compaction，这会导致作业一直 Failover。为此我们对 Flink 的 sql planner 做了改动，让它能够识别出相同的 sink 进行复用，从而避免这种问题
技术发展路线图与版本规划
Flink和Paimon的集成发展遵循着清晰的技术路线图，不同的优化特性按照成熟度和优先级被分配到不同的版本发布周期中。
已发布功能特性
在当前已发布的版本中，核心的优化功能已经投入生产使用，包括前面详细讨论的Lookup Join优化、Paimon Action/Procedure的易用性改进、物化表支持、Nested Projection Pushdown，以及Partial Update Sink Reuse等关键特性。这些功能已经通过了大规模生产环境的验证，能够为企业级实时湖仓部署提供稳定可靠的性能保障。
Flink 2.1 与 Paimon 1.3 版本特性
在Flink 2.1和Paimon 1.3的版本发布中，重点关注Variant数据类型的基础支持能力。这个版本将提供完整的Variant类型读写功能，使得用户能够在Flink和Paimon中原生处理半结构化数据，而不需要依赖复杂的字符串解析操作。
同时，这个版本还将支持Variant配置的shredding字段功能，允许用户根据数据访问模式手动配置哪些字段需要进行shredding优化。这为有明确数据访问模式的企业用户提供了精细控制的能力，能够针对具体的业务场景进行深度的性能调优。
Flink 2.2 版本增强功能
Flink 2.2版本将进一步完善Variant数据类型的功能，重点提供更加灵活和强大的字段访问能力。用户将能够使用直观的语法访问Variant类型中的嵌套字段，同时支持灵活的类型转换操作，使得Variant类型能够与现有的强类型处理流程无缝集成。
这个版本的Variant类型支持将使得半结构化数据的处理体验接近传统结构化数据，同时保持了半结构化数据的灵活性优势。
展望未来：技术创新的新方向
半结构化数据处理的智能化发展
在半结构化数据处理领域，未来的发展将更加注重自动化和智能化。Variant shredding功能将支持自动设置shredding字段，系统能够通过分析历史查询模式和数据访问频率，自动识别哪些字段适合进行shredding优化，无需用户手动配置。
更进一步，Flink将支持Variant字段访问的下推优化到数据源层面，结合读裁剪优化技术，能够在数据读取阶段就完成字段的选择和过滤操作。这种源端优化将大大减少数据传输和处理的开销，特别是在处理大规模半结构化数据时能够带来显著的性能提升。
非结构化数据处理能力扩展
Flink的发展规划还包括对非结构化数据处理能力的重要扩展。未来版本将能够处理文本、图像、音频等非结构化数据类型，这为构建更加全面的数据处理平台奠定了基础。
非结构化数据处理能力的引入将使得Flink不仅能够处理传统的业务数据，还能够支持内容分析、多媒体处理、文档解析等更广泛的应用场景。这种扩展将进一步巩固Flink作为统一数据处理平台的地位。
更多内容
活动推荐
复制下方链接或者扫描二维码
即可快速体验 “一体化的实时数仓联合解决方案”
了解活动详情：https://www.aliyun.com/solution/tech-solution/flink-hologres
