FATE学习：配置文件解析及V1/V2版本对比
综述
为了让任务模型的构建更加灵活，目前 FATE 使用了一套自定的领域特定语言 (DSL) 来描述任务。
在 DSL 中，各种模块（例如数据读写 data_io，特征工程 feature-engineering， 回归 regression，分类 classification）可以通向一个有向无环图 （DAG） 组织起来。通过各种方式，用户可以根据自身的需要，灵活地组合各种算法模块。
除此之外，每个模块都有不同的参数需要配置，不同的 party 对于同一个模块的参数也可能有所区别。为了简化这种情况，对于每一个模块，FATE 会将所有 party 的不同参数保存到同一个运行配置文件（Submit Runtime Conf）中，并且所有的 party 都将共用这个配置文件。
在实际的使用中（以命令行提交为例），通过-d 参数指定 DSL配置文件，通多-c 参数指定 Run Time Conf 配置文件。
对于像upload 这样单机、单模块的任务，只需要指定Run Time Conf 配置文件，而不需要指定 DSL文件。
python fate_flow_client.py -f upload -c upload_guest.json
而对于train、predict 这类多个模块组成的pipeline 而言，则需要分别指定DSL配置文件和Run Time Conf 配置文件。例如
python fate_flow_client.py -f submit_job -c train_conf.json -d train_job_dsl.json
在FATE1.5 之后的版本，对DSL进行了升级，从原来的v1版本升级到了v2版本，改动包括
- v2主要是统一了提交任务配置格式，具体改动在可以看下job_parameters和component_parameters)
- 可以多次生成预测配置（v1是自动生成的，万一训练阶段的need_deploy设置有问题就没得再改了）
- 预测阶段可编辑增加新组件等。
根据官方说法，后面会逐渐废弃v1，so…
使用版本 FATE 1.5.1
DSL配置文件结构解析
DSL的配置文件采用json格式，在实际的解析中，会解析成python中的dict对象。依照不同的层级的key来获取对应的value。
以v1 版本为例，以下配置文件来自源码examples/dsl/v1/hetero_logistic_regression/test_hetero_lr_train_job_dsl.json
{
"components" : {
"dataio_0": {
"module": "DataIO",
"input": {
"data": {
"data": [
"args.train_data"
]
}
},
"output": {
"data": ["train"],
"model": ["dataio"]
}
},
"intersection_0": {
"module": "Intersection",
"input": {
"data": {
"data": [
"dataio_0.train"
]
}
},
"output": {
"data": ["train"]
}
},
"hetero_lr_0": {
"module": "HeteroLR",
"input": {
"data": {
"train_data": ["intersection_0.train"]
}
},
"output": {
"data": ["train"],
"model": ["hetero_lr"]
}
},
"evaluation_0": {
"module": "Evaluation",
"input": {
"data": {
"data": ["hetero_lr_0.train"]
}
}
}
}
}
第一级的key 是components，用来表示这个任务将会使用到的各个模块。
按照上面的例子，第二级的key有四个，dataio_0，intersection_0，hetero_lr_0，evaluation_0。也就是这个算法涉及的模块，即example中定义的hetero_logistic_regression 包含四个模块，读取数据，求交，训练，评估。
每个模块主要包括三个第三级的key
module
用来指定使用的模块。value 的值需要和 federatedml/conf/setting_conf 下各个模块的文件名保持一致
input
包含2种输入类型Data和Model，涉及3种第四级的key，data ，model和isometric_model
- Data 包含3种第五级的key，即有3种可能的输入类型
- data：一般被用于 data_io 模块, feature_engineering 模块或者 evaluation 模块
- train_data：一般被用于 homo_lr, heero_lr 和 secure_boost 模块。如果出现了 train_data 字段，那么这个任务将会被识别为一个 fit 任务
- eval_data：如果存在 train_data 字段，那么该字段是可选的。如果选择保留该字段，则 eval_data 指向的数据将会作为 validation set。若不存在 train_data 字段，则这个任务将被视作为一个 predict 或 transform 任务。
- Model 有两种可能
- model: 用于同种类型组件的模型输入。例如，hetero_binning_0 会对模型进行 fit，然后 hetero_binning_1 将会使用 hetero_binning_0 的输出用于 predict 或 transform。
"hetero_feature_binning_1": { "module": "HeteroFeatureBinning", "input": { "data": { "data": [ "dataio_1.eval_data" ] }, "model": [ "hetero_feature_binning_0.fit_model" ] }, "output": { "data": ["eval_data"], "model": ["eval_model"] } }- isometric_model: 用于指定继承上游组件的模型输入。 例如，feature selection 的上游组件是 feature binning，它将会用到 feature binning 的信息来作为 feature importance。
"hetero_feature_selection_0": {
"module": "HeteroFeatureSelection",
"input": {
"data": {
"data": [
"hetero_feature_binning_0.train"
]
},
"isometric_model": [
"hetero_feature_binning_0.output_model"
]
},
"output": {
"data": ["train"],
"model": ["output_model"]
}
}
output
和 input 一样，有 data 和 model 两种类型
Tips
Tips：name
需要注意的是，这里定义的模块的名字，dataio_0 在job的create阶段[https://blog.csdn.net/yao544303963/article/details/119878240?spm=1001.2014.3001.5501]，会用于生成task的名字，并将该task的元数据写入DB。后续job中task 涉及的组件都通过这个名字和DSL文件对应起来。
如当前job涉及两份数据的dataio, 通过递增编号加以区分，如：dataio_0 和 dataio_1。
Tips：顺序
通过观察上述DSL，可以发现，上一个模块的name 和 output中 “data” 的value 组成了下一个模块的input 的value，如dataio_0.train。这样，就将所有的模块串起来，构成了job的DAG，也即在fate board 界面看到的内容。
DSL v1 v2 版本对比
对比v2 的DSL，源文件为examples/dsl/v2/hetero_logistic_regression/hetero_lr_normal_dsl.json
为了便于对比，调整了一下参数的格式，在dsl部分，v2只是新增了reader 模块，其余变化不大。
Run Time Conf配置文件结构解析（v1)
Run Time Conf 也采用json的方式，用来设置各个各参数。
以v1 版本为例，以下配置文件来自源码examples/dsl/v1/hetero_logistic_regression/test_hetero_lr_train_job_conf.json
{
"initiator": {
"role": "guest",
"party_id": 10000
},
"job_parameters": {
"work_mode": 0
},
"role": {
"guest": [
10000
],
"host": [
10000
],
"arbiter": [
10000
]
},
"role_parameters": {
"guest": {
"args": {
"data": {
"train_data": [
{
"name": "breast_hetero_guest",
"namespace": "experiment"
}
],
"eval_data": [
{
"name": "breast_hetero_guest",
"namespace": "experiment"
}
]
}
},
"dataio_0": {
"with_label": [
true
],
"label_name": [
"y"
],
"label_type": [
"int"
],
"output_format": [
"dense"
],
"missing_fill": [
true
],
"outlier_replace": [
true
]
},
"evaluation_0": {
"eval_type": [
"binary"
],
"pos_label": [
1
]
}
},
"host": {
"args": {
"data": {
"train_data": [
{
"name": "breast_hetero_host",
"namespace": "experiment"
}
],
"eval_data": [
{
"name": "breast_hetero_host",
"namespace": "experiment"
}
]
}
},
"dataio_0": {
"with_label": [
false
],
"output_format": [
"dense"
],
"outlier_replace": [
true
]
},
"evaluation_0": {
"need_run": [
false
]
}
}
},
"algorithm_parameters": {
"hetero_lr_0": {
"penalty": "L2",
"optimizer": "rmsprop",
"tol": 0.0001,
"alpha": 0.01,
"max_iter": 30,
"early_stop": "diff",
"batch_size": -1,
"learning_rate": 0.15,
"init_param": {
"init_method": "zeros"
},
"sqn_param": {
"update_interval_L": 3,
"memory_M": 5,
"sample_size": 5000,
"random_seed": null
},
"cv_param": {
"n_splits": 5,
"shuffle": false,
"random_seed": 103,
"need_cv": false
}
},
"intersect_0": {
"intersect_method": "rsa",
"sync_intersect_ids": true,
"only_output_key": false
}
}
}
包含如下几个一级key:
- initiator：在运行配置的开头，用户需要定义 initiator。
- job_parameters：设置workmode 等参数。
- role：所有参与这个任务的 roles 都需要在运行配置中指定。在 role 字段中，每一个元素代表一种角色以及承担这个角色的 party_id。每个角色的
- party_id 以列表形式存在，因为一个任务可能涉及到多个 party 担任同一种角色。
- role_parameters：这一部分的参数对于不同的 role 都有所区别。同样地，每一个参数也是用列表的方式呈现。在 role_parameters 中，role 名被作为每一项元素的 key，而 value 则是具体提的参数内容。就像上面这个例子，对于每一个 party，它们的输入参数 train_data， eval_data 都应该以列表形式存在。name 和 namespace 字段则是用来指定用来上传数据的表格位置。用户还可以分别配置每一个组件的参数。组件名需要和 DSL 配置文件中的组件名保持一致。每个组件具体的参数列表可以在 federatedml/param 的 Param 类中找到。
- algorithm_parameters：如果用户希望定义一些所有 party 都共享的参数，那么可以在 algorithm_parameters 中设置。 algorithm_parameters 里面的参数不需要额外处理，FATE 会自动把这些参数复制给每一个 party。
Run Time Conf配置文件v1 v2 版本对比
以v2 版本为例，以下配置文件来自源码examples/dsl/v2/hetero_logistic_regression/hetero_lr_normal_conf.json
{
"dsl_version": 2,
"initiator": {
"role": "guest",
"party_id": 10000
},
"role": {
"guest": [
10000
],
"host": [
9999
],
"arbiter": [
9999
]
},
"job_parameters": {
"common": {
"job_type": "train",
"backend": 0,
"work_mode": 0
}
},
"component_parameters": {
"common": {
"dataio_0": {
"output_format": "dense"
},
"hetero_lr_0": {
"penalty": "L2",
"tol": 0.0001,
"alpha": 0.01,
"optimizer": "rmsprop",
"batch_size": -1,
"learning_rate": 0.15,
"init_param": {
"init_method": "zeros"
},
"max_iter": 30,
"early_stop": "diff",
"cv_param": {
"n_splits": 5,
"shuffle": false,
"random_seed": 103,
"need_cv": false
},
"sqn_param": {
"update_interval_L": 3,
"memory_M": 5,
"sample_size": 5000,
"random_seed": null
}
},
"evaluation_0": {
"eval_type": "binary"
}
},
"role": {
"host": {
"0": {
"dataio_0": {
"with_label": false
},
"reader_0": {
"table": {
"name": "breast_hetero_host",
"namespace": "experiment"
}
}
}
},
"guest": {
"0": {
"dataio_0": {
"with_label": true
},
"reader_0": {
"table": {
"name": "breast_hetero_guest",
"namespace": "experiment"
}
}
}
}
}
}
}
整体变化，汇总如下表
无变化的一级key
- initiator
- role
更新之后的一级key
- dsl_version：新增，用来表示版本，如
"dsl_version": "2"
- job_parameters：新增二级key common 和 role用于区分公用配置和专属配置。应用于所有参与方，使用common范围标识符
仅应用于某参与方，使用role范围标识符，使用role.party_index定位被指定的参与方，直接指定的参数优先级高于common参数。
相比v1，新增或调整了以下类型的参数：- backend相关参数： 支持更为丰富
- 资源管理相关参数：为了进一步管理资源，fateflow启用更细粒度的cpu cores管理策略，去除早前版本直接通过限制同时运行作业个数的策略，参考资源管理详细说明
更多细节参考支持的系统参数
- component_parameters：类似job_parameters，将了v1中的algorithm_parameters调整到了common中，应用于所有参与方。将v1中的role_parameters调整到了role中，使用role.party_index定位被指定的参与方，直接指定的参数优先级高于common参数。
源码解析
涉及源码位于 python/fate_flow/scheduler/dsl_parser.py
主要功能为解析json 生成各项参数。
REF
- DSL 配置和运行配置 V1
- 任务配置和运行配置 V2