问题标签 [amazon-s3-select]

我打算使用 Python 对存储在 S3 中的一个非常大的 csv 文件执行一些内存密集型操作，目的是将脚本移动到 AWS Lambda。我知道我可以读取整个 csv nto 内存，但我肯定会遇到 Lambda 的内存和存储限制，使用如此大的文件是否有任何方法可以使用 boto3 一次将 csv 的块读入或读入 Python /botocore，理想情况下通过指定要读入的行号？

以下是我已经尝试过的一些事情：

1）使用range参数 inS3.get_object指定要读入的字节范围。不幸的是，这意味着最后一行在中间被截断，因为无法指定要读入的行数。有一些混乱的解决方法，例如扫描最后一个换行符，记录索引，然后将其用作下一个字节范围的起点，但如果可能的话，我想避免这种笨拙的解决方案。

2) 使用 S3 select 编写 sql 查询以选择性地从 S3 存储桶中检索数据。不幸的row_numbers是，不支持 SQL 函数，而且看起来没有办法读取行的子集。

我正在使用 S3 select 从 S3 存储桶中的文件中查询一个对象，但想知道我是否可以使用多个文件来执行此操作，或者它是否仅限于一个。我使用 aws lambda 从文件中编写了一个查询，但是当我尝试为另一个文件编写另一个查询时，它给了我一条错误消息。

我正在尝试从 S3 对象中捕获数据。我正在使用如下 S3 Select 功能：

boto3 版本：1.7.59

运行我的代码后，我收到错误：

回溯（最后一次调用）：文件“C:/Users/a_urrego/PycharmProjects/DW_FlightHub/S3Select.py”，第 48 行，OutputSerialization = { 'JSON': { 'RecordDelimiter': ',' } }, File " C:\Users\a_urrego\AppData\Local\Programs\Python\Python36-32\lib\site-packages\botocore\client.py”，第 314 行，在 _api_call 返回 self._make_api_call(operation_name, kwargs) 文件“C: \Users\a_urrego\AppData\Local\Programs\Python\Python36-32\lib\site-packages\botocore\client.py"，第 612 行，在 _make_api_call 中引发 error_class(parsed_response, operation_name) botocore.exceptions.ClientError：错误调用 SelectObjectContent 操作时发生 (ParseUnexpectedToken)：发现意外令牌 AS：如第 1 行第 33 列。

进程以退出代码 1 结束

我正在运行 Python 脚本以使用 AWS-S3-Select 工具查询 AWS-S3 存储桶。我正在从 txt 文件中导入一个变量，并希望将其传递给 S3-Select 查询。我还想通过查询整个 S3 目录而不是单个文件来计算所有导入的变量重复次数（在指定列内）。

这是我到目前为止所拥有的：

当我运行这个脚本时，我得到了以下错误：

我正在尝试使用AWS SELECT计算存储在 S3 存储桶中的文件中的行数。具体来说，执行以下命令（基于AWS s3api 文档和这个用于 count(*) 查询的 Java 示例）：

以上返回：

尽管默认值适用于我的用例，但我尝试CSV={}在命令行中提供带有参数的附加信息，并尝试了替代 JSON 语法'{"CSV":{}}'。总是收到Circular reference detected错误。

该文件存在于桶中；否则，你会得到一个NoSuchKey错误。是的，去过那里，做过... :)

AWS SELECT 的例子要么很少见，要么我的 Google-fu 让我失望了。

建议？欢迎使用替代方案，但它们必须是可编写脚本的。

我正在尝试执行以下操作：

• 从 S3 下载 Athena 查询的输出 ( file.csv)
• gzip 输出并上传到不同的 S3 位置 ( file.csv.gz)
• 在 Ruby SDK 中使用 S3 Select 来查询file.csv.gz

我总是收到以下错误，总是“接近字节 8192”，即使内容file.csv.gz完全不同：

Aws::S3::Errors::InvalidTextEncoding (UTF-8 encoding is required. The text encoding error was found near byte 8,192.)

注意：对相同的未压缩file.csv工作使用相同的 S3 Select 查询。我尝试过各种奇怪的事情，但我充满了绝望。

重现步骤：

1. 从文件开始s3://mybucket/file.csv
2. 使用 aws-cli 下载：aws s3 cp s3://mybucket/file.csv file.csv
3. 压缩文件：gzip file.csv
4. 上传file.csv.gz：aws s3 cp file.csv.gz s3://mybucket/file.csv.gz

