Uploaded bySORACOM,INC
IoT と時系列データと Elasticsearch | Data Pipeline Casual Talk Vol.4
IoT と時系列データと Elasticsearch Data Pipeline Casual Talk Vol.4 株式会社ソラコム ソリューションアーキテクト 今井 雄太
More Related Content
![[AWS EXpert Online for JAWS-UG 18] 見せてやるよ、Step Functions の本気ってやつをな](https://cdn.slidesharecdn.com/ss_thumbnails/awsxon18howfarstepfunctionsgo-211124111849-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス](https://cdn.slidesharecdn.com/ss_thumbnails/amazonauroratips-170307140000-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to IoT と時系列データと Elasticsearch | Data Pipeline Casual Talk Vol.4
IoT と時系列データと Elasticsearch | Data Pipeline Casual Talk Vol.4
- 1. IoTと時系列データとElasticsearch at Data PipelineCasual Talk Vol.4 Yuta Imai Solutions Architect, SORACOM, INC.
- 2. Who am I 今井雄太 経歴: • Sierで7年くらい • SNSの会社でアドサーバーとレポートシステムの開発 2.5年 • クラウドベンダでソリューションアーキテクト 3.5年 • Hadoopベンダでセールスエンジニア 1年 • ソラコムでソリューションアーキテクト 3年
- 3.
- 4.
- 5. お客様事例: ダイドードリンコ様 • 数万台以上の回線管理 •SORACOM Funnelを活用 し安全かつ容易にデータを 送信 毎日、明日が楽しみにな る。未来型自販機！
- 6.
- 7.
- 8.
- 9.
- 10. クラウド側の処理は変わらない モノ Funnel Beam Stream Batch Amazon Athena Amazon S3 AWS Lambda Amazon Redshift BigQuery Feedback model Pipeline Processing Time seriesDB Machine Learning Ad-hoc queries Metrics Feedback Event リアルタイムな イベント検出 ダッシュボード BI 機械学習 データレイク Feedback rule デバイス側での イベント検出 Google Cloud Storage
- 11.
- 12.
- 13.
- 14. SORACOM Air -モバイル通信サービス •だれでも •一枚から •使った分だけ
- 15.
- 16.
- 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
- 18.
- 19. SORACOM Funnel モノ SORACOM AmazonKinesis 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 認証したリクエストを 各種クラウドサービスへ直接送信
- 21.
- 22.
- 23.
- 24.
- 25.
- 26. ひとつの選択として: Elasticsearch ソラコムのお客様はITの専門家でないひとたちも多いので、情報の得やすさ や使い勝手、運用の容易さがあるとよい。 • 時間ベースのAggregation（ゼロフィル含め）が簡単にできる •情報が得やすく、KibanaがあるのでGetting startedしやすい • GCPやAWS上で利用可能なマネージドサービスがある • とりあえずデータを投げ込めばなんとかしてくれる（少なくとも最初は） • スケーラビリティがビルトインなので成長に対する安心感
- 27.
- 28. 一般的な時系列DBのウリ • Writeヘビーなワークロードに強い • イベントやログの書き込みに対する高いスループットや信頼性 •LSMツリーベースのデータ構造 • データの圧縮率が非常に高い • カラムナーストレージによる高圧縮率の実現 このあたり、Elasticsearchではどうなっているので しょうか
- 29.
- 30. Elasticsearch - Shard Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node0 Node 1 Node 2 Index Lucene Index Shard単体はそれぞれがLuceneのIndex。（用語が混乱しがちｗ)
- 31. Elasticsearch – LuceneIndex Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index まずはこの中身を覗いてみましょう
- 32. Elasticsearch – LuceneIndex 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 – LuceneIndex Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index Lucene Index
- 42. Elasticsearch – WritePath 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 – WritePath • shardIdはhash関数を使ってDocumentのField情報(_id?)をもとに決定 される。 • つまり、例えば特定のFieldをキーにして時系列にソートされた Document群がひとつのShardに格納されるわけではない。
- 44. Elasticsearch – SearchPath 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 – SearchPath • 前述のように、ほしい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 – DocValues • 「Indexを（例えば）日毎に分ける」「Shardあたりの受け持ちデータ量/クエリ量を 適切に」という2点を守っていればOKそうに思えてきましたよね。 • 内部的な話としてはLucene Indexは更に内部的にはImmutableなSegmentという ものを追記していくことでDenseなWriteオペレーションを効率的にさばけるように していることも分かってきました。 圧縮率とかカラムナーストレージの話は？
- 49.
- 50. Elasticsearch – DocValues こんなクエリがLuceneに対して発行されます
- 51. Elasticsearch – DocValues • 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 – DocValues • 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, weconnect.