FATE —— 三.1 使用DSL json conf任务配置和运行配置 V2
DSL 配置说明
1. 概述
DSL 的配置文件采用 json 格式，实际上，整个配置文件就是一个 json 对象 （dict）。
2. Components
含义： 在这个 dict 的第一级是 "components"，用来表示这个任务将会使用到的各个模块。
参考：
{
"components" : {
...
}
}说明：
每个独立的模块定义在 "components" 之下，例如：
"data_transform_0": {
"module": "DataTransform",
"input": {
"data": {
"data": [
"reader_0.train_data"
]
}
},
"output": {
"data": ["train"],
"model": ["model"]
}
}所有数据需要通过Reader模块从数据存储拿取数据，注意此模块仅有输出output
"reader_0": {
"module": "Reader",
"output": {
"data": ["train"]
}
}3. 模块
含义： 用来指定使用的模块。
说明： 这个参数的内容需要和组件注册文件夹下的python文件里各个组件的ComponentMeta保持一致。
参考：
"hetero_feature_binning_1": {
"module": "HeteroFeatureBinning",
...
}4. 输入
含义： 上游输入，分为两种输入类型，分别是数据和模型。
4.1 数据输入
含义： 上游数据输入，分为四种输入类型：
data: 一般被用于 data-transform模块, feature_engineering 模块或者 evaluation 模块
train_data: 一般被用于 homo_lr, hetero_lr 和 secure_boost 模块。如果出现了 train_data 字段，那么这个任务将会被识别为一个 fit 任务
validate_data： 如果存在 train_data 字段，那么(验证_数据)该字段是可选的。如果选择保留该字段，则指向的数据将会作为 validation set
test_data: 用作预测数据，如提供，需同时提供model输入。
4.2 模型输入
含义： 上游模型输入，分为两种输入类型：
model: 用于同种类型组件的模型输入。例如，hetero_binning_0 会对模型进行 fit，然后 hetero_binning_1 将会使用 hetero_binning_0 的输出用于 predict 或 transform。代码示例：
"hetero_feature_binning_1": {
"module": "HeteroFeatureBinning",
"input": {
"data": {
"data": [
"data_transform_1.validate_data"
]
},
"model": [
"hetero_feature_binning_0.fit_model"
]
},
"output": {
"data": ["validate_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"]
}
}5. 输出
含义： 输出，与输入一样，分为数据和模型输出
5.1 数据输出
含义： 数据输出，分为四种输出类型：
data: 常规模块数据输出
train_data: 仅用于Data Split
validate_data: 仅用于Data Split
test_data：仅用于Data Split
5.2 模型输出
含义： 模型输出，仅使用model
JOB RUNTIME CONFIG配置说明，针对1.5.x版本新格式
1. 概述
Job Runtime Conf用于设置各个参与方的信息, 作业的参数及各个组件的参数。 内容包括如下：
2. DSL版本
含义： 配置版本，默认为1，fate 1.7或以上的版本需要设置为2
参考：
"dsl_version": 23. 作业参与方
3.1 发起方
含义： 任务发起方的role和party_id。
参考：
"initiator": {
"role": "guest",
"party_id": 9999
}3.2 所有参与方
含义： 各参与方的信息。
说明： 在 role 字段中，每一个元素代表一种角色以及承担这个角色的 party_id。每个角色的 party_id 以列表形式存在，因为一个任务可能涉及到多个 party 担任同一种角色。
参考：
"role": {
"guest": [9999],
"host": [10000],
"arbiter": [10000]
}4. 系统运行参数
含义： 配置作业运行时的主要系统参数
4.1 参数应用范围策略设置
应用于所有参与方，使用common范围标识符
仅应用于某参与方，使用role范围标识符，使用role: {party_index: ...}定位被指定的参与方，直接指定的参数优先级高于common参数
"common": {
}
"role": {
"guest": {
"0": {
}
}
}其中common下的参数应用于所有参与方，role-guest-0配置下的参数应用于guest角色0号下标的参与方注意，当前版本系统运行参数未对仅应用于某参与方做严格测试，建议使用优先选用common
4.2 支持的系统参数
配置项 |
默认值 |
支持值 |
说明 |
inheritance_info |
无 |
job_id, component_list |
需要被继承的任务的jobid和组件名列表 |
job_type |
train |
train, predict |
任务类型 |
task_cores |
4 |
正整数 |
作业申请的总cpu核数 |
task_parallelism |
1 |
正整数 |
task并行度 |
computing_partitions |
task所分配到的cpu核数 |
正整数 |
计算时数据表的分区数 |
eggroll_run |
无 |
processors_per_node等 |
eggroll计算引擎相关配置参数，一般无须配置，由task_cores自动计算得到，若配置则task_cores参数不生效 |
spark_run |
无 |
num-executors, executor-cores等 |
spark计算引擎相关配置参数，一般无须配置，由task_cores自动计算得到，若配置则task_cores参数不生效 |
rabbitmq_run |
无 |
queue, exchange等 |
rabbitmq创建queue、exchange的相关配置参数，一般无须配置，采取系统默认值 |
pulsar_run |
无 |
producer, consumer等 |
pulsar创建producer和consumer时候的相关配置，一般无需配置。 |
federated_status_collect_type |
PUSH |
PUSH, PULL |
多方运行状态收集模式，PUSH表示每个参与方主动上报到发起方，PULL表示发起方定期向各个参与方拉取 |
timeout |
259200 (3天) |
正整数 |
任务超时时间,单位秒 |
model_id |
- |
- |
模型id，预测任务需要填入 |
model_version |
- |
- |
模型version，预测任务需要填入 |
支持的系统参数
!!! Note
1. 计算引擎和存储引擎之间具有一定的支持依赖关系
2. 开发者可自行实现适配的引擎，并在runtime config配置引擎4.3 未开放参数
配置项 |
默认值 |
支持值 |
说明 |
computing_engine |
service_conf.yaml配置 |
EGGROLL, SPARK, STANDALONE |
计算引擎类型 |
storage_engine |
service_conf.yaml配置 |
EGGROLL, HDFS, STANDALONE, LOCALFS |
组件输出中间数据存储引擎类型 |
federation_engine |
service_conf.yaml配置 |
EGGROLL, RABBITMQ, STANDALONE, PULSAR |
通信引擎类型 |
federated_mode |
依据federation_engine自动得到 |
SINGLE, MULTIPLE |
联邦合作模式: 多站点多方或者单站点模拟多方 |
未开放参数
4.4 参考配置
使用eggroll作为computing engine，采取默认cpu分配计算策略时的配置
"job_parameters": {
"common": {
"job_type": "train",
"task_cores": 6,
"task_parallelism": 2,
"computing_partitions": 8,
"timeout": 36000
}
}使用eggroll作为computing engine，采取直接指定cpu等参数时的配置
"job_parameters": {
"common": {
"job_type": "train",
"eggroll_run": {
"eggroll.session.processors.per.node": 2
},
"task_parallelism": 2,
"computing_partitions": 8,
"timeout": 36000,
}
}使用spark作为computing engine，rabbitmq作为federation engine,采取直接指定cpu等参数时的配置
"job_parameters": {
"common": {
"job_type": "train",
"spark_run": {
"num-executors": 1,
"executor-cores": 2
},
"task_parallelism": 2,
"computing_partitions": 8,
"timeout": 36000,
"rabbitmq_run": {
"queue": {
"durable": true
},
"connection": {
"heartbeat": 10000
}
}
}
}使用spark作为computing engine，pulsar作为federation engine
"job_parameters": {
"common": {
"spark_run": {
"num-executors": 1,
"executor-cores": 2
}
}
}4.5 资源管理详细说明
1.5.0版本开始，为了进一步管理资源，fateflow启用更细粒度的cpu cores管理策略，去除早前版本直接通过限制同时运行作业个数的策略
4.5.1 总资源配置
资源来自于基础引擎，当前版本未实现自动获取基础引擎的资源大小，因此你通过配置文件的方式配置$PROJECT_BASE/conf/service_conf.yaml指定，fateflow server启动时从配置文件扫描所有基础引擎信息并注册到数据库表t_engine_registry
fate_on_eggroll：total_cores=cores_per_node*nodes
fate_on_spark：total_cores=cores_per_node*nodes
fate_on_standalone：total_cores=cores_per_node*nodes
不同基础引擎间的资源计算互相隔离
以上配置修改后均需要重启fateflow server使之生效
4.5.2 运行资源计算
计算每个task实际提交到计算引擎的task_run_cores，但并不代表资源调度时的申请量
job conf使用task_cores配置：
task_run_cores(guest, host)：max(task_cores / total_nodes, 1) * total_nodes
task_run_cores(arbiter)：max(1 / total_nodes, 1) * total_nodes
fateflow会将参数自动转换为对应引擎的实际配置参数，如eggroll的eggroll.session.processors.per.node，spark的executor-cores和num-executors
job conf使用eggroll_run配置：
task_run_cores(guest, host, arbiter)：eggroll.session.processors.per.node * total_nodes
job conf使用spark_run配置：
task_run_cores(guest, host, arbiter)：executor-cores * num-executors
4.5.3 资源调度
作业申请资源的计算
对于计算引擎为eggroll、standalone
apply_cores(guest, host)：task_run_cores * task_parallelism
apply_cores(arbiter)：0，因为实际上仅消耗极少量资源且eggroll暂仅支持配置所有node节点cores一致，因此为了避免nodes太多导致arbiter资源扣减资源太多影响作业排队，所以资源调度计算时设为0
此处注意，在eggroll集群上，arbiter依然会在每个node被分配了task_run_cores/nodes个cores
对于计算引擎为spark
对于spark，支持executor-cores * num-executors，不与集群nodes数强相关，尤其spark本身有资源调度器，如果此处资源调度计算与实际提交不一致，可能会导致spark作业一直等待
apply_cores(guest, host, arbiter)：task_run_cores * task_parallelism
作业调度策略
按提交时间先后入队
目前仅支持FIFO策略，也即每次调度器仅会扫描第一个作业，若第一个作业申请资源成功则start且出队，若申请资源失败则等待下一轮调度
资源申请规则
调度器依据上述调度策略选出作业，分发联邦多方资源申请指令到所有参与方
若所有参与方均申请资源成功(total_cores - apply_cores > 0)，则该作业申请资源成功
若非所有参与方均申请资源成功，则发送资源回滚指令到已申请成功的参与方，该作业申请资源失败
5. 组件运行参数
5.1 参数应用范围策略设置
应用于所有参与方，使用common范围标识符
仅应用于某参与方，使用role范围标识符，使用role: {party_index: ...} 定位被指定的参与方，直接指定的参数优先级高于common参数
"commom": {
}
"role": {
"guest": {
"0": {
}
}
}其中common配置下的参数应用于所有参与方，role-guest-0配置下的参数表示应用于guest角色0号下标的参与方 注意，当前版本组件运行参数已支持两种应用范围策略
5.2 参考配置
intersection_0与hetero_lr_0两个组件的运行参数，放在common范围下，应用于所有参与方
对于reader_0与data_transform_0两个组件的运行参数，依据不同的参与方进行特定配置，这是因为通常不同参与方的输入参数并不一致，所有通常这两个组件一般按参与方设置
上述组件名称是在DSL配置文件中定义
"component_parameters": {
"common": {
"intersection_0": {
"intersect_method": "raw",
"sync_intersect_ids": true,
"only_output_key": false
},
"hetero_lr_0": {
"penalty": "L2",
"optimizer": "rmsprop",
"alpha": 0.01,
"max_iter": 3,
"batch_size": 320,
"learning_rate": 0.15,
"init_param": {
"init_method": "random_uniform"
}
}
},
"role": {
"guest": {
"0": {
"reader_0": {
"table": {"name": "breast_hetero_guest", "namespace": "experiment"}
},
"data_transform_0":{
"with_label": true,
"label_name": "y",
"label_type": "int",
"output_format": "dense"
}
}
},
"host": {
"0": {
"reader_0": {
"table": {"name": "breast_hetero_host", "namespace": "experiment"}
},
"data_transform_0":{
"with_label": false,
"output_format": "dense"
}
}
}
}
}5.3 多Host 配置
多Host任务应在role下列举所有host信息
样例:
"role": {
"guest": [
10000
],
"host": [
10000, 10001, 10002
],
"arbiter": [
10000
]
}各host不同的配置应在各自对应模块下分别列举
样例:
"component_parameters": {
"role": {
"host": {
"0": {
"reader_0": {
"table":
{
"name": "hetero_breast_host_0",
"namespace": "hetero_breast_host"
}
}
},
"1": {
"reader_0": {
"table":
{
"name": "hetero_breast_host_1",
"namespace": "hetero_breast_host"
}
}
},
"2": {
"reader_0": {
"table":
{
"name": "hetero_breast_host_2",
"namespace": "hetero_breast_host"
}
}
}
}
}
}5.4 预测任务配置
5.4.1 说明
DSL V2不会自动为训练任务生成预测dsl。 用户需要首先使用Flow Client 部署所需模型中模块。 详细命令说明请参考FATE-Flow document
$ flow model deploy --model-id $model_id --model-version $model_version --cpn-list ...可选地，用户可以在预测dsl中加入新模块，如Evaluation
5.4.2 样例
训练 dsl：
"components": {
"reader_0": {
"module": "Reader",
"output": {
"data": [
"data"
]
}
},
"data_transform_0": {
"module": "DataTransform",
"input": {
"data": {
"data": [
"reader_0.data"
]
}
},
"output": {
"data": [
"data"
],
"model": [
"model"
]
}
},
"intersection_0": {
"module": "Intersection",
"input": {
"data": {
"data": [
"data_transform_0.data"
]
}
},
"output": {
"data":[
"data"
]
}
},
"hetero_nn_0": {
"module": "HeteroNN",
"input": {
"data": {
"train_data": [
"intersection_0.data"
]
}
},
"output": {
"data": [
"data"
],
"model": [
"model"
]
}
}
}
预测 dsl:
"components": {
"reader_0": {
"module": "Reader",
"output": {
"data": [
"data"
]
}
},
"data_transform_0": {
"module": "DataTransform",
"input": {
"data": {
"data": [
"reader_0.data"
]
}
},
"output": {
"data": [
"data"
],
"model": [
"model"
]
}
},
"intersection_0": {
"module": "Intersection",
"input": {
"data": {
"data": [
"data_transform_0.data"
]
}
},
"output": {
"data":[
"data"
]
}
},
"hetero_nn_0": {
"module": "HeteroNN",
"input": {
"data": {
"train_data": [
"intersection_0.data"
]
}
},
"output": {
"data": [
"data"
],
"model": [
"model"
]
}
},
"evaluation_0": {
"module": "Evaluation",
"input": {
"data": {
"data": [
"hetero_nn_0.data"
]
}
},
"output": {
"data": [
"data"
]
}
}
}6. 基本原理
提交作业后，fateflow获取job dsl与job config，存于数据库t_job表对应字段以及$PROJECT_BASE/fateflow/jobs/$jobid/目录
解析job dsl与job config，依据合并参数生成细粒度参数, 以及处理参数默认值
将共同配置分发到各参与方并存储，依据参与方的实际信息，生成job_runtime_on_party_conf，同样存于数据库与jobs目录
每个参与方接收到任务时，均依据job_runtime_on_party_conf执行