Copy Job is geen vereenvoudigde versie van Pipeline, maar een ander uitvoeringsmodel.
De tutorial van de Fabric Community met 28.700 weergaven beschrijft een Copy Job als 'een pipeline zonder de complexiteit'. Die omschrijving is misleidend en verklaart de meeste discussies op het forum voor kopieertaken. Een kopieeractiviteit in een pipeline is een eenmalige, stateless uitvoering: u geeft een query of een mappad mee, de job verplaatst bytes en wordt afgesloten. Een Copy Job is een stateful item met een eigen metadatastore. Deze houdt de laatste watermarkwaarde, de laatste versie van de wijzigingsregistratie en de tijdstempel van de laatste succesvolle synchronisatie per bronobject bij. Deze status wordt opgeslagen in de workspace, niet in u controletabel.
Dit is belangrijk wanneer u de job opnieuw moet uitvoeren. Bij een pipeline wijzig u de parameter en voer u de job opnieuw uit. Bij een Copy Job biedt de wizard de optie 'Resetten', maar er wordt niet vermeld dat het resetten van een incrementele Copy Job in CDC-modus vereist dat de bron-SQL Server nog steeds de oorspronkelijke change_tracking_min_valid_version beschikbaar heeft. Als de bewaartermijn is verstreken, geeft een reset geen foutmelding, er wordt stilzwijgend overgeschakeld naar een volledige snapshot bij de volgende uitvoering, wat kan betekenen dat er om 2 uur 's nachts een volledige back-up van 4 TB wordt gemaakt. De jobstatus wordt weergegeven als 'Geslaagd'.
Het tweede gedragsverschil: Kopieertaken zijn geen pipelineactiviteiten. Ze worden standaard niet in dezelfde monitoringhub-weergave weergegeven, ze verzenden andere telemetrie naar de Fabric Capacity Metrics-app en de kosten voor onelake_billable_storage worden toegewezen aan het Copy Jobitem in plaats van aan de pipeline die het heeft geactiveerd. Teams die kosten doorberekenen aan pipelineen zien het verbruik van kopieertaken pas zichtbaar wanneer ze filteren op itemtype.
Bij het selecteren van de watermerkkolom maken de meeste beginners fouten in hun gegevens.
De wizard vraagt u een incrementele kolom te kiezen. Elke kolom met een geordend gegevenstype wordt geaccepteerd. Er wordt niet gecontroleerd of de kolom monotoon, geïndexeerd of bijgewerkt is bij wijzigingen in de rij.
Drie veelvoorkomende fouten:
- Het kiezen van ModifiedDate in een SQL Server-tabel waarbij de applicatie de rij bijwerkt, maar een trigger of ORM ModifiedDate niet aanraakt. De Copy Job filtert op WHERE ModifiedDate > @lastWatermark en mist elke UPDATE. INSERTs worden correct verwerkt, waardoor de job er goed uitziet tot de reconciliatie een week later.
- Het kiezen van een IDENTITY-kolom in een tabel met READ COMMITTED SNAPSHOT-isolatie. Langlopende transacties kunnen ID's in de verkeerde volgorde vastleggen. De Copy Job verhoogt de watermark naar MAX(id) tijdens de uitvoering en filtert vervolgens bij de volgende uitvoering op WHERE id > @watermark, waardoor rijen die te laat zijn vastgelegd, worden overgeslagen.
- Het kiezen van een DATETIME-kolom (niet DATETIME2). De afronding naar 3,33 ms betekent dat rijen die binnen hetzelfde millisecondeninterval als het watermerk worden ingevoegd, worden gedupliceerd of verwijderd, afhankelijk van of de vergelijking > of >= gebruikt. De Copy Job gebruikt >, dus worden ze verwijderd.
De oplossing is niet beschikbaar in de gebruikersinterface van de Copy Job. U hebt een kolom voor rijversies nodig, een bron met CDC-ondersteuning of u moet de modus voor wijzigingsregistratie gebruiken (waarvoor sysadmin of db_owner op SQL Server deze moet inschakelen, plus een CHANGE_TRACKING_MIN_VALID_VERSION die groot genoeg is om uw worst-case uitvalperiode te dekken). Voor Fabric Warehouse- en Lakehouse-bronnen bestaan CDC noch CT nog niet, u bent aangewezen op de watermerkmodus en hebt een kolom nodig die u zelf kunt beheren.
Schrijfgedrag van de sink: Bij het samenvoegen worden volledige partities stilzwijgend overschreven.
Voor Lakehouse Delta-sinks biedt Copy Job de opties Toevoegen, Overschrijven en Samenvoegen. Samenvoegen is de standaardoptie voor incrementele taken en doet wat u logischerwijs verwacht: upsert op basis van de sleutel. Wat de documentatie echter niet vermeldt, zijn de kosten voor het herschrijven van partities.
Delta MERGE op een gepartitioneerde tabel herschrijft elke partitie die een overeenkomende rij bevat. Als u incrementele batch 1000 bijgewerkte rijen bevat, verdeeld over 400 dagelijkse partities, herschrijft de job 400 partitiebestanden. Op een tabel met 200 GB per partitie verbruikt een update van 1000 rijen 80 TB aan rekenkracht via u F64-capaciteit. De uitvoeringsduur van Copy Job verandert van 'verwacht 90 seconden' naar 'verbruikt 6 CU-uren' en activeert throttling bij de volgende Power BI refresh die de capaciteit deelt.
Drie oplossingen die de wizard niet laat zien:
- Stel de partitiekolom op de sink in zodat deze overeenkomt met het natuurlijke aankomstpatroon van u watermerk. Als het watermerk ModifiedDate is, moet er gepartitioneerd worden op ModifiedDate afgekapt tot maand en niet op een bedrijfsdimensie zoals Regio.
- Schakel verwijderingsvectoren in voor de Lakehouse-tabel (ALTER TABLE name SET TBLPROPERTIES ('delta.enableDeletionVectors' = 'true')). Dit zet MERGE-updates om van een volledige herschrijving naar een soft-delete-plus-append tot de volgende OPTIMIZE.
- Wijzig voor bronnen die alleen toevoegen het gedrag van de Copy Job sink van Merge naar Append en handel de deduplicatie verderop in een notebook af. Merge is zelden de juiste keuze wanneer de bron garandeert dat er geen updates plaatsvinden.
Throttling, HTTP 429 en de herhalingslus die fouten verbergt
De Copy Job wordt uitgevoerd tegen de Fabric-capaciteit. Wanneer de capaciteit overbelast is, retourneert de onderliggende Data Movement-service HTTP 429 met een Retry-After-header. Het standaard herhalingsbeleid van de Copy Job is 3 pogingen met exponentiële backoff vanaf 30 seconden.
De foutmodus: een extractie van een SQL Server-bron van 4 uur start om 02:00 uur. Om 03:30 uur bereikt de F64-capaciteit 110% benutting omdat een Power BI refresh is gestart. De Copy Job ontvangt 429 bij de volgende API-aanroep. De job probeert het opnieuw om 03:30:30, 03:31:30 en 03:33:30. Alle drie de pogingen resulteren in 429 omdat de Power BI refresh nog steeds bezig is. De Copy Job markeert de uitvoering als mislukt met foutcode DataMovementOperationFailed en een algemene melding 'verzoek is beperkt'. Er wordt geen UserErrorRetryableThrottlingError-code weergegeven in de uitvoer van de run, u moet het activiteitenlogboek via de Fabric REST API raadplegen om de oorzaak van de throttling te achterhalen.
Wat het nog erger maakt: in de incrementele modus wordt het watermerk bij een mislukte run niet bijgewerkt. Goed zo. Maar het zorgt er ook voor dat de rijen die al naar de Delta-sink zijn geschreven, niet worden teruggedraaid. De volgende succesvolle run begint dus bij het oorspronkelijke watermerk en voegt de reeds aanwezige rijen opnieuw samen. Met idempotente samenvoegsleutels is dit geen probleem. Met de append-modus of met niet-unieke samenvoegsleutels (de wizard dwingt uniciteit niet af) krijgt u duplicaten.
Controleer de FabricCapacityMetrics-metrieken InteractiveRequest_Throttled en BackgroundRequest_Throttled tijdens uw Copy Job-vensters. Als een van beide niet nul is, loopt uw Copy Job risico, ongeacht wat de uitvoeringsgeschiedenis laat zien.
Dit is de lacune die MetricSign dicht voor Fabric Pipelines en Copy Jobs: het platform groepeert fouten die verband houden met throttling over items met capaciteitsdeling en geeft de hoofdoorzaak weer als 'capaciteitsconflict met [specifieke Power BI-dataset]' in plaats van drie afzonderlijke generieke 429-waarschuwingen. Wanneer de watermark van een Copy Job niet verdergaat, geeft MetricSign een refresh_delayed-signaal af voor de Lakehouse-tabellen stroomafwaarts voordat het BI-team stale data opmerkt.
Het omgaan met schema driften is optioneel en niet gedocumenteerd in de beginnershandleiding.
De wizard van Copy Job bevat een stap 'Schema-mapping'. Beginners klikken op 'Automatisch toewijzen' en gaan verder. Automatisch toewijzen legt het bronschema vast op het moment dat de job wordt aangemaakt en vergrendelt dit. Wanneer de bron-DBA drie maanden later een kolom toevoegt, doet Copy Job een van de volgende twee dingen, afhankelijk van de bronconnector:
- Voor SQL Server-, Snowflake- en PostgreSQL-connectoren: de nieuwe kolom wordt stilzwijgend genegeerd. De job slaagt. De Lakehouse-tabel krijgt de kolom nooit.
- Voor Parquet-, CSV- en JSON-bestandsconnectoren: de job mislukt met ErrorCode=DelimitedTextColumnNameNotAllowNull of ErrorCode=ParquetSchemaMismatch, afhankelijk van het formaat. De foutmelding verwijst naar het bestand, niet naar de schema-mappingconfiguratie.
De oplossing in beide gevallen is om 'Schema-afwijking toestaan' in de geavanceerde instellingen van de sink in te schakelen. Deze optie is standaard uitgeschakeld. Zodra deze is ingeschakeld, worden nieuwe bronkolommen als nullable aan de Delta-sink toegevoegd. Verwijderde bronkolommen blijven in de sink (Copy Job verwijdert geen kolommen). Typewijzigingen op bestaande kolommen mislukken nog steeds, er vindt geen automatische verbreding van INT naar BIGINT plaats.
Voor betrouwbaarheid in productieomgevingen is het raadzaam om schema driften te combineren met een contractcontrole op kolomniveau voordat de Copy Job wordt uitgevoerd. Een Notebook-activiteit die INFORMATION_SCHEMA.COLUMNS op de bron opvraagt en vergelijkt met het verwachte manifest, duurt 4 seconden en voorkomt het scenario waarbij kolommen ongemerkt worden verwijderd.