中国信通院2025年报告将“时空智能”定义为以统一高精度时空基准为核心，融合多源数据与AI算法，实现从物理世界的 “描述解释” 到 “预测决策” 升级的关键能力。

时空数据具有高维、动态和海量等特性，传统二维GIS地图难以承载其全部信息价值，决策者需要的是能融合、回溯和推演的“时空立方体”。

实时云渲染技术正成为将抽象的“时空立方体”转化为直观、沉浸、可操作三维场景的终极呈现层，是时空智能落地应用的可视化桥梁。

时空智能的内涵：微秒级、毫米级的精准感知与预测

时空智能的先进性，体现在其超越传统地理信息的精度与维度。

1. 精度跃升：从米到毫米。 传统GPS定位精度在米级，而结合北斗地基增强、视觉SLAM等技术，时空智能可以实现室内外厘米到毫米级的实时定位。这意味着，在数字孪生工厂中，可以精准追踪AGV小车的每一个轮子；在工地中，可以监测大型吊臂毫米级的形变。
2. 维度拓展：从静态到动态推演。 时空智能不仅描述“某物在某时某地”，更能预测“某物将在何时去往何地”。时空大模型可以基于历史轨迹数据，预测未来一段时间内城市交通流的变化、人群的聚集态势，甚至是地质灾害点的形变趋势。
3. 融合广度：从单一数据到多源交响。 它要求将卫星影像（空间）、历史档案（时间）、IoT传感器读数（状态）、社交媒体（事件）等完全不同质的数据，在统一的时空基准下进行关联、校准与融合分析。

复杂计算的海量数据，经过建模、三维引擎渲染生成可执行程序后，变身为一个个独立的可视化文件。如何将这些依托高算力高配置的程序文件，转变为即点即用、快速分发、数据通传的实际业务场景，需要实时云渲染技术来实现高效运转的展示方式。

实时云渲染：承载并呈现高精度时空数据的“动态画布”

实时云渲染在时空智能中的角色，是将后台复杂的计算、分析、预测结果，实时“绘制”在一张动态的、可交互的三维数字画布上。

1. 实现了时空数据的“实体化”与“情境化”。 在平行云LarkXR构建的平台上，一段货车的历史轨迹不再是一条单调的线，而是可以还原成一辆三维货车模型，在三维道路模型中重播放映，并沿途叠加显示当时的车速、载重、油耗等传感器数据，各类IOT数据叠加三维场景，实时反馈在一张图/一个场景中，极大的降低了决策者对模型数据的观测要求。
2. 支持海量动态目标的同屏实时呈现。 一个城市的数字孪生交通系统，可能需要同时显示数万辆车的实时位置。LarkXR实时云渲染平台赋予了三维场景云化展示、自由分发传播的便捷能力。管理者不再需要在固定时间、固定设备、固定业务系统中安装下载，或者是极其缓慢的加载缓冲，而是仅需一个URL链接即可宏观观察全城车流，也可以瞬间下钻到某个拥堵路口，查看每一辆车的实时视角。
3. 赋能了时空数据的“穿梭”与“推演”。云渲染后的页面上用户可以使用任意终端随时访问，拖动时间轴，秒级回溯过去24小时特定区域的人流变化；也可以开启预启动模式，观看基于AI模型推演出的未来1小时交通态势发展。这种在时间维度上的自由导航，是理解时空规律、验证预测模型的有力工具。平行云与AIRLOOK、商汤科技在实景三维与AI大模型融合的案例，正是这一能力的体现。
   

基于LarkXR构建“云边协同”的时空智能数字孪生应用

考虑到时空智能应用对实时性和计算量的不同要求，基于LarkXR的“云边协同”架构成为理想选择。

1. 去中心化：处理宏观、非实时、高计算量的任务。 例如，全市范围的交通大数据挖掘分析、基于多年遥感影像的城市扩张模拟、大规模时空预测模型的训练与推理。这些任务在传统模式下需要强大的CPU和GPU算力，并分散在各个高配物理设备上。LarkXR实时云渲染平台既可以完成数据中心化热备，同时也支持渲染节点去中心化，即依托地理边缘云节点架构优势，整合公有云、私有化部署等各类GPU算力资源。实时云渲染后的交互视频流（如预测出的拥堵区域三维可视化场景）再通过LarkXR流化推送到指挥中心大屏，支持最高8K分辨率。
2. 边缘云/端：处理局部、高实时、低延迟的交互。 例如，在智慧港口，龙门吊的毫米级防撞监控需要极低的延迟。可以在港口本地部署LarkXR边缘渲染节点，处理本地摄像头的视频与传感器数据，与港口BIM模型进行实时融合渲染，将结果直接推送到中控室和司机终端，实现端到端低于50毫秒的预警响应。
3. LarkXR自带PaaS平台管理功能，统一管控与灵活调度。 平台可以统一管理分布在中心云和各个边缘节点的渲染资源，根据应用负载和网络状况，智能调度渲染任务。

场景落地：智慧交通、地灾监测与文化遗产保护

基于实时云渲染的时空智能平台，正在多个领域催生革新性应用。

1. 智慧交通的“全景作战地图”。 交管部门可以基于该平台，将路网状态、信号灯配时、警车位置、事故报警、施工占道信息、甚至互联网导航公司的拥堵数据，全部融合在一张实景三维地图上。指挥员可以立体化掌握全局，点击一个事故点，系统自动关联周边监控视频和可用警力，实现精准、快速的扁平化指挥。
2. 地质灾害的“生命体”监测。 对于滑坡、沉降等灾害点，平台将InSAR卫星形变数据、地面GNSS监测站数据、雨量计数据、地质模型进行融合可视化。AI模型基于多源时空数据预测风险等级，并在三维地形上以动态扩展的红色区域示意风险蔓延趋势，为避险转移提供直观的决策依据。
3. 文化遗产的“四维数字档案”。 对于古建筑、考古遗址，平台可以整合不同历史年代的测绘数据、修复记录、影像资料，构建一个在时间轴上可滑动的四维数字孪生体。研究者可以“穿越”到不同年代观察其变迁，管理者可以模拟不同保护措施（如加盖雨棚）对微环境的影响，所有可视化终端均可以作为展示平台，并肩负向公众开放传播的使命，实现科学的预防性保护。
   

实时云渲染技术，让时空智能从实验室里的算法和服务器里的数据库，变成了决策者手中可以旋转、缩放、剖切、穿越的“水晶球”。它消融了数据与认知之间的最后一道屏障，让基于时空的精准描述、深刻解释和科学预测，真正赋能于各行各业的智能决策。平行云LarkXR实时云渲染平台，正是打磨这颗“水晶球”，让时空智慧清晰映现的关键力量。

本文已发布于官网：https://www.pingxingyun.com/

在当今的数据驱动时代，不同系统间的数据交换与集成已成为常态。Excel作为常见的报表和数据存储格式，XML作为一种跨平台的数据交换标准，它们之间的相互转换是Java开发者经常面临的实际需求。无论是将Excel数据导出为XML进行API调用，还是将接收到的XML数据导入Excel进行可视化分析，都需要一套高效可靠的解决方案。本文将深入探讨如何利用强大的Spire.XLS for Java库，在Java环境中轻松实现Excel到XML以及XML到Excel的灵活转换，帮助你提升数据处理效率。

Spire.XLS for Java 库简介与安装

Spire.XLS for Java是一个功能丰富的Excel操作库，它允许开发者在Java应用程序中创建、读取、编辑、转换和打印Excel文件，无需依赖Microsoft Office。其特点是API直观、性能高效，并且支持多种Excel文件格式（如XLS、XLSX、CSV等）与XML、PDF、HTML等格式的转换。

要开始使用Spire.XLS for Java，你需要在项目构建文件中添加相应的依赖。

Maven 依赖：

将下列代码添加到 pom.xml 文件中，以导入 JAR 文件

<repositories>
    <repository>
        <id>com.e-iceblue</id>
        <name>e-iceblue</name>
        <url>https://repo.e-iceblue.cn/repository/maven-public/</url>
    </repository>
</repositories>
<dependencies>
    <dependency>
        <groupId>e-iceblue</groupId>
        <artifactId>spire.xls</artifactId>
        <version>16.1.3</version>
    </dependency>
</dependencies>

在 Java 中将 Excel 转换为 XML

将Excel数据转换为XML在数据集成、Web服务交互或自定义数据存储方面非常常见。Spire.XLS支持将整个工作簿或指定工作表的数据导出为XML格式。该库提供了灵活的选项来控制XML的输出结构。

以下示例展示了如何将一个Excel工作簿转换为XML文件：

import com.spire.xls.*;

public class ExcelToXML {
    public static void main(String[] args) {
        //创建Workbook类的对象
        Workbook wb = new Workbook();

        //加载Excel文档
        wb.loadFromFile("input.xlsx");

        //保存为XML文件
        wb.saveAsXml("ToXML.xml");
    }
}

• 首先创建一个Workbook对象，然后使用loadFromFile()加载示例的Excel文件。
• wb.saveAsXml()方法将刚在加载的Excel文件保存为XML格式。

在 Java 中将 XML 转换为 Excel

反向转换，即将XML数据导入到Excel中，同样是常见的需求，尤其是在处理来自Web服务或配置文件的数据时。Spire.XLS能够解析XML数据并将其填充到Excel工作表中。

