Den kontinuerlige lanseringen av datatjenester i Azure har utløst både spenning og forvirring innen datalagring av flere grunner. Kunder er interessert i konseptet med et moderne skybasert datavarehus, men kan bli overveldet av overfloden av skybaserte tjenester tilgjengelig på markedet. De er interessert i å vite hvordan de kan komme i gang med å implementere tradisjonelle datavarehuskonsepter som dimensjonell modellering, sakte endrede dimensjoner, stjernediagram og datavarehus ETL eller ELT prosessering i skyen. Tradisjonelle lokale Microsoft-teknologier som SQL Server Integrations Services (SSIS) er et modent dataintegrasjonsverktøy som har vært utbredt i over et tiår. Etter hvert som flere skybaserte verktøy blir tilgjengelige er kunder interessert i å enten migrere ETL prosessene sine til skyen, eller bare rett og slett komme i gang med å forstå datavarehus i skyen. Vi skal her se på hvordan de kan komme i gang og hvilke verktøy de kan bruke.
De ferreste trenger Azure SQL Data Warehouse for å bygge sitt datavarehus i Azure
Ettersom flere selskaper uttrykker interesse for et moderne skybasert datavarehus, fortsetter Azure Data Factory å spille en betydelig rolle i ETL-prosessen. Microsoft fortsetter å møte og overgå dette behovet og interessen ved å utvide tjenestetilbudet deres innen Azure Data Factory ved å nylig legge til Mapping Data Flows, som gir mulighet for visuell og kodefritt å implementere logikk for datatransformasjon som utføres som aktiviteter med Azure Data Factory-pipeline ved bruk av en skalerbar klynge med Azure Databricks. I hovedsak bringer dette tilbudet Azure Data Factory ett steg nærmere Microsofts tradisjonelle SQL Server Integration Services, som har blitt brukt til datavarehus ETL programmering i mange år. Kartlegging av dataflyter har et enormt potensial i datalagerområdet for flere datalagringsmønstre, for eksempel sakte endring av dimensjoner Type I, type II og fakta-utvinning, transformasjon og datainnlasting.
Vi vil her se på det typiske datamagasinbelastningsmønsteret kjent som Slowly Changing Dimension Type I og hvordan Azure Data Factorys Mapping Data Flow kan brukes til å designe dette dataflytmønsteret ved å demonstrere et praktisk eksempel.
Vi vil her se på det typiske datamagasinbelastningsmønsteret kjent som Slowly Changing Dimension Type I og hvordan Azure Data Factorys Mapping Data Flow kan brukes til å designe dette dataflytmønsteret ved å demonstrere et praktisk eksempel.
HVA KOSTER DET EGENTLIG?
Så kommer 1000 kroners spørsmålet; "hva vil det egentlig koste?". Og da snakker vi ikke om utviklingskostnadene til datavarehus konsulentene eller lønnskostnadene til IT-avdelingen, men hvor stort beløp vil det stå på fakturaen fra Microsoft for alle Azure komponentene og bruk av lagring og beregninger i Azure. Her er det lett å gå på en smell! Faktum er at ingen kan fortelle deg hva det vil koste. Hvorfor ikke? Fordi prisingen i all hovedsak er basert på bruk. Hvor mye data du vil lagre og hvor mye CPU-tid ETL-prosesseringen krever. Her er det flere ukjente variabler enn det vi kan gå inn på her, men faktorer som mengden kildedata som hentes inn hver gang datavarehuset ska oppfriskes og frekvensen på disse oppdateringene spiller en vesentlig rolle. Kan det overhode være rimelig å forvente at noen kan svare på dette? Neppe! Og det er nettopp svaret som kundene ikke ønsker å høre fordi hvordan skal de kunne da vurdere kost/nytte? Det siste de trenger er en ventå-se strategi, selv om den nok desverre er den mest realistiske. Da hjelper det ikke at Microsoft proklamerer at de er mye billigere enn andre aktører. Dyrt blir det uansett!
Microsoft slår konkurrentene på pris - dyrt blir det uansett
Vi skal ikke prøve å forutse alle kostnadene men ønsker å hjelpe med å gi et gestimat på prisen for å kjøre et datavarehus i Azure.
La oss anta at Datavarehuset har F antall faktatabeller, D antall dimensjonstaballer og i snitt FD antall dimensjoner koblet til hver fakta. Videre anta at det lastes inn i snitt FN antall faktarader og DN nye dimensjonsrader i snitt hver gang Datavarehuset oppfriskes. Vi sier at hver rad i faktatabellen krever FB bytes og hver rad i dimensjonstabellen DB i snitt. La så O være antall ganger Datavarehuset oppfriskes hver dag. Vi skal nå forsøke å beregne lagringsforbruket og beregningeforbruket over tid. Dette kan virke som mange variabler men i praksis er denne modellen veldig forenklet. Vi ønsker oss en graf som viser fase kostnader, datakostnader og beregningskostnader over tid.
La oss anta at Datavarehuset har F antall faktatabeller, D antall dimensjonstaballer og i snitt FD antall dimensjoner koblet til hver fakta. Videre anta at det lastes inn i snitt FN antall faktarader og DN nye dimensjonsrader i snitt hver gang Datavarehuset oppfriskes. Vi sier at hver rad i faktatabellen krever FB bytes og hver rad i dimensjonstabellen DB i snitt. La så O være antall ganger Datavarehuset oppfriskes hver dag. Vi skal nå forsøke å beregne lagringsforbruket og beregningeforbruket over tid. Dette kan virke som mange variabler men i praksis er denne modellen veldig forenklet. Vi ønsker oss en graf som viser fase kostnader, datakostnader og beregningskostnader over tid.
AZURE SQL DATA WAREHOUSE
Det første som skaper forrvirring i datavarehus produktene til Microsoft er Azure SQL Data Warehouse. Tradisjonelt implementeres datavarehus i form av en ordinær relasjonsdatabase i SQL Server. I 2013 lanserte Microsoft det de den gang kalte SQL Server Parallel Data Warehouse som en løsning for å kunne bygge av datavarehus for store datamengder. Dette klarte de ved å spre databasen på flere servere både for lagring og prosessering. Slik kunne at man i prinsippet legge til nye servere for å øke kapasiteten ettersom datamengden økte. Det sier seg selv at dette er en svært kostbar løsning for kunder som i praksis betyr at den kun egner seg for store selskaper. Den gang var det tydelig ut fra navnet at dette ikke var en ordinær SQL Server i Azure men en teknologi for å implementere parallelle databaser som man faktisk må ta hensyn til under implementasjon av datavarehuset. I dag tilbyr Microsoft to database løsningen i skyen; Azure SQL Data Warehouse og Azure SQL Server.
I de fleste tilfellene vil en Azure SQL Server være tilstrekkelig for å implementere et datavarehus i Azure skyen. Men hva er egentlig forskjellen og når må man opp på den store og kostbare løsningen?
Azure SQL Data Warehouse - uslåelig ytelse til en fantastisk pris
Azure SQL Database - administrert intelligent SQL i skyen
|
|
|
AZURE DATA FACTORY
|
|
|
|
|
MAPPING DATA FLOWS
Building Data Flows in Azure Data Factory.
|
|
|
SCD TYPE 1 WITH MAPPING DATA FLOWS
AZURE DATA FACTORY AND CUSTOMER CHURN STORY
A very common customer use case for Azure Data Factory (ADF) is to design a customer churn analytics solution with Azure HDInsight, Azure SQL Data Warehouse and Azure Machine Learning using ADF as the cloud-based auto-scale data movement and data integration at the heart of that analytics solution. In this video, learn more about this use case from the customer perspective where Contoso is showcased as a fictitious mobile phone carrier.
Azure Data Factory on YouTube
Azure Data Factory on YouTube
|
|
|
|
|
|