ひしだまの変更履歴

ひしだまHPの更新履歴。
主にTRPGリプレイの元ネタ集、プログラミング技術メモと自作ソフト、好きなゲームや音楽です。

AZAREA Tips

2012-12-24 21:27:13 | PG(分散処理)

AZAREA-Cluster Framework 0.9.0の現時点でのTipsを書いてみた。
(ついでに、思い付くポイントでAsakusa Frameworkと比較してみた)

ところで、AZAREAはフローを別々に定義して1つのアプリケーションにまとめることが出来る。(AsakusaFWがBatch DSLで複数のFlowをまとめるような感じ)
1つの入力から4種類の集計を行うサンプルが落ちたのは フロー1つに処理をまとめ過ぎた所為かもしれないと思ったので、フローは分けた上でアプリケーションで1つにまとめてみた。
しかし、アプリケーション内のフローをまとめてMapReduceジョブにするようで、(それはそれで最適化としてはよく出来ていると思うけれども)結果は同じになった。 

結局のところ、AZAREAもAsakusaFWも“大規模で複雑な基幹バッチを対象にしている”と謳っているが、「大規模」「複雑」の指している内容が違うのかもしれない。
4種類の集計程度でも実際に動かしてみるとAZAREAアプリは落ちたりするんで、現時点のAZAREAは大規模なアプリケーションには実用的でないような気がする。
ただ、GUIでフローを描けるのは面白いので、小規模なMapReduceアプリを作りたいんだったらAZAREAは便利だと思う。(WordCountは今までで一番早く作ることが出来たし(たぶん15分くらいで作れるw))

(※あくまで個人の意見です。何か見逃しがあるような気がするので、他の人の検証結果も聞いてみたいなぁ)

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

AZAREAの実行速度

2012-12-21 23:59:45 | PG(分散処理)

Hadoopアドベントカレンダー2012 #hadoopAC12jpの21日目です。

今までHadoop関連のツール・フレームワークが出る度に、それで作ったアプリケーションの実行時間を計ってきたので、AZAREA-Cluster Frameworkでも計ってみました。
(あ、ついでにAsakusa Frameworkも0.2のbatchapp版で古かったので、0.4のDirect I/O版に修正しました) 

まずはWordCount
AZAREAはけっこう速いです。
素のMapReduce(Java)とC言語によるストリーミング(とCacading)が一番速いのですが、それに次ぐ順位に来ました。
Combinerは使ってなさそうなのに効率が良いのは、Hiveの様に何か特別な処理をしているのかもしれません。 

次は1つの入力から4種類の集計を行うアプリ
ところが、これは落ちましたorz
最適化を行って3つのMapReduceジョブに集約されているのですが、落ちたのは1つ目です。
スタンドアローンモードで動かすと「Unexpected key」というエラーで、分散環境ではOutOfMemoryErrorでした。
スタンドアローンモードと同じデータをシミュレーターで実行するとちゃんと通るんですけどねぇ。
(あ、ちなみにこのアプリのフローの図偏差値のサンプルと違ってちゃんと出ました。横に長くなって線がかぶってしまうのは仕方ないと思います(笑))

コメント (1)
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

AsakusaFW DirectI/O版 偏差値算出サンプル

2012-12-19 23:59:21 | PG(分散処理)

Hadoopアドベントカレンダー2012 #hadoopAC12jpの19日目です。

Asakusa FrameworkDirect I/O版の偏差値算出サンプルを書きました。


昨日、AZAREA-Clusterフレームワーク偏差値算出サンプルを作ってみたので、AsakusaFW版と比較してみようと思って久しぶりに見てみたのですが、CoGroupを使っていてびっくり^^;
元々、AsakusaFWを初めて試せるようになった頃にWordCountの次に作ったのが偏差値算出サンプルなので、まだ演算子についてもよく分からず、とりあえず何でも出来て便利なCoGroupを使いまくっていたのでした(苦笑)
しかしCoGroupは最適化の妨げになるのでなるべく使わないようにすべき!という訳で、CoGroupを使わないバージョンを作ってみたのでした。

で、出来るには出来たんですが、意外と面倒でしたね^^;
どういうデータモデルを用意してどう演算していけばいいかを考えるのは大変でした。
この辺りはAZAREAでも悩んだので、フローの図が描けるかどうかはあまり関係ないですね^^; 

ただ、久しぶりにAsakusaFWがDSL(ドメイン特化言語)を意識していることを実感しました。
Operatorでメソッドを書く(メソッド名を決める)のは、そのドメインの語彙を用意することに相当します。
今回の例で言えば、「偏差値を算出する(というドメイン)」で使う用語(「平均を算出する」とか「標準偏差を算出する」とか)を定義しているわけです。
そして、Jobの定義では(基本的に)その語彙だけを使って処理を記述することが出来ます。
(Eclipseを使うという制約からJavaをホスト言語としているので、くどい表記になっている部分もありますが^^; この辺りはScalaで書けるといいですよね~w)
(ただし、今回作ったものは自分の命名能力が貧弱なせいで あまり良い語彙になっていませんがorz)
(ついでに言えば、Operatorで入出力データの型を決めているので、ジョブを書く際には間違ったデータを入れようとするとコンパイルエラーになるので、誤りは減りますね。型付け万歳!w) 


