Hadoop读写文件时内部工作机制是怎样的

网上有关“Hadoop读写文件时内部工作机制是怎样的”话题很是火热，小编也是针对Hadoop读写文件时内部工作机制是怎样的寻找了一些与之相关的一些信息进行分析，如果能碰巧解决你现在面临的问题，希望能够帮助到您。

客户端通过调用FileSystem对象（对应于HDFS文件系统，调用DistributedFileSystem对象）的open()方法来打开文件（也即图中的第一步），DistributedFileSystem通过RPC（Remote Procedure Call）调用询问NameNode来得到此文件最开始几个block的文件位置（第二步）。对每一个block来说，namenode返回拥有此block备份的所有namenode的地址信息（按集群的拓扑网络中与客户端距离的远近排序，关于在Hadoop集群中如何进行网络拓扑请看下面介绍）。如果客户端本身就是一个datanode（如客户端是一个mapreduce任务）并且此datanode本身就有所需文件block的话，客户端便从本地读取文件。

以上步骤完成后，DistributedFileSystem会返回一个FSDataInputStream（支持文件seek），客户端可以从FSDataInputStream中读取数据。FSDataInputStream包装了一个DFSInputSteam类，用来处理namenode和datanode的I/O操作。

客户端然后执行read()方法（第三步），DFSInputStream（已经存储了欲读取文件的开始几个block的位置信息）连接到第一个datanode（也即最近的datanode）来获取数据。通过重复调用read()方法（第四、第五步），文件内的数据就被流式的送到了客户端。当读到该block的末尾时，DFSInputStream就会关闭指向该block的流，转而找到下一个block的位置信息然后重复调用read()方法继续对该block的流式读取。这些过程对于用户来说都是透明的，在用户看来这就是不间断的流式读取整个文件。

当真个文件读取完毕时，客户端调用FSDataInputSteam中的close（）方法关闭文件输入流（第六步）。

如果在读某个block是DFSInputStream检测到错误，DFSInputSteam就会连接下一个datanode以获取此block的其他备份，同时他会记录下以前检测到的坏掉的datanode以免以后再无用的重复读取该datanode。DFSInputSteam也会检查从datanode读取来的数据的校验和，如果发现有数据损坏，它会把坏掉的block报告给namenode同时重新读取其他datanode上的其他block备份。

这种设计模式的一个好处是，文件读取是遍布这个集群的datanode的，namenode只是提供文件block的位置信息，这些信息所需的带宽是很少的，这样便有效的避免了单点瓶颈问题从而可以更大的扩充集群的规模。

Hadoop中的网络拓扑

在Hadoop集群中如何衡量两个节点的远近呢？要知道，在高速处理数据时，数据处理速率的唯一限制因素就是数据在不同节点间的传输速度：这是由带宽的可怕匮乏引起的。所以我们把带宽作为衡量两个节点距离大小的标准。

但是计算两个节点之间的带宽是比较复杂的，而且它需要在一个静态的集群下才能衡量，但Hadoop集群一般是随着数据处理的规模动态变化的（且两两节点直接相连的连接数是节点数的平方）。于是Hadoop使用了一个简单的方法来衡量距离，它把集群内的网络表示成一个树结构，两个节点之间的距离就是他们离共同祖先节点的距离之和。树一般按数据中心(datacenter)，机架(rack)，计算节点(datanode)的结构组织。计算节点上的本地运算速度最快，跨数据中心的计算速度最慢（现在跨数据中心的Hadoop集群用的还很少，一般都是在一个数据中心内做运算的）。

假如有个计算节点n1处在数据中心c1的机架r1上，它可以表示为/c1/r1/n1，下面是不同情况下两个节点的距离：

distance(/d1/r1/n1, /d1/r1/n1) = 0 (processes on the same node)

distance(/d1/r1/n1, /d1/r1/n2) = 2 (different nodes on the same rack)

distance(/d1/r1/n1, /d1/r2/n3) = 4 (nodes on different racks in the same data center)

distance(/d1/r1/n1, /d2/r3/n4) = 6 (nodes in different data centers)

如下图所示：

