パーティション

テーブルをパーティション化すると 2 つの効果があります。Athena が読み取る量が減り、データベースにはもう存在しない履歴をデータレイクに保持できるようになります。

ここで何も設定しなければ、すべてのテーブルはそのままコピーされます。テーブルが大きくなるまではこれで十分に機能します。

パーティション化する理由

年と月でパーティション化されたテーブルは、S3 上でディレクトリになります。

catalog/{cluster}/vendas.pagamentos/ano=2024/mes=03/*.parquet

クエリに WHERE ano = 2024 AND mes = 3 があると、Athena は そのディレクトリだけ を読み取ります。パーティションがなければテーブル全体を読み取り、その分の課金が発生します。

Partições（パーティション）で、クラスター、データベース、テーブルを選んで設定を作成します。次にパーティションカラムを定義します。値を計算する式と、結果として生成されるカラム名です。

year(CAST(payment_date AS TIMESTAMP))   →   ano
month(CAST(payment_date AS TIMESTAMP))  →   mes

順序が重要です。粗い単位から細かい単位へ。月より前に年、日より前に月です。

値の組み合わせごとにディレクトリが 1 つ作られ、ディレクトリが多すぎると書き込みが遅くなり、ジョブのメモリを使い果たすおそれがあります。

Data Pump は利用可能なメモリとテーブルの幅から、収まるディレクトリ数を自動で計算します。40 カラムのテーブルは、3 カラムのテーブルよりはるかに少ないディレクトリしか扱えません。上限を超える場合は、失敗する代わりにバッチに分けて書き込みます。

とはいえ、意図をもって選ぶ価値はあります。数年分の履歴があるテーブルを日単位でパーティション化すると数千のディレクトリが生成されますが、クエリがその粒度を必要とすることはまれです。年と月で十分な場合がほとんどです。

ソート用のフィールドはありますが、コストが高くつきます。最初の 1 行を書き込む前に、テーブル全体をソートする必要があるためです。Parquet はブロックごとの最小値と最大値をすでに保持しているため、ソートがなくても Athena は十分に絞り込めます。理由が明確な場合にのみ使用してください。

デフォルトでは、パーティション化されたテーブルはデータレイクに 2 回 現れます。テーブル全体のコピーと、パーティション化されたバージョンが並びます。これは意図的な動作で、移行中に両者を比較できるようにするためです。

パーティション化されたものだけが必要になったら、直接コピーを置き換える を有効にします。

長期履歴を保持する を有効にすると、そのテーブルは実行ごとに消去されない領域に書き込まれるようになります。

これにより Postgres から古いデータを失わずにパージできます。 データベースから外れた月も、データレイクでは引き続き検索できます。catalog/ は現在のデータベースを反映し、longterm/ は蓄積します。

実行ごとに再書き込みされるのは、そのエクスポートに含まれるパーティションだけです。データベースからもう届かないものはそのまま残ります。

履歴の保持だけでも、行が作られた後は変わらないトランザクションテーブルには十分です。しかし、取り込み済みの行がデータベース側で修正された場合、古いバージョンがデータレイクに残ります。しかもその行は、もうエクスポートに含まれないパーティションにあるかもしれません。

変更された行を更新する を有効にし、次を指定します。

キーカラム — どの行を置き換えるかを判別するために行を識別します
変更を判別する条件 — 前回の取り込み以降に変更された行をエクスポートから選択する条件です（例: updated_at > current_date - 7）

Data Pump は該当する行を含むファイルを特定し、古いバージョンを新しいものに差し替えます。

各置き換えの前に、直前の状態が longterm/overrides/{export}/ に保存されます。 これは何が置き換えられたかを示す唯一の記録です。置き換えが誤っていた場合は、そこから復元します。同じエクスポートを再処理しても、この記録は上書きされません。

同じエクスポートを 2 回実行しても安全です。書き込みは再書き込み前にパーティションを削除し、置き換えはキーカラムで突き合わせます。結果は 1 回だけ実行した場合と同じです。