這是一組系列博文，目的是詳盡介紹 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公司等。