作者：徐可甲（烨陌）

引言：企业出海，安全合规不再是选择题，而是必答题

近年来，出海已成为越来越多中国企业的选择，出海业务的发展模式也从早期“先上线再整改”的粗放经营，转向“合规前置、本地嵌入、持续迭代”的成熟发展，积极探索从“产品输出”到“技术+品牌+本地化”的深度全球化。但随着欧盟《数字服务法》（DSA）、美国《数据隐私框架》、东南亚各国数据本地化立法加速，“合规先行”已成为企业能否在海外市场长期立足的关键。

越来越多的中企出海案例为创业者提供了清晰的参照：凭借国内成熟的产品化能力和完善的供应链体系，出海拓展全球市场正成为 AI 时代的重要机遇。但成功的出海企业不再仅靠成本优势，而是通过本地化合规架构、税务风控体系、ESG 治理、数据主权管理等多维举措，才能实现“走得出去、留得下来、做得长久”。机遇背后是不可忽视的合规挑战——数据跨境、多地监管、隐私保护、存储架构等问题，必须在业务扩张之前就完成系统性规划。

本文面向安全合规领域的开发者，梳理 AI 出海面临的核心合规挑战，并介绍阿里云日志服务（SLS）如何提供全链路的技术支撑。

出海合规：三道必须跨越的门槛

数据架构的隐患：“三明治模式”

当前许多出海企业的数据架构呈现典型的“三明治”形态：

• 顶层： 海外用户产生数据，海外资本注入资金
• 中层： 核心研发与运营团队驻扎国内
• 底层： 调用 OpenAI、Anthropic、Google 等海外模型服务

这种架构导致数据流转路径异常复杂：用户数据从海外传至国内处理，再转发至美国等地的模型服务商进行推理，最后返回用户。数据在多个司法管辖区之间反复穿梭，同时触发多地的数据主权审查。

全球主要经济体在数据立法时都遵循一个基本原则：本地产生的数据，主权归属本地。“三明治”架构恰恰与这一原则相悖，使企业暴露在多重合规风险之下。

三大市场的监管差异

出海企业通常需要同时应对中国、美国、欧盟三个主要法域的合规要求，它们的监管重心各有侧重。

美国：诉讼驱动，后果严重

美国监管的特点是以诉讼为核心手段，一旦被执法机构“盯上”，往往面临连锁反应式的处罚。

典型案例： 儿童教育机器人品牌 Apitor 因违反《儿童在线隐私保护法》（COPPA）受到处罚。其违规行为包括：通过 SDK 收集儿童精确位置信息、将数据回传中国服务器、隐私政策与实际操作严重不符。最终结果是 50 万美元和解金，外加十年期强制整改令——需销毁违规数据、接受第三方审计、定期提交合规报告。这种长周期、高成本的整改要求，几乎等同于产品在北美市场的“出局”。

欧盟：GDPR 的严格执行

欧盟以《通用数据保护条例》（GDPR）为核心，建立了全球最严格的数据保护体系。其核心理念是：数据归用户所有，企业使用需获得明确授权。

GDPR 的五项关键要求：

值得警惕的案例： 某消费级摄像头产品因中国工程师通过 VPN 访问存储在欧洲的用户数据，被德法两国数据保护机构认定为等效的数据跨境传输。这表明欧盟监管不仅审查数据的物理存储位置，更关注谁能访问这些数据。

中国：备案先行，合规底线

国内以《网络安全法》《数据安全法》《个人信息保护法》构建了完整的数据合规框架。对于 AI 出海业务，有两项硬性要求：

1. 数据出境合规：涉及个人信息或重要数据出境，需完成安全评估或标准合同备案。
2. AI 服务备案：算法备案是基础要求；具有舆论属性或内容生成能力的应用，还需完成生成式 AI 服务备案（俗称“双备案”）。

此外，《网络安全法》第二十一条明确规定：网络日志留存期限不少于六个月。这对日志采集与审计系统提出了明确的技术要求。

合规挑战与解决方案

面对上述复杂的合规环境，AI 出海企业需要一套完整的技术方案来支撑合规要求。以下从三个核心合规挑战出发，介绍阿里云日志服务（SLS）提供的解决方案。

如何实现操作审计与安全事件的快速溯源？

挑战

在美国监管的「顺藤摸瓜」式执法模式下，企业一旦被调查，需要提供完整的证据链来证明合规性。这意味着不仅要记录「谁在何时做了什么」，还要能够快速还原事件的完整上下文。

然而，现代云环境面临着两大挑战：

• 控制面与数据面的割裂： 云端的资源变更（如 OpenAPI 调用）与底层的运行时行为天然处于两个平行的观测维度。
• 异构数据的孤岛效应： K8s 的编排事件、ECS 的系统日志以及云产品的操作记录分散在不同的存储介质中，缺乏统一的上下文关联。

这种多维度的碎片化导致运维与安全团队深陷「数据丰富但信息贫乏」的困境。当异常发生时，仅凭离散的日志，很难将一个高阶的 API 操作精准映射到底层的进程执行或文件读写。

解决方案：云监控 2.0 日志审计

云监控 2.0 日志审计 [ 1] 打破了传统的单点日志查询模式，通过统一采集基座配合三大核心分析能力，构建完整的审计体系。

核心能力：

• 统一采集基座： 整合云产品日志与端侧运行时数据，屏蔽数据来源的碎片化差异。通过 LoongCollector [ 2] 以轻量级、无侵入的方式深入 ECS 主机和容器内部，实时采集文件访问、进程活动等信息。
• UModel 实体建模： 将离散日志映射到具体的云资源对象（如 Pod、ECS、AK），建立资产视角的上下文。系统基于日志上下文自动识别并连接不同层级的同一实体（如 ACS 层的 ECS 实例即 Infra 层的主机，Infra 层的主机即 K8s 层的节点）。
• 跨域关联： 打通 ACS（云控制层）、Infra（基础设施层）与 K8s（容器编排层），实现跨层级链路追踪。审计人员能够跨越日志源的边界，快速完成复杂的溯源任务。

• 告警调查与风险溯源： 提供基于实体的风险发现与溯源能力，支持内置与自定义规则。告警通过调查按钮直达风险拓扑，将复杂的风险关系以拓扑图的方式直观呈现。

合规效果：

• AK 审计场景： 当发生 AK 泄露时，系统不再展示孤立的操作记录，而是将 AK 的使用轨迹绘制成完整的调用链路。管理员可清晰看到该 AK 关联的角色权限及历史访问过的资源，快速厘清「谁持有密钥，动了什么数据」。

• 网络异常流量检测场景： 面对复杂的云网络环境，仅靠 IP 地址很难快速定位问题。日志审计 2.0 集成 VPC 流日志，让网络合规审计变得更加高效。通过地理位置、公网流量等维度，实时监测和分析异常网络流量的来源，例如攻击尝试或突发的不明大流量访问。

• 容器威胁感知场景： 当容器内部被执行未授权命令时（如 Ollama 漏洞被利用写入敏感路径），系统通过对进程事件及文件操作建模，管理员可以从风险进程顺藤摸瓜，找到其上下游调用关系，将攻击路径清晰还原为「异常进程 → Pod → K8s」。

• 主机暴力破解场景： 一旦检测到暴力破解告警，系统自动构建从底层主机到云端 ECS 的关联视图，并展示 VPC、安全组等周边资产，帮助运维人员迅速判断内网横向移动的风险边界。

这种方案让日志审计不再是孤立的数据查询，而是围绕资源对象的全生命周期行为分析，真正实现从「看日志」到「掌全局」的安全运营升级。

如何满足日志留存与集中审计的法规要求？

挑战

全球各主要法域对日志留存都有明确的强制性要求：

• 中国《网络安全法》： 网络日志留存不少于六个月
• 欧盟 GDPR： 要求数据访问可追溯，能够证明数据处理的合法性
• 美国各行业法规： 如 PCI-DSS、HIPAA 等对日志审计有严格规定

对于出海企业而言，更大的挑战在于：业务横跨全球多个地域，不同地域的日志需要满足数据本地化存储要求，同时又需要实现集中化分析以满足安全运营需求。一个基础的全球数据存储布局至少需要覆盖四个节点：

• 美国：覆盖北美及大部分中南美洲市场。
• 欧盟：通常选择法兰克福，覆盖整个欧盟及英国市场。
• 新加坡：覆盖东南亚市场（印度、沙特、日韩等需单独节点）。
• 中国：服务国内用户。

传统方案往往导致「信息孤岛」——日志分散在不同地域、不同账号，无法形成统一的安全视图。

解决方案：日志审计（新版）

阿里云日志审计（新版） [ 3] 专为跨地域、跨账号的日志集中管理而设计，已通过《信息安全技术网络安全专用产品安全技术要求》（GB 42250-2022）及《信息安全技术日志分析产品安全技术要求》（GA/T 911-2019）认证，是国家认可的网络安全专用产品。备注：当前以独立的应用形态存在，后续将于云监控 2.0 彻底融合。

核心能力：

• 多日志中心汇总：支持将国内日志存储到上海中心、国外日志存储到新加坡中心，满足跨境合规的数据本地化要求。日志只需接入一次，即可根据规则配置汇总到多个目标日志库。
• RD 资源目录跨账号采集：基于阿里云资源目录（RD），管理员可以一键将成员账号的所有日志汇总到管理员账号下，实现组织级别的统一审计。当资源目录下有账号新增或变更时，系统会自动适应。
• 云产品日志自动化接入：深度集成操作审计（ActionTrail）、对象存储（OSS）、专有网络（VPC）、负载均衡（SLB）等关键云产品的日志。用户无需手动配置复杂的投递规则，只需简单的接入操作即可自动完成底层资源的编排与日志流转。

这种方案打破了「信息孤岛」，在满足各地数据本地化存储要求的同时，实现了全球日志的统一管理和安全洞察。

如何保护敏感数据，防止隐私泄露？

挑战

GDPR 的「数据最小化原则」要求企业只能收集业务必需的最少数据，同时各国对敏感数据（生物识别、儿童数据等）的保护要求越来越严格。

然而，AI 应用的日志中往往隐藏着大量敏感数据：

• 用户咨询里可能出现手机号、订单号、收货地址。
• 后端业务日志中常常包含银行卡号、接口 IP、账户 ID。
• 工单流转过程中甚至会附带内部 Token、用户名。

这些信息若在系统内未经处理地流转、存储或导出，不仅违反数据最小化原则，更可能在调试、共享或导出日志时意外泄露。然而，现实场景中又无法简单地「少打日志」或「去掉字段」——日志是运维排障的工具，是运营分析的基础，也是安全审计的依据。

解决方案：脱敏函数

SLS 提供了丰富的脱敏方案，用户可以根据情况灵活选择：

• Logtail 端侧脱敏（数据流 1）：配置 SLSLogtail采集后，在端侧进行处理脱敏，然后写入 SLS 日志库中。
• Logtail + Ingest Processorer 脱敏（数据流 2）组合：对于日志产生速度较高，且需要进行大量正则处理的场景，iLogtail 本身也会占用一定的计算资源。为了避免高强度的资源占用严重影响服务器上的其他业务进程，可以在 Logtail 端侧仅配置采集任务，然后通过 Ingest Processorer（写入处理器）配置 SPL 语句在日志服务侧完成脱敏处理。
• SDK+ Ingest Processorer 脱敏（数据流 3）组合：除了通过 Logtail 采集日志外，我们还可以基于SDK通过接口调用完成日志写入，通过 Ingest Processorer里设置脱敏语句，脱敏处理在日志服务中完成，不占用端侧资源。

传统数据脱敏往往采用正则处理的方式，但在面对日益复杂的数据场景时，正则表达式的局限性也逐渐凸显：处理十多种敏感信息类型需要编写数十个复杂正则表达式，维护成本呈指数级增长；多重嵌套的正则操作会严重拖慢实时处理性能；JSON、URI、纯文本的混合日志格式难以用统一正则配置高效处理。为此，SLS 推出了全新的 mask（脱敏）函数 [ 4] ，能够对结构化和非结构化日志中的敏感数据进行精准识别和脱敏，无需编写复杂正则，开箱即用。

核心能力：

• 内置匹配（buildin）：开箱即用，内置对常见 6 种敏感信息的智能识别能力——手机号、身份证、邮箱、IP 地址、座机电话、银行卡号。无需编写任何正则表达式，仅需在配置中指定要脱敏的类型即可。
• 关键字匹配（keyword）：智能识别任意文本中符合 "key":"value"、'key':'value' 或 key=value 等常见 KV 对格式的敏感信息。即使数据嵌套多层 JSON 结构，也只需配置最内层的 Key 即可精准匹配，特别适合处理 AI 应用中常见的复杂嵌套日志。
• 按需保留：针对不同敏感字段，可定制化保留前后缀字符。例如手机号保留前三后四位（199****2345），既保护用户隐私，又方便运维人员进行问题排查和用户身份核验，实现安全与可用性的平衡。
• 高性能处理：相比传统正则方案，mask 函数在复杂脱敏场景下性能提升可达 2.8 倍，特别适用于大数据量和多类型敏感信息混合处理的场景。

结语

对于 AI 出海企业而言，合规不是「要不要做」的选择题，而是「该怎么做」的必答题。从 Manus 的成功路径可以看到，前置解决数据合规、法律合规问题，是融入国际市场的关键一步。

在实践中，有三条经验值得借鉴：

1. 合规布局比业务推进早半步：很多企业发展速度非常快，短短几个月用户就能涨到数万。如果在用户爆发后才考虑数据架构迁移或团队海外落地，不仅成本极高，风险也更大。合规规划应当与产品规划同步启动。
2. 合规是持续运营而非一次性工作：全球监管环境在不断演进，GDPR 在持续更新，各国数据保护法规也在陆续出台。企业需要建立持续的合规监控机制，而非将合规视为一次性的“过审”项目。
3. 技术方案要支撑业务敏捷性：选择能够自动适应业务变化的技术方案——如自动发现新增云资源、自动适配新增账号、自动识别敏感数据——避免合规成为业务发展的瓶颈。

阿里云日志服务（SLS）通过日志审计、数据脱敏等能力，为出海企业提供了从日志采集、存储、脱敏到分析溯源的全链路合规支撑。无论是满足《网络安全法》的日志留存要求，还是应对 GDPR 的数据保护挑战，都能提供坚实的技术底座。

合规之路虽然复杂，但有了正确的技术方案和前瞻性的布局，AI 企业就能在全球化浪潮中稳健前行，书写属于自己的出海故事。

参考文章：

《想成为下一个 Manus，先把这些出海合规问题处理好》

《已上线！云监控 2.0 面向实体的全链路日志审计与风险溯源》

相关链接：

[1] 云监控 2.0 日志审计

https://help.aliyun.com/zh/cms/cloudmonitor-2-0/log-audit/

[2] LoongCollector

https://help.aliyun.com/zh/sls/what-is-sls-loongcollector

[3] 阿里云日志审计（新版）

https://help.aliyun.com/zh/sls/new-log-audit-service/

[4] mask（脱敏）函数

https://help.aliyun.com/zh/sls/data-masking-with-the-mask-fun...

2025/7/18 --Yichao 'Peak' Ji

在Manus项目的最初阶段，我和我的团队面临一个关键决策：我们是应该使用开源基础模型训练一个端到端的智能体模型，还是基于前沿模型的上下文学习能力构建一个智能体？

在我的NLP生涯的第一个十年里，我们没有这种选择的奢侈。在遥远的BERT时代（是的，已经过去七年了），模型必须先进行微调——和评估——才能迁移到新任务。这个过程通常每次迭代需要数周时间，尽管与今天的LLM相比，这些模型非常小。对于快速发展的应用，特别是在产品市场匹配(PMF)之前，这种缓慢的反馈循环是一个致命缺陷。这是我上一个创业公司的惨痛教训，当时我从头开始训练模型用于开放信息提取和语义搜索。然后GPT-3和Flan-T5出现了，我的内部模型一夜之间变得无关紧要。具有讽刺意味的是，这些相同的模型标志着上下文学习的开始——以及一条全新的前进道路。

这个来之不易的教训使选择变得明确：Manus将押注于上下文工程。这使我们能够在几小时而非几周内交付改进，并使我们的产品与底层模型保持正交：如果模型进步是上涨的潮水，我们希望Manus成为那条船，而不是固定在海床上的柱子。

尽管如此，上下文工程证明绝非易事。这是一门实验科学——我们已经重建了我们的代理框架四次，每次都是在发现了更好的塑造上下文的方式之后。我们亲切地将这种手动架构搜索、提示调整和经验猜测的过程称为"随机研究生下降"。这并不优雅，但它有效。

这篇文章分享了我们通过自己的"SGD"所达到的局部最优解。如果你正在构建自己的AI代理，我希望这些原则能帮助你更快地收敛。

围绕KV缓存进行设计

如果我必须选择一个指标，我认为 KV-cache命中率 是生产阶段AI代理最重要的单一指标。它直接影响延迟和成本。为了理解原因，让我们看看典型代理是如何运作的：

在接收用户输入后，代理通过一系列工具使用链来完成任务。在每次迭代中，模型根据当前上下文从预定义的动作空间中选择一个动作。然后在环境中执行该动作（例如，Manus的虚拟机沙盒）以产生观察结果。动作和观察结果被附加到上下文中，形成下一次迭代的输入。这个循环持续进行，直到任务完成。

正如你所想象的，随着每一步的推进，上下文不断增长，而输出——通常是结构化的函数调用——保持相对简短。这使得代理（agents）相比聊天机器人的预填充和解码比例高度倾斜。例如在Manus中，平均输入与输出的token比例约为100:1。

幸运的是，具有相同前缀的上下文可以利用KV缓存，这大大减少了首个token的生成时间(TTFT)和推理成本——无论你是使用自托管模型还是调用推理API。我们说的不是小幅度的节省：例如使用Claude Sonnet时，缓存的输入token成本为0.30美元/百万token，而未缓存的成本为3美元/百万token——相差10倍。

从上下文工程的角度，提高KV缓存命中率涉及几个关键实践：

1. 保持你的提示前缀稳定。 由于LLM的自回归特性，即使是单个标记的差异也会使该标记之后的缓存失效。一个常见的错误是在系统提示的开头包含时间戳——尤其是精确到秒的时间戳。虽然这让模型能告诉你当前时间，但也会降低你的缓存命中率。
2. 使你的上下文只追加。 避免修改之前的操作或观察。确保你的序列化是确定性的。许多编程语言和库在序列化JSON对象时不保证键顺序的稳定性，这可能会悄无声息地破坏缓存。
3. 在需要时明确标记缓存断点。 某些模型提供商或推理框架不支持自动增量前缀缓存，而是需要在上下文中手动插入缓存断点。在分配这些断点时，要考虑潜在的缓存过期问题，并至少确保断点包含系统提示的结尾。

此外，如果你正在使用像 vLLM这样的框架自托管模型，请确保启用了前缀/提示缓存，并且你正在使用会话 ID 等技术在分布式工作节点之间一致地路由请求。

遮蔽，而非移除

随着代理能力的增强，其行动空间自然变得更加复杂——简单来说，工具数量爆炸式增长。最近流行的MCP只会火上浇油。如果你允许用户自定义工具，相信我：总会有人将数百个神秘工具插入到你精心策划的行动空间中。结果，模型更可能选择错误的行动或采取低效的路径。简而言之，你武装过度的代理变得更加愚蠢。

一个自然的反应是设计一个动态行动空间——可能是使用类似于RAG的方法按需加载工具。我们在Manus中也尝试过这种方法。但我们的实验表明了一个明确的规则：除非绝对必要，避免在迭代过程中动态添加或移除工具。 这主要有两个原因：

1. 在大多数LLM中，工具定义在序列化后位于上下文的前部，通常在系统提示之前或之后。因此任何更改都会使后续所有动作和观察的KV缓存失效。
2. 当先前的动作和观察仍然引用当前上下文中不再定义的工具时，模型会感到困惑。如果没有约束解码，这通常会导致模式违规或幻觉动作。

为了解决这个问题并仍然改进动作选择，Manus使用上下文感知的状态机来管理工具可用性。它不是移除工具，而是在解码过程中掩蔽token的logits，以基于当前上下文阻止（或强制）选择某些动作。

在实践中，大多数模型提供商和推理框架支持某种形式的响应预填充，这允许你在不修改工具定义的情况下约束动作空间。函数调用通常有三种模式（我们将使用 NousResearch 的 Hermes 格式 作为示例）：

