?簡(jiǎn)單說(shuō)兩句?

作者：后端小知識(shí)，CSDN后端領(lǐng)域新星創(chuàng)作者|阿里云專(zhuān)家博主

CSDN個(gè)人主頁(yè)：后端小知識(shí)

??GZH：后端小知識(shí)

??歡迎關(guān)注??點(diǎn)贊??收藏??留言??文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-844646.html

概覽

進(jìn)入大數(shù)據(jù)階段就意味著進(jìn)入NoSQL階段，更多的是面向OLAP場(chǎng)景，即數(shù)據(jù)倉(cāng)庫(kù)、BI應(yīng)用等。

大數(shù)據(jù)技術(shù)的發(fā)展并不是偶然的，它的背后是對(duì)于成本的考量。集中式數(shù)據(jù)庫(kù)或者基于MPP架構(gòu)的分布數(shù)據(jù)庫(kù)往往采用的都是性能穩(wěn)定但價(jià)格較為昂貴的小型機(jī)、一體機(jī)或者PC服務(wù)器等，擴(kuò)展性相對(duì)較差；而大數(shù)據(jù)計(jì)算框架可以基于價(jià)格低廉的普通的硬件服務(wù)器構(gòu)建，并且理論上支持無(wú)限擴(kuò)展以支撐應(yīng)用服務(wù)。

在大數(shù)據(jù)領(lǐng)域中最有名的就是 Hadoop 生態(tài)，總體來(lái)看，它主要由三部分構(gòu)成：底層文件存儲(chǔ)系統(tǒng) HDFS（Hadoop Distributed File System，Hadoop 分布式文件系統(tǒng)）、資源調(diào)度計(jì)算框架 Yarn（Yet Another Resource Negotiator，又一個(gè)資源協(xié)調(diào)者）以及基于 HDFS 與 Yarn的上層應(yīng)用組件，例如 HBase、Hive 等。一個(gè)典型的基于 Hadoop 的應(yīng)用如下圖所示。

▲圖 一個(gè)典型的 Hadoop 應(yīng)用

HDFS

HDFS 被設(shè)計(jì)成適合運(yùn)行在通用硬件（Commodity Hardware）上的分布式文件系統(tǒng)。它和現(xiàn)有的分布式文件系統(tǒng)有很多共同點(diǎn)，例如典型的 Master-Slave 架構(gòu)（這里不準(zhǔn)備展開(kāi)介紹），也有不同點(diǎn)，**HDFS 是一個(gè)具有高度容錯(cuò)性的系統(tǒng)，適合部署在廉價(jià)的機(jī)器上。**關(guān)于HDFS 這里主要想說(shuō)兩點(diǎn)，默認(rèn)副本數(shù)的設(shè)置以及機(jī)架感知（Rack Awareness）。

HDFS 默認(rèn)副本數(shù)是 3，這是因?yàn)?Hadoop 有著高度的容錯(cuò)性，從數(shù)據(jù)冗余以及分布的角度來(lái)看，需要在同一機(jī)房不同機(jī)柜以及跨數(shù)據(jù)中心進(jìn)行數(shù)據(jù)存儲(chǔ)以保證數(shù)據(jù)最大可用。因此，為了達(dá)到上述目的，數(shù)據(jù)塊需要至少存放在同一機(jī)房的不同機(jī)架（2 份）以及跨數(shù)據(jù)中心的某一機(jī)架（1 份）中，共 3 份數(shù)據(jù)。

機(jī)架感知的目的是在計(jì)算中盡量讓不同節(jié)點(diǎn)之間的通信能夠發(fā)生在同一個(gè)機(jī)架之 內(nèi)，而不是跨機(jī)架，進(jìn)而減少分布式計(jì)算中數(shù)據(jù)在不同的網(wǎng)絡(luò)之間的傳輸，減少網(wǎng)絡(luò)帶 寬資源的消耗。例如當(dāng)集群發(fā)生數(shù)據(jù)讀取的時(shí)候，客戶端按照由近到遠(yuǎn)的優(yōu)先次序決定 哪個(gè)數(shù)據(jù)節(jié)點(diǎn)向客戶端發(fā)送數(shù)據(jù)，因?yàn)樵诜植际娇蚣苤?，網(wǎng)絡(luò) I/O 已經(jīng)成為主要的性能瓶頸。

