HOME > CLIENT VOICE > Elasticsearch & Sparkで実現するエビデンスベースの科学技術データインテリジェンスシステム

Client Voice

グローバルで活躍する未来の政策プロフェッショナルを育成し、政策課題を解決するための基盤を提供する - 日本で唯一の政策研究を専門とする国立大学として、1997年に開学した政策研究大学院大学。世界各国からの留学生が大多数を占め、日々「国民を豊かにするための政策」についての教育と研究が行われています。この政策研究大学院大学に設置されている科学技術イノベーション政策研究センター (SciREX センター) が主導するビッグデータ活用を活用した政策影響評価のためのプラットフォーム構築プロジェクトに、クリエーションライン シニアコンサルタント 木内満歳が参加しました。本稿では政策研究大学院大学 科学技術イノベーション政策研究センター 専門職 原泰史様に本プラットフォームを支える技術について木内とともにお話を伺いました。

まず「政策研究大学院大学 科学技術イノベーション政策研究センター (SciREX センター) 」という組織について簡単にご紹介いただけるでしょうか。

原:政策研究大学院大学 科学技術イノベーション政策研究センター (SciREX センター) では、科学技術を産み出しイノベーションを世の中で多く実現するための仕組みづくり、特に、政策の役割について研究活動を行っています。社会科学の分野では、インターネットやスマートフォンなど、人びとの生活や生き方、あるいは経済システムそのものを変えるような技術を、General Purpose Technology (ジェネラルパーポステクノロジー) と呼んでいます。こうした技術が社会にどのように浸透し、そのとき、社会制度はどのように対応するべきか。2000年代の終わりから我々はこうした問題意識から、「科学技術イノベーション政策のための科学」と題し、研究活動を行ってきました。特に、2014年度に設置された本センターでは、こうした科学技術やイノベーションが社会に与えるインパクトを、客観的な根拠(エビデンス)にもとづいて検証し、合理的な政策の決定/推進を実現するための基盤づくりや人材育成が進められています。

政策はエビデンスに基づいている必要があると

原 泰史氏
原 泰史氏

原:政策として、すなわち税金を用いて政府が特定の科学領域への投資活動を行う以上、それに対する説明責任はあると思うんです。科学や技術がどう世の中の「役に立つ」かは様々な議論があります。しかしながら、世の中の期待感や大学教授の思い込みのようなあやふやな視点ではなく、技術の根拠となる論文やデータといった具体的かつ明確なデータと、その解析手法を組み合わせることでイノベーションの有効性を示すべきです。

ここ数年、残念なことに日本の科学技術論文の生産数は海外と比較してシェアが低下しつつあります。論文の生産性が落ちていることは、イノベーションを生み出す母体となるような科学技術が生まれにくくなる可能性を意味します。こうした状況下で、政策でバックアップする科学領域を把握するために、何らかのロジックにもとづいて政策を決めていくという"エビデンスベース"のプロセスと、それを実現するプラットフォームが必要だと考えました。ヨーロッパなどではRISIS など、そうした科学技術の論文やファンド情報を対象にした統合的なプラットフォームが存在し、一般公開されています。一方、日本ではそうした情報を体系立てたデータベースとして公開されているのは、一部の領域や機関に限られています。極端な例えですが、日本と海外の科学技術を支える状況は ”竹槍と戦闘機" ぐらいの違いがありますね。竹槍で近代的、かつ国際的な競争に勝てるわけがないんです。

具体的にはどんなプラットフォームをイメージされたのでしょうか。

原:データにもとづいて科学技術の推移を検証していくにあたり、科学者が研究活動を行うためのインプット (資金), アウトプット (特許や論文), そしてアウトカム (製品) に着目しようと考えました。誰がどんな論文を執筆したのか、研究にはどの組織からどれだけのファンドが提供されたのか、その技術をベースにした製品には何があるのか、etc... こうした科学技術に関するあらゆる情報がすぐに入手できて、誰もが活用できるプラットフォームがあれば、エビデンスにもとづく政策提言もしやすくなるのではないか - そうした構想から始まったプロジェクトが「SPIAS(SciREX Policymaking Intelligent Assistance System)」です。2016年からプラットフォーム開発に着手し、2016年7月にα版を、2017年3月にβ版をリリースしました。もちろん、データを繋ぎ合わせるだけではエビデンスとはいえません。科学技術の進展により、産業ごとの経済活動がどのように変化したのか、経済モデルと接合する。それによって、科学技術が経済にどのような影響を与えうるのか、現在および将来のシミュレートを可能にする。これが我々がSPIASで目指しているゴールです。

