數十年來，時間序列資料庫（TSDB）的使用在各個行業中都很普遍，特别是在金融和工業控制系統中。然而，物聯網 (IoT) 的出現導緻時間序列資料（簡稱時序資料）量激增，對資料庫的性能和存儲成本提出了更高的要求，進而促進了對專用時序資料庫的需求。
面對遺留時序解決方案的架構過時、擴充性有限等問題，新一代時序資料庫應運而生，它們采用了現代架構，可實作分布式處理和水準擴充，以及雲或本地的靈活部署。
2022 年底，又一重磅産品加入了開源時序資料庫這一賽道，并在短短一年内在 60 餘家企業測試和生産落地，吸引了 70 + 來自國内外重點高校和企業的貢獻者 ——openGemini，華為開源的分布式時序資料庫，主要聚焦于海量時序資料的存儲和分析，通過技術創新，簡化業務系統架構，降低海量時序資料的存儲成本，提升時序資料的存儲和分析效率。
今天，我們邀請到了 openGemini 社群負責人向宇，一起來聊聊，他們的開源故事～
01 源自内部需求，逐漸走向自研
openGemini 的研發，最開始也是源于華為自身的需求。
2019 年，随着華為雲的成立，廣州、上海、北京、貴州和香港等地的資料中心紛紛拔地而起，并陸續上線了 260 + 雲服務，平均每天采集的監控名額資料達數 TB，原有大資料解決方案逐漸不堪重負。資料量越大，查詢效率越低，資料存儲成本持續上升，急需一款高性能、高擴充性的專用時序資料庫。
在當時，并沒有什麼好用的、能跟得上需求發展的時序資料庫産品。InfluxDB 還是單機版，國内 Apache IoTDB 和 TDengine 還遠不能達到生産要求。是以，華為決心做自己的資料庫，優化資料處理工作，解決眼下十分要緊的業務問題。在這樣的背景下，openGemini 應運而生。
據向宇介紹，在技術選型上，他們一開始在開源 InfluxDB 的基礎上進行叢集化改造。但随着名額數量的增加和采集頻率的提高，日增資料量已達數十 TB。這時，InfluxDB 自身架構的缺陷開始凸顯，影響到系統的性能和穩定性。于是，他們選擇了對架構進行重構，開始了 openGemini 核心的自研之路。
02 個性獨特，性能搶跑
openGemini 自誕生起就跟華為自家業務的需求聯系緊密，是以每一個設計都充滿了實用的考量。具體來說，openGemini 差別于别的時序資料庫，主要有 9 大 “個性”：
性能優勢：在 openGemini 差異化競争力中，高性能是最重要的一項。在海量資料場景下，openGemini 相比開源 InfluxDB，簡單查詢場景提升 2 倍多，中等查詢場景提升 5 倍多，複雜查詢場景提升 10 倍以上。相比其他同類開源産品，openGemini 同樣具有明顯性能優勢。
官方公布的單機寫性能如下（測試工具為 TSBS，相關測試細節請參考 openGemini 官網文檔）：
官方公布的 DevOps 場景下單機查詢性能對比（平均時延，ms）：
官方公布的 IoT 場景下單機查詢性能對比（平均時延，ms）：
除此之外，openGemini 在資料存儲和資料分析方面推出一系列實用功能，以此建構更多差異化競争力：
獨特的分布式架構：openGemini 提供了單機和分布式叢集兩種版本，其中分布式叢集采用的是 MPP 大規模并行處理分層架構，将計算引擎，存儲引擎和中繼資料管理劃分為獨立的元件，分别是 ts-sql、ts-store、ts-meta 。不同元件支援獨立橫向擴充，使得面對複雜的應用場景也能靈活應對。
高基數引擎：高基數問題（也稱之為次元災難）會帶來反向索引膨脹，進而引起記憶體資源消耗過高、讀寫性能降低的問題，長期以來一直困擾着時序資料庫的發展。openGemini 高基數引擎通過建構時序專用的稀疏索引，進而徹底解決了這一難題，非常适合在網絡監控、金融風控、物聯網、交通等領域使用。
文字檢索：文本資料是一種常見的資料類型，openGemini 支援在文本資料之上建立索引，采用動态的學習型分詞方法，支援精确、短語和模糊比對，且具有記憶體資源占用少，檢索效率高的優點。
流式聚合：流式聚合是一種前置聚合方式，一邊寫資料、一邊對資料進行降采樣，其目的是解決傳統降采樣方法從磁盤讀取大量曆史資料進行計算，造成 I/O 放大嚴重的問題。
多級降采樣：對于存量的曆史資料，傳統降采樣方式會保留曆史資料明細。在某些場景下，曆史資料明細并不重要，隻需保留資料特征即可，多級降采樣功能可以實作對曆史資料明細的特征提取，并原地替換曆史資料明細，可進一步降低 50% 的存儲成本。
異常檢測和預測：異常檢測和預測是目前時序資料分析最成熟的應用之一，被廣泛應用于量化交易、網絡安全檢測和資料中心、工業裝置和 IT 基礎設施的日常維護等場景中。openGemini 提供了一個異常檢測庫 ——openGemini-castor，封裝了常見的 13 種異常場景的檢測算法，具有檢測速度快、準确性高、流批一體的優點，幫助應用提高資料分析效率。
資料冷熱分層存儲：支援将曆史資料轉存到對象存儲上，可實作低成本方式本永久保留曆史資料，還能支援大資料離線分析。【該功能計劃 H2 對外釋出】
資料可靠性：支援多計算副本，進一步提升資料可靠性。【該功能計劃 H2 對外釋出】
03 注重使用體驗，入門更友善
openGemini 不僅性能夠強，它獨特的設計，在實際的應用中，還能帶來很多舒适的體驗：
在入門方面，openGemini 與 InfluxDB v1.x 的生态完全相容，接口、生态工具等直接通用，InfluxDB 使用者可以無障礙遷移。同時，openGemini 采用了跟 InfluxDB 一樣的 Line Protocol，資料模組化簡單，且容易了解，對關系型資料庫的開發者也很友好。最後，openGemini 使用類 SQL 查詢語言，無需額外學習，上手容易。叢集部署上，社群還提供了一鍵部署工具 Gemix，省去了大量的配置工作。
在作業系統方面，openGemini 目前已支援主流 Linux 系統（含 openEuler）、Windows 和 MacOS，應用開發調試更加友善。處理器支援 X86 和 ARM64 兩種架構。
在雲原生方面，openGemini 提供了 Dockerfile 和 Docker 鏡像，支援 Docker、K8s、KubeEdge 等平台的部署。由于容器重新拉起後，IP 位址随之變化，openGemini 新增域名功能，確定叢集節點在容器重新開機後依然可以保持連通。社群還建立了 openGemini-operator 項目，友善使用者一鍵式容器化部署。openGemini 支援普羅米修斯遠端讀寫，可以作為普羅米修斯的一個後端存儲，解決它存儲能力不足的問題。【btw：openGemini 還将直接支援 PromQL，目前正在開發中】
在可觀測性方面，社群開發了 ts-monitor 元件，專門采集節點和核心名額，分為 19 個子類，260 餘項，可搭配 Grafana 實作對 openGemini 運作狀态的全面監控。例如 CPU 和記憶體使用率、寫入帶寬、寫時延、寫并發、QPS 等名額可以通過可視化界面一目了然，友善随時檢視運作狀況、資料庫性能調優和精準定位問題。
04 經過内部實戰考驗，回饋開源
openGemini 作為時序資料庫，目前最常見的使用場景就是物聯網和運維監控，在處理海量資料這方面，有着普通資料庫無法比拟的優勢。同時，openGemini 作為華為内部的項目，已經經過了 “自家人” 的考驗：
華為雲 SRE 使用 openGemini 作為監控資料存儲底座，全網共部署 25 套叢集，最大叢集規模 70 個節點，成功經受住了每秒 4 千萬條資料寫入和 5 萬次的并發查詢的實戰考驗。相比原有解決方案，在承載相同業務的情況下，較原系統端到端時延降低 50%，CPU 資源上可以節省 68%，記憶體資源可以節省 50%，硬碟資源可以節省 90% 以上。
華為雲的工業物聯平台，之前一直用的 InfluxDB 的單機版，自從切換到 openGemini 上來後，再也不用被吞吐量困擾了，端到端和查詢性能提升了 3 倍，裝置接入量提升到了百萬級。
向宇介紹，openGemini 源自開源，從 InfluxDB 開源項目中受益良多，是以秉承開源的精神，将 openGemini 的全部代碼開源，希望全球更多的企業和開發者從中獲益，也希望通過開放的社群平台，和廣大開發者一起，共同推動技術創新，共享開源成果。
目前，openGemini 隻有開源版和雲服務，并不打算涉足線下商業版本，且有意願向基金會捐獻。當下，社群尚有諸多未完善之處，接下來，社群将會進一步豐富 openGemini 的生态工具（諸如資料遷移工具、SDK、大資料生态內建等）、可視化管理界面、以及文檔等等。
“目前，社群的技術規劃總體上會圍繞物聯網、運維監控和可觀測性這三個重要應用場景，加強相關技術生态相容和核心能力建設，我們正在着手論證 openGemini 下一代的軟體架構。” 向宇說。
“短時間内，openGemini 不會考慮工業相關場景，因為工業領域的業務場景非常複雜，實時性要求極高，工業軟體廠商的護城河很深，時序資料庫能做的事情有限。此外，社群缺乏行業背景，對這方面的場景還不夠了解。之後，我們會考慮尋找一些工業領域的夥伴，比方說工業軟體供應商、解決方案提供商等，一起去合作、完善。” 向宇說。
openGemini 官網首頁:
https://www.openGemini.org/
openGemini 開源位址:
https://github.com/openGemini