浩瀚深度（[SHA: 688292]）旗下企业级大数据平台选择 Apache Doris 作为核心数据库解决方案，目前已在全国范围内十余个生产环境中稳步运行，其中最大规模集群部署于 117 个高性能服务器节点，单表原始数据量超 13PB，行数突破 534 万亿，日均导入数据约 145TB，节假日峰值达 158TB，是目前已知国内最大单表。凭借 Apache Doris 的高可靠、高性能与高可扩展能力，该集群已持续稳定运行半年以上，充分验证了其在超大规模数据场景下的卓越表现。
浩瀚深度作为国内互联网流量解析与数据智能化领域的领军企业，深耕行业三十余载，持续为国内互联网提供高性能、高精度、高可靠的整体解决方案。公司业务覆盖网络可视化、AI 智能、数据治理、数据价值挖掘及安全防护，是一家集软硬件产品研发、生产、销售和服务于一体的大型高科技企业。
顺水云大数据平台（StreamCloud）作为浩瀚深度自主研发的企业级的大数据平台产品，涵盖了从数据采集、数据存储、数据处理、数据挖掘、数据治理到数据共享的完整数据开发流程。帮助企业客户快速构建 PB 级数据中台，目前已经在通信、金融、交通等领域落地部署 100+ 项目，管理超过 130PB 数据，集群节点规模近万个。
为满足客户每日写入及查询万亿级增量数据的严苛需求，顺水云对 MPP 数据库产品进行了多轮选型测试，并在实际生产环境中尝试过 Greenplum、ClickHouse 等多个方案。经过综合比对，最终选定 Apache Doris 作为核心数据库解决方案。目前，该方案已在全国十余个生产环境上线运行，其中规模最大的集群部署于 117 个高性能服务器节点之上，单表原始数据量超 13PB，行数突破 534 万亿，日均导入数据量约 145TB ，节假日峰值数据量约 158TB，且已持续稳定运行半年以上。
早期架构以及痛点
早期架构如图所示，数据主要来源为用户上网日志，数据经过采集设备解析还原后发送到接口机上，再由接口机上程序接入 HDFS 集群，基于 Apache Spark 将不同类型话单经过加工、回填、合成等流程处理后生成结果数据，最终写入至 ClickHouse 中，用于日志存储与快速查询、流量质量分析、面向政企市场的用户画像 & 精准营销等场景。
随着业务数据体量逐渐庞大，对于高吞吐的数据写入、亿级数据的秒级响应、海量数据关联查询的需求也愈加迫切，以 ClickHouse 为核心的 OLAP 查询分析引擎体系在使用过程中对业务人员开发、运维人员维护存在如下痛点：
- 写入稳定性差且存储成本较高：为降低存储成本，我们尝试使用 ZSTD 压缩格式，但因其高压缩比带来的性能开销，频繁出现“too many parts”及当日数据入库积压问题。为保障业务稳定运行，只能增加存储成本使用默认的 LZ4 压缩；
- 运维成本高：使用自研的数据入库工具，由于不同接口机上数据量和导入性能差异，导致 ClickHouse 集群上各节点数据量不均衡，由于 ClickHouse 架构特性，坏盘时数据无法自动迁移，需要人工持续干预；
- 并发查询能力不足：在并发查询较多场景下，查询性能下降明显，无法支持业务需求；
- JOIN 能力不足：由于 ClickHouse 自身组件设计无法支持多表或大表 Join 查询场景，难以满足大表关联查询需求。
Apache Doris vs. ClickHouse 对比测试
测试准备
为了进一步对比验证 Doris 的写入和查询性能，我们使用了三台物理机模拟生产环境数据和业务对 Apache Doris 和 ClickHouse 做了一系列对比测试。主要分为以下 3 部分：
- 前缀索引测试对比
查看前缀索引文档详情
- 二级索引测试对比
查看 BloomFilter Index 文档详情
查看 Inverted Index 文档详情
全表扫描测试对比
测试参数：
建表：
Doris 自 2.0.0 版本支持倒排索引能力，因此我们在表的数据量和字段一致的背景下，针对不同的排序键与索引类型进行查询速度测试：
测试一：前缀索引
前缀索引可以加速等值查询和范围查询。在 Doris 中，建表时自动取表的 Key 的前 36 个字节作为前缀索引。前缀索引测试分为 3 次冷查询，测试结果如下：
测试二：二级索引
- BloomFilter Index 是基于 BloomFilter 的一种跳数索引，其原理是利用 BloomFilter 跳过等值查询指定条件不满足的数据块，达到减少 I/O 查询加速的目的。
- Inverted Index 可以用来进行文本类型的全文检索、普通数值日期类型的等值范围查询，快速从海量数据中过滤出满足条件的行。
二级索引分别对比测试了 Doris 的 BloomFilter Index 和 Inverted Index ，测试分为 3 次冷查询，测试结果如下：
测试三：全表扫描
全表扫描测试主要是测试了常用业务查询场景：like 模糊查询和 IP 函数，根据测试结果， IS_IP_ADDRESS_IN_RANGE 函数查询方面 ClickHouse 略胜。
结果分析
在合理配置索引的前提下，Doris 在关键查询场景下展现出显著性能优势：
- 前缀索引： Doris 查询速度是 ClickHouse 的 2 倍以上。
- 二级索引：
- 使用 BloomFilter 索引时，Doris 查询速度领先 ClickHouse 达 2 倍。
- 相同场景下 Doris 的倒排索引功能，使得查询性能更是大幅跃升，速度远超 ClickHouse，是其性能的 5 倍以上。
- 全表扫描： 两者性能接近，ClickHouse 在特定函数调用上略占优势。
综合来看，两者各有所长，但测试表明：在常用业务查询场景中，Doris 的前缀索引、BloomFilter 和倒排索引性能全面优于 ClickHouse。据此评估，迁移至 Doris 后，查询响应速度预计提升超 2 倍。
Doris 替换实践
由于 ClickHouse 和 Doris 均为 MPP 架构数据库，且 Doris 支持 MySQL 语法，因此架构变化小、迁移便捷。仅需将日志存储与分析引擎由 ClickHouse 替换为 Doris，具体步骤如下：
- 调整上游 Importer 写入组件的配置，使其将日志数据直接写入 Doris 表；
- 更新下游查询服务的 SQL 语句以适配 Doris 语法即可完成无缝迁移。
虽然我们对 Doris 做了几 TB 的数据测试做使用参考，但考虑生产环境日增数百 TB 的数据量级，再加上引入新组件的不确定性，实施初期我们采用了 ClickHouse 和 Doris 并行运行的方式。
同时在压测期间也遇到一些问题，目前均已解决，我们将这些问题的解决思路整理并分享至社区，以供参考。
实践一：解决大批量写入报错问题
在进行导入压力测试阶段，小数据量下，集群运行状况和导入性能均表现良好。但是在逐渐上升至 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: ***
在出现异常情况后，我们及时和社区同学联系沟通，参考官方文档中的《日志存储和分析》模块的参数进行调优后，导入任务恢复正常。
实践二：Compaction 压力过载优化
进一步压测，我们发现在导入持续一段时间后，BE 节点在监控中出现异常。结合监控以及 top -H 的输出，发现 Compaction 占用 CPU 资源比较多，导致 BE 出现假死。经过 Compaction 问题排查，发现与 Bucket 数量有关。
由于当时按照 ClickHouse 自动合并后单个分区下文件数量的最大值来设置， Bucket 数量我们设为了 480，导致 Tablet 过多而引发问题。
后来结合实际业务场景，以及业务高峰期数据量等因素进行了计算后，将 Bucket 缩减为 280 ，调整后 Compaction 资源占用恢复正常 ，BE 节点恢复平稳运行。
实践三：导入异常问题排查
在压测期间导入出现一个事物卡住的情况，异常如下：
errCode = 2, detailMessage = current running txns on db 10194 is 10000, larger than limit 10000
根据报错内容引导处理，我们调整了单个 DB 下的事务数量，发现不是根本原因。随后，我们将问题反馈给社区同学，在他们的协助下，很快定位到了问题根源。具体定位步骤如下：
- 找到一个具体的事务 ID
登录 FE 的主节点，搜索事务对应的具体 BE
grep "16788479" /opt/install/doris-2.15/fe/log/fe.log
登录到具体 BE，在日志中搜索该事务 ID
grep "16788479" /opt/install/doris-2.15/be/be.INFO
排查发现，事故起因是某台机器磁盘写满，导致集群开始将该节点的写入和副本调度至其他节点，而当前写入压力较大，进而引发了事务积压。此外，由于磁盘上仍残留部分 ClickHouse 数据，进一步加剧了磁盘空间分布不均的问题。
实践四：使用 Broker Load 解放接口机
由于 Doris 中的导入功能非常丰富，几乎在每个场景都有对应的导入，刚开始我们使用的是 Stream Load 导入本地数据文件，在进一步学习了解使用 Doris 后，发现 Broker Load 的导入方式更契合业务场景，因为系统加工合成的数据本身就存储在 HDFS 上，Broker Load 可以直接从 HDFS 上拉取数据，相比较之前从 HDFS 下载数据到本地再进行导入方式，这样不仅能减少一次数据传输，还解放了数据导入使用的接口机，进一步提高了效率。我们需要做的就是申请 Doris 集群和 HDFS 集群的网络打通和 Broker 的部署，并编写一套检测数据并提交 Broker Load 的脚本。
经测试，目前已经上线上百台的 Broker 节点去进行并行拉取 HDFS 的数据并进行导入，写入性能优异。但使用 Broker Load 时要注意按照业务场景进行调整，如果默认子任务失败则会导致整个目录的文件导入全部失败。HDFS 中数据以 15 分钟粒度为目录存储的，需要做好相应的失败检测与重试机制。
在机器成本方面，相较于使用 ClickHouse 导入一天数据需要 32 台接口机，改用 Doris 后，省去了从 HDFS 拉取数据的机器，仅需 23 台即可完成同等数据量的导入，机器资源节省超过 28%，显著降低了成本并提效。
架构升级成果
目前，浩瀚深度已在某运营商客户环境使用 Doris 替换 ClickHouse 构建了新的查询分析平台，服务器规模超百台，并实现日增数据量峰值近 158TB 的数据导入。采用双副本 + 倒排索引 + ZSTD 压缩后，存储量约 6.5PB，和原始数据相比，Doris 中单个副本的压缩率在 4 倍左右，且目前已稳定运行半年多，这次升级带来查询响应、并发能力、稳定性和运维效率等多方面的收益，成果显著。
- 显著降低硬件资源成本：利用 Doris Broker Load 高效导入机制，释放原 ClickHouse 所需的 32 台专用接口机，这些资源可灵活用于计算或存储，整体硬件成本节超 28%。采用 ZSTD 高压缩比格式，在未出现写入瓶颈的前提下，存储资源消耗相较 ClickHouse（LZ4 压缩）降低了 6%。
- 大幅提升查询效率：Doris 卓越的索引优化（前缀索引、Bloom Filter、倒排索引）及多表 JOIN 性能全面超越 ClickHouse。单 SQL 查询响应速度提升近 2 倍。批量查询任务执行效率提升近 30%。
- 有效降低运维复杂度与成本：服务器宕机或坏盘时，Doris 自动完成副本切换与写入重定向，保障服务连续性。集群扩缩容时，Doris 自动实现 Tablet 均衡分布，快速恢复集群负载均衡。通过 Doris 原生 Web UI 与 Grafana 监控，异常节点与磁盘故障可被快速定位。
未来规划
未来，浩瀚深度将从以下方面重点发展：
- 持续深化Doris 的湖仓一体化应用：通过 Doris 的 Hive Catalog 功能整合数据仓库资源，统一数据访问接口，实现对全量数据的统一查询与分析；
- 复杂查询加速：在多维度分析、聚合计算等复杂查询场景下，依托 Doris 强大的整合能力提升查询效率，加速报表生成；
- 成本优化：利用 Doris 的冷热数据分层存储等特性，在持续优化查询性能的同时，进一步降低总体存储成本。
最后，衷心感谢飞轮科技技术团队与 Doris 社区对浩瀚深度的持续、专业的技术支持，有力推动了我们的国产化架构转型进程。 我们热忱期待更多同仁加入 Apache Doris 的应用实践与社区贡献行列，共同丰富其功能生态、扩展函数支持，助力 Apache Doris 在全球 MPP 数据库领域绽放璀璨光芒！
