influxdb数据过期_为什么腾讯QQ的大数据平台选择了InfluxDB数据库？
導讀：本文帶你了解一個開源的、高性能的時序型數據庫——InfluxDB。
作者：韓健
來源：華章科技
00 為什么QQ要選擇InfluxDB？
從2016年起，筆者在騰訊公司負責QQ后臺的海量服務分布式組件的架構設計和研發工作，如微服務開發框架、名字路由、名字服務、配置中心等，做了大量分布式架構、高性能架構、海量服務、過載保護、柔性可用、負載均衡、容災、水平擴展等方面的工作，以公共組件的形式支撐來自QQ后臺和其他BG海量服務的海量流量。
2018年年底，筆者負責監控大數據平臺的研發工作，致力于減少現有監控后臺成本，以及支撐內部和外部海量監控數據的需求，打造千億級監控大數據平臺。
筆者發現，當前監控技術領域缺乏優秀的監控系統，尤其是在海量監控數據場景中，很多團隊常用的做法是堆服務器和堆開源軟件，比如大量采用高配置的服務器，單機近百CPU核數、TB內存、數十TB的SSD存儲，安裝了大量開源軟件，如Elasticsearch、Druid、Storm、Kafka、Hbase、Flink、OpenTSDB、Atlas、MongoDB等，但實際效果并不理想。
眾多開源軟件的組合是在增加了系統的運營成本和數據的處理延遲的情況下解決接入計算，在海量標簽和時間序列線情況下，常出現查詢超時、數據拉不出來等問題，且成本高昂。
筆者認為，海量或千億級是整體的量，是個籠統的概念，可以分而治之，通過分集群的方法來解決，海量監控數據的真正挑戰在于以下幾點：
- 能否做到實時。實時是種質變的能力，可將一個離線監控平臺提升為一個實時決策系統。難點在于能否設計實現高性能的架構，以及能否實現水平擴展等。
- 分集群后，單個業務的流量大小、標簽集多少是關鍵。流量大，相對容易解決，主要涉及系統性能和水平擴展等。標簽集多，海量標簽，海量時間序列線，如何做查詢優化是挑戰，如筆者遇到的一些業務上報的監控數據，有幾十個維度的標簽，并將QQ號和URL作為標簽值，有非常海量的時間序列線。
- 針對監控數據多寫少讀、成本敏感的特點，如何設計高效的存儲引擎？既能充分發揮硬件性能，又能在高效壓縮存儲的同時保障查詢效率。
為了更好地打造有競爭力的監控系統，我們將技術理念定位為“技術降成本，堅決反對開源軟件堆砌”。
- 首先，我們認為云計算是基建，決定它能否成功的關鍵在于能否在基礎技術上突破，打造出相比開源軟件更有成本優勢的云原生軟件；
- 其次，雖然現在開源軟件非常繁榮，基于開源軟件，我們很容易搭建一個基礎系統，將功能跑起來，但絕大部分開源軟件側重的是功能，而不是針對海量監控數據的場景進行設計，或多或少都有其局限性，且成本也非常高昂。
因此我們要做的是借助強大的技術和工程能力，直面問題，在架構和源碼層面解決它，而不是引入和堆砌更多的開源軟件。
出于工程效率的考慮，我們選擇基于開源軟件進行二次開發，使用開源軟件的部分代碼，按照我們的想法進行架構設計和功能開發。在對眾多的開源軟件進行調研分析后，我們最終選擇了以InfluxDB源碼為基礎進行二次開發。
之所以選擇InfluxDB源碼，主要是因為我們對InfluxDB源碼背后的技術和工程實力比較認可。InfluxDB研發團隊能真正解決海量監控數據場景的問題，也是在認真地打造一款優秀的監控產品(出于讀寫性能和可用性的考慮，InfluxDB研發團隊曾2次重構存儲引擎)。
在筆者著手以InfluxDB源碼為基礎開發集群等功能時，業界還沒有團隊實現了真正可用的InfluxDB集群能力。一些團隊只是通過Proxy實現了負載均衡，卻無法突破單機接入計算和存儲的限制，缺乏一致性能力。
有些團隊在對InfluxDB進行了多年的學習和研究后，最終考慮到基于時序分片的復雜度而放棄了基于InfluxDB開發集群能力，轉而選擇基于RocksDB、Zookeeper等開源軟件進行自建。
筆者在3個月內快速開發出了CP和AP架構分離、時序分片、水平擴展等基本集群能力，另外，根據業務的特點，在索引引擎、冷熱分離、查詢實現、第三方協議、高可用性、可運營性等方面也做了大量的工作。
最終的效果也是符合預期的，如從替換現有監控系統后臺的實施對比來看，我們用了不到10%的機器成本就支撐起原監控后臺所支撐的海量監控數據，成本優勢突出。
InfluxDB是一款非常優秀的軟件，直接推動監控技術進入了實時、納秒級的新時代，除了類SQL查詢語言、RESTful API等現代特性外，還具有讀寫性能高、存儲壓縮率高、生態豐富、功能強大等特性。
01 什么是InfluxDB
InfluxDB是一個開源的、高性能的時序型數據庫，在時序型數據庫DB-Engines Ranking上排名第一。
在介紹InfluxDB之前，先來介紹下時序數據。按照時間順序記錄系統、設備狀態變化的數據被稱為時序數據(Time Series Data)，如CPU利用率、某一時間的環境溫度等。
時序數據以時間作為主要的查詢緯度，通常會將連續的多個時序數據繪制成線，制作基于時間的多緯度報表，用于揭示數據背后的趨勢、規律、異常，進行實時在線預測和預警，時序數據普遍存在于IT基礎設施、運維監控系統和物聯網中。
時序數據主要有如下3個特點：
- 抵達的數據幾乎總是作為新條目被記錄，無更新操作。
- 數據通常按照時間順序抵達。
- 時間是一個主坐標軸。
時序型數據庫是存放時序數據的專用型數據庫，并且支持時序數據的快速寫入、持久化、多緯度的實時聚合運算等功能。
傳統數據庫通常記錄數據的當前值，時序型數據庫則記錄所有的歷史數據，在處理當前時序數據時又要不斷接收新的時序數據，同時時序數據的查詢也總是以時間為基礎查詢條件，并專注于解決以下海量數據場景的問題：
- 時序數據的寫入：如何支持千萬級/秒數據的寫入。
- 時序數據的讀取：如何支持千萬級/秒數據的聚合和查詢。
- 成本敏感：海量數據存儲帶來的是成本問題，如何更低成本地存儲這些數據，是時序型數據庫需要解決的關鍵問題。
InfluxDB是一個由InfluxData公司開發的開源時序型數據庫，專注于海量時序數據的高性能讀、高性能寫、高效存儲與實時分析，在DB-Engines Ranking時序型數據庫排行榜上位列榜首，廣泛應用于DevOps監控、IoT監控、實時分析等場景。
具體的DB-Engines Ranking時序型數據庫的排行榜(源自2019年5月的DB-Engines Ranking數據)如圖1-1所示。
- InfluxDB部署簡單、使用方便，在技術實現上充分利用了Go語言的特性，無須任何外部依賴即可獨立部署；
- 提供類似于SQL的查詢語言，接口友好，使用方便；擁有豐富的聚合運算和采樣能力；
- 提供靈活的數據保留策略(Retention Policy)來設置數據的保留時間和副本數；
- 在保障數據可靠性的同時，及時刪除過期數據，釋放存儲空間；
- 提供靈活的連續查詢(Continuous Query)來實現對海量數據的采樣。
- 支持多種通信協議，除了HTTP、UDP等原生協議，還兼容CollectD、Graphite、OpenTSDB、Prometheus等組件的通信協議。
▲圖1-1 時序型數據庫DB-Engines Ranking排名
講到InfluxDB，就不能不提InfluxData的開源高性能時序中臺TICK(Telegraf + InfluxDB + Chronograf + Kapacitor)，InfluxDB是作為TICK的存儲系統進行設計和開發的。
TICK專注于DevOps監控、IoT監控、實時分析等應用場景，是一個集成了采集、存儲、分析、可視化等能力的開源時序中臺，由Telegraf、 InfluxDB、Chronograf、Kapacitor 4個組件以一種靈活松散但緊密配合、互為補充的方式構成，各個模塊相互配合、互為補充，整體系統架構如圖1-2所示。
▲圖1-2 TICK系統架構
Telegraf是用于采集和上報指標的數據采集程序，采用靈活的、可配置的插件實現。
Telegraf可以通過配置文件的配置，采集當前運行主機的指定指標，如CPU負載、內存使用等，也可以從第三方消費者服務(如StatsD、Kafka等)拉取數據，上報到已支持的多種存儲系統、服務或消息隊列，如InfluxDB、Graphite、OpenTSDB、Datadog、Librato、Kafka、MQTT、NSQ等。
InfluxDB是專注于時序數據場景(如DevOps監控、IoT監控、實時分析等)的高性能時序型數據庫，支持靈活的自定義保留策略和類SQL的操作接口。
Chronograf是可視化的、BS架構的管理系統，可用于配置和管理接收到的監控數據、告警，并支持通過靈活強大的模塊和庫，快速配置數據可視化儀表盤、告警規則、可視化規則。
Kapacitor是從零構建的原生數據處理引擎，支持流式處理和批量處理，支持靈活強大的自定義功能，如定義新的告警閾值、告警指標特征、告警統計異常特征等，以及后續的告警處理行為。
除了靈活，Kapacitor也很開放，能靈活地集成對接第三系統，如HipChat、OpsGenie、Alerta、Sensu、PagerDuty、Slack等。
02 InfluxDB的優勢
存儲和分析時序數據的時序型系統并不鮮見，自計算機問世以來，我們一直在數據庫中存儲時序數據。
最初，使用通用存儲系統存儲時序數據，如MySQL。第一代時序平臺，如KDB +、RRDtool、Graphite等，在20年前就推出了，主要用于存儲和分析數據中心的時序數據，以及高頻金融數據、股票波動率等。
根據DB-Engines等數據庫趨勢跟蹤和行業分析網站發布的信息，時序型數據庫是數據庫市場中份額增長最快的部分。原因很明顯，計算機虛擬世界，如數據庫、網絡、容器、系統、應用程序等，和物理世界，如家用設備、城市基礎設施、工廠機器、電力設施等，正在創建海量的時序數據。
現在更多的企業會通過時序存儲和數據分析來獲得預測能力和實時決策能力，從而為客戶提供更好的使用體驗。這意味著底層數據平臺需要發展以應對新的工作負載的挑戰，以及更多的數據點、數據源、監控維度、控制策略和精度更高的實時響應，對下一代時序中臺提出了更高的要求，具體如下所示。
- 專為時序存儲和高性能讀寫而設計：計算機虛擬世界的各種系統和應用，以及物理世界的IoT設備等都在創建海量的時序數據，每秒千萬級的數據吞吐量是很常見的，而且這些數據還需要可以以非阻塞方式接收并且可壓縮以節省有限的存儲資源。
- 專為實時操作而設計：預測能力和實時決策能力，需要收到數據后，就能實時輸出最新的數據分析結果，執行預定義的操作。
- 專為高可用性而設計：現代軟件系統需要全天候可用，除了基本的集群能力，還需要根據需求自動擴容和縮容，支持柔性可用等。
InfluxData選擇從頭開始構建InfluxDB以支持下一代時序中臺的需求，InfluxDB通過實現高度可擴展的數據接收和存儲引擎，可以高效地實時收集、存儲、查詢、可視化顯示和執行預定義操作。它通過連續查詢提升查詢效率和縮短延遲，通過數據保留策略，及時高效地刪除過期冷數據，提升存儲效率。
為什么通用數據庫在時序場景上不是最優的選擇呢？許多通用數據庫正在為時序數據添加一些支持，雖然可能很容易使用，但它們基本上都不是針對海量時序數據的吞吐量和實時操作而設計的。
與InfluxDB相比，通用數據庫，如Cassandra、MongoDB、HBase等，需要開發人員投入大量的時間進行代碼編寫，以開發與InfluxDB類似的功能。具體來說，開發人員需要做如下工作：
- 編寫代碼實現跨集群數據分片功能、聚合運算和采樣功能、數據生命周期管理功能等。
- 實現豐富的API接口。
- 編寫用于數據采集的工具。
- 實現實時處理模塊并編寫用于監控和警報的代碼。
- 編寫可視化引擎以向用戶顯示時序數據。
為了讓讀者對InfluxDB的優勢有個直觀的認識，接下來，會把InfluxDB和其他被用作時序存儲的系統(如ElasticSearch、MongoDB、OpenTSDB)做簡要的對比：
1. InfluxDB vs ElasticSearch
ElasticSearch是專為搜索而設計的系統，是實現搜索功能的絕佳選擇。
然而，對于時序數據，卻并非如此。在處理時序數據時，InfluxDB的性能遠遠超過ElasticSearch系統，對于寫入吞吐量，InfluxDB通常優于ElasticSearch 5～10倍，具體差值取決于架構。對于特定時序的查詢速度，使用ElasticSearch比使用InfluxDB要慢5～100倍，具體差值取決于查詢的時間范圍。
最后，如果需要存儲原始數據以便稍后查詢，則ElasticSearch上的硬盤占用比InfluxDB大10～15倍。如果先匯總數據再存儲，ElasticSearch的硬盤占用比InfluxDB大3～4倍。綜合來看，ElasticSearch非常適合進行搜索，但不適用于時序存儲和實時分析。
2. InfluxDB vs MongoDB
MongoDB是一個開源的、面向文檔的數據庫，俗稱NoSQL數據庫，用C和C ++語言編寫。雖然它通常不被認為是真正的時序型數據庫(TSDB)，但它經常被用作時序存儲系統。它以時間戳和分組的形式提供建模原語，使用戶能夠存儲和查詢時序數據。
MongoDB旨在存儲“無模式”數據，其中每個對象可能具有不同的結構。實際上，MongoDB通常用于存儲內容大小可變的JSON或BSON對象。由于其采用通用性和無模式數據存儲區設計，MongoDB無法利用時序數據的高度結構化特性。
需要特別指出的是，時序數據由標簽(鍵/值串對)和時間戳組成，這時必須對MongoDB做專門配置以支持時序數據，但這樣做效率很低。
相比MongoDB，InfluxDB的性能和成本優勢明顯，InfluxDB的寫性能大約是MongoDB的2.4倍，存儲效率大約是MongoDB的20倍，查詢效率大約是MongoDB的5.7倍。綜合來看，MongoDB非常適合文檔和自定義對象，但不適用于大規模的時序數據和實時分析。
3. InfluxDB vs OpenTSDB
OpenTSDB是一個可擴展的分布式時序型數據庫，用Java語言編寫，構建在HBase之上。它最初是由Beno?t Sigoure于2010年開始編寫的，并在LGPL下開源。
OpenTSDB不是一個獨立的時序型數據庫，相反，它依賴HBase作為其數據存儲層，因此OpenTSDB時序守護進程(OpenTSDB中的TSD用語)在實例之間沒有共享狀態可以高效地提供查詢引擎的功能。
OpenTSDB允許通過其API進行簡單的聚合和數學運算，但沒有完整的查詢語言。OpenTSDB支持毫秒的分辨率，但隨著亞毫秒級操作的普及，OpenTSDB有時會出現精度不足的問題。
相比OpenTSDB，InfluxDB的性能和成本優勢明顯，InfluxDB的寫性能大約是OpenTSDB的5倍，存儲效率大約是OpenTSDB的16.5倍，查詢效率大約是OpenTSDB的3.65倍。
另外，OpenTSDB的設計初衷主要是用于生成儀表板圖，不是為了滿足任意查詢，也不是為了存儲數據。這些限制會影響它的使用方式。
03 InfluxDB的特性
作為一個開源系統，InfluxDB究竟有什么魅力吸引了如此多的用戶，從而在時序型數據庫DB-Engines Ranking上排名第一呢？
1. InfluxDB的特點
InfluxDB是支持時序數據高效讀寫、壓縮存儲、實時計算能力的數據庫服務，除了具有成本優勢的高性能讀、高性能寫、高存儲率，InfluxDB還具有如下特點：
- 無系統環境依賴，部署方便。
- 無模式(schema-less)的數據模型，靈活強大。
- 原生HTTP管理接口，免插件配置和免第三方依賴。
- 強大的類SQL查詢語句，學習成本低，上手快。
- 豐富的權限管理功能：精細到“表”級別。
- 豐富的時效管理功能：自動刪除過期數據，自定義刪除指標數據。
- 低成本存儲，采樣時序數據，壓縮存儲。
- 豐富的聚合函數，支持AVG、SUM、MAX、MIN等聚合函數。
2. 核心概念
InfluxDB實現了類SQL的接口，盡管與傳統關系型數據庫(如MySQL)語法相似，但InfluxDB在語義體系上有些差別，接下來將以一條CPU利用率的時序數據為例介紹相關的核心概念，如代碼清單1-3所示。
- 代碼清單1-3 一條CPU利率的時序數據
- 時間(Time)：如代碼清單1-3中的“1557834774258860710”，表示數據生成時的時間戳，與MySQL不同的是，在InfluxDB中，時間幾乎可以看作主鍵的代名詞。
- 表(Measurement)：如代碼清單1-3中的“cpu_usage”，表示一組有關聯的時序數據，類似于MySQL中表(Table)的概念。
- 標簽(Tag)：如代碼清單1-3中的“host=server01”和“location=cn-sz”，用于創建索引，提升查詢性能，一般存放的是標示數據點來源的屬性信息，在代碼清單1-3中，host和location分別是表中的兩個標簽鍵，對應的標簽值分別為server01和cn-sz。
- 指標(Field)：如代碼清單1-3中的“user=23.0”和“system=57.0”，一般存放的是具體的時序數據，即隨著時間戳的變化而變化的數據，與標簽不同的是，未對指標數據創建索引，在代碼清單1-3中，user和system分別是表中的兩個指標鍵，對應的指標值分別為23.0和57.0。
- 時序數據記錄(Point)：如代碼清單1-3中的“1557834774258860710 server01 cn-sz 55 25”，表示一條具體的時序數據記錄，由時序(Series)和時間戳(Timestamp)唯一標識，類似于MySQL中的一行記錄。
- 保留策略(Retention Policy)：定義InfluxDB的數據保留時長和數據存儲的副本數，通過設置合理的保存時間(Duration) 和副本數(Replication)，在提升數據存儲可用性的同時，避免數據爆炸。
- 時間序列線(Series)：表示表名、保留策略、標簽集都相同的一組數據。
關于作者：韓健，資深架構師，現就職于騰訊，擔任監控大數據平臺技術負責人，曾先后擔任創業公司CTO、Intel資深工程師。既對分布式系統、InfluxDB的架構設計和開發有深刻的理解，又在海量服務分布式組件架構設計、高性能架構設計、高質量代碼編寫等方面有深厚的積累，經驗豐富。
本文摘編自《InfluxDB原理與實戰》，經出版方授權發布。
延伸閱讀《InfluxDB原理與實戰》
推薦語：InfluxDB技術專家基于DB-Engines排名TOP的時序數據庫，打造千億級大數據監控平臺經驗總結。包含9個企業級案例，100余示例，300余條命令和語法。
總結
以上是生活随笔為你收集整理的influxdb数据过期_为什么腾讯QQ的大数据平台选择了InfluxDB数据库？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 多层数组如何遍历_带你从零学大数据系列之
- 下一篇： Linux系统中read的用法,Linu