Near real-time Data Warehousing ein Balance-Akt zwischen Mehrwert und Umsetzungskosten

Transkript

1 Near real-time Data Warehousing ein Balance-Akt zwischen Mehrwert und Umsetzungskosten Karol Hajdu Senior Consultant , Wien Basel Baden Bern Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg München Stuttgart Wien

2 Gängige Vorstellungen. Fachseite: Mit near real-time DWH wird erzielt, dass alle immer von den gleichen Daten reden. Wir brauchen flexible Lösungen um Diese Flexibilität bietet uns ein near real-time DWH an. IT Seite: Hochverfügbarkeit bedeutet near real-time. Die komplexe Ableitungslogik ist jetzt im DWH implementiert. Machen wir dieses DWH im Sinne von SOA - zum zentralen Service Provider! Wir brauchen nur die Aktualität zu erhöhen. Trivadis - Das Unternehmen 2

3 Agenda 1. Grundverständnis 2. Near-real-time Funktionalität Mehrwert und Rahmenbedingungen Daten sind immer im Spiel. 3. Umsetzungsbeispiel Projekterfahrung Komplexität und andere Kostentreiber 4. Fazit 3

4 Grundverständnis: Unternehmen und Prozesse Unternehmen = Prozesse + Akteure Akteure: interne MA und Systeme, Lieferanten, Kunden Prozesse: Oft wiederkehrende Prozesse Bsp.: Bestellabwicklung, Verkaufsabwicklung, Reklamationsabwicklung, Kredit-Vergabe, Konto-Eröffnung Hoher Anspruch an Standardisierung des Ablaufs, Freiraum für Individualisierung durch Ablauf- und Entscheidungs-regeln fest eingegrenzt Einmalige unikate Prozesse Entwurf/Anpassung der wiederkehrender Prozesse Konzeption neuer Produkte/Dienstleistungen Entwurf/Sicherstellung der externen und internen Kommunikation 4

5 Grundverständnis: Reaktionszeit (Latenz) der Business-Entscheide 5

6 Grundverständnis: Latenzzeit-Anforderungen an IT-Prozesse 6

7 Grundverständnis: Hochverfügbar = Echtzeit (0s Latenzzeit) Hochverfügbarkeit der Daten Voraussetzung für near real time Datenaufbereitung Near real-time Prozesse benötigen hochverfügbare Daten, ABER: Grossteil dieser Daten bildet nur den Entscheidungskontext, muss zwar hochverfügbar, aber nicht hochaktuell sein z.b. Kundensegment Nur sehr wenige Datenänderungen bilden derart neue Erkenntnisse ab, dass sie Echtzeit-Entscheidungsprozesse auslösen. Nur diese wenigen Daten müssen in Echtzeit verarbeitet werden! Trivadis - Das Unternehmen 7

8 Agenda 1. Grundverständnis 2. Near-real-time Funktionalität Mehrwert und Rahmenbedingungen Daten sind immer im Spiel. 3. Umsetzungsbeispiel Projekterfahrung Komplexität und andere Kostentreiber 4. Fazit 8

9 Wahrnehmung vom Business Event: Reaktionszeit unter 15 Std. - Wo gibt s Bedarf? Beispiel Automatische IT unterstützte Prozess-Steuerung, z.b. in Form einer Rückkopplung. Auskünfte und Entscheide im Customer Call Center Ständige Überwachung der Verkaufs- oder Usage- Entwicklung kurz nach Launch von neuem Produkt.. Rahmenbedingungen / Voraussetzungen Die Relevanz-Einstufung, der Entscheidungskontext und die Entscheidungsregeln sind in voraus (zur Design-Zeit) fest definiert. Entscheidungskontext sehr spezifisch (Einzelkunden bezogen). Entscheidungskontext und -regeln sind in voraus (zur Design-Zeit) rahmenweise definiert. Auslösungsereignis und Ereigniszeitraum sehr spezifisch (Produkt und Zeitraum bezogen).. 9

