🚀 STEP 26: プロジェクト① AWSでのデータ基盤構築
総合演習:ECサイトのデータ分析基盤を0から構築しよう!
📋 このプロジェクトで構築するもの
- S3データレイク(Raw/Processed/Curated層)
- AWS Glueでのスキーマ検出とETL処理
- Redshiftへのデータロード
- Athenaでのアドホック分析
- QuickSightでのダッシュボード作成
- コスト最適化設定
学習時間の目安: 4時間
🎯 このプロジェクトのゴール
これまで学んだSTEP 1-25の知識を総動員して、実践的なデータ基盤を構築します。完成すると「ECサイトの売上を分析できるダッシュボード」ができあがります!
🎯 1. プロジェクト概要
シナリオ
あなたはECサイトのデータエンジニアです。経営層から「売上データを分析できるダッシュボードが欲しい」と依頼されました。
📋 要件定義
- データソース:注文データ、顧客データ、商品データ(CSV形式)
- 更新頻度:日次(毎日午前2時に前日分を取り込み)
- 分析内容:日別売上、カテゴリ別売上、顧客セグメント分析
- ユーザー:経営層、マーケティングチーム
- 予算:月額$500以内
アーキテクチャ全体像
💡 例え話:データ基盤 = 食品工場
【データ基盤 = 食品工場】
■ 原材料の仕入れ(Raw層)
・農家から野菜が届く(生データ)
・品質はバラバラ、土がついてる
・そのまま保管(生データ保存)
■ 下処理工場(Processed層)
・野菜を洗う(クレンジング)
・皮をむく、カットする(変換)
・規格を統一(標準化)
■ 製品倉庫(Curated層)
・すぐ使える状態で保管
・レシピ(分析)に最適化
■ 出荷・販売(分析・可視化)
・お店(ダッシュボード)で販売
・お客さん(経営層)が購入
💡 データも同じ!生データ→加工→分析の流れ
【全体アーキテクチャ図】
データソース(CSV)
│
▼
┌─────────────────────────────────────────────┐
│ S3データレイク │
│ ├── 📦 Raw層(生データ) │
│ │ └── orders.csv, customers.csv │
│ │ │
│ ├── 🔧 Processed層(加工済み) │
│ │ └── orders_enriched.parquet │
│ │ │
│ └── 📊 Curated層(分析用) │
│ └── sales_summary.parquet │
└─────────────────────────────────────────────┘
│
├──────────────────────────────┐
▼ ▼
┌─────────────┐ ┌─────────────┐
│ Glue Crawler │ │ Athena │
│ (スキーマ) │ │(アドホック)│
└──────┬──────┘ └─────────────┘
▼
┌─────────────┐
│ Glue ETL │
│ (データ変換)│
└──────┬──────┘
▼
┌─────────────┐
│ Redshift │
│ (DWH) │
└──────┬──────┘
▼
┌─────────────┐
│ QuickSight │
│(ダッシュボード)│
└─────────────┘
📊 2. データの準備
サンプルデータの構成
📝 3つのデータファイル
【orders.csv】注文データ
・order_id: 注文ID
・customer_id: 顧客ID
・product_id: 商品ID
・quantity: 数量
・unit_price: 単価
・order_date: 注文日
【customers.csv】顧客データ
・customer_id: 顧客ID
・name: 名前
・email: メールアドレス
・age: 年齢
・gender: 性別
・prefecture: 都道府県
【products.csv】商品データ
・product_id: 商品ID
・product_name: 商品名
・category: カテゴリ
・price: 価格
・cost: 原価
サンプルデータ例
orders.csv(注文データ)
order_id,customer_id,product_id,quantity,unit_price,order_date,order_timestamp
1001,101,2001,1,98000,2024-01-15,2024-01-15 10:30:00
1002,102,2002,2,1500,2024-01-15,2024-01-15 11:45:00
1003,103,2003,1,8000,2024-01-15,2024-01-15 14:20:00
1004,101,2004,2,35000,2024-01-16,2024-01-16 09:15:00
1005,104,2001,1,98000,2024-01-16,2024-01-16 15:30:00
Pythonでサンプルデータ生成
import pandas as pd
import numpy as np
from datetime import datetime, timedelta
# 注文データ生成(1000件)
np.random.seed(42)
n_orders = 1000
orders = pd.DataFrame({
‘order_id’: range(1001, 1001 + n_orders),
‘customer_id’: np.random.randint(101, 201, n_orders),
‘product_id’: np.random.randint(2001, 2051, n_orders),
‘quantity’: np.random.randint(1, 5, n_orders),
‘unit_price’: np.random.choice([1500, 8000, 12000, 35000, 98000], n_orders),
‘order_date’: [
(datetime(2024, 1, 1) + timedelta(days=np.random.randint(0, 90))).strftime(‘%Y-%m-%d’)
for _ in range(n_orders)
]
})
orders.to_csv(‘orders.csv’, index=False)
print(f”✅ orders.csv を生成しました({n_orders}件)”)
🗂️ 3. S3データレイクの構築
💡 例え話:3層構造 = 倉庫の整理
【データレイク3層構造 = 倉庫の整理】
■ Raw層(原材料倉庫)
・届いた荷物をそのまま保管
・ダンボールのまま、開封しない
・「とりあえず全部取っておく」
■ Processed層(加工倉庫)
・開封して中身を確認
・検品、分類、ラベル貼り
・使いやすい形に整理
■ Curated層(展示倉庫)
・すぐ出荷できる状態
・売れ筋商品は前に配置
・お客さん(分析者)向けに最適化
💡 なぜ3層に分ける?
・生データを残しておける(やり直し可能)
・加工の履歴が追える
・用途に応じて最適化できる
STEP 1: S3バケットの作成
# AWS CLI でバケット作成
aws s3 mb s3://my-ecommerce-data-lake-12345 –region ap-northeast-1
# フォルダ構造を作成
aws s3api put-object –bucket my-ecommerce-data-lake-12345 –key raw/
aws s3api put-object –bucket my-ecommerce-data-lake-12345 –key processed/
aws s3api put-object –bucket my-ecommerce-data-lake-12345 –key curated/
📝 コマンドの解説
【各コマンドの意味】
aws s3 mb s3://バケット名 –region リージョン
│ │ │ │
│ │ │ └── 東京リージョン
│ │ └── バケット名(世界でユニーク)
│ └── mb = make bucket(バケット作成)
└── AWS CLIコマンド
aws s3api put-object –bucket バケット名 –key フォルダ名/
│ │ │ │
│ │ │ └── 末尾の/でフォルダ扱い
│ │ └── 対象バケット
│ └── オブジェクトを作成
└── S3 APIを直接呼び出し
💡 バケット名は世界中でユニーク!
「12345」の部分を自分の番号に変更してください
STEP 2: データのアップロード
# Raw層にCSVをアップロード
aws s3 cp orders.csv s3://my-ecommerce-data-lake-12345/raw/orders/
aws s3 cp customers.csv s3://my-ecommerce-data-lake-12345/raw/customers/
aws s3 cp products.csv s3://my-ecommerce-data-lake-12345/raw/products/
# パーティション分割(日付別)でアップロード
aws s3 cp orders.csv s3://my-ecommerce-data-lake-12345/raw/orders/year=2024/month=01/day=15/
✅ パーティション分割のメリット
【なぜパーティション分割するのか?】
悪い例(全データ1つのフォルダ):
s3://bucket/orders/orders.csv ← 全データが1ファイル
→ 1日分だけ欲しくても全部読み込む
→ Athenaのスキャン料金が高い!
良い例(日付でパーティション分割):
s3://bucket/orders/year=2024/month=01/day=15/orders.csv
s3://bucket/orders/year=2024/month=01/day=16/orders.csv
→ 必要な日付だけ読み込める
→ スキャン料金を大幅削減!
💡 WHERE order_date = ‘2024-01-15’ で
その日のデータだけスキャンされる
STEP 3: ライフサイクルポリシーの設定
{
“Rules”: [
{
“Id”: “MoveToIA”,
“Status”: “Enabled”,
“Transitions”: [
{
“Days”: 30,
“StorageClass”: “STANDARD_IA”
},
{
“Days”: 90,
“StorageClass”: “GLACIER_IR”
},
{
“Days”: 365,
“StorageClass”: “DEEP_ARCHIVE”
}
]
}
]
}
📝 ライフサイクルの意味
【ストレージクラスの自動移行】
Day 0-29: STANDARD(通常)
├── アクセス頻度: 高い(直近データ)
└── 料金: $0.023/GB
Day 30-89: STANDARD_IA(低頻度アクセス)
├── アクセス頻度: 月1回程度
└── 料金: $0.0125/GB(約半額)
Day 90-364: GLACIER_IR(即時取得)
├── アクセス頻度: 年数回
└── 料金: $0.004/GB(約1/6)
Day 365+: DEEP_ARCHIVE(長期保存)
├── アクセス頻度: ほぼなし
└── 料金: $0.00099/GB(約1/20)
💡 古いデータほど安いストレージに自動移行!
🕷️ 4. AWS Glueでのスキーマ検出
💡 例え話:Glue Crawler = 探偵
【Glue Crawler = データの探偵】
事件現場(S3)に行って、手がかり(データ)を調べる
探偵の仕事:
1️⃣ 現場を調査(S3をスキャン)
2️⃣ 証拠を分析(ファイル形式を判別)
3️⃣ 報告書を作成(スキーマをカタログに登録)
報告書(Data Catalog)の内容:
・テーブル名: orders
・カラム: order_id(int), customer_id(int), …
・ファイル形式: CSV
・保存場所: s3://bucket/raw/orders/
💡 手動でテーブル定義を書く必要なし!
Crawlerが自動で検出してくれる
STEP 1: Glue Crawlerの作成(コンソール)
【Glue Crawler作成手順】
1. AWSコンソール → 「AWS Glue」 → 「Crawlers」
2. 「Add crawler」をクリック
3. 基本設定
・Crawler名: ecommerce-raw-crawler
・説明: Raw層のCSVファイルをスキャン
4. データソース
・データストア: S3
・パス: s3://my-ecommerce-data-lake-12345/raw/
・サブフォルダをすべてクロール: はい
5. IAMロール
・新規作成: AWSGlueServiceRole-ecommerce
・S3への読み取り権限が自動付与される
6. 出力先
・データベース: 新規作成 → ecommerce_db
・テーブル接頭辞: raw_
7. スケジュール
・オンデマンド(必要に応じて実行)
8. 「Finish」で作成完了!
STEP 2: Crawlerの実行
# Crawlerを実行
aws glue start-crawler –name ecommerce-raw-crawler
# 実行状態を確認
aws glue get-crawler –name ecommerce-raw-crawler –query ‘Crawler.State’
【実行結果】
✅ Crawler ‘ecommerce-raw-crawler’ が完了しました
検出されたテーブル:
┌─────────────────┬──────────┬────────────────────────────────────┐
│ テーブル名 │ カラム数 │ 保存場所 │
├─────────────────┼──────────┼────────────────────────────────────┤
│ raw_orders │ 7 │ s3://…/raw/orders/ │
│ raw_customers │ 7 │ s3://…/raw/customers/ │
│ raw_products │ 6 │ s3://…/raw/products/ │
└─────────────────┴──────────┴────────────────────────────────────┘
💡 Data Catalogに登録され、AthenaやRedshiftから参照可能に!
🔄 5. Glue ETL Jobでのデータ変換
💡 例え話:ETL = 料理の下ごしらえ
【ETLの各工程】
Extract(抽出)= 材料を冷蔵庫から出す
・orders.csv を読み込む
・customers.csv を読み込む
・products.csv を読み込む
Transform(変換)= 下ごしらえ
・野菜を洗う → 欠損値を除去
・切り分ける → 合計金額を計算
・調味料と混ぜる → テーブルを結合
Load(格納)= 調理済み食材を保存
・Parquet形式で保存(圧縮・高速)
・日付でパーティション分割
・Processed層に書き込み
💡 生データ(CSV)→ 使いやすい形式(Parquet)に変換!
ETL Jobのコード(PySpark)
# Glue ETL Job(PySpark)
import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job
from pyspark.sql.functions import *
# 初期化
args = getResolvedOptions(sys.argv, [‘JOB_NAME’])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args[‘JOB_NAME’], args)
# 1. Raw層からデータ読み込み
orders_df = spark.read.format(“csv”) \
.option(“header”, “true”) \
.option(“inferSchema”, “true”) \
.load(“s3://my-ecommerce-data-lake-12345/raw/orders/”)
customers_df = spark.read.format(“csv”) \
.option(“header”, “true”) \
.option(“inferSchema”, “true”) \
.load(“s3://my-ecommerce-data-lake-12345/raw/customers/”)
products_df = spark.read.format(“csv”) \
.option(“header”, “true”) \
.option(“inferSchema”, “true”) \
.load(“s3://my-ecommerce-data-lake-12345/raw/products/”)
# 2. データクレンジング
orders_df = orders_df.na.drop() # 欠損値を除去
# 合計金額の計算
orders_df = orders_df.withColumn(
“total_amount”,
col(“quantity”) * col(“unit_price”)
)
# 3. テーブル結合
orders_enriched = orders_df \
.join(customers_df, on=”customer_id”, how=”left”) \
.join(products_df, on=”product_id”, how=”left”)
# 4. Processed層に保存(Parquet形式)
orders_enriched.write \
.mode(“overwrite”) \
.partitionBy(“order_date”) \
.parquet(“s3://my-ecommerce-data-lake-12345/processed/orders_enriched/”)
job.commit()
📝 コードの各部分を解説
【重要なポイント】
spark.read.format(“csv”).option(“header”, “true”)
├── CSVファイルを読み込む
├── header=true: 1行目をカラム名として使用
└── inferSchema=true: データ型を自動推論
orders_df.na.drop()
└── 欠損値(null)がある行を削除
.withColumn(“total_amount”, col(“quantity”) * col(“unit_price”))
├── 新しいカラム “total_amount” を追加
└── 数量 × 単価 = 合計金額
.join(customers_df, on=”customer_id”, how=”left”)
├── customer_idで結合
└── left: 注文データは全て残す
.write.mode(“overwrite”).partitionBy(“order_date”).parquet(…)
├── overwrite: 既存データを上書き
├── partitionBy: 日付でフォルダ分割
└── parquet: 圧縮された列指向フォーマット
【実行結果】
✅ ETL Job が完了しました
処理件数: 1,000行
実行時間: 2分30秒
出力先: s3://my-ecommerce-data-lake-12345/processed/orders_enriched/
フォーマット: Parquet(圧縮率: 80%)
出力フォルダ構成:
processed/orders_enriched/
├── order_date=2024-01-15/
│ └── part-00000.parquet
├── order_date=2024-01-16/
│ └── part-00000.parquet
└── …
🏢 6. Redshiftへのデータロード
STEP 1: Redshiftクラスタの作成
【Redshiftクラスタ作成手順】
1. AWSコンソール → 「Amazon Redshift」
2. 「クラスターを作成」をクリック
3. 構成設定
・ノードタイプ: dc2.large(開発用・安価)
・ノード数: 1(コスト削減)
・データベース名: ecommerce
・ポート: 5439
4. データベース設定
・マスターユーザー: admin
・パスワード: (強力なものを設定)
5. ネットワーク設定
・VPC: デフォルトVPC
・パブリックアクセス: はい(開発用)
※本番ではVPC内のみアクセス推奨
6. 「クラスターを作成」
→ 作成に約10分かかります
STEP 2: テーブルの作成
— Redshiftに接続してテーブル作成
CREATE TABLE orders_fact (
order_id INT,
customer_id INT,
product_id INT,
quantity INT,
unit_price DECIMAL(10,2),
total_amount DECIMAL(10,2),
order_date DATE,
order_timestamp TIMESTAMP,
customer_name VARCHAR(100),
customer_email VARCHAR(100),
customer_age INT,
customer_gender VARCHAR(10),
customer_prefecture VARCHAR(50),
product_name VARCHAR(200),
category VARCHAR(100),
product_price DECIMAL(10,2)
)
DISTKEY(customer_id)
SORTKEY(order_date);
📝 DISTKEYとSORTKEYの意味
【キーの役割】
DISTKEY(customer_id)
├── データをどのノードに分散するか決める
├── customer_idが同じデータは同じノードに
└── 顧客単位の集計が高速に!
SORTKEY(order_date)
├── ディスク上でのソート順を決める
├── order_dateでソートされて保存
└── 日付範囲の検索が高速に!
💡 よく使うWHERE句やJOINのキーで設定する
STEP 3: S3からデータをロード
— COPYコマンドでS3からロード
COPY orders_fact
FROM ‘s3://my-ecommerce-data-lake-12345/processed/orders_enriched/’
IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftCopyRole’
FORMAT AS PARQUET;
【実行結果】
✅ データロードが完了しました
ロード件数: 1,000行
実行時間: 5秒
エラー: 0件
💡 Parquet形式は圧縮済みなのでロードも高速!
STEP 4: 確認クエリ
— データ件数と売上合計を確認
SELECT
COUNT(*) AS total_orders,
SUM(total_amount) AS total_sales,
AVG(total_amount) AS avg_order_value
FROM orders_fact;
— 日別売上
SELECT
order_date,
COUNT(*) AS order_count,
SUM(total_amount) AS daily_sales
FROM orders_fact
GROUP BY order_date
ORDER BY order_date DESC
LIMIT 10;
🔍 7. Athenaでのアドホック分析
💡 Athena vs Redshift の使い分け
【使い分けのポイント】
Athena(サーバーレス)
├── 用途: アドホック分析、探索的分析
├── 料金: $5/TBスキャン(使った分だけ)
├── 起動時間: 即座に実行可能
└── 向いている: 単発クエリ、不定期な分析
Redshift(クラスタ型)
├── 用途: 定型レポート、ダッシュボード
├── 料金: 時間課金(稼働中は常に課金)
├── 起動時間: クラスタ起動に数分
└── 向いている: 高頻度クエリ、複雑な結合
💡 「ちょっと確認したい」→ Athena
「毎日レポート生成」→ Redshift
STEP 1: 外部テーブルの作成
— Athenaで外部テーブルを作成
CREATE EXTERNAL TABLE IF NOT EXISTS orders_enriched (
order_id INT,
customer_id INT,
product_id INT,
quantity INT,
unit_price DECIMAL(10,2),
total_amount DECIMAL(10,2),
order_timestamp TIMESTAMP,
customer_name STRING,
customer_age INT,
customer_gender STRING,
customer_prefecture STRING,
product_name STRING,
category STRING
)
PARTITIONED BY (order_date DATE)
STORED AS PARQUET
LOCATION ‘s3://my-ecommerce-data-lake-12345/processed/orders_enriched/’;
— パーティションを認識させる
MSCK REPAIR TABLE orders_enriched;
STEP 2: 分析クエリの実行
— カテゴリ別売上ランキング
SELECT
category,
COUNT(*) AS order_count,
SUM(total_amount) AS total_sales,
AVG(total_amount) AS avg_order_value
FROM orders_enriched
WHERE order_date >= DATE ‘2024-01-01’
GROUP BY category
ORDER BY total_sales DESC;
— 都道府県別の顧客分析
SELECT
customer_prefecture,
COUNT(DISTINCT customer_id) AS unique_customers,
COUNT(*) AS order_count,
SUM(total_amount) AS total_sales
FROM orders_enriched
GROUP BY customer_prefecture
ORDER BY total_sales DESC
LIMIT 10;
📊 8. QuickSightでのダッシュボード作成
ダッシュボードの設計
【ECサイト売上ダッシュボード構成】
┌────────────────────────────────────────────────────────┐
│ 📊 ECサイト売上ダッシュボード │
├────────────────────────────────────────────────────────┤
│ 【KPI】 │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │¥12.5M │ │1,000 │ │150 │ │¥12,500 │ │
│ │総売上 │ │注文数 │ │顧客数 │ │平均単価 │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
├────────────────────────────────────────────────────────┤
│ 【日別売上推移】 │
│ ┌────────────────────────────────────────────────┐ │
│ │ ╱╲ ╱╲ │ │
│ │ ╱ ╲╱ ╲ 📈 トレンド上昇中 │ │
│ │ ╱ ╲ │ │
│ └────────────────────────────────────────────────┘ │
├────────────────────────────────────────────────────────┤
│ 【カテゴリ別】 │ 【都道府県別TOP5】 │
│ ┌────────────────┐ │ 1. 東京都 ¥5.2M │
│ │ 🍰 円グラフ │ │ 2. 神奈川県 ¥2.1M │
│ │ Electronics 80%│ │ 3. 大阪府 ¥1.8M │
│ │ Office 15% │ │ 4. 愛知県 ¥1.2M │
│ │ Other 5% │ │ 5. 福岡県 ¥0.9M │
│ └────────────────┘ │ │
└────────────────────────────────────────────────────────┘
QuickSightセットアップ手順
【QuickSight設定手順】
1. AWSコンソール → 「Amazon QuickSight」
2. 初回は「サインアップ」が必要
・エディション: Standard($9/月)
・リージョン: 東京
・S3アクセス権限: 付与
3. データセットの作成
・「Datasets」→「New dataset」
・データソース: Redshift
・クラスターID、DB名、ユーザー名を入力
・テーブル: orders_fact
4. ダッシュボード作成
・「Analysis」→「New analysis」
・作成したデータセットを選択
・ビジュアルを追加
5. ビジュアルの種類
・KPI: 総売上、注文数などの数値
・折れ線: 時系列データ
・円グラフ: 構成比
・棒グラフ: ランキング
💰 9. コスト最適化設定
| 項目 | 設定内容 | 削減額(月) | 削減率 |
|---|---|---|---|
| S3ライフサイクル | 30日後にIA、90日後にGlacier | 約$50 | 33% |
| Redshift停止 | 夜間・週末は停止(週40時間稼働) | 約$150 | 76% |
| Glue DPU削減 | 10 DPU → 5 DPU | 約$30 | 50% |
| Athenaパーティション | 日付パーティション活用 | 約$20 | 80% |
【コスト見積もり比較】
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ 最適化前: $650/月
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
├── Redshift(24時間稼働) $400
├── S3(Standard) $150
├── Glue $70
└── その他 $30
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ 最適化後: $400/月 ✅目標達成!
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
├── Redshift(業務時間のみ) $120
├── S3(ライフサイクル) $100
├── Glue(DPU削減) $40
├── Athena $20
├── QuickSight $9
└── その他 $111
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
削減額: $250/月(38%削減)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📝 10. STEP 26 のまとめ
✅ このプロジェクトで構築したもの
- S3データレイク:Raw/Processed/Curatedの3層構造
- Glue Crawler:自動スキーマ検出でテーブル定義を自動生成
- Glue ETL:データクレンジングと結合、Parquet変換
- Redshift:分析用DWHにデータをロード
- Athena:S3直接クエリでアドホック分析
- QuickSight:経営層向けダッシュボード
- コスト最適化:月額$650→$400に削減(38%減)
💡 次のステップへ
このプロジェクトでは、AWSの主要データサービスを組み合わせて、実践的なデータ基盤を構築しました。
次のSTEP 27では、GCPでのデータ基盤構築に挑戦します!
BigQuery、Dataflow、Looker Studioを使って、同様のデータ基盤を作りましょう!
❓ よくある質問
Q1: Redshiftの代わりにAthenaだけで完結できますか?
はい、可能です。小規模なデータや低頻度の分析ならAthenaだけで十分です。ただし、高頻度クエリや複雑な結合が必要な場合はRedshiftの方がパフォーマンスとコストのバランスが良いです。
Q2: データレイクの3層構造は必須ですか?
必須ではありませんが、強く推奨します。Raw層に生データを残しておくことで、加工ロジックに問題があった場合に再処理できます。「やり直しがきく」ことは実務で非常に重要です。
Q3: Glue ETLの代わりにLambdaでも処理できますか?
小規模データならLambdaでも可能です。ただし、Lambdaは15分のタイムアウト制限と10GBのメモリ制限があります。大規模データや複雑な変換にはGlue ETLの方が適しています。
Q4: QuickSightの代わりに無料のBIツールはありますか?
Apache Supersetやmetabaseが無料の代替手段です。ただし、自分でサーバーを立てる必要があります。マネージドサービスの手軽さを考えると、QuickSight($9/月)はコスパが良いです。
Q5: このプロジェクトをTerraformで自動化できますか?
はい、可能です!S3バケット、Glue、Redshiftなど全てTerraformで定義できます。STEP 25で学んだIaCの知識を活用して、再現性の高いインフラを構築しましょう。
学習メモ
クラウドデータ基盤(AWS・GCP) - Step 26
📋 過去のメモ一覧
▼