如何用形象的比喻描述大資料的技術生態?Hadoop Hive Spark 之間是什麼關係?

時間 2021-05-05 20:56:31

1樓:Seven0007

大部分人都知道Hadoop,Hadoop作為最基本大資料框架,佔據著核心的位置。Apache Hadoop是社群開源版本,而生產中使用最多的,還是基於Apache的第三方發行版的Hadoop,例如HDP和CDH,這兩家是免費的,目前我們使用的是HDP。當然也有收費,例如華為、Intel。

那麼,Hadoop發揮著什麼樣的作用?

在傳統思維中,程式的執行只占用執行程式主機的計算資源,例如CPU和記憶體;檔案只占用所在主機的磁碟儲存。而Hadoop可以利用多台機器組成集群,從而提供「分布式計算和分布式儲存的能力」

HDFS由主節點NameNode和從節點DataNode組成。在大資料中,主從結構是最常見的架構。

NameNode負責管理整個檔案系統的元資料,例如某個檔案存放在哪台機器上。當NameNode故障無法工作,則HDFS就變得不可用。目前解決方法的就是HA高可用,即集群中有兩個NameNode,平時乙個處於Active狀態,乙個處於StandBy狀態。

當處於Active的NameNode無法工作時,StandBy的NameNode會變成Active狀態並接管工作。

DataNode負責資料檔案的儲存,每個檔案根據預先設定的副本數被儲存在不同的機器上。假如你設定的副本數為3,那麼乙個檔案將會額外被複製三份,生成三個副本。根據機架感知策略,存放在不同的節點上。

副本1放在和Client相同機架的節點上(Client不在集群內則選擇最近的節點)

副本2放在與第乙個機架不同的機架中的任意節點上

副本3放在與第二個節點所在機架的不同的節點

這樣,當乙個節點故障導致檔案損壞,也可以通過其他節點的檔案副本保證正常使用,這就是資料容災策略,通過犧牲空間、資料冗餘來保證資料的可用性,類似於raid。同時,Kafka也是通過副本來保證資料可用性。

MapReduce是乙個分布式計算模型,將任務的執行分為Map和Reduce兩個階段,每個階段都拆分成多個任務來併發執行,類似於演算法中的分治思想。

如圖,分治思想是將任務拆分成多個子任務同時計算,以此得出最終結果。MapReduce也是將任務拆分,分發到Hadoop的各個節點上進行計算,這樣就可以利用多個主機的計算資源。至於MapReduce底層的實現細節,有興趣的話可以研究一下。

離線資料通常是指已經持久化到磁碟的資料,例如儲存於檔案、資料庫。我把離線計算理解成有邊界計算,因為檔案、資料庫中的資料是已知的、通常不會改變。狹義上也可以理解為資料庫SQL計算,利用大資料技術在海量離線資料中進行分析,用於營銷決策或者報表展示等。

離線計算一般使用的是Hive。Hive作為資料倉儲工具,其資料檔案存放於HDFS之上,通過HiveSQL對資料檔案進行增刪改查操作。雖然Hive提供著資料庫的操作方式,但HiveSQL會被Hive的執行引擎解析成MapReduce任務,分發在Hadoop節點上執行,所以Hive本身並不是乙個資料庫,底層計算還是依賴於MapReduce。

經常使用的技術還有SparkSQL、Kylin、Hbase、Druid等。

電商舉例,分析出乙個月內成交量最多的商品Top100,製作視覺化報表。

與離線計算對應的就是實時計算,可以理解為無邊界流式計算。資料就像河水一樣,源源不斷的進入程式中。而程式也會一直執行,直到出現異常或者被人工停止。

目前企業使用最多的實時計算框架的就是Flink和SparkStreaming,並配合Kafka作為訊息佇列來構建實時計算。這裡簡單模擬一下流處理:

如圖,採集程式作為生產者,實時生成資料寫入Kafka;Flink程式作為消費者,實時讀取Kafka中的資料來源來進行計算處理,最終將計算結果寫入Kafka或者HDFS中。

日常中比較常用的流處理技術還有Storm、RabbitMQ等,而Redis通常作為快取為流式計算提供服務。

電商舉例,找出目前正在瀏覽某書籍的使用者,推送書籍優惠券。

Seven0007:我的程式設計師之路03:我和大資料

2樓:

你是乙個農場主,你有好多塊地。 計算機集群。

