AWS Athena + S3限制

Question

我目前正在将AWS S3 + Athena用于一个项目。 但是，使用1-2个月后，我发现了一些限制。 我不确定我是否会使用它，或者这确实是一个限制。 但是请不要问为什么在进行足够的研究之前我选择使用它。我认为有2分：

1. 这是项目所必需的
2. Athena S3和AWS的资源不是很集中，其功能不断变化。在实际使用Athena + S3一段时间之前，我很难找到其功能。

别着急，现在回到话题。 > _ << / p>

当前，我面临一个问题。随着数据量的增加，数据扫描的大小和查询变得越来越大，越来越长（有时甚至发生异常，例如当我执行查询时，打开的文件太多）。但是，似乎只有分区但没有针对AWS S3 + Athena的索引。因此，问题来了。

问题1：
我可以在AWS S3 + Athena上做类似索引的事情吗？

问题2：
如果使用分区，则似乎只能指定一个组合键（S3文件夹中的一列或多列作为标签）。否则，数据大小将加倍。这是真的吗？

问题3：
即使我愿意增加数据大小，对于带有2个复合键的表也是不可能的。为了实现此目的，我必须具有2个Athena表和2个相同的数据集，但在S3中具有2种分区类型。这是真的吗？

问题4：
对于错误“打开的文件太多” ，经过一些研究，看来这是操作系统级别的问题，预定义的文件描述符数量有限。我目前的情况是，SQL在大多数情况下没有例外，但是在特定时期内，它很容易例外。我的理解是，亚马逊将拥有一台计算机集群（例如32台节点服务器），以服务一定数量的客户，包括我的公司和其他公司。每个服务器都有可用的有限数量的文件描述符，并且在所有客户之间共享。然后，在某些高峰时段（其他公司正在执行大量查询），可用的文件描述符数量将减少，这也解释了为什么我的具有相同数据集的SQL有时但并非总是例外。这是真的吗？

问题5：
由于缺乏索引功能，因此S3 + Athena不应执行复杂的SQL查询。这意味着，复杂的连接逻辑只能在加载到S3之前在转换层的某个位置完成。这是真的吗？

问题6：
该问题紧接前一个问题5。 让我用一个简单的例子来说明： 开发了一个报告系统来显示订单和交易。关系是订单执行后将生成交易。Order_ID是链接交易及其相关订单活动的关键。分区设置为日期。
现在，出现以下数据：

要求是：
1.对于第1天的报告，仅显示订单记录 O001下订单
2.对于第2天的报告，仅显示订单记录 O002-订单更改订单
3.对于第3天的报告，将显示所有记录，包括4个订单记录和1个交易记录。 4.对于第4天的报告，仅显示订单记录 O004-备注更改
对于第一天，第二天和第四天，很容易，因为我只显示同一天的数据。
但是，对于第3天，我需要显示所有数据，一些过去和将来（O001-备注更改）。
为了避免复杂的SQL，我只能在Transformation层上执行联接逻辑。
但是，在第3天进行转换时，如果聚会在第1天和第2天没有向我发送数据，则只能找到历史文件，因为您永远不知道需要回溯多少天，所以这是不好的。
即使我们在Athena进行搜索，因为Order_ID不在分区上，所以也需要全表扫描。
以上并不是最坏的情况，最坏的情况是在第3天进行转换时，第4天的 O001-备注更改是将来的数据，因此在第3天不应该知道。
有更好的方法吗？还是AWS S3 + Athena不适用于这种复杂情况（上述情况只是我当前情况的简化版本）？

我知道我的问题太多了很多。但是所有这些都是我真正想要澄清的，我找不到明确的答案。非常感谢您的帮助，非常感谢。

Answer 1

索引

否，Amazon Athena（及其所基于的Presto）不支持索引。这是因为Athena / Presto（甚至是Redshift）是为大数据而设计的，因此，即使大数据上的索引也是 Big Data ，因此维护大索引效率不高。

尽管传统数据库使用索引的速度更快，但这不适用于大数据系统。而是使用索引，压缩和列数据格式来提高性能。

分区

分区是分层的（例如Year -> Month -> Day）。分区的目的是“跳过”不需要读取的文件。因此，只有在WHERE子句使用分区层次结构时，它们才会提供好处。

例如，使用SELECT ... WHERE year=2018将使用分区，并跳过所有其他年份。

如果您的查询未在WHERE子句中放置这些分区字段之一，则所有目录和文件都需要扫描，因此没有任何好处。

您说“数据大小将加倍”，但事实并非如此。所有数据仅存储一次。分区不会修改数据大小。

打开的文件太多

如果这是Amazon Athena生成的错误，则应在AWS支持下提出。

复杂查询

Athena当然可以执行复杂的查询，但是它不是理想的平台。如果您经常执行复杂的SQL查询，请考虑使用Amazon Redshift。

问题6：表格/查询

我无法遵循您的要求。如果您正在寻求有关SQL的帮助，请创建一个单独的问题，以显示表中数据的示例以及所要输出的示例。

Answer 2

扩展John的正确答案以补充几点： 问题1：提高性能的一种方法是按固定的时间间隔对数据进行排序，而在使用Orc和Parquet等列数据格式时，由于跳过文件中的大多数条带/行组以提高性能，因此可以为您带来性能上的好处。

Q3：再次按一组列进行分区，然后按另一组对日期进行排序，这将为您在任一选择器集上的查询提供性能优势。 Q4：打开的文件太多：这是Athena所基于的presto配置。该值越大，存储要写入的内容所需的内存就越多，直到条带完成为止，因此它受到限制。雅典娜没有提供完全的隔离，因此您或运行具有多个小文件的任何其他用户的查询都可能导致这种情况。联系支持人员，我怀疑他们会有所帮助。共享基础架构的缺点之一：） Q5：复杂的说，如果您的意思是大型查询需要执行大量操作，那么理论上Athena应该能够处理。您可以在查询中排序的数据量有一定限制，具体取决于Amazon带来群集的节点数。

由于Amazon决定了集群大小，因此Athena中存在可扩展性限制，因此建议先执行ETL，然后使用Athena进行查询。尽管在Presto的较新版本中，此约束变得越来越不实用。 问题6：由于Presto使用ANSI-sql标准，因此不是我的专业知识，并且更适合SQL部分。您可以在https://prestodb.io/docs/current/functions.html处查看功能和运算符的列表。 如果Athena的可扩展性对您不利，则可以检查Qubole，EMR或Starburst中托管的预发行版。