(2017.8.27)...

Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved

Elasticsearchと科学技術ビッグデータが切り拓く日本の知の俯瞰と発見

2017.8.27

クリエーションライン株式会社シニアコンサルタント木内満歳

1

※前半資料は https://www.slideshare.net/yasushihara/elasticsearch-15-spiasを参照ください

https://www.slideshare.net/yasushihara/elasticsearch-15-spias


自己紹介木内満歳（きうちみつとし）

クリエーションライン株式会社シニアコンサルタント

Slideshare: http://www.slideshare.net/mkiuchi4

各種寄稿

a. gihyo.jp: “Mesosphere DCOSでつくるクラウドアプリケーション”

b. 日経クラウドファースト2016年6月 “Azure IoT Suiteの評価”

c. Codezine: “機械学習をクラウドで手軽に体験！ BluemixのApache Sparkで異常

なセンサーデータを洗い出す”

各種講演a. 政策研究大学院大学科学技術イノベーション政策研究センター

「科学技術イノベーション政策のための科学オープンフォーラム」b. Developer Summit 2016 Summer

c. 日経BP社 “パブリッククラウド導入の企画提案力養成講座”

専門分野：Apache Mesos, Apache Spark, 分散コンピューティング, クラウドコンピューテ

ィング, NoSQL DB, グラフDB

O’reilley Certified Developer on Apache Spark

Docker Certified Technical Trainer

2

http://www.slideshare.net/mkiuchi4

http://gihyo.jp/admin/serial/01/dcos

http://itpro.nikkeibp.co.jp/NCF/

http://codezine.jp/article/detail/9391


会社紹介

2006年1月設立拠点：東京都神田佐久間町(秋葉原)

社員数: 35(業務委託・BP含め 60人)

主な業務：クラウド基盤コンサルティング・アプリケーション開発・運用IoT/ビッグデータ基盤構築、データ分析サービスアジャイル開発/DevOps開発/CI/CDに関するコンサルティング

クリエーションライン株式会社

3


取扱製品

クラウド基盤・アジャイル開発支援

データ分析基盤

4


アジェンダ

1. SPIASが解決すべき技術課題2. 解決に向けた方策3. 試作構成4. 検証

a. データ移行b. 統計的な傾向把握：組織毎の予算配分状況c. 定性的な傾向把握：年代ごとに使用された主要な用語d. 論文毎の関係性・カテゴリの発見

5.まとめ6.今後の展開

5


1. SPIASが解決すべき技術的課題

• 量と質の向上(スケーラビリティ)

– データベース

• 量・速度のスケーラビリティ

• 論文データベースの特性に合わせた要素技術選択

– 統計処理環境

• 集計

• 各種機械学習

•認証(AD/LDAPベース)

6



•スケーラビリティ




– 現状のDB収録：約100GB, 約15機関

• 課題

– 現状ではDBの制約から全てのデータを入れていない

– 民間のリポジトリに対応できていない

– 管理組織によってスキーマ構造が異なる

– 異なるスキーマを受け入れ、統合管理する必要性

7


現状のテーブル構造● かなり複雑化● RDB(正規化)のアプローチで今後も続けることは厳しい

8






[求められる要素技術]

• 全文検索(含む形態素解析)

• 各種集計処理

さらにアドバンスドな処理として

• 類似性探索・カテゴリの発見

• 論文間の参照訴求・原論文探索

• 組織毎の傾向性探索

9





• 基本的にはドキュメント量が倍になると、

– 関連性探索の検索量は4倍以上になる

– 関連してコーパスが増えると、その増加量の4倍以上計算量が増える

• 従ってドキュメント量が増加するごとに、統計処理に要する計算量は指

数関数的に上昇する

スケーラブルDBの必要性

•高度な統計処理のニーズ

– ドキュメント間類似探索

– 論文間リファレンス訴求など

スケーラブル分析環境の必要性

10


2. 解決に向けた方策

• RDBから分散NoSQLへの移行

– 現状: MySQL+Mroonga

– 移行先: Elasticsearch

• Apache Sparkによる統計処理環境

[選択理由]

• 双方ともにスケーラビリティがある

• Elasticsearch:

– kuromojiによる形態素解析

– スキーマ定義不要(厳密には若干型指定などが必要だが)

– 全文検索機能がデフォルトで使用できる

