大数据生态及其技术栈
大數據生態及其技術棧
原文:大數據生態及其技術棧
如何用形象的比喻描述大數據的技術生態?Hadoop、Hive、Spark 之間是什么關系?對于大部分人來說都是傻傻分不清楚。
今年來大數據、人工智能獲得了IT界大量的關注。如果一個企業不玩大數據,都不好意思說自己是在IT圈混的。我敢打賭,你在中關村西二旗地鐵站溜一圈,保準你會聽到如下名詞:Hadoop、Spark、MapReduce、NoSQL、離線計算、實時計算、實時推送等等一大串名稱。程序猿哥哥們就是有這么實在,坐在地鐵上還能那么投入的討論技術問題。那么,這些聽起來高大上的技術,究竟都是干什么用的呢?他們之間的有什么區別和聯系?
通常,一個技術的興起,都是由現實需求驅動的。了解了我們面臨的問題,就能更好的理解各個大數據技術的使用場景,各類大數據技術的區別也就顯而易見了。
網易大數據工程師@Xiaoyu Ma對大數據的話題進行了通俗的解讀,各位準備好小板凳,開講啦...
首先上一張大數據生態系統的圖:
Hadoop生態系統概覽
然后了解大數據技術棧中常見的概念:
Hadoop:Hadoop實現了一個分布式文件系統(Hadoop Distributed File System),簡稱HDFS。HDFS有高容錯性的特點,并且設計用來部署在低廉的(low-cost)硬件上;而且它提供高吞吐量(high throughput)來訪問應用程序的數據,適合那些有著超大數據集(large data set)的應用程序。HDFS放寬了(relax)POSIX的要求,可以以流的形式訪問(streaming access)文件系統中的數據。
Hadoop的框架最核心的設計就是:HDFS和MapReduce。HDFS為海量的數據提供了存儲,則MapReduce為海量的數據提供了計算。
HDFS:Hadoop分布式文件系統(HDFS)被設計成適合運行在通用硬件(commodity hardware)上的分布式文件系統。它和現有的分布式文件系統有很多共同點。但同時,它和其他的分布式文件系統的區別也是很明顯的。HDFS是一個高度容錯性的系統,適合部署在廉價的機器上。HDFS能提供高吞吐量的數據訪問,非常適合大規模數據集上的應用。HDFS放寬了一部分POSIX約束,來實現流式讀取文件系統數據的目的。HDFS在最開始是作為Apache Nutch搜索引擎項目的基礎架構而開發的。HDFS是Apache Hadoop Core項目的一部分。HDFS有著高容錯性(fault-tolerant)的特點,并且設計用來部署在低廉的(low-cost)硬件上。而且它提供高吞吐量(high throughput)來訪問應用程序的數據,適合那些有著超大數據集(large data set)的應用程序。HDFS放寬了(relax)POSIX的要求(requirements)這樣可以實現流的形式訪問(streaming access)文件系統中的數據。
Spark: Spark是一個高效的分布式計算系統,相比Hadoop的Mapreduce計算框架,它在性能上比Mapreduce要高100倍。Spark提供比Hadoop更上層的API,同樣的算法在Spark中實現往往只有Hadoop的1/10或者1/100的長度。Shark類似“SQL on Spark”,是一個在Spark上數據倉庫的實現,在兼容Hive的情況下,性能最高可以達到Hive的一百倍。
HBase:是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統,利用HBase技術可在廉價PC Server上搭建起大規模結構化數據集群。像Facebook,都拿它做大型實時應用 Facebook's New Realtime Analytics System: HBase to Process 20 Billion Events Per Day
Pig:Yahoo開發的,并行地執行數據流處理的引擎,它包含了一種腳本語言,稱為Pig Latin,用來描述這些數據流。Pig Latin本身提供了許多傳統的數據操作,同時允許用戶自己開發一些自定義函數用來讀取、處理和寫數據。在LinkedIn也是大量使用。
Hive:Facebook領導的一個數據倉庫工具,可以將結構化的數據文件映射為一張數據庫表,并提供完整的sql查詢功能,可以將sql語句轉換為MapReduce任務進行運行。其優點是學習成本低,可以通過類SQL語句快速實現簡單的MapReduce統計。像一些data scientist 就可以直接查詢,不需要學習其他編程接口。
Cascading/Scalding:Cascading是Twitter收購的一個公司技術,主要是提供數據管道的一些抽象接口,然后又推出了基于Cascading的Scala版本就叫Scalding。Coursera是用Scalding作為MapReduce的編程接口放在Amazon的EMR運行。
Zookeeper:一個分布式的,開放源碼的分布式應用程序協調服務,是Google的Chubby一個開源的實現。
Oozie:一個基于工作流引擎的開源框架。由Cloudera公司貢獻給Apache的,它能夠提供對Hadoop MapReduce和Pig Jobs的任務調度與協調。
Azkaban: 跟上面很像,Linkedin開源的面向Hadoop的開源工作流系統,提供了類似于cron 的管理任務。
Tez:Hortonworks主推的優化MapReduce執行引擎,與MapReduce相比較,Tez在性能方面更加出色。
Mesos:一個分布式環境的資源管理平臺,它使得Hadoop、MPI、Spark作業在統一資源管理環境下執行。它對Hadoop2.0支持很好。Twitter,Coursera都在使用。
Tachyon:是一個高容錯的分布式文件系統,允許文件以內存的速度在集群框架中進行可靠的共享,就像Spark和MapReduce那樣。有幸跟項目發起人李浩源聊過幾次,這個項目目前發展非常快,甚至比Spark當時還要驚人。目前到0.6版本,參與開源的規模和版本迭代速度都很快。已經拿到著名VC A16Z 750萬美金的投資,https://www.crunchbase.com/organization/tachyon-networks
看了這么多大數據相關概念,相信你對大數據技術棧更迷糊了。下面是一段更加通俗的解讀:
大數據本身是個很寬泛的概念,Hadoop生態圈(或者泛生態圈)基本上都是為了處理超過單機尺度的數據處理而誕生的。你可以把它比作一個廚房所以需要的各種工具。鍋碗瓢盆,各有各的用處,互相之間又有重合。你可以用湯鍋直接當碗吃飯喝湯,你可以用小刀或者刨子去皮。但是每個工具有自己的特性,雖然奇怪的組合也能工作,但是未必是最佳選擇。
大數據,首先你要能存的下大數據。
傳統的文件系統是單機的,不能橫跨不同的機器。HDFS(Hadoop Distributed FileSystem)的設計本質上是為了大量的數據能橫跨成百上千臺機器,但是你看到的是一個文件系統而不是很多文件系統。比如你說我要獲取/hdfs/tmp/file1的數據,你引用的是一個文件路徑,但是實際的數據存放在很多不同的機器上。你作為用戶,不需要知道這些,就好比在單機上你不關心文件分散在什么磁道什么扇區一樣。HDFS為你管理這些數據。
存的下數據之后,你就開始考慮怎么處理數據。雖然HDFS可以為你整體管理不同機器上的數據,但是這些數據太大了。一臺機器讀取成T上P的數據(很大的數據哦,比如整個東京熱有史以來所有高清電影的大小甚至更大),一臺機器慢慢跑也許需要好幾天甚至好幾周。對于很多公司來說,單機處理是不可忍受的,比如微博要更新24小時熱博,它必須在24小時之內跑完這些處理。那么我如果要用很多臺機器處理,我就面臨了如何分配工作,如果一臺機器掛了如何重新啟動相應的任務,機器之間如何互相通信交換數據以完成復雜的計算等等。這就是MapReduce / Tez / Spark的功能。MapReduce是第一代計算引擎,Tez和Spark是第二代。MapReduce的設計,采用了很簡化的計算模型,只有Map和Reduce兩個計算過程(中間用Shuffle串聯),用這個模型,已經可以處理大數據領域很大一部分問題了。
那什么是Map什么是Reduce?
考慮如果你要統計一個巨大的文本文件存儲在類似HDFS上,你想要知道這個文本里各個詞的出現頻率。你啟動了一個MapReduce程序。Map階段,幾百臺機器同時讀取這個文件的各個部分,分別把各自讀到的部分分別統計出詞頻,產生類似
(hello, 12100次),(world,15214次)等等這樣的Pair(我這里把Map和Combine放在一起說以便簡化);這幾百臺機器各自都產生了如上的集合,然后又有幾百臺機器啟動Reduce處理。Reducer機器A將從Mapper機器收到所有以A開頭的統計結果,機器B將收到B開頭的詞匯統計結果(當然實際上不會真的以字母開頭做依據,而是用函數產生Hash值以避免數據串化。因為類似X開頭的詞肯定比其他要少得多,而你不希望數據處理各個機器的工作量相差懸殊)。然后這些Reducer將再次匯總,(hello,12100)+(hello,12311)+(hello,345881)= (hello,370292)。每個Reducer都如上處理,你就得到了整個文件的詞頻結果。
這看似是個很簡單的模型,但很多算法都可以用這個模型描述了。
Map+Reduce的簡單模型很黃很暴力,雖然好用,但是很笨重。第二代的Tez和Spark除了內存Cache之類的新feature,本質上來說,是讓Map/Reduce模型更通用,讓Map和Reduce之間的界限更模糊,數據交換更靈活,更少的磁盤讀寫,以便更方便地描述復雜算法,取得更高的吞吐量。
有了MapReduce,Tez和Spark之后,程序員發現,MapReduce的程序寫起來真麻煩。他們希望簡化這個過程。這就好比你有了匯編語言,雖然你幾乎什么都能干了,但是你還是覺得繁瑣。你希望有個更高層更抽象的語言層來描述算法和數據處理流程。于是就有了Pig和Hive。Pig是接近腳本方式去描述MapReduce,Hive則用的是SQL。它們把腳本和SQL語言翻譯成MapReduce程序,丟給計算引擎去計算,而你就從繁瑣的MapReduce程序中解脫出來,用更簡單更直觀的語言去寫程序了。
有了Hive之后,人們發現SQL對比Java有巨大的優勢。一個是它太容易寫了。剛才詞頻的東西,用SQL描述就只有一兩行,MapReduce寫起來大約要幾十上百行。而更重要的是,非計算機背景的用戶終于感受到了愛:我也會寫SQL!于是數據分析人員終于從乞求工程師幫忙的窘境解脫出來,工程師也從寫奇怪的一次性的處理程序中解脫出來。大家都開心了。Hive逐漸成長成了大數據倉庫的核心組件。甚至很多公司的流水線作業集完全是用SQL描述,因為易寫易改,一看就懂,容易維護。
自從數據分析人員開始用Hive分析數據之后,它們發現,Hive在MapReduce上跑,真雞巴慢!流水線作業集也許沒啥關系,比如24小時更新的推薦,反正24小時內跑完就算了。但是數據分析,人們總是希望能跑更快一些。比如我希望看過去一個小時內多少人在充氣娃娃頁面駐足,分別停留了多久,對于一個巨型網站海量數據下,這個處理過程也許要花幾十分鐘甚至很多小時。而這個分析也許只是你萬里長征的第一步,你還要看多少人瀏覽了跳蛋多少人看了拉赫曼尼諾夫的CD,以便跟老板匯報,我們的用戶是猥瑣男悶騷女更多還是文藝青年/少女更多。你無法忍受等待的折磨,只能跟帥帥的工程師蟈蟈說,快,快,再快一點!
于是Impala,Presto,Drill誕生了(當然還有無數非著名的交互SQL引擎,就不一一列舉了)。三個系統的核心理念是,MapReduce引擎太慢,因為它太通用,太強壯,太保守,我們SQL需要更輕量,更激進地獲取資源,更專門地對SQL做優化,而且不需要那么多容錯性保證(因為系統出錯了大不了重新啟動任務,如果整個處理時間更短的話,比如幾分鐘之內)。這些系統讓用戶更快速地處理SQL任務,犧牲了通用性穩定性等特性。如果說MapReduce是大砍刀,砍啥都不怕,那上面三個就是剔骨刀,靈巧鋒利,但是不能搞太大太硬的東西。
這些系統,說實話,一直沒有達到人們期望的流行度。因為這時候又兩個異類被造出來了。他們是Hive on Tez / Spark和SparkSQL。它們的設計理念是,MapReduce慢,但是如果我用新一代通用計算引擎Tez或者Spark來跑SQL,那我就能跑的更快。而且用戶不需要維護兩套系統。這就好比如果你廚房小,人又懶,對吃的精細程度要求有限,那你可以買個電飯煲,能蒸能煲能燒,省了好多廚具。
上面的介紹,基本就是一個數據倉庫的構架了。底層HDFS,上面跑MapReduce/Tez/Spark,在上面跑Hive,Pig。或者HDFS上直接跑Impala,Drill,Presto。這解決了中低速數據處理的要求。
那如果我要更高速的處理呢?
如果我是一個類似微博的公司,我希望顯示不是24小時熱博,我想看一個不斷變化的熱播榜,更新延遲在一分鐘之內,上面的手段都將無法勝任。于是又一種計算模型被開發出來,這就是Streaming(流)計算。Storm是最流行的流計算平臺。流計算的思路是,如果要達到更實時的更新,我何不在數據流進來的時候就處理了?比如還是詞頻統計的例子,我的數據流是一個一個的詞,我就讓他們一邊流過我就一邊開始統計了。流計算很牛逼,基本無延遲,但是它的短處是,不靈活,你想要統計的東西必須預先知道,畢竟數據流過就沒了,你沒算的東西就無法補算了。因此它是個很好的東西,但是無法替代上面數據倉庫和批處理系統。
還有一個有些獨立的模塊是KV Store,比如Cassandra,HBase,MongoDB以及很多很多很多很多其他的(多到無法想象)。所以KV Store就是說,我有一堆鍵值,我能很快速滴獲取與這個Key綁定的數據。比如我用身份證號,能取到你的身份數據。這個動作用MapReduce也能完成,但是很可能要掃描整個數據集。而KV Store專用來處理這個操作,所有存和取都專門為此優化了。從幾個P的數據中查找一個身份證號,也許只要零點幾秒。這讓大數據公司的一些專門操作被大大優化了。比如我網頁上有個根據訂單號查找訂單內容的頁面,而整個網站的訂單數量無法單機數據庫存儲,我就會考慮用KV Store來存。KV Store的理念是,基本無法處理復雜的計算,大多沒法JOIN,也許沒法聚合,沒有強一致性保證(不同數據分布在不同機器上,你每次讀取也許會讀到不同的結果,也無法處理類似銀行轉賬那樣的強一致性要求的操作)。但是丫就是快。極快。
每個不同的KV Store設計都有不同取舍,有些更快,有些容量更高,有些可以支持更復雜的操作。必有一款適合你。
除此之外,還有一些更特制的系統/組件,比如Mahout是分布式機器學習庫,Protobuf是數據交換的編碼和庫,ZooKeeper是高一致性的分布存取協同系統,等等。
有了這么多亂七八糟的工具,都在同一個集群上運轉,大家需要互相尊重有序工作。所以另外一個重要組件是,調度系統。現在最流行的是Yarn。你可以把他看作中央管理,好比你媽在廚房監工,哎,你妹妹切菜切完了,你可以把刀拿去殺雞了。只要大家都服從你媽分配,那大家都能愉快滴燒菜。
你可以認為,大數據生態圈就是一個廚房工具生態圈。為了做不同的菜,中國菜,日本菜,法國菜,你需要各種不同的工具。而且客人的需求正在復雜化,你的廚具不斷被發明,也沒有一個萬用的廚具可以處理所有情況,因此它會變的越來越復雜。
轉載于:https://www.cnblogs.com/xuwei1/p/10423010.html
總結
以上是生活随笔為你收集整理的大数据生态及其技术栈的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Maven 使用 Tomcat7
- 下一篇: 拨打电话号码