Datalager, datasjö, eller kanske ett sjöhus? Om dessa termer inte omedelbart skapar associationer, är det troligt att ditt arbete inte direkt berör datahantering.
Men en sådan utgångspunkt känns nästan overklig, då det verkar som att allt idag på ett eller annat sätt är kopplat till data. Eller som företagsledare gärna uttrycker det:
- Verksamhet som är datacentrerad och datadriven.
- Data tillgänglig var som helst, när som helst, hur som helst.
Den främsta tillgången
Data har blivit en allt viktigare tillgång för alltfler företag. Jag minns tiden då stora bolag genererade enorma datamängder, kanske terabyte av ny data varje månad. Det var för 10-15 år sedan. Idag kan man enkelt producera den mängden data på bara några dagar. Man kan fråga sig om allt detta verkligen är nödvändigt, och om det verkligen finns någon användning för all information. Och svaret är, definitivt inte 😃.
All data kommer inte att vara av värde, vissa delar kanske inte ens används en enda gång. Jag har själv sett hur företag genererat gigantiska mängder data, som sedan visade sig vara totalt värdelös direkt efter den initiala inläsningen.
Men situationen ser annorlunda ut idag. Datalagring – nu i molnet – är kostnadseffektivt, datakällor växer lavinartat och ingen kan med säkerhet säga vilka data som kommer att vara värdefulla ett år fram i tiden, när nya tjänster integreras i systemen. Då kan även den äldre informationen få ett stort värde.
Strategin handlar därför om att lagra så mycket data som möjligt, men också i ett så effektivt format som möjligt. På så sätt kan data inte bara lagras på ett effektivt sätt, utan även sökas, återanvändas, transformeras och distribueras vidare.
Låt oss undersöka tre metoder för att uppnå detta i AWS:
- Athena Database – en kostnadseffektiv och enkel metod för att bygga en datasjö i molnet.
- Redshift Database – en robust molnversion av ett datalager som har potential att ersätta många av de befintliga lokala lösningarna, även om det är svårt att matcha den exponentiella tillväxten av data.
- Databricks – en kombination av datasjö och datalager i en enda lösning, med ytterligare fördelar.
Datasjö med AWS Athena
Källa: aws.amazon.com
En datasjö är en plats där man snabbt kan lagra inkommande data i ostrukturerat, semistrukturerat eller strukturerat format. Man förväntar sig inte heller att den lagrade datan ska förändras, utan snarare att den ska förbli atomär och oföränderlig. Detta är viktigt för att maximera potentialen för återanvändning i senare skeden. Om denna atomegenskap går förlorad direkt efter inläsning, kan man inte få tillbaka den.
AWS Athena är en databas som lagrar data direkt på S3-buckets, utan serverkluster i bakgrunden. Det gör den till en mycket kostnadseffektiv datasjötjänst. Strukturerade filformat, som Parquet eller CSV-filer (komma-separerade värden), upprätthåller dataorganisationen. S3-hinken innehåller filerna, och Athena refererar till dessa när data hämtas från databasen.
Athena stöder inte alla standardfunktioner, som till exempel uppdateringskommandon. Därför bör Athena betraktas som ett mycket enkelt alternativ. Å andra sidan, så hindrar det dig från att modifiera din atomära datasjö, helt enkelt för att du inte kan 😐.
Tjänsten stöder indexering och partitionering, vilket gör det möjligt att köra urvalskommandon effektivt och dela upp datan logiskt (till exempel efter datum eller nyckelkolumner). Den kan även skalas horisontellt på ett enkelt sätt, vilket är lika enkelt som att lägga till nya buckets till infrastrukturen.
För- och nackdelar
Fördelar:
- Den största fördelen med Athena är den låga kostnaden (eftersom det bara består av S3-hinkar och SQL-användningskostnader). Om du vill bygga en prisvärd datasjö i AWS är detta ett utmärkt alternativ.
- Som en inbyggd tjänst integreras Athena enkelt med andra AWS-tjänster, som Amazon QuickSight för datavisualisering eller AWS Glue Data Catalog för att skapa beständig strukturerad metadata.
- Bäst lämpad för att köra ad hoc-frågor mot stora mängder strukturerad eller ostrukturerad data, utan att behöva underhålla en komplett infrastruktur runt omkring.
Nackdelar:
- Athena är inte särskilt effektivt när det gäller att snabbt returnera komplexa urvalsfrågor, speciellt om frågorna inte följer antagandena i datamodellen för hur man designat förfrågningarna.
- Detta gör den också mindre flexibel inför eventuella framtida förändringar i datamodellen.
- Athena stöder inga ytterligare avancerade funktioner direkt, och om du behöver något specifikt måste du implementera det ovanpå.
- Om datan från datasjön ska användas i ett mer avancerat presentationslager, är det ofta nödvändigt att kombinera den med en annan databastjänst som är bättre lämpad för det ändamålet, som AWS Aurora eller AWS DynamoDB.
Syfte och praktiska tillämpningar
Välj Athena om målet är att skapa en enkel datasjö utan avancerade funktioner som finns i datalager. Till exempel, om du inte förväntar dig att köra högpresterande analysfrågor regelbundet. Istället är prioriteten att ha en pool av oföränderlig data med enkel utökning av datalagringen.
Du behöver inte längre bekymra dig så mycket om utrymmesbrist. Kostnaden för S3-lagring kan minskas ytterligare genom att implementera en datalivscykelpolicy. Det innebär att data flyttas över till olika typer av S3-hinkar, med långsammare svarstider men lägre kostnader, mer lämpade för arkivering.
En annan stor fördel med Athena är att den automatiskt skapar en fil med resultatet från din SQL-fråga. Denna fil kan sedan användas för olika ändamål. Det är ett bra alternativ om du har många lambdatjänster som bearbetar data i flera steg. Resultatet från varje lambda-instans blir automatiskt en strukturerad fil som är redo för vidare bearbetning.
Athena är ett bra alternativ i situationer där stora mängder rådata kommer till din molninfrastruktur och du inte behöver bearbeta den direkt vid inläsning. Det räcker med snabb lagring i molnet med en lättförståelig struktur.
Ett annat användningsområde är att skapa ett dedikerat utrymme för dataarkivering, för en annan tjänst. Athena DB blir en kostnadseffektiv backup-plats för data som inte behövs omedelbart, men kan bli aktuell i framtiden. I sådana fall matar man bara in data och skickar den vidare.
Datalager med AWS Redshift
Källa: aws.amazon.com
Ett datalager är en plats där data lagras på ett strukturerat sätt, enkelt att läsa in och ut. Syftet är att köra ett stort antal komplexa frågor, koppla samman många tabeller via avancerade kopplingar. Olika analysfunktioner används för att beräkna statistik baserat på befintlig data. Det slutliga målet är att med hjälp av befintlig data utvinna prognoser och fakta som kan användas i verksamheten.
Redshift är ett komplett datalagersystem med klusterservrar för att ställa in och skala – både horisontellt och vertikalt – samt ett datalagringssystem optimerat för snabba och komplicerade frågor. Numera kan du även köra Redshift i serverlöst läge. Det finns inga filer på S3 eller liknande, det är en vanlig databasklusterserver med ett eget lagringsformat.
Det innehåller även verktyg för prestandaövervakning, anpassningsbara instrumentpaneler som kan användas för att finjustera prestandan. Administration är också tillgängligt via separata instrumentpaneler. Det kräver lite ansträngning att förstå alla funktioner och inställningar, och hur de påverkar klustret. Men det är inte alls lika komplicerat som administrationen av Oracle-servrar brukade vara för lokala lösningar.
Även om det finns AWS-begränsningar i Redshift som sätter vissa gränser för hur det kan användas dagligen (till exempel antalet samtidiga användare eller sessioner), så hjälper det faktum att operationerna går väldigt snabbt till att kringgå dessa gränser till viss del.
För- och nackdelar
Fördelar:
- En inbyggd AWS-molndatalagertjänst som är lätt att integrera med andra tjänster.
- En central plats för lagring, övervakning och intag av olika typer av datakällor från varierande källsystem.
- Om du har velat ha ett serverlöst datalager utan infrastruktur att underhålla, så är det möjligt nu.
- Optimerad för högpresterande analyser och rapportering. Till skillnad från en datasjölösning finns en stark relationsdatamodell för att lagra all inkommande data.
- Redshifts databasmotor härstammar från PostgreSQL, vilket säkerställer hög kompatibilitet med andra databassystem.
- Mycket användbara COPY- och UNLOAD-kommandon för att läsa in och ut data från och till S3-hinkar.
Nackdelar:
- Redshift stöder inte ett stort antal samtidiga aktiva sessioner. Sessionerna kommer att ställas i kö och bearbetas sekventiellt. Även om det inte är ett problem i de flesta fall, eftersom operationerna går snabbt, är det en begränsande faktor i system med många aktiva användare.
- Även om Redshift stöder många funktioner som är kända från mogna Oracle-system, så är det inte på samma nivå. Vissa funktioner kanske inte finns (som DB-triggers). Eller så stöds de i en begränsad form (som materialiserade vyer).
- När du behöver ett mer avancerat och anpassat databearbetningsjobb måste det skapas från grunden. Oftast används Python eller Javascript. Det är inte lika smidigt som PL/SQL i Oracle-system, där även funktioner och procedurer använder ett språk som liknar SQL-frågor.
Syfte och praktiska tillämpningar
Redshift kan vara ditt centrala lager för olika datakällor som tidigare fanns utanför molnet. Det är ett fullgott alternativ till tidigare Oracle-datalagerlösningar. Eftersom det även är en relationsdatabas är migreringen från Oracle till och med en ganska enkel operation.
Om du har befintliga datalagerlösningar på olika platser, som inte är enhetliga i tillvägagångssätt, struktur eller en fördefinierad uppsättning av gemensamma processer, är Redshift ett utmärkt val.
Det ger dig möjlighet att sammanföra olika datalagersystem från olika platser under ett och samma tak. Du kan fortfarande separera dem per land, så att datan förblir säker och tillgänglig endast för de som behöver den. Samtidigt möjliggör det en enhetlig lagerlösning som täcker alla företagsdata.
Ett annat användningsområde är att bygga en datalagerplattform med omfattande stöd för självbetjäning. Det innebär att enskilda användare kan skapa sina egna bearbetningar, som inte är en del av den gemensamma plattformslösningen. Dessa tjänster förblir tillgängliga endast för skaparen eller den definierade gruppen, och påverkar inte övriga användare.
Se vår jämförelse mellan Datalake och Datawarehouse.
Lakehouse med Databricks på AWS
Källa: databricks.com
Lakehouse är en term som är starkt knuten till Databricks. Det är inte en inbyggd AWS-tjänst, men fungerar väl i AWS-ekosystemet och ger olika möjligheter för integration med andra AWS-tjänster.
Databricks syftar till att koppla samman (tidigare) separata områden:
- En lösning för datasjölagring av ostrukturerad, semistrukturerad och strukturerad data.
- En lösning för datalagerstruktur och snabbt åtkomlig data (även kallad Delta Lake).
- En lösning som stöder analys och maskininlärning över datasjön.
- Datastyrning för alla områden ovan med centraliserad administration och verktyg för att stödja produktiviteten för olika typer av utvecklare och användare.
Det är en gemensam plattform som kan användas av dataingenjörer, SQL-utvecklare och dataforskare för maskininlärning. Varje grupp har tillgång till en uppsättning verktyg för att utföra sina uppgifter.
Databricks är en ”allt-i-ett”-lösning som försöker kombinera fördelarna med datasjö och datalager. Utöver det finns verktyg för att testa och köra maskininlärningsmodeller direkt på de befintliga datalagren.
För- och nackdelar
Fördelar:
- Databricks är en mycket skalbar dataplattform, som skalas efter arbetsbelastningen, även automatiskt.
- Det är en samarbetsmiljö för dataforskare, dataingenjörer och affärsanalytiker. Möjligheten att arbeta tillsammans i samma miljö är en stor fördel, inte bara organisatoriskt utan även kostnadsmässigt, eftersom det annars skulle krävas separata miljöer.
- AWS Databricks integreras sömlöst med andra AWS-tjänster, som Amazon S3, Amazon Redshift och Amazon EMR. Det gör att användare enkelt kan överföra data mellan tjänster och utnyttja hela utbudet av AWS-molntjänster.
Nackdelar:
- Databricks kan vara komplicerat att konfigurera och hantera, speciellt för användare som är nya inom big data-bearbetning. Det kräver en god teknisk expertis för att få ut det mesta av plattformen.
- Även om Databricks är kostnadseffektivt i sin prissättning, kan det ändå vara dyrt för storskaliga projekt. Kostnaden kan snabbt öka om användarna behöver skala upp sina resurser.
- Databricks erbjuder en rad förbyggda verktyg och mallar, vilket kan vara en begränsning för användare som behöver fler anpassningsalternativ. Plattformen kanske inte passar användare som kräver större flexibilitet och kontroll över sina arbetsflöden.
Syfte och praktiska tillämpningar
AWS Databricks passar bäst för stora företag med enorma datamängder. Här kan det tillgodose behovet av att läsa in och kontextualisera olika datakällor från olika externa system.
Ofta är kravet att tillhandahålla data i realtid. Det innebär att så fort data dyker upp i källsystemet, ska processerna hämta, bearbeta och lagra datan i Databricks omedelbart, eller med minimal fördröjning. Om fördröjningen är mer än en minut betraktas det som nära realtidsbearbetning. I de flesta fall är båda scenarierna möjliga med Databricks, tack vare ett stort utbud av adaptrar och realtidsgränssnitt som ansluter till olika inbyggda AWS-tjänster.
Databricks kan även enkelt integreras med Informatica ETL-system. Om organisationen redan använder Informaticas ekosystem i stor utsträckning, är Databricks ett bra kompatibelt komplement.
Avslutande ord
Eftersom datavolymerna fortsätter att växa exponentiellt, är det bra att veta att det finns lösningar som kan hantera det effektivt. Det som tidigare var en mardröm att administrera och underhålla kräver nu mycket lite administrationsarbete. Teamet kan istället fokusera på att skapa värde utifrån datan.
Välj den tjänst som bäst passar dina behov. Medan AWS Databricks är något du troligen kommer att vara mer låst till efter beslutet, är de andra alternativen mer flexibla, även om de är mindre kapabla, särskilt i sina serverlösa lägen. Det är relativt enkelt att migrera till en annan lösning i efterhand.