回顾·HBase在风控系统应用和高可用实践

本文根据挖财高级技术专家郭冬冬在中国HBase技术社区第3届 MeetUp 杭州站 中分享的《HBase在风控系统的应用和高可用实践》编辑整理而成。

我主要从事分布式服务、分布式计算以及大数据研究相关工作，目前在挖财负责大数据平台开发工作。挖财大数据平台采用HBase技术框架，首先讲一下为什么采用HBase。第一个方面从业务角度，各条业务线快速发展，各自有自己的MySQL实例；风控需要有独立的数据集市；如何快速获取数据，上线风控系统。第二方面从数据层面，目前有百亿-千亿数据级别数据导入，而HBase支持海量数据导入；风控需要ms级别延迟，而HBase低延迟；HBase和Hive/Spark结合能进行大数据分析，从而服务风控分析。

接下来介绍下HBase体系架构，HBase支持binlog同步和schema管理，将schema模式转化为数据库模式去支持SQL查询，这样就能方便开发人员按已有的技能开发。大大提升了效率，由原来的ID查询转化为row-key查询。第二个就是提供索引支持，风控领域需要通过各种各样的渠道查询，因此索引对其提升很大。

有了索引就是要把数据打通，如何将原来的数据导入系统的数据仓库，我们构建了export数据仓库工具，这也是HBase最大的一个优势。其特点是HBase文件和上层次是隔离的，可以通过HBase的export将整个文件取出来，利用Spark将其解析成表导入到数据仓库。同时可以使用增量export，只导出今天的数据，这样对数据库的影响很低。WareHouse上的数据以前都是从业务上进行，从数据仓库拖到WareHouse是比较容易的，复制过来后可以利用Spark做成HBase文件，直接利用bulk load导入HBase里面，这是一个在线服务，几乎不影响在线服务，bulk load效率也很高。我们系统中每天有几亿或十几亿的表导入HBase中，还会为其生成索引表文件，将索引文件和表都导入数据仓库。其他的数据库要么需要通过其接口或者SQL一条条写入才能生成索引，那么就是能可以导入文件，但是不能在线进行大数据量操作。

基于HBase做的风控系统已经上线，其实再往上，各个业务也想连接HBase数据库服务来解决他们的问题。比如爬虫服务，网页可能几百K或者上兆，放在MYSQL里面可能不接受服务，因为数据量太大（可能有几十T），还有就是它是一个冷数据，不是经常查询。这种HBase构建网关来提供服务，封装了一些简单接口，如get、scan这种常用查询模式的接口开放出去提供给业务使用。这种类似于数据库服务概念，我们还做了一些权限校验，各个业务线陆续使用这套完整的流程。WareHouse里面有些工作可以结合在一起，风控用到的一些特征，不仅仅是表里的结果，有些每天需要全量更新，依据用户过去的表现或数据计算更新一些数据，这些数据第二天需要实时查询。

系统上线半年，用户由单一风控用户发展到十几个，数据量是原来的20倍，访问量上百倍，最高时达到上千倍，用户量膨胀严重。这样经常会出现CPU不高，不知道谁在查询，CPU不高到底是哪个表出现问题，怎么样的SQL不合理。如果出现问题不很快解决，由于HBase特性regionServer继续时间过长，运行就会宕机。虽然会自行恢复，但是恢复时间影响查询时间。

接下来讲一下一个regionServer宕掉影响这么大，外面公司一个regionServer集群恢复也就半个小时，但是我们的很长，原因就是我们用了Phoenix索引组件。图上面部分是数据表region写入过程，写入的时候在服务端regionServer内部有个Coprocessor Host，将索引数据也会更新。当写入数据时会将索引数据写入索引表中。会生成一个indexer和WAL Updater，当写入WAL就算regionServer宕机也会保持数据一致性，当写入WAL，会将索引更新到region的index Table里面。当在Region Coprocessor Host发生crash或者需要recover时WAL会将数据 Replay到IndexRegionA RS2上，这样就保持数据一致性。

