Visar inlägg med etikett Databaser. Visa alla inlägg
Visar inlägg med etikett Databaser. Visa alla inlägg

2012-10-23

Data kommer inte från en svart låda

Inte allt för länge sedan satt jag med i ett möte där man diskuterade olika lösningar för både DW och BI. Det var en del av ett stort DW/BI projekt som skulle innebära stora förändringar för hela organisationen. Projektet hade fortlöpt under ganska lång period innan detta möte och det var många personer inblandade. De allra flesta hade deltagit i ett antal workshops både internt och externt med leverantörer och konsulter för att arbeta fram lösningen. Mitt i detta möte ställer helt plötsligt ekonomichefen frågan: "Alltså en databas, vad är det för någonting egentligen? Är det ett program? En burk? Eller vad?". Svaret på frågan som han fick från leverantören var någonting i stil med "Man lagrar data i en databas och det kan både vara mjukvara och hårdvara". Då kände man verkligen klyftan mellan leverantören, IT-avdelningen och verksamheten. Jag förväntar mig verkligen inte att en ekonomichef skall förstå sig på underliggande teknologier i databaser, men tycker att det är ett misslyckande om hela företagets DW/BI lösning uppfattas som ett stort svart magisk hål som spottar ur sig rapporter och KPIer. Om varken IT eller leverantörer kan göra ett bättre jobb i att förmedla vad det är som leverar allt data ut till slutanvändaren, vem ska då kunna göra det?

Vi föreställer oss att jag har en receptsamling på 1000 recept i en låda. Vem som helst kan komma och fråga mig om recept och mitt jobb är att kunna ta fram rätt recept. De första frågorna som ställs är i stil med "Kan du ge mig receptet på kladdkaka?". Ganska snabbt inser jag att det vore nog klokt att sortera recepten i bokstavsordning, på så sätt kan jag mycket fortare hitta rätt recept.

Sen börjar frågorna förändras "Kan du ge mig alla recept som innehåller nötter?". Hur ska jag lösa dessa frågor på ett effektivt sätt? Alla recept innehåller flera ingredienser så det går inte att sortera på något vettigt sätt. Tre alternativ skulle kunna vara:
  1. Jag skaffar fler lådor, en låda per ingrediens. Sedan tar jag kopior av recepten och lägger en kopia i varje låda för varje ingrediens varje recept innehåller.
  2. Jag köper ett gäng Post-it index och färgkodar alla recept med olika färger beroende på vilka ingredienser de innehåller.
  3. Jag tar hjälp av fler personer.
Alternativ ett blir en grymt effektiv lösning. Ifall någon vill ha recept med nötter så tar jag bara alla recept i nötlådan. De går nästan inte att komma på en lösning som skulle gå snabbare. Nackdelarna är dock många och växer på sikt. Ju fler recept jag samlar på mig, dessto fler ingredienser kommer det att finnas och dessto fler lådor måste jag förvara någonstans. Potentiellt köpa nya hyllor. För varje nytt recept måste jag lägga tid på att kopiera receptet och sortera in det i rätt lådor. Ifall jag har skrivit fel någonstans, måste jag leta upp alla kopior och ändra på samtliga. Ifall jag missar att ändra på en av kopiorna kommer jag att ha olika recept för samma sak. Sen kommer det stora problemet. Frågor angående olika kombinationer börja ställas, "Kan du ge mig alla recept som innehåller nötter och grädde?". Shit, ska jag ha lådor och kopior för alla olika kombinationer av ingredienser!!! Den tekniska motsvarigheten till detta är att skapa silos (kuber, in-memory, materialiserade vyer, etc.) för att få prestanda.

Alternativ två är inte lika effektivt. För att hitta alla nötrecept måste jag plocka fram t.ex. alla blåa recept, men det går betydligt fortare än att läsa igenom alla recept och leta efter nötter. Fördelen är dock att jag har fortfarande bara en kopia av receptet. Det går lite fortare att klistra på mina Post-it index lappar än att göra kopior och sortera dem. Jag kan på ett lättare sätt hantera kombinationer då recept med nötter och grädde skulle innebära t.ex. blåa och röda recpet. Det blir dock lite jobbigare ifall jag bestämmer mig för att grädde inte längre ska vara röd utan gul. Då måste jag gå igenom alla röda och byta till gult index. Det börjar bli ännu jobbigare att få plats med alla möjliga färgkodningar för alla möjliga kombinationer rent fysiskt på receptet. Den tekniska motsvarigheten till detta alternativ är att försöka ha en generell modell i sitt DW och arbeta med inbyggd funktionalitet (index, hashmaps, projektioner, etc.) för att snabba upp sökningarna och hitta rätt.

Alternativ tre kan bli riktigt effektivt. Dessto fler personer som hjälper till dessto fortare går det att hitta rätt recept. Det är lätt att hantera ökade antal recept då det bara är att ta hjälp av fler. Spontant känns det som en väldigt dyr lösning att betala löner till alla som hjälper till, men när det kommer till de tekniska lösningarna finns det både dyra och billiga alternativ. Den tekniska motsvarigheten är att parallellisera och/eller distribuera beräkningarna (MPP, Hadoop, etc.) för att snabba upp sökningarna.

