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

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

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

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


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

一、系统目标

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

大规模:分布式算法和负载均衡;

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

可服务:并发、热升级、安全、APIadmin等。

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

二、飞天基本架构

213514664.png

1 飞天架构层次图

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

三、分布式文件系统

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

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

214100587.png

2 盘古架构图

四、任务调度

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


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

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

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

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

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

213642392.png

3 ODPS多集群架构


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

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

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

1、基于HTTP协议,对防火墙友好;

2、保证E2E完整;

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

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


第四部分 ODPS Graph

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

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

主讲人总结下阶段工作,主要包括:

1、内存控制,并发稳定性;

2、数据倾斜(数据不均衡);

3、支持图拓扑变化。