Data definitions språk för schema migreringData definition languages for schema migration

Den här artikeln beskriver design överväganden och prestanda alternativ för data definitions språk (DDLs) när du migrerar scheman till Azure Synapse Analytics.This article describes design considerations and performance options for data definition languages (DDLs) when you're migrating schemas to Azure Synapse Analytics.

DesignövervägandenDesign considerations

Granska dessa design aspekter när du planerar migreringen av schemat.Review these design considerations as you plan your schema migration.

Förberedelse för migreringPreparation for migration

När du förbereder att migrera befintliga data till Azure Synapse Analytics är det viktigt att tydligt definiera omfånget för övningen (särskilt för ett första migreringsjobb).When you're preparing to migrate existing data to Azure Synapse Analytics, it's important to clearly define the scope of the exercise (especially for an initial migration project). Tiden fram för att förstå hur databas objekt och relaterade processer kommer att migreras kan minska både ansträngningen och risken senare i projektet.The time spent up front to understand how database objects and related processes will migrate can reduce both effort and risk later in the project.

Skapa en inventering av databas objekt som ska migreras.Create an inventory of database objects to be migrated. Beroende på käll plattformen innehåller den här inventeringen några eller alla av följande objekt:Depending on the source platform, this inventory will include some or all of the following objects:

  • TabellerTables
  • VyerViews
  • IndexIndexes
  • FunctionsFunctions
  • Lagrade procedurerStored procedures
  • Data distribution och partitioneringData distribution and partitioning

Den grundläggande informationen för de här objekten bör omfatta mått som antal rader, fysisk storlek, data komprimerings förhållande och objekt beroenden.The basic information for these objects should include metrics such as row counts, physical size, data compression ratios, and object dependencies. Den här informationen bör vara tillgänglig via frågor mot system katalog tabeller i käll systemet.This information should be available via queries against system catalog tables in the source system. Systemets metadata är den bästa källan för den här informationen.The system metadata is the best source for this information. Extern dokumentation kan vara inaktuell och inte synkroniserad med ändringar som har tillämpats på data strukturen sedan den första implementeringen.External documentation might be stale and not in sync with changes that have been applied to the data structure since the initial implementation.

Du kanske också kan analysera faktisk objekt användning från Query-loggar eller använda verktyg från Microsoft-partners som Attunity-synlighet för att hjälpa dig.You might also be able to analyze actual object usage from query logs or use tooling from Microsoft partners like Attunity Visibility to help. Det är möjligt att vissa tabeller inte behöver migreras eftersom de inte längre används i produktions frågor.It's possible that some tables don't need to be migrated because they're no longer used in production queries.

Data storlek och arbets belastnings information är viktigt för Azure Synapse Analytics eftersom det hjälper dig att definiera lämpliga konfigurationer.Data size and workload information is important for Azure Synapse Analytics because it helps to define appropriate configurations. Ett exempel är de nivåer som krävs för samtidighet.One example is the required levels of concurrency. Att förstå den förväntade tillväxten av data och arbets belastningar kan påverka en rekommenderad mål konfiguration och det är en bra idé att även utnyttja den här informationen.Understanding the expected growth of data and workloads might affect a recommended target configuration, and it's a good practice to also harness this information.

När du använder data volymer för att beräkna det lagrings utrymme som krävs för den nya mål plattformen är det viktigt att förstå data komprimerings förhållandet, om det finns några, på käll databasen.When you're using data volumes to estimate the storage required for the new target platform, it's important to understand the data compression ratio, if any, on the source database. Att ta bort mängden lagrings utrymme som används i käll systemet är troligt vis ett falskt belopp för storleks ändringen.Simply taking the amount of storage used on the source system is likely to be a false basis for sizing. Information om övervakning och metadata kan hjälpa dig att avgöra okomprimerad rå data storlek och omkostnader för indexering, datareplikering, loggning eller andra processer i det aktuella systemet.Monitoring and metadata information can help you determine uncompressed raw data size and overheads for indexing, data replication, logging, or other processes in the current system.

Den okomprimerade rå data storleken för de tabeller som ska migreras är en start punkt för att uppskatta lagrings utrymmet som krävs i den nya Azure Synapse Analytics-miljön.The uncompressed raw data size of the tables to be migrated is a good starting point for estimating the storage required in the new target Azure Synapse Analytics environment.

Den nya mål plattformen kommer också att innehålla en komprimerings faktor och indexerings kostnader, men de kommer förmodligen att skilja sig från käll systemet.The new target platform will also include a compression factor and indexing overhead, but these will probably be different from the source system. Pris nivån för Azure Synapse Analytics-lagring innehåller även sju dagars säkerhets kopiering av ögonblicks bilder.Azure Synapse Analytics storage pricing also includes seven days of snapshot backups. Jämfört med den befintliga miljön kan detta påverka den totala kostnaden för lagring som krävs.When compared to the existing environment, this can have an impact on the overall cost of storage required.

Du kan fördröja prestanda justeringen för data modellen tills den är sen i migreringsprocessen och den tidpunkt då real tids data volymer finns i data lagret.You can delay performance tuning for the data model until late in the migration process and time this with when real data volumes are in the data warehouse. Vi rekommenderar dock att du implementerar vissa alternativ för prestanda justering tidigare på.However, we recommend that you implement some performance tuning options earlier on.

I Azure Synapse Analytics är det till exempel klokt att definiera små dimensions tabeller som replikerade tabeller och definiera stora fakta tabeller som grupperade columnstore-index.For example, in Azure Synapse Analytics, it makes sense to define small dimension tables as replicated tables and to define large fact tables as clustered columnstore indexes. På samma sätt ger index som definierats i käll miljön en uppfattning om vilka kolumner som kan ha nytta av indexering i den nya miljön.Similarly, indexes defined in the source environment provide a good indication of which columns might benefit from indexing in the new environment. Med hjälp av den här informationen när du först definierar tabellerna innan inläsningen sparas tid senare i processen.Using this information when you're initially defining the tables before loading will save time later in the process.

Det är en bra idé att mäta komprimerings förhållandet och indexera kostnader för dina egna data i Azure Synapse Analytics eftersom migreringen fortskrider.It's good practice to measure the compression ratio and index overhead for your own data in Azure Synapse Analytics as the migration project progresses. Det här måttet möjliggör framtida kapacitets planering.This measure enables future capacity planning.

