Redshiftでの次元モデリングとETL

私はデータウェアハウスの将来の代替品として、AmazonのRedshiftデータベースを調査しています。私の経験は常に次元モデリングとRalph Kimballの方法を使用してきたので、Redshiftが自動インクリメント列のシリアルデータ型などの機能をサポートしていないのを見るのは少し奇妙でした。

ただし、スタースキーマ用にRedshiftを最適化する方法についてのAWSビッグデータブログからのこの最近のブログ投稿があります：https : //blogs.aws.amazon.com/bigdata/post/Tx1WZP38ERPGK5K/Optimizing-for-Star-Schemas -Amazon-Redshiftでインターリーブされたソーティング

Redshiftでスタースキーマをロードするためのベストプラクティスは何ですか？これがRedshiftのドキュメントで解決されていません。

私はS3からステージングテーブルにファイルをインポートし、SQLを使用してルックアップなどの変換を行い、宛先テーブルに挿入する前に代理キーを生成することに傾倒しています。

これは他の人が現在行っていることですか？これを簡単にするためのお金の価値があるETLツールはありますか？

あなたは間違いなくRedshiftのインモンではなく、キンボールで正しい軌道に乗っています。

これにはいくつかのパターンがあり、私はそれらをすべて異なるユースケースで使用しました

1. 「ELT」パターン-ソーステーブルを完全にレッドシフトにロードします。データがロードされるまで、重要な変換は行わないでください。これには、s3にロードしてからredshift copyコマンドを使用するか、ソース（例：mysqlまたはpostgres）をターゲット（例：redshift）に同期できる「AWSデータ移行サービス」を使用することをお勧めします。次に、定期的に実行します。 sqlはredshift内で処理して、dimをファクトに入力します。必要に応じて、サードパーティのクラウドベースのツールを使用して、このプロセスを「簡素化」できます（Matillionなど）（サードパーティのツールの使用はお勧めしません）。
2. 「ETLパターン」-Apache Sparkを使用して、処理中のデータを変換します。ディメンションとファクトをredshift spark-> s3-> redshiftにロードします。これにはEMRを使用しましたが、これは良いことです。これは、AWS Glueを使用する場合のアプローチでもあります
3. 変形しないでください！-1）に似ていますが、ロードされたテーブルを使用するだけです。

ファクトやディメンションではなく値が繰り返される幅の広いテーブルがある場合、Redshiftがより適切に機能する場合があることに注意してください。その理由は、円柱状のアプローチにより、Redshiftがさまざまな値をかなり効率的なレベルまで圧縮できるためです。多くのディメンションを使用する場合とフラットワイドテーブルを使用する場合の公式はありません。唯一の方法は、実際に試してみることです。

いくつかのリンク

Redshiftタレット用AWS DMS

AWSグルー

ETLにはAWS Glueがあります。これは、（とりわけ）Redshiftにロードされる、管理されたサーバーレスETLサービスです。

https://aws.amazon.com/glue/

私は現在、同様のタスクを扱っています。それは、ETLプロセスを構築し、次元モデルを設計することです。私はそれを処理するための最良の方法について多くを調査し、MPPで作業するときに確実に適用すべきテクニックの驚くべき有用な情報源を見つけました。

質問に答える

Redshiftでスタースキーマをロードするためのベストプラクティスは何ですか？

必ずこのリソースを調べてください。きっとあなたはそれが信じられないほど役立つでしょう。これは、MPPカラムストアの使用を活用するための強力な手法を備えた、35ページ以下のドキュメントです。あなたが好きなコメントをサポートしています

ファクトやディメンションではなく値が繰り返される幅の広いテーブルがある場合、Redshiftがより適切に機能する場合があることに注意してください。その理由は、円柱状のアプローチにより、Redshiftがさまざまな値をかなり効率的なレベルまで圧縮できるためです。多くのディメンションを使用する場合とフラットワイドテーブルを使用する場合の公式はありません。唯一の方法は、実際に試してみることです。

ジョン・スコットによるコメント

あなたがそれが私と同じくらい役立つことを願っています

S3からのロードは一般的なパターンだと思います。

一意性の制約を適用する必要があったため、Postgresに書き込み、その後10分ごとに新しいデータをレッドシフトに複製することを選択しました。

Redshiftにロードするには、https：//github.com/uswitch/blueshiftを使用します。

Redshiftは円柱状のデータベースであるため、ストレージとクエリのパフォーマンスはRDBMSモデルとは異なります。柱状データベースの最適化も異なります。通常はディスクI / Oが少なく、ディスクから読み込まれるデータも少ないため、クエリが高速になります。

あなたが参照しているAWSブログ投稿に関しては、それらの推奨事項を確認し、分散、キー、カーソル、ワークロード管理などのデータに最適なオプションを検討し、少なくともアプローチについて良い考えがあると思いますあなたが使うでしょう。視覚的な表現で作業する方が簡単だと思うので、既存のテーブルがどのようにRedshiftに移行するのかを示す、ダーティなDBダイアグラムを検討することをお勧めします。主要なデータをカバーして、どこにデータがいくら送られているのかを把握します。そして、私は確かにAmazonのODBC / JDBCドライバーを使用します。大量のデータをロードすることは、いずれにしても面倒であり、別のDBタイプへの移行がはるかに少なくなります。

ETL / ELTに関しては、他のポスターが述べているようにAWS Glueがあります。そして、はい、いくつかのツールがあり、そのうちのいくつかは無料です。Amazonには、DBのベストプラクティスガイドがあり、これも役立つ場合があります。他のフォーラムで私が見たヒントの1つは、データを可能な限りローロードして、Redshiftで変換を行うことです。それはあなたをELTプロセスに導くでしょう。非常に多くのオプションがあるため、おそらく2つの方法の比較を見ると役立つでしょう。ここに違いを説明するPanopolyのブログ記事があります。それはあなたが道を決めるのを助けるかもしれません。

Amazonは最近、RedshiftでETLのいくつかのベストプラクティスを公開しました

https://aws.amazon.com/blogs/big-data/top-8-best-practices-for-high-performance-etl-processing-using-amazon-redshift/

このトピックのトニーギブスに関するプレゼンテーションでは、AWS Solution ArchitectがUPSERTスタイルのロードに次のパターンを推奨しています。

1. ステージングテーブルに（S3から）CSVデータを読み込む
2. prdテーブルから一致する行を削除する

3. ステージからデータを挿入する

   BEGIN;
   CREATE TEMP TABLE staging(LIKE …); — copies dist keys
   copy staging from ’s3://… COMPUTE OFF;
   DELETE deep_dive d
   USING staging s WHERE d.aid = s.aid;
   INSERT INTO deep_dive SELECT * FROM staging
   DROP table staging;
   COMMIT;
   

可能であれば、ゴースト行を回避するために、DROP TABLEまたはTRUNCATEをDELETEよりも優先してください。

彼の講演とスライドのビデオをご覧ください。

私たちのチームでは、通常、SQL COPYステートメントを使用して、S3から直接Redshiftにデータをロードします。

また、優れたApache Airflowツールを使用してすべてのETLを管理します。

Redshiftに直接書き込むStichなどの統合サービスを使用し、CREATE TABLE LIKEとSELECT INTO を使用してデータを別のスキーマに移動します。