プレイブック

継続的かつ大量のデータは、到着から数分以内に分析する必要があります。

→取り込みにはPub/Sub -> 変換にはDataflow (ストリーミング) -> 分析にはストリーミングインサートまたはStorage Write APIを使用したBigQuery。

理由: これは、一般的なサーバーレス、オートスケーリングストリーミングパターンです。バッチ処理 (例: Dataproc) では、低レイテンシ要件を満たすことはできません。

データパイプラインは、予期せぬトラフィックスパイク (例: 季節的なボリュームが10倍) を処理し、低レイテンシを維持する必要があります。

→フルマネージドのオートスケーリングサービスを使用します: 取り込みにはPub/Sub、オートスケーリングが有効なDataflow、ストレージにはBigQuery。

理由: マネージドサービスは、負荷に合わせてリソースを自動的にスケーリングし、過剰なプロビジョニングコストを回避し、ピークトラフィック時でもパフォーマンスを確保します。

大規模なオンプレミスHadoop/HiveデータウェアハウスをGoogle Cloudに移行します。

→データをCloud Storageに移行し、BigQueryにロードします。サーバーレス分析にはHive/Spark SQLをBigQueryに置き換えます。SQLに簡単に変換できないSparkジョブにはDataprocを使用します。

理由: BigQueryは、Hadoopデータウェアハウスに代わるサーバーレスで高性能なソリューションを提供し、運用オーバーヘッドを削減します。

ストリーミングパイプラインは、各エンティティ (例: 銘柄ごと) のメッセージを、正確に1回、順序どおりに処理する必要があります。

→順序キーを持つメッセージをPub/Subにパブリッシュします。指定されたキーに対して順序どおりの処理を保証するDataflowストリーミングパイプラインで処理します。

理由: Pub/Subの順序キーとDataflowを組み合わせることで、手動の状態管理なしで、マネージドでスケーラブルな順序付けされた正確に1回の処理を提供します。

リファレンス↗

データガバナンスを備えたバッチおよびストリーミングワークロードの両方をサポートする、柔軟でスケーラブルなデータレイクを構築します。

→ストレージレイヤーとしてCloud Storageを使用します。バッチ処理とストリーム処理の両方にDataflowを使用します。メタデータ管理、検出、ガバナンスにはDataplexとData Catalogを使用します。

理由: このアーキテクチャは、ストレージとコンピューティングを分離し、統一されたガバナンスを備えた中央データストアで複数の処理エンジン (Dataflow、Dataproc) を使用できるようにします。

機密データ (例: PHI、PII) を処理するパイプラインは、HIPAAやGDPRなどの規制に準拠する必要があります。

→すべてのデータアクセスに対してCloud Audit Logsを有効にします。VPC Service Controlsを実装して、データ漏洩を防ぐセキュリティ境界を作成します。

理由: 監査ロギングは、コンプライアンスのためのデータアクセスを追跡する上で不可欠です。VPC Service Controlsは、機密データの主要な要件であるデータ漏洩に対する強力な防御を提供します。

バッチレイヤーとスピードレイヤーが分離されたラムダアーキテクチャは、データの統一されたビューを提示する必要があります。

→サービングレイヤーにはBigQueryを使用します。`MERGE`ステートメントを使用して、バッチ処理されたデータをマスターテーブルに更新/挿入し、同じ期間のストリーミングデータを上書きします。現在の期間の履歴バッチデータとリアルタイムストリーミングデータを`UNION`するビューを公開します。

理由: このパターンは、クライアント側の調整ロジックを必要とせずに、低レイテンシのリアルタイムビューとバッチ修正された履歴精度を提供します。

ドメインが自身のデータ製品を所有する、分散型データメッシュアーキテクチャを実装します。

→ドメイン固有の「レイク」と「ゾーン」に対するフェデレーションガバナンスにはDataplexを使用します。ドメインごとにBigQueryデータセットを使用します。ドメイン間でデータ製品を共有するにはAnalytics Hubを使用します。

