OLAP (Online Analytical Processing)

Azure Analysis Services

Onlineanalysbearbetning (OLAP) är en teknik som organiserar stora affärsdatabaser och stöder komplex analys. Den kan användas för att utföra komplexa analysfrågor utan att påverka transaktionssystem negativt.

De databaser som ett företag använder för att lagra alla sina transaktioner och poster kallas OLTP-databaser (online transaction processing). Dessa databaser har vanligtvis poster som anges en i taget. Ofta innehåller de en hel del information som är värdefull för organisationen. De databaser som används för OLTP har dock inte utformats för analys. Därför är det dyrt att hämta svar från dessa databaser när det gäller tid och arbete. OLAP-system har utformats för att extrahera denna business intelligence-information från data på ett mycket högpresterande sätt. Det beror på att OLAP-databaser är optimerade för tunga läs- och lågskrivningsarbetsbelastningar.

Diagram that shows the OLAP logical architecture in Azure.

Semantikmodellering

En semantisk datamodell är en konceptuell modell som beskriver innebörden av de dataelement som den innehåller. Organisationer har ofta egna villkor för saker, ibland med synonymer eller till och med olika betydelser för samma term. En inventeringsdatabas kan till exempel spåra en utrustning med ett tillgångs-ID och ett serienummer, men en försäljningsdatabas kan referera till serienumret som tillgångs-ID. Det finns inget enkelt sätt att relatera dessa värden utan en modell som beskriver relationen.

Semantisk modellering ger en abstraktionsnivå över databasschemat, så att användarna inte behöver känna till de underliggande datastrukturerna. Detta gör det enklare för slutanvändare att fråga efter data utan att utföra aggregeringar och kopplingar över det underliggande schemat. Dessutom byts kolumner vanligtvis namn till mer användarvänliga namn, så att kontexten och innebörden av data är mer uppenbara.

Semantisk modellering används huvudsakligen för läsintensiva scenarier, till exempel analys och business intelligence (OLAP), i stället för mer skrivintensiv transaktionsdatabearbetning (OLTP). Detta beror främst på arten av ett typiskt semantiskt lager:

  • Sammansättningsbeteenden anges så att rapportverktygen visar dem korrekt.
  • Affärslogik och beräkningar definieras.
  • Tidsorienterade beräkningar ingår.
  • Data är ofta integrerade från flera källor.

Traditionellt placeras det semantiska lagret över ett informationslager av dessa skäl.

Example diagram of a semantic layer between a data warehouse and a reporting tool

Det finns två primära typer av semantiska modeller:

  • Tabell. Använder relationsmodelleringskonstruktioner (modell, tabeller, kolumner). Internt ärvs metadata från OLAP-modelleringskonstruktioner (kuber, dimensioner, mått). Kod och skript använder OLAP-metadata.
  • Flerdimensionellt. Använder traditionella OLAP-modelleringskonstruktioner (kuber, dimensioner, mått).

Relevant Azure-tjänst:

Exempel på användningsfall

En organisation har data som lagras i en stor databas. Den vill göra dessa data tillgängliga för företagsanvändare och kunder för att skapa egna rapporter och göra en analys. Ett alternativ är bara att ge dessa användare direkt åtkomst till databasen. Det finns dock flera nackdelar med att göra detta, inklusive att hantera säkerhet och kontrollera åtkomst. Dessutom kan designen av databasen, inklusive namnen på tabeller och kolumner, vara svår för en användare att förstå. Användarna skulle behöva veta vilka tabeller som ska frågas, hur tabellerna ska kopplas och annan affärslogik som måste tillämpas för att få rätt resultat. Användarna skulle också behöva känna till ett frågespråk som SQL även för att komma igång. Detta leder vanligtvis till att flera användare rapporterar samma mått men med olika resultat.

