Atlassian 每天 440 亿条安全日志，摄取成本是怎么降掉 80% 的

Atlassian 的安全团队每天要处理 440 亿条安全事件，它们来自二十年里陆续收购进来的产品，每个产品都有自己的日志格式、时间戳写法和私有 schema。¹10 月 15 日，Databricks 和 Atlassian 的工程师合写了一篇博客，讲他们怎么把这些日志统一成一套开放的 schema，放进 Databricks 湖仓。¹

厂商称的结果是：摄取成本降了 80%，500 多个生产检测信号跑在同一套 schema 上，分析师效率提升 60%。¹客户案例页还说，随时可查的日志从 30 天延长到 12 个月。²

这是一个很有代表性的海量数据降本案例。省下的钱来自一连串前后咬合的工程决定：先决定收什么，再在落地前统一格式，然后让 AI 在门禁里做映射，最后才做查询优化。下面按数据走的顺序，把这套方案的做法一个个拆开。

二十年的收购，留下一堆对不上的日志

问题先出在分析师身上：数据落地以后，他们要花大量时间做清洗；数据散在不同地方、长成不同形状，跨平台的关联分析做不起来；原来的 SIEM（安全信息和事件管理系统）管道也跟不上数据量。¹

旧 SIEM 还有三个结构性的毛病：数据存在私有存储里，只保留 30 天，更早的日志要从冷存储回灌，费时又费钱；授权按每 GB 摄取量收费，数据一涨账单就涨；查询用厂商自己的语言，换工具时技能带不走。²

真正把事情推到台前的是一次重大安全事件。调查时要回灌接近 1 PB 的数据，旧系统撑不住，团队在事件当中切到了 Databricks。²

统一用的 schema 叫 OCSF（Open Cybersecurity Schema Framework，开放网络安全 schema 框架）。它 2022 年由 AWS、Cisco、IBM、Splunk 等公司发起，2024 年 11 月进入 Linux Foundation，有 900 多位贡献者、200 多个参与组织。⁴整条数据路径如下。

先定收什么：按价值和成本给日志打分

Data + AI Summit 上的演讲提到，团队用一张“价值对成本”的评分表来决定哪些日志值得摄取。³客户案例页的说法是，有了这张评分表，湖里只存信号，噪音挡在门外。²

这一步在按 GB 收费的 SIEM 时代很难做好：每多收一类日志就多一笔账，筛选标准变成“付得起多少”。换到自己的存储以后，问题才变成“哪些值得留”。

算一笔假设的账：如果每条事件平均 1 KB，每天 440 亿条大约是 44 TB。入口每少收 10%，每天就少存、少转、少查 4.4 TB。这些数据之后的每一个环节都不用再为它付钱。所以降本的第一刀在入口，查询优化排在最后。

落地之前就转换：Atlassian 有意选了 ETL

现在的数据平台习惯 ELT：原始数据先落地，用到时再转换。Atlassian 反过来，有意选了 ETL，数据在路上就转换好。博客给的理由有三个：能做实时检测，不被某家厂商的格式绑住，数据在流动中就被压缩。¹客户案例页给了一个具体数字：转成 Parquet 以后，比原来的 JSON 字符串小 20%。²

ELT 的好处是灵活，坏处正是 Atlassian 开头遇到的问题：每个分析师都在落地以后各自清洗一遍。ETL 把这份工作挪到入口，只做一次。代价是映射必须提前做好，没映射的字段容易丢。Atlassian 的 Go 库里有一项“自动处理未映射字段”，¹就是在补这个口子。

我的理解是，ETL 在这里划算，有两个前提：目标 schema 稳定且大家共用，数据量大到每个分析师各洗一遍的成本高得离谱。两个条件 Atlassian 都满足。

4 万个字段写进 Go 代码，错误在编译时就暴露

OCSF 大约有 4 万个字段。¹团队在 ECS、UDM 这些选项里选了它，因为它是唯一完全开放的一个，还有强类型、校验、压缩效率和可扩展性，背后又有 Linux Foundation。¹

更关键的一步是把整套 schema 写进 Go 的 struct，团队叫它 TypeGo：不合规的记录在编译时就失败，嵌套对象直接支持，代码有单元测试。¹配套的是一个开源的 Go OCSF 库，带校验性能优化。¹存储层的 ACID 事务又让 schema 版本迁移不会弄坏下游的使用者。¹

字段多，一开始看着吓人，后来反而成了优势，因为语义跟着数据走：拿到一个字段，就知道它在所有来源里是同一个意思。¹对做数据的人来说，这是把“数据契约”做到了最硬的程度：契约写在代码里，违约的数据根本过不了编译。

80% 到底省在哪一步，三份材料说法不同

