DatabricksTaylor Kain, Zachary Schmerber (Atlassian), Niels Heijmans (Atlassian)Problem & solution
Reducing the noise: How Atlassian built an OCSF security lakehouse on Databricks
Summary
Atlassian faced a security data pipeline ingesting 44 billion events daily from 20 years of growth and acquisitions, each with proprietary logging formats. To unify this fragmented telemetry, the team standardized on the Open Cybersecurity Schema Framework (OCSF) and built a security lakehouse on Databricks. They embedded the entire OCSF schema into Go structs (TypeGo), guaranteeing compile-time correctness and reducing AI hallucinations during automated transformation. Table optimization with partitioning and Z-ORDER cut query times by 95%, and Graviton clusters with Photon reduced cost and runtime by two-thirds. The result was a self-service platform where SOC analysts can onboard new data sources in days, and detection teams moved from one-to-one alerts to signal-based clustering using standardized OCSF values.
Context
Atlassian, a global SaaS provider serving 350,000 customers, accumulated 20 years of logging formats from acquisitions, resulting in a security data pipeline ingesting 44 billion events per day with no common schema. Analysts wasted time normalizing data, cross-platform correlation was limited, and SIEM pipelines could not keep pace. The team needed to coalesce fragmented telemetry into one place while maintaining flexibility and avoiding vendor lock-in.
Approach / What changed
Standardize all security telemetry on the Open Cybersecurity Schema Framework (OCSF) and build a lakehouse on Databricks. Use ETL to transform data in flight, embed the entire OCSF schema into Go structs (TypeGo) for compile-time correctness, and automate the mapping pipeline into a self-service platform where analysts can onboard new data sources with gated PR-based workflows. Optimize table performance with partitioning, Z-ORDER, Graviton clusters, and Photon.
Takeaways
Embedding the OCSF schema into Go structs (TypeGo) guarantees compile-time correctness and reduces AI hallucinations during automated transformation.
Table optimization with partitioning and Z-ORDER on structured OCSF data improved query performance by 95%, and Graviton clusters with Photon cut cost and runtime by roughly two-thirds.
Standardization on OCSF enabled detection teams to move from one-to-one alerts to signal-based clustering, where multiple findings are grouped into a single alert using standardized values like actor.user.
FAQ
Why did Atlassian choose OCSF over ECS or UDM?
OCSF was the only option considered wholly open. It offered a strongly typed schema with robust validation, good compression efficiency, extensibility, and an open-source community with Linux Foundation backing. Its roughly 40,000 fields provided semantic context that stays with the data.
How did they achieve a 95% query performance gain?
By structuring data in OCSF and using partitioning and Z-ORDER optimization on Databricks, a representative query dropped from ~45 seconds to 2–3 seconds, a 95% improvement. Enabling Graviton clusters with Photon further reduced query cost and runtime by roughly two-thirds.
How did Atlassian automate log mapping?
They built a self-service platform where an analyst identifies logs and provides a canonical dataset. The workflow scans the Go structs, generates mappings and a DAG, tests locally, deploys a canary via PR, validates at scale, and promotes to production after a soak. Regression testing gates everything.
Source and freshness
- Source
- databricks.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.