Wanneer moet u tabellen partitioneren in Azure Databricks

Notitie

Databricks raadt het gebruik van vloeibare clustering aan voor alle nieuwe Delta-tabellen. Zie Liquid clustering gebruiken voor Delta-tabellen.

Liquide clusters worden soms ook wel 'liquid partitions' genoemd. Dit artikel verwijst alleen naar verouderde Delta-partitionering en niet naar liquide clustering.

Dit artikel bevat een overzicht van hoe u tabellen kunt partitioneren in Azure Databricks en specifieke aanbevelingen over wanneer u partitionering moet gebruiken voor tabellen die worden ondersteund door Delta Lake. Vanwege ingebouwde functies en optimalisaties hebben de meeste tabellen met minder dan 1 TB aan gegevens geen partities nodig.

Azure Databricks maakt standaard gebruik van Delta Lake voor alle tabellen. Bij de volgende aanbevelingen wordt ervan uitgegaan dat u voor alle tabellen met Delta Lake werkt.

In Databricks Runtime 11.3 LTS en hoger clustert Azure Databricks automatisch gegevens in niet-gepartitioneerde tabellen door opnametijd. Zie Opnametijdclustering gebruiken.

Moeten kleine tabellen worden gepartitioneerd?

Databricks raadt u aan geen tabellen te partitioneren die minder dan een terabyte aan gegevens bevatten.

Wat is de minimale grootte voor elke partitie in een tabel?

Databricks raadt alle partities aan ten minste een gigabyte aan gegevens te bevatten. Tabellen met minder, grotere partities presteren meestal beter dan tabellen met veel kleinere partities.

Opnametijdclustering gebruiken

Door Delta Lake en Databricks Runtime 11.3 LTS of hoger te gebruiken, profiteren niet-gepartitioneerde tabellen die u maakt automatisch van opnametijdclustering. Opnametijd biedt vergelijkbare queryvoordelen als partitioneringsstrategieën op basis van datum/tijd-velden zonder dat u uw gegevens hoeft te optimaliseren of af te stemmen.

Notitie

Als u opnametijdclustering wilt behouden wanneer u een groot aantal wijzigingen uitvoert met behulp UPDATE van of MERGE instructies in een tabel, raadt Databricks aan om te worden uitgevoerd OPTIMIZE met behulp van een kolom die overeenkomt met ZORDER BY de opnamevolgorde. Dit kan bijvoorbeeld een kolom zijn met een tijdstempel voor gebeurtenissen of een aanmaakdatum.

Delen Delta Lake en Parquet partitioneringsstrategieën?

Delta Lake maakt gebruik van Parquet als de primaire indeling voor het opslaan van gegevens en sommige Delta-tabellen met partities die zijn opgegeven, demonstreren de organisatie die vergelijkbaar is met Parquet-tabellen die zijn opgeslagen met Apache Spark. Apache Spark maakt gebruik van Hive-stijl partitionering bij het opslaan van gegevens in Parquet-indeling. Partitionering in Hive-stijl maakt geen deel uit van het Delta Lake-protocol en workloads moeten niet afhankelijk zijn van deze partitioneringsstrategie om te communiceren met Delta-tabellen.

Veel Delta Lake-functies breken veronderstellingen over de gegevensindeling die mogelijk zijn overgedragen vanuit Parquet-, Hive- of zelfs eerdere Delta Lake-protocolversies. U moet altijd communiceren met gegevens die zijn opgeslagen in Delta Lake met behulp van officieel ondersteunde clients en API's.

Hoe verschillen Delta Lake-partities van partities in andere data lakes?

Hoewel Azure Databricks en Delta Lake voortbouwen op opensourcetechnologieën zoals Apache Spark, Parquet, Hive en Hadoop, zijn partitioneringsmotieven en strategieën die nuttig zijn in deze technologieën doorgaans niet waar voor Azure Databricks. Als u ervoor kiest om uw tabel te partitioneren, moet u rekening houden met de volgende feiten voordat u een strategie kiest:

