(レポート) ISM303: エンタープライズデータウェアハウスのAmazon Redshiftへの移行 #reinvent

今やAmazon Redshiftは様々な企業で活用され、その効果を存分に発揮しています。エンタープライズシステムにおいてもAmazon Redshiftを活用し、データを移行するというケースは良く見られるようになりましたが、一方で移行に関する問題や課題等に悩まされるというお話も良く伺います。そこで当エントリではそのケースにズバリな『エンタープライズデータウェアハウスのAmazon Redshiftへの移行』(意訳タイトル。英語原題:"Migrating Your Enterprise Data Warehouse to Amazon Redshift")というセッションに参加してきた際のレポートをご紹介したいと思います。

当セッションのスライド資料

当セッションについては既にスライド資料がSlideshareで公開されていたので共有します。

データロードの選択肢

データロードのオプションには色々な選択肢がある。

• Amazon S3へのパラレルアップロード
• AWS Direct Connect
• AWS Import/Export
• Amazon Kinesis
• システムインテグレータを使う

変更をロード

システム内の変更を識別し、Amazon S3へデータを移動。変更をロードする方法には以下の様なものがある。

• "Upsertプロセス"を使う
• パートナー企業のETLを使う

UPSERT

• 目的としては、Amazon Redshift内での新しいデータの追加と変更箇所の更新。
• データを一時的なステージングテーブルにロード。
• 本番用テーブルとステージングテーブルを結合し、共通の行を削除。
• 新しいデータを本番用テーブルにCOPY。
• 詳細については下記ドキュメントを参照。
• 新しいデータの更新と挿入 - Amazon Redshift

COPYコマンド

• (大前提)データ投入の際はCOPYコマンドを使うこと。
• 空テーブルに対するCOPY実行の際にはCOMPUPDATEオプションを使う。
• 自動圧縮ありでテーブルをロードする - Amazon Redshift
• スライスそれぞれがロード出来るファイルは1回に1つのみ。入力ファイルを分割することで、全てのスライスがパラレルにデータをロード出来るようになる。
• データを複数のファイルに分割する - Amazon Redshift
• manifestファイルを使う。
• マニフェストを使用し、データファイルを指定する - Amazon Redshift

プライマリーキーとマニフェストファイル

Amazon Redshiftはプライマリーキー制約が強制されません。 + もしデータが複数回ロードされた場合、Amazon Redshiftにはそのまま重複登録されてしまう。 + DMLで定義すると、オプティマイザがそのデータは一意なものであると想定する。

何をロードするか、ファイルが存在しない時にどのように振る舞うか等の制御を正確に行うためにはマニフェストファイルを使う。 + Amazon S3上にJSON形式のマニフェストを定義。 + ロードして欲しいものをクラスタがちゃんとロードしている事を確認。

Redshiftへの移行を行う事による効果・メリット

発表者がこのタイミングで変わり、Boingo社のRedshift移行に関する事例紹介とその時の問題点・改善点、移行に於ける各種効果やメリット等が説明されました。これらの対応を施す事で、

以下の様に様々な面で大幅に改善を行う事が出来ました、と報告しています。

また、これらの点以外にも、AWSの各種ーサービスを用いている事で様々なメリットを得られているという点にも触れていました。

Edmunds.com社の取り組みと学び

車バイヤーのEdmunds.comの事例および取り組みの紹介。致命的に遅いクエリ／高いシステムリソース利用率／データロードが遅い／タイムアウト等などの局面を改善するという挑戦に取り組んだ際の学びについて詳細な解説がなされました。

クエリ

• 『SELECT *』はNo.1のパフォーマンス殺しな操作。
• 主なソート列に対してWHERE句を用いる。
• "テンポラリテーブル"を作成するクエリに気を付ける。
• 実行に長い時間が掛かるクエリはダウンストリームサービスに影響が及ぶかも
• 制約の定義

VACUUM

• VACUUMはこまめに行う。
• データロード後に実施
• VACUUMに掛かった時間をモニタリング。

データのロード

• ソートキーの順序に沿ってロードする。
• 複数ファイルに分割してロードする。(サイズは1MBから1GBまで)
• 圧縮を使う

内部構造

Redshiftに於けるスライス等の構造については以下の様な形となっています。

• 全てのノードはスライスに分割されている。1コアあたり1スライス。
• それぞれのスライスにはメモリやCPU、ディスクスペースが割り当てられている。
• それぞれのスライスはパラレルでワークロードの処理を実行している。

監視

• 管理コンソール／Amazon CloudWatchによるモニタリング：CPU、メモリ、プロセスが監視可能
• スライスを跨ぐデータ分散
• テーブル毎のスペース利用状況
• WLMクエリカウント、キューの待ち時間、実行時間
• コミット統計、時間の掛かるクエリの確認

さいごに

こうしてみると、エンタープライズという規模の大小に関わらず、Amazon Redshiftのパフォーマンス改善が見込める部分は多そうです。確認観点として定期的にこれらの情報をウォッチしておき、更なる性能改善、パフォーマンスの向上に役立てて行きたいですね。以上、ラスベガスの現場からお送り致しました。