DSL 的配置文件采用 json 格式,实际上,整个配置文件就是一个 json 对象 (dict)。
-
含义: 在这个 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"] } }
-
含义: 用来指定使用的模块。
-
说明: 这个参数的内容需要和组件注册文件夹下的python文件里各个组件的ComponentMeta保持一致。
-
参考:
"hetero_feature_binning_1": { "module": "HeteroFeatureBinning", ... }
- 含义: 上游输入,分为两种输入类型,分别是数据和模型。
-
含义: 上游数据输入,分为四种输入类型:
- 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输入。
- 含义: 上游模型输入,分为两种输入类型:
-
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"] } }
-
- 含义: 输出,与输入一样,分为数据和模型输出
- 含义: 数据输出,分为四种输出类型:
- data: 常规模块数据输出
- train_data: 仅用于Data Split
- validate_data: 仅用于Data Split
- test_data:仅用于Data Split
- 含义: 模型输出,仅使用model
Job Runtime Conf用于设置各个参与方的信息, 作业的参数及各个组件的参数。 内容包括如下:
-
含义: 配置版本,默认为1,fate 1.7或以上的版本需要设置为2
-
参考:
"dsl_version": 2
-
含义: 任务发起方的role和party_id。
-
参考:
"initiator": { "role": "guest", "party_id": 9999 }
-
含义: 各参与方的信息。
-
说明: 在 role 字段中,每一个元素代表一种角色以及承担这个角色的 party_id。每个角色的 party_id 以列表形式存在,因为一个任务可能涉及到多个 party 担任同一种角色。
-
参考:
"role": { "guest": [9999], "host": [10000], "arbiter": [10000] }
- 含义: 配置作业运行时的主要系统参数
-
应用于所有参与方,使用common范围标识符
-
仅应用于某参与方,使用role范围标识符,使用role: {party_index: ...}定位被指定的参与方,直接指定的参数优先级高于common参数
"common": { } "role": { "guest": { "0": { } } }
其中common下的参数应用于所有参与方,role-guest-0配置下的参数应用于guest角色0号下标的参与方 注意,当前版本系统运行参数未对仅应用于某参与方做严格测试,建议使用优先选用common
配置项 | 默认值 | 支持值 | 说明 |
---|---|---|---|
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配置引擎
配置项 | 默认值 | 支持值 | 说明 |
---|---|---|---|
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 | 联邦合作模式: 多站点多方或者单站点模拟多方 |
未开放参数
-
使用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 } } }
1.5.0版本开始,为了进一步管理资源,fateflow启用更细粒度的cpu cores管理策略,去除早前版本直接通过限制同时运行作业个数的策略
- 资源来自于基础引擎,当前版本未实现自动获取基础引擎的资源大小,因此你通过配置文件的方式配置
$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使之生效
计算每个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
- 作业申请资源的计算
- 对于计算引擎为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
- 对于计算引擎为eggroll、standalone
- 作业调度策略
- 按提交时间先后入队
- 目前仅支持FIFO策略,也即每次调度器仅会扫描第一个作业,若第一个作业申请资源成功则start且出队,若申请资源失败则等待下一轮调度
- 资源申请规则
- 调度器依据上述调度策略选出作业,分发联邦多方资源申请指令到所有参与方
- 若所有参与方均申请资源成功(total_cores - apply_cores > 0),则该作业申请资源成功
- 若非所有参与方均申请资源成功,则发送资源回滚指令到已申请成功的参与方,该作业申请资源失败
-
应用于所有参与方,使用common范围标识符
-
仅应用于某参与方,使用role范围标识符,使用role: {party_index: ...} 定位被指定的参与方,直接指定的参数优先级高于common参数
"commom": { } "role": { "guest": { "0": { } } }
其中common配置下的参数应用于所有参与方,role-guest-0配置下的参数表示应用于guest角色0号下标的参与方 注意,当前版本组件运行参数已支持两种应用范围策略
-
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" } } } } }
多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" } } } } } }
DSL V2不会自动为训练任务生成预测dsl。 用户需要首先使用Flow Client 部署所需模型中模块。 详细命令说明请参考FATE-Flow document
$ flow model deploy --model-id $model_id --model-version $model_version --cpn-list ...
可选地,用户可以在预测dsl中加入新模块,如Evaluation
训练 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"
]
}
}
}
- 提交作业后,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执行