Tachyon在Spark中的做用（Tachyon: Reliable, Memory Speed Storage for Cluster Computing Frameworks 论文阅读翻译）

本人不多转载别人的文章，但看了这篇文章感受很是不错，我不晓得这篇文章是不是此人原创翻译的，但给点个赞吧，加油

转载于：http://blog.csdn.net/hust_sheng/article/details/47614925

摘要：

         Tachyon是一种分布式文件系统，能够借助集群计算框架使得数据之内存的速度进行共享。当今的缓存技术优化了read过程，可是，write过程由于须要 容错机制， 就须要经过网络或者是磁盘进行复制操做。 Tachyon经过将“血统”技术引入到存储层进而消除了这个瓶颈。建立一个长期的以“血统机制”为基础的存储系统的关键挑战是失败状况发生的时候及时地进行数据恢复。 Tachyon经过引入一种检查点的算法来解决这个问题，这种方法保证了恢复过程的有限开销以及经过资源调度器下进行计算所须要的资源获取策略。咱们的评审展现了 Tachyon的write性能超过HDFS达到100X，也将 现实 工做流的端到端的负载提高了4X。

 

（补充）：

         Tachyon是Spark生态系统内快速崛起的一个新项目。 本质上，  Tachyon是个分布式的内存文件系统， 它在减轻Spark内存压力的同时，也赋予了Spark内存快速大量数据读写的能力。Tachyon把内存存储的功能从Spark中分离出来， 使Spark能够更专一计算的自己， 以求经过更细的分工达到更高的执行效率。

        Spark平台具体问题主要有如下几个：

1. 当两个Spark做业须要共享数据时，必须经过写磁盘操做。好比：做业1要先把生成的数据写入HDFS，而后做业2再从HDFS把数据读出来。在此，磁盘的读写可能形成性能瓶颈。
2. 因为Spark会利用自身的JVM对数据进行缓存，当Spark程序崩溃时，JVM进程退出，所缓存数据也随之丢失，所以在工做重启时又须要从HDFS把数据再次读出。
3. 当两个Spark做业需操做相同的数据时，每一个做业的JVM都须要缓存一份数据，不但形成资源浪费，也极易引起频繁的垃圾收集，形成性能的下降。 

介绍：

         虽然如今有不少程序框架和存储系统用来改善大规模数据的并行处理性能，可是，这些系统的瓶颈都是I/O操做过程，目前的解决方法是经过cache进行数据缓存。可是随之而来的问题就出现了，cache能够显著改善read性能，可是由于容错的须要，必须经过节点之间的数据传递对“写的数据”进行复制备份，可是，因为节点之间数据复制的过程当中网络的延迟以及吞吐率性能的低下，致使即便数据被复制存储在内存中，write过程的性能也不好。

         write性能低下会严重影响到job工做流的性能，由于job之间会彼此影响。为了改善写性能，咱们提出了 Tachyon（一个基于内存的存储系统）来实现write和read的高吞吐率，同时没有牺牲容错机制。 Tachyon经过利用“血统“绕开了重复复制带来的吞吐率的局限性。采用的方法是经过再次对task之上的操做进行计算来 恢复 出错或者丢失的数据（跟Saprk的容错机制是同样的，只是在 Tachyon进行存储的阶段也是采用“血统”机制 ）而无需进行数据备份。

         然而，将“血统机制”引入接二连三的分布式存储系统中也是有必定挑战的。

         （1）第一个挑战是，如何限制一个长期执行的存储系统的重复计算（容错操做）的开销。该挑战对于一个单一的计算job是不存在的，好比一个Mapreduce job或者是一个Spark job，由于在这种状况下重复计算的时间被job的执行时间所限制。相反， Tachyon的执行过程是不肯定的，这意味着重复计算的时间可能没法被限制。有一些框架好比Spark Streaming经过周期性（能够本身设置时间间隔）地设置检查点（checkpoint操做,设置checkpoint目录进行数据备份以及执行位置的标记）能够避开这个问题，但不幸的是， Tachyon中基本不能照作，由于存储层不能感知到job当前的执行语义，job的计算特性的分类也十分普遍复杂。尤为是，当 可用的带宽没法知足 数据的写速度，固定时间间隔的检查点操做可能会致使无限制的数据恢复操做（由于job的执行状况是透明的，因此checkpoint设置的合理性相当重要）。相反，基于“血统图”进行数据检查点设置的 选择反而能够对重复计算过程进行限制。

         （2）第二个挑战是如何为重复计算过程获取资源。好比，若是job之间有优先级的话， Tachyon在一方面必须确保重复计算获取到足够的资源，在另外一方面，重复计算不能影响到当前具备高优先级的正在执行的job的性能。

         解决上述挑战的方法：

         （1）第一个挑战： Tachyon在后台经过异步执行某种算法不断的对相应文件设置检查点（文件信息备份）来解决第一个挑战。咱们也提出了一个新奇的算法来决定什么时候以及选择哪个文件来检查，这个算法叫作边沿算法（Edge algorithm ），这种算法对重复计算的开销进行了较好的限制。

           （2）对于第二个挑战， Tachyon提供了一种资源申请方案，该方案能够作到：准守严格的job优先级并按照权重进行资源分配。

         论文最终获得的结论是： Tachyon的write性能超过HDFS达到100X，也将现实工做流的端到端的负载提高了4X（相对基于内存的 HDFS ）。另外， Tachyon能够将复制备份引发的网络传输减小高达50%。最后，基于对Facebook和Bing的跟踪，能够发现 Tachyon的重复计算开销占用的集群资源不超过1.6%。

         更为重要的是，因为复制备份操做的固有带宽限制，将来，一个基于“血统”的容错模型多是让集群存储系统可以匹配内存计算的惟一方法。

背景：

•  （待改善的）目标的工做负载属性
  

1. 数据的不变性。数据一旦进行write就不可变了，存储系统只是提供数据之上的扩展操做。
2. 肯定性的工做任务。MapReduce和Spark等框架都要求用户代码肯定的状况下执行“血统”机制。对于工做任务不具备肯定性的框架，就采用复制备份进行容错处理。
3. 基于位置的调度。MapReduce和Spark等框架都是基于位置进行调度的，这样能够尽量地减小网络传输的开销。
4. 应用的工做区必须在内存，数据能够在磁盘。
5. 尽可能进行程序操做的复制，而尽可能避免数据的复制。由于操做的复制开销要更小。（好比：相同的操做在大量数据之上反复被执行，代码书写的过程当中，要选择让操做程序进行屡次复制，而不是让数据进行复制）

• 避免复制操做（避免memory与其余媒介进行数据交换）的情景

    一些基于内存的计算框架例如Spark确实加速了一些特定job的执行速度，可是，不一样种类的job之间可靠的数据共享却成为瓶颈。

    

    从上图能够看出，如今主流系统使用的媒介，HDD、SDD以及网络传输所支持的带宽都远远小于内存支持的带宽。

    大数据处理过程当中的数据共享开销每每会主导流水线端到端的时延。

    现实中的数据代表有34%的job， 其 输出的 数据量 至少等于输入的数据量，在集群计算的过程当中，这些job就会限制write的吞吐率。

    硬件的改进没法解决上述问题。一个节点之上，内存的带宽比disk整体带宽要高出1~3个数量级。SDD的出现也没有太大做用，毕竟它相对磁盘的主要优点是随机访问的性能提高，而不是连续的I/O带宽的提高（表中可见），后者才是关键。

设计综述：

•  系统架构
  

    Tachyon由两层组成：“血统”和持久化存储。“血统”层级提供很高的I/O吞吐率而且会追踪job执行的连续过程。持久化层主要被用于异步检查，持久化层能够是任何以数据备份为基础的存储系统，HDFS，S3等。

    

     Tachyon采用了标准的master/slave架构：为了管理元数据，master必须包含一个workflow manager，该管理器的做用就是跟踪“血统”信息，计算检查点操做的顺序（对应第一个挑战）以及与集群资源管理器进行交互来为从新计算申请资源（第二个挑战）。

    每个worker上都跑着一个守护进程用来管理本地资源而且按期将worker状态报告给master节点。另外，每个worker节点都会用RAMdisk来存储 内存映像文件，用户的应用能够绕过守护进程直接和 RAMdisk进行交互，这样，一个具备数据本地性的应用能够避免没必要要的数据拷贝，之内存速度进行数据交互。【内存文件管理系统】

• 举例

    

    须要注意的是，“血统”信息是存储在 Tachyon的持久化层的。

    咱们都知道， Tachyon会经过避免复制备份来改善write性能，然而，复制备份对于不少job同时read读取相同的数据的状况有明显的优化做用。虽然， Tachyon使用“血统”机制避免了数据的复制备份，可是 Tachyon并非彻底没有数据备份的。 Tachyon也使用客户端cache技术来对频繁读取操做的状况进行优化：当一个文件不在当前机器时，该文件会被从远程机器上读取过来而且缓存在 Tachyon本地的cache里面，这是 Tachyon中的数据备份现象 。

• API总结

    须要特别说明的是， Tachyon自己就是一个标准的文件管理系统，支持全部标准的文件管理操做，除此以外还提供了获取job操做过程的“血统”信息的API接口。而且，使用者若是仅仅将 Tachyon做为传统的文件管理系统来用，而不使用 Tachyon的“血统”的API接口，这种状况下，write性能将不会获得改善，读写性能与其余文件系统好比HDFS差很少。

• Lineage Overhead（“血统”开销）
  

    从存储的方面来讲，“血统”信息被累积存储在二进制文件当中，可是，根据微软的数据统计：一个典型的数据中心平均天天执行1000个job，而且花费1TB大小的容量来存储一年下来全部job执行生成的未压缩的二进制文件，这样的数据量对于一个很小的数据中心来讲都是微不足道的。

    此外， Tachyon会对“血统”信息进行回收。 Tachyon在检查完输出文件以后会删除“血统”记录，这样会明显减小“血统”信息的大小。另外，在执行的过程当中，那些按期执行的job任务一般会变换参数屡次执行，在这种状况下，只有一份程序的拷贝会被存储。

