leanbi
01/12/2014

Data Warehouse – Eine zu große Last für den Mittelstand?

Ab den 90´Jahren wurde das Konzept des Data Warehouse (DWH) von Inmon [1] und Kimball [2] entwickelt, mit dem Ziel die firmeneigenen Daten zentral und in hoher Qualität zu halten. Das DWH soll die einzige Grundlage (Single Source of Truth) für taktische und strategische Entscheide einer Firma sein. Diese Konzepte haben sich bis in die heutige Zeit als gültig erwiesen. Hinzugekommen sind verschieden Adaptionen durch das Aufkommen neuer Technologien. Wie die BIG DATA Technologien zu Anpassungen der Datenmodelle beitragen können, wurde bis anhin noch recht wenig ausgeführt.

Wie sieht ein DWH für KMU’s in der heutigen Zeit aus? Was kann BIG DATA dazu beitragen? Das wollen wir besprechen.

Der Aufbau und Betrieb eines Data Warehouse gestaltet sich schnell als zu aufwändig für KMU‘s, auch wenn vordefinierte Datenmodelle und Reports eine gewisse Erleichterung bieten. Dies besonders darum, weil ein DWH mehrere Datenschichten mit mehreren Datenmodellen aufweist.

Müssen also Mittelständer in den sauren Apfel eines aufwändigen DWH beißen, wenn auch diese eine Datenbasis für Entscheide aufbauen wollen? Nein, denn es geht auch einfach, wenn gewusst wie. Doch zuerst einmal die grundlegende Frage: Wieso benötigen KMU‘s überhaupt ein Data Warehouse (DWH)?

Die Definition von Zeh [3], bietet hierfür einen guten und prägnanten Einstieg:

„Ein Data-Warehouse ist ein physischer Datenbestand, der eine integrierte Sicht auf die zugrundeliegenden Datenquellen ermöglicht.“[1]

Der Zweck eines DWH lässt sich so einfach formulieren:

  • Historisierung der Daten mit dem Zweck, dimensionale Analysen ausführen zu können, beispielsweise Zeitreihen.
  • Zusammenführung der Daten aus mehreren Datenquellen, um zusammenhängende Erkenntnisse zu erhalten.
  • Aggregation von Daten, damit Informationen einfach einsehbar sind und performante Auswertungen erfolgen können.

Parallel zum operativen Reporting, bei welchem direkt auf den Datenquellen ausgewertet werden kann, werden im DWH die Daten nochmals physisch abgelegt.

Die Praxis zeigt, dass die Datenintegration und Datenmodellierung ca. 80% eines typischen Business Intelligence (BI) Projektes ausmachen. Nur 20% sind die Aufwände für das eigentliche Front End wie Standard und Ad Hoc Reports und Dahsboards. Mit der komplexen Datenmodellierung einer konventionellen DWH- Architektur wird ein DWH schnell schwerfällig, für das Fach undurchsichtig und verträgt sich nicht mit den agilen und sich fortwährend ändernden fachlichen Ansprüchen, und besonders nicht mit unseren Ansätzen von LeanBI.

Wir wollen uns also fragen, wie wir ein Data Warehouse für den Mittelstand so stark vereinfachen können, dass ein solches optimal bei kleinen Kosten einzusetzen ist, gleichzeitig aber eine langfristige und qualitativ hochstehende Lösung für den Kunden umgesetzt bleibt.

Wenn wir nun die Konzepte von Inmon und Kimball betrachten, so passt der Kimball Ansatz eher in unsere agile Welt. Nach Kimball werden fachspezifische Data Marts mit Facts und Dimensionen aufgebaut, wobei die Dimensionen über „Conformed Dimensions“ zentral gepflegt werden. Die Dimensionen beinhalten alle Stammdaten wie Zeit, Produkt, Region, Kunde und viele weitere. Die den Data Marts zugrunde liegende DWH Schicht ist dafür da, die Daten in eine konsistente Form zu bringen und für die Datamarts zu transformieren und zu aggregieren. Ein Data Warehouse besteht damit nach Kimball in erster Linie aus einer Summe von Datamarts. Inmon setzt auf den konsequenten Ansatz, einen Data Warehouse Layer in der 3. Normalform einzuführen, der die Grundlage aller Datamarts ist. Der Vorteil liegt dann darin, dass die Daten in einer sehr fein-granularen Form im DWH vorliegen, sodass auch zukünftige neue Anforderungen direkt aus dem Datenpool der DWH Schicht alimentierbar sind. Prinzipiell leuchten beide Konzepte ein. In der Praxis sind in den letzten 20 Jahre bei vielen Unternehmungen auf beider Grundlagen äußerst komplexe DWH’s entstanden, die kaum abzulösen sind und ein langes „Legacy“- Dasein fristen.

