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

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

在大數(shù)據(jù)領(lǐng)域中最有名的就是 Hadoop 生態(tà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)備展開介紹），也有不同點(diǎn)，HDFS 是一個(gè)具有高度容錯(cuò)性的系統(tǒng)，適合部署在廉價(jià)的機(jī)器上。關(guān)于HDFS 這里主要想說兩點(diǎn)，默認(rèn)副本數(shù)的設(shè)置以及機(jī)架感知（Rack Awareness）。

HDFS 默認(rèn)副本數(shù)是 3，這是因?yàn)?Hadoop 有著高度的容錯(cuò)性，從數(shù)據(jù)冗余以及分布的角度來看，需要在同一機(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(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 沒有將資源管理相關(guān)功能與應(yīng)用程序相關(guān)功能拆分開，逐 漸成為集群的瓶頸，進(jìn)而導(dǎo)致集群出現(xiàn)可擴(kuò)展性變差、資源利用率下降以及多框架支持不 足等多方面的問題。 

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

三、Hive

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

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

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

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

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

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

四、HBase

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

1．特點(diǎn)

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

1）大：一個(gè)表可以有上億行，上百萬列（列多時(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é)，沒有類型定義具體的數(shù)據(jù)對(duì)象（因?yàn)橄到y(tǒng)需要適應(yīng)不同 類型的數(shù)據(jù)格式和數(shù)據(jù)源，不能預(yù)先嚴(yán)格定義模式）。 

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

2．存儲(chǔ)

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

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

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

五、Spark及Spark Streaming

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

Spark Streaming 是基于 Spark 的一個(gè)流式計(jì)算框架，它針對(duì)實(shí)時(shí)數(shù)據(jù)進(jìn)行處理和控制， 并可以將計(jì)算之后的結(jié)果寫入 HDFS。它與當(dāng)下比較火的實(shí)時(shí)計(jì)算框架 Flink 類似，但是二者在本質(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ì)開發(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ù)倉庫或數(shù)據(jù)平臺(tái)相關(guān)的工作。《企業(yè)級(jí)數(shù)據(jù)架構(gòu)：核心要素、架構(gòu)模型、數(shù)據(jù)管理與平臺(tái)搭建》作者。