理由: Dataplexは、データメッシュの核となる原則であるドメインの自律性を許容しながら、中央ガバナンスプレーンを提供します。

データレイクとデータウェアハウスを組み合わせ、未加工データに対するSparkジョブと、キュレートされたデータに対する高速SQLを可能にします。

→Cloud Storageにオープンフォーマット (Iceberg, Delta Lake) でデータを保存します。統一されたガバナンスおよびアクセスレイヤーを提供するためにBigLakeを使用します。Dataproc (Spark) とBigQueryの両方からデータをクエリします。

理由: BigLakeは、Cloud Storage上のデータをBigQueryのパフォーマンスときめ細かなセキュリティでインプレースクエリすることを可能にし、レイクとウェアハウスを統合します。

低いRPO (例: 1時間) を持つ重要なBigQueryデータウェアハウスの災害復旧戦略を設計します。

→重要なデータセットに対してBigQueryのクロスリージョンデータセットレプリケーションを構成します。スキーマとビュー定義の管理にはTerraformまたはDataformを使用します。Cloud MonitoringアラートによってトリガーされるCloud Functionsでフェイルオーバーをオーケストレーションします。

理由: クロスリージョンレプリケーションは、DRリージョンで継続的に更新され、クエリ可能なコピーを提供し、重要なデータに対する低いRPO/RTO要件を満たします。

OLTPデータベース (例: Oracle, PostgreSQL, MySQL) からBigQueryへの変更を低レイテンシで継続的にレプリケーションします。

→Datastreamを使用してChange Data Capture (CDC) を実行します。変更をBigQueryに直接ストリーミングするように構成し、BigQueryがその`MERGE`機能を使用してそれらを適用します。

理由: Datastreamは、マネージドサーバーレスCDCサービスであり、カスタムパイプラインやソースデータベースへの大きな負荷を必要とせずに、リアルタイムのデータベースレプリケーションを簡素化します。

リファレンス↗

Dataflowストリーミングパイプラインは、一部のイベントが数時間遅れて到着しても、正確なイベント時刻ウィンドウの結果を生成する必要があります。

→遅延に対応するために`allowedLateness`を設定したイベント時刻ウィンドウを構成します。速報結果のために早期発火するトリガーを使用し、遅延データを含めるために発火したペインを蓄積します。

理由: Dataflowのウォーターマーク、トリガー、および許容遅延のモデルは、順不同データを処理する際に完全性とレイテンシのバランスをとるための堅牢なフレームワークを提供します。

BigQueryに書き込むDataflowパイプラインが、再起動後または一時的な障害後に重複を経験します。

→BigQuery Storage Write APIシンク (`STORAGE_WRITE_API`) を使用し、メソッドを`at-least-once` (デフォルト、以前は`STREAMING_INSERTS`) または`exactly-once` (`COMMITTED`モード) に設定します。

理由: `COMMITTED`モードのStorage Write APIは、ストリーミング用の組み込みの正確に1回セマンティクスを提供し、カスタムの重複排除ロジックの必要性を排除します。

Dataflowを使用して、ページネーションされ、レート制限されたREST APIからデータを取り込みます。

→`SplittableDoFn`を使用して、ページネーションされたソースを並行して処理します。DoFn内でレート制限ロジック (例: Guava RateLimiterを使用) と、再試行のための指数バックオフを実装します。

理由: `SplittableDoFn`は、動的な作業再調整を可能にします。これをレート制限と再試行ロジックと組み合わせることで、外部APIを処理するための回復力があり効率的なパターンが作成されます。

単一のデータストリームを複数の宛先 (例: BigQuery, Bigtable, Cloud Storage) に書き込む必要があります。

→単一のDataflowパイプラインで、初期処理後、同じ最終`PCollection`に複数の`PTransform`ライターを適用します。

理由: ファンアウトパターンは、データが1回しか処理されないため、非常に効率的です。同じソースから読み取る複数の個別のパイプラインを実行するコストと複雑さを回避します。

高ボリュームのストリームは、定期的に更新されるスローリーチェンジングディメンションテーブル (例: ユーザープロファイル) と結合してエンリッチされる必要があります。

→Dataflowでサイド入力パターンを使用します。ディメンションテーブルを`PCollectionView`としてロードします。パイプラインの再起動を防ぐために、定期的なトリガーを構成してスケジュールに基づいてサイド入力をリフレッシュします。

理由: サイド入力は、ディメンションデータをすべてのワーカーにブロードキャストして高速なインメモリ検索を可能にし、要素ごとのAPI/DB呼び出しを回避します。定期的なリフレッシュは更新を効率的に処理します。

Dataprocクラスターのワークロードは大幅に変動するため、過剰なプロビジョニングまたはパフォーマンス不足につながります。

→オートスケーリングポリシーを持つDataprocクラスターを作成します。プライマリおよびセカンダリワーカーの最小/最大数を定義します。ポリシーはYARNメトリックに基づいてクラスターをスケーリングします。

理由: オートスケーリングは、クラスターリソースをジョブ需要に合わせることでコストを最適化し、高負荷時にはスケールアップし、アイドル時にはスケールダウンします。

Dataflowパイプラインは、カスタムバイナリ、プロプライエタリライブラリ、または標準ワーカーイメージにない特定のバージョンを必要とし、インターネットのないVPCで実行する必要があります。

→すべての依存関係がプリインストールされたカスタムコンテナイメージを構築します。イメージをArtifact Registryにプッシュします。カスタムコンテナを参照するFlex Templateを使用してパイプラインをデプロイします。

理由: カスタムコンテナを持つFlex Templateは、ランタイム環境と依存関係に対する完全な制御を提供し、オフラインまたは特殊な環境にとって非常に重要です。

`GroupByKey`を実行するDataflowまたはSparkジョブが、一部のキーに不均衡に多くの値がある (「ホットキー」) ために遅くなります。

→2段階の集約 (キーソルティング) を実装します。まず、キーにランダムなサフィックスを追加して、ホットキーを複数のワーカーに分割します。部分的に集約します。次に、サフィックスを削除し、部分的な結果を集約します。

理由: このファンアウト技術は、ホットキーの作業を手動で分割し、並行して処理できるようにしてボトルネックを克服します。

ストリーミングパイプラインは、不正な形式のレコードのために失敗してはなりません。無効なレコードは、処理を停止せずに分析のために隔離する必要があります。

→`DoFn`内で、解析のためにtry-catchブロックを使用します。`TupleTag`付きの複数出力DoFnを使用して、有効なレコードをメイン出力に、無効なレコード (エラーコンテキスト付き) を別のエラー出力にルーティングします。エラーPCollectionをPub/SubトピックまたはBigQueryテーブルなどのデッドレター宛先にシンクします。

理由: このパターンは、不正なデータを隔離し、パイプラインの障害を防ぎ、失敗したレコードがデバッグと再処理のためにキャプチャされることを保証することで、回復力をもたらします。

BigQueryクエリが遅く高価で、通常は日付/時刻列やその他のカーディナリティの高い列 (例: `customer_id`) でフィルタリングされます。

→日付/時刻列でテーブルをパーティショニングします (例: 日次パーティション)。最大4つの頻繁にフィルタリングされる列 (例: `customer_id`、`product_category`) でテーブルをクラスタリングします。

理由: パーティショニングは、スキャンされるデータを関連する期間のみに刈り込みます。クラスタリングは、パーティション内のデータをさらにソートし、クラスタリングされた列のフィルタリングのためにスキャンされるデータを最小限に抑えます。これは、主要なBQパフォーマンスチューニングパターンです。

リファレンス↗

アプリケーションは、リアルタイムパーソナライゼーションやIoT特徴ストアなどの大規模データセット (数十億行) に対して、低レイテンシ (10ms未満) の読み取りおよび書き込みを必要とします。

→Bigtableを使用します。主要なアクセスパターンをサポートする行キーを設計します。時系列データには`entity_id#reverse_timestamp`を使用します。

理由: Bigtableは、大規模な高スループット、低レイテンシワークロード向けに最適化されたNoSQLワイドカラムストアです。BigQueryは分析用であり、ポイントルックアップのレイテンシが高くなります。

トランザクションアプリケーションは、グローバル分散、水平スケーラビリティ、およびSQLインターフェースによる強力な一貫性を必要とします。

→マルチリージョン構成でCloud Spannerを使用します。

理由: Spannerは、グローバル分散、ACIDトランザクション、リレーショナルスキーマというこれらすべての機能を提供する唯一のサービスです。Cloud SQLはリージョンであり、Bigtableはリレーショナルではなく、クラスター間で最終的な一貫性があります。

BigQueryデータウェアハウスには、クエリされる頻度は低いが保持する必要がある大量の履歴データがあり、高いストレージコストにつながっています。

→90日間連続して変更されていないパーティション/テーブルについては、アクションは不要です。BigQueryは自動的に長期保存料金を適用し、約50%のコスト削減になります。

理由: これは自動的に組み込まれた最適化です。データを手動でGCSに移動すること (アーカイブティアの場合を除く) は、多くの場合不要であり、複雑さを増します。

Cloud Storageバケット内のデータには予測可能なアクセスパターンがあります: 30日間は頻繁、90日間はたまに、その後は稀。

→オブジェクトを移行するバケットライフサイクルポリシーを構成します: Standard -> Nearline (30日後) -> Coldline (90日後)。

理由: ライフサイクルポリシーは、データへのアクセス頻度が低下するにつれて、より安価なストレージクラスにデータを移動することでコスト最適化を自動化します。

BigQueryテーブルは、一意キー制約を強制する必要があります。

→ロードパイプラインで一意性を強制します。キーがすでに存在しない場合にのみ挿入するロジックを持つ`MERGE`ステートメントを使用します。または、DataflowでステートフルなDoFnを使用して重複を排除します。

理由: BigQueryは`PRIMARY KEY`または`UNIQUE`制約を強制しません。一意性はデータロードプロセスによって管理される必要があります。

BigQueryのディメンションテーブルは、時点分析 (SCD Type 2) のために変更の完全な履歴を保持する必要があります。

→`valid_from`と`valid_to`のタイムスタンプ列を追加します。変更が発生した場合、`MERGE`ステートメントを使用して古いレコードの`valid_to`を更新し、新しいレコードを挿入します。

理由: これは、データウェアハウスでSCD Type 2を実装するための標準パターンです。`MERGE`は、必要な更新および挿入操作を実行するための効率的かつアトミックな方法を提供します。

アプリケーションは、トランザクションサポートと複雑なクエリニーズを備えた、柔軟なスキーマのJSONドキュメントのためのマネージドでスケーラブルなデータベースを必要とします。

→NativeモードでFirestoreを使用します。コレクション、ドキュメント、およびサブコレクションを利用してデータをモデル化します。複雑なクエリのために複合インデックスを作成します。

理由: Firestoreは、トランザクションワークロード向けに最適化されたサーバーレスのNoSQLドキュメントデータベースであり、豊富なクエリ機能を備えています (Bigtable (キーバリュー) やBigQuery (分析) とは異なります)。

きめ細かな (行/列) セキュリティを強制しながら、BigQuery経由でCloud Storage (Parquet、Avroなど) のデータをクエリする必要があります。

→Cloud Storageデータ上にBigLakeテーブルを作成します。BigLakeテーブルに行レベルおよび列レベルのBigQueryセキュリティポリシーを適用します。

理由: BigLakeは、BigQueryガバナンスをCloud Storageのオープンフォーマットデータに拡張し、セキュアで統一されたデータレイクハウスアーキテクチャを可能にします。

