今回はSnowflakeの超便利関数「GET_OBJECT_REFERENCES」を物理テーブル化するPROCEDUREを作ってみました。
今回は前回投稿した記事、「PythonでSnowflakeのGET_OBJECT_REFERENCES関数を物理テーブル化する」の続きという位置づけですので、ぜひこちらもご覧ください🙇
（GET_OBJECT_REFERENCES関数については以前の記事で紹介しております。）
前回はPythonでGET_OBJECT_REFERENCES関数を物理テーブル化していきました。
今回も、前回作成したテーブルと同じものを作ります。
今回使用するデータも前回と同じです。
今回作成した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であったそうです！これは朗報ですね。
最後まで読んでいただき、ありがとうございます！🙇