Hadoop

写文件

现在我们来看一下Hadoop中的写文件机制解析，通过写文件机制我们可以更好的了解一下Hadoop中的一致性模型。

Hadoop

上图为我们展示了一个创建一个新文件并向其中写数据的例子。

首先客户端通过DistributedFileSystem上的create()方法指明一个欲创建的文件的文件名（第一步），DistributedFileSystem再通过RPC调用向NameNode申请创建一个新文件（第二步，这时该文件还没有分配相应的block）。namenode检查是否有同名文件存在以及用户是否有相应的创建权限，如果检查通过，namenode会为该文件创建一个新的记录，否则的话文件创建失败，客户端得到一个IOException异常。DistributedFileSystem返回一个FSDataOutputStream以供客户端写入数据，与FSDataInputStream类似，FSDataOutputStream封装了一个DFSOutputStream用于处理namenode与datanode之间的通信。

当客户端开始写数据时（第三步），DFSOutputStream把写入的数据分成包（packet）, 放入一个中间队列——数据队列（data queue）中去。DataStreamer从数据队列中取数据，同时向namenode申请一个新的block来存放它已经取得的数据。namenode选择一系列合适的datanode（个数由文件的replica数决定）构成一个管道线（pipeline），这里我们假设replica为3，所以管道线中就有三个datanode。DataSteamer把数据流式的写入到管道线中的第一个datanode中（第四步），第一个datanode再把接收到的数据转到第二个datanode中（第四步），以此类推。

DFSOutputStream同时也维护着另一个中间队列——确认队列（ack queue），确认队列中的包只有在得到管道线中所有的datanode的确认以后才会被移出确认队列（第五步）。

如果某个datanode在写数据的时候当掉了，下面这些对用户透明的步骤会被执行：

1）管道线关闭，所有确认队列上的数据会被挪到数据队列的首部重新发送，这样可以确保管道线中当掉的datanode下流的datanode不会因为当掉的datanode而丢失数据包。

2）在还在正常运行的datanode上的当前block上做一个标志，这样当当掉的datanode重新启动以后namenode就会知道该datanode上哪个block是刚才当机时残留下的局部损坏block，从而可以把它删掉。

3）已经当掉的datanode从管道线中被移除，未写完的block的其他数据继续被写入到其他两个还在正常运行的datanode中去，namenode知道这个block还处在under-replicated状态（也即备份数不足的状态）下，然后他会安排一个新的replica从而达到要求的备份数，后续的block写入方法同前面正常时候一样。

有可能管道线中的多个datanode当掉（虽然不太经常发生），但只要dfs.replication.min（默认为1）个replica被创建，我们就认为该创建成功了。剩余的replica会在以后异步创建以达到指定的replica数。

当客户端完成写数据后，它会调用close()方法（第六步）。这个操作会冲洗（flush）所有剩下的package到pipeline中，等待这些package确认成功，然后通知namenode写入文件成功（第七步）。这时候namenode就知道该文件由哪些block组成（因为DataStreamer向namenode请求分配新block，namenode当然会知道它分配过哪些blcok给给定文件），它会等待最少的replica数被创建，然后成功返回。

replica是如何分布的

Hadoop在创建新文件时是如何选择block的位置的呢，综合来说，要考虑以下因素：带宽（包括写带宽和读带宽）和数据安全性。如果我们把三个备份全部放在一个datanode上，虽然可以避免了写带宽的消耗，但几乎没有提供数据冗余带来的安全性，因为如果这个datanode当机，那么这个文件的所有数据就全部丢失了。另一个极端情况是，如果把三个冗余备份全部放在不同的机架，甚至数据中心里面，虽然这样数据会安全，但写数据会消耗很多的带宽。Hadoop 0.17.0给我们提供了一个默认replica分配策略（Hadoop 1.X以后允许replica策略是可插拔的，也就是你可以自己制定自己需要的replica分配策略）。replica的默认分配策略是把第一个备份放在与客户端相同的datanode上（如果客户端在集群外运行，就随机选取一个datanode来存放第一个replica），第二个replica放在与第一个replica不同机架的一个随机datanode上，第三个replica放在与第二个replica相同机架的随机datanode上。如果replica数大于三，则随后的replica在集群中随机存放，Hadoop会尽量避免过多的replica存放在同一个机架上。选取replica的放置位置后，管道线的网络拓扑结构如下所示：

