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