AWS S3上でのデータレイク設計:ベストプラクティスとフォルダ構造
Amazon Web Services(AWS)を使用してSimple Storage Service(S3)を基盤としたデータレイクを構築することは、膨大な量のデータを管理する戦略的なアプローチです。よく設計されたデータレイクは、データを保存するだけでなく、効率的にカテゴリ分けし、処理し、分析と洞察のためにすぐに利用できるようにします。この記事では、AWS S3上でのデータレイク設計のベストプラクティスについて、共通のデザインゾーン、フォルダ構造、およびAmazon Athenaを使用した効率的なデータパーティショニングのためのフォルダ構造に焦点を当てて説明します。
ベストプラクティスにおける一般的なゾーンの設計
AWS S3上のデータレイクは、通常、以下の4つの主要なゾーンに分けられます:
rawゾーン:すべての受信データが元の形式で格納されるエリアです。JSON、CSV、XMLファイル、画像などの構造化、半構造化、非構造化データが含まれます。
transformedゾーン:このゾーンのデータは、特定のユースケースのために処理され、正規化されています。データをApache ParquetやApache ORCのような列指向フォーマットに変換し、パフォーマンスとコスト効率を向上させることがよくあります。
curatedゾーン:さらに豊かにされ、分析とレポーティングのために最適化されたデータが含まれます。データアナリストや科学者が信頼できる、分析準備が整ったデータを探す場所です。
logsゾーン:監視と監査に不可欠で、データレイクアーキテクチャ内のAmazon S3および他のサービスからのログを保存します。CloudWatchおよびCloudTrailのログが含まれます。
効率的なデータパーティショニングのための共通フォルダ構造
特にAmazon Athenaのようなサービスで効率的なデータ取得を容易にするためには、論理的で標準化されたフォルダ構造を採用することが重要です。ここでは、データレイクゾーンに沿った効率的なデータパーティショニングをサポートする推奨されるサンプルフォルダ構造を示します:
data-lake-bucket/
│
├── raw/
│ └── Line-of-Business/
│ └── Database-Name/
│ └── Table-Name/
│ └── Partition1/
│ └── Partition2/
│ └── .../
│ └── Data-Files
│
├── transformed/
│ └── Line-of-Business/
│ └── Database-Name/
│ └── Table-Name/
│ └── Partition1/
│ └── Partition2/
│ └── .../
│ └── Data-Files
│
├── curated/
│ └── Business-Unit/
│ └── Database-Name/
│ └── Table-Name/
│ └── Partition1/
│ └── Partition2/
│ └── .../
│ └── Data-Files
│
└── logs/
├── s3-access-logs/
├── cloudwatch-logs/
└── cloudtrail-logs/
LOB(事業部門) および BU(ビジネスユニット) は、組織単位を高いレベルで区別するためのプレースホルダーです。
Database-name および table-name は、格納されているデータのソースまたは性質を反映しています。
Partition1、Partition2 などは、データを整理するために選択されたパーティショニングスキームを表します。生データゾーンではソースプロセス日付によるパーティショニング、変換済みおよびキュレーション済みゾーンではビジネス日付によるパーティショニングが一般的です。
Athenaのためのフォルダ名とパーティショニング
Amazon Athenaで効率的なクエリを実行するためにフォルダ構造を設計する際には、以下の点を考慮してください:
パーティショニングスキームを反映した一貫した命名規則をフォルダに使用すること、例えば `year=YYYY/month=MM/day=DD` など。
変換済みおよびキュレーション済みゾーンのファイルには、Athenaによる高速取得に最適化された列指向フォーマットであるApache Parquetを使用すること。
クエリ実行時の最適なパフォーマンスのために、ファイルサイズを約128MBに保つこと。
細かいアクセスとライフサイクル管理のために、オブジェクトレベルのタグ付けを有効にすること。
ベストプラクティスの要約
バケット名は一意であり、DNS命名規則に準拠していることを確認してください。
本番および非本番のワークロードを異なるAWSアカウントに分けてください。
生データ、変換済み、およびキュレーション済みのレイヤーの自動取り込みおよびカタログ作成メカニズムを実装してください。
誤ってデータを削除することから保護するために、バージョニングを有効にしてください。
強化されたセキュリティのために、AWS KMSまたはAWS CloudHSMを使用した暗号化を検討してください。
これらのガイドラインに従い、AWS S3データレイクを効率的に構造化することで、組織内のデータ管理、取得、および分析プロセスを大幅に改善することができます。
参考文献
https://docs.aws.amazon.com/whitepapers/latest/building-data-lakes/data-lake-foundation.html