Visualisering och rapportering för Teradata-migreringar

Den här artikeln är del fyra i en serie i sju delar som ger vägledning om hur du migrerar från Teradata till Azure Synapse Analytics. Fokus i den här artikeln är metodtips för visualisering och rapportering.

Få åtkomst till Azure Synapse Analytics med hjälp av Microsoft och BI-verktyg från tredje part

Organisationer får åtkomst till informationslager och data marts med hjälp av en rad olika BI-verktyg och program . Några exempel på BI-produkter är:

• Microsoft BI-verktyg, till exempel Power BI.

• Office-program, till exempel Microsoft Excel-kalkylblad.

• BI-verktyg från tredje part från olika leverantörer.

• Anpassade analysprogram med inbäddade BI-verktygsfunktioner.

• Operativa program som stöder BI på begäran genom att köra frågor och rapporter på en BI-plattform som i sin tur frågar efter data i ett informationslager eller data mart.

• Interaktiva utvecklingsverktyg för datavetenskap, till exempel Azure Synapse Spark Notebooks, Azure Machine Learning, RStudio och Jupyter Notebooks.

Om du migrerar visualisering och rapportering som en del av migreringen av informationslagret måste alla befintliga frågor, rapporter och instrumentpaneler som genereras av BI-produkter köras i den nya miljön. Dina BI-produkter måste ge samma resultat på Azure Synapse som i din äldre informationslagermiljö.

För konsekventa resultat efter migreringen måste alla BI-verktyg och programberoenden fungera när du har migrerat ditt informationslagerschema och data till Azure Synapse. Beroendena innehåller mindre synliga aspekter, till exempel åtkomst och säkerhet. När du hanterar åtkomst och säkerhet kontrollerar du att du migrerar:

• Autentisering så att användarna kan logga in på informationslagret och data mart-databaser i Azure Synapse.

• Alla användare till Azure Synapse.

• Alla användargrupper till Azure Synapse.

• Alla roller i Azure Synapse.

• Alla auktoriseringsbehörigheter som styr åtkomstkontroll till Azure Synapse.

• Användar-, roll- och behörighetstilldelningar för att spegla vad du hade i ditt befintliga informationslager före migreringen. Till exempel:

  • Behörigheter för databasobjekt som tilldelats roller
  • Roller som tilldelats till användargrupper
  • Användare som tilldelats användargrupper och/eller roller

Åtkomst och säkerhet är viktiga överväganden för dataåtkomst i det migrerade systemet och beskrivs mer detaljerat i Säkerhet, åtkomst och åtgärder för Teradata-migreringar.

Migrera alla nödvändiga data för att säkerställa att rapporter och instrumentpaneler som frågar efter data i den äldre miljön ger samma resultat i Azure Synapse.

Företagsanvändare förväntar sig en sömlös migrering utan överraskningar som förstör deras förtroende för det migrerade systemet i Azure Synapse. Var noga med att dämpa alla rädslor som användarna kan ha genom god kommunikation. Användarna förväntar sig att:

• Tabellstrukturen förblir densamma när den hänvisas direkt till i frågor.

• Tabell- och kolumnnamn förblir desamma när de hänvisas direkt till i frågor. Till exempel bör beräknade fält som definierats för kolumner i BI-verktyg inte misslyckas när aggregerade rapporter skapas.

• Historisk analys är densamma.

• Datatyper förblir desamma, om möjligt.

• Frågebeteendet förblir detsamma.

• ODBC/JDBC-drivrutiner testas för att säkerställa att frågebeteendet förblir detsamma.

Om BI-verktyg frågar efter vyer i det underliggande informationslagret eller data mart-databasen, kommer dessa vyer fortfarande att fungera efter migreringen? Vissa vyer kanske inte fungerar om det finns egna SQL-tillägg som är specifika för ditt äldre informationslager DBMS som inte har någon motsvarighet i Azure Synapse. I så fall måste du känna till dessa inkompatibiliteter och hitta ett sätt att lösa dem.

