当前,数据量呈快速增长态势,给诸如 Presto 等查询引擎带来了挑战。
Presto 作为一种流行的交互式查询引擎,具有可扩展、高性能并可与 Hadoop 进行平滑集成的特性。随着数据量的增长,Presto 需要读取更大的数据块并将其加载到内存中,继而导致IO、内存占用增大以及 GC 时间变长等。
Apache Parquet 是一种可用于高效存储和检索数据的开源列式文件格式,提供高效的数据压缩和编码方案,性能更优,能批量处理复杂的数据。
我们先前已经采取了一些措施来加快 Presto 对 Parquet 数据的读取速度,但需要读取的数据量依旧很大。从 Java 版本的 Parquet(parquet-mr 1.11.0) 开始,Parquet 添加了一个名为 Page Index 的特性,通过在列块(column chunk)中过滤不必要的 Parquet 页(page)来加快查询速度。
本文就该特性、移植到 Presto 的状态以及基准测试结果进行了介绍。
Parquet 文件元数据包含有关文件中数据的最小/最大值的统计信息。对于一个给定 filter 的查询而言,统计信息的最小/最大值可以用作 filter 要查找的值的范围。如果要查找的值不在范围内,就可以跳过读取该数据块。这样一来提高了 IO、内存和 CPU等资源的利用率,从而加快了查询速度。
下述示例展示了如何将 filter 应用于包含统计信息的表,‘x > 100’的 filter 会查找(100, ∞) 范围内的值。表中的统计信息显示只有第二列(最小值为 1 和最大值为 209) 的数值范围 [1, 209],与 filter 的过滤范围重叠。因此,我们可以跳过读取剩余 3 列,从而将数据读取的时间减少3/4 。
Parquet 包含列块和页的统计信息。列块的统计信息显示出该列块中数据的取值范围,而页统计信息显示的是页数据,粒度更细、更有效。下述示例展示了页统计信息与列统计信息相比,如何能更好地降低数据读取量。
在第一个示例中,有一个查询中包含了“x = 2000”的filter条件。为便于演示,我们仅在一个列块中显示三个页。图表中的三个页的统计信息构成了三个范围:[-100, 60]、[50, 234]和[800, 1000] 。列块的统计信息构成 [-100, 1000] 的范围。由于我们正在查找的值为2000 ,因此页统计信息和列块统计信息都显示无需读取该列中的数据。在这种情况下,页统计信息和列块统计信息一样,都有效地减少了数据读取量。
在第二个示例中,列块和页中的数据和统计信息与第一个示例相同。唯一不同的是filter “x = 55”。在这种情况下,由于该值在列块统计范围 [-100, 1000] 内,因此对于读取的判断为“yes”。同样地,第一个页统计范围 [50, 234] 和第二个页统计范围 [-100, 60] 对于读取的判断都为“yes”,但对于最后一个页而言,由于超出了 [800, 1000 ]的范围,因此读取判断为“no”。
在第三个示例中,列块和页中的数据和统计信息依旧与第一个示例相同,但filter更改为'x = 700'。该值在列块统计范围 [-100, 1000]内,因此对于读取的判断为“yes”,但对于所有页统计信息而言,由于所有的范围都不包含要查找的值“700”,因此读取的判断结果为“No”, 跳过整列数据,不予读取。
在所有上述示例中,我们在一个列块中只显示3个页,但实际上一个列块中通常有几十甚至几百个页。因此,在现实操作中能节省更多的成本。如果列数据是经过排序的,那么误报的可能性就会降低,从而使得页统计效果更好。
在1.11.0 版本之前,页统计信息都放在页头(page header)中。问题是要获取页统计信息必须读取每一个页。即便之后判定无需读取该页,但该页已经被读取。为了解决该问题,parquet-mr 1.11.0 将列块的所有页统计信息放在同一位置,方便reader可以一次性读取并判定应该读取哪个页。由于 Presto 部分重写了 parquet-mr 代码,我们需要将 Parquet 1.11.0 中的修改移植到 Presto 代码库中。代码修改(PR-17284) 已于 2022 年 2 月合并到 Presto master 分支中,并将在 0.273 版本中发布。
我们基于需要频繁访问的生产数据表对 Parquet 列索引进行了基准测试。我们用原始生产环境的数据表的快照创建了一个测试表,它包含了若干数据分区,并且数据是经过排序的。之后,我们在测试环境中对表运行 Presto 查询。可以针对每个查询通过 Presto 会话属性设置打开和关闭 Page Index 功能,从而实现横向比较。
我们观察到,输入数据扫描存在巨大的优化空间。下图显示了 Parquet Page Index 启用(左)与禁用(右)时运行示例查询的统计信息。可以看出,他们在这一阶段生成了相同的数据,但是在未启用 Parquet 列索引(column index)时需要扫描 149.31MB/239K 行原始输入数据,而在启用 Parquet 列索引的情况下只需要扫描 63.31MB/75.4K 行原始输入数据。后者的输入读取量降低了57%。这是因为在使用 Parquet Page Index 时,operator 可以识别并跳过不符合过滤条件的页。
除了在原始输入读取量方面的提升外,我们还从测试中观察到内存使用量也有所降低。从下面的截图可以看出,在启用 Parquet Page Index(右)时,只需要使用 91.73MB的峰值内存,而在未启用 Parquet Page Index 时,则需要使用141.60 MB的峰值内存。实现此项提升在预期范围内:由于查询需要读取的原始输入数据更少,因此保存数据所需的内存也更小。
值得注意的是,我们测试用的Presto查询在经过排序的列上使用filter,例如:WHERE foo = bar,其中 foo 列是有序的,这也是 Parquet Page Index 降低读取量效果最显著的地方,如果不对 filter 依赖的列数据进行排序,则收益可能降低。
分享嘉宾:
Uber: Xinli Shang
Uber: Chen Liang
想要了解更多关于Alluxio的干货文章、热门活动、专家分享,可点击进入【Alluxio智库】: