分佈式 Data Warebase - 構築 AI 時代數據基石詳情 - 數據庫,數據倉庫,分佈式系統,人工智能,分佈式事務 Protonbase 博客

導讀：作者以人類世界一個信息層次模型 DIKW 為出發點，引出對計算機世界（系統）處理數據過程的介紹。接着以一個民宿平台數據架構隨業務發展而不斷演進的過程，展示了這場信息革命中，在具體應用場景下，一個系統是如何一步一步變得龐大、複雜的，伴隨而來的是運維、開發、業務中的一系列棘手問題。最後作者引入解決問題的一種新思路：以擴展關係型數據庫為基礎，引入分佈式事務並支持更多數據模型。基於此打造瞭解決性能瓶頸的新一代數據系統——分佈式 Data Warebase，開啓了數據系統的新時代，讓數據涌現智能。

本文結構如下：

人類世界 DIKW 模型
計算機世界的“DIKW”
一個典型數據系統的演進過程
現有數據架構存在着哪些痛點
新一代數據系統——分佈式 Data Warebase
數據系統新使命：讓數據涌現智能

01/人類世界 DIKW 模型

1989 年 Russell Ackoff 提出了一種信息層次模型：DIKW，描述了從數據到智慧的轉化過程，幫助組織和個人在決策中有效利用信息。

其主要包含 4 個層次，以下以一個鐵球的例子來解釋這些概念：

數據（Data）：數據是未經加工的、原始的事實和數字，缺乏含義。比如“9.8”本身並不具備確切的物理含義。
信息（Information）：當數據被整理、分析，賦予一定的背景後，就成為了信息。信息是具有意義的結構化數據，能夠幫助理解數據的內容。比如“一個 1 千克的鐵球以 9.8 米/秒²的加速度下落”這句話中的“9.8”就傳達了特定的信息，即鐵球下降的加速度。
知識（Knowledge）：知識是對信息的理解和歸納。比如，根據觀察，1 千克、5 千克、10 千克的鐵球都以 9.8 米/秒²的加速度下落，可以歸納出“所有的鐵球都以 9.8 米/秒²的加速度下落”這一知識。進一步，我們發現銅球和銀球也以相同加速度下落，於是進一步歸納出“所有物體都以 9.8 米/秒²的加速度下落”。這種歸納和抽象使信息轉化為知識，從而能夠預測未來，如推斷 8 千克的鉛球也將以 9.8 米/秒²的加速度下落。
智慧（Wisdom）：智慧是對知識的深入理解和抽象，具有前瞻性和創造性，能夠做出高質量的決策。例如基於“所有物體都以 9.8 米/秒²的加速度下落”這一知識，可以推斷重力下加速度與落體本身的特性無關，而是時空的一種幾何性質。這就是廣義相對論的核心思想，體現了智慧。智慧是最高級的智能，它需要複雜的推理論證和深刻的洞察，目前僅人類具備這種能力。

以上是人類世界中，對數據的一步步加工利用過程。從數據到智慧，對事物的抽象程度越來越高，理解也越來越深，那計算機世界是如何實現這一過程的呢？

02/計算機世界的“DIKW”

這裏參照 DIKW 模型，介紹每一層在計算機世界是如何實現的。

1. 數據層：比特

對計算機而言，機器使用比特（Bit），即 0 和 1 來表達數據，比如發送的消息、聆聽的音樂、觀看的電影，在計算機裏就是一串 0 和 1。在這一層，機器實現了對數據的存儲，我們知道單獨的數據是沒有意義的，那計算機如何為這串比特賦予意義呢？

2. 信息層：數據模型

在信息層，會為數據賦予上下文意義，並以一定的結構化方式進行組織。數據就此被升級為信息，能夠被計算機理解和處理。這裏我們通過一個例子來展開介紹，“小明預訂了 2024 年 6 月 1 日的兩個標間”。

首先機器會以比特的形式將這些文字存儲為數據，但機器並不理解這個句子的含義。為了讓機器理解它，計算機先將這段文字分解（結構化），分別為關鍵數據和對關鍵數據的描述（業內也稱元數據），比如關鍵數據小明，其描述是預訂人。以這種方式，一條信息就被計算機轉化成具有相互關聯結構的一條記錄，更多的記錄進而形成數據表，我們把這種相關聯的信息組織在一起的方式稱為數據模型，也可以理解為信息的語言。

常見的數據模型有兩種：關係模型和文檔模型。

關係模型：我們所舉的例子就是一種關係模型，將數據進行結構化，並賦予這些數據上下文信息，這樣數據就能夠被機器理解和處理，從而變成信息。作為一種描述信息的語言，關係模型對數據的要求非常嚴格，要求所有數據結構必須完全一致。
文檔模型：這種方式下數據被組織為文檔結構，文檔內部數據具有一定的結構，但數據間結構可以不完全一樣，這種數據也被稱為半結構化數據。文檔模型將數據組織為一種樹狀結構，這種結構能夠較好地表達實體間一對一、一對多的關係。文檔模型是讓半結構化數據變成信息的語言。

數據模型進一步帶動了數據產品的興起，比如以關係模型為基礎發展而來的關係型數據庫，以文檔模型為代表的 NoSQL 數據庫，還有面向 BI 分析場景，引入分佈式、列式存儲等功能的數據倉庫。數據庫產品能夠很方便地把數據轉化為信息，並且高效地存儲、檢索和管理這些信息。不同的數據產品共同構築了信息革命強大的基石。

3. 知識層：嵌入向量

人們通過對信息的整理、歸納、總結形成知識。基於數據模型，在計算機的世界要如何進行這一過程呢？這就要提到知識的一種表示方式：嵌入向量。

前面提到“所有物體都以 9.8 米/秒²的加速度落地”，這就是對大量相關信息的歸納總結。除了這種歸納之外，相關信息的匯聚也能形成知識。比如一個民宿所有信息聚集在一起就形成了一種知識，這個知識刻畫了民宿各個方面的信息，比如價格信息、住宿環境信息、交通信息等。之後我們使用數學語言對各個方面的信息進行量化，形成計算機能夠理解的一個向量。我們把承載這個向量的空間稱之為潛空間。

為方便解釋，這裏我們選取三個方面對民宿進行評估並進行向量化處理，之後對其進行三維可視化，效果如圖所示。

一旦選用了一種數學語言去表達這種知識，我們就可以在這個潛空間中執行各種數學任務：分類、迴歸、重建。通過兩個嵌入向量間的距離，來衡量它們所代表的知識的相似程度。兩個嵌入向量的距離越短，它們所對應的民宿就越相似。

簡單地根據輸入特徵生成的高維向量，在潛空間中的度量不一定能反應它們所代表的知識的相似度，所以實現層面上，通常需要通過模型來生成嵌入向量。這些模型可以是專門的嵌入模型，此外神經網絡的每一層也是一個不斷從輸入信息中抽象更高級知識的過程，這些中間層產出的向量也代表了不同抽象程度的知識。

03/一個典型數據系統的演進過程

基於數據模型搭建起來的各類數據產品，讓行業對數據和信息的應用以空前規模發展起來。特別是門户互聯網和移動互聯網時代的到來，大大加速了各類數據產品的迭代和應用。這裏以一個民宿平台為例，剖析如何運用這些數據產品，不斷滿足業務從簡單到多元的發展過程。

1. 業務初期到經營分析階段

業務初期，民宿的房東將自己的房子上架到民宿平台，有需求的用户在平台上瀏覽，查尋自己感興趣的民宿，之後可能會在平台上完成預訂、入住、離店、以及評價等常規業務操作。

實現這樣一個民宿平台應用，首先從核心的應用服務搭建出發，一開始業務體量相對有限，產品功能一般會按照 MVP 的思路進行設計。從數據架構角度看，概括而言就是簡單查詢，所以最初一般會把所有的數據都存儲在關係型數據庫中，比如 MySQL 或者 PostgreSQL。

隨着業務體量增長，遇到五一或者國慶這樣的假期，民宿的需求往往爆發式增長，簡單的單機關係型數據庫很快就會遭遇性能瓶頸，這個時期需要引入 NoSQL 類型數據庫，比如 MongoDB，主要引入原因是這類數據庫只需簡單增加機器，就可以實現水平擴容，有效應對更高的業務負載；其分佈式架構和優化的數據存儲方式，更適合處理大數據量的業務場景；並且其靈活的數據模型，能夠適應多變的應用需求。

