备案控制台
探索云世界
开发者社区 大数据 文章 正文

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

2023-07-04 351
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： 数据仓库是数据库的下一代产品形态 —— 如何对数字化转型过程中涌现的数据集合进行有效的存储、分析和利用，继而帮忙企业进行运营决策优化甚至创造出新的获客模式和商业模式形成竞争力，是企业主们亟需解决的问题。在数据价值爆发的时代背景中，数据仓库在千行百业中都有着相应的应用场景。

目录

数据仓库 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 协议的国产开源数据仓库产品，

另外，这两款产品的安装部署和操作手册的文档都非常详尽，请大家自行查阅，下文中主要记录了测试操作步骤，并不赘述基本安装部署的步骤。

测试场景

在本文中首先关注应用场景更加广泛的结构化数据的 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 执行步骤

导入数据集
  • 查看为 Hadoop 准备的存储空间。
$ ./sync_scripts.sh 'df -h' | grep home

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

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

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

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

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

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

  • 因为数据集非常大所以导入的时间较长，大概 58 分钟。

  • 通过执行 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 执行步骤

导入数据集
  • 清空 HDFS 存储。
$ hdfs dfs -rm -r /cloudwave
$ hdfs dfs -ls /

  • 启动 StarRocks FE（前端）守护进程。
$ ./fe/bin/start_fe.sh --daemon

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

$ 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)" +

测试结果分析

  • 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 条多表联合 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. 强大的生态系统支持：便于与其他云服务和工具进行集成，例如：机器学习平台、可视化平台等等。它与云提供商的生态系统紧密结合，能够快速获取最新的技术和功能更新，并获得强大的支持和服务。

文章标签：
性能测试
测试技术
Cloud Native
数据挖掘
分布式计算
SQL
索引
监控
Hadoop
数据库
存储
关键词：
测试工具
性能测试工具
数据仓库测试
相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
云物互联
目录
相关文章
jianz123
|
19天前
|
测试技术 C语言
网站压力测试工具Siege图文详解
网站压力测试工具Siege图文详解
jianz123
26 0
python兴趣圈
|
1月前
|
JavaScript jenkins 测试技术
这10款性能测试工具，收藏起来，测试人的工具箱！
这10款性能测试工具，收藏起来，测试人的工具箱！
python兴趣圈
84 1
天下无贼001
|
1月前
|
人工智能 监控 测试技术
利用AI辅助工具提升软件测试效率
【2月更文挑战第17天】 随着科技的不断发展，人工智能（AI）在各个领域的应用越来越广泛。在软件测试领域，AI技术也发挥着重要作用。本文将探讨如何利用AI辅助工具提升软件测试效率，包括自动化测试、智能缺陷识别和预测等方面。通过引入AI技术，软件测试过程将变得更加高效、准确和可靠。
天下无贼001
198 1
小馒头学Python
|
1月前
|
Web App开发 前端开发 测试技术
探索自动化测试工具：Selenium的威力与应用
探索自动化测试工具：Selenium的威力与应用
小馒头学Python
49 0
探索自动化测试工具：Selenium的威力与应用
游客kwe6k52lwpmug
|
1月前
|
测试技术
现代软件测试中的自动化工具与挑战
传统软件测试面临着越来越复杂的系统架构和不断增长的测试需求，自动化测试工具应运而生。本文将探讨现代软件测试中自动化工具的应用和挑战，深入分析其优势与局限性，为软件测试领域的发展提供思路和启示。
游客kwe6k52lwpmug
23 0
游客7v53mftipku2u
|
1月前
|
jenkins 测试技术 持续交付
现代软件测试中的自动化工具与挑战
随着软件开发领域的不断发展，自动化测试工具在测试过程中扮演着越来越重要的角色。本文将探讨现代软件测试中自动化工具的应用及面临的挑战，旨在帮助开发人员和测试人员更好地理解和应对自动化测试中的问题。
游客7v53mftipku2u
30 2
jianz123
|
19天前
|
测试技术 Linux Apache
网站压力测试工具webbench图文详解
网站压力测试工具webbench图文详解
jianz123
12 0
肥猪肥猪-17824
|
21天前
|
安全 测试技术
深入理解白盒测试：方法、工具与实践
【4月更文挑战第7天】 在软件开发的质量控制过程中，白盒测试是确保代码逻辑正确性的关键步骤。不同于黑盒测试关注于功能和系统的外部行为，白盒测试深入到程序内部，检验程序结构和内部逻辑的正确性。本文将探讨白盒测试的核心技术，包括控制流测试、数据流测试以及静态分析等方法，同时介绍当前流行的白盒测试工具，并讨论如何在实际项目中有效实施白盒测试。文章的目标是为软件测试工程师提供一份综合性指南，帮助他们更好地理解和应用白盒测试技术。
肥猪肥猪-17824
30 1
游客7ofzsdfcat7ls
|
27天前
|
Java 测试技术 API
软件测试中的自动化工具与策略
软件测试是确保软件质量的重要环节，而自动化测试工具和策略的应用在提高测试效率和准确性方面发挥着重要作用。本文将介绍几种常见的自动化测试工具，并探讨在软件测试中应用自动化测试的最佳实践和策略。
游客7ofzsdfcat7ls
16 0
mrq4nk6ni2neg
|
29天前
|
Web App开发 Java 测试技术
深入理解与应用软件自动化测试工具Selenium
随着软件开发的快速发展，软件测试在保证产品质量方面发挥着越来越重要的作用。其中，自动化测试以其效率高、成本低的特点受到了广大开发者的欢迎。本文主要介绍了自动化测试工具Selenium的基本概念、原理以及在实际开发中的应用，旨在帮助读者更好地理解和使用Selenium进行高效的自动化测试。
mrq4nk6ni2neg
22 4

