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 引擎，它們之間有什麽不同呢？下面我們將從這兩個項目的介紹開始為大家做個深度解讀和比較。
- 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 接口完善，用戶社區也十分活躍。
- 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 更具有優勢。用戶應該根據自身的實際情況，選擇合適的引擎。
HBase場景 | 都是HBase上的SQL引擎，Kylin和Phoenix有什麽不同？