阿里HBase在用户画像领域的实践

2019-12-13 6248

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

云原生多模数据库 Lindorm，多引擎多规格 0-4节点

云数据库 Redis 版，社区版 2GB

云数据库 MongoDB，通用型 2核4GB

简介： 互联网应用的一个特点是拥有海量的用户，这些海量的用户会产生海量的行为数据，有些产品还会需要去爬取更多的外部数据。基于海量数据的模型训练最终刻画出用户画像，基于用户画像自动的指导系统决策，在效率和准确度上给行业带来了质变。

HBase用户福利

新用户9.9元即可使用6个月云数据库HBase，更有低至1元包年的入门规格供广大HBase爱好者学习研究，更多内容请参考链接

背景

互联网应用的一个特点是拥有海量的用户，这些海量的用户会产生海量的行为数据，有些产品还会需要去爬取更多的外部数据。基于海量数据的模型训练最终刻画出用户画像，基于用户画像自动的指导系统决策，在效率和准确度上给行业带来了质变。常见的应用领域包括实时风控、实时推荐、实时广告竞价。

如上图所示，系统一般包括3个部分，数据采集系统、在线系统、离线系统。数据采集后会入库在线系统，同时数据也会归档到离线系统，离线系统周期性的对数据进行训练生成新的用户画像，新的画像回流到在线系统供上层业务查询。一般的查询场景都是通过一个key来查询某一行数据。在线系统中包含了实时和离线画像两个部分的数据，并且实时部分的数据一般只保留最近N天的数据。

大规模数据下的难点

在海量用户数据的场景下，我们总结了实时应用的一些难点或者问题：

上百GB、几十亿模型数据如何快速回流在线系统？如何不影响在线系统的对外服务？
一般实时应用全链路的超时时间在200ms或者100ms以内，留给数据库的时间就更少。另一个层面，数据库响应越快意味着单位时间内可以应用的规则越多，业务就有更多的发挥空间。因此对系统的平均延迟、P999毛刺都要非常高的要求。在这样一个前提下，如果将离线计算好的上亿、上百亿条画像数据回流在线系统，就是一次人为的热点，影响在线服务。一般选择在低峰期执行，但随着业务发展数据量猛增，问题只会越来越困难。
如何快速的存储用户行为变化，又保障读取延迟的稳定性？在线系统的一个职责就是存储用户的实时行为，实时画像。因此系统必须支持非常高的并发写入，在万、十万、百万规模上随业务增长。而同时系统也要支持同样甚至更多体量的读，并且读取的延迟既要低又要稳定。我们知道不同客户之间的行为差异是很大的，一些操作频繁的用户产生的数据可能非常多，当读取到这个用户时会消耗更多资源，请求变慢甚至影响其它请求。
如何高效的聚合数据到离线数仓？我们常见的有两种方式：一种是双写，一条写在线系统，一条写离线系统。数据可能先在kafka系统中缓存，缺点是多维护一条链路。另一种是从在线系统拖数据，有些会直接通过API扫描过滤数据，这种对在线系统的影响非常大。

HBase在画像领域的应用

以蚂蚁风控系统为例，使用HBase来作为在线系统，很好的解决了上面三个问题。首先HBase支持Bulkload的写入方式，可以在百毫秒内向系统中加载几十亿行数据，并且不影响系统的读写响应。其次HBase的动态列、稀疏列特性支持真正的部分更新，用户的一次行为变化可能就需要更新1个列，HBase可以只写入这个列。再次HBase的多版本特性可以控制数据规模，比如记录用户的最近登陆信息，大部分人一天登陆不超过10次，但可能有人几百次，为了保证读取时间的稳定性，可以通过HBase设置最多保留100个版本，每个版本记录一次登陆。超过的版本系统自动删除。最后我们开发了一套基于HBase日志的增量归档服务，可以把HBase的增量数据按时间片分区归档到离线系统，由于是基于日志的增量，可以做到不影响在线系统。

