Hive 计数查询中雅典娜（蜂巢/普雷斯托）拼花地板vs兽人

我正在雅典娜测试一个大数据集（1.5TB，5.5b记录），包括拼花地板和orc格式。我的第一个测试是一个简单的，计数查询-

SELECT COUNT(*) FROM events_orc
SELECT COUNT(*) FROM events_parquet

拼花地板文件需要一半时间才能作为orc文件运行此查询。但我注意到的一件事是，当对拼花地板文件进行计数时，它返回

0kb

作为扫描的字节，而对于orc，它返回

78gb

。这对于拼花地板是有意义的，因为计数在元中，不需要扫描字节。orc也有一个带有计数的元，但它似乎没有使用该元来确定这些文件的计数

---

为什么雅典娜不使用orc文件中的元数据来确定计数，这显然与拼花地板文件有关？

答案是，雅典娜读取拼花地板元数据，而不是orc。除此之外，雅典娜使用的Presto和/或ORC serde版本中没有其他原因

---

我还注意到雅典娜在使用ORC时读取了太多的数据，它没有跳过它应该跳过的列，等等。我认为雅典娜ORC serde很旧，没有你所期望的所有优化。雅典娜毕竟是基于一个非常古老的普雷斯托版本。

这取决于那些ORC文件是如何创建的。您能解释一下您是如何在数据中进行ETL的吗？表定义是什么

ORC拥有的索引很少：

索引ORC在每个文件中提供三级索引：

文件级别：

关于整个文件中每列中的值的统计信息

条带级别：

关于每列中每个值的统计信息 条纹

行级别：

关于每组10000行的每列中的值的统计信息 在条带中，文件和条带级别列统计信息位于 文件页脚，以便轻松访问，以确定是否剩余 该文件的任何部分都需要读取。行级索引包括这两种索引 每个行组的列统计信息和查找位置 到行组的开头

Athena和PrestoDb一样，Athena使用的查询引擎可以使用这些索引来加速查询

---

如果雅典娜不使用这些信息进行查询，我会非常惊讶。

在ORC的情况下，您的数据是否被压缩了？