以下代码展示了如何将一个XML文件转换为Excel文件：

import com.spire.xls.*;

public class XmlToExcel {
    public static void main(String[] args) {
        //创建Workbook类的对象
        Workbook wb = new Workbook();

        //加载XML文档
        wb.loadFromXml("sample.xml");

        //转为xlsx格式的Excel
        wb.saveToFile("toExcel.xlsx",FileFormat.Version2013);
    }
}

• 首先创建一个Workbook对象，然后使用loadFromXml加载XML文件。
• 调用saveToFile()将XML文件保存为Excel工作簿。

注意： 上述XML转Excel示例中的XML解析部分是基于一个简单、扁平化的XML结构。对于复杂的、嵌套的XML结构，你需要更复杂的解析逻辑来映射到Excel的行和列。

结语

通过本文的介绍和代码示例，我们详细探讨了如何在Java环境中，利用Spire.XLS for Java库实现Excel与XML文件的双向转换。无论是将Excel数据高效导出为XML，还是将XML数据灵活导入到Excel中进行处理，Spire.XLS都提供了直观且功能强大的API支持。掌握这些转换技巧，将极大地增强你在数据处理、系统集成和报表自动化方面的能力。希望本文能为你提供有价值的参考，助你在实际项目中更加游刃有余地处理各种文件转换需求。

前面的章节（社区专栏《SQL调优》）我们已经写了很多篇幅关于 MySQL 执行计划的解读，今天我们来继续延伸介绍执行计划的链路跟踪功能，也就是 MySQL 的 Optimizer Trace。

在这之前，先来回顾下 EXPLAIN 的结果：

mysql:ytt>explain select * from t1 a left join y1 b on a.id = b.id where a.r1<100 order by a.r2 desc;
+----+-------------+-------+------------+--------+---------------+---------+---------+----------+--------+----------+-----------------------------+
| id | select_type | table | partitions | type   | possible_keys | key     | key_len | ref      | rows   | filtered | Extra                       |
+----+-------------+-------+------------+--------+---------------+---------+---------+----------+--------+----------+-----------------------------+
|  1 | SIMPLE      | a     | NULL       | ALL    | idx_r1        | NULL    | NULL    | NULL     | 998222 |    50.00 | Using where; Using filesort |
|  1 | SIMPLE      | b     | NULL       | eq_ref | PRIMARY       | PRIMARY | 4       | ytt.a.id |      1 |   100.00 | NULL                        |
+----+-------------+-------+------------+--------+---------------+---------+---------+----------+--------+----------+-----------------------------+
2 rows in set, 1 warning (0.00 sec)

EXPLAIN 展示出来的核心数据有：

1. 表关联顺序
2. 优化器筛选过的索引
3. 实际使用的索引
4. 每张表依据统计信息的扫描行数
5. Extra 额外数据提示
6. 两种执行计划（explain format=tree / explain format=json）展示出来的额外成本数据

如果想快速对于 SQL 进行优化，基于以上的结果完全可以满足。但是想深入了解 MySQL 优化器为什么选择这样的执行计划，基于以上的结果就无法满足。

举例说明：

• 我想知道对于表 a 来讲，为什么有索引 idx_r1，但是实际却没有使用，而走的全表扫？
• 两张表关联，为什么选择的顺序是表 a 驱动表 b，而不是表 b 驱动表 a？
• 为什么字段 r2 有索引，但是依然要走排序？

带着这些疑问，我们来介绍 MySQL 的 Optimizer Trace 功能。

1. 什么是 Optimizer Trace？

简单来讲，Optimizer Trace 是一个 SQL 执行计划的链路跟踪器，跟踪 SQL 的解析、优化、执行等过程，并且把结果记录到 MySQL 元数据表（information_schema.optimizer_trace），之后可以对这张表分析得到很多个执行计划的“为什么？”！

2. 如何使用 Optimizer Trace？

要使用 Optimizer Trace 功能，首先得打开控制开关。谨记：这个功能非常耗费资源，默认关闭的，可以通过调整以下变量开启：

mysql:ytt>show variables like 'optimizer_trace%';
+------------------------------+----------------------------------------------------------------------------+
| Variable_name                | Value                                                                      |
+------------------------------+----------------------------------------------------------------------------+
| optimizer_trace              | enabled=off,one_line=off                                                   |
| optimizer_trace_features     | greedy_search=on,range_optimizer=on,dynamic_range=on,repeated_subselect=on |
| optimizer_trace_limit        | 1                                                                          |
| optimizer_trace_max_mem_size | 1048576                                                                    |
| optimizer_trace_offset       | -1                                                                         |
+------------------------------+----------------------------------------------------------------------------+
5 rows in set (0.00 sec)

以上几个参数详细解释下：

• optimizer_trace：enabled=on/off 启用/禁用 Optmizer Trace 功能；one_line=on/off 启用/禁用 json 格式化存储，一般不需改动。
• optimizer_trace_limit/optimizer_trace_offset：这两个参数和 LIMIT 子句一样，用来最终展示 Trace 的 SQL 条数。展示的条数越多，对内存消耗越大，默认展示最近的一条记录。比如设置 optimizer_trace_limit 为 10，optimizer_trace_offset 为 -10，就可以最多展示 10 条 Trace 记录。
• optimizer_trace_max_mem_size：用来存储 Trace 结果的最大内存。
• optimizer_trace_features：用来启动/禁用相关 Trace 特性开关。
• end_markers_in_json：启用/禁用 注释功能。开启这个，Trace 结果可读性更强。

• Optimizer Trace 可以跟踪的语句有：

  • SELECT、TABLE、VALUES、WITH、INSERT、REPLACE、UPDATE、DELETE
  • EXPLAIN
  • SET（排除设置 Optimizer Trace 相关参数）
  • DO
  • 存储函数内部、触发器内部等的 DECLARE、CASE、IF、RETURN 语句
  • CALL

在数据库里，语句调优一般说的是 SELECT 语句，所以大部分场景跟踪的也只有 SELECT 语句。

元数据表字段解析

mysql:ytt>desc information_schema.optimizer_trace;
+-----------------------------------+----------------+------+-----+---------+-------+
| Field                             | Type           | Null | Key | Default | Extra |
+-----------------------------------+----------------+------+-----+---------+-------+
| QUERY                             | varchar(65535) | NO   |     |         |       |
| TRACE                             | varchar(65535) | NO   |     |         |       |
| MISSING_BYTES_BEYOND_MAX_MEM_SIZE | int            | NO   |     |         |       |
| INSUFFICIENT_PRIVILEGES           | tinyint(1)     | NO   |     |         |       |
+-----------------------------------+----------------+------+-----+---------+-------+
4 rows in set (0.00 sec)

• QUERY：TRACE 的 SQL 语句原文
• TRACE：SQL 语句的 TRACE 结果，JSON 格式存储（由变量 end_markers_in_json 来控制）
• MISSING_BYTES_BEYOND_MAX_MEM_SIZE：TRACE 结果超过变量 optimizer_trace_max_mem_size 设置的值后，截断的大小（BYTE）
• INSUFFICIENT_PRIVILEGES：对存储过程、存储函数等包含有 SQL SECURITY DEFINER 的用户是否有对应的权限，有权限为 0，无权限为 1，并且 TRACE 字段为空。

Optimizer Trace 开启步骤

mysql:ytt>set optimizer_trace='enabled=on';
Query OK, 0 rows affected (0.00 sec)

mysql:ytt>set optimizer_trace_limit=10;
Query OK, 0 rows affected (0.00 sec)

mysql:ytt>set optimizer_trace_offset=-10;
Query OK, 0 rows affected (0.00 sec)

mysql:ytt>set end_markers_in_json=on;
Query OK, 0 rows affected (0.00 sec)

这里要注意的是，修改任何一个 Optimizer Trace 相关参数，元数据表 information_schema 表都会被清空。

mysql:ytt>select count(*) from information_schema.optimizer_trace;
+----------+
| count(*) |
+----------+
|       10 |
+----------+
1 row in set (0.00 sec)

mysql:ytt>set optimizer_trace_offset=-2;
Query OK, 0 rows affected (0.00 sec)

mysql:ytt>select count(*) from information_schema.optimizer_trace;
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.00 sec)

3. Optimizer Trace 的结果

我们用一个最简单的例子来看看 Optimizer Trace 的大致结构：do 语句非常简单，只用来验证是否语法正确，不出结果。

mysql:ytt>do 1+1;
Query OK, 0 rows affected (0.00 sec)

下面是 Optimizer Trace 结果：

mysql:ytt>select query,trace from information_schema.optimizer_trace\G
*************************** 1. row ***************************
query: do 1+1
trace: {
  "steps": [
    {
      "join_preparation": {
        "select#": 1,
        "steps": [
          {
            "expanded_query": "/* select#1 */ select (1 + 1) AS `1+1`"
          }
        ]
      }
    },
    {
      "join_optimization": {
        "select#": 1,
        "steps": [
        ]
      }
    },
    {
      "join_execution": {
        "select#": 1,
        "steps": [
        ]
      }
    }
  ]
}
1 row in set (0.00 sec)

可以看到，Optimizer Trace 结果是一个 JSON 串，key 为 steps，value 是一个数组，数组有三个 key，分别为：

