WEB問題集
小売企業がオンプレミスのOracleデータベースから日次でBigQueryへ売上データを取り込みたいと考えています。データは数百GBで、CDC（変更データキャプチャ）は不要、夜間バッチで全件転送します。最も運用負荷が低くマネージドな取り込み方法はどれですか。
正解：D
正解の根拠
夜間バッチでCDC不要、全件転送という要件では、CSV／Avro等にエクスポートしてCloud Storage経由で bq load する方法がもっとも単純で運用負荷が低く、コストも低く抑えられます。マネージドコンポーネント（Cloud Storage、BigQuery Loadジョブ）のみで完結します。
| 選択肢 | 適合性 |
|---|---|
| A | Storage Transfer Service はOracleを直接ソースにできません |
| B | Datastreamは継続CDC向けで要件過剰 |
| C | シンプルなバッチETLの定石 |
| D | Dataflowは柔軟だが運用負荷が増える |
不正解の理由
- A: Storage Transfer Service のソースはS3／Azure／HTTP／オンプレPOSIXファイル等であり、Oracle を直接接続できません。
- B: Datastreamはストリーミングレプリケーション用途で、夜間バッチ全件転送には機能・コスト共に過剰です。
- C: Dataflowは強力ですが、テンプレート管理・パイプライン監視が必要で、要件に対して複雑すぎます。
IoTセンサーから毎秒数十万件のイベントが発生し、これをBigQueryで近リアルタイム分析したいと考えています。順序保証は不要、重複は許容範囲、エンドツーエンドのレイテンシは数秒以内が目標です。最適な取り込みアーキテクチャはどれですか。
正解：D
正解の根拠
高スループットの近リアルタイム取り込みでは、Pub/Sub をバッファ、Dataflow で変換、BigQuery Storage Write API で低レイテンシ書き込み、というのがGoogle推奨パターンです。Storage Write API は exactly-once セマンティクスとストリーミング書き込みを両立します。
| 項目 | 推奨 |
|---|---|
| バッファ | Pub/Sub |
| 処理 | Dataflow ストリーミング |
| 書き込み | Storage Write API |
不正解の理由
- B: 5分間隔のファイルバッチでは数秒レイテンシ要件を満たせず、BigQuery Data Transfer Service はSaaS統合用途です。
- C: Cloud SQL は毎秒数十万件のINSERTには性能限界があり、バッチ集約も遅延が大きすぎます。
- A: Cloud Functions と bq コマンドではスループット不足で、コストとレート制限の両面で破綻します。
データアナリストがBigQueryに格納するファイル形式を選定しています。読み取りは列指向の集計クエリが中心、ファイルサイズはできるだけ小さく、スキーマ進化（カラム追加）にも対応したい場合、どのファイル形式が最適ですか。
正解：D
正解の根拠
Parquet は列指向フォーマットで、列単位の集計クエリにおいて必要列のみ読み込めるため I/O とコストを削減できます。Snappy圧縮で高い圧縮率を保ちつつ、スキーマ進化（カラム追加・型のwidening）にも対応します。
| 形式 | 指向 | 集計性能 | スキーマ進化 |
|---|---|---|---|
| CSV | テキスト | 低 | 不可 |
| JSON | 行 | 低 | 柔軟だが非効率 |
| Avro | 行 | 中 | 強い |
| Parquet | 列 | 高 | 対応 |
不正解の理由
- A: CSVはテキスト形式で型情報を持たず、列指向集計でも全列を読み込むためI/O効率が悪いです。
- B: JSON Lines は柔軟ですがサイズが大きく、列単位の最適化が効きません。
- C: Avro は行指向で書き込み・全件読み出しに強いものの、列単位集計ではParquetに劣ります。
Amazon S3 に保存されている過去5年分の履歴ログ（合計50TB）をGoogle Cloud に一括移行したいと考えています。ネットワーク帯域は十分にあり、初回フルコピーが目的、以後の同期は不要です。最も適切なサービスはどれですか。
正解：B
正解の根拠
Storage Transfer Service はS3／Azure Blob／HTTPなどから Cloud Storage への大規模転送に最適化されたフルマネージドサービスで、エージェントレスで動作し、帯域制御・スケジュール・整合性チェックを内蔵しています。十分な帯域があれば50TB程度はオンライン転送が現実的です。
| シナリオ | 推奨サービス |
|---|---|
| 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 実行時に文字化けが発生しています。最も簡潔で確実な対処方法はどれですか。
正解：C
正解の根拠
BigQuery のCSVローダーが公式サポートするエンコーディングはUTF-8とISO-8859-1のみです。Shift_JIS は未サポートのため、Cloud Storage 配置前にUTF-8へ変換するのが最も確実で再現性の高い方法です（iconv／PowerShell の Get-Content -Encoding 等）。
| BigQuery対応エンコーディング |
|---|
| UTF-8（既定） |
| ISO-8859-1 |
| UTF-16BE／UTF-16LE／UTF-32BE／UTF-32LE（一部） |
不正解の理由
- A: --encoding に Shift_JIS を指定する選択肢はなく、UTF-8指定だけでは元データの文字化けは解消しません。
- B: BYTES型で読むと型情報が失われ、後段クエリでの変換が複雑化し品質保証も難しくなります。
- D: Content-Encoding はHTTP圧縮メタデータであり、文字エンコーディング変換とは無関係です。