并发编程网 - ifeve.com

颠覆大数据分析之结论

译者：吴京润    购书

随着Hadoop2.0到来——被称作YARN的Hadoop新版本——超越Map-Reduce的思想已经稳固下来。就像本章要解释的，Hadoop YARN将资源调度从MR范式分离出来。需要注意的是在Hadoop1.0，Hadoop第一代，调度功能是与Map-Reduce范式绑定在一起的——这意味着在HDFS上惟一的处理方式就是Map-Reduce或它的业务流程。这一点已在YARN得到解决，它使得HDFS数据可以使用非Map-Reduce范式处理。其含义是，从事实上确认了Map-Reduce不是惟一的大数据分析范式，这也是本书的中心思想。 Hadoop YARN允许企业将数据存储在HDFS，并使用专业框架以多种方式处理数据。比如，Spark可以借助HDFS上的数据迭代运行机器学习算法。（Spark已重构为工作在YARN之上，感谢Yahoo的创新精神），还有GraphLab/Giraph可以借助这些数据用来运行基于图的算法。显而易见的事实是，主要的Hadoop发行版已宣布支持Spark（Cloudera的），Storm（Hortonworks的），还有Giraph（Hortonworkds的）。所有的一切，本书一直主张的超越Hadoop Map-Reduce的思想已通过Hadoop YARN得到了验证。本章概述了Hadoop YARN以及不同的框架（Spark/GraphLab/Storm）如何工作在它上面工作。

Hadoop YARN概览

Hadoop YARN的基本架构是从Map-Reduce框架中分离了资源调度，而这二者在Hadoop1.0中是捆绑在一起的。我们首先概述一下Hadoop YARN的动机，然后再讨论一些YARN的有趣方面。

Hadoop YARN的有趣方面

Hadoop的普及导致它被应用于各种情况，即使最初它并不是为之设计的。一个例子就是开发者只使用映射作业随意产生工作进程，而没有化简阶段，MapReduce范式没有被恰当的使用。这些随意的进程可以是web服务或迭代工作负载的成组调度计算，与消息传递接口（MPI）的成组调度作业类似（Bouteiller等2004）。这种情况引发了一系列讨论Hadoop MapReduce局限性的论文。比如，MapScale或SciCloud谈到Hadoop不适合做迭代计算。Hadoop1.0的限制主要在于以下方面：

• 扩展性：没有简单的内建方法，为两个不同的Hadoop集群交互/共享资源或作业。这个问题为一些部署带来了困难，例如在Yahoo，运行着几千个节点的Hadoop。大型Hadoop集群有其局限性，比如调度方案在扩展性上的局限和单点故障问题。
• 地方性意识：就近计算很重要，换句话说最好在拥有数据副本的节点上启动映射/化简。比方说，Yahoo为多租户集群使用的平台，在JobTracker调用时，只会返回相关数据的一个小子集。大多数读取是远程的，造成了性能损失。
• 集群效用：通过Pig/Hive构建的工作流可能会在集群中执行时导致无环有向图（DAG）。缺乏动态调整集群规模的能力（当DAG出现时调整），也导致利用率不佳。
• Map-Reduce编程模型的局限性：这是Hadoop跨企业应用的主要障碍。Map-Reduce模型不适合做迭代式机器学习运算，而这类计算可能要求解决前文所述的三座大山(广义N体问题)和五项优化。即使大型图处理问题与MapReduce也不是天作之合。不同类型的处理过程对数据的要求是显而易见的；这就是Hadoop YARN的主要推动因素。

作为资源调度器的YARN

