一、數據分析的痛點與機遇

在當今大數據時代，實時數據倉庫的需求愈發重要。企業越來越多地依賴數據來支撐業務決策和創新，而“實時性”正逐漸成為影響數據分析和數據倉庫系統選擇的關鍵因素。那么，為什么實時數據倉庫如此重要？我們需要如何構建一個實時數據倉庫？

通過與用戶的接觸和反饋，可以發現企業對于數據分析的實時性有著越來越高的要求。實時數據倉庫的構建和管理中，實時性主要體現在以下三方面：

• 數據服務的實時性：隨著客戶需求的提升，數據產品和服務的實時響應能力變得至關重要。尤其在金融、零售等行業，業務系統需要隨時提供最新數據來支撐運營與決策。
• 數據處理的實時性：在數據進入數據倉庫的速度上，企業要求越來越短的延遲。傳統的批處理模式已經不能滿足高頻數據更新的需求，實時處理數據的能力成了一個重要考量。
• 查詢與分析的實時性：數據倉庫不僅需要快速存入數據，更需要高效的查詢與分析。用戶希望數據一旦進入倉庫，即刻能夠進行高效分析，從而縮短從數據生成到分析產出的時間差。

成本問題與降本增效的需求

在不斷提高實時性的同時，企業也在關注數據分析過程中的成本問題。大數據領域的系統架構經過了二十多年的發展，尤其是基于 Hadoop 生態的技術棧已經相對成熟，但由于它龐大的架構體系，系統的維護和人力成本較高。傳統的 Hadoop 生態系統通常包括 HDFS、MapReduce、Hive 等組件，且每個組件的維護和優化需要專門的人員。這種分散化、多模塊的架構不僅增加了復雜度，也導致運維難度加大，使得企業需要投入大量資源去維護整個技術棧。

為了應對這些痛點，云原生架構成為企業構建實時數據倉庫的重要機遇。云技術的發展使得許多企業能夠輕松獲得彈性資源，極大地緩解了傳統大數據架構中的資源瓶頸。云原生的基礎設施提供了以下兩方面的優勢：

• 云原生技術：在傳統的 IT 架構中，企業往往需要為峰值和低谷同樣的資源配置，但云原生技術允許按需擴展，支持企業只為所用資源付費，實現了更高的性價比。企業無需再維護本地的機房、服務器等硬件基礎設施，降低了大量的固定成本。
• 統一化的架構整合：傳統大數據技術棧中包含多個分散的組件，每個組件需要獨立運維和優化。相比之下，云原生的數據平臺可統一管理存儲、計算和查詢等服務，實現數據湖與數據倉庫一體化、批處理與流處理一體化。比如，數據湖在一體化數據分析中能靈活處理結構化和非結構化數據，而統一架構有助于簡化維護，減少開發和運維成本。

在這種背景下，企業有了拋棄舊技術棧、構建新一代實時數據倉庫的迫切需求。SelectDB 產品正是順應了這一趨勢。通過云原生的技術優勢，SelectDB 不僅能夠幫助企業降低成本，還實現了數據分析全流程的統一化和自動化，打破了傳統架構的技術限制。

二、SelectDB 產品簡介

1. Apache Doris

Apache Doris 是一款采用 MPP 架構的實時分布式 OLAP 數據倉庫，專注于高效的實時數據分析。Doris 項目于 2013 年內部開發，2017 年正式開源，目前在 GitHub 上獲得了接近 13,000 星，全球已有超過 5,000 家企業采用，社區活躍度極高，累計貢獻者超過 650 人，且曾連續數月在大數據開源項目中排名第一。

Doris 廣泛應用于金融、互聯網、電信、交通、物流、零售、制造和游戲等多個領域。其核心優勢體現在以下幾點：

• 實時數據處理：Doris 的設計支持毫秒級的數據加載和查詢，滿足了企業對實時數據分析的高要求。
• 高擴展性的 MPP 架構：Doris 利用 MPP 架構，實現大規模并行計算，確保在面對大數據集時仍能高效處理和快速分析。
• 簡化的運維與管理：Doris 采用統一架構，減少了對復雜組件的依賴，降低了傳統數據倉庫的運維成本，使企業能夠更高效地管理數據平臺。

Doris 在各行業的廣泛應用不僅展示了其在實時分析、擴展性和低運維成本方面的強大優勢，也為 SelectDB 的設計提供了堅實的技術基礎。

2. SelectDB

SelectDB 是基于 Apache Doris 開源項目構建的一個商業化產品，主要定位于實時數據分析平臺。通過在 Apache Doris 之上進行進一步的包裝和優化，SelectDB 在大數據生態系統中充當了高效的分析引擎，支持接入多種數據源并提供數據加工和 BI 分析服務。

SelectDB 可以接入多種數據源，支持包括 MySQL 等傳統數據庫、數據流、數據湖等各種不同的數據來源。對于數據湖中的數據，SelectDB 支持聯邦查詢，這樣用戶無需將數據物理導入至 SelectDB，即可直接進行分析。這種靈活的接入方式不僅簡化了 ETL 過程，還確保數據分析的實時性。

SelectDB 支持多種數據應用，包括數據加工、BI 報表生成、機器查詢等功能。作為大數據平臺中的關鍵一環，SelectDB 通過高效的數據查詢和處理能力，為用戶提供了全方位的數據分析支持。

SelectDB 的三種產品形態

• SelectDB Cloud：一種全托管的云端產品，由 SelectDB 自營。用戶可以在阿里云、騰訊云等公有云平臺上使用 SelectDB Cloud，無需自行管理基礎設施。
• 阿里云數據庫 SelectDB：由阿里云直接提供并集成在阿里云平臺上的 SelectDB 服務，用戶可以像使用其他云數據庫一樣便捷地獲取。
• SelectDB Enterprise：一種支持私有化部署的產品，適用于需要在企業自有 IDC、私有云中部署的場景。該版本滿足了數據安全與合規的需求，適合無法將數據外泄的敏感應用場景。

三、SelectDB 的設計探索與創新

1. SelectDB 的四大設計理念

在設計 SelectDB 時，聚焦于以下四大核心理念，以確保其產品能滿足用戶對實時數據分析的需求，并在云環境中實現高效、靈活的應用：

• 實時極速：SelectDB 重點提升數據導入和查詢的實時性，以滿足用戶對數據分析速度的高要求，實現毫秒級數據處理和查詢響應。
• 融合統一：通過兼容多種數據源，SelectDB 能夠在單一系統中處理不同數據來源的查詢和存儲需求，提供一致的數據服務，適應多樣化的數據處理場景。
• 云原生架構：充分利用云技術的彈性與資源優勢，SelectDB 基于云原生架構設計，以降低用戶的基礎設施成本，并實現高效的資源利用。
• 開放生態：SelectDB 保持開放態度，鼓勵用戶參與開源社區，不僅能夠反饋需求，還可以直接參與開發，從而確保產品在實際應用中持續優化和創新。

2. 實時極速

在設計 SelectDB 時，“實時極速”被視為數據價值的核心之一。團隊認為，數據的時效性越高，其對決策支持的價值就越大。在大數據時代，用戶對實時數據的需求已從過去的“天級”“小時級”提升到“分鐘級”甚至“秒級”，而 SelectDB 正是為滿足這一需求而生的。

要評估數據是否達到實時性，主要考量以下兩方面：

• 數據導入速度：數據從源系統導入 SelectDB 的速度是否足夠快，確保不會因長時間等待而降低數據價值。
• 數據查詢響應：數據的查詢響應時間是否足夠短，以便支持秒級甚至亞秒級別的快速查詢。特別是在需要即時數據分析的場景下，傳統的大數據查詢延遲已經無法滿足需求，SelectDB 通過設計優化在極短時間內實現查詢響應。

為提升數據導入的實時性，SelectDB 提供了多樣化的數據導入 API 和工具。通過集成的 Flink Connector、Spark Connector 等工具，SelectDB 能夠從流式數據源按需導入數據，并支持設定 10 秒、20 秒等靈活的間隔來確保導入的實時性。

此外，SelectDB 在小批量高頻導入上也做了深入優化，具體體現在以下兩方面：

• 更新模型支持：SelectDB 提供了原地更新的組件模型，允許數據在導入時直接更新到已有數據行上。這在傳統大數據架構中是較為復雜的，因為小批量高頻更新通常會犧牲查詢性能，而 SelectDB 通過優化設計有效解決了這一難題。
• Group Commit 優化：SelectDB 實現了“攢批”機制（Group Commit），在實時性與查詢效率之間進行平衡，用戶可按需選擇導入和查詢模式，從而實現最佳性能。

在數據結構的動態變化上，SelectDB 支持輕量級的 schema 更改，用戶可以在秒級時間內完成加列、減列等操作，幾乎對系統無感知。這一功能解決了傳統系統在處理大數據表結構調整時的延遲問題，使用戶在需要頻繁進行 schema 變更時也能靈活應對，滿足了用戶隨時調整數據模型的需求。

攢批（Group Commit）功能

在數據導入過程中，SelectDB 的“攢批”功能為小批量數據的高效寫入提供了靈活方案。該功能通過異步和同步模式的靈活設置，大幅優化了數據導入的實時性和性能。

• 異步模式：在異步模式下，用戶提交的數據立即落盤為 WAL（Write-Ahead Log），而請求會在數據寫入前端返回，用戶提交的數據將會在一定時間后完成導入并可查詢。（例如，用戶可執行單條“INSERT INTO”語句將一行數據寫入，這種方式通常與大數據系統不兼容（因其數據合并和讀寫優化需求），而 SelectDB 提供了對該負載的兼容。在異步模式下，數據可見性延遲可達 10 秒左右，適合對數據可見性要求較低的用戶。）
• 同步模式：同步模式適用于數據導入后立即可見的場景。用戶在提交數據時，系統會在指定的延遲時間內完成數據寫入并返回查詢結果。用戶可自行設定最長等待時間，當數據寫入請求返回時，即可立即查詢結果。這種模式兼顧了數據實時性的需求，但會帶來一定的寫入延遲。
• 非攢批模式：非攢批模式即為原始模式，不進行數據批次積累，數據直接導入。盡管可提供實時的可見性，但性能較差，適合對數據實時性和性能要求極高的特定場景。
• 自定義調優參數：SelectDB 允許用戶根據實際需求自定義調節攢批參數，包括：數據可見性間隔（設定數據在異步模式下的可見時間）、積累批次最大值（控制每次積累的數據批次大小）。這種靈活的配置使得 SelectDB 可以應對不同場景的性能和可見性需求，用戶可以根據實際業務場景進行最優配置。目前，攢批功能在 SelectDB 的兩類 API 上均已實現，可涵蓋絕大多數用戶的使用場景。

攢批功能顯著提高了小批量數據導入的效率，使得數據導入可以在更短的時間內完成并可查詢，同時為不同的場景提供了靈活的可調參數。這種創新功能已被廣泛應用，幫助用戶在小批量、高頻次數據導入中實現最佳的實時性與性能平衡。

在查詢速度方面，SelectDB 在多個大數據應用場景中表現出色，通過自研優化器和基于 Pipeline 的執行框架實現了極致的查詢效率。以下為 SelectDB 在主要查詢場景中的優勢：

• 大寬表查詢：SelectDB 在大寬表查詢中性能領先，特別是在 Clickbench 這樣的系統中表現卓越，甚至達到了榜首水平。這種優勢得益于 SelectDB 在數據結構和執行優化上的創新，使得大寬表的查詢速度大幅提升。
• 多表 JOIN 查詢在多表 JOIN 場景中（如 TPCH、TPCHS 測試基準），SelectDB 同樣具備數量級的性能領先。通過多項執行優化技術（例如基于物化視圖、Runtime Filter 等），SelectDB 在復雜查詢中的表現遠超傳統系統。
• 高性能點查：SelectDB 在高并發點查上具備獨特的優化，能夠實現數量級的吞吐和低延遲，達到了萬億級 QPS 的表現。多項技術的結合，包括對高并發的吞吐率和低延遲的深度優化，使得在點查場景中，SelectDB 展示出極強的性能。

為了提升在高頻點查場景中的性能，SelectDB 針對 IO 和查詢規劃進行了創新優化。以下為關鍵的改進措施：

