読者です 読者をやめる 読者になる 読者になる

夢とガラクタの集積場

落ちこぼれ三流エンジニアである管理人の夢想=『夢』と、潰えた夢=『ガラクタ』の集積場です。

Apache Drillの開発された背景とモデル、構造

こんにちは。

とりあえず前回のものだけではまだApacheDrillが何が何やらわからないため、
開発された背景や位置づけなども含めてまとめてみます。

1.Apache DrillProposalの内容

とりあえず、Apache DrillProposalの内容を要約して訳してみます。

概要

Apache DrillはGoogle Dremelをベースに開発された、巨大なデータに対して対話式に解析が可能な分散システムである。

提案

Apache DrillはGoogle Dremelをベースに、
幅広いクエリ言語/解析対象のデータセットに対応することを目指す。
かつ、入れ子構造になっているデータに対しても適した検索手段を提供する。
Apache Drillは最終的に10000のサーバ、ペタバイトクラスのデータ、兆単位のレコードに対して秒単位での検索を可能とすることを目指す。

背景

多くの組織ではバッチ処理、ストリーム処理、対話式解析等データを集約して解析/処理する必要がある。
ここ数年、OSSとしてバッチ処理Hadoop)、ストリーム処理(Apache S4、Storm)が公開された。
そんな中、2010年にGoogleから巨大データに対する対話式解析を行う分散システムである「Google Dremel」の論文が発表された。
現時点で、Google Dremelに対応し、広まったOSSプロダクトは存在しない。

必要となる根拠

大量に蓄積された様々なデータ(JSON、Avro、Protocol Buffers)に対する対話式の解析システムは下記のように大きなニーズを持つ。
上記のニーズはGoogle Dremelの登場によってより明確になった。

ここ数年、Googleの論文をベースにバッチ処理Hadoop)、ストリーム処理(Apache S4、Storm)がOSS化され、
数千もの企業で利用されるようになった。
だが、Hadoopは非常に大きなスループットを持つがレイテンシが大きい、
ストリーム処理はその時点のデータにしか対処できない等対話式の解析システムにはそぐわない。
Drillはその穴を埋めるために開発が開始された。

DremelはJSON、Avro、Protocol Buffersといった入れ子構造を持つデータに対して対応しているため、毎回データを正規化する必要が無い。
Drillも同様に上記の機能を保持する方針。

Drillは下記の4つの層/要素から構成される。

  • クエリ言語

ユーザからの入力を解析し、実行計画を構築する層。
まずはDremelの同様のSQLライクなクエリをサポートし、その後拡張する予定。

  • 低レイテンシ分散実行エンジン

クエリ言語レイヤで作成された実行計画を分散実行する層。
Google Dremel、Microsoft Dryad、Hyracks等をベースに作成される。

前述の通り。
だが、列ベースの処理と行ベースの処理両方をサポートする予定。

  • スケーラブルなデータソース

HDFSをはじめとした分散データソースと接続するレイヤ。

当初の目標

まずは詳細な要件とアーキテクチャを規定して、初期実装を完了させることが目標。
複数のストレージシステムに対応し得るAPIと、Dremelと似たクエリ言語をまずは作成する。

現在のステータス

詳細な要件とアーキテクチャは規定完了した。
現在は4つのコンポーネントApacheプロジェクト上で実装している。

・・・と、こんな感じでした。
外部IFとなるクエリ言語、データソースを様々なものに対応する・・・ということは、
独自のクエリエンジン、データソースアダプタについては比較的容易に作成できるということなんでしょうかね。

2.Apache Drillの構造

いくつか位置づけや構造についての図もあったのでここで見てみます。

ビッグデータ処理モデルでの比較

ビッグデータにはいくつか処理のモデルがありますが、
資料中ではバッチ処理、ストリーム処理に続く3つめの処理モデルとして「対話による解析」が
あげられていました。

ストリーム処理の「有向非巡回グラフ」が若干わかりにくいのですが、
ストリーム処理の構成要素・・・Apache S4であれば「Processing Element」、Stormであれば「Spout/Bolt」を
向きが定義され、起点と終点を定めて配置して利用する・・・ということを示しているようです。

実際、StormでもTridentAPIを用いる際にはグラフライブラリを用いてSpout/Boltにマッピングしている事例もあったりしますし。

データフロー

データフロー・・・といっても前述のレイヤに記述されたものがそのまま図になっただけですが。
とりあえずHDFSに取り込んだデータに対して分散並列実行エンジンが処理を分配して、
結果を集めてクエリ言語レイヤに返す・・・という構成のようですね。

これだけ見てみると非常にシンプルなのですが、最終的に開発が終わった段階ではどんな感じになっているんでしょうね?

3.で、ソースコードは?

で、最も重要なソースコードですが、「1.Apache DrillProposalの内容」の時点で
「今は設計が終わった段階で、Apacheプロジェクトで開発しているよ」ということが分かってしまったという・・・

実際、Apacheのgit(http://git.apache.org/incubator-drill.git/)を見てもソースは何もなく、
GitHubhttps://github.com/apache/incubator-drill)も同様という状況のようです。

なので、開発が終わってくるのを待つしかなさそうです。とほほ・・・