300億條時序數據：金倉時序能力在工業場景的實測

　　工業場景里的數據增長，很多時候不是"更多行"，而是"更多秒"。

　　物聯網設備每秒都在上報，傳感器以毫秒級頻率采集，監控探頭全年無休。智能工廠的設備狀態、智慧城市的交通流量、新能源風機的運行指標，這些數據的時間戳是核心維度，丟了一秒，分析就缺了一塊。

　　金倉數據庫用時序加空間雙引擎來做工業級時序數據處理。這個方案有意思的地方在于，它沒有像 InfluxDB 那樣做一個獨立的專用數據庫，而是把時序能力做進了關系型數據庫內核。為什么要走這條路，下面會展開。

　　每秒都在寫入，從不休息

　　工業時序數據有幾個很明顯的特征，理解這些特征，才能理解為什么處理它的方式需要專門的設計。

　　第一個是高頻寫入。傳感器秒級甚至毫秒級持續上報，日均幾十億到幾百億條數據。這種寫入壓力是持續性的，不存在"高峰期過了就好"的說法，因為設備不會下班。

　　第二個是海量存儲。設備數量多、指標維度豐富，數據量從 TB 級一路漲到 PB 級。而且這些數據的價值密度極低，大部分數據寫入之后你可能永遠不看，但你無法預知哪一秒的數據將來會變得關鍵。出了事故要查三個月前的某個傳感器讀數？你必須存著。

　　第三個是查詢復雜度跨度極大。從"最近五分鐘的溫度"這種毫秒級點查，到"過去一年里每臺設備在特定工況下運行了多少小時"這種跨年度聚合分析，同一套系統要應付完全不同的查詢模式。

　　第四個是實時響應的剛性需求。告警觸發這種事，差幾秒鐘可能就不是"警告"而是"事故"了。這意味著數據從寫入到能被查詢到之間的延遲必須極短。

　　第五個是冷熱分明。最近的數據頻繁訪問，三個月前的數據偶爾看一眼，兩年前的數據基本不動。但你不能刪，合規要求往往規定數據必須保留五年以上。

　　從湊合用，到專用工具，再到融合方案

　　有了這些特征，再看時序數據處理技術的發展脈絡，邏輯就清晰了。

　　第一階段是湊合著用。在關系型數據庫上加自定義表結構，把時間戳當索引。能跑，但寫入慢、查詢慢、存儲成本高。這是不得已的辦法。

　　第二階段是專用工具。InfluxDB 這類專用時序數據庫的出現，解決了寫入慢的問題，簡單查詢也變快了。但這個方案有一個結構性缺陷，它把時序數據和業務數據的生態割裂了。舉一個具體的例子：你想查"上個月銷售額最高的五家門店里，哪臺設備的故障率最高"。銷售額在業務數據庫里，設備故障數據在時序數據庫里，你得先在一個庫查出門店排名，再把結果帶到另一個庫里做篩選。兩套系統，兩套查詢語言，兩組維護人員。

　　第三階段是融合方案，也就是金倉走的路。金倉 KES 直接把時序能力做進了關系型數據庫內核。時序數據、空間數據、業務數據在同一個庫里，用同一種 SQL 查詢。這個架構選擇的核心邏輯是：時序數據從來不是孤立存在的，它總要跟設備信息關聯，跟地理位置關聯，跟業務記錄關聯。與其建兩套系統來回拼接，不如用一套系統統一處理。

　　時序加空間，一個庫兩種能力

　　金倉時序能力的底層是雙引擎架構：時序引擎和空間引擎運行在同一個 KES 數據庫內，上面再加一個關系引擎做底座，最底層是統一 SQL 查詢引擎。

　　時序引擎負責高速寫入、時間聚合和數據壓縮。它支持千萬級設備持續高并發寫入，內置時間窗口聚合函數，基于自動化數據分區（Chunk）做高壓縮比存儲。

　　空間引擎負責 GIS 查詢、空間索引和坐標轉換。它和時序引擎的聯動是這個架構最獨特的地方，你可以在一條 SQL 里同時查詢"某個時間段內"和"某個空間區域內"的數據。比如"查過去一周在機場周邊特定區域頻繁出現的車輛"，在傳統架構里需要時序數據庫和空間數據庫分兩次查詢再拼結果，在這里就是一條 SQL。

　　關系引擎提供 ACID 事務、復雜關聯和存儲過程能力。這是金倉的底座，它保證了時序數據也有事務保障，也可以跟業務表做 JOIN。

　　最底層的統一 SQL 查詢引擎意味著開發者不需要學新語言。不管是時序查詢、空間查詢還是關系查詢，用的都是標準 SQL。

　　設備越多，差距越大

　　架構說清楚了，來看實測。

　　用業界公認的時序基準測試套件 TSBS，金倉和 InfluxDB 做了一組從 100 臺到 1000 萬臺設備的對比。結果很有意思，設備數量越大，差距越大。

