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

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

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

▲圖 　一個典型的 Hadoop 應用

一、HDFS

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

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

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

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

二、Yarn

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

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

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

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

三、Hive

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

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

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

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

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

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

四、HBase

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

1．特點

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

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

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

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

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

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

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

2．存儲

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

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

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

五、Spark及Spark Streaming

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

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

關于作者：

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