• join_preparation 准备阶段：这里会做一些 SQL 改写，关键字识别等等，可以看到 expanded_query 对应的值即为 SQL 语句被改写后的内部 SQL。
• join_optimization 优化阶段：具体 SQL 优化，包括一些可能的逻辑优化，一些根据表统计信息预估的物理优化等等。
• join_execution 最终执行阶段：最终 SQL 采用的执行计划等等。

本篇是Optimizer Trace的开端，由于内容太多，我特地拆分为几篇来写，欢迎继续订阅。

随着国家“中小企业数字化转型城市试点”和“人工智能+”战略的深入推进，工业全要素智能化已成为推动制造业转型升级的核心方向。在这一背景下，工业大数据平台作为连接海量数据、整合智能应用的关键载体，正在为企业的生产、管理、决策提供全新的赋能路径。工业大数据平台不仅仅是数据的存储与处理工具，更是通过融合工业机理与人工智能技术，构建起一套高效、智能、安全的数字化生态系统，助力企业在复杂多变的市场中提升竞争力，实现可持续发展。
工业大数据平台的核心价值在于其对数据全生命周期的管理能力。从数据采集到存储、治理、分析再到应用，平台通过高度集成的技术架构，解决了传统制造业面临的痛点。例如，许多企业在生产过程中缺乏对多源异构数据的有效整合，导致数据孤岛现象严重，无法形成统一的数据视角。工业大数据平台通过对接多种数据源和协议，实现了数据的统一接入与管理，为后续分析奠定基础。更重要的是，平台能够将原始数据转化为可落地的业务洞察，例如通过工艺参数优化、质量缺陷溯源等功能，直接驱动生产效率的提升和成本的降低。可以说，工业大数据平台是制造业数字化转型中不可或缺的战略支撑。
然而，工业大数据平台的建设并非易事，它涉及技术、管理、生态等多个维度的协同创新。首先，平台需要具备强大的数据处理能力，以应对海量、异构、实时性的工业数据。其次，数据治理和安全机制必须完善，以确保数据在共享与使用过程中不被滥用或泄露。此外，平台还需要结合行业特性，提供差异化的应用场景，例如在汽车制造领域，平台可以帮助企业实现生产线的智能监控与预测性维护，而在能源行业，则能辅助企业进行用电趋势分析和设备健康管理。
在这一领域，广域铭岛凭借其深厚的工业知识积累和创新的解决方案，成为行业的标杆之一。通过其自主研发的Geega OS工业操作系统和工业AI应用平台，不仅为制造企业提供数据集成、治理和分析服务，还通过工厂大脑等工具，将AI能力深度嵌入生产环节。例如，其在汽车产业链上的实践，帮助中小企业实现了质量缺陷的AI视觉检测和生产工艺的智能寻优，显著提升了生产效率和产品合格率。此外，还积极参与国家工业互联网大数据中心的建设，推动数据资产化和行业智能体的研发，为制造业的智能化升级提供了强有力的支撑。
国内还有许多企业在工业大数据领域取得了显著成果。例如某工业互联科技有限公司通过构建工业软件生态平台，为政府、企业与组织提供数字化转型服务，特别关注中小企业在安全生产和智能制造方面的痛点。其打造的“五位一体”管理平台，涵盖了重大危险源监测预警、可燃有毒气体检测报警等功能，为化工企业的安全运营提供了保障。此外某航天平台也在工业数据汇聚、共享和应用方面发挥了重要作用，通过开放的云服务框架和工业大数据引擎，推动了数据驱动的制造模式创新。
这些案例充分证明了工业大数据平台在提升资源利用效率、优化生产流程和增强企业竞争力方面的巨大潜力。

VMware NSX 4.2.3.3 发布，新增功能概览

VMware NSX 4.2.3.3 - 网络安全虚拟化平台

构建具有网络连接和安全性的云智能网络，跨多种云环境支持一致的策略、运维和自动化。

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

作者主页：sysin.org

网络虚拟化平台

VMware NSX

使用 VMware NSX，通过单一窗口像管理单个实体一样管理整个网络。

​VMware NSX 4.2.3.3 | 27 JAN 2026 | Build 25171318

新增功能

VMware NSX 4.2.3.3 是一个更新版本，包含错误修复以及以下新功能。

• 在裸金属 Edge 节点上支持 NVIDIA Mellanox ConnectX-6 Lx SmartNIC（CX6 LX）。
• Edge 传输节点的重新部署工作流会在启动重新部署之前，先校验用户提供的 vCenter 配置（例如 vCenter、计算资源和数据存储 ID）。如果检测到 vCenter 配置不正确，重新部署将停止并抛出错误。
• 在之前的版本中，由证书过期触发的告警并未清晰指示如何替换证书 (sysin)，通常需要使用 CARR 脚本进行手动干预。从本版本开始，告警会引导用户前往相关的 UI 页面进行证书替换，无需再使用 CARR 脚本，使证书过期后的恢复更加简便。

有关本版本中已修复问题的列表，请参见下方“已解决的问题”。

已解决的问题

已修复问题 3585470：当 SCX Pod 崩溃、频繁重启或重新启动时，IDPS 告警“Security Services Health Degraded”未能稳定生成。

由于告警未生成，用户在 IDPS 安全服务降级时不会收到通知。

已修复问题 3604716：当 IDPS 服务（Turbo 模式）在低数据包速率（低于 1K PPS）下处理流量时，数据包会产生额外延迟。

在低流量条件下，由于每个数据包遇到额外延迟，应用响应时间可能会增加。

已修复问题 3504290：NSX Manager 节点在“start_manager”步骤升级失败。

由于 CORFU_NONCONFIG 服务器启动失败，NSX Manager 节点升级失败。在升级的“start_manager”步骤中，配置 Corfu 服务器启动时遇到竞争条件，导致 CORFU_NONCONFIG 服务器异常 (sysin)，并持续将 CORFU_NONCONFIG 状态报告为“DEGRADED”。

已修复问题 3542426：在 NSX Federation 环境中，某些罕见情况下，备用全局管理器与主全局管理器的同步状态显示为 UNAVAILABLE。

在罕见场景（例如网络抖动、领导节点切换或服务重启）下，主备全局管理器之间的同步实际上是成功的，但 active_standby_sync_statuses 显示为“UNAVAILABLE”。该问题仅影响状态显示，不影响实际功能。

已修复问题 3569783：在重新配置分布式负载均衡器（DLB）或分布式防火墙（DFW）后，部分 DLB 连接未命中预期的 DFW 规则。

重新配置 DLB 或 DFW 后，某些 DLB 连接可能不再命中之前的 DFW 规则，而是命中默认 DFW 规则。如果默认 DFW 规则的动作为丢弃，则可能导致数据包被丢弃。

已修复问题 3582922：由于来宾操作系统发送的异常 IGMPv3 数据包，ESX 主机会发生紫屏（PSOD）。

来自来宾操作系统的异常 IGMPv3 数据包在 McastFilterProcessIGMPv3Report() 中由于分组信息过大而导致 PSOD。

已修复问题 3590050：在新部署的 ESX 主机上，NSX 安装有时会失败。

当尝试在新加入的 ESX 主机上安装 NSX 时，用于将 ESX 主机加入 NSX Manager 集群的 CLI 命令可能失败，并返回错误 “curl_wrapper: (7) No APH UUID found in CheckTrusted RPC response”。

已修复问题 3617765：当规则更新使连接的当前规则失效时，Edge 上的数据路径 fastpath 线程会进入无限循环 (sysin)，导致 CPU 使用率飙升至 100%。

通过 Edge 的流量会受到影响。

已修复问题 3616400：在高流量场景下，网关防火墙 NSGroup 中频繁更新 IP 地址可能会触发 Edge 节点上的 datapath 守护进程产生 core dump。

当 datapath 守护进程因 core dump 重启时，通过 Edge 的流量会受到影响。

已修复问题 3518994：Distributed Firewall（DFW）API 在 /api/v1/infra/domains/default/security-policies/default-layer3-section/statistics 中返回错误的统计信息。

DFW 规则的字段（packet_count、byte_count、session_count、hit_count）显示了错误的统计值。

已修复问题 3614734：在频繁配置变更的情况下，竞争条件可能导致 Edge 上的 datapath 守护进程产生 core dump。

当使用已删除的安全组进行规则匹配时会触发 core dump，datapath 进程随后重启，从而影响流量。

已修复问题 3635224：新 Edge 安装、重新部署和扩容操作失败。

由于 Edge OVF 的签名证书已于 2026 年 1 月 3 日过期，导致 OVF 证书无法验证 (sysin)，新 Edge 安装、重新部署和扩容操作失败。该问题适用于通过 NSX Manager UI、NSX API、vCenter、OVF Tool 或 SDDC Manager 进行的操作。

升级到 NSX 4.2.3.3 可解决此问题。

已修复问题 3630051：在记录高流量事件时，NSX IDPS 事件日志有时缺少空白字符，影响签名映射和威胁分析。

监控团队会间歇性地收到签名名称格式异常的事件数据，从而导致 IDPS 签名映射和威胁分析出现混乱和错误。

已修复问题 3605372：在极少数情况下，超时后删除 FQDN 域条目可能导致 ESXi 主机发生 PSOD。

主机发生 PSOD 后，其上运行的虚拟机会失去网络连接。

已修复问题 3519821：在日语界面中查看 Distributed Firewall（DFW）策略规则列表时 (sysin)，规则数量显示为“{{totalRuleCount}} / {{viewedRuleCount}}”，而非实际数值。

