Een clusterstrategie ontwerpen en implementeren

Het optimaliseren van hoe gegevens fysiek op schijf zijn georganiseerd, zijn rechtstreeks van invloed op queryprestaties en opslagefficiëntie. Wanneer u een clusterstrategie voor uw Delta Lake-tabellen ontwerpt, bepaalt u hoe de query-engine relevante gegevens zoekt en ophaalt. De juiste aanpak kan de hoeveelheid gescande gegevens tijdens query's aanzienlijk verminderen, waardoor zowel reactietijden als rekenkosten worden verlaagd.

Azure Databricks biedt verschillende aanvullende technieken voor gegevensorganisatie. Als u weet wanneer u vloeibare clustering-, Z-volgorde- of verwijderingsvectoren toepast, kunt u beslissingen nemen die de prestaties, onderhoudsinspanningen en compatibiliteit met uw bestaande tabellen in balans brengen.

Basisbeginselen van gegevens overslaan

Voordat u specifieke clusteringtechnieken onderzoekt, is het belangrijk om inzicht te hebben in het onderliggende mechanisme dat ze allemaal gebruiken: gegevens overslaan. Delta Lake verzamelt automatisch statistieken voor elk gegevensbestand, inclusief minimum- en maximumwaarden, null-aantallen en recordaantallen voor elke kolom. Wanneer u een query uitvoert met filtervoorwaarden, controleert de query-engine deze statistieken eerst en slaat de bestanden over die mogelijk geen overeenkomende records bevatten.

Als u bijvoorbeeld een query uitvoert op verkoopgegevens voor januari 2026 en de statistieken van een bepaald bestand alleen records van maart 2026 bevatten, slaat de engine dat bestand volledig over zonder de inhoud ervan te lezen. Deze optimalisatie gebeurt automatisch, maar de effectiviteit ervan is afhankelijk van hoe goed uw gegevens zijn georganiseerd.

Gegevensoverslaan wordt effectiever wanneer gerelateerde records samen worden opgeslagen in dezelfde bestanden. Als records voor elke maand willekeurig worden verspreid over alle bestanden, kan de engine geen bestanden overslaan omdat elk bestand records van elke maand bevat. Clusteringtechnieken bestaan om dit probleem precies op te lossen.

Liquid clustering implementeren voor nieuwe tabellen

Liquid clustering is de aanbevolen methode voor het ordenen van gegevens in nieuwe Delta Lake-tabellen en is ook beschikbaar in openbare preview voor beheerde Apache Iceberg-tabellen in Unity Catalog (Databricks Runtime 16.4 LTS en hoger). In tegenstelling tot traditionele partitionering kunt u met vloeistofclustering uw clusterstrategie wijzigen zonder bestaande gegevens te herschrijven. Deze flexibiliteit is waardevol wanneer querypatronen zich ontwikkelen of wanneer u niet zeker weet welke kolommen het vaakst worden gefilterd.

Als u vloeibare clustering wilt inschakelen, gebruikt u de CLUSTER BY-clausule bij het maken van een tabel.

CREATE TABLE sales.transactions (
    transaction_id STRING,
    customer_id STRING,
    product_category STRING,
    region STRING,
    transaction_date DATE,
    amount DECIMAL(12,2)
)
CLUSTER BY (region, transaction_date);

U kunt maximaal vier clustersleutels opgeven. Kies kolommen die regelmatig worden weergegeven in uw queryfilters. De volgorde van clustersleutels is minder belangrijk dan het selecteren van de juiste kolommen, omdat liquid clustering voor alle opgegeven sleutels tegelijkertijd optimaliseert.

Nadat u een geclusterde tabel hebt gemaakt, voert u de OPTIMIZE opdracht uit om clustering toe te passen op uw gegevens:

OPTIMIZE sales.transactions;

Liquide clustering is incrementeel. Elke OPTIMIZE run clustert alleen de gegevens die moeten worden gereorganiseren, waardoor regelmatig onderhoud efficiënt is. Databricks raadt u aan om elke twee uur taken te plannen OPTIMIZE voor tabellen met regelmatige invoegingen of updates.

Clusteringsleutels wijzigen wanneer dat nodig is

Een belangrijk voordeel van liquide clustering ten opzichte van partitionering is de mogelijkheid om uw clusterstrategie te wijzigen. Als uw querypatronen veranderen, werkt u de clustersleutels bij met een ALTER TABLE instructie:

ALTER TABLE sales.transactions
CLUSTER BY (customer_id, transaction_date);

Volgende OPTIMIZE bewerkingen maken gebruik van de nieuwe clusteringbenadering. Eerder geschreven gegevens worden niet automatisch opnieuw geschreven. Als u nieuwe clustering wilt toepassen op alle bestaande gegevens, voert u het volgende uit:

OPTIMIZE sales.transactions FULL;

Automatische clusteringsleutelselectie inschakelen

Azure Databricks kan op intelligente wijze clustersleutels selecteren op basis van uw werkelijke querypatronen. Automatische vloeistofclustering analyseert de werkbelastinggeschiedenis en kiest kolommen die het grootste voordeel bieden bij het overslaan van gegevens:

CREATE TABLE sales.orders CLUSTER BY AUTO;

U kunt automatische clustering inschakelen voor bestaande tabellen:

ALTER TABLE sales.transactions CLUSTER BY AUTO;

Automatische vloeistofclustering vereist dat voorspellende optimalisatie is ingeschakeld. Azure Databricks evalueert periodiek of verschillende clusteringsleutels de prestaties zouden verbeteren en past de strategie dienovereenkomstig aan.

Migreren van Z-volgorde naar liquide clustering

Z-ordering is een verouderde techniek waarmee gegevens worden georganiseerd om gerelateerde informatie in dezelfde bestanden te plaatsen. Hoewel liquide clustering wordt aanbevolen voor nieuwe tabellen, zult u bestaande tabellen tegenkomen die gebruikmaken van Z-volgorde en die beide benaderingen moeten begrijpen.

Z-ordering maakt gebruik van de OPTIMIZE opdracht met een ZORDER BY component:

OPTIMIZE sales.legacy_transactions
ZORDER BY (region, transaction_date);

Z-volgorde verschilt van liquid clustering op verschillende belangrijke manieren:

Wanneer u een tabel met Z-volgorde overdraft, hebt u twee opties. Blijf Z-volgorde gebruiken voor consistentie of migreren naar liquide clustering voor verbeterde flexibiliteit. Als u wilt migreren, schakelt u eerst liquide clustering in op de bestaande niet-gepartitioneerde tabel:

ALTER TABLE sales.legacy_transactions
CLUSTER BY (region, transaction_date);

Voer vervolgens een volledige optimalisatie uit om alle bestaande gegevens opnieuw in te delen:

OPTIMIZE sales.legacy_transactions FULL;

Verwijderingsvectoren beheren voor efficiënte updates

Verwijderingsvectoren hebben betrekking op een ander aspect van de gegevensorganisatie: hoe Delta Lake gewijzigde of verwijderde records verwerkt. Wanneer u standaard één rij in een Parquet-bestand bijwerkt of verwijdert, moet Delta Lake het hele bestand opnieuw schrijven. Voor tabellen met frequente wijzigingen zorgt dit voor aanzienlijke overhead.

Als verwijderingsvectoren zijn ingeschakeld, markeert Delta Lake gewijzigde rijen als verwijderd in een afzonderlijk metagegevensbestand in plaats van het Parquet-bestand onmiddellijk opnieuw te schrijven. Volgende leesbewerkingen passen deze verwijderingen onmiddellijk toe, waarbij het oorspronkelijke bestand wordt gecombineerd met de verwijderingsvector om nauwkeurige resultaten te retourneren.

Verwijderingsvectoren zijn standaard ingeschakeld voor nieuwe tabellen die zijn gemaakt met Databricks Runtime 14.1 of hoger. U kunt ze expliciet inschakelen voor bestaande tabellen:

ALTER TABLE sales.transactions
SET TBLPROPERTIES ('delta.enableDeletionVectors' = true);

Verwijderingsvectoren worden fysiek toegepast wanneer de gegevensbestanden worden herschreven tijdens:

• Een OPTIMIZE opdracht
• Triggers voor automatische compressie
• Een REORG TABLE ... APPLY (PURGE) bewerking

Voor nalevingsscenario's waarbij u ervoor moet zorgen dat verwijderde gegevens fysiek worden verwijderd, voert u een REORG bewerking uit, gevolgd door VACUUM:

REORG TABLE sales.transactions APPLY (PURGE);
VACUUM sales.transactions;

Met verwijderingsvectoren kunnen ook gelijktijdigheid op rijniveau worden ingeschakeld, waardoor meerdere gelijktijdige transacties verschillende rijen in dezelfde tabel kunnen wijzigen zonder conflicten. Deze mogelijkheid is met name waardevol voor tabellen met grote updatevolumes.