數據倉庫是數據庫的下一代產品形態 —— 如何對數字化轉型過程中涌現的數據集合進行有效的存儲、分析和利用，繼而幫忙企業進行運營決策優化甚至創造出新的獲客模式和商業模式形成競爭力，是企業主們亟需解決的問題。在數據價值爆發的時代背景中，數據倉庫在千行百業中都有著相應的應用場景。

目錄

數據倉庫 v.s. 傳統數據庫

隨著 5G 網絡和 IoT 技術的興起，以及越來越復雜多變的企業經營環境，都在促使著包括工業制造、能源、交通、教育和醫療在內的傳統行業紛紛開啟了數字化轉型之路。由于長尾效應的存在，千行百業的數字化轉型過程中必然會釋放出比以往任何時候都要龐大的海量數據。那么如何對這些涌現的數據集合進行有效的存儲、分析和利用，繼而幫忙企業進行運營決策優化甚至創造出新的獲客模式和商業模式形成競爭力，就成為了擺在企業主面前亟需解決的問題。

在這樣的需求背景下，我們也觀察到近年來市場上正在出現越來越多的數據倉庫產品。數據倉庫（Data Warehouse）是一種用于集成、存儲和分析大規模結構化數據與非結構化數據的數據管理系統。相對于傳統的僅用于數據存儲的數據庫（Database）而言，數據倉庫更是一種專門設計的 “數據存儲 + 數據分析 + 數據管理" 一體化解決方案，強調數據的易用性、可分析性和可管理性，提供了包括：數據清洗、整合、轉換、復雜查詢、報表生成和數據分析等功能，用于幫助企業實現基于數據的決策制定和數字化運營場景。

更具體而言，下列表格中從技術層面更細致的對比了兩者的區別：

對比項	傳統數據庫	云原生數據倉庫
需求面向	面向數據存儲，主要用于支持事務處理以滿足業務操作的需求。	面向大規模數據存儲與高效能數據分析，主要用于數據分析和決策支持和，以滿足企業的報表、分析和數據挖掘需求。
數據結構和組織方式	通常以表格的形式組織數據，采用關系型數據模型，通過 SQL 語句進行數據操作。	采用星型或雪花型的結構，將數據組織成事實表和維度表，通過復雜的查詢和分析操作進行數據處理。
數據處理復雜性	通常處理相對較小規模和實時的數據。	處理的數據量通常很大，并且涉及到多個源系統的數據集成和轉換，需要處理復雜的查詢和分析操作，同時兼容 SQL 語句。
可擴展性	從分析到方案制定再到落地實施，周期較長。	在線水平擴展，分鐘級擴展。
數據量級	一般處理 TB 左右以下性能良好，隨著數據量增加維護難度增加。	支持 TB 至 PB 量級，通過平臺管理功能進行運維實例管理和監控。
DBA 維護成本	工作量較大，中間件，SQL 優化性能分析要求 DBA 有豐富的技術經驗。	平臺化運維管理，功能模塊化處理，DBA 工作更便捷高效。
數據分片	引用中間件層需要手動維護分片規則，制定不當容易出現數據傾斜。	分布式數據庫自身具有路由分片算法，分布相對均勻可按需調整。

可見，在數據價值爆發的時代背景中，數據倉庫在千行百業中都有著相應的應用場景，例如：

1. 金融和銀行業：應用數據倉庫平臺對大量的金融數據進行分析和建模，繼而支持風險評估、交易分析和決策制定。
2. 零售和電子商務行業：應用數據倉庫平臺完成銷售分析、供應鏈分析、客戶行為分析等，幫助零售商了解產品銷售情況、優化庫存策略、提升客戶滿意度，并進行個性化推薦和營銷活動。
3. 市場營銷和廣告行業：應用數據倉庫平臺整合不同渠道的市場數據和客戶行為數據，幫助企業了解客戶需求，支持目標市場分析、廣告效果評估、客戶細分等工作。

