OpenStack 大数据项目 Sahara 概述

2013 年 4 月，OpenStack 社区知名厂商 Mirantis 正式宣布了基于 OpenStack 的开源 BDaaS（BigData-as-a-Service）项目——Sahara（原名 Savanna），正式开始了在 OpenStack 上构建大数据服务能力的努力。

近日，开源技术专家章宇（ @一棹凌烟）在其博客上分享了对 Sahara 项目的研究心得。整个介绍系列分为 7 篇文章，除前言部分外，其余六篇分别是：

• Sahara 概述：介绍项目的目的、概况、发展等基本情况
• Sahara 使用方式：介绍具体如何使用 Sahara 进行大数据业务操作
• Sahara 设计实现：介绍 Sahara 的架构设计与实现
• Sahara 与 AWS EMR 和 Serengeti 的对比：将 Sahara 与目前最知名的公有云大数据服务和 Hadoop 虚拟化项目进行简单对比分析
• 对 Sahara 的若干思考
• 小结与展望

在《 Sahara 概述》中，章宇介绍了 Sahara 的定位、功能的演进、社区支持力度与整体发展的趋势。

Sahara 最初的基本定位是基于 OpenStack 提供简单的 Hadoop 集群创建方式，不过随着项目不断演进，Sahara 所涵盖的范畴也有所扩大。章宇从两个层面介绍了 Sahara 项目的发展方向：

从服务层次的维度看，Sahara 已经开始从利用 OpenStack 的 IaaS 能力，提供简单的大数据工具集群创建和管理服务，扩展到提供分析即服务（Analytic-as-a-Service）层面的大数据业务应用能力。Sahara v0.3 中引入的 EDP（Elastic Data Processing）就是一个明确的体现。

从承载的业务类型维度看，Sahara 也很有可能会迅速突破单一的 Hadoop 工具范畴，拓展支持其他新兴的大数据工具。例如，关于提供 Spark 支持的 BP 已经被提交至社区，目前正在等待 review。

Sahara 项目的发展较快，其项目 PTL Sergey Lukjanov 已经宣布 Sahara 将于 OpenStack Juno 版本中正式成为integrated 项目，目前代码已经提交，并在等待review，其版本演进可以参见其wiki 页面介绍。目前Sahara 已经被集成在RDO 中，因此可以被更为简单方便的安装部署。

《 Sahara 使用方式》简单介绍了 Sahara 的使用模式、基本概念与操作流程。

Sahara 有两种使用模式：

• 基本的大数据集群应用模式（基本模式）
• 通过 EDP 机制引入的分析即服务模式（EDP 模式）

简单来说，基本模式要求用户自己从底层搭建 Hadoop 虚拟机、建立集群，技术门槛较高；而 EDP 模式有点类似于 AWS EMR 服务，对底层的 Hadoop 集群操作和 Hadoop 业务操作进行了封装，暴露给用户的只有非常简单的接口，使用简便。

章宇介绍了 Sahara 当中的节点（node）、节点组 (node group)、节点组模板（node group template）、集群（cluster）、集群模板（cluster template）、任务（job）等关键概念，并简单列出了在基本模式下用 Sahara 建立 Hadoop 集群的操作流程。整个介绍比较概括，step by step 的操作文档可参考 Sahara 官方的 QuickStart 。

接下来，章宇开始从研究代码的层面介绍Sahara 的设计与实现。Sahara 的设计有两大特点：

1、模块化、可配置：

Sahara 中的大量功能和机制，都基于可选择、可配置的模块化插件实现，例如：可以通过对 engine 的配置来选择不同的 Hadoop 集群编配引擎，通过对 plugin 的配置来选择不同的 Hadoop 发行版安装与部署方式和工具，等等。

2、代码重用：

Sahara 也尽可能重用了 OpenStack 自身提供的 IaaS 层组件及其服务，例如：利用 Nova 提供虚拟机资源，利用 Horizon 提供人机界面，等等。

Sahara 对 Horizon（界面）、Glance（镜像管理）、Keystone（身份认证）、Heat（集群配置）、Ceilometer（监控）、Nova（虚拟机管理）、Neutron（网络）、Cinder（块存储）和 Swift（对象存储）都有不同程度的代码复用，其中 Nova、Glance 和 Keystone 是必要组件，其他组件可选用。

Sahara 的整体架构可参考其架构图。其中，章宇建议：

在分析集群创建流程时，主要应关注 sahara.api、sahara.service.api、sahara.service.engine 和 sahara.plugins 这四个 package 的各自行为及相互关系。其中，sahara.service.api 中的 _provision_cluster() 驱动了整个 cluster 创建的过程。

接下来，章宇从产品和技术的层面将 Sahara 与 EMR、Serengeti 进行了对比，要点如下：

• EMR 在 Sahara 基本模式的基础上融合了 EDP 模式的特点
• EDP 的用户只需要指定“哪些数据”、“哪个集群”、“哪个程序包”这三要素，而完全不用关心集群如何创建、如何管理这样的与自己核心业务诉求无关的问题
• EMR 的用户则除了需要在创建集群时指定大量信息外，还需要负责集群和业务的运行管理
• 比较而言，EDP 的用户是纯粹的大数据业务应用者，而 EMR 的用户则身兼业务应用和系统运维两种职责
• 基于 EMR 的大数据解决方案，全面涵盖了数据的存储、计算、分析、共享等各个处理环节，这是 Sahara 还难以企及的
• Sahara 和 Serengeti 的区别，可以说是“应用云化”和“应用虚拟化”的区别。Serengeti 项目的主要关注点在于如何为搭建在虚拟机环境下的 Hadoop 集群提高性能和可靠性，这里面的思考是 Sahara 可以借鉴的

介绍到这里，章宇对 Sahara 目前的状态进行了概述，认为目前的 Sahara 还面临以下几点挑战：

• Sahara 的管理平面性能存在疑问，创建和发布集群的等待时间有待测试
• 复杂管理的成功率方面，目前 Sahara 中没有看到明确的处理机制，这是一个缺失
• Sahara 搭建的 Hadoop 在虚拟化环境下的性能有待优化，不过这个问题可以等到前面两个关键问题解决了之后再来优化
• Auto-scaling 的缺失。目前 Sahara 要扩展需要人工执行
• Sahara 最大的亮点在 EDP，其价值有待进一步挖掘