SnowflakeのGET_OBJECT_REFERENCES関数を物理テーブル化するPROCEDUREをつくる

今回はSnowflakeの超便利関数「GET_OBJECT_REFERENCES」を物理テーブル化するPROCEDUREを作ってみました。

今回は前回投稿した記事、「PythonでSnowflakeのGET_OBJECT_REFERENCES関数を物理テーブル化する」の続きという位置づけですので、ぜひこちらもご覧ください🙇

（GET_OBJECT_REFERENCES関数については以前の記事で紹介しております。）

前回のおさらい

前回はPythonでGET_OBJECT_REFERENCES関数を物理テーブル化していきました。

今回も、前回作成したテーブルと同じものを作ります。

今回使用するデータも前回と同じです。

• TEST_A/B
  • テーブル
• TEST_C
  • TEST_Aを参照するビュー
• TEST_D
  • TEST_Bを参照するビュー
• TEST_E
  • TEST_C/Dを参照するビュー

物理化してみた

今回作成したPROCEDUREは以下になります。

処理の流れをブロックごとに記載していきます。

1. show viewsコマンドでviewの一覧を取得し、ループさせてGET_OBJECT_REFERENCES関数を実行する

ここまでは前回のPythonで実装した処理と同じです。

2. 結果をループさせて連想配列化し、配列にpush

同じkeyの連想配列を格納した配列が出来上がります。

3. 2の配列の中の連想配列をJSON化し、Snowflakeでtempテーブル化

SnowflakeはJSON等の半構造化データをサポートしています。（詳しくはこちら）

tempテーブルを確認してみます。

問題なく作成されています。

4. 3のtempテーブルをフラット化し、GET_OBJECT_REFERENCES関数の結果と同じ構造のテーブルを作成

flatten関数を使用することで、半構造化データを構造化しています。（詳しくはこちら）

ちなみに、flatten関数を使用した結果をそのまま出力すると以下になります。

配列の要素ごとにレコード化されていますね。

select句で「value:キー名」と指定して、値を取り出すことができます。

それでは実行結果を確認してみましょう。

しっかり物理化されています！👏

実行時間

ひとつ課題点としては、当然ですがViewの数が多いと実行時間が増えてしまいます。

業務で試した際、View数107で約1分かかりました。

Pythonで実装したものも同じくらい時間がかかるので、おそらく全View分のGET_OBJECT_REFERENCES関数を実行するところがネックになっていると思われます。

おわりに

いかがだったでしょうか。

PROCEDUREで実装するときに、Python用コネクタAPIの「executemany」メソッドにあたるものが見つからなったため、違うロジックで実装してみました。

噂によると、依存関係を一括して取得できるようになるという発表がSnowdayであったそうです！これは朗報ですね。

最後まで読んでいただき、ありがとうございます！🙇