什么是數據平臺——企業構建Data+AI的基礎數據底座需要的決策參考

什么是數據平臺

標準的解釋是這樣的

Wikipedia
A data platform usually refers to a software platform used for collecting and managing data, and acting as a data delivery point for application and reporting software.

數據平臺是指將各類數據進行整合、存儲、處理和分析的技術平臺，旨在基于數據為業務提供各類服務、產生業務價值。數據平臺可以從不同的數據源中獲取數據，并將數據進行清洗、融合和轉換，最終提供給分析師、決策者和應用開發者等各類用戶使用。

大數據平臺，是數據平臺在大數據時代的概念衍生，其功能寬度和包含的要素要勝于傳統的數據平臺，是能處理海量數據存儲、計算，支持離線批處理分析、交互式查詢、流數據實時計算等多類負載場景的技術堆棧，通常包括數據采集、數據存儲、數據計算、調度運維、數據治理和數據應用等主要核心功能。

非官方的解釋，我有一個更簡明的定義：

“數據平臺是盡可能高效地利用存儲和計算資源（用最少資源），處理和分析海量且多樣數據的技術底座”

數據平臺的價值

介紹數據平臺價值的文字很多，通常會提到數據平臺可以存儲海量信息，處理、分析并轉化這些數據為分析洞察等等。不過結合筆者在過去十幾年的數據分析和使用平臺的經驗，還是講三點有特別價值的點。

大數據平臺是創新的孵化器

以智能汽車和工業互聯網場景為例，據車百智庫2024年的行業分析報告，一輛L4自動駕駛的智能網聯汽車，每日通過車內外傳感器采集的行駛數據、環境數據和行為數據等，已達到10TB的量級，是傳統汽車的5-10倍。根據最新預計，在路上行駛的智能汽車每年上傳到云端的數據超過70000PB。在20年前，也就是2000年前后，互聯網最蓬勃發展時期全球互聯網的數據總量是1000PB。也就是如今僅智能汽車機器產生的數據就是20年前整個互聯網數據的70倍。如今進入大數據時代，我們越來越清晰的看到，數據規模的幾何倍增長衍生產生的數據價值，以及需要更創新更智能分析數據的方式。

舉3個過去10年已經成為現實的數據創新的例子：

城市交通管理：
許多城市利用數據平臺來優化交通流量，通過分析來自交通信號、車輛傳感器、公共交通系統的數據，數據平臺能夠預測交通擁堵并調整信號燈周期，甚至引導駕駛者選擇最佳路線。這種智能交通系統的創新減少了擁堵，提高了城市交通運行效率
電商如亞馬遜的動態定價策略：
亞馬遜的數據平臺能夠實時分析市場需求、庫存水平、競爭對手定價等信息，以此來調整產品價格。這種動態定價策略幫助亞馬遜最大化利潤，同時保持市場競爭力。數據平臺在這里起到了創新策略的試驗場和實施者的角色。
內容和電商平臺的動態推薦系統：
數據平臺收集了用戶的觀看歷史、評分、搜索習慣等數據，并利用復雜的算法為用戶推薦電影和電視劇。這種個性化體驗不僅提高了用戶滿意度，也增加了用戶粘性。抖音、小紅書、電商如阿里、京東、海外如Netflix的平臺都有類似的推薦設置。通過不斷迭代更新，使得推薦系統越來越精準。

還有更多的案例，這里不再一一列舉。簡言之，筆者認為基于數據和智能AI的創新是幫助企業從激烈的競爭中走出差異化的道路的有效手段。

數據平臺促進非技術團隊的分析能力

通過提供易于使用的工具，數據分析不再是數據分析師和科學家的專屬領域。非技術團隊如市場、運營、財務甚至產品研發等，傳統上依賴BI團隊和數據開發運維團隊支持，可自己上手用更直觀的方式進行數據分析，這得益于數據平臺的不斷演進，包括采用如數據可視化的操作面板，元數據和數據資產管理平臺，免運維的SQL運行環境，更安全的數據管理機制，也包括自然語言支持的數據分析能力逐步成熟。總的說，數據平臺凝結了技術普惠的結晶，一整套提供給組織使用，大幅降低了門檻，提升組織的數據能力。

