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

大資料需要學習什麼？很多人問過我這個問題。每一次回答完都覺得自己講得太片面了，總是沒有一個合適的契機去好好總結這些內容，直到開始寫這篇東西。大資料是近五年興起的行業，發展迅速，很多技術經過這些年的迭代也變得比較成熟了，同時新的東西也不斷湧現，想要保持自己競爭力的唯一辦法就是不斷學習。

思維導圖

下面的是我整理的一張思維導圖，內容分成幾大塊，包括了分散式計算與查詢，分散式排程與管理，持久化儲存，大資料常用的程式語言等等內容，每個大類下有很多的開源工具，這些就是作為大資料程式猿又愛又恨折騰得死去活來的東西了。

大資料需要的語言

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分鐘。我的公眾號大叔據，會同步更新。喜歡看公眾號文章的同學可以關注下，文章的篇幅不會太長，不會佔用你太多的閱讀時間，每天花一點時間學習，長期積累總是會有收穫的。