w26M2
w26M2
w26M2
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
• 4.2 Daten-Zugriff<br />
Barrieren einer traditionellen Batch-Verarbeitung<br />
Der Kernbaustein MapReduce der aktuellen Big-Data-<br />
Kerntechnologie Hadoop wird zu Recht als Batch<br />
Processing-Komponente eingeordnet (vgl. Tabelle 2).<br />
Tatsächlich ist das MapReduce-Framework ja ein System,<br />
das die parallele Ausführung von Jobs auf den Datenknoten<br />
eines Hadoop-Clusters plant, die Ausführung<br />
überwacht und die Berechnungsergebnisse zusammenführt<br />
(vgl. Unterabschnitt 4.1.1). Im Unterabschnitt<br />
4.2.1 werden praktische Aspekte der Anwendung der<br />
MapReduce-Komponente betrachtet und zwei populäre<br />
Bausteine erläutert, welche den Einsatz im IT-Alltag<br />
deutlich vereinfachen: Pig und Hive.<br />
Der traditionelle Ansatz für Data Warehouse und Big<br />
Data analysiert ruhende Daten. Die Überwachung und<br />
Steuerung dynamischer Prozesse bedarf eines anderen<br />
Ansatzes. Hierbei werden zeitlich geordnete Ereignisse<br />
aus heterogenen Quellen überwacht, verdichtet, gefiltert<br />
und korreliert. Das ist das Feld von Streaming und Complex<br />
Event Processing (Unterabschnitt 4.2.2).<br />
Ausführungen über Search & Discovery sowie Query<br />
ergänzen den Abschnitt.<br />
4.2.1 Batch Processing<br />
Bei der Batch-Verarbeitung werden Geschäftsvorfälle<br />
gesammelt und in – häufig nächtlichen, von Online-<br />
Betrieb freien – Batch-Läufen 56 verarbeitet. So werden<br />
durch Batch-Skripte bzw. ETL-Werkzeuge immer wiederkehrend<br />
die neu angefallenen Daten aus den operativen<br />
Systemen abgezogen und für entsprechende analytische<br />
Zielsysteme aufbereitet. Die neu berechnete Datenbasis<br />
bzw. Scores stehen den entsprechenden (Geschäfts-)<br />
Prozessen bzw. Analysenwerkzeugen mit entsprechender<br />
zeitlicher Verspätung zur Verfügung. Zur Verminderung<br />
dieser ETL-Verzögerungen beim Laden von Daten müssen<br />
die Batch-Läufe immer weiter parallelisiert und optimiert<br />
werden.<br />
In einem Big-Data-Szenario wird man dementsprechend<br />
schnell an vier Barrieren einer traditionellen Batch-Verarbeitung<br />
stoßen:<br />
Barriere<br />
Limitierte<br />
Sichtbarkeit<br />
Limitierte<br />
Skalierbarkeit<br />
Limitierte<br />
Agilität<br />
Eingeschränkte<br />
Historisierung<br />
Erläuterung<br />
Es gibt im Unternehmen zu viele<br />
(Alt-) Applikationen, aus denen noch<br />
keine Daten über geeignete Schnittstellen<br />
abgezogen werden können.<br />
Die Quellapplikationen bzw. deren<br />
eingerichtete Schnittstellen sind<br />
eventuell nicht auf immer wiederkehrende<br />
Abfragen bzw. auf Massendatenexport<br />
ausgerichtet.<br />
Die Ursprungsformate sind oft<br />
rigide in relationalen Schemata<br />
gespeichert. Batch-Austauschformate<br />
wie CSV speichern aus Performancegründen<br />
evtl. nur Auschnitte<br />
der Originaldaten.<br />
Eventuell hält das operative System<br />
nur einen kleinen Ausschnitt der<br />
Transaktionsdaten produktiv vor,<br />
z. B. Daten eines Jahres. Ältere<br />
Transaktionsdaten stehen dann nur<br />
noch in einem Archiv oder voraggregiert<br />
in einem Data Warehouse zur<br />
Verfügung.<br />
Tabelle 4: Barrieren einer traditionellen Batch-Verarbeitung<br />
Ein zentraler Hadoop-basierter Enterprise Data Lake<br />
hingegen vereinigt die Zwischenspeicherung der Originaldaten<br />
aus den Originalsystemen im HDFS und deren<br />
Tranformationen auf dem Wege einer hochperformanten<br />
parallelen Batch-Verarbeitung.<br />
56<br />
Die Bezeichnung stammt aus den 60er Jahren des 20. Jahrhunderts, denn die Daten (und oft auch Programme) lagen dabei als Lochkarten vor und wurden<br />
als Stapel eingelesen und verarbeitet.<br />
48
Change language