一个 Flutter 武侠文字挂机项目

作者：张庆玉，阿里云计算平台事业部开发工程师

本文整理自 Streaming Lakehouse Meetup 活动分享，阿里云计算平台事业部开发工程师张庆玉分享的 StarRocks 与 Apache Paimon 的深度集成实践，探讨如何构建真正意义上的 Lakehouse Native 数据引擎。

在数据湖已成为企业数字化转型重要基础设施的当下，如何在一个统一的计算引擎中高效处理多种数据源，成为业界关注的焦点。StarRocks 通过与 Paimon 的深度融合，正逐步构建一套完整的 Lakehouse Native 解决方案——不仅支持多源联邦分析，更在性能、功能与可观测性上实现系统性突破。

StarRocks 数据湖总体架构：单一引擎，多源联邦分析

StarRocks 与 Paimon 的结合，首先体现在统一的架构设计理念上。借助统一的 Catalog 机制，StarRocks 能够在一个引擎内同时管理内部表和外部数据湖（如 Paimon 表），并支持跨 Catalog 的联邦查询。

这种设计延续了 StarRocks 存算分离的核心思想。虽然数据存储在远端的数据湖中，但查询执行仍能充分利用 StarRocks 在 OLAP 场景下的全部优化能力——从底层的 CPU 指令集加速、向量化执行引擎，到 I/O 层面的缓存策略与合并读取，都可无缝应用于 Paimon 表的查询过程。这使得数据湖不再只是“冷存储”，而真正成为高性能分析的一部分。

StarRocks+Paimon 发展历程

StarRocks 对 Paimon 的支持并非一蹴而就，而是经历了多个版本的持续打磨。

• StarRocks 3.1: 首次引入 Paimon 外表，通过 JNI （Java Native Interface）实现基本读取能力，并支持 Paimon 物化视图加速查询和谓词下推。这一阶段主要解决“能不能用”的问题。
• StarRocks 3.2: 性能迎来显著提升—— FE 计划阶段引入 Metadata cache，缓存表分区和 manifests 等元数据，大幅加快计划生成；同时支持表级与列级统计信息采集，提升执行计划质量。3.2 版本还实现了物化视图的分区级别刷新功能，避免了全量刷新带来的资源浪费。此外，该版本进一步增强了对 Paimon DV 表的支持——StarRocks 查询引擎现在可以通过 Native Reader 直接读取 DV 表，相比之前基于 MOR（Merge-On-Read）表结构的 JNI 读取实现，读取性能获得大幅提升，尤其适用于高吞吐、低延迟的实时分析场景。
• StarRocks 3.3: 标志着 StarRocks 向 Lakehouse Native 迈出关键一步，多项核心特性相继落地——相关细节将在下文逐一展开。

StarRocks+Paimon 最新进展

功能增强

• Time Travel：StarRocks 现已支持通过 VERSION AS OF 或 TIMESTAMP AS OF 查询历史快照或指定时刻的数据。这一能力在数据审计、故障回滚、AB Test 等场景中具有重要价值，让数据湖具备了更强的时间维度管理能力。

• Paimon Format Table：作为 Paimon 的一种兼容 Hive 格式的表类型，它允许用户将现有 Hive 表直接迁移到 Paimon，而 StarRocks 能无缝识别并高效查询，极大降低了迁移成本。

性能优化

• Native Reader/Writer: 在未开启 DV 的情况下，MOR 表需要在查询时实时合并多个版本的增量数据，只能通过 JNI 调用 Java 层处理，存在类型转换、行列格式转换、JVM GC 等开销，效率低下且易引发 OOM。如今，StarRocks 基于 Paimon CPP SDK，在 BE 的 C++ 代码中直接实现 Paimon Native Scanner，实测显示 MOR 表读取性能提升超过 5 倍。写入侧同样受益，Native Writer 显著提升了写入吞吐。

• Distributed Plan: 面对超大规模表（数十万文件），manifest 解析曾是 FE 的性能瓶颈。为此，StarRocks 引入 Distributed Plan 机制，当 manifest 数量过多时，FE 将解析任务分发至多个 CN 节点并行执行，各节点完成本地谓词下推后返回所需文件列表。这一设计使 plan 阶段的解析能力随 BE 资源线性扩展，有效缓解单点压力。

• DV Index Cache: 在高并发查询 Paimon 主键表时，index manifest 的全局反序列化会造成严重读放大——即使只查一个分桶，也要加载全量索引。于是，DV Index Cache 应运而生：按桶级别缓存 DV index 对象，避免重复解析。由于缓存的是 Java 对象而非序列化字节，还省去了反序列化开销。实测表明，该优化在高并发场景下 QPS 提升超 80%。

可观测性：完善 profile 指标

StarRocks 完善了 Profile 指标体系，覆盖 plan 与执行两个阶段。在 plan 阶段，用户可查看 manifest 缓存命中率、远程读次数、谓词下推效果及最终扫描文件数，用于判断是否需调大缓存或优化查询条件。在 BE 执行阶段，则能清晰区分 JNI 与 native 读取的比例——若 JNI 占比较高，可能提示需要对表进行 full compaction，或考虑切换至 DV 表模式。

未来规划：性能对齐内表

StarRocks 的长期目标很明确：让查询 Paimon 的性能与体验对齐查询 StarRocks 本地表。

目前，BE 执行层的差距已不大——两者均基于列存格式（如 Parquet/ORC），具备类似索引结构，I/O 优化策略也高度通用。真正的挑战在于 FE 的 plan 阶段：Paimon 的 manifest 解析可能因 cache miss 触发高延迟的远程读，导致 plan 耗时波动，影响整体查询稳定性。

未来工作将聚焦于消除 plan 阶段的 latency-sensitive IO，通过更智能的缓存预热、异步解析、元数据压缩等手段，使 Paimon 查询的延迟变得稳定、可预测，彻底告别“毛刺”。

结语

StarRocks 与 Paimon 的深度融合，代表了现代湖仓架构的重要演进方向。它不只是“能查数据湖”，而是真正“懂数据湖”——从架构统一、功能完善到性能极致优化，每一步都围绕真实业务场景展开。

这套 Lakehouse Native 方案已在阿里集团内部多个高并发、低延迟场景中落地验证，为电商、物流、金融等业务提供坚实支撑。随着社区生态的持续壮大，我们有理由相信，StarRocks + Paimon 将成为企业构建下一代实时数据平台的核心引擎。

自然语言理解、摘要生成、代码编写、逻辑推理，OpenAI 等厂商的模型把这些事情做得相当好。但是只有一个问题，那就是 “贵".尤其是在应用上了规模之后，API 调用费用的增长速度会让人心跳加速。

Prompt 缓存是应对这个问题最直接也最容易被忽视的手段。本文会从原理讲到实践，覆盖四种不同层级的缓存策略，配有代码示例和架构图。

LLM 的成本为什么涨得这么快

LLM API 的定价模型就三个维度：输入 Token 数（也就是 Prompt 长度）、输出 Token 数（响应长度）、调用次数。

比如FAQ 机器人、聊天式新人引导助手、内部开发者工具、AI 仪表板——这些应用有一个共同特征：大量重复或高度相似的 Prompt 被反复发送，而期望得到的回答几乎一样。

如果不做缓存的话，每次调用都要按量计费，那费用肯定就爆炸了。

Prompt 缓存是什么

一句话概括：

当相同或等价的 Prompt 再次出现时，直接复用之前的 LLM 响应，而不是重新调用 API。

先查缓存，命中就直接返回；没命中再去调 LLM，拿到结果后存入缓存。

