數據庫管理-第332期 大數據已死，那什么當立？（20250602）

作者：胖頭魚的魚缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE Partner10年數據庫行業經驗
擁有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等認證
墨天輪MVP，ITPUB認證專家
圈內擁有“總監”稱號，非著名社恐（社交恐怖分子）公眾號：胖頭魚的魚缸
CSDN：胖頭魚的魚缸（尹海文）
墨天輪：胖頭魚的魚缸
ITPUB：yhw1809。
除授權轉載并標明出處外，均為“非法”抄襲

前兩天在數據庫圈歷史學家司馬遼太杰的朋友圈看到一段話“每隔一段時間，就有人傳大數據已死的話題…”，確實好像每隔一段時間都會有人提出這個論點，更有甚者，會有人提出沒有數據庫該承載那么大的數據，今天我也提出下我的一些觀點。

1 概念還是技術

首先，大數據到底是一種概念還是技術，也許在曾幾何時，大數據就等同于Hadoop，在那段實踐中大數據被看做一種技術，利用Hadoop的大數據量存放與處理能力來解決大規模數據的復雜分析需求。
但是隨著軟件的發展，比如搜索與數據分析引擎、列式存儲數據庫、分布式等技術的擴充；加上硬件的發展，計算（CPU）、緩存（內存）、IO（SSD）的巨大進步。使得實現大數據量的分析計算可以不再需要復雜臃腫的Hadoop了。
回到本小節題目，我認為大數據，在當下的大數據是一種概念，或者說是一種場景需求，簡單來說就是從海量數據中獲取需要的分析結果。

2 必然的大數據量

為什么有人不相信可能出現那么大的數據量，無外乎有以下一些原因：

• 所在的公司/企業業務量就那么大，想象不出什么樣的業務會帶來那么大的數據量
• 認為歷史數據沒有價值，僅保留很短時間內的活動數據，整體數據就很小了
• 業務拆分的比較細，每部分業務的數據量都不大，自己也只負責這部分數據
• 自認為自己研發能力出眾，不會產生那么多冗余數據
• …

我在類互聯網公司干過，也在傳統行業摸爬滾打過，我來說說對上面這些原因自己的見解：

• 確實有業務，光是基礎數據的數據量就能超出你的想象，而且這些數據還有不少是需要頻繁變更的，更別說基于這些基礎數據構建起來的整體業務的數據量
• 歷史數據是寶貝，先不說可以用于審計溯源，還可以通過分析得出一些很有價值的東西，比如趨勢預測、反詐、構建知識庫、模型訓練等等
• 無論業務拆的多細，我們最終的分析需求是需要把所有數據串聯起來，這樣整體的數據量就不會小
• 菜是原罪，而且世界是個巨大的草臺班子，不是每個人都那么的優秀
• …

3 離線到實時

這里還是舉個例子，以前家里寬帶不能上網了，打運營商電話報障投訴，很大概率是不能立馬給你說出故障原因并給出解決時限的，有些故障處理個十天半個月也不是問題，甚至有時候運營商的客服和故障處理人員態度還不大好。但現在不一樣，很多時候在你電話報障的時候，就能直接給你說出故障原因，同時網絡維護人員會很快給你打電話并同步故障處理進度，態度非常好。為什么會有這種變化，其主要原因一是上級通信主管單位的要求，運營商必須保證網絡連通性；二是現在投訴可以直接電話到工信部，這樣的投訴再下放到本地，帶來的影響可會被放大很多。
運營商的數據就是上一節說到的基礎數據都是海量且實時變化的，排障就是在這些海量基礎數據之上結合其他相關大規模流轉數據找到故障點并反饋一線快速處置，這就是一個典型的HTAP場景了。如果還是用以前相對臃腫的Hadoop來解決類似的問題，那么ETL的過程所耗費的時間往往就已經讓故障工單超時了。

4 未來

其實大數據的近實時在線分析和離線分析兩種場景并不是有你無他的，兩種場景根據需求不同是同時存在的，只不過如前一節所說的一樣，只不過很多原來沒有時間要求的計算分析現在實時性要求越來越高了。依托軟硬件的發展與合理的應用與數據層架構設計，可以非常便捷的實現HTAP的場景需求，另一方面我覺得以后離線大數據分析中ETL的部分完全可以交給AI來做，不僅性能更好，還能敏捷的變更需求，如果再將數據排布一并交給AI，那么離線大數據分析的性能會有一個質的提升。

總結

大數據是數據量越來越大，實時性要求越來越高環境下的一種概念或者場景需求。
老規矩，知道寫了些啥。