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