Vad är Data Mart i Data Warehouse? Typer och exempel

⚡ Smart sammanfattning

Data Mart-design levererar en fokuserad delmängd av datalagerinformation till en avdelning, som omfattar de tre data mart-typerna, de fem faserna från design till hantering, och de bästa metoderna som säkerställer snabb, säker och kostnadseffektiv leverans.

  • 🎯 Definition: En datamart är en ämnesorienterad delmängd av ett datalager, byggd för en avdelning som försäljning, marknadsföring, HR eller finans.
  • 🧩 Marknadstyper: Beroende butiker hämtar varor från ett centrallager, oberoende butiker hämtar varor direkt från operativa system och hybridbutiker kombinerar båda.
  • ⚙️ Implementeringsfaser: Att bygga en datamart går genom att designa, konstruera, fylla i, komma åt och hantera.
  • 🔌 ETL och RDBMS: Ett RDBMS lagrar marten medan ett ETL-verktyg mappar, t.ex.tracts, transformerar, rensar och laddar källdata plus metadata.
  • 📊 Dimensionell design: Att modellera data kring ett stjärnschema snabbar upp frågor och förenklar rapportering för affärsanvändare.
  • ???? Affärspåverkan: En mindre omfattning innebär snabbare frågor, lägre kostnad, striktare åtkomstkontroll och snabbare leverans än ett fullt lager.
  • 🧭 Bästa praxis: Håll leveranscykeln till veckor, budgetera hårdvara och nätverk och involvera alla intressenter tidigt.

Data Mart i ett datalager som visar beroende, oberoende och hybrida data marts

En datamart ger den analytiska kraften hos en datalagret till ett enda team. Genom att fokusera på ett ämnesområde kan en avdelning snabbt analysera sina egna data utan att behöva vänta på företagsomfattande arbetsbelastningar. Avsnitten nedan förklarar vad en datamart är, varför organisationer använder en, de tre typer som finns tillgängliga och hur man implementerar och hanterar en.

Vad är Data Mart?

En datamart är fokuserad på ett enda funktionellt område i en organisation och innehåller en delmängd av de data som lagras i en DatalagerDet är en kondenserad version av ett datalager, utformat för användning av en specifik avdelning, enhet eller användargrupp – till exempel marknadsföring, försäljning, HR eller ekonomi.

Eftersom en datamart endast har en funktion styrs den vanligtvis av en enda avdelning inom organisationen. Det fokuset håller dess omfattning begränsad och dess ägarskap tydligt.

En datamart hämtar också data från endast ett fåtal källor, till skillnad från ett datalager som integrerar många. Som ett resultat är datamarts små i storlek och mycket mer flexibla än ett komplett datalager.

Varför behöver vi Data Mart?

Organisationer förlitar sig på datamarts av flera praktiska skäl:

  • En datamart förbättrar användarnas svarstid genom att minska mängden data de frågar efter.
  • Det ger enkel åtkomst till ofta efterfrågade data.
  • Ett datacenter är enklare och billigare att implementera än ett företagsdatalager.
  • Den är agil: när modellen ändras kan en mindre datamart snabbt byggas om.
  • En datamart definieras av en enda ämnesexpert, medan ett datalager definieras av ett tvärvetenskapligt team, så en mart är mer öppen för förändring.
  • Data partitioneras, vilket möjliggör mycket detaljerade åtkomstkontrollprivilegier.
  • Data kan segmenteras och lagras på olika hårdvaru- eller mjukvaruplattformar.

Kort sagt, eftersom ett datamart hanterar en mindre, väldefinierad dataskiva, är det snabbare att bygga, billigare att driva och enklare att säkra än ett företagsdatalager.

Datamart är dock inte alla uppbyggda på samma sätt. Källan en mart hämtar data från avgör vilken av tre typer du arbetar med.

Typer av Data Mart

Det finns tre huvudtyper av datamart, som skiljer sig åt genom var de hämtar sina data:

  1. Beroende: Beroende datamarts hämtar data direkt från operativa källor, externa källor eller båda.
  2. Oberoende: En oberoende datamart skapas utan ett centralt datalager.
  3. Hybrid: En hybrid datamart kan ta data från datalager eller operativa system.

Beroende Data Mart

En beroende datamart hämtar en organisations data från ett enda datalager, vilket ger den fördelen av centralisering. Om du behöver bygga en eller flera fysiska datamarts konfigurerar du dem som beroende datamarts.

En beroende datamart kan byggas på två sätt: ett där användare får åtkomst till både datamarten och datalagret beroende på behov, och ett där åtkomsten är begränsad till endast datamarten. Det andra tillvägagångssättet är inte optimalt, eftersom det kan skapa en "dataskräpgård" – data som börjar från en gemensam källa men sedan skrotas och till stor del används.

Beroende datalager hämtar data från ett enda datalager
Beroende Data Mart

Independent Data Mart

En oberoende datamart skapas utan ett centralt datalager. Denna typ av datamart är ett idealiskt alternativ för mindre grupper inom en organisation.

