AWSデータエンジニア認定(DEA-C01) 試験対策 – 主要サービスの使い分け・着眼点まとめ

本サイトではアフィリエイト広告を利用しています。
広告

AWS Certified Data Engineer - Associate (DEA-C01) 試験では、様々なAWSサービスの特徴を理解し、特定の要件に対して最適なサービスや機能を組み合わせる能力が問われます。ここでは、特にデータエンジニアリング領域で重要となるサービスについて、試験シナリオで注目すべき「着眼点」をまとめました。

ETLツールの使い分け: AWS Glue vs Amazon EMR

  • 運用モデル:

    • Glue: サーバーレスであり、インフラ管理が不要。運用負荷が非常に低い。
    • EMR (主に on EC2): マネージドクラスターであり、EC2インスタンスの選択や管理が必要。運用負荷はGlueより高い。
    • 着眼点: 「運用負荷を最小限にしたい」 → Glue (またはEMR Serverless)。「インフラを細かく制御・管理したい」 → EMR。

  • 主な用途:

    • Glue: ETL処理に最適化されている。Glue StudioによるGUI開発も可能。
    • EMR (主に on EC2): ETLに加え、機械学習、インタラクティブSQL(Presto/Trino)、ストリーミング(Flink)など、多様なビッグデータフレームワークを実行可能。
    • 着眼点: 「Spark/PythonでのETLが主目的」→ Glue。「多様なフレームワーク (Presto, Flink, HBase等) も使いたい」→ EMR。

  • 柔軟性/カスタマイズ:

    • Glue: OSアクセス不可、利用可能なライブラリに制限がある場合があり、柔軟性は低い。
    • EMR (主に on EC2): OSログインが可能で、ソフトウェアの追加や設定変更の自由度が高く、柔軟性・カスタマイズ性が高い。
    • 着眼点: 「OSレベルの操作や特殊な設定/ライブラリが必要」→ EMR。

  • コストモデル:

    • Glue: DPU時間に基づく従量課金。ジョブ実行時のみ課金。
    • EMR (主に on EC2): EC2インスタンス料金 + EMR料金。スポットインスタンスを活用することで大幅なコスト削減が可能。長時間稼働時はEMRが有利な場合も。
    • 着眼点: 「ジョブ実行時のみ課金が良い(断続的ジョブ)」→ Glue (or EMR Serverless)。「スポットインスタンスでコスト削減したい」→ EMR。

  • 起動時間:

    • Glue: ジョブ実行リクエストから処理開始までに数分の準備時間がかかる場合がある（コールドスタート）。
    • EMR (主に on EC2): クラスターの起動に数分〜十数分かかるが、常時起動しておけばジョブはすぐに実行できる。
    • 着眼点: 「ジョブを即時実行したい(クラスター常時起動を許容)」→ EMR。

  • 開発体験:

    • Glue: Glue Studio (GUI) が利用可能。インタラクティブセッションも提供。
    • EMR: SSH接続やステップ実行、EMR Studio (Notebook) など。オンプレミス経験者が既存コードを流用しやすい場合が多い。
    • 着眼点: 「GUIで開発したい」→ Glue Studio。「既存のオンプレSpark/Hadoopコードを流用」→ EMR がしやすい可能性。

  • サーバーレスオプション:

    • Glue: 標準でサーバーレス。
    • EMR: EMR Serverless があり、Spark/Hiveをサーバーレス実行可能。
    • 着眼点: GlueとEMR Serverlessは運用モデルが近い。機能、バージョン、コスト、既存コードとの互換性などを比較検討。

  • データカタログ連携:

    • Glue: Glueデータカタログの利用が前提・必須。
    • EMR: Glueデータカタログの利用が推奨されるベストプラクティス。
    • 着眼点: どちらもGlueデータカタログとの連携が重要。

  • 判断キーワード: サーバーレス、運用負荷、ETL特化、多様なフレームワーク、カスタマイズ性、スポットインスタンス、既存コード移行。

データレイククエリエンジンの使い分け: Amazon Athena vs Redshift Spectrum

  • 共通点: S3データレイク上のデータをSQLで直接クエリ。Glueデータカタログ利用。
  • 試験での着眼点:
    • 「サーバーレスで」「インフラ管理なく」 S3データをすぐにクエリしたい → Athena。
    • 「既存のRedshiftクラスターを」 活用したい → Spectrum。
    • 「Redshift内のテーブルとS3上のデータを頻繁にJOIN」 したい → Spectrum (統合度が高い)。
    • 「運用コストを最小限に」 (Redshiftクラスターコスト回避) → Athena (スキャン量課金注意)。
    • 「RedshiftのSQL方言や機能を活用」 したい → Spectrum。
    • 「S3データのみのアドホック分析」 が主 → Athena。
    • 「Redshift中心の分析で、S3データも扱いたい」 → Spectrum。
  • 判断キーワード: サーバーレス、既存Redshift、内部テーブルとのJOIN、コスト（運用 vs スキャン量）。

ストリーミングデータの入口と出口: Kinesis Data Streams vs Kinesis Data Firehose

  • 試験での着眼点:
    • 「複数のリアルタイムアプリで」 同じストリームデータを処理したい → Data Streams (データ保持・分配)。
    • 「データを一時的にバッファリング」 したい、後続処理のスパイクに備えたい → Data Streams。
    • 「データをS3/Redshift/OpenSearch等に『とにかく簡単に』ロード」 したい → Data Firehose (サーバーレス・設定容易)。
    • ストリーミングデータをロードする 『前』に形式変換や加工をサーバーレスで」 行いたい → Data Firehose + Lambda連携。
    • 「運用負荷を極力下げて」 データを配信したい → Data Firehose (シャード管理不要)。
    • データの 「順序保証」 がある程度重要 → Data Streams (同一パーティションキー内)。
  • 判断キーワード: データ保持、複数コンシューマ、簡単配信、配信前変換、サーバーレス、運用負荷、順序保証。

データレイクの門番: AWS Lake Formation

  • 試験での着眼点:
    • データレイクのアクセス権限を 「一元的に管理」 したい。
    • 「テーブルレベル、列レベル、行レベル」 で細かくアクセス制御したい (IAM/S3ポリシーでは困難)。
    • 「複数のAWSサービスからのアクセス権限を統一」 したい (Athena, Spectrum, Glue, EMR等)。
    • 「タグベース」 でアクセス制御を行いたい (TBAC)。
    • 「クロスアカウントで安全にデータ共有」 したい（権限管理込み）。
    • 「データガバナンス強化」「アクセス監査」 を行いたい。
  • キーワード: 一元管理、きめ細かな権限 (列/行レベル)、複数サービス連携、タグベース制御(TBAC)、クロスアカウント共有、ガバナンス、監査。これらの要件があれば Lake Formation を検討。

クラウドBIの選択肢: Amazon QuickSight

  • 試験での着眼点:
    • AWSネイティブなBIツールで 「サーバーレス」 にダッシュボードを構築・共有したい。
    • ダッシュボードの応答性能向上のためデータを 「インメモリ(SPICE)」 に取り込みたい (高速だが鮮度は更新時点)。
    • 常に 「最新」 のデータで分析したい → 直接クエリ モード検討 (応答速度はソース依存)。
    • ユーザー毎に表示される 「行データ」 を制限したい → 行レベルセキュリティ(RLS)。
    • ユーザー権限に応じて特定の 「列」 を非表示にしたい → 列レベルセキュリティ(CLS)。
    • ダッシュボードを自社Webアプリ等に 「埋め込みたい」 。
    • 機械学習で 「異常」「予測」「要因」 を自動分析したい → ML Insights。
    • 「自然言語でクエリ」 したい → Q。
  • キーワード: AWSネイティブBI、サーバーレス、SPICE、直接クエリ、RLS、CLS、埋め込み分析、ML Insights、Q。

データレイクの基盤: Amazon S3 の重要機能

  • 試験での着眼点:
    • コスト最適化:
      • アクセス頻度に応じた 「ストレージクラス」 選択 (Standard, IA, Intelligent-Tiering, Glacier等)。
      • データの自動階層化・削除 → 「ライフサイクルポリシー」。
    • データ保護・可用性:
      • 誤削除・上書きからの保護 → 「バージョニング」。
      • DR・リージョン間同期 → 「レプリケーション (CRR/SRR)」。
      • 意図しない公開防止 → 「ブロックパブリックアクセス」。
    • セキュリティ:
      • データ保管時の保護 → 「サーバーサイド暗号化 (SSE-S3, SSE-KMS)」。
      • アクセス制御 → 「IAMポリシー」「バケットポリシー」。
    • データ処理連携・効率化:
      • ファイル配置トリガーの自動化 → 「S3イベント通知 (Lambda, SQS, SNS連携)」。
      • データ転送量・処理時間削減 → 「S3 Select / Glacier Select」 (必要なデータのみ抽出)。
    • パフォーマンス:
      • 高速転送 → マルチパートアップロード/ダウンロード、Transfer Acceleration。
      • 高頻度リクエスト対応 → 「プレフィックス設計」。
  • キーワード: データレイク基盤、コスト最適化、ストレージクラス、ライフサイクル、バージョニング、データ保護、セキュリティ、暗号化、アクセス制御、イベント通知、データ抽出、パフォーマンス。
広告

コメント

タイトルとURLをコピーしました