インテージテクノスフィア技術ブログ

株式会社インテージテクノスフィアの社員達がシステム開発や仕事に関する技術情報を随時掲載いたします

【Snowflake】Openflow構築後につまずくCanvas UIとコネクタのフローの見方を整理する

Snowflake Openflowは、外部サービスとのデータ連携をGUI上で構築できるサービスです。
現時点では日本語のUIドキュメントが十分に整備されておらず、環境構築後に画面をどのように見ればよいのか困惑することもあるのでは。
本記事は、そのような方に向けて、OpenflowのCanvas UIや、コネクタの処理フローの見方を整理したものになります。

はじめに

こんにちは。インテージテクノスフィアの藤平です。

Snowflakeのデータ連携サービスとして登場したOpenflow。最近ではSPCS版も公開され、検証やPoCの中でOpenflowに触れる機会が増えてきているのではないでしょうか。
私自身もBYOCの構築を試してみて、コネクタを実際に動かすところまでは到達できました。ただ、その段階での正直な感想は「なんとなく動いたが、よく分からない」でした。

box(非構造化データ)のコネクタの中身。複雑…
まだ公開されて日が浅いこともあり、Snowflakeの公式ドキュメントは構築手順に関する内容までが中心です。
OpenflowのベースとなっているApache NiFiについても、日本語の記事はそれほど多くない印象を受けます。

※2025年12月時点では、OpenflowのCanvas周りに関する日本語の参考資料は公開されておらず、現在整備中との回答をサポートよりいただいています。

そこで本記事では、Apache NiFiの公式ドキュメントを手がかりにしながら、「OpenflowのCanvas上のフローをどう見ればよいのか」に焦点を当てて整理していきたいと思います。

Openflowのコネクタの中身を見て「このフローは何をしているのか」を 大まかに把握できることをゴールとしています。

Openflowとは

Snowflake Openflowは、外部サービスとのデータ連携やイベント駆動型の処理を、GUI上でフローとして構築できるSnowflakeのデータ連携サービスです。
あらかじめ用意されたコネクタを利用することで、コードを書くことなくデータの取得や書き込み処理を構築できます。

コネクタの一部。2026年1月時点で30種類あります。便利!
一方で、Openflowでは処理内容がすべてCanvas上に可視化されるため、処理内容を理解するには、UIの構造や考え方を把握する必要があります。

OpenflowのUIはApache NiFiをベースとしており、UIや概念もApache NiFiとほとんど変わりません。
そのため、NiFiの設計思想を前提に画面を見ることでOpenflowのCanvasが読み取れると考え、Apache NiFiの公式ドキュメントを基に情報を集めてみました。

Apache NiFiのUIはOpenflowとほぼ一緒です

Openflow・Apache NiFiの用語

早速UIを見ていく前に、OpenflowおよびベースとなっているApache NiFiで登場する基本構成と頻出用語を整理しておきます。

用語 概要
FlowFile NiFiにおける単一のデータ単位。以下の2要素で構成され、uuidやファイル名といった標準属性を含む
FlowFile Attributes FlowFileが表すデータに関するメタデータやコンテキストを表す属性(Key, Value)
FlowFile Content FlowFileが表す実データ本体
Processor データ処理の最小単位。データ取得、変換、加工、送信など様々なプロセッサが存在
Relationship 各Processorに0個以上定義され、成功/失敗などFlowFileの処理結果を示す名前が付けられる
Connection 1つ以上のRelationshipで構成。処理結果ごとにルーティング先を分岐可能
Controller Service Processorや他のProcess Groupから参照される共通設定(接続情報や認証情報)
Process Group 複数コンポーネントをまとめたコンテナ

実際にフローを見てみる

以下の画像は、Openflowコネクタの中から一部のフローを抜粋したものです。

Google Sheets コネクタの一部抜粋
Canvas上では、1つ1つの大きな四角がProcessor(処理単位)を表しており、FlowFileはProcessor間をConnection(矢印)に沿って順次受け渡されます。

この画像の例で言うと、

①Google SheetsからデータをFlowFile Contentとして取得
②FlowFile Attributesに挿入先となるテーブル情報を追加
③FlowFileを基にテーブル定義の更新(ALTER TABLE)
④テーブルの初期化(TRUNCATE)
⑤(画面外)テーブルへFlowFile Contentのデータを挿入

という一連の処理が、Processor単位で構成されていることが分かります。

また、いずれかの処理でエラーが発生した場合はfailureのRelationshipを通じて、ログ出力のProcessorにルーティングされる構造になっており、例外処理そのものもフローの1つとして可視化されます。

また、Processorの一連はProcess Groupとしてまとめることができます。つまり、コネクタとはSnowflakeから提供されるあらかじめ構築されたProcess Groupの集合体であり、複数の処理ブロックを組み合わせた完成済みのフローとして提供されていると言えますね。

全てProcess Group。ダブルクリックで中のフローを確認できます

Canvas全体のUI構成

ここまでで、Openflowにおける基本的な用語とフローの考え方を整理してきました。
ここでは、それらを踏まえたうえで、実際のCanvas UIの構成を確認していきます。

OpenflowのCanvas画面

①Component Toolbar
画面上部に並んでいるアイコン群がComponent Toolbarです。 ここから、必要なコンポーネントをドラッグ&ドロップでCanvas上に配置できます。

※コネクタのみの使用で自分でフローを組まない場合は、ほとんど使わないかもしれません。
処理フローは全て以下のコンポーネントとProcessorを繋ぐRelationship、Connectionから構成されるので、アイコンを覚えておくとコネクタの中身が理解しやすくなると思います。

各アイコン一覧

②Status Bar
Component Toolbarの直下に表示されている横長のバーがStatus Barです。 ここでは、Openflow全体の稼働状況をリアルタイムで確認できます。 例えばアクティブなスレッド数、データフロー内に存在するデータ量、エラーの有無などです。

③Navigate Palette
画面左側上部に表示されているのがNavigate Paletteです。 画面操作用のナビゲートでズームイン/アウトやフレーム表示が可能です。

④Operation Palette
Navigate Paletteの下に配置されているのがOperation Paletteです。
ここでは、Canvas上に作成したフローに対して実行・停止、有効化・無効化、設定の表示といった操作を行います。
また、Operation Paletteの内容はCanvas上を右クリックした際に表示されるメニューと同等です。

⑤Global Menu
右上のユーザー名をクリックするとGlobal Menuが表示されます。 ここでは、Canvas上の個々のフロー操作ではなく、Openflow環境全体に関わる操作を行います。

特にフロー共通の設定に関する項目としてはController settingsやParameter contextsがあり、
フローの実行状況や挙動の確認・監視についてはData provenance、Summary、Counter等の画面から行います。

各処理の詳細内容を見るには

Canvas上のProcessorをダブルクリックすると、Processorの設定画面が開きます。
基本情報を設定するSettingsタブ、実行タイミングを制御するSchedulingタブなど複数のタブがありますが、
処理内容を理解するうえで特に重要なのはPropertiesタブです。

「ExecuteSQL」ProcessorのPropertiesタブ

Propertiesタブの設定内容はProcessorの種類によって異なりますが、
そのProcessorがどのような処理を行っているかに関わる情報が定義されています。
コネクタの中身をざっくり把握するだけであれば、まずはPropertiesタブを確認すれば十分だと個人的には思います。

Controller Service

Propertiesタブを確認していると、Snowflakeや外部サービスへの接続情報、認証情報などが 直接は記載されていないことに気付くと思います。
これらの共通設定をまとめて管理しているのがController Serviceです。

ProcessorのPropertiesタブ。DBの接続情報はController Serviceを使用している

Controller ServiceはCanvas上のフローではなく、Global Menu内のController settingsで設定する共通設定を定義するための仕組みです。

Controller Serviceで接続情報や認証情報を一元管理し、複数のProcessorから参照して使い回すことができます。
コネクタを利用する際は、どのController Serviceが参照されているかも併せて確認してみてください。

Controller Serviceの設定画面。ここで認証方法やロール等接続情報を一元管理している

変数:Parameter ContextsとFlowFile Attributes

接続・認証情報はController Serviceが担いますが、
それ以外にもフロー全体で共通して利用する変数をParameter Contextsで定義することができます。

Parameter ContextsはGlobal Menu内のParameter contextsから確認でき、ProcessorやProcess Groupで呼び出す際は#{parameter_name}のように記載します。

Parameter Contextで変数定義するParametersタブ。本来はVALUEに値を記載する

なお、変数はすべてParameter Contextsで管理するわけではなく、
FlowFileごとに動的に変化する値についてはFlowFile Attributesが用いられます。 FlowFile AttributesはFlowFileのメタデータとしてキーバリュー形式で情報を持っていますが、${key_name}という形でPropertiesで呼び出すことで、FlowFile AttributesのValueを利用することができます。

FlowFile Attributesが後続Processorで変数として呼び出されている様子

このように、OpenflowのUIは一見すると要素が多く複雑に見えますが、フロー全体の流れはCanvas上で俯瞰しつつ、処理の詳細は Processorの設定画面や変数定義を追っていくことで、コネクタの中身も段階的に理解できるのではないかと思います。

おわりに

今回はOpenflowの環境構築後に、UI全体やコネクタの処理フローをどのように見ればよいのかに重点を置いて整理しました。

しかしOpenflowはできることが多いだけに、全貌を理解するのにはまだまだ時間がかかりそうです。 既存のコネクタを読み解くだけでもかなり大変なので、0から自力でProcessorを配置して処理フローを組むのはかなりの玄人でないと難しいのではないでしょうか…。

とはいえ、Canvasの見方や基本的な考え方が分かってくると、「何が起きているか分からない」という状態からは一歩抜け出せます。 まずはコネクタを分解して読み解くところから始め、少しずつ理解を積み上げていくのが現実的なアプローチだと感じています。

次はOpenflowの監視、管理周りの検証をしていき、気付いた点や学びを整理しながら情報発信できたらと思います。

参考

Apache NiFi User Guide

全プロセッサー (アルファベット順) | Snowflake Documentation

All controller services (alphabetical) | Snowflake Documentation





🌟インテージテクノスフィアのSnowflake構築・活用ソリューションサービスサイトはこちら

www.intage-technosphere.co.jp