BigData-Architekturen

© Zühlke 2013

Dr. Georg Molter

Big-Data-Architekturen: Herausforderungen und Lösungen

9. Juli 2013 Folie 1

© Zühlke 2013

Übersicht

• Big-Data-Architekturen: Anforderungen und Trade-Offs

• Rahmenarchitektur und Lösungsbausteine

• Von den Anforderungen zur Architektur

9. Juli 2013 Big Data-Architekturen: Herausforderungen und Lösungen | Dr. Georg Molter Folie 2

© Zühlke 2013

Big Data-Architekturen: Herausforderungen und Lösungen

Dr. Georg Molter

Anforderungen und Trade-Offs


© Zühlke 2013

Anforderungen und Trade-Offs: Volume, Velocity und Variety

Big Data-Architekturen: Herausforderungen und Lösungen | Dr. Georg Molter

Volu

me

/ D

aten

men

ge

Velocity / Geschwindigkeit der Analyse

Tiefe(*) Analyse Vorhersage-Modelle

(*) Tief: Bis zu 10.000 mal größer Schnell: Bis zu 10.000 mal schneller

9. Juli 2013

Variety: „Big Data geht über strukturierte Daten hinaus, schließt unstrukturierte Daten aller Arten mit ein: Text, Audio, Video, Click Streams, Logdateien und mehr.“ IBM, Bringing Big Data to the Enterprise

Folie 4

Schnelle(*) Entscheidungen Reaktive Analyse Echtzeit-Bearbeitung von Analyse-Aufgaben

© Zühlke 2013

Anforderungen und Trade-Offs: Analyse-Stufen

9. Juli 2013 Big Data-Architekturen: Herausforderungen und Lösungen | Dr. Georg Molter

Explorative Analyse Experimentieren mit den

Daten Untersuchung der Daten

aus verschiedenen Blickwinkeln Schneiden und

Projektion der Daten entlang verschiedener, teilweise nichttrivialer Dimensionen

Modellbildung und –Validierung Ableitung und

Validierung in sich geschlossener Erklärungsmodelle Optimierung der Modelle

zur Steigerung von Aussagekraft und Trennschärfe

Modellanwendung / Automatisierte Analyse Anwendung der Modelle

im Produktivbetrieb zur Routine-Analyse realer Datensätze

Folie 5

Große Datenmengen erforderlich

Geschwindigkeit ist nicht absolut kritisch

Potenziell große Datenmengen, aber Vorfilterung möglich

Geschwindigkeit ist extrem wichtig

© Zühlke 2013

Anforderungen und Trade-Offs: Datenspeicherung


Speicherung aller in Frage kommender

Daten Speicherung der jeweils erforderlichen Daten

Keine Datenspeicherung

Anwendungen Explorative Analyse und

Modellvalidierung Archivierung

Auswirkungen Großes Datenvolumen, hohe

Kosten für Speicherung, hoher Ballast für die Verarbeitung, keine optimierte Strukturierung

Anwendungen Gezielte, optimierte Analyse für

einen spezifischen Zweck gemäß zuvor identifizierter Modelle

Selektion und Filterung zur Begrenzung der Datenmenge

Auswirkungen Geringere Unterstützung für

explorative Analyse

Anwendungen Streaming Analytics: optimierte

Analyse für spezifische Zwecke, zeitnah zur Datenentstehung

Stream Mining für explorative Analyse

Auswirkungen Keine Speicherungskosten Keine Möglichkeit für

nachträgliche weitere Analyse

© Zühlke 2013

Anforderungen und Trade-Offs: Datenrate und -Verteilung


Datenrate und Burstiness • Mit welcher Rate werden

die Daten erzeugt? • Mit welcher zeitlichen

Verteilung werden die Daten erzeugt?

Performance-Optimierung • Peak Performance • Guaranteed Performance • Opportunistic Performance

Analyse-Geschwindigkeit („Velocity“) • Innerhalb welcher Zeitspanne

muss ein Analyseergebnis vorliegen? – Bedingt durch physische Prozesse – Bedingt durch die Reaktion von

Menschen

© Zühlke 2013

Anforderungen und Trade-Offs: Überblick


Volume

Velocity

Sensibilität der Daten

Datenspeicherung

Datenrate

Performance-Optimierung

Analyseszenario

Variety / Strukturiertheit der Daten

E M

A Flexibilität

Skalierbarkeit

© Zühlke 2013


