對話黃東旭、關濤、李遠策：資料引擎，One Size Fits All 能實作麼？

今天，資料平台是企業的必選項。長期以來，企業在選擇資料平台架構時，多傾向于針對流處理和批處理兩大場景分别部署兩套方案。近年來，一體化資料融合平台的概念逐漸受到關注，行業開始嘗試在同一個架構中同時處理不同類型的資料，簡化資料平台技術棧。那麼企業真的可以使用一套解決方案應對所有場景嗎？一體化資料平台有哪些主流選項？Lambda 與 Kappa 架構各有哪些優勢和不足？企業該如何選擇适合自己的解決方案？

針對上述問題，InfoQ 聯合雲器科技策劃了《極客有約》特别版——《再談資料架構》系列直播的第三期。本期節目，我們邀請到了 PingCAP 聯合創始人兼 CTO 黃東旭、雲器科技聯合創始人 &CTO 關濤以及快手科技資料架構中心總架構師李遠策暢談以下話題：

1. 從需求視角看，目前使用者需要怎樣的資料平台？
2. AI 火熱的今天，資料平台如何更好地支援 AI 能力？
3. 資料融合平台的發展趨勢？

從需求視角看，資料平台如何更滿足目前使用者需要？

關濤：不同企業需求不同。如果面向未來思考這個問題，第一，目前選型資料平台，需要做到 Data+AI 一體化，要能支援半 / 非結構化存儲，能支援 SQL 和 AI 的運算，避免建成即落伍。第二，考慮總 TCO（總持有成本）最低，是否投入人力自建或者采用 SaaS 服務。最後一點，平台是否足夠簡單，讓非技術背景的使用者也能使用，AI 技術也在幫助這一點。

黃東旭：我覺得未來像 HTAP 的資料庫能夠進一步把 Kappa 架構的實時性和資料的新鮮程度再推進一步。我一直相信大資料會向資料庫這個方向走，它會慢慢把很多傳統的大資料的東西漸漸統一。

李遠策：企業選擇技術架構時，首先要理清需求和關注的名額，還要考慮到備選産品背後公司的影響力、經營狀态，這樣才更容易招到合适的人來做事情。偏中小型的公司還要考慮産品的可用性，盡量采用比較簡潔的架構。

InfoQ：大資料領域有着超過 20 年的發展曆史。從企業視角來看，今天大資料已經是必選項，那麼對企業而言，我們需要怎樣的資料平台呢？

關濤：從企業的視角看，大資料現在是預設的必選項，在這個前提下可以抽象出三個挑戰（同時也是選型的一些考慮）：

第一，是平台總持有成本。每個企業幾乎都在做海量資料，為此需要付出硬體成本、軟體成本與人力運維成本。降本是一個非常高優先級的話題。

第二，對比資料庫系統和大資料系統，大資料系統相對就複雜一些。以 Hadoop 的系統為例，一個相對完備的 Hadoop 系統大概七八個元件拼接在一起，對于使用和維護，這是很大的技術挑戰。

第三，是這個領域發展很快，這就需要持續追趕和疊代。例如最近就在讨論怎樣利用 AI 提升資料平台的能力。客戶一方面會考慮新技術能否用起來，一方面會考慮平台怎麼能擴充支援這些能力。

從企業視角，選擇資料平台時第一要考慮平台能否存儲和管理更全域的資料，例如非結構化、非流化的資料；第二是它能否支援 SQL 以外的多種計算态勢，第三就是平台能否有效實作降本增效。最後一點，平台是否足夠簡單，讓非技術背景的使用者也能使用。

黃東旭：補充兩點。從曆史上看，大資料的行業變化趨勢一定程度上也能反映使用者的需求變遷。2000 年前後，谷歌發現他要處理的資料量遠大于傳統的單機資料庫分庫分表技術能夠承載的極限，而且這個系統也難以擴充，隻能用多台小機器連在一起變成一個大的分布式系統來做資料處理。是以我覺得 Big data 技術之是以難用是有曆史根源的，一開始它就不是奔着通用系統去設計。後來我們看到，幾乎所有的資料系統開始又重新支援 SQL 或更易用、更标準化的 API，通用性及易用性越來越像資料庫，這是第一個趨勢。

