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

已于 2023-07-04 09:58:06 修改
阅读量9.5k 收藏 103
点赞数 27
分类专栏： 云原生内容合伙人专栏 文章标签： 数据仓库 大数据 spark 数据库 kubernetes 分布式 数据分析
于 2023-07-04 09:54:42 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Jmilk/article/details/131499124
版权

目录

文章目录

数据仓库 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 国际标准测试数据集，该数据集的主要内容如下表所示：

表名表行数（单位：行）描述
lineorder60 亿SSB 商品订单表
customer3000 万SSB 客户表
part200 万SSB 零部件表
supplier200 万SSB 供应商表
dates2556日期表

测试用例

  • 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.0ssb10007.60290%（5763%/6400%）59%（360G/606G）58分钟
StarRocks 3.0ssb100010.39766.6%（4266%/6400%）169%（1024G/606G）112分钟
  1. 2 条多表联合 join 扩展 SQL 测试语句结果统计：
数据仓库数据集拓展SQL1响应时间（s）拓展SQL1 CPU 最大占用率拓展SQL2响应时间（s）拓展SQL2 CPU 最大占用率
Cloudwave 4.0ssb10000.0120.0935%（6%/6400）0.0140.118%（7.6%/6400）
StarRocks 3.0ssb10002.7978.7%（5037%/6400）4.890.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. 强大的生态系统支持：便于与其他云服务和工具进行集成，例如：机器学习平台、可视化平台等等。它与云提供商的生态系统紧密结合，能够快速获取最新的技术和功能更新，并获得强大的支持和服务。

在这里插入图片描述

范桂飓
关注
  • 27
    点赞
  • 踩
  • 103
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 14
    评论