　　寫入性能方面，100 臺設備時兩者互有優劣，可以認為在一個水平線上。400 臺設備、每臺 10 指標時，金倉的寫入吞吐達到 InfluxDB 的 162%。到了 1000 萬臺設備的極限壓力下，金倉達到 267%。

　　背后的原因不復雜：InfluxDB 在單機架構下，寫入路徑在數據量大到一定程度后會遇到瓶頸；而金倉可以把寫入壓力分攤到多個節點上，規模越大，分攤效果越明顯。

　　查詢性能的差距更大。簡單聚合查詢，單設備、單指標、短時間窗口，兩者都在毫秒級，差不多。到了中等復雜度，多指標聚合、跨設備分組，金倉可達 InfluxDB 的 3-4 倍。到了高復雜度關聯分析，差距以數量級計算。

　　一個最具代表性的場景：查詢某個時間段內每臺設備的最后一次讀數，400 臺設備的數據。金倉用了 147.36 毫秒，InfluxDB 用了 10514.64 毫秒。差了超過 70 倍。

　　這個差距不是因為金倉在查詢優化上特別出色，雖然優化確實做得不錯，而是因為 InfluxDB 的架構在這個類型的查詢上有本質性的短板。專用時序數據庫的設計取舍是把寫入和簡單點查做到極致，代價就是復雜查詢的能力弱。這不是調參數能解決的，是架構級的取舍。

　　跑分之外的三件事

　　跑分重要，但不是全部。企業在生產環境里要考慮的因素比純性能更多。

　　第一件事是 SQL 生態。金倉基于關系型數據庫內核，完整支持存儲過程、ACID 事務、多表關聯查詢。團隊已有的 SQL 分析工具可以直接用，不需要學新的查詢語言。對于已經在關系型數據庫上投了大量時間和技能的團隊來說，這個兼容性意味著遷移的學習成本幾乎為零。

　　第二件事是存儲成本。金倉提供了基于時間的自動化數據分區和保留策略。冷數據經過高壓縮比存儲，實測能達到 1:4 的壓縮比，100TB 數據實際只占 25TB 磁盤。冷熱分級意味著熱數據走高性能存儲保證響應速度，冷數據走高壓縮歸檔降低存儲成本，兩邊都能兼顧。

　　第三件事是多模融合。時序數據、GIS 空間數據、JSON 文檔數據在同一個庫里直接關聯查詢，不需要跨系統 JOIN。這在工業場景里的價值特別大，一臺設備的運行狀態是時序數據，它的地理位置是空間數據，它的規格參數是文檔數據，三者本來就應該在同一個查詢里出現。

　　從港口到風機，四個真實場景

　　從架構回到實踐，以下案例能看出時序能力在不同場景下的表現。

　　泰興交通用金倉給港口做管理系統。在這個項目里，時序數據是集卡和拖車的秒級 GPS 軌跡數據，空間數據是港口地理圍欄和航道信息。兩者合在一起，可以做"過去一小時內哪些車駛入過禁行區域"這種時空聯合查詢。日均幾十億條數據寫入，查詢響應速度一直穩定。

　　新能源領域的案例更能說明時序和業務的融合需求。某企業上千臺風機的運行狀態被持續監測，每秒數十萬點傳感器數據寫入。運營團隊需要查的不是單獨的溫度或轉速，而是"這臺風機當前的狀態，跟它同型號的另一臺比有什么差異"，這需要把傳感器的時序數據跟設備元數據放在一起做關聯查詢。金倉在這種復雜分析查詢上的性能達到了 InfluxDB 的 2 到 70 倍，而且憑借更高的數據壓縮比，存儲成本預計節省超過百萬元。

　　寫在最后

　　時序數據庫的選型，底色是"專用"和"通用"之間的權衡。

　　InfluxDB 這類專用數據庫在簡單場景下表現很好，寫入快，點查快，部署簡單。但它快的代價是生態割裂：復雜查詢慢，事務不支持，需要跟業務數據庫分開維護。當業務規模小、查詢模式簡單的時候，這個代價可以接受。但當業務開始需要把時序數據跟設備信息、地理位置、業務記錄關聯分析的時候，割裂的成本就急劇上升了。

　　金倉把時序能力做進關系型數據庫內核，走的是另一條路，用通用數據庫的內核能力去覆蓋專用場景。優勢很明顯：不需要另外學技術棧，不需要跨系統拼接查詢結果，已有的 SQL 工具和技能可以繼續用。

　　對工業場景來說，這個權衡的方向通常是明確的。因為工業里的時序數據從來不是孤立存在的，它總要跟設備信息關聯，跟地理位置關聯，跟業務記錄關聯。這些關聯分析的能力，恰恰是通用數據庫的長處。

　　轉自：天極網

　　【版權及免責聲明】凡本網所屬版權作品，轉載時須獲得授權并注明來源“中國產業經濟信息網”，違者本網將保留追究其相關法律責任的權力。凡轉載文章及企業宣傳資訊，僅代表作者個人觀點，不代表本網觀點和立場。版權事宜請聯系：010-65363056。

延伸閱讀