Det kan vara möjligt att förenkla ditt befintliga data lager innan migrering genom att minska komplexiteten för att under lätta migreringen.It might be possible to simplify your existing data warehouse before migration by reducing complexity to ease migration. Den här ansträngningen kan vara:This effort might include:

  • Ta bort eller arkivera oanvända tabeller innan du migrerar för att undvika att migrera data som inte används.Removing or archiving unused tables before migrating to avoid migrating data that's not used. Att arkivera till Azure Blob Storage och definiera data som en extern tabell kan hålla data tillgängliga för en lägre kostnad.Archiving to Azure Blob Storage and defining the data as an external table might keep the data available for a lower cost.
  • Konvertera fysiska datamarts till virtuella datamarts genom att använda datavirtualization-programvara för att minska vad du behöver migrera.Converting physical data marts to virtual data marts by using data virtualization software to reduce what you have to migrate. Den här omvandlingen ökar också flexibiliteten och minskar den totala ägande kostnaden.This conversion also improves agility and reduces total cost of ownership. Du kan betrakta det som modernisering under migreringen.You might consider it as modernization during migration.

Ett mål för migreringen kan också vara att modernisera lagret genom att ändra den underliggande data modellen.One objective of the migration exercise might also be to modernize the warehouse by changing the underlying data model. Ett exempel är att flytta från en inMon data modell till en data valv metod.One example is moving from an Inmon-style data model to a data vault approach. Du bör besluta detta som en del av förberedelse fasen och införliva en strategi för över gången till migreringsprocessen.You should decide this as part of the preparation phase and incorporate a strategy for the transition into the migration plan.

Den rekommenderade metoden i det här scenariot är att först migrera data modellen till den nya plattformen och sedan övergå till den nya modellen i Azure Synapse Analytics.The recommended approach in this scenario is to first migrate the data model as is to the new platform and then transition to the new model in Azure Synapse Analytics. Använd plattformens egenskaper för skalbarhet och prestanda för att köra omvandlingen utan att påverka käll systemet.Use the platform's scalability and performance characteristics to execute the transformation without affecting the source system.

Migrering av data modellData model migration

Beroende på plattform och käll systemets ursprung kan data modellen för vissa eller alla delar redan finnas i ett stjärn-eller snö schema format.Depending on the platform and the origins of the source system, the data model of some or all parts may already be in a star or snowflake schema form. I så fall kan du migrera den direkt till Azure Synapse Analytics som den är.If so, you can directly migrate it to Azure Synapse Analytics as is. Det här scenariot är den enkla och lägsta risk migrering som uppnås.This scenario is the easiest and lowest-risk migration to achieve. En som-är migrering kan också vara det första steget i en mer komplex migrering som innehåller en över gång till en ny underliggande data modell, till exempel ett data valv, enligt beskrivningen ovan.An as-is migration can also be the first stage of a more complex migration that includes a transition to a new underlying data model such as a data vault, as described earlier.

En uppsättning Relations tabeller och vyer kan migreras till Azure Synapse Analytics.Any set of relational tables and views can be migrated to Azure Synapse Analytics. För analytiska fråge arbets belastningar mot en stor data uppsättning ger en stjärn eller snö data modell vanligt vis den bästa övergripande prestandan.For analytical query workloads against a large data set, a star or snowflake data model generally gives the best overall performance. Om käll data modellen inte redan finns i det här formuläret kan det vara värt att använda migreringsprocessen för att modellera om modellen.If the source data model is not already in this form, it might be worth using the migration process to reengineer the model.

Om migreringstabellen innehåller några ändringar i data modellen är det bästa sättet att utföra dessa ändringar i den nya mål miljön.If the migration project includes any changes to the data model, the best practice is to perform these changes in the new target environment. Det vill säga migrera den befintliga modellen först och sedan använda kraften och flexibiliteten i Azure Synapse Analytics för att transformera data till den nya modellen.That is, migrate the existing model first, and then use the power and flexibility of Azure Synapse Analytics to transform the data to the new model. Den här metoden minimerar påverkan på det befintliga systemet och använder prestanda och skalbarhet i Azure Synapse Analytics för att göra ändringar snabbt och kostnads effektivt.This approach minimizes the impact on the existing system and uses the performance and scalability of Azure Synapse Analytics to make any changes quickly and cost-effectively.

Du kan migrera det befintliga systemet som flera lager. till exempel data inmatning/mellanlagring, informations lager lager och rapporterings-eller data mart lager.You can migrate the existing system as several layers; for example, the data ingest/staging layer, data warehouse layer, and reporting or data mart layer. Varje lager består av Relations tabeller och vyer.Each layer consists of relational tables and views. Även om du kan migrera dessa till Azure Synapse Analytics som de är, kan det vara mer kostnads effektivt och tillförlitligt att använda några av funktionerna i Azure-eko systemet.Although you can migrate these to Azure Synapse Analytics as they are, it might be more cost-effective and reliable to use some of the features and capabilities of the Azure ecosystem. Exempel:For example:

  • Data inmatning och mellanlagring: I stället för att använda Relations tabeller för snabb parallell data inläsning kan du använda Azure Blob Storage med PolyBase under en del av ETL-processen (Extract, Transform, Load) eller ELT (extrahera, Läs in, transformera).Data ingest and staging: Instead of using relational tables for fast parallel data loading, you can use Azure Blob storage with PolyBase during part of the ETL (extract, transform, load) or ELT (extract, load, transform) process.

  • Data inmatning och mellanlagring: Du kan använda Azure Blob Storage tillsammans med PolyBase för snabb parallell data inläsning för en del av ETL-processen (Extract, Transform, Load) eller ELT (Extract, load, Transform) i stället för Relations tabeller.Data ingest and staging: You can use Azure Blob Storage in conjunction with PolyBase for fast parallel data loading for part of the ETL (extract, transform, load) or ELT (extract, load, transform) process, rather than relational tables.

  • Rapporterings lager och data Marts: Prestanda egenskaperna för Azure Synapse Analytics kan eliminera behovet av att fysiskt instansiera sammanställda tabeller för rapporterings syfte eller data Marts.Reporting layer and data marts: The performance characteristics of Azure Synapse Analytics might eliminate the need to physically instantiate aggregated tables for reporting purposes or data marts. Det kan vara möjligt att implementera dessa som-vyer på kärn informations lagret eller via ett data Virtualization-skikt från tredje part.It might be possible to implement these as views onto the core data warehouse or via a third-party data virtualization layer. På Basic-nivå kan du skapa en process för datamigrering av historiska data och eventuellt även stegvisa uppdateringar som visas i det här diagrammet:At the basic level, you can achieve the process for data migration of historical data and possibly also incremental updates as shown in this diagram:

    Diagram som illustrerar ett modernt informations lager.Diagram that illustrates a modern data warehouse. Bild 1: ett modernt informations lager.Figure 1: A modern data warehouse.

