极客星球 | 联邦学习与产品化之路

2022 年 3 月 26 日
本文字数：2859 字
阅读完需：约 9 分钟

一、背景——联邦学习与 fate 简介

1、联邦学习

联邦学习（Federated Learning）是一种新兴的人工智能基础技术，由谷歌最先提出于 2016 年，原用于解决安卓手机终端用户在本地更新模型的问题。其设计目标是在保障大数据交换时的信息安全、保护终端数据和个人数据隐私、保证合法合规的前提下，在多参与方或多计算结点之间开展高效率的机器学习，目标是在保证数据隐私安全及合法合规的基础上实现共同建模，提升 AI 模型的效果。总的来说，联邦学习本质上是一种分布式机器学习技术或机器学习框架。

2、FATE

Federated AI Technology Enabler（简称 FATE) 是由微众银行 AI 团队，于 2019 年 2 月推出的全球首个工业级别联邦学习框架，可以让企业和机构在保护数据安全和数据隐私的前提下进行 AI 协作。FATE 项目使用多方安全计算 (MPC) 以及同态加密 (HE) 技术构建底层安全计算协议，以此支持不同种类的机器学习的安全计算，包括逻辑回归、基于树的算法、深度学习和迁移学习等。

FATE 技术架构的底层是 Tensorflow / Pytorch（深度学习）、EggRoll /Spark（分布式计算框架）和多方联邦通信网络，上层为联邦安全协议，并在安全协议的基础上构建联邦学习算法库。

Federatedml 模块包括许多常见机器学习算法联邦化实现。所有模块均采用去耦的模块化方法开发，以增强模块的可扩展性。具体包括：

联邦统计: 包括隐私交集计算，并集计算，皮尔逊系数等；
联邦特征工程：包括联邦采样，联邦特征分箱，联邦特征选择等；
联邦机器学习算法：包括横向和纵向的联邦 LR, GBDT， DNN，迁移学习等；
模型评估：提供对二分类，多分类，回归评估，联邦和单边对比评估；
安全协议：提供了多种安全协议，以进行更安全的多方交互计算。

二、Fate 产品化

1、Fate 操作方式

1）配置 Json + fate_client 命令行

为了让任务模型的构建更加灵活，目前 FATE 使用了一套自定的域特定语言 (DSL：domain-specific language) 来描述任务。在 DSL 中，各种模块可以通向一个有向无环图（DAG）组织起来。通过各种方式，用户可以根据自身的需要，灵活地组合各种算法模块。

FATE 构建联邦学习 Pipeline 是通过自定义 dsl 和 conf 两个配置文件来实现的：

dsl 文件：用来描述任务模块，将任务模块以有向无环图（DAG）的形式组合在一起。
conf 文件：设置各个组件的参数，比如输入模块的数据表名；算法模块的学习率、batch 大小、迭代次数等。

执行示例：

2）pipeline 代码行

pipeline 是一个更高级的接口，它将上面提交任务的方式以及很多 fate flow client 命令进行了封装，使用 pipeline 建模就像传统方式一样在 python 里添加需要的模块、定义模块的参数，然后运行，而不用更改 dsl 的 json 文件，然后使用命令行提交任务。

2、产品化需求

1）任务配置繁琐

以上 fate 提交任务的两种方式，由于 Fate 内部模块众多，且不同的模块对应的参数不同，只有对 fate 框架比较熟悉的技术人员才能使用，有一定的技术门槛，对普通业务人员不友好

2）不支持 component 复用

在 1.7 以下的版本中，fate 并不支持不同 component 的独立运行、阶段复用，只能数据预处理、数据对齐、特征工程、模型训练等步骤一次性执行结束。如果中间任何一个环节出现问题，整个任务必须重新从头执行；如果想使用相同的数据、不同的训练参数重新训练，也必须修改好对应的 json 后重新提交，执行完整流程。

这对于使用者来说，会带来不必要的时间浪费，如果双方的数据量较大，这个问题会更加明显。

3）缺失权限控制

这部分包括两个方面：

对外：在原生 Fate 中，当双方配置相应的 party_id、ip、port 后，单方可以无限次发起任务，也可以使用枚举攻击获取另一方数据（例如手机号 MD5 枚举），会给合作方的硬件资源、数据安全等带来危害；
对内：缺少不同项目以及相关数据之间的权限控制，容易造成管理混乱

4）部署较为繁琐

现阶段的客户多愿意采用本地部署的方式而非云部署，官方虽然提供了各种本地部署指导以及 ansible 自动化部署脚本，但对于技术人员来讲，部署依然较为繁琐；如果不同合作方涉及多个不同的操作系统，部署会更加复杂，也会带来较多的稳定性隐患。

三、产品化难点

1、component/步骤解耦

通过研读 fate 源码，发现各个 component 衔接的核心在于如何读取上一个 component 的数据、Model 输出；而控制输入的模块则由 dsl 定义，在原生 fate 中，对应的是上一个 component 的代号【同一 job 内，job_id 固定】，不能人为指定。

因此，要实现解耦/复用，需要重新定义 DSL 中模块输入的参数，并在 fate_flow 中修改对应的解析逻辑，使后续的 component 可以读取上一个 component 的输出。

核心逻辑如下：

java 端提交 job 信息到 fate，fate 端解析 json 获取对应的 job_id、component、data_name；

tracker 组件从底层库表读取对应 component 输出的库表

2、通信信道安全性【信通院认证必选项】

1）双端口

在最早的求交产品中，我们将任务相关的信息使用单独的 web 程序通过指定的端口进行通信，与 fate 自身的端口是相互独立的。但是这样一来，如果要满足认证所需的安全性，web 端通信的数据加密需要单独开发，技术难度较大，整个系统也需要定义两套不同的加解密系统，系统设计会出现不必要的冗余模块，因此被弃用。

2）统一 TLS 通道

Fate 的 eggroll 模块已经实现 TLS 双向通信加密功能，只需要添加双方的公私钥文件，并在配置中开启即可。

因此可以利用 fate 中已有的 proxy_app 模块，通过 eggroll 定义好的 grpc 通信通道进行信息传递；

由于只涉及请求事件信息传递，因此还需要在 java 端增加相应的解析执行模块，来完成具体的信息同步、数据入库、状态更新等动作。

3、兼顾数据安全的项目合作机制

1）配置全局合作 Token

在信通院版本的开发中，为了缩短开发周期，我们使用了全局 Token 方式，对于某一合作方，我们将双方协定好的 token 配置在数据库中，后续任务根据这一 token 进行权限认证（数据读取、job 执行权限）；如果合作解除，任意一方删除 token 或取消对应库表的授权即可；这样初步达到了权限控制的目的。

但是这种方式仍存在对方可通过枚举窃取数据的弊端，例如通过手机号枚举获取我方全库数据 id。

2）会话式项目合作 Token

这种方式执行合作前，需要先通过对话式的通信创建任务，每个任务分配一个合作 Token，并限定合作所涉及的库表，这样就从根本上杜绝了枚举攻击的可能。