Google Cloud認定 Associate Data Practitioner WEB問題集

WEB問題集

Question#1(Associate Data Practitioner)

あなたの小売企業は、BigQuery に保存されている過去の購買データを使用して 顧客の離脱（churn）を予測 したいと考えています。データセットには、顧客の属性情報、購買履歴、およびその顧客が離脱したかどうかを示すラベル列が含まれています。このデータを使って、離脱する可能性が高い顧客を特定するための機械学習モデルを構築したいとします。

customer_data テーブルを使用し、churned 列をターゲットラベルとして、ロジスティック回帰モデルを作成・学習する必要があります。どの BigQuery ML クエリを使用すべきでしょうか？

A. CREATE OR REPLACE MODEL churn_prediction_model
OPTIONS(model_type='logistic_reg') AS
SELECT *
FROM customer_data;
B. CREATE OR REPLACE MODEL churn_prediction_model
OPTIONS(model_type='logistic_reg') AS
SELECT * EXCEPT(churned),
churned AS label
FROM customer_data;
C. CREATE OR REPLACE MODEL churn_prediction_model
OPTIONS(model_type='logistic_reg') AS
SELECT * EXCEPT(churned)
FROM customer_data;
D. CREATE OR REPLACE MODEL churn_prediction_model
OPTIONS(model_type='logistic_reg') AS
SELECT churned AS label
FROM customer_data;

正解と解説ディスカッション 0

正解：B

BigQuery ML における CREATE MODEL の基本構文

BigQuery ML では、CREATE MODEL 構文を使って直接SQLから機械学習モデルを作成・学習できます。ロジスティック回帰モデルを作る場合の基本形は次の通りです：

CREATE OR REPLACE MODEL dataset.model_name
OPTIONS(model_type='logistic_reg') AS
SELECT feature_columns, label_column AS label
FROM dataset.table;

ここで：

model_type='logistic_reg'：分類タスク（Yes/Noなど）に使用。
label 列名：予測したいターゲット変数（目的変数）として指定する必要があります。
その他の列：特徴量（説明変数）として利用されます。

churned を label として明示的に指定し、その他の列を特徴量として利用しています。

SELECT * EXCEPT(churned),
       churned AS label

BigQuery MLの推奨構文どおり。

Question#2(Associate Data Practitioner)

あなたの会社には複数の小売店舗があります。各店舗で毎日の総売上件数（total_sales）を記録しています。各店舗ごとの傾向を把握するために、SQLで週次（7日）の移動平均を計算したいと考えています。どのクエリを使用すべきですか？

A. SELECT store_id, date, total_sales,
AVG(total_sales) OVER (
PARTITION BY store_id
ORDER BY total_sales
RANGE BETWEEN 6 PRECEDING AND CURRENT ROW
) AS rolling_avg
FROM store_sales_daily;
B. SELECT store_id, date, total_sales,
AVG(total_sales) OVER (
PARTITION BY date
ORDER BY store_id
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
) AS rolling_avg
FROM store_sales_daily;
C. SELECT store_id, date, total_sales,
AVG(total_sales) OVER (
PARTITION BY store_id
ORDER BY date
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
) AS rolling_avg
FROM store_sales_daily;
D. SELECT store_id, date, total_sales,
AVG(total_sales) OVER (
PARTITION BY total_sales
ORDER BY date
RANGE BETWEEN 6 PRECEDING AND CURRENT ROW
) AS rolling_avg
FROM store_sales_daily;

正解と解説ディスカッション 0

正解：C

週次（7日）移動平均＝「現在行を含む直近7行」の平均が妥当。
店舗ごとに独立して計算したいので PARTITION BY store_id。
時系列順に窓を進めるので ORDER BY date。
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW で「現在行＋前6行＝7行」の平均を取れる。

Question#3(Associate Data Practitioner)

あなたの会社は、小型機器から送信される JSON形式のテレメトリーデータ を処理する、ほぼリアルタイムのストリーミングパイプラインを構築しています。 Pub/Sub トピックに届くメッセージを処理し、その中の serial number（シリアル番号）フィールドを大文字に変換 し、結果を BigQuery に書き込みたいと考えています。

できるだけ コード量を最小限にし, かつ マネージドサービスを利用 したい場合、どの方法を選ぶべきでしょうか？