只有深刻理解了這兩點(diǎn)，才能理解為什么 Hadoop 有著高度的容錯(cuò)性。高度容錯(cuò)性是Hadoop 可以在通用硬件上運(yùn)行的基礎(chǔ)。

Yarn

Yarn 是繼 Common、HDFS、MapReduce 之 后 Hadoop 的又一個(gè)子項(xiàng)目， 它是在MapReduceV2 中提出的。

在 Hadoop1.0 中，JobTracker 由資源管理器（由 TaskScheduler 模塊實(shí)現(xiàn)）和作業(yè)控制 （由 JobTracker 中多個(gè)模塊共同實(shí)現(xiàn)）兩部分組成。

在 Hadoop1.0 中，JobTracker 沒(méi)有將資源管理相關(guān)功能與應(yīng)用程序相關(guān)功能拆分開(kāi)，逐 漸成為集群的瓶頸，進(jìn)而導(dǎo)致集群出現(xiàn)可擴(kuò)展性變差、資源利用率下降以及多框架支持不 足等多方面的問(wèn)題。

在 MapReduceV2 中，Yarn 負(fù)責(zé)管理 MapReduce 中的資源（內(nèi)存、CPU 等）并且將其 打包成 Container。這樣可以使 MapReduce 專(zhuān)注于它擅長(zhǎng)的數(shù)據(jù)處理任務(wù)，而不需要考慮資源調(diào)度。這種松耦合的架構(gòu)方式實(shí)現(xiàn)了 Hadoop 整體框架的靈活性。

Hive

Hive 是基于Hadoop 的數(shù)據(jù)倉(cāng)庫(kù)基礎(chǔ)構(gòu)架，它利用簡(jiǎn)單的 SQL 語(yǔ)句（簡(jiǎn)稱(chēng) HQL）來(lái)查詢(xún)、分析存儲(chǔ)在 HDFS 中的數(shù)據(jù)，并把 SQL 語(yǔ)句轉(zhuǎn)換成 MapReduce 程序來(lái)進(jìn)行數(shù)據(jù)的處理。Hive與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)的主要區(qū)別體現(xiàn)在以下幾點(diǎn)。

1）存儲(chǔ)的位置， Hive 的數(shù)據(jù)存儲(chǔ)在 HDFS 或者 HBase 中，而后者的數(shù)據(jù)一般存儲(chǔ)在裸設(shè)備或者本地的文件系統(tǒng)中，由于 Hive 是基于 HDFS 構(gòu)建的，那么依賴(lài) HDFS 的容錯(cuò)特性，Hive 中的數(shù)據(jù)表天然具有冗余的特點(diǎn)。

2）數(shù)據(jù)庫(kù)更新， Hive 是不支持更新的，一般是一次寫(xiě)入多次讀寫(xiě)（這部分從 Hive 0.14之后開(kāi)始支持事務(wù)操作，但是約束比較多），但是由于 Hive 是基于 HDFS 作為底層存儲(chǔ)的， 而 HDFS 的讀寫(xiě)不支持事務(wù)特性，因此 Hive 的事務(wù)支持必然需要拆分?jǐn)?shù)據(jù)文件以及日志文 件才能支持事務(wù)的特性。

3）執(zhí)行 SQL 的延遲，Hive 的延遲相對(duì)較高，因?yàn)槊看螆?zhí)行都需要將 SQL 語(yǔ)句解析成MapReduce 程序。

4）數(shù)據(jù)的規(guī)模上，Hive 一般是 TB 級(jí)別，而后者規(guī)模相對(duì)較小。

5）可擴(kuò)展性上，Hive 支持 UDF、UDAF、UDTF，后者相對(duì)來(lái)說(shuō)可擴(kuò)展性較差。

HBase

HBase（Hadoop Database）是一個(gè)高可靠性、高性能、面向列、可伸縮的分布式存儲(chǔ)系統(tǒng)。它底層的文件系統(tǒng)使用 HDFS， 使用ZooKeeper 來(lái)管理集群的 HMaster 和各RegionServer 之間的通信，監(jiān)控各RegionServer 的狀態(tài)，存儲(chǔ)各 Region 的入口地址等。

