北京
做快递柜的丰巢，每天产生的日志比你想象的更夸张——每秒100万条、每天40TB。这数据量要是打印出来，能绕地球好几圈。
但问题是，他们的日志平台扛不住了。
高峰期日志延迟超过1小时，线上出故障想查日志？等你能看到的时候，用户投诉电话已经打完了。集群CPU飙到200%-300%，查询频繁超时，运维人员盯着空白页面干瞪眼。更头疼的是存储成本，40TB/天，这数字放在任何公司的财报里都是显眼包。
原来的ELK架构就像一辆超载的货车：Elasticsearch集群13台高配机器+5台低配机器混着跑，每天磁盘占用40TB，写入峰值80万条/秒。团队咬牙买了10台112核512G的怪兽机器，测试下来写入峰值勉强摸到100万条/秒——但业务高峰已经冲到120万条/秒了。
继续堆机器？这就像给漏水的桶不断加水，治标不治本。
转机来自公司内部：另一块业务已经在用Apache Doris。团队顺手搭了个测试集群，同样的硬件条件，结果让人意外——
存储占用18TB/天，直接砍半；写入峰值200万条/秒，翻倍。
换句话说，Doris用更少的空间，吞下了更多的数据。
查询场景也做了验证：检索最近1小时、3小时、1天的日志，Doris整体快于Elasticsearch。团队最终拍板：换。
新架构保留了Filebeat→Kafka的采集链路，后半段彻底重构：Flink替代Logstash负责写入，Doris替代Elasticsearch做存储和计算，SelectDB Studio替代Kibana当查询入口。
上线后的数字很漂亮：写入速度提升2倍，查询速度提升6倍，存储空间减少50%。
但漂亮数字背后有不少踩坑细节。比如最初试过Logstash写Doris，高并发下频繁OOM，后来换成Flink才稳定。表结构设计也折腾了几轮：按天分区会导致分桶数爆炸，改成按小时；分桶数从360调到240再到180，Compaction Score才从2000+降到280，写入终于不抖了。
查询治理更有意思。团队发现用户经常不写时间范围，SQL直接扫全表。于是加了拦截规则：没WHERE条件？拦。没指定log_time？拦。没写app_name？也拦。就像给数据库装了红绿灯， reckless driving直接扣下。
权限控制用了行级策略，按业务线字段隔离。单业务线用等值过滤，跨业务线用IN，一张表搞定，不用拆得七零八落。
监控方面盯两个指标：Kafka消费积压、日志链路延迟。后者有个巧妙设计——表里加了doris_ingest_time字段，对比log_time就能算出日志从产生到入库花了多久。曾有一次查不到最新日志，Kafka没积压、文件也存在，最后发现是生产端延迟，靠这个字段定位的。
现在平台已经平稳运行，后续要接审计日志、Nginx日志，终极目标是用OTel+Grafana打通监控、链路追踪和日志，实现从日志跳追踪、从追踪回日志的双向联动。
丰巢的工程师提到一个细节：优化过程中最耗时的不是技术选型，而是调整分桶数和Compaction参数——这些"看不见"的配置，决定了系统能不能在高峰期稳住。就像快递柜的调度算法，用户感知不到，但决定了你的包裹能不能准时取出来。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