第二個趨勢就是從 MapReduce 到 Streaming System 再到現在的 HTAP，大家一直在追求越來越高的實時性。現在很多實時的報表甚至對于資料的一緻性和事務性都提出了要求，我覺得這也是另外一個趨勢。

李遠策：我站在一個企業使用者的視角來談一談企業使用過程中會遇到哪些痛點、挑戰。資料處理流程包括資料采集、資料加工和資料分析三大環節，其中資料加工環節的時間消耗是比較大的，超過了 50% 的比重。資料加工環節面臨不少挑戰，比如流批兩種資料生産模式對應的兩套計算引擎有各自的學習和維護成本，這是第一點。

第二點是大資料架構經常處理多種資料來源的資料，又會使用多種計算引擎，這給資料的品質和計算結果的一緻性也帶來了很大的挑戰。資料品質在企業内部是一個比較重要的問題，它往往比資料延遲影響更大，而且具有一些隐藏性和傳遞性。一旦出問題，資料品質的影響面是不可控的，是以我認為資料品質也是目前資料處理的一個非常大的痛點，需要從資料加工的規範以及全鍊路的資料品質監控、計算引擎的算子語義的一緻性等多個層面上來做好保障工作。

資料的治理和規範化也是一個非常大的挑戰。資料治理對資料品質、資料安全、成本控制以及找數等多個方面有很多很關鍵的作用，是以做好資料治理需要體系化的建設；資料的管理規範，比如中繼資料管理等，也可能是比較大的挑戰。

下一個問題，我們怎麼樣定義一個好的資料引擎？有幾個方面，第一個是成本，對于計算引擎來講成本等價于算力，對于存儲引擎來講成本控制主要來源于資料的副本數。第二點是資料品質，包括引擎的穩定性、計算結果準确性，還有存儲資料的可靠性等方面。第三點是效率，包括兩個方面，一是互動式分析的查詢延遲，二是資料開發效率。最後一個是資料的安全性，這一點在企業裡也是非常關鍵的。

InfoQ：現在我們能看到越來越多的企業選擇将架構轉變成一體化的 Kappa 架構，背後都有哪些考慮點？

李遠策：大資料架構經曆了一個架構演化的過程，早期是離線批數架構，後來過渡到了 Lambda 架構。Lambda 架構相對于離線資料架構來講主要引入了實時階段鍊路，提升了資料處理的時效性，可以更實時地看到過程中的資料計算結果；同時也為了保障資料最終一緻性，它需要把最終的離線計算的鍊路結果進行覆寫。其實 Lambda 架構是比較複雜的，資源消耗也比較快。

Kappa 架構解決了 Lambda 架構的一些缺陷，可以了解成一種 Lambda 架構簡化版。比如說 Kappa 架構隻依賴于實時計算鍊路來做資料計算，如果需要資料重計算或者新增計算名額，它需要對曆史資料進行回放計算。Kappa 架構最大的優勢是架構比較簡單，需要依賴的資料引擎較少。

黃東旭：早期的大資料處理平台，其流計算部分沒辦法支援批量或者很大的離線計算，基本沒有資料存儲和加工能力，是以就有了 Lambda 架構。

Kappa 架構誕生的背景是現在的這些新一代的基礎設施配上比較高性能的 OLAP 資料庫基本上也能做到流批一體。有了流批一體這樣的新的資料庫和流處理系統以後，技術的進步讓 Kappa 架構變得更簡單，它其實是曆史的必然。

雖然 Kappa 現在是比較前沿的方向，但我仍然覺得這是一個中間狀态。Kappa 架構仍然沒有辦法很好地去處理更實時的場景。我覺得未來可能像 HTAP 的資料庫能夠進一步把 Kappa 架構的實時性和資料的新鮮程度再推進一步。HTAP 相當于又可以把前面資料服務的那塊 DB 歸納進來，是以我一直相信大資料會向資料庫這個方向走，它會慢慢把很多傳統的大資料的東西漸漸統一。

關濤：換個視角來看，一體化平台都能解決哪些問題呢？第一個問題是使用者界面側的文法和語義的統一。第二點是多系統的組合帶來了中繼資料不統一、資料存儲不統一的問題。第三點，因為三套系統各自獨立需要分别管理，且需要很多資料同步，開發維護成本很高。

