仕組み

データレイクにデータが入るには、設定と実行の 2 つが必要です。設定はコンソールで一度だけ行います。実行はスナップショットごとに自動で行われます。

この区別が重要なのは、設定が不完全でもパイプラインは正常終了する からです。取り込み対象のデータベースが 1 つも選択されていない場合でも、スナップショットはエクスポートされ、Parquet ファイルは S3 に届き、コピージョブはそれらを黙って無視します。どこにもエラーは出ません。だからこそ、コンソールの概要画面には不足しているものが一覧表示されます。

テーブルがたどる経路

1. AWS がスナップショットを取得
   自動（バックアップウィンドウ）または手動

2. RDS が Parquet でエクスポート
   exported/{cluster}/{export}/pagila/public.payment/1/*.parquet

3. Data Pump が選択されたものを、指定された名前でコピー
   catalog/{cluster}/pagila.pagamentos/*.parquet

4. 設定されたテーブルを再パーティション
   catalog/{cluster}/pagila.pagamentos/ano=2024/mes=03/*.parquet

5. Glue がカタログ化
   SELECT * FROM datalake.pagila_pagamentos WHERE ano = 2024

ステップ 3 と 4 が、お客様の判断が反映される部分です。どのデータベースとテーブルを対象にするか（取り込みの設定）、どう再パーティションするか（パーティション）です。

トリガー

スナップショットが完成すると、RDS はイベントを発行します。Lambda 関数がそれを受け取り、そのクラスターが登録されているかを確認し、登録されていればエクスポートを開始します。エクスポートが完了すると、同じ経路で処理パイプラインが起動します。

Lambda はどちらの場面でも同じもので、イベントの種類で判別します。関係のないイベント（作成開始、コピー、削除）は記録されたうえで無視されます。

パイプライン

同一イメージから起動する Fargate タスクとして、4 つのジョブが順に実行されます。

前回のカタログを削除 — catalog/{cluster}/ は実行ごとに再構築されるため、常にデータベースの現在の状態を反映します。
ファイルをコピー — 選択されたデータベースのみを対象に、テーブルのフィルターと別名を適用します。
再パーティション — 設定済みテーブルごとに 1 タスクを並列実行します。
生のエクスポートを削除 — 任意です。

最後に Glue のクローラーが結果をカタログ化し、後続処理につなげたい場合のために SNS トピックへ通知が発行されます。

S3 上のデータの配置

exported/{cluster}/{export}/{データベース}/{スキーマ}.{テーブル}/{パート}/*.parquet
   └── RDS が生成するもの: スナップショットに含まれるすべて

catalog/{cluster}/{alias}.{テーブル}/*.parquet
   └── Glue がカタログ化するもの: 選択したものだけ

longterm/{cluster}/{alias}/{テーブル}/
   └── ソースデータベースでのパージ後も残る履歴

catalog/ と longterm/ の違いによって、Postgres から古いデータをパージした後でも履歴を保持できます。catalog/ は実行ごとに再作成され、 longterm/ は蓄積されます。

Postgres 側ですでにパーティション化されたテーブル

Postgres でネイティブにパーティション化されたテーブルの場合、RDS は親テーブルと各子パーティションを別々のテーブルとしてエクスポートします。親テーブルにはすでにすべての行が含まれているため、両方をコピーするとデータレイク上で各行が重複します。

Data Pump は名前のパターンではなく、エクスポート自体のメタデータを使って子テーブルを検出し無視します。データベース側で新しいパーティションが作成されても自動で認識され、維持すべきリストはありません。