01 選型背景
我公司致力于儲能業(yè)務(wù)的開發(fā)，包括對龐大而復(fù)雜的儲能裝置進行設(shè)計、制造和管理。
在生產(chǎn)安全的重任下，我們需要實時監(jiān)測電池的每一次充放電過程、電流、電壓等值，以保障電池安全，而每一個變化的數(shù)據(jù)就是一個帶有時間戳的時序數(shù)據(jù)。
大型儲能裝置十分復(fù)雜，伴隨著業(yè)務(wù)的擴展，我們的設(shè)備和測點數(shù)量不斷激增，數(shù)據(jù)采集的頻率也在不斷提高。
面對海量的時序數(shù)據(jù)，傳統(tǒng)的處理方案顯得力不從心，成本高昂且效率低下。因此，我們需要一款高性能的時序數(shù)據(jù)庫，實現(xiàn)數(shù)據(jù)的高效處理和實時分析。
經(jīng)過深入的調(diào)研之后，我們在 InfluxDB 和 IoTDB 之間選擇了 IoTDB 作為儲能業(yè)務(wù)線的時序數(shù)據(jù)庫。
IoTDB 1.0 版本后支持了分布式部署，其數(shù)據(jù)分區(qū)存儲的高可擴展性，以及多副本存儲實現(xiàn)了無單點故障的高可用性，都深深吸引了我們。
而且，IoTDB 搭配了多種一致性協(xié)議，能夠適配不同的場景，這種易于橫向擴展的系統(tǒng)架構(gòu)，完美匹配了我們業(yè)務(wù)的發(fā)展趨勢。
02 部署架構(gòu)
考慮到將 IoTDB 部署在物理服務(wù)器上，通過公網(wǎng)進行業(yè)務(wù)應(yīng)用交互可能會帶來數(shù)據(jù)延遲和運維成本問題，并且需要從頭規(guī)劃計算、存儲以及監(jiān)控系統(tǒng)，整個過程耗時漫長，不利于項目推進。
最終，我們決定直接在業(yè)務(wù)應(yīng)用的 K8S 環(huán)境上部署 IoTDB，實現(xiàn)云上集成應(yīng)用。這樣不僅可以提高運維的一致性，也充分利用了云環(huán)境的彈性。
部署 IoTDB 后的業(yè)務(wù)架構(gòu)是這樣的：在儲能設(shè)備端，電池簇持續(xù)實時上報增量時序數(shù)據(jù)，并每隔 5 秒上報一次超過 10 萬指標(biāo)的全量時序數(shù)據(jù)。
這些數(shù)據(jù)通過站端轉(zhuǎn)發(fā)服務(wù)器，使用 MQTT 協(xié)議傳輸至云端，經(jīng)過 EMQX 的數(shù)據(jù)轉(zhuǎn)換后，存儲至阿里云環(huán)境中部署的 IoTDB 數(shù)據(jù)庫，并進一步進行數(shù)據(jù)的查詢、計算與分析。
IoTDB 新穎的分布式架構(gòu)和高可用模式，為我們提供了強有力的數(shù)據(jù)存儲保障，因此目前我們采用了 3C3D 的高性能分布式架構(gòu)。
對于整體存儲空間，IoTDB 支持使用公有云的 SSD 云盤隨時擴容，DataNode 節(jié)點容量也可以通過 scale StatefulSet 工作負(fù)載進行擴容，為我們的業(yè)務(wù)架構(gòu)提供了非常高的靈活性。
為滿足實時監(jiān)控處理需求，我們利用了 IoTDB 內(nèi)置的 Prometheus Exporter，快速接入監(jiān)控，實時了解集群狀態(tài)，為性能優(yōu)化指明方向。
在數(shù)據(jù)備份方面，我們采用了 Velero 對 IoTDB 相關(guān)負(fù)載進行備份，數(shù)據(jù)可以直接備份到 OSS 上，也可以通過 crontab 定時備份，并使用 velero hook annotation 在備份前進行強制 flush 刷盤，以保障備份過程中的數(shù)據(jù)完整性。
值得一提的是，在部署落地的過程中，IoTDB 的用戶文檔描述清晰，運維簡便，上手成本低，大大方便了我們運維人員的部署工作。
并且，我們深深感受到 IoTDB 背后有一群熱愛研發(fā)的程序員，他們的運維支持穩(wěn)定可靠、響應(yīng)積極快速，我們生產(chǎn)中遇到的問題能夠在很短時間內(nèi)獲得很多實質(zhì)性的幫助，因此我們對于 IoTDB 產(chǎn)品和團隊是非常信任的。
我們的 IoTDB 集群配置如下：
使用的 IoTDB 數(shù)據(jù)備份腳本如下：
03 應(yīng)用效果
以下舉例兩個 IoTDB 在我們的儲能業(yè)務(wù)中的實際應(yīng)用場景：
業(yè)務(wù)場景一：在某大型儲能業(yè)務(wù)中，IoTDB 共監(jiān)測 150 個設(shè)備，10000 測點，1 秒采集一次上報的時序數(shù)據(jù)。其集群寫入性能穩(wěn)定實現(xiàn)千萬級吞吐，并發(fā) 10 個聚合查詢場景，平均耗時都在 1 秒之內(nèi)，各項監(jiān)控指標(biāo)表現(xiàn)優(yōu)異，完全滿足我們的業(yè)務(wù)需求。
在該場景，我們使用 IoT-Benchmark 進行壓測的結(jié)果如下：
集群設(shè)置：
性能表現(xiàn)：
業(yè)務(wù)場景二：在某大型儲能業(yè)務(wù)中，IoTDB 共監(jiān)測 150 個設(shè)備，1 分鐘采集一次，連續(xù)上報 3 個月的時序數(shù)據(jù)，覆蓋測點數(shù)近 150 億個。IoTDB 的千萬級寫入性能完全滿足場景需要。在核心聚合查詢場景中，SQL 結(jié)果均在 1 秒內(nèi)返回，而對于如此數(shù)量的模型數(shù)據(jù)，關(guān)系型數(shù)據(jù)庫是不可能完成查詢的。
聚合查詢場景舉例如下：
04 未來展望
部署 IoTDB 后，我們不但可以很自豪地和客戶說：“我們使用的是國產(chǎn)時序數(shù)據(jù)庫。”而且這款國產(chǎn)時序數(shù)據(jù)庫還能夠真正高效地管理海量時序數(shù)據(jù)，有效提升數(shù)據(jù)的處理和實時分析能力，為公司儲能業(yè)務(wù)的電池安全監(jiān)控提供有力保障。
未來，我們希望抽象出一套 operator 來滿足各種不同架構(gòu)的 IoTDB 部署，同時實現(xiàn) K8S 環(huán)境的一鍵部署。我們也希望與 IoTDB 團隊繼續(xù)保持緊密合作，適配更大規(guī)模的數(shù)據(jù)體量，通過對更多時序數(shù)據(jù)的有效管理，進一步賦能我們儲能業(yè)務(wù)的發(fā)展。
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
