今後投資すべきか、検討する必要のありそうな技術

当たり前ではあるけど、相変わらず計算機分野の技術の流行り廃りは激しい。とてもじゃないが一人の人間、もしくは小さなチームが全部の流行を追う事は不可能。そこで自分の関わる分野に役立ちそうなものをピックアップしてみた。

まず、今ユーザー（生物学者と医師）から出ている課題：

• 生物学は、各コンポーネント（遺伝子など）を見る時代から、それらの関係性を見る時代に確実にシフトしている。しかし、関係性を見ると言ったところで、フラットなPPI等を眺めるだけで得られる知見には自ずと限界がある。可視化から更なる理解を深めるためには、機能モジュールやネットワークモチーフ等に基づいた階層構造の表現が必要。そして、それはインタラクティブ、且つ簡単なオペレーションでなくてはならない。（計算機リテラシーの高い人ばかりが研究者ではない。）
• モジュール／サブネットワークを表現するファイルフォーマットの検証。XMLを使えば容易、というか、もう既にGraphMLやXGMMLなどでサポートされている。しかし、生物学者が自分のデータを可視化してみたいと思ったとき、それを手作業で作るのは容易ではない。Excelなどのシンプルなテーブルで、人間が手でエディットできるような表現は出来ないだろうか？
• 計算機のコア数が増えてきているが、まだ一部の重い処理（レイアウトやモジュール発見アルゴリズム実行時など）を実行する時でも遊んでいる事が多い。
• 実験等から得られた興味のある遺伝子リストから、既知のネットワークを取って来る事は比較的簡単に行えるようになった。しかし、その後、様々なデータベースからアノテーション情報を取ってきたり、ネットワークをマージしたりする事は、割と皆行っているが、初めての人は戸惑う。ワークフロー／ヒストリ機能の実装等で、ほぼ皆が行うような部分は楽に行えるようにしてほしい。
• 公共のデータベースを今一度確認し、有用なものがあればそれへの容易なアクセス手段が必要。
• 異種間のモジュール比較と可視化。この機能への容易なアクセス手法が必要。現状では手間がかかりすぎて、多くの生物学者に気軽に使える機能ではない。一番のネックは、オーソロガスな遺伝子間のスコアファイルをどうダイナミックに生成するか、と言う点。

まあ他にも色々あるが、共通項としては、「ハードコアなユーザーばっか相手にしてると感覚麻痺するぜ。とにかく簡単かつストレスフリーにする方向でやってかないと、便利な機能でも使う人は増えない」と言う感じか。これに関して、インタラクションデザインとか、ドキュメントで解決できる問題についてはひとまず置いておくとして、乱立する新技術の中で、特にパフォーマンスやデータアクセスの部分で使えそうなモノは・・・

GPGPU/CUDA/OpenCL

グラフレイアウトでは、既に大幅な実行速度向上が確認され、実装もされている:

• Cytoscape GPU Assisted Graph Layout Plugin

また、よくあるグラフアルゴリズムをGPU上で実装して比較してる人もいる

• Large Graph Algorithms for Massively Multithreaded Architectures

この技術は当然万能ではなく、速く出来る問題とそうではない問題が割とはっきりしてる。今後暫くは、GPUは昔のCPUのような速度で進化して行くので、使える部分には使いたい。とりあえず、解析関係で、Cytoscape特有のモノに利用出来ないか検討する必要があるかも。

参考になる情報：

• OpenCL Tutorials

Gohara博士によるOpenCL技術の簡単な説明とチュートリアルビデオ。非常にわかりやすい英語なのでぜひ。CPUとGPUで同じアルゴリズムを実装し、その差を比べる部分は、ある特定の問題分野では非常にこの技術が有効であると実感できるはず。

Scala

Scalaスケーラブルプログラミング[コンセプト&コーディング] (Programming in Scala)

JVM上で走るオブジェクト指向＋関数型なハイブリッド言語。何と言っても、関数型の特徴を持ちつつ、JAVAの資産に直接アクセス出来るのは大きい。今後は並列性を意識したコードを書かざるを得ないようになってくるが、いくらconcurrntパッケージが便利だからといって、並列処理の実装がトリッキーである事には変わりない。その代替として検討する価値はあるかもしれない。まだベンチマークも何もやった事無いので、どのくらい実用的なのかまだよく理解出来てないけど。

オントロジやSemantic Web、Webサービス関連技術

Programming the Semantic Web: Build Flexible Applications with Graph Data

データ統合の過程で、いつも問題になるのは「どの名前の項目が、どのデータを指すのかがデータベースごとにバラバラ」と言う点。これはどちらかと言うとデータを提供する側の問題でもあるのだが、データを消費するプログラムを書いている者として、実際にどういう形でデータが整理され、公開されれば使いやすいのかを提案出来るようになるにはこの辺りの技術の理解も必要。現実問題として、「こんな形（RDF）で保存されたデータがあるけど、これをCytoscapeで使うにはどうしたらいいかな？」なんて相談も実際に出てきてるし。しかしこの分野は、使い方を間違えると必要以上に問題をややこしくしてしまう可能性もはらんでいるのでバランス感覚が必要か？

データへのアクセス手段としてのAPI標準化などは、DBCLSの方々やEBI何かの努力もあって少しずつ便利になってきている。これもその成果の一つ

• PSICQUIC Reference Implementation

間もなくこれを使うクライアントも公開出来そう。

Hadoop

Hadoop

MapReduceのオープンソース実装。巨大レコードの分散処理なんかでよく話題に上るけれど、この分野の人にも関係ありそうな、こんなプロジェクトもある：

• Mahout: Machine Learning Library for Hadoop

ただ、スーパーコンピューターセンターの人たちも、各ノードごとに大量のメモリを積んだ新しいマシンの計画を立てているようなので、そっちが気軽に使えるようならば、餅は餅屋に任せておいた方がいいかな。