不少人都知道大數據很火，就業很好，薪資很高，想往大數據方向發展。但該學哪些技術，學習路線是什麼樣的呢？ 其實就是想告訴你的大數據的三個發展方向，平臺搭建/優化/運維/監控、大數據開發/設計/架構、數據分析/挖掘。請不要問我哪一個好學，哪一個錢多。html
先說一下大數據的4V特徵：python
數據量大，TB->PBios
數據類型繁多，結構化、非結構化文本、日誌、視頻、圖片、地理位置等；git
商業價值高，可是這種價值須要在海量數據之上，經過數據分析與機器學習更快速的挖掘出來；github
處理時效性高，海量數據的處理需求再也不侷限在離線計算當中。算法
現現在，正式爲了應對大數據的這幾個特色，開源的大數據框架愈來愈多，愈來愈強，再列舉一些常見的：shell
文件存儲：Hadoop HDFS、Tachyon、KFS數據庫
離線計算：Hadoop MapReduce、Spark編程
流式、實時計算：Storm、Spark Streaming、S四、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
……
眼花了吧，上面的有30多種吧，別說精通了，所有都會使用的，估計也沒幾個。
推薦一個大數據學習羣 142974151天天晚上20:10都有一節【免費的】大數據直播課程，專一大數據分析方法,大數據編程，大數據倉庫，大數據案例，人工智能,數據挖掘都是純乾貨分享，
推薦第二個方向（開發/設計/架構），由於這個方向容易找工做，下面給你們具體講解一下。
第一章：初識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嗎？
若是不會，請學點SQL吧。
2.2 SQL版WordCount
在1.6中，你寫（或者抄）的WordCount一共有幾行代碼？
給你看看個人:
SELECT word,COUNT(1) FROM wordcount GROUP BY word;
這即是SQL的魅力，編程須要幾十行，甚至上百行代碼，我這一句就搞定；使用SQL處理分析Hadoop上的數據，方便、高效、易上手、更是趨勢。不管是離線計算仍是實時計算，愈來愈多的大數據處理框架都在積極提供SQL接口。
2.3 SQL On Hadoop之Hive
什麼是Hive？官方給的解釋是：
The Apache Hive data warehouse software facilitates reading, writing, and managing large datasets residing in distributed storage and queried using SQL syntax.
爲何說Hive是數據倉庫工具，而不是數據庫工具呢？有的朋友可能不知道數據倉庫，數據倉庫是邏輯上的概念，底層使用的是數據庫，數據倉庫中的數據有這兩個特色：最全的歷史數據（海量）、相對穩定的；所謂相對穩定，指的是數據倉庫不一樣於業務系統數據庫，數據常常會被更新，數據一旦進入數據倉庫，不多會被更新和刪除，只會被大量查詢。而Hive，也是具有這兩個特色，所以，Hive適合作海量數據的數據倉庫工具，而不是數據庫工具。
2.4 安裝配置Hive
請參考1.1和 1.2 完成Hive的安裝配置。能夠正常進入Hive命令行。
2.5 試試使用Hive
請參考1.1和 1.2 ，在Hive中建立wordcount表，並運行2.2中的SQL語句。
在Hadoop WEB界面中找到剛纔運行的SQL任務。
看SQL查詢結果是否和1.4中MapReduce中的結果一致。
2.6 Hive是怎麼工做的
明明寫的是SQL，爲何Hadoop WEB界面中看到的是MapReduce任務？
2.7 學會Hive的基本命令
建立、刪除表；
加載數據到表；
下載Hive表的數據；
請參考1.2，學習更多關於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.5.
你應該已經具有如下技能和知識點：
知道如何把已有的數據採集到HDFS上，包括離線採集和實時採集；
你已經知道sqoop（或者還有DataX）是HDFS和其餘數據源之間的數據交換工具；
你已經知道flume能夠用做實時的日誌採集。
從前面的學習，對於大數據平臺，你已經掌握的很多的知識和技能，搭建Hadoop集羣，把數據採集到Hadoop上，使用Hive和MapReduce來分析數據，把分析結果同步到其餘數據源。
接下來的問題來了，Hive使用的愈來愈多，你會發現不少不爽的地方，特別是速度慢，大多狀況下，明明個人數據量很小，它都要申請資源，啓動MapReduce來執行。
第五章：快一點吧，個人SQL
其實你們都已經發現Hive後臺使用MapReduce做爲執行引擎，實在是有點慢。
所以SQL On Hadoop的框架愈來愈多，按個人瞭解，最經常使用的按照流行度依次爲SparkSQL、Impala和Presto.
這三種框架基於半內存或者全內存，提供了SQL接口來快速查詢分析Hadoop上的數據。關於三者的比較，請參考1.1.
咱們目前使用的是SparkSQL，至於爲何用SparkSQL，緣由大概有如下吧：
使用Spark還作了其餘事情，不想引入過多的框架；
Impala對內存的需求太大，沒有過多資源部署；
5.1 關於Spark和SparkSQL
什麼是Spark，什麼是SparkSQL。
Spark有的核心概念及名詞解釋。
SparkSQL和Spark是什麼關係，SparkSQL和Hive是什麼關係。
SparkSQL爲何比Hive跑的快。
5.2 如何部署和運行SparkSQL
Spark有哪些部署模式？
如何在Yarn上運行SparkSQL？
使用SparkSQL查詢Hive中的表。
PS: Spark不是一門短期內就能掌握的技術，所以建議在瞭解了Spark以後，能夠先從SparkSQL入手，按部就班。
第六章：一夫多妻制
請不要被這個名字所誘惑。其實我想說的是數據的一次採集、屢次消費。
在實際業務場景下，特別是對於一些監控日誌，想即時的從日誌中瞭解一些指標（關於實時計算，後面章節會有介紹），這時候，從HDFS上分析就太慢了，儘管是經過Flume採集的，但Flume也不能間隔很短就往HDFS上滾動文件，這樣會致使小文件特別多。
爲了知足數據的一次採集、屢次消費的需求，這裏要說的即是Kafka。
6.1 關於Kafka
什麼是Kafka？
Kafka的核心概念及名詞解釋。
6.2 如何部署和使用Kafka
使用單機部署Kafka，併成功運行自帶的生產者和消費者例子。
使用Java程序本身編寫並運行生產者和消費者程序。
Flume和Kafka的集成，使用Flume監控日誌，並將日誌數據實時發送至Kafka。
這時，使用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：
https://github.com/ltsopensource/light-task-scheduler
Zeus：
https://github.com/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提供了一些封裝好的算法，以及特徵處理、特徵選擇的方法。固然，你若是想更快掌握大數據，能夠了解大數據培訓相關課程，不會讓你失望的。
