[レポート] (ANT334) オンプレミスデータウェアハウスからAmazon Redshiftに記録的な速さで移行する方法（Fannie Mae） #reinvent

石川覚

2019.12.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは！DA事業本部の石川です！

本記事はAWS re:Invent 2019のセッションレポートとなります。オンプレミスデータウェアハウスからAmazon Redshiftに記録的な速さで移行する方法（Fannie Mae）についてのセッションのレポートです。前半はTony GibbsさんがRedshiftの基本やマイグレーションについて解説した後、後半は、Fannie Maeのエンタープライズデータウェアハウス(EDW)の移行事例について紹介しています。

概要

Modern data warehousing blends and analyzes all your data—in your data warehouse and in your data lake—without needing to move the data. In this session, a representative from Fannie Mae explains how they migrated from a leading on-premises data warehouse to Amazon Redshift in record time. See how the company uses AWS Database Migration Service (AWS DMS), AWS Schema Conversion Tool, AWS Glue, and Amazon Redshift to provide timely analytics across the organization.

最新のデータウェアハウスは、データウェアハウス内およびデータレイク内のすべてのデータを、データを移動することなくブレンドおよび分析します。このセッションでは、Fannie Maeの代表者が、主要なオンプレミスデータウェアハウスからAmazon Redshiftに記録的な速さで移行した方法について説明します。会社がAWS Database Migration Service（AWS DMS）、AWS Schema Conversion Tool、AWS Glue、およびAmazon Redshiftを使用して組織全体でタイムリーな分析を提供する方法をご覧ください。

スピーカー

https://dev.classmethod.jp/wp-content/uploads/2019/01/httpstls.oguri_.classmethod.infoindex.html-2019-01-25-06-37-20.png

動画

オンプレミスデータウェアハウスからAmazon Redshiftに記録的な速さで移行する方法（Fannie Mae）

Amazon Redshift : データウェアハウスとは

ANSI SQL - ACID データウェアハウス
速く、パワフル、シンプルなデータウェアハウスを1/10のコストで提供する
超並列演算（MPP）、ペタバイトスケール

PostgreSQLをベースにAWSクラウド対応と、OLAP、MPP、カラムナを兼ね備えたDWHであり、サービス開始の2013/02から2019/12現在までに、175の重要なパッチ、300の重要な機能が追加されている

Amazon Redshift architecture

超並列、シェアードナッシング、カラムナアーキテクチャ
リーダーノード
- SQLエンドポイント
- メタデータストア
- 並列SQL処理に合わせる
コンピュートノード
- カラムなストレージを内部に持つ
- 並列でクエリを実行する
- ロード、アンロード、バックアップ、リストア
Amazon Redshift Spectrum nodes
- S3に対してクエリを直接実行する

用語と概念

カラムナ
- ディスク上のデータを保存するためにカラムナアーキテクチャを採用している
- 分析クエリのためのI/Oの削減が目的
- データを行ではなくカラムごとに物理的にディスクに保存する
- 必要に応じてカラムデータのみを読み取る
圧縮
- より多くのデータ保存し、I/Oを削減してパフォーマンスを改善する目的
- クラスタに２倍から４倍のデータを保存する
- COPYコマンドは最初のロードの際にデフォルトで自動的にANALYZEとデータ圧縮する
- ANALYZE COMPRESSIONコマンドは既存のテーブルのカラムごとに適切な圧縮エンコードを見つける
ブロック
- カラムデータは1MBのイミュータブルなブロックに保持する
- ブロックは個別にエンコードされる
- ブロックには、最大数百万の値を含めることができる
ゾーンマップ
- 不要なI/Oを排除することが目的
- インメモリのブロックメタデータ
- ブロックごとに最大値、最小値を持つ
- 全てのブロックは自動的にゾーンマップに持つ
- クエリに不必要なデータブロックを効果的に読み飛ばす
データソート
- ゾーンマップの有効性を高め、I/Oを削減することにより、クエリの実行を高速化することが目的
- ゾーンマップを活用して、範囲制限スキャンで不要なブロック読み込みを減らすのに効果的
- テーブルに１つ以上のソートキーを定義することで達成できる
- 最適なソートキーは以下で選択
- クエリパターン
- ビジネス要件
- データ特性
スライス
- スライスは仮想コンピュートノードのように考えることができる
- データパーティショニングの単位
- 並列クエリ処理
- スライスに関する事実
- コンピュートノード毎に2もしくは16スライス
- テーブルの行はスライスに分散される
- スライスは自身のデータのみ処理する

データの分散

分散スタイルは、テーブルのデータがクラスター全体にどのように分散されるかを決定するテーブルプロパティ
- KEY: 値はハッシュ化、同じ値は同じ場所（スライス）に保存する
- ALL: すべてのデータはノードごとの最初のスライスに保存する
- EVEN: ラウンドロビン
- AUTO: EVENとALLの組み合わせ
目的
- 並列処理のためにデータを均等に分散する
- 並列処理している間のデータの移動を最小にする
まとめ
- 分散スタイルKEY
- ON句で使用されるカラムに分散することにより、大きなテーブル間のJOINパフォーマンスを最適化する
- INSERT INTO SELECTパフォーマンスを最適化する
- GROUP BYパフォーマンスを最適化する
- 分散されているカラムのカーディナリティは高く、行のスキューは発生しない
- 分散スタイルALL
- ディメンションテーブルとの結合パフォーマンスを最適化する
- 小さなテーブルのディスク使用を削減する
- 小さなもしくは中位のテーブルに設定する（3000行未満）
- 分散スタイルEVEN
- KEYもALLも適用されない場合
- 分散スタイルAUTO
- デフォルトの分散タイプ、分散キー ALL and EVENを組み合わせる

