第1章 Delphi简介

Size: px

Start display at page:

Download "第1章 Delphi简介"

抑荀
4 years ago
Views:

初识 Hadoop 古代, 人们用牛来拉重物当一头牛拉不动一根圆木时, 他们不曾想过培育更大更壮的牛同样, 我们也不需要尝试开发超级计算机, 而应试着结合使用更多计算机系统数据! 数据! 格蕾斯霍珀我们生活在数据时代! 很难估计全球以电子方式存储的数据总量有多少, 但 IDC 的一项预测曾指出, 数字全球 (digital universe) 项目统计得出,2006 年的数据总量为 0.

1 初识 Hadoop 古代, 人们用牛来拉重物当一头牛拉不动一根圆木时, 他们不曾想过培育更大更壮的牛同样, 我们也不需要尝试开发超级计算机, 而应试着结合使用更多计算机系统数据! 数据! 格蕾斯霍珀我们生活在数据时代! 很难估计全球以电子方式存储的数据总量有多少, 但 IDC 的一项预测曾指出, 数字全球 (digital universe) 项目统计得出,2006 年的数据总量为 0.18 ZB, 并预测在 2011 年, 数据量将达到 1.8 ZB * 1 ZB 等于字节, 或者等于 1000 EB, PB, 或者是大家更熟悉的 10 亿 TB 的数据! 这相当于世界上每人一个磁盘驱动器所能容纳数据的数量级数据洪流有很多来源以下面列出的部分为例纽约证券交易所每天产生 1 TB 的交易数据 Facebook 存储着约 100 亿张照片, 约 1 PB 存储容量 Ancestry.com, 一个家谱网站, 存储着 2.5 PB 数据 The Internet Archive( 互联网档案馆 ) 存储着约 2 PB 的数据, 并以每月至少 20 TB 的速度增长瑞士日内瓦附近的大型强子对撞机每年产生约 15 PB 的数据 * 来自 Gantz 等的 The Diverse and Exploding Digital Universe, March 2008, 网址为来源分别为 /Inside+ Ancestrycoms+TopSecret+Data+Center.aspx, 和初识 Hadoop 1

