數據采集處理項目技術方案(編輯修改稿)

　

【文章內容簡介】 條件來查 找數據。這些查詢對應于 SQL 查詢的功能，使 SQL 開發人員能夠很 直觀地編寫 D2B 查詢。l 支持查詢中的正則表達式。l l D2B 查詢結果存儲在提供過濾、聚合和排序等一系列功能的游標中，包 括 limit()、skip()、 sort()、count()、 distinct() 和 group()等等高級特性。l 高級聚合的 map/reduce 實現。l l 類似于 RDBMS 的屬性索引支持，可以直接在文檔的選定屬性上創建索引。l 使用提示、解釋計劃和分析的查詢優化特性。l 類似于 MySQL 的主/從復制，支持復制和故障恢復。l 基于集合的對象存儲，在需要規范化數據時允許參考查詢。l 通過自動分片功能水平擴展。l 高性能無爭用并發機制的即時更新。D2B 服務端可運行在 Linux、Windows 或 OS X 平臺，支持 32 位和 64 位應 用。推薦運行在 64 位平臺，因為 D2B 在 32 位模式運行時支持的最大文件尺寸 為 2GB。分布式數據庫（D2B） 集群示例圖 D2B 與關系型數據庫的邏輯結構對比:D2B關系型數據庫數據庫(database)數據庫(database)集合(collection)表(table)文檔(document)行(row)D2B 的性能指標：10 億約 600GB 以上（與每條記錄大小有關系，這里的數據：1Kb/條）寫（1 億,無索引）約 1500020000 條/s寫（1 億,有索引）約 10000 條/s寫（1 億：Replica Sets + Sharding 模式）約 60008000 條/s讀（1 億）約 80MB120MB/s讀（1 億）800010000 個查詢/s統計一個值（10 億）3s（復雜查詢）最大節點數量1024（理論上）測試環境的硬件配置：Intel Xeon E78837 2 路 16 核心,256GB 內存，15k SAS 16*600GB硬盤，RAID50；總共 12 臺設備；D2B 的架構模式：Replica Sets + Sharding。 負載均衡1)開源負載均衡軟件比較LVSNginxHAProxyLVS（Linux Virtual Server）可以實 現Linux平臺下的負載均衡, 提供 了含有三種IP負載均衡技術的IP 虛擬服務器軟件IPVS、基于內容請 求分發的內核Layer7交換機 KTCPVS和集群等功能Nginx是一款輕量級、高可用性的 Web服務軟件及反向代理軟件，基 于HTTP（第七層）應用代理服務 器。在國內大型的互聯網公司都有 使用。HAProxy是一款提供高可用性的 基于TCP（第四層）和HTTP（第 七層）應用的代理軟件。在國內大 型的互聯網公司都有使用。抗負載能力強、是工作在網絡4 層之上僅作分發之用，沒有流量的 產生，這個特點也決定了它在負載 均衡軟件里的性能最強的；配置性比較低，這是一個缺點 也是一個優點，因為沒有可太多配 置的東西，所以并不需要太多接 觸，大大減少了人為出錯的幾率；工作穩定，自身有完整的雙機 熱備方案，如LVS+Keepalived和 LVS+Heartbeat；無流量，保證了均衡器IO的性 能不會收到大流量的影響；軟件本身不支持正則處理，不 能做動靜分離；工作在網絡的7層之上，可以針 對應用做一些分流的策略，比 如針對域名、目錄結構，它的正則 規則比HAProxy更為強大和靈活；Nginx對網絡的依賴非常小，理 論上能ping通就就能進行負載功 能；Nginx安裝、配置、維護比較簡 單；可以承擔高的負載壓力且穩定， 一般能支撐超過幾萬次的并發量；Nginx可以通過端口檢測到服務 器內部的故障，不支持url來檢測；Nginx也可作為Web反向加速緩 存器；能夠補充Nginx的一些缺點比如 Session的保持，Cookie的引導等工 作；HAProxy對網絡的依賴非常小， 理論上能ping通就就能進行負載 功能；它跟LVS一樣，本身僅僅就只 是一款負載均衡軟件；單純從效率 上來講HAProxy更會比Nginx有更 出色，在并發處理上也是優于 Nginx；HAProxy安裝、配置、維護比 較簡單；可以承擔高的負載壓力且穩定， 一般能支撐超過幾萬次的并發量；建議用 Nginx（或者 HAProxy）作為負載均衡（反向代理）軟件配合硬件負 載均衡使用。究竟選擇 Nginx 還是 HAProxy 要看團隊對這兩種軟件的熟悉程度， 越熟悉，就能容易掌控，減少風險，我們團隊對 Nginx 非常熟悉，所以，這里我們推薦用 Nginx 作為軟件的反向代理工具。 數據采集1) 概述數據采集功能主要完成海量數據采集、上傳。 數據采集的來源有： 國家工商局、企業網站、百度、谷歌等。根據特定的數據源，不同應用，不同類型 的數據進行收集，并提供統一的數據采集方式，方便后臺數據集成、數據存儲。 數據采集結構圖：數據采集主要是由采集服務器，通過 HTTP 協議和 Restful 技術把數據上傳并緩存在 WEB 及消息服務器上，WEB 及消息服務器可以緩存一周的數據上傳 量，數據上傳后，再由消息處理服務進程（MPS）進程完成數據的最終清洗及格 式，并最終入庫存儲。臺標等非結構化數據存儲在分布式文件系統（S2DFS）中， log 或者行為等結構化數據存儲在分布式數據庫（MongonDB）中。參見如下數 據采集/存儲流程圖：DMQ 是一個分布式的消息服務平臺，提供的功能包括：配置維護、名字服 務、分布式同步、組服務等，能提供一種高性能、可靠的、可擴展的、分布式的、 可配置關鍵特性，DMQ 的核心技術特點：l 大容量堆內存和高可用性：假設你有 100 臺服務器, 并且每個節點有 2GB 的空間用于復制緩存,最終你獲得的總數據量的大小為 200GB， 每臺服務器僅僅是一個拷貝。相反，借助于分布式復制架構，可獲得 100GB 的備份虛擬堆內存，并且在網格中的任何位置都能訪問。如果 某臺服務器崩潰了, 網格只需要簡單地創建一份丟失數據的新副本， 并將它們放到另一臺服務器上。應用也無需再借助于一個巨大的獨立 數據庫來獲取數據以追求最大性能的 這是 80%以上的企業應用中 的瓶頸所在!l 擴展性：由于數據是均勻分布的，所以除了考慮到網絡上的組通訊， 根本就沒有必要來限制網格的大小網絡上的組通訊只要能夠發現 一個新的節點即可. 所有的數據獲取方式都是通過點對點通信，即節點之間直接進行通信，非常容易控制。 DMQ 的增加或者減少不需要 關閉整個服務。 簡單的添加刪除集群中的機器不會引發任何服務中斷。l 數據分布：DMQ 使用一致性哈希算法來決定集群中鍵值的存儲位置。 一致性哈希算法成本低，速度快并且最重要的是不需要額外的元數據 或者網絡通信就能確定鍵值的位置。 數據分布的目的是為了在集群 環境下保持足夠的狀態副本以使其具備可持續性和容錯性，但是又不 會有過多的副本而阻礙 DMQ 的可擴展性。l 原子性：一個 Update 操作不是成功就是失敗，不會有第三種狀態出現。l 順序性：在一個 DMQ 集群中，其中一臺 DMQ 服務器上的消息 a 在 消息 b 之前發布，那么在所有的 DMQ 服務器上的消息 a 都會在消息 b 之前被發布，DMQ 會保持一致順序。l 實時性：對于每個 Client，DMQ 集群中的所有服務器都會保持實時更 新制度，使得所有的服務視圖都會是最新的。l 分布式統一鏡像：Client 無論連接到集群中的哪一個 DMQ 集群節點 服務，都是得到同樣的鏡像視圖。l 可靠性：數據在內存中緩存了 2 份，任何一臺計算機故障，都不會造 成數據的丟失。2) 分布式消息管理架構圖：MPS1MPS3MPS5MPS7MPS9MPS MPS2MPS4MPS6MPS8MPS10統一的數據視圖心跳/同步Server1【備】（數據）Server2【主】（數據）Server3【備】（數據）Server4【備】（數據）數據網（電信、移動、聯通）智能終端智能終端智能終端智能終端智能終端智能終端智能終端智能終端DMQ 有以下幾種關鍵較色，每類較色的職責如下表格描述？角色名稱職責領導者(Leader)就是DMQ集群的老大，它不接受Client的請求，是管理其他DMQ服務的，只負責進行投票的發起和決議，最終更新狀態.追隨者(Follower)追隨者（Follower）的上司是領導者（Leader），參與領導者（Leader）發起的投票，向下是面向客戶端的交互，用于接收客戶端的請求和反 饋客戶端的結果。參與領導者（Leader）發起的投票。觀察者(Observer)觀察者可以接收客戶端連接，將寫請求轉發給領導者（Leader）節點。但是Observer不參加投票過程，只是同步領導者（Leader）的狀態。 Observer為系統擴展提供了一種方法。DMQ 的核心是原子廣播，這個機制保證了各個 Server 之間的同步,有兩種模 式，它們分別是恢復模式和廣播模式。恢復模式：一般是在服務剛啟動或者在領導者（Leader）崩潰后，開始進入 恢復模式，此時先就會開始選舉領導者（Leader），當領導者（Leader）被選舉出 來，并且追隨者（Follower）完成了和當前領導者（Leader）的狀態及數據同步以 后，恢復模式就結束了。廣播模式：恢復模式結束后，即領導者（Leader）已經和追隨者（Follower） 進行了狀態同步以后，他就可以開始廣播消息了，即進入廣播狀態。3) 分布式消息數據架構圖：上圖的 MM（Messages Manager）：消息數據管理者。通過嵌入式 nosql 內核完 成上百萬并發量的緩存數據來提供異步發布和訂閱。應用程序通過 JDBC/REST/Memcached 等符合業界標準接口完成集群中的消息緩存數據的操作， 集群成員之間也通過該接口完成成員之間的數據同步，狀探測步。4) 典型分布式消息平臺比較：由于常見的 RabbitMQ、ActiveMQ 和 ZeroMQ 消息中間件不具備分布式功能， 所以不在比較之列。數據采集中心面對的是高并發海量數據上傳，所以分布式消息平臺必須在‘數據接收224。數據緩存數據發布’整個過程保證數據的高性能吞吐、高可靠性、高擴展性、可維護性等屬性。注：*越多速速越快。3 大數據計算平臺 需求概述根據應用，這個項目數據量30T，企業數據量非常大，需要大量并發，網絡爬蟲爬取的企業數據信息存儲在數據中心。 此數據量跟企業記錄相關。 同時，需要對清洗后的記錄和計算好的推薦結果進行存儲，但是這些數據不放在數據中心。此項目之后會做成實時計算，需要用到流式計算的相關計算和調度。計算量很大，可以多部署 DCS 進程，提高計算并發度，作業調度也要采用分部署調度架構。 總體設計云數據采集中心與大數據計算平臺的關系是，云數據采集中心提供存儲和計 算資源，通過 API 的方式訪問資源，大數據計算平臺主要實現核心算法，包括圖 像匹配算法，挖掘算法，智能推薦算法，知識學習算法等等，也能夠通過 API的方式建立統計應用、智能推薦應用等等。大數據計算平臺 的需要的數據：包括網上實時爬取得、二次計算分析而獲取的等等，都通過通用接口存儲在云數據采集中心的分布式存儲平臺中（分布式文件 系統（S2DFS）、分布式數據庫（D2B））。計算時候，通過接口發起作業，由云 數據采集中心的作業調度服務進程（JSS）負責調度，由數據計算服務進程（DCS） 負責計算處理，并把結果反饋給大數據計算平臺的各個應用。根據 小節對 S2DFS分布式文件系統的詳細介紹，本章節就不重復敘述， 由于要增加新的存儲設