基于以上原因，我們也希望能夠與時俱進地去考察市場上的數據倉庫產品的特性，并以此支撐公司技術選型工作。技術選型是一項系統且嚴謹的工作內容，需要從功能、性能、成熟度、可控性、成本等多個方面進行考慮，本文則主要關注在性能方面，嘗試探討一種可復用的性能測試方案，包括：性能指標、方法論和工具集這 3 個方面的內容。

數據倉庫性能測試案例

性能指標

數據倉庫的性能指標需要根據具體的應用場景來設定，但通常的會包括以下幾個方面：

1. 讀寫性能：衡量數據倉庫在讀取和寫入數據方面的性能表現。包括：吞吐量（每秒處理的請求數量）、延遲（請求的響應時間）、并發性（同時處理的請求數量）等。
2. 水平擴展性：衡量數據倉庫在大規模系統中的水平擴展能力，能夠隨著客戶端的并發增長而進行彈性擴展，并獲得線性的性能提升。
3. 數據一致性：測試數據倉庫在分布式環境中的數據一致性保證程度。根據應用場景的不同，對數據強一致性、弱一致性、最終一致性會有不同的側重。
4. 故障恢復和高可用性：測試數據倉庫在面對故障時的恢復能力和高可用性。可以模擬節點故障或網絡分區等場景，評估數據倉庫的故障轉移和數據恢復性能。
5. 數據安全性：評估數據倉庫在數據保護方面的性能。包括：數據的備份和恢復速度、數據加密和訪問控制等。
6. 集群管理和資源利用率：評估數據倉庫在集群管理和資源利用方面的性能。包括：節點的動態擴縮容、負載均衡、資源利用率等。
7. 數據庫管理工具性能：評估數據倉庫管理工具在配置、監控、診斷和優化等方面的性能表現。

在本文中主要關注讀寫性能方面的操作實踐。

測試方案

為了進一步完善測試流程，以及對國產數據倉庫大趨勢的傾向性，所以本文采用了相對方便獲取且同樣都是采用了 Hadoop 作為底層分布式文件系統支撐的兩款國產數據倉庫產品進行測試：

1. Cloudwave 4.0（2023 年 5 月發版）是一款由北京翰云時代數據技術有限公司推出的國產商業云原生數據倉庫產品。
2. StarRocks 3.0（2023 年 4 月發版）是一款使用 Elastic License 2.0 協議的國產開源數據倉庫產品，

另外，這兩款產品的安裝部署和操作手冊的文檔都非常詳盡，請大家自行查閱，下文中主要記錄了測試操作步驟，并不贅述基本安裝部署的步驟。

• Cloudwave：https://github.com/CloudwaveDatabase/cloudwave
• StarRocks：https://github.com/StarRocks/starrocks

測試場景

在本文中首先關注應用場景更加廣泛的結構化數據的 SQL 讀寫場景。

測試數據集

測試數據集則采用了常見的 SSB1000 國際標準測試數據集，該數據集的主要內容如下表所示：

表名	表行數（單位：行）	描述
lineorder	60 億	SSB 商品訂單表
customer	3000 萬	SSB 客戶表
part	200 萬	SSB 零部件表
supplier	200 萬	SSB 供應商表
dates	2556	日期表

測試用例

• TestCase 1. 執行 13 條標準 SQL 測試語句。

use ssb1000;

