Granulariteit kiezen voor een kolom of tabel op basis van vereisten

Granulariteit is een van de meest kritieke ontwerpbeslissingen die u neemt bij het bouwen van een gegevensmodel. Het definieert het detailniveau dat in uw tabellen is vastgelegd en is rechtstreeks van invloed op de opslagkosten, queryprestaties en de analytische vragen die u kunt beantwoorden. Als data engineer helpt het begrijpen van granulariteit u bij het ontwerpen van tabellen die voldoen aan bedrijfsvereisten en tegelijkertijd efficiënte bewerkingen onderhouden.

In deze les wordt uitgelegd wat granulariteit betekent in de context van dimensionale modellering en hoe u verschillende granulariteitsopties evalueert op basis van de vereisten van uw organisatie.

Begrijpen wat granulariteit vertegenwoordigt

Granulariteit, ook wel 'grain' genoemd, beschrijft het detailniveau dat elke rij in een tabel vertegenwoordigt. In een feitentabel bepaalt de granulatie welke zakelijke gebeurtenis of meting elke rij vastlegt. In een dimensietabel bepaalt het graan hoe entiteiten worden weergegeven en versiebeheer.

Overweeg een IoT-sensorgegevensscenario. U kunt uw feitentabel ontwerpen op verschillende granulariteitsniveaus:

• Granulariteit op millisecondenniveau: elke rij vertegenwoordigt één sensorleesbewerking die is vastgelegd op millisecondenniveau. Hiermee worden de meest gedetailleerde informatie vastgelegd, waaronder nauwkeurige tijdstempels, sensorwaarden en apparaat-id's voor elke meting.

• Tweede geaggregeerde granulariteit: elke rij vertegenwoordigt de gemiddelde, minimum- of maximumsensorwaarde voor een apparaat per seconde. Afzonderlijke metingen worden samengevat in statistieken per seconde.

• Minuut geaggregeerde granulariteit: elke rij vertegenwoordigt geaggregeerde sensorstatistieken voor een apparaat gedurende een hele minuut. Dit biedt de minste details, maar vereist de minste opslag.

De korrel die u kiest, is van invloed op alles downstream. Zodra u details kwijtraakt via aggregatie, kunt u deze niet meer herstellen. Als in uw minuut geaggregeerde tabel wordt aangegeven dat sensor X een gemiddelde temperatuur van 75°C had gedurende een specifieke minuut, kunt u niet bepalen welke milliseconden temperatuurpieken hadden of het exacte moment waarop een anomalie is opgetreden identificeren.

Factoren evalueren die invloed hebben op granulariteitsbeslissingen

Als u de juiste granulariteit kiest, moet u meerdere concurrerende problemen in balans brengen. De juiste keuze is afhankelijk van uw specifieke bedrijfscontext en technische beperkingen.

Bedrijfsvereisten bepalen de granulariteit.

De analytische vragen die uw organisatie moet beantwoorden, moet de primaire factor zijn bij het bepalen van granulariteit. Stel uzelf eens af: wat is het meest gedetailleerde analyseniveau dat nodig is?

Als technici apparatuurafwijkingen op milliseconden moeten detecteren, volstaan aggregaties per minuut niet. Als het management alleen uurlijkse samenvattingen van het gebruik per productielijn nodig heeft, is het opslaan van elke sensorwaarde een verspilling van middelen.

Houd rekening met deze scenario's:

Querypatronen beïnvloeden prestaties

De manier waarop gebruikers query's uitvoeren op uw gegevens, beïnvloeden de optimale granulariteit. Wanneer query's doorgaans op hogere niveaus filteren en aggregeren, zorgt het opslaan van te veel fijnmazige gegevens voor onnodige verwerkingsoverhead. Elke query moet meer rijen scannen en aggregeren dan nodig is.

Tegelijkertijd kunnen gebruikers niet inzoomen op gedetailleerde vragen door gegevens op te slaan met een te grof granulariteit. Het vinden van de balans vereist inzicht in zowel huidige als verwachte querypatronen.

Opslag- en rekenkosten stapelen zich op

Gedetailleerdere granulariteit betekent meer rijen, waardoor de opslagkosten toenemen. Het verhoogt ook de rekenkosten omdat query's meer gegevens moeten verwerken. In Azure Databricks stapelen deze kosten zich op in de loop van de tijd naarmate er steeds meer historische gegevens worden verzameld.

Een productiefaciliteit met duizenden sensoren die met intervallen van milliseconden meet, kunnen dagelijks miljarden rijen genereren met de beste granulariteit. Als u statistische gegevens per seconde of per minuut samenvoegt, kan het aantal rijen met 99% of meer worden verminderd, waarbij u rechtstreeks vertaalt naar lagere opslag- en querykosten.