Dr. Georg Molter

Lösungsbausteine


© Zühlke 2013

Die Lambda-Architektur als Rahmen


Herausforderung • (Beinahe-)Echtzeit-Analyse großer Datenmengen

Batch Layer Serving Layer

Speed Layer New Data

All Data Batch Views

Realtime Views Queries

Lösungsansatz: Lambda-Architektur1

• Inkrementelle Berechnung der Analysefunktion mit „eventual accuracy“: query = λ(all data) = λbatch(old data) ⊕ λspeed(recent data)

Folie 10

1Nathan Marz and James Warren: Big Data - Principles and best practices of scalable realtime data systems, Manning 2012

© Zühlke 2013








Lösungsansatz: Lambda-Architektur • Inkrementelle Berechnung der Analysefunktion mit „eventual accuracy“:

query = λ(all data) = λbatch(old data) ⊕ λspeed(recent data)

Folie 11

© Zühlke 2013








Lösungsansatz: Lambda-Architektur • Inkrementelle Berechnung der Analysefunktion mit „eventual accuracy“:

query = λ(all data) = λbatch(old data) ⊕ λspeed(recent data)

Effiziente, tiefe und exakte Analyse großer Datenmengen Zeitversatz ist akzeptabel

Bereitstellung der Batch-Ergebnisse ("Batch Views") für Queries

Zeitnahe Analyse neuer Daten mit speziell dafür geeigneten Mechanismen Reduzierte

Anforderungen bzgl. Genauigkeit oder Tiefe

Folie 12

© Zühlke 2013

Lösungsbausteine: Data Warehouse und OLAP


Geschäftsanwendungen

Operative Datenbanken

Extraktion Extraktion

Transformation Transformation

Integration

Geeignet für • Automatisierte und

explorative Analyse • Mittelgroße

Datenmengen • Mittlere Velocity

Integration von Daten aus unterschiedlichen Quellen

Bereitstellung für verschiedene dispositive Zwecke

Originaldaten

Data Warehouse

Reporting & Analytics

Data Mining

Applications

© Zühlke 2013

Lösungsbausteine: Data Warehouse und OLAP






Integration

Geeignet für • Automatisierte und

explorative Analyse • Mittelgroße

Datenmengen • Mittlere Velocity

Integration von Daten aus unterschiedlichen Quellen

Bereitstellung für verschiedene dispositive Zwecke

Originaldaten

Data Warehouse


Data Mining

Applications

Folie 14

Technologie-/Produktalternativen • On-premise DWH: SAP BW, Oracle, MS SQL Server

• Cloud DWH: Redshift, Teradata

• Data Mining: R, WEKA (Waikato Environment for Knowledge Analysis), RapidMiner (früher YALE)

© Zühlke 2013

Data Warehouse

Alternative Datenkategorien und -Quellen






Integration


Data Mining

Folie 15

?

•Keine strukturierte Datenspeicherung erforderlich: Unmittelbare Verarbeitung, ggfs. Aufbewahrung für Archivierungszwecke

•Hohe Skalierbarkeit erforderlich

Applications

Social Media Connected Products

© Zühlke 2013

Alternative Datenkategorien und -Quellen: Map / Reduce-Auswertung


© Zühlke 2013



Problemfeld • Batch-Verarbeitung von großen Datenmengen

Lösungsprinzipien • Gliederung der Aufgabenstellung in einzelne Verarbeitungsschritte • Massive Parallelisierung ( verteilte Ausführung) • Lokalität (Speicherung und Query-Ausführung räumlich eng verknüpft)

Beispiel-Problemstellung • Auswertung von automatisch übertragenen Zählerständen

• Einzelner Ablesewert ist ein Schnappschuss, der nach Übermittlung – nur noch Dokumentationscharakter hat – nicht im Online-Zugriff stehen muss

• Zielfunktion der Auswertung: Kumulierter Verbrauch pro Verbrauchsstelle und pro Kunde

© Zühlke 2013



Map: Verdichtung pro Zähler

Zwischenergebnisse: Verbrauchswerte

pro Zähler

Reduce: Kumu- lierter Verbrauch

pro Kunde

Endergebnis: Kumulierter Verbrauch

© Zühlke 2013



Map: Verdichtung pro Zähler

Zwischenergebnisse: Verbrauchswerte

pro Zähler

Reduce: Kumu- lierter Verbrauch

pro Kunde

Endergebnis: Kumulierter Verbrauch

• Zur Analyse derselben Business-Fragestellung gibt es viele verschiedene Abbildungsmöglichkeiten auf Map / Reduce.

• Geeignete Wahl der Map- und Reduce-Funktionen ist kritisch, – um die Vorteile der Lokalität zu nutzen

– um Parallelisierbarkeit und Skalierbarkeit sicherzustellen

• … sie hat weitreichende Auswirkungen auf Performance und Datentransfer …

• … und damit auf Kosten!

© Zühlke 2013

Alternative Datenkategorien und –Quellen: Map / Reduce-Auswertung






Integration

Connected Products Folie 20

Data Warehouse


Data Mining

Applications Weitere Anwendungen

Geeignet für • Explorative und auto-

matisierte Analyse • Große Datenmengen • Batchverarbeitung • Vorverarbeitung von

Daten

© Zühlke 2013

Alternative Datenkategorien und –Quellen: Map / Reduce-Auswertung






Integration

Geeignet für • Explorative und auto-

matisierte Analyse • Große Datenmengen • Batchverarbeitung • Vorverarbeitung von

Daten

Data Warehouse


Data Mining


Folie 21

Connected Products

Technologie-/Produktalternativen • Hadoop in verschiedenen Open-Source-

Distributionen und als Bestandteil verschiedener kommerzieller Produkte: Hortonworks, Cloudera; MS Daytona / HDInsight; SAP HANA

• Hadoop-Cluster in der Cloud: Elastic MapReduce

• Explorative Analyse: Apache Pig, Apache Hive (Hadoop-basiertes DWH)

© Zühlke 2013

Alternative Datenkategorien und –Quellen: Stream Processing, CEP, Online Analytics


Problemfeld • Mustererkennung und regelbasierte Verarbeitung für einen Strom aus vielen

Einzel-Ereignissen • Filterung, Korrelation und Aggregation von Ereignissen

Lösung mit einer Complex Event Processing (CEP)-Engine • Beschreibung von Mustern und Regeln häufig mit SQL-ähnliche Sprachen:

z.B. CQL (Continuous Query Language), EPL (Event Processing Language)

„Wenn Ereignis A eintritt, unmittelbar gefolgt von Ereignis B, und innerhalb eines Zeitfensters von einer Stunde nicht Ereignis C, dann erzeuge ein neues Ereignis vom Typ X“

© Zühlke 2013

Alternative Datenkategorien und –Quellen: CEP, Stream Analytics, Online Analytics






Integration

Data Warehouse


Data Mining


Folie 23


CEP Engine Filterung Aggregation Korrelation

Adaption

© Zühlke 2013







Integration

Data Warehouse


Data Mining




Folie 24

Geeignet für •Automatisierte Analyse •Große Datenmengen •Hohe Velocity

Adaption

© Zühlke 2013







Integration

Data Warehouse


Data Mining




Geeignet für •Automatisierte Analyse •Große Datenmengen •Hohe Velocity

Technologie-/Produktalternativen • Trident / Twitter Storm, Esper

• Microsoft StreamInsight, Oracle CEP

Adaption

Folie 25

© Zühlke 2013

Lösungsbausteine: In Memory-Datenbanken

Lösungsansatz • Datenablage und -Verarbeitung im Hauptspeicher • Geringere Zugriffs-Latenzen, höhere Bandbreite, bessere Vorhersagbarkeit • Unterstützung für parallele Abfragebearbeitung • Speicherkapazität im Terabyte-Bereich (z.B. HANA-Deployment bei Red Bull

mit 8TB RAM1) • Persistenzsicherung mit Hilfe von Logdateien, Schnappschüssen und

Replikation

Technologie- / Produktalternativen • SAP HANA, Oracle TimesTen, SAG Terracotta • MySQL, Apache Derby, MonetDB

1 siehe http://reshaping-datacenter.de.ts.fujitsu.com/fileadmin/user_upload/documents/Downloads_DE/ps-hana-case-study-Red-Bull-em-en.pdf


© Zühlke 2013

Lösungsbausteine: DWH / Analytics Appliances

DWH / Analytics Appliance • Vorgefertigte Kombination aus Hardware (Server, Storage) und Software

(Betriebssystem, Middleware, Datenbanksystem, Analytics-Software) • Spezial- oder Standard-Hard- und Software

Spezifische Eigenschaften • Hohe Performance

