HBase場(chǎng)景 | 都是HBase上的SQL引擎，Kylin和Phoenix有什么不同？

大數(shù)據(jù)時(shí)代，數(shù)據(jù)的價(jià)值越來越被重視，企業(yè)從海量大數(shù)據(jù)中挖掘所需要的信息，用來驅(qū)動(dòng)業(yè)務(wù)決策以獲得更大的商業(yè)價(jià)值。
與此同時(shí)，出現(xiàn)了越來越多的大數(shù)據(jù)技術(shù)幫助企業(yè)進(jìn)行大數(shù)據(jù)分析，例如 Apache Hadoop，Hive，Spark，Presto，Drill，以及今天我們即將介紹的 Apache Kylin 和 Apache Phoenix 項(xiàng)目等，都是使用 SQL 語(yǔ)言就可以分析大數(shù)據(jù)，極大地降低了大數(shù)據(jù)的使用門檻。
這些大數(shù)據(jù)技術(shù)提供 SQL 查詢接口，不只是因?yàn)?SQL 學(xué)習(xí)成本低，同時(shí)也和 SQL 擁有豐富而強(qiáng)大的表達(dá)能力、能滿足絕大多數(shù)的分析需求的特性有關(guān)系。
了解 Apache Kylin 和 Apache Phoenix 的同學(xué)都知道，它們都是使用 Apache HBase 做數(shù)據(jù)存儲(chǔ)和查詢，那么，同為 HBase 上的 SQL 引擎，它們之間有什么不同呢？下面我們將從這兩個(gè)項(xiàng)目的介紹開始為大家做個(gè)深度解讀和比較。

1. Apache Kylin
   1.1 Apache Kylin 介紹
   Kylin 是一個(gè)分布式的大數(shù)據(jù)分析引擎，提供在 Hadoop 之上的 SQL 接口和多維分析能力（OLAP），可以做到在 TB 級(jí)的數(shù)據(jù)量上實(shí)現(xiàn)亞秒級(jí)的查詢響應(yīng)。

上圖是 Kylin 的架構(gòu)圖，從圖中可以看出，Kylin 利用 MapReduce/Spark 將原始數(shù)據(jù)進(jìn)行聚合計(jì)算，轉(zhuǎn)成了 OLAP Cube 并加載到 HBase 中，以 Key-Value 的形式存儲(chǔ)。Cube 按照時(shí)間范圍劃分為多個(gè) segment，每個(gè) segment 是一張 HBase 表，每張表會(huì)根據(jù)數(shù)據(jù)大小切分成多個(gè) region。Kylin 選擇 HBase 作為存儲(chǔ)引擎，是因?yàn)?HBase 具有延遲低，容量大，使用廣泛，API完備等特性，此外它的 Hadoop 接口完善，用戶社區(qū)也十分活躍。

2. Apache Phoenix
   2.1 Apache Phoenix 介紹
   phoenix 是一個(gè) Hadoop 上的 OLTP 和業(yè)務(wù)數(shù)據(jù)分析引擎，為用戶提供操作 HBase 的 SQL 接口，結(jié)合了具有完整 ACID 事務(wù)功能的標(biāo)準(zhǔn) SQL 和 JDBC API，以及來自 NoSQL 的后期綁定，具有讀取模式靈活的優(yōu)點(diǎn)。
   下圖為 Phoenix 的架構(gòu)圖，從圖中可以看出，Phoenix 分為 client 和 server，其中 client 又分為 thin（本質(zhì)上是一個(gè) JDBC 驅(qū)動(dòng)，所依賴的第三方類較少）和非 thin （所依賴的第三方類較多）兩種；server 是針對(duì) thin client 而言的，為 standalone 模式，是由一臺(tái) Java 服務(wù)器組成，代表客戶端管理 Phoenix 的連接，可以進(jìn)行橫向擴(kuò)展，啟動(dòng)方式也很簡(jiǎn)單，通過 bin/queryserver.py start 即可。

接下來我們進(jìn)行一個(gè)兩者的對(duì)比。

3.Kylin 和 Phoenix 的對(duì)比
3.1 兩者優(yōu)缺點(diǎn)對(duì)比
我們先來看看 Kylin 和 Phoenix 各自的優(yōu)點(diǎn)是什么。Kylin 的優(yōu)點(diǎn)主要有以下幾點(diǎn)：

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

Phoenix 的優(yōu)點(diǎn)則主要是以下幾點(diǎn)：

支持明細(xì)和聚合查詢；
支持 insert, update, delete 操作，其使用 upsert 來代替 insert 和 update；
較好的利用 HBase 的優(yōu)點(diǎn)，如 row timestamp，將其與 HBase 原生的 row timestamp 映射起來，有助于 Phoenix 利用 HBase 針對(duì)存儲(chǔ)文件的時(shí)間范圍提供的多種優(yōu)化和 Phoenix 內(nèi)置的各式各樣的查詢優(yōu)化；
支持多種函數(shù)：聚合、String、時(shí)間和日期、數(shù)字、數(shù)組、數(shù)學(xué)和其它函數(shù)；
支持具有完整 ACID 語(yǔ)義的跨行及跨表事務(wù)；
支持多租戶；
支持索引（二級(jí)索引），游標(biāo)。