就这一个改动，成本就能降低 30%–90%，具体数字取决于工作负载的重复程度。

策略 1：精确匹配缓存

这是最基础的方案。逻辑非常简单：完全相同的 Prompt 字符串出现时，直接返回缓存结果。

适用场景包括静态 FAQ、政策说明文档、"解释 X"这一类 Prompt，以及聊天机器人中反复出现的 system prompt。

下面是 Node.js 的实现：

 import crypto from "crypto";  

const cache = new Map();  

function hashPrompt(prompt) {  
  return crypto.createHash("sha256").update(prompt).digest("hex");  
}  

async function getLLMResponse(prompt) {  
  const key = hashPrompt(prompt);  

  // Step 1: Cache lookup  
  if (cache.has(key)) {  
    return cache.get(key);  
  }  

  // Step 2: Call LLM API  
  const response = await callLLM(prompt);  

  // Step 3: Store in cache  
  cache.set(key, response);  

  return response;  
 }

为什么要对 Prompt 做哈希？因为 Prompt 本身可能很长，哈希之后得到固定长度的 key，查找速度快，SHA-256 的碰撞概率也低到可以忽略。

内存缓存的优点是极快，单实例或小规模系统用起来非常合适。但是这样做也进程重启缓存就没了，多实例之间也无法共享。

策略 2：规范化缓存

精确匹配有一个很容易遇到的问题：Prompt 里多一个空格、少一个换行、大小写不同，就被当成不同的 key 了。实际上这些差异对语义毫无影响。

解决办法是在缓存前先做规范化处理。举个例子：

规范化之前：

  "Explain REST APIs"  
 "Explain REST APIs "  
 "Explain  REST APIs"

规范化之后全部变成：

  "explain rest apis"

代码实现：

 function normalizePrompt(prompt) {  
  return prompt  
    .toLowerCase()  
    .replace(/\s+/g, " ")  
    .trim();  
}  

function getCacheKey(prompt) {  
  return hashPrompt(normalizePrompt(prompt));  
 }

不必要的 cache miss 减少了，命中率明显上升，同时整个过程依然是确定性的、安全的。

策略 3：语义缓存

"What is REST?" 和 "Explain REST architecture" 说的其实是同一件事，但无论精确匹配还是规范化匹配都会把它们当作两个完全不同的请求。

所以思路是引入向量嵌入。把 Prompt 编码成向量，通过余弦相似度之类的指标判断两个 Prompt 是否"足够接近"。如果相似度超过阈值，直接返回缓存结果。

语义缓存流程

工具选型方面，Embedding 可以用 OpenAI 的接口，向量存储可以选 Pinecone、Weaviate 这类专门的向量数据库，小规模场景下在内存里做相似度搜索也够用。

伪代码如下：

 const SIMILARITY_THRESHOLD = 0.90;  

async function getSemanticResponse(prompt) {  
  const embedding = await getEmbedding(prompt);  

  const match = await vectorDB.findClosest(embedding);  

  if (match && match.score > SIMILARITY_THRESHOLD) {  
    return match.response;  
  }  

  const response = await callLLM(prompt);  

  await vectorDB.store({  
    embedding,  
    response  
  });  

  return response;  
 }

语义缓存的风险

语义缓存的核心风险在于阈值设定。设得太低会把不相关的 Prompt 混为一谈，返回错误结果；设得太高又和精确匹配没什么区别。0.90 是一个比较常见的起步值，具体数字需要根据业务场景调优。

策略 4：分层缓存架构

生产环境一般不会只用单一缓存策略，而是按层级组合。典型的三层架构长这样：

 L1 Cache (In-memory, per instance)  
    |  
 L2 Cache (Redis / Shared Cache)  
    |  
 L3 Semantic Cache (Vector DB)  
    |  
 LLM Provider

每一层的定位不同。L1 是进程内存缓存，速度最快但作用域最小；L2 一般用 Redis，多个实例可以共享同一份缓存；L3 是语义缓存层，处理那些文本不同但意思相近的 Prompt。只有三层都没命中的情况下，请求才会打到 LLM Provider。

缓存过期与失效

Prompt 缓存不能"设了就忘"。以下几种情况必须主动失效：模型版本升级了，Prompt 模板改了，或者缓存的内容涉及时效性信息。

最简单的做法是设 TTL：

 cache.set(key, response, {  
   ttl: 60*60*24// 24 hours  
 });

成本影响

缓存带来的收益是双重的——成本下降，延迟也降低了。对于重复率高的工作负载，这两个指标的改善都非常可观。

总结

在 LLM 系统的各种优化手段中，Prompt 缓存的投入产出比可能是最高的。入手门槛低，可以渐进式迭代，而且到了一定规模之后几乎是刚需。

可以先从精确缓存做起，这是成本最低、风险最小的方案。规范化处理应该尽早加上，代码量很小但效果明显。语义缓存只在业务确实需要时才引入，因为它带来了额外的复杂度和向量计算开销。TTL 和版本控制是必须配套的机制。最后缓存命中率要持续监控，因为这是判断缓存策略是否有效的核心指标。

如果正在生产环境跑 AI 系统却没做 Prompt 缓存，可以试试上面的方法，肯定会为你省钱。

https://avoid.overfit.cn/post/10623b71c58d425dae471f5333a54e4c

作者： Vasanthan K

IDA Pro 9.3 (macOS, Linux, Windows) - 强大的反汇编程序、反编译器和多功能调试器

A powerful disassembler, decompiler and a versatile debugger. In one tool.

请访问原文链接：https://sysin.org/blog/ida-pro/ 查看最新版。原创作品，转载请保留出处。

作者主页：sysin.org

IDA Pro

一个强大的反汇编程序、反编译器和多功能调试器。集成在一个工具中。

IDA 9.3 发布：更广泛的架构支持、更快的界面与更多改进

Hex-Rays ✦ 发布于：2026 年 2 月 13 日

在经历了数月来自 Beta 测试人员的反馈与持续打磨之后，Hex-Rays 非常高兴地推出 IDA 9.3！

在 9.2 版本奠定的基础之上，本次更新带来了更深入的架构支持、更智能的反编译能力、更优的性能表现，以及一系列提升日常体验的改进，让逆向工程工作更加顺畅、高效、强大。

下面将概述 IDA 9.3 的主要功能与改进内容。如需完整的技术细节，请务必查阅官方发布说明。

🏗️ 跨架构与跨平台的增强支持

IDA 9.3 持续扩展处理器覆盖范围，并提升了对现代平台与嵌入式目标的指令解码准确性。

• ARM64 支持得到了显著扩展 (sysin)，新增了对更新架构扩展的解码与内建函数处理能力，包括 SVE、SME 以及 内存标记扩展（Memory Tagging Extension，MTE）。这些改进对于分析现代操作系统和经过加固的二进制文件尤为重要。
• 对更多嵌入式架构的支持也有所增强。新增的处理器模块引入了对 Andes AndeStar V3 内核（NDS32）的支持，该架构常见于嵌入式与物联网设备中。同时，对 RISC-V、TriCore 和 ARC 处理器也进行了改进，在交叉引用检测和整体分析可靠性方面都有提升。
• 在较为传统的平台上，x86/x64 与 PowerPC 受益于更完善的指令语义建模以及对间接跳转的增强处理，从而使控制流重建更加准确。
• 更广泛的硬件覆盖范围，确保 IDA 依然是固件、汽车系统、移动平台以及特定平台逆向工程工作流中的强力选择。

🧩 反编译器改进与工作流增强

