導讀：

第一章：初識Hadoop

第二章：更高效的WordCount

第三章：把別處的資料搞到Hadoop上

第四章：把Hadoop上的資料搞到別處去

第五章：快一點吧，我的SQL

第六章：一夫多妻制

第七章：越來越多的分析任務

第八章：我的資料要實時

第九章：我的資料要對外

第十章：牛逼高大上的機器學習

經常有初學者會問，自己想往大資料方向發展，該學哪些技術，學習路線是什麼樣的，覺得大資料很火，就業很好，薪資很高……首先，如果你確定了想往這個方面發展，先考慮自己的過去從業經歷、專業、興趣是什麼。計算機專業——作業系統、硬體、網路、伺服器？軟體專業——軟體開發、程式設計、寫程式碼？還是數學、統計學專業——對資料和數字特別感興趣？

 

很多初學者，對大資料的概念都是模糊不清的，大資料是什麼，能做什麼，學的時候，該按照什麼線路去學習，學完往哪方面發展，想深入瞭解，想學習的同學歡迎加入大資料學習qq群：199427210，有大量乾貨（零基礎以及進階的經典實戰）分享給大家，並且有清華大學畢業的資深大資料講師給大家免費授課，給大家分享目前國內最完整的大資料高階實戰實用學習流程體系
 

其實這就是想告訴你大資料的三個發展方向，平臺搭建/優化/運維/監控、大資料開發/設計/架構、資料分析/挖掘。

先扯一下大資料的4V特徵：

資料量大，TB->PB
資料型別繁多，結構化、非結構化文字、日誌、視訊、圖片、地理位置等；
商業價值高，但是這種價值需要在海量資料之上，通過資料分析與機器學習更快速的挖掘出來；
處理時效性高，海量資料的處理需求不再侷限在離線計算當中。
現如今，正式為了應對大資料的這幾個特點，開源的大資料框架越來越多，越來越強，先列舉一些常見的：

檔案儲存：Hadoop HDFS、Tachyon、KFS

離線計算：Hadoop MapReduce、Spark

流式、實時計算：Storm、Spark Streaming、S4、Heron

K-V、NOSQL資料庫：HBase、Redis、MongoDB

資源管理：YARN、Mesos

日誌收集：Flume、Scribe、Logstash、Kibana

訊息系統：Kafka、StormMQ、ZeroMQ、RabbitMQ

查詢分析：Hive、Impala、Pig、Presto、Phoenix、SparkSQL、Drill、Flink、Kylin、Druid

分散式協調服務：Zookeeper

叢集管理與監控：Ambari、Ganglia、Nagios、Cloudera Manager

資料探勘、機器學習：Mahout、Spark MLLib

資料同步：Sqoop

任務排程：Oozie

······

第一章：初識Hadoop
1.1 學會百度與Google

不論遇到什麼問題，先試試搜尋並自己解決。

Google首選，翻不過去的，就用百度吧。

1.2 參考資料首選官方文件

特別是對於入門來說，官方文件永遠是首選文件。

相信搞這塊的大多是文化人，英文湊合就行，實在看不下去的，請參考第一步。

1.3 先讓Hadoop跑起來

Hadoop可以算是大資料儲存和計算的開山鼻祖，現在大多開源的大資料框架都依賴Hadoop或者與它能很好的相容。

關於Hadoop,你至少需要搞清楚以下是什麼：

Hadoop 1.0、Hadoop 2.0
MapReduce、HDFS
NameNode、DataNode
JobTracker、TaskTracker
Yarn、ResourceManager、NodeManager
自己搭建Hadoop，請使用第一步和第二步，能讓它跑起來就行。

建議先使用安裝包命令列安裝，不要使用管理工具安裝。

另外：Hadoop1.0知道它就行了，現在都用Hadoop 2.0.

1.4 嘗試使用Hadoop

HDFS目錄操作命令；
上傳、下載檔案命令；
提交執行MapReduce示例程式；
開啟Hadoop WEB介面，檢視Job執行狀態，檢視Job執行日誌。
知道Hadoop的系統日誌在哪裡。
1.5瞭解它們的原理

MapReduce：如何分而治之；

HDFS：資料到底在哪裡，什麼是副本；

Yarn到底是什麼，它能幹什麼；

NameNode到底在幹些什麼；

ResourceManager到底在幹些什麼；

1.6 自己寫一個MapReduce程式

仿照WordCount例子，自己寫一個（照抄也行）WordCount程式，

打包並提交到Hadoop執行。

不會Java的話，Shell、Python都可以，有個東西叫Hadoop Streaming。

如果能認真完成了以上幾步，恭喜你，你的一隻腳已經進來了。

第二章：更高效的WordCount
2.1 學點SQL吧

