プレイブック

Cloud StorageからBigQueryに大量のバッチファイル（CSV、Parquet、Avro）をロードする。

→BigQueryのロードジョブを使用する。単一のジョブで複数のファイルをロードするために、ワイルドカードURI（例：`gs://bucket/path/*`）を指定する。

理由: これはバッチ取り込みにおいて最も高速で費用対効果の高い方法である。ロードジョブは無料であり、ストリーミングの行ごとのコストを回避できる。

リファレンス↗

変換の可能性を考慮しつつ、大量のリアルタイムデータ（IoT、クリックストリーム）を取り込む。

→Pub/Sub -> Dataflow -> BigQuery を使用する。

理由: これは標準的なスケーラブルなストリーミングパターンである。Pub/Subは耐久性のあるスケーラブルなバッファを提供し、Dataflowは複雑な変換、ウィンドウ処理、およびexactly-once処理を可能にする。

運用データベース（MySQL、PostgreSQL、Oracle）を低レイテンシでBigQueryにレプリケートし、すべての変更（挿入、更新、削除）をキャプチャする。

→Change Data Capture (CDC) に Datastream を使用する。

理由: 低インパクトのリアルタイムCDC向けに特化して構築されている。初期のバックフィルを処理し、継続的な変更をBigQueryに直接ストリーミングする。

リファレンス↗

BigQueryへのロード前に、複雑なデータ検証、エンリッチメント、または変換（例：ネストされたJSON/XMLのフラット化）を実行する。

→カスタムのApache Beam変換（例：ParDo）を含むDataflowパイプラインを使用する。

理由: Dataflowは、カスタムコード（Python/Java）、複雑なロジック、および無効なレコードをデッドレターキューにルーティングするための最大の柔軟性を提供する。

テラバイトまたはペタバイト規模のデータを、別のクラウド（例：S3）またはオンプレミスのデータセンターからCloud Storageに転送する。

→クラウド間転送にはStorage Transfer Serviceを使用する。ネットワーク帯域幅が限られているオンプレミス環境ではTransfer Applianceを使用する。

理由: STSは、オンライン転送用のマネージド型高性能サービスである。Transfer Applianceは、ネットワークがボトルネックになる場合のオフライン（物理的な輸送）転送用である。

Cloud StorageまたはAmazon S3に存在するデータを、ロードせずにBigQueryから直接クエリする。

→BigQuery外部テーブルを作成する。Sparkとの統合ガバナンスのためには、BigLakeテーブルを使用する。

理由: BigQueryでのデータ重複とストレージコストを回避する。BigLakeは、オブジェクトストレージデータに対するきめ細かなセキュリティ（行/列レベル）とガバナンスを追加する。

リファレンス↗

ソースファイル（JSON、Avro）に新しい列が追加された際に、取り込みパイプラインが自動的に適応する必要がある。

→BigQueryロードジョブを`schemaUpdateOptions`が`ALLOW_FIELD_ADDITION`に設定されるように構成する。

理由: スキーマ進化を自動化する。BigQueryはロードジョブを失敗させることなく、新しい列をテーブルスキーマに追加する。

レガシーなストリーミングAPIよりも低コストで、exactly-onceセマンティクスにより大量のデータをBigQueryにストリーミングする。

→BigQuery Storage Write API を使用する。

理由: 古い`insertAll` APIと比較して、より高いスループットと低コストを提供し、ストリーム内でのexactly-once配信のような強力な保証を備えている。

リファレンス↗

複数の依存タスク（例：Dataflow、BigQuery、Cloud Functions）を含む複雑なワークフローをスケジュールに基づいてオーケストレーションする。

→Cloud Composer（マネージドApache Airflow）を使用する。

理由: 複雑なワークフローオーケストレーションの標準である。依存関係の定義、スケジューリング、リトライ、アラート、および豊富なオペレーターエコシステムのためのDAGを提供する。

Cloud Composer DAGが、特定のファイルがCloud Storageバケットに現れるまで一時停止し、待機してから続行する必要がある。

