從大數據到數據庫

做者：馬曉宇

做爲一個從大數據轉行作數據庫的人，我自覺得能感覺到兩個世界的異同。在這裏，斗膽聊下這個話題，以及對將來的見解。

大數據興起

從 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。

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

<center>摘自 pramodgampa.blogspot.com</center>

現今的大數據生態，如同哥斯拉，強大而難以馴服。無論什麼場景，彷佛都經不起它尾巴一掃。但若說乾淨靈巧地解決問題，倒是難如登天。畢竟狂野粗放基因的產物，無論如何演化，都很難優雅起來。對數據湖而言，開放形態加上公共存儲格式，能輕易串聯多種引擎，但也幾乎抹殺了精細整理數據的可能；而混沌的存儲體系和不受控的數據入口，也限制了整個體系能夠伸展騰挪的空間。對 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 已經慢慢脫離野蠻生態直通雲霄了），甚至更多有經驗的小夥伴也好，這都成爲咱們能借力的抓手，讓咱們能有勇氣挑戰彷佛不切實際的目標：讓用戶從大數據生態複雜的技術棧解放出來，讓數據平臺收斂到單一一個產品，由於這纔是數據處理應有的模樣，哪怕這是一條很長很長的路。

原文閱讀：https://pingcap.com/blog-cn/from-big-data-to-databases/