ByConity实战指南：ELT测试深度解析

三掌柜
176 阅读8分钟

目录

  • 前言
  • 关于ByConity
  • ELT测试准备
  • 具体ELT测试步骤
  • 体验心得
  • 结束语
  • 参考文献

前言

在大数据时代，数据仓库作为企业数据管理和分析的核心，扮演着至关重要的角色，尤其是实时数仓和离线数仓的构建对于数据分析至关重要。而ByConity作为一款开源云原生数据仓库，以其强大的数据处理能力和灵活的扩展性，满足了实时数仓和离线数仓的多样化需求，支持多种数据分析场景。那么本文就来详细分享一下如何使用ByConity进行ELT测试，通过实际操作体验ByConity在数据接入、加工和分析方面的强大能力，方便后期学习和使用。

关于ByConity

先来了解一下ByConity，其实ByConity是一款开源云原生数据仓库，它支持多种数据分析场景，由字节跳动主导，并以 Apache License 2.0 的形式开源，赋能开发者与企业，而且它也有一些自带的特点，具体如下所示：

  • 实时数仓：快速数据入库和即时分析能力，低时延返回分析结果。
  • 离线数仓：强调复杂任务的稳定执行和更好的内存管理。
  • BSP模式：提供task级别的容错、细粒度调度和基于资源感知的调度。

ELT测试准备

为了能够上手感受 bsp 模式带来的效果，下面会提供使用 TPC-DS 1TB 的数据测试，而且接下来会按照下面的步骤进行测试，验证 ByConity 在 ELT 方面的实际感受。 另外需要说明的是本次测试将在火山引擎 ECS 上，需要通过 SSH 等工具连接集群，并完成基于 TPC-DS 标准数据集的数据查询等操作，具体操作步骤如下所示。

1、测试环境

现在介绍一下需要的测试环境要求，具体如下所示：

0

2、环境准备

由于完整的测试需要下面三点的环境准备工作，但是本次测试是已经有对应的测试环境准备，所以这一步可以忽略，为了方便大家学习了解，这里还是分享一下（本文直接跳过该操作步骤），具体如下所示：

  1. 火山引擎ECS：确保已在火山引擎上创建ECS实例。
  2. SSH工具：用于连接集群。
  3. TPC-DS数据集：准备1TB的TPC-DS标准数据集。

3、前提条件

在开始测试之前，需要有以下登录ECS的凭据：

  • ECS服务器IP地址；
  • 用于登录的用户名和密码。

具体ELT测试步骤

那么接下来就是本文的重点部分，来分析具体的ELT测试步骤，具体如下所示。

1、登录ECS

上面在准备工作的时候也介绍到登陆ESC需要的凭证信息，我们可以通过SSH连接到ECS服务器，但是考虑到大家不同的操作系统，这里分享一下在不同操作系统下的连接方法。

（1）MacOS / Linux

先来介绍关于MacOS / Linux系统下的连接方法，需要说明的是本文的测试环境使用的是MacOS系统，所以操作步骤也是按照该系统下的操作示例来演示，其他系统的操作步骤这里不在演示，具体如下所示：

  • 打开终端，输入ssh -p 23 <提供的用户名>@，并回车确认；
  • 如果系统提示确认是否连接，输入yes并回车；

0

  • 输入提供的登录密码并回车；

0

  • 但是为了避免超时断开连接，建议运行tmux new -s $user_id（比如tmux new -s user00003）命令创建一个新的tmux会话；
  • 执行clickhouse client --port 9010命令进入客户端。

0

（2）Windows

在来介绍关于Windows系统下的连接方法，具体如下所示：

  • 打开“开始”，搜索并打开“命令提示符”终端。
  • 输入ssh -p 23 <提供的用户名>@，并回车确认。
  • 如果系统提示确认是否连接，输入yes并回车。
  • 输入提供的登录密码并回车。
  • 依然为了避免超时断开连接，建议运行tmux new -s $user_id（如tmux new -s user00003）命令创建一个新的tmux会话。
  • 执行clickhouse client --port 9010命令进入客户端。

2、核心操作流程

（1）数据导入

  1. 配置数据源：在ByConity中配置数据源，指向TPC-DS数据集所在位置。
  2. 执行导入任务：使用ByConity的导入功能，将数据从数据源导入到ByConity中。

