Firma centralizuje logi przepływu VPC z wielu kont w jednym buckecie S3. Logi są przechowywane jako pliki tekstowe skompresowane za pomocą gzip i muszą być przechowywane bezterminowo. Analitycy uruchamiają doraźne zapytania Athena na tych logach, ale wydajność zapytań spada wraz ze wzrostem wolumenu logów. Musisz zarówno poprawić wydajność zapytań, jak i zmniejszyć zużycie pamięci masowej. Która zmiana zapewni NAJWIĘKSZĄ poprawę wydajności?

Poprawna odpowiedź to ponowna konfiguracja dostarczania logów przepływu VPC do formatu Apache Parquet z partycjami godzinowymi. Parquet to kolumnowy format przechowywania danych, który znacznie poprawia wydajność zapytań Athena, ponieważ Athena może odczytywać tylko potrzebne kolumny, a nie całe wiersze. Partycjonowanie godzinowe dodatkowo zwiększa wydajność, ograniczając skanowanie danych tylko do odpowiednich przedziałów czasowych, co jest kluczowe dla logów. Zmniejsza to również koszty przechowywania, ponieważ Parquet jest formatem skompresowanym. Pozostałe opcje są mniej efektywne: Dekompresja i ponowna kompresja za pomocą bzip2 zwiększy koszty Lambda i nie poprawi wydajności zapytań w takim stopniu jak format kolumnowy. S3 Transfer Acceleration przyspiesza przesyłanie danych do S3, ale nie wpływa na wydajność zapytań ani na koszty przechowywania po ich zapisaniu. S3 Intelligent-Tiering optymalizuje koszty przechowywania, ale nie poprawia wydajności zapytań. Nowa grupa robocza Athena lub wersja silnika 2 mogą przynieść pewne korzyści, ale nie rozwiązują podstawowego problemu nieefektywnego formatu danych i braku partycjonowania, które są głównymi czynnikami wpływającymi na wydajność zapytań na dużych zbiorach logów.