从理论到实践：ByConity 在 ELT 中的实施与效果

2024-12-07
北京
本文字数：3709 字
阅读完需：约 12 分钟

前言：

相信绝大多数的公司都存在数据 BI 系统，是一种集成了数据仓库、在线分析处理（OLAP）、数据挖掘等技术，旨在为企业或组织提供决策支持的系统。随着云计算、大数据、人工智能等技术的不断发展，数据 BI 系统也将不断演进和完善，以更好地满足企业和组织的需求，今天给大家来推荐一个字节跳动公司推出的开源的云原生数据仓库 - 【ByConity】，如何满足公司大数据的业务需求。

一、什么是 ByConity?

ByConity 是新一代的开源的云原生数据仓库，它采用计算-存储分离的架构，在满足数仓用户对资源弹性扩缩容，读写分离，资源隔离，数据强一致性等多种需求的同时，并提供优异的查询、写入性能。ByConity 使用大量成熟 OLAP 技术，例如列存引擎，MPP 执行，智能查询优化，向量化执行，Codegen, indexing，数据压缩等。

二、ByConity 适用场景：

ByConity 可以满足企业用户的多种用户场景，例如交互式查询、实时数据看板和实时数据仓库。

交互式查询：这类场景下包括用户自定义查询、自助式报表、用户画像分析、营销效果分析和行为日志分析等应用场景。这些应用均支持自由维度和多表关联查询分析，并具有较快的响应速度。行为日志分析还支持数据量较大的日志探索分析。
实时数据看板：适用实时业务监控大屏、直播数据统计看板、业务仪表盘和系统链路监控等应用场景。所有应用均强调实时特性，部分支持统计功能。
实时数据仓库：包括实时数据接入和准实时 ETL 计算，强调实时数据写入和数据立即可见，同时支持复杂计算和数据清洗。
ELT 负载: 用户可以使用 bsp 模式进行批处理作业。作业将分阶段执行，并使用基于磁盘的 shuffle 操作交换数据。在此模式下，失败的 task 会自动被重试，增强任务的稳定性。

二、TPC-DS 测试：

首先为了方便测试，官方温馨提供了一台在线的 ByConity 服务器，配置也是比较高，如下为相关的配置环境参数说明：

当然，ByConity 也支持“多种云上快速部署”，详情可参考文档基于Kubernetes集群部署：

ByConity 支持模块化和容器化的部署，可以直接部署在 Kubernetes 集群上，并且利用 Kubernetes 的弹性伸缩能力进行扩缩容。
ByConity 不仅可以在火山云上部署，也可以在阿里云、AWS、腾讯云等多种云上部署。

1. 动手实验前的准备：

首先通过 SSH 方式进行登录，注意这里是 23 端口，登录进去可以看到是 Debian 的系统，但是没关系，跟平时使用的 centos 和 ubuntu 系统是差不多的。

接着使用“tmux new”命令创建一个新的会话。

ssh -p 23 ip地址tmux new -s user0010

复制代码

在新的窗口，执行“clickhouse client --port 9010”命令进入客户端，在左下角表示当前登录的 tmux 用户是谁？右边是机器服务器名字和时间。因为 ByConity 是基于 ClickHouse 进行优化和扩展，所以语法上基本上没有太多差异，基本没有什么学习成本。

clickhouse client --port 9010

复制代码

进入 ByConity 客户端后，可以看到版本是 21.8.7.1（请注意版本），再使用“use test_elt”命令进入当前使用测试用数据库 test_elt，这里的测试数据量有 1TB，由于 TPC-DS 定义的查询语法为标准 SQL，所以，需要设置数据库会话的方言类型为 ANSI。

use test_eltset dialect_type = ‘ANSI’

复制代码

在动手实验之前，先使用“top”命令来查看一下系统的负载，可以看到“clickhouse”进程占用也比较低，CPU 只有 1%，内存只有 2.5%。

上面的部署进行了一些动手评测的准备工作，主要说明了一下实验环境的版本及系统环境配置，当然，ByConity 也支持自己云部署，可以在官方上自行查看，本文采用的是连接在线的 ByConity 服务端进行 TPC-DS 的测试。

1. 测试 78 条语句：

在默认情况下，ByConity 是 MPP 模式的，在执行第 78 条 SQL 语句时，会发生“Memory limit (total) exceeded: Memory limit (total) exceeded”错误，需要 56.69GB 但是最大值限制值为 56.51GB，看执行过程的信息是执行了 2.19 亿条 rows，数据的处理能力还是挺强的。

→ Progress: 219.15 thousand rows, 586.05 KB (783.73 thousand rows/s., 2.10 MB/s.)  98%0 rows in set. Elapsed: 39.089 sec. Processed 219.15 thousand rows, 586.05 KB (5.61 thousand rows/s., 14.99 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 56.69 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.

复制代码

在窗口执行的过程中，使用“top”命令查看“clickhouse”进程可以看到 CPU 这里已飙升到 7.3%了，而内存还是 2.5%。

同时，我们也可以使用“show processlist”命令来查看一些详细的参数信息，以便于更为详细的分析问题点。

接下来手工来开启 bsp 模式，来尝试使用 work 为 4 的数量来执行，同样，执行相同的 SQL 语句，但是需要增加设置 bsp 语句，但是因为我们设置 work 是 4 数量，发现也是同样发生内存已经超过临界值。

为什么在 MPP 模式下处理的数据量是 2.19 亿，猜测在 bsp 模式在 work4 的时候处理数据的能力比 MPP 要小。而且处理的时间也比较长，是 126.949s，但是 MPP 模式下是 39.089s。

在窗口执行的过程中，使用“top”命令查看“clickhouse”进程可以看到 CPU 这里已飙升到 6.6%了，而内存还是 2.5%。

接下来通过接下来手工来开启 bsp 模式，来尝试使用 work 为 8 的数量来执行，同样，执行相同的 SQL 语句，但是需要增加设置 bsp 语句，但是因为我们设置 work 是 8 数量，可以发现查询出了结果，显然是，bsp 模式将任务进行了拆分，利用多个 task 来消费任务。

那么，我们使用 12 个 work 数量呢？可以看到使用 bsp 模式下 work 消费数量为 8 的时候，相对于 work 数量为 8 的时候，要更快一点，少了 7s 左右的时间，并且 rows 读取的能力也是高 2million rows/s，当遇到数据量很庞大的任务，可以拆分更多的 work 数量。

2. 并发压力运行测试语句 78：

上面只是单纯的同一个语句进行增加 work 数量进行测试，接下来，我们可以使用并发的场景来测试一下 bsp 模式在同时运行的效果。

首先我们开启 2 个 ByConity 模式控制台窗口，接下来，在第一窗口，使用测试语句 78，并且开启 bsp 模式，然后，work 设置为 24 进行执行。

接下来，在第二个窗口中，同样，使用测试语句 78，并且开启 bsp 模式，然后，work 设置为 12 进行执行，2 个窗口都是几乎差不多的时候执行语句，可以看到 CPU 达到 6%，内存达到 2.4%，然后，第一个因为开启了 work 是 24 个，所以在同一时间处理的任务多，只花费了 56.474s 就完成了，但是第二个窗口开启了 work 是 12 个，需要花费更多的时间来执行，使用了 79.102s 来执行。

可见，work 数目开的越高，任务执行的效果就越快，同理，我们执行三个窗口并发呢？再看看效果如何？

首先我们开启 3 个 ByConity 模式控制台窗口，接下来，在第一窗口，使用测试语句 78，并且开启 bsp 模式，然后，work 设置为 48 进行执行。

接下来，在第二个窗口中，同样，使用测试语句 78，并且开启 bsp 模式，然后，work 设置为 24 进行执行，2 个窗口都是几乎差不多的时候执行语句，可以看到 CPU 达到 9%，内存达到 2.5%，然后，第一个因为开启了 work 是 48 个，所以在同一时间处理的任务多，只花费了 63.074s 就完成了，但是第二个窗口开启了 work 是 24 个，需要花费更多的时间来执行，使用了 84.122s 来执行。

同时，在第三个窗口中，同样，使用测试语句 78，并且开启 bsp 模式，然后，work 设置为 12 进行执行，3 个窗口都是几乎差不多的时候执行语句，同样，因为第二个因为开启了 work 是 24 个，所以在同一时间处理的任务多，只花费了 84.122s 就完成了，但是第三个窗口开启了 work 是 12 个，需要花费更多的时间来执行，使用了 116.229s 来执行，差别看起来还是比较大的。