（2）数据加工

  1. 编写加工逻辑：根据业务需求编写SQL或使用ByConity提供的ETL工具进行数据加工。
  2. 执行加工任务：运行加工逻辑，对数据进行清洗、转换和聚合。

（3）数据分析

  1. 编写分析查询：根据分析需求编写SQL查询。
  2. 执行分析任务：在ByConity中执行查询，获取分析结果。

（4）结果验证

  1. 验证数据准确性：检查加工后的数据是否符合预期。
  2. 验证性能表现：评估ByConity在处理大规模数据集时的性能表现。

3、执行查询操作

（1）使用测试数据库 test_elt

首先使用测试数据库 test_elt，具体操作如下所示：

use test_elt

具体示例如下所示：

0

（2）设置数据库会话的方言类型为ANSI

由于TPC-DS定义的查询语法为标准 SQL，设置数据库会话的方言类型为 ANSI，具体操作如下所示：

set dialect_type = 'ANSI'

具体示例如下所示：

0

（3）选择TPC-DS的查询进行执行

SQL列表见github.com/ByConity/by… ，本文使用的是第78个sql，具体操作如下所示：

0

然后查询失败，具体如下所示：

0

（4）查询失败情况处理

查询失败后，在失败的 SQL 最后加上设置后再次执行，具体如下所示：

SETTINGS bsp_mode = 1,distributed_max_parallel_size = 12;

具体示例如下所示：

0

然后添加上面三句语句执行，具体如下所示：

0

然后就可以查询成功了，具体示例如下所示：

0

（5）选择复杂查询场景进行执行

然后再选择其他较为复杂的查询进行执行，并在执行成功的查询中，添加参数限制查询的最大内存使用量，如下所示：

SETTINGSmax_memory_usage=40000000000;（单位为 B，当前约合 37.25 GB）

具体示例如下所示：

0

上图中将内存限制为合适的值，引发 oom。随后执行步骤（4），就可以完成查询。需要说明的是内存不宜限制的过小，可以先用 40000000000 做第一次尝试，如果依然顺利执行，可依次将内存调整为上一次的70%。

（6）拓展

如果大家还想希望了解具体查询的含义，可以将SQL复制到大模型产品中让其进行解释，帮助大家更好地理解查询对应的实际场景。这里以官方的示例案例来分享，具体如下所示：

0

体验心得

通过本次测试很好的验证了 ByConity 集群在处理 TPC-DS 1TB 数据集时的性能表现，尤其是在执行复杂查询时，内存限制和并行计算设置是优化查询性能的关键。还有就是通过合适的 SQL 设置、内存管理和资源调度，能够确保在大数据量下依然保持较高的查询效率。

但是本次测试也遇到了一点点问题，具体问题点如下所示：

问题1： 操作文档中提供的sql，会有换行的问题，复制执行不能执行，另外如果整段文档数据复制执行，注释也会被复制进去，造成执行失败

问题2： bsp 模式虽然很方便，但是在执行失败的时候还是有一定的问题，比如查询速度会有波动

另外在实际操作中，可以通过下面的方式进一步提升性能，具体如下所示：

  • 使用内存限制：通过查询数据量设置合理的 max_memory_usage，避免内存溢出。
  • 调整并行执行任务数：通过服务器资源和查询复杂度灵活调整 distributed_max_parallel_size。
  • 优化查询计划：根据常见查询使用物化视图或缓存查询结果，减少重复计算。

最后不得不说ByConity 增加的 BSP模式是一个重要的功能更新，非常好用，非常适合实战场景。

结束语

通过本次ELT测试演示分享，想必大家都感受到笔者体验ByConity在数据处理和分析方面的强大能力。特别是ByConity的BSP模式为用户提供了更高效、更稳定的数据处理解决方案，尤其适用于需要大规模数据处理和实时分析的场景。在这里我想要呼吁大家积极通过上文的实际操作，来深入了解ByConity的特性和优势，并将其应用于实际业务中，以提高数据处理效率和分析能力。随着技术的不断发展，ByConity肯定会继续优化和升级，为用户提供更加丰富和强大的数据仓库解决方案，也让我们期待ByConity在后面带来的新的能力。

参考文献

ByConity 技术文档：byconity.github.io/zh-cn/docs/… ByConity介绍：byconity.github.io/zh-cn/

avatar
文章
阅读
粉丝