HBase場景 | 都是HBase上的SQL引擎，Kylin和Phoenix有什麼不一樣？

大數據時代，數據的價值愈來愈被重視，企業從海量大數據中挖掘所須要的信息，用來驅動業務決策以得到更大的商業價值。
與此同時，出現了愈來愈多的大數據技術幫助企業進行大數據分析，例如 Apache Hadoop，Hive，Spark，Presto，Drill，以及今天咱們即將介紹的 Apache Kylin 和 Apache Phoenix 項目等，都是使用 SQL 語言就能夠分析大數據，極大地下降了大數據的使用門檻。
這些大數據技術提供 SQL 查詢接口，不僅是由於 SQL 學習成本低，同時也和 SQL 擁有豐富而強大的表達能力、能知足絕大多數的分析需求的特性有關係。
瞭解 Apache Kylin 和 Apache Phoenix 的同窗都知道，它們都是使用 Apache HBase 作數據存儲和查詢，那麼，同爲 HBase 上的 SQL 引擎，它們之間有什麼不一樣呢？下面咱們將從這兩個項目的介紹開始爲你們作個深度解讀和比較。

1. Apache Kylin
   1.1 Apache Kylin 介紹
   Kylin 是一個分佈式的大數據分析引擎，提供在 Hadoop 之上的 SQL 接口和多維分析能力（OLAP），能夠作到在 TB 級的數據量上實現亞秒級的查詢響應。

上圖是 Kylin 的架構圖，從圖中能夠看出，Kylin 利用 MapReduce/Spark 將原始數據進行聚合計算，轉成了 OLAP Cube 並加載到 HBase 中，以 Key-Value 的形式存儲。Cube 按照時間範圍劃分爲多個 segment，每一個 segment 是一張 HBase 表，每張表會根據數據大小切分紅多個 region。Kylin 選擇 HBase 做爲存儲引擎，是由於 HBase 具備延遲低，容量大，使用普遍，API完備等特性，此外它的 Hadoop 接口完善，用戶社區也十分活躍。

2. Apache Phoenix
   2.1 Apache Phoenix 介紹
   phoenix 是一個 Hadoop 上的 OLTP 和業務數據分析引擎，爲用戶提供操做 HBase 的 SQL 接口，結合了具備完整 ACID 事務功能的標準 SQL 和 JDBC API，以及來自 NoSQL 的後期綁定，具備讀取模式靈活的優勢。
   下圖爲 Phoenix 的架構圖，從圖中能夠看出，Phoenix 分爲 client 和 server，其中 client 又分爲 thin（本質上是一個 JDBC 驅動，所依賴的第三方類較少）和非 thin （所依賴的第三方類較多）兩種；server 是針對 thin client 而言的，爲 standalone 模式，是由一臺 Java 服務器組成，表明客戶端管理 Phoenix 的鏈接，能夠進行橫向擴展，啓動方式也很簡單，經過 bin/queryserver.py start 便可。

接下來咱們進行一個二者的對比。

3.Kylin 和 Phoenix 的對比
3.1 二者優缺點對比
咱們先來看看 Kylin 和 Phoenix 各自的優勢是什麼。Kylin 的優勢主要有如下幾點：

支持雪花/星型模型；
亞秒級查詢響應；
支持 ANSI-SQL，可經過 ODBC，JDBC 以及 RESTful API 進行訪問；
支持百億、千億甚至萬億級別交互式分析；
無縫與 BI 工具集成；
支持增量刷新；
既支持歷史數據也支持流式數據；
易用的管理頁面和 API。

Phoenix 的優勢則主要是如下幾點：

支持明細和聚合查詢；
支持 insert, update, delete 操做，其使用 upsert 來代替 insert 和 update；
較好的利用 HBase 的優勢，如 row timestamp，將其與 HBase 原生的 row timestamp 映射起來，有助於 Phoenix 利用 HBase 針對存儲文件的時間範圍提供的多種優化和 Phoenix 內置的各式各樣的查詢優化；
支持多種函數：聚合、String、時間和日期、數字、數組、數學和其它函數；
支持具備完整 ACID 語義的跨行及跨表事務；
支持多租戶；
支持索引（二級索引），遊標。

固然，Kylin 和 Phoenix 也都有一些還有待提高的不足之處。Kylin 的不足主要是體如今首先因爲 Kylin 是一個分析引擎，只讀，不支持 insert，update，delete 等 SQL 操做，用戶修改數據的話須要從新批量導入（構建）；其次，Kylin 用戶須要預先創建模型後加載數據到 Cube 後纔可進行查詢；最後，使用 Kylin 的建模人員須要瞭解必定的數據倉庫知識。
Phoenix 的不足則主要體如今：首先，其二級索引的使用有必定的限制，只有當查詢中全部的列都在索引或覆蓋索引中才生效且成本較高，在使用以前還需配置；其次，範圍掃描的使用有必定的限制，只有當使用了很多於一個在主鍵約束中的先導列時才生效；最後，建立表時必須包含主鍵 ，對別名支持不友好。
3.2 HBase 表存儲格式的對比
Kylin 將數據列區分紅維度和度量：維度的順序與 HBase 中的 Rowkey 創建關係從而將 Cube 數據存儲，維度的值會被編碼爲字節，而後多個維度的值被拼接在一塊兒組成 Rowkey，Rowkey 的格式爲 Shard ID（2 字節）+ Cuboid ID（8 字節，標記有哪幾個列）+ 維度值；度量的值會被序列化爲字節數組，而後以 column 的方式存儲；多個度量值能夠放在同一個列簇中，也能夠放在不一樣列簇中。以下圖所示：

