Developer Portal

データウェアハウスとして使う Amazon Redshift について

はじめに

こんにちは。開発本部の阪本です。

今回は私が社内勉強会(TechLunch)にて Amazon Redshift(以下 Redshift)についてお話した内容を紹介させていただきます。

Redshift とは

概要

20190701165024.png

Redshiftとは AWS サービスが提供しているデータウェアハウスで、高可用/高パフォーマンス/柔軟なスケーラビリティを実現しているのが特徴です。

競合としてはBigQueryやHadoop、また同じ AWS サービスではAmazon Athenaも同様の位置付けになると思います。

データベースとしての特徴

Redshift の特徴として、列志向型データベースという点があります。

MySQL のようなリレーショナルデータベースはデータを行（レコード）単位で保持している事に対し、Redshift は列単位で保持しています。

20190701165052.png

列単位でデータを持っているため集計クエリのような特定の列に対して大量の行を精査するのが高速である反面、行を特定してのアクセスは MySQL や PostgreSQL のような行志向のデータベースに比べてのクエリに比べて遅い傾向にあります。

またデータには SQL でアクセスすることができ、構文も PostgreSQL と互換性があります。 最近スキーマレスなデータベースなどが多く出てきていますが、Redshift は事前にテーブルを作成する必要のある従来型の RDBMS の形となっており、テーブル作成時はCREATE TABLEといったデータ定義言語(DDL)を使うことになります。

機能面の特徴

20190701165113.png

先にも書きましたが、データアクセス時に使う SQL はPostgreSQLの構文と互換性があります。

よって PostgreSQL 用ドライバ(JDBC 含む)さえ使えれば、後は特別に意識することなく Redshift に対して接続やクエリ発行が行えるということになります。

この恩恵はプログラムだけではなく他社が展開しているサービスにも受けることができ、BI ツールのTableauやRedashなどもそのままデータソースとして利用することが出来ます。

次に、一般的な RDBMS との差についてです。 RDBMS にはあり Redshift には無いものとしては

  • UNIQUE 制約
  • 外部キー制約
  • インデックスが無い

などがあります。

インデックスに関しては遠い意味での代用品(Sort Key)があるものの、基本的には使うことが出来ません。 注意点としてクエリ自体は PostgreSQL 互換なのでこれらを作る DDL 構文を受け入れてくれるますが、Redshift では無視されますのでご注意ください。

逆に、Redshift 固有のものとしては

  • Sort Key
  • 分散キー
  • 列圧縮

などがあります。 これらについては以下で少し掘り下げて説明します。

Sort Key

テーブルをソートする際に使うインデックスのようなものです。 列単位で指定することができ、ORDER BYやGROUP BY句などの精査速度に影響します。

分散キー

MySQL でいうパーティショニングキーに近いものとなります。

Redshift のデータ分散方法は

  • 均等に分散
  • キー値による分散
  • 全コピー
  • Auto（負荷状況による自動選択)

の 4 つで、データ量や特性によって使い分けることが出来ます。

分散キーは Redshift を上記の方法でクラスタリングした際に、どのノードにどのデータを保持するかを決定する判断材料となるキーです。

運用面の特徴

AWS コンソール

20190701165138.png

Redshift は AWS コンソール上からも詳細な情報を確認することが出来ます。

20190701165201.png

Amazon RDSにあるような一般的なメトリクスに加えてクエリ単位での実行状況や実行計画、そしてクエリの強制停止もコンソールから実行することができます。

データ取り込み

Redshift はインポート元となるデータ取り込み選択肢が豊富ということも特徴の一つです。

取り込み可能な形式

CSV/JSON/AVRO/PARQUET/ORC + これらの形式を圧縮したもの(BZIP,GZIP など)

読み取り元

Amazon S3/Amazon EMR/Amazon DynamoDBなど

特にデータ配置元として S3 がサポートされているので、各種サービスが出力するログや、Amazon CloudWatch Logsからの S3 やAmazon Kinesis Data Firehoseからの S3 ・・など、組み合わせ次第で可能性がとても広がります。

また S3 に配置しているデータはインポートせずに外部テーブルとして直接クエリを実行する機能 Amazon Redshift Spectrum があります。データ量がとても多い場合などにはこちらを利用するのも有効な手段です。

ワークロード管理

20190701165215.png

負荷に関する運用については WLM(Work Load Management)という機能があります。

これは Redshift に接続するユーザをグループ単位で負荷制御を行うことが出来る機能です。

制御できる項目としては

並列クエリ実行数

同一グループ内でのクエリ同時実行数。上限に達すると待ち行列に入って詰まる。

クエリ実行時間

クエリ実行時間の上限。

メモリ使用量

クエリ実行時に使うメモリ使用量の上限。

などがあります。

可用性について

Redshift はクラスタリングをサポートしており、クラスタにはクエリの待受を行うリーダー(Leader)ノードと実処理を行うコンピューティングノードが作成されます。

AWS も推奨しているように、Redshift はマルチノード運用を基本としています。

これは Redshift の個々のデータノードは RAID5 のような形で各ノードに分散しているため、ノード障害が発生した場合でも生存ノードからノード復旧を自動で行ってくれます。 （同時に障害が発生しても復旧可能なノード数については、クラスタ内のノード数に依存します）

将来性について

