xx
arrow_backTil oversigten7. august 2026 | Tenzir GmbH
How should you lay out OCSF events in Iceberg? We survey the storage strategies the OCSF community is converging on, explain why wide sparse tables are cheap in Iceberg but expensive in ClickHouse, and show how one line of TQL turns the recommendation into a running lakehouse.
The Open Cybersecurity Schema Framework (OCSF) defines what a normalized security event looks like: its normative form is JSON. It deliberately says nothing about how to store events for analysis. That question lands on every security data engineer the moment the first OCSF-mapped events flow: one table or many? Flattened or nested? Partitioned by what?
The OCSF community is now tackling this head-on. Paul Agbabian’s storage strategies article surveys the table layouts practitioners use for OCSF events in Parquet and Iceberg. We contributed to that discussion and want to expand on one aspect here that deserves more attention: the choice of storage engine changes which strategy is right, and the answer for Iceberg differs from the answer for OLAP engines like ClickHouse. We conclude with a blueprint for shipping OCSF into an Iceberg lakehouse with Tenzir.
Artikel er skrevet af:
Tenzir GmbH
I en verden, hvor sikkerhedsdata ofte er låst fast bag stive platforme, skyhøje udgifter og proprietære formater, tror vi på en anden fremtid – en fremtid, hvor data flyder frit uden begrænsninger.
Sikkerhedsdata bør være et strategisk aktiv, ikke en byrde styret af leverandører. Enhver organisation fortjener kraftfulde, intuitive værktøjer, der gør sikkerhedsdata tilgængelige, oplysende og handlingsrettede – uden besvær med kompleksitet, siloer eller uforudsigelige omkostninger.
Vi er her for at omdefinere, hvordan sikkerhedsteams behandler, analyserer og handler på baggrund af deres da