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

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

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

▲圖 　一個典型的 Hadoop 應用

一、HDFS

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

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

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

只有深刻理解了這兩點，才能理解為什么 Hadoop 有著高度的容錯性。高度容錯性是Hadoop 可以在通用硬件上運行的基礎。

二、Yarn

Yarn 是繼 Common、HDFS、MapReduce 之 后 Hadoop 的又一個子項目， 它是在MapReduceV2 中提出的。 

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

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

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

三、Hive

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

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

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

3）執(zhí)行 SQL 的延遲，Hive 的延遲相對較高，因為每次執(zhí)行都需要將 SQL 語句解析成MapReduce 程序。

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

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

四、HBase

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

1．特點

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

1）大：一個表可以有上億行，上百萬列（列多時，插入變慢）。

2）面向列：面向列（族）的存儲和權限控制，列（族）獨立檢索。

3）稀疏：對于空（null）的列，并不占用存儲空間，因此，表可以設計得非常稀疏。

4）每個單元格中的數(shù)據(jù)可以有多個版本，默認情況下版本號自動分配，是單元格插入 時的時間戳。 

5）HBase 中的數(shù)據(jù)都是字節(jié)，沒有類型定義具體的數(shù)據(jù)對象（因為系統(tǒng)需要適應不同 類型的數(shù)據(jù)格式和數(shù)據(jù)源，不能預先嚴格定義模式）。 

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

2．存儲

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

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

列式存儲的方式更適合 OLAP 型的應用場景，因為這類場景具有數(shù)據(jù)量較大以及查詢字段較少（往往都是聚合類函數(shù)）的特點。例如最近比較火的 ClickHouse 也是使用列式存儲的方式進行數(shù)據(jù)的存儲。

五、Spark及Spark Streaming

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

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

關于作者：

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