- 一、上传数据
- 1.1 上传数据配置文件
- 1.2 上传数据命令
- 二、任务配置和运行配置
- 2.1 DSL 配置文件
- 2.1.1 DataIO
- 2.2 运行配置 Submit Runtime Conf
- first_test
- 参考资料
//upload_data.json
{
"file": "examples/data/breast_hetero_guest.csv", //所上传的csv文件
"table_name": "hetero_breast_guest", //存储数据表的表名
"namespace": "experiment", //存储数据表的命名空间
"head": 1, //指定数据文件是否包含表头，1包含，0不包含
"partition": 8, // 指定用于存储数据的分区数
"work_mode": 0, //指定工作模式，0代表单机版，1代表集群版
"backend": 0 //指定后端，0代表EGGROLL， 1代表SPARK加RabbitMQ， 2代表SPARK加Pulsar
}
1.2 上传数据命令
//使用fate-flow方式上传数据 (FATE版本1.6.0单机部署，docker:fate) python /fate/python/fate_flow/fate_flow_client.py -f upload -c upload_data.json
（不同版本fate_flow_client.py的位置可能不同）
二、任务配置和运行配置版本1.5.0以前的FATE适用V1规则
版本1.5.0以后的FATE适用V2规则，可兼容V1
此处主要介绍V2，对V1稍做补充
components表示将会使用到的各个模块
每个独立的模块定义在在"components" 之下，使用模块名加 _num 作为对应模块的 key，如"dataio_0"
所有数据需要通过Reader模块从数据存储拿取数据，此模块仅有输出output
{
"components" : {
"reader_0": {
"module": "Reader",
"output": {
"data": ["train"]
}
}
"dataio_0": {
"module": "DataIO",
"input": {
"data": {
"data": [
"reader_0.train_data" //通过Reader模块拿数据
]
}
},
"output": {
"data": ["train"],
"model": ["dataio"]
}
}
...
}
}
参数说明
-
module
指定使用的模块，需要和 federatedml/conf/setting_conf 下各个模块的文件名保持一致 -
input
分为两种输入类型，分别是 data 和 model
data：有四种可能的输入类型：
* data（一般被用于data_io 模块、feature_engineering 模块或者 evaluation 模块）
* train_data（一般被用于 homo_lr, heero_lr 和 secure_boost 模块，出现train_data的任务将会被识别为一个fit任务）
* validate_data（如果存在 train_data 字段，则 eval_data 指向的数据将会作为 validation set。若不存在 train_data 字段，则这个任务将被视作为一个predict 或 transform 任务）
* test_data（用作预测数据，如提供，需同时提供model输入）
model：有两种可能的输入类型：
* model（用于同种类型组件的模型输入）
* isometric_model（用于指定继承上游组件的模型输入） -
output
和 input一样，有 data 和 model 两种类型
data：有四种可能的输出类型：
* data（常规模块数据输出）
* train_data: 仅用于Data Split数据分割
* validate_data: 仅用于Data Split
* test_data： 仅用于Data Split
model：只使用model
"dataio_0": {
"module": "DataIO",
"input": {
"data": {
"data": [
"args.train_data"
]
}
},
"output": {
"data": ["train"],
"model": ["dataio"]
},
"need_deploy": true
}
2.2 运行配置 Submit Runtime Conf
设置各个参与方的信息, 作业的参数及各个组件的参数
内容包括如下：
- 首先说明是V2版本
"dsl_version": "2"
- initiator
任务发起方
"initiator": {
"role": "guest",
"party_id": 9999
}
- role
所有参与方的信息
每一个元素代表一种角色以及承担这个角色的 party_id。每个角色的 party_id 以列表形式存在，因为一个任务可能涉及到多个 party 担任同一种角色。
"role": {
"guest": [9999],
"host": [10000],
"arbiter": [10000]
}
guest代表数据应用方。Guest是数据应用方，在纵向模型的建模中往往是有y的一方。通常整个建模任务通常是服务于y的业务逻辑的，因此也只有guest需要应用这一模型。同时，如果允许Host方任意发起建模流程，有可能会有Guest方的数据泄露风险。
host是数据提供方。
arbiter仲裁器/仲裁者是用来辅助多方完成联合建模的，它的主要作用是聚合梯度或者模型。比如纵向lr里面，各方将自己一半的梯度发送给arbiter，然后arbiter再联合优化等等。（集中式拓扑）
local是指本地任务, 该角色仅用于upload和download阶段中。
- role_parameters
这一部分的参数对于不同的 party 都有所区别 - job_parameters
- component_parameters
- algorithm_parameters
（待研究）
Python容器中：
docker exec -it confs-xxxx_python_1 bash //进入容器 cd fate_flow python fate_flow_client.py -f upload -c examples/upload_host.json
Client容器中：
//进入容器 docker exec -it confs-xxxx_client_1 bash //上传数据 cd /data/projects/fate/examples/first_test/data/ flow data upload -c test_upload_train.json --drop //guest和host都需执行此步 //提交任务 cd /data/projects/fate/examples/first_test/ flow job submit -c ./test_conf.json -d ./test_dsl.json参考资料
FATE官方API：https://fate.readthedocs.io/en/latest/?badge=latest
《联邦学习实践》相关文档：https://github.com/FederatedAI/Practicing-Federated-Learning
