いまさら聞けないRedshiftのお話し

はじめに

こんにちは、園田です。

前回に引き続き、「いまさら聞けない」シリーズを開催したいと思います。
いまさら聞けないシリーズの第8弾はRedshiftになります。

いまさら聞けないシリーズは一応サービスに詳しい人が読んでも気付きがある内容を目指して頑張っているのですが、今回のRedshiftは園田がDBに詳しくないのでもしかしたら初心者向けかもしれません。

一応頑張りますので、生暖かい目で見ていただければと思います。
なお、DBは好きなんですけど、チューニングが必要なようなシビアな業務で使ったことはありません。

使う事は出来るけど、という「初心者+（プラス）」みたいな位置づけです。

恒例のAWS資料を貼っておきます。

Redshiftってなに？

今さらシリーズ恒例のRedshiftってなに？、から始めましょう。

よく考えると、「Redshiftってなに？」という人がこの記事を見るとは思えませんが、導入としては最適ですよね。これからも続けていこうと思います。

結論から言うと、AWSがマネージドしているデータウェアハウス（以下、DWH）になります。
DWHとデータベース（DB）って違うのかな、と思って確認したら、「データを収集・統合して分析に特化する」データベースシステムと記載があったので、DBの仲間ですね。

一応AIにも聞いてみましょう。

もうこれでいいんじゃないか、と思わなくもないですね。
AIが答えているような特徴を持つ、DWHになります。

DWHってなに？

Redshiftを説明するにあたり、そもそものDWHの説明をしましょう。

DWHはデータウェアハウスの名前の通り、大量にデータを入れることが可能なデータベースです。
「データを収集・統合して分析に特化したデータベースシステム」というと分かり易いですね。ぶっちゃけ、リレーショナルDB（RDB）でも大量のデータを入れることは可能ですから。

RDBとDWH、どちらもデータを入れて、SQLで検索できるわけですが、その違いはどこにあるのでしょう。

RDBとDWHですが、最大の違いは「行指向型」なのか「列指向型」なのか。という点になります。

DWHの話をする前にRDBのことをきちんと分かっている必要があるので、RDBの特徴からお話ししましょう。
以前、「今さら聞けないRDSの話」を執筆したので、その際にRDBの特徴を書いているかな、と思ったら書いてませんでした。

という訳で、ちょっと脱線しますが、RDBの特徴です。

RDBの特徴

色々ありますが、端的にいうとトランザクション処理における4つの特性（ACID）を保持しているという事になります。

ACIDとはAtomicity、Consistency、Isolation、Durabilityの頭文字になります。それぞれはこんな感じですね。

英語でも日本語でも良く意味がわからない言葉です。
DBの世界ではトランザクションのことと指します。

具体的に言うと、園田がAさんに1万円を振り込んだとします。
その際の処理は以下の通りです。

この一連の処理をトランザクションと呼びます。
まぁ呼び方は何でも良いのですが、上記の処理をする際、1.1と1.2の間で障害が発生すると大変なことになります。

具体的には園田の1万円がどこかに消えてしまいます。大変ショックです。
（園田の口座から1万円が減ったのに、Aさんの口座に1万が増えていないので、1万円がなくなってしまった状態）

現実世界で1万円が消えてしまっては大変です。そのため、リレーショナルデータベースでは、一連の処理（トランザクション）が完了するまで、完了の状態にはなりません。

これを「Atomicity（原始性）」が保持されている状態（矛盾が発生しない状態）と定義します。

こちらは日本語の意味通りです。
「1」で口座の話をしましたが、今回も口座の話で説明したいと思います。

園田がAさんに1万円を振り込みたいと考えました。
この際の処理はさきほどと同様、

という処理となります。

ただ、園田の銀行口座には5,000円しかなかったと定義します。
その場合、お金がないのでAさんの口座に振り込むことはできません。

このように定義されたルールをきちんと守り一貫性を持たせることが「Consistency（一貫性）」となります。
（実際データとしては、「-5,000」としても問題ないが、ルールとしてはNG）

こちらも口座の話で説明します。

この1.1が完了したが、1.2が終わっていない状態で、Bさんが園田の銀行口座を確認した際にはどうなるでしょうか。
答えは「1万円が減っていない状態」です。
だって処理が終わってないのにお金が減っていたらおかしいですから。

1のAtomicityと関連しますが、トランザクションが完了していない場合、トランザクションが開始前データを見せることでAtomicityを担保します。
これによりIsolation（独立性）を確保します。

これは分かり易いですね。
システム障害が発生してもデータを守るという事です。

