SyntaxHighlighter

2012年5月27日日曜日

Google App Engine PipelineAPI (1)

前回に引き続き、PipelineAPIについて。


なぜPipeline処理?

Hadoop Cascading(Apacheプロジェクトではない)でも用いられている。Cascadingは、HadoopMapReduceを隠蔽(抽象化)するライブラリー。CascadingではMapReduceタスクをPipeという単位で記述し、Pipeをつなげて処理を行う。MapReduceの複合ジョブを効率的に行う事が出来る。
基本的なMapReduceではReducerの結果をMapperに渡すなどは出来ない。
GoogleAppEngine PipelineAPIでもMapperとの複合を主な用途として紹介している。


Pipeline処理とは

コンピュータにおける処理要素を直列に連結し、ある要素の出力が次の要素の入力となるように配置して処理することである。コンピュータ等の高速化技術の一つである。パイプラインの各要素は並列またはタイムスライス化して実行される。
(出典:Wikipedia パイプライン処理


GoogleAppEngine PipelineAPIの処理概要

PipelineAPIでは、Jobクラスを実装する事により、Pipeline処理を記述していく。
並列したJobはバリア同期によって統合される。
各Job(Record)は自Taskの状態とOutputSlot(出力)とバリア同期の為の情報を持っている。
処理のおおまかな流れは下図の通り(Google I/O 2011より)













Multiply、AddはJobで、SlotA、SlotB、SlotCは出力スロットとなっている。
Barrierはバリア同期を行っている処理でSlotA,SlotBが埋まる事(Fill)によって、
Addが実行(Run)される事を示している。

Taskの状態遷移
【FAN_OUT】Jobの入力処理(Task)を起動させるTask
【HANDLE_SLOT_FILLED】入出力スロットが埋められたら動くTask
【RUN_JOB】バリア同期によるロックが解放されたら動くTask(Jobを実行する)
【FINALIZE_JOB】出力スロットを埋める。
【DELETE_PIPELINE】PipeLine処理終了

処理の詳細について

(次回以降にまた調べてみたところを紹介する予定)

・バリア同期について
バリア同期が行われているTaskはRUN_JOBとFINALIZE_JOB。
バリア同期の情報はwaitingOnMeKeysとして、自Jobが実行するための
埋め待ちSlotの情報を保持している。


・FutureValue,ImidiateValueについて
FutureValueは処理待ちのJobのOutPutSlotの情報を保持している。
ImidiateValueは言葉の通り即値であり、HANDLE_SLOT_FILLEDのTaskが直後に行われる。

・Slotの配置(Keyの採番)について
同期化されたメソッドによって採番されている。(Slotの競合は起きない)

課題、その他

・非同期パイプライン、人間のジョブを挟むパイプライン処理
・各ステージの分割の仕方、最適化について
・どれだけスケールするか、Quotaについて等
・AppEngineMapperとの複合(ここはあまり興味なくなってきたかも)

引き続きGoogleAppEngine PipelineAPIをいじくってみる。
でも気になるから、Cascadingもさわってみるかな。

続く。

2012年5月20日日曜日

Google App Engine Pipeline APIを使ってみた。

先日Google App EngineMapReduceを使ってみた記事を書いてみたが、
関連してPipelineAPIの存在を知った。
今回はPipelineAPIについて使ってみた感想を書く。

まず、PipelineAPIについて、
PipelineAPIは、複雑で時間を消費するワークフローを接続し処理する。
APIの主要な使用ケースはGoogle App Engine MapReduceとの接続である。
(訳:筆者※英語力低)

こんな図形まで載っている。







この図形の示す意味は、下記のとおり。


フレームワークは、ユーザが1つの仕事の出力が1つ以上の仕事の入力になる多数の仕事の準備を表現することを可能にします。
これらの準備は、最もAの出力がBの入力スロットに向けられるべきであることを仕事Aから仕事Bの中の入力スロットのうちの1つまでの有向辺が示す一種の有向グラフと評することができます。
例えば、私たちは、3つの整数入力をとる仕事、x、y、zを構築するようにDiffJobとMultJobを使用し、次の計算[(x -y)*(x -z)]を行ないます-2.
その計算は次の仕事グラフとして表現されるかもしれません。
(グラフは右から左まで読みます。)
(Powered by Excite.翻訳)

なるほど、要は処理を分散並行させる事ができるんだな。(ん、分かりづらい?;)

ま、やっぱり実際に触ってみる方が早い。
GettingStartに従って、プロジェクト作成してみよう。
サンプルでは文字の出現回数について集計を行うサンプルがあったが、
ヒヨッコHadooperとしてはWordCountがやりたい。
早速作ってみた。

PipelineAPIの詳細については追って調査し、紹介しようと思う。
MapReduceっぽく実装してみただけで、本家のMapReduceとは
かけ離れているので注意。
Exampleで使用してるViewをそのまま使って、Let's Deploy!

文字列を適当に入力。そして実行。











処理中…。












完了。ちゃんと数えられている。













管理コンソール。今回は子のプロセスが3つ。










子のプロセスの詳細も見れる。













使ってみた感想。正直面白い。これはMapReduceも夢じゃない。はず。
(処理時間は正直早いとは言えないが、少量データだし。)
Google App Engine PipelineAPIの中身までまだ追いきれていないが、
これはMapReduceとはまた違ったアプローチで大量データの処理も
できるのではなかろうか。うん、なんか面白そう。

今度は、 PipelineAPIの中身に迫ってみるか。
Google App Engine MapReduce…、とりあえず、頭の片隅には入れておこう)



2012年5月13日日曜日

