データウェアハウスの将来の代替品として、AmazonのRedshiftデータベースを調査しています。私の経験は常に次元モデリングとRalph Kimballの方法を使用してきたので、Redshiftが自動インクリメント列のシリアルデータ型などの機能をサポートしていないのを見るのは少し奇妙でした。
ただし、スタースキーマ用にRedshiftを最適化する方法に関するAWSビッグデータブログからの最近のブログ投稿があります。 https://blogs.aws.Amazon.com/bigdata/post/Tx1WZP38ERPGK5K/Optimizing-for -Star-Schemas-and-Interleaved-Sorting-on-Amazon-Redshift
Redshiftでスタースキーマをロードするためのベストプラクティスは何ですか?これがRedshiftのドキュメントで解決されていません。
S3からステージングテーブルにファイルをインポートし、SQLを使用してルックアップや代理キーの生成などの変換を行ってから、宛先テーブルに挿入します。
これは他の人が現在行っていることですか?これを簡単にするためにお金の価値があるETLツールはありますか?
あなたは間違いなくRedshiftのインモンではなく、キンボールで正しい軌道に乗っています。
これにはいくつかのパターンがあり、私はそれらをすべて異なるユースケースで使用しました
ファクトやディメンションではなく値が繰り返される幅の広いテーブルがある場合、Redshiftがより適切に機能する場合があることに注意してください。この理由は、円柱状のアプローチにより、Redshiftがさまざまな値をかなり効率的なレベルまで圧縮できるためです。多くのディメンションを使用する場合とフラットワイドテーブルを使用する場合の式がありません。唯一の方法は、実際に試して見ることです。
いくつかのリンク
私は現在、同様のタスクを扱っています。それは、ETLプロセスを構築し、次元モデルを設計することです。私はそれを処理するための最良の方法について多くを調査し、MPPで作業するときに確実に適用すべきテクニックの驚くべき有用な情報源を見つけました。
質問に答える
Redshiftでスタースキーマをロードするためのベストプラクティスは何ですか?
this resource を確認してください。きっとあなたはそれが信じられないほど役立つでしょう。これは、MPPカラムストアの使用を活用するための強力なテクニックを備えた35ページ以下のドキュメントです。あなたが好きなコメントをサポートしています
ファクトやディメンションではなく値が繰り返される幅の広いテーブルがある場合、Redshiftがより適切に機能する場合があることに注意してください。この理由は、円柱状のアプローチにより、Redshiftがさまざまな値をかなり効率的なレベルまで圧縮できるためです。多くのディメンションを使用する場合とフラットワイドテーブルを使用する場合の式がありません。唯一の方法は、実際に試して見ることです。
ジョン・スコットによるコメント
あなたがそれが私と同じくらい役立つことを願っています
ETLにはAWS Glueがあります。これは、(とりわけ)Redshiftにロードされる、管理されたサーバーレスETLサービスです。
Amazonは最近、RedshiftでETLのいくつかのベストプラクティスを公開しました
このトピックに関するプレゼンテーションでは、AWS Solution ArchitectがUPSERTスタイルのロードに対して次のパターンを推奨しています。
ステージからデータを挿入する
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 を使用してデータを別のスキーマに移動します。
Redshiftは円柱状のデータベースであるため、ストレージとクエリのパフォーマンスはRDBMSモデルとは異なります。柱状データベースの最適化も異なります。通常はディスクI/Oが少なく、ディスクから読み込まれるデータも少ないため、クエリが高速になります。
参照しているAWSブログの投稿に関しては、それらの推奨事項を確認し、分散、キー、カーソル、ワークロード管理などのデータに最適なオプションを検討し、少なくともアプローチについて良い考えがあると思いますあなたが使うでしょう。私は視覚的な表現で作業する方が簡単だと思います。既存のテーブルがどのようにRedshiftに移行するかを示す、ダーティで迅速なDBダイアグラムを検討するかもしれません。主要なデータをカバーして、どこにデータがいくら送られているのかを把握します。そして、私は確かにAmazonのODBC/JDBCドライバーを使用します。大量のデータをロードすることは、いずれにせよ面倒であり、別のDBタイプへの移行がはるかに少なくなります。
ETL/ELTに関しては、他のポスターが述べているようにAWS Glueがあります。そして、はい、いくつかのツールがあり、そのうちのいくつかは無料です。 Amazonには DB Best Practices Guide があり、それも役立つかもしれません。他のフォーラムで私が見たヒントの1つは、データを可能な限りそのままロードし、Redshiftで変換を行うことです。それはあなたをELTプロセスに導きます。非常に多くのオプションがあるため、おそらく2つの方法の比較を見ると役立つでしょう。これは、違いを説明するPanopolyからの ブログ記事 です。これは、パスを決定するのに役立つ場合があります。
S3からのロードは一般的なパターンだと思います。
一意性の制約を適用する必要があったため、Postgresに書き込み、10分ごとに新しいデータをレッドシフトに複製することを選択しました。
Redshiftにロードするために https://github.com/uswitch/blueshift を使用します。