前回の記事で、自作のデータ分析ライブラリADAPTの紹介をした。本記事はその開発に関して色々と思うところを書き並べるものである。しょうもない自分語りなので興味のない人は引き返してほしい。
ADAPTは私が大学院生時代からちまちまと作ってきたライブラリである。OpenADAPTはそれらのうち、特に重要な、そして現状C++で他に代替できるものがなさそうなデータ処理部分のみを切り出してゼロから再構築したものだ。元々は自分専用であったり研究室内のみで公開したりと限定的な用途でのみ利用してきたのだが、そろそろ個人での開発に限界を感じてきており、今回、公開へと踏み切った。
元を辿れば、これは私が趣味で作り始めたデータ分析ライブラリだった。しかし私の研究が進むにつれて単なるデータ分析だけでなくデータの3D可視化やハードウェア駆動中の内部データ処理などへ応用範囲が広がり、いつからか研究室に向けて公開するようになった。特に前バージョンは利用者も増え、研究室内で一定の意義と市民権を得ることができた、と認識している。しかし私の研究室は理学系かつITに疎いところなのでこのような開発に興味を持ってくれる人がおらず、誰一人として開発を手伝ってはくれなかった。開発がかなり大規模化し(個人開発ながらソースコードが11万行に達した)博士論文の研究と並行してメンテナンスし続けることに限界を感じていたにも関わらず、その困難を結局誰も理解してくれなかったのだ。理学系研究室の人間はその大半が大掛かりなソフトウェア開発の経験がない、せいぜい数日で出来上がってしまうようなしょっぱいプログラムしか書かない連中なので、そもそも理解する基礎がないのである。ただソフトウェアの価値を彼らが認知してくれるとすれば、研究上直接的に役に立つ場合のみであるというのはまあ当然の話で、ADAPTを応用して作成したソフトウェアならともかく、基礎も基礎のデータ分析ライブラリともなれば実用までがあまりに遠く(それが応用上どれだけ有意義だとしても)理解されないのは仕方がない側面もある。なぜなら、他にも代替する手段がありうるからだ。その代替手段は大抵の場合、大変に不便で応用性や再利用性の欠片もない愚策なのだが、不便の何たるかを知らない彼らにとっては満足できるものなのだ。彼らは確かに無知だが、彼らの無知さにばかり責任を求めるのは酷ではある。
今回ADAPTのオープンソース化に踏み切ったのは、このような環境下で何とか開発を継続するための協力者や理解者を求めたから、という点もある。実際に得られるかどうかは、まあ、博打である。元手が皆無なので負けてもそれほど損失のない博打だ。せいぜい、サンプルプログラムや記事を書いた手間が無駄になるくらい。
C++のデータ分析ツールって需要あるの?という疑問については、正直よくわからないが、一応私の分野では先駆者がいる。私の属す素粒子宇宙系では昔からROOTというCERN開発のフレームワークが使われているのだ。ROOTはスクリプト的に使われることが多いものの、C++のライブラリには違いない。
しかし、分野内でデファクトスタンダードと化しておりしばしば強制的に使わされる私に言わせれば、ROOTはゴミである。ソースコードを見ても何をしているのか分からない、モダンC++とは異なるかなり古めかしい流儀で設計された機能群。グローバル変数や静的メンバ変数が暗黙的に多数使われているらしく、挙動が難解。JOIN相当機能がないのでデータが複数に分かれていたりすると地獄。インタプリタがC++標準と異なる挙動をするので混乱を招く。ライブラリとして使おうとするとだいたい動かない。他にも問題点多数。とかく使いにくくて敵わないのだ。歴史が長いだけあって非常に多機能ではあるが、歴史が長いだけあって前時代的な設計になっている。既に素粒子宇宙系の中でもROOTを捨てるグループが多数出てきている。
C++でROOT以外だと、個人開発のものは多少見つかるのだが、私の用途に適してはいなかった。じゃあPythonにすれば、と思わなくもないが、Pythonは素の速度が信じられないほどに遅いので、大規模なデータをまともに扱えない。過去幾度となくPythonでデータ処理させようとしてはその鈍足さに絶望してきた私にとって、あれに移行する選択肢はない。よって、私は自作することにした。
ADAPTは、ライブラリと呼ぶことさえ烏滸がましい最初期のがらくたを除いて、今回公開したものが都合3バージョン目である。
最初に作ったものは実質的なプロトタイプで、バージョンは0。階層構造は当時から採用されていたが、いかんせんC++歴1年程度の私の知識では真っ当なものは作れなかった。
一応このときの経験から様々な知見を得ることが出来、再設計されたのがバージョン1系、現在研究室において主として稼働しているバージョンである。しかし十分に整理することはできず複雑怪奇なものになってしまった上、随所に原因不明のバグも発生した。特にJoinの仕組みなどは1.Y系で本格的に導入されたのだが、C++歴2年ほどで言語を使いこなせていなかった当時の私ではどうしても限界があった。とはいえ機能的には充足していたこともあって、私の学生時代はこのバージョンで乗り切ることが出来た。
バージョン2系―――これが前記事で紹介したOpenADAPTに相当するものなのだが―――は、獲得した知識と経験だけを残しそれ以外の資産をまるごとスクラップにすることで出来上がった。過去のコードはほとんど残っていない、ゼロからの構築だった。コンセプトはともかく設計が愚かしい前バージョンから前進するには、丸ごと捨て去るしかなかった。
今の今までオープンソースにもせず、研究室の一部範囲に対してのみ公開してきたことを思うと、ずいぶん暇なことをしていたんだなぁと思わなくもない。いや、研究上必要だったから作ったんだけどね。
ADAPTは現代のデータベースで最も普及しているテーブルを基本とした関係モデルではなく、階層型+Joinという変則的な仕組みを採用している。そんなものが本ライブラリ以外に存在するのか分からないが、私の用途ではこれが便利だった。予め構造化された数百万から数十億件程度のデータ分析をこなす中で速度と柔軟性を両立しようとして、現状ではこのような構造に行き着いているのである。とはいえ私はコンピュータサイエンスに関しては素人なので、これが私の目的に対して真に最適な方法なのかは判断しかねる。
私が階層型を採用したのは、私の扱うデータは既に構造が確立されており、いちいち組み替える必要のないものばかりだったからだ。そこで、一度データを読み込んでしまえばデータの改変はほとんど起きないことを前提に、走査と抽出の速度に特化した設計を考える中で、今の形に行き着いた。ただ汎用性はPandasなどのほうが遥かに高いことだろう。ADAPTの場合、親子関係の組み換えや新たなフィールド追加などしようものなら新たにツリーを生成するのに匹敵するコストがかかる。ただ将来的には必要になる気はするので、何とかコストを最小化して実装したいとは思っている。
何にせよ、汎用性とパフォーマンスの改善は今後の課題である。そもそも今の設計が、私の求めるパフォーマンスを満足しているのかもテストできていない。旧バージョンより遅くなったりしたら目も当てられない。このあたりは、今後私の研究に本格導入していく中で改善していく。
長年開発してきたライブラリを公開するので、さすがにちょっと緊張している。SlackLogViewerなどは作り始めた時点で間違いなく需要があると確信できたが、こちらはさっぱりである。Pythonによるデータ分析全盛期の現代に、わざわざC++を、それも個人開発のライブラリを使いたがる人間がどれだけいるというのか。しかし、私自身が欲しかったのだから作ったのだし、せっかく作ったものをいつまでも非公開で放っておくのも非生産的ではある。私と似たような悩みを抱えつつ、しかし自主開発するほどのコストを払えずに悶々としていた人のもとに届くことを願って、本記事を投稿する。