DataLakeを考える時、必要になるのは「データを集めること」と「データ分析できるようにデータを加工すること」です。
とはいえ、分析に使うデータも様々なものがあり、どのようなアーキテクチャで設計していくかも、いきなりだと難しいでしょう。
この記事では、「データ」に視点を当てて、アーキテクチャを整理していくアプローチをご紹介します。
分析対象になるデータの種類を整理する
分析対象となるデータを整理すると、以下のいずれかに該当するはずです。
- WordやPDFなどの、構造化されていないデータ
- JSONやCSVなど、構造化されているテキストデータ
- 絶えずデータが発生する、ストリーミングなデータ
- Databaseに保存されているリレーショナルなデータ
それぞれ、特徴を見ていきましょう。
1. WordやPDFなどの、構造化されていないデータ
分析しようとした時に扱いを考えるのが難しい、構造化されていないデータ群です。
最近ではAIに学習させてRAGを生成するために利用することも増えています。
ただ、ことDataLakeの観点では「可視化のためには決まった構造でデータを変換する必要がある」データであり、どのような構造でデータを変換するかは、どんなクラウドサービスを使うにせよ、自前での設計が避けられません。
「どんな情報があって、どんな構造にできるのか」を考える必要があることを念頭に置いておきましょう。
S3にまずはrawデータを保管をすることが基本になり、そこからデータを変換する仕組みをAWS上で実装していく流れになります。
なので、
- S3にどうデータを収集するか
- S3に集めたデータを加工する手段をどうするか
を考えていくことになります。
2. JSONやCSVなど、構造化されているテキストデータ
JSONやCSVなどのデータは構造化されているので、そのまま分析に使うことができます。
AWSであれば、S3に配置しておくことで、Athenaを使ってクエリすることが可能です。
S3にデータがあれば、そこからGlueを使ってデータ変換し、Redshiftにロードすることも可能になります。
https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-an-etl-service-pipeline-to-load-data-incrementally-from-amazon-s3-to-amazon-redshift-using-aws-glue.html
こちらもS3にrawデータを保管することが基本になり、そこから
- S3にデータをどう収集するか
- 分析手段に合わせてそデータ変換して別の場所に持っていくのか検討する
という流れを考えることになります。
3. 絶えずデータが発生する、ストリーミングなデータ
IoTからのセンサーデータのような、絶えず発生するデータに関しては、ストリーミングデータと呼ばれています。
頻度高くデータが発生するもので、書き込みメインのデータになります。
こちらのAWS解説も併せて参照ください。
ストリーミングデータはそのまま分析用のデータベース等に入れるのではなく、ストリーミングされたデータをそのまま一時的に書き込みし、加工してDWHへ投入する、という流れにすると分析でも使いやすくなります。
なので、
- ストリームデータはそのままで書き込みする
- 書き込んだデータをDWH向けに加工して利用できるようにする
という流れを考えることになります。
4. Databaseに保存されているリレーショナルなデータ
リレーショナルなデータであれば、そのまま分析に利用するDWHへ書き込んでしまう、という考え方もできます。
ただ、テーブル構造によっては検索速度にも影響するため、必要なデータのみを書き込む、という流れが良いでしょう。
- テーブルの中から必要な情報をピックアップする
- 必要な情報のみをDWH向けに書き込めるようにする
という流れを考えることになります。
AWSのサービスはどう選んでいくのか？
ここまで整理できたら、AWSのサービスを選んでいきましょう。
a. S3へのデータを書き込み
まずは、rawデータをS3に集める手段を考えます。
やり方としては、主に以下のような手段があります。
- DataSyncを利用して、自動でデータを転送する（リアルタイム同期）
- AWS CLIやSDKを使ってデータを転送する（定期実行）
- Transfer Familyを使ってデータを転送する（定期実行）
リアルタイムの同期を考えるなら、一番良いのはDataSyncです。
ファイルサーバーからPDFやWordなどを転送するには最適ですね。
CSVやJSONなど、アプリケーションの生成過程などで発生する場合は、AWS CLIで定期に転送する整理が良いでしょう。
オンプレミスなど、制約が多い環境ではTransfer Familyを使い、sftpで転送する手段も考えられますね。
転送元によって取れる手段も変わるので、転送元によって手段を選ぶと良いでしょう。
b. データを変換する
分析を行う場合、そのままでは分析に利用できないケースもあるため変換処理を行うことになりますが、ここでGlueを使います。
どういうデータをどういう分析に使うためにどう変換するか、という大事なポイントになる部分です。
リレーショナルなデータ以外はS3に保管ができますし、S3にあるデータをGlueによって加工ができます。
また、リレーショナルデータをODBC接続で繋いでロードした上で変換も可能なので、データ変換としてはまずはGlueを考えることになります。
ただ、PDFやWordのようなファイルだといきなりの変換ができないため、場合によっては多段での変換処理が必要になると認識しておきましょう。
2026年6月現在のAWSでは、ファイルを分析に用いる場合、特に日本語を使う場合は自前実装での抽出が必要になる点に留意してください。
ある整ったデータであれば、加工は最低限としてS3へのファイル書き込みを起因にLambdaでデータ加工をする手段もあります。
Glueで取り込めるデータソースのみを使うのであれば、LakeFormationを使って権限管理やデータフローを管理する方法も考えられます。
c. ストリームデータを扱う
ストリームデータに関しては、Kinesis Data StreamとKinesis Data Firehoseを組み合わせることで、自動でS3にデータが保管可能です。Redshiftにそのまま書き込みもできますが、プロセス上S3への書き込みが必ず発生します。
加工なしでそのまま使える場合は直接Redshiftへ、加工が必要な場合は一度S3へ保存した上で、加工をしてからRedshiftに書き込む流れが良いでしょう。
まとめ
データの視点で、AWSでの分析にいたるまでのデータの扱いを追ってみました。
データの種類によって集める手段が異なったり、加工の有無によっても使うサービスが異なったりといった視点がありますので、まずはデータをベースに、どういった対応が必要となりそうかを改めて整理してみましょう。
この記事が、誰かのお役に立てば幸いです。