10 亿级数据跑不动？联通基于隐语 SCQL 在生产环境的“性能优化与避坑指南”

本文整理自对话生产用户联通软研院，介绍了基于隐语（SecretFlow）的引入、调研、落地过程中的关键决策与实战经验。从需求梳理到架构选型，再到对 SCQL 二次开发、系统解耦、数据源扩展与性能优化的探索，联通团队不仅探讨了关于大规模业务场景的隐私计算如何落地，也为后续在可信数据空间建设中的推广应用提供了重要参考。

技术背景及痛点

其实要说起我们团队构建隐私计算平台的起点，还得回到当初研究隐私计算技术的初衷。近些年，随着国家层面对数据安全和隐私保护的法律法规越来越严格，在联通内部的数据管控要求也同步趋严。

这种趋势无疑是正确且必要的，但也给我们日常的数据研发和业务支撑带来了一些非常现实的矛盾。 我们经常会遇到这样的场景：业务方需要用到一些敏感数据（比如用户信息）来提升模型效果或实现某些创新应用；但与此同时，数据的所有方因为严格的安全要求，往往无法直接交付原始数据。典型如不同主体之间做联合分析——但由于涉及跨域敏感数据，这种需求往往被搁置，数据价值被白白浪费，而业务也因此无法推进。

传统方式去申请数据，为保证数据安全合规共享，不仅流程繁琐、审批周期长和要求高，而且数据交付后，事后为保证数据安全流通，在审计，合规抽检投入成本也非常高。

我们团队当时面临的核心痛点，就是如何在“数据严格管控”和“数据充分应用”之间找到一个平衡点。正是在这样的背景下，我们注意到了隐私计算技术。经过初步调研，我们发现：“数据不出域、可用不可见”的理念，正是解决上述矛盾的关键路径。它不是通过制度或流程去约束人，而是通过技术手段，在多个参与方之间建立一个安全可信的数据协同环境。

这个是真正投入隐私计算技术研究，开始搭建平台的起点。也正是从这个实践出发，我们一步步探索出了适合内部业务场景的技术架构与应用路径。

推动历程

下图这段经历其实是我们团队在过去一年中围绕隐私计算技术，从需求梳理、技术选型到平台建设落地的完整过程。

2024 年年中，正式启动了这个项目，目标是解决跨域数据共享的合规难题，通过技术手段在“安全”与“可用”之间找到平衡。

6 月份时候，基本明确了采用隐私计算作为主要技术路径。根据我们对内部需求的梳理，发现“隐私保护下的联合分析”是一个非常核心的诉求。在这个过程中，在 GitHub 上发现了 隐语（SecretFlow） 项目，印象非常深刻的是，社区活跃度高、文档完善、上手门槛低，于是我们将其纳入了技术选型的候选清单。

首先使用官方的“快速开始”教程，在本地完成了 SCQL + SQLNode 的部署验证，初步跑通了一个小规模的联合分析流程，验证结果非常符合我们的期望。

能力验证与选型确认

基于后续规划中对隐私求交和联盟建模等能力的需求，我们又部署了 SecretPad All-in-One 套件，对隐语的多种能力做进一步评估。

之前也关注过 FATE ，所以我们也有意识地做了一些对比测试。在简单开箱验证后，我们发现隐语在这些能力上同样表现不俗。

随后，我们又扩展部署了中心化与 P2P 模式，并针对不同的数据量场景进行了性能验证。最终我们认为，隐语在联合分析、隐私求交与联邦建模三大关键场景中，都能较好满足我们的需求，于是正式确定其为核心技术选型。

对比选型

既然说到这里，也跟大家分享下我们技术选型的经验，在项目初期进行技术选型的时候，我们其实对市面上主流的隐私计算框架做了比较全面的调研和初步验证。

最后，我们筛选出了三个重点框架进行了深入学习与评估：FATE、SPDZ 和隐语（SecretFlow）。

FATE

FATE 是一个在联邦学习领域较为成熟的框架，它的生态完整、社区建设也不错。

不过，我们的业务实际情况是：纯粹的机器学习建模类任务占比并不高，反而是需要处理大量复杂的联合查询与统计分析任务。因此，FATE 在适配度方面并不理想，很早就在评估阶段被排除了。

SPDZ

接下来研究了 SPDZ，这是一个经典的多方安全计算框架，在学术圈有很高的影响力，算法支持也很丰富。但是在验证过程中发现，SPDZ 更像是一个偏底层的研究工具，需要用其特定语法去重新构建计算逻辑。

如果想要落地到业务，还要花费大量时间开发适配算子，从工程效率上看并不现实。

隐语 Secretflow

相较而言，隐语(Secretflow)在我们关心的几个方面都展现出了明显优势。

首先是工程上的易用性与业务适配度，它的 SCQL 组件提供类 SQL 的接口形式，能够无缝嵌入我们原有的数据加工流程中。

对于我们这种已有大量 SQL 处理逻辑的团队来说，这种设计大大降低了改造成本，使得敏感数据的联合分析、统计任务可以快速响应和上线。

另一个让我印象非常深刻的，是隐语的技术生态活跃度。我们初次接触 SCQL 时，它的版本是 0.9.0，刚完成一次大版本升级。当时我翻了一下 GitHub 上的更新日志，发现它几乎每个月都会有新版本迭代，说明背后团队投入非常持续。对于隐私计算这样一个技术快速演进的领域，选择一个有“生命力”的开源框架对我们来说尤为重要。

此外还有一个“加分项”也不能不提：隐语的文档与社区支持非常完善。从快速上手指南，到详细的 API 说明，再到 B 站上官方出品的系列视频教程，这些内容对我们团队非常友好，也极大地降低了上手门槛和学习成本。

综合考虑工程效率、适配度、社区活跃度和学习支持等多个维度，最终我们决定将隐语作为平台构建的核心框架。

平台搭建与场景上线

确定技术方案后，我们围绕现有平台能力，完成了整体架构设计与集成规划。

2024 年底，我们完成了第一版系统的上线，并在若干实际业务中开展了试点验证，内部也收集到了非常宝贵的反馈。

进入 2025 年，我们将工作重心转向平台的扩展与可信空间能力的集成，目标是将隐私计算能力深入嵌入到公司整体的数据治理体系中，打造一套具备可扩展性、合规性和高性能的隐私保护数据计算平台。

平台架构

在选型完成之后，我们的首要目标是优先满足内部的跨域数据分析需求，并逐步拓展到支持内外部的数据协同场景。

基于这一目标，我们依托联通现有的中台开发治理平台和数据服务平台，做了一套整体的规划，并启动隐私计算平台的研发和集成工作。

从 2024 年 9 月起，我们正式投入平台的研发与搭建工作。平台初期采用的是 All-in-One + SCQL 独立部署 的方式，主要原因是当时的 All-in-One 架构还没有原生集成 SCQL 组件。

我们将 SCQL 和 SecretPad 统一封装，在中心化部署模式下，借助 SCDB，并通过逻辑库名和项目名实现一对一的映射，确保上层应用对计算框架“无感”，可以同时使用 SCQL 联合分析与 SecretPad 提供的隐私求交、联邦建模等能力。

目前，虽然新版 All-in-One 已支持集成 SCQL 与 Kuscia，但由于我们对结果数据的输出量级有明确要求，而现有版本暂未满足，因此我们仍保留 独立部署架构。

在部署模式上，平台内部采用 中心化部署，外部则基于 P2P 模式。外部架构也有进一步的演进：我们正在与可信数据空间对接，并计划通过连接器打通更多可信协同能力。

整体架构图中：

• 向下层，已打通与元数据管理、数据资产系统的集成，实现计算节点与租户之间在权限体系、数据源管理等方面的联通。

• 向上层，我们将结果数据对接至数据服务平台，支持多种数据共享方式（如 API、文件等），确保从数据获取、计算执行到结果发布的流程完整闭环、无缝集成。

这套架构体系实现了内部跨域计算与数据服务流程的打通，也为未来支撑更复杂的内外部协同场景打下了基础。

实践场景

为了更直观地展示隐私计算在实际业务中的价值，我们可以从两个典型的落地场景来跟大家介绍一下：一个是联通内部的跨域数据融合分析场景，另一个是与外部机构协同的联邦建模场景。

场景一：内部跨主体联合分析

在通信运营商业务中，存在大量跨域的数据融合需求。例如：针对特定客客群的画像与行为分析，需要各个主体之间开展联合分析，以制定更具针对性的融合发展策略。

在该场景中，我们通过隐语的 SCQL 能力实现了跨域数据的联合查询：

• 参与方： 主体 A、主体 B、主体 C。

• 数据分布：

• 主体 C 提供共性数据，并在项目中进行统一配置。

• 主体 A、主体 B 拥有个性化数据与差异化的数加工口径，且这些数据对其他参与方不可见。

• 权限管理：

• 主体 C 通过配置 CCL（数据控制语言）权限及对敏感字段做加密脱敏处理，避免敏感明细数据暴露。

• 主体 A 和主体 B 在项目中仅可访问自己的个性化数据与定制口径。

在此基础上，主体 A 和主体 B 之间可以采用不同的档位（如 A、B、C、D vs 一、二、三、四）进行对比分析，而无需暴露任何明细数据，实现了真正意义上的 “数据不出域，联合可计算”。

👉 此场景不仅验证了 SCQL 在多租户权限管理下的灵活性，也为后续更多跨部门、跨区域的联合分析场景奠定了实践基础。

场景二：跨企业数据联邦建模合作

在对外协作中，我们以与某 A 企业联合建模的场景为例，展示了隐语在纵向联邦学习场景下的落地能力：

• 参与方： 联通连接器 与 A 企业连接器。

• 数据资产分布：

• 联通侧拥有用户的部分特征与标签信息。

• A 企业拥有另一部分特征数据。

为满足业务需求，我们基于隐语的 SecretPad 和联邦建模能力，对连接器进行了二次封装，实现了以下流程：

1. 数据产品目录发布： 双方将各自特征数据注册为可信数据空间数据产品，并遵守国数局“三统一”要求，确保数据安全合规流通。

2. 特征扩充与建模训练： 通过纵向联邦学习完成特征扩充与模型训练。

3. 联通侧预测验证： 预测服务部署于联通侧，便于直接调用结果并用于业务策略制定。

这一场景充分体现了隐语在 数据协作安全性 和 建模闭环效率 上的优势，成功支撑了联通与外部企业的联合智能服务能力。

踩坑经验

在隐语的实际落地过程中，我们遇到多个具有代表性的技术问题。跟大家介绍下我们遇到的关键问题点、原因分析及对应的解决方案，供大家在使用隐语时参考与借鉴。

集成挑战

最开始的时候，我们平台需要提供“任务生命周期管理”功能，但 SCQL 原生仅支持项目表与权限管理，完整任务管理功能由 SecretNote 提供，无法直接集成。

于是我们初步尝试直接修改 SCQL 源码添加接口，但因其请求参数由 Protobuf 定义、代码自动生成，改动成本极高。

当我们发现成本很大的时候，重新定位了 SCQL 的边界，任务管理功能由平台后端独立开发并维护；SCQL 仅作为隐私计算引擎服务调用，从架构层面实现职责清晰、解耦设计。

安装部署

除了系统集成之外，我们还踩过部署配置相关的坑，All-in-One 部署后容器参数（如内存）被覆盖，修改不生效。

• 原因分析：配置文件重启后被镜像中的原始文件覆盖。

• 解决方案：

• 查看并修改 install 脚本中复制配置文件的逻辑；

• 或自定义构建镜像，内嵌所需参数设置。

SCQL Agent 回调 URL 配置错误，导致异步查询无法返回。

• 原因分析：配置项填写错误，仅同步任务可用，异步任务因回调失败导致无响应。

• 解决方案：修正 engine 配置项中的回调地址，并通过社区反馈确认解决路径。

使用挑战

在任务执行层面，我们也经历了多次调优。早期在 0.9.0 版本中执行大规模联合分析任务时，由于任务执行后内存不释放，导致资源消耗异常。

• 原因分析：SCQL v0.9.0 版本存在资源释放 Bug，尤其在处理亿级表时（10 亿 × 3000 万）内存压力极大。

• 解决方案：调整引擎参数配置，并升级至更稳定版本后解决。

在 CCL 使用中，我们也曾遭遇多种语法兼容与口径迁移问题，配置难以通过校验，报错信息模糊不清。

• 原因分析：业务方移植既有 SQL 逻辑，语句复杂度高；SCQL 报错字段提示不明确，导致调试效率低。

• 解决方案：深入学习社区文档、参考官方 CCL 示例，逐步积累规则配置经验。

语法问题

某些 MySQL 合法语法（如 ON 子句中嵌套逻辑）在 SCQL 中报错。

• 原因分析：SCQL 的 SQL 解析器与 MySQL 并非完全一致，部分语法需适配。

• 解决方案：经社区沟通，使用双括号包裹子表达式成功绕过限制；实际语法上需保守处理。

升级风险

低版本场景运行正常，高版本升级后 SQL 执行异常（目前该问题最新版本已修复）。

• 原因分析：新版本 BUG 导致

• 解决方案：通过 GitHub 提交 issue 并附上详细参数配置，才完成问题定位并修复。

如果你也遇到过相关的问题，一定记得提 issue，这样的话后面的同学也都能避免踩坑，总的来看隐语不仅为我们提供了丰富的计算能力与接口封装，但是实际使用中仍需注意工程层面的问题落地与持续的社区互动。

