CDC - integrationshub och datalager

CDC eller Change Data Capture är en lyckad implementation i en integrationsarkitektur, framförallt i ett datalager med krav på uppdateringar nära realtid. Om många av källsystemen är databas Oracle så är det lätt att sätta upp en CDC på källsystemen från en integrationshub eller stagingdatabas. Oracle har fyra implementationer av CDC varav en heter Asynchronous Distributed Hotlog CDC. Källsystemets version måste vara Oracle 9 rel.2 eller högre och integrations- eller stagingdatabasen Oracle 10 rel.2 eller högre. Vid denna implementation kan den ansvariga för integrationshubben alternativt stagingdatabasen "lyssna" på förändringar i valda tabeller i källsystemet. Förändringarna propageras via streams AQ till förändringstabeller i hubben alternativt stagingdatabasen. Allt detta sätts upp automatiskt via DBMS_CDC-paket i Oracledatabasen. Förändringarna kan sedan bearbetas med exempelvis OWB var 5:e minut för inläsning i datalagret alternativt skapa xml-meddelanden som skickas ut på en integrationsbuss (ESB). Den stora fördelen med CDC är att utan applikationskod fånga förändringar i källsystemens tabeller och sedan bearbeta dessa.

Internetportal lanseras i början på september

Nu är sommarledigheten slut för den här gången och det är full fart igen. Sommarledigheten har inneburit en hel del arbete. Internetportalen för digital marknadsföring lanseras i början på september med direktreklam till nystartade företag i postnummerområde 74xxx-76xxx. Syftet med portalen är att i första hand ge nystartade företag möjlighet att marknadsföra sig gratis och på sikt även kunna få samma möjligheter som de stora företagen vad gäller kommunikation till sina kunder med kundklubbar osv.

SOA och Masterdata

Integration är just nu ett hett ämne och företag för flitiga diskussioner om målbilder för en principarkitektur. Målet är att all kommunikation ska ske via en ESB där alla förändringar i källsystemens data skickas i form av XML-meddelanden. Alla andra system som har ett intresse av förändringen prenumererar på meddelandet och tar del av förändringen. Tyvärr fokuserar företagen för mycket på tekniken med förkortningar som AQ, ESB, BPEL, BAM, SOAP, WS, XML, WSDL, XSD, JMS mm. Företagen borde i ett första skede fokusera mer på företagets data och organisation, allt handlar om data och hur data ska hanteras i företaget. Vi måste komma ihåg att tekniken bara är ett sätt att göra data tillgängligt. Det första steget enligt mig är att bestämma sig för vem som äger data och upprätta en organisation för Data Stewards som kontrollerar och övervakar attributen (definitioner, affärsregler, namn osv).

Införandet av en integrationshub (Enterprise MDM) med centraliserad data är ett första steg mot en lyckad integrationsarkitektur. I detta första steg finns mycket erfarenhet hos personer som har jobbat med datalager eftersom de stött på problemet med olika definitioner på samma begrepp i de källsystemen som integreras med datalagret.

Läs mer om masterdatahantering:
http://www.intelligententerprise.com/showArticle.jhtml?articleID=197004155&pgno=1

I nästa inlägg presenterar jag mina åsikter om datalagrets ETL-process och SOA.

Mer om QlikView

Den som jobbar med QlikView som presentationsverktyg i sin BI-lösning måste vara mycket medveten om dess för- och nackdelar. Idag upptäckte jag ytterligare två saker som befäster min ståndpunkt att man måste ha ett traditionellt datalager i en databas innan man läser upp data till QlikView-applikationen. Datalagrets stjärnmodeller ska speglas till QlikView-appen och ingen tvättning av data ska ske i QlikViews laddscript.

1. I verktyg som Oracle Discoverer får man fel "Cannot divide by zero" om man utför en beräkning med noll i nämnaren, men inte i QlikView. QlikView skickar tillbaka resultatet noll istället vilket kan leda till felaktiga resultat i analysen.
2. I Discoverer får man en varning eller ett fel om man försöker beräkna exempelvis omsättning där dimensionerna ger en kartesisk join eller fan-trap query.

Slutsats: Utför inte alltför komplicerade beräkningar i applikationen. Lägg dessa i scriptet eller i databasen istället för att få kontroll över beräkningen och genomför omfattande avstämningar och tester. Var försiktig med att bygga ihop olika stjärnmodeller eftersom de kan ge felaktiga resultat där exempelvis omsättningen kan bli alldeles för hög (dubbelräknas)!

Avtal klart

Nu har vi tecknat ett avtal med First Business som kommer att distribuera direktreklam angående vår portal till nystartade företag i Uppsala med omnejd. Vi jobbar nu med att ta fram reklambladets innehåll (layout, texter m m). Det blir mycket spännande att se hur detta erbjudande kommer att tas emot av företagen. Nystartade företags behov av att marknadsföra sig är oerhört stort i början eftersom ingen eller få känner till företaget. Vi kommer att marknadsföra vår portal mot företagens potentiella konsumenter i takt med att företag ansluter sig till oss.

Lansering av portal för internetmarknadsföring!

Vi har under en längre tid sökt kontakt med ett företag som kan hjälpa oss att marknadsföra vår portal för digital marknadsföring. Nu har vi fört en del diskussioner med ett företag som distribuerar startpaket till nystartade företag. Skulle ett samarbete inledas så kommer vi att via företaget distribuera reklam till i första hand nystartade företag som får möjlighet att marknadsföra sina produkter i vår portal.



Exempel på utseende i portalen:







Mer info kommer inom kort!!!!!!

Möte med QlikTech!