热门文章

最新文章

  • 1
    利用Hive与Hadoop构建大数据仓库：从零到一
  • 2
    构建MaxCompute数据仓库的流程
  • 3
    MongoDB性能最佳实践：如何制定更有效的基准测试？
  • 4
    MaxCompute是一个强大的云数据仓库服务
  • 5
    深入理解自动化测试框架Selenium的设计与实现
  • 6
    如何入门做物联网系统压测？
  • 7
    使用金庸的著作，来测试阿里通义千问最新开放的长文档处理功能
  • 8
    提升软件测试效率与质量的策略
  • 9
    渗透测试工程师面试题大全
  • 10
    《手把手教你》系列技巧篇（十八）-java+ selenium自动化测试-元素定位大法之By css中卷（详细教程）
  • 1
    Apache Flink官方网站提供了关于如何使用Docker进行Flink CDC测试的文档
    145
  • 2
    Kafka【付诸实践 03】Offset Explorer Kafka 的终极 UI 工具安装+简单上手+关键特性测试（一篇学会使用 Offset Explorer）
    196
  • 3
    P2P网络下分布式文件共享场景的测试
    33
  • 4
    Jest测试核心
    10
  • 5
    探索自动化测试在持续集成环境中的关键角色
    13
  • 6
    软件质量测试笔记-合工大
    102
  • 7
    模拟试错（STE）法让7B大模型测试超GPT-4
    33
  • 8
    《手把手教你》系列基础篇（五）-java+ selenium自动化测试- 创建首个自动化脚本（详细教程）
    42
  • 9
    Flink CDC产品常见问题之使用3.0测试mysql到starrocks启动报错如何解决
    76
  • 10
    DataWorks报错问题之ecs自建数据库连通性测试报错如何解决
    17

    • 相关课程

    更多
  • 高校精品课-北京理工大学-数据仓库与数据挖掘（上）
  • 高校精品课-华东师范大学-数据仓库与商务智能
  • SaaS模式云数据仓库实战
  • 数据分析系统之数据管理与数据仓库
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • SaaS 模式云数据仓库必修课

    • 相关电子书

    更多
  • 上云时代业务压测和诊断最佳实践
  • 超大规模性能测试的云端方案及案例分享
  • Cassandra 性能压测及调优实战

    • 相关实验场景

    更多
  • 测试场景（RDS无优惠）
  • 基于DTS构建一站式实时数据服务
  • 基于Hologres+PAI+计算巢，5分钟搭建企业级AI问答知识库
  • 云原生HTAP数据库，让你的交易和分析一库搞定
  • 基于数据湖架构的网站访问行为分析
  • 通过性能测试PTS对Serverless应用进行性能压测
    • 下一篇
    部署LAMP环境（Alibaba Cloud Linux 3）