🎯 30秒でわかる！Redshift Data Sharing とは
一言でいうと：データをコピーせずに、別のRedshiftクラスターとリアルタイムでデータを共有できる機能！
図書館で例えると：本を複製せずに、他の図書館の利用者にも同じ本を読めるようにする仕組み📖
📦 コピー不要
データを物理的にコピーする必要がない。元データへの「読み取りアクセス」を許可するだけ！
⚡ リアルタイム
Producer（提供者）がデータを更新すると、Consumer（利用者）も即座に最新データを参照可能！
💰 コスト削減
ストレージの重複がないため、保存コストを大幅削減。ETLパイプラインも不要！
🔒 セキュア
細かい権限管理が可能。誰に・どのデータを・どこまで共有するか完全にコントロール！
📖 図書館で理解するData Sharing
Redshift Data Sharing = 「図書館ネットワーク」
あなたの街の図書館が持っている貴重な本を、他の街の図書館でも読めるようにする仕組みです！
従来の方法
「本をコピーして送る」
他の図書館が本を読みたいと言ったら、その本を全部コピーして郵送する。
• コピー代と郵送代がかかる（💸 コスト増）
• コピーに時間がかかる（⏰ 遅延）
• 原本が更新されてもコピーは古いまま（📅 データの鮮度低下）
• 各図書館に本の保管場所が必要（📦 ストレージ重複）
Data Sharing
「閲覧カードを発行する」
他の図書館に「うちの本を読める特別閲覧カード」を発行する。本自体は動かさない！
• コピー不要（💰 コスト削減）
• 即座にアクセス可能（⚡ リアルタイム）
• 原本が更新されれば最新を読める（🔄 常に最新）
• 保管場所は1箇所だけ（📦 ストレージ効率UP）
🔄 Data Sharing の仕組み
Producer
データを持っている側
（本を所有する図書館）
Datashare
共有の設定・許可証
（特別閲覧カード）
Consumer
データを利用する側
（閲覧カードで読む人）
📦 主要コンポーネント
Producer クラスター
データを所有し、共有を提供するRedshiftクラスター。
図書館で言うと：貴重な本を所蔵している「本館」
Datashare
共有するデータの「コンテナ」。テーブル、ビュー、スキーマなどを含む。
図書館で言うと：「この棚の本は共有OK」というリスト
Consumer クラスター
共有されたデータにアクセスするRedshiftクラスター。
図書館で言うと：閲覧カードで本を読める「分館」
Namespace
クラスターを識別するための一意の識別子。
図書館で言うと：各図書館の「会員番号」
⚡ 従来の方法 vs Data Sharing
❌ 従来のデータ共有方法
- 📦 データをS3にエクスポートしてコピー
- ⏰ ETLパイプラインの構築・管理が必要
- 💾 各クラスターにデータを重複保存
- 📅 データの鮮度に遅延が発生
- 💸 ストレージコストが2倍、3倍に
- 🔧 同期処理の運用・監視が必要
- 🐛 データ不整合のリスク
✅ Redshift Data Sharing
- 🚀 SQLコマンド数行で共有設定完了
- ⚡ ETL不要、リアルタイムアクセス
- 💰 データは1箇所のみ保存
- 🔄 常に最新データにアクセス可能
- 📉 ストレージコストを大幅削減
- 🎯 運用コストほぼゼロ
- ✨ データの一貫性を保証
💼 こんな時に使おう！ユースケース
マルチテナントSaaS
複数の顧客（テナント）に、それぞれ専用のデータアクセスを提供。各顧客は自分のデータだけを見られる！
部門間データ共有
営業部門のデータを、マーケティング部門やファイナンス部門と安全に共有。部門ごとに必要なデータだけを許可！
グローバル展開
本社（東京リージョン）のデータを、海外拠点（US、EU）のクラスターと共有。グローバルレポートが瞬時に！
パートナー連携
取引先やパートナー企業と、必要なデータだけを安全に共有。機密データは隠しつつ、協業を促進！
データ収益化
AWS Data Exchangeを通じて、自社のデータセットを販売。新しい収益源を創出！
開発・本番環境の分離
本番データを開発環境と共有して、リアルなデータでテスト。ただしコピーは作らない！
🛠️ Data Sharing 設定の流れ
📋 Datashare を作成する（Producer側）
共有するデータの「入れ物」を作成します。これが閲覧カードの発行準備です。
📦 共有するオブジェクトを追加（Producer側）
スキーマやテーブルなど、共有したいデータを Datashare に追加します。
🔑 Consumer に権限を付与（Producer側）
どのアカウント/クラスターがアクセスできるかを指定します。
📖 データベースを作成（Consumer側）
Consumer側で、Datashareからデータベースを作成してアクセスできるようにします。
🎉 データにアクセス！（Consumer側）
通常のSQLクエリでデータにアクセスできます。データはコピーされていません！
💰 料金の考え方
Producer側
ストレージ費用：データを保存しているので、通常通りストレージ料金が発生
Consumer側
コンピュート費用：クエリを実行するための計算リソース料金のみ。ストレージ費用は不要！
クロスリージョン
データ転送費用：リージョン間でデータを読み取る場合、データ転送料金が発生
Data Exchange
サブスクリプション費用：マーケットプレイスでデータを購入する場合、販売者が設定した料金
🔒 最小権限の原則
必要なテーブルだけを共有しましょう。スキーマ全体ではなく、特定のテーブルのみを追加することをおすすめします。
👁️ ビューを活用
機密列を除外したビューを作成して共有すれば、データのマスキングが可能。Consumer には見せたくない情報を隠せます。
📊 監視を忘れずに
CloudWatchでData Sharingのメトリクスを監視。誰がいつアクセスしたかを追跡しましょう。
🏷️ 命名規則を統一
Datashare名には目的や内容がわかる名前をつけましょう。例：`sales_team_datashare`、`marketing_reports_share`
⚡ Serverlessも対応
Redshift ServerlessでもData Sharingは利用可能！プロビジョンドクラスターとServerless間でも共有できます。
🔄 定期的な見直し
不要になったDatashareは削除しましょう。アクセス権限も定期的に棚卸しすることをおすすめします。
🎓 まとめ
📚 図書館 = Redshift Data Sharing
本をコピーせずに「閲覧カード」で共有するように
データをコピーせずに「Datashare」でリアルタイム共有！
ETLパイプラインも不要
即座にアクセス可能
監査ログも完備
Producer = データを持っている側（本を所有する図書館）
Consumer = データを利用する側（閲覧カードで読む人）
Datashare = 共有設定の入れ物（特別閲覧カード）
同一アカウント・クロスアカウント・クロスリージョンで柔軟に共有可能！🎉