关于机器学习:联邦学习开源框架FATE架构

作者：京东科技 葛星宇

1. 前言

本文除非凡阐明外，所指的都是 fate 1.9 版本。

fate 材料存在着多处版本性能与公布的文档不匹配的状况，各个模块都有独立的文档，性能又有关联，坑比拟多，首先要理分明各概念、模块之间的关系。

2. 网络互联架构

1. 概念解释：

RollSite 是一个 grpc 通信组件，是 eggroll 引擎中的一个模块，相当于咱们的 grpc 通信网关。

Exchange 是 RollSite 中的一个性能，用于保护各方网关地址，并转发音讯。参考《FATE exchange 部署指南》

2. 比照解读：

l 网状架构相当于咱们的一体化版本模式，但没有 dop 平台来保护网关，每方须要在配置文件里保护其余参与方的网关地址。

l 星型架构的益处是只在 Exchange 方保护所有参与方的网关地址，前提是须要信赖 Exchange，并且流量全副都须要从 Exchange 方直达，相当于咱们的中心化版本。但不反对证书。

3. Exchange 配置

在 Exchange 上配置路由表：

在各 party 方配置默认路由指向 exchange，不须要再配置每个 party 的地址。

3. 总体架构

FATE 反对 eggroll 和 spark 两种计算引擎, 搭配不同的通信组件，共五种组合，不同的通信模块不能兼容。

参考：：《不同类型 FATE 的架构介绍》

区别：

l RabbitMQ 是一个简略易上手的 MQ

l Pulsar 相比 RabbitMQ，能够反对更大规模的集群化部署，也反对 exchange 模式的网络结构。

l Slim FATE 相比其余模式，最大化缩小集群所需的组件，能够应用在小规模联邦学习计算，IOT 设施等状况。

3.1. 基于 EggRoll 引擎的架构

Eggroll 是 FATE 原生反对的计算存储引擎，包含以下三个组件：

l rollsite 负责数据传输，以前的版本里叫 Proxy+Federation

l nodemanager 负责存储和计算

l clustermanager 负责管理 nodemanager

3.2. 基于 spark+hdfs+rabbitMQ 的架构

3.3. 基于 spark+hdfs+Pulsar 的架构

3.4. spark_local (Slim FATE)

反对 rabbitMQ 替换 pulsar

4. 组件源码

所有的 fate 我的项目都在这个叫 FederateAI 社区的 URL 下：https://github.com/FederatedAI

主我的项目：FATE 是一个汇总的文档和超链汇合，学习入口，在线文档

关联我的项目：

•KubeFATE docker 和 k8s 的部署

•AnsibleFATE 相当于咱们的图形化部署版的底层脚本 学习入口

•FATE-Flow 联结学习工作流水线治理模块，注册、治理和调度核心。

•EggRoll 第一代 fate 的计算引擎

•FATE-Board 联结学习过程可视化模块，目前只能查看一些记录

•FATE-Serving 在线联结预测，学习入口

•FATE-Cloud 联邦学习云服务, 相似于咱们的 dop 平台，治理性能。

•FedVision 联邦学习反对的可视化对象检测平台

•FATE-Builder fate 编译工具

•FedLCM 新增的我的项目：创立 FATE 联邦并部署 FATE 实例。目前仅反对部署以 Spark 和 Pulsar 作为根底引擎，并应用 Exchange 实现相互连贯的

5. FATE-Flow

FATE Flow 是调度零碎，依据用户提交的作业 DSL，调度算法组件执行。

官网文档

服务能力:

· 数据接入

· 工作组件注册核心

· 联结作业 & 任务调度

· 多方资源协调

· 数据流动追踪

· 作业实时监测

· 联结模型注册核心

· 多方单干权限治理

· 零碎高可用

· CLI、REST API、Python API

5.1. 流程架构

旧版，图比拟平面

· DSL Parser：是调度的外围，通过 DSL parser 能够拿到上下游关系、依赖等。

· Job Scheduler：是 DAG 层面的调度，把 DAG 作为一个 Job，把 DAG 外面的节点 run 起来，就称为一个 task。

· Federated Task Scheduler：最小调度粒度就是 task，须要调度多方运行同一个组件但参数算法不同的 task，完结后，持续调度下一个组件，这里就会波及到协同调度的问题。

· Job Controller：联邦工作控制器

· Executor：联邦工作执行节点，反对不同的 Operator 容器，当初反对 Python 和 Script 的 Operator。Executor，在咱们目前的利用中拉起 FederatedML 定义的一些组件，如 data io 数据输入输出，特征选择等模块，每次调起一个组件去 run，而后，这些组件会调用基础架构的 API，如 Storage 和 Federation Service (API 的形象)，再通过 Proxy 就能够和对端的 FATE-Flow 进行协同调度。

