Greenplumの高速性を支える大規模並列処理
もっとも単に安くDWHを使えるだけでは競合優位という面でもあまり差別化できない。現在のDWHに求められる最も重要な要素は"スピード"だ。Greenplumはノード間でディスクを共有しない"シェアードナッシング"による大規模並列処理を採用しており、高速性という点でも大きな優位点をもつ。
仲田氏の説明をもとに、もう少しこの並列処理について詳しく見ていこう。ビッグデータ時代においては、いかに大量の外部データを速く取り込めるかがDWH差別化のカギになる。ところが従来のマスターサーバとスレーブサーバ(EMCは"セグメントサーバ"と呼ぶ)という構成の場合、セグメントサーバのデータローディングがボトルネックになりやすい。このため、高速化を図るにはマスターサーバの数を増やすという"プッシュ型"の手法が取られがちだった。
Greenplumの場合、データソースからデータを取り込む際、セグメントサーバはマスターサーバにいちいち"お伺い"を立てる必要がない。つまりセグメントサーバが独自にデータを取り込むことができる"プル型"のイメージである。これは、個々のセグメントサーバに実装されているパラレルデータフローエンジンにより実現している。プル型方式であればアーキテクチャ的なボトルネックが生じにくく、仲田氏によれば「フルラックで1時間に10テラバイトのデータ処理が可能」だという。まさしくリニアなローディングがここに実現するというわけだ。
この並列処理の仕組みは、1億件を超えるような大量のデータソートを複雑なSQL文で行うような場合に威力を発揮する。アプリケーションからソート要求が来た場合、セグメントサーバは自分のストレージに格納されているデータのソートを開始する。もし、各セグメントサーバが個々にソート作業を完了させてから、マスターサーバに結果を戻し、それからマスターサーバがソート結果のマージを行い、アプリケーションに返す…というプロセスではパイプラインが途切れることになってしまう。そこでGreenplumの場合、アプリケーションの要求にあったソート結果があればセグメントサーバは随時それをマスターサーバに戻し、マスターサーバは各セグメントサーバから集まったデータを使ってソートを行い、アプリケーションに返す。この方式だとパイプラインが途切れることなくインコアで処理を行うことができ、大幅な高速化を図ることが可能になる。
