PDTのリーパープロセスについて

[Sae]

日本語で情報が少ないトピックの記事を翻訳しています。

今回はLookerで古いPDTをスクラッチスキーマから削除するリーパーというプロセスについて紹介します。

この記事はこちらの英語バージョンの日本語訳です。

元の記事の最終情報更新日時：2019 年 12月 12日

リーパーの役割：

リーパーの役割は、非アクティブな PDTをDBのスクラッチスキーマから削除することです。

動作スケジュール：

リジェネレーターとは異なり、すべてのConnectionに対して合計 1 つのリーパースレッドしかありません。 クラスターインスタンスの場合、リーパースレッドはマスターノードで動作します。接続設定のPDT And Datagroup Maintenance Scheduleセクションで設定されたcronに対して、最頻で 1 時間ごとに動作します。

プロセス：

LookerはLookerのinternal DBのactive_derived_tablesテーブルを使用して、どのテーブルをスクラッチスキーマからdropするべきか判断します。リーパーはテーブルを実際にdropする前に、まずactive_derived_tablesテーブルを更新します。

1. active_derived_tablesテーブルを更新する

   • リーパーはまず初めに、本番環境で構築された LookMLで使用されているすべての派生テーブルのリストを取得し、そのリストになかったテーブルのレコードをactive_derived_tablesテーブルから削除します。

   • 次にリーパーは現在スクラッチスキーマに存在するすべてのテーブルのリストを取得し、そのリストになかったテーブルのレコードをactive_derived_tablesテーブルから削除します。

   • 次にリーパーは、 persist_forで永続化されている PDTのうち有効期限切れになったPDTのレコードを、active_derived_tablesテーブルから削除します。

   • 上記のステップが終わると、active_derived_tablesテーブルは、スクラッチスキーマに存在するアクティブなテーブルを反映した状態になります。

   • 更新された状態のactive_derived_tablesテーブルは、スクラッチスキーマ上に存在する全てのアクティブなテーブルのリストを含んでいます。なお注意点として、スクラッチスキーマ上に存在すべきテーブルが何らかの理由で存在しない場合（まだ構築されていないテーブル、ユーザーやエラーによって削除されたテーブルなど）は含まれません。

   • active_derived_tablesが更新された後、リーパーはテーブルをdropする処理に移ります。

2. reg_keyをチェックしてテーブルをdropする

   • リーパーはまず初めに、スクラッチスキーマの全てのテーブルに対して、reg_keyが有効かどうか確認します。reg_keyとは、テーブル名の中のLX$に続く2文字で、X部分はCまたはRの値が入ります。スクラッチスキーマのconnection_reg_r3テーブルに有効なreg_keyのリストがあります。

   • reg_keyが有効な場合

     1. active_derived_tablesテーブルにレコードがある場合、テーブルはdropされません。

     2. active_derived_tablesテーブルにレコードがない場合、テーブルはdropされます。

   • reg_keyが無効な場合、リーパーはreg_keyがconnection_reg_r3テーブルに存在するかどうか確認します。

     1. connection_reg_r3テーブルにreg_keyに対応するレコードがある場合、テーブルはdropされません。

     2. connection_reg_r3テーブルにreg_keyに対応するレコードがない場合、テーブルはdropされます。

Enemy Reaping：

通常、リーパーは、リーパーが動作しているLookerインスタンスのテーブルのみに動作します。PDT テーブル名に含まれるインスタンスハッシュに基づいて、PDT が属するインスタンスを識別しています。

2 つのインスタンスが同じインスタンスハッシュを持つ稀な状況が発生した場合、1 つのインスタンスのリーパーが別のインスタンスのアクティブな PDT に動作してしまいす。これはEnemy Reapingと呼ばれており問題を引き起こす可能性があります。