Hive on Spark & Tachyon解析

http://www.csdn.net/article/2015-04-01/2824369

 

在2015年3月14日的上海Spark Meetup第三次聚会上，Cloudera公司副总裁苗凯翔在开场发言中首先回忆了Hadoop的由来。

苗凯翔：Hadoop & Spark

Cloudera公司副总裁 苗凯翔

Hadoop由Doug Cutting根据Google论文编写，当下已成为大数据处理的主流平台。Doug于2008年Cloudera成立时离开雅虎，其后便一直担任Cloudera的首席架构师。同时，Doug也一直是Apache软件基金会主席，带领着Hadoop的发展。当下，Hadoop代表的已不仅仅是一个计算框架，而是一个庞大的生态圈，拥有大量的计算单元，而Spark加入这个大家庭则是这两年非常重要的一点。Spark拥有很多优势，其最大的两个特点就是简单和快。从Cloudera来看，Spark并不是Hadoop的取代，而是天然的结合，互为补充。在取代MapReduce的同时，与YARN、Impala等组件共存，带来很多功能上的增补，比如机器学习。Cloudera在Spark社区中一直非常积极，同时也是Spark最大的贡献者之一，拥有大量的资源和提交者。

在提到合作伙伴Intel时，苗凯翔将之称为“Hadoop的黄埔军校”，从09年开始研究Hadoop，Intel的起步非常早，从而有着非常深的积累。同时，着眼中国区的Cloudera，其中很多研究者来自Intel，而Intel在Spark社区贡献上也排行第三。因此，站在大数据实时计算的角度，由Cloudera和Intel一起举办的Spark Meetup也非常有意义。

陈建忠：Advanced Analytics with Spark

Cloudera高级解决方案架构师 陈建忠

在陈建忠开场两个简单的调查中我们发现，与会者中几乎所有人都尝试过Spark，其中更有一些用户已经投入生产环境使用，而SQL on Spark则成为大家最期望了解的方面。为此，陈建忠从Hive on Spark和如何使用Spark加速业务两个方面进行了讲解。

在演讲开始，陈建忠首先介绍了Cloudera对Spark的贡献。陈建忠表示，Spark在2013年成为ASF的顶级项目，而Cloudera在2014年初已经开始拥抱Spark，将其加入CDH 5.0发行版。而在生态系统上，Cloudera主要和Intel合作参与了以下几个方向的建设：Hive on Spark，一些代码和优化基本已经在Hive上实现；Pig on Spark，主要服务于Hadoop生态圈一些已有的Pig用户；Spark over YARN；Spark Streaming可靠性，主要针对一些数据丢失和驱动出错等问题；通用的Spark优化，比如Shuffle低效性等。限于篇幅问题，下面重点探讨一下Hive on Spark。

Hive on Spark

在许多已有Hadoop企业中，Hive担当着非常重要的角色，为Hadoop注入了使用SQL的能力，已经成为SQL on Hadoop上的事实标准。基于这些原因，Cloudera选择继续拥抱Hive，主要的精力则放在性能和最小化特性差异上，造福大量期望利用Spark引擎高效性的Hive重度用户。

Hive上的修改

在Hive on Spark设计原则上，工程师主要尊重以下几点：首先，尽量少的改动Hive已有代码；其次，最大化代码重用；再次，最小化feature的改动，带来更多的兼容性，也减少了后续的维护开销。

如上图所示，在类层次结构中并无太大的变动，通过加入SparkCompiler、SparkTask和SparkWork形成完整的计算体系。

Work真正拥有包装的是MapReduce或者Spark Job，类似“select name,sum(value) as v from dec group by name order by v;”这样的查询，在之前我们需要两个MR作业，而现在一个Spark作业（一个Map作业和两个Reduce作业）就可以完成。

Spark上的修改

Spark Client：首先，负责与Spark cluster通信；其次，需要支持多种部署类型，local（单节点模式）、local-cluster（伪分布式）、standalone（Spark自己负责resource allocation）、yarn-cluster（Spark Driver会在YARN的Container中运行）以及yarn-client（Spark Driver以客户端的方式运行）；最后，还会做作业提交、监视、错误报告、统计、度量、计数等任务。

