Greenplum DB / Greenplum MR - Dell EMC Japan DB / Greenplum MR 徹底解説 Greenplum DB / Greenplum MR 徹底解説 2 3 バッチ処理・データ解析における汎用RDBMSの課題

1

データ・ウェアハウスの未来をリードするGreenplum DB 2

ビッグデータ活用でビジネス変革を実現企業向け次世代Hadoopソリューション Greenplum MR 18

Contents

Greenplum DB / Greenplum MR徹底解説

EMCジャパン株式会社東京都渋谷区代々木2-1-1新宿マインズタワー〒151-0053http://japan.emc.com

お問い合わせはhttp://japan.emc.com/contact/

EMC2、EMC、Greenplum、Greenplum DatabaseおよびEMCロゴは、EMC Corporationの登録商標、または商標です。これらの商標は、日本または諸外国で商標登録等により、適用法令で守られている場合があります。他のすべての名称ならびに製品についての商標は、それぞれの所有者の商標または商標登録です。

© Copyright 201 EMC Corporation. 不許複製SG1038-1 02/12

Greenplum MR (旧Greenplum HD）が「 ITpro EXPO AWARD 優秀賞」

を受賞しました

第 1版

2

Greenplum DB / Greenplum MR 徹底解説Greenplum DB / Greenplum MR 徹底解説

2 3

バッチ処理・データ解析における汎用RDBMSの課題

Greenplum DBのアーキテクチャの話をする前に、これまでデータベース分野

でされてきた議論を、今、一度振り返ってみます。

データベースの分野では、これまで大きく2つのアーキテクチャが議論されて

きました。

1つがシェアードエブリシングです。シェアードエブリシングというのは、1台

のサーバ・ストレージの中に、必要なデータを全て詰め込み、この1台のサーバ

で、全てのデータベースの処理をしようというアプローチです。

シェアードエブリシング・アーキテクチャで、最も有名なのはOracleデータベー

ス、IBM／DB2、あるいはMS SQL Server、PostgreSQL、MySQLのようなデータ

ベースです。

一般的にデータベースといわれるものは、基本的にはシェアードエブリシング

と考えてよいでしょう。

シェアードエブリシング・アーキテクチャはOLTPの処理には非常に向いていま

すが、バッチ処理やデータウェアハウスの処理には不向きとされています。

何故かというと、OLTPのように、1件のデータを抜き出すというのではなくて、

全てのデータを一気にスキャンする、あるいはテーブルをJOINするなど、一気

にデータを読みだして処理をするところで、IOボトルネックが発生しやすいの

です。1台のサーバで全てのデータを扱うため、CPU、メモリのボトルネックだ

けでなく、プロセス自身のボトルネックも発生しやすいと言えます。

このシェアードエブリシング・アーキテクチャのシステムで大量データ処理の性

能を向上させるために何をするかというと、1台のサーバ・ストレージにできる

だけ多くのハードウェア・リソースを追加していくことでした。

まず、CPUを10、20、30、40と増やしていくわけです。しかしながら、それで性

能が伸びるかというと、その保証はありません。次に、ストレージ・ボトルネッ

クが発生し、性能がそのボトルネックに引っ張られてしまう。そのボトルネック

を解消するために、ストレージを増設し強化する。増設したからといって、性能

が伸びるのかというと、次はまたCPUがボトルネックになってしまう。このよう

なイタチごっこが、シェアードエブリシング・アーキテクチャが、データウェアハ

ウス処理、バッチ処理に向いてないとされてきた理由です。

シェアードナッシング・アーキテクチャ

この課題を解決するアーキテクチャとして、考え出されたのが、シェアードナッ

シング・アーキテクチャです。

このシェアードナッシング・アーキテクチャというのは、一つのデータを分割

して複数のサーバに小分けにして処理をする、という考え方です。複数の小さ

なサーバを水平方向に並べて、1台のサーバが処理しなければならないデータ

の量を少なくすることで、ストレージの負荷を低くします。これによりIOボトル

ネックを解消します。加えて、サーバのメモリ上に読み出したデータも少ないた

め、CPUとメモリのボトルネックも解消できます。このような利点をもつものが

シェアードナッシング・アーキテクチャです。

このシェアードナッシング・アーキテクチャは、特に新しいアーキテクチャであ

りません。既に30年以上前からこの業界では使われてきたアーキテクチャであ

り、古くはTeradataが、このアーキテクチャで実績を上げてきました。

しかしこのシェアードナッシング・アーキテクチャにはコストの課題がありま

した。例えば、Teradataですと、サーバを並列に並べて、このお互いのサーバ

がデータを通信するのですが、そのためのインタコネクトにバイネットという

データウェアハウス向けの独自のテクノロジーが必要でした。バイネットは、専

用のハードウェアで動くもので、必然的にコストが上がっていくというのが課

題でした。

あるいは他社の例では、インタコネクトに加えてCPUも独自に開発をしていて、

そこがハードウェアを縛る原因になり、必ずコストが上がるような状況を招い

ていました。

これらのような理由で、なかなかデータウェアハウス・システムのコストを下げ

ることができない状況が続いていたのです。経済的に余裕のある企業がかな

り大きな投資を行う。これがこれまでのデータウェアハウスのシステムでした。

Greenplum DBは、データウェアハウス分野のためのデータベースであり、当然

このシェアードナッシング・アーキテクチャを採用しています。しかしながら、そ

れを構成するハードウェアは特別なものに縛られるということがありません。

サーバ同士を繋げるためのインタコネクトは通常のイーサネットスイッチを使う

ことができます。

また、Greenplum DB自体はコモディティ化された普通のＩＡサーバ上で動作し

ます。Linux OSが動けば、全てGreenplum DBの対象プラットフォームになりま

す。Greenplum DBは、シェアードナッシング・アーキテクチャでありながら、特

定のハードウェアに縛られずに簡単にデータウェアハウス環境が構築できるの

です。

Buffers

Locks

Control Blocks

集計が集中

ソートが集中

結合処理が集中

スキャンが集中

サーバ#1

シェアードエブリシング

Buffers

Locks

Buffers

Locks

Buffers

Locks

Control Blocks Control Blocks Control Blocks

サーバ#1 サーバ#2 サーバ#3

スキャン・結合・ソート・集計を並列化

シェアードナッシング

徹底解説その１データ・ウェアハウスの未来をリードするGreenplum DB

図1: シェアードエブリシングとシェアードナッシング・アーキテクチャ

Greenplum DBはデータウェアハウス、バッチ処理のための高速データベースです。構造化データを対象にしたビッグデータの分析を低コストで高速に実行する基盤として利用できます。ここでは、Greenplum DBの先進機能、利用例を紹介しながらGreenplum DBのアーキテクチャを説明します。

Greenplum DBの特徴・アーキテクチャを理解する

Greenplum DBの位置づけ

次に、Greenplum DBがシステムの中のどこに位置付けられているのかを確認

してみましょう。

一番左は基幹系のデータベースです。日中にトランザクション処理をするため

のデータベースで、OracleやIBM DB2、MySQLなどが使われています。これら

のデータベースから日中のトランザクションを吸いだしてＥＴＬサーバを経由し

て貯め込む先、そこにあるのがGreenplum DBです。ここに履歴、ヒストリカル

データをどんどん貯め込み、分析をかけていくということになります。

Greenplum DBはあくまでもデータベースですので、ユーザからはBIツールを

使ってアクセスすることになります。

BIツールとしては、Business Objectsや、MicroStrategy、JaspersoftやSASな

ど、一般的に広く使われているツールが利用可能です。

BI、ETL製品への幅広い対応で基幹システム、分析システム連携を実現

基幹システム

分析&レポートETLExtractTransform Load

Oracle

DataStageInfomaticaSAS ETLAb InitioPluralSoftTalend

MicroStrategyCognosSASJaspersoft Business ObjectsPentahoHyperionACTUATE

High SpeedLoader

IBM/DB2

MySQL

Postgres

SQLServer

JDBC＜　　＞

ODBC＜　　＞

SQL/92＜　　＞

Greenplum DBの3つの特徴

バッチ処理・データ解析のためのデータベースであるGreenplum DB。その特

徴を、3つご紹介します。

まず第1点目は、大規模に処理をパラレル化する、並列処理をさせるという、

シェアードナッシング・アーキテクチャである点です。シェアードナッシング・

アーキテクチャを採用することによって、百から千以上のCPUコアを同時に使

い、パラレルに、高速にデータ処理を行えるというのが第一点目の特徴です。

大規模並列処理と言っても、標準のSQLが使えます。SQLを知っている開発者、

ユーザであれば、Greenplum DBに標準のSQLを投げ込むだけで、ユーザは並列

処理を意識しなくてもGreenplum DBが自動的にパラレル処理を実現してくれ

ます。

2点目は、特定のハードウェアに縛られないオープンアーキテクチャである点です。

Greenplum DBを構成する全てのコンポーネントは特定のハードウェアに縛ら

れません。インタコネクト、ストレージ、サーバ、CPU、メモリ、OSに至るまで、

すべてのコンポーネントが特定のものに縛られていません。

従来、データウェアハウスを始めるということは、それ専用のデータウェアハウ

ス・システムを新規に導入するということと同じでした。それに対しGreenplum

DBは、コモディティのサーバ、スイッチ、ストレージをうまく活用してデータ

ウェアハウスの環境を、構築し、運用することができる。これが2点目のポイン

トです。

そして3点目が拡張性です。

Greenplum DBは、サーバを追加するだけで簡単に拡張できます。システムを止

めずに、オンラインでシステムにサーバを追加し、拡張することができますの

で、CPUのパワーが足りなくなった場合にも、簡単に性能をアップさせることが

できます。ストレージも同様です。この拡張性が3点目のポイントです。

シェアードナッシング・アーキテクチャの実装により、高速なバッチ処理・データ分析を実現

Greenplum DBを構成するコンポーネントは大きく3つあります。

上からマスターサーバ。2つ目がネットワーク・インタコネクト。3つ目がセグメ

ントサーバです。

マスターサーバは、ユーザからのクエリの受付と、クエリ結果の返答を行いま

す。ただしデータベース処理自身は行いません。データベース処理は、バックエ

ンドにあるセグメントサーバに対して、分散して指示をします。

ユーザから「こういうクエリがきましたので、処理をしなさい」と命令を受け、

分散して処理をするのがセグメントサーバです。実際には、このセグメント

サーバの台数によってデータベースの性能と、データベースの容量が決まります。

このマスターサーバと、セグメントサーバの間を繋げるのが、ネットワーク・イ

ンタコネクトです。

マスターサーバと、セグメントサーバは、他社であれば専用のサーバが必要でし

たが、Greenplum DBでは通常のインテル・アーキテクチャのサーバが活用でき

ます。 OSはLinuxが一般的です。

このマスターサーバとセグメントサーバの間を取り持つ、ネットワーク・インタ

コネクトにはイーサネットスイッチを使います。ここも、専用のものは必要あり

ません。今であれば10Gbイーサネットスイッチを冗長化のために2台使う構成

が一般的です。よりコストを抑えたいということで1Gbイーサネットスイッチを

2台使用している事例もあります。

シェアードナッシング・アーキテクチャによる高速DB処理

SQLを解析し、セグメントサーバのための最適な並列実行プランを作成

gNetソフトウェアインタコネクトによるセグメント間の効率的なデータ送受信

パラレルデータフローエンジンが、ハードサーバ性能を最大活用

パラレルロードによる、

高速ローディング

マスターサーバクエリプランニング＆ディスパッチ

セグメントサーバクエリの実行＆データの格納

外部ソースローディング、ストリーミング等

ネットワークインタコネクト

SQL

大規模並列処理

・シェアードナッシングによる大規模並列処理・パラレルエンジンが、数台から数百台のサーバによる並列処理を実現・広範囲のSQL対応（SQL-92, SQL-99, SQL-2003 OLAP）

オープンアーキテクチャ

・コモディティハードウェアで実現する大規模DB・ソフトウェアオンリーのアプローチにより、低価格かつ構成の高い柔軟性を実現

拡張性

・スモール・スタートが可能・データ量の増加に伴うシステム拡張を低コストで実現・数百ギガから数十ペタバイト規模までの　リニアなスケーラビリティ

図2: Greenplum DBの位置づけ

図3: Greenplum DBの特徴


4 5

世界最高速のデータロード性能

Greenplum DBは他製品と比べてさまざまな差別化ポイントがありますが、最

もわかりやすいポイントはデータロード性能です。データロード性能は他社製

品と比較して、圧倒的に高速です。

図4はGreenplum DBと、他社の4製品における、1時間当たりにローディングで

きるデータの量を比較したグラフです。縦軸が1時間当たりでローディングでき

るデータの量、TB/h、横軸が各製品です。

他製品が5TB、或いは2TBという性能に対して、Greenplum DBは10TBのデータ

ローディングが可能です。他製品と比較して2倍、または5倍のローディング性

能があります。

また、Greenplum DBも他製品も1ラックから2ラック、3ラックと、ラックを増設

し拡張することができます。Greenplum DBの場合、2ラックにするとセグメン

トサーバが増えて行き、リニアに性能が向上し、20TB/hのデータローディング

が可能になります。対して他製品では性能が頭打ちになり、大きく変わりません。

2ラックでも3ラックでもローディング性能は5TBあるいは2TBのまま変わりま

せん。

Greenplum DBは、2ラックでは20TB/h、3ラックにすると、30TB/hというよう

に、ローディング性能がリニアに増加します。

リニアに性能を向上させることができることは、特にHadoopを利用している

ユーザに非常に好評です。

Hadoopで扱うべきデータがどこまで増えるのか分からない状況で、性能を青

天井で向上させることができる仕組みが非常に評価されています。

TB/h

10

0

20

30

40 Greenplum DBはラック数に比例してロード性能が向上

0 2 4 6 8

10 12 TB/h

1ラック構成での比較

世界最高速のデータロード性能を実現するGreenplum DBのScatter/Gather Streaming 技術　活用例1

Greenplum DBが他製品と比較して何故これだけの性能差がでるのか？その

理由を、Greenplum DBの主要機能の紹介を通じて説明していきます。まず、

データローディングの機能について説明していきましょう。

Greenplum DBでは、様々なデータローディング手法があります。

その中で最も高速にデータをローディング出来るのが、この活用例１のロー

ディング方法です。

図5では、マスターサーバ1台とセグメントサーバ2台という、非常に小さな

Greenplum DBシステムを簡易的に表しています。このGreenplum DBシステム

のインタコネクト部分に、ロードサーバ（NASやファイルサーバ）を直接接続し、

マスターサーバを経由しないでデータをローディングすることが可能です。ま

た、このロードサーバ自身を水平方向に増やしていき、ローディング性能を増や

していく、リニアにスケールさせることができます。

Oracleを利用しているユーザであれば、Oracleからファイルをロードサーバ上

に掃きだし、そこから直接インタコネクトを経由してセグメントサーバにデータ

を流し込んでいく、ということも可能です。

他DB（Oracle等）

セグメントサーバ

ロードサーバロードサーバ


マスターサーバ

データロード：従来の処理方式

ここでは他製品の仕組みと比較しながらデータローディング性能の優位性に

ついて更に説明します。

従来のデータのローディング方式、これはOracle Exadata、Netezza、そして

Teradata、この3つのアーキテクチャに等しく当てはまるものです。

他製品ともに名称は違っても、2階層のサーバでシステムが構成されていると

いう点ではGreenplum DBと同じです。

例えば、Greenplum DBでは、マスターサーバ、セグメントサーバと呼んでいます

が、Oracleではデータベースサーバーとストレージサーバーと呼んでいます。

このストレージサーバーを並べることによって性能を上げています。これは

Netezza、Teradataも同様です。

他製品におけるデータローディングは、全てのデータがマスターサーバを経由

して入っていきます。マスターサーバ上にローディングプロセスがあり、仮に

ファイルサーバが2台、CSVのようなテキストファイルが2つあったとします。こ図4: 世界最高速のロード性能

図5: Greenplum Scatter/Gather Streaming 活用例1

世界最高速のデータロード性能を実現するGreenplum DBのScatter/Gather Streaming技術

れらのデータをローディングするとき、この図のようにマスターサーバを経由

しなければ全てのデータがセグメントサーバに入っていかないという事になり

ます。

図6ではセグメントサーバは4台ですが、8台になったとしても、或いは12台に

なったとしても、マスターサーバがボトルネックになってしまい、ローディング

の性能は伸びません。

先ほどの1ラック、2ラック、3ラックと、システムを増強していたとしても、性能

が伸びないというのは、正にこの点に起因するわけです。

データソース

マスタサーバ


ローディングプロセス

セグメントサーバセグメントサーバセグメントサーバ

データソース

Greenplum DB の徹底した並列処理

これに対し、Greenplum DBのデータローディングでは、マスターサーバはデー

タのやり取りをしません。

マスターサーバは、必須のコンポーネントであり、システム内には存在します

が、データローディングの処理自体には関与しません。

ではどのようにデータをローディングしているのでしょうか。各セグメントサー

バ上はデータを取りこむ、パラレルデータフローエンジンというものが存在し

ます。従来製品の仕組みの説明でいうところの、ローディングプロセスを担っ

ています。

データをデータソースから取りこむ処理を、他製品であれば1か所にしかない

ところを、Greenplum DBでは各セグメントサーバ上に、ローディングプロセス

を台数分持つわけです。

まず、各セグメントサーバは、データの内容などは特に考えず、図7の場合で言

えば、色や場所は特に考えないで、ブロック単位でデータソースからデータを

持ってきます。次に、セグメントサーバの1台1台が、マスターサーバが定める分

散ポリシーに応じて、データを分散するという処理を行います。実際には、こ

の処理を全てのセグメントサーバが同時に行います。これによってローディン

グ性能を向上させることができるのです。

ラックを増やすということは、当然セグメントサーバが増えることになり、デー

タを引っ張ってきてデータを所定の位置に分散するという、この処理を行うエ

ンジンであるセグメントサーバ分増えますので、ローディング性能がリニアにど

んどん伸びていくのです。


データフローエンジン


データソース

セグメントサーバセグメントサーバセグメントサーバセグメントサーバ

データソース

パラレルデータフローエンジン




データソースデータソース




パラレル

セグメントサーバセグメントサーバ

各セグメントサーバは、データの内容（この場合は色や場所）などは特に考えず、ブロック単位でデータソースにデータを取りに行き、各々のデータのロード先にデータを振り分けます。

実際には、上記の処理をすべてのセグメントサーバが同時に行います。この並列処理が高速なローディングを可能にしています。


活用例1でご紹介したのは、大量のデータを限られた時間に、できるだけ高速

に流し込むというローディング手法です。

それ以外にもGreenplum DBは、様々なデータのローディングが可能です。

2つ目のローディング手法としてご紹介するのは、ロードサーバを使用しない

ローディング手法です。

ここでは、Oracleを例として説明します。

図8に示すとおり、OracleとIP通信ができる環境があれば、セグメントサーバが

Oracleに対して直接コネクトし、データをローディングすることが可能です。

従って、Oracleから一度、ファイルサーバにファイルをダンプする必要なく、直

接データを抜き出すことが可能です。

このローディング手法は、一旦ロードサーバ（ファイルサーバ）に対してファイ

ルをダンプして、そこからセグメントサーバにデータを流し込むというこの手間

を省けます。「なるべく最新のデータが欲しい」といった場合に、役に立つ仕組

みです。

このローディング手法は、ローディングのパフォーマンスが速いか遅いか

は、データソース側の、この例であればOracleのシステムに依存します。直接

Oracleからデータを引っ張ってくることになるため、Oracle側のシステム規模

が小さいと、高いローディングの性能を出すことはできません。

一方、Oracle側のサーバが非常に高スペックで、OracleとGreenplum DBの間の

ネットワークも帯域が非常に太ければ、非常に速いローディングが期待できます。

ですからこの手法は、ニアリアルタイムなデータに対して分析をしたい場合に、

有効な手法です。

図6: 従来の処理方式

図7: Greenplum DBの徹底した並列処理


6 7

具体的な仕組みとしては、Greenplum DBの外部表という機能を使用してい

ます。外部表というのは、Greenplum DBの中にまだ入っていない、セグメント

サーバ上に置かれていないデータであるが、その外にあるデータをあたかも

Greenplum DBのデータとして扱える機能です。

この外部表には、OSコマンドの結果をGreenplum DBのデータレコードとして

扱う機能があります。

例えばOracleからデータを抜き出す場合には、OSコマンドの中で、Oracleク

ライアントのコマンドを叩き、Oracleクライアントが外部にあるOracleに対

して、SQL P lusでコネクションを張りデータを引き出してきて、その結果を

Greenplum DBの中のデータレコードとして扱うことが可能です。

OSコマンドとして発行できれば、何でも外部表データとして扱えるので、

Oracle以外のデータベースにも対応可能です。 DB2、SQL Serverであったり、

シェルのコマンドであったり、何かのアプリケーションの実行結果であったり、

様々なものをデータとして扱うことができます。

他DB（Oracle等）

セグメントサーバセグメントサーバ



ここまでは、高速にデータをロードする、あるいはニアリアルタイムなデータ

をローディングする方法をご紹介しました。次は、データを書きだすお話しで

す。当然、Greenplum DBは、マスターサーバを経由してデータを書きだすこと

が可能ですが、ここもローディングと同じように、マスターサーバがボトルネッ

クになる可能性があります。他製品が持っている、また違う箇所のボトルネッ

ク、アンロード時のボトルネックになります。

Greenplum DBは、マスターサーバを経由してデータを書き出す以外に、セグメ

ントサーバから直接ファイルサーバに対してデータを書き出すことも可能です。

それを示したのが図9です。

セグメントサーバから、マスターサーバを経由しないで、ダイレクトにデータを

書き出しています。

この書き出し先も、1台ではなく、2台、3台、4台と増設することができ、データ

を受け取る側のサーバを増やすことによって、大量のデータのパラレルの高速

アンロードが可能です。

このパラレルなデータのロード、パラレルのデータのアンロード、この仕組は

Hadoopとの連携に非常に有効に働きます。

ここでサポートしているファイルの形式は、CSVなどのテキストファイルです。

テキストファイルに対するデータの書き出しが可能です。


ロードサーバロードサーバ




最新のデータのロード・アンドロードの技術として、Greenplum DB 4.1で搭載

された機能が、外部表のデータソースとしてHadoopをサポートしたことです。

Hadoopのデータをパラレルにローディングでき、パラレルにデータをアンロー

ドすることもできます。

図10では、下がHadoopシステムです。

Hadoop

Hadoop

Hadoop

Hadoop

Hadoop

GreenplumDB


データノード



データノードデータノード

ネームノード

Hadoopは、Greenplum DBと似た2つのレイヤーから構成されています。

Hadoopは、親的役割をするネームノードと、水平方向にスケールさせて性能を

あげていくデータノードの2つのレイヤーの組み合わせで構成されています。

HadoopのデータノードとGreenplum DBセグメントサーバが直接パラレルにや

りとりすることによって、Greenplum DBのマスターサーバを経由せず、なおか

つHadoopのネームノードも経由しないで、パラレルにデータのロードが可能で

すし、アンロードも可能です。

Hadoopは、現在非常に注目されている技術ですので、他社製品も当然のよう

にHadoopとの連携ができると言われています。

他社も「Hadoopとの連携ができるようになりました」と発表しています。

しかしながら、他製品は、マスターサーバを経由してHadoopとデータのロー

ド・アンロードを行いますので、Hadoopと連携する際、Hadoopシステムから

データを抜き出そうとすると、結局マスターサーバを経由します。同様にマス

ターサーバを経由してデータが出ていくわけです。従って、データが大きくなれ

ばなるほど、連携部分のボトルネックが顕著になります。

Greenplum DBはこの点を解決しています。Hadoopを外部表として使えるとい

うようになったという、この機能がボトルネックを解消しているのです。




例えばデータ量が50億件の非常に大規模なデータを、別の50億件のテーブル

と突き合わせて、その突き合わせた結果の、非常に大きくなったテーブルをそ

のまま集計も何もしないで、Hadoopに渡したい。このようにデータ量として

は、数百ギガバイトになるようなものを、マスターサーバを経由させると当然ボ

トルネックになります。そのような場合に使うのは、このアンロードの機能にな

ります。

Greenplum DBにおけるマスターサーバの役割

ここで1つ疑問が生じたのではないでしょうか。Greenplum DBのマスターサー

バは実際には何をやっているのでしょうか？マスターサーバはクエリの実行や

JOIN処理などは行いません。それらの処理を行うのはセグメントサーバです。

Greenplum DBでは、セグメントサーバ同士が、自分以外のサーバが、どういっ

たデータを持ってるかを知っています。従って、JOIN処理などにマスターサーバ

が関わらないで、セグメントサーバ同士が通信をすることによって、処理を実行

していきます。

その処理に関する分散ポリシーを、各セグメントサーバに定義をすることは、マ

スターサーバを経由してのみ可能です。

例えばテーブルを作るときに、「このテーブルはこういった分散をさせます」と

いう指示をします。そうすると、その指示が各セグメントサーバ上に伝達され、

このテーブルに関しては「こういう分散ポリシーなんだ」ということを各セグ

メントサーバが記憶します。その後は、例えばデータソースから直接データを

引っ張ってきたとしても、セグメントサーバは「マスターサーバから教わったこ

の分散ポリシーに従って、分散すればいいのだ」と判断して処理を行います。

仮に「自分のところにあるべきデータじゃない」ということがわかった場合に

は、他のセグメントサーバに渡せばいいということを知っていますので、直接他

のセグメントサーバにデータを渡します。

マスターサーバは必須であり、テーブルの定義、あるいは分散ポリシーを設定

するためには絶対に必要ですが、複雑な処理であったとしても、マスターサー

バは実際のクエリ処理を、行わないで済むわけです。


8 9

データレコードの分散処理

Greenplum DBが、データをどのように分散配置しているかを説明します。

Greenplum DBは、データレコードの分散配置の仕方をテーブル作成時に指定

します。具体的には CREATE TABLE 文の後ろに DISTRIBUTEDという句を追加し

ます。DISTRIBUTED の後ろにカラムを指定しますと、データレコード１行づつ

の指定されたカラムの値をハッシュ値にしてセグメントへのデータレコードの

ハッシュ分散が行われます。図11は、Greenplum DBがハッシュ分散した時の仕

組みを表しています。DISTRIBUTED の後ろに RANDOMLY と指定すると、ハッ

シュ分散は行わずにラウンドロビン方式でデータレコードを各セグメントへ分

散させてゆきます。

なお、分散配置の仕方が 2通りあると説明をしましたが、どちらの場合でもと

ても重要なポイントは、テーブル作成後に指定された分散配置の仕方は各セグ

メントにも通達されているという点です。ですので、各セグメントがクエリ処理

をする過程で他セグメントのデータレコードを参照する必要が出てきた場合で

も、そのデータレコードの在処をマスターサーバに問い合わせません。各セグ

メントサーバが分散配置の仕方を把握していますのでお互いに通信します。

B A B C C A A C

C C C

A A A

B B

データレコードマスターサーバ


ハッシュの指定

S2

S1

S3

クエリのパラレル処理

次にクエリのパラレル処理について説明します。Greenplum DBでは、各セグメ

ントサーバへのクエリ処理は、マスターサーバからの指示を受けてパラレルに

行われます。

まず、クライアントは、クエリの投げ先としてマスターサーバを指定し、クエリ

を投げます。次にクエリを受け付けたマスターサーバは、クエリの解析を行い、

各セグメントサーバへの実行プランを作成します。「パーティションスキャン

をするか」、「シーケンシャルスキャンをするか」、などや「JOINでは入れ子JOIN

をするか、ハッシュJOINするか」などの実行プランを考えるのがマスターサー

バです。実行プランを作った後、実際にクエリの処理を始める時に、各セグメ

ントサーバに対して、この実行プランを処理しなさいという指示を出します。

指示を受け取った各セグメントサーバは自分が持っているデータに対して、マス

ターサーバから来た実行プランを実行します。全てのセグメントサーバは独立

して処理を実施しますが、データの配置によってはセグメント1台の中で処理が

終わらず、複数台のセグメントサーバと通信をしなければならない場合が生じ

ます。ここが重要な点ですが、その場合もマスターサーバは介在せずセグメン

トサーバ同士が直接会話してデータの交換をします。マスターサーバの介在を

必要としないためパラレリズムが維持されるわけです。

クエリ処理の結果は、セグメントサーバがそれぞれマスターサーバに対して返

して、そして最終的にクライアントに返っていく、これが通常のクエリ処理のフ

ローです。

また、クエリの結果はアンロードすることも可能です。各セグメントサーバが実

施したクエリ処理の結果をアンロード先のサーバに対して出力したり、Hadoop

に渡したりすることができます。

アンロードの仕組みは、出力先がファイルでも、Hadoopであったとしても、

Greenplum DBの外部表という機能を使っています。外部表ですからテーブル

です。アンロード時は処理したクエリの結果を「こちらの外部表にINSERTして

ください」というように指示します。このようにINSERTすると、実はその出力先

がHadoopであったり、あるいはファイルサーバ上のテキストファイルであった

りするのです。Hadoopとの連携については、後の章で詳しく説明します。

クライアントクエリ実行プラン






答返と付受のリエク・成作のンラプ行実・

のンラプ行実のへトンメグセ・配布と実行の指示

納格をターデザーユ・答返と付受の示指のらかタスマ・

行実のリエク・

高度なパイプライン処理により高速化されたソーティング

次にソーティングのお話をしましょう。

ソーティングのような複雑な処理は、結局セグメントサーバ上1台では処理し

きれないので、マスターサーバがすべて処理するため、マスターサーバがボトル

ネックになるのでは？と思われるかも知れません。

Greenplum DBは、マスターサーバがボトルネックになること無く、ソーティングを

非常に高速に実行できる仕組みを実現しています、その仕組みをご紹介します。

図13のマスターサーバ1台と、セグメントサーバ3台の構成で確認してみます。

まずクライアントからソートの要求が来たとします。次に、そのソートの要求は

マスターサーバから、各セグメントサーバに対して指示が行きます。指示を受け

たセグメントサーバは、まず自分たちの中に順番がバラバラな状態で持ってい

るデータをプリソートします。その結果をマスターサーバに返していくわけで

すが、実は全てのデータがマスターサーバに返りきる前に、マスターサーバはク

複雑な検索・集計・分析を、短時間に処理するための先進機能

図11: データレコードのハッシュ分散

図12: クエリのパラレル処理

ライアントへの返答を始めます。

なぜこのような仕組みが可能なのでしょうか。

順を追って説明します。

まず、各セグメントサーバが、データのプリソートをした段階で、それぞれのセ

グメントサーバが持っている一番小さなデータはわかります。そこから一番上

にあるデータを、それぞれのセグメントサーバが出し合います。この段階で、こ

の全てのデータの中で一番小さなデータが何かということはわかります。この

図13の中では「1」が一番小さなデータということがわかり、それを返します。

そして次の一行が飛んでいきます。そして、この3行を比べてみて今回も一番左

のサーバのデータが一番小さいことがわかり、クライアントに返せます。

この仕組みを繋げていくと、パイプラインが途切れることなく、マスターサーバ

を経由してクライアントに対してソーティングされたデータを返していくこと

ができます。

セグメントサーバセグメントサーバセグメントサーバ


ソート要求

ソート要求

ソート要求

ソート要求

１

２４

９

３

６

７

１１５

８

１０

１２

クライアント

②ソートの指示を受けた各セグメントサーバは、自分のデータをプリソートします。

①クライアントから来たソート要求を、各セグメントサーバに指示します。ソート

要求


１２

４

９セグメントサーバ

３

６７

１１セグメントサーバ

５

８

１０１２


クライアント

①各セグメントサーバは、ソート結果をマスターサーバに返します。

②全てのデータがマスターサーバに帰りきる前に、マスターサーバはクライアントへの返答を始めます。

他製品の場合はどうでしょうか。プリソートされていない全てのデータを、一

回マスターサーバに持っていき、1台のマスターサーバでソーティングを行いま

す。すべてのデータの読み出しと、すべてのソーティングを1台のデータベース

のサーバの中で行うため、処理がパラレル化されず、ソーティング処理に非常

に時間がかかります。従ってソーティング処理を高速に行うためには、非常に

CPUスペックが高く、大容量のメモリの積んだ非常に大きなサーバが必要にな

るわけです。例えばCPUが64コア、メモリは1TBといった巨大なハードウェア・

リソースが必要となり、非常に高価なシステムになります。

これに対し、Greenplum DBは、ソーティング処理を効率良くパラレル化できる

アーキテクチャを持っていますので、マスターサーバはボトルネックにはなりま

せん。Greenplumのアプライアンス製品であるGreenplum DCAのマスターサー

バが積んでいるCPUは、2CPU、トータル12コア。メモリは48GBです。この程度

のハードウェアスペックで充分なのです。

図13: Greenplum DBのソーティング


10 11

Greenplum Polymorphic Data Storage が提供する豊富な選択肢

先に紹介した機能以外にも、Greenplum DBには、データアクセスを高速化す

るいくつかの仕組みがあります。

その仕組の一つであるデータの格納方式について説明します。

Greenplum DBでは、ローストアと、カラムストアという2つのデータの格納方式

を持っています。

ローストアというのはデータをロー方式、行単位で格納するという方式です。こ

れは一般的なデータベース製品が使っている、非常に一般的なものです。

実は、この仕組みは、データウェアハウス処理でよくある集計処理には非常に

効率が悪いのです。何故でしょうか？例えば、このカラムのＣのデータだけを

抜き出したいとします。ローストア方式の場合、ここの値だけを読みたいのに、

全てのカラムの全レコード読みながら、カラムＣだけのデータを抜き出すこと

をします。結果的に、非常に効率の悪いアクセスパターンになってしまうのです。

これに対してGreenplum DBが持っているカラムストアは、データをカラム単位

で格納していきます。

ですから、カラムＣのデータだけ集計したい、例えばカラムＣの「平均値を出し

たい」あるいは「合計値を出したい」という場合でも、他のカラムに対するアク

セスは一切行なわず、Ｃカラムだけ一気に足し合わせてアクセスをし、集計が

できますので、IO負荷が非常に少なくて済むわけです。このように、集計処理

を非常に高速に実行できるというのがカラムストアのメリットです。

実は、このカラムストアというのは新しい技術ではありません。

古くはSybaseのデータウエアハウス・ソリューションである、SybaseIQが15年

前からこの仕組みを提供しています。ですが、カラムストア・データーベースの

課題というのは、逆にローストアを持っておらず、カラムストアしか無いという

のが課題でした。

大半のデータベース、例えばOracleやDB2などはローストアを採用しています。

ローストアから持って来たデータをカラムストアに入れる、データベースのマイ

グレーションすることはクエリの書き方をうまく調整しなければ、なかなかパ

フォーマンスが出ません。

ローストアというのは、1件単位でデータを格納していきますので、インサート

処理は非常に高速です。逆にカラムストアは、集計処理は非常に速いのです

が、インサート処理は苦手で遅いのです。インサート処理をカラムストア方式

に対してそのまま適応すると、非常に効率の悪いデータベータ処理になりま

す。ここがカラムストアの課題でした。

Greenplum DBは、ローストアとカラムストアを、1つのテーブルの中で混合して

使うことが可能です。

テーブルをパーティショニングして、最新のデータに関しては、アップデートや

インサートが多く発生し、複数カラムに対してアクセスが多くなるのでロースト

アで格納する。それ以降の古いデータに関しては集計しかしないので、カラム

ストアを使う。このようなことが可能です。これはGreenplum DBだけのテクノ

ロジーです。

従来からあるローストアのテーブル

カラムストアのテーブル

列A 列B 列C 列D

読み出す必要のないカラムの値もアクセス。余分なIO負荷が発生

列A 列B 列C 列D

特定カラムの特定カラムの値のみアクセスするため、IO負荷を劇的に軽減

検索範囲

検索範囲

テーブルパーティショニングによる検索範囲の限定

Greenplum DBのテーブルパーティショニングについて紹介しましょう。

データを、セグメントサーバにハッシュキーを使って分散配置をしていくという

のは、先程説明しました。Greenplum DBは、更に各セグメントサーバの中で、

検索をする範囲を絞り込んでいくことができます。それが、テーブルパーティ

ショニングになります。検索範囲を絞り込んでいくことで、ストレージへのIOを

減らし、レスポンスタイムを更に短くできます。

テーブルパーティショニングの種類としては、レンジ（範囲）パーティショニング、

リストパーティショニング、マルチレベルパーティショニングに対応しています。

1年間の集計処理を例にあげると、レンジパーティショニングでは2011年の1月

から12月の販売データを1カ月ごとに区切ることができるので、6月の売り上げ

データだけを集計したい、合算値を出したいといった場合に、6月のデータだけ

を読み出すことができます。

パーティショニングをしなければ、1月から12月のデータを全部読み出した（フ

ルスキャン）上で6月分だけ抜き出して集計処理を行いますが、パーティショニ

ングを行うと、1月から5月分および７月から12月分のデータを読まず、6月分の

データだけを読み出せるので、フルスキャンを発生させること無く、非常に高

速なクエリ処理が可能になります。

また、レンジパーティショニングで区切ったテーブルを更にリストで分ける、あ

るいは、レンジパーティショニングで分けたものを更にレンジパーティショニン

グで分ける、といったことも可能です。

例えば、月単位で分けたテーブルを更に週単位で分ける、あるいは、リストで分け

たものをリストで組み合わせる。これがマルチレベルパーティショニングです。

Greenplum Polymorphic Data Storage が提供する豊富な選択肢

図14: ローストア、カラムストア

セグメントの場合

セグメント＋パーティションの場合

検索範囲



検索範囲

既存投資の保護とさらなる高速化へ – インデックス

Greenplum DBは、データベースですので当然インデックスにも対応しています。

広く一般的に使われているB-Treeインデックス、それ以外にビットマップ・イン

デックスにも対応しています。B-Treeインデックスというのは、OLTP処理に強

いとされるインデックスです。ビットマップ・インデックスはDWH/BIシステムに

多い参照処理に効果的に機能します。この両方のインデックスに対応している

ので、OLTP処理にもデータウェアハウス処理のどちらにも適したインデックス

を使えます。

Zeb

ar

Root

Branch Branch Branch

Leaf Leaf Leaf Leaf Leaf Leaf

Book

ra

C

1 1 1 1 1

MALE

FEMALE

SAZAE

TARAO

WAKAME

KATSUO

MASUO

FEMALE

MALE

FEMALE

MALE

MALE

テーブル

インデクス

B-Treeインデクスの格納方式

Bitmapインデクスの格納方式

ワークロード管理 - リソースキュー

続いて、ワークロード管理について紹介します。データウェアハウス・システム

ですので、複数のユーザが同時にクエリを投げるということが当然ありえます。

この場合に、どのように優先順位付けをするかという機能がリソースキューを

使ったワークロード管理です。

Greenplum DBを使用する全てのユーザは、必ずどれかの一つのリソースキュー

に紐付けられます。このリソースキューごとにCPUリソースの割り当てや同時に

実行可能なクエリの数を決めることができます。

例えば図17の場合、マネジメント層用のエグゼクティブキューと、レポート作成

の担当者用のレポートキュー、アナリスト用のアナリストキューの3つがありま

す。このキューの太さ、これがCPUリソースの配分を表しています。マネジメント

の方は、非常に太いキューを持っているので、多くのCPUリソースが割り当てら

れており、アナリストと同じクエリを同時に投げたとしても、エグゼクティブは

非常に早くクエリの結果が得られます。一方アナリストは頻繁にクエリを発行

しているため、エグゼクティブに比べてCPUリソースが少し絞られており、クエ

リ結果が帰ってくるのも少し遅いわけです。

加えて、いくつのクエリを同時に実行できるかも定義できます。

図17の場合、例えばアナリストは同時に4つのクエリしか実行できません。5つ

目のクエリを実行しようとしても、すでに4つのキューを使っているため、実行

中の4つのうちどれかが終わるまで待たされます。これに対してエグゼクティブ

用には、10のキューが設定されています。従って、5つ6つのクエリを実行して

も、待たされずに処理されていきます。クエリが11個目になって、初めて待たさ

れるというわけです。

この、クエリが実際に実行されるタイミング、CPUリソースの配分、加えてメモリ

の配分を行えるのがワークロード管理、リソースキューという機能になります。

リソースキュー間でCPUやメモリ割当をプライオリティ付け

エグゼクティブキュー

レポートキュー

アナリストグキュー

アナリスト

レポート作成担当者

マネジメント

実行開始待ちのクエリ実行中のクエリ

リソースキュー間でCPUやメモリ割当をプライオリティ付け

同時に処理できるクエリ数か、コストの総和をリソースキュー毎に設定

GreenplumDBの提供するワークロード管理機能の一つリソースキューによって、複数の利

用者やバッチ、システムの同時利用のために、受け付けたクエリの処理に関する優先順位付

けを行うことが可能です。

リソースキューは大きく 4つの観点から優先順位付けを行います。

(1) 同時に処理されるクエリのコストの総和クエリ毎のコストを確認し、処理中の複数クエリのコストの総和が、あらかじめ指定した閾

値を上回ることのないよう、制御します。

(2)同時に処理されるクエリ数処理中のクエリ数を確認し、処理するクエリの数があらかじめ指定した閾値を上回ることが

ないよう、制御します。

(3) CPUリソースの優先度リソースキュー間で CPUリソースをどのように割り当てるかを制御します。

(4) メモリの優先度リソースキュー間でメモリをどのように割り当てるかを制御します。

複数の利用者・バッチ処理・システムでの同時利用のための機能

図15: テーブルパーティショニングによる検索範囲の限定

図16: B-TreeインデクスとBitmapインデクス

図17: ワークロード管理 - リソースキュー


12 13

動的なクエリ優先度付け

Greenplum DBでは、クエリごとにCPUリソースの動的な割り当てが可能です。

例えば、リソースキューについて、C P Uリソースの配分を最大限利用できる

キューと、中くらい利用できるミディアムというキュー、配分が少ないローとい

う3つのキューがあるとします。

まず1つ目のミディアムというキューのユーザは、まだ誰もシステム資源を使っ

ていないためクエリを実行したときCPUリソースを100％使えます。仮に、この

ミディアムのキューにもう一つクエリが来た場合には、リソース配分は、同じプ

ライオリティですので、このように均等に配分されます。次にローのクエリが来

たとします。ミディアムよりプライオリティが低いので、CPUリソースの割り当て

は限られます。少しだけCPUリソースをもらい、それに合わせて他の2つのクエ

リの割り当ては均等に下がります。最後に4つ目のクエリとしてマックスのクエ

リが来たとします。マックスは最大限CPUリソースが貰えます。それに伴い、ミ

ディアムとローに関しては、割り当てが下がります。

これをマスターサーバが判断しながらダイナミックにCPUリソースの割り当て

を変更していきます。Greenplum DBはこのような動的なリソース割り当てが可

能です。

また、この他にも特定のクエリを狙い撃ちでCPUリソースの割り当てを絞り込む

ことも可能です。データウェアハウスの運用の中でまれにあるケースとして、アナ

リストが1週間1つのクエリを回し続けているということがあります。非常に処理

が重たいクエリを実行してしまったため、１週間ずっとCPUを80％以上使ってし

まい、他のユーザにCPUリソースが割り当てられないという状況に陥ってしまい、

今まではこれに対する術がありませんでした。手段としては、あくまでローにす

るしかなく、ローでも割り当てられてしまいます。Greenplum DBは、この1週間実

行し続けられているクエリに対して、CPUリソースの割り当てを更に絞り込むこ

とが可能です。まさに狙い撃ちをして、このユーザのこのクエリは徹底的に絞り

込み、それによって他のユーザに対するCPUリソースの割り当てを上げることが

できます。これもGreenplum DBのリソース管理の機能の一つです。

リソースキュー

Medium

Max

Low

リソース使用量の合計

Qry1 Qry2 Qry3

100%

?

Qry4


Medium

Max

Low


Qry1 Qry2 Qry3

100%

??

Qry4


Medium

Max

Low


Qry1 Qry2 Qry3

100%

??

?Qry4

?

一つ目のミディアムユーザー

は、まだ誰もリソースを使って

いないため、クエリの実行にリ

ソースを 100%使えます。

ミディアムのキューにもう一つクエリ

が来た場合は、同じプライオリティで

すので、均等にリソース配分されます。

次にローとマックスのリソース

が来ました。マックスは最大限

リソースが使えるので、それに

伴いミディアムとローの割り当

ては下がります。

Greenplum DBの高い可用性

次にご紹介するのは、可用性についてです。Greenplum DBでは、全てのコン

ポーネントを冗長化できます。

マスターサーバは、ホット・スタンバイで構成します。ネットワーク部分は、アク

ティブ・アクティブで2台以上のスイッチを使った冗長化をします。

次にセグメントサーバですが、セグメントサーバ間でデータをミラーリングす

る、ミラーセグメントという機能があります。この機能により、例えばセグメン

トサーバがダウンしてしまった場合に、その停止したサーバのミラーデータを

持っている他のセグメントサーバにフェイルオーバーし、サービスを止めること

なく処理を継続できます。

加えて、当然マスターサーバであっても、セグメントサーバであっても、データ

はR AIDで保護していますので、多段階でのデータの保護がなされていること

になります。

マスターサーバマスターサーバ


マスターサーバにおけるデータ保護

・サーバ障害に備えたトランザクションログの複製

・ドライブ障害に備えた RAID

セグメントサーバにおけるデータ保護・サーバ障害に備えたミラーセグメント

・ドライブ障害に備えた RAID

図18: 動的なクエリ優先度付け

図19: Greenplum DBの高い可用性

Greenplum DB 4.2 の新機能

2011年12月にリリースされたGreenplum DBの最新バージョン4.2では、次のような機能拡張が行われており、クエリ・スピードの向上、リ

ソースの利用率向上、システム管理機能の強化などが図られています。

メモリ管理の最適化最新バージョンでは、クエリの処理フェーズごとにメモリの割り当てが可能になり、クエリのスピードが向上しました。

テーブル・パーティションのエンハンスクエリプランナの拡張により、テーブル・パーティショニング時の性能が大幅に向上します。

カラム単位の圧縮機能カラム単位で圧縮アルゴリズムや圧縮レベルを選択可能になりました。

例えば普段はほとんど参照しないカラムは高圧縮に設定するなど、カラム毎に圧縮レベル

の設定などが可能です。この機能をうまく活用することにより、ストレージの利用効率を

向上させることができます。

Oracle関数への対応が拡張最新バージョンでは、日付関数や文字列関数、算術関数など、20以上のOracle関数に対応しました。これにより、既存のクエリを極力書き

換えることなく、DBのマイグレーションやバッチ処理の最適化が可能となります。

バックアップ機能の強化Data Domain Boostに対応しました。これにより、

重複除外を行ってからバックアップができるよう

になり、バックアップがより高速になります。

拡張機能のパッケージ化PostGIS、pgcrypt、PL/Rなどの拡張機能が、新しいパッケージ・マネージャによりパッケージ化され、導入が容易になりました。

システム管理ツールのエンハンス従来のシステム管理ツールでは、各サーバ・リソースの利用率のモニタリングまででしたが、新しい管理ツールでは、Greenplumクラスタ全

体のモニタリングに加え、設定、スタート/停止などの操作も可能になりました。

カラム単位の圧縮機能

列A 列B 列C 列D

従来はテーブル単位の圧縮

最新バージョンでは、カラム単位で圧縮アルゴリズムや圧縮レベルを選択可能

マスターサーバマスターサーバ


重複除外重複除外重複除外重複除外

重複除外重複除外

Data Domain

DD Boostにより、重複除外プロセスの一部が各マスターサーバ、セグメントサーバに分散され、より高速あなバックアップが実現できます。


14 15

Greenplum DBの適用範囲

ここでは、Greenplum DBがどのような分野に適用できるかをお話しします。

Greenplum DBはデータウェアハウス用の製品ですので、当然データウェアハウ

スに適用できますが、それ以外にもデータベースの最適化という分野で多く利

用されてます。最適化の具体例としては、バッチ処理への適用です。

既存のシステムにおいて、データ量の増加にともないバッチ処理の長時間化

がシステムの課題となっているケースが多く見受けられます。既存のデータ

ベース・システムに対してCPUやメモリーを追加しても性能が伸びない。また、

チューニングをいくら実施しても性能が伸びない。このような状況はよくある

のではないでしょうか。

データ分析を業務に活用したいが、膨大な初期投資が掛かるため、ROIが計れずに着手できていない

インフラ整備に費用がかかり、分析業務への投資が回らない

Community Editionの発表

容量課金モデルでのライセンス

S/W提供による柔軟なH/W構成

汎用的なオープンテクノロジーの活用

DWH/分析/BI環境のスモールスタート

既存運用に則ったシステム構築

大容量データでの分析を行いたいが、うまく回せる技術基盤がない

大容量データを扱うためのシステムコストが膨大になってしまう

超並列処理(MPP)による高パフォーマンスのDB処理

高速データロード

スケールアウト構成による拡張性

大容量データに適したアプライアンス製品

予測不可能な将来のDWH環境活用に備えた、柔軟な拡張性をもったシステム構成

Oracle等商用RDBのバッチ処理　時間がかかっており、オンライン処理に影響を及ぼしている

商用RDB S/Wのコスト負荷

クエリ(大量データ検索など)のレスポンスが遅い

超並列処理(MPP)による高パフォーマンスのDB処理

高速データロード

容量課金モデルでのライセンス

S/W提供による柔軟なH/W構成

汎用的なオープンテクノロジーの活用

汎用的インターフェースの採用

バッチ処理をGreenplum環境に切り出すことによる既存DBシステムのシステム/コスト最適化

高パフォーマンスの参照系DB

課題 Greenplum DBの特徴 Greenplum DBの活用

ＨＷＤ

化適最ＢＤ

これはシェアードエブリシング・アーキテクチャにおいて多く見受けられる課題

です。バッチ処理の流れは、データのローディング、スキャン、テーブルの結合、

集計、最後にアンロードして返していく、というものです。シェアードエブリシ

ング・アーキテクチャの場合、これら全ての処理が1台のサーバの中で処理され

るため、全フェーズにおいてボトルネックが発生することが課題でした。

1.ロード 2.スキャン 3.結合 4.集約

Σ

5.アンロード

ノード#1 シェアードエブリシングアーキテクチャ

ノード#1 ノード#1 ノード#1 ノード#1

シリアル処理のため、全フェーズにてボトルネックが発生

次にシェアードナッシング・アーキテクチャの場合を見てみましょう。

他社のシェアードナッシング・アーキテクチャが採用している仕組みの場合、ス

キャン、結合、集約の各処理はパラレル化出来ていますが、データのロード、ア

ンロードの部分はマスターサーバがボトルネックとなります。

Σ

従来のMPP

Greenplum DB

1.ロード 2.スキャン 3.結合 4.集約 5.アンロード

ノード#1

ノード#1 ノード#1 ノード#1

ノード#２ノード#２ノード#２ノード#1

ノード#３ノード#３ノード#３

ノード#1 ノード#1 ノード#1

ノード#２ノード#２ノード#２


ノード#1

ノード#２

ノード#３

ノード#1

ノード#２

ノード#３

ノード#ｎノード#ｎノード#ｎノード#ｎノード#ｎ

これに対してGreenplum DBは、ロードもアンロードもパラレル化できますので、

全フェーズにおいてパラレル処理が可能です。加えて、セグメントサーバの追加に

より、パラレル度を容易に上げることができます。他製品と比べ、より大規模な

並列分散処理により高速にバッチ処理を実行することが可能なのです。

このすべてのフェーズにおけるパラレル化は、Hadoopの環境にも有効です。

Hadoopから、パラレルにデータを抜き出し、そのままスキャン、結合、集約、

アンロードまで、すべてパラレル処理をして、そのままHadoopにシームレスに

データを戻す。このようなことが可能です。

Σ

Greemplum DB

Hadoop 処理

Hadoop 処理

1.ロード 2.スキャン 3.結合 4.集約 5.アンロード

ノード#1 ノード#1 ノード#1 ノード#1ノード#1

ノード#２ノード#２ノード#２


ノード#２

ノード#３

ノード#２

ノード#３

ノード#ｎノード#ｎノード#ｎノード#ｎノード#ｎ

ノード#1

ノード#２

ノード#３

ノード#ｎ

ノード#1

ノード#２

ノード#３

ノード#ｎ

他システムとのパラレル連携を機能強化

バッチ処理最適化の事例

バッチ処理にGreenplum DBを適用し、最適化に成功されたお客様事例をご紹

介します。このお客様は、他社のデータベース・システムでCRM/SFAを運用して

いました。全国の営業が、自分の顧客の販売履歴を確認できるというシステム

です。しかしながら、夜間のバッチ処理が終わらず、毎朝営業に、どの顧客に訪

問すべきかというデータを、必要なタイミングで渡せなくなりつつありました。

データ量が増加する一方で、営業のシステム利用頻度も増加しており、現状の

仕組みでは処理が追いつかなくなってきていたのです。そこで、他の製品・ソ

リューションを検討され、様々な性能検証を交えて検討した結果、Greenplum

DBが採用されました。性能検証では、ロード性能、クエリ性能、多重アクセス

性能、バッチ処理などを実施しました。

既存のデータベース・システムは残しつつ、そのデータベースの参照用キャッ

Greenplum DBの利用イメージと、さまざまなニーズに応える提供形態

図20: Greenplum DBの適用範囲

図21: バッチ処理往年の課題

図22: バッチ処理フロー比較

図23: Greenplum DB 4.1によるバッチフロー

シュとしてGreenplum DBをDWHデータベースとして適用したのですが、その結

果バッチ処理は20倍高速化され、データのロード性能は103倍向上しました。

それ以外にも、非定型のクエリで27倍の高速化が確認されて、性能としては申

し分なく、最後は他のDWHデータベース製品とのコスト比較になりましたが、

Greenplum DBは他製品と比べて数分の一で済み、そのコストパフォーマンス

の高さが評価されて採用に至りました。

既存システムに対する負荷を、Greenplum DBを使いオフロードした結果、性能

面、コスト面でも高い効果が得られたという事例です。

データベース機能別役割

図24は、データベースの機能を分類し、Greenplum DBが得意な適用範囲を示

した表です。

OLTPデータベース、キャッシュ用のデータベース、バッチ処理用データベース。

そしてデータウェアハウス用のデータベースがあります。

機能 OLTP処理参照系処理の高速化

(キャッシュ) バッチ処理データ

ウェアハウス

主なユーザー •顧客•顧客窓口

•顧客•顧客窓口•アナリスト

-•マネジメント•アナリスト

サービス

•オンライントランザクション

•オンライン参照

•オンライン参照•レポーティング

(定型帳票/定型検索)

•集計•データマート作成

•レポーティング•データマイニング

/非定型検索

アクセス・プロファイル

•複数ユーザによる頻繁な検索と更新

•複数ユーザによる頻繁な検索

•バッチプロセスによるデータの集計とテーブル作成

•複数ユーザによる頻繁な検索と分析

ストアデータ最新のデータ直近 3ヶ月のデータ集計対象データ過去 3年間の長期データ

候補 DBOracle

DB2 GreenplumDB GreenplumDB GreenplumDB

適用範囲

Greenplum DBはOLTP系以外すべてに適用できます。図25でそれぞれ説明して

いきます。

OLTP系処理には、既存のOracleやDB2が適しています。一方、参照系にかかる

負荷をオフロードしたい場合には、キャッシュ的な役割で、トランザクション・

データベース用のサーバの前にキャッシュサーバを置き、これにクライアントか

らアクセスすることで、トランザクション・データベースに対する負荷を下げら

れます。ここのキャッシュ用データベースとして、Greenplum DBを適用し、参

照系処理の性能を上げることができます。

次は、トランザクション用データベースのバックエンドにGreenplum DBを置い

て、日中のトランザクション処理に関してはOracleなどで行い、夜間バッチ処理

はバッチ処理用のGreenplum DBにデータをロードして集計処理などを行い、

朝までにトランザクション・データベースにデータを戻す仕組みです。

最後はデータウェアハウスです。フロントのトランザクション・データベースか

らGreenplum DBにデータをロードし、BIツール経由でユーザがクエリを発行し

て分析やレポーティングを行うという一般的なデータウェアハウスの用途です。

このように、Greenplum DBはOLTP系以外の様々な用途で効果を発揮します。

トランザクション

キャッシュ


バッチ

データウェアハウス


OLTP処理参照系処理の

高速化(キャッシュ) バッチ処理データウェアハウス




図24: データベース機能別役割(1/2)

図25: データベース機能別役割(2/2)


16 17

Greenplum Data Computing Appliance

次はGreenplum DBの構築方法についてお話をします。Greenplum DBはソフト

ウェアとして提供されている製品で、ハードウェアに縛られません。既存のサー

バやストレージ、スイッチを使って、その上にソフトウェアだけを購入して構築

することが可能です。

一方、全てのサーバ、ストレージ、スイッチをGreenplum DBに最適化された

スペック、構成にして最大限高速化したい場合、アプライアンス製品を使うこ

とも可能です。Greenplum DBが組み込まれた形で提供されるハードウェア

一式がパッケージになった製品です。この選択肢があるというのも、他製品

とは異なる点です。このアプライアンス製品は、Greenplum Data Computing

Appliance（DCA）という名称で提供されています。

ハードウェアのスペックを簡単に紹介します。フルラックで、圧縮したデータで

144TB格納可能です。

モデルは大きく分けてフルラック、ハーフラック（72T B）、クオーターラック

(36TB)の3モデルを提供しています。このフルラックを複数台で構成すると、マ

ルチラック構成となります。

DCAの場合は、サーバ、ストレージ、スイッチの全てのハードウェアコンポーネ

ントとGreenplum DBが事前にすべてセットアップされているため、構築が非常

に簡単です。導入した段階でストレージのRAID設定、冗長化の仕組みの構築も

全て済んでいます。従ってDCAを導入するとすぐにデータウェアハウスの環境が

利用可能になります。

また、保守の面でも非常にメリットがあります。まずハードウェア、ソフトウェ

ア双方のサポートフローを一元化することができます。

システムの調子が悪いが、どこが悪いかわからないという場合には、サポート

センターに一報をいただければ、あとの解析はEMCが行わせていただくという

ものです。加えて、EMCではリモートでアプライアンスを常時接続監視すると

いうサービスを実施しています。これはEMCが従来からストレージ製品を中心

に提供しているサービスであり、その仕組みを使っていますので、非常に実績

が多く信頼性が高いものになります。

このアプライアンス版は、現時点では2つのモデルを用意しています。1つは先

ほど紹介したフルラックで144TB格納できるモデルで、ハードディスクにSAS

ドライブを使用しています。もう1つはハイキャパシティモデルです。こちらは

SATAディスクを使っており、フルラックに496TB格納できます。

また、GreenplumはSSDディスクにも対応しています。SSDを使って更にパ

フォーマンスを上げることも可能です。SSDを使ったハイパフォーマンス構成

はリファレンス構成として公開しています。

Greenplum DCA の豊富な選択肢

Greenplumはデータベースの機能だけを提供するに留まりません。BIツールや

今話題のHadoopがバンドルされたアプライアンス製品が今後リリースされる

予定です。図27にあるとおり、BIツールのSASが入った「SASハイパフォーマン

ス・アナリティクス on Greenplum DCA」、今話題のHadoopがすぐに利用できる

モデルとしては、「Greenplum HD Module」をそれぞれリリースする予定です。

これはハードウェアとGreenplum DBが構成されているアプライアンスの中に、

更にSASやHadoopのソフトウェアも設定された状態で出荷されるものです。

柔軟な拡張性を実現するハードとソフトの疎結合

次にシステム拡張について紹介します。データウェアハウスのアプライアンス

製品の多くはCPUとストレージを同時に強化した上位モデルへのリプレース

と言う方式が一般的です。一方、Greenplum DCAでは、二つの方向の拡張性を

持っています。

1つ目は、横方向に、容量だけを拡張するという方法です。セグメントサーバの

台数は増やさずに、ストレージを増設して容量を拡張していく方式です。2つ目

は、CPUパワーが必要な場合に、セグメントサーバを増設することによって性能

Greenplum DB環境構築における様々な選択肢Greenplum Data Computing Appliance

図26: Greenplum Data Computing Appliance 図27: Greenplum DCAの豊富な選択肢

容量

性能

バランスGreenplum DCA

コスト・パフォーマンスGreenplum

High Capacity DCA

パフォーマンスGreenplum

High Performanceリファレンス構成

Hadoop連携Greenplum HD Module

SAS連携SAS High -Performance

Analytics onGreenplum DCA

ロード性能 20TB/hスキャン性能 72GB/s

ラック容量最大496TB

コンピューティング

ストレージ

データベース

ネットワーク

GreenplumData Computing Appliance

を向上させる方法です。容量と性能、どちらにも柔軟に拡張することが可能で

あるため、必要最小限の追加投資で最適なシステム拡張を実現できます。

セグメント・サーバ 2台＋ストレージ・アレイ2台

柔軟な拡張性を実現するハードとソフトの疎結合

・システム負荷にあわせてシステム拡張部位を選択可能・ソフトウェアとハードウェアの疎結合が実現する柔軟性・既存システムのリタイアが不要

容量

能性

CPU ディスク

CPU ディスク

セグメント・サーバ 2台

セグメント・サーバ 4台

CPU ディスク

CPU ディスク

CPU ディスク

CPU ディスク

CPU ディスク

CPU ディスク

ストレージ・アレイ増設による容量重視の拡張方式

サーバ増設による性能重視の拡張方式

システムのEnd-of-Lifeまで続くコスト削減効果

最後はシステムのリタイアの時の話です。

Greenplum DBは、全てコモディティ・ハードウェアで構成されていますので、

不要になったハードウェアを様々な用途に再利用が可能です。インタコネクト

は、一般的なイーサネットスイッチなので通常のスイッチとして使え、セグメン

トサーバもマスターサーバも、例えばファイルサーバやWebサーバ、ファイアー

ウォールなどの用途に使えます。それぞれのハードウェアの寿命が来るまで、無

駄なく利用が可能なのです。

システムの End-of-Life まで続くコスト削減効果・専用DWHシステムの場合　_ リタイアするシステムは、DWHシステムとしてのみ活用可能　　 ex.開発機、検証機

・ GreenplumDBの場合　_ リタイアするシステムは、コモディティ製品の組み合わせのため、　　多様な用途に転用可能　　 ex.開発機、検証機、ファイル・サーバ、ウェブ・サーバ etc

インタコネクト

リタイア

リタイア

CPU ディスク

CPU ディスク

CPU ディスク

CPU ディスク

CPU ディスク

CPU ディスク

検証用DWH

CPU ディスク

スイッチ

ウェブ・サーバ

CPU ディスク

ファイル・サーバ

図28: 柔軟な拡張性を実現するハードとソフトの疎結合

図29: システムのEnd-of-Lifeまで続くコスト削減効果


18 19

Hadoopがなぜ注目されているのか？

Hadoopについて少しご紹介しましょう。既にご存知の方にはおさらいになり

ますが、Hadoopは、元々はGoogle Labで生み出された分散処理の考え方が

ベースになっています。それをJavaで実装し、オープンソースにより提供されて

いるものがApache Hadoopです。これによりビッグデータ時代の超大容量な非

構造、構造化含めたデータの高速な処理が可能になりました。

ビザ・インターナショナル社の例では、700億トランザクションログの処理に

約1か月掛かっていたのが、Hadoopに移行することにより13分に短縮できまし

た。別の例では、ニューヨーク・タイムズ社が、今まで蓄積されていた、TIFF形

式で保管していた13TBに登る記事データをPDF化するという処理をAmazon

Webサービス上のHadoopで処理したところ、非常に高速に、低予算で実現する

ことができました。

Ventana Researchという調査会社による、複数業界の数百社に対するHadoop

利用に関する調査によると、半分以上の企業が1度はHadoopの利用を考えた

という結果があります。また94%のHadoop利用者が以前は不可能だった大規

模データ分析が可能になったと回答しています。

Hadoopの先進利用ユーザとして有名な企業は、Yahoo、Facebookなどがあり

ます。2009年には、ClouderaというApache Hadoopの商用サポートを提供す

るベンダーが出てきました。このような有力企業によるHadoopの採用が進

み、現在のようなビッグデータ時代が到来したと言えます。

Hadoopに適合する処理と言うのは、対象データはTB（テラバイト）からPB（ペ

タバイト）に至る大規模なデータで、分野はバッチ処理です。基本的に適用分

野というのはGreenplum MRでもApache Hadoopでも大きく変わりません。

Apache Hadoopはリアルタイム性を求められるトランザクション処理には向い

Greenplum DBとGreenplum MRは異なる製品で、Greenplum MRは、Greenplum版のHadoopディストリビューションです。DBはGreenplumの中核製品ですが、

Greenplum MRを使うのにGreenplum DBは必須ではなく、Greenplum MRは単体で利用できる製品です。ここからは、次世代のHadoopとして注目されている

Greenplum MRについて、その技術概要を紹介します。

Greenplum MR 技術概要

徹底解説その２ビッグデータ活用でビジネス変革を実現企業向け次世代Hadoopソリューション Greenplum MR

ていませんが、それはGreenplum MRでも同様です。

具体的には、ログ解析やレコメンデーションのシステム、Web系であれば検索

のインデックス作成、BI分野であればデータマイニングなどのさまざまな利用

例があります。

そもそもHadoopとは？

Greenplum MRの説明に入る前に、Hadoopの仕組みについて簡単に説明します。

Hadoopは大きく2つのコンポーネントから構成されています。まず１つはデー

タをためるためのHDFS(Hadoop Distributed File System)という分散ファイル

システムです。Hadoopの大きな特徴は、ためるだけでなく加工もできるという

点ですが、そのためのフレームワークとしてMapReduceがあります。従来は、

データをためる部分にNASなどの専用ストレージ、あるいはファイルサーバな

どを使い、データの加工や集計には、更に別のサーバを用意して処理を行うの

が一般的でした。このため、膨大な非構造化データをストレージから加工や

集計を行うサーバに読み込む処理がボトルネックとなり、多大な時間を要して

いました。

一方Hadoopは、ためたその場でMapReduceによる分散処理ができるというの

が強みです。データをためる部分と加工する部分が1か所に同居できる、という

点が今までの環境とは大きく異なる点です。

例えば、大量のTIFF画像をPDFに変換する際も、TIFF画像をためている場所で

変換処理が行えるのです。

図30: Hadoopの利用例図31: Hadoopの仕組み

Greenplum MR – Hadoopディストリビューション

Greenplum DBとGreenplum MRは大きく構造化データと非構造化データとい

う点で棲み分けをしています。もちろん対象が重複するところもありますが、

構造化データのためのGreenplum DB、非構造化データのためのGreenplum

MRという位置付けです。

Greenplum MRは、2011年5月に発売されたGreenplum版のHadoopディストリ

ビューションです。

Apache Hadoopと100%のインターフェースの互換性を保ちつつ、更に高速性・

信頼性・管理性を増したというのがGreenplum MRの特徴です。

Greenplum MR スタック

Greenplum MRに含まれているコンポーネントを示したのが図33になります。

Hadoopの中心となるHDFSとMapReduceに加えて、Pig、Hive、HBaseなどのコ

ンポーネントも提供されています。加えて監視管理のための機能、運用を容易

にするボリューム管理の機能やNFSアクセスの機能など、Greenplum MRで追

加されているコンポーネントも含まれています。これらはApache Hadoop の中

にはなく、独自にEMCが提供しているモジュールです。

Greenplum MR の強み

オープンソースのApache Hadoopではなく、Greenplum MRを使うメリットを改

めて整理します。

まず第1点目は非常に高速であることです。Apache Hadoopと比べて2-5倍の

パフォーマンスを発揮します。Apache HadoopはJava言語で書かれています

が、Greenplum MRはC/C++言語によりコアコンポーネントが書き直されてお

り、Javaのガベージコレクションがありません。これにより高速な処理を実現し

ています。

2つ目は高い信頼性です。Apache Hadoopでは、ネームノード、JobTracker

の部分が単一障害点になっていました。Greenplum MRではネームノードも

JobTrackerも標準で冗長化される仕組みを持っています。これにより単一障害

点の課題を解決しています。

3点目は使いやすさの点です。先ほど監視管理機能のモジュールを持っている

というのを紹介しましたが、それ以外にもNFSマウントができるなどの改良を

加えています。これまでは、例えばWebサーバが書き出すログをHadoopで分析

する場合、書き出されたログ・データをHadoopのHDFSに転送して処理をして

いました。これに対し、Greenplum MRではNFSマウントが可能ですので、Web

サーバのログの書き出し先をGreenplum MRのファイルシステムに設定するこ

とができます。こうすることでログが書き出された時点でHadoop上に格納さ

れているため、すぐに処理することができます。このような点が使いやすさを

向上しているポイントです。

更に、使いやすさを向上させているポイントは、Greenplum DBと組み合わせて

利用可能な点です。Greenplum DBはHadoopとの連携ができるようになってい

るので、Greenplum DBからHadoopのHDFS上のデータを取り出してクエリを実

行し、分析をかけることができるのです。

ここからは、Greenplum MRが持つ優位性を更に掘り下げて紹介します。

図32: Greenplum DBとGreenplum HDの棲み分け図33: Greenplum MRスタック

MapR

MapR’s Lockless Storage ServicesTM

Data Placement Control Local Mirroring

Mirroring and SnapshotsMapR Volumes

MapR’s High Performance MapReduce

Direct ShuffleTM

Distributed NameNode HATM

JobTracker HA Direct Access NFSTM

MapRHeatmapTM

Mahout Cascading NagoisIntegration

GangliaIntegration Flume

LDAP, NIS Integration

Quotas, Alerts, Alarms CLI, REST API

Direct Access NFSTM

Realtime Dataflows

Zookeeper

Hive Pig Oozie Sqoop HBase Whirr

EMC Greenplum MR スタック

Greenplum DB

Greenplum MR


20 21

Greenplum MR – 高速化

Greenplum MRではApache Hadoopと比べて性能向上が

図られています。

先に紹介した通り、Javaのオーバーヘッドを無くしたこと

に加え、各プロセスの再設計、最適化により高速化が図

られています。まず、データルーティングテーブルによる

ロック競合の除去、ステートマシンによるアプリケーショ

ンスレッド競合の除去、ロックおよびLinuxページキャッ

シュの不使用によるシャッフル処理の高速化などがあり

ます。

また、分散ネームノードとパラレルNFSマウントによるデータアクセスの効率

化、ビルトイン圧縮機能によるI/O処理の効率化などの機能によっても性能改

善が図られています。

では、Apache Hadoopと比べてどれくらいの性能差があるのでしょうか？

Greenplum MRとApache Hadoopのパフォーマンスの差について、性能ベンチ

マークの例をあげて紹介します。まず1つ目のグラフはReadとWriteのダイレク

トIOを比較した例、2つ目のグラフはソーティング処理を比較した例です。両者

とも条件を合わせるためサーバなどのハードウェアは同じ構成を使用していま

す。Readについては3倍強の性能差、Writeに至っては4倍以上の性能差が確認

できています。続いてTerasortを使ったベンチマーク結果です。3.5TBのデータ

をソーティングするのに掛かった時間を比較しています。こちらの例では3倍強

の性能差が確認できました。

Greenplum MR 性能ベンチマーク比較

MR

Greenplum MR – 信頼性向上

Greenplum MRはネームノードやJobTrackerの冗長化

などでApache Hadoopが持っていた単一障害点の課

題をクリアしているなど、企業が安心して利用するた

めに、様々な点で信頼性向上が図られています。

JobTrackerのHA化

先ほども触れたとおり、JobTrackerがHA化されています。JobTraçkerというの

はMapReduce部分のマスターサーバになります。これまではJobTrackerが停止

すると、すべてのMapReduce処理が止まってしまうというのが課題でした。こ

こをHA化することで信頼性が向上します。障害が発生してもジョブタスクは失

われずに処理を継続できます。

分散ネームノード

HDFSのメタ情報を管理するネームノードの部分については、各データノードが

メタデータを保持することで分散させてネームノード機能を構成しています。

これにより１つのノードサーバがダウンしても、他のノードが処理を継続するこ

とで、全体のシステムダウンやデータ喪失を防止し、HDFSへのファイルアクセ

スを継続することができます。

NFSゲートウエイのHA化

NFSゲートウエイもHA化されています。Greenplum MRではどのネームノードも

NFSゲートウエイとして機能し、NFSアクセス機能を提供することができます。

クライアントからはどのノード経由でも透過的にHDFS上のファイルにアクセス

でき、なおかつ負荷分散も可能です。

スナップショット機能による迅速なデータ復旧

データコピーを伴わない高速なスナップショット機能により、ユーザの誤操作

によるデータ損失を防止できます。

ミラーリング

HDFS上のデータのバックアップやリモートミラーリングによるDR構成なども可

能です。また、ローカルミラーを使った開発・テスト用データの移行も容易にな

ります。

図34: Greenplum MRの強み

Apache Hadoopの

2～5倍の

パフォーマンス

Apache Hadoop

に存在する

単一障害点を除去

システム管理機能の充実

運用コストの低減

Apache Hadoopとの

100%互換性

高い信頼性使いやすさ互換性高　速

既存資産の有効活用Greenplum DBを通して既存

システムのSQL資産やアプリ

接続をサポート

Greenplum DBの連携機能を使用

することでさらに…

図35: Greenplum MR 性能比較

Greenplum MR – 使いやすさ向上

ここでは、Greenplum MR の使いやすさについての優

位性を整理します。

まず第1にNFSによるダイレクトHDFSアクセスが可能

な点です。NFSによる複数同時アクセスによるランダム

Read/Writeが可能です。アプリケーションのデータの出力先として直接HDFS

を設定できます。

2つ目は圧縮機能です。Apache Hadoopの場合はアプリケーションコードから

圧縮機能を活用することができますが、Greenplum MRではファイルシステム

内部で圧縮機能を持っているので、アプリケーションからは意識せず透過的に

利用することが可能です。これはストレージ容量の削減とI/O性能の向上に寄

与しています。

3つ目はボリューム管理についての機能です。Greenplum MR では、Hadoopク

ラスタ上で「ボリューム」の概念を使った柔軟なデータの運用が可能です。ま

た、スナップショット、ミラー、データの複製などの機能も標準機能として提供

しています。

ボリュームという単位でHDFS上のファイルシステムを分割管理でき、そのボ

リュームごとにレプリケーション数設定、スナップショットの運用設定、ミラー

リング設定ができ、更にディスク使用量の上限設定（クォータ機能）、管理権限

設定も可能になっています。

このように、Apache Hadoopでは提供していない、HDFS上のボリューム管理の

機能が非常に充実しています。

これらの機能により、これまでのHadoopシステムの課題であったマルチテナン

トでの共用やバックアップについても強化がなされています。

マウントポイント: / （ルートボリューム）容量上限: 200TB管理権限: user1(full), user2(full)レプリケーション数: 3スナップショット: 3時間に1回ミラーリング: なし

マウントポイント: /mirrors/vol_emc

ボリュームA

ボリュームB

ボリュームC ミラー設定

Greenplum MR Hadoopクラスタ

マウントポイント: /vol_emc容量上限: 50TB管理権限: user2(full), user3(dump, modify)レプリケーション数: 2スナップショット: 1日に1回ミラーボリューム: /mirrors/vol_emc

4つ目はデータの格納先の物理的な配置をコントロールする機能です。これ

は、先程述べたボリューム機能と、サーバノードの物理的な配置を記述するト

ポロジ構成定義を組み合わせることにより実現します。図39を例にして説明す

ると、まずあらかじめノードが格納されているラックや、そのラック群が設置さ

れているデータセンターなどのシステムの物理構成をもとにトポロジというツ

リー構造を定義しておきます。そしてボリュームを例えば図中の/datacenter/

rack2というトポロジに関連づけると、そのボリュームのデータは/datacenter/

rack2を構成するサーバノードに限定して分散配置されます。このようにデータ

配置のコントロールが柔軟に行えるようになることで、CPUやI/Oなどのリソー

スを特定のデータ／サービスに占有で割り当てる構成も可能になりますし、障

害の影響範囲を限定することもできるようになります。

/datacenter1 /datacenter2

/rack1 /rack2 /rack1

/node1 /node2 /node3

/

/node1 /node2 /node3 /node1 /node2 /node3

ボリュームを/datacenter1/rack2に関連づけ

5つ目として使いやすい管理ツールがあります。独自に追加されたWebベース

管理コンソールにより、Hadoopシステムの「見える化」が可能です。

図36: Greenplum MR のHA構成

図37: NFSによるダイレクトHDFSアクセス

図38: ボリューム管理

図39: トポロジ構成定義

図40: Greenplum MRの管理コンソール


22 23

Greenplum DBとGreenplum MRの高速データ連携

先ほども紹介した通り、GreenplumファミリであるDBとMRは連携して運用が

可能です。

ここではGreenplum DBとMRを組み合わせてどのような使い方ができるのかを

簡単に紹介します。

Greenplum DBはApache Hadoop、Greenplum MRのどちらとも連携が可能です。

Greenplum DBとGreenplum MRの連携機能を利用すると、HDFSから直接

データをローディングしてGreenplum DBに格納することができ、なおかつ

Greenplum DBからGreenplum MRあるいはApache Hadoopに対してデータを

アンロード、すなわち書き出すことができます。Greenplum DBとGreenplum

MRもしくはApache Hadoopとの双方向のデータのやり取りが可能です。

Greenplum DBが持つHadoopとの連携機能は、単にデータのやりとりができ

るに留まりません。Greenplum DBの章で紹介したとおり、Greenplum DB は、

HadoopのHDFS上のファイルを外部表として扱うことができるため、SQLを介

して直接Hadoopにあるデータの処理が可能です。また、Hadoopユーザであれ

ばMapReduceを使い、Greenplum DBから持ってきたデータを入力として並列

処理することもできます。 HadoopのデータノードとGreenplumセグメントサー

バが直接パラレルにやりとりすることによって、Greenplum DBのマスターサー

バを経由せず、なおかつHadoopのネームノードも経由しないで、並列化された

高速なデータのロード、アンロードが可能です。

Greenplum DBと Hadoopの高速データ連携

GreenplumDB/Hadoop連携 - 4パターン-

Greenplum DBとGreenplum MR（またはApache Hadoop）との連携は、データ

のロード・アンロードを使った連携だけでなく、Greenplum DB側からHDFSに

対してアクセスする方法として、データのロードを行わず、参照のみ行うという

ことも可能です。どのような仕組みで実現しているかを紹介します。

図42と図43に、Greenplum DBとHadoopの連携4パターンを示しています。

図42がHDFSからGreenplum DBにデータを格納している方法です。Greenplum

DBの外部表機能を使っています。外部表の中身は、HadoopのHDFSファイル

を指定しています。これにより、SQLでテーブル（外部表）にアクセスすること

で、実はHDFS上のデータにアクセスできるというのがポイントです。HDFSか

らGreenplum DB上に格納したい場合は、外部表の中身をGreenplum DB上の

テーブルにINSERTすることで可能です。あるいは、HDFS上の外部表のデータ

をGreenplum DB上に新規テーブルを作成(CREATE TABLE)して流し込むことも

可能です。

HDFSデータをGP DBへロード1

HadoopからGP DBの既存テーブルへ追加

HDFSデータをGP DBへロード2

Hadoopから GP DBの新規テーブルへロード

GP DBでのコマンド実行例INSERT INTO fact0 SELECT * FROMext_tab_hdfs_data ;

GP DBでのコマンド実行例CREATE TABLE new_fact0 (like fact0) AS SELECT * FROM ext_tab_hdfs_data;

GP DBマスター GP DBマスター

GP DBセグメント




HDFSデータノード




HDFSネームノード


3番目のパターンは、HDFSのデータをGreenplum DB上に保存せずに、クエリ結

果としてユーザに返すという方法です。 SELECT * FROM ext_dta_hdf_data (外

部表 ) によって、データノードからセグメントサーバに送られたデータはDBの

テーブルとして解釈され、クエリの結果はGreenplum DB上に保存されることな

くマスターサーバを経由してクライアントに返されます。

1度だけのデータアクセスをしたい場合はこの形式が効率的ですが、何度も

HDFSのデータにアクセスして処理したい場合、先ほど紹介した、一度データを

ローディングする手法が適しています。

外部表というのは基本的にHDFS上のどのファイルのどのカラムがどのデータ

型か、などを指定して、通常のSQLのSELECTによりアクセスができますが、外

部にあるものですから、直接INSERT、UPDATE、DELETEすることができませ

ん。このような処理をしたい場合は、一度データをGreenplum DB上に格納す

る必要があります。つまりGreenplum DB上にロードして、処理を行う形になり

ます。

Greenplum DBとGreenplum MRの連携による、更に効果的なビッグデータ分析

図41: Greenplum DBとHadoopのデータ連携

図42: Greenplum DBとHadoopのデータ連携 4パターン（１）

そして、4番目のアンロードというのは、1番目、2番目の逆の処理になります。

Greenplum DBからHDFSに対してデータを戻す方式です。これも外部表の機能

ですが、このケースでは書き込み可能な外部表の定義を行っています。SELECT

* FROM fact0 によりGreenplum DB上のデータを抽出した結果を、INSERTで外

部表であるext_data_hdf_dataすなわちHDFSにアンロードするというパター

ンです。

HDFSデータに対するクエリ

HadoopからGP DBセグメントとGP DBマスター

を経てクライアントへ

GP DBからHDFSへアンロード

GP DBのテーブルからHadoopへ追加

GP DBでのコマンド実行例SELECT * FROM ext_tab_hdfs_data ;

GP DBでのコマンド実行例INSERT INTO ext_tab_hdfs_dataSELECT * FROM fact0 ;

GP DBマスター GP DBマスター











Greenplum MR/BIツールとの連携例

これまでお話しした内容をふまえ、G r e e n p l u m D Bの連携機能を使った

Greenplum MRやBIツールとの連携イメージについて紹介します。

データソースとして、データベースのデータやログなどのような構造化データ

については、データウェアハウスであるGreenplum DBを使って処理を行いま

す。加えて、ツイッターのつぶやきのテキストのような非構造化データや、音

声データ、画像データ、動画などの非構造化データなどは、まずはGreenplum

MRにため込み、そこで非構造化データを処理して構造化データに変えて、そ

れをGreenplum DBに流し込みます。そこから先は、従来からある一般的なBI

ツールを使い、マイニングやレポーティングなどの分析を行うという形です。こ

うすることで、従来は利用されていなかった多様なデータを取り込み、さらに

Greenplum DBのスケーラブルな処理能力を生かして大容量の生のデータを分

析対象とすることで、今まで出来なかったようなデータ分析が可能になります。

ユーザ

BIツール

データソース

DB ログテキストウェブ

SAS

Cognos JasperSoft

MicroStrategyレポーティング・分析環境の提供GreenplumDBへのSQLアクセスBIツールへのJDBC/ODBC接続

SQLの高速分散処理ワークロード管理機能による多重クエリ処理 Hadoopとのパラレルデータ連携

データソースからのデータのロード MapReduceによる高速分散処理

GreenplumDBとのデータ連携データソースからの非構造化/構造化データのロード

・高速パラレルロード・アンロード・BIツールからのGreenplum MR上への透過的アクセス・BIツールからの大量アクセス時の安定稼働

Greenplum DB

Greenplum MR

例えば音声データであれば、音声認識アルゴリズムを使い、それを全部テキス

トデータに変換します。さらに変換されたテキストデータの分析をして、集計

をして構造化データに変えていきます。これらの処理をHadoop上で行い、結

果をGreenplum DBに格納します。その先はBIツールを使い分析をかけてゆく、

といった連携ができるのではないでしょうか。

Greenplum

MR

Greenplum

DB

Hadoopはデータをためるのは簡単なのですが、ユーザがHadoopのプログラ

ミングインターフェースを使ってそのデータを加工したり分析を行うことはハー

ドルが高く、Apache Hadoop自身ですぐに解決はできません。それに対して、

Greenplum DBとGreenplum MRのシームレスな連携機能を利用することによ

り、ユーザは慣れ親しんだSQLで分析ロジックを記述したり既存のアプリケー

ションを接続したりできるという点が、Greenplumソリューションの優位性です。

最後に

データベースのような構造化データはこれまでどおりGreenplum DB上で処理

を行い、非構造化データについてはGreenplum MRで処理を行ってGreenplum

DBに取り込んでいく。構造化データも非構造化データも含めてGreenplumファ

ミリで総合的に扱ってゆくというアプローチが、今後ますます大きくなるビッ

グデータを分析・活用していくための最良の戦略であるとEMCは考えています。

図43: Greenplum DBとHadoopのデータ連携 4パターン（２）

図44: BIツールとの連携

図45: Greenplum DBとGreenplum MRの連携イメージ

Documents

Greenplum DB / Greenplum MR - Dell EMC Japan DB / Greenplum MR 徹底解説 Greenplum DB / Greenplum MR 徹底解説 2 3 バッチ処理・データ解析における汎用RDBMSの課題