/image%2F1093946%2F20160225%2Fob_122d53_rb-100x100.jpg)
Datenanalyse im DWH
Veröffentlicht auf 23. Februar 2010
Die Datenanalyse in der Entwicklung im DWH ist, ebenso wie z.B. Design und Architektur, eine wichtige Phase bevor man mit der eigentlichen Entwicklung beginnt. Leider wird sie, aus den verschiedensten Gründen, mindestens genauso oft vernachlässigt oder in die spätere Entwicklung verschoben.
Die ersten Einflüsse dieser Vernachlässigung bekommen die Entwickler zu spüren. Sie müssen Software für ETL-Prozesse entwickeln, ohne genau zu wissen, was verarbeitet wird. Die Folge dieser Unkenntnis hat bereits in dieser frühen Phase entscheidende Auswirkungen auf den weiteren Projektverlauf, denn der ersten Entwicklungsstufe wird zwangsläufig noch weitere folgen. Dies geschieht aber oft erst kurz vor der Betriebaufname in der Produktion, da hier meistens die ersten produktionsnahen Daten zur Verfügung stehen.
Auch dies könnte man bewerkstelligen, wenn man nur eine weitere Entwicklungsphase benötigen würde, in der Regel ist allerdings eine komplett neue Iteration nötig, der gegebenenfalls noch weitere folgen. Eine Iteration umfasst eine Konzeptionierungs-, Entwicklungs,- Test- und Deploymentphase. Dies benötigt je nach Projekt auf jeden Fall wieder mehrere Arbeitstage, wenn es nicht dazu kommen soll, dass für anderen Projekten ebenfalls benötigte Ressourcen dort abgezogen und sie dadurch in Mitleidenschaft gezogen werden sollen.
Zu einer Datenanalyse gehört eine genaue Definition der zu liefernden Daten (Typ, Inhalt), Lieferung und -zeiten, Kenntnis des Formats der Datenfelder, der Menge und gegebenenfalls der fachlichen Zusammenhänge der Quelldaten. Kompromisse sollten hierbei nur bedingt gemacht werden, eine Verarbeitung von qualitativ schlechten oder falschen Daten dürfte aus betriebswirtschaftlicher Sicht niemanden weiterbringen, ein weiteres Augenmerk sollte daher auf die Datenqualität gelegt werden.
Bisherige Implementierungen von generische Ansätzen in einem Data Warehouse, um dem angesprochenen Problem zu entgehen und eventuell die Wiederverwendbarkeit zu erhöhen, waren meiner Erfahrung nach bisher nicht erfolgversprechend und rentabel, da hier viel zu viele Abhängigkeiten bei nicht konsequenter Trennung der Logik auftraten. Im Test wurden diese Fehler leider nicht gefunden, da die Komplexität und der Zeitaufwand für vollständige manuelle Tests in einen betriebswirtschaftlich unrentablen Bereich abgeglitten wären. Die Fehler wurden somit erst in Produktion bekannt.
Sollte jemand bessere Erfahrungen mit diesem Thema gemacht haben, würden ich und die Leser dieses Blogs sich bestimmt über einen kleinen Erfahrungsbericht freuen. Schreiben Sie mir!
Die ersten Einflüsse dieser Vernachlässigung bekommen die Entwickler zu spüren. Sie müssen Software für ETL-Prozesse entwickeln, ohne genau zu wissen, was verarbeitet wird. Die Folge dieser Unkenntnis hat bereits in dieser frühen Phase entscheidende Auswirkungen auf den weiteren Projektverlauf, denn der ersten Entwicklungsstufe wird zwangsläufig noch weitere folgen. Dies geschieht aber oft erst kurz vor der Betriebaufname in der Produktion, da hier meistens die ersten produktionsnahen Daten zur Verfügung stehen.
Auch dies könnte man bewerkstelligen, wenn man nur eine weitere Entwicklungsphase benötigen würde, in der Regel ist allerdings eine komplett neue Iteration nötig, der gegebenenfalls noch weitere folgen. Eine Iteration umfasst eine Konzeptionierungs-, Entwicklungs,- Test- und Deploymentphase. Dies benötigt je nach Projekt auf jeden Fall wieder mehrere Arbeitstage, wenn es nicht dazu kommen soll, dass für anderen Projekten ebenfalls benötigte Ressourcen dort abgezogen und sie dadurch in Mitleidenschaft gezogen werden sollen.
Zu einer Datenanalyse gehört eine genaue Definition der zu liefernden Daten (Typ, Inhalt), Lieferung und -zeiten, Kenntnis des Formats der Datenfelder, der Menge und gegebenenfalls der fachlichen Zusammenhänge der Quelldaten. Kompromisse sollten hierbei nur bedingt gemacht werden, eine Verarbeitung von qualitativ schlechten oder falschen Daten dürfte aus betriebswirtschaftlicher Sicht niemanden weiterbringen, ein weiteres Augenmerk sollte daher auf die Datenqualität gelegt werden.
Bisherige Implementierungen von generische Ansätzen in einem Data Warehouse, um dem angesprochenen Problem zu entgehen und eventuell die Wiederverwendbarkeit zu erhöhen, waren meiner Erfahrung nach bisher nicht erfolgversprechend und rentabel, da hier viel zu viele Abhängigkeiten bei nicht konsequenter Trennung der Logik auftraten. Im Test wurden diese Fehler leider nicht gefunden, da die Komplexität und der Zeitaufwand für vollständige manuelle Tests in einen betriebswirtschaftlich unrentablen Bereich abgeglitten wären. Die Fehler wurden somit erst in Produktion bekannt.
Sollte jemand bessere Erfahrungen mit diesem Thema gemacht haben, würden ich und die Leser dieses Blogs sich bestimmt über einen kleinen Erfahrungsbericht freuen. Schreiben Sie mir!