Apache Flink 1.13.0 发布公告

简介: Apache Flink 社区很高兴宣布 Flink 1.13.0 的发布!200 多个贡献者为这个新版本处理了 1000 多个问题。该版本使我们迈出了一大步:将流处理应用程序变得与其他任何应用程序一样自然且易于管理。新的反应式扩展模式意味着通过仅更改并行进程数,就可以像在任何其他应用程序中一样扩展和扩展流应用程序。

Apache Flink 社区很高兴宣布 Flink 1.13.0 的发布!200 多个贡献者为这个新版本处理了 1000 多个问题。


该版本使我们迈出了一大步:将流处理应用程序变得与其他任何应用程序一样自然且易于管理。新的反应式扩展模式意味着通过仅更改并行进程数,就可以像在任何其他应用程序中一样扩展和扩展流应用程序。


该版本还突出显示了一系列改进,可以帮助用户更好地了解应用程序的性能。当流的流动速度不如您期望的那样快时,它们可以帮助您理解原因:加载和反压可视化可识别瓶颈,CPU 火焰图可识别应用程序中的热代码路径,以及状态访问延迟以了解如何 国家后端正在跟上。


除了这些功能之外,Flink 社区还对整个系统进行了很多改进,其中一些我们将在本文中进行讨论。我们希望您喜欢新版本和新功能。在本文结尾处,我们描述了从早期版本的 Apache Flink 升级时要注意的更改。


Notable features

Reactive scaling

响应式缩放是 Flink 计划的最新成果,旨在使流处理应用程序像其他任何应用程序一样自然且易于管理。


Flink 在资源管理和部署方面具有双重性质:您可以将Flink应用程序部署到诸如 Kubernetes 或 Yarn 之类的资源协调器上,从而 Flink 可以主动管理资源并根据需要分配和释放工作人员。这对于快速更改其所需资源的作业和应用程序(例如批处理应用程序和临时 SQL 查询)特别有用。应用程序并行性规则将遵循工作程序的数量。在 Flink 应用程序的上下文中,我们称此为主动缩放。


对于长时间运行的流应用程序,将其像其他任何长时间运行的应用程序一样部署通常是一个更好的模型:该应用程序实际上不需要知道它可以在K8,EKS,Yarn 等上运行,并且不需要 设法获得一定数量的工人;取而代之的是,它仅使用分配给它的工人数。工人规则的数量,应用程序并行度会对此进行调整。在 Flink 的上下文中,我们称之为反应式缩放。


应用程序部署模式开始了这项工作,使部署更像应用程序(通过避免两个单独的部署步骤来(1)启动集群和(2)提交应用程序)。响应式缩放模式可以完成此操作,现在您不必再使用额外的工具(脚本或 K8s 运算符)来保持工作程序的数量和应用程序并行性设置的同步。


现在,您可以像其他典型应用程序一样在 Flink 应用程序周围放置自动缩放器—只要您在配置自动缩放器时注意重新缩放的成本即可:有状态的流应用程序在缩放时必须四处移动状态。


要尝试反应式扩展模式,请添加调度程序模式:反应性配置条目并部署应用程序集群(独立或 Kubernetes )。查看反应式缩放文档以获取更多详细信息。


Analyzing application performance

像任何应用程序一样,分析和理解 Flink 应用程序的性能至关重要。由于 Flink 应用程序通常是数据密集型(处理大量数据),并且同时有望在(接近)实时延迟范围内提供结果,因此通常甚至更为关键。


当某个应用程序不再符合数据速率,或者某个应用程序占用的资源超出您的预期时,这些新工具可以帮助您查找原因:


Bottleneck detection, Back Pressure monitoring


性能分析期间的第一个问题通常是:瓶颈是哪个操作?


为了帮助回答这个问题,Flink 公开了有关任务繁忙(正在执行工作)和背压(具有执行工作的能力,但不能执行任务的原因,因为其后继操作员无法接受更多结果)的度量标准。瓶颈的候选者是繁忙的操作员,其前任承受了压力。


Flink 1.13 带来了改进的背压度量系统(使用任务邮箱计时而不是线程堆栈采样),并且重新制作了工作数据流的图形表示,并带有颜色编码以及繁忙度和背压比率。



CPU flame graphs in Web UI

性能分析过程中的下一个问题通常是:哪一部分的操作是昂贵的?


一种可视有效的调查方法是火焰图。它们有助于回答以下问题:-哪些方法当前正在消耗 CPU 资源?-一种方法的 CPU 消耗与其他方法相比如何?-堆栈上的哪一系列调用导致执行特定方法?


火焰图是通过重复采样线程堆栈轨迹而构造的。每个方法调用都由一个条形图表示,其中该条形图的长度与它在样本中出现的次数成正比。启用后,将在新的 UI 组件中为选定的操作员显示图形。



火焰图的创建成本很高:它们可能会导致处理开销,并给 Flink 的度量系统带来沉重的负担。因此,用户需要在配置中显式启用它们。


Access Latency Metrics for State

另一个可能的性能瓶颈可能是状态后端,尤其是当您的状态大于 Flink 可用的主内存并且您正在使用 RocksDB 状态后端时。


这并不是说 RocksDB 的运行速度很慢(我们喜欢 RocksDB!),但是它对达到良好的性能有一些要求。例如,很容易因磁盘资源类型错误而使 RocksDB 在云设置上对 IOP 的需求感到饥饿。


在 CPU 火焰图的顶部,新的状态后端延迟指标可以帮助您了解状态后端是否响应。例如,如果您看到 RocksDB 状态访问开始花费毫秒,那么您可能需要研究内存和 I / O 配置。可以通过设置 state.backend.rocksdb.latency-track-enabled 选项来激活这些指标。对指标进行了采样,并且这些指标的收集应对 RocksDB 状态后端性能产生边际影响。


Switching State Backend with savepoints

从保存点恢复时,您现在可以更改 Flink 应用程序的状态后端。这意味着应用程序的状态不再被锁定在最初启动该应用程序时所使用的状态后端中。


例如,这使它有可能首先从 HashMap 状态后端(JVM Heap 中的纯内存)开始,然后在状态变得太大时切换到 RocksDB 状态后端。


在后台,Flink 现在具有规范的保存点格式,在为保存点创建数据快照时,所有状态后端都使用该格式。


User-specified pod templates for Kubernetes deployments

Kubernetes 本地部署(Flink 在其中与 K8S 主动对话以启动和停止 Pod)现在支持自定义 Pod 模板。


使用这些模板,用户可以以 Kubernetes-y 的方式设置和配置 JobManagers 和 TaskManagers 窗格,并具有 Flink的Kubernetes 集成中直接内置的配置选项之外的灵活性。


Unaligned Checkpoints - production-ready

未对齐的检查点已经成熟到可以鼓励所有用户尝试的程度,如果他们发现应用程序存在背压问题。


特别是,这些更改使“未对齐检查点”更易于使用:


现在,您可以从未对齐的检查点重新缩放应用程序。如果您需要从保留的检查点扩展应用程序,这将非常方便,因为您无法(负担得起)创建保存点。


对于没有反压的应用程序,启用未对齐的检查点比较便宜。现在,未对齐的检查点可以超时自动适应性地触发,这意味着如果对齐阶段花费的时间比未对齐的检查点更长,则检查点将从对齐的检查点开始(不存储任何进行中的事件),然后退回到未对齐的检查点(存储一些正在进行的事件)。一定的时间。


在检查点文档中找到有关如何启用未对齐检查点的更多信息。


Machine Learning Library moving to a separate repository

为了加快 Flink 机器学习工作(流式,批处理和统一机器学习)的开发,该工作已移至 Flink 项目下的新存储库 flink-ml。我们在这里采用类似有状态功能的方法,在这种方法中,一个单独的存储库通过允许更多轻量级的贡献工作流和单独的发布周期来帮助加快了开发速度。


请继续关注机器学习方面的更多更新,例如与 ALink(Flink 上许多常见的机器学习算法的套件)或 Flink 和 TensorFlow 集成的相互作用。


Notable SQL & Table API improvements

像以前的版本一样,SQL 和 Table API 仍然是一大发展领域。


Windows via Table-valued functions

定义时间窗口是流 SQL 查询中最常见的操作之一。Flink 1.13 介绍了一种定义窗口的新方法:通过表值函数。这种方法不仅表达能力更强(允许您定义新的窗口类型),而且完全符合 SQL 标准。Flink 1.13 支持新的语法中的 TUMBLE 和 HOP 窗口,后续的版本中还会有 SESSION 窗口。为了演示增加的表达能力,考虑下面两个例子。一种新的累积窗函数,它给窗口分配一个扩展步长直到达到最大窗口大小


SELECT window_time, window_start, window_end, SUM(price) AS total_price 
  FROM TABLE(CUMULATE(TABLE Bid, DESCRIPTOR(bidtime), INTERVAL '2' MINUTES, INTERVAL '10' MINUTES))
GROUP BY window_start, window_end, window_time;


您可以引用表值窗口函数的窗口开始时间和窗口结束时间,从而使新类型的构造成为可能。例如,除了常规的窗口聚合和窗口连接之外,您现在可以表示窗口 Top-K 聚合


SELECT window_time, ...
  FROM (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY window_start, window_end ORDER BY total_price DESC) 
      as rank 
    FROM t
  ) WHERE rank <= 100;


Improved interoperability between DataStream API and Table API/SQL


这个版本从根本上简化了 DataStream API 和 Table API 程序的混合。Table API 是开发应用程序的好方法,它具有声明性和许多内置函数。但有时,您需要转到 DataStream API,以获得其表达性、灵活性和对状态的显式控制。


新方法 StreamTableEnvironment.toDataStream()/.fromDataStream()可以将 DataStream API 中的数据流建模为表源或汇。自动转换类型、事件时间和水印。此外,Row 类(表示来自表 API 的行事件)已经得到了很大的改进(改进了 toString()/hashCode()/equals()方法的行为),现在支持按名称访问字段,并支持稀疏表示。


Table table=tableEnv.fromDataStream(
 dataStream,Schema.newBuilder()
 .columnByMetadata("rowtime","TIMESTAMP(3)")
 .watermark("rowtime","SOURCE_WATERMARK()")
 .build());
DataStream<Row> dataStream=tableEnv.toDataStream(table)
 .keyBy(r->r.getField("user"))
 .window(...)


SQL Client: Init scripts and Statement Sets


SQL 客户端是直接运行和部署 SQL 流和批处理作业的便捷方法,而无需从命令行编写任何代码,也无需将其作为 CI / CD 工作流的一部分。


此版本大大改进了 SQL 客户端的功能。现在,SQL 客户端和 SQL 脚本都支持 Java 应用程序可用的几乎所有操作(通过编程方式从TableEnvironment 启动查询时)。这意味着 SQL 用户在其 SQL 部署中需要的粘合代码少得多。


Easier Configuration and Code Sharing


将不再支持 YAML 文件来配置 SQL 客户端。而是,客户端在执行主 SQL 脚本之前接受一个或多个初始化脚本来配置会话。


这些初始化脚本通常将在团队/部署之间共享,并且可用于加载公用目录,应用公用配置设置或定义标准视图。


./sql-client.sh -i init1.sql init2.sql -f sqljob.sql

More config options

更大的可识别配置选项集和改进的 SET / RESET 命令使从 SQL 客户端和 SQL 脚本中定义和控制执行变得更加容易。


Multi-query Support with Statement Sets

多查询执行使您可以将多个 SQL 查询(或语句)作为单个 Flink 作业执行。这对于无限期运行的 SQL 查询流特别有用。


语句集是将应该一起执行的查询组合在一起的机制。


以下是可以通过 SQL 客户端运行的 SQL 脚本的示例。它设置和配置环境并执行多个查询。该脚本捕获端到端的查询以及所有环境设置和配置工作,从而使其成为一个独立的部署工件。


-- set up a catalog
CREATE CATALOG hive_catalog WITH ('type' = 'hive');
USE CATALOG hive_catalog;
-- or use temporary objects
CREATE TEMPORARY TABLE clicks (
  user_id BIGINT,
  page_id BIGINT,
  viewtime TIMESTAMP
) WITH (
  'connector' = 'kafka',
  'topic' = 'clicks',
  'properties.bootstrap.servers' = '...',
  'format' = 'avro'
);
-- set the execution mode for jobs
SET execution.runtime-mode=streaming;
-- set the sync/async mode for INSERT INTOs
SET table.dml-sync=false;
-- set the job's parallelism
SET parallism.default=10;
-- set the job name
SET pipeline.name = my_flink_job;
-- restore state from the specific savepoint path
SET execution.savepoint.path=/tmp/flink-savepoints/savepoint-bb0dab;
BEGIN STATEMENT SET;
INSERT INTO pageview_pv_sink
SELECT page_id, count(1) FROM clicks GROUP BY page_id;
INSERT INTO pageview_uv_sink
SELECT page_id, count(distinct user_id) FROM clicks GROUP BY page_id;
END;
Hive query syntax compatibility


现在,您可以使用 Hive SQL 语法针对 Flink 编写 SQL 查询。除了 Hive 的 DDL 方言外,Flink 现在还接受常用的 Hive DML 和 DQL 方言。


要使用 Hive SQL 方言,请将 table.sql-dialect 设置为 hive 并加载 HiveModule。后者很重要,因为 Hive 的内置功能对于正确的语法和语义兼容性是必需的。以下示例说明了这一点:


CREATE CATALOG myhive WITH ('type' = 'hive'); -- setup HiveCatalog
USE CATALOG myhive;
LOAD MODULE hive; -- setup HiveModule
USE MODULES hive,core;
SET table.sql-dialect = hive; -- enable Hive dialect
SELECT key, value FROM src CLUSTER BY key; -- run some Hive queries


请注意,Hive 方言不再支持 Flink 的 SQL 语法的 DML 和 DQL 语句。切换回 Flink 语法的默认方言。


Improved behavior of SQL time functions


与时间打交道是任何数据处理的关键要素。但是同时,处理数据时,处理不同的时区,日期和时间是一项非常棘手的任务。


在 Flink 1.13 中。我们在简化与时间相关的函数的使用上付出了很多努力。我们调整了(更具体的)函数的返回类型,例如:PROCTIME(),CURRENT_TIMESTAMP,NOW()。


此外,您现在还可以在 TIMESTAMP_LTZ 列上定义事件时间属性,以在夏时制的支持下优雅地执行窗口处理。


请参阅发行说明以获取完整的更改列表。


Notable PyFlink improvements

PyFlink 中此发行版的总体主题是使 Python DataStream API 和 Table API 更接近于与 Java / Scala API 的功能对等。


Stateful operations in the Python DataStream API

借助 Flink 1.13,Python 程序员现在还可以充分享受 Apache Flink 的状态流处理 API 的全部潜能。Flink 1.12 中引入的经过重新设计的Python DataStream API 现在具有完整的有状态功能,允许用户记住状态中事件的信息并稍后对其采取行动。


有状态处理能力是许多更复杂的处理操作的基础,这些操作需要记住各个事件之间的信息(例如,窗口操作)。


此示例显示使用状态的自定义计数窗口实现:


class CountWindowAverage(FlatMapFunction):
    def __init__(self, window_size):
        self.window_size = window_size
    def open(self, runtime_context: RuntimeContext):
        descriptor = ValueStateDescriptor("average", Types.TUPLE([Types.LONG(), Types.LONG()]))
        self.sum = runtime_context.get_state(descriptor)
    def flat_map(self, value):
        current_sum = self.sum.value()
        if current_sum is None:
            current_sum = (0, 0)
        # update the count
        current_sum = (current_sum[0] + 1, current_sum[1] + value[1])
        # if the count reaches window_size, emit the average and clear the state
        if current_sum[0] >= self.window_size:
            self.sum.clear()
            yield value[0], current_sum[1] // current_sum[0]
        else:
            self.sum.update(current_sum)
ds = ...  # type: DataStream
ds.key_by(lambda row: row[0]) \
  .flat_map(CountWindowAverage(5))
User-defined Windows in the PyFlink DataStream API


Flink 1.13 在 PyFlink DataStream API 中添加了对用户定义窗口的支持。程序现在可以使用标准窗口定义以外的窗口。


