hadoop 大数据的动机

20多年前的计算机革命使得大量的数据正被企业集聚起来。数字传感器的发展、通信系统的激增，尤其是移动平台和设备；对系统事件大规模的日志记录；以及朝着无纸化企业的迅速发展，这些导致企业内部数据资源的大规模集聚。企业对技术的依赖确保了数据将继续以更快的速度增长。

摩尔定律称计算机的性能一直以来都是几乎每两年就会比过去翻一番，最初计算资源与数据增长速度保持一致。然而，2005年左右这种计算资源的发展速度开始逐渐减缓。

计算行业开始寻找其他选择，即并行处理以提供更经济的解决方案。如果一台计算机不能 变得更快，则其目标是用大量计算资源来并行处理同样的问题。Hadoop是网络中的多台计算机运用MapReduce扩展数据处理（单指令的变体，计算技术的多数据[SIMD]类）的概念的实现。

基于云计算通过供应商如亚马逊，谷歌和微软等不断演变，推动了这一概念的发展，因为我们现在可以租用计算资源来节省购买这些所需的一小部分成本（t.dbdao.com）。

本书是设计意图是使用Hadoop，一个由Apache软件基金会主办，现已扩展并由各供应商，如Cloudera，MapR和Hortonworks支持的项目，来开发和运行软件的实用指南。本章将从总体上讨论大数据尤其是Hadoop的动机。

大数据是什么？

在本书中，大数据的一个数据集定义，指那些单个机器资源无法处理或存储（在某些情况下）的任何数据集。该定义的前半部分至关重要。它可以在一台机器上处理几乎任何规模的数据。即使那些无法在单个机器上存储的数据可以通过从一个共享存储器如网络附加存储（NAS）介质读取被导入一台机器。然而，处理这些数据所需的时间量相对于处理这些数据的可用时间将会多得多。思考一个简单的例子。如果一个企业单位处理任务的平均容量为200 GB，假设我们每秒可以读大概50 MB。在每秒50 MB的前提下，我们从磁盘顺序读取100 MB数据需要2秒，读取整个200 GB的数据将花费我们大约1个小时。现在想象一下，要求该数据在5分钟内处理完。如果每个任务所需的200 GB能够均匀分布在100个节点上，且每个节点可以处理其自己的数据（考虑一个简化用例，如基于一个简单标准：SALES_YEAR> 2001只选择一个数据子集），减少执行CPU处理所用的时间，将100个节点的结果集合起来，总处理可在1分钟内完成（t.dbdao.com）。

这个简单的例子表明大数据是上下文相关的，且上下文由业务需求提供（t.dbdao.com）。

虽然我们在前面的例子中提出了许多假设，最关键的是我们可以非常快速地处理数据，但至于我们可以从永久存储中读取数据的速度究竟有多快仍然存在很大的局限性。与读/写节点本地永久存储相比，通过网络发送数据速度更要慢得多。

所有大数据方法的一些共同特点如下：

数据分布在多个节点（网络I/ O速度<<本地磁盘I/ O速度）。 应用程序被分配到数据（集群中的节点），而非相反。 数据尽可能被本地处理到节点上（网络I/ O速度<<本地磁盘I/ O速度）。 随机磁盘I / O被顺序磁盘I / O代替（传输速率<<磁盘寻道时间）。

所有大数据模式的目的都是使输入/输出（I / O）并行化以提高性能。

数据在多个节点分布

根据定义，大数据是不能用一台机器的资源处理的数据。大数据的一个卖点是商品机的使用。一个典型的商品机有2-4 TB的磁盘。由于大数据是指远大于它的数据集，数据将会跨多个节点分布。

注意，将数据跨多个节点分布对于处理数十TB的数据来说不是真的有必要。你会发现大数据系统通常在节点适当的位置上处理数据。因为有大量的节点参与数据处理，必须将数据跨节点分布。因此，一个500GB的数据集也会被分布在多个节点上，即使集群中的一台机器能够存储数据。这种数据分布有两重目的：

每个数据块在不止一个节点上（默认Hadoop的复制因子为3）被复制。这使得系统对故障容错。如果一个节点发生故障，其他节点具有故障节点上所承载数据的副本（t.dbdao.com）。 为了并行处理，几个节点参与数据处理。