当 NSX UI 切换为日语并进入 Distributed Firewall 策略页面查看或创建防火墙规则时，滚动规则列表，网格底部的分页/计数指示器未能将占位符替换为实际的数值。

已修复问题 3625943：将 NSX Manager 从 3.2.x 升级到 4.2.x 后，Tier-1 网关上的 DHCP 服务器因 IP 池重叠错误而处于失败状态。

在 NSX Manager UI 中，一些段仍处于 “IN-PROGRESS” 状态，所连接的 Tier-1 网关处于 “FAILED” 状态。该问题的影响仅限于 DHCP 配置更改，DHCP 服务器和 datapath 功能不受影响。

已修复问题 3516646：在 NSX Federation 中，使用 AR 通道的数据库操作出现问题。

在 NSX Federation 环境中，罕见的竞争条件可能导致 NSX 中的数据库操作出现问题，尤其是 Async-Replicator（AR）通道所使用的操作。由于 AR 通道用于全局管理器（GM）与本地管理器（LM）之间的通信，可能导致 GM 与 LM 之间的配置同步失败。

已修复问题 3619313：IpAddressAllocation 在更新完成后仍保持为 IN_PROGRESS 状态。

UI 中即使对象已完成更新，IpAddressAllocation 仍显示为 IN_PROGRESS。该问题仅为显示问题，不影响功能。

已修复问题 3626240：当 Edge 与 ESXi 主机共享同一 VLAN 用于 TEP 流量时，Edge 隧道会中断。

当跨不同主机时，Edge 隧道无法建立；当位于同一主机上时，隧道可以建立。

已修复问题 3626202：“Compute Manager Lost Connectivity” 告警未提供足够的解决指导。

在之前的版本中，该告警要求用户打开外部 KB 文档并执行多步骤操作来解决问题。

本版本增强了告警说明，通过直接引导用户前往 系统 → Fabric → Compute Managers 页面来解决问题，无需再查阅 KB 文档 (sysin)，从而提升了易用性。

已修复问题 3618724：DHCP 中继在 VPC 子网中无法按预期工作。

当用户配置带有外部 DHCP 中继配置文件的 VPC（例如指向 192.168.110.10 的 “DHCP-Server”），并创建访问模式为 “Public” 的 VPC 子网时，该子网会被自动配置为 NSX 管理的 DHCP 服务器（例如 30.30.30.50），而不是使用 VPC 级别的 DHCP 中继配置。因此，连接到该 VPC 段的虚拟机会从 NSX DHCP 服务器而非预期的外部 DHCP 服务器（192.168.110.10）获取 IP 地址。

已修复问题 3607928：在启用 ENS 的环境中，当 vNIC 端口被停用时，主机会发生紫屏（PSOD）。

在端口停用过程中，ENS 在端口分离前存在一个宽限期，在此期间 datapath 线程仍可能运行。如果在所有 datapath 线程运行完成之前宽限期结束，则会触发 PSOD。

本版本针对导致该问题的变量提供了补充修复，并包含一些增强改进。

已修复问题 3605756：在大规模部署环境中收集支持包时，ESXi 主机会发生紫屏（PSOD）。

ESXi 内核模块维护了一个内部表，用于存储主机上所有逻辑交换机和路由域中的 VTEP 联合信息，以优化 datapath 处理并提升内存使用效率。在逻辑交换机和路由域中存在超过 2048 个唯一 VTEP 的大规模环境中，执行收集支持包的命令会导致缓冲区溢出，从而引发 PSOD。

已修复问题 3601750：在重新部署 Edge 节点或集群后，Tier-1 未向 Tier-0 通告服务接口路由。

该问题适用于从 NSX-V 迁移到 NSX-T 3.2.0 或更高版本的环境，且仅影响服务端口。服务端口配置中的一个参数（管理状态）在迁移和重新部署后未被设置，NSX Manager 将其视为关闭状态，从而停止通告服务接口路由。这会导致预期通过 Tier-0/VRF 的 Tier-1 服务接口网络流量失败。

已修复问题 3603918/3601174：在配置 RSPAN Destination 时，ESXi 主机会发生紫屏（PSOD）。

在 RSPAN 过程中，会为数据结构分配内存。由于缺陷，该内存未能及时释放，最终导致内存耗尽。后续的内存分配失败会进入循环，从而导致主机 PSOD。

已修复问题 3583257：NSX Manager 节点上多个服务处于错误状态。

在基础设施高负载的罕见情况下，运行在 NSX Manager 节点上的模块可能因 org.bouncycastle.crypto.fips.FipsOperationError 异常而进入错误状态。该异常表示 BouncyCastle 的 FIPS 认证加密模块（BCFIPS）由于底层操作系统提供的熵不足（随机数不够随机），未能通过连续自检，从而初始化失败。NSX Manager 上运行的模块均为 FIPS 合规，并依赖 BCFIPS 来维持该合规性。

已修复问题 3580790：当 NSX Manager 上的 /tmp 目录已满时，备份操作失败但未指明失败原因。

备份失败时，错误信息未明确指出失败是由于 /tmp 磁盘空间已满导致的。

已修复问题 3574090：升级后，NSX Manager 节点与所有传输节点及其他管理器节点失去管理连接 (sysin)。

在升级过程中，如果在部署时启用了软件完整性检查功能，NSX Manager 节点的管理 IP 地址在重启后无法保持。

已修复问题 3567393：裸金属 Edge 的数据平面转发受影响，datapath 配置处于错误状态，且 Edge datapath 的 CLI 无法使用。

在罕见情况下，当将配置从基于 bond 的单 VTEP 更改为基于独立 pNIC 的多 VTEP 时，裸金属 Edge 节点可能出现 datapath 影响。在配置变更过程中，两个系统进程相互等待并永久阻塞，导致两个进程冻结。

已修复问题 3546893：计划任务备份未执行。

由于计划备份未运行，客户只能执行手动备份。

已修复问题 3534050：在存储故障后，Edge datapath 服务无法启动。

由于 Tx 或 Rx 环大小无效，Edge datapath 服务启动失败，导致数据平面转发完全中断。

已修复问题 3529732：NSX Manager 的 syslog 未记录 NSX 用户成功登录事件。

日志中仅记录实际操作，而未记录相对被动的登录行为。

已修复问题 3514331：在主机上使用 Broadcom 网卡承载 Geneve 流量时，当带有错误 L4 校验和的数据包通过 Tier-0 上行链路进入 Edge VM，会被错误地更新内部 L4 校验和并通过 Geneve 转发至南向的工作负载虚拟机。

客户无法通过 HTTPS 下载文件。

已修复问题 3486896：在 NSX Manager 中导航至升级页面会出现错误 “Reboot less upgrade cannot be disabled for vSphere Lifecycle Managed cluster”，且升级 API 返回 “Internal server error”。

如果将无重启升级配置设置为 false，且主机集群启用了 vLCM，则在主机计划验证阶段同步计划会失败，导致所有升级 API 失败，升级无法完成。

通过此修复，如果当前无重启配置被设置为 false，则会为启用了 vLCM 的组重置该配置。

下载地址

想要开始学习和研究？

请访问：https://sysin.org/blog/vmware-nsx-4/

相关产品：

• VMware Avi Load Balancer 30.2.5 - 多云负载均衡平台
• VMware Avi Load Balancer 31.2.1 - 多云负载均衡平台

更多：VMware 产品下载汇总

一、概述总结
智慧学堂闯关小程序是一款专为学生群体打造的在线学习工具，以趣味闯关游戏为核心形式，将刷题练习与学习视频深度结合，为用户带来沉浸式、互动性极强的学习体验。该小程序支持微信公众号部署，通过微擎系统在线交付，源码经过加密处理，保障官方正品品质。用户可通过观看学习视频积累知识后参与闯关刷题，成功通关后能直观查看任务完成度、闯关进度、排名、获取星星数、学习时长、答题量及正确率等核心数据，有效激发学习动力。

二、功能介绍
（一）核心学习功能
闯关答题体系：设置闯关大关卡与小关卡层级结构，支持按章节添加关卡，用户需依次完成关卡挑战，可重玩已闯关卡，提升学习熟练度。

学习视频联动：关卡可绑定指定视频课程（如UI设计基础视频教程），用户可先观看视频积累知识点，再参与对应关卡答题，实现学练结合。

精准知识点匹配：支持选择具体学科知识点，涵盖小学语文等多学科，可设置2级、3级细分知识点，确保答题内容针对性强。

单元测试模式：支持将关卡设为单元测试，无需绑定新知识点，自动调用前期知识点题库生成题目，方便阶段性检测学习效果。

（二）数据统计与反馈功能
多维数据展示：实时呈现闯关进度（如8/20）、任务完成度排名、满星通关关卡数、学习时长（如0/60m）、答题量、正确率（如36.7%）等核心数据，让用户清晰掌握学习情况。

答题结果解析：闯关结束后可查看详细答题结果，包括答对答错题目分布、正确答案及个人作答情况，支持查看解析，帮助用户查漏补缺。

全站统计分析：提供作答次数、正确率、易错项等全站数据统计，为用户优化学习重点提供数据支撑。

（三）后台管理功能
闯关管理：支持添加闯关题库、设置题库标签，可自定义关卡名称、描述、顺序，配置关卡所需钻石数（用于跳过章节），灵活控制关卡是否上架。