• 自动 – 模型可以选择调用或不调用函数。通过仅预填充回复前缀实现：<|im_start|>assistant
• 必需 – 模型必须调用函数，但选择不受约束。通过预填充到工具调用令牌实现：<|im_start|>assistant<tool_call>
• 指定 – 模型必须从特定子集中调用函数。通过预填充到函数名称的开头实现：<|im_start|>assistant<tool_call>{"name": "browser_

通过这种方式，我们通过直接掩码token的logits来约束动作选择。例如，当用户提供新输入时，Manus必须立即回复而不是执行动作。我们还有意设计了具有一致前缀的动作名称——例如，所有与浏览器相关的工具都以browser_开头，命令行工具以shell_开头。这使我们能够轻松确保代理在给定状态下只从特定工具组中进行选择而无需使用有状态的logits处理器。

这些设计有助于确保Manus代理循环保持稳定——即使在模型驱动的架构下。

使用文件系统作为上下文

现代前沿LLM现在提供128K令牌或更多的上下文窗口。但在真实世界的代理场景中，这通常不够，有时甚至是一种负担。有三个常见的痛点：

1. 观察结果可能非常庞大，尤其是当代理与网页或PDF等非结构化数据交互时。很容易超出上下文限制。
2. 模型性能往往会下降，超过一定的上下文长度后，即使技术上支持该窗口大小。
3. 长输入成本高昂，即使使用前缀缓存。你仍然需要为传输和预填充每个token付费。

为了解决这个问题，许多代理系统实现了上下文截断或压缩策略。但过度激进的压缩不可避免地导致信息丢失。这个问题是根本性的：代理本质上必须根据所有先前状态预测下一个动作——而你无法可靠地预测哪个观察结果可能在十步之后变得至关重要。从逻辑角度看，任何不可逆的压缩都带有风险。

这就是为什么我们在Manus中将文件系统视为终极上下文：大小不受限制，天然持久化，并且代理可以直接操作。模型学会按需写入和读取文件——不仅将文件系统用作存储，还用作结构化的外部记忆。

我们的压缩策略始终设计为可恢复的。例如，只要保留URL，网页内容就可以从上下文中移除；如果沙盒中仍然保留文档路径，则可以省略文档内容。这使得Manus能够缩短上下文长度，而不会永久丢失信息。

在开发这个功能时，我发现自己在想象状态空间模型(State Space Model, SSM) 在智能体环境中有效工作需要什么条件。与Transformer不同，SSM缺乏完整的注意力机制，并且在处理长距离的后向依赖关系时表现不佳。但如果它们能够掌握基于文件的记忆——将长期状态外部化而不是保存在上下文中——那么它们的速度和效率可能会开启一类新型智能体。基于SSM的智能体可能是神经图灵机真正的继任者。

通过复述操控注意力

如果你使用过Manus，你可能注意到一个有趣的现象：在处理复杂任务时，它倾向于创建一个todo.md文件——并在任务进行过程中逐步更新它，勾选已完成的项目。这不仅仅是可爱的行为——这是一种操控注意力的刻意机制。

Manus中的一个典型任务平均需要大约50次工具调用。这是一个很长的循环——由于Manus依赖LLM进行决策，它很容易偏离主题或忘记早期目标，尤其是在长上下文或复杂任务中。

通过不断重写待办事项列表，Manus将其目标复述到上下文的末尾。这将全局计划推入模型的近期注意力范围内，避免了"丢失在中间"的问题，并减少了目标不一致。实际上，它使用自然语言来使自己的注意力偏向任务目标——而不需要特殊的架构变更。

保留错误的内容

代理会犯错。这不是bug——这是现实。语言模型会产生幻觉，环境会返回错误，外部工具会出现异常行为，意外的边缘情况随时都会出现。在多步骤任务中，失败不是例外；它是循环的一部分。然而，一个常见的冲动是隐藏这些错误：清理痕迹，重试操作，或重置模型的状态并将其留给神奇的"温度"。这感觉更安全，更受控制。但这是有代价的：擦除失败会移除证据。没有证据，模型就无法适应。

根据我们的经验，改善代理行为最有效的方法之一出奇地简单：将错误的尝试保留在上下文中。 当模型看到一个失败的行动——以及由此产生的观察结果或堆栈跟踪——它会隐式地更新其内部信念。这会改变其先验，降低重复相同错误的可能性。

事实上，我们认为错误恢复是真正代理行为的最明显指标之一。然而，在大多数学术工作和公共基准测试中，这一点仍然代表性不足，它们通常关注理想条件下的任务成功。

不要被少样本示例所困

少样本提示是提高LLM输出的常用技术。但在代理系统中，它可能会以微妙的方式适得其反。

语言模型是优秀的模仿者；它们模仿上下文中的行为模式。如果你的上下文充满了类似的过去行动-观察对，模型将倾向于遵循该模式，即使这不再是最优的。

这在涉及重复决策或行动的任务中可能很危险。例如，当使用Manus帮助审查20份简历时，代理通常会陷入一种节奏——仅仅因为这是它在上下文中看到的，就重复类似的行动。这导致偏离、过度泛化，或有时产生幻觉。

解决方法是增加多样性。Manus在行动和观察中引入少量的结构化变化——不同的序列化模板、替代性措辞、顺序或格式上的微小噪音。这种受控的随机性有助于打破模式并调整模型的注意力。

换句话说，不要让自己陷入少样本学习的窠臼。你的上下文越单一，你的智能体就变得越脆弱。

结论

上下文工程仍然是一门新兴的科学——但对于智能体系统来说，它已经是必不可少的。模型可能变得更强大、更快速、更经济，但再多的原始能力也无法替代对记忆、环境和反馈的需求。你如何塑造上下文最终决定了你的智能体的行为方式：它运行的速度、恢复的效果以及扩展的范围。

在Manus，我们通过反复的重写、死胡同以及面向数百万用户的实际测试学到了这些经验。我们在这里分享的内容并非放之四海而皆准的真理——但这些是对我们有效的模式。如果它们能帮助你避免哪怕一次痛苦的迭代，那么这篇文章就达到了它的目的。

智能体的未来将一次构建一个上下文。好好设计它们吧。

在企业研发管理实践中，IPD 往往是必修课，但很多团队在推进过程中发现，光有流程和制度远远不够。工具的选择，往往直接决定了 IPD 能否真正落地。
华为云 CodeArts、飞书项目与 Siemens Teamcenter 各自沿着不同的路线优化研发协作与流程管理：有的偏向完整工业级流程，有的擅长敏捷团队协作，有的强调数据和配置管理。
本文将结合实际落地场景，分析三款工具在不同组织类型和研发阶段中的适配度与能力边界，帮助团队在选型时少走弯路。

华为云 CodeArts（原 DevCloud）

定位： IPD理念的“原产地”与“正统派”。

核心卖点

源自华为 30 年实践： 这不是一款普通的商业软件，而是华为将自身 30 年的研发管理变革经验“代码化”后的产物。它内置了华为内部一直在使用的标准工作流和管理模板。端到端全链路打通： 实现了从客户需求（Epic）到特性（Feature）再到开发任务（Story）的闭环管理，确保每一个开发动作都能追溯到最初的市场价值。

如何支撑 IPD 流程

1. 结构化流程固化： IPD 强调复杂的决策评审（CDCP、PDCP）。
   CodeArts 预置了这些关键节点，强制要求项目在进入下一阶段前完成必要的动作，防止流程“随意剪裁”。

2. 分层分级管理： 完美适配 IPD 的“产品线-产品-版本”三层架构。
   它允许 PD（产品经理）在顶层看路标，PM（项目经理）在中间管进度，开发人员在底层做执行，数据自动聚合。
3. 需求价值流（OR）：
   它的需求管理极其严谨，支持 $APPEALS 等分析模型，帮助团队在立项初期就剔除伪需求。

缺点与挑战

1. 灵活性不足：带有强烈的“华为基因”，流程规范非常严苛。对于不想完全照搬华为模式的企业，修改配置的难度较大。
2. 上手门槛高： 界面充斥着大量的专业术语和复杂字段，如果团队没有经过 IPD 培训，员工会有较强的抵触心理。

适合谁？

行业： ICT、通信、大型软件研发、智能硬件。
企业画像： 立志全盘引入华为管理体系的中大型企业，且企业内部已有一定的流程管理文化基础。

飞书项目 - 行业专版

定位： 流程型组织的大杀器，用“柔性”解决 IPD 的“刚性”痛点。

飞书项目是 IPD 软件领域的一个破局者。如果说华为 CodeArts 是严谨的“教官”，Teamcenter 是厚重的“仓库”，那么飞书项目更像是一个“超级连接器”。它不仅仅是一个项目管理工具，而是试图用互联网的极致协作体验去重构传统且僵化的 IPD 流程。

核心卖点

1. 流程像“乐高”一样灵活：
   它是市面上配置能力最强的工具之一。传统的 IPD 软件改一个流程可能需要找厂商二次开发，而在飞书项目里，业务人员可以通过拖拽节点自定义复杂的串行、并行、判断流程。

2. “聊着天就把项目管了”：
   它与飞书（IM、文档、会议）深度集成。IPD 流程中大量的评审（TR）、决策（DCP）往往死于沟通效率低，飞书项目能让评审在群里自动触发，文档直接关联，极大地降低了协作摩擦。

3. 可视化“泳道图”：
   它把复杂的 IPD 计划变成了直观的“全景泳道图”，不同部门（市场、研发、供应链）在同一张图上协作，依赖关系一目了然，非常适合解决跨部门“扯皮”。

如何与 IPD 流程契合

1. 结构化流程落地：
   它可以完美复刻 IPD 的“阶段-关口”（Stage-Gate）模型。通过设置“关键节点”，如果不完成规定的评审要素（如文档、签字），流程就无法流转到下一阶段。
2. 角色与权限协同：
   IPD 强调 PDT（产品开发团队）作战，飞书项目支持极细颗粒度的权限管控，能让市场看市场的视图，开发看开发的视图，但底层数据是互通的。
3. 度量与复盘：
   它自带强大的 BI 仪表盘，可以实时分析流程效率（比如：某个评审环节平均卡了多少天），这非常符合 IPD 中“持续改进”的理念。

缺点与挑战

1. “空盒子”属性： 它刚交付时往往是一个“空盒子”或者“半成品模版”，需要企业有很强的流程配置专家（ CSM）去把公司的 IPD 流程“画”进去。如果你没有想清楚自己的流程，用起来会很乱。
2. 工程数据管理弱： 它擅长管“事”和“人”，但不擅长管“物”。它无法像 Teamcenter 那样管理复杂的 BOM 结构、CAD 图纸的版本分支。做硬件研发时，它通常需要和 PLM 系统做对接。

适合企业/行业

行业： 新势力造车、消费电子（手机、无人机）、游戏、复杂的软硬结合项目。
企业类型： 1. 追求速度的创新型企业： 觉得传统 PLM 太慢、太难用，希望用互联网思维做硬件的公司。 2. 协作痛点极大的公司： 部门墙严重，急需通过工具拉通沟通的企业。

Siemens Teamcenter

定位：全球制造业的“物理底座”与“数据派”

核心卖点

1. 单一数据源（Single Source of Truth）：
   无论你有多少个工厂、多少个设计中心，Teamcenter 确保所有人看到的图纸、BOM 和工艺数据是唯一且准确的。

2. 多学科融合：
   它是极少数能同时完美管理机械（MCAD）、电子（ECAD）和软件（ALM）数据的平台，是复杂系统工程的基石。

如何支撑 IPD 流程

1. 刚性的阶段门径控制（Stage-Gate）： Teamcenter 最擅长管理 IPD 的“关口”。如果不完成规定的工程文档归档，系统会物理锁死，无法进入下一阶段，确保流程绝对刚性执行。
2. 变更管理（ECR/ECO）： IPD 流程中，产品变更牵一发而动全身。Teamcenter 提供了最严谨的变更闭环管理，确保从设计到制造的一致性。

缺点与挑战

1. 昂贵且笨重： 实施费用通常以百万/千万级计算，周期长达一年以上，不仅是购买软件，更是购买咨询服务。2. 用户体验老旧： 典型的工业软件界面，交互复杂，对于习惯了互联网软件的现代研发人员来说，使用体验极差。

适合谁？

行业： 汽车主机厂、航空航天、重型机械、高端医疗器械。
企业画像： 产品极其复杂，BOM 结构庞大，对数据准确性和安全性要求高于一切的超大型制造企业。

本文首发于 Aloudata 官方技术博客：《一表痛、EAST、1104 报表口径文档自动生成：解析 SQL 过滤条件，一键溯源与保鲜》转载请注明出处。

摘要：EAST 等监管报送指标口径文档的自动生成，核心挑战在于对复杂 SQL 中过滤条件（WHERE、JOIN ON等）的精准识别与逻辑解析。传统表级或列级血缘工具无法穿透此逻辑，导致人工梳理耗时数月、口径易失效。本文探讨了如何通过算子级血缘与行级裁剪技术，实现 EAST 口径的自动化盘点与一键溯源，将盘点效率提升 20 倍，并构建主动元数据驱动的数据治理闭环。

在金融监管日益严格的背景下，EAST、1104 等监管报送已成为银行数据团队的核心工作。然而，指标口径文档的梳理却是一个公认的“效率黑洞”。传统依赖人工逐行扒代码的方式，不仅耗时数月，且难以保证口径的准确性与实时性。本文将深入剖析这一难题的技术核心——SQL 过滤条件的精准解析，并介绍如何通过算子级血缘技术实现 EAST 口径文档的自动化生成与持续保鲜。

一、监管报送的困境：传统口径梳理的真实成本

面对复杂的监管指标，银行数据团队普遍陷入“看不清、盘不动、保鲜难”的困境。监管指标的加工逻辑通常深藏在数百行、涉及多级嵌套和存储过程的 SQL 中。

这种传统人工模式的成本主要体现在三个维度：

• 效率黑洞：一个 EAST 指标的口径梳理，需要数仓工程师反复沟通、逐层追溯，耗时数周甚至数月。相比之下，采用自动化手段的机构（如浙江农商联合银行）可将全盘盘点时间从数月缩短至 8 小时。
• 精度盲区：人工解读复杂 SQL（如嵌套子查询、存储过程）极易遗漏关键过滤条件。例如，“对公贷款余额”指标可能包含“贷款状态=正常”、“客户行业非房地产”等多个 WHERE 筛选，人工偏差会直接导致口径文档失真，埋下合规隐患。
• 保鲜难题：数据仓库持续演进，一旦上游 ETL 逻辑变更，静态的、人工维护的口径文档立即失效，导致文档与实际生产长期脱节。

二、技术破局关键：为何传统血缘工具无法解析 SQL 过滤条件？

自动化生成口径文档的构想之所以难以落地，根本在于传统血缘工具的解析粒度不足。它们无法理解 SQL 中最关键的“行级数据筛选逻辑”。

真正的难点不是回答“数据来自哪个表的哪个字段”，而是回答“这个指标具体是由哪一部分数据（符合什么条件）计算出来的”。这正是 WHERE、JOIN ON 等过滤条件的价值所在。

传统工具在此存在代际差距：

• 表级血缘的“狼来了”效应：仅能告知数据来源表，当非相关字段变更时，会产生大量无效下游影响告警，消耗信任。
• 列级血缘的“半盲状态”：能追踪字段传递，但无法解析 CASE WHEN 条件分支、复杂表达式，尤其无法穿透 WHERE 子句的过滤逻辑。它无法告知“某分行存款总额”是否限定了“客户等级=A 类”。

因此，要实现口径的自动化、准确化提取，必须突破列级血缘，深入到 SQL 执行的算子层面，即算子级血缘（Operator-level Lineage）。

三、核心解法：算子级血缘与行级裁剪技术

以 Aloudata BIG 为代表的主动元数据平台，通过深入解析 SQL 的抽象语法树（AST），实现了算子级血缘，从而将黑盒化的数据加工链白盒化。其核心能力包括：

1. 白盒化口径提取：自动穿透临时表、多层嵌套子查询以及 DB2、Oracle 等存储过程（PL/SQL），将分散在多段 SQL 中的业务逻辑，压缩合并成一段清晰、可读的“加工口径描述”，直接输出文档文本。
2. 行级裁剪 (Row-level Pruning)：精准识别 WHERE、JOIN ON、HAVING 等子句中的过滤条件。在进行上游变更影响分析时，能智能判断变更是否真的会影响当前指标。例如，上游表“客户信息表”中“所属支行”枚举值变更，只会影响筛选条件中包含该支行的下游指标。此项技术能将不必要的评估分支减少 80% 以上，实现精准影响分析。
3. 可视化逐层下钻：提供从报表指标反推至源系统的完整可视化血缘图谱，可点击任意节点查看具体加工 SQL、字段映射及关键过滤条件，便于复核、审计与问题定位。

四、实践验证：银行如何将 EAST 盘点效率提升 20 倍？

头部金融机构的实践已验证，基于算子级血缘的自动化口径管理能带来显著业务回报：

• 浙江农商联合银行：解决了 DB2 存储过程血缘解析的行业难题。通过部署相关技术，实现了监管指标溯源人效提升 20 倍，EAST 等指标的全盘盘点周期从数月缩短至 8 小时内完成，对 DB2 存储过程的解析准确率达 99%。

这些案例证明，自动化口径管理是实现 “指标溯源、血缘分析、线上化管理” 的核心技术基石。

五、实施路径：从试点到全行推广

建议金融机构采用“由点及面、价值驱动”的策略，构建主动元数据能力：

1. 场景试点，验证价值：选取 1-2 个逻辑复杂的 EAST 报表模块（如“大额风险暴露”）试点，重点验证算子级血缘解析准确率与自动化生成口径的可用性。
2. 流程嵌入，形成闭环：将自动化口径与现有报送流程、DataOps 研发流程融合。实现 SQL 变更的事前影响评估（风险防控）和故障的分钟级根因定位。
3. 体系推广，构建基座：将能力扩展至 1104、一表通等体系，并应用于数仓模型治理、敏感数据管控等场景，最终构建企业级 DataOps 体系。

六、常见问题 (FAQ)

Q1: 算子级血缘和列级血缘主要区别是什么？对 EAST 报送具体有何帮助？

算子级血缘深入 SQL 执行计划，能精准解析 WHERE 过滤、JOIN 条件、聚合分组等具体操作逻辑；列级血缘只追踪字段映射关系，无法理解数据筛选逻辑。对于 EAST 报送，算子级血缘能自动回答“指标是基于哪部分数据（如‘贷款状态=正常’）计算的”，从而生成准确口径文档，而列级血缘只能给出字段列表，仍需大量人工解读。

Q2: 我们的 SQL 非常复杂，包含大量存储过程和嵌套查询，能准确解析吗？

可以。以 Aloudata BIG 为例，其核心技术优势之一就是覆盖复杂场景，特别对 DB2、Oracle、GaussDB 等的存储过程（PL/SQL）进行了深度适配，解析准确率超过 99%。无论是动态 SQL、临时表还是多层嵌套，都能实现穿透解析。

Q3: 自动生成的口径文档，如何保证其持续“保鲜”，跟上代码的变更？

主动元数据平台的血缘关系通过主动解析代码、日志等方式实时或准实时更新。当上游代码变更时，平台能自动重新解析并通知责任人。基于此生成的口径文档是“活”的、与代码逻辑实时同步的视图，解决了传统文档“一发布即过时”的难题。

核心要点总结

1. 核心难点：EAST 口径自动化生成的最大技术障碍在于对 SQL 中行级过滤条件（WHERE 等）的精准解析。
2. 技术代差：算子级血缘（Operator-level Lineage） 通过解析 SQL 执行算子，实现了 >99% 的解析准确率与行级裁剪能力，是破局关键。
3. 核心价值：能够自动穿透复杂逻辑（如存储过程），一键生成可读口径，并将监管指标盘点效率提升 20 倍，实现口径实时保鲜。
4. 演进路径：从痛点场景试点出发，将自动化能力嵌入 DataOps 流程，最终构建覆盖全链路的主动元数据基座。

再次提醒：本文更详细的图表与案例细节，请访问 Aloudata 官方技术博客阅读原文：https://ai.noetl.cn/knowledge-base/east-document-generation-s...

在当今快节奏且竞争激烈的商业环境中，高效的项目管理对于按时、按预算、高质量地交付项目至关重要。项目管理工具在组织任务、跟踪进度和促进协作方面发挥着关键作用。在众多功能中，报告功能尤为重要，因为它能将原始项目数据转化为有意义的洞察，从而支持明智的决策。

• 增强可见性和透明度
• 支持更佳决策
• 改进资源管理
• 跟踪绩效和生产力
• 促进与利益相关者的沟通和报告

在现代组织中，项目会产生大量与任务、时间表、成本、资源和绩效相关的数据。虽然标准报告可以提供有用的摘要，但每个组织和项目都有其独特的需求。项目管理工具中的可定制报告功能正是在此发挥了极其重要的作用。它允许用户根据自身特定目标设计报告，从而使项目数据更具相关性、可操作性和影响力。

• 满足不同利益相关者的需求
  不同的利益相关者需要不同类型的信息。高管可能需要高层次的进度和预算摘要，项目经理可能需要详细的任务和风险报告，而团队成员则可能专注于各自的工作。可定制报告使每个利益相关者都能只查看对他们而言重要的数据，从而提高清晰度并减少信息过载。
• 利用相关数据改进决策
  可定制报告允许用户选择特定参数，例如日期范围、项目阶段、任务状态、优先级和团队成员。通过以有意义的方式筛选和组织数据，管理者可以识别趋势、及早发现问题并做出明智的决策。相关数据有助于更快、更准确地解决问题。
• 增强项目控制和监控
  每个项目都有其独特的成功指标。借助可定制的报告，管理人员可以根据项目特定的关键绩效指标 (KPI) 跟踪进度。无论是成本偏差、进度绩效还是质量指标，都可以定制报告，以精确监控定义该项目成功的要素。

Zoho Projects 支持自定义模块帮助您按照您的需求创建和导出报表。Zoho Projects在全局层和项目层有自定义报表。在该报表中， 用户可以设置报表的图表配置，可以确定报表中希望添加的条件和采取希望查看的数据。您可以添加新的报表，可以克隆或者编辑报表或者如果您希望分组报表可以在不同的文件夹中保存报表。Zoho Projects为任务，项目，里程碑，问题，工时表等所有的模块支持自定义报表。

Zoho Projects报表中用户还可以创建自定义视图和按照设置的视图，可以查看和导出报表。比如说，项目经理希望查看已经批准的所有的工时。他可以创建一个自定义视图，视图中添加一个条件，“审批状态是一批准“。 添加条件以后，可以选择在视图中希望显示的列并点击保存。创建该视图以后，如果项目经理在报表模块中选择创建的视图，他可以按照创建的视图查看报表。然后他还可以添加其他的条件和导出报表。这样的自定义报表选项让一个项目管理软件成更加灵活。

精选文章：

AgentScope 拥抱函数计算 FC，为 Agent 应用提供 Serverless 运行底座

一杯咖啡成本搞定多模态微调：FC DevPod + Llama-Factory 极速实战

一文看懂函数计算 AgentRun，让 Agentic AI 加速进入企业生产环境

AgentRun Sandbox SDK 正式开源！集成 LangChain 等主流框架，一键开启智能体沙箱新体验

探秘 AgentRun丨通过无代码创建的 Agent，如何用高代码进行更新？

AgentRun 实战：快速构建 AI 舆情实时分析专家

产品最新消息

作者 | 三线程序员
Tags | MySQL Doris PG 达梦 金仓
关键词 | SeaTunnel、DolphinScheduler、信创、国产、达梦、人大金仓

• 适用版本：apache-seatunnel-2.3.8+、apache-dolphinscheduler-3.1.7、人大金仓8.6/9.x
• 预估阅读：10 min

[toc]

一、为什么要写这篇

集团内部关于数据平台近期遇到了两次异构数据源的问题，洽好利用了开源工具简单应对，验证了自己目前工作的思路，正好总结一下分享过程中的收获也经验。以下只谈技术方案选择与经验分享，不讨论数据量、性能、安全等其它内容。

a) 数据中转归集：现有数据平台需要将部分数据数据上报给行业平台，同时还要将另一条第三方物联数据做数据归集中转后再进行上报行业平台。。
b) 国产化信创可控切换：明年技术平台指标项信创切换的前期验证工作，需要验证业务系统与数据平台一体信创国产化信创切换风险验证，将现有 MySQL → 达梦 / 人大金仓 之间做迁移。

根据二三线城市实际公司和技术水平情况、调研了数据采集/集成项目后，暂定 Apache SeaTunnel 的核心原因：

• 插件式架构，Source/Sink 支持 100+，新增国产库只需改 JDBC Driver； 考虑使用SeaTunnel 进行导入数据，同时考虑datax做为备用方案；（原则seatunnel支持自动建表，datax只支持导入无法自动建表，需要手动建表工作量较大。）
• 天然集成 DolphinScheduler，调度方便可观测性及管理运维易用性高；

笔者在整个过程中趟了不少坑，经验在四五六节中进行了总结，因此成文，给社区回流经验，也作为内部复盘的内容。

二、整体需求

1. 利用 SeaTunnel 的 jdbc source和达梦专用sink实现数据数据上报，由于上报表比较多，需要利用seatunnel的自动建表和字段映射解决过程中兼容问题；
2. 使用人大金仓数据库替换数据平台webDB和ds的调度持久化DB，同时验证seatunnel做为数据平台的数据采集模块的延伸方案(原有为doris jdbc catalog),读写kingbase数据库进行数据采集计算；

三、前置条件

四、安装测试运行

有经验的朋友可直接跳过，本节主要介绍个人遇到的一些安装注意事项。

1. 安装一个字，简单快捷。

步骤：下载、解压、安装连接器、测试。（本人暂时只试用了自带的 Zeta 引擎，其它引擎和集群未使用，目前满足离线 ETL 常规需求）

需要重点介绍一下安装连接器，如果网络不好或者maven懒得改代理、着急快速部署、验证新版本什么的，可以直接修改apache-seatunnel-2.3.8\config目录下的plugin_config文件，只保留需要的连接器；

如我只连常用数据库就保留connector-jdbc，只连DDoris数据仓库就保留connector-doris其它的删除掉或注释掉。具体所需对照可以查看\apache-seatunnel-2.3.8\connectors目录下的plugin-mapping.properties文件，里面有详细的source和sink所需要对应的连接器。

配置好了直接运行脚本就可以了，进目录cd apache-seatunnel-2.3.8/安装命令sh bin/install-plugin.sh 2.3.8，不指定版本号注安装当前版本的；安装完毕，你的connector目录就会多出许多连接器jar包。老手熟的话可以不安装（panda哥就没用过），直接从原有安装机器或本地把下载好的连接器，手动传上去也可以正常运行。

这里有个神奇的情况，在Windows环境下有时候连接器历史下载过可能重新部署后没再次下载，仍然可以运行。但在某一个特定的时间点就又开始报错说缺少jdbc连接器。神奇的系统。

2. 这里有两个概念需要理解一下

一个是连接器： 既使用什么方式进行数据连接，常见的http、文件、数据库jdbc。（一般运行时报什么jdbc错误，八成是没下载jdbc连接器。install-plugin没？）

一个是驱动包： 特定数据源的连接驱动、常见的mysql、pg等。（一般运行时连接失败，九成是没放对应的数据库驱动。）驱动包要自己<u>手动扔啊，手动，手动</u>。

3.测试demo

# 切换工作目录至Apache SeaTunnel 2.3.8的安装目录
cd /opt/apache-seatunnel-2.3.8/

# 执行SeaTunnel批处理任务
# 参数说明：
# --config：指定任务配置文件路径，此处为默认的批处理配置模板
# -m local：指定运行模式为本地模式（无需集群环境）
./bin/seatunnel.sh --config ./config/v2.batch.config.template -m local

