Spark技术解析及其在百度最大单集群1300台的应用实践2

问题导读
1、Spark技术有哪些热点？
2、如何更好的使用Tachyon？
3、Tachyon在百度实践中遭遇的挑战有哪些？





本文接前篇：
1、Spark技术解析及其在百度最大单集群1300台的应用实践


摘要：
2015年1月10日，一场基于Spark的高性能应用实践盛宴由Databricks软件工程师连城、百度高级工程师甄鹏、百度架构师孙垚光、百度美国研发中心高级架构师刘少山四位专家联手打造。
百度基础架构部架构师孙垚光——百度高性能通用Shuffle服务


在2014 Sort Benchmark国际大赛上，百度成功夺冠，其幕后英雄无疑卓越的Shuffle机制，在孙垚光的分享中，我们对Shuffle的发展、细节和未来有了一次深度的接触。


Shuffle简介

孙垚光表示，简单来说，Shuffle就是按照一定的分组和规则Map一个数据，然后传入Reduce端。不管对于MapReduce还是Spark，Shuffle都是一个非常重要的阶段。然而，虽然Shuffle解决的问题相同，但是在Spark和MapReduce中，Shuffle流程（具体时间和细节）仍然存在一定的差别：



Baidu Shuffle发展历程

通过孙垚光了解到，Shuffle在百度的发展主要包括两个阶段：跟随社区和独立发展。从2008年百度的MapReduce/Hadoop起步开始，百度就开始跟随社区，使用社区版本，期间的主要工作包含Bug修复和性能优化两个方面（增加内存池、减少JVMGC，传输Server由Jetty换Netty，及批量传输、聚合数据等方面）。


分离了shuffle和Map/Reduce

在2012年开始，Baidu Shuffle开启独立发展阶段，主要源于下一代离线计算系统的开发，Shuffle被抽离为独立的ShuffleService服务，从而提高了集群资源的利用率。

截止此时，不管是社区版本（MapReduce/Spark），还是百度研发的ShuffleService，它们都是基于磁盘的PULL模式。基于磁盘，所有Map的数据都会放到磁盘，虽然Spark号称内存计算，但是涉及到Shuffle时还是会写磁盘。基于PULL，所有数据在放到Map端的磁盘之后，Reduce在使用时还需要主动的拉出来，因此会受到两个问题影响：首先，业务数据存储在Map端的服务器上，机器宕机时会不可避免丢失数据，这一点在大规模分布式集群中非常致命；其次，更重要的是，Shuffle阶段会产生大量的磁盘寻道（随机读）和数据重算（中间数据存在本地磁盘），举个例子，某任务有1百万个Map，1万个Reduce，如果一次磁盘寻道的时间是10毫秒，那么集群总共的磁盘寻道时间= 1000000 ×10000 ×0.01 = 1亿秒。

New Shuffle

基于这些问题，百度设计了基于内存的PUSH模式。新模式下，Map输出的数据将不落磁盘，并在内存中及时地Push给远端的Shuffle模块，从而将获得以下提升：


New Shuffle的优势


New Shuffle架构

如图所示，蓝色部分为New Shuffle部分，主要包含两个部分：数据写入和读取的API，Map端会使用这个接口来读取数据，Reduce会使用这个接口来读取数据；其次，最终重要的是，服务器端使用了典型的主从架构，用多个shuffle工作者节点来shuffle数据。同时，在系统设计中，Master非常有利于横向扩展，让shuffle不会成为整个分布式系统的瓶颈。

让New Shuffle模块专注于shuffle，不依赖于外部计算模块，从而计算模块可以专注于计算，同时还避免了磁盘IO。然而New Shuffle带来的问题也随之暴漏，其中影响比较重要的两个就是：慢节点和数据重复。

慢节点。以shuffle写入过程中出现慢节点为例，通常包含两个情况。首先，Shuffle自身慢节点，对比社区版本中只会影响到一个task，New Shuffle中常常会影响到一片集群。在这里，百度为每个Shuffle节点都配置了一个从节点，当Map检测到一个慢节点时，系统会自动切换到从节点。其次，DFS出现慢节点，这个情况下，Shuffle的从节点只能起到缓解作用。这种情况下，首先DFS系统会自动检测出慢节点，并进行替换。比如，传统的HDFS会以pipeline的形式进行写入，而DFS则转换为分发写。