Hadoop

总体来说，上述默认的replica分配策略给了我们很好的可用性（blocks放置在两个rack上，较为安全），写带宽优化（写数据只需要跨越一个rack），读带宽优化（你可以从两个机架中选择较近的一个读取）。

一致性模型

HDFS某些地方为了性能可能会不符合POSIX（是的，你没有看错，POSIX不仅仅只适用于linux/unix， Hadoop 使用了POSIX的设计来实现对文件系统文件流的读取 ），所以它看起来可能与你所期望的不同，要注意。

创建了一个文件以后，它是可以在命名空间（namespace）中可以看到的：

Path p = new Path("p");

fs.create(p);

assertThat(fs.exists(p), is(true));

但是任何向此文件中写入的数据并不能保证是可见的，即使你flush了已经写入的数据，此文件的长度可能仍然为零：

Path p = new Path("p");

OutputStream out = fs.create(p);

out.write("content".getBytes("UTF-8"));

out.flush();

assertThat(fs.getFileStatus(p).getLen(), is(0L));

这是因为，在Hadoop中，只有满一个block数据量的数据被写入文件后，此文件中的内容才是可见的（即这些数据会被写入到硬盘中去），所以当前正在写的block中的内容总是不可见的。

Hadoop提供了一种强制使buffer中的内容冲洗到datanode的方法，那就是FSDataOutputStream的sync()方法。调用了sync()方法后，Hadoop保证所有已经被写入的数据都被冲洗到了管道线中的datanode中，并且对所有读者都可见了：

Path p = new Path("p");

FSDataOutputStream out = fs.create(p);

out.write("content".getBytes("UTF-8"));

out.flush();

out.sync();

assertThat(fs.getFileStatus(p).getLen(), is(((long) "content".length())));

这个方法就像POSIX中的fsync系统调用（它冲洗给定文件描述符中的所有缓冲数据到磁盘中）。例如，使用java API写一个本地文件，我们可以保证在调用flush()和同步化后可以看到已写入的内容：

FileOutputStream out = new FileOutputStream(localFile);

out.write("content".getBytes("UTF-8"));

out.flush(); // flush to operating system

out.getFD().sync(); // sync to disk （getFD()返回与该流所对应的文件描述符）

assertThat(localFile.length(), is(((long) "content".length())));

在HDFS中关闭一个流隐式的调用了sync()方法：

Path p = new Path("p");

OutputStream out = fs.create(p);

out.write("content".getBytes("UTF-8"));

out.close();

assertThat(fs.getFileStatus(p).getLen(), is(((long) "content".length())));

由于Hadoop中的一致性模型限制，如果我们不调用sync()方法的话，我们很可能会丢失多大一个block的数据。这是难以接受的，所以我们应该使用sync()方法来确保数据已经写入磁盘。但频繁调用sync()方法也是不好的，因为会造成很多额外开销。我们可以再写入一定量数据后调用sync()方法一次，至于这个具体的数据量大小就要根据你的应用程序而定了，在不影响你的应用程序的性能的情况下，这个数据量应越大越好。

一文看懂大数据的技术生态圈

MapReduce从出现以来，已经成为Apache Hadoop计算范式的扛鼎之作。它对于符合其设计的各项工作堪称完美：大规模日志处理，ETL批处理操作等。

随着Hadoop使用范围的不断扩大，人们已经清楚知道MapReduce不是所有计算的最佳框架。Hadoop 2将资源管理器YARN作为自己的顶级组件，为其他计算引擎的接入提供了可能性。如Impala等非MapReduce架构的引入，使平台具备了支持交互式SQL的能力。

今天，Apache Spark是另一种这样的替代，并且被称为是超越MapReduce的通用计算范例。也许您会好奇：MapReduce一直以来已经这么有用了，怎么能突然被取代看毕竟，还有很多ETL这样的工作需要在Hadoop上进行，即使该平台目前也已经拥有其他实时功能。

