一、 概述

  1. 定义

  MaxCompute（原ODPS，Open Data Processing Service）是阿里云提供的一款大数据产品。根据阿里云官网文档[1]定义，MaxCompute是适用于数据分析场景的企业级SaaS模式云数据仓库，提供了大数据计算和存储服务。MaxCompute提供海量数据的实时性要求不高的分布式处理能力。MaxCompute适用于计算和存储100GB以上规模的数据，最大可达EB级。其设计是为了处理海量数据，故不适用于实时性要求较高的场景。

  MaxCompute提供了以下功能：数据通道、开发作业与分析作业。数据通道实现数据在其他数据源与MaxCompute之间的数据传输。MaxCompute支持多种计算模型，如SQL、MapReduce、Spark等，并支持外部表、SDK、JDBC等以实现海量数据开发处理。MaxCompute提供了Logview与优化器，提供分析功能，帮助定位和优化作业。除此之外，MaxCompute还支持访问控制、安全管理、运维管理等功能。本文将重点介绍MaxCompute的一些核心概念和系统架构，以及其提供的多种数据通道和批处理计算模型。

  1. 核心概念

  下面是MaxCompute中的一些核心概念。首先是一些与服务有关的概念。Region（可用区）表示MaxCompute在不同地域提供服务，用户可以根据自身地域选择合适的可用区。Quota（配额）是MaxCompute的计算资源池，提供了计算所用的资源，例如CPU和内存。Networklink（网络连接）则提供网络连接服务。

阿里的odps 与hadoop odps阿里云_SQL

  Project（项目空间）是MaxCompute的基本组织单元，它的概念相当于传统数据库中的Schema或者Database。Table（表）是MaxCompute的数据存储单元，有着由行、列组成的二维逻辑结构。表包括内部表和外部表。内部表即MaxCompute中的表，存储了实际数据；外部表的数据则不被存储在MaxCompute中，MaxCompute仅存储这些外部表的访问链接。创建Table时，可以创建Partition（分区）空间，也就是指定Table中一个或多个字段作为分区列，并且可以指定多级分区。类似文件系统，每一个分区在表之下有独立的目录。当查询时，可以在指定分区内查询，从而提高处理效率。Views（视图）是建立在表之上的一个虚拟表，与传统数据库中的概念类似。Instance（实例）表示实际运行作业（Job）的一个具体实例，是一个动态概念，将在下文架构部分具体介绍。MaxCompute提供Function（函数）以封装计算功能，例如内建函数。当内建函数不能满足需求时，用户可开发UDF（User Defined Function，即用户自定义函数）。Resource（资源）是MaxCompute中的特有概念。例如将java类文件打包为jar文件上传MaxCompute后，就成为了其中的一个资源。UDF便需要依赖这些资源。资源类型包括File类型、Table类型、Jar类型、Archive类型、Python类型，大小限制为500MB。User（用户）、Role（角色）则是MaxCompute中与安全管理有关的概念，此处略。此外，MaxCompute中还有Lifecycle的概念，即生命周期。表数据若在一段指定时间内没有变动，将被MaxCompute回收，而这个指定时间就是生命周期。

二、 系统架构

  1. 总体架构

  下图展示了MaxCompute的系统结构，包括客户端、接入层、逻辑层、存储/计算层。其中核心部分是逻辑层，体现了MaxCompute的控制体系。

阿里的odps 与hadoop odps阿里云_阿里的odps 与hadoop_02

  1. 客户端与接入层

  客户端是用户访问MaxCompute的方式，包括Restful API、SDK、命令行、网页、IDE等。用户可以使用HTTP的GET、PUT、POST等标准语法，访问相关资源。ODPS SDK则封装了Restful API，以提供对MaxCompute的访问。用户也可以通过命令行输入命令、或者使用相关IDE（如RStudio）的方式访问MaxCompute。大部分用户通过Web页面方式访问MaxCompute，这种方式优点是操作方便。

