摘要：本文整理自阿里云产品经理李昊哲老师在 Flink Forward Asia 2024 流批一体（一）专场中的分享，主要分为以下三个方面：
一、 实时湖仓发展趋势洞察
二、基于 Flink 搭建流批一体实时湖仓
三、Materialized Table 升级流批一体湖仓体验
在流批一体的专场，我们主要探讨如何在阿里云上实现流批一体的最优解决方案。具体来说，将向大家介绍 Uniflow 的实时化流批一体湖仓解决方案。分享将围绕以下三个方面展开：
首先，会探讨实时湖仓的发展趋势和背景。在这一部分，我将介绍当前实时湖仓在业内的发展状况，以及阿里云在这一领域的地位。
接下来，将重点介绍流批一体在阿里云内部，特别是在 Flink 方面的应用情况。会给大家分享目前正在进行的工作、已经取得的成果以及未来的规划。
最后，将探讨 Materialized Table。这是基于流批一体补仓解决方案之上进行的大量体验优化，增强了用户的易用性。
一、实时湖仓发展趋势洞察
1.1 湖仓发展历史趋势及实时湖仓 AI 一体化
在 1.0 时代，主要依赖结构化数据。当时，离线数据通常存储在如 HDFS 这样的数据仓库（Warehouse）中，并进行批量数据的计算。这部分工作属于早期在批处理领域所做的努力。
在实时湖仓的 2.0 时代，引入了“湖”的概念，这意味着纳入了更多半结构化和非结构化的数据，进一步融合了数据湖与数据仓。在这一阶段，众多开源项目如 Apache Hudi、Apache Iceberg 等实时化、流批一体的湖仓解决方案应运而生。然而，在 1.0 和 2.0 时代，我们主要还是基于批计算或批处理来进行操作，可能对于数据的实时性，特别是数据流动的实时性，并未给予足够重视，或者说数据的时效性没有得到充分保障。
进入 3.0 阶段，即从 2023 年开始，我们正逐步迈向实时湖仓与 AI 一体化的趋势，并且发现了三个关键词：实时化、AI 化以及 AI 驱动。因此，我们目前正处于流批一体与 AI 化深度融合的大背景下。
1.2 阿里云在实时湖仓解决方案中的领导地位
刚才已经介绍了湖仓的大背景。接下来，关于阿里云目前所处的地位或背景，分析和结论基于 2024 年 IDC 的实时湖仓分析研究报告得出，该报告在2024年对 13 家公司进行了评估，包括阿里云、其他云厂商、互联网厂商以及大数据厂商，从战略和能力两个维度评估了目前实时湖仓领域各云厂商的地位。
此部分有两个重要的发现。第一个发现是在未来的 5 到 10 年中，实时湖仓解决方案可能会更广泛地应用于金融、互联网、零售以及物流等多个行业领域。这一趋势的背景是数据量的急剧增长以及企业降本增效的迫切需求，因此这样的方案可能会更多地在企业中得到实施。
第二个重要的结论是，阿里云目前处于领导者象限的首位。这意味着，如果企业希望应用或深入了解实时湖仓，阿里云提供的方案相对成熟，并且具有深厚的技术积累和实践经验。
二、基于 Flink 搭建流批一体实时湖仓
接下来，在介绍了大的背景之后，将重点放在第二个部分，即阿里云内部如何实现流批一体、构建实时湖仓，以及如何端到端地进行构建。接下来将分别拆解这些概念，并逐步与大家详细分享和介绍。
2.1 阿里云流批一体实时湖仓解决方案介绍
首先，Uniflow 的流批一体实时湖仓解决方案旨在帮助企业更高效地处理和分析数据。那么，企业为什么需要这样的解决方案呢？它能为企业带来哪些好处？
在技术架构选型的过程中，企业通常面临一个所谓的“不可能三角形”，即在性能、新鲜度和成本三个方面，无法同时达到最优。企业希望能够在性能和数据的新鲜度上取得高水平，同时又要保持低成本，而这在传统架构中难以实现。
Uniflow 解决方案的目标是在性能、新鲜度和成本这三者之间找到一个最佳的平衡（Trade Off）。通过提供分钟级的数据新鲜度和全链路的实时性，Uniflow 力求在保持低成本的同时，确保企业能够快速获取并利用最新的数据，从而提升业务决策的效率和准确性。
最终，数据会流入到数据分析层，即 OLAP 引擎层。在这里，可以更多地利用如 StarRocks、Hologres 这样的 OLAP 分析查询引擎，实现秒级的应用查询。而最初的 Warehouse 可能会有天级别的延迟。通过纯粹使用 Flink 进行 Streaming ETL，延迟可以缩短到秒级别。
这中间涉及的是成本与数据新鲜度之间的权衡。因此，我们期望整套 Streaming LakeHouse 解决方案能够同时具备 LakeHouse 的特性和 Streaming 的特性。这也是在当前企业追求最优性价比以及降本增效的背景下所提出的需求。
推出这一设计理念与初衷，旨在打造一个相对完美的解决方案。这里展示的是在设计之初较为典型且可能较为完美的一个 Streaming LakeHouse 架构示例图。在数据源端，通过 Flink CDC 读取日志以及数据库中的元数据。随后，利用 CDAS, CTAS 等方式，可以一键将数据导入到 Paimon 或类似的表格式中，并存储于 Paimon 中。Paimon 支持流式和批量的读写操作，实现数据的实时写入。当需要在数据分析层进行更多查询或实时响应时，方案完全兼容并开放。
整套方案的原理是基于低成本的 OSS 存储，并深度集成 Flink，以实现全链路的实时化。这种集成使得企业能够在降低成本的同时，确保数据的新鲜度和查询性能，满足业务的实时需求。
2.2 流批一体的数据处理方案介绍
其核心优势在于低成本的实时化，这也是之前提及的重点。接下来要讲的第二部分是流批一体，这正是本分会场的核心理念。流批一体意味着用户无需维护两套代码，也无需重复编写流作业和批作业，避免分别进行不同的上线和发布流程。这些冗余的操作将大大节省开发和运维成本。
此外，在最上层的数据查询方面，方案是完全开放的，用户可以自主选择适合自己的上层数据查询工具进行分层处理。在 ODS、DWS 层，该方案与 Paimon 完全打通，Paimon 的流处理和批处理，以及 CDC 功能，全面支持上层的查询引擎。
整套方案广泛适用于多种场景。用户既可以进行纯粹的 Spark SQL 或 Flink SQL 等批计算任务，也可以专注于实时流计算。无论是需要降低成本的实时场景，还是需要加速处理的纯批作业，亦或是需要实现流批一体的融合，这三种特定的应用场景都能通过一套完整的方案来全面支持。通过这样的方案，企业能够更灵活地应对不同的业务需求，实现更高效的数据处理和分析。
整体的数据架构如上图，从底层到上层的整体架构可以看作是一个分层的展示。在中间层，通过统一的元数据来处理底层不同的数据格式，包括 Table Format 等，最为标准的是像 Paimon 这样的流批一体的存储引擎。在上层，Flink 天然支持流批处理。通过流批统一的调度和计算，实现流处理与批处理的统一，即流数据的处理与批数据的读写。这样，能够向上层提供非常完善的企业级能力支持，打造基于 Flink 构建的实时补仓的完整解决方案。
2.3 Uniflow 与 Streaming Lakehouse 的区别及优化
上述介绍的都是关于 Streaming Lakehouse 的发展历程及其设计理念。接下来要探讨的是 Uniflow 是什么，以及它与 Streaming Lakehouse 的区别。
在之前提到的整体数据架构模型中，旨在保持完全开放，底层的数据格式可以由用户自主选择，上层的查询工具也任由用户挑选。Uniflow 这套流批一体的架构，实际上是将实时的 Flink 流批一体技术与 Streaming Lakehouse 的概念相融合，精心打造的一套解决方案或开发架构
传统的流处理与批处理架构是完全分割的。通常使用 Spark 进行批计算和批处理，而利用 Flink 进行流计算。这需要分别维护两套完整的架构。例如，在一个简单的场景中，需要对历史数据进行全量计算，同时在 Flink 上增加增量计算来处理数据流失、追数据和补数据等情况。这种架构存在三个显著的痛点和弊端。首先，它极易出错，因为底层数据被冗余存储了两份，且数据口径不一致。其次，整体数据隔离性较差，尽管数据本质上是相同的，但却需要重复存储。最后，这也导致存储成本加倍
Uniflow 针对这些问题进行了优化。一个标准的做法是通过 Flink CDC 直接实现全增量一体化的数据读取，并将数据写入 Paimon 存储层，从而完全屏蔽复杂的数据摄入和存储过程。Paimon 存储引擎天然支持流批一体，是一种非常优秀的湖格式存储，因此可以完全屏蔽底层数据存储的细节。在上层，可以灵活地选择流式读取或批式读取数据，然后将其写入 Flink 进行批计算。此外，上层的物化表（Materialized Table）也会根据不同的场景进行自主判断，以进行后续处理。
关于 Uniflow 整条链路的每一个部分如何实现，以及具体的技术架构和细节，会在接下来的演示中详细分享。这种架构不仅简化了开发流程，还有效降低了存储和运维成本，提升了数据处理的效率和准确性。
2.4 实现 Uniflow 架构中的实时数据处理
刚才谈到了 Uniflow 的整体架构，现在将这个概念拆分开来，单独探讨实时的理念。在大家的认知中，Flink 是一个完全的实时流处理引擎，能够实现 Exactly Once 的无误流式数据处理。然而，在企业生产实践中，要确保端到端的实时加速，仅仅依靠一个计算引擎是不够的。因此，需要从数据摄入、存储、计算到查询的各个环节，都尽可能地减少时延。其目标是让时延达到分钟级甚至秒级。
首先，在数据输入端采用标准的 Flink CDC 来实现全增量一体化的数据集成。Flink CDC 支持 Schema Evolution 能力，因此能够灵活处理数据结构的变更，确保数据持续一致地流入系统。
接着，在存储环节，使用统一的 Paimon 存储来统一表格式或数据格式。Paimon 利用其 Absurd 或 Partial Update 数据更新能力，实现实时的数据统一存储，确保数据的实时性和一致性。
在数据计算部分，Flink 作为一个流批一体的实时大数据引擎，已经被广泛认可和了解，因此无需过多介绍。它能够高效地处理实时流数据和批数据。
在查询方面，外部的 OLAP 联邦查询可以实现秒级响应。例如，通过 StarRocks 或 HoloView 等联邦查询引擎，可以高效地执行查询操作，满足企业对快速数据分析和决策的需求。
2.5 流批一体端到端解决方案
刚才提到了实时处理需要 Flink 的支持，接下来将重点讨论今天的主题，流批一体的端到端实现。之前讨论了实时的端到端处理，而现在要深入的是流批一体的端到端处理。从底层到上层，流批一体的端到端实现也包含几个主要方向： Flink CDC 数据摄取、存储计算以及开发与运行。
流批一体的四个方面都是如何实施的呢？从开发和运维的角度来看，流批一体的概念虽然提出已有一段时间，并且我们一直在为此付出努力，但可能之前的实现程度还未达到完美的状态，或者还未真正实现流批的无缝融合。随着业界逐渐接受这一概念，大家普遍认为它能够有效解决各自的痛点和场景问题，同时与实际需求高度匹配。
然而，确实还有很多工作要做。流批一体化的实现涉及四个关键方向：统一存储、统一调度、统一计算以及上层统一的开发与运行。在这里，重点讨论上层的开发与运行部分。从代码层面来看，流批一体化的实现只需维护一套统一的代码。在作业运行时，无需进行额外的配置，而是在作业触发时选择执行批处理模式还是流处理模式即可。这种方式大大简化了开发和运维流程，减少了复杂性，提高了效率。
在上层开发与运行部分，已经有了一种更简便的方式来实现流批一体化。通过这种方式，开发者可以更优雅地使用 Materialized Table，简化数据处理流程。关于 Flink 的批处理能力，尽管过去可能存在疑虑，但目前 Flink 的批处理性能已经能够与 Spark 3.0 基本持平。这一点已经得到具体测试报告和数据的支持，表明 Flink 在批处理和流处理方面都具备强大的能力。
2.6 Flink CDC 在数据集成中的应用
接下来要讨论的是利用 Flink CDC 实现流批一体的数据摄取。如果大家对数据同步或数据变更同步工具有所了解，可能已经听说过 Flink CDC。目前，Flink CDC 可以说是业界最流行或最通用的数据集成工具。通过数据源端和数据目的端的 Source 和 Connector，Flink CDC 已支持了三十多个开源和业界成熟的数据连接器。
Flink CDC 天然支持对流批一体化的读取，并能够进行全增量一体化的处理。这意味着可以先将数据全量的批处理并写入到数据仓库中，然后 Flink CDC 会自动判断何时进行增量计算，并将增量数据实时写入到目的端。这一过程可以通过简单地创建一个 MySQL Catalog 和一个对应的 Paimon Catalog 来实现，从而轻松维护一套元数据。这种方式使得数据的全量和增量处理变得更加高效和自动化，减少了手动干预和复杂配置。
2.7 Paimon：实现 Flink 流批一体的突破
之前在流批一体方面没有实现完整的突破，或者说没有实现端到端的突破，其中一个重要原因是未能找到一个能够完美适配 Flink 的流批一体存储解决方案。Paimon 的出现填补了这一空白。 Paimon 原名为 Flink Table Store，由 Flink 的 Committer 或研发团队主导和推动。在2024年，Paimon 被贡献到了 Apache Flink 开源社区，成为了一个顶级项目。在阿里巴巴内部，为了寻找一个完美的存储方案进行了大量的探索，最终选择了 Paimon。
最初，HDFS 被用作批处理的标准文件格式。随后，在业界，我们尝试过将 Flink 与诸如 ORC 这样的存储格式相结合。然而，在实际应用中或内部实践中发现，由于架构或性能的局限，这种结合在延迟方面可能只能达到小时级别。因此，在兼顾时效性和成本方面，这种方案的效果并不理想。
2024 年，我们推出了 Paimon。事实上，Paimon 在内部已经进行了长时间的沉淀和优化。但正式对外发布，并在企业和行业中广泛推广、积累客户和实践，也是2024年才开始有了显著的进展和成果。
2.8 Paimon技术方案实现流批一体及性能优化
接下来将详细介绍 Paimon。之前提到 Paimon 能够非常完美地适配 Flink，那么它是如何实现这一点的呢？Paimon 其实是对之前提到的多种湖存储格式（如 Delta Lake、Hudi、Iceberg 等）进行迭代和创新的结果。它吸取了这些格式的优点，并将它们与列存储进行了融合，采用了类似于 ACID 标准的架构。
在内部，Paimon 还采用了内置的高效算子，完全屏蔽了底层复杂的实现细节，使得用户无需关注这些细节。对于批计算，数据会以表的形式存储到 File Store 中；而对于流计算，数据则会通过增量的流式订阅方式读取到 Log Store 中。这种实现机制对用户层或上层开发来说是完全透明的，不会带来任何影响。
为什么 Paimon 能够同时满足流批一体的需求并控制成本呢？在谈论成本时，通常是指在追求高性能的过程中，将性能提升到极致，以减少资源消耗和代价。基于读写性能的平衡原则，以及之前提到的 Lakehouse 特性， Paimon 提供了相应的支持。在底层， Paimon 兼容 HDFS、OSS、S3 等标准的湖存储格式，实现了卓越的读写性能平衡。无论是 Append、Update 还是 Delete 操作， Paimon 都进行了优化。在数据合并、更新以及查询方面， Paimon 将性能发挥到极致，从而实现了低成本的目标。
之前已经介绍了许多内容，包括开发运行时的流处理、数据集成的流处理、 Flink CDC ，以及存储层的流处理，即 Paimon 。这些部分已经相当详尽，无需过多赘述。之所以将它们放在最后提及，是因为众所周知， Flink 在设计之初就秉持着一个核心理念：将批计算视为流计算的特例，并天然地支持流批一体的架构。为了实现这一理念， Flink 上进行了大量的优化工作，例如处理小文件合并等问题。此外，还加强了对 State 的支持。
2.9 Flink 在流计算和批处理能力测试
以下是一份详尽的测试报告。对于熟悉 Flink 的朋友而言，业界最常用或最标准的测试方案莫过于 Nexmark 。在本次测试中，我们对比了开源社区的最新版本。测试采用了 Flink 1.19 这一相对稳定的版本进行。测试将其与阿里云自研的商业版本以及企业级引擎的性能进行了对比。之前已经提到过，这个产品不仅完全兼容开源，还在性能上超越了开源版本。
在商业化引擎能力方面进行了大量优化。从测试结果来看，阿里云自研的商业版 Flink 引擎在处理 1000 条记录时，Flink Engine 达到了 740 ，相当于开源版本性能的 8.4 倍。而在处理 2 亿条数据的场景下，其性能是开源版本的 5.7 倍。这些性能提升为客户带来了显著的成本效益，降低了运营成本。
这部分内容主要展示了批计算的输出能力。可能会有人对 Flink 的批计算能力有所质疑。为此，基于 Spark 结合开源 Flink 以及阿里云自研的 Flink 引擎进行了测试。测试结果显示，在处理 10TB 的大规模数据时， Flink 引擎的性能已经达到了 Apache Spark 3.4 的 3.1 倍。这充分证明了在批计算方面所做的优化是有效的，这一结论也在完整的测试报告中得到了验证。
2.10 企业级能力支持与 Materialize Table 介绍
这部分内容全面展示了企业级能力支持，建立在之前提到的流批一体的处理的基础之上。
除了企业级能力的优化之外，还提供了稳定性和安全性层面的多重保障。从基础设施层到存储、计算、调度服务，我们都致力于确保能够满足用户的 SLA 要求。
三、Materialized Table 升级流批一体湖仓体验
最后一部分是关于 Materialized Table 的介绍
这一设计理念主要是为了解决传统 Lambda 架构或流批架构中的痛点。我们特别关注上层应用，尤其是针对那些可能不太了解流批概念的数据分析师或业务用户。他们可能希望不依赖开发团队，就能独立进行数据查询和补数操作。因此，在流批一体架构已经相对完善的基础上，我们进一步希望在应用层面做出更多优化。以下展示的是比较标准的流批一体处理架构。
在中间层基于 Materialized Table 进行了一层统一的代码封装，这样做的目的是屏蔽流批计算的复杂性。用户只需进行数据定义，并注册一个 Materialized Table 。在实际进行数据查询时，用户只需调整所谓的“数据新鲜度”参数，就可以完全忽略流作业或批作业。对于上层的数据开发者来说，他们只需修改这个“新鲜度”设置，就能达到预期的效果。
具体来说，用户只需注册一个 Materialized Table 并写入数据，即可实现这一流程。在最终查询阶段，能够自动推断并选择采用全量计算、增量计算还是流式计算的方式。
从命令行操作的角度来看，原本复杂的周期调度方式现在被简化为简单的声明式 ETL。这意味着，不仅开发团队，业务团队或数据团队的成员也能轻松完成整套操作，无需编写繁琐的作业。他们只需通过简单的声明式命令，就能自行构建并执行查询。
之前曾提到性价比的概念。由于当前的大环境，我们一直认为流计算成本高昂，因为它代表着资源消耗和额外开销。然而，通过使用 Materialized Table ，可以针对三种不同的计算模型进行智能决策和判断。具体而言，系统可以自动决定何时采用批处理进行小时级的全量数据读取，以及何时进行秒级的流计算以获取增量数据。这些决策都在系统内部自动完成，从而在信息数据新鲜度与成本之间实现最佳平衡。
在 MT 这部分进行了大量的内部积累。阿里巴巴的一个显著优势在于业务种类繁多，应用场景丰富，覆盖的行业广泛。这为我们提供了宝贵的经验和解决方案的沉淀机会。2024年在内部也加强了合作，以进一步提升 MT 的性能和应用效果。
这是2024年与淘宝天猫合作进行的一项技术沉淀，目前的存储和计算规模都相当庞大。这里展示的是一个相对简单的案例，即基于 MySQL 进行整库实时同步，通过 Flink CDC 模式将数据写入 Paimon 表中，并进行数据分层处理，通过 ODS、DW、DWS 等层次进行数据分层处理。随后，利用 StarRocks 的 OLAP 引擎，实现秒级查询，最终为天猫生成实时报表。下面有整套方案中的其中一个 demo ，为大家进行简单演示，希望能让大家直观地了解 MT 的功能及其所能达到的效果。
点击下方观看：
DEMO 观看地址
更多内容
活动推荐
阿里云基于 Apache Flink 构建的企业级产品-实时计算 Flink 版现开启活动：
新用户复制点击下方链接或者扫描二维码即可0元免费试用 Flink + Paimon
实时计算 Flink 版（3000CU*小时，3 个月内）
了解活动详情：https://free.aliyun.com/?utm_content=g_1000395379&productCode=sc
