本文章属于Hadoop系列文章，分享Hadoop相关知识。后续文章中会继续分享Hadoop的组件、MapReduce、HDFS、HBase、Flume、Pig、Spark、Hadoop集群管理系统以及案例项目等。想学习大数据的同学希望可以点赞、收藏、持续关注不迷路。

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

数据！数据！

我们生活在这个数据大爆炸的时代，很难估算全球的电子设备存储量。根据国际数据公司（IDC）曾经发布的报告，2013年统计出全球数据总量为4.4ZB，预测到2020年数据量将会达到44ZB，1ZB等于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作为关系型数据库的补充，两个系统之间差异如下

网格计算

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

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