Q1. BigQueryで市場動向のキュレーション済みデータセットを作成し、複数の外部パートナーと共有したいと考えています。
各パートナーがアクセスできる行と列を制御したいと考えています。
Googleが推奨するプラクティスに従いたいと考えています。
どうすればよいですか。
A. Analytics Hubでデータセットを公開する。サブスクリプションを使用して各パートナーにデータセットレベルのアクセス権を付与する。
B. パートナーごとに個別のCloud Storageバケットを作成する。データセットを各バケットにエクスポートし、各パートナーをそれぞれのバケットに割り当てる。IAMロールを使用してバケットレベルのアクセス権を付与する。
C. IAMロールを使用して、各パートナーにBigQueryデータセットへの読み取りアクセス権を付与する。
D. パートナーごとに個別のプロジェクトを作成してデータセットを各プロジェクトにコピーする。各データセットをAnalytics Hubで公開する。サブスクリプションを使用して各パートナーにデータセットレベルのアクセス権を付与する。
回答
- A. Analytics Hubでデータセットを公開し、サブスクリプションでアクセス権を付与する。
-
Analytics Hubは、外部パートナーとデータを共有しつつ、提供側がアクセス制御を維持できるサービスです。
サブスクリプションを通じて配信することで、データをコピーさせずにクエリ実行のみを許可でき、共有を細かく管理できます。
Bは、Cloud Storageはファイル保管用であり、BigQueryデータセットの共有手段としては適切ではありません。
Cは、IAMロールでは行・列レベルの細かな制御ができません。
Dは、パートナーごとにプロジェクトを作成してコピーする方式は複雑で拡張性に欠けます。
よって、Analytics Hubによる共有が最適です。
Analytics Hub の概要 | BigQuery
Q2. 自分のデータを使って、組織のリーダーシップチームにBigQueryの機能をデモンストレーションしようとしています。
ローカルマシンに保存されているファイルを、できるだけ少ない労力でBigQueryに一度だけ読み込む必要があります。
どうすればよいですか。
A. BigQuery Storage Write API ライブラリを使用するPythonスクリプトを記述して実行する。
B. Dataprocクラスタを作成し、ファイルをCloud Storageにコピーして、spark-bigquery-connectorを使用するApache Sparkジョブを記述する。
C. ローカルマシンで bq load コマンドを実行する。
D. Apache Beam の FileIO および BigQueryIO コネクタをローカルランナーで使用するDataflowジョブを作成する。
回答
- C. ローカルマシンで bq load コマンドを実行する。
-
一度きりの読み込みを最小限の労力で行うには、すぐに使えるツールが適しています。
bq load コマンドはGoogle Cloud SDKに含まれるCLIツールで、ローカルのCSVやJSONファイルをコマンド一つでBigQueryに直接アップロードできます。
コーディングが不要で、既存のSDKをそのまま利用できます。
Aは、Storage Write APIを使うPythonスクリプトは認証やライブラリ設定、デバッグが必要で過剰です。
Bは、Dataprocクラスタの作成やファイル転送が伴い複雑すぎます。
Dは、Dataflowジョブの構築も一度きりの読み込みには労力過多です。
bq コマンドライン ツールの使用 | BigQuery
Q3. チームがBigQueryに保存された大規模なデータセットを分析し、ユーザー行動の傾向を特定する必要があります。
分析には複雑な統計計算、Pythonパッケージ、可視化が含まれます。
分析を開発・共有するためのマネージドな共同作業環境を推奨する必要があります。
何を推奨すべきですか。
A. Colab Enterpriseノートブックを作成してBigQueryに接続する。ノートブックをチームと共有する。Colab Enterpriseでデータを分析し可視化を生成する。
B. BigQuery MLで統計モデルを作成する。クエリをチームと共有する。データを分析し、Looker Studioで可視化を生成する。
C. Looker Studioダッシュボードを作成してBigQueryに接続する。ダッシュボードをチームと共有する。Looker Studioでデータを分析し可視化を生成する。
D. Connected Sheetsを使用してGoogle SheetsをBigQueryに接続する。Google Sheetをチームと共有する。Google Sheetsでデータを分析し可視化を生成する。
回答
- A. Colab EnterpriseノートブックをBigQueryに接続して共有する。
-
BigQueryに接続したColab Enterpriseノートブックは、複雑な統計計算やPythonパッケージ、可視化に適したマネージドな共同作業環境を提供します。
高度な分析向けのPythonライブラリをサポートし、大規模データのクエリにおいてBigQueryとシームレスに連携します。
チームでの共同開発と共有が可能で、可視化機能も備えています。
B・Cは可視化中心で、複雑なPython計算には不向きです。
Dは、Connected Sheetsはスプレッドシート分析向けで、高度な統計処理やカスタム可視化には適しません。
Colab Enterprise の概要 | Vertex AI
Q4. あなたはBigQueryテーブルに保存された地域別の販売取引データを管理するデータベース管理者です。
各営業担当者が自分の担当地域の取引のみを閲覧できるようにする必要があります。
どうすればよいですか。
A. データセットに対して適切なIAM権限を付与する。
B. データマスキングルールを作成する。
C. 行レベルアクセスポリシーを作成する。
D. BigQueryにポリシータグを追加する。
回答
- C. 行レベルアクセスポリシーを作成する。
-
行レベルアクセスポリシーは、担当地域などの条件に基づいて行を絞り込み、ユーザーごとに閲覧できる行を制限できます。
これにより、別テーブルやビューを作らずに細かなアクセス制御を実現でき、最小権限の原則に沿います。
Aは、IAM権限はデータセット単位の制御で行レベルには対応しません。
Bのデータマスキングは列の値を隠す機能で、行の絞り込みには使えません。
Dのポリシータグは列レベルのアクセス制御に用いるものです。
よって行レベルアクセスポリシーが最適です。
行レベルのセキュリティの概要 | BigQuery
Q5. 組織は、Pub/Subに毎秒数千件到着するイベントに対してニアリアルタイム分析を実装する必要があります。
受信メッセージには変換が必要です。
開発時間を最小化しつつ、データを処理・変換してBigQueryに読み込むパイプラインを構成する必要があります。
どうすればよいですか。
A. Googleが提供するDataflowテンプレートを使用してPub/Subメッセージを処理し、変換を実行してBigQueryに書き込む。
B. Cloud Data Fusionインスタンスを作成し、Pub/Subをソースとして構成する。Data Fusionでメッセージを処理・変換してBigQueryに書き込む。
C. Cloud Storageサブスクリプションを使用してPub/SubからCloud Storageにデータを読み込む。Dataprocクラスタを作成し、PySparkでCloud Storage内のデータを変換してBigQueryに書き込む。
D. Cloud Run関数を使用してPub/Subメッセージを処理し、変換を実行してBigQueryに書き込む。
回答
- A. Googleが提供するDataflowテンプレートを使用して処理・変換し、BigQueryに書き込む。
-
Googleが提供するDataflowテンプレートは、ストリーミングデータ処理向けに事前構築・最適化されており、最小限の開発でパイプラインを展開できます。
Pub/Subからの取り込み、変換、BigQueryへの書き込みを一括で担い、スケーラビリティと低レイテンシを確保します。
Bは、Cloud Data Fusionの構築は開発時間の最小化という要件に対して手間がかかります。
Cは、Dataprocクラスタを介する方式は複雑でレイテンシも増えます。
Dは、Cloud Run関数は継続的なストリーム処理には不向きです。
Google 提供のテンプレート | Dataflow
Q6. Cloud Storageで、生データ、処理済みデータ、バックアップを含む大量のデータを管理しています。
組織は、特定のデータ型についてデータの不変性を義務付ける厳格なコンプライアンス規制の対象です。
保持要件を満たしつつ、効率的なプロセスでストレージコストを削減したいと考えています。
どうすればよいですか。
A. アクセスパターンに基づいてオブジェクトを適切なストレージクラスに移行するライフサイクル管理ルールを構成する。不変性要件を満たすため、すべてのオブジェクトにオブジェクトのバージョニングを設定する。
B. 経過期間とアクセスパターンに基づいてオブジェクトを異なるストレージクラスに移動する。不変性要件を満たすため、Cloud KMSを使用して顧客管理の暗号鍵（CMEK）で特定のオブジェクトを暗号化する。
C. オブジェクトのメタデータを定期的に確認し、経過期間とアクセスパターンに基づいて適切なストレージクラスに移動するCloud Run関数を作成する。不変性を強制するため、特定のオブジェクトにオブジェクトの保持を使用する。
D. 特定のオブジェクトに対してオブジェクトの保持を使用して不変性を強制し、経過期間とアクセスパターンに基づいてオブジェクトを適切なストレージクラスに移行するライフサイクル管理ルールを構成する。
回答
- D. オブジェクトの保持で不変性を強制し、ライフサイクル管理ルールでストレージクラスを移行する。
-
オブジェクトの保持（オブジェクトホールド）は、オブジェクトの削除や上書きを防いで不変性を確保し、ライフサイクル管理ルールは経過期間に応じて低コストのストレージクラスへ自動移行します。
この組み合わせで、コンプライアンスとコスト削減を両立できます。
Aのバージョニングは不変性を保証しません。
BのCMEKは暗号化であり不変性の手段ではありません。
CはCloud Run関数による手動管理が不要な手間を生みます。
オブジェクトの保持 | Cloud Storage
Q7. Cloud Storageバケットに保存された機密性の高い顧客データを処理するデータパイプラインを構築しています。
単一ゾーンの障害が発生した場合でも、このデータにアクセスできるようにする必要があります。
どうすればよいですか。
A. バケットの前段にCloud CDNを設定する。
B. バケットでオブジェクトのバージョニングを有効にする。
C. データをマルチリージョンバケットに保存する。
D. データをNearlineストレージに保存する。
回答
- C. データをマルチリージョンバケットに保存する。
-
マルチリージョンバケットは複数のロケーションにデータを複製するため、単一ゾーンの障害が発生してもデータへのアクセスを維持できます。
高い可用性と耐久性が求められる機密データに適しています。
Aは、Cloud CDNは配信性能の向上が目的で、元データの可用性は保護しません。
Bは、オブジェクトのバージョニングは上書きや削除に備える機能で、ゾーン障害時の可用性は確保しません。
Dは、Nearlineはストレージクラスの選択であり、ゾーン障害への冗長性とは無関係です。
バケットのロケーション | Cloud Storage
Q8. 組織はIoTイベントデータをPub/Subトピックに送信しています。
サブスクライバーアプリケーションはメッセージを読み取り、変換を行ってからデータウェアハウスに保存します。
トピックへの書き込みが特に多い繁忙時間帯に、サブスクライバーアプリケーションが期限内にメッセージを確認応答（ack）できていないことに気付きました。
こうした負荷の急増に対応し、メッセージ処理を継続できるようにパイプラインを変更する必要があります。
どうすればよいですか。
A. メッセージが確認応答されるまで再試行する。
B. サブスクライバーでフロー制御を実装する。
C. 確認応答されていないメッセージをデッドレタートピックに転送する。
D. 最後に確認応答されたメッセージまでシークする。
回答
- B. サブスクライバーでフロー制御を実装する。
-
サブスクライバーでフロー制御を実装すると、メッセージを取得・処理する速度を調整でき、負荷急増時でもサブスクライバーが過負荷にならず期限内に確認応答できます。
これにより繁忙時間帯でもパイプラインの安定性を保ち、メッセージを不必要に破棄・遅延させずに済みます。
Aの再試行のみでは過負荷は解消しません。
Cのデッドレタートピックは処理失敗の退避先で、スパイク対策ではありません。
Dのシークは再処理の手段で、急増への対応にはなりません。
フロー制御によるバックログの処理 | Pub/Sub
Q9. Cloud SQLデータベースにデータを保存するWebアプリケーションを管理しています。
プライマリデータベースインスタンスから読み取りトラフィックをオフロードして、アプリケーションの読み取り性能を改善する必要があります。
労力とコストを最小限に抑えるソリューションを実装したいと考えています。
どうすればよいですか。
A. Cloud CDNを使用して、頻繁にアクセスされるデータをキャッシュする。
B. 頻繁にアクセスされるデータをMemorystoreインスタンスに保存する。
C. データベースをより大きなCloud SQLインスタンスに移行する。
D. 自動バックアップを有効にし、Cloud SQLインスタンスのリードレプリカを作成する。
回答
- D. 自動バックアップを有効にし、Cloud SQLインスタンスのリードレプリカを作成する。
-
リードレプリカを作成すると、プライマリインスタンスから読み取りトラフィックをオフロードでき、負荷を分散して読み取り性能を向上できます。
Cloud SQL内で容易に実装でき、コスト効率にも優れます。
プライマリは書き込みに専念し、レプリカが読み取りクエリを処理するため、最小限の労力で性能を改善できます。
Aは、Cloud CDNは静的Webコンテンツ向けでデータベースには不適切です。
Bは、Memorystoreは追加のキャッシュ層で実装の手間が増えます。
Cの大型化はコストが高く、読み取り負荷の分散にはなりません。
レプリケーションについて | Cloud SQL
Q10. 組織は既存のエンタープライズデータウェアハウスをBigQueryに移行することを決定しました。
既存のデータパイプラインツールは、すでにBigQueryへのコネクタをサポートしています。
移行速度を最適化するデータ移行アプローチを特定する必要があります。
どうすればよいですか。
A. 既存環境からCloud Storageへのデータ転送を容易にする一時ファイルシステムを作成する。Storage Transfer Serviceを使用してデータをBigQueryに移行する。
B. Cloud Data Fusionのウェブインターフェースを使用してデータパイプラインを構築する。パイプラインのオーケストレーションを容易にする有向非巡回グラフ（DAG）を作成する。
C. 既存のデータパイプラインツールのBigQueryコネクタを使用してデータマッピングを再構成する。
D. BigQuery Data Transfer Serviceを使用してデータパイプラインを再作成し、データをBigQueryに移行する。
回答
- C. 既存のデータパイプラインツールのBigQueryコネクタを使用してデータマッピングを再構成する。
-
既存のツールがすでにBigQueryコネクタをサポートしているため、そのコネクタでデータマッピングを再構成するのが最も効率的です。
現行ツールを活かすことで移行の複雑さとセットアップ時間を削減でき、移行速度を最適化できます。
追加サービスや中間ステップを介さず、データをBigQueryへ直接流し込めます。
A・Dは新たなサービスやパイプラインの再作成が必要で手間が増えます。
Bは、Cloud Data Fusionでの再構築は不要な複雑さを招きます。
データ ウェアハウスの移行の概要 | BigQuery