OpenStack 怎样建构Hadoop与Spark系统

　　Piston公司的全新CloudOS计划在OpenStack环境之下对裸机服务器以及虚拟机系统加以管理，但其最终目标是将容器技术也同样纳入打理范畴。　　面对目前三大主流选项——通过OpenStack管理裸机与虚拟机系统，抑或是采用容器技术——大家会做何决断Piston公司就此给出了自己的意见：为什么不尝试三足鼎立　　以其OpenStack解决方案而闻名的Piston公司目前正着手推出CloudOS产品的最新版本，旨在允许企业客户将由OpenStack负责管理的虚拟机系统以及由CloudOS负责管理的裸机(主要面向Hadoop等应用程序)加以部署，并最终将容器技术纳入进入——三者全部在同一套框架之内实现运作。　　CloudOS 40的主要新特性在于有能力在裸机而不仅仅是OpenStack虚拟机系统之内对Hadoop以及Spark进行管理。Hadoop能够运行在虚拟化基础设施之上; 举例来说，VMware已经作出声明，表示其有能力切实达成这一目标。　　不过Piston公司CEO Jim Morrisroe相信，强制要求企业客户在OpenStack虚拟机、裸机或者容器当中单独选择其一或者全部采用属于严重的错误思维——当然，前提是相关工作负载有能力适应其中任意一种方案。　　“Cassandra、HDFS、Hadoop以及Spark——这些方案在虚拟机系统当中并不能发挥最出色的实际表现，”他在一次电话采访当中指出。“以一键式部署方式将其运行在由CloudOS管理的裸机基础之上能够带来显著的收益提升。”同样，他表示一部分分析型应用程序在虚拟机系统中的运行效果优于裸机平台。　　CloudOS会将Iocaine Linux(一套基础性Linux版本)部署在由其管理的各台设备之上，并在此基础之上运行多层式管理、网络、计算以及存储体系。在最高层级之上则是对各类常见应用程序进行配置以完成部署及运行：Hadoop及其相关技术、OpenStack外加即将得到支持的容器技术都在支持清单当中。　　目前，用户能够自行选择编排技术：Kubernetes、Docker、Mesos或者Swarm皆可。Morrisroe强调称，客户的选择应当根据现有选项考量得出：“我认为我们还不清楚这类工作最终最适合采用哪种编排方式，”他解释称，他所指的不仅是容器技术、也包括面向Hadoop等产品的编排机制。　　“我们希望客户有能力找到最适合自己的方案，”Morrisroe表示。“如果客户需要作出改变，他们也不该被迫在基础设施当中构建起新的孤立体系，同时应保证其能够以非破坏性方式进行并充分利用现有设备储备。”　　从理论角度讲，提供一套容器技术选项能够与Docker之间产生很好的互补作用。这一点对于Docker向其所谓“包含基础但仍然可选”模式进行转变的过程而言显得尤为重要，其中面向编排及网络等功能的模块被包含在产品当中、但仍然允许客户以自由方式在不同机制之间任意切换。CloudOS在这方面扮演补充性角色可谓意义重大，但其仍然算不上革命性飞跃。　　与其它准备以规模化方式运行容器机制的企业——例如IBM——不同，Piston公司的主张是将与安全性巩固与容器化技术相关的问题留给直接负责的部门。“我们希望利用现有容器编排项目中的创新成果，”Morrisroe表示。　　“容器化与安全性巩固等事务，我们希望留给相关社区及从业企业负责。我认为这能帮助我们的客户降低风险，因为随着技术的不断演进，不可能存在那种百试百灵的万能药。如果存在更理想的容器编排方式，我们希望能够迅速将其纳入自身解决方案，并集成到整体工具箱当中。”　　[附录：当被问及能够支持哪些容器技术类型时，Morrisroe回应称，“我们的终极目标在于允许客户根据实际需要任意选择理想的容器技术。这意味着我们未来需要能够支持Docker、Rocket以及各类通用型LXC容器。随着以容器为核心的各类新技术的不断涌现，我们将努力与开发出这些新技术的研发方通力合作，从而及时对其提供支持。”]

一提到大数据处理，相信很多人第一时间想到的是 Hadoop MapReduce。没错，Hadoop MapReduce 为大数据处理技术奠定了基础。近年来，随着 Spark 的发展，越来越多的声音提到了 Spark。而Spark相比Hadoop MapReduce有哪些优势

