主流大數(shù)據(jù)系統(tǒng)在后臺的層次角色及數(shù)據(jù)流向

最近有不少質(zhì)疑大數(shù)據(jù)的聲音，這些質(zhì)疑有一定的道理，但結(jié)論有些以偏概全，應(yīng)該具體問題具體分析。對大數(shù)據(jù)的疑問和抗拒往往是因為對其不了解，需要真正了解之后才能得出比較客觀的結(jié)論。

創(chuàng)新互聯(lián)是專業(yè)的梅州網(wǎng)站建設(shè)公司，梅州接單;提供做網(wǎng)站、網(wǎng)站制作,網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行梅州網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊,希望更多企業(yè)前來合作!

大數(shù)據(jù)是一個比較寬泛的概念，它包含大數(shù)據(jù)存儲和大數(shù)據(jù)計算，其中大數(shù)據(jù)計算可大致分為計算邏輯相對簡單的大數(shù)據(jù)統(tǒng)計，以及計算邏輯相對復(fù)雜的大數(shù)據(jù)預(yù)測。

下面分別就以上三個領(lǐng)域簡要分析一下：

第一，大數(shù)據(jù)存儲解決了大數(shù)據(jù)技術(shù)中的首要問題，即海量數(shù)據(jù)首先要能保存下來，才能有后續(xù)的處理。因此大數(shù)據(jù)存儲的重要性是毫無疑問的。

第二，大數(shù)據(jù)統(tǒng)計是對海量數(shù)據(jù)的分析統(tǒng)計和輕度挖掘，例如統(tǒng)計海量用戶產(chǎn)品的日/月活躍度、用戶基于地區(qū)的分布、用戶歷史操作、運營側(cè)數(shù)據(jù)指標(biāo)等，這些需要大數(shù)據(jù)計算平臺的支持才能實現(xiàn)，對于擁有海量用戶的互聯(lián)網(wǎng)公司來說是不可或缺的技術(shù)。

第三，大數(shù)據(jù)預(yù)測領(lǐng)域才是爭議最多的領(lǐng)域。事實上，預(yù)測必有誤差、必有小概率事件，大數(shù)據(jù)預(yù)測的背后是各種機器學(xué)習(xí)/模式識別等深度挖掘算法，這些算法只是工具而已，用得好不好、恰不恰當(dāng)還是要看應(yīng)用的領(lǐng)域和使用者本身的能力。就像C++語言這個工具，適合做后臺開發(fā)，不適合做網(wǎng)頁前端，有C++編程很牛的程序員，也有編程很差的程序員，不能因為存在編程差的程序員而否定C++。此外，大數(shù)據(jù)預(yù)測想要做到精準(zhǔn)，門檻非常高，所以有很多聲稱使用大數(shù)據(jù)預(yù)測的產(chǎn)品，實際效果往往不佳，給人們造成了大數(shù)據(jù)預(yù)測普遍不行的印象。由于門檻高，真正能掌握大數(shù)據(jù)預(yù)測能力，做到精準(zhǔn)的，目前只有很少數(shù)產(chǎn)品。

綜上所述，大數(shù)據(jù)存儲和大數(shù)據(jù)統(tǒng)計是海量用戶產(chǎn)品不可或缺的技術(shù)，而對于大數(shù)據(jù)預(yù)測技術(shù)，小概率事件必然出現(xiàn)，且并不是每個人都能運用得好。所以不能籠統(tǒng)地說大數(shù)據(jù)沒有用處，要看具體領(lǐng)域，以及產(chǎn)品背后的團(tuán)隊。

大數(shù)據(jù)經(jīng)過最近幾年的發(fā)展，它的基礎(chǔ)設(shè)施——各個大數(shù)據(jù)存儲和計算平臺已經(jīng)比較成熟，業(yè)界主流的大數(shù)據(jù)平臺在后臺的層次角色一般如下圖所示：

