時系列の世界の時系列データ

®© 2014 MapR Technologies 1

®

© 2014 MapR Technologies

Jim Scott, Director, Enterprise Strategy & Architecture Things Expo – 2014 年 11 月


アジェンダ •  時系列とは何か? •  時系列はどこから来るか? •  処理のために何が必要か?

–  理論的に –  現実的に

•  どのように扱えばよいか? –  時系列処理の基本 –  高度な時系列データベース


時系列（Time Series）とは何か? •  タイムスタンプ付きの何か

–  センサー計測値 –  システム統計値 –  ログファイル –  設定ファイル

そう、その通り •  それから、いくつかの分類

–  数値で表現される時系列（ほとんどの人が思い浮かべるもの） –  イベント –  非数値で表現される時系列（特殊なケース）


時系列分かりました?


時系列で何ができるか •  取得

–  計測、送信、受信

•  蓄積 –  個別に、もしくは一定時間でグループ化

•  検索 –  アドホック、柔軟性、相互関係、集計

•  分析と可視化 –  検索を通じて実行


取得通常あまり問題にならない

•  センサー •  データ収集 – エージェント、Raspberry Pi •  送信 – LAN/WAN、モバイルネットワーク、衛星経由 •  システムでの受信 – デーモンまたはキューでの待ち受け、もしくは使

い方によってはデータベースへの直接書き込み


ストレージの選択 •  フラットファイル

–  大量データの短時間での投入に適している –  基本的にどんなデータタイプにも対応する –  高頻度の更新が要求されるデータには適さない –  特定範囲の検索は苦手

•  従来の RDBMS –  10,000/秒までの投入／構造化された（数値）データが望ましい／高コスト

•  NoSQL（MapR-DB や HBase など） –  10,000 行 / 秒 / ノードの処理は余裕 – リニアにスケール –  様々な種類のデータに対応 –  高頻度の更新に適している –  範囲検索が容易


検索の要件 •  時系列、時刻範囲、タグにより検索

–  一度に数百万件のデータポイントが返る可能性も –  可能であればその場でウインドウ集計を行う

•  シンプルなクエリ

–  開始時刻、終了時刻、メトリクス、タグ –  連携のための REST API –  テストのためのコマンドラインインターフェース

•  グラフ


特定の事例 •  サーバファームを想定 •  数多くのシステムメトリクス •  一般に、100〜300 統計値 / 30 秒 •  負荷、RPC の数、パケット数、リクエスト/秒 •  一般に、100〜10,000 台


概算 10 サンプル / 秒 / 台

x 1,000 台 = 10,000 サンプル / 秒

•  Open TSDB で処理するのに適切な規模

•  インストールしてやってみましょう、ただし大きな規模では試さないように


スケールするか?


特定の事例 •  石油掘削リグを想定 •  油井を掘削する際、数多くの可動部品が存在する •  一般に、掘削リグは約 1 万サンプル/秒を生成 •  温度、圧力、磁力、機械振動レベル、

塩分濃度、電圧、電流、その他多数 •  一般に、プロジェクトあたり 100 リグ


概算 1 万サンプル / 秒 / リグ

x 100 リグ = 100 万サンプル / 秒

•  だが待て、まだある –  システムをテストする必要性を考慮 –  もしかするとそれは一年分のデータかも –  するとそのデータを 1 年より遥かに短時間でロードすることが必要

•  リアルタイムの 100 倍 = 1 億サンプル / 秒


どのように動かすか（Open TSDB on MapR）?

メッセージキューコレクタ MapR

テーブルサンプル

Web サービスユーザ


データストレージ •  一般に、時間ウインドウは 1 時間 •  カラム名は時間ウインドウからのオフセット •  別のテーブルで series-uid を検索する

Key 13 43 73 103 … … series-uid.time-window 4.5 5.2 6.1 4.9

…


最終的な圧縮 •  blob としてデータを挿入すると、もともとのカラムは冗長になる •  通常とは異なり、これが時系列 DB のあるべき姿

Key 13 43 73 103 blob … series-uid.time-window 4.5 5.2 6.1 4.9 {t:[13,43,73,103],

v=[4.5,5.2,6.1,4.9]} …


最終的な圧縮

•  古いデータは blob のみに変換してしまえば、ストレージ容量を抑え、高速に検索することができる

Key blob … series-uid.time-window {t:[13,43,73,103],

v=[4.5,5.2,6.1,4.9]} …


1 回ごとのローディング •  サンプル毎に 1 回の挿入が必要、圧縮で別にもう 1 回挿入が必要 •  クラスタ上の典型的なパフォーマンス

–  1 エッジノード + 4 クラスタノード –  毎秒 2 万サンプルまでの測定

•  サーバ監視には適している •  大規模な履歴の投入には適さない •  1000 倍規模の産業用途には遅すぎる


ちょっとした工夫 … メモリにデータをバッファ

メッセージキューサンプル

ユーザ

コレクタ MapR テーブル

Web サービスログ

コレクタで1時間分のデータをバッファすることで1000倍以上の性能向上が得られる

最新の1時間分のデータをログにためることでコレクタのクリーンな再開が可能（ラムダ + イプシロンアーキテクチャ）

Webサービスはデータベースとコレクタ両方に問い合わせる


一括ローディング •  3600 サンプルで 1 回の挿入

–  圧縮は不要

•  クラスタ上の典型的なパフォーマンス –  1 エッジノード + 4 クラスタノード –  毎秒 3000 万サンプルまでの測定 –  700 倍以上高速な挿入

•  大規模な履歴の投入に適している •  3000 万データポイントの取り出しは 20 秒以内（JSON 形式） •  産業用途向け


どういうケースには適さないか? •  場合によって、系列 ID + 時間範囲による検索では不十分

•  ログファイル –  テキストベースの条件をもとにした非常に柔軟なイベントの検索が必要な場

合

•  時系列データベースより検索エンジンが有利な場合も –  Lucene ベースの検索エンジンは 100 万イベント / 秒以上スケールする

•  時空間（Geo-temporal）ストレージアクセスパターン


Q & A

@kingmesal maprtech

[email protected]

Engage with us!

MapR

maprtech

mapr-technologies

時系列の世界の時系列データ

Data & Analytics