個々の公共の番号でこの記事の発信元：TechFlow
過去2年間のAIは、主要な大学や専門学校は、プロの人工知能を開始している、最もホットな分野の代名詞となっています。しかし、実際には、人工知能や深い学習や機械学習のちょうど最初の2年間は、言及する価値がある、基礎となるデータのサポートから不可分です。TBレベルのデータへの心の数十のために、従来のデータベースが要件を満たすことができないことは明らかです。今日、我々はビッグデータ--Hadoopの時代の陰の英雄を見てみましょう。
Hadoopのは、2つの意味があり、実際に、それは実際に単にコンピューティングシステムに分散されていることをいう最も早いキーワード。しかし、時代の進展とともに、Hadoopのシステムは、すでに技術の完全な家族になるHadoopの今、展開します。その後、ランデータ解析ツール（ハイブ、豚）の先頭に分散ファイルシステム（HDFS）の下、および分散システム連携サービス（ZooKeeperの）と分散データベース（HBaseの）から、ほぼ半分覆い、Hadoopののファミリーに属しますビッグデータシナリオ。スパークが普及していない前に、中小企業の多くは、まだありますが、今でも、Hadoopのビッグデータアプリケーションの絶対的な主流となって、あるいは大規模なデータシステムを構築するためのHadoopに依存していました。
今日では、Hadoopの大家族が、初期のHadoopの構造は非常に単純ですが、ほとんど唯一の2は、一方が他方にはMapReduceのアルゴリズムであり、全体のデータをサポートすることです分散ファイルシステム、です。
分散ファイルシステム
頻繁TBあるいはPB計でビッグデータの時代、データの大規模な成長の大きさは、。私たちは、従来の方法を使用している場合、このようなデータの膨大な量のために、非常に困難です。すべてのデータが再び通過してもO（n）のアルゴリズムので、消費時間は明らかに容認できないとする、時間に確かにあります。膨大なデータサイズがデータベースの搬送容量を超えるとまた、データサイズのMySQLのようなそのようなデータベースは、制限され、それはほとんどのシステム・レベルのために悪夢である（重要なデータを破棄することはできないが、今システムがサポートすることができません） 。
既然我们把数据全部存储在一起，会导致系统问题，那么我们可不可以把数据分成很多份分别存储，当我们需要处理这些数据的时候，我们对这些分成许多小份的数据分别处理，最后再合并在一起？
答案当然是可行的，Hadoop的文件系统正是基于这个思路。
在HDFS当中，将数据分割成一个一个的小份。每个小份叫做一个存储块，每个存储块为64MB。这样一个巨大的文件会被打散存储在许多存储块当中。当我们需要操作这些数据的时候，Hadoop会同时起动许多个执行器（executor）来并发执行这些存储块。理论上来说，执行器的数量越多，执行的速度也就越快。只要我们有足够多的执行器，就可以在短时间内完成海量数据的计算工作。
但是有一个小问题，为什么每个存储块偏偏是64MB，而不是128MB或者256MB呢？
原因也很简单，因为数据存储在硬盘上，当我们查找数据的时候，CPU其实是不知道数据究竟存放在什么地方的。需要有一个专门的程序去查找数据的位置，这个过程被称为寻址。寻址的时候会伴随着硬盘的高速旋转。硬盘的旋转速度是有限的，自然我们查找文件的速度也会存在瓶颈。如果存储块太小，那么存储块的数量就会很多，我们寻址的时间就会变长。
如果存储块设置得大一些行不行？也不行，因为我们在执行的时候，需要把存储块的数据拷贝到执行器的内存里执行。这个拷贝伴随着读写和网络传输的操作，传输数据同样耗时不少。存储块过大，会导致读写的时间过长，同样不利于系统的性能。根据业内的说法，希望寻址的耗时占传输时间的1%，目前的网络带宽最多可以做到100MB/s，根据计算，每个存储块大约在100MB左右最佳。也许是程序员为了凑整，所以选了64MB这个大小。
目前为止，我们已经搞清楚了Hadoop内部的数据存储的原理。那么，Hadoop又是怎么并发计算的呢？这就下一个关键词——MapReduce出场了。
MapReduce
严格说起来MapReduce并不是一种算法， 而是一个计算思想。它由map和reduce两个阶段组成。
先说map，MapReduce中的map和Java或者是C++以及一些其他语言的map容器不同，它表示的意思是映射。负责执行map操作的机器（称作mapper）从HDFS当中拿到数据之后，会对这些数据进行处理，从其中提取出我们需要用到的字段或者数据，将它组织成key->value的结构，进行返回。
为什么要返回key->value的结构呢？直接返回我们要用到的value不行吗？
不行，因为在map和reduce中间，Hadoop会根据key值进行排序，将key值相同的数据归并到一起之后，再发送给reducer执行。也就是说，key值相同的数据会被同一个reducer也就是同一台机器处理，并且key相同的数据连续排列。reducer做的是通过mapper拿到的数据，生成我们最终需要的结果。
Sample
这个过程应该不难理解， 但是初学者可能面临困惑，为什么一开始的时候，要处理成key-value结构的呢？为什么又要将key值相同的数据放入一个reducer当中呢，这么做有什么意义？
这里，我们举一个例子，就清楚了。
MapReduce有一个经典的问题，叫做wordCount，顾名思义就是给定一堆文本，最后计算出文本当中每个单词分别出现的次数。Map阶段很简单，我们遍历文本当中的单词，每遇到一个单词，就输出单词和数字1。写成代码非常简单：
def map(text): for line in text: words = line.split(' ') for w in words: print(w, 1)
这样当然还是不够的，我们还需要把相同的单词聚合起来，清点一下看看究竟出现了多少次，这个时候就需要用到reducer了。reducer也很简单，我们读入的是map输出的结果。由于key相同的数据都会进入同一个reducer当中，所以我们不需要担心遗漏，只需要直接统计就行：
def reduce(text): wordNow = None totCount = 0 for line in text: elements = line.split(' ') word, count = elements[0], int(elements[1]) # 碰到不同的key，则输出之前的单词以及数量 if word != wordNow: if wordNow is not None: print(wordNow, totCount) wordNow = word totCount = 1 #否则，更新totCount else: totCount += count
如果我们map的结果不是key-value结构，那么Hadoop就没办法根据key进行排序，并将key相同的数据归并在一起。那么我们在reduce的时候，同一个单词就可能出现在不同的reducer当中，这样的结果显然是不正确的。
当然，如果我们只做一些简单的操作，也可以舍弃reduce阶段，只保留map产出的结果。
现在看MapReduce的思想其实并不复杂，但是当年大数据还未兴起的时候，MapReduce横空出世，既提升了计算性能，又保证了结果的准确。一举解决了大规模数据并行计算的问题，回想起来，应该非常惊艳。虽然如今技术更新，尤其是Spark的流行，抢走了Hadoop许多荣光。但MapReduce的思想依旧在许多领域广泛使用，比如Python就支持类似的MapReduce操作，允许用户自定义map和reduce函数，对数据进行并行处理。
不过，MapReduce也有短板，比如像是数据库表join的操作通过MapReduce就很难实现。而且相比于后来的Hive以及Spark SQL来说，MapReduce的编码复杂度还是要大一些。但不管怎么说，瑕不掩瑜，对于初学者而言，它依旧非常值得我们深入了解。
扫码关注，获取更多文章：
