在這篇文章裡，我們沿大數據發展時間線，從產品、行業、技術多角度討論其發展脈絡，究其發展承其脈絡大家可以學習、借鑑、並最終推測未來大致走向。
社區
Hadoop：開源大數據的基石
Hadoop 於 2005 年問世。之前，Doug Cutting 和 Mike Cafarella 已經拜讀過 Google 的 GFS 論文，並且自己“手工造輪子”實現自己的 Google 分佈式文件系統(最初稱為 Nutch 分佈式文件系統的 NDFS，後來改名為 HDFS 或 Hadoop 分佈式文件系統)。在 2004 年時候，Google 發表神作《MapReduce: Simplified Data Processing on Large Clusters》，上述兩位正在構架開源搜索引擎的大牛在考慮構建 Nutch webcrawler 的分佈式版本正好需要這套分佈式理論基礎。因此，上述兩位社區大牛基於 HDFS 之上添加 MapReduce 計算層。他們稱 MapReduce 這一層為 Hadoop，由於 Hadoop 核心原理均是基於上述兩篇論文，即 MapReduce 以及 GFS，其本身在技術理論上並無創新，更多是“山寨”實現。對於技術原理感興趣的看官可自行閱讀 Google 原作立刻了解各自原理，而對於 Hadoop 發展歷史感興趣的可以推薦閱讀下 Marko Bonaci 的《The history of Hadoop》。
Hadoop 技術相比於 Google 原作並無新意，甚至在 GFS 系統細節方面折扣實現不少。但筆者在此並無討論技術差異點的打算，我仍然回到老本行，從產品或者市場角度去探討 Hadoop 成功因素以及給我們的啟示。
在筆者看來，Hadoop 體系能夠成功，並在數據處理市場佔據一席之地，其初期核心因素就在於以下幾點：
時機。彼時互聯網 Web 2.0 風頭正緊，大量用戶與網站交互行為爆炸式增長，如何使用廉價的服務器(大量互聯網創業公司就是窮鬼，買不起大小型機)去分析各類網站數據的業務需求已經迫在眉睫。此時，大量 Top 互聯網公司有數據、有需求、有硬件，就缺一個廉價的數據分析系統。於是乎，開源、免費的 Hadoop 工具正好鑽入此類大數據市場空檔，迅速佔領了核心種子客戶群體，併為後續市場推廣奠定了群眾基礎。
開源。開源在開發者社區感染力不容小覷。Cutting 和 Cafarella 通過開源(以及 HDFS 的源代碼)確保 Hadoop 的源代碼與世界各地可以共享，最終成為 Apache Hadoop 項目的一部分。Google 此時並未意識到開放論文僅僅自我精神爽了一次：讓爾等看看我等技術影響力;實際上並未從長遠去思考大數據技術影響力構建以及更加長遠的雲計算商業生態構建。互聯網時代下，大量軟件被開發者以及背後的互聯網商業公司作為開源系統貢獻出來，整個互聯網開發者行業已經被開源社區完全洗腦，彷彿開源就是人類燈塔，閉源就是萬惡不赦。於是，此時，一個開源的、免費的、感覺挺符合互聯網精髓的大數據處理軟件出現在各大互聯網公司圈中，迅速在互聯網大數據處理領域觸達了這部分市場群體。
商業。早年開源軟件皆靠諸位開源運動人士在業界做社區用戶推廣，這波人本身毫無金錢彙報全靠一腔精神熱血。但本質上來說，人類以及人類社會都是趨利性的，沒有利益驅動的市場行為終究無法持續。因此，早期沒有找到合適盈利模式的開源軟件一直髮展緩慢，靠類似 Richard Stallman 類似開源黑客鬥士去做市場推廣，市場效率之低下。後期，在 Linux 商業公司紅帽逐步摸索出開源軟件變現模式後，其他開源軟件也紛紛仿效。Hadoop 一時間背後迅速成立三家公司，包括 Cloudera、HotonWorks、MapR，這些公司盈利潛力完全都依賴於 Hadoop 開源生態的規模，因此，三家公司都會盡不遺餘力地推進 Hadoop 生態發展，反過來促進了 Hadoop 整個生態用戶的部署採用率。到大數據市場更後期的時代，其商業競爭更趨激烈。以 Kafka、Spark、Flink 等開源大數據軟件為例，在各自軟件提交到 Apache 基金會之時創始人立刻創辦商業公司，依靠商業推進開源生態建設，同時通過收割生態最終反哺商業營收。
最終 Hadoop 在生態建設上獲得了巨大的成功，其影響力在開源業界開創了一個嶄新領域：大數據處理可見一斑。我們從如下幾個維度來看看 Hadoop 生態成功的各類體現：
Hadoop 的技術生態
不得不承認，Hadoop 有技術基座的先天優勢，特別類似 HDFS 的存儲系統。後續各大 Hadoop 生態圈中的大數據開源軟件都多多少少基於 Hadoop 構建的技術底座。故而，大量大數據生態後起之秀基本均源於 Hadoop，或者利用 Hadoop 作為其基礎設施，或者使用 Hadoop 作為上下游工具。此類依存共生關係在整個 Hadoop 社區生態已蔚然成風，越多大數據開源系統加入此生態既收割現有大數據生態客戶流量，同時亦添加新功能進入 Hadoop 社區，以吸引更多用戶使用 Hadoop 生態體系。就好比淘寶買家賣家相互增長，形成商業互補，相輔相成。
Hadoop 的用戶生態
前文已述，優秀的開源(免費)系統確實非常容易吸收用戶流量、提升用戶基數，這個早已是不爭事實。通過開源 (免費) 的系統軟件鋪開發者市場、培養開發者習慣、籌建開發者社區，早已是開源軟件背後商業公司的公開市場打法，這就類似通過免費 APP 培養海量客戶技術，最終通過收割頭部客戶實現營收。或者好比一款遊戲，大部分可能均是免費玩家，但用戶基數達可觀規模之時，一定湧現出不少人民幣玩家，並通過他們實現整體營收。當前風頭正緊的開源大數據公司，包括 DataBricks(Spark)、Confluent(Kafka)、Ververica(Flink)莫不如此。在開源軟件競爭激烈日趨激烈的環境下，其背後若無商業公司資金支撐，其背後若無市場商業團隊運營支撐，當年寫一個優秀的開源軟件就憑”酒香不怕巷子深“的保守概念，現如今早已推不動其軟件生態圈發展。試看當前大數據生態圈，那些日暮西山、愈發頹勢的開源軟件，其背後原因多多少少就是缺乏商業化公司的運作。
Hadoop 的商業生態
大量商業公司基於 Hadoop 構建產品服務實現營收，雲計算公司直接拉起 Hadoop 體系工具作為大數據雲計算服務，軟件集成商通過包裝 Hadoop 引擎提供客戶大數據處理能力，知識機構(包括書籍出版社、Hadoop 培訓機構)通過培訓 Hadoop 開發運維體系實現營收和利潤，上述種種商業行為均基於 Hadoop 體系實現商業利潤。整個 Hadoop 開創了開源大數據的新概念，並由此養活大數據行業數不勝數的參與者。這波參與者享受了開源 Hadoop 的收益，同時也在為 Hadoop 貢獻知識。
如果說 Google 三篇論文發表後敲開了大數據時代的理論大門，但論文絕逼異常高冷、不接地氣、無法落地投產。真正人人皆用大數據的時代是直到開源社區提供了成熟的 Hadoop 軟件生態體系之後，我們才可以說企業界方才逐步進入到大數據時代。可以說，當代 Hadoop 的誕生，為企業大數據應用推廣起到了決定性作用。
生態：大數據的林林總總
Google 三家馬車叩開了大數據理論大門，而 Hadoop 才真正開啟了行業大數據時代。前文已述，Hadoop 已經早已超出 MapReduce(計算模型)和 HDFS(分佈式存儲)軟件範疇。當前早已成為 Hadoop 大數據代名詞，指代大數據社區生態，無數號稱新一代、下一代的大數據技術無不構建在 Hadoop 生態基石之上。下文我們分維度重點討論基於 Hadoop 生態之上的各式各樣大數據組件抽象。
高階抽象：讓人人成為大數據用戶
上篇道，數據庫兩位大拿 David J. DeWitt 以及 Michael Stonebraker 十分不待見 MapReduce 論文所訴理論，基本上是羽檄爭執、口誅筆伐。其討伐重點之一便是使用 MapReduce 而拋棄 SQL 抽象，將實際問題的解決難度轉嫁用戶非正確的系統設計方式。同樣，這個批判確為 MapReduce 之缺陷，凡是正常人類絕逼感同身受。一個普普通通數據處理業務，用 SQL 表達多則百行、少則數行，熟練的數據工程師多則數小時少則數分鐘即可完成業務開發，輕鬆簡便。而一旦切換到 MapReduce，需要將 SQL 的直接業務表達子句換成底層各種 Map、Reduce 函數實現，少則數千行多達數萬行，導致整個數據開發難度陡增，業務開發效率抖降。
針對上述兩個問題，Google 和 Hadoop 兩條技術分別做出各自的技術方案：
Google 公司的 FlumeJava
Google 嘗試提供高階的 API 去描述數據處理 Pipeline，進而解決上述業務表達難題。FlumeJava 通過提供可組合的高級 API 來描述數據處理流水線，從而解決了這些問題。這套設計理念同樣也是 Apache Beam 主要的抽象模型，即 PCollection 和 PTransform 概念，如下圖：
這些數據處理 Pipeline 在作業啟動時將通過優化器生成，優化器將以最佳效率生成 MapReduce 作業，然後交由框架編排執行。整個編譯執行原理圖如下圖。
FlumeJava 更清晰的 API 定義和自動優化機制，在 2009 年初 Google 內部推出後 FlumeJava 立即受到巨大歡迎。之後，該團隊發表了題為《Flume Java: Easy, Efficient Data-Parallel Pipelines》的論文，這篇論文本身就是一個很好的學習 FlumeJava 的資料。
開源生態的 Hive
開源社區受眾更廣，其使用者更多，因此實際上開源社區對於開發效率提升訴求更高。但 Hadoop 社區似乎對於 SQL 情有獨鍾，更多將精力投入到 SQL-On-Hadoop 類的工具建設之中，最終，社區吸收 Facebook 提交給 Apache 基金會的 Hive，並形成了業界 SQL-On-Hadoop 的事實標準。
對於 Hive 而言，其官網特性說明充分闡釋了 Hive 的作為一套 Hadoop MapReduce 之上的 DSL 抽象之價值和特性：
Hive 是基於 Hadoop 的一個數據倉庫工具，可以將結構化的數據文件映射為一張數據庫表，並提供完整的 sql 查詢功能，可以將 sql 語句轉換為 MapReduce 任務進行運行。其優點是學習成本低，可以通過類 SQL 語句快速實現簡單的 MapReduce 統計，不必開發專門的 MapReduce 應用，十分適合數據倉庫的統計分析。
Hive 是建立在 Hadoop 上的數據倉庫基礎構架。它提供了一系列的工具，可以用來進行數據提取轉化加載(ETL)，這是一種可以存儲、查詢和分析存儲在 Hadoop 中的大規模數據的機制。Hive 定義了簡單的類 SQL 查詢語言，稱為 HQL，它允許熟悉 SQL 的用戶查詢數據。同時，這個語言也允許熟悉 MapReduce 開發者的開發自定義的 mapper 和 reducer 來處理內建的 mapper 和 reducer 無法完成的複雜的分析工作。
於筆者這樣的產品經理而言，其重要意義是將 MapReduce 進一步進行抽象為業務高階語言，讓更多不善於 Java/C++ 編碼的數據工程師能夠快速上手使用大數據工具進行數據分析，讓大數據業務開發成本更低、使用門檻更低、維護成本更低，讓傳統的、使用數據庫的數據分析師能夠基本無縫遷移到基於 Hadoop 的大數據平臺，從而極大擴展了大數據用戶群體，進一步拉動 Hadoop 社區的用戶生態以及商業生態。
從另外一個方面，Hive 作為一個 SQL-On-Hadoop 工具，為後續諸多大數據處理軟件提供了很好的表率：即越高階的業務抽象 API 能夠極大降低用戶開發門檻，拉動使用者基數。後續大量的開源閉源大數據系統都或多或少、有模有樣地提供了各自 SQL 方言，方便用戶更加快速、簡單地上手各自的大數據軟件。開源社區來看，從 Hive 開始，Presto、Impala、Spark、或者當前風頭正緊的 Flink，無不提供 SQL 作為高階數據分析語言。從閉源產品而言，阿里雲的 MaxCompute、AWS 的 Redshift、Google 的 BigQuery，均提供各自 SQL 抽象以爭取更多雲上開發人員的使用。據阿里對外宣傳的文章來看，基於 MaxCompute 的離線數倉體系服務了整個阿里集團數萬名員工之眾、每日運行作業達數百萬至多，以至於集團內部包括數據工程師、產品經理、運營人員、財務人員人人可以分析數據，人人可以提取數據，人人皆為數據分析師。可以想像，若非 SQL 這類高階業務表達語言助力，阿里集團大數據體系絕無可能有如此規模的受眾群體，亦不可能產生巨大業務價值。
實時計算：讓計算更快產生業務價值
大數據誕生之初給使用者最大的疑惑在於：為何計算如此之慢?彼時使用數據庫多數查詢在亞秒級別返回，使用數倉多數查詢在數秒級別返回，到 Hadoop 的大數據時代，大部分查詢在數分鐘、數小時、甚至於數天級別方才能夠查詢出結果。大數據、大數據，在一旦解決計算可處理的問題之後，時效性問題便擺上檯面。
大數據領域下，時效性分為兩個方面：
數據從用戶請求到最終呈現的實時性，這條路徑強調的是請求響應的及時性。
數據從發生到處理、並最終產生業務價值的全鏈路時效性，這條路徑強調的是數據鏈路及時性。
前者我們稱之為交互式計算領域，後者我們稱之為實時(流)計算領域。我一直認為交互式查詢是技術方面的優化，是人人痛恨 MapReduce 計算模型太慢太落後的技術優化，和產品形態並無太大關聯。而後者，則是整個大數據產品模型的變化，這是一種觸發式計算，有點類似阿里雲的 FunctionCompute，或者是 AWS 的 Lambda;或者更加準確地定義是：基於事件流的實時流計算。我們通常看到三個系統：
第一代：Storm
Storm 是 Nathan Marz 的心血結晶，Nathan Marz 後來在一篇題為《History of Apache Storm and lessons learned》的博客文章中記錄了其創作歷史。這篇冗長的博客講述了 BackType 這家創業公司一直在自己通過消息隊列和自定義代碼去處理 Twitter 信息流。Nathan 和十幾年前 Google 裡面設計 MapReduce 相關工程師有相同的認識：實際的業務處理的代碼僅僅是系統代碼很小一部分，如果有個統一的流式實時處理框架負責處理各類分佈式系統底層問題，那麼基於之上構建我們的實時大數據處理將會輕鬆得多。基於此，Nathan 團隊完成了 Storm 的設計和開發。
上述將 Storm 類比為流式的 MapReduce 框架，我自認為特別貼切，因為這個概念類比更好向各位看官傳達了 Storm API 的 low-level 以及開發效率低下，這類基礎大數據的 API 讓業務人員參與編寫業務邏輯好比登天。同時，Storm 的設計原則和其他系統大相徑庭，Storm 更多考慮到實時流計算的處理時延而非數據的一致性保證。後者是其他大數據系統必備基礎產品特徵之一。Storm 針對每條流式數據進行計算處理，並提供至多一次或者至少一次的語義保證。我們可以理解為 Storm 不保證處理結果的正確性。
第二代：Spark
Spark 在 2009 年左右誕生於加州大學伯克利分校的著名 AMPLab。最初推動 Spark 成名的原因是它能夠經常在內存執行大量的計算工作，直到作業的最後一步才寫入磁盤。工程師通過彈性分佈式數據集(RDD)理念實現了這一目標，在底層 Pipeline 中能夠獲取每個階段數據結果的所有派生關係，並且允許在機器故障時根據需要重新計算中間結果，當然，這些都基於一些假設 a)輸入是總是可重放的，b)計算是確定性的。對於許多案例來說，這些先決條件是真實的，或者看上去足夠真實，至少用戶確實在 Spark 享受到了巨大的性能提升。從那時起，Spark 逐漸建立起其作為 Hadoop 事實上的繼任產品定位。
在 Spark 創建幾年後，當時 AMPLab 的研究生 Tathagata Das 開始意識到：嘿，我們有這個快速的批處理引擎，如果我們將多個批次的任務串接起來，用它能否來處理流數據?於是乎，Spark Streaming 就此誕生。相比於 Storm 的低階 API 以及無法正確性語義保證，Spark 是流處理的分水嶺：第一個廣泛使用的大規模流處理引擎，既提供較為高階的 API 抽象，同時提供流式處理正確性保證。 有關更多 Spark 的信息，筆者推薦 Matei Zaharia 關於該主題的論文《 An Architecture for Fast and General Data Processing on Large Clusters》:
第三代：Flink
Flink 在 2015 年突然出現在大數據舞臺，然後迅速成為實時流計算部分當紅炸子雞。從產品技術來看，Flink 作為一個最新的實時計算引擎，具備如下流計算技術特徵：
完全一次保證：故障後應正確恢復有狀態運算符中的狀態
低延遲：越低越好。許多應用程序需要亞秒級延遲
高吞吐量：隨著數據速率的增長，通過管道推送大量數據至關重要
強大的計算模型：框架應該提供一種編程模型，該模型不限制用戶並允許各種各樣的應用程序在沒有故障的情況下，容錯機制的開銷很低
流量控制：來自慢速算子的反壓應該由系統和數據源自然吸收，以避免因消費者緩慢而導致崩潰或降低性能
亂序數據的支持：支持由於其他原因導致的數據亂序達到、延遲到達後，計算出正確的結果。
完備的流式語義：支持窗口等現代流式處理語義抽象
你可以理解為整個實時計算產品技術也是時間發展而逐步成熟發展而來，而上述各個維度就是當前稱之為成熟、商用的實時計算引擎所需要具備的各類典型產品技術特徵。Flink 是當前能夠完整支持上述各類產品特徵參數的開源實時流處理系統。
加米穀大數據零基礎培訓，5月大數據開發0基礎班開課啦，歡迎預約免費試聽！
全家桶：一套引擎解決“所有”大數據問題
Flink 和 Spark：All-In-One
大數據全家桶其實是一個實打實的產品問題：從大數據社區反饋的情況來看，對於大部分大數據處理用戶，實際上的大數據處理訴求分類有限，基本上在 Batch(60%+)、Stream(10%+)、Adhoc(10%+)、其他(包括 ML、Graph 等等)。對於任何一個大數據處理引擎深入做透一個領域後，勢必會考慮下一步發展，是繼續做深做專，抑或還是橫向擴展。做又紅又專?從商業來看，這個領域的市場規模增長可能有限，眼瞅著都到天花板了;但從橫向角度來看，周邊大數據引擎虎視眈眈，隨時都有殺入我們現有市場之中。面對市場，各色需求可窮舉;面對技術，引擎基礎業已夯實，為何不周邊突破擴展，開拓新的大數據領域。Spark 從批入手，針對 Hadoop 處理性能較差的問題，將 Spark 的 Batch 功能做成一個“爆款應用”，同時提供 Spark Streaming、Spark ML，前期靠 Spark Batch 為整個 Spark 社區用戶倒流，並吸收為 Spark Streaming、Spark ML 的客戶。而通過 Spark 大數據全家桶功能，Spark 產品構建一個粘性的護城河。大量中小用戶一旦全功能上了 Spark，大家理解後續很難因為 Spark 某個功能點不太滿足需求而拋棄使用 Spark。
Spark 從批入手，嘗試在一個技術棧體系內統一基礎的大數據處理;在另外一個方向，Flink 從 Stream 入手，在構建出 Flink Stream 強大生態後，也在考慮佈局 Flink Batch，從 Stream 切入 Batch 戰場。
下圖是 Spark 的軟件棧體系：
下圖是 Flink 的軟件棧體系：
兩者在產品功能棧上早已十分相似，缺的是各自薄弱領域的精細化打磨。在此，我們不討論兩者功能強弱分佈，畢竟本文不是一個產品功能介紹文章。未來兩個系統鹿死誰手花落誰家，各位看官拭目以待吧。
Beam: One-Fits-All
前文已述，早期 Google 在大數據領域純粹扮演了一個活雷鋒的角色，以至於整個開源大數據生態蓬勃發展起來，並最終形成完整的大數據商業生態之時，Google 基本門外一看客，眼瞅著自己的技術理論在開源社區發揚光大，自己沒撈半點好處。適時，Google 雲業已發展起來，並拉起諸多祖師爺級別的產品技術服務客戶，例如 BigTable。常理而言，BigTable 開創 NoSQL 大數據之先河，其 Paper 位列 Google 大數據三駕馬車之中，技術地位可見一斑。再看社區 HBase，乃直接“抄襲”Google BigTable 論文理論，實乃徒子徒孫之技術。但最終，Google 雲發佈 BigTable 產品之時，為了考慮社區產品兼容性以及用戶上雲遷移成本，竟然不得不兼容 HBase 1.0 的 API 接口。可以想象，BigTable 項目組成員當時內心感覺只能是：簡直日了狗!但一切為了雲計算營收，BigTable 產品放下技術執念選擇兼容 HBase 接口，實屬難得!我們為 Google 尊重市場而放下身段的行為點贊!
Google 受此大辱，吃此大虧，當然會痛定思痛，考慮建設開源社區並嘗試力圖控制社區。於是在此背景之下，Apache Beam“粉墨登場”。Google 考慮問題之核心不在於是否要開源一個大數據處理系統(當時社區 Spark 已經蔚然成風，Flink 的發展同樣亦是扶搖直上，似乎社區並無缺少一個好的大數據引擎)，而僅僅缺乏開源社區大數據處理接口之統一，包括將核心的批處理以及流處理接口統一。而之前 Google 內部的 FlumeJava 一直承擔大數據 Data Pipeline 之 API 定義角色，於是想當然地從內部將之前的 FlumeJava 接口進行抽象改進，提供統一的批流處理 API 後在 2016 年貢獻提交給 Apache 基金會。試圖通過定義一套統一的 API 抽象層，說服各個廠商實現該套抽象，即可完成 API 統一的千秋大業，併為用戶遷移 Google 雲上埋下最大伏筆。
此類打法構思只能是技術人員對於大數據社區發展不切實際的夢想，或者是 Google 實在太高估自己的技術影響力，認為只要 Google 技術一出，開源社區絕對俯首稱臣，拉下老臉哭著喊著求兼容。但 Google 打錯算盤的是，從沒有一個市場追趕者角色制定標準來讓市場領導者來做適配，市場領導者憑什麼鳥你。你區區一個追趕者，制定標準，挖下大坑，讓領導者來兼容你的標準絕對是痴人說夢。於是乎，在 Apache Beam 發佈之後，除 Flink 社區意圖想聯合 Beam 社區一起做做技術影響力之外，其他開源大數據產品和 Beam 一直若即若離。大家都是明白人，都明白 Google 大力推動 Beam 的明修棧道暗度陳倉，我兼容你標準，最終你不是靠雲上產品想把大家的流量全部收割了麼。因此，開源社區難以有真心和 Beam 社區結成歃血同盟者，社區合作者多半皆是善於投機的機會主義者。一時間，Beam 的前景黯淡。
結語
本文瀏覽了整個大數據發展歷史，特別重點關注了數據計算處理部分的內容。我們從程序本質以及行業發展脈絡分別描述了大數據之前的程序時代以及數據庫時代，大數據當代的各類理論、系統、社區發展。我們觀察歷史，是讓我們有信心面對當前;我們分析當代，是讓我們有機會看清未來。未來整個雲計算以及之上的大數據發展，已經超出本文的討論範疇，但從上述歷史、當代分析能對未來其發展推測一二，歡迎大家自行思考。文章行文較為倉促，定有紕漏之處，望各位看官不吝賜教。
附錄：https://www.leiphone.com/news/201901/gLVJGxFuKtGfxwJ6.html
https://darkhouse.com.cn/blo
閱讀更多 Spark大數據開發 的文章
