初识Hadoop，走进大数据世界

在古时候人们用牛来拉重物当一头牛拉不动一根圆木时人们从来没有考虑过要想方设法培育出一种更强壮的牛。同理我们也不该想方设法打造什么超级计算机而应该千方百计综合利用更多计算机来解决问题。

数据数据

我们生活在这个数据大爆炸的时代很难估算全球的电子设备存储量。根据国际数据公司IDC曾经发布的报告2013年统计出全球数据总量为4.4ZB预测到2020年数据量将会达到44ZB1ZB等于1000EB等于1 000 000PB等于大家所熟悉的10亿TB这远远超过了全世界任意一块硬盘所能保存的数据量。

数据“洪流”有很多来源以下面列出为例

• 纽约证交所每天产生的交易数据大约的4TB到5TB之间。
• FaceBook存储的照片超过2400亿张并以每月至少7PB的速度增长。
• 互联网档案馆存储的数据约为18PB。
• 瑞士日内瓦附近的大型强子对撞机每年产生数据越30PB。

还有其他大量的数据比如作为物联网一部分的机器设备产生的日志、RFID读卡器、车载GPS等等。

组织或企业要想在未来取得成功不仅需要管理好自己的数据更需要从其他渠道获取有价值的信息。现在得益于开放的互联网我们已经可以从各个地方获取到需要的数据这是个好消息但不幸的是我们必须想方设法好好的存储和分析这些数据。

遇到的问题

我们遇到的问题很简单在硬盘存储容量多年来不断提升的同时硬盘数据读取的速度却没有与时俱进。1990年一个普通的硬盘可以存储1370MB的数据传输速度为4.4 MB/s因此只需要5分钟就可以读完整个硬盘的数据。20年过去了1TB的硬盘成为主流但其数据传输速度约为100 MB/s读完整个硬盘至少需要花费2.5个小时。

一个很简单减少读取时间的办法是同时从多个硬盘上读数据。试想如果有100个硬盘每个硬盘存储1%的数据并行读取那么不到两分钟就可以读完所有数据。仅使用硬盘容量的1%似乎很浪费但是我们可以存储100个数据集每个数据集1TB并实现共享硬盘的读取。

Hadoop的出现

虽然如此但要对多个硬盘中的数据并行进行读/写数据还有很多问题要解决。

第一个需要解决的是硬件故障问题。一旦开始使用多个硬件其中个别硬件就很有可能发生故障。为了避免数据丢失最常见的做法是复制系统保存数据的副本一旦有系统发生故障就可以用另外保存的副本。例如冗余硬盘阵列RAID就是按这个原理实现的另外Hadoop的文件系统HDFS也是这一类。

第二个问题是大多数分析任务需要结合大部分数据共同完成分析即从一个硬盘读取的数据可能需要从另外99个硬盘的数据结合使用保证其正确性是一个非常大的挑战MapReduce提出一个编程模型该模型抽象出这些硬盘读/写问题并转换为对一个数据集由键-值对组成的计算有很高的可靠性。

简而言之Hadoop为我们提供了一个可靠的且可扩展的存储与分析平台。此外由于Hadoop运行在商用硬件上且是开源的所以使用成本是在可接受范围内的。

相较于其他系统的优势

Hadoop不是历史上第一个用于数据存储和分析的分布式系统但是Hadoop的一些特性将它和类似的系统区别开来。

关系型数据库

为什么不能用配有大量硬盘的数据库来进行大规模数据分析为什么用Hadoop

这两个问题的答案来自于计算机硬盘的发展趋势寻址时间的提升远远不敌传输速率的提升寻址是将磁头移动到硬盘的某个位置进行读/写操作的过程它是导致硬盘操作延迟的主要原因而传输速率取决于硬盘的带宽。
如果数据访问中包含大量的硬盘寻址那么读取大量数据必然会花更长的时间。另一方面如果数据库系统只更新一小部分记录那么传统的B树更有优势。但数据库系统如果有大量的数据更新B树的效率就明显落后于MapReduce了。在很多情况下可以将MapReduce作为关系型数据库的补充两个系统之间差异如下

	关系型数据库	MapReduce
数据大小	GB	PB
数据存取	交互式和批处理	批处理
更新	多次读/写	一次写入多次读取
事务	ACID	无
结构	写时模式	读时模式
完整性	高	低
横向扩展	非线性	线性

网格计算

高性能计算和网格计算组织多年来一直在研究大规模数据处理主要使用类似于消息传递接口的API。广义上讲高性能计算采用的方法是将作业分散到集群的各个机器上这些机器访问存储区域网络SAN所组成的共享文件系统如果节点需要访问的数据量更庞大很多节点就会因为网络带宽的瓶颈问题而不得不闲下来等数据。

Hadoop尽量在计算节点上存储数据以实现数据的本地快速访问。数据本地化是Hadoop数据处理的核心并因此获得良好的性能。