当 AI 遇上大数据！MiniMax基于 Doris 的PB级数据保卫战

❝在大模型（LLM）狂飙突进的这两年，我们习惯了在发布会上看各大厂商秀肌肉：万亿参数、超长上下文、跑分吊打 XXX... 但在这些光鲜亮丽的 PPT 背后，有一群人正盯着屏幕上不断飘红的监控报警，手里攥着速效救心丸。这群人就是负责 AI 基础设施的研发同学。 大模型是个吞金兽，这一点大家都知道。但很多人忽略了，它也是个产屎大户——这里指的不是模型输出的废话，而是海量的、爆炸式增长的日志数据。 今天我们要聊的故事主角，是国内大模型独角兽 MiniMax，且看它是如何基于 Apache Doris 秒级查询PB级数据。

MiniMax为什么选了Doris？

先把时间拨回 MiniMax 早期。像大多数追求敏捷的互联网公司一样，他们在搭建日志系统时，首选了 Grafana Loki。

理由很充分：Loki 号称日志界的 Prometheus，轻量、开源、部署快。它不像 Elasticsearch 那样不仅要存原文还要建一大堆索引（倒排索引），Loki 的设计哲学是——只索引元数据（比如时间戳、标签），原本的日志内容压缩一扔，主打一个写入快、存储省。

在业务起步阶段，这简直是完美的后胎。

但随着 MiniMax 的业务爆发，特别是万亿参数模型上线后，剧情开始反转。AI 场景的日志跟传统 Web 业务完全是两个物种。一次大模型的推理请求，链路极长，上下文数据多得吓人，单条日志的体积甚至能顶上普通应用几百条。

这时候，Loki变成了致命伤。

图片

大家最怕的场景出现了：线上出故障，急需定位问题，你在搜索框里输入一个关键词，点击【查询】。因为 Loki 没有对日志内容建全文索引，它只能把所有相关标签的日志捞出来，然后暴力扫描——相当于你要在图书馆找一本书，Loki 不查目录，而是从第一排书架开始把每一页都翻一遍。

结果就是，CPU 飙升，内存报警，查询转圈转到天荒地老，最后给你吐出一个Timeout。

更要命的是运维成本。

Loki 的架构组件多得像乐高积木：Ingester、Querier、Index Gateway、Compactor……为了隔离性，MiniMax 不得不在每个集群单独部署一套。运维工程师每天不仅要盯着模型训练，还得伺候这几十套日志系统，配置复杂到让人怀疑人生。

这种日子过久了，谁都得疯。

MiniMax 意识到，Loki 已经不再是那个小甜甜了，他们需要一个能扛得住 PB 级数据、查得快、还得便宜的牛夫人。

图片

摆在 MiniMax 面前的选项其实不多。

老牌霸主 Elasticsearch（ES）当然在候选名单里。ES 的倒排索引能力是业界标杆，查得确实快。但 ES 有个著名的毛病：成本高。

对于 PB 级别的日志数据，如果用 ES 存，那个存储成本和资源消耗，老板看了财务报表估计会直接把你叫进办公室谈心。而且 ES 在高并发写入时的吞吐量，面对 AI 洪峰时也显得有点吃力。

这时候，Apache Doris 走进来了。

很多人的印象里，Doris 还是那个跑报表、做 OLAP 分析的数据库。但实际上，Doris 在这两年悄悄点满了日志检索的技能树。

MiniMax 的技术团队做了一番硬核对比，发现 Doris 居然是个六边形战士：

首先是倒排索引。

Doris 现在支持原生倒排索引，这意味着它在全文检索上的能力已经可以和 ES 掰手腕。你查一个关键词，它不需要全表扫描，而是直接定位文档 ID，速度极快。

其次是写入性能。

Doris 的 Stream Load 和 Routine Load 机制，吞吐量极其残暴。MiniMax 实测下来，单节点写入吞吐能达到 ES的近5倍。

整个集群日志洪流灌进去，Doris 连眉头都不皱一下。

最关键的是成本。

Doris 的列式存储加上 ZSTD 压缩算法，压缩比能做到 1:5 以上。同样的 PB 级数据，存在 Doris 里占用的磁盘空间只有原来的几分之一。

再加上冷热数据分层技术，把 7 天前的老日志自动扔到廉价的对象存储（S3）上，这成本一下就打下来了 70% 以上。

既能省钱，又能干活，还能用 SQL 直接查（兼容 MySQL 协议），这对运维和研发来说，简直就是降维打击。

基于 Doris 的全新日志系统

决定迁移后，MiniMax 搞出了一套名为 Mlogs 的新系统。

这次他们学聪明了，不再搞一集群一套的烟囱式架构，而是用一套 Doris 集群服务所有业务线。架构图画出来异常清爽：

图片

最前端还是 iLogtail 采集日志，扔进 Kafka 做缓冲（削峰填谷，这是基操）。

关键在后端。对于标准的 JSON 日志，直接用 Doris 的 Routine Load 功能。你只需要配置好 Kafka 的 Topic，Doris 就会自己伪装成一个消费者，源源不断地把数据拉进来，完全不需要写一行额外的 Java 或 Python 代码。

对于那些格式稀奇古怪的复杂日志，MiniMax 加了一层自定义的 Ingester 清洗，处理完后再通过 Stream Load 批量灌入 Doris。

在查询端，变化更是翻天覆地。

以前在 Loki 里查日志是盲人摸象，现在在 Doris 里是精准制导。

通过 MATCH 和 MATCH_PHRASE 语法，利用倒排索引进行分词查询，亿级的数据量，查个关键字只需要秒级。

更有意思的是，为了防止某些小白用户手滑查一个过去一整年的数据把集群搞挂，MiniMax 的团队在中间层做了一个查询截断功能。

系统会预估你要查的数据量，如果发现你要查的时间范围内有几万亿条日志，直接拦截并提示缩小范围。这种防呆设计极大地保护了系统的稳定性。

结语

现在的 MiniMax 内部，PB 级日志都跑在 Apache Doris 上。

过去查询转圈圈的日子结束了，整体可用性达到了 99.9%。对于通宵达旦训练模型的工程师来说，秒级定位 bug 意味着能多睡两个小时，这可是实打实的福报。

这个案例其实给大数据的从业者提了个醒：在 AI 时代，数据的体量和复杂度正在重塑我们的基础设施。原本泾渭分明的界限正在模糊——做分析的数据库开始干日志检索，做搜索的引擎试图搞分析。

Apache Doris 从一个单纯的 OLAP 数据库，进化到如今能吞下 PB 级日志的统一存储平台，正是这种技术融合的缩影。对于像 MiniMax 这样的 AI 独角兽来说，选择 Doris 不仅仅是因为它快或便宜，更是因为它能用最简的架构，解决最复杂的问题。

在算力比黄金还贵的今天，把省下来的 CPU 拿去跑模型，总比浪费在扫描日志上要划算得多，不是吗？