k4200’s notes and thoughts

Programmer side of k4200

Impalaのアーキテクチャを少し調べてみた

前回、Dremelの論文を読んで、分かる範囲で説明した。

さて、前回の記事を書いた後、BigQueryのホワイトペーパー (miyakawa_taku さんありがとうございます)を紹介されたので読んでみた。論文の要約+BigQueryの紹介と言った内容。

今回は、まずはそのホワイトペーパーの内容を少し紹介して、その後にImpalaのアーキテクチャにたどり着ければという感じ。

BigQueryのホワイトペーパーに書いてあること

Google BigQueryとは、データをアップロードしてそのデータに対してデータ分析が出来るというサービス。GoogleがDremelとして発表したシステムを外部向けにしたもの、らしい。お値段はこの辺。比較的お手頃という印象。

さて、ホワイトペーパーの中身について見ていく。

Dremelが速い理由

まずは、Dremelがなぜ速いのかという話題で、理由として以下の2つを挙げている。

以前ブログで書いた内容はそんなに的外れじゃなかったってことで良かった・・・

BigQueryとMapReduceとの比較

BigQueryはその名の通り、ビッグデータに対してクエリーを実行できる仕組み。言い換えると(テーブル構造の、定型の)データに対してクエリーを実行する事しかできない。その分高速。それに対して、MapReduceは、プログラマーが自由に処理を記述出来るので、非定型のデータを処理する場合や複雑な処理に特に向いている。あと、大量のデータを出力する処理にも。

ホワイトペーパーによると・・・

BigQueryを使うべき場面

  • ある条件にマッチしたレコードを探す場合
  • 色んな条件による集計が必要な場合
  • トライアンドエラーで色々解析処理をしたい場合

MapReduceを使うべき場面

OLAPとの比較

Relational OLAPはRDBMSベースのOLAP。ROLAPでは、(巨大なデータを実用的な時間で解析したい場合)解析・クエリーに使われるカラムに対して事前にインデックスを貼るが必要あるけど、クエリーの種類が増えるに従いインデックスも増えていき、元のデータサイズより大きなサイズのインデックスになる場合もある。

Multidimensional OLAP (MOLAP)の場合、BIエンジニアが(時間とお金をかけて)データキューブを作る必要がある。

どちらの場合も、実行する予定のクエリーを事前に決めておいて、それに対して何かの処理をしなきゃいけない。よって、アドホックにクエリーを実行したり、試行錯誤を繰り返す場合などには向かない。

Impalaのアーキテクチャ

概要

毎回回り道している気がするけど、今回こそImpalaの内容を。以前のブログでも書いたけど、こちらのページに色々な情報へのリンクがまとまっていた。

Impalaの説明とアーキテクチャの概要に関してはこちらのスライドがまとまっていた。10ページ以降。

内部構造

もう少し内部的な話をすると、以下のようになっている。

  • クライアントから受け取ったクエリー文字列をパース
  • パース結果はParseNode型(interfaceで、実体はParseNodeBaseクラスの各種サブクラス)として返される
    • ParseNodeは子要素を持ちTree構造になることもある
  • ParseNode.analyze()が意味解析(?)を実行し、その結果がAnalyzerクラスのインスタンスにセットされる
  • Planner.createPlanFragments が解析結果から ArrayList を作成する

この後、Coordinator に処理が移る、のかな(詳細はまだ読めてない)。

先ほどのリンク集から辿れるページに、いくつかのモジュールのソースコードに関する解説があったので、それらのリンクを貼っておく。

まとめ

ようやくImpalaまで辿りつけた。他の人と同じ所を説明しても仕方ないので、次回はクライアントからクエリーを受け取って ArrayList を作成する部分までのソースを読んでみる