快遞柜巨頭豐巢最近干了一件事——把用了多年的日志平臺(tái)從 ELK 架構(gòu)"搬"到了 Apache Doris。這不是什么跟風(fēng)追新，而是被業(yè)務(wù)逼的：每天 40TB 日志、100 萬(wàn)條/秒的寫入峰值，老系統(tǒng)一到高峰期就"罷工"，日志延遲能飆到 1 小時(shí)以上。

想象一下，你家的快遞柜出了故障，工程師想查日志定位問(wèn)題，結(jié)果系統(tǒng)告訴你"稍等，日志還在路上"——這種體驗(yàn)，豐巢的運(yùn)維團(tuán)隊(duì)吃了太多次。

原來(lái)的 ELK 架構(gòu)由 18 臺(tái)機(jī)器組成，異構(gòu)集群，配置參差不齊。團(tuán)隊(duì)甚至專門采購(gòu)了 10 臺(tái)頂配新機(jī)做測(cè)試，寫入峰值勉強(qiáng)摸到 100 萬(wàn)條/秒，但業(yè)務(wù)高峰已經(jīng)沖到 120 萬(wàn)。繼續(xù)堆機(jī)器？治標(biāo)不治本，成本還會(huì)滾雪球。

轉(zhuǎn)機(jī)出現(xiàn)在公司內(nèi)部——其他業(yè)務(wù)已經(jīng)在用 Doris，團(tuán)隊(duì)得以低成本試水。同樣的硬件條件下，Doris 交出的成績(jī)單很直接：存儲(chǔ) 18TB/天（省 50%），寫入峰值 200 萬(wàn)條/秒（快 1 倍）。查詢場(chǎng)景里，最近一小時(shí)、三小時(shí)、一天的日志檢索，Doris 整體更快。

新架構(gòu)保留了 Filebeat → Kafka 的前半段，后半段換成了 Flink → Doris，查詢?nèi)肟谟?SelectDB Studio 替代 Kibana。上線后，寫入速度提升約 2 倍，查詢速度提升約 6 倍，存儲(chǔ)空間減少約 50%。

技術(shù)細(xì)節(jié)里藏著不少工程取舍。比如分區(qū)粒度，按天分區(qū)會(huì)導(dǎo)致分桶數(shù)爆炸，最終選了按小時(shí)；分桶方式用 RANDOM，單桶控制在 5GB 左右；壓縮用 ZSTD，索引按需建，全文檢索的字段開(kāi)分詞，等值查詢的不開(kāi)。最有趣的是加了一個(gè) doris_ingest_time 字段，專門用來(lái)算"日志從產(chǎn)生到入庫(kù)到底耽誤了多久"。

穩(wěn)定性保障上，團(tuán)隊(duì)給查詢和寫入做了資源隔離，CPU 硬限制 1:1，內(nèi)存軟限制。還寫了三條 SQL 攔截規(guī)則：沒(méi) where 條件的、沒(méi)指定 log_time 的、沒(méi)指定 app_name 的，一律攔在規(guī)劃階段——畢竟見(jiàn)過(guò)太多"手滑"把全表查穿的案例。

目前平臺(tái)已平穩(wěn)運(yùn)行，下一步要接審計(jì)日志、Nginx 日志，最終目標(biāo)是 OTel + Grafana 的完整可觀測(cè)閉環(huán)。豐巢的工程師提到一個(gè)細(xì)節(jié)：未來(lái)想實(shí)現(xiàn)從日志跳追蹤、從追蹤回日志的雙向聯(lián)動(dòng)——那時(shí)候，查問(wèn)題就不用再開(kāi)七八個(gè)窗口來(lái)回翻了。