YARN对范式的根本转变是将资源管理从面向具体应用的处理与执行中分离出来。这两个功能的重要组件是资源管理（RM）和应用主机（Application Masteer(AM)）。RM是将集群资源视作统一的视图，并与之一起的整体调度；它还负责全局调度。AM根据相关作业执行情况为RM负责具体作业资源征用。 AM向RM发送资源请求。RM用一个租约授权应答，并为AM申请一个容器（绑定到一个特定结点上的逻辑资源分组）。资源请求（ResourceRequest类）包含容器数量、每个容器的大小（4GB内存和两核CPU）、位置参数，以及应用中的请求优先级。AM创建执行计划，基于它从RM收到的容器集更新。AM通过节点管理器（NM）（驻留在集群的每个节点上）发送给RM的消息获取节点中的容器状态，RM又把消息传播给各个AM。基于这些状态，AM能够重启失败任务。AM注册到RM并定期向RM发送心跳。它在这些消息里带着它的资源请求。 RM负责客户端应用的提交，拥有集群的完整视图，为AM分配资源，通过NM监控集群。它通过NM的心跳获取有效资源。借助这个集群的全局视图，RM满足公平性和活跃度等调度属性，负责为更好的集群效用提供支持。RM向AM容器以及访问这些容器的令牌。RM也可以从AM请求资源（在集群过载的情况下）——AM可以为这些请求生产一些容器。 NM注册到RM，并持续发送心跳消息。它通过心跳消息向RMK发送节点上的有效资源，比如CPU、内存，诸如此类。NM还负责容器租约、监控、管理容器执行。容器由容器启动上下文描述（CLC）——上下文包括执行启动的命令、安全令牌、依赖（可执行文件、压缩包）、环境变量，等等。NM可能会杀死容器，比如在容器租约结束时，即使调度器决定取消它也会如此。NM还监控节点健康状况，并在发现节点有任何硬件或软件问题时修改它的状态为不健康。

YARN上的其它的框架

整体YARN架构如图6.1。这张图清晰的验证了本书要阐释的超越Hadoop MapReduce思想。存储在HDFS的数据可以用多种方式，通过不同的框架处理，而不只是Hadoop MapReduce（还有Pig和Hive）。举个盒子，Hortonworks已宣布支持基于Storm的流式处理——这意味着当数据以流的方式到达时，它可以通过Storm处理并储存在HDFS以备历史分析。类似的，Tez这样的开源平台可以用来做HDFS数据的交互式查询处理。

图6.1  Hadoop YARN架构：不同框架处理HDFS数据

Tez是新的Hadoop YARN生态系统平台之一——它拥有执行无环有向图的能力，这样的图可以是一个数据流图，以顶点表示数据的处理，以边表示数据的流向。查询计划由Hive和Pig生成，比如，可以无环有向图的形式浏览。无环有向图通过Tez应用编程接口构建。（Tez API允许用户指定无环有向图、顶点计算，以及边。它还支持无环有向图的动态识别。） 另一种处理可能是迭代式机器学习——Spark是一个理想选择，如同本书所展示的。它适合应用于YARN，因为Spark已有运行于Hadoop YARN之上的发布版。整个Spark生态系统——包含Spark流和Shark——都可以处理储存在HDFS的数据。 图处理框架也能够处理HDFS的数据——Giraph（由Hortonworks支持）和GraphLab是不错的选择。（GraphLab团队正在开发对Hadoop YARN的支持。）来自Spark生态系统的GraphX是这一领域的另一种选择。

大数据分析的未来是怎样的？

本节探讨未来的大数据分析的技术前景。

要探讨的一件有趣的事情是在Apache Tez之上实现机器学习算法。这里要解决的问题在于是否存在帮助实现迭代式机器学习的无环有向图执行器。主要的挑战是停止/结束条件不可是静态的，而只能在运行时。这一点已在最近由Eurosys提出的Optimus系统（Ke等2013）探讨过，该系统提供了一个在DryadLINQ上实现机器学习算法的途径。

另一件需要引起注意的有趣工作是来自斯坦福大学的Forge系统（Sujeeth等2013）。Forge提供了一个领域特定元语言（DSL），该语言允许用户为不同领域指定DSL。DSL概念的引入作为分布式系统的替代手段——后者从程序员以及高效实现的领悟中抽象出来的。Forge也有为机器学习提供的特定DSL，称做OptiML。Forge即有单纯的Scala实现（用于原型机）也有高效并行的分布式实现，后者可以部署在集群环境（用于生产环境）。Forge使用Delite框架（Brown等2011）实现了后者的一部分。性能测试显示了由Forge在集群节点上自动生成的分布式实现相当于用Spark实现的等价功能的40倍性能。它也表达了Spark仍然有优化的可能性——这一点值得做更进一步的探讨。