Om du kan använda dessa eller liknande metoder minskas antalet tabeller som ska migreras.If you can use these or similar approaches, the number of tables to be migrated is reduced. Vissa processer kan vara förenklade eller eliminerade, vilket minskar arbets belastningen för migreringen.Some processes might be simplified or eliminated, again reducing the migration workload. Tillämpligheten för dessa metoder beror på det enskilda användnings fallet.The applicability of these approaches depends on the individual use case. Men den allmänna principen är att överväga att använda funktionerna och funktionerna i Azures eko system, där det är möjligt, för att minska migreringens arbets belastning och bygga en kostnads effektiv mål miljö.But, the general principle is to consider using the features and facilities of the Azure ecosystem, where possible, to reduce the migration workload and build a cost-effective target environment. Detta gäller även för andra funktioner, till exempel säkerhets kopiering/återställning och arbets flödes hantering och övervakning.This also holds true for other functions, such as backup/restore and workflow management and monitoring.

Produkter och tjänster som är tillgängliga från Microsoft-partner kan hjälpa till med migrering av data lager och automatisera delar av processen i vissa fall.Products and services available from Microsoft partners can help with data warehouse migrations and automate parts of the process for some cases. Om det befintliga systemet ingår en ETL-produkt från tredje part kanske den redan stöder Azure Synapse Analytics som mål miljö.If the existing system incorporates a third-party ETL product, it might already support Azure Synapse Analytics as a target environment. Befintliga ETL-arbetsflöden kan omdirigeras till det nya mål informations lagret.The existing ETL workflows can be redirected to the new target data warehouse.

Data Marts: fysiska eller virtuellaData marts: Physical or virtual

Det är en vanlig metod för organisationer med äldre data lager miljöer för att skapa datamarter som tillhandahåller sina avdelningar eller affärs funktioner med bra ad hoc självbetjänings fråga och rapportera prestanda.It's a common practice for organizations with older data warehouse environments to create data marts that provide their departments or business functions with good ad hoc self-service query and report performance. En data mart består vanligt vis av en delmängd av data lagret som innehåller sammanställda versioner av ursprungliga data.A data mart typically consists of a subset of the data warehouse that contains aggregated versions of the original data. Sitt formulär, vanligt vis en dimensions data modell, har stöd för att användare enkelt kan fråga data och få snabba svars tider från användarvänliga verktyg som Tableau, mikrostrategi eller Microsoft Power BI.Its form, typically a dimensional data model, supports users to easily query the data and receive fast response times from user-friendly tools like Tableau, MicroStrategy, or Microsoft Power BI.

En användning av data Marts är att visa data i ett användbart formulär, även om den underliggande lager data modellen är något annorlunda (till exempel ett data valv).One use of data marts is to expose the data in a usable form, even if the underlying warehouse data model is something different (such as a data vault). Den här metoden kallas även en modell på tre nivåer.This approach is also known as a three-tier model.

Du kan använda separata datamarter för enskilda affär senheter i en organisation för att implementera robusta data säkerhets regler.You can use separate data marts for individual business units within an organization to implement robust data security regimes. Du kan till exempel ge användar åtkomst till vissa datamarts som är relevanta för dem och eliminera, obfuscate eller maskera känsliga data.For example, you can allow user access to specific data marts relevant to them and eliminate, obfuscate, or anonymize sensitive data.

Om dessa datamarter implementeras som fysiska tabeller kräver de ytterligare lagrings resurser för att hålla dem i bostaden och ytterligare bearbetning för att bygga och uppdatera dem regelbundet.If these data marts are implemented as physical tables, they require additional storage resources to house them and additional processing to build and refresh them regularly. Fysiska tabeller visar att data i Mart endast är aktuella som den senaste uppdateringen, så de kanske inte lämpar sig för data instrument paneler med hög flyktighet.Physical tables show that the data in the mart is only as current as the last refresh operation, so they may not be suitable for highly volatile data dashboards.

Med ankomsten med låg kostnad, skalbart, massivt parallell bearbetnings arkitekturer (MPP) kan du eventuellt tillhandahålla data mart-funktioner utan att behöva instansiera Marten som en uppsättning fysiska tabeller.With the advent of low-cost, scalable massively parallel processing (MPP) architectures, you might be able to provide data mart functionality without needing to instantiate the mart as a set of physical tables. Du kan åstadkomma detta med Azure Synapse Analytics genom att använda någon av dessa metoder för att virtualisera datamarterna:You can achieve this with Azure Synapse Analytics by using one of these methods to virtualize the data marts:

  • SQL-vyer för huvud informations lagret.SQL views on the main data warehouse.
  • Ett Virtualization-lager som använder funktioner som vyer i Azure Synapse Analytics eller Virtualization-produkter från tredje part, till exempel Denodo.A virtualization layer that uses features such as views in Azure Synapse Analytics or third-party virtualization products such as Denodo.

Den här metoden fören klar eller eliminerar behovet av ytterligare lagring och agg regerings bearbetning.This approach simplifies or eliminates the need for additional storage and aggregation processing. Det minskar det totala antalet databas objekt som ska migreras.It reduces the overall number of database objects to be migrated.

En annan fördel med data lager metoden är kapaciteten att köra åtgärder som till exempel kopplingar och agg regeringar på stora data volymer.Another benefit of the data warehouse approach is the capacity to run operations such as joins and aggregations on large data volumes. Du kan till exempel implementera agg regerings-och Join-logiken i ett Virtualization-lager och Visa extern rapportering i en virtualiserad vy genom att skicka den robusta bearbetningen som krävs för att skapa dessa vyer i data lagret.For example, implementing the aggregation and join logic within a virtualization layer and displaying external reporting in a virtualized view push the robust processing required to create these views into the data warehouse.

De primära driv rutinerna för att välja att implementera fysisk eller virtuell data mart implementering är:The primary drivers for choosing to implement physical or virtual data mart implementation are:

  • Mer flexibilitet.More agility. En virtuell data mart är enklare att ändra än fysiska tabeller och tillhör ande ETL-processer.A virtual data mart is easier to change than physical tables and the associated ETL processes.
  • Sänk den totala ägande kostnaden på grund av färre data lager och kopior av data i en virtualiserad implementering.Lower total cost of ownership because of fewer data stores and copies of data in a virtualized implementation.
  • Eli minering av ETL-jobb för att migrera och förenklad data lager arkitektur i en virtualiserad miljö.Elimination of ETL jobs to migrate and simplified data warehouse architecture in a virtualized environment.
  • Prestanda.Performance. Tidigare var fysiska datamarter mer pålitliga.Historically, physical data marts have been more reliable. Virtualization-produkter implementerar nu intelligenta caching-tekniker för att minimera detta.Virtualization products are now implementing intelligent caching techniques to mitigate this.

Du kan också använda datavirtualisering för att visa data till användare konsekvent under ett migreringsjobb.You can also use data virtualization to display data to users consistently during a migration project.

Data mappningData mapping

Nyckel-och integritets begränsningar i Azure Synapse AnalyticsKey and integrity constraints in Azure Synapse Analytics

Begränsningar för primär nyckel och främmande nycklar används inte för närvarande i Azure Synapse Analytics.Primary key and foreign key constraints aren't currently enforced within Azure Synapse Analytics. Du kan dock inkludera definitionen för PRIMARY KEY i CREATE TABLE instruktionen med- NOT ENFORCED satsen.However, you can include the definition for PRIMARY KEY in the CREATE TABLE statement with the NOT ENFORCED clause. Det innebär att rapporterings produkter från tredje part kan använda metadata för tabellen för att förstå nycklarna i data modellen och därför generera de mest effektiva frågorna.This means that third-party reporting products can use the metadata for the table to understand the keys within the data model and therefore generate the most efficient queries.

Stöd för data typer i Azure Synapse AnalyticsData type support in Azure Synapse Analytics

Vissa äldre databas system är stöd för data typer som inte stöds direkt i Azure Synapse Analytics.Some older database systems include support for data types that aren't directly supported within Azure Synapse Analytics. Du kan hantera dessa data typer genom att använda en datatyp som stöds för att lagra data som de är eller genom att omvandla data till en datatyp som stöds.You can handle these data types by using a supported data type to store the data as is or by transforming the data to a supported data type.

Här är en alfabetisk lista över data typer som stöds:Here's an alphabetical list of supported data types:

  • bigint
  • binary [ (n) ]
  • bit
  • char [ (n) ]
  • date
  • datetime
  • datetime2 [ (n) ]
  • datetimeoffset [ (n) ]
  • decimal [ (precision [, scale ]) ]
  • float [ (n) ]
  • int
  • money
  • nchar [ (n) ]
  • numeric [ (precision [ , scale ]) ]
  • nvarchar [ (n | MAX) ]
  • real [ (n) ]
  • smalldatetime
  • smallint
  • smallmoney
  • time [ (n) ]
  • tinyint
  • uniqueidentifier
  • varbinary [ (n | MAX) ]
  • varchar [ (n | MAX) ]

I följande tabell visas vanliga data typer som inte stöds för närvarande, tillsammans med den rekommenderade metoden för att lagra dem i Azure Synapse Analytics.The following table lists common data types that aren't currently supported, together with the recommended approach for storing them in Azure Synapse Analytics.

Datatyp som inte stödsUnsupported data type LösningWorkaround
geometry varbinary
geography varbinary
hierarchyid nvarchar(4000)
image varbinary
text varchar
ntext nvarchar
sql_variant Dela upp kolumnen i flera kolumner med stark typSplit column into several strongly typed columns
table Konvertera till temporära tabellerConvert to temporary tables
timestamp Återworks kod som används datetime2 och CURRENT_TIMESTAMP funktionenRework code to use datetime2 and the CURRENT_TIMESTAMP function
xml varchar
Användardefinierad typUser-defined type Konvertera tillbaka till den interna data typen när det är möjligtConvert back to the native data type when possible

Potentiella data problemPotential data issues

Beroende på käll miljön kan vissa problem orsaka problem när du migrerar data:Depending on the source environment, some issues can cause problems when you're migrating data:

  • Det kan finnas diskreta skillnader i hur NULL data hanteras i olika databas produkter.There can be subtle differences in the way that NULL data is handled in different database products. I exemplen ingår sorterings ordning och hantering av tomma sträng strängar.Examples include collation sequence and handling of empty character strings.
  • DATE, TIME , INTERVAL och TIME ZONE data och associerade funktioner kan variera mycket från produkt till produkt.DATE, TIME, INTERVAL, and TIME ZONE data and associated functions can vary widely from product to product.

Testa dessa noggrant för att avgöra om önskade resultat uppnås i mål miljön.Test these thoroughly to determine whether the desired results are achieved in the target environment. Migreringen kan hitta buggar eller felaktiga resultat som för närvarande är en del av det befintliga käll systemet, och migreringsprocessen är en bra möjlighet att korrigera avvikelser.The migration exercise can uncover bugs or incorrect results that are currently part of the existing source system, and the migration process is a good opportunity to correct anomalies.

Metod tips för att definiera kolumner i Azure Synapse AnalyticsBest practices for defining columns in Azure Synapse Analytics

Det är vanligt att äldre system innehåller kolumner med ineffektiva data typer.It's common for older systems to contain columns with inefficient data types. Du kan till exempel hitta ett fält som definierats som VARCHAR(20) när de faktiska data värdena skulle få plats i ett CHAR(5) fält.For example, you might find a field defined as VARCHAR(20) when the actual data values would fit into a CHAR(5) field. Eller så kan du hitta användningen av INTEGER fält när alla värden skulle få plats i ett SMALLINT fält.Or, you might find the use of INTEGER fields when all values would fit within a SMALLINT field. Otillräckliga data typer kan leda till ineffektivhet i både lagrings-och frågans prestanda, särskilt i stora fakta tabeller.Insufficient data types can lead to inefficiencies in both storage and query performance, especially in large fact tables.

Det är en lämplig tid att kontrol lera och rationalisera aktuella data definitioner under en migrering.It's a good time to check and rationalize current data definitions during a migration exercise. Du kan automatisera dessa uppgifter genom att använda SQL-frågor för att hitta det maximala numeriska värdet eller tecken längden i ett data fält och jämföra resultatet med data typen.You can automate these tasks by using SQL queries to find the maximum numeric value or character length within a data field and comparing the result to the data type.

I allmänhet är det en bra idé att minimera den totala definierade rad längden för en tabell.In general, it's a good practice to minimize the total defined row length for a table. För bästa prestanda för frågor kan du använda den minsta data typen för varje kolumn, enligt beskrivningen ovan.For the best query performance, you can use the smallest data type for each column, as described earlier. Den rekommenderade metoden för att läsa in data från externa tabeller i Azure Synapse Analytics är att använda PolyBase-verktyget, som stöder en maximal definierad rad längd på 1 megabyte (MB).The recommended approach to load data from external tables in Azure Synapse Analytics is to use the PolyBase utility, which supports a maximum defined row length of 1 megabyte (MB). PolyBase läser inte in tabeller med rader som är längre än 1 MB och du måste använda bcp verktyget i stället.PolyBase won't load tables with rows longer than 1 MB, and you must use the bcp utility instead.