Twitter Ambroseを使ってみた。

GitHubを眺めていたら気になるプロダクトがあったので、
早速使ってみた。

Twitter Ambroseとは、
MapReduceジョブをリアルタイムにビジュアル化してモニタリングするツール。
要は、MapReduceジョブを見える化して最適化のお手伝いをするツールである。

こんな感じ。














Bootstrapを使ったUIで洗練されていてカッコいい。
このグラフの意味するものは、下記の通り。(直訳)

円の上の弧セグメントはそれぞれMapReduceジョブを表わします。
ジョブ同士の依存性は、セグメントを接続する弦によって表わされます。
灰色のジョブはまだ走っていません。明るいグリーン・ジョブは走っています。
また、ライトグリーン仕事は終わります。
ジョブがそれぞれ二分されることに着目してみてください。
弧の2分の1の上の弦は先行ジョブに接続します。その一方で他方の半分上の弦は後継者仕事に接続しています。
例えば、仕事より下の図形では、10と13は前任者を持っていません。
また、仕事8および18はブタ・ワークフローでの最終仕事です。
示された弦図形が私たちの最初であることに注目する、
ワークフローの視覚化で通過する、また、改良の余地があります。
私たちは、ワークフローDAGのグラフのように、同様に他のビジュアル化を支援したい。
改善されたビジュアル化を開発する場合は、必ず私たちに引くことリクエストを送ってください!
(powered by Exceite.翻訳)



で、早速使ってみた。
今回は、Hadoopの疑似分散環境で実行してみる。
また、実行環境はPigを選択した。

テストデータとして以下のような入力データを準備

a A 1
b B 2
c C 3
a AA 11
a AAA 111

実行するPigスクリプトは

one = load 'input/one.txt';
grouped = GROUP one BY $0;
summed = FOREACH grouped GENERATE group, SUM(one.$2);
DUMP summed;


そして、実行してみた。













んー、実にシンプル。疑似分散環境(対象データの量が少ない)だから仕方ない。
でもすんなり導入できそう。

現在、サポートしている実行環境はPigだけで、
今後、サポートする実行環境を増やしていくそう。

Twitter AmbroseをGAEで動かすぞ。と意気込んではみたが、
課題が。(まずはMapReduceをなんとかせんと、そしてPig…orz)

ってまあ僕自身もまだ生まれたてのヒヨッコHadooperなので、
まずは、見た目重視ってことで。

ではでは、次回はGAEのMapReduceの続きでも。



2012年5月12日土曜日

Google App EngineのMapReduceを使ってみた。

遅ればせながら GoogleAppEngine MapReduce を使ってみた。
まずは、GettingStartに従って、Jarファイルを生成する。

生成されたJarファイルは6つ。これらを使ってExampleを動かしてみるのが今回の目標。






続いて、プロジェクトの作成を行う。
個人的にGoogleAppEngine(以後、GAE)のアプリケーションを作るときは、
Slim3ベースのプロジェクトを使うのが楽チンなので、今回もSlim3で。


Exampleでは、"PBFVotes"というKindに400件のEntityを挿入してそのうち"skub"プロパティーの値で"pro"と"anti"、それぞれ設定されている件数を数えるというもの。
ちなみに付属のExampleではMapper処理完了のコールバックを登録していないものなので、
最終的な集計結果は得られない。Mapper処理完了のコールバックを登録して、実行しよう。


実行結果。めっちゃログ吐くし。。





















でも結果バッチリ。







さらに管理コンソール付き。なんかかっこいい。















使ってみた感想。
今回は少ないデータ量だったので、あまり分散された感と処理が速くなった感はない。
しかもMapフェーズまでは本家Hadoop MapReduceっぽいのだが、
以降、Shuffle,Sort,Reduceフェーズがなく、尻切れとんぼ(言葉が悪いが)感が否めない。
ただ、Mapperを独自実装したり、Shard数を増やしてみたりといろいろ試しがいはある。
グーグル、フル機能のMapReduceをGoogle App Engineで提供へ 記事でもあるように、
Python版はフル機能が実装されているらしい。Javaの近いうちにフル機能が実装されるのだろうか。
期待して待っていよう。
それかShuffle以降の実装も独自にすすめてみるのも。
AppEngineReducerという呼ばれる気配のないクラスがあったし。
次回も引き続きGAE Mapreduce。中身に迫る。(予定)









2012年5月6日日曜日

Ohlohj Ver1.0.0リリース

Ohlohj Ver1.0.0をリリース致しました。
OhlohjOhlohというオープンソースソフトウェア開発を見通すことを目的とした、Webサービススイートとオンラインコミュニティプラットフォームを擁するウェブサイトで、サポートするREST APIのJavaラッパがOhlohj となります。
Ohlohj Ohloh非公式ライブラリです。
XMLの解析やOAuth認証など面倒な作業はすべてOhlohj が処理します。
まずはohlohj.OhlohAPIインターフェースのJavadocを見るのが早いです。
また、Google APP Engine上でも動作し、標準で非同期処理をサポートしています。


使い方
・標準のWebアプリケーションの場合
ohlohj-core-1.0.0.jarをDownloadページよりDownloadし、クラスパスに通すだけ。後は好きなAPIを呼び出してください。
・Google APP Engine上で動作させる場合
lohloh-core-1.0.0.jarとohlohj-appengine-1.0.0.jarをDownloadページよりDownloadしクラスパスに通せば、非同期処理が行えます。
(上記標準のWebアプリケーションと同じ手順でも動作いたしますが、非同期処理はできません)


ライセンス
Ohlohj は Apache License 2.0 に基づいてリリースされています。