導讀

本文將分享云器Lakehouse如何重新定義實時多維分析，幫助客戶實現實時、智能、全托管的數據平臺。主要內容包括以下幾大部分：

• 多維數據分析的發展趨勢和場景解析

• 技術解析：新一代數平臺Lakehouse如何支持實時分析需求

• 價值解析：讓 BI+AI 分析高新鮮度，可智能優化，可面向并發的彈縮

• 對比傳統實時數倉產品的收益對比，參考案例

本文探討企業如何在高時效性業務進程中構建高效靈活的數據應用體系。我們將介紹實時數據應用的關鍵特點和發展趨勢，總結優秀數據平臺的核心特征。文章還將具體展示應用下一代數據平臺的效果，實現降本增效、并構筑結合 AI 的數據分析，打造 BI+AI 基礎設施。最后，我們將展望實時數據分析領域的前沿技術與行業發展趨勢。

實時智能分析不可或缺，但企業面對實施的挑戰和阻礙很多

瞬息萬變的商業環境，數據是生命線

在當前數據驅動的瞬息萬變的商業環境下，每個公司都需要理解數據的本質，做好數據分析逐漸變成企業發展的基礎，做好高時效性的數據分析與決策成為企業發展的驅動力和生存的生命線。

例如，在直播時代之前，人們可能只關注前一個小時或前一天的數據。而今天的直播運營總監希望了解五分鐘內直播間銷量情況，判斷庫存備貨并即時決策促銷策略。業務模式推動數據分析的需求演進，要更實時的分析數據，更實時決策業務。

其次，許多數據團隊不僅為公司內部運營人員提供分析結果，為公司高管提供數據報表，還要整合及建設數據報表給自己的產品用戶，越來越多的數據價值被呈現給最終用戶。千萬個用戶的不規則峰谷的查詢需求且短時間內高并發查詢分析使得后臺系統面臨巨大壓力。

再次，非結構化數據的分析需求凸顯，ML/AI 為非結構化數據分析開辟了新的可能性。

因此，我們應思考新一代的數據分析范式，補充傳統的數據分析體系的短板，亦或重構新的數據架構及模式。

全新的實時數據分析范式

我們設想一種全新的實時數據分析范式，它具備三個主要特征：

• 更實時：業務決策需要更實時的數據分析支撐。傳統離線數據是 T+1 更新，既每天刷新一次。而更實時的數據分析意味著數據的整體更新頻率加速到一小時甚至一分鐘。

• 更智能：更智能的分析能夠開拓洞察數據的方式，囊括更多不同類型的數據。創新的場景包括報表的智能化展示，基于 ML/A I的數據挖掘，非結構化數據的內容歸類與提取，等等。

• 更普惠：大數據分析將不再是個別大廠的專屬能力，而可以成為一個普惠的工具。簡化數據工程，數據分析和開發人員構建數據平臺的復雜度，也讓數據用戶更簡便獲得洞察。

傳統數據架構成為實現多維實時智能分析場景的阻礙

阻礙一：傳統架構下，業務需求的多樣性導致了數據架構復雜，進而限制了整體平臺的能力上限。舉個例子，很多數據平臺維護團隊增加了 20% 新機器資源加到集群中，但是所拿到的性能提升效果還不足 10% 。

阻礙二：傳統的數據湖和實時數據平臺不可兼得，會帶來效能瓶頸。如數據湖的查詢并發能力不足，數據新鮮度和寫入并發度低，嚴重依賴緩存；集成困難，例如成千上萬張異構的表，需要為每個不同的數據庫編寫腳本進行處理；數據實時同步和業務 schema 變化導致的運維復雜，數據整合的成本非常高。

阻礙三：傳統架構通常需要預置資源，閑時浪費，忙時又不夠用。即便有擴展機器的方式，但彈性能力和時效性達不到要求。

總結：企業或組織經常陷入性能-成本陷阱，即把性能不足的問題歸結為資源預算不足。要知道傳統的擴展方式由于上述復雜性原因，提升性能對應成本的增加是成倍的，而非線形增加。企業或許不得不因成本因素決策砍掉一些“非必要”功能，導致數據方向的創新在成本約束下難以成勢。

什么原因造成了傳統數據架構的成本約束，讓我們詳細拆解一下性能與成本。

拆解數據分析效能與成本，為什么成本這么難控

高成本是由于全鏈路積累的連鎖反應，綜合導致的高成本。數據的處理場景，包括數據采集、集成、預處理、存儲、流轉、并發、治理和運維。我們對每個環節進行問題拆解，詳見上圖。

根本原因在于組裝數據工具盡管各有“專長”，但也有“合成謬誤”

當前主流數據架構在提供數據服務或搭建數據分析平臺時，存在數據處理和服務割裂、鏈路冗長等問題，導致高延遲和數據冗余。同時上一代流計算產品需要預留大量 CPU 資源，成本高昂。傳統的?Hadoop?架構不適用于頻繁更新的業務庫場景，而新的實時數據分析工具如 Presto 、?ClickHouse?等在規模支持上有限制。

盡管每個組件都能夠單獨工作，也各有所長，但是對于使用工具的企業來說，合在一起使用，就會出現上述談到的許多阻礙和問題。

總結下一代可支撐實時多維分析的數據平臺需要具備哪些功能

1. 多租戶場景下的分庫分表與合庫合表：在多租戶產品中,數據平臺需要支持分庫分表,同時又要能夠靈活地進行合庫合表操作,以滿足行業分析的需求。此外,為了讓管理層能夠實時掌握業務變化,數據庫與大數據系統之間需要實現極低延遲的數據同步,要求大數據系統具備快速計算和數據推送的能力。

2. 歷史數據與實時數據的無縫整合。

3. 自然語言查詢和多數據源支持。

4. 多云環境下的一致性體驗：數據平臺需要隨著業務平臺一起部署到多個云服務上,如阿里云、騰訊云或 AWS 。在這種情況下,如何在不同的云環境中提供一致的用戶體驗,是數據平臺需要考慮和解決的重要問題。

5. 開放湖倉一體架構,支持 AI 應用：為了更好地支持 AI 應用的發展,數據平臺的架構應采用開放湖倉一體的設計,實現結構化數據和非結構化數據的統一管理。同時,數據分析作業和 AI 模型調用作業也需要進行統一的工作流編排,并通過統一的元數據管理來實現高效的數據治理和權限分配。

6. 彈性資源管理,降低成本。

全新Lakehouse技術解密

如何實時分析海量數據，即取即用

云器Lakehouse做了全新的設計。

• 在數據集成部分，實現了實時同步和產品化操作，例如常見的 MySQL 、 SQL Server 數據庫、 PostgreSQL 數據庫都可以通過平滑配置化方式實現分秒級的數據同步。

• 在數據處理部分，我們使用統一的數據管理，支持增量計算的單一引擎 SingeEngine 來解決實時、離線和不同類型的檢索工作負載問題。

• 在資源控制和資源供應模式方面，采用全托管方式，并通過彈性并發方式提供相關資源，做到毫秒級的資源彈性，以及資源供給的水平份數和規格兩個維度的擴縮。

Lakehouse如何支持實時 BI 及多維分析整體架構

云器提供了面向多維分析的整體架構方案。

當前的數據平臺是一個多云數據平臺，伴隨許多客戶出海，跨越多個數據平臺，賬戶即開即用，一天內就能完成交付，并支持異構云。

• 從查詢實時性來看，數據新鮮度從原來的 T+1 、 H+1 達到了秒級新鮮度。

• 查詢并發度達到千級別以上，并在這種并發度基礎上， BI 工具自動生成的復雜 SQL 查詢，也能控制在 P99 1 秒以內。

• 從降低成本的角度來看，這是一個零運維的全托管產品，使大家能將更多精力放在數據本身的建設以及業務的考慮上，并提供非常高的?SLA?。