# 1
select sum(lo_revenue) as revenue from lineorder,dates where lo_orderdate = d_datekey and d_year = 1993 and lo_discount between 1 and 3 and lo_quantity < 25;
# 2
select sum(lo_revenue) as revenue from lineorder,dates where lo_orderdate = d_datekey and d_yearmonthnum = 199401 and lo_discount between 4 and 6 and lo_quantity between 26 and 35;
# 3
select sum(lo_revenue) as revenue from lineorder,dates where lo_orderdate = d_datekey and d_weeknuminyear = 6 and d_year = 1994 and lo_discount between 5 and 7 and lo_quantity between 26 and 35;
# 4
select sum(lo_revenue) as lo_revenue, d_year, p_brand from lineorder ,dates,part,supplier where lo_orderdate = d_datekey and lo_partkey = p_partkey and lo_suppkey = s_suppkey and p_category = 'MFGR#12' and s_region = 'AMERICA' group by d_year, p_brand order by d_year, p_brand;
# 5
select sum(lo_revenue) as lo_revenue, d_year, p_brand from lineorder,dates,part,supplier where lo_orderdate = d_datekey and lo_partkey = p_partkey and lo_suppkey = s_suppkey and p_brand between 'MFGR#2221' and 'MFGR#2228' and s_region = 'ASIA' group by d_year, p_brand order by d_year, p_brand;
# 6
select sum(lo_revenue) as lo_revenue, d_year, p_brand from lineorder,dates,part,supplier where lo_orderdate = d_datekey and lo_partkey = p_partkey and lo_suppkey = s_suppkey and p_brand = 'MFGR#2239' and s_region = 'EUROPE' group by d_year, p_brand order by d_year, p_brand;
# 7
select c_nation, s_nation, d_year, sum(lo_revenue) as lo_revenue from lineorder,dates,customer,supplier where lo_orderdate = d_datekey and lo_custkey = c_custkey and lo_suppkey = s_suppkey and c_region = 'ASIA' and s_region = 'ASIA'and d_year >= 1992 and d_year <= 1997 group by c_nation, s_nation, d_year order by d_year asc, lo_revenue desc;
# 8
select c_city, s_city, d_year, sum(lo_revenue) as lo_revenue from lineorder,dates,customer,supplier where lo_orderdate = d_datekey and lo_custkey = c_custkey and lo_suppkey = s_suppkey and  c_nation = 'UNITED STATES' and s_nation = 'UNITED STATES' and d_year >= 1992 and d_year <= 1997 group by c_city, s_city, d_year order by d_year asc, lo_revenue desc;
# 9
select c_city, s_city, d_year, sum(lo_revenue) as lo_revenue from lineorder,dates,customer,supplier where lo_orderdate = d_datekey and lo_custkey = c_custkey and lo_suppkey = s_suppkey and (c_city='UNITED KI1' or c_city='UNITED KI5') and (s_city='UNITED KI1' or s_city='UNITED KI5') and d_year >= 1992 and d_year <= 1997 group by c_city, s_city, d_year order by d_year asc, lo_revenue desc;
# 10
select c_city, s_city, d_year, sum(lo_revenue) as lo_revenue from lineorder,dates,customer,supplier where lo_orderdate = d_datekey and lo_custkey = c_custkey and lo_suppkey = s_suppkey and (c_city='UNITED KI1' or c_city='UNITED KI5') and (s_city='UNITED KI1' or s_city='UNITED KI5') and d_yearmonth  = 'Dec1997' group by c_city, s_city, d_year order by d_year asc, lo_revenue desc;
# 11
select d_year, c_nation, sum(lo_revenue) - sum(lo_supplycost) as profit from lineorder,dates,customer,supplier,part where lo_orderdate = d_datekey and lo_custkey = c_custkey and lo_suppkey = s_suppkey and lo_partkey = p_partkey and c_region = 'AMERICA' and s_region = 'AMERICA' and (p_mfgr = 'MFGR#1' or p_mfgr = 'MFGR#2') group by d_year, c_nation order by d_year, c_nation;
# 12
select d_year, s_nation, p_category, sum(lo_revenue) - sum(lo_supplycost) as profit from lineorder,dates,customer,supplier,part where lo_orderdate = d_datekey and lo_custkey = c_custkey and lo_suppkey = s_suppkey and lo_partkey = p_partkey and c_region = 'AMERICA'and s_region = 'AMERICA' and (d_year = 1997 or d_year = 1998) and (p_mfgr = 'MFGR#1' or p_mfgr = 'MFGR#2') group by d_year, s_nation, p_category order by d_year, s_nation, p_category;
# 13
select d_year, s_city, p_brand, sum(lo_revenue) - sum(lo_supplycost) as profit from lineorder,dates,customer,supplier,part where lo_orderdate = d_datekey and lo_custkey = c_custkey and lo_suppkey = s_suppkey and lo_partkey = p_partkey and c_region = 'AMERICA'and s_nation = 'UNITED STATES' and (d_year = 1997 or d_year = 1998) and p_category = 'MFGR#14' group by d_year, s_city, p_brand order by d_year, s_city, p_brand;

• TestCase 2. 執行多表聯合 join 拓展 SQL1 測試語句。

select count(*) from lineorder,customer where lo_custkey = c_custkey;

• TestCase 3. 執行多表聯合 join 拓展 SQL2 測試語句。

select count(*) from lineorder,customer,supplier where lo_custkey = c_custkey and lo_suppkey = s_suppkey;

性能指標

這里設定 2 個最常見的性能指標：

1. 最大 CPU 資源占用數據；
2. 最大 TestCase 執行耗時數據。

并且為了對測試結果進行 “去噪“，每個 TestCases 都會執行 19 輪 SQL 測試腳本。值得注意的是，還需要額外的去除掉第 1 輪的測試數據，因為第 1 次查詢性能數據會收到系統 I/O 的變量因素影響。所以應該對余下的 18 輪測試數據做平均計算，以此獲得更加準確的 SQL 執行平均耗時數據。

測試腳本工具

• Cloudwave 測試腳本：

#!/bin/bash
# Program:
#       test ssb
# History:
# 2023/03/17    junfenghe.cloud@qq.com  version:0.0.1

rm -rf ./n*txt
for ((i=1; i<20; i++))
do
    cat sql_ssb.sql |./cplus.sh > n${i}.txt
done

• StarRocks 測試腳本：

#!/bin/bash
# Program:
#       test ssb
# History:
# 2023/03/17    junfenghe.cloud@qq.com  version:0.0.1

rm -rf ./n*txt
for ((i=1; i<20; i++))
do
    cat sql_ssb.sql | mysql -uroot -P 9030 -h 127.0.0.1 -v -vv -vvv >n${i}.txt
done

• 結果分析腳本：

#!/bin/bash
# Program:
#       analysis cloudwave/starrocks logs of base compute
# History:
# 2023/02/20     junfenghe.cloud@qq.com  version:0.0.1

path=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/sbin:/usr/local/bin:~/bin
export path

suff="(s)#####"

if [ -z "${1}" ]
then
    echo "Please input database'name"
    exit -1
fi

if [ -z "$2" ]
then
    echo "Please input times of scanner"
    exit -f
fi

if [ -n "${3}" ]
then
    suff=${3}
fi

for current in ${2}
do
    result_time=""

    if [ "${1}" == "starrocks" ]
    then
        for time in $( cat ${current} | grep sec  | awk -F '('  '{print $2}' | awk -F ' ' '{print $1}' )
        do
            result_time="${result_time}${time}${suff}"
        done
    elif [ "${1}" == "cloudwave" ]
    then
        for time in $( cat ${current} | grep Elapsed | awk '{print $2}'| sed 's/:/*60+/g'| sed 's/+00\*60//g ; s/+0\*60//g ; s/^0\*60+//g' )
        do
            result_time="${result_time}${time}${suff}"
        done
    fi
    echo ${result_time%${suff}*}
done

exit 0

• sql_ssb.sql 文件：用于保存不同 TestCases 中的 SQL 測試語句，然后被測試腳本讀取。

基準環境準備

硬件環境

為了方便測試環境的準備和節省成本，同時盡量靠近分布式的常規部署方式。所以測試的硬件環境采用了阿里云上的 4 臺 64 Core 和 256G Memory 的云主機來組成分布式集群，同時為了進一步避免磁盤 I/O 成為了性能瓶頸，所以也都掛載了 ESSD pl1 高性能云盤。

軟件環境

• JDK 19：Cloudwave 4.0 依賴

• JDK 8：StarRocks 3.0 依賴
  

• MySQL 8：作為 StarRocks FE（前端）
  

• Hadoop 3.2.2：作為 Cloudwave 和 StarRocks 的分布式存儲，并設定文件副本數為 2。
  

測試操作步驟

Cloudwave 執行步驟

導入數據集

1. 查看為 Hadoop 準備的存儲空間。

$ ./sync_scripts.sh 'df -h' | grep home

2. 格式化 Hadoop 存儲空間。

$ hdfs namenode -format

3. 啟動 HDFS，并查看服務狀態。

$ start-dfs.sh 
$ ./sync_scripts.sh 'jps'

4. 創建 SSB1000 數據集的上傳目錄。

$ hdfs dfs -mkdir /cloudwave
$ hdfs dfs -mkdir /cloudwave/uploads
$ hdfs dfs -put ssb1000 /cloudwave/uploads/

5. 檢查數據上傳結果，可以看到 SSB1000 數據集，占用了 606GB 的存儲空間。

$ hdfs dfs -du -h /
$ du -sh /home/cloudwave/ssb-poc-0.9.3/ssb-poc/output/data_dir/ssb1000

6. 啟動 Cloudwave。

$ ./start-all-server.sh

7. 導入 SSB1000 數據集。

$ ./cplus_go.bin -s 'loaddata ssb1000'

8. 因為數據集非常大所以導入的時間較長，大概 58 分鐘。
   

9. 通過執行 HDFS 的命令，可以看到 Cloudwave 對數據集同步進行了數據壓縮，這也是 Cloudwave 的特性功能之一。SSB1000 的原始大小是 606G，導入后被壓縮到到了 360G。下圖中的 720G 表示 HDFS 中 2 個數據副本的總大小，壓縮比達到了可觀的 59%。
   

TestCase 1. 執行 13 條標準 SQL 測試語句

將 TestCase 1 的 13 條標準 SQL 測試語句寫入到 sql_ssb.sql 文件中，然后執行 Cloudwave 測試腳本，同時監控記錄 CPU 資源的使用率數據。

$ ./test_ssb.sh

結果如下圖所示。在 TestCase 1 中，4 節點的 Cloudwave 集群的最大 CPU 使用率平均為 5763% / 6400% = 90%（注：64 Core CPU 總量為 6400%）。

如下圖所示，執行分析腳本程序來計算 TestCase 1 的平均耗時為 7.6s。

$ ./analysis.sh cloudwave "$(ls n*txt)" +

TestCase 2. 執行多表聯合 join 拓展 SQL1 測試語句

將 TestCase 2 的 多表聯合 join 拓展 SQL1 測試語句寫入到 sql_ssb.sql 文件中，然后執行 Cloudwave 測試腳本，同時監控記錄 CPU 資源的使用率數據。

$ ./test_ex.sh

結果如下圖所示。在 TestCase 2 中，4 節點的 Cloudwave 集群的最大 CPU 使用率平均為 0.0935%（6% / 6400%）。

如下圖所示，執行分析腳本程序來計算 TestCase 2 的平均耗時為 12ms。

$ ./analysis.sh cloudwave "$(ls n*txt)" +

TestCase 3. 執行多表聯合 join 拓展 SQL2 測試語句

將 TestCase 2 的 多表聯合 join 拓展 SQL2 測試語句寫入到 sql_ssb.sql 文件中，然后執行 Cloudwave 測試腳本，同時監控記錄 CPU 資源的使用率數據。

$ ./test_ex.sh

結果如下圖所示。在 TestCase 2 中，4 節點的 Cloudwave 集群的最大 CPU 使用率平均為 0.118%（7.6% / 6400%）。

如下圖所示，執行分析腳本程序來計算 TestCase 3 的平均耗時為 14ms。

$ ./analysis.sh cloudwave "$(ls n*txt)" +

StarRocks 執行步驟

導入數據集

1. 清空 HDFS 存儲。

$ hdfs dfs -rm -r /cloudwave
$ hdfs dfs -ls /

2. 啟動 StarRocks FE（前端）守護進程。

$ ./fe/bin/start_fe.sh --daemon

3. 添加 StarRocks BE（后端）單元。

$ mysql -uroot -h127.0.0.1 -P9030
$ ALTER SYSTEM ADD BACKEND "172.17.161.33:9050"; 
$ ALTER SYSTEM ADD BACKEND "172.17.161.32:9050"; 
$ ALTER SYSTEM ADD BACKEND "172.17.161.31:9050"; 
$ ALTER SYSTEM ADD BACKEND "172.17.161.30:9050"; 

4. 啟動 StarRocks BE 守護進程。

$ ./sync_scripts.sh "cd $(pwd)/be/bin && ./start_be.sh --daemon &&ps -ef | grep starrocks_be"

5. 驗證 StarRocks 集群狀態，依次查看 4 個節點都 Alive=true 了。
   

6. 創建表。
   

7. 開始導入數據，SSB1000 的導入時間總計為 112 分鐘。

$ date && ./bin/stream_load.sh data_dir/ssb100 && date

導入過程中可以發現雖然設置了 HDFS 的副本數為 2，但 StarRocks 將副本數自動修改為了 3。

另外在導入數據集時，發現 StarRocks 似乎沒有進行數據壓縮，占用了 1T 的存儲空間，所以導入時間也相應的變得更長。

TestCase 1. 執行 13 條標準 SQL 測試語句

將 TestCase 1 的 13 條標準 SQL 測試語句寫入到 sql_ssb.sql 文件中，然后執行 StarRocks 測試腳本，同時監控記錄 CPU 資源的使用率數據。

$ ./test_ssb.sh

結果如下圖所示。在 TestCase 1 中，4 節點的 StarRocks 集群的最大 CPU 使用率平均為 67%（4266% / 6400%）。

如下圖所示，執行分析腳本程序來計算 TestCase 1 的平均耗時為 10.39s。

$ ./analysis.sh cloudwave "$(ls n*txt)" +

TestCase 2. 執行多表聯合 join 拓展 SQL1 測試語句

將 TestCase 2 的 多表聯合 join 拓展 SQL1 測試語句寫入到 sql_ssb.sql 文件中，然后執行 StarRocks 測試腳本，同時監控記錄 CPU 資源的使用率數據。

$ ./test_ex.sh

結果如下圖所示。在 TestCase 2 中，4 節點的 StarRocks 集群的最大 CPU 使用率平均為 78.7%（5037% / 6400%）。

如下圖所示，執行分析腳本程序來計算 TestCase 2 的平均耗時為 2.79s。

$ ./analysis.sh cloudwave "$(ls n*txt)" +

TestCase 3. 執行多表聯合 join 拓展 SQL2 測試語句

將 TestCase 2 的 多表聯合 join 拓展 SQL2 測試語句寫入到 sql_ssb.sql 文件中，然后執行 StarRocks 測試腳本，同時監控記錄 CPU 資源的使用率數據。

$ ./test_ex.sh

結果如下圖所示。在 TestCase 2 中，4 節點的 Cloudwave 集群的最大 CPU 使用率平均為 90.5%（5797% / 6400%）。

如下圖所示，執行分析腳本程序來計算 TestCase 3 的平均耗時為 4.8s。

$ ./analysis.sh cloudwave "$(ls n*txt)" +

測試結果分析

1. 13 條標準 SQL 測試語句結果統計：