建议刚接触的朋友多借助官方文档与社区反馈渠道，持续迭代自己的使用模式，从而提升隐私计算场景的落地效率与系统稳定性。

实践技巧

在使用隐语 SCQL 的过程中，我们总结出一个关键的最佳实践经验：对于非核心功能，应通过外围实现方式来降低对原有框架的侵入。这不仅提升了系统的健壮性，也极大地提高了可维护性和扩展性。

案例：SCQL 扩展 Hive 数据源的两种方式

在我们为 SCQL 扩展 Hive 数据源的过程中，面临了两个技术路径选择：

直接在 Engine 中实现 Hive Connector（C++）

• 使用 C++ 在 Engine 中构建 Hive 数据连接器。

• 优点是性能高，但问题是侵入性强，维护成本高。

开发独立的 Arrow Flight SCQL 服务

• 实现一个兼容 Arrow Flight SCQL 协议 的服务，支持 Hive 查询。

• 通过 SCQL Engine 中现有的 arrow flight scql linked 能力来连接这个服务，从而获取 Hive 中的数据。

最终，我们毫不犹豫地选择了方案二，因为整体优势如下：

• 对框架改动小：只需在 broker 和 SCDB 中添加少量代码。

• 数据获取逻辑独立：全部放在自研的数据服务中处理。

• 验证效果良好：开发过程顺利，也验证了解耦设计的可行性和高可用性。

拓展建议

在数据源扩展方面，SCQL 实际上也在其框架中预留了接口（例如 engine 模块），支持通过模块化方式对接更多数据源。

如果在实际业务场景中识别到具有通用价值的数据源能力，欢迎向社区贡献：

• 可将通用的拓展封装为插件或模块，提升框架能力。

• 但需评估是否耦合了企业内部的私有逻辑，决定是否适合向社区提交。

二次开发

在进行 SCQL 的二次开发过程中，我们积累了一些宝贵的经验，特别是在源码学习和功能拓展方面，希望能为后续开发者提供参考。

刚开始分析 SCQL 代码时，我们采用的是“按功能模块拆解”的思路，试图通过静态地梳理每个模块来理解整个系统。

然而在实际过程中发现，这种方式对于隐私计算这样 流程复杂、模块耦合紧密的系统，并不奏效：

• 各模块之间调用关系错综复杂，单看模块难以构建清晰的流程图；

• 阅读体验“割裂”，很难在脑中形成完整的数据流与执行路径；

• 静态分析效率低，难以快速定位实际开发中的关键点。

有效路径

为了突破困境，我们调整了思路，选择从核心业务流程入手进行端到端追踪，以 “SCQL 查询请求的完整生命周期” 为主线进行深入分析。

具体步骤如下：

1. 从 SCQL 接收请求开始：观察查询请求进入系统后，经过了哪些模块与组件处理，如请求接收、参数验证、权限检查等。

2. 请求调度与转发：分析请求如何从 SCQL Server 被调度到 Engine，包括涉及的通信协议、调度策略等。

3. Engine 处理过程：继续追踪 Engine 如何接收请求、调度算子、执行任务、获取数据并生成结果。

4. 结果返回链路：观察从 Engine 回传结果到 SCQL，再由 SCQL 返回给上层系统的全过程。

通过这条完整的执行链路，我们实现了从请求到执行再到返回的闭环追踪，对架构设计、数据流动路径、各组件职责边界有了系统性认知。 效果：

• 后续修复 bug 时，可以快速定位问题模块；

• 扩展功能时，能准确找到切入点，减少试错成本；

• 构建起稳定、清晰的 mental model，有助于整体把控系统演进。

在隐私计算领域，SCQL 涉及的内容包括大量的 安全协议、分布式组件、算子优化、数据安全机制等，理论知识较为复杂，对于准备进行 SCQL 二次开发的团队和个人，我们强烈建议采用以下方法：

• 不要陷入模块细节：避免一开始就逐个研究算子、服务、模块定义；

• 选择一个典型场景作为切入点：比如 SCQL 查询生命周期、隐私求交任务、联邦建模过程等；

• 全链路梳理主流程：先跑通流程，再逐步拆解底层模块；

• 记录关键路径与接口调用：便于后续追踪和团队知识传承。

初期可将精力聚焦于 SCQL 的接口使用、部署流程、典型任务配置。亲手完成一次 SCQL 全流程部署，比纯看代码更能理清体系。

如运行遇到瓶颈、功能扩展受限时，再探究相关协议（如 PSI、MPC）、数据加密机制或算子优化。