如果不懂資料庫的童鞋先學習使用SQL句。

2.2 SQL版WordCount

在1.6中，你寫（或者抄）的WordCount一共有幾行程式碼？

如果用SQL的話：

SELECT word,COUNT(1) FROM wordcount GROUP BY word;
這便是SQL的魅力，程式設計需要幾十行，甚至上百行程式碼，SQL一句就搞定；使用SQL處理分析Hadoop上的資料，方便、高效、易上手、更是趨勢。不論是離線計算還是實時計算，越來越多的大資料處理框架都在積極提供SQL介面。

2.3 安裝配置Hive

Hive算是資料倉庫工具，安裝不難，網上有很多教程，配置完成後，可以正常進入Hive命令列。

2.4 試試使用Hive

嘗試在Hive中建立wordcount表，並執行2.2中的SQL語句。在Hadoop WEB介面中找到剛才執行的SQL任務。看SQL查詢結果是否和1.4中MapReduce中的結果一致。

明明寫的是SQL，為什麼Hadoop WEB介面中看到的是MapReduce任務？

2.5 學會Hive的基本命令

建立、刪除表；載入資料到表；下載Hive表的資料；並學習更多關於Hive的語法和命令。

以上如果按照第一章和第二章的流程認真完整的走了一遍後，應該已經具備以下技能和知識點：

0和Hadoop2.0的區別

MapReduce的原理（還是那個經典的題目，一個10G大小的檔案，給定1G大小的記憶體，如何使用Java程式統計出現次數最多的10個單詞及次數）；

HDFS讀寫資料的流程；向HDFS中PUT資料；從HDFS中下載資料；

自己會寫簡單的MapReduce程式，執行出現問題，知道在哪裡檢視日誌；

會寫簡單的SELECT、WHERE、GROUP BY等SQL語句；

Hive SQL轉換成MapReduce的大致流程；

Hive中常見的語句：建立表、刪除表、往表中載入資料、分割槽、將表中資料下載到本地；

從上面的學習，你已經瞭解到，HDFS是Hadoop提供的分散式儲存框架，它可以用來儲存海量資料，MapReduce是Hadoop提供的分散式計算框架，它可以用來統計和分析HDFS上的海量資料，而Hive則是SQL On Hadoop，Hive提供了SQL介面，開發人員只需要編寫簡單易上手的SQL語句，Hive負責把SQL翻譯成MapReduce，提交執行。

此時，你的認知中“大資料平臺”是這樣的：

那麼問題來了，海量資料如何到HDFS上呢？

第三章：把別處的資料搞到Hadoop上
此處也可以叫做資料採集，把各個資料來源的資料採集到Hadoop上。

3.1 HDFS PUT命令

put命令在實際環境中也比較常用，通常配合shell、python等指令碼語言來使用。建議需熟練掌握。

3.2 HDFS API

HDFS提供了寫資料的API，自己用程式語言將資料寫入HDFS，put命令本身也是使用API。

實際環境中一般自己較少編寫程式使用API來寫資料到HDFS，通常都是使用其他框架封裝好的方法。比如：Hive中的INSERT語句，Spark中的saveAsTextfile等。

可以嘗試瞭解原理，試著寫幾個Demo。

3.3 Sqoop

Sqoop是一個主要用於Hadoop/Hive與傳統關係型資料庫Oracle/MySQL/SQLServer等之間進行資料交換的開源框架。

就像Hive把SQL翻譯成MapReduce一樣，Sqoop把你指定的引數翻譯成MapReduce，提交到Hadoop執行，完成Hadoop與其他資料庫之間的資料交換。

自己下載和配置Sqoop（建議先使用Sqoop1，Sqoop2比較複雜）。

瞭解Sqoop常用的配置引數和方法。

使用Sqoop完成從MySQL同步資料到HDFS；

使用Sqoop完成從MySQL同步資料到Hive表；

PS：如果後續選型確定使用Sqoop作為資料交換工具，那麼建議熟練掌握，否則，瞭解和會用Demo即可。

3.4 Flume

Flume是一個分散式的海量日誌採集和傳輸框架，因為“採集和傳輸框架”，所以它並不適合關係型資料庫的資料採集和傳輸。Flume可以實時的從網路協議、訊息系統、檔案系統採集日誌，並傳輸到HDFS上。因此，如果你的業務有這些資料來源的資料，並且需要實時的採集，那麼就應該考慮使用Flume。

下載和配置Flume。使用Flume監控一個不斷追加資料的檔案，並將資料傳輸到HDFS；

PS：Flume的配置和使用較為複雜，如果你沒有足夠的興趣和耐心，可以先跳過Flume。

3.5 阿里開源的DataX

之所以介紹這個，是因為以前某公司客戶目前使用的Hadoop與關係型資料庫資料交換的工具，就是之前基於DataX開發的，個人感覺非常好用。現在DataX已經是3.0版本，支援很多資料來源。你也可以在其之上做二次開發。

PS：有興趣的可以研究和使用一下，對比一下它與Sqoop。

至此，你的“大資料平臺”應該是這樣的：

第四章：把Hadoop上的資料搞到別處去
前面介紹瞭如何把資料來源的資料採集到Hadoop上，資料到Hadoop上之後，便可以使用Hive和MapReduce進行分析了。那麼接下來的問題是，分析完的結果如何從Hadoop上同步到其他系統和應用中去呢？

其實此處的方法和第三章基本一致的。

4.1 HDFS GET命令

把HDFS上的檔案GET到本地。需要熟練掌握。

4.2 HDFS API

原理同3.2.

4.3 Sqoop

原理同3.3。

使用Sqoop完成將HDFS上的檔案同步到MySQL；

使用Sqoop完成將Hive表中的資料同步到MySQL；

4.4 DataX

原理同3.4

此時，“你的大資料平臺”應該是這樣的：

走完第三章和第四章的流程，那麼你應該已經具備以下技能和知識點：

知道如何把已有的資料採集到HDFS上，包括離線採集和實時採集；
知道sqoop（或者還有DataX）是HDFS和其他資料來源之間的資料交換工具；
知道flume可以用作實時的日誌採集；
至此，對於大資料平臺，應該已經掌握如何搭建Hadoop叢集，把資料採集到Hadoop上，使用Hive和MapReduce來分析資料，把分析結果同步到其他資料來源。

接下來的問題就是，Hive使用的越來越多，你會發現很多不愉快的地方，特別是速度慢，

大多情況下，明明我的資料量很小，它都要申請資源，啟動MapReduce來執行。

第五章：快一點吧，我的SQL
其實大家都已經發現Hive後臺使用MapReduce作為執行引擎，實在是有點慢。因此SQL On Hadoop的框架越來越多，按我的瞭解，最常用的按照流行度依次為SparkSQL、Impala和Presto.這三種框架基於半記憶體或者全記憶體，提供了SQL介面來快速查詢分析Hadoop上的資料。

目前我們的方案使用的是SparkSQL，至於為什麼用SparkSQL，原因大概如下：

使用Spark還做了其他事情，不想引入過多的框架；
Impala對記憶體的需求太大，沒有過多資源部署；
5.1 關於Spark和SparkSQL

什麼是Spark，什麼是SparkSQL。

Spark有的核心概念及名詞解釋。

SparkSQL和Spark是什麼關係，SparkSQL和Hive是什麼關係。

SparkSQL為什麼比Hive跑的快。

可參考：SparkSQL與Hive on Spark的比較

5.2 如何部署和執行SparkSQL

Spark有哪些部署模式？

如何在Yarn上執行SparkSQL？

使用SparkSQL查詢Hive中的表。

可參考：Spark – lxw的大資料田地

PS: Spark不是一門短時間內就能掌握的技術，因此建議在瞭解了Spark之後，可以先從SparkSQL入手，循序漸進。

如果認真完成了上面的學習和實踐，此時，你的”大資料平臺”應該是這樣的：

第六章：一夫多妻制
其實我想說的是資料的一次採集、多次消費。

在實際業務場景下，特別是對於一些監控日誌，想即時的從日誌中瞭解一些指標（關於實時計算，後面章節會有介紹），這時候，從HDFS上分析就太慢了，儘管是通過Flume採集的，但Flume也不能間隔很短就往HDFS上滾動檔案，這樣會導致小檔案特別多。

為了滿足資料的一次採集、多次消費的需求，這裡要說的便是Kafka。

6.1 關於Kafka

Kafka是一種高吞吐量的分散式釋出訂閱訊息系統，它可以處理消費者規模的網站中的所有動作流資料。這種動作（網頁瀏覽，搜尋和其他使用者的行動）是在現代網路上的許多社會功能的一個關鍵因素。這些資料通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。

6.2 如何部署和使用Kafka

使用單機部署Kafka，併成功執行自帶的生產者和消費者例子。

使用Java程式自己編寫並執行生產者和消費者程式。

Flume和Kafka的整合，使用Flume監控日誌，並將日誌資料實時傳送至Kafka。

關於Kafka，可以參考 ：Kafka – lxw的大資料田地

至此，“大資料平臺”應該擴充成這樣：

這時，使用Flume採集的資料，不是直接到HDFS上，而是先到Kafka，Kafka中的資料可以由多個消費者同時消費，其中一個消費者，就是將資料同步到HDFS。

總結：

