最近有不少質疑大資料的聲音，這些質疑有一定的道理，但結論有些以偏概全，應該具體問題具體分析。對大資料的疑問和抗拒往往是因為對其不了解，需要真正了解之後才能得出比較客觀的結論。
大資料是一個比較寬泛的概念，它包含大資料存儲和大資料計算，其中大資料計算可大緻分為計算邏輯相對簡單的大資料統計，以及計算邏輯相對複雜的大資料預測。下面分别就以上三個領域簡要分析一下：
第一，大資料存儲解決了大資料技術中的首要問題，即海量資料首先要能儲存下來，才能有後續的處理。是以大資料存儲的重要性是毫無疑問的。
第二，大資料統計是對海量資料的分析統計和輕度挖掘，例如統計海量使用者産品的日/月活躍度、使用者基于地區的分布、使用者曆史操作、營運側資料名額等，這些需要大資料計算平台的支援才能實作，對于擁有海量使用者的網際網路公司來說是不可或缺的技術。
第三，大資料預測領域才是争議最多的領域。事實上，預測必有誤差、必有小機率事件，大資料預測的背後是各種機器學習/模式識别等深度挖掘算法，這些算法隻是工具而已，用得好不好、恰不恰當還是要看應用的領域和使用者本身的能力。就像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型等類型，分别對搜尋排序、廣告算法、個性化推薦、安全檢測等應用提供支援。
這裡不得不提的是用在離線進行中的任務依賴控制系統。線上處理的各系統由于基本上是資料流驅動或者是事件驅動的，是以不需要顯式地設定各個任務的上下遊依賴關系，資料和事件的流式傳播即觸發了對應的計算。而對于離線處理，各個任務都是批量處理的方式，是以需要等上遊完成批量處理，下遊才能開始接着處理。現實中往往采用定時器+預估完成時間的方式來粗略地隐式地配置任務依賴，這樣帶來的問題是：
第一，預估時間不準确，造成時間的浪費或是無效的計算;
第二，上遊的延遲會引起下遊的連鎖反應，不具有彈性的容忍機制;
第三，随着任務增多，依賴關系配置和執行時間的預估變得越發複雜和不可控，而且任務遷移時很容易發生任務丢失和依賴失效的問題。
任務依賴控制系統正是為了解決這些問題而誕生的，它把所有任務的依賴拓撲關系放到全局統一的視圖中，将這些任務集中起來管理，可視化地配置它們的依賴關系，任務的遷移變得簡單可靠。同時，它負責監控每個任務的完成情況，如果成功完成，則馬上觸發下遊的任務;如果失敗，則進行重試，直到執行成功才觸發下遊任務，或者超過重試次數門檻值後進行告警。這種自動化的依賴觸發方式，縮短了整體業務耗時，并具有彈性容忍延時能力。
對于大資料處理來說，資料是素材，平台是工具。工欲善其事，必先利其器。大資料各個層次的平台已經日臻成熟，我們對其原理與架構也清晰明了。而海量資料中蘊含的巨大價值能否被有效挖掘，就看使用者們的功力了。
本文作者：佚名
來源：51cto