ByConity ELT 测试体验
在实际业务中,用户会基于不同的产品分别构建实时数仓和离线数仓。其中,实时数仓强调数据能够快速入库,且在入库的第一时间就可以进行分析,低时延的返回分析结果。而离线数仓强调复杂任务能够稳定的执行完,需要更好的内存管理。
ByConity 是一款开源云原生数据仓库,可以满足用户的多种数据分析场景。
ByConity 增加了 bsp 模式:可以进行 task 级别的容错;更细粒度的调度;基于资源感知的调度。希望通过 bsp 能力,把数据加工(T)的过程转移到 ByConity 内部,能够一站式完成数据接入、加工和分析。
一、测试环境
二、登录环境
1、命令行登录 ECS
MacOS / Linux 可以通过 Shell(终端)应用来完成 SSH 连接远程服务器。打开终端,输入ssh -p 23 <提供的用户名>@<ECS服务器IP地址>
,并回车确认。
Windows10 以上可以使用自带 cmd 命令行来登录。也可以用最新版本的 putty。
2、为避免使用时超时自动断开连接,请运行tmux new -s $user_id
(如 tmux new -s user0001
)命令创建一个新的 tmux 会话,其中$user_id
是可以自定义的会话名称。
3、执行 clickhouse client --port 9010
命令进入客户端。
三、执行查询
1、使用测试用数据库 test_elt:
use test_elt
2、由于 TPC-DS 定义的查询语法为标准 SQL,设置数据库会话的方言类型为 ANSI:
set dialect_type = 'ANSI'
3、选择 TPC-DS 的 99 个查询中你希望的执行,SQL 列表见 https://github.com/ByConity/ByConity/tree/master/tests/optimizers/tpcds/queries。其中部分查询会因为内存限制而执行失败,常见会执行失败的查询为:q78,请优先选择 q78 以便执行步骤 4。
4、查询失败后,在失败的 SQL 最后加上设置后再次执行:
SETTINGS
bsp_mode = 1,
distributed_max_parallel_size = 12;
其中参数distributed_max_parallel_size
可以设置为 4 的其他整数倍(因为 Worker 的数量为 4)。注意要把 limit 100 后的分号去掉。
添加参数后执行成功。
5、选择 Q67 查询进行执行,在执行成功的查询中,添加参数限制查询的最大内存使用量,如:
SETTINGS
max_memory_usage=40000000000;
(单位为 B,当前约合 37.25 GB)
将内存限制为合适的值,引发 oom。随后执行步骤 4,完成查询。
四、测试反馈
ByConity 增加的 BSP(Bulk Synchronous Parallel)模式是一个重要的功能更新,旨在提升数据处理的效率和容错能力。
distributed_max_parallel_size
参数用于控制分布式查询中表扫描的并行度。通过调整这个参数,用户可以根据集群的资源情况和查询的需求来优化查询性能。max_memory_usage
参数用于限制单个查询在执行过程中可以使用的最大内存量。通过设置这个参数,可以防止单个查询占用过多内存资源,影响其他查询的执行和系统的稳定性。
通过合理调整distributed_max_parallel_size
和max_memory_usage
的值,用户可以在保证查询性能的同时,避免资源过度消耗和查询失败的风险。
ByConity 的 ELT 能力能够简化数据处理的复杂性,提高系统的响应速度和可靠性。通过将大部分转换操作留在分析阶段,ByConity 能够更好地适应复杂的数据处理需求,特别是在实时数仓和离线数仓的场景中表现出色。
版权声明: 本文为 InfoQ 作者【穿过生命散发芬芳】的原创文章。
原文链接:【http://xie.infoq.cn/article/722e372c0bfd12970dadd5fc5】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论