本文へスキップ
BecomeCoder

AWS SAP（ソリューションアーキテクト プロフェッショナル）コース　·　第6章　新規ソリューションの設計②：データストアとデータベース　·　レッスン34

データレイクと分析

導入

トランザクション処理用のデータベースと、大量の履歴データを横断して分析するための基盤は、そもそも設計思想が違います。SAPでは、S3を中心としたデータレイクをどう組み立てるかが問われます。

説明

データレイク とは、構造化・非構造化を問わず、あらゆる形式の生データをそのまま溜め込む集約基盤です。AWSでは Amazon S3 を土台に構築するのが定石です。

flowchart LR
    S1["RDS/Aurora"] --> GLUE["AWS Glue<br/>ETL・カタログ化"]
    S2["DynamoDB"] --> GLUE
    S3["アプリログ"] --> GLUE
    GLUE --> LAKE["S3データレイク"]
    LAKE --> ATHENA["Athena<br/>S3を直接SQLで分析"]
    LAKE --> REDSHIFT["Redshift<br/>大規模データウェアハウス"]
    LAKE -.->|"アクセス制御"| LF["Lake Formation"]
サービス役割
S3データレイクの実体。あらゆるデータを安価に保存
AWS Glue各データソースからのETL（抽出・変換・格納）、データカタログ（メタデータ管理）
Amazon AthenaS3上のデータをサーバー管理なしでSQLクエリ。使った分だけ課金
Amazon Redshift列指向の大規模データウェアハウス。頻繁で複雑な集計クエリに強い
AWS Lake Formationデータレイク全体のアクセス権限を一元管理（列・行レベルの権限も可）

AthenaとRedshiftはどちらも分析用ですが、「たまにS3を直接調べたい」ならAthena、「毎日大量の複雑な集計クエリを高速に回したい」ならRedshiftという向き不向きがあります。Redshiftは事前にデータをロード・整形してクラスターに格納するため高速な反面、常時起動のコストがかかります（Redshift Serverlessでオンデマンド化も可能）。

  • 「サーバー管理なしでS3のログをたまにSQL分析したい」→ Athena
  • 「BIツールから頻繁に複雑な集計クエリを投げる基盤がほしい」→ Redshift
  • 「複数部門でデータレイクを共有しつつ、部門ごとにアクセスできる列を制限したい」→ Lake Formation

読んでみよう

データレイクの問題は「保存（S3）」「カタログ化・変換（Glue）」「問い合わせ（Athena/Redshift）」「権限（Lake Formation）」の4つの役割分担を押さえれば整理できます。それぞれのサービスがどの役割かを即答できるようにしておきましょう。