durch parallele Abfragebearbeitung • Hohe Skalierbarkeit • Schnelles Setup

Beispiele • IBM PureData System for Hadoop, IBM Netezza / IBM PureData System for Analytics • Oracle Exadata / Exalytics • Teradata Data Warehouse Appliance • Microsoft Parallel Data Warehouse


• Für ein DWH mit 128TB Kapazität Kosten von € 500.000,- aufwärts1

1http://www.valueprism.com/resources/resources/

Resources/PDW%20Compete%20Pricing%20FINAL.pdf

Folie 27

© Zühlke 2013

Oracle Big Data Appliance: „Engineered system optimized for acquiring, organizing and loading unstructured data into Oracle Database 11g“ • Oracle NoSQL • Hadoop, Oracle Hadoop Adapter, Oracle Loader for

Hadoop • R als Statistik- und Grafiksprache • Oracle Enterprise Linux and Oracle HotSpot VM

• Einsatzgebiet: „Analyse der von Blogs, Social-Media-

Feeds, Smart-Metern, Sensoren und anderen Geräten erzeugten großen Datenmengen, die sich mit klassischen Data Warehouses und Business-Intelligence-Software so nicht erfassen lassen“



http://techsatwork.com/blog/?p=743

© Zühlke 2013

Oracle Exadata: „Engineered“ MPP-DBMS für OLTP-, OLAP- und gemischte Anwendungen • Bis zu 8 Datenbankserver, bis zu 128 CPU-Cores und 2TB Memory • 14 Oracle Exadata Storage Servers, bis zu 168 storage-nahe CPU-Cores für SQL-

Verarbeitung • Bis zu 5.3TB Exadata Smart Flash Cache • Unkomprimierte Kapazität pro Rack bis zu 432TB • Hybrid Columnar Compression mit Kompressionsraten von 10 bis 15 • Maximaler Stromverbrauch: 17,0kW

Oracle Exalytics / Exalogic: In-memory BI-Appliance • Ergänzt Oracle BI Enterprise Edition und die Exadata-Systeme • Bis zu 1TB und 40 CPU-Cores • Oracle TimesTen In-Memory DB



© Zühlke 2013

Einordnung der Lösungsbausteine

Klassisches DWH / OLAP

OLAP-Unter-stützung

Z.B. Cube-Berechnung

Klassische Vor-berechnung

Map/ Reduce

Hochparallele Analyse großer Datenmengen

Kernanwendung Kernanwendung

CEP / Stream Processing

Stream Analytics Kernanwendung Kernanwendung

In Memory-Verarbeitung

Schnelle Analyse im Haupt- speicher

Reaktionsschnelle automatisierte Analyse

Hoher Batch-Durchsatz im Hauptspeicher

Schnelle Analyse im Haupt- speicher

Analytics Appliances

Hochoptimiertes Gesamtsystem




Explorative Analyse

Automatisierte Analyse

Batch-Verarbeitung

Speed-Verarbeitung

Folie 31


© Zühlke 2013

Einordnung der Lösungsbausteine

Klassisches DWH / OLAP

Integration, Zusammenarbeit mit Business-Anwendungen

Mittlere Velocity; Zeitversatz ist übliche Praxis

Batch Layer

Map/ Reduce

Großes Datenvolumen, hohe Skalierbarkeit

Mittlere Velocity Batch Layer


Großes Datenvolumen, keine Speicherung

Hohe Velocity Speed Layer


„Kleines“ Datenvolumen Hohe Velocity Batch Layer und Speed Layer

Analytics Appliances

Hohe Skalierbarkeit, großes Datenvolumen

Hohe Performance durch parallele Abfragebearbeitung

Batch Layer und Speed Layer

Optimierung Velocity Lambda-Architektur


© Zühlke 2013


Dr. Georg Molter

Lösungsdesign


© Zühlke 2013

Von den Anforderungen zur Architektur


Identifikation und Herausarbeiten der wesentlichen Business-Fragestellungen

Volume

Velocity


Datenspeicherung

Datenrate


Analyseszenario


EM

AFlexibilität

Skalierbarkeit

KlassischesDWH / OLAP


Explorative und automatisierteAnalyse


Batch Layer

Map/Reduce

Großes Daten-volumen, hohe Skalierbarkeit




Großes Datenvolumen,keine Speicherung




„Kleines“Datenvolumen


Hohe Velocity Batch Layer und Speed Layer

