Dremelの論文読んで、Impalaのアーキテクチャも少し調べてみた
最近、趣味で検索エンジンみたいなの作ってるし、仕事でも大規模データを扱う話が増えてきた。初心者向け分散処理勉強会なんてのも有志で立ち上げて色々勉強中。
さて、ちょっと前にClouderaがImpalaなるものを出した。Googleが2010年に発表したDremelというシステムに関する論文にインスパイアされて作ったらしい。
勉強会のネタにもなるし、まずはDremelの論文を読んで分かる範囲で説明して、その後Impalaのアーキテクチャについて調べてみる。
（間違い等があればご指摘頂けると助かります）
Dremel論文
ポイント
大雑把にまとめちゃうと、ポイントは2つ。
- 列指向のデータ構造（= Columnar storage: Chapter 4, Figure 3）
- 木構造のサーバー群によるクエリー実行（= Multi-level serving tree: Chapter 6）
前者の利点だが、Columnar storageにする事により、行指向のデータ構造（Record oriented storage）に比べてMapReduceジョブは顕著に速くなる。さらに、Dremelの場合、行指向データに対するMRに比べて100倍以上高速。（Figure 10）
後者に関しては、クエリーの種類によって結果は異なるが、例えば論文中のQuery 3は、ツリーの深さを4段まで深くすることにより、2段の時に比べてスループットが1/6以下になっている。
Columnar storageはなんで速いの？
ColumnarがRecordに比べて速い理由は、（クエリーで対象となる列が少ない場合）ディスクから読み込むデータが少ないから（Figure 9）。列数が多くなると、Record形式のほうが速くなる。どの辺で逆転するかは場合によるけど、一般的には数十位だとか。
MapReduceと比べて速い理由が読んだだけだとよく分からなかった。
Figure 10を見ると、Columnarを使ったMRに比べてもDremelは数十倍速いんだけど、それの理由がよく分からなかった。Hadoopは全然詳しくないんだけど、MapReduceでもMulti-levelで処理するよね？Dremelが特定の処理（aggregationとか）に特化しているから？
その他特筆すべき所
Chapter 6の「Query Dispatcher」の所で説明しているように、Dremelは複数のエンドユーザーによって使われることを想定しているシステムなので、空いているサーバーに処理を振ったり、複数のサーバーで冗長性を持たせたりしている。詳しくは論文を参照。
あと、Figure 14に関してだけど、このクエリーの例で言うと分割されたデータ（tablets）の99%に対する処理は5秒以内に終わったが、残り1%が全体の足を引っ張っている。前述の冗長性によって、あまりに遅い処理はQuery Dispatcherが他のノードに回したりしているらしいけど、そもそも正確性が必要ないクエリーであれば、5%を捨てる事でスループットを向上させる事が出来る。
Impala
さて、Impalaのアーキテクチャについて調べてみる。日本語だとこちらのページにいろんな資料へのリンクがあって便利。Impalaの解説も簡単に書いてある。興味を持った点をいくつか引用。
そうだったのね。F1というのも時間があったら調べてみようと思う。
HiveQL、Hiveメタストアが利用可能。Hiveとの親和性が高い
Hiveって名前知ってる位で全く知らないので、これもちょっと勉強する必要があるかも。
その他感想
またまた上のページの話だけど、日本だとこういうのに関する情報を発信している人って片手で数えられる位みたいだし、イベントとか勉強会とかに色々参加してそういう詳しい人達から色々話を聞いてみたいなぁと思った。