先ほど"科学技術に関するあらゆる情報"と言われていましたが、SPIASでは実際にはどういったデータがベースになっているのでしょうか。

原:現在、SPIASで集約しているデータのタイプは大きく4つに分かれています。

1. 科学技術分野データ … 国立研究開発法人 科学技術振興機構 研究開発戦略センター(JST/CRDS) が発行する科学技術俯瞰報告書
2. ファンドデータ … 日本学術振興会 (JSPS), 科学技術振興機構 (JST), 日本医療研究開発機構 (AMED) など、日本の主なファンディングエージェンシーによるファンドの提供情報
3. 特許/論文データ … 日本および外国の学術雑誌で公刊された論文情報および特許の公表情報
4. 製品データ … 製品に関連するプレスリリース情報

これらの情報を一元化することで、データ間をまたがった検索が実現するだけでなく、ファンド(資金調達)から製品化までの流れ、つまり"パス"を可視化させることが可能になります。

SPIASに集約されたビッグデータを活用することで、イノベーションが起こるまでのプロセスが明らかになり、イノベーションが与える多面的な影響を定量的に計測できるようになるということでしょうか。

原:そうですね。たとえばある政策立案者が「再生細胞医療」に関する情報を調べているとします。関連する研究を行っているのは誰か、どんな論文が書かれ、どれだけのファンドが集まったのか、データどうしが体系的に紐づけられていれば横断的な横串の検索が可能になるので、情報探索にかかるリードタイムを大幅に削減できます。さらに可視化までのパスが用意されているので、担当者の自由な視点にもとづいた解析をアドホックに行うことができ、政策に関する新たなアイデアも創発されやすくなると期待しています。

お話を伺っていると、データの寄せ集め感がすごいというか、データの種類がバラバラでその量も膨大に思われます。これらの科学技術データをSPIASにすべて集約することはかなり大変だったのではないでしょうか。

原氏と木内1

木内:データの量や種類はもちろんのこと、そのほかにもいくつかの技術的課題がありました。SPIASのデータ集約に関して原さんからクリエーションラインにご相談をいただいたとき、我々はその課題を主に「スケーラビリティ」の観点から捉え直すことにしました。具体的には、過去のデータを移行/集約し、さらに将来に渡ってスケールし続けるデータを格納するのに適したデータベースは何か、そして政策担当者や研究者といったITのプロではない方々が検索や統計処理を行うのにふさわしい統計処理環境は何か、そうした視点から現状の課題と求められる要素技術を絞り込んでいきました。

データベースの選定では何を重要視されたのでしょうか。

木内:SPIASの最大の特徴は扱っているメインのデータがファンドや特許、論文であるという点です。しかもその量は膨大で、これからも速いスピードで増えていくことが予想されます。ビッグデータとしてのデータベースの特性にあわせた"スケールするデータベース"を選ぶ必要がありました。

原:僕が今メインで研究をしている「イノベーションの経済学」の分野では、Excel や Stata という統計解析ソフト, もしくは SQL を使って解析をする研究者が殆どです。これまでであれば、データの総量も限られていましたから、データの接合をしなければならないときも、頑張って Excel で vlookup すれば(笑)、なんとかなったわけです。そこからSPIAS を構築しまずは LAMP でのシステム構築を行ったのですが、「どうもこれは限界があるな」と感じていました。木内さんがお話されたように、これからもデータが増大し続けていく分野ですし、しかも、それらを柔軟につなぎ合わせる必要があるわけです。持続可能なシステムを作る上では、LAMPとは違うプラットフォームが必要なことはわかっていました。

クリエーションラインに相談したのは、もともと5年ほど前から安田社長と知り合いだったこともありますが、ElasticsearchやMongoDBといったNoSQLでの実績が豊富だったことが大きな理由です。LAMPに代わるアーキテクチャとしてNoSQLを検討していたところだったので。

木内:原さんからご相談いただいた時点で、SPIASにはすでに10以上の組織にまたがった約数十万本のドキュメント、容量にして100GBほどのデータが約数十個のテーブルに分かれた状態で MariaDB に格納されていました。ですが、データベースの制約からすべてを入れることができていなかった。加えて、データの提供元ごとにスキーマが異なる、さらにその異なるスキーマを受け入れて統合管理することが難しい、といった課題が存在していました。

原:where in したり join したりと、テーブルを結合に結合を重ねて解析してきたので、構造がかなり複雑化していました。リレーショナルデータベースでは今後のスケーラビリティは担保出来ないなあと感じていた次第です。

木内:もうひとつ、データの格納先として重要な選定基準だったのが、検索や各種の集計/統計処理を論文という非構造化のドキュメントデータに最適化して行えるということです。論文を検索する以上、形態素解析を含む全文検索ができる技術であることは不可欠でした。また、論文データベースはその性質上、ドキュメント間の類似探索や論文間リファレンス訴求など、高度な統計処理のニーズが必ず出てきます。しかし論文探索の場合、ドキュメント量が2倍になると関連性探索の検索量は4倍以上になります。当然ながら計算量も指数関数的に増えていくため、スケーラビリティを担保することも同時に実現しなくてはいけない。

これらの課題を検討した結果、我々が出した結論は

・RDBのMySQLからNoSQLのElasticsearchへのデータ移行
・Apache Sparkによる統計処理環境の構築

という選択でした。

ElasticsearchとApache Spark、この2つをデータベース構築に最適な技術として選ばれた理由をお聞かせください。

木内:まずどちらの技術もスケーラビリティを担保できるという点が最大の理由です。

Elasticsearchはドキュメント指向のNoSQLです。スケーラビリティに加え、今回のようなドキュメントデータを格納することに非常に適しています。さらにElasticsearchは「kuromoji」というJavaで書かれた日本語の形態素解析エンジンをライブラリとして使うことができます。また、全文検索機能がデフォルトで利用でき、スキーマ定義が不要であることも、重要なポイントでした。

Sparkに関しては、Elasticsearchとの接続をサポートしていること、そして統計処理や機械学習、グラフ処理などのパッケージが充実していることが大きな理由です。Elasticsearchを統計という面から補完するのにちょうどよい技術でした。またインメモリによるパフォーマンス改善への期待もありました。

実はもうひとつ、今回のプロジェクトでクリエーションラインから提供させていただいたツールに「e19(千京: senkei)」というデータサイエンティストのためのマネージドサービスがあります。Sparkの操作をWebから行えるようにするツールで、Hadoopの分散ファイルシステム「HDFS」から構成されています、データサイエンスのための各種環境をクラウド経由で提供するというイメージでしょうか。今回はSparkを補完する分析ツールとして、実験的にe19を導入させていただきました。クラウドベースのe19により、分析や統計を行うユーザが個人のデバイスを使ってどこからでも作業を行うことが可能になります。

要素技術の選定のあとはいよいよ環境構築とデータ移行に入るわけですが、具体的にはどういうプロセスを辿ったのでしょうか。

木内:もともと、MariaDB 上にデータが構築されていたため、Windows Azure上でElasticsearch環境を3ノード構築し、そこに移行するようにしました。Sparkとe19による統計処理や分析はクリエーションラインが用意するクラウド環境からアクセスできるようにしました。これらの分析環境をAzureと切り離すことでストレステストを実施したかったという理由からです。

MariaDBからElasticsearchへの移行において、最大の難所だったのはRDBからの非正規化(De-Normarize)です。ここでの作業に最初はElasticから提供されているオープンソースのデータ処理パイプライン「Logstash」を使いました。LogstashにはMySQLへ接続するためのJDBCドライバが用意されており、データの取り込み事態は簡単に行うことができます。しかしLogstashは書式がわかりにくく、複数テーブルにJOINを行う際の記法が書かれていません。また複数テーブルのJOINを行うとデータがあふれてしまい、インスタンスのメモリをすぐにオーバーフローしてしまいます。これらの問題に対応するため、最終的にPythonで移行プログラムを作成しました。

正規化されているデータを非正規化するというのはそう簡単にはできないんですね。

木内
弊社 木内