下面我们深入解读一下Bulkload和增量归档技术：

Bulkload技术

为什么HBase可以直接插入一个文件(HFile)，其它的系统如RDS，MongoDB，ES是否也可以呢？我们以两条数据更新为例来解释。

T1时刻系统写入一行，行键是row1，包含3个列
insert row1，column1=a，column2=b，column3=c

T2时刻系统局部更新行row1，把column3更新为x，并增加一个新的列column4
update row1，column3=x column4=y

T3时刻读取row1，应该返回
row1，column1=a，column2=b，column3=x，column4=y

首先看一下文档类存储的实现，在更新row1时，需要先读取row1，column1=a，column2=b，column3=c，我们记为版本1，然后把版本1的内容与跟新内容合并为row1，column1=a，column2=b，column3=x，column4=y，我们记为版本2，最终的写入包括删除版本1和插入版本2。这样约束了系统的更新只能走API。

然后我们看一下HBase的实现，在更新row1时，不需要读取旧行的信息，直接写入 row1，column3=x column4=y。我们可以想象最终在文件层面HBase有两个文件，一个存储着 row1，column1=a，column2=b，column3=c ts=1 ，另一个存储着row1，column3=x column4=y ts=2。其中ts是版本号，一般情况下就是数据的入库时间戳，这里我们用1、2来简化。当读取row1的时候，系统会从两个文件中读取两条row1进行合并，合并的规则是取版本号最大的KV，因此column3有两个版本1、2，则选择较大的版本2的值x返回给客户端

当我们理解了HBase这样的一个特性，就可以发现其实可以直接向系统中插入一个HFile，后面的查询就可以感知到这个新的HFile并合并其中的内容。写入绕过了存储引擎，日志、MemStore、MVCC等等都不需要，文件本身可以由数仓生成，然后传输到HBase中的HDFS，执行一个rename操作即可将文件加载到HBase，加载过程仅需百毫秒。整个流程只会消耗HBase系统的网络和磁盘IO来复制文件，而且HFile文件的压缩率一般在4-10倍，这也大大降低了资源消耗。所以使用Bulkload可以做到基本不影响在线系统。

阿里HBase在Bulkload方面的优化包括：

提供同时向主备进行bulkload的服务，保障主备之间数据的一致性。服务使主备同时加载相同文件，时间差保持在1秒内。
保证bulkload文件的本地化率。默认情况写入HDFS的三副本是随机，优化后我们可以保证其中一份副本一定在对应的分区所在的DN节点上，使得hbase的读取可以走短路读。

增量归档解决方案

增量归档是一个独立于HBase的服务。它监听HBase的日志产出，解析日志并同步到离线系统比如Hadoop或者MC。这里有一个关键点是数据在离线系统是按时间分区的，这样方便进行T+1的计算。对于离线计算来讲，需要数据是保序到达，并且落入正确的分区。其次HBase日志中的数据是KV的格式，每一个列是一个KV。而离线系统中期望的是宽表的格式，数据按行组织。

在同步的过程中，数据会先同步到离线系统中的一个临时表，数据来源于多个节点，是乱序到达。同步系统会通过分析计算出“同步时间点T”，小于T时间的数据肯定已经到达，此时可以把小于T的数据“Dump”到结果表，并且在这个过程中转化成为宽表的格式。

HBase日志本身是有生命周期的，会被删除。为了保证数据在删除前一定同步了，我们在HBase层开发了Log Exporter，让归档系统可以来注册消费日志并通知日志的消费进度。

结束

综上所述，HBase非常适合用户画像场景，在实时风控、实时推荐、实时广告竞价领域有着广泛的应用。基于HFile的Bulkload和基于WAL的增量归档使得HBase与离线系统之间高效、平滑的进行数据流转，最大化减少离线对在线的影响。HBase支持高并发的读写吞吐，并且可以保持稳定的响应时间。HBase良好的水平扩展性可以从容的应对业务增长。