因为 Windows 是处理无限制流的所有程序的核心(通过将流拆分为有界大小的“桶”),所以这大大提高了 API 的可表达性。


Row-based operation in the PyFlink Table API

Python Table API 现在支持基于行的操作,即行上的自定义转换函数。这些函数是在内置函数之外的表上应用数据转换的简便方法。


这是在 Python Table API 中使用 map()操作的示例:


@udf(result_type=DataTypes.ROW(
  [DataTypes.FIELD("c1", DataTypes.BIGINT()),
   DataTypes.FIELD("c2", DataTypes.STRING())]))
def increment_column(r: Row) -> Row:
  return Row(r[0] + 1, r[1])
table = ...  # type: Table
mapped_result = table.map(increment_column)


除了 map()之外,API 还支持 flat_map(),aggregate(),flat_aggregate()和其他基于行的操作。这使 Python Table API 在与Java Table API 的功能奇偶性方面迈出了一大步。


Batch execution mode for PyFlink DataStream programs

PyFlink DataStream API 现在还支持有界流的批处理执行模式,这是 Flink 1.12 中为 Java DataStream API 引入的。


批处理执行模式通过利用受限流的本质来绕过状态后端和检查点,从而简化了操作并提高了受限流上程序的性能。


Other improvements

Flink Documentation via Hugo

Flink 文档已从 Jekyll 迁移到 Hugo。如果您发现缺少的东西,请告诉我们。我们也很想知道您是否喜欢新的外观。


Exception histories in the Web UI

Flink Web UI 将显示最多 n 个导致作业失败的最后异常。这有助于调试根故障导致后续故障的方案。根源故障原因可以在异常历史记录中找到。


Better exception / failure-cause reporting for unsuccessful checkpoints

Flink 现在为失败或中止的检查点提供统计信息,从而使无需分析日志即可更轻松地确定失败原因。


仅在检查点成功的情况下,以前版本的 Flink 才报告指标(例如,持久数据的大小,触发时间)。


Exactly-once JDBC sink

从 1.13 开始,JDBC 接收器可以通过在检查点上事务性地提交结果,来保证一次准确地交付符合 XA 的数据库的结果。目标数据库必须具有(或链接到)XA 事务管理器。


该连接器当前仅适用于 DataStream API,并且可以通过 JdbcSink.exactlyOnceSink(...)方法(或直接实例化 JdbcXaSinkFunction)来创建。


PyFlink Table API supports User-Defined Aggregate Functions in Group Windows

PyFlink 的 Table API 中的 Group Windows 现在支持常规的 Python 用户定义的集合函数(UDAF)和 Pandas UDAF。这些功能对于许多分析和ML培训计划而言至关重要。


Flink 1.13 在以前的版本中进行了改进,以前的版本仅在无限制的 Group-by 聚合中支持这些功能。


Improved Sort-Merge Shuffle for Batch Execution

Flink 1.13 改进了批处理执行程序的内存稳定性和排序合并阻塞改组的性能,该程序最初是通过 FLIP-148 在 Flink 1.12 中引入的。


具有更高并行度(1000s)的程序不应再频繁触发 OutOfMemoryError:Direct Memory。通过更好的 I / O 调度和广播优化,可以提高性能(尤其是在旋转磁盘上)。


HBase connector supports async lookup and lookup cache

HBase 查找表源现在支持异步查找模式和查找缓存。通过针对 HBase 的查找联接,这极大地提高了表/ SQL作业的性能,同时在典型情况下减少了对 HBase 的 I / O 请求。


在以前的版本中,HBase 查找源仅同步通信,从而降低了管道利用率和吞吐量。


