云环境下大规模分布式计算数据感知的调度系统.docx

摘要：介绍了新的调度系统，包括资源调度、应用编排、配置标签中心、云网络和云存储服务等子系统系统通过数据拓扑感知能力保证了计算和数据的局部性，节约网络I/O开销；通过优化点对点大数据量读取的资源调度，解决网络风暴造成的影响；通过网络和磁盘隔离技术以及可抢占的方式来保证服务等级协议关键词：云计算;调度系统;大数据;AI平台;数据局部性;分布式计算;抢占1 引言随着云计算、大数据与人工智能（artificial intelligence，AI）技术的发展以及行业对这3种技术的综合应用需求，目前国内外出现了大数据、云计算、人工智能三者相互融合的技术发展趋势中国计算机学会大数据专家委员会在2019年大数据发展趋势调查报告中指出：人工智能、大数据、云计算将高度融合为一体化系统2006年Hadoop项目的诞生标志着大数据技术时代的开始，而亚马逊云计算服务（Amazon web services，AWS）商用则标志着云计算正式迈出了改变信息时代的步伐自此之后，大数据和云计算成为最近十几年十分火热的技术，学术界和工业界都大力投入相关技术研发和落地应用中，并且创造了几个学术界和工业界协作的经典之作如2012年加州大学伯克利分校推出的新型计算引擎Spark技术迅速被工业界接受，并成为新一代的标准计算引擎。

在云计算领域，更多的是企业级应用推动了技术的发展，如2014年开始兴起的容器技术和编排系统，最终推进了新一代原生云平台的快速发展，Docker和Kubernetes技术则成为新一代原生云的标准基础软件的研发不是简单的功能堆积，必须经过详细的架构设计和功能验证大数据和AI计算都是典型的分布式计算模型，是基于有向无环图（directed acyclic graph，DAG）或者大规模并行处理（massive parallel programming， MPP）迭代的计算模式，意味着计算任务都是运行时才能生成的，因而难以进行预先调度，而分布式的特点又要求调度系统有更高的灵活性和自适应性目前工业界在努力尝试将大数据平台和AI技术部署在原生云上，以做到更大的弹性和可扩展性但是，目前全球范围内在这个领域取得的突破性成就还比较少本文将介绍核心创新：云平台中的核心调度系统如何在原生云平台上管理和调度大数据和AI应用2 云原生云原生（cloud native）是指在应用开发时，以云作为其生产部署方式，从而充分利用云的弹性、可扩展、自愈等核心优势区别于传统的臃肿的单体应用开发模式，云原生应用因为其有效的协同开发、测试和运维，极大地提高了软件开发效率和质量，支持产品快速地上线和迭代，已经成为当前主流的应用开发模式。

通常称能够有效支撑云原生应用的平台为原生云平台，其主要特点是容器化的封装、自动化的管理以及面向微服务的体系Docker直接使用Linux Cgroup等技术提供逻辑上的虚拟化，因其系统开销小、启动快、隔离性较好、方便应用封装等特点，Docker已经成为首选的应用容器技术此外Docker技术支持跨平台部署，能够实现“一次编译，多次部署”基于虚拟机的技术对高负载的应用可能有30%的性能损耗，而Docker技术没有硬件虚拟化，跟裸机相比几乎没有性能损耗，因此也可以用于部署类似大数据和AI应用的计算或者I/O资源密集型的应用一个大的云平台可能需要高效稳定地运行数万个容器，这就需要非常强大的服务编排系统为了满足日益增多的服务和任务的资源需求，Borg、Mesos、Omega等一系列的集群资源调度系统相继出现其中，Borg是集中式调度器的代表，其作为集群调度器的鼻祖，在Google公司有超过10年的生产经验，其上运行了GFS、BigTable、Gmail、MapReduce等各种类型的任务Mesos是双层调度器的代表，可以让多个框架公平地共享集群资源Omega则是共享状态调度器的代表，它的特点是支持使用不同的调度器调度不同类型的任务，解决资源请求冲突的问题。

Kubernetes是Google开源用来管理Docker集群的项目，继承了Borg的优点，实现了编排、部署、运行以及管理容器应用的目的，Kubernetes的总体架构如图1所示Kubernetes提供资源池化管理，可以将整个集群内的中央处理器（center processing unit，CPU）、图形处理器（graphic processing unit，GPU）、内存、网络和硬盘等资源抽象为一个资源池，可以根据应用的资源需求、资源池中的实时资源情况进行灵活调度；Kubernetes包含一个统一的调度框架，最多可以管理数千个服务器和数万个容器，同时提供插件化的接口，让第三方来定制和扩展新的调度系统；此外Kubernetes支持通过ConfigMap等方式动态地调整应用配置，从而具备动态调配的基础能力本文基于这些基础技术开发了支持复杂应用平台的调度系统图1Kubernetes的总体架构3 大数据和AI计算模型分布式计算在复杂的工业应用需求下快速迭代和发展，从离线处理的MapReduce计算模型开始，逐渐发展出了以Spark为代表的计算（Spark、Tez、Druid等）以及实时计算模型（Flink、Spark Streaming等）。

新的分布式计算模型开拓了新的应用领域，同时也对大规模系统的管理、调度和运维提出了较大的挑战3.1 MapReduceMapReduce框架是Hadoop技术的核心，它的出现在计算模式历史上是一个重大事件，在此之前行业内主要通过MPP的方式增强系统的计算能力，一般是利用复杂而昂贵的硬件加速计算，如高性能计算机和数据库一体机等而MapReduce是通过分布式计算来提高计算速度的，并且只需要廉价的硬件就可以实现可扩展的、高并行的计算能力3.2 Spark随着大量的企业开始使用Hadoop构建企业应用，MapReduce性能慢的问题逐渐成为研究瓶颈，MapReduce只能用于离线数据处理，而不能用于对性能要求高的计算场景，如交互式分析、实时分析等在此背景下，Spark计算模型诞生了虽然本质上Spark仍然是一个MapReduce计算模式，但是几个核心的创新使得Spark的性能在迭代计算应用中比MapReduce快一个数量级以上：第一，数据尽量通过内存进行交互，相比基于磁盘的交换，能够避免I/O带来的性能问题；第二，采用延时评估（lazy evaluation）的计算模型和基于DAG的执行模式，可以生成更好的执行计划。

