Thrive Learningが動的テーブルの更新費用を削減

Snowflakeは、Thrive Learningが動的テーブルのカスタム増分化で更新費用と遅延を抑えた事例を紹介しました。

要点

• Thrive Learningは、学習プラットフォームの顧客向け分析とAI機能を支えるデータパイプラインにSnowflakeの動的テーブルを使っています。
• 複雑な結合と重複排除により増えていた全更新、分割レーン、オートクラスタリング費用を、カスタム増分化で差分処理へ寄せました。
• 公式記事では、オートクラスタリングが約150 credits/dayから約2 credits/dayへ、変換コンピュートが約150 credits/dayから約5 credits/dayへ下がった社内計測結果が示されています。

今回のブログ記事で語られていること

今回のSnowflakeブログは、動的テーブルの新機能そのものを紹介するだけでなく、実際の分析プロダクトでどのように費用と鮮度のトレードオフを解いたかを、Thrive Learningのデータエンジニアリング事例として説明しています。Thrive Learningは英国の企業向け学習プラットフォームで、製造、航空、小売など500を超えるB2Bテナントにサービスを提供しています。同社のAnalyse suiteは顧客が学習データを探索するための中核機能であり、最近ではそのデータ基盤の上にAIを重ねた有料アドオンも展開しています。つまり、データ更新の遅延や費用は社内BIだけの問題ではなく、顧客体験、商談時の競争力、AI機能の土台に直結します。

問題になったのは、RecordStoreと呼ばれる主要パイプラインです。当初は動的テーブルらしい自動更新の差分処理で動いていましたが、上流で安定していないIDを補うために複数ソースを結合し、重複排除を加えたことで、Snowflakeが増分更新を続けられず全更新へ落ちました。Thriveは変換費用を下げるため、最近のデータを6時間ごとに更新する高頻度レーンと、古いデータを週次更新する低頻度レーンに分けました。しかし最後に二つのレーンをUNIONする構成がオートクラスタリング費用を押し上げ、変換費用とクラスタリング費用の間で別の負担を抱える形になりました。

カスタム増分化では、REFRESH_MODE = CUSTOM_INCREMENTAL、REFRESH USING、MERGE INTO SELF、CHANGES()を使い、どの差分を処理し、どのように自分自身へマージするかを明示できます。Thriveは、Streams and Tasksで得たい実行モデルに近い差分処理を実現しながら、スケジューリング、再実行、トランザクション保証、遅延の管理をSnowflake側に残しました。さらに、変換管理を dbt で行っているため、手作りのStreams and Tasksへ外出しすると dbt DAG 上のリネージが切れる懸念がありました。今回の実装では独自の dbt materialization で動的テーブルを dbt プロジェクト内のノードとして扱い、テスト、ドキュメント、リネージを同じ運用に保っています。

今回のブログ記事が関係する人

Snowflakeの動的テーブルを使うデータエンジニア、dbt で変換リネージを管理する分析基盤チーム、AI機能や顧客向け分析のために低遅延な更新を求めるプロダクト担当に関係します。特に、結合や重複排除のために動的テーブルが全更新へ落ちたり、分割テーブルとUNIONで費用を抑えようとして別の運用負担が増えたりしている環境では、参考にしやすい内容です。

結局、今回のブログ記事をどう読むべきか

この事例は、動的テーブルのカスタム増分化を「速くなる新機能」とだけ見るより、差分処理、更新遅延、dbt リネージ、オートクラスタリング費用を同時に扱う設計手段として読むほうが実務的です。導入側は、どのテーブルが全更新へ落ちているか、差分の定義を安全に書けるか、マージ後の正しさをどう検証するか、dbt や監視の既存運用に収まるかを確認しておくとよいです。