值得庆幸的是，在Spark上重新实现MapReduce一样的计算是完全可能的。它们可以被更简单的维护，而且在某些情况下更快速，这要归功于Spark优化了刷写数据到磁盘的过程。Spark重新实现MapReduce编程范式不过是回归本源。Spark模仿了Scala的函数式编程风格和API。而MapReduce的想法来自于函数式编程语言LISP。

尽管Spark的主要抽象是RDD（弹性分布式数据集），实现了Map，reduce等操作，但这些都不是Hadoop的Mapper或Reducer API的直接模拟。这些转变也往往成为开发者从Mapper和Reducer类平行迁移到Spark的绊脚石。

与Scala或Spark中经典函数语言实现的map和reduce函数相比，原有Hadoop提供的Mapper和Reducer API 更灵活也更复杂。这些区别对于习惯了MapReduce的开发者而言也许并不明显，下列行为是针对Hadoop的实现而不是MapReduce的抽象概念：

· Mapper和Reducer总是使用键值对作为输入输出。

· 每个Reducer按照Key对Value进行reduce。

· 每个Mapper和Reducer对于每组输入可能产生0个，1个或多个键值对。

· Mapper和Reducer可能产生任意的keys和values，而不局限于输入的子集和变换。

Mapper和Reducer对象的生命周期可能横跨多个map和reduce操作。它们支持setup和cleanup方法，在批量记录处理开始之前和结束之后被调用。

本文将简要展示怎样在Spark中重现以上过程，您将发现不需要逐字翻译Mapper和Reducer！

作为元组的键值对

假定我们需要计算大文本中每一行的长度，并且报告每个长度的行数。在HadoopMapReduce中，我们首先使用一个Mapper，生成为以行的长度作为key，1作为value的键值对。

public class LineLengthMapper extends

Mapper<LongWritable, Text, IntWritable, IntWritable> {

@Override

protected void map(LongWritable lineNumber, Text line, Context context)

throws IOException, InterruptedException {

context.write(new IntWritable(line.getLength()), new IntWritable(1));

}

}

值得注意的是Mappers和Reducers只对键值对进行操作。所以由TextInputFormat提供输入给LineLengthMapper，实际上也是以文本中位置为key（很少这么用，但是总是需要有东西作为Key），文本行为值的键值对。

与之对应的Spark实现：

lines.map(line => (line.length, 1))

Spark中，输入只是String构成的RDD，而不是key-value键值对。Spark中对key-value键值对的表示是一个Scala的元组，用(A，B)这样的语法来创建。上面的map操作的结果是(Int，Int)元组的RDD。当一个RDD包含很多元组，它获得了多个方法，如reduceByKey，这对再现MapReduce行为将是至关重要的。

Reduce

reduce()与reduceBykey()

统计行的长度的键值对，需要在Reducer中对每种长度作为key，计算其行数的总和作为value。

public class LineLengthReducer extends

Reducer<IntWritable, IntWritable, IntWritable, IntWritable> {

@Override

protected void reduce(IntWritable length, Iterable<IntWritable> counts,

Context context) throws IOException, InterruptedException {

int sum = 0;

for (IntWritable count : counts) {

sum += count.get();

}

context.write(length, new IntWritable(sum));

}

}

Spark中与上述Mapper，Reducer对应的实现只要一行代码：

val lengthCounts = lines.map(line => (line.length, 1)).reduceByKey(_ + _)

Spark的RDD API有个reduce方法，但是它会将所有key-value键值对reduce为单个value。这并不是Hadoop MapReduce的行为，Spark中与之对应的是ReduceByKey。

另外，Reducer的Reduce方法接收多值流，并产生0，1或多个结果。而reduceByKey，它接受的是一个将两个值转化为一个值的函数，在这里，就是把两个数字映射到它们的和的简单加法函数。此关联函数可以被调用者用来reduce多个值到一个值。与Reducer方法相比，他是一个根据Key来Reduce Value的更简单而更精确的API。