當(dāng)然，Kylin 和 Phoenix 也都有一些還有待提升的不足之處。Kylin 的不足主要是體現(xiàn)在首先由于 Kylin 是一個(gè)分析引擎，只讀，不支持 insert，update，delete 等 SQL 操作，用戶修改數(shù)據(jù)的話需要重新批量導(dǎo)入（構(gòu)建）；其次，Kylin 用戶需要預(yù)先建立模型后加載數(shù)據(jù)到 Cube 后才可進(jìn)行查詢；最后，使用 Kylin 的建模人員需要了解一定的數(shù)據(jù)倉(cāng)庫(kù)知識(shí)。
Phoenix 的不足則主要體現(xiàn)在：首先，其二級(jí)索引的使用有一定的限制，只有當(dāng)查詢中所有的列都在索引或覆蓋索引中才生效且成本較高，在使用之前還需配置；其次，范圍掃描的使用有一定的限制，只有當(dāng)使用了不少于一個(gè)在主鍵約束中的先導(dǎo)列時(shí)才生效；最后，創(chuàng)建表時(shí)必須包含主鍵 ，對(duì)別名支持不友好。
3.2 HBase 表存儲(chǔ)格式的對(duì)比
Kylin 將數(shù)據(jù)列區(qū)分成維度和度量：維度的順序與 HBase 中的 Rowkey 建立關(guān)系從而將 Cube 數(shù)據(jù)存儲(chǔ)，維度的值會(huì)被編碼為字節(jié)，然后多個(gè)維度的值被拼接在一起組成 Rowkey，Rowkey 的格式為 Shard ID（2 字節(jié)）+ Cuboid ID（8 字節(jié)，標(biāo)記有哪幾個(gè)列）+ 維度值；度量的值會(huì)被序列化為字節(jié)數(shù)組，然后以 column 的方式存儲(chǔ)；多個(gè)度量值可以放在同一個(gè)列簇中，也可以放在不同列簇中。如下圖所示：

Phoenix 在列名與 HBase 列限定符之間引入了一個(gè)間接層，將 HBase 非關(guān)系型形式轉(zhuǎn)換成關(guān)系型數(shù)據(jù)模型，在創(chuàng)建表時(shí)默認(rèn)會(huì)將 PK 與 HBase 中表的 Rowkey 映射起來，PK 支持多字段組合，剩下的列可以根據(jù)需求進(jìn)行選擇，列簇如果未顯式定義，則會(huì)被忽略，Qualifier 會(huì)轉(zhuǎn)換成表的字段名。如下圖所示：