→Airflow DAGで`GCSObjectExistenceSensor`を使用する。

理由: これは外部条件を待機するための慣用的なAirflowの「センサー」パターンである。PythonOperator内のカスタムポーリングループよりも効率的である。

ストリーミングDataflowパイプラインが、イベントが順不同または遅れて到着した場合でも、タイムスタンプによってイベントを正しく集計する必要がある。

→ウォーターマーク付きのイベント時間ウィンドウ処理を使用し、`allowedLateness`を構成する。

理由: このDataflow/Beamのコア機能は、イベントが処理された時ではなく、イベントが発生した時に基づいてデータを正しくグループ化する。`allowedLateness`は遅延データが破棄されるのを防ぐ。

バッチ処理またはMLのために、大規模で非インタラクティブなApache Sparkジョブを実行する。

→Dataprocクラスターを使用する。コストを最大限に削減するには、Spot VM（旧プリエンプティブVM）を備えたエフェメラルクラスターを使用する。

理由: DataprocはマネージドSpark/Hadoopサービスである。エフェメラルクラスターはジョブの期間中のみ存在し、Spot VMは耐障害性のあるワークロードに対して大幅な割引を提供する。

異なるチームが様々なパラメータ（例：入力/出力パス）で実行できる、標準化されたDataflowパイプラインを作成する。

→パイプラインをDataflow Flex Templateとしてパッケージ化する。

理由: Flex Templateは、再利用可能なDataflowジョブの最新の標準である。これらはコンテナベースであり、カスタム依存関係をサポートし、実行時パラメータを受け入れる。

Cloud Composer DAGのタスクが、一時的な外部の問題（例：APIレート制限、リソース競合）により断続的に失敗する。

→タスクに対して`retries`と`retry_delay`を`retry_exponential_backoff=True`で設定する。

理由: これにより、失敗したタスクを自動的に、遅延を増やしながら再試行することでパイプラインに回復力をもたらし、多くの場合、手動介入なしに一時的な問題を解決する。

Dataflowストリーミングパイプラインが処理に遅れをとり、高いシステムラグまたはデータ鮮度の問題を示している。

→Dataflowの監視メトリックを調査する。オートスケーリングが`maxNumWorkers`の制限に達していないかを確認する。`maxNumWorkers`を増やすか、より大きなマシンタイプに切り替える。

理由: 高いシステムラグは、処理能力の不足を示す主要な指標である。パイプラインは、データ流入に対応するために、より多くの、またはより大きなワーカーを必要とする。

クエリコストとパフォーマンスのために、大規模なBigQueryテーブルを最適化する。

→頻繁にフィルタリングされる時間単位の列（例：トランザクション日付）でテーブルをパーティション分割する。他のカーディナリティが高く、頻繁にフィルタリングされる列（例：`customer_id`）でテーブルをクラスタリングする。

理由: パーティション分割は、スキャンされるデータ量を削減することでコストとレイテンシを削減する最も効果的な方法である。クラスタリングは、パーティション内のデータをソートすることでパフォーマンスをさらに向上させる。

リファレンス↗

有効な認証情報を持つユーザーによっても、機密性の高いBigQueryデータセットからのデータが不正な宛先（例：公開GCSバケット）にコピーされるのを防ぐ。

→VPC Service Controlsを使用して、BigQueryデータセットを含むプロジェクトの周囲にサービス境界を作成する。

理由: VPC Service ControlsはGCPサービスに対する「仮想ファイアウォール」として機能し、データが境界を離れるのを防ぐ。これはデータ流出に対する重要な多層防御制御である。

リファレンス↗

BigQueryテーブル内の機密性の高い列（例：PII）へのアクセスを承認されたグループに制限し、他のユーザーが残りの列をクエリできるようにする。

→Data Catalogを使用してタクソノミーとポリシータグを作成する。機密性の高い列にポリシータグを適用し、承認されたグループに「Fine-Grained Reader」ロールを付与する。

理由: これはBigQueryにおける列レベルセキュリティのためのネイティブでスケーラブルな方法である。個別のビューを作成および管理する必要なく、一元化されたガバナンスを提供する。

ユーザーが自分に関連する行のみを表示できるようにテーブルをフィルタリングする（例：営業マネージャーは自分の地域のデータのみを表示）。

→`SESSION_USER()`に基づいて行をフィルタリングする行レベルセキュリティポリシーをテーブルに作成する。

理由: クエリ時に動的な述語ベースのフィルタリングを提供する。これは、各ユーザーまたはロールごとに承認されたビューを作成するよりも安全で管理しやすい。

規制に準拠するため（例：7年以上前のデータを削除）、指定された保持期間後にBigQueryテーブルからデータを自動的に削除する。

→時系列データの場合、時間パーティション分割テーブルにパーティション有効期限を設定する。その他のテーブルの場合、デフォルトのテーブル有効期限を設定する。

理由: これは、手動のクリーンアップスクリプトや外部オーケストレーションなしにコンプライアンスを確保する、組み込みの「設定して忘れる」機能である。

BigQueryテーブルが誤って変更または削除された。

→BigQuery Time Travelを使用して、`FOR SYSTEM_TIME AS OF`を用いて、インシデント発生前の特定の時点のテーブルをクエリする。

理由: BigQueryはテーブルデータの7日間の履歴を自動的に保持する。これにより、バックアップから復元する必要なく、タイムトラベル期間内で即座に復旧できる。

リファレンス↗

組織全体でデータアセット（BigQuery、GCS）を発見、管理、保護、監視する。

→Dataplex を使用する。

理由: Dataplexはインテリジェントなデータファブリックとして機能し、異なるデータサイロにまたがるデータガバナンス、品質、リネージ、発見、ライフサイクル管理のための統合されたペインを提供する。

データがソースシステムから変換ジョブを経て、最終的なレポートテーブルにどのように流れるかを理解し、視覚化する。

→Dataplex Data Lineage を使用する。

理由: BigQuery、Data Fusion、およびComposerのログからリネージ情報を自動的にキャプチャし、影響分析と監査のためにデータの依存関係のインタラクティブなグラフベースのビューを提供する。

他のユーザーからの「スロット競合」を避け、重要なワークロードの予測可能なクエリパフォーマンスとコストを確保する。

→BigQuery Editions（容量ベースの料金）を購入する。特定のプロジェクトまたはフォルダにスロットプールを割り当てるために予約を作成する。

理由: 共有のオンデマンドプールから専用のコンピューティング容量に切り替えることで、重要なジョブのリソースを保証し、予測可能な請求を提供する。

BigQueryおよびCloud Storage内のすべてのデータアセットをスキャンし、PIIおよびその他の機密データを自動的に識別・分類する。

→Cloud Data Loss Prevention (DLP) 検出スキャンジョブを構成する。

理由: Cloud DLPは、数百の事前定義された検出器を使用して、大規模な機密データを検出する。Data Catalogと統合して、ガバナンスのためにポリシータグを自動的に適用できる。

コンテナ化されたアプリケーション（GKEまたはCloud Run上）が、サービスアカウントキーを管理せずにBigQueryに安全に認証する必要がある。

→Workload Identity を使用する。

理由: サービス間認証の推奨されるベストプラクティスである。KubernetesサービスアカウントをGCP IAMサービスアカウントにマッピングし、短期間で自動的にローテーションされるトークンを使用する。

コンプライアンスのために、過去90日間に機密性の高いBigQueryテーブルをクエリしたすべてのユーザーのレポートを生成する。

→BigQueryデータアクセス監査ログを有効にし、分析のためにBigQueryデータセットにルーティングできるそれらのログをクエリする。

理由: データアクセスログは、誰がいつどのデータにアクセスしたかの不変の記録を提供する。これらはセキュリティおよびコンプライアンス監査に不可欠であるが、明示的に有効にする必要がある。

高額なBigQueryコストの原因となっているユーザーまたはクエリを特定する。