• Data Eviction（数据回收）
  

    当数据量不超过内存大小的时候， Tachyon的执行性能很好，因此，问题就出现了：当内存占满的时候，数据如何回收呢？（有些数据使用率过低，须要移除内存，或者说从内存中删除）对于那些数据密集型的应用，咱们在数据回收的时候考虑如下两个因素：

    （1）访问频率

    （2）访问的临时本地性（75%的二次访问都发生在6个小时以内）

    在上述特性的影响下，咱们使用 LRU（近期最少使用算法） 做为默认的数据回收策略，固然LRU不必定适用于全部场景，因此 Tachyon同时也支持其余的数据回收策略。在下一个张章节中，咱们会给出这样的描述： Tachyon会将最大的文件除外的全部文件存储在内存中，大的文件直接存储在持久层。（就是spill过程）

•  Master Fault-Tolerance
  

     Tachyon经过master的备用节点进行master的容错处理。主master将自身每一步 的操做 以日志的形式都持久化存储在持久层之中，当主master节点出错的时候，备用节点经过读取日志（日志的大小微不足道）将自身改变成为与以前的master同样的状态。

• Handling Environment Changes
  

    还有一类问题 Tachyon会遇到，就是若是框架的版本变了或者是系统版本变了咱们如何经过“血统”信息 的二进制文件来支持重计算进而恢复文件数据。

    （1）咱们发现，系统变化以后，能够经过以前设置的 检查点进行计算恢复操做。所以，在计算环境改变以前，咱们须要作一些工做：

    a）全部当前未复制的文件都被设置检查点（备份）；

    b）全部的新数据都被同步保存

    固然，除了上述操做，咱们能够直接简单地将全部数据进行复制便可。

    （2）还有一种方法来更加高效地处理这种状况， 用虚拟机映像单独保存所需的计算环境（不作介绍）。

• Why Storage Layer（为何选择存储层）
  

    选择将“血统”机制引入存储层的缘由：

    （1）多个job在流水线中会造成复杂的“血统”关系；而且，在一个生产环境中，数据的生产者和消费者可能会在不一样的框架下面（一个job过程能够会涉及到多个框架之间的交互）。并且，仅仅在job级别或者是框架级别理解“血统”关系并无什么卵用，咱们应该深刻到存储层对“血统”信息进行统计。

    （2）一些信息只有存储层知道，好比何时文件重命名了或者何时文件被删除了，在存储层构建的“血统”才是最准确的。

检查点：

    该部分实际上是对Tachyon第一个挑战的解决说明。

     Tachyon利用 checkpoint算法来限制由于出错致使的文件恢复的时间开销。不像MapReduce或Spark的job那样，生命周期很短， Tachyon的job的生命周期很长 ，也正由于“血统”信息的复杂，若是没有检查点的设置，那么会须要很长的时间来执行重计算（血统过于复杂）。还有就是持续执行的像Spark Streaming这样的数据流系统， 会获取到当前执行的job的动做语义来决定在那些文件上以及什么时候进行检查点操做。 Tachyon没法获取到job具体的语义动做，可是也要进行检查点的设置。

     Tachyon的检查点设置的关键是”血统“容许后台之内存的速度异步执行检查点操做而不用中止写操做，且 Tachyon后台的检查点操做具备很低的优先级，目的是避免影响当前存在的job任务。

    理想的checkpoint算法须要知足一下几点：

    （1）限制重计算的时间。像 Tachyon这样长时间执行的系统，造成的”血统“链也很长，因此对于失败状况下的重计算操做的耗时要加以限制，须要注意的是，一旦咱们限制了重计算的时间就意味着咱们须要限制重计算所需的资源。

    （2）为”热“文件进行检查点操做

    （3）尽可能避免为临时文件进行检查点操做

• Edge Algorithm
  

    基于上述特性，咱们设计了 Edge算法：

    首先， Edge将要检查的文件选择的是”血统“图的叶子（边沿）文件；

    其次， Edge会结合文件的优先级进行检查点操做，即优先为优先级高的文件设置检查点。

    最后， Edge会将能够放入内存的数据集进行内存缓存，那些太大的文件会直接存储在持久层，若是很大的文件也存储在内存，须要进行checkpoint的时候，就会出现内存与磁盘的数据交换。目的就是避免同步设置检查点将write的速度下降到磁盘的速度。接下来依次进行分析。

Checkpointing Leaves

     Edge算法用DAG表示文件之间的关系，其中，文件是节点，文件之间的关系（B是某job read A以后生成的）造成DAG图的边（A-B）。这种算法对DAG图的叶子（边沿）节点进行检查点操做。以下图：

    

    上图表示了 Edge算法的工做过程。一开始，集群中只有两个job在运行，并生成了A1，B1。 Edge算法对A1，B1进行了检查点操做（备份），以后的阶段，A3，B4，B5，B6成为了叶子，并依次被进行检查点操做，以后阶段，A6，B9成为叶子。若是在A6进行检查点操做的时候出现了错误， Tachyon只须要对A4~A6的过程进行 从新计算。

