Visualisering och rapportering för Teradata-migreringar

Den här artikeln är del fyra i en serie i sju delar som innehåller 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 Azure Synapse Analytics med hjälp av Microsoft och BI-verktyg från tredje part

Organisationer får åtkomst till informationslager och dataförråd med hjälp av en rad 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 dataförråd.

• 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 ska du se till att du migrerar:

• Autentisering så att användare kan logga in på informationslagret och datamartdatabaser på Azure Synapse.

• Alla användare som ska Azure Synapse.

• Alla användargrupper som ska Azure Synapse.

• Alla roller att Azure Synapse.

• Alla behö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. Exempel:

  • Behörigheter för databasobjekt som tilldelats roller
  • Roller som tilldelats till användargrupper
  • Användare som tilldelats till 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.

Tips

Befintliga användare, användargrupper, roller och tilldelningar av åtkomstsäkerhetsprivilegier måste migreras först för att migreringen av rapporter och visualiseringar ska lyckas.

Migrera alla nödvändiga data för att säkerställa att de 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 några överraskningar som förstör deras förtroende för det migrerade systemet på 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 refereras direkt till i frågor.

• Tabell- och kolumnnamn förblir desamma när de refereras 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.

• Den historiska analysen är densamma.

• Datatyperna 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.

Tips

Kommunikation och företagsanvändarengagemang är avgörande för framgång.

Kommer dessa vyer fortfarande att fungera efter migreringen om BI-verktyg frågar vyer i det underliggande informationslagret eller datamartdatabasen? 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 behöver du känna till dessa inkompatibiliteter och hitta ett sätt att lösa dem.

Tips

Vyer och SQL-frågor som använder egna SQL-frågetillägg resulterar sannolikt i inkompatibiliteter som påverkar BI-rapporter och instrumentpaneler.

Andra problem, till exempel beteendet NULL för värden eller datatypsvariationer på 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. Ett testsele är också användbart, 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.

Tips

Använd repeterbara tester för att se till att rapporter, instrumentpaneler och andra visualiseringar migreras.

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 riskerna ä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 genom 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 och 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 effekten av migrering 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 omfattar strukturella ändringar i din datamodell. 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 dataförråd. 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 dataförråden som migreras.

Tips

Med datavirtualisering kan du skydda företagsanvändare från strukturella ändringar under migreringen så att de inte känner till dessa ändringar. Strukturella ändringar inkluderar schemaändringar som justerar din datamodell för Azure Synapse.

Med datavirtualisering kan alla 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 dataarkivet 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 befintliga rapporter och instrumentpaneler till Azure Synapse är vilka som ska migreras först. Flera faktorer kan driva det 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 får fördelar 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 kan 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 sammanställa 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 migreringsarbetet. En viktig fråga när du bestämmer om du vill inaktivera en rapport som inte används är om rapporten inte används eftersom personer inte vet att den finns, eftersom den inte har 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 överväga i vilken utsträckning en rapports insikter bidrar till affärsvärdet. Ett sätt att göra detta ä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ätt tillgänglig i de flesta organisationer.

Ett annat sätt att utvärdera affärsvärde är att titta på justeringen av en rapport med affärsstrategi. Den affärsstrategi som din chef har satt upp 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 med vilken SPO:er som rapporten bidrar till, till exempel minskning av bedrägerier, förbättrat kundengagemang och optimerad verksamhet. 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. SPO:er 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 första 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.

Nivå	Rapport-/instrumentpanelsnamn	Affärssyfte	Avdelning som används	Användningsfrekvens	Affärsprioritet
Strategisk
Taktisk
Operativ

Metadataidentifieringsverktyg som Azure Data Catalog låta 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 hjälpa dig att förstå dess affärsvärde. Utan sådana verktyg är det troligt att det är tidskrävande 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 baseras på migrering av data marts först påverkar ordningen på migreringen 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.

Tips

Din strategi för datamigrering påverkar vilka rapporter och visualiseringar som migreras först.

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 dataarkiv. När du migrerar ditt äldre informationslager till Azure Synapse kan flera faktorer påverka migreringen av 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 datalager DBMS som inte har någon motsvarighet i Azure Synapse.

• Datatyper i ditt äldre datalager 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 indexeras eller partitioneras 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.

Tips

Schemainkompatibiliteter omfattar dbms-tabelltyper och datatyper som inte stöds på Azure Synapse.

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 Teradata-databasobjekttyper som inte stöds.

Tips

Fråga systemkatalogen för ditt äldre lager DBMS för att identifiera schemainkompatibiliteter med Azure Synapse.

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 informationslager redan har vyer som CAST inte stöds av 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 dbms-vyer för äldre informationslager som innehåller egna SQL-funktioner som inte har någon motsvarighet i Azure Synapse.

• Problem med SQL-frågor som omfattar 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 rapporteringsportfölj till Azure Synapse. Du måste använda ett mer exakt sätt för 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 av upphovsrättsskyddade kommer att avvisas av Azure Synapse när -uttrycken EXPLAIN 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.

Tips

Mäta effekten av SQL-inkompatibiliteter genom att hämta dina DBMS-loggfiler och köra EXPLAIN -instruktioner.

Testa migrering av rapporter och instrumentpaneler till Azure Synapse Analytics

En viktig del av migreringen av informationslager ä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 nödvändiga resultat för varje test som du ska köra för att verifiera att det lyckades. Testa och jämför rapporter och instrumentpaneler i dina befintliga och migrerade informationslagersystem med:

• 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 har migrerats.

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

