[概覽]開源大數據技術漫談

開源大數據技術漫談
http://sanwen8.cn/p/150ZTVb.html
簡單把上述大數據技術做一個總結,大數據可以從流程上分為輸入(Delivery)、處理(Processing)、存儲(Storage)和查詢(Querying)四個步驟,分別有對應的開源技術,而這些技術方案之間往往又是相互滲透的。看下圖:

Paste_Image.png

大數據開源要從Hadoop說起。2003年Google發布了GFS的論文,2004年發布了MapReduce的論文。Yahoo的工程師們以這個設計思路開發了名為Nutch的搜索項目,并在2006年把它開源了。從此,Hadoop橫空出世,開啟了大數據開源的時代。

來看看Hadoop的內部構造,我們可以簡單地把Hadoop分為數據存儲和數據處理兩大部分。待處理的數據以文件為單位被保存在HDFS(分布式文件系統)上,然后交由MapReduce進行數據處理。

HDFS(分布式文件系統)在Hadoop中負責數據的存儲,其特點是可以運行在廉價的硬件上,提供了高度容錯的大吞吐量的數據訪問。而MapReduce是一種并行計算的方案,極大地方便了編程人員在不會分布式并行編程的情況下,將自己的程序運行在分布式系統上。

隨著基于Hadoop的開發越來越多,其先天的局限性也逐步暴露出來。Hadoop原來是為搜索設計的解決方案,它的存儲是基于文件系統的,包括原始輸入和中間計算結果都要保存為磁盤上。而我們都知道磁盤IO是系統性能的瓶頸之一。這也造成了基于Hadoop的大數據方案在一些對實時性要求比較高的場景下不太適用。

仔細分析實時性場景,我們會發現有兩種不同的實時性需求:一種是實時數據處理,另一種是實時數據查詢。不同場景對數據的輸入、計算、存儲和查詢有不同的要求,也就產生了不同的開源大數據解決方案。

第一種實時數據處理場景要求輸入數據是實時的流數據,數據的分析處理要在規定時間內完成。比如要分析每年春運的人員流動數據,輸入數據是海量的汽車、火車、航班旅客信息,對輸出結果的時效有極高的要求,如果數據分析速度太慢,就失去了實時監控和預測的意義。

實時數據輸入解決方案讓輸入數據以流的方式實時地進入大數據系統,而不必先存儲到HDFS文件系統中,從而避免了由于磁盤IO造成的性能損失。Apache Kafka, RabbitMQ,Apache Flume等是當前比較流行的開源方案,其中Apache Kafka越來越引人注目,這主要歸功于其恐怖的性能指標。Kafka目前用于LinkedIn,它每天處理超過100億消息,持續負載平均每秒172,000消息。目前,無論從內部和外部的使用數據的應用程序大量使用多訂閱者支持。每個消息發布出來后,基本上會有5.5個消息消費者使用,這導致的結果是每一天將有550億的消息發送給實時消費者。

隨著大數據中計算越來越復雜,往往一個處理過程會分解成很多小的計算任務,這些計算任務的中間結果需要保存在文件中做為下一個任務的輸入。這樣在計算過程中就會引入多次磁盤讀寫,降低了整體的計算速度。基于流處理的開源方案解決了這個問題,通過把中間計算結果保存在內存中,大大減少了磁盤讀寫帶來的性能損失。這類方案有代表性的有Spark,STORM,samza,其中Spark發展得最好。

第二種實時數據查詢場景類似于早期的商業智能解決方案,它對數據處理速度和輸入數據的實時性要求不高,但對數據查詢的響應速度要求極高。對這種業務需求的基本解決思路是數據的預處理和查詢優化。所謂預處理就是把所有可能的查詢條件組合都事先計算好,這樣當實際查詢發生時不必再進行計算,而可以直接使用已經算好的結果。這就引入了第二個問題,如何快速匹配查詢結果。目前主流的開源查詢方案包括SQL-on-Hadoop,基于Key-Value存儲的cassandra,Apache HBASE,和基于列存儲的Druid等。其中Druid是最近開始嶄露頭角的一個新項目,它采用了列存儲技術,將查詢速度提高到次秒級,提供了以交互方式訪問數據的能力。

簡單把上述大數據技術做一個總結,大數據可以從流程上分為輸入(Delivery)、處理(Processing)、存儲(Storage)和查詢(Querying)四個步驟,分別有對應的開源技術,而這些技術方案之間往往又是相互滲透的。看下圖:


大數據技術在國內的互聯網企業中已經大量應用,淘寶、百度都是其中的佼佼者。特別是淘寶,由于馬云在很早就把數據提到全公司的戰略高度上,無論在人才上,技術實力上還是應用的深度廣度上,淘寶的大數據都是走在前列的。從目前公開的資料看,淘寶的大數據平臺主要還是建立在Hadoop之上的,但也在不斷加入新的技術,如STORM等。淘寶不僅自己使用開源軟件,自己也為開源做出貢獻,比如開源系統timetunnel就是淘寶參考kafka產品的一個數據庫日志采集收取發布中間件。而RocketMQ是另一個淘寶開源的消息中間件,定位于非日志的可靠消息傳輸,在阿里集團被廣泛應用在訂單,交易,充值,流計算,消息推送,日志流式處理,binglog分發等場景。

從Hadoop開源到今天已經過了10年,開源大數據技術的發展是被不斷擴大的業務需求推動的。未來的10年,隨著越來越多的大數據應用的出現,新的需求又會對大數據技術提供新的挑戰,推動大數據向新的領域擴展。而人工智能技術可以說是最令人激動的大數據發展方向了。目前,Google和微軟都在人工智能上押了重注,同時也是開源社區中重要的領導者,比如微軟的MicrosoftCognitive Services和Google的TensorFlow。 相信開源大數據技術的未來會越來越精彩。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,702評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,143評論 3 415
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,553評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,620評論 1 307
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,416評論 6 405
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,940評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,024評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,170評論 0 287
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,709評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,597評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,784評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,291評論 5 357
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,029評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,407評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,663評論 1 280
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,403評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,746評論 2 370

推薦閱讀更多精彩內容