STEP 13：Redshiftへのデータロード

ホーム > クラウドデータ基盤 > STEP 13

📥 STEP 13: Redshiftへのデータロード

COPYコマンドを使いこなし、S3から効率的にデータをロードしよう

📋 このステップで学ぶこと

  • COPYコマンドの基本と詳細オプション
  • S3からのデータ取り込み方法（CSV、JSON、圧縮）
  • バルクロードの最適化テクニック
  • エラーハンドリングとトラブルシューティング
  • 実践演習：100万件のデータロード

🎯 このステップのゴール

このステップを終えると、COPYコマンドを使って大量データを高速にロードできるようになります。INSERT文との違いを理解し、最適化テクニックを身につけましょう。

🎯 1. COPYコマンドの基本

COPYコマンドとは

COPYコマンドは、Redshiftに大量データを高速にロードするための専用コマンドです。INSERT文と比べて圧倒的に速いため、Redshiftでは「データロード＝COPYコマンド」と覚えてください。

💡 例え話：引っ越し業者 vs 自分で運ぶ

【INSERT文 = 自分で1個ずつ運ぶ】 ・ダンボール1箱ずつ車で往復 ・100箱なら100往復 ・時間がかかる、疲れる 【COPYコマンド = 引っ越し業者】 ・大型トラックで一気に運ぶ ・複数のスタッフが同時に作業（並列処理） ・荷物を圧縮してまとめて運ぶ ・プロの技で超高速！ 【結果】 INSERT: 100万件 → 30分〜1時間 COPY: 100万件 → 1〜3分 → 約20〜30倍の速度差！

INSERT vs COPY の比較

📊 処理時間の比較（実測値）

データ量 INSERT文 COPYコマンド 速度差
1万件 30秒 2秒 15倍
10万件 5分 10秒 30倍
100万件 45分 1分 45倍
1000万件 7時間 10分 42倍

結論：Redshiftでは、常にCOPYコマンドを使いましょう！

COPYコマンドが速い理由

⚡ 5つの高速化ポイント

  • 並列処理：全ワーカーノードが同時にデータをロード
  • 直接S3接続：各ノードが直接S3からデータを取得
  • バルク処理：1件ずつではなく、まとめて処理
  • 圧縮対応：gzip、bz2などの圧縮ファイルを直接ロード
  • 最適化I/O：ディスク書き込みを最適化

基本的なCOPYコマンド構文

— 基本構文 COPY テーブル名 FROM ‘S3パス’ IAM_ROLE ‘IAMロールのARN’ [オプション]; — 最もシンプルな例 COPY sales FROM ‘s3://my-bucket/data/sales.csv’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ CSV;

COPYコマンドの仕組み

🔄 データロードの流れ

【COPYコマンドの内部処理】 1. リーダーノードがCOPYコマンドを受け取る ↓ 2. S3からファイルリストを取得 ↓ 3. ファイルを分割して各ワーカーノードに割り当て ┌─────────────────────────────────────────┐ │ ファイル1 → ノード1 が担当 │ │ ファイル2 → ノード2 が担当 │ │ ファイル3 → ノード1 が担当 │ │ ファイル4 → ノード2 が担当 │ └─────────────────────────────────────────┘ ↓ 4. 各ワーカーノードが並列でS3からデータをロード ↓ 5. データを圧縮してディスクに書き込み ↓ 6. リーダーノードが完了を確認 ↓ 7. ロード完了！ 【ポイント】 ・全ノードが同時に処理 → 高速 ・ファイルが多いほど並列度UP ・ネットワーク帯域を最大限活用

📄 2. S3からのデータ取り込み

CSV形式のロード

📝 基本的なCSVロード

— CSVファイルをロード COPY sales FROM ‘s3://my-bucket/data/sales.csv’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ CSV — CSV形式を指定 DELIMITER ‘,’ — 区切り文字（デフォルトはカンマ） IGNOREHEADER 1; — ヘッダー行（1行目）をスキップ

📝 各オプションの意味

