1.背景概述
近些年來，資料爆炸或者大資料成為 IT 行業發展的高頻詞彙，傳統單機資料庫 處理資料能力的瓶頸成為擺在 IT 工程師面前十分常見且亟待解決的問題。單機硬體存儲容量和計算力的增長遠遠趕不上資料的增長。在單機軟體中，資料庫是資料相關處理技術的集大成者，集合了資料存儲、資料實時讀寫、線上事務和資料分析等技術，并通過主備、多活等方案保證了可靠性。但是，在實際業務場景中，我們往往并沒有同時用到所有資料庫提供的能力，這也為我們解決業務中實際遇到的大資料難題提供了解決思路。
目前的大資料系統大多是通過分布式原理，重點解決某個方面或者某些方面的困境和難題，比如 HDFS 解決了大資料存儲的問題，MapReduce 解決了大資料量複雜分析和計算的難題，HBase 解決了實時讀寫的問題。下面筆者将介紹 HBase 從解決實時讀寫問題出發，逐漸進化，從 NoSQL 發展到 NewSQL 的過程和最新進展。
單純從解決大資料實時讀寫問題角度，最初的 HBase 系統可以去掉很多傳統資料庫無關的功能，比如事務，SQL 表達與分析等，重點關注于分布式系統的擴充性，容錯性，分布式緩存的設計，讀寫性能的優化以及毛刺的減少等方面。這也就是 NoSQL 最初的含義，解決大資料的實時存取的核心問題是第一位的，提供簡單的 Get，Put，Scan 接口就可以解決使用者的燃眉之急。通過第一階段的努力，HBase 成為了優秀的大資料實時存取引擎，傳統資料庫的容量問題解決了，HDFS 實時性不夠的問題也解決了。
走過了從無到有的第一階段，我們需要讓 HBase 更強大，更好用，門檻更低，讓 HBase 幫助更多的使用者解決他們遇到的實際問題。衆所周知，SQL 是資料處理領 域的語言标準，簡單，好用，表達力強，使用者使用廣泛。HBase 很有必要回過頭來支援 SQL，包括語言表達的支援和相關的資料處理方式和能力的支援。當然， HBase SQL 的實作和發展跟傳統單機資料庫有很多不同，便于差別，我們稱之為 NewSQL。這也是社群 Phoenix 項目的初衷，如果說 HBase 是功能強大的存儲引擎，那麼支援 NewSQL 之後，就變成了新一代的大飛機。
接下來，第二章将介紹 Phoenix 項目是如何讓 HBase 從 NoSQL 成長為 NewSQL 的;第三章介紹 Phoenix 在阿裡的實踐，增強和典型案例;第四章總結全文以及展望 Phoenix 未來的發展。
2.方案與實作
系統整體架構如圖 2 所示，其中黃色部分是 HBase 的元件，藍色部分是 Phoenix，我們可以看出 Phoenix 跟 HBase 是緊密結合的。Phoenix 首先要能通過 SQL 暴露 HBase 的能力，然後再通過一系列功能和特性增強 HBase 能力，并且還要做到足 夠易用。下面我分别從基于 HBase 的 SQL，SQL 執行與優化以使用接口三個方 面介紹 Phoenix 已經做到的事情。
2.1 基于 HBase 的 SQL
讓 HBase 支援 SQL，我們首先能想到的是，把 SQL 語言翻譯成 HBase API，并且 HBase 本身的功能特性必須得能通過 SQL 暴露出來。Phoenix SQL 文法即 SQL- 92 标準文法+方言。Phoenix 支援标準文法的絕大部分特性，包括:标準類型; 聚合，連接配接，in，排序以及子查詢等查詢文法;create，drop，delete 等資料操作 文法，這些操作在底層都會轉變為 HBase API。
此外，HBase 的某些特性也能通過 SQL 方言的形式表達，比如:
- HBase 的列族，可以把相關的列放到一起，以減少 IO，優化讀性能，在建立 Phoenix 表的時候直接寫成”cf.col”即可，Phoenix 會自動建立 cf 列族， 如果不指定，則放在預設列族中;
- Phoenix 将 insert 和 update 合并成 upsert 關鍵字，來對應 HBase 的 Put 概 念;
- HBase 為了避免在表初始時隻有一個 Region 帶來資料熱點，支援預分區， Phoenix 支援在建表的時候通過 split on 關鍵字來表達。
-
HBase 支援動态列的特性在 Phoenix 中也得以保留，存入資料的時候直接聲明新的字段即可使用。
由于充分結合，Phoenix 天然繼承了 HBase 所擁有的高并發，大容量，實時存取等特性。
從圖 3 中可以看出，有了 SQL，使用者無需編寫繁瑣的 java 代碼，大大簡化了代碼邏輯，傳統資料庫使用者可以快速上手，原有基于傳統資料庫的代碼邏輯，隻需要少量修改即可運作起來。
在很多場景下僅擁有實時存取的特性是不夠的，大資料線上原地分析也是自然而然的需求，Phoenix 基于 HBase 擁有的高效緩存和 LSM 索引，可以做到對 PB 級 資料做操作型分析的毫秒級或秒級傳回。
Phoenix SQL 的整體執行流程如圖 4 所示，使用者輸入的查詢語句首先經過 SQLParser 解析為執行計劃，然後經過 QueryOptimizer 的優化，選取最優的執行計劃，執行計劃最終會轉變為 HBase 的 Scan，RegionServer 端的協處理器會作用于該 Scan，做本地過濾和聚合，然後把 結果傳回到用戶端做彙總聚合形成最終結果，并通過ResultSet 的形式傳回給使用者。其中主要使用到的政策有:無需資料傳輸的算子原地計算;實時同步的二級索引;熱點資料自動打散;以及基于代價和規則的執行計劃優化等。後面筆者介紹前三個最具有 Phoenix 特色的政策。
在沒有 Phoenix 之前，使用者如果需要分析 HBase 資料，隻能從HBase 拖出去或者繞過 HBase 直接讀取 HDFS 上面的 HFile 的方式進行，前者浪費了大量的網絡 IO，後者用不到 HBase 本身做的大量緩存和索引優化。Phoenix 使用 HBase 的協處理器機制，直接在 RegionServer 上執行算子邏輯，然後将算子的結果傳回即可，也就是大資料中的“Move Operator to Data”理念。比如，使用者執行“select
count(*) from mytable where mytime > timestamp’2018-11-11 00:00:00’”，在實際執行中，會先找到符合過濾條件的 region，然後在 RegionServer 本地計算 count， 最後再對各個 Region 上的結果進行彙總。
索引是傳統資料庫中常見的技術，HBase 表中可以指定主鍵，對主鍵使用 LSM 算 法建構索引。Phoenix 中，使用者在建立表的時候，可以指定索引列，可以是單列， 也可以是組合列。很多時候僅有主鍵索引是不夠的，特别是對于列特别多的寬表， 為此，Phoenix 提供二級索引功能，使用者能夠對表中非主鍵的列添加索引，并可以加入其它相關列到索引表中，如果某個查詢涉及到的列全部在索引表中，直接查詢索引表即可，無需通路原資料表。索引表跟原表做到實時同步更新，以保證 資料一緻性。
索引示例如圖 5 所示，建立索引的時候通過“on”關鍵字指定索引表的主鍵，實際 HBase 表中會使用 BA 來作為聯合主鍵;“include”關鍵字指定加入到索引表的其 他列。當執行“select c from data_table where b > xx ”時，Phoenix 直接查詢索引 表即可，否者需要傳回原表查找。
當資料的通路比較集中，比如物聯網場景中需要對最新的的監控資料做查詢分析， 而這部分資料往往會集中分布在某個 RegionServer 上，那麼就會形成熱點，性 能也會大大折扣。此時需要能夠把資料打散到不同的 RegionServer 上來解決， 加鹽就是這樣一個技術。加鹽的過程本質上是對原有的主鍵加上一個位元組的字首， 如下面公式所示:
其中，BUCKETS_NUMBER 為桶的個數。主鍵的分布決定了資料的分布，把主鍵 打散也就意味着資料打散。具體使用時，一般建議桶的數目等于 RegionServer 的數目。
2.3 使用接口
Phoenix 提供 JDBC 的方式通路，并支援重用戶端和輕用戶端兩種方式，重客戶 端的 JDBC 串字首是“jdbc:phoenix:”，輕用戶端的 JDBC 串字首為 “jdbc:phoenix:thin:”。重用戶端中，Phoenix 初執行在 HBase 協處理器之外的邏輯均運作在用戶端，這樣可以帶來最優的性能，但也帶來了用戶端的複雜性。輕客 戶端則将上訴邏輯運作在單獨不熟的 QueryServer 中，用戶端僅有很薄的 JDBC 協定轉換。輕用戶端除支援 Java 語言外，也支援 Python、Go、C#等多種語言。
3.實踐案例
阿裡雲 HBase 産品中內建 Phoenix 功能已經有一年多的時間了，阿裡雲 HBase 團隊對 Phoenix 在穩定性和性能方面做了一系列的改進優化，并積極回報回社群， 團隊的瑾謙同學也成長為了 Phoenix 社群的 commiter。Phoenix 的使用者既有來自 于新型大資料業務，如物聯網、網際網路金融以及新零售等;也有來自傳統行業， 比如遊戲、養殖業和運輸業等。Phoenix 資料既有來線上實時業務，也有從單機 資料庫同步進來。下面，筆者以物聯網場景為例，說明 Phoenix 如何在實際業務中解決使用者難題。
在物聯網場景下，大量傳感器會把實時監測到的資料上傳到雲平台，經過一定的 預處理後實時寫入到 Phoenix 中，管控平台從 Phoenix 中直接線上查詢和分析數 據，如生成報表，監控異常等。該場景會用到 Phoenix 的一下特性:
- 對實時寫入的并發和 TPS 要求很高，甚至可以達到百萬級。
- 資料量比較大，一般在 TB 到 PB 級别，且需要根據業務增長動态擴容。
- 有動态列的需求，比如根據業務調整，動态添加監控名額。
- 線上查詢，甚至是毫秒級查詢要求。
- 次元比較多，需要用到二級索引，以加速線上查詢。
- 頻繁查詢最近一段時間的資料，會造成熱點，可以使用加鹽的特性。
4.總結與展望
開源的 HDFS、MapReduce 和 HBase 來源于 Google 的三篇論文，但最終驅動的 還是大資料場景下的實際需求。Phoenix 的出現也是需求驅動的必然結果，它繼 承了 HBase 的各種特性，如高并發，水準擴充，實時讀寫等，并在其基礎上實作 了一套 SQL 引擎，增加了如文法解析、二級索引、查詢優化以及 JDBC 等功能和 特性，完成了NoSQL 到 NewSQL 的轉變。
阿裡雲 HBase 團隊和社群對 Phoenix 後續還會根據實際需求做進一步的進化， 包括穩定性的進一步加強;執行計劃和運作時的進一步優化;輕用戶端在易用性 支援上的持續完善;實時交易場景中事務的支援以及跟 Spark 的深度內建等等。 筆者非常希望對 HBase 和 Phoenix 感興趣的讀者朋友可以參與到社群裡面，共 同推動技術的發展，滿足更多的場景需求。