?

引子

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

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

沿大數據發展時間線，從產品、行業、技術多角度討論其發展脈絡，究其發展承其脈絡我們可以學習、借鑒、並最終推測未來大致走向。

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

站在雲高度提供獨一無二的視角去觀察大數據 / 雲計算的發展。

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

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

?

大數據史前

歷史

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

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

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

程序時代

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

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

我們可以將計算機 / 程序的發展脈絡簡單提煉出兩點，同時這兩點也會指導我們討論後續所有系統發展的一般客觀規律，即：

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

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

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

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

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

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

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

數據庫時代

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

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

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

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

數據處理一次社會化的大分工

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

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

?

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

SQL 與關系代數

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

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

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

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

在本小節的結束時間，我們附上有關數據庫發展 Timeline，希望數據庫的發展路線給大家看到整個數據庫發展時間脈絡 [註 2]。

大數據開發技術群：957205962

大數據十年回顧（1）：大數據史前的數據庫發展