• Apache Spark

– Elasticsearchとの接続サポート

– 統計処理, 機械学習, グラフ処理を含む統合パッケージ

11


3. 試作構成

Senkei

データ移行データ分析

12


4. 検証

A.データ移行

B.統計的な傾向把握：組織毎の予算配分状況

C.定性的な傾向把握：年代ごとに使用された主要な用語

D.論文毎の関係性・カテゴリの発見

13


4-A: データ移行

RDBからのDe-Normarize

複数のテーブルから子要素を取り出し親要素につなげる

[テーブル名] [対応するオブジェクト構造]projects =.

├ project_documents =.document

└ project_doc_links =.doclink

├ project_doc_texts =.doclink.doctext

└ project_members =.doclink.member

14



RDBからのDe-Normarize

• LogstashにはJBDCによるRDBインプットに対応するコネクタがある– ドキュメントに複数テーブルにJOINを行う場合の記法が書かれていない

– 複数テーブルのJOINを行うとデータ爆発で移行用のインスタンスのメモリをオーバーフローしてしまう

• Pythonで移行プログラムを作成

15



移行後のデータ例

{ "id": 105271,

"title": "量子情報処理プロジェクト","enterprise_id_top": 500,

"enterprise_id_bottom": 501,

"doclink": [

{ "project_id": 105271,

"project_document_id": 100630,

"url": "http://first-quantum.net/",

"doctext": [

{ "title": "概要",

"body": "量子情報処理の分野で・・・",

"member": [

{ "researcher_id": 116116,

"name": "山本喜久","institution_id": 4701,

"affiliation": "情報・システム研究機構(国立情報学研究所)", },]} ] } ],

"document": [

{ "title": "量子情報処理プロジェクト", } ]}

16



移行後のデータ例

{ "id": 105271,

"title": "量子情報処理プロジェクト","enterprise_id_top": 500,

"enterprise_id_bottom": 501,

"doclink": [

{ "project_id": 105271,

"project_document_id": 100630,

"url": "http://first-quantum.net/",

"doctext": [

{ "title": "概要",

"body": "量子情報処理の分野で・・・",

"member": [

{ "researcher_id": 116116,

"name": "山本喜久","institution_id": 4701,

"affiliation": "情報・システム研究機構(国立情報学研究所)", },]} ] } ],

"document": [

{ "title": "量子情報処理プロジェクト", } ]}

テーブル”projects”からのデータ

テーブル”project_doc_links”からのデータ

テーブル”project_doc_texts”からのデータ

テーブル”project_members”からのデータ

17



データ移行量: 約850,000ドキュメント

移行時間: 約40時間(約4500ドキュメント/分)

移行後のフィールド数(≒カラム数)は約40,000個

主な原因はプロジェクト参加者が非常に多いプロジェクトがあったこと

(参加者1人につき9フィールドできるので、参加者が100人だと100x9=900

フィールド。プロジェクト内のドキュメントが10個あると900x10=9000フ

ィールドになってしまう)

18



手こずった点

• mysql-restoreの時間

– dump 1.5h, restore: 40h(dump比25倍)

• Logstashの書式のわかりにくさ

• JOINによるデータ爆発

• インデックス(≒テーブル)作成時にフィールド定義やtokenizerの定義をし

ないと、作成後にダイナミックに変更することができないため、何回かや

りなおした

19


4-B:

• 統計的な傾向把握：組織毎の予算配分状況– elasticsearchのaggregated queryを使用– kibanaで可視化

20


4-B: 統計的な傾向把握

• 競争的資金活用プロジェクトにおける年次予算配分状況

21




● 資金の大部分はいくつかの組織

に偏っている（近年はそれでも

多様性が出てきた）

● 比較的マイナーな組織で多額の

予算配分が行われているのは、

看板研究者の移籍などによると

推測される

22




● elasticsearchによる集計は非常に簡便

23


4-C: 定性的な傾向把握：年代ごとに使用された主要な用語

• kibanaのtag cloudを使用– タイトルで使用される用語をkuromojiで形態素解析– プロジェクトの予算平均の多い順にソートして表示

24



elasticsearchでのkuromoji形態素解析

PUT _template/projects {

"settings": { "index": { "analysis": { "tokenizer": {

"kuromoji_user_dict": {

"type": "kuromoji_tokenizer",

"mode": "normal"

} } } } },

"template": "project*",

"mappings": { "project": { "dynamic_templates": [

{ "mk": { "match_mapping_type": "string",

"mapping": {

"type": "text",

"analyzer": "kuromoji",

"fielddata": true,

"fields": {

"title": {

"type": "keyword"

} } } } } ] } }

}

● トークナイザkuromojiはプラ

グイン利用可能

● 形態素解析するフィールドを

事前に定義することで自動的

に品詞を抜き出す

$ elasticsearch-plugin install analysis-kuromoji

25



1960年代 1970年代

1980年代 1990年代

2000年代 2010年代

26



技術トピックによる予算配分

世界の中の日本・相対的な視点

1960年代 1970年代

1980年代 1990年代

2000年代 2010年代

エネルギーの開発と利用

研究の実用化・大学発ベンチャー次世代エネルギー・材料開発

27



技術トピックによる予算配分

世界の中の日本・相対的な視点

1960年代 1970年代

1980年代 1990年代

2000年代 2010年代

エネルギーの開発と利用

研究の実用化・大学発ベンチャー次世代エネルギー・材料開発

大阪万博(1970)

電子顕微鏡(1965)

オイルショック(1973)

プラザ合意(1986)

カーボンナノチューブ(1991)

京都議定書(1999)

平沼プラン(2001)

東日本大震災(2011)

28



• 各年代における研究は当時の世相、政策を反映している

• 一般的な傾向としては「エネルギー開発」「材料開発」に多めの予算が割り当てられる傾向がある

29


4-D: 論文毎の関係性・カテゴリの発見

• 文書間の類似度計算– 研究プロジェクトタイトルを形態素解析– Bag of Words(BoW)の作成、多次元ベクトル化

• ベクトル間計算– コサイン類似度– 他にもベクトル間距離や集合の発見(クラスタリング)にも利用可能

30



• 文書間のコサイン類似度計算– 研究プロジェクトタイトルを形態素解析– Bag of Words(BoW)の作成、多次元ベクトル化

(例)

文書1: りんごバナナぶどうメロン文書2: メロンりんごパイナップルなし--

コーパス: [りんご: 2, バナナ: 1, ぶどう: 1, メロン: 2, パイナップル: 1, なし: 1]

--

文書1-BoW: [2, 1, 1, 2, 0, 0]

文書2-BoW: [2, 0, 0, 2, 1, 1]2つの文書を同次元のベクトル空間上で計算可能になる

31



• 文書間のコサイン類似度計算– 非常にデータ量が多い

• コーパス*: 約15万次元• プロジェクト数: 約80万プロジェクト⇒ 15万 x 80万^2 のマトリクス計算

⇒ 15万 x 80万^2 x 4byte(float) = 3.84e17 ≒約350PB

まともにやってもそもそもできない

※コーパス: ここでは「ドキュメント群全体で現れる単語の一覧と個々の単語の出現数」という意味で使用

32



• 文書間のコサイン類似度計算⇒ 15万 x 80万^2 のマトリクス計算(例)

コサイン類似度計算:

a = [...], b=[...] とした場合：(a.*b)/norm(a)*norm(b)

⇒これを 80万x80万回=6400万回やればよい

1回の類似度計算に要する浮動小数点計算回数=(15万^2)*((15万^2)+(15万^2))^2) = 45562500万回 = 4600億回

80万^2=6400万回の計算には 4600億 * 6400万 = 約3000京回必要CPU 1core=2GHzの場合、50GFLOPS=500億FLOPS/秒つまり理論上は3000京÷500億≒約7000日の計算・・・だがしかし！

33



• 文書間のコサイン類似度計算⇒さらに悪いことに・・・

• 実際にはメモリ〜CPU間のデータ転送による遅延• ディスクIO、ネットワークデータ転送が入る場合はさらに遅延• データの用意に関する各種OSの処理などが入るため、理論時間の100〜1000倍以上かかるかもしれない

⇒実際には数十年、へたしたら数百年かも・・・

さらにドキュメント、コーパスは今後さらに増える可能性

データ量と計算量の圧縮は必須要件かつマルチコア・マルチノードにわたるスケーラブルな処理が必要

34



350PB ⇒ 10GBまでデータ圧縮

• 文書間のコサイン類似度計算– BoWは基本的にゼロが非常に多いベクトル– Sparse Vector(疎行列)の活用

(例)

array = [0.0, 0.0, 0.0, 0.2, 0.1, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.82, 0.0, 0.0]

4byte(float) x 15 = 60byte

↓array = Vectors.sparse(15, [3,4,12], [0.2, 0.1, 0.82])

│ │ └ゼロ以外の実際の値│ └─────ゼロ以外の値のインデックス└─────────ベクトル長

4byte(int, float) x (1+3+3) = 28byte

35



• 文書間のコサイン類似度計算– ベクトル間計算

• Apache Sparkによる分散計算• DIMSUMによるサンプリング計算

DIMSUM=“Dimension Independent Matrix Square using MapReduce,”

もともとのコサイン類似度で発生するシャッフル量 =O(NL^2)

DIMSUMにおけるシャッフル量 =O(DL log(D)/γ) *γ=10*log(N)/threshold

N(dimension)に依存しない(N=各ベクトルの次元数, D=コサイン類似度組合せ数, L=疎行列長)

36



• 文書間のコサイン類似度計算– ベクトル間計算: Apache Spark: DIMSUM

• Twitterによって開発(2014年)、SparkにOSSとして寄贈

https://blog.twitter.com/engineering/en_us/a/2014/all-pairs-similarity-via-dimsum.html

https://databricks.com/blog/2014/10/20/efficient-similarity-algorithm-now-in-spark-twitter.html

37

https://blog.twitter.com/engineering/en_us/a/2014/all-pairs-similarity-via-dimsum.html

https://databricks.com/blog/2014/10/20/efficient-similarity-algorithm-now-in-spark-twitter.html



• 文書間のコサイン類似度計算– ベクトル間計算: Apache Spark: DIMSUM

• Twitterによって開発(2014年)、SparkにOSSとして寄贈

TwitterにおけるDIMSUM適用後のシャッフル量の変化

適用前適用後

38



• 文書間のコサイン類似度計算: DIMSUM

こんな風に読む

処理時間: 約6時間(サンプリング1%, pre、post処理含む)

39




● そんなにドキュメント間の類似性が偏る=グループ化で

きる要素があるようには見受けられない

● 比較的どれにも似ていない、(いい意味では)独自性のある

ドキュメントはそれなりにありそう

● 一般的すぎる単語の刈り込みなどが必要だと思われる

40




DIMSUMとて万能ではない

Executor間の大幅な処理時間のばらつき = Partition毎のデータ量に大きな偏差がある->改善の余地あり？

41



• 文書間のコサイン類似度計算⇒さらに悪いことに・・・

• 実際にはメモリ〜CPU間のデータ転送による遅延• ディスクIO、ネットワークデータ転送が入る場合はさらに遅延• データの用意に関する各種OSの処理などが入るため、理論時間の100〜1000倍以上かかるかもしれない

⇒実際には数十年、へたしたら数百年かも・・・

さらにドキュメント、コーパスは今後さらに増える可能性

データ量と計算量の圧縮は必須要件かつマルチコア・マルチノードにわたるスケーラブルな処理が必要

ともあれ当初目的は達成。◯データ量・計算量 = 大幅な圧縮に成功◯マルチコア・マルチノードにわたるスケーラブル処理 = 実装

⇒今後のデータ増加に対しても対応できる道筋を作った

42


まとめ

•量と質の向上(スケーラビリティ)




⇒elasticsearchが有効なデータベースとして

機能することを確認した


• 集計

• 各種機械学習

⇒Apache Sparkで現実的な時間での処理ができる可能性が

あることを確認した

43


今後の展開

• さらなるデータソースの取込み

– 海外英語論文

– 科研費

•高度な分析技術の投入

– 研究者プロファイリング

– 論文被引用関係のグラフデータ化、および分析

– 研究者コロニーの視覚化

– 組織間マッチング、研究アソシエーション探索

44


宣伝

“e19”と書いて「せんけい」と読みます

7/28リリース

マネージドApache Spark分析環境

データサイエンティストのためのサービス

https://e19.io

45


みなさまへのお願い

本プロジェクトは2019年4月の事業化を目標に開発を進めています。

ご興味を持たれた方はぜひお問い合わせください。

• 事業に協賛したい

• データを提供したい

• 開発に参加したい

• そのほか

46

(2017.8.27)...

Data & Analytics