圖1：提升企業內數據使用員工比例

優化資源分配與成本控制

在成本控制方面，講究的是數據新鮮度和成本平衡。例如處理高新鮮度的流式數據，通過flink和kafka的組合，由于流數據要保持常駐的計算節點，通常會有比較高的成本，而且如果考慮后續的分析加工鏈路也需要實時，整體方案的成本會比較高。如何無極調節數據新鮮度和成本的平衡，是一個數據平臺需要具備的能力。

新的解法有包括更統一的引擎架構，例如下一代數據平臺數據引擎可以用增量計算技術實現數據的微批處理和增量存儲。此外更智能的引擎也可以通過AI識別和學習適合合并數據和計算任務，進行增量而非全量處理流程、或通過優化數據存儲方案，減少重復冗余的數據存儲降低成本。具有AI加持的數據平臺可以通過多種自動化方式減少手動處理需求，從而降低成本并提高效率。

圖2：無極調速的數據平臺大幅提升運行效率概念圖

定義數據平臺功能的組成，分別解決什么問題

通常一個數據平臺有如下功能模塊（熟悉這個領域的朋友可以略過）包括：

1.數據集成同步

將來自不同數據源的數據整合到一起形成一個統一的數據集的過程，涉及數據收集、清洗、轉換、重構和整合，以便在統一的數據倉庫或數據湖中進行存儲和管理，包括離線同步和實時同步。

圖3：典型數據集成

2.數據的批處理

數據的批處理是數據最通常的處理方式，將數據集合按照上下游關系安排任務順序，分批次進行處理，以處理海量數據，是一種最大化處理數據規模，最大化節省資源的數據處理方式。

3.流數據的處理

是實時處理和分析連續生成的數據流的過程。流數據的處理通過跟蹤和存儲有狀態算子的中間計算結果，支持有狀態的計算和容錯性，具有低延遲和高吞吐量的特點，適用于實時數據處理場景，如網絡監控、推薦系統和物聯網數據分析等場景。

4.交互式分析

數據分析師使用例如SQL/Python/R等數據分析語言，或通過可視化工具對數據進行實時的查詢，聚類，匯總等分析，得出分析結果并支持企業或組織采取決策或行動。交互式分析有低延遲高并發的特點，以更好支持分析師對實時性及臨時性（ad-hoc）和交互性的使用體驗。

5.任務開發調度和運維監控

通過數據開發界面，使用類似SQL等通用的描述性數據分析語言，對數據進行抽取(Extract)、轉換(Transform)和裝入(Load)的步驟，或進行ML/數據科學研究，進行數據分析的模塊。

通過對系統內所有數據庫資源進行統一管理和監控，采集監控數據，并根據預警規則進行判定，以及采取相應的預警或自動化處理措施，確保系統的穩定性和性能。

圖4：數據目錄監控數據血緣

6.數據資產管理

狹義上是對數據本身的創建、存儲、加工和控制的一整套流程，旨在幫助用戶快速理解數據的上下游關系及其含義，精準定位所需數據，減少數據研究時間成本，提高效率。進一步，現代的數據資產管理，旨在提供企業對數據資產進行規劃、控制和供給數據的方式。例如確保數據的安全前提下的跨組織共享；例如有嚴格權限管控的數據報表，確保核心數據保密；例如同一個報表，不同人看有不同的報表層級——區域只能看到區域的數據，總部能縱覽全局，等數據權限控制機制。

把組件組裝在一起，就可以了么？

一個建設大數據平臺的最樸素的想法就是把上述的組件組合在一起，構成企業能用的平臺。MDS（Modern Data Stack）就是這樣的數據架構理念，它強調組件之間的解耦與模塊化，組合實現不同工具和服務的集成。

MDS理念和反思

Tristan Handy，dbt的CEO，最先在2020年下半年的Future Data會議上提出了“Modern Data Stack”（MDS）這一概念，既由眾多模塊化功能組合而成的數據技術棧，并在dbt Labs的博客上發表了相關文章。

