摘要：?HBase和Phoenix的優(yōu)勢大家眾所周知，想要落地實踐卻問題一堆？replication的隨機發(fā)送、Connection的管理是否讓你頭痛不已？本次分享中，滴滴以典型的應(yīng)用場景帶大家深入探究HBase和Phoenix，并分享內(nèi)核改進措施。同時滴滴就如何實現(xiàn)穩(wěn)定性與容量規(guī)劃分享了眾多內(nèi)部技巧，不容錯過！

本次直播視頻精彩回顧，戳這里！?
以下內(nèi)容根據(jù)演講嘉賓視頻分享以及PPT整理而成。
本文將圍繞一下幾個方面進行介紹： 1. HBase特性應(yīng)用與內(nèi)核改進 2. Phoenix改進與實踐 3. GeoMesa應(yīng)用簡介與展望 4. 穩(wěn)定性&容量規(guī)劃 一． HBase特性應(yīng)用與內(nèi)核改進
1. HBase在滴滴的典型應(yīng)用場景 滴滴中有一些對HBase簡單操作，例如Scan和Get。每一個操作可以應(yīng)用于不同的場景，例如Scan可以衍生出時序和報表。時序可以應(yīng)用到軌跡設(shè)計中，將業(yè)務(wù)ID、時間戳和軌跡位置作為整體建立時序。另外在資產(chǎn)管理中，將資產(chǎn)狀態(tài)分為不同階段，將資產(chǎn)ID、時間戳、資產(chǎn)狀態(tài)等信息建立時序。Scan在報表中應(yīng)用也非常廣泛。其實現(xiàn)有多種方式，主流方法是通過phoenix，使用標準的SQL操作Hbase做聯(lián)機事務(wù)處理，該方法中需要注意主鍵及二級索引設(shè)計。報表中會以用戶歷史行為、歷史事件及歷史訂單為需求進行詳細設(shè)計。
Get操作可以應(yīng)用于HBase中存儲的語音和滴滴發(fā)票等小文件中。最基本的應(yīng)用方法為根據(jù)ID獲取實體屬性。更深入的例如可以應(yīng)用于join操作，例如在實時計算中有多個數(shù)據(jù)流需要合并，此時的ID即為HBase中的rowkey。另例如業(yè)務(wù)上游存在多個數(shù)據(jù)源，需要將這多個數(shù)據(jù)源數(shù)據(jù)聚合至一個表中。
此外，HBase中仍衍生出一些其他操作。互聯(lián)網(wǎng)公司需求變化快速，介入業(yè)務(wù)方眾多，可以通過動態(tài)列幫助實現(xiàn)這類需求。另有一些綜合應(yīng)用，例如圖和Coprocessor。圖包括用戶自定義的圖，可以自定義數(shù)據(jù)來源與數(shù)據(jù)分配。HBase集群中也接入了JanusGraph。Coprocessor主要應(yīng)用于Phoenix和GeoMesa。

2. replication 的應(yīng)用與優(yōu)化
假設(shè)原集群有三個主機：ReplicationSource01, ReplicationSource02, ReplicationSource03，目標集群有四個：RS01, RS02, RS03, RS04。若原集群發(fā)送replication請求，傳統(tǒng)的邏輯會隨機發(fā)送該請求。若目標集群的表存儲在GROUP A中的兩個主機上，但隨機發(fā)送卻有可能導(dǎo)致這兩個主機接收不到replication請求，而是發(fā)送至和該業(yè)務(wù)無關(guān)的GROUP中。因此這里對此作出優(yōu)化，對執(zhí)行策略進行適當修改，將可能發(fā)送到其他集群的請求在原集群中進行匹配，獲取目標集群GROUP的分配，使得請求可以發(fā)送至對應(yīng)的GROUP主機中，防止影響其他業(yè)務(wù)。
此外，未來希望在replication中增加table級別的信息統(tǒng)計，統(tǒng)計請求的連接錯誤信息，從用戶角度進行優(yōu)化。
3. Connection的管理與使用
基于滴滴如今的HBase版本，用戶使用中會出現(xiàn)關(guān)于Connection的一些問題，例如建立了多個Connection后，對應(yīng)的ZK也會非常多，因此需要對Connection進行管理。這里采用在RS中創(chuàng)建ClusterConnection來盡量減少Connection的創(chuàng)建。這會應(yīng)用在Phoenix二級索引場景中，詳情在Phoenix部分介紹。 4. ACL權(quán)限認證的優(yōu)化?
ACL主要實現(xiàn)用戶的用戶名、密碼與IP匹配的功能。此處創(chuàng)建了userinfo來存儲用戶密碼信息，rowkey為用戶名，CF(Column Family)為對應(yīng)的密碼。HBase:ACL這個表，在ZK中有/acl節(jié)點，類似的建立了userinfo節(jié)點。

