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