IBM Platform Symphony 高效的大数据处理引擎（2）

look_w

Platform Symphony 的模块和基础知识在文章的开始我们就已经谈到了 Platform Symphony 的基础架构，这里我们就来看看 Platform Symphony 两层架构中都有哪些详细的模块。
EGO 简介用一句说，EGO（全称为 Enterprise Grid Orchestrator）就是一个管理集群资源的模块。首先它会将物理资源，进行虚拟抽象并管理，然后在多个应用之间进行协调和分配。这也是其设计的初衷。类似于开源的 Yarn，可是要知道 EGO 这个设计及实现都是十几年前就已经有了，而 Yarn 则是这几年才发展起来的（企业级的分布式系统，通常都会积累沉淀很久才会趋于稳定）。EGO 会将集群节点分为管理节点和计算节点，并定义一套资源分配的策略。我们也可以说 EGO 就是由这三部分组成，如下图所示。
图 5. EGO 的组成管理节点，一般会运行一些特殊化的服务，例如管理 Symphony 任务的服务（Session Manager 和 WEB 的服务进程，后面会介绍）。计算节点则是承载用户计算任务的节点。图中的 Master candidate 属于一个 Standby 的 Master 节点。对于 Symphony 的 Master 节点来说，这就是它的 HA。Master 和 Master Candidate 都属于管理节点，它们会共享一个目录（NFS）来记录运行时的一些媒体信息。当 Master 宕机或长时间不响应的时候，Master Candidate 会接管集群成为新的 Master，并从 NFS 的媒体信息中恢复正在执行的任务信息。CPU slot 是一个用来衡量计算资源的基本单位。一个 Slot 可以用来启动一个用户的 Service 实例（在计算节点），也可以用来启动一个 Session Manager 这样的管理服务实例（在管理节点）。其实管理节点和计算节点只是 EGO 内置的两种资源分组，我们也叫 Resource Group。用户也可以自定义其特有的 Resource Group 来隔离不同的应用。Resource Group 之间也可以有优先级，也可以定制化共享资源。这也是 EGO 提供给上层的功能。
这里也介绍下 EGO 中几个重要的服务进程，VEMKD、EGOSC、PEM。VEMKD 相当于 Yarn 中的 RM，它启动在 Master 节点上面，用于监测集群的资源的状态以及管理集群资源。上层的应用最终都会向 VEMKD 来申请资源（Slot）。EGOSC 全名就是 EGO service controller，它会向 VEMKD 申请资源启动一些系统管理的服务。PEM 全名是 Process Manager，用于启动进程实例，和监测进程实例的状态。
SOAM 的组成SOAM 是一个面向服务的中间件，其由 Session Director（SD）、Session Manager（SSM）、Service Instance Manager (SIM) 和 Service Instance（SI）组成。具体的关系如下图。
图 6. SOAM 的架构设计简单介绍下各个模块之间的关系，Client 就是用户根据 Symphony SDK 开发的客户端程序，用户从 Client 提交计算任务。Client 会先和 SD 建立连接，SD 会找到该类型应用的 SSM。如果该类型 SSM 不存在，SD 会向 EGO 层申请管理节点的资源，并启动 SSM（这里的 SD 和 SSM 都是管理节点的系统服务实例，不占用计算节点的资源）。SSM 会根据用户提交的任务向 EGO 层申请一定的计算资源。拿到计算资源后 SOAM 层会在计算节点启动 SIM 和 SI（一般一个 Slot 启动一个 SI 实例）。然后 SSM 会发送任务和数据到 SIM，进而到 SI 完成计算。SIM 会管理用户的 Service 进程，如果用户的 Service 遇到一些错误，SIM 会根据用户配置产生对应的行为，我们称之为 Error Handing。
Symphony 的应用以及其运行时涉及的概念在 Symphony 中运行的应用，主要包含三部分，分别是 Client、Service 程序以及该应用的定义文件 App Profile。其中 Client、Service 都需要用户根据 Symphony SDK 开发。运行时涉及的概念见下图。
图 7. Symphony App 运行时的相关概念从图中，可以看见 Client 会创建 Session（跟 Job 是一个意思），Session 会包含很多个 Task。Client 每提交一次作业都会创建一个 Session，并生成多个 Task。Session 的 ID 是全局唯一的，而 Task 的 ID 只是在该 Session 中唯一。每一个应用都会有一个 App Profile，它会定义跟该应用相关的属性，以及 Symphony 对该应用在某个场景的行为。对运行时的数据流向，我们可以参见下图。
图 8. Symphony 应用的数据流向Symphony 的 Package 管理无论是开源的 Hadoop 还是 Platform Symphony，用户都需要开发自己的程序。因此，会涉及到如何管理用户应用的部署包。对于 Hadoop 来说，需要上传 Package（Jar 包）到 HDFS。同样的 Symphony 需要用户将 Package 发送给 RS 服务。不过 Symphony 提供了很友好的命令行工具和 WEB 操作入口。用户上传完成后，Symphony 会在运行该用户应用时，自动下载 Package 到计算节点。如下图所示。
图 9. Symphony 的 Package 的管理