在物理層，根據(jù)不同的使用場景以及成本預(yù)算的考慮，會采用不同的硬件配置方案。對于自身容錯備份機制較好的大存儲系統(tǒng)，只需使用SATA硬盤即可;若所承載的平臺自身容災(zāi)機制較弱甚至是無，且數(shù)據(jù)比較重要，則可以使用RAID或者SAS硬盤。對于大部分存儲和計算平臺來說，網(wǎng)絡(luò)一般不是大的瓶頸，所以使用千兆網(wǎng)卡和交換機即可;對于內(nèi)部網(wǎng)絡(luò)吞吐量非常大，內(nèi)部網(wǎng)絡(luò)IO已經(jīng)成為瓶頸，并且時效性要求非常高的核心業(yè)務(wù)，可以使用萬兆網(wǎng)卡和交換機提高性能。

在計算性能上，近年來逐步興起與成熟的語音識別技術(shù)和深度學(xué)習(xí)技術(shù)，由于計算量異常巨大，需要依靠GPU加速或者是重核卡的加速才能在可容忍的時間內(nèi)完成計算，業(yè)界不少的專用集群都配備了GPU或是重核卡。隨著SSD的成本不斷下降，它成為對硬盤IO性能有高要求的應(yīng)用非常有吸引力的選擇。為了充分復(fù)用服務(wù)器的資源，將其空閑部分繼續(xù)加以利用，虛擬機技術(shù)成為了有效的解決方案;同時虛擬機的資源隔離機制，使得服務(wù)器的資源分配可以達(dá)到更精細(xì)的粒度，從而使資源分配更加合理和高效。業(yè)界不少大數(shù)據(jù)平臺，都搭建在了虛擬機集群之上。

此外，為了保證服務(wù)的高可用性，防止機架、機房甚至是城市的網(wǎng)絡(luò)、電源故障等突發(fā)災(zāi)情，重要的業(yè)務(wù)需要進(jìn)行多機房、多城市的容災(zāi)部署。

在軟件層面上，第一層首先是云存儲層。按時效性劃分，各個大數(shù)據(jù)存儲平臺一般分為離線存儲和在線存儲兩種類型。離線存儲用來對超大規(guī)模數(shù)據(jù)(一般PB以上)進(jìn)行持久性存儲，適用于數(shù)據(jù)訪問響應(yīng)時間要求低(秒級以上)的場景。在主流平臺里最典型的就是hadoop的HDFS。在線存儲用來對海量數(shù)據(jù)進(jìn)行實時的訪問，適用于在線服務(wù)場景或者是對數(shù)據(jù)訪問響應(yīng)時間有高要求的計算任務(wù)提供支持的場景。在線存儲不一定需要對數(shù)據(jù)進(jìn)行持久化，同時它既可以是原始數(shù)據(jù)，也可以只是緩存的數(shù)據(jù)。在主流的平臺里，Memcached是一個分布式內(nèi)存緩存系統(tǒng)，不提供持久化。Redis與Memcached類似，但是它提供了持久化能力及主從同步能力，所支持的數(shù)據(jù)類型和操作更加豐富。

以上兩者是典型的緩存系統(tǒng)，在中等數(shù)據(jù)規(guī)模下表現(xiàn)較好，對于更大數(shù)據(jù)規(guī)模就會比較吃力，這時就需要使用HBase或者Cassandra等支持實時場景的大容量存儲系統(tǒng)。同時，由于HBase和Cassandra支持超大規(guī)模數(shù)據(jù)的持久化存儲，它們也可以用在離線存儲領(lǐng)域。

大數(shù)據(jù)的計算層平臺按照時效性劃分，也分為離線計算和在線計算(或叫實時計算)兩種類型，而各個計算間的數(shù)據(jù)傳遞工作一部分由存儲系統(tǒng)完成，另一部分由數(shù)據(jù)管道系統(tǒng)(如消息隊列系統(tǒng)等)完成。離線計算平臺通常用來處理數(shù)據(jù)量巨大，耗時長的計算任務(wù)，適用于對大量數(shù)據(jù)的統(tǒng)計分析和深度挖掘。

典型的離線計算平臺有：

1、作為通用并行計算模型的hadoop MapReduce、Spark;

2、高性能并行計算的MPI;

3、數(shù)據(jù)倉庫式計算的Hive、Impala、Shark;

4、圖模型計算的Pregel、Bagel、GraphX等。

在線計算/實時計算平臺通常用來處理流式數(shù)據(jù)，適用于計算量一般較輕，且時效性需求高或永不間斷的計算場景。

