字节跳动开源云原生数据仓库 ByConity 有奖众测，邀你体验完整的数仓能力

在数据驱动时代，高效的数据处理和分析能力已经成为企业竞争力的关键。在实际业务中，用户会基于不同的产品分别构建实时数仓和离线数仓。其中，实时数仓强调数据能够快速入库，且在入库的第一时间就可以进行分析，低时延的返回分析结果。而离线数仓强调复杂任务能够稳定的执行完，需要更好的内存管理。

ByConity 是字节跳动开源的云原生数据仓库，可以满足用户的多种数据分析场景。2024 年 8 月，ByConity 增加了 bsp 模式：可以进行 task 级别的容错；更细粒度的调度；基于资源感知的调度。希望通过 bsp 能力，把数据加工（T）的过程转移到 ByConity 内部，能够一站式完成数据接入、加工和分析。

为了让更多的开发者深入了解并体验 ByConity bsp 模式的能力，InfoQ 和 ByConity 社区联合举办“ByConity 有奖众测活动”，邀请广大开发者参与 ByConity bsp 模式在离线数仓场景的实际测试，通过亲身实践来感受其带来的高效与便捷。

ByConity 有奖众测参与指南

活动时间

2024 年 12 月 2 日 - 2024 年 12 月 20 日

众测要求

本次众测活动共提供两种测试类型，以满足不同用户的需求。

标准测试

• 测试环境与数据集：社区提供测试环境与测试集，用户可以在提供好的环境中上手测试。

• 测试内容：使用小资源跑 TPC-DS 数据集，中间加上一些参数调整。

• 产出要求：产出对应测试文档并在 InfoQ 写作社区 + 掘金开发者社区发布。

 进阶测试

• 测试环境与数据集：用户使用自有环境 & 自有数据集进行测试。

• 测试内容：100G 以上数据，需要执行 10 分钟以上的查询，包含一个以上的 join 或 group by。

• 产出要求：产出对应测试文档并在 InfoQ 写作社区 + 掘金开发者社区发布。

参与方式

点击链接或者扫码海报报名二维码参与，参与标准测试开发者需完成测试并产出测试文章并发布，参与进阶测试开发者需在自有场景成功完成测试，能够胜任离线数仓的负载，并有对应测试文档产出并发布。

参与者可添加小助手进答疑群

参与奖品

标准测试：

• 完成测试，填写测试反馈，送社区 T 恤

• 发布测试文章，送其他社区精美礼品

  罗技（Logitech）蓝牙键盘（黑色 / 银色）

  ByConity 一周年纪念版 t 恤

  ByConity 双肩包

  抖音文创多功能三合一无线充电器

进阶测试：社区周边 + 进阶测试激励。

ELT 任务对系统的要求

• 整体易扩展：导入和转换通常需要大量的资源，系统需要通过水平扩展的方式来满足数据量的快速增长。

• 可靠性和容错能力：大量的 job 能有序调度；出现 task 偶然失败（OOM）、container 失败时，能够拉起重试；能处理一定的数据倾斜。

• 效率 & 性能：有效利用多核多机并发能力；数据快速导入；内存使用有效（内存管理）；CPU 优化（向量化、codegen）。

• 生态 & 可观测性：可对接多种工具；任务状态感知；任务进度感知；失败日志查询；有一定可视化能力。

ByConity 对 ELT 能力的优化

提升任务并行度，保障业务平稳运行

传统架构中，之所以要分别建设离线数仓和实时数仓，是因为常见的 OLAP 产品不擅长处理大量的复杂查询，很容易把内容打满任务中断，甚至造成宕机。

ByteHouse 具备 BSP 模式，支持将查询切分为不同的 stage，每个 stage 独立运行。在此基础上，stage 内的数据也可以进行切分，并行化不再受节点数量限制，理论上可以无限扩展，从而大幅度降低峰值内存。

任务级重试，减少重试成本

离线加工任务的另外一个特点就是链路比较长，并且任务间有依赖关系。如下图所示，

如上图所示，task4 依赖 task1、task2 的完成。如果 task1 失败发起重试，会显示为整个链路执行失败。ByteHouse 增加了任务级重试能力，在 ByteHouse 中只有运行失败的 task 需要重试。

大批量并行写入，稳且快

实时数仓存在频繁更新的特点，使用重叠窗口进行批量 ETL 操作时，会带来大量的数据更新。在这种场景下，ByteHouse 做了大量的优化。

写入优化示意图

经过持续优化，将最耗时的数据写入部分单独并行化，并且在写入 part 文件时标记是否需要进行后续的 dedup 作业。在所有数据写入完毕后，由 server 指定一个 worker 进行 dedup 和最后的事务提交（如上图最右）。

简化数据链路，提高健壮性

ByteHouse 在传统的 MPP 链路基础上增加了对复杂查询的支持，这使得 join 等操作可以有效地得到执行。在数据交换方面，要求所有 stage 之间的依赖必须在查询执行之前以网络连接的形式体现。离线加工场景下，这种方式有着天然的劣势：

• stage 较多、并行度较大时，每一个 task 出现的抖动都会影响整体链路，叠加的抖动增加任务失败的概率；

• task 同时拉起会进一步对资源进行挤占。

BSP 模式使用 barrier 将各个 stage 进行隔离，每个 stage 独立运行，stage 之内的 task 也相互独立。即便机器环境发生变化，对查询的影响被限定在 task 级别。且每个 task 运行完毕后会及时释放计算资源，对资源的使用更加充分。

在这个基础上，BSP 的这种设计更利于重试的设计。任务失败后，只需要重新拉起时读取它所依赖的任务的 shuffle 数据即可，而无需考虑任务状态。

期待开发者持续关注 ByConity，同 ByConity 一起开启开启数据仓库的新篇章。