10 Wahrnehmung vom Business Event: Was sind die Voraussetzungen? 1. Die Liste der möglichen Entscheidungsvarianten sind in voraus definiert. 2. Die Anweisungen zur Umsetzung jeder der Entscheidungsvarianten sind in voraus definiert. 3. Der Anlass zur Überprüfung der Relevanz der Information kommt von aussen (Kunde, Supplier, ) oder aber er kommt periodisch von einem internen automatischen Dienst. Beispiel Automatische IT unterstützte Prozess-Steuerung, z.b. in Form einer Rückkopplung. Auskünfte und Entscheid im Customer Call Center Ständige Überwachung der Verkaufs- oder Usage- Entwicklung kurz nach Launch von neuem Produkt.. Rahmenbedingungen / Voraussetzungen Entscheidungskontext und -regeln sind in voraus (zur Design-Zeit) fest definiert. Entscheidungskontext sehr spezifisch (Einzelkunden bezogen). Entscheidungskontext und -regeln sind in voraus (zur Design-Zeit) rahmenweise definiert. Auslösungsereignis und Ereigniszeitraum sehr spezifisch (Produkt und Zeitraum bezogen).. 10

11 Wahrnehmung vom Business Event: Wo liegt der Kick die Komplexität? Identische Semantik implementiert durch unterschiedliche IT Applikationen! Std. Wiederkehrende (operative) Prozesse Call-Datetime Rating-Datetime Bezugszeit Belastungsdatum 2 Tage oder mehr Identisch => fast identisch: Unterschiede: - Integritätsanspruch! - Zeitachsen! Einmalige (unikate) Prozesse 11

12 Bedarf an near real-time Datenverarbeitung - Fazit Near real-time Informationsaufbereitung und deren ROI Der falsche Weg: Zentralisierung der Geschäftslogik als Auslöser für RT-Ausbau vom bestehenden DWH Unterschiede im Integritätsanspruch der Informationen! Verwendungszweck auf Business-Seite ist entscheidend, und nicht die Gemeinsamkeit bezüglich der Datenaufbereitung Adressierung des Mehrwerts auf Business-Seite ist entscheidend 12

13 Agenda 1. Grundverständnis 2. Near-real-time Funktionalität Mehrwert und Rahmenbedingungen Daten sind immer im Spiel. 3. Umsetzungsbeispiel Projekterfahrung Komplexität und andere Kostentreiber 4. Fazit 13

14 Process Warehouse Biopharmazie Zellkultur + Nährlosung etc. 80l Fermenter + Nährstoffe + Wachstum + Proben 400l Mehr Platz + Nährstoffe + Wachstum + Proben 2000l Noch mehr Platz usw l Ernte, Aufreinigung, Trocknung, Paketierung etc

15 Systemlandschaft Beteiligte Systeme 2*DualCore Opteron RedHat Enterprise 64 bit 250GB SAN Oracle 10.2 EE 15

16 Fachanforderungen Prozesskenngrößen ph-wert, optische Dichte, Zellkonzentration, Temperatur, Sauerstoffgehalt etc. Aus Sensoren in Fermentern etc. + Probenanalyse-Ergebnisse Visualisierbar und vergleichbar Image: Boehringer Ingelheim GmbH! "#""! "#""! "#""! "#""! "#"" Chargenbaum - Welcher Stoff, Welcher Prozess geht in Charge X ein? geht aus Charge X hervor?! "#""! "#"" 16

17 Aufgabe/Mehrwert vom PWH Vergleichbarkeit von Messdaten über Produktionsläufe hinweg gewährleisten Spezielle Prozessschritt-Marker/Labels in MES und LIMS, sowie diverse Dateiformate ermöglichen die Einordnung der Messdaten in ein 4-stufiges Phasenmodell Diese Phasen werden im PWH definiert (separate Applikation) Vergleich mit Ergebnissen teilweise auch gegen Verfahrensentwicklung und Test interessant Bspw. mit Dehnung der Zeitschienen einzelner Phasen zum Vergleich Near real-time Anforderung Wichtige Analysen müssen am selben Tag durchgeführt werden Max. 2 Stunden Verzögerung für diese Datenbestände 17