Mapper

map() 与 flatMap()

现在，考虑一个统计以大写字母开头的单词的个数的算法。对于每行输入文本，Mapper可能产生0个，1个或多个键值对。

public class CountUppercaseMapper extends

Mapper<LongWritable, Text, Text, IntWritable> {

@Override

protected void map(LongWritable lineNumber, Text line, Context context)

throws IOException, InterruptedException {

for (String word : line.toString().split(" ")) {

if (Character.isUpperCase(word.charAt(0))) {

context.write(new Text(word), new IntWritable(1));

}

}

}

}

Spark对应的写法：

lines.flatMap(

_.split(" ").filter(word => Character.isUpperCase(word(0))).map(word => (word,1))

)

简单的Spark map函数不适用于这种场景，因为map对于每个输入只能产生单个输出，但这个例子中一行需要产生多个输出。所以，和MapperAPI支持的相比，Spark的map函数语义更简单，应用范围更窄。

Spark的解决方案是首先将每行映射为一组输出值，这组值可能为空值或多值。随后会通过flatMap函数被扁平化。数组中的词会被过滤并被转化为函数中的元组。这个例子中，真正模仿Mapper行为的是flatMap，而不是map。

groupByKey()

写一个统计次数的reducer是简单的，在Spark中，reduceByKey可以被用来统计每个单词的总数。比如出于某种原因要求输出文件中每个单词都要显示为大写字母和其数量，在MapReduce中，实现如下：

public class CountUppercaseReducer extends

Reducer<Text, IntWritable, Text, IntWritable> {

@Override

protected void reduce(Text word, Iterable<IntWritable> counts, Context context)

throws IOException, InterruptedException {

int sum = 0;

for (IntWritable count : counts) {

sum += count.get();

}

context

.write(new Text(word.toString().toUpperCase()), new IntWritable(sum));

}

}

但是redeceByKey不能单独在Spark中工作，因为他保留了原来的key。为了在Spark中模拟，我们需要一些更像Reducer API的操作。我们知道Reducer的reduce方法接受一个key和一组值，然后完成一组转换。groupByKey和一个连续的map操作能够达到这样的目标:

groupByKey().map { case (word,ones) => (word.toUpperCase, ones.sum) }

groupByKey只是将某一个key的所有值收集在一起，并且不提供reduce功能。以此为基础，任何转换都可以作用在key和一系列值上。此处，将key转变为大写字母，将values直接求和。

setup()和cleanup()

在MapReduce中，Mapper和Reducer可以声明一个setup方法，在处理输入之前执行，来进行分配数据库连接等昂贵资源，同时可以用cleanup函数可以释放资源。

public class SetupCleanupMapper extends

Mapper<LongWritable, Text, Text, IntWritable> {

private Connection dbConnection;

@Override

protected void setup(Context context) {

dbConnection = ...;

}

...

@Override

protected void cleanup(Context context) {

dbConnection.close();

}

}

Spark中的map和flatMap方法每次只能在一个input上操作，而且没有提供在转换大批值前后执行代码的方法，看起来，似乎可以直接将setup和cleanup代码放在Sparkmap函数调用之前和之后：

val dbConnection = ...

lines.map(... dbConnection.createStatement(...) ...)

dbConnection.close() // Wrong!

然而这种方法却不可行，原因在于：

· 它将对象dbConnection放在map函数的闭包中，这需要他是可序列化的（比如，通过java.io.Serializable实现）。而数据库连接这种对象一般不能被序列化。

· map是一种转换，而不是操作，并且拖延执行。连接对象不能被及时关闭。

· 即便如此，它也只能关闭driver上的连接，而不是释放被序列化拷贝版本分配的资源连接。

事实上，map和flatMap都不是Spark中Mapper的最接近的对应函数，Spark中Mapper的最接近的对应函数是十分重要的mapPartitions()方法，这个方法能够不仅完成单值对单值的映射，也能完成一组值对另一组值的映射，很像一个批映射（bulkmap）方法。这意味着mapPartitions()方法能够在开始时从本地分配资源，并在批映射结束时释放资源。

