简介: 本文将介绍阿里云Hologres如何基于RoaringBitmap进行UV等高复杂度计算的方案,实现亿级用户万级标签亚秒级分析,帮助用户从Kylin平滑迁移到Hologres,实现更实时、开发更灵活、功能更完善的多维分析能力。
在用户行为分析和圈人场景中,经常需要从亿级甚至十亿级用户中快速筛选出符合特定标签的用户统计,很多企业会使用Apache Kylin(下文简称Kylin)来支持这样的场景。但是Apache Kylin的核心是预计算,当遇上设计不合理的Cube,或者需求维度多的场景时,会遇到维度爆炸,Cube构建时间长,SQL函数不支持等问题。
本文将介绍阿里云Hologres如何基于RoaringBitmap进行UV等高复杂度计算的方案,实现亿级用户万级标签亚秒级分析,帮助用户从Kylin平滑迁移到Hologres,实现更实时、开发更灵活、功能更完善的多维分析能力。
对比项 |
Apache Kylin |
Hologres |
差异点 |
定位 |
MOLAP on Hadoop |
Real-Time MPP Data Warehouse |
- |
建模方式 |
星型、雪花模型 |
宽表模型、主题模型 |
Hologres无需复杂建模理论和建模过程,数据导入即可查 |
核心原理 |
空间换时间,减少运行时计算,预计算Cube,依赖Hadoop |
并行计算、列存、向量化,充分利用多节点,多核计算资源 |
Hologres没有存储爆炸问题,无需预构建等待 |
运维方式 |
依赖YARN,HBase,ZK等,外部依赖多 |
计算存储分离,弹性伸缩,升级平滑,无外部依赖 |
Hologres托管式运维,运维简单,无需Hadoop技能 |
使用场景 |
固定报表,固定维度组合,固定指标服务,秒级响应 |
敏捷自助报表、自助式分析、探索式分析、自助取数、在线数据服务,秒级响应 |
Hologres分析更敏捷,无限制,支持完善的SQL Join,嵌套查询,窗口函数等 |
查询接口 |
自定义JDBC,ODBC,有限SQL能力 |
兼容PostgreSQL,标准JDBC、ODBC,支持标准SQL |
Hologres兼容开源生态,SQL标准 |
开发效率 |
依赖于建模人员的熟练度,掌握Kylin的复杂建模技巧 |
针对“表”设计,概念简单 |
Hologres上手容易,学习门槛低 |
数据时效性 |
T+1,加工流程长,数据修正慢,模型修改成本非常高 |
实时,写入即可查,数据可更新,模型可变更 |
Hologres T+0,全实时 |
基于上述的比较,我们看到Kylin和Hologres拥有一些共同的场景:海量数据交互式分析、亚秒级响应、横向扩展能力。Kylin有很多优点,包括:最小化查询开销,以点查的性能完成多维分析,查询性能更稳定,利用Bitmap支持全局精确去重。同时也发现了一些Kylin的使用难点,包括:建模复杂(主要由IT团队负责建模),Cube膨胀(存储成本高),构建Cube时间长(业务不实时,构建任务资源消耗大),模型不可变(业务不敏捷),SQL支持能力弱(固定的Join连接条件、有限的SUM COUNT算子,BI兼容度低,SQL协议不标准),可扩展能力弱(UDF少)。
迁移到Hologres之后,可以获得的收益包括:建模简单(面向表,DWD&DWS),SQL能力强(兼容PostgreSQL11,支持Ad-Hoc Query),数据链路实时(写入即可见),运维简单(无Hadoop依赖)
在场景迁移之前,首先介绍以下精确去重和累加计算在Kylin和Hologres上不同的实现方式,以便于根据不同场景选用不同的方式去迁移原有业务。
如下图所示,Kylin根据维度和度量,进行多次预计算生成2^n个cuboid(n为维度数量)来构建cube。查询时,根据查询的维度,映射到相应的cuboid得到度量结果。Cube相比原始明细数据会有N倍的数据膨胀,且非常不灵活。
对于Hologres来说,去做精确去重和累加计算则更为灵活:
综上所述,Kylin对可累加指标或精确去重指标的查询时,需构建Cube才能获取较高性能,这将引入额外的预计算和数据膨胀。而Hologres则更为灵活:
本文下面将会介绍基于Hologres的DWS层构造和查询方案。
BasicSummaryTable
,如Kylin中 Fact A left join Fact B
,指标:Sum(a), count(b)
,Hologres中执行 insert into BasicSummaryTable(col1, col2, ..., coln, sum_a, count_b) select col1, col2, ..., coln, sum(a), count(b) from A left join b group by col1, col2, ..., coln
. 结果保存为BasicSummaryTable表。BasicSummaryTable
表给BI应用。
DWS层的构造中,最重要的就是各种度量数据(指标)的聚合,需要保证各指标都是可累计的。对于SUM、COUNT、MIN、MAX、AVG(可通过保留两个字段:sum和count来解决),指标的可累计是非常简单的。
但对于COUNT DISTINCT类的指标(需要精确去重的指标,例如UV),也需要保证在DWS中,这个指标是可累计的,可通过Hologres原生支持的RoaringBitmap数据类型来进行计算和保存。
下面通过一个案例介绍Hologres中通过DWS来计算大时间范围的PV、UV的最佳实践。
PV (Page View): 字面含义页面访问量,比如一天内页面的累计访问量。其实也可引申为某段时间内某个指标的累加量。比如:双十一期间某件商品的点击量,活动促销期间某个地区的订单量等。
UV (Unique Visitor) : 访问网页的自然人,如果有20个人一天访问某个页面100次,这一天就是20个UV。可以引申为某段时间内某个指标精确去重后的量。
PV和UV是分析场景中比较重要的两个指标,下面将以T+1离线场景为案例,进行PV UV计算的介绍。
每天有几亿条数据,客户总量千万级,每日UV在百万级,需要T+1根据十个左右维度(支持维度间任意组合)查询一天,一周,或者一个月甚至半年期间相应的用户数去重统计信息,得出用户数精确去重指标UV,以及访问量PV。
如果不采取任何预聚合运算,上述场景计算用户数精确去重指标UV和访问量PV,SQL如下:
select count(distinct uid) as uv, count(1) as pv from src_t group by dim1, dim2 where ymd ='20210426'; select count(distinct uid) as uv, count(1) as pv from src_t group by dim1, dim5, dim9 where ymd like '202103%'; --查询区间为3月份 --group by的字段是固定维度的中任意维度的组合 --where 过滤的区间范围 从一天到半年不等 --因此有多少维度和时间的组合需求,就需要查询多少个这样count distinct sql,每条在查询时都需要大量计算
这种方式下,根据查询区间,每次查询要对几亿条到几十亿甚至几百亿条数据进行多个维度的Group by,然后再使用COUNT DISTINCT进行精确去重,会产生大量的数据交换计算,实时地得到结果需要一定量的计算资源,大大增加用户的成本。
Hologres内置Bitmap类型,通过计算一定维度组合条件下的Bitmap结果集,把维度的所有组合生成预计算的结果表,简单原理如下:
查询时,根据查询时的维度,查询对应的预计算结果表对桶进行聚合运算即可达到亚秒级查询。
--计算bitmap insert into result_t select RB_BUILD_AGG(uid) as uv_bitmap, count(1) as pv from src_t group by dim, ymd; --存在跨天查询的需求,日期也必须加到group by维度中 --查询时 select RB_CARDINALITY(RB_OR_AGG(uv_bitmap)), pv from result_t where ymd = '20210426' select RB_CARDINALITY(RB_OR_AGG(uv_bitmap)), pv from result_t where ymd >= '20210301' and ymd <= '20210331'
后面我们将会陆续推出Hologres基于RoaringBitmap的高效UV计算最佳实践,主要内容如下,敬请期待:
Apache Kylin:http://kylin.apache.org/
Kylin精确去重:https://blog.bcmeng.com/post/kylin-distinct-count-global-dict.html
Hologres RoaringBitmap函数:https://help.aliyun.com/document_detail/216945.htm
原文链接
本文为阿里云原创内容,未经允许不得转载。