华为云实时数据湖查询优化

—2023— 华为云实时数据湖查询优化 演讲人：孟涛—华为—高级工程师 华为云数据湖介绍 Hudi查询能力介绍 华为云基于hudi的性能优化 未来规划 华为云数据湖介绍 数据湖基础架构 CDM CDL Hudi 贴源层汇总层集市层 批处理 SparkSQL 流式计算 FlinkSQL 交互式分析 HetuEngine 批处理 Spark DGC 数据源 postgr esql mysql oracle 数据入湖： 历史存量数据通过CDM一次性搬迁。 新增数据通过CDL实时搬迁。 数据存储： 选用hudi作为数据湖的基座，支持hdfs/ 对象存储obs， 数据加工： 批量加工:Spark、SparkSQL两种方式。 流式加工:FlinkSQL增量拉取hudi表数据。 交互式分析：hetu引擎承担数据湖的查 询出口。 hdfs obs Hudi查询能力介绍 Hudi介绍 流式挖掘，增量查询 高效的更新，删除能力，可插拔索引 事务,MVCC，并发控制，schemaevolution， timetravel 丰富的表级别服务：自动小文件合并，数据布 局优化clustering,compacion,clean 丰富的生态集成，支持flink/spark写入 Presto/hive/spark/flink等查询 Clustering hudi早在0.7版本就已经提供了clustering优化数据布局，0.10版本随着z-order/hilbert高阶聚类算法的加入，hudi的数据布局优化日趋强大。hudi当前提供以下三种不同的聚类方式，针对不同的点查场景，要根据具体的过滤条件来选择不同的策略 数据布局优化配合FileSkipping才能更好的发挥效果。当我们完成数据布局后，对每个文件的相关列收集统计信息，下图给个简单的示例，数据经过排序后写入表中生成三个文件，指定点查wherea<10下图可以清楚的看出a<10的结果集只存在于parquet1文件中，parquet2/parquet3中a的最小值都比10大，显然不可能存在结果集，所以直接裁剪掉parquet2和parquet3即可 File minValue_a maxValue_a parquet1 0 999 parquet2 1000 2000 parquet3 2001 3000 空间曲线z-order/hilbert生成。 普通sort无法满足多列排序需求，空间曲线类似于 对每列做加权平均排序，对队列排序效果更好 tips: 实际环境中hilbert的聚合性比z-order更好 Z-orderhilbert MDT metatable：hudi的元数据信息表，是一个自管理的hudimor表，位于hudi表的.hoodie目录对用户无感知。同样的hudi很早就开始支持metaTable，经过不断的迭代，到0.12版本metatable已经成熟，当前metaTable表的能力如下： column_stats 当前hudi支持对指定列收集包括min-maxvalue，nullcount，totalcount在内的统计信息；并且hudi保证这些信息收集是原子性。利用这些统计信息结合查询引擎可以 很好的完成fileSkipping大幅度减少IO。 bloomfilter bloomfilter是hudi提供的另一种能力，当前只支持对主键构建bloomfilter。bloom的判断不存在就一定不存在的特性，可以很方便我们进行fileSkipping，我们可以将查询 条件直接作用到每个文件的bloomfilter上，进而过滤点无效的文件。注意bloom只适合等值过滤条件例如wherea=10，对于a>10这种就无能为力的。 高性能fileList 在查询超大规模数据集是，fileList是不可避免的操作；在hdfs上该操作耗时还可以接受，一旦涉及到对象存储大规模的fileList效率极其低下，hudi引入metatable将文件信息直接保存在下来，从而避免了大规模filelist, 华为云基于hudi的性能优化 Hudi索引优化 索引是为了加快数据检索速度而创建的一种存储结构，是一种空间换时间的设计思想，作用可以理解为书的目录，通过目录我们可以快速检索到需要的内容。常见的索引类型有:数据索引(如对数据做分区，sort，z-order)，二级索引(lucene、bitmap)，前缀索引等等，每种所有都有各自的优缺点。引入这些索引可以极大的提升查询引擎的查询能力 数据索引Min-max Lucene索引 Bitmap索引 各种索引对比和使用建议 基于MDT的Min-max索引 MDT hetu Col_stat_index Spark 查询 spark 入库Files&partitions flink Datafiles timeline obs Min-max索引要想效果好，数据入库后需要采用clustering，按照查询条件做排序异步重组数据。读取时开启mdt利用hfile高效的点查能力，快速加载索引数据完成数据文件的裁剪 基于MDT的Min-max索引集成 select*fromtablewhereid>9 lucene Lucene是apache开源的一款搜索工具，具有极其高效的检索效率。solr和es均基于其进行开发。利用lucene强大 的倒排索引能力，可以赋予hudi更高效的多维查询，文本检索能力。 正向索引，给每个文档编号，作为其唯一标识 文档id 内容 1 西安大唐不夜城 2 西安回民街 倒排索引，对字段内容做分词，按分词和id构建索引 表某一个列值1,9,4,4,3,1,1,3,8,9 分词（列值，string类型会分词） 文档id（行号） 1 1,6,7 9 2,10 4 3,4 3 5,8 8 9 分词 文档id 西安 1,2 大唐不夜城 1 回民街 2 lucene 索引的创建和使用 //createindex createindexidx_nameonmytableusinglucene(c1)options(block_size=1024) //索引执行 Callrun_build(table=>‘mytable,show_involved_partition=>true’) 构建lucene索引要注意的点 1）选择文件级别构建，我们选择行号作为docID，全表级别生成行号不现实，而且表里面数据会持续写入之前行号讲不可以。 2）异步构建方式，防止阻塞入库流程。天级别大任务可以选择同步构建 关于索引大小 Lucene针对string类型，做分词后产生的索引文件很大，甚至比数据文件都大，18300行-->600M 数值类型产生的索引文件相对较小18300-->6.6M，可以直接放到 内存，加快索引查询 Lucene会生成很多文件，这对hdfsnamenode是有压力的 bitmap Bitmap索引，其索引采用bit数组进行存储和计算操作，位置编码的每一位表示键 值对应的数据行的有无，查询时直接用索引位图做运算，即可skipping掉大量数据 id name age 1 zs 21 2 ls 22 3 ww 33 4 zl 34 5 ll 22 age 0 1 2 3 4 21 1 0 0 0 0 22 0 1 0 0 1 33 0 0 1 0 0 34 0 0 0 1 0 bitmap1 bitmap2 bitmap3bitmap4 将age所有值存成有序数组，根据过滤条件选取对应bitmap进行交并运算，返回的结构即为具体某些行包 含目标数据，如果返回结果位0直接可以skipping掉整个文件，否则进行做page级别skipping。 bitmap 索引的创建和使用 //createindex createindexidx_nameonmytableusinglucene(c1)options(block_size=1024) //索引执行 Callrun_build(table=>‘mytable,show_involved_partition=>true’) 构建lucene索引要注意的点 1）选择文件级别构建， 2）异步构建方式，防止阻塞入库流程。 3)等值bitmap占用空间较大，范围查询时非常不友好 采用Bit-SliceRangeEncodedBitmap(featurebase.com/blog/range-encoded-bitmaps)方式构建bitmap，节省存储空间 4)Bitmap入参需要整数，对于string，double，float等类型可以现在字典然后再按字典值生成bitmap 二级索引构建 1)引入新的timeline类型：index（社区已有相应pr，待合入） Index.request索引计划生成，可按实际用户指定的索引类型生 成 Index.inflight索引计划执行 Index.commit索引数据提交 整个索引构建流程按先调度后执行的异步模式执行 2）借助index服务，负责索引计划的执行，解放入库程序 T1T2T3T4 Committimeline time insertinsertindexinsert C2|done C3-index|request Pushindexplan C3-index|inflightt C3-index|inflight Startexecute C3-index|done Finishandcommit Index server 二级索引集成 Lucene/bitmap 索引类型支持: coordinator split1 split2 split3 work1 work2 work3 Indexreader skipping skipping scan File3 File2 File1 Indexserver 支持Lucene/bitmap。 Bloomfilter当前社区是直接放到mdt里面的并且实际文件较大，加载耗时较长。因此直接使用了parquet自身的能力替代 索引应用： 索引在work端生效，由于lucence/bitmap索引构建出来的索引文件很大，无法放到coordinator里面直接skipping扫描文件。 索引获取： 通过与indexserver交互，获取索引信息的位置， 由work端获取相应的索引文件，做裁剪。 实际效果： 采用我们采用和ck一样的SSB数据集进行测试，数据规模1.5T，120亿条数据。性能提升3x到11x 各种索引对比和使用建议 索引 简介 优点 缺点 sort/z-order（min-max） 入库时指定常用的过滤字段排序。查询通过文件的min-max值过滤不需要的文件 数据本身即索引，无需额外空间。支持范围查询，等值查询；同时对聚合操作可以减少shuffle开销 数据很难保证全局有序，随着数据的写入，表的有序性逐渐消失。排序比较耗资源。 Bitmap 其索引使用bit数组进行存储。位置编码的每一位标识该行是否存在，查询时直接用位图快速过滤所需数据 占用空间较小，创建和使用较快，支持范围查询，等值查询 对索引列有基数要求，太高没优势，太低空间效率和性能大幅度下降 bloomfilter bloomfilter可以快速判断一个值是否在目标集合中，利用这个特性，可以很方便的确定文件是否包含目标数据，从而实现过滤 等值查询效率较高，实现简单 假阳性问题，只支持等值查询，不适合低基数据 Lucene 利用lucene引擎强大的倒排索引和列式存储能力，实现多维查询，文本检索 比较成熟，常见的es和solr都以lucene为基础。支持文本检索，前缀查询，正则匹配 海量数据下，存储空间过大，并且索引文件数过多 统计信息优化 Hudime