ByConity查询性能问题排查与优化实践

问题背景

在使用ByConity替代原有ClickHouse集群的过程中，遇到了显著的查询性能差异问题。具体表现为：在ClickHouse集群中150亿数据的查询响应时间为200ms，而在ByConity集群中13亿数据的简单查询（如select a from x where b=x）响应时间却长达2-28秒不等，其中limit 100的简单查询也需要11秒。

环境配置

ByConity集群部署在10台物理机上，采用Kubernetes架构，底层存储先后尝试了OpenEBS Local PV+HDFS和MinIO方案。集群状态显示正常运行，无Pod重启情况。

初步排查

通过分析query_log和profile_events日志，发现以下几个关键现象：

1. 冷查询性能较差，HDFS读取时间较长
2. 即使是不涉及磁盘操作的简单查询（如select a from x limit 100）也需要11秒
3. 列是否为projection对性能影响不大

深入分析

1. 元数据操作瓶颈

通过执行特定诊断SQL，发现表存在大量小parts（约25万个），每个part仅包含约1万条数据。这是由于使用Kettle JDBC驱动批量导入时，每次仅导入1万条数据导致的。

select count() from cnch(server, system.cnch_parts) 
where database = 'xxx' and table = 'yyy'

2. 后台合并任务异常

进一步检查发现Daemon Manager(DM)服务未正常工作，导致后台merge任务无法执行。DM日志显示HDFS地址配置缺失的错误：

Failed to get HDFS connection: HDFS address is empty

3. 分区与TTL配置问题

表的分区策略(partition by toYYYYMM(begin_time))与TTL表达式(toStartOfMonth(ip_begin_time) + toIntervalMonth(12))不匹配，这会影响数据生命周期管理的有效性。

解决方案

1. 修复Daemon Manager配置

在byconity-dm-config的ConfigMap中，为daemon-manager.yaml添加HDFS地址配置：

hdfs_addr: hdfs://byconity-hdfs-namenodes:8020

重启DM Pod后，后台merge任务开始正常执行，逐步合并小parts。

2. 调整数据导入策略

建议调整批量导入的数据量，减少小parts的产生。对于JDBC导入，可以增大batch size至10万或更高。

3. 统一分区与TTL配置

将分区表达式调整为与TTL一致：

ALTER TABLE xxx.yyy 
MODIFY PARTITION BY toStartOfMonth(ip_begin_time)
TTL toStartOfMonth(ip_begin_time) + toIntervalMonth(12)

优化效果

实施上述措施后：

1. 后台merge任务成功合并小parts
2. 简单查询性能提升至毫秒级
3. 系统整体稳定性显著改善

经验总结

1. 小parts问题：大量小parts会严重影响查询性能，特别是在分布式系统中，元数据操作会成为瓶颈。
2. 后台服务监控：Daemon Manager等后台服务状态需要定期检查，确保合并、TTL等任务正常执行。
3. 配置一致性：存储地址等关键配置必须完整正确，否则会导致后台服务异常。
4. 设计规范：表的分区策略与TTL设置需要保持一致，遵循最佳实践。

通过这次问题排查，我们不仅解决了当前性能问题，也为后续ByConity集群的运维积累了宝贵经验。建议用户在迁移至ByConity时，特别注意数据导入策略和后台服务的配置检查。