AWS再入門 Amazon Redshift編

Amazon Redshift

はじめに

当エントリはDevelopers.IOで弊社AWSチームによる2015年アドベントカレンダー 『AWS サービス別 再入門アドベントカレンダー 2015』の4日目のエントリです。 昨日3日目のエントリは清水の『Amazon CloudFront 』でした。

このアドベントカレンダーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

本日4日目のテーマは『Amazon Redshift』です。

目次

　

サービスの基本的な説明

Amazon Redshiftとは、一体どんなサービスなのでしょうか？ここではポイントをかいつまんでご紹介して行きたいと思います。

　

高速且つフルマネージドなデータウェアハウス(DWH:Data Ware House)サービス

Amazon Redshiftはざっくり言うと『高速で完全マネージド型、ペタバイト規模のデータウェアハウス』です。(※AWSサービス公式ページから拝借) では『データウェアハウス』とは一体何でしょうか？

Wikipediaでその意味を調べてみると、

データウェアハウスとは、直訳すれば「データの倉庫」である。利用者により定義範囲は異なるが、一般に時系列に整理された大量の統合業務データ、もしくはその管理システムを指す。

とあります。ある用途で集められたデータ、しかも莫大・膨大なデータを取り込めて管理出来るシステム、という事ですね。Amazon Redshiftではそれらの管理を『フルマネージド』で行ってくれるという訳です。

この『データウェアハウス』であるAmazon Redshiftに対して、利用者としては何を行えば良いのでしょうか？データベースとは違って何やら違う代物っぽいし、色々専門的な作業をしなければならないのではないか...と思われるかも知れないですが、実際のところはそこまでデータベースに対して行なう作業と変わりません。AWSアカウントにサインインした後は、以下の様な手順で環境を作成し、データを参照・分析用に扱える様に準備しておきます。データが既に分析用に加工されていれば、投入即分析・参照可能ですが、状況に拠っては所定の内容では項目(カラム)が足りない、情報(テーブルやビュー)が足りない等もありえますので、その部分についてはユーザーが事前にETL処理等で加工を済ませておく必要があります。

  • 1.クラスタの作成
  • 2.クラスタ内にスキーマを作成
  • 3.スキーマ内にテーブルを作成
  • 4.(必要に応じて、投入するデータを投入可能な形に加工しておく:ETL)
  • 5.テーブルに対してデータを投入
  • 6.(必要に応じて、BIツール等でアクセスし易い形にSQLを使ってサマリテーブルを作成しておく:ELT)
  • 7.BIツール等でAmazon Redshiftにアクセスする

なお、ETL処理とは『Extract/Transform/Load』の頭文字を取ったもので、データを任意の目的の為に加工しておく処理の事をこう呼んだりします。データベースにロードする前にファイルベースで変換を掛けておこう、という時に使います。似たような言葉でELT(Extract/Loda/Transform)というものもありますが、こちらはデータベースにロードしてから変換を掛けよう、というものです。(幾つか見解があるようですが、基準がシンプルなので個人的にはこの区分けを使っています)

参考までに、Amazon Redshiftを取り巻く分析・ETL周りのアーキテクチャ例を示した画像を以下に展開します。

dwh-flow

上記キャプチャ画像真ん中下側、青いエリアの部分がAmazon Redshiftのシステム範囲となります。Redshiftに取り込まれたデータを以って、上記で解説した作業を行っていく過程で様々なリソースの管理が必要となりますが、この部分の管理をAWS側で『フルマネージド』してくれる訳です。(※以下は公式サイト内言及箇所の抜粋です)

Amazon Redshift は、クラスターの状態のモニタリングやバックアップの取得、パッチの適用、アップグレードにいたるまで、データウェアハウスの管理、モニタリング、スケーリングに必要なすべての作業を制御します。パフォーマンスや容量に対するニーズの変化に合わせ、クラスターのサイズを簡単に変更できます。こうした多大な時間と労力を要する作業を自動化することで、お客様はデータの解析とビジネスに専念できます。

Amazon Redshiftの公式ページにYouTube動画が展開されていますので、併せて載せておきます。

　

PostgreSQLに準拠したデータベース