例如从联邦 SQL 查询扩展到联邦建模时，再关注 SecretPad、Kuscia、SPU 等模块的协同关系。

社区未来发展方向

目前我们正参与到可信数据空间的建设工作中，了解到国家数据局已制定了相应的技术架构规范。作为关键支撑技术之一，隐私计算将成为可信数据空间的重要组成部分。

在这个背景下，我们也看到了 隐语（SecretFlow）社区已经在该方向有所规划和布局，包括相关的标准接口、模块整合、系统架构演进等内容。这些内容非常值得深入研究和持续推进。

因此，我们期待在后续的社区技术演进中，可以进一步强化可信数据空间相关的内容规划与技术路线，非常希望能与社区共同推动相关内容的共建与深入，一起学习进步，共同参与可信数据空间的技术生态建设。

技术延伸讨论

1、我们在使用 SCQL 处理大规模数据时候（双方，1 方数据规模较大约 10 亿），经常出现 OOM 或者超时的情况，对于这种场景，有什么改进的点呢？

隐私计算本身相比明文计算慢很多，因此在大规模场景下可以从以下优化：

• 带宽、延迟、内存、CPU 等资源必须充足。

• 推荐配置独占资源运行 SCQL 引擎，避免并发干扰，确保最大可用资源分配。

当某一方数据达到 10 亿量级时，单次任务可能需要 上百 GB 内存，若资源不足极易出现 OOM。 OOM 优化措施：

1. 增加内存资源：

a. 从容器层面、物理机层面提升内存规格； b. 若使用 K8s，考虑适配更大规格的节点（如 256GB RAM）。

1. 关闭并发或设置独占模式：

a. 同时仅运行一个计算任务，避免多个大任务并发抢占资源。

1. 开启 batched 模式（新版本功能）：

a. batched 模式将部分中间数据转储到磁盘，显著降低内存使用； b. 内存压力降低，但 性能会有所下降，适合资源有限但对性能不极致要求的场景。 超时问题优化建议

1. 延长系统默认超时配置：

a. 根据场景，适当增大 engine、broker 等组件的超时时间设置，避免因长时间计算被意外中断；

1. 适配网络环境：

a. 评估网络质量（尤其跨城/跨域部署），优化 VPN、TLS 层的传输性能。 业务层优化 在无法显著扩展硬件资源时，可从业务入手，降低密态处理负担。

• 前置过滤：提前在明文阶段完成筛选条件（如 WHERE, LIMIT），减少进入 SCQL 的数据规模；

• 数据拆分：将大表划分为多个小批次分布式处理，适合周期性任务；

• 逻辑拆解：将复杂 SQL 拆分为多步处理，减轻单个任务负载压力；

• 仅密态处理必要部分：对于非敏感字段或不涉及联邦场景的数据，优先考虑明文计算完成。

SCQL 在大规模隐私计算场景中，计算成本与资源消耗远高于传统明文计算，可以从“硬件资源保障 + SCQL 参数优化 + 业务逻辑调整”三个层次协同优化，提升整体任务成功率与系统稳定性。如需了解具体配置项或 batched 模式使用方式，建议参考最新 SCQL 文档或联系社区技术支持。

2、社区未来规划数据源是否支持接入实时数据源？

在现阶段，SCQL 的数据源接入机制虽然支持一定程度的灵活配置，但仍存在一些限制：

• 通过配置文件方式接入数据源，但修改配置后仍需重启服务才能生效；

• 已支持对接 Kuscia、Arrow SQL Server 及用户自建 Server 等实时服务，以实现数据的动态接入，但增加了外部系统的依赖。

目前，社区暂无正式的实时数据源支持路线图，社区非常重视用户的实践反馈，如果能通过用户案例进一步验证实时数据接入的需求与价值，将会优先考虑在后续版本中支持此能力。短期建议：针对对接 Flink、Spark 等实时系统的场景，则建议先落盘，再接入 SCQL。

3、我们这边有一些数据量特别大的表（几十上百亿），执行隐私计算任务会超时报错，SCQL 是否有计划支持多节点分布式计算？

当前支持情况

• SCQL Engine 已支持多节点部署，即一个参与方可以在多台机器上部署多个 engine 节点；

• 但目前尚不支持将单个计算任务自动拆分至多个节点并行执行。

换句话说，当前版本的 SCQL 仍是基于“一个任务一个节点”的模式执行，尚未支持自动的分布式并行调度。

对于有明确分布式计算需求的场景，建议将使用反馈提交至社区，以支持后续技术规划。