從大數據到數據庫,聊聊我對未來的看法

作爲一個從大數據轉行做數據庫的人,我自以爲能感受到兩個世界的異同。在這裏,斗膽聊下這個話題,以及對未來的看法。

大數據興起

從 70 年代關係型數據庫進入歷史舞臺,很長一段時間它幾乎是包打天下的選擇。你很可能可以用一套數據庫玩轉所有業務,你也不需要一個連的工程師來維護她。哪怕你也許業務複雜,需要不同的數據庫,但她們終究是還是數據庫,溫柔體貼。

這個黃金時代整整延續了 20 多年。

上世紀 90 年代人們開始討論「Big Data」。SGI 首席科學家 John Mashey 在一個名爲「Big Data… and the Next Wave of Infrastress」讓這個詞彙變得流行。那個時候,人們討論着硬盤容量和網絡帶寬,在未來數據爆炸的陰影下瑟瑟發抖。那個時候,互聯網公司是第一批真正嘗試解決大數據問題的先行者。有別傳統的運營方式讓它們率先面對了大數據時代 著名的 3V 問題(By Gartner)。

  • 容量(Volumn):爆炸性的交易量帶來爆炸性的數據容量。
  • 速度(Velocity):和在這個規模下仍提供高速的數據應用。
  • 多樣性(Variety): 以及爲了支持業務變更和複雜性所造成的數據多樣性。

與傳統公司不同,互聯網公司的數據單位價值偏低,但數據量極其龐大。而且它們並不一定是結構化的,並非完全能用 SQL 來處理。簡而言之,它們已經超出了當時數據庫的能力邊界。而當時的互聯網公司巨頭們如 Google 和 Amazon,紛紛選擇拋棄了傳統手段,重起爐竈,由此拉開了「大數據」時代的大幕。

有興趣的童鞋,可以翻翻下面的論文:

  • The Google File System - 2003
  • MapReduce: Simplified Data Processing on Large Clusters - 2004
  • Bigtable: A Distributed Storage System for Structured Data - 2006
  • Dynamo: Amazon’s Highly Available Key-value Store - 2007

也許你並不瞭解 GFS,Google 內的 MapReduce 或者 BigTable 具體是什麼樣子的。不過相信既然你看到了這裏,你一定聽說過 Apache Hadoop 和 NoSQL。Hadoop 加上屬於 NoSQL 的 HBase,就是以上面 Google 的幾篇論文爲基礎開發而成的。這是一個真正現象級的開源通用大規模分佈式數據存儲和處理套件。它的影響力是巨大的,稍具規模的互聯網公司就不得不用,稍有經驗的從業者就可以領取不菲的薪水,人人都以能向其提交一個補丁爲榮,更不用提一個實打實的 Committer,你都可以從他腦後看到光環。不管現在多少人宣稱 Hadoop 已死,XXX 是真理,但是以 Hadoop + NoSQL 爲基礎,所謂大數據基礎架構所帶來的想法變遷,一直延續到了今天,且並沒有太大變化:

  • 選用白菜價的硬件組成集羣,突出 Scale Out 而非 Scale Up。
  • 極度簡化和粗暴的計算模型。
  • 幾乎不經整理的存儲格式,在多種引擎之間共享,所謂數據湖。
  • 忽略 / 弱化一致性,拋棄關係模型,簡化甚至無視事務,所謂 NoSQL。

你可以說這是開源社區的威力,但追根究底還是 Google,Amazon 這些先行者卓有遠見的工作爲大家鋪平了道路。不過,有些反直覺的是:這些引用數幾千幾萬的論文其實並沒有提出巧奪天工的設計;相反,它們本質上是告訴了業界,把數據庫換成設計如此粗糙狂野的架構,仍然可以解決問題:就算你沒錢買超高端的軟硬件,只要你放寬心,告訴自己,無視一致性,忘掉精巧的優化執行器和存儲結構,忽略半結構化帶來的混亂,幹掉 SQL 語言,多僱幾個碼農,你仍然活的下去,而且可以活的還不錯。

這些到底爲我們帶來了什麼?且看曾經非常著名的 Sort Benchmark。

  • 2004 年,NEC Express 5800 / 1320 Xd 單機,價格可能介於 200-600 萬 USD 之間,1 分鐘排序 34G。
  • 2006 年,Fujitsu PrimeQuest 480 單機,2 年將結果推高 6G,1 分鐘排序 40G 數據;機器價格不可考。
  • 2007 年,麻省理工林肯國防實驗室,Bradley C. Kuszmaul 使用 TX-2500 磁盤集羣(550 萬 + USD),440 節點用 Infiband 串聯,使用了自制系統(文件系統,通信模塊),在經歷了無數硬件軟件故障之後,一分鐘內排序了 214GB 數據;該試驗相比之前的超豪華服務器,已經開始使用「便宜硬件」,但是使用自制軟件系統。
  • 2009年,Yahoo! 使用 Hadoop 以近似的總價(500 萬 USD,以單價反推)但近 1/3 的單價串聯了 1400 個白菜價節點集羣,得到了一倍多的速度,排序了 500G。而這裏 1400 的節點數是爲了湊整 500G / 1 分鐘,而非只能這麼多或者必須這麼多。

請允許我用一句詩來總結它的意義:「舊時王謝堂前燕,飛入尋常百姓家」。

王之蔑視

與業界的歡騰不同,當時數據庫研究者圈子對此的反應已經不是嗤之以鼻,而是痛心疾首了。這有點像,老師傅練了一輩子武藝,你突然告訴他,打架只要掄大錘就行了。

MapReduce: A major step backwards by David DeWitt & Michael Stonebraker

上面這篇文章是 DeWitt 和 Stonebraker 大神合寫的對 MapReduce 的批評。這兩尊是真神,DeWitt 是美國工程院院士,微軟 Jim Gray 實驗室老大,而石破天,則是圖靈獎獲得者。在他們看來,這破玩意拋棄了數據庫所有美好的特點,實現也醜陋,還接不上數據庫工具,簡直臭不可聞。文末,老人家們「酸酸」地說,我們很高興看到社區對這些技術感興趣,但是也別把我們幾十年的研究成果當 X 啊。

兩位的評論,哪怕延伸到整個大數據生態,就算放到時隔多年的今天,也還是套的上去。但這套糙快猛的理念催生的技術棧,已經無需贅述獲得了多大的成功。哪怕是數據庫圈內的人,也時有抱怨:老一輩的人有時候不夠 Open-Minded。所以,他們說錯了麼?

也許他們對業界面臨的困擾不夠感同身受,也許他們不夠有包容心。不過,他們對技術的判斷着實是精準到位的。

事實上,沒過多久,人們在大數據體系中引入了 SQL、MPP 引擎、列存,加入了向量化、JIT,實現了 CBO。對於數據庫圈外的童鞋們,有時你看社區興高采烈地宣稱,他們實現了多麼神奇的技術,彷彿普羅米修斯從天上帶來了火種,其實他們只是從十幾甚至幾十年前的故紙堆中汲取了養分。

是大數據社區的人無知無能因此重新「發明」數據庫界玩爛的技術麼?不,只是因爲業界等不了數據庫圈子慢慢悠悠匠心打磨:沒有合適的工具,他們每分每秒都在損失 $。且不說大規模分佈式交易型數據庫一直是老大難,就算脫開交易型場景不談,分佈式的分析型數據庫早已有之,卻也因爲包袱沉重,還沒來得及跟上時代的步伐,就被大數據的浪頭打的狼狽不堪。Pivotal 先是由 Greenplum 折騰了對接 Hadoop 的 HAWQ ,繼而被迫雙雙開源;就連 Teradata 這樣的巨擘也不得不支持 Hadoop。

只是,一旦社區步入小康,雖是野蠻生長的生態,也還是阻擋不了人們追求小資生活的決心:用戶希望友好、快速、高效、穩定的數據存儲和處理手段,這是亙古不變的需求。而這些,恰恰是數據庫領域多年積累所在。

摘自 pramodgampa.blogspot.com

現今的大數據生態,如同哥斯拉,強大而難以馴服。不管什麼場景,似乎都經不起它尾巴一掃。但若說乾淨靈巧地解決問題,卻是難如登天。畢竟狂野粗放基因的產物,不管如何演化,都很難優雅起來。對數據湖而言,開放形態加上公共存儲格式,能輕易串聯多種引擎,但也幾乎抹殺了精細整理數據的可能;而混沌的存儲體系和不受控的數據入口,也限制了整個體系可以伸展騰挪的空間。對 NoSQL 而言,孱弱或者乾脆不存在的事務,所謂最終一致性,小兒科的 SQL 支持,也都成爲人們詬病的理由。而整個圈子野蠻生長的開放體系,在得到巨大動能的同時,也使得用戶體驗幾乎不可能良好。這些種種,使得大數據生態很大程度上都只服務於工程師,而你需要一大票專家才能真的馴服大數據平臺。從這個角度看,MapR 變賣家當給 HP,Hortonworks 被收購,Cloudera 鉅虧股價狂瀉,都是必然的:大數據生態基本不可能做成類似 Oracle 這樣的標準件生意。

也許,更偏向於數據庫形態的方案,纔是更友善的方案;也許,隨着技術的成熟,我們還有機會回到黃金時代。

迴歸數據庫

隨着時間的推進,Google 這樣的巨人自己也忍受不了自己創造的怪物,又開始了新的探索:哪怕是 Google 這樣聰明腦袋匯聚的地方,也不想總是需要自己花心思處理一致性,或者用繁瑣的代碼實現 SQL 邏輯。

Spanner: Google’s Globally-Distributed Database - 2012

Spanner 是一個能像 NoSQL 一樣延展(甚至橫跨多個大陸),但卻支持傳統數據庫事務的分佈式交易型數據庫。它創造性地用原子鐘解決了以往分佈式事務一致性需要依賴中心節點,因而無法大規模擴展的問題。這算是拉開了所謂 NewSQL 的大幕。這啓發了很多項目,比如小強,比如我們的 TiDB。她們擁有對業務透明的 Sharding 設計和分佈式事務,良好的可擴容性,又兼顧了一致性,這讓分佈式體系很大程度上擁有單機數據庫近似的用戶體驗。不過有意思的是,哪怕論文最創新的點是基於原子鐘的分佈式事務,但是對很多人來說,它更大的意義仍然是:證明給一個類似 NoSQL 架構加上傳統數據庫特性,用來做傳統數據庫業務,是可行的(當然共識算法 Paxos / Raft 的應用也很重要)。天知道這背後經歷了多少試錯,這就是先行者的偉大。

至此,業界也許可以說解決了整個體系中最難啃的問題:分佈式交易型數據庫。而隨着技術不斷成熟,人們也逐漸開始接受這個新鮮事物:光就 TiDB 而言,從第一個用戶拿來做並不那麼 TP 的邊緣業務,到現在登上銀行核心系統。也許你在刷二維碼付費的時候,背後支撐你這筆交易的數據庫就是 TiDB。

對我們來說,現有的 Multi-Raft 體系,提供了可自由伸縮,對用戶透明的分片體系,以及可均衡的並行複製機制。以這些爲基礎,通過 Raft Learner 將數據從 TP 行存到 AP 列存進行異步異構複製但提供一致性讀取,我們得以整合了 TP 和 ODS 層,而且互相之間不影響,這就是今年我們折騰的 TiFlash。希望明年能嘗試進一步同樣通過 Raft 協議將列存引擎延伸到傳統的數倉業務,而統一更多場景。很多人不相信最終數據庫能做到一站式服務(Silver Bullet),能簡化到一個產品,去除平臺間數據的遷移。畢竟,有些設計的取捨很難兼顧。我個人的看法是,也許,但通過小心的設計,我們現在已經可以做到將不同的引擎無縫地整合到一個產品中。畢竟,經過這十多年的大數據浪潮,哪怕浪不再那麼高,社區終究沉澱下了寶貴的財富,前人設計的得失也好,強大的開源引擎如 Spark 也好(Spark 已經慢慢脫離野蠻生態直通雲霄了),甚至更多有經驗的小夥伴也好,這都成爲我們能借力的抓手,讓我們能有勇氣挑戰似乎不切實際的目標:讓用戶從大數據生態複雜的技術棧解放出來,讓數據平臺收斂到單一一個產品,因爲這纔是數據處理應有的模樣,哪怕這是一條很長很長的路。

作者介紹

馬曉宇 | PingCAP 分析型產品負責人

原文鏈接

https://zhuanlan.zhihu.com/p/97085692

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章