December 11, 2023
I mindre organisationer klarar man sig oftast långt med att klippa och klistra i Excel för att sammanställa sin uppföljning. En del har kommit i kontakt med verktyg så som Power BI (PBI), Qlik eller Tableau och laddat ner gratisversionen för att skapa flashiga grafer och sammanställningar. Uttag görs manuellt från källsystemet för att laddas direkt in i användarens gränssnitt. Andra har ERP-system eller e-handelsplattformar med inbyggd uppföljning och analys som ofta lämpar sig väldigt bra för just det enskilda systemets data. När organisationer växer och systemfloran ökar i både antal och komplexitet liksom mängden data så uppstår ofta ett behov av att centralisera och strukturera data i mer automatiserade flöden. Man stöter på verksamhetskrav på att skapa sig en gemensam syn på verksamheten och dess information och lösningen består ofta av att köpa in ett datalager, ett Data Warehouse (DW).
Detta har inte alltid varit en självklarhet och det råder fortfarande skilda meningar kring datalagrets roll. Uppstickare under början av 2000-talet som QlikTech (numera Qlik) hävdade länge att det inte behövdes något datalager utan att allt gick att hantera i deras programvara. Men även om det var fullt möjligt att använda sig av QlikView för detta ändamål så är frågan man måste ställa sig, till vilket pris. En salig blandning av olika applikationer med duplicerat data och i värsta fall flera sanningar skapade en rörig arkitektur. Många av de organisationer som valde denna väg har med tiden (och ökade datavolymer) fått börja se sig om efter alternativa sätt att lagra data.
Vid val av datalager så kan det upplevas som en djungel av olika produkter och tjänster och det kan ibland vara svårt och frustrerande att hitta rätt. Vad finns det, hur fungerar det och framförallt vad kostar det är frågor som ofta cirkulerar hos ledningen. Denna text syftar till att hjälpa dig att sondera den till synes ogenomträngliga terräng av datalager och hjälpa dig att bestämma vad som lämpar sig bäst för just er.
För att göra sitt val har vi identifierat nedan viktiga faktorer:
Du behöver veta på ett ungefär vilken mängd data som kommer att behöva hanteras. Om er totala datavolym kan uttryckas i hundratals terabytes eller i petabytes så rekommenderas det starkt att gå för icke-relationella databaser. Dessa är bättre lämpade för att hantera stora datamängder.
Idag har dock många relationsdatabaser riktigt bra beprövade sökoptimeringsverktyg och om man kan tänka sig molnlösningar så är det att betrakta som ett gott alternativ för ett analytics warehouse förutsatt att all data kan läggas på en nod.
Relevanta datalager baserat på datavolym:
En annan viktig aspekt är att utvärdera vilken kompetens som finns inom bolaget. Utan dedikerade resurser internt för underhåll, support och konfigurering av databasen så faller valet naturligt på ett av de molnbaserade datalagren som finns på marknaden. Administration av datalager så som att distribuera, hosta, hantera replikering eller kryptering finns då inbyggt i tjänsten som bara är att börja använda genom ett fåtal klick.
Att lägga administrationen av datalager på tjänsteleverantörerna har givetvis också sina brister. Verksamheter inom exempelvis finansiell och offentlig sektor med mycket extern rapportering och höga krav på kontrollerade uppdateringar och omstarter av hårdvara bör fundera en extra gång på detta alternativ. Diskussion med en tydlig kravspecifikation bör hållas med leverantör.
Moderna datalagerlösningar som Redshift, BigQuery eller Snowflake är att rekommendera. Alternativ till att välja en molnlösning är att själva sätta upp och installera ett datalager från grunden i relationsdatabaser som exempelvis SQL Server, PostgreSQL eller Oracle. Datalager för stora datamängder baseras ofta på något som Hadoop eller Greenplum. Dessa system kräver dock omfattande installations-, underhållstekniska resurser och kompetent personal.
När du börjar arbeta med en databas, förväntar du dig att den är skalbar nog för att stödja din fortsatta tillväxt. En databas skalbarhet uppnås på två sätt, horisontellt eller vertikalt. Horisontell skalbarhet avser tillägg av fler maskiner medan vertikal skalbarhet innebär att resurser läggs till i en enda nod för att öka dess kapacitet.
Redshift ger lätt skalbara alternativ. Med några få musklick kan du öka antalet noder och konfigurera dem för att möta dina behov. Redshift fungerar mycket bra tills du når omkring 100TB data som behandlas samtidigt i en fråga. Datakapaciteten hos ditt Redshift-kluster kommer alltid att förlita sig på antal noder i ditt kluster, till skillnad från vissa andra datalagringsalternativ.
Här skiljer sig BigQuery där man sällan pratar om någon klusterkapacitet och utifrån kundens perspektiv finns inga krav på fördefinierad storlek eller uppsättning av resurser. I BigQuery tilldelas upp till 2000 ”slots”, vilket är att jämställa med noder i Redshift. Hur många slots som används av varje ställd fråga avgörs automatiskt baserat på frågans storlek och komplexitet. På grund av Googles ”multi-tenancy” strategi kan BigQuery skala sömlöst när kundernas krav på samtida frågor växer och man har då till och med möjlighet att överstiga begränsningen på 2000 slots om så krävs.
BigQuery är beroende av Colossus, vilket är Googles senaste generations distribuerade filsystem. Colossus gör det möjligt för BigQuery-användare att skala till dussintals petabytes av lagrad data sömlöst, utan att betala extra för mycket dyrare datorresurser.
Snowflake är separerad i tre olika skikt (Storage, Compute och Services) för att kunna erbjuda både skalbarhet och prestanda. Alla datamängder, tabeller och sökresultat lagras i det så kallade lagringsskiktet (Storage) vilket är byggt på Amazon S3 Cloud Storage eller Azure. Lagringsskiktet är separerat och helt oberoende från skiktet för beräkningar vilket möjliggör maximal skalbarhet för datalagring. I beräkningsskiktet (Compute) erbjuder Snowflake flera virtuella datalager i nästan vilken skala som helst.
Gällande skalbarhet är det svårt att mäta sig med molnbaserade datalager.
Molnbaserade datalager som Redshift, BigQuery och Snowflake erbjuder alla en prissättning som baseras på hur mycket du använder tjänsten (on-demand), men varje tjänst kommer med sin egen unika prismodell.
Amazon Redshift erbjuder tre prissättningsmodeller:
Google BigQuery erbjuder skalbara, flexibla prisalternativ och avgifter för datalagring, streaminginsatser och för att fråga data, men laddning och export av data är gratis. Prissättningsstrategin för BigQuery är ganska unik eftersom den är baserad på en taxa per GB för lagring och en taxa per skannad bytes för frågor. Det erbjuder också kostnadskontrollmekanismer som gör att du kan täcka dina dagliga kostnader till ett belopp som du väljer. Det erbjuder också en långsiktig prissättningsmodell.
Snowflake erbjuder on-demand prissättning, vilket liknar BigQuery och Redshift Spectrum. Till skillnad från BigQuery faktureras beräkningsförbrukningen per sekund i stället för byte skannad, med ett minimum på 60 sekunder. Snowflake skiljer datalagring från beräkning och fakturering är därför separerad för dem båda.
Lagringstaxan börjar vid ca 40 dollar / TB / månad för standardutgåvan och är densamma för andra utgåvor. Taxan för beräkning är $ 2,00 per timme för Standard och upp till $ 4,00 per timme för Enterprise.
Utöver licenskostnader och den tid som krävs för att sätta upp miljö on-premises så kommer din prissättning att bestå av VM eller hårdvarukostnader. Licenskostnader inkluderar både operativsystem och programvara. Har du funderingar kring en Hadoop-lösning så erbjuder AWS en EMR-lösning som är ett kostnadseffektivt alternativ.
En viktig faktor att tänka på vid byggande av ett nytt datalager samt vidareutveckling av ett befintligt är att snabbt kunna hantera förändrade omständigheter som kommer från yttre eller inre påverkan. Många gånger kan det ofta ta lång tid att komma igång trots agila utvecklingsinsatser snarare än de gamla klassiska vattenfallsprojekten. Man fastnar i att hårdvaran saknas helt eller i att den saknar kapacitet för att ta hand om de ökade datamängderna. Vid val av mer moderna datalager som Redshift, BigQuery och Snowflake kan man mer sömlöst skala upp och ner utifrån de behov som råder just nu. Man undviker helt enkelt dessa begränsningar.
Olika produkter och tjänster erbjuder olika typer av gränssnitt för hantering och administration av datalager. Det skall vara intuitivt och enkelt att genomföra administrativa åtgärder och rekommendationen är att helt enkelt att känna och klämma på administratörsgränssnittet för att själva avgöra vad som känns bra.
Råd för val av datalager är följande: