導讀：大數(shù)據(jù)是當前最熱的技術(shù)之一，這十年它經(jīng)歷了哪些階段?每個階段分別創(chuàng)造和發(fā)展了什么?未來大數(shù)據(jù)又將朝著哪些方向繼續(xù)前行?在這篇文章里，我們沿大數(shù)據(jù)發(fā)展時間線，從產(chǎn)品、行業(yè)、技術(shù)多角度討論其發(fā)展脈絡，究其發(fā)展承其脈絡大家可以學習、借鑒、并最終推測未來大致走向。

引子

我一直認為大數(shù)據(jù)中文社區(qū)里面不乏各類技術(shù)大牛所著深度架構(gòu)干貨，同時亦不乏各類技術(shù)的總監(jiān) /VP/CXO 高屋建瓴指點行業(yè)江山的激情文字，所缺的往往是站在技術(shù)、產(chǎn)品、社區(qū)、市場交匯點的思考點滴。有如我經(jīng)常在我部門中所說，中國當前不乏各類云計算的技術(shù)大牛，亦不缺各類 C 端領域的產(chǎn)品大拿，但中國云計算領域要盤點出來一個既通曉技術(shù)、又懂得產(chǎn)品全局觀、更有甚者能夠把握行業(yè)脈絡的技能全通行業(yè)聞名者，確實屈指可數(shù)乏善可陳。

我一直篤定一名優(yōu)秀的云計算產(chǎn)品經(jīng)理一定是全技能通才，上可討論行業(yè)趨勢產(chǎn)業(yè)脈絡，下可寫得了代碼修得了 Bug，中還可設計產(chǎn)品交互參與 API 制定，有時可能自戀一把還去 投投稿、賺賺人氣、刷刷存在感。同理，我希望這篇命題式作文亦兼具如此多條思路：

沿大數(shù)據(jù)發(fā)展時間線，從產(chǎn)品、行業(yè)、技術(shù)多角度討論其發(fā)展脈絡，究其發(fā)展承其脈絡我們可以學習、借鑒、并最終推測未來大致走向。

我不敢用“預測”而只能用“推測”，是因為我非常認可吳軍老師在《硅谷來信》中所言”輕預測重反應“，他對于如此復雜如此變幻的市場、世界，缺乏直言預測的勇氣。我深以為然。因此，我不敢輕言預測，只能說我們嘗試用之前的發(fā)展軌跡去推測一下未來的走勢。至于最終市場方向是否符合我們預計，實在是天命難測命運難為。當然，最終如果市場不按我們預測的套路出牌，錯的不是市場，而是我們的理論。所謂”市場永遠是正確的，錯誤的只能是我們的理論“，是吳軍老師教會我的第二點產(chǎn)品市場觀。

站在云高度提供獨一無二的視角去觀察大數(shù)據(jù) / 云計算的發(fā)展。

我曾有幸作為一個不處在核心崗位仍在電商邊緣工作的觀察者在電商崛起的時代被有幸卷入電商浪潮。我是親眼看到以淘寶、天貓為代表中國電商行業(yè)崛起的時代，那是一個創(chuàng)造金錢、財富、神話的時代，你可以比之為美國淘金時代。接下來的時代，即我們當前的時代，可能是一個更加激動人心、更加”技術(shù)爆炸“的時代，它們可能是 IOT 時代、是大數(shù)據(jù)時代、是云計算時代、是人工智能時代。上述都是從產(chǎn)業(yè)某種維度觀察 IT 技術(shù)設施發(fā)展的淺顯斷論，可能是一葉障目管中窺豹，亦可能是獨辟蹊徑曲線救國。但不管怎樣，站在云計算高度來看，這些都是當前云計算所希望領域突破，也是希望能夠利用云計算服務上述更多行業(yè)、造福更多中國中小企業(yè)的領域。比如當前阿里云服務的具有百萬級客戶群體以及技術(shù)積累，從市場份額來看它是后續(xù)數(shù)個追隨者份額之和。兵貴神速，任何的先發(fā)優(yōu)勢在行業(yè)井噴年代造就的發(fā)展加速度是任何后續(xù)資本、人力、技術(shù)投入都不可比擬的。才發(fā)現(xiàn)，差之毫厘謬以千里，形容發(fā)展加速度亦十分貼切。

接下來，我會從上篇(大數(shù)據(jù)史前)、下篇(大數(shù)據(jù)當代)，討論整體大數(shù)據(jù)發(fā)展特點和脈絡。負責任地說，以下論點都是作者一家之言(不代表任何公司的立場)，同時篇幅受限論點基本均是管中窺豹，不成體系。大家權(quán)當作為茶余飯后消遣閱讀的 IT 雜文。

大數(shù)據(jù)史前

歷史

如果我把大數(shù)據(jù)開創(chuàng)的時代當做公元元年紀年，那么我把大數(shù)據(jù)開創(chuàng)時代之前的時間稱之為”史前時代“，當然此史前并未真正較真為“文明之前”，僅僅筆者的象征性說法。另外需要注意的是，我專門使用的名詞是”史前時代“而非”田園時代“，史前指代的是蠻荒、指代的是愚昧、指代的是茹毛飲血，而田園往往給人以心理暗示是男耕女織、自給自足、路不拾遺的上古伊甸園。我從不認可人類社會文明之前乃是一個夜不閉戶、道不拾遺的謙謙君子社會，古人常云”人心不古世風日下“就好比男人經(jīng)常性懷念前女友整日日有所思夜有所夢，倘要他們真的返回原始社會過著食不果腹衣不蔽體，常常需要血肉廝殺、易子而食的時候，這波文人可能就兩眼一瞪：傻缺才愿意回去過苦日子呢，我又不傻!

同理，我從不認為大數(shù)據(jù)之前的數(shù)據(jù)處理特別包括數(shù)據(jù)庫理論才是數(shù)據(jù)處理的田園時代，以至于大批數(shù)據(jù)庫理論學派發(fā)檄文聲討 MapReduce 理論的種種缺憾;同時我亦不認為當前整體軟件系統(tǒng)設計過于復雜，整個大數(shù)據(jù)生態(tài)過于冗余。IT 圈時常有人感慨，當前系統(tǒng)設計之臃腫、運作之復雜，實在有違“Simplicity is beauty”的原則，時常追憶當年玩 Unix Shell、翻翻 X86 中斷手冊，無比簡約無比快感。但可惜，市場永遠是對的，如果當前企業(yè)級軟件市場確實需要如此復雜的軟件體系、如此多樣的系統(tǒng)生態(tài)，說明這部分理論基礎以及工程實踐確實需要如此復雜化、多樣化。試看當今任何學科之前沿領域，無不復雜絕頂，即便同一學科不同子領域之下的職業(yè)從業(yè)者亦可能相互之間無法洞悉各自精髓。社會發(fā)展已經(jīng)到如此精細化地步，不能責怪與之服務的人類知識體系。

大數(shù)據(jù)史前時代的數(shù)據(jù)處理，筆者粗略地將其劃為兩個時代邊界：程序時代以及后續(xù)的數(shù)據(jù)庫時代。

程序時代

從時間上，從計算機誕生到專業(yè)數(shù)據(jù)庫發(fā)跡(不精確來說，以 IBM 關(guān)于數(shù)據(jù)庫論文發(fā)表左右時間代表專業(yè)數(shù)據(jù)庫誕生，同樣上述時代劃分并不一定科學也并非嚴格意義的嚴謹)，那個時候的程序員(或者更應該稱之為計算機科學家)過著普遍“輪子幫”的編碼生活，即一切都需要靠手解決。這個是程序員的蠻荒時代，人人都面臨著所有最基礎、最原始、最重復的勞動工作，人人需要面對硬件、面對驅(qū)動，人人需要處理算法、處理數(shù)據(jù)結(jié)構(gòu);同時，這也是程序員的黃金時代，由于重復構(gòu)建輪子所練就的技術(shù)內(nèi)功，人人皆可為大神：隨隨便便讀下 RFC 就可以完整實現(xiàn) TCP/IP 協(xié)議棧(Bill Joy)、做個學校大作業(yè)就可以完成一個 Lex(Eric Schmidt)，或者在大二在校時間寫一個現(xiàn)代操作系統(tǒng)(Linus Torvalds)。不過，從商業(yè)公司角度而言我一直較為排斥重復造輪子的做法，因為大部分自研或者不客氣說就是造輪子(注意，我指大部分并非全部人員，沒有一棍子打死所有人)，其實是對于最大化實現(xiàn)商業(yè)公司價值無異于緣木求魚;而從程序員自我實現(xiàn)角度而言，我推薦程序員多去造造輪子，以便最大化窺覽計算機最核心的知識精華。我承認，盡管在現(xiàn)代中國勞資雙方關(guān)系還算友好，但畢竟各取所需各有利益，雙方在一些底層商業(yè)邏輯上面一直有矛盾存在。

私以為，”一切程序都是對于信息(數(shù)據(jù))的處理“應該是我們計算機處理問題的底層構(gòu)建邏輯，是計算機領域放之四海而皆準的公理性斷論。因此，不管是上古時代 C/S 架構(gòu)的代碼，抑或當前風頭正緊的微服務、還是大數(shù)據(jù)中有關(guān)數(shù)據(jù)處理 Pipeline 的抽象，均是對于數(shù)據(jù)的處理抽象。不同的是視當前問題的復雜程度、抽象對象的復雜程度，我們提供了不同層次的抽象設計原則而已。程序?qū)τ跀?shù)據(jù)處理的抽象最為直接最為裸奔，整個程序處理邏輯都在于對計算機硬件執(zhí)行抽象，是為數(shù)據(jù)處理 Action 的抽象，是 Input->Action->Output 的抽象。該抽象對于數(shù)據(jù)的存儲、數(shù)據(jù)的結(jié)構(gòu)、數(shù)據(jù)的傳輸、數(shù)據(jù)的壓縮等等均無定義，交由應用開發(fā)程序員自行安排、自行處理。這里的抽象最為原始、最為暴力，其靈活度甚高，同樣其普適性亦涵蓋整個計算機應用領域，無人敢說我的程序不是處理數(shù)據(jù) / 信息的，因為整個計算機的發(fā)明即為信息 / 數(shù)據(jù)處理所服務的。因此我可以說，程序，是為(大)數(shù)據(jù)處理最為初級的抽象方式，這是大數(shù)據(jù)史前時代最為野蠻也最為普適的一個抽象。隨著計算機科學以及工程的發(fā)展，我們一定會發(fā)展出更加高階的抽象層次。

我們可以將計算機 / 程序的發(fā)展脈絡簡單提煉出兩點，同時這兩點也會指導我們討論后續(xù)所有系統(tǒng)發(fā)展的一般客觀規(guī)律，即：

人類社會的發(fā)展脈絡之一就是社會分工，程序的抽象就是計算機科學 / 工程領域?qū)τ谏鐣�分工的計算機實踐。人類社會從最早與獸無異的捕獵者，逐步進化到農(nóng)業(yè)社會有君主、有祭司、有農(nóng)民，然后過渡到工業(yè)社會出現(xiàn)廠主、工人、商人，最終演化到時至今日三百六十行隔行如隔山的分門別類職業(yè)爆發(fā)。究其原因，均源于社會發(fā)展導致的社會分工，當人類社會面向的知識領域、技能領域浩如煙海，大量職業(yè)參與者窮其一生無法精通其中寥寥數(shù)種工種和領域之時，必定將爆發(fā)出各種人類社會分工;同時由于分工導致社會合作協(xié)作加劇，不容于社會分工體系之下的個人、公司、國家必定淘汰于這個全球分工協(xié)作網(wǎng)絡。

 

 

計算機科學 / 工程無不遵守上述社會發(fā)展大規(guī)律，當有大量底層系統(tǒng)構(gòu)建者構(gòu)建出操作系統(tǒng)、編譯器、數(shù)據(jù)庫之后，上層應用開發(fā)者僅僅需要了解底層 API 功能原理即可拼湊完整其上層業(yè)務構(gòu)建。操作系統(tǒng)構(gòu)建者抽象了硬件資源使用方式，我們必須 Follow 操作系統(tǒng)構(gòu)建者的抽象去通過各類 System Call 完成計算資源的調(diào)用;編譯器構(gòu)建者抽象了業(yè)務邏輯的表達方式，我們必須 Follow 編譯器構(gòu)建者的抽象去使用各類程序語言和 Library 去完成業(yè)務邏輯的編排;數(shù)據(jù)庫構(gòu)建者抽象了數(shù)據(jù)處理的語言表達，我們必須 Follow 數(shù)據(jù)庫構(gòu)建者的抽象去使用 SQL/API 操作我們的數(shù)據(jù)。同理，大數(shù)據(jù)系統(tǒng) / 框架在分布式計算資源之上抽象了對于數(shù)據(jù)處理的 Pattern，大數(shù)據(jù)應用開發(fā)者只能 Follow 這個抽象去做相應的大數(shù)據(jù)計算和處理。

構(gòu)建底層的操作系統(tǒng)、數(shù)據(jù)庫、中間件、大數(shù)據(jù)、AI，是社會分工的制定者，是游戲規(guī)則的設計者，是產(chǎn)業(yè)上游的利益分配者，他們能夠定義整個 IT 商業(yè)市場的規(guī)模、玩法以及利益分配。他們可能是傳統(tǒng)的軟件服務商，例如 Microsoft、Oracle，也可能是新型的云計算公司，例如阿里云、AWS。對于這類公司而言，未來它們(當然，得在云時代存活下來的計算服務商)會成為整個信息社會的底層構(gòu)建者，未來它們會是一層不可逾越的商業(yè)基礎設施。

人類文明的兩大發(fā)展主線：能量和信息。人類社會一直都沿著上述兩條發(fā)展主線演進，即擴大能量使用以及加速信息傳播。能量的使用，從人類使用火(減少能量散失)、到發(fā)明農(nóng)業(yè)

(擴大能量攝入)、到最終原子彈發(fā)明(開發(fā)更大效率的核能)，所有能量發(fā)展均沿著能量的“開源節(jié)流”線發(fā)展。同時對于信息，包括文字(跨地域跨時空傳播信息)、印刷術(shù)(大規(guī)模傳播信息)、電報(及時傳播信息)、IT 技術(shù)(大規(guī)模數(shù)字化傳播信息)均在嘗試最大化將信息流動起來、傳播起來。

從這個角度拉看，在互聯(lián)網(wǎng) /IT 領域，凡是有利于信息產(chǎn)生、傳播、處理、反饋的技術(shù)、系統(tǒng)、產(chǎn)品都將創(chuàng)造巨大的社會價值，進而創(chuàng)造巨大的財富價值。例如從個體信息傳播發(fā)展來看，從互聯(lián)網(wǎng) 1.0 時代集中式官媒發(fā)聲到所謂 Web2.0 時代大量博客、微博發(fā)聲，都是有利于互聯(lián)網(wǎng)用戶傳播自己的信息渠道;從 Web2.0 的博客(長篇大論的文字)到微博(只言片語想到說到及時上傳文字 + 圖片信息)到現(xiàn)在抖音(傳播信息量更大的視頻內(nèi)容)。下一代技術(shù) / 系統(tǒng)，凡是有利于數(shù)據(jù)從物理世界進入信息世界(當前大量行業(yè)尚未被信息化)，凡是有利于信息世界傳播的均是發(fā)展熱點，例如：5G(加速信息傳播)、VR(更多物理世界信息化)、IOT(更多物理世界信息化)。

 

 

繼續(xù)從這個角度入手，我們同樣可以發(fā)掘數(shù)據(jù)系統(tǒng)發(fā)展趨勢：凡是有利于數(shù)據(jù)(信息)產(chǎn)生、傳播、處理、反饋的技術(shù)都可能帶動整體數(shù)據(jù)系統(tǒng)的向前演進。例如更簡單地抽象了數(shù)據(jù)處理范式(SQL)、更簡單地應對互聯(lián)網(wǎng)時代下大規(guī)模數(shù)據(jù)處理能力(MapReduce 以及其衍生系統(tǒng))、AI(大數(shù)據(jù)處理后直接提交 AI 系統(tǒng)做市場決策)。因此，在下文我們做未來數(shù)據(jù)系統(tǒng)發(fā)展推演，我將不遺余力地使用該原則進行發(fā)展推演。

數(shù)據(jù)庫時代

我應該把文件系統(tǒng)的抽象放置在數(shù)據(jù)庫時代之前，畢竟文件系統(tǒng)的抽象同樣解放了數(shù)據(jù)程序員去關(guān)注底層硬件指令和驅(qū)動的繁瑣。在此，我之所以略過文件系統(tǒng)不在于文件系統(tǒng)本身重要性欠佳，文件系統(tǒng)抽象和操作系統(tǒng)抽象一樣，奠定了我們今時今日整個計算機世界的工程基石。但篇幅所限，我們今天本文重點討論數(shù)據(jù)系統(tǒng)，而非存儲系統(tǒng)發(fā)展歷史，我們不得不暫時省略掉不在我們討論主線的主題。

令人稱贊的數(shù)據(jù)庫時代!讓程序員終將擺脫直接面對硬件磁盤結(jié)構(gòu)以及底層文件系統(tǒng)進行數(shù)據(jù)操作�？梢韵胂螅�在數(shù)據(jù)庫誕生之前的時代，程序員是如何面對底層存儲系統(tǒng)結(jié)構(gòu)去構(gòu)建自己的應用代碼，在存儲要靠磁帶的蠻荒時代，程序員在一個類似線性表存儲中自己嘗試去構(gòu)建數(shù)據(jù)索引以及設計數(shù)據(jù)內(nèi)容存儲，并且還需要面對底層磁盤硬件操作寫入方式;在接下來當提供文件系統(tǒng)抽象封裝的操作系統(tǒng)之上構(gòu)建各自應用時，程序員稍加解脫可基于一個成熟的文件系統(tǒng)而不用去直接面向磁盤操作，但終究仍需要面對設計諸如索引結(jié)構(gòu)、存儲結(jié)構(gòu)、并發(fā)讀寫、失敗恢復等諸多底層系統(tǒng)設計細節(jié)�？梢韵胂�，諸如此類基礎底層的系統(tǒng)類軟件設計和實現(xiàn)，絕逼難度異于常規(guī)，非大神級別參與實現(xiàn)不可，這將變相提升整個軟件項目的復雜度以及投入成本，并最終帶來項目落地以及市場商業(yè)的巨大風險。

困難往往意味著機會，越普遍越難解的困難往往蘊藏著巨大的市場機會。如前文所言，諸如操作系統(tǒng)、數(shù)據(jù)庫、編譯器之類的軟件產(chǎn)業(yè)基礎服務，投入巨大、風險巨高，非一般公司可以為之。但同理而言，一旦此類公司發(fā)布出可商用的軟件版本、構(gòu)建出可繁衍的軟件生態(tài)，即可成就一番軟件霸業(yè)。操作系統(tǒng)如此，看看曾經(jīng)“不可一世”的微軟、當前如日中天的蘋果;數(shù)據(jù)庫如此，瞧瞧遍大街的 Oracle“霸占”多少銀行電信行業(yè)，養(yǎng)活多大上下市場生態(tài)。

在此，我想僅僅想討論數(shù)據(jù)庫領域兩個我認為涉及到本文主旨的論點。

數(shù)據(jù)處理一次社會化的大分工

文件系統(tǒng)的抽象將存儲進行了分工，大量開發(fā)人員不用在面對硬件和驅(qū)動讀寫存儲，而是面向文件句柄、目錄層次、讀寫權(quán)限，這是一個巨大的飛躍，恰到好處地將操縱硬件資源包裝為一個面對有結(jié)構(gòu)有層次利于操作的系列文件 API;再次，數(shù)據(jù)庫將存儲抽象從一個完全平面的、Bit 線性表、操作對象粒度為文件的層次再次提升到關(guān)系二維表(特指關(guān)系型數(shù)據(jù)庫)、面向業(yè)務記錄(數(shù)據(jù)行)、操作對象粒度細化到數(shù)據(jù)的層次。

抽象有利于業(yè)務表達，因為抽象會提供更高級別的 API(從文件 API 提升到數(shù)據(jù) API)，更有利于業(yè)務開發(fā)人員聚焦自身的業(yè)務表達;但任何事情都有 trade-off，聚焦意味著放棄，抽象反面就是泛化，文件系統(tǒng)作為一個存儲系統(tǒng)設計而言具有最為廣泛的市場應用價值，但同時如果要讓每個業(yè)務開發(fā)人員在文件系統(tǒng)層面操縱結(jié)構(gòu)化數(shù)據(jù)存儲，必定其痛苦萬分幾欲自宮。因此，數(shù)據(jù)庫設計人員跨出這一步，提煉出高階數(shù)據(jù) API 同時丟失了文件系統(tǒng)普適性的廣闊市場。于是乎，我們在云計算行業(yè)里面可以看到，阿里云的 OSS、AWS 的 S3 仍然可能承載了云上最廣泛、最龐大的數(shù)據(jù)資源(但卻不一定是最有業(yè)務價值的數(shù)據(jù)，例如云計算上一個存儲對象的二級制文件系統(tǒng)服務出現(xiàn)宕機，可能給用戶造成的后果是短時間內(nèi)該文件句柄指代的對象不可讀寫：可能是音樂不能播放、文檔不能打開，用戶可能尚且能夠等待網(wǎng)站恢復，但一個業(yè)務關(guān)鍵數(shù)據(jù)庫系統(tǒng)一旦宕機，可能造成的后果就是災難性的：全站不可登錄、不可交易，是巨大的業(yè)務故障)。因為其文件系統(tǒng)(當然這里是一個分布式文件系統(tǒng))業(yè)務適配范圍遠遠超出關(guān)系數(shù)據(jù)庫的適配范圍;同時，在阿里云 RDS 周邊，我們看到了更多類似數(shù)據(jù)庫的其他垂直領域數(shù)據(jù)處理系統(tǒng)，例如消息隊列(提供流式數(shù)據(jù)讀寫的 API 抽象)、搜索引擎(提供全文檢索服務的 API 抽象)等等等等，因為傳統(tǒng)關(guān)系型數(shù)據(jù)庫在聚焦關(guān)系代數(shù)二維模型情況下，讓出其他數(shù)據(jù)存儲和處理市場份額給到了其他數(shù)據(jù)系統(tǒng)。

 

 

因此，就數(shù)據(jù)處理系統(tǒng)而言，我一直在不停強調(diào)分工、分工、分工。原因是所有的數(shù)據(jù)存儲服務、工具、引擎都在基于文件系統(tǒng)這個普適性的存儲抽象上做垂直領域化的邏輯抽象，包括數(shù)據(jù)庫、消息隊列、搜索引擎，以至于到本文重點大數(shù)據(jù)處理系統(tǒng)。這些都是抽象，是底層邏輯構(gòu)建者在定義自己的理想世界，然后讓上層應用開發(fā)人員心甘情愿融入或者被屈服拉入這一層被抽想改造的”烏托邦“。抽象意味著分工，意味著獨立的市場領域以及商業(yè)份額，越是底層領域普適性越高、受眾面越大、收入空間越足，而越是上層領域普適性越差、受眾面越小、收入空間越小、但可能利潤空間不錯。故而，可以想象，云計算廠商在爭取到巨大的 IT 市場流量入口之后，勢必逐步下沉到普適性更強領域，因此其市場領域更大、想象空間更大，因此處于壟斷地位的云計算公司未來一定會大力發(fā)展諸如 CPU、GPU、IOT 甚至于各類小型機、大型機等各類計算端 + 中心設備，而上層的軟件生態(tài)，包括從最為基礎的 OS 直到上層 SaaS 服務，都是在為這個龐大的 IT 基礎設施為帶動更多的算力資源消耗之目標而服務。對于龐大如阿里云、AWS 類的云計算服務商，本質(zhì)上做的是計算力生意，本質(zhì)上是構(gòu)建下一代計算力的全社會基礎設施。

SQL 與關(guān)系代數(shù)

我有充分的理由可以說，當前 IT 領域最火熱的技術(shù)已經(jīng)不是數(shù)據(jù)庫，或者至少不是傳統(tǒng)關(guān)系型的數(shù)據(jù)庫。當前，包括大數(shù)據(jù)、人工智能、微服務、NoSQL 各類新型技術(shù)層出不窮、屢見不鮮，以至于我時常誤以為 IT 技術(shù)到了劉慈欣《三體》所言的”技術(shù)爆炸“時代。身邊人所言 IT 技術(shù)更新?lián)Q代之快速，非常容易造成從業(yè)人員跟不上節(jié)奏，不無道理。從另外角度而言，不叫賣的技術(shù)要么早已技術(shù)基石、人人皆知，要么瀕臨淘汰、昨日黃花。誠然，關(guān)系型數(shù)據(jù)庫絕非當紅炸子雞，但其技術(shù)影響力絕非后者，而恰恰相反早已經(jīng)是整個計算機科學和工程的基石。猶如計算機科學領域的操作系統(tǒng)，當前已經(jīng)沒有任何太多新穎故事可講。猶記得我在大學時間正值中國互聯(lián)網(wǎng)大爆發(fā)的時代，LAMP 架構(gòu)風頭正勁無出其右，因此有關(guān) Linux/Unix 的網(wǎng)站、教材、博客如投機創(chuàng)業(yè)一般地爭風口要上市。而時至今日，有關(guān) Linux/Unix 的材料早已爛大街再無人作為市場亮點宣傳，而風頭正緊的乃是大數(shù)據(jù)、人工智能、Kubernetes、Docker 等各類技術(shù)噱頭。每每看到這些滿大街的網(wǎng)紅技術(shù)，想想當年 LAMP 培訓宣傳的如日中天，感嘆其實技術(shù)圈和網(wǎng)紅圈本質(zhì)上沒有太多差別，追一個流量網(wǎng)紅和追一個“噱頭技術(shù)”其實相差無幾。

數(shù)據(jù)庫技術(shù)已成計算機基石，早已度過當年求曝光要宣傳的流量小生時代。但不可否認，整個數(shù)據(jù)庫技術(shù)為后續(xù)數(shù)據(jù)處理帶來了大量基礎科學理論以及工程實踐。大量數(shù)據(jù)庫理論論文、工程代碼在后續(xù)的大數(shù)據(jù)、中間件領域中被大量借鑒、拷貝、甚至于”抄襲“。特別是關(guān)系型數(shù)據(jù)庫有關(guān)數(shù)據(jù)處理模型的抽象：理論是關(guān)系代數(shù)、工程是 SQL 查詢語言。

雖然說，數(shù)據(jù)庫模型的歷史雖然不是起源于關(guān)系型模型，但必須得說關(guān)系型數(shù)據(jù)庫曾統(tǒng)一了所有的數(shù)據(jù)庫模型，并一直統(tǒng)治至今。 關(guān)系型模型進入人們視野的具體時間是 E.F.Codd 在 1970 年發(fā)表的論文: “A Relational Model of Data for Large Data Bank”。很多人對關(guān)系型數(shù)據(jù)模型的印象是表和字段，并還能想到的是表與表之間通過某些字段可以關(guān)聯(lián)起來。似乎正因為這樣，關(guān)系型數(shù)據(jù)庫才被冠于這個名字。 然而關(guān)系型數(shù)據(jù)模型中的“關(guān)系”在英文中對應的單詞“Relation”是一個抽象的數(shù)學概念，它既不是獨指 2 個表之間的關(guān)系，也不等價于一個二維表(雖然習慣于以二維表來表示)。 數(shù)學中關(guān)于 Relation 的定義是這樣的：給定 n 個集合 S1、S2、 S3、 …、 Sn, R 是一個 n 元數(shù)組 (n-tuples)，它的第一個元素取自集合 S1，第二個元素取自集合 S2，以此類推。我們將 R 稱之為基于該 n 個集合的一個 Relation，Sj 為 R 的第 j 個域 (Domain)。

 

 

另外一個值得大書特書的就是 SQL，即結(jié)構(gòu)化查詢語言 (Structured Query Language)。筆者是個產(chǎn)品經(jīng)理，相較之如談論如同白開水一般的計算機科學理論例如上文的關(guān)系代數(shù)，非我等產(chǎn)品經(jīng)理興趣所在;我們更加關(guān)注我們的產(chǎn)品接口(Interface)，這層接口可為 UI、同樣亦可為 API，而上述 SQL 即為關(guān)系代數(shù)理論之上用來方便構(gòu)建用戶和系統(tǒng)交互的恰當方式。相比較于用戶之前使用硬件接口 / 驅(qū)動直接操縱數(shù)據(jù)讀寫存儲空間，以及后續(xù)稍顯友好文件系統(tǒng)讀寫接口，SQL 給應用開發(fā)者提供的 API 是令人震撼的，SQL 本質(zhì)是聲明性語言，它告訴計算機我們想要什么(What)，而非執(zhí)行步驟(How)。從抽象程度而言，What 的命令通常要比 How 的命令在描述問題抽象程度更有利于業(yè)務溝通，試想“我想成功約到一個漂亮小姐姐”類似愿望的表達，始終會比”我打算去健身，同時在園區(qū)物色一個漂亮小姐姐，天天請吃西餐 + 看電影，持續(xù)一個月，看看對方反饋效果“的計劃顯得更加貼近男人的內(nèi)心表達。如此，不恰當?shù)卣f，前者就是聲明式語言，后者就是命令式語言。同理，對于聲明式語言，其業(yè)務抽象程度較之命令式更高，筆者作為產(chǎn)品經(jīng)理非常能夠理解 SQL 設計者意欲將關(guān)系代數(shù)理論以及數(shù)據(jù)存儲處理的工程都使用 SQL 語言進行封裝，同時我亦承認，SQL 在統(tǒng)一數(shù)據(jù)抽象層方面意義巨大。但，理論總歸完美，現(xiàn)實總有殘缺，相比于工程而言，大量工程業(yè)務細節(jié)不一定能夠完全用理論 Hold，例如在某些極端情況下，一段 SQL 語句往往在成本和產(chǎn)出之間無法達到最優(yōu)，往往需要專業(yè) DBA 設定特殊的 Hint 往往才能夠提升數(shù)據(jù)庫查詢性能。畢竟，現(xiàn)實數(shù)據(jù)情況多種多樣，預制的專家規(guī)則無法一一窮舉，只能靠具體的 DBA 專家進行特殊性能調(diào)優(yōu)。未來，對于程序處理的優(yōu)化，我們認為每個系統(tǒng)都會有類似 AlphaGo 一樣的 AI Daemo，時時刻刻在學習當前的數(shù)據(jù)特征以及程序處理情況，進而進行深入的、定制化的個性化優(yōu)化。

在本小節(jié)的結(jié)束時間，我們附上有關(guān)數(shù)據(jù)庫發(fā)展 Timeline，希望數(shù)據(jù)庫的發(fā)展路線給大家看到整個數(shù)據(jù)庫發(fā)展時間脈絡 [注 2]。

 

 

大數(shù)據(jù)當代

理論

