拜拜ClickHouse，Doris 最大单表有了新答案：不是534亿，而是534万亿！

❝下午，在Apache Doris社区群里，突然发了一篇文章： "Doris单表534万亿行数据，13PB存储，日导入158TB..." 有人看完私聊我说："吹牛的吧，我见过最大的表也就几千亿行。" 还有人调侃："哥们，你这是在数宇宙中的原子吗？" 我也愣住了。534万亿，这个数字到底有多大？ 举个栗子：地球上的沙粒大约有7.5×10^18颗，也就是750亿亿颗。534万亿，虽然只是地球沙粒数量的0.7%，但换个角度想想——这相当于把整个撒哈拉沙漠的沙粒都数一遍还要多。 每秒钟处理一条数据，534万亿条数据需要处理1695万年... 但，这就是浩瀚深度 x Doris 的真实案例！

多么痛的领悟

浩瀚深度是做什么的？国内互联网流量解析与数据智能化领域的领军企业。

好比全国的网络流量像瀑布一样汹涌而来，每天产生的上网日志数据量达到145TB，节假日峰值158TB。

这些数据需要实时采集、解析、存储、查询分析。

最开始，他们用的是ClickHouse。

用过ClickHouse的人都知道，这货单表查询速度挺快，压缩比也不错。

日子过得还算安稳，直到数据量越来越大。

ClickHouse开始"罢工"了。

写入经常出现"too many parts"错误，正如一个胃不好的人，吃多了就消化不良。

更要命的是，ClickHouse的JOIN能力太弱了。业务部门天天找技术部门："为什么这个关联查询跑了半天还没结果？"

技术负责人头都大了："兄弟，这不是我们的问题，是ClickHouse不支持大表JOIN啊！"

并且，在并发查询较多场景下，查询性能下降明显，无法支持业务需求，太痛了！

运维同事更是苦不堪言。

ClickHouse集群有台机器坏盘了，数据迁移全靠人工干预。半夜三更接到报警电话，爬起来手动处理，这日子没法过了。

Doris的惊艳登场

于是，技术选型重新开始。

现在ClickHouse和Doris，2个测试对比方案摆在桌上：模拟生产环境数据和业务对 Apache Doris 和 ClickHouse 做了一系列对比测试。

1. 前缀索引测试对比

2. 二级索引测试对比

3. 全表扫描测试对比

测试参数如下：

测试结果出来，所有人都惊呆了。

前缀索引查询，Doris速度是ClickHouse的2倍。

BloomFilter索引，Doris依然领先ClickHouse 2倍。

最夸张的是，相同场景下 Doris 的倒排索引功能，使得查询性能更是大幅跃升，速度远超 ClickHouse，是其性能的 5 倍以上。

"这不科学啊！"有同事质疑。

"我们再测一遍。"

结果还是一样。

不过全表扫描，两者性能接近。

但，除此之外。Doris天然支持 MySQL 语法，不仅查询快，运维还简单。机器坏了？自动副本切换。数据倾斜？自动负载均衡......

最后，"就是它了！"负责人三下五除二直接拍板。

534万亿背后的故事

从ClickHouse迁移到Doris的过程，还算顺利，但也遇到了一些坎坷👇

1. 30台接口机同时并发导入时，系统开始报错：

org.apache.doris.common.UserException: errCode = 2, detailMessage = get tableList write lock timeout, tableList=(Table [id=885211, name=td_home_dist, type=OLAP])
 
[INTERNAL_ERROR]cancelled: tablet error: tablet writer write failed, tablet_id=24484509, txn_id=3078341, err=[E-216]try migration lock failed, host: ***

找Doris社区求助，很快得到回复。调整参数配置，问题解决：参数调整参考文档：https://doris.apache.org/zh-CN/docs/observability/log

2. Compaction压力过载，BE节点假死：

排查发现是Bucket数量设置过高，从480调整为280，系统恢复正常。

3. 磁盘写满导致事务积压：

errCode = 2, detailMessage = current running txns on db 10194 is 10000, larger than limit 10000

经过Doris社区同学协助，一顿排查发现，事故起因是某台机器磁盘写满，加上写入压力较大，进而引发了事务积压。

此外，由于磁盘上仍残留部分 ClickHouse 数据，进一步加剧了磁盘空间分布不均的问题。

一个个技术难题被攻克（详见🔗原文链接）...

最关键的优化是使用Broker Load。

原来需要32台接口机从HDFS拉取数据，现在Doris直接从HDFS读取，只需要23台机器。

最终，整体硬件成本节超 28%。单 SQL 查询响应速度提升近 2 倍。批量查询任务执行效率提升近 30%。

运维复杂度大幅降低，技术同事终于可以好好睡觉了。

至此，这套系统已在全国范围内十余个生产环境中稳步运行。日均145TB的数据导入，像一条数据的大河，源源不断地流入Doris这个超级DB！

结语

技术圈有句话："Talk is cheap, show me the code."

浩瀚深度 x Doris的534万亿行数据，此时，就是最好的code。

数据的海洋无边无际，而我们正在用技术搭建更大的船。