【レポート】古いDWHからモダンなデータレイクへマイグレートする #reinvent #ABD327

原題

ABD327 - Migrating Your Traditional Data Warehouse to a Modern Data Lake

概要

In this session, we discuss the latest features of Amazon Redshift and Redshift Spectrum, and take a deep dive into its architecture and inner workings. We share many of the recent availability, performance, and management enhancements and how they improve your end user experience. You also hear from 21st Century Fox, who presents a case study of their fast migration from an on-premises data warehouse to Amazon Redshift. Learn how they are expanding their data warehouse to a data lake that encompasses multiple data sources and data formats. This architecture helps them tie together siloed business units and get actionable 360-degree insights across their consumer base.

このセッションでは、Amazon RedshiftとRedshift Spectrumの最新の機能について議論し、そのアーキテクチャと内部の仕組みを詳しく説明します。最近の可用性、パフォーマンス、および管理の拡張機能の多くと、それらがエンドユーザーエクスペリエンスをどのように向上させるのかを共有しています。また、21st Century Foxからは、オンプレミスのデータウェアハウスからAmazon Redshiftへの高速移行のケーススタディが紹介されています。データウェアハウスを複数のデータソースとデータ形式を含むデータレイクに拡張する方法を学びます。このアーキテクチャは、サイロ化されたビジネスユニットを結びつけ、消費者ベースで360度の洞察を得ることができます。

登壇

• Vidhya Srinivasan - GM, Redshift, Spectrum
• Balaji Muthuramalingam - Executive Director, Fox Film Entertainment

セッションレポート

このセッション

• Amazon Redshift / Redshift Spectrum
• 最近のリリースと今後のリリース
• 事例紹介：21th Century Fox Data Lake on AWS

Amazon Redshift / Redshift Spectrum

Redshiftは、AWSビッグデータソリューションの中で、分析（Analyze）に分類されるサービスです。クラウドのBDW（Big Data Warehouse）の中で最も多く採用され、5000以上の導入実績、その幾つかは10PBを超えています。Forresterの調査結果でAWSは５段階評価の「５」を６分野で獲得しています。

RedshiftというDWHは、速く、パワフル、シンプル、そしてフルマネージドサービスを1/10のコストで提供しています。

Redshift Spectrumは、S3データレイクでDWHを拡張します。 - エクサバイトの Amazon RedshiftのS3に対するSQLクエリ - Amazon RedshiftのテーブルとS3の外部テーブルを結合する - コンピューティングとストレージを分離してスケールする - 安定したクエリのパフォーマンスと無制限の同時実行性 - Parquet、ORC、Grok、Avro、およびCSVデータ形式 - スキャンしたS3のデータの量に応じて支払う

下の図のように、ツールから外部テーブル（S3.EXT_TABLE）に対してクエリを実行すると、リーダーノード〜コンピュートノード〜Spectrumレイヤの順に伝搬され、Spectrumレイヤで結果が得られると、これまでとは逆の順でクエリーの結果が返ります。Redshiftのテーブル定義はRedshift内のデータカタログで管理し、外部テーブルのテーブル定義はAWS Glueのデータカタログで管理されます。

Hiveで５年かかるエクサバイトのクエリを、Redshift Spectrumでは3分以内に結果を返す例です。速さの理由は下の図の”Optimaization”に挙げられた対策しているからです。

NUVIADでは、プロのマーケター向けにモバイルマーケティングプラットフォームを提供しており、代理店や現地企業に対してペタバイト規模のハイパーターゲット分析を使用している実績を紹介しています。

Redshiftは世界で16リージョンで利用可能です。現在、多くの大手企業での採用やパートナー企業があります。

最近のリリースと今後のリリース

New Dense Compute Node（新しいコンピュート重視ノード）- DC2

• 従来のDC1と比較して、30％優れたストレージ利用率で3倍のIO性能を実現
• 利用費は従来のDC1と変わらず２倍のパフォーマンス

