数据库的联邦学习架构：在数据不出域的前提下实现跨组织模型训练的架构探索
一、"联合风控"的理想与"数据孤岛"的现实
金融行业有一个广泛的合作需求：多家银行联合训练一个风控模型，利用各家的反欺诈数据来提升模型的准确率。但这里有一个看似无解的矛盾——每家银行的交易数据都属于最高级别的敏感信息，监管要求不得出域。传统的方案是各家把数据脱敏后汇集到一个中心节点训练模型，但这仍然存在数据泄露的风险（即使脱敏后，攻击者可能通过模型反推原始数据）。
联邦学习（Federated Learning）正是为解决这个"数据可用不可见"的矛盾而设计的：模型在各参与方的本地数据上训练，只有模型参数（梯度）在网络中传输，原始数据始终保留在各自的数据库中。将联邦学习与数据库结合，意味着数据训练的过程直接在数据库内部完成，而无需将数据导出。
二、数据库内嵌联邦学习的技术架构
在数据库内部署联邦学习，核心组件包括：
模型训练运行时。数据库需要内嵌一个轻量级的机器学习运行时（如ONNX Runtime Embedded或TensorFlow Lite），可以直接在SQL引擎内部执行张量计算。MySQL HeatWave和SingleStore已经提供了数据库内嵌ML推理的能力，但数据库内嵌分布式训练仍处于早期阶段。
数据特征提取。模型的输入数据从数据库表中直接读取，通过SQL查询进行特征工程（如窗口函数计算时间窗口内的聚合特征、JOIN拼接不同维度的特征）。这些特征提取操作在数据库内完成，不需要将数据导出到外部处理。
安全梯度交换。各参与方训练完成后，使用安全聚合协议（如Secure Aggregation）对梯度进行加密求和，确保协调服务器无法看到任何单一参与方的原始梯度。同态加密和差分隐私是两种常用的隐私保护技术。
模型同步与版本管理。全局模型在协调服务器上维护，定期分发到各参与方。每次联邦训练轮次后，模型版本号递增，各参与方同步更新本地模型。
三、工程实现的关键挑战
挑战一：数据分布的非独立同分布（Non-IID）。各参与方的数据分布可能完全不同（如银行A的用户主要是年轻人，银行B的用户主要是中老年）。在这种Non-IID数据上训练的全局模型可能无法在任何一方上获得良好性能。解决方案包括FedProx算法（在本地目标函数中加入近端项约束，防止本地模型偏离全局模型太远）和个性化联邦学习（允许每个参与方有部分独立的模型参数）。
挑战二：通信效率与带宽。在大规模联邦学习中，模型参数（可能数百万个）的传输成为瓶颈。梯度压缩（Top-K稀疏化、量化压缩）可以将通信量减少100~1000倍，代价是模型收敛速度略有下降。
挑战三：数据库内训练的CPU/GPU资源竞争。数据库的CPU和内存资源首先服务于查询请求，训练任务需要在不影响查询性能的前提下运行。解决方案包括将训练任务调度到数据库的低负载时段（如凌晨）、使用独立的Worker线程池。
挑战四：恶意参与方的投毒攻击。某个参与方可能故意上传错误的梯度来破坏模型。鲁棒聚合方法（如Krum、Trimmed Mean）可以过滤掉异常梯度。
四、与现有数据共享方案的关系
联邦学习不是数据共享的替代方案，而是一种互补方案。对于可以共享的数据（如经过严格脱敏和审批的数据），传统的集中式训练在效率和效果上都优于联邦学习（Non-IID问题的消除）。联邦学习的价值在于处理"无论如何都不能共享"的数据——它是"无方案可施"时的最后选择。
五、总结
数据库的联邦学习架构，是数据库技术与隐私计算技术交叉融合的前沿方向。短期来看，其应用主要集中在金融风控和医疗数据分析等数据高度敏感且监管严格的领域。长期来看，随着数据库内嵌ML能力和隐私保护技术的成熟，联邦学习将成为数据库的一种基础能力——当需要跨组织协同训练模型时，不需要搭建复杂的额外基础设施，直接在数据库内完成。
对于正在探索联邦学习的数据团队，当前最务实的选择是使用现有的联邦学习框架（如FATE、TensorFlow Federated）与数据库配合，而非期望数据库原生支持联邦学习。后者还需要3~5年的技术成熟周期。