因此，10个节点内共享50 GB数据使得全部10个节点能够处理自己的子数据集，实现5-10倍的性能提升。读者也许会问为什么不是所有的数据都在网络文件系统（NFS）上，其中每个节点都可以读取它的部分。答案是从本地磁盘读取比从网络读取速度更快。大数据系统使本地计算成为可能，因为在一个任务（一个应用程序实例）启动前应用程序库被复制到每个数据节点上。我们下一节再讨论这个问题。

应用程序被移动到数据位置

对于我们这些乘着Java平台环境浪潮的，三层架构已经渗透我们的观念。在三层编程模式中，数据通过网络导入之后在集中式应用程序层被处理。我们过去习惯于数据被分配而应用程序被集中化的概念。

大数据无法处理这种网络开销。移动数TB的数据到应用层将使网络饱和，导致效率极其低下，可能造成系统故障。在大数据世界中，数据被分布在各个节点上，但应用程序移动到数据。注意该过程并不容易，这很重要。不仅应用程序需要被移动到数据，而且所有的依赖库也需要被移动到处理节点。如果你的集群上有数百个节点，很容易明白对于维护/调度为什么这会是一个噩梦。因此，大数据系统的设计使你可以集中部署代码，且底层大数据系统在任务执行之前，将应用程序移动到处理节点（t.dbdao.com）。

数据在某个节点本地处理

这种数据被节点本地处理的属性是大数据系统前面两个属性的自然结果。所有的大数据编程模型都是基于分散和并行处理的。网络I / O是比磁盘I / O速度慢很多数量级。因为数据已经被分布到各个节点，应用程序库被移动到节点，其目标是在适当的位置处理数据。

虽然一个典型的大数据系统比较倾向于在节点上本地处理数据，但也有例外。大数据系统在尽可能靠近数据的节点上调度任务。从各个章节中你会明白对于某些类型的系统，某些任务需要跨节点提取数据。最起码，每个节点的结果必须被同化在一个节点上（MapReduce有名的reduce阶段或大规模并行编程模型类似的阶段）。然而，对于大量用例来说，最终同化阶段的数据与在节点本地任务处 理的原始数据相比要少得多。因此网络开销的影响通常（但不总是）忽略不计（t.dbdao.com）。

连续读取优于随机读取

首先，你需要了解数据是如何从磁盘读取的。磁盘头需要被定位在数据在磁盘上所处的位置。该过程，需要花费一定时间，被称为 寻道 操作。一旦磁盘头根据需要被定位，数据将被从磁盘顺序读取。这被称为 传输 操作。寻道时间大约为10毫秒;传输速度为（每1 MB）20毫秒的量级。这意味着如果我们从磁盘不同的1 MB部分读取100 MB将花费我们10（寻道时间）* 100（seeks）= 1秒，再加20（每1MB的传输速率）* 100 = 2秒。读取100 MB总共需要3秒。然而，如果我们从磁盘顺序读取100 MB，这将花费我们10（seek time）* 1（seek）= 10毫秒+ 20 * 100 = 2秒，总共2.01秒。

注意，我们从2009年开始一直使用以Jeff Dean博士的演讲为基础的数字。无可否认的是，该数字已经改变;事实上，他们自那时起已经改进了。然而，数字之间的相对比例没有改变，因此为保持一致性我们将继续使用。

大多数面向吞吐量的大数据编程模型利用了此功能。数据被从磁盘顺次扫描并在内存中过滤。这与更倾向于随机读取的典型的关系数据库管理系统（RDBMS）模型形成鲜明对比（t.dbdao.com）。

一个示例

假设你想获取2000年按国家排序的总销售数据，且该销售数据随机分布在多个节点。用大数据技术来实现这一目的可归纳为以下步骤：

1.每个节点读取全部销售数据并过滤出不属于2000年的销售数据。数据随机分布在所有节点并从磁盘上顺序读取。过滤发生在内存，而不是磁盘上，以避免寻道时间成本。

2.每个国家一被发现，每个节点进程开始为其创建组，并增加给定国家区的销售数额。（应用程序存在于所有节点上，且数据被本地处理到一个节点。）

3.当所有节点都已完成了从磁盘清理销售数据并且按国家编号计算总销售额的过程后，他们发送其各自的编号到一个指定节点（我们称之为 接收节点 assembler node），这个节点是在过程一开始所有节点一致同意的。

4.指定的接收节点汇聚了每个节点按国家编号所有的总销售额，并为每个状态增加从各节点接收到的值。

5.接收节点按状态为最终数字排序，并提供结果。

这一过程展示了大数据系统的典型特点：集中于使吞吐量大化（单位时间内完成多少任务）胜于延迟（一个请求被响应的速度有多快，其中一个关键方面在于被评判的是哪个事务系统，因为我们希望响应速度尽可能快）。

大数据编程模型

你将会遇到的大数据编程模型的主要类型如下：

•大规模并行处理（MPP）数据库系统（ Massively parallel processing (MPP) database system ）：EMC的Greenplum和IBM的Netezza就是该系统的例子。

•内存中数据库系统（ In-memory database systems ）：例子包括Oracle Exalytics和SAP HANA。

•MapReduce系统（ MapReduce systems ）：这些系统包括Hadoop，它是所有大数据系统中最通用的。

•批量同步并行（BSP）系统（ Bulk synchronous parallel (BSP) systems ）：例子包括Apache HAMA和Apache Giraph（t.dbdao.com）。

大规模并行处理（MPP）数据库系统

MPP系统的核心是基于包含在一列或一组列中的值采用某种形式的分割数据。例如，前面例子中计算按国家排序的 2000年的销售额，我们可以按国家对数据进行分区，所以某些节点会包含某些国家的数据。这种分区方法使得每个节点来计算2000年的总销售额。

该系统的限制是显而易见的。你需要在设计时确定数据如何分割。选择的分割标准常常受底层用例驱动。因此，它不适合于 临时 查询。某些查询 能够以极快的速度执行，因为他们能利用数据是如何在节点间拆分的。其他查询执行速度很慢，因为数据不是以它被访问以执行查询时一致的方式分布，导致所需的数据被通过网络传输到各节点（t.dbdao.com）。

为了解决这一限制，这些系统通常多次存储数据，按不同的标准拆分。根据查询，选择适当的数据集。

以下是MPP编程模型符合前面所定义的大数据系统属性的方式（思考销售额按国家排序的例子）：

数据按国家被拆分到不同节点上。 每个节点包含所有用来处理其数据子集必要的应用程序库。 每个节点本地读取数据到自身。当你运用不考虑数据是如何分布的查询时例外;在这种情况下，每一个任务需要通过网络从其它节点提取其自己的数据。 对于每个任务，数据按顺序读取。所有的销售数据都是共同定位并从磁盘提前。在内存中运用过滤（year =2000）。 内存数据库系统

从操作的角度来看，内存数据库系统与MPP系统相同。实现的不同之处在于，每个节点都有大量内存，且大部分数据被预加载到内存中。SAP HANA按照这一原则运行。其他系统，如Oracle Exalytics，使用专门的硬件以确保多台主机被安置在一个单一设备上。内存数据库本质上就像一个带SQL接口的内存MPP数据库（t.dbdao.com）。

内存数据库商业实现的主要缺点之一是，存在大量硬件和软件锁定。此外，由于该系统使用专有和专用硬件，通常价格昂贵。内存数据库尝试使用商品硬件可以快速增加集群的容量。举个例子，一个具有25GB RAM的商用服务器。试图承载1 TB 的in-memory数据库需要40多个主机（考虑到需要在服务器上执行的其他活动）。 1 TB并不算太大，并且我们已经是一个多达40节点的集群。

下面介绍内存数据库的编程模型是如何满足我们前面定义的大数据系统的属性：

在前面的示例中数据被按国家拆分。每个节点将数据加载到内存中。 每个节点包含所有处理其子集必要的应用程序库。 每个节点本地读取数据到其节点上。当你运用不考虑数据是如何分布的查询时例外;在这种情况下，每一个任务需要从其它节点提取其自己的数据。 由于数据缓存在内存中，只有当数据首次被读入内存中时，连续数据读取属性才适用。 MapReduce系统

MapReduce是本书所依据的范例。它是四种方法中迄今为止最通用的。MapReduce的Hadoop实现的一些重要特征有以下几方面：

它使用商业规模硬件。注意商业规模并不意味着笔记本或台式机。节点仍是企业规模，但它们使用最普通的组件（t.dbdao.com）。 数据并不需要基于任何预定义的标准在不同节点间进行分区。 用户只需要定义两个单独进程：map 和reduce。

本书中我们将广泛讨论MapReduce。在一个非常高的级别，MapReduce系统需要用户定义一个map 进程和一个reduce进程。当Hadoop被用于实现MapReduce，数据通常分布在64 MB-128 MB的块中，且每个块被复制两次（Hadoop中默认复制因子为3）。在计算2000年的销售额并按国家排序的例子中，整个销售数据作为块（大小为64 MB-128 MB）被加载到Hadoop分布式文件系统中（HDFS）。当MapReduce进程启动时，系统首先将所有应用程序库（包括用户定义的map和reduce进程）传输到每个节点。

每个节点都会调度map任务从包含销售数据文件中扫描块。每个Mapper（各个节点上的）将读取块的记录，并筛选出2000年的记录。然后每个Mapper输出一个包含键/值对的记录。如果销售记录是2000年的，则 Key 代表国家， value 代表给定记录中的销售数量。

最后，可配置数量的Reducer接收来自每个Mapper的键/值对。键将被分配给特定的Reducer，以确保给定键是被一个且唯一一个Reducer接收的。然后每个Reducer对所有接收到的键/值对的销售值数量进行合计。Reducer接收的数据格式是键（状态）和该键（2000年的销售记录）的值列表。输出被写回到HDFS。客户端将其从HDFS读出后，按国家对结果进行排序。最后一步可委托给Reducer，因为Reducer按排序顺序接收分配给它的键。但在该例中，我们需要将Reducer的数量限制为一个来实现这一点。由于Mappers 和Reducers之间的通信产生网络I / O，可能会导致瓶颈出现。本书后面我们将会详细讨论这个问题。

这就是MapReduce编程模型是如何满足前面定义的大数据系统的属性的：

数据被拆分到HDFS的大块中。由于HDFS是分布式文件系统，数据块以冗余的方式分布在所有节点上。 应用程序库，包括map 和reduce应用程序代码，被传播到所有任务节点上。 每个节点本地读取数据到其节点上。所有节点上的Mapper被启动，并本地读取数据块到自身（大多数情况下，任务和磁盘块之间的映射由scheduler负责，其可分配远程块到map任务以保持所有节点均工作）。 对于大块上的每个任务，数据在同一时间被顺序读取（块的大小通常为64 MB-128 MB）

MapReduce范例的重要限制之一是，它不适合于迭代算法。绝大多数数据科学算法本质上都是迭代的，并最终收敛于一个解决方案。当被应用于这种算法时，MapReduce范例要求每个迭代作为单独的MapReduce任务运行，且每次迭代常常使用由它的前一迭代产生的数据。但因为每个MapReduce任务从永久存储中读取新鲜数据，迭代需要将其结果存储在永久存储中以供下一次迭代使用。该过程产生不必要的I/ O，并对整体的吞吐量有显著影响。这一限制被系统的BSP类解决了，接下来将会介绍（t.dbdao.com）。

海量同步并行（BSP）系统

系统的BSP类的运行方式与MapReduce方法非常类似。然而，MapReduce任务在其处理周期结束时终止，这点BSP不一样，BSP系统由一个屏障（barrier）上同步的进程列表（等同于map进程）组成，将数据发送到主节点，交换相关信息。一旦迭代完成，主节点将指示每个处理节点恢复下一次迭代。

在一个屏障上同步是并行编程中的一个常用概念。当许多线程负责执行各自的任务时使用，但在继续进行之前需要达成一个检查点。在决定有关计算的其余部分是继续进行还是中止之前（并行或者按顺序），所有线程需要完成一个达到某一点的任务时需要这种模式。现实世界进程中总是使用同步屏蔽。例如，在一辆车到来之前，拼车的同伴经常在指定地点碰面。整个进程的速度仅仅和到达屏障的最后一个人（或线程）一样快。

BSP执行方法允许每个类似map进程缓存其先前迭代的数据，显著提高了整个进程的吞吐量。在本书的数据科学章节我们将会讨论BSP系统。它们与迭代算法相关。

大数据和事务性系统

在大数据背景下了解事务的概念是如何演变的非常重要。该讨论与NoSQL数据库相关。Hadoop拥有HBase作为其NoSQL数据存储。或者，你可以使用云中可用的Cassandra或NoSQL系统，如Amazon Dynamo。

虽然大多数RDBMS用户对数据库中的ACID属性充满期待，这些属性是有代价的。当底层数据库在高峰期需要处理每秒百万次的事务时，遵守最纯粹形式的ACID特性是极具挑战性的。