Natürlich hat man sich die Frage nach einer Vereinfachung gestellt. Folgendes einleuchtendes Konzept findet breite Anwendung: Wenn die richtige Hardwaretechnologie zur Verfügung steht (MPP, Massive Parallel Processing), können die Daten in ein großes, einziges relationales Datenmodell überführt werden. Man entledigt sich damit der Datamarts, die auch immer einen hohen Projekt- und Betriebsaufwand und eine Einschränkung der Informationsbreite mit sich bringen. Es findet also ein Reduktion des Schichtenmodells statt (je nach Anwendung verbleiben aber trotzdem 2 bis 3 Schichten). Durch die kombinierte Hard- und Softwaretechnologie ist die Abfrageperformance immer noch vorhanden. Die Daten stehen damit übergreifend und Silo- frei zur Verfügung, bei gleichzeitig relativ einfacher Datenmodellierung. Dieser Vorteil muss jedoch erkauft werden. Das Datenmodell bedarf einer starken technischen und fachlichen Governance, um Modellierungsfehler zu verhindern. Die Infrastrukturanforderungen sind sehr hoch und teuer, Änderungen im meistens großen relationalen Modellen sind komplex, Umsetzungen weiterhin aufwändig. Eine starke Abhängigkeit zur Informatik bleibt bestehen.

In den letzten Jahren ist die In-Memory Technologie bekannter geworden, teils weil sich große Softwarehäuser diese Technologie neu auf die Fahne geschrieben haben, teils weil das physische Memory (RAM) einen starken Preiszerfall erlitten hat. Große Softwarehäuser, aber auch die Firmen selber kämpfen aber mit der Integration dieser In-Memory Lösungen. So entstehen immer noch „Side by Side“ Lösungen (zum Beispiel eine HANA Lösung nicht unter, sondern neben einem SAP BW), sodass sich der TCO (Total Cost of Ownership) anstatt zu reduzieren sich -wird die Bilanzgrenze richtig gesetzt- stetig erhöht.

Wir können und wollen nicht alle Erfahrungen der BI Welt über den Haufen werfen, aber unser Ansatz gestaltet sich als neu, durch neue heranwachsende Technologien, die ein langsames Umdenken ermöglichen. Es ist eine Kombination von Architekturvorgaben und Anwendung neuer DB- und BI- Technologien, die wir hier vorstellen werden.

Wir vereinfachen die Datenintegration und die Datenhaltung auf dem Rohdatenlayer zuerst einmal massiv. Dann wollen wir ein DWH mit einfachen, agilen und fachorientierte Lösungen bieten. Wir werden damit den Anteil Datenintegration und Datenmodellierung von den besprochenen 80% auf 40% herunterschrauben. Und: ein Teil der Datenmodellierung soll direkt durch das Fach geschehen, damit können wir Kosten nochmals erheblich reduzieren.

Es gibt viele TCO- Versprechungen, die nicht wirklich erfüllen. Sie werden nach dem Studium unserer Blogs verstehen, wieso wir den TCO einer DWH Lösung wirklich massiv reduzieren können, sodass der Einsatz für ein KMU verträglich wird.

Dann wollen wir auf dem BI Layer eine hohe Integration verschiedener BI Anwendungsfälle bieten. Diese einfache Erwartung wird leider von den vielen BI Herstellern und Consultants nicht wirklich erfüllt. Zum Beispiel wird der Planungsteil meistens in separaten Tools untergebracht. Planung, Dashboarding, Reporting, Analyse aus einem integrierten Tool, egal auf welchem Device, aus einem Guss ohne mehrfache Erstellung.

Interessiert? Bleiben Sie dran…nächste Blogs

  • Ein BI Tool aus einem Guss: Wir stellen unseren neuen Technologiepartner vor
  • Datenmodellierung für den Mittelstand
  • Planung und Budgetierung, schnell und einfach für den Mittelstand
  • Ein Datensee für den Mittelstand. Wie nutzen wir BIG DATA Technologie bei kleinen Datenmengen?
  • Quellanbindungen einfach gemacht!
  • Wie können BI Anforderungen schnell und einfach erhoben werden?

[1] Inmon, W.H. Building the Data Warehouse (Third Edition), New York: John Wiley & Sons, (2002).

[2] Kimball, R. and M. Ross. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling (Second Edition), New York: John Wiley & Sons, 2000.

[3] Thomas Zeh: Data Warehousing als Organisationskonzept des Datenmanagements. Eine kritische Betrachtung der Data-Warehouse-Definition von Inmon. In: Informatik – Forschung und Entwicklung. 18, Nr. 1, 2003.

DWHArchitektur

admin
Letzte Artikel von admin (Alle anzeigen)