运行时需要注意的就是windows命令行乱码，字符集换行符什么的这些问题，最一统的解决方案就是别直接windows的传linux上去混用，大不了重写或贴过去。cmd运行时控制台中文信息乱码解决是 chcp 65001 。

⚠️ 再次提醒，无论运行什么类型的etl，涉及的连接器和驱动包要保证都有，报错时第一时间核对这个，不要死盯着报错重试了。特别是在Windows环境下，Linux大法还是好。

4. 小分享

作业文件习惯单独建一个job目录存放。（与DolphinScheduler集成有时间再写吧，欠的东西太多了。）

常用conf样例，可直接cv修改，注意Doris作为sink写入时使用的是streamload方式，要用对应的http端口，不是Navicat连接的端口（大年纪程序员经常忘）:

<u>mysql 2doris样例</u>

env {
    parallelism = 2
    job.mode = "BATCH"
}
source {
    Jdbc {
        url = "jdbc:mysql://192.168.0.31:3306/cons"
        driver = "com.mysql.cj.jdbc.Driver"
        connection_check_timeout_sec = 100
        user = "root"
        password = "123456"
        table_path = "cons.community_info"
        query = "select * from cons.community_info"
    }
}
sink {
    Doris {
        fenodes = "192.168.0.110:8030"
        username = "root"
        password = "123456"
        database = "data_test"
        table = "ods_xyz_communityinfo_base"0
        sink.enable - 2pc = "true"
        sink.label - prefix = "test123"
        doris.config = {
            format = "json"
            read_json_by_line = "true"
        }
    }
}

<u>mysql 2doris 多表样例</u>（有复杂业务需要json一条数据变拆分成多行的可参考 https://github.com/apache/seatunnel/issues/7961 使用SELECT * FROM fake LATERAL VIEW OUTER EXPLODE(cpe_nodes) as cpe_nodes函数）

