最合適的工業網際網路大資料處理方式是什麼？
大羅2022-01-13 16:13:10普通人提到工業網際網路，偏向狹隘的定義，指裝置聯網之後的資料呈現；而廣義的工業網際網路包含人機料法環的統一線上管理，乃至數字孿生概念，以及和傳統業務系統（例如CRM等）的融合；
而無論是狹隘還是廣義的定義，都離不開對裝置物聯的海量資料管理。
對比我們提及消費網際網路的電商業務，日活訪問量動不動過10萬和100萬，殊不知，在工業網際網路領域，高併發是常態而且更有挑戰；兩者區別很明顯，消費網際網路有時段訪問峰值，而工業網際網路流量曲線基本波動很小，因為裝置不會保持空置狀態，所以開機等於聯網，就會上報資料。
而且，單單討論日活訪問量還不夠，10萬個自然人訪問系統，對比10萬臺裝置聯網，肯定是後者的qps更高，因為1臺裝置對應的點號（裝置屬性）就可能過千。
那麼，在高連線，多併發，大資料上報的場景下，如何選擇一款大資料庫軟體，作為資料載體，就變得十分重要了。
這款軟體首先得滿足分散式，因為分散式才能避免單點故障，支援水平容量擴充套件，併發計算；
其次，它最好還是易於運維，比如，較少的服務程序管理，自動資料負載均衡；
再次，它需要友好的互動形式，例如，滿足常規sql聚合，更甚者，流計算中的視窗函式也能支援！
最後，它還是能夠節省成本的，比如，開源意味著初期階段不用付費，比如，資料壓縮率高可以節省伺服器費用；
針對以上需求特性，我們公司選用了濤思資料的國產資料庫TDengine 。
選用TDengine，是因為我之前曾經在大資料Hadoop生態裡浸淫過，深知hadoop體系的不足。
我們的工作包含資料從應用層到大資料庫的彙總，然後是分析計算，反饋應用層需要的業務報表資料。例如，平均每分鐘的功率曲線，統計每分鐘的用電量，對比不同裝置，乃至廠區的耗能情況，這裡面既有實時流計算，也有批處理。
如果把大資料系統作為一箇中臺型服務，它對應用層暴露的僅僅是HTTP形式的查詢介面，然後，背後，需要涵蓋很多技術元件，例如，Hadoop的HDFS/Hive做原始資料保留，Hbase則儲存計算後的資料，計算框架則使用Flink或者Spark，分散式協調使用zookeeper，還需要訊息中介軟體Kafka。
所以，整個框架技術元件看起來非常的“重”，這個“重”，一方面體現在需要對Hadoop的技術元件非常熟悉，例如，資料均衡備份冗餘策略，hive分割槽策略，hbase的key設計規則，一方面對於業務規則的不好適應。例如，每分鐘的功率開始是取該分鐘間隔內的最後一個數值，後來改成取該分鐘內的平均數值，凡此種種，需要大資料系統，從ods層面重新開始計算，帶來非常大的開發工作量；
一言以蔽之，專案經理經常調侃，“就是展示幾條曲線，幾個資料而已，為什麼要那麼複雜？”
在專案經理調侃之餘，我們開發也在思考，其實工業網際網路以裝置為主線，統計的都是一段時間內單個裝置的資料，難道就沒有一個很好的強調物聯網時序場景的大資料軟體嗎？
一番調研之後，發現TDengine的優勢完全可以解決我們的痛點——以裝置資料模型建立超級表，以裝置為單個子表，按時間先後順序連續儲存資料。在查詢的時候，可以提供預計算的統計資料，可以基於裝置單個子表的tag做聚合的功能，結合流計算中的滑動視窗、滾動視窗概念、可以快速的從原始資料得到聚合統計結果。
然後，它的安裝包十分小巧，只有10M左右，藉助於官方文件，linux系統下的叢集部署也很簡單，配置好主機名，域名解析，暴露的埠，執行程式，立馬就能使用了。對比之前的hadoop技術棧，這對運維團隊來說簡直就是福音！
在和應用整合方面，TDengine支援jdbc-jni和http restful兩種方式讀寫資料，我們採取jdbc-jni結合mybatis的方式，本地開發的時候，需要安裝對應版本的TDengine-client。設計好超級表，子表則在首次寫入的時候同時建立。對應於我們三節點（24核，62G）的叢集，程式輕輕鬆鬆就達到qps 每秒寫入1萬記錄的效能。至於查詢效能，例如當天的功率曲線，按照1分鐘1個記錄，總共1440個計算資料，輕鬆的在1秒鐘內透過1句sql聚合當天1萬條記錄而得到；又例如每月的日溫度曲線，總共30個計算資料，也可以在當月30萬條記錄，透過avg函式結合interval，同樣也是在秒級查詢的時間間隔內返回！這麼高的效能，看同行的調研，基本磁碟空間只需要原來hadoop/influxdb的十分之一！
最後是應用部署，因為我們的程式採用容器化的方式執行和管理，所以，需要簡單基於linux映象安裝對應版本的TDengine-client，生成基礎映象，再提供給應用程式使用！ 這中間，我們遇到問題都是在github提交issue，很快就有TDengine的官方夥伴回覆，在社群群也有工作人員以及其他熱心開發者幫忙解答。這其實也再次側面驗證開源產品的好處，“你遇到的坑早有前人幫你淌過”。
除此之外，裝置的全球化部署，對應著不同客戶有基於自身時區進行統計的需求，即是每個客戶審閱自己裝置的統計資料時，當然期望是以客戶自己所在時區為維度進行統計。很幸運，TDegnine不僅提供了時間視窗函式interval，還支援偏移 offset（偏移必須小於間隔）。首先，我們配置taos的系統時區為“timezone UTC-12”（即地球最早的時區）。然後，當中國時區客戶（Asia/Shanghai （CST， +0800））查詢以天為間隔的時候，我們會偏移4個小時，例如， interval（1d， 4h）；當美國時區客戶（America/Los_Angeles（PST， -0800）查詢以天為間隔的時候，我們會偏移20個小時，例如， interval（1d， 20h）；
後來，TDengine的社群工作人員也把這個做成了經典案例文章——《一文幫你掌握TDengine的降取樣查詢+跨時區統計》。
寫在最後，我這篇文章的回答，其實只是解讀了工業網際網路的其中一個側重點，“如何價效比更高的承載海量裝置物聯資料”，我個人首推TDengine。題外話，裝置的物聯過程涉及的技術棧很廣，小廠幾臺裝置負荷不起高昂的開發費用，大廠的鉅額投入又會衍生出販賣解決方案的想法。所以，工業網際網路專案衍生出來的系統，很自然的會朝著SaaS化以平攤開發成本，再結合公有云基於使用者需求按需部署系統。