Changes to consider when upgrading to Flink 1.13
FLINK-21709 - The old planner of the Table & SQL API has been deprecated in Flink 1.13 and will be dropped in Flink 1.14. The Blink engine has been the default planner for some releases now and will be the only one going forward. That means that both the BatchTableEnvironment and SQL/DataSet interoperability are reaching the end of life. Please use the unified TableEnvironment for batch and stream processing going forward.
FLINK-22352 The community decided to deprecate the Apache Mesos support for Apache Flink. It is subject to removal in the future. Users are encouraged to switch to a different resource manager.
FLINK-21935 - The state.backend.async option is deprecated. Snapshots are always asynchronous now (as they were by default before) and there is no option to configure a synchronous snapshot anymore.
FLINK-17012 - The tasks’ RUNNING state was split into two states: INITIALIZING and RUNNING. A task is INITIALIZING while it loads the checkpointed state, and, in the case of unaligned checkpoints, until the checkpointed in-flight data has been recovered. This lets monitoring systems better determine when the tasks are really back to doing work by making the phase for state restoring explicit.
FLINK-21698 - The CAST operation between the NUMERIC type and the TIMESTAMP type is problematic and therefore no longer supported: Statements like CAST(numeric AS TIMESTAMP(3)) will now fail. Please use TO_TIMESTAMP(FROM_UNIXTIME(numeric)) instead.
FLINK-22133 The unified source API for connectors has a minor breaking change: The SplitEnumerator.snapshotState() method was adjusted to accept the Checkpoint ID of the checkpoint for which the snapshot is created.

Resources


现在,可以在 Flink 网站的更新的“下载”页面上找到二进制分发和源工件,并且可以在 PyPI 上获得 PyFlink 的最新分发。


如果您打算将安装程序升级到 Flink 1.13,请仔细阅读发行说明。此版本与以前的 1.x 版本的 API 兼容,这些版本的 API 使用 @Public 注释进行了注释。


您还可以查看完整的发行版变更日志和更新的文档,以获取变更和新功能的详细列表。


这次的版本更新带来了非常多的新特征,具体的改动可以查看官网,后面我也会针对新的功能做进一步的解析.