En oberoende datamart har ingen relation till ett företagsdatalager eller till någon annan datamart. Dess data laddas och analyseras på egen hand. Denna metod strider mot huvudskälet till att bygga ett datalager från första början: en konsekvent, centraliserad lagring av företagsdata som många användare med olika intressen kan analysera.

Oberoende datacenter skapat utan centralt datalager

Independent Data Mart

Hybrid Data Mart

En hybrid datamart kombinerar input från källor utanför datalagret. Detta är användbart när du behöver ad hoc-integration – till exempel efter att en ny grupp eller produkt har lagts till i organisationen.

Den är väl lämpad för miljöer med flera databaser och erbjuder en snabb implementeringsprocess med minsta möjliga datareningsinsats. En hybrid datamart stöder även stora lagringsstrukturer och fungerar bra för mindre, datacentrerade applikationer.

Hybrid Data Mart som kombinerar ett datalager med andra källor

Hybrid Data Mart

Steg för att implementera en Datamart

De fem stegen i implementeringen av en datamart

Steg för att implementera en Datamart

Att implementera en datamart är en givande men detaljerad process. Den går igenom fem faser – design, konstruktion, ifyllning, åtkomst och hantering – som var och en beskrivs nedan.

Utforma

Design är den första fasen i implementeringen av en datamart. Den täcker alla uppgifter från den första begäran om en datamart till att samla in krav, och den slutar med den logiska och fysiska designen av datamarten.

Designsteget innefattar följande uppgifter:

  • Samla in affärs- och tekniska krav och identifiera datakällor.
  • Välja lämplig delmängd av data.
  • Designa den logiska och fysiska strukturen för datamarknaden.

Data kan partitioneras baserat på följande kriterier:

  • Datum
  • Affärs- eller funktionell enhet
  • Geografi
  • Vilken kombination som helst av ovanstående

Data kan partitioneras på applikations- eller DBMS-nivå, men partitionering på applikationsnivå rekommenderas eftersom det möjliggör en annan datamodell varje år i takt med att affärsmiljön förändras. De flesta datamarts är byggda på en dimensionell modell, såsom ett stjärnschema, för att hålla frågor snabba.

Vilka produkter och teknologier behöver du?

En enkel penna och papper räcker i det här skedet. Verktyg som hjälper dig att skapa UML- eller entitetsrelationsdiagram kan också lägga till metadata i dina logiska och fysiska designer.

konstruera

Konstruktion är den andra fasen av implementeringen. Det innebär att skapa den fysiska databasen och de logiska strukturerna.

Det här steget omfattar följande uppgift:

  • Implementera den fysiska databasen som designades i den tidigare fasen – till exempel skapa schemaobjekt som tabeller, index och vyer.

Vilka produkter och teknologier behöver du?

Du behöver ett relationsdatabashanteringssystem (RDBMS) för att bygga en datamart. En RDBMS erbjuder flera funktioner som är avgörande för en datamarts framgång:

  • Lagringshantering: Ett RDBMS lagrar och hanterar data, vilket låter dig skapa, lägga till och ta bort poster.
  • Snabb dataåtkomst: Med en SQL-fråga kan du enkelt hämta data baserat på specifika villkor eller filter.
  • Dataskydd: RDBMS kan återställa från systemfel som strömavbrott och återställa data från säkerhetskopior om en disk slutar fungera.
  • Fleranvändarstöd: Den erbjuder samtidig åtkomst, så flera användare kan läsa och ändra data utan att skriva över varandras ändringar.
  • Säkerhet: Den reglerar vilka användare som har åtkomst till vilka objekt och vilka operationer de kan utföra.

Befolkar

I den tredje fasen matas data in i datamarten.

Ifyllningssteget innefattar följande uppgifter:

  • Kartaping källdata till måldata.
  • Extrackälldata.
  • Rengöring och omvandling av data.
  • Laddar in data i datamarten.
  • Skapa och lagra metadata.

Vilka produkter och teknologier behöver du?

Du utför dessa uppgifter med en ETL (t.ex.tract, Transformera, Ladda) verktyg. Det undersöker datakällorna, utför en mappning mellan källa och målping, och sedan extracts, transformerar, rensar och laddar in data i datamarten.

Längs vägen skapar verktyget även metadata – detaljer som var informationen kommer ifrån, hur aktuell den är, vilka ändringar som gjorts och vilken sammanfattningsnivå som tillämpades.

Åtkomst

Åtkomst är det fjärde steget, och det ger tillgång till informationen: frågar efter data, skapar rapporter och diagram och publicerar dem. Slutanvändare skickar in frågor och visar resultaten, ofta genom OLAP verktyg.

Åtkomststeget omfattar följande uppgifter:

  • Skapa ett metalager som översätter databasstrukturer och objektnamn till affärstermer, så att icke-tekniska användare enkelt kan komma åt datamarten.
  • Upprätta och underhålla databasstrukturer.
  • Konfigurera API:er och gränssnitt vid behov.

Vilka produkter och teknologier behöver du?

