何海詣，賈 宇，沈 宜，張家亮，郝渝江

（成都三零凱天通信實(shí)業(yè)有限公司，四川 成都 610041）

0 引 言

在互聯(lián)網(wǎng)信息爆炸的時代，數(shù)據(jù)系統(tǒng)面臨的信息處理量呈幾何級的增長，在動輒以TB、EB甚至更高量級范疇的數(shù)據(jù)量下，傳統(tǒng)信息系統(tǒng)基于簡單的網(wǎng)絡(luò)通信協(xié)議和關(guān)系型數(shù)據(jù)庫，并嚴(yán)格遵守ACID基本要素的設(shè)計思路已經(jīng)遠(yuǎn)遠(yuǎn)無法滿足形勢的需要，在這個背景之下，近年來大量研究人員專注于研究以滿足系統(tǒng)高吞吐量、良好的可伸縮性能及擴(kuò)展性、優(yōu)異的容錯性和魯棒性以及保證系統(tǒng)核心業(yè)務(wù)為主的系統(tǒng)框架設(shè)計，而NoSQL數(shù)據(jù)庫的強(qiáng)勢發(fā)展為此奠定了堅實(shí)的基礎(chǔ)。

在互聯(lián)網(wǎng)數(shù)據(jù)分析系統(tǒng)中，通常存在網(wǎng)絡(luò)爬蟲、文字識別、視圖像識別等功能平臺，而后將這些平臺產(chǎn)生的數(shù)據(jù)用于檢索、統(tǒng)計與展現(xiàn)等業(yè)務(wù)形態(tài)，因此如何將這些海量的數(shù)據(jù)高效且較低成本的進(jìn)行交互與整合，是本文闡述的重點(diǎn)。

1 關(guān)鍵技術(shù)研究

1.1 NoSQL的設(shè)計理念

在互聯(lián)網(wǎng)時代，信息需要的處理規(guī)模即便是在局部行業(yè)范疇至少都是在PB、EB或更高的量級范疇，包括了結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化的數(shù)據(jù)，在一個系統(tǒng)中，信息的交互與存儲是系統(tǒng)實(shí)現(xiàn)業(yè)務(wù)目標(biāo)的關(guān)鍵所在，當(dāng)系統(tǒng)在大數(shù)據(jù)環(huán)境下進(jìn)行工作時，如果采用傳統(tǒng)的設(shè)計思路，利用簡單的網(wǎng)絡(luò)通信協(xié)議再輔助關(guān)系數(shù)據(jù)庫管理系統(tǒng)來實(shí)現(xiàn)系統(tǒng)的業(yè)務(wù)邏輯，不僅成本高昂且不利于橫向擴(kuò)展。因此，在這互聯(lián)網(wǎng)蓬勃發(fā)展、信息爆炸的時代，NoSQL這一概念的全新思維注入，為解決這一問題提供了革命性的方案?；贜oSQL設(shè)計的支持海量數(shù)據(jù)管理的系統(tǒng)應(yīng)具有橫縱向的擴(kuò)展性滿足系統(tǒng)的適用性、極高的數(shù)據(jù)吞吐量用于滿足系統(tǒng)信息處理能力、良好的容錯性和魯棒性保證分布式系統(tǒng)保證核心業(yè)務(wù)的穩(wěn)定、可伸縮性用于滿足分布式系統(tǒng)的負(fù)載均衡和對部署環(huán)境的適配性以及相對較低的部署成本等。

NoSQL也稱Not only SQL，是對不同于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)庫系統(tǒng)的統(tǒng)稱，它具有非關(guān)系型、分布式、不保證ACID的數(shù)據(jù)庫設(shè)計模式等特征[1]。NoSQL主要用于超大規(guī)模數(shù)據(jù)的存儲與交互，這些數(shù)據(jù)存儲通常要求沒有固定的數(shù)據(jù)結(jié)構(gòu)，無需多余操作就可以橫向擴(kuò)展。

NoSQL典型遵守CAP理論和BASE原則[2]。CAP理論可簡單概述為：一個分布式系統(tǒng)不能同時滿足一致性、可用性和分區(qū)容錯性這三個需求，最多只能同時滿足兩個[3]。BASE原則告訴了我們做為分布式系統(tǒng)的適用性和局限性，首先基于“基本可用”的定義明確了系統(tǒng)部分功能模塊可能存在短時間處于不可用的狀態(tài)，這將會導(dǎo)致部分正在處理的數(shù)據(jù)可能會在該過程中丟失，但由于分布式系統(tǒng)的冗余部署的特性，只要不是所有該功能模塊的部署節(jié)點(diǎn)全部異常，則能保證系統(tǒng)核心業(yè)務(wù)的正常；其次在“軟狀態(tài)”的定義中明確指出了分布式系統(tǒng)的數(shù)據(jù)在一段時間內(nèi)基本不會同步，以異步為主，因此系統(tǒng)業(yè)務(wù)不能依賴數(shù)據(jù)的瞬時同步來進(jìn)行，也不能與信息的上下文邏輯關(guān)系進(jìn)行強(qiáng)耦合；在“最終一致”的定義中我們知道，由于分布式系統(tǒng)“軟狀態(tài)”的存在，在某一隨機(jī)時間點(diǎn)上系統(tǒng)中的數(shù)據(jù)不一定嚴(yán)格準(zhǔn)確，但是在基于策略同步完成后，系統(tǒng)的數(shù)據(jù)最終可以完成一致[4]?；谏鲜隼碚摵驮瓌t，基于NoSQL理念設(shè)計的系統(tǒng)通常應(yīng)用于強(qiáng)調(diào)系統(tǒng)的吞吐量，存儲的空間大小以及系統(tǒng)橫縱向的可擴(kuò)展性，同時在數(shù)據(jù)方面不要求嚴(yán)格同步，并能一定程度容忍數(shù)據(jù)丟失的風(fēng)險。因此，基于NoSQL所設(shè)計的系統(tǒng)通常不會應(yīng)用于與業(yè)務(wù)強(qiáng)耦合的場景，如企業(yè)OA系統(tǒng)、訂單管理系統(tǒng)、BOSS系統(tǒng)等，但卻非常適合針對大數(shù)據(jù)分析的功能系統(tǒng)，在這樣的系統(tǒng)中，業(yè)務(wù)的嚴(yán)謹(jǐn)性不是最重要的考量對象，但是對性能、系統(tǒng)的擴(kuò)展性與穩(wěn)定性等卻有非常嚴(yán)格的要求。

在性能上，由于NoSQL數(shù)據(jù)存儲系統(tǒng)不需要保證ACID，且數(shù)據(jù)庫結(jié)構(gòu)簡單，在面向大數(shù)據(jù)環(huán)境下可以取得非常優(yōu)異的性能，讀寫效率基本都是在毫秒級。在設(shè)計上，NoSQL數(shù)據(jù)庫面向的是分布式系統(tǒng)多客戶端對數(shù)據(jù)的高并發(fā)存儲吞吐處理以及基于大數(shù)據(jù)的存儲，因此具有靈活的部署策略與讀寫性能[5]；通過自由的模式定義方式，實(shí)現(xiàn)在海量數(shù)據(jù)的數(shù)據(jù)中進(jìn)行快速的訪問，另外，靈活的分布式體系結(jié)構(gòu)支持橫向可伸縮性和可用性，且對硬件的需求較低[6]。因此，基于NoSQL所構(gòu)建的系統(tǒng)對于信息的處理性能至少以萬次/秒來進(jìn)行統(tǒng)計，遠(yuǎn)遠(yuǎn)超過傳統(tǒng)意義上的系統(tǒng)處理性能；同時基于該理念所構(gòu)建的系統(tǒng)通常能夠在邏輯上輕易的通過疊加硬件的方式無限擴(kuò)展性能，一般只受限于部署環(huán)境中網(wǎng)絡(luò)吞吐量的限制，因此系統(tǒng)的生命周期通常很長，能夠極大的降低系統(tǒng)的平均成本；另外，由于基于NoSQL理念所構(gòu)建的系統(tǒng)的各個功能節(jié)點(diǎn)的信息耦合均依賴NoSQL數(shù)據(jù)庫的分發(fā)與存儲，且信息的處理互相獨(dú)立不耦合，因此可以非常簡單的進(jìn)行分布式冗余部署，極大的提高了系統(tǒng)核心業(yè)務(wù)的穩(wěn)定性。

1.2 NoSQL數(shù)據(jù)庫的研究

NoSQL數(shù)據(jù)庫大致可以分為如下四類[7]：

