综述由于是异步提交的，job启动是由server 进行轮询，对于处于waiting的 job 按照FIFO进行调度。调度之后的操作有2部分：Part1. 申请资源Part2. start job：将job的状态从waiting -> running 状态涉及的主要方法： dag_scheduler.schedule_waiting_jobs()执行细节dag_scheduler.py：轮询，发现处于waiting状态的job（这一部分见fate flow server 启动部分）

综述在前文的基础上，因为job已经处于running状态，会按照task的依赖关系，依次调度该job下的task。调度之后的操作有2部分：Part1. 申请资源Part2. start job：将job的状态从waiting -> running 状态涉及的主要方法： dag_scheduler.schedule_running_jobs()执行步骤dag_scheduler.py：rundo轮询，发现处于running状态的job（这一部分见fate flow server

综述前文对upload task 进行schedule 之后，最终调用 task_executor 进行执行，进入具体的执行部分。每个task的具体日志会打在${job_log_dir}/ $ {role}/ ${party} 中（为便于记录，这里简记为 ${task_log_dir}这里就按照 ${task_log_dir}/DEBUG.log看 会比较清晰一点执行细节执行命令/opt/app-root/bin/python /data/projects/fate/python/fate

综述task结束时，是通过TaskExecutor.report_task_update_to_driver更新本地的DB中task的状态信息的。但由于是异步请求，对于发起者而言，并不会收到task 结束的信息，只有在轮询中，去查询db，获取task的状态。获取task已经finish的信息后，会返还资源和进行相关环境清理。执行细节dag_scheduler.py：schedule_running_job 调度轮询，和前文类似，这里不多赘述调用链为DagScheduler.schedule_r

综述同task，job结束时，并不会返回job finish 的信息，也是在DagScheduler.schedule_running_job() 轮询时，通过calculate_job_status() 方法获取job的状态。获取job已经finish的信息后，会返还资源和进行相关环境清理。执行步骤dag_scheduler.py：当调度完task后，执行calculate_job_status，计算job当前的状态。执行calculate_job_progress，计算job当前的完成进度。

综述在FATE学习：跟着日志读源码（二）fate_flow server 启动介绍过，fate_flow_server.py中的DAGScheduler(interval=2 * 1000).start()，默认每隔2s，启动一次dag_scheduler，共五种调度。其中：调度处于waiting 状态的job：job的状态从waiting -> running，主要在FATE学习：跟着日志读源码（五）upload任务job schedule阶段介绍。调度处于running 状态的job：涉

目录使用方式JOB_OPERATEsubmit_jobstop_jobquery_jobclean_jobdata_view_queryJOBjob_configjob_logTASK_OPERATEquery_taskTRACKINGcomponent_parameterscomponent_metric_allcomponent_metricscomponent_output_modelcomponent_output_datacomponent_output_data_tableDATAdownloa

综述为了让任务模型的构建更加灵活，目前 FATE 使用了一套自定的领域特定语言 (DSL) 来描述任务。在 DSL 中，各种模块（例如数据读写 data_io，特征工程 feature-engineering， 回归 regression，分类 classification）可以通向一个有向无环图 （DAG） 组织起来。通过各种方式，用户可以根据自身的需要，灵活地组合各种算法模块。除此之外，每个模块都有不同的参数需要配置，不同的 party 对于同一个模块的参数也可能有所区别。为了简化这种情况，对于

综述当前支持如下五种API来提交FATE任务，分别为：CLI API：通过python 启动python 脚本，提交FATE任务。REST API：Rest API 形式，发起http请求，提交FATE任务。Flow SDK：python 封装的SDK，调用相关API，提交FATE任务。Flow Client：封装为命令行工具模式的FATE Flow命令行控制台。Pipeline：python 封装的high level API。几种API的对比CLI API使用方式:python

综述在创建job 、task 和 执行task的过程中，将相关配置信息、pid信息等落盘。目录位于 /data/projects/fate/jobs/${jobid} 下主要包括3类：pid：用于记录执行各个task的进程号的文件。配置文件：针对输入的DSL 文件，和Run Time Conf文件，结合当前FATE部署时的配置参数，会生成任务运行时最终使用的配置文件。日志目录结构|-- job_dsl.json： 结合输入的DSL 文件 和 默认配置参数生成。|-- job_runti