是以一體化架構第一是統一語言、統一開發體驗，簡化使用者開發過程；第二是統一存儲、統一計算；第三是你能不能比較靈活地在這幾個點上做切換。資料新鮮度、延時和成本構成了資料處理不可能三角，如前面所說，你很難把這三點都保證住，但一體化系統能比較容易地在這三個點之間做轉換。

InfoQ：不同的企業面臨不同的業務場景，那麼針對各種需求背景，企業采用哪一種模式是最合适的呢？

黃東旭：首先 HTAP 是實時性要求最高的，但它的分析能力是偏弱的，是以它要盡可能貼近線上、實時、新鮮的資料。流式資料就更接近 Kappa 跟 Lambda 的領域。在雲時代之前，大多數企業會有自己純離線資料層，比如 HDFS。Lambda 架構的離線處理層可以直接複用 HDFS 的 MapReduce 引擎，隻需要再搭一個流式處理層就好了。但現在大家慢慢地上雲，即使不上雲也是在從 HDFS 或者 Hadoop 的架構轉到基于對象存儲的方案上，可選項就多了，是以沒有必要非得抱着 MapReduce 或 Hadoop 這一套。是以一體化的方案越來越流行和 Hadoop 的沒落是相關的。

李遠策：企業選擇技術架構時，首先要理清需求和關注的名額，還要考慮到備選産品背後公司的影響力、經營狀态，這樣才更容易招到合适的人來做事情。偏中小型的公司還要考慮産品的可用性，盡量采用比較簡潔的架構。Kappa 結構就是比較簡潔，遇到的問題相對比較收斂，比較容易管理。技術選型還要有一些前瞻性，防止資料架構的頻繁疊代。不過目前在企業内部，Lamdba 架構因為其靈活性的優勢采用度還是很高，Kappa 的技術還有很大疊代空間。

關濤：雖然不同企業有不同選擇，但大方向還是一緻的。資料領域從資料庫到資料分析再到 AI，前半部分的場景基本已經固定了，而這些領域中都在向着更簡單、更一體化的方向更新。這裡 HTAP、流批一體、湖倉一體都是整合模式，好處就是開發、運維更簡單，成本更低。

Lambda 是目前很多企業做資料分析的主流架構，企業需要低成本的批處理，同時又需要非常快的實時報表，就用 Lambda 架構搭一個。而 Kappa 就是個思想，本質是希望能在這些地方上做統一，是技術發展趨勢。面向未來，企業選擇一個一體化架構或者向這個方向演進是明确的。

AI 火熱的今天，資料平台如何更好地支援 AI 能力？

黃東旭：第一點，個人或企業的個性化資料必須有一個存儲服務，能夠很輕易地讓 AI 去通路、讀取。第二點，現在的 AI 就像一個黑盒，很難驗證它給你的答案是不是 100% 準确的。但資料技術可以給 AI 一個補充。

關濤：AI 極大擴充了資料處理的能力，可以說 AI 是整個資料領域發展的第三級推進火箭。LLM 比較新發展快，架構并不固定，我建議平台架構總體保持擴充性，考慮到資料分析和 AI 兩方面的需求就好了。很多企業的平台架構可以等待 AI 技術更成熟一點再跟進，讓子彈再飛一會。

李遠策：AI 在資料分析領域會越來越多地發揮重要作用。為此，資料平台要用好 AI 就要通過上雲來降低成本。

InfoQ：AI 是當下的大熱主題。資料平台天然就非常适合做 AI 的用武之地，那麼整體來看，資料平台該如何更好地擁抱 AI 呢？

黃東旭：對于資料平台來說，第一個趨勢，個人或企業的個性化資料必須有一個存儲服務，能夠很輕易地讓 AI 去通路、讀取。第二點，現在的 AI 就像一個黑盒，很難驗證它給你的答案是不是 100% 準确的。但資料技術可以給 AI 一個補充。比如我們可以直接去問 LLM 一個事實性的問題，但我要求它的回答并不是告訴我結論，而是幫我生成 SQL，用這個 SQL 去查詢包含事實資訊的資料庫。因為我确認資料庫的資料是真實的，是以這樣就規避掉了 AI 瞎編答案的問題。這就對資料平台提出一個新的需求，要能很好地支援大語言模型給你生成的稀奇古怪的 SQL。

