データ分析基盤の設計 データレイクとETLのサービスを選び分ける

SAP-C02では、部門ごとに散在したデータを統合し、分析まで繋げるアーキテクチャの設計が問われます。サービス数が多く迷いやすい領域ですが、データの流れを段階に分けて考えれば選択は機械的になります。

覚え方は「集める・整える・問い合わせる」の3つの観点です。取り込み層・加工層・分析層のどこの話をしているのかを見極めれば、候補は一気に絞られます。

集める：取り込み層

データレイクの実体はS3です。取り込み方は発生源で決まります。アプリのログやクリックストリームのように継続的に流れ込むならAmazon Data Firehoseで、バッファリングしつつS3へ自動配信します。オンプレミスのファイルサーバーから定期的にまとめて運ぶならAWS DataSync、リレーショナルDBの変更を継続的に反映するならAWS Database Migration ServiceのChange Data Capture（CDC）が定番です。

整える：加工とカタログ

AWS Glueのクローラーがスキーマを自動推論してGlue Data Catalogに登録し、AthenaやRedshift Spectrum、EMRがそのカタログを共有します。ETLのコードを書きたくない、サーバーを管理したくないならGlue、SparkやHiveの既存ジョブをそのまま動かしたい・数時間規模の大規模処理ならEMRを選びます。

ファイル形式も設問になります。列指向のParquetやORCに変換し、日付などでパーティション化しておくと、Athenaのスキャン量が桁で減ってコストと実行時間が下がります。

問い合わせる：分析層

アクセス制御とガバナンス

複数アカウントでデータレイクを共有するなら、AWS Lake Formationでテーブル単位・列単位・行単位の権限を一元管理します。S3バケットポリシーだけで細かな列制御を実現しようとする構成は誤答になりやすいので注意してください。アカウント間共有はLake FormationとAWS Resource Access Managerの組み合わせが定石です。

チェックリスト

• 取り込み層でFirehose・DataSync・DMSを選び分けられる
• GlueとEMRの使い分けを要件から説明できる
• Parquet化とパーティション設計の効果を数量的に説明できる
• AthenaとRedshiftのコスト構造の違いを理解している
• Lake Formationによる列単位・行単位の権限管理を説明できる

まとめ

分析基盤は「集める・整える・問い合わせる」の3層に分解し、各層で頻度と定型性からサービスを選ぶのが定石です。仕上げに クイズ で知識を定着させ、出題範囲の最新版は AWS認定 公式ページ で必ず確認してください。