【資料公開】Iceberg で Amazon Athena をデータウェアハウスぽく使おう #midosuji_tech
2024.06.19データアナリティクス事業本部インテグレーション部機械学習チーム・新納（にいの）です。
2024/6/12にクラスメソッド大阪オフィスで開催された勉強会、Midosuji Techにて「Iceberg で Amazon Athena をデータウェアハウスぽく使おう」というタイトルで登壇をしました。ご参加いただいた皆様、ありがとうございました！ワイワイガヤガヤタイムでもたくさんのご質問をいただき、楽しい時間を過ごすことができました！
本エントリでは登壇資料と内容のまとめをお届けします。
スライド
内容まとめ
Icebergの概要と、その特徴の中から特にSchema Evolutionとパーティション管理の便利さをお話ししました。
テーブルフォーマットとは
Icebergはテーブルフォーマットのひとつです。テーブルフォーマットについて順を追って説明します。
データレイクはデータファイルをストレージサービスに配置し、コンピュートがデータ取得と処理を実施します。CSVやJSONといったファイルをデータとして読み込むと、コンピュートからのデータアクセスの効率は決してよくありません。
そこで、Avro・Parquet・ORCなどといった処理効率の良いファイル形式が登場します。例えば、データ分析の文脈でよく使われるParquetは列方向にデータが連続する列指向フォーマットであり、カラムごとにデータを抽出する分析用途では処理効率がよくなります。
処理効率の良いファイル形式を利用しても、結局のところ、ファイルそのものへのアクセスをしているので様々な制約があります。そこで登場するのが、こうしたファイルを管理する仕組みであるテーブルフォーマットです。ユーザーやコンピュートはテーブルフォーマットを介してデータファイルにアクセスすることで、テーブルフォーマットが提供している管理機能が利用できるようになります。
Icebergとは
改めて、Icebergとはデータウェアハウスのように使える機能が提供されているテーブルフォーマットの一種です。従来のテーブルフォーマットと異なり、データファイルとそれに紐づいたメタデータファイルを管理することにより、UPDATE/DELETE/MERGEといったデータ編集、ACIDトランザクションサポート、タイムトラベル昨日、より精度の高いパーティショニングができるようになりました。
Icebergの数ある便利ポイントの中でも、今回はスキーマとパーティションを中心にお話ししました。
Schema Evolution
時間の経過や分析要件の変化により、当初定義したスキーマから変更が必要になるケースがあります。そこで、既存のデータを保持し、古いスキーマとの互換性を維持しつつ、システムのスキーマを変更するプロセスをSchema Evolutionと呼びます。
IcebergではこのSchema Evolutionを実現可能です。メタデータファイルを更新することでスキーマ変更ができるため、テーブル再作成やデータの再ロードといったプロセスが不要となります。
パーティション管理
クエリパターンの変化により、パーティションを変更するPartition Evolutionが必要になるケースがあります。Iceberg自体はパーティション変更のクエリをサポートしており、Partition Evolutionを実現できますが、Amazon Athenaではパーティション関連のDDL（ADD・REPLACEなど）がサポートされていません。（2024年6月現在）
カラムの値を関数で変換し、パーティション値を生成するHidden Partitionという便利機能はAthenaからも利用可能です。わざわざパーティション用のカラムを事前に生成しておく必要がなく、bucket関数ではハッシュによるパーティションキーの計算も設定だけで簡単に実施できます。
さいごに
Icebergをデータウェアハウスぽく使おうという登壇まとめでした。IcebergとAthenaはデータウェアハウスぽく使えはするものの、Redshiftなどの完全なる代替とはなりません。データウェアハウスのほうがコストは掛かっても便利に使えるケースがあるため、例えばBIから参照するデータマート用などの適しているユースケースで採用すると上手く使えそうです。
同じイベントでAthenaとStep Functionsを使ったETLオーケストレーションについても紹介されていましたので、こちらもご参照ください。
【資料公開】AthenaとStep Functionsで簡単ETLオーケストレーション #midosuji_tech | DevelopersIO