AsakusaFWはフローをGUIで描く機能はありませんが、Graphvizを使って図を生成することは出来ます。
AZAREAのフローに相当するフローグラフと、どのようなMapReduceジョブに変換されるかを表すステージグラフの2種類が出せます。(実際はもっと色々な種類があります)
これらのグラフには前述の“語彙(Operatorのメソッド名)”が表示されるので、ちゃんとした命名をしていれば、グラフを見るだけでおおよそ何をしているか分かるはずです。

で、偏差値算出のプログラムはAsakusaFW版もAZAREA版も似た感じになったのですが、AZAREAのMapReduceは6個でAsakusaFWは4個でした。
一般的にはMapReduceジョブ数が少ない方が全体の実行時間は短くなると思われるので、AsakusaFWは最適化をけっこう頑張ってますよね。
個々のMapReduce処理の効率が分からないので、実際にどちらが速いかは、実行してみないことには何とも言えないのですが。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

AZAREAを試してみた

2012-12-18 23:59:10 | PG(分散処理)

Hadoopアドベントカレンダー2012 #hadoopAC12jpの18日目です。

AZAREA-Clusterの疑問点をブログに書いていたら回答をいただきました。まさか反応があると思っていなかったので、びっくり!ありがとうございます!
で、個人でもダウンロードの申込が出来るとのことだったので、申し込んで無事ダウンロードできました。

早速インストールして試してみました。
GUIは思っていたより動作が軽いですね!(もっとも、僕のPCはEclipseのScalaプラグインも特に問題なく動くスペックなので、参考になるかどうか微妙ですが^^;)

WordCountは今までで一番簡単に作れたかも(笑)
(どの処理クラスを使うかについては さすがにちょっと迷いましたが)

また、WordCountより複雑なものとして、例によって偏差値算出のサンプルも作ってみました。
やはりWordCount程度では分からない問題がいくつか出てきましたね。
集計処理用のGroupが入力と出力で同じ種類のEntityしか受け付けられないようなので、事前にConversionで変換しておかないといけないのが面倒なところ。そのせいでフロー上のステップがだいぶ増えてしまった印象です。
あと、分岐・結合しているのに再表示されたフローがそういう風にならない(見えない)のはさすがにどうかと…。 
AZAREAのバージョンはまだ0.9なので、その辺りは今後に期待というところでしょうか。 

さて、コーディングしていて非常に気になった点が、ライセンスについてです。
評価版が評価にのみ使用できるというのは問題ありませんね。まさに試したくて使っているわけですし(笑)
AZAREAの存在および評価を第三者に開示できるというのも有り難いです。試した結果をウェブページに書いて公開したいですし(笑)(わざわざ「存在を開示してよい」と書いてあるのは珍しい気がしましたが、商用製品だと、存在すら秘密にするような事もあるのでしょう、きっと)
問題なのは、リバースエンジニアリング禁止ですね。普通のソフトウェア(WordとかExcelとか)だったら特に問題ないのですが、ソースを生成するタイプのフレームワークではどうなのでしょう。生成されるソースで使っているクラスやメソッドは、どういう仕様(使い方)なのか知りたいところです。しかし、親クラスはAZAREAの提供するクラスです。ダウンロードしたアーカイブの中にソースは当然ありませんでしたし、Javadocも入っていませんでした。そこでクラスを調べようとしたら、リバースエンジニアリングになる可能性があるのでは?という懸念が出てくると思うのです。
また、AZAREAで作ったプログラムはデバッガーでテストできますが、例えば間違って変なデータを渡してAZAREAフレームワーク内部で例外が発生してデバッガーで停止したりしたら、それもリバースエンジニアリングの範疇に入ってしまう??
すると、作ったアプリで例外が発生したら、開発者が自分で調査せずに即サポート行きにするしかないんでしょうか。それだと解決までに時間がかかって開発者も大変だし、つまらない問い合わせが増えてサポートの人も大変だと思うのですが…。
もっとも、評価版のライセンスがこうだというだけで、商用ライセンスだと違うのかもしれませんね。

そう考えると、OSSって有り難いですね(笑)
最近は何かあるとソースを見るのが当たり前になっていて、気付きませんでした^^;

コメント (1)
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

分散キャッシュの例

2012-12-15 23:58:59 | PG(分散処理)

Hadoopで分散キャッシュのコーディング方法を試して、irofさんによってmzpさんを量産するサンプルを作ってみました。

当ブログでは、なんでそうなったか…を書いておきますw


Hadoopアドベントカレンダーのネタがさすがに尽きたなぁと思っていたところに、skrbさんがJavaFX Advent Calendarでいろふさんのネタを使ってるじゃないですか!
他にもいろふカレンダーに触れているものがあるらしいし、これはHadoopもいろふさんに絡めるしか…! と思いつつも、難しいかなぁと思ったのですが、mike_neckさんが良いアイデアを出してくれましたw
これに以前見かけたみずぴーさん量産の話をくっつけたのが今回のネタです。

ちなみにどこかではぶれいすさんの量産に成功したらしいですが、自分の技術力では出来ませんでした…^^;

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする