Redshiftで他システムと連携する方法 3つ【勉強メモ】 - BlueVancouver- アラサー　エンジニア転職@カナダ

今までは個人ではGCPを良く使っていたのですが、AWS Redshiftについて、ここ最近学ぶことが多かったので、備忘録として残しておこうと思います。分かったことは、これという正解がない（複数の正解がある）ことがわかったということです。

そもそもRedshiftとは。そしてRDSとの違い

RDSは、トランザクション処理型のオンライントランザクション処理（OLTP）ワークロードに最適化された DB。主なデータベースエンジンとして、MySQL、PostgreSQL、Oracle Database、Microsoft SQL Serverなど。
RDSは、データの挿入、更新、削除、トランザクションの処理が主な目的です。例えば、Webアプリケーション、モバイルアプリケーション、eコマースなどのトランザクションがメインのシステムに使用したい。

- Redshiftは、大容量のデータを高速に解析・クエリすることが可能で、主に、大量の業務データから、複雑な分析やビジネスインテリジェンス（BI）に使用したい。
- Redshiftは、カラムベースのストレージ方式を採用していて、高い圧縮率とクエリパフォーマンスを提供。また、複数のノードからなるクラスタ構成でスケーラブルな処理能力を持っている。

ここから本題

自分のAccountでRedshiftを持っているとする。他のAWS accountのRedshift(または別region)にデータを渡したい場合はどの選択肢があるか?

COPYコマンドを使用する：
- 自分のRedshift ->
  自分のs3 (相手のaccountにアクセス許す)->
  相手のaccountでs3からRedshiftにcopy
- COPYコマンドを使用して、データを一括でエクスポートおよびインポートする。
- ソースRedshiftクラスタからデータをエクスポートし、その出力データをS3に保存する。
- ターゲットRedshiftクラスタでCOPYコマンドを使用して、S3からデータをインポートします。
- この方法では、データの一括転送が可能ですが、データの一貫性や遅延に関する考慮が必要です。
- Pro: シンプルでわかりやすい。自分のaccount内でcopyコマンドだけを実行するGlueJobまたはLambdaを作って、毎日決まった時間にスケジューリング可能。
- Con:リアルタイムではない。相手が何らかのtransform必要な場合は追加でRedshiftの中でストアドか、s3からRedshiftの間にGlue Jobなど挟む必要あり。自分のRedshiftのschemaに何らかの変更があった場合、相手にいちいち連携する必要がある。よくこれで問題をみてきた。相手と自分で複雑な処理が必要な時はあまり向いていない。
- まとめると、この方法だけでもさらに複数のパターンがあって、便利。
- 1-1:Redshift (A)->S3(A)->copyしてRedshift (B)、つまり物理データを持つ
- 1-2:Redshift (A)->S3(A)->copyせずGlueCrawlerでS3(A)の新しいデータを認識する。その後、external tableとしてaccess Redshift (B) 、つまり物理データを持たない
- 1-3:Redshift (A)->S3(A)->何らかのtransformation->S3(B)->copyしてRedshift (B)
クロスアカウントアクセスを設定する：
- ソースAWSアカウントとターゲットAWSアカウント間でクロスアカウントアクセスを設定します。
- ソースRedshiftクラスタのデータを、ターゲットRedshiftクラスタに直接クエリやデータの転送を行うことができる。
- 注意として、自分はexternal schema を作る必要がある。
- 例)
  GRANT USAGE ON DATABASE sales_db TO Bob;
  
  CREATE EXTERNAL SCHEMA sales_schema FROM REDSHIFT DATABASE sales_db;
  
  GRANT USAGE ON SCHEMA sales_schema TO GROUP Analyst_group;
- Pro:相手が直接自分のRedshiftにアクセスできるので、リアルタイムかつ自分のすることは少ない。特定のスキーマだけアクセスを設定することも可能。
- Con: アクセス権限(Viewを作るなど)とセキュリティに注意する必要がある。
- 公式ドキュメント:
  https://docs.aws.amazon.com/redshift/latest/dg/manage-permissions.html
- Demo:
  https://www.youtube.com/watch?v=FW63-BehQg0
AWS Data Pipelineを使う
- ソースとなるRedshiftクラスタからのデータエクスポートする。
- Data Pipelineの定義ファイルで、ソースとなるRedshiftデータベースを指定。
- エクスポート活動（ExportActivity）を定義し、ソースデータベースからデータを抽出し、一時的なデータストア（例：S3バケット）にエクスポートします。
- 目的のRedshiftクラスタへのデータインポート:
  インポート活動（ImportActivity）を定義し、データのターゲットとなるRedshiftデータベースを指定します。
- インポート活動のパラメータで、エクスポートされたデータの場所（S3パス）を指定。
- 必要に応じて、データのマッピングや変換を行うために、データ変換活動（DataTransformActivity）を定義することもできます。
- スケジュールの設定:
  Data Pipelineの定義ファイルで、エクスポート活動とインポート活動を含むパイプラインを定義します。
- タスクスケジュール（例：毎日、毎週、または特定の日時）を設定して、パイプラインを実行する頻度を指定。

方法1) のcopyコマンドの自動化と方法3)のdata pipelineはどっちがいいのか。

人によって意見が分かれるかもしれませんが、自分の意見として、data pipelineではRedsihft->S3->Redshift間でデータストラクチャーのマッピングを定義できたり、追加のtransformationを加えられるので、柔軟。ただ、これは方法1-3のように、間にGlueJobやlambdaなど自分で追加処理は追加できるので、あまり柔軟性の軸で判断する意味はないと感じる。

どちらのoptionもLogとmonitoringを有効化すればcloud watchでアラートも設定できますし、あまり差は感じません。

個人的には、あまり言葉を選ばずに言えば、結局のところ、コストと速さをbench markingしてみて、あとは自分が慣れているものを使えばいいのではと思う。

まとめ

Cloudのプラットフォーム(AWS, GCP, Azure)の世界はどんどん便利になっていて、とてもありがたいですし、開発者の皆様に感謝しています。