既存プログラムからAsakusaFWへの変換

Asakusa Framework Advent Calendar 2019の2日目です。

Asakusa Frameworkをいきなり採用しようという人は稀（というか居ないのでは？＾＾；）であり、大抵は「既存の遅い処理をAsakusaFWに置き換えてみよう」というところから始まると思います。

しかし、どんなプログラムでもAsakusaFWに置き換えられるかというと、やはりそんな事は無く。
特に面倒なのは、処理の途中で（条件によって）SQLを実行するようなタイプです。（そういう作りだからこそ、N+1問題を引き起こして実行が遅くなりがちな訳ですが…）
AsakusaFWはまとめて（分散して）処理を行うので、条件によって必要性が変わるデータでも、全て事前に結合しておく方がコーディングが楽です。
なので、結合条件が細かく変わるケースや、結合するデータが複数レコードになるケースでは、AsakusaFW化するのは面倒になります。

ただ、単独のSQL文（SELECTやUPDATE）であれば、ほぼAsakusaFW化することが出来ると思います。
明日以降のアドベントカレンダーで、SQLをAsakusaFW化する際のポイントを説明していきたいと思います。

Asakusa Frameworkとは（2019版）

Asakusa Framework Advent Calendar 2019の1日目です。

アドベントカレンダーの初日ということで、2019年時点のAsakusa Frameworkの紹介を書いておきたいと思います。

---

Asakusa Frameworkは、分散バッチアプリケーションを開発・実行する為のフレームワークです。
同一のソースをリコンパイルするだけで異なる実行基盤、すなわちHadoop（MapReduce）, Spark, M3BP, Vanilla用のバイナリーを生成することが出来ます。
また、分散処理とは別に、ファイル同士を結合して処理するにはとても便利だと思います。

2019年に出た新バージョン0.10.3だけですかね＾＾；
バグフィックスの他は、Direct I/O JSON（jsonファイルの読み書き）が追加されました。

個人的な注目点は、AsakusaFWが依存しているHadoopのバージョンアップです。
HadoopがJava8までしか対応していないのでAsakusaFWもJava8でしか使えないのですが、Hadoop3.3.0でJava11対応するらしいので、これがリリースされたらAsakusaFWのJavaの対応バージョンも上がると思います。
が、現状ではHadoop2系が対象なので、Hadoop3系になって大丈夫なのかなぁという思いが無くも無いです＾＾；（少なくとも、現在AsakusaFWを運用しているシステムであれば、動いている環境はHadoop2系のはずなので、バージョンアップは簡単ではないでしょう）
また、Asakusa on Sparkの為にはApache SparkもHadoop3.3.0およびJava11に対応してくれないといけないので、簡単にはいかなさそうな気がします…。

AsakusaFW 0.10.3 Direct I/O JSON

2019/6/12にAsakusa Framework0.10.3がリリースされた。→リリースノート

一番の目玉はDirect I/OでJSONファイルの読み書き（のExporter/Importerが生成される）が出来るようになったことかな？
もちろんAsakusaFWはデータモデルというシンプルなクラスしか扱えない為、配列やらネストしたJSONは扱えないと思うけど。

これに伴って、DMDL EditorXの入力補完機能にdirectio.jsonを追加した。

---

後は例によって細かいバグ修正等。

ロギング演算子で上限境界の無い型引数が指定できるようになった。
…ロギング演算子を使おうと思ったことが無かったので、全然気付かなかった＾＾；

Hiveの入出力データ（orcファイル）のカウント情報のバグ修正。
レコード数とバイト数に同じ値が出力されていた＾＾；さすがにそんなデータは無かろうてｗ

Asakusa on Sparkで、Direct I/Oの出力ファイル名のパターンに「ランダムな値」を指定できるようになった。
ランダムな値とは「[0..9]」みたいなやつ。ワイルドカード「*」とかは以前からちゃんと使えていた。

com.asakusafw.bridge.api.Reportがdeprecatedになった。
ちょっと前のブログで書いた、パッケージ違いのReportクラスがあって紛らわしいという問題。ユーザーが使ってはいけない方にdeprecatedが付けられた為、間違ってimportするとコンパイル警告が出るようになった。
（このdeprecatedはまさにユーザーが使うのは非推奨という意味であり、廃止予定という意味では無い）

BinaryStreamFormat.createInputで使うDelimiterRangeInputStreamがdeprecatedになった。
これは将来廃止予定という意味のdeprecated。今後はLineFeedDelimitedInputStreamを使う。

BinaryStreamFormat.getMinimumFragmentSizeでLong.MAX_VALUEを返すのは駄目になった。
というか、Long.MAX_VALUEが返された場合の挙動がバグだったらしい。
getMinimumFragmentSizeは、入力ファイルを分割しない場合は-1を指定する。基本的には親クラスのデフォルトメソッドを使っておけばいいようだ。

AsakusaFW Reportクラス

Asakusa FrameworkのReport APIで使用するReportクラスでハマったのでメモ。

OperatorクラスではReportクラスを使って「Report.info("message");」のようにログ出力することが出来るが、Reportクラスには以下の2つがあり、前者を使うのが正しい。

• com.asakusafw.runtime.core.Report
• com.asakusafw.bridge.api.Report

後者はAsakusaFW内部のクラスらしいのだが、誤ってimportしてもOperatorクラス上は普通にコーディングできてしまうので、間違いに気付きづらい＾＾；
Operatorのテストを実行すると例外が発生するが、知らないと意味不明な感じの内容だ…。
（最初はAsakusaFWのバージョンアップによってReport APIの初期化方法が変わったのかと勘違いしたよorz）

DMDL テンプレートSPI

Asakusa Framework Advent Calendar 2018の24日目、拙作DMDLのテンプレート機能の紹介です。

これはだいぶ昔に作った機能なのですが、AsakusaFWのSPIの機能を利用して独自のDMDL属性（@template）を作り、テンプレートにその属性の内容を埋め込むものです。
つまり、これを使ってImporter・Exporter（FromCsv, ToCsv）のソースファイルを生成することが出来ます。

DMDL EditorXにはImporter・Exporterを生成するウィザードもありますが、個人的には微妙に使いづらく、結局、既存のクラスをコピペして修正して使うことが多いです。

その点、このテンプレート機能を使う方が楽そうです。（なお、テンプレートエンジンにはFreeMarkerを使っています）

ただ、AsakusaFW0.7の頃に作った物なので依存関係が古く、build.gradleに記述する際はAsakusaFWやHadoopの依存関係をexcludeしないといけません。
この辺り、Gradleでライブラリー化（Mavenのpomを生成）するときに依存関係を除外する方法があればいいんですけどねぇ。