综述fate_flow_server 启动时，会初始化db。cluster模式为mysql，standalone模式为sqlite，详细说明参考FATE学习：跟着日志读源码（二）fate_flow server 启动而在fate 任务的运行过程中，产生的job和task的metadata 以及 tracker 信息。这部分数据都存储在db中。因而也涉及大量的DB操作。创建 job or task： intsert 语句更新 job or task信息： update 语句、delete语句db概

综述upload，intersection，lr 等等组件，如果有中间结果，都以lmdb的形式存储。有关lmdb的，请参考官方文档存储位置为：nodemanager 的 /data/projects/fate/eggroll/data/LMDB按照output_data_{task_id} 存储各个task的结果 如:output_data_20210908144140944232712_dataio_0_0output_data_20210908144140944232712_hetero_

综述存储fate 训练过程中的模型目录: /data/projects/fate/model_local_cache/{model_version}/{model_id}内容(app-root) bash-4.2# ls -R.:define pipeline.pb variables./define:define_meta.yaml proto./define/proto:boosting-tree-model-meta.proto data-io-param.proto

综述upload 任务的http请求，可以分为两部分。一部分是submit -> job finish 这个流程中产生的。另一部分是polling 的过程中，轮询产生的请求（只轮询后收集相关信息，不实际执行）执行细节以下的日志，是一个upload执行后，容器中完整的日志。10.200.96.235 - - [26/Jul/2021 08:20:31] "POST /v1/party/202107260820309976351/local/0/create HTTP/1.1" 200 -1

综述将一个job中的各个component拆开来运行。只需要将上一步component 输出的name,namespace 作为下一步的输入，即可。至于component 输出的name,namespace，可以通过cli 中的component_output_data_table 或者直接查db 获取。在一些需要复用component 的情况下，比如一次求交结束后，使用不同的模型训练、预测等。可以有效的减少重复操作的耗时（io的和求交的耗时可是不小的）准备upload 数据生成up_guest

作为刚接触FATE的新人，尤其是工程向的，肯定很好奇FATE运行过程中，产生的日志都记录在哪里？运行过程中的模型和中间数据都保存在哪里？总的来看，FATE运行时产生数据包括如下几部分：db部分，记录和各项metircs，存在mysql(standalone 模式是sqlite)中。参见FATE学习：运行过程中产生的数据（二） db部分日志：落盘在本地，logs目录下。参见FATE学习：跟着日志读源码（一）日志目录结构jobs 运行时参数：基于输入中的配置项和默认配置项（缺省部分）生成的配置，存

综述参考FATE 的flowchart，常规任务开始的第一个组件，就是dataio。同前文，在${job_log_dir}/fate_flow_schedule.log 中输出如下命令后，开始通过task_executor 执行dataio。[INFO] [2021-06-04 14:42:02,995] [1:140456603948800] - job_utils.py[line:310]: start process command: /opt/app-root/bin/python /data

综述本篇以upload任务的sumbit 和 create 阶段为例，结合产生的日志，说明该生命阶段代码的运行情况。执行步骤为便于说明，画了下uml 时序图，结合图说下各步操作在CLI 用户执行命令 python fate_flow_client.py -f upload -c upload_guest.jsonfate_flow_client.py:调用 call_fun()函数，向本地server 发起post请求response = requests.post("/".join([s

综述从联邦建模的角度去理解整个job的生命周期，就是一系列功能模块组成的DAG，可以参照fate官方的文档，其中，各个功能模块就具体实现而言，就是fate中的各个算法或数据组件。不过结合源码，从日志的角度来看，可以将整个job的生命周期，按照不同阶段所做的操作，进行划分。具体如下图：submit：提交 jobcreate：创建job 和该job下对应的 tasks（相当于元数据） ，这里创建好之后，所有状态都是waitingjob schedule：对于job，按照FIFO的顺序，轮询到wa