3.3 查詢方式對(duì)比
Kylin 查詢時(shí)會(huì)將 SQL 通過 Apache Calcite 進(jìn)行解析和優(yōu)化，轉(zhuǎn)化成對(duì) HBase 的 RPC 訪問。Kylin 會(huì)將計(jì)算邏輯下壓到 HBase Region Server 中使用 Coprocessor 并行運(yùn)行，每個(gè) RS 返回過濾聚合后的數(shù)據(jù)給 Kylin 節(jié)點(diǎn)，Kylin 做最后的處理后返回給客戶端。因?yàn)榇罅康挠?jì)算在 Cube 生成的時(shí)候已經(jīng)完成，因此 Kylin 的查詢效率非常高，通常在毫秒到秒級(jí)。
Kylin 在 Insight 頁(yè)面提供 SQL 查詢窗口；也能夠通過 REST API 發(fā)送請(qǐng)求的方式進(jìn)行查詢；還能夠快速的與其他 BI 工具集成并使用 BI 工具自帶的方式進(jìn)行查詢。
Phoenix 直接使用 HBase API，以及協(xié)處理器和自定義過濾器，從而使得查詢的效率更好。對(duì)于查詢，Phoenix 可以根據(jù) region 的邊界進(jìn)行分塊并在客戶端并行運(yùn)行以減少延遲。聚合操作將在服務(wù)器端的協(xié)處理器中完成（這點(diǎn)與 Kylin 類似），返回到客戶端的數(shù)據(jù)量是進(jìn)行過壓縮的，而不是全部返回。
Phoenix 是通過命令行的方式進(jìn)行查詢（既可以輸入單條 SQL 語(yǔ)句，也可以執(zhí)行 SQL 文件）；也可以通過界面進(jìn)行查詢，但需額外安裝 Squirrel。
3.4 查詢優(yōu)化方式對(duì)比
Kylin 查詢優(yōu)化方法比較多樣，既有邏輯層的維度減枝優(yōu)化（層級(jí)，必須，聯(lián)合，推導(dǎo)等），編碼優(yōu)化，rowkey 優(yōu)化等，也有存儲(chǔ)層的優(yōu)化，如按某個(gè)維度切 shard，region 大小劃分優(yōu)化，segment 自動(dòng)合并等，具體可以參考 Kylin 的文檔。用戶可以根據(jù)自己的數(shù)據(jù)特征、性能需求使用不同的策略，從而在空間和時(shí)間之間找到一個(gè)平衡點(diǎn)。
為了使得查詢效率更高，Phoenix 可以在表上加索引，不同的索引有不同的適用場(chǎng)景：全局索引適用于大量讀取的場(chǎng)景，且要求查詢中引用的所有列都包含在索引中；本地索引適用于大量寫入，空間有限的場(chǎng)景。索引會(huì)將數(shù)據(jù)的值進(jìn)行拷貝，額外增加了開銷，且使用二級(jí)索引還需在 HBase 的配置文件中進(jìn)行相應(yīng)配置。數(shù)據(jù)總不會(huì)是完美分布的，HBase 順序?qū)懭霑r(shí)（行鍵單調(diào)遞增）可能會(huì)導(dǎo)致熱點(diǎn)問題，這時(shí)可以通過加鹽操作來解決，Phoenix 可以為 key 自動(dòng)加鹽。
從上述內(nèi)容可以看出：
1）Kylin 和 Phoenix 雖然同為 Hadoop/HBase 上的 SQL 引擎，兩者的定位不同，一個(gè)是 OLAP，另一個(gè)是 OLTP，服務(wù)于不同的場(chǎng)景；
2）Phoenix 更多的是適用于以往關(guān)系型數(shù)據(jù)庫(kù)的相關(guān)操作，當(dāng)查詢語(yǔ)句是點(diǎn)查找和小范圍掃描時(shí)，Phoenix 可以比較好地滿足，而它不太適合大量 scan 類型的 OLAP 查詢，或查詢的模式較為靈活的場(chǎng)景；
3）Kylin 是一個(gè)只讀型的分析引擎，不適合細(xì)粒度修改數(shù)據(jù)，但適合做海量數(shù)據(jù)的交互式在線分析，通常跟數(shù)據(jù)倉(cāng)庫(kù)以及 BI 工具結(jié)合使用，目標(biāo)用戶為業(yè)務(wù)分析人員。
下面我們做一個(gè)簡(jiǎn)單的性能測(cè)試，因?yàn)?Kylin 不支持?jǐn)?shù)據(jù)寫入，因此我們不得不測(cè)試數(shù)據(jù)的查詢性能，使用相同 HBase 集群和數(shù)據(jù)集。
3.5 性能對(duì)比
我們準(zhǔn)備的測(cè)試環(huán)境為 CDH 5.15.1，1個(gè) Master，7個(gè) Region Server，每個(gè)節(jié)點(diǎn) 8 核心 58G 內(nèi)存，使用 Star Schema Benchmark 數(shù)據(jù)進(jìn)行測(cè)試。其中單表 Lineorder 表數(shù)據(jù)量為 3 千萬，大小為 8.70 GB。Phoenix 導(dǎo)入時(shí)間: 7mins 9sec，Kylin 導(dǎo)入時(shí)間: 32mins 8sec。多表 Lineorder 數(shù)據(jù)量 750 萬，大小為 10 GB。

圖 5 是一個(gè)單表查詢場(chǎng)景的分析，從上我們可以看出， 針對(duì)于一張表的查詢，Phoenix 查詢的耗時(shí)是 Kylin 的幾十甚至是幾百倍，加入索引后，Phoenix 的查詢速度有了較為顯著的提升，但仍然是 Kylin 的十幾倍甚至幾十倍，因此單表查詢 Kylin 具有明顯優(yōu)勢(shì)。
圖6是一個(gè)多表 join 查詢的場(chǎng)景，從上圖可以看出，對(duì)于多表 join 的情況，Kylin 查詢依舊非?？?，因?yàn)?join 在 Cube 構(gòu)建階段已經(jīng)完成了；Phoenix 加入索引后時(shí)間并沒有較為顯著的減少，耗時(shí)仍然是 Kylin 的幾十倍甚至幾百倍。
因此，無論是單表還是多表查詢，Kylin 查詢的時(shí)間都遠(yuǎn)遠(yuǎn)小于 Phoenix，當(dāng)然這是因?yàn)橛辛祟A(yù)計(jì)算的原因。

4.總結(jié)
簡(jiǎn)單來看，Apache Phoenix 與Apache Kylin 似乎都是 Hadoop/HBase 上的 SQL 引擎，實(shí)際上它們服務(wù)于不同的目的，Phoenix 適用于頻繁寫但讀取少的事務(wù)型場(chǎng)景，Kylin 則適合寫少讀多的分析型場(chǎng)景；在 OLTP 的場(chǎng)景中，Phoenix 具有低延遲、高并發(fā)、事務(wù)性等優(yōu)點(diǎn)；在 OLAP 的場(chǎng)景下，Kylin 更具有優(yōu)勢(shì)。用戶應(yīng)該根據(jù)自身的實(shí)際情況，選擇合適的引擎。