IoT と時系列データと Elasticsearch | Data Pipeline Casual Talk Vol.4
•
11 gefällt mir•10,678 views
IoT と時系列データと Elasticsearch Data Pipeline Casual Talk Vol.4 株式会社ソラコム ソリューションアーキテクト 今井 雄太
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie IoT と時系列データと Elasticsearch | Data Pipeline Casual Talk Vol.4
Ähnlich wie IoT と時系列データと Elasticsearch | Data Pipeline Casual Talk Vol.4 (20)
Mehr von SORACOM,INC
Mehr von SORACOM,INC (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (10)
IoT と時系列データと Elasticsearch | Data Pipeline Casual Talk Vol.4
- 1. IoTと時系列データとElasticsearch at Data Pipeline Casual Talk Vol.4 Yuta Imai Solutions Architect, SORACOM, INC.
- 2. Who am I 今井 雄太 経歴: • Sierで7年くらい • SNSの会社でアドサーバーとレポートシステムの開発 2.5年 • クラウドベンダでソリューションアーキテクト 3.5年 • Hadoopベンダでセールスエンジニア 1年 • ソラコムでソリューションアーキテクト 3年
- 3. IoT?
- 4. お客様事例: 西鉄グループ様 乗車当日の時刻表と現時 刻の時間帯を大文字で画 面に掲載。多言語対応で、 運行状況や緊急時のお知 らせ等も一斉配信 スマートバス停実証実 験、リアルタイム情報 提供 協力パートナー：安川情報システム株式会社 お客様事例: 西鉄グループ様 Ⓒ2014 ZENRIN CO.LTD.(Z14KF No.213)
- 5. お客様事例: ダイドードリンコ様 • 数万台以上の回線管理 • SORACOM Funnelを活用 し安全かつ容易にデータを 送信 毎日、明日が楽しみにな る。未来型自販機！
- 7. IoTの技術面での難しさ
- 8. インターネット クラウドモノ IoTは、テクノロジーの総合格闘技 センサー ゲート ウェイ デバイス 通信 データ 収集 可視化 デバイス 管理 省 電力化 セキュ リティ クラウド 連携 遠隔 管理
- 9. IoTでも変わらないもの
- 10. クラウド側の処理は変わらない モノ Funnel Beam Stream Batch Amazon Athena Amazon S3 AWS Lambda Amazon Redshift BigQuery Feedback model Pipeline Processing Time series DB Machine Learning Ad-hoc queries Metrics Feedback Event リアルタイムな イベント検出 ダッシュボード BI 機械学習 データレイク Feedback rule デバイス側での イベント検出 Google Cloud Storage
- 11. ソラコムが解決すること
- 14. SORACOM Air - モバイル通信サービス •だれでも •一枚から •使った分だけ
- 16. SORACOMの特徴
- 17. エッジプロセッシング SORACOM Mosaic IoTテクノロジー民主化のためのプラットフォーム SORACOMGlobalPlatform ライブラリ & SDKs CLI(Go), Ruby, Swift Web インターフェース User Console データ転送支援 SORACOM Beam クラウドアダプタ SORACOM Funnel データ収集・蓄積 SORACOM Harvest Data / Files プライベート接続 SORACOM Canal IoT向けデータ通信 SORACOM Air for Cellular (2G, 3G, LTE) / LPWA (LoRaWAN, Sigfox, , LTE-M) / アップロード専用SIM 専用線接続 SORACOM Direct 仮想専用線 SORACOM Door API Web API Sandbox コネクティビティ ネットワーク インタフェース SIM認証・証明 SORACOM Endorse デバイス管理 SORACOM Inventory 透過型トラフィック処理 SORACOM Junction ダッシュボード作成/共有 SORACOM Lagoon セキュアプロビジョニング SORACOM Krypton アクセス権限管理 SORACOM Access Management アプリケーション デバイスLAN SORACOM Gate 開発者サポート Developer Support USB ドングル / セルラーモジュール / マイコンモジュール / ボタン / カメラデバイス クラウドファンクション SORACOM Funk オンデマンドリモートアクセス SORACOM Napter
- 19. SORACOM Funnel モノ SORACOM Amazon Kinesis Data Firehose Microsoft Azure EventHubs AWS IoT Core Amazon Kinesis Data Streams Google Cloud Pub/Sub Amazon Kinesis Video Streams SORACOM Funnel Credential HTTP TCP UDP HTTPS等funnel.soracom.io 認証したリクエストを 各種クラウドサービスへ直接送信
- 25. 時系列DBの選択肢（の一部）
- 26. ひとつの選択として: Elasticsearch ソラコムのお客様はITの専門家でないひとたちも多いので、情報の得やすさ や使い勝手、運用の容易さがあるとよい。 • 時間ベースのAggregation（ゼロフィル含め）が簡単にできる • 情報が得やすく、KibanaがあるのでGetting startedしやすい • GCPやAWS上で利用可能なマネージドサービスがある • とりあえずデータを投げ込めばなんとかしてくれる（少なくとも最初は） • スケーラビリティがビルトインなので成長に対する安心感
- 28. 一般的な時系列DBのウリ • Writeヘビーなワークロードに強い • イベントやログの書き込みに対する高いスループットや信頼性 • LSMツリーベースのデータ構造 • データの圧縮率が非常に高い • カラムナーストレージによる高圧縮率の実現 このあたり、Elasticsearchではどうなっているので しょうか
- 29. Elasticsearch Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index
- 30. Elasticsearch - Shard Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index Lucene Index Shard単体はそれぞれがLuceneのIndex。（用語が混乱しがちｗ)
- 31. Elasticsearch – Lucene Index Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index まずはこの中身を覗いてみましょう
- 32. Elasticsearch – Lucene Index Shard (Lucene Index) Lucene IndexはSegmentと呼ばれるファイルの集合。 Segment Segment Segment Inverted Index Inverted Index Inverted Index
- 33. Lucene Index - Write Shard (Lucene Index) SegmentはImmutable。書き込み(addDocument)はインメモリバッファで受 け取る。 Segment Segment Segment Inverted Index Inverted Index Inverted Index In-memory buffer write 更に、データロストを防ぐために Translogというファイルにも同様 の情報が追記される。
- 34. Lucene Index - Write Shard (Lucene Index) バッファは定期的に(デフォルトでは1秒おき)に新しいSegmentとしてFlush され、初めてSearchableになる。 Segment Segment Segment Inverted Index Inverted Index Inverted Index In-memory buffer Segment Inverted Index flush
- 35. Lucene Index - Search Shard (Lucene Index) Lucene Indexに対するSearchはすべてのSegmentに対してScanが実施さ れ、マージされた結果が返る。 Segment Segment Segment Inverted Index Inverted Index Inverted Index Segment Inverted Index IndexSearcher
- 36. Lucene Index - Search Shard (Lucene Index) SegmentはImmutableなのでFile System Cacheをうまく活用しやすいように なっている。 Segment Segment Segment Inverted Index Inverted Index Inverted Index Segment Inverted Index IndexSearcher
- 37. Lucene Index - Delete Shard (Lucene Index) DeleteはレコードにDeleteフラグを立てるだけ。Search時にフィルタされる。 なのでSearchのコストが高くなる。 Segment Segment Segment Inverted Index Inverted Index Inverted Index Segment Inverted Index Deleted : true
- 38. Lucene Index - Update Shard (Lucene Index) UpdateはWriteとDeleteのあわせ技。さらにコストが高い。 Segment Segment Segment Inverted Index Inverted Index Inverted Index Segment Inverted Index Deleted : true In-memory buffer addDocument
- 39. Lucene Index – Compaction/Rollup Shard (Lucene Index) 古いSegmentはより大きなSegmentとしてMergeされていく。この際に Deletedなレコードはパージされる。 Segment Segment Segment Inverted Index Inverted Index Inverted Index Segment Inverted Index Deleted Segment Inverted Index Merge sort
- 40. Lucene Index – Compaction/Rollup Shard (Lucene Index) 古いSegmentになるほどCompaction対象になる頻度も減り、キャッシュを 活かして高速な検索が可能になる。(LSMっぽい) Segment Segment Segment Segment Segment NewOld In-memory buffer Write
- 41. Elasticsearch – Lucene Index Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index Lucene Index
- 42. Elasticsearch – Write Path Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index Client index request Routing クラスタ内のどのNodeでもリク エストは受付可。Coordinatorとし て動作して、shardIdを決定してそ のShardのPrimary Nodeへルー ティングする。 Decide routing 出典: Elasticsearch: The Definitive Guide: A Distributed Real-Time Search and Analytics Engine (English Edition)
- 43. Elasticsearch – Write Path • shardIdはhash関数を使ってDocumentのField情報(_id?)をもとに決定 される。 • つまり、例えば特定のFieldをキーにして時系列にソートされた Document群がひとつのShardに格納されるわけではない。
- 44. Elasticsearch – Search Path Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index Client search request searchはすべてのShardに対してリ クエストを転送し、結果をマージ する。 参照系のOperationはReplicaを利 用することができる。
- 45. Elasticsearch – Search Path • 前述のように、ほしいDocument群はすべてのShardに等しく存在する 可能性をもっている。 • よって、SearchはすべてのShardをScanし、それらのレスポンスが マージされたものが最終的な結果となる。 • つまり、Fieldの内容によってデータが偏ったりはしない（はず）で、 Shardの数を増やすことによるリニアなスケールが期待できる。 • さらに、Readヘビーなワークロードの場合、それらを処理するために Replicaを増やすという戦略も取れる。
- 46. Elasticsearch – Performance • Write(Index)はShardの偏りが発生しないようになっているので、Shard数を増やすことに よってスケーラビリティを確保しやすくなっている • Read(Search)もすべてのShardをScanする前提になっているので、Shard数を増やすこと で（ShardあたりのDocument量が減ることにより）スケールしやすくなっている。 • ただし、Shard内のSegment群がファイルキャッシュに載る限りにおいて。 • また、精度の観点からはShardは1つで済むならそちらのほうがいいという話がある。 もちろん、リソース利用の観点からのShardが少ないほうがいい。 • https://www.youtube.com/watch?v=PpX7J-G2PEo&t=2110
- 47. Elasticsearch – Performance • Segmentがファイルキャッシュに乗らなくなるとパフォーマンスに問題が発生する ため、ElasticsearchのIndexは、例えば日毎に分ける。それによってひとつの Indexあたりのデータ量に制約をかけるとともに予測が容易になる。 • つまりこれってPartitioning • 古いDocumentをパージするにも、DeleteではなくてIndexごと削除していくことで 低コストなオペレーションができる。 log- 2019090 1 log- 2910909 02 Elasticsearch indices log- 2019090 3 log- 2910909 04 log- 2019090 5 log- 2910909 06 log- 2019090 7 …
- 48. Elasticsearch – Doc Values • 「Indexを（例えば）日毎に分ける」「Shardあたりの受け持ちデータ量/クエリ量を 適切に」という2点を守っていればOKそうに思えてきましたよね。 • 内部的な話としてはLucene Indexは更に内部的にはImmutableなSegmentという ものを追記していくことでDenseなWriteオペレーションを効率的にさばけるように していることも分かってきました。 圧縮率とかカラムナーストレージの話は？
- 49. こういうクエリをなげると・・・ Elasticsearch – Doc Values
- 50. Elasticsearch – Doc Values こんなクエリがLuceneに対して発行されます
- 51. Elasticsearch – Doc Values • Doc Valuesとは、Field(RDB的に言えばカラム)ごとに作成される、「ValueでSortさ れたSecondary Index的なカラムナーストレージ」のこと。Inverted Indexと同様に Segmentごとに作成される。 • Inverted Indexは全文検索を高速に解決するためには有効だが、例えば「date: 20190930」みたいなValueで検索することには最適ではない。また、ValueでSort されていない。（TermでSortされている） • 今回のテーマで扱っているようなクエリ(SortやAggregation)はほぼこちらのDoc Valuesをつかって実現されている。（はず） • Doc Valuesはカラムナーストレージなので圧縮率も高い。（圧縮方式は）
- 52. Elasticsearch – Doc Values • Doc Valuesはカラムナーストレージなので圧縮率も高い。もちろん型もある。（圧 縮方式まではしらべきれていない） • Doc ValuesはSegmentの作成時に一緒に作成されるので、カラムナーストレージ の連続的書き込みの相性の悪さをうまく解決してくれている。 • いいですね！ • 一方、ドキュメントをいろいろあたって見る限り、SegmentごとにBoundary(例えば、 当該Segmentが担当するFieldのValueの最小値、最大値)や、Bloom Filterを持っ ているわけではなさそう。（おそらく）
- 53. Elasticsearch – Conclusion • 「Indexを（例えば）日毎に分ける」「Shardあたりの受け持ち データ量/クエリ量を適切に」という2点を守っていれば、時系 列DBっぽいユースケースにはしっかりおすすめできる。 • という感じに・・・結果として広く世に伝わっているプラクティ スをなぞる形にはなりましたが、「あ、これでよかったんや」 的にわりと安心できましたよね？(にっこり）
- 54. Executive conclusion • SORACOMは通信を中心に、様々なヘビーリフティングを肩 代わりします！ • デバイスも最近はいろんなボードやゲートウェイが簡単に手 に入るようになってきています！ • もちろん、クラウドもどんどん便利になってきていますよね。 • IoTも価値のあるところ「だけ」に集中できる世の中になって きています。 • IoTアプリケーションを作る際にはSORACOMを使ってぜひ楽 をしてください！
- 55. You create, we connect.