订单管理：完善的订单管理体系，方便运营者跟踪产品使用相关订单信息。

权限与配置：支持设置操作员权限，系统可自动生成关卡数、星星（积分）总数，支持多标签分隔配置，满足多角色协作管理需求。

（四）特色功能
积分激励机制：闯关成功可获取星星（积分），通过积分累计激发用户持续学习的积极性。

灵活跳过机制：部分章节可花费指定钻石跳过，满足用户多样化学习节奏需求。

多场景适配：题库涵盖教育学、心理学、教育心理学、小学语文等多学科，支持教师招聘、中小幼等不同学习场景使用。

三、适用场景与行业价值
（一）适用场景
教育培训机构：可作为课后练习工具，配合线下课程设置闯关题库，帮助学员巩固知识点，提升学习效果。

学校教学辅助：教师可利用小程序布置课后作业、单元测试，通过闯关形式激发学生学习兴趣，减轻教学管理压力。

备考人群自学：针对教师招聘等备考场景，提供细分学科题库，用户可通过闯关刷题系统梳理知识点，提升应试能力。

课外兴趣学习：适用于中小学生课外知识拓展，通过趣味闯关培养自主学习习惯。

（二）行业价值
对学习者：打破传统刷题的枯燥感，以游戏化形式提升学习兴趣，通过多维数据反馈明确学习短板，实现高效针对性学习；灵活的学习模式适配不同学习节奏，支持随时随地碎片化学习。

对教育机构/学校：降低教学管理成本，通过后台系统实现题库、关卡的快速配置与管理，实时掌握学员学习数据，便于优化教学方案；提升教学服务质量，增强学员粘性与满意度。

对行业发展：推动教育数字化、趣味化转型，将游戏化思维与教育场景深度融合，为在线教育行业提供创新的产品形态与运营思路。

四、问答环节
问：智慧学堂闯关小程序支持哪些部署环境？

答：支持PHP5.5、PHP5.6、PHP7.1、PHP7.2、PHP7.3多种环境部署，适用微信公众号使用。

问：小程序的闯关形式具体是怎样的？

答：采用大关卡+小关卡的层级结构，用户可先观看绑定的学习视频，再参与对应知识点的闯关刷题，通关后可查看任务完成度、进度排名、星星积分等数据，支持重玩已闯关卡。

问：后台能否自定义题库和关卡？

答：可以，后台支持添加闯关题库、设置题库标签，可自定义关卡名称、描述、顺序、所需钻石数等，还能选择绑定视频课程和具体知识点，支持设置单元测试关卡。

问：小程序的积分机制是怎样的？

答：用户闯关成功后可获取星星（积分），星星总数由系统自动生成，通过积分激励用户持续参与闯关学习。

问：单元测试关卡与普通关卡有何区别？

答：测验关卡无需绑定知识点，系统会自动使用前面章节的知识点题库生成题目，适合用于阶段性知识检测。

问：小程序的题库涵盖哪些学科和场景？

答：题库涵盖教育学、心理学、教育心理学、小学语文等多学科，适用于教师招聘、中小幼等不同学习场景，支持多等级知识点细分。

摘要：
2025 OceanBase 年度发布会金融专场，盛京银行信息科技部数据库负责人王克东分享了该行引入 OceanBase 的数据库升级实践。盛京银行依托 OceanBase 的技术能力，重点借助其 HTAP 能力，完成了从传统集中式架构到统一数据平台的全栈升级，在混合负载场景下批处理能力提升 80%，同时大幅降低了软硬件投入成本。

11 月 18 日，2025 OceanBase 年度发布会在北京举行。在金融专场，盛京银行信息科技部数据库负责人王克东进行专题分享，介绍盛京银行在数据库升级过程中引入 OceanBase 后的应用实践。

他表示，近年来，盛京银行依托 OceanBase 各项能力，尤其是 HTAP 能力，完成从传统集中式架构到统一数据平台的全栈升级。在这一过程中，盛京银行最大的惊喜来自 OceanBase 的 HTAP 能力，混合负载场景下批处理能力提升 80%，软硬件投入成本得到大幅降低。

以下为演讲实录。

大家好，我是盛京银行信息科技部数据库负责人王克东，今天很荣幸在这里分享盛京银行在数据库升级过程中的一些经验。

盛京银行总部位于辽宁省沈阳市，前身为沈阳市商业银行。2007 年 2 月，经中国银监会批准更名为盛京银行。盛京银行目前已在沈阳、北京、上海、天津、长春、大连等城市设立了 18 家分行，拥有 3 家专营机构和 2 家子公司，是东北地区规模最大的城商行。

这几年来，我们依托 OceanBase 数据库各项能力，尤其是 HTAP 能力，完成从传统集中式架构到统一数据平台的全栈升级。今天的分享，我将着重介绍盛京银行在数据库选型过程中的一些思考和经验、实际改造案例、在 OceanBase 数据库上的架构实践以及我个人对盛京银行未来数据库建设的一些展望和思考。

选型之路：为何选择分布式数据库?

在数据库选型上，我们面临的第一个问题是：选择集中式数据库还是分布式数据库？

随着互联网金融的快速发展，我们发现许多线下业务正在加速向线上转移，这也意味着未来数据库将承担更大的压力。因此，我们首要确定的方向就是选择分布式数据库，以应对日益增长的业务需求。

下一个问题随之而来：选哪一个分布式数据库产品？我们主要从四个方面进行综合考量。

首先，在核心技术自主研发的大背景下，我们倾向于选择原生的分布式数据库；第二，要有丰富的案例沉淀，有大量成功案例可供借鉴参考；第三，产品需具备高可用和完善的容灾架构，以保障业务的连续性和安全性；第四，该产品应拥有完善的周边生态，能够满足我们日常运维管理的需求，否则未来运维会面临诸多挑战。

基于上述思考，我们正式踏上了数据库选型之路，并首先对系统建设进行了需求分析。在这一过程中，我们积极走访了多家已成功升级改造的银行，与他们进行了深入交流。随后，针对实际业务场景设立测试案例，邀请头部数据库厂商与分布式数据库厂商到盛京银行进行实际测试。测试内容主要涵盖数据库自身的性能、高可用性、容灾能力、周边生态工具的完善度，以及在开发侧需要进行改造的内容。我们也重点关注在升级过程中可能遇到的各类问题。

经过约半年的测试和综合评估，我们最终选择 OceanBase 作为盛京银行的数据底座，原因在于以下几点：

首先，OceanBase 具备高兼容性，尤其是对传统数据库的全兼容。盛京银行原有的所有数据库均采用传统数据库，OceanBase 在兼容性上的优势极大降低了开发侧的改造成本，有效节省了大量人力和资源，实现了系统的平滑升级，个别业务系统仅需进行少量代码改动；

第二，OceanBase 在成本方面也表现突出。它让我们能够摆脱高昂的存储费用，同时凭借高压缩比，显著节约了存储空间；

第三，OceanBase 强大的 HTAP 能力给我们留下了深刻印象。在测试过程中，OceanBase 不仅在传统 TP 场景中展现了优秀的性能，在 HTAP（混合事务与分析处理）更为惊艳。尤其是在反洗钱批量处理系统等业务场景中，OceanBase 的测试结果遥遥领先。

此外，OceanBase 具备良好的水平扩展能力，可以满足我们不断增长的业务需求，其高可用和容灾架构也充分保障了业务的连续性和安全性。同时，OceanBase 拥有丰富的案例积累，为我们的推进和落地提供了宝贵参考。

落地实践：两个阶段持续夯实数据库底座

盛京银行整个升级过程主要分为两个阶段。

第一阶段，我们采用主备中心互为主备的架构，通过数据复制方式实现容灾，每个中心的 OceanBase 集群均具备高可用性。在架构搭建完成后，我们利用 OMS 迁移工具，通过“全量+增量”方式将数据升级到 OceanBase 。由于 OceanBase 与原数据库高度兼容，我们众多业务系统实现了平滑升级，且升级后只需更换连接驱动即可对外提供服务。此阶段，我们还充分发挥了 OceanBase 的多租户能力，建设一个集群，通过多租户模式支持多套业务系统，对外提供服务，有效节约了资源和运维成本。

第二阶段，随着第三机房的正式启用，我们将原有主备模式的容灾架构在线升级为三中心五副本架构。此次架构调整充分利用了 OceanBase 的在线扩缩容能力，实现了无业务中断的平滑升级。三中心五副本架构不仅进一步增强了系统的可靠性和容灾能力，也成为盛京银行未来数据库发展的确定方向。在去年金融电子化优秀案例评选上，凭借这一创新架构，我们荣获了科技创新奖。

通过以上两阶段的实践，我们不断夯实了盛京银行的数据库底座，为业务发展和创新提供了坚实保障。

升级成效：最大惊喜来自 HTAP 批处理能力提升 80%

数据库升级至OceanBase 后，我们最大的惊喜来自 OceanBase 的 HTAP 能力，混合负载场景下批处理能力提升 80%，软硬件投入成本得到大幅降低。

成效主要体现在以下方面，将用两个案例来说明。

首先，要重点介绍的是 OceanBase 的 HTAP 能力在反洗钱系统中的应用。

该系统原先批量处理通常需要约 20 个小时。数据库改造并升级至 OceanBase 后，批量处理时间缩短至 8 个小时。这只是改造的第一步，随着 OceanBase 升级到第四代版本后，批量处理时间又进一步降至 6 个小时。可以看出，OceanBase 每一代版本在性能方面都在持续提升，极大优化了我们的业务效率。