圖5：Modern Data Stack（MDS）

業界對MDS的討論

Modern Data Stack(MDS)概念的提出者 Tristan Handy在2024年2月的文章中也表達了他最新的思考，文章的標題就是“Is the 'Modern Data Stack' still a useful idea?"。當一個概念的提出者都發出這樣的疑問，我們就應該引起重視了。感興趣的朋友可以參看這篇文章：《Is the "Modern Data Stack" Still a Useful Idea?》

Tristan Handy

Finally, as a result of all of this pressure on data spend, buyers developed a strong preference to buy?integrated solutions?rather than to buy many tools to construct a stack. Buyer willingness to construct?a stack from 8-12 vendors has declined significantly. Companies are much more likely today to expect to buy 2-4 products as the core of their analytics infrastructure.

Handy的觀察是“（隨著經濟大環境的改變），來自成本的壓力逐級傳導到數據團隊和架構選擇上，客戶越來越傾向于購買整合一體的產品。而組合8-12個廠商的技術棧方案，已不太受買家青睞，采用的意愿度大幅下降...”

此外，Ternary Data的創始人兼CEO，暢銷書《數據工程基礎》的聯合作者Joe Reis，與Matt Housley共同討論了Modern Data Stack的未來，并在他們的線上書中提到了“現代數據棧”MDS這一概念的消亡。文章的標題甚至更直接“Everything Ends - My Journey with modern data stack” ，直譯文章標題《一切都結束了——我的MDS歷程》：Everything Ends - My Journey With the Modern Data Stack

文中的觀點也是對現代數據技術棧的反思，講到由于多種數據工具的大量產生使得人們的關注點不再是基礎和原理，而是簡單的實踐，重視工具的使用技巧而不是工具背后的原理。導致數據技術棧的發展缺乏創新。

Joe Reis也很不留情面的講出，“MDS組件確為客戶提供了‘豐富’的工具，讓企業的數據團隊有了成噸的‘問題’要解決——然而對企業本身無實際附加價值。”

Joe Reis

I feel like the MDS made it easy for the data industry to go backward, allowing data teams to have a ton of convenient tooling while adding questionable value to their organization.

大部分使用開源工具的企業或者組織，買臺機器并下載開源數據工具使用，并不會對代碼和項目做定制化開發和長期的投入，僅僅是使用基礎能力。這樣的方式既沒有發揮出開源軟件的工具的100%潛力，也沒有真正的降低成本。

筆者的觀察是，一方面數據架構過于復雜，如果并非對極致的場景的特殊組件有強要求，可以考慮更一體化的整套商業化產品。這一點Joe Reis說的情況看來是在國內海外差異不大，畢竟改造開源代碼做企業的本地化適配，是只有少數幾個大廠才投得起的事。要看企業規模來決定是不是采用大量開源組裝的方案。有能力使用開源并基于開源做定制開發以更好的做到數據創新，才是開源組件的正確打開方式。然而這種級別的投入，也只有少數幾個大廠能夠想想，在如今的創業環境中這樣的投入不一定經濟。

數據架構的演進

參考A16Z-Andreessen Horowitz在2023年更新總結現代數據架構全景圖，包括離線、實時以及數據湖，數據倉庫，ML/AI等多個領域統一數據架構。圖中每一個灰色框代表一個專門的領域模塊，通常有多個類似的產品提供相似的功能。

圖6：A16Z 2023 現代數據架構全景圖

在具體的場景中選擇適合的產品，例如我們可以在Spark/Trino/Impala/Doris等產品中做選擇，如果看中多樣性可能選擇Spark對接Hive，如果對高并發和時效性有要求會選擇Trino/Impala等。在不同的場景中選擇各有優勢的產品，還包括用Yarn統一管理資源等等。

這個思路就是我們常說的Lambda架構，Lambda架構是一種用于處理大數據的架構模式，通常至少是將數據處理分為兩個明確的層次：批處理層（Batch Layer）和流處理層（Speed Layer）。Lambda架構的目的是同時兼顧數據處理的準確性和實時性，通過這兩個層次的結合，能夠有效處理和分析大規模數據集。同理，組合結構化數據所需的數據倉庫和非結構化數據的數據湖，等等組裝的方式來實現一個基礎的數據平臺。有過統計，如果需要完成基本的數據平臺，會需要至少10余個組件拼裝完成。這是一個比較復雜且有挑戰的過程。