· Tracking Manager：工作输入输出的实时追踪，包含每个 task 输入的 data 和 model。

· Model Manager：联邦模型管理器

5.2. api service

DataAccess 数据上传，下载，历史记录, 参考示例

Job 提交（并运行），进行，查问，更新，配置，列表，task 查问

Tracking

Pipeline

Model

Table

客户端命令行实际上是对 api 的包装调用，能够参考其示例

Python 调用 api 示例

5.3. 算法模块

Federatedml 模块包含许多常见机器学习算法联邦化实现。所有模块均采纳去耦的模块化办法开发，以加强模块的可扩展性。具体来说，咱们提供：

1. 联邦统计: 包含隐衷交加计算，并集计算，皮尔逊系数, PSI 等

2. 联邦特色工程：包含联邦采样，联邦特色分箱，联邦特征选择等。

3. 联邦机器学习算法：包含横向和纵向的联邦 LR, GBDT，DNN，迁徙学习等

4. 模型评估：提供对二分类，多分类，回归评估，聚类评估，联邦和单边比照评估

5. 平安协定：提供了多种平安协定，以进行更平安的多方交互计算。

Figure 1：Federated Machine Learning Framework

可开发在 fate 框架下运行的算法：指南

6. FATE-Serving

6.1. 性能架构

6.2. 部署逻辑架构

Adatptor：默认的状况应用零碎自带的 MockAdatptor，仅返回固定数据用于简略测试，理论生产环境中须要使用者须要自行开发并对接本人的业务零碎。（这部分能够看看能不能对接咱们本人的在线预测零碎。）

l 反对应用 rollsite/nginx/fateflow 作为多方工作协调通信代理

l rollsite 反对 fate on eggroll 的场景，仅反对 grpc 协定，反对 P2P 组网及星型组网模式

l nginx 反对所有引擎场景，反对 http 与 grpc 协定，默认为 http，反对 P2P 组网及星型组网模式

l fateflow 反对所有引擎场景，反对 http 与 grpc 协定，默认为 http，仅反对 P2P 组网模式，也即只反对相互配置对端 fateflow 地址

6.3. 部署实例图

6.4. 工作时序图

6.5. 模型推送流程

蓝色为 guest 集群，灰色代表 host 集群

1. 通过 fate flow 建模 2. 别离部署 guest 方 Fate-serving 与 host 方 Fate-serving

3. 别离配置好 guest 方 Fate-flow 与 guest 方 Fate-serving、host 方 Fate-flow 与 host 方 Fate-serving。

4. Fate-flow 推送模型

5. Fate-flow 将模型绑定 serviceId

6. 以上操作实现后，能够在 serving-admin 页面上查看模型相干信息（此步操作非必须）。

7. 能够在 serving-admin 页面上测试调用（此步操作非必须）。

6.6. 搭配 nginx 代理

https://fate-serving.readthedocs.io/en/develop/example/nginx/

FATE-Serving 之间的交互能够通过 nginx 反向代理转发 grpc 申请，以下几种场景配置如下：

· 场景一：单方不配置 TLS，通过 nginx 四层代理转发

· 场景二：单方配置 TLS，通过 nginx 四层代理转发，单方别离进行证书校验

· 场景三：数据应用方配置 Client 端证书，Nginx 配置 Server 端证书，Host 不配置证书，通过 nginx 七层代理转发，由 Client 端和 nginx 进行证书校验

7. FATE Cloud

FATE Cloud 由负责联邦站点治理的云治理端 Cloud Manager 和站点客户端治理端 FATE Manager 组成，提供了联邦站点的注册与治理、集群自动化部署与降级、集群监控、集群权限管制等外围性能。

联邦云治理端（Cloud Manager）

联邦云治理端即联邦数据网络的管理中心，负责对立经营和治理 FATE Manager 及各站点，监控站点的服务与联邦单干建模，执行联邦各权限管制，保障联邦数据单干网络的失常运作；

联邦站点治理端（FATE Manager）

联邦站点治理端，负责管理和保护各自的联邦站点，为站点提供退出联邦组织、执行站点服务的自动化部署与降级，监控站点的联邦单干与集群服务，并治理站点用户角色与利用权限；

产品手册

8. 部署测试

共有 4 类部署形式，单机的装置模式是只提供了单机的装置文档，也能够钻研怎么扩大成集群模式。

| | 单机（不举荐生产用）| 集群（生产举荐）|
| 非容器 | AllinOne | ansible |
| 容器 | docker compose | k8s |

部署时会要求配置机器对应的角色，只能选 host，guest 和 Exchange，其中 host 和 guest 并没有区别，理论运行联邦时还是在 job 的配置中去配置哪一方是 guest，哪一方是 host，工作只能在 guest 方提交。

