淺析時間序列數據

時間 2020-01-10

標籤淺析時間序列數據简体版

原文原文鏈接

時間序列是一個在IT基礎設施組件、物聯網傳感器的每一個業務流程中以及在應用程序中功能強大的等待被解鎖的強大武器。利用好它能夠揭示可操做的趨勢，模式，可變性，變化，共變，週期異常，異常和異常值率。在實踐中，認識的時間序列數據可幫助您回答這樣的問題：php

基於訪問者的行爲給用戶最好的反饋方式是什麼，實時？git
我該用什麼樣的模式可讓我在金融市場上執行更快速更智能的交易？github
我能夠預見到訪客的停留時間以及爲何他們會離開麼？mongodb
我能跟蹤運輸車隊上面的傳感器隨着時間的推移，以優化交貨的時間和燃油經濟性？數據庫
我可否預測個人彈性基礎設施可否承受住相似黑色星期五規模的事件？json
我能夠經過在我網絡中PB級別數據傳輸隨着時間的變化來檢測我網絡中的惡意模式麼？服務器
我能夠根據環境條件實時的調整水，肥下降個人成本，增長個人做物產量麼？微信

時序數據用例

在InfluxData，最廣泛使用的狀況下，咱們幫助到企業是自定義的監視體系，實時分析解決方案，物聯網（IOT）和傳感器數據管理系統，再加上的OpenStack，雲，容器或虛擬基礎架構監控互聯網。網絡

然而，時間序列數據限制爲僅少數使用上述狀況是不現實的。 InfluxData用戶與咱們分享種類繁多的通用和特殊的使用案例，例如：架構

異常檢測
消息
個性化
股票交易
市政基礎設施管理
GPS服務
量子物理研究
銷售點系統
製造與家庭自動化
運輸和物資保障

什麼是時序數據

時間序列數據無非是基於時間的一序列數據點，更典型地由來自在一時間間隔相同的源製成連續測量的。換句話說，若是你要在圖上畫出你的觀點，你的其中一個軸將永遠是時間。例如，時間序列數據可經過像氣象站或RFID標識，IT基礎設施組件，如應用程序，服務器和網絡交換機或經過股票交易系統的傳感器來產生的。

時間序列數據的圖形示例

那些不是時序的數據集

這裏有幾個隨時間變化的缺少時間成分的數據集的幾個例子：示出了人們之間的關係的數據，散點圖，顯示一個變量如何影響另外一個，或示出了活動的給定體積比例的捐款的數據。由於他們缺少時間的組件，咱們不能認爲他們「時間序列」的數據。

時序的數據庫

時序數據庫優化了收集，存儲，檢索和處理時序數據。相對於文檔數據庫（優化了對json文檔的存儲），搜索數據庫（優化了全文搜索）或者傳統的關係型數據庫（優化了關係型數據表格存儲）

Baron Schwartz概述了一些專用時間序列數據庫的典型特徵應包括：

數據庫90%以上的工做量是高頻高容量的寫入
寫操做一般是隨着時間追加到現有的表中
這些寫操做一般是按必定時序的，例如：每秒或者每分鐘
若是時間序列數據庫中獲取受限資源，這一般是由於它是I / O綁定
更新單個點數據的操做不多
刪除數據幾乎老是跨越大的時間範圍（日，月或年）進行，幾乎從不到一個特定的點
數據庫查詢操做一般是在某序列中有序的，多是按時間排序或者按某功能排序
執行並行讀取或者多組讀取是常見的

這裏有一些開源的，對時序數據存儲和處理都比較高效的時序數據庫：

InfluxDb
OpenTSDB (Runs on top of Hadoop and HBase)
KDB+
Graphite
More examples on Wikipedia

須要注意的是一些時間序列的產品和項目正在積極維護和開發，而另外一些人不多能獲得更新。咱們建議把項目的社區發展/支持，發展速度和商業的支持來做爲你選用項目的一些評價標準（若是你正在考慮該數據庫是開源的。）

目前最火的時序數據庫是什麼？

