通用大數據架構爲何不適合處理物聯網數據?

爲處理日益增加的互聯網數據,衆多的工具開始出現,最流行的應該是 Hadoop 體系。除使用你們所熟悉的 Hadoop 組件如 HDFS,MapReduce, HBase, Hive 外,通用的大數據處理平臺每每還使用 Kafka 或其餘消息隊列工具,Redis 或其餘緩存軟件,Flink 或其餘實時流式數據處理軟件。存儲上也有人選用 MongoDB,Cassandra 或其餘 NoSQL 數據庫。這樣一個典型的大數據處理平臺基本上能很好的處理互聯網行業的引用,好比典型的用戶畫像、輿情分析等等。git

很天然,在物聯網、車聯網、工業互聯網起來後,你們都想到的是用通用的大數據處理平臺來處理它們的數據。如今市場上流行的物聯網、車聯網等大數據平臺幾乎無一例外是這類架構,這套方法證實徹底工做。但這套通用方法效果如何?能夠說有不少不足,主要表如今幾個方面。github

  • 開發效率低:由於不是單一軟件,須要集成至少 4 個以上模塊,並且不少模塊都不是標準的 POSIX 或 SQL 接口,都有本身的開發工具、開發語言、配置等等,須要必定的學習成本。並且因爲數據從一個模塊流動到另一個模塊,數據一致性容易受到破壞。同時,這些模塊基本上都是開源軟件,總會有各類 BUG,即便有技術論壇、社區的支持,一旦被一技術問題卡住,總要耗費工程師很多時間。總的來說,須要搭建一個還不錯的團隊才能將這些模塊順利的組裝起來,所以須要耗費較大的人力資源。
  • 運行效率低:現有的這些開源軟件主要是用來處理互聯網上非結構化的數據,可是物聯網採集的數據都是時序的、結構化的。用非結構化數據處理技術來處理結構化數據,不管是存儲仍是計算,消費的資源都大不少。舉個例子,智能電錶採集電流、電壓兩個量,用 HBase 或其餘 KV 型數據庫存儲的話,其中的 Row Key 每每是智能電錶的 ID,加上其餘靜態標籤值。每一個採集量的 key 由 Row Key,Column Family, Column Qualifier, 時間戳,鍵值類型等組成,而後緊跟具體的採集量的值。這樣存儲數據,overhead 很大,浪費存儲空間。並且若是要作計算的話,須要將具體採集量先解析出來。好比計算一段時間電壓的平均值,就須要先將電壓值從 KV 的存儲裏解析出來,放入一個數組,而後再進行計算。解析 KV 結構的 overhead 很大,致使計算的效率大幅下降。KV 型存儲的最大好處是 schemaless, 寫數據前不用定義數據結構,想怎麼記錄就能夠怎麼記錄,這對於幾乎天天都會更新的互聯網應用而言,是個很誘人的設計。可是對於物聯網、車聯網等應用而言,沒多少引人之處,由於物聯網設備產生的數據的 schema 通常是不變的,即便改變,頻次很低,由於相應的配置或固件須要更新才行。
  • 運維成本高:每一個模塊,不管是 Kafka, HBase, HDFS 仍是 Redis,都有本身的管理後臺,都須要單獨管理。在傳統的信息系統中,一個 DBA 只要學會管理 MySQL 或是 Oracle 就能夠了,但如今一個DBA須要學會管理、配置、優化不少模塊,工做量大了不少。並且因爲模塊數過多,定位一個問題變的更爲複雜。好比用戶發現有條採集的數據丟失,這丟失是 Kafka, HBase,Spark,仍是應用程序丟失?沒法迅速定位,每每須要花很長時間,找到方法將各模塊的日誌關聯起來才能找到緣由。並且模塊越多,系統總體的穩定性就越低。
  • 應用推出慢、利潤低:因爲研發效率低,運維成本高,致使產品推向市場的時間變長,讓企業喪失商機。並且這些開源軟件都在演化中,要同步使用最新的版本也須要耗費必定的人力。除互聯網頭部公司外,中小型公司在大數據平臺的人力資源成本通常都遠超過專業公司的產品或服務費用。
  • 對於小數據量場景,私有化部署過重:在物聯網、車聯網場景中,由於涉及到生產經營數據的安全,不少仍是採起私有化部署。而每一個私有化部署,處理的數據量有很大的區別,從幾百臺聯網設備到數千萬臺設備不等。對於數據量小的場景,通用的大數據解決方案就顯得過於臃腫,投入產出不成正比。所以有的平臺提供商每每有兩套方案,一套針對大數據場景,使用通用的大數據平臺,一套針對小數據規模場景,就使用 MySQL 或其餘 DB 來搞定一切。但這樣致使研發、維護成本提升。

通用大數據平臺有上述的問題,是否有好的辦法解決?那麼咱們須要針對物聯網的場景作細緻的分析。仔細研究會發現,全部機器、設備、傳感器產生的數據都是時序的,並且不少還帶有位置信息。這些數據具備明顯的特徵,1: 數據是時序的,必定帶有時間戳;2:數據是結構化的;3: 數據極少有更新或刪除操做;4:數據源是惟一的;5:相對互聯網應用,寫多讀少;6:用戶關注的是一段時間的趨勢,而不是某一特色時間點的值;7: 數據是有保留期限的;8:數據的查詢分析必定是基於時間段和地理區域的;9:除存儲查詢外,還每每須要各類統計和實時計算操做;10:流量平穩,能夠預測;11:每每須要有插值等一些特殊的計算;12:數據量巨大,一天採集的數據就能夠超過 100 億條。算法

若是咱們充分利用上述特徵,徹底能夠開發出一個特殊的針對物聯網場景進行優化的大數據平臺。這個平臺將具備以下特徵,1:充分利用物聯網的數據特色,在技術上作各類優化,大幅度提升數據插入、查詢的性能,下降硬件或雲服務成本;2:必須是水平擴展的,隨着數據量的增長,只須要增長服務器擴容便可;3:必須有單一的管理後臺,是易於維護的,儘可能作到零管理;4:必須是開放的,有業界流行的標準 SQL 接口,提供 Python、R 或其餘開發接口,方便集成各類機器學習、人工智能算法或其餘應用。數據庫

濤思數據的 TDengine 就是充分利用物聯網數據的 12 大特色而開發的全棧式的大數據處理引擎,具有上面所說的幾大特徵,有望解決通用大數據平臺在處理物聯網數據時的不足。按照濤思數據的設計思路,使用 TDengine,應能夠大幅簡化物聯網大數據平臺的架構,縮短研發週期,下降平臺運營費用。數組


目前,TDengine 已經在 GitHub 上開源,歡迎你們下載體驗,若有任何問題,均可以在 GitHub 上提出,咱們有專門的研發人員進行解答。緩存

相關文章
相關標籤/搜索