För den effektivaste kopplings körningen definierar du kolumnerna på båda sidor av kopplings typen som samma datatyp.For the most efficient join execution, define the columns on both sides of the join as the same data type. Om nyckeln för en dimensions tabell definieras som SMALLINT , bör motsvarande referens kolumner i fakta tabeller som använder dimensionen också definieras som SMALLINT .If the key of a dimension table is defined as SMALLINT, then the corresponding reference columns in fact tables using that dimension should also be defined as SMALLINT.

Undvik att definiera Character-fält med stor standard storlek.Avoid defining character fields with a large default size. Om den maximala storleken på data i ett fält är 50 tecken använder du VARCHAR(50) .If the maximum size of data within a field is 50 characters, use VARCHAR(50). Använd inte på samma sätt NVARCHAR om det VARCHAR är tillräckligt.Similarly, don't use NVARCHAR if VARCHAR will suffice. NVARCHAR lagrar Unicode-data för att tillåta olika språk teckenuppsättningar.NVARCHAR stores Unicode data to allow for different language character sets. VARCHAR lagrar ASCII-data och tar mindre plats.VARCHAR stores ASCII data and takes less space.

Översikt över design rekommendationerSummary of design recommendations

Migrera inte onödiga objekt eller processer.Don't migrate unnecessary objects or processes. Använd inbyggda funktioner och funktioner i Azure-miljön där det behövs för att minska det faktiska antalet objekt och processer som ska migreras.Use built-in features and functions in the target Azure environment where appropriate to reduce the actual number of objects and processes to migrate. Överväg att använda ett Virtualization-lager för att minska eller eliminera antalet fysiska datamarter som du migrerar och för att push-överföra bearbetningen till data lagret.Consider using a virtualization layer to reduce or eliminate the number of physical data marts that you'll migrate and to push down processing into the data warehouse.

Automatisera när det är möjligt och Använd metadata från system kataloger i käll systemet för att generera DDLs för mål miljön.Automate wherever possible, and use metadata from system catalogs in the source system to generate DDLs for the target environment. Om möjligt kan du också automatisera genereringen av dokument.If possible, also automate generating documents. Microsoft-partner som WhereScape kan tillhandahålla specialiserade verktyg och tjänster som hjälper dig med automatisering.Microsoft partners such as WhereScape can provide specialized tools and services to assist with automation.

Utför alla nödvändiga ändringar av data modellen eller optimeringar av data mappning på mål plattformen.Perform any required data model changes or data-mapping optimizations on the target platform. Du kan göra dessa ändringar mer effektivt i Azure Synapse Analytics.You can make these changes more efficiently in Azure Synapse Analytics. Den här metoden minskar påverkan på käll system som kanske redan kör nära till full kapacitet.This approach reduces the impact on source systems that might already be running close to full capacity.

PrestandaalternativPerformance options

I det här avsnittet beskrivs de funktioner som är tillgängliga i Azure Synapse Analytics som du kan använda för att förbättra prestanda för en data modell.This section describes the features available within Azure Synapse Analytics that you can use to improve performance for a data model.

Allmän metodGeneral approach

Plattformens funktioner kör prestanda justering på den databas som ska migreras.The platform's features run performance tuning on the database that will be migrated. Index, data partitionering och data distribution är exempel på sådan prestanda justering.Indexes, data partitioning, and data distribution are examples of such performance tuning. När du förbereder för migrering kan dokumentera och Visa optimeringar som du kan använda i mål miljön i Azure Synapse Analytics för att dokumentera justeringen.When you're preparing for migration, documenting the tuning can capture and reveal optimizations that you can apply in the Azure Synapse Analytics target environment.

Förekomsten av ett icke-unikt index i en tabell kan till exempel ange att fält som används i indexet används ofta för filtrering, gruppering eller koppling.For example, the presence of a non-unique index on a table can indicate that fields used in the index are used frequently for filtering, grouping, or joining. Detta är fortfarande fallet i den nya miljön, så tänk på det när du väljer vilka fält som ska indexeras där.This will still be the case in the new environment, so keep it in mind when you're choosing which fields to index there. Mer detaljerad information om Teradata-och Netezza-miljöer finns i Azure Synapse Analytics-artiklar om lösningar och migrering för Teradata och lösningar och migrering för Netezza.For more detailed information about Teradata or Netezza environments, see Azure the Synapse Analytics articles about solutions and migration for Teradata and solutions and migration for Netezza.

Använd prestanda och skalbarhet för Azure Synapse Analytics-miljön för att experimentera med olika prestanda alternativ som data distribution.Use the performance and scalability of the target Azure Synapse Analytics environment to experiment with different performance options like data distribution. Fastställ det bästa valet av alternativa metoder (till exempel replikerat jämfört med hash-distribuerat för en stor dimensions tabell).Determine the best choice of alternative approaches (for example, replicated versus hash-distributed for a large dimension table). Detta innebär inte att data måste läsas in på nytt från externa källor.This doesn't mean that data must be reloaded from external sources. Det är relativt snabbt och enkelt att testa alternativa metoder i Azure Synapse Analytics genom att skapa kopior av alla tabeller med olika partitionerings-eller distributions alternativ via en CREATE TABLE AS SELECT instruktion.It's relatively quick and easy to test alternative approaches in Azure Synapse Analytics by creating copies of any table with different partitioning or distribution options via a CREATE TABLE AS SELECT statement.

Använd de övervaknings verktyg som tillhandahålls av Azure-miljön för att förstå hur frågor körs och var Flask halsar kan inträffa.Use the monitoring tools provided by the Azure environment to understand how queries are executed and where bottlenecks might be occurring. Verktyg är också tillgängliga från tredjeparts Microsoft-partner för att tillhandahålla övervaknings instrument paneler och automatiserad resurs hantering och aviseringar.Tools are also available from third-party Microsoft partners to provide monitoring dashboards and automated resource management and alerting.

Varje SQL-åtgärd i Azure Synapse Analytics och Resource, till exempel minne eller CPU som används av den frågan, är inloggad i system tabeller.Each SQL operation in Azure Synapse Analytics and resource, such as memory or the CPU used by that query, is logged into system tables. En serie med dynamiska hanterings vyer fören klar åtkomsten till den här informationen.A series of dynamic management views simplifies access to this information.

I följande avsnitt förklaras viktiga alternativ i Azure SQL Data Warehouse för justering av frågeresultat.The following sections explain the key options within Azure SQL Data Warehouse for tuning query performance. Befintliga miljöer kommer att innehålla information om eventuell optimering i mål miljön.Existing environments will contain information about potential optimization in the target environment.

Temporära tabellerTemporary tables

