erfahrungsbericht: umstieg von rdbms auf big data … ·  · 2015-10-19– apache spark für azure...

Wir unternehmen IT.

Erfahrungsbericht: Umstieg von RDBMS auf Big Data-Technologien

Karlsruhe, 30.09.2015

www.consol.de

$id thgreiner

Thorsten Greiner

Teamleiter Software Development ConSol* Software GmbH, Düsseldorf

http://de.linkedin.com/in/thgreiner

Physiker, Big Data, Hadoop, Gitarre, Röhrenverstärker

www.consol.de

Analyse-Backend

02.06.15

Workflow

Messen Speichern Auswerten Präsentieren

www.consol.de

Analyse-Backend

02.06.15

Workflow

Messen Speichern Auswerten Präsentieren

Messsysteme

• Sensoren z.B. für: – GPS – Netzwerk – UI-Events

• Online oder Offline • Datenvolumen: > 100 GB / Tag

Sensor 1

Sensor 2

Sensor 3

Zeit

Kennzahlen - Visualisierung

• ca. 100 verschiedene Kennzahlen mit entsprechender Visualisierung

RDBMS-basierte Lösung

Load BI

Batch

Probleme

• fehlende Skalierbarkeit

• Berechnung nur auf transformierten Daten

• hohe Lizenzkosten

• kein quelloffenes System Load BI

Batch

Warum Hadoop?

• Skalierbarkeit!

• ELT statt ETL – Berechnungen auf den Originaldaten

• geringere Lizenzkosten

• offenes SystemLoad BI

Batch

www.consol.de

Deployment

Rechenzentrum Cloud

VS

Ramp-Up / Kontrolle

Cluster in der Cloud

• Platform as a Service – Amazon Elastic MapReduce – Google App Engine MapReduce – Apache Spark für Azure HDInsight

• Infrastructure as a Service – Cluster mit API aufsetzen (Cloudera Manager/Apache Ambari) – Testen von verschiedenen Konfigurationen sehr einfach!

Infrastructure as a Service

• Testen mit verschiedenen Instanztypen, z.B. EC2:

• Kosten jeweils ca. 30 € / h

Cores Memory Disk Anzahlr3.4xlarge 16 122 GiB 320 GB 20r3.8xlarge 32 244 GiB 2 x 320 GB

SSD10

d2.4xlarge 16 122 GiB 12 x 2000 GB HD

10c3.8xlarge 32 60 GiB 2 x 320 GB

SSD16

Lokaler Cluster

• Standard-Hardware heisst nicht „billig“!

• Hardware-Sizing – CPUs (2x 4-8 core @ 2.x GHz) – RAM (64 - 512 GB) – HDD (12-24x 1 TB)

• Netzwerk – 2x1 GBit/s Standard, 10 GBit/s Optimum

Disks

CP

U

Speicher optimiert

BalanciertCPU optimiert

Geringer Energieverbrauch

weniger mehr

+

-

RechenzentrumCloud

www.consol.de

Architektur

02.06.15

Rohdaten

Compute Cluster

Node 1 Node 2

Node 3 Node 4

Kenn-zahlen

Kenn-zahlen

Lokaler Cluster

Node 1 Node 2

RechenzentrumCloud

www.consol.de

Architektur

02.06.15

Rohdaten Kenn-zahlen

Lokaler Cluster

Node 1 Node 2

Hive Impala

Data Ingestion - wie kommen Daten in den Cluster?

• Ziel: Rohdaten strukturiert und effizient ablegen – geeignet partitioniert (Messsystem, Datum) – Originaldaten in Containerformaten ablegen (Sequencefiles, AVRO) – Komprimierung

• Apache Flume

Events Container

Implementierung / Optionen

• Hadoop-Skriptsprachen – Pig – Hive

• Frameworks – MapReduce – Spark HDFS

YARN

MapReduce Spark

Hive Pig

MapReduce

• fester Ausführungsplan • Spill-to-Disk • robust aber langsam

• Sprache: Java

D A T A

Mapper Mapper Mapper Mapper

Reducer Reducer

R R

Spark

• flexibler Ausführungsplan • In-Memory-Verarbeitung • schnell aber fragil

• Sprachen: – Scala – Java – Python

D A T A

map filter keyBy keyBy

join join

R

aggregatejoin

Kennzahl-Berechnung mit Spark - Erkenntnisse

• Skalierung – fast proportional mit Anzahl der Knoten – Overhead bei Input / Output

• Partitionierung – zu viele Partitionen: sehr kleine / kurze Tasks – zu große Partitionen: Stabilitätsprobleme

• Kaum Performance-Verbesserung durch Caching – Speicher in Spill-to-Memory investieren

Herausforderungen mit Spark

• Ausführungsplan - Anwender hat keine direkte Kontrolle - kaum Werkzeuge für Debugging / Troubleshooting

• Programmiermodell - funktionale Programmierung ⇔ stateful vs. stateless

• Stabilität - Container werden terminiert, wenn Memory-Limits überschritten

Spark-Tuning

• Ausführungsplan verstehen – Spark UI – RDD.toDebugString

• Memory-Footprint verringern – primitive Typen statt Java-Objekte

• Custom Partitioner nutzen – Shuffle über Netzwerk vermeiden

• Custom Serializer für Kryo nutzen

Warum MapReduce?

• Statemachines – mit MapReduce und Secondary Sort

Sensor 1

t

Sensor 2

Sensor 3

Warum MapReduce?

• Statemachines – mit MapReduce und Secondary Sort

• Stabilität – Parameter-Tuning bei Spark

Sensor 1

t

Sensor 2

Sensor 3

Verarbeitungs-Pipeline

Sensordaten Container MapReduce zeitabh. Daten

Kennzahlen

Impala

Ausblick

Sensordaten Container MapReduce zeitabh. Daten

Kennzahlen

DashboardImpala

Big-Data-Projekte = Software-Entwicklung!

• Tools – Versionkontrolle – Continuous Integration – DevOps

• Vorgehensmodell – Anforderungsmanagement – Scrum, Kanban

Big-Data-Projekte = Software-Entwicklung!

• Umgebungen – Testsystem lokal (VM) – Testcluster – Integrationscluster – Produktionscluster

• Testdaten – Unit-Tests / lokale Tests – reale Daten

Hadoop - Herausforderung im Betrieb

• Sicherheit – Authentifizierung: Kerberos – RBAC: Ranger, Sentry – Perimeter Security: Knox

• Backup – Replication ersetzt kein Backup – Proprietäre Lösungen – HDFS Snapshots

Fazit

• Hadoop-Cluster sind skalierbare Alternative zu RDBMS • Lokaler Cluster vs. Cloud-Lösung

– Flexibilität – Kosten – Datenschutz / -sicherheit

• MapReduce vs. Spark – Spark ist flexibler und schneller – noch Unzulänglichkeiten bei Spark – MapReduce in bestimmten Anwendungsfällen weiterhin sinnvoll

www.consol.de

Danke!

02.06.15

www.consol.de

ConSol* Software GmbHFranziskanerstraße 38

D-81669 München

Tel: +49-89-45841-100Fax: +49-89-45841-111

info@consol.dewww.consol.de

02.06.15

Attributions

- Cloud Computing Icon: Author: 百楽兎, Creative Commons Attribution-Share Alike 3.0 Unported license

- Hadoop Elephant Icon: Author: Intel Free Press, Creative Commons Attribution-Share Alike 2.0 Generic