こんにちは
sigma computing社のサービス「sigma」に最近注目しています！
まだドキュメントや事例の読込も浅いのですが、今回は注目機能のひとつである「WriteBack」の挙動を実際見てみたので紹介します。
とりあえず試してみたい方のための準備についても紹介いたします。
WriteBackに関する概要は以下のブログで解説しているので合わせてご参照ください
それでは見ていきましょう！
結論
簡易な検証でしたがわかったこととしては以下となります。
- できること
読み込み元のテーブルを参照して変更した結果を別テーブルに保存する。
現時点ではカラムの追加と値の変更ができるので、雑感としてはSQLでいうAlterやUpdateはできるけどInsertはできない。といった印象。 - できないこと
読み込み元のテーブルの数値を上書き更新する行為。
参照したテーブルをユーザーが更新できてしまったらヤバそうだけどコントロールできれば非効率な作業を解決できるのでは…？と期待して調べ始めたのですが、なるほどやっぱり。だけどもっと色々試したい！という感想に至りました。きっとこの機能が輝くシーンがあると思っています。
現時点ではシミュレーションダッシュボードとかのデータソースにWriteBack先のテーブルを指定するとか面白いかもしれないです。
必要な準備
-
snowflake側
WriteBack専用のSchemaが必要です。
既存DB配下でも新規でもOK
sigmaのConnectionsで指定したUserにテーブルCreateの権限は必須。 -
sigma側
コネクション設定ではWrite accsessがEnableであること。
snowflakeの上記設定ができているとEnableにできるようになります。
挙動確認
sigmaの読み込んだデータに列と計算式を追加してみる
sigmaワークブック上でDataから対象テーブルを選択し、列をいじってみます
snowflake側ではWriteBack関連のテーブルには変化なし。
sigmaのワークブック内での出来事に止まっているように見える。
sigmaのLinked input table[1]に列を加えて値を入れてみる
こんどはWriteback可能なデータを読み込んでいじってみます
- sigma側
- snowflake側
自動生成されたテーブルに上記の変更内容がレコードとして登録されました
snowflakeのどこに書き込まれるのか
sigmaで設定したWrite schema配下に
"SIGDS_"から始まるテーブルに変更内容が、
"SIGDS_WAL[2]_"から始まるテーブルに変更履歴が
それぞれテーブルが自動生成され記録されました。
ちなみに…検証後の調査で判明したのですが、WALは非推奨となったようで現在はAuditlogで変更管理は行う方針としているようです ※2025年8月15日update
まとめ
今回は最短で機能に触れてみた形だったため、簡易な内容でしたが挙動がみれたことで機能への理解を深めることができました。
ビジネスシーンでの使いどころを探るべくもっと深く触っていきたいと思います！
それではまた。
-
Linked input tableについてはこちら
https://zenn.dev/truestar/articles/32ccd6e36d72b6 ↩︎ -
WAL（Write‑Ahead Log）
Sigmaの入力テーブルに対するユーザー操作やシステム処理が記録される変更履歴の逐次ログ。 ↩︎