鍵值型數(shù)據(jù)庫：該類型數(shù)據(jù)庫的存儲方式是以Key-value的形式，使用HASH表進(jìn)行存儲，其映射方式是一對多的方式。由于其數(shù)據(jù)結(jié)構(gòu)簡單且不需要嚴(yán)格遵守ACID，因此該類型數(shù)據(jù)庫讀寫速度在所有NoSQL數(shù)據(jù)庫中是最快的，但缺點(diǎn)是僅能通過Key的完全匹配來進(jìn)行查詢，不能通過Value或其他組合方式來進(jìn)行復(fù)合搜索。

列存儲數(shù)據(jù)庫：該類型數(shù)據(jù)庫不同于傳統(tǒng)數(shù)據(jù)庫的存儲方式，在使用上也有較大的不同，其主要以列為數(shù)據(jù)局操作的主要對象。列存儲數(shù)據(jù)庫與鍵值型數(shù)據(jù)庫在部分概念上存在重疊，其主要區(qū)別在于列存儲數(shù)據(jù)庫可以基于列來進(jìn)行局部更新，這對于在大數(shù)據(jù)環(huán)境下的很多業(yè)務(wù)形態(tài)的實(shí)現(xiàn)具有極高的價值。

文檔型數(shù)據(jù)庫：該類型數(shù)據(jù)庫依賴文件來構(gòu)建對應(yīng)的數(shù)據(jù)結(jié)構(gòu)，通常使用JSON、XML等不嚴(yán)格定義的數(shù)據(jù)組裝方式來進(jìn)行，由于文件結(jié)構(gòu)自由化程度很高，因此文檔型數(shù)據(jù)庫幾乎可以適用于任何數(shù)據(jù)結(jié)構(gòu)，具有非常良好的適配性。

圖形數(shù)據(jù)庫：該類型數(shù)據(jù)庫利用圖論的三大基本要素（節(jié)點(diǎn)、關(guān)系、屬性）來進(jìn)行構(gòu)建，基于這三大屬性構(gòu)建數(shù)據(jù)間的關(guān)聯(lián)信息，是NoSQL數(shù)據(jù)庫中最接近關(guān)系數(shù)據(jù)庫的一種類型，但由于設(shè)計比較復(fù)雜，通常適用于大型社交網(wǎng)絡(luò)系統(tǒng)的構(gòu)建。

由于本系統(tǒng)是針對大數(shù)據(jù)環(huán)境下數(shù)據(jù)融合而進(jìn)行構(gòu)建的，由于功能相對單一，且不涉及復(fù)雜的業(yè)務(wù)控制邏輯，因此能夠快速進(jìn)行信息交互成為了本系統(tǒng)最主要的關(guān)注點(diǎn)，另外考慮到識別類型的橫向擴(kuò)展性，因此，NoSQL數(shù)據(jù)庫中鍵值型數(shù)據(jù)庫是本系統(tǒng)最優(yōu)的選擇，針對鍵值型數(shù)據(jù)庫再進(jìn)行細(xì)分，又大致可以分為key-document、key-colume以及key-value型數(shù)據(jù)庫，現(xiàn)在主流的鍵值型數(shù)據(jù)庫有BigTable、MongoDB、Redis、HBASE 等。

在本系統(tǒng)中，在大數(shù)據(jù)環(huán)境下我們需要構(gòu)建龐大的指令分發(fā)體系，由于Redis中的數(shù)據(jù)全部存儲在內(nèi)存當(dāng)中，因此讀寫速度奇快，官方測試數(shù)據(jù)顯示，單機(jī)系統(tǒng)下能進(jìn)行每秒約11萬次的讀操作，約8萬次的寫操作，同時，Redis支持發(fā)布-訂閱模式，因此我們選擇在系統(tǒng)中使用Redis作為高速消息隊列，為分布式系統(tǒng)內(nèi)部業(yè)務(wù)控制信令的傳輸提供支撐。

另外，由于系統(tǒng)主要目的在于數(shù)據(jù)動態(tài)關(guān)聯(lián)性的需求，且要求檢索速度非常快，因此需要選擇一款檢索速度快且按列進(jìn)行局部動態(tài)更新的數(shù)據(jù)庫。HBASE的表支持億級行存儲，并能支撐按列進(jìn)行動態(tài)更新，通過Row key進(jìn)行數(shù)據(jù)檢索達(dá)到毫秒級。因此特別適合在系統(tǒng)中用于大數(shù)據(jù)的快速檢索與匹配，且可對信息進(jìn)行長時間的冗余備份存儲，因此我們選擇HBASE做為系統(tǒng)中快速檢索匹配使用的數(shù)據(jù)庫。