专栏目录
一文理清数据仓库实施方法论
积硅步以致千里
05-09 1759
关键的原则包括： 以数据仓库技术为核心平台 数据平台的设计必须解决现有问题，同时着眼于未来 促进一致性和跨部门的整合 剔除重复的数据 保留事件的历史和事件的相关内容 收集和保存最原始的数据 收集满足现有需要更广泛的数据 为客户的使用、使用模式和角色选择合适的工具 达到自动操作化的最高程度和重复使用 项目具体实施步骤 项目前期准备： 业务探索（Business Discovery） 信息探索（Information Discovery） 逻辑数据模型设计 系统体系结构设计： 物理数据库设计 数据转换加.
数据挖掘论文合集-242篇（part1）
01-13
IDSS 中数据仓库和数据挖掘的研究与实现.caj InternetWeb数据挖掘研究现状及最新进展.caj Internet数据挖掘原理及实现.caj Min-Max模糊神经网络的应用研究.pdf OLAP与数据挖掘一体化模型的分析与讨论.caj OLAP和数据...
数据仓库架构和建设方法论
努力努力再努力！的博客
11-05 6291
1.数据仓库概要 1.1.数据仓库起因 在建设数据仓库之前，数据散落在企业各部门应用的数据存储中，它们之间有着复杂的业务连接关系，从整体上看就如一张巨大的蜘蛛网：结构上错综复杂，却又四通八达。在企业级数据应用上单一业务使用方便，且灵活多变；但涉及到跨业务、多部门联合应用就会存在：①数据来源多样化，管理决策数据过于分散；②数据缺乏标准，难以整合；③数据口径不统一，可信度低；④缺乏数据管控体系，数据质量难以保证。 如果企业在数据建设方面没有一个整体的规划，而采取自然演化的方式，那么在未来数据应用的过程中，将不得
数据仓库构建方法论（六）：数据建模方法论
叶子叶来
01-28 6750
根据boss想法整理一般通用的数据仓库模型构建思路，这里参考了公众号内文章，觉得写得很好，既有理论指导又有实践案例，能够详细地说明； 什么是数据模型？ 数据模型是抽象描述现实世界的工具和方法，通过抽象的实体及实体之间联系的形式，表示现实世界中事务的相互关系的一种映射。数据模型表现的抽象的是实体和实体之间的关系，通过对实体和实体之间关系的定义和描述，来表达实际的业务中具体的业务关系。 数据仓库模型是数据模型中针对特定的数据仓库应用系统的特定数据模型，数据仓库模型分为几个层次： 通过上面的图形，我们能够很
数据挖掘论文合集-242篇（part2）
01-13
IDSS 中数据仓库和数据挖掘的研究与实现.caj InternetWeb数据挖掘研究现状及最新进展.caj Internet数据挖掘原理及实现.caj Min-Max模糊神经网络的应用研究.pdf OLAP与数据挖掘一体化模型的分析与讨论.caj OLAP和数据...
数据挖掘在各行业的应用论文
04-19
数据仓库与数据挖掘.caj 空间数据挖掘技术.caj 数据仓库与数据挖掘技术及其在科技情报业的应用前景.caj 相关案件的数据挖掘.caj 数据挖掘技术.caj 一种实时过程控制中的数据挖掘算法研究.caj EIS 环境下的数据挖掘...
数据挖掘论文合集-242篇（part3）
01-13
IDSS 中数据仓库和数据挖掘的研究与实现.caj InternetWeb数据挖掘研究现状及最新进展.caj Internet数据挖掘原理及实现.caj Min-Max模糊神经网络的应用研究.pdf OLAP与数据挖掘一体化模型的分析与讨论.caj OLAP和数据...
推荐系统架构师考试全套视频教程合集.zip
11-01
5.8数据仓库 5.9数据挖掘 第六部分 计算机网络 6.1开放系统互连参考模型 6.2 TCP/IP协议族 6.3网络规划与设计 6.4计算机网络分类 6.5网络接入技术 6.6网络存储技术 6.7虚拟局域网（VLAN） 第七部分 软件架构设计 ...
数据中台、数据仓库、数据治理与主数据的定位与差异
CServer_01的博客
04-24 442
它们就像一支协同作战的团队，数据中台负责调度和整合数据资源，数据仓库提供数据存储和查询支持，数据治理确保数据的安全和规范，而主数据则确保数据的准确性和一致性。通过以上通俗易懂的解释和生活中的例子，相信大家对数据中台、数据仓库、数据治理和主数据等概念有了更加清晰的认识。数据中台是企业数据的“中央厨房”，它负责整合来自各个业务部门、系统和渠道的数据，进行清洗、加工和标准化处理，然后提供给各个业务部门使用。就像中央厨房一样，数据中台确保了数据的质量、一致性和可用性，让数据能够更好地支持企业的决策和运营。
【Hadoop】-HDFS的存储原理[4]
weixin_63106307的博客
04-20 1357
HDFS的存储原理是将大文件切分成固定大小的数据块，并在集群中的不同节点上存储数据块的，以提高数据的可靠性和性能。同时，HDFS采用流式的数据读写方式，减少了寻址的开销，提高了数据的传输效率。
ELK日志系统的搭建
adminstate的博客
04-23 1019
ELK日志系统搭建
ElasticSearch 入门学习
灰熊
04-23 725
ElasticsSearch 是一个分布式的实时文档存储，每个字段可以被索引与搜索也是一个分布式实时分析搜索引擎也是一个能胜任上百个服务节点的扩展，并支持 PB 级别的结构化或者非结构化数据。
深入理解Java消息中间件-RabbitMQ
u011532237的博客
04-21 811
RabbitMQ是基于高级消息队列协议（AMQP）实现的一款开源消息代理软件，旨在提供高可用性、安全、互操作性强的企业消息系统。它由Erlang编写，因而继承了Erlang语言高并发、高可靠性的特点。
大数据——Zookeeper ZBA协议（四）
大数据爱好者的博客
04-20 878
对于分布式框架而言，基本上都会遵循CAP三大理论CAP(CAP理论是从客户端角度出发的！！！C(Consistency)：一致性。在一段时间内，访问这个集群获取到的数据是相同的。注意，此时，在一个时间段内，不要求每一台服务器的数据都一样，只要保证客户端获取到的数据一样就行A(Availability)：可用性。当客户端对集群中的节点发起请求的时候，节点能够在合理的时间内(一般理解为立刻)进行响应 - 时效性。注意，此处的可用性和服务器的高可用不是一回事儿！！！
大数据技术应用实训室解决方案
whwzzc的博客
04-22 1064
大数据实验实训课程体系的设计依据主要围绕培养目标、培养方案和课程体系建设三个方面来展开。大数据实验实训课程的设计旨在培养具备大数据理论知识和实践技能的专业人才。具体而言，这些人才应该能够熟练掌握大数据处理和分析的核心技术，具备独立设计和实施大数据应用的能力。同时，他们还应具备创新思维和团队协作精神，能够适应大数据行业的快速发展和变化。通过实训课程的训练，学生能够熟悉主流的大数据平台和工具，了解大数据应用的最新趋势和场景，为未来的职业发展打下坚实的基础。
架构师系列- 消息中间件（15）-kafka业务实战
最新发布
dengwei_dw的专栏
04-26 674
假设我们要传输一批订单到另一个系统，那么订单对应状态的演变是有顺序性要求的。已下单 → 已支付 → 已确认不允许错乱！Kafka Eagle监控系统是一款用来监控Kafka集群的工具，支持管理多个Kafka集群、管理Kafka主题（包含查看、删除、创建等）、消费者组合消费者实例监控、消息阻塞告警、Kafka集群健康状态查看等。
Rabbitmq消息应答，持久化，权重分配(7)
weixin_45751763的博客
04-24 787
Rabbitmq的消息应答，持久化，权重分配机制
实时数仓选型
qq_45972323的博客
04-22 244
ADS:不落盘，不存储。实质上时接口模块，查询ClickHouse的SQL语句（SQL查ClickHouse）
ibm数据仓库建模方法论
01-27
IBM数据仓库建模方法论（IBM Data Warehouse Modeling Methodology）是IBM为构建高质量的数据仓库而制定的一套建模方法与指导原则。其目标是帮助组织实现数据驱动决策和分析，从而提高业务效率和竞争力。 该方法论主要包括以下几个方面： 1. 需求分析：在开始建模之前，首先要深入了解业务需求和数据源。通过与利益相关者合作，明确数据需求、目标与范围，以及数据的重要性和可用性。 2. 数据模型设计：根据需求分析结果，设计合适的数据模型来存储和组织数据。这包括确定实体、属性、关系和约束等概念，并选择合适的建模工具和技术来解决特定问题。 3. 数据抽取与装载：将源系统中的数据抽取到数据仓库中。这涉及到数据清洗、转换和加载等步骤，以确保数据的准确性和一致性。 4. 数据仓库更新：持续监控和更新数据仓库中的数据，包括定期的数据抽取和转换过程，以保持数据的实时性和准确性。 5. 数据仓库查询与分析：提供灵活的查询和分析功能，以支持决策和业务需求。这包括使用各种BI工具和技术来提取、分析和可视化数据。 6. 数据质量管理：确保数据仓库中的数据质量高且可信。通过建立数据验证和监控机制，及时发现和纠正数据质量问题。 7. 数据安全与隐私保护：采取必要的安全措施，保护数据仓库中的数据不受未经授权的访问和泄漏。 通过遵循IBM数据仓库建模方法论，组织可以更好地管理和利用数据，提高数据仓库的效率和价值。同时，该方法论还提供了一套通用的指导原则和最佳实践，适用于各种规模和复杂度的数据仓库项目。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 14
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

范桂飓

文章对您有帮助就请一键三连：）

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值