IDA 9.3 的反编译器迎来了多项有意义的升级，重点聚焦于可读性、可控性与生产效率。

• 最引人注目的新增功能之一，是反编译器对 Renesas V850（RH850） 架构的支持，进一步巩固了 IDA 在汽车电子与嵌入式分析领域的优势。
• 微代码（microcode）查看器也得到了增强，为用户提供了更多对底层表示的控制能力。分析人员可以更自由地试验微代码，例如修改指令、调整变量值 (sysin)，从而更容易探索不同的解释路径并精炼复杂分析。
• 对 值范围传播 与 条件分析 的改进，使反编译器能够更有效地消除不可达分支，生成更加清晰、准确的伪代码。这些优化直接提升了代码的可读性，加快了对复杂逻辑的理解速度。
• 此外，“Decompile All”（全部反编译）命令现已在更多产品版本中提供，让更多用户能够使用批量反编译工作流，并提升了自动化分析能力。

⚡ 用户界面与响应速度

IDA 9.3 对性能和用户体验给予了高度重视。

• 表格视图（如 Functions、Names、Imports、Bookmarks、Breakpoints）在处理大型数据库时变得明显更加流畅。跨大规模代码库的导航体验更加顺滑 (sysin)，视图刷新速度更快且更稳定。
• 许多界面细节优化与一致性修复进一步改善了整体体验。虽然单项改动可能较为细微，但叠加起来，对日常使用的舒适度和长时间分析的流畅性都有显著提升。

🐞 调试器改进

IDA 9.3 中的调试器改进，进一步缩小了静态分析与动态分析之间的差距。

• 对 现代 Android 环境 的支持得到了扩展，包括对近期平台版本的更好兼容，以及对诸如指针认证（Pointer Authentication，PAC）等安全机制的增强处理。
• 栈视图（stack view）也得到了改进，在调试过程中提供了更直观的解引用方式以及更清晰的栈内容可视化，使运行时检查更加高效、易读。

下载地址

IDA Pro 9.3 for macOS arm64 (Apple 芯片)

IDA Pro 9.3 for macOS x64 (Intel 处理器)

IDA Pro 9.3 for Linux x64

IDA Pro 9.3 for Windows x64

• 下载地址：https://sysin.org/blog/ida-pro/

在数字化快速发展的今天，AI助手与网页之间的交互效率成为了一个日益重要的问题。传统的AI与网页交互方式，通常需要通过截取屏幕、解析DOM结构或者模拟鼠标点击来完成操作，这种方式不仅消耗大量计算资源，还十分脆弱，稍有页面改版或结构变化，AI就会“迷失”或无法继续执行任务。为了应对这一挑战，WebMCP（Web模型上下文协议）应运而生，它提供了一种全新的解决方案，让AI能够更高效、更直接地与网页交互。

WebMCP是WebAPI的一个新提案，它提出了一种新的Javascript接口，允许Web开发人员将Web应用的功能以“tools”的形式公开，从而可以被AI agent、浏览器助手等调用。使用WebMCP的网页可以被视为MCP服务器，浏览器支持在客户端脚本中实现工具，降低了后端服务开发维护成本。

在这样的背景下，高德开放平台JS API结合浏览器这一新特性，推出支持WebMCP的搜索插件，用户调用AMap.PlaceSearch即可拥有被AI调用的新能力。

https://www.bilibili.com/video/BV1ChZLB8EJY/?aid=116067984805...

使用方法

01 引入高德地图JS API及地址搜索插件

// 引入 JS API 资源
<script type="text/javascript" src="//webapi.amap.com/maps?v=2.0&key=您的 JS API key"></script>
// 引入地址搜索插件资源
<link type="text/css" rel="stylesheet" href='https://a.amap.com/jsapi/static/mcp_plugin/1.0.0/place_search.css' />
<script type="text/javascript" src='https://a.amap.com/jsapi/static/mcp_plugin/1.0.0/place_search.js'></script>

02 安装 MCP-B 扩展程序或与 Assistant-UI 等 AI 框架集成在支持WebMCP的浏览器中打开网页，即可在对话框中调用amap_search_poi工具。

WebMCP正在重新定义AI与网页交互的方式，它通过结构化数据交互和直接功能调用，极大提升了效率和稳定性。高德开放平台推出的搜索插件是一个典型的应用案例，展示了WebMCP在实际场景中的巨大潜力。

如果你是开发者，关注高德开放平台，我们将持续推出更多创新工具，助力你打造更智能、更高效的开发体验，共同开启未来新篇章！

在自动化生成报表时，我们往往更关注“数据是否正确”，却忽略了一个同样重要的问题——数据是否易读、是否专业、是否符合业务习惯。同样的数字，在不同的显示格式下，带给读者的理解体验是完全不同的。千分位分隔可以提升可读性，红色负数可以强化风险提示，括号表示法符合财务规范，而日期与时间格式则直接影响数据的语义表达。

在 Excel 中，这一切都由数字显示格式控制。通过 Python 操作 Excel 文件时，我们同样可以精确设置这些显示规则，而无需依赖 Microsoft Office。本篇文章将围绕一个完整示例，在同一张工作表中演示多种常见数字格式的设置方式，并解释每种格式代码背后的逻辑。

本文示例基于 Free Spire.XLS for Python，可通过pip安装：pip install spire.xls.free。

1. 初始化工作簿与表头结构

首先创建工作簿，并在工作表中设置示例区域结构。

from spire.xls import *
from spire.xls.common import *

# 创建工作簿
workbook = Workbook()

# 获取第一个工作表
sheet = workbook.Worksheets.get_Item(0)
sheet.Name = "数字格式演示"

# 设置表头
sheet.Range["B5"].Text = "格式说明"
sheet.Range["C5"].Text = "原始数值"
sheet.Range["D5"].Text = "格式化显示"

这里特别需要注意的是：
Excel 的数字格式只会作用于“数值类型”数据，因此必须使用 NumberValue 写入数值，而不是 Text。否则格式代码不会生效。

2. 千分位与小数位控制

在财务或销售报表中，大数值如果不加分隔符，会严重影响可读性。

sheet.Range["B6"].Text = "千分位 + 两位小数"
sheet.Range["C6"].Text = "9876543.219"
sheet.Range["D6"].NumberValue = 9876543.219
sheet.Range["D6"].NumberFormat = "#,##0.00"

#,##0.00 表示使用千分位分隔，并始终保留两位小数。
其中 # 代表可选数字位，而 0 表示必须占位，即使为 0 也会显示。

3. 负数以红色显示

在财务场景中，负值往往需要视觉强调。

sheet.Range["B7"].Text = "负数红色显示"
sheet.Range["C7"].Text = "-4567.8"
sheet.Range["D7"].NumberValue = -4567.8
sheet.Range["D7"].NumberFormat = "[Red]#,##0.00"

方括号中的 [Red] 是条件格式的一种表达方式。
当数值为负时，会自动以红色显示，增强警示效果。

4. 百分比格式

百分比在增长率、完成率等场景中非常常见。

sheet.Range["B8"].Text = "百分比（1位小数）"
sheet.Range["C8"].Text = "0.8765"
sheet.Range["D8"].NumberValue = 0.8765
sheet.Range["D8"].NumberFormat = "0.0%"

当使用 % 符号时，Excel 会自动将数值乘以 100 后显示。
0.0% 表示保留一位小数。

5. 负数使用括号表示

在标准财务报表中，负数通常用括号表示，而不是负号。

sheet.Range["B9"].Text = "负数括号表示"
sheet.Range["C9"].Text = "-3200"
sheet.Range["D9"].NumberValue = -3200
sheet.Range["D9"].NumberFormat = "#,##0;(#,##0)"

分号 ; 用于区分不同数值类型的格式。
第一部分表示正数格式，第二部分表示负数格式。
因此负值会显示为 (3,200)。

6. 日期格式控制

Excel 中的日期本质是一个序列号。通过设置格式，可以改变显示方式。

sheet.Range["B10"].Text = "日期格式"
sheet.Range["C10"].Text = "44927"
sheet.Range["D10"].NumberValue = 44927
sheet.Range["D10"].NumberFormat = "yyyy-mm-dd"

/ 或 - 用于分隔年、月、日。
yyyy-mm-dd 是常见的标准日期格式。

7. 时间格式

时间在 Excel 中以 1 表示 24 小时，因此 0.75 表示一天的 75%。

sheet.Range["B11"].Text = "时间格式"
sheet.Range["C11"].Text = "0.75"
sheet.Range["D11"].NumberValue = 0.75
sheet.Range["D11"].NumberFormat = "hh:mm:ss"

这里的 hh:mm:ss 控制小时、分钟和秒的显示方式。

8. 货币格式（欧元示例）

货币格式通常需要带符号并保留小数位。

sheet.Range["B12"].Text = "欧元货币"
sheet.Range["C12"].Text = "2500.5"
sheet.Range["D12"].NumberValue = 2500.5
sheet.Range["D12"].NumberFormat = "€#,##0.00"

$ 或 € 等符号可以直接写入格式字符串。
在实际应用中也可以结合系统区域设置自动适配。

9. 科学计数法

在处理大规模数据或科研数据时，科学计数法更便于阅读。

sheet.Range["B13"].Text = "科学计数法"
sheet.Range["C13"].Text = "987654321"
sheet.Range["D13"].NumberValue = 987654321
sheet.Range["D13"].NumberFormat = "0.00E+00"

E+00 表示指数形式，0.00 控制有效数字位数。

10. 数值前添加文本说明

有时我们希望数值带有说明文字，但仍保持可计算性。

sheet.Range["B14"].Text = "带文本前缀"
sheet.Range["C14"].Text = "1500"
sheet.Range["D14"].NumberValue = 1500
sheet.Range["D14"].NumberFormat = "\"销售额:\" #,##0"

双引号用于包裹固定文本，数值仍然是数值类型。

11. 自动调整与保存文件

sheet.AllocatedRange.Style.Font.Size = 12
sheet.AllocatedRange.AutoFitRows()
sheet.AllocatedRange.AutoFitColumns()

workbook.SaveToFile("SetNumberFormatPython.xlsx", FileFormat.Version2016)
workbook.Dispose()

生成 Excel 文件预览

下图是使用以上代码生成的 Excel 文件的预览效果：

常见 NumberFormat 代码说明

总结

数字格式并不会改变数据本身，它改变的是“数据如何被理解”。在自动化报表系统中，数据的准确性固然重要，但展示的专业性同样决定了报表质量。通过合理使用 NumberValue 与 NumberFormat，我们可以在保持数据可计算性的前提下，实现高度定制化的显示效果。

当报表开始面向客户、财务人员或管理层时，数字格式不再只是技术细节，而是沟通质量的一部分。熟练掌握这一能力，会让你的自动化报表系统真正达到专业级水准。

更多 Excel 文件操作技巧请前往 Spire.XLS for Python 官方教程查看。

作者：潘伟龙（阿里云可观测）、阮孝振（阿里云开放平台）

1. 背景与挑战

业务背景

阿里云开放平台（OpenAPI） 是开发者管理云上资源的标准入口。开放平台承载了几乎所有云产品的对外接口，关乎客户的自动化业务和各类管控需求。随着企业对自动化的依赖日益加深，OpenAPI 的稳定性建设变得至关重要。

监控体系的需求方包括：

• 开放平台运维团队：负责网关整体可用性，需要全局视角的监控告警
• 各云产品团队（ECS/RDS/SLB 等）：需要查看自己产品的 API 调用指标和大盘，并配置细粒度告警
• SRE 团队：需要快速定位故障，进行根因分析

任何接口的波动都可能影响客户的生产业务，因此必须建立全方位的指标监控体系，并配套及时的告警能力，以确保高可用性。

核心挑战

构建监控体系的核心数据源是 API 网关的访问日志。这些日志由分布式部署在各地域的网关节点产生，具有以下鲜明特点：

2. 技术方案

针对上述挑战，我们采用 Flink + SLS（日志服务） 的云原生组合来构建实时监控体系。

技术选型

该方案的核心组件及选型理由如下：

这套组合的核心优势：

• 全托管运维：SLS 和 Flink（基于阿里云实时计算）均为全托管服务，无需运维基础设施
• 弹性扩展：消费吞吐和计算资源可按需扩缩
• 端到端保障：从采集到告警的全链路可观测

整体架构

整个数据处理链路采用地域化部署 + 中心化汇聚的架构设计，在各地域内完成日志采集与聚合计算，最终将指标汇聚到中心化的 MetricStore 实现全局监控。

地域内处理（Regional Processing）

每个地域独立部署完整的数据处理链路，实现就近计算、降低延迟：

1. 数据采集：由 Logtail 实时采集本地域网关节点日志。Logtail 是阿里云自研的高性能日志采集 Agent，具备毫秒级延迟和百万级 EPS 吞吐能力，确保海量日志的可靠传输。
2. 日志存储：各地域的 SLS Logstore 存储本地域 OpenAPI 的原始访问日志，支持对请求明细的实时查询与分析，同时作为 Flink 流计算的数据源。

3. 流式聚合计算：各地域独立部署 Flink Job 1（聚合作业），关联 MySQL 维表（存储网关机器的集群信息、API 业务域如 ECS 等元数据），进行局部维度的业务指标汇总。地域内处理可大幅减少跨域传输的数据量。

   跨地域汇聚（Cross-Region Aggregation）

   多个地域的聚合结果统一写入中心化的 MetricStore，实现全局视图：

4. 指标汇聚：各地域的 Flink Job 2（指标转换） 将聚合结果转为时序指标格式，统一推送到中心地域的 SLS MetricStore。通过汇聚设计，运维团队可在单一视图查看全球所有地域的指标。
5. 可视化与告警：基于 Grafana 对接中心化的 SLS MetricStore，通过标准 PromQL 实现多维度的指标大盘展示，并配置细粒度告警规则，实现从异常发现到通知的闭环。

分层设计理念

为什么要分两层？核心考虑是平衡实时性与资源效率：

为什么不直接一层聚合？

\> 1. 数据倾斜（Data Skew）：OpenAPI 流量分布极不均匀，某些大产品（如 ECS）的 QPS 是其他产品的数千倍。如果直接按 \`Product\` 进行 GroupBy，会导致特定 Flink Task 出现严重的数据倾斜和状态膨胀。

\> 2. 资源效率：通过第一层单机维度的局部聚合，输出到下游的数据量可降低 90% 以上，大幅减轻了全局聚合作业的计算和存储开销。

3. 指标体系设计

我们需要生成的指标体系由 Metric Name（指标名称） 和 Labels（标签） 组成，覆盖以下四个核心维度：

指标命名规范：Prefix_MetricName。例如 Ecs 产品的 QPS 指标名为 namespace_product_gw_http_req。

4. 核心作业实践

Job 1：聚合作业

设计意图：消费原始日志，关联 MySQL 维表补充元数据（网关集群信息、API 业务域等），并进行多阶段聚合：先进行细粒度的多维聚合（按产品/API/租户等）以减少下游数据量，再进行全局指标汇总。

1. 数据源：网关原始日志

原始日志由 Logtail 从网关节点采集。以下是一条典型的网关访问日志（已脱敏）：

{
  "AK": "STS.NZD***Lgwc",
  "Api": "DescribeCustomResourceDetail",
  "CallerUid": "109837***3503",
  "ClientIp": "192.168.xx.xx",
  "Domain": "acc-vpc.cn-huhehaote.aliyuncs.com",
  "ErrorCode": "ResourceNotFound",
  "Ext5": "{\"logRegionId\":\"cn-huhehaote\",\"appGroup\":\"pop-region-cn-huhehaote\",\"callerInfo\":{...},\"headers\":{...}}",
  "HttpCode": "404",
  "LocalIp": "11.197.xxx.xxx",
  "Product": "acc",
  "RegionId": "cn-huhehaote",
  "RequestContent": "RegionId=cn-huhehaote;Action=DescribeCustomResourceDetail;Version=2024-04-02;...",
  "TotalUsedTime": "14",
  "Version": "2024-04-02",
  "__time__": "1768484243"
}

字段说明：Ext5 包含嵌套的 JSON 结构（调用者信息、请求头等），RequestContent 是 KV 格式的请求参数。这些复杂结构需要在后续处理中解析。

基于上述日志结构，我们定义 Flink Source 表：

CREATE TABLE openapi_log_source (
  `__time__` BIGINT,
  LocalIp STRING,           -- 网关节点 IP
  Product STRING,           -- 产品 Code (如 Ecs, RDS)
  Api STRING,               -- API 名称 (如 DescribeInstances)
  Version STRING,           -- API 版本
  Domain STRING,            -- 请求域名
  AK STRING,                -- AccessKey
  CallerUid STRING,         -- 调用者 UID
  HttpCode STRING,          -- HTTP 状态码
  ErrorCode STRING,         -- 网关错误码
  TotalUsedTime BIGINT,     -- 请求耗时 (ms)
  ClientIp STRING,          -- 客户端 IP
  RegionId STRING,          -- 地域
  Ext5 STRING,              -- 扩展字段 (嵌套 JSON)
  RequestContent STRING,    -- 请求参数 (KV 格式)
  ts AS TO_TIMESTAMP_LTZ(`__time__` * 1000, 3),
  WATERMARK FOR ts AS ts - INTERVAL '5' SECOND
) WITH (
  'connector' = 'sls',
  'project' = '*****',
  'logstore' = 'pop_rpc_trace_log',
  'endpoint' = 'cn-shanghai-intranet.log.aliyuncs.com'
);

Watermark 策略说明：这里设置 ts - INTERVAL '5' SECOND 表示允许最多 5 秒的乱序数据。该值需根据实际业务场景权衡：生产环境中，网关日志通过 Logtail 采集，端到端延迟通常在 2-3 秒内，5 秒的 Watermark 延迟可以覆盖绝大多数场景。对于跨地域同步场景，可适当放宽至 10-15 秒。

2. MySQL 维表：元数据富化

为了满足指标的标签需求（如 app_group, gc_level），需要关联维表：

-- 网关集群信息 (关联 LocalIp)
CREATE TABLE gateway_cluster_dim (
  local_ip STRING,
  app_group STRING,          -- 集群名称
  region_id STRING,          -- 物理 Region
  PRIMARY KEY (local_ip) NOT ENFORCED
) WITH ('connector' = 'jdbc', ...);

-- 租户等级信息 (关联 Uid)
CREATE TABLE user_level_dim (
  uid STRING,
  gc_level STRING,           -- 客户等级 (GC5/GC6/GC7)
  PRIMARY KEY (uid) NOT ENFORCED
) WITH (
  'connector' = 'jdbc',
  'url' = 'jdbc:mysql://xxx:3306/dim_db',
  'table-name' = 'user_level',
  'lookup.cache.max-rows' = '50000',       -- 缓存最大行数
  'lookup.cache.ttl' = '10min',            -- 缓存过期时间
  'lookup.max-retries' = '3'               -- 查询失败重试次数
);

维表缓存策略选择：生产环境中，gateway_cluster_dim 采用 ALL 策略，启动时全量加载并定时刷新；user_level_dim 采用 LRU 策略，缓存 5 万条热点租户数据，TTL 设为 10 分钟以平衡命中率和数据新鲜度。

3. Job 1 输出：写入本地域聚合日志

计算结果写入本地域的 SLS Logstore machine_agg_log，作为中间存储。

-- 定义本地聚合日志存储
CREATE TABLE machine_agg_log_sink (
  window_start TIMESTAMP(3),
  product STRING,
  api STRING,
  version STRING,
  caller_uid STRING,
  region_id STRING,
  app_group STRING,
  gc_level STRING,
  http_code STRING,
  error_code STRING,
  qps BIGINT,
  rt_mean DOUBLE,
  slow1s_count BIGINT,
  http_2xx BIGINT,
  http_5xx BIGINT,
  http_503 BIGINT
) WITH (
  'connector' = 'sls',
  'project' = '****',
  'logstore' = 'machine_agg_log',  -- 地域化部署，写入本地域 Logstore
  'endpoint' = 'cn-shanghai-intranet.log.aliyuncs.com' -- 实际部署时替换为各地域 Endpoint
);

-- 执行写入
INSERT INTO machine_agg_log_sink
SELECT 
  TUMBLE_START(l.ts, INTERVAL '10' SECOND),
  l.Product, l.Api, l.Version, l.CallerUid, g.region_id, g.app_group, u.gc_level, l.HttpCode, l.ErrorCode,
  COUNT(*) as qps,
  AVG(CAST(l.TotalUsedTime AS DOUBLE)),
  SUM(CASE WHEN l.TotalUsedTime > 1000 THEN 1 ELSE 0 END),
  SUM(CASE WHEN l.HttpCode >= '200' AND l.HttpCode < '300' THEN 1 ELSE 0 END),
  SUM(CASE WHEN l.HttpCode >= '500' THEN 1 ELSE 0 END),
  SUM(CASE WHEN l.HttpCode = '503' THEN 1 ELSE 0 END)
FROM openapi_log_source l
LEFT JOIN gateway_cluster_dim FOR SYSTEM_TIME AS OF l.ts AS g ON l.LocalIp = g.local_ip
LEFT JOIN user_level_dim FOR SYSTEM_TIME AS OF l.ts AS u ON l.CallerUid = u.uid
GROUP BY 
  TUMBLE(l.ts, INTERVAL '10' SECOND),
  l.Product, l.Api, l.Version, l.CallerUid, g.region_id, g.app_group, u.gc_level, l.HttpCode, l.ErrorCode;

Job 2：指标转换与跨域汇聚

设计意图：各地域独立部署 Job 2，消费本地域的聚合日志 machine_agg_log，将数据转换为时序格式，并跨域写入中心地域 (cn-shanghai) 的 MetricStore。

1. 数据源：消费本地聚合日志

CREATE TABLE machine_agg_log_source (
  window_start TIMESTAMP(3),
  product STRING,
  region_id STRING,
  -- ... 其他字段同 Sink 定义
  WATERMARK FOR window_start AS window_start - INTERVAL '5' SECOND
) WITH (
  'connector' = 'sls',
  'project' = '****',
  'logstore' = 'machine_agg_log',  -- 消费本地域 Logstore
  'endpoint' = 'cn-shanghai-intranet.log.aliyuncs.com'
);

2. 目标汇聚：中心化 MetricStore Sink

CREATE TABLE metricstore_sink (
  `__time_nano__` BIGINT,
  `__name__` STRING,
  `__labels__` STRING,
  `__value__` DOUBLE
) WITH (
  'connector' = 'sls',
  'project' = '****',      -- 中心化 Project
  'logstore' = 'openapi_metrics',            -- 中心化 MetricStore
  'endpoint' = 'cn-shanghai-intranet.log.aliyuncs.com' -- 统一指向中心地域 Endpoint
);

3. 计算与汇聚逻辑

Job 2 将聚合日志进一步汇总（如按 Product 维度）并格式化为 Metric 写入中心。

示例：计算产品维度 QPS 并汇聚

INSERT INTO metricstore_sink
SELECT 
  UNIX_TIMESTAMP(CAST(TUMBLE_START(window_start, INTERVAL '1' MINUTE) AS STRING)) * 1000000000,
  'namespace_product_gw_http_req',
  CONCAT('product=', product, '|region_id=', region_id), -- 保留地域标签，实现全球视角
  CAST(SUM(qps) AS DOUBLE)
FROM machine_agg_log_source
GROUP BY TUMBLE(window_start, INTERVAL '1' MINUTE), product, region_id;

架构优势：

带宽节省：Job 1 将海量明细日志聚合为少量统计数据（数据量减少 99%），Job 2 仅跨域传输这些轻量级指标，极大降低了专线带宽成本。

隔离性：各地域计算独立，单地域故障不影响其他地域及中心监控的写入。

作业配置与调优

为了保障作业的稳定性和数据准确性，生产环境中我们对 Checkpoint 和状态后端进行了专项调优。

Checkpoint 配置与权衡

提供了两种配置策略，需根据业务对数据一致性与服务可用性的偏好进行选择：

策略 A：标准与一致性优先（推荐通用场景）

适用于绝大多数对数据准确性有要求的监控场景。

SET 'execution.checkpointing.interval' = '60s';           -- 1分钟 Checkpoint
SET 'execution.checkpointing.mode' = 'EXACTLY_ONCE';      -- 精确一次语义
SET 'execution.checkpointing.timeout' = '10min';

策略 B：高可用优化配置（本案例生产实践）

在 OpenAPI 网关这种超高并发且对可用性极度敏感的场景下，为了避免 Checkpoint 过于频繁导致的性能抖动，同时又不希望完全牺牲数据可靠性，我们采取了“弱一致性 + 低频打点 + 允许失败”的组合策略：

SET 'execution.checkpointing.interval' = '180s';          -- 延长至 3 分钟，减少频率
SET 'execution.checkpointing.mode' = 'AT_LEAST_ONCE';     -- 降低 Barrier 对齐开销
SET 'execution.checkpointing.timeout' = '15min';          -- 放宽超时时间
SET 'execution.checkpointing.max-concurrent-checkpoints' = '1';
SET 'execution.checkpointing.tolerable-failed-checkpoints' = '10'; -- 允许连续失败，不因 CP 失败重启作业

优化思路：

状态后端选择

阿里云实时计算 Flink 版提供了企业级的 GeminiStateBackend，相比开源 RocksDB，它在存算分离架构下针对大状态场景进行了深度优化。针对本案例中“状态大（GB级）、聚合Key多”的特点，我们开启了 KV 分离功能：

SET 'table.exec.state.backend' = 'gemini';                -- 使用企业级 GeminiStateBackend
SET 'state.backend.gemini.kv.separate.mode' = 'GLOBAL_ENABLE'; -- 开启 KV 分离

GeminiStateBackend 核心优势对比：

生产建议：对于网关日志聚合这种 State Size 较大且吞吐要求极高的场景，强烈推荐使用 GeminiStateBackend + KV 分离。实测开启后，作业在流量高峰期的 CPU 使用率下降了 20%，且 Checkpoint 耗时更加稳定。

5. 可视化与告警

监控效果展示

通过两个 Flink 作业的聚合，我们在 Grafana 中构建了多维度的 OpenAPI 监控大盘，实现了从产品全局视图到具体错误码的深度下钻。

自助查询与告警

在 Grafana 中添加 SLS MetricStore 作为数据源后，各云产品团队可以使用 PromQL 语法自助查询指标并配置告警规则：

常用查询示例：

# QPS 趋势
sum(namespace_product_gw_http_req) by (product)

# 错误率环比（当前 1 分钟与 1 小时前对比）
(
  sum(rate(namespace_product_gw_http_5xx[1m])) / sum(rate(namespace_product_gw_http_req[1m]))
) / (
  sum(rate(namespace_product_gw_http_5xx[1m] offset 1h)) / sum(rate(namespace_product_gw_http_req[1m] offset 1h))
) > 2

# 平均延迟趋势
avg(namespace_product_gw_rt_mean) by (product)

告警规则示例：

- alert: HighErrorRate
  expr: sum(namespace_product_gw_http_5xx) by (product) / sum(namespace_product_gw_http_req) by (product) > 0.01
  for: 2m
  labels:
    severity: warning
  annotations:
    summary: "{{ $labels.product }} 错误率过高"
    description: "当前错误率: {{ $value | printf \"%.2f\" }}%"

各云产品团队可以在 Grafana 中配置自己产品的监控大盘和告警规则，实现自主运维。

6. 规模化验证

该方案已在阿里云开放平台稳定运行，以下是生产环境的核心指标：

上图展示了系统在生产环境中的核心运行指标。得益于 Flink 的分布式计算能力和 SLS 的高吞吐存储，该方案成功支撑了阿里云开放平台全量 API 调用的实时监控，覆盖 60+ 个全球地域、300+ 个云产品，日均处理 200TB+ 压缩日志（原始日志约 2PB，单条日志约 4-5KB），生成 50 万+ 时序指标。

数据处理规模

指标生成能力

系统稳定性

业务价值

• 故障发现提速：故障发现时间从分钟级缩短到秒级
• 运维效率提升：300+ 云产品团队实现自助监控配置

在方案落地过程中，我们发现原始日志包含大量冗余字段和嵌套结构，而指标计算只需其中的核心字段。为此，我们引入了 Source 端谓词下推 技术，在数据进入 Flink 之前完成字段裁剪，有效降低了网络传输量并加速了 Flink 计算。

7. 进阶优化：Source 端谓词下推（Predicate Pushdown）

谓词下推概念与 Connector 能力对比

谓词下推（Predicate Pushdown） 是数据库和大数据领域的经典优化策略，核心思想是将过滤条件下推到数据源端执行，减少数据传输量和计算开销。

Flink 的下推能力取决于 Source Connector 的实现：

SLS 消费处理器：一种 Source 端下推实现

早期版本的 Flink SLS Connector 会默认全量拉取 SLS Logstore 的数据，但实际上很多字段是不需要的。借助 SLS 消费处理器，我们实现了真正的 Source 端谓词下推——过滤和转换逻辑在 SLS 服务端执行，Flink 只接收处理后的结果。

技术优势：

• SIMD 向量化引擎：SPL 底层采用向量化执行引擎，利用 CPU SIMD 指令集（如 AVX2/AVX-512）批量处理数据，相比逐行处理性能提升数倍
• 同机房本地计算：数据处理在 SLS 存储节点本地完成，无需跨网络传输原始数据，避免了网络 I/O 成为瓶颈
• 列式存储加速：SLS 底层采用列式存储，配合 project 列裁剪，只读取必要的列数据，大幅减少磁盘 I/O
• 零拷贝传输：处理后的数据直接进入消费通道，减少内存拷贝开销

计费提示：

普通消费：按传输的压缩数据量计费。

使用SPL消费处理器：按扫描的原始（未压缩）数据量计费。

详细定价及区别请参考 SLS 产品定价。

SPL 配置示例

基于前文介绍的网关日志结构，我们通过 SPL 消费处理器实现 Source 端过滤。对比传统的 Flink 侧过滤：

-- 传统方式：Flink 侧过滤（需拉取全量数据）
SELECT * FROM openapi_log_source
WHERE Domain != 'popwarmup.aliyuncs.com'
  AND JSON_VALUE(Ext5, '$.logRegionId') NOT IN ('cn-shanghai', 'cn-beijing')

使用 SPL 消费处理器后，过滤和转换在 SLS 服务端完成：

-- 1. 行过滤：排除无效数据
* 
| where Domain != 'popwarmup.aliyuncs.com'

-- 2. 嵌套 JSON 分层展开（只对有效数据执行）
| parse-json -prefix='ext5_' Ext5  
| where ext5_logRegionId not in ('cn-shanghai', 'cn-beijing', 'cn-hangzhou')
| parse-json -prefix='callerInfo_' ext5_callerInfo  
| parse-json -prefix='headers_' ext5_headers  

-- 3. 正则提取 KV 格式字段
| parse-regexp RequestContent, '[;]RegionId=([^;]*)' as request_regionId  

-- 4. 列裁剪：只保留必要字段（放在最后，减少输出数据量）
| project LocalIp, Product, Version, Api, Domain, ErrorCode, HttpCode, 
         TotalUsedTime, AK, RegionId, ClientIp, 
         callerInfo_callerType, callerInfo_callerUid, callerInfo_ownerId,
         ext5_regionId, ext5_appGroup, ext5_stage, request_regionId

在 Flink SLS Source 中引用

在 Flink SQL 中，通过 processor 参数引用预先配置好的消费处理器：

CREATE TABLE openapi_log_source (
  `__time__` BIGINT,
  -- SPL 处理后的字段（已展开嵌套 JSON、已裁剪冗余列）
  LocalIp STRING,
  Product STRING,
  Version STRING,
  Api STRING,
  Domain STRING,
  ErrorCode STRING,
  HttpCode STRING,
  TotalUsedTime BIGINT,
  AK STRING,
  RegionId STRING,
  ClientIp STRING,
  callerInfo_callerType STRING,      -- 从 Ext5.callerInfo 展开
  callerInfo_callerUid STRING,
  callerInfo_ownerId STRING,
  ext5_regionId STRING,              -- 从 Ext5 展开
  ext5_appGroup STRING,
  ext5_stage STRING,
  request_regionId STRING,           -- 从 RequestContent 正则提取
  ts AS TO_TIMESTAMP_LTZ(`__time__` * 1000, 3),
  WATERMARK FOR ts AS ts - INTERVAL '5' SECOND
) WITH (
  'connector' = 'sls',
  'project' = '****',
  'logstore' = 'pop_rpc_trace_log',
  'endpoint' = 'cn-shanghai-intranet.log.aliyuncs.com',
  'processor' = 'openapi-processor'  -- 引用消费处理器，实现过滤下推
);

优化效果

通过 SPL 源头预处理，我们在以下几个维度取得了显著提升：

总结

通过 Flink + SLS 的云原生组合，我们成功构建了阿里云 OpenAPI 网关的实时监控体系：

Flink 核心技术要点

架构设计启示

1. 分层聚合缓解数据倾斜：流量分布不均时，先按物理节点局部聚合，再按业务维度全局汇总
2. 谓词下推降低成本：将过滤逻辑下推到 Source 端（如 SLS 消费处理器），减少网络传输和计算资源消耗
3. 选择企业级状态后端：大状态场景选用 GeminiStateBackend + KV 分离，显著提升 I/O 效率与作业稳定性

本案例的技术方案可推广至微服务调用链监控、CDN 日志分析、物联网数据聚合等类似场景。

开发者资源

• Flink SLS Connector 文档
• SLS MetricStore
• Grafana + SLS 集成
• SLS SPL语法文档

刚刚过去的 2025 年，是实时数据从“可选项”走向“必选项”、从“技术工程”走向“业务引擎”的觉醒之年。

对 TapData 来说，这也是从“平台化能力建设期”走向“能力真正被更广泛使用、被更多生产实践验证”的一年。

在医疗、零售、酒店服务等行业，我们看到实时数据不再只是后台系统之间的连接工程，而是开始进入业务主流程：数据开始直接参与到业务响应、服务体验与运营决策之中。

实时数据的角色正在悄然发生改变。

从“连通系统”到“支撑业务”：需求重心的变化

过去几年，企业总是问我们：“如何实现系统A到B的数据同步”。而在 2025 年，我们高兴地发现了一个可爱的变化：越来越多的团队，不再满足于“数据已经同步成功”，而是开始追问——“我的业务能不能被实时数据直接驱动？”

我们清晰地看到，需求正在发生根本性的跃迁：

• 从“帮我接系统”到“我要用实时数据立刻决策”
• 从“搭一条管道”到“建一套可持续复用的数据资产”
• 从“技术团队交付项目”到“业务部门主动调用数据服务”

在零售行业，实时数据不再只是分析素材，而是被期待用于更及时的用户触达与运营反馈；在医疗行业，团队不再满足于“系统间数据一致”，而是开始关注实时数据是否能真正支撑业务协同与服务闭环；在酒店与服务行业，实时数据开始被拉进客户服务与运营调度的核心链路中……

这不仅仅是一次工具升级，更是一场从“连接数据”到“激活数据”的认知革命——企业对实时数据的角色认知正在发生变化：实时数据不再只是“连起来”，它不再只是“工程链路”，而开始成为业务系统可以依赖的基础能力层。

一个逐渐清晰的共识：实时数据需要服务层

实时数据，正在从“管道”，走向“可被复用的服务层”。

过去一年，在与多个行业客户的交流中，我们反复听到类似的痛点：

• 实时链路越来越多，但每一条都像“一次性临时工程”
• Kafka、CDC 采集等组件越来越复杂，但复用性越来越差
• 数据很新鲜，但业务侧接入成本依然很高

问题并不在实时性本身，而在于实时数据长期停留在“运输层”，却缺少一个面向业务的“服务层”。

这也是 2025 年 TapData 在产品与架构方向上持续强化的一件事——让实时数据不只流动，还能被沉淀、被复用、被治理，可以直接服务业务系统——在实时数据集成能力之外，TapData 作为实时 Operational Data Hub 的更多属性开始被看见、被发掘、被应用。

无论是围绕增量物化视图的能力完善，还是围绕实时数据服务 API、模型管理、链路可观测性的持续演进，
背后的目标都不是单纯堆功能，而是让实时数据开始具备基础设施应有的形态：稳定、可复用、可演进、可被业务系统长期依赖。

行业实践也在不断长出新芽：这些领域，实时数据已开始直接推动增长

从“实时同步项目”，走向“实时能力平台化”——2025 年，我们看到越来越多用户的实时项目“长大了”。

一个非常明显的变化是：不少实时数据项目，从“点状落地”，开始走向“能力平台化”。

起初，大家往往是从一个很具体的小需求切入，比如同步两个系统、做一个实时看板、拉起客户画像……但在真正上线跑起来之后，越来越多团队开始意识到，如果每个需求都拉一条新链路，实时能力本身就会变成新的“烟囱森林”。

因此，在越来越多的制造、零售、酒店、医疗等行业场景中，我们看到不少团队开始把实时数据能力往平台层抽象，让数据同步、建模、视图构建、API 服务——不再是一次性工程，而是沉淀为长期可复用的“实时数据底座”。

在医疗行业，我们帮助客户搭建起患者主数据平台。

在这一类超大规模医疗体系中，历史上患者相关数据分散在大量业务系统里，被反复复制、各自维护。为了支撑不同应用团队的需求，长期累积了数量庞大的同步链路与数据副本，最终形成了上万条实时管道、上百份数据拷贝并行存在的复杂局面。

更现实的挑战在于：医疗行业的组织结构决定了，各系统部门很难长期投入人力配合“工程型集成项目”。传统做法下，每新增一个业务场景，就需要多个系统团队反复参与字段对齐、接口改造与联调，交付周期往往以月甚至年计算。

TapData ODH 方案的价值，正是在这里开始显现：实时数据不再以“管道”的形式分散存在，而是被统一沉淀为主数据模型，并通过 API 以服务化方式对外提供。

各业务系统不再需要深度参与底层数据工程，只需围绕服务接口参与测试与验收，就可以持续复用同一套实时数据能力。

当实时数据开始以“平台服务”的形态被消费，而不是以“工程项目”的方式被反复建设时，它才真正具备了被长期依赖的基础设施形态。

在零售行业，我们帮助客户搭建起商品与库存主数据服务平台。

在这一类多渠道零售体系中，门店系统、供应链系统、电商系统长期并行运行，商品与库存数据分散在多个核心系统与多个数据库集群中，各自维护、口径不一。为了支撑全渠道业务，历史上往往需要为不同应用团队分别搭建同步链路与接口服务，同一份商品与库存数据被反复同步、反复加工，实时链路逐渐堆叠成难以复用的工程体系。

随着全渠道库存统一与实时可用成为业务刚需，越来越多业务系统开始依赖同一份“统一库存视图”来支撑前台展示、订单履约与运营决策。但如果仍然沿用“每个系统各自维护同步与接口”的方式，实时能力本身就会迅速碎片化，不仅交付周期长，后续业务系统接入成本也会持续上升。

在这一类项目中，实时数据开始从“为单个系统供数”，转向“作为平台能力被复用”：来自多个核心系统与多个数据库集群的数据被统一同步到平台侧，沉淀为统一的商品与库存主数据模型，并通过 API 持续对外提供服务。

当商品与库存数据开始以平台服务的方式被不同业务系统复用，实时能力才真正从“工程管道”，走向可长期演进的业务基础设施。

在酒店服务行业，我们帮助客户搭建起实时客户数据平台。

在这一类高度现场化的服务体系中，客户行为来自 POS、CRM、预订系统、会员系统等多个触点，数据分散、更新频繁、时效要求极高。

如果这些实时数据只能以“同步链路”的方式存在，就很难支撑现场服务、风控与营销系统对毫秒级响应的依赖。

随着业务对实时客户洞察与现场联动能力的要求提升，越来越多前台与运营系统开始依赖同一份“实时客户画像”来驱动决策。实时玩家追踪、实时分析、即时促销与奖励发放，都需要基于统一的实时客户视图。但如果每一个业务系统各自维护一套同步与加工逻辑，实时能力很快就会碎片化为一组难以复用、难以治理的工程管道。

在这一类项目中，实时数据开始从“工程链路”，转向“业务平台能力”：来自不同业务系统的客户行为数据被统一汇入 ODH，在平台侧完成实时加工与聚合，并通过 API 服务对业务系统直接提供。

当实时客户数据开始以服务化的方式被不同业务系统复用，实时能力才真正从后台工程，走向现场业务可以长期依赖的基础设施。

这些不是“未来场景”，而是 2025 年真实发生的业务进化。它们的共同点是：以 TapData 为实时数据底座，将“实时能力”直接嵌入业务闭环，让数据从支持角色，走向驱动角色。

这种转变并不激进，但它意味着更多企业开始把实时数据视为长期基础设施，而不是某个项目的临时解决方案。而这也正是 TapData 产品自身经由多年打磨的能力高光部分，我们的思路不谋而合。

全球同频：2025，实时数据进入“服务化时代”

实时数据开始进入“治理与服务并重”的阶段。在海外市场的交流中，我们也感受到类似的趋势变化。

相比过去几年更关注“能不能跑起来”，2025 年越来越多团队开始关心：

• 实时链路是否具备长期演进能力？
• 是否具备数据治理、权限、血缘与审计能力？
• 是否能支撑业务系统、API 服务与实时应用？
• 是否能从“工程组件”升级为“平台能力”？

这些讨论，本质上不再是工具选型层面的对比，而是在讨论，实时数据，是否已经进入“平台化、服务化、治理化”的阶段。它不再只是技术团队收到的小需求，而是全业务可见、可用的活力资产。

2025：不是终点，而是新的开端

回看 2025 年，我们并不认为这是一个“完成阶段”，倒更像是一个方向逐渐被验证清晰的崭新节点。

从工程视角看，实时数据集成、CDC、流处理依然重要；但从企业视角看，真正决定价值的，是这些能力是否能长期稳定地服务业务系统。

这也是我们在 2026 以及更长远的未来持续坚持的方向：帮助更多企业打牢实时数据业务基础设施，让实时数据的“实用性”最大化。

写在最后：致每一位推动数据觉醒的同行者

感谢 2025 年所有选择 TapData、挑战现状、践行创新的伙伴。

无论您是正将实时数据用于一个具体的同步场景，还是正在构建更长期的实时数据能力平台，我们都很珍惜这些真实场景对产品方向的反馈与塑造。

实时数据这条路，注定不是一蹴而就的工程问题，而是企业架构能力的一次长期演进。这条路，我们走得不早不晚，恰逢其时。

愿我们在今后的日子里，继续把“实时”这件事，做得更稳、更可用，也更可持续。

2026，让我们继续——把数据，变成行动；把实时，变成增长。

新年快乐🎇
TapData 团队

自 2025 年 5 月宣布开源以来，openFuyao 社区已汇聚 30 家成员单位、300 多名开发者、成立 16 个 SIG，围绕多样化算力集群生产场景，探索算力极致释放新路径。

在社区全体成员的共同努力下，构建了 AI 分布式作业调度、K8s-native AI 推理调度、在离线混部调度、超节点使能调度等八大能力，相关成果已在互联网、金融、运营商等关键行业规模应用，支撑工商银行、联通云等重量级项目实现技术突破与落地，助力商业发行版伙伴交付湖北银行等 40+项目，累计部署超 1.1 万套。同时，社区治理日益完善，通过提供一站式开发流水线与层次化学习体系，助力开发者高效参与社区共建。

2026 年，openFuyao 社区将持续增强容器平台的基础能力，实现集群高可用、高安全、易迁移。同时，社区将致力于把多样化算力平滑接入云原生体系，实现算力资源高效释放。此外，社区将持续构建 K8s-native AI 推理调度框架等硬件亲和调度能力，全面提升业务性能与资源效率。并且，社区将全面拥抱超节点应用生态，构建超节点 K8s 使能和调度增强能力，支持零成本接入客户生产，持续赋能开发者探索超节点应用新范式。

openFuyao 正从蓝图加速成长为驱动产业智能化的坚实底座，感谢所有并肩同行的成员单位及开发者朋友们，诚邀更多企业、科研机构、开发者加入 openFuyao，共建多样化算力集群软件繁荣生态！

筹备委员会主席 周俊懿
2026 年 1 月