下圖所示為userinfo接入流程。最上方是用戶客戶端封裝后的userinfo序列化信息，發(fā)送至服務(wù)器端，服務(wù)器通過AccessController進行一些操作，例如preGetOp, preDelete和prePut等。然后TableAuthManager進行權(quán)限判斷。TableAuthManager類中會存儲權(quán)限信息cache，當接收到新的userinfo時，首先會更新cache，供客戶端訪問時調(diào)用。傳統(tǒng)cache只包含/hbase/acl信息，滴滴優(yōu)化后增添了/hbase/userinfo信息。那么此時更新cache需要/acl信息和/userinfo信息進行Join()操作。
但是在使用原生/acl時也遇到一些問題，究其原因，還是需要減輕對zookeeper的依賴。 此外，滴滴還對其他方面進行了優(yōu)化，包括RPC audit log, RSGroup, quota, safe drop table等。RPC audit log可以對用戶請求量及錯誤信息進行分析。quato可以限制用戶流量，例如限制用戶對某個表每秒內(nèi)可以執(zhí)行多少次put操作。另外在drop table時，傳統(tǒng)方式為直接清理表格內(nèi)容，現(xiàn)優(yōu)化為先存儲一份快照再刪除，防止誤刪操作。
二． Phoenix改進與實踐
1. Phoenix原理與架構(gòu)
Phoenix提供基于HBase的sql操作的框架，主要進行源數(shù)據(jù)的管理。在RegionServer3上存儲著SYSTEM.CATALOG表，在每個RegionServer上有Coprocessor進行查詢、聚合、二級索引的建立等操作。
Phoenix client主要進行Connection管理，源數(shù)據(jù)管理，sql語法物理執(zhí)行計劃，并行Scan的發(fā)送與查詢，對scanner進行封裝。RegionServer中使用coprocessor較多。

2. Phoenix重要業(yè)務(wù)支持——全量歷史訂單
接下來主要介紹滴滴基于一個Phoenix重要端上任務(wù)，歷史訂單查詢，作出的優(yōu)化改進。滴滴的APP端改進前可以查詢?nèi)齻€月內(nèi)的歷史訂單數(shù)據(jù)，如今已經(jīng)達到全量歷史訂單數(shù)據(jù)，即理論上可以查詢所有訂單數(shù)據(jù)。系統(tǒng)穩(wěn)定性可以達到SLA99.95%。除卻HBase集群自身保證的監(jiān)控和恢復(fù)措施外，二級索引寫失敗處理和業(yè)務(wù)增加二級索引問題也也作出了較好的改進。并且，滴滴對查詢延遲要求也比較高，現(xiàn)使用JDBC客戶端P99延遲已達到了30-40ms。在功能上也實現(xiàn)了在每個column都可以聲明default值。
2.1 Index coprocessor改進

在穩(wěn)定性的改進中，connection的管理至關(guān)重要。在HBase中，ZK較為脆弱，connection的數(shù)量過多會對ZK造成較大的壓力。Phoenix傳統(tǒng)寫二級索引都是由Index coprocessor完成，當主表聲明的Index較多時，會產(chǎn)生較多Region。ZK的連接數(shù)即為region數(shù)乘以index數(shù)量，這會導(dǎo)致可能一個表會包含幾千個ZK。因此，為了解決這個問題，在RegionServer內(nèi)部建立 ClusterConnection，所有Region都復(fù)用該ClusterConnection。
2.2 TupleProjector性能優(yōu)化

為了對客戶端P99延遲進行優(yōu)化，這里針對TupleProjector進行了改進工作。初始phoenix 進行一次Query compilePlan耗時150ms左右，這主要由于訂單業(yè)務(wù)表多達130多個column，對每一個column進行g(shù)et column expression都會耗時1ms，因此這總耗時對系統(tǒng)來說是難以容忍的消耗。對于上述類型的寬表，最有效的優(yōu)化措施為配置并行處理。優(yōu)化后P99可以達到35ms左右。

2.3 二級索引設(shè)計 Phoenix的Salting功能非常有效，但對延遲影響較大，因此若延遲要求較高，那么Salting則并不合適，所以這里在主表與索引表中不使用Salting功能，而是采用reverse將主鍵列散列。索引中使用Function Index和Function Index減少查詢延遲。示例代碼如下所示：

2.4 Default值的坑

一般業(yè)務(wù)不會使用Default值，并且傳統(tǒng)的Default設(shè)計存在很多bug。例如在聲明Default列的二級索引中的寫入錯誤，即試圖寫入新值時，真正寫入的仍然是Default值。示例如下：
這里有兩種解決方案。一是在Index進行build之前，即在客戶端時進行一些特殊處理。方法二為在生成索引表的源數(shù)據(jù)時對錯誤填寫的值進行修改。 另一處bug例如在建立異步二級索引生成rowkey和Indexer build rowkey不一致，導(dǎo)致在索引查詢數(shù)據(jù)時double。具體原因是PTablempl.newKey對Default值的列邏輯上存在bug。示例如下：

2.5 性能壓測

在進行上述優(yōu)化后，分別通過Java-JDBC和Java-queryServer查詢進行性能壓測。結(jié)果如下：
其他非Java語言會通過Go-queryServer查詢，壓測P99結(jié)果會比Java語言稍慢。
2.6 二級索引策略 在傳統(tǒng)邏輯中，若Indexer二級索引寫失敗，則直接disable二級索引表，然后rebuild，但這在線上是不可用的。因此，滴滴采取關(guān)閉自動rebuild和disable進行改進。那么關(guān)閉自動rebuild和disable后如何感知寫失敗呢？此時需要定時查詢RegionServer log實時收集的ES，然后調(diào)用異步二級索引Partial rebuild來進行修補。當主表數(shù)據(jù)量較大時，進行異步全量二級索引時可能會split大量的maptask，超出master的承受范圍。因此需要改進split邏輯，對某些task進行合并。當這些改進完成，就可以提供較為穩(wěn)定的支持。

2.7 集群升級對二級索引寫入影響 當出現(xiàn)集群升級時，二級索引寫入肯定會失敗，該如何將該影響降至最低呢？如果將主表和索引表部署在一起，那么一臺機器升級，所有機器都會出現(xiàn)寫失敗。前文中也提到，滴滴在HBase中增添了GROUP功能，那么便可以將主表和索引表分開，部署在不同GROUP中，降低集群升級的影響。如下圖所示：

三． GeoMesa應(yīng)用簡介與展望
1. GeoMesa架構(gòu)原理 滴滴最近開始對GeoMesa展開調(diào)研，暫未取得豐富的線上經(jīng)驗。GeoMesa是基于分布式存儲、計算系統(tǒng)上的大規(guī)模時空數(shù)據(jù)查詢分析引擎。即在存儲時可以選擇存儲區(qū)域，數(shù)據(jù)輸入也可以包含多種形式，如spark kafka等。架構(gòu)如下圖所示：
GeoMesa對地理時空信息進行索引有著極大的優(yōu)勢。以HBase為例，GeoMesa可以將二維或三維數(shù)據(jù)映射至一維存儲，Geohash是較為常見的編碼方式。這種索引方法屬于點索引，如今使用較為廣泛。具體示例如下圖所示：
Geohash方法是將經(jīng)緯度等高維地理時空數(shù)據(jù)進行01編碼映射到一維。首先將維度置于奇數(shù)位，經(jīng)度為偶數(shù)位，通過base32生成字符串，降為一維，具體過程見下圖：
Geohash的理論基礎(chǔ)為Z-order曲線。但Z-order曲線存在突變性，即當?shù)乩砦恢镁嚯x非常遠，但編碼后的邏輯位置可能會產(chǎn)生連續(xù)的現(xiàn)象，如下圖。因此，通過Geohash查詢到的結(jié)果會比真正需要的結(jié)果數(shù)量差異較大，會有很多無效結(jié)果。

這會造成上圖中，某些點編碼前綴相同，但實際地理位置卻相差較遠，而與實際地理位置較近的編碼前綴并不相同。
2. GeoMesa應(yīng)用 GeoMesa經(jīng)常應(yīng)用于熱力圖繪制。滴滴使用其進行行車軌跡記錄，即查詢某時間段某區(qū)域內(nèi)經(jīng)過的車輛。以及對軌跡點加工，通過矢量路徑分析擁堵等。日后希望將XZ-order線和多邊形索引應(yīng)用至滴滴的業(yè)務(wù)場景中去。
滴滴也將GeoMesa進行了可視化，具體詳見視頻。

3. GeoMesa未來展望 基于上述Z-order曲線的突變性問題，未來希望可以基于希爾伯特空間填充曲線編碼生成索引。因為希爾伯特空間填充曲線含有地理空間局部性特征，因此一維曲線上離得越近的點在2D空間離得越近。這個特性對Scan具有較好的適用性。此外，GeoMesa中的plan耗時較長，平均每次耗時90ms，未來希望可以進行優(yōu)化。
四． 穩(wěn)定性&容量規(guī)劃
為了達到穩(wěn)定性與容量規(guī)劃，滴滴主要進行了以下工作。 首先是機器規(guī)劃。其中主要從三個維度進行考慮：每秒讀寫量、平均流量和存儲空間。每秒的讀寫量影響服務(wù)讀寫能力，平均流量會影響服務(wù)讀寫能力和磁盤IO，而存儲空間對應(yīng)其磁盤空間。若每秒讀寫量太大，會影響該服務(wù)的GC及網(wǎng)絡(luò)流量等。若需要的存儲空間比磁盤的總存儲空間要大，那么服務(wù)也會受到影響。因此這里可以通過壓力測試和DHS統(tǒng)計，將這三個維度進行綜合比較，計算機器容量規(guī)劃。同時，也可以根據(jù)上述信息，完成集群的GROUP劃分規(guī)劃。 其次，還對HBase的一些指標進行監(jiān)控，根據(jù)監(jiān)控情況判斷用戶服務(wù)是否處于健康狀態(tài)。出現(xiàn)故障時，也可以根據(jù)監(jiān)控排查問題。這里不再贅述，其中一監(jiān)控效果如下：
滴滴目前的工作流程大致為，當用戶接入時，先預(yù)估請求量，進行壓力測試，檢查后進行上線。上線后業(yè)務(wù)經(jīng)常會發(fā)生變化，例如發(fā)展較好數(shù)據(jù)量增加等，此時會循環(huán)進行一些操作，如根據(jù)監(jiān)控數(shù)據(jù)自動提示優(yōu)化線上業(yè)務(wù)，或者人工定期檢查或用戶反饋來進行優(yōu)化。后續(xù)工作是希望可以達到自動化模式，即利用監(jiān)控數(shù)據(jù)，優(yōu)化線上服務(wù)，自動發(fā)現(xiàn)空閑節(jié)點和可優(yōu)化的GROUP。
同時，滴滴也建立了DHS(Didi HBase Service)平臺，接入了用戶需求，可以可視化信息、自動驗證，幫助用戶了解服務(wù)狀態(tài)。如今正致力于以更少的人工計算，統(tǒng)計上述更細致的服務(wù)相關(guān)信息，幫助管理員了解用戶使用方式。

原文鏈接

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的高手如何实践HBase？不容错过的滴滴内部技巧的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。