ひしだまの変更履歴

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

Asakusa Framework 勉強会 2014真夏で食べてきました

2014-08-22 23:59:59 | PG(分散処理)

Asakusa Framework 勉強会 2014真夏』に参加してきました。
今回は普段と違って5分ずつのLT大会、およびビアバッシュということで、ビールとピザをいただきながらの勉強会でした(笑)


最初は土佐さんの『Asakusa脳の作り方』。

前回の才所さんの発表に出てきた「Asakusa脳」がキーワードです(笑)
Asakusa脳になるまで、つまりAsakusaFWに慣れるまでに壁があるんじゃないかという話ですね。
そのうちのひとつ、演算子の実装方法について、ジョブフロー側の実装例が無い!という訳で、土佐さんがチートシートを作ったそうです。→演算子のチートシート

図と実装例が書かれています。GitHubでこんなことも出来るんですねぇ。


2つ目はts_minさんのOperatorのテストの実装方法の話。

例として、データモデルに条件判定用の項目を追加し、それを使って集計するというフローを挙げ、その演算子のテストを書いてみてハマった点の紹介でした。

ちなみにこの例ではConvert演算子で項目を追加したデータモデルへの変換と値のセットを行っていましたが、Extend演算子でデータモデルを変換し、Update演算子で条件判定用の値をセットするということも出来ます。
単なるデータ移送となる項目が多い場合は、こちらの方がお奨めです。

また、条件判定して片方のデータを捨てる(使わない)だけなら、Branch演算子で振り分けた方が、処理対象のデータが減って有利になると思われます。

グループ化した各グループの先頭を取り出すのは、発表されていた通り、GroupSort演算子が向いていますね。
このGroupSort演算子のテストでは、テストデータとしてソートされたデータを渡す必要があります。
確かに、GroupSort演算子の仕様を知っていないとテストデータが作れないという面がありますね…。
演算子内部の動作をエミュレートしてくれるテストクラスがあると便利かもしれませんね。


3つ目はpochi_blackさんの『非構造データをAsakusaで扱うための考え方と実装』。

ログのような非構造データを扱う話でした。
AsakusaFWでは構造化されたデータを対象としているので、非構造データをどうやって構造化データに変換するかというのがポイントです。

TSVFormatやCSVFormatは、データの途中にタブやカンマが入っているとアウト。
Asakusa独自フォーマットはドキュメントが未整備で断念。
で、結局、素のMapReduceで前処理を書いたそうです^^; 

この話が、ちょうと次のH&Mさんの話につながりました(笑)


4つ目はH&Mさんの『非定形データの処方箋』ということで、非構造データを実際に読み込むクラスを作ったそうです。
つまり、pochi_blackさんが断念したAsakusa独自フォーマット(RecordReader)を実装したということです。

非構造データといってもテキストデータなので、区切り文字を気にせず1行ずつのテキストとして読み込むことが出来れば、後はExtract演算子なりConvert演算子なりで処理すればいいので、読み込み部分が鍵です。
入力ファイルを指定するImporterは内部でDataFormatという変換クラスを持っており、その中でレコードを読み込むRecordReaderがありますので、それを作ったというわけですね。
DMDLで@directio.csv等を指定している場合は、それらのクラスは自動生成されます。それを参考にして1行ずつ読み込むクラスを作ったそうです。

自分も昔そういうことをやったことがあったなぁと思ったんですが。(WordCountのサンプルを作ろうと思ったら、1行ずつ読み込む必要があるんですよね(爆))
自分が作ったFormatは0.2.1時代で、Direct I/Oは0.2.5以降(正式は0.4から)なので、相当古いですね^^;

今のバージョンで使えるやつを作ってみようかなぁ…と言っても今回H&Mさんが作成済みなので、本家にコントリビュートされるのを待ちますかね(笑)


5つ目はreiji_hataさんの『処理速度向上のノウハウ』。

  • 演算子は処理性能としてMap/Reduceがあるので、なるべくMap系の演算子を使いましょう。
  • CoGroupは便利だけどReduce系なので頼り過ぎないようにしましょう。
  • CoGroupの前後にReduce系処理があるなら、CoGroupの中に入れてしまう方が速くなる。
  • 結合に関して、トランザクションデータと複数のマスターを結合する場合、トランザクションデータを分割して、それぞれ結合した方が良いことがある。
  • データサイズが小さいファイルでは、ImporterのデータサイズでTINYを指定する。
  • HDFSにファイルを置く際に(UNIXのsplitコマンドなどで)自分で分割して置いた方が速くなる。

CoGroupは便利ですが、最適化されづらいので、なるべく使わない方がいいと言われています。
また、入力データがメモリーに乗る範囲ならいいですが、乗り切らない場合はパフォーマンスがかなり劣化します。0.7で改善されるみたいですけど^^;

