十年的輪回，正如大數據的發展一般，它既是一個輪回的結束，也是嶄新的起點。大數據在過去的二十年中蓬勃發展，從無到有，崛起為最具爆炸性的技術領域之一，逐漸演變成為每個企業不可或缺的基礎設施。然而，在這個時刻，我們不禁要問：當前的大數據架構是否已經趨于完美？2023 年，伴隨著人工智能的躍變式爆發，數據平臺將如何演進，以適應未來的數據使用場景？
這并非簡單的問題，更是一個關乎企業生存與發展的命題。在過去的十年中，我們目睹了 Spark、Flink 和 Kafka 等系統的崛起，它們成為大數據領域的支柱。然而，現在是否有新的力量嶄露頭角，希望挑戰它們的地位？2023 年，大數據領域有哪些實質性進步嗎？
在 2023 年年終盤點之際，InfoQ 有幸采訪了大數據領域的資深專家，包括 關濤、李瀟、王峰（莫問）、吳英駿、張迎（按姓名拼音排序）。他們共同探討了數據堆棧技術的演變過程，深入剖析了技術快速演變所帶來的挑戰。在這次專訪中，我們將揭示技術變革的背后原因和邏輯，為大家呈現大數據領域的現狀以及未來可能的發展方向。
1突如其來的革新和質疑？
流存儲 Kafka 誕生在 2011 年，而流計算 Flink 到今年也剛好滿了十年。
十年前，軟件范式是利用虛擬化技術來發揮硬件性能。此外，云服務也只是剛剛興起，存算分離等云原生概念尚未普及。
如今時過境遷，一切都在快速變化。當今的應用程序每天可以處理多達數萬億個事件，維護數 TB 的數據。硬件的迭代速度飛快，相對十年前的 SSD，NVMe 速度提升十倍，價格也降至原來的 20%。S3 越來越多地被用作基礎設施服務的核心持久層，而不僅僅是作為備份或分層存儲層，例如 Snowflake、Databricks 等。
對象存儲是云時代的產物，支持原始數據存儲、分布式可擴展、高靈活性、低價，都是對象存儲之所以被選擇的原因。可以預計在未來會有更多的數據業務完全基于對象存儲而構建。
--2021 年，滕昱《使用對象存儲，數據湖才能重獲新生》
這也給一些初創公司帶來了巨大的機會：不需要用分層架構去實現存算分離，而是干脆用更加極端點方式去做存算分離，即直接建立在 S3 對象存儲之上。
基于對象存儲的構建也大大降低了構建新數據系統的門檻，催生了一系列這樣的“垂直”基礎設施初創公司：今年誕生的兼容 Kafka 的 WarpStream、AutoMQ，去年拿到 A 輪融資的 Neon Database、流數據庫 RisingWave，等等。
然而 S3 雖然價格便宜，能省成本，但高延遲是一個問題，數據系統構建者需要費點周折才能處理好需要低延遲的工作任務。恰好在今年底，AWS 發布了 S3 Express One Zone，一種新的低延遲 S3 存儲類別，可以說是在正確的時間提供了正確的技術（目前價錢昂貴）。
推動數據庫和數據產品發展的主要因素主要有兩方面。一方面是數據本身，另一方面是硬件的發展。S3 是硬件層面的變化，這勢必會給大數據領域帶來巨大的變革。
眾所周知，在數據庫的歷史上，每次存儲介質的變化都會引發軟件的變革。
--2023 年，曹偉《數據庫的下一場革命：進入對象存儲時代》
“低延遲 S3 的發布，對于我們這些從事數據基礎設施業務的人來說，這是今年最大的一個新聞。”RisingWave（risingwave.com）創始人 & CEO 吳英駿認為。
如今的大數據技術棧是真的難用嗎？
站在當前的時間點，對于大數據系統的易用性問題，采訪嘉賓給出了“不夠好”、“不夠便宜”，“太過復雜”的評價，可以說當今的大數據技術棧是公認的“難用”。
大數據架構在過去漫長的 20 年里經歷了從場景到系統的完整迭代。
大數據的起源可以追溯到谷歌的 MapReduce 框架，這標志著大數據的最初階段。在此之前，數據庫方面主要有一些頂級產品，如 Oracle、SQL Server 和 IBM DB2。google 提出了一個通用的、折中的方案，即不必購買 Oracle、DB2 或 Microsoft Server，使用簡單的模型讓大規模并行計算在擁有大量普通計算機的科技企業中變得可行：利用 MapReduce，不使用數據庫，就能完成大數據計算，只不過用戶需要去承擔這些復雜性。
這里還有個大家可能忘卻的典故：數據庫專家 David DeWitt 與 Michael Stonebraker（同樣是圖靈獎獲得者）在 2008 年發表了《MapReduce: A major step backwards》，對 MapReduce 進行了批評，稱其為開歷史倒車。
要充分利用這些資源，MapReduce 提出的方法是，將底層編程接口封裝成 Map 和 Reduce 函數之后，便直接暴露給有編程經驗的用戶，讓用戶自己實現具體業務邏輯，并自己可以操控程序并行度等細節。用戶不再是使用 SQL，而是使用 C 或 JAVA 等編程語言，需要承擔編寫底層代碼的復雜性，處理更多的編碼工作，這也意味著很高的學習壁壘，讓許多人望而卻步。
在這期間，批處理和流處理在 Spark 和 Flink 的引領下率先成熟。
截圖來源：https://zhuanlan.zhihu.com/p/662659681
近幾年，交互分析，也稱直接在線服務能力（Operational Analytics） 隨 Clickhouse 等通用實時數倉流行，并已是事實上完成主流客戶的部署。隨流、批、交互三類計算場景成為標配，Lambda 架構也成為（國內的）事實標準。Lambda 架構能夠滿足客戶場景上的訴求，最大的缺陷就是復雜：數據開發、組件運維、數據管理均復雜。
畢竟并不是所有公司都跟 Google、Facebook 或 Twitter 這樣的大型科技公司一樣，擁有強大的工程團隊，能夠管理復雜的流處理系統來實現他們的需求。也并不是所有用戶都像阿里和拼多多這樣有著非常大的數據量，復雜的分布式系統阻礙了十幾或幾十個人的小公司或一些傳統企業的采用，對它們來說，這是一件成本高、挑戰大的事情。
吳英駿認為，大數據架構里，如流處理，應該回歸第一性原理了。
“現在的系統，誕生于十年前，與當下云時代設計的系統相比，從本質上來說肯定是不同的，這表明大數據生態在這十年間并沒有取得實質性進步。”
“在當前時刻，我們再設計這個系統時，肯定會思考能否基于現有系統實現性能提升。”
語言層面，新系統需要提供一個更高層次的語言，比如 SQL 或 Python/ target=_blank class=infotextkey>Python。另外，云上最核心的一個點在于“存算分離”，站在現在這個時間節點上，新一代的系統從設計上的第一天開始就應該是“存算分離”的。跟分級存儲架構不一樣，現在的系統可以將所有數據直接放到 S3，而不僅僅是將歷史數據放到 S3，那么這樣就可以更加極端的去實現存算分離，設計、實現和運維自然都會更加簡單。
RisingWave 于 2023 年 6 月發布了 1.0 穩定版本，并通過數月的大量性能測試，得出了“比 Flink 快 10 倍”的結論。
“性能比較不是關鍵，易用才是關鍵。基于對象存儲并能在性能和效率方面取得提升，那肯定是因為整體基礎架構正在發生變化，這是一個核心點。”
2以 Spark 社區為例看易用性進展：從 Python 到 AI
“簡單易用”同樣是 Spark 社區的主要發力重點。在 Databricks 今年的 Data and AI Summit 主題演講中，Reynold Xin 談及了三個 Spark 社區在易用性的最新進展。
首先，需要提供一套簡單好用的 API。Python 和 SQL 已經成為了整個數據處理行業的主流語言。在過去幾年，Python 已成為 TIOBE 指數顯示的排名第一的編程語言，這種受歡迎的原因來自于它的簡單性和易學性，使其成為初學者和專家的首選語言。Python 的廣泛庫和框架簡化了數據分析和機器學習中的復雜任務。各大數據系統都提供了它自己的 Python DataFrame APIs。PySpark 的 PyPI 下載量（https://pypistats.org/packages/pyspark）僅在 2023 年最后一個月就達到了來自 169 個國家的 2800 萬次下載。為了方便 pandas 用戶，PySpark 也提供了 pandas API 的支持?？梢哉f，API 的簡單易用已是大勢所趨。特別值得一提的是，即將發布的 Spark 4.0 版本中，一個全新的 Python 的數據源接口被特別設計來強調易用性。這一更新將使 Python 用戶更加輕松地創建和管理自己的數據源，進一步增強 Spark 平臺的用戶友好度和靈活性。
Spark 社區在這方面繼續發力，過去一年的一個主要項目，Spark Connect，引入了一種分離的客戶端 - 服務器架構，允許從任何地方運行的任何應用程序遠程連接到 Spark 集群。這種架構的改進涉及到了穩定性、升級、調試和可觀測性多個方面。Spark Connect 使得用戶可以在他們喜愛的集成開發環境（IDE）中直接進行交互式的調試，并且可以使用應用程序自身的指標和日志庫進行監控。
其次，一個穩定成熟的數據系統必須具備一套穩定的 API，這也是 Spark 社區對 API 行為和語義的變更制定嚴格規范的原因，目的是讓用戶更順暢地升級至最新版本。在上個月，最流行的 PySpark 版本就是最新的 Spark 3.5，這體現了用戶始終傾向于使用最新版本的趨勢。為了迎合這一趨勢，Spark 社區努力保證向后兼容。
此外，錯誤信息的標準化也是 Spark 社區過去一兩年里的努力方向。盡管這看似技術復雜度不高，但這實際上是使系統更加簡單易用的基本需求。今年的 Spark 4.0 release 還會進一步標準化日志，以使用戶能夠更好地進行系統調優和代碼調試。
而隨著生成式 AI 的發展，未來 API 將變得更加簡單易用，自 ChatGPT 大流行到現在，我們發現它已經對 PySpark 有了深入的了解。這得益于 Spark 社區在過去十年里提供了豐富的 API 文檔、開源項目和教學資源。Spark 社區開發了一個叫做 English SDK 的項目，將 Spark 專家的知識融入到 LLM 中。這樣一來，用戶就可以通過簡單的自然語言指令來操作 PySpark，而不需要自己寫復雜的代碼。這種方法讓編程變得更容易上手，學習過程也更簡單。
3流處理的演進
從 2014 年誕生之后，Flink 已經確立了其在全球實時流計算領域的地位。阿里、Amazon、Azure、Cloudera、Confluence 等眾多企業都提供了支持和托管服務。
樹大招風，實際上今年不止一家企業宣稱在流處理技術上實現了 10-1000 倍的效率提升，如果這些技術確實可以在生產環境得到驗證，像阿里、騰訊、抖音這樣的大型公司每年可能會節省數十億的機器成本。盡管目前還沒有看到哪家公司在真正的生產環境中實現了這一效果，但這一趨勢表明流處理技術的不斷創新將在未來帶來更多的機遇和成果。與此同時，Flink 的發展現狀 和未來演進則更加引人關注。
流處理領域是否有留給創業公司的機會窗口？
事實上，Flink 一直在不斷完善和創新。Kafka 已經在商業版中實現了一個“分級存儲”架構來實現了存算分離的改造。同 Kafka 一樣，Flink 也會從存算耦合轉為存算分離的架構。
據莫問介紹，目前 Flink 也在不斷學習和自我革新，2024 年將是 Flink 項目的第一個十周年，Flink 社區也會發布 Flink 2.0 新的里程碑，徹底的云原生存算分離架構、業界一流的批處理能力、完整的流批融合能力都會是全新的亮點。
莫問認為，隨著云原生概念的逐步普及，未來主流的計算負載一定是運行在 Cloud 上，全球范圍內都是這個趨勢，因此大數據架構也需要更好地適配云底座，利用好云的彈性優勢。存算分離將會是未來大數據架構的標配，不過存算分離在帶來了諸多好處的同時也帶來了額外的性能挑戰，目前看來在對 latency 敏感的場景下，多級緩存和冷熱分層將是對存算分離架構的有益補充，2024 年將發布的 Flink 2.0 也會采用這套最新的架構。
分級存儲側重于在計算節點上進行緩存，遠端存儲主要存儲歷史記錄。相較之下，新的直接建立在 S3 上的系統將所有數據完全存儲遠端，但也會造成性能的下降，這需要在產品設計方面去做一個權衡。
在存算分離上，Flink 會有一個迭代的過程，吳英駿認為，“大家的最終思想都是統一的。如果我們將時間拉長，放到五年之后，我們可能會看到這兩種系統實際上非常相似。在未來發展中，雙方都會在自己的短板上進行彌補。比如說，RisingWave 從第一天起就將內部狀態放在對象存儲上，而這意味著 RisingWave 需要思考如何降低對象存儲所帶來的高延遲問題。而對于 Flink 來說，面臨著使用本地磁盤存儲狀態而導致的大狀態管理困難的問題。它可能需要引入一個分級存儲的架構，來降低處理大狀態計算時的資源消耗，同時避免系統直接掛掉。”
“但在目前一兩年里，這兩種系統在架構上仍然會有相當大的區別。架構的調整不是一朝一夕能夠完成的。”
新興軟件和成熟軟件之間有了較量，那么用戶進行選型時，會關注哪些因素呢？
作業幫于 2019 年底調研 Flink 1.9 版本，并在 2020 年內部搭建了實時計算平臺，現在流和批都在幾千任務的規模。其大數據架構師張迎表示，選型時，主要根據業務訴求，結合多云融合能力、成熟度、已有技術積累、云廠商的支持力度、成本等綜合考慮。
這幾年使用大數據技術棧時主要有兩點比較強的感受：生產環境的可用性、周邊系統的建設，這兩點一定要跟得上。一個用戶可以寫出來幾百個 SQL 任務，但是出了問題往往不知道如何追查和改進。后面的工作，例如調優、自動化測試、日志、監控報警、高可用也都是圍繞這類需求展開的。
原來需要寫代碼的實時任務，很多可以通過 SQL 完成。（在 2015 年后，隨著流處理的成熟，流計算引擎紛紛選擇了支持 SQL 通用編程語言）。SQL 越來越復雜，配置越來越多，一定程度上還是將復雜度留給了數據流的構建者。“對于簡單的數據流，開發和運維都變得更簡單了。而對于復雜且重要的數據流，我們的態度也一直是謹慎保守為主，避免盲目求新。”
流處理技術進化方向
關于 SQL 的說法，跟莫問預測流處理引擎未來進化方向之一是一致的，即：“全面 SQL 化，提升體驗，降低門檻”。大數據處理從離線向實時升級的趨勢已經確立，大量行業已經開始實時化升級，并取得非常好的業務收益。為了讓更多用戶能夠享受到實時流計算帶來的價值，流處理引擎需要進一步提升端到端的易用性，全面 SQL 化 ，提升用戶體驗，降低使用門檻，讓流計算能夠在更多場景和行業中被生產使用起來。
云原生架構的不斷發展，也同步推動了數據湖存儲方案的加速落地。數據湖具備的開放和成本優勢，必然使得越來越多的數據流入湖中，從而成為天然的數據中心，湖上建倉的 Lakehouse 架構正在成為主流，下一步客戶一定是希望數據在 Lakehouse 中能夠更加實時的流動起來。
Apache Paimon 是從 Flink 社區中孵化出來的新項目，定位就是流批一體實時數據湖格式，解決 Lakehouse 數據實時化的問題。
基于 Flink + Paimon 可以構建出新一代的 Streaming Lakehouse 架構，讓 Lakehouse 上的數據可以全鏈路實時流動起來。此外，基于計算和存儲端到端流批一體的特性，也更加方便用戶在 Lakehouse 架構上實現實時離線一體化的數據分析體驗。
“Paimon 是一個好的嘗試，”關濤對此評論道。
之前 Flink 流批一體缺乏對應的存儲系統配合：Flink 自帶的狀態存儲無法滿足批處理通用數倉的需求，Paimon 則是補全這個短板的關鍵。
莫問指出，在實時流處理這條鏈路上，確實也存在一些新的機會和變化。眾所周知，Flink 和 Kafka 目前已經分別成為流計算和流存儲的事實標準，但 Kafka 真的是最適合流分析的存儲方案嗎？
Kafka 和很多消息隊列類似，都是一種消息中間件，而非為大數據分析而生。例如：Kafka 并未對數據提供結構化的 Schema 描述， 也無法提供完整的 Changelog 語義，且 Kafka 中的數據時無法進行實時更新和探查分析的。
“但以上這些缺陷，都是實時流分析需要的特性和能力，我們也正在思考這個問題，并探索新的解決方案，希望能夠在明年發布一款更加適合流分析的流存儲技術。”
42023 年，大數據技術棧的整體變化
近些年各種不同的大數據基礎設施雨后春筍般的涌出，一方面為用戶提供了多樣化的選擇，但另一方面也為用戶帶來了幸福的煩惱。通常情況下，用戶要搭建一套大數據業務系統，需要非常多的核心技術組件才能完成，少則三到五種，多則五到十種，這主要帶來以下幾方面的問題：
- 技術組件繁多，必然提升系統架構的復雜度。通常來講，系統穩定性風險和系統復雜度成正比，過于復雜的體系必然帶來更大的穩定性隱患；
- 每一項技術組件都需要有對應的專家來運維管理以及客戶支持，對于中小企業來說，這必然帶來高昂的人力資源成本；
- 過多的同質化組件存在，也會為用戶帶來選擇的困擾，并行保留多個同質化組件不僅給運維團隊帶來了額外的運維負擔，也給開發者帶來了額外的學習成本。
因此，未來數據技術的演進會逐漸出現一些整合的趨勢，走向更加簡潔的架構，核心目標不僅是讓每個組件運行得更快，還需要考慮為用戶提供更加簡單、一致性的開發體驗，以及全局最優的運維成本。
從 Lambda 架構到 KAppa 架構的演進。當前數據分析平臺的典型架構是 Lamdba 架構（由三層系統組成：批處理 BatchLayer，流處理層 Speedlayer，服務層 Servinglayer），隨批、流、交互三種引擎誕生和成熟組裝而成。這種架構的典型缺陷，包括復雜度高，數據冗余度高，學習成本 / 開發成本高等等。針對 Lamdba 架構的缺陷，Kappa 架構應運而生。但多年過去了，Kappa 架構仍然更像是參考架構，并沒有很多引擎 / 平臺做到 Kappa 架構的要求。2023 年是個拐點，除了部分已有引擎開始拓展邊界相互滲透，還有一些新的設計和計算模式被提出。例如云器科技提出“通用增量計算”的新計算范式統：Lambda 架構到 SingleEninge，用一個引擎覆蓋流批交互三種模式。
目前業界主流的幾款 Streaming、Batch 和 OLAP 引擎都開始相互滲透，例如：Flink 在發力流批一體、流批融合計算能力，Databricks 也基于 Spark 和 Delta 推動了 Delta Live Table 淡化流批的差異，StarRocks 在提供 OLAP 極致查詢能力的同時，也開始通過物化視圖形態提供對數據湖上數據的 ETL 處理能力。本質上各大主流計算引擎都在不斷擴展自己的能力邊界，淡化流、批、OLAP 邊界，希望為用戶提供全場景一致性的數據分析體驗。這也是技術發展的必然趨勢，各家都會逐漸補齊短板，但也都有各自核心的優勢。
在最近幾年的數據技術趨勢演進的路線中，我們可以清晰的看到兩個趨勢變化 ：一是數據架構的云原生化。幾乎所有的大數據公司都選擇了擁抱云原生，推出了基于多云的 PaaS/SaaS 計算服務，從 Serverless 到 BYOC，為用戶提供了在云上不同類型的托管服務。二是數據分析的實時化。在技術上，數據的“實時化”包括了兩個因素：數據的新鮮度，以及數據的查詢速度。用戶也不再盲目地只追求速度，而是更注重新鮮度、性能和成本的平衡。在時效性上， Iceberg 贏得了更多關注，數據湖存儲技術為我們提供了構建近實時（near-online）數倉的可能性，在成本不變的情況下可以支持更快、更多的流量數據。
數據集成上，SeaTunnel 成功畢業，Flink CDC 3.0 演變成以 Flink 為基礎的端到端流式 ELT 數據集成框架。比如作業幫目前主要在使用 SeaTunnel 以降低異構數據源間數據處理的開發成本。
社區希望能表格式能夠統一，但實際還有一段路要走。
Lakehouse 平臺在數據倉儲領域的使用正迅速增加。這反映了一個重要的趨勢：組織正從傳統的數據處理平臺過渡到更加靈活、集成和效率更高的現代數據架構。據 2023 年 MIT Technology Review Insights 報告，全球 74% 的首席信息官（CIOS）表示他們已經在使用 Lakehouse 架構。自 Databricks 在 2020 年推出此概念以來，Lakehouse 作為一個新類別得到了廣泛的采納。幾乎所有還未使用 Lakehouse 的首席信息官都計劃在未來三年內部署此類平臺。
有專家認為，Lakehouse（湖倉一體）和 Iceberg 表格式已成為事實標準。但是，當前根據 Slack users、 Github Stars、Github PRs、Github Forks、Issues 各個指標顯示，Delta、Hudi 和 Iceberg 還是三分天下。雖然 Delta、Iceberg 和 Hudi 起源地不同，但是各個社區都在努力地提升開源社區的活躍度，讓用戶社區和開發者社區更加健康的發展。隨著社區的競爭加速，基礎功能的差異在不斷減少。
三種表格式（Table Format）均基于 Apache Parquet 數據格式，但這些格式各自會創建出相似、但又不盡相同的元數據，從而影響數據向應用程序和分析工作負載的表達方式。結果就是，Delta、Hudi 和 Iceberg 之間存在一定的不兼容性。表格式的最終統一還有難度，未來還得看哪種表格式能給出更好的性能、更好的易用性和更持續的創新能力，接下來的一年肯定更加精彩。
頭部的云廠商的產品都或多或少地支持不同的表格式。Snowflake、BigQuery、Athena 都已支持 Iceberg，而微軟和 Databricks 都以 Delta Lake 為主要存儲格式。因為當前數據處理引擎的格式支持缺陷，用戶不得不將數據以不同格式存成多份。格式的兼容性讀寫會是未來一個值得關注的方向。比如 10 月份發布的 Delta Lake 3.0 增加了 Delta UniForm 通用格式，Delta Uniform 自動為 Iceberg 和 Delta Lake 生成元數據，提供了一個實時數據視圖，而底層它們共享的同一份 Parquet 數據，因此用戶可以避免額外的數據復制或轉換。另外，同時能支持 Hudi、Iceberg 和 Delta Lake 的元數據自動轉換和生成的 XTable 也于 2023 年底正在申請進入了 Apache 孵化器。
5GenAI 來了
無論是大公司還是小公司，大家都渴望從生成式 AI 的熱潮中分到一杯羹。當然，作為大公司，無論是 Databricks 還是 Snowflake，它們確實更有實力來進行生成式 AI 的開發。
今年 Databricks 不僅率先發布了開源可商用的大模型 Dolly，還于 6 月底宣布以 13 億美元的價格，收購生成式 AI 公司 MosaicML 。
在 LLM 服務方面，對數據棧的依賴主要集中在知識庫的構建和查詢上，包括但不限于向量數據庫。有人認為在短期內很難看到深層次 AI 對數據湖或數據倉庫方面帶來重大變革，但也有人認為數據是服務于 AI 的：大數據是燃料，大模型訓練已經涵蓋了大量已有的大數據技術，而數據湖則作為存儲系統在其中扮演重要角色。
Databricks 李瀟對此也進行了解釋，他認為數據湖倉（Lakehouse）的作用是為 GenAI 提供了一個集中、高效和可擴展的數據存儲和管理環境。它結合了數據湖的靈活性和數據倉庫的高性能，支持結構化和非結構化數據的存儲和處理，這是 AI 應用的數據需求的基石。
“今年，Databricks 的最大進展主要體現在將人工智能集成到數據平臺中。“
作為大數據行業里一個非常重要且典型的企業，Databricks 在 GenAI 也反映了整個大數據行業的技術演進。現在我們可以通過它在數據智能平臺投入來看看生成式 AI 將對數據和分析產生的影響。
Databricks 是由一群 Apache Spark 的原創者所創建。Spark 的誕生階段，始于 2010 年，標志著 Hadoop 技術時代的結束。它的出現大幅降低了大數據處理的門檻，使得大數據開始與機器學習和人工智能結合，成為統一的分析引擎。2020 年，Lakehouse 架構的推出打破了傳統數據湖和數據倉庫的界限。Lakehouse 架構結合了數據湖和數據倉庫的最佳元素，旨在降低成本并加速數據及人工智能項目的實施。Lakehouse 架構建立在開源和開放標準之上，它通過消除歷史上復雜化數據和 AI 的孤島，簡化了數據架構。
而現在，則是到了生成式 AI 大潮下的 Lakehouse 階段。Databricks 構建了一個基于數據湖倉（Lakehouse）的數據智能平臺（Data Intelligence Platform），該平臺的目標是實現數據和 AI 的平民化，使用自然語言極大簡化了數據和 AI 的端到端體驗。它利用生成式 AI 模型來理解數據的語義，并在整個平臺中應用這種理解?？梢宰層脩艨梢栽诒３蛛[私和控制的同時，從頭開始構建模型或調整現有模型。
同時，Databricks 還提供了 Unity Catalog 數據治理工具來確保數據的質量和安全。Databricks 還于今年推出了 Lakehouse Federation (聯邦查詢) 的功能，用戶可以跨多個數據平臺（如 MySQL、PostgreSQL、Snowflake 等）發現、查詢和管理數據，而無需移動或復制數據。另外，Databricks SQL（Lakehouse 上的無服務器數據倉庫）使用量也獲得了大幅增長。
Databricks 認為，在不久的未來，每個領域的贏家都是那些可以最有效利用數據和 AI 的，并堅信對數據和 AI 的深刻理解是每個贏家的必備技能。
未來的大數據架構將是一個高度集成、智能化和自動化的系統，它能夠有效地處理和分析大量數據，同時簡化數據管理和 AI 應用的開發過程，為企業提供競爭優勢。
“未來的大數據架構，我們可以稱為‘數據智能平臺（Data Intelligence Platform）’。它正是順應了兩個主要趨勢：數據湖倉（Data Lakehouse）和生成式人工智能（AI）。”李瀟表示。
這一架構建立在數據湖倉的基礎上，它提供一個開放、統一的基礎，用于所有數據和治理，由一個理解用戶數據獨特語義的數據智能引擎 (Data Intelligence Engine) 驅動。這是相對現有 Lakehouse 架構下的，最大的突破。
智能化方面，這個引擎能理解客戶數據的獨特語義，使平臺能自動優化性能和管理基礎設施。操作簡化方面，自然語言大大簡化了用戶體驗。數據智能引擎理解客戶的語言，使搜索和發現新數據就像詢問同事一樣簡單。此外，自然語言還助力編寫代碼、糾錯和尋找答案，加速新數據和應用程序的開發。
在隱私保護方面，數據和 AI 應用需要強大的治理和安全措施，尤其是在生成式 AI 的背景下。提供一個端到端的機器學習運維（MLOps）和 AI 開發解決方案，該方案基于統一的治理和安全方法。這允許在不妥協數據隱私和知識產權控制的情況下，實現所有人工智能目標。
總的來說，未來的大數據架構將更加重視智能化、操作簡化和數據隱私，為企業在數據和 AI 應用方面提供競爭優勢。這將使企業能更有效地利用數據，推動創新，同時保護數據安全和發展 AI 技術。