人人皆言，是 Google 最早提出了云計算的概念。猶記得當年 Google 正值硅谷的當紅炸子雞，Google 的 CEO 乃 Eric Schmidt 老爺子，其本人在硅谷的搜索引擎大會上，首次提出了 Cloud Computing(云計算)概念時，何等意氣風發(fā)，頗有指點江山激揚文字之意。彼時之 Google 乃最為高光之時刻，整個硅谷視之為“顛覆微軟邪惡帝國”的自由燈塔，一時間無數(shù)文人騷客為此趨之若鶩、門庭若市。但 Google 雖貴為云計算概念所創(chuàng)者，似頗得云計算之精髓，但 Google 躺在其最大的廣告現(xiàn)金流之上，類似于“站著就能把錢給掙回來”，似乎缺少開拓新 B 端市場的毒辣眼光，以為云計算乃“科技幻想，當前切勿有此執(zhí)念”，和中外諸多頭部互聯(lián)網(wǎng)一起落入俗套，紛紛為云計算概念點贊卻本身不落地推進執(zhí)行。而恰恰相反的，僅僅在 Google 高調(diào)宣稱云計算之概念的十天之后，亞馬遜的云服務 EC2 就向公眾開放提供試用。我一直揣測當時亞馬遜 /AWS 其本身仍然認為此業(yè)務乃傳統(tǒng)虛機租賃的延續(xù)，和云計算之類高大上的科幻名詞尚有差距，自認為也不可一視同仁。但亞馬遜理論上雖未創(chuàng)新但在商業(yè)市場孜孜不倦推動云計算產(chǎn)品、產(chǎn)業(yè)逐步落地。

回顧這段歷史，我們得承認彼時亞馬遜在技術(shù)領先性上和 Google 尚有差距，不能一概而論，但其市場先行、產(chǎn)品試探的商業(yè)做法無異于更加貼近于當前瞬息萬變、波詭云譎的互聯(lián)網(wǎng)時代下的企業(yè)服務。最終，Google 首提云計算之概念，但花落他家，亞馬遜 /AWS 在市場上率先證明了云計算在商業(yè)市場上的可行性。對于云計算而言，我們可以說大家(包括 Google 開始)都沒有為此真正相信過，以至于亞馬遜 /AWS 最終靠商業(yè)行動力獲得云計算歐美市場的定義權(quán)。因為相信所以看見，為亞馬遜 /AWS 市場商業(yè)創(chuàng)新能力手工點贊!

暫且按下 Google 云計算不表，早期 Google 對業(yè)界另一大貢獻即是大數(shù)據(jù)概念提出，同樣不幸，Google 在大數(shù)據(jù)領域比云計算領域更是親力親為扮演活雷鋒的角色。云計算中 Google 僅僅貢獻科技概念和名詞包裝，早期市場方面全靠 AWS 一家將其發(fā)揚光大，Google 早期除了貢獻這個概念本質(zhì)上對于云計算商業(yè)和市場并無特殊貢獻，相反是貢獻了“技術(shù)指導商業(yè)”往往會拖累市場發(fā)展的反例：一個純粹的技術(shù)公司承載不了云計算的商業(yè)夢想;而大數(shù)據(jù)領域，Google 不僅是貼錢、貼人地支持大數(shù)據(jù)發(fā)展，以至于最終開源大數(shù)據(jù)社區(qū)蓬勃發(fā)展成就一方霸業(yè)，但 Google 與之 Hadoop 社區(qū)，好比一匆匆過客，呆癡癡、傻乎乎地眼見諸多理論被開源“山寨”進而被其他云計算公司使用，毫無作為令人嘆惋。于是乎，Google 在完美地錯過了云計算的先發(fā)優(yōu)勢之后，順便再進一步丟棄了主導開源大數(shù)據(jù)理論、技術(shù)以及市場彪炳千秋之機會。

篇幅有限，在此我們僅從兩個維度切入討論 Google 的三駕馬車，同時順帶聊聊 Google 在大數(shù)據(jù)領域的先發(fā)后至，以及 Google 云計算的思考。

大數(shù)據(jù)：退步還是進步?

討論的第一個主題就是大數(shù)據(jù)相比于數(shù)據(jù)庫在數(shù)據(jù)處理理論上是進步還是退化?筆者專門加上了一個“理論上”，因為前文已述，我等產(chǎn)品經(jīng)理對于技術(shù)理論并無多大興趣，特別對于技術(shù)領先型，如果無法轉(zhuǎn)換為成本優(yōu)勢、性能優(yōu)勢、體驗優(yōu)勢，此類技術(shù)之牛 X，于我不甚關(guān)心。我會直接從商業(yè)或市場上給出結(jié)論：大數(shù)據(jù)相比于數(shù)據(jù)庫是市場進步，因為他們當前更加貼近市場對于大規(guī)模數(shù)據(jù)處理的訴求。

以 MapReduce 為例(有關(guān) MapReduce 的概念解釋，請參看下文的資料推薦，本文非技術(shù)入門科普文不討論技術(shù)原理)，當年 David J. DeWitt 以及 Michael Stonebraker 有關(guān) MapReduce 的聲討檄文仍歷歷在目。2008 年，上述兩位數(shù)據(jù)庫大拿在 databasecolumn 網(wǎng)站發(fā)表《MapReduce: A major step backwards》(MapReduce: 一個巨大的倒退)基本上把互聯(lián)網(wǎng)大數(shù)據(jù)派和數(shù)據(jù)庫派之間的爭吵推向一個高潮。任何一個稍懂數(shù)據(jù)庫以及大數(shù)據(jù)的相關(guān)從業(yè)人員，都能夠明確看到兩者之間的嚴重分歧。于數(shù)據(jù)庫人員而言：我派祖師爺數(shù)十年之心血積累，創(chuàng)建諸如關(guān)系模型、SQL 語言、ACID、存儲優(yōu)化等等理論精髓，方才以開山立派流芳百世，爾等小屁孩一登場啥都不懂就把祖師爺數(shù)十年積累貶的一文不值，砍得七零八落，你這個不是開歷史倒車又是什么?數(shù)據(jù)庫提了大致五點問題，擺出架勢準備為數(shù)據(jù)處理的后生小輩諄諄教導一番：

在大規(guī)模的數(shù)據(jù)密集應用的編程領域，它是一個巨大的倒退

它是一個非最優(yōu)的實現(xiàn)，使用了蠻力而非索引

它一點也不新穎——代表了一種 25 年前已經(jīng)開發(fā)得非常完善的技術(shù)

它缺乏當前 DBMS 基本都擁有的大多數(shù)特性

它和 DBMS 用戶已經(jīng)依賴的所有工具都不兼容

筆者認為上面問題將 MapReduce 當前設計實現(xiàn)的弊端描述得恰如其分，一點不冤�？� MapReduce 論文，其核心實現(xiàn)基本上推翻之前數(shù)據(jù)庫幾乎所有優(yōu)秀研究成果，而采用了最原始最簡單最暴力的實現(xiàn)方式，將就能用，但實屬不雅。在互聯(lián)網(wǎng)業(yè)務之局外人看來，特別在于數(shù)據(jù)庫這幫學院派人士看來，類似處理方式無異于鼠目寸光、飲鴆止渴、開歷史之倒車。但身居互聯(lián)網(wǎng)行業(yè)久矣，我深知互聯(lián)網(wǎng)行事作風：快、糙、猛�；ヂ�(lián)網(wǎng)做事，能用就行，快速占領市場，管什么狗屁規(guī)矩。類似鄧小平先生那句名言：不管白貓黑貓，抓住老鼠就是好貓。我管你們數(shù)據(jù)庫之前如何設計精巧，今天要快速搞定我大 Google 大數(shù)據(jù)，為何不能做 trade-off。

從 MapReduce 之后，緊接著 2006 年 Google 再發(fā)大作《Bigtable: A Distributed Storage System for Structured Data》，BigTable 則是完全瞄準在線數(shù)據(jù)處理領域，講述了用于存儲和管理結(jié)構(gòu)化數(shù)據(jù)的分布式存儲系統(tǒng)，其建立在 GFS、MapReduce 等基礎之上。該論文啟發(fā)了后期的很多的 NoSQL 數(shù)據(jù)庫，包括 Cassandra、HBase 等。如果說 MapReduce 完全專注于離線批量大數(shù)據(jù)處理 / 計算，則 BigTable 可以說和數(shù)據(jù)庫完全在同一戰(zhàn)場。可以想象適時諸多計算機學院派大牛當面對 BigTable 論文時必定搖頭嘆息：孺子不可教也。之后整個大數(shù)據(jù)行業(yè)借助 Hadoop 生態(tài)春風，蓬勃發(fā)展，至今十年有余，催生諸多云計算、大數(shù)據(jù)產(chǎn)品的市場。

在此，我想重申我的觀點，大數(shù)據(jù)是大數(shù)據(jù)時代之下系統(tǒng)演化結(jié)果，是更加貼近大數(shù)據(jù)場景下用戶處理數(shù)據(jù)的訴求，而非開歷史倒車。大數(shù)據(jù)、大數(shù)據(jù)，我們討論的就是一個“數(shù)據(jù)爆炸”時代下如何進行有效地大規(guī)模數(shù)據(jù)處理問題。這個問題是數(shù)據(jù)庫之前未曾遇到、也未曾解決的特定問題，這些數(shù)據(jù)可能非結(jié)構(gòu)化、非關(guān)系化，可能是半結(jié)構(gòu)化的 Nginx 日志或者是用戶上傳的圖片、再或者可能是整個城市大腦的交通探頭高清視頻數(shù)據(jù)。這些數(shù)據(jù)用傳統(tǒng)的、狹義的關(guān)系型數(shù)據(jù)庫無法解決，因此大數(shù)據(jù)方案舍棄了數(shù)據(jù)庫模型中當前不適合上述數(shù)據(jù)處理的特性，犧牲某些功能從而換取大規(guī)模數(shù)據(jù)處理之能力。這是面向市場的、面向問題的、積極應對需求變化的技術(shù)做法，不教條也不做作。誠然，我相信大數(shù)據(jù)領域中某些領域，例如在處理關(guān)系數(shù)據(jù)事務型或者分析型場景下，可能仍然有大量數(shù)據(jù)庫理論發(fā)揮作用，甚至看上去像一個數(shù)據(jù)庫系統(tǒng)，如 Google Spanner;但在更大的數(shù)據(jù)處理與分析領域，我們將使用更多更分門別類的數(shù)據(jù)處理和存儲方式，這類方式完全異于傳統(tǒng)數(shù)據(jù)庫，例如機器學習、例如圖像識別。同時，我們可以預見，隨著整個物理世界更多地數(shù)據(jù)化(上篇我們曾經(jīng)討論，凡是有利于加速信息生成、采集、傳輸、處理、反饋的技術(shù)都能夠創(chuàng)造市場價值)，而更多的物理社會數(shù)據(jù)化(IOT)、網(wǎng)絡化(5G)勢必造成更加復雜多樣的數(shù)據(jù)處理需求類型，進而可以預見未來大數(shù)據(jù)處理會更加多樣化，大數(shù)據(jù)分工于數(shù)據(jù)庫系統(tǒng)，而接下來大數(shù)據(jù)同樣內(nèi)部面臨巨大的分工：更多更垂直更定制化的大數(shù)據(jù)系統(tǒng)將源源不斷產(chǎn)生，以應對快速爆炸的數(shù)據(jù)時代。社會分工理論在此同樣具備適用性。

Google 大數(shù)據(jù)：機遇和失誤

前文已述，Google 確實在技術(shù)和理論高度創(chuàng)造了”大數(shù)據(jù)“的概念，Google 無償將其技術(shù)框架理論貢獻給開源社區(qū)，整體上有效促進大數(shù)據(jù)開源社區(qū)以及周邊行業(yè)發(fā)展，以至于最終開源大數(shù)據(jù)社區(qū)蓬勃發(fā)展成就一方霸業(yè)，Google 勇氣可嘉精神可嘆。但至始至終，Google 在大數(shù)據(jù)領域除了成就其技術(shù)影響力美名之外，基本毫無所獲，遑論從云市場大數(shù)據(jù)獲益。Google 確實起了大早趕了晚集。究其原因，大概如下：

• 缺少對于云計算的重視和投入

試看當前的技術(shù)變現(xiàn)手段，最為直接即是云計算領域。任何一個技術(shù)領先的技術(shù)型產(chǎn)品，無論 IaaS、PaaS 甚至是 SaaS 的技術(shù)型產(chǎn)品，放置云上進行售賣乃變現(xiàn)之最快途徑。Google 早年對此市場似乎有些暈頭轉(zhuǎn)向，毫無章法，以至于錯失諸多大數(shù)據(jù)技術(shù)商業(yè)變現(xiàn)機會。

看最近 Google 似乎已經(jīng)轉(zhuǎn)換云市場策略，在 Google Cloud 上大量鋪開其核心產(chǎn)品，但可惜由于開源大數(shù)據(jù)早已成為業(yè)界標準，Google 自行一套的大數(shù)據(jù)產(chǎn)品體系不一定能夠討得用戶歡心。生不逢時。

• 缺乏對于開源社區(qū)的重視和投入

Google 以技術(shù)起家，十分重視技術(shù)影響力建設，以至于一直以來都是世界各大 IT 人員心中的技術(shù)燈塔。但從某種角度而言，技術(shù)影響力若無法變現(xiàn)，包括人才變現(xiàn)、營收變現(xiàn)，均是徒有虛名。Google 以三駕馬車敲開大數(shù)據(jù)大門，雖打開一嶄新行業(yè)，但概念雖新、落地很難，Google 顯然缺乏讓大數(shù)據(jù)在整個行業(yè)落地的動力和想法。同時，萬萬沒想到開源社區(qū)竟然依樣畫葫蘆”山寨“一把并最終形成 Hadoop 生態(tài)體系，并最終受眾眾多，用戶甚廣，時至今日 Hadoop 體系早已成為大數(shù)據(jù)行業(yè)事實標準，而其祖師爺 Google 未能實質(zhì)獲得任何可見好處，有點像祖師爺?shù)募夹g(shù)被江湖小輩盜版后發(fā)家致富，最終餓死祖師爺了。試想，如果當年 Jeff Dean 公開 MapReduce、GFS 論文同時，直接開放一套剝開 Google 內(nèi)部系統(tǒng)依賴的完整開源軟件。以 Google 自身強大的技術(shù)號召力，開源社區(qū)絕對不敢造次、多半服從 Google 技術(shù)生態(tài)。由此 Google 基本控制了大數(shù)據(jù)生態(tài)社區(qū)，后續(xù)云計算變現(xiàn)順水推舟。但，Google 錯失定義開源大數(shù)據(jù)軟件機會，一失足成千古恨。

不過，Google 何等聰明伶俐，早已洞察一切。現(xiàn)在的 Google，從 TensorFlow、Kubernetes、Beam 開始，在技術(shù)開放之初，發(fā)表論文之時，就順便開源一套軟件技術(shù)內(nèi)核，并投入重金支持開源社區(qū)構(gòu)建。對于 Google 而言，社區(qū)即標準、社區(qū)即流量、社區(qū)即商業(yè)，一切都可以導向未來的商業(yè)化變現(xiàn)，長線投資、長期發(fā)展;而對于開源社區(qū)，如此巨頭花重金支持生態(tài)發(fā)展，拍手稱贊何樂不為。各取所需各獲所利。

Google 云的先發(fā)后至

前文已述 Google 在云計算方面的創(chuàng)新與失誤，系列文章的下篇我們還會深入討論云計算行業(yè)的林林總總。但此刻我們更多關(guān)注與盤點 Google 云的失誤。Google 云在筆者看來犯了數(shù)個錯誤，這些錯誤在聰明如 Google 看來一定早已知曉，但種種原因改變的進展遲緩，特別是相對于亞馬遜 /AWS 而言，更是顯得后知后覺：

Google 云是服務 B 端市場的，但明顯 Google 云似乎一直沒有意識到其主要客戶是 B 端企業(yè)。不得不承認，Google 公司圍繞消費者的 C 端產(chǎn)品固然強大，但 B 端產(chǎn)品思路以及市場策略實屬抽風。Google 一直在強調(diào)自己的云標簽是“人工智能”，試圖通過拉入 AlphaGo 等重磅公關(guān)事件來提升用戶對于 Google 云的認可度。AlphaGo 火了人工智能，也順便幫 Google 的 AI 能力大大 PR 了一把，但明顯這部分流量并未給 Google 云帶來有效的轉(zhuǎn)化，倒是后邊大量云計算廠商通過開源深度學習引擎再次“撿漏”。另外，試問人工智能能夠帶來多少計算資源消耗，人工智能又能夠提升多少云計算客戶基數(shù)。很多情況下，在機器學習領域，一次數(shù)據(jù) Training 足夠、使用開源軟件足夠，小公司暫時沒有能力也沒有數(shù)據(jù)進行 Training、大公司有數(shù)據(jù)但大都自行部署開源機器學習引擎自己構(gòu)建機器學習平臺，何來大客戶、何來大營收?人工智能在當前整個云計算生態(tài)以及大數(shù)據(jù)生態(tài)最多算個云計算公司產(chǎn)品黏性，再不濟就只能是市場噱頭，叫好不叫座。 按照企業(yè)基因?qū)W說，天生缺 toB 基因的 Google，想在云計算方面要靠全方位無死角地伺候 B 端客戶，試看 Google 天生自帶高貴基因，似乎難以鋪廣開來。

Google 云計算是服務年薪百萬級的 Google 員工，而非行業(yè)普通開發(fā)者水平;服務的是數(shù)億用戶的業(yè)務規(guī)模，而非行業(yè)普通業(yè)務水平。早期大量 Google 云產(chǎn)品均是服務內(nèi)部的產(chǎn)品在云上的“云化版”，這類系統(tǒng)天生有個悖論，論穩(wěn)定性、論成熟性、論領先性，這類系統(tǒng)絕對無出其右，但高射炮打蚊子，各位看官可要清楚 Google 云平臺面對的企業(yè)內(nèi)部員工可是年薪百萬級別起的軟件工程師，試問這類工程師其專業(yè)水平可是整個行業(yè)平均水平?Google 云平臺服務的是 Google 內(nèi)部業(yè)務技術(shù)開發(fā)水平，這些業(yè)務方動輒數(shù)億用戶、動輒 PB 數(shù)據(jù)、動輒數(shù)百人團隊，試問這類業(yè)務規(guī)�？墒钦麄�行業(yè)平均規(guī)模?Google 云拿一個超越于當前年代的產(chǎn)品，試圖讓用戶搬云遷站，其改造成本有多高? 其維護成本有多高?有多少用戶愿意使用類似產(chǎn)品，或者接受如此改造?常言道，步子邁大了容易扯著 X，話糙理不糙。

尊重市場是任何一家商業(yè)化公司活下來的最高法則。但令人嘖嘖稱奇的是，諸如強大如 Google、聰明如 Google 仍然在不停犯類似錯誤。例如，不可能因為 Google 內(nèi)部廣泛采用 BigTable 因此就要在云上勸說用戶放棄使用 Mysql 轉(zhuǎn)而投入使用 BigTable。人人皆知從一個關(guān)系型數(shù)據(jù)庫遷移到 NoSQL 數(shù)據(jù)庫的改造難度，勢必極大增加用戶改造上云成本。我們一定是要讓用戶遷云過程中進行全面的代碼改造再行上云，還是先將客戶收入囊中循循善誘、徐徐圖之。這個是技術(shù)導向和市場導向兩類不同思路，麻煩就在大量云計算公司往往有技術(shù)導向的可能性以及傾向性。當前，整個云計算市場在燒錢爭搶市場的階段，猶如當年快的與滴滴燒錢培養(yǎng)用戶打車習慣的階段，流量為王、用戶基數(shù)為王、最大規(guī)模占據(jù)市場份額為王。任何成功商業(yè)模式均需建立在龐大的市場規(guī)模之上，無規(guī)模不商業(yè)，當用戶基數(shù)一到、資源消耗一到，后續(xù)任何的服務增值、利潤打造、云市場買賣平臺構(gòu)建均基于此可以做長線演化。但用戶基數(shù)是 0 到 1 的問題，此問題不解何來討論商業(yè)模式?

Google 云在今年四月適才剛剛舉辦了 Google Cloud NEXT 2019，InfoQ 隨即給出了一個忍俊不禁的報道《谷歌 Cloud NEXT 重磅盤點：終于想起云做的是 ToB 生意》，看得出來諸位 IT 同仁對于之前 Google 云的評價。

社區(qū)

Hadoop：開源大數(shù)據(jù)的基石

Hadoop 于 2005 年問世。之前，Doug Cutting 和 Mike Cafarella 已經(jīng)拜讀過 Google 的 GFS 論文，并且自己“手工造輪子”實現(xiàn)自己的 Google 分布式文件系統(tǒng)(最初稱為 Nutch 分布式文件系統(tǒng)的 NDFS，后來改名為 HDFS 或 Hadoop 分布式文件系統(tǒng))。在 2004 年時候，Google 發(fā)表神作《MapReduce: Simplified Data Processing on Large Clusters》，上述兩位正在構(gòu)架開源搜索引擎的大牛在考慮構(gòu)建 Nutch webcrawler 的分布式版本正好需要這套分布式理論基礎。因此，上述兩位社區(qū)大�；�于 HDFS 之上添加 MapReduce 計算層。他們稱 MapReduce 這一層為 Hadoop，由于 Hadoop 核心原理均是基于上述兩篇論文，即 MapReduce 以及 GFS，其本身在技術(shù)理論上并無創(chuàng)新，更多是“山寨”實現(xiàn)。對于技術(shù)原理感興趣的看官可自行閱讀 Google 原作立刻了解各自原理，而對于 Hadoop 發(fā)展歷史感興趣的可以推薦閱讀下 Marko Bonaci 的《The history of Hadoop》。

 

 

Hadoop 技術(shù)相比于 Google 原作并無新意，甚至在 GFS 系統(tǒng)細節(jié)方面折扣實現(xiàn)不少。但筆者在此并無討論技術(shù)差異點的打算，我仍然回到老本行，從產(chǎn)品或者市場角度去探討 Hadoop 成功因素以及給我們的啟示。

在筆者看來，Hadoop 體系能夠成功，并在數(shù)據(jù)處理市場占據(jù)一席之地，其初期核心因素就在于以下幾點：

時機。彼時互聯(lián)網(wǎng) Web 2.0 風頭正緊，大量用戶與網(wǎng)站交互行為爆炸式增長，如何使用廉價的服務器(大量互聯(lián)網(wǎng)創(chuàng)業(yè)公司就是窮鬼，買不起大小型機)去分析各類網(wǎng)站數(shù)據(jù)的業(yè)務需求已經(jīng)迫在眉睫。此時，大量 Top 互聯(lián)網(wǎng)公司有數(shù)據(jù)、有需求、有硬件，就缺一個廉價的數(shù)據(jù)分析系統(tǒng)。于是乎，開源、免費的 Hadoop 工具正好鉆入此類大數(shù)據(jù)市場空檔，迅速占領了核心種子客戶群體，并為后續(xù)市場推廣奠定了群眾基礎。

開源。開源在開發(fā)者社區(qū)感染力不容小覷。Cutting 和 Cafarella 通過開源(以及 HDFS 的源代碼)確保 Hadoop 的源代碼與世界各地可以共享，最終成為 Apache Hadoop 項目的一部分。Google 此時并未意識到開放論文僅僅自我精神爽了一次：讓爾等看看我等技術(shù)影響力;實際上并未從長遠去思考大數(shù)據(jù)技術(shù)影響力構(gòu)建以及更加長遠的云計算商業(yè)生態(tài)構(gòu)建�；ヂ�(lián)網(wǎng)時代下，大量軟件被開發(fā)者以及背后的互聯(lián)網(wǎng)商業(yè)公司作為開源系統(tǒng)貢獻出來，整個互聯(lián)網(wǎng)開發(fā)者行業(yè)已經(jīng)被開源社區(qū)完全洗腦，仿佛開源就是人類燈塔，閉源就是萬惡不赦。于是，此時，一個開源的、免費的、感覺挺符合互聯(lián)網(wǎng)精髓的大數(shù)據(jù)處理軟件出現(xiàn)在各大互聯(lián)網(wǎng)公司圈中，迅速在互聯(lián)網(wǎng)大數(shù)據(jù)處理領域觸達了這部分市場群體。

商業(yè)。早年開源軟件皆靠諸位開源運動人士在業(yè)界做社區(qū)用戶推廣，這波人本身毫無金錢匯報全靠一腔精神熱血。但本質(zhì)上來說，人類以及人類社會都是趨利性的，沒有利益驅(qū)動的市場行為終究無法持續(xù)。因此，早期沒有找到合適盈利模式的開源軟件一直發(fā)展緩慢，靠類似 Richard Stallman 類似開源黑客斗士去做市場推廣，市場效率之低下。后期，在 Linux 商業(yè)公司紅帽逐步摸索出開源軟件變現(xiàn)模式后，其他開源軟件也紛紛仿效。Hadoop 一時間背后迅速成立三家公司，包括 Cloudera、HotonWorks、MapR，這些公司盈利潛力完全都依賴于 Hadoop 開源生態(tài)的規(guī)模，因此，三家公司都會盡不遺余力地推進 Hadoop 生態(tài)發(fā)展，反過來促進了 Hadoop 整個生態(tài)用戶的部署采用率。到大數(shù)據(jù)市場更后期的時代，其商業(yè)競爭更趨激烈。以 Kafka、Spark、Flink 等開源大數(shù)據(jù)軟件為例，在各自軟件提交到 Apache 基金會之時創(chuàng)始人立刻創(chuàng)辦商業(yè)公司，依靠商業(yè)推進開源生態(tài)建設，同時通過收割生態(tài)最終反哺商業(yè)營收。

最終 Hadoop 在生態(tài)建設上獲得了巨大的成功，其影響力在開源業(yè)界開創(chuàng)了一個嶄新領域：大數(shù)據(jù)處理可見一斑。我們從如下幾個維度來看看 Hadoop 生態(tài)成功的各類體現(xiàn)：

Hadoop 的技術(shù)生態(tài)

不得不承認，Hadoop 有技術(shù)基座的先天優(yōu)勢，特別類似 HDFS 的存儲系統(tǒng)。后續(xù)各大 Hadoop 生態(tài)圈中的大數(shù)據(jù)開源軟件都多多少少基于 Hadoop 構(gòu)建的技術(shù)底座。故而，大量大數(shù)據(jù)生態(tài)后起之秀基本均源于 Hadoop，或者利用 Hadoop 作為其基礎設施，或者使用 Hadoop 作為上下游工具。此類依存共生關(guān)系在整個 Hadoop 社區(qū)生態(tài)已蔚然成風，越多大數(shù)據(jù)開源系統(tǒng)加入此生態(tài)既收割現(xiàn)有大數(shù)據(jù)生態(tài)客戶流量，同時亦添加新功能進入 Hadoop 社區(qū)，以吸引更多用戶使用 Hadoop 生態(tài)體系。就好比淘寶買家賣家相互增長，形成商業(yè)互補，相輔相成。

Hadoop 的用戶生態(tài)

前文已述，優(yōu)秀的開源(免費)系統(tǒng)確實非常容易吸收用戶流量、提升用戶基數(shù)，這個早已是不爭事實。通過開源 (免費) 的系統(tǒng)軟件鋪開發(fā)者市場、培養(yǎng)開發(fā)者習慣、籌建開發(fā)者社區(qū)，早已是開源軟件背后商業(yè)公司的公開市場打法，這就類似通過免費 APP 培養(yǎng)海量客戶技術(shù)，最終通過收割頭部客戶實現(xiàn)營收�；蛘吆帽纫豢钣螒�，大部分可能均是免費玩家，但用戶基數(shù)達可觀規(guī)模之時，一定涌現(xiàn)出不少人民幣玩家，并通過他們實現(xiàn)整體營收。當前風頭正緊的開源大數(shù)據(jù)公司，包括 DataBricks(Spark)、Confluent(Kafka)、Ververica(Flink)莫不如此。在開源軟件競爭激烈日趨激烈的環(huán)境下，其背后若無商業(yè)公司資金支撐，其背后若無市場商業(yè)團隊運營支撐，當年寫一個優(yōu)秀的開源軟件就憑”酒香不怕巷子深“的保守概念，現(xiàn)如今早已推不動其軟件生態(tài)圈發(fā)展。試看當前大數(shù)據(jù)生態(tài)圈，那些日暮西山、愈發(fā)頹勢的開源軟件，其背后原因多多少少就是缺乏商業(yè)化公司的運作。

Hadoop 的商業(yè)生態(tài)

大量商業(yè)公司基于 Hadoop 構(gòu)建產(chǎn)品服務實現(xiàn)營收，云計算公司直接拉起 Hadoop 體系工具作為大數(shù)據(jù)云計算服務，軟件集成商通過包裝 Hadoop 引擎提供客戶大數(shù)據(jù)處理能力，知識機構(gòu)(包括書籍出版社、Hadoop 培訓機構(gòu))通過培訓 Hadoop 開發(fā)運維體系實現(xiàn)營收和利潤，上述種種商業(yè)行為均基于 Hadoop 體系實現(xiàn)商業(yè)利潤。整個 Hadoop 開創(chuàng)了開源大數(shù)據(jù)的新概念，并由此養(yǎng)活大數(shù)據(jù)行業(yè)數(shù)不勝數(shù)的參與者。這波參與者享受了開源 Hadoop 的收益，同時也在為 Hadoop 貢獻知識。

如果說 Google 三篇論文發(fā)表后敲開了大數(shù)據(jù)時代的理論大門，但論文絕逼異常高冷、不接地氣、無法落地投產(chǎn)。真正人人皆用大數(shù)據(jù)的時代是直到開源社區(qū)提供了成熟的 Hadoop 軟件生態(tài)體系之后，我們才可以說企業(yè)界方才逐步進入到大數(shù)據(jù)時代�？梢哉f，當代 Hadoop 的誕生，為企業(yè)大數(shù)據(jù)應用推廣起到了決定性作用。

生態(tài)：大數(shù)據(jù)的林林總總

Google 三家馬車叩開了大數(shù)據(jù)理論大門，而 Hadoop 才真正開啟了行業(yè)大數(shù)據(jù)時代。前文已述，Hadoop 已經(jīng)早已超出 MapReduce(計算模型)和 HDFS(分布式存儲)軟件范疇。當前早已成為 Hadoop 大數(shù)據(jù)代名詞，指代大數(shù)據(jù)社區(qū)生態(tài)，無數(shù)號稱新一代、下一代的大數(shù)據(jù)技術(shù)無不構(gòu)建在 Hadoop 生態(tài)基石之上。下文我們分維度重點討論基于 Hadoop 生態(tài)之上的各式各樣大數(shù)據(jù)組件抽象。

高階抽象：讓人人成為大數(shù)據(jù)用戶

上篇道，數(shù)據(jù)庫兩位大拿 David J. DeWitt 以及 Michael Stonebraker 十分不待見 MapReduce 論文所訴理論，基本上是羽檄爭執(zhí)、口誅筆伐。其討伐重點之一便是使用 MapReduce 而拋棄 SQL 抽象，將實際問題的解決難度轉(zhuǎn)嫁用戶非正確的系統(tǒng)設計方式。同樣，這個批判確為 MapReduce 之缺陷，凡是正常人類絕逼感同身受。一個普普通通數(shù)據(jù)處理業(yè)務，用 SQL 表達多則百行、少則數(shù)行，熟練的數(shù)據(jù)工程師多則數(shù)小時少則數(shù)分鐘即可完成業(yè)務開發(fā)，輕松簡便。而一旦切換到 MapReduce，需要將 SQL 的直接業(yè)務表達子句換成底層各種 Map、Reduce 函數(shù)實現(xiàn)，少則數(shù)千行多達數(shù)萬行，導致整個數(shù)據(jù)開發(fā)難度陡增，業(yè)務開發(fā)效率抖降。

針對上述兩個問題，Google 和 Hadoop 兩條技術(shù)分別做出各自的技術(shù)方案：

Google 公司的 FlumeJava

Google 嘗試提供高階的 API 去描述數(shù)據(jù)處理 Pipeline，進而解決上述業(yè)務表達難題。FlumeJava 通過提供可組合的高級 API 來描述數(shù)據(jù)處理流水線，從而解決了這些問題。這套設計理念同樣也是 Apache Beam 主要的抽象模型，即 PCollection 和 PTransform 概念，如下圖：

 

 

這些數(shù)據(jù)處理 Pipeline 在作業(yè)啟動時將通過優(yōu)化器生成，優(yōu)化器將以最佳效率生成 MapReduce 作業(yè)，然后交由框架編排執(zhí)行。整個編譯執(zhí)行原理圖如下圖。

 

 

FlumeJava 更清晰的 API 定義和自動優(yōu)化機制，在 2009 年初 Google 內(nèi)部推出后 FlumeJava 立即受到巨大歡迎。之后，該團隊發(fā)表了題為《Flume Java: Easy, Efficient Data-Parallel Pipelines》的論文，這篇論文本身就是一個很好的學習 FlumeJava 的資料。

開源生態(tài)的 Hive

開源社區(qū)受眾更廣，其使用者更多，因此實際上開源社區(qū)對于開發(fā)效率提升訴求更高。但 Hadoop 社區(qū)似乎對于 SQL 情有獨鐘，更多將精力投入到 SQL-On-Hadoop 類的工具建設之中，最終，社區(qū)吸收 Facebook 提交給 Apache 基金會的 Hive，并形成了業(yè)界 SQL-On-Hadoop 的事實標準。

 

 

對于 Hive 而言，其官網(wǎng)特性說明充分闡釋了 Hive 的作為一套 Hadoop MapReduce 之上的 DSL 抽象之價值和特性：

Hive 是基于 Hadoop 的一個數(shù)據(jù)倉庫工具，可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射為一張數(shù)據(jù)庫表，并提供完整的 sql 查詢功能，可以將 sql 語句轉(zhuǎn)換為 MapReduce 任務進行運行。其優(yōu)點是學習成本低，可以通過類 SQL 語句快速實現(xiàn)簡單的 MapReduce 統(tǒng)計，不必開發(fā)專門的 MapReduce 應用，十分適合數(shù)據(jù)倉庫的統(tǒng)計分析。

Hive 是建立在 Hadoop 上的數(shù)據(jù)倉庫基礎構(gòu)架。它提供了一系列的工具，可以用來進行數(shù)據(jù)提取轉(zhuǎn)化加載(ETL)，這是一種可以存儲、查詢和分析存儲在 Hadoop 中的大規(guī)模數(shù)據(jù)的機制。Hive 定義了簡單的類 SQL 查詢語言，稱為 HQL，它允許熟悉 SQL 的用戶查詢數(shù)據(jù)。同時，這個語言也允許熟悉 MapReduce 開發(fā)者的開發(fā)自定義的 mapper 和 reducer 來處理內(nèi)建的 mapper 和 reducer 無法完成的復雜的分析工作。

于筆者這樣的產(chǎn)品經(jīng)理而言，其重要意義是將 MapReduce 進一步進行抽象為業(yè)務高階語言，讓更多不善于 Java/C++ 編碼的數(shù)據(jù)工程師能夠快速上手使用大數(shù)據(jù)工具進行數(shù)據(jù)分析，讓大數(shù)據(jù)業(yè)務開發(fā)成本更低、使用門檻更低、維護成本更低，讓傳統(tǒng)的、使用數(shù)據(jù)庫的數(shù)據(jù)分析師能夠基本無縫遷移到基于 Hadoop 的大數(shù)據(jù)平臺，從而極大擴展了大數(shù)據(jù)用戶群體，進一步拉動 Hadoop 社區(qū)的用戶生態(tài)以及商業(yè)生態(tài)。

從另外一個方面，Hive 作為一個 SQL-On-Hadoop 工具，為后續(xù)諸多大數(shù)據(jù)處理軟件提供了很好的表率：即越高階的業(yè)務抽象 API 能夠極大降低用戶開發(fā)門檻，拉動使用者基數(shù)。后續(xù)大量的開源閉源大數(shù)據(jù)系統(tǒng)都或多或少、有模有樣地提供了各自 SQL 方言，方便用戶更加快速、簡單地上手各自的大數(shù)據(jù)軟件。開源社區(qū)來看，從 Hive 開始，Presto、Impala、Spark、或者當前風頭正緊的 Flink，無不提供 SQL 作為高階數(shù)據(jù)分析語言。從閉源產(chǎn)品而言，阿里云的 MaxCompute、AWS 的 Redshift、Google 的 BigQuery，均提供各自 SQL 抽象以爭取更多云上開發(fā)人員的使用。據(jù)阿里對外宣傳的文章來看，基于 MaxCompute 的離線數(shù)倉體系服務了整個阿里集團數(shù)萬名員工之眾、每日運行作業(yè)達數(shù)百萬至多，以至于集團內(nèi)部包括數(shù)據(jù)工程師、產(chǎn)品經(jīng)理、運營人員、財務人員人人可以分析數(shù)據(jù)，人人可以提取數(shù)據(jù)，人人皆為數(shù)據(jù)分析師�？梢韵胂瘢�若非 SQL 這類高階業(yè)務表達語言助力，阿里集團大數(shù)據(jù)體系絕無可能有如此規(guī)模的受眾群體，亦不可能產(chǎn)生巨大業(yè)務價值。

實時計算：讓計算更快產(chǎn)生業(yè)務價值

大數(shù)據(jù)誕生之初給使用者最大的疑惑在于：為何計算如此之慢?彼時使用數(shù)據(jù)庫多數(shù)查詢在亞秒級別返回，使用數(shù)倉多數(shù)查詢在數(shù)秒級別返回，到 Hadoop 的大數(shù)據(jù)時代，大部分查詢在數(shù)分鐘、數(shù)小時、甚至于數(shù)天級別方才能夠查詢出結(jié)果。大數(shù)據(jù)、大數(shù)據(jù)，在一旦解決計算可處理的問題之后，時效性問題便擺上臺面。

大數(shù)據(jù)領域下，時效性分為兩個方面：

數(shù)據(jù)從用戶請求到最終呈現(xiàn)的實時性，這條路徑強調(diào)的是請求響應的及時性。

數(shù)據(jù)從發(fā)生到處理、并最終產(chǎn)生業(yè)務價值的全鏈路時效性，這條路徑強調(diào)的是數(shù)據(jù)鏈路及時性。

前者我們稱之為交互式計算領域，后者我們稱之為實時(流)計算領域。我一直認為交互式查詢是技術(shù)方面的優(yōu)化，是人人痛恨 MapReduce 計算模型太慢太落后的技術(shù)優(yōu)化，和產(chǎn)品形態(tài)并無太大關(guān)聯(lián)。而后者，則是整個大數(shù)據(jù)產(chǎn)品模型的變化，這是一種觸發(fā)式計算，有點類似阿里云的 FunctionCompute，或者是 AWS 的 Lambda;或者更加準確地定義是：基于事件流的實時流計算。我們通�？吹饺齻�系統(tǒng)：

第一代：Storm

Storm 是 Nathan Marz 的心血結(jié)晶，Nathan Marz 后來在一篇題為《History of Apache Storm and lessons learned》的博客文章中記錄了其創(chuàng)作歷史。這篇冗長的博客講述了 BackType 這家創(chuàng)業(yè)公司一直在自己通過消息隊列和自定義代碼去處理 Twitter 信息流。Nathan 和十幾年前 Google 里面設計 MapReduce 相關(guān)工程師有相同的認識：實際的業(yè)務處理的代碼僅僅是系統(tǒng)代碼很小一部分，如果有個統(tǒng)一的流式實時處理框架負責處理各類分布式系統(tǒng)底層問題，那么基于之上構(gòu)建我們的實時大數(shù)據(jù)處理將會輕松得多。基于此，Nathan 團隊完成了 Storm 的設計和開發(fā)。

 

 

上述將 Storm 類比為流式的 MapReduce 框架，我自認為特別貼切，因為這個概念類比更好向各位看官傳達了 Storm API 的 low-level 以及開發(fā)效率低下，這類基礎大數(shù)據(jù)的 API 讓業(yè)務人員參與編寫業(yè)務邏輯好比登天。同時，Storm 的設計原則和其他系統(tǒng)大相徑庭，Storm 更多考慮到實時流計算的處理時延而非數(shù)據(jù)的一致性保證。后者是其他大數(shù)據(jù)系統(tǒng)必備基礎產(chǎn)品特征之一。Storm 針對每條流式數(shù)據(jù)進行計算處理，并提供至多一次或者至少一次的語義保證。我們可以理解為 Storm 不保證處理結(jié)果的正確性。

第二代：Spark

Spark 在 2009 年左右誕生于加州大學伯克利分校的著名 AMPLab。最初推動 Spark 成名的原因是它能夠經(jīng)常在內(nèi)存執(zhí)行大量的計算工作，直到作業(yè)的最后一步才寫入磁盤。工程師通過彈性分布式數(shù)據(jù)集(RDD)理念實現(xiàn)了這一目標，在底層 Pipeline 中能夠獲取每個階段數(shù)據(jù)結(jié)果的所有派生關(guān)系，并且允許在機器故障時根據(jù)需要重新計算中間結(jié)果，當然，這些都基于一些假設 a)輸入是總是可重放的，b)計算是確定性的。對于許多案例來說，這些先決條件是真實的，或者看上去足夠真實，至少用戶確實在 Spark 享受到了巨大的性能提升。從那時起，Spark 逐漸建立起其作為 Hadoop 事實上的繼任產(chǎn)品定位。

