2.存算分离状态管理
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;visibility: visible;">3.Streaming LakehouseingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;">4.AI 实时化探索ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;">5. 问答环节01
Flink 2.0概述
1. Apache Flink发展历程
Flink的发展历程可以分为三个阶段：
（1）起源阶段（2009-2016年）：
起源于柏林工业大学的Stratosphere项目。
2014年捐赠给Apache基金会，并更名为Apache Flink。
同年，Flink从孵化器毕业成为顶级项目。
2016年3月发布了Flink 1.0版本，标志着Flink正式进入生产可用阶段。
（2）发展阶段（2016-2019年）：
主要发展动力来自中国，尤其是阿里巴巴在淘宝、天猫等业务中的大规模应用。
2018年成立中文社区及举办首届Flink Forward Asia峰会。
2019年阿里巴巴收购了Flink创始团队成立的公司Data Artisans（现名为Ververica），并将企业版Blink贡献给Apache社区。
（3）全球化与创新阶段（2019年至今）：
2020年推出Flink CDC，2022年启动Flink Table Store子项目（即Apache Paimon）。
2023年开源Fluss项目，旨在提供面向实时数据分析的存储系统。
同年，Flink获得SIGMOD System Award。
2025年3月发布了Flink 2.0版本，标志着实时计算进入了新阶段。
2. Flink 1.0的核心能力与挑战
（1）Flink 1.0解决了什么问题
Flink 1.0在流计算领域解决了许多关键问题，其中最为核心的是有效解决了有状态流计算的问题。在此之前，尽管存在如Storm等流计算系统，但这些系统往往难以实现精确的实时计算，通常需要依赖后续的离线处理来校正计算结果。这主要是因为早期的流计算系统未能妥善解决有状态流计算的问题。
高性能、低延迟：Flink实现了大规模数据的实时处理，确保了系统的高效运行和快速响应。
大规模、分布式：支持大规模并行处理任务，使得Flink能够应对海量数据的实时处理需求。
精确一次状态一致性：Flink通过其状态管理和分布式快照机制，能够在节点故障时恢复状态，并保证每条数据仅被处理一次（精确一致性），从而避免数据丢失或重复处理。
事件时间语义：针对实时数据中常见的乱序或迟到问题，Flink引入了事件时间的概念，确保即使数据到达顺序混乱也能正确处理。
流式SQL：虽然Flink最初仅支持Java和Scala编写的应用程序，但为了降低开发门槛，Flink引入了SQL支持，使得用户可以使用标准的数据分析语言来描述动态数据流的计算逻辑。
流批一体：Flink还提供了流批一体的能力，这意味着相同的业务逻辑既可以用于实时处理也可以用于离线回刷，减少了作业开发和运维的复杂度，同时降低了数据存储的需求。
（2）实时计算面临的挑战
尽管Flink 1.0已经具备了强大的功能，并且在性能层面能够支持秒级甚至亚秒级的时效性，规模上也足以应对数千并发乃至上万并发的生产环境，但在实际应用中仍面临一些关键挑战：
计算资源：
常驻计算资源：由于流计算资源常驻，为保证数据能第一时间得到处理，难免会出现资源冗余或闲置的情况。
随机状态访问的性能影响：在流处理过程中，不同分组的数据到达顺序是随机的，这要求系统不断在不同分组之间切换以累加数据，带来了额外的资源开销并影响整体性能。
计算结果更新的成本：实时处理中，每当有新数据到达，都需要对之前的计算结果进行更新，导致聚合算子输出的数据量大幅增加，进而影响下游运算逻辑的效率。
快照容错开销：确保系统在故障后能够恢复状态数据，Flink通过定期对状态数据进行快照，并将这些快照持久化到远程存储中，以保证即使遇到故障也能快速准确地恢复数据处理的状态。
使用成本：
研发阶段：需要理解流计算特有的概念（如事件时间语义、窗口函数等）。
运维阶段：需处理反压调优、快照管理等问题。
这些问题限制了实时数据处理技术在更广泛场景和行业的推广使用，尤其是对于那些时效性要求较低的应用场景，用户可能会选择更加经济的离线计算方案。
3. Flink 2.0致力于解决什么问题
Flink 2.0的核心目标是使实时计算更加普适和普惠，旨在将Flink 1.0中已成熟的功能扩展到更多行业场景。为此，Flink 2.0主要聚焦于两个方面的工作：
拓宽场景
针对云原生、数据湖和AI等新兴场景，解决其实时计算中的新需求与挑战。
降低成本
提升资源使用效率和支持弹性伸缩。
降低开发门槛，提供流批一致的开发体验，简化用户操作。
增强运维便捷性，实现引擎自适应参数调优，减少用户干预。
02
存算分离状态管理
1.分布式有状态流处理
有状态的计算是指对于给定输入数据和系统的当前状态，通过计算产生输出数据并更新系统状态的过程。在Flink中，这意味着算子会持续接收输入数据，并基于数据中的键值查找对应的状态数据，结合输入数据和当前状态完成运算，然后将结果发送到下游，并更新状态存储。
在分布式环境下，Flink将数据根据其键值分发至不同的Task Manager (TM)节点上处理，确保每个节点仅处理一部分键值对应的数据及其状态信息，从而实现高效实时处理。这种方式确保了在执行计算时可以高效地访问本地存储的状态数据，从而保证了更好的实时性和性能表现。
为了满足容错需求，Flink会定期对本地状态数据创建快照，并将其持久化存储到远程存储系统中，如OSS、HDFS或S3等。由于算子与其对应的状态数据位于相同的TM节点上，这种架构被称为存算一体的状态管理架构。
2.云原生场景下的挑战
在当前的存算一体架构下，特别是在云原生环境中，面临如下一些需求和挑战：
计算与存储解绑：不同作业对计算资源和存储空间的需求差异大，需要独立扩缩容。
容器化资源使用优化：在进行周期性状态快照时会产生密集I/O操作，这会导致资源使用上的波动。由于每个容器之间的资源是相互隔离的，为了应对这种峰值资源需求，必须预留足够的资源，这导致在非峰值时段出现资源闲置和浪费。因此，希望引擎能够在资源使用上更加均匀和平滑，以提高资源利用率。
利用海量低价云存储：随着云存储性能提升，本地磁盘不再是高性能存储访问的必要条件。
带状态快速扩缩容：动态调整计算资源以匹配实时数据流量变化的需求，减少扩缩容时的断流时间。
3.存算分离的状态管理——ForSt
Flink 2.0引入了一种全新的存算分离状态后端，名为ForSt（“For Streaming”的缩写）。与传统的存算一体架构相比，ForSt不仅涵盖了本地存储，还将远程存储纳入其中，实现了计算与存储的解耦。
核心区别
在存算一体架构中，本地状态被视为Ground Truth，而远程存储仅用于快照的持久化。而在ForSt架构下，远程存储成为Ground Truth，这意味着状态更新将更积极地写入远程存储系统，而本地存储则主要用于缓存加速。
主要优势
状态存储解绑本地盘：状态更新直接写入远程存储，本地磁盘仅作为缓存加速使用，降低了对本地磁盘大小的依赖，从而实现计算资源和存储资源的独立扩缩容。
即时扩缩容&容错恢复：基于远程存储作为Ground Truth，作业在进行扩缩容或从故障中恢复时无需将完整状态数据拉取到本地磁盘，减少了等待时间。作业可以直接从远程存储访问所需状态，避免了长时间断流的问题。
轻量级快照过程：由于状态数据已存储于远程系统，快照过程变得更加轻量化。周期性的大规模数据上传不再是必需，快照操作只需将缓存中尚未写出的数据刷新出去，并做一些元数据标记即可完成。这种方式减少了周期性的I/O资源波动，使得远程存储操作的负载更加均匀和平稳，提高了资源使用的效率和稳定性。
4.性能
在采用存算分离架构时，一个常见的担忧是性能是否会因从本地磁盘改为远程存储而下降。实际上，如果不做任何优化直接将状态存储从本地迁移到远程，确实会导致性能显著下降。然而，Flink 2.0通过一系列优化措施解决了这一挑战，并实现了性能的显著提升。
性能优化措施
算子适配：包括SQL算子在内的多个内置算子得到了优化，以更好地适应新的存算分离架构。
异步状态访问：Flink 2.0将算子的运行线程模型从同步改为异步。这意味着，在等待获取远程状态数据的同时可先处理后续数据的CPU处理部分，从而提高了整体处理效率。
分层Cache：充分利用本地内存和磁盘作为两层缓存，加速对状态数据的访问。
Grouping I/O：对底层I/O进行了优化，使得一次远程I/O调用可以完成多次批量的状态访问，减少了I/O通信的开销。
轻量快照：轻量化的checkpoint快照过程进一步降低了资源消耗。
性能结果
基于Nextmark测试集的结果显示，在Flink 2.0中，存算分离模式下的吞吐量达到了存算一体模式的75%到120%，具体数值取决于不同的查询（query）。值得注意的是，某些查询下存算分离模式的性能甚至优于存算一体模式。这些测试使用了1GB的本地磁盘空间作为缓存，而查询的状态大小范围为1.2GB至4.8GB，表明缓存无法存放全部状态数据，但在这种情况下仍实现了较好的性能表现。
此外，如果增加本地磁盘的空间用于缓存，预计性能将进一步提高。当前版本只是存算分离状态管理的第一个版本，未来版本将继续针对性能瓶颈进行优化，持续改进用户体验和系统性能。
03
Streaming Lakehouse
1. Lambda架构
在处理既有实时又有离线数据需求的场景中，传统上采用Lambda架构。该架构需要构建两条独立的数据处理链路：一条用于实时处理（如Flink结合Kafka），另一条用于离线处理（如Spark结合Iceberg或Hive）。然而，这种架构存在一些问题：
开发效率低：相同的业务逻辑需分别用不同引擎（如Flink和Spark）实现。
口径难一致：由于不同计算引擎实现细节差异，可能导致结果偏差。
技术栈复杂：涉及多种大数据组件，增加了系统复杂性。
存储成本高：为支持实时和离线处理，数据需存储两份，导致存储成本翻倍。
2. Streaming Lakehouse架构
为解决上述问题，Flink推出了Streaming Lakehouse架构，旨在合并实时和离线数据处理链路。这一架构主要依赖于Flink的流批一体计算能力和Paimon的存储能力（支持流读写及批读写），实现了一体化的数据处理方案。主要优势包括：
口径统一：采用同一套引擎和算子实现，确保了实时和离线处理间的数据口径一致性。
简化技术栈：减少了所需的大数据组件数量，降低了系统复杂度。
存储成本低：只需存储一份数据即可满足实时和离线处理的需求，大幅降低了存储成本。
开发效率方面的改进与挑战
尽管Streaming Lakehouse架构在许多方面提供了改进，但在开发效率上仍有提升空间。目前，通过统一使用Flink SQL进行开发，避免了针对不同引擎编写代码的需求，这是一个进步。然而，该架构尚未完全达到理想的“流批一体”状态——即使用一份代码、一套引擎、一份数据就能同时支持实时和离线处理。
3.什么是真正的流批一体
真正的流批一体意味着通过一份代码、一套引擎以及一份数据，即可同时满足实时和离线的数据处理需求。
在当前的实践中，已经实现了部分流批一体的目标：
一份数据：基于Paimon的能力，现在可以只存储一份数据，并支持以流式或批式两种不同的方式来读写。
一套引擎：Flink支持在流模式和批模式之间进行切换，这使得相同的逻辑可以根据需要选择最适合的执行模式。
然而，在实现完全的流批一体方面仍存在一些挑战，尤其是在代码层面：
编程模型差异：尽管实时处理和离线处理都可以使用Flink SQL进行开发，但由于两者采用的编程模型不同，导致最终编写的代码无法完全一致。具体来说：
实时处理：面向的是无限的数据流，通常需要基于时间窗口来进行聚合和关联等操作。
离线处理：通常将数据按时间分成多个分区（partition），每个分区被视为一个有限的数据集。在运行时只需指定要处理哪个分区，而在实际的数据处理逻辑中不需要考虑时间窗口等概念。
4. Materialized Table
为了解决流批一体中存在的编程模型差异问题，Flink SQL引入了物化表（Materialized Table）的概念。通过定义数据新鲜度，自动选择合适的执行模式（流或批），使得用户无需关心底层执行细节，仅需关注业务层面的数据更新时效性要求。
（1）如何使用物化表
创建物化表：使用类似于CREATE TABLE的语法来创建一张物化表，并定义其schema。在底层，目前是基于Paimon表来实现存储。
指定分区字段及数据新鲜度：需要指定表的分区字段以及数据的新鲜度。数据新鲜度是一个关键概念，用于描述业务对数据更新时效性的需求。根据用户设定的数据新鲜度，Flink能够自动判断并选择使用流模式还是批模式来更新物化表中的数据。
定义SQL查询：通过编写一个SQL查询来描述物化表中数据的生成逻辑。
这部分逻辑更接近于传统的批处理方式，但增加了数据新鲜度的概念。
（2）物化表的运维便利性
物化表不仅简化了开发过程，还在运维方面提供了极大的便利性：
修改数据新鲜度：可以通过简单的ALTER语句直接设置物化表的新鲜度。
数据回刷操作：同样利用ALTER语句，配合REFRESH命令，可以轻松实现对特定分区的数据回刷。
5. Flink X Paimon深度集成
除物化表外，Flink 2.0在Flink与Paimon集成方面还做了大量工作，包括场景拓展（如针对宽表拼接、维表查询等常见场景的功能和性能定制优化）以及引擎能力提升（优化Flink读写Paimon表的性能，改进使用Flink进行Paimon表管理操作的易用性）等。
04
AI实时化探索
1. AI技术趋势
近年来，AI技术的发展可以大致分为四个层次的应用：
基础模型能力：基于通用数据和信息训练出的大语言模型，赋予AI对世界的认知和思考的基础能力。
领域知识增强：通过专业领域的知识（如企业知识库或个人用户的私有数据）增强AI的能力，使其成为特定领域或业务场景下的专家。
实时数据增强：使AI具备感知和响应实时业务数据及事件的能力。例如，在客服聊天机器人中，AI应能了解客户最近使用的产品和服务，以提供更精准的帮助。
Agentic AI：不仅限于内容的输入输出，还包括从外部主动获取数据、执行行动来影响外部世界的能力。
随着技术的发展，越接近实际应用层面，对于实时性的需求就越强烈。正如一句流行的话所说：“AI is only as good as the data it operates on.”，数据质量决定了AI能力的上限。
2. Retrieval-Augmented Generation（RAG）
在这一背景下，Flink在实时数据处理中的作用显得尤为重要。一个典型的使用Flink实现RAG架构的例子包括两条链路：
增强链路（蓝色）：Flink持续捕捉企业数据更新，并实时调用大语言模型进行向量化处理，将结果存储到向量数据库中。
检索生成链路（绿色）：实时接收用户请求，调用大语言模型生成向量，并在向量数据库中进行近似检索，结合检索到的上下文信息与用户请求一起传递给大语言模型生成最终内容返回给用户。
3. Flink需要的关键能力
为了支持上述架构，Flink需要以下关键能力：
模型调用：能够调用大语言模型完成向量化（embedding）和内容生成等任务。
向量数据库对接：支持将生成的向量写入向量数据库，并支持高效的向量检索。
半结构化、非结构化数据类型处理：企业数据、用户请求、模型生成结果等多为半结构化或非结构化数据，Flink需高效处理这类数据，包括预处理用户请求、校验AI返回结果等。
目前，Flink社区的工作主要集中在模型调用部分，而向量数据库对接及半/非结构化数据类型的处理正在规划之中。
4. Flink CDC和Flink SQL对模型调用的支持
Flink CDC支持调用大语言模型：Flink CDC的transform已支持调用大语言模型，目前内置OpenAI的embedding和chat两种transform。用户可在CDC的yaml文件中定义model，指定transform名称、底层实现类及模型服务参数等，进而在transform中调用model。
Flink SQL支持模型调用：Flink SQL正在支持模型调用，用户可像定义Catalog一样定义model，指定数据输入输出类型及模型服务参数等。定义后，可在SQL语句中通过function或table function调用模型。此项工作仍在进行中。
05
问答环节
Q1：物化视图在Flink 2.0中是否仅支持Paimon，未来是否会支持其他数据存储表？
A1：Flink中的物化表与物化视图稍有差异，核心在于将底层生成表的数据逻辑或方式对用户屏蔽。目前Flink的物化表仅支持Paimon。但从技术架构设计上，未来可以支持更多数据存储系统。要支持物化表，需具备两方面能力：
将物化表相关元数据作为附加信息存放在表的Catalog中，大部分存储系统可做到。
根据数据新鲜度动态决策流模式或批模式，要求底层存储系统同时支持流和批两种读写方式。目前市面上存储系统中，Paimon相对成熟，其他如Iceberg、Hudi等在这方面能力尚不成熟。
Q2：离线SQL改造成实时化时，如全表聚合等复杂操作，物化表能否解决底层状态问题？
A2：
全量运算（如多年历史数据全量聚合）的实时化业务需求较少，更多是基于过去一段时间数据的计算。
即使是全量计算，使用批运算成本也较高。Flink物化表目前支持流和批两种模式，还在研发第三种方式——增量计算方式。即通过批运算，但每个批之间有状态继承关系，非独立运算，避免重复计算已处理数据，减少状态存储和计算开销，是未来有前景的方向，但此方案仍在研发中。
Q3：Flink处理速度在什么量级，与其他流批引擎（如Storm、Spark）相比有何优缺点？
A3：
处理速度：Flink在生产环境中可达到秒级甚至毫秒级的实时处理速度，具体取决于业务数据量、计算复杂度及资源配置。相比而言，Spark Streaming在实时性上稍逊一筹，而Storm虽然能达到类似Flink的低延迟，但在状态一致性上有劣势。
性能差距：Flink在批处理性能上与Spark存在一定差距，但两者处于同一量级，且Flink正在通过引入类似Spark AQE（Adaptive Query Execution）等优化技术缩小差距。
Q4：Flink的row by row处理模式与基于文件存储的数据湖匹配度低，是否适合数据湖，未来Flink是否会向增量计算方向发展？
A4：确实，Flink的row by row处理模式与数据湖基于文件存储的特性存在不匹配。如果底层存储是数据湖，使用Flink这种实时处理模式，会付出计算成本，但数据更新频率低，没有获得相应收益。
解决方案探讨：Paimon支持table store和log store两种存储方式。若需实时消费，可订阅log store的change log，无需等待文件级别的Flush，但可能面临数据未完成两阶段提交、后续需重写的风险；若数据写入log store后一段时间未被消费，已完成compaction等优化操作，下游可高效地以batch scan方式读取数据。
| 欢迎光临 链载Ai (https://www.lianzai.com/) | Powered by Discuz! X3.5 |