物聯網大資料平臺TIZA STAR架構解析
1.導讀
有人說物聯網是引領資訊科技的第三次浪潮。
第一次浪潮是個人電腦的出現，開創了資訊時代的第一次革命，此次浪潮成就了微軟、IBM等巨頭。
第二次浪潮是以資訊傳輸為特徵的網際網路及移動網際網路，實現了計算機與人的聯通，此次浪潮成就了Google、Facebook，以及國內的BAT等巨頭。
第三次浪潮是以資訊感知為特徵的物聯網，實現了物與物、人與物的全面聯通，這次浪潮還沒有形成寡頭，但是隨著感測技術、通訊技術以及大資料處理技術的發展，物聯網已經在公共事務管理、公共社會服務和經濟發展建設等領域中遍地開花，涉及到的行業也越來越多，如交通管理、節能環保、物流零售等。
2.背景
萬物互聯的時代正逐步到來，據權威報告預測，2020年全球物聯網連線的終端數將達到500億，資料呈現爆發式增長。這個資料究竟有多大呢？舉個典型的例子：
某個工程機械集團，擁有10萬臺工程機械裝置，
每臺裝置上的採集終端每隔10秒上傳一次資料，每條資料大小1K，
一年的資料量為365天*8.6億=3000億，
一年佔用的儲存為3000億*1K=300TB。
我們通常為了保證高可用，會對資料做3份冗餘儲存，也就是說，這樣一個企業一年的資料儲存量就可以達到1PB，而1PB就相當於50個國家圖書館的總資訊量。
物聯網的資料中蘊含的價值也是非常高的，比如：利用車載終端上傳的資料，可以提前預測群體出行的時間、方式和路線，可以為城市車輛排程提供決策幫助；在工業裝置上安裝的感測器，實時收集工業裝置的使用狀況，可以進行裝置診斷、能耗分析、質量事故分析等；通過各種環保感測器採集的資料，可以輔助空氣質量改善、水汙染控制等。
3.傳統架構的瓶頸
面對如此海量的物聯網資料，傳統技術架構已經難以應對。
首先，傳統架構都嚴重依賴於關係型資料庫，而關係型資料庫的索引結構基本上都是類B+樹，隨著終端數量增大，資料庫讀寫壓力劇增，讀寫延遲增大，資料庫面臨崩潰。其次，難以支援海量資料的儲存，傳統資料庫無法水平擴充套件，所以擴容成本非常高，難以滿足PB/EB級資料的讀取和寫入。最後，難以進行大規模資料處理，傳統情況下依賴資料庫的SQL或者儲存過程來進行資料分析的模式，無法對資料做分散式處理，經常一個SQL能把整個資料庫拖垮。
為了能夠把眾多行業的物聯網大資料價值發揮出來，天澤資訊推出了一個企業級的物聯網大資料平臺（TIZA STAR）。
4.TIZA STAR架構解析
那麼TIZA STAR到底是什麼呢？它是一個面向物聯網的開放的資料處理平臺，涵蓋了資料接入、計算、儲存、交換和管理。使用者基於這個平臺，可以很輕鬆地打造自己的物聯網解決方案。下圖可以展現出TIZA STAR的定位：
圖1 TIZA STAR的定位
TIZA STAR主要是為了解決什麼問題呢？下面的這幾個都是典型的物聯網應用場景：
- 物聯網安全，解決了從資料接入到最終展現給使用者的每個環節的安全防護；
- 實時接入，解決了百萬級別的物聯網終端，以很高的頻率傳送的資料能夠實時的接入到系統中；
- 當前狀態，解決了在百萬級別的物聯網終端中，快速地獲取到某個終端的當前的狀態；
- 歷史狀態，解決了在百萬級別的物聯網終端中，快速地獲取到某個終端在過去的某個時間段內的狀態引數；
- 下發指令，解決了如何給一個或者多個物聯網終端下發指令，從而可以實現遠端控制和引數調校等。
4.1架構圖
圖2 TIZA STAR架構圖
最底層是裝置層，可以全部採用X86通用伺服器，無需採購小型機等昂貴的計算裝置和高階儲存裝置，從整體上可以大幅拉低成本。
最上層是業務層，主要是物聯網的各種應用和第三方系統。業務層無需對資料進行處理和分析，只是通過查詢介面獲取到平臺層中已經處理過的資料並在介面進行展示。
中間的這一層就是TIZA STAR, 包含了資料接入服務、資料儲存服務、資料計算服務（包括實時計算和離線計算）、監控報警服務、平臺管理服務、資料交換服務。下面會對每個模組詳細介紹。
4.2資料接入
資料接入時，感測器或者採集終端通過無線或者有線的方式傳送到平臺端，平臺端通過軟負載均衡(LVS)或者硬負載均衡(F5等)將流量均勻的負載到各個可水平擴充套件的閘道器，每個閘道器都是基於netty實現的高效能的網路接入程式。
資料接入協議分兩個層次，在通訊層次上，支援TCP、UDP、HTTP和WEBSOCKET等通訊協議；在資料協議層次上，支援MQTT、JSON、SOAP和自定義二進位制協議。通過這兩個層次的互相搭配，可以輕鬆實現任何物聯網終端、任何協議的資料接入。
圖3 TIZA STAR資料接入協議
閘道器接收到資料，並完成解包之後，將資料包傳送到訊息中介軟體中，可以有效地應對“井噴流量”和下游服務短暫不可用的問題。在訊息中介軟體的選擇上，我們比較了Kafka、RabbitMQ和ActiveMQ，最後選擇了Kafka，因為在分散式環境下Kafka的吞吐效能非常優秀，並且其持久化和訂閱/釋出的功能與物聯網的場景非常匹配。
4.3資料儲存
TIZA STAR綜合使用了多種儲存引擎，包括HDFS、HBase、RDBMS和Redis。其中HDFS非常適合於非結構化資料的儲存，支援資料的備份、恢復和遷移，在系統中主要用於儲存原始資料和需要進行離線分析的資料。
- HBase適合於儲存半結構化的資料，可以很好的支援海量物聯網終端的歷史資料的查詢，在系統中主要用於儲存終端的歷史軌跡和狀態等體量比較大的資料。
- RDBMS適合於儲存結構化的資料，通常根據具體的資料庫採用不同的高可用部署方案，在系統中主要用來儲存終端基礎資料、字典資料和資料分析的結果等。
- Redis是基於記憶體的KV資料庫，在系統中通常用來快取需要頻繁更新和訪問的資料，比如物聯網終端的當前狀態等。在多種KV資料庫中我們最後選擇了Redis，主要是看重Redis為多種資料型別以及多種資料操作提供了很好的內嵌支援。
4.4資料處理
資料處理包括實時計算和離線計算兩種。
實時計算我們比較了Storm和Spark-streaming，最後選擇了Storm，主要考慮兩點：一方面是因為Storm的實時性更好一些，另一方面是因為在物聯網的場景中需要支援對終端資料的全域性分組，而Spark-streaming只能在每個RDD中做分組。所以最後我們選擇了Storm作為我們的實時處理引擎，在它的基礎上我們包裝了自己的實時計算服務，可以支援應用層的排程和管理。基於實時計算服務可以很容易實現對物聯網資料的清洗、解析、報警等實時的處理。
離線計算目前支援MapReduce和Hive，對Spark的支援也正在進行中，主要用於對物聯網資料做日/周/月/年等多個時間維度做報表分析和資料探勘，並將結果輸出到關係資料庫中。
4.5資料交換介面
資料交換介面主要是為了簡化應用層與平臺層之間的資料訪問而抽象了一層訪問介面，有了這層介面，應用層就不需要直接呼叫Hadoop、HBase等原生API，可以快速地進行應用開發。
目前資料交換介面支援：SQL、Restful、Thrift和Java API，使用者可以根據實際情況靈活選擇資料交換的方式。
資料交換的內容包括：物聯網終端的當前狀態、物聯網終端的歷史狀態/軌跡、指令下發、資料訂閱與釋出等等。
4.6平臺管理
平臺管理包括監控報警和管理UI。
監控報警我們是用Ganglia和Nagios配合來做的，從三個級別來做：硬體級別（伺服器、cpu、記憶體、磁碟等）、程序級別（程序不存在、埠監聽異常等）、關鍵業務指標（中間佇列的元素數、閘道器建立的tcp連線數等）
管理UI包括介面化安裝部署、使用者管理、終端管理、叢集管理、資料接入管理、實時和離線計算任務介面化管理。
4.7平臺SDK
平臺SDK是為了方便企業使用者基於TIZA STAR定製自己的物聯網應用，我們提供了三個SDK：GW-sdk、RP-sdk、OP-sdk。
- 其中基於GW-sdk可以快速新增一種新的物聯網終端協議的接入。
- 基於RP-sdk可以快速開發一整條實時處理鏈，也可以快速開發處理鏈中的某個模組。
- 基於OP-sdk可以快速開發一個可週期性排程的MapReduce/Spark任務。
4.8平臺安全
物聯網安全也日益重要，前段時間發生的私家車被惡意遠端控制的事件就體現出了物聯網安全的重要性。TIZA STAR從鏈路安全、接入安全、網路安全、儲存安全和資料防篡改這幾個方面來保證物聯網安全。
- 通過SSL和TLS保證鏈路安全；
- 通過祕鑰鑑權對資料的訪問有效進行控制；
- 通過防火牆等硬體裝置防止網路攻擊；
- 通過副本冗餘保證資料的儲存安全；
- 通過每512位元組進行CRC校驗的機制保證資料的防篡改。
5.應用案例
5.1資料流
接下來我們以車聯網為例，看一下TIZA STAR的資料流。
圖4 車聯網資料流
如圖4所示，物聯網終端通過無線/有線網路傳送到TIZA STAR平臺，經過一系列的處理後存入到各種儲存引擎中，業務可以通過資料交換介面來訪問處理後的資料。具體流程如下：
- 車載裝置或者感測器裝置通過網路經過LVS/F5負載均衡將資料傳送至閘道器；
- 閘道器接收到資料後進行公共協議解析，然後把解析後的資料發給Kafka，存放在原始資料Topic；
- 實時計算任務從原始資料Topic中讀取資料經過資料清洗後傳送至原始資料解析模組；
- 原始資料解析模組將解析出來的車輛的引數傳送至Kafka解析資料Topic。然後將解析後的資料傳送至報警判斷模組；
- 報警判斷模組根據已有規則進行預警，並將產生的結果分別傳送至Kafka的報警資料Topic，同時把解析後的資料傳送至當前狀態分析模組；
- 當前狀態分析模組對車輛當前狀態進行分析，如果狀態有變化則更新至Redis；
- 資料匯入模組非同步的將Kafka中的資料分別匯入HBase和HDFS；
- 離線計算則週期性地從HDFS中讀取資料進行各種報表分析和資料探勘；
- 使用者業務平臺和管理平臺可通過資料交換介面訪問TIZA STAR平臺數據。
5.2效能對比
表1是天澤資訊為某個大型工程機械集團做的平臺升級前後的效能指標對比情況，其中老平臺是傳統的基於IOE的解決方案，硬體環境包括IBM的小型機、EMC的儲存和Oracle RAC，新平臺是基於TIZA STAR的解決方案，使用的硬體是30臺左右X86架構伺服器，伺服器中自帶儲存。
該工程機械集團註冊終端數接近15萬，每個終端分佈在全國各地，每隔30秒傳送一條資料到平臺，上傳的資料包含工程機械裝置的位置、工況等資訊，該企業會對上報的資料進行分析，用於生產、經營的改善。
表1 效能指標對比
6.結束語
從研發到正式商用，耗時一年半， TIZA STAR經歷了三個階段：
第一個階段是封閉研發階段。TIZA STAR平臺最初的研發緣於公司一個客戶的迫切需求，原有的資料平臺隨著業務量擴大，效能捉襟見肘，經常出現宕機的情況，已經無法支撐正常的業務需求。為了更好的為客戶服務，我們決定對老平臺進行升級，目標是用業界最新的大資料技術來解決老平臺的效能問題。經過半年多的時間，我們釋出了新平臺，為了不影響客戶業務的正常開展，決定新老平臺同時執行。幾個月後，經過對比，新平臺在效能、高可用性、可運維性等方面都完勝老平臺。
第二個階段是拓展階段。TIZA STAR平臺在第一個客戶成功上線後，公司開始在物聯網的諸多領域推廣這個產品，但推廣的過程不是很順利。一方面，由於目前物聯網領域還沒有一個統一的標準，不同企業、不同物聯網終端都有自己的非標協議，我們在資料接入、協議解析、儲存方面都要進行不同程度的定製。另一方面，隨著上線的案例越來越多，我們原來的平臺架構也暴露出很多問題，針對這些問題，我們做了很多調整，比如將網路通訊元件由Mina替換成Netty，引入了KV資料庫，對Hadoop、Hbase和Kafka等進行了大版本的升級。在這個階段，雖然TIZA STAR平臺在不同的行業都有成功案例，但團隊做的還是很辛苦。於是把物聯網平臺進行封裝以滿足大多數場景的需求就顯得迫在眉睫，TIZA STAR的產品化就此應需而生。
第三個階段是產品化階段。在此階段，我們對資料接入、計算、儲存、交換等各個環節進行了封裝；累計開發了超過100種行業協議；抽象出了3個SDK，便於使用者基於平臺定製自己的新協議和業務處理模組；完善了監控和報警，形成一個完整的運維閉環；實現了安裝部署、管理和運維的介面化操作；提供了標準版和簡化版來滿足不同規模的客戶需求。經歷了半年多努力，TIZA STAR平臺終於實現了產品化。
在產品迭代的過程中，我們經歷過產品初次上線成功的喜悅，也經歷過產品拓展過程中的迷茫。專案組也從最初的五六人，到幾十個人初具規模的研發團隊。目前，TIZA STAR平臺正式註冊了商標，申請了軟體著作權和四項物聯網大資料領域的發明專利，產品在各個方面都有非常大的提升，希望今後可以給更多的企業提供物聯網平臺端解決方案。
2016年11月18日-20日，由CSDN重磅打造的年終技術盛會SDCC 2016中國軟體開發者大會將在北京舉行，大會秉承乾貨實料（案例）的內容原則，本次大會共設定了12大專題、近百位的演講嘉賓，並邀請業內頂尖的CTO、架構師和技術專家，與參會嘉賓共同探討電商架構、高可用架構、程式語言、架構師進階、微信開發、前端、平臺架構演進、基於Spark的大資料系統設計、自動化運維與容器實踐、高吞吐資料庫系統設計要領、移動視訊直播技術等。點選官網立即參會。