この記事は公開されてから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。
レポート
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をどのように使っているか？という点で非常に興味深いセッションでした。
14
