Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Notitie
Databricks raadt vloeibare clustering aan voor alle beheerde tabellen. Voor beheerde tabellen met Apache Iceberg ondersteunt Unity Catalog alleen vloeibare clustering en interpreteert kolommen als clustersleutels PARTITION BY . Zie Een gepartitioneerde tabel converteren naar liquide clustering.
De meeste tabellen op Azure Databricks met minder dan 100 TB aan gegevens hebben geen partitionering nodig. Azure Databricks gebruikt standaard Delta Lake voor alle tabellen en clustert gegevens in niet-gepartitioneerde tabellen automatisch op opnametijd, zodat u partitioneringsachtige prestaties krijgt zonder handmatige afstemming. Overweeg alleen een aangepaste partitioneringsstrategie als deze beter presteert dan deze standaardopties. Zie Opnametijdclustering gebruiken.
Strategieën voor aangepaste partitionering
Geavanceerde gebruikers van Apache Spark en Delta Lake kunnen een partitioneringsstrategie identificeren die beter presteert dan de standaardopnametijdclustering.
Warning
Een ineffectieve partitioneringsstrategie kan een negatieve invloed hebben op de prestaties van query's en een volledig herschrijven van gegevens vereisen om dit op te lossen. Een volledig herschrijven kan erg duur en traag zijn voor grote tabellen.
Voordat u aangepaste partitioneringsstrategieën gebruikt, raadt Databricks vloeibare clustering aan voor alle tabellen en voorspellende optimalisatie voor beheerde tabellen in Unity Catalog. Zie Liquid Clustering gebruiken voor tabellen en Voorspellende optimalisatie voor beheerde tabellen in Unity Catalog.
Als u een bestaande gepartitioneerde Delta Lake-tabel wilt converteren naar liquide clustering, gebruikt u ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BY. Liquid clustering werkt zowel voor kolommen met lage als hoge kardinaliteit en voorkomt de vaste partitiegrenzen en problemen met kleine bestanden die vaak voorkomen bij statische partitionering. Zie Een gepartitioneerde tabel converteren naar liquide clustering.
Ondersteunde gegevenstypen voor partitiekolommen
Partitionering ondersteunt deze gegevenstypen voor partitiekolommen:
- Datum
- Tijdstempel
- TimestampNTZ
- Tijdsegment
- Snaar / Touwtje
- Binary
- Boolean
- Geheel getal, lang, kort, byte
- Float, Double, Decimal
Partitiekolommen moeten kolommen op het hoogste niveau zijn. U kunt niet partitioneren op een van de volgende manieren:
- Complexe typen, zoals
StructType,MapType,ArrayTypeofVariantType - Struct-velden, zoals
struct_col.field. Delta Lake behandelt een struct-veldPARTITIONED BYals een expressie in plaats van een kolomreferentie.
Als u een tabel wilt ordenen op basis van een structveld, gebruikt u in plaats daarvan liquide clustering, waarmee een structveld wordt herkend als een clusteringsleutel. Liquid clustering is de enige manier om gegevens over te slaan op een structveld zonder het eerst te extraheren in een kolom op het hoogste niveau. Zie Liquid Clustering gebruiken voor tabellen.
Aanbevelingen voor minimale grootte
Partitionering onder deze minimale grootten heeft waarschijnlijk een negatieve invloed op de prestaties van query's in plaats van deze te verbeteren. Houd rekening met het volgende wanneer u besluit of u een tabel wilt partitioneren:
- Voor tabellen:
- Partitioneer niet met minder dan 1 TB aan gegevens.
- Gebruik met meer dan 1 TB tot 100 TB aan gegevens liquide clustering in plaats van partitionering. Partitionering heeft waarschijnlijk een negatieve invloed op de prestaties dan het helpt.
- Met 100 TB of meer gegevens kan partitionering de prestaties verbeteren, maar Databricks raadt aan eerst liquid clustering te gebruiken en prestatieverbeteringen te controleren.
- Controleer voor partities of elke partitie ten minste 1 GB aan gegevens bevat. Tabellen met minder, grotere partities presteren meestal beter dan tabellen met veel kleinere partities.
Opnametijdclustering gebruiken
Door Delta Lake te gebruiken, maken niet-gepartitioneerde tabellen automatisch gebruik van opnametijdclustering. Opnametijd heeft verbeteringen in queryprestaties die vergelijkbaar zijn met partitioneringsstrategieën met datum/tijd-velden, zonder dat u uw gegevens handmatig hoeft te optimaliseren of af te stemmen.
Notitie
Als u opnametijdclustering wilt behouden bij het uitvoeren van een groot aantal wijzigingen met behulp van UPDATE- of MERGE-instructies op een tabel, raadt Databricks aan om liquid clustering te gebruiken op een kolom die overeenkomt met de opnamevolgorde, zoals een tijdstempel van gebeurtenissen of een aanmaakdatum. Zie Liquid Clustering gebruiken voor tabellen.
Compatibiliteit met Delta Lake- en Parquet-partitionering
Delta Lake maakt gebruik van Parquet voor het opslaan van gegevens en sommige gepartitioneerde Delta Lake-tabellen hebben gegevensindelingen die vergelijkbaar zijn 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 mogen niet afhankelijk zijn van deze partitioneringsstrategie om te communiceren met Delta Lake-tabellen.
Databricks raadt u aan om te communiceren met gegevens die zijn opgeslagen in Delta Lake met behulp van officieel ondersteunde clients en API's. Veel Delta Lake-functies breken veronderstellingen over de gegevensindeling die mogelijk zijn gebruikt met Parquet-, Hive- of zelfs eerdere Delta Lake-protocolversies.
Notitie
Wanneer u kolomtoewijzing inschakelt voor een Delta Lake-tabel, worden kolomnamen in partitiemappen bij partitionering in Hive-stijl vervangen door willekeurige voorvoegsels. Zie Kolommen hernoemen en verwijderen met kolomtoewijzing van Delta Lake.
Het partitioneren van Delta Lake vergeleken met andere data lakes
Partitioneringstechnieken die nuttig zijn in andere open source-technologieën (zoals Apache Spark, Parquet, Hive en Hadoop), zijn niet altijd waar voor Azure Databricks. Als u ervoor kiest om de tabel te partitioneren, kunt u het volgende overwegen:
- Transacties worden niet gedefinieerd door partitiegrenzen. Omdat Delta Lake zorgt voor ACID via transactielogboeken, hoeft u geen batch met gegevens te scheiden door een partitie om atomiciteit te garanderen.
- Azure Databricks-rekenclusters hebben geen gegevenslocatie die is gekoppeld aan fysieke media. Gegevens die in de lakehouse worden opgenomen, worden opgeslagen in cloudobjectopslag. 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.
Z-volgorde en partities
Notitie
Databricks raadt vloeibare clustering aan via Z-volgorde voor alle nieuwe tabellen. Zie Liquid Clustering gebruiken voor tabellen.
U kunt Z-orderindexen naast partities gebruiken om query's op grote gegevenssets te versnellen. De meeste tabellen maken gebruik van opnametijdclustering om te voorkomen dat u Z-volgorde en partities hoeft af te stemmen.
Houd rekening met de volgende regels wanneer u een strategie voor queryoptimalisatie plant op basis van partitiegrenzen en Z-volgorde:
- Voor Z-order is de
OPTIMIZEopdracht vereist. 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.
Hoe Azure Databricks optimaliseert rond bestaande partities
Veel klanten migreren naar Delta Lake vanuit op Parquet gebaseerde data lakes, zoals het gebruik van de CONVERT TO DELTA instructie om een bestaande Parquet-tabel te converteren naar een Delta Lake-tabel zonder bestaande gegevens opnieuw te schrijven. Omdat de conversie bestaande gegevens niet herschrijft, kunnen grote tabellen eerdere partitioneringsstrategieën overnemen.
Sommige Databricks-optimalisaties gebruiken deze partities indien mogelijk, waardoor negatieve prestatie-effecten worden beperkt voor partitioneringsstrategieën die niet zijn geoptimaliseerd voor Delta Lake.
Delta Lake en Apache Spark zijn opensourcetechnologieën. Hoewel Databricks functies heeft die de afhankelijkheid van partitionering verminderen, kan de open source community nieuwe functies bouwen die complexiteit toevoegen.