Exemplet är så klart väldigt förenklat, men ett sätt att illustrera att en databas är ingen svart låda. Man kan lagra allt data i en viss ordning på hårddisken och ha olika sätt för att sedan hitta delmängder baserat på vissa villkor men mycket mer än så kan man inte göra. Rent krasst kan man säga att blir lösningen snabb på en sak, blir den långsam på en annan. Poängen med detta exempel är att jag anser att det är viktigt att alla inblandade i ett DW/BI projekt bör ha en insikt på denna nivån. Alla måste förstå att oavsett vad någon säger eller lovar så finns det ingen silver bullet. Alla lösningar har begränsningar och det gäller att välja en lösning vars begränsningar får så liten inverkan som möjligt.

2011-11-10

Hadoop World 2011

I veckan har den tredje upplagan av Hadoop World ägt rum i New York. I år var det helt slutsålt och många nekades tillträde. Det var många intressanta speakers och två som jag hade velat närvara på var David Champagne från Revolution Analytics som pratade om integrationen av R och Hadoop samt Abhishek Gupta på LinkedIn som pratade om hur de använder Hadoop för att transformera rådata till features som de använder i deras rekommendationssystem.

2011-10-21

R och Hadoop


Revolution Analytics har utvecklat tre paket som integrerar R med Hadoop.
  • rmr - integrerar Hadoop MapReduce funktionalitet in i R
  • rhdfs - integrerar filhantering i HDFS in i R
  • rhbase - integrerar den distribuerade databasen HBase in i R
Bilden är tagen från en presentation över RHadoop som man hittar här.

2011-10-06

MicroStrategy och MySQL Community Server

För prototypning och POCs tycker jag att MySQL CE är väldigt smidig att arbeta med. Den är gratis, den funkar på Linux och Windows och det är enkelt att scripta upp allting. När man kör MicroStrategy Connectivity Wizard så finns det dock bara ett alternativ för att köra MySQL och det är "MicroStrategy ODBC Driver for MySQL Wire Protocol" vilket inte fungerar med community versionen. Men om man kollar i "Certified and Supported Configurations" ser man att MySQL community server stöds både för meta data och data warehousing. För att använda MySQL community server som datakälla i MicroStrategy måste man installera MySQLs ODBC Driver version 5.1.8 och sedan lägga till en ny DSN via MicroStrategy Connectivity Wizard och då välja "Other Relational Databases" eller lägga in en ODBC data källa direkt i Windows Kontrollpanel.

2011-10-04

Oracle Exalytics

I går på OpenWorld presenterade Larry Ellison Oracles nya produkt Exalytics. Produkten är ett paket som täcker hela BI stacken från hårdvara till slutanvändargränssnitt, men det som är intressant är att den bygger på en kombination av Oracles TimesTen minnesdatabas och Oracles Essbase analysdatabas för att kunna erbjuda en minneslösning för både radbaserat och kolumnbaserat relationsdata samt kuber. Ledordet för utvecklingen ska ha varit parallellisera allt och produkten ska ha en genomgående parallell struktur. För den som vill läsa Oracles white paper som ger en teknisk introduktion till Exalytics hittar det här eller så kan man kika på lite highlights från Larry nedan.

2011-09-04

NoSQL

Jag tycker det är väldigt intressant att följa debatten kring hela NoSQL hypen. Senast den här veckan hade Computer Sweden en stor artikel. Några av mina tankar...

En viktig aspekt med NoSQL databaserna är att de är gjorda för sitt specifika ändamål, man behöver ingen datamodell och man vet i förväg hur data kommer accessas. Jämför detta med en SQL databas där man i förväg inte har en aning om hur datat modelleras eller kommer att accessas. Man gör antaganden om hur datat kommer att efterfrågas och skapar t.ex. index. Man kan givetvis använda en SQL databas som key-value store, eller för att lagra dokument, men det är självklart att NoSQL databaser optimerade för sin uppgift gör jobbet bättre än en generell SQL databas skulle göra på en likvärdig modell.

Avsaknaden av en datamodell kan dock vara ett problem. Har man många applikationer med olika objektmodeller som mappar mot datalagret är det lätt att man får motsägelser i datat. Det finns inte heller något standardiserat gränssnitt för NoSQL databaser. Om man flera applikationer i olika programmeringsspråk kan detta kräva att man bygger ett eget accesslager ovanpå datalagret för att få ett gemensamt gränssnitt mot alla applikationer. Arbetet har dock påbörjats med UnSQL men det återstår att se hur det fortlöper.

Som vanligt så finns det tyvärr ingen silver bullet som löser alla problem. Alla databaser har sin styrka, må det vara en rad/kolumnbaserad relationsdatabas, grafdatabas, dokumentdatabas eller key-value store. Det viktiga är att förstå de olika alternativen för att kunna välja den bästa lösningen. Hur många svenska företag sitter på hybridlösningar i sitt warehouse idag?