大數據須要學什麼？

注意本文非廣告，閱讀時間四分鐘左右，適合大數據入門級讀者閱讀

大數據須要學習什麼？不少人問過我這個問題。每一次回答完都以爲本身講得太片面了，老是沒有一個合適的契機去好好總結這些內容，直到開始寫這篇東西。大數據是近五年興起的行業，發展迅速，不少技術通過這些年的迭代也變得比較成熟了，同時新的東西也不斷涌現，想要保持本身競爭力的惟一辦法就是不斷學習。

思惟導圖

下面的是我整理的一張思惟導圖，內容分紅幾大塊，包括了分佈式計算與查詢，分佈式調度與管理，持久化存儲，大數據經常使用的編程語言等等內容，每一個大類下有不少的開源工具，這些就是做爲大數據程序猿又愛又恨折騰得死去活來的東西了。

大數據須要的語言

Java

java能夠說是大數據最基礎的編程語言，據我這些年的經驗，我接觸的很大一部分的大數據開發都是從Jave Web開發轉崗過來的（固然也不是絕對我甚至見過產品轉崗大數據開發的，逆了個天）。

• 一是由於大數據的本質無非就是海量數據的計算，查詢與存儲，後臺開發很容易接觸到大數據量存取的應用場景
• 二就是java語言本事了，自然的優點，由於大數據的組件不少都是用java開發的像HDFS,Yarn,Hbase,MR,Zookeeper等等，想要深刻學習，填上生產環境中踩到的各類坑，必須得先學會java而後去啃源碼。

說到啃源碼順便說一句，開始的時候確定是會很難，須要對組件自己和開發語言都有比較深刻的理解，熟能生巧慢慢來，等你過了這個階段，習慣了看源碼解決問題的時候你會發現源碼真香。

Scala

scala和java很類似都是在jvm運行的語言，在開發過程當中是能夠無縫互相調用的。Scala在大數據領域的影響力大部分都是來自社區中的明星Spark和kafka,這兩個東西你們應該都知道（後面我會有文章多維度介紹它們），它們的強勢發展直接帶動了Scala在這個領域的流行。

Python和Shell

shell應該不用過多的介紹很是的經常使用，屬於程序猿必備的通用技能。python更多的是用在數據挖掘領域以及寫一些複雜的且shell難以實現的平常腳本。

分佈式計算

什麼是分佈式計算？分佈式計算研究的是如何把一個須要很是巨大的計算能力才能解決的問題分紅許多小的部分，而後把這些部分分配給許多服務器進行處理，最後把這些計算結果綜合起來獲得最終的結果。

舉個栗子，就像是組長把一個大項目拆分，讓組員每一個人開發一部分，最後將全部人代碼merge，大項目完成。聽起來好像很簡單，可是真正參與過大項目開發的人必定知道中間涉及的內容可很多。

好比這個大項目如何拆分？任務如何分配？每一個人手頭已有工做怎麼辦？每一個人能力不同怎麼辦？每一個人開發進度不同怎麼辦？開發過程當中組員生病要請長假他手頭的工做怎麼辦？指揮督促你們幹活的組長請假了怎麼辦？最後代碼合併過程出現問題怎麼辦？項目延期怎麼辦？項目最後黃了怎麼辦？

仔細想一想上面的奪命十連問，其實每一條都是對應了分佈式計算可能會出現的問題，具體怎麼對應你們思考吧我就很少說了，其實已是很是明顯了。也許有人以爲這些問題其實在多人開發的時候都不重要不須要特別去考慮怎麼辦，可是在分佈式計算系統中不同，每個都是很是嚴重而且很是基礎的問題，須要有很好的解決方案。

最後提一下，分佈式計算目前流行的工具備：

• 離線工具Spark，MapReduce等
• 實時工具Spark Streaming，Storm，Flink等

這幾個東西的區別和各自的應用場景咱們以後再聊。

分佈式存儲

傳統的網絡存儲系統採用的是集中的存儲服務器存放全部數據，單臺存儲服務器的io能力是有限的，這成爲了系統性能的瓶頸，同時服務器的可靠性和安全性也不能知足需求，尤爲是大規模的存儲應用。

分佈式存儲系統，是將數據分散存儲在多臺獨立的設備上。採用的是可擴展的系統結構，利用多臺存儲服務器分擔存儲負荷，利用位置服務器定位存儲信息，它不但提升了系統的可靠性、可用性和存取效率，還易於擴展。

上圖是hdfs的存儲架構圖，hdfs做爲分佈式文件系統，兼備了可靠性和擴展性，數據存儲3份在不一樣機器上（兩份存在同一機架，一份存在其餘機架）保證數據不丟失。由NameNode統一管理元數據，能夠任意擴展集羣。

主流的分佈式數據庫有不少hbase，mongoDB，GreenPlum，redis等等等等，沒有孰好孰壞之分，只有合不合適，每一個數據庫的應用場景都不一樣，其實直接比較是沒有意義的，後續我也會有文章一個個講解它們的應用場景原理架構等。

分佈式調度與管理

如今人們好像都很熱衷於談"去中心化"，也許是區塊鏈帶起的這個潮流。可是"中心化"在大數據領域仍是很重要的，至少目前來講是的。

• 分佈式的集羣管理須要有個組件去分配調度資源給各個節點，這個東西叫yarn;
• 須要有個組件來解決在分佈式環境下"鎖"的問題，這個東西叫zookeeper；
• 須要有個組件來記錄任務的依賴關係並定時調度任務，這個東西叫azkaban。

固然這些「東西」並非惟一的，其實都是有不少替代品的，我這裏只舉了幾個比較經常使用的例子。

說兩句

回答完這個問題，準備說點其餘的。最近想了好久，準備開始寫一系列的文章，記錄這些年來的所得所想，感受內容比較多不知從哪裏開始，就畫了文章開頭的思惟導圖肯定了大的方向，你們都知道大數據的主流技術變化迭代很快，不斷會有新的東西加入，因此這張圖裏內容也會根據狀況不斷添加。細節的東西我會邊寫邊定，你們也能夠給我一些建議，我會根據寫的內容實時更新這張圖以及下面的目錄。

關於分組

上面的大數據組件分組實際上是比較糾結的，特別是做爲一個有強迫症的程序猿，有些組件好像放在其餘組也能夠，並且我又不想要分太多的組看起來會很亂，因此上面這張圖的分組方式會稍主觀一些。分組方式確定不是絕對的。

舉個例子，像kafka這種消息隊列通常不會和其它的數據庫或者像HDFS這種文件系統放在一塊兒，可是它們一樣都具有有分佈式持久化存儲的功能，因此就把它們放在一起了；還有openTsDB這種時序數據庫，說是數據庫實際上只是基於HBase上的一個應用，我以爲這個東西更側重於查詢和以及用何種方式存儲，而不在於存儲自己，因此就主觀地放在了「分佈式計算與查詢」這一類，還有OLAP的工具也一樣放在了這一組。

一樣的狀況還存在不少，你們有異議也能夠說出來討論下。

目的

你們都知道大數據的技術突飛猛進，做爲一個程序猿想要保持競爭力就必須得不斷地學習。寫這些文章的目的比較簡單，一是能夠當作一個筆記，梳理知識點；二是但願能幫到一些人瞭解學習大數據。每一篇的篇幅不會太長，閱讀時間控制在5到10分鐘。個人公衆號大叔據，會同步更新。喜歡看公衆號文章的同窗能夠關注下，文章的篇幅不會太長，不會佔用你太多的閱讀時間，天天花一點時間學習，長期積累老是會有收穫的。