0

我正在使用 AWS Glue Crawler 抓取大约 170 GB 的 avro 数据以创建 Data Catalog 表。

avro 数据中有几个不同的模式版本，但爬虫仍然设法将数据组合到一个表中（我启用了“按数据兼容性和模式相似性分组 - 模式”）。

这是事情出现问题的时候。

我只能使用 Athena 对SELECT COUNT(*) FROM <DB>.<TABLE>数据运行查询 - 任何其他查询都会引发以下错误：

GENERIC_INTERNAL_ERROR: Unknown object inspector category: UNION

一个简短的谷歌检查让我相信这与 avro 文件中的模式有关。

通常，这是我会集中精力的地方，但是：我之前已经能够执行完全相同的过程（AVRO -> 爬虫 -> 胶水作业 -> PARQUET），但使用较小的 avro 数据集（50GB）有同样的问题（只能运行计数查询）。继续。

之前的转换工作大约需要一个小时。现在，在 170 GB 数据上运行相同的作业时，作业会在一分钟内完成，因为glueContext.create_dynamic_frame.from_catalog现在返回一个空帧 - 没有错误，没有任何内容。混乱是真实的，因为我能够在 Athena 中对作业使用的同一张表运行 COUNT 查询，返回 520M 个对象的计数。

有谁知道问题可能是什么？

一些可能相关的事情：

  • COUNT 查询返回 520M，但recordCount表中的属性显示 170M 记录。
  • 数据存储在 300k .avro 文件中，大小为 2MB-30MB
  • 是的，爬虫指向包含所有文件的文件夹，而不是文件（常见的爬虫陷阱）。
  • 之前使用较小数据集（50 GB）的尝试是 100% 成功的 - 我可以爬取 parquet 数据并使用 Athena 查询它（测试了许多不同的查询，所有的工作）
4

1 回答 1

1

我们遇到了同样的问题，可以按如下方式解决。

在我们的 avro 模式中，有一个混合字段类型的记录，即，一些是 form "type" : [ "string" ]，另一些是 form "type" : [ "null", "string" ]。

手动将其更改为[ "null", "string" ]到处，我们能够在 Athena 中使用该表而没有任何问题。

于 2019-12-13T13:24:34.053 回答