皆さんこんにちは！ インサイトテクノロジー 宮地です。
最近、じめじめムシムシ暑い日が続いていますが、皆さん元気にお過ごしでしょうか。
医学的には体を冷やす食べ物や飲み物はおすすめではないようですが、ついついランチはそっち系に走りがちになってしまいます。
最近のマイブームは、半田そうめん！！
そうめんとうどんのいいとこどりな感じの麺でおすすめです。
さて、Snowflakeから興味深い新機能がリリースされているので、今回はこちらを紹介させてもらいたいと思います。
1. Dynamic Tables *preview
https://docs.snowflake.com/user-guide/dynamic-tables-about
Dynamic tables are the building blocks of declarative data transformation pipelines. They significantly simplify data engineering in Snowflake and provide a reliable, cost-effective, and automated way to transform your data for consumption. Instead of defining data transformation steps as a series of tasks and having to monitor dependencies and scheduling, you can simply define the end state of the transformation using dynamic tables and leave the complex pipeline management to Snowflake.
ダイナミックテーブルは宣言型データ変換パイプラインの構成要素です。
Snowflakeのデータエンジニアリングを大幅に簡素化し、信頼性、コスト効率、自動化されたデータ変換方法を提供します。
データ変換ステップを一連のタスクとして定義し、依存関係とスケジューリングを監視する代わりに、ダイナミックテーブルを使用して変換の最終状態を定義するだけで、複雑なパイプライン管理をSnowflakeに任せることができます。
という説明がありますが、ざっくりと「マテリアライズドビュー的なもの」と言えるのではないかと考えています。
ただ、マテリアライズドビューではないので、当然違いはあります。
以下で特徴を比較してみました。
■マテリアライズドビュー
・単一テーブルからのみ作成可能
・マテリアライズドビューはクエリできない
・自動クエリリライトの対象
・ベース表に入った更新は即座に反映される（参照可能）
■ダイナミックテーブル
・複数テーブルから作成可能
・既存のダイナミックテーブルもソースとして利用可能
・自動クエリリライトの対象とはならない
・ベース表に入った更新はTARGET_LAGに指定した時間が経たないと参照できない
詳細は、下記リンクを参照してください。
■Dynamic Tables Compared to Materialized Views
https://docs.snowflake.com/en/user-guide/dynamic-tables-comparison
それでは実際にこの新機能を試してみましょう！
① ステップ1：ダイナミックテーブル作成
CREATE OR REPLACE DYNAMIC TABLE orders_merge
TARGET_LAG = '1 minute'
WAREHOUSE = QLIK_WH
as
select a.order_id,a.order_date,sum(nvl(b.unit_price*quantity,0))
from orders a
left outer join order_items b
on a.order_id = b.order_id
group by a.order_id,a.order_date;
はい、こんな感じでダイナミックテーブルの作成完了です。
イメージとしては、create viewするときと似ていますね。
② ステップ2：確認
show dynamic tables;
はい、こんな感じで、確認できます。
target_lag、refresh_modeの情報と合わせて、rows、bytesの情報も表示されています。
（作成時に初期リフレッシュが行なわれている模様です。）
実際のデータがどうなっているか見てみましょう。
select * from public.orders_merge;
③ ステップ3：ベース表のデータ更新
delete from soe.order_items where order_id = 418789;
commit;
ベース表のデータを削除してみました。
※削除後、target_lagに指定した時間を待ちます。
④ ステップ4：確認
select * from public.orders_merge where oid = 418789;
外部結合側のレコードが削除されたので、SUMPRICEがNULLとなっています。
ベース表を更新した後、target_lagに指定の時間が経過後、自動で反映されていることの確認が取れました！
余談ですが、ダイナミックテーブルのユーザからの操作は、データの参照しか行えません。
delete、insertを直接実行しようとすると、下記のようにエラーとなります。
ここまでの流れで、比較的簡単な作成と利用が可能なことが分かりました。
ダイナミックテーブルの使いどころですが、これまでマテリアライズドビューではできなかった
・複数テーブルを結合してレポーティング用のデータを作成
→ これまでビューで耐えていた方には朗報かと！
・データパイプラインチックに、ダイナミックテーブルを経由して最終データを生成
など、完全なETLパイプラインの代わりにはならないかもしれないですが、簡易的なパイプラインとしては十分使えるのではないかと考えています。
（これからもう少し触り倒して特性/制限事項の確認が必要です。）
もうひとつ、Snowflakeの機能を軽く紹介します。
2. Amazon S3-compatible Storage *GA
https://docs.snowflake.com/en/user-guide/data-load-s3-compatible-storage
こちらは、「Amazon S3互換ストレージがSnowflakeの外部ステージとして利用可能となる」という機能です。
Amazon S3互換ストレージの実環境が用意できていないため、動作確認は取れていないですが、
・ストレージコストを抑えたい
・自社のプライベートクラウド上のAmazon S3互換ストレージを使いたい
といった要望に応えられるのではないかと。
こちらは別の機会にAmazon S3互換ストレージを用意して、いろいろと試した結果をご報告できればと考えています。
今回はココまでとなります。
ではまた次回、よろしくお願いします！
皆様も夏バテせず、この暑い夏を乗り切りましょう。（今年はちょっと冷夏になることを個人的には期待・・・）