当一个region挂掉或者regionServer挂掉后，需要将这些region都Replay到另一个region上。图中方形是数据，圆形是索引表，索引表和数据表需要结合到一起Replay。每一个regionServer同时能Opening的region是有限的，剩下的会放在Pending组件中等待Replay。这样可能就会出现一个表在Opening，索引表在Pending里面，需要将index的WAL数据回放到index Region里面，但是其index region一直在Pending，最后会导致该region的Replay会失败。除了region挂掉导致时间很长外，还有一个就是Phoenix对数据写入失败后的处理机制，当index写入失败会触发Phoenix Index Write Error Handler，会尝试Disable Index Table然后尝试将RegionServer给Abort掉，这样原表就不会recover，这样就维护Index一致。在实际过程中一个数据量很大的表，突然将索引disable，每次查询都是访问全表，非常吃内存。

当没有索引，正常的一个region当需要recover需要多久，图中从Opening到完成Open启动服务需要十几秒。当mainstore没有flush就去Replay WAL时可能耗费的时间就更长，可能就需要几分钟，如果你有200多个region时这个时间是非常可怕的。

为了解决这个问题，在我们的上层添加功能而不是在HBase中改动，在上层做了很多工作进行管控来解决我们的问题。第一个就是监控，时间抖动是10秒，超过10秒就要响应。第二个就是做了一些SQl拦截，制定一些规则如scan是不是RowKey scan，再者查询是否用到索引查询，FullScan是不是允许，当表数据少时是否支持Count操作。

为了解决这个问题，除了做RuleBased SQL Interception还做了CostBased SQL Interception，运用了一些Phoenix机制，将数据做一些点位（GUIDE_POSTS）,如果RowKey A到RowKey B有40万条数是允许scan。通过对表细粒度拆分以及SQL的解析和Scan范围的解析，就可以精确到表级别控制你每个表可以scan多少条数据。规则不可能覆盖所有情况，因此还需要提供AdHoc Interception，当遇到某种不合理情况实时添加规则，当在遇到这种情形就无法执行。还可以进行用户级别，如果某个用户短时间流量很大，可以暂时将用户Disable掉，或者暂时限制某些表的写入操作。

通过这些改进后，region集群的recover时间由两小时缩短为15min，其实这里面更多的是Replay region里Mainstore的数据（大约10G）。

解决这些问题后又出现其他问题，如DNS解析问题，机器问题，如磁盘挂掉，人为操作失误。最后提出要求时间在5min，从系统开始出现问题到我们发现问题、开始解决问题、线上恢复问题这些都需要在5分钟内解决。解决方案采用MYSQL思想，使用双集群。当一个集群挂掉，另一个集群也是可以服务，将代理集群的写入操作复制到另一个集群中去。做了数据的复制、切换，当机器出现问题，切换到另一个集群，当恢复完成在切换回来，机器正常运行数据复制延迟大约10-20秒以内。真正切换时，需要将数据复制过来才能保证数据是一样的，我们会先将数据写入Disable掉，当数据复制完成后一致再进行切换。业务会告诉服务暂时不可用，双集群还有一个好处是人进行实时查询的集群可以连接到该集群来降低服务压力。这是一个冷集群，当数据量大需不需要预热，会不会被打垮，HBase有一个好处就是里面有些build等都是在内存里面提前完成，构建了缓存，同时也会做一些查询，进行一些预热。

其实现在很多人都不会讲HBase作为一个大数据存储，HBase成为了其中一个基础服务。我们的数据目前有几十TB，高峰时达到几十万QPS，基本维持在20-30万，SQL查询每天达到上亿。我们也会在探索如何提高可用性场景，刚开始选用的版本还没有高级的功能可以用，后续可以用HBase Region Replicate，实现几秒级集群间切换，当一个region挂掉，能几秒切换到另一个region继续服务。利用HBase Multi Tenant把一些核心的服务隔离，将服务进行分组。HBase2.0提供很多兼容性协议，对大数据平台升级很有帮助。再者就是多集群到多机房，能否摆脱Phoenix，自研SQL引擎，一般场景是分析人员给一些SQL，要对一些表做计算，我们将其翻译成Java代码执行，这样存在效率和沟通问题，因此想基于SparkSQL，将其改造能进行线上服务的内存计算， 4Core, 8G 20个context, 实现ms以下响应。当我们将上层的SQL层、计算层搞定后，再加上schema管理，就脱离了Phoenix，基于HBase的数据库。

作者介绍：

郭冬冬，挖财数据平台高级技术专家。硕士毕业于中科院，曾就职于同花顺，目前就职于挖财数据研发部，负责挖财大数据平台建设。开源社区爱好者，热衷于分布式爬虫，分布式数据库，大数据计算等技术。

——END——

（北京、杭州、上海、深圳）

内推信息：

文章没看够？下面还有: