Optimalisatie van Delta Lake-tabellen en V-order
De Lakehouse en de Delta Lake tabelindeling staan centraal in Microsoft Fabric, aangezien het optimaliseren van tabellen voor analyse een belangrijke vereiste is. In deze handleiding worden concepten en configuraties voor optimalisatie van Delta Lake-tabellen besproken en hoe deze kunnen worden toegepast op de meest voorkomende big data-gebruikspatronen.
Wat is V-Order?
V-Order is een optimalisatie van schrijftijd voor de Parquet-bestandsindeling waarmee razendsnelle leesbewerkingen mogelijk zijn onder de Microsoft Fabric-rekenengines, zoals Power BI, SQL, Spark en andere.
Power BI- en SQL-engines maken gebruik van Microsoft Verti-Scan-technologie en V-Geordende parquet-bestanden om toegangstijden voor gegevens te bereiken die lijken op die van in-memory toegang. Spark en andere niet-Verti-Scan-rekenprogramma's profiteren ook van de V-Geordende bestanden met gemiddeld 10% snellere leestijden, met sommige scenario's tot 50%.
V-Order werkt door speciale sortering, rijgroepdistributie, woordenlijstcodering en compressie toe te passen op Parquet-bestanden, waardoor er minder netwerk-, schijf- en CPU-resources in rekenprogramma's nodig zijn om deze te lezen, waardoor kostenefficiëntie en prestaties worden geboden. Sorteren in V-volgorde heeft een invloed van 15% op de gemiddelde schrijftijden, maar biedt maximaal 50% meer compressie.
Het is 100% opensource parquet-indeling compatibel; alle parquet-engines kunnen het lezen als gewone Parquet-bestanden. Delta-tabellen zijn efficiënter dan ooit; functies zoals Z-Order zijn compatibel met V-Order. Tabeleigenschappen en optimalisatieopdrachten kunnen worden gebruikt om de V-volgorde van de partities te beheren.
V-Order wordt toegepast op het niveau van het parquet-bestand. Delta-tabellen en de kenmerken, zoals Z-Order, compressie, vacuüm, tijdreizen, enz. zijn orthogonaal naar V-Order, als zodanig compatibel en kunnen samen worden gebruikt voor extra voordelen.
Schrijfbewerkingen in V-volgorde beheren
V-Order is standaard ingeschakeld in Microsoft Fabric en in Apache Spark wordt het gecontroleerd door de volgende configuraties.
Configuratie | Standaardwaarde | Beschrijving |
---|---|---|
spark.sql.parquet.vorder.default | waar | Beheert het schrijven van V-volgorde op sessieniveau. |
TBLPROPERTIES("delta.parquet.vorder.default") | onwaar | Standaardmodus V-Order voor tabellen |
Dataframe writer-optie: parquet.vorder.default | niet ingesteld | Beheer V-volgorde schrijfbewerkingen met Dataframe Writer |
Gebruik de volgende opdrachten om het gebruik van V-Order-schrijfbewerkingen te beheren.
Configuratie van V-volgorde controleren in Apache Spark-sessie
%%sql
SET spark.sql.parquet.vorder.default
V-order schrijven uitschakelen in Apache Spark-sessie
%%sql
SET spark.sql.parquet.vorder.default=FALSE
Schakel het V-Order schrijven in binnen de Apache Spark-sessie
Belangrijk
Wanneer deze optie is ingeschakeld op sessieniveau. Alle Parquet-schrijfbewerkingen worden gemaakt met V-Order ingeschakeld. Dit omvat niet-Delta parquet-tabellen en Delta-tabellen waarbij de parquet.vorder.default
tabeleigenschap is ingesteld op true
of false
.
%%sql
SET spark.sql.parquet.vorder.default=TRUE
V-volgorde beheren met deltatabeleigenschappen
Schakel de tabeleigenschap V-order in tijdens het maken van de tabel:
%%sql
CREATE TABLE person (id INT, name STRING, age INT) USING parquet TBLPROPERTIES("delta.parquet.vorder.default" = "true");
Belangrijk
Wanneer de tabeleigenschap is ingesteld op true, gedragen de opdrachten INSERT, UPDATE en MERGE zich zoals verwacht en worden de optimalisatie van schrijftijd uitgevoerd. Als de configuratie van de V-Order-sessie is ingesteld op 'true' of als spark.write is ingeschakeld, dan zullen de schrijfbewerkingen V-Order zijn, zelfs als de TBLPROPERTIES is ingesteld op 'false'.
Schakel V-Order in of uit door de tabeleigenschap te wijzigen:
%%sql
ALTER TABLE person SET TBLPROPERTIES("delta.parquet.vorder.default" = "true");
ALTER TABLE person SET TBLPROPERTIES("delta.parquet.vorder.default" = "false");
ALTER TABLE person UNSET TBLPROPERTIES("delta.parquet.vorder.default");
Nadat u V-Order met tabeleigenschappen hebt ingeschakeld of uitgeschakeld, worden alleen toekomstige schrijfbewerkingen naar de tabel beïnvloed. Parquet-bestanden behouden de volgorde die wordt gebruikt toen deze werd gemaakt. Als u de huidige fysieke structuur wilt wijzigen om V-Volgorde toe te passen of te verwijderen, leest u de sectie 'V-Volgorde beheren bij het optimaliseren van een tabel' hieronder.
V-order rechtstreeks beheren voor schrijfbewerkingen
Alle Apache Spark-schrijfopdrachten nemen de sessie-instelling over als deze niet expliciet is. Alle volgende opdrachten schrijven met V-Order door impliciet de sessieconfiguratie over te nemen.
df_source.write\
.format("delta")\
.mode("append")\
.saveAsTable("myschema.mytable")
DeltaTable.createOrReplace(spark)\
.addColumn("id","INT")\
.addColumn("firstName","STRING")\
.addColumn("middleName","STRING")\
.addColumn("lastName","STRING",comment="surname")\
.addColumn("birthDate","TIMESTAMP")\
.location("Files/people")\
.execute()
df_source.write\
.format("delta")\
.mode("overwrite")\
.option("replaceWhere","start_date >= '2017-01-01' AND end_date <= '2017-01-31'")\
.saveAsTable("myschema.mytable")
Belangrijk
V-Order is alleen van toepassing op bestanden die worden beïnvloed door het predicaat.
In een sessie waarbij spark.sql.parquet.vorder.default
niet is ingesteld of ingesteld is op false, worden de volgende opdrachten uitgevoerd met behulp van V-Order.
df_source.write\
.format("delta")\
.mode("overwrite")\
.option("replaceWhere","start_date >= '2017-01-01' AND end_date <= '2017-01-31'")\
.option("parquet.vorder.default ","true")\
.saveAsTable("myschema.mytable")
DeltaTable.createOrReplace(spark)\
.addColumn("id","INT")\
.addColumn("firstName","STRING")\
.addColumn("middleName","STRING")\
.addColumn("lastName","STRING",comment="surname")\
.addColumn("birthDate","TIMESTAMP")\
.option("parquet.vorder.default","true")\
.location("Files/people")\
.execute()
Wat is Schrijfbewerking optimaliseren?
Analytische workloads op big data-verwerkingsengines zoals Apache Spark presteren het meest efficiënt wanneer u gestandaardiseerde grotere bestandsgrootten gebruikt. De relatie tussen de bestandsgrootte, het aantal bestanden, het aantal Spark-werkrollen en de configuraties, speelt een belangrijke rol bij de prestaties. Het opnemen van gegevens in Data Lake-tabellen kan het overgenomen kenmerk hebben van het voortdurend schrijven van veel kleine bestanden; dit scenario wordt meestal het 'probleem met kleine bestanden' genoemd.
Optimaliseren van schrijfopdrachten is een Delta Lake-functie binnen Microsoft Fabric en Azure Synapse Analytics in de Apache Spark-engine die het aantal geschreven bestanden vermindert en het doel heeft om de individuele bestandsgrootte van de geschreven gegevens te vergroten. De grootte van het doelbestand kan worden gewijzigd per workload met behulp van configuraties.
De functie is standaard ingeschakeld in Microsoft Fabric Runtime voor Apache Spark. Lees het artikel De noodzaak voor het optimaliseren van schrijfbewerkingen op Apache Spark voor meer informatie over scenario's voor het optimaliseren van schrijfgebruik.
Samenvoegoptimalisatie
Met de opdracht Delta Lake MERGE kunnen gebruikers een deltatabel bijwerken met geavanceerde voorwaarden. Met de opdracht MERGE kunt u gegevens uit een brontabel, weergave of DataFrame bijwerken in een doeltabel. Het huidige algoritme in de opensource-distributie van Delta Lake is echter niet volledig geoptimaliseerd voor het verwerken van ongewijzigde rijen. Het Microsoft Spark Delta-team heeft een aangepaste optimalisatie van Low Shuffle Merge geïmplementeerd. Niet-aangepaste rijen worden uitgesloten van een dure shuffling-bewerking die nodig is voor het bijwerken van overeenkomende rijen.
De implementatie wordt beheerd door de spark.microsoft.delta.merge.lowShuffle.enabled
configuratie, die standaard is ingeschakeld in de runtime. Er zijn geen codewijzigingen vereist en is volledig compatibel met de opensource-distributie van Delta Lake. Lees het artikel Low Shuffle Merge optimalisatie voor Delta-tabellen om meer te weten te komen over de gebruiksscenario's van Low Shuffle Merge.
Onderhoud van Delta-tabellen
Naarmate deltatabellen veranderen, verminderen de prestaties en de efficiëntie van de opslagkosten om de volgende redenen:
- Nieuwe gegevens die aan de tabel worden toegevoegd, kunnen de gegevens vertekenen.
- Batch- en streaminggegevensopnamesnelheden kunnen veel kleine bestanden opleveren.
- Bijwerk- en verwijderbewerkingen veroorzaken uiteindelijk extra leesbelasting; Parquet-bestanden zijn standaard onveranderbaar, dus Delta-tabellen voegen nieuwe Parquet-bestanden toe met de wijzigingenset, waardoor de problemen die door de eerste twee items worden opgelegd, worden verergerd.
- Er zijn geen gegevensbestanden en logboekbestanden meer nodig die beschikbaar zijn in de opslag.
Als u de tabellen in de beste staat wilt houden voor de beste prestaties, voert u bin-compactie- en vacuümbewerkingen uit in de Delta-tabellen. Bin-compactie wordt gerealiseerd met de opdracht OPTIMIZE; hiermee worden alle wijzigingen samengevoegd in grotere, geconsolideerde parquet-bestanden. Het opschonen van dereferencing van opslag wordt uitgevoerd met het commando VACUUM.
De tabelonderhoudsopdrachten OPTIMALISEREN en VACUUM kunnen worden gebruikt in notebooks en Spark-taakdefinities en vervolgens ingedeeld met behulp van platformmogelijkheden. Lakehouse in Fabric biedt de mogelijkheid om via de gebruikersinterface ad-hoc tabelonderhoud uit te voeren, zoals uitgelegd in het artikel over Delta Lake-tabelonderhoud.
Belangrijk
Het correct ontwerpen van de fysieke tabelstructuur, op basis van de opnamefrequentie en de verwachte leespatronen, is waarschijnlijk belangrijker dan het uitvoeren van de optimalisatieopdrachten die in deze sectie worden beschreven.
V-volgorde beheren bij het optimaliseren van een tabel
De volgende commando's voeren bin-compact uit en herschrijven alle betrokken bestanden met behulp van V-Order, onafhankelijk van de TBLPROPERTIES-instelling of sessieconfiguratie-instelling:
%%sql
OPTIMIZE <table|fileOrFolderPath> VORDER;
OPTIMIZE <table|fileOrFolderPath> WHERE <predicate> VORDER;
OPTIMIZE <table|fileOrFolderPath> WHERE <predicate> [ZORDER BY (col_name1, col_name2, ...)] VORDER;
Wanneer ZORDER en VORDER samen worden gebruikt, voert Apache Spark opeenvolgend bin-compactie, ZORDER en VORDER uit.
De volgende opdrachten comprimeren en herschrijven alle betrokken bestanden met behulp van de TBLPROPERTIES-instelling. Als TBLPROPERTIES is ingesteld op true voor V-Order, worden alle betrokken bestanden geschreven als V-Order. Als TBLPROPERTIES niet is ingesteld of is ingesteld op onwaar op V-Order, neemt deze de sessie-instelling over; Als u V-Order uit de tabel wilt verwijderen, stelt u de sessieconfiguratie in op false.
%%sql
OPTIMIZE <table|fileOrFolderPath>;
OPTIMIZE <table|fileOrFolderPath> WHERE predicate;
OPTIMIZE <table|fileOrFolderPath> WHERE predicate [ZORDER BY (col_name1, col_name2, ...)];