• Transacties worden niet gedefinieerd door partitiegrenzen. Delta Lake zorgt voor ACID via transactielogboeken, dus u hoeft geen batch met gegevens te scheiden door een partitie om atomische detectie te garanderen.
• Azure Databricks-rekenclusters hebben geen gegevenslocatie die is gekoppeld aan fysieke media. Gegevens die in lakehouse worden opgenomen, worden opgeslagen in de opslag van cloudobjecten. Terwijl gegevens tijdens gegevensverwerking in de cache worden opgeslagen in de lokale schijfopslag, maakt Azure Databricks gebruik van op bestanden gebaseerde statistieken om de minimale hoeveelheid gegevens te identificeren voor parallel laden.

Hoe werken Z-volgorde en partities samen?

U kunt Z-orderindexen naast partities gebruiken om query's op grote gegevenssets te versnellen.

Notitie

De meeste tabellen kunnen gebruikmaken van opnametijdclustering om te voorkomen dat u zich zorgen hoeft te maken over Z-volgorde en partitionering.

De volgende regels zijn belangrijk om rekening mee te houden bij het plannen van een strategie voor queryoptimalisatie op basis van partitiegrenzen en Z-volgorde:

• Z-order werkt samen met de OPTIMIZE opdracht. U kunt bestanden niet combineren tussen partitiegrenzen en dus kan Z-orderclustering alleen plaatsvinden binnen een partitie. Voor niet-gepartitioneerde tabellen kunnen bestanden in de hele tabel worden gecombineerd.
• Partitionering werkt alleen goed voor velden met een lage of bekende kardinaliteit (bijvoorbeeld datumvelden of fysieke locaties), maar niet voor velden met een hoge kardinaliteit, zoals tijdstempels. Z-order werkt voor alle velden, waaronder velden met hoge kardinaliteit en velden die oneindig kunnen groeien (bijvoorbeeld tijdstempels of de klant-id in een transactie- of ordertabel).
• U kunt geen Z-volgorde voltooien voor velden die worden gebruikt voor partitionering.

Als partities zo slecht zijn, waarom gebruiken sommige Azure Databricks-functies deze dan?

Partities kunnen nuttig zijn, met name voor zeer grote tabellen. Veel prestatieverbeteringen voor partitionering richten zich op zeer grote tabellen (honderden terabytes of hoger).

Veel klanten migreren naar Delta Lake vanuit data lakes op basis van Parquet. Met de CONVERT TO DELTA instructie kunt u een bestaande Parquet-tabel converteren naar een Delta-tabel zonder bestaande gegevens opnieuw te schrijven. Daarom hebben veel klanten grote tabellen die eerdere partitioneringsstrategieën overnemen. Sommige optimalisaties die door Databricks zijn ontwikkeld, proberen deze partities waar mogelijk te benutten, waardoor een aantal mogelijke nadelen worden beperkt voor partitioneringsstrategieën die niet zijn geoptimaliseerd voor Delta Lake.

Delta Lake en Apache Spark zijn opensourcetechnologieën. Hoewel Databricks nog steeds functies introduceert die de afhankelijkheid van partitionering verminderen, kan de opensource-community nieuwe functies blijven bouwen die complexiteit toevoegen.

Is het mogelijk om ingebouwde optimalisaties van Azure Databricks te verbeteren met aangepaste partitionering?

Sommige ervaren gebruikers van Apache Spark en Delta Lake kunnen mogelijk een patroon ontwerpen en implementeren dat betere prestaties biedt dan opnametijdclustering. Het implementeren van een slechte partitioneringsstatus kan zeer negatieve gevolgen hebben voor downstreamprestaties en kan een volledige herschrijf van gegevens vereisen om te herstellen. Databricks raadt aan dat de meeste gebruikers standaardinstellingen gebruiken om dure inefficiënties te voorkomen.