关于数据库:数据仓库性能测试方法论与工具集

数据仓库 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    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 测试语句后果统计：

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. 弱小的生态系统反对 ：便于与其余云服务和工具进行集成，例如：机器学习平台、可视化平台等等。它与云提供商的生态系统紧密结合，可能疾速获取最新的技术和性能更新，并取得弱小的反对和服务。