接着業務用户量開始迅速上升，用户需求也越來越多元，用户不再侷限於通過全名的方式去查找民宿，而是希望能夠根據一些關鍵詞找到自己感興趣的民宿，在這方面 MongoDB 提供的能力相對有限。於是系統引入 ElasticSearch，因為其提供了強大的搜索能力，採用內存數據處理使得查詢速度非常快，可以達到近乎實時的數據處理。為了讓搜索引擎能夠提供搜索服務，首先需要把數據導入到搜索引擎之中。數據的導入一般分為兩種形式，第一種是全量數據導入，關係型數據庫和 NoSQL 數據庫裏面的數據會定期以全量的方式導入搜索引擎。第二種是增量數據導入，如果應用對數據的時效性有比較高的要求，還要再引入增量的數據同步鏈路，比如採用 Kafka 和 Flink 這樣的技術把上游的增刪改同步到搜索引擎之中。當搜索引擎有了這些數據後，就可以為應用提供高性能的關鍵詞搜索了。

至此，通過利用各類數據產品，業務系統具備了基礎信息的存儲和高效提取能力。

這個時期的業務，已經渡過了最初的用户量少、商家少、業務數據量少的狀態，我們希望對業務進行各種分析，比如節假日平台 GMV 的同環比情況，民宿預訂量 Top10 的城市是哪些，用户畫像是怎樣等等。所以系統開始引入 Snowflake 或者 Hive 這類數倉產品。這時需要把各種業務數據從各個數據庫同步到數倉之中，然後就可以使用 ClickHouse 或者 Hive 對數據進行全面的 BI 分析。

可以看到伴隨業務的發展，系統持續引入不同的數據產品。又因為各系統依賴的數據來源不同，系統內部存在大量複雜的數據同步作業。此時的數據架構如圖：

2. 傳統式 AI 助理精細化運營階段

首先解釋下，這裏的傳統式 AI 是相對於當下比較火熱的生成式 AI 而言，主要包含業務洞察和實時決策等商業智能的內容。

業務用户量的增加，帶來人羣的多樣性和需求的多元化。以往面向全量用户的運營方式收到的效果開始變得越來越小，甚至有時還會帶來虧損。同時伴隨着市場環境由增量市場轉變為存量市場，面對用户的運營更加呼喚企業精細化運營，於是離線洞察和實時決策等需求開始成為這個階段企業的普遍需求。

💡 離線洞察

民宿房東希望更多住客入住自家民宿，所以他決定通過折扣來做推廣。為了提高推廣的成功率，他希望只發送給對價格敏感的客户。為了做到這點，首先就要理解用户，根據用户的基本信息，以及用户和平台交互的各種行為信息，構建出描述用户的知識。如前文所述，這個知識可以表達為潛空間中的一個嵌入向量，為每個用户構建了相應的嵌入向量後，就可以對這些嵌入向量分類，判斷出個體用户是否對價格敏感。

為了滿足這樣的需求，首先需要對數據進行預處理，比如篩選有用的用户特徵數據，之後交給模型訓練，找出對價格敏感的人羣，然後就可以將這個人羣包發給業務進行營銷推廣活動。到這一步，數據架構方面新增了數據預處理和模型訓練。

💡 實時決策

民宿是受季節性因素影響的行業，有淡旺季之分，如果民宿價格全年保持不變就會有些不合理。淡季的時候，需求變少，如果民宿大量空置會給老闆帶來不小的損失，所以房東為了提高淡季入住率，在以往空置率較高的季節，更傾向降低價格以吸引潛在的住客。同理，旺季時在不影響入住率的前提下，適當提價能夠為房東帶來更高的收入。於是就有了價格波動。

價格什麼時候變動？變動多少？怎樣調整可以讓利益最大化？如果人工判斷將會是一件複雜而繁瑣的事情，相信老闆內心也是拒絕的。假如使用傳統 AI 來處理這件事，民宿老闆想獲取更多收益的業務訴求，就轉變為系統如何實現價格自動調整的問題。

通過上述問題描述可以發現，影響價格的重要因素有兩個：民宿和市場。民宿方面，基礎的操作需要根據民宿的各種特性，比如裝修風格、年份、房間數、地理位置等通過模型產生出一個代表民宿知識的嵌入向量。然後獲取市場相關的信息，比如民宿所在地區當前的總入住率、相似民宿的價格、入住率等信息。AI 模型通過將這些信息和知識整合在一起，實時推斷出一個最優價格，從而實現民宿實時自動定價功能。

技術實現上，這個功能需要依賴一個在線的模型服務，同時這個服務也會依賴上文提到的數據預處理和模型訓練。

為了給這個在線模型服務提供高吞吐低延遲的特徵輸入，需要一個在線的特徵存儲。由於特徵的數據量比較大，通常會採用 MongoDB 或者 HBase 這類存儲作為在線特徵存儲。由於訓練時用到的一些特徵也可能被當作模型服務的輸入，這部分離線的特徵必須同步到在線的特徵存儲中。除此之外，為了得到更好的效果，還可能需要實時計算一些特徵，這進一步增加了系統的複雜度。

