前言
本文隶属于专栏《1000个问题搞定大数据技术体系》,该专栏为笔者原创,引用请注明来源,不足和错误之处请在评论区帮忙指出,谢谢!
本专栏目录结构和参考文献请见1000个问题搞定大数据技术体系
目录
思维导图
正文
8、相关工作
集群编程模型
集群编程模型的相关工作分为以下几类:
- 第一,像 MapReduce,Dryad 以及 Ciel 一样支持一系列处理数据的操作,并且需要通过稳定的存储系统来共享数据,RDDs 表达了一种比稳定存储系统更高效的数据共享抽象,因为它避免了数据备份、 I / O 以及序列化的成本。
- 第二,几个针对数据流系统的高层级的编程接口,包括 DryadLINQ 和 FlumeJava ,它们提供了语言集成 api,使的用户可以通过像 map 和 join 等操作来操作并行的集合。然而,在这些系统中,并行的集合是指在磁盘上的文件或者一个查询计划表达的临时数据集。虽然这些系统在相同的查询中的操作之间组装数据的 pipeline(比如,一个 map 操作后跟另外一个 map),但是它们不能在查询之间进行高效的数据共享。我们在并行集合模式上建立 spark api,是由于它的便利性以及在集成语言接口上不要求新颖性,但是我们基于在这些接口背后以 RDDs 作为存储抽象,就可以使的 spark 支持大量类型的应用了。
- 第三,系统为许多专门的需要数据共享的应用提供了高层的接口。比如,Pregel 支持迭代式的图计算应用、 Twister 和 HaLoop 支持迭代式的 MapReduce。然而,这些框架只是为他们支持的计算模型隐式的共享数据,并没有提供可以让用户根据自己的需求显式的共享数据的通用抽象。比如,一个用户不能用 Pregel 或者 Twister 将数据加载到内存中然后决定在数据集上面跑什么样的查询。RDDs 提供了一个显式的分布式存储抽象,因此可以支持那些特殊系统不能支持的应用,比如交互式数据挖掘。
- 最后,一些系统暴露共享可变状态以使的用户可以执行内存计算。比如,Piccolo 使的用户通过分布式的函数来读取和更新分布式 hash 表中的单元格数据。DSM 和像 RAMCloud 这样的 key - value 存储系统提供了类似的模型。RDDs 和这些系统有两个方面的不同,第一,RDDs 基于像 map,sort 以及 join 等操作提供了高层的编程接口,然而,在 Piccolo 和 DSM 中的接口只是读取和更新表的单元格数据。第二,Piccolo 和 DSM 通过 checkpoint 和回滚机制实现容错,在许多应用中这种机制比基于血缘机制 RDDs 的容错的成本更大。最后,如 2.3 小节讨论的,相对于 DSM,RDDs 还提供了其他的优势功能,比如执行慢的 task 的处理机制。
缓存系统
Nectar 可以通过标识通用的程序分析的子表达式来达到在 DryadLINQ 任务之间对中间数据结果的复用。
这种能力肯定会加入到基于 RDD 的系统中。
然而,Nectar 即没有提供基于内存的缓存(他是将数据放到分布式文件系统中)也不能让用户可以显式的对数据集进行缓存控制和分区控制。
Ciel 和 FlumeJava 同样可以缓存任务结果,但是也不提供基于内存的缓存或者显式的控制哪些数据可以缓存。
Ananthanarayanan et al. 已经提出在分布式文件系统上加一层基于内存的缓存来利用数据访问的暂时性和本地性。
这种解决方案却是加快了已经存在于文件系统中的数据访问速度,但是它在共享同一个应用中的中间结果方面并没有 RDD 高效,因为它在每一个 stage 之间仍然需要将数据写入到文件系统中
血缘
在科学计算以及数据库中,捕获数据的血缘或者来源信息是一个很长时间被研究的话题了,对于像解释结果的应用,需要让他们可以从其他的应用重新产生,且当在工作流中存在一个 bug 或者数据丢失的时候可以重新对数据进行计算。
对于这边面的容错的工作,我们推荐读者看下面的资料。
R. Bose and J. Frew. Lineage retrieval for scientific data processing: a survey. ACM Computing Surveys, 37:1–28, 2005.
J. Cheney, L. Chiticariu, and W.-C. Tan. Provenance in databases: Why, how, and where. Foundations and Trends in Databases, 1(4):379–474, 2009.
RDDs 提供了一种并行编程模型,记录跟踪细粒度的血缘的成本很低,我们可以根据血缘来达到容错的目的。
我们基于血缘的容错机制和 MapReduce 以及 Dryad 一个任务中的容错机制是类似的,在 DAG 中跟踪任务的依赖。
然而,在这些系统中,一个任务结束后血缘信息也就丢失了,用户需要依靠数据备份式的存储系统来共享任务之间的数据。
与此相反,RDDs 可以在任务之间通过将数据存储在内存中达到高效的数据共享,并不需要数据的备份和磁盘 I/O 消耗。
关系型数据库
RDDs 在概念上和数据库中的视图比较类似,存储的 RDDs 则像具体的视图。
然而,像 DSM 系统,数据库一般允许细粒度的对所有的数据进行读写访问,这种方式需要对操作和数据进行记录日志,用于容错,以及需要额外的开销来保持数据的一致性,对于粗粒度转换模型的 RDDs 来说,这些额外的开销式不需要的。
解析
Ciel
Ciel 是一种用于分布式数据流程序的通用执行引擎。
和其他的分布式计算引擎一样,Ciel 掩盖了分布式编程的复杂性。
与那些系统不同的地方在于,Ciel 作业可以做出与数据相关的控制流决策,这使它能够计算迭代和递归算法。
FlumeJava
MapReduce和类似系统大大简化了编写数据并行代码的任务。
然而,许多现实世界的计算需要流式线式的MapReduces,编程和管理此类流水线可能很困难。
FlumeJava 是一个Java库,可以轻松开发、测试和运行高效的数据并行流水线。
FlumeJava 库的核心是代表不可变并行集合的几个类,每个类都支持少量并行处理它们的操作。
并行集合及其操作对不同的数据表示和执行策略进行了简单、高级、统一的抽象。
为了使并行操作高效运行,FlumeJava推迟了它们的评估,而是在内部构建了执行计划数据流图。
当最终需要并行操作的最终结果时,FlumeJava首先优化执行计划,然后在适当的底层原语(例如MapReduces)上执行优化操作。
并行数据和计算的高级抽象、延迟评估和优化以及高效的并行原语相结合,产生了一个易于使用的系统,接近手动优化管道的效率。
FlumeJava 正被谷歌内部数百名开发人员积极使用。
Twister
Twister是一个增强的MapReduce runtime,具有扩展的编程模型,高效地支持迭代MapReduce计算。
它使用publish/subscribe消息传递基础设施进行通信和数据传输,支持长时间的map/reduce任务,这些任务可以以“配置一次使用多次”的方法使用。
另外,它还可以通过“广播”和“分散”类型的数据传输为MapReduce提供编程扩展。
相比较其它MapReduce runtimes,这些改进允许Twister支持高效的MapReduce计算。
Piccolo
Piccolo 是 New York 大学在 OSDI 2000上发表的 paper 《Piccolo: Building Fast, Distributed Programs with Partitioned Tables》提出来的一个新的分布式计算编程模型,Piccolo 允许计算单元跑在不同的机器上,更重要的是它对计算过程中的共享状态数据的访问有很好的本地性,同时解决了在运行时写数据的冲突等问题。
它和 MapReduce 的区别在于能够轻松访问中间状态(其实就是中间结果,之后都采用中间结果的说法),由于 MapReduce 需要把中间结果保存到 HDFS,开销比较大,所以对需要频繁访问中间结果的运算效率不高,而 Piccolo 把中间结果保存在内存中,Piccolo 中叫做 in-memory table,Piccolo 对 in-memory table 抽象出 key-value 简单的操作接口,方便操作。
RAMCloud
RAMCloud 是一个完全使用DRAM的存储系统,它的所有数据都保存到内存中。
当然了为了故障恢复RAMCloud会将日志和数据的备份持久化到普通硬盘中。
Nectar
管理数据和计算是数据中心计算的核心。
手动管理数据会导致数据丢失、浪费存储空间和繁琐的记录。
缺乏适当的计算管理可能会导致失去跨多个作业共享通用计算或增量计算结果的机会。
Nectar 是一个旨在解决所有上述问题的系统。
Nectar 使用一种新颖的方法来自动化和统一数据中心的数据和计算管理。
使用 Nectar,计算结果(称为派生数据集)由计算它的程序唯一标识,并与程序一起由数据中心范围的缓存服务自动管理。
派生数据集的所有计算和使用均由系统控制。
如果确定丢失,系统会自动从其程序中重新生成派生数据集。
Nectar 极大地改善了数据中心的管理和资源利用:过时或不经常使用的派生数据集被自动垃圾收集,共享的公共计算只计算一次并被其他人重用。
9、结尾
我们已经展示了在集群应用中一个高效的,通用的以及容错的对共享数据的抽象的 RDDs。
RDDs 可以表达大量的并行应用,包括特殊的编程模型提出的迭代式计算以及这些模型表达不了的新的应用。
和已经存在的对集群存储抽象不同的是,RDDs 提供了基于粗粒度转换的 api,可以使的用户通过血缘达到高效的容错。
我们在 Spark 系统中实现了 RDDs,在迭代式的应用中,性能是 hadoop 的 20 倍,并且可以用于交互式的查询数百 GB 的数据。
我们已经在 spark-project.org 中开源了 Spark,作为一个稳定的数据分析和系统研究的手段。
Spark 官网:https://spark.apache.org