此外，通过有效的检查点（check pointing）机制可以实现良好的容错机制，避免内存失效带来的计算问题3.3 TensorFlowTensorFlow是Google公司开发的第二代人工智能学习系统，它可以将复杂的数据结构传输至人工智能神经网络中进行分析和处理，可用于语音识别、图像识别等多项机器学习和深度学习任务，并且完全开源，目前也是开源社区活跃的开发项目之一TensorFlow支持异构设备的分布式计算，可以在各个平台上自动运行模型，支持在、单个CPU/GPU、大型数据中心服务器等各种设备上运行4 原生云与大数据、AI融合的技术难点和解决思路4.1 基于容器云开发大数据或AI产品的技术难点原生云平台的一个主要特点是面向微服务设计，使用容器的方式编排普通的Web应用或者微服务但是大数据或者AI计算平台本身并没有采用微服务设计，各个系统都采用自身的分布式系统设计完成服务的管理和调度，并且执行时服务会一直变化以MapReduce为例，每个MR程序启动Map或者Reduce工作任务的数量是由应用本身来指定的（通过参数set mapreduce.reduce.tasks=N），调度器通过解析相关的参数来生成给定数量的工作任务，并在相关的任务完成后立即销毁。

大数据系统内的服务有自己的服务重启或者迁移逻辑，并且其配置或参数可能会随着应用或用户的输入而变化，而很多组件之间有很长的依赖链，如何及时地将某个参数的变化推送到所有的下游服务中，是调度系统的一个重要挑战对于没有数据存储的无状态服务，容器有多种编排方式进行编排和管理但是对于有数据状态的服务，如数据库（MySQL）或者分布式存储服务（Hadoop distributed file system，HDFS），由于容器内的数据会随着容器的销毁而销毁，因此采用传统的编排方式无法保证数据状态的一致性和数据持久化大数据和AI计算都涉及大量的数据和复杂的迭代运算，为了达到更好的性能，MapReduce、Spark和TensorFlow在架构中都特别注重“计算贴近数据”设计，一般会根据数据的位置选择启动相应的计算服务，尽量让计算任务和数据节点在同一个节点上，这样就可以避免网络带宽带来的性能损失而在容器模式下，不同的服务封装在不同的容器内，并且使用容器自身的网络；而容器网络一般采用重叠网络（overlay network）模式，因此容器内的应用并不能感知调度容器的机器的物理拓扑，因此也就无法确定从哪个节点调度计算任务所在的容器。

为此，重新设计了云网络服务，以有效解决相应的调度信息缺失问题另外，大数据或者AI应用都是资源密集型应用，在运行时会对CPU、GPU、内存、磁盘、网络等资源进行动态申请和释放如某个应用可能会根据用户的输入生成一个Spark的机器学习任务，在大数据平台上生成若干个执行任务（executor），并申请一定的CPU和内存资源及时地响应这些短生命周期服务的资源需求，是当前各种原生云的调度系统无法有效支持的功能4.2 融合大数据和AI的云调度系统的设计考量为了有效解决各种实际技术难题，重新设计云平台的调度系统成为必须考虑和完成的工作相较于原生的Kubernetes调度系统，云平台的调度系统需要从以下方面重新设计1）基于资源需求的调度能力整个云平台的资源从逻辑上被抽象为一个大的资源池，按照CPU、GPU、内存、存储和网络进行分类管理一个容器在被调度的时候，通过编排文件或者配置来描述相应的资源需求调度器需要根据资源池的实际资源情况和各个主机的物理资源情况，在毫秒级时延内找到合适的物理节点来调度当前容器在超大规模的云集群里，调度器的效率、性能和负载均衡是重要的技术指标，最终会影响云平台的资源使用率2）支持本地存储并基于存储感知的容器调度为了有效支持有状态的服务，如数据库服务（MySQL）、分布式存储服务，本文设计了基于本地存储的存储服务。

云储存将所有的存储资源抽象为一个存储池，每个节点的本地存储抽象为若干持久化存储池（persistence volume group），而单个可以被容器申请的存储资源定义为存储卷（persistence volume，PV）每个PV只能被一个容器挂载，可以是任意大小，支持硬盘驱动器（hard disk drive，HDD）或固态硬盘（solid state drive，SSD），也支持HDD与SSD组成的分层式存储有状态的容器服务在启动时会申请需要的PV资源（如大小、IOPS要求、SSD或HDD），调度器需要在毫秒内从平台内找到合适的机器，从而将容器调度起来；如果容器因为各种原因不能正常工作，调度器能够检测到不健康的状态，同时根据数据的物理拓扑情况，选择合适的机器重启相应的容器3）网络物理拓扑的感知与实时调度能力为了支持灵活弹性的调度，一般情况下云原生平台为容器设计专门的网络空间，并且一般与主机网络保持透明通常一个服务器节点上会有多个容器服务，因此主机IP的数量远小于容器IP的数量在MapReduce、Spark和TensorFlow的设计中，在启动计算任务时，会根据数据存储的物理拓扑决定最终服务启动在哪个服务器上。

但是在容器平台上，所有的任务都只能感知容器网络，而不能感知物理机器的IP，无法了解数。