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