快递柜巨头丰巢最近干了一件事——把用了多年的日志平台从 ELK 架构"搬"到了 Apache Doris。这不是什么跟风追新，而是被业务逼的：每天 40TB 日志、100 万条/秒的写入峰值，老系统一到高峰期就"罢工"，日志延迟能飙到 1 小时以上。

想象一下，你家的快递柜出了故障，工程师想查日志定位问题，结果系统告诉你"稍等，日志还在路上"——这种体验，丰巢的运维团队吃了太多次。

原来的 ELK 架构由 18 台机器组成，异构集群，配置参差不齐。团队甚至专门采购了 10 台顶配新机做测试，写入峰值勉强摸到 100 万条/秒，但业务高峰已经冲到 120 万。继续堆机器？治标不治本，成本还会滚雪球。

转机出现在公司内部——其他业务已经在用 Doris，团队得以低成本试水。同样的硬件条件下，Doris 交出的成绩单很直接：存储 18TB/天（省 50%），写入峰值 200 万条/秒（快 1 倍）。查询场景里，最近一小时、三小时、一天的日志检索，Doris 整体更快。

新架构保留了 Filebeat → Kafka 的前半段，后半段换成了 Flink → Doris，查询入口用 SelectDB Studio 替代 Kibana。上线后，写入速度提升约 2 倍，查询速度提升约 6 倍，存储空间减少约 50%。

技术细节里藏着不少工程取舍。比如分区粒度，按天分区会导致分桶数爆炸，最终选了按小时；分桶方式用 RANDOM，单桶控制在 5GB 左右；压缩用 ZSTD，索引按需建，全文检索的字段开分词，等值查询的不开。最有趣的是加了一个 doris_ingest_time 字段，专门用来算"日志从产生到入库到底耽误了多久"。

稳定性保障上，团队给查询和写入做了资源隔离，CPU 硬限制 1:1，内存软限制。还写了三条 SQL 拦截规则：没 where 条件的、没指定 log_time 的、没指定 app_name 的，一律拦在规划阶段——毕竟见过太多"手滑"把全表查穿的案例。

目前平台已平稳运行，下一步要接审计日志、Nginx 日志，最终目标是 OTel + Grafana 的完整可观测闭环。丰巢的工程师提到一个细节：未来想实现从日志跳追踪、从追踪回日志的双向联动——那时候，查问题就不用再开七八个窗口来回翻了。