【セッションレポート】Amazon Redshift によるデータ分析基盤の設計・チューニング #cmdevio2015 #cmdevio2015G

2015.03.31

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

2015年3月29日に開催された Developers.IO 2015 にて、『Amazon Redshift によるデータ分析基盤の設計・チューニング』というタイトルで、ビックデータ解析基盤をAWSで構築する際に注意すべき設計やチューニングポイントについて発表しました。

最初に

弊社が提供する「カスタマストーリー」で提供するビックデータ解析基盤の構築・運用サービスで培った経験をベースにお話しました。 ご提供いただいたSAPジャパン様のオフィスはとても素敵で、スピーカーとしてテンションが上がってきました。

発表資料

発表資料は以下となります。

はじめに

Amazon Redshiftのこれまでの経緯と、難しい・複雑であるといった誤解について、本当はシンプルであるがゆえにスケーラブルでオープンであることを解説しました。

Redshiftのアーキテクチャ

クラスタを構成する要素としてリーダノードと複数のコンピュートノードが存在し、コンピュートノード内のスライスが並列実行することによって線形スケールが実現されていることを解説しました。

RDS/RDBとの相違点

様々なRDS/RDBとの相違点について例を上げ解説しました。私はRDB/RDSとの違いを知ることがRedshiftを知る近道であると考えています。そして、その違いの理由は線形スケールを実現するためのアーキテクチャー「シェアード・ナッシング」であることを理解して頂けたと思います。

データ解析基盤の設計

分析対象のデータ形式を分析する手法として「R言語」の活用から、Redshiftならではのキーやパラメタの選定方法に至るまで解説しています。

パフォーマンスチューニング

データ解析基盤導入後に利用目的や範囲が広がることは大変喜ばしいことですが、より大規模なデータやリソースを効果的に利用するため必要となるチューニングについて解説しました。並列実行やワークロードマネジメント、クエリプランの確認・チューニングに至るまでを紹介しました。

トラブルシューティング

よくある問題の紹介と解決方法をご紹介しました。

まとめ

・まずはRDB/RDSとの違いを知ることが近道 ・適切な分散キーの選定は最優先 ・同時実行や粒度の小さいクエリーは向きません

最後に

当日は雨の中お越しくださいまして誠にありがとうございました。セッションの後もご質問を頂いたり、ご挨拶をさせていただきましたこと感謝しております。また別の機会に皆様にお会いできることを楽しみにしております。