3つ目のはちょっと目から鱗ですね(笑)
AsakusaFWは最適化で処理(複数の演算子)をまとめてくれますが、処理の中身までは判断できないので、処理内容によってはプログラマーがまとめてしまった方が良いということもあるのかもしれません。 

4つ目の観点も考えたことが無かったですね~。
結合する場合はデータが少ないに越したことは無いので、処理内容的に分割していいなら、こういう手もありなのかもしれません。

Importerのデータサイズの指定、データサイズが小さいときにTINYを指定すること、これは忘れがちですが重要です。

最後のファイル分割に関しては、不思議ですね。
HDFSが自動的にブロックサイズ(最近だとデフォルトで128MB?)で分割してくれるので、@directio.csvで特殊なオプションを指定したりしていない限りは、自動的に分割されると思うからです。
うーむ、不思議不思議。


6つ目はaoetkさんの『AsakusaのドキュメントをDashで見たい』。
他のLTとはかなり毛色の違う、異色の話でした(笑)

MacのDashというツールを使って、AsakusaFWのドキュメントを見られるようにする方法でした。
AsakusaFWのソース(ドキュメントのソースも含む)一式をダウンロードし、Dash用にコンパイルする手順を紹介していました。 

会社によってはインターネットへの接続を制限している所もあるそうなので、そういう所では、ローカルでドキュメントを見られるようにする需要があるかもしれませんね。


7つ目はreoreoreoさんの『テストドライバの各実行ステップをスキップする時の注意』。

調査の為に、本番環境と同じデータを使ってローカル環境で実行しようとしたそうです。
AsakusaFWのテストドライバーでは主にExcelファイルからデータを読み込みますが、データをExcelに転記するのはナンセンス。
そこで、テストドライバーが作る一時ファイルに注目し、それを差し替えるという方法を思い付いたようです。
しかしテストドライバーの初期化・クリーンアップ処理で前回配置されたデータを削除しているので、それをスキップする必要がある。って、ドキュメントにスキップ方法が書いてあったので試してみたが、上手くいかなかったそうで。
オチは、そこにセットする値のtrue/falseがドキュメントとは逆だったということでした(爆)
ちなみにバグっぽいです(by apirakunさん)。
まぁ、LTのネタにするのもいいですがw、メーリングリストやissueを書いてもらうと修正されると思います。

ちなみに自分も、テストドライバーでCSVファイルが読み込めると便利だと思うんですが、AsakusaFWの作成者であるashigeruさんにその正当性を納得させることが出来ません(爆)
本番データを読み込ませるようなことは、テストドライバーの使い道とは違うってことらしいんですねorz
誰かashigeruさんを説得して下さいw
(CSVファイルを直接読むことは出来ませんが、近いことは出来るようになっているんですけどね)


最後はokachimachiorz1さんの『Asakusa0.7の新機能で、テストデータをどうドキュメントするのか的な実用的なアレ』。
冒頭いきなり山の話から始まりましたが、登山が趣味らしいので(笑)

0.7からテストデータのExcelでセルの参照(や演算)が使えるようになるので、それを使ってテストデータを作っているという話でした。

ModelTransformerが必要になった理由は、検証データで「ある行では値があり、別の行では値がnullであること」を記述する方法が無かった為です。
通常の「完全一致の比較」ではこれが出来るのですが、0.7から使えるようになる「範囲比較」では出来ないのです。
そこで、ModelTransformerで実行結果のnullを0に置換し、検証データでは0を書いておくことで、比較できるようにします。

範囲比較は、「±nの範囲内だったらOK」とする検証ルールです。
BigDecimalやdoubleは完全一致の判定が出来ないので、範囲比較が新設されたのでした。


しかし真の最後は、飛び入りでapirakunさんでした(笑)
apirakunさんは主にAsakusaFWのリリース担当で、テストしたりドキュメントを書いたりしています。(「隣の人」というのはAsakusaFWを作ってる人のことですw)

0.7は現在RC1が作られた状態だそうで、ドキュメントもURLに0.7/developを指定すれば見られます。ドキュメントはまだ未完成ですが、HiveのORCとかParquetとかだけ先に書いたそうです。
Hive用のDDL(CREATE TABLE文)を生成するGradleコマンドも用意されるそうで、デモしていました。 

あと、Shafuでプロジェクトテンプレートを指定するときに、GitHubのzipファイルのパスを指定できるという裏技?があるそうです。例えば「https://github.com/asakusafw/asakusafw-examples/archive/0.7-develop.zip」といった形のようです。


今回も色々な話が聞けて、自分と似たことを考えてるなぁとかその発想は無かったなぁとか、面白かったです。
使っている人達の要望事項が伝わらないと想像だけで開発されることになるので、こういった機会があると良いですね。
ありがとうございました。

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