数据库 频道

B 站基于 Iceberg 湖仓一体优化实践及智能化管理平台的助力

本文根据向阿鲲在【第十三届中国数据库技术大会(DTCC2022)】线上演讲内容整理而成。

讲师介绍

【嘉宾介绍】哔哩哔哩 OLAP 资深开发工程师,十多年软件行业从业经验,四年多大数据 OLAP 方向研发经验,先后在唯品会、B 站从事大数据 OLAP 方向的研发工作,目前主要负责B站OLAP平台,湖仓一体方向:Iceberg 内核研发、优化探索实践,智能化管理平台搭建、以及业务接入支持等相关工作。

本文摘要:本文整理自向阿鲲在DTCC2022大会上关于“B站基于Iceberg湖仓一体优化实践及智能化管理平台的助力”的主题演讲,主要介绍了Iceberg 湖仓一体项目在B站的落地实践,Iceberg 湖仓一体的内核优化,智能化管理平台的背景、意义与实践,以及未来展望。

分享大纲:

1、湖仓一体项目在 B 站 OLAP 平台的落地实践

2、基于 Iceberg 湖仓一体内核优化

3、智能化管理平台 Magnus

4、未来规划

以下为演讲正文:

湖仓一体项目在 B 站 OLAP 平台的落地实践

为什么引入湖仓一体?

第一部分先简单介绍一下B站湖仓一体项目的背景。下图是我们早期数据服务架构,借此来展开为什么会引入湖仓一体。

先介绍一下基础信息:在B站,大数据平台主要依托 Hadoop生态。我们看一下架构图的左侧,数据源经过 ETL 会把数据 load到不同的数据库引擎,像 ES、TiDB,ClickHouse、InfluxDB,以及HBase 等。然后通过一个统一的查询服务对接不同的数据库引擎,为不同的数据产品提供查询服务。这样一套架构会存在一些问题:

首先数据出仓繁琐,数据一致性很难保障,因为同一份数据可能存在不同的存储系统里面。二是数据处理复杂,需要定制化。此外,为了提高查询性能,需要为不同的存储引擎优化计算。

引入湖仓一体架构

针对以上痛点,B站引入了湖仓一体架构,并启动了湖仓一体项目。湖仓一体项目是在Hadoop生态上引入了Iceberg组件,通过在Iceberg组件上的一系列优化,在拥有数据湖灵活性的同时,打造了一套高性能的数仓的体验。

湖仓一体的数据流转图如上,左边是数据采集,目前B站的数据来源主要有 APP 埋点数据,MySQL业务数据,服务 log 日志等。通过公司内部统一的传输服务Lancer 进行数据分发,主要分两条链路:

一、通过Flink近实时地写 Iceberg 表,默认 5 分钟一个checkpoint。另外一条链路是天级或者小时级,落入到Iceberg表。Iceberg表无论在ODS、DWS、DWD的哪一层,都可以根据用户需求对外直接提供服务,目前最多的业务场景是使用 DWD层明细层数据直接对外提供服务。

数据导入后,会由智能化管理平台 Magnus,后台进行异步地数据组织优化。

数据分析侧:通过统一的计算引擎Trino作为查询的统一入口,同时也引入了 Alluxio作为缓存加速,以及保证查询的稳定性。

对性能有极致需求的场景,我们会将Iceberg表的数据出仓到ClickHouse,但是整体上用户可以直接基于Iceberg表进行OLAP查询分析。

湖仓一体的架构有不少优势,解决了此前数据服务架构的很多痛点。首先数据不用出仓,避免了数据重复存储。其次,大数据可以添加索引,支持毫秒级/秒级查询能力,满足基本取数场景。再者,从数据处理到取数过程大大缩短,数据处理也就更加高效了。同时,支持数据增量 update,支持事务,能对接更多业务场景。

目前湖仓一体项目在 B 站 OLAP 平台的落地场景主要有数据服务(取数服务)、ABTest 实验平台、BI 报表、标签人群圈选、日志检索等。如取数服务,主要对接公司的运营后台、数据产品(万华镜、观星台、Boss 看板等),以及OLAP多维分析场景。计算引擎Trino的单集群QPS峰值可以达到 300 QPS,数据产品万华镜目前的平均查询耗时大概在 200 毫秒。

基于 Iceberg 湖仓一体的内核优化

数据组织排序

Iceberg提供了文件级别元数据,像manifest 文件索引了所有的数据文件,并保存了数据文件的一些元信息,如数据文件路径、具体有哪些列,以及每个列的Min/Max值等。计算引擎可以利用Iceberg提供的文件级别元信息进行高效查询过滤。

假如不对数据进行任何优化,直接利用Iceberg提供的元数据:字段在文件内的Min/Max值。如左上图,存在 column: Id,它的Min/Max 值在所有文件内都是比较分散的,如果通过id = 100 做过滤,由于每个文件的跨度都比较大,都可能包含100这个数值,这样就没办法直接过滤任何文件了。

通过对Iceberg表进行数据组织排序,可以使得文件根据字段Id有很好的聚集性。如上图右边部分,通过排序之后,再用 Id =100进行查询,只需要读第一个文件就行,另外 3 个文件通过元数据的 Min/Max值就可以直接过滤掉,这种情况下不需要去扫描所有的文件了,可以大大提高查询性能。

