STEP 26:プロジェクト① AWSでのデータ基盤構築

🚀 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

📋 過去のメモ一覧
#artnasekai #学習メモ
LINE