Ett annat alternativ är att kapsla in all information som användarna behöver i en semantisk modell. Den semantiska modellen kan enklare efterfrågas av användare med ett rapporteringsverktyg som de väljer. Data som tillhandahålls av den semantiska modellen hämtas från ett informationslager, vilket säkerställer att alla användare ser en enda version av sanningen. Den semantiska modellen innehåller också egna tabell- och kolumnnamn, relationer mellan tabeller, beskrivningar, beräkningar och säkerhet på radnivå.

Typiska egenskaper för semantisk modellering

Semantisk modellering och analytisk bearbetning tenderar att ha följande egenskaper:

Krav Beskrivning
Schema Schema vid skrivning, starkt framtvingat
Använder transaktioner Nej
Låsningsstrategi Ingen
Uppdaterbar Nej (kräver vanligtvis omberäkningskub)
Tilläggsbart Nej (kräver vanligtvis omberäkningskub)
Arbetsbelastning Tunga läsningar, skrivskyddade
Indexering Flerdimensionell indexering
Datumstorlek Liten till medelstor
Modell Flerdimensionella
Dataform: Kub- eller star/snowflake-schema
Frågeflexflexitet Mycket flexibel
Skalning: Stor (10s-100s GBs)

När du ska använda den här lösningen

Överväg OLAP i följande scenarier:

  • Du måste köra komplexa analytiska och ad hoc-frågor snabbt, utan att påverka OLTP-system negativt.
  • Du vill ge företagsanvändare ett enkelt sätt att generera rapporter från dina data
  • Du vill ange ett antal aggregeringar som gör att användarna kan få snabba, konsekventa resultat.

OLAP är särskilt användbart för att tillämpa aggregerade beräkningar över stora mängder data. OLAP-system är optimerade för läsintensiva scenarier, till exempel analys och business intelligence. Med OLAP kan användare segmentera flerdimensionella data i sektorer som kan visas i två dimensioner (till exempel en pivottabell) eller filtrera data efter specifika värden. Den här processen kallas ibland "segmentering och diktering" av data och kan göras oavsett om data partitioneras över flera datakällor. Detta hjälper användarna att hitta trender, upptäcka mönster och utforska data utan att behöva känna till detaljerna i traditionell dataanalys.

Semantiska modeller kan hjälpa företagsanvändare att sammanfatta relationskomplexiteter och göra det enklare att analysera data snabbt.

Utmaningar

För alla fördelar som OLAP-system ger skapar de några utmaningar:

  • Medan data i OLTP-system ständigt uppdateras genom transaktioner som flödar in från olika källor, uppdateras OLAP-datalager vanligtvis med mycket långsammare intervall, beroende på företagets behov. Det innebär att OLAP-system är bättre lämpade för strategiska affärsbeslut snarare än omedelbara svar på ändringar. Dessutom måste en viss nivå av datarensning och orkestrering planeras för att hålla OLAP-datalager uppdaterade.
  • Till skillnad från traditionella, normaliserade relationstabeller som finns i OLTP-system tenderar OLAP-datamodeller att vara flerdimensionella. Detta gör det svårt eller omöjligt att direkt mappa till entitetsrelationer eller objektorienterade modeller, där varje attribut mappas till en kolumn. I stället använder OLAP-system vanligtvis ett star- eller snowflake-schema i stället för traditionell normalisering.

OLAP i Azure

I Azure kopieras data som lagras i OLTP-system som Azure SQL Database till OLAP-systemet, till exempel Azure Analysis Services. Datautforsknings- och visualiseringsverktyg som Power BI, Excel och tredjepartsalternativ ansluter till Analysis Services-servrar och ger användarna mycket interaktiva och visuellt omfattande insikter om modellerade data. Dataflödet från OLTP-data till OLAP orkestreras vanligtvis med SQL Server Integration Services, som kan köras med Hjälp av Azure Data Factory.

I Azure uppfyller alla följande datalager huvudkraven för OLAP:

SQL Server Analysis Services (SSAS) erbjuder OLAP- och datautvinningsfunktioner för business intelligence-program. Du kan antingen installera SSAS på lokala servrar eller vara värd på en virtuell dator i Azure. Azure Analysis Services är en fullständigt hanterad tjänst som tillhandahåller samma viktiga funktioner som SSAS. Azure Analysis Services stöder anslutning till olika datakällor i molnet och lokalt i din organisation.