A. Pub/Sub から BigQuery へのサブスクリプションを使用し、結果を直接 BigQuery に書き込み、5分ごとに変換クエリをスケジュール実行する。
B. Pub/Sub から Cloud Storage へのサブスクリプションを使用し、バケットにオブジェクトが届いたときにトリガーされる Cloud Run サービスを作成して変換処理を実行し、その結果を BigQuery に書き込む。
C. 「Pub/Sub → BigQuery」Dataflow テンプレートを UDF（ユーザー定義関数）付きで使用し、結果を BigQuery に書き込む。
D. Pub/Sub のプッシュサブスクリプションを使用し、メッセージを受信して変換し、結果を BigQuery に書き込む Cloud Run サービスを作成する。

正解と解説ディスカッション 0

正解：C

Dataflow には「Pub/Sub → BigQuery」というマネージドテンプレートが用意されており、ほぼノーコードで実行可能。
軽微なデータ変換は UDF（JavaScript User-Defined Function） を指定するだけで実装できる。
フルマネージドでスケーラブルなストリーミング処理が可能。

👉 最小コード・リアルタイム・マネージドの要件すべてを満たす。

Question#4(Associate Data Practitioner)

あなたは、Cloud Storage に保存されている 日次売上データ（CSVファイル） を処理して BigQuery にロードし、後続のレポートで利用できるようにしたいと考えています。このデータを 変換処理しながら 取り込み、さらに データ品質（Data Quality）の問題を可視化できるような スケーラブルなデータパイプラインを、迅速に構築 する必要があります。

どうすべきでしょうか？

A. Cloud Data Fusion を使用してバッチパイプラインを作成し、Cloud Storage をソース、BigQuery をシンク（出力先）として設定する。
B. CSV ファイルを BigQuery にテーブルとしてロードし、スケジュールクエリを使って SQL 変換スクリプトを定期実行する。
C. CSV ファイルを BigQuery にロードしたあと、Cloud Data Fusion で BigQuery ソースと BigQuery シンクを使ったバッチパイプラインを作成する。
D. Dataflow の「Cloud Storage から BigQuery へのバッチテンプレート」を使用してパイプラインを作成する。

正解と解説ディスカッション 0

正解：A

GUIベースでデータパイプラインをノーコードまたはローコードで構築可能。
Cloud Storage → BigQuery などの典型的なETLジョブをテンプレート的に構築できる。
データプロファイリングやデータ品質の可視化（Data Quality Insights） 機能を提供。
バッチ処理にもストリーミング処理にも対応。

つまり、迅速に・スケーラブルに・変換＋品質可視化を実現できるのは Data Fusion だけです。

Question#5(Associate Data Practitioner)

あなたは、データ処理中に作成される 一時ファイル（temporary files） を保存する Cloud Storage バケット を管理しています。これらの一時ファイルは 7日間だけ必要 で、それ以降は不要になります。

ストレージコストを削減し、バケット内を整理するために、7日より古いファイルを自動的に削除 したいと考えています。どの方法を取るべきでしょうか？

A. Cloud Scheduler ジョブを設定し、週に1回 Cloud Run 関数を呼び出して、7日より古いファイルを削除する。
B. Cloud Storage のライフサイクルルール（Lifecycle Rule）を設定し、7日より古いオブジェクトを自動的に削除する。
C. Dataflow のバッチ処理を開発し、週に1回実行してファイルの経過日数に基づいて削除する。
D. 毎日実行される Cloud Run 関数を作成し、7日より古いファイルを削除する。

正解と解説ディスカッション 0

正解：B

🔹 ライフサイクル管理（Object Lifecycle Management）とは

Cloud Storage には「オブジェクトライフサイクル管理（Object Lifecycle Management）」という機能があります。これは、バケット内のオブジェクトに対して 自動で削除・アーカイブ・クラス変更 などのルールを設定できる機能です。目的：不要なデータを自動削除して、コストと管理手間を削減する。 ✅ ライフサイクルルール設定例以下のようなルールを設定すれば、アップロードから7日経過したファイルを自動削除できます。

{
  "rule": [
    {
      "action": {"type": "Delete"},
      "condition": {"age": 7}
    }
  ]
}

この設定を適用すると：

オブジェクトの「作成日（creation time）」から7日後に自動削除されます。
Cloud FunctionやSchedulerなどを自分で実装する必要はありません。