云器Lakehouse的三個重點功能能力解密

在低成本限定情況下全面提升數據新鮮度

• 采用了完全的白屏化無代碼配置方式，支持異構數據源兩兩組合，上百種離線和實時的同步鏈路；

• 支持海量千萬級別的數據庫表進行整庫遷移，增量同步，單表或多表同步，多實例合并同步等等一系列策略和功能，這些都是通過配置化方式即可一鍵同步，同步后即可查詢；

• 支持 Schema Evolution ，提供了一體化的運維和監控工具，可以監控流量情況、延遲數據、同步條數、是否存在問題等情況；

• 業務庫的動態變化能夠實時反映在大數據中。根據多位客戶的使用反饋，整體數據延遲在 0 到 20 秒左右，這是一個顯著的提升，為實時業務提供了堅實的基礎。

全托管彈性能力支持業務峰谷并發變化

云器產品構建了一個強大的?Serverless?庫存資源池，使集群能夠毫秒級地按需啟動，根據并發量和 SQL 復雜度自動進行擴縮容。

用戶使用時按量計費，前端查詢的 JDBC 流量無需感知。

研究顯示， APP 查詢存在明顯的峰谷模式。每天 9-11 點、 15-17:30 以及 20-21:30 是查詢高峰,而月末月初是銀行類 APP 數據賬務查詢的高峰。高峰時期的并發查詢量可達低谷時期的百倍至千倍。

智能優化減少彈性并發

• 自動優化能力，簡化用戶操作；

• 采用 AI 技術應用于數據布局優化、緩存策略和智能數據模型優化；

• 自助化產品提供分庫、分區、分桶、索引等操作的作業管理；

• 全托管減少運維負擔，讓開發者專注于數據業務創新。

實時分析場景用例介紹Case Study

下面簡單介紹幾個典型的應用場景。

電商

在電商領域，具體的包括推薦系統的實時化應用場景：進行實時用戶行為分析、內容特征分析以及 A/B 測試等，會涉及不同類型的組件，包括 Spark 、 Hive 、 ClickHouse 、?Druid?等，以及一些基礎服務。圖中每條黃色的線代表一個獨立的分析場景，構成了一個典型的 Lambda 架構。

多種引擎和這個系統組合起來建設成本是比較高的，和業務上對齊難度也比較大。云器Lakehouse的產品作為一體化平臺，將實時和離線部分整合到一個數據倉庫中，使用一個引擎來滿足不同類型的數據分析和處理需求，提高效率并簡化數據處理流程。這樣有幾點優勢：

• 讓中型電商企業可以一步到位獲得完整的大型電商的數據底座能力；

• 數據平臺無啟動門檻，按量低成本實現基于數據的商品的實時推薦能力；

• 多云可擴展運行的數據平臺，不用為云底座的切換額外適配。

金融風控

金融風控場景的數據綜合性要求高，需要跨數據業務域進行數據分析，需要近實時的計算和多維度的數據做綜合計算。

例如基于新數據或用戶新行為觸發規則計算，要做到迅速響應，這就要求高數據新鮮度。實時架構需要結合用戶標簽、購物行為標簽和金融行為標簽，其中金融行為標簽通常是離線標簽，這就要求離線與實時標簽一起進行關聯查詢。

此外，查詢并發量較高，在高并發下的數據的秒級延遲和千級別查詢并發有嚴格要求。

云器Lakehouse的產品作為一體化平臺在這個場景下，有如下優勢：

• 產品化數據集成，可實現海量多數據源的實時集成，并且有易配置的方式，批量對相同類型的分庫分表進行合并集成；

• 100% Serveless ，全托管存算分離架構，保障資源的高峰和低谷需求；

• 優化多表關聯查詢，離線和實時數據鏈路實現融合；

• 高并發高響應度的實時即時查詢支持企業級多用戶使用；

• 企業級數據資源權限管理機制和用戶權限管理機制。

SaaS CRM

