高手如何實踐HBase？不容錯過的滴滴內部技巧

摘要： HBase和Phoenix的優點你們衆所周知，想要落地實踐卻問題一堆？replication的隨機發送、Connection的管理是否讓你頭痛不已？本次分享中，滴滴以典型的應用場景帶你們深刻探究HBase和Phoenix，並分享內核改進措施。同時滴滴就如何實現穩定性與容量規劃分享了衆多內部技巧，不容錯過！

本次直播視頻精彩回顧，戳這裏！

如下內容根據演講嘉賓視頻分享以及PPT整理而成。

本文將圍繞一下幾個方面進行介紹：

1. HBase特性應用與內核改進
2. Phoenix改進與實踐
3. GeoMesa應用簡介與展望
4. 穩定性&容量規劃

一． HBase特性應用與內核改進

1.HBase在滴滴的典型應用場景

滴滴中有一些對HBase簡單操做，例如Scan和Get。每個操做能夠應用於不一樣的場景，例如Scan能夠衍生出時序和報表。時序能夠應用到軌跡設計中，將業務ID、時間戳和軌跡位置做爲總體創建時序。另外在資產管理中，將資產狀態分爲不一樣階段，將資產ID、時間戳、資產狀態等信息創建時序。Scan在報表中應用也很是普遍。其實現有多種方式，主流方法是經過phoenix，使用標準的SQL操做Hbase作聯機事務處理，該方法中須要注意主鍵及二級索引設計。報表中會以用戶歷史行爲、歷史事件及歷史訂單爲需求進行詳細設計。

Get操做能夠應用於HBase中存儲的語音和滴滴發票等小文件中。最基本的應用方法爲根據ID獲取實體屬性。更深刻的例如能夠應用於join操做，例如在實時計算中有多個數據流須要合併，此時的ID即爲HBase中的rowkey。另例如業務上游存在多個數據源，須要將這多個數據源數據聚合至一個表中。

此外，HBase中仍衍生出一些其餘操做。互聯網公司需求變化快速，介入業務方衆多，能夠經過動態列幫助實現這類需求。另有一些綜合應用，例如圖和Coprocessor。圖包括用戶自定義的圖，能夠自定義數據來源與數據分配。HBase集羣中也接入了JanusGraph。Coprocessor主要應用於Phoenix和GeoMesa。

2. replication 的應用與優化

假設原集羣有三個主機：ReplicationSource01, ReplicationSource02, ReplicationSource03，目標集羣有四個：RS01, RS02, RS03, RS04。若原集羣發送replication請求，傳統的邏輯會隨機發送該請求。若目標集羣的表存儲在GROUP A中的兩個主機上，但隨機發送卻有可能致使這兩個主機接收不到replication請求，而是發送至和該業務無關的GROUP中。所以這裏對此做出優化，對執行策略進行適當修改，將可能發送到其餘集羣的請求在原集羣中進行匹配，獲取目標集羣GROUP的分配，使得請求能夠發送至對應的GROUP主機中，防止影響其餘業務。

此外，將來但願在replication中增長table級別的信息統計，統計請求的鏈接錯誤信息，從用戶角度進行優化。

3. Connection的管理與使用

基於滴滴現在的HBase版本，用戶使用中會出現關於Connection的一些問題，例如創建了多個Connection後，對應的ZK也會很是多，所以須要對Connection進行管理。這裏採用在RS中建立ClusterConnection來儘可能減小Connection的建立。這會應用在Phoenix二級索引場景中，詳情在Phoenix部分介紹。

4. ACL權限認證的優化

ACL主要實現用戶的用戶名、密碼與IP匹配的功能。此處建立了userinfo來存儲用戶密碼信息，rowkey爲用戶名，CF(Column Family)爲對應的密碼。HBase:ACL這個表，在ZK中有/acl節點，相似的創建了userinfo節點。

下圖所示爲userinfo接入流程。最上方是用戶客戶端封裝後的userinfo序列化信息，發送至服務器端，服務器經過AccessController進行一些操做，例如preGetOp, preDelete和prePut等。而後TableAuthManager進行權限判斷。TableAuthManager類中會存儲權限信息cache，當接收到新的userinfo時，首先會更新cache，供客戶端訪問時調用。傳統cache只包含/hbase/acl信息，滴滴優化後增添了/hbase/userinfo信息。那麼此時更新cache須要/acl信息和/userinfo信息進行Join()操做。