1．特點(diǎn)

HBase 是 Key-Value 形式的數(shù)據(jù)庫(kù)（類(lèi)比 Java 中的 Map）。既然是數(shù)據(jù)庫(kù)那肯定就有 表，HBase 中的表大概有以下幾個(gè)特點(diǎn)。

1）大：一個(gè)表可以有上億行，上百萬(wàn)列（列多時(shí)，插入變慢）。

2）面向列：面向列（族）的存儲(chǔ)和權(quán)限控制，列（族）獨(dú)立檢索。

3）稀疏：對(duì)于空（null）的列，并不占用存儲(chǔ)空間，因此，表可以設(shè)計(jì)得非常稀疏。

4）每個(gè)單元格中的數(shù)據(jù)可以有多個(gè)版本，默認(rèn)情況下版本號(hào)自動(dòng)分配，是單元格插入 時(shí)的時(shí)間戳。

5）HBase 中的數(shù)據(jù)都是字節(jié)，沒(méi)有類(lèi)型定義具體的數(shù)據(jù)對(duì)象（因?yàn)橄到y(tǒng)需要適應(yīng)不同 類(lèi)型的數(shù)據(jù)格式和數(shù)據(jù)源，不能預(yù)先嚴(yán)格定義模式）。

這里需要注意的是，HBase 也是基于 HDFS，所以也具有默認(rèn) 3 個(gè)副本、數(shù)據(jù)冗余的特 點(diǎn)。此外 HBase 也是利用 WAL 的特點(diǎn)來(lái)保證數(shù)據(jù)讀寫(xiě)的一致性。

2．存儲(chǔ)

HBase 采用列式存儲(chǔ)方式進(jìn)行數(shù)據(jù)的存儲(chǔ)。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)主要是采用行式存儲(chǔ) 的方式進(jìn)行數(shù)據(jù)的存儲(chǔ)，數(shù)據(jù)讀取的特點(diǎn)是按照行的粒度從磁盤(pán)上讀取數(shù)據(jù)記錄，然后根 據(jù)實(shí)際需要的字段數(shù)據(jù)進(jìn)行處理，如果表的字段數(shù)量較多，但是需要處理的字段較少（特 別是聚合場(chǎng)景），由于行式存儲(chǔ)的底層原理，仍然需要以行（全字段）的方式進(jìn)行數(shù)據(jù)的查 詢(xún)。在這個(gè)過(guò)程中，應(yīng)用程序所產(chǎn)生的磁盤(pán) I/O、內(nèi)存要求以及網(wǎng)絡(luò) I/O 等都會(huì)造成一定的 浪費(fèi)；而列式存儲(chǔ)的數(shù)據(jù)讀取方式主要是按照列的粒度進(jìn)行數(shù)據(jù)的讀取，這種按需讀取的 方式減少了應(yīng)用程序在數(shù)據(jù)查詢(xún)時(shí)所產(chǎn)生的磁盤(pán) I/O、內(nèi)存要求以及網(wǎng)絡(luò) I/O。

此外，由于相同類(lèi)型的數(shù)據(jù)被統(tǒng)一存儲(chǔ)，因此在數(shù)據(jù)壓縮的過(guò)程中壓縮算法的選用以 及效率將會(huì)進(jìn)一步加強(qiáng)，這也進(jìn)一步降低了分布式計(jì)算中對(duì)于資源的要求。

列式存儲(chǔ)的方式更適合 OLAP 型的應(yīng)用場(chǎng)景，因?yàn)檫@類(lèi)場(chǎng)景具有數(shù)據(jù)量較大以及查詢(xún)字段較少（往往都是聚合類(lèi)函數(shù)）的特點(diǎn)。例如最近比較火的 ClickHouse 也是使用列式存儲(chǔ)的方式進(jìn)行數(shù)據(jù)的存儲(chǔ)。

Spark及Spark Streaming

