ホーム ›
対応資格一覧 ›
IT・情報処理 › Professional Data Engineer 出題範囲（5分野） Designing data processing systems65問 Ingesting and processing the data64問 Storing the data60問 Preparing and using data for analysis60問 Maintaining and automating data workloads65問 Professional Data Engineerの例題（6問・解説つき） スキルサートのAIが出題範囲に沿って作成した演習問題です（過去問ではありません）。アプリでは毎週新しい問題が追加されます。
例題1Designing data processing systems 大規模なモバイルゲームアプリにおいて、リアルタイムのユーザー行動ログを処理するパイプラインを設計しています。イベントは、ネットワーク不安定により最大で10分程度の遅延が発生する可能性があります。Dataflowを使用して、1分ごとの固定ウィンドウでイベント数を集計し、遅延して到着したデータについても正確に結果を更新したいと考えています。どのアプローチが最も適切ですか。
Dataflowのグローバルウィンドウを使用し、10分間データが到着しなかった場合にのみサイド入力をトリガーとして集計を行う。 Dataflowで固定ウィンドウを設定し、Watermarkの遅延許容値をゼロにして、遅延したデータはすべて破棄する。 Cloud Storageにイベントを一度保存し、毎分実行されるCloud Functionsを使用してバッチ処理でBigQueryへロードする。 Dataflowで固定ウィンドウを設定し、allowedLateness（許容される遅延時間）を10分に設定し、集計結果を累積的に出力するトリガーを構成する。 Pub/Subの保持期間を10分以上に設定し、Dataflowのウィンドウ処理を使用せずにすべてのデータをメモリ内で管理する。 解答と解説を見る 正解: Dataflowで固定ウィンドウを設定し、allowedLateness（許容される遅延時間）を10分に設定し、集計結果を累積的に出力するトリガーを構成する。
正解は「Dataflowで固定ウィンドウを設定し、allowedLateness（許容される遅延時間）を10分に設定し、集計結果を累積的に出力するトリガーを構成する。」です。ストリーミング処理においてWatermark（水位標）よりも後に到着したデータ（遅延データ）を処理するには、allowedLatenessの設定が不可欠です。これにより、指定した期間内に到着した遅延データを破棄せずにウィンドウに関連付けることができます。また、トリガーを構成することで、遅延データ到着のたびに更新された集計結果を出力し、最終的な正確性を担保できます。他の選択肢のように遅延データを破棄したり、ウィンドウ処理を無視したりする方法では、リアルタイム性と正確性の両立が困難です。グローバルウィンドウは無期限のストリーム向けであり、固定時間枠の集計には不向きです。
例題2Ingesting and processing the data IoTデバイスから送信されるセンサーデータをPub/Sub経由で受信し、Cloud Dataflowでリアルタイムに集計するパイプラインを設計しています。ネットワークの不安定さにより一部のメッセージが数分遅れて到着する可能性がありますが、集計結果の正確性を高めるために、遅延データも含めてウィンドウの結果を更新し続ける必要があります。この要件を満たすために、Dataflowで設定すべき適切な構成はどれですか。
サイド入力を使用して、遅延データを一時的なBigQueryテーブルに蓄積し、バッチジョブで後からメインのストリームと結合する。 スライディングウィンドウを使用し、遅延データが破棄されるように累積モードを無効化したデフォルトのトリガーを適用する。 セッションウィンドウを使用し、ギャップ時間を最大遅延時間よりも長く設定して、すべてのデータを1つのウィンドウに含める。 固定ウィンドウを使用し、withAllowedLateness を設定して、遅延データが到着した際に結果を更新するトリガーを構成する。 グローバルウィンドウを使用し、AfterWatermarkトリガーを設定して、データの到着が完全に止まるまで待機する。 解答と解説を見る 正解: 固定ウィンドウを使用し、withAllowedLateness を設定して、遅延データが到着した際に結果を更新するトリガーを構成する。
正解は「固定ウィンドウを使用し、withAllowedLateness を設定して、遅延データが到着した際に結果を更新するトリガーを構成する」です。Dataflowにおいて、ストリーミングデータの遅延（Late data）を適切に処理するには、ウィンドウの「許可された遅延時間（allowed lateness）」を設定することが重要です。これにより、ウォーターマークがウィンドウの終了時間を過ぎた後に到着したデータも無視されず、指定した時間内であればウィンドウが再計算されます。併せて、遅延データ到着時に更新された結果を出力するためのトリガーを構成することで、最終的な集計結果の正確性を保証できます。グローバルウィンドウや極端に長いセッションウィンドウは、リソースの枯渇やリアルタイム性の欠如を招くため不適切です。
例題3Storing the data 数千台のIoTデバイスから秒間数百万件のデータをCloud Bigtableに書き込む際に、書き込み負荷が特定のノードに集中し、パフォーマンスが低下するホットスポットが発生しています。この問題を解決するために行キーの設計として推奨される手法はどれですか。
行キーをハッシュ化し分散させる。 データを単一の行に集約し、列ファミリーを増やして対応する。 行キーとしてデータの書き込み時刻のみを使用する。 デバイスIDを先頭にしたシーケンシャルなタイムスタンプを行キーにする。 すべてのデータを単一のクラスタ内の単一のノードに集中させる。 解答と解説を見る 正解: 行キーをハッシュ化し分散させる。
正解は『行キーをハッシュ化し分散させる。』です。Cloud Bigtableは行キーが辞書順に並ぶため、タイムスタンプや連続する値をキーにすると、特定のタブレット（データ範囲）に書き込みが集中し、ホットスポットが生じます。ハッシュ化を行うことでデータがクラスタ全体に均等に分散されます。デバイスIDを先頭にするシーケンシャルなキーや、書き込み時刻のみのキーは、順序性が強すぎるため解決になりません。単一ノードへの集中はスケーラビリティを著しく損ないます。また、列ファミリーの増加はスキーマの構造に関わるものであり、書き込み負荷の分散を目的とする場合には不適切です。
例題4Preparing and using data for analysis 大規模な広告配信システムのログデータを BigQuery ML で分析しています。100万種類以上の異なるIDを持つ「ユーザーID」という特徴量をモデルに含めたいと考えていますが、単純にワンホットエンコーディングを適用すると、次元数が膨大になりメモリ不足が発生する懸念があります。この問題を解決するために最適な特徴量変換の手法はどれですか。
ML.ONE_HOT_ENCODER を使用してすべてのIDをバイナリ変数に変換する ML.FEATURE_CROSS を使用してユーザーIDと他の変数を掛け合わせる ML.STANDARD_SCALER を使用してIDの数値を正規化する ML.LABEL_ENCODER を使用して各IDに整数値を割り当てる ML.HASH_BUCKETIZE を使用してIDを固定数のバケットにハッシュ化する 解答と解説を見る 正解: ML.HASH_BUCKETIZE を使用してIDを固定数のバケットにハッシュ化する
正解は「ML.HASH_BUCKETIZE を使用してIDを固定数のバケットにハッシュ化する」です。高カーディナリティ（種類が非常に多い）のカテゴリカル変数を扱う際、ハッシュバケット化は次元数を制御しつつ特徴量を表現する有効な手法です。ワンホットエンコーディングではメモリ不足を招く可能性があり、ラベルエンコーディングは順序性に意味を持たせてしまうため不適切です。標準化は数値データ用であり、特徴量クロスは逆に次元を増やしてしまいます。ハッシュ化により、衝突のリスクはありますが計算コストとメモリ消費を大幅に抑制できます。
例題5Maintaining and automating data workloads あなたは Cloud Composer 2 を使用して 100 以上の複雑な DAG を管理しています。最近、DAG のパース時間が長くなり、スケジューラーの負荷が高くなっていることが判明しました。運用コストを抑えつつ、スケジューリングの遅延を解消するための最も適切なアプローチはどれですか。
Cloud Composer 1 にダウングレードして、管理オーバーヘッドを削減する。 スケジューラーの CPU とメモリのリソースを増やし、スケジューラーのレプリカ数を増やす。 すべての DAG ファイルを単一の Python ファイルに統合して、Airflow によるファイル読み込み回数を減らす。 Airflow の設定で dag_dir_list_interval を極端に小さくして、パース頻度を高める。 ワーカーの数を増やし、タスクの並列実行数を増やす。 解答と解説を見る 正解: スケジューラーの CPU とメモリのリソースを増やし、スケジューラーのレプリカ数を増やす。
正解は「スケジューラーの CPU とメモリのリソースを増やし、スケジューラーのレプリカ数を増やす。」です。Cloud Composer 2 ではスケジューラーの垂直・水平スケーリングが可能であり、DAG のパース（解析）ボトルネックを解消するために最も直接的な解決策となります。「ワーカーの数を増やす」ことはタスク実行のキャパシティを向上させますが、パース処理を担当するスケジューラーの負荷軽減には繋がりません。「単一の Python ファイルに統合」する手法は、開発効率とメンテナンス性を著しく低下させるため、アンチパターンです。「Cloud Composer 1 へのダウングレード」は、最新の環境管理や自動スケーリング機能を失うため推奨されません。「dag_dir_list_interval を極端に小さくする」ことは、パースをより頻繁に行うことを意味し、リソースが不足している状況ではスケジューラーの負荷をさらに悪化させる原因となります。
例題6Designing data processing systems あなたは数千台のIoTデバイスから送られてくる時系列センサーデータを保存するストレージソリューションを設計しています。要件として、毎秒10万件以上の高スループットな書き込みが必要であり、かつ特定のデバイスIDとミリ秒単位のタイムスタンプに基づいたスキャンクエリを低レイテンシで実行できる必要があります。最もコスト効率が良く、パフォーマンス要件を満たすサービスはどれですか。
Cloud SQL (PostgreSQL) Cloud Bigtable BigQuery Cloud Storage Firestore 解答と解説を見る 正解: Cloud Bigtable
正解は「Cloud Bigtable」です。Cloud Bigtableは、毎秒数百万件の書き込みを処理できるスケーラビリティを備えた、フルマネージドのNoSQLワイドカラムデータベースです。特に、デバイスIDとタイムスタンプを組み合わせた行キーを設計することで、時系列データに対する範囲スキャンをミリ秒単位の低レイテンシで実行できます。Cloud SQLは高スループットな書き込みにおいてスケールの限界があり、Cloud Storageはランダムな読み取りや小規模な頻繁な書き込みには適しません。BigQueryは分析には優れていますが、ミリ秒単位の書き込み・読み取りレイテンシを保証するトランザクション的な用途には向きません。Firestoreは柔軟なクエリが可能ですが、これほどの大規模なスループットではBigtableの方がコスト効率と性能の面で優れています。
よくある質問
Professional Data Engineerの問題はスキルサートで何問解けますか？ 全314問・5分野の問題を用意しています。問題は出題範囲に沿って随時追加しています。
無料で使えますか？ 無料プランで週10回の演習（1回10問）と、毎日の「今日の1問」を利用できます。解説を読み、わからない点はAIに質問できます。
ここの問題は過去問ですか？ 過去問ではありません。出題範囲に沿ってAIが作成した演習問題です。すべて解説つきで、間違えた問題は繰り返し解けます。 Professional Data Engineerの対策はアプリで AIが毎週生成する新作問題・ランクマッチ・週次ランキング・AI診断で「続けられる」資格学習を。無料で始められます。