大数据方面的深度学习仍然是神圣领域的圣杯。近期来自谷歌的论文显示已取得一定进展（Dean等2012）。这篇论文展示了两种训练算法，多点同时随机梯度下降算法（译者注：原文为Downpour Stochastic Gradient Descent，译文参考：http://blog.sina.com.cn/s/blog_81f72ca70101kuk9.html）和集群多节点L-BGFS（译者注：原文为SandblasterL-BGFS，译文参考前面的链接），用于训练深度神经网络。核心思想是共享参数服务器用于多模型副本并行训练。尽管参数服务器在训练时是共享的，分片本身也会成为单点故障。一个可能的改进是在它们之间覆盖网络，作为通讯的对等集合查看参数服务器，就像OpenDHT或Pastry。这样参数服务器就实现了容错，甚至提升了性能。

使用七大任务（译者注：此处应为前面章节提到的以下七类任务：基础分析、线性代数运算、广义的多体问题、图形计算、优化、积分、比对问题）的目的是需要描述为机器学习这类计算并识别在大数据世界里当前实现的差距。就任务6、7的实现而言，它们之间在集成方面就有差距（在处理数据方面的整合工作上），可能要求马尔科夫链的蒙特卡罗（MCMC）实现，正如在第一章解释过的，“介绍：为什么要超越Hadoop Map-Reduce？”。MCMC在Hadoop上是出名的难以实现。Spark可能是最理想的。类似的，任务7（比对问题）可能要求隐马尔科夫（HMMs）实现。这一点就是另一个领域的讨论了——实现了隐马尔科夫模型的大数据。应用包括图像的重复数据删除（比如，在Aadhaar工程中——印度的身份项目，要求如何从存储的数以亿计的图像中找出重复的照片）。

D-wave量子计算机已被安装在量子人工智能（AI）实验室（由NASA、谷歌，以及大学空间研究协会联合运行）。这一举措的根本目的是用量子方法探讨难以解决的问题（任务5）。谷歌还聘请了一些人工智能研究人员，比如Ray Kurzweil。这一系列的举措的圣杯是量子机器学习，可能会有人使用这一术语。而它已被麻省理工学院的Seth Lyod在量子计算国际会计中提出（ICQT 2013: http://icqt.org/conference/）。他的工作是使用量子比特检索（译者注：Qbit，量子比特）。在大数据集环境下它可以快速给出结果，同时又抛出了另外的有趣问题：隐私。量子比特不能在传输过程中窥探——窥探会影响量子比特状态。当然这是一个值得深入探索的领域。

分析领域的另一项有趣进展是基于磁盘的单点分析——与云/分布式的趋势背道而驰。由GraphLab的创建者发表的GraphChi的论文（Kyrola等2012）提出了例证。GraphChi提供了一种处理磁盘上的大型图的机制。对于Twitter-2010图型的三角形计数，他们表现也单点低于90分钟的性能，而相同功能的hadoop实现却要在一个分布式环境下的1400个工作进程花费400分钟。GraphChi采用一系列外存算法和并行滑动窗口的方式异步处理磁盘上的大型图。2014年10月，在纽约的一次Strata会议中，Sisense，一家小的初创公司，展示了它单节点10秒钟内处理10TB的能力，而全部花费不到10,000美元（www.marketwired.com/press-release/-1761584.htm ）。探索GraphChi在分布式环境的应用大概会很有趣——它可能会提供快速处理巨型图的能力。

另一件有趣的趋势是大数据、移动设备和云端在物联网（IoT）的支持下的整合。对于大数据架构/研究，这里蕴藏着巨大的机遇，因为通过物联网有更多来自用户的有效数据，同时还提供了数据分析的温床。通过云端的大量大数据平台，云端已与大数据做了很大程度上的整合。IoT与大数据云的整合可能是一个可预见的趋势。