Google Professional Data Engineer 1-10

表示モード
画像位置
文字位置
STATUS FILTER

表示する理解度を選択

読み込み中...
Q1Google Professional Data Engineer

A. スレッディング(Threading)
B. シリアライゼーション(Serialization)
C. ドロップアウト法(Dropout Methods)
D. 次元削減(Dimensionality Reduction)

回答
C

訓練データに適合するのに新規データで性能が落ちるのは、過学習(オーバーフィッティング)の典型的な兆候です。
ドロップアウト法(Dropout)は学習時に一部のニューロンを無効化し、特定の特徴量への過度な依存を防ぐ正則化手法で、汎化性能を高めます。
過学習を抑えて汎化性能を高める標準手法はドロップアウト(Dropout)です。
スレッディングやシリアライゼーションは処理・保存の仕組みで対策になりません。
次元削減は特徴量を減らせますが、ニューラルネットワークの過学習を直接抑える標準手法はドロップアウトです。

機械学習集中講座: 過学習(Google for Developers)

Q2Google Professional Data Engineer

A. 新しいデータだけで継続的にモデルを再訓練する。
B. 既存データと新しいデータを組み合わせて継続的にモデルを再訓練する。
C. 既存データで訓練し、新しいデータをテストセットとして使う。
D. 新しいデータで訓練し、既存データをテストセットとして使う。

回答
B

モデルの精度を保つには、新しい傾向を取り込みつつ過去のパターンも維持する必要があります。
新しいデータだけで再訓練すると過去に学んだ有用な知識を失いやすく、既存データのみでは変化に追従できません。
嗜好変化に追従するには、既存データと新規データを組み合わせて再訓練します。
これにより最新の傾向を反映しながら安定した予測を維持できます。
本問はテストセットの扱いではなく、訓練データの構成が論点です。

ML 開発のベストプラクティス(Google Cloud)

Q3Google Professional Data Engineer

A. データベースサーバーの容量(メモリとディスク)を200倍程度に増やす。
B. テーブルを日付範囲で小さなテーブルにシャーディングし、あらかじめ指定した日付範囲でのみレポートを生成する。
C. マスター患者記録テーブルを患者テーブルと受診テーブルに正規化し、自己結合を避けるために必要な他のテーブルも作成する。
D. テーブルを診療所ごとに小さなテーブルへ分割する。クエリは小さなテーブルのペアに対して実行し、統合レポートにはUNIONを使う。

回答
C

自己結合を多用する単一テーブル設計は、データ量の増加に伴い結合コストが急増し性能が悪化します。
自己結合を避けるための正規化が、性能と拡張性を両立する最も妥当な設計変更です。
マスターテーブルを患者テーブルと受診テーブルへ正規化し関連テーブルを整えると、自己結合を排除できクエリ負荷を抑えられます。
サーバー増強(A)は一時しのぎで根本解決になりません。
日付や診療所での分割(B・D)は利用に制約や手間を生みます。

データベーススキーマ設計のベストプラクティス(Google Cloud)

Q4Google Professional Data Engineer

A. レポート設定を編集してキャッシュを無効にする。
B. テーブル詳細を編集してBigQuery側のキャッシュを無効にする。
C. 可視化を表示しているブラウザのタブを更新する。
D. 過去1時間分のブラウザ履歴を消去してから、可視化を表示しているタブを再読み込みする。

回答
A

Data Studio(現Looker Studio)には表示を高速化するためのキャッシュ機構があり、これが原因で最新データが反映されないことがあります。
最新データを表示するには、レポート設定でキャッシュ(データ更新頻度)を調整します。
BigQuery側のキャッシュ(B)やブラウザ操作(C・D)はこの問題の対処になりません。
なお製品名はData Studioから機能を引き継ぐ形でLooker Studioへ改称されており、設定の考え方は同じです。

データの更新頻度を管理する(Looker Studio ヘルプ)

Q5Google Professional Data Engineer

A. フェデレーションデータソース(外部データソース)を使い、SQLクエリ内でデータをチェックする。
B. Google StackdriverでBigQueryの監視を有効にし、アラートを作成する。
C. gcloud CLIでBigQueryにデータをインポートし、max_bad_recordsを0に設定する。
D. Google Cloud Dataflowのバッチパイプラインを実行してBigQueryにデータをインポートし、エラーは分析用に別のデッドレターテーブルへ送る。

回答
D

不正・破損行が混在しうるデータでは、取り込み時に検証し、問題行を切り分けて処理を止めない設計が重要です。
不正行を止めずに隔離するには、Dataflowでデッドレターテーブルへ振り分けます。
正常な行はBigQueryへ投入し、エラー行は後から調査できます。
max_bad_recordsを0にする(C)と1行でも不正があれば全体が失敗します。
SQLでのチェック(A)や監視アラート(B)は破損行の隔離・継続処理には不十分です。

Dataflow パイプラインのベストプラクティス(Google Cloud)

