我收到一个 HIVE_PARTITION_SCHEMA_MISMATCH 错误，我不太确定该怎么做。当我查看 2 个不同的模式时，唯一不同的是我的一个结构中的键的顺序(由胶水爬虫创建)。我真的不关心数据的顺序，并且我将数据作为 JSON blob 接收，所以我不能保证键的顺序。
struct<device_id:string,user_id:string,payload:array<struct<channel:string,sensor_id:string,type:string,unit:string,value:double,name:string>>,topic:string,channel:string,client_id:string,hardware_id:string,timestamp:bigint,application_id:string>
struct<device_id:string,user_id:string,payload:array<struct<channel:string,name:string,sensor_id:string,type:string,unit:string,value:double>>,topic:string,channel:string,client_id:string,hardware_id:string,timestamp:bigint,application_id:string>
最佳答案
我建议您停止使用 Glue 爬虫。这可能不是您希望的响应，但爬虫的工作真的很糟糕。它们有时可以作为一种从其他人生成的随机数据堆中获取模式的方法很有用，并且您不想花时间查看它的模式是什么——但是一旦你有了一个模式，并且您知道新数据将遵循该架构，而 Glue 爬虫只是挡道，会产生不必要的问题，就像您遇到的问题一样。
具体做什么取决于如何将新数据添加到 S3。
如果您可以控制生成数据的代码，则可以在上传数据后添加用于添加分区的代码。此解决方案的好处是在生成新数据后立即添加分区，因此表始终是最新的。但是，它可能会以一种不可取的方式将数据生成代码与 Glue(或 Athena，如果您更喜欢通过 SQL 添加分区)紧密耦合。
如果从生成数据的代码中添加分区没有意义，您可以创建一个 Lambda 函数来执行此操作。您可以将其设置为每天在固定时间运行(如果您知道新数据的位置，则不必等到它存在，分区可以指向空位置)，也可以通过 S3 通知触发它(如果有多个文件，您可以想办法通过 SQS 来消除通知的抖动，或者只是一遍又一遍地创建分区，如果分区已经存在，只需吞下错误)。
您可能还听说过 MSCK REPAIR TABLE ...。在某些方面它比 Glue 爬虫更好，但在其他方面同样糟糕。它只会添加新分区，从不更改架构，这通常是您想要的，但效率极低，并且文件越多运行速度越慢。有点像 Glue 爬虫。
关于amazon-web-services - 如何忽略亚马逊雅典娜结构顺序，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56397037/