ORC 格式扫描每个查询中的所有表答案

【问题标题】：ORC Format scan all table in each queryORC 格式扫描每个查询中的所有表
【发布时间】：2018-09-02 07:32:25
【问题描述】：

我在雅典娜创建了我的第一个兽人桌。

CREATE EXTERNAL TABLE `orc_test`(
 `hexid` string,
 `version` int,
 `ts` int,
 `campaignid` int,
 `sourceuid` string,
 `publisherid` string,
 `adslot` string,
 `share` double,
 `earn` double,
 `spent` double,
 `rebate` double,
 `payout` double,
 `cost` double,
 `ip` string,
 `useragent` string,
 `referer` string,
 `param1` string,
 `param2` string,
 `param3` string,
 `param4` string,
 `param5` string,
 `param6` string,
 `appid` string,
 `bundleid` string,
 `deviceid` string,
 `uuid` string,
 `callbackurl` string)
PARTITIONED BY (
 `year` string,
 `month` string,
 `day` string,
 `hour` string,
 `minute` string) 
STORED AS orc
LOCATION
 ‘s3://someplace/orc_2’
TBLPROPERTIES (‘orc.compress’=‘SNAPPY’)

当我搜索特定数据（例如 hexid）时。该查询扫描整个表。作为一个柱状表，不会只搜索hexId列，不扫描整个表吗？

我觉得我错过了什么。

谢谢！

pd：对不起我的英语！

【问题讨论】：

标签： performance amazon-athena snappy orc

【解决方案1】：

我相信只有在 WHERE 子句中使用分区列时才会减少扫描的数据，以便 Athena 可以识别要扫描的分区子集。在您的表定义中，hexid 不是分区字段，因此 Athena 必须扫描整个数据集以识别行。

有关更多信息，请参阅 Athena 文档中的 Partitioning Data。

【讨论】：

感谢@James 的回答。那么，在这些情况下，ORC 格式（列）和 JSON 格式有什么区别？因为您也可以在 json 表中创建分区。如果扫描所有表格，列格式有什么好处？
好问题，@justMiLa，我自己最终使用了 JSON，因为转换的努力似乎没有意义。文档在这一点上没有帮助。我的猜测是柱状格式可以帮助 Athena 更快地响应，即使 IO 费用相同或几乎相同。
另见Top 10 Performance Tuning Tips for Amazon Athena - 5. Optimize columnar data store generation。它表明列格式可以通过跳过块统计允许的块来减少 IO。
再次感谢@James。昨天发生了一件奇怪的事情。我用 Parquet 格式做了同样的测试，它没有扫描所有的表。当我搜索任何列时，它只扫描这些列（没有分区）。所以，问题出在 ORC 格式上，但我不知道在哪里......

【解决方案2】：

请看一下这个帖子：https://forums.aws.amazon.com/message.jspa?messageID=841338#841338 似乎列式读取可用性取决于 ORC 条带大小。在 Presto 中默认为 8MB（而 Athena 使用 Presto），您的 ORC 文件必须包含大于 8MB 的条带。低于该限制，将读取整个文件。

AWS Athena 对 Parquet 文件没有这个问题。但是，请注意复杂的 parquet 数据类型：

"当您查询具有复杂数据类型（数组、映射、结构）的列，并且正在使用 Parquet 存储数据时，Athena 当前会读取整行数据，而不是像预期的那样选择性地仅读取指定的列. 这是一个已知问题。” （所有限制：https://docs.aws.amazon.com/athena/latest/ug/other-notable-limitations.html）

【讨论】：