このメモは私自身の思考も入り混じって記載されています。話者の内容をそのまま記述したものではありませんのであしからずご了承ください。
話者：八木橋 徹平さん
Redshiftの導入メリット
- バックアップ・運用監視への初期投資が抑えられるため導入リスクが低い
- 運用コストはかなり低下する。バックアップ・運用監視などへの心配が減る。
- 導入時点で数年先を見越す必要ない。適宜追加すればよいため、適宜サイズを調整できるためオーバーヘッドがなくなる。
- 簡単に捨てることもできる。資産として計上しないため除却を考えなくて良い。
特徴とか
- ノードスライスとはメモリとディスクをCPUコアと同数に分割した論理的な単位
- カラムナ（列指向）であり集計演算には向くものの、トランザクション処理には不向き。
- データの平準化は設計の段階で意識しよう。この辺は当然と言えば当然か。
- ロードについてはS3からコピーコマンドでいけるよ。
- 自動スナップショットがあるし、ロールバックも可能。これはデータの記述の方式によって実現。
主要アップデート
- 新しいノードタイプリリース - DS2（ストーレジが巨大（1ノード辺り2T~16T））。CPUやメモリが二倍になっているが価格は据え置き
- Redshiftのカスタムドライバが出た。postgreSQLのドライバよりも信頼性高く、最適化されている。
- Interleaved Sort Keyというものが出来て、これを用いて不用意なフルスキャンを回避できるようになった。
テーブル設計
- テーブル分散方式ね。データがどう蓄積されるかが大事。
- EVEN（ラウンドロビン）
- DISTKEY（カーディナリティの低いカラムは偏りがでるので注意）
- ALL（全ノードに全レコード。JOINの時に有利になることも）
- コロケーション（関連するレコードを同じノードにお集める概念）重要。JOIN対象となるレコードを同一ノードに集める。
- コロケーションの方法としては、ジョインに使用するカラムをDISTKEYとして作成するか、分散方式ALLでテーブルを作成
- 小規模ならALLでよい
- ジョインは避けてテーブルを非正規化し、EVENで作成
- 複数テーブルに対して、ジョイン対象のキーをDISTKEYで作成
インテグレーション
- ETL + Uploadが大きな要素だよね。
- オンプレとAWSサービス間のデータ連携が難しいところ。
- データクレジングするタイミングは、アップロードする前？後？EMRでバッチ的な。手元にHadoopあるならそれ使えばよいね。
- TalendにはAWSなどのドライバもあるのか。
- やっぱS3を起点とした設計をもっと煮詰めたい。
ETLの設計ポイント
- EMR使ったら楽だよ。そらそうだ。
- AWS-CLIは非同期だからポーリングいるよ（AWS-CLIって非同期実行だったか）。
- INESRT - SELECT文はCOPY同様に効率のよいコマンドだよ。
ケース・スタディ
すかいらーくの場合
- 数十億件規模のPOSデータ
- BIツールとしてはTableau
- これまで数十分かかっていたクエリが、ほぼリアルタイムに返ってくる
- 仮説検証サイクルが高速化
まとめ
- AWS史上において最速の成長率
- 製造・流通でも利用
- スタートアップ～一部上場まで
