Advice: efficiënt opslaan en queryen van een grote dataset

Samenvatting

Grote dataset van 7 TB vraagt om een andere queryaanpak wanneer Athena voor ID- en tekstzoekopdrachten te traag reageert.

Grote dataset: opslag en querypatroon

De dataset bestaat uit Parquet-bestanden in een S3-bucket, verdeeld over partities op basis van datum. Gebruikers bevragen die bestanden momenteel via Athena, met Glue als onderdeel van de queryomgeving.

Dat patroon werkt minder goed voor zoekopdrachten op een ID of tekst. Een query kan daardoor meer dan tien minuten nodig hebben om één rij terug te geven. De vraagsteller zoekt daarom advies over een opslag- en queryvoorziening voor een dataset van deze omvang.

Athena, Glue en OpenSearch: waarom dit telt

De partities op datum sluiten niet direct aan op de beschreven zoekvragen. Een query die geen datumselectie gebruikt, heeft mogelijk weinig voordeel van die indeling en moet veel bestanden doorzoeken voordat een resultaat verschijnt. Dat verklaart waarom een kleine resultaatset toch lang kan wachten.

De keuze voor OpenSearch wijst op een andere technische benadering: zoekopdrachten op tekst en specifieke identifiers vragen om een index die daarop is ingericht. De bron meldt nog niet of OpenSearch de uiteindelijke oplossing wordt. Wel maakt de casus duidelijk dat opslagformaat, partitiesleutel en zoekpatroon samen moeten worden ontworpen.

Voor BI-teams zit de les vooral in het onderscheid tussen analytische scans en gerichte zoekopdrachten. Athena blijft in deze situatie de bestaande route voor gebruikers, maar de gemelde wachttijd laat zien dat één querylaag niet automatisch geschikt is voor elk type toegang.

Grote dataset: concrete takeaway

Breng eerst de querypatronen in kaart voordat je de opslag vervangt. Leg vast welk aandeel van de zoekopdrachten op datum, ID of tekst zoekt en test daarna afzonderlijk Athena met de huidige datumspartities en OpenSearch als mogelijke zoekindex. Meet daarbij de tijd tot het eerste resultaat, niet alleen de totale verwerkingstijd.