天天看點

大資料需要學什麼?

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

思維導圖

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

大資料需要學什麼?

大資料需要的語言 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的工具也同樣放在了這一組。

在這裡我還是要推薦下我自己建的大資料學習交流qq裙:522189307 , 裙 裡都是學大資料開發的,如果你正在學習大資料 ,小編歡迎你加入,大家都是軟體開發黨,不定期分享幹貨(隻有大資料開發相關的),包括我自己整理的一份最新的大資料進階資料和進階開發教程,歡迎進階中和進想深入大資料的小夥伴。上述資料加群可以領取