一.背景概述

近些年來，數據爆炸或者大數據成為IT行業發展的高頻詞匯，傳統單機數據庫處理數據能力的瓶頸成為擺在IT工程師面前十分常見且亟待解決的問題。單機硬件存儲容量和計算力的增長遠遠趕不上數據的增長。在單機軟件中，數據庫是數據相關處理技術的集大成者，集合了數據存儲、數據實時讀寫、在線事務和數據分析等技術，并通過主備、多活等方案保證了可靠性。但是，在實際業務場景中，我們往往并沒有同時用到所有數據庫提供的能力，這也為我們解決業務中實際遇到的大數據難題提供了解決思路。

當前的大數據系統大多是通過分布式原理，重點解決某個方面或者某些方面的困境和難題，比如HDFS解決了大數據存儲的問題，MapReduce解決了大數據量復雜分析和計算的難題，HBase解決了實時讀寫的問題。下面筆者將介紹HBase從解決實時讀寫問題出發，逐步進化，從NoSQL發展到NewSQL的過程和最新進展。

圖1 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 Phoenix架構

系統整體架構如圖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 vs HBase API

從圖3中可以看出，有了SQL，用戶無需編寫繁瑣的java代碼，大大簡化了代碼邏輯，傳統數據庫用戶可以快速上手，原有基于傳統數據庫的代碼邏輯，只需要少量修改即可運行起來。

?

2.2 SQL查詢優化

圖4 Phoenix SQL執行流程

在很多場景下僅擁有實時存取的特性是不夠的，大數據在線原地分析也是自然而然的需求，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直接查詢索引表即可，否者需要返回原表查找。

圖5 Phoenix二級索引

當數據的訪問比較集中，比如物聯網場景中需要對最新的的監控數據做查詢分析，而這部分數據往往會集中分布在某個RegionServer上，那么就會形成熱點，性能也會大大折扣。此時需要能夠把數據打散到不同的RegionServer上來解決，加鹽就是這樣一個技術。加鹽的過程本質上是對原有的主鍵加上一個字節的前綴，如下面公式所示：

new_row_key?=?(++index?%?BUCKETS_NUMBER)?+?original_key

其中，BUCKETS_NUMBER為桶的個數。主鍵的分布決定了數據的分布，把主鍵打散也就意味著數據打散。具體使用時，一般建議桶的數目等于RegionServer的數目。

?

2.3 使用接口

Phoenix提供JDBC的方式訪問，并支持重客戶端和輕客戶端兩種方式，重客戶端的JDBC串前綴是“jdbc:phoenix:”，輕客戶端的JDBC串前綴為“jdbc:phoenix:thin:”。重客戶端中，Phoenix初執行在HBase協處理器之外的邏輯均運行在客戶端，這樣可以帶來最優的性能，但也帶來了客戶端的復雜性。輕客戶端則將上訴邏輯運行在單獨不熟的QueryServer中，客戶端僅有很薄的JDBC協議轉換。輕客戶端除支持Java語言外，也支持Python、Go、C#等多種語言。

?

三.實踐案例

阿里云HBase產品中集成Phoenix功能已經有一年多的時間了，阿里云HBase團隊對Phoenix在穩定性和性能方面做了一系列的改進優化，并積極反饋回社區，團隊的瑾謙同學也成長為了Phoenix社區的Commiter。Phoenix的用戶既有來自于新型大數據業務，如物聯網、互聯網金融以及新零售等；也有來自傳統行業，比如游戲、養殖業和運輸業等。Phoenix數據既有來在線實時業務，也有從單機數據庫同步進來。下面，筆者以物聯網場景為例，說明Phoenix如何在實際業務中解決用戶難題。

在物聯網場景下，大量傳感器會把實時監測到的數據上傳到云平臺，經過一定的預處理后實時寫入到Phoenix中，管控平臺從Phoenix中直接在線查詢和分析數據，如生成報表，監控異常等。該場景會用到Phoenix的一下特性：

• 對實時寫入的并發和TPS要求很高，甚至可以達到百萬級。

• 數據量比較大，一般在TB到PB級別，且需要根據業務增長動態擴容。

• 有動態列的需求，比如根據業務調整，動態添加監控指標。

• 在線查詢，甚至是毫秒級查詢要求。

• 維度比較多，需要用到二級索引，以加速在線查詢。

• 頻繁查詢最近一段時間的數據，會造成熱點，可以使用加鹽的特性。

圖6 Phoenix在物聯網的應用

?

四.總結與展望

開源的HDFS、MapReduce和HBase來源于Google的三篇論文，但最終驅動的還是大數據場景下的實際需求。Phoenix的出現也是需求驅動的必然結果，它繼承了HBase的各種特性，如高并發，水平擴展，實時讀寫等，并在其基礎上實現了一套SQL引擎，增加了如語法解析、二級索引、查詢優化以及JDBC等功能和特性，完成了NoSQL到NewSQL的轉變。

阿里云HBase團隊和社區對Phoenix后續還會根據實際需求做進一步的進化，包括穩定性的進一步加強；執行計劃和運行時的進一步優化；輕客戶端在易用性支持上的持續完善；實時交易場景中事務的支持以及跟Spark的深度集成等等。筆者非常希望對HBase和Phoenix感興趣的讀者朋友可以參與到社區里面，共同推動技術的發展，滿足更多的場景需求。

總結

以上是生活随笔為你收集整理的HBase进化 | 从NoSQL到NewSQL，凤凰涅槃成就Phoenix的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。