Amazon S3 と Lake Formation で構築するデータレイク - 設計パターンとガバナンス
S3 をストレージ基盤とし Lake Formation できめ細かいアクセス制御を実現するデータレイクの設計パターンを紹介。ETL パイプラインとコスト最適化も解説します。
データレイクの設計パターン
データレイクは 99.999999999% (イレブンナイン) の耐久性を持つ S3 をストレージ基盤として、生データの取り込みから分析可能な状態への変換までを段階的に管理します。ランディングゾーン (Raw) には取り込んだ生データをそのまま保存し、ステージングゾーン (Processed) では Glue ジョブで型変換やクレンジングを実施します。キュレーションゾーン (Curated) にはビジネスロジックを適用した分析用データを Parquet 形式で配置します。S3 のプレフィックス設計では year/month/day のパーティション構造を採用し、Athena のクエリでパーティションプルーニングによるスキャン量削減を実現します。
Lake Formation によるガバナンス
Lake Formation はデータレイクのアクセス制御を一元管理するサービスです。従来は S3 バケットポリシー、IAM ポリシー、Glue カタログポリシーを個別に設定する必要がありましたが、Lake Formation ではデータベース・テーブル・列・行の各レベルで GRANT/REVOKE ベースの権限管理を行えます。タグベースアクセス制御 (LF-TBAC) を使うと、データに分類タグを付与し、タグに基づいてアクセス権を自動適用できます。クロスアカウント共有では Organizations 内の他アカウントにテーブル単位でアクセスを許可し、データメッシュアーキテクチャを実現します。
ETL パイプラインの設計
データレイクの ETL パイプラインは Glue ジョブで構築します。ランディングゾーンの生データを Glue クローラーでスキーマ検出し、データカタログに登録します。 Glue ジョブで型変換、欠損値処理、重複排除を実行し、 Parquet 形式でキュレーションゾーンに出力します。パーティションキー (日付、リージョン) を設定して Athena のクエリパフォーマンスを最適化します。 Glue ワークフローで複数ジョブの依存関係を定義し、クローラー → ETL ジョブ → データ品質チェックの順序を制御します。 EventBridge で S3 へのデータ到着をトリガーに ETL パイプラインを自動起動し、ニアリアルタイムのデータ更新を実現します。 Lake Formation の基礎から応用まで、書籍 (Amazon)で体系的に学べます。
データレイクのコスト最適化
S3 のストレージクラスを活用してデータレイクのコストを最適化します。ランディングゾーンの生データは S3 Standard に格納し、30 日後に S3 Intelligent-Tiering に移行するライフサイクルルールを設定します。キュレーション済みデータは頻繁にクエリされるため Standard に保持し、アーカイブゾーンのデータは Glacier Instant Retrieval に移行します。Athena のクエリコストは Parquet 形式と適切なパーティション設計で大幅に削減でき、CSV と比較してスキャン量を 90% 以上削減できるケースがあります。Glue ジョブの DPU 数を適切に設定し、過剰なリソース割り当てを避けます。S3 のストレージレンズでバケットごとのコスト内訳を可視化し、不要なデータの削除やストレージクラスの見直しを定期的に実施します。
レイヤー設計
データレイクは、データの加工段階に応じて層を分けて設計するのが定石です。取り込んだままの生データを置く層、クレンジングや整形を施した層、分析しやすい形に集計・加工した層、という具合に段階を分けます。生データを保持しておくことで、後から異なる目的で再加工でき、加工のやり直しにも対応できます。各層を明確に分離することで、データの来歴が追いやすくなり、品質の管理もしやすくなります。利用者は、目的に応じて適切な層のデータを参照します。段階的なレイヤー構成が、柔軟で再利用性の高いデータレイクの土台になります。
ファイル形式とパーティショニング
データレイクの性能とコストは、ファイルの保存形式と分割の仕方に大きく左右されます。列指向の形式で保存すると、分析クエリで必要な列だけを読み込めるため、スキャン量が減り、高速かつ低コストになります。日付や属性でデータをパーティション分割しておけば、クエリ時に必要な範囲だけを読み込めます。一方、小さなファイルが大量にあるとクエリ性能が落ちるため、適度なサイズにまとめる工夫が必要です。保存形式・分割・ファイルサイズを適切に設計することが、大規模データを効率よく分析するための重要な要素になります。
メタデータとカタログ管理
データレイクには多様なデータが蓄積されるため、どこに何があるかを管理する仕組みが不可欠です。データカタログにテーブル定義を登録し、データの構造や場所を一元的に管理します。クローラーでデータの構造を自動的に読み取り、カタログを最新に保てます。取り込むデータの構造は時間とともに変化するため、スキーマの進化に対応できる設計にしておきます。整備されたカタログがあれば、利用者は必要なデータを見つけやすくなり、複数の分析ツールから一貫してアクセスできます。メタデータの管理が、データレイクを「使えるもの」にする鍵です。
データレイクからレイクハウスへ
従来のデータレイクは、大量のデータを安価に保管できる反面、更新や整合性の管理が苦手でした。これを補うのが、データレイクの上で更新・削除や整合性のある操作を可能にする、新しいテーブル形式の活用です。オープンなテーブル形式を使うと、データレイクのコスト効率を保ちながら、データウェアハウスのような信頼性のあるデータ操作や、過去の時点のデータを参照する機能を得られます。複数の分析エンジンから同じテーブルを一貫して扱えます。ストレージとウェアハウスの利点を統合したこのアプローチは、データ基盤の選択肢を広げています。
まとめ
S3 と Lake Formation を組み合わせたデータレイクは、3 層構造のゾーン設計でデータ品質を段階的に向上させ、Lake Formation の細粒度アクセス制御でガバナンスを確保します。Glue クローラーによるスキーマ自動検出と列指向フォーマットの採用で、運用効率とクエリ性能を両立できます。