söndag 5 februari 2012

Process Metadata ur ett systemförvaltningsperspektiv

De flesta som är involverade i datalager-projekt eller jobbar med beslutsstöd i någon form har då och då stött på begreppet metadata. Vi tar ofta till en inpräntade definition av begreppet utan att vidare tänkta på vad det innefattar. Många brukar beskriva metadata som data om data, andra gör en större distinktion i ämnet och skiljer på olika typer av metadata. Här tänkte jag fördjupa mig i begreppet process metadata i datalagerlösningar mer specifikt vill jag ge min syn på hur denna typ av metadata kan ge vinster i förvaltningen av datalager och beslutsstödslösningar.

Vi börjar med att definiera vad metadata är och lånar denna definition från Kimball [1] som definierar detta som

../think about metadata as all the information that defines and describes the structures, operations, and contents of the DW/BI system. The DW/BI industry often refers to two main categories of metadata: technical and business. We've added a third category: process metadata. As you'll see in the descriptions of these categories that follow, technical metadata is primarily definitional, while business and process metadata are primarily descriptive. Be careful with these categories because there is some overlap. It's best to not get too dogmatic when you are dealing with metadata.

  • Technical metadata defines the objects and processes that make up the DW/BI system from a technical perspective. This includes the system metadata that defines the data structures themselves, like tables, fields, data types, indexes, and partitions in the relational engine, and databases, dimensions, measures, and data mining models. In the ETL process, technical metadata defines the sources and targets for a particular task, the transformations (including business rules and data quality screens), and their frequency. Technical metadata does the same kinds of things in the front room. It defines the data model and how it is to be displayed to the users, along with the reports, schedules, distribution lists, and user security rights.
    Some technical metadata elements are useful for the business users, like tables and column names; others, like the definition of a table partition function, are of no interest.

  • Business metadata describes the contents of the data warehouse in more user accessible terms. It tells you what data you have, where it comes from, what it means, and what its relationship is to other data in the warehouse. The display name and content description fields are basic examples of business metadata. Business metadata often serves as documentation for the DW/BI system. As such, it may include additional layers of categorization that simplify the user's view by subsetting tables into business process oriented groups, or by grouping related columns within a dimension. The metadata models used by the major BI tools provide these kinds of groupings. When users browse the metadata to see what's in the warehouse, they are primarily viewing business metadata.

  • Process metadata describes the results of various operations in the warehouse. In the ETL process, each task logs key data about its execution, such as start time, end time, CPU seconds used, disk reads, disk writes, and rows processed. Similar process metadata is generated when users query the warehouse. This data is initially valuable for troubleshooting the ETL or query process. After people begin using the system, this data is a critical input to the performance monitoring and improvement process. It can also be valuable to monitor user access both as a demonstration of the popularity of the warehouse and for security and compliance purposes. /..

Vi kan konstatera att metadata är en väldigt central del i en datalager-/beslutsstödslösning och det är lätt att förstå att viss metadata(Technical metadata) klarar vi oss inte utan och det är själva byggstenarna i vårt system. Andra metadata underlättar användandet av och förståelsen för systemet (Business metadata) men process metadata får ofta en betydligt mer undanskymd roll, något som jag personligen anser att vi måste råda bot på, härfinns verkligen guld att hämta.

Vad ska vi då ha denna process metadata till? Många av de produkter som vi använder tillhandahåller inte denna typ av metadata per automatik, andra produkter synliggör inte data som finns under huven. Enligt min erfarenhet är det endast ett fåtal produkter som både samlar och synliggör process metadata på ett enkelt sätt. Vi måste då föra på denna information i vår utvecklingsprocess, något som givetvis kostar pengar i systemets alla faser i livscykeln. Det är precis här när vi pratar om livscykelhantering som process metadata kommer in som små guldkorn och det är här jag tror att vi kan få igen den investering som krävs vid införandet.

Hur många gånger har du som systemförvaltare/förvaltningsleverantör eller utvecklare ställts inför en användare som påstår att, idag går den här rapporten otroligt mycket långsammare att köra än den gjorde för några veckor sedan? Här krävs hårda fakta för att avgöra om det finns något nytta i att börja optimera. Process metadata kan ge oss precis det hårda fakta där vi kan se svart på vitt om det är rapporten som tar lång tid att köra eller om det är användarens subjektiva uppfattning som har ändrats. Vi skulle kunna besvara frågan om det är fler rapporter med samma datakälla som har börjat ta längre tid att köra, då kanske det är värt att lägga tid på att optimera källan. Vi kan också tänka oss att vi kan hitta information om parametersättning och på detta sätt avgöra vad användarna oftast söker på. Detta skulle kunna vara ett underlag för optimering eller för en ny partitioneringsstrategi.

Ställs du någonsin inför behovet av att göra kapacitetsplanering för exempelvis hårdvara och lagringsutrymme? Vi skulle även här kunna dra nytta av process metadata för att läsa in detta och använda som verksamhetskunskap i vår förvaltningsverksamhet. När vi behöver analysera process metadata, kan vi rent av skapa oss egna analyskuber utifrån detta data? Kan vi skapa en trendanalys och svara på när kommer lagringsutrymmetatt ta slut, när kommer vi att spräcka tidsgränserna för vårt batchfönster?

Frågan är med kunskap om datalager, analyser och data mining hur långt kan vi dra detta, vilken ytterligare information kan vi komplettera vårt process metadata med och vad kan vi härleda för kunskap då?
Kan vi statistiskt beräkna när sannolikheten är störst att vår laddningsprocess kommer att krascha så att vi styr jourarbete och supportresurser till dessa tider?
Tanken är lockande, men även utan dessa högtravande funderingar finns det mycket värdefull information att extrahera. Vilka BI-applikationer är mest populära, vilka rapporter har inte använts det senaste året, vilka användare har inte loggat in i systemet kan vi spara licenskostnader på detta?

Hur förändras laddtider och lagringsutrymme, när behöver vi skala upp och ut i vår lösning, när behöver vi uppgradera?

Jag tror och hoppas att flera av de projekt jag kommer att arbeta med i framtiden kan se nytta av att investera i mer hantering av process metadata och analys av denna typ av information.


Referenser:
[1] Kimball et al., The Data Warehouse LifecycleToolkit, Second Edition. NewYork, Wiley, 2008, ISBN 978-0-470-14977-5, 116–117

Inga kommentarer:

Skicka en kommentar