Microsoft Fabric-Copy Job: Waar het misgaat in een productieomgeving

De functie Copy Job slaat intern incrementele watermark-status op. Je kiest een kolom – meestal een LastModified-kolom of een integer-ID – en Fabric houdt de hoogste watermark bij tussen de uitvoeringen. De gebruikersinterface toont één enkele waarde. Er is geen zichtbare controletabel, geen auditrij waarop u kunt SELECTeren en geen native manier om de watermark terug te draaien zonder de job opnieuw aan te maken.

Dit is belangrijk wanneer de klok van de bron niet synchroon loopt of wanneer een upstream-job records aanvult met tijdstempels die eerder zijn dan de huidige watermark. Copy Job zal die rijen niet meenemen. De uitvoering is voltooid. Aantal gelezen rijen: 0. Aantal geschreven rijen: 0. Status: Geslaagd. Drie weken later merkt iemand op dat er 14.000 records ontbreken in de tabel dim_customer die wel in de bron aanwezig zijn.

De tweede mogelijke fout: typefout in de watermark-kolom. Als uw bronkolom van het type datetime2(7) is en Fabric dit interpreteert als datetime, kan de afkapping ervoor zorgen dat de vergelijking WHERE LastModified > @watermark rijen overslaat waarvan de precisie tot op de seconde nauwkeurig binnen dezelfde seconde valt als de maximale waarde van de vorige run. Dit ziet u niet in de uitvoeringsgeschiedenis. U ziet het wel wanneer het aantal rijen afwijkt van het bronsysteem.

De praktische oplossing is om nooit alleen op het interne watermerk te vertrouwen. Voer dagelijks een reconciliatiequery uit op de bron — SELECT COUNT(*), MAX(LastModified) FROM source.table, en vergelijk deze met de bestemming. Als het verschil twee dagen achter elkaar de drempelwaarde overschrijdt, beschouw de Copy Job dan als mislukt, ongeacht de groene status. Dit is een vergelijkbaar probleem als een Power BI-datasetrefresh die succesvol wordt voltooid met een verouderde gatewaycache: het platform meldt succes omdat de uitgevoerde bewerking niet is mislukt.

Wanneer een bron een kolom toevoegt, hangt het standaardgedrag van de Copy Job af van de toewijzingsmodus. Met automatische toewijzing ingeschakeld en 'Schemaverschuiving toestaan' aan, wordt de nieuwe kolom overgenomen. Bij expliciete toewijzingen wordt de nieuwe kolom stilzwijgend verwijderd. In beide gevallen wordt een foutmelding gegenereerd.

Het gevaarlijkere geval is typevernauwing. Een bronkolom verandert van int naar bigint omdat iemand de grens van 2,1 miljard heeft bereikt. De toewijzing van Fabric blijft int aangeven. De Copy Job blijft draaien. Rijen waarvan de waarde groter is dan 2^31 mislukken bij het schrijven naar individuele rijen, maar als 'fouttolerantie' is ingesteld op het overslaan van incompatibele rijen (de standaardinstelling in veel sjablonen), worden deze fouten vastgelegd in een bestand met overgeslagen rijen op de staginglocatie en wordt de activiteit als succesvol gerapporteerd.

Controleer de JSON met uitvoeringsdetails voor de tellers dataConsistencyVerification en dataInconsistency. Het portaal toont 'Gelezen rijen' en 'Geschreven rijen' prominent, maar het aantal overgeslagen rijen wordt in een subpaneel weergegeven. Als rows_read - rows_written > 0 en u geen deduplicatie hebt geconfigureerd, treedt er ongemerkt gegevensverlies op.

Voor een PostgreSQL-bron – en volgens een onderzoek van Stack Overflow uit 2024 werkt 51,9% van de professionele ontwikkelaars met PostgreSQL – gebruikt Copy Job de npgsql-driver. Numerieke kolommen zonder expliciete precisie worden standaard toegewezen aan decimal(38,18), waardoor alles wat breder is, wordt afgekapt. SQL Server-bronnen ondervinden een vergelijkbaar probleem met sql_variant-kolommen, die worden geconverteerd naar nvarchar(max) en hun onderliggende type-metadata verliezen.

De verdedigbare aanpak is om het bestemmingsschema te vergrendelen met expliciete Delta-tabel-DDL, Copy Job zo in te stellen dat het mislukt bij een schema-mismatch in plaats van te converteren en elke DDL-wijziging in de bron te behandelen als een implementatie die een update van de jobtoewijzing vereist. Schema-on-read is prima voor verkennend onderzoek. Het is echter niet geschikt voor de tabel die het managementdashboard voedt.

Het standaard herhaalbeleid van de Copy Job is 3 pogingen met intervallen van 30 seconden bij tijdelijke fouten. Fouten die als tijdelijk worden geclassificeerd, zijn onder andere netwerktime-outs, beperkte reacties (HTTP 429, 503) en de algemene foutcode UserErrorFailedToConnectToSqlServer wanneer de verbindingspool verzadigd is.

De valkuil: een verkeerd geconfigureerde firewall of verlopen service principal-referenties kunnen zich manifesteren als een verbindingstime-out bij de eerste poging, slagen bij de tweede poging omdat een ander gatewayknooppunt het verzoek oppikt en vervolgens de volgende dag consequent mislukken wanneer de verkeerd gerouteerde verbinding niet langer beschikbaar is. De uitvoeringsgeschiedenis van de eerste dag toont 'Geslaagd na 1 poging', gemakkelijk te negeren. De volgende dag mislukt de job volledig met ErrorCode=UserErrorFailedToConnectToSqlServer en nu moet u onder druk debuggen.

De Fabric-Copy Job toont standaard geen details over fouten per poging in de activiteitsuitvoer. Om dit te verkrijgen, moet u diagnostische logboekregistratie inschakelen voor een Log Analytics-workspace en de tabel FabricItemsOperations opvragen:

`` FabricItemsOperations | where OperationName == "CopyJob.Run" | where Status == "Succeeded" | where AdditionalProperties.retryCount > 0 | project TimeGenerated, ItemName, retryCount = AdditionalProperties.retryCount, lastError = AdditionalProperties.lastErrorMessage ``

Een geslaagde uitvoering met retryCount > 0 is een belangrijke indicator. Het geeft aan dat de job slechts één configuratiefout verwijderd is van een mislukking. Behandel het op dezelfde manier als een CI-build die mislukt maar uiteindelijk slaagt: los de onderliggende fout op, normaliseer deze niet. De uitvoeringen die vandaag slagen met een nieuwe poging, zijn de uitvoeringen die u volgende week om 2 uur 's nachts zullen waarschuwen.

Voor grote tabellen biedt Copy Job parallel kopiëren met instellingen voor de mate van parallelliteit. Via de gebruikersinterface kunt u een waarde van 1 tot en met 32 kiezen. Achter de schermen splitst Fabric de bronquery op basis van fysieke partities (indien de bron dit ondersteunt) of een dynamisch bereik over een door u geselecteerde numerieke kolom.

Dynamische bereikpartitionering is waar het misgaat. Als u een kolom kiest met een scheve verdeling – bijvoorbeeld een CustomerID waarbij 80% van de rijen bij één tenant hoort – splitst Fabric het bereik gelijkmatig op basis van minimum/maximum. Eén partitie krijgt 80% van de rijen. De andere 31 partities worden binnen enkele seconden verwerkt en blijven inactief terwijl de zware partitie serieel wordt uitgevoerd. De totale doorvoer is nauwelijks beter dan bij DOP=1, maar u betaalt wel voor 32 rekeneenheden.

Erger nog, de zware partitie kan de time-out van 2 uur bereiken. De partitie mislukt, de activiteit mislukt en Fabric biedt geen mogelijkheid tot gedeeltelijk succes. U moet de hele job opnieuw uitvoeren.

Controleer de partitioneringsstrategie door het veld executionDetails.profile.queue van de run te inspecteren. Dit veld toont het aantal rijen per partitie en de duur ervan. Als max_partition_duration / median_partition_duration > 4, is uw partitiekolom onjuist. Kies een hash-gedistribueerde surrogaatsleutel of partitioneer de bron vooraf met een berekende kolom zoals ABS(CHECKSUM(NEWID())) % 32.

Voor bronnen zonder numerieke sleutels, de meeste SaaS-API's, JSON-bestandsdumps, wordt parallel kopiëren teruggebracht tot parallelisme op bestandsniveau, wat alleen nuttig is als u veel bestanden van ongeveer gelijke grootte hebt. Een enkel JSON-bestand van 40 GB krijgt één worker, ongeacht de DOP-instelling.

Het patroon bij alle vier de faalmodi is hetzelfde: het statusveld van de Copy Job rapporteert de bewerking, niet het resultaat. Een run die nul rijen las omdat het watermerk niet opschoof, een run die een bigint naar int converteerde en overlooprijen oversloeg, een run die na drie pogingen slaagde tegen een verslechterend eindpunt, al deze gevallen geven 'Geslaagd' weer in het activiteitenlogboek. De native Fabric-monitoring waarschuwt voor fouten, niet voor deze patronen.

De Fabric Pipelines-integratie van MetricSign volgt Copy Jobruns ten opzichte van historische baselines en markeert refresh_delayed wanneer het aantal rijen of de duur van een job afwijkt van het voortschrijdend gemiddelde, zelfs als de job zelf als succesvol wordt gerapporteerd. Het signaal voor het aantal herhalingen uit de diagnostische logboeken wordt gegroepeerd met de uiteindelijke fout, zodat u de waarschuwing en de storing als één incident ziet in plaats van afzonderlijk ingediende tickets met een week ertussen.

De operationele discipline die belangrijker is dan welke tool dan ook: elke bestemmingstabel van een Copy Job moet een versheidscontract hebben. Definieer het expliciet: dim_customer moet in de afgelopen 4 uur een rij hebben geschreven. Controleer dit onafhankelijk van de uitvoeringsgeschiedenis van de job. Onderzoek het wanneer het contract wordt geschonden, zelfs als elke uitvoering groen aangeeft.