株式会社メドレーのブログ

2019/07/01

<![CDATA[ データウェアハウスとして使う Amazon Redshift について ]]>

はじめにこんにちは。開発本部の阪本です。今回は私が社内勉強会(TechLunch)にて Amazon Redshift(以下 Redshift)についてお話した内容を紹介させていただきます。 Redshift とは概要 Redshift とは AWS サービスが提供しているデータウェアハウスで、高可用/高パフォーマンス/柔軟なスケーラビリティを実現しているのが特徴です。競合としては BigQuery や Hadoop 、また同じ AWS サービスでは Amazon Athena も同様の位置付けになると思います。データベースとしての特徴 Redshift の特徴として、列志向型データベースという点があります。 MySQL のようなリレーショナルデータベースはデータを行（レコード）単位で保持している事に対し、Redshift は列単位で保持しています。列単位でデータを持っているため集計クエリのような特定の列に対して大量の行を精査するのが高速である反面、行を特定してのアクセスは MySQL や PostgreSQL のような行志向のデータベースに比べてのクエリに比べて遅い傾向にあります。またデータには SQL でアクセスすることができ、構文も PostgreSQL と互換性があります。最近スキーマレスなデータベースなどが多く出てきていますが、Redshift は事前にテーブルを作成する必要のある従来型の RDBMS の形となっており、テーブル作成時は CREATE TABLE といったデータ定義言語(DDL)を使うことになります。機能面の特徴先にも書きましたが、データアクセス時に使う 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 コンソール Redshift は AWS コンソール上からも詳細な情報を確認することが出来ます。 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 があります。データ量がとても多い場合などにはこちらを利用するのも有効な手段です。ワークロード管理負荷に関する運用については 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 にロードしてみます。まずは目次データをこちらの画像の様に加工し、100 セット分のファイルとして分割し S3 へとアップロードします。今回のロードするデータ量は 235,732,000 レコードの 11.9GB となりました。 S3 にファイルが配置出来たら、それを格納するテーブルを Redshift に作ります。この際 PostgreSQL の CREATE TABLE によってテーブルを作成します。テーブルの作成が完了したら、次はデータのロードです。これも SQL クエリの COPY コマンドによって取り込みが行われます。今回このロード処理は 8 分 55 秒で完了しました。データ量から考えるとかなり早いと感じますが、これはロード処理において並列処理の恩恵を最大限に受けているということが理由と考えられます。 Redshift のロード処理は分割されたファイルを使って並列処理を実行するため、巨大な単一ファイルを取り込むより短時間で取り込むことができます。クエリ発行次に、クエリ発行についてですが、これはそのまま PostgreSQL のクエリを実行することになります。今回は先のステップで取り込んだ目次ページをタイトルごとに DISTINCT する集計クエリを発行してみます。すると 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 についても特徴がはっきりしているタイプのサービスなので、使い所を間違えないように、上手く使っていければと思います。

株式会社メドレー の技術ブログ

コンテンツ

株式会社メドレーの技術ブログ