第二个案例是我们通过架构改造后带来的灾备切换效率提升。众所周知，金融机构每年都需要按监管要求进行同城灾备环境的切换演练，确保关键业务系统可以在灾备环境下全部接管主业务。以前在主备模式下，每次切换都需要针对整个集群及其所有业务系统进行验证，有的系统属于监管范围，有的则并非强制要求，这就导致我们要对所有业务系统进行切换测试，既耗时又影响正常运营。

而在我们全面升级为“三中心五副本”架构后，灾备切换效率有了质的提升。对于需要满足监管要求的业务系统，我们可以灵活地通过租户形式，将系统从同城中心切换到主中心，或者反向切换至同城中心。

“三中心五副本”的架构下，整个大集群中的主中心和同城灾备中心的数据库节点及服务器都能够同时对外提供服务。而在原有主备模式下，只有主中心具备对外服务能力，同城中心的数据库服务器及节点处于闲置状态。新的架构大大提升了资源利用率，实现了数据库和服务器资源的高效使用。

以上两个案例，不仅体现了 OceanBase 在性能和可靠性上的优势，也为盛京银行数据库建设和金融业务创新带来了实实在在的价值。

总结数据库升级后的收益，主要体现在以下几方面：

首先，是显著的稳定性提升。高可用架构保障了我们业务系统 7×24 小时不间断运行；其次，运维便利性得到了极大提升，切换演练过程通过 COP 工具实现一键切换，租户级别的切换平均每个租户用时仅需约 5 秒；第三，架构升级后带来了明显的性能提升，尤其是在 HTAP 能力方面，批量处理和报表生成时间大幅减少。成本方面的优化主要体现在服务器和存储资源的节约。同时，先进的三中心五副本架构也进一步保障了数据库的安全。

未来规划：持续携手 OceanBase 迈上新台阶

对于盛京银行未来数据库建设的规划，结合个人思考，我有以下几点看法：经历了数据库升级后，我们在技术层面得到了显著提升，积累了大量技术经验。这不仅体现在数据库层面，更包括了服务器、网络、操作系统以及开发侧的全栈式提升。

如今，盛京银行现有关键业务系统已逐步升级至 OceanBase，新建业务系统也直接以 OceanBase 为底座上线。

展望未来，我希望根据业务条线和系统类型，进行多维度的业务划分，建立多套 OceanBase 数据库集群，实现分类管理，避免“鸡蛋放在一个篮子里”，从而提升系统的灵活性与安全性。

目前，盛京银行正在开展 OceanBase 一体机以及 4.3.5 版本的相关测试，意在进一步提升 HTAP 场景下的业务处理效率。4.3.5 版本在列存 AP 能力上有所优化。今年的年度发布会，OceanBase 发布了 4.4 版本，未来我们也将计划对该版本进行进一步测试和评估。

希望能够充分借助 OceanBase 的领先技术，持续赋能盛京银行科技平台，通过技术驱动业务创新和发展，助力盛京银行业务持续迈上新台阶。

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/

摘要：
中国联通使用的传统集中式数据库面临高并发、扩展难、运维复杂等痛点，于是其与 OceanBase 构建“企业版核心承载 + 社区版自主创新” 双轨体系，现已全面覆盖联通 B 域（业务支撑）、O 域（运营支撑）、M 域（管理支撑）全场景。其中，OceanBase 企业版攻克运营商最核心的B域40% 生产系统，支撑全球最大规模 “全国大集中” 核心业务。

当超 4 亿用户的通信消费、5G 服务、政企业务全部汇聚于 “全国一套系统”，当传统数据库的性能瓶颈，遭遇数字时代的 “数据海啸”，自研数据库如何扛起全球最复杂的电信核心业务？

近日，中国联通软件研究院（简称 “联通软研院”）与 OceanBase 的四年深度合作交出了震撼行业的答卷：

双方打造的 “企业版核心承载 + 社区版自主创新” 双轨体系，已全面覆盖联通 B 域（业务支撑）、O 域（运营支撑）、M 域（管理支撑）全场景，累计部署节点超 1000个。其中，OceanBase 企业版攻克运营商最核心的 B 域 40% 生产系统，支撑全球最大规模 “全国大集中” 核心业务；基于OceanBase 社区版自研的 CUDB 数据库规模化上线数百套系统，更以 AI 向量数据库创新应用 ChatDBA，为运营商智能化转型提供了可复用的创新方案。

这场合作见证了自研数据库技术从 “入局” 到 “破局” 再到 “引领” 的华丽转身。

破局 “全国大集中”：超 4 亿用户核心系统的分布式升级革命

在电信行业 “省集中” 为主流的格局下，中国联通率先推行 “全国大集中” 战略，以一套 cBSS 系统承载 31 省全业务、全客户、全渠道服务，支撑超 4 亿用户的 CRM、计费、结算等核心场景 —— 这是全球电信行业单体承载用户最多、集中化程度最高的业务支撑系统，其技术升级难度堪称 “在飞行的飞机上换引擎”。

此前，该系统长期依赖传统集中式数据库，即便后续升级为 “中间件 + 数据库” 架构，仍面临高并发性能瓶颈、扩展性不足、运维复杂等致命痛点：月初缴费高峰时 “一省慢、全国卡”，5000 万用户基数就触达集中式数据库性能上限；31 省业务 “共性收敛与个性保留” 难以平衡；复杂存储过程与多数据库类型导致升级改造难如登天。

OceanBase 的分布式架构成为破解困局的关键。作为 “全国电信唯一大集中核心业务支撑系统国产升级” 案例，OceanBase 企业版通过三大核心能力实现突破：

一是 “两地三中心” 部署模式，以Paxos 协议分布式一致性机制，实现 RPO=0（数据零丢失）、RTO<30秒的金融级容灾，相比传统集中式数据库的主备架构，容灾建设成本降低 50% 以上，支撑核心业务全年 7×24小时无间断运行；

二是多租户弹性扩缩容技术，将全国上千个节点物理资源池化，按业务需求动态分配 CPU、内存、IO，彻底解决资源争抢问题，计费中心查询性能提升 60%，政企中台并发处理能力翻倍，资源利用率从不足 40% 跃升至 80% 以上，硬件成本降低 60%；

三是深度兼容特性，完美适配 MySQL 与 Oracle 语法，让复杂存储过程、冷僻 SQL 语句无需大幅改写，实现 ERP 系统零改造平滑升级，B 域核心系统整体升级改造成本降低 70%。

更具创新性的是，基于 OceanBase 多租户能力构建的 “一库多服” 架构：通过镜像库将 10 余个业务中心的高负载查询请求从生产库剥离，既保障 “全国一套账” 的统一管理，又能灵活响应各省 5G 用户增长分析、政企客户关联图谱等个性化需求，仅用 1 周就完成所有数据库升级同步，成为支撑业务运营的数据枢纽。

自主创新加码：CUDB 引领开源生态规模化落地

在核心业务升级的同时，联通软研院并未止步于 “使用者” 角色，而是向 “开发者”“创新者” 转型。

2021 年 OceanBase 开源后，联通软研院仅用 13 个月就完成社区版深度优化，打造出分布式 HTAP 数据库产品分布式 CUDB，成为基于 OceanBase 社区版的最大规模应用案例。截至 2025 年 6 月，分布式 CUDB 已承载数百个业务应用，部署节点超 200 个，管理原始数据量近 300TB，广泛覆盖 O 域、M 域各类场景。

为解决传统 MySQL 多版本分散、升级低效的痛点，自研 MySQL 与分布式 CUDB 双向数据迁移工具，实现 10 万条 / 秒的升级速度 —— 这是社区版 OMS 的 3 倍、同类产品 DataX 的 5 倍，已累计完成 25TB + 数据升级，兼容性与效率均处于行业领先水平。

同时，分布式 CUDB 全面接入联通云，实现 “一点开通、一点交付、一点监控、一点运维、一点操作” 的一站式服务，大幅提升云租户使用体验与运营效率。更值得关注的是，联通软研院在合作中累计向 OceanBase 开源社区贡献代码超万行，输出数据库事务日志精准恢复、云存储备份对接等核心能力，实现 “使用开源、贡献开源” 的良性循环，推动数据库生态协同进化。

AI + 数据库融合：ChatDBA 树立智能化转型新范式

2025 年，AI 成为数字化转型的核心驱动力，中国联通软研院聚焦 AI 向量数据库等前沿领域，基于 OceanBase 完成数据库智能专家 ChatDBA 的底层架构升级，破解了大模型落地的关键痛点。作为基于 RAG（检索增强生成）技术构建的 AI 应用，ChatDBA需整合海量数据库专业知识与运维经验，传统架构存在扩展性不足、运维复杂、资源利用率低等问题。

经过对主流向量数据库的全面测评，OceanBase 的一体化能力脱颖而出：其支持关系型数据、向量数据等多类型数据混合存储查询，可处理最高 16000 维稠密向量，在 768 维 100 万数据集下检索性能是主流向量数据库的 3-6 倍；分布式架构保障高并发与故障自动恢复，多租户技术实现资源隔离，搭配完善的管控与迁移工具，大幅降低运维成本。