種了好多好多莊稼。 儲存的資料。

現在你要收割莊稼,一種是中手扶拖拉機。 hive。

另一種是用聯合收割機。 spark。

但是油和機器都要去申請。 yarn。

3樓:cyrildou

原先都是單機,但是現在資料量/計算量都太大了,單機不夠,於是要搞很多機器一起來,這就牽扯:

分布式儲存:多台機器構成乙個統一的儲存系統(A機器不夠了就存到B機器,系統自動完成這個過程),這玩意的代表是HDFS分布式檔案系統。 但是它是個檔案系統,有分布式資料庫嗎?

於是hbase出來了.

分布式計算: 分布式儲存裡存了這麼多內容,怎麼計算呢?單靠一台機器的計算肯定慢,希望也是分給多台機器來一起算好加快速度,於是產生了MapReduce等分布式計算框架。

spark等也是搞這個的,只是是比mapReduce再加快了些。後邊還有flink等,只是模型不同。

hdfs \ hbase \ mapreduce 就是google的三家馬車gfs \ bigtable \ mapReduce的開源實現,統稱hadoop. 所以你可以從儲存和計算兩個維度去看待。

但是mapReduce寫起來太複雜,一般人搞不定, 於是要做一層轉換, 於是有了從sql到mapReduce的轉換,這個工作是hive做的。所以你可以簡單把Hive理解成是乙個轉換工具,是為了「小白」可以用自己熟悉的sql語句來做分布式計算。

4樓:京東白條

大資料技術生態包含的名詞繁多,功能複雜。總結起來我們可以概括為資料的存、取、用。這裡我們可以將資料的最終產品比作一道菜,而我們所有的技術都是為了來完成這道菜的製作。

那麼我們需要做一道什麼菜呢?西紅柿炒雞蛋?土豆燉牛腩?

熗炒土豆絲?清蒸鱸魚?好吧,能做的太多了,所以我們需要的工具也就很多。

那麼我們該怎麼做呢?首先我們從菜市場把菜買回來,走進乙個叫hadoop的廚房裡。根據菜的型別,我們將菜放入不同的籃子裡存放,比如一些沒處理過的茄子,雞蛋,土豆等可以放在乙個叫hdfs的籃子裡,一些需要快速處理的青菜放在hbase的籃子裡。

等我們將菜依次放好後,我們需要對菜進行切割,並根據菜名來將不同的菜組合起來,在切的過程中我們使用的刀有很多種,我們可以用笨重但效能穩定的mapreduce刀來剁骨頭拍大蒜,用簡單的hive菜刀來切肉,用快速的spark刀來切青菜、用mahout刀來削帶形狀的土豆絲,最後這些菜都放到乙個叫yarn的灶台上翻炒,而yarn這個灶台會自動幫我們解決一些基本做菜的資源問題,比如火的大小和鹽的數量等。等到翻炒完後,我們就可以起鍋收菜啦,而這盤菜就是我們日常看到的統計分析報表。

魯楠,資料探勘師,京東集團-智慧型技術部

5樓:北G眺望

大資料的整個生態是我們暫時無法了解的,我們需要更多的資料來進行分析和更多的資料來進行一定大資料發展,所以現在講我們的大資料進行資料封鎖是不可能的,我們需要更多的資料來為大資料提供支援。

6樓:小木曾冬馬

hadoop 廚房免費送廉價燃氣灶(map reduce) 這燃氣灶所有人都嫌棄於是說以後可能就不送了但是大家對送的冰箱讚不絕口

spark:電磁爐做飯的最後一步,執行工具

7樓:好程式設計師

hadoop:Apache Hadoop軟體庫是乙個框架,它允許使用簡單的程式設計模型跨計算機集群的大型資料集的分布式處理。

它被設計成從單個伺服器擴充套件到數千台機器,每個機器提供本地計算和儲存。而不是依靠硬體上提供高可用性,本身的設計目的是檢測和處理應用程式層的故障。

hadoop理解:用多台廉價的計算機組成集群,替代傳統的伺服器。每台機器都可以儲存和計算。

1.資料檔案被分成多個塊儲存在各個計算機上,提供冗餘備份機制。這樣,單台計算機壞掉資料也不會丟失。這就是HDFS分布式檔案儲存系統。

