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