常見的實時計算平臺有：Storm、S4、Spark Streaming等。消息隊列平臺一般用于上下游計算的數(shù)據(jù)銜接，特別是時效性要求較高的計算流程，每個計算步驟的輸出結(jié)果寫入消息隊列平臺后，下游計算可立即感知并啟動計算，縮短反應(yīng)時間。業(yè)界用得較多的平臺包括輕量級的Kestrel，以及重量級、容錯性好的Kafka。

業(yè)務(wù)邏輯層承載著各個業(yè)務(wù)具體的計算邏輯，一般來說有日志處理、離線分析、深度挖掘、分類聚類、預(yù)測建模等離線業(yè)務(wù)，也有實時挖掘、實時監(jiān)控等實時處理業(yè)務(wù)。

最外的服務(wù)層就是直接對外提供服務(wù)的各個業(yè)務(wù)的線上服務(wù)器集群。

位于后臺的各個大數(shù)據(jù)平臺，為了容災(zāi)、資源復(fù)用、例行維護(hù)的考慮，其服務(wù)訪問入口可能會發(fā)生變化，因此往往需要一個資源定位系統(tǒng)來獲取各個平臺當(dāng)前最新的服務(wù)訪問入口。通過資源定位系統(tǒng)提供的自動定位服務(wù)能力，各個平臺服務(wù)接口的遷移就可以對使用者透明。

在大數(shù)據(jù)各平臺的整體層次結(jié)構(gòu)中，最不可或缺的配套系統(tǒng)就是自動監(jiān)控運維系統(tǒng)。海量數(shù)據(jù)的處理，對存儲和計算的壓力都是非常巨大的，所以各個平臺出現(xiàn)硬件異常和軟件異常的概率急速上升，因此需要一套自動監(jiān)控運維系統(tǒng)來不斷監(jiān)控各個服務(wù)器的硬件狀況，操作系統(tǒng)層面的CPU、內(nèi)存、IO、網(wǎng)絡(luò)等各個指標(biāo)，大數(shù)據(jù)平臺層面的運作情況，業(yè)務(wù)邏輯層面的服務(wù)狀態(tài)等。

另外一方面，雖然各個大數(shù)據(jù)平臺都具有一定的容錯能力，但是并不是所有類型的錯誤都能夠容忍，并且當(dāng)出現(xiàn)了可容忍的小錯誤時，往往預(yù)示著更致命的錯誤隱藏在背后，若不及時發(fā)現(xiàn)，就很可能導(dǎo)致非常嚴(yán)重的后果。因此需要監(jiān)控運維系統(tǒng)將這些小問題提前預(yù)警出來，以便將事故扼殺在萌芽中。自動監(jiān)控運維系統(tǒng)一般具有系統(tǒng)狀態(tài)檢測、性能分析、監(jiān)控報警、自動發(fā)布與回滾等能力。尤其是自動發(fā)布與回滾能力，對于海量用戶的業(yè)務(wù)來說，是必不可少的，可以大大減輕運維的工作量，消除容易出錯的人工環(huán)節(jié)，增加業(yè)務(wù)的穩(wěn)定性。

前面給出了各個大數(shù)據(jù)系統(tǒng)在后臺的層次結(jié)構(gòu)，接下來介紹一下業(yè)務(wù)數(shù)據(jù)在各個平臺之間的流向關(guān)系。

如上圖所示，數(shù)據(jù)的來源一般有三種：第一種是線上的實時日志流;第二種是定期批量收集和更新的數(shù)據(jù);第三種是長期不變的靜態(tài)數(shù)據(jù)。前兩種數(shù)據(jù)通常發(fā)布到訂閱發(fā)布系統(tǒng)當(dāng)中，以通知下游消費者進(jìn)行消費。靜態(tài)數(shù)據(jù)一般直接保存在離線存儲系統(tǒng)中，供需要時訪問。

發(fā)布訂閱系統(tǒng)負(fù)責(zé)管理數(shù)據(jù)的發(fā)布和收集下游的訂閱需求，將數(shù)據(jù)分發(fā)給對應(yīng)的消費者，一部分?jǐn)?shù)據(jù)會發(fā)送到在線計算平臺，另一部分?jǐn)?shù)據(jù)會落入離線存儲平臺。發(fā)布訂閱系統(tǒng)可分為持久式和非持久式，可根據(jù)業(yè)務(wù)的特性選用。