在此之外，New Shuffle还需要解决更多问题，比如资源共享和隔离等。同时，基于New Shuffle的机制，New Shuffle还面临一些其他挑战，比如Reduce全启动、数据过于分散、对DFS压力过大、连接数等等。


数据重复。如上图所示，这些问题主要因为New Shuffle对上层组件缺少感知，这个问题的解决主要使用task id和block id进行去重。

New Shuffle展望

孙垚光表示，New Shuffle使用了通用的Writer和Reader接口，当下已经支持百度MR和DCE（DAG、C++），同时即将对开源Spark提供支持。在未来，New Shuffle无疑将成为更通用的组件，支持更多的计算模型。

百度美国硅谷研发中心高级架构师刘少山——Fast big data analytics with Spark on Tachyon


Tachyon是一个分布式的内存文件系统，可以在集群里以访问内存的速度来访问存在Tachyon里的文件。Tachyon是架构在分布式文件存储和上层各种计算框架之间的中间件，主要负责将那些不需要落到DFS里的文件，落到分布式内存文件系统中，从而达到共享内存，以提高效率。1月10日下午的最后一场分享中，刘少山带来了一场Tachyon的深入解析。

Tachyon和Spark

刘少山表示，在Spark使用过程中，用户经常困扰于3个问题：首先，两个Spark 实例通过存储系统来共享数据，这个过程中对磁盘的操作会显著降低性能；其次，因为Spark崩溃所造成的数据丢失；最后，垃圾回收机制，如果两个Spark实例需求同样的数据，那么这个数据会被缓存两次，从而造成很大的内存压力，更降低性能。


使用Tachyon，存储可以从Spark中分离处理，让其更专注于计算，从而避免了上述的3个问题。

Tachyon架构


刘少山从Spark的角度分享了Tachyon的部署。在与Spark搭配使用时，系统会建立一个Tachyon的job，通过Tachyon Client来访问同一个机器上的Tachyon Worker，也就是机器上的内存。而Tachyon Client则会与Tachyon Master交互，来清楚每个分节点所包含的数据。由此可见，在整个Tachyon 系统中，Master、Client和Worker为最重要的三个部分。

Tachyon Master。Master主要部件是Inode和Master Worker Info：Inode会负责系统的监视，Master Worker Info则存储了所有Worker的信息。

Tachyon Worker。Worker主要负责存储，其中Worker Storage是最主要的数据结构，包含Local data folder和Under File System两个部分。其中Local data folder表示存在本地的Tachyon文件，Under File System则负责从HDFS中读取Worker中未发现的数据。

Tachyon Client。Client为上层用户提供了一个透明的机制，其TachyonFS接口负责数据请求。每个Client中有多个Tachyon File，其中Block In Stream负责文件读取（Local Block In Stream负责本地机器读取，Remote Block In Stream则负责读取远程机器）；Block Out Stream主要负责将文件写到本地机器上。在Client上，Master Client会与Master交互，Worker Client则与Client交互。

Tachyon在百度

为什么要使用Tachyon，刘少山指出，在百度，计算集群和存储集群往往不在同一个地理位置的数据中心，在大数据分析时，远程数据读取将带来非常高的延时，特别是ad-hoc查询。因此，将Tachyon作为一个传输缓存层，百度通常会将之部署在计算集群上。首次查询时，数据会从远程存储取出，而在以后的查询中，数据就会从本地的Tacnyon上读取，从而大幅的改善了延时。


在百度，Tachyon的部署还处于初始阶段，大约部署了50台机器，主要服务于ad-hoc查询。

实践中遭遇的挑战

通过刘少山了解到，Tachyon的使用过程并不是一帆风顺，比如：因为Tachyon需求对Block完全读取，从而可能造成Blocks并未被缓存；有时候，虽然scheduler已经确认了数据存在本地，Spark workers仍然从远程blocks读取，而缓存命中率也只有可怜的33%（如果你需要的是2号block，Tachyon会分别从1、2、3号block读取，从而将block读取了3份）。因此，刘少山表示，如果要使用好Spark与Tachyon，一定要对用例和Tachyon进行充分的了解。

分享最后，刘少山还介绍了Hierarchical Storage Feature特性以及百度未来的工作，其中包括缓存替换策略等。