Azure Synapse Analytics stöder temporära tabeller som endast är synliga för den session där de skapades.Azure Synapse Analytics supports temporary tables that are visible only to the session in which they were created. De finns för varaktigheten för en användarsession och tas automatiskt bort i slutet av sessionen.They exist for the duration of a user session and are automatically dropped at the end of the session.

Om du vill skapa en tillfällig tabell ska du ange ett prefix för tabell namnet med hash-tecknen ( # ).To create a temporary table, prefix the table name with the hash character (#). Du kan använda alla vanliga alternativ för indexering och distribution med temporära tabeller, enligt beskrivningen i nästa avsnitt.You can use all the usual indexing and distribution options with temporary tables, as described in the next section.

Temporära tabeller har vissa begränsningar:Temporary tables have some restrictions:

  • Det är inte tillåtet att byta namn på dem.Renaming them isn't allowed.
  • Det är inte tillåtet att visa eller partitionera dem.Viewing or partitioning them isn't allowed.
  • Ändring av behörigheter är inte tillåtet.Changing permissions isn't allowed.

Temporära tabeller används ofta i ETL/ELT-bearbetning, där tillfälliga mellanliggande resultat används som en del av en omvandlings process.Temporary tables are commonly used within ETL/ELT processing, where transient intermediate results are used as part of a transformation process.

Tabell distributions alternativTable distribution options

Azure Synapse Analytics är ett MPP-databassystem som uppnår prestanda och skalbarhet genom att köras parallellt över flera bearbetnings noder.Azure Synapse Analytics is an MPP database system that achieves performance and scalability by running in parallel across multiple processing nodes.

Det idealiska bearbetnings scenariot för att köra en SQL-fråga i en miljö med flera noder är att balansera arbets belastningen och ge alla noder en lika stor mängd data att bearbeta.The ideal processing scenario for running an SQL query in a multinode environment is to balance the workload and give all nodes an equal amount of data to process. Med den här metoden kan du också minimera eller eliminera mängden data som måste flyttas mellan noderna för att uppfylla frågan.This approach also allows you to minimize or eliminate the amount of data that has to be moved between nodes to satisfy the query.

Det kan vara svårt att uppnå det idealiska scenariot eftersom det ofta finns agg regeringar i typiska analys frågor och flera kopplingar mellan flera tabeller, precis som mellan fakta-och dimensions tabeller.It can be challenging to achieve the ideal scenario because there are often aggregations in typical analytics queries and multiple joins between several tables, as between fact and dimension tables.

Ett sätt att påverka hur frågor bearbetas är att använda distributions alternativen i Azure Synapse Analytics för att ange var varje tabells enskilda data rader lagras.One way to influence how queries are processed is to use the distribution options within Azure Synapse Analytics to specify where each table's individual data rows are stored. Anta till exempel att två stora tabeller är kopplade till data kolumnen CUSTOMER_ID .For example, assume that two large tables are joined on the data column, CUSTOMER_ID. Genom att distribuera de två tabellerna genom CUSTOMER_ID kolumnerna när kopplingen utförs, kan du se till att data från varje sida av kopplingen redan finns på samma bearbetnings nod.By distributing the two tables through the CUSTOMER_ID columns whenever that join is performed, you can ensure that the data from each side of the join will already be co-located on the same processing node. Den här metoden eliminerar behovet av att flytta data mellan noder.This method eliminates the need to move data between nodes. Distributions specifikationen för en tabell definieras i CREATE TABLE instruktionen.The distribution specification for a table is defined in the CREATE TABLE statement.

I följande avsnitt beskrivs tillgängliga distributions alternativ och rekommendationer för när du ska använda dem.The following sections describe the available distribution options and recommendations for when to use them. Om det behövs kan du ändra distributionen av en tabell efter den första belastningen: skapa tabellen igen med den nya distributionen genom att använda CREATE TABLE AS SELECT instruktionen.It's possible to change the distribution of a table after the initial load, if necessary: re-create the table with the new distribution by using the CREATE TABLE AS SELECT statement.

ResursallokeringRound robin

Tabell distribution med resursallokering är standard alternativet och sprider data jämnt över noderna i systemet.Round-robin table distribution is the default option and spreads the data evenly across the nodes in the system. Den här metoden är bra för data inläsning och för data som är relativt låga i volymen och som inte har en tydlig kandidat för hashing.This method is good for fast data loading and for data that's relatively low in volume and doesn't have an obvious candidate for hashing. Den används ofta för mellanlagrings tabeller som en del av en ETL-eller ELT-process.It's frequently used for staging tables as part of an ETL or ELT process.

HashHashed

Systemet tilldelar raden till en hash-Bucket, en uppgift baserad på en hash-algoritm som tillämpas på en användardefinierad nyckel som CUSTOMER_ID i föregående exempel.The system assigns the row to a hash bucket, a task based on a hashing algorithm applied to a user-defined key like CUSTOMER_ID in the preceding example. Bucket tilldelas sedan till en speciell nod, och alla data rader hash-distribuerade på samma värde slutar på samma bearbetnings nod.The bucket is then assigned to a specific node, and all data rows hash-distributed on the same value end up on the same processing node.

Den här metoden är användbar för stora tabeller som ofta är anslutna eller aggregerade på en nyckel.This method is useful for large tables that are frequently joined or aggregated on a key. Andra stora tabeller som ska anslutas ska vara hash-värden på samma nyckel om möjligt.Other large tables to be joined should be hashed on the same key if possible. Om det finns flera kandidater för hash-nyckeln väljer du den oftast anslutna till en.If there are multiple candidates for the hash key, choose the most frequently joined one.

Kolumnen hash får inte innehålla NULL-värden och är vanligt vis ett datum eftersom många frågor filtreras efter datum.The hash column shouldn't contain nulls and isn't typically a date because many queries filter on date. Hashing är vanligt vis mer effektivt om nyckeln till hash är ett heltals värde i stället CHAR eller VARCHAR .Hashing is typically more efficient if the key to hash is an integer value instead CHAR or VARCHAR. Undvik att välja nycklar med ett högt skevat värde intervall, t. ex. När ett litet antal nyckel värden representerar en stor del av data raderna.Avoid choosing keys with a highly skewed range of values, like when a small number of key values represent a large percentage of the data rows.

ReplikeradReplicated

Om du väljer replikerad som distributions alternativ för en tabell kommer en fullständig kopia av tabellen att replikeras på varje Compute-nod för frågans bearbetnings syfte.Choosing replicated as the distribution option for a table will cause a complete copy of that table to be replicated on each compute node for query processing purposes.

Den här metoden är användbar för relativt små tabeller (vanligt vis mindre än 2 GB komprimerade) som är relativt statiska och ofta anslutna till större tabeller via en Equi-koppling.This approach is useful for relatively small tables (typically less than 2 GB compressed) that are relatively static and frequently joined to larger tables via an equi-join. Tabellerna är ofta dimensionella tabeller i ett stjärn schema.These tables are often dimensional tables in a star schema.

IndexeringIndexing

Azure Synapse Analytics innehåller alternativ för indexering av data i stora tabeller för att minska de resurser och den tid som krävs för att hämta poster:Azure Synapse Analytics includes options for indexing data in large tables to reduce the resources and time required to retrieve records:

  • Grupperat columnstore-indexClustered columnstore index
  • Grupperat indexClustered index
  • Icke-grupperat indexNon-clustered index

Ett icke-indexerat alternativ, HEAP finns för tabeller som inte drar nytta av något av index alternativen.A non-indexed option, HEAP, exists for tables that don't benefit from any of the index options. Användningen av index är en kompromiss mellan förbättrade fråge tider jämfört med längre inläsnings tider och användning av mer lagrings utrymme.Using indexes is a trade-off between improved query times versus longer load times and usage of more storage space. Index går ofta snabbare SELECT , UPDATE , DELETE och MERGE åtgärder i stora tabeller som påverkar en liten procent andel av data raderna, och de kan minimera fullständiga tabells ökningar.Indexes often speed up SELECT, UPDATE, DELETE, and MERGE operations on large tables that affect a small percentage of the data rows, and they can minimize full table scans.

Index skapas automatiskt när UNIQUE eller PRIMARY KEY begränsningar definieras i kolumner.Indexes are automatically created when UNIQUE or PRIMARY KEY constraints are defined on columns.

Grupperat columnstore-indexClustered columnstore index

Grupperat columnstore-index är standard indexerings alternativet i Azure Synapse Analytics.Clustered columnstore index is the default indexing option within Azure Synapse Analytics. Den ger bästa möjliga komprimering och fråga om prestanda för stora tabeller.It provides the best compression and query performance for large tables. För mindre tabeller med färre än 60 000 000 rader är dessa index inte effektiva, så du bör använda HEAP alternativet.For smaller tables of fewer than 60 million rows, these indexes aren't efficient, so you should use the HEAP option. På samma sätt kan en heap eller en temporär tabell vara mer effektiv om data i en tabell är tillfälliga och ingår i en ETL/ELT-process.Similarly, a heap or a temporary table might be more efficient if the data in a table is transient and part of an ETL/ELT process.

Grupperat indexClustered index

Om det finns ett krav för att regelbundet hämta en enda rad eller ett litet antal rader från en stor tabell baserat på ett starkt filter villkor, kan ett grupperat index vara mer effektivt än ett grupperat columnstore-index.If there's a requirement to regularly retrieve a single row or small number of rows from a large table based on a strong filter condition, a clustered index might be more efficient than a clustered columnstore index. Endast ett grupperat index tillåts per tabell.Only one clustered index is allowed per table.

Icke-grupperat indexNon-clustered index

Icke-grupperade index liknar grupperade index i så att de kan påskynda hämtningen av enstaka rader eller ett litet antal rader baserat på ett filter villkor.Non-clustered indexes are similar to clustered indexes in that they can speed up retrieval of single rows or a small number of rows based on a filter condition. Internt, icke-grupperade index lagras separat från data och flera icke-grupperade index kan definieras i en tabell.Internally, non-clustered indexes are stored separately from the data, and multiple non-clustered indexes can be defined on a table. Men varje ytterligare index kräver mer lagrings utrymme och minskar data flödet för infogning eller inläsning av data.However, each additional index will require more storage and will reduce the throughput of data insert or loading.

HeapHeap

Heap-tabeller innebär ingen av de kostnader som är kopplade till skapandet och underhållet av index vid data inläsnings tid.Heap tables incur none of the overhead associated with the creation and maintenance of indexes at data load time. De kan hjälpa till att snabbt läsa in tillfälliga data under processer, inklusive ELT processer.They can help to quickly load transient data during processes, including ELT processes. Cachelagring kan också hjälpa när data läses omedelbart efteråt.Caching can also assist when the data is read immediately afterward. Eftersom grupperade columnstore-index är ineffektiva under 60 000 000 rader kan heap-tabeller också hjälpa till att lagra tabeller med rader som är mindre än den här mängden.Because clustered columnstore indexes are inefficient below 60 million rows, heap tables can also help to store tables with rows less than this amount.

DatapartitioneringData partitioning

I ett informations lager för företag kan fakta tabeller innehålla flera miljarder rader.In an enterprise data warehouse, fact tables can contain many billions of rows. Partitionering är ett sätt att optimera underhållet och frågorna i dessa tabeller genom att dela upp dem i separata delar för att minska mängden data som bearbetas när frågor körs.Partitioning is a way to optimize the maintenance and querying of these tables by splitting them into separate parts to reduce the amount of data processed when running queries. Partitionerings specifikationen för en tabell definieras i CREATE TABLE instruktionen.The partitioning specification for a table is defined in the CREATE TABLE statement.

Du kan bara använda ett fält per tabell för partitionering.You can use only one field per table for partitioning. Det är ofta ett datum fält, eftersom många frågor filtreras efter ett datum eller ett datum intervall.It's frequently a date field because many queries are filtered by a date or date range. Du kan ändra partitionering för en tabell efter den första inläsningen, om det behövs, genom att skapa tabellen igen med den nya distributionen genom CREATE TABLE AS SELECT instruktionen.You can change the partitioning of a table after initial load, if necessary, by re-creating the table with the new distribution through the CREATE TABLE AS SELECT statement.

Partitionering för optimering av fråga: Om frågor mot en stor fakta tabell ofta filtreras med en viss data kolumn, kan partitionering i den kolumnen avsevärt minska mängden data som behöver bearbetas för att utföra frågorna.Partitioning for query optimization: If queries against a large fact table are frequently filtered by a certain data column, then partitioning on that column can significantly reduce the amount of data that needs to be processed to perform the queries. Ett vanligt exempel är att använda ett datum fält för att dela upp tabellen i mindre grupper.A common example is to use a date field to split the table into smaller groups. Varje grupp innehåller data för en enda dag.Each group contains data for a single day. När en fråga innehåller en- WHERE sats som filtrerar på datumet måste endast partitioner som matchar datum filtret vara tillgängliga.When a query contains a WHERE clause that filters on the date, only partitions that match the date filter need to be accessed.

Partitionering för optimering av tabell underhåll: Det är vanligt att data lager miljöer upprätthåller en rullande fönster med detaljerade fakta uppgifter.Partitioning for optimization of table maintenance: It's common for data warehouse environments to maintain a rolling window of detailed fact data. Ett exempel är försäljnings transaktioner som går tillbaka fem år.An example is sales transactions that go back five years. Genom att partitionera på försäljnings datumet blir det mycket mer effektivt att ta bort gamla data bortom det rullande fönstret.By partitioning on the sales date, the removal of old data beyond the rolling window becomes much more efficient. Att släppa den äldsta partitionen går snabbare och använder färre resurser än att ta bort varje enskild rad.Dropping the oldest partition is quicker and uses fewer resources than deleting each individual row.

StatistikStatistics

När en fråga skickas till Azure Synapse Analytics bearbetas den först av fråge optimeringen.When a query is submitted to Azure Synapse Analytics, it's first processed by the query optimizer. Optimeringen fastställer de bästa interna metoderna för att köra frågan effektivt.The optimizer determines the best internal methods to execute the query efficiently.

Optimeringen jämför de olika fråge körnings planer som är tillgängliga baserat på en kostnads baserad algoritm.The optimizer compares the various query-execution plans that are available based on a cost-based algorithm. Noggrannheten för kostnads uppskattningarna beror på vilken statistik som är tillgänglig.The accuracy of the cost estimates is dependent on the statistics available. Det är en bra idé att se till att statistiken är aktuell.It's a good practice to ensure that statistics are up to date.

Om alternativet är aktiverat i Azure Synapse Analytics AUTO_CREATE_STATISTICS utlöses en automatisk uppdatering av statistik.In Azure Synapse Analytics, if the AUTO_CREATE_STATISTICS option is turned on, it will trigger an automatic update of statistics. Du kan också skapa eller uppdatera statistik manuellt via CREATE STATISTICS kommandot.You can also create or update statistics manually via the CREATE STATISTICS command.

Uppdatera statistik när innehållet har ändrats väsentligen, till exempel i en daglig uppdatering.Refresh statistics when the contents have changed substantially, such as in a daily update. Den här uppdateringen kan införlivas i en ETL-process.This refresh can be incorporated into an ETL process.

Alla tabeller i databasen ska ha statistik som samlats in på minst en kolumn.All tables in the database should have statistics collected on at least one column. Det säkerställer att grundläggande information, till exempel radantal och tabell storlek, är tillgänglig för optimeringen.It ensures that basic information such as row count and table size is available to the optimizer. Andra kolumner som ska samlas in statistik är kolumner som anges i JOIN ,, DISTINCT ORDER BY och GROUP BY bearbetning.Other columns that should have statistics collected are columns specified in JOIN, DISTINCT, ORDER BY, and GROUP BY processing.

ArbetsbelastningshanteringWorkload management

Azure Synapse Analytics omfattar omfattande funktioner för att hantera resursutnyttjande över blandade arbets belastningar.Azure Synapse Analytics incorporates comprehensive features for managing resource utilization across mixed workloads. Genom att skapa resurs klasser för olika arbets belastnings typer, till exempel frågor och data inläsning, kan du hantera din arbets belastning.Creating resource classes for different workload types, such as queries versus data load, helps you manage your workload. Den anger gränser för antalet frågor som körs samtidigt och på de beräknings resurser som tilldelats varje fråga.It sets limits on the number of queries that run concurrently and on the compute resources assigned to each query. Det finns en kompromiss mellan minne och samtidighet:There's a trade-off between memory and concurrency:

  • Mindre resurs klasser minskar högsta mängd minne per fråga men ökar samtidigheten.Smaller resource classes reduce the maximum memory per query but increase concurrency.
  • Större resurs klasser ökar det maximala minnet per fråga men minskar samtidigheten.Larger resource classes increase the maximum memory per query but reduce concurrency.

PrestandarekommendationerPerformance recommendations

Använd metoder för prestanda förbättring som index eller data distribution för att mäta kandidater för liknande metoder i den nya mål miljön, men benchmark för att bekräfta att de är nödvändiga i Azure Synapse Analytics.Use performance improvement methods like indexes or data distribution to gauge candidates for similar methods in the new target environment, but benchmark to confirm that they're necessary in Azure Synapse Analytics. Skapa COLLECT STATISTICS steg i ETL/ELT-processer för att se till att statistiken är aktuell eller Välj att automatiskt skapa statistik.Build COLLECT STATISTICS steps into ETL/ELT processes to ensure that statistics are up to date, or select to automatically create statistics.

Förstå de justerings alternativ som är tillgängliga i Azure Synapse Analytics och prestanda egenskaperna för associerade verktyg, till exempel PolyBase för snabb parallell data inläsning.Understand the tuning options available in Azure Synapse Analytics and the performance characteristics of associated utilities, such as PolyBase for fast parallel data loading. Använd de här alternativen för att bygga en effektiv implementering från slut punkt till slut punkt.Use these options to build an efficient end-to-end implementation.

Använd flexibilitet, skalbarhet och prestanda i Azure-miljön för att implementera data modell ändringar eller alternativ för prestanda justering på plats.Use the flexibility, scalability, and performance of the Azure environment to implement any data model changes or performance tuning options in place. Den här ansträngningen kommer att minska påverkan på befintliga käll system.This effort will reduce the impact on existing source systems.

Förstå de dynamiska hanterings vyer som är tillgängliga i Azure Synapse Analytics.Understand the dynamic management views available in Azure Synapse Analytics. Dessa vyer ger både information om resursutnyttjande och detaljerad körnings information för enskilda frågor.These views provide both system-wide resource utilization information and detailed execution information for individual queries.

Förstå Azures resurs klasser och allokera dem på lämpligt sätt för att säkerställa effektiv hantering av blandade arbets belastningar och samtidighet.Understand Azure resource classes and allocate them appropriately to ensure efficient management of mixed workloads and concurrency.

Överväg att använda ett Virtualization-lager som en del av Azure Synapse Analytics-miljön.Consider using a virtualization layer as part of the Azure Synapse Analytics environment. Det kan skärma förändringar i lager implementeringen från affärs användare och rapporterings verktyg.It can shield changes in the warehouse implementation from business users and reporting tools.

Research partner – tillhandahållna Migreringsverktyg och tjänster som Qlik replikera för Microsoft-migreringar, WhereScape och Datometry.Research partner-provided migration tools and services such as Qlik Replicate for Microsoft migrations, WhereScape, and Datometry. Dessa tjänster kan automatisera delar av migreringsprocessen och minska den tid och risk som ingår i ett migreringsjobb.These services can automate parts of the migration process and reduce the elapsed time and risk involved in a migration project.