【CSV】 ・CSV形式であることを明示 ・引用符で囲まれたフィールドを正しく処理 【DELIMITER】 ・フィールドの区切り文字を指定 ・’,’ カンマ区切り（CSV） ・’\t’ タブ区切り（TSV） ・’|’ パイプ区切り 【IGNOREHEADER】 ・指定した行数をスキップ ・通常は1（ヘッダー行） ・ヘッダーがない場合は0または省略

💡 よくある形式の例

— TSV（タブ区切り） COPY sales FROM ‘s3://my-bucket/data/sales.tsv’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ DELIMITER ‘\t’ IGNOREHEADER 1; — パイプ区切り COPY sales FROM ‘s3://my-bucket/data/sales.txt’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ DELIMITER ‘|’; — セミコロン区切り（ヨーロッパでよく使用） COPY sales FROM ‘s3://my-bucket/data/sales_eu.csv’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ DELIMITER ‘;’ IGNOREHEADER 1;

JSON形式のロード

📝 JSON Lines形式（1行1JSON）

— JSONファイルの内容例（sales.json） {“sale_id”: 1, “product”: “ノートPC”, “amount”: 80000} {“sale_id”: 2, “product”: “マウス”, “amount”: 2000} {“sale_id”: 3, “product”: “キーボード”, “amount”: 15000} — COPYコマンド COPY sales FROM ‘s3://my-bucket/data/sales.json’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ JSON ‘auto’; — 自動でカラムをマッピング — ‘auto’はJSONのキー名とテーブルのカラム名が一致する場合に使用

⚠️ JSONパス指定（キー名が異なる場合）

— JSONパスファイル（jsonpaths.json）を作成 { “jsonpaths”: [ “$[‘sale_id’]”, “$[‘product_name’]”, — テーブルのカラム名と異なる “$[‘total_amount’]” — テーブルのカラム名と異なる ] } — S3にjsonpaths.jsonをアップロード後 COPY sales(sale_id, product, amount) — カラム順を指定 FROM ‘s3://my-bucket/data/sales.json’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ JSON ‘s3://my-bucket/jsonpaths.json’;

圧縮ファイルのロード

🗜️ 圧縮のメリット

  • 転送時間短縮：S3からの転送量が減る
  • S3料金削減：保存容量が減る
  • ネットワーク負荷軽減：帯域を効率的に使用
【圧縮効果の例】 元データ: 100MB gzip圧縮後: 25MB（75%削減） bzip2圧縮後: 20MB（80%削減） → 転送時間も約4〜5倍速くなる！

📝 gzip圧縮ファイルのロード

— gzip圧縮されたCSVをロード COPY sales FROM ‘s3://my-bucket/data/sales.csv.gz’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ CSV GZIP — gzip圧縮を指定 IGNOREHEADER 1; — ファイル拡張子が.gzでなくても、GZIPオプションがあれば解凍される

📝 その他の圧縮形式

— bzip2（.bz2） COPY sales FROM ‘s3://my-bucket/data/sales.csv.bz2’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ CSV BZIP2; — lzop（.lzo）- 高速だが圧縮率は低い COPY sales FROM ‘s3://my-bucket/data/sales.csv.lzo’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ CSV LZOP; — zstd（.zst）- 最新、高速かつ高圧縮 COPY sales FROM ‘s3://my-bucket/data/sales.csv.zst’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ CSV ZSTD;

複数ファイルの並列ロード

💡 例え話：複数車線の高速道路

【1ファイル = 1車線の道路】 ・全データが1台のトラックに ・渋滞発生、遅い 【複数ファイル = 複数車線の高速道路】 ・データを分割して複数のトラックに ・各車線を同時に走行（並列処理） ・超高速！ 【ポイント】 ファイル数 ≥ ノード数 × スライス数 → 全スライスが仕事を持てる

📝 プレフィックスで複数ファイルを指定

— S3のファイル構造 s3://my-bucket/data/sales/ ├── sales_001.csv.gz ├── sales_002.csv.gz ├── sales_003.csv.gz └── sales_004.csv.gz — フォルダを指定して全ファイルを並列ロード COPY sales FROM ‘s3://my-bucket/data/sales/’ — 最後の「/」が重要！ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ CSV GZIP IGNOREHEADER 1; — 各ノードが別々のファイルを同時に処理 — → 4ファイルなら最大4倍速！

