阿里巴巴集团离线大数据处理平台介绍

阿里巴巴集团离线大数据处理平台介绍

上周报名参加了2013阿里巴巴暑期学校，课程为期两天，主要介绍阿里巴巴离线大数据处理平台（开放数据处理服务ODPS）。这里通过博客形式与大家分享一下。

暑期学校官网：http://102.alibaba.com/competition/dataSummer.htm

备注：该课程面向各高校院所的在读研究生，属于公开课程，且主要介绍系统的基本架构，并未对实现细节做过多阐述，因此并不涉及商业秘密。本人所写博客仅作技术交流之用，如有阿里巴巴工作人员认为本博客不妥，请及时告之，我将修改或删除。此外，从技术交流角度来讲，本博客内容包含个人理解，如有不妥，亦请指正。

第一部分 阿里巴巴大规模分布式系统――飞天

一、系统目标

飞天是阿里巴巴大规模分布式系统的昵称，本质是一个集群操作系统（或者说云操作系统）。该平台的数据总量约为10PB，CPU核数在万核以上，支持多租户、屏蔽故障等功能，同时提供在线和离线服务（类似Google），并以公共服务方式提供服务（类似Amazon）。该平台的核心问题主要包括大规模、可靠性、可服务等。

大规模：分布式算法和负载均衡；

可靠性：软硬件故障、断网停电、数据备份；

可服务：并发、热升级、安全、API、admin等。

飞天并不是阿里巴巴的全局平台，即阿里巴巴集团不是所有的业务都运行在飞天之上。考虑到公开课程的举办地点和宣传材料，飞天应当是阿里云的主要架构，不过上面运行着很多其他部门的应用，主要包括金融和广告业务。

二、飞天基本架构

图1 飞天架构层次图

图1为飞天的架构层次图。从下向上看，依次为数据中心、Linux集群、RPC等、分布式文件系统与任务调度、开放存储服务等、云服务引擎。在飞天云操作系统中，分布式文件系统和任务调度为核心组件，其昵称分别为“盘古”和“伏羲”，均由飞天团队自主研发。在分布式文件系统和任务调度之上，运行着多个业务平台，其中包括开放数据处理服务ODPS，ODPS就是本次系列课程的主角。

三、分布式文件系统

分布式文件系统的昵称是“盘古”，其基本框架和基本功能类似GFS、HDFS，图2为盘古的架构图。盘古为了维护高可用性，采用多Master架构，多Master间的关系采用一种“Paxos的简化实现方法”。听完详细介绍后，个人觉得其实是“一主双热备”，基本思路是使用三个Master，其中一个Master作为主Master，另外两个Master作为热备。当主Master故障后，就从两个热备中选取一个作为主Master，原来的主Master降级为Newbie，当Newbie恢复正常后，再升级为热备。

在另一个topic中，一位阿里员工提到“珍爱生命，远离Paxos”，他们在实践中并不使用真正的Paxos，主要原因是Paxos的错误处理非常复杂。

图2 盘古架构图

四、任务调度

任务调度的昵称是“伏羲”，伏羲支持多种编程模型，目前包括MapReduce、MPI、BSP等，但实现思路没有详细介绍。课下与一位阿里的员工师兄简单交流了一下，伏羲采用单调度器，并没有采用类似Mesos的二级调度机制。对于伏羲来说，并不特别关注任务属于哪个编程模型，统一进行调度。这样做的好处是调度器可以看到全局资源视图，集群利用率更高；但接入Hadoop MapReduce、BSP时都需要做了专门的兼容工作，兼容性一般。

第二部分 开放数据处理服务平台――ODPS

ODPS（Open Data Processing Service）主要提供海量数据分析的离线服务，采用RESTfulAPI，支持SQL、MR、BSP等。从服务对象来看，ODPS为阿里内部应用和某些外部应用服务，例如阿里金融和广告业务。

ODPS架构较为特殊，采用多集群架构，各个集群地理上位于不同地点，可能是不同机房，也可能在不同城市。采用多集群架构基于这样一种假设：平台总数据量很大，需要多个集群进行存储；单次计算所需数据量和资源适中，单一集群即可满足。

ODPS基于多集群架构提出一种理念，即“以在线服务的方式，提供离线计算服务”，其架构图如图3所示。ODPS支持少量在线计算和大量离线计算，其框架包括一个主控集群和多个计算集群，主控集群用于在线计算和总体调度，计算集群用于离线计算；在主控集群内，ODPS Worker用于处理简单的在线计算，Scheduler用于离线任务调度。主控集群以在线方式向外提供服务，如果查询是在线任务，就由ODPS worker计算后直接返回；如果是离线任务，就由Scheduler进行调度，将离线任务交给Executor，再由Executor交给计算集群。

在主控集群中，ODPS Worker和Executor是无状态的，Scheduler是有状态的，Scheduler是所谓的“单点”。针对由此产生的高可用问题，ODPS团队采用下列解决方法：将Scheduler部署在一个较为稳定的物理节点上，并将元数据写入Meta中，Meta托管给飞天上的另一种服务――开放存储服务（OSS）。但即使是这样，还会存在问题。主讲人提到有一次Scheduler和Meta同时故障，导致部分任务数小时不正常。

图3 ODPS多集群架构

第三部分 基于HTTP协议的大数据传输服务――ODPS Tunnel

第二部分介绍了ODPS如何处理数据，这部分介绍如何将数据导入到ODPS。ODPS每天新增数据量为200TB，数据7*24小时实时产生，来自广域网环境。

ODPS这部分组件叫做“Tunnel”，具有下述特点：

1、基于HTTP协议，对防火墙友好；

2、保证E2E完整；

3、支持可编程接口，且具有管理工具。

Tunnel传输结构化数据，并设计一种专用的文件格式――CFile。该文件按列压缩，编码兼容Protobuf。所谓“文件头”在文件尾部，用于记录文件大小和记录数。之所以在文件尾部，是由于文件数据实时产生，在新建文件时并不知道文件大小，只有在文件完成时才能明确文件大小。

第四部分 ODPS Graph

ODPS团队实现了一种图计算编程框架（没有专用名称），是一种基于BSP迭代的分布式图处理框架，在飞天之上构建，支持类似Pregel的接口（Java接口）。在计算过程中，数据在内存之中，通过网络进行通信。

ODPS Graph面向有向图，数据结构采用邻接表（Vertex/Edge），点的属性包括id、value、halted、edges等；边的属性包括destVertexId，value。该图计算框架采用Master-Slave架构，Master用于维护Worker的心跳和状态；Worker用于执行Master的工作，并执行Worker间通讯。错误恢复使用cheekpoint机制。可以看出，这部分图计算工作与Pregel类似。

主讲人总结下阶段工作，主要包括：

1、内存控制，并发稳定性；

2、数据倾斜（数据不均衡）；

3、支持图拓扑变化。

本文出自 “说话的白菜” 博客，谢绝转载！