Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

ビッグデータ時代のDWHは「安さ」と「速さ」/EMC Greenplumのアーキテクチャ

edited by DB Online   2011/06/03 07:00

Greenplumの高速性を支える大規模並列処理

もっとも単に安くDWHを使えるだけでは競合優位という面でもあまり差別化できない。現在のDWHに求められる最も重要な要素は"スピード"だ。Greenplumはノード間でディスクを共有しない"シェアードナッシング"による大規模並列処理を採用しており、高速性という点でも大きな優位点をもつ。

仲田氏の説明をもとに、もう少しこの並列処理について詳しく見ていこう。ビッグデータ時代においては、いかに大量の外部データを速く取り込めるかがDWH差別化のカギになる。ところが従来のマスターサーバとスレーブサーバ(EMCは"セグメントサーバ"と呼ぶ)という構成の場合、セグメントサーバのデータローディングがボトルネックになりやすい。このため、高速化を図るにはマスターサーバの数を増やすという"プッシュ型"の手法が取られがちだった。

Greenplumの場合、データソースからデータを取り込む際、セグメントサーバはマスターサーバにいちいち"お伺い"を立てる必要がない。つまりセグメントサーバが独自にデータを取り込むことができる"プル型"のイメージである。これは、個々のセグメントサーバに実装されているパラレルデータフローエンジンにより実現している。プル型方式であればアーキテクチャ的なボトルネックが生じにくく、仲田氏によれば「フルラックで1時間に10テラバイトのデータ処理が可能」だという。まさしくリニアなローディングがここに実現するというわけだ。

Greenplumでは、各セグメントサーバに「パラレルデータフローエンジン」が実装されており、
クエリやデータの実行に関してマスターサーバに依存する必要がない。
高速データローディングはこのエンジンによって実現されている部分が大きい

この並列処理の仕組みは、1億件を超えるような大量のデータソートを複雑なSQL文で行うような場合に威力を発揮する。アプリケーションからソート要求が来た場合、セグメントサーバは自分のストレージに格納されているデータのソートを開始する。もし、各セグメントサーバが個々にソート作業を完了させてから、マスターサーバに結果を戻し、それからマスターサーバがソート結果のマージを行い、アプリケーションに返す…というプロセスではパイプラインが途切れることになってしまう。そこでGreenplumの場合、アプリケーションの要求にあったソート結果があればセグメントサーバは随時それをマスターサーバに戻し、マスターサーバは各セグメントサーバから集まったデータを使ってソートを行い、アプリケーションに返す。この方式だとパイプラインが途切れることなくインコアで処理を行うことができ、大幅な高速化を図ることが可能になる。


著者プロフィール

  • 五味明子(ゴミ アキコ)

    IT系出版社で編集者としてキャリアを積んだのち、2011年からフリーランスライターとして活動中。フィールドワークはオープンソース、クラウドコンピューティング、データアナリティクスなどエンタープライズITが中心で海外カンファレンスの取材が多い。 Twitter(@g3akk)やFacebook(...

バックナンバー

連載:DB Press

もっと読む

All contents copyright © 2007-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5