TL;DR
- CodeCatalystのblueprintの中から"AWS Glue ETL"をやってみた
- CSVファイルとParquetファイルの両方でAthenaのクエリを実行してみた
- Parquetは列指向だから特定の列の扱い(集計など)に強い
- 逆に、全情報を取ってくるならCSVの方が早い
CodeCatalystのblueprint "AWS Glue ETL"
-
CodeCatalystにはblueprintという便利なサンプルプロジェクトをいくつか提供してくれます
-
その中で今回は"AWS Glue ETL"というテーマを体験しました
- アーキテクチャと使い方の流れは以下の通りです
1． S3バケットにCSVファイルをアップロード
2． Lambdaがキックされ、その中でGlue Jobを実行する
3． Glue JobはCSVファイルをParquetファイルに変換し、別ファイルとしてS3にアップロードする
4． 自分でAthenaを操作してParquetファイルに対してSQLクエリを実行
- アーキテクチャと使い方の流れは以下の通りです
-
CodeCatalystはCDKを使ったデプロイパイプラインを自動で提供してくれるので本当に便利ですよね！
Athenaでクエリしてみた
※このSQLもblueprintの中でGlue WorkGroupとしてデプロイされていますのでご安心を
※512ミリ秒
- ここで気になったことは、変換前のCSVと変換後のParquetでパフォーマンス比較したらどうなるのか？ということです
- blueprintの中のサンプルCSVファイルの中身は265件だけです
- パフォーマンスの差を確認するために以下のような簡単なプログラムを用意しましたのでご参考ください
import csv
with open('output.csv', 'w', newline='', encoding='utf-8') as file:
writer = csv.writer(file, quoting=csv.QUOTE_NONNUMERIC)
# ヘッダー行を書き込む
writer.writerow(["LocationID", "Borough", "Zone", "service_zone"])
# 1万件のデータ行をループで作成して書き込む
for i in range(1, 10001):
location_id = i
borough = f'Borough{i}'
zone = f'Zone{i}'
service_zone = f'service_zone{i}'
writer.writerow([location_id, borough, zone, service_zone])
1万件で比較してみた
- ちなみに、CSVファイルクエリ用のGlue TableはGlue Crawlerを使って作りました
- (これはもちろん手動です、初めてなので手探りでした･･･)
※Parquetファイルの結果
※CSVファイルの結果
- CSVの方が早いぞ！！
- (それもそのはず、実行しているSQLが｢SELECT * 〜｣だからParquetの強みが活かせてない)
10万件で比較してみた
※Parquetファイルの結果
※CSVファイルの結果
- お〜、どんどん差が出ますな〜(感心)
ここで満を持して集計関数で比較してみた
- ｢SELECT SUM(CAST(LocationID AS bigint)) FROM 〜｣というように、LocationID列の値の合計を出力
※Parquetファイルの結果
※CSVファイルの結果
- ちゃんとParquetの方がパフォーマンスが良い！！
- (ちなみに、ファイルサイズもParquetの方が小さいのでストレージ容量、費用の削減にもなります)
まとめ
- CodeCatalystはやっぱり便利だし、他のblueprintも試していきたいしぜひ皆さんにもおすすめしたい
- Parquetの理解が浅かった･･･
- GlueやAthenaを使ったことなく、今回を気に勉強ができた
Appendix
- S3バケットへのオブジェクト登録でキックされるLambdaの設定を一部手動で変更しました
- 変更箇所：｢Suffixに.csv｣ではなく、｢Prefixにcsv-input/｣
- 変更理由：Athenaのクエリ実行結果が同じバケットにアップロードされ、そのせいでキックされることを防ぐため
- PrefixとSuffixの併用は仕様上不可
