目錄

• 目錄
• 數據倉庫 v.s. 傳統資料庫
• 數據倉庫性能測試案例
  • 性能指標
  • 測試方案
    • 測試場景
    • 測試數據集
    • 測試用例
    • 性能指標
    • 測試腳本工具
  • 基準環境準備
    • 硬體環境
    • 軟體環境
  • 測試操作步驟
    • Cloudwave 執行步驟
      • 導入數據集
      • TestCase 1. 執行 13 條標準 SQL 測試語句
      • TestCase 2. 執行多表聯合 join 拓展 SQL1 測試語句
      • TestCase 3. 執行多表聯合 join 拓展 SQL2 測試語句
    • StarRocks 執行步驟
      • 導入數據集
      • TestCase 1. 執行 13 條標準 SQL 測試語句
      • TestCase 2. 執行多表聯合 join 拓展 SQL1 測試語句
      • TestCase 3. 執行多表聯合 join 拓展 SQL2 測試語句
  • 測試結果分析
• 從數據倉庫到雲原生數據倉庫

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

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

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

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

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

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 國際標準測試數據集，該數據集的主要內容如下表所示：

測試用例

• 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    [email protected]  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    [email protected]  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     [email protected]  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 測試語句結果統計：

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

從上述測試結果中可以看出 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. 強大的生態系統支持：便於與其他雲服務和工具進行集成，例如：機器學習平臺、可視化平臺等等。它與雲提供商的生態系統緊密結合，能夠快速獲取最新的技術和功能更新，並獲得強大的支持和服務。