Iceberg石川覚2024.10.26AWS事業本部コンサルティング部の石川です。INSERTなど一度に100パーティションを超える書き込みができません。ある時、「あれ、100パーティション超えてるやん」って事があり、それをきっかけに、何ができて何ができないのか、悶々と検証した結果、100パーティションの壁を超える方法をご紹介したいと思います。<指定したいカラム名>)とする。<指定したいカラム名>)は、ハッシュに基づき100のパーティションに分類されるため、パーティション内ではスキャンが発生するこの方法を使用すると処理時間が長くなる傾向があり、バーティション数によっては、100パーティションの制限とは異なる理由で、エラーになる可能性があります。https://docs.aws.amazon.com/ja_jp/athena/latest/ug/other-notable-limitations.htmlそして、AWSの公式のワークアラウンド、一度に書き込みするパーティションを100を超えないようにクエリを分割して実行する方法です。AthenaのDBアダプターdbt-athenaでは、100パーティションを超える書き込みがあった場合に分割してクエリを実行するように実装されています。tool)とは、データウェアハウス内のデータ変換を効率化するためのツールです。EngineV3だと100パーティションを超えているのに正常になる。ここが疑問のスタートラインでした。(101,'101')IcebergのBucket機能についてこの後に、パーティション設定に利用するBucket機能について、事前に解説します。Bucket機能は、データのパーティショニングを効率的に行うための重要な機能です。Bucketは、ハッシュ関数を使用してデータを指定された数のバケットに分散させる方法です。Bucketの特長カーディナリティの高いカラムに適しているユニークな値が多いカラムに対して効果的です。データの均等分散ハッシュ関数を使用することで、データを指定された数のバケットに均等に分散させます。適切にバケッティングされたデータは、クエリの実行時間を短縮し、パフォーマンスを向上させます。BY句で簡単に設定できます。以下はbucket関数を使用してテーブルを作成する例です。この例では、idカラムを16のバケットに分散させています。EngineV3で検証を進めます。100パーティション超えでエラーを確認100パーティション超えでエラーになることを確認します。(101,'101');100パーティション超えで、想定通りとエラーになりました。パーティション指定でBucketの数を101、101レコードをINSERTパーティション指定でBucketの数を101に設定します。そのテーブルに101レコードをINSERTします。(101,'101');101レコードをINSERTが成功しました。下記のようにdataフォルダ直下に64のハッシュのフォルダが作成されて、その下にデータが保存されています。検証2のパーティション指定に、パーティションキーdataを追加しました。そのテーブルに101レコードをINSERTします。(101,'101');パーティション指定でBucketのきーと組み合わせても、100パーティション超えエラーになりました。(bucket(101,id),bucket(101,data))も試しましたが同様にエラーでした。パーティション指定でBucketの数を201、201レコードをINSERT検証2が成功したので、パーティション指定でBucketの数を201に設定します。そのテーブルに201レコードをINSERTします。(201,'201');検証2と境界は同じはずなのですが、エラーになりました。どこまでレコード数を減らせばできるのか?、、、試してみました。131レコードの時点で成功しました。なんか、中途半端なレコード数です。下記のようにdataフォルダ直下に100のハッシュのフォルダが作成されて、その下にデータが保存されています。このあたり関連があるのかもしれませんね。パーティション指定でBucketの数を100、201レコードをINSERT検証1から検証4までの結果、わかったことをまとめます。bucketの指定は201でもエラーにならないため、テーブル作成の段階では問題にならないbucketの指定したテーブルに対して、100のハッシュフォルダまでデータをINSERTできた上記の結果から、以下の仮説を立てたbucketの指定は100(正確には100以内)にすることで、100より多いハッシュフォルダが作成させるリスクを回避できるよって、検証5では、bucketの指定は100のテーブルに対して、201レコードをINSERTできるかを確認する。(201,'201');201パーティションのレコードをINSERTが成功、101パーティションの壁を超えられました。下記のようにdataフォルダ直下に84のハッシュフォルダが作成されていました。上記のINSERTを数回実行したところ、同じハッシュフォルダの下にファイルが追加されるのではなく、ハッシュフォルダが追加されていました。メタデータのファイル(.metadata.json)のファイルサイズが大きくなるのが気になります。クエリは成功しました。クエリは成功しました。Icebergテーブルで100パーティションの壁を超える方法として、以下のことが明らかになりました。パーティション指定でBucketの数を100に設定することで、100を超えるパーティションを持つデータの挿入が可能になります。この方法を使用することで、201レコードのような100パーティションを超えるデータの挿入に成功しました。この方法を使用すると処理時間が長くなる傾向があります。検証5では201レコードの挿入に14.594秒かかりました。データはS3上で複数のハッシュフォルダに分散して保存されます。これにより、メタデータファイルのサイズが大きくなる可能性があります。今後の課題として、OPTIMIZEやVACUUMの実行によるデータのコンパクション効果の検証が必要です。Athenaの100パーティション制限を回避できますが、パフォーマンスとストレージ効率のトレードオフを考慮する必要があります。実際の使用時には、データ量やクエリパターンに応じて適切に設計することが重要です。