目次
はじめに
こんにちは、omkです。
Glueジョブでパーティションを追加する際にクローラーを利用せずにテーブルに反映するやつを検証しています。
その際に気になったのが更新時に実質的にクローリングされているかどうかというところです。
データの書き込み範囲のみの更新であればケースによっては利用中のクローラーを完全に廃止することは出来ないと考えているため本検証を行うこととなりました。
以下のページに記載の内容に関する検証です。
https://docs.aws.amazon.com/ja_jp/glue/latest/dg/update-from-job.html
前提
- クローラーは利用しない
- Glue4.0でPython3、Spark3.3を利用
- Glueジョブ中にglueContext.write_dynamic_frame_from_catalog()でparquet形式で出力する際にパーティションを更新する
- 既存のパーティションを削除してから実行して、パーティションが更新される範囲が書き込むデータの範囲だけであるかそれ以外も更新されるかを確認する
検証
次のテーブルを用意しました。
| date | name | comment |
|---|---|---|
| 20221031 | hoge | hogehoge |
| 20221101 | fuga | fugafuga |
| 20221115 | piyo | piyopiyo |
「date」をパーティションとして設定します。
このテーブルに対してS3から既存のパーティションを削除して、新規に次のデータを追加します。
| date | name | comment |
|---|---|---|
| 20221214 | moga | mogamoga |
データの更新範囲が書き込むデータ分のみであればテーブルの過去分のパーティションは更新されず残ることになり、
全体を読み込みなおすのであればパーティションは追加したデータのみとなる想定です。
S3からデータを消しましたがテーブルのパーティションは変わらず残ります。
では、ジョブを実行します。
ジョブの実行が完了したらテーブルのパーティションを確認します。
削除したパーティションは残ったままですので更新範囲は書き込むデータ分のみということがわかりました。
ということでパーティションの削除が発生するテーブルにおいては完全にクローラーの代替として利用出来るわけではなく、
削除されたパーティションを反映するためには依然としてクローラーが必要であるように思われます。
※補足ですが、glueContext.purge_table()でデータを消せばテーブルのパーティションも合わせて削除されます。
おわり
アーキテクト課のomkです。
AWSについて雑多に取り組んだ内容を発信しています！！