Hologres OLAP场景核心能力介绍-2024实时数仓Hologres线上公开课02
内容介绍:
一、OLAP场景与痛点
二、Hologres OLAP场景核心能力
三、典型客户案例
本次分享的主题是Hologres OLAP场景核心能力介绍,由Hologres产品经理赵红梅(梅酱)分享。
一、OLAP场景与痛点
OLAP的典型应用场景有很多,总结下来大概会有如下的四类:
第一类,BI报表分析类,比如BI报表、实时大屏、数据中台等。
第二类,人群运营类,比如对人群的精准营销、用户画像、圈人圈品等。
第三类,日志检索分析,比如行为分析、流量分析、广告投放等。
第四类,实时监控类,比如订单物流的监控、网络的监控、还有实时风直播监控等。
总的来说,OLAP场景广泛的用在各个行业。比如广告、游戏、电商,互联网等。
基于这些OLAP场景,我们可以来分析一下,如果要支撑这些复杂的OLAP多维分析,那在技术上遇见的不变的难题有哪些?
第一,技术栈复杂。通常来说,如果要支持多OLAP分析场景,可能会运用上多个产品,比如mysql、CK、Doris, CK可能专用于流量分析场景,Doris可能用在多位分析的场景等。这就导致我们技术上的组件会变得非常繁多。
第二,需求响应时间长。因为场景变得越来越丰富,业务需要更加灵活的OLAP分析,随时可以变动我们的需求。受限于技术栈复杂,开发没办法很快的响应业务的需求,这导致业务的响应时间变得很长。第三,开发、运维成本高。对于多种技术产品共同使用在不同的场景来说,开发、分析还有BI人员都需要学会不同的开发语言,这就导致上手难度变高。同时也需要对不同的组件运维,运维也会变得复杂,会显著带来各种成本。
第四,数据时效性不能满足业务的需求。比如的产品可能专注在数据的实时写入与更新,查询的能力会弱一点;有些产品专注于是在查询的能力,在数据的写入更新等等能力上不足。这导致没无法很满足业务大部分OLAP分析的需求,也就不能做更精细化的运营分析。
第五,生态兼容能力。不同的业务它有不同的开发和分析工具,需要底层的技术产品对这些工具一一适配,有些产品可能在兼容度上不高,这就需要额外开发。业务上还有额外的定制需求,比如做专门的漏斗分析需求、流程需求等等。
第六,业务间相互影响。随着相同的产品支持不同的业务,如果这个产品底层的技术产品没有很好的隔离机制,导致业务间相互影响,从而影响了线上业务。
二、Hologres OLAP场景核心能力
而Hologres的定位是一站式实时数仓,通过下图就可以很容易的理解Hologres的核心能力。
从下往上看,在存储层Hologres既支持离线数据的导入,也支持实时数据的写入与更新,对于数据湖的数据也可加速查询。
在数据应用层Hologres支持OLAP的多维分析;支持hbase region这一类的在线服务; 也可以湖仓一体;同时Hologres也与达摩院的向量引擎proxima深度打通,支持向量和大模型。
Hologres如何解决OLAP场景的难题?对于下面的六个难点Hologres有一一的应对方法。
技术栈复杂,Hologres采用服务分析一体化架构;需求响应的时间长,数据时效性低,基于Hologres引擎的计算能力、高性能的写入和实时能力也可以得到满足;开发、运维成本高,Hologres有binlog简化、数仓分层,有更多的函数等,可以进一步的降低开发和运维成本;在生态上,Hologres也支持多种BI和开发工具,也能很好的满足生态兼容的问题;在高级能力上,Hologres支持计算组隔离serverless computing等能力解决业务间相互影响的问题。
1.Hologres OLAP场景的核心优势
第一,Hologres支持实时数仓OLAP分析。实时数仓在OLAP场景上对于数据写入的时效性有严格的要求,可保持数据的新鲜度。Hologres支持高性能的实时写入与更新,写入即可查。同时, Hologres采用列存的存储模式,在OLAP场景上使用阿里ORC的压缩格式,支持多种索引,如簇簇、位图、字典等等,都可有效提高数据的检索效率。同时我们是分布式架构,分布式计算、MPP架构,可以并行化的处理各种query。在OLAP场景也支持组件的局部更新,满足OLAP场景的不同需求。
第二,在湖仓场景上,可对湖和仓的数据做直读加速。比如MaxComputer、 OSS 、Paimon的数据秒级交互式直读;无需移动原数据,元数据自动搬迁,不需要额外处理。如果想实现更好的性能,就可把湖和仓的数据导入OSS, 导入Hologres列表,同步的速度是百万行每秒的速度。
第三,在生态上Hologres兼容PG生态。上层的语法是兼容标准的postgre开发语法的;同时开发工具和BI工具上也是兼容PG的; 另外也支持PG的多种扩展,比如postgis,都可支持。同时在一些深耕的领域,比如流传、漏斗、画像等等,都可以很好的支持小流量分析、画像分析等场景。
先看一下Hologres丰富的索引能力。Hologres的数据存储格式可以支持行存、列存及行列共存。在OLAP场景上,大多使用列存存储数据。列存的好处是可支持数据的多维分析、过滤、聚合等,有效的支持分析师、报表这类的web多维分析能力。查询的QPS根据query的复杂程度有不同,响应时间从毫秒级到秒级。另外Hologres有丰富的索引,从上到下可以看到,第一层是分区,可以快速的定位到数据主要分区;第二层是distribution key, 可以定位到数据所在的节点;下一层是event time column,可快速定位到数据所在的文件;再下一层是分段键,可让数据在文件内排序。基于Hologres丰富的索引,还有Hologres的存储格式,可以做到高效检索数据,即使是复杂的OLAP多维分析也能达到秒级甚至毫秒级的响应。
Hologres的查询性能。去年首次参加TPC-H的标准性能测试,在30T标准测试的结果中,Hologres斩获全球第一,领先全球第二名23%,这证明Hologres查询性能是毋庸置疑的。
这里Hologres与同等olap产品的对比,这里以click house为主, click house其实更擅长做流量分析的场景,Hologres与click house对比有以下几个方面可以分享。
第一,性能方面。同样使用SSB的数据集,相同的规格的实例规格对比,在所有的查询中,Hologres的查询性能都比click house更快,这意味着click house的OLAP能力也比CK更快。
另外给大家简单介绍一下Hologres和CK的一些区别。CK更多的定位是做流量分析的场景,Hologres是通用的实时数仓,擅长的领域不仅是流量分析,也包括多维分析各种OLAP多维分析的场景,同时也支持像HBase release这样线服务的场景。存储上CK采用列存,Hologres也可以使用列存。在数据写入的时效性上,因为CK需要对客户端做产品处理,所以写入的时效性基本都是秒级,而Hologres自适应,P处理,可以做到毫秒级,数据写入即可查。尤其值得一提是数据更新能力, CK不支持完整的组件能力,不支持违约金的约束,像OLAP场景中,对于数据更新、删除以及局部列更新、宽打宽局部列更新这样的场景,CK无法很好的支持,而Hologres有完整的组件,支持唯一性约束,这样子就可在OLAP场景非常完整的支持组件的更新、删除、宽表打宽局部列更新。在查询上,CK更多的是做大宽表的查询,而Hologres在查询的场景上,不仅支持大宽表的查询,也支持多表的JOIN、复杂的聚合分析等等,同时像窗口函数,Hologres也比CK支持的更多。另外,在高级的企业级的能力上,CK没有权限、分离的高级功能,Hologres不仅有各种丰富的权限控制,同时也有存储、隔离的资质,比如计算组实例、serverless computer等,可以高效的满足企业各种隔离的需求。
接下来是数据同步能力。Hologres在底层是与max computer打通的,可以直接查max computer盘古数据。相比于其他的产品,查询性能也会更快。如果我想要max computer的数据直接导入Hologres,也支持百万行数据的秒级同步。下图是数据同步的性能对比,比如同样使用TPC-H数据集,分别使用公网copy 、VBC copy以及max computer写入的方式来做写入性能对比。通过max compute直读写入的方式,能够显著提升写入性能,数据的延迟基本在毫秒级。这是某用户使用Hologres直读max computer的反馈,没有用直读时候CPU、延迟和连接数消耗较快, 用了Hologres直读MC之后,延迟、连接、CPU消化等都有所下降。
接下来分享一下Hologres的实时同步能力。在OLAP场景,很多业务对数据的时效性有非常高的要求。Hologres内置fixed plan,可以达到非常高性能的实时写入与更新。
简单介绍一下fixed plan, 比如有一个数据更新insert on conflict的数据更新的SQL,如果没有用Hologres内置fixed plan的能力, plan非常复杂,需要经过优化器解析、协调器查询引擎、存储引擎等多个组件,导致SQL最终的耗时变得非常高。如果用了Hologres内置fixed plan, SQL的plan会变得非常简单,只有一个fixed insert一个字段,这意味着不需要经过那么多组件就可以直接查存储引擎的数据。如果用了fixed plan,它的RPS也会比没有用的更高。
这有一个标准的更新对比,同样使用列存,使用不同的存储模式,使用fixed plan和未使用fixed plan数据更新的性能对比,在开启使用了fixed plan之后与没有使用fixed plan的性能相差几倍到几十倍。另外fixed plan现在已经广泛的应用在众多的业务当中,支持场景也非常多,比如单行写入、多行写入、局部列更新、写入负表等,可满足业务的不同需求。
2.数仓分层开发效率的问题
讲到写入软件之后,我们来讲一下我们数仓分层开发效率的问题。
一般来说OLAP场景上数据量非常复杂,业务上都需要做一定的数仓分层,比如传统的做法可能是像flink, 然后直接写到卡夫卡,最后把ADS层写到数仓这的方式实现数仓分层。
而Hologres在数仓分层的能力上,提供Binlog能力,可以记录单表DML的变更记录。有了Hologres Binlog之后,就可通过flink直接读取Hologres Binlog,记录数据变更,达到数据分层的目的。
以前是用卡夫卡,现在可把卡夫卡替换,直接用flink结合Hologres Binlog实现数仓分层,这样也可达到Kafka、datahub同等的消息队列能力。在Hologres Binlog里,一张表既可以做flink的sink表,也可以做flink的设施表,增加了数据复用的能力,同时也简化了数仓分层的体验。
讲完数仓分层以及写入的更新、离线同步的一些能力之后,下面来介绍一下Hologres在OLAP场景上查询的能力。
第一是Runtime Filter,在OLAP场景会有很多多表关联的场景,比如在画像分析的场景上,需要使用用户的行为表、用户的属性表做join,
计算用户画像,用户的行为表通常是明细表,存储的数据量会比较多,属性表是小表,就会有大小表join场景。而Runtime Filter要解决的就是join效率的问题,它的原理是如下:传统上如果使用join,会有build端和probe端,如果大小表的数据量差异很大,会导致在join时IO较高。Runtime Filter在join之前会根据生成一个轻量的过滤器,把join所需要的数据先过滤出来,最后参与join的专业计算,然后对表去做数据的裁剪,可以减少join的数据量,同时也可以减少数据在网络传输的量,有效提升join的性能。通过Runtime Filter可以很好的提升大小表的join效率。值得一提的是,让Runtime Filter是一个数据的底层能力,就是引擎的底层能力,不需要做额外的设置,就可以自动优化、使用。
可以简单分享一下Runtime Filter效率问题。比如两个表单个join字段,是否开启Runtime Filter的效率,可以看到,开启Runtime Filter后,不管在CPU、内存还是source上,都比没有开启的更高。随着query变得越来越复杂,在有多个join字段时,Runtime Filter能力更强。比如有两个join字段,如果开启了一个Runtime Filter在CPU的消耗上,更损失CPU,同时耗时也会比没有开启Runtime Filter更高。
3.Hologres专用的流量函数
下面要介绍一些Hologres专用的流量函数。
通常在OLAP的场景,比如画像、流量分析、行为分析等,都需要对用户的一些行为路径做一些分析,Hologres提供专门的函数,比如漏斗函数、留存函数、路径函数等,都可以满足流量分析的诉求。我们在业务上就可以直接使用这些函数,以满足业务更精细化的运营需求。可能有一些OLAP产品不能支持漏斗、留存,还有路径这样的函数,常见的做法是,比如漏斗要用开窗函数,留存函数路径函数等可能都需要用到开窗、join等非常复杂的SQL写法,然后才能满足业务需求。而在Hologres里,如果要实现流量分析的诉求,可直接使用漏斗函数、留存函数、路径函数,同时也可以简化流量分析的步骤,达到非常好的性能。比如像下图漏斗函数的性能对比,在没有漏斗函数时候,用户通常会使用多表join的方式来做,带漏斗函数之后的效率显著提升。
下面是列式的JSONB。日志数据、标签数据等业务上会有多维分析的诉求,通常会用JSONB或者是用array的方式存储,它的好处就在是使用上可以灵活、随意的加字段,但是坏处是性能不能满足业务的长需求。以这个case为例,有一个JSONB的支撑,JSONB里面还嵌套了JSONB,如果想查某个JSONB里某个key的value,需要对JSONB所有的key都做一遍扫描,然后才能查到,导致IO消耗特别高,CPU利用率特别高,延迟也会变高。
Hologres支持JSONB列存,在底层就可以把Jason的数据按列存储,好处是想要查某个key时,直接就能查这个Key,不需要把整个数据JSONB扫描出来,可以有效降低IO消耗,以及CPU, 从而提升查询性能。同时按列存储可以非常有效利用ORC的压缩能力,存储也更加省。分享一下使用列式JSONB的效率。同样做PV的两个大表,如果以前用的是array,延迟基本都是秒级,但用JSONB后,延迟都到了毫秒级,同时存储也会下降百分之五六十,可以帮助用户、业务进一步的降本增效。
下面就是RB,它的场景是在对数值类数据的去重和标签计算。要计算某个UV,例如电商里店铺的加购UV、直播里的成交UV、访问UV、
还有APP里的访问UV等。通常对于这种数字类的数据做精确去重时,常见的做法有两种,一种是使用预聚合的方式,另一种是使用明细表直接查,然后最后使用他们的系统的方式。这两种方式都各有优缺点,使用预计核的方式没法支持任意的周期查询,使用明细表的方式虽然在开发效率上可以灵活,但是在QPS上没办法得到较高的QPS,而且如果的QPS一旦高了,延迟会降低。可以通过Hologres RB的函数快速在底层构建一个RB, 同时可以支持任意长周期的基数计算。
这里有一个示例:以前要计算UV时,使用明细表和维表join的方式来查UV, uniq就是计算UV,是unique product是在计算商品的UV,查一天或者查几天的数据,可能数据的实时性很好,但把时间周期拉得更长,支持半年或者一年的数据之后,这种方式不能很好的满足业务的需求,IO会变得特别高,查询效率会变得特别低,因为明细表的数据会特别大。用RB后,可以通过B的方式预聚合,每天生成一个预聚合的结构表构建RB, 这样就可以支持任一周期的查寻,不管在时间维度上是选什么样的周期力度, RB每天都可以构建,可以显著降低查询延迟。
这有一个RB和join效率的对比,可以看到,在支持7天、30天、90天,还有100天这种随着时间越来越长的技术查询时,RB的效率显著比join更高。当然这只是单表的查询,相比于180天Hologres是毫秒级而言,join的方式是秒级。如果把QPS、并发加的更高,原来join方式的效率会更低,RB的方式因为它单个SQL的查询足够快,所以它的并发能够支持更高。
讲完查询上,可以来讲一下生态上。Hologres兼容PG生态,意味着说只要能连接PG的开发工具或BI工具,都能无缝对接Hologres,比如data V、Quick bi、 meta base、tableau、 SAP、Power BI等,都可无缝对接Hologres。市面上主流的一些开发工具、BI工具也可以直接对接,开箱直接使用,无需额外的定制开发,生态上也更加兼容,满足业务的不同需求。
随着技术产品对业务的支持变多,不同的业务有不同的复杂可能,要怎么样去做有效的隔离呢?
Hologres有warehouse计算组实例的功能。通过计算组实例,可以有效隔离不同的负载,在warehouse实例内可以分不同的计算组,以根据业务的负载分,也可以根据不同业务来源分。比如根据负载分,可以把写入上分成离线写入计算组、实时写入计算组,可以有效的避免写入之间的相互影响。
在查询上也可以跟根据不同的业务来分不同的计算组,可以分为OLAP查询计算组和在线服务计算组,可以有效的把查询隔离开,不同的计算组之间是完全隔离的,写入与查询之间相互不影响,写入与写入之间不影响,查询与查询之间不影响,同时,对外只有一个endpoint,这样就可以实现业务的自动迁移。当某一计算组目前负载较高,或是遇见卡住等问题,可以快速的将流量切到其他的计算组,无需做应用变更,同时也可对计算组做单独的扩修容。
比如今天OLAP计算组要上一个新的业务,并发、QBS也比之前更高,那就可对OLAP计算组做单独的扩容,以满足业务的快速需求。
另外在OLAP场景上也会有一些大型的任务,比如大型的DML任务、做ETL处理。Hologres提供serverless computing功能。serverless computing概念是Hologres自己内置,把的DML任务路由到Hologres自己共享的serverless computing上面去,可以有效的把大任务隔离,不仅可以降低成本,同时也可以提升性能。
某个用户在没有使用serverless computing之前,业务是非常有周期性规律的,每天晚上会有定时的调度任务来对数据做调度,白天是查询,其实查询的负载不是特别高。使用serverless computing之后,周期性的调度任务完全由serverless computing承载,这样不管白天和晚上都相当于是空闲下来,可以把资源很好的节约,节省成本。开启serverless computing功能,语法非常简单,只需使用一个goc,就可以把指定的DML任务路由到serverless computing执行。
三、典型客户案例
下面给大家分享一下在这个场景上面的一些典型客户案例。
第一个是小红书。小红书以种草笔记内容的方式被大家所知道,搜索推荐的团队是非常重要的场景,主要场景就是对首页客户去做人群精准、高效的匹配,为用户做推荐最精准的内容。典型的OLAP场景像实时的指标报警、实时的指标分析等,原来使用开源自建的CK来承载OLAP的分析业务,随着业务的发展,他们的痛点变得越来越明显。自建CK需要有专门人运维,运维成本特别高。而CK存储只存七天以内的数据,超过7天存储就会爆炸, CK不是存储计算分离的架构,存储会随着数据量变多而爆炸。
第二是查询,通常CK只能查小于三天的数据,如果需要对用户做更精准的匹配需要更长时间范围内的数据,CK没办法很好的支持。同时CK是没有组件的,没法对数据去重。当CK over之后,不能自动数据重追,数据有正确性问题,没有组件就没有数据的唯一性,容易出现数据的正确性问题。同时自建的CK运维也会变得越来越复杂。于是小红书通把自建的CK替换成了Hologres。原有的价格不变,对小红书带来的显著的收益,即多、快省。省:用户不需要自己去运维一套CK的集群。
Hologres是免运维的,可以显著减少人力成本;快:后边是不仅可以支持,因为是存储计算分离的架构,不仅可以支持七天,也可以支持等长周期的数据。如果存储不够,可以直接按需扩缩容。同时在查询性能上也比CK更快, Hologres有完整的组件可以实现业务的更新、去重。即使上游换了,也可以自动追数据,也不会出现正确性的问题。
第二是乐元素,是一个游戏公司,它著名的产品有开心消消乐、海滨消消乐等。以前乐元素的OLAP自助分析平台更多支持的场景,像用户的行为分析、活动分析、流程分析等,这些都是常见的游戏分析的场景。通过Hive+presto的方式支撑业务的分析需求,随着业务的快速迭代,Hive+presto没有办法很好支持实时的能力。同时对他们来说,运维、性能等方面都没有办法很好的满足需求。乐元素有非常多用户的行为分析、流量分析的诉求,Hive+presto没有办法很好的支持,留存、漏斗这些的场景是没有专门函数的,不得不手写SQL来支持业务,这导致业务的效率变慢。
于是乐元素从Hive+presto 迁移到Hologres,运营效率都得到了显著的提升。首先,Hologres有专门的留存、漏斗的函数,还有路径的函数,很好的满足游戏行业用户的行为分析,查询效率也相比原来的SQL提升近十倍,另外稳定性也得到了提升,以前Hive+presto的时候,只要业务有高峰期,就不断的扩缩容,对于人运维的压力较大,而Hologres有湖仓分离的架构,可以根据业务的需求动态的扩缩容,极大的避免运维成本,提升弹性能力。第三,成本节省。相比于原来的Hive+presto自建,现在通过Hologres后,整体成本节约了50%。同时人力成本也节省了近几十万元。
以上是本次分享的全部内容。