結合這兩個需求，你會發現資料應用的場景越來越廣，這樣就必須得思考怎麼以更低的成本把這些資料存儲和處理起來。AI 的時代資料量會更大，通路方式會更加靈活，但顯然用現在的這些思路去解決，成本就太高了。我覺得要規模化地降低存儲成本，一條路就是上雲，第二就是減少備援，一體化還有一個好處就是降低了資料的備援度。第三還是要靠存儲、計算引擎的突破。大多數資料應用還是符合八二原則，80% 的資料可能價值比較低，20% 的資料可能是比較熱的。這對彈性計算的能力要求就會更高，需要對彈性計算友好的計算引擎，加上能夠智能地決定資料冷熱分布的存儲引擎。

關濤：AI 極大擴充了資料處理的能力，可以說 AI 是整個資料領域發展的第三級推進火箭，前面第一級是資料庫技術，第二級是大資料，第三級是 AI。AI 領域還是變化疊代非常快的領域，資料平台要如何承接它也是一個挑戰。

我的建議，第一是保持平台的架構擴充性，比如要考慮怎麼存非結構化的資料。第二要考慮資料分析 +AI，SQL 表達和 AI 兩方面的需求。以前可能就是 SQL 引擎分析資料，以後一定會有另外一個 AI 引擎可以用，這對架構的開放性要求很高。以前做數倉，存儲和計算放在一起沒有問題，但現在你得考慮存儲計算一定要分離開，而且要保證可能是 m 對 n 的映射才行。第三點，如果你不是特别面向大語言模型或者 AI 向前演進的企業，而是更偏使用者的狀态，可以讓子彈再飛一會兒，你隻要保證架構擴充就好了，讓這些技術再疊代一段時間，當它形成一定的 Pattern 後再跟進，避免架構頻繁調整。

李遠策：一個很重要的觀點是說自然語言是最好的。我先用自然語言描述問題，之後生成一個 SQL，再跑一個 SQL 把結果取出來。甚至比如說你畫出這條曲線之後，曲線可能有一些波動，AI 能幫你做一些歸因。是以 AI 在資料分析領域可能會越來越多地發揮重要作用。

第二點，AI 在資料平台應用就伴随着上雲、降成本。為什麼上雲能夠降成本？我覺得有三個點，一是存算分離，因為雲就有存算分離這個特性。第二是資料的冷熱，冷熱資料可以采用分級存儲，成本自然就降下來。還有就是彈性，可以采用波峰波谷的方式去使用雲計算，進而降低成本。

InfoQ：大模型時代，向量資料庫也是比較熱門的主題。為什麼向量資料庫熱度迅速攀升，它到底解決了什麼問題？

李遠策：一是大模型現在的實時性還是沒那麼高，沒法及時感覺新鮮的資料。第二是大模型在回答私有化的問題時，如果直接使用私有資料會存在安全和隐私方面的問題。向量資料庫靠一些 embedding 和相似性計算的方式，可以把更實時和更私有化的資料通過 embedding 得到一些向量存在資料庫裡，然後經過相似性的搜尋，給大模型提供資料的時候會帶一些 hint 的資訊過去，讓大模型能夠做一些輔助性檢查，這是向量資料庫在大模型方面的應用點。

黃旭東：向量資料庫是能夠提供多元度、模糊查詢以及聚類這樣特殊查詢方式的一種資料庫。傳統資料庫要去查某條資料，可能就像電子表格一樣，我知道它的 ID 然後查出來；但是向量資料庫查詢可能像一個地圖一樣，我就畫一個圈，你告訴我這個地方有什麼東西。

為什麼向量資料庫突然在 LLM 這個領域裡邊火了呢？因為大模型這邊訓練完了以後，你要在對外提供服務的時候，有一個環節去做上下文的存儲。我做一個對話之類的互動，可能這些上下文要作為這個模型的短期記憶，要有一個存儲。

第二就是做事實校驗，比如說我把很多事實放到向量資料庫裡，大模型在回複答案的時候，先要在這個資料庫裡确認一下事實性。