Grupperade Columnstore-index är tillgängliga i SQL Server 2014 och senare, samt Azure SQL Database, och är idealiska för OLAP-arbetsbelastningar. Från och med SQL Server 2016 (inklusive Azure SQL Database) kan du dock dra nytta av hybridtransaktions-/analysbearbetning (HTAP) med hjälp av uppdateringsbara icke-illustrerade kolumnlagringsindex. Med HTAP kan du utföra OLTP- och OLAP-bearbetning på samma plattform, vilket tar bort behovet av att lagra flera kopior av dina data och eliminerar behovet av distinkta OLTP- och OLAP-system. Mer information finns i Komma igång med Columnstore för driftanalys i realtid.

Kriterier för nyckelval

För att begränsa alternativen börjar du med att svara på följande frågor:

  • Vill du ha en hanterad tjänst i stället för att hantera dina egna servrar?

  • Behöver du säker autentisering med Hjälp av Microsoft Entra-ID?

  • Vill du utföra realtidsanalyser? I så fall begränsar du dina alternativ till dem som stöder realtidsanalys.

    Realtidsanalys i den här kontexten gäller för en enda datakälla, till exempel ett ERP-program (Enterprise Resource Planning), som kör både en drifts- och analysarbetsbelastning. Om du behöver integrera data från flera källor eller kräva extrema analysprestanda med hjälp av föraggregerade data, till exempel kuber, kan du fortfarande kräva ett separat informationslager.

  • Behöver du använda föraggregerade data, till exempel för att tillhandahålla semantiska modeller som gör analys mer användarvänlig för företag? Om ja väljer du ett alternativ som stöder flerdimensionella kuber eller tabell semantiska modeller.

    Genom att tillhandahålla aggregeringar kan användarna konsekvent beräkna dataaggregeringar. Föraggregerade data kan också ge en stor prestandaökning när du hanterar flera kolumner på många rader. Data kan föraggregeras i flerdimensionella kuber eller tabellsemantiska modeller.

  • Behöver du integrera data från flera källor utöver ditt OLTP-datalager? I så fall bör du överväga alternativ som enkelt integrerar flera datakällor.

Kapacitetsmatris

I följande tabeller sammanfattas de viktigaste skillnaderna i funktioner.

Allmänna funktioner

Kapacitet Azure Analysis Services SQL Server Analysis Services SQL Server med Columnstore-index Azure SQL Database med Columnstore-index
Är hanterad tjänst Ja No No Ja
Stöder flerdimensionella kuber Nej Ja No Nej
Stöder tabellsemantiska modeller Ja Ja No Nej
Integrera enkelt flera datakällor Ja Ja Nr 1 Nr 1
Stöder realtidsanalys Nej No Ja Ja
Kräver process för att kopiera data från källor Ja Ja No Nej
Microsoft Entra-integrering Ja Nej Nr 2 Ja

[1] Även om SQL Server och Azure SQL Database inte kan användas för att fråga från och integrera flera externa datakällor, kan du fortfarande skapa en pipeline som gör detta åt dig med hjälp av SSIS eller Azure Data Factory. SQL Server som finns på en virtuell Azure-dator har ytterligare alternativ, till exempel länkade servrar och PolyBase. Mer information finns i Pipelineorkestrering, kontrollflöde och dataflytt.

[2] Anslut ing till SQL Server som körs på en virtuell Azure-dator stöds inte med ett Microsoft Entra-konto. Använd ett Active Directory-domänkonto i stället.

Skalbarhetsfunktioner

Kapacitet Azure Analysis Services SQL Server Analysis Services SQL Server med Columnstore-index Azure SQL Database med Columnstore-index
Redundanta regionala servrar för hög tillgänglighet Ja No Ja Ja
Stöder utskalning av frågor Ja No Ja Ja
Dynamisk skalbarhet (skala upp) Ja No Ja Ja

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Nästa steg