Amazon Redshift のような広く使われているデータウェアハウスを理解するには、まずはその基礎となるアーキテクチャと、その上に構築されているコアとなる原理を理解する必要があり、その基礎となるアーキテクチャは『超並列処理（Massively Parallel Processing、略してMPP）』です。そこで本記事では、MPPデータベースとは何か、その機能や、長所および短所について掘り下げていきます。ご質問があれば、コメントでぜひお知らせください！

ストレージとコンピューティング・パワーはここ数十年で大きく進歩しましたが、残念なことに、現代のデータ・ストレージと分析のニーズには追いついていないという現実があります。そこで MPP データベースが、必要な処理能力を複数の異なるノードに割り当てることで、この問題を解決して大規模なデータセットを最も効率的に分析してくれます。

ビッグデータ分析： 人間に例えてみる

垂直方向ではなく水平方向に拡大縮小する

MPP アーキテクチャが大規模データセットの処理をどのように効率化するかを見るために、コンピュータの世界から少し離れて、サーバーの代わりに人間を使って同じような問題を解決する方法に例えてみましょう。

あなたが研究者で、生涯の夢が「国会図書館にある単語の総数を数えること」だとします。ワシントンD.C.で直接登録し（驚くことに必要なのはこれだけです）、入館を許可されたあなたは、棚から目についた最初の本を手に取り、数え始めます。

この例では、１つのサーバーが［国会図書館］というデータを通過し、［単語の総数］であるクエリを処理することを表しています： ウィキペディアによると、国会図書館には１億６７００万以上のユニークな項目があるので、通常の読書速度では、テキストをすべて読み通すのには何万年もかかるでしょう。

このことに気付いたあなたは、読書速度を上げようとします（縦方向に拡大する）。速読教室にお金を注ぎ込んで、本を開いたりページをめくったりするスピードを上げるための高価な道具を買うことによって、１分間に数えられる単語数を２倍に増やすことはできますが、この増加率でも、タスク完了まで数千年もかかることは明らかです。

では、処理能力を上げるために投資する代わりに、国会図書館が雇用している３,０００人に助けを求めたらどうでしょう？単語を数えるスピードはそれほど速くできませんが、人を増やすことで水平方向に拡張する能力はほぼ無限です。そして司書長は、このプロジェクトが税金の有効活用につながると判断し、全従業員をこの仕事に専念させ、あなたをそのまとめ役に任命します。

この状況について少し考えてみましょう： どうするのが一番都合がいいでしょうか？サッと効率よく正確に結果を出すために、あなたならその従業員をどのようにまとめますか？

一番簡単なのは、各人に図書館のほぼ均等と思われる部分を割り振って取り組むことでしょう、そうですね、全員に棚を支給するとか。完全に同じにはならないですが、十分近いでしょう。全員が自分の棚にあるテキストを読んで単語を数えている間、まとめ役であるあなたは全てを整理します：必ず全員に棚が割り当てられ、必要に応じてスナックや水、トイレ休憩が取れるようにし、病欠の電話をしてきた人がいたら臨時従業員を見つけて補充します。

従業員は自分の棚にある単語数を全部数え終わると、その数を付箋に書き、あなたのデスクまで行って渡します。あなたは付箋に書かれた数字を受け取り、総語数の集計に加えます。そして全員が自分の棚を片付けたら、最終的な集計をします！

これが超並列処理（Massively Parallel Processing）です。ただコンピュータの代わりに人間を使って例えているだけです。単純だけど大きなタスクを複数のバケットに分割し、そのバケットを同時に処理することで、その人がどんなに熟練していても、一人で作業するよりもはるかに速くなりますよね。

MPPデータベースとは

クラスターとノードです！

簡単に言うと、MPP データベースは、データと処理能力が複数の異なるノード（サーバー）間で単一のリーダーノードと単一または複数のコンピュートノードで分割された、データベースまたはデータウェアハウスの一種です。- MPPでは、リーダー（あなた）はリーダーノードと呼ばれ、他の全員に指示を出し、最終的な集計を行います。そして図書館の従業員、つまりあなたのヘルパーは、コンピュートノードと呼ばれ、データを全て処理し、クエリを実行して、単語を数えます。

また、MPP データベースは、より高価な個々のサーバーへのアップグレード（垂直方向のスケールアップ）ではなく、より多くのコンピュートリソース（ノード）を追加することで水平方向にスケールアップすることができます。クラスタにノードを追加することで、データと処理をより多くのマシンに分散させることができ、クエリをより早く完了させることができるのです。

この構造がなければ、大規模なデータセットに対して最も単純なクエリを実行するのでさえ、法外な時間がかかってしまいます。

本題に戻りましょう。
ETL パイプラインはお任せください。

MPPと代替案

大体 Hadoop

大量データを処理しやすくする技術は超並列処理だけではありません。こちらにHadoop Hive と Redshift の比較および分析の全貌がありますので、ぜひご覧ください。

要約すると、Hadoop とは異なり、MPP データベースは「シェアード・ナッシング」アーキテクチャが使われています。データセットが重なることはなく、通信はすべてネットワークを介して行われます。各ノードやサーバーには、担当するデータ（本棚）と、そのデータを分析するための計算能力（図書館従業員）があるため、MPP データベースの導入やメンテナンスが非常にしやすくなっています。また、Amazon の Redshift データベースのようなクラウド MPP データベースもコスト効率が高く、Looker や Tableau のような SQL ベースの BI（ビジネスインテリジェンス）ツールに対応しています。

MPP データベースの共通の問題は、データの構造化であり、MPPデータベースは非構造化データに対応しておらず、MySQLやPostgreSQLデータベースのような構造化データであっても、MPPの構造に合うように何らかの処理が必要になります。これは、MPPデータベースが通常カラム型であるため、分析クエリをより高速に処理することができるからです。詳しくはカラム型データベースのガイドをお読みください。

このような理由から、Redshift にデータをスムーズかつ簡単に読み込むためのパイプラインをセットアップするのは、かなりのプロジェクトになる可能性があります。特に、ほぼリアルタイムでデータを複製したい場合はそうであり、それは大体重要なビジネス指標を追跡する場合になってしまいます。そこで Integrate.io の出番です。Integrate.io は、MySQL、PostgreSQL、Amazon Auroraなどのトランザクションデータベースから Redshift への継続的でほぼリアルタイムの複製を提供します。簡単なセットアップを１回だけすれば、当社の強固なシステムは、各読み込みで１００％の精度を保証します。なのでデータは常に最新のものです。