/home/by-natures/dev*

データ界隈で働くエンジニアとしての技術的なメモと、たまに普通の日記。

Greenplum Database の紹介

こんにちは、天丼です。Greenplum

先日書いた英検についてですが、2次試験は見事に爆死してきたので、次回はちゃんと準備をして臨みたいとおもいます。日本人女性(恐らく50代)の面接官だったのですが、発音に抑揚が無く声も小さくて… 思わず「I can't understand your English.」と口走ってしまったので、attitudeは最低点かもしれないというネタだけは残してきました。

 

今日は、Greenplum というデータベース(※)についての簡単なご紹介と、セミナーへ参加してきたのでその情報を記載したいと思います。間違いや付け加えたい事項があれば、是非コメントください!

(※ 正確には Greenplum Database のことを差しますが、データベース以外はあまり触れないので、基本的には Greenplum と略記します。)

Greenplum Databaseとは

テラバイトからペタバイト規模のビッグデータを、今までのRDBMSより高速に扱うことができるデータベースとのこと。Greenplum社が2003年に設立され、2010年にEMC社が買収する形で、現在はEMC社の一部門としてGreenplumが存在するようです(http://www.greenplum.com/about-us)。

技術的にはPostgreSQLを元にしており、shared-nothing MPP architecture(MPP=Massively Parallel Processing) によって大量のデータを高速に扱うことに成功しているようです。端的に表すと下図のような感じ。

[caption id="" align="aligncenter" width="528" caption="出典:東京エレクトロンデバイス株式会社 「EMC Greenplum Databaseの特長」 http://cn.teldevice.co.jp/product/detail/greenplum_database/feature"]Greenplum 概要[/caption]

マスター・ホストと、セグメント・ホストというのがありますが、マスターがいわゆる命令系統、セグメント・ホストが、それぞれ担当のデータを保持し、マスターからの要求に応じてクエリを実行するといった役割分担です。

ここでデータは、テーブルごとに特定のカラムのハッシュ値で一意に定められるので、各セグメント・ホスト間では共有するデータがありません。不整合が発生しないことを保障し、不整合チェックに関するオーバーヘッドを回避し、並列実行時の効率を上げることができます。

一番下の外部ソースの部分ですが、これはデータのロードに関しては、マスター・ホストを介さずとも、各セグメント・ホストへ直接ロードさせることが出来るので、非常に高速だというのです。なんでも、Scatter/Gather Streaming technology を使っているのだとか。

知識不足でイマイチ理解できないのですが、Scatter / Gather というのが、バラバラのデータを一つにまとめて送りつける(適当でスミマセン!)技術のようなので、行に対するセグメント・ホストが一意に定まるという点から、マスター・ホストを介すような複雑な処理が要らず、与えられたデータを読み込んで、どのセグメント・ホストにロードさせるのかを考えるだけでよい…のかもしれません。誰か分かれば教えてください。

主な用途

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

セミナーでは「OLTP処理もできるが、その点では他のRDBMSとは差別化ができない」と言っていました。参照中心のデータベースなので、差別化する必要もないかと思いますが。。

1日の終わりに、OLTPを担うRDBMSからデータをバッチでGreenplumにまとめて入れて、DWHを構築…その後分析、みたいな使い方がよさそうですね。

販売形態

Community Edition は無料で利用できますが、商用利用はできず、セグメントも1つしか持てません。少し調べたところ、セグメント1つの状態で商用利用することができる、Single-node Edition なるものもあるようです。

しかし基本的にはセグメントに寄らない容量課金で、1.0TBあたり300万円とのこと。

アプライアンスは基本(1/4ラック)で5000万円、1/4ラック追加ごとに4000万円とのこと。この辺の金額が年間辺りなのか、アプライアンスはライセンス費が含まれているのかどうかなど、細かいことは分かりませんでした。個別に問い合わせほしいってことなんでしょう。

Greenplumのメリット

そんなGreenplumのメリット。EMC社の説明から引っ張ってきましょう。

  • Massively Parallel Processing Architecture for Loading and Query Processing MPPだからクエリもロードも早いよってことですね。
  • Polymorphic Data Storage-MultiStorage/SSD Support 色んなストレージ技術が使えるよって言ってますね。色んな圧縮形式に対応していることと、カラムストアとローストアの両方が使えるのが特筆すべき点でしょうか。カラムストアにすれば圧縮も効くし、Greenplum の主な用途である分析時に、集計関数のパフォーマンスが上がるのではないでしょうか。
  • Multi-level Partitioning with Dynamic Partitioning Elimination 色んなレベルのパーティションの切り方が出来るよって言ってますね。 ここでいうパーティションというのが、各セグメント・ホスト内で物理的に更に細かく分けることが出来るのですが、その単位のことを差します。僕が今使っているのはシンプルに Date だけですが、日にちが違えば違うテーブルになると言った具合です。この Date に Month を加えることも出来るのが "Multi-level" の部分でしょう。 PostgreSQLでもパーティション機能はあるので、"Multi-level" が Greenplum としてのメリットなのか、そもそもセグメントを切った後で更に今まで通りパーティションも使えるよ、というのがメリットなのか、その辺りがよく分からないです。

ここに載っていないメリットとして、EMC社から頂いたパンフレットからいくつか抜粋。

  • スモールスタート shared-nothing なのに、後からいくらでもセグメントを追加できるのは凄い。実際にセミナーでデモを見せてもらいましたが、セグメントの追加はマスター・ホストの 設定ファイルを書き変えて、Greenplumを再起動するだけです。 もちろんハッシュ値が偏ったままなので、これを再配分するバッチも用意されていますが、こちらもコマンド一発です(ちょっと時間はかかりますが)。
  • コモディティ・ハードウェア 専用ハードウェアを必要とせず、 LinuxOSが稼働する環境であれば動かせるようにしようというのが Greenplum のそもそもの目的なんだとか。

個人的には、簡単に使えるというのを一つ付け加えておきたいです。PostgreSQLを元に作られているため、設定ファイルに馴染みがありますし、ハッシュのキーとするカラムの指定や、パーティションの指定などがSQL(?)で簡単に行え、その状況は例えば pgAdmin で普通に閲覧することができるのは大きな魅力だと思います(PostgreSQLを元に作られているだけのことはありますね)。

他にもいくつかあったんですが、Greenplum Database と外部環境の接続についての話が多いので割愛。その中でも Hadoop に関する話は面白そうなのですが…あまりに僕が Hadoop に明るくないため、今回は割愛。。(本だけは買ってあるというやる気アピールだけして逃げる。。)

Greenplumのデメリット

デメリットなど製品紹介資料に書いてあるはずもなく、ここは完全に僕の経験と感想になってしまうのですが…。

初期設定値でも十分に早い Greenplum ですが、メモリをあまり使っていなかったり、CPUリソースが余っていたりすると、リソースをフルで使わせてスループットをもっと上げたくなるのが親心でしょう。このときに、どの個所をみてチューニングすればよいのかが分かりづらいというのが一つデメリットとして挙げられます。

大抵はPostgreSQLと共通のパラメータなのですが、それをPostgreSQLと同じ要領でチューニングすればよいのかも分かりませんし、SQLのリソースに対する挙動もPostgreSQLとGreenplumでは異なるので、SQLのチューニングだけでも勘所が掴みづらいです。

そんな方のために、EMC社ではアプライアンス・ソリューションとして Greenplum 用に最適化したハードウェア(DELL)に Greenplum を導入した状態で販売を行っています。コモディティ・ハードウェアを謳っているのに、アプライアンスも用意しているなんて、なかなかに悔しい売り方をしてくれますね(^_^;

(Community Edition だと1つのサーバ内でマスタと複数セグメントを共存させることになるので、リソース管理が非常に複雑になってしまいます。この辺が僕が感じている、Greenplum に対するチューニングの複雑さの原因かもしれません。)

それでもSQLのチューニングなどはGreenplum用に行う必要がある気もしますが、Greenplum的には「今までのインデックスやパーティショニングなどの小手先のチューニングも重要だが、セグメントを分割して並列処理させることで処理が高速化できる」というスタンスのようなので、Greenplumにおける細かいSQLの最適化や、よいインデックスの張り方などはあまり調査されないかもしれません。

Greenplumの今後

Greenplum Data Scientist Community(データベースだけではない)Greenplum の大きな目標として、セミナーでは " Greenplum is not just a database. " という標語が掲げられました。「データベースを用いて、本当にしたいことは何だろうか」という点から、データベースの一歩その先を考えるということのようです。

彼らが考えている、データベースのその先とは、次のようなものでした。

  1. Data Availability
  2. Distributed Computing
  3. Analytics Tools
  4. Data Scientist Availability
  5. Org. Alignment

下にいけばいくほど、データベースが提供する価値が大きくなり、その分そこに到達するまでに時間がかかるだろう、ということでした。

メモしたはいいものの、細かい説明は無かったので詳細は分からないのですが…。データが十全に保持されれば、それを分散させて早く処理させたいし、処理が早くなればデータを時間を掛けて分析する余裕が生まれ、(4. はよく分からないw)、最終的に組織を最適化するのにデータベースは役立つだろう、という感じでしょうか。

今はHadoopとの連携強化に力を入れているようで、上のステップで言えば 3. にあたる時期なのでしょう。更に、2013年春にリリースが予定されている Greenplum Database (バージョンは未定、4.2.3 か 4.5 か 5.0 とのこと。。)では、Analytics Tools を強化すべく、以下の機能がリリースされるそうです:

個人的に嬉しいのが、プランナーの刷新です。今までGreenplumのプランナーはPostgreSQL用のものを少しずつ拡張していたそうですが、アーキテクチャが異なるGreenplumでは、やはり限界なのだそうです。そこで次のリリースでは、一から構築したGreenplum専用のプランナーをリリースするとのこと。数年(セミナーでは5年って聞こえた気が…)掛けたプロジェクトだと言っていたので、相当凄いものが出てくるのではないかと期待しています。先ほど述べたデメリットも、かなり軽減されるのではないでしょうか。

他には、時系列クエリへの対応、日本語ドキュメントの充実化、キャッシュ技術の向上、1000や10000セグメントに分割した場合に問題となるオーバーヘッドの軽減(そんなに分割すること自体がGreenplumとしても想定外らしいです)などが挙がっていました。

 

商用にはライセンスが必要となりますが、それ以外であればCommunity Editionで1サーバ内にマスター/セグメントを共存させることで、Greenplumに触れることができます。Community Edition でも非常に性能がよく、個人利用としても面白いプロダクトだと思いますので、興味があるかたは手元のサーバにインストールしてみてはどうでしょうか。