Partitionera loggar för hastighet och kostnad

Eftersom Athena tar betalt per genomsökt datamängd slösar ni både pengar och tid om ni frågar efter ett års loggar för att hitta händelser från en enda dag. Partitionering är tekniken som gör att Athena bara behöver läsa den relevanta delen av datan, vilket gör frågorna avsevärt snabbare och billigare. Det är den viktigaste enskilda optimeringen i Athena.

En partition delar upp en tabells data efter värdena i en eller flera kolumner, vanligtvis datumkomponenter som mappas till S3-prefix. CloudTrail-loggar är redan strukturerade efter region/year/month/day, så partitionering efter dessa värden motsvarar den fysiska strukturen och gör att Athena kan hoppa över mappar utanför frågan.

När en fråga filtrerar på en partitionskolumn utför Athena partition pruning: endast matchande prefix läses och resten ignoreras. En fråga för en enda dag med korrekta partitioner genomsöker en mycket liten del av bucketen. Utan pruning skulle samma fråga genomsöka allt, även data som den omöjligen kan behöva.

Ett sätt att registrera partitioner är ALTER TABLE ADD PARTITION, där ett partitionsvärde kopplas till dess S3-plats. Det fungerar, men är omständligt för dagliga loggdata eftersom ni skulle behöva lägga till en partition varje dag. Det passar bra för enstaka historiska inläsningar, men skalar inte för fortlöpande loggar.

Partition projection är den moderna och rekommenderade metoden: ni anger partitionsmönstret för Athena, till exempel datum inom ett intervall, och Athena beräknar prefixen vid frågetillfället utan att lagra varje partition i katalogen. För CloudTrail- och Flow Log-data som växer kontinuerligt undviker detta ständigt underhåll och gör pruning automatisk.

En Glue crawler kan också upptäcka nya partitioner enligt ett schema och lägga till dem i katalogen. Det automatiserar hanteringen av partitioner för data som förändras, men för förutsägbara datum-baserade layouter är partition projection vanligtvis enklare och medför ingen crawler-kostnad.

Partitionering begränsar vilka filer som läses, medan kolumnformat som Parquet begränsar vilka kolumner som läses i dessa filer. Genom att kombinera båda – konvertera loggar till Parquet och partitionera efter datum – kan ni minska den genomsökta datamängden med flera storleksordningar. Många team kör ett konverteringsjobb för att lagra frågeoptimerade kopior av loggar med hög volym.

Om ni komprimerar loggdata med format som GZIP eller Snappy minskar ni ytterligare antalet genomsökta byte och lagringskostnaden. Athena läser komprimerade filer transparent. Tillsammans med partitionering och kolumnlagring fullbordar komprimering den trio av tekniker som gör storskalig logganalys ekonomiskt överkomlig.

För säkerhetsloggar bör ni i första hand partitionera efter datum eftersom utredningar är tidsbegränsade. Överväg även partitionering efter konto eller region för organisationstrails, så att ni snabbt kan rikta in er på ett visst konto. Rätt partitionsnycklar återspeglar hur era utredningar faktiskt filtrerar och maximerar pruning för verkliga frågor.

Athena rapporterar genomsökt datamängd per fråga. Genom att övervaka detta mått ser ni om partitioneringen fungerar: en välpartitionerad fråga med ett begränsat tidsintervall bör genomsöka megabyte, inte terabyte. Om en fråga genomsöker betydligt mer än förväntat är filtret förmodligen inte anpassat till partitionskolumnerna.

Optimeringslagren består av partitionering för att hoppa över irrelevanta data, kolumnformat för att bara läsa nödvändiga kolumner och komprimering för att minska antalet byte. Tillämpade på CloudTrail och Flow Logs omvandlar dessa tekniker långsamma och kostsamma genomsökningar till snabba och billiga utredningar – precis vad storskalig säkerhetsanalys kräver.

Partitionering delar upp tabelldata efter kolumner, vanligtvis datum, så att Athena kan utföra partition pruning och bara genomsöka relevanta prefix, vilket minskar kostnad och tidsåtgång. Föredra partition projection framför manuella ADD PARTITION eller crawlers för loggar som växer. Kombinera partitioner med kolumnformatet Parquet och komprimering för stora besparingar, partitionera säkerhetsloggar efter datum och konto och övervaka måttet för genomsökt datamängd.