Amazon Redshiftは、PostgreSQL8.0.2に準拠した環境・技術仕様となっています。ですので、PostgreSQLをこれまでに扱っていた場合であれば特に意識せず扱える事が出来ますし、そうでない場合でもPostgreSQLの情報を参考にRedshiftの学習や実践を行なう事が出来ます。

準拠はしていますが、完全にPostgreSQLとRedshiftが同じ仕組みや仕様で動いているという訳ではありません。参考にしつつも、使われ方や構文等をAWS及びRedshiftの環境に即した形に適応させています。この辺りの詳細については、公式の以下ページを参考にしてください。

Amazon Redshiftで諸々の作業を行なう際には、CUIであればPostgreSQLのpsqlコマンドがそのまま活用出来ます。

またGUIの場合も同様にPostgreSQLに対応しているツールであれば使えるものが存在します。Redshiftで対応しているツールに関するブログエントリを以下にまとめましたので、実作業をされる際は是非ご参考にして頂ければと思います。

　

カラムナ型のテーブル構造

Amazon Redshiftでは、データの格納方式に『カラムナ型』というものを採用しています。これは従来のRDBMSでは『行指向型』では行を単位にデータを格納しているため、任意の列(カラム)を取得するのには行を取得しないと行けなく、大規模データを前にするとパフォーマンスの面で厳しい面がありました。カラムナ型の場合、行では無く列(カラム)を単位にしてデータの管理を行っているため、参照時に任意の列を指定する事でその列の値だけを取得しに行けるようになり、結果として同じ件数、同じ列の値を取得した際に高速なレスポンスが期待出来ます。

redshift_slides_01

　

チューニングのポイントは『分散キー』『ソートキー』『列圧縮タイプ』

Amazon Redshiftでデータウェアハウス環境を構築していく上でのチューニングポイントとなるのは大きく3つあります。

分散キー

Amazon Redshiftでは、ノードと呼ばれるコンピューティングリソースの集合で構成され『クラスタ』と呼ばれています。データへのアクセスがAmazon Redshiftクラスタに届くと、クラスタのリーダーノードが処理を受け付け、配下のコンピューティングノードへと処理を分散して指示します。

データの配備についてもノード毎に分散して格納するスタイルを取っています。ノード毎に分散配置されたデータを見に行き、状況に応じて結合させたりした結果を再度集約して返す、という作業を内部で行っていますので、なるべく『ノード間のデータ移動をさせない』設定を施す事がポイントとなります。

分散キーの指定方法は『EVEN(均等分散)』『KEY(任意のキーによる分散)』『ALL(データ全体のコピーを分散)』の3つが指定可能です。それぞれ用途に応じたテーブルの構造や関連、または結合の方法に適した分散キーの指定をテーブル作成時に行なう事がポイントとなります。テーブル1つに対して指定可能な分散キーの数は1つです。

ソートキー

従来のRDBMS同様に、Amazon Redshiftにもソートキーは存在します。ソートを活用する事で範囲が制限された述語を効率的に処理することが出来るので。分散キー同様にテーブルデータに及び活用方法に適したソートキーの指定を行なう事が重要です。ソートキーはテーブル1つに対して複数個指定が可能となっています。

ソートキーの指定は、従来のものの他に最近ではInterleaved Sortingというソート方法を指定する事も可能です。

列圧縮タイプ

列圧縮タイプの選択を行なうと、指定の列を選択した形式で圧縮して管理します。圧縮指定を行なう事でデータ自体の容量も削減する事が出来、結果としてネットワークI/Oも改善します。

データ型毎に可能な列圧縮タイプの一覧まとめは以下にブログ化しています。結構頻繁に参照してたりします。

投入するデータ件数が一定件数あるのならば、以下の様な手法で最適な列圧縮タイプを見つけ出す事も可能です。

また、ツールとして診断から定義の変更までを行ってくれるツール等もあったりします。

　

Redshiftクラスタ全体の管理機能

Redshiftのテーブル単位に於けるパフォーマンスチューニングについては上記でご紹介した様なポイントがありますが、クラスタ全体を管理する情報についても幾つか調整が可能な項目が存在します。

パラメータグループ

検索パスやSSLの設定等の制御を、パラメータ値を書き換える事で変更が可能です。

WLM(ワークロード管理)