添加setup方法是简单的，添加cleanup会更困难，这是由于检测转换完成仍然是困难的。例如，这样是能工作的：

lines.mapPartitions { valueIterator =>

val dbConnection = ... // OK

val transformedIterator = valueIterator.map(... dbConnection ...)

dbConnection.close() // Still wrong! May not have evaluated iterator

transformedIterator

}

一个完整的范式应该看起来类似于：

lines.mapPartitions { valueIterator =>

if (valueIterator.isEmpty) {

Iterator[...]()

} else {

val dbConnection = ...

valueIterator.map { item =>

val transformedItem = ...

if (!valueIterator.hasNext) {

dbConnection.close()

}

transformedItem

}

}

}

虽然后者代码翻译注定不如前者优雅，但它确实能够完成工作。

flatMapPartitions方法并不存在，然而，可以通过调用mapPartitions，后面跟一个flatMap(a= > a)的调用达到同样效果。

带有setup和cleanup的Reducer对应只需仿照上述代码使用groupByKey后面跟一个mapPartition函数。

别急，等一下，还有更多

MapReduce的开发者会指出，还有更多的还没有被提及的API：

· MapReduce支持一种特殊类型的Reducer，也称为Combiner，可以从Mapper中减少洗牌(shuffled)数据大小。

· 它还支持同通过Partitioner实现的自定义分区，和通过分组Comparator实现的自定义分组。

· Context对象授予Counter API的访问权限以及它的累积统计。

· Reducer在其生命周期内一直能看到已排序好的key 。

· MapReduce有自己的Writable序列化方案。

· Mapper和Reducer可以一次发射多组输出。

· MapReduce有几十个调优参数。

有很多方法可以在Spark中实现这些方案，使用类似Accumulator的API，类似groupBy和在不同的这些方法中加入partitioner参数的方法，Java或Kryo序列化，缓存和更多。由于篇幅限制，在这篇文章中就不再累赘介绍了。

需要指出的是，MapReduce的概念仍然有用。只不过现在有了一个更强大的实现，并利用函数式语言，更好地匹配其功能性。理解Spark RDD API和原来的Mapper和ReducerAPI之间的差异，可以帮助开发者更好地理解所有这些函数的工作原理，以及理解如何利用Spark发挥其优势。

一文看懂大数据的技术生态圈

大数据本身是个很宽泛的概念，Hadoop生态圈（或者泛生态圈）基本上都是为了处理超过单机尺度的数据处理而诞生的。你可以把它比作一个厨房所以需要的各种工具。锅碗瓢盆，各有各的用处，互相之间又有重合。你可以用汤锅直接当碗吃饭喝汤，你可以用小刀或者刨子去皮。但是每个工具有自己的特性，虽然奇怪的组合也能工作，但是未必是最佳选择。