env {
  job.mode = "BATCH"
  parallelism = 4
}
source {
  Jdbc {
    url = "jdbc:mysql://192.168.0.31:3306/cons"
    driver = "com.mysql.cj.jdbc.Driver"
    connection_check_timeout_sec = 100
    user = "root"
    password = "qianhe999"
    "table_list"=[
        {
            "table_path"="cons.gas_alarm_events"
        },
        {
            "table_path"="cons.gas_check_dispatch"
        }
    ]
    
}
sink {
  Doris {
        fenodes = "192.168.0.110:8030"
        username = "root"
        password = "123456"
        database = "data_test"
    sink.enable - 2pc = "true"
        sink.label - prefix = "test123"
    table = "ods_xyz_${table_name}_base"
        doris.config = {
            format = "json"
            read_json_by_line = "true"
        }
    }
}

自动建表模板doris版本

save_mode_create_template = """CREATE TABLE IF NOT EXISTS ${database}.${table_name} (
${rowtype_primary_key},
${rowtype_fields},
decoded_project_description  STRING
)
ENGINE=OLAP
UNIQUE KEY (${rowtype_primary_key})
COMMENT '${comment}'
DISTRIBUTED BY HASH (${rowtype_primary_key})
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"in_memory" = "false",
"storage_format" = "V2",
"disable_auto_compaction" = "false"
)"""

<u>http接口2 Doris 样例</u>（http的主要参考了git的文章 https://github.com/apache/seatunnel/issues/8431）

env {
  execution.parallelism = 2
  job.mode = "BATCH" 
  checkpoint.interval = 10000 
  }
source {
  Http {
    url = "http://192.168.0.1120:31907/biz-data-service/241211/ABC_o1_XYZ"
    method = "POST"
    format = "json"
    headers = {Accept="application/json",Content-Type="application/json;charset=utf-8"}
    body= "{\"params\":{\"branch\":\"长安区\"},\"size\":10,\"current\":1}"
    content_field = "$.data.records.*"
   schema = {
      fields {
  mc=string 
  dz=string 
  last_update=timestamp
  jd="decimal(20, 5)" 
  id :int
  mplx=string 
  wd=string 
        }
    }
  }
}
sink {
   Doris {
        fenodes = "192.168.0.110:8030"
        username = "root"
        password = "123456"
        database = "data_test"
        table = "ods_xyz_http_base"
save_mode_create_template = """CREATE TABLE IF NOT EXISTS ${database}.${table_name} (
cid bigint NOT NULL AUTO_INCREMENT(1) COMMENT '主键',
${rowtype_fields}
) ENGINE=OLAP
UNIQUE KEY (cid)
DISTRIBUTED BY HASH (cid) BUCKETS 1 
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"in_memory" = "false",
"storage_format" = "V2",
"disable_auto_compaction" = "false"
)"""
  data_save_mode = "DROP_DATA" # 默认是追加，这里测试了一下清表。既每次只保留最新一次。
  sink.enable - 2pc = "true"
  sink.label - prefix = "test123"
  doris.config = {
            format = "json"
            read_json_by_line = "true"
        }
    }
 }

五、读Doris写达梦数据库操作步骤

首先需要确保SeaTunnel能正常运行，需要在Linux服务器库或Windows命令行上进行验证，基础的SeaTunnel本地的Zeta引擎可以正常工作运行。

如用 Windows，可能会出现SeaTunnel今天能运行，明天不能运行的特殊情况（报错内容是“找不到或无法加载主类”）；我没有彻底解决，但在网上找的方案大部分都是java环境变量设置的情况，还有就是关掉命令窗口重新打开。但偶尔有机会确实再次出现，隔天就没事了。神奇的系统！

1. 正常情况

-- 官方模板一次通
env {
  parallelism = 1
  job.mode = "BATCH"
}
source {
  Jdbc {
    url = "jdbc:dm://e2e_dmdb:5236"
    driver = "dm.jdbc.driver.DmDriver"
    connection_check_timeout_sec = 1000
    user = "SYSDBA"
    password = "SYSDBA"
    query = """select * from "SYSDBA".e2e_table_source"""
  }
}
sink {
  Jdbc {
    url = "jdbc:dm://e2e_dmdb:5236"
    driver = "dm.jdbc.driver.DmDriver"
    connection_check_timeout_sec = 1000
    user = "SYSDBA"
    password = "SYSDBA"
    query = """
INSERT INTO SYSDBA.e2e_table_sink (DM_BIT, DM_INT, DM_INTEGER, DM_PLS_INTEGER, DM_TINYINT, DM_BYTE, DM_SMALLINT, DM_BIGINT, DM_NUMERIC, DM_NUMBER,
 DM_DECIMAL, DM_DEC, DM_REAL, DM_FLOAT, DM_DOUBLE_PRECISION, DM_DOUBLE, DM_CHAR, DM_CHARACTER, DM_VARCHAR, DM_VARCHAR2, DM_TEXT, DM_LONG,
 DM_LONGVARCHAR, DM_CLOB, DM_TIMESTAMP, DM_DATETIME, DM_DATE, DM_BLOB, DM_BINARY, DM_VARBINARY, DM_LONGVARBINARY, DM_IMAGE, DM_BFILE)
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
"""
  }
}

2.我跳的坑（读Doris写达梦，流水帐形式就当小说看）

2.1.SeaTunnel使用中遇到的问题

(1) 表或视图不存在

手写query正常，动态却不行，generate_sink_sql =true不行。最终需要追加上数据库名称，而且源表是Doris表都是小写，而目标表是达梦表库表字段都是大写，所以会报表不存在。

(2) 源与目标表名大小写方式不一致

需要追加转换功能，字段大小写也需要转换。

表转换需要使用Transform，并且追加源表别名与目标表表别名，方便操作。

transform {
 TableRename {
  plugin_input = "source_doris"
  plugin_output = "desc_dameng"
  convert_case = "UPPER"
  }
}

字段转换

sink {
 Jdbc {
  plugin_input = "desc_dameng"
  url = "jdbc:dm://dmhost:2070?schema=X_Y_Z_KFC"
  driver = "dm.jdbc.driver.DmDriver"
  user = "X_Y_Z_USE"
  password = "123456"
  database = "DAMENGKFC"
  table = "X_Y_Z_KFC.${table_name}"
  generate_sink_sql = true
  field_ide="UPPERCASE"
  schema_save_mode = "CREATE_SCHEMA_WHEN_NOT_EXIST"
  data_save_mode="DROP_DATA"
   dialect ="Dameng"   --好像没啥实际意义（说是会根据jdbc连接串推算）
}
}

(3) 无法创建表

低版本不支持达梦建表(2.3.8就没有达梦的ddl创建表的方法，达梦数据库sink写入时ddl自动建表方法是在2.10后才追加的)，最终升级到2.3.10并下载对应的connector连接包还是不行。

版本升级最新与更新最新的连接包（中间下载时间太长，使用了从maven上直接手动下载的包，最后对了一下大小都一样。没有问题。。。）又升级到了2.3.12版本也是无法自动建表。

Dialect方言显示指定也不行（包括相应的lib包也都加上了。。。还是不行，甚至怀疑过达梦的驱动包有问题，是否需要找商厂要个驱动才能用）。

最终验证与字段注释有关，表注释直接就扔了根本不建。只要表中有字段就报commont 语法解析问题。

2.2. 两头走不通的折中方案

(1) 使用达梦迁移工具

在测试环境没有问题，在生产环境Doris版本升级了竟然报读取错误了。。。(测试环境是Doris 2.1.3，生产是2.1.9版本，估计是哪有差异。)

(2) 手动建表

参考MySQL导入达梦，使用Linux的脚本处理dump的SQL脚本 。

把字段和表注释去除，使用AI处理了一上午，只能把表字段注释去掉。但是无法把字段注释和表注释单独弄到一个脚本中，只能生成一个所谓的纯净建表语句。

但突然发现导出的数据类型肯定在达梦中无法执行，需要转换。对应到各种不同的类型，这个对应再用手工做一遍，考虑放弃此方案。

(3) 灵感闪现-直接删除表的注释

通过schema_info直接用sql拼出一堆清注释的语句。

还有个小波折，差点这个方案也不能用了。就是Doris的默认值，开始转换时使用的SQL

ALTER TABLE dwd_X_Y_base MODIFY COLUMN filedA1 varchar(255) COMMENT "";指定了字段类型，当有字段last_update有默认值时不允许修改。后来仔细查了查官网文档，Doris还是做了人的，有专门单独去注释的语句，不加字段类型就行了。

2.3 最终可行方案-半手工方案

利用现有的备份库，或者直接重新做个临时备份；思路就是通过备份库去把表建上，再切到正式库去做真实的数据同步。

(1) 在备份库上把所有注释去了

a. 选择表范围。（只取Xyz的底层数据表，用于分业务去做同步SeaTunnel拼哪些表做同步）

SELECT   *  FROM   information_schema.TABLES 
WHERE   TABLE_SCHEMA = 'data_test_backup' 
AND ( TABLE_NAME like  'ods_xyz_%'  or TABLE_NAME like  'dwd_xyz%')  ;

b. 选择去除字段注释的内容。

SELECT 
  CONCAT('ALTER TABLE ', TABLE_SCHEMA,'.',TABLE_NAME, '  MODIFY COLUMN  ', COLUMN_NAME, '  ',  ' COMMENT "";') AS alter_sql
FROM 
  information_schema.columns 
WHERE 
  TABLE_SCHEMA = 'data_test_backup' 
  AND (table_name LIKE 'ods_xyz_%' OR TABLE_NAME LIKE 'dwd_xyz%')
  AND LENGTH(COLUMN_COMMENT) > 0;

c. 复制出清除字段脚本，在备份库上直接执行。

alter table ods_xyz_1001_base modify column filed1 comment "";
alter table ods_xyz_1001_base modify column filed2 comment "";
.....

ctrl+A 、 ctrl +R 全选运行。

(2) 使用备份库把数据第一次自动建表导进去。

新建xyz_low1.conf读取备份库建表初始化到达梦，未把多表改成正则去匹配，是方便调试找错。直接把表名扔给AI生成table_path数组，也方便以后做真增量时，直接在sql中追加限制条件。

env {
  parallelism = 2
  job.mode = "BATCH"
}
source {
 Jdbc {
  plugin_output = "source_doris"
  url = "jdbc:mysql://backuphost:9030/data_test_backup"
  driver = "com.mysql.cj.jdbc.Driver"
  connection_check_timeout_sec = 100
  user = "XXX"
  password = "******"
  table_list = [
 {
  table_path = "data_test_backup.dwd_xyz_1001_base"
  query = "select * from data_test_backup.dwd_xyz_1001_base"
 },
 {
  table_path = "data_test_backup.dwd_xyz_1002_base"
  query = "select * from data_test_backup.dwd_xyz_1002_base"
 },
 .....
]
}
}
transform {
 TableRename {
  plugin_input = "source_doris"
  plugin_output = "desc_dameng"
  convert_case = "UPPER"
  }
}
sink {
 Jdbc {
  plugin_input = "desc_dameng"
  url = "jdbc:dm://101.2.3.4:2026?schema=X_Y_Z_KFC"
  driver = "dm.jdbc.driver.DmDriver"
  user = "X_Y_Z_USE"
  password = "123456"
  database = "DAMENGKFC"
  table = "X_Y_Z_KFC.${table_name}"
  generate_sink_sql = true
  field_ide="UPPERCASE"
  schema_save_mode = "CREATE_SCHEMA_WHEN_NOT_EXIST"
  data_save_mode="DROP_DATA"
  dialect ="Dameng"
}
}

(3) 切回同步从库直接读取最新数据

复制备份库的配置文件，修改数据库ip地址端口密码等信息，就可直接运行了。

(4) 同时拼出来在达梦里需要追加的语句

追加表注释。

SELECT   CONCAT('COMMENT ON TABLE ', upper(TABLE_NAME), ' IS ''', TABLE_COMMENT, ''';')  
FROM   information_schema.TABLES 
WHERE   TABLE_SCHEMA = 'data_test' 
AND (table_name LIKE 'ods_xyz_%' OR TABLE_NAME LIKE 'dwd_xyz_%')

在达梦数据库上执行！把自动建表的表注释补出来。

有条件追加字段注释(当时任务急，未来可期你懂的)。

(5) 加工层导入时的遇到的新问题(ads层字段创建不规范导致)

个别语句有问题的需要调整修改一下，记得重新把先表删除了，再改配置文件中的内容。

{
  table_path = "data_test_backup.ads_xyz_1001_agg"
  query = "select label_type,`sum(total)` as  'totalnum',sord_num from   data_test_backup.ads_xyz_1001_agg"
 },

2.4 配个定时就OK

Windows、Linux直接脚本定时，或者集成ds进行配置可视化任务。

Windows下的bat脚本

@echo off
rem 先切到 SeaTunnel 的 bin 目录
cd /d "E:\apache-seatunnel-2.3.12-bin\apache-seatunnel-2.3.12\bin"
rem 执行作业
seatunnel.cmd --config ./job/xyz_low.conf -m local

3. 写达梦数据库的总结

通过学习达梦数据库，笔者发现它本身就是Oracle的魔改版本，有点像把PG和Oracle捏在了一起，加了个PG的Schema，语法全是Oracle的。笔者主要利用了SeaTunnel的自动建表功能，特别是字段类型映射转换节省了大量时间，但研究的时间也不短。

同时，笔者也发现了一些问题，比如表注释会丢弃，这些还好，反正就是一次性的事手动补一下，直接用sql生成一下脚本即可。

在报错调试方面，似乎由于线程的问题，会把同线程的其它表的无错的内容报成异常打印出来。

还有就是关于表结构的问题，要注意调试过程中手动删除表，因为默认使用的参数是schema_save_mode = "CREATE_SCHEMA_WHEN_NOT_EXIST"，如果表已经存在不会再创建表，容易造成建的表有问题，而发生奇怪的异常报错。

4. 另一时间线

后续平台又需要与第三方物联系统做数据对接，就直接利用了Doris stream load技术来实现，分享一下经验：最终需要将http接口外网暴露的地址是Doris的be端口，而非fe端口。

中间还验证了一个拉的方式，就是利用SeaTunnel的http连接器，去拉数据。这里有个小问题，就是需要做鉴权，有时间会再做个分享。（方法很low但验证可行。）

六、读写人大金仓数据库操作步骤(信创)

信创就是我人生的至暗时刻，刚经历了达梦又得弄Kingbase，但最终对自己个人成长还是有助力的，不说信创数据库怎么兼容的各种问题吧，在时下这个环境换个角度看，这可能就是一种“技术壁垒”。也没时间写内部技术文档了，直接从头回忆吧。

1. 坑Kingbase初理解

先说开放性kingbase至少比达梦强，官网给下载安装程序包，包括安装版和docker版本，还可以免费申请测试的授权证书，开发授权最多有1年的试用期。这一点就敞亮、局气。首先和身边的前同事（现在还是好朋友）打听了一下，他们之前试用过，大概就是Kingbase是个套壳，底层是pg，改了改几个函数，论开放性有个叫瀚高的更开放，基本没有魔改的，本着原生的一致进行了二开。

然后运维大哥三下五除二就把docker拉起来，高高兴兴选择了下MySQL模式，结果MySQL的驱动不能直接连，必须要用Kingbase的原生，中间省略各种问题，最终又装了一个pg模式的。

概念就一个：Kingbase有多种兼容模式，mysql/pg/sqlserver什么的。。。理论上不考虑这个兼容模式用Kingbase原生的驱动肯定都能连接。如果知道具体的兼容模式，可以尝试用兼容的驱动连接。如pg模式直接用pg驱动就可以连接，但MySQL模式Navicat就不能用MySQL的驱动连接。

KSQL是Kingbase自己的连接工具，有必要也安装一个，它的驱动就是用的Kingbase原生的驱动。

2. 预期设想

听劝MySQL兼容模式不好用，咱就用底层原生的最稳定了，当年kmx直接用的Cassandra读的妥妥的好。那就准备用Kingbase的pg兼容模式做为源和目标了。

在SeanTunnel官方文档上查了一下，支持Kingbase，但是，但是，但是，只有部分类型兼容！又在技术群里圈了一下panda大佬交流了Kingbase的读写情况，收获良多，再次感谢！！！感谢！！！感谢！！！

jdbc:kingbase8的不归路就开始了....（这里source和sink的库都是Kingbase的pg模式）

env {
  parallelism = 2
  job.mode = "BATCH"
}
source {
  Jdbc {
    driver = "com.kingbase8.Driver"
    url = "jdbc:kingbase8://192.168.0.31:4322/sourcedb"
    user = "kingbase"
    password = "123456"
   query = "select *  from source_user_detail"
   }
}
sink {
    jdbc {
        url = "jdbc:kingbase8://192.168.0.119:4322/targerdb"
        driver = "com.kingbase8.Driver"
        user = "kingbase"
        password = "123456"
        generate_sink_sql = true
       database = targerdb
       table = public.target_user_detail
       #schema_save_mode = "CREATE_SCHEMA_WHEN_NOT_EXIST"
        data_save_mode="APPEND_DATA"
      }
}

一切顺利，不到“10”分钟就搞定了；当时测试的小遗憾是不能schema_save_mode自动建表。在交流群里吐槽了一下，也感谢迅哥儿和西门分享经验和想法！！

后来panda大佬要给Kingbase立flag说可以支持，我是测试了不行；panda佬说Kingbase是继承pg的代码都支持，还提醒嘱咐source不能用query，无法自动建表，要用tabl_path是个坑，让我记到文章里提醒大家，“造福更多使用者”。最终panda佬可能查了查源码确认了打脸，“Kingbase在建表那块没适配”，但这不是重点。

重点是：“用pg连接器是可以地，如果你Kingbase本身是pg兼容模式 那可以用pg的，只要元数据检查能通过。那就换成pg驱动和配置试试”，结论就是“把kingbase的pg模式就当成jdbc的pg用”，而且可以自动建表等参数都能用了。“pg支持啥它支持啥”。

source {
  Jdbc {
    driver = "org.postgresql.Driver"
    url = "jdbc:postgresql://192.168.0.31:4322/sourcedb"
    user = "kingbase"
    password = "123456"
    table_path = "sourcedb.public.source_user_detail"
 }
}
sink {
    jdbc {
        url = "jdbc:postgresql://192.168.0.119:4322/targerdb"
        driver = "org.postgresql.Driver"
        user = "kingbase"
        password = "123456"
        generate_sink_sql = true
        database = targerdb
        table = public.target_user_detail
        schema_save_mode = "CREATE_SCHEMA_WHEN_NOT_EXIST"
        data_save_mode="APPEND_DATA"
     }
}

满心欢喜的下班，一切都太顺利了。。。

3. 突变大转折

业务也要做信创准备，那帮子老古董就咬死了我这祖传代码就是MySQL，信创我也是用金仓的MySQL兼容模式！！！！！我还提前分享了验证结论，告诉他们推荐用pg模式，可是人家业务就是这么横，让我们换pg，我这完全不接受，我找领导去！！！！！可想而知的结果，弄不了就是你们技术不行。我这血压一下子就上去了，@#￥%……&%……&……&（&￥%&……（（）￥%&……（）￥#￥%

4. 背叛

这Kingbase的兼容MySQL模式肯定是类型有问题啊，这可怎么办？赶紧找其它办法吧。网上找了有什么Datamover，DataX( 老家伙)，还有一直关注没用过的Tis赶紧弄过来试吧，时间紧任务重，Tis有docker版本，赶紧拉起来。试了一下还真行，点点点就弄好一张表！！！表也建上了数据也导过去了，挺好。

顺利吗....没过一会，说表的字段都是大写的，Kingbase默认是区分大小写的和pg一样。但是可以通过数据库初始化时指定，Docker下面指定那个参数是起不来的，运维大哥说只能填pg，填不了其它的。又是个两头堵死的情况，像不像达梦？。。。

简单看了看Tis底层用的DataX，建表语句可以自己修改字段名变小写，但是DataX的脚本不让改，直接拷出来在DataX上执行有问题，看不懂的错误。没时间了研究了。。。

5. 赌一把

晕晕忽忽一下午，压力大吃碳水多，感觉到压力与生活的影响了，就要自己调节。工作只是工作，还有生活。重新调整饮食，早上有时间还把家里的毛巾洗了洗，心情拉满去上班。

来吧，再试一把老朋友SeaTunnel！还是老三样，connector重下，驱动重放，执行文件编码问题。一关一关过呗，MySQL兼容类型有问题，我先跳过那个字段直接写死几个列，先跑一把给给自己信心。

注意环境有改变：192.168.0.31:4321 的Kingbase是MySQL兼容模式，192.168.0.119:4322是Kingbase的pg兼容模式。

所以source要用Kingbase的原生去读，字段转小写的问题，通过SQL先尝试解决，大力出奇迹，这些个牛马的事扔给AI弄；sink保留原来的pg也没事。

env {
  parallelism = 2
  job.mode = "BATCH"
}
source {
  Jdbc {
    driver = "com.kingbase8.Driver"
    url = "jdbc:kingbase8://192.168.0.31:4321/kingbase"
    user = "kingbase"
    password = "123456"
  query = "SELECT `ID` AS id,`PARENT_ID` AS parent_id,`DICT_LABEL` AS dict_label,`DICT_VALUE` AS dict_value,...REMARK` AS remark FROM public.dict;"
  }
}
sink {
    jdbc {
      url = "jdbc:postgresql://192.168.0.119:4322/datatest"
        driver = "org.postgresql.Driver"
        user = "kingbase"
        password = "123456"
        generate_sink_sql = true
        database = datatest
        table = data_test.dim_busi_dict_001
        schema_save_mode = "CREATE_SCHEMA_WHEN_NOT_EXIST"
        data_save_mode="APPEND_DATA"
     }
}

经过9*9=81次调试，一把过了。高高兴兴找运维大哥说成了成了，运维大哥问了一句“int型的怎么解决的”？我#$%&&,我绕过去了。。。。晕了忘了个干净。

信心有了，可现实就是这么冰冷，int类型转换失败....AI说指定source的表结构类型，不管用....sql转换类型也没试成功.....不行，服软，花点钱买Kingbase的产品吧。最多也就这样了。

Panda佬的那句"用pg连接器是可以地"，我又再次仔细理解了一下。是不是有什么没理解到？我用pg驱动读个Kingbase的MySQL兼容模式，再赌一把？

env {
  parallelism = 2
  job.mode = "BATCH"
}
source {
  Jdbc {
    driver = "org.postgresql.Driver"
    url = "jdbc:postgresql://192.168.0.62:4321/kingbase"
    user = "kingbase"
    password = "123456"
   query = "SELECT * FROM public.dict;"
  }
}
sink {
    jdbc {
      url = "jdbc:postgresql://192.168.0.119:4322/datatest"
        driver = "org.postgresql.Driver"
        user = "kingbase"
        password = "123456"
        generate_sink_sql = true
        database = datatest
        table = data_test.dim_busi_dict_001
        field_ide="LOWERCASE"
        schema_save_mode = "CREATE_SCHEMA_WHEN_NOT_EXIST"
        data_save_mode="APPEND_DATA"
    }
}

最后结局了肯定是过了，再tm不过这文章就没必要写这块了。后来拿Navicat直接连了一下Kingbase的MySQL兼容模式，也能连上。#￥%，原来是自己绕远了。

赶紧分享给群里的小伙伴，又和panda佬谈了体会，“那挺好啊”，原来世界真的很大，我们只在自己的井里。有些事只是自己没见过，但并不代表这个世界上没有。

​ 2026.1.21 三线程序员

需求变更不可避免，真正拖垮交付的是“变更失控”。IPD 需求管理的核心，是把需求从“口头共识”升级为“受控资产”：用需求分层与追溯建立共同语言，用需求基线固化交付承诺，再用 CCB 把变更变成可决策的投资选择。本文给出一套可落地的全流程、角色机制与指标闭环，帮助组织稳节奏、降返工、提质量。

本文关键词：IPD 需求管理、需求管理、需求变更、需求变更管理、需求基线（Requirements Baseline）、CCB（变更控制委员会）、变更控制（Change Control）、配置管理（Configuration Management）、影响分析、需求追溯矩阵（RTM）

为什么“需求没管住”，IPD节奏就一定会崩

很多团队以为项目失控是“需求太多”。我更常见到的现实是：需求并不一定多，但“承诺”太轻——轻到可以被一句“这个很急”随时改写。

在研发现场，需求失控往往呈现为三个连锁反应（也是多数团队在搜索“需求变更怎么管”时真正想解决的问题）：

• 没有基线：团队不知道“当前承诺交付的到底是哪一版”。需求列表在变，验收口径也在变，最后只能靠人记忆与拉扯。
• 没有统一决策机制：变更由“声音最大的人”决定，项目经理被迫在多个老板之间做“情绪路由”，而不是做项目控制。
• 没有影响评估：变更只讨论“要不要做”，很少讨论“会伤到哪里、要付出什么代价、是否有替代方案”。

这三件事叠加时，IPD 强调的“跨职能并行”会从优势变成放大器：市场、产品、研发、测试、供应链同时在动，但缺少共同的“受控参照物”，于是每个环节都在用自己的版本理解需求。

从产品研发的经验看，越晚发现需求错误，返工常常越贵。

NASA 的研究给出过一个非常直观的量化视角：把“在需求阶段发现并修正一个需求错误”的成本定义为 1，若到设计阶段再发现，成本上升到 3–8；到制造/构建阶段 7–16；到集成测试 21–78；到运维阶段甚至可能达到 29 到 1500+。这类数据对硬软结合、集成验证成本高的行业尤其有解释力：系统越复杂，后期返工越容易引发链式成本。

但作为管理者，我们也要保持理性：并非所有软件项目都能稳定观测到“延迟一定更贵”的效应。成熟的做法不是迷信曲线，而是把重点放在：缩短反馈回路 + 建立变更治理机制上。

IPD 需求管理的骨架：把需求纳入配置管理

要把“需求变更”管得既稳又快，底层一定要借用系统工程成熟的方法：配置管理（Configuration Management, CM）。

• 配置管理：把关键产物（需求、设计、接口、测试等）当作“配置项”，通过基线与变更控制保持一致性。
• 需求基线（Requirements Baseline）：在某一时点对“已达成一致的需求承诺”做冻结，作为后续变更评审的参照。
• 变更控制（Change Control）：对基线后的任何修改，按流程提出、评估、批准/否决、实施与验证。

NASA 对“基线”的定义是在某一时点对配置项属性的“达成一致的描述”，并提供一个已知配置来处理后续变更；当前批准的基线会成为后续变更的依据。翻译成研发语言就是一句话：

只要你对交付结果负责，需求就必须从“讨论对象”变成“受控资产”。

我建议用“四件套”搭起 IPD 需求管理的骨架，并给出每件套的“最小可用标准（MVS）”，避免一上来就走向重流程。

1）需求分层：把“想要什么”变成“必须满足什么”

需求不分层，CCB 就会陷入“你说的需求不是我理解的需求”。至少要有三层共同语言：

• 干系人/市场需求（Why）：目标人群、场景、价值假设、成功指标
• 系统/产品需求（What）：功能、性能、接口、合规/安全、约束条件
• 版本交付需求（How far / When）：本次版本范围、验收口径、不可延期项
• 最小可用标准（MVS）：一条进入版本承诺的需求，必须同时具备“范围描述 + 验收口径 + 关键约束”。否则它不是需求，是愿望。

在实践里，建议把“需求分层 + 统一ID + 状态定义”直接固化到系统中——例如在 ONES Project 里建立需求池、编写需求并自定义需求状态与属性，再把需求与任务规划进迭代，减少口头协商带来的歧义。

典型失败模式（反例）：只冻结“要做什么”，但不冻结“验收怎么算完成”，你会得到一个现象：研发认为交付了，测试认为没通过，业务认为没达到预期——每个人都没错，但项目照样延期。

2）追溯链：没有追溯，就没有“像样的影响分析”

追溯不是为了“好看”，是为了让你在 CCB 上用证据说话：这条变更会影响哪些设计、接口、测试与交付承诺？

做追溯建议从“最短闭环”开始：需求ID → 设计/接口项 → 测试用例 → 验收结果。这条链跑通，影响分析就有了骨架；以后再逐步扩展到风险、合规、供应链与文档基线。

现场判断标准：

如果一条变更在 10 分钟内讲不清影响范围，不是“CCB没效率”，而是“追溯链不足以支撑决策”。

追溯链最容易“断”在测试与交付环节。像 ONES TestCase 支持测试用例与需求、任务关联、测试计划与迭代关联，能把“需求—任务—测试—缺陷”这条链更稳地串起来。

3）需求基线：冻结的不是文档，是“交付承诺”

很多组织把基线做成“需求列表冻结”，但真正该冻结的是交付承诺：范围、验收口径、关键约束、里程碑假设。因为基线本质是“对某一时点状态的达成一致描述”，并作为后续变更的处理依据。

你可以把“需求基线包（Baseline Package）”理解成：

一次版本对业务、对组织、对客户的正式承诺。

基线包不是只存在于PPT。在版本/迭代层面把承诺落到系统里，后续才好做偏差对比。比如 ONES Project 在实践案例里强调了产品版本与迭代规划；并且在甘特图场景下提供“基线对比”的思路，用来直观看当前与计划偏差。

4）CCB 变更控制：把变更从“情绪”变成“投资决策”

成熟组织不会纠缠“要不要做变更”，而是讨论三个更硬的问题：

• 批准的收益与代价是什么？
• 不批准的后果是什么？（很多时候这才是关键）
• 有没有折中方案：延期、降级、分阶段、替代实现？

全流程落地：从需求基线到 CCB 变更控制

下面给出一套端到端流程。建议 PMO 或系统工程牵头固化为 SOP，并在两到三个版本内跑出稳定节奏。

摘要版
需求入口 → 需求分解与追溯 → 建立需求基线 → 变更申请（CR）→ 影响分析 → CCB 决策 → 执行验证 → 更新基线与追溯 → 关闭变更单

1. 需求入口：先把“入口”管住，后端才不会靠吵架控风险

目标：统一入口、统一信息质量，把“讨论成本”前移。

建议设“入库门槛”（最少字段）：

• 来源与目标用户/场景
• 价值假设（可量化更好：收入、成本、风险暴露、合规罚则）
• 验收口径（DoD：什么算交付完成）
• 关键约束（法规、接口、性能、交付窗口）
• 初步优先级与紧急性（规则要写清楚）

常见误区：入口不清晰时，变更会伪装成“补充说明”“临时插单”，绕开治理机制。最后你会发现：CCB不是“变更太多开不过来”，而是“该进CCB的变更从来没进来”。
入口治理的关键是“字段齐全 + 状态可控”。例如在 ONES Project 中，你可以把变更申请作为一种工作项/表单来收敛入口信息，同时利用其“需求池 + 自定义需求状态/属性”的机制，减少信息缺失导致的反复打回。

2. 需求分解与追溯：先把“结构化依据”建起来

目标：让影响分析可计算、可复核、可追责。

落地要点：

• 每条需求唯一 ID，避免“同名不同义”
• 需求拆分以“可验证、可交付”为原则：大需求拆到能被测试与验收
• 建立最小追溯链：需求 → 设计/接口 → 测试 → 验收
• 对关键需求标注：合规/安全点、关键性能指标、供应链影响

补一句经验：追溯不是一次性工作，它是“把承诺变成资产”的成本。你付出维护成本，换来的是后期影响分析的确定性与决策效率。另外，追溯链维护最怕“各写各的”。像 ONES TestCase 明确支持用例与需求、任务关联，并把测试计划与迭代关联，能把追溯从“Excel表”推进到“过程资产”。

3. 建立需求基线：用“基线包”把承诺讲清楚

目标：明确“我们承诺交付什么”，并建立后续变更的参照物。

基线包建议包含（这份清单本身就是很强的检索与引用片段）：

• 基线需求清单（范围、优先级、验收口径、依赖）
• 关键接口与约束清单
• 里程碑与交付节奏（把范围与计划绑定）
• 风险清单与缓冲策略（范围缓冲/资源缓冲/技术预研）

NASA 强调：基线提供一个已知配置来处理后续变更，当前批准的基线是后续变更的依据。管理动作落地：从这一刻起，任何改动都必须留下“为什么改、谁批准、改了什么、影响如何、如何验证”。

基线包建议同时“文档化 + 结构化”。文档化用于解释口径与边界，结构化用于后续对比与追踪。比如 ONES Project 与 ONES Wiki 支持“文档关联任务/工作项”，适合把基线包的关键结论与对应需求、迭代绑定起来，减少“决策在群里、执行在系统里、复盘找不到证据”的割裂。

4. 变更申请：把“口头插单”变成“可评审的请求”

目标：让变更带着信息来，而不是带着情绪来。

变更单（CR/SCR）最低要素建议包含：

• 变更内容（新增/删除/修改）与动因
• 关联需求 ID 与基线版本号
• 紧急性与业务窗口（是否不可错过）
• 初步影响：范围/进度/成本/质量/风险
• 备选方案：延期/降级/分阶段/替代实现
• 不批准的后果：风险、合规、客户承诺、商业损失

这一步的本质，是把“我想要”变成“我愿意为代价买单的选择”。变更单最有价值的不是“提交”，而是“字段强约束”。在 ONES Project 中，通过自定义需求状态与属性，可以把“影响分析一页纸”所需的关键字段前置到变更申请阶段，减少 CCB 会议上临时补材料。

5. 影响分析：CCB 能不能开好，取决于这一页纸

目标：把“要不要做”变成“值不值得做、怎么做更划算”。

建议用“一页纸影响分析”，强制输出：

• 范围影响：涉及哪些需求 ID、交付物、接口
• 进度影响：关键路径是否改变，里程碑推迟多少
• 成本/资源影响：人天、外采、测试资源、供应链
• 质量影响：回归测试范围、缺陷风险、技术债
• 风险与安全：合规、安全、可靠性是否受影响
• 不批准的后果：推迟/拒绝会带来什么损失或风险

一句话点破：影响分析不是“把风险写出来就安全了”，而是帮助组织做取舍：这次我们愿意买哪一种代价。

影响分析要快、要准，离不开“需求—任务—测试—缺陷”的数据贯通。ONES Project 提到与 TestCase 数据互通、并支持一键提 Bug，这类能力能让你在评估质量与回归范围时不至于全靠经验猜。

6. CCB决策：用机制替代“拍脑袋”，用章程替代“临时拉群”

目标：让组织用同一套规则做取舍，并且决策可复盘。

建议把 CCB 做成“有章程的治理机制”，至少明确：

• 成员构成与表决权：业务、研发、测试、架构/系统工程、质量/合规
• 授权阈值：哪些变更项目级 CCB 可决，哪些必须上升到更高层级
• 节奏与通道：常规变更走周例会；紧急变更走快速通道但必须补齐记录；小变更按阈值授权给项目经理/产品负责人

一次高效 CCB 建议做到“三定”：

• 定级：紧急 / 常规 / 优化（不同通道、不同 SLA）
• 定策：批准、否决、退回补充、进入研究队列
• 定责：谁执行、谁验证、谁更新基线、何时关闭
• CCB 开不动的三种典型原因（增强“经验信号”）
• 材料不全：变更没有“一页纸影响分析”；
• 参照物缺失：没有明确的需求基线版本；
• 授权不清：谁能拍板不清晰，会议只能“讨论”，无法“决定”。

CCB 会议的“决定”一定要变成“可复盘的组织记忆”。ONES Project 明确提到与 ONES Wiki 的协同：文档可以关联任务/工作项。你可以把“CCB 决策纪要、否决原因、替代方案”沉淀在 Wiki，并回链到对应变更单，下一次再出现类似变更，组织就不会重复交学费。

7. 执行与闭环

目标：防止“会上通过了，现场没变；或者现场变了，组织失忆”。

落地动作建议固定成三步闭环：

1）实施与验证：研发实现、自测、测试回归、验收确认；
2）更新配置项：更新需求基线版本号、更新追溯链（RTM）；
3）关闭变更单：记录决策理由与验证证据，沉淀可复盘信息。

常见问题 FAQ：

Q1：需求基线到底“冻结什么”？
冻结的是“交付承诺”：范围 + 验收口径 + 关键约束 + 里程碑假设，而不只是需求列表。基线要能成为后续变更评审的参照。

Q2：CCB 一定要很大、很正式吗？
不一定。关键不是规模，而是“章程 + 授权阈值 + 可复盘记录”。小团队也可以做“小型 CCB”，用阈值把小变更下放，把大变更拉上来。

Q3：影响分析写不出来怎么办？
优先补追溯链：没有需求 ID、接口项、测试用例的对应关系，就很难评估影响。先从“最短闭环追溯”做起，逐步完善；工具层面也建议把“需求—任务—测试用例”的关联关系固化起来。

Q4：紧急变更怎么处理才不破坏治理？
给紧急变更单独通道：先快速决策、快速止损，但必须补齐“事后记录 + 基线更新 + 验证证据”，否则紧急会变成常态。

成熟的 IPD需求管理 不是“把流程写得更细”，而是把组织能力做得更强：

• 用分层与追溯，让影响分析有据可依；
• 用需求基线把交付承诺冻结成“受控资产”（基线是后续变更处理的依据）。
• 用 CCB 把变更变成可决策的投资，并通过“实施验证—基线更新—记录闭环”形成组织记忆与复用能力。

最后再强调一句：变更永远会来。真正的差距不在于谁能“减少变更”，而在于谁能把变更变成组织的可控能力——这才是 IPD 体系建设最硬的底座。

HarmonyOS 中 User Authentication Kit 开发实战与应用

引言

在当今数字化时代，应用安全至关重要，而用户身份认证是保障应用安全的第一道防线。HarmonyOS 的 User Authentication Kit 为开发者提供了全面且强大的用户认证解决方案，助力开发者轻松构建安全可靠的认证系统。本文将结合实际案例，深入探讨 User Authentication Kit 在不同场景下的开发应用。

User Authentication Kit 核心特性

• 多认证方式支持：涵盖锁屏口令、人脸、指纹等多种认证方式，同时支持组合认证，如人脸与锁屏口令相结合，满足不同安全等级的需求。
• 归一化认证接口：通过统一的接口，开发者可以便捷地调用不同的认证方式，无需为每种认证方式编写复杂的差异化代码，大大简化了开发流程。
• 感知认证可信等级：开发者能够根据应用场景的风险程度，指定期望的认证可信等级，确保高风险操作得到足够强度的认证保护，例如在涉及资金交易的场景中要求更高的认证可信等级。
• 认证结果复用：允许在短时间内（最长 5 分钟）复用其他应用的认证结果，避免用户在多个应用间频繁重复认证，显著提升用户体验。

案例场景：“学海在线教育平台”认证系统开发

“学海在线教育平台”服务于广大学生群体，包括小学生、初中生和高中生，同时涉及家长与教师用户。由于不同用户群体的使用场景和安全需求各异，因此需要构建一个多层次、全方位的用户认证系统。

需求设计

1. 学生日常登录

   • 场景描述：学生日常登录平台进行课程学习、作业练习等操作。考虑到学生使用设备的便捷性和效率，需要一种快速且便捷的认证方式。
   • 需求分析：对于低年级学生，可能对复杂密码记忆存在困难，而人脸识别具有直观、快速的特点，适合作为主要认证方式。同时，为防止他人冒用学生身份，还需结合一定的安全机制。
   • 设计方案：采用人脸识别作为主要登录方式。在人脸识别过程中，加入活体检测功能，要求学生按照提示做出简单动作，如眨眼、摇头等，确保是本人操作。对于首次登录的学生，引导其进行人脸录入，并设置备用的锁屏口令，以防人脸识别出现异常情况时可通过口令登录。

2. 在线考试场景

   • 场景描述：在线考试要求严格保证考生身份的真实性，防止作弊行为，确保考试公平公正。
   • 需求分析：单一的认证方式难以满足考试场景的高安全性需求，需要采用多种认证方式相结合，增加作弊难度。
   • 设计方案：采用人脸 + 指纹双重验证方式。在考试开始前，考生需先进行人脸识别，验证身份后，再通过指纹认证进一步确认身份。同时，在考试过程中，利用设备的摄像头和麦克风进行实时监控，若检测到异常行为，如画面中出现多人、声音异常等，及时发出预警并记录相关信息。

3. 家长敏感操作认证

   • 场景描述：家长在平台上进行如缴费、修改学生重要信息等敏感操作时，需要高度的安全性，以保护账户资金和学生信息的安全。
   • 需求分析：此类操作涉及较高风险，需要采用更为严格的认证方式，确保操作是由家长本人发起。
   • 设计方案：除了常规的人脸识别或指纹认证外，增加短信验证码验证环节。当家长发起敏感操作时，系统向家长预留的手机号码发送验证码，家长需在规定时间内输入正确的验证码，方可完成操作。此外，对于家长账户登录，可设置登录设备管理功能，家长可查看最近登录设备信息，并对异常设备登录进行冻结或修改密码等操作。

4. 教师管理操作认证

   • 场景描述：教师在平台上进行成绩录入、班级管理等操作时，同样需要确保操作的安全性和教师身份的真实性。
   • 需求分析：教师操作涉及众多学生的学习数据，需保证数据的准确性和安全性，防止数据泄露或被篡改。
   • 设计方案：采用指纹认证结合数字证书的方式。教师在首次登录平台时，需下载并安装个人数字证书到设备中。之后每次进行管理操作时，先通过指纹认证确认身份，再使用数字证书对操作进行签名，确保操作的不可抵赖性和数据的完整性。

关键代码实现

1. 检查设备支持的认证类型：

   import { userAuth } from '@ohos.userIAM.userAuth';
   let auth = new userAuth.UserAuth();
   let authTypes = auth.getAvailableAuthType(userAuth.AuthLevel.STRONG);
   console.log(`支持认证类型: ${authTypes}`);

2. 学生人脸识别登录：

   async function studentFaceLogin(): Promise<boolean> {
    let challenge = generateRandomChallenge();
    let authParams = {
        challenge: challenge,
        authType: userAuth.AuthType.FACE,
        authTrustLevel: userAuth.AuthTrustLevel.ATL3,
        extraInfo: { requireLiveness: true }
    };
    try {
        let result = await auth.auth(authParams);
        return result.result === userAuth.AuthResult.SUCCESS;
    } catch (err) {
        console.error(`认证失败: ${err.code}, ${err.message}`);
        return false;
    }
   }

3. 在线考试双重认证：

   async function examAuth(): Promise<boolean> {
    let authParams = ([{ authType: userAuth.AuthType.FACE, authTrustLevel: userAuth.AuthTrustLevel.ATL4 }, { authType: userAuth.AuthType.FINGERPRINT, authTrustLevel: userAuth.AuthTrustLevel.ATL3 }]);
    let controller = new userAuth.AuthController();
    return controller.execute(authParams)
      .then(result => {
            return result.allSucceeded;
        });
   }

4. 家长敏感操作认证（包含短信验证码验证）：

   async function parentSensitiveOperationAuth(): Promise<boolean> {
    let faceResult = await faceAuth();
    if (!faceResult) {
        return false;
    }
    let smsCode = await sendAndGetSmsCode();
    let verifyResult = await verifySmsCode(smsCode);
    return verifyResult;
   }
   async function faceAuth(): Promise<boolean> {
    let challenge = generateRandomChallenge();
    let authParams = {
        challenge: challenge,
        authType: userAuth.AuthType.FACE,
        authTrustLevel: userAuth.AuthTrustLevel.ATL4
    };
    try {
        let result = await auth.auth(authParams);
        return result.result === userAuth.AuthResult.SUCCESS;
    } catch (err) {
        console.error(`人脸认证失败: ${err.code}, ${err.message}`);
        return false;
    }
   }
   async function sendAndGetSmsCode(): Promise<string> {
    // 调用短信发送接口并等待用户输入验证码
    // 此处省略实际短信发送和获取用户输入的逻辑
    return "123456";
   }
   async function verifySmsCode(code: string): Promise<boolean> {
    // 调用接口验证短信验证码
    // 此处省略实际验证逻辑
    return code === "123456";
   }

5. 教师指纹与数字证书认证：

   async function teacherAuth(): Promise<boolean> {
    let fingerprintResult = await fingerprintAuth();
    if (!fingerprintResult) {
        return false;
    }
    let certResult = await verifyDigitalCertificate();
    return certResult;
   }
   async function fingerprintAuth(): Promise<boolean> {
    let challenge = generateRandomChallenge();
    let authParams = {
        challenge: challenge,
        authType: userAuth.AuthType.FINGERPRINT,
        authTrustLevel: userAuth.AuthTrustLevel.ATL4
    };
    try {
        let result = await auth.auth(authParams);
        return result.result === userAuth.AuthResult.SUCCESS;
    } catch (err) {
        console.error(`指纹认证失败: ${err.code}, ${err.message}`);
        return false;
    }
   }
   async function verifyDigitalCertificate(): Promise<boolean> {
    // 调用数字证书验证接口
    // 此处省略实际验证逻辑
    return true;
   }

安全性能与用户反馈

经过实际测试，“学海在线教育平台”的认证系统在安全性能方面表现出色。人脸识别误识率为 1/50 万，通过率 98.7%，平均耗时 800ms；指纹识别误识率 1/10 万，通过率 99.2%，平均耗时 500ms；双重认证误识率低至 1/1 亿，通过率 97.5%，平均耗时 1.2s。短信验证码验证和数字证书验证的成功率均达到 99%以上。

用户反馈积极，学生表示人脸识别登录方便快捷，提高了学习效率；家长对敏感操作的多重认证方式表示放心，认为有效保护了账户安全；教师对指纹与数字证书结合的认证方式给予肯定，认为确保了教学管理操作的安全性和数据的可靠性。

总结

HarmonyOS 的 User Authentication Kit 为开发者提供了丰富的功能和灵活的开发接口，能够满足不同应用场景下的复杂认证需求。通过“学海在线教育平台”的案例，我们详细展示了如何根据不同用户群体和使用场景，设计并实现多层次、全方位的认证系统。开发者在实际项目中，应充分结合业务需求，合理运用 User Authentication Kit 的各项特性，为用户打造安全、便捷的应用体验。

欢迎来到 Apache SeaTunnel 的世界！这份文档旨在帮助新手快速了解 SeaTunnel 的核心功能、基本架构，并完成第一个数据同步任务。

1. 什么是 Apache SeaTunnel？

Apache SeaTunnel 是一个非常易于使用、高性能、支持实时流式和离线批处理的海量数据集成平台。它的目标是解决常见的数据集成问题，如数据源多样性、同步场景复杂性以及资源消耗高的问题。

核心特性

• 丰富的数据源支持：支持 100+ 种 Connector，涵盖主流数据库、云存储、SaaS 服务等。
• 批流一体：同一套 Connector 代码同时支持批处理（离线）和流处理（实时）。
• 高性能：支持多引擎（Zeta, Flink, Spark），提供高吞吐、低延迟的数据同步能力。
• 简单易用：通过简单的配置文件（Config）即可定义复杂的数据同步任务。

2. 架构与环境

2.1 架构图

SeaTunnel 采用了解耦的设计架构，Source、Transform、Sink 插件与具体的执行引擎（Engine）是分离的。

2.2 操作系统支持

SeaTunnel 基于 Java 开发，理论上支持所有安装了 JDK 的操作系统。

2.3 环境准备

在开始安装 SeaTunnel 之前，请确保你的环境满足以下要求：

• JDK 版本：必须安装 Java 8 或 Java 11。

  • 可以通过命令 java -version 检查。
  • 确保设置了 JAVA_HOME 环境变量。

3. 核心组件深度解析

在使用 SeaTunnel 之前，深入理解其核心组件的内部机制有助于你更好地调优和排查问题。

3.1 Source (数据源)

Source 负责从外部系统读取数据，并将其转换为 SeaTunnel 内部的行格式（SeaTunnelRow）。

• Enumerator (枚举器)：运行在 Master 节点（Coordinator）。负责发现数据分片（Splits）。例如，在 JDBC Source 中，Enumerator 会根据 partition_column 的最大值和最小值计算出多个查询范围（Splits）。
• Reader (读取器)：运行在 Worker 节点。负责接收 Enumerator 分配的 Splits，并真正执行读取操作。多个 Reader 并行工作，极大提高了读取效率。
• Checkpoint 支持：对于流式作业，Source 还需要支持状态保存（如 Kafka 的 Offset），以便在故障恢复时实现断点续传。

3.2 Transform (数据转换)

Transform 负责在数据从 Source 流向 Sink 的过程中对数据进行处理。

• 无状态转换：大多数 Transform（如 Sql, Filter, Replace）是无状态的，即处理当前行不需要依赖其他行的数据。
• Schema 变更：Transform 可以改变数据的 Schema（增加、删除、修改字段），下游 Sink 会感知到这种变化。

3.3 Sink (数据目标)

Sink 负责将 SeaTunnel 处理后的数据写入到外部系统。

• Writer (写入器)：运行在 Worker 节点。负责将数据写入目标系统。通常支持批量写入以提高吞吐量。
• Committer (提交器)：运行在 Master 节点（可选）。对于支持事务的 Sink（如文件系统、Iceberg），需要一个全局的 Committer 来在 Checkpoint 完成时统一提交事务（二阶段提交），从而实现 Exactly-Once（精确一次）语义。

3.4 执行流程

1. 解析配置：SeaTunnel 解析配置文件，构建逻辑执行计划。
2. 资源分配：Master 节点根据并行度申请资源。
3. 任务分发：Enumerator 生成分片，分发给 Reader。
4. 数据流转：Reader -> Transform -> Writer。
5. 状态提交：周期性触发 Checkpoint，保存状态并提交事务。

4. 支持的 Connector 及其优缺点分析

SeaTunnel 支持超过 100 种 Connector，以下是几类最常用的 Connector 及其特性分析：

4.1 关系型数据库 (JDBC)

支持列表: MySQL, PostgreSQL, Oracle, SQLServer, DB2, Teradata, Dameng(达梦), OceanBase, TiDB 等。

• 优点：

  • 通用性强：只要有 JDBC 驱动即可连接几乎所有 SQL 数据库。
  • 功能完善：支持列投影（只读部分列）、并行读取（基于 partition_column 切分）、Exactly-Once（取决于实现）。
  • 自动建表：部分 Connector 支持在目标端自动创建表结构。

• 缺点：

  • 性能瓶颈：受限于 JDBC 协议和单机驱动性能，超大规模数据读取可能需要精细调优（如 fetch_size）。
  • 源库压力：如果并行度设置过高，可能打满源库连接池或 CPU。

4.2 消息队列

支持列表: Kafka, Pulsar, RocketMQ, Amazon DynamoDB Streams 等。

• 优点：

  • 高吞吐：天生适合大规模流数据处理，支持削峰填谷。
  • 格式丰富：支持 JSON, Avro, Protobuf, Canal-JSON, Debezium-JSON 等多种序列化格式。
  • Exactly-Once：支持端到端的精确一次语义（依赖 Checkpoint 机制）。

• 缺点：

  • 配置复杂：涉及 Offset 管理、序列化 Schema 配置、Consumer Group 管理等。
  • 数据可见性：相比数据库，数据在 Topic 中不够直观，调试稍显麻烦。

4.3 变更数据捕获 (CDC)

支持列表: MySQL-CDC, PostgreSQL-CDC, Oracle-CDC, MongoDB-CDC, SQLServer-CDC, TiDB-CDC 等。

• 优点：

  • 实时性：毫秒级捕获数据库增删改操作。
  • 无锁读取：SeaTunnel 的 CDC 实现了无锁并行快照算法，极大降低了对源库的影响。
  • 断点续传：支持从 Binlog/WAL 指定位置恢复。
  • Schema Evolution：支持表结构变更同步（部分支持）。

• 缺点：

  • 权限要求：通常需要较高的数据库权限（如 REPLICATION SLAVE）。
  • 依赖日志：源库必须开启 Binlog（或 WAL），且保留时间需足够长。

4.4 文件系统 & 云存储

支持列表: LocalFile, HDFS, S3, OSS, GCS, FTP, SFTP 等。

• 优点：

  • 海量存储：适合数据湖场景，成本低廉。
  • 格式支持：原生支持 Parquet, ORC, Avro, JSON, CSV, Excel, Text 等。
  • 压缩支持：支持 Snappy, Gzip, Lzo 等多种压缩算法。

• 缺点：

  • 小文件问题：流式写入时，如果 Checkpoint 间隔太短，容易产生大量小文件（SeaTunnel 有文件合并功能但会增加复杂度）。

4.5 NoSQL & 其他

支持列表: Elasticsearch, Redis, MongoDB, Cassandra, HBase, InfluxDB, ClickHouse, Doris, StarRocks 等。

• 特点：针对各数据库特性进行了优化，例如 ClickHouse/StarRocks 支持 Stream Load 高速导入，Elasticsearch 支持批量写入。

5. Transform 实战演练 (附带详细注释)

Transform 插件用于在 Source 和 Sink 之间处理数据。以下是几个常用 Transform 的配置示例。

5.1 Sql Transform (最推荐)

使用 SQL 语法对数据进行处理，支持重命名、计算、常量添加、过滤等。

transform {
  Sql {
    # 输入表名，必须与 Source 的 result_table_name 一致
    plugin_input = "fake"
    # 输出表名，供后续 Transform 或 Sink 使用
    plugin_output = "fake_sql"
    
    # SQL 查询语句
    # 1. name as full_name: 字段重命名
    # 2. age + 1: 数值计算
    # 3. 'US' as country: 增加常量列
    # 4. where age > 10: 数据过滤
    query = "select name as full_name, age + 1 as next_year_age, 'US' as country from fake where age > 10"
  }
}

5.2 Filter Transform

用于删除或保留指定字段（注意：不是过滤行，是过滤列/字段）。

transform {
  Filter {
    plugin_input = "fake"
    plugin_output = "fake_filter"
    
    # 仅保留 name 和 age 字段，其他字段会被丢弃
    include_fields = ["name", "age"]
    
    # 或者使用 exclude_fields 删除指定字段
    # exclude_fields = ["card"]
  }
}

5.3 Replace Transform

用于字符串替换，支持正则表达式。

transform {
  Replace {
    plugin_input = "fake"
    plugin_output = "fake_replace"
    
    # 需要替换的字段名
    replace_field = "name"
    # 匹配模式（旧字符串）
    pattern = " "
    # 替换后的字符串（新字符串）
    replacement = "_"
    # 是否使用正则表达式，这里设为 true，表示 pattern 是一个正则
    is_regex = true
    # 是否只替换第一个匹配项
    replace_first = true
  }
}

5.4 Split Transform

将一个字符串字段拆分为多个字段。

transform {
  Split {
    plugin_input = "fake"
    plugin_output = "fake_split"
    
    # 分隔符，这里使用空格
    separator = " "
    # 需要拆分的源字段
    split_field = "name"
    # 拆分后生成的新字段名列表
    output_fields = ["first_name", "last_name"]
  }
}

6. 快速安装

对于新手，推荐直接下载编译好的二进制发行包进行体验。

步骤 1: 下载

前往 SeaTunnel 下载页面 下载最新版本的二进制包（例如 apache-seatunnel-2.3.x-bin.tar.gz）。

步骤 2: 解压

tar -xzvf apache-seatunnel-2.3.x-bin.tar.gz
cd apache-seatunnel-2.3.x

步骤 3: 安装 Connector 插件

SeaTunnel 的 Connector 是插件化的。首次使用需要下载插件：

sh bin/install-plugin.sh

注意：该命令会根据 config/plugin_config 文件中的配置，从 Maven 中央仓库下载常用插件（如 connector-fake, connector-console 等）。如果下载速度慢，请耐心等待或配置 Maven 镜像。

💡 技巧：配置 Maven 国内镜像加速下载

如果遇到下载速度极慢或超时失败的情况，建议配置 Maven 阿里云镜像。

1. 找到或创建 Maven 配置文件：~/.m2/settings.xml (Windows 下为 C:\Users\你的用户名\.m2\settings.xml)。
2. 添加如下镜像配置：

<settings>
  <mirrors>
    <mirror>
      <id>aliyunmaven</id>
      <mirrorOf>*</mirrorOf>
      <name>阿里云公共仓库</name>
      <url>https://maven.aliyun.com/repository/public</url>
    </mirror>
  </mirrors>
</settings>

保存后再次运行 sh bin/install-plugin.sh 即可享受高速下载。

7. 实战：第一个 SeaTunnel 任务

我们将创建一个简单的任务：生成一些随机数据（FakeSource），并将其打印到控制台（Console Sink）。

步骤 1: 创建配置文件

在 config 目录下创建一个名为 hello_world.conf 的文件，内容如下：

env {
  # 并行度设置：决定了有多少个线程同时执行任务。
  # 设置为 1 表示单线程执行，适合测试；生产环境可根据资源调大。
  parallelism = 1
  # 作业模式：
  # BATCH (批处理)：一次性处理完数据后结束（如离线同步）。
  # STREAMING (流处理)：持续运行，实时处理数据（如实时同步）。
  job.mode = "BATCH"
}

source {
  # FakeSource 是一个虚拟数据源，用于生成测试数据
  FakeSource {
    # result_table_name: 将此数据源产生的数据注册为一个临时表，表名为 "fake"
    # 后续的 Transform 或 Sink 可以通过这个名字引用这份数据
    result_table_name = "fake"
    
    # row.num: 指定生成数据的总行数，这里生成 16 行数据
    row.num = 16
    
    # schema: 定义数据的结构（字段名和类型）
    schema = {
      fields {
        name = "string" # 定义一个名为 name 的字符串字段
        age = "int"     # 定义一个名为 age 的整型字段
      }
    }
  }
}

transform {
  # Sql Transform: 使用 SQL 语句对数据进行处理
  Sql {
    # plugin_input: 指定输入数据来源，这里引用了 Source 中定义的 "fake" 表
    plugin_input = "fake"
    
    # plugin_output: 指定处理后的结果表名，命名为 "fake_transformed"
    # 下游的 Sink 将使用这个名字来获取处理后的数据
    plugin_output = "fake_transformed"
    
    # query: 执行的 SQL 查询语句
    # 这里演示了选择 name 和 age 字段，并新增一个常量字段 new_field
    query = "select name, age, 'new_field_val' as new_field from fake"
  }
}

sink {
  # Console Sink: 将数据输出打印到控制台（标准输出）
  Console {
    # plugin_input: 指定要输出的数据来源，这里引用了 Transform 输出的 "fake_transformed" 表
    plugin_input = "fake_transformed"
  }
}

步骤 2: 运行任务

使用 SeaTunnel 自带的 Zeta 引擎运行该任务。

执行命令：

./bin/seatunnel.sh --config ./config/hello_world.conf -e local

命令详解：

• ./bin/seatunnel.sh: 启动脚本，默认使用 Zeta 引擎。
• --config (或 -c): 指定配置文件的路径。这里我们指定了刚才创建的 hello_world.conf。

• -e local (或 -m local): 指定执行模式。

  • local: 本地模式。SeaTunnel 会在当前进程中启动一个轻量级的 Zeta 引擎集群来运行任务，任务结束后集群关闭。适合开发和测试。
  • cluster: 集群模式。任务会提交到已经运行的 SeaTunnel 集群中执行。适合生产环境。

步骤 3: 查看结果与日志分析

任务启动后，终端会输出大量日志。我们需要关注以下关键信息：

1. 任务提交成功：
   看到 Job execution started 表示配置文件解析通过，任务已提交给引擎。

2. 数据处理过程：
   由于我们使用的是 Console Sink，数据会直接打印在日志中。你应能看到类似如下的输出：

   ...
   INFO  ...ConsoleSinkWriter - subtaskIndex=0 rowIndex=1: SeaTunnelRow#tableId=-1 SeaTunnelRow#kind=INSERT: CpiOd, 12345, new_field_val
   INFO  ...ConsoleSinkWriter - subtaskIndex=0 rowIndex=2: SeaTunnelRow#tableId=-1 SeaTunnelRow#kind=INSERT: eQqTs, 67890, new_field_val
   ...

   • subtaskIndex: 并行任务的编号。
   • rowIndex: 当前处理的行号。
   • SeaTunnelRow: 打印出的具体数据内容。
3. 任务结束：
   最后看到 Job Execution Status: FINISHED 表示任务执行成功结束。

8. 常见问题排查 (Troubleshooting)

如果在运行过程中遇到报错，请参考以下常见问题进行排查：

🔴 问题 1: command not found: java 或 JAVA_HOME is not set

• 现象：运行脚本时直接报错，提示找不到 Java。
• 原因：环境未安装 Java 或未配置环境变量。

• 解决：

  1. 运行 java -version 确认 Java 8 或 11 已安装。
  2. 设置环境变量：export JAVA_HOME=/path/to/your/java (建议写入 ~/.bashrc 或 ~/.zshrc)。

🔴 问题 2: Exception in thread "main" ... ClassNotFoundException

• 现象：报错提示找不到某个类，例如 ClassNotFoundException: org.apache.seatunnel.connectors.seatunnel.fake.source.FakeSourceFactory。
• 原因：Connector 插件未安装。默认包中只有引擎核心，没有包含具体的数据源插件。

• 解决：

  • 确保你执行过 sh bin/install-plugin.sh。
  • 检查 connectors/seatunnel 目录下是否有对应的 jar 包（例如 connector-fake-*.jar）。

🔴 问题 3: Config file not valid 或 HOCONSyntaxError

• 现象：提示配置文件格式错误。
• 原因：hello_world.conf 中的括号 {} 不匹配，或者关键字拼写错误。
• 解决：仔细检查配置文件语法。SeaTunnel 使用 HOCON 格式，确保每一层级的 { 和 } 都是成对出现的。

🔴 问题 4: 任务卡住不动

• 现象：日志停止更新，但任务没有结束。
• 原因：可能是资源不足（CPU/内存），或者在流模式（STREAMING）下这是正常现象（流任务是无休止运行的）。

• 解决：

  • 如果是 BATCH 模式卡住，检查 plugin_config 里的内存设置。
  • 检查是否在 env 中错误地设置了 job.mode = "STREAMING"。

9. 进阶学习资源

• 官方文档: https://seatunnel.apache.org/docs/
• Connector 列表: 查看 docs/en/connector-v2 目录，了解所有支持的数据源。
• 示例代码: 在 config 目录下通常会有一些模板文件（如 v2.batch.config.template），可以作为参考。

Apache SeaTunnel 批流一体、生态丰富、部署轻便，入门有指南，实战有案例。即刻上手探索，加入开源社区，让数据流转更简单，为数据工程高效赋能！祝你学习愉快！

VMware ESXi 9.0.2.0 macOS Unlocker & OEM BIOS 2.7 标准版和厂商定制版

ESXi 9.0 标准版，Dell (戴尔)、HPE (慧与)、Lenovo (联想)、Inspur/IEIT SYSTEMS (浪潮)、H3C (新华三)、Cisco (思科)、Fujitsu (富士通)、Hitachi (日立)、NEC (日电)、Huawei (华为)、xFusion (超聚变) OEM 定制版

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

作者主页：sysin.org

VMware vSphere 是 VMware 的虚拟化平台，可将数据中心转换为包括 CPU、存储和网络资源的聚合计算基础架构。vSphere 将这些基础架构作为一个统一的运行环境进行管理，并为您提供工具来管理加入该环境的数据中心。

vSphere 的两个核心组件是 ESXi 和 vCenter Server。ESXi 是用于创建并运行虚拟机和虚拟设备的虚拟化平台。vCenter Server 是一项服务，用于管理网络中连接的多个主机，并将主机资源池化。

通用特性概览

该版本在官方原版基础上新增以下特性：

• macOS Unlocker：来自 GitHub 的 Unlocker 4，现已支持 macOS Tahoe
• OEM BIOS 2.7：使用社区最流行的 OEM BIOS/EFI64，现已支持 Windows Server 2025
• LegacyCPU support，允许在不受官方支持的旧款 CPU 上安装 ESXi 9.0
• ESX-OSData 卷大小修改为 8GB，解决自 ESXi 7.0 起系统占用磁盘空间过大的问题（超过 142GB）
• 有限支持采用混合架构的第 12 代及以上 Intel 处理器，可实现正常引导和运行
• 同时提供 Dell、HPE 和 Lenovo 等厂商定制版映像 (sysin)，包含了必要的驱动和 OEM 软件

直接运行 macOS Tahoe

参看：macOS 26 Blank OVF - macOS Tahoe 虚拟化解决方案

ESXi 默认是支持创建 macOS 虚拟机的，但该功能仅限于 Apple Mac 硬件上启用。该版本解锁了对 macOS 虚拟化的支持，在任意非 Mac 硬件上可以直接运行 macOS 虚拟机。

⚠️ macOS 虚拟机与 Mac 上的 macOS 体验有天壤之别，仅用于体验而已。开启 macOS 卓越性能的唯一平台是搭载 Apple M 芯片的 Mac。尽早加入 Apple 阵营，开启卓越体验吧。

直接新建虚拟机，操作系统选择 “Apple macOS 12 (64-bit)”，即可安装和正常启动：

虚拟化中的 macOS Tahoe：

附：

• macOS Tahoe 26.2 (25C56) Boot ISO 原版可引导映像下载
• macOS Sequoia 15.7.3 (24G419) Boot ISO 原版可引导映像下载
• macOS Sonoma 14.8.3 (23J220) Boot ISO 原版可引导映像下载
• 更多：macOS 下载汇总 (系统、应用和教程)

VMware Dell 2.7 BIOS EFI64 ROM

来自社区最新的 OEM BIOS/EFI64，现已更新支持 Windows Server 2025。

BIOS.440 & EFI64.ROM - Dell 2.7 OEM BIOS: NT 6.0 (Vista/Server 2008), NT 6.1 (7/Server 2008 R2), NT 6.2 (Server 2012), NT 6.3 (Server 2012 R2), NT 10.0 (Server 2016/Server 2019/Server 2022/Server 2025)

Windows Server OVF 系列：

• Windows Server 2025 OVF (2025 年 12 月更新) - VMware 虚拟机模板
• Windows Server 2022 OVF (2025 年 12 月更新) - VMware 虚拟机模板
• Windows Server 2019 OVF (2025 年 12 月更新) - VMware 虚拟机模板
• Windows Server 2016 OVF (2025 年 12 月更新) - VMware 虚拟机模板
• Windows Server 2008 R2 OVF (2025 年 12 月更新) - VMware 虚拟机模板

其他 OVF，如：Rocky Linux 10 x86_64 OVF (sysin) - VMware 虚拟机模板，Ubuntu 24.04 LTS x86_64 OVF (sysin) - VMware 虚拟机模板，更多请在本站搜索 “OVF”。

支持不受官方支持的旧款 CPU

ESXi 9.0 同样废弃了对部分旧款 CPU 的支持，笔者根据相关文档判断以下 CPU 将不受 ESXi 9.0 支持：

• Intel

  • Xeon D‑1500 Series
  • Xeon E3‑1200‑V5 / E3‑1500‑V5 Series
  • Xeon E5‑2600‑V4 / E5‑1600‑V4 Series
  • Xeon E5‑4600‑V4 Series
  • Xeon E7‑8800/4800‑V4 Series
  • Xeon E3‑1200‑V6 Series
  • Intel Xeon Platinum 8100 / Gold 6100/5100 / Silver 4100 / Bronze 3100 Series
  • Xeon D‑2100 Series
  • Xeon W‑2100 Series

• AMD

  • Bulldozer 架构（如 Opteron 6200/4200/3200）
  • Piledriver 架构（如 Opteron 4300/6300 系列）
  • Steamroller 架构（如 Opteron X2250/X1250 Berlin）
  • Kyoto 架构（如 Opteron X1100/X2100）

ESXi 8.0 同样废弃了对部分旧款 CPU 的支持，以下 CPU 将不受 ESXi 8.0 支持：

• Intel Family 6, Model = 2A (Sandy Bridge DT/EN, GA 2011)
• Intel Family 6, Model = 2D (Sandy Bridge EP, GA 2012)
• Intel Family 6, Model = 3A (Ivy Bridge DT/EN, GA 2012)
• AMD Family 0x15, Model = 01 (Bulldozer, GA 2012)

vSphere 7.0 Update 2 及更高版本中 ESX 安装程序显示的如下警告消息已经明示：
CPU_SUPPORT_WARNING: The CPUs in this host may not be supported in future ESXi releases. Please plan accordingly.

修改启动参数，在官方不受支持的 CPU 的服务器上可以正常安装。

根据 VMware vSphere 7.0 Release Notes，以下 CPU 已经不受支持（无法安装或者升级 ESXi 7.0）

Comparing the processors supported by vSphere 6.7, vSphere 7.0 no longer supports the following processors:

• Intel Family 6, Model = 2C (Westmere-EP)
• Intel Family 6, Model = 2F (Westmere-EX)

笔者在一台 2010 年发布的服务器上安装运行良好 (sysin)：HP DL 380 G7，Intel® Xeon® CPU E5606

备注：本截图为 7.0 版本

ESX-OSData 卷大小修改为 8GB

ESXi 9.0 对存储容量的要求未有明显变更，以下 ESXi 8.0 的描述基本适用。

⚠️ 在 ESXi 8.0 中建议放弃使用 USB/SD 卡作为系统存储介质（虽然 SD 卡和 USB 介质继续获得有限支持，详见 KB85685）。

从 ESXi 7.0 开始，对磁盘空间的要求有所变化：

• 8GB SD 卡 + 32GB 本地磁盘
• 32GB 本地磁盘
• 142G 或者更大的本地磁盘

通常我们在一块数百 GB 或者更大的本地磁盘上安装 ESXi，系统分区磁盘空间将占用 142GB 以上，整个系统分区（内核参数：systemMediaSize）需要 138GB 和 4GB 以上的空闲空间，其中 ESX-OSData volume 大约需要 120GB 的磁盘空间，对于磁盘空间紧张情况下可能有一定的浪费 (sysin)。修改后，系统安装后占用的磁盘空间不超过 16GB（特别是针对个人实验，无需浪费过多存储容量）。

图：vSphere 7 中的新分区架构，只有系统引导分区固定为 100 MB，其余分区是动态的，这意味着分区大小将根据启动媒体大小确定。

从 vSphere 7.0 Update 1c 开始，您可以使用 ESXi 安装程序引导选项 systemMediaSize 限制启动媒体上系统存储分区的大小。如果您的系统占用空间较小，不需要最大 128 GB 的系统存储大小，您可以将其限制为最小 32 GB。systemMediaSize 参数接受以下值：

• min（32 GB，用于单磁盘或嵌入式服务器）
• small（64 GB，用于至少有 512 GB RAM 的服务器）
• default（128 GB）
• max（消耗所有可用空间，用于多 TB 的服务器）

即使设置值为 min，相比之前的版本所需存储容量还是要大的多。

有限支持第 12 代及以上 Intel 处理器

ESXi 面向数据中心虚拟化，在测试和学习时也常常将其运行于桌面 PC 之上。

据悉 ESXi 8.0 并不支持第 12 代 Intel 处理器，直接引导会出现 PSOD。本次通过加载内核参数可以有限支持第 12 代 Intel CPU，即可以正常引导和安装，也可以正常运行 (sysin)，但是无法区分或识别两种核心，P 核的超线程是无法识别的，比如 i7-12650H 配备 6P + 4E 在桌面系统中显示为 16 核心，而在 ESXi 中仅识别为 10 核。现在有了更好的解决方案，绝大多数主流品牌机和主板都可以通过配置开启 P 核的超线程（非主流请慎选）。

已经广泛验证支持第 12 代及以上 Intel 处理器（目前 13、14 代同样支持），更多案例，期待您的反馈。

第 12 代英特尔酷睿桌面级处理器有 N 个性能核（P 核，Performance-core）和 N 个能效核（E 核，Efficient-core）组成，性能核和能效核的混合架构，是 12 代酷睿处理器最大的革新。该架构或俗称 PE 大小核。

第 12 代及以上 Intel CPU 已经成功安装 ESXi 后需要进一步配置，可联系笔者了解详情。

⚠️：并不推荐此类 CPU，无法有效利用全部计算资源。

💡：仅标准版和集成驱动版提供此项特性，品牌服务器于此无关。

提供标准版和厂商定制版映像

提供标准版和 Dell、HPE、Lenovo 等定制版映像 iso 文件，定制版集成了对应厂商的驱动，建议该厂商产品优先使用。

• Standard (标准版)
• Dell (戴尔) 定制版
• HPE (慧与) 定制版
• Cisco (思科) 定制版
• Fujitsu (富士通) 定制版
• H3C (新华三) 定制版
• Hitachi (日立) 定制版
• Huawei (华为) 定制版
• Inspur/IEIT SYSTEMS (浪潮) 定制版
• Lenovo (联想) 定制版
• NEC (日电) 定制版
• xFusion (超聚变) 定制版

💡：各厂商定制版将逐步提供，部分厂商关注度太低，可能不再提供定制服务。

Dell (戴尔) 服务器兼容性

因新产品刚刚发布，将及时更新相关内容。

以下如未列出，欢迎提供机型和配置（CPU、RAID Controller、网卡）来询。

💡 提示：

• ① 以上机型、CPU 等参数未全部列出，详尽信息可在官网查询。
• ② ESXi 不支持 SW RAID（仅 Intel VROC 等少数产品支持）。
• ③ 以上仅列出 Rack 和 Tower 机型，其他 C、F 和 M 机型理论上兼容性同。

HPE (慧与) 服务器兼容性

因新产品刚刚发布，将及时更新相关内容。

以下如未列出，欢迎提供机型和配置（CPU、RAID Controller、网卡）来询。

💡 提示：

• ① 以上机型、CPU 等参数未全部列出，详尽信息可在官网查询。
• ② ESXi 不支持 SW RAID（仅 Intel VROC 等少数产品支持）。
• ③ HPE ProLiant 映像是独立的，不包含 Synergy 和 Superdome。

华为与超聚变服务器兼容性

因新产品刚刚发布，将及时更新相关内容。

以下如未列出，欢迎提供机型和配置（CPU、RAID Controller、网卡）来询。

💡 提示：

• ① 以上机型、CPU 等参数未全部列出，详尽信息可在官网查询。
• ② ESXi 不支持 SW RAID（仅 Intel VROC 等少数产品支持）。
• ③ 以上仅列出 Rack 机型，其他机型理论上兼容性同。
• ④ 已知配备华为海思芯片的网卡（SP57x、SP58x、SP67x、SP68x）目前不支持 ESXi。
• ⑤ 已知配备的 Silicom 网卡最高支持 ESXi 6.x。

其他品牌服务器兼容性

如果已经有定制版的品牌，可以访问品牌官网查询官方兼容列表，本站定制版兼容性更加广泛。

欢迎提供机型和配置（CPU、RAID Controller、网卡）来询。

请提供以下四个信息：

• 机器品牌和型号
• CPU 型号
• RAID 卡型号
• 网卡型号

常见问题解答 (FAQ)

请访问原文链接：https://sysin.org/blog/vmware-esxi-9-oem/ 查看。

下载地址

VMware ESXi 9.0.2.0 macOS Unlocker & OEM BIOS 标准版和厂商定制版：

• 发布日期：2026-01-20
• 新增 vCenter 和 ESXi SSL 证书自动续期功能，以及 25 项已知问题修复。详见官方文档及本站相关发布。
• Standard (标准版)：https://sysin.org/blog/vmware-esxi-9-oem/
• Dell (戴尔) PowerEdge 定制版 A02：https://sysin.org/blog/vmware-esxi-9-oem/
• HPE (慧与) ProLiant 定制版 Sep2025：https://sysin.org/blog/vmware-esxi-9-oem/
• Huawei (华为) FusionServer 定制版：https://sysin.org/blog/vmware-esxi-9-oem/
• xFusion (超聚变) FusionServer 定制版：https://sysin.org/blog/vmware-esxi-9-oem/
• Lenovo (联想) 定制版 S02：https://sysin.org/blog/vmware-esxi-9-oem/
• Inspur (浪潮) 定制版：https://sysin.org/blog/vmware-esxi-9-oem/
• H3C (新华三) 定制版：https://sysin.org/blog/vmware-esxi-9-oem/

• 其他定制版：https://sysin.org/blog/vmware-esxi-9-oem/

  • Cisco (思科) UCS 定制版
  • Fujitsu (富士通) 定制版
  • Hitachi (日立) 定制版
  • NEC (日电) 定制版

集成驱动版本，请访问：

• VMware ESXi 9.0.2.0 macOS Unlocker & OEM BIOS 2.7 集成网卡驱动和 NVMe 驱动 (集成驱动版)

官方原版，请访问：

• VMware vSphere 9.0.2.0 正式版发布 - 企业级工作负载平台

上一个版本，请访问：

• VMware ESXi 8.0U3h macOS Unlocker & OEM BIOS 2.7 标准版和厂商定制版

更多：VMware 产品下载汇总

第三届 PolarDB 开发者大会

📍 1 月 20 日，上海 · 五角场凯悦酒店

作为 AI 时代下的云原生数据库领域开年技术盛宴，大会不仅聚焦“AI 就绪的云原生数据库”的前沿实践，呈现 30+ 场技术演讲；更是携手各社区伙伴，一起带来数场 AI 互动体验，用真实体验、互动来感知 AI 时代的数据库，感受数据+AI 的无限可能。

AgentScope Java：Agentic LLM 应用开发框架

AgentScope Java 是以 Agentic 为核心设计理念，面向 Java 开发者的 LLM 应用开发框架。包括核心层、Studio、RL、Memory，以及架构上全力推进 Serverless 化，实现毫秒级冷启动与混合部署，帮助开发者在应对高并发的同时，显著降低部署成本并提升效率。

AgentRun：一站式 Agentic AI 基础设施平台

函数计算 AgentRun 是以高代码为核心的一站式 Agentic AI 基础设施平台，秉持生态开放和灵活组装的理念，为企业级 Agent 应用提供从开发、部署到运维的全生命周期管理，让 Agentic AI 真正进入企业生产环境。

现场还有

《PolarDB AI 能力集》

《AI 原生应用架构白皮书》

等您来领取