Idag hade vi ett givande möte med QlikTech där vi fick lite tips på olika saker vi kan göra i verktyget. Vi kunde också delge våra erfarenheter om buggar och förbättringar som vi önskade. Utbyte av erfarenheter av det här slaget är ofta mycket givande. Min bild av hur QlikView ska positioneras i en BI-plattform är numera ganska klar.

• Styrkan med QlikView i förhållande till traditionella BI-verktyg är ad hoc analys av stora datamängder. Istället för att underhålla en stor mängd aggregerade kuber eller materialiserade vyer för att förbättra prestanda i svarstider så läser man in all data i QlikView på detaljnivå där trendanalyser över flera år med många dimensioner kan göras med mycket bra prestanda. Begränsningen med OLAP-kuber av antalet dimensioner och aggregeringsnivå försvinner. En annan styrka är användargränssnittet som är mycket enkelt, snyggt och flexibelt. Här har man verkligen lyckats med WYSIWYG.

• Svagheten med QlikView i förhållande till traditionella BI-verktyg är hantering av metadata som idag sker direkt i scriptet. Döper man om ett fält så måste man ladda om allt. Ej lika enkelt för slutanvändaren att göra beräkningar som i OLAP där användaren snabbt och enkelt kan visa all data som uppfyller ett villkor och i samma rapport också visa ytterligare ett villkor som kan vara en delmängd av det första urvalet. Mängdlära med union, intersect och minus, se bild:

Slutanvändaren skriver formler själv precis som i excel vilket kan ge olika resultat hos olika användare vilket kan leda till felaktiga slutsatser=förödande. Detta måste hanteras i organisationen som måste ge ett fåtal användare superuser-rättigheter. Fasta rapporter är inte heller styrkan. Vill slutanvändaren se hur resultatet var en given dag eller vecka utan postöverskridande beräkningar passar det bättre med ett rapportverktyg som Oracle Reports där ett urval på dag kan göras innan rapporten genereras. I QlikView måste applikationen (dokumentet) först läsas in med alla data (inget urval gjort) i internminnet och sedan kan urvalet göras. Här har man inte lyckats så bra med layouten!

Slutsatsen är att använda QlikView för avancerad ad-hoc analys på stora datamängder och trendanalyser. Slopa aggregeringar i databasen för att förbättra prestanda för slutanvändarens ad hoc analyser. Läs in allt i QlikView!

Preparera data genom att bygga upp ett datalager i databasen. Hantera allt som har med nyckeluppslag, bearbetning, Slowly Changing Dimensions etc att göra i datalagret. Uppläsning till QlikView ska vara enkla script. Se QlikView som presentationsverktyg och inte ett ETL-verktyg. Bygg fasta rapporter med andra verktyg än QlikView!

Arbete, arbete, arbete...

Idag var det release av nya ETL-processer i datalagret! Nu är det bara att hålla tummarna för att nattens laddningar ska fungera utan problem. Totalt så blev det 11 timmars arbete idag innan dagen var slut. Medan jag körde tunga insert...select av historisk data för att fylla på de nya faktatabellerna så skrev jag en användarhandledning på ett nytt formulär som jag ska visa för analysfunktionen i veckan.

Test inför produktionssättning

Sista dagen innan jag får ta en dag ledigt (sportlov). Förberedelse inför release med allt vad det innebär. Dokument till produktion om vad som ska göras i datalagret och när. För ovanlighetens skull är vi ute i god tid och alla tester, validering av data mm, visar rätt. Imorgon blir det skridskoåkning för hela slanten.

Kvällsmöte!

Ikväll bestämde jag och Janne hur visitkorten skulle se ut och la en beställning till kph i Uppsala. Vi tittade också på hemsidan som delvis är klar. Det saknas uppgifter på flikarna Produkter och Tjänster. Vi väckte en idé om att skriva ett dokument om hur vi jobbar med Business Intelligence och Data Warehouse. Exempel på fråga är hur vår strategi ser ut när det gäller en optimal datadesign för åtkomst av nyckeltal i verktygen.

Denna vecka är det sportlov men det märker vi inte av...djupt försunkna i våra arbetsuppgifter. Innan vi avslutade mötet kom Maria in med punchglass.

Select kontra Insert/Update/Delete! Luleå krossar Brynäs?

Idag har jag suttit och testat ett formulär som ska ge användarna möjlighet att koppla attribut till olika dimensioner i datalagret. Än en gång så inser jag att det krävs enormt mycket mer testtid för att testa IUD-kommandon kontra att "bara" skriva SELECT och skapa rapporter. Målet för dagen var att hinna klart med testerna och nu ser det ut att vara i hamn...puuuuh. Dax att åka hem och se när Luleå krossar Brynäs, eller hur Janne?

LevelKey Roadmap

Nu har jag och Janne haft vår första konferens, en dag i ett av Scandic Uplandias mötesrum. Rubriken på dagen LevelKey roadmap, ett möte där vi "brainstormade" fram tänkbara områden som fick bli en strukturerad lista att jobba efter. Listan prioriterades och får utgöra ett underlag för våra månadsmöten. Trots ett hårt arbete så kände vi en uns av dåligt samvete för att vi inte satt ute hos kunderna den dagen. Efter en kort diskussion på lunchen så insåg vi att det jobb vi gjorde var mycket viktigt för företagets framtid och utveckling och att vi faktiskt har suttit hos kunderna 40 timmar vecka ut och vecka in samtidigt som vi har startat upp bolaget med allt vad det innebär i form av registreringar hos bolagverket, skatteverket, banken, ISP, bokföring mm.