但你可以發現這兩種應用都是在模型對外服務的時候使用，但我覺得這個熱度不會持續太久。因為無論圖資料庫還是向量資料庫，它應該屬于對現有的資料庫架構的一種補充。隻要把向量資料庫思考成現有資料上的一個特殊索引即可。未來主流資料庫可能都會有這些特性去支援大模型的相關應用場景。

關濤：我認為向量資料庫是一個中間狀态，最終要麼被LLM融合，要麼被資料平台融合。可以設想如果大模型持續進化，把向量資料庫的能力都内置了，向量資料庫可能就沒落了；如果大模型還是很需要向量資料庫，它可能會被整合進主流的資料架構裡，變成資料平台、資料引擎裡的一個外置索引，而不是那麼獨立的一套系統。是以我認為向量資料庫最終不太會以獨立平台 / 系統的方式存在。

資料融合平台的發展趨勢

關濤：資料分析領域會更加一體化，Lamdba 架構會被替換。Data 與 AI 會進一步融合。最後，平台會更普惠化、民主化。哪個平台最普惠 / 最簡單，能讓最多的人用起來，它最終會赢得市場。

黃東旭：大資料的未來一定在雲上；實時場景會向 OLTP 這邊去靠；Serverless 可能是降本新思路。

李遠策：未來的資料架構要繼續往統一化演進，會有越來越多的整合型資料産品出來。

InfoQ：資料融合平台下一步的發展趨勢是怎樣的？各位老師怎麼去看它接下來的一些趨勢？

關濤：第一是結構化資料分析這個領域會更加一體化，更融合、更簡單，從 Lambda 到 Kappa 轉型會是一個大方向，未來一段時間會有一系列的企業在這方面向前做突破和疊代。

第二是面向持續變化的 AI 領域，針對資料和 AI 的融合趨勢，資料平台要做好準備，提升擴充性，考慮分析型的計算、存儲以及非結構化的資料與處理能力，讓 AI 的引擎能更好地消費這些資料。

最後，資料平台會越來越簡單易用，普惠化、民主化。而不是純粹的性能競争。哪個平台最普惠 / 最簡單，能讓最多的人用起來，它最終會赢的市場。

黃東旭：第一，大資料的未來一定是在雲上，包括公有雲、混合雲等等。更智能的存儲引擎、更彈性的計算架構都要建構在雲原生技術上，下一步的技術演進會跟雲貼得更近。第二點，實時的場景開始越來越向 OLTP 這邊去靠。是以有可能會在傳統的大資料技術棧中出現一個新的層，這個層可能過去叫 Reverse ETL，也可能叫 Data Serving 或者資料湖中間的某個部分，但我覺得這一層會慢慢地清晰，也是 HTAP 這個場景會發光發熱的地方。這一層會慢慢地跟 OLTP 結合，統一一部分實時計算的架構，可能會有更加簡單易用的一套資料技術模式，這個模式會以 HTAP、Database 為中心。第三個趨勢是 Serverless，Serverless 的很多技術理念用在大資料的處理之上，可能是降成本的新思路。

李遠策：未來的資料架構還是要往統一化演進，包括但不局限于流體的計算引擎、統一化的分析引擎，還包括一些在離線混合排程的排程系統，這都是統一化的演化思路。在不久的未來，可能會有越來越多的這種整合型的資料産品出來。

InfoQ：7 月 20 号雲器科技是有一個新産品的釋出會的，關濤老師友善透露一下嗎？

關濤：謝謝主持人。雲器科技是成立了一年半的資料平台服務提供商，我們的主打的技術口号是多雲和一體化，希望給使用者提供全托管的企業級的極緻簡單的資料平台，我們能同時支援資料和 AI 的負載。

我們在 7 月 20 号會舉辦首次産品釋出會，主題是 “Single Engine · All Data”，如果大家希望關注我們，搜尋雲器科技就能找到我們的網站和公衆号。7 月 20 号，歡迎大家來聽我們的釋出會。雲器是向一體化、SaaS 且多元化的方向演進的，釋出會上我們會分享一個 Kappa 架構的最佳實踐，然後展示一個資料與 AI 的融合平台 Demo ，以及客戶最佳實踐，最後嘗試對融合 AI 的資料平台會有怎樣的效果給出答案。