阿里的odps 与hadoop odps阿里云_阿里的odps 与hadoop_03

  接入层实现将客户端命令接入到MaxCompute中。客户端请求命令时，会带有AccessID和SHA1签名信息。首先接入层会将请求命令通过一个LVS负载均衡，将命令分配到不同的HTTP Server上。HTTP Server将解析出的AccessID和SHA1信息传到云账号服务器进行相关验证。验证通过后，云账号服务器会返回一个AccountID给HTTP Server。为了考虑安全性，MaxCompute设计了一个AccountID与多个AccessID的对应。后续请求中，发送请求将使用AccountID而非AccessID。此后，HTTP Server将命令发送到MaxCompute中进行处理。

  1. 逻辑层

  逻辑层又称控制层，是MaxCompute的核心部分。逻辑层包括命令解析、项目空间管理、对象管理、元数据管理、授权管理等功能。命令解析即对执行层传输过来的命令进行解析，生成相关执行逻辑。项目空间管理即管理Project，包括创建、删除与修改等。对象管理包括对Table（表）、Resource（资源）和Task（作业）的管理。此外还包括对元数据的管理，以及对数据对象的访问控制和授权管理。

a) 任务、作业与实例

  MaxCompute存在Task（任务）、Job（作业）与Instance（实例）的概念。任务是MaxCompute的基本计算单元。比如一个SQL查询、一个MapReduce程序都是一个任务。任务之间的执行顺序称为工作流（Workflow）。Workflow应该是一个有向无环图（DAG），这是因为执行顺序代表了任务之间的依赖关系和约束，两个任务不能存在相互依赖。一个或者多个任务及其工作流就组成了Job（作业）。或者说，Job可以划分为多个Task以及这些Task的工作流。Instance（实例）则是与Job相关的动态概念。一个Job是一个静态概念，一旦Job被提交到MaxCompute系统中运行，系统就会为其生成一个实例，并且每次运行Job都会生成一个Instance。实例保存了作业执行时的快照（Snapshot）、返回状态等信息。

b) 工作组件

  MaxCompute的逻辑层包括Worker（请求处理器）、Scheduler（调度器）、Executor（作业执行管理器）三大组件。Worker相当于客服中心。每当一个请求被接入层运送过来，Worker就会进行处理。若该请求仅涉及到Restful请求，或者仅仅是对用户空间、表、资源、任务等的管理，则Worker可以进行本地处理。若该请求涉及到一些计算型的作业（例如SQL、MapReduce），则Worker会将作业提交给调度器。

阿里的odps 与hadoop odps阿里云_数据_04

  Scheduler相当于中央控制室。当作业被Worker提交过来，并产生Instance后，Scheduler便会负责Instance的调度。上图表示了Scheduler的调度流程。首先Scheduler会维护一个Instance列表存放Instance。Scheduler从列表中取出Instance，将其分解为Task并生成其工作流后，会将可运行的Task放入到TaskPool中。TaskPool是一个优先级队列，Scheduler会定时对该队列进行排序。此外，Scheduler还负责查询计算集群的资源情况。

阿里的odps 与hadoop odps阿里云_SQL_05

  最后是Executor（作业执行器）。Executor相当于一线工作人员。Executor负责执行TaskPool中的Task，其的工作流程如上图所示。首先Executor会判断自身资源是否充足，如果充足则会主动轮询PoolTask，申请并取出Task。之后，Executor生成Task的描述文件，并提交给计算层运行。在运行过程中，Executor会监控Task的运行状态，并把这些状态汇报给Scheduler。

c) 处理流程

  下面，以一个图总结下MaxCompute逻辑层的业务处理流程。

阿里的odps 与hadoop odps阿里云_App_06

  首先是Worker。Worker收到接入层传入的请求后，会首先进行相关检查，比如表是否存在、版本是否最新等。检查通过后，生成作业实例ID，并把实例发送到Scheduler。之后，存储Instance相关元数据，并把实例推送到Scheduler中的Instance列表。然后是Scheduler。Scheduler将Instance转换成任务以及其DAG形式的工作流，然后将Task推送到TaskPool中，并更新Instance的元数据。同时，Scheduler还会轮询飞天内核（Apsara Core），以查询集群计算资源。最后是Executor。Executor从TaskPool中取出一个Task，生成描述文件后，将该Task提交到计算层（即阿里云的飞天内核）运行。在运行过程中，Executor会轮询Task的运行状态，并将状态反馈到Scheduler以更新Task状态。最后，Executor会更新Task相关的元数据。可以注意到，整个过程中，逻辑层的三大组件Worker、Scheduler、Executor都会与元数据进行交互，这是通过SQL Planner组件实现的。

  1. 存储/计算层

  最后是MaxCompute系统架构中的最低层，存储/计算层。存储/计算层其实就是阿里云的飞天内核。飞天是阿里云自研的大型分布式计算系统，其内核包括分布式系统底层服务、分布式文件系统、任务调度、集群监控和部署等模块。其中，盘古（Pangu）系统提供分布式文件系统服务，其聚集了大量普通机器的存储资源以提供大规模可靠的存储服务。伏羲（Fuxi）系统提供资源管理和任务调度。存储/计算层依靠盘古和伏羲提供存储和管理调度服务，控制SQL和MapReduce等作业任务的运行。

a) 盘古

  盘古文件系统中存在master和chunkserver的概念，有点类似于HDFS中的namenode和datanode。master负责管理整个文件系统的元数据，管理chunkserver状态，以及数据恢复等。在HDFS中，用户不直接与namenode进行数据传输。与此类似，盘古master仅提供给客户端元数据相关操作，而数据存储以及数据传输都由chunkserver完成。chunkserver上存储的是数据块（chunk），即文件被切成的固定大小的块。创建数据块时，盘古master会分配128bit的ID，客户端根据次ID读取数据块。目前，盘古系统中包括三台master和多台chunkserver。三台master是热备份的，也就是说，同一时间内仅有一台master对外提供服务。一旦发生故障，备份master将替代当前工作master。与HDFS中的数据复制策略类似，为了保证数据可靠性，一个数据块会被存储到多个chunkserver上，一般副本数量为3。

  MaxCompute底层数据存储在Pangu上，以表（Table）形式存储，进行压缩并保存为AliORC格式。

  AliORC即Alibaba ORC，是基于开源项目Apache ORC的优化。根据Apache ORC官网介绍[2]，Apache ORC是Hadoop生态中最快、最小的列式存储格式，支持ACID事务、内置索引以及各种复杂类型。Apache ORC被Spark、Hive、Hadoop等采用作为存储格式。ORC采用的是列式存储，即把表中的数据以先列后行的顺序存储。由于相同列数据属性相似、冗余度高，列式存储能增大数据压缩率以节省磁盘空间。ORC主要有两点优化。其一是查询速度方面，ORC将文件切成大小相近的块，块内应用列式存储，并在每一块中提供轻量索引。其二是ORC存储文件前，先使用通用的压缩算法（如zStandard、、snappy、LZO、zlib）压缩。AliORC则对ORC进行了深度优化，包括提供了更多扩展特性（如支持C++ Arrow、支持谓词下推），以及实现了I/O模式管理、自适应字典编码、异步预读等。

  此外，MaxCompute的元数据（MetaStore）存储在阿里云自研的Tablestore（TS，原OTS）中，而TS支持单表10PB数据、万亿条记录。

b) 伏羲

  伏羲提供资源管理和任务调度。在伏羲上存在两种计算，在线服务和离线处理，分别对应Fuxi Service和Fuxi Job概念（注意伏羲系统中的Job概念与MaxCompute逻辑层中Job概念的差异）。Fuxi Service由用户创建和销毁，伏羲不会主动销毁。而Fuxi Job是伏羲上的临时任务，任务结束并释放资源后就会被销毁回收。

阿里的odps 与hadoop odps阿里云_阿里的odps 与hadoop_07

  上图表示了伏羲的系统架构，包括中央资源服务器（Fuxi Master）、分布式结点管理器（Fuxi Agent，也叫Tubo）、应用程序主机（App Master）和App Worker等组件。Fuxi Master和Fuxi Agent负责资源管理；App Master和App worker负责任务调度。Fuxi Master负责管理各集群结点并收集资源，处理App Master的资源申请并进行分配。Fuxi Agent负责收集本地信息和状态，报告给Fuxi Master；同时，还提供流程监控、环境保护、流程隔离等功能。App Master负责特定程序执行逻辑，并调度App Worker执行。

  典型的协作过程如上图所示。首先，Client向Fuxi Master提交应用程序请求，并提供描述文件。Fuxi Master找到满足资源条件的Fuxi Agent，并为这个应用程序启动对应的App Master。App Master检索描述文件，确定资源需求等，并向Fuxi Master请求分配资源。Fuxi Master分配资源并通知相应Fuxi Agent启动App Worker。App Master调度App Worker执行。

三、数据通道

  用户使用MaxCompute的第一步就是需要将数据从其他数据源导入到MaxCompute上。MaxCompute提供了多种数据通道工具，以提供其他数据源与MaxCompute之间的数据传输功能。这些工具包括Tunnel批量数据通道、Streaming Tunnel流式数据写入通道、大规模数据迁移工具MMA（MaxCompute Migration Assist）、DataHub实时数据通道等。

阿里的odps 与hadoop odps阿里云_阿里的odps 与hadoop_08

  Tunnel定位为MaxCompute的一个API层组件，提供数据通道服务。上图表示了Tunnel集群在整个架构中的位置。系统通过SDK向上层应用提供了相关接口，例如DataWorks、DataHub等。系统的服务端分为API层和执行层。API层中的Frontend集群会负责处理控制流，将控制流运送给控制集群；而Tunnel集群则负责数据流的处理，将数据流送入计算集群。执行层，控制集群负责资源管控、元数据管理、权限管理等；而计算集群负责实际的计算和存储。

  Tunnel提供了MaxCompute对外数据读写的唯一接口，提供了完善的权限检验及格式检查。由于Tunnel直接与底层的盘古文件系统打交道，因此其读写性能较高。DataHub提供了实时数据通道。从上述架构可以看出，DataHub传入的实时数据流会通过SDK送入到Tunnel集群中，并由Tunnel送入MaxCompute。Tunnel适合于批量数据处理，并提供Streaming Tunnel作为流式数据写入通道。此外，Tunnel还提供了一个MMA工具以支持大规模数据迁移。下图以Hive数据迁移到MaxCompute为例介绍MMA的技术架构及原理。

  首先在Hadoop集群中，Meta Carrier会连接Hive metastore服务，抓取Hive元数据。此后，Meta Processor会根据抓取到的元数据，生成用于在MaxCompute中创建表和分区的ODPS DDL语句，以及用于数据迁移的Hive UDTF SQL语句。ODPS Console根据ODPS DDL语句，在MaxCompute中创建表与分区。最后，Data Carrier在Hadoop集群上，运行Hive UDTF SQL语句，批量传输数据。

阿里的odps 与hadoop odps阿里云_SQL_09

四、 计算模型

  一旦数据被传输到MaxCompute上，用户就可以使用MaxCompute上的计算服务对数据进行计算。MaxCompute支持多种计算服务，这些计算服务包括SQL、MapReduce、Spark、Mars、Graph、SQLML、PyODPS等等。其中，SQL、MapReduce、Spark是属于批处理计算模型。本节介绍MaxCompute支持的计算模型SQL、MapReduce和Spark。

  1. MapReduce

  MapReduce是Hadoop生态中的经典批处理计算模型。下面以WordCount程序为例介绍MapReduce的工作过程。

  MapReduce包括输入数据、Map阶段、Shuffle阶段、Reduce阶段、输入数据几个流程。输入数据会对数据进行分片，保证每片数据大小相同。Map阶段会把数据映射到一个键值对（key-value）。Shuffle阶段可分为合并排序阶段和分配阶段。合并排序阶段会把key相同的键值对进行合并，并根据key值进行排序。分配阶段会把key不同的键值对分配给不同的Reducer。合并操作由Combiner定义，值得注意的是，与经典MapReduce不同，在MaxCompute中Combiner的输入输出参数需要与Reduce保持一致。Reduce阶段会将键值对进行相关操作（例如进行一些统计计算），最后将数据输出。

