apache分析软件哪个好：Apache Hudi 0.11.0
apache分析软件哪个好：Apache Hudi 0.11.0在Hudi中我们默认开启了基于bloom filter的索引。这些bloom filter是存储在数据文件的footer中。作为一个单独的存在，它可以被用到索引的流程过程中。如果没有index的情况下，对于所有的更新以及删除的记录，我们需要和所有的文件进行merge，这样开销会非常大。如果使用了索引，读写开销会极大地降低，可以提高查询这个位置的效率。1. 为什么要引入多级索引（Multi-Modal Index）在介绍多级索引之前，我们先看看索引是什么？索引是数据库系统中常用的查询加速技术。通过构建索引就可以利用生成的元数据metadata快速定位查询所需数据的位置，这样可以减少甚至避免从文件系统中扫描或者读取不必要的数据，减少IO的开销，大大提升查询效率。我们可以类比图书馆以及教科书中的索引，这些都是通过利用提前生成好的metadata来快速找到想要查找的信息。其实在Apache Hud
导读：Apache 社区在2022年4月30日发布了Apache Hudi 0.11.0版本，其中包括一系列的新功能和提升优化。本次分享主要是针对Apache Hudi 0.11.0新版本新特性进行深度解读，主要介绍4个方面的内容：
- 多级索引
- Spark SQL 新功能
- Flink 集成改进
- 其他功能和提升
01
多级索引
首先和大家分享下多级索引，接下来我们将从三个方面介绍它。第一是为什么我们引入多级索引multi model index，第二多级索引的设计以及实践，最后将介绍如何利用多级索引，极大提升读写性能。
1. 为什么要引入多级索引（Multi-Modal Index）
在介绍多级索引之前，我们先看看索引是什么？索引是数据库系统中常用的查询加速技术。通过构建索引就可以利用生成的元数据metadata快速定位查询所需数据的位置，这样可以减少甚至避免从文件系统中扫描或者读取不必要的数据，减少IO的开销，大大提升查询效率。我们可以类比图书馆以及教科书中的索引，这些都是通过利用提前生成好的metadata来快速找到想要查找的信息。
其实在Apache Hudi的湖仓一体的架构中已经提供了特有的索引支持，这里我们可以看一个例子。其中我们用的一种索引可以快速定位到我们所需要更新或者删除的记录所在的文件组。如下图所示：
如果没有index的情况下，对于所有的更新以及删除的记录，我们需要和所有的文件进行merge，这样开销会非常大。如果使用了索引，读写开销会极大地降低，可以提高查询这个位置的效率。
在Hudi中我们默认开启了基于bloom filter的索引。这些bloom filter是存储在数据文件的footer中。作为一个单独的存在，它可以被用到索引的流程过程中。
那我们为什么还要在Hudi中引用多级索引？其实索引的主要目的就是刚刚提到的提升数据查询的速度，那么就需要存储metadata。而对于TB、EB级别表中的metadata，它们的量级会很大。通常的做法是把它们存储于单独的数据块block或者是数据文件中。而我们在实测的过程中，遇到了读写瓶颈。同时，在维护metadata的过程中，它需要实时的和数据表进行同步。这样的管理十分复杂，因为要保证transaction，如果我们要在Hudi中引用新的索引开发周期会很长。
2. 多级索引的设计与实现
为了解决上述的问题，我们在湖仓一体的存储架构中引入了多级索引，是首次在类似的架构中引入统一平台、多元化、高性能的索引。我们的目标是支持所有计算及查询引擎来提升读写性能，甚至未来如果出现新的引擎，也是可以进行兼容的。
接下来我们介绍一些在多级索引设计中所需要的需求。
- 第一是我们需要保证可拓展的元数据（scalable metadata）。我们希望元数据是Serverless的，是不需要任何的计算或者是内存中需要支持的，可以独立存在于数仓一体和数据湖中。同时希望它能独立于计算及查询引擎，它是可拓展的，能高性能地支持不同索引类型。
- 第二是我们希望多级索引中的元数据和数据表保持实时同步，保证每次的更新都是事务性的。
- 第三是保证查询的速度。保证对于多级索引的查询是低延迟的，主要的查询类型包括point range and prefix lookups等。
我们分别来看一下是如何实现的。
首先是可拓展的元数据，我们采用了和已有数据库类似的设计，那就是在内部构建一个元数据表meta table。对于Hudi table来说，我们利用的是Hudi的mor表来存储这些数据。mor表的优势是可以很快地进行数据的更新与删除。同时，Hudi表也是Serverless的，它不会依赖任何计算及内存资源。在这个表里我们针对不同的索引是建立独立的分区的。在这样的情况下，不同的index可以完成独立的管理以及自动化的管理。我们在使用mor表的另一个优点是可以支持任意的索引大小。从mb级别到gb级别再到tb级别。针对独立的分支，我们可以引入新的作用类型，就只需要建立新的分区。在构建可拓展的元数据的时候，需要索引的一个初始化。我们提高了两种方式的初始化。一种是同步，同步是在写入表的过程中，在最后commit之前会做一个index的步骤。而第二种方式是异步。异步创建索引是hudi首次引入的，保证了concurrent writer 不受影响。下面是异步创建索引的流程图：
- 第二点的设计原则是保证对metadata table的更新是事务性的，来保证metadata table结构里面的数据要和数据表实时同步。我们设计了一套叫multi table多表的transaction。同时在这个metadata table 里，有自我管理的表服务，包括compaction cleaning。它们会保证定时操作，以保证这个metadata table 的读性能会很好。
- 第三点是对于metadata的快速查询。我们使用了HFile作为MDT的数据格式。原因是列格式Parquet或基于行的Avro不适合 pointed lookup；HFile格式中的index使得 pointed lookup非常高效，只需要读取相关数据块。我们针对HFile做了一个测试，得出在千万（10M） 条目中查询 N 条目，HFile 相比于 Parquet、Avro 有 10-100倍的提升。如下图：
3. 利用多级索引极大提升读写性能
接下来介绍多级索引所带来的主要的读写性能提升。
- 首先是File Listing
在云存储中我们发现大部分情况下，如果对于大型表的上千分区以及百万级的数据文件做listing，会造成读写瓶颈。这主要是因为云存储的设计所导致的。如果我们利用metadata table中的Files来做分区。这个分区里提供了这个数据表里所有的file。相比于云软件系统有2-20倍的提升。如下图：
- 另一个比较重要的特性是Data Skipping
Data Skipping 技术是利用列统计数据来对所需要的这个数据文件做file pruning （文件裁剪），列统计数据常见的列统计数据包括取最大值、最小值、数量、大小等。Data Skipping 的作用就是通过这些统计数据来排除掉不需要读的文件，这样可以极大的提高查询速度。我们在这个multi model index 的metadata 中构建了column_stats分区，这个分区里的每条记录包含了这个Hudi表里所对应文件的列统计数据。每个Record key是由列名称、分区名称和文件名称组成。通过这种排列格式，可以快速定位所需的column stats。查询复杂度是基于查询列所需要的列的数量，通常这个数量是5到10个。对于大宽表来说，这样可以极大地提升这个效果。在实际测试中，云上Hudi大宽表的“定向”查询速度有10x-30x的提升。大幅减少了对无关数据文件的扫描和读取，提高了I/O效率。如下图：
