HologresV2.2版本发布直播解读
内容介绍
一、产品简介
二、Hologres V2.2版本特性介绍
一、产品简介
实时数仓Hologres是一站式实时数仓引擎,支持海量数据实时写入、实时更新、实时分析(写入即可查)、支持标准SQL(兼容PostgreSQL协议),支持PB级数据多维分析(OLAP)与即席分析(Ad Hoc),支持高并发低延迟的数据服务(Serving),与MaxCompute、Flink、 DataWorks无缝集成,与DLF、OSS深度融合,提供离在线一体化全栈数仓和湖仓一体的解决方案。
产品的主要优势体现在四个方面:
首先支持实时OLAP分析,支持高性能的写入,写入即可查;使用了业界主流的列存模式,支持多种索引,包括聚簇索引、位图、字典等;支持向量化,使用全异步调度框架,最大程度的释放硬件性能;Progress从第一天诞生就支持主键模型,并支持主键去重,基于主键的整行更新、部分列更新等多种丰富的更新场景。
其次,支持Serving场景,支持百万到千万级别的高性能检查;支持行存;对于Serving的场景,高可用尤为敏感;支持多副本模式,当一个副本发生故障时,点查会自动重试,最大程度的保证点查场景的可用性;点查不仅对于延时非常敏感,对于p99的延时抖动都非常敏感,所以我们也支持了溶剂级别的物理资源隔离;支持读写分离架构,最大程度的保证了多种负载不互相影响。
第三,支持湖仓数据交互式分析,对于MaxCompute数据湖中的表进行秒级的交互式查询;还支持百万行每秒的极速数据同步;无需主动建表,支持元数据自动发现,极大化的简化用户的使用。
第四,我们使用PostgreSQL生态兼容PG的开发工具和BI工具;支持。PostgreSQL多种扩展,如PostGIS扩展。
二、Hologres V2.2版本特性介绍
1.Hologres V2.2的特性
Hologres V2.2版本新增的特性主要涵盖五类能力,包括引擎能力增强、弹性能力、湖仓一体、运维监控和容灾能力。
引擎能力:
支持了向量化执行引擎HQE的增强,JOIN性能有30%以上的提升;查询优化器性能提升,SQL在Plan阶段的处理速度提升40%以上;新增多种种丰富的路径分析函数,简化分析流程。
弹性能力:
支持了serverless Computing,显著提升稳定性,弹性降本。
湖仓一体:
支持了直读OSS文件,性能提升五倍以上;还有多种的缓存策略;以及多种谓词下推过滤,极大的提升性能;同时支持了Paimon格式。
运维监控:
提供了多种能力,包括SQL指纹、Query洞察、SQL诊断和表索引诊断、以及新增了15个以上的Metrics,可观测性增强。
容灾:
支持了异地备份和跨AZ容灾。
接下来将这些能力展开来分享一下。
首先是性能上的,Hologres V2.2版本提升了查询优化器和查询引擎的能力, 1.1版本使用96CU在TBC-H的总查询耗时为223秒,在2.2版本中,测试结果为111秒,性能提升将近100%。
在新的版本中,增强了Runtime Filter能力。在原有的localRuntime Filter上,支持了global Runtime Filter,在join场景上能够有效的减少数据扫描量,同时减少join的计算量和数据的网络传输量,有效提升join的查询效率约30%。同时,Query engine支持了每个worker内的数据先合并再进行worker间分发,显著降低网络开销。在带有Shuffle的场景上,查询性能提升8%以上。
查询优化器也有提升,生成plan的速度提升40%以上。主要优化了查询优化器的内存分配机制和join算法。时间比较和过滤是常见的场景。在这些场景上,优化了常见的时间、计算的函数,例如DATE- PART函数,提升带有时间属性的字段,例如年份的这种查询效率。对于DATE和TIMESTAMP类型的字段比较性能有明显的提升。
新版本中新增了路径分析函数,路径分析主要用于分析用户在使用产品的时候,路径的分布情况,会将用户每次会话的访问顺序进行记录,通常以桑基图的形式呈现。
如下图,它直观的帮助用户发现在每一步关键节点前后行为的流入流出情况。例如,访问某个电商产品首页的用户后,有多大比例的用户进行了搜索,有多大比例的用户访问了分页,有多大比例的用户直接访问商品详情。传统模式下需要写拖从、嵌套、子查询才能达到这样的效果。现在使用Hologres仅需要这样一个函数,就可以快速实现路径分析。
在行为分析、用户分析上,我们提供了多种丰富的函数:包括漏斗函数,用来分析用户在每一步的这种转化的情况;留存函数用来分析用户每天的这种流程情况;最后路径分析函数,作为一个整体,覆盖了主要的运营分析的场景。
在画像场景下,我们支持了Roaring Bitmap, 可以用于高效的计算各类的PV、UV场景。在超高基数的场景下,可以达到毫秒级的响应。原来在做标签计算时,需要用join模式互相进行嵌套的计算,不仅消耗资源,而且查询效率有限。使用Roaring Bitmap后,就可转化成以下的这种查询,简单易懂,多快好省。
切换成Roaring Bitmap后,所有查询都能实现毫秒级的响应。而且消耗的资源也有明显的减少。
这张图是常见的OLAP产品在行为分析、画像分析上的能力对比。可以看到,相比clickhouse 、Doris、progress在漏斗分析、留存分析、路径分析、属性标签分析和行为分析上都有便捷的函数和完整的方法去支持和支撑,能够高效的辨别的实现行为分析、画像分析,助力业务快速获得商业洞察。
serverless Computing是这次重点需要说明的新能力。一般在MPP架构上执行大任务,通常会因为大任务之间的资源增强,导致大任务的不稳定或者OM等问题。serverless Computing是Hologres在写这种问题上的给大家的一份答卷。Hologres支持将都收到的SQL使用共享的service集群执行。每个大任务单独分配资源,按照大任务占用的计算资源和执行时长收费,无需为大任务预留大量的计算资源,造成无任务时候的计算资源浪费。各个SQL之间使用独立的资源执行,互相之间资源隔离,不会互相资源争抢,运行更加稳定可靠。这些执行不会占用现有实例的资源,不会影响现有实例的查询。
这是一个常见的使用场景,业务每天需要在0点到4点之间执行大量的写入任务。在使用serverless Computing之前,就需要为了能够完成这样大量的写入任务,准备大量预留的计算资源,在白天计算资源闲置造成浪费。
使用serverless Computing之后,0点到4点这种写入任务,可以使用serverless Computing资源去执行。业务仅需为稳定的查询和导入的流量预留资源即可,不仅大大提升了大任务、大SQL、大写入的隔离能力,提升导入任务的稳定性,无需预留大量的资源,达到了降本增效的目的。
这是一个用户真实的案例。在12月之前,未使用serverless Computing,在运行CPU时都会出现峰值,且出现剧烈的抖动,可以看到这些峰值都非常的明显。
在使用serverless Computing之后,整个CPU利用率逐渐平缓起来,把SQL都使用serverless Computing之后,OM的任务也继续的减少。实例的CPU明显下降,综合水位预计可以下降50%以上,总成本节约约30%。
在数据湖能力上,新版本大幅提升,包括支持使用Hologres原生的向量执行引擎,直读OSS上的ORC、PARQUET数据文件,性能提升五倍以上。支持使用内置的高速磁盘和内存,实现多级缓存,支持为此下推、过滤,有效的减少了数据的扫描量,提升性能。
在表格式上,除了之前支持的delta、 link之外,还新增了PAIMON格式的支持,更好的拥抱开源生态。
2.运维相关的能力
接下来介绍运维相关的能力。
作为DBA的同学,经常会有一些疑问:近期业务新增了哪些业务?新增了哪些查询?如何快速定位?哪些业务影响了整个集群?Hologres已经提供了慢Query日志用于分析和排查慢Query,但是想进一步找到某个时间业务上了哪些新的query,哪些特征的query影响了整个集群是比较复杂的,需要多重的比较和写一些live的查询才能定位到。在新版本中新增了SQL指纹的能力。SQL指纹是Hologres提供的一种自动的Query聚类分析能力,在2.2版本中存放在慢Query日志的系统表中。新增的指纹列以展示SQL指纹对于select、insert delete、update类型的query系统会计算一个MDS的哈希值,作为该Query的SQL指纹,帮助业务快速识别资源占用的Query以及异常的慢Query。根据这些Query指纹就可以快速定位,业务今年上了哪些的新的Query?以及到底是哪些特征query?哪些业务发过来的特征query影响了整个集群的稳定性和使用?
其次,DBA常见的第二个痛点是分析查询的信息非常分散、无法快速定位问题。对于一些传统的因表锁或行锁等导致Query的失败,或者被cancel过程。需要首先选取慢Query日志,然后再去找跟他相关的时间点的DDL,然后看相关的查询消耗等,需要跳2到3张表。现在新增了query洞察,支持通过query ID就可以快速的获取当前query的执行相关信息,比如说query进程的资源消耗,query所涉及的表的元数据,以及query对应的执行计划,同时可以根据query洞察快速判断query是否产生了DDL冲突或者表锁的情况,以辅助业务进一步快速排查问题。
DBA常见的第三个痛点是对于示例的健康情况难以判断。所以新增了SQL诊断和表统计信息,用于快速完成治理。
SQL诊断可以通过不同维度的Query趋势明细分析,可以辅助快速的了解实例的使用情况,并做出对应的优化,以达到更好的效果。可以统计实力一段时间内的Query数量,比如它的成功率、常见失败query的报错信息。根据这些报错信息的error message, 就可快速的定位进行quarry的诊断和治理。
表诊断可以实现对于当前实例的Table Group、表、索引进行快速的诊断,帮助业务进行实例治理,从而提升实例的稳定性、性能等,比如它可以帮助你快速发现表数量超过一万的Table Group, 对于这种Table Group需要去治理;对于一些无用的表等要进行清理,或者拆分Table Group。对于子分区超过一万的分区表,建议使用冷热分层的策略,以节省最终的存储成本。
新版本中新增了15个以上的Metrics 指标,提供不同执行引擎的QPS,
比如HQE、 hollow原生引擎、或face QE等,这些引擎的QPS、RPS latencty等客观性的指标,以及对于binlog 、serverless等功能的运行状况的观测指标,以方便及时了解任务的负载、实例的负载。同时也提供locks、analyze等健康度的指标,帮助快速的观测实例的运行状况,及时处理异常。
针对常见的Metrics,推荐设置的报警:
首先是基础类的,对于实例的CPU以及每个worker的CPU和memory都推荐设置相关的一些报警规则,比如连续十分钟占用率超过80%等。对于连接数,推荐设置连接数使用率的告警,比如连接数使用率最高的FE的连接数使用率超过80%就应该产生报警,对于超高时(达到100%或者90%)就可以选择杀连接。以及在本实例运行的最长query的时常,可以对它设置一些告警,比如平时的任务只会跑1个小时,突然今天发现有一条音色的任务还有2个小时,可能就是异常的,触发报警之后去活跃的query里找到对应的query,看看是否有异常存在。如果已经堵塞了实例,可以主动杀query,然后对于失败的query的QES个数也推荐设置报警,连续五分钟超过两个、五个时就应该产生报警。对于框架类型,比如说FE replay延迟、主从同步延迟,这只在只读从实例存在,推荐设置中间的延时告警。对于auto analyze,推荐观测它的值,也可以设计一些报警,比如每个DB中超过十张表没有auto analyze的数据,我们会缺失一些统计信息,可以手动的去补一些auto analyze,收集统计信息,以便查询优化器可以生成一个比较适优的query plan。对于使用serverless Computing的用户,推荐设置对于正在运行的查询中最长的报警,以便可以实际的掌控serverless资源的使用和占用的情况。对于使用binlog,推荐对于walsender的使用数、使用率进行报警设置, 以占比过高后,影响正常的binlog使用。
新版本支持了跨AZ的容灾和异地备份的两类功能。对于跨AZ的容灾,支持在两个实例间创建数据同步的关系,在灾难发生时进行analyze point的指向切换,尽可能的保证业务的连续性。但这种模式需要更多的计算资源同步数据。对于延迟没有那么敏感的场景,可以考虑使用异地备份。在设置规则以及原有的实例创建完备份的快照之后,备份快照会再复制一份到设置的其他的region。比如正常的实例在杭州,然后在杭州创建了一份快照之后,可以把快照再复制一份到上海region,在灾难发生的时候,就可以在上海region根据最新的snapshot恢复出全新的实例,继续恢复业务,达到容灾效果。
以上是本次分享的全部内容。