AWS Athena + S3 限制
AWS Athena + S3 limitation
我目前正在为一个项目使用 AWS S3 + Athena。
但是，在使用 1-2 个月后，我发现它有一些局限性。
我不确定我是否不知道如何使用它或者它真的是一个限制。
但是请不要问我为什么在没有进行足够的研究之前选择使用它。我认为有2点：
- 项目需要
- Athena S3 和AWS 的资源不是很集中，其功能不断变化。在实际使用一段时间之前，我很难找到 Athena + S3 可以做什么或不能做什么。
跑题了，言归正传。 >_<
目前，我遇到了一个问题。随着数据量越来越大，数据扫描量和查询量越来越大，查询时间也越来越长（有时甚至会出现异常，比如我查询的时候too many open files） .但是AWS S3 + Athena好像只有分区没有索引。于是，问题就来了。
问题一：
我可以在 AWS S3 + Athena 上做类似索引的事情吗？
问题二：
如果我使用分区，似乎只能指定一个组合键（S3 文件夹中的一个或多个列作为标签）；否则，数据大小将加倍。这是真的吗？
问题三：
即使我愿意增加数据大小，也不可能有 2 个复合键的 table。我必须有 2 个 Athena tables 和 2 个相同的数据集，但在 S3 中有 2 种类型的分区才能实现这一点。这是真的吗？
问题四：
对于错误"too many open files"，经过一番研究，似乎是OS级别的问题，预定义的文件描述符数量有限。我现在的情况是 SQL 大部分时间没有异常，但是在某个时期，它很容易出现异常。我的理解是亚马逊会有一个计算机集群（比如32节点的服务器）来服务一定数量的客户，包括我公司和其他公司。每个服务器都有有限数量的可用文件描述符，并在所有客户之间共享。然后，在某些高峰期（其他公司正在执行大量查询），可用的文件描述符数量会下降，这也解释了为什么我的 SQL 具有相同的数据集有时会出现异常，但并非总是如此。这是真的吗？
问题 5:
由于缺少索引功能，S3 + Athena 不应该执行复杂的 SQL 查询。这意味着，复杂的连接逻辑只能在加载到 S3 之前在转换层的某个地方完成。这是真的吗？
问题 6:
这个问题接在上一个问题 5 之后。
让我用一个简单的例子来说明：
开发了一个报告系统来显示订单和交易。其关系是，在订单执行后，交易将 generated.The Order_ID 是 link 上涨交易及其相关订单活动的关键。分区设置为日期。
现在，以下数据来了：
要求是：
1. 第1天的报表，只显示订单记录O001-下单
2. 第2天的报表，只显示订单记录O002-Order Change Order
3. 第3天的报告显示所有记录，包括4条订单记录和1条交易记录
4. 第4天的报表，只显示订单记录O004-Remark Change
对于第 1、2 和 4 天，这很容易，因为我只显示当天的数据。
但是，对于第 3 天，我需要显示所有数据，一些是过去的，一些是未来的（O001-Remark Change）。
为了避免复杂SQL，我只能在Transformation层做join逻辑
但是第3天做改造的时候，如果对方没有把第1天和第2天的数据发给我，你只能找到历史文件，这样不好，你永远不知道要往回找多少天。
即使我们在 Athena 进行搜索，由于 Order_ID 不在分区中，也需要完整的 table 扫描。
以上还不是最坏的，最坏的情况是第3天转换时，第4天O001-Remark Change是未来数据，第3天应该不知道
有更好的方法吗？还是 AWS S3 + Athena 不适合这样复杂的情况（上面的情况只是我目前情况的简化版）？
我知道我的问题太多太多了。但所有这些都是我真正想澄清的，我找不到明确的答案。非常感谢任何帮助，非常感谢。
索引
不，Amazon Athena（以及它所基于的 Presto）不支持索引。这是因为 Athena/Presto（甚至 Redshift）是为大数据设计的，所以即使大数据上的索引也是 大数据 所以维护一个巨大的数据效率不高指数.
虽然传统数据库通过索引变得更快，但这不适用于大数据系统。相反，使用索引、压缩和列数据格式来提高性能。
分区
分区是分层的（例如Year -> Month -> Day）。带分区的objective是对不需要读取的"skip over"个文件。因此，只有在 WHERE 子句使用分区层次结构时，它们才会提供好处。
例如，使用 SELECT ... WHERE year=2018 将使用分区并跳过所有其他年份。
如果您的查询没有将这些分区字段之一放在 WHERE 子句中，则需要扫描所有目录和文件，因此没有任何好处。
你说"the data size will be doubled"，但事实并非如此。所有数据仅存储一次。分区不修改数据大小。
打开的文件太多
如果这是由 Amazon Athena 生成的错误，那么您应该通过 AWS Support 提出它。
复杂查询
Athena 当然可以执行复杂的查询，但它不是理想的平台。如果您经常执行复杂的 SQL 查询，请考虑使用 Amazon Redshift。
问题 6：Table/Query
我无法按照您的要求进行操作。如果您正在为 SQL 寻求帮助，请创建一个单独的问题，显示 table 中的数据示例和您正在寻求的输出示例。
扩展 John 的正确答案以添加两点：
Q1：获得性能的一种方法是定期对数据进行排序，同时使用像 Orc 和 Parquet 这样的柱状数据格式可以为您带来性能优势，因为它会跳过文件中的大部分 stripes/row 组以提供更好的性能。
Q3：再次按一组列进行分区并按另一组列对日期进行排序会给你在任何一组选择器上的查询带来性能优势。
Q4：打开的文件太多：这是 Athena 所基于的 presto 配置。该值越大，则需要更多的内存来存储要写入的内容，直到完成一条条，因此它是有限的。 Athena 不提供完全隔离，因此您或任何其他用户 运行 具有多个小文件的查询可能会导致这种情况。联系支持人员，我怀疑他们能提供帮助。共享基础设施的缺点之一 :)
Q5：复杂，如果你的意思是做大量操作的巨大查询，理论上 Athena 应该能够处理。您可以在查询中排序的数据量虽然有限制，具体取决于 Amazon 集群的节点数量。
由于Amazon决定集群大小，Athena存在可扩展性限制，建议先进行ETL再使用Athena查询。尽管对于较新版本的 Presto，此限制变得越来越不实用。
Q6：不是我的专业知识，更适合 SQL 部分，因为 Presto 使用 ANSI-sql 标准。您可以在此处查看函数和运算符列表 https://prestodb.io/docs/current/functions.html。
如果 Athena 的可扩展性成为您的障碍，您可以检查 Qubole、EMR 或 Starburst 以获取托管的 presto 发行版。
我目前正在为一个项目使用 AWS S3 + Athena。 但是，在使用 1-2 个月后，我发现它有一些局限性。 我不确定我是否不知道如何使用它或者它真的是一个限制。 但是请不要问我为什么在没有进行足够的研究之前选择使用它。我认为有2点：
- 项目需要
- Athena S3 和AWS 的资源不是很集中，其功能不断变化。在实际使用一段时间之前，我很难找到 Athena + S3 可以做什么或不能做什么。
跑题了，言归正传。 >_<
目前，我遇到了一个问题。随着数据量越来越大，数据扫描量和查询量越来越大，查询时间也越来越长（有时甚至会出现异常，比如我查询的时候too many open files） .但是AWS S3 + Athena好像只有分区没有索引。于是，问题就来了。
问题一：
我可以在 AWS S3 + Athena 上做类似索引的事情吗？
问题二：
如果我使用分区，似乎只能指定一个组合键（S3 文件夹中的一个或多个列作为标签）；否则，数据大小将加倍。这是真的吗？
问题三：
即使我愿意增加数据大小，也不可能有 2 个复合键的 table。我必须有 2 个 Athena tables 和 2 个相同的数据集，但在 S3 中有 2 种类型的分区才能实现这一点。这是真的吗？
问题四：
对于错误"too many open files"，经过一番研究，似乎是OS级别的问题，预定义的文件描述符数量有限。我现在的情况是 SQL 大部分时间没有异常，但是在某个时期，它很容易出现异常。我的理解是亚马逊会有一个计算机集群（比如32节点的服务器）来服务一定数量的客户，包括我公司和其他公司。每个服务器都有有限数量的可用文件描述符，并在所有客户之间共享。然后，在某些高峰期（其他公司正在执行大量查询），可用的文件描述符数量会下降，这也解释了为什么我的 SQL 具有相同的数据集有时会出现异常，但并非总是如此。这是真的吗？
问题 5:
由于缺少索引功能，S3 + Athena 不应该执行复杂的 SQL 查询。这意味着，复杂的连接逻辑只能在加载到 S3 之前在转换层的某个地方完成。这是真的吗？
问题 6:
这个问题接在上一个问题 5 之后。
让我用一个简单的例子来说明：
开发了一个报告系统来显示订单和交易。其关系是，在订单执行后，交易将 generated.The Order_ID 是 link 上涨交易及其相关订单活动的关键。分区设置为日期。
现在，以下数据来了：
要求是：
1. 第1天的报表，只显示订单记录O001-下单
2. 第2天的报表，只显示订单记录O002-Order Change Order
3. 第3天的报告显示所有记录，包括4条订单记录和1条交易记录
4. 第4天的报表，只显示订单记录O004-Remark Change
对于第 1、2 和 4 天，这很容易，因为我只显示当天的数据。
但是，对于第 3 天，我需要显示所有数据，一些是过去的，一些是未来的（O001-Remark Change）。
为了避免复杂SQL，我只能在Transformation层做join逻辑
但是第3天做改造的时候，如果对方没有把第1天和第2天的数据发给我，你只能找到历史文件，这样不好，你永远不知道要往回找多少天。
即使我们在 Athena 进行搜索，由于 Order_ID 不在分区中，也需要完整的 table 扫描。
以上还不是最坏的，最坏的情况是第3天转换时，第4天O001-Remark Change是未来数据，第3天应该不知道
有更好的方法吗？还是 AWS S3 + Athena 不适合这样复杂的情况（上面的情况只是我目前情况的简化版）？
我知道我的问题太多太多了。但所有这些都是我真正想澄清的，我找不到明确的答案。非常感谢任何帮助，非常感谢。
索引
不，Amazon Athena（以及它所基于的 Presto）不支持索引。这是因为 Athena/Presto（甚至 Redshift）是为大数据设计的，所以即使大数据上的索引也是 大数据 所以维护一个巨大的数据效率不高指数.
虽然传统数据库通过索引变得更快，但这不适用于大数据系统。相反，使用索引、压缩和列数据格式来提高性能。
分区
分区是分层的（例如Year -> Month -> Day）。带分区的objective是对不需要读取的"skip over"个文件。因此，只有在 WHERE 子句使用分区层次结构时，它们才会提供好处。
例如，使用 SELECT ... WHERE year=2018 将使用分区并跳过所有其他年份。
如果您的查询没有将这些分区字段之一放在 WHERE 子句中，则需要扫描所有目录和文件，因此没有任何好处。
你说"the data size will be doubled"，但事实并非如此。所有数据仅存储一次。分区不修改数据大小。
打开的文件太多
如果这是由 Amazon Athena 生成的错误，那么您应该通过 AWS Support 提出它。
复杂查询
Athena 当然可以执行复杂的查询，但它不是理想的平台。如果您经常执行复杂的 SQL 查询，请考虑使用 Amazon Redshift。
问题 6：Table/Query
我无法按照您的要求进行操作。如果您正在为 SQL 寻求帮助，请创建一个单独的问题，显示 table 中的数据示例和您正在寻求的输出示例。
扩展 John 的正确答案以添加两点： Q1：获得性能的一种方法是定期对数据进行排序，同时使用像 Orc 和 Parquet 这样的柱状数据格式可以为您带来性能优势，因为它会跳过文件中的大部分 stripes/row 组以提供更好的性能。
Q3：再次按一组列进行分区并按另一组列对日期进行排序会给你在任何一组选择器上的查询带来性能优势。 Q4：打开的文件太多：这是 Athena 所基于的 presto 配置。该值越大，则需要更多的内存来存储要写入的内容，直到完成一条条，因此它是有限的。 Athena 不提供完全隔离，因此您或任何其他用户 运行 具有多个小文件的查询可能会导致这种情况。联系支持人员，我怀疑他们能提供帮助。共享基础设施的缺点之一 :) Q5：复杂，如果你的意思是做大量操作的巨大查询，理论上 Athena 应该能够处理。您可以在查询中排序的数据量虽然有限制，具体取决于 Amazon 集群的节点数量。
由于Amazon决定集群大小，Athena存在可扩展性限制，建议先进行ETL再使用Athena查询。尽管对于较新版本的 Presto，此限制变得越来越不实用。 Q6：不是我的专业知识，更适合 SQL 部分，因为 Presto 使用 ANSI-sql 标准。您可以在此处查看函数和运算符列表 https://prestodb.io/docs/current/functions.html。 如果 Athena 的可扩展性成为您的障碍，您可以检查 Qubole、EMR 或 Starburst 以获取托管的 presto 发行版。