導讀：本次分享的主題爲 Hadoop or TDengine，如何做物聯網大數據平臺的選型？主要介紹物聯網大數據處理中可能遇到的問題；結合實際的應用場景，分析 TDengine、InfluxDB、ClickHouse、Hadoop、MySQL 等系統在處理時序數據時的優缺點。
——前言——
1. 大數據時代
大數據時代，大家都在說什麼叫大數據，強調的就是一個“大”字，人們期望對海量數據的挖掘和運用能夠獲取到更多有價值的東西。其來源包括：微信聊天數據，淘寶&京東等電商數據，高速收費站的數據，摩拜等共享單車產生的數據，股票交易數據，天文望遠鏡產生的數據等等，這些數據有的是物聯網的數據，有的是時序數據，有的不是時序數據，比如微信和淘寶、京東等產生的數據就不在本次討論範圍內。
物聯網的數據可以分爲兩類，靜態數據和動態數據：
- 靜態數據：通常爲標籤類數據，如：設備所在的地址、編號、顏色等等，這些數據不會隨着設備產生新數據的過程中而發生變化。
- 動態數據：以時間序列爲基礎的數據，其特點是和時間有一一對應的關係，可以按照時間順序記錄的數據列，並且這種關係在數據處理中尤爲重要。充分利用這樣的關係，才能把數據庫做好。現在越來越多的公司意識到處理這樣的時序數據應該用專門的數據庫，當然，也還有相當一部分的公司仍然用Hadoop來處理，在此基礎上做分析和改造，這樣成本就會相對較高。
物聯網大數據主要體現在採集的機器數目越來越多，頻次越來越高，如：電網以前可能只採集500KV的數據，慢慢可能採集10KV的數據，最後入戶的220V的數據可能都要採集。隨着這種2維方式的增長，採集的數據成幾何量的增加，因此，傳統的方法帶來越來越多的挑戰。
2. 物聯網、工業4.0的技術鏈
對物聯網、工業4.0的數據進行分析，會經過如下4個步驟：
- 數據採集：通常通過傳感器採集。
- 邊緣計算：通過通訊模組傳輸數據。
- 存儲·查詢·計算：將傳輸的數據輸入雲數據引擎進行存儲。
- 系統：最後將處理好的數據接入大屏、app、web界面應用等系統。
物聯網的數據平臺主要集中在邊緣計算和雲數據引擎：
- 邊緣計算。有些場景需要用到邊緣計算，有的則不需要。邊緣計算（或前置機模塊），主要負責採集工業上的協議（因爲，傳感器採集的數據，通常是不規整的），同時可以在邊緣計算上做降採樣，把一些頻率高的數據放在邊緣計算部分。
- 雲數據引擎。這塊是本次分享的重點，後面會詳細介紹。
——物聯網大數據選型——
1. 傳統的實時數據庫
在物聯網概念出現之前，設備數據的採集和分析也是非常重要的功能需求。爲了解決流程控制領域的實時數據處理問題，從上世紀八十年代起，出現了一批實時數據庫，以美國的OSISoft PI爲代表，具有較高的數據處理能力，能夠很好的解決傳統工業生產問題。當時和實時數據庫相結合的組態軟件流行了很長一段時間，主要強調工控領域的實時數據採集、監視或者控制，其實現思路並不複雜，本質上是內存庫，賣點在於實時響應和實時控制。這裏實時控制是非常重要的，因爲工控就是在強調控制，通過過來的參數，如溫度高的、電流大的，能夠把這些信息反饋回去，重點在於快速，能夠在1s之內響應。也因爲這個特點，這種實時庫只能存儲當前所有采集量的截面，相當於一個時間片，有些好的產品可以存儲多個截面，但也比較有限，可能只能存儲5分鐘內的數據。
2. 傳統的實時數據庫面臨的挑戰
這樣的數據處理方式是物聯網嗎？答案是肯定的，因爲物聯網的基本概念是物體和物體相聯。但這只是物聯網的初級階段，解決數據採集從無到有，包括數據的實時上數和告警的問題，隨着測點數暴漲，數據採集頻次不斷提高，傳統實時數據庫暴露出下列問題：
- 水平擴展：沒有水平擴展的能力，數據量增加，只能依靠硬件scale up（增加單個硬件性能，如把16G內存的機器換成256G內存的，但是這樣的擴展能力還是有限的）。所以水平擴展，在選型過程中如果解決，也是一個重要的問題。
- 技術架構：技術架構陳舊，使用磁盤陣列（價格比較昂貴），還運行在Windows環境下。
- 數據分析：數據分析能力偏弱（還需要歷史數據，否則只能根據當前數據進行分析，看看有沒有超過閾值，或發出報警，這其實不能算作數據分析），不支持現在流行的各種大數據分析接口。
- 雲服務：不支持雲端部署，更無法支持PaaS。
現在做物聯網，在實時數據的基礎上，還要進行擴充，做歷史數據。通過歷史的查詢，歸類的統計，或者機器學習的方法把歷史數據增值，獲得兩類信息：
- 整體情況的統計，如有10W個設備，統計這10W個設備的總體情況，也就是常說的報表。
- 單個設備的分析，如有一臺設備經常壞，爲什麼經常壞呢？我們可以看下這臺設備採集的數據是什麼樣的，是不是電流經常發生突變等信息。通過對單個設備進行分析，把這塊的數據模式收集起來，擴展到其它設備中，能夠提高整個系統運維的安全性。同時，把單個設備進一步擴展，擴展到每個人用的手機或者手環等，能把這些大數據做好，那麼我們除了To B業務外，也能在To C業務上給公司產生增值。
如果不需要歷史數據，可以只做redis，因爲只看當前數據，redis會比一些實時數據庫的架構穩定性更好。
3. 通用的互聯網大數據解決方案
目前的Hadoop方案，是一些大型的互聯網企業最先使用的。在處理大數據時，將多個開源軟件，如現在比較流行的kafka，然後把實時數據引入到redis，把歷史數據存到Hadoop，中間可能結合Spark和Flink的計算，利用集羣來處理海量數據。這是一種非常好的，通用的處理大數據的解決方案，可以處理百億、千億、甚至萬億級別的數據，只需保證它的服務器足夠。如果有特殊需求，可以寫一些代碼來實現，比如做實時監控，就可以在kafka後面掛一個Flink做實時分析，做實時的流計算，把當前的QBS、健康狀態做實時統計；在比如看歷史數據，可以在Hadoop上掛一個MapReduce，這樣我們可以通過寫程序把所有的需求都實現。
那麼對於物聯網，爲什麼不用這一套解決方案來做呢？是不是不需要做物聯網大數據平臺的選型呢？答案顯然是否定的。
4. 通用互聯網方案面臨的挑戰
對於一些規模較小的公司，做軟件開發所關注的點，Hadoop系統並沒有很好的解決，因爲它比較低效，也比較複雜，成本比較高。逐一分析下：
- 開發效率低：因牽涉到多種系統，每種系統有自己的開發語言和工具，開發精力花在了系統聯調上，而且數據的一致性難以保證。如果你的公司從頭開始做這件事，投入成本更大。
- 開發成本高：這套架構需要的開發人員，市場比較稀缺，可以把這套系統搭建起來的比較有經驗的研發經理，年薪沒有50W是找不到的，一般的開發人員也比較難找，如果從新培養，但是待遇低的話，也很難留住人才。
- 運維複雜：每個系統都有自己的運維後臺，帶來更高的運維代價，出問題後難以跟蹤解決，系統的不穩定性大幅上升。
- 運行效率差：非結構化數據技術來處理結構化數據，整體性能不夠，系統資源消耗大。因爲多套系統，數據需要在各系統之間傳輸，造成額外的運行代價。
- 應用推向市場慢：集成複雜，得不到專業服務，項目實施週期長，導致人力攀升，利潤縮水。
綜上所述，該如何解決這些問題，如果你的公司做這樣的項目能夠投入的人比較少，不足10人，那麼投入的硬件可能就是10個服務器，在這樣的規模內，用Hadoop顯然是不合適的，否則1~2年也不會做出好的產品。
另外，在國內人力成本越來越高的情況下，很多的公司都期望能夠選擇一個數據庫。不光解決各種效率問題，更重要的是出了問題能夠及時有人處理，比如用俄羅斯的ClickHouse或者美國的InfluxDB，如果出現問題，花錢也很難找到人維護，所以國家搞國產化，也有這樣的因素在裏面。
5. 物聯網、工業4.0數據特徵：時序空間數據
那麼對於物聯網大數據平臺，什麼樣的選型方案纔是專業的、正確的？我們首先要對網聯網數據的模式進行分析，總結物聯網數據的特徵，並加以充分利用，這樣我們選擇的數據庫纔是一個真正能夠利用軟硬件資源，發揮最大效用的網聯網數據庫。大家在做自己的app時也要考慮你的數據是否滿足這樣的特徵，是否適合用時序數據庫來做。其典型特徵有：
- 所有采集的數據都是時序的。在數據索引的基礎上，把內存塊、磁盤文件按照這樣的時序的假設進行拆分，就不需要再做額外的索引，來節約時間，提升效率。
- 數據都是結構化的。計算機的編程語言更擅長處理結構化的數據，比如一個Json格式的數據過來，雖然有很多的庫直接就把它解析掉了，形成我們需要的數據，但是這個過程也是比較耗時的，因爲傳入的時候需要進行正向的序列化，傳出的時候需要進行反向的序列化，這倆次的序列化會產生很大的CPU消耗。並且結構化的數據，可以採用列式存儲，雖然物聯網的數據量比較大，但是變化通常都比較有規律，如果採用行式存儲，壓縮比率不會太高，如果採用列式存儲，如001100這種數據，我們只需要記住0出現幾次，1出現幾次，而不需要把所有的數據都記錄下來。因此，不是列式存儲的數據，建議大家都不要選用。
- 一個採集點的數據源是唯一。因爲時序數據最重要的特點就是每臺機器產生的數據跟其它機器產生的數據在邏輯上一定是分離的，因此，可以按照分離的操作進行分表，Prometheus（普羅米修斯）和濤思數據庫都是這樣做的，邏輯上進行分離之後，就不需要把大量的數據混合在一起進行查詢，大大提高了查詢效率。
- 數據很少有更新或刪除操作。可以在數據寫入磁盤的時候進行優化，當數據量增大的時候（幾十上百M/s的寫入速度），能夠達到單塊磁盤極限的量，這時，一定要減小落盤後的修改，否則在修改的時候，某些數據是沒有辦法寫入磁盤的，這時系統整體的吞吐量是不夠的。
- 數據一般是按到期日期來刪除的。在選型初期，很多公司不太注意壓縮比，運行一段時間之後，數據越來越大，就不得不考慮數據的保存時長，如何快速的刪除過期數據，這是需要考慮的問題。
- 數據以寫操作爲主，讀操作爲輔。在設計過程中要有一個優先級，需要優先滿足寫的操作。
- 數據流量平穩，可以較爲準確的計算。有些互聯網公司可能雙十一的時候數據流量非常大，平時數據量相對較小，那麼就不太容易估算機器的容量。
- 數據都有統計、聚合等實時計算操作。這些操作可以在數據庫中進行預先計算，可以在數據庫內部做，也可以在接收的時候將數據庫的結果保存在一些關鍵步驟，這也是之前Hadoop等數據庫通用的方法。
- 數據一定是指定時間段和指定區域查找的。可以把查詢遍歷的磁盤縮小到非常小的一部分，這是提升數據庫速度的一個關鍵。
- 數據量巨大，一天的數據量就超過100億條。數據庫能不能支撐分離存儲，新的、熱的數據放在SSD中，老的數據放在HD上，或者其它更老的數據放在網絡存儲中。
這就是物聯網大數據平臺在選型中需要注意的問題。
——實際應用場景分析——
接下來通過分析一些系統的現狀，來看看出現了哪些問題：
1. 某智能園區配電監控系統
這是某智能園區配電監控系統，採用的還是10年前的架構，實時數據庫是這個架構的最核心部分，數據從採集設備過來之後，經過數據採集服務器（前置機）進入到實時數據庫和歷史數據庫中（實時數據庫以內存庫爲基礎，隨着技術的進步，也進行了擴展，開發了歷史數據庫，並且把數據分爲三層，分別爲熱層、穩層和冷層。熱層是指數據在內存中，穩層是指數據在硬盤中，冷層是指對硬盤中的文件進行了壓縮或者二次歸檔。這種冷溫熱層的區分，已經和現在的時序數據庫系統比較接近了，但是使用上並不是很方便。），採集的數據通過採集服務器進入到了內存庫進行了實時計算，同時歷史數據採用Oracle進行存儲，並且這種方式也採用了行轉列的方式，在時間維度上對數據進行拆分，按天分表，5分鐘一條歷史數據，每表288字段。
這個系統的賣點在於實時數據處理，包括告警、失電設備分析、故障快速恢復方案，可以通過大屏展示一些數據指標。
其問題在於：
- 歷史數據分析較少
- 難以升級改造，提高數據採集頻率和性能需要推翻重做
這時可以採用InfluxDB或者TDengine時序數據庫替換實時數據庫和歷史數據庫，不過InfluxDB達到同樣的效果，可能會需要比較高的硬件成本，這也是需要考慮的因素。
2. 某車聯網數據倉庫
第二個是某車聯網數據倉庫，採用的是Hadoop系統的解決方案：
- 記錄了百萬級別車的歷史數據，分鐘級別的採集頻率
- 每天數據增量在2TB左右，需要保存10年
- 作爲數據倉庫，無實時查詢要求
- 歷史查詢僅僅在發生事故時使用
存在的問題：
- 採用百臺級別的硬件服務器，硬件擴容成本和軟件維護成本很大
- 因爲存儲在Hadoop系統中的數據採用的是lzo的壓縮格式，綜合壓縮比只能達到45%
- 有強烈的改造需求，希望提供一些增值服務，比如每臺車的車主想要查看自己車輛的信息，都去過哪些地方，停留了多久等，這時對系統的查詢需求就會比較大，但是Hadoop是沒法做到實時查詢的，做到10s級別的查詢都非常困難。隨着記錄的車輛越來越多，國家要求更多的車輛的數據要保存的車聯網中，那可能就不是百萬級別的車，可能300W、500W甚至更多，服務器就得相應增加到300臺或者500臺，雖然能夠處理，但是盈利空間並不是很大，沒有動力來支持做這樣的擴容。
這時，我們就建議更換它的數據庫，這裏比較適合的有：TDengine、ClickHouse，ClickHouse適合做一些數據倉庫，但是實時寫入的能力相對差一些，TDengine在實時查詢上會更好，壓縮比可以做到更高，當時測試的時候，壓縮比可以做到4%，比原來提升了10倍。
3. 某大型機械製造商的設備管理系統
第三個是大型機械製造商提供給客戶的設備管理系統，每套設大概賣到50萬或者100萬，已經銷售了幾十萬級別的設備。數據進來之後，首先進入kafka中，通過kafka將實時的壓力分攤出去，實時數據會進入redis中，通過統計進入關係庫中，然後給到App做最新狀態的顯示，歷史輸入會進入Cassendra中，Cassendra的特點是寫入速度非常快，但是查詢非常耗時。這樣的系統其實是需要更新的，但是動力並不高，因爲它還是能基本滿足用戶的需求，這時就需要挖掘出用戶新的需求，提供增值服務。
從這個例子和上一個例子我們可以看到，如果只是偶爾的查詢，一般的數據庫都能滿足要求。但是物聯網不只是物體和物體的聯接，還包括用戶和物體的交互，不止能夠看報表，還要能夠走到C端的用戶中，這時物聯網平臺纔能有影響力，才能產生更多的增值服務。所以當我們的客戶不再是公司、管理人員、運維人員，而是真正的用戶，那這套系統將非常具有價值。在這種需求下，如何去選型是我們需要考慮，也就是誰的實時數據處理的好，誰的歷史數據處理的好，能夠滿足這樣的需求。
4. 某智能工廠的高頻數據採集系統
這是某智能工廠的高頻數據採集系統：
- 採集設備100，採集點7000
- 採集頻率5s，但是歷史數據只能存儲60s
目前的訴求：
現在希望將採集頻率提升到20ms，每秒數據量達到50hz*7000*16B=5.6MB，並且採集規模擴大到所有產品線，以期更好的提高生產效能。
這裏可以採用TDengine和Prometheus，它們各有優缺點，大家可以在選型的時候考慮下。
5. 某電動車製造商的車輛實時檢測系統
最後一個案例是某電動車製造商的車輛實時檢測系統，目標比較火，是面向終端用戶的。用戶在購買電動車之後可以選擇是否購買車輛實時檢測系統，實際就是在車輛上安裝這樣的採集盒，定期的將車輛的軌跡、電池等參數上傳到雲端，成批次的寫入MySQL數據庫，之後車主就可以隨時查詢車輛的軌跡。這套系統，在最初是非常OK的，但是隨着車輛的增加達到1000輛時，寫入壓力就非常大了，CPU佔有率非常高，導致沒有辦法處理實時查詢的請求，最終只能降低入庫的頻率，但這樣大大降低了用戶體驗。
這時它需要：
- 提高實時的寫入能力
- 寫入的數據可以快速查詢
- 可以水平和動態的擴容
明確了這樣的業務需求之後，它做了技術選項，當時競爭的數據庫也比較多，最終選擇了TDengine，說明TDengine在這樣的業務需求下，是非常出色的。
——時序數據庫選型問題總結——
最後，總結下時序數據庫選型時需要注意的問題，時序數據庫的基本功能就是提供高效可靠的數據採集、數據插入、數據查詢和計算等通用的功能，判斷一款時序數據庫是否好用，主要是看能否在你的業務需求上產生亮點，對業務產生增值：
- 性能提升：提高實時寫入（用點/s的指標進行衡量，10W點/s只是起點）、實時查詢、聚合計算、歷史查詢性能，更多更快。
- 業務提升：帶來新的業務需求，離線功能轉在線功能。
- 總擁有成本：1. 硬件成本：磁盤空間、計算資源、機房費用。2. 運維成本：備份、遷移、DBA工具、人員成本、運維工具。
- 研發成本：豐富的API接口、低學習成本、低人員成本。
總之，在物聯網的選型上，如何找到自己痛點，在單位硬件的條件下，測試這幾個痛點的主要性能，才能更好的做物聯網大數據平臺的選型。
作者介紹：
關勝亮
濤思數據 | 聯合創始人
2017年加入濤思數據，負責 TDengine 的核心研發工作。畢業於中科院計算所，曾任職360、北京科東等公司，在數據採集與實時監控領域有豐富經驗。
本文來自 DataFun 社區
原文鏈接：