Getting new and strange HIVE issue out of the blue

To prevent and handle these types of HIVE_BAD_DATA errors in Athena, you can take several approaches:

1. Schema Validation: Please not that parquet files have their own metadata/schema. so, Ensure that the schema defined in your Athena table matches the actual data types in your Parquet files. In this case, it appears that the 'bond_amount' field is defined as a double in the table schema, but the Parquet file contains binary data for this field. You can inspect the parquet files' metadata using some parquet-tools and ensure both parquet schema and table schema defined should match/compatible.

2. Data Type Conversion: If possible, modify your data ingestion or ETL process to convert the binary data to the appropriate double format before writing it to Parquet files.

3. Schema Evolution: If the data type change is intentional, you may need to handle schema evolution properly. Parquet supports schema evolution, but you need to ensure your conversion process and queries can handle these changes.

4. Use STRING as Intermediate Type: As a workaround, you could define the column as STRING in your Athena table schema, then use CAST in your queries to convert it to DOUBLE when needed. This allows for more flexibility in handling different data types.

5. Data Cleaning: Implement a data cleaning step in your pipeline to handle or remove any incompatible data before it reaches Athena.

By implementing these practices, you can better prevent, detect, and handle data type mismatches and other HIVE_BAD_DATA errors in your Athena queries.
Sources
Amazon Athena HIVE_BAD_DATA: Error Parsing a column in the table: Cannot convert value of type String to a REAL value | AWS re:Post
Hive Bad Data error | AWS re:Post
Athena engine version 3 - Amazon Athena