SaaS CRM 場景中，需要支持成百上千甚至上萬個多租戶。這些租戶分散在不同類型的 Pod 中。傳統的 BI 工具需要查詢 Greenplum 或 Clickhouse 等系統，而底層服務能力是分散的，這給運維帶來了許多問題。多套系統的組合使得架構變得極其復雜，數據量膨脹至兩到三倍。由于每塊資源較小，進行擴展時，支持的查詢并發不足，資源被隔離在不同的 Pod 中，這是一個標準的 SaaS 軟件數據架構。

此外，租戶級別可能達到幾萬、幾十萬甚至上百萬的量級，每個租戶可能擁有幾個到幾十個表，需要同步的表就會達到千萬級，實時數據同步成為了一大挑戰。解決這一問題，可以進行多項優化，如之前提到的產品化數據集成方式，采用一體化模型建倉，嵌入式 BI ，以及自動優化生成的 SQL 和支持高并發查詢。

某頭部 SaaS CRM 企業，對接數百個數據庫和數萬張表，利用云器Lakehouse的實時數據集成能力，將數據新鮮度從原來的 15 分鐘提升至秒級。此外，查詢時間也變得更穩定，不再受限于 Greenplum 等資源隔離模式。從成本角度來看，實現了接近零運維成本的模式，使用成本也降低了約 50% 。更為重要的是，為客戶提供多云一致性的體驗。

云器Lakehouse目前在阿里云、騰訊云和 AWS 上均有服務，客戶能夠在不同的云平臺上使用同一款產品進行數據處理和分析。企業內部在進行產研架構設計時，只需設計一套系統，無需熟悉多款產品，從而大大縮短了業務上線周期。

展望AI時代的數據平臺架構

前文中介紹了云器Lakehouse數據平臺架構的一些關鍵特性。綜合來看，組裝式的數據架構會導致數據語義處理不統一、數據倉庫維護不統一，以至增加了數據開發和維護的成本。異構存儲和多套元數據的存在，導致了大量計算和存儲資源的冗余。此外，數據架構的復雜性使得在增加新的業務場景時，需要涉及到多個數據庫或其他數據類產品的變動。

云器Lakehouse提供了一體化的數據架構解決方案，其底層是湖倉一體的架構，以統一的元數據和統一的數據管理作為基礎，在此之上，采用單一引擎（single engine）的方式來支持不同場景下的數據變化和數據處理需求，包括批處理計算、流處理計算、交互式檢索以及點查詢等場景。

為了面向 AI 和機器學習的未來處理需求，該架構設計允許多種引擎直接集成進來，共同完成 AI 的處理、訓練和服務。

從實時數倉到Lakehouse

展望未來，尤其是在 AI 時代，單純從數據處理角度來考慮數據平臺建設是不夠的。業務創新需要更實時、更智能、更普惠的數據分析能力，需要新型的數據倉庫模式的支持。新型數據倉庫模式包括一體化的數據倉庫，支持 Schema Evolution 演進、自動刷新，以及結構化數據和非結構化數據的統一管理。

從實時數倉到 Lakehouse ，保持不變的是，在 BI 方向上引入更多交互和場景化，實現更貼合業務高峰和低谷的資源供給，進一步 SaaS 化，從而降低成本；實現全鏈路實時化的同時保持成本可控，實現實時性和成本的平衡，實現一個低成本、全鏈路實時化的數據架構；另外，追求一體化、精簡的數據倉庫，從而將更多資源和能力投入在業務創新上。

變化的部分則包括，大語言模型將逐步深入企業應用，而 AI 相關應用需要全新的數據基礎設施，AI infra 將從自行組裝轉變為依靠全托管平臺。從數據管理和組織的角度來看，湖倉一體技術能夠讓管理更加一致化、多元化，同時管理結構化數據、非結構化數據、文本數據、 JSON 數據和圖片數據。數據平臺本身的技術也將借助智能化方式加速發展和迭代，如何利用 AI 迭代數據平臺技術，也是云器重點研究的方向之一。