Result Caching - １秒未満のクエリ応答時間

• 処理の流れ
  1. クエリはリーダーノードに送ります
  2. キャッシュにクエリ結果が含まれている場合は、処理しないでキャッシュを返します
  3. キャッシュにクエリ結果がない場合は、クエリが実行され、結果がキャッシュされます
• 特長
  • リーダーノードのインメモリーキャッシュで、1秒未満で結果を返す
  • 透過的 – キャッシュの存在を意識せずに動作します
  • WLMのスキップ、処理のスキップ、最適化のスキップ
  • キャッシュはセッション間で横断して持続する
  • キャッシュによってAmazon Redshiftクラスタが解放され、他の非反復クエリのパフォーマンスが向上します

• Result Caching によるスループットの向上
  • （ノードタイプは）高い方が良いです！ （1時間あたりのクエリ数）
  • 読み書き可能なワークロード
  • スモールクエリとラージクエリの混在、INSERT、COPY、VACUUMのRead-writeワークロード
  • ds2.xlargeクラスタ、4ノード構成

• 顧客の視点では
  • （ノードタイプは）下が良い！ （クエリ待ち時間）
  • 4ノードのdc2.8xlargeクラスタ
  • Tableauダッシュボード、10ユーザテスト ※ これは間違いではありません...キャッシングテスト実行の平均実行時間の結果は1秒未満でしたので、このスケールではy軸には表示されません。

Short Query Acceleration – ショートクエリ用の高速レーン

• ショートクエリ用の高速レーン
  • ショートクエリが長い実行クエリの後ろにつかない
  • より高いスループット、少ない変動性
  • あなたのワークロードのためにカスタマイズされた（クエリパターンを機械学習して、適切なキューに積む）
  • 透過的 – アクセラレーションの存在を意識せずに動作します

この構成では、SQA機能を​​有効にしてショートクエリのランタイムが明確に改善されています。ショートクエリの多くは5倍以上の改善を見ていましたが、実行時間の長いクエリではそれに対応した増加が見られました。これはまさしく「どのように機能が動作するか」を表しています。

• 秒未満で実行されるクエリでは、平均待機時間が36秒から0に短縮されます。
• 非常にビジーなクラスタでP90の待機時間が370秒から32.1秒に短縮

Coming soon: Nested data support

• S3上のネストされてかつ半構造化されたデータをSpectrumを使って分析する
• Amazon Redshift の CTASを用いて、ネストされたデータの簡単なETLを可能にする
• オープンな仕様のファイルフォーマットのサポート：Parquet, ORC, JSON, Ion, AVRO
• ドット表記を使用して既存のSQLを拡張する

例．「/home」のリンクのクリック頻度を検索する

s3data.clickStream: <<
{ “session_time”: “20171013 14:05:00”,
“clicks”: [ {“page”: “/home”, “referrer”: “”},
            {“page”: “/products”, “referrer”: “/home”} ]
},
{ “session_time”: “20171013 14:06:00”,
“clicks”: [ {“page”: “/contact”, “referrer”: “/home”} ]
} >>

SELECT c.page,
       COUNT(*) AS count
FROM s3data.clickStream s,
       s.clicks c
WHERE s.session_time > ‘2017-10-01 00:00:00’
  AND c.referrer = “/home”
GROUP BY c.page;

ネストされたデータを分析してクエリのパフォーマンスを向上させる

クエリのパフォーマンスを向上させるため、新しいOrdersテーブルには、OrderWithItemsがネストされた列として含まれ、結合処理が排除されます

Coming Soon: Enhanced Monitoring

クエリの待ち時間とスループットを監視してワークロードを最適化する

• クエリのスループットメトリックを使用してAmazon Redshiftクラスタを最適化してパフォーマンスを最大限に高める
• データベースとワークロードのメトリックにアクセスして、クラスタのパフォーマンスをより深く把握する
• Amazon SNS経由でアラートと通知を取得する

