Data Visualization Japan Meetup 2020（2020年12月28・29日開催）における、大野 圭一朗さん（カリフォルニア大学サンディエゴ校 医学部）の講演です。生物学研究のためのツール開発という立場から、現代のコードベース可視化の実践を紹介します。
カリフォルニア大学サンディエゴ校の医学部で勤務しています、大野と申します。
大学に勤務していると言っても研究者ではなく、あくまでソフトウェア開発者という立場です。大学はある種の非営利団体なので、その中に他の団体と共同でいろんなプロジェクトが立ち上がり、そちらの組織にも名前が入っていたりするのですが、基本的にはサンディエゴをベースに大学の中でソフトウェアを開発しています。
この会はオーディエンスの方がいろんな分野から来られているので、テクニカルなことばかりに集中してもなかなか面白くない可能性があるので、今回は長めのイントロとして私がやっているようなことをお話ししながら、最終的に技術的な部分を紹介する、という形で進めたいと思います。
生物学と可視化
研究室のタイトル的なものは、以前は「ネットワークバイオロジー」を掲げていましたが、今はもっと広く「ゲノミクス」というカテゴリーで考えていただければいいと思います。
ゲノミクスという性質上、生物すべてに共通するものなので、扱う生物種は本当にいろいろです。もともとは技術的な制約から酵母などから始まって、今は人間の疾患や哺乳類の研究をしている研究者もたくさんいます。
2020年という特殊な年
2020年の主役はこれですよね——コロナウイルスの実際の遺伝配列（シーケンス） です。
そういうこともあって、今年は一般のメディアも含めて生物学に関係する用語が飛び交った年だったと思います。PCR（ポリメラーゼ連鎖反応） という言葉を聞かない人はいないでしょうし、それに使うプライマー、ゲノムを解析してウイルスの系統樹を作る技術、そしてワクチンの話題で mRNA という言葉が毎日登場する。
私たちは特定の生物種を研究しているというより、汎用的に使える手法——いわゆるバイオインフォマティクス——でいろんな生物種を研究しているので、COVID-19 に関する共同研究者の仕事を紹介しながら、可視化との関わりをお話しします。
生物学のデータはほぼすべて公開されている
生物学分野のデータは、特殊なものを除いてほぼすべて公開データとして誰でもアクセスできるようになっています。
リンクの先へ行くと、実際にリファレンスのゲノム——このコロナウイルスのゲノムデータにアクセスできます。ウイルスというのは非常に効率がいいと言ったら変ですが、情報量としては本当に3万文字くらいで表せるゲノム情報で、今の世界をぐちゃぐちゃにしているという感じです。
データとしては本当に単純で、FASTA という名前のフォーマットで、情報量もそれほど大きくありません。
ただ、元のファイルには ATGC という文字列が並んでいるだけで、**これを見て何か分かる人間は基本的にいません。**なのでコンピュータの力を借りて、今わかっている情報をその上に乗せたり、ゲノムブラウザというインタラクティブなツールを使ったりしながら、研究者は日々研究しているわけです。
タンパク質相互作用ネットワーク
ウイルスが人間に対して何か悪さをして、最終的に疾患として現れる——それがなぜ起こるかというと、ウイルスのタンパク質と、ホストである人間側のタンパク質が何らかの相互作用を行うからです。
そういうものを解析するとき、相互作用はグラフ＝ネットワークとして表せるので、シンプルなネットワーク図で全体のインタラクションを把握できるようにするわけです。
この論文では、網羅的に解析した結果をネットワーク図として表しています。
薬というのは「この病気が出てきたからすぐ作ろう」というのは無理だというのは、今年の状況を見てこられた方は皆わかると思います。開発に非常に時間がかかるのに対して、ウイルスは待ってくれない。
そこで研究者や医師が最初に考えるのは——すでに臨床試験が終わって他の病気に使われている薬があって、それが同じような作用機構で同じようなタンパク質をターゲットにするなら、この病気にも使えるんじゃないかということ。この ドラッグリパーパシングの研究でこういったネットワーク可視化が実際に使われています。
余談ですが、この論文は被引用数が970。せいぜい半年ほどでこんな引用数が出るのは普通ではないので、いかに今、世界中の研究者がこの部分に寄ってたかって研究しているかが端的に分かる数字だと思います。
生物学で使われる可視化の種類
ネットワークは生物学で使われる可視化のごく一部です。
- アライメントビュー ——塩基配列やアミノ酸配列を比較するとき。昔は目でやっていた時代もあったようですが、基本は機械で並べて、どこが変異しているのかを目で見られるようにする
- ゲノムブラウザ
- タンパク質の構造ビューア ——タンパク質は3次元構造の状態によって働きが決まるので、その3次元の状態を見られるようにする
- ネットワーク図 ——相互作用
- 系統樹
Nextstrain に行くと、系統樹と世界中への伝播をダッシュボード的に作り上げたソフトウェアがあります。研究ツールと報道ツールの中間くらいという印象を私は受けました。生物学で使うツールは、複数の異なった形のデータを統合してダッシュボード的にし、そこで探索的な可視化を行うということが割と頻繁に起こります。
データ型と可視化手法の対応
COVID-19 関連研究で使われる情報を、コンピュータの用語に置き換えると——
| 生物学のデータ | 計算機的には |
|---|---|
| 遺伝子配列 | 文字列 |
| 3次元構造 | 座標＋文字（アミノ酸） |
| 薬剤との相互作用 | グラフ構造 |
| 感染経路 | グラフ構造 |
| 系統樹 | ツリー |
つまり——ウイルスの研究に限らず、計算機はある種、生物を研究するためのインフラ的な立場になっている。だから私のような立場の人間が存在するわけで、本業は生物学者のためのツールやインフラを整えることです。
余談 ― 犬の年齢
私の職場から出た論文の一つに面白いものがあって、ニューヨーク・タイムズでも記事になりました。
昔から「人間と犬の年齢を比べるときは7を掛ければいい」という説がありました。俗説なのかサイエンスのデータに基づいたものなのか私は知らないのですが、実際に調べてみるともう少し違うカーブを描くんじゃないか、というのを私の職場の大学院生が論文にして出したんです。犬という身近な動物を使った研究だったこともあって、日本語でもニュースになっているのを見つけました。
ゲノミクスは生物に共通する基盤を研究しているので、生物種としては本当にいろんなものを扱っています。とはいえ研究予算が集中するのは難易度の高い疾患なので、どうしてもがんなどを研究する場合が多いです。
私たちの仕事
遺伝子から、最終的に生物上に現れるフェノタイプ（表現型）を予測したり、その関連性を調べたり——そういったことを計算機を使って研究している職場です。
中でも私たちはネットワークやパスウェイ——化学物質と人間のタンパク質、あるいはタンパク質同士が集合したコンプレックス、そういったもの同士の反応経路や作用の仕組みを中心に研究しています。がんの研究、DNA のダメージを修復する機構、老化とは何か——そういうものを分子生物学的に研究しているのを、計算機側からサポートしています。
実際に何をやっているかというと——
- 解析の部分：研究者が書いたプロトタイプ的なコードやアルゴリズムを、一般の生物学者が使えるようなツールにまとめる
- 可視化の部分（私が主にいるチーム）：新しい可視化手法そのものを開発・研究するのではなく、可視化研究者が作ってある程度評価の定まった手法を組み合わせて、より複雑な探索的可視化ができるアプリケーションを作る。あるいは論文に合わせてカスタムのツールを作って最終的な図を作成する
バイオインフォマティクスという言葉は分かりにくいのですが、やっていることは意外と地味で、普通のソフトウェアエンジニアがやっているようなことです。
インフラ整備とお金
インフラ整備には必ずお金の問題が出てきます。**こういうソフトウェアは基本的にそれ自身がお金を生みません。**使う人が多くても、その人からお金を取るというよりは、どこかからお金をもらってきて開発するという形になります。
毎年いろんなグラント（助成金）に応募するのですが、面白いファンディングソースとして Chan Zuckerberg Initiative があります。Facebook のザッカーバーグさんと奥さんがやっている慈善団体で、そこが「Essential Open Source Software for Science」という枠を作って、科学研究の分野で広くインフラ的に使われているソフトウェアに対してお金を出しましょうという基金を運営しています。
私たちも応募して通ったのですが、サイトを見ると pandas、Bokeh、NumPy、Jupyter、Binder など、聞いたことがあるプロジェクトがいくつもあります。これだけ広く使われているソフトウェアでも、持続的に開発していくのは難しいという現状があるので、非常にありがたい基金です。日本も含めて、起業家の方なども含めてこういったサポートができるといいなと思ったりしました。
作っているもの
NDEx ——生物学方面で使うネットワークやパスウェイの共有サイトのようなものです。Pfizer や Roche といった製薬会社も資金を出してくれています。パブリックにできないデータについては、彼らが自前のサーバーにデプロイして機密性のあるデータをそちらで使う。それとは別に私たちがパブリックのサーバーも運営していて、キュレーターが、たとえば今年なら COVID-19 関連の信頼性のあるネットワークデータをコレクションとしてまとめる、といったことをしています。
Cytoscape ——汎用のネットワーク可視化ソフトです。比較的大規模なものから、人間が手で描くようなパスウェイ図まで可視化できます。もともとは私のボスが2003年ごろに開発し始めたもので、2020年現在も続いている。この「継続させる」というのが非常に難しいのがこの分野のソフトウェアの特徴ですが、なんとか生き残っています。
カスタムツールを作る
私たちに関して言うと探索的な可視化ツールを作るのですが、データの特殊性もあってニーズが複雑で、研究者が見たいものも研究内容によってだいぶ変わるので、カスタムのツールを作る必要性はずっとあります。
最近作っているのが HiView です。巨大なネットワークに対して階層的なクラスタリングを行い、その階層を circle packing で表現して、どんどん展開して中に入っていけるブラウザと、それに対応する各種データを表示するダッシュボードです。
ただ、技術的な要素を見ていくと特殊なことは何もやっていません。
- 階層構造の部分：D3 の circle packing をベースに、インタラクションを後から追加
- ネットワーク（node-link diagram）：Cytoscape.js（これも私たちのチームが作っている JavaScript ライブラリ）
- バーチャートなど：1から作る必要もないので react-vis（Uber が最初に作ったライブラリ）
- UI：Material-UI（大元のデザインは Google、オープンソースの実装として React で使える）
使っている技術の要素は本当にシンプルです。つまり——基本的なパターンはだいたい有り物のツールでカバーできる。
**データの種類と量が決まれば、自ずと使える手法が決まり、最近は実装まで手に入る。**このあたりは昔に比べるとずいぶん楽になったと思います。
手法についても、**何を見せたいかがあって、データの種類と量が決まれば、「これは散布図」「これはヒストグラム」とかなり自動的に決まってくる。**チートシートのようなサイトもいくつかあるので、必要なものが実装も含めて手に入るかをまず調べるのが、最近は大事になってきています。
それでも自分でコードを書く必要があるケース
大きく3つだと思います。
- 大量のデータがある
- 比較的複雑なインタラクションが必要
- 可視化手法自体を作らなければならない
3つ目はどちらかというと可視化自体を研究している研究者の領域なので、私はあまり踏み込みません。今日は1と2について実例を交えてお話しします。
問題の複雑さ
一番簡単なのは単一種類のデータを可視化したいというケース。これは Excel でもライブラリでも比較的簡単に作れます。
データ型が増えれば、それに対応する違う種類のチャートを作らなければならない。逆にデータは単一でもものすごい量があると、既存の手法にただ読み込ませるだけで大丈夫か、というケースが出てくる。
そして大量の、いろんな種類のデータをそれぞれ相互につなげて、アクションに基づいて見え方が変わる——そうなるとかなり複雑になっていきます。
私が主に作業しているのはこのあたりで、構成要素自体は1から作らなくても、量的な問題や特殊なインタラクションに時間を割いています。
① 複雑なインタラクション ― Plotly Dash
**Tableau のようなコマーシャルツールでもある程度双方向性のあるダッシュボードは作れます。**もちろん限界があって、描きたいコンポーネントがなかったり、必要なインタラクションがなかったりする場合はどうしても自分で書かざるを得ない。
ただ、ほとんどの人——特に分析自体をやって最終的な可視化まで作っている人——にとって、JavaScript で1から書くのはハードルが高い。
いま、データ分析者にとって Python は非常に大きな存在です。「Python で1から書けてしまえば楽だろうな」と思っている人は多いと思います。
そこで Plotly Dash です。JavaScript を書かなくてもインタラクティブな Web アプリケーション／ダッシュボードが作れてしまうツールキットです。
Plotly（カナダの会社だと思います）のビジネスモデルはエンタープライズエディションの方で、可視化部分はオープンソースなので、Dash も基本機能は全部フリーで使えます。
実例を見るのが一番早いと思いますが、基本的な部品が全部揃っているので、それを組み合わせて割と複雑なダッシュボードを Python のみで構築できる。
今は「1か0か」ではなく、こういう中間的なツールキットもあるので、データ分析側にいる人はこのあたりも考慮するといいと思います。
ちょっとびっくりしたのですが、**英語の書籍も出ていないような気がするのに、日本語で書籍が出ていました。**興味がある方は見てもらうと実際どういうものか分かると思います。
また、Plotly から私たちのカナダのコラボレーター——Cytoscape.js を作っている同僚——にアプローチがあって、Cytoscape.js を Dash で使えるコンポーネント「Dash Cytoscape」 が用意されています。その解説もこの日本語書籍にはかなりページを割いて書いてあります。
もちろん限界はあって、描画部分までいじりたくなると、最終的にはモダンフロントエンドと呼ばれるジャングルに入るしかない。ただそこまで行く前に、今公開されているコンポーネントで目的のアプリケーションが作れるかどうかをちゃんと試した方がいい。
私の同僚もこれで作り始めたのはいいけれど、データ量的に対応できなくて最終的に私に仕事が回ってきたこともあるので、そのあたりの見積もりも大事です。
② 大量のデータ ― deck.gl
可視化のアプリケーションを書く＝ほぼ Web ブラウザで見るという流れになってきています。
私はネットワーク描画をかなり長く扱っているのですが、100万や200万といったノード・エッジをシンプルな node-link diagram で表す——そんなものをブラウザで実行するのは、昔はあまり考えられませんでした。今は技術的に可能になってきている。
ユースケース
エッジ数の多い密なネットワークを、シンプルに node-link で表示したい。でも数がめちゃくちゃ多い。そして全体の傾向を見たい——クラスタリングを施した後、クラスター同士が密に固まった状態をざっと表示して、同時に Google マップのようにズームイン・ズームアウトもできるといいよねという、無茶なお願いをしてくる人がいるわけです。
有り物で自由にそういうことができるものはないので、作るとしたらどのくらいの手間かを考え始めました。
私たちは最終的なアプリケーションを作る人間で、解きたい課題があってそれに技術を持ってくる形なので、CG の専門家もいないし GPU に詳しい人間もいない。できるだけハイレベルな API を持つライブラリがあればな、と探していたところ——都合のいいものがありました。
deck.gl
もともと Uber が作っていたライブラリです。
彼らのサイトを見ると**地理空間データの例が非常に多い。**日本だと食べ物の配達のイメージが強いと思いますが、彼らがメインで最初に始めたのは配車サービスなので、そちらのデータを可視化したい欲求があったのだと思います。
**ただ実際は汎用的なツールです。**もともと Uber で作られましたが、今後は比較的オープンな体制で作っていくことも決定しているようなので、ロックインもあまり心配しなくて大丈夫だと思います。
deck.gl を使った例として kepler.gl があります。地理空間データを手間少なく地図に重ねて表示できるツールで、下で走っているのが deck.gl です。
**よく間違われるのですが、例が地理空間可視化ばかりなだけで、実際は汎用のツールキットなのでいろんなことができます。**Uber は自動運転の研究もやっていたので、その結果を可視化するようなものも全部これで作っていると、開発者のワークショップで聞きました。
なぜ自分たちで作ろうと思ったか
100万を超えるエッジやノードを持ったデータの概要（オーバービュー）を見たいというのが主なモチベーションです。
クラスター同士がそれぞれ近い場所に集まって、カラーコーディングされて、必要に応じてさらにデータレイヤーを上に乗せられる——そういう巨大な白地図のようなものが作れればいいなというので始まりました。
deck.gl の考え方 ― レイヤーの集合
deck.gl はレイヤーの集合で作ります。基本的な考えは「可視化したいものを、いくつかのレイヤーに分割して表現できないか」。散布図用のレイヤー、直線を引くだけのシンプルなレイヤー——そういうプリセットを重ね合わせて作ります。
グラフを描画したい場合は、ノードを表示し、ラベルを付け、ノード同士を線で繋ぎ、必要に応じて背景を描く。つまりノードレイヤーとエッジレイヤーを別々に既存のもので作ればいい。
技術スタックは下から——
- WebGL（ブラウザ技術）
- luma.gl（Uber が作った、WebGL に対するもう少し高レベルな API のラッパー）
- deck.gl
レイヤー自体の描き方は割と簡単に切り替えられるので、2次元から3次元に切り替えて、複数のレイヤーが重なった3次元空間の表現——2.5次元と呼んだりします——もやろうと思えばできます。
実例
40万ノードくらいのものです。あらかじめ Python でクラスタリングを施し、レイアウトしたものを描画しています。さすがに分析やレイアウトをオンザフライでやるのは現実的ではないので、そこは別でやっています。
ただズームやパンといった基本的な部分については、このくらい何も考えずにやっても普通に描けるパフォーマンスが、今の機械・ライブラリ・ブラウザのおかげで出るようになっている。
50万ノードくらい入れると、ここまで行くともう単なるメッシュにしか見えないのですが、何も考えずとも比較的こういうものを deck.gl で作れるということが確認できました。
D3.js とどう違うのか
ちゃんとライブラリに合った役割を割り当てるのが大事です。
- D3.js：カラーパレットの生成や circle packing の計算といった、数学的なライブラリとして使うのは今でも非常に便利。それが今後のメインの使い方として正しくなってくると思います
- deck.gl：ひたすら力技で大量のデータを描くユースケースに異常に向いている
ただし巨大なデータを一気に描画する場合、その場で解析やレイアウトを行うのは現実的ではないので、その部分は大きな計算機であらかじめ計算しておいて、どこかに蓄積する。こういう役割分担が今後は大事になってくると思います。
まとめ
D3.js でチャートを作る作業自体は面白いんですけれども、最近はいろんなものがすでにあるので、既存のものを利用する。「自前で作らないと気が済まない」という欲求と戦うのが、今後は結構大事だと思います。
今の段階では単純にメモリに流し込んだものを無理やり描いているだけなので、実用的なアプリケーションにするには、1000万といったオブジェクトがあってもダイナミックにロードすれば、ブラウザでも十分扱えるはずで、そういう仕組みができないかを今やっている最中です。
生物学的な話からスタートしましたが、まとめとしては——
- 比較的複雑なアプリケーションを作る場合でも、必要なツールキットは非常によく整備されている。まずそれを使えないかよく考える
- 足りない場合は、中間的な Dash を使う
- それでもできない場合は、deck.gl で自前のレンダリングを書く
作る側としてはどんどん便利な世界になってきているので、ぜひこのあたりも試してみてください。以上です。