大数据，首先你要能存的下大数据。传统的文件系统是单机的，不能横跨不同的机器。HDFS（Hadoop Distributed FileSystem）的设计本质上是为了大量的数据能横跨成百上千台机器，但是你看到的是一个文件系统而不是很多文件系统。比如你说我要获取/hdfs/tmp/file1的数据，你引用的是一个文件路径，但是实际的数据存放在很多不同的机器上。你作为用户，不需要知道这些，就好比在单机上你不关心文件分散在什么磁道什么扇区一样。HDFS为你管理这些数据。存的下数据之后，你就开始考虑怎么处理数据。虽然HDFS可以为你整体管理不同机器上的数据，但是这些数据太大了。一台机器读取成T上P的数据（很大的数据哦，比如整个东京热有史以来所有高清**的大小甚至更大），一台机器慢慢跑也许需要好几天甚至好几周。对于很多公司来说，单机处理是不可忍受的，比如微博要更新24小时热博，它必须在24小时之内跑完这些处理。那么我如果要用很多台机器处理，我就面临了如何分配工作，如果一台机器挂了如何重新启动相应的任务，机器之间如何互相通信交换数据以完成复杂的计算等等。这就是MapReduce / Tez / Spark的功能。MapReduce是第一代计算引擎，Tez和Spark是第二代。MapReduce的设计，采用了很简化的计算模型，只有Map和Reduce两个计算过程（中间用Shuffle串联），用这个模型，已经可以处理大数据领域很大一部分问题了。那什么是Map什么是Reduce？考虑如果你要统计一个巨大的文本文件存储在类似HDFS上，你想要知道这个文本里各个词的出现频率。你启动了一个MapReduce程序。Map阶段，几百台机器同时读取这个文件的各个部分，分别把各自读到的部分分别统计出词频，产生类似（hello, 12100次），（world，15214次）等等这样的Pair（我这里把Map和Combine放在一起说以便简化）；这几百台机器各自都产生了如上的集合，然后又有几百台机器启动Reduce处理。Reducer机器A将从Mapper机器收到所有以A开头的统计结果，机器B将收到B开头的词汇统计结果（当然实际上不会真的以字母开头做依据，而是用函数产生Hash值以避免数据串化。因为类似X开头的词肯定比其他要少得多，而你不希望数据处理各个机器的工作量相差悬殊）。然后这些Reducer将再次汇总，（hello，12100）＋（hello，12311）＋（hello，345881）= （hello，370292）。每个Reducer都如上处理，你就得到了整个文件的词频结果。这看似是个很简单的模型，但很多算法都可以用这个模型描述了。Map＋Reduce的简单模型很黄很暴力，虽然好用，但是很笨重。第二代的Tez和Spark除了内存Cache之类的新feature，本质上来说，是让Map/Reduce模型更通用，让Map和Reduce之间的界限更模糊，数据交换更灵活，更少的磁盘读写，以便更方便地描述复杂算法，取得更高的吞吐量。有了MapReduce，Tez和Spark之后，程序员发现，MapReduce的程序写起来真麻烦。他们希望简化这个过程。这就好比你有了汇编语言，虽然你几乎什么都能干了，但是你还是觉得繁琐。你希望有个更高层更抽象的语言层来描述算法和数据处理流程。于是就有了Pig和Hive。Pig是接近脚本方式去描述MapReduce，Hive则用的是SQL。它们把脚本和SQL语言翻译成MapReduce程序，丢给计算引擎去计算，而你就从繁琐的MapReduce程序中解脱出来，用更简单更直观的语言去写程序了。有了Hive之后，人们发现SQL对比Java有巨大的优势。一个是它太容易写了。刚才词频的东西，用SQL描述就只有一两行，MapReduce写起来大约要几十上百行。而更重要的是，非计算机背景的用户终于感受到了爱：我也会写SQL！于是数据分析人员终于从乞求工程师帮忙的窘境解脱出来，工程师也从写奇怪的一次性的处理程序中解脱出来。大家都开心了。Hive逐渐成长成了大数据仓库的核心组件。甚至很多公司的流水线作业集完全是用SQL描述，因为易写易改，一看就懂，容易维护。自从数据分析人员开始用Hive分析数据之后，它们发现，Hive在MapReduce上跑，真鸡巴慢！流水线作业集也许没啥关系，比如24小时更新的推荐，反正24小时内跑完就算了。但是数据分析，人们总是希望能跑更快一些。比如我希望看过去一个小时内多少人在充气娃娃页面驻足，分别停留了多久，对于一个巨型网站海量数据下，这个处理过程也许要花几十分钟甚至很多小时。而这个分析也许只是你万里长征的第一步，你还要看多少人浏览了跳蛋多少人看了拉赫曼尼诺夫的CD，以便跟老板汇报，我们的用户是猥琐男闷骚女更多还是文艺青年／少女更多。你无法忍受等待的折磨，只能跟帅帅的工程师蝈蝈说，快，快，再快一点！于是Impala，Presto，Drill诞生了（当然还有无数非著名的交互SQL引擎，就不一一列举了）。三个系统的核心理念是，MapReduce引擎太慢，因为它太通用，太强壮，太保守，我们SQL需要更轻量，更激进地获取资源，更专门地对SQL做优化，而且不需要那么多容错性保证（因为系统出错了大不了重新启动任务，如果整个处理时间更短的话，比如几分钟之内）。这些系统让用户更快速地处理SQL任务，牺牲了通用性稳定性等特性。如果说MapReduce是大砍刀，砍啥都不怕，那上面三个就是剔骨刀，灵巧锋利，但是不能搞太大太硬的东西。这些系统，说实话，一直没有达到人们期望的流行度。因为这时候又两个异类被造出来了。他们是Hive on Tez / Spark和SparkSQL。它们的设计理念是，MapReduce慢，但是如果我用新一代通用计算引擎Tez或者Spark来跑SQL，那我就能跑的更快。而且用户不需要维护两套系统。这就好比如果你厨房小，人又懒，对吃的精细程度要求有限，那你可以买个电饭煲，能蒸能煲能烧，省了好多厨具。上面的介绍，基本就是一个数据仓库的构架了。底层HDFS，上面跑MapReduce／Tez／Spark，在上面跑Hive，Pig。或者HDFS上直接跑Impala，Drill，Presto。这解决了中低速数据处理的要求。那如果我要更高速的处理呢？如果我是一个类似微博的公司，我希望显示不是24小时热博，我想看一个不断变化的热播榜，更新延迟在一分钟之内，上面的手段都将无法胜任。于是又一种计算模型被开发出来，这就是Streaming（流）计算。Storm是最流行的流计算平台。流计算的思路是，如果要达到更实时的更新，我何不在数据流进来的时候就处理了？比如还是词频统计的例子，我的数据流是一个一个的词，我就让他们一边流过我就一边开始统计了。流计算很牛逼，基本无延迟，但是它的短处是，不灵活，你想要统计的东西必须预先知道，毕竟数据流过就没了，你没算的东西就无法补算了。因此它是个很好的东西，但是无法替代上面数据仓库和批处理系统。还有一个有些独立的模块是KV Store，比如Cassandra，HBase，MongoDB以及很多很多很多很多其他的（多到无法想象）。所以KV Store就是说，我有一堆键值，我能很快速滴获取与这个Key绑定的数据。比如我用身份证号，能取到你的身份数据。这个动作用MapReduce也能完成，但是很可能要扫描整个数据集。而KV Store专用来处理这个操作，所有存和取都专门为此优化了。从几个P的数据中查找一个身份证号，也许只要零点几秒。这让大数据公司的一些专门操作被大大优化了。比如我网页上有个根据订单号查找订单内容的页面，而整个网站的订单数量无法单机数据库存储，我就会考虑用KV Store来存。KV Store的理念是，基本无法处理复杂的计算，大多没法JOIN，也许没法聚合，没有强一致性保证（不同数据分布在不同机器上，你每次读取也许会读到不同的结果，也无法处理类似银行转账那样的强一致性要求的操作）。但是丫就是快。极快。每个不同的KV Store设计都有不同取舍，有些更快，有些容量更高，有些可以支持更复杂的操作。必有一款适合你。除此之外，还有一些更特制的系统／组件，比如Mahout是分布式机器学习库，Protobuf是数据交换的编码和库，ZooKeeper是高一致性的分布存取协同系统，等等。有了这么多乱七八糟的工具，都在同一个集群上运转，大家需要互相尊重有序工作。所以另外一个重要组件是，调度系统。现在最流行的是Yarn。你可以把他看作中央管理，好比你妈在厨房监工，哎，你妹妹切菜切完了，你可以把刀拿去杀鸡了。只要大家都服从你妈分配，那大家都能愉快滴烧菜。你可以认为，大数据生态圈就是一个厨房工具生态圈。为了做不同的菜，中国菜，日本菜，法国菜，你需要各种不同的工具。而且客人的需求正在复杂化，你的厨具不断被发明，也没有一个万用的厨具可以处理所有情况，因此它会变的越来越复杂。

以上是小编为大家分享的关于一文看懂大数据的技术生态圈的相关内容，更多信息可以关注环球青藤分享更多干货

关于“Hadoop读写文件时内部工作机制是怎样的”这个话题的介绍，今天小编就给大家分享完了，如果对你有所帮助请保持对本站的关注！