Redshiftへのデータ流し込み(Batch)
Batchを作ることになったので、そちらを書いていきます。warningを解消する際にすでに公開していたバッチですが、コードを改善したのでまた載せていきます。
サンプルコードは参考までにしてください。
前提
検討・方針
AWS DATAPIPEを利用することも検討したけれど、テーブル毎に定義を増やさなければいけないので、管理しづらいと思いこちらは辞めた。APPにタスクを作成して、バッチ処理することで対応する。ただし、migrationに伴うテーブル定義の変更をRedShift側に伝播できる仕組みはないので、こちらは手動でsqlを回すことになる。(データコピーで利用するテーブルカラムを限定して、設計の時間を稼ぐこともできるがそれも今回はやらない)
処理の流れは、
- dumpファイルの作成し1GBを超える場合は分割(updated_atで期間は絞る)
- S3へアップロード
- コピー用テーブルを作成
- コピー用テーブルにデータコピー
- コピー用テーブルとターゲットテーブルでマージして、UPSERTを実行
- コピー用テーブルを削除
です。
RDBに処理するファイルとステータスを登録・更新し、タスク完了時には、Slackへ通知。(サンプルコードには載せていません）
dumpファイルの作成し1GBを超える場合は分割(updated_atで期間は絞る)
Redshift のCOPY SQLコマンドは、データを複数ファイルに分割することが推奨されています。
注記 データを複数のファイルに分割し、並列処理の長所を最大限に活用することをお勧めします。
分割するファイル数は、ノード数 x スライス数の倍数になります。ds2.xlargeのノードタイプを利用しているので4ファイルに分割します。
S3へのアップロード
分割したファイル全てを所定のフォルダにアップロードします。今回model.idのフォルダを作成して、その直下にファイルをアップロードします。
コピー用テーブルを作成
テーブルの属性値は、実際に使われているテーブルを元に作成します。そうすることでコピー用テーブルの管理コストをなくします。
コピー用テーブルにデータコピー
COPYコマンドによりコピー用テーブルにデータをコピーします。
コピー用テーブルとターゲットテーブルでマージして、UPSERTを実行
コピー用テーブルの削除
課題(解決済み含む)
ノードタイプの変更に際して、ノードのストレージ使用量をみているが、テンポラリテーブルを利用することで一時的に使用量が増えることになる。 => タスクが動いた際に使用量の閾値を超えた場合にもアラートが出るので、このアラートが出たらタイプを変更する想定です。 アラートに起因しているかは、その時に調査する。
DBのマイグレーションの追随 => これが課題。Rails migrationを利用しているが、この変更にRedshift側のテーブルを追随させる必要がある。今回は, READMEに追加して、注意喚起しているが、migrationコマンドにフックする形でスクリプトを走らせることと、定義をmigrationから解析して反映させるツールを作ることを検討する。
調査と実装で重く、放置しても運用面で負荷が大きい。
