この記事では、ASTERIA WarpからSnowflakeへデータを書き込む場合の連携パターンを整理し、パターン別におすすめの方法をご紹介いたします。
(本記事はASTERIA Warp 製品ブログの記事「SnowflakeとASTERIA Warpのデータ連携パターンを比較する【書き込み編】」をさらに掘り下げた内容となっております。)
Snowflakeと連携する3つのパターン
Snowflakeへデータを書き込む方法はいくつかの軸で分類することができます。
・実現手段
ETLツールを活用するのか、プログラミングをするのか。
・データ量
一度に書き込むデータは、多いのか少ないのか。
・書き込み経路
サーバからSnowflakeへ直接書き込むのか、外部のクラウドストレージを経由して書き込むのか。
それぞれどのパターンを選択すべきかは要件をふまえた検討が必要ですが、ここではASTERIA WarpからSnowflakeへのデータ連携(書き込み)をする場合に候補となる、3つのパターンについてご紹介し、そのうち2つについてはサンプルフローの内容を解説いたします。
-
スモールスタートパターン
一度に書き込むデータ量が少ない場合におすすめの方法です。メリットは、少量のデータに対して素早く動作する点です。一方、大量のデータを書き込む場合には処理時間が長くなるなどの課題もあります。
なお、このパターンは ASTERIA Warp の Core エディションを含むすべてのエディションでお使いいただけます。
-
大量データパターン
一度に書き込むデータ量が多い場合におすすめの方法です。メリットは、大量のデータを書き込む場合でも性能の劣化が少ない点です。一方、処理開始時に多少のオーバーヘッドがあるため少量のデータではスモールスタートパターンより処理に時間がかかる場合があうという点はデメリットになります。
なお、このパターンは EXE コンポーネントを利用するため、ASTERIA Warp Standard エディション以上でお使いいただけます。
-
Snowpipeパターン
継続的にデータを書き込む場合におすすめの方法です。クラウドストレージサービスと組み合わせて利用する必要があるため、設定の難易度が上がる点には注意が必要ですが、すでにクラウドストレージサービスを利用している場合はシステム構成をシンプルにできる可能性があります。
それでは、各パターンについて詳しく見ていきましょう。
1. スモールスタートパターン
Snowflakeアダプターを利用するパターンです。
Snowflakeのほかには次のソフトウェアがあれば利用できます。
・ASTERIA Warp(Coreエディションを含む全てのエディション)
・Snowflakeアダプター
例えば、オンプレミスの共有フォルダにあるCSVファイルを、Snowflakeアダプターを利用してSnowflakeへ書き込む場合は、次のようなステップで実現可能です。
- ASTERIA Warpをセットアップする
- Snowflakeアダプターをセットアップする
- フローを作成し、実行する
ASTERIA Warpのセットアップ方法については、インストールガイドをご参照ください。
Snowflakeアダプターのセットアップ方法については、Snowflakeアダプターの紹介をご参照ください。
ここでは、サンプルフローの内容をご紹介します。
フローの概要は次の通りです。シンプルな「ファイル取得→加工・変換→書き込み」というETLを実現するフローとなっています。
- 連携するデータを取得
- FileGetコンポーネントを使って、Snowflakeへ書き込みたいデータを取得します。
- データを加工・変換
- マッパーを使って、連携データの内容を加工・変換します。Snowflakeにデータを渡す前に、必要なデータの追加や不要なデータの削除が可能です。
- ここではマッパーだけを使った例としていますが、RecordFilterコンポーネントなどを使って必要データだけに絞り込むなどの処理を入れることも可能です。
- Snowflakeへ書き込む
- SnowflakePutコンポーネントを使って、加工後のデータをSnowflakeのテーブルに直接書き込みます。
2. 大容量データパターン
これはSnowflake社が提供しているコマンドライン(CLI)ツール「SnowSQL」をASTERIA Warpと組み合わせて利用する方法です。
Snowflakeのほかには次のソフトウェアがあれば利用できます。
・SnowSQL
・ASTERIA Warp(Standardエディション以上)
例えば、オンプレミスの共有フォルダにある大きなCSVファイルをこの方法でSnowflakeへ書き込む場合は、次のようなステップで実現可能です。
- ASTERIA Warpをセットアップする
- ASTERIA Warpサーバーの中にSnowSQLをセットアップする
- フローを作成し、実行する
ASTERIA Warpのセットアップ方法については、インストールガイドをご参照ください。
SnowSQLのセットアップ方法については、Snowflake社が提供しているドキュメント「SnowSQL(CLIクライアント)」をご参照ください。
ここでは、サンプルフローの内容をご紹介します。
フローの概要は次の通りです。
このフローをスケジュール実行することで、定期的にフォルダ監視をし、ファイルがあったらデータロードを実施するという処理を実現できます。
ここでは、連携するファイルを投入するフォルダ(以下、連携用フォルダ)を1つ決めておき、その連携用フォルダに投入されたファイルをSnowSQLを用いてデータロードする仕組みを想定しています。このとき、SnowSQLを動かすためのコマンドファイルを作成する必要がありますが、その処理もフローの中で実施しています。
- 連携するデータの一覧を取得
- FileListコンポーネントを使って、連携用フォルダ内のファイル一覧を取得します。複数のファイルを投入しても処理することができます。
- ここでは、CSVファイルのみ取得する設定としています。
- SnowSQL用のコマンドを作成(PUT)
- SnowSQLはコマンドラインツールのため、文字によってコマンドを作成する必要があります。ここでは、ファイルをSnowflake側のステージに書き込むためのSnowSQLコマンド(PUT)を組み立てています。
- SnowSQL用のコマンドを作成(COPY INTO)
- ステージにあるファイルをテーブルに書き込むためのSnowSQLコマンド(COPY INTO)を組み立てています。
- COPY INTOコマンドでは、オプション指定でファイルフォーマット等を設定可能です。詳細はSnowflake社のサイトでご確認ください。
- このマッパーでは、上記の処理のほか、次のステップで使うコマンドファイルのファイルパスも生成し、フロー変数に保存しています。
- SnowSQL用のコマンドファイルを書き込む
- 組み立てたSnowSQLコマンドを、ファイルに書き込みます。
- SnowSQLを呼び出してデータロード
- EXEコンポーネントを使って、SnowSQLのコマンドラインツールを呼び出します。その際、先ほど書き込んだSnowSQLコマンドのファイルを使うように指定しています。
- このタイミングで、連携するデータがステージに書き込まれ、さらにそこからテーブルに書き込まれます。
- EXEコンポーネントのファイルパスプロパティは、プロパティ式を使って以下のように設定しています。
ヒントこのサンプルフローでは実装していませんが、ステージに上げたファイルを削除するためのSnowSQLコマンドを追加したり、フローの冒頭で「連携用フォルダのファイルを処理中フォルダに移動する」ような処理を追加すると、より実践的なフローになるでしょう。 |
注意事項SnowSQLを利用する場合、なんらかの理由でファイルをステージにコピーできなかった、ステージからのデータ取り込みが実施されなかった等の問題が発生しても、ASTERIA Warp側のEXEコンポーネントはエラーにはなりません。処理の実施状況を詳細に把握したい場合は、SnowSQLからのレスポンスデータの内容(=EXEコンポーネントの出力ストリーム)をログ出力するなど、処理結果を確認できるような仕組みをフローに追加するとよいでしょう。 |
3. Snowpipeパターン
これは、Snowflake社が提供している「継続的データロード」の仕組みである「Snowpipe」を利用するパターンです。
Snowflakeのほかには次のソフトウェアやサービスがあれば利用できます。
・クラウドストレージサービス
Amazon S3, Google Cloud Storage, Microsoft Azure Blobストレージ等、SnowpipeとASTERIA Warpが対応しているサービスいずれか。Snowpipeが対応しているクラウドストレージサービスの詳細はSnowflake社のサイトでご確認ください。
・ASTERIA Warp(Coreを含む全てのエディション)
・利用するクラウドストレージサービスと連携するためのアダプター
例えば、オンプレミスの共有フォルダを監視し、そのフォルダに作成された大きなCSVファイルを、Amazon S3を経由してSnowpipeを用いてSnowflakeへ書き込む場合は、次のようなステップで実現可能です。
- Amazon S3の環境を用意する
- Snowpipeの設定を実施する
- ASTERIA Warpをセットアップする
- Amazon Web Servicesアダプターをセットアップする
- フローを作成し、実行する
Amazon S3の環境設定やSnowpipeの設定の詳細は、ここでは割愛いたします。各社から提供されているドキュメント等をご参照ください。
フローの概要は次の通りです。Snowpipeによって監視されているAmazon S3のバケットにファイルをアップロードすると、その後はSnowpipeによって自動的にファイルがテーブルへ書き込まれます。
SnowflakePutコンポーネントではなくAWS S3Putコンポーネントを使っている点以外、フローの内容はパターン1と同様ですので詳細な説明は割愛します。
なお、Snowpipeの設定ではAWS側の権限設定なども必要となります。そのため、筆者が検証した限りでは、他の2つの方法と比較して難易度が相対的に高く感じました。そのため、最初はパターン1か2でデータ連携を開始し、必要に応じて後からSnowpipeへ移行するような段階を踏むとスムーズに導入できるのではないかと考えています。
パターンの比較
スモールスタートパターンと大容量データパターンを比較すると、このような違いがあります。
処理時間比較 *1 *2 *3
書き込み処理時間 |
スモールスタートパターン |
大容量データパターン |
1000件(129KB) |
1.6秒 |
4.7秒 |
10万件(13MB) |
31.3秒 |
5.9秒 |
1千万件(1.3GB) |
- *4 |
96.2秒 |
共通
|
スモールスタート パターン |
大容量データパターン |
Snowpipeパターン |
対応エディション |
すべて |
Standard以上 |
すべて |
Snowflakeアダプター |
必要 |
不要 |
不要 |
SnowSQL(CLIツール) |
不要 |
必要 |
不要 |
クラウドストレージとの接続 (AWSアダプター等) |
不要 |
不要 |
必要 |
設定難易度 |
低 |
中 |
高 |
*1 Snowpipeパターンについては処理時間の測定が困難なため、処理時間比較の表には掲載しておりません。
*2 処理時間の数値は一例であり、環境や実施タイミングにより変動します。掲載した数値は筆者のPCにて各項目を5回ずつ処理した際の平均値です。
*3 スモールスタートパターン(Snowflakeアダプター利用)では、SnowflakePutコンポーネントの「バッチ件数」プロパティを10000件に設定して処理を実施しました。
*4 検証を実施した際には、処理開始からおよそ4時間経過した時点でSnowflake側にてセッションタイムアウトが発生し、異常終了となりました。
さいごに
この記事を参考にしていただくことで、皆さまのASTERIA WarpとSnowflakeを使ったデータ活用の推進に貢献することができましたら幸いです。