除了實時定價以外，實時決策還應用於個性化推薦、實時類營銷任務等場景，這裏暫時不過多展開。這個階段，數據架構迭代升級為下圖：

3. 生成式 AI 助力業務創新階段

2022 年底，以 ChatGPT 為代表的大模型，讓 GenAI（生成式 AI）進入公眾視野。這不僅帶來了技術應用上的新突破，也帶來了人機交互模式上的創新：基於自然語言的對話。

💡 生成式 AI：通用知識提取

生成式 AI 的崛起，特別是基於 Transformer 架構的大語言模型在理解和生成文字，以及基於 Diffusion 的圖像模型生成圖像上取得了重大突破。生成式 AI 能生成高質量的文本甚至代碼，能夠通過文生圖、圖生圖的方式生成圖像，能夠通過文字生成音頻甚至視頻，這一系列能力不僅極大地拓寬了 AI 的使用場景，也在重新定義什麼是非結構化數據，它以一種全新的方式給傳統的非結構化數據賦予結構，從中提取知識。

相比傳統 AI，生成式 AI 訓練的數據集要大幾個數量級。最先進的大語言模型幾乎使用了人類所有公開的高質量文本語料，因此它具備非常廣泛的知識和智能。當你和 ChatGPT 這樣一個先進的大語言模型交互時，它往往能夠對很多問題給出高質量的回答。這可能會帶來錯覺：數據不再重要，擁有這樣一個大語言模型就可以解決一切業務問題。事實恰恰相反，數據在生成式 AI 時代將會變得更為重要。

這裏以九間堂民宿為例，介紹生成式 AI 的實際應用價值。

💡 業務數據驅動的生成式 AI

九間堂民宿計劃在江蘇地區開展廣告宣傳活動，希望利用 AI 技術生成相關營銷圖片。上圖左側即是初步由 AI 生成的圖片，圖中展現了九間房屋，位於地圖上的江蘇。由於通用模型僅掌握有限的基本信息，因此生成了這一初步效果。儘管合格，但廣告效果仍有提升空間。為此，我們蒐集並整理了九間堂在江蘇最受歡迎的幾處民宿的描述和圖片資料，並將這些信息輸入大模型進行學習和優化。經過對業務數據的深入理解後，AI 生成了右側的新圖，相比之下，其廣告效果顯著提升。

業務數據除了在以上內容設計方面具有價值外，還能通過不同的方式讓業務更智能。

✨ 上下文學習（In Context Learning）

這裏舉一個例子，用户對某個民宿感興趣，但是他不確信這個民宿是否能夠讓家裏的所有成員都住得比較舒適。當然他可以自己去詳細地瞭解這個民宿的所有信息，然後再看是否能住下，但這無疑是件繁瑣的事情。

於是我們想利用大語言模型的能力來完成這樣一個規劃，把這個民宿的描述等信息給到大語言模型，然後再向大語言模型提問，請它安排家人的住宿。大家可以看到大語言模型在瞭解了這些信息之後，給出了一個非常合理的安排。這就是大語言模型一個核心的能力，它可以從上下文當中學習知識，並且把自己的智能應用在這些新學的知識上。

✨ 向量搜索

基於嵌入向量的相似性搜索。比如基於 Transformer 的文本嵌入模型能夠為民宿的描述和評論等文字生成嵌入向量。兩個民宿越相似，它們對應嵌入向量的歐氏距離也就越接近。我們把高效地查找與某個指定向量最相近的若干向量的搜索叫作向量搜索。

✨ 檢索增強生成-RAG

通過結合向量搜索技術與大模型的上下文學習能力，發展出了檢索增強生成（RAG）技術。當用户提出一個問題，例如“靠近西湖、適合一家四口居住且為簡約風格的民宿”，我們首先讓大語言模型對問題進行改寫，再利用文本嵌入模型為改寫後的問題生成嵌入向量。接着，通過向量搜索找到與該問題最接近的嵌入向量對應的民宿列表，將這些民宿的描述和用户的問題一同作為上下文輸入給大語言模型。基於上下文學習（In-context Learning）能力，大語言模型能夠理解這些信息，並生成符合用户需求的答案。

✨ 模型微調

