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

この記事は 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。

レポート

Amazon Data Warehouse Overview

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

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

Web Logs on Amazon Redshift Project

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

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

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

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

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

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

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

Petabyte Cluster Design

ここからはSamor。

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

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

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

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

まとめ

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