18 Umsetzung der near real-time Anforderung: Die Herausforderungen Daten-Extraktion Integration und Transformation Presentation Erkennung der Änderungen (Change Data Capture) Erstellung/Pflege der Indexe und Aggregate für kurze Antwortzeit der Abfragen Minimale Belastung der Quellsysteme Einfache Wiederanlauffähigkeit nach Abbruch kurze Durchlaufzeit Synchronisation der erkannten Datenänderungen Intelligenter Umgang mit outof-sync Situationen Kurze Durchlaufzeit Restriktiver Umgang mit Indexierung der near real-time Inhalte Asynchrones Nachführen der Indexe und Aggregate kurze Durchlaufzeit 2*DualCore Opteron RedHat Enterprise 64 bit 250GB SAN Oracle 10.2 EE 18

19 Near real-time Datenbewirtschaftung: die realen Herausforderungen Beispiel #1 Data Capturing dauert zu lange Beispiel: Capturing dauert 3 Stunden bei 2 stündlicher Ladung Abhängige Daten anderer Quellen können ebenfalls nicht verarbeitet werden Kritischer Ladestau! )% $% &* &'(&)% 19

20 Near real-time Datenbewirtschaftung: die realen Herausforderungen Beispiel #2 Load/Transformation/Aggregation Prozess dauert zu lange Beispiel: Messdaten Transformation dauert 3 Stunden bei 2 stündlicher Taktung )% Kritischer Ladestau! $% &* &'(&)% 20

21 Near real-time Datenbewirtschaftung: die realen Herausforderungen Beispiel #3 Quellsystem fällt aus Beispiel: MES Maintenance Abhängige Daten anderer Quellen können ebenfalls nicht verarbeitet werden oder zu viele Singletons oder Ladestau oder wiederholtes Fehlerladen )% $% &'(&)% &* 21

22 Near real-time Datenbewirtschaftung: die realen Herausforderungen Beispiel #4 Quelldaten nicht ausreichend synchron Zu viele Singletons oder Ladestau )% oder wiederholtes Fehlerladen $% &* &'(&)% 22

23 Near real-time Datenbewirtschaftung ist nur Mittel: das Ziel ist die near real-time Entscheidungsfindung! Status-Nachrichten der PHD Sensoren: jede 1s, 2500 Sensoren 1.3 GB / Std., 3 TB Daten in 3 Jahren Sensorwerte nur jede 10. Sekunde, nur für letzte 3 Monate ältere History auf Std-Basis verdichtet ph Wert: der Zeitpunkt der Änderung ist die Information, denn Laufzeit und Reihenfolge der ph Werte sind relevant Durchflüsse & Schalterpositionen ditto Schwankungen bei Durchflüssen müssen zeitlich viel präziser erfasst werden als die bei den ph Werten 130 MB / Std., 300 GB in 3 J. starker Informationsverlust IT Lösung mit wenig Involvierung der Fachseite Oracle BI-City MB / Std., 45 GB in 3 J. kein Informationsverlust IT Lösung mit viel mehr Involvierung der Fachseite

24 Agenda 1. Grundverständnis 2. Near-real-time Funktionalität Mehrwert und Rahmenbedingungen Daten sind immer im Spiel. 3. Umsetzungsbeispiel Projekterfahrung Komplexität und andere Kostentreiber 4. Fazit 24

25 Near real-time Data Warehousing ein Balance-Akt zwischen Mehrwert und Umsetzungskosten Mehrwert entsteht nicht durch near real-time Datenaufbereitung, erst durch near real-time Entscheidungsfindung und -umsetzung Komplexität der Implementierung bei IT steigt enorm Effizienteste Dämmung des Komplexitätsanstiegs: die IT versteht sehr gut den Business Mehrwert der near real-time Entscheidungsfindung! Daher: Der Business Mehrwert muss seitens Fachseite präzis und verständlich kommuniziert werden! 25

26 Vielen Dank!? Basel Baden Bern Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg München Stuttgart Wien