檢索增強生成技術通過文本嵌入模型把數據變成嵌入向量，也就是知識。模型微調的基本思路是讓通用模型去學習業務相關的領域知識，從而讓這些領域知識成為模型的內在能力。微調的流程首先把業務數據做各種清洗加工，然後讓大語言模型去學習這些高質量的數據集，從而成為一個理解業務數據的大語言模型。微調的方式一般會分為四種：無監督微調、蒸餾、監督微調、以及強化學習。

這裏簡單介紹一下這些微調方式的原理：

無監督微調：簡單而言就是博覽羣書。比如想讓大語言模型理解古文，需要先找到一些高質量的古文書，然後讓大語言模型閲讀這些書。通過這種泛讀的方式，大語言模型就能總結出古文用字的一些內在規律，就有了一定的古文素養，從而有知識和能力做和古文相關的任務。
蒸餾：這種方式可以理解為找一個老師，跟着一個古文素養很高的老師學，藉助老師能夠更快更好地學到古文的精髓。
監督微調：除了上面提到的兩個沒有明確目的的素質教育之外，應試教育在某些場景也同樣重要。即便大語言模型經過各種素質教育，有了比較好的古文素養，並不代表着它在考試中一定可以得到高分。比如讓大語言模型去參加科舉考試，如果沒有培訓過八股文的寫作，那它就可能因為寫的文章不符合規範而得不到好的成績。應試教育做的就是這種對齊工作，讓大語言模型知道人類在完成某些任務時的一些偏好。最直接的對齊方式是監督微調。在這個例子裏，就是讓大語言模型學習歷屆八股文的考題和範文。通過這種方式，大語言模型就明白了八股文的規範，就學會了如何把古文能力用八股文這種方式表現出來。
強化學習：這種學習方式不會告訴模型什麼是正確答案，但是會給模型寫的文章進行打分，告訴模型這篇文章寫得好還是不好。通過反覆的試驗模型就會找到獲得高分的寫作手法，從而按照人類的期望高質量地完成任務。

簡單總結一下，生成式 AI 和業務數據結合有四種方式：上下文學習、向量搜索、整合了向量搜索和上下文學習的檢索增強生成即 RAG、模型微調。在實際的應用中，往往會把這幾種方式結合在一起，還可能使用外部的工具，我們把這類智能的應用叫做數據智能體，即 AI Agent。

回到民宿這個例子中，可以想象有一個虛擬旅遊顧問，用户可以向它諮詢任何關於旅遊的問題。比如為一家四口人設計一個杭州三天的旅行計劃，並且根據用户反饋進行修改，形成用户滿意的方案後自動完成各種機票、民宿、以及景點的預定。為了完成這些功能，虛擬旅行顧問就需要利用大語言模型的能力去做規劃，使用推薦系統找出用户可能喜歡的杭州的景點，找出這些景點附近用户可能喜歡的民宿，等等。這樣一個 AI Agent 能夠綜合大語言模型的能力並且靈活使用外部的工具。

最終，數據架構迭代至如下情況：

面對如此龐大、複雜的數據架構，你很難想象它能很好地滿足業務高可用、高效率、高質量的訴求。這種架構往往存在一些顯著的痛點。

04/現有架構存在的痛點

運維視角：感受最直接也最深的當屬運維人員，同時運維這麼多產品，勢必會使運維複雜度上升。特別是數據同步，它往往是一個系統中最薄弱的環節，很容易導致系統的不穩定。同時因為一份數據需要在多個產品中重複存儲，一致性方面存在很大挑戰，也帶來了更大的成本。
開發視角：構建這樣複雜的架構有較高的開發門檻，開發人員需要學習和理解多個不同的數據產品，每個數據產品都有一些侷限性，開發人員還需要理解和繞開這些問題。對很多中小公司來説，招聘大量優秀的數據和 AI 工程師是一大挑戰，從而導致很多數據的業務價值並沒有被完全挖掘出來。即使團隊很幸運擁有這些工程師，他們也需要把大量時間花在繁瑣的數據同步上，這無疑極大地降低了開發效率，降低了業務的迭代速度，阻礙了業務的發展。
業務視角：雖然我們剛才所看到架構是從業務需求倒推出來的，但是從業務視角來看，它也不是完美的。因為需要做各個產品之間的數據同步，就無法避免數據延遲的問題。數據延遲會導致業務看到的數據可能不一致，進而導致其它業務問題。特別是對於創新性業務，可能涉及多個業務系統，這樣新業務從想法到落地的過程大大加長，讓業務難以在短時間內形成市場競爭力。

接下來將介紹 ProtonBase 是如何解決這些痛點的。