過去１年半の間でもこれだけの新機能が追加されており、まだまだ進化しています。

  • UNLOADコマンドの CSV 対応
  • Concurrency Scaling
  • ALTER文でVARCHARの桁数変更
  • Elastic Resize
  • UNLOADコマンドのヘッダ行出力対応
  • コンソールにてクエリ実行環境追加
  • ネスト化されたデータのサポート
  • 自動バージョンアップ方式の設定／予告確認可能
  • Parquet、ORC からの IMPORT サポート
  • Amazon Redshift Spectrum 東京サポート
  • 新ノードタイプ DC2
  • Query Editor の追加
  • PL/SQL プロシージャのサポート
  • Vacumコマンドの自動化 New!!(2018/12 リリース)
  • WLM ワークロード管理の自動化 New!!(2019/06 リリース)

実際の使い勝手

では、実際のところ Redshift の使い勝手がどういったものなのかを実例を含めて紹介します。 ここでは dc2.large ノード数 2 のサンプル環境を使用します。

データのロード

クエリを発行するにも、まずは元になるデータが必要です。

ここでは日本語 Wikipedia の目次ダンプデータを 100 セット分用意し、その内容を Redshift にロードしてみます。

20190701165252.png 20190701165257.png

まずは目次データをこちらの画像の様に加工し、100 セット分のファイルとして分割し S3 へとアップロードします。

20190701165317.png

今回のロードするデータ量は235,732,000 レコードの 11.9GBとなりました。

20190701165331.png

S3 にファイルが配置出来たら、それを格納するテーブルを Redshift に作ります。 この際 PostgreSQL のCREATE TABLEによってテーブルを作成します。

20190701165355.png

テーブルの作成が完了したら、次はデータのロードです。 これも SQL クエリのCOPYコマンドによって取り込みが行われます。 今回このロード処理は8 分 55 秒で完了しました。

データ量から考えるとかなり早いと感じますが、これはロード処理において並列処理の恩恵を最大限に受けているということが理由と考えられます。

Redshift のロード処理は分割されたファイルを使って並列処理を実行するため、巨大な単一ファイルを取り込むより短時間で取り込むことができます。

クエリ発行

次に、クエリ発行についてですが、これはそのまま PostgreSQL のクエリを実行することになります。

今回は先のステップで取り込んだ目次ページをタイトルごとにDISTINCTする集計クエリを発行してみます。

20190701165409.png

すると49 秒で結果が帰ってきました。 最低限のスペックで 235,732,000 レコードを精査するクエリの実行時間としては良いスコアではないでしょうか。

不便に感じたこと

ここでは私が Redshift を運用していて不便に感じた事をいくつか紹介します。

料金が高い

これだけの機能とスペックが含まれているので仕方が無いかもしれませんが、AWS の他のサービスと比較して高価な印象があります。

さらにマルチノードとなると料金が掛け算で増えることになり、スペックの選択肢が他のサービスと比べても少ないため運用の際にはよく見積もりされることをおすすめします。

更新クエリが遅い

列志向型のせいなのかランダムアクセスが苦手で、特定の行を探して更新するUPDATEやDELETEは遅いです。

そもそも Redshift は頻繁にUPDATE/DELETEする用途には向いておらず（後述）、INSERTのみの積み上げ型や全レコード洗い替えが基本の用途になります。

また、UPDATE/DELETEを繰り返すとパフォーマンスが低下します。

これは内部的に保持している SortKey の状態が更新するたびに劣化し、連動してパフォーマンスが低下するためです。

解消するためには SortKey の再構築（VACUM/OPTIMIZEコマンド)により回復しますが、そもそもコマンド実行時間が長く、負荷も大きいので実行タイミングは検討が必要となります。

(追記)2018/12 のアップデートで自動実行機能が追加されました！

AWS コンソールが機能しないことがある

先に多くの便利な機能を紹介しましたが、なぜかこれらが AWS コンソール上で機能してくれないことが割とあります。

WLM の設定次第なのか不明ですが、実行中のクエリが出なかったりクエリの強制停止が効かないなど、イザという時に限って使えないことがよくありました。

メンテナンスが高頻度

新機能が続々追加されていると紹介していますが、この度にメンテナンスが発生するものとなります。

タイミングは事前に設定したメンテナンスウインドウの週一の曜日/時間帯ですが、経験から 2 週間に 1 度ぐらいの頻度で発生していました。

この時間帯は再起動を伴う場合もあるため、Write どころか Read すら出来ない状態になることもあります。

そのため日中は社内業務。夜間はバッチでといった２４時間ずっと稼働する要件を満たす事は少し厳しいものとなります。

まとめ

まとめととなりますが、Redshift は特徴をふまえると下記のような場面で利用すれば良いかなと感じています。

BI ツール等のデータソースとして

メンテ頻度や負荷の問題があるので、自分達のアプリから直接は繋げない。

履歴やマスタデータのような大量の積み上げ型データの集計

UPDATEが発生するなら、全件入れ替えが可能なデータ。

１日の利用頻度がそれなりにあること

頻度が高く無いのであれば、Athena の方が安い。

どのサービスにも言えることですが、要件の合ったサービス選びをすることが一番大事です。

Redshift についても特徴がはっきりしているタイプのサービスなので、使い所を間違えないように、上手く使っていければと思います。

前の記事 次の記事