80% 是这个案例里最常被转述的数字，但三份材料各说各的：

• 博客把它放在“把安全遥测统一到 OCSF 之后”。¹
• Summit 演讲摘要说的是“换用文件通知加载器之后”。³
• 客户案例页写的是“运营摄取成本”降了 80%，引用 Atlassian 首席安全架构师 Niels Heijmans 的话，说的是“摄取开销”。²

三种说法不冲突，但不是同一件事。把前面几节放在一起看，可能的来源至少有四个：不再按 GB 付 SIEM 授权、入口评分少收的日志、在途压缩、加载方式的改变。文件通知加载，我的理解是由存储事件告诉加载器有新文件到达，不用反复扫描目录，量越大省得越多。

三份材料都没有给分项。拿这个数去说服老板之前，最好先在自己的账单上找到对应的那一项：你省的是授权费、存储费，还是计算费。

AI 做映射，但每一步都有人把关

最早的映射是一套六步的手工流程：收集日志、转成 TypeGo、配路由、测试、配置、提 PR 上线。博客的说法是从“映射即服务”走到了自助平台。¹现在的流程如图 2。¹

强类型 schema 在这里又帮了一次忙：模型写不出不合法的输出，凭空编出来的映射少了，反复试错消耗的 token 也省了。¹

速度的变化很大。负责这件事的工程师 Zachary Schmerber 说，他花了一年映射了今天已映射数据的三分之一，剩下三分之二只用了两个月。¹博客把这段话放在讲自动化的那一节，但没有明说提速全靠自动化。换算成每月的进度，差了大约 12 倍。

我在写裁判模型的那篇里说过，强审计场景用模型做判断，要先问三件事：有没有办法分流没把握的，结论能不能重放，判错了回退要花多少。Atlassian 的流程三件事都有答案：人工确认在前面挡着，回归测试负责重放，金丝雀环境和观察期把回退成本压在上生产之前。

字段统一以后，告警从一条规则一条变成按人聚合

统一 schema 最直接的收益在检测上。以前是一条规则触发一个告警；现在多个信号按统一的 OCSF 字段聚成一个告警，团队的 Alert Explorer 工具就是按这些标准值来聚类的：同一个用户字段，不管出现在认证事件还是网络事件里，都是同一个字段。¹

富化（给告警补上用户、资产等背景信息）也跟着简化了：以前每条检测各写一套，现在对一个标准化的用户名调一次富化 API。¹跨领域关联、用户行为分析、同时看多台路由器或多个漏洞扫描器的异常，都变得可行。¹检测代码也从 SIEM 的专有查询迁到了 PySpark，用一个共享的 Python 库复用函数。²分析师效率提升的 60%，博客归因于“所有工具共用同一套可重复的流程”。¹

查询提速排在最后，数字要看清是哪一组

查询优化的数字不少，但来自不同的查询：

• 分区加 Z-ORDER，让一条“有代表性”的查询从约 45 秒降到 2 到 3 秒；换用 Graviton 集群加 Photon，查询成本和耗时又降了约三分之二。¹
• 客户案例页的另一组：Photon 把查询从 17 秒降到 5 秒，210 多亿条事件 1 分钟内查完。²
• Summit 摘要只说定时任务和一整天范围的搜索，从几分钟降到几秒。³

这几组数不能相加，也不能互相印证，只能说明方向。下一步团队要评估 Liquid Clustering。¹权限由 Unity Catalog 统一管，因为里面有内部威胁调查这类敏感数据。²

排在最后的原因很简单：入口评分和统一 schema 决定了存什么、存成什么样，查询优化只能加速剩下的那部分。顺序反过来，就是在给噪音提速。

能照搬的四件事，和要打折的三件事

能照搬的：

• 入口评分：每类日志按价值和成本打分，先砍掉不值得收的。
• schema 前置并且强类型：不一定用 Go，JSON Schema 或 Protobuf 也能在入口挡住不合规的数据。
• AI 映射的门禁链：人工确认、本地测试、金丝雀、观察期、回归测试，一个都别省。
• 在统一字段上做富化和聚合：富化写一次，所有检测共用。

要打折的：

• 这是 Databricks 和 Atlassian 合写的材料，数字都没有独立核实。
• 几组性能数字来自不同查询，口径不一；80% 的归因三份材料说法不同。
• Atlassian 的工程投入不是每家都有：自己维护 Go 库和映射 IDE，团队里还有 OCSF schema 的维护者。¹

对做审计和合规日志平台的人，这个案例更值得细看。审计日志和安全日志长得很像：来源多、量大、每一条都要能追溯。统一 schema、把校验放在入口、每次映射变更都留下测试和审核记录，这三件事搬过去就能用。