8.1. AllinOne

所有的组件都部署在一台机器上，比拟适宜开发调试，参考链接。

8.2. ansible

尝试用 ansible 部署时遇到了 python 相干的谬误，领导文档也短少具体的步骤，没有相干谬误的阐明。

8.3. k8s

手上没有 k8s 环境，暂未测试。

参考文档：《KubeFATE 部署 FATE 反对引擎介绍》

8.4. docker compose

容器部署尝试用 docker compose 形式部署了一对，比较顺利，参考了 2 篇官网文章，前边的筹备步骤和装置过程参考此文，“验证部署”及之后的步骤参考《Docker Compose 部署 FATE》

不同点如下：

8.4.1. 筹备阶段

下载镜像较慢，如果大批量部署，能够搭建内网镜像服务。

| Role | party-id | OS | IP | |
| host | 20001 | Centos7.6 | 11.50.52.81 | 8C64G |
| guest | 20002 | Centos7.6 | 11.50.52.62 | 8C64G |
| 部署机 | | Centos7.6 | 11.50.52.40 | |

以上内容代替文档中对应的局部内容。

一开始我只部署了一台 host，原本打算这 2 台做一个集群，起初发现文档里没提这种形式，只好先按文档试验一次，于是又部署了 guest，这样在 guest 的配置里曾经写好了 host 的地址，于是手动将配置更新到了 host 的 /data/projects/fate/confs-20001/confs/eggroll/conf/route_table.json

发现不须要重启容器后续步骤也没报错，阐明能够动静批改路由信息。

8.4.2. hetero_lr 测试

进入容器的时候，容器名蕴含的平台 id 须要批改成理论的。

json 格局定义阐明文档

fateflow/examples/lr/test\_hetero\_lr\_job\_conf.json 中不同点，

批改对应的平台 id

 "initiator": {
 "role": "guest",
 "party_id": 20002
 },
 "role": {
 "guest": [20002],
 "host": [20001],
 "arbiter": [20001]
 },
 

按文档写资源不够运行不了, 须要批改如下

"job_parameters": {

    "common": {

      "task_parallelism": 1,

      "computing_partitions": 1,

      "task_cores": 1

    }

  },

不要批改 fateflow/examples/lr/test\_hetero\_lr\_job\_dsl.json 文件，文档中的配置是旧版本的，批改了就不能执行了，外面的 DataIO 组件已废除。

运行测试后能够通过 board 查看，胜利的 id：202211031508511267810

http://11.50.52.62:8080/#/history

http://11.50.52.81:8080/#/history

8.4.3. 模型部署

# flow model deploy --model-id arbiter-20001#guest-20002#host-20001#model --model-version 202211031508511267810

输入了产生的 model_version 是 202211031811059832400

1. 批改加载模型的配置

# cat > fateflow/examples/model/publish_load_model.json <<EOF
{
  "initiator": {
    "party_id": "20002",
    "role": "guest"
  },
  "role": {
    "guest": ["20002"],
    "host": ["20001"],
    "arbiter": ["20001"]
  },
  "job_parameters": {
    "model_id": "arbiter-20001#guest-20002#host-20001#model",
    "model_version": "202211031811059832400"
  }
}
EOF

2. 批改绑定模型的配置

# cat > fateflow/examples/model/bind_model_service.json <<EOF
{
    "service_id": "test",
    "initiator": {
        "party_id": "20002",
        "role": "guest"
    },
    "role": {"guest": ["20002"],
        "host": ["20001"],
        "arbiter": ["20001"]
    },
    "job_parameters": {
        "work_mode": 1,
        "model_id": "arbiter-20001#guest-20002#host-20001#model",
        "model_version": "202211031811059832400"
    }
}
EOF

3. 在线测试

发送以下信息到 ”GUEST” 方的推理服务 ”{SERVING\_SERVICE\_IP}:8059/federation/v1/inference”

# curl -X POST -H 'Content-Type: application/json' -i 'http://11.50.52.62:8059/federation/v1/inference' --data '{"head": {"serviceId":"test"},"body": {"featureData": {"x0": 1.88669,"x1": -1.359293,"x2": 2.303601,"x3": 2.00137,"x4": 1.307686},
    "sendToRemoteFeatureData": {"phone_num": "122222222"}
  }
}'

9. 在 Jupyther 中构建工作

Jupyter Notebook 是 web 界面 IDE。已集成在 fate-client 容器中。

10. 总结

本文旨在从宏观的角度剖析 FATE 的源码散布、总体架构、次要性能及外围流程，尚有许多细节和性能未深入研究，欢送大家留言，互相学习。