本文整理自對話生產用户聯通軟研院，介紹了基於隱語（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 和聯邦建模能力，對連接器進行了二次封裝，實現了以下流程：
- 數據產品目錄發佈： 雙方將各自特徵數據註冊為可信數據空間數據產品，並遵守國數局“三統一”要求，確保數據安全合規流通。
- 特徵擴充與建模訓練： 通過縱向聯邦學習完成特徵擴充與模型訓練。
- 聯通側預測驗證： 預測服務部署於聯通側，便於直接調用結果並用於業務策略制定。
這一場景充分體現了隱語在 數據協作安全性 和 建模閉環效率 上的優勢，成功支撐了聯通與外部企業的聯合智能服務能力。
踩坑經驗
在隱語的實際落地過程中，我們遇到多個具有代表性的技術問題。跟大家介紹下我們遇到的關鍵問題點、原因分析及對應的解決方案，供大家在使用隱語時參考與借鑑。
集成挑戰
最開始的時候，我們平台需要提供“任務生命週期管理”功能，但 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 查詢請求的完整生命週期” 為主線進行深入分析。
具體步驟如下：
- 從 SCQL 接收請求開始：觀察查詢請求進入系統後，經過了哪些模塊與組件處理，如請求接收、參數驗證、權限檢查等。
- 請求調度與轉發：分析請求如何從 SCQL Server 被調度到 Engine，包括涉及的通信協議、調度策略等。
- Engine 處理過程：繼續追蹤 Engine 如何接收請求、調度算子、執行任務、獲取數據並生成結果。
- 結果返回鏈路：觀察從 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優化措施：
- 增加內存資源：
a. 從容器層面、物理機層面提升內存規格；
b. 若使用 K8s，考慮適配更大規格的節點（如 256GB RAM）。 - 關閉併發或設置獨佔模式：
a. 同時僅運行一個計算任務，避免多個大任務併發搶佔資源。 - 開啓 batched 模式（新版本功能）：
a. batched 模式將部分中間數據轉儲到磁盤，顯著降低內存使用；
b. 內存壓力降低，但 性能會有所下降，適合資源有限但對性能不極致要求的場景。
超時問題優化建議 - 延長系統默認超時配置：
a. 根據場景，適當增大 engine、broker 等組件的超時時間設置，避免因長時間計算被意外中斷； - 適配網絡環境：
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 仍是基於“一個任務一個節點”的模式執行，尚未支持自動的分佈式並行調度。
對於有明確分佈式計算需求的場景，建議將使用反饋提交至社區，以支持後續技術規劃。
