Best way to overcome HIVE_PARTITION_SCHEMA_MISMATCH error in Athena while preserving structure of structs?
I ran the following Amazon Athena query on a table created by AWS Glue, which had crawled an Amazon S3 export of Synthea data from Amazon HealthLake:
SELECT * FROM "glue01234567890_fhir_export_abcdefghijklmnopqrst";
That resulted in this error:
HIVE_PARTITION_SCHEMA_MISMATCH: There is a mismatch between the table and partition schemas. The types are incompatible and cannot be coerced. The column 'code' in table 'demo.glue01234567890_fhir_export_abcdefghijklmnopqrst' is declared as type 'struct<coding:array<struct<system:string,code:string,display:string>>,text:string>', but partition 'partition_0=ImagingStudy' declared column 'id' as type 'string'. This query ran against the "demo" database, unless qualified by the query. Please post the error message on our forum or contact customer support with Query Id
I saw one answer to go to edit the Crawler and then to output -->configuration and "Update all new and existing partitions with metadata from the table." However, that didn't resolve the error for me.
When I edit the schema manually an change column 'code' from
string, the error goes away, and Athena brings my attention to the next mismatch:
partition 'partition_0=Immunization' declared column 'patient' as type 'struct<reference:string>'.
I don't think, however, manually replacing all structs with strings will get me the results I want, because I need Glue and Athena to be aware of the fields inside the structs. What is the best approach to overcoming this error while preserving the structure of the data, in this situation where I want to make the HealthLake export queryable by Athena?
I understand I'll want to add a step to the ETL in Glue to first convert to Parquet or ORC for Athena performance reasons, but right now I'm dealing with a small sample dataset and just want to focus on getting a minimum viable end-to-end flow going.
The reason for the problem is the size of the dataset which confuses the crawler to pick the "correct" column type based on too few examples.
I would start with the general type of String. You can still use Athena to parse it, either directly with the dot notation (
SELECT patient.reference FROM...) or using the many JSON functions. See more ways to query JSON here.
Thank you for the idea! To help me understand this deeper, I'm interested how you arrive at the conclusion that the size of the dataset is an issue here, and how that would make a difference to this scenario? Great point that Athena is able to parse values of type
Stringas JSON without the need of having type
crawled data can not be queried in athenaAccepted Answerasked 5 years ago
AWS Glue Datatype Numeric giving issueasked 4 months ago
HIVE_METASTORE_ERROR when running an Athena query to select the first 10 rows from a partitioned table created by a Glue Crawler.asked a month ago
Encountering an issue with AWS Athena - HIVE_METASTORE_ERROR: Error: : expected at the position 63 ofasked 5 months ago
Amazon Athena query outputting all columns in the csv as VARCHARsAccepted Answerasked 2 years ago
Athena permission error running a queryasked 3 months ago
Best way to overcome HIVE_PARTITION_SCHEMA_MISMATCH error in Athena while preserving structure of structs?asked a month ago
GENERIC_USER_ERROR for Athena + Dynamodbasked 25 days ago
I cannot use current_date + interval in Athena boto3 query in LambdaAccepted Answerasked 3 months ago
How to create Athena View using CDKAccepted Answerasked 4 months ago