2024HBase在风控系统应用和高可用实践

HBaseHBase。第一个MySQLHBasemsHBaseHBase和Hive/Spark结合能进行大数据分析，从而服务风控分析。HBase，HBasebinlogschemaschemaSQLportBseBse可以通过Bse的potpk同时可以使用增量pot，只导出今天的数据，这样对数据库的影响很低。WeHuse上的数据以前都是从业务上进行，从数据仓库拖到WeHuse是比较容易的，复制过来后可以利用pk做成Bse文件，直接利用bukad导入Bse里面，这是一个在bukad表导入Bse据库要么需要通过其接口或者QL解决他们的问题。比如爬虫服务，网页可能几百K或者上兆，放在MYSQL里面可能不接最高时达到上千倍，用户量膨胀严重。这样经常会出现CPU不高，不知道谁在查询，CPUSQLHBase特性regionServer继续时间过长，运行就会宕机。虽然会自行恢复，但是恢复时间影响查接下来讲一下一个regionServer宕掉影响这么大，外面公司一个regionServer集群恢复也就半个小时，但是我们的很长，原因就是我们用了Phoenix索引组件。图上面部分是数regionregionServerCoprocessorHost，将索引数据也会更新。当写入数据时会将索引数据写入索引表中。会生成一个indexer和WALUpdaterWALregionServerWAL，regionindexTableRegionCoprocessorHostcrash或者需要recover时WAL会将数据Replay到IndexRegionARS2上，这样就保持数据当一个region挂掉或者regionServer挂掉后，需要将这些region都Replay到另一个regionServerOpeningregionPendingOpeningWALindexRegionindexregionPending，最后会导致该region的ReplayregionPhoenix对数据写入失败后的处理机制，当index写入失败会触发PhoenixIndexWriteErrorHandlerDisableIndexTableRegionServerAbortregionrecoverOpeningOpenmainstoreflushReplayWAL长，可能就需要几分钟，如果你有200多个region时这个时间是非常可怕的。HBase1010SQlscanRowKeyscan，再者查询是否用到索引查询，FullScan是不是允许，当表数据少时是否支持Count操作。为了解决这个问题，除了做RuleBasedSQLInterception还做了CostBasedSQLInterception，运用了一些Phoenix机制，将数据做一些点位（GUIDE_POSTS）,如果RowKeyARowKeyB40scanSQL和Scan范围的解析，就可以精确到表级别控制你每个表可以scan多少条数据。规则不可能覆盖所有情况，因此还需要提供AdHocInterception，当遇到某种不合理情况实时添加可以暂时将用户Disable掉，或者暂时限制某些表的写入操作。通过这些改进后，regionrecover15min，其实这里面更多的是Replayregion里Mainstore的数据（大约10G）。解决这些问题后又出现其他问题，如DNS解析问题，机器问题，如磁盘挂掉，人为操作失误。最后提出要求时间在5min，从系统开始出现问题到我们发现问题、开始解决问题、线上恢复问题这些都需要在5分钟内解决。解决方案采用MYSQL思想，使用双集群。当一正常运行数据复制延迟大约10-20秒以内。真正切换时，需要将数据复制过来才能保证数低服务压力。这是一个冷集群，当数据量大需不需要预热，会不会被打垮，HBase有一个buildHBase，HBase我们的数据目前有几十TB，高峰时达到几十万QPS，基本维持在20-30万，SQL查询每以用，后续可以用HBaseRegionReplicate，实现几秒级集群间切换，当一个region挂regionHBaseMultiTenant隔离，将服务进行分组。HBase2.0PhoenixSQLSQL，要