SQL on Hadoop 的真相（1）

轉自：http://blog.jobbole.com/86710/

這是一組系列博文，目的是詳盡介紹 SQL-on-Hadoop 。本系列的第一篇會介紹 Hadoop 系統的存儲引擎和在線事務處理（簡稱 OLTP ）；第二篇將介紹在線分析處理（簡稱 OLAP ）；第三篇將介紹對 Hadoop 引擎的改進以及在相關替代產品中如何選型等話題。

SQL on Hadoop 是一個既使人興奮又使人困擾的話題；

幾乎每週都有一個新的 SQL on Hadoop 支持項目彷佛抓住過社區注意力，哪怕只是一個短暫的瞬間；

在這個系列中，咱們會討論 Hadoop 系統上支持的每一類 SQL 解決方案，並對它們的架構，用例以及其餘作出誠實的討論。

Hadoop 引擎上的 SQL 有許多普遍的應用領域：

• 數據處理與在線分析處理（OLAP）
• 改進優化
• 在線事務處理（OLTP）

存儲引擎:

今天 Hadoop 主要有三個存儲引擎：分別是 Apache HBase、Apache Hadoop HDFS 和 Hadoop Accumulo。Apache Accumlo與 Hbase 很是類似，但它本是由 NSA 組織建立的項目，歷史上特別看重系統的安全性，尤爲在受權認證方面；在咱們看來，HBase 如今已經將安全特性方面的工做加入到項目中了，這樣的話後面就再也不進一步討論 Accumulo 了。

HBase 是一個分佈式鍵值存儲系統，數據是經過排好序的 map 形式存儲，也就是說數據都是通過對 key 列排序的，就像咱們下面要描述的那樣，HBase 典型的用例是 OLTP 應用，HDFS 是一個文件系統並可以以分佈式的方式存儲極大容量的數據集合；

HBase 在 HDFS 裏存儲的數據是以 HFile 格式存入的，這種格式不可配置。當不使用 HBase 而直接使用 HDFS 時，用戶是必需要選擇一種文件格式；

當進行文件格式選擇時是有許多要點須要考慮的，好比，

• 主要的讀取模式是怎樣的？是讀取全部行呢，仍是隻讀取全部行數據的一個子集；
• 數據是否是還可能含有非 ASCII 碼的文本內容？
• 哪些工具會讀寫這些數據呢（Apache Hive,  Spark ?）；

廣義上說有兩種文件格式與 HDFS 一塊兒使用，它們是 Columnar 和 row-wise。Columnar 格式例如 RCFILE、ORC 和 Apache Parquet等，這些類型能提供極致的壓縮性能（經過相似行程編碼的多種編碼方式進行壓縮），同時在只讀取行內少許列的場景下，也能提供較高的讀性能；好比你一行數據有五十到一百個列卻只需讀取七八個列的場合；

row-wise 格式，好比有受限定的文本格式、Sequence 文件格式以及 Apache Avro 格式，這些格式雖不提供有效的壓縮特性，但比較適合那些須要讀取表中大多數列的業務場景，也適合那種數據是以流的方式，每次小批量地導進表中的業務場景；

咱們建議排除文本格式，RCfile 和 Sequence 文件這幾種格式，由於他們都是歷史遺留的文件格式，另外不推薦也是由於集成歷史系統數據時它們有潛在的異常問題。咱們不建議使用這些格式是由於他們容易發生文本衝突（如非 ASCII 碼文本），性能差，還有除了文本方式以外不多有工具能夠讀取它們；

一旦咱們回答了選 columnar 仍是 row-wise 的問題，並排除了歷史遺留的那些文件格式，最重要的問題就變成了哪個工具和引擎可以讀取和寫入這些數據，大量的 Hadoop 生態鏈工具和引擎已經集成了 Avro 和 Parquet 項目，其中 ORC 是性能最好的 Apache Hive 文件格式。

在線事務處理

Apache HBase 項目提供 OLTP 類型的操做並極具擴展性，HBase 是惟一一個一般用於在線用戶數據存儲的Hadoop子模塊，可是 HBase 項目的目標並非作一個關係型數據庫管理系統，並且它也不是爲了替換 MySQL、Oracle 或者 DB2 這類關係型數據庫的，實際上 HBase 本身並不提供任何 SQL 接口，並且用戶還必須用 Java, Python, 或者 Ruby 編程來存儲和檢索數據；

Apache Phoenix 項目目標是基於 Apache HBase 提供 OLTP 類型的 SQL，Phoenix 容許用戶基於 HBase 數據模型執行插入更新和刪除操做，可是就像前面提到的同樣，HBase 數據模型從根本上就不一樣於傳統關係型數據庫，這樣的話 HBase 加 Phoenix 也仍然不是關係型數據庫的替代者；

HBase （以及Phoenix） 項目對於那些基於 RDBMS 之上，在應用擴展過程當中遇到麻煩的業務場景很是有用；傳統關係型數據庫領域裏的一個傳統解決方案是進行水平分區，但這種解決方案跑起來卻常遭受如下缺陷的困擾：

• 跨分片事務沒有獲得支持
• 增長機器進行水平擴容時須要複雜且昂貴的再分片過程，

就像通過分片的數據庫同樣，HBase 並不支持事務，但增長機器進行水平擴展和在HBase內部作負載再均衡，HBase 系統就要容易得多；

新的節點能夠被加入到 HBase 集羣中，HBase 可以自動分配數據分片到不一樣節點，若是假定分片數據庫和 HBase 都缺乏事務支持的話，HBase 就會因提供易於增長機器水平擴展的能力而勝出，有一些公司已經在作底層使用 HBase 架構基礎而上層增長事務 SQL 支持的產品，好比 Splice Machine公司等。