Du kan komma åt datamarten med hjälp av kommandoraden eller ett grafiskt gränssnitt. Ett grafiskt gränssnitt är oftast att föredra eftersom det genererar grafer enkelt och är mer användarvänligt än kommandoraden.

Hantering

Att hantera är den sista fasen i implementeringsprocessen för en datamart. Med hjälp av antingen ett grafiskt gränssnitt eller kommandoraden hanterar teamen löpande hanteringsuppgifter som:

  • Löpande användaråtkomsthantering.
  • Systemoptimering och finjustering för bättre prestanda.
  • Lägga till och hantera färsk data i datamarten.
  • Planera återställningsscenarier för att hålla systemet tillgängligt om det går sönder.
  • Återställning från hårdvaru- och mjukvarufel samtidigt som data bevaras.

Bästa metoder för implementering av Data Marts

Följ dessa bästa praxis under hela implementeringsprocessen för datamarten:

  • Strukturera källan för en datamart efter avdelning.
  • Mät implementeringscykeln i veckor snarare än månader eller år.
  • Involvera alla intressenter i planerings- och designfasen, eftersom en implementering av en datamart kan vara komplex.
  • Budgetera noggrant för kostnader för hårdvara, programvara, nätverk och implementering för datamart.
  • Även när en datamart delar hårdvara kan den behöva olika programvaror för att hantera användarfrågor; bedöm den extra processorkraft och lagring som behövs för snabba svar.
  • När ett datamart finns på en annan plats än datalagret, se till att nätverkskapaciteten är tillräcklig för att flytta de nödvändiga datavolymerna.
  • Budget för laddningstid, som växer i takt med att transformationernas komplexitet ökar.

Fördelar och nackdelar med en datamart

Precis som alla arkitekturval medför en datamart tydliga fördelar tillsammans med några nackdelar.

Fördelar

  • En datamart innehåller en delmängd av organisationsomfattande data som är värdefull för en specifik grupp användare.
  • Det är ett kostnadseffektivt alternativ till ett datalager, vilket kan vara dyrt att bygga.
  • En datamart möjliggör snabbare åtkomst till data.
  • Den är lätt att använda eftersom den är utformad för användarnas specifika behov, vilket kan accelerera affärsprocesser.
  • Ett datamart behöver mindre implementeringstid än ett datalager, eftersom man bara fokuserar på en delmängd av datan.
  • Den innehåller historisk data som hjälper analytiker att identifiera trender.

Nackdelar

  • Företag skapar ibland för många olikartade, orelaterade datamarts, vilka blir svåra att underhålla.
  • En datamart kan inte tillhandahålla företagsomfattande dataanalys eftersom dess datamängd är begränsad.

Vanliga frågor

A datalagret är ett företagsomfattande arkiv som täcker alla ämnen, medan en datamart innehåller en mindre, ämnesorienterad delmängd för en avdelning. Datamarts är billigare, snabbare att bygga och snabbare att fråga efter, men de kan inte leverera företagsomfattande analyser.

En datamart lagrar strukturerad, bearbetad data modellerad för en affärsfunktion. En datasjö lagrar rådata av alla typer – strukturerad, semistrukturerad eller ostrukturerad – i stor skala. Datamart erbjuder snabb rapportering medan sjöar stöder utforskande datavetenskap och maskininlärning.

De flesta datamarts använder en dimensionell modell, vanligtvis ett stjärnschema med en central faktatabell kopplad till dimensionstabeller. Ett snöflingeschema normaliserar dessa dimensioner ytterligare. Både snabbar upp frågor och förenklar rapportering för affärsanvändare.

En försäljningsdatamart innehåller kundtransaktioner, intäkter och pipeline-statistik för säljteamet. Marknadsförings-, finans- och HR-marts fungerar på samma sätt och ger varje avdelning föraggregerad data utan att hela företagets datalager ska frågas.

En datamart stöder OLAP, inte OLTP. Den är optimerad för att läsa, aggregera och analysera historisk data för rapporter och instrumentpaneler, snarare än för de snabba infogningar och uppdateringar som transaktionella OLTP-system hanterar.

En molnbaserad datamart körs på en hanterad molnbaserad datalagerplattform istället för lokala servrar. Den eliminerar hårdvaruhantering, skalar lagring och beräkning på begäran, och fakturerar vanligtvis per fråga, vilket sänker kostnaden och snabbar upp distributionen.

AI och maskininlärningsverktyg snabbar upp arbetet på datamarknaden genom att profilera källdata, rekommendera scheman och dimensioner samt generera ETL-kartor.pings och flaggar problem med datakvaliteten. De föreslår också partitionerings- och indexeringsstrategier, även om ingenjörer bör granska varje rekommendation innan de driftsätts till produktion.

Ja. ChatGPT och GitHub Copilot utkast till SQL-frågor, stjärnschema-DDL och ETL-skript från en kort prompt. RevVisa utdata för korrekta tabellnamn, kopplingar och kornighet innan du kör den, eftersom genererad kod kan missa affärsregler.

Sammanfatta detta inlägg med: