Bedste praksis for åben spejling i Microsoft Fabric

Brug disse praksisser til at offentliggøre pålidelige ændringsdata, forbedre merge-effektiviteten og forberede dig på gendannelse og skemaudvikling, når du skriver datafiler til en Fabric-landingszone. Anvend dem sammen med kravene og formaterne til open mirroring landing zone samt dokumentationen for din dataproducent. Producenter som Oracle GoldenGate kan have yderligere krav.

Publicér filer atomært

For et simpelt publiceringsmønster uploades en enkelt fil i dens tabelmappe med et midlertidigt navn med underscorepræfiks, såsom _00000000000000000042.parquet. Når uploaden er færdig, brug Azure Data Lake Storage Gen2-omdøbningsoperationen til atomært at omdøbe den til dens endelige navn, såsom 00000000000000000042.parquet.

For en parallel eller flertrinsudgiver kan du bruge den reserverede _scratchPad mappe som et valgfrit staging-område, som åben spejling udelukker fra tabelopdagelse. Upload, fuldfør og valider filen der, og flyt eller omdøb den derefter atomisk til tabelmappen. Åben spejling ignorerer også elementer med underscore-præfiks, så ingen af de midlertidige mønstre eksponerer ufuldstændige data som en tabelfil.

Før omdøbningen skal du tjekke, at Parquet- eller CSV-filen er komplet og gyldig. Udgiv ikke en delvis, korrupt eller nul-byte fil. Behandl hver sidste landingsbane som uforanderlig:

• Tilføj aldrig til eller overskriv en offentliggjort fil.
• Genanvend aldrig en endelig sti til forskelligt indhold.

Oprethold en crash-sikker, varig forbindelse mellem hver kildebatch og dens tildelte publikationssekvens eller endelige sti. Ved genoptagelse eller gendannelse skal du først tjekke, om den uforanderlige fil allerede er offentliggjort, og verificere, at den repræsenterer den tildelte batch. Hvis det gør, så fortsæt fremdriften uden at omskrive den. Hvis den ikke findes, så prøv den midlertidige upload og atomic rename for den samme opgave. Hvis vejen findes med forskelligt indhold, så stop og forlig konflikten. Overskriv det aldrig eller tildel det til en anden batch.

Vælg en fildetekteringsstrategi

Open mirroring bruges SequentialFileName som standard. Behold den, når kildeordenen er vigtig, og brug LastUpdateTimeFileDetection kun, når filer kan ankomme uafhængigt, og streng kildehændelsesrækkefølge ikke er påkrævet eller gives andre steder. Følg den valgte strategis allokerings- og behandlingsfremskridt på tværs af producentgenstarter og -genvindinger.

For SequentialFileName, spring ikke over, genbrug eller regresser ikke et indeks. Anvend verify-before-retry recovery-mønsteret fra Public-filer atomært, før du fortsætter den holdbare sekvensprogression.

LastUpdateTimeFileDetection garanterer ikke, at filerne behandles i den rækkefølge, producenten forventer. Den behandler hvert aktuelt synligt, ubehandlet sæt i lagringsrækkefølge LastModified , ikke producer-sekvens eller hændelsestid. Lige tidsstempler har ikke en defineret producentordre-tiebreak. En sen fil kan behandles efter nyere batches, og at overskrive en behandlet sti gør ikke stien berettiget til at blive læst igen. Hold hver sti unik og uforanderlig, og brug ikke denne strategi til at antage, at alle logiske kildebatches er ankommet.

Før spejlingen starter, skal du oprette hele landingzone-strukturen og offentliggøre de oprindelige filer, som din producentkontrakt kræver. Denne forberedelse giver spegilning et konsekvent punkt, hvorfra man kan opnå fremskridt.

Hold fletningsnøglerne smalle

For bedst mulig sammensmeltningsydelse og mere forudsigelig hukommelsesforbrug, hold en sammensmeltningsnøgle så lille som muligt. Brug færre end fem nøglekolonner, når det er muligt. Denne vejledning er en præstationsanbefaling, ikke en hård grænse.

Ved en nøgleændring koder open mirroring de typede nøgleværdier og beregner en 64-bit kandidatlokator. Denne lookup-hash lokaliserer kandidater i en cache eller målindeks, men det er ikke rækkeidentiteten. En cache-miss falder tilbage til målindekset. Før en upsert, eller når kandidater er tvetydige, verificerer motoren de præcise indtastede sammensatte nøgleværdier. Denne verifikation beskytter korrektheden, når forskellige nøgler producerer den samme hash-kandidat.

Opdateringer og sletninger opdaterer ikke fysisk den tidligere datarække:

• En matchet opdatering markerer den tidligere målrække som slettet via en slettevektor og skriver en erstatningsrække.
• En matchet sletning markerer den forrige række som slettet.
• En insert eller upsert uden et præcist match skriver en ny række.

Vurder opslagsindsatsen ved at overveje antallet af ændrede rækker, nøglebredden og kodede bytes, antallet af relevante målfiler, indeksparathed, cache-hitrate og kandidatnøgledatalæsninger. Disse faktorer indikerer relativ indsats, ikke forløbet tid eller en estimeret færdiggørelsestid. Den faktiske tid varierer med mållayout, indeksparathed, cache-tilstand, lagerydelse, samtidighed og gentagelser. Benchmark repræsentativt datavolumen, nøglefordelinger, ændringsrater, mållayout og cache-forhold.

Optimer filer, der kun indsætter

Kolonnen __rowMarker__ identificerer hver række som indsætt, opdatering, slet eller upsert. For en Parquet-strøm, der kun er reelt indsat, bør du udelade __rowMarker__ , når den valgte open mirroring-kontrakt og fildetekteringsstrategi tillader det. Berettigede Parquet-filer uden markør kan bruge direkte staging (direct staging). En markørbærende fil bruger den rækkebaserede behandlingssti, selv når hver markør angiver en indsættelse.

At mangle __rowMarker__ alene beviser ikke, at en stream kun er append-only. Konfiguration kan tildele en standardoperation, såsom upsert, så den valgte kontrakt bestemmer datasemantikken. Fjern ikke markøren fra CSV eller fra en stream, der kan opdatere eller slette rækker.

Før produktionsbrug, valider den markørfrie sti med repræsentative filer, konfiguration, indledende indlæsning, inkrementelle indsættelser, gentagelser og gendannelse. Bekræft både de resulterende rækker og den forventede behandlingssti.

Plan for genopretning

Hvis en nul-byte, korrupt eller på anden måde ugyldig fil fejler indtastningen, slet den fra OneLake og upload en komplet, gyldig erstatning med præcis samme filnavn. For sekventiel navngivning forbliver senere filer blokeret, indtil det manglende sekvensnummer er genoprettet. Denne procedure reparerer en fejlet fil; den afspiller ikke en fil, der allerede er behandlet. En gyldig Parquet-fil, der indeholder nul rækker, er ikke en nul-byte fil og kræver ikke reparation.

For at genstarte en tabel fra begyndelsen:

1. Slet hele landingzone-mappen på bordet.
2. Vent til tabellen forsvinder fra den spejlede database.
3. Genskab den samme mappe, upload den nødvendige konfiguration og en fuldendt, gyldig indledende indlæsning.
4. Genoptag kun offentliggørelsen af inkrementelle ændringer, når tabellen dukker op igen.

Stop ikke og genstart den spejlede database for at gendanne en enkelt tabel. Gør det kun, når du bevidst vil have hele den spejlede database til at genstarte fra starten.

Koordinat-kildeskemaændringer

Før du offentliggør data efter en ændring i kildedatadefinitionsproget (DDL), skal du bekræfte, at de nye kilde- og landing-file-skemaer er kompatible med den eksisterende destinationstabelle. De fleste ændringer fortsætter gennem den normale udgivelsesproces. Kun en ændring i breaking kræver at den berørte tabel genopbygges og genopfyldes.

Nøglekolonner er faste efter at tabelmetadata har deklareret dem, så planlæg en genopbygning, hvis nøglen skal ændres. For afgrænset tekst understøtter den deklarerede skema-definition ikke skemaudvikling.

For at genopbygge et bord skal du følge genstartsproceduren i Plan for genopretning. Brug Fabric REST API'en til spejlede databaser og PySpark-baseret automatisering, hvor det er relevant, for at koordinere genopbygningen og validere destinationstabellen, før du genoptager publiceringen.

Følg producentspecifikke krav

Open mirroring definerer landing zone-kontrakten, ikke hvordan din producer genererer filer. Tredjepartsforfattere tilføjer deres egne forudsætninger, som producenten ejer og dokumenterer. Gennemgå dokumentationen for din producer og open mirroring partners-økosystemet.

Bekræft disse landingszoneindstillinger for enhver producent:

• keyColumns: Udfør nøglen til opdaterings- og slet-support. Udelad det kun for indsættelsestabeller.
• fileDetectionStrategy: Behold den sekventielle standard, når rækkefølgen betyder noget. Sat LastUpdateTimeFileDetection kun til ikke-sekventielle filnavne.
• isUpsertDefaultRowMarker: Sæt til true når markørfrie rækker skal behandles som opadgående rækker i stedet for indsættelser.
• _partnerEvents.json: Publicér denne fil på spejldatabaseniveau for at identificere producent og kildetype.

Følgende eksempler viser, hvilke slags producent-side miljøer disse forfattere udsætter. De ejes af producenten, så bekræft dem altid i producentens egen dokumentation.

Orakel GoldenGate 23ai

Oracles dokumentation replikeres til en spejlet database via GoldenGate for Distributed Applications and Analytics. Tilføj en Classic Replicat, sæt målet til Mirrored Database i Microsoft Fabric, og vælg din Fabric Mirror-forbindelse som alias. Lad de administrerede muligheder og replikationsparametre være standardindstillinger, og sæt OneLake-hændelseshandlerens egenskaber gg.eventhandler.onelake.workspace til gg.eventhandler.onelake.mirror dit målarbejdsområde og spejlnavn.

MongoDB Atlas

MongoDB's dokumentation kører en spejlingsapplikation på en Azure App Service eller en virtuel maskine, så værten er en forudsætning, du provisionerer. Autentificér med en serviceprincipal, der har administratoradgang til Fabric-arbejdsområdet, og lever Atlas-forbindelses-URI, databasenavnet og enten en eksplicit liste over samlinger eller alle samlinger. Tilføj en efterfølgende streg til landingszonens URL, når du sender den til applikationen. Fordi applikationen kører en indledende synkronisering pr. samling, før den følger ændringsstrømmen, dimensionerer værten til den indledende belastning; MongoDBs egen højniveau-benchmark foreslår overvågning af gennemstrømning og CPU ud over cirka fem store samlinger.

Begge producenter skriver også deres egne status- og statusfiler med et understregningspræfiks. Åben mirroring ignorerer elementer med underscore-præfiks, så de aldrig vises som tabeldata.

Tjekliste for udgivelse og genfinding