上面举例的是一个线性排序的场景:基于一个或多个字段进行分区内线性全排序,典型应用场景包括:根据 up_id/avid 进行点查/范围查询。线性排序遵循最左匹配的原则,如果第一个字段是一个高基数字段,根据它排序之后,大概率第二个字段是无序的,根据第二个字段去做过滤,通常无法直接过滤掉任何数据文件。

由于线性排序的缺陷,我们内部实现了 Z-order 排序, Z-order 排序基本原理如下:多个待排序字段,分别按照大小进行二进制编码,每组字段根据编码后的值按 bit 位交错生成一个 Z-Value 值,使得生成的 Z-Value 沿着特定空间轨迹是有序的。

如上图的左边部分,Z-Value 沿着 Z字形曲线,对应取值分别是 0、1、2、3… ,是依次递增的。即沿着Z字形是有序的,这也是 Z-order排序名字的由来。

通过 Z-order 排序之后,把左边的图从 x 跟 y 分别从中间做切分,把数据切分成 4 个文件,得到右边图的效果。第一个文件 x 取值范围是 0- 3, y取值范围0- 3,其他几个文件类似。这种情况下,假如是用 x = 1 过滤,只需要去扫描左上角第一个文件和左下角的文件即可。如果用 y = 5 去过滤,只需要去扫描左下角跟右下角的数据文件就可以。这个场景,不管是用 x 还是 y 进行过滤,都有 50% 的过滤效果。当数据越多,生成的数据文件越多,经过 Z-order 排序后,单个字段过滤可以达到80%-90%的过滤效果。

在实际应用场景中,Z-order排序通常会基于 2~4 个字段进行分区内 Z-Order 空间排序。实际测下来,如果Z-order排序的字段过多,比如超过 4 个字段,过滤效果大打折扣。Z-order排序典型应用场景有根据 up_id、avid、time 等多个字段进行点查/范围查询。

二级索引支持

二级索引支持:Bloomfilter 索引,很小的存储开销,支持任意普通类型字段的点查。典型应用场景包括存在较多不同字段过滤场景,适用于相对较高基数的字段;Bitmap 索引:支持多个字段的组合查询,并且支持范围查询。典型应用场景包括单个字段或多个字段组合的点查或范围查询,字段基数不宜过高;BloomRF 索引:较小的存储开销,支持字段的点查和范围查询。典型应用场景包括高基数字段的点查和范围查询;Tokenbf、ngrambf 索引:针对 String 类型数据进行检索,典型应用场景为日志场景中的关键字检索。

经过数据组织排序,多种二级索引支持,在SSB 1000大宽表模式进行性能测试,整体来看,查询时间有 1- 10 倍查询性能提升。读文件数量性能提升更为明显,有2-400倍的读文件减少。

预计算、星型模型支持

星型模型优化是指在 join 场景下,根据维表过滤字段。通过关联维表,按照维表字段进行数据重新组织,查询时将维表谓词直接进行下推。

如上图右下角,事实表T1 left join 维表T2,根据某个 key 做关联,然后利用维表的某一个字段去做过滤。熟悉 Spark或 Trino 的同学应该都知道,这种情况下可以利用dynamic filter来提高过滤效率,表T2,通过f1 过滤出key2, key2 可能是一个值,也可能是有限的几个值。key2 即是T1表对应的 Key1 的取值,然后将 key1的取值下推到T1事实表中,理想情况下不需要做全表扫描。实际,我们在做SSB测试的时候也发现了一个问题,在这种情况下,可能查询出来key1是一个很大的范围,比如是 1 到3000。即便数据文件做了排序,由于范围太大,无法达到预想效果。

如何解决以上问题?上图右上角我们拓展了一种 SQL 语法,在事实表上通过关联维表加了一个维表字段。关联关系通过 left join 去关联维表,这里有限制条件unique,也可以支持primary key。 中间 SQL 语句:可以通过新增维表字段 F1作排序,对应的Iceberg元数据,索引每个文件的Min/Max 值。查询时,可以将F1 字段直接下推到事实表,如左图2,这种情况下只需要读一个文件就可以。

预计算主要解决聚合、多表关联场景下大量数据摄入、计算密集导致查询耗时的问题。目前我们实现了单表、多表的预计算,支持多种聚合函数:count、avg、max、min、sum、count_distinct、approx_count_distinct、percentile、top_n,支持查询部分 cube 文件、部分数据文件的场景,计算引擎在 Plan 阶段 通过 iceberg 元数据,判断查询是否能命中预计算,并进行相应的查询改写。

通过SSB 1000 1TB数据查询测试,整体性能有几倍到几十倍的性能提升。

第二部分,总结来看,内核优化核心是,只读取查询所需的数据,尽量减少无用数据的摄入。

智能化管理平台 Magnus

Magnus 背景:

Iceberg 是一个表格式,只提供了数据、元数据读、写 API 的实现,缺乏统一的数据、元数据操作、管理的服务。另外我们引入Iceberg 是为了替换Hive,用户习惯了使用 Hive 表,怎么减少用户使用 Iceberg 表的成本?使得使用起来跟普通的 Hive 表一样?

上图是我们数据平台用户建表的一个截图,截图部分是建 Iceberg 表比建普通的Hive表要多出来的一部分。需要用户去填数据分布信息,以及数据索引的配置信息。这对用户而言会产生一些问题。首先,可能用户都不确定常用查询Pattern是什么样的,其次,用户对如何定义数据分布,如何定义索引会有一定的学习和理解成本。还有一种情况,由于查询模式会随时间变化,需要用户频繁去改动,或者用户可能根本未感知到变化,这会导致随时间查询性能逐步下降。另外,上文我们提到的数据组织排序、索引,都只介绍了其定义,并未涉及这些操作是该由谁来触发,交由谁来管理,显然直接交给用户是不合理的。

为了解决上面提到的一些问题,我们开发了智能化管理平台 Magnus。其架构如下:

Magnus包括元数据管理、优化结果以及优化推荐三部分。同时Magnus 会去监听Spark 、Flink、 API ETL 等作业的 Commit Event,Commit Event的信息会包含具体是哪一个表、哪个快照操作,操作类型,这些信息都会通知到Magnus。Magnus通过查询HDFS的元数据了解表上有没有定义对应的组织排序、索引等信息,生成后续的操作,对应操作会先落库到数据库里面,待达到相应条件,触发具体的作业执行。

目前支持的作业类型包括Optimized Action(包括对数据进行小文件合并、组织排序等)、构建索引、生成cube、重写元数据(如果元数据都很小,源数据的读取开销不能忽略,这种情况下可以进行元数据重写、合并),此外,还支持快照过期、孤儿文件删除,索引和 cube 删除等,相应的 作业 会使用 Spark 进行执行。

上图为Magnus Iceberg元数据管理平台的界面,包括某个表的快照、manifest、分区统计信息等,以及表的列信息,包括关联列、索引、cube 信息等。此外,还有优化汇总的信息以及分析模块推荐等。

上图为Magnus智能化数据组织优化的流程,待执行任务,会先落地到DB,Magnus的调度任务会把它捞出来准备做提交,提交之前会有一些操作。首先看具体是哪个表,要做什么样的操作,是做组织排序还是建索引或其他操作,根据具体操作统计影响分区文件的大小,进行Spark 资源的分配。关于Resource Limit ,由于我们 Iceberg 表数据存在独立的Hadoop集群,如果白天有很多ETL任务对整个查询性能会有很大影响,所以通过Resource Limit 去限制白天跑的整体任务量,尽量不要去影响Ad Hoc查询。

如果资源达到或超过了设置的最大值,会把 Job 加入等待队列。针对数据可能存在不同的机房,通过分区数据进行探测,获取数据所在机房,并提交到指定的 Yarn Queue,实现多机房之间的调度,最终所有 spark job 通过 Yarn-Cluster模式进行调度运行。

上图为Magnus的智能查询分析与优化模式推荐,右边是Magnus,左边是计算引擎Trino,用户的 SQL 提交到 Trino引擎后,Trino会将能下推到存储的过滤条件解析出来。我们会将每个SQL的Query信息以及能够下推的过滤条件,都保存到 MySQL。

Magnus每天会去抽取历史的查询信息进行分析,分析包括:过滤的条件、条件字段所在表对应的最细粒度分区的基数,分区数据文件大小以及分区定义,也会去看对应的查询过滤字段出现的频率。如果是组合查询,会对组合频率进行统计,并区分是点查还是范围查询,以及查询耗时等统计信息,最终我们会把这些统计信息汇总重新落地到 MySQL。上图Magnus 右侧是一个推荐模块,推荐模块会分析汇总的信息,其中涉及一些规则:首先是默认边界的检测:比如检测是不是小表,如果表的单分区记录数只有百万级别或更少,大概率它只会生成一个文件,如果再去进行Z-order排序是没有意义的。核心点,会对不同的影响因子设置权重、提供一套统一的经验公式。影响因子包括:过滤字段的基数、过滤百分比、查询频次、查询耗时等,最终为每个表推荐出更合理的分区设置、组织排序字段、索引信息、其他Trait等信息。

如上图,是作出推荐结果的依据,统计信息包括每个字段的查询频次,是等值过滤还是范围查询,字段的的基数、不同字段组合查询的耗时等,据此可以推断推荐结果是否合理。

第三部分:总结来看,Magnus 的核心价值就是助力查询加速,降低用户使用湖仓的门槛。

未来规划

我们近期在湖沧一体方向上的规划主要有以下几个方面:一、预计算支持Star Tree,主要是解决维度字段基数过高导致性能衰退的问题。二、历史分析推荐支持预计算。三、历史分析推荐实现真正的智能化, Magnus 的定位是智能化的,但是目前离智能化还有一段距离,推荐结果出来之后,还是需要人工进行推荐结果的应用以及效果的验证对比,未来我们希望能做到不需要人工的参与。四、CDC 数据落地支持,后面会推进更多CDC业务场景的落地。

0
相关文章