这是代码：

以下收到文本编码错误。

但是，针对未压缩的运行file.csv不会：

我尝试了各种文本编码、内容类型元数据、内容编码等的组合，但似乎找不到任何有效的方法。在我看来，它总是在字节 8192 上出现错误的事实非常奇怪/可疑。

任何帮助将非常感激！

我正在尝试使用 AWS s3select 功能来查询镶木地板文件。根据文档，它是受支持的，但我尝试了各种配置，但无法正常工作。在我已注释掉的每个 InputSerialization 尝试中，我都列出了我在尝试该版本时收到的错误。有人可以告诉我如何正确配置它吗？

下面是两种方法，它们是我在 AWS 中的状态机的一部分。

首先，使用 S3 SELECT 从 csv 文件中获取数据的方法。

现在，调用它的方法：

但是，我从 CloudWatch 日志中获取的数据是垃圾 - 它看起来有点像 ASCII 字符/或编码字符？不是我所期待的！有什么想法吗？

{ "_1": "\u00001\u00000\u00005\u0000", "_2": "\u0000K\u0000a\u0000t\u0000e\u0000\u0000F\u0000a\u0000r\u0000d\u0000e\u00000l\u0000l\u u0000" }

{ "_1": "\u00001\u00000\u00006\u0000", "_2": "\u0000S\u0000h\u0000o\u0000n\u0000a\u0000\u0000M\u0000a\u0000r\u0000i\u00000n\u0\000\u u0000" }

{ "_1": "\u00001\u00000\u00008\u0000", "_2": "\u0000S\u0000h\u0000o\u0000n\u0000a\u0000 \u0000M\u0000a\u0000r\u0000i\u00000n\u0\000o\u u0000" }

{ "_1": "\u00001\u00001\u00001\u0000", "_2": "\u0000S\u0000h\u0000o\u0000n\u0000a\u0000 \u0000M\u0000a\u0000r\u0000i\u00000n\u0\000o\u u0000" }

{ "_1": "\u00001\u00001\u00002\u0000", "_2": "\u0000L\u0000i\u0000n\u0000a\u0000\u0000H\u0000a\u0000n\u0000n\u0000a\u00000w\u0\000\u u0000" }

{ "_1": "\u00001\u00001\u00003\u0000", "_2": "\u0000J\u0000e\u0000n\u0000n\u0000i\u0000f\u0000e\u0000r\u0000\u0000H\u00000a\u00000\u r\u0000" }

{ "_1": "\u00001\u00001\u00004\u0000", "_2": "\u0000S\u0000t\u0000a\u0000n\u0000 \u0000K\u0000a\u0000k\u0000k\u0000a\u00000s\u00000i\u\ r\u0000" }

{ "_1": "\u00001\u00001\u00006\u0000", "_2": "\u0000S\u0000t\u0000a\u0000n\u0000 \u0000K\u0000a\u0000k\u0000k\u0000a\u00000s\u00000s\u\ r\u0000" }

{ "_1": "\u00001\u00001\u00008\u0000", "_2": "\u0000S\u0000t\u0000a\u0000n\u0000 \u0000K\u0000a\u0000k\u0000k\u0000a\u00000s\u00000i\u\ r\u0000" }

{ "_1": "\u00001\u00001\u00009\u0000", "_2": "\u0000S\u0000h\u0000o\u0000n\u0000a\u0000 \u0000M\u0000a\u0000r\u0000i\u00000n\u0\000o\u u0000" }

{ "_1": "\u00001\u00002\u00007\u0000", "_2": "\u0000A\u0000y\u0000d\u0000i\u0000n\u0000\u0000T\u0000e\u0000b\u0000y\u00000a\u00000a\u\u u0000n\u0000\r\u0000" }

{ "_1": "\u00001\u00002\u00008\u0000", "_2": "\u0000C\u0000a\u0000m\u0000e\u0000r\u0000o\u0000n\u0000\u0000P\u0000a\u00000l\u00000r\u u0000\r\u0000" }

{ "_1": "\u00001\u00009\u00007\u0000", "_2": "\u0000S\u0000h\u0000a\u0000r\u0000o\u0000n\u0000\u0000B\u0000e\u0000r\u00000g\u00000\u\u r\u0000" }

{ "_1": "\u00002\u00000\u00001\u0000", "_2": "\u0000K\u0000a\u0000r\u0000e\u0000e\u0000n\u0000a\u0000\u0000D\u0000a\u00000v\u00000e\u\u u0000\r\u0000" }

