目录

• 前言

• 关于 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、测试环境

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

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 并回车；

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

• 但是为了避免超时断开连接，建议运行 tmux new -s $user_id（比如 tmux new -s user00003）命令创建一个新的 tmux 会话；

• 执行 clickhouse client --port 9010 命令进入客户端。

（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

具体示例如下所示：

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

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

set dialect_type = 'ANSI'

具体示例如下所示：

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

SQL 列表见https://github.com/ByConity/byconity-tpcds/tree/main/sql/standard ，本文使用的是第 78 个 sql，具体操作如下所示：

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

（4）查询失败情况处理

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

SETTINGS bsp_mode = 1,distributed_max_parallel_size = 12;

具体示例如下所示：

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

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

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

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

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

具体示例如下所示：

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

（6）拓展

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

体验心得

通过本次测试很好的验证了 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 技术文档：https://byconity.github.io/zh-cn/docs/introduction/what-is-byconity

ByConity 介绍：https://byconity.github.io/zh-cn/