F achbeitrag - trivadis.com

ger Business Intelligence beim IT-Lösungsanbieter Trivadis mit Hauptsitz in Basel und
Niederlassungen in der Schweiz, Deutschland
und Österreich.
E-Mail: [email protected]
S o nderdr u c k
aus BI-Spektrum
Sonderausgabe tdwi 2008
für
Peter Welkenbach verfügt über mehr als
zehn Jahre Erfahrung mit objektorientierten Systemen und komplexen Integrationsarchitekturen.
Als Principal Consultant, Trainer und Mitglied
des Architektur Boards von Trivadis liegt sein
aktueller Schwerpunkt auf modernen EnterpriseArchitekturen und deren Bedeutung für zukunftsorientierte Geschäftsstrategien.
E-Mail: [email protected]
GRID-Computing
Neue Echtzeit-BIModelle verändern
die Finanzwelt
Bereits in den 90er Jahren, nach Einführung der ersten
BI-Applikationen, wurde erkannt, dass ein Data Warehouse (DWH) nicht nur zum Reporting von Managementinformationen dienen kann. Aus der anfänglichen,
produktorientierten Sicht auf die Daten zur vornehmlichen Analyse von Vertriebsinformationen entwickelte sich mehr und mehr eine kundenorientierte Sicht im
Zuge von Customer-Relationship-Management-Initiativen (CRM). Mit dieser Entwicklung wurde auch der unschätzbare Wert eines konsolidierten DWH klarer: Die
Daten konnten zum Beispiel genutzt werden, um Kundenabrechnungen von historischen Umsätzen abhängig
zu machen oder Kundenkontakte zu analysieren und
so Kampagnen effizienter durchzuführen. Insbesondere
durch das analytische CRM wurden in der Vergangenheit
erste BI-Applikationen mit operativem Charakter aufgebaut. Die strikte Trennung zwischen BI und operativer
Welt begann zu bröckeln.
Heute gibt es eine Vielzahl von Entwicklungen, die diese
Auflösung der Trennung in operative Systeme und dispositive BI forcieren. Hierzu gehören unter anderem analytische
Anforderungen im Kundensupport, bei Cross-Selling-Initiativen, bei der Kündigungsbearbeitung, in der Betrugsaufdeckung, im Supply-Chain-Management oder bei der Steuerung von Produktionsprozessen. Entscheidend dabei ist,
dass durch die engere Verzahnung von BI und operativen
Prozessen auch die so genannte Datenlatenz, das heißt die
Zeit zwischen Aufkommen eines Datums im operativen
System und der Verarbeitung durch den Ladeprozess ins
DWH, immer stärker in den Vordergrund rückt. Dies ist
nicht zu verwechseln mit der zuvor diskutierten Nutzungsart des BI-Systems für strategische, taktische oder operative Entscheidungen. Realtime- oder Near-Realtime-BI ist
eben nur ein Spezialfall von operativer BI.
Dies erfordert Architekturen, die BI-Funktionalitäten auf
Daten anbieten mit sehr kurzer Verfügbarkeitsverzögerung
im Stunden-, Minuten- oder gar Sekundentakt. Insbesondere die Verknüpfung dieser Daten mit historischen Daten
aus dem DWH ist ein überaus spannendes Feld der BI.
Kaum sind Architekturen dieser Art realisierbar, kommt
jedoch bereits die nächste Welle an Anforderungen – so
zum Beispiel im Finanzmarkt. Dieser ist geprägt von
Datenmengen, die in Echtzeit nicht mehr zu analysieren sind. Zum einen, da sie etwa Börsendaten enthalten,
die mehr oder weniger parallel auf der ganzen Welt über
Daten-Feeds wie Reuters oder den CEP der Deutschen
Börse eingespielt werden. Zum anderen, da sie gegebenenfalls komplexe Strukturen beinhalten, die erst in einen sinnvollen Zusammenhang gebracht werden müssen.
Hierzu zählen zum Beispiel Unternehmensmeldungen,
die Ereignisse wie komplette Risikoneuberechnungen
auslösen können, oder auch Wertpapier-Ticks, die zuerst
zu einem Kurs oder Index verdichtet werden müssen. Das
aber ist Voraussetzung, um Services anzubieten wie die
Top 10 der gehandelten Wertpapiere der letzen fünf Minuten oder Informationen über Aktien, die an bestimmten
Börsen bereits um einen bestimmten Prozentsatz gestiegen oder gefallen sind, an anderen Handelsplätzen jedoch
noch nicht.
Grundsätzlich versagen existierende BI-Architekturen
bei Anforderungen dieser Art. Sie sind heute nicht in der
F achbeitrag
Jan-Henrik Fischer ist Solution Mana-
BI-spektrum l TDWI-Sonderheft 2008
13
F achbeitrag
Lage, parallel große Datenmengen
global in Echtzeit mehrstufig zu verarbeiten, dabei diese Daten temporär zu
komplexen Informationen zusammenzufügen, Ereignisse abzuleiten, die
mit Analysen auf historischen Daten
begründet und gegebenenfalls kombiniert sind, und die erarbeiteten Regeln
in Echtzeit auf Datenfeeds anwenden.
Um diesen Anforderungen gerecht
zu werden, ist eine Kombination aus
bekannten Near-Realtime-Mechanismen, hochskalierbaren Parallel-GridArchitekturen und Engines zum Complex Event Processing (CEP) denkbar.
Realtime-BI löst die Trennung operativ-dispositiv
Prozesse
DWH
BI Server
Abb. 1: Schematische Near-Realtime-Architektur : Entweder wird über Adapter direkt auf die
operative Datenbasis zugegriffen oder es wird eine spezielle Datenzwischenhaltung (Operational Data Store – ODS beziehungsweise Low Latency Data Mart – LLDM) genutzt mit
geringer Latenz zur Speicherung und Vorverarbeitung der operativen Daten.
Complex Event Processing System
Historical
Data
Business Processes
Computer Systems
Production Systems
Etc.
Complex Event
Event Publisher
Event Subscriber A
Event Subscriber B
Event
Topic A
Router
Topic B
Message Broker
Abb 2: Klassische Event-Verarbeitung mit Messaging
Im klassischen Architekturszenario werden eine Messaging-Middleware als zentrales Element
zur Event-Vermittlung sowie Loadbalancing und Failover eingesetzt. Events werden durch
Publisher an die Middleware gesendet, die Middleware sorgt für ein Routing der Events, und
angemeldete Subscriber erhalten einfache oder bereits aggregierte Events zu einer weiteren
Auswertung zugestellt.
Beispiel einer CQL-Abfrage aus
dem Oracle CEP Whitepaper:
IF MSFT price moves outside 2%
of MSFT-15-minute-VWAP
(volumeweighted average price)
FOLLOWED BY S&P moving by 0.5%
AND IBM‘s price moves up by 5%
OR MSFT‘s price moves down by 2%
ALL within a 2 minute time window
THEN BUY MSFT and SELL IBM;
BI-spektrum l TDWI-Sonderheft 2008
14
ETL
ODS
Complex Event Processing
und
Event Driven Architectures
(EDA)
Bei Complex Event Processing handelt es sich um eine Technologie für
kontinuierliche Echtzeit-Datenanalyse. Als ihr geistiger Vater gilt David
Luckham von der Stanford University [Luc02]. Mit dieser Technologie
versucht man, multiple Ereignisse
aus der Gesamtheit von einfachen
und komplexen Ereignissen innerhalb
eines Ereigniskontinuums (auch Ereigniswolke) zu untersuchen, mit dem
Ziel, die für sein Anliegen relevanten
Ereignisse zu identifizieren und sie einer zeitlichen Korrelation zuzuordnen.
Eine wesentliche Komponente von
CEP-Engines ist die Continous Query
Language (CQL), die nicht umsonst
eine namentliche Verwandtschaft mit
Operative Systeme
dem sonst im BI so wichtigen SQL hat. Diese Sprache
ähnelt im Aufbau dem SQL, kann aber aktiv auf Datenströme angewandt werden und beinhaltet neue Elemente,
insbesondere das relative Zeitfenster. So können Abfragen, die als SQL-Statements vom BI-Server komplexe
Events formulieren, zum Beispiel auf Datenströme der
letzten fünf Minuten angewandt werden. CQL bildet die
Verbindung zum klassischen BI.
Event-Middleware
Basis einer CEP-Engine ist eine Middleware, die für den
Transport der Ereignisse in sinnvoller Form sorgt. Die
Verwandtschaft mit einer serviceorientierten Architektur
GRIDs
Der Begriff GRID ist nicht eng eingegrenzt. Unterschiedliche Quellen definieren den Begriff durchaus mit unterschiedlichen Bedeutungsrahmen. Joshy Joseph definiert
ein Grid wie folgt [Jos04]: „Grids repräsentieren ein verteiltes System für gemeinsame Resourcen der beteiligten
Teilnehmer […]. Grids stellen eine verteilte Architektur
dar, welche die Problemkreise eines verteilten Computing Grid mit niedriger Latenz, Nebenläufigkeit und Ausfallsicherheit adressiert.“
Unter einem Data-Grid wird ein System verstanden, welches den Applikationen einen gemeinsamen
Speicherbereich über alle Knoten des Grids hinweg
zur Verfügung stellt. Eine einzelne Applikation, in unserem Falle also eine CEP-Engine, kann somit über
wesentlich mehr Speicher für Berechnungen verfügen, als ein einzelner Rechner ermöglicht. Diese Problematik ist zwar in Zeiten von 64-Bit-Architekturen
nicht mehr so relevant wie früher, jedoch ermöglicht
die Verteilung auch eine Ausfallsicherheit, da die Daten im Grid auf unterschiedlichen Knoten redundant
vorgehalten werden können. Data-Grids werden heutzutage häufig mit Computational-Grids gemeinsam
genutzt, beziehungsweise wird die Funktionalität von
F achbeitrag
(SOA) legt nahe, dass man für moderne
Complex Event Processing System
Ansätze eine Art ESB (Enterprise Service
Historical
Data
Business Processes
Complex Event
Bus) als moderne Integrationsplattform
Computer Systems
Production Systems
wählen wird, beziehungsweise dass eine
Etc.
CEP-Engine als Service in eine EDA integriert werden kann. Externe Ereignisse
Event Producer
werden durch spezifische Producer (AdEvent Consumer A
Event Consumer B
apter) zum ESB gemeldet und dort in ein
Event
internes Nachrichtenformat transformiert.
Sie müssen anschließend als Nachricht
dem jeweiligen Consumer (CEP-Agents,
CEP-Engine) zugeführt werden.
Node
A
Durch die Verbindung von klassischen
BI-Architekturen mit CEP-Engines ist
Node
n
es nun möglich, die komplexen Strukturen, die durch die detaillierte BI-Analyse
GRID
entdeckt wurden, auf Echtzeit-Datenströme anzuwenden, zum Beispiel Er- Abb 3: CRI Übersicht.
eignisse sich ändernder Börsenkurse im Die messaging-basierte Middleware wird durch Grid-Technologie ersetzt. Dies ermöglicht
Verhältnis zu anderen Ereignissen wie die Nutzung auch größerer Server-Cluster (Node A bis Node N), auf denen eine DatenvorFirmeninformationen – eine hervorra- haltung, Datentransport, Skalierbarkeit und Hochverfügbarkeit durch die Grid-Infrastruktur
gende Technologie, um die Datenflut der gewährleistet wird. Weiterhin sind somit auf der Grid-Ebene je nach Produkt zusätzliche
Finanzwelt auf Relevanz zu prüfen. Wie Grid-Funktionalitäten (wie z. B. höchst performante, parallelisierbare clusterweite Aggreaber garantiert man die parallele Ver- gationen und Berechnungen) verfügbar, welche die klassische Eventverarbeitung ergänzen.
arbeitung von Datenfeeds, die weltweit
auftreten? Wie lässt sich die immens hohe Skalierbar- Data- und Computational-Grid in ein und demselben
keit und Ausfallsicherheit gewährleisten, ohne dies Produkt angeboten. Computational-Grids erlauben es,
zu Lasten der Latenz realisieren zu müssen? Bei dieser die Rechenoperationen parallel über das Grid verteilt
Frage werden so genannte Grid-Architekturen relevant.
auszuführen und dienen somit der Erhöhung der potenziellen Rechenleistung.
Wesentliche Aufgaben von Grids sind:
◆ Distributed Caching und Processing: Daten werden
über alle Gridknoten verteilt. Hierzu sind unterschiedliche Verteilungstopologien und -strategien möglich.
Ein Data-Grid kann in unterschiedliche, von einander
getrennte Sub-Caches unterteilt werden. Dies erlaubt
effektivere Zugriffsmechanismen durch Vorfilterung.
Die Verteilung der Daten über verschiedene physikalische Knoten hinweg garantiert eine dauerhafte
Verfügbarkeit und Datenintegrität der Daten auch im
Fehlerfall einzelner Knoten. Das automatische Fail­
over-Verhalten und die Loadbalancing-Funktionalität sind Teil der Grid-Infrastrukturkomponente. Die
Transaktionssicherheit auch über den kompletten Grid
hinweg wird gewährleistet.
◆ Event Driven Processing: Funktionalität von Computational-Grids. Rechenoperationen und Transaktionen
können parallel über alle Grid-Knoten hinweg durchgeführt werden. Eine einfache Ereignisverarbeitung,
ähnlich dem Triggermechanismus von Datenbanken,
sorgt dafür, dass auf Datenänderungen reagiert werden
kann. Einzeldaten im Grid können mit dem Konzept
von In-Memory-Views und In-Memory-MaterializedViews zu komplexeren Datenkonstrukten zusammengefasst werden.
BI-spektrum l TDWI-Sonderheft 2008
15
F achbeitrag
CRI als neues Architekturkonzept
Wir haben gesehen, dass Complex Event Processing als
Real-Time-Analyse vielfältige Möglichkeiten bietet. Diese
Möglichkeiten ergeben sich vor allem für komplexe Abfragen auf Datenströmen, die jedoch dann entsprechende
Anforderungen an die Laufzeitumgebung stellen. Weiterhin haben wir aufgezeigt, wie sich heutzutage Grid-Technologien nutzen lassen und wie aktuelle Konzepte zur
Verschmelzung von SOA mit Grid-Technologie aussehen.
Nun liegt es nahe, die Fähigkeiten der beiden Technologien Complex Event Processing und SOA-Grid zusammen zu nutzen und somit dem Business hochskalierbare
Analyseapplikationen für komplexe Mustererkennungen in
Echtzeitszenarien zur Verfügung stellen zu können. Diese
Verschmelzung der Technologien bezeichnen wir als Complex Realtime Intelligence, kurz CRI. Im Grunde genommen handelt es sich hierbei im einfachsten Fall um eine
Event-Driven-Architecture mit Complex Event Processing
Engines als Consumern, wobei der Nachrichtentransport
und auch eine Voranalyse und Vorfilterung feingranularer
Einzelereignisse mit Grid-Technologie erfolgt. Die Infrastrukturkomponenten des Grids sorgen auch für ein Loadbalancing, Ausfallsicherheit und Verfügbarkeit von historischen Daten aus Datamarts im In-Memory-Cache.
Abbildung 3 zeigt die grundsätzliche Idee hinter dem
CRI-Konzept. Event-Producer (Prozesse, Systeme, etc.)
speisen über Adaptoren in das Gesamtsystem ein. Ein
GRID sorgt für die skalierbare Verteilung dieser Events,
die dann von angeschlossenen Event-Consumern analysiert und auch als komplexe Events verarbeitet werden
können. Diese können mit historischen Daten korreliert
werden oder aber auch in die Systeme mit den historischen Daten weitergeleitet werden.
BI-spektrum l TDWI-Sonderheft 2008
16
Die Kombination aus Grid und CEP erlaubt es, mit
einfachen Mitteln höchst skalierbare, aber dennoch
einfach wartbare Auswertungsarchitekturen für Neartime-BI zu schaffen. Hier wird es in naher Zukunft sicherlich noch weitere Architektur-Blueprints und BestPractice-Beschreibungen geben, um diese Technologien
einfach und gewinnbringend im eigenen Unternehmen
zu integrieren. Nach unserer Einschätzung werden Finanzinstitute die ersten Adaptoren dieser Technologien
sein, profitieren sie doch am meisten von der Verbindung
komplexer Analyse mit weltweit durchleuchteten Echtzeit-Events – in den Risiko- und Börsensystemen zählt
jede Sekunde, die an Latenz eingespart werden kann.
Literatur
[Jos04] Joseph Joshy, Fellenstein Craig: Grid Computing,
Prentice Hall, 2004.
[Luc02] Luckham David: The Power of Events: An Introduction to Complex Event Processing in Distributed
Enterprise Systems, Addison-Wesley Longman, 2002.
BI-SPEKTRUM
ist eine Fachpublikation des Verlags:
SIGS DATACOM GmbH · Lindlaustraße 2c · 53842 Troisdorf
Tel.: 0 22 41/23 41-100 · Fax: 0 22 41/23 41-199
E-mail: [email protected] · www.bi-spektrum.de
www.sigs.de/publications/aboservice.htm