Nalevings- en controlevereisten zijn belangrijk

Wettelijke vereisten verplichten soms specifieke granulariteitsniveaus. Financiële dienstverleners moeten vaak details op transactieniveau bewaren voor controledoeleinden, ongeacht de opslagkosten. Gezondheidszorgorganisaties moeten mogelijk om nalevingsredenen afzonderlijke interacties van patiënten bijhouden.

Wanneer naleving uw granulariteitsbeslissing aanstuurt, documenteer dan duidelijk de vereisten. Deze reden helpt wanneer belanghebbenden vragen waarom u meer details opslaat dan alleen analytische behoeften vereist.

Granulariteit toepassen op feitentabellen

Feitentabellen profiteren het meest van zorgvuldige granulariteitsbeslissingen, omdat ze doorgaans de grootste hoeveelheden gegevens bevatten. Het fijnmazigheidsniveau van een feitentabel wordt bepaald door de combinatie van de dimensiesleutels.

Een verkoopsfeitentabel met dimensiesleutel voor datum, product, klant en winkel heeft een granulariteit van één rij per product per klant per winkel per dag. Elke unieke combinatie van deze dimensiewaarden resulteert in een afzonderlijke rij. Het toevoegen van een tijddimensiesleutel op uurniveau zou de granulariteit wijzigen naar 'één rij per product per klant per winkel per uur', waardoor het aantal rijen aanzienlijk toeneemt.

Overweeg bij het ontwerpen van feitentabellen of u het volgende nodig hebt:

• Atomisch graan: het meest gedetailleerde niveau dat in het bronsysteem is vastgelegd. Het kiezen van atomisch graan biedt maximale analytische flexibiliteit omdat u altijd omhoog kunt aggregeren, maar nooit omlaag kunt uitsplitsen.

• Geaggregeerde data: vooraf samengevatte gegevens op een hoger niveau dan de bron. Statistische feitentabellen verbeteren de queryprestaties voor veelvoorkomende analytische patronen, maar beperken de vragen die gebruikers kunnen beantwoorden.

Veel organisaties onderhouden zowel atomische als statistische feitentabellen, waarbij statistische tabellen worden gebruikt als prestatieoptimalisatie, terwijl atomische details voor ad-hocanalyse behouden blijven. In Azure Databricks kunnen gerealiseerde weergaven deze samengevoegde tabellen automatisch onderhouden, waardoor ze worden vernieuwd wanneer de onderliggende atomische gegevens veranderen.

Granulariteit toepassen op dimensietabellen

Dimensietabellen hebben ook een korrel, hoewel deze anders werkt dan feitentabelkorrels. De dimensiekorrel bepaalt hoe u uw bedrijfsentiteiten vertegenwoordigt en versiet.

Voor een klantdimensie kunt u het volgende kiezen:

• Eén rij per klant: de huidige status van elke klant, bijgewerkt wanneer kenmerken veranderen (SCD-type 1).
• Eén rij per klant per versie: een nieuwe rij voor elke belangrijke wijziging, met behoud van historische statussen (SCD Type 2).
• Eén rij per klant per periode: periodieke momentopnamen die klantkenmerken met regelmatige tussenpozen vastleggen.

De dimensiekorrel die u kiest, moet overeenkomen met de korrel van de feitentabel. Als in uw feitentabel afzonderlijke transacties met surrogaatsleutels voor de klantdimensie worden bijgehouden, moet de granulariteit van uw klantdimensie die relatie ondersteunen. Een transactie die verwijst naar klantversie 5, moet die specifieke versie in de dimensietabel kunnen vinden.

Balans tussen compromissen bij het selecteren van granulariteit

Geen enkele granulariteitskeuze is universeel juist. Elke beslissing omvat afwegingen die u moet evalueren op basis van uw specifieke vereisten.

Wanneer u niet zeker weet, is het vaak veiliger om te beginnen met een fijnere granulariteit . U kunt later altijd statistische tabellen maken voor prestatieoptimalisatie, maar u kunt geen details herstellen die nooit zijn vastgelegd. In deze richtlijnen wordt echter ervan uitgegaan dat u het budget en de infrastructuur hebt om in eerste instantie nauwkeurige opslag te ondersteunen.

Als u weet hoe u de juiste granulariteit kiest, kunt u gegevensmodellen ontwerpen die de analytische behoeften van uw organisatie ondersteunen en tegelijkertijd kosten effectief beheren. De implementatiedetails voor het bouwen en laden van tabellen op de door u gekozen granulariteit in Azure Databricks worden behandeld in latere eenheden.