1 大資料啟蒙
1.1 分治思想
在認識分治思想之前，讓我們先來看這樣一個需求：
- 我有一萬個元素（比如數字或單詞）需要存儲，如果查找某一個元素，最簡單的周遊方式複雜度是多少呢？
- 更進一步，如果我期望的複雜度是O(4)呢？
對于第一個需求，我們很容易就能想到可以用數組或者是連結清單來存儲，這樣查找某一個元素的時間複雜度分别是O(logn)和O(n)：
那麼對于第二個需求，我們應該如何實作呢？
如果你有學過資料結構，那你一定很快就能想到可以用散清單這種結構來實作這個需求，使用2500個長度為4（抛開資料分布不平衡的因素）的連結清單來存儲這10000個元素，在查找的時候，首先通過hash值與2500取模定位到所在的連結清單數組，然後就能以O(4)的複雜度來查找這個元素了，如下圖所示：
上述案例中的散清單就展現出了一種分治思想，分而治之的思想非常重要，它被運用在了很多場景中，比如：
- Redis叢集
- ElasticSearch
- Hbase
- HaDoop生态
1.2 單機處理大資料問題
繼續來看這樣一個需求：
- 有一個非常大的文本檔案，裡面有很多很多的行，隻有兩行一樣，它們出現在未知的位置，需要查找到它們。
- 給定的硬體隻有一台單機，而且可用的記憶體很少，也就幾十兆。
現在我們來分析一下這個問題，假設這個檔案有1T大小，I/O速度是500MB每秒，那麼1T檔案讀取一遍需要約30分鐘，循環周遊（逐行兩兩比對）需要N次I/O時間（總共需要30 * N 分鐘），使用分治思想可以使時間為2次I/O（也就是1個小時左右）。
那麼如何利用分治思想呢？我這裡提供一種思路：可以計算每一行的hash值，然後對一個基數（比如2000）取模，将檔案散列成2000個小檔案塊（這些檔案塊小到可以放到記憶體裡），這樣會花費一次I/O，也就是30分鐘，我們可以知道的是，哈希運算和取模運算都是穩定的運算（兩個相同的值無論經過多少次運算，得到的結果總是一樣的），是以相同的兩行，它們的計算結果一定會相同，也就是說，它們一定會被散列到同一個檔案塊中，這樣再周遊每一個檔案塊（1次I/O）就能找到某個檔案塊中重複的兩行。
tips：記憶體尋址比I/O尋址快10萬倍。
現在讓我們來考慮另一個問題：如果1T的檔案中放的都是數值且都是亂序的，現在我們希望把這些數值做一次全排序，我們應該如何來實作呢？
我們都知道哈希這種運算是無序的，是以在這個需求中就不再适用了，這時我們可以使用另一種方式：讀取一行中的數值，如果它在某個標明的範圍内（假設是1~100），就将它發送到0号小檔案塊中，如果它在101~200之内，就将它發送到1号小檔案塊中...依此類推，直到檔案中的所有數值都被發送到一個個小的檔案塊中。這樣耗費一次I/O時間可以使得這些數值做到外部（檔案塊之間）有序，内部（某個檔案塊中）無序。這時如果我們切分的檔案塊足夠小，我們就可以将它放到記憶體中做一次排序，這樣就能使得數值在每個檔案塊中也是有序的，進而實作了使用兩次I/O完成了所有數值的全排序。
我們也可以先讀取一個小檔案塊大小（比如50M）的數值進行排序，這樣我們就能得到n多個内部有序，外部無序的小檔案塊，學過算法的同學都知道有一種算法可以用于外部排序——對，那就是歸并排序，是以我們可以使用歸并排序對這n多個小檔案塊進行排序，這樣也能使用兩次I/O完成數值的全排序。
如果你了解了上面的東西，讓我們再來做進一步思考：如果把時間變成分鐘、秒級，應該如何做到呢？很顯然在單機、硬體條件有限的情況下是絕無可能做到的，這也是單機在面臨大資料問題的瓶頸所在（記憶體大小、I/O速度），這個時候叢集分布式的優勢就展現出來了。
1.3 叢集分布式處理大資料的辯證思考
- 2000台機器真的比一台機器速度快嗎？
- 如果考慮分發上傳檔案的時間呢？
- 如果考慮每天都有1T資料的産生呢?
- 如果增量了一年，最後一天計算資料呢?
讓我們對上述問題進行逐一解答，首先2000台機器不一定比一台機器速度快，如果隻有1T的資料需要處理，那麼由于叢集分布式需要先将檔案分發上傳到2000台機器中，這個過程消耗的網卡I/O（網絡I/O比磁盤I/O速度還要慢）傳輸時間是非常多的，是以這種情況下并不能展現出叢集分布式的優勢。但是如果考慮每天都會有1T的資料産生，這些資料增量了一年，這個時候叢集分布式在處理這些資料的計算時的長處就能充分發揮出來了。在處理增量資料時，叢集分布式處理資料的時長并不會随着資料量的增長而有着明顯的增長，但是單機在資料量逐漸增長的情況下處理資料所耗費的時間會越來越多。資料量越大，叢集分布式的優勢就會越明顯。
1.4 結論
總而言之，從上述的分析我們可以得知，大資料技術關注的重心主要有下面幾點：
- 分而治之
- 并行計算
- 計算向資料移動
- 資料本地化讀取
2 Hadoop初識
2.1 Hadoop 之父 Doug Cutting
Doug Cutting是一位軟體設計師，也是 開源 搜尋技術的倡導者和創造者。他建立了 Lucene， 并與 Mike Cafarella 一起建立了 Nutch ，這兩個都是開源搜尋技術領域的項目，這些項目現在由 Apache Software Foundation 管理。Cutting和Cafarella也是 Apache Hadoop 的共同創始人。 -- 摘自 維基百科
- Hadoop的發音是 [hædu:p]
- Cutting兒子對玩具小象的昵稱
- Lucene
- Avro
- Hadoop
2.2 Hadoop的時間簡史
- 《The Google File System 》 2003年
- 《MapReduce: Simplified Data Processing on Large Clusters》 2004年
- 《Bigtable: A Distributed Storage System for Structured Data》 2006年
- Hadoop由 Apache Software Foundation 于 2005 年秋天作為Lucene的子項目Nutch的一部分正式引入。
- 2006 年 3 月份，Map/Reduce 和 Nutch Distributed File System (NDFS) 分别被納入稱為 Hadoop 的項目中。
- Cloudera公司在2008年開始提供基于Hadoop的軟體和服務。
- 2016年10月hadoop-2.6.5
- 2017年12月hadoop-3.0.0
- hadoop.apache.org
2.3 Hadoop項目/生态
Hadoop項目包含了這些子產品：
- Hadoop Common：給其他Hadoop子產品提供支撐的基礎功能類庫。
- Hadoop Distributed File System (HDFS™)：提供對應用程式資料的高吞吐量通路的分布式檔案系統。
- Hadoop YARN：作業排程和叢集資源管理架構。
- Hadoop MapReduce：基于YARN的大型資料集并行處理系統。
- Hadoop Ozone : Hadoop的對象存儲。
Apache中其他與Hadoop相關的項目包括：
- Ambari™ ：一個基于Web的工具，用于配置，管理和監控Hadoop叢集，其中包括對Hadoop HDFS，Hadoop MapReduce，Hive，HCatalog，HBase，ZooKeeper，Oozie，Pig和Sqoop的支援。
- Avro™ ：資料序列化系統。
- Cassandra™ ：可擴充的多主資料庫，沒有單點故障。
- Chukwa™ ：用于管理大型分布式系統的資料收集系統。
- HBase™ ：可擴充的分布式資料庫，支援大型表的結構化資料存儲。
- Hive™ ：提供資料彙總和即席查詢的資料倉庫基礎設施。
- Mahout™ : 可擴充的機器學習和資料挖掘庫。
- Pig™ ：用于并行計算的進階資料流語言和執行架構。
- Spark™ ：用于Hadoop資料的快速通用計算引擎。Spark提供了一種簡單而富有表現力的程式設計模型，該模型支援廣泛的應用程式，包括ETL，機器學習，流處理和圖形計算。
- Tez™ ：一個基于Hadoop YARN的通用資料流程式設計架構，該架構提供了強大而靈活的引擎來執行任意DAG任務，以處理批處理和互動用例的資料。Hadoop生态系統中的Hive™，Pig™和其他架構以及其他商業軟體（例如ETL工具）都采用了Tez，以取代Hadoop™MapReduce作為基礎執行引擎。
- ZooKeeper™ ：面向分布式應用程式的高性能協調服務。
2.4 大資料生态
Cloudera官網：
https://www.cloudera.com/Cloudera’s Distribution Including Apache Hadoop(CDH)是Apache Hadoop和相關項目中最完整的，經過測試的和最受歡迎的發行版。
- hadoop-2.6.0+cdh5.16.1
- hbase-1.2.0+cdh5.16.1
- hive-1.1.0+cdh5.16.1
- spark-1.6.0+cdh5.16.1