[セッションレポート]Delivering Results with Amazon Redshift, One Petabyte at a Time #reinvent

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

この記事は AWS re:Invent 2014、BDT309-JT - Delivering Results with Amazon Redshift, One Petabyte at a Time - Japanese Trackのレポートです。

スピーカーはAmazonのData WarehouseチームのMr.Erik SelbergとMr.Samar Sodhi。

レポート

DSC_0031

Amazon Data Warehouse Overview

DSC_0032

Amazon Data Warehouseとは、エンタープライズであるAmazon自体が使っているDWH。ペタバイト級。
もともとはOracleを使っていた、その後EMR、現在はRedshiftを使っている。

DSC_0034

Amazon Data WarehouseはAWSのチームではなくコンシューマ向けのチームであり、チームのミッションは、最適な価値をお客様に伝えること。そしてベストプラクティスを公表していくこと。もしAWSがベストでなければそれを伝える。これは証言。

DSC_0035

Web Logs on Amazon Redshift Project

Web Logsの管理。Amazonにとっても重要。
Amazonで重要なのはWeblogとバックエンドのデータ(配送や発送まで)を統合していくこと。
Amazonの成長ペースに合わせていかなくてはならない。

DSC_0036

課題。2年分のWeblogを1時間以内でクエリ結果が出ること。サイクルタイムは1分。
いつも一定の問い合わせ時間で結果が返ってくること。
鮮度の高いデータが使えること。朝4時までに昨日のデータが入手できること。

DSC_0037

ゴール。5B rowを1時間以内に対応。
データのリテンション。古いデータを削除するときに影響がないこと。
ゼロインパクトメンテナンス。24時間ずーっと稼働できること。

DSC_0038

Oracle RAC...データが多いとクエリが遅くなる。
EMR...Oracleよりはいいがクエリに数日かかってしまう

DSC_0039

現在は101ノードのRedshiftクラスタを構成している。非常に効果的なソリューション。

DSC_0040

ベストプラクティス、3つのクラスタのうち2つは本番、1つは災害対策用のスタンバイで常に同期をしている。またRedshiftではprodとtest&devを分けて作っておく必要がある。

パフォーマンス。バックフィルの懸念は問題なかった。150billion rowsについても結果が出てる。

DSC_0041

Petabyte Cluster Design

ここからはSamor。

DSC_0042

デザインとして一番難しかったもの。400TBのテーブル。今後も増えている。
Redshiftにしたときのチャレンジ。データを削除するのが難しい。論理削除しかされない。
データを属性に合わせてそーとしたい場合VACCUMを使うが、CPUを非常に使うので遅い
パーティションを使って回避。
クエリは15個しか並列で動かない。悪いクエリはクラスタに負荷をかけてしまう。

DSC_0043

私たちが取った対応。ストアデータを月ごとのテーブルにすること。
マイナス面。predicate pushが常に起きるわけではない。
テーブルを全てデイリーで扱うことはできない。テーブルのリミットが9990だから。
メンテナンスのオーバーヘッドが大きい。

DSC_0045

アーキテクチャとしてのベストプラクティス。
S3ファイルからのCOPYは、ファイルサイズによって負荷を軽減することができる。
セッションIDを使ってディストリビューションした。

DSC_0046

DSC_0048

DSC_0049 DSC_0047

redshiftのパフォーマンス。素晴らしい実績が出ている。

DSC_0054

まとめ

AmazonでRedshiftをどのように使っているか?という点で非常に興味深いセッションでした。