→`INFORMATION_SCHEMA.JOBS`ビューをクエリする。

理由: このメタデータビューには、実行されたすべてのクエリに関するユーザー、課金されたバイト数、消費されたスロットを含む詳細情報が含まれており、正確なコスト帰属と分析を可能にする。

累計、グループ内のランキング（例：カテゴリごとの上位N件）、または現在の行を前の行と比較するなどの複雑な分析計算を実行する。

→BigQuery SQLウィンドウ関数（`SUM() OVER (...)`、`RANK() OVER (...)`、`LAG() OVER (...)`）を使用する。

理由: 現在の行に何らかの形で関連する一連のテーブル行に対して計算を実行するための、標準的かつ最も効率的なSQLメソッドである。

SQLを記述しないビジネスユーザー向けに、BigQueryデータ上でインタラクティブで自動更新されるダッシュボードを作成・共有する。

→Looker Studio を使用する。

理由: ネイティブで無料のGCP可視化ツールである。BigQueryに直接接続し、シンプルなリンクを介した共有を可能にし、データソースの認証情報をユーザーアクセスとは別に管理する。

リファレンス↗

ビジネスアナリストが使い慣れたスプレッドシートツール（ピボットテーブル、グラフ、数式）を使用して、BigQuery内のテラバイト規模のデータを分析できるようにする。

→Connected Sheets を使用する。

理由: Google SheetsからBigQueryへのライブ接続を提供する。すべての処理と計算はBigQueryで行われ、従来のスプレッドシートのサイズとパフォーマンスの制限を回避する。

大規模で複雑な集計をクエリするLooker Studioダッシュボードが遅く、コストがかかる。

→BigQueryマテリアライズドビューを作成して集計を事前計算する。Looker Studioのデータソースをそのマテリアライズドビューに向ける。

理由: マテリアライズドビューは、コストのかかるクエリ結果を事前計算してキャッシュする。これにより、ダッシュボードのパフォーマンスが劇的に向上し、反復的なワークロードのクエリコストが削減される。

BigQueryに存在するデータを使用して、機械学習モデル（例：分類、回帰、予測用）を構築、トレーニング、提供する。

→BigQuery ML (BQML) を使用する。

理由: 標準SQLの`CREATE MODEL`構文を使用してモデルをトレーニングできるようにすることで、MLを民主化する。モデルはBigQuery内で存在および実行されるため、デプロイと予測が簡素化される。

リファレンス↗

過去の時系列データに基づいて、将来のビジネス指標（例：売上、需要）を予測する。

→BigQuery MLで`ARIMA_PLUS`モデルタイプを使用する。

理由: `ARIMA_PLUS`は、トレンド、季節性、祝日、異常検出を自動的に処理する、時系列予測に特化したBQMLモデルである。

非常に大きなファクトテーブル（TB単位）と小さなディメンションテーブル（100MB未満）を結合するBigQueryクエリが遅い。

→BigQueryがブロードキャスト結合を使用していることを確認する。多くの場合自動的だが、必要であればクエリプランを確認するか、`JOIN`ヒントを使用できる。

理由: ブロードキャスト結合は、小さいテーブル全体を各処理スロットに送信するため、ネットワークを介した大きなテーブルのコストがかかり遅いデータシャッフルを回避できる。

BigQuery MLモデルは、モデルのドリフトを防ぐために、新しいデータで定期的に（例：毎週）再トレーニングされる必要がある。

→BigQueryスケジュール済みクエリを使用して、`CREATE OR REPLACE MODEL`ステートメントを実行する。

理由: これはBQMLの再トレーニングを自動化する最もシンプルで統合された方法である。ComposerやCloud Functionsのような外部サービスは不要である。

協調フィルタリングによるレコメンデーションシステム（例：「Xを購入したユーザーはYも購入しています」）を構築する。

→BigQuery MLで`MATRIX_FACTORIZATION`モデルタイプを使用する。

理由: このモデルは、ユーザーとアイテムのインタラクションデータに基づくレコメンデーションタスク用に特別に設計されている。