{ "_1": "\u00002\u00000\u00002\u0000", "_2": "\u0000L\u0000i\u0000n\u0000a\u0000 \u0000H\u0000a\u0000n\u0000n\u0000a\u00000w\u0\000\u u0000" }

{ "_1": "\u00002\u00000\u00003\u0000", "_2": "\u0000S\u0000a\u0000m\u0000\u0000V\u0000i\u0000t\u0000a\u0000n\u0000z\u00000a\u000\r\" }

{ "_1": "\u00002\u00000\u00006\u0000", "_2": "\u0000K\u0000a\u0000r\u0000e\u0000e\u0000n\u0000a\u0000\u0000D\u0000a\u00000v\u00000e\u u0000\r\u0000" }

{ "_1": "\u00002\u00000\u00008\u0000", "_2": "\u0000K\u0000a\u0000r\u0000e\u0000e\u0000n\u0000a\u0000\u0000D\u0000a\u00000v\u00000e\u u0000\r\u0000" }

{ "_1": "\u00002\u00001\u00004\u0000", "_2": "\u0000K\u0000a\u0000r\u0000e\u0000e\u0000n\u0000a\u0000\u0000D\u0000a\u00000v\u00000e\u\u u0000\r\u0000" }

{ "_1": "\u00002\u00001\u00007\u0000", "_2": "\u0000K\u0000y\u0000l\u0000i\u0000e\u0000\u0000B\u0000r\u0000a\u0000d\u000000\u00000e\u r\u0000" }

{ "_1": "\u00002\u00001\u00008\u0000", "_2": "\u0000K\u0000a\u0000t\u0000e\u0000 \u0000F\u0000a\u0000r\u0000d\u0000e\u00000l\u0\00l\u u0000" }

{ "_1": "\u00002\u00001\u00009\u0000", "_2": "\u0000C\u0000a\u0000m\u0000e\u0000r\u0000o\u0000n\u0000\u0000P\u0000a\u00000l\u00000r\u u0000\r\u0000" }

{ "_1": "\u00002\u00002\u00003\u0000", "_2": "\u0000S\u0000a\u0000m\u0000\u0000V\u0000i\u0000t\u0000a\u0000n\u0000z\u00000a\u000\r\" }

{“_1”：“\u00002\u00002\u00005\u0000”，“_2”：“\u0000K\u0000a\u0000r\u0000e\u0000e\u0000n\u0000a\u0000\u0000D\u0000a\u00000v\u00000e\u u0000\r\u0000" }

{ "_1": "\u00002\u00002\u00006\u0000", "_2": "\u0000K\u0000a\u0000t\u0000e\u0000 \u0000F\u0000a\u0000r\u0000d\u0000e\u00000l\u0\00l\u u0000" }

{ "_1": "\u00002\u00002\u00008\u0000", "_2": "\u0000K\u0000a\u0000r\u0000e\u0000e\u0000n\u0000a\u0000\u0000D\u0000a\u00000v\u00000e\u u0000\r\u0000" }

{ "_1": "\u00002\u00002\u00009\u0000", "_2": "\u0000K\u0000a\u0000r\u0000e\u0000e\u0000n\u0000a\u0000\u0000D\u0000a\u00000v\u00000e\u\u u0000\r\u0000" }

{ "_1": "\u00002\u00003\u00000\u0000", "_2": "\u0000K\u0000a\u0000r\u0000e\u0000e\u0000n\u0000a\u0000\u0000D\u0000a\u00000v\u00000e\u u0000\r\u0000" }

这是实际的 CSV 数据

我有 1M 行 CSV 数据。选择 10 行，我是否需要为 10 行付费。S3 Select 中返回的数据和扫描的数据是什么意思？

关于 S3 select 的这些条款的文档较少

是否可以通过分区对 S3 文件进行最简单的并发 SQL 查询？

看起来您必须从 3 个选项中选择 2 个选项的问题。

您可以使用 S3 Select 对 S3 进行并发 SQL 查询。但是 S3 Select 不支持分区，它也可以一次处理单个文件。

Athena 支持分区和 SQL 查询，但它有 20 个并发查询的限制。限额可以提高，但没有保证和上限。

您可以通过 EMRFS 配置在 S3 上工作的 HBase，但这需要很多配置。而且我认为数据应该通过 HBase（另一种格式）写入。也许更简单的解决方案？