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

本文整理自 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 将成为企业构建下一代实时数据平台的核心引擎。

​

 VMware17是 VMware Workstation 17​ 的安装包，这玩意儿是用来在电脑上跑虚拟机的，比如你想在一台 Windows 电脑里再装个 Linux、Win7、Win10 来测试软件、搭环境，用它就很方便。

一、准备工作

1. 下载安装包​

   • 安装包下载：https://pan.quark.cn/s/175b29637ce5 ，去 VMware 下 VMware17.exe（注意区分 Workstation Pro 和 Player 版本，Pro 功能全，Player 免费但限制多）。
   • 文件大小几百 MB，下的时候注意别断网。

2. 用管理员身份运行（必须） ​

   • 右键 VMware17.exe→ 选“以管理员身份运行”，不然可能装不上驱动或权限报错。

二、安装步骤

1. 双击 VMware17.exe（如果右键过了就直接双击）。
2. 弹出“用户账户控制”提示 → 点  “是” 。
3. 进入安装向导，选语言（默认英文，有的版本有中文）→ 点  “Next” 。
4. 阅读许可协议 → 选 “I accept…” → 点  “Next” 。

5. 选安装类型：

   • 一般选 Typical（典型安装） ​ 就行，省事儿；想自定义路径或组件就选 Custom。

6. 选安装位置：

   • 默认在 C 盘，可点 Browse 改到其他盘（建议留够空间，虚拟机文件挺占地方）。

7. 用户体验设置：

   • 可取消勾选“帮助改进 VMware…”（不想上报数据就取消），然后点  “Next” 。

8. 快捷方式：

   • 默认勾“桌面快捷方式”和“开始菜单文件夹”，保持默认就行。
9. 点  “Install” ​ 开始安装，等进度条走完（几分钟）。
10. 安装完会提示输入许可证密钥（如果有），没密钥可以先点“Finish”，之后用试用模式。

三、首次运行与基本使用

1. 在开始菜单或桌面找到 VMware Workstation 17​ → 点开。
2. 第一次打开会让选“试用”或“输入许可证”，试用一般能用 30 天。

3. 新建虚拟机：

   • 点“Create a New Virtual Machine” → 选安装来源（ISO 镜像或物理光驱）→ 按向导设置系统类型、内存、硬盘大小 → 完成后启动就能装系统。
4. 虚拟机界面跟真机差不多，鼠标点进去操作，Ctrl+Alt 切回主机。

​

自然语言理解、摘要生成、代码编写、逻辑推理，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

​

DxO ViewPoint 4 是专门用来修照片透视和畸变的工具，Mac 和 Windows 都能用。拍建筑、风景或者人像的时候，经常会遇到画面歪了、线条不直、边缘变形这些问题，用它就能很快调回来。

第一步：先把安装包下好​

安装包下载：https://pan.quark.cn/s/d25f8fb6b22e  ,下载 DxO ViewPoint 4 for Mac v4.13.0.282.dmg，点下载等它跑完。一般默认存在「下载」文件夹里，下完能直接看到这个.dmg文件。

第二步：双击打开dmg文件​

找到下载好的.dmg文件，双击它！会弹出一个新窗口，里面有个DxO ViewPoint的图标（一般是软件logo），旁边箭头指去「应用程序」文件夹。

第三步：拖到“应用程序”里​

按住DxO ViewPoint的图标，直接往右边“应用程序”文件夹拖就行～ 拖过去等几秒，看到进度条走完，就说明复制好了（相当于安装完成）。

第四步：打开软件试试​

打开「访达」，左边点「应用程序」，找到DxO ViewPoint的图标，双击打开。第一次开可能会跳提示“来自未知开发者”（Mac的安全限制），别慌！点提示框里的「仍要打开」，确认后就能正常用了。

​