本文档采取总分总的方式，先介绍JobManager的启动顺序，再从启动顺序中拆解每个组件最底层的实现。最后再总结一次JobManager的实现。本文主要介绍standalone模式下的JobManager实现。大部分组件的实现都类似，只是在高可用、executeGraph上会有实现的差异。可以把 JobManager 的启动理解为“先把地基服务准备好，再把三大组件创建并启动”。JobMaster。

BlobServer是 JobManager 的文件分发服务端：对外提供 PUT/GET，内部实现“本地缓存 +（可选）HA 持久化 + transient TTL + 作业级清理”。它在启动链路里属于地基服务：被创建并启动后，核心组件（Dispatcher/RM/Web）才开始启动；并且 HA 模式下它与BlobStore一起保障“永久 BLOB 可恢复”。

不是“无依赖地创建 3 个核心组件”，它依赖一整套在。Standalone Session 的入口类直接返回。只需要把地基对象作为参数传进去。的 Session 变体。的代码顺序固定是：先。

这里将数据门户单独拎出来是因为这个数据门户是从公司整体的角度，记录登记哪些数据可以使用，数仓也只是其中的一部分，虽然这个一部分非常的多。只是在大数据场景下，将事实表的维度剥离出来，做成维表，是收益比很低的一件事，所以很多维表字段不会剥离，相反，还会有很多维表字段进行下沉，多张表中维护同份数据。还有一些没法抽象的，比如业务过程中业务的状态，业务种类这些就没必要做成维度表，而是下沉到dwd层的明细表。

可以看到内部涉及了很多的类，而这3个是比较典型的类。用来管理内部。最后，在针对查看一下他的初始化方法，startSupervisorActor//获取对应的 actorSystem} else {} else {port = -1;//启动对应的 startSupervisorActor//SupervisorActor.startSupervisorActor 方法//这里没有用工厂方法，应该是