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

Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
Elasticsearchと科学技術ビッグデータが切り拓く日本の知の俯瞰と発見
2017.8.27
クリエーションライン株式会社シニアコンサルタント
木内満歳
1
※前半資料は 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

会社紹介
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

– ベクトル間計算: 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) Elasticsearchと科学技術ビッグデータが切り拓く日本の知の俯瞰と発見

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (13)

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

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

More from Mitsutoshi Kiuchi

More from Mitsutoshi Kiuchi (7)

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