作者 | 翟娜
大數(shù)據(jù)時代一疯，數(shù)據(jù)的價值越來越被重視，企業(yè)從海量大數(shù)據(jù)中挖掘所需要的信息夺姑，用來驅(qū)動業(yè)務決策以獲得更大的商業(yè)價值墩邀。
與此同時，出現(xiàn)了越來越多的大數(shù)據(jù)技術幫助企業(yè)進行大數(shù)據(jù)分析盏浙，例如 Apache Hadoop磕蒲，Hive留潦，Spark，Presto辣往，Drill兔院，以及今天我們即將介紹的 Apache Kylin 和 Apache Phoenix 項目等，都是使用 SQL 語言就可以分析大數(shù)據(jù)站削，極大地降低了大數(shù)據(jù)的使用門檻坊萝。
這些大數(shù)據(jù)技術提供 SQL 查詢接口，不只是因為 SQL 學習成本低许起，同時也和 SQL 擁有豐富而強大的表達能力十偶、能滿足絕大多數(shù)的分析需求的特性有關系。
了解 Apache Kylin 和 Apache Phoenix 的同學都知道园细，它們都是使用 Apache HBase 做數(shù)據(jù)存儲和查詢惦积，那么，同為 HBase 上的 SQL 引擎猛频，它們之間有什么不同呢狮崩？下面我們將從這兩個項目的介紹開始為大家做個深度解讀和比較。
1鹿寻、Apache Kylin
1.1Apache Kylin 介紹
Kylin 是一個分布式的大數(shù)據(jù)分析引擎睦柴，提供在 Hadoop 之上的 SQL 接口和多維分析能力（OLAP），可以做到在 TB 級的數(shù)據(jù)量上實現(xiàn)亞秒級的查詢響應毡熏。
圖1 Kylin 架構(gòu)
上圖是 Kylin 的架構(gòu)圖坦敌，從圖中可以看出，Kylin 利用 MapReduce/Spark 將原始數(shù)據(jù)進行聚合計算痢法，轉(zhuǎn)成了 OLAP Cube 并加載到 HBase 中狱窘，以 Key-Value 的形式存儲。Cube 按照時間范圍劃分為多個 segment财搁，每個 segment 是一張 HBase 表蘸炸，每張表會根據(jù)數(shù)據(jù)大小切分成多個 region。Kylin 選擇 HBase 作為存儲引擎妇拯，是因為 HBase 具有延遲低幻馁，容量大洗鸵，使用廣泛越锈，API完備等特性，此外它的 Hadoop 接口完善膘滨，用戶社區(qū)也十分活躍甘凭。
2、Apache Phoenix
2.1 Apache Phoenix 介紹
Phoenix 是一個 Hadoop 上的 OLTP 和業(yè)務數(shù)據(jù)分析引擎火邓，為用戶提供操作 HBase 的 SQL 接口丹弱，結(jié)合了具有完整 ACID 事務功能的標準 SQL 和 JDBC API德撬，以及來自 NoSQL 的后期綁定，具有讀取模式靈活的優(yōu)點躲胳。
下圖為 Phoenix 的架構(gòu)圖蜓洪，從圖中可以看出，Phoenix 分為 client 和 server坯苹，其中 client 又分為 thin（本質(zhì)上是一個 JDBC 驅(qū)動隆檀，所依賴的第三方類較少）和非 thin （所依賴的第三方類較多）兩種；server 是針對 thin client 而言的粹湃，為 standalone 模式恐仑，是由一臺 Java 服務器組成，代表客戶端管理 Phoenix 的連接为鳄，可以進行橫向擴展裳仆，啟動方式也很簡單，通過?bin/queryserver.py start?即可孤钦。
圖2 Phoenix 架構(gòu)圖
接下來我們進行一個兩者的對比歧斟。
3、Kylin 和 Phoenix 的對比
3.1 兩者優(yōu)缺點對比
我們先來看看 Kylin 和 Phoenix 各自的優(yōu)點是什么司训。Kylin 的優(yōu)點主要有以下幾點：
1. 支持雪花/星型模型构捡；
2. 亞秒級查詢響應；
3. 支持 ANSI-SQL壳猜，可通過 ODBC勾徽，JDBC 以及 RESTful API 進行訪問；
4. 支持百億统扳、千億甚至萬億級別交互式分析喘帚；
5. 無縫與 BI 工具集成；
6. 支持增量刷新咒钟；
7. 既支持歷史數(shù)據(jù)也支持流式數(shù)據(jù)吹由；
8. 易用的管理頁面和 API。
Phoenix 的優(yōu)點則主要是以下幾點：
1. 支持明細和聚合查詢朱嘴；
2. 支持 insert倾鲫，update，delete 操作萍嬉，其使用 upsert 來代替 insert 和 update乌昔；
3. 較好的利用 HBase 的優(yōu)點，如 row timestamp壤追，將其與 HBase 原生的 row timestamp 映射起來磕道，有助于 Phoenix 利用 HBase 針對存儲文件的時間范圍提供的多種優(yōu)化和 Phoenix 內(nèi)置的各式各樣的查詢優(yōu)化；
4. 支持多種函數(shù)：聚合行冰、String溺蕉、時間和日期伶丐、數(shù)字、數(shù)組疯特、數(shù)學和其它函數(shù)哗魂；
5. 支持具有完整 ACID 語義的跨行及跨表事務；
6. 支持多租戶漓雅；
7. 支持索引（二級索引）啡彬，游標。
當然故硅，Kylin 和 Phoenix 也都有一些還有待提升的不足之處庶灿，Kylin 的不足主要是體現(xiàn)在首先由于 Kylin 是一個分析引擎，只讀吃衅，不支持 insert, update, delete 等 SQL 操作往踢，用戶修改數(shù)據(jù)的話需要重新批量導入（構(gòu)建）；其次徘层，Kylin 用戶需要預先建立模型后加載數(shù)據(jù)到 Cube 后才可進行查詢峻呕；最后，使用 Kylin 的建模人員需要了解一定的數(shù)據(jù)倉庫知識趣效。
Phoenix 的不足則主要體現(xiàn)在：首先瘦癌，其二級索引的使用有一定的限制，只有當查詢中所有的列都在索引或覆蓋索引中才生效且成本較高跷敬，在使用之前還需配置讯私；其次，范圍掃描的使用有一定的限制西傀，只有當使用了不少于一個在主鍵約束中的先導列時才生效斤寇；最后，創(chuàng)建表時必須包含主鍵 拥褂，對別名支持不友好娘锁。
3.2 HBase 表存儲格式的對比
Kylin 將數(shù)據(jù)列區(qū)分成維度和度量：維度的順序與 HBase 中的 Rowkey 建立關系從而將 Cube 數(shù)據(jù)存儲，維度的值會被編碼為字節(jié)饺鹃，然后多個維度的值被拼接在一起組成 Rowkey莫秆，Rowkey 的格式為 Shard ID（2 字節(jié)）+ Cuboid ID（8 字節(jié)，標記有哪幾個列）+ 維度值悔详；度量的值會被序列化為字節(jié)數(shù)組镊屎，然后以 column 的方式存儲；多個度量值可以放在同一個列簇中伟端，也可以放在不同列簇中杯道。如下圖所示：
圖3 Kylin 的 HBase Table 格式
Phoenix 在列名與 HBase 列限定符之間引入了一個間接層匪煌，將 HBase 非關系型形式轉(zhuǎn)換成關系型數(shù)據(jù)模型责蝠，在創(chuàng)建表時默認會將 PK 與 HBase 中表的 Rowkey 映射起來,PK 支持多字段組合党巾，剩下的列可以根據(jù)需求進行選擇，列簇如果未顯式定義霜医，則會被忽略齿拂，Qualifier 會轉(zhuǎn)換成表的字段名。如下圖所示：
圖4 Phoenix 數(shù)據(jù)模型
3.3 查詢方式對比
Kylin 查詢時會將 SQL 通過 Apache Calcite 進行解析和優(yōu)化肴敛，轉(zhuǎn)化成對 HBase 的 RPC 訪問署海。Kylin 會將計算邏輯下壓到 HBase Region Server 中使用 Coprocessor 并行運行，每個 RS 返回過濾聚合后的數(shù)據(jù)給 Kylin 節(jié)點医男，Kylin 做最后的處理后返回給客戶端砸狞。因為大量的計算在 Cube 生成的時候已經(jīng)完成，因此 Kylin 的查詢效率非常高镀梭，通常在毫秒到秒級刀森。
Kylin 在 Insight 頁面提供 SQL 查詢窗口；也能夠通過 REST API 發(fā)送請求的方式進行查詢报账；還能夠快速的與其他 BI 工具集成并使用 BI 工具自帶的方式進行查詢研底。
Phoenix 直接使用 HBase API，以及協(xié)處理器和自定義過濾器透罢，從而使得查詢的效率更好榜晦。對于查詢，Phoenix 可以根據(jù) region 的邊界進行分塊并在客戶端并行運行以減少延遲羽圃。聚合操作將在服務器端的協(xié)處理器中完成（這點與 Kylin 類似）乾胶，返回到客戶端的數(shù)據(jù)量是進行過壓縮的，而不是全部返回朽寞。
Phoenix 是通過命令行的方式進行查詢（既可以輸入單條 SQL 語句胚吁，也可以執(zhí)行 SQL 文件）；也可以通過界面進行查詢愁憔，但需額外安裝 Squirrel腕扶。
3.4 查詢優(yōu)化方式對比
Kylin 查詢優(yōu)化方法比較多樣，既有邏輯層的維度減枝優(yōu)化（層級吨掌，必須半抱，聯(lián)合，推導等）膜宋，編碼優(yōu)化窿侈，rowkey 優(yōu)化等，也有存儲層的優(yōu)化秋茫，如按某個維度切 shard史简，region 大小劃分優(yōu)化，segment 自動合并等肛著，具體可以參考 Kylin 的文檔圆兵。用戶可以根據(jù)自己的數(shù)據(jù)特征跺讯、性能需求使用不同的策略，從而在空間和時間之間找到一個平衡點殉农。
為了使得查詢效率更高刀脏，Phoenix 可以在表上加索引，不同的索引有不同的適用場景：全局索引適用于大量讀取的場景超凳，且要求查詢中引用的所有列都包含在索引中愈污；本地索引適用于大量寫入，空間有限的場景轮傍。索引會將數(shù)據(jù)的值進行拷貝暂雹，額外增加了開銷，且使用二級索引還需在 HBase 的配置文件中進行相應配置创夜。數(shù)據(jù)總不會是完美分布的擎析，HBase 順序?qū)懭霑r（行鍵單調(diào)遞增）可能會導致熱點問題，這時可以通過加鹽操作來解決挥下，Phoenix 可以為 key 自動加鹽揍魂。
從上述內(nèi)容可以看出：
1）Kylin 和 Phoenix 雖然同為 Hadoop/HBase 上的 SQL 引擎，兩者的定位不同棚瘟，一個是 OLAP现斋，另一個是 OLTP，服務于不同的場景偎蘸；
2）Phoenix 更多的是適用于以往關系型數(shù)據(jù)庫的相關操作庄蹋，當查詢語句是點查找和小范圍掃描時，Phoenix 可以比較好地滿足迷雪，而它不太適合大量 scan 類型的 OLAP 查詢限书，或查詢的模式較為靈活的場景；
3）Kylin 是一個只讀型的分析引擎章咧，不適合細粒度修改數(shù)據(jù)倦西，但適合做海量數(shù)據(jù)的交互式在線分析，通常跟數(shù)據(jù)倉庫以及 BI 工具結(jié)合使用赁严，目標用戶為業(yè)務分析人員扰柠。
下面我們做一個簡單的性能測試，因為 Kylin 不支持數(shù)據(jù)寫入疼约，因此我們不得不測試數(shù)據(jù)的查詢性能卤档，使用相同 HBase 集群和數(shù)據(jù)集。
3.5 性能對比
我們準備的測試環(huán)境為 CDH 5.15.1程剥，1個 Master劝枣，7個 Region Server，每個節(jié)點 8 核心 58G 內(nèi)存，使用 Star Schema Benchmark 數(shù)據(jù)進行測試舔腾。其中單表 Lineorder 表數(shù)據(jù)量為 3 千萬溪胶，大小為 8.70 GB。Phoenix 導入時間: 7mins 9sec, Kylin 導入時間: 32mins 8sec琢唾。多表 Lineorder 數(shù)據(jù)量 750 萬，大小為 10 GB盾饮。具體的 SQL 語句參見Github采桃。
圖5 單表對比圖
圖 5 是一個單表查詢場景的分析，從上我們可以看出丘损， 針對于一張表的查詢普办，Phoenix 查詢的耗時是 Kylin 的幾十甚至是幾百倍，加入索引后徘钥，Phoenix 的查詢速度有了較為顯著的提升衔蹲，但仍然是 Kylin 的十幾倍甚至幾十倍，因此單表查詢 Kylin 具有明顯優(yōu)勢呈础。
圖6 多表對比圖
圖6是一個多表 join 查詢的場景舆驶，從上圖可以看出，對于多表 join 的情況而钞，Kylin 查詢依舊非成沉快，因為 join 在 Cube 構(gòu)建階段已經(jīng)完成了臼节；Phoenix 加入索引后時間并沒有較為顯著的減少撬陵，耗時仍然是 Kylin 的幾十倍甚至幾百倍。
因此网缝，無論是單表還是多表查詢巨税，Kylin 查詢的時間都遠遠小于 Phoenix，當然這是因為有了預計算的原因粉臊。
4草添、總結(jié)
簡單來看，Apache Phoenix 與Apache Kylin 似乎都是 Hadoop/HBase 上的 SQL 引擎扼仲，實際上它們服務于不同的目的果元，Phoenix 適用于頻繁寫但讀取少的事務型場景，Kylin 則適合寫少讀多的分析型場景犀盟；在 OLTP 的場景中而晒，Phoenix 具有低延遲、高并發(fā)阅畴、事務性等優(yōu)點倡怎；在 OLAP 的場景下，Kylin 更具有優(yōu)勢。用戶應該根據(jù)自身的實際情況监署，選擇合適的引擎颤专。
5、參考
3.?https://github.com/apache/phoenix
