物聯網行業的基本系統架構

from: https://my.oschina.net/u/3374539/blog/3164203?from=20200209

 

 

1. 物聯網行業的基本系統架構，及使用數據庫遇到的需求與挑戰
2. IoTDB 的功能特點及系統架構

車聯網

因為本人是在做車聯網行業，所以對這個行業的信息了解更深入一些，能夠拿到一些更具體的數字來說明這個行業的具體情況。在上一篇文中的數據是出於自己的理解，為了讓大家容易明白而編造的數據，但實際情況要復雜的多。

1. 系統架構

1.1 系統簡介

 

以上示意圖可能非常簡單，但我覺得足夠表明一個整體架構。 當一台設備、一輛車連接到協議網關后，便開始了真正的收發數據。一般通信的方式都是基於 tcp，搞一段二進制協議，所以協議網關基本要做的工作就是完成對連接的管理、完成對數據的收發及編解碼。

當數據完成編解碼之后一般會發往消息隊列當中，一般都是 Kafka 之中。用來解耦生產和消費兩端，提供一層緩沖，無論消費服務是死是活還是速度慢，包治百病，甚至還能治未病。

數據發往消息隊列的過程中，或之后花活兒就多起來了。但主要的我認為無非還是三種處理方式：

1. 需要將原始數據保存入庫，這里的原始數據包含二進制數據和解碼后的二進制數據。
2. 流處理或批處理數據，在數據落到硬盤之前將能夠提前計算的數據全部預先計算出來，這樣做的好處是將來查詢的時候如果和預計算的模型匹配，那就能非常快的得到結果。
3. 離線處理，這里的應用就太廣泛了，一般來講都是將耗時比較大的放置離線計算來做。但是這里要聲明一點，離線計算依然是越快越好，不能因為他叫離線計算所以在設計或開發階段就不關注時效。

1.2 數據質量

上一章提到了基本的數據質量，但實際工作中，往往質量會出現各種意想不到的數據，下面是工程中影響數據質量的幾個比較大的問題：

1. 數據丟失，不管是在采集，上報，數據流轉環節，都可能會帶來一定的數據丟失比例。
2. 數據亂序，數據在打包、上報、流轉等環節均可能出現亂序，尤其是在補傳數據中。
3. 數據重復，數據重復發送，尤其是在網絡不好時。
4. 數據本身不准確，這個最突出的地方就是在 GPS 數據中，經常出現飄點、噪點等等。

2. 數據庫的挑戰

2.1 數據項多

汽車里具有非常復雜的電路系統和傳感器設備，我印象當中的粗略估算應該是有 120 項左右，並且這些數據項並不是車內數據的全部。隨着自動駕駛的到來，汽車的傳感器會越來越多，數據項就會更多。

如果按照傳統的 Mysql 存儲，那么由於行式存儲，所以在取回數據時候就會非常影響效率，之后介紹到 IoTDB 的文件格式的時候再聊。

2.2 存量數據大

我們按照寶馬汽車 2019 銷售量估計，252 萬輛，我們假定 4 年前就已經具備了聯網模塊那就是 1000 萬輛汽車。按照每條數據 1K，每天采樣上傳 1 次，應該是 每天 9G 數據。但因為車不可能一直都點火開，所以要假設一個 30% 的在線率，那就是 3G 數據。

3 年大約就會存儲 3TB 數據，可能你覺得 3T 數據對於時下最熱的大數據來講並不是一個非常龐大的數字，但如果整個數據里面不包含任何圖片、音視頻甚至都沒有文字，全部是由整數、浮點數堆積起來的，那你可以試想一下這個數據庫里面到底有多少數據，如果你一個不小心執行了 count(*) 你覺得會卡死不？

2.3 采集頻率高

汽車不同於其他傳感器的地方是，他是一個處在時刻運動當中的物體，如果需要做一些高階的計算模型，比如說：碰撞檢測、行駛軌跡糾偏等，那么相應的數據采集頻率有可能要達到秒級。

當然我說完這句話，可能你感觸並不是很深，但是結合前面說到的兩點：120項數據、1000萬輛車，將采集頻率提高到 1 秒一采集，那么這個頻率下，一天產生的數據大小就是 259T。這時候你找 DBA 說，哥們我們的需求要 1 天寫入 259T 數據，我覺得反正我是沒臉找人家，讓產品去跟 DBA 聊吧。

2.4 大數據分析需求

現有時序數據庫都無法支持大數據分析框架，都需要通過數據庫的 Api 把數據從數據庫往數據倉庫導出后再存一份，數據量直接翻倍。 舉個例子，我如果需要對 Mysql 中的數據進行 MapReduce 計算，那么只能是將數據通過 JDBC 接口導出到 Hbase 或 Hdfs 上，然后執行計算，可能你覺得這很正常，但按照上面提到的數據量，數據復制之后你公司里可能就需要每天支撐 500T 數據。

2.4 不同數據庫遇到的問題

我們公司也采用了多種嘗試，從開始的 MySql 到 MongoDB 再到 Hbase 等等，它們總存在這一點或多點的讓你覺得就是不滿足的地方，如下圖：

IoTDB

到此為止，整體需求基本明確，作為一款物聯網的時序數據庫需要處理的問題:

1. 高速寫入
2. 高效壓縮
3. 多維度查詢，降采樣、時序分割查詢等
4. 查詢低延遲高效
5. 提高數據質量，亂序、空值等
6. 對接現有大數據生態

IoTDB 功能特點

IoTDB 完成了上述問題中的幾乎所有功能，而且可以靈活對接多生態，高性能優勢等。那么 IoTDB 是如何完成這些優勢項，如何做到？

IoTDB 架構描述

對照上面的圖，大致了解一下 IoTDB 的結構，邏輯上被分為 3 個大部分，其中：

1. Engine 是完整的數據庫進程，負責 sql 語句的解析，數據寫入、查詢、元數據管理等功能。
2. Storage 是底層存儲結構，類似於Mysql 的 idb 文件
3. Analyzing Layer 是各種連接器，暫不涉及細節。

Engine 和 Storage 中主要包含：

1. IoTDB Engine，也就是代碼中的 Server 模塊.
2. Native API，他是高效寫入的基石，代碼中的 Session 模塊
3. JDBC，傳統的 JDBC 連接調用方式，代碼中的 JDBC 模塊
4. TsFile，這是整個數據庫的一個特色所在，傳統的數據庫如果使用 Spark 做離線分析，或者 ETL 都需要通過數據庫進程對外讀取，而 IoTDB 可以直接遷移文件，省去了來回轉換類型的開銷。TsFile 提供了兩種讀寫模式，一種基於 HDFS，一種基於本地文件。