具体的には

という処理を行います。
データは必ず守らないといけないですからね。

以上がRDBの特徴です。色々面倒なことをしているという事が分かって貰えたかと思います。
まぁ、データを間違いなく確実に処理をさせるためにRDBというのは色々なことを頑張っているわけです。

で、Redshiftの説明をする前に「Atomicity（原始性）」をもうちょっと掘り下げたいと思います。

「Atomicity（原始性）」を確保するために、ほかの処理で矛盾が発生しないようにするため、RDBでは保護をして変更が出来ないように処理をします。
これを「ロック（lock）」と言います。

例えば、園田の口座に10万円があって、Aさんが1万円振り込むときに、同タイミングでBさんも1万振り込もうとすると正しい処理では12万になるはずが、

しちゃうと、園田の口座は11万になってしまって、矛盾が発生してしまいます。

これを防ぐため、Aさんが振込する時は、ロックをかけてBさんが更新できないようにします。

Bさんの更新が出来るようになったタイミングはすでに処理が終わっていて、11万になっているので、追加で+1万の処理をして無事12万になるという事ですね。

矛盾が発生しない様、きちんとロックをする。これがRDBの優れたところです。

で、この「ロック」処理ですが、基本テーブルの「行」に対して実施されています。
上のお話だと、口座というテーブルがあったとすると、その「園田」の口座の行がロックされている形です。

話が長くなりましたが何が言いたいかというとRDBは複数の処理をするために「行単位」で処理をします。
行単位で内容を見て、行単位でデータのアップデートを実施します。

Excelの1025行目の設定を変更する、みたいな感じです。
このように非常に（人間にとって）分かり易い処理をするのがRDBになります。

一方で、DWHは列に対して処理を行います。これがDWHの特徴です。
ちょっと人間の感覚的に理解が難しいのですが、そういうものなんです。

これを列指向といいます。

列指向ってなに？

RDBのお話しはわかって貰えたと思いますので、次はDWHの「列指向」のお話をします。
（RDBの説明も難しいですね。そもそも本1冊書ける内容を端的にするのは大変です）

DWHは「データを収集・統合して分析に特化したデータベースシステム」と定義されていましたが、ポイントは「分析」になります。

分かり易く、「どの製品が、どの年齢層に売れたかを分析する」という事を例にとってみましょう。
こんな感じのデータがあるとします。（適当に作りました）

で、こんなデータが1,000万行あるとしましょう。
ちなみに行は色々データが付加されて20列ぐらいあると思ってください。
（20列のデータが1,000万行あるという事です。）

とりあえず、分析を行うのですが、まずは製品と年代の関連性でも見たいとしましょう。
この場合、必要なのは、「製品名」と「年代」だけです。

という事は、この場合の分析においては、製品名と年代の「列」以外のデータは見る必要はありません。

にも拘わらず、RDBの場合は行指向型DBであるため、1行ずつデータを読み込むことをします。そのため、1,000万行・20列をすべて読み込んで、データを出力するという動作となり、この用途においては非常に無駄があるアーキテクチャとなってしまいます。

「いやいや、他の列は不要だから特定の列だけデータを読めばいいでしょ。」というのが列指向DBの特徴、要するにDWHになります。

というわけで、RDBとDWHは利用するシチュエーションや、アーキテクチャが全然違うというのが分かって貰えたと思います。

RDBは行に対して処理をして、DWHは列に対して処理をする。ぶっちゃけ別物です。

DWHの特徴

「特定の列だけ読めばいいでしょ。」という話をしましたが、これだと結局1,000万行を読み込む必要があります。

特定の列だけとはいえ、1,000万行を読むとなると時間が掛かってしまいます。
という訳で、DWHと基本自動的に「データ圧縮」をしてくれます。

「どの製品が、どの年齢層に売れたかを分析する」という話でしたが、年齢層は、未成年、20～29歳、30～39歳、40～49歳、50～59歳、60～69歳、70歳以上という風に分かれていたとしましょう。

この場合、たったの7種類しかありません。
1,000万行あるのにたったの7つです。

「7つしか種類が無いにも関わらず1000万行をみるって、ちょっと頭悪くない？」ということで、データを圧縮してしまいます。

具体的には「ここからここまでは20～29歳」、「ここからここまでは30～39歳」というような形でデータを管理します。
このようにデータを圧縮することで、読み込むデータ量が減り、更に速度があがります。

ちなみにRDBはこんなことできませんよ。
列指向DBであるDWHだからこそできる機能です。

