2024HBase在風(fēng)控系統(tǒng)應(yīng)用和高可用實(shí)踐

HBaseHBase。第一個(gè)MySQLHBasemsHBaseHBase和Hive/Spark結(jié)合能進(jìn)行大數(shù)據(jù)分析，從而服務(wù)風(fēng)控分析。HBase，HBasebinlogschemaschemaSQLportBseBse可以通過(guò)Bse的potpk同時(shí)可以使用增量pot，只導(dǎo)出今天的數(shù)據(jù)，這樣對(duì)數(shù)據(jù)庫(kù)的影響很低。WeHuse上的數(shù)據(jù)以前都是從業(yè)務(wù)上進(jìn)行，從數(shù)據(jù)倉(cāng)庫(kù)拖到WeHuse是比較容易的，復(fù)制過(guò)來(lái)后可以利用pk做成Bse文件，直接利用bukad導(dǎo)入Bse里面，這是一個(gè)在bukad表導(dǎo)入Bse據(jù)庫(kù)要么需要通過(guò)其接口或者QL解決他們的問題。比如爬蟲服務(wù)，網(wǎng)頁(yè)可能幾百K或者上兆，放在MYSQL里面可能不接最高時(shí)達(dá)到上千倍，用戶量膨脹嚴(yán)重。這樣經(jīng)常會(huì)出現(xiàn)CPU不高，不知道誰(shuí)在查詢，CPUSQLHBase特性regionServer繼續(xù)時(shí)間過(guò)長(zhǎng)，運(yùn)行就會(huì)宕機(jī)。雖然會(huì)自行恢復(fù)，但是恢復(fù)時(shí)間影響查接下來(lái)講一下一個(gè)regionServer宕掉影響這么大，外面公司一個(gè)regionServer集群恢復(fù)也就半個(gè)小時(shí)，但是我們的很長(zhǎng)，原因就是我們用了Phoenix索引組件。圖上面部分是數(shù)regionregionServerCoprocessorHost，將索引數(shù)據(jù)也會(huì)更新。當(dāng)寫入數(shù)據(jù)時(shí)會(huì)將索引數(shù)據(jù)寫入索引表中。會(huì)生成一個(gè)indexer和WALUpdaterWALregionServerWAL，regionindexTableRegionCoprocessorHostcrash或者需要recover時(shí)WAL會(huì)將數(shù)據(jù)Replay到IndexRegionARS2上，這樣就保持?jǐn)?shù)據(jù)當(dāng)一個(gè)region掛掉或者regionServer掛掉后，需要將這些region都Replay到另一個(gè)regionServerOpeningregionPendingOpeningWALindexRegionindexregionPending，最后會(huì)導(dǎo)致該region的ReplayregionPhoenix對(duì)數(shù)據(jù)寫入失敗后的處理機(jī)制，當(dāng)index寫入失敗會(huì)觸發(fā)PhoenixIndexWriteErrorHandlerDisableIndexTableRegionServerAbortregionrecoverOpeningOpenmainstoreflushReplayWAL長(zhǎng)，可能就需要幾分鐘，如果你有200多個(gè)region時(shí)這個(gè)時(shí)間是非?？膳碌?。HBase1010SQlscanRowKeyscan，再者查詢是否用到索引查詢，F(xiàn)ullScan是不是允許，當(dāng)表數(shù)據(jù)少時(shí)是否支持Count操作。為了解決這個(gè)問題，除了做RuleBasedSQLInterception還做了CostBasedSQLInterception，運(yùn)用了一些Phoenix機(jī)制，將數(shù)據(jù)做一些點(diǎn)位（GUIDE_POSTS）,如果RowKeyARowKeyB40scanSQL和Scan范圍的解析，就可以精確到表級(jí)別控制你每個(gè)表可以scan多少條數(shù)據(jù)。規(guī)則不可能覆蓋所有情況，因此還需要提供AdHocInterception，當(dāng)遇到某種不合理情況實(shí)時(shí)添加可以暫時(shí)將用戶Disable掉，或者暫時(shí)限制某些表的寫入操作。通過(guò)這些改進(jìn)后，regionrecover15min，其實(shí)這里面更多的是Replayregion里Mainstore的數(shù)據(jù)（大約10G）。解決這些問題后又出現(xiàn)其他問題，如DNS解析問題，機(jī)器問題，如磁盤掛掉，人為操作失誤。最后提出要求時(shí)間在5min，從系統(tǒng)開始出現(xiàn)問題到我們發(fā)現(xiàn)問題、開始解決問題、線上恢復(fù)問題這些都需要在5分鐘內(nèi)解決。解決方案采用MYSQL思想，使用雙集群。當(dāng)一正常運(yùn)行數(shù)據(jù)復(fù)制延遲大約10-20秒以內(nèi)。真正切換時(shí)，需要將數(shù)據(jù)復(fù)制過(guò)來(lái)才能保證數(shù)低服務(wù)壓力。這是一個(gè)冷集群，當(dāng)數(shù)據(jù)量大需不需要預(yù)熱，會(huì)不會(huì)被打垮，HBase有一個(gè)buildHBase，HBase我們的數(shù)據(jù)目前有幾十TB，高峰時(shí)達(dá)到幾十萬(wàn)QPS，基本維持在20-30萬(wàn)，SQL查詢每以用，后續(xù)可以用HBaseRegionReplicate，實(shí)現(xiàn)幾秒級(jí)集群間切換，當(dāng)一個(gè)region掛regionHBaseMultiTenant隔離，將服務(wù)進(jìn)行分組。HBase2.0PhoenixSQLSQL，要