Apache Fluss（孵化中）是新一代流式存储系统，旨在解决传统架构中数据重复复制、高成本与复杂性等问题。它基于 Apache Arrow 构建，支持列式存储、实时更新与高效查询，融合流处理与湖仓架构优势，适用于实时分析、AI 与多模态数据场景。Fluss 提供统一读写、冷热分层与开放生态，已在阿里巴巴大规模落地，助力企业实现低成本、高效率的实时数据处理。
欢迎阅读对 Apache Fluss（孵化中） 的深度解读 —— 这是一项突破性的流式存储解决方案，旨在彻底重塑实时数据分析与人工智能（AI）基础设施的未来。
本文内容基于伍翀在 Flink Forward Asia 2025 新加坡大会上的主题演讲，旨在介绍 Fluss 作为下一代流式存储系统的核心理念与技术优势。我们将深入探讨 Fluss 如何弥合传统流处理系统与现代湖仓（Lakehouse）架构之间的鸿沟，显著提升机器学习特征工程、多模态 AI 数据摄入等前沿场景下的存储能力。
在当今“数据驱动”的时代，Apache Kafka 已成为几乎所有流式数据架构的基石。它在微服务间的事件通信、高吞吐日志采集等方面表现出色。
当我们需要从流数据中获取实时洞察时，通常会使用 Apache Flink 进行处理与转换。而为了实现分层建模，我们常将数据写回 Kafka 的多层主题（Topic）中：比如青铜层（bronze）、银层（silver）、金层（gold）——即所谓的“数据湖勋章架构（Medallion Architecture）”。
Kafka 本身不支持高效的 KV 查询。于是我们不得不把数据复制一份到 Redis 这类 KV 存储中，只为支持维度表关联。
Kafka 并不是为“可查询”而设计的。你只能再次复制数据，导入 ClickHouse 等 OLAP 系统才能做交互式分析。
对不起，还得再复制一次——这次要转成 Iceberg、Paimon 等开放格式。
于是，同样的数据在 Kafka、Redis、ClickHouse、Iceberg 之间被反复复制，形成“数据影子系统”。
几乎没有任何业务价值。它既不能被查询，也不适合长期存储，更不支持更新。只是一个“黑盒中转站”。
这并不是 Kafka 的错。Kafka 的设计初衷是高吞吐、低延迟的事件分发，而非分析或 AI 场景。它缺乏：
正是基于这一深刻认知，Fluss 项目在两年前应运而生 ，一个从零构建、专为分析与 AI 场景优化的流式存储系统。它的目标很明确：终结数据重复复制，打造统一、高效、低成本的实时数据底座。
它是一个支持亚秒级读写延迟的流式存储系统，底层基于 Apache Arrow 构建，采用列式日志结构（columnar log）。这一设计赋予了 Fluss 天然的分析优势。
得益于 Arrow 的列式格式，Fluss 支持流式列裁剪与流式分区裁剪。查询时仅读取所需列与分区，大幅降低网络传输开销，提升分析效率。
Fluss 支持将热数据保留在本地高速存储中，冷数据则自动归档至湖仓（如 Iceberg、Paimon），实现成本与性能的平衡。归档数据采用标准开放格式，可被 Spark、Trino、StarRocks 等引擎直接读取。
Fluss 引入了 Union Read 特性，智能合并热数据（Fluss）与冷数据（湖仓）。它先读取历史数据，再无缝衔接实时流，无重复、无遗漏。Flink 已原生支持 Union Read，StarRocks 集成也在推进中。
通过 Fluss，企业可以实现一个真正统一的实时湖仓架构——数据只存一份，却能同时满足：
需要强调的是，Fluss 并非要取代湖仓，而是为湖仓注入强大的流式能力。它让数据在“流”与“湖”之间自由流动，实现真正的数据融合。
Fluss 内置一个分层服务（tiering service），持续将 Fluss 中的数据转换为 Iceberg/Paimon 等格式，写入湖仓。这一机制类似于数据库的“冷热分层”策略，但 Fluss 将湖仓作为“冷层”，确保冷数据对整个生态开放可读。
当流任务需要回溯历史数据时，湖仓提供快速“追赶”能力；当执行批分析时，Fluss 可将最近几分钟的最新数据补全至湖仓，确保批处理结果也是“实时的”。
Fluss 不是纸上谈兵。它已在阿里巴巴大规模落地，展现出强大的稳定性与性能。
淘宝每天产生海量日志：点击流、用户行为、订单流等，是下游分析与 AI 模型的数据基础。
流式 Join 是 Flink 的核心能力，由于 Kafka 无法同时提供流读和索引点查的能力，所以在 Kafka+Flink 的架构下需将所有上游数据缓存在 Flink 状态中。例如，阿里搜索推荐团队需关联“页面点击流”与“订单流”做归因分析。两个流数据量巨大，在 Kafka+Flink 的架构下状态高达 100 TB，这导致作业不稳定、checkpoint超时、资源消耗巨大等问题。
语义等价于传统 Join，但让 Flink 作业变得很轻量和灵活，同时在 Fluss 中的索引能被多个 Flink 作业复用。
首先是多模态数据的崛起，与传统分析主要依赖结构化数据不同，AI 应用越来越多地处理文本、图像、音频、视频等非结构化数据，这对存储和处理系统提出了更高的灵活性要求。其次是流式数据的需求激增——AI 智能体（Agent）不再满足于基于历史数据的离线推理，而是需要实时感知、即时决策，要求数据管道具备低延迟、持续更新的能力。最后是开放数据的重要性日益凸显——为了实现跨系统、跨工具的协同，数据格式必须开放、标准、可互操作，就像分析领域依赖 Parquet、Iceberg 一样，AI 也需要属于自己的“通用语言”。Fluss 正是基于这样的洞察，致力于构建一个支持多模态、原生流式、拥抱开放生态的下一代数据底座。
未来的 Fluss 将不仅是分析引擎的底座，更是多模态 AI 实时流水线的核心：
加入 Apache 是 Fluss 社区的重要里程碑，标志着它迈向更开放、更中立、更可持续的未来。
现在，适用于 Apache Fluss 的阿里云托管服务已启动邀测，现已在北京、杭州、新加坡等区域开服。
它不是 Kafka 的替代品，也不是湖仓的竞争对手，而是一个融合者：将流、批、分析、AI 统一在同一个高效、开放、实时的数据底座之上。
随着其在 Apache 社区的持续演进，Fluss 有望成为未来数据架构的“实时神经中枢”，助力企业真正释放数据与 AI 的全部潜能。
本文整理自抖音集团数据工程师在Flink Forward Asia 2024的分享，围绕流式湖仓架构的背景、实践与未来展望展开。内容涵盖实时数仓架构演进、Paimon的应用与优化，以及在长周期指标计算和大流量场景下的落地实践经验。
释放Qwen3-Coder潜力：Bolt+AnalyticDB Supabase，打造真正的生产力工具
阿里云发布Qwen3-Coder，具备卓越自主编码能力，支持超长上下文窗口与工具调用，结合Bolt与AnalyticDB Supabase，实现高效开发。
本文整理自阿里云的高级技术专家、Apache Flink PMC 成员李麟老师在 Flink Forward Asia 2025 新加坡[1]站 —— 实时 AI 专场中的分享。将带来关于 Flink 2.1 版本中 SQL 在实时数据处理和 AI 方面进展的话题。
简介：本文整理自阿里云高级技术专家李麟在Flink Forward Asia 2025新加坡站的分享，介绍了Flink 2.1 SQL在实时数据处理与AI融合方面的关键进展，包括AI函数集成、Join优化及未来发展方向，助力构建高效实时AI管道。
本文介绍了 Stable Diffusion 文生图模型的工作流程，包括输入文本描述、语义编码、图像生成与解码等关键步骤，揭示了 AI 如何将文字转化为图像的技术原理。
本文聚焦前端领域WebSocket断网重连难题，深入解析指数退避算法的工业级实践路径。首先指出传统固定间隔、线性递增重连策略在效率与服务器压力间的失衡问题，随后拆解指数退避算法“指数增长+随机抖动+最大间隔约束”的核心逻辑。文章详细阐述算法与WebSocket生命周期的适配要点，包括重连时机甄别、状态原子化管理，还介绍网络状态感知融合、重连超时设置、数据缓存恢复等优化方向，并结合大型在线协作平台案例验证效果，同时梳理开发者常见误区与避坑方法，最后展望算法与AI、跨端场景结合的未来方向，为前端构建稳健实时应用提供完整指南。
【新模型速递】PAI-Model Gallery云上一键部署Qwen3-Coder模型
Qwen3-Coder 是通义千问最新开源的 AI 编程大模型正式开源，拥有卓越的代码和 Agent 能力，在多领域取得了开源模型的 SOTA 效果。PAI 已支持最强版本 Qwen3-Coder-480B-A35B-Instruct 的云上一键部署。
5.24 Declaring Attributes of Functions【转】
【无人机】采用NOMA的节能多无人机多接入边缘计算（Matlab代码实现）
【电机轴承监测】基于matlab声神经网络电机轴承监测研究（Matlab代码实现）
【无人机编队】基于非支配排序遗传算法II NSGA-II高效可行的无人机离线集群仿真研究（Matlab代码实现）
【电力系统】基于matlab虚拟电厂内部负荷调度优化模型（matlab+yalmip+cplex）（Matlab代码实现）