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 数据输入

  • 含义: 上游数据输入,分为四种输入类型:

  1. data: 一般被用于 data-transform模块, feature_engineering 模块或者 evaluation 模块

  1. train_data: 一般被用于 homo_lr, hetero_lr 和 secure_boost 模块。如果出现了 train_data 字段,那么这个任务将会被识别为一个 fit 任务

  1. validate_data: 如果存在 train_data 字段,那么(验证_数据)该字段是可选的。如果选择保留该字段,则指向的数据将会作为 validation set

  1. test_data: 用作预测数据,如提供,需同时提供model输入。

4.2 模型输入

  • 含义: 上游模型输入,分为两种输入类型:

  1. 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"]
    }
}
  1. 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 数据输出

  • 含义: 数据输出,分为四种输出类型:

  1. data: 常规模块数据输出

  1. train_data: 仅用于Data Split

  1. validate_data: 仅用于Data Split

  1. 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": 2

3. 作业参与方

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 参考配置

  1. 使用eggroll作为computing engine,采取默认cpu分配计算策略时的配置

"job_parameters": {
  "common": {
    "job_type": "train",
    "task_cores": 6,
    "task_parallelism": 2,
    "computing_partitions": 8,
    "timeout": 36000
  }
}
  1. 使用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,
  }
}
  1. 使用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
      }
    }
  }
}
  1. 使用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,但并不代表资源调度时的申请量

  1. 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

  1. job conf使用eggroll_run配置:

  • task_run_cores(guest, host, arbiter):eggroll.session.processors.per.node * total_nodes

  1. job conf使用spark_run配置:

  • task_run_cores(guest, host, arbiter):executor-cores * num-executors

4.5.3 资源调度
  1. 作业申请资源的计算

  • 对于计算引擎为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

  1. 作业调度策略

  • 按提交时间先后入队

  • 目前仅支持FIFO策略,也即每次调度器仅会扫描第一个作业,若第一个作业申请资源成功则start且出队,若申请资源失败则等待下一轮调度

  1. 资源申请规则

  • 调度器依据上述调度策略选出作业,分发联邦多方资源申请指令到所有参与方

  • 若所有参与方均申请资源成功(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. 基本原理

  1. 提交作业后,fateflow获取job dsl与job config,存于数据库t_job表对应字段以及$PROJECT_BASE/fateflow/jobs/$jobid/目录

  1. 解析job dsl与job config,依据合并参数生成细粒度参数, 以及处理参数默认值

  1. 将共同配置分发到各参与方并存储,依据参与方的实际信息,生成job_runtime_on_party_conf,同样存于数据库与jobs目录

  1. 每个参与方接收到任务时,均依据job_runtime_on_party_conf执行

你可能感兴趣的:(联邦学习,深度学习,人工智能,python,算法)