Dataflow パイプラインは、（小さなデータセットでテストを行うために）ローカルで実行することも、Google Cloud のマネージド リソース上で Dataflow マネージド サービスを使用して実行することもできます。実行される場所に関係なく、パイプラインとそのワーカーは権限システムを利用してパイプライン ファイルとリソースへのセキュアなアクセスを維持します。Dataflow の権限は、パイプライン リソースへのアクセスに使用されるロールに従って割り当てられます。このドキュメントでは、次のコンセプトについて説明します。
- Dataflow VM のアップグレード。
- ローカル パイプラインと Google Cloud パイプラインの実行に必要なロールと権限。
- プロジェクト間でパイプライン リソースにアクセスするために必要なロールと権限。
- Dataflow サービスとデータ セキュリティで使用されるデータのタイプ。
始める前に
プラットフォームの概要で、Google Cloud プロジェクトの識別子についての記事をご覧ください。識別子とは、プロジェクト名、プロジェクト ID、プロジェクト番号などです。
Dataflow VM のアップグレードとパッチの適用
Dataflow は Container-Optimized OS を使用します。したがって、Container-Optimized OS のセキュリティ プロセスが Dataflow に適用されます。
バッチ パイプラインには時間制限があります。メンテナンスの必要はありません。新しいバッチ パイプラインを開始すると、最新の Dataflow イメージが使用されます。
ストリーミング パイプラインでセキュリティ パッチがすぐに必要な場合、Google Cloud はセキュリティに関する情報でそのことを通知します。ストリーミング パイプラインの場合は、--update オプションを使用して、最新の Dataflow イメージでジョブを再起動することをおすすめします。
Dataflow コンテナ イメージは、Google Cloud Console で入手できます。
ローカル パイプラインのセキュリティと権限
Apache Beam パイプラインをローカルで実行するときは、Google Cloud CLI 実行可能ファイルで構成した Google Cloud アカウントとして実行されます。したがって、ローカルで実行される Apache Beam SDK のオペレーションからアクセスできるのは、その Google Cloud アカウントが権限を持つファイルとリソースに限られます。
デフォルトとして選択した Google Cloud アカウントを一覧表示するには、gcloud config list コマンドを実行します。
Google Cloud 上のパイプラインのセキュリティと権限
Cloud Platform 上でパイプラインを実行するときは、Dataflow は 2 つのサービス アカウントを使用してセキュリティと権限を管理します。
Dataflow サービス アカウント。Dataflow サービスは、プロジェクトの割り当ての確認や、ユーザーの代理でのワーカー インスタンスの作成など、ジョブ作成リクエストの一部として Dataflow サービス アカウントを使用します。また、Dataflow はジョブの実行中に Dataflow サービス アカウントを使用して、ジョブを管理します。このアカウントは、Dataflow サービス エージェントとも呼ばれます。
ワーカー サービス アカウント。 ワーカー サービス アカウントは、ユーザーがジョブを送信した後にワーカー インスタンスが入力リソースや出力リソースにアクセスする目的で使用されます。デフォルトでは、ワーカーはプロジェクトに関連付けられた Compute Engine のデフォルトのサービス アカウントをワーカー サービス アカウントとして使用します。ワーカー サービス アカウントでジョブを作成、実行、確認できるようにするには、次のロールが必要です。
roles/dataflow.adminroles/dataflow.worker
また、Apache Beam パイプラインが Google Cloud リソースにアクセスする場合は、必要なロールを Dataflow プロジェクトのワーカー サービス アカウントに付与する必要があります。ワーカー サービス アカウントは、Dataflow ジョブの実行中にリソースにアクセスできる必要があります。たとえば、ジョブで BigQuery に書き込む場合は、サービス アカウントにも少なくとも roles/bigquery.dataEditor ロールが必要です。リソースの例:
最後に、サービス アカウントの権限を借用するため、ユーザー アカウントに iam.serviceAccounts.actAs のロールが必要です。他のプロジェクトの権限によっては、ユーザー アカウントに roles/dataflow.developer のロールも必要になる場合があります。
プロジェクトに必要なロールを追加する手順は次のとおりです。
コンソール
Google Cloud コンソールの [IAM] ページに移動します。
プロジェクトを選択します。
ユーザー アカウントを含む行で、「プリンシパルを編集します」をクリックし、[ 別のロールを追加] をクリックします。
プルダウン リストで、[サービス アカウント ユーザー] のロールを選択します。
Compute Engine のデフォルトのサービス アカウントを含む行で、「プリンシパルを編集します」をクリックし、[ 別のロールを追加] をクリックします。
プルダウン リストで、[Dataflow ワーカー] ロールを選択します。
この手順を Dataflow 管理者とジョブで使用されるリソースに必要なロールに対して繰り返し、[保存] をクリックします。
ロール付与の詳細については、コンソールを使用して IAM ロールを付与するをご覧ください。
gcloud CLI
ユーザー アカウントに
roles/iam.serviceAccountUserロールを付与します。次のコマンドを実行します。gcloud projects add-iam-policy-binding PROJECT_ID --member="user:EMAIL_ADDRESS --role=roles/iam.serviceAccountUserPROJECT_IDは、実際のプロジェクト ID に置き換えます。EMAIL_ADDRESSは、ユーザー アカウントのメールアドレスに置き換えます。
Compute Engine のデフォルト サービス アカウントにロールを付与します。IAM ロール
roles/dataflow.admin、roles/dataflow.worker、ジョブで使用するリソースに必要なロールごとに、次のコマンドを 1 回実行します。gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" --role=SERVICE_ACCOUNT_ROLEPROJECT_IDは、実際のプロジェクト ID に置き換えます。PROJECT_NUMBERは、使用するプロジェクト番号に置き換えます。プロジェクト番号を確認するには、プロジェクトを特定するに記載されている手順を行うか、gcloud projects describeコマンドを使用します。SERVICE_ACCOUNT_ROLEは、個々のロールに置き換えます。
Dataflow サービス アカウント
リソース Dataflow Job を使用したすべてのプロジェクトには、Dataflow サービス アカウント（Dataflow サービス エージェント）があります。このアカウントには、次のメールアドレスが設定されています。
service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com
このサービス アカウントは Google によって作成、管理され、リソース Dataflow Job の初回使用時にプロジェクトに自動的に割り当てられます。
Dataflow パイプラインの実行の一環として、Dataflow サービスはユーザーの代わりにリソースを操作します。たとえば、追加の VM を作成します。Dataflow サービスでパイプラインを実行するときに、このサービス アカウントが使用されます。
このアカウントには、プロジェクトの Dataflow サービス エージェントのロールが割り当てられます。Compute Engine ワーカーの起動など、プロジェクトで Dataflow ジョブを実行するために必要な権限があります。このアカウントは Dataflow サービスによってのみ使用され、プロジェクトに固有のものです。
Dataflow サービス アカウントの権限は、Google Cloud コンソールまたは Google Cloud CLI で確認できます。
コンソール
[ロール] ページに移動します。
プロジェクトを選択します（該当する場合）。
リストで「Cloud Dataflow Service Agent」というタイトルをクリックします。ページが開き、Dataflow サービス アカウントに割り当てられた権限が一覧表示されます。
gcloud CLI
Dataflow サービス アカウントの権限を表示します。
gcloud iam roles describe roles/dataflow.serviceAgent
Google Cloud のサービスは、プロジェクトとそのリソースへの読み取り / 書き込みアクセス権が付与されていることが前提となっているため、プロジェクトに対して自動的に設定されたデフォルトの権限を変更しないことをおすすめします。Dataflow サービス アカウントがプロジェクトに対する権限を失うと、Dataflow が VM を起動することや、その他の管理タスクを実行することができなくなります。
Identity and Access Management（IAM）ポリシーからサービス アカウントの権限を削除しても、アカウントは Dataflow サービスによって所有されているため、引き続き存在します。
ワーカー サービス アカウント
Compute Engine インスタンスは Apache Beam SDK のオペレーションをクラウドで実行します。これらのワーカーは、プロジェクトのワーカー サービス アカウントを使用して、パイプラインに関連付けられたファイルやその他のリソースにアクセスします。ワーカー サービス アカウントはすべてのワーカー VM の ID として使用され、VM からのすべてのリクエストでワーカー サービス アカウントを使用します。このサービス アカウントは、Cloud Storage バケットや Pub/Sub トピックなどのリソースの操作にも使用されます。
ワーカー サービス アカウントでジョブを作成、実行、確認できるようにするには、次のロールが必要です。
roles/dataflow.adminroles/dataflow.worker
デフォルトのワーカー サービス アカウント
デフォルトでは、ワーカーはプロジェクトの Compute Engine のデフォルト サービス アカウントをワーカー サービス アカウントとして使用します。このサービス アカウントのメールアドレスは次の形式です。
PROJECT_NUMBER-compute@developer.gserviceaccount.com
このサービス アカウントは、Google Cloud コンソールの API ライブラリでプロジェクトの Compute Engine API を有効にすると、自動的に作成されます。
Compute Engine のデフォルトのサービス アカウントでは、プロジェクトのリソースに幅広くアクセスできるため、Dataflow を簡単に開始できます。ただし、本番環境のワークロードでは、必要なロールと権限のみを持つ新しいサービス アカウントを作成することをおすすめします。
ユーザー管理のワーカー サービス アカウントを指定する
きめ細かいアクセス制御を使用してリソースを作成して使用する場合は、ユーザー管理のサービス アカウントを作成します。このアカウントをワーカー サービス アカウントとして使用します。
ユーザー管理のサービス アカウントがない場合は、サービス アカウントを作成します。
サービス アカウントに必要な IAM ロールを設定します。
- サービス アカウントでジョブを作成、実行、確認できるようにするには、
roles/dataflow.adminロールとroles/dataflow.workerロールが必要です。あるいは、これらのロールに必要な権限を含む IAM カスタムロールが必要です。必要な権限の一覧については、ロールをご覧ください。 - ジョブで必要とされる Google Cloud リソース（BigQuery、Pub/Sub、Cloud Storage）を使用するために、別のロールが必要となる場合もあります。たとえば、ジョブで BigQuery から読み取りをする場合は、サービス アカウントは少なくとも
roles/bigquery.dataViewerロールを持つ必要があります。 - ユーザー管理のサービス アカウントに、Dataflow ジョブで指定されたステージング済みの一時的な場所に対する読み取りと書き込みのアクセス権があることを確認してください。
- サービス アカウントの権限を借用するには、ユーザー アカウントに
iam.serviceAccounts.actAs権限が必要です。
- サービス アカウントでジョブを作成、実行、確認できるようにするには、
次のロールを Dataflow サービス アカウント（
service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com）と Compute Engine サービス エージェント（service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com）に付与します。これらのアカウントはどちらも、ユーザーが管理するサービス アカウントに対して Google が管理するサービス アカウントです。これらのアカウントは、Dataflow ジョブが別のプロジェクトで実行される場合でも、ユーザー管理のサービス アカウントと同じプロジェクトにあります。- サービス アカウント トークン作成者のロール（
iam.serviceAccountTokenCreator） - サービス アカウント ユーザー ロール（
iam.serviceAccountUser）
サービス アカウントにロールを付与する手順については、サービス アカウントの管理ページにある単一のロールを付与するをご覧ください。
- サービス アカウント トークン作成者のロール（
パイプライン ジョブを実行するときに、サービス アカウントを指定します。
Java
コマンドラインからパイプライン ジョブを実行する場合は、次のように
--serviceAccountオプションを使用してサービス アカウントを指定します。--serviceAccount=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.comパイプライン ジョブを Flex テンプレートとして実行する場合は、次のように
--service-account-emailオプションを使用してサービス アカウントを指定します。--service-account-email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.comPython
--service_account_emailオプションを使用して、--service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.comパイプライン ジョブの実行時にサービス アカウントを指定します。Go
--service_account_emailオプションを使用して、--service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.comパイプライン ジョブの実行時にサービス アカウントを指定します。
プロジェクトに関連付けられているサービス アカウントの一覧は、Google Cloud コンソールの [権限] ページで確認できます。
ユーザー管理のサービス アカウントは、ジョブと同じプロジェクトにあっても、別のプロジェクトにあってもかまいません。サービス アカウントとジョブが別々のプロジェクトに属している場合は、ジョブを実行する前にサービス アカウントを構成する必要があります。
Google Cloud リソースにアクセスする
Apache Beam パイプラインは、同じ Google Cloud プロジェクトまたは他のプロジェクトの Google Cloud リソースにアクセスできます。次のようなリソースが該当します。
Apache Beam パイプラインからこれらのリソースに確実にアクセスできるようにするには、各リソースのアクセス制御メカニズムを使用して、自分の Dataflow プロジェクトのワーカー サービス アカウントにアクセス権を明示的に付与する必要があります。
Dataflow で Assured Workloads 機能を使用する場合（主権管理のある EU リージョンとサポートなど）、すべての Cloud Storage、BigQuery、Pub/Sub、I/O コネクタ、パイプラインがアクセスするその他のリソースを、組織の Assured Workloads プロジェクトまたはフォルダに配置する必要があります。
ただし、ユーザー管理のワーカー サービス アカウントを使用している場合、または他のプロジェクトのリソースにアクセスしている場合は、追加の操作が必要になることがあります。次の例では、Compute Engine のデフォルトのサービス アカウントを使用していますが、ユーザー管理のワーカー サービス アカウントを使用することもできます。
Artifact Registry リポジトリにアクセスする
Dataflow でカスタム コンテナを使用するときに、アーティファクトを Artifact Registry リポジトリにアップロードする場合があります。
Dataflow で Artifact Registry を使用するには、Dataflow ジョブを実行するワーカー サービス アカウントに少なくとも Artifact Registry 書き込みアクセス権（role/artifactregistry.writer）を付与する必要があります。
すべてのリポジトリのコンテンツは、Google が管理する暗号鍵か顧客管理の暗号鍵を使用して暗号化されます。Artifact Registry はデフォルトで Google が管理する暗号鍵を使用するため、このオプションの構成は不要です。
Cloud Storage バケットにアクセスする
Dataflow プロジェクトに Cloud Storage バケットへのアクセス権を付与するには、Dataflow プロジェクトのワーカー サービス アカウントからそのバケットにアクセスできるようにします。少なくとも、サービス アカウントには、バケットとそのコンテンツの両方に対する読み取りと書き込みの権限が必要です。必要なアクセス権は、Cloud Storage の IAM 権限を使用して付与できます。
バケットに対する読み取りと書き込みに必要な権限をワーカー サービス アカウントに付与するには、gcloud storage buckets add-iam-policy-binding コマンドを使用します。このコマンドは、Dataflow プロジェクトのサービス アカウントをバケットレベルのポリシーに追加します。
gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" --role=SERVICE_ACCOUNT_ROLE
次のように置き換えます。
- BUCKET_NAME: Cloud Storage バケットの名前
- PROJECT_NUMBER: Dataflow プロジェクト番号。プロジェクト番号を確認するには、プロジェクトを特定するに記載されている手順を実施するか、
gcloud projects describeコマンドを使用します。 - SERVICE_ACCOUNT_ROLE: IAM ロール
オブジェクトやマネージド フォルダの一覧表示、作成、表示、削除など、サービス アカウントがストレージ オブジェクトを完全に制御する必要がある場合は、サービス アカウントに Storage オブジェクト管理者（roles/storage.objectAdmin）ロールを付与します。
Google Cloud プロジェクト内の Cloud Storage バケットのリストを取得するには、gcloud storage buckets list コマンドを使用します。
gcloud storage buckets list --project= PROJECT_ID
PROJECT_ID は、プロジェクトの ID に置き換えます。
リソース共有を制限する組織のポリシーによって制限されていない限り、Dataflow パイプラインとは異なるプロジェクトのバケットにアクセスできます。ドメインの制限の詳細については、ドメイン別の ID の制限をご覧ください。
バケットがない場合は、新しいバケットを作成します。次に、バケットに対する読み取りと書き込みに必要な権限をワーカー サービス アカウントに付与します。
バケットの権限は Google Cloud コンソールで設定することもできます。詳細については、バケット権限の設定をご覧ください。
Cloud Storage には、バケットとオブジェクトにアクセスするためのユーザー権限を付与する 2 つのシステムが用意されています。1 つは IAM、もう 1 つはアクセス制御リスト（ACL）です。通常は、IAM を使用してリソースへのアクセスを制御することをおすすめします。
IAM は、Google Cloud 全体の権限を制御し、バケットレベルとプロジェクト レベルで権限を付与できます。Cloud Storage に関連付けられている IAM ロールと各ロールに含まれる権限のリストについては、Cloud Storage に適用される IAM ロールをご覧ください。権限をより細かく制御する必要がある場合は、カスタムロールを作成します。
ACL を使用してアクセスを制御する場合は、ワーカー サービス アカウントの権限が IAM 設定と一致していることを確認してください。IAM ポリシーと ACL ポリシーの不一致により、Cloud Storage バケットがきめ細かいアクセスから均一なバケットレベルのアクセスに移行されると、Cloud Storage バケットが Dataflow ジョブにアクセスできなくなる可能性があります。詳細については、一般的なエラーのガイダンスをご覧ください。
BigQuery データセットにアクセスする
BigQueryIO API を使用すると、Dataflow を使用しているプロジェクトと同じプロジェクト、または別のプロジェクトに含まれる BigQuery データセットにアクセスできます。BigQuery ソースとシンクが正しく動作するためには、Dataflow ジョブで読み書きする BigQuery データセットに対するアクセス権が次の 2 つのアカウントに付与されている必要があります。
- Dataflow ジョブの実行に使用する Google Cloud アカウント。
- Dataflow ジョブを実行するワーカー サービス アカウント。
場合によっては、BigQuery を構成してこれらのアカウントにアクセス権を明示的に付与する必要があります。BigQuery ページまたは BigQuery API を使用して BigQuery データセットに対するアクセス権を付与する方法については、BigQuery アクセス制御をご覧ください。
必要な BigQuery 権限の中で、BigQuery データセットにアクセスするにはパイプラインで bigquery.datasets.get IAM 権限が必要です。通常、BigQuery IAM ロールのほとんどに bigquery.datasets.get 権限が含まれていますが、roles/bigquery.jobUser ロールは例外です。
たとえば、Google Cloud アカウントが cloudysanfrancisco@gmail.com で、Dataflow ジョブを実行するプロジェクトのプロジェクト番号が 123456789 の場合、使用する BigQuery データセットへのアクセス権をアカウント cloudysanfrancisco@gmail.com と 123456789-compute@developer.gserviceaccount.com に付与する必要があります。
Pub/Sub トピックとサブスクリプションにアクセスする
Pub/Sub トピックまたはサブスクリプションにアクセスするには、Pub/Sub の Identity and Access Management 機能を使用して、ワーカー サービス アカウントの権限を設定します。
次の Pub/Sub のロールの権限が関連しています。
- データを使用するには、
roles/pubsub.subscriberが必須です。 - Pub/Sub サブスクリプションを作成するには、
roles/pubsub.editorが必要です。 - Dataflow がトピックとサブスクリプションの構成をクエリできるようにするため、
roles/pubsub.viewerの使用をおすすめします。この構成には 2 つの利点があります。- Dataflow は、正常に動作しない可能性のあるサブスクリプションでサポートされていない設定をチェックします。
- サブスクリプションがデフォルトの確認応答期限（10 秒）を使用していなければ、パフォーマンスが向上します。Dataflow は、メッセージがパイプラインで処理されている間、メッセージの確認応答期限を繰り返し延長します。
pubsub.viewer権限がないと、Dataflow は確認応答期限を確認できないため、デフォルトの期限を前提とします。この構成により、Dataflow は必要以上に modifyAckDeadline リクエストを発行します。 - サブスクリプションまたはトピックを所有するプロジェクトで VPC Service Controls が有効になっている場合は、IP アドレスに基づく上り（内向き）ルールのため、Dataflow で構成をクエリすることはできません。この場合、ワーカー サービス アカウントに基づく上り（内向き）ルールが必要です。
Pub/Sub の Identity and Access Management 機能の詳細と使用方法を示すコードサンプルについては、サンプル ユースケース: プロジェクト間通信をご覧ください。
Firestore にアクセスする
ネイティブ モードまたは Datastore モードで Firestore データベースにアクセスするには、データベースを所有するプロジェクトの編集者として Dataflow ワーカー サービス アカウント（PROJECT_NUMBER-compute@developer.gserviceaccount.com など）を追加するか、より制限の厳しい Datastore のロール（roles/datastore.viewer など）を使用します。また、Google Cloud コンソールの API ライブラリで、両方のプロジェクトで Firestore API を有効にします。
信頼できるイメージのポリシーを使用してプロジェクトのイメージにアクセスする
プロジェクトに信頼できるイメージのポリシーを設定していて、ブートイメージが別のプロジェクトにある場合は、そのイメージにアクセスできるように、信頼できるイメージのポリシーが構成されていることを確認します。たとえば、テンプレート化された Dataflow ジョブを実行する場合は、ポリシー ファイルに dataflow-service-producer-prod プロジェクトへのアクセス権が含まれていることを確認します。この Google Cloud プロジェクトには、テンプレート ジョブ用のイメージが含まれています。
データアクセスとセキュリティ
Dataflow サービスは 2 種類のデータを処理します。
エンドユーザー データ。このデータは Dataflow パイプラインによって処理されます。一般的なパイプラインは 1 つ以上のソースからデータを読み取り、データの変換を実装して、結果を 1 つ以上のシンクに書き込みます。すべてのソースとシンクは、Dataflow によって直接管理されないストレージ サービスです。
オペレーション データ。このデータには、Dataflow パイプラインの管理に必要なすべてのメタデータが含まれています。このデータには、ユーザーが提供するメタデータ（ジョブ名やパイプライン オプションなど）とシステムが生成したメタデータ（ジョブ ID など）の両方が含まれます。
Dataflow サービスは、データのセキュリティとプライバシーを保つためにさまざまなセキュリティ メカニズムが使用されています。こうしたメカニズムは次のシナリオに適用されます。
- サービスにパイプラインを送信する
- パイプラインを評価する
- パイプラインの実行中と実行後にテレメトリーと指標へのアクセスをリクエストする
- Shuffle や Streaming Engine などの Dataflow サービスを使用する
データの局所性
Dataflow サービスのすべてのコアデータ処理は、パイプライン コードで指定されたリージョンで行われます。リージョンが指定されていない場合は、デフォルトのリージョン us-central1 が使用されます。このオプションをパイプライン コードに指定すると、パイプライン ジョブは、他のリージョンのソースやシンクからの読み取りと書き込みを任意で行うことができます。ただし、実際のデータ処理は、Dataflow VM の実行が指定されたリージョンでのみ行われます。
パイプライン ロジックは個々のワーカー VM インスタンスで評価されます。これらのインスタンスのゾーンと、それらが通信するプライベート ネットワークの場所を指定できます。プラットフォームの補助的な計算は、Cloud Storage のロケーションやファイルサイズなどのメタデータによって異なります。
Dataflow はリージョン サービスです。データのロケーションとリージョンの詳細については、Dataflow リージョンをご覧ください。
パイプライン送信のデータ
Google Cloud プロジェクトの IAM 権限は、Dataflow サービスへのアクセスを制御します。プロジェクトの編集者またはオーナーの権利を付与されたプリンシパルは、パイプラインをサービスに送信できます。パイプラインを送信するには、Google Cloud CLI を使用して認証を行う必要があります。認証後、パイプラインは HTTPS プロトコルを使用して送信されます。Google Cloud アカウントの認証情報で認証する方法については、使用している言語のクイックスタートをご覧ください。
パイプライン評価のデータ
パイプラインの評価で一時的なデータが生成され、ローカルのワーカー VM インスタンスまたは Cloud Storage に保存されます。一時データは保存時に暗号化されますが、パイプライン評価の完了後は保持されません。このようなデータは、Shuffle サービスまたは Streaming Engine サービス（Dataflow を有効にしている場合）でも、Dataflow パイプラインで指定されたリージョンに保存できます。
Java
デフォルトでは、Dataflow ジョブが完了すると、そのジョブが成功したか失敗したかを問わず Compute Engine VM が削除されます。その結果、関連付けられている Persistent Disk と、その中に格納されている中間データも削除されます。Cloud Storage に格納されている中間データは、--stagingLocation や --tempLocation として提供する、Cloud Storage パスのサブロケーションにあります。出力を Cloud Storage ファイルに書き込む場合、書き込みオペレーションがファイナライズされる前に一時ファイルが出力場所に作成されることがあります。
Python
デフォルトでは、Dataflow ジョブが完了すると、そのジョブが成功したか失敗したかを問わず Compute Engine VM が削除されます。その結果、関連付けられている Persistent Disk と、その中に格納されている中間データも削除されます。Cloud Storage に格納されている中間データは、--staging_location や --temp_location として提供する、Cloud Storage パスのサブロケーションにあります。出力を Cloud Storage ファイルに書き込む場合、書き込みオペレーションがファイナライズされる前に一時ファイルが出力場所に作成されることがあります。
Go
デフォルトでは、Dataflow ジョブが完了すると、そのジョブが成功したか失敗したかを問わず Compute Engine VM が削除されます。その結果、関連付けられている Persistent Disk と、その中に格納されている中間データも削除されます。Cloud Storage に格納されている中間データは、--staging_location や --temp_location として提供する、Cloud Storage パスのサブロケーションにあります。出力を Cloud Storage ファイルに書き込む場合、書き込みオペレーションがファイナライズされる前に一時ファイルが出力場所に作成されることがあります。
パイプライン ログとテレメトリーのデータ
Cloud Logging に格納される情報は、主に Dataflow プログラムのコードによって生成されます。Dataflow サービスは Cloud Logging に警告やエラーデータを生成することもありますが、これはサービスがログに追加する単なる中間データです。Cloud Logging はグローバル サービスです。
テレメトリー データと関連指標は暗号化した状態で保存され、このデータに対するアクセス権は Google Cloud プロジェクトの読み取り権限によって制御されます。
Dataflow サービスのデータ
パイプラインに Dataflow Shuffle または Dataflow Streaming を使用する場合は、ゾーン パイプライン オプションを指定しないでください。代わりに、リージョン オプションを使用して、Shuffle または Streaming を利用できるリージョンのいずれかを指定します。Dataflow は、指定されたリージョンのゾーンを自動的に選択します。転送中のエンドユーザー データはワーカー VM 内と同じゾーン内に存在します。これらの Dataflow ジョブは引き続き、VM ゾーン外のソースとシンクに対する読み取りと書き込みを行うことができます。転送中のデータは、Dataflow Shuffle サービスまたは Dataflow ストリーミング サービスにも送信できますが、データは常にパイプライン コードで指定されたリージョンに残ります。
推奨事項
パイプラインの基盤となるクラウド リソースにあるセキュリティ メカニズムを使用することをおすすめします。これらのメカニズムには、BigQuery や Cloud Storage など、データソースとシンクのデータ セキュリティ機能が含まれます。また、単一のプロジェクトに異なる信頼レベルが混在しないように配慮してください。