阿里的odps 与hadoop odps阿里云_SQL_10

  在上图的WordCount实例中，map阶段将单词作为key，其value都为1，表示该单词出现一次。Shuffle中的合并排序阶段，每个map程序将单词出现次数进行合并并根据单词顺序进行升序排序。例如map2统计到单词2出现了两次、map3统计到1单词出现了三次。Shuffle的分配阶段，根据单词不同，将单词1分给reduce1、单词2和3分给reduce2。好的分配方式应保证每个reduce的处理数量相近。最后，Reduce阶段统计每个单词出现的次数。最后，reduce得到单词1出现了5次、单词2和3分别出现了3次和1次。

  除了经典的MapReduce，MaxCompute还提供了扩展MapReduce模型（MR2）。经典MapReduce的问题是，每次执行完一次Map-Reduce流程后，需要将结果数据保存到文件系统HDFS中，而下一次执行作业时又要从中取出。这产生了冗余的磁盘操作。MR2支持更复杂的编程，在Reduce之后可直接执行下一次Reduce而无需插入Map，即Map>Reduce>Reduce。

  1. SQL

  MaxCompute提供了MaxCompute SQL计算模型，其语法是ANSI SQL92的子集，并加以扩展。类似于Hive SQL转换为MapReduce在Hadoop上执行，从原理来说，MaxCompute上的SQL最终也都会转换成MapReduce执行。SQL主要包括From、Join、Where、Group by、Select、Sum、Distinct、Count、Order by等操作。本节介绍以上操作如何转换为MapReduce过程。

  From操作即找出输入的表或文件，这在表达式解析的过程中完成。Join操作会涉及map阶段和reduce整个阶段，两个表的编号作为map中value的key值，并在reduce阶段拼接两表的数据。Where操作如涉及到分区字段，会在SQL解析时进行裁减；若不涉及分区字段，会准确设置过滤条件，并在map阶段过滤。Group by操作的字段会作为map阶段的关键字，利用MapReduce进行排序，在reduce端组合输出。Select操作在编译解析时直接裁剪列，这是因为MaxCompute采用的是列存储。Sum涉及聚合函数，并行的聚合函数可以在map阶段进行提前聚合，减少reduce阶段网络传输。Distinct操作包括单Distinct和Multi Distinct。单Distinct的列直接依附在Group by字段后面进行处理；Multi Distinct 吧Distinct的字段都分开形成独立的n张表，然后做Union all操作。Count操作则是MapReduce的经典应用场景。Order by操作只存在一个Reducer，以保证全局有序。

  1. Spark

  MaxCompute支持Spark计算模型。由于Spark的运行基于Yarn调度，MaxCompute设计了Cupid平台，以原生支持Yarn所支持的计算框架。下图比较了运行在YDFS和yarn平台上和Cupid平台上的Spark。

阿里的odps 与hadoop odps阿里云_阿里的odps 与hadoop_11

  为了说明Cupid如何兼容Yarn，首先说明Yarn的接口。Yarn面向应用主要由三个接口，即用于客户提交作业的YarnClient，用于App Master向Resource Manager申请和释放资源的AMRMClient，以及用于启动和停止Container的NMClient。

  下图表示了Yarn on MaxCompute，其中蓝色表示开源组件，黄色表示Cupid平台的组件。用户提交作业时，通过YarnClient提交到控制集群。控制集群中的Cupid Task将作业提交到计算集群中的Fuxi Master。Fuxi Master启动Cupid Master，Cupid Master根据Yarn协议启动Yarn中的App Master。可以看到，Cupid Master替代了Resource Manager与App Master交互进行资源申请和释放。启动Container前，Fuxi Agent会先启动Cupid Worker，Cupid Worker再根据Yarn协议启动Container。类似地，Cupid Worker替代了Node Manager管理Container。此外，Cupid还通过ProxyServer提供了网页访问服务，以及启启动Yarn中的History Server以查看作业历史信息等。

阿里的odps 与hadoop odps阿里云_数据_12

  通过兼容了Yarn的Cupid平台，MaxCompute打通了Spark生态。在这个生态中的技术，如Mllib、PySpark、Streaming、SparkR、Graphx等都可以运行在MaxCompute上。

五、 总结

  本文介绍了阿里云自研的MaxCompute大数据计算服务平台，包括一些核心概念和系统架构，以及其提供的数据通道以及支持的计算模型。MaxCompute可以说是传统大数据系统中Hadoop生态的有效替代，其减少了运维和管理成本，使得大数据处理更为便捷。

参考：

[1] 阿里云MaxCompute官方文档.

https://www.alibabacloud.com/help/zh/maxcompute/latest/what-is-maxcompute

[2] Apache ORC官网.https://orc.apache.org/