Spark与Hadoop MapReduce在业界有两种说法 ：一是 Spark 将代替 Hadoop MapReduce，成为未来大数据处理发展的方向 ;二是 Spark 将会和 Hadoop 结合，形成更大的生态圈。其实 Spark 和 Hadoop MapReduce 的重点应用场合有所不同。相对于 Hadoop MapReduce 来说，Spark 有点“青出于蓝”的感觉，Spark 是在Hadoop MapReduce 模型上发展起来的，在它的身上我们能明显看到 MapReduce的影子，所有的 Spark 并非从头创新，而是站在了巨人“MapReduce”的肩膀上。千秋功罪，留于日后评说，我们暂且搁下争议，来看看相比 Hadoop MapReduce，Spark 都有哪些优势。

1、计算速度快

大数据处理首先追求的是速度。Spark 到底有多快用官方的话说，“Spark 允许 Hadoop 集群中的应用程序在内存中以 100 倍的速度运行，即使在磁盘上运行也能快 10 倍”。可能有的读者看到这里会大为感叹，的确如此，在有迭代计算的领域，Spark 的计算速度远远超过 MapReduce，并且迭代次数越多，Spark 的优势越明显。这是因为 Spark 很好地利用了目前服务器内存越来越大这一优点，通过减少磁盘 I/O 来达到性能提升。它们将中间处理数据全部放到了内存中，仅在必要时才批量存入硬盘中。或许读者会问 ：如果应用程序特别大，内存能放下多少 GB 答曰 ：什么 GB 目前 IBM 服务器内存已经扩展至几 TB 了。

2、应用灵活，上手容易

知道 AMPLab 的 Lester 为什么放弃 MapReduce 吗因为他需要把很多精力放到Map和Reduce的编程模型上，极为不便。 Spark在简单的Map及Reduce操作之外，还支持 SQL 查询、流式查询及复杂查询，比如开箱即用的机器学习算法。同时，用户可以在同一个工作流中无缝地搭配这些能力，应用十分灵活。

Spark 核心部分的代码为 63 个 Scala 文件，非常的轻量级。并且允许 Java、Scala、Python 开发者在自己熟悉的语言环境下进行工作，通过建立在Java、Scala、Python、SQL(应对交互式查询)的标准 API 以方便各行各业使用，同时还包括大量开箱即用的机器学习库。它自带 80 多个高等级操作符，允许在 Shell中进行交互式查询。即使是新手，也能轻松上手应用。

3、兼容竞争对手

Spark 可以独立运行，除了可以运行在当下的 YARN 集群管理外，还可以读取已有的任何 Hadoop 数据。它可以运行在任何 Hadoop 数据源上，比如 HBase、HDFS 等。有了这个特性，让那些想从 Hadoop 应用迁移到 Spark 上的用户方便了很多。Spark 有兼容竞争对手的胸襟，何愁大事不成

4、实时处理性能非凡

MapReduce 更 加 适 合 处 理 离 线 数 据( 当 然， 在 YARN 之 后，Hadoop也可以借助其他工具进行流式计算)。Spark 很好地支持实时的流计算，依赖Spark Streaming 对数据进行实时处理。Spark Streaming 具备功能强大的 API，允许用户快速开发流应用程序。而且不像其他的流解决方案，比如Storm，Spark Streaming 无须额外的代码和配置，就可以做大量的恢复和交付工作。

5、社区贡献力量巨大

从 Spark 的版本演化来看，足以说明这个平台旺盛的生命力及社区的活跃度。尤其自 2013 年以来，Spark 一度进入高速发展期，代码库提交与社区活跃度都有显著增长。以活跃度论，Spark 在所有的 Apache 基金会开源项目中位列前三，相较于其他大数据平台或框架而言，Spark 的代码库最为活跃。

Spark 非常重视社区活动，组织也极为规范，会定期或不定期地举行与 Spark相关的会议。会议分为两种 ：一种是 Spark Summit，影响力极大，可谓全球 Spark顶尖技术人员的峰会，目前已于 2013—2015 年在 San Francisco 连续召开了三届Summit 大会 ;另一种是 Spark 社区不定期地在全球各地召开的小型 Meetup 活动。Spark Meetup 也会在我国的一些大城市定期召开，比如北京、深圳、西安等地，读者可以关注当地的微信公众号进行参与。

Spark 的适用场景

从大数据处理需求来看，大数据的业务大概可以分为以下三类 ：

(1)复杂的批量数据处理，通常的时间跨度在数十分钟到数小时之间。

(2)基于历史数据的交互式查询，通常的时间跨度在数十秒到数分钟之间。

(3)基于实时数据流的数据处理，通常的时间跨度在数百毫秒到数秒之间。

目前已有很多相对成熟的开源和商业软件来处理以上三种情景 ：第一种业务，可以利用 MapReduce 来进行批量数据处理 ;第二种业务，可以用 Impala 来进行交互式查询 ;对于第三种流式数据处理，可以想到专业的流数据处理工具Storm。但是这里有一个很重要的问题 ：对于大多数互联网公司来说，一般会同时遇到以上三种情景，如果采用不同的处理技术来面对这三种情景，那么这三种情景的输入/ 输出数据无法无缝共享，它们之间可能需要进行格式转换，并且每个开源软件都需要一支开发和维护团队，从而提高了成本。另外一个不便之处就是，在同一个集群中对各个系统协调资源分配比较困难。

那么，有没有一种软件可以同时处理以上三种情景呢 Spark 就可以，或者说有这样的潜力。Spark 同时支持复杂的批处理、互操作和流计算，而且兼容支持HDFS 和 Amazon S3 等分布式文件系统，可以部署在 YARN 和 Mesos 等流行的集群资源管理器上。

从 Spark 的设计理念(基于内存的迭代计算框架)出发，其最适合有迭代运算的或者需要多次操作特定数据集的应用场合。并且迭代次数越多，读取的数据量越大，Spark 的应用效果就越明显。因此，对于机器学习之类的“迭代式”应用，Spark 可谓拿手好戏，要比 Hadoop MapReduce 快数十倍。另外，Spark Streaming因为内存存储中间数据的特性，处理速度非常快，也可以应用于需要实时处理大数据的场合。

当然，Spark 也有不适用的场合。对于那种异步细粒度更新状态的应用，例如 Web 服务的存储或增量的 Web 爬虫和索引，也就是对于那种增量修改的应用模型不适合。Spark 也不适合做超级大的数据量的处理，这里所说的“超级大”是相对于这个集群的内存容量而言的，因为 Spark 要将数据存储在内存中。一般来说，10TB 以上(单次分析)的数据就可以算是“超级大”的数据了。

一般来说，对于中小企业的数据中心而言，在单次计算的数据量不大的情况下，Spark 都是很好的选择。另外，Spark 也不适合应用于混合的云计算平台，因为混合的云计算平台的网络传输是很大的问题，即便有专属的宽带在云端 Cluster和本地 Cluster 之间传输数据，相比内存读取速度来说，依然不抵。

通过前面的介绍我们知道，Spark的客户端（Driver）有两种：Spark Submit和Spark Shell。这两种客户端相同点都是维护一个Spark Context对象，来向Spark集群提交任务；不同点是Spark Submit只能提交任务，不能交互，而Spark Shell是一个命令行工具，即可以提交任务，还可以人机交互。本节先来介绍Spark Submit客户端的使用。

例子：使用蒙特卡罗方法计算圆周率。

如图所示，蒙特卡罗方法求圆周率，使用的是概率的思想：往正方形区域随机撒点，总点数记为P2，落在单位圆区域内的点数记为P1，单位圆的面积为π，正方形的面子为4，π = P1 / P2 4。这里的P1和P2均由随机实验中得到，实验的次数（P2）越多，得到的结果就越精确。

Spark提供的测试用例$SPARK_HOME/examples/jars/spark-examples_211-210jar中就有蒙特卡罗求圆周率的例子SparkPI，我们就使用它来介绍Spark Submit的使用。

(1)如果配置了基于Zookeeper的Spark HA，需要先启动Zookeeper服务器

(2)启动Spark集群

使用Spark Submit的命令格式如下：

(1)提交SparkPI任务，随机实验次数为100：

(2)提交SparkPI任务，随机实验次数为1000：

(3)提交SparkPI任务，随机实验次数为10000：

可以看到上面三次实验的结果分别是：

一般对于随机实验来说，试验次数越多结果越精确。但是不免存在误差。如果想要获取更精确的圆周率，你可以输入更多的次数进行测试。但这不是本文介绍的重点。

至此，使用Spark Submit客户端提交Spark任务的方法已经介绍完毕，祝你玩的愉快！