goo blog サービス終了のお知らせ 

ひしだまの変更履歴

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

Asakusa Framework 0.9.0のWindGateの環境変数のデフォルト値

2016-12-15 00:00:00 | PG(分散処理)

Asakusa Framework Advent Calendar 2016の15日目です。
今日は、2016/12/6にリリースされたAsakusaFW 0.9.0のちょいネタ、WindGateプロファイルの環境変数のデフォルト値についてです。

WindGateプロファイル(ASAKUSA_HOME/windgate/profile/hoge.properties)では、環境変数を使うことが出来ます。
ここで、ハイフンで区切って(環境変数が定義されていなかったときの)デフォルト値を設定することが出来るようになりました。

…って、うん?その機能は前から無かったっけ?
と思ったら、yaess.propertiesには以前からありました^^;

YAESSやWindGateでは、プロファイル内の設定値を実行時に変更すること(実行時引数で上書きするとか)は出来ません。
が、環境変数を使うように書いておくことで、実行時に設定値を変更できるわけです。 


Asakusa Framework 0.9.0のthreads.commit

2016-12-14 00:00:00 | PG(分散処理)

Asakusa Framework Advent Calendar 2016の14日目です。
今日は、2016/12/6にリリースされたAsakusaFW 0.9.0のちょいネタ、threads.commitについてです。

AsakusaFWはトランザクションの考え方を持っていて、Direct I/Oでファイルを出力するとき、一旦一時領域にファイルを出力し、全て出力し終わったら最終格納場所へ移動するという仕組みになっています。
これにより、簡易的なトランザクション(処理が成功したときだけ出力し、失敗したときは何も出力しない(中途半端な状態を残さない))を実現しているわけです。

この一時領域の場所や、そもそもこの仕組みを使うかどうか等はデータソースの定義で変更することが出来ます。
この定義に、AsakusaFW 0.9.0でthreads.commitというプロパティーが追加になっていました。
一時領域から最終格納場所への移動はシングルスレッドで行われていますが、このプロパティーを設定することで、マルチスレッドで実行されるようです。
とはいえ、普通は移動はメタデータの変更だけなのでほとんど時間はかからないはずで、シングルスレッドで充分だと思います。が、一時領域が最終格納場所と別ファイルシステムだったりMapRで別ボリュームだったりすると、移動ではなく転送(コピー&削除)になって時間がかかることがあるので、複数ファイルの転送を行うならマルチスレッドにした方が速くなることがあるのかもしれません。 


Asakusa Framework 0.9.0のVanilla

2016-12-13 00:21:32 | PG(分散処理)

Asakusa Framework Advent Calendar 2016の13日目です。
今日は、2016/12/6にリリースされたAsakusaFW 0.9.0のAsakusa Vanillaについてです。

VanillaはAsakusaFWの実行エンジンのリファレンス実装だそうです。
まだ試験的機能なので標準ではありませんが、フローのテストの実行エンジンとして使う想定のようです。
ただ、現時点ではまだWindowsではちゃんと動かないようです。(Windowsで実行したら、テスト失敗になりました(苦笑))
というわけで、ちゃんと使えるバージョンになったら改めて試したいと思います。

待て、次号(次バージョン)!


Asakusa Framework 0.9.0のM3BP WindGateダイレクト・モード

2016-12-12 09:11:27 | PG(分散処理)

Asakusa Framework Advent Calendar 2016の12日目です。
今日は、2016/12/6にリリースされたAsakusaFW 0.9.0のAsakusa on M3BPのWindGateダイレクト・モードについてです。

Asakusa on M3BPでもWindGate JDBC(RDBへのアクセス)は使えます。
ただ、WindGateの実行は、Asakusaアプリケーション本体とは別フェーズで実行されます。
例えば複数のテーブルを読み込むとき、全テーブルを読み終わらないと次のフェーズ(アプリケーション本体の実行)に移りません。つまり、1つだけデータ量の多いテーブルがあると、その読み込みに引きずられて全体が遅くなってしまうことになります。

そこで今回、Asakusa on M3BPではWindGateダイレクト・モードというものが出来るようになりました。
(これはAsakusa on M3BPの機能なので、Asakusa on Spark等では使えません)
(また、WindGateのOracleダイレクト・パス・インサート機能と名前は似ています^^;が、無関係の機能です)

WindGateダイレクトモードでは、RDBへのアクセスを、専用のフェーズでなくアプリケーション本体の一部として実行します。
つまり、読み終わったテーブルのデータを使って処理を実行していきます。このため、1つだけデータ量が多いテーブルがあっても、出来る処理は先に実行するので、全体として実行時間が短くなる(だろう)という訳です。 

 


Asakusa Framework 0.9.0のSpark出力方法の改善

2016-12-11 00:10:48 | PG(分散処理)

Asakusa Framework Advent Calendar 2016の11日目です。
今日は、2016/12/6にリリースされたAsakusaFW 0.9.0のAsakusa on Sparkの出力方法の変更についてです。

Asakusa on SparkはApache Sparkで処理を行いますが、Direct I/Oの最後の出力(epilogueフェーズ)に関してだけはHadoop版と同じ仕組み(つまりMapReduce)を使用していました。
それが、今回のバージョンで、出力もSparkのみで行えるようになりました。

これに伴い、Asakusa on Sparkの反復バッチ機能で、今まではExporterには反復用の変数を指定できなかったのが、指定できるようになったそうです。(Importerには最初から指定できた)


Sparkから直接出力する機能を使うかどうかは、build.gradleのasakusafw.spark.optionで切り替えられるようです。→コンパイラープロパティー
でもデフォルトは直接出力する状態なので、特に切り替えることは無いような気がします^^;

asakusafw {
    spark {
        option 'spark.output.direct', 'true'
    }
}

入力の方もprologueフェーズの省略をspark.input.directで切り替えられるようですが、これも特に切り替える必要は無いでしょう。