2 系統(tǒng)設(shè)計

2.1 Redis內(nèi)存數(shù)據(jù)庫的部署設(shè)計

本文所論述的系統(tǒng)需要在大數(shù)據(jù)環(huán)境下收集分發(fā)龐大的數(shù)據(jù)指令，這些數(shù)據(jù)指令是系統(tǒng)完成正常業(yè)務(wù)流程的基礎(chǔ)，在前文中通過技術(shù)分析確定了使用Redis內(nèi)存數(shù)據(jù)庫做為系統(tǒng)各模塊之間消息傳遞的基礎(chǔ)，并從性能上確認(rèn)了該類型數(shù)據(jù)庫能夠滿足系統(tǒng)的設(shè)計需要，因此在本節(jié)中主要論述Redis內(nèi)存數(shù)據(jù)庫的部署方案以及使用策略以滿足系統(tǒng)通信的穩(wěn)定性及業(yè)務(wù)需求。

如圖1所示，系統(tǒng)部署的是擁有6個節(jié)點(diǎn)的Redis集群，采用主從冗余部署的方案保證通信的穩(wěn)定性。圖1中虛線表示Gossip通信協(xié)議，M(X)表示主節(jié)點(diǎn)，S(Y)表示從節(jié)點(diǎn)，Redis集群利用該協(xié)議建立了各個節(jié)點(diǎn)之間的兩兩聯(lián)系，并負(fù)責(zé)各個節(jié)點(diǎn)之間基于“最終一致性”原則實(shí)現(xiàn)數(shù)據(jù)的最終的同步，從而實(shí)現(xiàn)了一個全網(wǎng)狀拓?fù)浣Y(jié)構(gòu)的集群架構(gòu)。基于部署圖我們可以看出，當(dāng)任一節(jié)點(diǎn)出現(xiàn)異常下線時，系統(tǒng)通信不會受到任何的影響，當(dāng)系統(tǒng)出現(xiàn)兩個節(jié)點(diǎn)異常時，通信可用性可以通過計算1-(1/(2*6-1))得出其概率約為90%。在實(shí)際系統(tǒng)運(yùn)維過程中，當(dāng)Redis節(jié)點(diǎn)出現(xiàn)異常時通常會利用工程化機(jī)制使其自動恢復(fù)，同時輔助人工恢復(fù)的方式，因此在短時間出現(xiàn)1-2個節(jié)點(diǎn)異常時，基本不會影響到系統(tǒng)核心業(yè)務(wù)的運(yùn)轉(zhuǎn)，由此我們判斷使用該部署方式基本可以滿足系統(tǒng)使用需要[8]。

圖1 Redis集群部署圖

2.2 HBASE數(shù)據(jù)庫的部署設(shè)計

在本系統(tǒng)中存在業(yè)務(wù)數(shù)據(jù)關(guān)聯(lián)整合的需求，且要求檢索速度非?？欤瑫r由于視圖像識別類型會隨著系統(tǒng)的迭代更新而不斷增長，因此需要選擇一款檢索速度快且按列進(jìn)行局部動態(tài)更新的數(shù)據(jù)庫。HBASE的表支持億級行存儲，并能支撐按列進(jìn)行搜索，通過Row key進(jìn)行數(shù)據(jù)檢索達(dá)到毫秒級。因此特別適合在系統(tǒng)中用于大數(shù)據(jù)的快速檢索與匹配，且可對信息進(jìn)行長時間的冗余備份存儲，因此我們選擇HBASE做為系統(tǒng)中快速檢索匹配使用的數(shù)據(jù)庫。

系統(tǒng)中部署的HBASE結(jié)構(gòu)圖如圖2所示，通過冗余部署等價HBASE業(yè)務(wù)層避免單節(jié)點(diǎn)訪問故障。其中HMaster會為每個Region分配一個HRegionServer以供控制數(shù)據(jù)的I/O請求響應(yīng)，HMaster和HRegion Server都會在Zookeeper當(dāng)中進(jìn)行注冊，這樣Zookeeper可以得知HBASE環(huán)境中有效的節(jié)點(diǎn)狀態(tài)，當(dāng)Client端發(fā)起數(shù)據(jù)I/O請求時，首先從Zookeeper中獲得有效的HMaster的節(jié)點(diǎn)，并通過HMaster獲得此次I/O請求所對應(yīng)的有效HRegionServer節(jié)點(diǎn)地址，從而完成此次數(shù)據(jù)讀寫操作[9]。依賴于這個機(jī)制的實(shí)現(xiàn)，HBASE環(huán)境中只要有一個HMaster和HRegion Server存活，Client均可以順利完成數(shù)據(jù)讀寫的核心業(yè)務(wù)，同時，Zookeeper中注冊的各個節(jié)點(diǎn)會同步本節(jié)點(diǎn)數(shù)據(jù)吞吐量，使得HMaster可以方便的實(shí)現(xiàn)負(fù)載均衡的策略。