AnalyticsAppliances

Hohe Skalier-barkeit, großes Datenvolumen




OptimierungAnalyse-szenario

VelocityLambda-

Architektur

Mapping auf geeignete technische Lösungen

Identifikation der Anforderungen und Trade-Offs der spezifischen Anwendung

Unternehmensarchitektur als Randbedingung Zu unterstützende Businessprozesse Informationsarchitektur (Informationshoheit,

Charakteristika der Daten wie Langlebigkeit, Stammdaten vs. aggregierte Daten, dispositive vs. operative Daten, Schutzcharakteristik)


© Zühlke 2013

Von den Anforderungen zur Architektur

9. Juli 2013

Identifikation und Herausarbeiten der wesentlichen Business-Fragestellungen

Volume

Velocity


Datenspeicherung

Datenrate


Analyseszenario


EM

AFlexibilität

Skalierbarkeit

KlassischesDWH / OLAP




Batch Layer

Map/Reduce

Großes Daten-volumen, hohe Skalierbarkeit




Großes Datenvolumen,keine Speicherung




„Kleines“Datenvolumen


Hohe Velocity Batch Layer und Speed Layer

AnalyticsAppliances

Hohe Skalier-barkeit, großes Datenvolumen




OptimierungAnalyse-szenario

VelocityLambda-

Architektur

Mapping auf geeignete technische Lösungen

Identifikation der Anforderungen und Trade-Offs der spezifischen Anwendung

Unternehmensarchitektur als Randbedingung Zu unterstützende Businessprozesse Informationsarchitektur (Informationshoheit,

Charakteristika der Daten wie Langlebigkeit, Stammdaten vs. aggregierte Daten, dispositive vs. operative Daten, Schutzcharakteristik)

Folie 35

Visualisierung

Automatisierung

Data Mining

Etablieren einer auf interdisziplinärer Zusammenarbeit beruhenden Vorgehensweise mit kurzen Feedbackzyklen

Team bestehend aus Fachexperten, Analyse- Spezialisten, Visualisierungs-Spezialisten und Entwicklern


© Zühlke 2013

Informationsquellen

Lambda-Architektur und Big-Data-Architekturen • Nathan Marz and James Warren: Big Data - Principles and best practices of scalable realtime data

systems, Manning 2012 • James Kinley: The Lambda Architecture: principles for architecting realtime Big Data systems,

http://jameskinley.tumblr.com/post/37398560534/the-lambda-architecture-principles-for-architecting • Nathan Marz: The Secrets of Building Realtime Big Data Systems,

http://de.slideshare.net/nathanmarz/the-secrets-of-building-realtime-big-data-systems • Chris Eaton, Dirk Deroos, Tom Deutsch, George Lapis, Paul Zikopoulos: Understanding Big Data:

Analytics for Enterprise Class Hadoop and Streaming Data, McGraw Hill 2012

Map / Reduce • Jeffrey Dean und Sanjay Ghemawat: MapReduce: Simplified Data Processing on Large Clusters,

Google Labs 2004, http://research.google.com/archive/mapreduce.html

Rechtliche Aspekte • Safe Harbor-Framework des US-Department of Commerce: http://export.gov/safeharbor/index.asp • Arnd Böken: Patriot Act und Cloud Computing: Zugriff auf Zuruf? iX 01/2012,

http://www.heise.de/ix/artikel/Zugriff-auf-Zuruf-1394430.html


http://jameskinley.tumblr.com/post/37398560534/the-lambda-architecture-principles-for-architecting

http://de.slideshare.net/nathanmarz/the-secrets-of-building-realtime-big-data-systems

http://research.google.com/archive/mapreduce.html

http://export.gov/safeharbor/index.asp

http://www.heise.de/ix/artikel/Zugriff-auf-Zuruf-1394430.html

© Zühlke 2013 9. Juli 2013 Big Data-Architekturen: Herausforderungen und Lösungen | Dr. Georg Molter Folie 37

Georg Molter

https://www.xing.com/profile/Georg_Molter2

http://blog.zuehlke.com/auf-der-suche-nach-der-idealen-big-data-architektur/

mailto:[email protected]

https://twitter.com/GeorgMolter

http://xing.com/profile/Georg_Molter2

Date post:	08-Dec-2014
Category:	Technology
Upload:	zuehlke
View:	2,991 times
Download:	0 times

BigData-Architekturen

Technology