Asakusa Frameworkとは（2020版）

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

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

---

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

2020年に出たAsakusaFWの新バージョンは無いですね＾＾；もうだいぶ枯れてますから…。

以前から個人的に注目していた、対応するJavaのバージョンですが、今年はHadoop3.3.0がリリースされて、ついにJava11対応しました！
これでHadoopに依存してJava8止まりだったAsakusaFWもJava11に対応できる…はずですが、まだ対応されていませんorz
これには、AsakusaFWの開発者がTsurugi DBの開発で忙しいという面があるようです＾＾；
来年辺り、Java11対応するといいなぁ…。

 

embulk-parser-poi_excel 0.1.10

embulk-parser-poi_excel 0.1.10をリリースしました。
（本当は0.1.8なんだけど、リリースをミスって0.1.10になりましたorz）

機能的には、cell_addressを追加しました。
cell_addressは現在の行以外のセルの値を取得できるものです。

---

その修正のために久しぶりにGitHubを見たら（なんとびっくり）issueが上がっていたので、それも対応しました。

（特にxlsxファイルにおいて）結合セルが多いと、処理がとても遅くなるというものです。
POIというかExcelの結合セルの仕様上仕方が無いんですが、TreeMapを使ってキャッシュを作ることで高速化しました。
メモリー使用量的に問題になるかもしれないので、search_merged_cellオプションで元の方式と切り替えることが出来ます。
（このオプションは昔からあった（ドキュメントには書いてなかった＾＾；）もので、元々はfalse,trueで切り替えていたが、今回none,linear_search,tree_searchに変更した）

（追記：よく考えたらあの実装ならTreeMapでなくHashMapでも良かったので、ver0.1.11でhash_searchも追加した）

---

さらについでに、POIのバージョンを新しくしました。
3.13だったので、3系の最新である3.17に。

既に4系が出ていますが、それはいずれ変更したいと思います。

embulk-parser-poi_excel not available ver 0.1.8-0.1.9

embulk-parser-poi_excel 0.1.8や0.1.9をインストールしても使えません。生成されたgemファイルの中が足りない（classpathディレクトリーしか存在しない）為、インストールしても正しく認識できないようです。

RubyGems上は0.1.8と0.1.9を非公開にしました。

どうも、Cygwin上でgradlewのgemタスクを実行すると正しいgemファイルが生成されないようです。（昔はこれで出来たはずなのに）
コマンドプロンプトからgemタスクを実行すると正しいgemファイルが生成されました。

というわけで、本来0.1.8として公開したかったバージョンは0.1.10で公開されています。

SQL to AsakusaFW：UNION

Asakusa Framework Advent Calendar 2019の24日目、SQLをAsakusaFWに変換するポイントについてです。

SQLのUNIONには、「UNION」と「UNION ALL」があります。
UNIONは重複データが有る場合はそれを排除して1レコードのみ出力しますが、UNION ALLは重複があっても構わず全て出力します。

UNION ALLはAsakusaFWではcore.confluent演算子がすばりそのものです。

UNIONは重複排除をするので、MasterCheck演算子で（全カラムをキーとして比較し）存在しないものだけ出力すれば良い、ような気がしますが、厳密には違います。
s1 UNION ALL s2 UNION s3の様に、複数のSELECTをUNION ALLでつないで最後だけUNIONになっている場合、それまで重複ありで複数レコード出力されていたものが、最後に重複排除されてしまうのだそうです。
そのため、UNIONはFold演算子で（全カラムを集計キーとして使用し）集計キー毎に1レコードだけ出力するのが良さそうです。

SQL to AsakusaFW：分析関数

Asakusa Framework Advent Calendar 2019の23日目、SQLをAsakusaFWに変換するポイントについてです。

SQLでサブクエリーと並んで少々やっかいな（と思う）のが、row_number等の分析関数です。

これはGroupViewで簡単に…というわけにいきませんが、GroupSort演算子を使えば実現できます。
複数の分析関数が使われている場合、パーティションキー（集約キー）とソートキーが同一であればひとつのGroupSortで実現できると思いますが、そうでない場合は、複数のGroupSortを使わざるを得ないでしょう。