木内:MySQLに代表されるRDBは"情報として有意な単位"でテーブル分けを行います。検索においても複数のテーブルを結合してフィルタリングする必要があります。これらはいわばRDBにおける"お作法"ですね。オンデマンドでJOINするという作業を日常的なユースケースとして想定しないのです。

一方、Elasticsearchのアプローチはこれとはまったく真逆です。ドキュメントはあくまでドキュメントとして保管されている必要があります。分解された複数のテーブルから関連する子要素を取り出し、親要素につなげていく - 非正規化はバラバラに分解されたドキュメントの元の形を想像しながらつなぎ合わせていく作業ですが、これはSQLとNoSQLの両方を理解していないとできません。

移行にはどのくらいの時間を要したのでしょうか。

木内:約85万ドキュメントをトータル約40時間で移行しました。1分あたり4500ドキュメントの計算になります。移行後のフィールド数は約4万個です。数が多いのは参加者が非常に多いプロジェクトがあったことが原因です。参加者ひとりにつき9フィールド作成されてしまうので、たとえば100人だと900フィールド、さらにプロジェクト内のドキュメントが10個あると9000フィールドになってしまうので、仕方がないのですが。

移行後の統計や分析環境はどう改善されたのでしょうか。

原:Elasticsearchによる集計はすごく使いやすくて、たとえば組織ごとの予算配分状況などの統計的な偏向把握が非常にわかりやすく可視化できます。またkibanaのタグクラウドを使用し、ファンドの題目(タイトル)で使われている用語をkuromojiで形態素解析することで各年代でどういった研究や施策に力が入れられていたか、その傾向を分析できるようになりました。これは定性的な偏向把握の実例ですね。関係性やカテゴリの発見においても、膨大なデータと計算量を必要とするコサイン類似度計算をSparkによるベクトル間計算で大幅に圧縮でき、さらにマルチコア/マルチノードによるスケーラブルな処理が可能になったことで、今後のデータ増加にも対応できる道筋が作れたと思います。統計や分析のパフォーマンスに関してはストレスフリーで使えているというか、現実的な時間での処理ができているので、とくに不満はないですね。

木内:先ほど「SQLとNoSQLの両方の知識が必要」と言いましたが、ここ最近のビッグデータ処理の流れとして、データの格納にはNoSQLデータベースを使いつつ、検索にはSQLを利用するケースが増えています。今回のプロジェクトはまさにそういったケースで、たとえば「iPS細胞の研究において総額でいくらの予算が配分されたのか」といった統計を行うにはSQLの知識が必要となります。ビッグデータの処理に関して「SQLかNoSQLか」という議論はもう古く、両方の良さを適材適所に組み合わせていく風向きに変わっていることを実感しています。

このプロジェクトの今後の展開について最後に教えてください。

原:「2位じゃダメなんですか?」と発言した方が昔いましたが.... 科学技術の発展によって, 今日僕たちは地球の裏側に居る人達とリアルタイムで話したり, 恋人や子どもたちの近況をSNS を通じて知ることが出来ているわけです。だけど、そうした科学がどのようにしてイノベーションとして、世の中を変えるような技術となり、経済的な利益を生み出すか、そうした過程はまだまだ解析が行われていません。

 特に日本は少子高齢化に直面しているわけで、政府が科学に投資する上でも、「何故投資を行うのか」、「誰が幸福になるのか」、可能な限り説明する必要があると思います。まずはSPIAS という形で具現化を行っている最中ですが、今後は政府のみならず、民間ユースへの展開も可能性のひとつとして考えたいと思います。名前は別になるかもしれませんが。それまでには、システムをさらに改善していく(オープンデータとプライベートデータの融合、スケーライビリティの向上、パフォーマンスの向上、自然言語処理手法の最適化、etc.) のはもちろんのこと、より仲間を増やしていきたいと考えているところです。このプロジェクトの具体的にどう昇華させるかはこれから詰めていきますが、今後もこのプラットフォームの研究開発を続けていきたいと考えています。

原氏と木内2

grips_logo

政策研究大学院大学

事業内容
政策及び政策の革新にかかわる研究と教育を通して、我が国及び世界の民主的統治の発展と高度化に貢献することを目的とした大学院大学
代表者
政策研究大学院大学長 田中 明彦
設立
1997年10月1日
URL
http://www.grips.ac.jp/

CLIENT VOICE一覧を見る

mautic is open source marketing automation