Spark Context，需要注意的是它不仅是一个广义上的Driver，而且是非常重量级的组件，很多计算都在其中进行。同时需要注意的是，Spark Context是thread-unsafe的，因此同一个JVM中不能建立两个Spark Context；最后，Spark Context设计之初就是建立在单用户应用程序之上，因此不能有多session存在。因此，这里引入了Remote Spark Context，详见下图。Remote Spark Context会在独立的JVM进程中运行，Hive Server 2的进程中可以运行多个用户的Session，每一个Session含有一个Remote Spark Context的客户端，此客户端已RPC方式向Remote Spark Context发送命令。这样就有效解决了在同一个Hive Server 2中不能运行多个Spark Context的问题。

Spark中的数据处理逻辑

在Hive on Spark下，表格的建立即是生成一个HadoopRDD。同时，Map端的数据处理task即被转换为Spark中的函数。而对于shuffle来说，一些转换则可以调用Spark中的操作，比如groupByKey、sortByKey等。最后，提供了Reduce端处理的一些函数。

Hive on Spark当前状态

目前，基本上Hive的所有功能已被实现，会在Hive 1.1被添加到Trunk里。同时，第一轮优化已经结束，其中包括Map join、SMB、Split generation and grouping、CBO、vectorization等。当然，未来还会有更多优化被添加。

总结

陈建忠表示，在现实世界中，有很多业务涉及到大数据的处理，比如检测信用卡欺诈、智能商品推荐、金融风险评估、基因分析等。而在所有场景中，数据科学家往往面对众多挑战：随着数据体积、数据源的增多，传统R等工具已经无法满足需求；其次，数据科学家的使用场景通常都会碰到迭代操作，然而传统基于磁盘的工具（比如MapReduce）很显然无法满足快速处理的需求；最后，还有实时处理的需求，传统的数据挖掘工具着重于模型的建立，而当下模型需要部署在生产环境中进行实时数据分析，且需要对模型进行实时调整。演讲的最后，陈建忠通过VaR（Value at Risk，风险价值或者风险收益）用例简单地演示了如何通过Spark加速业务的发展。

史鸣飞：Tachyon介绍及应用总结

英特尔亚太研发有限公司大数据技术部软件工程 史鸣飞

Intel大数据团队于2012年加入Spark社区，是国内最早参与Spark开发和推广的团队之一，在Spark及相关项目中拥有超过10位活跃的Contributor，而在2012年已经参与Tachyon社区。本次史鸣飞演讲的主题包括Tachyon的介绍、Tachyon的应用实例、Tachyon当前的发展状况，以及Intel在Tachyon上的贡献。

关于Tachyon

1.Tachyon出现的背景

史鸣飞表示，鉴于大数据对速度的追求，在内存速度提升远高于磁盘以及内存价格越来越低的当下，机构使用内存来缓存大量数据已经越来越普遍，“内存为王”已被越来越多的用于生产实践中。同时，在这种趋势下，越来越多基于内存的框架被开发，比如Spark。然而，现有基于内存的计算框架所面临的挑战亦不可谓不多，下面即以Spark为例，描述基于内存（尤其是基于JVM）计算框架所面临的挑战。

数据共享。同一集群中，可能会运行着多个不同的计算框架，比如MapReduce和Spark，在现有条件下，两个框架如果需要共享数据必须通过共享存储实现（HDFS）。而HDFS的访问则会引起磁盘和网络的IO，因此这是一个很低效的过程。

缓存数据丢失。Spark运行在JVM上，现有的缓存机制使用block manager把数据缓存在JVM堆内存中。一旦执行引擎崩溃，缓存数据丢失。

GC开销。数据缓存在JVM堆内存空间中，GC开销随应用程序运行时间和堆内存空间中缓存数据量的增长而迅速增长。

而之所以产生这些问题，其根本原因在于缺乏独立的脱离JVM管理的内存管理模块。首先，缺乏独立的内存管理模块，从而造成了数据共享上的问题，这主要是因为现有Spark的内存管理处于执行引擎中，所有的数据管理都在一个application（或者框架）内部，因此脱离了这个application，在内存中缓存的数据就无法被访问。其次，JVM管理，当下所有数据都储存于JVM的堆内存空间中，因此无法避免GC的开销；那么，想避免GC开销，数据必须要脱离JVM。而这些正是Tachyon的设计初衷，一个脱离JVM管理的内存管理模块。

2.Tachyon的设计思想和特性

Tachyon在大数据技术堆栈中所处的位置

Tachyon是一个基于内存的OffHeap的分布式存储，因此它可以最直接地解决了Spark做数据管理时所碰到的问题。基于内存空间大小的限制以及网络IO的考虑，Tachyon只会将数据在内存中保存一份。

元数据的容错和HDFS的原理和方法相似，内存文件数据通过在存储层保存数据的Lineage实现容错，当数据丢失时基于Lineage进行数据恢复，这还是个alpha的功能，暂时不推荐使用。

3.Tachyon的基本架构

从整体上看，Tachyon的架构与HDFS有一些类似。首先，Master负责存储Tachyon Cluster中所有文件的元数据，包括目录结构、location、大小等。其次，Worker负责管理集群中每个节点的存储空间，它直接使用了Linux的Ramdisk，把内存空间映射为block设备，让Tachyon可以在Ramdisk上做数据的读写。此外，Tachyon还存在一个被用户程序所使用的组件——Client，也就是用户程序的编程接口。用户程序通过Client访问Tachyon的存储空间，而Client则会负责与Master和Worker的交互。在图最左边还存在ZooKeeper，用于管理主从Master设置。

4. 现有问题的解决

数据共享。通过Tachyon来储存中间结果，避免了数据落到磁盘上，以实现内存数据共享。同时，绕过了HDFS可以减少因此造成的磁盘和网络IO。

缓存数据丢失。因为所有缓存数据都储存在Tachyon的OffHeap空间中，由Spark任务异常造成的JVM崩溃将不会引发数据丢失。

GC开销。因为所有缓存数据储存于Tachyon，从而就会解决GC的问题。需要注意的是，Tachyon解决的是缓存数据带来的GC，而非Spark任务执行过程中的GC。

Tachyon应用

在介绍完Tachyon的架构和设计原则后，史鸣飞分享了3个Tachyon实际使用场景。

1.流式处理框架

如上图所示，在流式处理框架中，在Event logs进入系统后首先使用Kafka进行缓存，随后通过Spark Streaming对缓存的数据进行处理，并将处理完成的数据存入Tachyon的In-Memory Tables中，随后可以通过Spark SQL或者Shark对In-Memory Tables中的数据做交互式的查询、在线分析等处理。如果缺少Tachyon，数据就很难在不同框架之间做共享，如果后端使用Shark做分析，那么Shark和Spark Streaming必须同时启动在一个Spark Context中。Spark Streaming将RDD写入Shark Context的RDD中，随后Shark才能访问这些数据。

2.OffHeap存储

如上图，在多次迭代，大数据量的情况下，使用Tachyon可以显著地减少GC开销，从而带来非常大的性能提升。但是需要注意的是，在数据体积不大的情况下，使用Tachyon所带来的额外开销甚至会拉低系统性能。

3. 远程数据缓存

在实际应用场景中，有些集群可能专门负责数据的存储（比如S3），而有些集群则专门负责计算（比如EC2），那么如果应用需要多次访问远程数据，集群之间的数据搬运将消耗大量的网络资源。而在使用Tachyon之后，计算集群从远程存储集群读取数据，缓存至Tachyon进行多次读取和计算。

总结

综上所述，在现有业务中，Tachyon拥有非常广泛的使用场景：中间结果数据需要在不同的应用/计算框架之间共享；需要快速响应，对延迟敏感的应用；内存数据量比较大，并且拥有长时间/迭代式的计算需求；需要多次访问大量的远程数据。然而，Tachyon也存在一定的局限性，比如CPU负载增大，以及序列化和反序列化引入开销。

Tachyon项目于2012年夏开始于UC Berkeley AMPLab，当下已经在超过50家公司中被使用，拥有60多位Contributor，分别来自二十多个组织。当下，Spark和MapReduce程序可以不经修改直接运行在Tachyon上，而Spark将Tachyon作为默认的OffHeap的存储系统。值得一提的是，Intel在Tachyon上同样拥有不错的贡献，拥有3位活跃的Contributor，贡献超过200个的提交，其中就包括在多层级的本地存储的贡献。