可是在使用原生/acl時也遇到一些問題，究其緣由，仍是須要減輕對zookeeper的依賴。
此外，滴滴還對其餘方面進行了優化，包括RPC audit log, RSGroup, quota, safe drop table等。RPC audit log能夠對用戶請求量及錯誤信息進行分析。quato能夠限制用戶流量，例如限制用戶對某個表每秒內能夠執行多少次put操做。另外在drop table時，傳統方式爲直接清理表格內容，現優化爲先存儲一份快照再刪除，防止誤刪操做。

二． Phoenix改進與實踐

1. Phoenix原理與架構

Phoenix提供基於HBase的sql操做的框架，主要進行源數據的管理。在RegionServer3上存儲着SYSTEM.CATALOG表，在每一個RegionServer上有Coprocessor進行查詢、聚合、二級索引的創建等操做。

Phoenix client主要進行Connection管理，源數據管理，sql語法物理執行計劃，並行Scan的發送與查詢，對scanner進行封裝。RegionServer中使用coprocessor較多。

2. Phoenix重要業務支持——全量歷史訂單

接下來主要介紹滴滴基於一個Phoenix重要端上任務，歷史訂單查詢，做出的優化改進。滴滴的APP端改進前能夠查詢三個月內的歷史訂單數據，現在已經達到全量歷史訂單數據，即理論上能夠查詢全部訂單數據。系統穩定性能夠達到SLA99.95%。除卻HBase集羣自身保證的監控和恢復措施外，二級索引寫失敗處理和業務增長二級索引問題也也做出了較好的改進。而且，滴滴對查詢延遲要求也比較高，現使用JDBC客戶端P99延遲已達到了30-40ms。在功能上也實現了在每一個column均可以聲明default值。

2.1 Index coprocessor改進

在穩定性的改進中，connection的管理相當重要。在HBase中，ZK較爲脆弱，connection的數量過多會對ZK形成較大的壓力。Phoenix傳統寫二級索引都是由Index coprocessor完成，當主表聲明的Index較多時，會產生較多Region。ZK的鏈接數即爲region數乘以index數量，這會致使可能一個表會包含幾千個ZK。所以，爲了解決這個問題，在RegionServer內部創建 ClusterConnection，全部Region都複用該ClusterConnection。

2.2 TupleProjector性能優化

爲了對客戶端P99延遲進行優化，這裏針對TupleProjector進行了改進工做。初始phoenix 進行一次Query compilePlan耗時150ms左右，這主要因爲訂單業務表多達130多個column，對每個column進行get column expression都會耗時1ms，所以這總耗時對系統來講是難以容忍的消耗。對於上述類型的寬表，最有效的優化措施爲配置並行處理。優化後P99能夠達到35ms左右。

2.3 二級索引設計

Phoenix的Salting功能很是有效，但對延遲影響較大，所以若延遲要求較高，那麼Salting則並不合適，因此這裏在主表與索引表中不使用Salting功能，而是採用reverse將主鍵列散列。索引中使用Function Index和Function Index減小查詢延遲。示例代碼以下所示：

2.4 Default值的坑

通常業務不會使用Default值，而且傳統的Default設計存在不少bug。例如在聲明Default列的二級索引中的寫入錯誤，即試圖寫入新值時，真正寫入的仍然是Default值。示例以下：

這裏有兩種解決方案。一是在Index進行build以前，即在客戶端時進行一些特殊處理。方法二爲在生成索引表的源數據時對錯誤填寫的值進行修改。
另外一處bug例如在創建異步二級索引生成rowkey和Indexer build rowkey不一致，致使在索引查詢數據時double。具體緣由是PTablempl.newKey對Default值的列邏輯上存在bug。示例以下：

2.5 性能壓測

在進行上述優化後，分別經過Java-JDBC和Java-queryServer查詢進行性能壓測。結果以下：

其餘非Java語言會經過Go-queryServer查詢，壓測P99結果會比Java語言稍慢。

2.6 二級索引策略

在傳統邏輯中，若Indexer二級索引寫失敗，則直接disable二級索引表，而後rebuild，但這在線上是不可用的。所以，滴滴採起關閉自動rebuild和disable進行改進。那麼關閉自動rebuild和disable後如何感知寫失敗呢？此時須要定時查詢RegionServer log實時收集的ES，而後調用異步二級索引Partial rebuild來進行修補。當主表數據量較大時，進行異步全量二級索引時可能會split大量的maptask，超出master的承受範圍。所以須要改進split邏輯，對某些task進行合併。當這些改進完成，就能夠提供較爲穩定的支持。

