包含分区的表中的更新
在 Athena 中,一个表及其分区必须使用相同的数据格式,但它们的架构可以不同。当您创建一个新分区时,该分区通常继承表的架构。随着时间的推移,该架构可能开始变得不同。原因包括:
-
当您的表的架构发生变化时,分区架构没有更新,从而没有保持与表的架构同步。
-
AWS Glue 爬网程序允许您发现具有不同架构的分区中的数据。这意味着,假如您使用 AWS Glue 在 Athena 中创建了一个表,则当爬网程序完成处理后,该表的架构及其分区可能会有所不同。
-
如果您直接使用 AWS API 添加分区。
如果分区满足以下约束,Athena 会成功地处理具有分区的表。如果不满足这些约束,Athena 会发出 HIVE_PARTITION_SCHEMA_MISMATCH
错误。
-
每个分区的架构与表的架构兼容。
-
表的数据格式允许您要执行的更新类型:添加、删除、重新排序列或更改列的数据类型。
例如,对于 CSV 和 TSV 格式,您可以将列重命名,在表的最后添加新列,并将列的数据类型更改为其他兼容类型,但您无法删除列。对于其他格式,可以添加或删除列,或者将列的数据类型更改为其他兼容类型。有关信息,请参阅摘要:Athena 中的更新和数据格式。
避免带有分区的表出现架构不匹配错误
在查询执行开始时,Athena 通过检查表和分区之间每个列数据类型是否兼容来验证表的架构。
-
对于 Parquet 和 ORC 数据存储类型,Athena 依赖于列名,并将其用于基于列名的架构验证。这消除了具有 Parquet 和 ORC 格式分区的表的
HIVE_PARTITION_SCHEMA_MISMATCH
错误。(如果 SerDe 属性设置为按名称访问索引,则对于 ORC 来说此为真:orc.column.index.access=FALSE
。Parquet 默认按名称读取索引)。 -
对于 CSV、JSON 和 Avro,Athena 使用基于索引的架构验证。这意味着,如果您遇到架构不匹配错误,则应删除导致架构不匹配的分区并创新创建它,以便 Athena 可以成功地查询它。
Athena 会将表的架构与分区架构做比较。假如您使用 AWS Glue 爬网程序在 Athena 中创建了一个 CSV、JSON 和 AVRO 格式的表,则在爬网程序完成处理后,该表的架构和其分区的架构可能会不同。如果表的架构与分区架构之间存在不匹配,则您的 Athena 查询将因类似如下的架构验证错误而失败:'crawler_test.click_avro' is declared as type 'string', but partition 'partition_0=2017-01-17' declared column 'col68' as type 'double'. ('crawler_test.click_avro' 声明为类型 'string',但分区 'partition_0=2017-01-17' 声明列 'col68' 的类型为 'double'。)
对于此类错误,通常的解决方法是删除导致错误的分区并重新创建它。有关更多信息,请参阅 ALTER TABLE DROP PARTITION 和 ALTER TABLE ADD PARTITION。