Lambda架構

實踐上，以下是幾個不同場景不同用戶的數據架構實例，可以作為參考理解數據平臺的典型架構：

圖7：目前典型的大數據系統架構案例

Lambda架構受詬病的原因，還在于數據處理需要分為兩個路徑：一個是批處理路徑，用于處理大量歷史數據；另一個是流處理路徑，用于處理實時數據。

圖8：Lambda架構數據處理流程

這兩個路徑在處理邏輯上往往有所重疊，但是需要分別維護，這就增加了系統的復雜性和開發成本。此外數據湖和倉難統一，也有格式不開放，冗余數據的諸多問題。

Kappa架構是什么

Kappa架構的設計理念是簡化實時大數據系統的復雜性。

與Lambda架構不同，Kappa架構提出了一個更為簡潔的解決方案。在Kappa架構中，所有數據——無論是實時的還是歷史的——都被同一套處理引擎進行處理，無論是實時分析還是批量處理，都使用相同的處理邏輯，從而簡化了系統設計，減少了冗余，并使得系統維護和擴展變得更加容易。

簡單來說，如果把Lambda架構比作一家餐廳里分開運作的快餐窗口（流處理）和正餐區（批處理），那么Kappa架構就像是一個將所有顧客都通過同一個窗口服務的快餐店。這樣做的好處是，餐廳的工作人員只需要掌握一套服務流程，無論是面對想要快速吃完走人的顧客，還是想要慢慢享用的顧客，服務的效率和質量都能得到保證。

一體化架構有統一的引擎，支持實時、離線和交互分析，避免了數據冗余、多條鏈路等問題。下圖是舉例一個典型的在Kappa架構的數據分析架構，支持多種不同的任務負載，共享資源池，可彈性伸縮并有統一存儲等特點。

圖9：一體化架構使用示意圖

總結數據平臺必備的組件和要素

總結一下現在的數據平臺——不再只是單一功能的大數據庫，有處理批和流以及實時分析等多種負載的引擎能力，有整體的支持非結構化數據和結構化數據的管理機制，有更多有機組合的管控能力。數據平臺也不再是幾個組件的簡單集合。

數據平臺應該具備如下六個關鍵要素：

穩定：數據平臺需穩定運行，直接支撐業務運營。保證數據處理及時準確，遵循“可監控，可灰度，可回滾”原則。關鍵在于可觀測性，確保任務運行、版本控制、監控、告警、運維等功能齊全。
經濟：存儲和計算的高效對于成本的節約至關重要。存儲格式，壓縮率、文件的讀寫性能，單位算力處理數據的性能，一直是基礎平臺層持續優化追求的目標。在性能上的比拼，是數據平臺在穩定性之外的主要考量要素。
多樣：數據平臺需要能夠支持多樣的數據處理模式，比如離線批處理、交互式查詢分析、流計算和實時處理等。傳統的方式通過組裝不同的計算引擎來滿足，但業界也開始出現基于Single Engine來滿足不同作業負載的新的趨勢。
安全：數據平臺需要能提供體系化的安全管控能力，諸如統一的數據權限管理、存儲加密、數據脫敏、風險識別，以及滿足安全合規要求等
開放：數據平臺可以與其他產品進行對接，尤其是存儲、計算引擎的開放性；數據平臺自身也要易于擴展增加新的組件。
易用：數據平臺在操作層面的易用性容易被忽視、但對數據平臺的成功應用至關重要。數據平臺需要綜合考量不同的用戶群體，比如數倉ELT工程師、數據分析師、業務運營人員等，在專業技能和使用習慣上的差異性，用戶使用體驗。從平臺建設視角看，僅面向技術同學、單純以技術視角來構建數據平臺產品是大忌，會嚴重影響平臺的推廣使用。數據平臺效率為本、業務價值優先。

