『Amazon Redshift』での本格データ分析～ここまで来た、クラウド型DWH～セミナーに参加しました。

2015年3月21日から hiruta

Amazon の松本様からRedshiftについての話

Redshiftは2PBまで使用できる。（これ以上使いたい場合は、相談に応じるとのこと)
Redshiftは縦指向。RDSとは異なる。集計に最適
S3からRedshiftにロードさせるのが基本的な使い方
- Lambdaを使うことでイベントトリブンでロードする方法も可能だが、S3にcsvなりデータ取り組むとで、データがRedshiftにロードできてしまうので、変なデータが置かれてもデータがロードされてしまうことが起こりうるので、気をつけないといけない。Lambdaのスケジュールトリブン（スケジュールによるイベント発火）が望まれる。

ウルシステムズ　吉田悦万様からデータ分析システム導入のポイントについて

ウルシステムズが提供している、オールインワン型のクラウドDWH Whte-eYeの紹介から

お客様ごとに要件を合わせて提供

　必要なAMIを組み合わせて短期間で構築

事例として、ショッパーインサイトの「 POSデータの分析システム」で移行前だと以下問題を抱えていたのをクラウドに移行することでどう解決したかの話

　フラストレーションが溜まっていた。

次に、分析システムを導入する場合のポイントについての話

→投資対効果が見えにくい。

→スモールスタートする企画

→システムのライフサイクルを踏まえたコスト比較

→クラウドのコストメリット　3,4,5年を見据えて。オンプレだとインフラのマイグレーションとの比較も含めてコスト比較のがいい

BIG DATA LANDSCAPE (→ここ）

→BIG-Dataはコンポーネント（部品）が多岐に渡っている

ある程度は、チューニングをしなくても出ますが、データ量が多くなるとチューニングは必要になる

チューニングすることで、処理も速くなり、リソースの使用時間も減る。つまりは利用料にも跳ね返ってくる

Sortkey カーディナリティの低いものに有効

ディスクの利用率などて適切な圧縮エンコーディングで

Distkeyは、データを投入してから検証

分散されているか指標があるので、データ投入後に確認する

共通部品を作って開発をするのがポイント

定期的にVACUUM使わないと

多量のデータ扱っているとそんなにVACUUM時間がかかるのでそんなに実行できないSELECTのサブクエリー

メモリに展開できない場合、ディスクフルのエラーが発生する

十分容量を確保した設計が重要

ロングランテスト。ディスク容量のグラフ化

列数が多いテーブルでVACUUMを実行するとエラーになる可能性がある

ERROR 1036 DETAIL: Vacuum clumn limit exceded

→VACUUMの間だけ、wlm_query_slot_count の値を上げる

本番機のパラメータを変えたくないので、DEEP COPY でこれで解決しているとのこと

クラウドインフラ構築記