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

这篇具有很好参考价值的文章主要介绍了数据仓库性能测试方法论与工具集。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

目录
  • 目录
  • 数据仓库 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)而言,数据仓库更是一种专门设计的 “数据存储 + 数据分析 + 数据管理" 一体化解决方案,强调数据的易用性、可分析性和可管理性,提供了包括:数据清洗、整合、转换、复杂查询、报表生成和数据分析等功能,用于帮助企业实现基于数据的决策制定和数字化运营场景。

更具体而言,下列表格中从技术层面更细致的对比了两者的区别:

对比项 传统数据库 云原生数据仓库
需求面向 面向数据存储,主要用于支持事务处理以满足业务操作的需求。 面向大规模数据存储与高效能数据分析,主要用于数据分析和决策支持和,以满足企业的报表、分析和数据挖掘需求。
数据结构和组织方式 通常以表格的形式组织数据,采用关系型数据模型,通过 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

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

  1. 格式化 Hadoop 存储空间。
$ hdfs namenode -format

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

  1. 启动 HDFS,并查看服务状态。
$ start-dfs.sh 
$ ./sync_scripts.sh 'jps'

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

  1. 创建 SSB1000 数据集的上传目录。
$ hdfs dfs -mkdir /cloudwave
$ hdfs dfs -mkdir /cloudwave/uploads
$ hdfs dfs -put ssb1000 /cloudwave/uploads/

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

  1. 检查数据上传结果,可以看到 SSB1000 数据集,占用了 606GB 的存储空间。
$ hdfs dfs -du -h /
$ du -sh /home/cloudwave/ssb-poc-0.9.3/ssb-poc/output/data_dir/ssb1000

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

  1. 启动 Cloudwave。
$ ./start-all-server.sh

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

  1. 导入 SSB1000 数据集。
$ ./cplus_go.bin -s 'loaddata ssb1000'

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

  1. 因为数据集非常大所以导入的时间较长,大概 58 分钟。
    数据仓库性能测试方法论与工具集

  2. 通过执行 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 /

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

  1. 启动 StarRocks FE(前端)守护进程。
$ ./fe/bin/start_fe.sh --daemon

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

  1. 添加 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"; 
  1. 启动 StarRocks BE 守护进程。
$ ./sync_scripts.sh "cd $(pwd)/be/bin && ./start_be.sh --daemon &&ps -ef | grep starrocks_be"

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

  1. 验证 StarRocks 集群状态,依次查看 4 个节点都 Alive=true 了。
    数据仓库性能测试方法论与工具集

  2. 创建表。
    数据仓库性能测试方法论与工具集

  3. 开始导入数据,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分钟
  1. 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. 强大的生态系统支持:便于与其他云服务和工具进行集成,例如:机器学习平台、可视化平台等等。它与云提供商的生态系统紧密结合,能够快速获取最新的技术和功能更新,并获得强大的支持和服务。

数据仓库性能测试方法论与工具集文章来源地址https://www.toymoban.com/news/detail-517852.html

到了这里,关于数据仓库性能测试方法论与工具集的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • [渗透测试]—3.1 渗透测试方法论

    渗透测试(Penetration Testing)是一种模拟攻击者的行为,以评估系统安全性的方法。作为一名渗透测试工程师,了解渗透测试的方法论是非常重要的。在本章中,我们将详细介绍渗透测试的基本概念、方法论和常见工具。 渗透测试的主要目的是: 发现潜在的安全漏洞和风险

    2024年02月15日
    浏览(53)
  • 黑盒测试方法论—边界值

    边界值分析法是一种很实用的黑盒测试用例方法,它具有很强的发现故障的能力。边界值分析法也是作为对等价类划分法的补充,测试用例来自等价类的边界。 这个方法其实是在测试实践当中发现,Bug 往往出现在定义域或值域的边界上,而不是在其内部。为检测边界附近的

    2024年02月11日
    浏览(52)
  • 数据建模方法论及实施步骤

    了解数据建模之前首先要知道的是什么是数据模型。数据模型(Data Model)是数据特征的抽象,它从抽象层次上描述了系统的静态特征、动态行为和约束条件,为数据库系统的信息表示与操作提供一个抽象的框架。 一、概要:数据建模简介 数据基本用于两种目的:1、操作型记

    2024年02月05日
    浏览(46)
  • 领域建模之数据模型设计方法论

    本文通过实际业务需求场景建模案例,为读者提供一种业务模型向数据模型设计的方法论,用于指导实际开发中如何进行业务模型向数据模型转化抽象,并对设计的数据模型可用性、扩展性提供了建议性思考。通过文章,读者可以收获到业务模型向数据模型抽象可参考的一种

    2024年02月09日
    浏览(55)
  • 收藏:不错的数据中台建设方法论

    数据中台建设方法论体系,需要从 组织、保障、准则、内容、步骤5个层面 全面考虑,以确保数据中台建设和实施能如期完成。 1种战略行动 ,把用数据中台驱动业务发展定位为企业级战略,全局谋划 2项保障条件 ,通过宣贯统一组织间的数据认知,通过流程加速组织变革

    2024年02月12日
    浏览(43)
  • 领域建模之数据模型设计方法论 | 京东云技术团队

    本文通过实际业务需求场景建模案例,为读者提供一种业务模型向数据模型设计的方法论,用于指导实际开发中如何进行业务模型向数据模型转化抽象,并对设计的数据模型可用性、扩展性提供了建议性思考。通过文章,读者可以收获到业务模型向数据模型抽象可参考的一种

    2024年02月09日
    浏览(42)
  • 构建数据中台的三要素:方法论、组织和技术

    知道要转型,要建设数据中台,却不知咋做,咋办? 现在有很多讲“如何建设数据中台”文章,观点各不相同: 数据中台是数据建设方法论,按照数据中台设计方法和规范实施就可建成数据中台 数据中台背后是数据部门组织架构变更,把原先分散的组织架构形成一个统一中

    2024年02月16日
    浏览(40)
  • 什么是主数据管理?企业主数据管理方法论

    主数据又被称为黄金数据,其价值高也非常重要。对企业来说,主数据的重要性如何强调都不为过,主数据治理是企业数据治理中最为重要的一环。主数据管理的内容包括  主数据管理标准、主数据应用标准  和  主数据集成服务标准  三大类。 主数据管理的作用和意义主要

    2024年02月13日
    浏览(36)
  • MATLAB实战应用-【数据处理篇】数据清洗(从方法论到实战应用)

    目录 前言 数据清洗需要达到什么要求 如何规范数据 一、解决数据的完整性问题:

    2023年04月08日
    浏览(45)
  • 二蛋赠书七期:《云原生数据中台:架构、方法论与实践》

    大家好!我是二蛋,一个热爱技术、乐于分享的工程师。在过去的几年里,我一直通过各种渠道与大家分享技术知识和经验。我深知,每一位技术人员都对自己的技能提升和职业发展有着热切的期待。因此,我非常感激大家一直以来对我的关注和支持。 为了回馈大家的厚爱,

    2024年02月05日
    浏览(45)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包