圖2 HBASE架構(gòu)

2.3 系統(tǒng)框架設(shè)計

系統(tǒng)框架圖如圖3所示，從圖中可以看出互聯(lián)網(wǎng)大數(shù)據(jù)融合系統(tǒng)面對的是多個第三方業(yè)務(wù)系統(tǒng)以及海量的業(yè)務(wù)數(shù)據(jù)信息，每個業(yè)務(wù)系統(tǒng)所需求的業(yè)務(wù)數(shù)據(jù)信息會根據(jù)產(chǎn)品形態(tài)的不同而有所區(qū)別，因此本系統(tǒng)不僅要支持對海量數(shù)據(jù)進(jìn)行處理，還需要具體區(qū)分信息所歸屬的業(yè)務(wù)系統(tǒng)，同時不增加如數(shù)據(jù)識別引擎等功能子系統(tǒng)的運(yùn)算負(fù)荷以及系統(tǒng)存儲空間。

本系統(tǒng)主要由任務(wù)管理模塊、Redis消息處理模塊、HBASE數(shù)據(jù)管理模塊以及業(yè)務(wù)數(shù)據(jù)匯聚模塊組成。

任務(wù)管理模塊主要負(fù)責(zé)處理系統(tǒng)任務(wù)數(shù)據(jù)的配置與管理。如上文中提到的本系統(tǒng)面對的是多個第三方業(yè)務(wù)系統(tǒng)，需要將數(shù)據(jù)基于業(yè)務(wù)系統(tǒng)進(jìn)行區(qū)分反饋，因此本系統(tǒng)構(gòu)建了一套任務(wù)體系用于關(guān)聯(lián)數(shù)據(jù)與業(yè)務(wù)系統(tǒng)之間的聯(lián)系，任務(wù)管理模塊則是該流程中關(guān)鍵的一個環(huán)節(jié)。該模塊通過從第三方業(yè)務(wù)系統(tǒng)中接收到任務(wù)的配置信息，將底層數(shù)據(jù)基于數(shù)據(jù)來源進(jìn)行分系統(tǒng)映射，通過任務(wù)ID與業(yè)務(wù)系統(tǒng)進(jìn)行關(guān)聯(lián)，并存儲在Mysql數(shù)據(jù)庫中以供系統(tǒng)內(nèi)部共享使用，由此確定了數(shù)據(jù)在進(jìn)入Solr分布式搜索引擎時的分庫依據(jù)，實(shí)現(xiàn)了業(yè)務(wù)數(shù)據(jù)的對應(yīng)關(guān)系。

Redis消息處理模塊主要負(fù)責(zé)接收功能子系統(tǒng)發(fā)送的業(yè)務(wù)數(shù)據(jù)消息，主要有互聯(lián)網(wǎng)數(shù)據(jù)采集信息、文字及視圖像識別信息等，同時，Redis消息處理模塊還將依據(jù)系統(tǒng)任務(wù)配置信息確定接收到的互聯(lián)網(wǎng)數(shù)據(jù)信息應(yīng)當(dāng)交付給哪一個功能子系統(tǒng)進(jìn)行處理。由于功能子系統(tǒng)在互聯(lián)網(wǎng)大數(shù)據(jù)環(huán)境下通過分布式部署而擁有極高的數(shù)據(jù)產(chǎn)生和處理能力，因此Redis數(shù)據(jù)庫使用集群部署方案，以6個節(jié)點(diǎn)建立兩兩之間的冗余備份以支撐子系統(tǒng)間的數(shù)據(jù)交互需求。

