1、大數據(big data)
什麼是大數據？wikipedia上面給出了這樣的定義：
In information technology, big data is a collection of data sets so large and complex that it becomes difficult to process using on-hand database management tools or traditional data processing applications.
大數據是指龐大而且複雜(如半結構化甚至是非結構化數據)的數據集，這些數據集很難由現有的數據管理工具或傳統的數據處理程序進行處理及操作等。通常，大數據的數據來源包括社交網絡、web服務器日誌、流量傳感器、衛星傳回的影像、銀行交易信息、web頁面內容、GPS軌跡信息、遙感汽車車行記錄、金融市場數據等。
那麼，多大規模的數據算得上是大數據？2008年，Google每天需要處理的數據量為20PB；2009年，Facebook有2.5PB的用戶數據，且以每天15TB的速度增長；eBay有6.5PB的用戶數據，且以每天50TB的速度增長；2011年，Yahoo!共有180到200PB的數據；2012年，Facebook每天生成的數據量為500GB。
分享之前我還是要推薦下我自己創建的大數據學習資料分享群 957205962，這是全國最大的大數據學習交流的地方，2000人聚集，不管你是小白還是大牛，小編我都挺歡迎，今天的源碼已經上傳到群文件，不定期分享乾貨，包括我自己整理的一份最新的適合2019年學習的前端資料和零基礎入門教程，歡迎初學和進階中的小夥伴
為了能更清晰地展示大數據的屬性，通常從volume(數據大小)、veloicy(變化頻度)和varity(數據源)三個不同的視角對其進行描述，這些角度有助於觀察、理解數據的自然特徵以及評估軟件平臺存儲及處理數據的能力等。
圖像來源：http://www.datameer.com/p_w_picpaths/img_bigdata.png
多數情況下，大數據需要根據實際需求進行處理後才能成為有用的信息，這個處理過程即所謂的大數據分析(Big Data analytics)。大數據分析能夠通過分析足量的、快速變化的結構化及非結構化數據集，從而完成更深層次的、更為完整的商業解析，並實現結果的可視化；例如，對社交網站或購物網站的訪問日誌進行分析以揭示用戶行為、精準廣告投放、用戶及主題建模、話題推薦、搜索引擎完成頁面排序及索引等。傳統的商業智能系統(business intelligence system)僅能用來有效地分析較小規模的結構化數據，對有著海量非結構化數據的大數據進行分析則非常困難。
Google為了高效存儲web爬蟲收集到的web頁面併為其建立搜索索引開發出了GFS和MapReduce，GFS用於存儲海量頁面數據，MapReduce則實現在集群的多個節點上並行完成數據處理及分析。Apache Hadoop是Google的大數據存儲及處理框架的開源實現，它包含HDFS和MapReduce兩個核心組件。
2、大數據處理與MapReduce
MapReduce在大數據問題的處理上採用了與傳統數據處理方式架構上幾乎完全不同的解決方案，它通過將需要處理的任務並行運行在集群中的多個商用計算機節點上的方式完成。MapReduce在實現大數據處理上有著多個基礎理論思想的支撐，雖然這些基礎理論甚至實現方法都未必是MapReduce所創，但它們卻由MapReduce採用獨特的方式加以利用而重新大放光彩。
傳統數據處理模型
MapReduce數據處理模型
(1) 向外擴展(Scale out)而非向上擴展(Scale up)：大數據的處理更適合採用大量低端商業服務器(scale out)而非少量高端服務器(scale up)。後者正是向上擴展的系統性能提升方式，它通常採用有著SMP架構的主機，然而有著大量的CPU插槽(成百上千個)及大量的共享內存(可以多達數百GB)的高端服務器非常昂貴，但其性能的增長卻非線性上升的，因此性價比很一般。而大量的低端商業服務器價格低廉、易於更換和伸縮等特性有效避免了向上擴展的敝端。
(2)假設故障很常見(Assume failures are common)：在數據倉庫架構級別，故障是不可避免且非常普遍的。假設一款服務器出故障的平均概率為1000天1次，那麼10000臺這種服務器每天出錯的可能性將達到10次。因此，大規模向外擴展的應用場景中，一個設計優良且具有容錯能力的服務必須能有效克服非常普遍的硬件故障所帶來的問題，即故障不能導致用戶應用層面的不一致性或非確定性。MapReduce編程模型能通過一系列機制如任務自動重啟等健壯地應付系統或硬件故障。
(3)將處理程序移向數據(Move processing to the data)：傳統高性能計算應用中，超級計算機一般有著處理節點(processing node)和存儲節點(storage node)兩種角色，它們通過高容量的設備完成互聯。然而，大多數數據密集型的處理工作並不需要多麼強大的處理能力，於是把計算與存儲互相分開將使得網絡成為系統性能瓶頸。為了克服計算如此類的問題，MapReduce在其架構中將計算和存儲合併在了一起，並將數據處理工作直接放在數據存儲的位置完成，只不過這需要分佈式文件系統予以支撐。
(4)順序處理數據並避免隨機訪問(Process data sequentially and avoid random access)：大數據處理通常意味著海量的數量難以全部載入內存，因而必須存儲在磁盤上。然而，機械式磁盤尋道操作的先天性缺陷使得隨機數據訪問成為非常昂貴的操作，因此避免隨機數據訪問並以順序處理為目的完成數據組織成為亟待之需。固態磁盤雖然避免了機械磁盤的某此缺陷，然而其高昂的價格以及並沒有消除的隨機訪問問題仍然無法帶來性能上的飛躍發展。MapReduce則主要設計用來在海量數據集上完成批處理操作，即所有的計算被組織成較長的流式處理操作，以延遲換取較大的吞吐能力。
(5)隱藏系統級別的細節：程序開發中，專業程序員公認的難題之一就是得同步追蹤短期記憶的各種細節，簡單如變量名，複雜如算法等；這會生較大的記憶負荷因為其需要程序員在開發過程中高度集中注意力，因此，後來才出現了各種各樣的開發環境(IDE)以幫助程序員在一定程度上解決諸如此類的問題。開發分佈式程序的過程更為複雜，程序員必須協調管理多個線程、進程甚至是主機之間的各種細節，而這其中，令人最為頭疼的問題是分佈式程序以無法預知的次序運行，以及以無法預知的模式進行數據訪問。這必然大大增加競爭條件、死鎖及其它臭名照著的問題出現的可能性。傳統上，解決此類問題的辦法無外乎使用底層設備如互斥量，並在高層應用類似“生產者-消費者”隊列的設計模式等；但基於這種方式設計的分佈式程序極難理解並且很難進行調試。MapReduce編程模型通過為其內部少量的幾個組件提供了一個簡單且精心定義的接口，從而將程序員與系統底層的處理細節隔離開來。MapReduce實現了“運算什麼”與“如何在多個節點並行運算”的隔離，前者可以程序員控制，後者則完全由MapReduce編程框架或運行時環境控制。
(6)無縫擴展(Seamless scalability)：數據密集型的處理應用中擴展算法(scalable algorithm)是其核心要件。一個理想的擴展算法應該滿足兩種特性：數據擴展一倍時其處理時長的增長幅度不會越過原處理所需時長的一倍；其次，集群規模擴大一倍時，其處理時長降低至少一倍。進一步地，理想的擴展算法還應該能夠處理種種規模如PB級別的數據，以及良好地運行於各種規模如數千節點的集群中，而且其無論運行時何種規模的集群、處理何種規模的數據，其程序並不需要做出修改，甚至連配置參數也不需要改動。然而，現實是殘酷地，這種理想算法並不存在，Fred Brook在其經典的“人月神話”中有一個斷言：為落後於預定計劃的項目增加程序員只會讓項目的完成時間進一步延後。這是因為並不能通過簡單地將複雜任務切分為多個小任務並將其分配出去並行完成來獲得線性擴展，也即是“一個婦女可以在10個月生出孩子，但十個婦女並不能在一個月內生出孩子來”。然而，這個斷言於今至少在某此領域已經被MapReduce打破——MapReduce最激動人心的特性之一就是其處理能力隨著節點的增加而線性增長，即集群規模增長N倍其處理相同規模數據的時長也會縮短N倍。
閱讀更多 微笑數據工程師 的文章