相关实践学习
基于Hologres+Flink搭建GitHub实时数据大屏
通过使用Flink、Hologres构建实时数仓,并通过Hologres对接BI分析工具(以DataV为例),实现海量数据实时分析.
实时计算 Flink 实战课程
如何使用实时计算 Flink 搞定数据处理难题?实时计算 Flink 极客训练营产品、技术专家齐上阵,从开源 Flink功能介绍到实时计算 Flink 优势详解,现场实操,5天即可上手! 欢迎开通实时计算 Flink 版: https://cn.aliyun.com/product/bigdata/sc Flink Forward Asia 介绍: Flink Forward 是由 Apache 官方授权,Apache Flink Community China 支持的会议,通过参会不仅可以了解到 Flink 社区的最新动态和发展计划,还可以了解到国内外一线大厂围绕 Flink 生态的生产实践经验,是 Flink 开发者和使用者不可错过的盛会。 去年经过品牌升级后的 Flink Forward Asia 吸引了超过2000人线下参与,一举成为国内最大的 Apache 顶级项目会议。结合2020年的特殊情况,Flink Forward Asia 2020 将在12月26日以线上峰会的形式与大家见面。
相关文章
|
2月前
|
人工智能 数据处理 API
阿里云、Ververica、Confluent 与 LinkedIn 携手推进流式创新,共筑基于 Apache Flink Agents 的智能体 AI 未来
Apache Flink Agents 是由阿里云、Ververica、Confluent 与 LinkedIn 联合推出的开源子项目,旨在基于 Flink 构建可扩展、事件驱动的生产级 AI 智能体框架,实现数据与智能的实时融合。
425 6
阿里云、Ververica、Confluent 与 LinkedIn 携手推进流式创新,共筑基于 Apache Flink Agents 的智能体 AI 未来
|
存储 Cloud Native 数据处理
从嵌入式状态管理到云原生架构:Apache Flink 的演进与下一代增量计算范式
本文整理自阿里云资深技术专家、Apache Flink PMC 成员梅源在 Flink Forward Asia 新加坡 2025上的分享,深入解析 Flink 状态管理系统的发展历程,从核心设计到 Flink 2.0 存算分离架构,并展望未来基于流批一体的通用增量计算方向。
335 0
从嵌入式状态管理到云原生架构:Apache Flink 的演进与下一代增量计算范式
|
4月前
|
SQL 人工智能 数据挖掘
Apache Flink:从实时数据分析到实时AI
Apache Flink 是实时数据处理领域的核心技术,历经十年发展,已从学术项目成长为实时计算的事实标准。它在现代数据架构中发挥着关键作用,支持实时数据分析、湖仓集成及实时 AI 应用。随着 Flink 2.0 的发布,其在流式湖仓、AI 驱动决策等方面展现出强大潜力,正推动企业迈向智能化、实时化的新阶段。
587 9
Apache Flink:从实时数据分析到实时AI
|
4月前
|
SQL 人工智能 API
Apache Flink 2.1.0: 面向实时 Data + AI 全面升级,开启智能流处理新纪元
Apache Flink 2.1.0 正式发布,标志着实时数据处理引擎向统一 Data + AI 平台迈进。新版本强化了实时 AI 能力,支持通过 Flink SQL 和 Table API 创建及调用 AI 模型,新增 Model DDL、ML_PREDICT 表值函数等功能,实现端到端的实时 AI 工作流。同时增强了 Flink SQL 的流处理能力,引入 Process Table Functions(PTFs)、Variant 数据类型,优化流式 Join 及状态管理,显著提升作业稳定性与资源利用率。
526 0
|
3月前
|
人工智能 运维 Java
Flink Agents:基于Apache Flink的事件驱动AI智能体框架
本文基于Apache Flink PMC成员宋辛童在Community Over Code Asia 2025的演讲,深入解析Flink Agents项目的技术背景、架构设计与应用场景。该项目聚焦事件驱动型AI智能体,结合Flink的实时处理能力,推动AI在工业场景中的工程化落地,涵盖智能运维、直播分析等典型应用,展现其在AI发展第四层次——智能体AI中的重要意义。
1299 27
Flink Agents:基于Apache Flink的事件驱动AI智能体框架
|
4月前
|
存储 人工智能 数据处理
对话王峰:Apache Flink 在 AI 时代的“剑锋”所向
Flink 2.0 架构升级实现存算分离,迈向彻底云原生化,支持更大规模状态管理、提升资源效率、增强容灾能力。通过流批一体与 AI 场景融合,推动实时计算向智能化演进。生态项目如 Paimon、Fluss 和 Flink CDC 构建湖流一体架构,实现分钟级时效性与低成本平衡。未来,Flink 将深化 AI Agents 框架,引领事件驱动的智能数据处理新方向。
485 6
|
4月前
|
消息中间件 存储 Kafka
Apache Flink错误处理实战手册:2年生产环境调试经验总结
本文由 Ververica 客户成功经理 Naci Simsek 撰写,基于其在多个行业 Flink 项目中的实战经验,总结了 Apache Flink 生产环境中常见的三大典型问题及其解决方案。内容涵盖 Kafka 连接器迁移导致的状态管理问题、任务槽负载不均问题以及 Kryo 序列化引发的性能陷阱,旨在帮助企业开发者避免常见误区,提升实时流处理系统的稳定性与性能。
430 0
Apache Flink错误处理实战手册:2年生产环境调试经验总结
|
SQL 消息中间件 分布式计算
《Apache Flink 案例集(2022版)》——5.数字化转型——移动云Apache Flink 在移动云实时计算的实践(上)
《Apache Flink 案例集(2022版)》——5.数字化转型——移动云Apache Flink 在移动云实时计算的实践(上)
434 0
|
数据采集 分布式计算 Kubernetes
《Apache Flink 案例集(2022版)》——5.数字化转型——移动云Apache Flink 在移动云实时计算的实践(下)
《Apache Flink 案例集(2022版)》——5.数字化转型——移动云Apache Flink 在移动云实时计算的实践(下)
449 0
|
存储 SQL 传感器
【Flink】(04)Apache Flink 漫谈系列 —— 实时计算 Flink 与 Alibaba Cloud Realtime Compute 剖析2
【Flink】(04)Apache Flink 漫谈系列 —— 实时计算 Flink 与 Alibaba Cloud Realtime Compute 剖析2
851 0
【Flink】(04)Apache Flink 漫谈系列 —— 实时计算 Flink 与 Alibaba Cloud Realtime Compute 剖析2

热门文章

最新文章

推荐镜像

更多