開篇曾談到數據平臺的定義，“數據平臺是指用最少資源，處理和分析海量且多樣數據的技術平臺”。我認為這個定義足夠簡潔抽象地概括了數據平臺的核心價值——通過整合和統一為企業和組織提升數據分析效率。

此外關于數據平臺的發展趨勢，如果您想深入了解演進過程和發展趨勢，我重磅推薦這篇文章《AI風暴來襲：2024年數據平臺的演進、挑戰與機遇》，對數據平臺的演進過程和方向做了很好的梳理。

如何選擇數據平臺

1.明確企業或組織對數據平臺的需求

并非所有企業的數據需求都是相同的。根據企業的成熟度、業務目標和技術能力，我們可以將企業對數據平臺的需求分為五個級別，從基礎的數據收集和存儲到高級的數據智能和預測性分析，每一級別都代表了企業在數據應用深度和復雜度上的逐級上升。

圖10：數據分析5級智能分層模型

如圖所示的企業數據智能化的5級分層模型，代表企業對數據的分析能力和智能化能力，從L1到L5逐步升級向上，層級越高智能化能力越強，也需要更完備的數據平臺能力支撐。這里建議重點關注兩個關鍵跨越——分別出現在向L2級和L4級的跨越上。

第一個關鍵跨越是由第1級臺階邁向第2級臺階的過程，為什么這一個跨越很重要，因為這是真正進入大數據分析的分水嶺——考慮到數據量的快速增加，CTO必須要考慮數據平臺的成本和效率問題。相對的，第一級臺階基于對小量數據，依靠內存計算和MPP高并發低延遲的計算已經逐漸成為數據分析的統一標準，很容易給用戶帶來“甜區”效應。問題就在于當數據量快速擴大時，組織往往會發現很難一邊對接更多的多個組件，保證數據分析規模平滑擴展，一邊控制成本：總系統復雜度和維護成本陡然上升。

第二個關鍵跨越是由第3級邁向第4級的過程中，為什么它重要，有兩個原因，其一是外部環境的劇變，AI時代下應該考慮數據資產如何能夠更好地和AI結合，結合數據和AI的能力。其二是數據生態的內耗阻力讓CTO重新思考尋找開放的數據格式和數據湖倉方案。傳統的方案數據格式在多種負載中不統一，在數據傳統的數據湖不具備狀態存儲，而實時鏈路又需要帶狀態的存儲。挑戰在于此時企業已經有了非常大的數據規模，方案的調整和遷移成本都會相對更高。所以這級跨越也對組織來說非常具有挑戰，需要提前規劃長效的升級方案。

2.選擇“云上”或“云下On-Premise”

圖11：云下 vs 云上

近期“下云”話題炒得火熱，特別是在馬斯克推動Twitter全力“下云”之后，這一討論達到了高潮。所謂“下云”，指的是企業從依賴云計算服務商提供的云服務，轉而采用自建數據中心或其他本地解決方案來處理和存儲數據。據評估這個決策可以為Twitter節省60%的成本。對頭部巨型企業而言，這個成本節省是非常有吸引力的。有一個數據可以參考，據評估蘋果公司每月在亞馬遜云計算上的支出就超過了3000萬美元。

安全考慮，對于對數據安全性和隱私有嚴格要求的企業來說，On-Premise部署提供了讓數據管理者放下顧慮的方式。企業可以直接控制物理服務器和網絡環境，實施自定義的安全策略，減少數據泄露和未經授權訪問的風險。

自建服務器部署的另一個考慮是企業想實現“可控”。企業將擁有對數據庫系統的完全控制權，包括硬件選擇、配置設置、數據管理和安全性控制。此外，企業會拒絕接受云廠商提供的一系列服務，不想被鎖定了軟件生態，不想被“綁定”。

優點
- 安全因素
- 自主可控，不會被云廠商綁定
缺點
- 需要龐大的專業的技術團隊
- 數據規模和計算規模缺乏彈性

On-Premise部署的缺點也是很明顯，首先需要龐大的專業的技術團隊，這就決定了必須要有足夠大規模的計算集群，這樣做才值得。其次，選擇OP部署相當于放棄了云的彈性能力，擴縮容將變得復雜，需要一系列流程和操作。

