[0064]如圖3所示，根據(jù)本發(fā)明的實施例的數(shù)據(jù)質(zhì)量監(jiān)控系統(tǒng)300，包括:
[0065]數(shù)據(jù)收集模塊302:用于對客戶端(如手機App)產(chǎn)生的數(shù)據(jù)進行及時的收集；
[0066]數(shù)據(jù)質(zhì)量監(jiān)控模塊304:用于監(jiān)控數(shù)據(jù)量是否合理、手機app使用是否正常、服務器是否正常等。并及時對結(jié)果進行分析，做出對應的策略。
[0067]數(shù)據(jù)質(zhì)量報警模塊306:用戶在數(shù)據(jù)質(zhì)量不合理時，通過郵件或者短信等方式通知相應人員進行處理，保證手機App的正常使用。
[0068]質(zhì)量分析模塊308:用戶收集App產(chǎn)生的錯誤數(shù)據(jù)，并進行分析，及時發(fā)現(xiàn)App的缺陷，為開發(fā)人員升級維護做出參考依據(jù)，從而提高App的用戶體驗。
[0069]如圖4所示，根據(jù)本發(fā)明的一個實施例的數(shù)據(jù)收集與質(zhì)量監(jiān)控的流程，包括:
[°07°]步驟402，Kafka集群收集App發(fā)送的消息。
[0071 ]步驟404，HDFS(Hadoop Distributed File System，分布式文件系統(tǒng))存儲Kafka集群收集的消息。
[0072]步驟406，根據(jù)HDFS中存儲的數(shù)據(jù)進行產(chǎn)品質(zhì)量分析。然后存儲產(chǎn)品質(zhì)量分析，并得到分析結(jié)果，即質(zhì)量分析報表或在分析到數(shù)據(jù)異常時，進行報警(可通過郵件或短信等方式)。
[0073]步驟408，SparkStreaming對Kafka集群收集的數(shù)據(jù)進行分析，并存儲至數(shù)據(jù)庫，同時也得出質(zhì)量分析報表。其中，TachYon是一種分布式內(nèi)存文件系統(tǒng)。
[0074]在本發(fā)明的另一個實施例中，對數(shù)據(jù)進行收集和質(zhì)量監(jiān)控的流程包括:
[0075]1、啟動一個單節(jié)點的zookeeper(是一個分布式的、開放源碼的分布式應用程序協(xié)調(diào)服務)。
[0076]2、基于啟動的zookeeper搭建Kafka集群。
[0077]3、創(chuàng)建topics(主題)。
[0078]4、啟動consumer(消費者)&producer(生產(chǎn)者)，并進行訂閱。
[0079]5、Spark streaming接收consumer訂閱的topics消息。
[0080]6、通過spark streaming分析接收到的消息，并將分析后的結(jié)果保存到HDFS中。[0081 ] 7、質(zhì)量監(jiān)控:質(zhì)量監(jiān)控分為數(shù)據(jù)格式異常及數(shù)據(jù)量異常。數(shù)據(jù)格式異?？赡苡捎趥鬏敾蛘咂渌厥馇闆r導致的，一般系統(tǒng)設置一個容忍值，即這種數(shù)據(jù)比例非常小就忽略不計。另一種是數(shù)據(jù)量異常，異常監(jiān)測是基于歷史數(shù)據(jù)，通過周期性的規(guī)律以及近幾天的數(shù)據(jù)預測一個合理范圍，當超出范圍后會做出預警。在實踐過程中通過上述方案發(fā)現(xiàn)了由于Kafka原因?qū)е碌臄?shù)據(jù)量驟降，以及客戶端重復上傳導致的數(shù)據(jù)量太高的問題。
[0082]本發(fā)明上述實施例的技術方案通過Kafka和Spark Streaming技術實現(xiàn)了以下技術效果:
[0083]1、采用Kafka消息訂閱模式來傳送消息，保證分布式的高可靠性和高性能。并能具有一定的容錯性；
[0084]2、采用Spark Streaming實現(xiàn)實時計算；
[0085]3、能夠結(jié)合歷史質(zhì)量數(shù)據(jù)對當前的質(zhì)量數(shù)據(jù)進行分析；
[0086]4、能夠根據(jù)分析數(shù)據(jù)對用戶行為做出進一步的分析；
[0087]5、可以根據(jù)分析結(jié)果，改進App，提高用戶的粘性。
[0088]以上結(jié)合附圖詳細說明了本發(fā)明的技術方案，本發(fā)明提出了一種新的數(shù)據(jù)處理方案，提高了數(shù)據(jù)接收過程的可靠性，保證了數(shù)據(jù)接收過程的高性能要求，同時能夠?qū)邮盏降臄?shù)據(jù)質(zhì)量進行監(jiān)控，并且能夠進行攻擊預防，避免可能出現(xiàn)的惡性攻擊問題，保證數(shù)據(jù)處理裝置的正常穩(wěn)定運行。
[0089]以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領域的技術人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內(nèi)。
【主權(quán)項】
1.一種數(shù)據(jù)處理方法，其特征在于，包括: 構(gòu)建分布式的消息接收系統(tǒng)； 通過所述分布式的消息接收系統(tǒng)接收客戶端發(fā)送的數(shù)據(jù)； 對所述分布式的消息接收系統(tǒng)接收到的數(shù)據(jù)進行格式轉(zhuǎn)換處理，以得到格式化數(shù)據(jù)；對所述格式化數(shù)據(jù)進行格式檢測和數(shù)據(jù)量檢測，以對所述客戶端發(fā)送的數(shù)據(jù)進行質(zhì)量監(jiān)控。2.根據(jù)權(quán)利要求1所述的數(shù)據(jù)處理方法，其特征在于，對所述格式化數(shù)據(jù)進行格式檢測和數(shù)據(jù)量檢測，以對所述客戶端發(fā)送的數(shù)據(jù)進行質(zhì)量監(jiān)控的步驟，具體包括: 檢測所述格式化數(shù)據(jù)的格式是否異常； 確定所述格式化數(shù)據(jù)中格式異常的數(shù)據(jù)所占的比例； 在所述比例大于或等于預定值時，確定所述客戶端發(fā)送的數(shù)據(jù)出現(xiàn)異常，并進行報警提示。3.根據(jù)權(quán)利要求2所述的數(shù)據(jù)處理方法，其特征在于，對所述格式化數(shù)據(jù)進行格式檢測和數(shù)據(jù)量檢測，以對所述客戶端發(fā)送的數(shù)據(jù)進行質(zhì)量監(jiān)控的步驟，具體還包括: 統(tǒng)計對所述格式化數(shù)據(jù)的歷史接收量； 根據(jù)所述歷史接收量，判斷當前接收到的所述格式化數(shù)據(jù)的接收量變化率是否處于預定范圍內(nèi)； 在判定當前接收到的所述格式化數(shù)據(jù)的接收量變化率未處于所述預定范圍內(nèi)時，進行報警提示。4.根據(jù)權(quán)利要求1至3中任一項所述的數(shù)據(jù)處理方法，其特征在于，在通過所述分布式的消息接收系統(tǒng)接收客戶端發(fā)送的數(shù)據(jù)的步驟之前，還包括: 判斷任一客戶端在預定時間內(nèi)發(fā)送的數(shù)據(jù)量是否超過數(shù)據(jù)量閾值，若是，則拒絕接收所述任一客戶端發(fā)送的數(shù)據(jù)。5.根據(jù)權(quán)利要求1至3中任一項所述的數(shù)據(jù)處理方法，其特征在于，通過Sparkstreaming對所述分布式的消息接收系統(tǒng)接收到的數(shù)據(jù)進行格式轉(zhuǎn)換處理； 所述構(gòu)建分布式的消息接收系統(tǒng)的步驟，具體包括:構(gòu)建Kafka集群，以構(gòu)成所述分布式的消息接收系統(tǒng)。6.一種數(shù)據(jù)處理裝置，其特征在于，包括: 系統(tǒng)構(gòu)建單元，用于構(gòu)建分布式的消息接收系統(tǒng)； 數(shù)據(jù)接收單元，用于通過所述分布式的消息接收系統(tǒng)接收客戶端發(fā)送的數(shù)據(jù)； 格式化單元，用于對所述分布式的消息接收系統(tǒng)接收到的數(shù)據(jù)進行格式轉(zhuǎn)換處理，以得到格式化數(shù)據(jù)； 質(zhì)量監(jiān)控單元，用于對所述格式化數(shù)據(jù)進行格式檢測和數(shù)據(jù)量檢測，以對所述客戶端發(fā)送的數(shù)據(jù)進行質(zhì)量監(jiān)控。7.根據(jù)權(quán)利要求6所述的數(shù)據(jù)處理裝置，其特征在于，所述質(zhì)量監(jiān)控單元包括: 第一檢測單元，用于檢測所述格式化數(shù)據(jù)的格式是否異常； 確定單元，用于確定所述格式化數(shù)據(jù)中格式異常的數(shù)據(jù)所占的比例； 處理單元，用于在所述比例大于或等于預定值時，確定所述客戶端發(fā)送的數(shù)據(jù)出現(xiàn)異常，并進行報警提示。8.根據(jù)權(quán)利要求7所述的數(shù)據(jù)處理裝置，其特征在于，所述質(zhì)量監(jiān)控單元還包括: 統(tǒng)計單元，用于統(tǒng)計對所述格式化數(shù)據(jù)的歷史接收量； 第一判斷單元，用于根據(jù)所述歷史接收量，判斷當前接收到的所述格式化數(shù)據(jù)的接收量變化率是否處于預定范圍內(nèi)； 所述處理單元，還用于在所述第一判斷單元判定當前接收到的所述格式化數(shù)據(jù)的接收量變化率未處于所述預定范圍內(nèi)時，進行報警提示。9.根據(jù)權(quán)利要求6至8中任一項所述的數(shù)據(jù)處理裝置，其特征在于，還包括: 第二判斷單元，用于所述數(shù)據(jù)接收單元接收客戶端發(fā)送的數(shù)據(jù)之前，判斷任一客戶端在預定時間內(nèi)發(fā)送的數(shù)據(jù)量是否超過數(shù)據(jù)量閾值； 所述數(shù)據(jù)接收單元還用于，在所述第二判斷單元判定所述任一客戶端在預定時間內(nèi)發(fā)送的數(shù)據(jù)量是否超過所述數(shù)據(jù)量閾值時，拒絕接收所述任一客戶端發(fā)送的數(shù)據(jù)。10.根據(jù)權(quán)利要求6至8中任一項所述的數(shù)據(jù)處理裝置，其特征在于，所述格式化單元具體用于，通過Spark streaming對所述分布式的消息接收系統(tǒng)接收到的數(shù)據(jù)進行格式轉(zhuǎn)換處理； 所述系統(tǒng)構(gòu)建單元具體用于:構(gòu)建Kafka集群，以構(gòu)成所述分布式的消息接收系統(tǒng)。
【專利摘要】本發(fā)明提供了一種數(shù)據(jù)處理方法及數(shù)據(jù)處理裝置，其中，數(shù)據(jù)處理方法，包括：構(gòu)建分布式的消息接收系統(tǒng)；通過所述分布式的消息接收系統(tǒng)接收客戶端發(fā)送的數(shù)據(jù)；對所述分布式的消息接收系統(tǒng)接收到的數(shù)據(jù)進行格式轉(zhuǎn)換處理，以得到格式化數(shù)據(jù)；對所述格式化數(shù)據(jù)進行格式檢測和數(shù)據(jù)量檢測，以對所述客戶端發(fā)送的數(shù)據(jù)進行質(zhì)量監(jiān)控。本發(fā)明的技術方案提高了數(shù)據(jù)接收過程的可靠性，并且保證了數(shù)據(jù)接收過程的高性能要求，同時能夠?qū)邮盏降臄?shù)據(jù)質(zhì)量進行監(jiān)控。
【IPC分類】H04L29/06, H04L29/08
【公開號】CN105592151
【申請?zhí)枴緾N201510958830
【發(fā)明人】楊文俊
【申請人】暢捷通信息技術股份有限公司
【公開日】2016年5月18日
【申請日】2015年12月18日