私がAWS AthenaおよびAWS Glueでメタデータの取り扱いでハマった話を共有いたします。

ハマった経緯

parquetのデータをS3に配置する
Glueのテーブルを作成する
AthenaでSELECT文を実行するため、load partition()を実行しパーティションを読み込む
AthenaでSELECT文を実行する → parquet内でのデータ型の定義とGlueテーブルのテーブル定義に齟齬があるためエラーと表示される
テーブル定義を誤っていたことに気づきGlueのテーブル情報を修正する
AthenaでSELECT文を実行する → なぜかparquet内でのデータ型の定義とGlueテーブルのテーブル定義に齟齬があるためエラーと表示される(困惑)

ハマった状況を再現

そのとき、ハマった状況を再現していきます。
まず、S3に配置するparquetをpysparkを使って作成する。

from pyspark.sql.types import StructType
from pyspark.sql.types import StructField
from pyspark.sql.types import StringType
from pyspark.sql.types import IntegerType
rdd = sc.parallelize([
	('apple', 120),
	('banana', 220),
	('tomato', 320),
	('chicken', 300),
	])
schema = StructType([
	StructField('label', StringType(), False),
	StructField('value', IntegerType(), False),
	])
df = spark.createDataFrame(rdd, schema)
df.repartition(1).write.parquet('./output/')

dfの中身はこのようになっております。
labelのカラムがstring型、valueのカラムがint型です。

これをS3に配置します。今回は s3://inu-is-dog/2020-04-19-qiita/id=123/part-00000.snappy.parquet へ配置いたしました。
id=123がパーティションとなるのがミソです。

次にGlueでテーブルを手動で作成いたします。

データベース名：sampledb
テーブル名：table_20200419
データストア：s3://inu-is-dog/2020-04-19-qiita/
データ形式：Parquet
スキーマ:
- id(パーティションキー) [string]
- label [int]
- value [int]

あえて、スキーマのlabelのデータ型はstring型ではなく、int型(誤り)としています。

次にAthenaの画面に遷移します。
今回はidのパーティションを持つテーブルを作成したため、SELECT文を実行する前にid=123のパーティションを登録する。

ALTER TABLE sampledb.table_20200419 ADD PARTITION (id = '123');

それでは、SELECT文を実行してみましょう。

SELECT * 
FROM sampledb.table_20200419;

"HIVE_BAD_DATA: Field label's type BINARY in parquet is incompatible with type int defined in table schema"とエラーが表示されました。

Glueのテーブル登録でlabelのデータ型を誤って登録していたことが原因でしょう。

...ということで、table_20200419のスキーマの編集を行いました。

これで先ほどのSELECT文は通るはず....

ダメでした.... 同じエラーメッセージです。(困惑)

Athenaの画面の左側のテーブル情報を見てもわかるのですがlabelのカラムは正常にstring型に更新されております。
それなら、なぜまた同じエラーメッセージなのか？？

原因

Glueのテーブル table_20200419へ画面を遷移させ、[パーティションの表示] → [id=123のプロパティの表示]をさせてみましょう。

id=123のパーティションではlabelはint型で扱うように設定されていることがわかります。

パーティションごとのメタデータはそのパーティションを読み込んだ際のテーブル情報が登録されており、大元のテーブルの変更は反映されていないということになります。

対処法

この原因を踏まえて、大元のテーブルのカラム情報が変更された際には今まで読み込んでいたパーティションのメタデータも更新する必要があることがわかりました。

パーティションをDROPした後、改めてパーティションを読み込む対応方法を共有いたします。

ALTER TABLE sampledb.table_20200419 DROP PARTITION (id = '123');

ALTER TABLE sampledb.table_20200419 ADD PARTITION (id = '123');

これで無事、SELECT文が通るようになりました。

この記事がみなさまの開発や分析の一助となれば幸いです。