截至2016年4月的，InfluxDB被DB-engines.com排名最流行的時間序列數據庫。你能夠在這裏得到最新排名。

開明的開發人員和架構師明白，最成功的項目都是那些不管公司組織的偏見最終選擇了正確的工具的項目。InfluxDB已經幫助許多企業避免了不少額外的努力去整合一個時間序列數據庫與其餘正在使用的數據管理系統，與試圖使一個「圓釘適合到一個方孔。」在接下來的幾節中，咱們將看看爲何企業經過採用專用數據庫來管理本身的時間序列數據服務每每是更好的。

Time-Series vs ElasticSearch 和其餘全文檢索數據庫

全文或「搜索」數據庫是由文本文檔，如書籍，報紙，學術論文或文字在網頁上，或者日誌中發現。爲了說明時間序列和全文檢索數據庫之間的差別，咱們將使用ElasticSearch做爲一個例子。

ElasticSearch是用Java編寫的一個開源的，全文搜索引擎，建在了Apache Lucene項目之上。這不是在傳統意義上的數據庫，這是一個JSON文檔的數據存儲。你能夠把它和InfluxDB（一個開源的用Go實現的時序數據庫）在表和標籤方面作個比較。隨着一些努力，ElasticSearch能夠用有限的數學和分析功能，管理時間序列指標，但它是否是這個用例建的目的。對比InfluxDB來講它在單節點上你沒法獲得很好的性能和壓縮能力。且不說像數據聚合，連續查詢和保留策略的時間序列的特定功能。可是，InfluxDB和ElasticSearch很好地協同工做的一種方式是在日誌由ElasticSearch和性能指標與用於數據結合共同的可視化工具，管理由InfluxDB系統（如Grafana）。

Time-Series vs Cassandra和其餘混合/面向列的數據庫

正如其名稱所暗示的，面向列的數據庫中組織數據基於列而不是行。面向列的數據庫很是適合構建數據倉庫、或者須要支持大量聚合的，須要計算很是大相似數據的即席查詢的系統。爲了說明時間序列和麪向列數據庫之間的差別，咱們將使用Cassandra，這個在技術上是一個面向列的數據庫爲例。

Cassandra是一個用Java實現的開源的、分佈式的基於鍵值對和麪向列的混合型數據庫。它在作了高容錯的同事還保持着高性能的特性。與此相比，InFluxDB是開源的用Go寫的用表和標籤的形式來管理時序數據的時序數據庫。

Cassandra是InfluxDB的界定「易於使用」特色的對立面。它有不少的依賴，配置，部署和管理都比較複雜。Cassandra須要用戶編寫一個查詢計劃，執行器和其它代碼到應用程序來處理時間序列數據（即已經在InfluxDB中的功能。）最後，先把全部數據從系統中提取出來再執行查詢，對比用InfluxDB直接在數據庫內直接執行查詢。你能夠想像，對於很是大的數據集，這可能會對性能產生不良影響。

Time-Series vs MongoDB 和其餘面向文檔的數據庫

MongoDB是用C++實現的開源的面向文檔的數據庫，它用動態模式優化了對類JSON（BSON）文檔的管理。與此相比，InFluxDB是開源的用Go寫的用表和標籤的形式來管理時序數據的時序數據庫。

開發人員常常用MongoDB去管理時序數據由於這是他們所熟悉的一種技術。毫無疑問，若是你想在MongoDB中管理時間序列數據，正確的模式設計相當重要。若是開發人員理解"一個Point(InfluxDB中的一條數據)等於一個文檔"，那麼他們很快就會遇到如何有效地管理大量的文檔內存需求挑戰。相反，嘗試存儲時序數據在一個文檔中是艱鉅的由於文件由它們的大小限制。此外，對子文檔可用的查詢功能也是有限的。而且只是用文檔存儲時序數據，開發人員確定會遇到更糟糕的查詢性能。最後，MongoDB的子文檔中不能使用MongoDB的map-reduce功能，這也是MongoDB處理時序數據的缺憾。