HBASE數(shù)據(jù)管理模塊主要負(fù)責(zé)建立以網(wǎng)頁為基礎(chǔ)的系統(tǒng)內(nèi)數(shù)據(jù)匯聚管理，通過在HBASE中建立網(wǎng)頁、網(wǎng)頁附屬信息、網(wǎng)頁資源信息及識別結(jié)果的數(shù)據(jù)表，實(shí)現(xiàn)信息在系統(tǒng)內(nèi)部的初次整合并與業(yè)務(wù)無關(guān)，該數(shù)據(jù)是之后業(yè)務(wù)數(shù)據(jù)匯聚的基礎(chǔ)。

圖3 大數(shù)據(jù)融合系統(tǒng)框架圖

業(yè)務(wù)數(shù)據(jù)匯聚模塊主要負(fù)責(zé)將HBASE中的數(shù)據(jù)基于業(yè)務(wù)需求寫入到Solr分布式搜索引擎中，每個業(yè)務(wù)系統(tǒng)唯一對應(yīng)一個Solr表，并依據(jù)業(yè)務(wù)形態(tài)形成獨(dú)立的表結(jié)構(gòu)，該表與數(shù)據(jù)的對應(yīng)關(guān)系來源于系統(tǒng)任務(wù)配置信息。

3 系統(tǒng)實(shí)現(xiàn)途徑

系統(tǒng)詳細(xì)流程圖如圖4所示，系統(tǒng)首先進(jìn)行初始化配置，主要是初始化通信接口及初始任務(wù)配置；當(dāng)業(yè)務(wù)系統(tǒng)下發(fā)了任務(wù)配置時，需要將該配置寫入任務(wù)映射數(shù)據(jù)庫以供后續(xù)使用。

圖4 大數(shù)據(jù)融合系統(tǒng)詳細(xì)流程

當(dāng)系統(tǒng)接收到互聯(lián)網(wǎng)采集數(shù)據(jù)信息后，首先需要判斷該數(shù)據(jù)所屬的任務(wù)關(guān)系，不同的數(shù)據(jù)所需要進(jìn)行的識別方案基于任務(wù)的關(guān)系可能會有區(qū)別，在確定數(shù)據(jù)的處理方案后，系統(tǒng)將采集到的數(shù)據(jù)信息規(guī)則化存儲到HBASE數(shù)據(jù)庫中，以網(wǎng)頁為單位建立初始的表結(jié)構(gòu)信息（如表1所示），等待后續(xù)識別信息的補(bǔ)充，同步的，分解的待識別網(wǎng)頁資源信息將下發(fā)到識別服務(wù)引擎進(jìn)行識別。

當(dāng)識別服務(wù)引擎返回結(jié)果之后，系統(tǒng)將識別結(jié)果信息與之前HBASE緩存的數(shù)據(jù)進(jìn)行關(guān)聯(lián)，形成以網(wǎng)頁為單位的全量數(shù)據(jù)倉庫，再基于該數(shù)據(jù)所對應(yīng)的任務(wù)信息將所需要的數(shù)據(jù)業(yè)務(wù)規(guī)則化，寫入Solr搜索引擎。

表1 HBASE數(shù)據(jù)關(guān)聯(lián)

最后，業(yè)務(wù)系統(tǒng)從Solr搜索引擎中讀取出需要的數(shù)據(jù)，并依據(jù)產(chǎn)品業(yè)務(wù)形態(tài)提供給最終用戶使用。

4 結(jié) 語

本文對一種基于NoSQL的互聯(lián)網(wǎng)大數(shù)據(jù)融合系統(tǒng)進(jìn)行了研究與實(shí)現(xiàn)，從整體上介紹了NoSQL數(shù)據(jù)庫的設(shè)計理念，說明了Redis和HBASE在本系統(tǒng)中的使用方式，并對系統(tǒng)的框架和實(shí)現(xiàn)途徑進(jìn)行了詳細(xì)說明。基于本文的研究結(jié)果，該系統(tǒng)已經(jīng)實(shí)際在互聯(lián)網(wǎng)大數(shù)據(jù)分析系統(tǒng)中做為數(shù)據(jù)調(diào)度中心來進(jìn)行使用，該系統(tǒng)融合了爬蟲集群、文字識別、視圖像識別及業(yè)務(wù)展示等多個功能，并能為多個客戶提供服務(wù)，互聯(lián)網(wǎng)大數(shù)據(jù)融合系統(tǒng)主要為整個系統(tǒng)提供數(shù)據(jù)分發(fā)與整合的作用，是整個系統(tǒng)的數(shù)據(jù)流中心。