なんかClouderaが出したらしい．Hiveと違ってMapReduceをやらず，独自のクエリエンジンを使っている．場合によっては10x以上速くなるらしい．GoogleのDremelに触発されて2年かけて作ってたらしい．
Frontend / Backendのサーバが2種類．FrontendがBeeswax経由でWebから叩けたりする．BackendはHDFSとかのデータノード上でクエリとかを実行するやつだと思われる(2.の実行エンジン辺り？)．
主要なディレクトリはcommon, be(backend), fe(fronend)の3つ．
※ Thriftとかを実行して必要なソースを全部揃えてないので，確証がないので注意！
ThriftのIDLが入っている．ImpalaはThriftべったりなコードになっていて，IDLで定義されているデータがサーバ周りではそこかしこに出てくる．気になる人は生成しましょう
これはJavaで書かれている．SQLのパーサやスキャナのbison/flexつき．なんでこれがJavaかというと，おそらくHiveとかをライブラリとして使いたいからだと思われる．
feのエントリポイント．Frontend.javaがコアで，ここからクエリのオペレーションの解析やプランナを呼び出している(Hiveとかがライブラリでどこまで出来るのか詳しくないので，なんでこれをC++で実装してないのかは謎．誰か教えてください)． fe/src/main/java/com/cloudera/impala/analysisにたくさんのExprを解析するためのクラス群がたまっている．
common/thrift/ImpalaPlanService.thriftを使うと，多分このFrontendを単独で動かすことが出来る．
これはC++で書かれている．
これらがサーバの本体．一つのサーバでFrontendとBackendの両方のAPIを持ってる(上のfeディレクトリがなんでfeという名前なのかは正直分かってない)．Frontend/BackendのどちらもThriftサーバである．
impala-serverはサーバ起動時にfe/src/main/java/com/cloudera/impala/service/JniFrontend.java(Frontend.javaのJNIラッパー)を生成するというアプローチを取っていて，普通に使う分には外部にPlanServiceを別途立ち上げる必要は無い．
各クエリの表現が実装されている．各ExprにCodegenメソッドがあるので，そこでLLVMを使って頑張る．
アグリゲーションとか，その辺の操作周りのクラスが入っている．操作によってはJITとかする．ここにもCodegenとかあって，正直この辺りimpalaがどこまでLLVMに依存しているのかまだ分かってない．
HBaseの読み込みはJNIで，HDFSは多分libhdfs．
スケジューラとか入っている．Coodinatorが分散処理する時とかに多分使う．
ユーティリティとか．
- どこからかQuery投げる
- BE(C++)が受ける
- FE(Java)にクエリを解析するため投げる
- BE(C++)でクエリを実行 with LLVM (複数ノードであれば，Coodinator経由で処理を分散して各ノードで実行．Dremelの影響を受けていると行っているが，この辺の分散処理はscatter/gatherみたいな感じ(Treeではない気がする))
- BE(C++)がHDFS/HBaseからデータを取ってきて処理実行
- 結果を返す
みたいな感じな気がする．
クエリを投げると中でそのクエリに対応したidと状態が作られる．通常ではクエリのidが返され，クライアントはそのidを使って再度データのフェッチとかのリクエストを投げる．中ではidと状態のマップを持ってるので，そのまま返せば良い．これは多分，でかいデータだと本当に何秒かかるか分からんので，まぁよくあるAPI．sync用のAPIもあった気がする．
ここでHighになっているメモリ使用量を制限出来ない問題．いわゆるでかいデータでjoinとか使用とすると際限なくメモリ食いまくりますよ，ということなのでfixされるまで注意
- Planner周りのソース真面目に読む
- Coodinator周りのソース真面目に読む
- クエリ実行部分のソース真面目に読む
- その前にHiveのソース真面目に読む