• 行列混合存儲優化 IO：傳統大數據系統基于列式存儲，導致每次查詢特定行時需要從多列讀取數據，產生大量隨機 IO。SelectDB 通過引入“行列混合存儲”的方案，將每行數據以結構化的形式存入內部列，從而在查詢時可以只讀取該內部列，減少 IO 操作頻次。該方案通過存儲空間換取查詢時間，將原先 1000 列的隨機 IO 縮減為 1 個，大幅提升 IO 效率。
• 專用的點查規劃與執行路徑：在查詢規劃方面，SelectDB 針對點查操作設計了專門的規劃器和執行路徑。對于簡單的點查請求，SelectDB 能夠自動識別查詢條件的明確性，并采用簡化的短路執行路徑，避免了傳統優化器的復雜計算過程。這種路徑能夠快速鎖定目標數據節點并執行查詢，不需要進行數據 shuffle，從而提高查詢速度。
• 預編譯 SQL 語句：對于高頻點查的場景，SelectDB 通過 Prepare Statement 優化，對用戶的 SQL 語句進行預編譯。這減少了重復的解析和語義分析，降低了高 QPS（每秒查詢量）下的解析壓力，實現更高的吞吐性能。
• 緩存與索引優化：SelectDB 在點查上還采用了基于磁盤和內存的緩存，并結合索引技術進一步加速查詢響應。在典型三節點集群配置下，點查吞吐量可達 2 萬-3 萬 QPS，查詢延遲維持在個位數毫秒級別，為用戶提供了極高的查詢性能和低延遲體驗。

3. 融合統一

SelectDB 致力于通過一套系統支持多種工作負載，簡化 ETL 和查詢。其架構演進如下：

• 單庫單倉庫：傳統模式，以單一庫或倉庫為核心，處理有限工作負載，ETL 依賴外部組件。
• 混合數據源：支持多源數據進入倉庫，擴大工作負載能力，但 ETL 效率仍受限。
• 融合統一：SelectDB 通過集成 ETL 和查詢能力，實現對內外表的統一查詢，支持多工作流，簡化數據處理流程，實現"all-in-one"的高效架構。

在融合統一方面，SelectDB 通過對多種數據源（如 HICE、Hive、Iceberg、MySQL 等）的支持，提升了查詢效率，尤其是在湖數據查詢和 ETL 性能上取得顯著優化：

• 多源數據集成：SelectDB 支持通過 Catalog 方式集成多種外部數據源，優化外表查詢的性能。
• 湖數據查詢優化：針對湖數據查詢，SelectDB 在規劃層面進行了優化，通過統一統計信息和 workload 理解，比傳統查詢引擎如 Trino、Presto 表現更優。
• 實時與批處理的統一：SelectDB 支持數據實時導入和庫內ETL，大幅提升性能，相較于 Hive、Spark 等有數量級性能優勢。

SelectDB 通過支持復雜數據類型（如 map、array、variant）實現數據類型的多樣化和簡便性，尤其適用于海量日志數據場景。相比于傳統結構，這些復雜類型能有效簡化用戶操作：

• 復雜數據類型支持：SelectDB 除傳統 MySQL 數據類型外，支持 map、array 等復雜類型及自動類型推導。用戶無需手動定義類型，系統會根據存儲內容自動識別類型，簡化操作。
• 日志場景優化：針對海量日志場景，SelectDB 提供更高的寫入吞吐和更優的性價比，尤其在與 ES（Elasticsearch）系統對比中顯示出顯著的存儲效率和性能優勢，減少了存儲開銷并提升了查詢性能。

4. 云原生架構

在 SelectDB Cloud 的原生架構設計中，系統將計算和存儲徹底解耦，以實現高性價比和靈活的資源管理。架構主要由接入層、計算節點和存儲層組成，關鍵特性包括：

