关于机器学习:联邦学习开源框架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两种计算引擎,搭配不同的通信组件，共五种组合，不同的通信模块不能兼容。

计划名	计算引擎	存储	通信	是否反对exchange	task调度	特点
EggRoll	nodemanager	nodemanager	rollsite	是	clustermanager	原生、最成熟
Spark_RabbitMQ	spark	hdfs	nginx+ rabbit	否	yarn？	简略易上手的MQ
Spark_Pulsar	spark	hdfs	nginx+ pulsar	是	yarn？	比RabbitMQ，能够反对更大规模的集群化部署
Slim FATE	spark_local	localFS	nginx+ pulsar	是	spark？	最小资源。可用rabbit代替pulsar

参考：：《不同类型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类部署形式，单机的装置模式是只提供了单机的装置文档，也能够钻研怎么扩大成集群模式。

部署时会要求配置机器对应的角色，只能选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的源码散布、总体架构、次要性能及外围流程，尚有许多细节和性能未深入研究，欢送大家留言，互相学习。

作者：京东科技 葛星宇