今天我們常說的大資料技術，其實起源於Google在2004年前後發表的三篇論文，也就是我們經常聽到的“三駕馬車”，分別是分散式檔案系統GFS、大資料分散式計算框架MapReduce和NoSQL資料庫系統BigTable。
你知道，搜尋引擎主要就做兩件事情，一個是網頁抓取，一個是索引構建，而在這個過程中，有大量的資料需要儲存和計算。這“三駕馬車”其實就是用來解決這個問題的，你從介紹中也能看出來，一個檔案系統、一個計算框架、一個數據庫系統。
現在你聽到分散式、大資料之類的詞，肯定一點兒也不陌生。但你要知道，在2004年那會兒，整個網際網路還處於懵懂時代，Google釋出的論文實在是讓業界為之一振，大家恍然大悟，原來還可以這麼玩。
因為那個時間段，大多數公司的關注點其實還是聚焦在單機上，在思考如何提升單機的效能，尋找更貴更好的伺服器。而Google的思路是部署一個大規模的伺服器叢集，透過分散式的方式將海量資料儲存在這個叢集上，然後利用叢集上的所有機器進行資料計算。 這樣，Google其實不需要買很多很貴的伺服器，它只要把這些普通的機器組織到一起，就非常厲害了。
當時的天才程式設計師，也是Lucene開源專案的創始人Doug Cutting正在開發開源搜尋引擎Nutch，閱讀了Google的論文後，他非常興奮，緊接著就根據論文原理初步實現了類似GFS和MapReduce的功能。
兩年後的2006年，Doug Cutting將這些大資料相關的功能從Nutch中分離了出來，然後啟動了一個獨立的專案專門開發維護大資料技術，這就是後來赫赫有名的Hadoop，主要包括Hadoop分散式檔案系統HDFS和大資料計算引擎MapReduce。
當我們回顧軟體開發的歷史，包括我們自己開發的軟體，你會發現，有的軟體在開發出來以後無人問津或者寥寥數人使用，這樣的軟體其實在所有開發出來的軟體中佔大多數。而有的軟體則可能會開創一個行業，每年創造數百億美元的價值，創造百萬計的就業崗位，這些軟體曾經是Windows、Linux、Java，而現在這個名單要加上Hadoop的名字。
如果有時間，你可以簡單瀏覽下Hadoop的程式碼，這個純用Java編寫的軟體其實並沒有什麼高深的技術難點，使用的也都是一些最基礎的程式設計技巧，也沒有什麼出奇之處，但是它卻給社會帶來巨大的影響，甚至帶動一場深刻的科技革命，推動了人工智慧的發展與進步。
我覺得，我們在做軟體開發的時候，也可以多思考一下，我們所開發軟體的價值點在哪裡？真正需要使用軟體實現價值的地方在哪裡？你應該關注業務、理解業務，有價值導向，用自己的技術為公司創造真正的價值，進而實現自己的人生價值。而不是整天埋頭在需求說明文件裡，做一個沒有思考的程式碼機器人。
Hadoop釋出之後，Yahoo很快就用了起來。大概又過了一年到了2007年，百度和阿里巴巴也開始使用Hadoop進行大資料儲存與計算。
2008年，Hadoop正式成為Apache的頂級專案，後來Doug Cutting本人也成為了Apache基金會的主席。自此，Hadoop作為軟體開發領域的一顆明星冉冉升起。
同年，專門運營Hadoop的商業公司Cloudera成立，Hadoop得到進一步的商業支援。
這個時候，Yahoo的一些人覺得用MapReduce進行大資料程式設計太麻煩了，於是便開發了Pig。Pig是一種指令碼語言，使用類SQL的語法，開發者可以用Pig指令碼描述要對大資料集上進行的操作，Pig經過編譯後會生成MapReduce程式，然後在Hadoop上執行。
編寫Pig指令碼雖然比直接MapReduce程式設計容易，但是依然需要學習新的指令碼語法。於是Facebook又釋出了Hive。Hive支援使用SQL語法來進行大資料計算，比如說你可以寫個Select語句進行資料查詢，然後Hive會把SQL語句轉化成MapReduce的計算程式。
這樣，熟悉資料庫的資料分析師和工程師便可以無門檻地使用大資料進行資料分析和處理了。Hive出現後極大程度地降低了Hadoop的使用難度，迅速得到開發者和企業的追捧。據說，2011年的時候，Facebook大資料平臺上執行的作業90%都來源於Hive。
隨後，眾多Hadoop周邊產品開始出現，大資料生態體系逐漸形成，其中包括：專門將關係資料庫中的資料匯入匯出到Hadoop平臺的Sqoop；針對大規模日誌進行分散式收集、聚合和傳輸的Flume；MapReduce工作流排程引擎Oozie等。
在Hadoop早期，MapReduce既是一個執行引擎，又是一個資源排程框架，伺服器叢集的資源排程管理由MapReduce自己完成。但是這樣不利於資源複用，也使得MapReduce非常臃腫。於是一個新專案啟動了，將MapReduce執行引擎和資源排程分離開來，這就是Yarn。2012年，Yarn成為一個獨立的專案開始運營，隨後被各類大資料產品支援，成為大資料平臺上最主流的資源排程系統。
同樣是在2012年，UC伯克利AMP實驗室（Algorithms、Machine和People的縮寫）開發的Spark開始嶄露頭角。當時AMP實驗室的馬鐵博士發現使用MapReduce進行機器學習計算的時候效能非常差，因為機器學習演算法通常需要進行很多次的迭代計算，而MapReduce每執行一次Map和Reduce計算都需要重新啟動一次作業，帶來大量的無謂消耗。還有一點就是MapReduce主要使用磁碟作為儲存介質，而2012年的時候，記憶體已經突破容量和成本限制，成為資料執行過程中主要的儲存介質。Spark一經推出，立即受到業界的追捧，並逐步替代MapReduce在企業應用中的地位。
一般說來，像MapReduce、Spark這類計算框架處理的業務場景都被稱作批處理計算，因為它們通常針對以“天”為單位產生的資料進行一次計算，然後得到需要的結果，這中間計算需要花費的時間大概是幾十分鐘甚至更長的時間。因為計算的資料是非線上得到的實時資料，而是歷史資料，所以這類計算也被稱為大資料離線計算。
而在大資料領域，還有另外一類應用場景，它們需要對實時產生的大量資料進行即時計算，比如對於遍佈城市的監控攝像頭進行人臉識別和嫌犯追蹤。這類計算稱為大資料流計算，相應地，有Storm、Flink、Spark Streaming等流計算框架來滿足此類大資料應用的場景。 流式計算要處理的資料是實時線上產生的資料，所以這類計算也被稱為大資料實時計算。
在典型的大資料的業務場景下，資料業務最通用的做法是，採用批處理的技術處理歷史全量資料，採用流式計算處理實時新增資料。而像Flink這樣的計算引擎，可以同時支援流式計算和批處理計算。
除了大資料批處理和流處理，NoSQL系統處理的主要也是大規模海量資料的儲存與訪問，所以也被歸為大資料技術。 NoSQL曾經在2011年左右非常火爆，湧現出HBase、Cassandra等許多優秀的產品，其中HBase是從Hadoop中分離出來的、基於HDFS的NoSQL系統。
我們回顧軟體發展的歷史會發現，差不多類似功能的軟體，它們出現的時間都非常接近，比如Linux和Windows都是在90年代初出現，Java開發中的各類MVC框架也基本都是同期出現，Android和iOS也是前腳後腳問世。2011年前後，各種NoSQL資料庫也是層出不群，我也是在那個時候參與開發了阿里巴巴自己的NoSQL系統。
事物發展有自己的潮流和規律，當你身處潮流之中的時候，要緊緊抓住潮流的機會，想辦法脫穎而出，即使沒有成功，也會更加洞悉時代的脈搏，收穫珍貴的知識和經驗。而如果潮流已經退去，這個時候再去往這個方向上努力，只會收穫迷茫與壓抑，對時代、對自己都沒有什麼幫助。
但是時代的浪潮猶如海灘上的浪花，總是一浪接著一浪，只要你站在海邊，身處這個行業之中，下一個浪潮很快又會到來。你需要敏感而又深刻地去觀察，略去那些浮躁的泡沫，抓住真正潮流的機會，奮力一搏，不管成敗，都不會遺憾。
正所謂在歷史前進的邏輯中前進，在時代發展的潮流中發展。通俗的說，就是要在風口中飛翔。
上面我講的這些基本上都可以歸類為大資料引擎或者大資料框架。而大資料處理的主要應用場景包括資料分析、資料探勘與機器學習。資料分析主要使用Hive、Spark SQL等SQL引擎完成；資料探勘與機器學習則有專門的機器學習框架TensorFlow、Mahout以及MLlib等，內建了主要的機器學習和資料探勘演算法。
此外，大資料要存入分散式檔案系統（HDFS），要有序排程MapReduce和Spark作業執行，並能把執行結果寫入到各個應用系統的資料庫中，還需要有一個大資料平臺整合所有這些大資料元件和企業應用系統。
————————————————
版權宣告：本文為CSDN博主「徐念安」的原創文章，遵循 CC 4。0 BY-SA 版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https：//blog。csdn。net/geekmubai/article/details/87299091
