降噪：Atlassian 如何在 Databricks 上构建 OCSF 安全湖仓
内容提要
Atlassian每天处理440亿起安全事件，因日志格式不统一，采用OCSF标准并在Databricks上构建自助式安全湖仓。通过ETL、表优化和Go结构体嵌入模式，查询速度提升95%，成本降低约三分之二，支持500多种威胁检测信号，实现跨源关联与AI辅助分析。
延伸解读
OCSF 选型：为何开放标准胜出
Atlassian 在评估 ECS、UDM 等方案后选择 OCSF，核心在于其完全开放、强类型和社区支持。OCSF 约 4 万个字段看似繁琐，但语义上下文随数据保留，使跨源查询无需事后归一化。强类型和验证减少了转换后的歧义，同时压缩效率高，为后续湖仓性能打下基础。
ETL 与表优化：性能提升的关键
团队刻意选择 ETL 而非 ELT，在传输中转换以支持实时检测并保持厂商中立。结合 Databricks 的 ACID 事务和自动扩展 Spark，再通过分区与 Z-ORDER 优化，代表性查询从约 45 秒降至 2-3 秒，提升 95%。启用 Graviton 与 Photon 后，查询成本和运行时间进一步降低约三分之二。
TypeGo 与自助平台：工程效率变革
将 OCSF 模式嵌入 Go 结构体（TypeGo）确保编译时正确性，并显著减少 AI 转换中的幻觉和 token 消耗。原本六阶段手动流程被自动化，最终演变为自助平台：分析师选择日志后，系统自动生成映射、DAG、测试并部署。映射效率从一年完成三分之一提升到两个月完成剩余三分之二。
检测与 AI 前景：从告警到信号
标准化使检测从一对一告警转向基于信号和风险的聚类，通过 Alert Explorer 围绕 OCSF 值（如 actor.user）聚合发现，简化富化和分类。OCSF 的语义丰富性还为 AI 辅助分析提供上下文，减少幻觉，未来路线图包括代理技能、上下文 SQL 和基于 OCSF 的上下文图，并探索 Liquid Clustering 优化查询。
Q&A
Atlassian 为什么选择 OCSF 而不是 ECS 或 UDM？
OCSF 是团队认为完全开放的唯一选项，相比 ECS 或 UDM，它提供强类型模式和健壮验证，减少转换后的歧义，压缩效率好，可扩展，并有开源社区支持（Linux 基金会背书，迈向国际标准）。
Atlassian 在 Databricks 上构建安全湖仓时，为什么选择 ETL 而不是 ELT？
为了支持实时检测、保持供应商独立性，并在数据流经管道时进行压缩。
Atlassian 如何通过表优化提升查询性能？
利用结构化 OCSF 数据进行分区和 Z-ORDER，将代表性查询从约 45 秒降至 2-3 秒，提升 95%；启用 Graviton 集群和 Photon 后，查询成本和运行时间减少约三分之二。
什么是 TypeGo，它如何帮助保证数据质量？
TypeGo 是将整个 OCSF 模式嵌入 Go 结构体的工程决策。因为模式存在于类型系统中，正确性在编译时得到保证，每个新 OCSF 日志都经过预验证，嵌套对象原生支持，部署灵活，且全部单元测试。
Atlassian 如何将安全日志映射过程从手动转变为自助服务？
团队最初采用六阶段手动流程，后来几乎全部自动化，并最终作为自助服务平台交给客户。分析师识别所需日志并提供规范数据集，经过门控确认后，工作流扫描 Go 结构体中的框架，生成映射和 DAG，本地测试，通过 PR 部署金丝雀配置，在金丝雀环境大规模验证，浸泡后晋升生产并通知错误。回归测试门控一切。
OCSF 标准化如何改变 Atlassian 的威胁检测和告警方式？
采用 OCSF 后，威胁检测管道从一对一告警转变为基于信号和风险的检测方法，多个信号发现聚类到单个告警中。通过 Alert Explorer 工具，发现围绕标准化 OCSF 值聚类，例如 actor.user 值在认证事件和网络事件中一致，从而标准化聚类、丰富和分类剧本，提供更有意义、可操作的告警。
OCSF 的语义丰富模式为 AI 辅助分析带来了什么好处？
因为 OCSF 在模式内携带定义，智能体辅助变得准确得多，减少了幻觉。路线图包括技能培训、智能体编排、上下文 SQL 和基于 OCSF 的上下文图，长期目标是让 OCSF 成为所有数据的规范起点。