05/新一代數據系統

1. 基於第一性原理的解題新思路

從以下幾個方面分析和拆解存在的痛點：

之所以存在各種各樣的數據庫，核心原因在於針對不同的業務和性能需求選用不同的數據庫，面向查詢速度引入 ES，面向 BI 分析引入列式存儲，面向巨量數據和安全引入分佈式等；
之所以系統會越來越龐大，核心在於業務驅動下，傳統的解題思路一般是做加法，而非按照第一性原理，用系統的思維去結構化問題。這在公司場景下算是正常現象。
之所以數據架構變得複雜起來，核心在於一個業務需要多種已處理好的數據支持，這就要求在數據架構內部不同系統之間進行大量數據同步，同步伴隨着帶來數據延遲和一致性問題。為了能夠讓系統沒有數據延遲，唯一的選擇是讓數據同步不再是一種必要而是一個選擇。這就意味着我們需要用同一份數據支持各種場景。

綜合評估下，關係型數據庫的功能最完備，離我們的最終目標最接近，所以我們決定以關係型數據庫為出發點去吸取其他產品的一些核心技術。

從語言層次角度考慮，關係型數據庫使用的語言是關係模型，它本身就能夠很好地支持表達結構化的數據。為了能夠很好地表達半結構化的數據，可以引入 JSON 類型。知識層的語言是嵌入向量，可以引入高維向量這種類型。這樣我們在一個表裏同時存儲結構化數據、半結構化數據、以及表達知識的嵌入向量，從此數據同步不再是必須，而是可選的。

從性能的角度考慮，新一代系統應該達到什麼樣的標準？這就要從現在業務所需要的技術説起：

💡 分佈式事務：為了能夠通過增加更多機器的方式提升系統的性能並且保持數據的一致性，就需要實現分佈式事務，然後就能通過數據分片這種橫向擴展方式提升系統的性能。

💡 豐富的索引：速度是系統性能當中最重要的指標之一，特別是在搜索場景。之所以引入搜索引擎，是因為關係型數據庫即使在單機的情況下搜索的效率也很差。為了提升單機搜索性能，可以引入像倒排索引這樣的索引結構。同樣為了提升向量搜索的性能，也可以引入向量索引。

💡 列式存儲：數字化全力推進的當下，為了支持高效彙總分析，引入列式存儲。它能夠提升數據壓縮率，避免大量不必要的 IO，提升系統的分析性能。

💡 向量化執行：通過將操作應用於一組數據（向量）而不是單個數據點來實現高效處理，從而減少查詢執行時間，提升整體性能。

💡 物化視圖：通過物化視圖這種預計算的方式去避免反覆執行同樣的查詢，進一步提升系統的性能。

2. 分佈式Data Warebase

基於以上介紹的新一代技術路線和性能要求標準，ProtonBase 構建出一類全新的數據產品：分佈式 Data Warebase。Data Warebase 這個詞是 Data Warehouse 和 Database 這兩個詞的組合，它意味着 Data Warebase 同時具有了 Data Warehouse 和 Database 的所有能力和優勢。

⭐️ 數據類型：基於關係模型的設計，分佈式 Data Warebase 天然支持結構化的數據。通過擴展 JSON 這種文檔模型，可以很好地支持半結構化數據。通過引入高維向量，支持從傳統意義上的非結構化數據中提取的知識。

⭐️ 應用場景：除了基礎的簡單查詢外，它還能夠很好地支持關鍵詞查詢、以及 BI 方面的彙總分析，同時基於向量的引入，支持通過向量搜索提取知識。

⭐️ 挑戰極限：分佈式 Data Warebase 在性能、正確性、和實時性上挑戰物理極限。

⭐️ 極簡體驗：分佈式 Data Warebase 為用户提供了極簡的體驗，它兼容已有的生態，減少學習成本，充分發揮現有生態工具的能力。它通過隔離，保證不同場景之間互不影響。通過自適應保證它不僅在最苛刻的業務場景達到性能、正確性、和實時性的最優，而且在用户的實際場景裏也能夠挑戰極限，達到具體場景裏性能、準確性和實時性的最優。

分佈式 Data Warebase 在數據架構上帶來了怎樣的改變？

3. 新產品帶來數據智能新範式

分佈式 Data Warebase 可以看作是對傳統數據系統架構基於第一性原理的重構。通過對傳統架構核心痛點的解構，採用全新的技術路線，一站式支持上層業務。極大地簡化了架構，讓技術重心重新回到對業務的高效響應上。