架构

先来看一个官方给的架构图，
简单来说，提供了client和board两种客户端，访问fate的flow server完成了任务flow的调度。整个任务流官网也很中肯的定义为Pipeline。Pipeline有点像开发常用的jenkins，一个任务完成后触发后续任务，直到所有任务结束。

• • image.png

FATE-Flow联邦学习Pipeline

FATE-Flow是用于联邦学习的端到端Pipeline系统，它由一系列高度灵活的组件构成,专为高性能的联邦学习任务而设计。其中包括数据处理、建模、训练、验证、发布和在线推理等功能。官方给的一个示例图如下：

• • image.png

DSL示例

流的调度抽象来看是一个DAG图的调度，这个DAG是通过DSL描述，下面给出一个DSL的示例：

{
    "components" : {
        "dataio_0": {
            "module": "DataIO",
            "input": {
                "data": {
                    "data": [
                        "args.train_data"
                    ]
                }
            },
            "output": {
                "data": ["train"],
                "model": ["dataio"]
            },
            "need_deploy": true
         },
        "hetero_feature_binning_0": {
            "module": "HeteroFeatureBinning",
            "input": {
                "data": {
                    "data": [
                        "dataio_0.train"
                    ]
                }
            },
            "output": {
                "data": ["train"],
                "model": ["hetero_feature_binning"]
            }
        },
        "hetero_feature_selection_0": {
            "module": "HeteroFeatureSelection",
            "input": {
                "data": {
                    "data": [
                        "hetero_feature_binning_0.train"
                    ]
                },
                "isometric_model": [
                    "hetero_feature_binning_0.hetero_feature_binning"
                ]
            },
            "output": {
                "data": ["train"],
                "model": ["selected"]
            }
        },
        "hetero_lr_0": {
            "module": "HeteroLR",
            "input": {
                "data": {
                    "train_data": ["hetero_feature_selection_0.train"]
                }
            },
            "output": {
                "data": ["train"],
                "model": ["hetero_lr"]
            }
        },
        "evaluation_0": {
            "module": "Evaluation",
            "input": {
                "data": {
                    "data": ["hetero_lr_0.train"]
                }
            },
            "output": {
                "data": ["evaluate"]
            }
        }
    }
}

DSL的抽象

上面的DSL示例子有点庞大，这里可以做如下抽象

• • image.png

还是上面的DSL
组件ID，用来标识组件身份， 比如"dataio_0"
组件元数据：运行模块，基本属性，比如： "module": "DataIO", "need_deploy": true
运行时数据：输入 + 输出（再进一步抽象就是输出输出类型和值）

fate_flow_server启动分析

过程做的几件事：
1 加载各manager
2 初始化两个信号SIGTERM(软件终止信号), SIGCHLD(当子进程停止或退出时通知父进程)
3 初始化数据库表
4 Job环境初始化：环境变量，队列，权限，ZK等
5 启动轮训线程，用于轮训可调度任务
6 启动rpc服务，用的grpc框架。 补充知识，几个rpc方式的对比
7 异常中断后最后延迟1天退出

Fate的代码解析

一般的服务端分成和fate的分层略有差异，这个是编程风格的原因，没有好坏，我这里给出一个对应关心，左边是fate的分层，app->manager->db，很flask的风格，但是Django和阿里出的java开发规范会更建议右边的风格，对应关系如下：

• fate的app其实对应的是接口层，java中一般叫做controller层，为什么不用app呢，因为一般我们把app当作一个确定的微服务，在部署上，一个app对应一个port或者一个ip:port

• manger其实是核心逻辑，java中一般是service，通用逻辑再抽象出manager

• db是数据层，fate中，db下存放的是db_models，一般我们会像右边抽象出DO和DAO层来访问数据库。

• • image.png

整个fate的核心逻辑放在以下几个manager中：

• model_manger
  • 模型管理
• data_manager
  • 数据库操作，对应DAO
• pipeline_manager
  • pipeline管理，dag解析主要在这里
  • dag的解析在driver层
• queue_manager
  • 队列管理，事件
• tracking_manager
  • 相当于全局同步管理期，管理任务，job的持久化和结果同步