NetezzaとかRedshiftとかPrestoとかその辺の話

4日間のNetezza研修に行ってきたのでNetezzaのアーキテクチャについて書いてみる。

Netezzaの全体像はこんな感じです。

SMP hostというのがクエリを受け付けてparseして最適化してプランを作ります。SMP hostのDiskはDRBDで二重化されています。

プランはSnippetという単位になりそれが各SPUにばらまかれて並列処理されます。

各SPUでC++コードの生成、コンパイル、実行という処理を行いますが、2回目以降はコンパイル済みのオブジェクトコードがキャッシュされるので早くなります。

SPUはSnippet processing unitの略でCPU, FPGA, Memoryを持ちます。

FPGAで解凍処理や行、列の絞り込みを行うことによって性能向上をはかります。

CPUの仕事を減らしてハード側でなるべく処理させるという感じでしょうか。

テーブルを作るときに分散キーを設定するとそれに基づいてデータが分散します。ユーザIDのようなRDBでいう主キーを分散キーに設定すると良いようです。そうするとデータがちゃんと分散するだけでなく、joinのときもうまくいけばデータ移動する必要がないので早くなります。joinのキーと分散キーが一緒ならjoinするテーブル同士のデータが同じDiskにある可能性が高いですからね。

ちなみにログの日付を分散キーに設定するとデータは分散しますけど、select * from yyyymmdd=20150524のようなクエリがなげられたときに20150524のデータを持つ特定のSPUに処理が集中して並列処理できないので遅くなります。

Netezzaにはインデックスは無いですが、zone mapというものがあります。あと統計情報もあります。

zone mapは自動的に設定されるものです。Netezzaではデータは3MBのextentという単位で配置されるのですが、このextent毎に各カラムのmin, maxの情報を保持しておりこれがzone mapです。これによってアクセスする必要が無いextentが分かるので高速化できます。例えばextent 1でmin(userid)=100, max(userid)=200だったらselect * from user where userid=300というクエリがなげられたときにextent 1にアクセスする必要がありません。hiveのパーティションみたいなもんですかね。文字列型のカラムにはzone mapは作成されないです。

NetezzaはPostgresqlベースで作られていてpostmasterプロセスなども実際に動いています。ストレージ部分だけ変えているんだと思います。

MVCC型なのでvacuum的なものが必要でNetezzaの場合はgroomコマンドがそれに相当します。

なお研修後にWEB+DB PRESS Vol.78のRedshif特集を読み直したらほとんどNetezzaと同じアーキテクチャでした。

WEB+DB PRESS Vol.78

作者: WEB+DB PRESS編集部編,栗林健太郎,安詮院康広,山口良平,尾上忠輔,大川高志,坂本寛樹,青木峰郎,増井雄一郎,中島聡,江島健太郎,中島拓,柴田博志,伊藤直也,登尾徳誠,片桐崇,後藤秀宣,佐藤鉄平,近藤宇智朗,長野雅広,奥野幹也,渡邊恵太,A-Listers,家永英治,はまちや2,川添貴生,原田勝信,和島史典,城倉和孝,安達俊雄,Akira,川嶋賢一
出版社/メーカー: 技術評論社
発売日: 2013/12/21
メディア: 大型本
この商品を含むブログ (6件) を見る

ただBigQueryは違うっぽいです。BigQuery本をチラ見する限りマルチテナントがキーだとかクエリを数千core使って処理するとかあるので。

一方でPrestoには似ている気がします。並列DBの一般的なアーキテクチャなのかもしれません。

ちなみにPrestoの場合はバイトコードをそのままworkerに配布してディスクに書くこと無く実行するというモデルのようです。guavaのキャッシュライブラリを使ってキャッシュしているので2回目は早くなります。ExpressionCompilerが該当部分だと思います。

この辺Prestoは全部メモリ上で処理します。なので、でかいテーブルのjoinなんかでメモリに乗り切らない場合はエラーになります。Netezzaの場合はメモリに乗り切らない場合はspillしてdisk hash joinになります。またjoinで片方のテーブルが小さい場合はそれを全ノードにばらまいてjoinします。これがbroadcast joinです。これはNetezzaもPrestoも多分同じ挙動。

でかいテーブル同士のjoinをどうするのかがひとつのテーマっぽいです。
PrestoのMLにもそんなネタがながれてました。
https://groups.google.com/forum/#!topic/presto-users/4h4wYpp0VOs

この辺の並列DBに関して体系だった本があると良いのですが、無いようです。
一応下記がそれに相当するらしいのですが、2008年出版だし値段が2万円を超えている。。。