對于在線處理部分，在線計算平臺所需的數(shù)據(jù)一部分來自從發(fā)布訂閱系統(tǒng)中獲取實時數(shù)據(jù)，另一部分來自在線存儲系統(tǒng)。在線計算平臺常見的計算類型有在線服務(wù)、流式計算、實時回饋等，分別服務(wù)于數(shù)據(jù)抓取、實時統(tǒng)計、實時監(jiān)控、在線分析、實時推薦等應(yīng)用。在線存儲平臺中的數(shù)據(jù)一般分為臨時緩存數(shù)據(jù)和持久化數(shù)據(jù)，這些數(shù)據(jù)通常來自在線計算平臺和離線計算平臺。在線存儲平臺承載的應(yīng)用有：KV緩存、數(shù)據(jù)庫緩存、流式數(shù)據(jù)、字典服務(wù)等。

對于離線處理部分，離線存儲平臺負(fù)責(zé)對文件、對象、結(jié)構(gòu)化數(shù)據(jù)的存儲，服務(wù)于日志、網(wǎng)頁、關(guān)系鏈、多媒體、字典、數(shù)據(jù)庫等應(yīng)用，它的數(shù)據(jù)來源非常豐富。而離線計算平臺的數(shù)據(jù)一般來自離線存儲和在線存儲，計算結(jié)果往往也寫回離線和在線存儲平臺。離線計算平臺上的計算分為IO密集型、計算密集型、迭代型、類SQL型等類型，分別對搜索排序、廣告算法、個性化推薦、安全檢測等應(yīng)用提供支持。

這里不得不提的是用在離線處理中的任務(wù)依賴控制系統(tǒng)。在線處理的各系統(tǒng)由于基本上是數(shù)據(jù)流驅(qū)動或者是事件驅(qū)動的，所以不需要顯式地設(shè)置各個任務(wù)的上下游依賴關(guān)系，數(shù)據(jù)和事件的流式傳播即觸發(fā)了對應(yīng)的計算。而對于離線處理，各個任務(wù)都是批量處理的方式，因此需要等上游完成批量處理，下游才能開始接著處理。

現(xiàn)實中往往采用定時器+預(yù)估完成時間的方式來粗略地隱式地配置任務(wù)依賴，這樣帶來的問題是：

第一，預(yù)估時間不準(zhǔn)確，造成時間的浪費或是無效的計算;

第二，上游的延遲會引起下游的連鎖反應(yīng)，不具有彈性的容忍機制;

第三，隨著任務(wù)增多，依賴關(guān)系配置和執(zhí)行時間的預(yù)估變得越發(fā)復(fù)雜和不可控，而且任務(wù)遷移時很容易發(fā)生任務(wù)丟失和依賴失效的問題。任務(wù)依賴控制系統(tǒng)正是為了解決這些問題而誕生的，它把所有任務(wù)的依賴拓?fù)潢P(guān)系放到全局統(tǒng)一的視圖中，將這些任務(wù)集中起來管理，可視化地配置它們的依賴關(guān)系，任務(wù)的遷移變得簡單可靠。同時，它負(fù)責(zé)監(jiān)控每個任務(wù)的完成情況，如果成功完成，則馬上觸發(fā)下游的任務(wù);如果失敗，則進(jìn)行重試，直到執(zhí)行成功才觸發(fā)下游任務(wù)，或者超過重試次數(shù)閾值后進(jìn)行告警。這種自動化的依賴觸發(fā)方式，縮短了整體業(yè)務(wù)耗時，并具有彈性容忍延時能力。

對于大數(shù)據(jù)處理來說，數(shù)據(jù)是素材，平臺是工具。工欲善其事，必先利其器。大數(shù)據(jù)各個層次的平臺已經(jīng)日臻成熟，我們對其原理與架構(gòu)也清晰明了。而海量數(shù)據(jù)中蘊含的巨大價值能否被有效挖掘，就看使用者們的功力了。

分享文章：主流大數(shù)據(jù)系統(tǒng)在后臺的層次角色及數(shù)據(jù)流向
轉(zhuǎn)載源于：http://muchs.cn/article0/soppio.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、面包屑導(dǎo)航、營銷型網(wǎng)站建設(shè)、微信小程序、定制開發(fā)、網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)