Phoenix 在列名與 HBase 列限定符之間引入了一個間接層，將 HBase 非關係型形式轉換成關係型數據模型，在建立表時默認會將 PK 與 HBase 中表的 Rowkey 映射起來，PK 支持多字段組合，剩下的列能夠根據需求進行選擇，列簇若是未顯式定義，則會被忽略，Qualifier 會轉換成表的字段名。以下圖所示：

3.3 查詢方式對比
Kylin 查詢時會將 SQL 經過 Apache Calcite 進行解析和優化，轉化成對 HBase 的 RPC 訪問。Kylin 會將計算邏輯下壓到 HBase Region Server 中使用 Coprocessor 並行運行，每一個 RS 返回過濾聚合後的數據給 Kylin 節點，Kylin 作最後的處理後返回給客戶端。由於大量的計算在 Cube 生成的時候已經完成，所以 Kylin 的查詢效率很是高，一般在毫秒到秒級。
Kylin 在 Insight 頁面提供 SQL 查詢窗口；也可以經過 REST API 發送請求的方式進行查詢；還可以快速的與其餘 BI 工具集成並使用 BI 工具自帶的方式進行查詢。
Phoenix 直接使用 HBase API，以及協處理器和自定義過濾器，從而使得查詢的效率更好。對於查詢，Phoenix 能夠根據 region 的邊界進行分塊並在客戶端並行運行以減小延遲。聚合操做將在服務器端的協處理器中完成（這點與 Kylin 相似），返回到客戶端的數據量是進行過壓縮的，而不是所有返回。
Phoenix 是經過命令行的方式進行查詢（既能夠輸入單條 SQL 語句，也能夠執行 SQL 文件）；也能夠經過界面進行查詢，但需額外安裝 Squirrel。
3.4 查詢優化方式對比
Kylin 查詢優化方法比較多樣，既有邏輯層的維度減枝優化（層級，必須，聯合，推導等），編碼優化，rowkey 優化等，也有存儲層的優化，如按某個維度切 shard，region 大小劃分優化，segment 自動合併等，具體能夠參考 Kylin 的文檔。用戶能夠根據本身的數據特徵、性能需求使用不一樣的策略，從而在空間和時間之間找到一個平衡點。
爲了使得查詢效率更高，Phoenix 能夠在表上加索引，不一樣的索引有不一樣的適用場景：全局索引適用於大量讀取的場景，且要求查詢中引用的全部列都包含在索引中；本地索引適用於大量寫入，空間有限的場景。索引會將數據的值進行拷貝，額外增長了開銷，且使用二級索引還需在 HBase 的配置文件中進行相應配置。數據總不會是完美分佈的，HBase 順序寫入時（行鍵單調遞增）可能會致使熱點問題，這時能夠經過加鹽操做來解決，Phoenix 能夠爲 key 自動加鹽。
從上述內容能夠看出：
1）Kylin 和 Phoenix 雖然同爲 Hadoop/HBase 上的 SQL 引擎，二者的定位不一樣，一個是 OLAP，另外一個是 OLTP，服務於不一樣的場景；
2）Phoenix 更多的是適用於以往關係型數據庫的相關操做，當查詢語句是點查找和小範圍掃描時，Phoenix 能夠比較好地知足，而它不太適合大量 scan 類型的 OLAP 查詢，或查詢的模式較爲靈活的場景；
3）Kylin 是一個只讀型的分析引擎，不適合細粒度修改數據，但適合作海量數據的交互式在線分析，一般跟數據倉庫以及 BI 工具結合使用，目標用戶爲業務分析人員。
下面咱們作一個簡單的性能測試，由於 Kylin 不支持數據寫入，所以咱們不得不測試數據的查詢性能，使用相同 HBase 集羣和數據集。
3.5 性能對比
咱們準備的測試環境爲 CDH 5.15.1，1個 Master，7個 Region Server，每一個節點 8 核心 58G 內存，使用 Star Schema Benchmark 數據進行測試。其中單表 Lineorder 表數據量爲 3 千萬，大小爲 8.70 GB。Phoenix 導入時間: 7mins 9sec，Kylin 導入時間: 32mins 8sec。多表 Lineorder 數據量 750 萬，大小爲 10 GB。

圖 5 是一個單表查詢場景的分析，從上咱們能夠看出， 針對於一張表的查詢，Phoenix 查詢的耗時是 Kylin 的幾十甚至是幾百倍，加入索引後，Phoenix 的查詢速度有了較爲顯著的提高，但仍然是 Kylin 的十幾倍甚至幾十倍，所以單表查詢 Kylin 具備明顯優點。
圖6是一個多表 join 查詢的場景，從上圖能夠看出，對於多表 join 的狀況，Kylin 查詢依舊很是快，由於 join 在 Cube 構建階段已經完成了；Phoenix 加入索引後時間並無較爲顯著的減小，耗時仍然是 Kylin 的幾十倍甚至幾百倍。
所以，不管是單表仍是多表查詢，Kylin 查詢的時間都遠遠小於 Phoenix，固然這是由於有了預計算的緣由。

4.總結簡單來看，Apache Phoenix 與Apache Kylin 彷佛都是 Hadoop/HBase 上的 SQL 引擎，實際上它們服務於不一樣的目的，Phoenix 適用於頻繁寫但讀取少的事務型場景，Kylin 則適合寫少讀多的分析型場景；在 OLTP 的場景中，Phoenix 具備低延遲、高併發、事務性等優勢；在 OLAP 的場景下，Kylin 更具備優點。用戶應該根據自身的實際狀況，選擇合適的引擎。