0
| 本文作者： 胡敏 | 2024-01-31 18:44 |
“感謝云數(shù)據(jù)倉庫多年來的辛勤付出，但它們引領(lǐng)的霸權(quán)時代即將落幕。”
在近期的一篇博客中，Clickhouse 產(chǎn)品VP Tanya在文章開頭便放出了這一大膽的觀點。Tanya稱，以Snowflake、Redshift、BigQuery為代表的云數(shù)倉已經(jīng)不能完全滿足客戶需求，并且許多企業(yè)也已經(jīng)發(fā)現(xiàn)云數(shù)據(jù)倉庫成本不可持續(xù)。
此觀點一發(fā)，也引起了業(yè)內(nèi)人士諸多討論。
有人認(rèn)為，云數(shù)倉從來就沒形成過霸權(quán)時代。而Tanya在文中所反復(fù)提到的實時數(shù)倉，也有從業(yè)者表示這并非新概念，早在十年前，實時數(shù)倉就已經(jīng)被提過好幾撥。
還有人認(rèn)為，實時數(shù)倉雖是一個發(fā)展趨勢，但并不能完全代替?zhèn)鹘y(tǒng)數(shù)倉，與此同時，市場對于實時數(shù)據(jù)分析需求有，但也沒那么強......
基于上述的一些討論，雷峰網(wǎng)(公眾號：雷峰網(wǎng))獨家對話了Clickhouse 產(chǎn)品VP Tanya，了解其寫作該文章的由來以及觀點。Tanya稱，這篇文章她想表達的含義并非是說ClickHouse可以替代所有現(xiàn)有的數(shù)據(jù)倉庫場景，而是希望對其進行演進。
同時，借由這一篇文章，雷峰網(wǎng)也對話了業(yè)內(nèi)多位專家：阿里云數(shù)據(jù)庫事業(yè)部OLAP與工具高級產(chǎn)品專家薛菲、嬴圖創(chuàng)始人孫宇熙、PingCAP副總裁劉松、酷克數(shù)據(jù)副總裁魏一、Airwallex技術(shù)專家董大凡、Aloudata CEO周衛(wèi)林與他們分別聊了聊數(shù)倉的發(fā)展趨勢、云數(shù)倉成本、數(shù)倉深層計算、生成式AI對數(shù)倉影響等幾個備受關(guān)注的話題。
實時數(shù)倉確實一個發(fā)展趨勢，對話的幾名受訪者也基本同意這一觀點。
PingCAP副總裁劉松過往職業(yè)經(jīng)歷與數(shù)倉息息相關(guān)。職業(yè)生涯前期他入職了Oracle，見證了以Teradata為代表的傳統(tǒng)數(shù)倉的興起。2014年他加入阿里云后，又見證了以Snowflake、BigQuery、Redshift為代表的云數(shù)倉快速冒頭。在他看來，數(shù)倉的確在沿著從傳統(tǒng)數(shù)倉，到云數(shù)倉，再到實時數(shù)倉的方向演進。
這種的演進背后，實際上是客戶需求的變化。
阿里云數(shù)據(jù)庫事業(yè)部OLAP與工具高級產(chǎn)品專家薛菲談到了她接觸過的一家頭部游戲企業(yè)。他們一直致力于吸引更多的玩家，并確保玩家在其平臺上獲得更好的體驗。然而，近年來，他們獲取新客戶成本開始提升，希望獲得更實時的數(shù)據(jù)，了解客戶檔案、行為，以及客戶做了哪些特定的點擊，以便快速調(diào)整他們的策略。
除游戲玩家有需求外，嬴圖創(chuàng)始人孫宇熙提到，他創(chuàng)業(yè)的這幾年接觸國內(nèi)外不少的金融機構(gòu)。他發(fā)現(xiàn)，隨著市場環(huán)境變化，許多客戶，尤其是金融類客戶他們所需要的不僅是事后分析，用數(shù)據(jù)做決策，而是希望有實時分析。拿銀行為例，客戶在一邊轉(zhuǎn)賬的同時，后臺做實時風(fēng)控分析的需求也越來越高漲。
“clickhouse提出要做新一代的實時數(shù)倉?；旧蠘I(yè)界也同意這樣的一個邏輯?！睂O宇熙說道。
數(shù)倉在朝著實時方向發(fā)展，不過新一代的實時數(shù)倉仍不能完全代替以前的數(shù)倉。
Airwallex技術(shù)專家董大凡作為數(shù)倉產(chǎn)品的使用者，他表示：“即便企業(yè)使用了實時數(shù)倉，傳統(tǒng)數(shù)倉也還是有一席之地?！?/p>
為何有一席之地？其一是實時數(shù)據(jù)分析可能帶來更高的成本。Aloudata CEO周衛(wèi)林在創(chuàng)業(yè)之前，在螞蟻金服擔(dān)任數(shù)據(jù)平臺部門負(fù)責(zé)人，他表示，實時數(shù)據(jù)分析成本增加主要有兩個原因：第一，數(shù)據(jù)越實時，數(shù)據(jù)采集和更新的頻次會越高，數(shù)據(jù)預(yù)計算的比例會越低，因此對數(shù)據(jù)計算性能要求會越高，這會帶來費用的增加；第二，通常需要實時數(shù)據(jù)的場景，數(shù)據(jù)分析的顆粒度會很細(xì)，分析的靈活性會越高，這樣數(shù)據(jù)分析的數(shù)據(jù)量會很大，這會帶來費用的增加。
對于一家企業(yè)來說，在追求數(shù)據(jù)時效的同時，成本也是不能回避的問題。假設(shè)一個公司花了100萬，通過數(shù)據(jù)實時化能把風(fēng)控引擎的精確度從50%提升到55%，然而這5%的提升所降低的損失低于投入成本，很顯然企業(yè)投資意愿不會高漲。
因此，實時數(shù)倉通常的場景應(yīng)用會比較明確，ROI 相對確定，對于不確定高的場景很難規(guī)模性使用實時數(shù)倉，原因是比不過傳統(tǒng)數(shù)倉的ROI，尤其是 BI 分析場景上。
此外，當(dāng)下并非所有場景都必須要實時數(shù)據(jù)分析。就比如雙十一，交易額直接在屏幕上面毫秒級刷新固然很爽，但對于老板而言，他可能只要求第二天在辦公室里面看報表，了解雙十一交易額多少，幾點是高峰，他的目的不是為了實時決策，而是為了長期規(guī)劃和決策。
（接下來，雷峰網(wǎng)將推出《投資人，正逃離分析型數(shù)據(jù)庫賽道》，歡迎加作者微信 mindy1857 交流。）
酷克數(shù)據(jù)副總裁魏一也表達了類似觀點。魏一在加入酷克數(shù)據(jù)之前，曾就職于SAP，后來在EMC/Pivotal 從事Greenplum數(shù)據(jù)庫技術(shù)研發(fā)工作，也是數(shù)倉領(lǐng)域的資深專家。在他看來，目前企業(yè)會存在實時數(shù)據(jù)分析需求，但除此之外，企業(yè)還有批處理的需求，雖然批處理數(shù)據(jù)時效性不及實時數(shù)倉，但是成本更低。
由于企業(yè)需求的多樣化，也演化了數(shù)倉廠商們不同的產(chǎn)品研發(fā)策略。有一部分的廠商嘗試在打造一個統(tǒng)一的數(shù)據(jù)服務(wù)平臺，比如說snowflake、酷克數(shù)據(jù)、PingCAP。
“對于企業(yè)決策者而言，他們一定是需要一個統(tǒng)一的數(shù)據(jù)服務(wù)平臺?！蔽阂徽f道。五年以前客戶做大數(shù)據(jù)分析，可能的選擇是：一個離線分析系統(tǒng)加上一個實時分析系統(tǒng)。比如離線分析選擇Hadoop，再疊加一個ClickHouse、Greenplum實時分析的產(chǎn)品。這種做法的劣勢是顯著增加了運營成本，因為要進行數(shù)據(jù)搬遷ETL操作，同時客戶還需要去管理不同的系統(tǒng)。相對地，統(tǒng)一融合的數(shù)據(jù)分析平臺的優(yōu)勢則在于，解決了由ETL導(dǎo)致的數(shù)據(jù)傳輸延遲問題，進一步降低了數(shù)據(jù)分析的成本投入。
魏一表示，酷克數(shù)據(jù)的產(chǎn)品HashData云數(shù)倉目前已在某國有大型銀行穩(wěn)定運行多年，節(jié)點規(guī)模超過30000個。從落地運行情況來看，客戶的數(shù)據(jù)冗余減少達到了30%以上，計算資源消耗也降低了30%。整個數(shù)據(jù)鏈路得以縮短，平均作業(yè)的完成時間加快了3個小時。
還有一部分廠商則不求做大而全的平臺，只做部分需求的滿足，比如BigQuery、RedShift他們現(xiàn)在并沒有把實時數(shù)倉作為優(yōu)先級，仍是服務(wù)于傳統(tǒng)數(shù)倉的需求。而clickhouse則是更專注在新一代實時數(shù)倉上。
這兩種產(chǎn)品策略沒有孰好孰壞，對于客戶來說，最終還是要結(jié)合自己的需求來進行技術(shù)、產(chǎn)品的選型。
實時數(shù)倉所重點強調(diào)的是數(shù)據(jù)處理效率要快，那如果進一步追問該問題，當(dāng)下的實時數(shù)倉到底能快到什么程度？孫宇熙認(rèn)為，即便當(dāng)下的數(shù)倉產(chǎn)品已經(jīng)讓數(shù)據(jù)分析速度有了極大突破，提升了10倍、或是100倍，但這或許并不意味著什么，市場可能需要到是快1萬倍。
為什么這么說？孫宇熙舉了銀行的例子，不論是08年美國次貸危機、還是近期硅谷銀行倒閉，其實背后本質(zhì)問題都是因為金融機構(gòu)的流動性受到?jīng)_擊，所以流動性一直以來是金融機構(gòu)關(guān)注的重點問題。08年金融危機之后，全球所有監(jiān)管機構(gòu)都在起草制定防止銀行流動性變差的協(xié)議，而在其中，設(shè)置了一個重要的指標(biāo)叫做流動性覆蓋率（liquidity coverage vision，縮寫LCR）LCR超過110%，你的流動性就達標(biāo)了；如果低于110，但高于100%，那你屬于很危險，因為很容易被擊穿；如果低于100%，意味著你的流動性已經(jīng)開始出現(xiàn)嚴(yán)重的問題。
在國內(nèi)，監(jiān)管機構(gòu)給出的要求是，2000億規(guī)模以上的中大型銀行都要向監(jiān)管機構(gòu)每日匯報一次LCR?！叭欢?，讓人十分遺憾的是，我們最頭部的大型國有商業(yè)銀行當(dāng)中，幾乎沒有哪一家能每天能把 LCR 這個指標(biāo)計算一次。有的大型銀行甚至只能一個月算一次?！?/p>
為什么銀行做不到？孫宇熙認(rèn)為一個原因是，要算LCR指標(biāo)，需要全行所有的數(shù)據(jù)。把所有的對公客戶、零售客戶等等客戶數(shù)據(jù)全匯總起來，很可能每日處理的數(shù)據(jù)量能達到百億，這種數(shù)據(jù)規(guī)模是驚人的。另一個原因是，目前數(shù)倉計算需要大量的表做關(guān)聯(lián)，“這種表結(jié)構(gòu)最大的問題在于它是低維的，依然是在用行和列來表達這個數(shù)據(jù)，它天然就不善于去做數(shù)據(jù)之間的關(guān)聯(lián)分析?！碑?dāng)用幾十張表去做關(guān)聯(lián)計算的時候，速度自然就會更慢。
在孫宇熙看來，未來數(shù)據(jù)分析效率會更快，除了表結(jié)構(gòu)之外，數(shù)據(jù)倉庫應(yīng)該要支持其他數(shù)據(jù)計算模式，比如說圖計算。圖數(shù)據(jù)庫的好處在于它能夠執(zhí)行某些類型的查詢，不僅可能更快、更有效，而且在編寫這些查詢時語法更為緊湊。
嬴圖曾在一家大型商業(yè)銀行內(nèi)部做過一個實驗，這家銀行原來的LCR計算大概要算4個小時，而用圖計算在2秒鐘內(nèi)，即可完成，“這是一個七千倍以上的性能提升?！?/p>
實際上現(xiàn)在已經(jīng)有許多數(shù)據(jù)倉庫支持除表結(jié)構(gòu)之外的其他數(shù)據(jù)分析，據(jù)薛菲表示，“全文搜索就是一個很好的例子。全文搜索不是結(jié)構(gòu)化數(shù)據(jù)，它是一種半結(jié)構(gòu)化數(shù)據(jù)。許多數(shù)據(jù)倉庫已經(jīng)支持諸如JSON或XML之類的類型，可以用來完成全文搜索的應(yīng)用，比如阿里云的自研數(shù)據(jù)倉庫AnalyticDB?！?/p>
此外，Clickhouse也有一個名為SQL Graph的項目。但Tanya也表示，目前他們的優(yōu)先級放在了如何將向量搜索與傳統(tǒng)分析結(jié)合使用上，而圖計算這部分項目暫時尚未將其列為重點，其最重要的原因是目前圖數(shù)據(jù)缺乏一個統(tǒng)一的標(biāo)準(zhǔn)。從開發(fā)者的角度來看，開發(fā)圖查詢是非常困難的。
不過，當(dāng)下圖計算或圖數(shù)據(jù)庫現(xiàn)在面臨一個巨大的機會，薛菲表示，可以將其與LLM（Large Language Models）結(jié)合起來?！拔磥?，LLM可能會成為處理圖數(shù)據(jù)的新接口，因為用自然語言表達關(guān)系問題要比使用尚未發(fā)明的圖標(biāo)準(zhǔn)更容易?！?/p>
LLM浪潮的崛起，也進一步推動了業(yè)務(wù)和應(yīng)用對向量能力的需求。薛菲稱，目前，阿里云瑤池數(shù)據(jù)庫已全面擁抱向量檢索能力，包括通義行業(yè)大模型在內(nèi)的LLM就采用了企業(yè)級智能數(shù)倉AnalyticDB作為默認(rèn)的向量檢索引擎，性能較開源增強了2~5倍，與全文檢索和結(jié)構(gòu)化搜索聯(lián)合進行多路召回，加速AIGC應(yīng)用落地。
（接下來，雷峰網(wǎng)將推出《大模型會顛覆分析型數(shù)據(jù)庫？》等文章，歡迎加作者微信 mindy1857 交流。）
于客戶而言，性能與成本都要考量。在成本端，近期關(guān)于云數(shù)倉到底貴不貴的話題也引發(fā)討論。包括在 Tanya的文章中也重點提到了關(guān)于云數(shù)倉的成本問題，“與替代方案相比，云數(shù)據(jù)倉庫的用戶支付 3-5 倍的費用并不少見?！?/p>
在接受雷峰網(wǎng)采訪時，她說道：“我們測試了Amazon Redshift，Google BigQuery和Snowflake三大數(shù)倉產(chǎn)品后發(fā)現(xiàn)，在資源消耗方面，這些數(shù)據(jù)倉庫的表現(xiàn)較差，包括較少的數(shù)據(jù)壓縮和運行查詢所需的更多內(nèi)存?！?/p>
雷峰網(wǎng)接觸的一些公司中，的確也有公司反映他們在用云數(shù)倉之后，整體的數(shù)據(jù)分析成本變高了。劉松談到了他們公司的案例。過去他們內(nèi)部使用BigQuery，一年數(shù)倉成本大概是花10萬美金。后來選用BigQuery之后，是原來的四倍。
云數(shù)倉為何會讓人覺得貴，這與其定價模型有關(guān)。定價模型涉及各個方面，例如數(shù)據(jù)掃描量、計算結(jié)果和資源利用率。
Tanya稱，他們曾對Google BigQuery進行了詳細(xì)研究，Google BigQuery的定價模型，除非客戶有承諾支出，否則實際上是按照掃描的數(shù)據(jù)量收費。但并非每個人都能做到承諾支出，同時特別對于初創(chuàng)公司在這方面確實很困難，因為他們的業(yè)務(wù)仍在探索中，很難有公司可以承諾一個特定的資源使用水平。而且承諾支出，也并不能完全彌補價格差距。
而云最大的優(yōu)勢是利用云的彈性和資源調(diào)用能力，假如新手開發(fā)者發(fā)出復(fù)雜查詢語句——“全表掃描”，它能調(diào)動資源，給你不斷地算，最后算出一個“天價”的計價單，你后悔也沒用。而在傳統(tǒng)數(shù)倉中，如果數(shù)倉做不出全表掃描的查詢，它只會死機。
到底如何解決云數(shù)倉的成本問題？在過去的一年里，許多客戶一直在向薛菲咨詢這個問題。
在她看來，要解決成本問題可以從三個方面考慮：第一是，讓產(chǎn)品完全實現(xiàn)Serverless（無服務(wù)器）架構(gòu)。第二方面是存儲，客戶可以使用云存儲，利用云上不同的存儲類型，為那些不經(jīng)常訪問的數(shù)據(jù)降低成本。第三，即保持開放。這也是她認(rèn)為最重要的一個方向。
“云數(shù)據(jù)倉庫之所以昂貴，其中一個原因是它們通常不是開放的，例如，過去如果用戶希望數(shù)據(jù)在數(shù)據(jù)倉庫中，那么就不能從外部計算中心以外的地方創(chuàng)建數(shù)據(jù)，比如不能從Spark中提取數(shù)據(jù)。但是現(xiàn)在，我認(rèn)為許多生態(tài)系統(tǒng)都在變得更加開放，即使數(shù)據(jù)僅存儲在數(shù)據(jù)倉庫中，用戶仍然可以使用自己的Spark、Presto，以及自己的機器學(xué)習(xí)平臺。在這種情況下，數(shù)據(jù)不再是冗余的。”
據(jù)阿里云向雷峰網(wǎng)透露，阿里云目前已與ClickHouse達成國內(nèi)獨家戰(zhàn)略合作，作為ClickHouse在中國獨家的云服務(wù)提供商，阿里云擁有全球最大的ClickHouse商用集群之一，可提供具備獨有企業(yè)級能力的云原生ClickHouse企業(yè)版。企業(yè)版基于存算分離架構(gòu)，可按量計費，比開源自建成本降低30%+。
在魏一看來，即使云數(shù)倉在公有云環(huán)境下可能比傳統(tǒng)數(shù)倉更貴，但考慮到云數(shù)倉規(guī)模化帶來的效率提升優(yōu)勢，從整體來看，云數(shù)倉肯定是要更節(jié)約成本的。
除關(guān)心成本外，今年生成式AI的席卷而來，也讓業(yè)內(nèi)人士非常關(guān)心其對數(shù)據(jù)領(lǐng)域的影響，包括一個是數(shù)據(jù)庫系統(tǒng)如何幫助人工智能(DB4AI)，另一個是人工智能如何幫助數(shù)據(jù)庫系統(tǒng)(AI4DB)。
在Tanya看來，生成式AI在訓(xùn)練的過程中，有很多地方可以利用數(shù)據(jù)平臺。首先是數(shù)據(jù)集篩選與分析，需要對用于訓(xùn)練大型語言模型的數(shù)據(jù)集進行篩選和分析，其中包括進行臨時分析，以確定最適合用于訓(xùn)練的數(shù)據(jù)集。
一旦確定了訓(xùn)練所需的數(shù)據(jù)集，就需要構(gòu)建數(shù)據(jù)管道，用于將這些數(shù)據(jù)集轉(zhuǎn)換為模型訓(xùn)練所需的格式。這是一個涉及數(shù)據(jù)處理和轉(zhuǎn)換的平臺建設(shè)過程。
生成式AI模型一旦構(gòu)建完成，需要與現(xiàn)有數(shù)據(jù)集進行整合。這可能涉及將模型產(chǎn)生的結(jié)果與現(xiàn)有數(shù)據(jù)集相結(jié)合，常見的方式是通過構(gòu)建嵌入來實現(xiàn)，并將其存儲在數(shù)據(jù)庫中，然后進行向量搜索與數(shù)據(jù)分析。
“這是一個有趣的領(lǐng)域，在消費模型的過程中，你可能需要進行向量搜索以及其他數(shù)據(jù)分析。這可能需要在數(shù)據(jù)庫中實現(xiàn)向量搜索功能，其中存在一個討論點，即是選擇專門的向量數(shù)據(jù)庫還是將向量搜索功能集成到傳統(tǒng)數(shù)據(jù)庫中?！?/p>
最后，生成式AI應(yīng)用程序，需要對訓(xùn)練和使用進行觀察。你究竟如何觀察這些情況？你應(yīng)該收集哪些類型的事件？這也是一個大數(shù)據(jù)問題。
在Tanya看來，未來，訓(xùn)練、消費和應(yīng)用可觀察性這三個領(lǐng)域可能都要用到大數(shù)據(jù)平臺。
薛菲表示，目前阿里云也在探索生成式AI與數(shù)倉的結(jié)合，其中探索的第一件事是LLM是否可以成為數(shù)據(jù)的單一或最通用的接口，以及自然語言是否可以成為未來的一切接口。
“也許在未來，SQL將會過時，或許SQL只對一小部分人來說還有關(guān)聯(lián)性，大多數(shù)人與數(shù)據(jù)互動的門檻將被極大的降低，因為LLM使得人們不需要了解SQL或者其他的語言就可以試用數(shù)據(jù)。”
第二個方向是探索AI如何更好地幫助優(yōu)化數(shù)據(jù)系統(tǒng)。
“比如它們?nèi)绾沃辉谛枰牡胤教砑铀饕?，基于AI規(guī)定如何優(yōu)化整個系統(tǒng)。也許我們只需要一個單一的數(shù)據(jù)系統(tǒng)，只需關(guān)心數(shù)據(jù)源，而中間的一切都可以由機器完成。我們不需要進行手動ETL，不需要手動SQL優(yōu)化。我們不需要擔(dān)心所有中間的數(shù)據(jù)建模。所有這些都可以自動完成。”
這些暢想聽起來確實令人興奮，薛菲稱，而自今年年初以來，已經(jīng)有客戶在詢問她，如何將生成式AI融入他們的工作流程中。
他們看到客戶將業(yè)務(wù)與AI相結(jié)合的過程大概分為三個不同的階段：第一階段是試水階段，客戶在這個階段進行初步嘗試，用企業(yè)知識庫在內(nèi)部進行驗證，探索大模型的能力邊界。第二階段是構(gòu)建可擴展且價格合理的AI增強應(yīng)用的階段。在這個階段，客戶仍然使用原始的企業(yè)數(shù)據(jù)，但通過引入LLM來增強其功能。第三階段是一些客戶開始探索構(gòu)建AI原生應(yīng)用程序，進入全新的應(yīng)用領(lǐng)域。
“在試水階段，阿里云的數(shù)據(jù)倉庫AnalyticDB可以通過開放的生態(tài)以及解決方案模版提供快速的概念驗證（POC），以便客戶可以輕松地與LLM連接，進行簡單的向量搜索，測試他們的想法。”薛菲說。
“在構(gòu)建可擴展的AI增強應(yīng)用階段，正如Tanya提出的一個關(guān)鍵問題，向量能力是作為單獨的數(shù)據(jù)庫還是與現(xiàn)有的數(shù)據(jù)庫結(jié)合？我的觀點認(rèn)為是后者會贏得市場。構(gòu)建第二階段的AI應(yīng)用必須從現(xiàn)有數(shù)據(jù)應(yīng)用中發(fā)展而來。因此，客戶的核心需求并不是單純的向量，而是向量搜索需要有機地與其他現(xiàn)有技術(shù)結(jié)合，如全文搜索和SQL。他們需要確保向量全文搜索和SQL能夠完全交織在一起，以保證AI增強應(yīng)用程序的順利運行?！?/p>
薛菲表示，目前看到市場上有很多客戶也紛紛進入這一階段，尤其是許多在線零售商和從事在線旅行，支持聊天機器人等服務(wù)的公司。
而對于未來，可能還會有許多的公司會邁向AI原生應(yīng)用程序的階段。“在這一階段，我們的數(shù)據(jù)存儲需要更深度與大語言模型結(jié)合?！毖Ψ普f道。目前阿里云發(fā)布了一系列新的能力，其中包括將LLM嵌入到阿里云的數(shù)據(jù)倉庫中，或者構(gòu)建一站式平臺，使數(shù)據(jù)和LLM能夠更緊密地交織在一起，使生態(tài)系統(tǒng)更加注重AI而不是數(shù)據(jù)，以便他們可以構(gòu)建下一代完全AI-Native型的業(yè)務(wù)應(yīng)用。
結(jié)語
站在2023年年末，回顧過去一年，不論是對數(shù)倉實時性、深層計算等技術(shù)問題的討論，還是對數(shù)倉成本等商業(yè)化問題的討論，這些眾多議題都在激發(fā)著數(shù)據(jù)庫領(lǐng)域的活力和生機。正如古人智者所言：“滾石不生苔”，在碰撞與交流的過程中，事物才能擺脫沉寂，煥發(fā)出源源不絕的活力，迎來真正的演變。
展望未來，薛菲提出了三個方向：數(shù)據(jù)倉庫會更加Serverless化（無服務(wù)器）、實時湖倉融合以及數(shù)據(jù)與人工智能的深度融合。與此同時，Tanya強調(diào)了“開放”的理念，她堅信未來的創(chuàng)新將在廣泛開放社區(qū)的土壤中蓬勃發(fā)生。
在大模型的引領(lǐng)下、在產(chǎn)業(yè)變革的潮頭中，數(shù)據(jù)庫將持續(xù)演進，而企業(yè)對其需求也將靈活變動。接下來，雷峰網(wǎng)也將持續(xù)推出《投資人，正逃離分析型數(shù)據(jù)庫賽道》《分析型數(shù)據(jù)庫公司相加，干不過一個李佳琪？》《大模型會顛覆分析型數(shù)據(jù)庫？》等文章，歡迎加作者微信（mindy1857）交流。
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