在 Spark 創(chuàng)建幾年后，當時 AMPLab 的研究生 Tathagata Das 開始意識到：嘿，我們有這個快速的批處理引擎，如果我們將多個批次的任務串接起來，用它能否來處理流數(shù)據(jù)?于是乎，Spark Streaming 就此誕生。相比于 Storm 的低階 API 以及無法正確性語義保證，Spark 是流處理的分水嶺：第一個廣泛使用的大規(guī)模流處理引擎，既提供較為高階的 API 抽象，同時提供流式處理正確性保證。 有關(guān)更多 Spark 的信息，筆者推薦 Matei Zaharia 關(guān)于該主題的論文《 An Architecture for Fast and General Data Processing on Large Clusters》:

 

 

第三代：Flink

Flink 在 2015 年突然出現(xiàn)在大數(shù)據(jù)舞臺，然后迅速成為實時流計算部分當紅炸子雞。從產(chǎn)品技術(shù)來看，F(xiàn)link 作為一個最新的實時計算引擎，具備如下流計算技術(shù)特征：

完全一次保證：故障后應正確恢復有狀態(tài)運算符中的狀態(tài)

低延遲：越低越好。許多應用程序需要亞秒級延遲

高吞吐量：隨著數(shù)據(jù)速率的增長，通過管道推送大量數(shù)據(jù)至關(guān)重要

強大的計算模型：框架應該提供一種編程模型，該模型不限制用戶并允許各種各樣的應用程序在沒有故障的情況下，容錯機制的開銷很低

流量控制：來自慢速算子的反壓應該由系統(tǒng)和數(shù)據(jù)源自然吸收，以避免因消費者緩慢而導致崩潰或降低性能

亂序數(shù)據(jù)的支持：支持由于其他原因?qū)е碌臄?shù)據(jù)亂序達到、延遲到達后，計算出正確的結(jié)果。

完備的流式語義：支持窗口等現(xiàn)代流式處理語義抽象

你可以理解為整個實時計算產(chǎn)品技術(shù)也是時間發(fā)展而逐步成熟發(fā)展而來，而上述各個維度就是當前稱之為成熟、商用的實時計算引擎所需要具備的各類典型產(chǎn)品技術(shù)特征。Flink 是當前能夠完整支持上述各類產(chǎn)品特征參數(shù)的開源實時流處理系統(tǒng)。

全家桶：一套引擎解決“所有”大數(shù)據(jù)問題

Flink 和 Spark：All-In-One

大數(shù)據(jù)全家桶其實是一個實打?qū)嵉漠a(chǎn)品問題：從大數(shù)據(jù)社區(qū)反饋的情況來看，對于大部分大數(shù)據(jù)處理用戶，實際上的大數(shù)據(jù)處理訴求分類有限，基本上在 Batch(60%+)、Stream(10%+)、Adhoc(10%+)、其他(包括 ML、Graph 等等)。對于任何一個大數(shù)據(jù)處理引擎深入做透一個領域后，勢必會考慮下一步發(fā)展，是繼續(xù)做深做專，抑或還是橫向擴展。做又紅又專?從商業(yè)來看，這個領域的市場規(guī)模增長可能有限，眼瞅著都到天花板了;但從橫向角度來看，周邊大數(shù)據(jù)引擎虎視眈眈，隨時都有殺入我們現(xiàn)有市場之中。面對市場，各色需求可窮舉;面對技術(shù)，引擎基礎業(yè)已夯實，為何不周邊突破擴展，開拓新的大數(shù)據(jù)領域。Spark 從批入手，針對 Hadoop 處理性能較差的問題，將 Spark 的 Batch 功能做成一個“爆款應用”，同時提供 Spark Streaming、Spark ML，前期靠 Spark Batch 為整個 Spark 社區(qū)用戶倒流，并吸收為 Spark Streaming、Spark ML 的客戶。而通過 Spark 大數(shù)據(jù)全家桶功能，Spark 產(chǎn)品構(gòu)建一個粘性的護城河。大量中小用戶一旦全功能上了 Spark，大家理解后續(xù)很難因為 Spark 某個功能點不太滿足需求而拋棄使用 Spark。

Spark 從批入手，嘗試在一個技術(shù)棧體系內(nèi)統(tǒng)一基礎的大數(shù)據(jù)處理;在另外一個方向，F(xiàn)link 從 Stream 入手，在構(gòu)建出 Flink Stream 強大生態(tài)后，也在考慮布局 Flink Batch，從 Stream 切入 Batch 戰(zhàn)場。

下圖是 Spark 的軟件棧體系：

 

 

下圖是 Flink 的軟件棧體系：

 

 

兩者在產(chǎn)品功能棧上早已十分相似，缺的是各自薄弱領域的精細化打磨。在此，我們不討論兩者功能強弱分布，畢竟本文不是一個產(chǎn)品功能介紹文章。未來兩個系統(tǒng)鹿死誰手花落誰家，各位看官拭目以待吧。

Beam: One-Fits-All

前文已述，早期 Google 在大數(shù)據(jù)領域純粹扮演了一個活雷鋒的角色，以至于整個開源大數(shù)據(jù)生態(tài)蓬勃發(fā)展起來，并最終形成完整的大數(shù)據(jù)商業(yè)生態(tài)之時，Google 基本門外一看客，眼瞅著自己的技術(shù)理論在開源社區(qū)發(fā)揚光大，自己沒撈半點好處。適時，Google 云業(yè)已發(fā)展起來，并拉起諸多祖師爺級別的產(chǎn)品技術(shù)服務客戶，例如 BigTable。常理而言，BigTable 開創(chuàng) NoSQL 大數(shù)據(jù)之先河，其 Paper 位列 Google 大數(shù)據(jù)三駕馬車之中，技術(shù)地位可見一斑。再看社區(qū) HBase，乃直接“抄襲”Google BigTable 論文理論，實乃徒子徒孫之技術(shù)。但最終，Google 云發(fā)布 BigTable 產(chǎn)品之時，為了考慮社區(qū)產(chǎn)品兼容性以及用戶上云遷移成本，竟然不得不兼容 HBase 1.0 的 API 接口。可以想象，BigTable 項目組成員當時內(nèi)心感覺只能是：簡直日了狗!但一切為了云計算營收，BigTable 產(chǎn)品放下技術(shù)執(zhí)念選擇兼容 HBase 接口，實屬難得!我們?yōu)?Google 尊重市場而放下身段的行為點贊!

Google 受此大辱，吃此大虧，當然會痛定思痛，考慮建設開源社區(qū)并嘗試力圖控制社區(qū)。于是在此背景之下，Apache Beam“粉墨登場”。Google 考慮問題之核心不在于是否要開源一個大數(shù)據(jù)處理系統(tǒng)(當時社區(qū) Spark 已經(jīng)蔚然成風，F(xiàn)link 的發(fā)展同樣亦是扶搖直上，似乎社區(qū)并無缺少一個好的大數(shù)據(jù)引擎)，而僅僅缺乏開源社區(qū)大數(shù)據(jù)處理接口之統(tǒng)一，包括將核心的批處理以及流處理接口統(tǒng)一。而之前 Google 內(nèi)部的 FlumeJava 一直承擔大數(shù)據(jù) Data Pipeline 之 API 定義角色，于是想當然地從內(nèi)部將之前的 FlumeJava 接口進行抽象改進，提供統(tǒng)一的批流處理 API 后在 2016 年貢獻提交給 Apache 基金會。試圖通過定義一套統(tǒng)一的 API 抽象層，說服各個廠商實現(xiàn)該套抽象，即可完成 API 統(tǒng)一的千秋大業(yè)，并為用戶遷移 Google 云上埋下最大伏筆。

 

 

此類打法構(gòu)思只能是技術(shù)人員對于大數(shù)據(jù)社區(qū)發(fā)展不切實際的夢想，或者是 Google 實在太高估自己的技術(shù)影響力，認為只要 Google 技術(shù)一出，開源社區(qū)絕對俯首稱臣，拉下老臉哭著喊著求兼容。但 Google 打錯算盤的是，從沒有一個市場追趕者角色制定標準來讓市場領導者來做適配，市場領導者憑什么鳥你。你區(qū)區(qū)一個追趕者，制定標準，挖下大坑，讓領導者來兼容你的標準絕對是癡人說夢。于是乎，在 Apache Beam 發(fā)布之后，除 Flink 社區(qū)意圖想聯(lián)合 Beam 社區(qū)一起做做技術(shù)影響力之外，其他開源大數(shù)據(jù)產(chǎn)品和 Beam 一直若即若離。大家都是明白人，都明白 Google 大力推動 Beam 的明修棧道暗度陳倉，我兼容你標準，最終你不是靠云上產(chǎn)品想把大家的流量全部收割了么。因此，開源社區(qū)難以有真心和 Beam 社區(qū)結(jié)成歃血同盟者，社區(qū)合作者多半皆是善于投機的機會主義者。一時間，Beam 的前景黯淡。

結(jié)語

本文瀏覽了整個大數(shù)據(jù)發(fā)展歷史，特別重點關(guān)注了數(shù)據(jù)計算處理部分的內(nèi)容。我們從程序本質(zhì)以及行業(yè)發(fā)展脈絡分別描述了大數(shù)據(jù)之前的程序時代以及數(shù)據(jù)庫時代，大數(shù)據(jù)當代的各類理論、系統(tǒng)、社區(qū)發(fā)展。我們觀察歷史，是讓我們有信心面對當前;我們分析當代，是讓我們有機會看清未來。未來整個云計算以及之上的大數(shù)據(jù)發(fā)展，已經(jīng)超出本文的討論范疇，但從上述歷史、當代分析能對未來其發(fā)展推測一二，歡迎大家自行思考。文章行文較為倉促，定有紕漏之處，望各位看官不吝賜教。

附錄

https://www.leiphone.com/news/201901/gLVJGxFuKtGfxwJ6.html

https://darkhouse.com.cn/blog/2

作者：宋詞

標簽： [db:TAGG]

版權(quán)申明：本站文章部分自網(wǎng)絡，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。