ひしだまの変更履歴

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

Asakusa Framework 勉強会 2014秋の感想

2014-10-20 23:59:59 | PG(分散処理)

2014/10/17『Asakusa Framework 勉強会 2014秋』に行ってきました。

今回の会場はサイトロックさん。
サイトロックさんはシステム運用をやっている会社で、噂には聞いていましたが、行ったのは初めてでした。食堂とかおしゃれな感じですね(笑)


最初は恒例の土佐さんの『Asakusa fwはじめの一歩 0.7.0』。

拙作DMDL EditorXですが、いくつか使用できない箇所があったようで><
属性追加ウィザードの障害(issue42)は、自分の環境では再現しないんですよねぇ。
たぶんXtext内部の情報に不整合があるのだと思います。プロジェクトのクリーンをしたりdmdlファイルを保存し直したりすると直るかも?

フローのテストクラスの作成の障害(issue43)は修正済みです。
詳しいことはissueに書いておいたので、興味がある人は見てみて下さい。
テストクラスの作成と同時に出来るテストデータ用Excelファイルの雛形生成は最近の機能追加では一番の機能だったので、ぜひ試してみて欲しかったのですが^^;
これを使うと、AsakusaFW本体(Jinrikisha)のExcelファイルの雛形生成を経由せず、フロークラスで使用する各シートを1つのワークブックに収めたExcelファイルを生成します。
特に目次ページは便利だと思います! LibreOffice Calcを使っていて不便だと思った箇所の改善に力を注ぎ込みました(笑) 

あ。あと、Importer/Exporter作成ウィザードでモデル名と同名のファイルを作る際の指定は「${modelName}」(波括弧)ではなく「$(modelName)」(丸括弧)です。ちゃんと生成は出来ているようなので、単なる見間違いだと思いますがw


2番目は、MDIS武石さんの『Asakusa Framework 適用事例(業務系バッチ高速化)』。

実行時間が数日レベルの年次処理の一部をAsakusaバッチにした話でした。

Oracle10gで更新対象のテーブルが300くらいある内、85%は数秒~10分程度で終わるのでHadoop化せず、1時間以上かかる(最長4時間半の)更新処理10テーブルをAsakusaアプリで作ったそうです。FlowPartは処理対象テーブル毎に作ったが、Operatorはほとんど共通化したとのこと。
RDBとHadoopとの転送にはSqoopを使用しているそうで、Asakusa Frameworkが想定している形のひとつですね(笑)

それで、現行環境で270分だったのがHadoop環境で13分!
久しぶりにこういった時間短縮の話を聞きました(笑)


3番目は、@atsushi_nakataさんの『汎用機担当エンジニアだった私が体感したAsakusa Framework』。

汎用機を担当して4年目のエンジニアでJavaを全く知らないところから、44日間でAsakusaアプリを作るところまで行ったそうです。
44日の半分くらいはJava自体の勉強に使ったようなので、Javaを知っている人なら、1ヶ月もあればAsakusaアプリを作れるようになるという事ですかね(笑)

AsakusaFWのトレーニングを受講して、実行環境にはNode0 DBRを利用されたそうです。
実行の際にはHadoopクラスターのノード数を変えて試したりしたようで、Node0 DBRが想定している使い方な気がします。

これも5000万件(5GB)の処理が1時間16分だったのが7分になったそうで、速い!(笑)

拙作Toad Editorも使われたようで、ありがとうございます。
こういうエディターを作ってみた結果、GUIで図を描いて線でつなぐのは大変だと思ったんですが、演算子が数個というレベルなら大丈夫っぽいですね。


最後は、ノーチラス・テクノロジーズの川口さん。
前回の勉強会では「今後出る予定の0.7.0」の紹介でしたが、今回は「9月に出た0.7.0」をリリースノートやドキュメントを見ながらの紹介でした。

●Parquet/ORCFileというカラムナーフォーマット対応
データの加工はAsakusaアプリで行い、その結果をParquetやORCFileとして出力して、SQLで見られるといいんじゃないかという考え方のようです。

HDFSを対象にSQLを実行するツールはSQL on Hadoopと呼ばれており、今のところ代表的なのはImpala・Presto・Drillです。
Impala:Claudera。HDFS上のファイルを相手にクエリーを高速に実行するもの
Presto:Facebook。Amazon S3やRDBも併せたクエリーを実行できる
Drill:MapR。なんかまだまだらしい^^;

ParquetやORCFileは、同じカラムナーと言ってもやはり特徴が違うそうで。
ORCFile:Hive用としてHortonWorksが推している
Parquet:現時点のバージョンではDECIMALやTIMESTAMPが使えない
ImpalaはParquetにしか対応していない。Prestoは当初はORCFileのみ対応していた。Drillは両方とも対応している。

DMDLのDECIMALやTIMESTAMPを表現する都合上、@directio.hiveの属性が増えています。これはデータ型によって付けられるものが異なります。
DMDL EditorXでも入力補完機能では出せるようになっていますが、属性追加ウィザードでは条件判定は出来ないので、データ型に応じて自動的に切り替えることは出来ませんorz 

また、ORCFileを作るのは、Pqrquetより少し時間がかかるそうです。
(重複データを排除するのでデータは小さくなる反面、重複データが少ないとディクショナリーを作るのにコストがかかる。
ただし将来のバージョンでは改善されるかもしれないし、マシンの性能によってはあまり影響が無いかもしれない)

ということで、AsakusaFWと直接関係無いながらも、勉強になる話でした。

●Hadoop2対応
代表的なHadoopディストリビューション(CDH4・MapR4・EMR AMI3)はHadoop2に対応してきており、Apache Hadoopも1系はもうあまり開発されていないそうです。

ただ、スタンドアローンではHadoop1系の方が速いので、AsakusaFWとしては、開発はHadoop1で行い、運用環境はHadoop2になるだろうという想定をしているようです。
という訳で、AsakusaFW0.7.0では切り替えが簡単に出来るようになったそうです。 →デプロイメントガイドの『Hadoop2系向けの構成
他にも設定ファイルを同梱したり置換したりしてアーカイブを作る機能も加わったようです。これは後で要チェック!

●テストドライバーの改善
個人的には(アプリ開発としては)ここが一番大きいと思っていたところなんですが、時間が押していたので省略されました(爆)

●実行時パフォーマンスの改善
Hadoopジョブ間の中間ファイルを、今まではHadoopのシーケンスファイルを使っていたが、それをやめてシンプルなファイルにし、snappy圧縮もするようになったそうです。
(中間ファイルのデータサイズが大きいアプリケーションでは改善が見込める。しかしI/Oコストは減っているがCPUを使うようになったので、性能は一概には言えない)

それと、CoGroup演算子でESCAPE指定をした際の内部構造がチューニングされ、けっこう速くなったらしいです。(というか元が遅すぎたんだとか^^;)

●IntelliJ対応
IntelliJ IDEAに対応したそうです。
でもDMDL Editorは無いよ!(爆) 

『ソフトウェア』 ジャンルのランキング
コメント   この記事についてブログを書く
« AsakusaFW0.7.0 Hive・Hadoop... | トップ | AsakusaFW0.7.1 スモールジョ... »

コメントを投稿

PG(分散処理)」カテゴリの最新記事

関連するみんなの記事