TPC-H benchmark data model

Over the last few weeks, Mathias Brink and I have worked hard on the topic of Data Vault on EXASOL.

Our (simple) question: How does EXASOL perform with Data Vault?

First, we had to decide what kind of data to run performance tests against in order to get a feeling for the power of this combination. And we decided to use the well-known TPC-H benchmark created by the non-profit organisation TPC.

Second, we built a (simple) Data Vault model and loaded 500 GB of data into the installed model.  And to be honest, it was not the best model. On top of it we built a virtual TPC-H data model to execute the TPC-H SQLs in order to analyse performance.

KISS –

K – Keep (Data Vault)

I – It (ETL in your Data Warehouse)

S – Small (lightweight processes aka short and easy SQL)

S – and simple (easy Inserts and Updates)

Auf dem 1. DDVUG Treffen hatten wir ein interessante Diskussion darüber, wo eigentlich die Datenmodellierung aufhört und Business Rules beginnen. Aufgehängt hatte sich dies an meiner Präsentation, in der es um einen Link ging, der eine 1:M (Hub A – (M) Link (1) – Hub B) Relation repräsentiert und über einen bi-temporalen Satelliten den gesteuert (end-dating) wird. So darf für jeden Eintrag im Hub B nur eine aktive Relation im Link existieren. Die Daten für das End-dating des Links kamen im von mir aufgeführten Beispiel bereits aus dem Quellsystem (Blogpost folgt bald).

Welche Zeit nehme ich für die Timelines in den Data Vault Entitäten? In meinen Projekten stellt sich immer wieder diese Frage. Dokumentiert das LoadDate im HUB, im LINK und im SAT den Load Date TimeStamp (LDTS) nach Dan Linstedt, oder doch die Transaction Time zu der Daten im Quellsystems entstanden sind? Oder besser die Extraktionszeit? Oder die Transaktionszeit der Datenbank1) zu der die Datenbank die Datensätze in die Tabellen speichert? Nicht einfach zu beantworten, oder?

Immer wieder kommt in Projekten die Frage auf, besser gesagt die Diskussion, ob Constraints in der Datenbank physisch sinnvoll sind oder nicht. Meist gibt es Vorgaben von DBAs oder durchsetzungsstarken ETLern, die eine generelle Abneigung gegen Constraints zu haben scheinen, dass Constraints nicht erwünscht sind. OK, diese Woche wurde mir wieder das Gegenteil bewiesen. Doch wie heißt es so schön: Ausnahmen ...

Auf dem #WWDVC und im Advanced Data Vault 2.0 Boot Camp haben wir ebenfalls über dieses Phänomen gesprochen. Das scheint weltweit zu existieren. Dazu hat kurz nach dem #WWDVC auch Kent Graziano einen Blogpost verfasst. Auf LinkedIn gab es dazu einige Kommentare.

Gut, wie argumentiert man am besten, bzw. was sind eigentlich die Vor- und Nachteile Constraints zu verwenden?

Anreise

Die Anreise zur Schulung mit KLM verlief ohne Probleme. Von Frankfurt nach Montreal, mit einem kurzen Stopp in Amsterdam und dann entspannt mit dem Auto über verschneite Landschaften nach St. Albans, VT, USA.

Auf dem Flug nach Amsterdam gab es viel Spaß im Flieger, da einer der Supervisors an Board seinen letzten Flug auf dieser Maschine hatte und sein Team ihn gebührend verabschiedete.

Das 1. Deutschsprachige Data Vault User Group (#DDVUG) Treffen findet auf der TDWI Konferenz 2014 in München statt. Dan Linstedt wird als Ehrengast extra aus St. Albans zu unserem Treffen kommen und einen Vortrag über Data Vault halten.

Darüber hinaus wird es viele anregende Vorträge und Diskussionen aus der Praxis geben. Es soll schließlich der Austausch zwischen allen Teilnehmern gefördert, das Fachsimpeln und Netzwerken im Vordergrund stehen.

Es ist eine Weile her seit ihr von mir etwas gehört habt. Entschuldigung.

Dafür geht es gleich mit etwas Großem weiter. Rückblickend wird es sich zeigen, ob hier ein historisches Ereignis in der Datenmodellierungsszene stattfindet: das erste weltweite Treffen (20.3.14 - 22.3.14) von Data Vault Interessierten in der Heimatstatt von Daniel Linstedt, in St. Albans, USA.