阿里HBase在用户画像领域的实践-阿里云开发者社区

开发者社区> 云原生多模数据库Lindorm> 正文

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

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

HBase用户福利

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

背景

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

1.png

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

大规模数据下的难点

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

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

HBase在画像领域的应用

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

2.png

下面我们深入解读一下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返回给客户端

3.png

当我们理解了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。而离线系统中期望的是宽表的格式,数据按行组织。

4.png

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

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

结束

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

相关链接

阿里云HBase推出普惠性高可用服务,独家支持用户的自建、混合云环境集群
HBase毛刺消除利器-双集群并发访问

HBase技术交流

欢迎加群进一步交流沟通:
image.png
image.png

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

分享:
云原生多模数据库Lindorm
使用钉钉扫一扫加入圈子
+ 订阅

Lindorm是适用于任何规模、多种类型的云原生数据库服务,支持海量数据的低成本存储处理和弹性按需付费,兼容HBase、Solr、SQL、OpenTSDB等多种开源标准接口,是互联网、IoT、车联网、广告、社交、监控、游戏、风控等场景首选数据库,也是为阿里巴巴核心业务提供支撑的数据库之一。

官方博客
链接