注意  ACID 是 atomicity, consistency, isolation, 和 durability 的缩写。详细讨论可参考以下链接： http://en.wikipedia.org/wiki/ACID 。

有些让步是必须的，且这些让步背后的动机隐含在所谓的CAP定理中（也称为Brewer’s theorem）。 CAP是下列词的缩写：

一致性 : 所有节点始终看到相同的数据副本。 可用性 ：保证每个请求在合理和明确的时间间隔内接收有关成功和失败的响应（t.dbdao.com）。 部分容忍 ：尽管部分失败，系统继续运行。

该定理还证明，在任何系统中，前述特征中只有两个可以实现，并不是所有。现在，我们一起来看看不同类型的系统：

• 一致和可用 ：一个带ACID属性的RDBMS就是一致和可用系统的一个例子。它不是分区容错;如果RDBMS出现故障，用户无法访问数据。

• 一致和部分容忍 : 一个集群RDBMS就属于这种系统。分布式事务确保所有用户总是看到相同的数据（一致性），数据的分布特性确保尽管节点损失，该系统仍然可用。然而由于分布式事务，当二阶段确认被发布，系统将在持续时间内不可用。这限制了可被系统所支持的并发事务的数量，反过来又限制了系统的可用性。

•可用性和部分容忍 ：被列为“最终一致性”的系统类型就属于这一类。考虑一个非常受欢迎的电子商务网站，如Amazon.com。假设你正在浏览产品目录，并注意到某个物品有两件可供出售。根据购买流程的性质，你明白在你注意到有一定数量的物品可供购买和发出购买请求之间，可能有人会抢先购买了此物品。因此始终显示最新值几乎不可能，因为库存在不断变化。库存的变化将传播到服务于用户的所有节点上。当该传播发生时，为了提供库存的最新值而阻止用户浏览库存将限制该网站的可用性，导致销售遭受损失。因此，我们牺牲一致性换取可用性，分区容错允许多个节点显示相同的数据（尽管可能只有很短的时间内每个用户能够看到不同的数据，这取决于服务于他们的节点）。

开发大数据系统时，这些决策是非常关键的。作为本书主要议题的MapReduce只是大数据生态系统的一个组成部分。它通常存在于其他产品如HBase的背景下，其中本节所讨论的权衡取舍对于开发一个好的解决方案至关重要。

我们的规模能有多大？

本章前面例子中我们作了几个假设。例如，我们忽略了CPU时间。对于大量的业务问题，计算复杂性并不是最重要的。然而，随着计算能力的增长，从实现的角度来看，各域变得更为实用。一个例子是使用复杂的Bayesia统计技术的数据挖掘。这些问题计算起来确实代价很大。对于这些问题，我们需要增加节点的数目来进行处理，或运用其他替代方法。

注意 大数据计算中使用的范例，如MapReduce，也已经被扩展到其他并行计算方法。例如，通用图形处理器（GPGPU）计算实现了对于计算密集型问题的大规模并行（t.dbdao.com）。

我们还忽略了网络I / O成本。使用50个计算节点来处理数据还需要使用一个分布式文件系统以及从集群中的50个节点中收集数据的通信成本。在所有的大数据解决方案中，I / O成本占据主导地位。这些成本引入了计算过程中的顺序依赖。

一个计算密集型例子

考虑用50个节点处理200 GB的数据，其中每个节点处理位于本地磁盘上4 GB的数据。每个节点需要80秒来读数据（以每秒50 MB的速率）。无论我们计算地多快，也不能在80秒内完成。假设该进程的结果是一个大小为200 MB的总数据集，且每个节点生成该结果中的4 MB，通过1 Gbps的（每数据包1 MB）网络传输到单个节点上用于显示。这将需要大约3毫秒（每1 MB需要250微秒来通过网络传送，且每个数据包将数据传送到目的地节点的网络延迟假定为500微秒（基于先前引用的Jeff Dean博士的谈话）。忽略计算成本，总处理时间不可能少于40.003秒。

现在，假设我们有4000个节点，每个节点神奇般地从本地磁盘读取其500 MB的数据，并生成0.1 MB的结果集。注意，如果数据以50 MB的块被读取我们的速度不能超过1秒。这转化为约4000倍的大程度的性能提升。换言之，对于某一类问题，如果它需要4000小时来完成处理，我们就不可能比用1个小时做得更好，无论在该问题上投入多少个节点。 4000倍可能听起来很多，但至于我们可以达到多快的速度，有一个上限。在该简化例子中，我们做了很多简化系统的假设。我们还假设在应用程序逻辑中不存在顺序依赖，这通常是一个错误假设。一旦我们增加了这些成本，大性能增益可能大幅下降。

顺序依赖，是所有并行计算算法的克星，它限制了性能提升的程度。该限制众所周知，并被记录为Amdhal定律（t.dbdao.com）。

Amdhal定律

正如光速定义着我们在宇宙中旅行速度的理论极限，Amdhal定律定义着我们通过增加更多节点到集群可以实现的性能提升的极限。

注意 有关 amdhal’s Law的完整讨论， 参见http://en.wikipedia.org/wiki/Amdahl’s_law 。

总而言之，定律指出如果一个给定解决方案可与比例P（其中P的取值范围为0 〜1 ）完全并行，对于无限数量节点（说明集群上很多节点的一种方式），我们能获得的大性能提升为1 /（ 1 -P）。因此，如果我们有1 ％的执行无法做出，可以获得的并行最佳提升为100倍。所有的程序都有一定的顺序依赖，磁盘I / O和网络I / O将增加更多。无论我们使用什么方法，对于能够实现多大提升还是有限制的。

大数据的业务用例

大数据和Hadoop在商业世界中有多个应用程序。人们通常认为大数据的三大属性为：

容量 速度  种类

容量是指所处理数据的大小。如果你的组织每晚需要在2小时内提取、加载和转换2 TB的数据，你将面临容量问题（t.dbdao.com）。

速度 是指大数据到达的速度。企业如Facebook和Twitter，都遇到了速度问题。他们每秒都会获得大量必须立即处理的微小消息，发布到社交媒体网站，传播到相关用户（家人，朋友和追随者），生成事件等等。

种类 是指越来越多的需要被处理的格式。企业搜索系统在组织中已经司空见惯。开源软件，如Apache Solr，使得搜索系统无处不在。大多数非结构化数据并不独立，具有与它相关联的大量结构化数据。例如，思考一个简单的文档，如电子邮件。电子邮件拥有大量与它相关的元数据，例如包括：发件人，收信人，收信人指令，发送/接收时间，有关发件人/收信人的组织信息（如发送时的标题），等等。

这些信息中有一些甚至是动态的。例如，如果你要分析好几年的电子邮件（法律实践领域有几个关于这方面的用例），电子邮件首次发送时知道发件人或收信人的头衔非常重要。动态主数据的这一特征是很常见的，并产生一些有趣的挑战。

大数据可帮助解决日常问题，如通过使用商品软件和硬件大规模的提取、转换、加载（ETL）事项。尤其是开源Hadoop，它在商用服务器上运行，并且可通过增加更多节点来扩展，使得ETL（或ELT，如它在大数据领域通常被称作的那样）以商业成本执行得更快。

一些围绕Hadoop和HDFS的开源产品已经发展到支持速度和各种用例。新数据格式已经发展到能够管理围绕大规模数据处理的I / O性能。本书将讨论这些发展背后的动机以及针对他们的适当的用例。

Storm（从Twitter发展而来）和Apache Flume（专门针对大规模的日志分析）发展来处理速度因素。选择使用哪个软件取决于该进程需要离“实时”有多近。Storm对于解决需要“更加实时”处理的问题比Flume有用。

关键信息是：大数据是一个各种产品协同工作以解决非常复杂的业务问题的生态系统。Hadoop往往是这些解决方案的核心。了解Hadoop使你能够深入理解如何使用大数据生态系统中的其他新产品（t.dbdao.com）。

小结

现在大数据已经成为主流，而其背后的两个主要驱动因素是开源Hadoop软件和云计算的出现。这两种发展使得人们大规模地采用大数据方法以较低的成本处理业务问题。Hadoop是所有大数据解决方案的基石。虽然其他编程模型，如MPP和BSP，也纷纷涌现以处理非常具体的问题，但当要处理的数据规模达到TB级规模时，它们都以某种或其他形式依赖于Hadoop。深入理解Hadoop使得其他编程模型的用户使用起来更有效。本书的目的正是使你实现这一点。

接下来的一章将指导你有关使用Hadoop软件的细节，提供用Hadoop解决问题的实用方法