• 統一接入層和云化服務：SelectDB Cloud 作為云化服務，通過統一接入層讓用戶訪問系統的計算與存儲資源，提供一致的訪問體驗。
• 計算與存儲分離：存儲層采用單副本共享的對象存儲方案，既降低成本，又支持計算層的彈性擴展。對象存儲雖然需要網絡訪問，但系統通過本地緩存來保持性能，主要緩存用戶查詢的熱數據。通常情況下，為過去 7 天的數據配置緩存即可，降低整體熱數據成本。
• 性能優化：為了緩解對象存儲訪問的延遲，SelectDB 實現了多層次的緩存，包括基于內存的緩存和預讀優化，使得常用數據能夠快速被檢索。
• 彈性與自動擴縮容：系統支持根據業務高峰和低峰自動擴縮容，用戶可以配置策略來自動調整計算資源，甚至在沒有流量時實現計算節點的完全停機，僅保留倉庫存儲，降低不必要的成本。
• 多計算集群和細粒度隔離：支持多計算集群的隔離，用戶可以將導入和查詢分離，并且同一數據集可以供不同業務使用，以滿足不同的查詢需求，靈活性大大提升。

SelectDB Cloud 的原生架構設計，不僅在性能和彈性上有所保障，還能為用戶在復雜業務負載下提供資源優化和成本控制。

5. 開放生態

在生態方面，SelectDB 基于 Apache Doris 構建，確保與 Apache Doris 的存儲格式和接口兼容。這個設計使得 SelectDB 和 Doris 之間可以隨時切換，用戶在使用開源版本時如果感受到規模擴大后對穩定性和商業支持的需求，可以輕松遷移到 SelectDB 商用版本。而對于需要更高自運維能力的用戶，也可以在 SelectDB 與 Doris 之間隨時轉換，保持靈活性。

此外，SelectDB、Doris 均基于 MySQL 協議，因此任何支持 MySQL 連接的工具（如 MySQL 客戶端、JDBC 等）都可以無縫連接到這些系統。這種兼容性大大簡化了系統的集成和使用，尤其對于已經熟悉 MySQL 的用戶，能夠迅速上手并集成進現有的技術棧。

四、SelectDB 應用場景與用戶案例

1. 案例-統一分析平臺

以某知名服裝生產商為例，該公司的業務流程復雜，涉及多種工作負載，如實時報表、ETL 處理以及數據導出等。之前，企業使用了多個不同的系統，如 GTP、ADB 等，管理這些系統需要大量的人力和維護成本。為了保證系統的穩定性，公司需要至少四五名運維人員來管理這些復雜的系統架構。這個多系統的環境帶來了較高的運維成本和管理難度。

在引入 SelectDB 之后，原有的多個系統被替換為 SelectDB，后者實現了系統的融合統一，能夠處理不同的數據流，例如支持 Flink 以及數據湖查詢等。這樣一來，系統架構變得更加簡化，不再需要多套系統之間的配合工作，整體性能得到了提升，同時運維的復雜性和成本也大大降低。SelectDB 不僅提升了性能，還能支持千億級別的數據處理，提供了便捷的橫向擴展能力，幫助該企業建立了一個統一的數據服務平臺。這一案例展示了 SelectDB 在制造業中作為通用數據平臺的應用效果，尤其是在減少系統復雜性、降低成本和提升性能方面的優勢。

2. 案例-日志搜索分析

在日志場景中，SelectDB 替代了傳統的 ES 和 Loki 等系統，帶來了顯著的成本下降。原本，ES 在性能上表現良好，但存儲成本較高；而 Loki 雖然存儲成本較低，但性能稍遜。通過使用 SelectDB，整體成本大幅下降，存儲和性能都優于 ES。具體來說， SelectDB 在日志檢索方面的性能優越，支持高效的查詢，同時大大降低了存儲開銷。接入 SelectDB 后，用戶的操作變得更加簡便，并且可以直接使用該系統來替代原有的 ELK 生態。

這種轉換帶來的好處不僅限于成本節省，還使得用戶的使用體驗得到了提升，尤其是在需要處理大量日志數據的場景下。SelectDB 的優越性能和低成本使得它成為日志管理和分析的理想選擇。這也說明了 SelectDB 在日志場景中的突出能力，能夠為用戶提供一個高效、低成本的解決方案。對于有興趣深入了解的朋友，可以通過私下交流進一步探討更多細節，或在展臺進行面對面的交流。