最後に

• DC2に切り替えることで、同じ価格で2倍のパフォーマンス向上
• Redshift Spectrumは、Amazon RedshiftクラスタをS3のすべてのデータにシームレスに、効率的に、コスト効率よく拡張します。
• クエリの監視ルールは、クエリの短縮と結果のキャッシュとともに、パフォーマンスを大幅に向上させることができます

Vidhya Srinivasan さんのパートはここで終わり、21th Century Fox Data Lake on AWSの事例紹介に移ります。

事例紹介：21th Century Fox Data Lake on AWS

21th Century Fox では、100TBのデータ、1500億レコード、25000クエリ／日、100データソース、24x7で稼働し続け、35000/日の処理をこなさなければなりません。この要件を満たすための Data Lake on AWS です。

Fox–AWS Architecture

S3上のData LakeからETL/ELT結果をSpark（EMR）やEDW/DM（Redshift）で活用する構成です。

Services

Lambdaやその他のデータソースをS3に保存、S3上のData LakeからAWS Glueを用いてETL/ELTして結果をS3に保存します。EMRやRedshiftからETL/ELT後ファイルを利用してデータ分析します。

教訓

設計上の考慮事項

ワークロード/アプリケーションを別々のクラスタに分ける - アプリケーションごとに必要に応じてスケールアップ＆ダウン

定期的にテーブルを分析する

• 'PREDICATE COLUMNS'の1回の読み込みごとに
• すべての列について毎週
• ANALYZEを起動するためにSVV_TABLE_INFO（stats_off）をクエリする

定期的なVACUUM TABLE

• 頻繁にアクセス/変更されたテーブル（STL_SCAN＆STL_DELETE）の毎日のVACUUM
• すべてのテーブルで毎週
• ディープコピーは、ソートされていない割合が高いほど高速になる

WLM

• リソースの優先順位付けと割り当てのための動的WLM設定（昼間と夜間のWLM設定）
• ETLおよびレポートツールレベルでジョブをキューイングして、Amazon Redshiftに一度に多すぎるクエリを送信しないようにします。

AWS、ProServe、APNパートナーとの密接な連携

• AWSアカウント/サポートチーム、AWS製品チーム、AWS ProServe、AWS ISVおよびSIパートナーとの緊密なパートナーシップにより、移行中に発生した問題
• AWS ProServeは、成功を促進する深い経験と専門知識をもたらしました

Amazon Redshiftへのマイグレーションのメリット

• コスト
  • 15-20%の年間コスト削減
  • 21CF スタジオのデータセンタスペースの削減
• パフォーマンス
  • 30-35%パフォーマンス向上
• ビジネスの俊敏性
  • 新規機材のプロビジョニングを合理化
  • ストレージの「壁」（上限）に対処する必要がなくなりました。
  • 新しいデータレイクを活用して、複数のビジネスユニットにわたるクラウドネイティブなAWSサービスとの相互運用性を向上させました。

感想

個人的に Vidhya Srinivasan さんのセッションは毎年参考にしています。本セッションでは、Redshiftの最新情報と今後提供予定の機能の紹介でした。新しいノードタイプDC2は、同じ価格で2倍のパフォーマンス向上だけではなく、Spectrumのユースケースを想定して設計されたものと予想しています。これまではショートクエリー・同時実行の対策として、RedshiftのフロントにRDS(PostgreSQL)でマテリアライズして、オフロードするなど検討が必要でしたが、Result Caching や Short Query Acceleration が透過的に提供されるので、これらの問題が緩和されることを期待しています。SpectrumでJSONサポートが遅れていたので心配していましたが、Nested data supportまでやるというのは嬉しい誤算です。

Redshiftのこれまでに関しては、【レポート】Amazon Redshift と Redshift Spectrumによるデータウェアハウスのベストプラクティス #reinvent #ABD304をあわせてお読みください。