Framtidens Business Intelligence – del 4 – Big Data

By | september 3, 2014

Detta är del 4 i min miniserie om Framtidens Business Intelligence. Övriga delar finns här.

Förväntningarna och hajpen är extremt hög kring Big Data. Hittills har det dock varit mer snack än verkstad. Samtidigt har tekniken mognat och priserna gått nedåt vilket har sänkt tröskeln rejält för vilka som kan ha nytta av Big Data. 2016 skall det slå igenom enligt vissa spåkulor.

Jag skulle vilja beskriva det så här:

  • Det är inte minsta tvekan om att datavolymerna ökar dramatiskt. Vi snackar om en fördubbling varje 18-24 månader.
  • Efterfrågan av nya datakällor som exempelvis sociala medier och maskiner ökar datavolymerna dramatiskt. Även mindre organisationer kommer bli alltmer intresserade av att analysera stora volymer data.
  • Vi har nått ett antal tekniska kapacitetstak som gör att man inte kan använda gårdagens tekniska lösningar för morgondagens stora datavolymer.

Därför är det för mig ingen tvekan om att Big Data teknologierna förr eller senare kommer att få stort genomslag.

Big Data och MPP

Vad är det då för tekniska kapacitetstak vi har mött?

  • Klockfrekvensen i CPU:er har knappt ökat på 8 år. Problemet är kylningen. Höjer man hastigheten så brinner CPU:erna helt enkelt upp.
  • Detta innebär att man ökar antalet kärnor per CPU och antalet CPU:er. Problemet är att de konkurrerar om delade resurser.
  • Man har börjat placera minneskretsar lokalt så nära CPU:erna som möjligt (i så kallad NUMA-arkitektur). Avståndet spelar stor roll – varje 10 centimeter innebär cirka 1 nanosekund extra i fördröjning (tur och retur för signalen mellan CPU och minne). Det är ljushastigheten som sätter denna begränsning. Skall en CPU kommunicera med en minneskrets som hör till en annan CPU så tar det ofta 10 gånger så lång tid.

Resultatet är att väldigt sällan så hjälper det att köpa ytterligare CPU:er när systemen går långsamt. Man ökar bara overheaden. Det är som i talespråket att ”ju fler kockar desto sämre soppa”.

Scalability Problem

För att närma sig den övre kurvan i figuren ovan måste man designa systemen på helt andra sätt än tidigare. MPP (”Massively Parallel Processing”) kallas detta, till skillnad mot SMP (”Symmetric Multiprocessing”) som traditionella system använder.

Metoden att parallellisera är välkänd: ”Divide and Conquer”. Dela upp stora uppgifter i mindre uppgifter som kan lösas oberoende av varandra. Sedan fördelas de mindre uppgifterna ut på olika beräkningsnoder och sammanställs till sist. Detta är den princip som alla Big Data-plattformar (MPP-plattformar) bygger på.

Skall man då alltid använda MPP-lösningar? Nej, definitivt inte. Det går en brytgräns mellan MPP och SMP. Om man är helt säker på att man ligger under den brytgränsen så är det onödigt med MPP. Om man har ”stora problem med en liten mängd data” så är det oftast bäst att ta hjälp av någon som är duktig på prestandaoptimering istället. Samtidigt är det lätt att underskatta sina framtida behov. Många system lever i 10-20 år, vissa ännu längre.

Här är några välkända Big Data plattformar.

Big Data platforms

En liten kommentar till bilden ovan bara: Microsofts plattform heter numera APS (Analytics Platform System). Det är samlingsnamnet för Microsoft PDW, HDInsight (Microsoft Hadoop-distribution) och Polybase (som kopplar ihop PDW med HDInsight).

Microsoft APS (Analytics Platform System)

Microsoft PDW

I en studie (beställd av Microsoft) jämför managementkonsultföretaget Value Prism pris och prestanda mellan plattformarna. Föga förvånande så ligger Microsoft absolut bäst till. Det är dock ingen tvekan om att det finns ett antal fördelar med Microsoft PDW

  • Bygger på SQL Server. Om man har redan befintliga lösningar i SQL Server så blir det enklare att migrera. Det är också lättare att få tag på konsulter med rätt kompetens än på smalare plattformar.
  • Produkten levereras av Microsoft tillsammans med HP och Dell. Detta är stora väletablerade leverantörer som kan förmodas finnas kvar under lång tid. Det minskar risken att man blir ståendes utan support och reservdelar.
  • Jag har inte hittat några helt oberoende jämförelser av prisnivåerna, men enligt undersökningen från Value Prism så ligger ju Microsoft bra till.

Varför har Microsoft då både PDW och HDInsight? Svaret är att det handlar om olika användningsområden. PDW är en relationsdatabas med alla för- och nackdelar det innebär. HDInsight/Hadoop är en mer generell plattform där man kan köra flera olika NoSQL-databaser. Klicka på bilden nedan för en förstoring.

Hadoop

Hadoop kärna

Hadoop (eller Apache Hadoop som är det riktiga namnet) är en Open Source platform för parallell processing. Hadoops kärna består av fyra komponenter.

  • Common – gemensam funktionalitet i hela kärnan.
  • HDFS – ett distribuerat filsystem.
  • YARN – ett ramverk för jobbschedulering.
  • MapReduce – ett system för parallell bearbetning av data som bygger på YARN.

Man kan bygga sina lösningar direkt mot Hadoops kärna, men det är det inte många som gör. Det är som om man skulle skriva alla sina Data Warehouse och BI-lösningar i JAVA. Istället använder man sig av ett antal applikationer.

Hadoop applikationer

Till Apache Hadoop finns också ett antal Open Source applikationer. Det finns i nuläget cirka 10 applikationer som utvecklas av samma Open Source-Community (Apache) som Hadoop. Några som kan vara användbara inom Business Intelligence är.

  • Pig har ett scriptspråk (”Pig Latin”) där man kan ställa frågor mot sina Hadoopfiler. Scripten kompileras till MapReduce-jobb. Fördelen med att använda Pig är att det är mycket mer ”högnivå” än att skriva direkt i MapReduce.
  • HBase är en NoSQL-databas som är designad för att hantera mycket stora tabeller (miljarder rader x miljontals kolumner). För den som är van vid SQL-databaser så känns HBase nog till en början väldigt rudimentär. Den har ett fåtal kommandon (get, scan, put, batch put, delete, incrementColumnValue och checkAndPut). Den är heller inte ACID compliant.
  • Hive är en SQL-liknande frågemotor. Man skriver frågor i HiveQL (som påminner mycket om SQL) och de kompileras till MapReduce-jobb. Man får sedan en tabell till svar precis som man skulle ha fått från en SQL-databas.
  • Mahout är ett bibliotek för Machine Learning. Funktionaliteten är liknande den i Microsofts Azure Machine Learning, men tröskeln att börja använda Mahout är mycket högre. Man måste vara en erfaren programutvecklare. Om man har tiden och tålamodet att sätta sig in i Mahout så kan det nog ändå ha många användningsområden.

Mer info

Vill du lära dig mer om Big Data så rekommenderar jag de här länkarna.