2 此外还有大量数据但是你可能会想它对自己有何影响大部分数据严密保存 (locked up) 在一些大型互联网公司 ( 如搜索引擎公司 ), 或者科学机构, 或者金融机构, 难道不是吗? 难道所谓的大数据的出现会影响到较小的组织或个人? 我认为是这样的以照片为例, 我妻子的祖父是一个狂热的摄影爱好者成年之后, 他经常拍照片整个照片集, 包括普通胶片幻灯片 35 mm 胶片, 在扫描成高解析度图片之后, 大约有 10 GB 相比之下,2008 年我家用数码相机拍摄的照片就有 5 GB 我家照片数据的生成速度是我妻子祖父的 35 倍! 并且, 这个速度还在不断增加, 因为拍摄照片变得越来越容易了更一般的情况是, 个人数据的产生量正在快速地增长微软研究院的 MyLifeBits 项目 ( 显示, 在不久的将来, 将普及个人信息档案 MyLifeBits 是这样的一个实验 : 获取并存储个人与外界的联系情况 ( 电话邮件和文件 ), 以供后期访问收集的数据中包括每分钟拍摄的照片等, 其数据量达到每月 1 GB 左右当存储成本下降得足够多, 以至于可以存储连续音频和视频时, 未来 MyLifeBits 项目所存储的数据量将是现在的许多倍目前的趋势是保存每个人成长过程中产生的所有数据, 但更重要的是, 计算机产生的数据可能比个人产生的更多机器日志 RFID 检测器传感器网络车载 GPS 和零售交易数据等所有这些都将使数据量显著增加公开发布的数据量也在逐年增加组织或企业, 不仅需要管理好自己的数据, 更需要从其他组织或企业的数据中获取有价值的信息, 以便在未来获得更大的成功这方面的先锋, 如 Public Data Sets on Amazon Web Services Infochimps.org 和 andtheinfo.org, 正在培育信息共享系统 (information commons), 任何人都可以在此自由下载和分析这些数据 ( 例如通过 AWS 平台实现共享, 并以合理的价格收费 ) 不同来源的信息混合处理后, 将带来意外的效果和今天难以想象的应用以 Astrometry.net 项目为例, 这是一个观察和分析 Flickr 网站上天文小组所拍星空照片的项目该项目分析每一张照片, 并辨别出该图片是天空或其他天体 ( 例如恒星, 银河系等 ) 的哪一部分该项目表明, 如果可用的数据足够多 ( 在本例中, 为加有标签的图片数据 ), 这些数据可用于数据创建者也想象不到到的一些应用 ( 例如, 图片分析 ) 2

3 曾有这么一句话 : 大量的数据胜于好的算法意思是说对于某些应用 ( 譬如基于先前偏好进行电影和音乐推荐 ), 不论你的算法有多好, 大量可用的数据总能带来更好的推荐效果现在, 我们已经有了大量的数据, 这对我们来说是个好消息不幸的是, 我们当下正纠结于存储和分析这些数据数据存储与分析我们遇到的问题很简单 : 多年来磁盘存储容量快速增加的同时, 其访问速度磁盘数据读取速度却未能与时俱进 1990 年, 一个普通磁盘可存储 1370 MB 的数据并拥有 4.4 MB/s 的传输速度, 因此, 读取整个磁盘中的数据只需要 5 分钟 20 年后,1 TB 的磁盘逐渐普及, 但其数据传输速度约为 100 MB/s, 因此读取整个磁盘中的数据需要约两个半小时读取一个磁盘中所有的数据需要很长的时间, 写甚至更慢一个很简单的减少读取时间的办法是同时从多个磁盘上读取数据试想, 如果我们拥有 100 个磁盘, 每个磁盘存储 1% 的数据, 并行读取, 那么不到两分钟就可以读取所有数据仅使用磁盘容量的 1% 似乎很浪费但是我们可以存储 100 个数据集, 每个数据集 1 TB, 并实现共享磁盘的访问可以想像, 该类系统的用户会很乐意使用磁盘共享访问以便缩短数据分析时间 ; 并且, 从统计角度来看, 用户的分析工作会在不同的时间点进行, 所以互相之间的干扰不会太大尽管如此, 但要实现对多个磁盘数据的并行读写, 还有更多的问题要解决第一个需要解决的问题是硬件故障一旦使用多个硬件, 其中任一硬件发生故障的概率将非常高避免数据丢失的常见做法是使用备份 : 系统保存数据的冗余副本, 在发生故障后, 可以使用数据的另一可用副本例如, 冗余磁盘阵列 (RAID) 就是按这个原理实现的, 另外,Hadoop 的文件系统, 即 HDFS(Hadoop Distributed Filesystem) 也是一类, 不过它采取的方法稍有不同详见后文描述引自 Anand Rajaraman 的文章 Netflix Challenge ( moredata-usual.html) Alon Halevy,Peter Norvig 和 Fernando Pereira 在 The Unreasonable Effectiveness of Data, IEEE Intelligent Systems, March/April 2009 中也给出了相似的观点这些规格针对的是 Seagate ST-41600n 初识 Hadoop 3

4 第二个问题是大多数分析任务需要以某种方式结合大部分数据共同完成分析任务, 即从一个磁盘读取的数据可能需要和从另外 99 个磁盘中读取的数据结合使用各种分布式系统允许结合多个来源的数据并实现分析, 但保证其正确性是一个非常大的挑战 MapReduce 提出了一个编程模型, 该模型将上述磁盘读写的问题进行抽象, 并转换为对一个数据集 ( 由键 / 值对组成 ) 的计算后文将详细讨论该模型, 需要指出的是, 该计算由 map 和 reduce 两部分组成, 而只有这两部分提供对外的接口与 HDFS 类似,MapReduce 内建了可靠性简而言之,Hadoop 提供了一个可靠的共享存储和分析系统 HDFS 实现存储, 而 MapReduce 实现分析处理纵然 Hadoop 还有其他功能, 但这两部分是它的核心与其他系统相比 MapReduce 似乎采用的是一种蛮力方法每个查询需要处理整个数据集或者至少数据集的很大一部分反过来想, 这也正是它的能力 MapReduce 是一个批量查询处理器, 并且它能够在合理的时间范围内处理针对整个数据集的即席 (ad hoc) 查询它改变了我们对数据的传统看法, 并且解放了以前存储在磁带和磁盘上的数据它赋予我们对数据进行创新的机会那些以前需要很长时间处理才能获得结果的问题现在已经迎刃而解, 但也引发了新的问题和见解例如,Rackspace 的邮件部门 Mailtrust, 使用 Hadoop 处理邮件日志他们写的一个查询是找出用户的地理分布他们是这么描述的 : 这些数据是非常有用的, 我们每月运行一次 MapReduce 任务来帮助我们决定哪些 Rackspace 数据中心需要添加新的邮件服务器通过整合数百 GB 的数据, 并用 MapReduce 分析这些数据,Rackspace 的工程师们从中了解到以前没有留意的数据, 并且, 他们可以运用这些信息改善现有的服务第 16 章将详细介绍 Rackspace 公司是如何运用 Hadoop 的关系型数据库管理系统我们为什么不能使用数据库来对大量磁盘上的大规模数据进行批量分析呢? 我们为什么需要 MapReduce? 4

5 这些问题的答案来自磁盘的另一个发展趋势 : 寻址时间的提高远远慢于传输速率的提高寻址是将磁头移动到特定磁盘位置进行读写操作的过程它是导致磁盘操作延迟的主要原因, 而传输速率取决于磁盘的带宽如果数据的访问模式中包含大量的磁盘寻址, 那么读取大量数据集所花的时间势必会更长 ( 相较于以流式数据读取模式 ), 流式读取主要取决于传输速率另一方面, 数据库系统更新一小部分记录, 传统的 B 树更有优势 ( 关系型数据库中使用的一种数据结构, 受限于寻址的比例 ) 但数据库系统更新大部分数据时,B 树的效率比 MapReduce 低得多, 因为需要使用排序 / 合并 (Sort/Merge) 来重建数据库在许多情况下, 可以视 Mapreduce 为关系型数据库管理系统的补充 ( 两个系统之间的差异见表 1-1) MapReduce 比较适合以批处理的方式处理需要分析整个数据集的问题, 尤其是即席分析 RDBMS 适用于点查询 (point query) 和更新, 数据集被索引后, 数据库系统能够提供低延迟的数据检索和快速的少量数据更新 MapReduce 适合数据一次写入多次读取的应用, 而关系型数据库更适合持续更新的数据集表 1-1: 关系型数据库和 MapReduce 的比较传统关系型数据库 MapReduce 数据大小 GB PB 访问交互式和批处理批处理更新多次读写一次写入多次读取结构静态模式动态模式完整性高低横向扩展非线性线性 MapReduce 和关系型数据库之间的另一个区别在于它们所操作的数据集的结构化程度结构化数据 (structure data) 是具有既定格式的实体化数据, 诸如 XML 文档或者满足特定预定义格式的数据库表这就是 RDBMS 包括的内容另一方面, 半结构化数据 ( semi-structured data ) 比较松散, 虽然可能有格式, 但经常被忽略, 所以它只能用作对数据结构的一般指导例如, 一张电子表格, 其结构是由单元格组成的网格, 但是每个单元格自身可保存任何形式的数据非结构化数据 (unstructured data) 没有什么特别的内部结构, 例如纯文本或图像数据 MapReduce 对于非结构化或半结构化数据非常有效, 因为在处理数据时才对数据进行解释换句话说 :MapReduce 输入的键和值并不是数据固有的属性, 而是由分析数据的人员来选择的初识 Hadoop 5

6 关系型数据往往是规范的 (normalized), 以保持其数据的完整性且不含冗余规范化给 MapReduce 带来了问题, 因为它使记录读取成为异地操作, 然而 MapReduce 的核心假设之一就是, 它可以进行 ( 高速 ) 的流式读写操作 Web 服务器日志是一个典型的非规范化数据记录 ( 例如, 每次都需要记录客户端主机全名, 导致同一客户端全名可能会多次出现 ), 这也是 MapReduce 非常适合用于分析各种日志文件的原因之一 MapReduce 是一种线性可伸缩的编程模型程序员编写两个函数, 分别为 map 函数和 reduce 函数每个函数定义一个键 / 值集合到另一个键 / 值对集合的映射这些函数无需关注数据集及其所用集群的大小, 因此可以原封不动地应用到小规模数据集或者大规模的数据集上更重要的是, 如果输入的数据量是原来的两倍, 那么运行的时间也需要两倍但是如果集群是原来的两倍, 作业的运行仍然与原来一样快 SQL 查询一般不这样但是在不久的将来, 关系型数据库系统和 MapReduce 系统之间的差异很可能变得模糊关系型数据库都开始吸收 MapReduce 的一些思路 ( 如 ASTER DATA 的和 GreenPlum 的数据库 ), 另一方面, 基于 MapReduce 的高级查询语言 ( 如 Pig 和 Hive) 使 MapReduce 的系统更接近传统的数据库编程方式 ** 网格计算高性能计算 (High Performance Computing,HPC) 和网格计算 (Grid Computing) 组织多年来一直在研究大规模数据处理, 主要使用类似于消息传递接口 (Message Passing Interface,MPI) 的 API 从广义上讲, 高性能计算的方法是将作业分散到集群的各台机器上, 这些机器访问由存储区域网络 (SAN) 组织的共享文件系统这比较适用于计算密集型的作业, 但如果节点需要访问更大量的数据 ( 几百个 GB 的数据, 这时 MapReduce 开始发挥其优势 ), 很多计算节点由于网络带宽的瓶颈问题而空闲下来等待数据 ** 2007 年 1 月,David J. DeWitt 和 Michael Stonebraker 发表的论文 MapReduce: A major step backwards ( 引起了人们的争论在文中, 他们认为 MapReduce 不适合替代关系数据库许多评论认为这是一种错误的比较 ( 参见 Mark C. Chu-Carroll 的文章 Databasesare hammers; MapReduce is a screwdriver, ), 及 DeWitt 与 Stonebraker 的回复 MapReduce II ( 他们对评论的主要观点进行了阐述 6

7 MapReduc 会尽量在计算节点上存储数据, 以实现数据的本地快速访问数据本地化 (data locality) 特性, 是 MapReduce 的核心特征, 并由此获得了良好的性能意识到网络带宽是数据中心环境最珍贵的资源 ( 到处复制数据很容易耗尽网络带宽 ) 之后,MapReduce 通过显式网络拓扑结构尽力保留网络带宽注意, 这种排列方式并未降低 MapReduce 的计算密集型的数据分析能力 MPI 赋予了程序员极大的控制能力, 但是需要程序员显式控制数据流机制, 包括通过 C 语言构造低层次的功能模块 ( 例如套接字 ) 和高层次的数据分析算法而 MapReduce 则在更高层面上执行任务, 即程序员仅从键 / 值对函数的角度考虑任务的执行, 这样数据流是隐含的在大规模分布式计算环境下, 协调各进程间的执行是一个很大的挑战最困难是合理地处理系统部分失效问题在不知道一个远程进程是否已失效的情况下仍然需要继续完成整个计算 MapReduce 让程序员无需考虑系统的部分失效问题, 因为自身的系统实现能够检测到失败的 map 或者 reduce 任务, 并让正常运行的机器重新执行这些失败的任务正是由于采用了无共享 ( shared-nothing) 框架, 所以 MapReduce 才能够实现失败检测, 这意味着各个任务之间彼此独立 ( 这里讲得过于简单了一点, 因为 MapReduce 系统本身控制着 mapper 的输出结果传给 reducer 的过程 ; 这种情况下, 重新运行 reducer 比重新运行 mapper 更需要格外小心, 因为 reducer 需要获取必要的 mapper 的输出结果, 如果没有获得必要的输出结果, 必须再次运行相关 mapper 重新生成输出结果 ) 因此, 从程序员的角度来看, 任务的执行顺序是无关紧要的相比之下, MPI 程序必须显式地管理自身的检查点和恢复机制, 尽管更多的控制权交给了程序员, 但也加大了编程的难度 MapReduce 听起来似乎是一个相当严格的编程模型, 而且在某种意义上看, 它的确如此 : 用户被限定于使用具有特定关联的键 / 值对,mapper 和 reducer 彼此间可做的协调非常有限,( 每个 mapper 将键 / 值传送给 reducer) 对此, 自然联想到一个问题 : 能用该编程模型做一些有用或不普通的事情吗? 答案是肯定的 MapReduce 是由谷歌的工程师开发的, 用于构建搜索引擎的索引, 并且他们证明了它能够一次又一次地解决这一索引问题 (MapReduce 的灵感来自于传统的函数式编程分布式计算和数据库社区 ), 此后该模型又被广泛应用于众多工业应用我们惊喜地发现, 有许多算法可以使用 MapReduce 来表达, 从 Jim Gray 首先支持在存储数据附近的机器上进行计算参见 Distributed Computing Economics March 2003, 网址为初识 Hadoop 7

8 图像图形分析到各类基于图像分析的问题, 再到机器学习算法当然, 它不能解决所有问题, 但它确实是一个比较通用的数据处理工具我们将在第 16 章介绍 Hadoop 的一些典型应用志愿计算人们第一次听说 Hadoop 和 MapReduce 的时候, 经常会问 : 它们和 SETI@home 有什么不同? SETI, 全称为 Search for Extra-Terrestrial Intelligence( 搜寻外星智慧 ), 执行着一个称为 SETI@home 的项目 ( 在该项目中, 志愿者把自己计算机 CPU 的空闲时间贡献出来分析无线天文望远镜的数据借此寻找外星智慧生命信号 SETI@home 因拥有大量志愿者而非常出名, 其他还有 Great Internet Mersenne Prime Search( 搜索大素数 ) 与 Folding@home 项目 ( 了解蛋白质构成及其与疾病之间的关系 ) 志愿计算项目将他们试图解决的问题分成多个块, 每个块称为一个工作单元 (work unit) 并将它们发到世界各地的电脑上进行分析例如,SETI@home 的工作单元是约 0.35 MB 的无线电望远镜数据, 分析这样的数据, 一台普通计算机需要数小时或数天完成分析后, 结果被发送回服务器, 之后客户端获得另一个工作单元为防止欺骗, 每个工作单元被送到 3 台不同的机器上执行, 且至少收到两个相同结果才被接受虽然表面上看起来,SETI@home 与 MapReduce 比较相似 ( 将问题分为独立的块, 然后进行并行计算 ), 但依旧还有很多显著的差异 SETI@home 问题是 CPU 高度密集的, 比较适合在全世界成千上万的计算机上运行, 因为用于计算的时间会远大于工作单元数据的传输时间志愿者贡献的是 CPU 周期, 而非网络带宽 MapReduce 的设计目标是服务于那些只需数分钟或数小时即可完成的作业, 并且运行于内部通过高速网络连接的单一数据中心内, 并且该数据中心内的计算机需要由可靠的定制的硬件构成相比之下,SETI@home 则需要在接入互联网的不可信的计算机上长期运行, 这些计算机具有不同网络带宽, 且无需数据本地化 * Apache Mahout( 是一个在 Hadoop 上运行的机器学习类库 ( 例如分类和聚类算法 ) * 2008 年 1 月,SETI@home 发表评论说每天使用台计算机处理 300 GB 数据, 同时他们也在做其他的一些数据计算, setiathome_

9 1.3.4 Hadoop 发展简史 Hadoop 是 Apache Lucene 创始人 Doug Cutting 创建的,Lucene 是一个广泛使用的文本搜索系统库 Hadoop 起源于 Apache Nutch, 一个开源的网络搜索引擎, 它本身也是 Lucene 项目的一部分 Hadoop 名字的起源 Hadoop 这个名字不是一个缩写, 它是一个虚构的名字该项目的创建者 Doug Cutting 如下解释 Hadoop 这一名称的来历 : 这个名字是我的孩子给一头吃饱了的棕黄色大象取的我的命名标准是简短, 容易发音和拼写, 没有太多的含义, 并且不会被用于别处小孩子是这方面的高手 Googol 就是小孩子起的名字 Hadoop 的子项目及后续模块所使用的名称也往往与其功能不相关, 通常也以大象或其他动物为主题取名 ( 例如 Pig ) 较小一些的组件, 名称通常具有较好的描述性 ( 也因此更俗 ) 这个原则很好, 这意味着你可以通过它的名字大致猜测它的功能, 例如,jobtracker 用于跟踪 MapReduce 作业从头开始构建一个网络搜索引擎是一个雄心勃勃的计划, 不仅是因为编写一个爬取并索引网页的软件比较复杂, 更因为这个项目需要一个专门的团队来实现项目中包含许多需要随时修改的组件同时, 构建这样一个系统的代价非常高据 Mike Cafarella 和 Doug Cutting 估计, 一个支持 10 亿网页的索引系统单是硬件上的投入就高达 50 万美元, 另外每月运行维护费用也高达 3 万美元不过, 他们认为这项工作仍然是值得的, 因为它开创了优化搜索引擎算法的平台 Nutch 项目始于 2002 年, 一个可以运行的网页爬取工具和搜索引擎系统很快浮出水面但后来, 开发者认为这一架构可扩展度不够, 不能解决数十亿网页的搜索问题 2003 年发表的一篇论文为此提供了帮助, 文中描述的是谷歌产品架构, 该架构称为谷歌分布式文件系统, 简称 GFS GFS 或类似的架构, 可以解决他们本书中我们使用小写形式 ( 如 jobtracker) 来表示对实体的应用, 代码形式 ( 如 JobTracker) 来表示对 Java 类的实现初识 Hadoop 9

10 在网页爬取和索引过程中产生的超大文件的存储需求特别关键的是, GFS 能够节省系统管理 ( 如管理存储节点 ) 所花的大量时间在 2004 年, 他们开始着手实现一个开源的实现, 即 Nutch 的分布式文件系统 (NDFS) * Mike Cafarella 和 Doug Cutting 的文章 Building Nutch: Open Source Search, ACM Queue, April 2004, 网址为 * Sanjay Ghemawat,Howard Gobioff 和 Shun-Tak Leung 的文章 The Google File System, October 2003, 网址为 10

11 2004 年, 谷歌发表论文向全世界介绍他们的 MapReduce 系统 2005 年初,Nutch 的开发人员在 Nutch 上实现了一个 MapReduce 系统, 到年中,Nutch 的所有主要算法均完成移植, 用 MapReduce 和 NDFS 来运行 Nutch 的 NDFS 和 MapReduce 实现不只是适用于搜索领域在 2006 年 2 月, 开发人员将 NDFS 和 MapReduce 移出 Nutch 形成 Lucene 的一个子项目, 称为 Hadoop 大约在同一时间, Doug Cutting 加入雅虎, 雅虎为此组织了一个专门的团队和资源, 将 Hadoop 发展成一个能够处理 Web 数据的系统 ( 见第 11 页的补充材料 ) 在 2008 年 2 月,Yahoo! 宣布其搜索引擎使用的索引是在一个拥有 1 万个内核的 Hadoop 集群上构建的 2008 年 1 月,Hadoop 已成为 Apache 的顶级项目, 证明了它的成功多样化活跃性到目前为止, 除 Yahoo! 之外, 还有很多公司使用了 Hadoop, 例如 Last.fm Facebook 和纽约时报等第 16 章和 Hadoop wiki 都介绍了一些案例,Hadoop wiki 的网址为纽约时报是一个很好的宣传范例, 他们将扫描往年报纸获得的 4 TB 存档文件通过亚马逊的 EC2 云计算转换成 PDF 文件, 并上传到网上整个过程使用了 100 台计算机, 历时不到 24 小时如果不将亚马逊的按小时付费的模式 ( 即允许纽约时报短期内访问大量机器 ) 和 Hadoop 易于使用的并发编程模型结合起来, 该项目很可能不会这么快开始启动并完成 2008 年 4 月,Hadoop 打破世界纪录, 成为最快的 TB 级数据排序系统通过一个 910 节点的群集,Hadoop 在 209 秒内 ( 不到三分半钟 ) 完成了对 1 TB 数据的排序, 击败了前一年的 297 秒冠军 ( 详情参见第 533 页的 Apache Hadoop TB 级数据排序小节 ) 同年 11 月, 谷歌在报告中声称, 它的 MapReduce 对 1 TB 数据排序 Jeffrey Dean 和 Sanjay Ghemawat 的文章 MapReduce: Simplified Data Processing on Large Clusters, 发表于 December 2004, 网址为初识 Hadoop 11

12 只用了 68 秒本书第 1 版出版的时候 (2009 年 5 月 ), 有报道宣称 Yahoo! 的团队使用 Hadoop 对 1 TB 数据排序只花了 62 秒 * Derek Gottfrid 的文章 Self-service, Prorated Super Computing Fun! 发表于 2007 年 11 月 1 日, 网址为 * 参见 Sorting 1PB with MapReduce, 发表于 2008 年 11 月 21 日, 网址为 12

13 Yahoo! 的 Hadoop 构建互联网规模的搜索引擎需要大量的数据, 因此需要大量的机器来进行处理 Yahoo!Search 有 4 个主要组成部分 :Crawler, 从网页服务器爬取网页 ; WebMap, 构建一个已知网页的链接图 ; Indexer, 为最佳页面构建一个反向索引 ;Runtime, 处理用户的查询 WebMap 构建的链接图非常大, 大约包括一万亿条边 ( 每条边代表一个网页链接 ) 和一千亿个节点 ( 每个节点代表不同的网址 ) 创建并分析如此大的图需要大量计算机运行若干天 2005 年初,WebMap 所用的底层架构称为 Dreadnaught, 需要重新设计使其可以扩展到更多的节点 Dreadnaught 成功地从 20 个节点扩展到 600 个, 但需要一个完全重新的设计, 才能进一步扩大 Dreadnaught 与 MapReduce 在很多方面都很相似, 但灵活性更强且结构更松散具体说来,Dreadmaught 工作的每一个分块都可以输送到下一阶段的各个分块继续执行, 而排序是通过库函数中完成的但实际情形是, 大多数 WebMap 阶段是两两构成一对, 并对应于一个 MapReduce 因此, WebMap 应用不需要做大量的重构操作, 便可以适应 MapReduce Eric Baldeschwieler(Eric14) 组建了一个小团队, 于是我们开始设计并在 GFS 和 MapReduce 上用 C++ 来建立一个新框架的原型, 最后用它来取代 Dreadnaught 尽管我们的当务之急是需要一个 WebMap 新框架, 但更清楚的是, 标准化 Yahoo! Search 的批处理平台对我们更重要使平台更通用以便支持其他用户, 才能够最大化整个平台的投资与此同时, 我们关注 Hadoop( 当时还是 Nutch 的一部分 ) 及其进展情况 2006 年 1 月,Yahoo! 聘请了 Doug Cutting 一个月后, 我们决定放弃我们的原型, 转而采用 Hadoop 与我们的原型和设计相比, Hadoop 的优势在于它已经在 20 个节点上实际应用过 (Nutch) 这样一来, 我们便能在两个月内搭建一个研究集群, 并能够更快地帮助我们的客户使用这个新的框架另一个显著的优点是 Hadoop 已经开源, 较容易 ( 尽管也不是太容易!) 从 Yahoo! 法务部门获得许可对该开源系统进行进一步研究因此, 我们在 2006 年初构建了一个 200 个节点的研究集群, 并将 WebMap 的计划暂时搁置, 转而为研究用户使用 Hadoop 提供支持以及进一步开发 Hadoop 大事记 2004 年由 Doug Cutting 和 Mike Cafarella 实现了现在 HDFS 和 MapReduce 的最初版本 2005 年 12 月 Nutch 移植到新框架,Hadoop 在 20 个节点上稳定运行初识 Hadoop 13

14 2006 年 1 月 Doug Cutting 加入 Yahoo! 2006 年 2 月 Apache Hadoop 项目正式启动以支持 MapReduce 和 HDFS 的独立发展 2006 年 2 月 Yahoo! 的网格计算团队采用 Hadoop 2006 年 4 月在 188 个节点上 ( 每个节点 10 GB) 运行排序测试集需要 47.9 个小时 2006 年 5 月 Yahoo! 建立了一个 300 个节点的 Hadoop 研究集群 2006 年 5 月在 500 个节点上运行排序测试集需要 42 个小时 ( 硬件配置比 4 月的更好 ) 2006 年 11 月研究集群增加到 600 个节点 2006 年 12 月排序测试集在 20 个节点上运行 1.8 个小时,100 个节点上运行 3.3 小时,500 个节点上运行 5.2 小时,900 个节点上运行 7.8 个小时 2007 年 1 月研究集群增加到 900 个节点 2007 年 4 月研究集群增加到两个 1000 个节点的集群 2008 年 4 月在 900 个节点上运行 1 TB 排序测试集仅需 209 秒, 成为世界最快 2008 年 10 月研究集群每天装载 10 TB 的数据 2009 年 3 月 17 个集群总共台机器 2009 年 4 月赢得每分钟排序,59 秒内排序 500 GB( 在 1400 个节点上 ) 和 173 分钟内排序 100 TB 数据 ( 在 3400 个节点上 ) Apache Hadoop 和 Hadoop 生态圈尽管 Hadoop 因 MapReduce 及其分布式文件系统 (HDFS, 由 NDFS 改名而来 ) 而出名, 但 Hadoop 这个名字也用于一组相关项目的统称, 这些相关项目都是用该底层平台做分布式计算和海量数据处理本书所提到的大多数核心项目都受 Apache 软件基金会支持, 该基金会对开源软 14

15 件项目的组织提供支持, 其中包括最初的 HTTP Server 项目随着 Hadoop 生态圈的成长, 出现了越来越多的项目, 其中不乏一些非 Apache 主管的项目, 这些项目对 Hadoop 是个很好的补充, 或者提供一些更高层的抽象本书所提到的 Hadoop 项目简述如下 Common 一组分布式文件系统和通用 I/O 的组件与接口 ( 序列化 Java RPC 和持久化数据结构 ) Avro 一种支持高效跨语言的 RPC 以及永久存储数据的序列化系统 MapReduce 分布式数据处理模型和执行环境, 运行于大型商用机集群 HDFS 分布式文件系统, 运行于大型商用机集群 Pig 一种数据流语言和运行环境, 用以检索非常大的数据集 Pig 运行在 MapReduce 和 HDFS 的集群上 Hive 一个分布式按列存储的数据仓库 Hive 管理 HDFS 中存储的数据, 并提供基于 SQL 的查询语言 ( 由运行时引擎翻译成 MapReduce 作业 ) 用以查询数据 Hbase 一个分布式按列存储数据库 HBase 使用 HDFS 作为底层存储, 同时支持 MapReduce 的批量式计算和点查询 ( 随机读取 ) ZooKeeper 一个分布式可用性高的协调服务 ZooKeeper 提供分布式锁之类的基本服务用于构建分布式应用 Sqoop 在数据库和 HDFS 之间高效传输数据的工具初识 Hadoop 15

水晶分析师

水晶分析师大数据时代的挑战产品定位体系架构功能特点大数据处理平台行业大数据应用 IT 基础设施数据源 Hadoop Yarn 终端统一管理和监控中心(Deploy,Configure,monitor,Manage) Master Servers TRS CRYSTAL MPP Flat Files Applications&DBs ETL&DI Products 技术指标 1 TRS