数据处理不再是“脏活累活”，听听开发者们怎么说？_大数据_凌敏



 写点什么



大小：2.19M时长：12:45

一直以来，数据处理都被视作“脏活累活”，从数据的收集、清洗、转换，再到存储、分析，每个步骤都可能遇到各种挑战，繁琐且耗时。近几年，随着大数据和人工智能技术的进步，数据处理变得更加自动化和智能化，但在面对复杂查询和 ETL 任务时，还是存在扩缩容成本高、性能受限等局限性。

为了解决这些痛点问题，2024 年 8 月，字节跳动开源云原生数据仓库 ByConity 增加了 BSP 模式，这一模式允许进行 task 级别的容错、更细粒度的调度，并支持资源感知的调度。通过引入 BSP 模式，将数据加工（T）的过程转移到 ByConity 内部，让开发者能够一站式完成数据接入、加工和分析，将数据处理从“脏活累活”转变为更加高效和智能的工作。

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

本次众测活动历时近一个月，吸引了来自金融、教育、安全等众多行业的数十名开发者参与，通过多种测试工具和环境测试 ByConity 的核心功能，并记录测试过程和心得（全部测试文档链接详见文末）。

我们对这些测试文档进行了梳理，总体来看，开发者对 ByConity BSP 模式的能力十分认可，在实际体验中，BSP 能大幅提升数据处理效率与容错能力。有开发者表示“ByConity 的实时查询速度是真的快啊，5 亿数据复杂查询也仅需 60s，真的巨快，之前遇到的业务场景中 1 千万数据还超时了，适合大数据量场景用。”本次活动也收集到了不少来自开发者的改进建议，ByConity 社区将根据这些反馈持续优化产品功能，构建一个更加活跃的开源生态。

BSP 模式体验：大幅提升数据处理效率与容错能力

不少参与测试的开发者反馈，BSP 模式的引入对数据处理效率和容错能力的提升至关重要。

BSP 模式通过将查询任务分割成多个 stage，实现了并行化处理，极大地降低了峰值内存的使用，提高了查询效率。此外，如果在 query 运行中遇到错误时，可以自动重试当前的 task，而不是从头开始重试，大大减少了重试成本。当 query 需要的内存巨大时，可以通过增加并行度来减少单位时间内内存的占用，理论上可以实现无限扩展。

在分布式查询中，ByConity 通过 distributed_max_parallel_size 参数允许用户根据集群资源和查询需求调整表扫描的并行度，优化查询性能。合理调整该参数，用户可以在保证查询性能的同时，避免资源的过度消耗和查询失败的风险。

在 BSP 模式下，ByConity 支持对 TableScan 算子的并行度进行扩展，这有助于在资源有限的情况下处理大表。用户可以通过设置 distributed_max_parallel_size 参数来控制 TableScan 的并行度，实现资源平铺的功能。

完美句号：

ByConity 在 ClickHouse 高性能计算框架的基础上，增加了对 BSP 模式的支持，可以进行 task 级别的容错 ; 更细粒度的调度，支持资源感知的调度：

①. 当 query 运行中遇到错误时，可以自动重试当前的 task，而不是从头进行重试。大大减少重试成本。
②. 当 query 需要的内存巨大，甚至大于单机的内存时，可以通过增加并行度来减少单位时间内内存的占用。只需要调大并行度参数即可，理论上是可以无限扩展的。
③. 可以根据集群资源使用情况有序调度并发 ETL 任务，从而减少资源的挤占，避免频繁失败。
④. 对于大的数据量，BSP 通过把一个查询切换成 N 个 task，可以加快查询的效率。
⑤. 通过 BSP 模式的效果非常的明显，通过 BSP 能力，把数据加工（T）的过程转移到 ByConity 内部，能够一站式完成数据接入、加工和分析。
⑥. 可以在 ByConity 开启几个不同的 vw，比如：vw1 专门跑批量数据，vw2 实时查询，vw2 专门使用 mpp 模式，通过这样拆分任务的方式，将需要查询最快时间查出来。然后 vw1 把表 ODS 数据清洗，加工到 vw2 的 DWD 里，然后 vw2 直接查 DWD 的数据。

程伟：

1. BSP 模式更适合大数据量的计算，可以通过分解并行任务，降低单个任务的内存需求，能够有效保障任务执行的稳定性，更适合 ELT，数仓等长任务场景。

2. BSP 的任务并行度，并不是设置的越高越好，设置的太高，内存占用低，执行时间长。设置的太低，内存不足，无法完成计算，需要多次尝试获取最佳值。

3. MPP 模式相对 BSP 模式，可以读取更少的数据完成查询，在短时任务的运行上更具优势。通过排序键、分区、索引等手段可以进一步减少需要操作的数据量，达到更快的查询速度。

穿过生命散发芬芳：

ByConity 增加的 BSP（Bulk Synchronous Parallel）模式是一个重要的功能更新，旨在提升数据处理的效率和容错能力。distributed_max_parallel_size 参数用于控制分布式查询中表扫描的并行度。通过调整这个参数，用户可以根据集群的资源情况和查询的需求来优化查询性能。

ByConity 的 ELT 能力能够简化数据处理的复杂性，提高系统的响应速度和可靠性。通过将大部分转换操作留在分析阶段，ByConity 能够更好地适应复杂的数据处理需求，特别是在实时数仓和离线数仓的场景中表现出色。

阿泽：

在 BSP 模式下，ByConity 支持对 TableScan 算子的并行度进行扩展，这有助于在资源有限的情况下实现对大表的处理。用户可以通过设置 distributed_max_parallel_size 参数来控制 TableScan 的并行度，实现资源平铺的功能。

endlessclould：

传统架构中，之所以要分别建设离线数仓和实时数仓，是因为常见的 OLAP 产品不擅长处理大量的复杂查询，很容易把内容打满任务中断，甚至造成宕机。ByteHouse 具备 BSP 模式，支持将查询切分为不同的 stage，每个 stage 独立运行。在此基础上，stage 内的数据也可以进行切分，并行化不再受节点数量限制，理论上可以无限扩展，从而大幅度降低峰值内存。是一个使用非常良好的数据仓库，无论是上手难度还是查询速度。

六月的雨在 InfoQ：

ByteHouse 在传统的 MPP 链路基础上增加了对复杂查询的支持，这使得 join 等操作可以有效地得到执行。BSP 模式使用 barrier 将各个 stage 进行隔离，每个 stage 独立运行，stage 之内的 task 也相互独立。即便机器环境发生变化，对查询的影响被限定在 task 级别。且每个 task 运行完毕后会及时释放计算资源，对资源的使用更加充分。在这个基础上，BSP 的这种设计更利于重试的设计。任务失败后，只需要重新拉起时读取它所依赖的任务的 shuffle 数据即可，而无需考虑任务状态。

ByConity 还有哪些技术优势？

在体验 ByConity 的过程中，不少开发者感受到其显著的技术优势和广泛的适用性，对 ByConity 给予了充分肯定。具体来说，ByConity 的技术优势在于其云原生架构、实时数据分析能力、高效的查询引擎和分布式计算能力，以及强大的兼容性和运维自动化功能。这些技术优势使得 ByConity 在大规模实时数据分析的场景下展现出较强的竞争力。

此外，ByConity 多级资源隔离功能允许不同业务和场景按需创建 Virtual Warehouse，实现物理资源隔离和读写分离，同时确保数据读写的强一致性，保证数据的实时更新。这种设计不仅提升了数据处理的效率，也降低了使用成本，因为存储计算分离架构使得实时扩容成为可能，优化了资源的利用。

性能上，在复杂多子查询场景中，ByConity 能够灵活处理多来源数据，并行处理能力大幅增强。通过 Kubernetes 部署，ByConity 展示了良好的扩展能力和资源调度优化能力，适合多云和混合云场景。

百里丶落云：

对比 Spark 的使用场景，ByConity 支持多级资源隔离，不同业务、不同场景按需创建 Virtual Warehouse，实现物理资源隔离和读写分离，同时保证数据读写的强一致性，确保数据始终是最新的。这无疑是巨大提升，同时，因为存储计算分离架构的原因，可以实现实时扩容，这可以更好的利用资源，和降低使用成本。ByConity 的上手难度相对较低，ByConity 提供了详尽的官方文档，完备的社区可以支持用户快速的使用。整体上手难度偏低，是一个效率高，成本低，且资源隔离和弹性扩缩容都不错的数据仓库。

程序员海军：

总的来说，ByConity 的技术优势在于其云原生架构、实时数据分析能力、高效的查询引擎和分布式计算能力，以及强大的兼容性和运维自动化功能，尤其在面向大规模实时数据分析的场景下展现出较强的竞争力。

法医：

我之前用过 ClickHouse，通过这次测试想聊聊优缺点，ByConity 是基于 ClickHouse 内核研发的开源云原生数据仓库，采用存算分离的架构。它们两个写入速度都是非常快的，适用于大量数据的写入，其次查询速度非常快，在海量数据下，查询速度可达 2-30GB/s，另外数据压缩比高，存储成本低，压缩比可达 0.2～0.3。ByConity 具备 ClickHouse 的诸多优点，并且与 ClickHouse 保持着良好的兼容性。同时，ByConity 在读写分离、弹性扩缩容以及数据强一致等方面进行了显著增强。

我觉得 ByConity 是 ClickHouse 的增强版，ClickHouse 缺点也很明显，ClickHouse 扩容非常麻烦，而且扩容后需要从新进行数据分布。另外运维也很麻烦，尤其是高峰期的时候，又不能快速扩容，它一般通过删减其它业务数据才能得到缓冲，所以它查询就会变得很慢。

写在最后

虽然 ByConity 的 BSP 模式为数据处理带来效率上的飞跃，但目前仍有可优化的空间。本次众测活动收集到了不少来自开发者的改进建议，比如，开发者 RoSofteg 反馈，开启 BSP 和没开启 BSP 模式的时候，查询速度的波动一样而且都有一点不稳定；在分布式环境中，节点资源利用不均可能导致负载不平衡；如果缓存策略配置不合理，可能导致数据冗余或性能下降；自动故障恢复功能需要在复杂环境中进行广泛测试，避免因配置不当引发更多问题。针对这些问题，RoSofteg 也提供了一些改进建议：