段為(中國移動通信集團廣東有限公司,廣州 510000)
?
大數(shù)據(jù)技術(shù)在物聯(lián)網(wǎng)服務(wù)平臺中的應(yīng)用
段為
(中國移動通信集團廣東有限公司,廣州 510000)
摘 要物聯(lián)網(wǎng)的出現(xiàn)及發(fā)展標志著大數(shù)據(jù)時代已經(jīng)來臨,大數(shù)據(jù)已滲透到我們生活的各個領(lǐng)域,引領(lǐng)并且改變著我們現(xiàn)有的生活方式。大數(shù)據(jù)不斷地從多樣化的物聯(lián)網(wǎng)傳感設(shè)備和應(yīng)用系統(tǒng)中產(chǎn)生,并且將會以更多、更復雜、更多樣化的方式持續(xù)增長。大數(shù)據(jù)的復雜化和格式多樣化,決定了物聯(lián)網(wǎng)服務(wù)平臺中針對大數(shù)據(jù)的服務(wù)場景和類型的多樣化,從而要求物聯(lián)網(wǎng)服務(wù)平臺必須融合大數(shù)據(jù)技術(shù)來應(yīng)對。
關(guān)鍵詞物聯(lián)網(wǎng);大數(shù)據(jù);Hadoop;Spark
1.1 物聯(lián)網(wǎng)催生了大數(shù)據(jù)
隨著物聯(lián)網(wǎng)的蓬勃發(fā)展,各種跨行業(yè)、領(lǐng)域的感知設(shè)備、終端能夠快速接入網(wǎng)絡(luò)并匯聚在一起。物聯(lián)網(wǎng)世界中大量的傳感器將物質(zhì)世界中形形色色的信息轉(zhuǎn)換成電信號后通過各類網(wǎng)絡(luò)傳送到上層應(yīng)用系統(tǒng),可以預(yù)見一種趨勢已經(jīng)形成,那就是海量的非結(jié)構(gòu)化數(shù)據(jù)將急速增長。這些數(shù)據(jù)量的增長并非是線性的,而是隨著越來越多的傳感器的研發(fā)、制造、投產(chǎn),數(shù)據(jù)量會呈現(xiàn)指數(shù)性的增長,這種趨勢是不可阻擋的。
1.2 大數(shù)據(jù)豐富了物聯(lián)網(wǎng)應(yīng)用
大數(shù)據(jù)時代下的物聯(lián)網(wǎng), 使得大數(shù)據(jù)價值得以體現(xiàn)。在物聯(lián)網(wǎng)技術(shù)的應(yīng)用中, 通過構(gòu)建智能建筑、數(shù)字化醫(yī)療、遙感勘測、智能運輸、環(huán)境監(jiān)測保護等手段, 可以通過大數(shù)據(jù)的收集, 通過云計算技術(shù)分析數(shù)據(jù), 把有用的數(shù)據(jù)挖掘出來形成有用的信息, 從而創(chuàng)造價值。世界頂級汽車公司, 正在使用的一項遙感技術(shù),有效識別車主身份, 避免豪車的被盜, 有效記憶識別開車人的駕姿, 判斷駕駛員是否在集中精神開車, 有效避免交通事故的發(fā)生。該技術(shù)通過對汽車座椅安裝一個傳感器, 記憶車主的重量、 正常駕駛的受力點以及相關(guān)的關(guān)鍵指標, 識別車主身份, 一旦駕駛員跟原有的數(shù)據(jù)不吻合, 汽車防盜系統(tǒng)會自動識別出危險, 并且自動通過無線技術(shù)把信息反饋到車主, 使得車主可以及時作出相應(yīng)的處理方式。大數(shù)據(jù)分析技術(shù)的發(fā)展和運用,使得各類物聯(lián)網(wǎng)應(yīng)用更加豐富多彩。
2.1 廣東移動物聯(lián)網(wǎng)服務(wù)平臺的數(shù)據(jù)特點
筆者負責建設(shè)的廣東移動物聯(lián)網(wǎng)服務(wù)平臺是一個基于GPRS企業(yè)接入網(wǎng)絡(luò)的網(wǎng)元、接口信令數(shù)據(jù)以及BOSS中的計費數(shù)據(jù)等,設(shè)計開發(fā)出行業(yè)客戶需要的服務(wù)組件,以開放、靈活的API接口方式向行業(yè)客戶提供物聯(lián)網(wǎng)服務(wù)的平臺。
圖1 物聯(lián)網(wǎng)平臺大數(shù)據(jù)技術(shù)選型
目前平臺每天接入數(shù)據(jù)量為1TB左右,數(shù)據(jù)量龐大,接口種類繁多,主要包括如下。
(1) 信令監(jiān)測平臺接口:通過FTP獲取專用APN卡、CMNet通道卡的網(wǎng)絡(luò)信令數(shù)據(jù),包括2G/3G卡信令數(shù)據(jù)(GN-CDR、用戶行為CDR及TCP建鏈CDR等)、4G卡信令數(shù)據(jù)(MME_CDR、HTTP_CDR、RTSP_CDR、VOIP_CDR等)。
(2)ESB系統(tǒng)接口:通過FTP、Webservice方式與接入ESB的話音網(wǎng)管、數(shù)據(jù)網(wǎng)管及資源管理系統(tǒng)對接,接入網(wǎng)元的網(wǎng)絡(luò)性能數(shù)據(jù),包括2G/3G網(wǎng)元(BSC、SGSN、GGSN)、4G網(wǎng)元(eNode B、MME、SGW、PGW),用戶在HLR中的APN配置信息、用戶實時的開關(guān)機信息以及2G/3G/4G基站的位置信息。
(3)BOSS接口:通過FTP獲取物聯(lián)網(wǎng)卡的業(yè)務(wù)訂購數(shù)據(jù),包括集團信息、產(chǎn)品信息及成員訂購信息。
(4)BI系統(tǒng)接口:通過FTP獲取2G/3G/4G物聯(lián)卡日流量信息。
(5)專網(wǎng)專號接口:通過WebService獲取專網(wǎng)專號的網(wǎng)絡(luò)數(shù)據(jù)以及業(yè)務(wù)狀態(tài)數(shù)據(jù)。
2.2 平臺引入大數(shù)據(jù)技術(shù)的必要性
平臺中數(shù)據(jù)的復雜性使得加快引入大數(shù)據(jù)技術(shù)已經(jīng)刻不容緩。針對海量數(shù)據(jù)的特點,雖然數(shù)據(jù)資源非常重要,但其中的數(shù)據(jù)信息很大程度上是冗余的,需要對數(shù)據(jù)進行清洗壓縮;再者,顆?;⒎墙Y(jié)構(gòu)化也是物聯(lián)網(wǎng)中大數(shù)據(jù)的特點,盡管這種特性的數(shù)據(jù)處理起來非常復雜,然而它們對數(shù)據(jù)的使用者來說至關(guān)重要,因此,解析非結(jié)構(gòu)數(shù)據(jù)也是不可忽視的重要環(huán)節(jié)。鑒于這些因素,非常有必要引入大數(shù)據(jù)技術(shù),通過統(tǒng)一的架構(gòu)設(shè)計,將非結(jié)構(gòu)化的數(shù)據(jù)變得結(jié)構(gòu)化,將不同系統(tǒng)之間不同結(jié)構(gòu)的數(shù)據(jù)盡可能地統(tǒng)一,從而使數(shù)據(jù)信息發(fā)揮更大的價值。
2.3 大數(shù)據(jù)技術(shù)的選型
物聯(lián)網(wǎng)服務(wù)平臺數(shù)據(jù)處理的流程包括采集,導入預(yù)處理,數(shù)據(jù)清洗與計算(提取、轉(zhuǎn)換和加載),存儲和管理數(shù)據(jù),數(shù)據(jù)統(tǒng)計分析,利用數(shù)據(jù)等階段。通過FTP接口聚集的信令數(shù)據(jù)、行業(yè)數(shù)據(jù)等更多的是非結(jié)構(gòu)化文檔,需要引入的大數(shù)據(jù)平臺和技術(shù),如分布式文件系統(tǒng)、分布式計算框架、非SQL數(shù)據(jù)、流計算技術(shù)等,通過這些技術(shù)可以加強非結(jié)構(gòu)數(shù)據(jù)的處理和集聚。技術(shù)選型如圖1所示。
3.1 總體架構(gòu)
通常認為物聯(lián)網(wǎng)包含信息感知、傳遞和處理這3個基本要素,相應(yīng)地,物聯(lián)網(wǎng)架構(gòu)也包含感知層、網(wǎng)絡(luò)層和應(yīng)用層3個基本層次。感知層利用傳感器(網(wǎng))、RFID等手段來實現(xiàn)信息采集和標識;網(wǎng)絡(luò)層利用現(xiàn)有的移動網(wǎng)、互聯(lián)網(wǎng)或其它專用網(wǎng),對采集來的信息進行傳輸和基礎(chǔ)處理,并提供公共管理服務(wù);應(yīng)用層對所感知的信息進行智能處理和決策后,實現(xiàn)各類應(yīng)用服務(wù)。物聯(lián)網(wǎng)服務(wù)平臺屬于應(yīng)用層,其內(nèi)外部數(shù)據(jù)的集成統(tǒng)一需要兩種數(shù)據(jù)(結(jié)構(gòu)化、非結(jié)構(gòu)化)和兩種技術(shù)平臺(關(guān)系型數(shù)據(jù)庫、大數(shù)據(jù)平臺)的巧妙融合,從而向上層應(yīng)用提供物聯(lián)網(wǎng)服務(wù),達到可運營、可管理的效果,使各種資源相互配合,實現(xiàn)效能最大化。整體架構(gòu)設(shè)計如圖2所示。
3.2 數(shù)據(jù)流組成
圖2 物聯(lián)網(wǎng)平臺大數(shù)據(jù)處理總體架構(gòu)
物聯(lián)網(wǎng)服務(wù)平臺數(shù)據(jù)分析基礎(chǔ)框架自數(shù)據(jù)源從下往上分為數(shù)據(jù)集成層、文件存儲層、編程模型層、數(shù)據(jù)存儲層以及數(shù)據(jù)分析層5層。數(shù)據(jù)流組成如下。
(1)數(shù)據(jù)采集與導入:①②。
(2)數(shù)據(jù)清洗與計算:實時分析——①③④、離線分析——⑤⑥。
(3)數(shù)據(jù)分析與統(tǒng)計:列存儲數(shù)據(jù)分析——⑦⑧⑨、數(shù)據(jù)倉庫數(shù)據(jù)分析——⑦⑧⑩ 。
3.3 數(shù)據(jù)技術(shù)應(yīng)用說明
(1)采用Hadoop分布式文件系統(tǒng)HDFS對非結(jié)構(gòu)化數(shù)據(jù)進行存儲。
(2)采用Hbase/Hive對半結(jié)構(gòu)化數(shù)據(jù)進行存儲。
(3)采用Oracle/Redis對結(jié)構(gòu)化數(shù)據(jù)分析結(jié)果進行存儲/緩存。
(4)采用Zookeeper作為分布式協(xié)調(diào)系統(tǒng)。
(5)采用Apache Flume-NG導入離線數(shù)據(jù)到Hadoop分布式文件系統(tǒng)HDFS。
(6)采用Storm/Apache Kafka進行實時數(shù)據(jù)處理。
(7)采用Apache Spark進行離線數(shù)據(jù)處理。
(8)采用SparkSQL/HiveOnSpark進行大數(shù)據(jù)統(tǒng)計分析。
4.1 數(shù)據(jù)導入預(yù)處理
由于采集數(shù)據(jù)的速度和數(shù)據(jù)處理的速度不一定同步,故不同方式接入的數(shù)據(jù)應(yīng)利用不同的技術(shù)導入。
對于實時的數(shù)據(jù)流數(shù)據(jù),現(xiàn)有的消息(隊列)系統(tǒng)能夠很好的導入,但存在未及時處理的數(shù)據(jù)不會寫到磁盤上,需要緩存在內(nèi)存的問題。Kafka正是為了解決以上問題而設(shè)計,它能夠很好地支持在線應(yīng)用。采集完成后,由集成子系統(tǒng)預(yù)處理導入到消息中間件,Kafka利用可靠高效的消息遞送機制幫助分布式系統(tǒng)進行平臺數(shù)據(jù)交換。
對于離線處理的文件則由Apache Flume-NG將需要離線分析的文件數(shù)據(jù)寫入Hadoop的分布式文件系統(tǒng)(HDFS)。Flume NG是一個分布式、可靠、可用的系統(tǒng),它能夠?qū)⒉煌瑪?shù)據(jù)源的海量數(shù)據(jù)進行高效收集、聚合、移動,最后存儲到一個中心化數(shù)據(jù)存儲系統(tǒng)中。Flume-NG中的Hdfs Sink的路徑名(對應(yīng)參數(shù)"hdfs.path",不允許為空)以及文件前綴(對應(yīng)參數(shù)"hdfs.filePrefix")支持正則解析,時間戳自動按時間創(chuàng)建目錄及文件前綴。采集到Hdfs中后,能有對應(yīng)的文件名,方便后續(xù)分析。
4.2 數(shù)據(jù)清洗與計算
由于數(shù)據(jù)源是由不同的系統(tǒng)定義,存在于不同的使用環(huán)境,來源于這些數(shù)據(jù)源的數(shù)據(jù)存在許多不一致的情形,所以在物聯(lián)網(wǎng)服務(wù)平臺數(shù)據(jù)集市構(gòu)建的過程中,需要對這些不一致或錯誤的數(shù)據(jù)進行轉(zhuǎn)換和清洗,以提高數(shù)據(jù)的質(zhì)量。數(shù)據(jù)清洗的過程是從大量原始數(shù)據(jù)中使用一系列邏輯判斷,檢查數(shù)據(jù)是否是符合數(shù)據(jù)集市的數(shù)據(jù),從而選擇做進一步保留或過濾的動作。物聯(lián)網(wǎng)服務(wù)平臺根據(jù)數(shù)據(jù)的時效性,分兩種清洗與計算模型:實時分析與離線分析。
實時分析主要處理同步頻率比較小的數(shù)據(jù),比如同步信令系統(tǒng)的網(wǎng)絡(luò)數(shù)據(jù),每5min同步一個數(shù)據(jù)文件,需要用流計算框架進行持續(xù)處理。Storm是Twitter的開源分布式流計算平臺。Storm通過簡單的API可以可靠地處理無界持續(xù)的流數(shù)據(jù),進行實時分析、持續(xù)計算、ETL處理等。Storm集群有兩種節(jié)點:主節(jié)點(Master)和工作節(jié)點(Worker)。主節(jié)點運行一個稱之為Nimbus的后臺程序,Nimbus負責在集群范圍內(nèi)分發(fā)代碼、為Worker分配任務(wù)和監(jiān)測故障。每個工作者節(jié)點運行一個稱為Supervisor的后臺程序,監(jiān)聽分配給它所在機器的工作,基于Nimbus分配給它的事情來決定啟動或停止工作者進程。Nimbus和Supervisor之間所有的協(xié)調(diào)工作是通過Zookeeper集群來進行的。物聯(lián)網(wǎng)服務(wù)平臺使用Storm實時分析信令文件數(shù)據(jù),抽取出用戶快照數(shù)據(jù)存儲到Redis內(nèi)存數(shù)據(jù)庫,同時把網(wǎng)絡(luò)軌跡數(shù)據(jù)保存到Hbase。相應(yīng)的處理程序會一直執(zhí)行,直至手動停止。
離線分析主要處理批量同步的數(shù)據(jù)以及較長時間間隔才清洗計算的大數(shù)據(jù)。Spark是UC Berkeley AMP lab所開源的類Hadoop MapReduce的通用的并行計算框架,它是基于內(nèi)存的迭代計算框架,適用于需要多次操作特定數(shù)據(jù)集的應(yīng)用場合。需要反復操作的次數(shù)越多,所需讀取的數(shù)據(jù)量越大,受益越大。物聯(lián)網(wǎng)服務(wù)平臺通過采用Spark計算框架迭代統(tǒng)計物聯(lián)卡的日流量,并累計得出物聯(lián)卡的月流量,然后將結(jié)果保存到Hbase。
4.3 數(shù)據(jù)存儲與管理
物聯(lián)網(wǎng)服務(wù)平臺數(shù)據(jù)存儲分文件存儲、半結(jié)構(gòu)化數(shù)據(jù)存儲、分析結(jié)果以及業(yè)務(wù)訂購數(shù)據(jù)存儲。文件存儲采用Hadoop分布式文件系統(tǒng)(HDFS),其運行于普通PC構(gòu)建的大規(guī)模集群之上,它隱藏了下層的負載均衡、冗余復制等實現(xiàn)細節(jié),對上層應(yīng)用程序提供一個統(tǒng)一的文件系統(tǒng)應(yīng)用程序接口。
Apache HBase是運行于HDFS頂層的NoSQL (Not Only SQL,泛指非關(guān)系型的數(shù)據(jù)庫)數(shù)據(jù)庫系統(tǒng),是一個架構(gòu)在Apache Hadoop上的開源的、分布式的、可橫向擴充的、一致的、低時延的、隨機訪問的非關(guān)系型數(shù)據(jù)庫。區(qū)別于Hive,HBase具備隨即讀寫功能,是一種面向列的數(shù)據(jù)庫。HBase以表的形式存儲數(shù)據(jù),表由行和列組成,列劃分為若干個列簇(Row Family)。Hbase按列存儲數(shù)據(jù),方便做數(shù)據(jù)壓縮,對某一列或者某幾列的查詢有非常大的I/O優(yōu)勢,查找速度快、可擴展性強、更容易進行分布式擴展。Hbase低時延隨機訪問特性如下。
(1)Hbase寫操作:1~3 ms,每個節(jié)點每秒1 000~10 000個寫操作。
(2)Hbase讀操作:內(nèi)存讀0~3 ms,硬盤讀10 ~30 ms,從內(nèi)存讀每個節(jié)點每秒10 000~40 000個讀操作。
(3)在表的任何位置都可以讀、寫或者插入數(shù)據(jù)。
(4)沒有順序?qū)懙南拗啤?/p>
Apache Hive是一個構(gòu)建于Hadoop(分布式系統(tǒng)基礎(chǔ)架構(gòu))頂層的數(shù)據(jù)倉庫。Hive可以看作是用戶編程接口,它本身不存儲和計算數(shù)據(jù);它依賴于HDFS(Hadoop分布式文件系統(tǒng))和MapReduce(一種編程模型,映射與化簡;用于大數(shù)據(jù)并行運算)。Hive最初的計算引擎為MapReduce,受限于其自身的Map+Reduce計算模式,以及不夠充分的大內(nèi)存利用,MapReduce的性能難以得到提升。于是Hive社區(qū)推出了Hive on Spark項目,將Spark作為繼MapReduce 和Tez之后Hive的第3個計算引擎。把Spark作為Hive的一個計算引擎,將Hive的查詢作為Spark的任務(wù)提交到Spark集群上進行計算。
Redis是一個開源的、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫。Redis在部分場合可以對關(guān)系數(shù)據(jù)庫起到很好的補充作用。Redis支持主從同步。數(shù)據(jù)可以從主服務(wù)器向任意數(shù)量的從服務(wù)器上同步,從服務(wù)器可以是關(guān)聯(lián)其它從服務(wù)器的主服務(wù)器。Redis的3個主要特點。
(1)Redis數(shù)據(jù)庫完全在內(nèi)存中,使用磁盤僅用于持久性。
(2)相比許多鍵值數(shù)據(jù)存儲,Redis擁有一套較為豐富的數(shù)據(jù)類型。
(3)Redis可以將數(shù)據(jù)復制到任意數(shù)量的從服務(wù)器。
物聯(lián)網(wǎng)服務(wù)平臺采用Hbase保存信令數(shù)據(jù)的網(wǎng)絡(luò)軌跡,該表的行鍵設(shè)計為:MD5(手機號碼)+時間戳+4位序號,對插入的數(shù)據(jù)設(shè)置好過期時間,由Hbase的數(shù)據(jù)過期功能自動刪除過期數(shù)據(jù)。其中,表的行鍵也保存到Redis中,業(yè)務(wù)分析需要訪問Hbase時,先通過Redis的行鍵快照來判斷是否有業(yè)務(wù)相關(guān)數(shù)據(jù),判斷有再根據(jù)行鍵訪問Hbase。
從Hbase或者Hive訪問到的半結(jié)構(gòu)化數(shù)據(jù),通過分析框架分析出結(jié)果后,也會保存到Redis和Oracle中,對于重復的查詢可以直接從內(nèi)存數(shù)據(jù)庫或關(guān)系數(shù)據(jù)庫中找到結(jié)果返回給用戶,提高查詢效率。
4.4 數(shù)據(jù)分析與統(tǒng)計
由于目前的大數(shù)據(jù)存儲Hbase/Hive都不是基于關(guān)系型數(shù)據(jù)庫的,所以傳統(tǒng)的通過SQL語言來操作數(shù)據(jù)的方式無法直接使用,如對于HDFS的數(shù)據(jù)是無法直接通過SQL來查詢的。大數(shù)據(jù)查詢和分析需要SQL on Hadoop技術(shù)。SQL on Hadoop是直接建立在Hadoop上的SQL查詢,既保證Hadoop性能,又利用SQL的靈活性。Hadoop解決方案對于SQL語言支持的深度與廣度各不相同,技術(shù)實踐方式也很多樣。最基本的工作是把傳統(tǒng)的SQL語言進行中間轉(zhuǎn)換后進行操作,如Hadoop中的Hive,就是把SQL(HiveQL,Hive的類SQL語句)編譯成MapReduce,從而讀取和操作HDFS上的數(shù)據(jù)。因為Hive會把SQL轉(zhuǎn)換為運行得較慢的MapReduce任務(wù),所以Hive的查詢性能通常很低。物聯(lián)網(wǎng)服務(wù)平臺采用的是高效的分布式計算系統(tǒng)Spark來實現(xiàn)數(shù)據(jù)分析與統(tǒng)計。Spark是使用Scala語言開發(fā)的一個開源SQL查詢引擎,它的設(shè)計目標是作為Hive的一個補充,同時在它自己的工作節(jié)點集合上執(zhí)行查詢而不是使用MapReduce。SparkSQL構(gòu)建在Apache Spark數(shù)據(jù)處理引擎之上,當內(nèi)存還足夠大的時候SparkSQL性能是最好的,如果內(nèi)存不夠裝下所有的數(shù)據(jù)時性能會下降,但還是會比Hive好很多。Spark SQL是支持在Spark中使用SQL的關(guān)系型查詢表達式。它的核心組件是一個新增的RDD類型SchemaRDD,它用一個Schema來描述行里面的所有列的數(shù)據(jù)類型,它就像是關(guān)系型數(shù)據(jù)庫里面的一張表。它可以從原有的RDD創(chuàng)建,也可以是Parquet文件,最重要的是它可以支持用HiveQL從Hive里面讀取數(shù)據(jù)。
對于物聯(lián)網(wǎng)服務(wù)平臺,數(shù)據(jù)量發(fā)展到數(shù)據(jù)倉庫階段,用Hive來構(gòu)建數(shù)據(jù)倉庫時,Hive on Spark可以用來支持數(shù)據(jù)挖掘。這里說的Hive on Spark是Hive跑在Spark上,用的是Spark執(zhí)行引擎,而不是MapReduce和Hive on Tez的道理一樣。從Hive 1.1版本開始,Hive on Spark已經(jīng)成為Hive代碼的一部分了。
物聯(lián)網(wǎng)服務(wù)平臺搭建在廣東移動網(wǎng)管網(wǎng)的OSS云上,共采用10臺服務(wù)器組建,除了安裝Oracle的服務(wù)器采用AIX系統(tǒng),其它服務(wù)器均是Redhat系統(tǒng)。其中,數(shù)據(jù)采集服務(wù)器2臺;導入處理服務(wù)器2臺;數(shù)據(jù)清洗與計算服務(wù)器2臺;數(shù)據(jù)存儲以及分布式協(xié)調(diào)服務(wù)器4臺。
其中,Hadoop分布式集群、Storm分布式集群、Kafka分布式集群采用Zookeeper作為分布式協(xié)調(diào)系統(tǒng)。Zookeeper分布式服務(wù)框架是Apache Hadoop的一個子項目,它主要是用來解決分布式應(yīng)用中經(jīng)常遇到的一些數(shù)據(jù)管理問題,如統(tǒng)一命名服務(wù)、狀態(tài)同步服務(wù)、集群管理、分布式應(yīng)用配置項的管理等。Zookeeper是分布式系統(tǒng)的高可靠的協(xié)調(diào)系統(tǒng),客戶端每次請求服務(wù)端都可以找到服務(wù)端集群中某一臺服務(wù)器,這樣服務(wù)端就可以向客戶端提供客戶端所需的服務(wù)。
物聯(lián)網(wǎng)服務(wù)平臺每天處理大約1 TB左右的原始數(shù)據(jù),含15億條記錄。清洗后的數(shù)據(jù),通過數(shù)據(jù)分析統(tǒng)計對客戶提供物聯(lián)網(wǎng)卡的公共管理服務(wù),如在數(shù)據(jù)軌跡(圖3)功能中,通過對信令話單數(shù)據(jù)的處理分析,實現(xiàn)對物聯(lián)網(wǎng)卡在某一時段上下行數(shù)據(jù)交互的查詢;在號碼打撈(圖4)功能中,也是通過對信令話單數(shù)據(jù)的處理分析,實現(xiàn)對某一APN在某一時段所有掉線號碼的快速查詢。
圖3 數(shù)據(jù)軌跡
圖4 號碼打撈
在未來10~20年中,物聯(lián)網(wǎng)面臨著大數(shù)據(jù)時代戰(zhàn)略性的發(fā)展機遇及挑戰(zhàn)。物聯(lián)網(wǎng)與大數(shù)據(jù)的握手,不僅會使物聯(lián)網(wǎng)產(chǎn)生更為廣泛的應(yīng)用,更會在大數(shù)據(jù)基礎(chǔ)上延伸出長長的價值產(chǎn)業(yè)鏈,所以,將大數(shù)據(jù)發(fā)展理念灌輸?shù)轿锫?lián)網(wǎng)發(fā)展的全過程中,能夠促進物聯(lián)網(wǎng)帶動大數(shù)據(jù)發(fā)展,而大數(shù)據(jù)的應(yīng)用又會加快物聯(lián)網(wǎng)的發(fā)展步伐。
The application of big data technology in Internet of things service platform
DUAN Wei
(China Mobile Group Guangdong Co., Ltd., Guangzhou 510000, China)
AbstractThe appearance and development of the Internet of things marks the arrival of the era of big data. Big data has penetrated into all areas of our lives, and is leading and changing our existing way of life. Big data are constantly generated from various sensing equipments of the Internet of things and applications system, and will sustainably grow in more complex and more diverse ways. The complexity and diversity of big data, which determines the variety of service situations and types of big data in Internet of things service platform, also demands that Internet of things service platform must integrate big data technologies to deal with.
KeywordsInternet of things; big data; Hadoop; Spark
收稿日期:2015-10-28
中圖分類號TN915
文獻標識碼A
文章編號1008-5599(2016)02-0008-06