データサイエンスチームは、データを移動またはエクスポートすることなく、大規模なBigQueryデータセットでMLモデルをトレーニングする必要があります。

→BigQuery MLを使用します。SQLで`CREATE MODEL`ステートメントを記述して、BigQuery内で直接トレーニング、評価、予測を行います。

理由: BQMLはデータ移動を排除し、MLワークフローを簡素化し、BigQueryの処理能力を活用して反復を加速します。

リファレンス↗

MLモデルは、バッチトレーニングと低レイテンシのオンライン推論の両方で特徴を必要とし、スキューを回避するためにそれらの間の一貫性が必要です。

→Vertex AI Feature Storeを使用します。バッチまたはストリーミングを介して特徴を取り込みます。トレーニング用のオフラインストア (BigQuery) と、低レイテンシのサービング用のオンラインストア (Bigtable) を提供します。

理由: これは、特徴の一貫性、時点の正確性、およびデュアルサービング要件という複雑な問題を解決するために特別に構築されたマネージドサービスです。

ビジネスユーザーはセルフサービスBIを必要としますが、データウェアハウスを直接クエリすると、一貫性のないメトリックとレポートを作成してしまいます。

→LookMLを使用してLookerセマンティックレイヤーを実装します。ディメンション、メジャー、および結合を一度定義します。ユーザーは生のテーブルではなく、ガバナンスされたモデルを探索します。

理由: LookMLはビジネスロジックの「唯一の信頼できる情報源」を提供し、セルフサービス探索を可能にしながら、一貫性のある正確なレポート作成を保証します。

BigQueryおよびCloud Storage内のデータに対して、自動データ品質チェック (NULL、一意性、値の範囲) とモニタリングを実装する必要があります。

→Dataplex Data Qualityを使用します。YAMLでルールを定義するか、プロファイリングから自動生成されたルールを使用します。時間経過に伴う品質を監視するためにスキャンをスケジュールします。

理由: Dataplexは、カスタムSQLチェックやスクリプトよりもスケーラブルで保守しやすい、マネージド統合データ品質ソリューションを提供します。

事前定義されたラベルなしで、顧客データセット内の自然なグループ分けまたはセグメントを発見します。

→BigQuery MLを使用して、顧客データに対して直接`KMEANS`クラスタリングモデルをトレーニングします。

理由: K-meansはセグメンテーションに最適な教師なし学習アルゴリズムです。BQMLは、データエクスポートなしでSQL経由で利用可能にします。

BigQueryに保存されているテキストデータに対して、セマンティック検索 (キーワードではなく意味に基づく) を有効にします。

→`ML.GENERATE_EMBEDDING`関数をVertex AI基盤モデルとともに使用して、ベクトル埋め込みを作成します。それらを保存し、類似性検索のために`VECTOR_SEARCH`関数を使用します。

理由: このパターンは、強力なセマンティック検索機能をBigQueryに直接もたらし、Elasticsearchのような外部検索インデックスの必要性を回避します。

テキスト要約や分類などの大規模言語モデル (LLM) 機能をBigQuery分析ワークフローに直接統合します。

→Vertex AI LLMエンドポイントを指すBigQuery MLリモートモデルを作成します。SQLクエリ内で`ML.GENERATE_TEXT`関数を使用してテキストデータを処理します。

理由: これにより、生成AIがSQLに密接に統合され、アナリストはBigQuery環境を離れることなく、または複雑なアプリケーションコードを記述することなく、LLMをデータに活用できます。

多段階のデータパイプラインには、異なるGCPサービス (例: Dataflow, BigQuery, Dataproc) にわたる複雑な依存関係、再試行、およびタスクが含まれます。

→Cloud Composer (マネージドApache Airflow) を使用します。Pythonを使用してワークフローをDAG (有向非巡回グラフ) として定義します。