為什麼Spark比MapReduce快。

使用SparkSQL代替Hive，更快的執行SQL。

使用Kafka完成資料的一次收集，多次消費架構。

自己可以寫程式完成Kafka的生產者和消費者。

前面的學習已經掌握了大資料平臺中的資料採集、資料儲存和計算、資料交換等大部分技能，而這其中的每一步，都需要一個任務（程式）來完成，各個任務之間又存在一定的依賴性，比如，必須等資料採集任務成功完成後，資料計算任務才能開始執行。如果一個任務執行失敗，需要給開發運維人員傳送告警，同時需要提供完整的日誌來方便查錯。

第七章：越來越多的分析任務
不僅僅是分析任務，資料採集、資料交換同樣是一個個的任務。這些任務中，有的是定時觸發，有點則需要依賴其他任務來觸發。當平臺中有幾百上千個任務需要維護和執行時候，僅僅靠crontab遠遠不夠了，這時便需要一個排程監控系統來完成這件事。排程監控系統是整個資料平臺的中樞系統，類似於AppMaster，負責分配和監控任務。

7.1 Apache Oozie

1. Oozie是什麼？有哪些功能？

2. Oozie可以排程哪些型別的任務（程式）？

3. Oozie可以支援哪些任務觸發方式？

4.安裝配置Oozie。

7.2 其他開源的任務排程系統

Azkaban

light-task-scheduler

alibaba/zeus

……

此時：

第八章：資料要實時
在第六章介紹Kafka的時候提到了一些需要實時指標的業務場景，實時基本可以分為絕對實時和準實時，絕對實時的延遲要求一般在毫秒級，準實時的延遲要求一般在秒、分鐘級。對於需要絕對實時的業務場景，用的比較多的是Storm，對於其他準實時的業務場景，可以是Storm，也可以是Spark Streaming。當然，如果可以的話，也可以自己寫程式來做。

8.1 Storm

1. 什麼是Storm？有哪些可能的應用場景？

2. Storm由哪些核心元件構成，各自擔任什麼角色？

3. Storm的簡單安裝和部署。

4. 自己編寫Demo程式，使用Storm完成實時資料流計算。

8.2 Spark Streaming

1. 什麼是Spark Streaming，它和Spark是什麼關係？

2. Spark Streaming和Storm比較，各有什麼優缺點？

3. 使用Kafka + Spark Streaming，完成實時計算的Demo程式。

此時：

至此，大資料平臺底層架構已經成型了，其中包括了資料採集、資料儲存與計算（離線和實時）、資料同步、任務排程與監控這幾大模組。接下來是時候考慮如何更好的對外提供資料了。

第九章：資料要對外
通常對外（業務）提供資料訪問，大體上包含以下方面：

離線：比如，每天將前一天的資料提供到指定的資料來源（DB、FILE、FTP）等；

離線資料的提供可以採用Sqoop、DataX等離線資料交換工具。

實時：比如，線上網站的推薦系統，需要實時從資料平臺中獲取給使用者的推薦資料，這種要求延時非常低（50毫秒以內）。

根據延時要求和實時資料的查詢需要，可能的方案有：HBase、Redis、MongoDB、ElasticSearch等。

OLAP分析：OLAP除了要求底層的資料模型比較規範，另外，對查詢的響應速度要求也越來越高，可能的方案有：Impala、Presto、SparkSQL、Kylin。如果你的資料模型比較規模，那麼Kylin是最好的選擇。

即席查詢：即席查詢的資料比較隨意，一般很難建立通用的資料模型，因此可能的方案有：Impala、Presto、SparkSQL。

這麼多比較成熟的框架和方案，需要結合自己的業務需求及資料平臺技術架構，選擇合適的。原則只有一個：越簡單越穩定的，就是最好的。

如果你已經掌握瞭如何很好的對外（業務）提供資料，那麼你的“大資料平臺”應該是這樣的：

第十章：牛逼高大上的機器學習
這裡本人也沒有接觸太多，稍微講一下我們的業務場景應用，遇到的能用機器學習解決的問題大概這麼三類：

分類問題：包括二分類和多分類，二分類就是解決了預測的問題，就像預測一封郵件是否垃圾郵件；多分類解決的是文字的分類；

聚類問題：從使用者搜尋過的關鍵詞，對使用者進行大概的歸類。

推薦問題：根據使用者的歷史瀏覽和點選行為進行相關推薦。

大多數行業，使用機器學習解決的，也就是這幾類問題。

入門學習線路：

數學基礎；

機器學習實戰（Machine Learning in Action），懂Python最好；

SparkMlLib提供了一些封裝好的演算法，以及特徵處理、特徵選擇的方法。

那麼把機器學習部分加進 “大資料