大量時空間データの処理 ～ 現状の課題と今後OSSが解決すべきこと。（Open Source Conference 2021 Online/Osaka講演資料）
- 1. © 2020 NTT DATA Corporation 大量時空間データの処理 ～ 現状の課題と今後OSSが解決すべきこと。 • 2021年1月30日 • 株式会社NTTデータ 技術革新統括本部 システム技術本部 • デジタル技術部 三浦 広志 OSC大阪
- 2. © 2021 NTT DATA Corporation 2 話の流れ 1. 自己紹介、本講演の内容について 2. 時空間情報の処理（GIS）とは 3. ビッグデータ時空間処理が必要になる背景 4. 効率的な時空間情報の処理にむけて 5. NTTの先進技術のご紹介 6. OSSでの実装状況 7. 利用するには
- 3. １. 自己紹介&メンバー紹介 三浦 広志 NTTデータ 技術革新統括本部 デジタル技術部 （Scalable Data Optimizationチーム） Executive ITスペシャリスト（プラットフォーム） （[email protected]） • コネクテッドカー、スマートシティに関連する データ活用の技術開発に従事
- 4. 個人的な自己紹介 • 各種OSS開発を主導、主要貢献者 – 圧縮フォーマット7zip互換実装（python）py7zr – 日本語処理ライブラリ かな漢字→ローマ字変換 pykakasi – GUI SDKの Qt の非公式CLIインストーラ aqtinstall – 翻訳ツールOmegaT自動翻訳エンジンTexTra®対応プラグイン – フリーGISツール ライブDVD OSGeoLive 和訳プロジェクト – OpenStreetMap タスクトラッカー Simple Task Manager • オープンストリートマップファウンデーションジャパン代表理事 https://osmf.jp/
- 6. © 20２1 NTT DATA Corporation 6 地理情報システム（GIS）とは
- 7. 地理情報システムと一般的なユースケース 自治体・小売業界等の幅広い業界で利用事例あり スマートデバイス活用に よる営業、配送効率化 小売店、飲食店チェーン 店舗開発・店舗管理の 高度化 自治体による都市計画、上下水 道管理, 林業管理 地理情報システム（略称：GIS）とは、地理情報および付加情報をコンピュータ上で作成・ 保存・利用・管理・表示・検索するシステムを言う – Wikipediaより 提供：GYRO_PHOTOGRAPH／イメージマート 提供：PantherMedia/イメージマート
- 8. GIS基盤の実現例 • GIS基盤の実現のための一般的なソフトウエアは多様にある 今日は、地理情報処理を効率的に扱うためのDatabaseに着目する デスクトップ上で地理空間情 報の作成・編集・可視化 例： QGIS、ArcGIS 地理空間情報の管理 効率的な空間演算処理 例： PostGIS,MySQL 地理情報の共有・編集用のサーバ （データ配信、背景地図配信、 更新） 例： MapServer、ArcServer Web地図用のライブラリ 例：OpenLayers デスクトップGIS データベース GISサーバ Webアプリケーション スマホアプリケーション 配信サービス 背景地図の配信、地理情報の配信 例： Google Maps、MapTiler 付加情報サービス 渋滞情報、天候情報
- 9. © 20２1 NTT DATA Corporation 9 ビッグデータ時空間処理が必要になる 背景
- 10. GISの世界にもビックデータの波が到来： Big Spatial Data • ビックデータの活用（IoTデータ）により、地理情報データもビックデータ化 PCやスマートフォンだけでなく、ビル、コネクテッドカー、スマートシティのカメラ、センサーの情報も集約 既存のRDBMSベースのDB前提では処理できない 提供：PantherMedia/イメージマート
- 11. 新たなGISへの要求 スマートデバイスの位置情報を集めて、人々の混雑度を分析するなどの技術は確立して おり、すでに緊急事態宣言時の人出の分析などに利用されている。 "Shibuya Crossing" by Dick Thomas Johnson is icensed under CC BY 2.0 "Swine Flu: Just Hype and Exaggeration?" by GDS Infographics is licensed under CC BY 2.0
- 14. © 20２1 NTT DATA Corporation 14 効率的な地理情報処理のために
- 15. 空間DBの必要性 • 空間演算処理を自作するのは大変なので、汎用処理化したものを利用したい 空間処理を効率的に扱うためのDB=空間DB 空間DBが備えている機能一例 ・ 空間オブジェクトの扱い （ジオメトリ型） ・ 空間演算処理例 =2点間の 距離
- 16. 空間DBの製品例 • 一貫性を重視した「RDBMS」ベースの製品 地図データの扱いがメイン、更新頻度が少なく、一貫性を重視するため RDBMSをベースに空間インデックス等の拡張を行うことで実現 空間DBの製品例(RDBMSベース) ・ PostGIS ・MySQL ・ Oracle Spatial ・ ArcGIS 空間DBのインデックス ・ R-Tree、 Quad-Tree 等 ・空間オブジェクト ・空間演算 ・空間演算ライブ ラリ ・地図投影変換ライブラリ PostgreSQL PostGIS GEOS PROJ
- 17. Strictly Confidential Project member Only 既存の空間DBの課題/解決策 • RDBMSベースでは、拡張性がなく、データ量増加に対応できない • 拡張性を重視するため、NoSQLを活用する方法があるのではないか？ 解決するための方法の一つとして、Ordered KVSを活用する方法が提 案されている 【得意な領域】 ・一貫性 ※ DB製品例 ・PostgreSQL ・MySQL 等 【得意な領域】 ・拡張性 ※DB製品例 ・HBase ・Redis(sortedset) Ordered KVS RDBMS
- 18. Ordered KVSの特徴 • ① 各レコードをサーバ間でパーティショニングすることで、拡張性を確保している • ② レコードがKeyの値でソートすることで、範囲検索に対応することが出来る この特性を上手く位置情報に活用したいが、 地理情報の2次元（緯度・経度）データを1次元のKeyデータにする必要がある Key Value ID VIN ID-122 VIN32 ID-142 VIN91 ID-198 VIN21 ID-199 VIN16 ソート済 Key Value ID VIN ID-032 VIN32 ID-041 VIN91 ID-072 VIN21 ID-096 VIN16 ソート済 Key Value ID VIN ID-232 VIN32 ID-241 VIN91 ID-272 VIN21 ID-296 VIN16 ソート済 クライアント ID-100～ID-199 ID-200～ID-299 ID-000～ID-099 ① 各サーバでパーティショニング ② Keyでソート済のため、範囲検索可能
- 19. 地理情報の適用方法 (1/2) • 地理情報に「空間充填曲線」を適用し、Ordered KVSを活用する 2次元（緯度・経度）の情報を1次元に圧縮して、Keyとすることで適用できる 一つのエンコーディング方式として、”Geohash”が存在する • Moore, GeoHex, S2 cell等、様々存在している https://www.slideshare.net/AtIso1/redisconf19-realtime-spatiotemporal-data-utilization-for-future-mobility-services-139153004 NTT研究所 ソフトウエアイノベーションセ ンターによるredisconf19 発表から著作者の許可を 得て引用
- 20. 地理情報の適用方法 (2/2) • Geohashの嬉しい特性として、前方一致検索が可能 地理情報システムでは、近接地域のデータを一度に取得することが多い 前方一致検索（Ordered KVSの範囲検索）でズームレベルに応じて、近接地域のデータをまとめて取得する ことが出来る。ディスクベースDBだと、シーケンシャルリードで効率的に読み込める https://www.slideshare.net/AtIso1/redisconf19-realtime-spatiotemporal-data-utilization-for-future-mobility-services-139153004 桁を長くすると、より細かい空間 領域を示せる Key Value GeoHash … 100101001 … 100101001 … 100111001 … 100111001 … 101011001 … 101111001 … ソート済 Ordered KVS NTT研究所 ソフトウエアイノベーションセ ンターによるredisconf19 発表から著作者の許可を 得て引用
- 22. 複数メッシュを跨る検索時の理想のディスクアクセス • 理想的には、ディスクを効率的に利用できるシーケンシャルリードにしたい 「近接性」が高い（隣り合うメッシュの番号が連続しやすい）エンコーディング方法ほど、 シーケンシャルリードしやすい ①それぞれのメッシュで取得 ②メッシュデータをまるごと取得（理想） ・・・ 103 ・・・ ・・・ 112 ・・・ 121 ・・・ 130 ・・・ ・・・ ・・・ 310 311 312 313 ・・・ ・・・ ランダムリード x 4回 シーケンシャルリード x 1回 エンコーディング(Geohash)
- 23. © 20２1 NTT DATA Corporation 23 NTT研究所が開発した技術の例
- 25. 時空間データ（地理情報 + 時間情報）の特定のクエリに特化する工夫 • Geohashの技術を拡張して、時空間コードで実現する クエリ③ 時間・空間の精度割合：固定 前方一致を長くするほど、より細かい時空間領域を特定できる Geohash 前方一致で特定空間を特定可能 前方一致で特定時空間 を特定可能 時空間コード
- 27. © 20２1 NTT DATA Corporation 27 OSSによる実現状況
- 29. OGC: Open Geospatial コンソーシアム 国際的な地理空間のためのオープンな規格を開発する団体 主な規格の例 GML XMLで地理情報を表現する KML XMLで2次元、3次元の地図上の注釈を実現する WMS 地図画像を配信するサーバの規格 WMTS 地図画像タイルを配信する規格 SQLの空間拡張： Simple Feature Specification
- 30. 時空間分析用DBのOSS PostgreSQL/PostGIS, MySQLといった定番のRDBMSが広く使われるが、 ビッグデータむけには、GeoMesa というOSSが有望 • プロジェクト概要 Apacheライセンス Eclipse FoundationのLocationTech Projectsの一つ 大規模スケールでの時空間情報分析を分散環境で 実行することを目的としたソフトウェアスイートツール群 想定ユースケース：IoT（携帯等), SNS, Tracking データストアレイヤは複数 サポート (HBase, Redis, Kafka等)
- 31. GeoMesa 機能面 対応しているデータ型：point, line, polygon等 API: OGC（Open Geospatial Consurtium) APIs, GeoJSON API, Spark（Spark SQL)で独自アプリ Geoserverを活用して、地図との連携、ヒストグラム・ヒートマッ プ・時系列分析等の可視化ができる 非機能面 ペタバイトオーダの時空間データを保持可能 100億ポイント以上 1000万/sのポイントデータを格納可能（1ノードあたり1万 /sec） スケールアウト型
- 32. GeoMesaの時空間処理のポイント • NTT研究所の技術と同様でZカーブを時空間データに適用することで列指向データ ベースへの格納・検索を実現 スケーラビリティと時空間処理の検索性能を両立している • RowキーにZカーブを時空間データに適用し た「Z3インデックス」を付与 • RowキーはソートされてRange検索可能 (Accumuloの場合のスキーマ）
- 33. GeoMesaのデータ格納フローからみる工夫 データ格納時の処理フローから、GeoMesaの動作を理解する クライアント HBaseサーバ 格納アプリケーション 格納データ （緯度・経度・時間情報） ① 緯度・経度・時間情報と実データを渡す ② 時空間検索用のデータを計算する - 時間 → エポック週 - 緯度・経度・時間 → z3コード HBase Client GeoMesa ③ データを格納する RowKey Column エポック週 Z3コード ユニークID VIN Speed その他 2444 10001000111…1111 ID-312 VIN312 50km ・・・ 2444 10011010101…1010 ID-911 VIN911 30km ・・・ 2444 10011001101…1001 ID-291 VIN291 79km ・・・ 2444 10011101000…1000 ID-116 VIN116 10km ・・・
- 34. GeoMesaのデータ検索フローから見る工夫 検索フローのイメージは下記の通り クライアント 検索アプリケーション ① 検索対象のポリゴン領域・時間を渡す ② 時空間検索用のデータを計算する - 時間 → エポック週 - ポリゴン領域・時間 → ポリゴン領域・時間を含むz3コード HBase Client GeoMesa ③ ポリゴン領域を含むz3で表現された 時空間領域に含まれるデータを検索する 検索条件 （空間領域・時間情報） ポリゴンを包含するZ3コード の時空間領域イメージ RowKey Column エポック週 Z3コード ユニークID VIN Speed その他 2444 10001000111…1111 ID-312 VIN312 50km ・・・ 2444 10011010101…1010 ID-911 VIN911 30km ・・・ 2444 10011001101…1001 ID-291 VIN291 79km ・・・ 2444 10011101000…1000 ID-116 VIN116 10km ・・・ HBase サーバ ex.100110 ④範囲検索
- 35. GeoMesa＋カラムナDB（Hbase）による効率処理 • GeoMesaはHBaseの仕組みを活用することで、データベース内に蓄積されている検索対象外のデー タ量が増加しても、検索対象の時空間データにのみアクセスできるためと考えられる RowKey Column エポック Z3コード ID VIN Speed その他 2444 100010001…111 ID-32 VIN32 50km ・・・ 2444 100110101…101 ID-91 VIN91 30km ・・・ 2444 100110011…100 ID-21 VIN21 79km ・・・ 2444 100111010…100 ID-16 VIN16 10km ・・・ RowKey Column エポック Z3コード ID VIN Speed その他 2444 100010001…111 ID-32 VIN32 50km ・・・ 2444 100110101…101 ID-91 VIN91 30km ・・・ 2444 100110011…100 ID-21 VIN21 79km ・・・ 2444 100111010…100 ID-16 VIN16 10km ・・・ 2444 100111100…100 ID-63 VIN63 90km ・・・ 2444 100111100…101 ID-46 VIN46 30km ・・・ 2444 100111101…101 ID-17 VIN17 10km ・・・ 2444 100111101…101 ID-78 VIN78 70km ・・・ 2444 100111110…110 ID-99 VIN99 30km ・・・ 2444 100111111…101 ID-41 VIN41 40km ・・・ 2444 100111111…111 ID-61 VIN61 20km ・・・ Z3コード（時空間コード）でソートされている → 検索対象外のデータ量が増加しても、検 索対象の時空間データのみにアクセス可能 ソート済 ソート済 データ保持期間が短いとき (運用開始直後など） データ保持期間が長いとき (過去データがある程度溜まってきた時)
- 36. © 20２1 NTT DATA Corporation 36 利用するには
- 37. 時空間情報を処理するOSSを利用する OSGeo-Live 14.0 https://live.osgeo.org ほとんどのドキュメントが日本語化された最初のバージョン 2021年1月31日リリース予定 → 現在3か月遅れでBeta2がリリース OSGeo 財団による提供 PostGIS, QGISなど地理情報処理のソフトを試せる GeoDocker https://github.com/geodocker コンポーネントがDockerで導入可能 Eclipse Foundationの LocationTech Technology Project が提供 GeoMesaなどBig Spatial Data関連コンポーネントを容易に導入可能
- 39. 今後必要とされること • MySQL, PostGISにより、地理情報処理が安定して実施できる 状況だが、さらなる時空間への拡張が期待される • 新たなOSSも登場したが、ドキュメントや事例、ノウハウが不足して いる • 大規模になると、Apache Hadoopファミリーやエンタープライズ Java系のノウハウが必要となり、従来のGISのノウハウでは不十分 となる
- 40. © 2021 NTT DATA Corporation その他、記載されている会社名、商品名、又はサービス名は、 各 社の登録商標又は商標です。 Contact me Github, Twitter, Messenger → @miurahr