從前世今生聊一聊，大廠為啥親睞時序資料庫
摘要：本文會從時序資料庫的基本概念、應用場景、需求與能力等方面一一展開，帶你瞭解時序資料庫的前世今生。
時序資料庫忽然火了起來。Facebook開源了beringei時序資料庫，基於PostgreSQL打造的時序資料庫TimeScaleDB也開源了。時序資料庫作為物聯網方向一個非常重要的服務，業界的頻頻發聲，正說明各家企業已經迫不及待的擁抱物聯網時代的到來。
本文會從時序資料庫的基本概念、應用場景、需求與能力等方面一一展開，帶你瞭解時序資料庫的前世今生。
應用場景
時序資料庫是一種針對時序資料高度優化的垂直型資料庫。在製造業、銀行金融、DevOps、社交媒體、衛生保健、智慧家居、網路等行業都有大量適合時序資料庫的應用場景：
- 製造業：比如輕量化的生產管理雲平臺，運用物聯網和大資料技術，採集、分析生產過程產生的各類時序資料，實時呈現生產現場的生產進度、目標達成狀況，以及人、機、料的利用狀況，讓生產現場完全透明，提高生產效率。
- 銀行金融：傳統證券、新興的加密數字貨幣的交易系統，採集、分析交易過程中產生的時序資料，實現金融量化交易。
- DevOps：IT基礎設施和應用的運維繫統，採集、分析裝置執行和應用服務執行監控指標，實時掌握裝置和應用的健康狀態。
- 社交媒體：社交APP大資料平臺，跟蹤使用者互動資料，分析使用者習慣、改善使用者體驗；直播系統，採集直播過程中包括主播、觀眾以及中間各環節的監控指標資料，監控直播質量。
- 衛生保健：商業智慧工具，採集智慧手錶，智慧手環中的健康資料，跟蹤關鍵指標和業務的總體健康情況
- 智慧家居：居家物聯網平臺，採集家居智慧裝置資料，實現遠端監控。
- 網路：網路監控系統，實時呈現網路延時、頻寬使用情況。
時序資料的需求
在上述場景中，特別在IoT物聯網以及OPS運維監控領域，存在海量的監控資料需要儲存管理。以華為雲Cloud Eye Service(CES)服務為例，單個Region需要監控7000多萬個監控指標，每秒需要處理90萬個上報的監控指標項，假設每個指標50個位元組，一年的監控資料有1PB；自動駕駛的車輛一天各種感測器監測資料就80G。
傳統關係型資料庫很難支撐這麼大的資料量以及這麼大的寫入壓力，Hadoop大資料解決方案以及現有的時序資料庫也會面臨非常大的挑戰。大規模IoT物聯網，以及公有云規模的運維監控場景，對時序資料庫的需求主要包括：
- 持續高效能寫入：監控指標往往以固定的頻率採集，部分工業物聯網場景感測器的採集頻率非常高，有的已經達到100ns，公有云運維監控場景基本也是秒級採集。時序資料庫需要支援7*24小時不中斷的持續高壓力寫入。
- 高效能查詢：時序資料庫的價值在於資料分析，而且有較高的實時性要求，典型分析任務如異常檢測及預測性維護，這類時序分析任務需要頻繁的從資料庫中獲取大量時序資料，為了保證分析的實時性，時序資料庫需要能快速響應海量資料查詢請求。
- 低儲存成本：IoT物聯網及運維監控場景的資料量曾現指數級增長，資料量是典型的OLTP資料庫場景的千倍以上，並且對成本非常敏感，需要提供低成本的儲存方案。
- 支援海量時間線：在大規模IoT物聯網及公有云規模的運維場景，需要監控的指標通常在千萬級甚至億級，時序資料庫要能支援億級時間線的管理能力。
- 彈性：監控場景也存在業務突發增長的場景，例如：華為Welink服務的運維監控資料在疫情期間暴增100倍，時序資料庫需要提供足夠靈敏的彈性伸縮能力，能夠快速擴容以應對突發的業務增長。
開源時序資料庫能力
過去10年，隨著移動網際網路、大資料、人工智慧、物聯網、機器學習等相關技術的快速應用和發展，湧現出許多時序資料庫，因為不同資料庫採用的技術和設計初衷不一樣，所以在解決上述時序資料需求上，他們之間也表現出現較大的差異，本文在下面內容將選擇使用最多的幾種開源時序資料庫為分析物件進行討論。
- OpenTSDB
OpenTSDB基於Hbase資料庫作為底層儲存，向上封裝自己的邏輯層和對外介面層。這種架構可以充分利用Hbase的特性實現了資料的高可用和較好的寫入效能。但相比Influxdb，OpenTSDB資料棧較長，在讀寫效能和資料壓縮方面都還有進一步優化的空間。
- InfluxDB
Influxdb是業界比較流行的一個時間序列資料庫，它擁有自研的資料儲存引擎，引入倒排索引增強了多維條件查詢的功能，非常適合在時序業務場景中使用。由於時序洞察報表和時序資料聚合分析，是時序資料庫主要的查詢應用場景，每次查詢可能需要處理上億資料的分組聚合運算，所以在這方面，InfluxDB採用的火山模型對聚合查詢效能影響較大。
- Timescale
TimeScale是一個基於傳統關係型資料庫postgresql改造的時間序列資料庫，繼承了postgresql許多優點，比如支援SQL，支援軌跡資料儲存，支援join，可擴充套件等等，讀寫效能好。TimeScale採用固定schema，資料佔用空間大，對於時序業務長期相對固定且對資料儲存成本不敏感的業務來說，也是一種選擇。
GaussDB（For Influx）的出現
針對高效能寫入、海量時間線和高資料壓縮的需求，當前還未能有比較好的開源解決方案。GaussDB（For Influx）汲取了開源各家之長，設計了雲原生架構的時序資料庫。架構如下圖所示。
相比現有的開源時序資料庫，架構設計上有以下兩方面的考慮：
- 儲存與計算分離
儲存計算分離，一方面利用成熟的分散式儲存系統提高系統的可靠性。監控資料一直持續高效能寫入，同時還有大量的查詢業務，任何系統故障導致業務中斷甚至資料丟失都會造成嚴重的業務影響，而利用經過驗證的成熟的分散式儲存系統，能夠顯著的提升系統可靠性，降低資料丟失風險，並明顯縮短構建本系統的時間。
另一方面，解除在傳統Share Nothing架構下，資料和節點物理繫結的約束，資料只是邏輯上歸宿於某個計算節點，使得計算節點無狀態化。這樣在擴容計算節點時，可以避免在計算節點間遷移大量的資料，只需要邏輯上將部分資料從一個節點移交給另外一個節點即可，可以將叢集擴容的耗時從以天為單位縮短為分鐘級別。
再一方面，通過將多副本複製從計算節點解除安裝到分散式儲存節點，可以避免使用者以Cloud Hosting形態在雲上自建資料庫時，分散式資料庫和分散式儲存分別做3副本複製導致總共9副本冗餘的問題，能夠顯著降低儲存成本。
- Kernel Bypass
為了避免在使用者態核心態來回拷貝資料帶來的效能損失，GaussDB（for Influx）系統端到端考慮Kernel bypass設計，沒有選擇使用標準的分散式塊或分散式檔案服務，而是定製的針對資料庫設計的分散式儲存，對外暴露使用者態介面，計算節點採用容器化部署，通過專用儲存網路直接和儲存節點通訊
除了架構之外，GaussDB（for Influx）還針對IoT物聯網及運維監控場景的其他需求做了如下優化：
- 寫優化的LSM-Tree佈局和非同步Logging方案，相比當前時序資料庫提升94%寫效能。
- 通過向量化查詢引擎，ARC Block Cache，以及Aggregation Result Cache提升聚合查詢效能，相比當前時序資料庫提升最高可達9倍
- 設計針對時序資料分佈特徵的壓縮演算法，壓縮率相比Gorilla提升2倍，並自動將冷資料分級到物件儲存，降低60%儲存成本
- 優化海量時間線的索引演算法，提升索引效率，在千萬時間線量級下，寫入效能是當前時序資料庫的5倍。
GaussDB（for Influx）成功保障了公司welink和雲監控CES兩大服務之後上線商用，接下來我們還將探索如何在海量資料中尋找有價值資料的高效分析方法，為使用者提供更加合適的分析和洞察能力。
參考文獻
https://zhuanlan.zhihu.com/p/32709932
https://www.cnblogs.com/jpfss/p/12183214.html
點選關注，第一時間瞭解華為雲新鮮技