依托这些优势，ChatDBA 仅用两周就完成适配改造，硬件资源成本直降 30%，运维人力成本同步降低，问题解决效率显著提升，成为运营商领域 “AI + 数据库” 深度融合的标杆范例。

从核心业务分布式升级的 “破冰”，到开源生态自主创新的 “深耕”，再到 AI 一体化架构的 “引领”，中国联通软研院与 OceanBase 的合作不仅实现了量化的降本增效，更构建了 “自主创新、安全稳定、智能高效” 的数字基建新范式。

联通软研院相关负责人表示，未来将持续扩大合作范围，深化向量数据库、多模数据融合等领域创新。OceanBase 也将以此次合作为基础，持续迭代升级，适配电信行业核心需求。

这场跨越四年的深度合作，不仅为中国联通 “数字服务使能者” 转型筑牢技术底座，更向全行业证明：自研数据库已具备支撑全球最复杂核心业务的能力。

这一点在 OceanBase 过去五年的实践中得以充分验证：自 2020 年商业化以来，OceanBase 已在运营商领域实现从“点上突破”到“面上开花”的转变，深度服务中国联通、中国移动、中国电信三大运营商，覆盖 B/O/M 全业务域。在今年 9 月举行的中国通信展上，凭借在通信行业扎根沉淀的实践优势和技术创新能力，OceanBase 联合运营商打造的五个标杆案例获得由中国通信企业协会评选的“一等案例”荣誉。这些成绩的背后，是 OceanBase 作为运营商“可信赖基石”地位的奠定。

当每一通电话、每一笔交易、每一次 AI 交互都运行在自主研发的数据库上，我们看到的不仅是技术自立自强的硬核实力，更是数字化的坚实底气 —— 自研数据库正在从幕后走向台前，重新定义数字时代的数据库核心标准。

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/

随着制造业数字化转型的加速，CRM系统已成为企业提升客户管理效率、优化销售流程、实现业务增长的关键工具。面对市场上琳琅满目的CRM产品，如何选择适合自身需求的系统，成为制造企业管理层关注的焦点。本文综合Gartner、IDC、Forrester、36氪、钛媒体等权威机构和媒体的评测，深度解读2026年制造业CRM系统排行榜，并为不同规模的企业提供选型建议。

一、制造业CRM系统市场概览

制造业CRM系统不仅仅是客户关系管理工具，更是企业数字化转型的核心引擎。根据Gartner《2025-2026全球CRM市场报告》，制造业CRM市场预计将以年均12.8%的速度增长，智能化、自动化、集成化成为主流趋势。权威机构Forrester也指出，制造业CRM系统正在从传统的客户管理向全流程营销、售后服务、供应链协同等方向扩展。

市场主流CRM系统评选标准

• 功能完善度（客户管理、销售自动化、数据分析等）
• 行业适配能力（制造业专属流程、定制化能力）
• 用户体验（界面友好度、操作便捷性）
• 集成能力（与ERP、MES等系统对接）
• 服务与支持（本地化服务、技术支持）

二、2026年制造业CRM系统排行榜（权威评测）

以下表格综合Gartner、IDC、Forrester等机构2026年最新评测数据，列举六大主流制造业CRM平台，并给出适用企业类型及核心优势。

数据来源：Gartner、Forrester、IDC、36氪、钛媒体等2026年CRM行业报告

三、六大制造业CRM系统深度解析

1. Zoho CRM——中大型制造企业首选

权威推荐理由：

• 智能自动化：Zoho CRM集成AI助手Zia，支持自动化线索分配、销售预测、客户画像分析，大幅提升销售团队效率。
• 深度集成：可与ERP、MES、SCM等制造业核心系统无缝对接，实现数据闭环。
• 全球化与本地化兼备：支持多语言、多币种，适合跨国制造集团，同时在中国设有本地服务团队。
• 高度定制化：流程、字段、报表均可自定义，灵活适应复杂制造业务。

权威点评：
Gartner 2026年报告中，Zoho CRM凭借“极高的行业适配度和智能化水平”，成为制造业CRM领域领导者。Forrester也指出其“性价比极高，适合成长型和成熟型制造企业”。

2. Salesforce——全球化大企业优选

• 强大生态系统：AppExchange平台提供数千种扩展应用，助力制造企业多元发展。
• 智能分析与自动化：Einstein AI赋能销售预测、客户洞察，支持全球化业务管理。
• 行业解决方案丰富：专为制造业定制的Cloud for Manufacturing，支持供应链协同和售后服务。

权威点评：
IDC、Gartner均将Salesforce列为“全球CRM市场领导者”，但在本地化和定制化方面略逊于Zoho CRM。

3. SAP C4C——ERP集成专家

• 供应链全流程打通：与SAP ERP、SAP MES无缝集成，支持生产、库存、订单等数据同步。
• 强大数据分析能力：内置BI工具，助力制造企业精细化运营。
• 安全与合规保障：全球化合规体系，适合大型制造集团。

权威点评：
Forrester认为SAP C4C在“制造业数据集成和流程管控”方面优势突出，适合对ERP集成要求极高的大型企业。

4. Zoho Bigin——中小制造企业极简首选

• 极简操作界面：上手快，无需复杂培训，适合小型制造企业快速部署。
• 核心功能覆盖：客户管理、销售流程、数据报表一应俱全，性价比极高。
• 移动端强大：支持手机、平板操作，外勤销售人员管理更便捷。

权威点评：
36氪、钛媒体评测认为Zoho Bigin是“中小制造企业数字化转型的最佳入门级CRM”，尤其适合预算有限、团队规模较小的企业。

5. 纷享销客——中国本地化中小企业优选

• 本地化服务领先：深耕中国市场，支持微信、钉钉集成，适应国内制造业业务场景。
• 移动办公能力强：移动端功能完善，支持销售、售后、客户服务一体化管理。
• 高度可扩展性：API开放，支持与第三方系统对接。

权威点评：
钛媒体、36氪多次将纷享销客评为“中国制造业CRM创新先锋”，在本地化和服务响应速度上表现突出。

6. 销售易——销售自动化专家

• 销售流程自动化：从线索获取到订单管理全流程自动化，提升销售团队效率。
• 私有化部署能力强：支持本地部署，满足数据安全和合规要求。
• 行业扩展性强：支持制造业定制化开发，适应复杂业务流程。

权威点评：
销售易在36氪、钛媒体2026年评测中被誉为“中小制造企业销售自动化标杆”，尤其适合对数据安全有较高要求的企业。

四、制造业CRM系统选型建议

不同规模企业如何选择？

• 中大型制造企业：
  首选Zoho CRM、Salesforce、SAP C4C。
  这三款系统功能全面，支持复杂流程和深度集成，适合管理多业务、多部门、多地区的制造企业。
• 中小型制造企业：
  推荐Zoho Bigin、纷享销客、销售易。
  这三款系统部署快、易用性强，性价比高，适合资源有限、快速发展的制造企业。

CRM系统部署模式建议

五、权威机构观点汇总

• Gartner：制造业CRM系统已成为企业数字化转型的核心，智能化和集成化是未来发展方向。
• Forrester：Zoho CRM、SAP C4C在制造业行业适配度和智能化水平上表现突出。
• IDC：中小企业CRM市场增长迅速，Zoho Bigin、纷享销客等本地化产品优势明显。
• 36氪、钛媒体：中国制造业CRM创新持续涌现，移动化、本地化成为中小企业选型重点。

六、结语

2026年制造业CRM系统市场竞争激烈，企业需根据自身规模、业务需求和数字化战略，选择最适合的CRM平台。Zoho CRM凭借智能化、集成化和高度定制化，成为中大型制造企业的首选；Zoho Bigin、纷享销客、销售易则以易用性和本地化优势，助力中小制造企业高效成长。
未来，CRM系统将持续赋能制造业，推动企业实现客户价值最大化与业务创新。

FAQ

Q1：制造企业选择CRM系统时，最关键的考量因素有哪些？
A：建议重点关注行业适配度、系统集成能力、数据安全、用户体验和服务支持。制造业流程复杂，需选择能深度定制和集成的CRM系统。

Q2：Zoho CRM与Zoho Bigin有什么区别，如何选型？
A：Zoho CRM面向中大型企业，功能全面、支持复杂流程和深度集成；Zoho Bigin则主打极简操作和快速部署，适合中小企业或CRM初次尝试者。

Q3：中小制造企业如何快速上线CRM系统？
A：建议选择云部署的CRM产品，如Zoho Bigin、纷享销客、销售易，通常一周内即可上线，且无需复杂IT运维，性价比高，支持移动办公。

参考资料：
Gartner《2025-2026全球CRM市场报告》、Forrester《CRM行业评测2026》、IDC《中国制造业CRM市场分析》、36氪、钛媒体等权威媒体评测数据。

很多人其实都遇到过类似问题：明明只是随手打开一个网站，结果却发现自己的IP 地址被识别得一清二楚，地区、运营商，甚至访问环境都暴露了。

如果你经常做跨境业务、投放广告、账号运营，或者对隐私比较敏感，那 IP 地址泄露绝对不是一件小事。

这篇文章我就结合实际使用经验，聊聊 IP 地址为什么会泄露，以及 5 个实用步骤，教你尽量隐藏真实 IP，顺带把一些常见的坑一次性讲清楚。

一、先搞清楚：你的 IP 到底有没有泄露？

在处理问题之前，第一步一定是确认问题是否存在。

最简单的方式，就是做一次 在线IP检测。
通过常见的 IP地址查询 / 在线IP查询 网站，你可以快速看到：

当前显示的 IP 地址

所属国家和城市

网络类型（住宅 / 数据中心）

运营商信息

如果你明明开着代理、加速器，但在线IP查询结果依然显示的是你真实所在地，那基本可以确定：
👉 IP 没有被有效隐藏，或者代理已失效。

很多新手就是卡在这一步，误以为“连上了就安全”，结果账号一注册就被风控。

二、只隐藏 IP 还不够，浏览器也在“出卖你”

这是一个非常容易被忽略的点。

即便你成功更换了 IP，但如果浏览器环境一致，网站依然可以通过 浏览器指纹检测 来识别你。

浏览器指纹通常包括：

User-Agent

时区、语言

屏幕分辨率

WebGL、Canvas

字体、插件信息

这些信息组合在一起，几乎就像“设备身份证”。
所以你会看到一种情况：

IP 换了，但账号还是被关联、被限制。

在操作前，先用 ToDetect指纹查询做一次检测，看清楚自己暴露了哪些维度，而不是只盯着 IP 不放。

三、步骤一：选择稳定、干净的代理 IP

如果你确实需要隐藏真实 IP，那么代理 IP 的质量非常关键。

简单说几个经验点：

不要贪便宜：大量共享 IP 很容易被标记

尽量选择住宅IP或高质量静态IP

不要频繁切换同一地区的 IP

一个账号 ≈ 一个 IP，别图省事

你可以在每次更换后，重新做一次 在线IP检测，确认显示的地址、地区是否和你预期一致。

四、步骤二：配合防指纹浏览器使用

这是很多老手都会做的一步。

单纯用普通浏览器 + 代理 IP，很容易被浏览器指纹检测识别。
更稳妥的做法是：

使用防指纹浏览器

每个环境独立指纹参数

IP、指纹、账号三者保持一致

配置完成后，建议再用 ToDetect指纹查询一遍，确认指纹唯一性是否合格。

这一步虽然稍微麻烦点，但对账号安全帮助非常大。

五、步骤三：避免这些“无意识泄露 IP”的行为

很多 IP 泄露，其实不是技术问题，而是操作习惯问题：

登录账号后切回真实网络

同一浏览器登录多个账号

开着代理访问国内站点

插件、脚本随意安装

这些行为都会增加被识别的概率。
建议你把操作流程固定下来，不要频繁“临时切换”。

六、步骤四：定期检测，而不是出事才查

IP 和指纹环境不是“一次配置，永久安全”。

建议你养成习惯：

每次重要操作前，做一次 IP地址查询

定期跑 浏览器指纹检测

发现异常，第一时间更换环境

很多封号、限制，其实都是小问题长期累积的结果。

七、写在最后：IP 只是基础，环境一致性才是关键

总结一句话：隐藏 IP 只是第一步，真正决定安全的是整体环境是否“像一个正常用户”。

如果你只是普通上网，简单注意隐私就好；但如果你涉及账号运营、跨境平台、多账号操作，那就一定要系统性地看待 在线IP查询 + 浏览器指纹检测这件事。

希望这篇文章，能帮你少踩一些坑，也少交点“学费”。

如果你后面还想了解 IP 类型区别、防关联原理、指纹参数怎么调更合理，也可以再慢慢深入研究。

本文首发于 Aloudata 官方技术博客：《监管质询时说不清字段来源？表级血缘的「最后一公里」困局》转载请注明出处。

摘要：在金融强监管背景下，传统表级血缘因精度不足，无法满足监管对指标口径和字段来源的精准追溯要求，导致数据团队陷入低效的“考古式”排查。本文深入探讨了数据治理中“最后一公里”的困局，并介绍了如何通过算子级血缘和主动元数据技术，实现监管指标的自动化盘点与精准溯源，将盘点周期从数月缩短至小时级，有效支撑 DataOps 流程与合规风控。

在金融强监管时代，当监管机构质询“EAST 报表中的‘对公贷款余额’具体计算口径是什么？是否剔除了关注类贷款？”时，数据团队常常无法快速、准确地给出答案。传统的表级血缘或列级血缘工具，因其固有的精度局限，在应对这类需要穿透复杂业务逻辑的“灵魂拷问”时，往往止步于“最后一公里”。本文将剖析这一困局，并阐述通过算子级血缘实现自动化、精准化数据溯源的技术路径与实践价值。

一、 场景挑战：监管的“字段级”追溯与数据团队的困境

随着监管要求从“表级”深入到“字段级”和“口径级”，传统粗粒度的血缘管理方法已完全失效。核心痛点表现在：

• 认责与溯源压力：毕马威等机构报告指出，监管报送（如“一表通”）的核心难点在于“压实数据项级认责”和“构建溯源能力”。监管要求每个上报的数据项都能清晰定位到源系统、加工逻辑和责任人。
• 低效的“考古式”排查：面对口径质疑或数据异常，数据团队往往需要通宵达旦，人工翻阅大量 Excel 表格、SQL 代码和文档，进行一场跨越数十个系统的低效“考古”，不仅耗时数周，且极易出错，带来巨大的合规风险与潜在罚款。

二、 传统表级血缘为何在监管场景下“哑火”？

表级血缘因解析精度不足、无法覆盖复杂逻辑、且维护滞后，在需要精准解释的监管场景下价值有限。

核心局限：当被问及“指标是否包含特定条件（如已核销贷款）”时，表级血缘无法穿透CASE WHEN、子查询等复杂加工逻辑，而这正是监管质询的核心关切。

三、 破局关键：算子级血缘与主动元数据平台

要打通监管溯源的“最后一公里”，必须将血缘解析精度从“表级”提升至“算子级”。算子级血缘能够深入解析 SQL 脚本中的每一个操作步骤（如 Filter 过滤、Join 关联、Aggregation 聚合），实现字段级、可解释的端到端白盒化追溯。

以 Aloudata BIG 主动元数据平台为例，其核心技术能力包括：

1. 高精度算子解析：基于 AST（抽象语法树） 进行完整 SQL 解析，准确率超 99%，而非简单的正则匹配。
2. 行级裁剪：精准识别 SQL 中的过滤条件，在上游变更影响分析时，能自动剔除无关数据分支，将评估范围降低 80% 以上，避免过度告警。
3. 复杂场景全覆盖：特别强化对 DB2、Oracle 等 PL/SQL 存储过程的解析能力，攻克银行核心监管报表的溯源盲区。
4. 白盒化口径提取：通过“一键溯源”功能，自动将跨越多层（ODS->DWD->DWS）的复杂加工逻辑，提炼成一段简洁、业务可读的“加工口径”描述。

四、 实践验证：从“数月”到“小时”的效能革命

头部金融机构的实践证明了算子级血缘在应对监管、提升效能方面的显著价值：

这些案例共同验证，高精度算子级血缘是实现自动化资产盘点和全链路主动风险防控、应对监管质询、提升数据可信度的关键技术路径。

五、 实施路径建议

金融机构可遵循“聚焦场景、快速验证、融入流程”的路径，稳步构建能力：

1. 锚定场景：选择 1-2 个核心且痛苦的监管报送流程（如 EAST、1104）作为试点，聚焦其中几十个关键指标。
2. 能力验证：利用平台的“一键溯源”功能，快速生成试点指标的完整加工口径和血缘图谱，与现有知识核对，验证准确性(>99%)与效率提升（从月到小时）。

3. 融入流程：将自动化溯源能力嵌入 DataOps 流程：

   • 事前：上线前自动评估变更影响，精准定位风险。
   • 事后：报表异常时，分钟级穿透定位问题根因。
   • 变“被动响应监管”为“主动防控风险”。
4. 组织保障：建立业务、科技、数据、合规的联合团队，并将数据溯源能力建设成效纳入相关考核，形成治理闭环。

六、 常见问题（FAQ）

Q1: 表级血缘和算子级血缘的核心区别是什么？

表级血缘描述数据在“表”之间的流动，如同知道货物在仓库间转运；算子级血缘则精确记录 SQL 内部的每一个操作步骤（如过滤、连接、聚合），如同清楚货物在流水线上的具体加工过程。后者对于需要精确口径追溯的监管场景至关重要。

Q2: 我们的监管报表由存储过程生成，传统工具解析不了，怎么办？

先进的主动元数据平台（如 Aloudata BIG）具备解析复杂场景的能力，包括对 DB2、Oracle、GaussDB 等 PL/SQL 存储过程的深度解析。

Q3: 建设这种精准溯源能力，投入和周期是否很长？

并非如此。建议从小范围高价值场景试点开始。例如，针对几十个核心监管指标进行自动化盘点，利用“一键溯源”功能，可能在几天内就能看到显著成果（如从数月缩短到 8 小时）。快速验证价值后，再逐步推广，可有效控制投入风险。

Q4: 除了应对监管，高精度数据血缘还有哪些业务价值？

价值广泛，主要包括：1) 变更风控：精准评估上游变更对下游的影响，避免资损；2) 根因定位：快速定位数据异常源头，提升排障效率；3) 成本治理：识别冗余计算与无效模型，优化资源；4) DataOps 协同：作为研发流程的“控制流”，提升交付效率与质量。

本文首发于 Aloudata 官方技术博客，查看更多技术细节与案例：https://ai.noetl.cn/knowledge-base/regulatory-inquiry-table-l...