筆者認為現在已經有越來越多的PaaS層產品/開源生態方案，支持在多云環境部署，也是一種解除軟件生態綁定的方式。另外On-Premise要考慮數據備份問題，異地災備也并不簡單。對于大中型企業，數據安全的擔憂永遠是相對于成本和性能做綜合考慮，根據企業自身情況安排適合的方式。舉個例子，您會選擇把錢放在家里的保險箱，還是存在銀行？數據的上云或下云也是類似的選擇。

相應的在云環境搭建數據平臺是有它的優勢，首先是計算資源和存儲資源的彈性伸縮能力，云資源池提供了近乎無限的可能性，而企業不用關心如何采購服務器的和軟件運行環境，運維擴縮容等問題。云計算契合增長型企業對數據平臺的訴求：全面、靈活且易擴展。

3.選擇“全托管”的數據平臺，或自建

自建企業數據平臺允許企業根據目前的需求定制其數據處理、存儲和分析的組件，例如目前不需要流數據的處理那就可以先不考慮流計算，如果暫時沒有大規模數據要求，例如可以用2臺機器先運行起來開源軟件做分析。這種方法為企業提供了靈活性和控制權，使企業能夠調整數據架構以優化性能和效率。然而靈活和控制權的代價是顯著的初期投資，包括硬件、軟件許可以及招募和培養專業人員的成本。開源數據平臺的運行離不開持續的維護和升級成本，如前文所述，組裝本身有系統復雜和冗余鏈路的諸多問題。

優點
- 靈活和可擴展性的控制權
- 如果選擇開源自建則軟件本身是“免費”的
- 如果能參與開源社區，或在此基礎上做定制開發，可以在特定場景專項優化
缺點
- 初始成本和維護成本難控制
- 技術復雜度，系統復雜度有挑戰
- 維護成本高

全托管的一體化數據平臺為企業提供了一個無需擔心硬件和軟件維護的解決方案，使得企業能夠更加專注于其核心業務。這些平臺通常易于部署和使用，能夠快速適應企業需求的變化。由于成本大多是基于訂閱的，企業可以更容易地預測和管理其數據管理成本。然而，選擇全托管的SaaS解決方案也意味著企業可能會面臨一定程度的功能限制，以及對供應商的依賴增加。

優點
- 快速部署和易于使用，一體化綜合性能優異
- 直接獲得成熟的大數據infra架構
- 成本可預測，線性可控，免運維減輕內部負擔
- 多云環境的數據平臺也兼具靈活
缺點
- 平臺有一整套組件，有一定的適應使用和學習門檻

在考慮是否自建企業數據平臺或選擇全托管的SaaS模式數據平臺時，關鍵在于評估您的企業情況。自建數據平臺提供了高度的定制性和對數據控制的優勢，適合那些對數據安全有著嚴格要求，且愿意投入初期成本和資源進行長期投資的企業。企業選擇開源自建如果不能做到深度參與開源，或基于開源框架做一些定制改造，實際上與使用整套方案無異。采用整套一體化方案適合專注在業務創新的企業，希望減輕管理負擔，快速啟動，并優先考慮成本效益。這種全托管的SaaS模式的數據平臺可能是這類企業更合適的選擇。

決策建議

評估業務需求和目標：明確您的數據處理需求、安全標準以及長短期業務目標。

考慮資源和能力：評估您的內部資源和技術能力，確定是否有能力自行建設和維護數據平臺。
成本效益分析：進行詳細的成本效益分析，包括初期投資、長期維護成本以及潛在的業務價值。
最后，無論選擇哪種路徑，都應保持靈活性，隨著企業發展和市場變化調整數據戰略。技術的迅速發展意味著今天的最佳選擇可能需要在未來重新評估。持續的技術評估和戰略調整將是企業成功利用數據的關鍵。

通過深入分析和適時的決策，企業可以選擇最適合其特定需求和目標的數據平臺解決方案，最大化數據的潛在價值，從而在競爭中保持優勢。

幾個關鍵問題：