注意：s3://my-bucket/data/sales（/なし）とs3://my-bucket/data/sales/（/あり）は異なります。/なしは「sales」という名前のファイルを指します。

マニフェストファイルの使用

📝 ロードするファイルを明示的に指定

— manifest.json（S3にアップロード） { “entries”: [ {“url”: “s3://my-bucket/data/sales_001.csv”, “mandatory”: true}, {“url”: “s3://my-bucket/data/sales_002.csv”, “mandatory”: true}, {“url”: “s3://other-bucket/data/sales_003.csv”, “mandatory”: true} ] } — COPYコマンド COPY sales FROM ‘s3://my-bucket/manifest.json’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ CSV MANIFEST; — マニフェストファイルを使用 — “mandatory”: true → ファイルがない場合エラー — “mandatory”: false → ファイルがなくてもスキップ

マニフェストを使う場面：

  • フォルダ内の一部のファイルだけロードしたい
  • 複数のS3バケットからロードしたい
  • ロードするファイルを厳密に制御したい

⚡ 3. バルクロードの最適化

最適化の4つのポイント

1️⃣ ファイルを分割

1つの大きなファイルより、複数の小さなファイルの方が速い。推奨：100MB〜1GB/ファイル

2️⃣ 圧縮する

gzip圧縮で転送量を削減。S3からの転送が速くなる。推奨：gzip

3️⃣ 並列度を上げる

ファイル数 ≥ ノード数 × スライス数。全スライスが並列処理できる。

4️⃣ ソート順を揃える

SORTKEYの順番でデータをソートしてからロード。VACUUM不要。

最適なファイル分割数の計算

📊 計算式

【計算式】 最適ファイル数 = ノード数 × スライス数/ノード × 倍数 【ノードタイプ別のスライス数】 dc2.large: 2スライス/ノード dc2.8xlarge: 16スライス/ノード ra3.xlplus: 2スライス/ノード ra3.4xlarge: 8スライス/ノード ra3.16xlarge: 16スライス/ノード 【例：dc2.large × 2ノード】 2ノード × 2スライス × 2倍 = 8ファイル 【例：dc2.8xlarge × 4ノード】 4ノード × 16スライス × 2倍 = 128ファイル

💡 具体例：10GBのデータをロード

【設定】 ・クラスター: dc2.large × 2ノード ・データ量: 10GB 【計算】 最適ファイル数 = 2 × 2 × 2 = 8ファイル 1ファイルのサイズ = 10GB ÷ 8 = 1.25GB/ファイル 【結果】 ✅ 1.25GB/ファイル → 推奨範囲内（100MB〜1GB） ✅ 8ファイル → 全スライスが並列処理可能 【ファイル分割コマンド（Linux）】 split -d -n 8 sales.csv sales_part_ # sales_part_00, sales_part_01, … sales_part_07 が生成

圧縮形式の比較

形式 圧縮率 解凍速度 推奨度 コメント
gzip 高い（70-80%削減） やや遅い ⭐⭐⭐ 最も一般的、バランス良い
zstd 高い（75-85%削減） 速い ⭐⭐⭐ 最新、高速かつ高圧縮
lzop 低い（50-60%削減） 最速 ⭐⭐ 速度重視の場合
bzip2 最高（80-90%削減） 遅い ⭐ 圧縮率重視、時間かかる

STATUPDATE と COMPUPDATE

📊 STATUPDATE：統計情報の更新

COPY sales FROM ‘s3://my-bucket/data/sales/’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ CSV STATUPDATE ON; — 統計情報を自動更新（推奨） — STATUPDATE ONのメリット： — ・クエリオプティマイザが正しい実行計画を作成 — ・クエリ性能が向上 — ・ロード後のANALYZE不要

🗜️ COMPUPDATE：圧縮エンコーディングの設定

— 初回ロード：COMPUPDATE ON（推奨） COPY sales FROM ‘s3://my-bucket/data/sales/’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ CSV COMPUPDATE ON; — 最適な圧縮を自動選択 — 追加ロード：COMPUPDATE OFF（推奨） COPY sales FROM ‘s3://my-bucket/data/sales_new/’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ CSV COMPUPDATE OFF; — 圧縮設定を変更しない — なぜ追加ロードでOFFにするのか？ — 圧縮エンコーディングが変わると、既存データと新データで — 圧縮方式が異なり、クエリ性能が低下する可能性があるため

🔧 4. エラーハンドリング

エラー許容設定

⚠️ MAXERROR：エラーを許容してロード継続

COPY sales FROM ‘s3://my-bucket/data/sales.csv’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ CSV MAXERROR 100; — 100件までのエラーを許容 — 動作： — ・エラーが100件以下 → ロード成功（エラー行はスキップ） — ・エラーが101件以上 → ロード失敗（全データがロールバック） — ユースケース： — ・ログデータなど、一部のエラーが許容できる場合 — ・データクレンジングが難しい場合

エラーログの確認

📋 STL_LOAD_ERRORSテーブル

— 最近のエラーを確認 SELECT starttime, — 発生時刻 filename, — ファイル名 line_number, — 行番号 colname, — カラム名 type, — データ型 err_reason — エラー理由 FROM stl_load_errors ORDER BY starttime DESC LIMIT 10; — 実行結果例 starttime | filename | line_number | colname | type | err_reason 2025-01-19 10:30:00 | sales_001.csv | 1523 | amount | numeric | Invalid digit 2025-01-19 10:30:00 | sales_001.csv | 2847 | amount | numeric | Invalid digit

📋 ロード履歴の確認

— 最近のロード結果を確認 SELECT query, — クエリID filename, — ファイル名 lines_scanned, — スキャンした行数 errors — エラー数 FROM stl_load_commits WHERE filename LIKE ‘%sales%’ ORDER BY starttime DESC LIMIT 10;

よくあるエラーと対処法

❌ エラー1：Access Denied

ERROR: S3ServiceException: Access Denied

原因：

  • IAM Roleに権限がない
  • S3バケットのアクセス許可が不足
  • S3パスが間違っている

対処法：

  • IAM RoleにAmazonS3ReadOnlyAccessをアタッチ
  • S3バケットポリシーを確認
  • S3パスを再確認（大文字小文字に注意）

❌ エラー2：Extra column(s) found

ERROR: Extra column(s) found

原因：CSVのカラム数がテーブルのカラム数より多い

対処法：

  • テーブル定義を確認：SELECT * FROM pg_table_def WHERE tablename = 'sales';
  • CSVのカラム数を確認：head -1 sales.csv | tr ',' '\n' | wc -l
  • IGNOREHEADERオプションを確認

❌ エラー3：Invalid digit, Value, or Sign

ERROR: Invalid digit, Value, or Sign

原因：データ型が合わない（例：文字列を数値列にロード）

対処法：

  • エラー行を確認：SELECT * FROM stl_load_errors ORDER BY starttime DESC LIMIT 1;
  • CSVのデータをクレンジング（空文字、特殊文字の除去）
  • 一時的にMAXERRORでエラーを許容してロード

❌ エラー4：Delimiter not found

ERROR: Delimiter not found

原因：指定した区切り文字がファイルに存在しない

対処法：

  • ファイルの区切り文字を確認：head -1 sales.csv
  • DELIMITERオプションを修正
  • タブ区切りならDELIMITER '\t'

トランザクション管理

🔄 COPYコマンドの原子性（Atomicity）

【重要な特性】 COPYコマンドは原子的（Atomic）です 成功 → 全データがロードされる 失敗 → 何もロードされない（全てロールバック） 【例：100万件中、50万件目でエラー】 COPY sales FROM ‘s3://my-bucket/data/sales.csv’ … — エラー発生！ SELECT COUNT(*) FROM sales; — 結果: 0（全てロールバックされた） 【対策】 ・事前にサンプルデータでテスト ・MAXERRORで一部エラーを許容 ・データを分割して小さいバッチでロード

💪 5. 実践演習：100万件のデータロード

演習 1 実践

100万件の売上データをRedshiftに効率的にロードしてください

要件：

  • 100万件のサンプルデータを作成
  • データを複数ファイルに分割（最適化）
  • gzip圧縮してS3にアップロード
  • COPYコマンドでRedshiftにロード
  • ロード時間を測定

【解答例】

1. サンプルデータ作成（Python）

import pandas as pd import numpy as np from datetime import datetime, timedelta import gzip import boto3 import os # 100万件のサンプルデータ生成 np.random.seed(42) n_records = 1000000 data = { ‘sale_id’: range(1, n_records + 1), ‘sale_date’: [ (datetime(2025, 1, 1) + timedelta(days=np.random.randint(0, 365))).strftime(‘%Y-%m-%d’) for _ in range(n_records) ], ‘product_id’: np.random.randint(1, 1000, n_records), ‘customer_id’: np.random.randint(1, 10000, n_records), ‘amount’: np.random.randint(100, 100000, n_records), ‘quantity’: np.random.randint(1, 10, n_records) } df = pd.DataFrame(data) print(f”データ件数: {len(df):,}”) print(f”メモリ使用量: {df.memory_usage(deep=True).sum() / 1024**2:.2f} MB”)

2. データを8ファイルに分割＆圧縮

# 8ファイルに分割（2ノード × 2スライス × 2倍） num_files = 8 chunk_size = len(df) // num_files for i in range(num_files): start_idx = i * chunk_size end_idx = start_idx + chunk_size if i < num_files - 1 else len(df) chunk = df.iloc[start_idx:end_idx] filename = f'sales_{i+1:03d}.csv.gz' # gzip圧縮してCSV保存 chunk.to_csv(filename, index=False, compression='gzip') # サイズ確認 size_mb = os.path.getsize(filename) / 1024**2 print(f"作成: {filename} ({len(chunk):,} 件, {size_mb:.2f} MB)")

3. S3にアップロード

# S3にアップロード s3 = boto3.client(‘s3’) bucket = ‘my-bucket’ prefix = ‘data/sales/’ for i in range(num_files): filename = f’sales_{i+1:03d}.csv.gz’ s3_key = f'{prefix}{filename}’ s3.upload_file(filename, bucket, s3_key) print(f”アップロード: s3://{bucket}/{s3_key}”) print(f”\n全ファイルをアップロード完了！”)

4. Redshiftにテーブル作成

— テーブル作成 CREATE TABLE sales_large ( sale_id INT NOT NULL, sale_date DATE NOT NULL, product_id INT NOT NULL, customer_id INT NOT NULL, amount DECIMAL(10,2) NOT NULL, quantity INT NOT NULL ) DISTKEY(customer_id) — JOINで使用 SORTKEY(sale_date); — 日付範囲検索で使用

5. COPYコマンドで高速ロード

— ロード開始時刻を記録 SELECT GETDATE() as load_start_time; — 結果: 2025-01-19 10:00:00 — COPYコマンド実行 COPY sales_large FROM ‘s3://my-bucket/data/sales/’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftRole’ CSV GZIP — gzip圧縮 IGNOREHEADER 1 — ヘッダースキップ STATUPDATE ON — 統計情報更新 COMPUPDATE OFF; — 圧縮エンコーディング更新なし — ロード終了時刻を記録 SELECT GETDATE() as load_end_time; — 結果: 2025-01-19 10:00:45 — 件数確認 SELECT COUNT(*) FROM sales_large; — 結果: 1,000,000

6. 結果確認

【ロード結果】 データ件数: 1,000,000件 ファイル数: 8ファイル 圧縮前: 約40MB 圧縮後: 約10MB（75%削減） ロード時間: 約45秒 【最適化の効果】 ・8ファイル分割 → 全スライスが並列処理 ・gzip圧縮 → 転送量75%削減 ・DISTKEY/SORTKEY → クエリ性能向上

⏰ 演習終了後は必ずクラスターを一時停止！

Redshiftコンソール → クラスター選択 → アクション → クラスターを一時停止

📝 STEP 13 のまとめ

✅ このステップで学んだこと

  • COPYコマンドは大量データを高速にロードする専用コマンド
  • INSERT文より20〜50倍高速
  • CSV、JSON、圧縮ファイルなど様々な形式に対応
  • ファイルを分割して並列ロードすると最速
  • エラーハンドリングでMAXERRORやSTL_LOAD_ERRORSを活用

💡 重要ポイント

  • Redshiftへのデータロードは常にCOPYコマンドを使う
  • ファイル数 = ノード数 × スライス数 × 2〜4 が最適
  • gzip圧縮で転送量を削減
  • 初回ロードはCOMPUPDATE ON、追加ロードはOFF
  • エラーはSTL_LOAD_ERRORSで確認

🎯 次のステップの準備

次のSTEP 14では、「Redshiftクエリ最適化」を学びます。
ディストリビューションキー、ソートキー、EXPLAIN、VACUUMなどで性能を最大化しましょう！

📝 理解度チェック

問題 1 基礎

COPYコマンドがINSERT文より速い理由を3つ挙げてください。

【解答例】

  1. 並列処理：全ワーカーノードが同時にデータをロードする
  2. 直接S3から読み込み：各ノードが直接S3からデータを取得、ネットワーク帯域を最大活用
  3. バルク処理：1件ずつ処理せず、大量データをまとめて処理する
問題 2 基礎

以下のCOPYコマンドの各オプションの意味を説明してください。

COPY sales FROM ‘s3://bucket/data.csv.gz’ IAM_ROLE ‘arn:…’ CSV GZIP IGNOREHEADER 1 MAXERROR 100;

【解答】

  • CSV：CSV形式のファイル
  • GZIP：gzip圧縮されたファイル
  • IGNOREHEADER 1：最初の1行（ヘッダー行）をスキップ
  • MAXERROR 100：100件までのエラーを許容（101件目でロード失敗）
問題 3 応用

10GBのデータを2ノード（各2スライス）のRedshiftクラスターにロードする場合、最適なファイル分割数を計算してください。

【解答】

ノード数: 2 スライス数/ノード: 2 倍数: 2〜4（推奨） 最適ファイル数 = 2 × 2 × 2 = 8ファイル 1ファイルのサイズ = 10GB ÷ 8 = 1.25GB/ファイル → 8ファイルが最適（1.25GB/ファイルは推奨範囲内）

❓ よくある質問

Q1: COPYコマンドの実行時間の目安は？
データ量とクラスターサイズによります。目安（dc2.large × 2ノード）：
・1GB（圧縮後）：1〜2分
・10GB（圧縮後）：5〜10分
・100GB（圧縮後）：30分〜1時間

最適化（ファイル分割、圧縮）でさらに高速化できます。
Q2: COPYコマンド実行中にエラーが出たらどうなる？
全てロールバックされます。COPYコマンドは原子的なので、途中でエラーが発生すると、それまでにロードしたデータも全て破棄されます。

対策：MAXERRORオプションで一部のエラーを許容、または事前にサンプルデータでテスト。
Q3: 追加ロードでCOMPUPDATE OFFにする理由は？
初回ロードでは、Redshiftが最適な圧縮エンコーディングを自動設定します（COMPUPDATE ON）。

追加ロードで圧縮エンコーディングが変わると、既存データと新データで圧縮方式が異なり、クエリ性能が低下する可能性があります。そのため、追加ロードではCOMPUPDATE OFFを推奨します。
Q4: S3からの転送料金はかかる？
同じリージョンなら無料です。
・RedshiftとS3が同じリージョン：データ転送料金なし
・RedshiftとS3が別リージョン：$0.02/GB

コスト削減のため、RedshiftとS3は必ず同じリージョンに配置しましょう。
Q5: エラーの詳細を確認するには？
STL_LOAD_ERRORSテーブルを確認します：
SELECT * FROM stl_load_errors ORDER BY starttime DESC LIMIT 10;

ファイル名、行番号、エラー理由が確認できます。
← 前のステップ
STEP 12: Amazon Redshift入門 次のステップへ →
STEP 14: Redshiftクエリ最適化
📝

学習メモ

クラウドデータ基盤（AWS・GCP） - Step 13

💾 自動保存 · 0文字
📋 過去のメモ一覧 ▼
#artnasekai #学習メモ
LINE
ホーム
クラウドデータ基盤（AWS・GCP）