Checkpointing Hot Files

     Tachyon分配优先级的策略是基于的是文件被读取的次数，与cache回收的LFU（最近最不经常使用页面置换算法）相似，保证了最频繁被获取的数据最早被进行checkpoint操做，这样显然能够加快数据恢复速度（容错处理）。

     Edge算法必须平衡叶子节点和优先级高的节点的checkpoint的操做。咱们经过下表进行分析。

    

    该表展现了来自雅虎的3000个节点的mapreduce集群的文件使用次数统计。基于这个表，咱们认为只要文件的访问次数查过2次，该文件就属于高优先级的文件。且基于该数据统计，发现86%的checkpointed文件都是叶子节点，所以，咱们能够获得这样的结论：优先级高的文件最早被执行checkpoint操做 （优先级高的文件自己就少，大概只有14%，可是仍然在checkpointed文件中占据14%的比例）。

    一个以复制备份为基础的文件系统必须复制每个文件，即便是job直接使用到的临时文件（也须要进行备份）。可是 Tachyon很对会对临时文件进行checkpoint（备份）操做，由于checkpoint操做针对的数据都比较靠后（叶子文件、优先级较高的文件），这样就使得临时文件在被执行checkpoint操做以前就会被删除掉（nice啊！）。

Dealing with Large Data Sets（大型数据集的处理）

    job过程当中除了很大的文件以外的几乎全部文件都被存储在内存中。

    由于96%的活跃jobs能够同时将本身的整个数据集保存在集群的内存中去，同时 Tachyon的master节点配置为能够同步地将上述数据集一次性写入磁盘。

    须要注意的是， 系统框架可能会遇到高丛发性（爆发性）的数据请求，在请求爆发期间， Edge算法会将内存中几乎全部的叶子节点以及非叶子节点都进行checkpoint处理（爆发性的数据请求会提高非叶子节点优先级，最终致使几乎全部的文件都checkpoint）。

     若是内存中的文件都是没有被执行checkpoint的（特殊状况），那么 Tachyon会同时对这些文件进行checkpoint操做来避免产生较长的”血统“链。

Bounded Recovery Time

    咱们将对DAG图上特定 叶子文件 i上执行checkpoint操做所花费的时间用Wi表示；将经过祖先转换成叶子文件i的操做过程所花费的时间表示成Gi，能够获得：

     定理一： Edge算法能够保证任何文件（发生错误）在3*M的时间被恢复，其中，M=maxi{Ti}，Ti=max(Wi, Gi).

    上述定理代表，重复计算与DAG图的深度是无关的（ 当数据集在内存中的时候， cache的表如今重复计算的过程当中是同样的）。

    上述对重复计算限制的 定理 没法应用到checkpoint算法对优先级的考虑因素中去。可是咱们能够很容易地获得优先级下checkpoint操做对 重复计算的限制：若是对叶子文件进行checkpoint的时间花费是c（在总的重复计算的时间中占用的比例），那么，优先级的checkpoint操做占用的时间就是1-c。

     推论二： 已知，对叶子文件进行checkpoint的时间花费是c（在总的重复计算的时间中占用的比例）。Edge算法能够保证任何文件（发生错误）在(3*M)/c的时间被恢复，其中，M=maxi{Ti}，Ti=max(Wi, Gi).

    

Resource Allocation资源申请

    该部分实际上是对Tachyon第二个挑战的解决说明。

   虽然Edge算法已经对重计算进行了限制， Tachyon还须要一种资源分配策略用于调度job的重计算。此外， Tachyon还必须遵照集群汇总现有的资源分配策略，好比均分或者是按照优先级分配。

    在不少状况下会有空闲的资源能够用于重计算，由于大部分计算中心计算资源的利用率只有30%~50%。当集群资源用完的时候，就须要考虑到相关的资源的分配问题。举一个例子，假如一个集群资源被三个job J1，J2，J3占据，同时有两个 丢失的文件F1，F2，须要执行 R1，R2两个job进行再计算才能够恢复。J2仅仅须要F2。 Tachyon怎么在考虑优先级的状况下安排重计算过程？

     Tachyon的 一个解决方案是进行集群资源的静态分配，好比将集群资源的25%分配给重计算过程。很显然，若是没有重计算任务这种方法限制了集群的利用率。另外，采用静态资源分配的策略，就会出现不少因素的影响，好比，上述状况，若是更高优先级的jobJ3须要文件F2， Tachyon应该如何调整R2的优先级呢？所以，咱们须要明确三个目标：

    （1）优先级的配合度。若是一个低优先级的job须要文件，针对该过程的重计算过程应该尽量小地影响更高优先级的job。可是，若是该文件后来被一个更高优先级的job所须要，用于执行数据恢复工做的job的优先级应该提高。 （也就是说文件的恢复job的优先级会随着获取文件的job的优先级来决定）

    （2）资源共享。没有重计算任务，集群就执行正常任务 （不是静态资源分配）。

     （3）避免重计算的串联操做。出错状况发生的时候，同时可能不仅是一个文件会发生丢失，若是不考虑数据的依赖关系就对这些文件进行重计算可能会引发递归的重计算job的产生。

    咱们现提出能够知足前两个目标的策略，再来讨论如何实现最后一个目标。

