【初心者向け】Dataflowとは？大量データを加工・転送するGoogle Cloudのサービスをやさしく解説

pgse

7時間前

【初心者向け】Dataflowとは？大量データを加工・転送するGoogle Cloudのサービスをやさしく解説

Google Cloudを使ったシステム開発やデータ分析の業務では、Dataflow（データフロー）というサービスを目にすることがあります。

「Dataflowは何をするサービスなの？」
「BigQueryとは何が違うの？」
「バッチ処理とストリーミング処理って何？」
「Pub/Subとはどのように連携するの？」

このような疑問を持つIT業務初心者の方は少なくありません。

Dataflowは、さまざまな場所からデータを読み込み、必要な形へ加工して、別のサービスへ渡すためのGoogle Cloudのデータ処理サービスです。

大量のファイルをまとめて処理するバッチ処理と、次々に届くデータを継続的に処理するストリーミング処理の両方に対応しています。

この記事では、Dataflowの基本的な仕組み、データパイプラインの意味、実際の業務での使われ方、BigQueryやPub/Subとの違いを、IT業務に従事する初心者向けに分かりやすく解説します。

Dataflowとは？
Dataflowを一言で表すと？
データパイプラインとは？
Dataflowの基本的な処理の流れ
1. 1．データを読み込む
2. 2．データを変換する
3. 3．データを書き込む
Dataflowで処理できるデータの例
バッチ処理とは？
ストリーミング処理とは？
バッチ処理とストリーミング処理の違い
実際の業務ではどのように使われる？
1. Cloud StorageのCSVをBigQueryへ登録する
2. アクセスログをリアルタイムに集計する
3. IoT機器のデータを処理する
4. 機械学習用のデータを準備する
ETLとは？
ELTとは？
Apache Beamとは？
DataflowとApache Beamの違い
Dataflowではどのプログラミング言語を使う？
Dataflowジョブとは？
バッチジョブとストリーミングジョブの違い
ワーカーとは？
自動スケーリングとは？
Dataflowテンプレートとは？
Google提供テンプレートとは？
Flex Templateとは？
DataflowとPub/Subの関係
DataflowとBigQueryの関係
DataflowとCloud Storageの関係
DataflowとCloud Runの違い
DataflowとDataprocの違い
DataflowとCloud Data Fusionの違い
ウィンドウとは？
固定ウィンドウとは？
スライディングウィンドウとは？
セッションウィンドウとは？
ウォーターマークとは？
トリガーとは？
Dataflowの監視
Dataflowで発生しやすい問題
1. 入力データの形式が想定と違う
2. サービスアカウントの権限が不足している
3. 一部のデータだけ処理に失敗する
4. データ量が多く処理が遅れる
5. 書き込み先の設定が間違っている
デッドレターとは？
Dataflowのアクセス権限
サービスアカウントとは？
Dataflowの料金はどのように決まる？
Dataflowの料金が高くなりやすい例
Dataflowのコストを抑える基本
1. 不要なデータを早い段階で除外する
2. 適切なワーカー設定を利用する
3. 自動スケーリングを検討する
4. ジョブを停止し忘れない
5. リージョンをそろえる
6. 予算とアラートを設定する
Dataflowを利用するメリット
Dataflowを利用するときの注意点
1. 小さな処理には構成が複雑になる場合がある
2. Apache Beamの知識が必要になる
3. ストリーミング処理は設計が難しい
4. エラー処理を事前に考える
5. 料金を継続的に確認する
6. ロケーションを確認する
初心者がDataflowを学ぶ順番
初心者向けの構成例
よくある質問
1. Dataflowはデータベースですか？
2. Dataflowだけでデータを保存できますか？
3. Dataflowを使うにはプログラミングが必要ですか？
4. Dataflowはリアルタイム処理に使えますか？
5. DataflowとBigQueryはどちらを使えばよいですか？
6. DataflowとPub/Subは同じサービスですか？
7. 少量のデータでもDataflowを使うべきですか？
8. Dataflowジョブは自動実行できますか？

Dataflowとは？

Dataflowは、Google Cloudが提供するフルマネージド型のデータ処理サービスです。

複数のサービスやシステムからデータを読み込み、加工・変換して、目的の保存先へ書き込む処理を実行できます。

例えば、次のような処理に利用されます。

Cloud StorageのCSVファイルをBigQueryへ登録する
Pub/Subへ届いたデータをリアルタイムに加工する
アクセスログから不要な項目を削除する
複数のデータを組み合わせる
データ形式をJSONから別の形式へ変換する
大量の売上データを集計する
異常なデータを取り除く
機械学習に使用するデータを準備する

簡単にいうと、Dataflowはデータを運びながら、使いやすい形へ整えるサービスです。

Dataflowを一言で表すと？

Dataflowを一言で表すと、データの加工工場と運送業者を組み合わせたようなサービスです。

工場では、届いた原材料を加工し、完成した製品を出荷します。

Dataflowでも、次のような流れでデータを処理します。

データを読み込む
不要なデータを取り除く
形式を整える
必要に応じて集計する
処理後のデータを別の場所へ保存する

データの取得元
  ↓
Dataflowで加工・変換
  ↓
データの保存先

この一連の流れをデータパイプラインと呼びます。

データパイプラインとは？

データパイプラインとは、データを取得してから、加工し、保存先へ渡すまでの一連の処理です。

パイプの中を水が流れていくように、データが複数の処理を順番に通過していくイメージです。

読み込み
  ↓
形式変換
  ↓
不要データの削除
  ↓
集計
  ↓
保存

例えば、ECサイトの注文データを分析用に準備する場合は、次のようなパイプラインを作成できます。

注文データを読み込む
注文日時の形式を統一する
テスト注文を除外する
商品ごとの売上を計算する
BigQueryへ保存する

Dataflowは、このようなデータパイプラインをGoogle Cloud上で実行する役割を持っています。

Dataflowの基本的な処理の流れ

Dataflowの処理は、大きく分けると次の3段階です。

データを読み込む
データを変換する
データを書き込む

1．データを読み込む

最初に、処理対象となるデータを取得します。

データの取得元をソースと呼ぶことがあります。

代表的な取得元には、次のようなものがあります。

Cloud Storage
Pub/Sub
BigQuery
データベース
外部システム
テキストファイル
CSVファイル
JSONファイル

2．データを変換する

読み込んだデータを、利用目的に合わせて加工します。

例えば、次のような処理を行います。

不要な行を削除する
必要な列だけを残す
文字列を数値へ変換する
日付の形式を統一する
複数の項目を組み合わせる
データをグループごとに集計する
重複データを取り除く
不正なデータを別の保存先へ分ける

3．データを書き込む

加工したデータを目的の場所へ保存します。

データの書き込み先をシンクと呼ぶことがあります。

代表的な書き込み先には、次のようなものがあります。

BigQuery
Cloud Storage
Pub/Sub
データベース
外部システム

ソース
  ↓
Dataflowによる変換処理
  ↓
シンク

Dataflowで処理できるデータの例

Dataflowでは、さまざまな種類のデータを処理できます。

Webサイトのアクセスログ
アプリケーションの操作履歴
ECサイトの注文情報
店舗の売上データ
センサーから届く測定値
システムのエラーログ
広告のクリック履歴
顧客や会員に関するデータ
CSVやJSON形式のファイル

ただし、Dataflowは画像や動画を保管するサービスではありません。

画像や動画などのファイルを保存する場合はCloud Storageを使い、そのファイルに関する情報や処理結果をDataflowで加工する構成があります。

バッチ処理とは？

Dataflowでは、バッチ処理を実行できます。

バッチ処理とは、一定量のデータをまとめて処理する方法です。

例えば、次のような処理がバッチ処理に該当します。

毎日深夜に前日分の売上を集計する
月末に1か月分の請求データを処理する
Cloud Storage内のCSVファイルをまとめてBigQueryへ登録する
過去1年分のアクセスログを集計する
定期的にバックアップデータを変換する

1日分のデータを蓄積
  ↓
深夜にまとめて処理
  ↓
集計結果を保存

処理結果がすぐに必要ではなく、決まった時間にまとめて処理できる場合に向いています。

ストリーミング処理とは？

Dataflowでは、ストリーミング処理も実行できます。

ストリーミング処理とは、データが届くたびに継続して処理する方法です。

例えば、次のような処理に利用されます。

Webサイトのアクセスを随時集計する
センサーから届く温度データを処理する
アプリの操作履歴をリアルタイムに分析する
不正なアクセスを検出する
システムエラーの発生件数を監視する
オンライン注文を順次処理する

データ1が到着 → 処理
データ2が到着 → 処理
データ3が到着 → 処理
データ4が到着 → 処理

新しいデータを短い間隔で分析したい場合に向いています。

バッチ処理とストリーミング処理の違い

項目	バッチ処理	ストリーミング処理
処理方法	データをまとめて処理する	届いたデータを継続的に処理する
実行タイミング	決められた時間など	常時またはデータ到着時
主な用途	日次集計、月次処理	リアルタイム監視、即時分析
処理対象	範囲が決まったデータ	次々に届くデータ
例	前日分の売上集計	現在のアクセス数の集計

Dataflowの特徴は、バッチ処理とストリーミング処理の両方を扱えることです。

実際の業務ではどのように使われる？

Cloud StorageのCSVをBigQueryへ登録する

社内システムから出力されたCSVファイルを、毎日BigQueryへ登録する場合があります。

社内システム
  ↓
CSVファイルを出力
  ↓
Cloud Storage
  ↓
Dataflowで形式を変換
  ↓
BigQuery

Dataflowでは、CSVの列をBigQueryのテーブル構造に合わせたり、不正なデータを除外したりできます。

アクセスログをリアルタイムに集計する

Webサイトのアクセス情報をPub/Subへ送り、Dataflowで集計してBigQueryへ保存する構成があります。

Webサイト
  ↓
Pub/Sub
  ↓
Dataflow
  ↓
BigQuery
  ↓
ダッシュボード

この構成では、現在のアクセス数やエラー件数などを短い間隔で確認できます。

IoT機器のデータを処理する

工場や店舗に設置されたセンサーから、温度や湿度などのデータが継続的に送信される場合があります。

Dataflowを利用すると、異常な値を検出したり、一定時間ごとの平均値を計算したりできます。

機械学習用のデータを準備する

機械学習では、元のデータをそのまま利用できるとは限りません。

Dataflowを使って、欠損値の処理、形式の統一、不要項目の削除などを行い、学習に使用しやすいデータを作成できます。

ETLとは？

Dataflowを扱う業務では、ETLという言葉がよく使われます。

ETLは、次の3つの英単語の頭文字です。

文字	英語	意味
E	Extract	データを取り出す
T	Transform	データを加工・変換する
L	Load	データを保存先へ登録する

例えば、社内システムの売上データをBigQueryへ登録する場合は、次のようになります。

社内システムからデータを取得する
日付や金額の形式を整える
BigQueryへ登録する

Dataflowは、このETL処理を実行するサービスとして利用できます。

ELTとは？

ETLと似た言葉に、ELTがあります。

ELTでは、取得したデータを先に保存し、そのあとで加工します。

Extract：データを取り出す
Load：データを保存する
Transform：保存したデータを加工する

例えば、元データをBigQueryへ先に登録し、そのあとSQLで加工する方法がELTに該当します。

ETLとELTのどちらを選ぶかは、データ量、処理内容、料金、運用方法などによって異なります。

Apache Beamとは？

Dataflowを理解するうえで重要なのが、Apache Beam（アパッチビーム）です。

Apache Beamは、バッチ処理とストリーミング処理のデータパイプラインを作成するためのオープンソースの仕組みです。

開発者はApache Beamを使って、次のような内容をプログラムとして定義します。

どこからデータを読み込むか
どのようにデータを加工するか
どこへデータを書き込むか

作成したApache Beamのパイプラインを、Google Cloud上で実行するサービスがDataflowです。

Apache Beam
  ↓
データ処理の内容を定義
  ↓
Dataflow
  ↓
Google Cloud上で実行

DataflowとApache Beamの違い

項目	Dataflow	Apache Beam
種類	Google Cloudの実行サービス	データパイプラインを作る仕組み
主な役割	パイプラインをクラウド上で実行する	データ処理の内容を定義する
管理者	Google Cloud	オープンソースプロジェクト
例	処理に必要な計算資源を準備する	読み込み・変換・保存処理を書く

Apache Beamが処理の設計図、Dataflowが設計図をもとに処理を動かす実行環境と考えると分かりやすいでしょう。

Dataflowではどのプログラミング言語を使う？

Apache BeamのSDKを利用してDataflowパイプラインを開発する場合、主に次のプログラミング言語が使われます。

Java
Python
Go

業務では、既存システムや開発チームのスキル、利用する機能などを考慮して言語を選択します。

IT業務初心者は、まずPythonまたはJavaによる簡単なパイプラインの構造を確認すると理解しやすいでしょう。

Dataflowジョブとは？

Dataflowで実行される1回のデータ処理を、ジョブと呼びます。

例えば、Cloud StorageのCSVをBigQueryへ登録する処理を実行すると、Dataflowジョブが作成されます。

ジョブでは、次のような情報を確認できます。

実行中か完了済みか
処理が失敗していないか
どの処理に時間がかかっているか
どのくらいのデータを処理したか
ワーカーが何台動いているか
エラーメッセージ

バッチジョブとストリーミングジョブの違い

項目	バッチジョブ	ストリーミングジョブ
終了	対象データを処理すると終了する	基本的に継続して動作する
主な用途	日次処理、ファイル変換	継続的なデータ処理
例	CSVをまとめて取り込む	Pub/Subのメッセージを処理し続ける

ストリーミングジョブは継続して動作するため、停止の判断や料金、監視方法についても考慮する必要があります。

ワーカーとは？

ワーカーとは、Dataflowのデータ処理を実際に行うコンピューティングリソースです。

大きな荷物を複数人で分担して運ぶように、大量のデータを複数のワーカーで分担して処理します。

大量のデータ
  ↓
ワーカー1 ─ 一部を処理
ワーカー2 ─ 一部を処理
ワーカー3 ─ 一部を処理
  ↓
処理結果をまとめる

処理量が増えるとワーカーを増やし、処理量が減るとワーカーを減らす構成があります。

自動スケーリングとは？

自動スケーリングとは、処理量に応じて使用するワーカー数を自動的に調整する仕組みです。

例えば、処理するデータが急増した場合はワーカーを増やし、データが少なくなった場合はワーカーを減らします。

これにより、次のような効果が期待できます。

大量データを効率よく処理できる
処理の遅れを抑えやすい
不要なリソースの利用を減らせる
手動で台数を変更する作業を減らせる

ただし、設定や処理内容によって動作が異なるため、実際の業務ではジョブの監視が必要です。

Dataflowテンプレートとは？

Dataflowには、あらかじめ用意された処理を利用できるテンプレートがあります。

テンプレートを利用すると、すべてのパイプラインを最初からプログラミングしなくても、一般的なデータ転送処理を実行できます。

例えば、次のような処理に対応するテンプレートがあります。

Cloud StorageからBigQueryへデータを転送する
Pub/SubからBigQueryへデータを転送する
データベースからBigQueryへデータを転送する
Pub/SubのデータをCloud Storageへ保存する

入力元や出力先などの必要な項目を指定し、ジョブを実行します。

Google提供テンプレートとは？

Google提供テンプレートは、Googleが用意している一般的なデータ処理用のテンプレートです。

プログラムを一から作らずに利用できるため、次のような場合に便利です。

一般的なデータ転送をすぐに実行したい
複雑な加工処理が必要ない
Apache Beamのコードをまだ書けない
検証環境で簡単に動作を確認したい

ただし、特殊な加工や独自の業務ルールが必要な場合は、独自のパイプラインを作成する必要があります。

Flex Templateとは？

Flex Templateは、独自に作成したDataflowパイプラインをコンテナとしてまとめ、繰り返し実行しやすくする仕組みです。

パイプラインのコード、依存ライブラリ、実行に必要な設定などをパッケージ化できます。

Flex Templateを利用すると、開発環境を持っていない利用者でも、必要な権限とパラメーターがあればジョブを実行できます。

DataflowとPub/Subの関係

Pub/Subは、システム間でメッセージを受け渡すためのサービスです。

Dataflowと組み合わせると、Pub/Subへ届いたデータを継続的に読み取り、加工できます。

アプリケーション
  ↓
Pub/Sub
  ↓
Dataflow
  ↓
BigQuery

それぞれの役割は次のとおりです。

サービス	役割
Pub/Sub	メッセージを受け取り、別のサービスへ渡す
Dataflow	受け取ったデータを加工・集計する
BigQuery	加工後のデータを保存・分析する

Pub/Subはデータの受け渡し、Dataflowはデータの加工を担当すると考えると分かりやすいでしょう。

DataflowとBigQueryの関係

BigQueryは、大量のデータを保存して分析するためのサービスです。

Dataflowは、BigQueryへ登録する前のデータを加工したり、BigQueryから読み込んだデータを別の場所へ移したりするために利用できます。

サービス	主な役割
Dataflow	データを読み込み、加工・転送する
BigQuery	データを保存し、SQLで分析する

Dataflowはデータの加工工程、BigQueryはデータの保存・分析場所という違いがあります。

DataflowとCloud Storageの関係

Cloud Storageは、CSV、JSON、ログ、バックアップなどのファイルを保存するサービスです。

Dataflowでは、Cloud Storageに保存されたファイルを読み込み、加工した結果をBigQueryや別のCloud Storageバケットへ保存できます。

Cloud Storage
  ↓
Dataflow
  ↓
BigQuery

また、Pub/Subから受け取ったデータをDataflowで処理し、Cloud Storageへファイルとして保存する構成もあります。

DataflowとCloud Runの違い

項目	Dataflow	Cloud Run
主な用途	大量データの加工・転送	WebアプリやAPIの実行
処理モデル	データパイプライン	コンテナアプリケーション
代表的な処理	ETL、集計、ストリーム処理	HTTPリクエストの処理
開発方法	Apache Beamやテンプレート	コンテナイメージ

Cloud Runでもデータ加工用のプログラムを実行できますが、大規模な分散処理や継続的なストリーム処理ではDataflowが適している場合があります。

DataflowとDataprocの違い

Dataprocも、大量データの処理に利用されるGoogle Cloudサービスです。

項目	Dataflow	Dataproc
主な技術	Apache Beam	Apache Spark、Hadoopなど
サーバー管理	比較的少ない	クラスター設定が必要
主な用途	バッチ・ストリーム処理	SparkやHadoopの処理
向いているケース	Beamによるデータパイプライン	既存のSpark処理などを利用する場合

既存のApache Sparkプログラムを移行する場合はDataprocが候補となり、新しく統一的なデータパイプラインを作成する場合はDataflowが候補になります。

DataflowとCloud Data Fusionの違い

Cloud Data Fusionは、画面上で部品を組み合わせながらデータパイプラインを作成できるサービスです。

項目	Dataflow	Cloud Data Fusion
主な作成方法	コードまたはテンプレート	画面上の操作
自由度	高い	用意された機能を組み合わせる
主な利用者	データエンジニア、開発者	コードを減らしてパイプラインを作りたい担当者

複雑な独自処理を実装する場合はDataflow、画面操作を中心にパイプラインを構築したい場合はCloud Data Fusionが候補になります。

ウィンドウとは？

ストリーミング処理では、データが継続的に届くため、すべてのデータが届き終わるタイミングがありません。

そこで、一定の範囲にデータを区切って集計するウィンドウという考え方を利用します。

例えば、アクセス数を1分ごとに集計する場合は、次のようにデータを分けます。

10:00:00～10:00:59のアクセス
10:01:00～10:01:59のアクセス
10:02:00～10:02:59のアクセス

それぞれの時間帯を一つのまとまりとして集計します。

固定ウィンドウとは？

固定ウィンドウは、データを重ならない一定間隔に区切る方法です。

例えば、5分ごとにアクセス数を集計します。

10:00～10:05
10:05～10:10
10:10～10:15

時間ごと、5分ごと、1日ごとなど、決まった間隔で集計したい場合に利用します。

スライディングウィンドウとは？

スライディングウィンドウは、一定の時間幅をずらしながらデータを集計する方法です。

例えば、直近10分間の平均値を1分ごとに計算する場合に利用できます。

10:00～10:10
10:01～10:11
10:02～10:12

範囲が重なる点が固定ウィンドウとの違いです。

セッションウィンドウとは？

セッションウィンドウは、利用者の一連の操作などを一つのまとまりとして扱う方法です。

例えば、利用者がWebサイトを操作し、一定時間操作がなければ、そのセッションが終了したと判断します。

利用者ごとの行動分析や、端末ごとの連続した通信をまとめたい場合などに利用できます。

ウォーターマークとは？

ストリーミング処理では、データが発生した順番どおりに到着するとは限りません。

ネットワークの遅延などによって、古い時刻のデータがあとから届く場合があります。

ウォーターマークは、ある時刻までのデータがどの程度そろったかを判断するための目安です。

ストリーミング処理では、遅れて届くデータをどのように扱うかも設計する必要があります。

トリガーとは？

トリガーとは、ウィンドウ内の集計結果をいつ出力するかを決める仕組みです。

例えば、次のような条件で結果を出力できます。

一定時間が経過したとき
一定件数のデータが届いたとき
ウィンドウが終了したと判断されたとき
遅れて届いたデータを受け取ったとき

ウィンドウ、ウォーターマーク、トリガーは、ストリーミング処理を理解するうえで重要な考え方です。

Dataflowの監視

Dataflowジョブを実行したあとは、正常に動作しているかを監視する必要があります。

Google Cloudコンソールでは、パイプラインの各処理を図として確認できます。

主に次の内容を確認します。

ジョブの実行状態
各処理段階の状態
処理済みのデータ件数
処理にかかっている時間
ワーカー数
エラーの発生状況
処理の遅れ
ログの内容

ジョブが動いているだけでなく、予定した速度でデータを処理できているかを確認することが重要です。

Dataflowで発生しやすい問題

入力データの形式が想定と違う

数値を想定した項目に文字が入っているなど、データ形式が異なると処理が失敗することがあります。

サービスアカウントの権限が不足している

Cloud Storageの読み取りやBigQueryへの書き込みに必要な権限がないと、ジョブを実行できません。

一部のデータだけ処理に失敗する

特定の行に不正な文字や欠損値が含まれていると、そのデータだけ処理できない場合があります。

データ量が多く処理が遅れる

想定以上のデータが届いた場合、処理が追いつかず遅延が発生することがあります。

書き込み先の設定が間違っている

BigQueryのテーブル名、データセット、スキーマなどが正しくないと書き込みに失敗します。

デッドレターとは？

正常に処理できなかったデータを、別の保存先へ分ける仕組みをデッドレターと呼ぶことがあります。

例えば、日付形式が不正なデータを通常のBigQueryテーブルへ登録せず、エラー用の保存先へ出力します。

正常なデータ
  ↓
BigQueryの通常テーブル

異常なデータ
  ↓
エラー確認用の保存先

処理できないデータが1件あっただけでパイプライン全体が停止しないように設計できます。

Dataflowのアクセス権限

DataflowがCloud StorageやBigQueryなどへアクセスするには、適切なIAM権限が必要です。

主に次のような主体が関係します。

Dataflowジョブを実行する利用者
Dataflowサービスが使用するアカウント
ワーカーが使用するサービスアカウント

ワーカーのサービスアカウントには、データの取得元と書き込み先へアクセスするための権限が必要です。

例えば、Cloud Storageから読み込み、BigQueryへ書き込む場合は、それぞれに必要な権限を設定します。

サービスアカウントとは？

サービスアカウントとは、人ではなく、アプリケーションやクラウドサービスがGoogle Cloudへアクセスするためのアカウントです。

Dataflowのワーカーは、サービスアカウントを使用してCloud StorageやBigQueryへアクセスします。

Dataflowワーカー
  ↓ サービスアカウントで認証
Cloud Storage・BigQuery

サービスアカウントへ必要以上に強い権限を付与せず、パイプラインに必要な最低限の権限だけを設定することが重要です。

Dataflowの料金はどのように決まる？

Dataflowの料金は、主にジョブが使用するコンピューティングリソースやストレージなどによって決まります。

主な料金要素には、次のようなものがあります。

ワーカーが使用するCPU
ワーカーが使用するメモリ
ディスク容量
ストリーミング処理で使用するリソース
データ転送
連携先サービスの利用料金

Dataflowだけでなく、BigQuery、Pub/Sub、Cloud Storageなどの料金も発生する場合があります。

実際に利用するときは、最新のGoogle Cloud公式料金ページを確認しましょう。

Dataflowの料金が高くなりやすい例

ストリーミングジョブを不要な期間も動かし続ける
必要以上に高性能なワーカーを使用する
ワーカー数の上限を大きく設定する
同じデータを何度も再処理する
不要なデータまでパイプラインへ流す
異なるリージョン間で大量のデータを転送する
エラーによる再試行が繰り返される

Dataflowのコストを抑える基本

不要なデータを早い段階で除外する

パイプラインの最初に不要なデータを除外すると、後続の処理量を減らせます。

適切なワーカー設定を利用する

処理量に対して過剰なCPUやメモリを割り当てないようにします。

自動スケーリングを検討する

処理量に応じてワーカー数を調整し、必要以上のリソースを使わないようにします。

ジョブを停止し忘れない

検証用のストリーミングジョブが不要になった場合は、停止されていることを確認します。

リージョンをそろえる

Dataflow、Cloud Storage、BigQuery、Pub/Subなどのロケーションを考慮し、不要なリージョン間転送を減らします。

予算とアラートを設定する

Google Cloudの予算設定を利用し、想定を超える料金が発生しそうな場合に確認できるようにします。

Dataflowを利用するメリット

バッチ処理とストリーミング処理の両方に対応できる
大量データを複数のワーカーで分散処理できる
処理量に応じた自動スケーリングを利用できる
サーバーの構築や管理作業を減らせる
BigQueryやPub/Subなどと連携しやすい
Apache Beamで柔軟な処理を作成できる
テンプレートを使って簡単に実行できる処理もある
Google Cloudコンソールからジョブを監視できる

Dataflowを利用するときの注意点

小さな処理には構成が複雑になる場合がある

少量のファイルを単純に変換するだけなら、Cloud Runや別の方法のほうが簡単な場合があります。

Apache Beamの知識が必要になる

独自のパイプラインを作成する場合は、Apache Beamの考え方やプログラミングの知識が必要です。

ストリーミング処理は設計が難しい

遅れて届くデータ、重複データ、ウィンドウ、再試行などを考慮する必要があります。

エラー処理を事前に考える

不正なデータが届いた場合にパイプライン全体を停止するのか、別の保存先へ分けるのかを設計します。

料金を継続的に確認する

ストリーミングジョブは長時間動作するため、利用リソースと料金を定期的に確認する必要があります。

ロケーションを確認する

取得元と保存先のロケーションが異なると、制約やデータ転送料が問題になる場合があります。

初心者がDataflowを学ぶ順番

Cloud StorageとBigQueryの役割を理解する
バッチ処理とストリーミング処理の違いを理解する
ETLとデータパイプラインの意味を理解する
Google提供テンプレートを実行してみる
Dataflowジョブの監視画面を確認する
Apache Beamの基本を学ぶ
簡単なバッチパイプラインを作成する
Pub/Subを使ったストリーミング処理を学ぶ

最初から複雑なストリーミング処理を作るのではなく、Cloud StorageからBigQueryへデータを移す簡単なバッチ処理から始めると理解しやすいでしょう。

初心者向けの構成例

最初の学習では、Cloud Storageに保存したCSVファイルをBigQueryへ登録する構成が分かりやすいでしょう。

CSVファイル
  ↓
Cloud Storage
  ↓
Dataflow
  ↓
BigQuery

この構成では、次の内容を学べます。

バケットとオブジェクト
Dataflowジョブ
データの読み込み
データ形式の変換
BigQueryへの書き込み
サービスアカウント
IAM権限
ジョブの監視

よくある質問

Dataflowはデータベースですか？

いいえ。Dataflowはデータを保存・検索するデータベースではなく、データを読み込み、加工し、別の保存先へ渡すサービスです。

加工後のデータはBigQuery、Cloud Storage、データベースなどへ保存します。

Dataflowだけでデータを保存できますか？

Dataflowはデータ処理を実行するサービスであり、長期的なデータ保存を主な目的としていません。

データの保存先には、BigQueryやCloud Storageなどを利用します。

Dataflowを使うにはプログラミングが必要ですか？

独自の処理を作成する場合は、Apache Beamを利用したプログラミングが必要です。

ただし、Google提供テンプレートを利用できる処理では、コードを書かずにジョブを実行できる場合があります。

Dataflowはリアルタイム処理に使えますか？

はい。Pub/Subなどから継続的にデータを受け取り、ストリーミング処理を実行できます。

DataflowとBigQueryはどちらを使えばよいですか？

役割が異なるため、どちらか一方を選ぶとは限りません。

Dataflowでデータを加工し、BigQueryへ保存してSQLで分析する構成がよく利用されます。

DataflowとPub/Subは同じサービスですか？

いいえ。Pub/Subはメッセージを受け渡すサービスで、Dataflowは受け取ったデータを加工・集計するサービスです。

少量のデータでもDataflowを使うべきですか？

必ずしもDataflowが最適とは限りません。

データ量が少なく処理が単純な場合は、Cloud Run、Cloud Run functions、BigQueryのSQLなどで対応できる場合があります。

Dataflowジョブは自動実行できますか？

バッチジョブをスケジュールしたり、別のサービスからジョブを開始したりする構成を作れます。

定期実行の方法は、テンプレートやシステム構成によって異なります。

処理に失敗したデータはどうなりますか？

モバイルバージョンを終了