关于hadoop的论文文献

分布式系统在互联网时代，尤其是大数据时代到来之后，成为了每个程序员的必备技能之一。分布式系统从上个世纪80年代就开始有了不少出色的研究和论文，我在这里只列举最近15年范围以内我觉得有重大影响意义的15篇论文（15 within 15）。1. The Google File System: 这是分布式文件系统领域划时代意义的论文，文中的多副本机制、控制流与数据流隔离和追加写模式等概念几乎成为了分布式文件系统领域的标准，其影响之深远通过其5000+的引用就可见一斑了，Apache Hadoop鼎鼎大名的HDFS就是GFS的模仿之作；2. MapReduce: Simplified Data Processing on Large Clusters：这篇也是Google的大作，通过Map和Reduce两个操作，大大简化了分布式计算的复杂度，使得任何需要的程序员都可以编写分布式计算程序，其中使用到的技术值得我们好好学习：简约而不简单！Hadoop也根据这篇论文做了一个开源的MapReduce；3. Bigtable: A Distributed Storage System for Structured Data：Google在NoSQL领域的分布式表格系统，LSM树的最好使用范例，广泛使用到了网页索引存储、YouTube数据管理等业务，Hadoop对应的开源系统叫HBase（我在前公司任职时也开发过一个相应的系统叫BladeCube，性能较HBase有数倍提升）；4. The Chubby lock service for loosely-coupled distributed systems：Google的分布式锁服务，基于Paxos协议，这篇文章相比于前三篇可能知道的人就少了，但是其对应的开源系统zookeeper几乎是每个后端同学都接触过，其影响力其实不亚于前三篇；5. Finding a Needle in Haystack: Facebook's Photo Storage：facebook的在线图片存储系统，目前来看是对小文件存储的最好解决方案之一，facebook目前通过该系统存储了超过300PB的数据，一个师兄就在这个团队工作，听过很多有意思的事情（我在前公司的时候开发过一个类似的系统pallas，不仅支持副本，还支持Reed Solomon-LRC，性能也有较多优化）；6. Windows Azure Storage: a highly available cloud storage service with strong consistency：windows azure的总体介绍文章，是一篇很好的描述云存储架构的论文，其中通过分层来同时保证可用性和一致性的思路在现实工作中也给了我很多启发；7. GraphLab: A New Framework for Parallel Machine Learning：CMU基于图计算的分布式机器学习框架，目前已经成立了专门的商业公司，在分布式机器学习上很有两把刷子，其单机版的GraphChi在百万维度的矩阵分解都只需要2~3分钟；8. Resilient Distributed Datasets: A Fault-Tolerant Abstraction forIn-Memory Cluster Computing：其实就是 Spark，目前这两年最流行的内存计算模式，通过RDD和lineage大大简化了分布式计算框架，通常几行scala代码就可以搞定原来上千行MapReduce代码才能搞定的问题，大有取代MapReduce的趋势；9. Scaling Distributed Machine Learning with the Parameter Server：百度少帅李沐大作，目前大规模分布式学习各家公司主要都是使用ps，ps具备良好的可扩展性，使得大数据时代的大规模分布式学习成为可能，包括Google的深度学习模型也是通过ps训练实现，是目前最流行的分布式学习框架，豆瓣的开源系统paracell也是ps的一个实现；10. Dremel: Interactive Analysis of Web-Scale Datasets：Google的大规模（近）实时数据分析系统，号称可以在3秒相应1PB数据的分析请求，内部使用到了查询树来优化分析速度，其开源实现为Drill，在工业界对实时数据分析也是比价有影响力；11. Pregel: a system for large-scale graph processing: Google的大规模图计算系统，相当长一段时间是Google PageRank的主要计算系统，对开源的影响也很大（包括GraphLab和GraphChi）；12. Spanner: Google's Globally-Distributed Database：这是第一个全球意义上的分布式数据库，Google的出品。其中介绍了很多一致性方面的设计考虑，简单起见，还采用了GPS和原子钟确保时间最大误差在20ns以内，保证了事务的时间序，同样在分布式系统方面具有很强的借鉴意义；13. Dynamo: Amazon’s Highly Available Key-value Store：Amazon的分布式NoSQL数据库，意义相当于BigTable对于Google，于BigTable不同的是，Dynamo保证CAP中的AP，C通过vector clock做弱保证，对应的开源系统为Cassandra；14. S4: Distributed Stream Computing Platform：Yahoo出品的流式计算系统，目前最流行的两大流式计算系统之一（另一个是storm），Yahoo的主要广告计算平台；15. Storm @Twitter：这个系统不多说，开启了流式计算的新纪元，几乎是所有公司流式计算的首选，绝对值得关注；