• Resource Allocation Strategy
  

     资源申请策略依赖于Tachyon所使用的调度方法。

     Priority Based Scheduler

    在优先级的调度器中，举一个相似的例子。 假如一个集群资源被三个job J1，J2，J3占据，三个job各自的优先级是P1，P2，P3。

    方法是，默认状况下全部的重计算job都只有最低的优先级，因此他们对其余的job有最低限度的影响。然而，这样会致使 “优先级反转” ：例如，文件F2的重计算job R2比J2有更低的优先级，此时当J2占用集群中全部的优先级的时候对F2文件进行获取，R2是得不到执行资源的，J2由于得不到F2也会所以被阻塞 。

    咱们经过优先级的继承关系来解决。当J2获取F2的时候， Tachyon增长R2的优先级到P2。当J3获取F2的时候，再将R2的优先级升至P3，以下图所示：

    

     Fair Sharing Based Scheduler

    在共享调度中，J1，J2，J3各自分享W1，W1，W3的资源 （最小的分享单位是1）。

    在咱们的解决方法中，重计算的jobs一块儿共享分配的资源，被 Tachyon分配好的的默认的资源Wr。当错误发生的时候，全部丢失文件的重计算job能够共享到Wr中的“1个资源”。

    此时，当一个job须要上述丢失的文件的时候，请求数据的job的一部分资源会被转移到那些针对这些文件的重计算job上去。好比，当J2须要F2的时候，J2会分到（1-a）*W1的资源，而R2会分到a*W1的资源。以下图所示；

    上述的方法知足了咱们的目标。由于重计算的job的 资源来自须要该缺失文件的job，因此，该过程不会对其余正常的job产生影响。

Recomputation Order

    若是执行重计算的过程当中没有对重计算的操做限定顺序，那么程序递归地对丢失的文件调用重计算操做就会有很低的性能。好比，若是job的优先级很低的话，该job很一直等待资源。若是改job的优先级很高，那么针对一个未来注定丢失的文件的前期计算就显得徒劳无功了。因此工做流管理器提早决定好文件重计算的顺序进而能够对他们进行调度。

     为了决定哪些文件须要进行重计算， 工做流管理器维护了一个DAG图。DAG图中的每个节点表明一个须要进行恢复的文件。在这个DAG图中，存在窄依赖和宽依赖（概念和Spark的一致）。这些依赖关系造成的DAG图是总的DAG图的子图。

    为了构建这样的DAG图，工做管理器会对目标文件进行DFS，若是当前文件节点在存储层可用的时候， DFS过程会中止。DFS访问到的节点必须是须要被重计算的。DAG图中的节点的计算顺序是逆序的，就是说，只有孩子节点都变为可用的时候当前节点才能够开始计算。上述计算过程是资源管理器执行的。

Implementation（实现）

     Tachyon使用已经存在的存储系统来做为本身的持久化层，且 Tachyon还使用 Apache  ZooKeeper来主导master的错误容忍。

• Lineage Metadata
  

    （1）Ordered input files list

    由于文件名可能会发生变化，可是每一个文件在顺序表中都有一个独特的不可变的文件ID，这样就能够保证应用在未来可能会出现重计算的状况，若是发生的话，重计算的时候就能按照程序第一次执行时候的顺序来读取相同的文件进行后续操做。

    （2）Ordered output files list

    该列表与   input files list原理同样。

    （3）Binary program for recomputation

    不少种方法实现一个重计算程序。一种天真的方法是为每个应用写一个有针对性的程序，一个稍微有点素养的程序员都不会这样作的。另外一种方法是写一个相似于“装饰器”的程序，该程序既能“读懂”Tachyon的 “血统”信息，又能理解 应用的逻辑关系。虽然这样的程序貌似很是灵活，可是也只能在一些特殊的框架（兼容这样的“装饰器”）下实现。

    （4） Program configuration

    关于所需的配置文件，Tachyon使用“装饰器”程序读取配置文件：在“血统”提交的时候使用 ”装饰器“对配置文件进行序列化，以后在重计算阶段解序列化。

    （5）Dependency type

    宽依赖和窄依赖。

• Framework Integration（框架整合）
  

    程序运行的过程当中，在它写文件以前会将一些信息提交给 Tachyon，而后，当程序写文件的时候， Tachyon会判断该文件是否在”血统“之中，若是在，该文件就能够被写入内存（说明要采用”血统“机制进行容错处理）。若是文件须要进行重计算， Tachyon会使用以前的”装饰器“程序将文件的”血统“信息以及丢失的文件列表提交给重计算程序来从新生成相关的数据。

• Recomputation Granularity（粒度）
  

    关于重计算的粒度选择问题。首先，咱们能够选择的粒度是job，好比，一个map job产生了10个文件，可是有一个文件丢失了，对于job级别的恢复， Tachyon会恢复10个文件。其次，若是咱们选择的粒度是task，这样，执行过程会变得复杂，可是效率会提高不少。MapReduce和Spark的层级是task级别的。

Evaluation

    基础平台：

     Ama zon EC2 cluster with 10 Gbps Ethernet. Each node had 32  cores, 244GB RAM, and 240GB of SSD. We used Hadoop  (2.3.0) and Spark (0.9).

    （1）Tachyon

    （2） in-memory installation of  Hadoop’s HDFS (over RAMFS), which we dub MemHDFS.  MemHDFS的writes操做的重计算数据的恢复仍旧会借助network，可是没有了disk的性能限制。

    比较结果以下：

   性能：

1. Tachyon的write速度比MemHDFS快100X；
2. 对于 multi-job workflow而言Tachyon的处理速度是MemHDFS的4X；在出错的状况下，大约花费了1分钟的时间进行数据库的恢复。Tachyon要比快3.8X；
3. Tachyon帮助基于内存的框架，经过将虚拟机存储转移至堆外内存（直接受操做系统管理）来改善的延迟；
   
4. Tachyon恢复master的失败仅仅须要不到1秒。
   

    异步检查点的设置：

    Edge算法超过任何固定间隔的检查点设置方法，分析代表 Tachyon能够将数据复制备份引发的网络交互降至50%。

    重计算的影响：

    重计算对其余的job几乎没有影响；另外，经过对Facebook和Bing的跟踪，重计算对集群资源的消耗不会超过1.6%。

    接下来是具体的性能比较过程。

• 性能

    Raw Performance

    实验中，集群中的每个节点会开启32个进程，每个进程读/写1GB的数据。结果以下图：

    

    对于写而言，Tachyon实现了15GB/sec/node的吞吐率。然而，尽管使用的是10Gbps的带宽，MemHDFS的写吞吐率只有0.14GB/sec/node，缘由就是因为须要数据备份带来的网络瓶颈。咱们同时能够看出，理论上在硬件之上采用一次备份的最大的性能也只有 0.5GB/sec/node。平均来看， Tachyon的write速度比 MemHDFS快100X，而理论上以复制为基础的write速度极限是 MemHDFS 的 30X。

    对于读而言，Tachyon实现了38GB/sec/node。咱们经过加入cache缓存以及 short-circuit reads（数据的本地性）的方法优化了HDFS读性能，可是MemHDFS也仅仅实现了17 GB/sec/node的速度。像这样速度上2倍的差距的缘由就是，HDFS API由于调用了java I/O streams 仍然须要额外的内存数据备份。

    另外，Tachyon读的性能要好于写的性能，由于硬件的设计为read留了更多带宽。

    Realistic Workflow

    实验中咱们测试Tachyon的工做流是基于一个媒体信息分析公司在一小时内执行较多job来进行的。包含周期性的提取、转换、加载 （ETL过程：用来描述将数据历来源端通过抽取（extract）、转换（transform）、加载（load）至目的端的过程。 ）过程以及针对job进行测量的相关报告。

    实验运行的环境是拥有30个节点的EC2（ 亚马逊弹性计算云 ）集群上面。整个工做流分为20批次的做业，共包含240个job（其中每一个批次有8个Spark job以及4个MapReduce job）。每批做业读1TB的数据并产生500GB的数据。咱们使用Spark的Grep job来仿真ETL应用，用MapReduce的WordCount来仿真测试分析的应用。且每批次的做业，咱们运行两个Grep应用来提早处理数据，以后咱们运行WordCount做业来读取处理以后的数据并计算最终的结果，获得最终结果以后，数据就会被删掉。

    咱们测量了Tachyon以及MemHDFS上面运行的工做流的端到端的延迟。为了模仿真实的场景，元数据一旦写入系统咱们就开始进行测量。对 Tachyon而言，咱们还测量了一个node失败的时间消耗。

    

    上图展现了相关性能：

    能够看出 Tachyon上的执行时间大约为16.6min，而MemHDFS则用时67min。加速比大约为4倍关系。当 Tachyon上发生失败状况的时候，时间也仅仅多耗费了1min，加速比仍旧有3.8倍。

    对 Tachyon而言，主要的负载是序列化和反序列化（空间开销和时间开销） ，这个实验使用的是  Hadoop TextInputFormat（ 主要用于描述输入数据的格式,功能： 数据切分和 为Mapper提供输入数据 ），若是使用更加高效的序列化模式，性能会有所提高。

    

    Overhead in Single Job（单个job的负载）

    当咱们运行一个单独的job的时候，能够发现Tachyon能带来更小的负载而且能够经过减小没用的负载来改善内存框架的性能。咱们使用Spark的一个worker节点（不要Tachyon）来运行Word Count job，经过两种方式进行缓存，一种是解序列化的java对象，一种是序列化的字节数组。相比较使用Tachyon进行缓存，当数据量小的时候，二者是相似的。当数据量变大的时候， Tachyon 更快，由于Tachyon避免了使用java的内存管理机制。Spark1.0.0已经将Tachyon做为默认的堆外存储方法。

    Master Fault Tolerance

     Tachyon使用 热门线路备份（以前的等待master节点）来实现更快的master节点恢复。时延发现热门线路备份能够在0.5s以内取代当前出错的master节点，且在标准偏差0.1s以内。上述实现的性能是可能的，由于取代的过程是备用master不断 经过当前master的日志文件数据来 获取更新本身的数据信息。

• Asynchronous Checkpointing（异步检查点的设置）
  

    Edge Checkpointing Algorithm

    咱们经过比较Edge算法和固定时间间隔的检查点设置的算法来最终对Edge算法进行评估。 咱们用100个jobs模拟一个迭代的工做流，整个过程的执行时间听从高斯分布 （正态分布 ）， 平均来看 每一个job用时为10s。

     每一个job的数据输出过程（write）都须要固定的15s的总时间来进行检查点的设置。操做过程当中，任意时刻node均可能出错。

    

    从上图能够看出，Edge算法优于固定时间间隔的算法。对固定时间间隔的策略而言，若是时间间隔设置的过小，检查点的设置就跟不上程序执行速度。若是时间间隔设置太大，检查点的设置间隔时间就会很长，数据恢复时间就会受到影响。而且，即便采用最优的固定时间间隔方法，性能也比不上 Edge算法，由于 Edge算法能够根据程序执行的过程以及状态进行检查点设置的时间间隔的调整。

    Network Traffic Reduction

    那些采用数据复制进行容错的文件系统在数据密集型的集群中几乎占用了一半的网络通讯。Tachyon能够减小通讯的消耗，缘由是Tachyon在异步的检查点设置的过程当中能够避免对那些会被删除的临时文件进行检查点的设置。带宽节省下来了，性能天然会提高。

    分析以下：

    （1 ）T表示 job执行的时间 与 对job输出的数据进行检查点设置的时间 （网络带宽） 的比例。好比，测试一个Spark Grep程序，获得T=4.5，说明job运行的速度是网络带宽的4.5倍。其实，T值的大小主要取决于网络带宽或者说是I/O。

    （2）X表示生成数据的job的百分比。

    （3）Y表示读取前面job的输出数据（组建“血统”）的job的百分比，若是Y=100，则会造成一个“血统”链，若是Y是0，则“血统”的深度就是1。

    所以，咱们尝试着将X置为60，将Y置为84，并使用Edge算法 来模拟1000个jobs的执行过程。取决于T，经过复制备份操做以后保存下来的网络通讯的百分比的状况：当T=4是40%，当T>=10的时候是50%。（也就是说，X和Y固定的状况下，检查点设置操做的带框越小，T越大，表示网络通讯越快 ----Tachyon）

•  Recomputation Impact
  

    Recomputation Resource Consumption（消耗）

    咱们会经过计算模型以及对FaceBook和Bing的追踪来计算重计算过程所需的资源。

    咱们的分析创建在下面的假设之上：

    （1）每一个机器的平均失效时间是3年。且若是一个集群包含1000个节点，平均天天会有一个节点出现失败的状况。

    （2）能够负担的检查点设置的吞吐率是200MB/s/node。

    （3）资源消耗用机器时间（machine-hours ）来测量。

    （4）分析的过程当中，认为Tachyon仅仅在job级别，使用粗粒度的重计算在最差的状况下进行测试（不用支持细粒度的task级别的重计算）

     Worst-case analysis

    最坏的状况下，一个节点出错，且其内存中的数据都是没有设置检查点的，须要task用超过200MB/sec的速度进行数据的再生。若是一个机器拥有128GB的内存，那么须要655秒的时间重计算丢失的数据。即便数据是连续存放的，其余的机器在这个过程都是阻塞的，由于这些机器都是须要依据这些数据进行并行计算的。在上述状况下，重计算过程占用了集群运行时间的0.7%。

    上述的开销是与集群的大小和内存的大下呈线性关系的，若是集群有5000个节点，每一个节点有1TB的内存，重计算的开销能够达到集群资源的30%。

    Real traces

    现实的工做流程中，Tachyon的重计算的开销要远远小于上述最差的状况，由于job之间是独立的，几乎不会影响整个集群，所以一个节点失败不会阻塞其余的节点。

    

    上图根据对FaceBook和Bing的追踪来比较不一样内存和不一样节点数的集群资源占用状况，能够看出正常状况下Tachyon的性能 。

Related Work

• Distributed Storage Systems

    在大数据分析中，分布式文件系统以及key/value存储系统都是经过将数据复制到不一样的节点进行容错处理的。这些系统write的吞吐率是受到网络带宽的限制的。无论这些系统如何优化，他们的吞吐率与内存的吞吐率相比都查的很远。Tachyon在存储层使用“血统”的概念来避开复制备份的操做，且利用内存进行单一的存储来提高性能。 Apache HDFS社区考虑将“血统”引入系统中，此灵感也是来自于Tachyon。

     【补充】 Batch-Aware Distributed File System（BAD-FS），该类型的系统有两部分组成：

    （1） storage层expose了诸如caching、consistency、replication等一般固定的控制策略；

     （2）scheduler层使用这些控制来适应不一样的工做流，这样可以针对特定的工做流来处理例如cache consistency、fault tolerance、space management等问题，使存储和计算协调一致。

     BAD-FS将传统文件系统的各类控制从File system转到了scheduler。这样的好处是：提升性能；优化错误处理；简化实现。

     [ BAD-FS]为存储过程单独提供了一个调度器，提供额外的控制做用。用户经过说明式的语言将jobs提交给调度器，系统也所以知道了jobs之间的“血统”关系。然而，为了让上述过程在并行大数据引擎上面成为现实，有两个基本的问题：

    （1）确保调度器和存储层之间的交互是正确的，好比避免 死锁或者是 优先级反转状况的出现。

    （2）限制重计算的时间

    对于第一个问题 （对应论文开始的资源申请的挑战），咱们会提供避免死锁或者是优先级反转的机制，同时也会考虑到调度器的策略。对于第二个问题 （对应论文开始的限制重计算时间的挑战），咱们会提供异步的检查点设置算法，该算法利用“血统图”在后台不停地执行检查点设置来确保优先的恢复时间。

• Cluster Computation Frameworks
  

    Spark在一个单独job的执行过程当中使用“血统”信息，且运行在一个单独的JVM里面。Spark中不一样的不一样种类的查询没法用一个稳定且高吞吐率的方法来共享数据集（RDD），由于Spark是一个计算框架，而不是一个存储系统。咱们经过将Tachyon与Spark进行集成，经过 进行稳定的数据集共享 充分改善了Spark jobs的工做流程处理性能 。而且，Spark在Tachyon的异步检查点设置的过程当中也会受益，由于它实现了高吞吐率的write过程。

    其余的系统好比MapReduce和Dryad（微软的分布式运算框架）也会在一个job的执行过程当中跟踪task的“血统”信息。可是这些系统不像Spark能够整合Tachyon，他们没法跟踪文件之间的关系，也所以没法在不一样的job之间提供高吞吐率的数据共享。

• Caching Systems 
  

     【补充】DryadLINQ 是一个把LINQ 程序（ LINQ即Language Integrated Query(语言集成查询)，LINQ是集成到C#和Visual Basic.NET这些语言中用于提供查询数据能力的一个新特性 ）转化成分布式计算指令，以便运行于PC集群的编译器。

     [ Nectar] 相似Tachyon， Nectar也会使用“血统”的概念，可是， Nectar仅仅服务于特定的程序框架 DryadLINQ，而且整合于传统的，复制的文件系统中。 Nectar是一个数据复用系统，服务于 DryadLINQ查询操做，目标是节省空间且避免多余计算。

    （1） 节省空间：删除大量无用文件，若是须要再次使用，就会从新运行产生这些文件的job。可是数据的恢复过程是没有时间限制的。

    （2） 避免多余计算：标示不一样程序里面比较广泛的代码块进而找到那些通过相同计算获得的文件，加以重复利用。做为对比， Tachyon的目标是经过不一样的基于内存的以及有限的数据恢复时间的框架来提供数据共享。

    [ PACMan]是一个基于内存的缓存系统，适用于数据密集型的并行工做。该系统探索了不一样的策略，目的是让数据仓库的缓存效率更加高效。然而，PACMan没有改善write的性能，也没有改善第一次read的性能。

• Lineage
  

    除了上述领域，“血统”已经被应用在不少其余的领域当中了，好比科学计算、数据库、分布式计算等等，也被应用在提供历史数据的应用中。Tachyon在不一样的环境下使用“血统”来实现内存速度的读写吞吐率。

• Checkpoint Research
  

    检查点的设置已经成为了一个很值得的研究领域。大多数的研究是在当失败状况发生的时候如何将从新计算的开销最小化。可是，不像以前 使用同步的检查点设置 的那些work操做， Tachyon会在后台进行异步的检查点设置，这样的话就算一个检查点设置操做没有完成，也能够经过“血统”来进行丢失数据的重计算。

Limitations and Future Work

     Tachyon致力于改善其目标工做多负载的性能，且评估也展现出了使人欣喜的结果。可是咱们也从中意识到了 Tachyon的局限性，好比CPU密集型或者是网络密集型的jobs的处理。另外，还有一些未来要面临的挑战：

    （1）Random Access Abstractions（随机访问抽象）

     运行jobs的数据密集型的应用会向 像 Tachyon这样的 存储系统输出文件。一般，这些文件会被DBMS进行再加工来让面向用户的应用使用这些数据。所以，Tachyon提供高层次的只读随机访问抽象，好比在已有的文件之上提供key/value接口，能够缩短数据管道而且让数据密集型的jobs输出的数据当即变为可用的数据。

    （2）Mutable data（可变的数据）

    “血统”通常没法进行高效率的细粒度的随机访问更新也是挑战之一。可是针对这个问题有不少的方向，好比定向更新一集批量更新。

    （3）Multi-tenancy（多重租赁 ）

    对于Tachyon而言，内存公平共享是重要的研究方向。像LRU/LFU这些策略能够提供好的总体性能，可是要以对每个用户进行隔离操做为代价。另外，安全也是处理过程的另一个有趣的问题。

    （4）Hierarchical（分等级） storage

    虽然内存的容量每一年都是以置数形式增加的，可是相对于内存的替代品而言仍是很昂贵的。一个早期的Tachyon研究者表示，除了要使用内存这一层级， Tachyon也应该使用NVRAM（  非易失随机存取存储器 ）和SSDs。未来，咱们将会研究如何在 Tachyon中支持层级存储。

    （5）Checkpoint Algorithm Optimizations

    咱们已经提出了Edge算法来提供一个受限的重计算时间。然而，也会有其余的技术考虑到不一样的度量标准，好比检查点设置开销，单个文件恢复开销，多有文件恢复开销等。咱们将这些改进留给社区来进一步探索。

Conclusion

    随着以数据为中心的工做负载开始存在于内存，write的吞吐率就成为了应用的主要瓶颈。所以，咱们认为以“血统”为基础的数据恢复的方法或许是惟一实现集群储存系统 加速 内存吞吐率的方法。咱们提出了 Tachyon，一个基于内存的存储系统，该系统引进了“血统”来加速由决定性的批量jobs组成的工做负载的关键部分的处理。在让Tachyon有实际用途的过程当中，咱们定位并解决了一些关键的挑战。咱们的评估展现了Tachyon在目前的存储方案上提供了可靠的加速。类似的方法也被HDFS社区采纳以便在集群中高效地利用内存。Tachyon目前已经开源。