主流大資料系統在後臺的層次角色及資料流向

最近有不少質疑大資料的聲音，這些質疑有一定的道理，但結論有些以偏概全，應該具體問題具體分析。對大資料的疑問和抗拒往往是因為對其不瞭解，需要真正瞭解之後才能得出比較客觀的結論。

大資料是一個比較寬泛的概念，它包含大資料儲存和大資料計算，其中大資料計算可大致分為計算邏輯相對簡單的大資料統計，以及計算邏輯相對複雜的大資料預測。下面分別就以上三個領域簡要分析一下：第一，大資料儲存解決了大資料技術中的首要問題，即海量資料首先要能儲存下來，才能有後續的處理。因此大資料儲存的重要性是毫無疑問的。第二，大資料統計是對海量資料的分析統計和輕度挖掘，例如統計海量使用者產品的日/月活躍度、使用者基於地區的分佈、使用者歷史操作、運營側資料指標等，這些需要大資料計算平臺的支援才能實現，對於擁有海量使用者的網際網路公司來說是不可或缺的技術。第三，大資料預測領域才是爭議最多的領域。事實上，預測必有誤差、必有小概率事件，大資料預測的背後是各種機器學習/模式識別等深度挖掘演算法，這些演算法只是工具而已，用得好不好、恰不恰當還是要看應用的領域和使用者本身的能力。就像C++語言這個工具，適合做後臺開發，不適合做網頁前端，有C++程式設計很牛的程式設計師，也有程式設計很差的程式設計師，不能因為存在程式設計差的程式設計師而否定C++。此外，大資料預測想要做到精準，門檻非常高，所以有很多聲稱使用大資料預測的產品，實際效果往往不佳，給人們造成了大資料預測普遍不行的印象。由於門檻高，真正能掌握大資料預測能力，做到精準的，目前只有很少數產品。

綜上所述，大資料儲存和大資料統計是海量使用者產品不可或缺的技術，而對於大資料預測技術，小概率事件必然出現，且並不是每個人都能運用得好。所以不能籠統地說大資料沒有用處，要看具體領域，以及產品背後的團隊。

大資料經過最近幾年的發展，它的基礎設施——各個大資料儲存和計算平臺已經比較成熟，業界主流的大資料平臺在後臺的層次角色一般如下圖所示：

在物理層，根據不同的使用場景以及成本預算的考慮，會採用不同的硬體配置方案。對於自身容錯備份機制較好的大儲存系統，只需使用SATA硬碟即可；若所承載的平臺自身容災機制較弱甚至是無，且資料比較重要，則可以使用RAID或者SAS硬碟。對於大部分儲存和計算平臺來說，網路一般不是最大的瓶頸，所以使用千兆網路卡和交換機即可；對於內部網路吞吐量非常大，內部網路IO已經成為瓶頸，並且時效性要求非常高的核心業務，可以使用萬兆網路卡和交換機提高效能。在計算效能上，近年來逐步興起與成熟的語音識別技術和深度學習技術，由於計算量異常巨大，需要依靠GPU加速或者是重核卡的加速才能在可容忍的時間內完成計算，業界不少的專用叢集都配備了GPU或是重核卡。隨著SSD的成本不斷下降，它成為對硬碟IO效能有高要求的應用非常有吸引力的選擇。為了充分複用伺服器的資源，將其空閒部分繼續加以利用，虛擬機器技術成為了有效的解決方案；同時虛擬機器的資源隔離機制，使得伺服器的資源分配可以達到更精細的粒度，從而使資源分配更加合理和高效。業界不少大資料平臺，都搭建在了虛擬機器叢集之上。此外，為了保證服務的高可用性，防止機架、機房甚至是城市的網路、電源故障等突發災情，重要的業務需要進行多機房、多城市的容災部署。

在軟體層面上，第一層首先是雲端儲存層。按時效性劃分，各個大資料儲存平臺一般分為離線儲存和線上儲存兩種型別。離線儲存用來對超大規模資料（一般PB以上）進行永續性儲存，適用於資料訪問響應時間要求低（秒級以上）的場景。在主流平臺裡最典型的就是hadoop的HDFS。線上儲存用來對海量資料進行實時的訪問，適用於線上服務場景或者是對資料訪問響應時間有高要求的計算任務提供支援的場景。線上儲存不一定需要對資料進行持久化，同時它既可以是原始資料，也可以只是快取的資料。在主流的平臺裡，Memcached是一個分散式記憶體快取系統，不提供持久化。Redis與Memcached類似，但是它提供了持久化能力及主從同步能力，所支援的資料型別和操作更加豐富。以上兩者是典型的快取系統，在中等資料規模下表現較好，對於更大資料規模就會比較吃力，這時就需要使用HBase或者Cassandra等支援實時場景的大容量儲存系統。同時，由於HBase和Cassandra支援超大規模資料的持久化儲存，它們也可以用在離線儲存領域。

大資料的計算層平臺按照時效性劃分，也分為離線計算和線上計算（或叫實時計算）兩種型別，而各個計算間的資料傳遞工作一部分由儲存系統完成，另一部分由資料管道系統（如訊息佇列系統等）完成。離線計算平臺通常用來處理資料量巨大，耗時長的計算任務，適用於對大量資料的統計分析和深度挖掘。典型的離線計算平臺有：作為通用平行計算模型的hadoop MapReduce、Spark；高效能平行計算的MPI；資料倉儲式計算的Hive、Impala、Shark；圖模型計算的Pregel、Bagel、GraphX等。線上計算/實時計算平臺通常用來處理流式資料，適用於計算量一般較輕，且時效性需求高或永不間斷的計算場景。常見的實時計算平臺有：Storm、S4、Spark Streaming等。訊息佇列平臺一般用於上下游計算的資料銜接，特別是時效性要求較高的計算流程，每個計算步驟的輸出結果寫入訊息佇列平臺後，下游計算可立即感知並啟動計算，縮短反應時間。業界用得較多的平臺包括輕量級的Kestrel，以及重量級、容錯性好的Kafka。

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

最外的服務層就是直接對外提供服務的各個業務的線上伺服器叢集。

位於後臺的各個大資料平臺，為了容災、資源複用、例行維護的考慮，其服務訪問入口可能會發生變化，因此往往需要一個資源定位系統來獲取各個平臺當前最新的服務訪問入口。通過資源定位系統提供的自動定位服務能力，各個平臺服務介面的遷移就可以對使用者透明。

在大資料各平臺的整體層次結構中，最不可或缺的配套系統就是自動監控運維繫統。海量資料的處理，對儲存和計算的壓力都是非常巨大的，所以各個平臺出現硬體異常和軟體異常的概率急速上升，因此需要一套自動監控運維繫統來不斷監控各個伺服器的硬體狀況，作業系統層面的CPU、記憶體、IO、網路等各個指標，大資料平臺層面的運作情況，業務邏輯層面的服務狀態等。另外一方面，雖然各個大資料平臺都具有一定的容錯能力，但是並不是所有型別的錯誤都能夠容忍，並且當出現了可容忍的小錯誤時，往往預示著更致命的錯誤隱藏在背後，若不及時發現，就很可能導致非常嚴重的後果。因此需要監控運維繫統將這些小問題提前預警出來，以便將事故扼殺在萌芽中。自動監控運維繫統一般具有系統狀態檢測、效能分析、監控報警、自動釋出與回滾等能力。尤其是自動釋出與回滾能力，對於海量使用者的業務來說，是必不可少的，可以大大減輕運維的工作量，消除容易出錯的人工環節，增加業務的穩定性。

前面給出了各個大資料系統在後臺的層次結構，接下來介紹一下業務資料在各個平臺之間的流向關係。

如上圖所示，資料的來源一般有三種：第一種是線上的實時日誌流；第二種是定期批量收集和更新的資料；第三種是長期不變的靜態資料。前兩種資料通常釋出到訂閱釋出系統當中，以通知下游消費者進行消費。靜態資料一般直接儲存在離線儲存系統中，供需要時訪問。

釋出訂閱系統負責管理資料的釋出和收集下游的訂閱需求，將資料分發給對應的消費者，一部分資料會傳送到線上計算平臺，另一部分資料會落入離線儲存平臺。釋出訂閱系統可分為持久式和非持久式，可根據業務的特性選用。

對於線上處理部分，線上計算平臺所需的資料一部分來自從釋出訂閱系統中獲取實時資料，另一部分來自線上儲存系統。線上計算平臺常見的計算型別有線上服務、流式計算、實時回饋等，分別服務於資料抓取、實時統計、實時監控、線上分析、實時推薦等應用。線上儲存平臺中的資料一般分為臨時快取資料和持久化資料，這些資料通常來自線上計算平臺和離線計算平臺。線上儲存平臺承載的應用有：KV快取、資料庫快取、流式資料、字典服務等。

對於離線處理部分，離線儲存平臺負責對檔案、物件、結構化資料的儲存，服務於日誌、網頁、關係鏈、多媒體、字典、資料庫等應用，它的資料來源非常豐富。而離線計算平臺的資料一般來自離線儲存和線上儲存，計算結果往往也寫回離線和線上儲存平臺。離線計算平臺上的計算分為IO密集型、計算密集型、迭代型、類SQL型等型別，分別對搜尋排序、廣告演算法、個性化推薦、安全檢測等應用提供支援。

這裡不得不提的是用在離線處理中的任務依賴控制系統。線上處理的各系統由於基本上是資料流驅動或者是事件驅動的，所以不需要顯式地設定各個任務的上下游依賴關係，資料和事件的流式傳播即觸發了對應的計算。而對於離線處理，各個任務都是批量處理的方式，因此需要等上游完成批量處理，下游才能開始接著處理。現實中往往採用定時器+預估完成時間的方式來粗略地隱式地配置任務依賴，這樣帶來的問題是：第一，預估時間不準確，造成時間的浪費或是無效的計算；第二，上游的延遲會引起下游的連鎖反應，不具有彈性的容忍機制；第三，隨著任務增多，依賴關係配置和執行時間的預估變得越發複雜和不可控，而且任務遷移時很容易發生任務丟失和依賴失效的問題。任務依賴控制系統正是為了解決這些問題而誕生的，它把所有任務的依賴拓撲關係放到全域性統一的檢視中，將這些任務集中起來管理，視覺化地配置它們的依賴關係，任務的遷移變得簡單可靠。同時，它負責監控每個任務的完成情況，如果成功完成，則馬上觸發下游的任務；如果失敗，則進行重試，直到執行成功才觸發下游任務，或者超過重試次數閾值後進行告警。這種自動化的依賴觸發方式，縮短了整體業務耗時，並具有彈性容忍延時能力。

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