Snowflakeで分析基盤を作っていると、だいたい壁にぶつかります。「取り込み（ETL/ELT）の入口が増えすぎる」「変換（モデリング）が属人化する」「運用コストが読めない」。この3つ、放っておくと“動くけど育たない”パイプラインになります。
そこで私が落ち着いたのが、**取り込みはSnowflake Openflow、変換はdbt**という役割分担でした。名前だけ聞くと当たり前に見えるんですが、実際にやると“クセ”があり、最初の設計で勝負が決まります。この記事では、現場でハマったポイント込みで「こうしておけばラクになる」をまとめます。
（Snowflake OpenflowはApache NiFiベースの統合サービスで、構造化・非構造化データを含めて多様なソース/宛先をつなげます。デプロイ形態も用意されています。(Snowflake Documentation)）
まず結論：3者の役割分担を固定すると運用が安定する
- Snowflake：保存・計算・ガバナンス（権限、共有、コストの見える化）を担当
- Snowflake Openflow：外部からの取り込み（ファイル、DB、API、ストリーミング等）と“運搬”を担当
- dbt：SQL中心の変換、テスト、ドキュメント化、モデル設計を担当
私の失敗は、最初にSnowflake Openflow側で変換を頑張りすぎたこと。できるんです、加工も。だけど、ビジネスロジックが増えるほど、差分検証や再実行の判断がつらくなる。その役割はdbtに寄せた方が、チームで回すときに強いです。
Snowflake Openflowは「入口の爆発」を止める道具
現場で増えがちなのが、SharePoint、Google Drive、S3、Box、DB、SaaS……と入口が散らばる問題。
Snowflake Openflowはコネクタが用意されていて、たとえばクラウドストレージ系（Google Drive/Box/SharePoint/S3/Azure Blobなど）を含む複数の接続先をまとめて扱えます。(snowflake.com)
私が効いたと感じた使いどころ（体験）
- ファイル系の取り込み：部署ごとにフォルダ運用が違っても、入口を一本化しやすい
- 非構造化の取り込み：ドキュメントを“とりあえず入れて検索・活用”まで持っていきやすい（デモ例も公開されています）(GitHub)
- 運用の見通し：フロー（パイプライン）という単位で整理できるので、事故ったときに原因箇所が追いやすい
dbtは「変換の増殖」を設計に変える道具
Snowflake上での変換をSQLで積み上げるなら、dbtの強みが出ます。特に効いたのはここ。
1) インクリメンタルで“毎日回す”が現実的になる
データ量が増えると「全件作り直し」は破綻します。
dbtはincremental modelで差分更新でき、Snowflake想定の設定例も公式で整理されています。(dbt 開発者ハブ)
私の体感だと、最初から全部をインクリメンタルにしないのがコツでした。まずは重要テーブルだけ。失敗するときはだいたい「unique_keyが曖昧」「更新があるのにinsert前提で作っていた」あたりです。
2) テストとドキュメントが“後からでも追いつく”
変換の正しさって、口頭の引き継ぎが一番弱い。
dbtはテスト・ドキュメント化を“作業の流れ”に組み込みやすいので、属人性が減りました（ここは使った人ほど戻れなくなるやつ）。
連携の基本アーキテクチャ（おすすめの型）
私が今いちばん事故が少ないと思う型はこれです。
- Snowflake Openflowで「Raw層」に取り込む（できるだけ加工しない）
- dbtで「Staging → Mart」へ変換（ビジネスロジックはここ）
- Snowflakeの権限設計はMart基準で公開（Rawは触らせない）
ポイントは、“加工はdbt、取り込みはSnowflake Openflow”を守ること。例外はありますが、例外を増やすと必ず運用が詰まります。
実装で詰まりがちなところ（ここが体験値）
A) ネットワーク/外部接続の許可設計が地味に重い
Snowflake OpenflowのSnowflakeデプロイメントでは、外部接続先を定義する仕組み（EAIやネットワークルール）を使って、コネクタがアクセスできるエンドポイントを制御します。(Snowflake Documentation)
ここ、初回は「つながらない」が普通です。私は“コネクタ設定のミス”だと思って数時間溶かしました。結局、許可リスト側の不足でした。
B) デプロイ形態の選び方で運用負荷が変わる
Snowflake Openflowは、管理された形で動かしつつ、自分のクラウド側で動かす選択肢も提示されています。(Snowflake Documentation)
「とりあえず早く始めたい」なら管理寄り、「ネットワークや統制が厳しい」なら自前寄り、みたいに最初に割り切ると後悔が減ります。
C) “誰が直すか”問題は、責務境界でほぼ解決する
障害が起きたときに揉めるのは、だいたいここです。
- 取り込みの遅延・欠損：Snowflake Openflow側の担当
- 変換結果の不整合：dbt側の担当
- コスト増：Snowflakeのクレジット/実行設計の担当
担当を人で決める前に、**“どの層で起きたらどっち”**を決めておくと、夜間対応が静かになります。
コスト感のリアル：最初に見るべきは“実行頻度”と“再実行のしやすさ”
私が見落としがちだったのは、「たまに動くパイプライン」より「毎日・毎時動くパイプライン」の方が支配的になること。
- Snowflake Openflow：コネクタやフローの実行頻度・データ量で効いてくる
- dbt：フルリフレッシュをやる設計だとすぐ重くなる。incrementalで逃がす(dbt 開発者ハブ)
- Snowflake：ワークロードを分離しないと、他チームの利用とぶつかる
体感としては、“再実行が簡単”な設計に寄せるほど、最終コストが下がることが多いです。トラブル時に小さく戻せるので。
まとめ：3つを同列に比べるより、一本の流れとして設計する
Snowflake / Snowflake Openflow / dbtは、競合というより流れの中の役者です。
私のおすすめは、入口の数をSnowflake Openflowで吸収し、変換の複雑さをdbtで整理し、最後にSnowflakeで運用・共有・統制を効かせること。
最初の1〜2本だけでもこの型で作ってみると、後の増築が驚くほどスムーズになります。
コメント