Spark 由 Twitter 公司開(kāi)發(fā)并開(kāi)源，解決了海量數(shù)據(jù)流式分析的問(wèn)題。Spark 首先將數(shù)據(jù) 導(dǎo)入 Spark 集群，然后通過(guò)基于內(nèi)存的管理方式對(duì)數(shù)據(jù)進(jìn)行快速掃描，通過(guò)迭代算法實(shí)現(xiàn) 全局 I/O 操作的最小化，達(dá)到提升整體處理性能的目的。這與 Hadoop 從“計(jì)算”找“數(shù)據(jù)” 的實(shí)現(xiàn)思路是類(lèi)似的，通常適用于一次寫(xiě)入多次查詢(xún)分析的場(chǎng)景。

Spark Streaming 是基于 Spark 的一個(gè)流式計(jì)算框架，它針對(duì)實(shí)時(shí)數(shù)據(jù)進(jìn)行處理和控制， 并可以將計(jì)算之后的結(jié)果寫(xiě)入 HDFS。它與當(dāng)下比較火的實(shí)時(shí)計(jì)算框架 Flink 類(lèi)似，但是二者在本質(zhì)上是有區(qū)別的，因?yàn)?Spark Streaming 是基于微批量（Micro-Batch）的方式進(jìn)行數(shù)據(jù)處理，而非一行一行地進(jìn)行數(shù)據(jù)處理。

關(guān)于作者：

李楊，資深數(shù)據(jù)架構(gòu)師，在數(shù)據(jù)相關(guān)領(lǐng)域有10年以上工作經(jīng)驗(yàn)。頭部保險(xiǎn)資管公司科技平臺(tái)交易系統(tǒng)團(tuán)隊(duì)開(kāi)發(fā)組負(fù)責(zé)人，負(fù)責(zé)多個(gè)應(yīng)用以及數(shù)據(jù)平臺(tái)的建設(shè)、優(yōu)化以及遷移工作。曾擔(dān)任某數(shù)據(jù)公司技術(shù)合伙人，負(fù)責(zé)多個(gè)金融機(jī)構(gòu)的數(shù)據(jù)倉(cāng)庫(kù)或數(shù)據(jù)平臺(tái)相關(guān)的工作?！镀髽I(yè)級(jí)數(shù)據(jù)架構(gòu)：核心要素、架構(gòu)模型、數(shù)據(jù)管理與平臺(tái)搭建》作者。

本文摘編于**《企業(yè)級(jí)數(shù)據(jù)架構(gòu)：核心要素、架構(gòu)模型、數(shù)據(jù)管理與平臺(tái)搭建》**作者。（書(shū)號(hào)：9787111746829），經(jīng)出版方授權(quán)發(fā)布，轉(zhuǎn)載請(qǐng)標(biāo)明文章出處。

推薦理由：

一部從企業(yè)架構(gòu)視角系統(tǒng)講解企業(yè)級(jí)數(shù)據(jù)架構(gòu)的著作，系統(tǒng)梳理和闡述了企業(yè)架構(gòu)的基礎(chǔ)知識(shí)，以及數(shù)據(jù)架構(gòu)的組成要素、架構(gòu)模型、數(shù)據(jù)治理和數(shù)據(jù)資產(chǎn)管理的理論知識(shí)。

作者直播推薦：

【都看到這了，點(diǎn)點(diǎn)贊點(diǎn)點(diǎn)關(guān)注唄，愛(ài)你們】????

結(jié)語(yǔ)

謝謝你的閱讀，由于作者水平有限，難免有不足之處，若讀者發(fā)現(xiàn)問(wèn)題，還請(qǐng)批評(píng)，在留言區(qū)留言或者私信告知，我一定會(huì)盡快修改的。若各位大佬有什么好的解法，或者有意義的解法都可以在評(píng)論區(qū)展示額，萬(wàn)分謝謝。
寫(xiě)作不易，望各位老板點(diǎn)點(diǎn)贊，加個(gè)關(guān)注!??????

??

作者：后端小知識(shí)，CSDN后端領(lǐng)域新星創(chuàng)作者|阿里云專(zhuān)家博主

CSDN個(gè)人主頁(yè)：后端小知識(shí)

??GZH：后端小知識(shí)

??歡迎關(guān)注??點(diǎn)贊??收藏??留言??

到了這里，關(guān)于Hadoop生態(tài) | HDFS | Yarn | Hive | Hbase的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！