理由: Composerは、複雑なワークフローオーケストレーションのための指定されたGCPツールであり、Cloud Schedulerのようなよりシンプルなツールにはない、堅牢な依存関係管理、スケジューリング、再試行ロジック、およびモニタリングを提供します。

外部APIを呼び出すAirflow DAGタスクが、一時的なネットワークの問題により頻繁に失敗します。

→DAGでタスクレベルの再試行を`retry_exponential_backoff=True`で構成します。これにより、再試行間の遅延が増加し、外部システムが回復する時間を確保できます。

理由: 指数バックオフは、一時的な障害を再試行するためのベストプラクティスであり、苦戦しているダウンストリームシステムを高速で繰り返しのリクエストで圧倒することを回避します。

BigQueryにおける複雑な相互依存SQL変換のセットを管理、バージョン管理、テスト、スケジュールします。

→Dataformを使用します。SQLXファイルでテーブルと依存関係を定義し、バージョン管理にGitを使用し、データ品質アサーションを記述し、実行ワークフローをスケジュールします。

理由: Dataformは、ELT向けのGoogle Cloudのネイティブソリューションであり、BigQuery変換のための依存関係管理、テスト、バージョン管理を提供し、DataOpsのベストプラクティスを推進します。

BigQueryやDataflowなどの複数のサービス間で、データがソースから最終レポートまでどのように流れるかを理解し、視覚化する必要があります。

→Dataplexを使用します。これは、サポートされているGoogle CloudサービスからのデータリネージュをData Catalog UIに自動的にキャプチャして表示します。

理由: 自動リネージュ追跡は、影響分析、デバッグ、ガバナンスにとって不可欠です。Dataplexは、統合されたサービスに対してこれをすぐに利用できるように提供します。

実行中のDataflowストリーミングジョブは、データや状態を失うことなく新しいロジックで更新する必要があります。

→`--update`コマンドラインオプションを使用して新しいパイプラインバージョンを起動し、実行中のパイプラインのジョブIDを指定します。`drain`モードを使用して、古いジョブが処理中のデータの処理を完了できるようにします。

理由: Dataflowのインプレース更新メカニズムは、状態を保持し、正確に1回の処理を保証しながら、ストリーミングパイプラインへの変更をゼロダウンタイムでデプロイする方法を提供します。

コンプライアンスのため、BigQueryおよびCloud Storage内の機密データへのすべての読み取りおよび書き込みアクセスはログに記録され、監査可能である必要があります。

→関連するサービスに対してCloud Audit Logs、特にデータアクセスログを有効にします。これらのログをBigQueryにエクスポートするためのログシンクを作成し、長期的な保持と分析に役立てます。

理由: Cloud Audit Logsは、データアクセスの改ざん防止された包括的な記録を提供します。ログをBigQueryにシンクすることで、強力なSQLベースの監査およびレポート作成が可能になります。

BigQueryのデータセット、テーブル、およびアクセス制御は、再現性とバージョン管理のためにコードとして管理する必要があります (Infrastructure as Code)。

→すべてのBigQueryリソース (データセット、テーブル、IAMポリシー) をTerraform設定ファイル (`.tf`) で定義します。CI/CDパイプラインを介してデプロイを管理します。

理由: TerraformはGCP上のIaCの標準であり、データインフラストラクチャの監査済み、バージョン管理済み、一貫性のある管理を可能にし、手動設定のずれを防ぎます。

本番環境のMLモデルのパフォーマンスが時間とともに低下しています。

→Vertex AIモデルモニタリングを実装します。本番トラフィックをベースラインと比較して、トレーニングとサービングのスキューおよび予測のドリフトを検出するようにモニタリングジョブを構成します。調査または自動再トレーニングをトリガーするアラートを設定します。

理由: モデルのパフォーマンスはデータドリフトにより低下します。これを検出し、モデルの精度を維持するために、事前のモニタリングは不可欠であり、再トレーニングの正当化となります。