データウェアハウスのマイグレーションを加速する

AWS のマイグレーションツール

AWS Schema Conversion Tool（SCT）
- 商用データベースやデータウェアハウススキーマをオープンソースエンジンやAWSネイティブサービスであるAmazon AuroraやAmazon Redshiftに変換する
AWS Database Migration Service（DMS）
- 簡単かつ安全に1つのデータベースとデータウェアハウスをAWSに移行およびまたは複製する

AWS Schema Conversion Tool（SCT）

移行元のデータベースエンジンからマイグレーションする時、自動的にデータベーススキーマやコード変換作業を助けます。

同種／異種の移行のアセスメントレポート作成
スキーマ変換
データウェアハウスのスキーマ変換
アプリケーションコードの変換
組み込みアプリケーションの変換
コードブラウザでハイライト表示された箇所はマニュアルで変換
SSLによるセキュアなデータベース接続
サービスの置き換え／AWS GlueによるモダンなETLへ移行
SCT data extractorを用いてデータをデータウェアハウス並行する
スキーマをRedhiftに最適化する

SCT data extractor

移行元のデータウェアハウスからデータを取り出し、Redshiftにデータを移行するツール

移行元のデータウェアハウスと同じ場所に複数のマイグレーションエージェントを配置する
Redshiftにデータを最適化して、ローカルファイルに保存する
ファイルはS3（ネットワークを介するか、Snowball Edgeを用いる）に保存して、最終的にRedshiftにロードする

AWS Database Migration Service（DMS）

移行元のデータベースエンジンからマイグレーションする時、DMSのインスタンスを介して自動的にデータベーススキーマやコード変換作業を助けます。

ユースケース

オンプレミスーAWS間のマイグレート
データベース間のマイグレート
自動スキーマ変換
ダウンタイム無しでデータを同期

従来のデータウェアハウスからマイグレートするTips

従来の行指向のデータウェアハウスから移行する場合
- 効果的なテーブルの非正規化（ファクトテーブルの中にディメンジョンカラムを含める）
- 日付のディメンジョンテーブルを避ける
- Redshiftはカラムナストレージと列圧縮なので、カラム数の多いテーブルが効果的
従来のSMPデータウェアハウスから移行する場合
- 速くJOINするにはテーブルのコロケーション（結合するレコードを同じロケーションに配置）が必要
- 分散スタイルALLやAUTOもしくはKEYを活用
- Redshiftはビッグデータ用途に設計されている（100GB以上からPBスケール）
- 小規模データセットはAmazon Aurora Postg　reSQLを検討する
- ワークフローをトランザクションで囲む　
素早い移行のためにストアド・プロシージャを活用する
- PL/pgSQLストアドプロシージャは、既存のプロシージャを簡単に移行できるように追加された

Fannie Maeのエンタープライズデータウェアハウス(EDW)とデータマートの移行

Fannie Maeは連邦住宅抵当公庫であり、アメリカの金融機関です。Fannie Maeはデータ分析と研修が不可欠であり、ビジネスにおいてデータウェアハウスは重要な役割を果たしています。

オンプレミス環境に引き続きアクセスしながら、クラウド移行しました。データマートの移行はDMS、SnowballEdge、バッチ処理を用いてデータを移行しています。異なる部門間のデータ共有にRedshift Spectrumを活用しています。

Redshiftのキーになった機能は、Redshift Spectrum、Concurrency Scaling、Elasticache、AutoWLM、Redshift Advisorです。Concurrency Scalingを組み合わせることで、半分のノード数を削減と同時実行が増えても一貫したパフォーマンスが得られました。

移行の学び
- DS2はコスト圧縮に効果的
- Concurrency Scalingは読み取り専用クエリに効果的、60秒でスケーリング
- ノードを増やせばよいというものではないので、スイートスポットを探す
- AWSエコシステムの統合はパフォーマンスとコストと同じぐらい重要
- ユーザーのトレーニングは重要

AWSLabs on GitHub - Amazon Redshift

https://github.com/awslabs/amazon-redshift-utils
https://github.com/awslabs/amazon-redshift-monitoring
https://github.com/aws-samples/amazon-redshift-udfs
Admin scripts
- クラスターで診断を実行するためのユーティリティのコレクション
Admin Views
- スキーマDDLを生成するためのビューのコレクション
Stored Procedures
- クラスターを管理する、または単に例として使用するためのストアドプロシージャのコレクション
Column Encoding Utility
- すでにロードされているデータを利用して、　既存のスキーマに最適な列エンコードを設定するユーティリティ

まとめ

この2年間で、Redshift Spectrum〜Concurrency Scaling〜自動メンテナンス・自動チューニング〜RA3やAQUAなど目まぐるしい進化を遂げていますが、一方で変わることのない基本についてフォーカスしています。今回のre:Invent2019は、全体的に「原点回帰」を感じましたが、このセッションも2014年の頃のような、Redshitの基本アーキテクチャや用語や概念について丁寧に解説されていました。決して難しい内容ではありませんが、これからRedshiftのPoCや移行を検討する方にとっては、要点が完結にまとめられた「良い」セッションと感じましたので紹介しました。