2.hadoop集群上的每台計算機都有自己的cpu,充分利用這些cpu進行平行計算。可以理解為乙個計算任務被拆分為多個部分,分配到集群下的計算機上,多台機器平行計算然後再將結果彙總。

這就是mapreduce。

hive:基於hadoop的資料倉儲工作,可以將結構性的資料對映成一張資料庫表,提供HiveQL語句(類sql),並將其轉化為mapreduce任務執行在hadoop上。

hive理解:本質就是MapReduce,簡化了MapReduce任務的開發。讓使用sql語言的人可以很快的進行大資料的開發

spark:Spark是基於記憶體計算的大資料平行計算框架。Spark基於記憶體計算,提高了在大資料環境下資料處理的實時性,

同時保證了高容錯性和高可伸縮性,允許使用者將Spark部署在大量廉價硬體之上,形成集群

spark理解:思想與MapReduce相同,但是是基於記憶體計算,速度更快。

Hadoop、Hive、Spark之間的關係?

hadoop:乙個大腦加乙個口袋構成乙個單體,大腦負責計算資料,口袋負責儲存資料。多個單體構成集群。

hive:使用HiveQL語句,將其轉化成MapReduce任務,讓多個大腦同時計算儲存在多個口袋裡的資料。

spark:多個更聰明的大腦組成的集群,計算儲存在hadoop集群上的資料。計算速度很快,可以進行實時的應用。

8樓:王禮

作者的問題本身有一些問題,不能把Hive與Hadoop、Spark放到同乙個維度去比較。我們通常比較的是Hadoop與Spark,他們才是兩種不同的大資料生態系統,各自的元件都非常多,往往也不容易學,下面我把他們兩者整理在一幅圖中,給大家乙個全貌的感覺。至於各元件的詳細介紹、相關聯絡和區別,以及它們在大資料平台建設中的具體實施關注點,以後再合適時候對帖子進行詳細的更新。

a.藍色部分,是Hadoop生態系統元件,黃色部分是Spark生態元件,雖然他們是兩種不同的大資料處理框架,但它們不是互斥的,Spark與hadoop 中的MapReduce是一種相互共生的關係。Hadoop提供了Spark許多沒有的功能,比如分布式檔案系統,而Spark 提供了實時記憶體計算,速度非常快。

有一點大家要注意,Spark並不是一定要依附於Hadoop才能生存,除了Hadoop的HDFS,還可以基於其他的雲平台,當然啦,大家一致認為Spark與Hadoop配合默契最好擺了。

HSQL未來可能會被Spark SQL替代,現在很多企業都是HIVE SQL和Spark SQL兩種工具共存,當Spark SQL逐步成熟的時候,就有可能替換HSQL;

MapReduce也有可能被Spark 替換,趨勢是這樣,但目前Spark還不夠成熟穩定,還有比較長的路要走;

Hadoop中的演算法庫Mahout正被Spark中的演算法庫MLib所替代,為了不落後,大家注意去學習Mlib演算法庫;

Storm會被Spark Streaming替換嗎?在這裡,Storm雖然不是hadoop生態中的一員,但我仍然想把它放在一起做過比較。由於Spark和hadoop天衣無縫的結合,Spark在逐步的走向成熟和穩定,其生態元件也在逐步的完善,是冉冉公升起的新星,我相信Storm會逐步被擠壓而走向衰退。

薛丁格的貓,如何來形象比喻?

UncleSlay 你收到乙個快遞,開啟之後知道了裡邊是什麼。那麼我們認為開啟之前就確定裡邊是什麼僅僅是你不知道。而薛丁格的貓說,不僅僅是你不知道裡邊是什麼而且也不確定是什麼。 海闊天空 現在網際網路時代,在你網戀奔現之前,你不知道他 她 是男是女,不知道是胖是瘦,不知道是美是醜!只有當你們現實見面...

如何形象生動的描述資料庫引擎這個概念?

機智飛 Adatabase engine orstorage engine is the underlying software component that a database management system DBMS uses to create,read,update and delet...

大資料專業的前景如何?

海牛大資料 大資料專業的前景還是不錯的。從大資料的快速落地就可以看出,大資料正在持續高速的發展。大資料目前已經覆蓋到各行各業,而且正在逐步推動傳統企業轉型公升級。而大資料人才的需求量也非常大的,人才缺口超百萬餘,隨著人工智慧 物聯網 雲計算等技術的發展,大資料人才急劇增加 大資料行業薪資普遍偏高,大...