我正在使用 AWS Glue 爬网程序对粗略的 170 GB avro 数据进行爬网以创建数据目录表。
avro 数据中有几个不同的模式版本，但爬虫仍然设法将数据合并到一个表中(我已经启用了"按数据兼容性和模式相似性分组 - 模式")。
这是事情出现问题的时候。
我只能使用 Athena 对数据运行SELECT COUNT(*) FROM <DB>.<TABLE>查询 - 任何其他查询都会引发以下错误：
GENERIC_INTERNAL_ERROR: Unknown object inspector category: UNION
一个简短的谷歌检查让我相信这与 avro 文件中的模式有关。
通常，这是我集中精力的地方，但是：我之前已经能够执行完全相同的过程(AVRO ->爬虫 -> Glue job -> PARQUET)，较小的 avro 数据集 (50GB) 具有相同的问题(只能运行计数查询)。继续前进。
转换作业以前大约需要一个小时。现在，当对 170 GB 数据运行相同的作业时，作业将在一分钟内完成，因为glueContext.create_dynamic_frame.from_catalog现在返回一个空帧 - 没有错误，没有任何东西。混乱是真实的，因为我能够在 Athena 中对作业使用的同一表运行 COUNT 查询，返回 520M 对象的计数。
有谁知道问题可能是什么？
可能相关的几件事：
- COUNT 查询返回 520M，但表属性中的
recordCount显示 170M 记录。 - 数据存储在大小为2MB-30MB的300k .avro文件中 是的，爬网程序
- 指向包含所有文件的文件夹，而不是文件(常见的爬网程序陷阱)。
- 之前使用较小数据集(50 GB)的尝试是 100% 成功的 - 我可以抓取镶木地板数据并使用 Athena 进行查询(测试了许多不同的查询，所有查询都有效)
我们遇到了同样的问题，可以按如下方式解决。
在我们的 avro 模式中，有一条具有混合字段类型的记录，即，一些是形式"type" : [ "string" ]，另一些是形式"type" : [ "null", "string" ]。
手动将其更改为随处[ "null", "string" ]，我们能够毫无问题地使用雅典娜中的表格。