1. 概述1970年，IBM的研究员博士在刊物《Communication of the ACM》上发表了一篇名为“A Relational Model of Data for Large Shared Data Banks”的论文，提出了关系模型的概念，标志着关系数据库的诞生，随后几十年，关系数据库及其结构化查询语言SQL成为程序员必须掌握的基本技能之一。2005年4月，Jeffrey Dean和Sanjay Ghemawat在国际会议OSDI上发表“MapReduce: Simplified Data Processing on Large Cluster”，标志着google的大规模数据处理系统MapReduce公开。受这篇论文的启发，当年秋天，Hadoop 由 Apache Software Foundation 公司作为 Lucene 的子项目 Nutch 的一部分正式被引入，2006 年 3 月份，MapReduce 和 Nutch Distributed File System (NDFS) 分别被纳入称为 Hadoop 的项目中。如今，Hadoop已经被超过50%的互联网公司使用，其他很多公司正准备使用Hadoop来处理海量数据，随着Hadoop越来越受欢迎，也许在将来的某段时间，Hadoop会成为程序员必须掌握的技能之一，如果真是这样的话，学会如何在Hadoop上编写MapReduce程序便是学习Hadoop的开始。本文介绍了在Hadoop上编写MapReduce程序的基本方法，包括MapReduce程序的构成，不同语言开发MapReduce的方法等。2. Hadoop 作业构成 Hadoop作业执行流程用户配置并将一个Hadoop作业提到Hadoop框架中，Hadoop框架会把这个作业分解成一系列map tasks 和reduce tasks。Hadoop框架负责task分发和执行，结果收集和作业进度监控。下图给出了一个作业从开始执行到结束所经历的阶段和每个阶段被谁控制（用户 or Hadoop框架）。下图详细给出了用户编写MapRedue作业时需要进行那些工作以及Hadoop框架自动完成的工作：在编写MapReduce程序时，用户分别通过InputFormat和OutputFormat指定输入和输出格式，并定义Mapper和Reducer指定map阶段和reduce阶段的要做的工作。在Mapper或者Reducer中，用户只需指定一对key/value的处理逻辑，Hadoop框架会自动顺序迭代解析所有key/value，并将每对key/value交给Mapper或者Reducer处理。表面上看来，Hadoop限定数据格式必须为key/value形式，过于简单，很难解决复杂问题，实际上，可以通过组合的方法使key或者value（比如在key或者value中保存多个字段，每个字段用分隔符分开，或者value是个序列化后的对象，在Mapper中使用时，将其反序列化等）保存多重信息，以解决输入格式较复杂的应用。 用户的工作用户编写MapReduce需要实现的类或者方法有：（1） InputFormat接口用户需要实现该接口以指定输入文件的内容格式。该接口有两个方法1234567891011public interface InputFormat {InputSplit[] getSplits(JobConf job, int numSplits) throws IOException;RecordReader getRecordReader(InputSplit split,JobConf job,Reporter reporter) throws IOException;}其中getSplits函数将所有输入数据分成numSplits个split，每个split交给一个map task处理。getRecordReader函数提供一个用户解析split的迭代器对象，它将split中的每个record解析成key/value对。Hadoop本身提供了一些InputFormat：（2）Mapper接口用户需继承Mapper接口实现自己的Mapper，Mapper中必须实现的函数是123456789void map(K1 key,V1 value,OutputCollector output,Reporter reporter) throws IOException其中，是通过Inputformat中的RecordReader对象解析处理 的，OutputCollector获取map()的输出结果，Reporter保存了当前task处理进度。Hadoop本身提供了一些Mapper供用户使用：（3）Partitioner接口用户需继承该接口实现自己的Partitioner以指定map task产生的key/value对交给哪个reduce task处理，好的Partitioner能让每个reduce task处理的数据相近，从而达到负载均衡。Partitioner中需实现的函数是getPartition( K2 key, V2 value, int numPartitions)该函数返回对应的reduce task ID。用户如果不提供Partitioner，Hadoop会使用默认的（实际上是个hash函数）。（4）CombinerCombiner使得map task与reduce task之间的数据传输量大大减小，可明显提高性能。大多数情况下，Combiner与Reducer相同。（5）Reducer接口用户需继承Reducer接口实现自己的Reducer，Reducer中必须实现的函数是123456789void reduce(K2 key,Iterator values,OutputCollector output,Reporter reporter) throws IOExceptionHadoop本身提供了一些Reducer供用户使用：（6）OutputFormat用户通过OutputFormat指定输出文件的内容格式，不过它没有split。每个reduce task将其数据写入自己的文件，文件名为part-nnnnn，其中nnnnn为reduce task的ID。Hadoop本身提供了几个OutputFormat:3. 分布式缓存Haoop中自带了一个分布式缓存，即DistributedCache对象，方便map task之间或者reduce task之间共享一些信息，比如某些实际应用中，所有map task要读取同一个配置文件或者字典，则可将该配置文件或者字典放到分布式缓存中。4. 多语言编写MapReduce作业Hadoop采用java编写，因而Hadoop天生支持java语言编写作业，但在实际应用中，有时候，因要用到非java的第三方库或者其他原因，要采用C/C++或者其他语言编写MapReduce作业，这时候可能要用到Hadoop提供的一些工具。如果你要用C/C++编写MpaReduce作业，可使用的工具有Hadoop Streaming或者Hadoop Pipes。如果你要用Python编写MapReduce作业，可以使用Hadoop Streaming或者Pydoop。如果你要使用其他语言，如shell，php，ruby等，可使用Hadoop Streaming。关于Hadoop Streaming编程，可参见我的这篇博文：《Hadoop Streaming编程》（ ）关于Pydoop编程，可参见其官方网站：关于Hadoop pipes编程，可参见《Hadoop Tutorial — Running C++ Programs on Hadoop》。5. 编程方式比较（1）java。 Hadoop支持的最好最全面的语言，而且提供了很多工具方便程序员开发。（2）Hadoop Streaming。 它最大的优点是支持多种语言，但效率较低，reduce task需等到map 阶段完成后才能启动；它不支持用户自定义InputFormat，如果用户想指定输入文件格式，可使用java语言编写或者在命令行中指定分隔符；它采用标准输入输出让C/C++与java通信，因而只支持text数据格式。（3）Hadoop Pipes。 专门为C/C++语言设计，由于其采用了socket方式让C/C++与java通信，因而其效率较低（其优势在于，但作业需要大量，速度很快）。它支持用户（用C/C++）编写RecordReader。（4）Pydoop。它是专门方便python程序员编写MapReduce作业设计的，其底层使用了Hadoop Streaming接口和libhdfs库。6. 总结Hadoop使得分布式程序的编写变得异常简单，很多情况下，用户只需写map()和reduce()两个函数即可（InputFormat，Outputformat可用系统缺省的）。正是由于Hadoop编程的简单性，越来越多的公司或者研究单位开始使用Hadoop。

越来越多的企业开始使用Hadoop来对大数据进行处理分析，但Hadoop集群的整体性能却取决于CPU、内存、网络以及存储之间的性能平衡。而在这篇文章中，我们将探讨如何为Hadoop集群构建高性能网络，这是对大数据进行处理分析的关键所在。关于Hadoop“大数据”是松散的数据集合，海量数据的不断增长迫使企业需要通过一种新的方式去管理。大数据是结构化或非结构化的多种数据类型的大集合。而 Hadoop则是Apache发布的软件架构，用以分析PB级的非结构化数据，并将其转换成其他应用程序可管理处理的形式。Hadoop使得对大数据处理成为可能，并能够帮助企业可从客户数据之中发掘新的商机。如果能够进行实时处理或者接近实时处理，那么其将为许多行业的用户提供强大的优势。Hadoop是基于谷歌的MapReduce和分布式文件系统原理而专门设计的，其可在通用的网络和服务器硬件上进行部署，并使之成为计算集群。Hadoop模型Hadoop的工作原理是将一个非常大的数据集切割成一个较小的单元，以能够被查询处理。同一个节点的计算资源用于并行查询处理。当任务处理结束后，其处理结果将被汇总并向用户报告，或者通过业务分析应用程序处理以进行进一步分析或仪表盘显示。为了最大限度地减少处理时间，在此并行架构中，Hadoop“moves jobs to data”，而非像传统模式那样“moving data to jobs”。这就意味着，一旦数据存储在分布式系统之中，在实时搜索、查询或数据挖掘等操作时，如访问本地数据，在数据处理过程中，各节点之间将只有一个本地查询结果，这样可降低运营开支。Hadoop的最大特点在于其内置的并行处理和线性扩展能力，提供对大型数据集查询并生成结果。在结构上，Hadoop主要有两个部分：Hadoop分布式文件系统(HDFS)将数据文件切割成数据块，并将其存储在多个节点之内，以提供容错性和高性能。除了大量的多个节点的聚合I/O，性能通常取决于数据块的大小——如128MB。而传统的Linux系统下的较为典型的数据块大小可能是4KB。MapReduce引擎通过JobTracker节点接受来自客户端的分析工作，采用“分而治之”的方式来将一个较大的任务分解成多个较小的任务，然后分配给各个TaskTrack节点，并采用主站/从站的分布方式(具体如下图所示)：Hadoop系统有三个主要的功能节点：客户机、主机和从机。客户机将数据文件注入到系统之中，从系统中检索结果，以及通过系统的主机节点提交分析工作等。主机节点有两个基本作用：管理分布式文件系统中各节点以及从机节点的数据存储，以及管理Map/Reduce从机节点的任务跟踪分配和任务处理。数据存储和分析处理的实际性能取决于运行数据节点和任务跟踪器的从机节点性能，而这些从机节点则由各自的主机节点负责沟通和控制。从节点通常有多个数据块，并在作业期间被分配处理多个任务。部署实施Hadoop各个节点硬件的主要要求是市县计算、内存、网络以及存储等四个资源的平衡。目前常用的并被誉为“最佳”的解决方案是采用相对较低成本的旧有硬件，部署足够多的服务器以应对任何可能的故障，并部署一个完整机架的系统。Hadoop模式要求服务器与SAN或者NAS进行直接连接存储(DAS)。采用DAS主要有三个原因，在标准化配置的集群中，节点的缩放数以千计，随着存储系统的成本、低延迟性以及存储容量需求不断提高，简单配置和部署个主要的考虑因素。随着极具成本效益的1TB磁盘的普及，可使大型集群的TB级数据存储在DAS之上。这解决了传统方法利用SAN进行部署极其昂贵的困境，如此多的存储将使得Hadoop和数据存储出现一个令人望而却步的起始成本。有相当大一部分用户的Hadoop部署构建都是采用大容量的DAS服务器，其中数据节点大约1-2TB，名称控制节点大约在1-5TB之间，具体如下图所示：对于大多数的Hadoop部署来说，基础设施的其他影响因素可能还取决于配件，如服务器内置的千兆以太网卡或千兆以太网交换机。上一代的CPU和内存等硬件的选择，可根据符合成本模型的需求，采用匹配数据传输速率要求的千兆以太网接口来构建低成本的解决方案。采用万兆以太网来部署Hadoop也是相当不错的选择。万兆以太网对Hadoop集群的作用千兆以太网的性能是制约Hadoop系统整体性能的一个主要因素。使用较大的数据块大小，例如，如果一个节点发生故障(甚至更糟，整个机架宕机)，那么整个集群就需要对TB级的数据进行恢复，这就有可能会超过千兆以太网所能提供的网络带宽，进而使得整个集群性能下降。在拥有成千上万个节点的大型集群中，当运行某些需要数据节点之间需要进行中间结果再分配的工作负载时，在系统正常运行过程中，某个千兆以太网设备可能会遭遇网络拥堵。每一个Hadoop数据节点的目标都必须实现CPU、内存、存储和网络资源的平衡。如果四者之中的任意一个性能相对较差的话，那么系统的潜在处理能力都有可能遭遇瓶颈。添加更多的CPU和内存组建，将影响存储和网络的平衡，如何使Hadoop集群节点在处理数据时更有效率，减少结果，并在Hadoop集群内添加更多的HDFS存储节点。幸运的是，影响CPU和内存发展的摩尔定律，同样也正影响着存储技术(TB级容量的磁盘)和以太网技术(从千兆向万兆甚至更高)的发展。预先升级系统组件(如多核处理器、每节点5-20TB容量的磁盘，64-128GB内存)，万兆以太网卡和交换机等网络组件是重新平衡资源最合理的选择。万兆以太网将在Hadoop集群证明其价值，高水平的网络利用率将带来效益更高的带宽。下图展示了Hadoop集群与万兆以太网的连接：许多企业级数据中心已经迁移到10GbE网络，以实现服务器整合和服务器虚拟化。随着越来越多企业开始部署Hadoop，他们发现他们完全不必要大批量部署1U的机架服务器，而是部署更少，但性能更高的服务器，以方便扩展每个数据节点所能运行的任务数量。很多企业选择部署2U或4U的服务器(如戴尔 PowerEdge C2100)，每个节点大约12-16个核心以及24TB存储容量。在这种环境下的合理选择是充分利用已经部署的10GbE设备和Hadoop集群中的 10GbE网卡。在日常的IT环境中构建一个简单的Hadoop集群。可以肯定的是，尽管有很多细节需要微调，但其基础是非常简单的。构建一个计算、存储和网络资源平衡的系统，对项目的成功至关重要。对于拥有密集节点的Hadoop集群而言，万兆以太网能够为计算和存储资源扩展提供与之相匹配的能力，且不会导致系统整体性能下降。