Stay foolish,Stay hungry

1 数据流

1.1 读取文件数据的剖析

为了知道客户端与HDFS，NameNode,DataNode交互过程中数据的流向，请看图3-2，这张图显示了读取文件过程中主要的事件顺序。
客户端通过调用FileSystem对象的open()方法打开一个希望从中读取数据的文件，对于HDFS来说，FileSystem是一个DistributedFileSystem的实例对象(图3-2 步骤1)。DistributedFileSystem远程调用名称节点(NameNode)得到文件开头几个块的位置。对于每一个块，名称节点返回包含这个块复本的所有数据节点(DataNode)的地址。进一步，这些数据节点会根据集群的网络拓扑结构按照距离客户端的远近进行排序。如果客户端本身是一个数据节点(例如一个MapReduce任务)，而这个数据节点包含要读取的块的复本，则客户端会直接从本地读取。

DistributedFileSystem返回一个FSDataInputStream对象给客户端，用于从文件中读取数据。FSDataInputStream是一个输入流，支持文件寻位(seek)。FSDataInputStream里包装了一个DFSInputStream类，这个类支持数据节点和名称节点的I/O操作。

客户端调用read()方法从流中读取数据。DFSInputStream存储了文件中开头几个块所在的数据节点的地址。首先连接第一个块所在的最近的数据节点，数据从数据节点被读取到客户端，然后不断地从这个流中读取(步骤4)直接这个块数据被读完，然后DFSInputStream将会关闭到这个数据节点的连接，寻找下一个块所在的最近的数据节点(步骤5)。这一系列操作对客户端来说是透明的，它不用管。从客户端的角度来看，它仅仅是在读取一个连续的数据流。

当数据量增大到超出了单个物理计算机存储容量时，有必要把它分开存储在多个不同的计算机中。那些管理存储在多个网络互连的计算机中的文件系统被称为“分布式文件系统”。由于这些计算机是基于网络连接的，所以网络编程的那些复杂性都会涉及，这也造成了分布式文件系统比一般的磁盘存储文件系统更复杂。例如，其中最大的一个难题是如何使文件系统因其中一个节点失败而不造成数据丢失。

Hadoop使用的分布式文件系统称为HDFS，即Hadoop Distributed Filesystem。在非正式或早期文档或配置文件中见到DFS也指的是HDFS。HDFS是Hadoop最重要的文件系统，是这章节要讲的核心。但是Hadoop实际上具有通用文件系统抽象层，所以我们也顺便看一下Hadoop如何与其它存储系统集成，例如本地文件系统和Amazon S3。

1 HDFS的设计

设计HDFS的目的是为了能够存储非常大体积的文件，这些文件能够以流的方式访问，并能够运行于一般日常用的硬件设备集群中。让我们更详细地说明一下这句话的意思。

1.1 非常大体积的文件

这里的”非常大”意思是文件的大小是几百M，几百G或者几百T。今天的运行的Hadoop集群能够存储P级数据。

1.2 流式数据访问

HDFS认为一次写入，多次读取的模式是最高效的处理模式，它围绕着这个模式建立。数据集通常都是自生成或从源数据复制，然后随着时间推移会进行多次分析。每次分析可能不是所有数据，但也会是占数据集很大比例的数据，所以读取整个数据集所花的时间比读取第一条数据延迟的时间更重要。

MapReduce是一个数据处理的编程模型。这个模型很简单，但也不是简单到不能够支持一些有用的语言。Hadoop能够运行以多种语言写成的MapReduce程序。在这一章中，我们将看看怎样用Java,Ruby,Python语言来写同一个例子。更重要的是，MapReduce程序天生并发运行，这就相当于把能够进行大数据分析的工具交到了某个拥有足够多机器的人手里。

##气候数据集
在我们的例子中，将会写一个程序来挖掘天气数据。天气传感器每一个小时都会在全球的许多地方收集数据，并且也收集了大量的日志数据。这些数据非常适合于用MapReduce分析。因为我们想要处理所有数据，并且这些数据是半结构化的和面向记录的。

###数据格式
我们所使用的数据来自于国家气候数据中心或称为NCDC。数据以行形式ASCII格式存储，每一行一条记录。这种格式支持丰富的气象属性集合，其中许多属性是可选的，长度可变的。简便起见，我们仅仅关注基本的属性，如温度。温度总是有值并且长度固定。