《程序員》精選：HBase在滴滴出行的應用場景和最佳實踐

背景

對接業務類型

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的實現有一個清晰的認識，大多數業務用戶把更多精力放在了業務邏輯上，對架構實現知之甚少，這就需要平台管理者去不斷幫助和引導，有了好的開端和成功案例後，通過這些用戶再去向其他的業務方推廣。資源隔離控制則幫助我們有效減少集群的數量，降低運維成本，讓平台管理者從多集群無止盡的管理工作中解放出來，將更多精力投入到組件社區跟進和平台管理系統的研發工作中，使業務和平台都進入一個良性循環，提升用戶的使用體驗，更好地支持公司業務的發展。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！