Q1. 御社はTensorFlowを用いて、多数のニューロンと層から成るニューラルネットワークモデルを構築しました。
このモデルは訓練データには十分に適合しています。
しかし、新しいデータに対してテストすると、性能が低下します。
これに対処するにはどの手法を採用できますか。
A. スレッディング(Threading)
B. シリアライゼーション(Serialization)
C. ドロップアウト法(Dropout Methods)
D. 次元削減(Dimensionality Reduction)
回答
- C
-
訓練データに適合するのに新規データで性能が落ちるのは、過学習(オーバーフィッティング)の典型的な兆候です。
ドロップアウト法(Dropout)は学習時に一部のニューロンを無効化し、特定の特徴量への過度な依存を防ぐ正則化手法で、汎化性能を高めます。
過学習を抑えて汎化性能を高める標準手法はドロップアウト(Dropout)です。
スレッディングやシリアライゼーションは処理・保存の仕組みで対策になりません。
次元削減は特徴量を減らせますが、ニューラルネットワークの過学習を直接抑える標準手法はドロップアウトです。
機械学習集中講座: 過学習(Google for Developers)
Q2. 衣料品のレコメンデーションを行うモデルを構築しています。
ユーザーのファッションの好みは時間とともに変化する可能性が高いと分かっているため、新しいデータが利用可能になり次第モデルへストリーミングで返すデータパイプラインを構築します。
このデータをモデルの訓練にどう使うべきですか。
A. 新しいデータだけで継続的にモデルを再訓練する。
B. 既存データと新しいデータを組み合わせて継続的にモデルを再訓練する。
C. 既存データで訓練し、新しいデータをテストセットとして使う。
D. 新しいデータで訓練し、既存データをテストセットとして使う。
回答
- B
-
モデルの精度を保つには、新しい傾向を取り込みつつ過去のパターンも維持する必要があります。
新しいデータだけで再訓練すると過去に学んだ有用な知識を失いやすく、既存データのみでは変化に追従できません。
嗜好変化に追従するには、既存データと新規データを組み合わせて再訓練します。
これにより最新の傾向を反映しながら安定した予測を維持できます。
本問はテストセットの扱いではなく、訓練データの構成が論点です。
ML 開発のベストプラクティス(Google Cloud)
Q3. 3つの診療所の数百人の患者を対象とするパイロットプロジェクトとして、患者記録のデータベースを設計しました。
設計では単一のテーブルですべての患者と受診履歴を表現し、レポート生成には自己結合(self-join)を使っていました。
サーバーのリソース使用率は50%でした。
その後プロジェクトの範囲が拡大し、データベースは現在その100倍の患者記録を保存する必要があります。
レポートは実行時間が長すぎるか計算リソース不足でエラーになるため、もう実行できません。
データベース設計をどう調整すべきですか。
A. データベースサーバーの容量(メモリとディスク)を200倍程度に増やす。
B. テーブルを日付範囲で小さなテーブルにシャーディングし、あらかじめ指定した日付範囲でのみレポートを生成する。
C. マスター患者記録テーブルを患者テーブルと受診テーブルに正規化し、自己結合を避けるために必要な他のテーブルも作成する。
D. テーブルを診療所ごとに小さなテーブルへ分割する。クエリは小さなテーブルのペアに対して実行し、統合レポートにはUNIONを使う。
回答
- C
-
自己結合を多用する単一テーブル設計は、データ量の増加に伴い結合コストが急増し性能が悪化します。
自己結合を避けるための正規化が、性能と拡張性を両立する最も妥当な設計変更です。
マスターテーブルを患者テーブルと受診テーブルへ正規化し関連テーブルを整えると、自己結合を排除できクエリ負荷を抑えられます。
サーバー増強(A)は一時しのぎで根本解決になりません。
日付や診療所での分割(B・D)は利用に制約や手間を生みます。
データベーススキーマ設計のベストプラクティス(Google Cloud)
Q4. 大規模なチーム向けに、Google Data Studio 360(現Looker Studio)で重要なレポートを作成します。
レポートはデータソースとしてGoogle BigQueryを使用します。
可視化に、1時間未満の新しいデータが表示されないことに気づきました。
どうすべきですか。
A. レポート設定を編集してキャッシュを無効にする。
B. テーブル詳細を編集してBigQuery側のキャッシュを無効にする。
C. 可視化を表示しているブラウザのタブを更新する。
D. 過去1時間分のブラウザ履歴を消去してから、可視化を表示しているタブを再読み込みする。
回答
- A
-
Data Studio(現Looker Studio)には表示を高速化するためのキャッシュ機構があり、これが原因で最新データが反映されないことがあります。
最新データを表示するには、レポート設定でキャッシュ(データ更新頻度)を調整します。
BigQuery側のキャッシュ(B)やブラウザ操作(C・D)はこの問題の対処になりません。
なお製品名はData Studioから機能を引き継ぐ形でLooker Studioへ改称されており、設定の考え方は同じです。
データの更新頻度を管理する(Looker Studio ヘルプ)
Q5. 外部の顧客が、自社データベースのデータを日次でまとめて提供してきます。
データはカンマ区切り(CSV)ファイルとしてGoogle Cloud Storage(GCS)に流れ込みます。
このデータをGoogle BigQueryで分析したいのですが、フォーマットが不正な行や破損した行が含まれている可能性があります。
このパイプラインをどう構築すべきですか。
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)
Q6. あなたの天気アプリは、現在の気温を取得するために15分ごとにデータベースへクエリを発行します。
フロントエンドはGoogle App Engineで動作し、数百万人のユーザーにサービスを提供しています。
データベース障害に対応するために、フロントエンドをどう設計すべきですか。
A. データベースサーバーを再起動するコマンドを発行する。
B. 最大15分を上限として、指数バックオフでクエリをリトライする。
C. データの古さを最小化するため、復旧するまで1秒ごとにクエリをリトライする。
D. データベースが復旧するまで、クエリ頻度を1時間に1回へ下げる。
回答
- B
-
大規模システムでデータベース障害時に短間隔のリトライを集中させると、復旧途中のサーバーへ負荷が殺到し障害が悪化します。
障害時のリトライは、負荷集中を避けるため指数バックオフで間隔を広げます。
上限を設けることでサーバー負荷を抑えつつ自動復旧を待てます。
再起動コマンド(A)はフロントエンドの責務ではなく、毎秒リトライ(C)は過負荷を招き、頻度を固定で下げる(D)のは柔軟性に欠けます。
リトライ戦略(Cloud Storage / Google Cloud)
Q7. 住宅価格を予測するモデルを作成しています。
予算の制約により、リソースの限られた単一の仮想マシン(VM)上で実行しなければなりません。
どの学習アルゴリズムを使うべきですか。
A. 線形回帰(Linear regression)
B. ロジスティック分類(Logistic classification)
C. 再帰型ニューラルネットワーク(RNN)
D. 順伝播型ニューラルネットワーク(Feedforward neural network)
回答
- A
-
住宅価格のような連続値を予測する回帰問題には、線形回帰が適しています。
連続値の予測かつ低リソース環境では、軽量な線形回帰が最適です。
線形回帰は計算量が小さく、リソースの限られた単一VMでも効率良く学習・推論できます。
ロジスティック分類(B)は分類用で連続値予測には不向きです。
RNN(C)や順伝播型ニューラルネットワーク(D)は表現力は高いものの計算資源を多く必要とし、制約環境には適しません。
CREATE MODEL 構文(線形回帰 / BigQuery ML)
Q8. 御社向けに新しいリアルタイムデータウェアハウスを構築しており、Google BigQueryのストリーミングインサートを使用します。
データが1回だけ送信される保証はありませんが、各行に一意のID(unique ID)とイベントのタイムスタンプを持っています。
データを対話的にクエリする際に、重複を含めないようにしたいと考えています。
どのクエリタイプを使うべきですか。
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)
Q9. 御社は、似た名前のテーブルをまたいでデータをクエリするために、ワイルドカードテーブル(WILDCARD tables)を使用しています。
現在、SQL文は次のエラーで失敗しています。
# Syntax error : Expected end of statement but got "-" at [4:11]
SELECT age FROM bigquery-public-data.noaa_gsod.gsod WHERE age != 99 AND _TABLE_SUFFIX = ‘1929’ ORDER BY age DESC
このSQL文を正しく動作させるテーブル名はどれですか。
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)
Q10. 御社は規制の厳しい業界に属しています。
要件の一つは、各ユーザーが業務に必要な最小限の情報だけにアクセスできるようにすることです。
この要件をGoogle BigQueryで強制したいと考えています。
取り得るアプローチを3つ選んでください。
(3つ選択)
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)
