Amazon Redshift は書き込みではなく読み取り用に最適化されているため、ETL ツール (私の場合は Pentaho データ統合) を使用してゆっくりと変化するディメンション手順を管理するにはどうすればよいですか?
ETL ツールは行ごとに更新/挿入 (ディメンションの参照/更新) を行うため、パフォーマンスは非常に低くなります。
誰かがすでにこの問題を経験していますか?
Amazon Redshift は書き込みではなく読み取り用に最適化されているため、ETL ツール (私の場合は Pentaho データ統合) を使用してゆっくりと変化するディメンション手順を管理するにはどうすればよいですか?
ETL ツールは行ごとに更新/挿入 (ディメンションの参照/更新) を行うため、パフォーマンスは非常に低くなります。
誰かがすでにこの問題を経験していますか?
更新はトランザクションで実行される一連の操作であるため、Redshift の更新は低速です。
そして、これらすべてをノード間で調整する必要があります。
1 つの行を更新すると、更新された 1000 行ほどの時間がかかる場合があります。さらに悪いことに、更新には非常に時間がかかり、書き込みロックが必要なため、長時間にわたってクエリがブロックされ、システム全体のパフォーマンスに大きな影響を与えます。
高速化するには3つの方法があります(すべて経験から):
更新は避けてください。
新しい行と古い行を区別できる条件がある場合は、新しい行をテーブルに追加し、その条件でクエリを変更します。Redshift の実行速度が速くなっていることに驚かれることでしょう。システムに過負荷をかける更新がないため、各クエリが少し複雑になっている可能性がありますが、それらのクエリはより高速に実行される可能性があります (dist キーが正しいことを確認してください)。
たとえば、ビジネス キーごとの最大タイムスタンプの条件は、驚くほど高速に実行されます (特に、ビジネス キーが分散キーである場合、すべてが並行して実行されます)。
これが望ましい解決策です。
バッチで更新を実行します。
更新が行の範囲に適用される場合は、where 条件を使用して一度にすべてを更新します。マイレージは異なる場合がありますが、1000 のバッチはうまく機能します。
「新しい」行を格納するテーブルを作成し、そのテーブルが 1000 行以上になったら結合を使用して更新します。