• Kontrollera att alla säkerhetsbehörigheter för dataåtkomst migreras för att säkerställa migrering av åtkomstkontrollistor (ACL).

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

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

• Se till att datasekretess upprätthålls.

• Testa prestanda och skalbarhet.

• Testa analysfunktioner.

Tips

Testa och finjustera prestanda för att minimera beräkningskostnaderna.

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 orkestrering. Om du redan har en uppsättning testfrågor för regressionstestning kan du använda de befintliga testverktygen för att automatisera efter migreringstestning.

Tips

Bästa praxis är att skapa en automatiserad testsvit för att göra tester repeterbara.

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 markera skillnader och fastställa var inkonsekvenser har sitt ursprung, när identifiering på andra sätt är svårt.

Tips

Använd verktyg som jämför metadata härstamning för att verifiera resultat.

Analysera ursprung för att förstå beroenden mellan rapporter, instrumentpaneler och data

Din förståelse av ursprung är en viktig faktor vid lyckad migrering av rapporter och instrumentpaneler. Ursprung är metadata som visar resan för migrerade data så att du kan spåra dess sökväg från en rapport eller instrumentpanel hela vägen tillbaka till datakällan. Ursprunget visar hur data har färdats från punkt till punkt, dess plats i informationslagret och/eller dataförrådet och vilka rapporter och instrumentpaneler som använder dem. Ursprung kan hjälpa dig att förstå vad som händer med data när de överförs genom olika datalager, till exempel filer och databaser, olika ETL-pipelines och till rapporter. När företagsanvändare har åtkomst till data härkomst förbättrar det förtroendet, ingjuter förtroende och stöder välgrundade affärsbeslut.

Tips

Din möjlighet att komma åt metadata och dataursprung från rapporter hela vägen tillbaka till en datakälla är avgörande för att verifiera att migrerade rapporter fungerar korrekt.

I miljöer med informationslager 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.

Tips

Verktyg som automatiserar insamlingen av metadata och visar ursprung från slutpunkt till slutpunkt i en miljö med flera leverantörer är värdefulla under en migrering.

Om du vill migrera sömlöst från ett äldre informationslager till Azure Synapse använder du data härstamning från slutpunkt till slutpunkt för att bevisa liknande 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 den äldre miljön 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 migreringens framgång.

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 verktyg för identifiering av metadata och data härkomst som jämför ursprung kan du kontrollera att en rapport i Azure Synapse som produceras från migrerade data skapas 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 transformeringar som har utförts och bör utföras för att säkerställa en lyckad körning i Azure Synapse.

• Minska rapportduplicering.

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

Flera ETL-verktyg tillhandahåller ursprungsfunktioner från slutpunkt till slutpunkt, så kontrollera om ditt befintliga ETL-verktyg har den funktionen om du planerar att använda det med Azure Synapse. Azure Synapse pipelines eller Data Factory stöder båda möjligheten att visa ursprung i mappningsflöden. Microsoft-partner tillhandahåller också automatiserade metadataidentifiering, data härkomst och jämförelseverktyg för ursprung.

Migrera BI-verktygets semantiska lager till Azure Synapse Analytics

Vissa BI-verktyg har ett så kallat semantiskt metadatalager. Det lagret förenklar företagsanvändares åtkomst till de underliggande fysiska datastrukturerna i ett informationslager eller en datamartdatabas. 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. De övergripande objekten använder affärsvillkor som är bekanta för affärsanalytiker och mappar till fysiska datastrukturer i ditt informationslager eller dataförråd.

Tips

Vissa BI-verktyg har semantiska lager som förenklar företagsanvändares åtkomst till fysiska datastrukturer i ditt informationslager eller dataarkiv.

Vid en migrering av informationslager 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.

Tips

Använd datavirtualisering för att skapa ett gemensamt semantiskt lager för att garantera konsekvens i alla BI-verktyg i en Azure Synapse miljö.

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 gemensamt ordförråd i datavirtualiseringsservern låter flera BI-verktyg se ett gemensamt semantiskt lager.

Slutsatser

I en lift and shift-migrering av informationslager bör de flesta rapporter, instrumentpaneler och andra visualiseringar migreras enkelt.

Under en migrering från en äldre miljö kan du upptäcka att data i det äldre informationslagret eller datamarttabellerna lagras i datatyper som inte stöds. Eller så kan du hitta äldre informationslagervyer som innehåller egenutvecklad 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. Använd EXPLAIN i stället instruktioner eftersom de är ett snabbt, pragmatiskt sätt att identifiera SQL-inkompatibiliteter. Omarbeta inkompatibla SQL-instruktioner för att uppnå motsvarande funktioner i Azure Synapse. Använd också automatiserade verktyg för identifiering av metadata och ursprung för att förstå beroenden, hitta duplicerade rapporter och identifiera ogiltiga rapporter som förlitar sig på 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 identiskt 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 de rapporter, instrumentpaneler och andra visualiseringar som du vill migrera, migrera alla användare, användargrupper, roller och behörigheter. 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 hur rapportinsikter bidrar till specifika mål. Om du migrerar dataförråd via datamart använder du 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 datamarter som ska migreras först.

Tips

Identifiera inkompatibiliteter tidigt för att mäta omfattningen av migreringsarbetet. Migrera användare, grupproller och behörighetstilldelningar. Migrera endast de rapporter och visualiseringar som används och bidrar till affärsvärde.

Strukturella ändringar av datamodellen i ditt informationslager eller dataförråd kan ske 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 mellan 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.