ByConity ELT 测试——体验 BSP 模式带来的高效数据处理
前言
在实际业务场景中,实时数仓和离线数仓的构建对于满足用户多样化的数据分析需求至关重要。实时数仓注重数据的快速入库与即时分析,而离线数仓则强调复杂任务的稳定执行与高效的内存管理。ByConity 作为一款开源云原生数据仓库
,不仅支持多种数据分析场景,还引入了BSP(Batch Service Processing)模式
,旨在通过更细粒度的调度和资源感知的调度策略,将数据加工过程无缝集成到 ByConity 内部,实现一站式数据接入、加工和分析。
测试环境
测试步骤
登录 ESC
MacOS / Linux
MacOS / Linux 可以通过 Shell(终端)应用来完成 SSH 连接远程服务器。
打开终端,输入ssh -p 23 <用户名>@<ECS服务器IP地址>
,并回车确认。
如果系统提示你输入 yes 或者 no 来确认是否连接,输入yes
并回车。
然后输入<登录密码>
并回车。
为避免使用时超时自动断开连接,运行tmux new -s $user_id
命令创建一个新的 tmux 会话,其中$user_id
是可以自定义的会话名称。(后续重新登录时,使用 tmux a -t $user_id
)。例如:
执行 clickhouse client --port 9010
命令进入客户端。如果后续输入 SQL 会被截断,在此处可以执行clickhouse client --port 9010 -mn
,此后 SQL 后需要加;
作为结束。
Windows
Windows 系统在本地主机打开开始
,打开命令提示符
终端,输入ssh -p 23 <用户名>@<ECS服务器IP地址>
,并回车确认。如果系统提示你输入 yes 或者 no 来确认是否连接,输入yes
并回车。然后输入<登录密码>
并回车。
如果连接失败,可以使用开源软件 PuTTY 进行连接操作。
执行查询
连接数据库
使用测试用数据库 test_elt
接下来看看库表
设置方言类型
由于 TPC-DS 定义的查询语法为标准 SQL,设置数据库会话的方言类型为 ANSI
。
查看数据量
查询操作
选择 q78 进行查询操作,代码如下。
Progress: 219.15 thousand rows, 577.28 KB (838.64 thousand rows/s., 2.21 MB/s.) 98%0 rows in set. Elapsed: 29.363 sec. Processed 219.15 thousand rows, 577.28 KB (7.46 thousand rows/s., 19.66 KB/s.)Received exception from server (version 21.8.7):Code: 241. DB::Exception: Received from localhost:9010. DB::Exception: Code: 241, e.displayText() = DB::Exception: Worker host:10.0.0.14:8124, exception:Code: 241, e.displayText() = DB::Exception: Memory limit (total) exceeded: would use 60.79 GiB (attempt to allocate chunk of 0 bytes), maximum: 56.51 GiB: While executing AggregatingTransform SQLSTATE: 53000 (version 21.8.7.1) SQLSTATE: 53000 (version 21.8.7.1) SQLSTATE: 53000.
这段返回值表明查询执行失败了,主要原因是内存超限。
Progress: 219.15 thousand rows, 577.28 KB (838.64 thousand rows/s., 2.21 MB/s.) 98%
这行显示查询进度:已处理 219.15 千行数据,数据量为 577.28 KB,处理速度为每秒 838.64 千行,已完成 98%
Memory limit (total) exceeded: would use 60.79 GiB (attempt to allocate chunk of 0 bytes), maximum: 56.51 GiB
这行是错误信息的关键部分,表明查询需要使用 60.79 GB 内存,但系统限制最大只能使用 56.51 GB,因此内存不足导致查询失败。
distributed_max_parallel_size
查询失败后,在失败的 SQL 最后加上设置后再次执行:
其中参数distributed_max_parallel_size
可以设置为 4 的其他整数倍(因为 Worker 的数量为 4)。添加参数后执行成功
。
触发 OOM
OOM
(Out Of Memory) 是当进程申请的虚拟内存空间超过系统限制或物理内存+交换空间的总量时触发的错误。在 Linux 系统中,OOM Killer
会被触发来终止某些进程以释放内存。
==触发 OOM 的常见原因:==
查询处理的数据量太大
内存限制设置太小
复杂的计算或排序操作
多表关联产生大量中间结果
查询 q64,代码如下:
查询成功。
在执行成功的查询中,添加参数限制查询的最大内存使用量,如:
单位为 B,当前约合 37.25 GB。将内存限制为合适的值,引发 oom。随后执行distributed_max_parallel_size
,完成查询。内存不宜限制的过小,可以先用 40000000000 做第一次尝试,如果依然顺利执行,可依次将内存调整为上一次的 70%。
如下,成功触发 OOM。
在代码后添加 SETTINGS bsp_mode = 1,distributed_max_parallel_size = 12;
测试反馈
ByConity 引入的 BSP(Bulk Synchronous Parallel)模式是一项关键的功能升级,distributed_max_parallel_size
参数负责调控分布式查询中表扫描的并行级别。用户可根据集群资源状况和查询的具体需求,灵活调整此参数以优化查询性能。max_memory_usage
参数则用于设定单个查询在执行期间所能使用的最大内存量。通过合理配置该参数,能有效防止单个查询过度占用内存资源,确保系统稳定性,避免对其他查询造成干扰。通过合理调整distributed_max_parallel_size
和max_memory_usage
的值,用户可以在保证查询性能的同时,避免资源过度消耗和查询失败的风险,从而实现资源的优化配置和系统的稳定运行。
在实际操作中,想要找到一个既能充分利用资源,又能避免 OOM 并维持 BSP 模式稳定运行的参数配置并不容易。建议系统能够具备自适应的能力,根据查询的资源需求和集群的当前状态,智能地推荐 BSP 模式的开启与否,并给出合理的并行度设置建议。
版权声明: 本文为 InfoQ 作者【颜颜yan_】的原创文章。
原文链接:【http://xie.infoq.cn/article/628aaa30ee915930d815133e9】。文章转载请联系作者。
评论