Q6Google Professional Data Engineer

A. データベースサーバーを再起動するコマンドを発行する。
B. 最大15分を上限として、指数バックオフでクエリをリトライする。
C. データの古さを最小化するため、復旧するまで1秒ごとにクエリをリトライする。
D. データベースが復旧するまで、クエリ頻度を1時間に1回へ下げる。

回答
B

大規模システムでデータベース障害時に短間隔のリトライを集中させると、復旧途中のサーバーへ負荷が殺到し障害が悪化します。
障害時のリトライは、負荷集中を避けるため指数バックオフで間隔を広げます。
上限を設けることでサーバー負荷を抑えつつ自動復旧を待てます。
再起動コマンド(A)はフロントエンドの責務ではなく、毎秒リトライ(C)は過負荷を招き、頻度を固定で下げる(D)のは柔軟性に欠けます。

リトライ戦略(Cloud Storage / Google Cloud)

Q7Google Professional Data Engineer

A. 線形回帰(Linear regression)
B. ロジスティック分類(Logistic classification)
C. 再帰型ニューラルネットワーク(RNN)
D. 順伝播型ニューラルネットワーク(Feedforward neural network)

回答
A

住宅価格のような連続値を予測する回帰問題には、線形回帰が適しています。
連続値の予測かつ低リソース環境では、軽量な線形回帰が最適です。
線形回帰は計算量が小さく、リソースの限られた単一VMでも効率良く学習・推論できます。
ロジスティック分類(B)は分類用で連続値予測には不向きです。
RNN(C)や順伝播型ニューラルネットワーク(D)は表現力は高いものの計算資源を多く必要とし、制約環境には適しません。

CREATE MODEL 構文(線形回帰 / BigQuery ML)

Q8Google Professional Data Engineer

A. タイムスタンプ列にORDER BY DESCを付け、LIMITを1にする。
B. 一意ID列とタイムスタンプ列でGROUP BYし、値をSUMする。
C. 一意IDでPARTITIONしたLAGウィンドウ関数を使い、WHERE LAG IS NOT NULLを併用する。
D. 一意IDでPARTITIONしたROW_NUMBERウィンドウ関数を使い、行番号が1の条件(WHERE row = 1)を併用する。

回答
D

ストリーミングインサートでは同一行が重複投入されることがあります。
重複排除には、一意IDでPARTITIONしたROW_NUMBERで行番号1のみを残します。
一意IDでPARTITION BYしROW_NUMBER()で各IDの行に番号を付け、行番号が1の行だけを残せば各IDにつき1行を取得できます。
LIMIT 1(A)は全体で1行しか返らず、GROUP BY+SUM(B)は値を合算してしまい不適切です。
LAG(C)は前後比較用で、重複排除の標準手法はROW_NUMBERです。

分析関数(ウィンドウ関数)の概念(BigQuery / Google Cloud)

Q9Google Professional Data Engineer

A. `bigquery-public-data.noaa_gsod.gsod`
B. bigquery-public-data.noaa_gsod.gsod*
C. `bigquery-public-data.noaa_gsod.gsod’*
D. `bigquery-public-data.noaa_gsod.gsod*`

回答
D

ワイルドカードテーブルでは、複数テーブルをまとめて参照するためにテーブル名の末尾へアスタリスク(*)を付け、ハイフンを含むプロジェクト名・テーブル名全体をバッククォート(`)で囲む必要があります。
ワイルドカードテーブルは、末尾に*を付け識別子全体をバッククォートで囲みます。
Dはこの構文を満たし、_TABLE_SUFFIXで対象テーブルを絞り込めます。
バッククォートなし(B)や囲み・引用符が誤ったもの(A・C)は、ハイフンを含む識別子やワイルドカードを正しく解釈できず構文エラーになります。

ワイルドカードテーブルを使用したクエリ(BigQuery / Google Cloud)

Q10Google Professional Data Engineer

A. 特定のテーブルへの書き込みを無効にする。
B. ロールによってテーブルへのアクセスを制限する。
C. データが常に暗号化されるようにする。
D. BigQuery APIへのアクセスを承認済みユーザーに限定する。
E. データを複数のテーブルまたはデータベースに分離する。
F. Google Stackdriver監査ロギングを使ってポリシー違反を特定する。

回答
B、D、E

最小権限の原則を実現するには、アクセスできる範囲そのものを絞り込む対策が有効です。
最小権限の実現は、ロール制限・APIアクセス限定・データ分離の3点が中心です。
該当するのはロールによるテーブルアクセス制限(B)、BigQuery APIアクセスを承認済みユーザーに限定(D)、データを複数テーブル・データベースへ分離(E)です。
暗号化(C)はデータ保護には有効ですが最小権限とは別の観点で、書き込み無効化(A)は読み取り範囲を絞れず、監査ロギング(F)は事後の違反検知であり、いずれもアクセス最小化そのものには直結しません。

アクセス制御の概要(BigQuery / Google Cloud)