WEB問題集
小売企業がオンプレミスのOracleデータベースから日次でBigQueryへ売上データを取り込みたいと考えています。データは数百GBで、CDC（変更データキャプチャ）は不要、夜間バッチで全件転送します。最も運用負荷が低くマネージドな取り込み方法はどれですか。
解説
正解の根拠
CDC が不要で夜間に全件を送るという要件では、オンプレミス側で CSV や Avro にエクスポートし、gcloud storage cp で Cloud Storage に置いてから bq load で取り込む経路が最も単純です。BigQuery のロード ジョブは共有スロットで実行され追加のコンピューティング費用がかからず、Cloud Storage をステージングに挟むことで転送の再開やリトライ、複数ファイルの並列ロードも自動的に効きます。パイプラインの実行環境やワーカーを自前で保持せず、Cloud Storage と BigQuery のマネージド機能だけで完結するため監視対象も障害点も最小です。取り込み先を日付でパーティション分割しておけば、日次のロード先を書き分けるだけで再実行やロールバックも容易になり、エクスポート時に圧縮しておけば転送量も抑えられます。
| 選択肢 | 適合性 |
|---|---|
| A | Storage Transfer Service はOracleを直接ソースにできません |
| B | Datastreamは継続CDC向けで要件過剰 |
| C | Dataflowは柔軟だが運用負荷が増える |
| D | シンプルなバッチETLの定石 |
不正解の理由
- A: Storage Transfer Service が扱えるソースは Amazon S3、Azure Blob Storage、公開 URL のリスト、他の Cloud Storage バケット、オンプレミスの POSIX ファイル システムです。Oracle のようなデータベースへ直接接続して抽出する機能はありません。
- B: Datastream は変更ログを読み取って継続的にレプリケートする CDC 専用サービスです。CDC が不要な要件に対してソース側のログ読み取り構成と継続的な課金が発生し、機能・コストの両面で過剰になります。
- C: Dataflow テンプレートと Cloud Scheduler の組み合わせでも実現はできますが、テンプレートのバージョン管理、ワーカー構成のチューニング、ジョブ失敗時の再実行監視といった運用が増えます。
IoTセンサーから毎秒数十万件のイベントが発生し、これをBigQueryで近リアルタイム分析したいと考えています。順序保証は不要、重複は許容範囲、エンドツーエンドのレイテンシは数秒以内が目標です。最適な取り込みアーキテクチャはどれですか。
解説
正解の根拠
毎秒数十万件のイベントを数秒以内で BigQuery に届けるには、送信側のスパイクを吸収するバッファ、整形を行うストリーム処理、低レイテンシな書き込み経路の3つが必要です。Pub/Sub はグローバルにスケールするメッセージ バッファとして瞬間的な流入増を吸収し、順序保証が不要なら順序キーなしで最大限の並列配信ができます。Dataflow のストリーミング ジョブがそれを購読して型変換や不正行の除去を行い、書き込みには Storage Write API を使います。Storage Write API はストリーム単位のコミットにより exactly-once セマンティクスと高スループットを両立し、書き込んだ行は直後からクエリ可能なため、エンドツーエンドで数秒というレイテンシ目標が成立します。
| 項目 | 推奨 |
|---|---|
| バッファ | Pub/Sub |
| 処理 | Dataflow ストリーミング |
| 書き込み | Storage Write API |
不正解の理由
- A: Cloud Functions で1イベントずつ受けて bq コマンドを実行する構成は、プロセス起動と API 呼び出しのオーバーヘッドが毎回かかり、毎秒数十万件のレートでは同時実行数とロード ジョブの割り当て上限に先に突き当たります。
- B: 5分ごとにファイルを生成する時点でその待ち時間だけでレイテンシ目標を超えます。BigQuery Data Transfer Service のスケジュール実行も最短15分間隔で、近リアルタイム用途向けの仕組みではありません。
- C: Cloud SQL は単一インスタンスの行指向データベースで、毎秒数十万件の INSERT は書き込み上限を超えます。さらに1時間ごとの集約では、要件の数秒に対して桁違いの遅延になります。
データアナリストがBigQueryに格納するファイル形式を選定しています。読み取りは列指向の集計クエリが中心、ファイルサイズはできるだけ小さく、スキーマ進化（カラム追加）にも対応したい場合、どのファイル形式が最適ですか。
解説
正解の根拠
Parquet は同じ列の値をまとめて格納する列指向フォーマットです。集計クエリで参照する列だけを読み出せるため、不要な列の読み取りが発生せず I/O とコストを削減できます。列の中には同じ型の似た値が並ぶので辞書エンコードやランレングス圧縮が効きやすく、Snappy を併用することで小さいファイル サイズと展開の速さを両立できます。さらに行グループごとに列の最小値・最大値などの統計をフッターに持つため、条件に合致しない行グループを読み飛ばせます。スキーマはファイル自体に埋め込まれており、BigQuery へのロード時にスキーマ自動検出が使えるほか、列の追加を許可するスキーマ更新オプションを指定すれば、既存テーブルへの取り込みを続けたままカラムを増やせます。
| 形式 | 指向 | 集計性能 | スキーマ進化 |
|---|---|---|---|
| CSV | テキスト | 低 | 不可 |
| JSON | 行 | 低 | 柔軟だが非効率 |
| Avro | 行 | 中 | 強い |
| Parquet | 列 | 高 | 対応 |
不正解の理由
- A: CSVはテキスト形式で型情報を持たず、列指向集計でも全列を読み込むためI/O効率が悪いです。
- B: JSON Lines は柔軟ですがサイズが大きく、列単位の最適化が効きません。
- C: Avro は行指向で書き込み・全件読み出しに強いものの、列単位集計ではParquetに劣ります。
Amazon S3 に保存されている過去5年分の履歴ログ（合計50TB）をGoogle Cloud に一括移行したいと考えています。ネットワーク帯域は十分にあり、初回フルコピーが目的、以後の同期は不要です。最も適切なサービスはどれですか。
解説
正解の根拠
Storage Transfer Service は、Amazon S3、Azure Blob Storage、S3 互換ストレージ、公開 URL リストなどから Cloud Storage へ大量のオブジェクトを移すフルマネージドの転送サービスです。S3 からの転送はエージェントレスで、Google が管理する転送基盤が並列にオブジェクトを取得するため、こちらで VM やエージェントを用意する必要がありません。ジョブには帯域上限の設定、実行スケジュール、転送済みオブジェクトのスキップ、チェックサムによる整合性検証、失敗分の自動リトライが組み込まれており、結果はログとして確認できます。帯域が十分にある環境で初回フルコピーだけを行う 50 TB 規模であれば、こうしたオンライン転送で完結できます。
| シナリオ | 推奨サービス |
|---|---|
| S3 から GCS（オンライン） | Storage Transfer Service |
| 低帯域・PB級 | Transfer Appliance |
| 継続CDC | Datastream |
不正解の理由
- A: 手動転送は再開・整合性検証・スループット制御をすべて自前実装する必要があり、運用負荷が高すぎます。
- D: Transfer Appliance は帯域が不足する場合や数百TB以上の超大規模転送向けで、本ケースでは過剰です。
- C: Datastream はDB の継続的CDC用で、S3オブジェクトの一括移行には対応しません。
BigQuery で扱うCSVファイルが Shift_JIS でエンコードされており、bq load 実行時に文字化けが発生しています。最も簡潔で確実な対処方法はどれですか。
解説
正解の根拠
BigQuery の CSV ローダーが読み取り時に指定できる文字エンコーディングは UTF-8 と ISO-8859-1、および UTF-16 / UTF-32 の各系統に限られ、Shift_JIS は指定できません。そのため Shift_JIS のまま bq load を実行すると、バイト列が別の文字として解釈され、文字化けした値がそのままテーブルへ格納されます。Cloud Storage に配置する前に iconv や PowerShell などで UTF-8 へ変換しておけば、既定のエンコーディングで正しく読み込まれ、再取り込みや自動化の際も同じ結果が再現できます。変換を一度で済ませられるため運用も単純です。
| エンコーディング | bq load での指定 |
|---|---|
| UTF-8 | 指定可（既定） |
| ISO-8859-1 | 指定可 |
| UTF-16BE / UTF-16LE | 指定可 |
| UTF-32BE / UTF-32LE | 指定可 |
| Shift_JIS | 指定できない |
不正解の理由
- A: --encoding に Shift_JIS を指定する選択肢はなく、UTF-8 を指定しても元ファイルのバイト列は Shift_JIS のままなので文字化けは解消しません。
- B: 全列を BYTES 型で読むと型情報が失われ、後段クエリでの変換が複雑化し品質保証も難しくなります。
- D: Content-Encoding は HTTP の圧縮方式を示すメタデータであり、文字エンコーディングの変換とは無関係です。