作者簡介：李揚站绪，滴滴出行資深軟件開發(fā)工程師贴唇。2015年加入滴滴出行基礎平臺部稚失，主要負責HBase和Phoenix以及相關分布式存儲技術(shù)栋艳。在滴滴之前，曾在新浪擔任數(shù)據(jù)工程師句各，專注于分布式計算和存儲吸占。
責編：郭芮（guorui@csdn.net），關注大數(shù)據(jù)領域诫钓。
背景
對接業(yè)務類型
HBase是建立在Hadoop生態(tài)之上的Database旬昭，源生對離線任務支持友好篙螟，又因為LSM樹是一個優(yōu)秀的高吞吐數(shù)據(jù)庫結(jié)構(gòu)菌湃，所以同時也對接了很多線上業(yè)務。在線業(yè)務對訪問延遲敏感遍略，并且訪問趨向于隨機惧所，如訂單骤坐、客服軌跡查詢。離線業(yè)務通常是數(shù)倉的定時大批量處理任務下愈，對一段時間內(nèi)的數(shù)據(jù)進行處理并產(chǎn)出結(jié)果纽绍，對任務完成的時間要求不是非常敏感，并且處理邏輯復雜势似，如天級別報表拌夏、安全和用戶行為分析、模型訓練等履因。
多語言支持
HBase提供了多語言解決方案障簿，并且由于滴滴各業(yè)務線RD所使用的開發(fā)語言各有偏好，所以多語言支持對于HBase在滴滴內(nèi)部的發(fā)展是至關重要的一部分栅迄。我們對用戶提供了多種語言的訪問方式：HBase Java native API站故、Thrift Server（主要應用于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進行SQL查詢。數(shù)據(jù)量較小冗美，對查詢的靈活性要求高魔种，延遲要求一般。
- 原始事實類數(shù)據(jù)：如訂單粉洼、司機乘客的GPS軌跡节预、日志等，主要用作在線和離線的數(shù)據(jù)供給属韧。數(shù)據(jù)量大安拟，對一致性和可用性要求高，延遲敏感宵喂，實時寫入糠赦，單點或批量查詢。
- 中間結(jié)果數(shù)據(jù)：指模型訓練所需要的數(shù)據(jù)等。數(shù)據(jù)量大拙泽，可用性和一致性要求一般淌山，對批量查詢時的吞吐量要求高。
- 線上系統(tǒng)的備份數(shù)據(jù)：用戶把原始數(shù)據(jù)存在了其他關系數(shù)據(jù)庫或文件服務顾瞻，把HBase作為一個異地容災的方案泼疑。
使用場景介紹
場景一：訂單事件
這份數(shù)據(jù)使用過滴滴產(chǎn)品的用戶應該都接觸過，就是App上的歷史訂單荷荤。近期訂單的查詢會落在Redis退渗，超過一定時間范圍，或者當Redis不可用時蕴纳，查詢會落在HBase上帕涌。業(yè)務方的需求如下：
- 在線查詢訂單生命周期的各個狀態(tài)统诺，包括status籍茧、event_type逾一、order_detail等信息。主要的查詢來自于客服系統(tǒng)喇潘。
- 在線歷史訂單詳情查詢体斩。上層會有Redis來存儲近期的訂單，當Redis不可用或者查詢范圍超出Redis颖低，查詢會直接落到HBase絮吵。
- 離線對訂單的狀態(tài)進行分析。
- 寫入滿足每秒10K的事件忱屑，讀取滿足每秒1K的事件蹬敲，數(shù)據(jù)要求在5s內(nèi)可用。
按照這些要求莺戒，我們對Rowkey做出了下面的設計伴嗡，都是很典型的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)的訂單及其他信息
場景二：司機乘客軌跡
這也是一份滴滴用戶關系密切的數(shù)據(jù)从铲，線上用戶瘪校、滴滴的各個業(yè)務線和分析人員都會使用。舉幾個使用場景上的例子：用戶查看歷史訂單時名段，地圖上顯示所經(jīng)過的路線阱扬；發(fā)生司乘糾紛，客服調(diào)用訂單軌跡復現(xiàn)場景伸辟；地圖部門用戶分析道路擁堵情況麻惶。
用戶們提出的需求：
- 滿足App用戶或者后端分析人員的實時或準實時軌跡坐標查詢；
- 滿足離線大規(guī)模的軌跡分析信夫；
- 滿足給出一個指定的地理范圍窃蹋，取出范圍內(nèi)所有用戶的軌跡或范圍內(nèi)出現(xiàn)過的用戶卡啰。
其中，關于第三個需求脐彩，地理位置查詢碎乃，我們知道MongoDB對于這種地理索引有源生的支持姊扔，但是在滴滴這種量級的情況下可能會發(fā)生存儲瓶頸惠奸，HBase存儲和擴展性上沒有壓力但是沒有內(nèi)置類似MongoDB地理位置索引的功能，沒有就需要我們自己實現(xiàn)恰梢。通過調(diào)研佛南，了解到關于地理索引有一套比較通用的GeohHash算法 。
GeoHash是將二維的經(jīng)緯度轉(zhuǎn)換成字符串嵌言，每一個字符串代表了某一矩形區(qū)域嗅回。也就是說，這個矩形區(qū)域內(nèi)所有的點（經(jīng)緯度坐標）都共享相同的GeoHash字符串摧茴，比如說我在悠唐酒店绵载，我的一個朋友在旁邊的悠唐購物廣場，我們的經(jīng)緯度點會得到相同的GeoHash串苛白。這樣既可以保護隱私（只表示大概區(qū)域位置而不是具體的點）娃豹，又比較容易做緩存。
但是我們要查詢的范圍和GeohHash塊可能不會完全重合购裙。以圓形為例懂版，查詢時會出現(xiàn)如圖4所示的一半在GeoHash塊內(nèi)，一半在外面的情況（如A躏率、B躯畴、C、D薇芝、E蓬抄、F、G等點）夯到。這種情況就需要對GeoHash塊內(nèi)每個真實的GPS點進行第二次的過濾倡鲸，通過原始的GPS點和圓心之間的距離，過濾掉不符合查詢條件的數(shù)據(jù)黄娘。
最后依據(jù)這個原理峭状，把GeoHash和其他一些需要被索引的維度拼裝成Rowkey，真實的GPS點為Value逼争，在這個基礎上封裝成客戶端优床，并且在客戶端內(nèi)部對查詢邏輯和查詢策略做出速度上的大幅優(yōu)化，這樣就把HBase變成了一個MongoDB一樣支持地理位置索引的數(shù)據(jù)庫誓焦。如果查詢范圍非常大（比如進行省級別的分析）胆敞，還額外提供了MR的獲取數(shù)據(jù)的入口着帽。
兩種查詢場景的Rowkey設計如下：
- 單個用戶按訂單或時間段查詢： reverse(user_id) + (Integer.MAX_LONG-TS/1000)
- 給定范圍內(nèi)的軌跡查詢：reverse(geohash) + ts/1000 + user_id
場景三：ETA
ETA是指每次選好起始和目的地后，提示出的預估時間和價格移层。提示的預估到達時間和價格仍翰，最初版本是離線方式運行，后來改版通過HBase實現(xiàn)實時效果观话，把HBase當成一個KeyValue緩存予借，帶來了減少訓練時間、可多城市并行频蛔、減少人工干預的好處灵迫。
整個ETA的過程如下：
- 模型訓練通過Spark Job，每30分鐘對各個城市訓練一次晦溪；
- 模型訓練第一階段瀑粥，在5分鐘內(nèi)，按照設定條件從HBase讀取所有城市數(shù)據(jù)三圆；
- 模型訓練第二階段在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使用等），關系數(shù)據(jù)庫在時間維度過程以后會產(chǎn)生各種性能問題度气，同時我們又希望可以通過SQL做一些分析查詢割按，所以使用Phoenix，使用采集程序定時錄入數(shù)據(jù)磷籍，生產(chǎn)成報表适荣，存入HBase，可以在秒級別返回查詢結(jié)果院领，最后在前端做展示弛矛。
圖7、圖8比然、圖9是幾張監(jiān)控工具的用戶UI丈氓，數(shù)字相關的部分做了模糊處理。
滴滴在HBase對多租戶的管理
我們認為單集群多租戶是最高效和節(jié)省精力的方案强法，但是由于HBase對多租戶基本沒有管理万俗，使用上會遇到很多問題：在用戶方面比如對資源使用情況不做分析、存儲總量發(fā)生變化后不做調(diào)整和通知饮怯、項目上線下線沒有計劃闰歪、想要最多的資源和權(quán)限等；我們平臺管理者也會遇到比如線上溝通難以理解用戶的業(yè)務蓖墅、對每個接入HBase的項目狀態(tài)不清楚库倘、不能判斷出用戶的需求是否合理临扮、多租戶在集群上發(fā)生資源競爭、問題定位和排查時間長等教翩。
針對這些問題杆勇，我們開發(fā)了DHS系統(tǒng)（Didi HBase Service）進行項目管理，并且在HBase上通過Namespace饱亿、RS Group等技術(shù)來分割用戶的資源蚜退、數(shù)據(jù)和權(quán)限。通過計算開銷并計費的方法來管控資源分配路捧。
DHS主要有下面幾個模塊和功能：
- 項目生命周期管理：包括立項关霸、資源預估和申請传黄、項目需求調(diào)整杰扫、需求討論；
- 用戶管理：權(quán)限管理膘掰，項目審批章姓；
- 集群資源管理；
- 表級別的使用情況監(jiān)控：主要是讀寫監(jiān)控识埋、memstore凡伊、blockcache、locality窒舟。
當用戶有使用HBase存儲的需求系忙，我們會讓用戶在DHS上注冊項目。介紹業(yè)務的場景和產(chǎn)品相關的細節(jié)惠豺，以及是否有高SLA要求银还。
之后是新建表以及對表性能需求預估，我們要求用戶對自己要使用的資源有一個準確的預估洁墙。如果用戶難以估計蛹疯，我們會以線上或者線下討論的方式與用戶討論幫助確定這些信息。
然后會生成項目概覽頁面热监，方便管理員和用戶進行項目進展的跟蹤捺弦。
HBase自帶的jxm信息會匯總到Region和RegionServer級別的數(shù)據(jù)，管理員會經(jīng)常用到孝扛，但是用戶卻很少關注這個級別列吼。根據(jù)這種情況我們開發(fā)了HBase表級別的監(jiān)控，并且會有權(quán)限控制苦始，讓業(yè)務RD只能看到和自己相關的表寞钥，清楚自己項目表的吞吐及存儲占用情況。
通過DHS讓用戶明確自己使用資源情況的基礎之上盈简，我們使用了RS Group技術(shù)凑耻，把一個集群分成多個邏輯子集群太示，可以讓用戶選擇獨占或者共享資源。共享和獨占各有自己的優(yōu)缺點香浩，如表1类缤。
根據(jù)以上的情況，我們在資源分配上會根據(jù)業(yè)務的特性來選擇不同方案：
- 對于訪問延遲要求低邻吭、訪問量小餐弱、可用性要求低、備份或者測試階段的數(shù)據(jù)：使用共享資源池囱晴；
- 對于延遲敏感膏蚓、吞吐要求高、高峰時段訪問量大畸写、可用性要求高驮瞧、在線業(yè)務：讓其獨占一定機器數(shù)量構(gòu)成的RegionServer Group資源，并且按用戶預估的資源量枯芬，額外給出20%~30%的余量论笔。
最后我們會根據(jù)用戶對資源的使用，定期計算開銷并向用戶發(fā)出賬單千所。
RS Group
RegionServer Group狂魔，實現(xiàn)細節(jié)可以參照HBase HBASE-6721這個Patch。滴滴在這個基礎上作了一些分配策略上的優(yōu)化淫痰，以便適合滴滴業(yè)務場景的修改最楷。RS Group簡單概括是指通過分配一批指定的RegionServer列表，成為一個RS Group待错，每個Group可以按需掛載不同的表籽孙，并且當Group內(nèi)的表發(fā)生異常后，Region不會遷移到其他的Group朗鸠。這樣蚯撩，每個Group就相當于一個邏輯上的子集群，通過這種方式達到資源隔離的效果烛占，降低管理成本胎挎，不必為每個高SLA的業(yè)務線單獨搭集群。
總結(jié)
在滴滴推廣和實踐HBase的工作中忆家，我們認為至關重要的兩點是幫助用戶做出良好的表結(jié)構(gòu)設計和資源的控制犹菇。有了這兩個前提之后，后續(xù)出現(xiàn)問題的概率會大大降低芽卿。良好的表結(jié)構(gòu)設計需要用戶對HBase的實現(xiàn)有一個清晰的認識揭芍，大多數(shù)業(yè)務用戶把更多精力放在了業(yè)務邏輯上，對架構(gòu)實現(xiàn)知之甚少卸例，這就需要平臺管理者去不斷幫助和引導称杨，有了好的開端和成功案例后肌毅，通過這些用戶再去向其他的業(yè)務方推廣。資源隔離控制則幫助我們有效減少集群的數(shù)量姑原，降低運維成本悬而，讓平臺管理者從多集群無止盡的管理工作中解放出來，將更多精力投入到組件社區(qū)跟進和平臺管理系統(tǒng)的研發(fā)工作中锭汛，使業(yè)務和平臺都進入一個良性循環(huán)笨奠，提升用戶的使用體驗，更好地支持公司業(yè)務的發(fā)展唤殴。
