Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,099 views

Published on

2017/8/27 July Tech Festaにて発表

Published in: Data & Analytics
  • Be the first to comment

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

  1. 1. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved Elasticsearchと科学技術ビッグデータが切り拓く日本の知の俯瞰と発見 2017.8.27 クリエーションライン株式会社 シニアコンサルタント 木内 満歳 1 ※前半資料は https://www.slideshare.net/yasushihara/elasticsearch-15-spias を参照ください
  2. 2. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 自己紹介 木内 満歳(きうち みつとし) クリエーションライン株式会社 シニアコンサルタント 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
  3. 3. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 会社紹介 2006年1月設立 拠点: 東京都神田佐久間町(秋葉原) 社員数: 35(業務委託・BP含め 60人) 主な業務: クラウド基盤コンサルティング・アプリケーション開発・運用 IoT/ビッグデータ基盤構築、データ分析サービス アジャイル開発/DevOps開発/CI/CDに関するコンサルティング クリエーションライン株式会社 3
  4. 4. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 取扱製品 クラウド基盤・アジャイル開発支援 データ分析基盤 4
  5. 5. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved アジェンダ 1. SPIASが解決すべき技術課題 2. 解決に向けた方策 3. 試作構成 4. 検証 a. データ移行 b. 統計的な傾向把握:組織毎の予算配分状況 c. 定性的な傾向把握:年代ごとに使用された主要な用語 d. 論文毎の関係性・カテゴリの発見 5.まとめ 6.今後の展開 5
  6. 6. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 1. SPIASが解決すべき技術的課題 • 量と質の向上(スケーラビリティ) – データベース • 量・速度のスケーラビリティ • 論文データベースの特性に合わせた要素技術選択 – 統計処理環境 • 集計 • 各種機械学習 •認証(AD/LDAPベース) 6
  7. 7. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 1. SPIASが解決すべき技術的課題 •スケーラビリティ – データベース • 量・速度のスケーラビリティ • 論文データベースの特性に合わせた要素技術選択 – 現状のDB収録:約100GB, 約15機関 • 課題 – 現状ではDBの制約から全てのデータを入れていない – 民間のリポジトリに対応できていない – 管理組織によってスキーマ構造が異なる – 異なるスキーマを受け入れ、統合管理する必要性 7
  8. 8. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 現状のテーブル構造 ● かなり複雑化 ● RDB(正規化)のアプローチで 今後も続けることは厳しい 8
  9. 9. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 1. SPIASが解決すべき技術的課題 •スケーラビリティ – データベース • 論文データベースの特性に合わせた要素技術選択 [求められる要素技術] • 全文検索(含む形態素解析) • 各種集計処理 さらにアドバンスドな処理として • 類似性探索・カテゴリの発見 • 論文間の参照訴求・原論文探索 • 組織毎の傾向性探索 9
  10. 10. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 1. SPIASが解決すべき技術的課題 • スケーラビリティ – 統計処理環境 • 基本的にはドキュメント量が倍になると、 – 関連性探索の検索量は4倍以上になる – 関連してコーパスが増えると、その増加量の4倍以上計算量が増える • 従ってドキュメント量が増加するごとに、統計処理に要する計算量は指 数関数的に上昇する スケーラブルDBの必要性 • 高度な統計処理のニーズ – ドキュメント間類似探索 – 論文間リファレンス訴求 など スケーラブル分析環境の必要性 10
  11. 11. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 2. 解決に向けた方策 • RDBから分散NoSQLへの移行 – 現状: MySQL+Mroonga – 移行先: Elasticsearch •Apache Sparkによる統計処理環境 [選択理由] • 双方ともにスケーラビリティがある • Elasticsearch: – kuromojiによる形態素解析 – スキーマ定義不要(厳密には若干型指定などが必要だが) – 全文検索機能がデフォルトで使用できる • Apache Spark – Elasticsearchとの接続サポート – 統計処理, 機械学習, グラフ処理を含む統合パッケージ 11
  12. 12. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 3. 試作構成 Senkei データ移行 データ分析 12
  13. 13. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4. 検証 A.データ移行 B.統計的な傾向把握:組織毎の予算配分状況 C.定性的な傾向把握:年代ごとに使用された主要な用語 D.論文毎の関係性・カテゴリの発見 13
  14. 14. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-A: データ移行 RDBからのDe-Normarize 複数のテーブルから子要素を 取り出し親要素につなげる [テーブル名] [対応するオブジェクト構造] projects =. ├ project_documents =.document └ project_doc_links =.doclink ├ project_doc_texts =.doclink.doctext └ project_members =.doclink.member 14
  15. 15. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-A: データ移行 RDBからのDe-Normarize • LogstashにはJBDCによるRDBインプットに対応するコネクタがある – ドキュメントに複数テーブルにJOINを行う場合の記法が書かれ ていない – 複数テーブルのJOINを行うとデータ爆発で移行用のインスタン スのメモリをオーバーフローしてしまう • Pythonで移行プログラムを作成 15
  16. 16. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-A: データ移行 移行後のデータ例 { "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
  17. 17. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-A: データ移行 移行後のデータ例 { "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
  18. 18. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-A: データ移行 データ移行量: 約850,000ドキュメント 移行時間: 約40時間(約4500ドキュメント/分) 移行後のフィールド数(≒カラム数)は約40,000個 主な原因はプロジェクト参加者が非常に多いプロジェクトがあったこと (参加者1人につき9フィールドできるので、参加者が100人だと100x9=900 フィールド。プロジェクト内のドキュメントが10個あると900x10=9000フ ィールドになってしまう) 18
  19. 19. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-A: データ移行 手こずった点 • mysql-restoreの時間 – dump 1.5h, restore: 40h(dump比25倍) • Logstashの書式のわかりにくさ • JOINによるデータ爆発 • インデックス(≒テーブル)作成時にフィールド定義やtokenizerの定義をし ないと、作成後にダイナミックに変更することができないため、何回かや りなおした 19
  20. 20. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-B: • 統計的な傾向把握:組織毎の予算配分状況 – elasticsearchのaggregated queryを使用 – kibanaで可視化 20
  21. 21. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-B: 統計的な傾向把握 • 競争的資金活用プロジェクトにおける年次予算配分状況 21
  22. 22. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-B: 統計的な傾向把握 • 競争的資金活用プロジェクトにおける年次予算配分状況 ● 資金の大部分はいくつかの組織 に偏っている(近年はそれでも 多様性が出てきた) ● 比較的マイナーな組織で多額の 予算配分が行われているのは、 看板研究者の移籍などによると 推測される 22
  23. 23. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-B: 統計的な傾向把握 • 競争的資金活用プロジェクトにおける年次予算配分状況 ● elasticsearchによる集計は非常に簡便 23
  24. 24. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-C: 定性的な傾向把握:年代ごとに使用された主要な用語 • kibanaのtag cloudを使用 – タイトルで使用される用語をkuromojiで形態素解析 – プロジェクトの予算平均の多い順にソートして表示 24
  25. 25. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-C: 定性的な傾向把握:年代ごとに使用された主要な用語 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
  26. 26. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-C: 定性的な傾向把握:年代ごとに使用された主要な用語 1960年代 1970年代 1980年代 1990年代 2000年代 2010年代 26
  27. 27. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-C: 定性的な傾向把握:年代ごとに使用された主要な用語 技術トピックによる予算配分 世界の中の日本・相対的な視点 1960年代 1970年代 1980年代 1990年代 2000年代 2010年代 エネルギーの開発と利用 研究の実用化・大学発ベンチャー 次世代エネルギー・材料開発 27
  28. 28. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-C: 定性的な傾向把握:年代ごとに使用された主要な用語 技術トピックによる予算配分 世界の中の日本・相対的な視点 1960年代 1970年代 1980年代 1990年代 2000年代 2010年代 エネルギーの開発と利用 研究の実用化・大学発ベンチャー 次世代エネルギー・材料開発 大阪万博 (1970) 電子顕微鏡 (1965) オイルショック (1973) プラザ合意 (1986) カーボンナノチューブ (1991) 京都議定書 (1999) 平沼プラン (2001) 東日本大震災 (2011) 28
  29. 29. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-C: 定性的な傾向把握:年代ごとに使用された主要な用語 • 各年代における研究は当時の世相、政策を反映している • 一般的な傾向としては「エネルギー開発」「材料開発」に多めの予算が割 り当てられる傾向がある 29
  30. 30. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-D: 論文毎の関係性・カテゴリの発見 • 文書間の類似度計算 – 研究プロジェクトタイトルを形態素解析 – Bag of Words(BoW)の作成、多次元ベクトル化 • ベクトル間計算 – コサイン類似度 – 他にも ベクトル間距離や集合の発見(クラスタリング)にも利 用可能 30
  31. 31. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-D: 論文毎の関係性・カテゴリの発見 • 文書間のコサイン類似度計算 – 研究プロジェクトタイトルを形態素解析 – 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
  32. 32. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-D: 論文毎の関係性・カテゴリの発見 • 文書間のコサイン類似度計算 – 非常にデータ量が多い • コーパス*: 約15万次元 • プロジェクト数: 約80万プロジェクト ⇒ 15万 x 80万^2 のマトリクス計算 ⇒ 15万 x 80万^2 x 4byte(float) = 3.84e17 ≒ 約350PB まともにやっても そもそもできない ※コーパス: ここでは「ドキュメント群全体で現れる単語の一覧と個々の単語の出現数」という意味で使用 32
  33. 33. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-D: 論文毎の関係性・カテゴリの発見 • 文書間のコサイン類似度計算 ⇒ 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
  34. 34. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-D: 論文毎の関係性・カテゴリの発見 • 文書間のコサイン類似度計算 ⇒ さらに悪いことに・・・ • 実際にはメモリ〜CPU間のデータ転送による遅延 • ディスクIO、ネットワークデータ転送が入る場合はさらに遅延 • データの用意に関する各種OSの処理 などが入るため、理論時間の100〜1000倍以上かかるかもしれない ⇒実際には数十年、へたしたら数百年かも・・・ さらにドキュメント、コーパスは今後さらに増える可能性 データ量と計算量の圧縮は必須要件 かつマルチコア・マルチノードにわたるスケーラブルな処理が必要 34
  35. 35. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-D: 論文毎の関係性・カテゴリの発見 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
  36. 36. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-D: 論文毎の関係性・カテゴリの発見 • 文書間のコサイン類似度計算 – ベクトル間計算 • 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
  37. 37. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-D: 論文毎の関係性・カテゴリの発見 • 文書間のコサイン類似度計算 – ベクトル間計算: 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
  38. 38. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-D: 論文毎の関係性・カテゴリの発見 • 文書間のコサイン類似度計算 – ベクトル間計算: Apache Spark: DIMSUM • Twitterによって開発(2014年)、SparkにOSSとして寄贈 TwitterにおけるDIMSUM適用後のシャッフル量の変化 適用前 適用後 38
  39. 39. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-D: 論文毎の関係性・カテゴリの発見 • 文書間のコサイン類似度計算: DIMSUM こんな風に読む 処理時間: 約6時間 (サンプリング1%, pre、post処理含む) 39
  40. 40. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-D: 論文毎の関係性・カテゴリの発見 • 文書間のコサイン類似度計算: DIMSUM ● そんなにドキュメント間の 類似性が偏る=グループ化で きる要素があるようには見 受けられない ● 比較的どれにも似ていない、 (いい意味では)独自性のある ドキュメントはそれなりに ありそう ● 一般的すぎる単語の刈り込 みなどが必要だと思われる 40
  41. 41. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-D: 論文毎の関係性・カテゴリの発見 • 文書間のコサイン類似度計算: DIMSUM DIMSUMとて万能ではない Executor間の大幅な処理時間のば らつき = Partition毎のデータ量に 大きな偏差がある->改善の余地あ り? 41
  42. 42. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 4-D: 論文毎の関係性・カテゴリの発見 • 文書間のコサイン類似度計算 ⇒ さらに悪いことに・・・ • 実際にはメモリ〜CPU間のデータ転送による遅延 • ディスクIO、ネットワークデータ転送が入る場合はさらに遅延 • データの用意に関する各種OSの処理 などが入るため、理論時間の100〜1000倍以上かかるかもしれない ⇒実際には数十年、へたしたら数百年かも・・・ さらにドキュメント、コーパスは今後さらに増える可能性 データ量と計算量の圧縮は必須要件 かつマルチコア・マルチノードにわたるスケーラブルな処理が必要 ともあれ当初目的は達成。 ◯ データ量・計算量 = 大幅な圧縮に成功 ◯ マルチコア・マルチノードにわたるスケーラブル処理 = 実装 ⇒今後のデータ増加に対しても対応できる道筋を作った 42
  43. 43. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved まとめ •量と質の向上(スケーラビリティ) – データベース • 量・速度のスケーラビリティ • 論文データベースの特性に合わせた要素技術選択 ⇒elasticsearchが有効なデータベースとして 機能することを確認した – 統計処理環境 • 集計 • 各種機械学習 ⇒Apache Sparkで現実的な時間での処理ができる可能性が あることを確認した 43
  44. 44. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 今後の展開 • さらなるデータソースの取込み – 海外英語論文 – 科研費 •高度な分析技術の投入 – 研究者プロファイリング – 論文被引用関係のグラフデータ化、および分析 – 研究者コロニーの視覚化 – 組織間マッチング、研究アソシエーション探索 44
  45. 45. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 宣伝 “e19” と書いて「せんけい」と読みます 7/28リリース マネージドApache Spark分析環境 データサイエンティストのためのサ ービス https://e19.io 45
  46. 46. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved みなさまへのお願い 本プロジェクトは2019年4月の事業化を目標に開発を進めています。 ご興味を持たれた方はぜひお問い合わせください。 • 事業に協賛したい • データを提供したい • 開発に参加したい • そのほか 46
  47. 47. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 47

×