また、管理側のパラメータ調整機能としてWLM(ワークロード管理)というのものが存在します。Redshiftクラスタ全体でユーザや実行クエリのグループに応じて、同時実行人数やリソースの割り当てを制御出来る仕組みとなっています。管理者ユーザーは専用のキューを用意させて優先的にSQL実行を行わせたい、そもそもの同時実行数の上限を上げたい、などといったケースでこちらの設定値を変更する事もあるでしょう。

小さく始めて大きく育てて行く事が出来る環境

オンプレ環境であれば任意のストレージ容量を事前に検討し、物理サーバを購入しておく必要がありました。当然ながら物理サーバのストレージ容量拡張も非常に困難なものになるかと思います。

Redshiftではこの点上手く出来ており、いつでもクラスタのタイプやストレージ容量の上限を変更する事が可能になっています。プロジェクト開始時点ではデータ総量が数GB〜数十GB、多くても数百GBしかないという場合であれば一番小さなクラスタタイプで、必要最小限のノード数で始め、以後のデータ増分のペースを考慮して適宜クラスタのリサイズ処理を行い、データの最大許容量を調整する事が出来ます。即ち『小さく始めて大きく育てる』事が可能となっているのです。リサイズ処理自体も至って簡単です。リサイズしたいクラスタのタイプとノード数を指定して変更させるだけで処理が完了します。

　

サービス利用のユースケース

Amazon Redshiftは冒頭解説文に記載があるように『データウェアハウス』としての用途で使うためにリリースされたサービスです。

Amazon Redshiftを活用する上でまず無くてはならないサービスはAmazon S3となります。Redshiftにデータを取り込む際に入力データとなるファイルを配備しておく場所の1つとしてAmazon S3が指定する事が出来、またS3自体様々なサービスの入力ファイル・出力ファイルのデータ格納先として連携が可能となっています。

Amazon S3へ格納されたデータのRedshiftへの取り込み処理や、Redshiftへ取り込みが済んだ後でSQLを使ってRedshift内のデータベースを操作してBIツール等で扱い易い形に整形しておく処理、またRedshiftに取り込む前に事前にファイルベースで整形をしておきたいという場合、任意のタイミングでバッチ処理を行い、また本番運用を想定する場合であればそれらの処理を自動化しておく必要があるかと思います。そうなった時には一番手っ取り早いのはバッチ処理のサーバとしてEC2環境を用意し、そこでcron起動で処理を実施させる方法になるかと思います。cron管理が面倒という場合であればRundeckの様なオープンソースのジョブ管理サーバを用意するでも良いですし、AWS謹製のジョブ管理サービスであるAWS Data Pipelineを活用するといった選択肢もあります。

Redshiftに集約するデータとしては様々な種類が検討されるかと思います。この辺り、Redshiftを含めたビッグデータのソリューションをどのように活用すれば良いのか、というところについては以下のセッションレポートなどが参考になるかと思います。

以下のスライドでは、Amazon Redshiftを活用すべきケースとオススメしないケースについても言及されています。Redshiftを最大限有効活用出来る形で使い倒したいところですね！

redshift_slides_02 redshift_slides_03

　

あわせて読みたい

上記までの解説で各種エントリをリンクでご紹介して来ましたが、上記で紹介したもの以外でオススメの情報をこちらで幾つか紹介したいと思います。

こちらは弊社ブログ内の『Amazon Redshift』に関するエントリの一覧です。Redshiftに関するものだけでも現在150本超！様々なエンジニアがRedshiftに関するエントリを適宜投稿していますので、こちらは是非チェックしておく事をオススメします！

その他オススメの情報は以下の通りです。

　

さいごに

以上、『AWS サービス別 再入門アドベントカレンダー 2015』の4日目のエントリ『Amazon Redshift編』でした。 Amazon Redshiftは使いはじめるのにハードルがあるんじゃないか、大変なんじゃないかと思われるかもしれませんが、実はそんなに難しくは無いと思います。エントリ内でも言及していましたが、『小さく始めて大きく育てていく』事が出来るのがAWSでありRedshiftの特徴です。お手持ちのデータを使って可視化や分析を始めてみたいけど...という方いらっしゃいましたら、こちらのエントリを読んでその第1歩を踏み出していって頂けますと幸いです。

明日12/05(土)は吉田のKMS(Key Management Service)です。お楽しみに！