なお、列指向であるがゆえに、RDBが実施できるトランザクション処理は実施できません。
行ごとにデータを読まない＝ロックが出来ない。という事なので。

Redshiftの特徴

DWHの特徴を説明したので、ようやくRedshiftの特徴になります。

Redshiftの特徴は、基本DWHそのものです。
そのため、DWHがもっている、

が特徴になります。

また、Redshiftについては2台以上のクラスタ構成となっているため（テスト用で1台構成にもできますが、拡張性&柔軟性が皆無になりますので、基本推奨しません。とりあえず触ってみたい時ぐらいですね。使うの。）、クラスタ台数を変更する、またサーバのサイズを変更するという事で、非常に高い拡張性&柔軟性を有しています。

まぁ、この辺はクラウドの特徴そのものですね。

あと、フルマネージドなので、構築はワンクリック、パッチ適用も自動実行してくれます。
また、バックアップも自動取得してくれます。もちろん手動でもバックアップ可能です。

「バックアップ取って、使わないときは削除する」という運用をされているお客様もいます。
（今だと、停止できるので、いちいち削除しなくてもいいですけど。昔は停止できませんでしたので。）

AWS Athenaとの差異について

トランザクション処理を使わないので「AWS Athena」でも良くないですかね。
ということで、AWS Athenaとの差異を見てみましょう。

「AWS Athena」はサーバレスで、S3に配置したデータに対し、SQLを実行することが出来ます。
GCPの「BigQuery」の対抗馬として、「AWS Athena」を作ったのでDWH的な利用も可能です。

「AWS Athena」はデータの読み込み量に費用が発生するだけなので、圧倒的に安価です。
また、速度もまぁまぁ早いです。

じゃ、Athenaで良くね。という話なんですが、
残念ながら、データ圧縮（自動）の機能は有していません。
（S3のデータを読み込むので、データ圧縮してくれるわけないです。）

なので、「データ圧縮（自動）」にされているRedshiftと比較すると、圧倒的にスピードが遅くなってしまいます。

とはいえ、「データ圧縮（自動）がないなら、人がやればいいじゃない」ということで、自分でデータ圧縮すれば速度が出ます。
具体的にはParquetとかORCの形式にすれば大丈夫です。

ただ、Parquetとかにしちゃうと人間が読めなくなっちゃうんですよね。
どうせ人間が見ないんだから読めなくても良いよね。とは思いますが、どうなんでしょうね。

試しに以下の政府統計のデータをParquetにしてみました。

https://www.e-stat.go.jp/stat-search/files?page=1&layout=datalist&toukei=00200521&tstat=000001011777&cycle=0&tclass1=000001094741&tclass2val=0

になりました。

もうちょっと同じような値が入っているデータだと圧縮できそうですけどね。

ちなみにAthenaのCTAS（CREATE TABLE AS）機能にて、Parquet形式に変換が可能です。
多少手間かけてよいならAthenaでも代替可能かもしれませんね。

Redshiftのライバル

いっぱいありますが、まぁこんな感じでしょうか。

SnowflakeはCTCの取扱商材ですね。
多分、CTCだとRedshiftよりSnowflakeを利用しているケースの方が多いのではないでしょうか。

Snowflakeは

という特徴があるため、Redshiftと比較して優位性があります。

とはいえ、すごく優位かというとそういう訳ではなく、Redshiftも「Redshift Spectrum」でS3のデータを持って来れたりするので、まぁ、ケースバイケースという所です。

なお、CTCではGCPの取り扱いも実施しています。
マルチベンダーでお客様の要望に合わせて色々商材を持っていける。というのはCTCのいいところだよね。という事で。

終わりに

という訳で、「いまさら聞けないRedshiftの話」でした。

今回もあんまりRedshiftの話をあまりしていないような気がしますが、気にしてはいけません。

実際Redshiftは柔軟性があるDWHですね。それ以上でも以下でもありません。

ただ、DWHって製品を購入するとなるとすごく高価なんですよね。当たり前ですが、大容量、高性能じゃないとスピードが出ないのでどうしても費用がかさんでしまいます。
なので、「DWHなんて高価なもの購入できないよ。」というお客様もいたのではないでしょうか。

クラウドではそんな高価なDWHも従量課金でとりあえず「お試し」ということが出来ます。
素晴らしい時代ですね。

今まで触りたくても触れなかった。という方はぜひRedshiftを触ってみてください。
手の届かなかった製品を触ってみるのってワクワクしますね。
そんな気持ちを持ち続けたいと思います。

ではまた、別の記事でお会いしましょう。