Andra problem, till exempel beteendet för NULL värden eller datatypvariationer mellan DBMS-plattformar, måste testas för att säkerställa att även små skillnader inte finns i beräkningsresultaten. Minimera dessa problem och vidta alla nödvändiga åtgärder för att skydda företagsanvändare från att påverkas av dem. Beroende på din äldre informationslagermiljö kan verktyg från tredje part som kan hjälpa till att dölja skillnaderna mellan äldre och nya miljöer så att BI-verktyg och program körs oförändrade.

Testning är avgörande för visualisering och rapportmigrering. Du behöver en testsvit och överenskomna testdata för att köra och köra tester på nytt i båda miljöerna. En testsel är också användbar, och några nämns i den här guiden. Det är också viktigt att involvera företagsanvändare i testaspekten av migreringen för att hålla förtroendet högt och hålla dem engagerade och en del av projektet.

Du kanske funderar på att byta BI-verktyg, till exempel för att migrera till Power BI. Frestelsen är att göra sådana ändringar samtidigt som du migrerar ditt schema, dina data, ETL-bearbetning med mera. Men för att minimera risken är det bättre att migrera till Azure Synapse först och få allt att fungera innan du genomför ytterligare modernisering.

Om dina befintliga BI-verktyg körs lokalt kontrollerar du att de kan ansluta till Azure Synapse via brandväggen så att du kan köra jämförelser mot båda miljöerna. Om leverantören av dina befintliga BI-verktyg erbjuder sin produkt i Azure kan du prova den där. Detsamma gäller för program som körs lokalt som bäddar in BI eller anropar DIN BI-server på begäran, till exempel genom att begära en "huvudlös rapport" med XML- eller JSON-data.

Det finns mycket att tänka på här, så låt oss ta en närmare titt.

Använda datavirtualisering för att minimera migreringens inverkan på BI-verktyg och rapporter

Under migreringen kan du vara frestad att uppfylla långsiktiga krav som att öppna affärsbegäranden, lägga till saknade data eller implementera nya funktioner. Sådana ändringar kan dock påverka BI-verktygets åtkomst till ditt informationslager, särskilt om ändringen innebär strukturella ändringar i datamodellen. Om du vill använda en flexibel datamodelleringsteknik eller implementera strukturella ändringar gör du det efter migreringen.

Ett sätt att minimera effekten av schemaändringar eller andra strukturella ändringar på dina BI-verktyg är att introducera datavirtualisering mellan BI-verktygen och ditt informationslager och data marts. Följande diagram visar hur datavirtualisering kan dölja en migrering från användare.

Datavirtualisering bryter beroendet mellan företagsanvändare som använder BI-verktyg med självbetjäning och det fysiska schemat för det underliggande informationslagret och data marts som migreras.

Med datavirtualisering kan eventuella schemaändringar som görs under en migrering till Azure Synapse, till exempel för att optimera prestanda, döljas för företagsanvändare eftersom de bara har åtkomst till virtuella tabeller i datavirtualiseringslagret. Och om du gör strukturella ändringar behöver du bara uppdatera mappningarna mellan informationslagret eller data marts och eventuella virtuella tabeller. Med datavirtualisering förblir användarna omedvetna om strukturella ändringar. Microsoft-partner tillhandahåller programvara för datavirtualisering.

Identifiera rapporter med hög prioritet som ska migreras först

En viktig fråga när du migrerar dina befintliga rapporter och instrumentpaneler till Azure Synapse är vilka som ska migreras först. Det kan vara flera faktorer som kan påverka beslutet, till exempel:

• Användning

• Affärsvärde

• Enkel migrering

• Strategi för datamigrering

I följande avsnitt beskrivs dessa faktorer.

Oavsett ditt beslut måste det involvera dina företagsanvändare eftersom de skapar rapporter, instrumentpaneler och andra visualiseringar och fattar affärsbeslut baserat på insikter från dessa objekt. Alla drar nytta när du kan:

• Migrera rapporter och instrumentpaneler sömlöst,
• Migrera rapporter och instrumentpaneler med minimal ansträngning och
• Peka dina BI-verktyg på Azure Synapse i stället för ditt äldre informationslagersystem och få liknande rapporter, instrumentpaneler och andra visualiseringar.

Migrera rapporter baserat på användning

Användning är ofta en indikator på affärsvärde. Oanvända rapporter och instrumentpaneler bidrar uppenbarligen inte till affärsbeslut eller erbjuder aktuellt värde. Om du inte har något sätt att ta reda på vilka rapporter och instrumentpaneler som inte används kan du använda något av de flera BI-verktyg som tillhandahåller användningsstatistik.

Om ditt äldre informationslager har varit igång i flera år finns det en god chans att du har hundratals, om inte tusentals, rapporter. Det är värt att kompilera en inventering av rapporter och instrumentpaneler och identifiera deras affärssyfte och användningsstatistik.

För oanvända rapporter avgör du om du vill inaktivera dem för att minska migreringen. En viktig fråga när du bestämmer om en oanvänd rapport ska inaktiveras är om rapporten inte används eftersom personer inte vet att den finns, eftersom den inte erbjuder något affärsvärde eller för att den har ersatts av en annan rapport.

Migrera rapporter baserat på affärsvärde

Enbart användning är inte alltid en bra indikator på affärsvärde. Du kanske vill ta hänsyn till i vilken utsträckning en rapports insikter bidrar till affärsvärdet. Ett sätt att göra det är att utvärdera lönsamheten för varje affärsbeslut som förlitar sig på rapporten och omfattningen av beroendet. Det är dock osannolikt att den informationen är lättillgänglig i de flesta organisationer.

Ett annat sätt att utvärdera affärsvärdet är att titta på hur en rapport överensstämmer med affärsstrategin. Affärsstrategin som fastställs av din chef beskriver vanligtvis strategiska affärsmål (SBAS), nyckeltal (KPI: er), KPI-mål som måste uppnås och vem som är ansvarig för att uppnå dem. Du kan klassificera en rapport efter vilka SBO:er rapporten bidrar till, som bedrägeriminskning, förbättrat kundengagemang och optimerade affärsverksamheter. Sedan kan du prioritera för migrering av rapporter och instrumentpaneler som är associerade med högprioriterade mål. På så sätt kan den inledande migreringen leverera affärsvärde inom ett strategiskt område.

Ett annat sätt att utvärdera affärsvärde är att klassificera rapporter och instrumentpaneler som operativa, taktiska eller strategiska för att identifiera på vilken affärsnivå de används. Småföretagare kräver bidrag på alla dessa nivåer. Genom att veta vilka rapporter och instrumentpaneler som används, på vilken nivå och vilka mål de är associerade med, kan du fokusera den inledande migreringen på affärsvärde med hög prioritet. Du kan använda följande måltabell för affärsstrategi för att utvärdera rapporter och instrumentpaneler.

Med verktyg för metadataidentifiering som Azure Data Catalog kan företagsanvändare tagga och betygsätta datakällor för att utöka metadata för dessa datakällor för att hjälpa till med identifiering och klassificering. Du kan använda metadata för en rapport eller instrumentpanel för att förstå dess affärsvärde. Utan sådana verktyg är det sannolikt en tidskrävande uppgift att förstå hur rapporter och instrumentpaneler bidrar till affärsvärdet, oavsett om du migrerar eller inte.

Migrera rapporter baserat på en strategi för datamigrering

Om din migreringsstrategi först baseras på migrering av data marts påverkar ordningen för migrering av data mart vilka rapporter och instrumentpaneler som migreras först. Om din strategi baseras på affärsvärde återspeglar den ordning i vilken du migrerar data marts till Azure Synapse affärsprioriteringar. Verktyg för metadataidentifiering kan hjälpa dig att implementera din strategi genom att visa vilka data mart-tabeller som innehåller data för vilka rapporter.

Problem med inkompatibilitet för migrering som kan påverka rapporter och visualiseringar

BI-verktyg skapar rapporter, instrumentpaneler och andra visualiseringar genom att utfärda SQL-frågor som har åtkomst till fysiska tabeller och/eller vyer i ditt informationslager eller data mart. När du migrerar ditt äldre informationslager till Azure Synapse kan flera faktorer påverka hur enkelt det är att migrera rapporter, instrumentpaneler och andra visualiseringar. Dessa faktorer är:

• Schemainkompatibiliteter mellan miljöerna.

• SQL-inkompatibiliteter mellan miljöer.

Schemainkompatibiliteter

Under en migrering kan schemainkompatibiliteter i informationslagret eller data mart-tabeller som tillhandahåller data för rapporter, instrumentpaneler och andra visualiseringar vara:

• Tabelltyper som inte är standard i ditt äldre informationslager DBMS som inte har någon motsvarighet i Azure Synapse.

• Datatyper i ditt äldre informationslager DBMS som inte har någon motsvarighet i Azure Synapse.

I de flesta fall finns det en lösning på inkompatibiliteterna. Du kan till exempel migrera data i en tabelltyp som inte stöds till en standardtabell med lämpliga datatyper och indexerade eller partitionerade på en datum/tid-kolumn. På samma sätt kan det vara möjligt att representera datatyper som inte stöds i en annan typ av kolumn och utföra beräkningar i Azure Synapse för att uppnå samma resultat.

Om du vill identifiera de rapporter som påverkas av schemainkompatibiliteter kör du frågor mot systemkatalogen för ditt äldre informationslager för att identifiera tabellerna med datatyper som inte stöds. Sedan kan du använda metadata från ditt BI-verktyg för att identifiera de rapporter som har åtkomst till data i dessa tabeller. Mer information om hur du identifierar inkompatibiliteter för objekttyper finns i Objekttyper för Teradata-databas som inte stöds.

Effekten av schemainkompatibiliteter på rapporter, instrumentpaneler och andra visualiseringar kan vara mindre än du tror eftersom många BI-verktyg inte stöder de mindre generiska datatyperna. Därför kanske ditt äldre datalager redan har vyer som omvandlar ej stödda datatyper till mer generiska typer.

SQL-inkompatibiliteter

Under en migrering kommer SQL-inkompatibiliteter sannolikt att påverka alla rapporter, instrumentpaneler eller andra visualiseringar i ett program eller verktyg som:

• Har åtkomst till äldre DBMS-vyer för informationslager som innehåller egna SQL-funktioner som inte har någon motsvarighet i Azure Synapse.

• Problem med SQL-frågor som innehåller egna SQL-funktioner, som är specifika för SQL-dialekten i din äldre miljö, som inte har någon motsvarighet i Azure Synapse.

Mäta effekten av SQL-inkompatibiliteter på din rapporteringsportfölj

Din rapportportfölj kan innehålla inbäddade frågetjänster, rapporter, instrumentpaneler och andra visualiseringar. Förlita dig inte på dokumentationen som är associerad med dessa objekt för att mäta effekten av SQL-inkompatibiliteter på migreringen av din rapportportfölj till Azure Synapse. Du måste använda ett mer exakt sätt att utvärdera effekten av SQL-inkompatibiliteter.

Använda EXPLAIN-instruktioner för att hitta SQL-inkompatibiliteter

Du hittar SQL-inkompatibiliteter genom att granska loggarna för den senaste SQL-aktiviteten i ditt äldre Teradata-informationslager. Använd ett skript för att extrahera en representativ uppsättning SQL-instruktioner till en fil. Prefixa sedan varje SQL-uttryck med en EXPLAIN -instruktion och kör dessa EXPLAIN instruktioner i Azure Synapse. Alla SQL-instruktioner som innehåller SQL-tillägg som inte stöds avvisas av Azure Synapse när EXPLAIN instruktionerna körs. Med den här metoden kan du utvärdera omfattningen av SQL-inkompatibiliteter.

Metadata från ditt äldre informationslager DBMS kan också hjälpa dig att identifiera inkompatibla vyer. Precis som tidigare samlar du in en representativ uppsättning SQL-instruktioner från tillämpliga loggar, prefixar varje SQL-instruktion med en EXPLAIN instruktion och kör dessa EXPLAIN instruktioner i Azure Synapse för att identifiera vyer med inkompatibel SQL.

Testa rapport- och instrumentpanelsmigrering till Azure Synapse Analytics

En viktig del av migreringen av informationslagret är testning av rapporter och instrumentpaneler i Azure Synapse för att verifiera att migreringen har fungerat. Definiera en serie tester och en uppsättning obligatoriska resultat för varje test som du ska köra för att verifiera att det lyckades. Testa och jämför rapporter och dashboards i dina befintliga och migrerade informationslagersystem för att:

• Identifiera om eventuella schemaändringar som gjordes under migreringen påverkade möjligheten för rapporter att köras, rapportresultat eller motsvarande rapportvisualiseringar. Ett exempel på en schemaändring är om du mappade en inkompatibel datatyp till en motsvarande datatyp som stöds i Azure Synapse.

• Kontrollera att alla användare migreras.

• Kontrollera att alla roller migreras och att användarna har tilldelats till dessa roller.

• Kontrollera att alla säkerhetsbehörigheter för dataåtkomst har migrerats för att säkerställa migreringen av åtkomstkontrollister (ACL).

• Säkerställ konsekventa resultat för alla kända sökfrågor, rapporter och instrumentpaneler.

• Se till att data och ETL-migrering är slutförda och felfria.

• Se till att datasekretessen upprätthålls.

• Testa prestanda och skalbarhet.

• Testa analytiska funktioner.

Information om hur du migrerar användare, användargrupper, roller och privilegier finns i Säkerhet, åtkomst och åtgärder för Teradata-migreringar.

Automatisera testningen så mycket som möjligt för att göra varje test repeterbart och för att stödja en konsekvent metod för att utvärdera testresultat. Automation fungerar bra för kända regelbundna rapporter och kan hanteras via Azure Synapse-pipelines eller Azure Data Factory-koordination. Om du redan har en uppsättning testfrågor för regressionstestning kan du använda de befintliga testverktygen för att automatisera efter migreringstestningen.

Ad hoc-analys och rapportering är mer utmanande och kräver kompilering av en uppsättning tester för att verifiera att samma rapporter och instrumentpaneler från före och efter migreringen är konsekventa. Om du hittar inkonsekvenser blir din möjlighet att jämföra metadata härstamning mellan de ursprungliga och migrerade systemen under migreringstestningen avgörande. Den jämförelsen kan belysa skillnader och fastställa var inkonsekvenser har sitt ursprung, när identifiering på annat sätt är svårt.

Analysera härkomst för att kunna förstå beroenden mellan rapporter, översiktspaneler och data

Din förståelse av härkomst är en viktig faktor vid en lyckad migrering av rapporter och översiktspaneler. Stamlinje är metadata som visar resan för migrerade data så att du kan spåra dess sökväg från en rapport eller instrumentbräda hela vägen tillbaka till datakällan. Huvudspårningen visar hur data har färdats från punkt till punkt, dess plats i datavaruhuset, och/eller datamart, och vilka rapporter och instrumentpaneler som använder den. Stam hjälper dig att förstå vad som händer med data när de rör sig genom olika datalager, såsom filer och databaser, olika ETL-pipelines samt in i rapporter. När företagsanvändare har tillgång till datahärledning stärks förtroendet, ökar tilliten och stödjer välgrundade affärsbeslut.

I miljöer med datalager för flera leverantörer kan affärsanalytiker i BI-team mappa ut data härkomst. Om du till exempel använder olika leverantörer för ETL, informationslager och rapportering, och varje leverantör har en egen metadatalagringsplats, kan det vara svårt och tidskrävande att ta reda på var ett specifikt dataelement i en rapport kommer ifrån.

För att migrera sömlöst från ett äldre informationslager till Azure Synapse använder du end-to-end data lineage för att säkerställa jämförbar migrering när du jämför de rapporter och instrumentpaneler som genereras av varje miljö. För att visa dataresan från slutpunkt till slutpunkt måste du samla in och integrera metadata från flera verktyg. Med åtkomst till verktyg som stöder automatisk identifiering av metadata och data härkomst kan du identifiera duplicerade rapporter eller ETL-processer och hitta rapporter som förlitar sig på föråldrade, tvivelaktiga eller obefintliga datakällor. Du kan använda den informationen för att minska antalet rapporter och ETL-processer som du migrerar.

Du kan också jämföra ursprunget från slutpunkt till slutpunkt för en rapport i Azure Synapse med ursprunget från slutpunkt till slutpunkt för samma rapport i din äldre miljö för att söka efter skillnader som oavsiktligt kan ha inträffat under migreringen. Den här typen av jämförelse är exceptionellt användbar när du behöver testa och verifiera att migreringen lyckades.

Visualisering av data härkomst minskar inte bara tid, ansträngning och fel i migreringsprocessen, utan möjliggör även snabbare migrering.

Genom att använda automatiserade metadataidentifierings- och dataursprungsverktyg som jämför ursprung kan du kontrollera att en rapport i Azure Synapse som produceras från migrerade data produceras på samma sätt i din äldre miljö. Den här funktionen hjälper dig också att avgöra:

• Vilka data som behöver migreras för att säkerställa en lyckad rapport- och instrumentpanelskörning i Azure Synapse.

• Vilka transformationer har utförts och bör utföras för att säkerställa framgångsrik körning i Azure Synapse.

• Så här minskar du replikering av rapporter.

Automatiserade verktyg för identifiering av metadata och dataursprung förenklar migreringsprocessen avsevärt eftersom de hjälper företag att bli mer medvetna om sina datatillgångar och veta vad som behöver migreras till Azure Synapse för att uppnå en stabil rapporteringsmiljö.

Flera ETL-verktyg tillhandahåller spårbarhet från början till slut, så kontrollera om ditt befintliga ETL-verktyg har den kapaciteten om du tänker använda det med Azure Synapse. Både Azure Synapse-pipelines eller Data Factory stöder möjligheten att visa ursprung i mappningsflöden. Microsoft-partner tillhandahåller även automatiserade metadataidentifiering, data härkomst och jämförelseverktyg för ursprung.

Migrera semantiska BI-verktygslager till Azure Synapse Analytics

Vissa BI-verktyg har ett så kallat semantiskt metadatalager. Det lagret förenklar företagsanvändarnas åtkomst till underliggande fysiska datastrukturer i ett informationslager eller en data mart-databas. Det semantiska metadatalagret förenklar åtkomsten genom att tillhandahålla objekt på hög nivå som dimensioner, mått, hierarkier, beräknade mått och kopplingar. Objekt på hög nivå använder affärsvillkor som är bekanta för affärsanalytiker och mappar till fysiska datastrukturer i ditt informationslager eller dataarkiv.

I en informationslagermigrering kan ändringar av kolumnnamn eller tabellnamn tvingas på dig. I Teradata kan t.ex. tabellnamn ha ett "#". I Azure Synapse tillåts "#" endast som ett prefix till ett tabellnamn för att ange en tillfällig tabell. I Teradata har TEMPORÄRA TABELLER inte nödvändigtvis ett "#" i namnet, men i Synapse måste de. Du kan behöva göra en del omarbetningar för att ändra tabellmappningar i sådana fall.

För att uppnå konsekvens mellan flera BI-verktyg skapar du ett universellt semantiskt lager med hjälp av en datavirtualiseringsserver som finns mellan BI-verktyg och program och Azure Synapse. På datavirtualiseringsservern använder du vanliga datanamn för objekt på hög nivå som dimensioner, mått, hierarkier och kopplingar. På så sätt konfigurerar du allt, inklusive beräknade fält, kopplingar och mappningar, bara en gång i stället för i varje verktyg. Peka sedan alla BI-verktyg på datavirtualiseringsservern.

Med datavirtualisering får du konsekvens i alla BI-verktyg och bryter beroendet mellan BI-verktyg och program och de underliggande fysiska datastrukturerna i Azure Synapse. Microsoft-partner kan hjälpa dig att uppnå konsekvens i Azure. Följande diagram visar hur ett vanligt ordförråd på datavirtualiseringsservern låter flera BI-verktyg se ett gemensamt semantiskt lager.

Slutsatser

Vid en migrering av informationslager enligt en "lyft och skift"-metod bör de flesta rapporter, instrumentpaneler och andra visualiseringar enkelt kunna migreras.

Under en migrering från en äldre miljö kan det hända att data i det äldre informationslagret eller data mart-tabellerna lagras i datatyper som inte stöds. Eller så kan du hitta äldre informationslagervyer som innehåller upphovsrättsskyddad SQL utan motsvarighet i Azure Synapse. I så fall måste du lösa dessa problem för att säkerställa en lyckad migrering till Azure Synapse.

Förlita dig inte på användarunderhållen dokumentation för att identifiera var problem finns. EXPLAIN Använd i stället instruktioner eftersom de är ett snabbt och pragmatiskt sätt att identifiera SQL-inkompatibiliteter. Omarbeta inkompatibla SQL-instruktioner för att uppnå motsvarande funktioner i Azure Synapse. Använd även automatiserade verktyg för identifiering av metadata och ursprung för att förstå beroenden, hitta duplicerade rapporter och identifiera ogiltiga rapporter som är beroende av föråldrade, tvivelaktiga eller obefintliga datakällor. Använd ursprungsverktyg för att jämföra ursprung för att kontrollera att rapporter som körs i din äldre informationslagermiljö skapas på samma sätt i Azure Synapse.

Migrera inte rapporter som du inte längre använder. BI-verktygsanvändningsdata kan hjälpa dig att avgöra vilka rapporter som inte används. För rapporter, instrumentpaneler och andra visualiseringar som du vill migrera, migrera alla användare, användargrupper, roller och privilegier. Om du använder affärsvärde för att driva din strategi för rapportmigrering associerar du rapporter med strategiska affärsmål och prioriteringar för att identifiera rapportinsikternas bidrag till specifika mål. Om du migrerar datamart för datamart, använd metadata för att identifiera vilka rapporter som är beroende av vilka tabeller och vyer, så att du kan fatta ett välgrundat beslut om vilka datamarts som ska migreras först.

Strukturella ändringar av datamodellen i ditt informationslager eller data mart kan inträffa under en migrering. Överväg att använda datavirtualisering för att skydda BI-verktyg och program från strukturella ändringar. Med datavirtualisering kan du använda en gemensam vokabulär för att definiera ett gemensamt semantiskt lager. Det gemensamma semantiska lagret garanterar konsekventa gemensamma datanamn, definitioner, mått, hierarkier och kopplingar i alla BI-verktyg och program i den nya Azure Synapse-miljön.

Nästa steg

Mer information om hur du minimerar SQL-problem finns i nästa artikel i den här serien: Minimera SQL-problem för Teradata-migreringar.