數據倉庫	數據集	響應時間（s）	CPU 最大占用率	存儲壓縮比	數據導入時間
Cloudwave 4.0	ssb1000	7.602	90%（5763%/6400%）	59%（360G/606G）	58分鐘
StarRocks 3.0	ssb1000	10.397	66.6%（4266%/6400%）	169%（1024G/606G）	112分鐘

2. 2 條多表聯合 join 擴展 SQL 測試語句結果統計：

數據倉庫	數據集	拓展SQL1響應時間（s）	拓展SQL1 CPU 最大占用率	拓展SQL2響應時間（s）	拓展SQL2 CPU 最大占用率
Cloudwave 4.0	ssb1000	0.012	0.0935%（6%/6400）	0.014	0.118%（7.6%/6400）
StarRocks 3.0	ssb1000	2.79	78.7%（5037%/6400）	4.8	90.5%（5797%/6400）

從上述測試結果中可以看出 Cloudwave 云原生數據倉庫的性能表現是非常突出的，尤其在在多表聯合 join 擴展 SQL 場景下，Cloudwave 4.0版本的 CPU 資源占有率非常低的同時執行速度也非常快。

當然，數據倉庫性能優化和測試是一門復雜的系統工程，由于文檔篇幅的限制上文中也只是選取了比較有限的測試場景和性能指標，主要是為了學習研究和交流之用，實際上還有很多值得優化和擴展的細節。

從數據倉庫到云原生數據倉庫

最后在記錄下一些學習心得。從前提到數據庫（Database）我會認為它們單純就是一個用于存放結構化數據或非結構化數據的 DBMS（Database Management System）應用軟件。但隨著數據挖掘的價值體系被越來越多用戶所認可，以及越來越多的用戶需求將數據應用于提升實際的生產效率上。使得單純面向數據存儲的數據庫逐漸被堆疊了越來越多的業務應用功能，進而演變成一個面向數據分析的數據倉庫（Data Warehouse）。

以基于云原生架構的 Cloudwave 4.0 數據倉庫的為例，從下圖的產品架構可以看出，Cloudwave 除了支持常規的結構化數據和非結構化數據存儲功能之外，還具有面向頂層應用程序的數據服務層，以多樣化的 SDK 驅動程序向應用程序提供數據存儲、數據管理、平臺管理、服務接入插件等能力。

尤其是 Cloudwave 所支持的并行全文檢索功能令我印象深刻，這個功能在文本信息處理場景中非常必要。下面引用了《翰云數據庫技術白皮書》中的一段介紹。更多的技術細節也推薦閱讀這本技術白皮書。

Cloudwave 能夠對 CLOB 大文本字段以及 Bfile 文件（e.g. 常用的 PDF、Word、 Excel、PPT、Txt 以及 Html 等）實現全文索引功能，實現了基于 HDFS 的 Lucene 索引存儲，保證了索引數據的安全性，并對 Lucene 索引數據進行自動分段，由多服務器均衡管理。全文檢索時，多服務器對索引段并行檢索，這樣就提高了查詢效率。處理 Bfile 類型的文件時，利用現有的解析類庫，從不同格式的文檔中偵測和提取出元數據和結構化內容。

此外，Cloudwave 云原生數據倉庫還集成了云原生架構技術體系，帶來了更多的集群化管理優勢，例如：

1. 彈性擴展性：支持根據需求進行彈性擴展，根據數據量和工作負載的變化自動調整資源。這使得數據倉庫能夠處理大規模數據集和高并發查詢，并滿足不斷增長的業務需求。
2. 靈活性和敏捷性：可以快速適應業務變化和新的數據分析需求，支持與多種云原生平臺上多種分析工具和技術的無縫集成。
3. 強大的生態系統支持：便于與其他云服務和工具進行集成，例如：機器學習平臺、可視化平臺等等。它與云提供商的生態系統緊密結合，能夠快速獲取最新的技術和功能更新，并獲得強大的支持和服務。