Google前工程師吐槽：收起你宣傳大數據的PPT吧！大數據已死，沒人Care資料大小、有人用才重要

隨著雲端運算時代的發展，大數據實際已經不復存在。在真實業務中，我們對大數據更多的是儲存而非真實使用，大量資料現在已經變成了一種負債，我們在選擇保存或者刪除資料時，需要充分考慮可獲得價值及各種成本因素。 

十多年來，人們一直很難從資料中獲得有價值的參考資訊，而這被歸咎於資料規模。「對於你的小系統而言，你的資料量太龐大了。」而解決方案往往是購買一些可以處理大規模資料的新機器或系統。但是，當購買了新的設備並完成遷移後，人們發現仍然難以處理、理解他們的資料。

你們可能已經意識到了，資料規模並不是問題關鍵所在。 

Google BigQuery 的創始工程師 Jordan Tigani

十多年來，我一直在為大數據搖旗呐喊。我是Google BigQuery 的創始工程師。作為團隊中唯一一個非常喜歡公開演講的工程師，我到世界各地參加會議，解釋我們將如何幫助人們抵禦即將到來的資料爆炸。我曾經在臺上即時查詢PB級的資料，證明無論你的資料有多大、有多糟糕，我們都能夠處理它，沒有任何問題。

▲ 這張照片是我在2012年在西班牙大資料會議上，警告巨大資料集的危險，並承諾如果他們使用我們的技術，就能獲得緩解。

在接下來的幾年裡，我花了大量時間解決使用者使用 BigQuery 遇到的問題。我與別人合著了兩本書，在其中深入研究了產品的使用方式。2018 年，我轉向了產品管理，我的工作主要是與客戶溝通以及分析產品指標，其中許多客戶是世界上的頭部企業。

讓我驚訝的是：大多數使用 BigQuery 的客戶並沒有真正的大數據。

即使是擁有大數據的客戶，也傾向於僅使用一小部分資料集。對於很多人來說，BigQuery 的出現就像科幻小說一樣——你真的不可能用其他任何方法這麼快地處理資料。然而，曾經是科幻小說的東西現在已經司空見慣，傳統的資料處理方式已經趕上來了。

這篇文章將解釋為什麼大數據時代已經結束。現在我們可以不再擔心資料大小，而是專注於如何使用它來做出更好的決策。我會展示一些圖表，這些圖表都是根據記憶手繪的，即便我有確切的數字，但我也不能分享它們。其實重要的是圖像形狀，而不是確切的值。

圖表背後的資料來自于日誌查詢、交易事後分析、基準測試結果（已發表和未發表）、客戶服務單、客戶調查研究、服務日誌和對已發表部落格文章的分析，也包括了一些我個人的直覺感知。 

宣傳大數據必不可少的 PPT，收起來吧！

在過去的 10 年中，每一個大數據產品的每一次推銷都以一張 PPT 開始，幻燈片大致像下圖這樣：

我們在Google使用這個幻燈片很多年了。當我轉到 SingleStore 時，他們雖使用的是自己的版本，但有著相同的圖表。我見過其他幾個供應商也有類似的圖表。這是「恐嚇」幻燈片：大數據來了！你需要買我賣的東西！

這其中傳達的資訊是，舊的資料處理方式將不再適用。資料產生的速度將使過去的資料系統陷入泥潭，接受新思想的人才能超越競爭對手。

不過，產生的資料量在增加，並不意味著它會成為每個人的問題。大多數應用程式不需要處理大量資料。這是採用傳統架構的資料管理系統復興的原因，SQLite、Postgres、MySQL都在強勁增長，而「NoSQL」甚至「NewSQL」系統卻停滯不前。

MongoDB是排名最高的 NoSQL 擴充資料庫，儘管多年來增長迅速，但最近略有下降。與 MySQL 或 Postgres 這兩個有絕對優勢的資料庫相比，它並沒有真正取得多大突破。如果大數據真的佔據了主導地位，那麼在經歷了這麼多年之後，我們應該看到一些不同的東西。

當然，分析系統的情況看起來有所不同，但在 OLAP 中，可以看到從本地部署到雲的巨大轉變，而且實際上沒有任何可與之相比的擴充雲端分析系統。

大多數人並沒有那麼多資料

從「大數據即將到來」的圖表中可以看出，很快每個人都會被他們的資料淹沒。十年過去了，這個現象還沒有出現。我們可以透過幾種方式驗證這一點:查看資料（定量地）、詢問人們是否有過大數據的感知經歷（定性地）、從基本原理（歸納地）思考分析。

在 BigQuery 工作時，我花了很多時間研究客戶規模。這裡的真實資料比較敏感，所以我不能直接分享任何數字。但我能確定的是，絕大多數客戶的資料儲存總量不到 1TB。當然，有的客戶確實有大量資料，但大多數組織，甚至一些相當大的企業，都只有中等規模的資料。

客戶的資料量大小遵循冪律分佈。最大的客戶擁有的儲存量是第二大客戶的兩倍，第三大的客戶儲存擁有量又是前者的一半，以此類推。雖然有數百 PB 級數據儲存量的客戶，但這種等級的很快就會減少。有成千上萬的客戶每月支付的儲存費用不到 10 美元，即半 TB 資料量的費用。在大量使用儲存服務的客戶中，資料儲存容量的中值遠小於 100GB。

我們在與行業分析師（Gartner、Forrester 等）交談後得到了進一步的印證。我們鼓吹我們處理巨量資料集的能力時，他們則會聳聳肩。「這很好，」他們說，「但絕大多數企業的資料倉庫都小於 1TB。」我們與業內人士交談時得到的普遍回饋是，100GB 是資料倉庫的合理數量級。這正是我們在基準測試中投入大量精力的地方。

我們的一位投資者決定弄清楚分析資料規模到底有多大，並調查了他的投資組合公司，其中一些是退出後的公司（要麼已經上市，要麼被更大的機構收購）。這些都是科技公司，它們傾向於擁有更大的資料量。他發現，在他的投資組合中，最大的 B2B 公司擁有大約 1TB 的資料，最大的 B2C 公司擁有大約 10TB 的資料。然而，大多數公司的資料量要少得多。

想要理解為什麼大數據這麼少，我們就要從資料的實際來源方面思考一下。假設你是一家中型企業，擁有 1000 名客戶。假設每個客戶每天都下 100 個商品的新訂單。這種頻率已經非常高了，但每天產生的資料可能還不到 1MB。三年後，你只有 1GB，而產生 1TB 資料需要數千年的時間。

或者，假設你的行銷資料庫中有一百萬個線索，你正在進行幾十個活動。你的潛在客戶表可能還不到 1GB，在每個活動中跟蹤每個潛在客戶可能也只產生幾 GB 資料。在合理的縮放範圍內，很難想像如何增長到巨量資料。

舉一個具體的例子，我 2020-2022 年在 SingleStore 工作，當時它是一家進入 E 輪的快速增長的公司，擁有可觀的收入和獨角獸估值。如果將我們的財務資料倉庫、客戶資料、行銷活動跟蹤記錄，以及服務日誌資料相加，可能也只有幾 GB 的資料規模。無論怎麼看，這都不是大數據。

儲存和計算分離中的儲存偏差

現代雲資料平臺都將儲存和計算分離，這意味著客戶不受單一因素的限制。這可能是過去 20 年中資料架構中最重要的一次變化，而不僅僅是橫向擴充。與現實環境中難以管理的「無共用」體系結構不同，共用磁片體系結構使你能夠獨立地增加儲存和計算能力。S3 和 GCS 等可擴充、高速的物件儲存的興起，讓我們在構建資料庫時變的非常容易。

在實踐中，資料大小的增長比計算能力的增長快得多。雖然儲存和計算分離的優勢特性，讓我們可以隨時選擇擴充其中任何一個，但這兩個軸實際上並不等效。對這一點的誤解導致了大量關於大數據的討論，因為處理大型計算需求的技術與處理大數據的技術是不同的。探究為什麼會出現這種情況是有必要的。

所有大型資料集都是隨著時間的推移而產生的。時間幾乎總是資料集中的一個軸。每天都有新訂單、新的計程車服務、新的日誌記錄、新的一局遊戲。如果一個業務是靜態的，既不增長也不萎縮，資料將隨著時間線性增長。這對分析需求意味著什麼?顯然，資料儲存需求將呈線性增長，除非你刪除資料（稍後將詳細介紹）。但是計算需求可能不需要隨著時間的推移而改變太多，大多數分析都是針對最近的資料進行的。掃描舊資料相當浪費資源，它不會改變，所以你為什麼要花錢一遍又一遍地讀取它呢？你可能希望先保存下來，以防對資料進行重新挖掘價值資訊，但構建包含重要資訊的聚合更加有效。

通常情況下，當資料倉庫客戶從儲存和計算一體的環境轉移到一個儲存和計算分離的環境時，他們的儲存使用量會急劇增長，但他們的計算需求往往不會真正改變。在 BigQuery 時，我們有一個客戶是世界上最大的零售商之一。他們有一個內部資料倉庫，大約有 100TB 的資料。當他們遷移到雲端時，他們最終的資料量是 30PB，增長了 300 倍。如果他們的計算需求也增加了類似的數量，他們將需要在資料分析上花費數十億美元。不過，他們只花了這個數位的一小部分。

這種偏向於儲存大小而不是計算大小的做法對系統架構產生了真正的影響。這意味著，如果使用可擴充物件儲存，那麼你所使用的計算量可能會遠遠少於預期。你甚至可能根本不需要使用分散式處理。

工作負載大小小於總體資料大小

用於分析工作的資料量絕對比想像的要小。例如，動態監控面板通常由聚合資料構建。人們往往需要查看的是前一小時、前一天或上周的資料，這通常需要頻繁查詢較小的表，對大型表只要選擇性地查詢便可以了。

幾年前，我對 BigQuery 的查詢情況做了一個分析，分析了每年花費超過 1000 美元的客戶。90%的查詢處理的資料小於 100MB。我用了很多不同的分析方法，以確保結果不被進行了大量查詢的幾個客戶的行為所扭曲。我還把僅對中繼資料的查詢剔除了，這是 BigQuery 中不需要讀取任何資料的部分查詢。到達 GB 這個量級的非常少，極少量的查詢能達到 TB 級。

擁有中等資料量的客戶經常進行相當大的查詢，但是擁有巨量資料的客戶幾乎從不查詢大量的資料。當他們這樣做時，通常是因為他們需要產生一份報告，而這時性能並不是真正的優先考慮事項。一家大型社群媒體公司會在週末發表報告，為高層領導週一上午做準備，這些查詢非常龐大，但也僅占一周內他們所做的數十萬次查詢中的一小部分。

即使在查詢大型表時，也很少需要處理大量資料。現代分析資料庫可以通過列投影來唯讀欄位的子集，透過分區修剪來唯讀較窄的日期範圍。他們通常可以更進一步，透過聚類或自動微分區，利用資料中的局部性來消除段。其他一些技巧，如對壓縮資料進行計算、投影和謂詞下推，都可以在查詢時減少 IO 操作。更少的 IO 意味著更少的計算量，進而降低成本和延遲。

嚴峻的經濟壓力促使人們減少對大數據量的處理。我們可以快速地擴充和處理一些東西，但並不代表著你可以廉價地獲得這個能力。如果使用一千個節點來獲得一個結果，這可能會消耗你大量的資源。我在會議上演示的 BigQuery 的 PB 級查詢零售價是 5000 美元，很少有人願意花費如此昂貴的費用。

請注意，即使你沒有使用按位元組付費的定價模型，關於對少量資料優惠的激勵政策也是有效的。假設你有一個 Snowflake 實例，如果你可以讓你的查詢更小，你可以使用一個更小的實例，進而支付更少的費用。你的查詢會更快，可以併發地運行更多查詢，隨著時間的推移，你最終支付的費用通常會更少。

大多數資料很少被查詢

我們處理的資料中有很大一部分是 24 小時以內的。當資料超過一周時，它被查詢的可能性可能比最近一天的資料低 20 倍。一個月後，資料基本上就只是儲存在那裡了。歷史資料往往很少被查詢，除非有人需要做一份特殊的報告。 

資料儲存時間的曲線扁平化得多。很多資料很快就會被丟棄，不過仍會有很多資料被追加到表中。最近一年，99%的資料存取只針對 30%的資料量。最近一個月 80%的資料存取可能只是針對 5%的資料量。 

大量資料不被使用，意味著資料集的大小比預期更易於管理。如果有一個 PB 級的表，其中包含 10 年的資料，你可能很少存取比今天更早的任何資料，這些資料壓縮後可能小於 50 GB。 

大數據邊界不斷縮小

「大數據」的一種定義是「不適合只用一台機器處理的資料」。根據這個定義，符合條件的工作機器在不斷減少。 

2004 年，Google MapReduce 論文發表時，資料不適合在單個商用機器上處理是很常見的，對機器擴容也非常昂貴。在 2006 年，AWS 推出了 EC2，我們能得到的唯一實例大小是一個單核和 2 GB 的 RAM。有很多工作都不適合那台機器。 

然而，現在 AWS 上的一個標準實例使用一個具有 64 核和 256 GB RAM 的物理伺服器。RAM 多了兩個數量級。如果你願意多花一點錢優化下記憶體，你可以獲得另外兩個數量級的 RAM。有多少工作需要用到超過 24TB 的 RAM 或 445 個 CPU 核？ 

過去，大型機器非常昂貴。然而，在雲端運算中，使用整個伺服器的虛擬機器的成本僅比使用八分之一伺服器的虛擬機器的成本高出 8 倍。成本隨著計算能力線性增加，規模非常大時也是如此。事實上，dremel 原始論文中發表的使用 3000 個並行節點的基準測試，我們現在可以在單個節點上就獲得類似的性能（稍後會詳細介紹）。 

資料是一種負債

大數據的另一種定義是「保存資料的成本低於丟棄資料的成本」。我喜歡這個定義，因為它概括了人們最終選擇大數據的原因。這並不是因為我們需要它，我們只是懶得刪除而已。想想現在的許多資料湖，它們完全符合這一要求：巨大而混亂的沼澤，沒有人真正知道它們包含什麼，也沒有人知道清理它們是否安全。 

讓資料一直存在業務中的成本比僅僅儲存物理位元組的成本要高。根據 GDPR 和 CCPA 等法規，你必須跟蹤某些特定類型資料的所有使用情況。部分資料需要在一定時間內刪除。如果你把電話號碼長時間保存在資料湖中的某個 parquet 檔中，你就可能違反了法定要求。 

除了監管法規，資料還可以用來起訴你。正如許多組織執行有限的電子郵件保留策略以減少潛在的責任一樣，資料倉庫中的資料也可能被用來對付你。如果你有 5 年前的日誌，這些日誌顯示程式碼中存在安全性漏洞或 SLA 缺失，保留舊資料可能會延長您的法律風險。我聽說過一個可能是杜撰的故事，講的是一家公司對其資料分析能力保密，以防止其在法律取證過程中被使用。 

當程式碼沒有得到積極維護時，它經常會遭受人們所說的「比特腐爛」。資料可能會遇到相同類型的問題；也就是說，人們忘記了專業領域的確切含義，或者過去的資料問題可能漸漸地被遺忘了。例如，可能存在一些資料錯誤，使得每個客戶的 id 為空。或者有一筆巨大的欺詐交易，使 2017 年第三季度看起來比實際情況要好得多。從歷史時間段提取資料的業務邏輯會變得越來越複雜。例如，可能有這樣的規則，「如果日期早於 2019 年，則使用 revenue 欄位，2019 年至 2021 年之間使用 revenue_usd 欄位，2022 年之後使用 revenue_usd_audited 欄位。」資料保存的時間越長，跟蹤這些特殊情況就越困難。而且並不是所有這些問題都能輕鬆解決掉，尤其是在資料缺失的情況下。 

如果你要保留舊資料，那麼最好想清楚為什麼要保留它，三思而後行。如果一定要保存，僅僅儲存聚合的儲存和查詢，成本不是要低得多嗎？你留著它以備不時之需嗎？你是覺得你可能未來從資料中獲得新的價值資訊麼？如果是，它有多重要？你真的需要它的可能性有多大？你真的不是一個資料囤積者嗎？這些都是要思考的重要問題，尤其是當你試圖計算保存資料的真實成本時。 

你是大數據中的百分之一嗎？

大數據是真實存在的，但大多數人可能不需要關心它。以下問題可以讓你確定是否處於那「大數據的百分之一」中： 

1. 你真的在生產大量資料嗎？
2. 如果是，你真的需要同時使用大量資料嗎？
3. 如果是，資料真的大到不能放在一台機器上嗎？
4. 如果是，你確定你不只是一個資料囤積者嗎？
5.  果是，你確定資料匯總不會更好嗎？ 

資料來源：

• BIG DATA IS DEAD