背景
對接業務類型
HBase是建立在Hadoop生态之上的Database，源生對離線任務支援友好，又因為LSM樹是一個優秀的高吞吐資料庫結構，是以同時也對接了很多線上業務。線上業務對通路延遲敏感，并且通路趨向于随機，如訂單、客服軌迹查詢。離線業務通常是數倉的定時大批量處理任務，對一段時間内的資料進行處理并産出結果，對任務完成的時間要求不是非常敏感，并且處理邏輯複雜，如天級别報表、安全和使用者行為分析、模型訓練等。
多語言支援
HBase提供了多語言解決方案，并且由于滴滴各業務線RD所使用的開發語言各有偏好，是以多語言支援對于HBase在滴滴内部的發展是至關重要的一部分。我們對使用者提供了多種語言的通路方式：HBase Java native API、Thrift Server（主要應用于C++、PHP、Python）、JAVA JDBC（Phoenix JDBC）、Phoenix QueryServer（Phoenix對外提供的多語言解決方案）、MapReduce Job（Htable/Hfile Input）、Spark Job、Streaming等。
資料類型
HBase在滴滴主要存放了以下四種資料類型：
- 統計結果、報表類資料：主要是營運、運力情況、收入等結果，通常需要配合Phoenix進行SQL查詢。資料量較小，對查詢的靈活性要求高，延遲要求一般。
- 原始事實類資料：如訂單、司機乘客的GPS軌迹、日志等，主要用作線上和離線的資料供給。資料量大，對一緻性和可用性要求高，延遲敏感，實時寫入，單點或批量查詢。
- 中間結果資料：指模型訓練所需要的資料等。資料量大，可用性和一緻性要求一般，對批量查詢時的吞吐量要求高。
- 線上系統的備份資料：使用者把原始資料存在了其他關系資料庫或檔案服務，把HBase作為一個異地容災的方案。
使用場景介紹
場景一：訂單事件
這份資料使用過滴滴産品的使用者應該都接觸過，就是App上的曆史訂單。近期訂單的查詢會落在Redis，超過一定時間範圍，或者當Redis不可用時，查詢會落在HBase上。業務方的需求如下：
- 線上查詢訂單生命周期的各個狀态，包括status、event_type、order_detail等資訊。主要的查詢來自于客服系統。
- 線上曆史訂單詳情查詢。上層會有Redis來存儲近期的訂單，當Redis不可用或者查詢範圍超出Redis，查詢會直接落到HBase。
- 離線對訂單的狀态進行分析。
- 寫入滿足每秒10K的事件，讀取滿足每秒1K的事件，資料要求在5s内可用。
圖1 訂單流資料流程
按照這些要求，我們對Rowkey做出了下面的設計，都是很典型的scan場景。
訂單狀态表
Rowkey：reverse(order_id) + (MAX_LONG – TS)
Columns：該訂單各種狀态
訂單曆史表
Rowkey：reverse(passenger_id | driver_id) + (MAX_LONG – TS)
Columns：使用者在時間範圍内的訂單及其他資訊
場景二：司機乘客軌迹
這也是一份滴滴使用者關系密切的資料，線上使用者、滴滴的各個業務線和分析人員都會使用。舉幾個使用場景上的例子：使用者檢視曆史訂單時，地圖上顯示所經過的路線；發生司乘糾紛，客服調用訂單軌迹複現場景；地圖部門使用者分析道路擁堵情況。
圖2 司乘軌迹資料流程
使用者們提出的需求：
- 滿足App使用者或者後端分析人員的實時或準實時軌迹坐标查詢；
- 滿足離線大規模的軌迹分析；
- 滿足給出一個指定的地理範圍，取出範圍内所有使用者的軌迹或範圍内出現過的使用者。
其中，關于第三個需求，地理位置查詢，我們知道MongoDB對于這種地理索引有源生的支援，但是在滴滴這種量級的情況下可能會發生存儲瓶頸，HBase存儲和擴充性上沒有壓力但是沒有内置類似MongoDB地理位置索引的功能，沒有就需要我們自己實作。通過調研，了解到關于地理索引有一套比較通用的GeohHash算法 。
GeoHash是将二維的經緯度轉換成字元串，每一個字元串代表了某一矩形區域。也就是說，這個矩形區域内所有的點（經緯度坐标）都共享相同的GeoHash字元串，比如說我在悠唐酒店，我的一個朋友在旁邊的悠唐購物廣場，我們的經緯度點會得到相同的GeoHash串。這樣既可以保護隐私（隻表示大概區域位置而不是具體的點），又比較容易做緩存。
圖3 GeoHash示意圖
但是我們要查詢的範圍和GeohHash塊可能不會完全重合。以圓形為例，查詢時會出現如圖4所示的一半在GeoHash塊内，一半在外面的情況（如A、B、C、D、E、F、G等點）。這種情況就需要對GeoHash塊内每個真實的GPS點進行第二次的過濾，通過原始的GPS點和圓心之間的距離，過濾掉不符合查詢條件的資料。
圖4 範圍查詢時，邊界GeoHash塊示意圖
最後依據這個原理，把GeoHash和其他一些需要被索引的次元拼裝成Rowkey，真實的GPS點為Value，在這個基礎上封裝成用戶端，并且在用戶端内部對查詢邏輯和查詢政策做出速度上的大幅優化，這樣就把HBase變成了一個MongoDB一樣支援地理位置索引的資料庫。如果查詢範圍非常大（比如進行省級别的分析），還額外提供了MR的擷取資料的入口。
兩種查詢場景的Rowkey設計如下：
- 單個使用者按訂單或時間段查詢： reverse(user_id) + (Integer.MAX_LONG-TS/1000)
- 給定範圍内的軌迹查詢：reverse(geohash) + ts/1000 + user_id
場景三：ETA
ETA是指每次選好起始和目的地後，提示出的預估時間和價格。提示的預估到達時間和價格，最初版本是離線方式運作，後來改版通過HBase實作實時效果，把HBase當成一個KeyValue緩存，帶來了減少訓練時間、可多城市并行、減少人工幹預的好處。
整個ETA的過程如下：
- 模型訓練通過Spark Job，每30分鐘對各個城市訓練一次；
- 模型訓練第一階段，在5分鐘内，按照設定條件從HBase讀取所有城市資料；
- 模型訓練第二階段在25分鐘内完成ETA的計算；
- HBase中的資料每隔一段時間會持久化至HDFS中，供新模型測試和新的特征提取。
Rowkey：salting+cited+type0+type1+type2+TS
Column：order, feature
圖5 ETA資料流程
場景四：監控工具DCM
用于監控Hadoop叢集的資源使用（Namenode，Yarn container使用等），關系資料庫在時間次元過程以後會産生各種性能問題，同時我們又希望可以通過SQL做一些分析查詢，是以使用Phoenix，使用采集程式定時錄入資料，生産成報表，存入HBase，可以在秒級别傳回查詢結果，最後在前端做展示。
圖6 DCM資料流程
圖7、圖8、圖9是幾張監控工具的使用者UI，數字相關的部分做了模糊處理。
圖7 DCM HDFS按時間統計使用全量和增量
圖8 DCM HDFS按使用者統計檔案數
圖9 DCM，MR Job運作結果統計
滴滴在HBase對多租戶的管理
我們認為單叢集多租戶是最高效和節省精力的方案，但是由于HBase對多租戶基本沒有管理，使用上會遇到很多問題：在使用者方面比如對資源使用情況不做分析、存儲總量發生變化後不做調整和通知、項目上線下線沒有計劃、想要最多的資源和權限等；我們平台管理者也會遇到比如線上溝通難以了解使用者的業務、對每個接入HBase的項目狀态不清楚、不能判斷出使用者的需求是否合理、多租戶在叢集上發生資源競争、問題定位和排查時間長等。
針對這些問題，我們開發了DHS系統（Didi HBase Service）進行項目管理，并且在HBase上通過Namespace、RS Group等技術來分割使用者的資源、資料和權限。通過計算開銷并計費的方法來管控資源配置設定。
圖10 DHS項目表監控
DHS主要有下面幾個子產品和功能：
- 項目生命周期管理：包括立項、資源預估和申請、項目需求調整、需求讨論；
- 使用者管理：權限管理，項目審批；
- 叢集資源管理；
- 表級别的使用情況監控：主要是讀寫監控、memstore、blockcache、locality。
當使用者有使用HBase存儲的需求，我們會讓使用者在DHS上注冊項目。介紹業務的場景和産品相關的細節，以及是否有高SLA要求。
之後是建立表以及對表性能需求預估，我們要求使用者對自己要使用的資源有一個準确的預估。如果使用者難以估計，我們會以線上或者線下讨論的方式與使用者讨論幫助确定這些資訊。
然後會生成項目概覽頁面，友善管理者和使用者進行項目進展的跟蹤。
HBase自帶的jxm資訊會彙總到Region和RegionServer級别的資料，管理者會經常用到，但是使用者卻很少關注這個級别。根據這種情況我們開發了HBase表級别的監控，并且會有權限控制，讓業務RD隻能看到和自己相關的表，清楚自己項目表的吞吐及存儲占用情況。
通過DHS讓使用者明确自己使用資源情況的基礎之上，我們使用了RS Group技術，把一個叢集分成多個邏輯子叢集，可以讓使用者選擇獨占或者共享資源。共享和獨占各有自己的優缺點，如表1。
表1 多租戶共享和獨占資源的優缺點
根據以上的情況，我們在資源配置設定上會根據業務的特性來選擇不同方案：
- 對于通路延遲要求低、通路量小、可用性要求低、備份或者測試階段的資料：使用共享資源池；
- 對于延遲敏感、吞吐要求高、高峰時段通路量大、可用性要求高、線上業務：讓其獨占一定機器數量構成的RegionServer Group資源，并且按使用者預估的資源量，額外給出20%~30%的餘量。
最後我們會根據使用者對資源的使用，定期計算開銷并向使用者發出賬單。
RS Group
RegionServer Group，實作細節可以參照HBase HBASE-6721這個Patch。滴滴在這個基礎上作了一些配置設定政策上的優化，以便适合滴滴業務場景的修改。RS Group簡單概括是指通過配置設定一批指定的RegionServer清單，成為一個RS Group，每個Group可以按需挂載不同的表，并且當Group内的表發生異常後，Region不會遷移到其他的Group。這樣，每個Group就相當于一個邏輯上的子叢集，通過這種方式達到資源隔離的效果，降低管理成本，不必為每個高SLA的業務線單獨搭叢集。
圖11 RS Group示意圖
總結
在滴滴推廣和實踐HBase的工作中，我們認為至關重要的兩點是幫助使用者做出良好的表結構設計和資源的控制。有了這兩個前提之後，後續出現問題的機率會大大降低。良好的表結構設計需要使用者對HBase的實作有一個清晰的認識，大多數業務使用者把更多精力放在了業務邏輯上，對架構實作知之甚少，這就需要平台管理者去不斷幫助和引導，有了好的開端和成功案例後，通過這些使用者再去向其他的業務方推廣。資源隔離控制則幫助我們有效減少叢集的數量，降低運維成本，讓平台管理者從多叢集無止盡的管理工作中解放出來，将更多精力投入到元件社群跟進和平台管理系統的研發工作中，使業務和平台都進入一個良性循環，提升使用者的使用體驗，更好地支援公司業務的發展。