2.7 集羣升級對二級索引寫入影響

當出現集羣升級時，二級索引寫入確定會失敗，該如何將該影響降至最低呢？若是將主表和索引表部署在一塊兒，那麼一臺機器升級，全部機器都會出現寫失敗。前文中也提到，滴滴在HBase中增添了GROUP功能，那麼即可以將主表和索引表分開，部署在不一樣GROUP中，下降集羣升級的影響。以下圖所示：

三． GeoMesa應用簡介與展望

1. GeoMesa架構原理

滴滴最近開始對GeoMesa展開調研，暫未取得豐富的線上經驗。GeoMesa是基於分佈式存儲、計算系統上的大規模時空數據查詢分析引擎。即在存儲時能夠選擇存儲區域，數據輸入也能夠包含多種形式，如spark kafka等。架構以下圖所示：

GeoMesa對地理時空信息進行索引有着極大的優點。以HBase爲例，GeoMesa能夠將二維或三維數據映射至一維存儲，Geohash是較爲常見的編碼方式。這種索引方法屬於點索引，現在使用較爲普遍。具體示例以下圖所示：

Geohash方法是將經緯度等高維地理時空數據進行01編碼映射到一維。首先將維度置於奇數位，經度爲偶數位，經過base32生成字符串，降爲一維，具體過程見下圖：

Geohash的理論基礎爲Z-order曲線。但Z-order曲線存在突變性，即當地理位置距離很是遠，但編碼後的邏輯位置可能會產生連續的現象，以下圖。所以，經過Geohash查詢到的結果會比真正須要的結果數量差別較大，會有不少無效結果。

這會形成上圖中，某些點編碼前綴相同，但實際地理位置卻相差較遠，而與實際地理位置較近的編碼前綴並不相同。

2. GeoMesa應用

GeoMesa常常應用於熱力圖繪製。滴滴使用其進行行車軌跡記錄，即查詢某時間段某區域內通過的車輛。以及對軌跡點加工，經過矢量路徑分析擁堵等。往後但願將XZ-order線和多邊形索引應用至滴滴的業務場景中去。

滴滴也將GeoMesa進行了可視化，具體詳見視頻。

3. GeoMesa將來展望

基於上述Z-order曲線的突變性問題，將來但願能夠基於希爾伯特空間填充曲線編碼生成索引。由於希爾伯特空間填充曲線含有地理空間局部性特徵，所以一維曲線上離得越近的點在2D空間離得越近。這個特性對Scan具備較好的適用性。此外，GeoMesa中的plan耗時較長，平均每次耗時90ms，將來但願能夠進行優化。

四． 穩定性&容量規劃

爲了達到穩定性與容量規劃，滴滴主要進行了如下工做。
首先是機器規劃。其中主要從三個維度進行考慮：每秒讀寫量、平均流量和存儲空間。每秒的讀寫量影響服務讀寫能力，平均流量會影響服務讀寫能力和磁盤IO，而存儲空間對應其磁盤空間。若每秒讀寫量太大，會影響該服務的GC及網絡流量等。若須要的存儲空間比磁盤的總存儲空間要大，那麼服務也會受到影響。所以這裏能夠經過壓力測試和DHS統計，將這三個維度進行綜合比較，計算機器容量規劃。同時，也能夠根據上述信息，完成集羣的GROUP劃分規劃。

其次，還對HBase的一些指標進行監控，根據監控狀況判斷用戶服務是否處於健康狀態。出現故障時，也能夠根據監控排查問題。這裏再也不贅述，其中一監控效果以下：

滴滴目前的工做流程大體爲，當用戶接入時，先預估請求量，進行壓力測試，檢查後進行上線。上線後業務常常會發生變化，例如發展較好數據量增長等，此時會循環進行一些操做，如根據監控數據自動提示優化線上業務，或者人工按期檢查或用戶反饋來進行優化。後續工做是但願能夠達到自動化模式，即利用監控數據，優化線上服務，自動發現空閒節點和可優化的GROUP。

同時，滴滴也創建了DHS(Didi HBase Service)平臺，接入了用戶需求，能夠可視化信息、自動驗證，幫助用戶瞭解服務狀態。現在正致力於以更少的人工計算，統計上述更細緻的服務相關信息，幫助管理員瞭解用戶使用方式。

本文做者：聒小小噪
閱讀原文本文爲雲棲社區原創內容，未經容許不得轉載。