HPI – BD19/20 – Benchmarking und Measurement

Als Teil der Lecture Series des HPI hier Teil 4 der Big Data-Vorlesung mit „Benchmarking und Measurement„.

Zuletzt – Teil 4: HPI BD19/20 – Big Data Stack

Warum überhaupt messen?

  • Verfügbarkeit von Webseiten gewährleisten
  • Interaktive Datenanalyse skalierbar machen
  • Realtime-Analytics

 

Überlegungen

  •  Systemperformance muss regelmäßig geprüft werden.
  • Niemals nur einer Messmethode glauben
  • Back-of-the-envelope calculations -> Überschlagsrechnung
    • Grobe erste Berechnung, ob es passt oder nicht
    • Bsp. Berechnung der Performance der Einzelkomponenten (L1/L2-Cache, Hauptspeicher, Festplatte, …)

Im weiteren zeigt die Vorlesung viele Möglichkeiten, statistisch mit Messwerten zu arbeiten um verschiedene Aspekte sinnvoll zu testen und validieren zu können.

 

SAP Analytix-Fazit

Nun, im BI-Umfeld wie überall im Bereich Analytics spielt Performance eine wichtige Rolle und umfasst oft viele Stufen und Optionen.

Im klassischen SAP BW on Any DB dürfte dies z. B. jeder BI-Administrator/-Berater kennen. Lesen auf ein flaches Schema wird tendenziell nicht empfohlen, außer man benötigt wirklich die Detailebene und liest jeden einzelnen Datensatz. Für alles was aggregierte Daten berechnet, macht das Star Schema (InfoCube) mehr Sinn. Darauf aufbauend gibt es klassisch die Aggregate, welche nochmals über mehrere Merkmale verdichtet, eine Teilmenge der Daten auf der Datenbank bereitstellt. In der Pre-HANA Ära gab es dann auch noch den BWA, der die Daten im deutlich schnelleren Hauptspeicher vorgehalten hat. Im optimalen Fall wurden die Daten auch schonmal geladen und liegen im noch schnelleren Cache. All dies kann man designen und bereitstellen um Performance hoch zu halten.

HANA bringt das Thema natürlich nochmal auf ein neues Level. Die Daten sind permanent in Memory, spaltenbasiert quasi schon aggregiert und liefern mit optimierter Hardware auch die entsprechende Performance.

Die Cloud kann und wird evtl. zukünftig hier noch flexiblere Optionen ermöglichen, da hier Ressourcen flexibel zugeschaltet oder wieder zurückgefahren werden können.

Natürlich weiß auch jeder, der sich mit Performancemessungen beschäftigt hat, dass das beschriebene allein evt. noch nicht immer auch beim Anwender ankommt. Die richtige Systemparametrisierung, das Netzwerk und das Frontend selbst bzw. der Rechner auf dem dieses läuft, geben ihr übriges dazu.

In einem SAP BW-System haben Statistiken auch einen lange Historie und können ad-hoc oder im Langzeitvergleich flexibel ausgewertet werden.

 

Nächste Lecture: Benchmarks

 

HPI – BD19/20 – Big Data Stack

Als Teil der Lecture Series des HPI hier Teil 4 der Big Data-Vorlesung mit „Big Data Stack„.

Zuletzt – Teil 3: HPI BD19/20 – RDBMS Internals

Umfrage vorab – kennt ihr schon:

  • Hybrid Hash Join
  • Log Structured Merge Tree (LSM-Tree)
  • Programmiersprachen (Java, Python, C++, Other)
  • Biggest Programm (LoC)
  • Vorlesung Database Implementation
  • Vorlesung Distributed Data Management

Big Data – Where Traditional Databases are Unsuitable

 

Der Big Data Stack

  • Application/Query Language/Analytics/Visualization
  • Data Processing
  • Scheduling (Yarn, Kubernetes, Mesos)
  • File System
  • Virtualization (Containers, VMs)
  • Storage / Compute
  • Network

 

Big Data Systems

  • Storage: Hadoop, Ceph
  • Analytical Processing: Spark, TEZ, Hive
  • Operational: HBase, Cassandra
  • Stream Processing: Storm, Flink, Spark Streaming, Kafka
  • Graph Processing: Giraph, GraphX, Neo4J
  • Machine Learning: SystemML, TensorFlow, Mahout

 

Paper zum Google File System (2003) -> HDFS

Paper zu Map Reduce (Google, 2004)

Paper zu BigTable (Google, 2006) -> HBase

Paper zu Chubby (Google, 2006) -> Zookeeper

Paper zu Hadoop Distributed Filesystem (Yahoo, 2010)

Paper zu Pregel (Google, 2010) -> Giraph

Paper zu Spanner (Google, 2012)

Paper zu F1 (Google, 2012)

Paper zu Borg (Google, 2015)  -> YARN

Paper zu Porcella (Google, 2019)

 

SAP Analytix-Fazit

Die Schnittstellen hier ist vor allem SAP Vora, welches mittlerweile Bestandteil von SAP Data Hub/Intelligence ist. Komponenten wie Ceph und Docker spielen auch hier eine Rolle. Grundsätzlich bringt auch HANA Smart Data Access ein Hadoop-Adapter mit.

Eine Zeit lang waren das die Komponenten, um im Kontext BW/4HANA das Big Data Warehouse zu propagieren.

Schaut man sich den Big Data Stack an, so sind die Layer natürlich vergleichbar zu einem Data Warehouse. Nur handhabt Big Data natürlich deutlich andere Aspekte (3 Vs) und ist vor allem typischerweise ein verteiltes System um diese Aspekte zu handhaben.

 

Nächste Lecture: Benchmarking und Measurement

HPI – BD19/20 – RDBMS Internals

Als Teil der Lecture Series des HPI hier Teil 3 der Big Data-Vorlesung mit „RDBMS Internals„.

Zuletzt – Teil 2: HPI – BD19/20 – Database Systems Recab

Hier geht es nochmal darum, wie Datenbanken im intern funktionieren.

Memory Hierarchy – klassisch gibt es verschiedene Abstufungen von schnell, teuer und klein (Register, Cache – in Kilobyte) zu langsam, günstig und damit typischerweise umfangreich (Bandlaufwerke – in Terabyte). Hauptspeicher und Festplatte liegt hier dazwischen. Flash ist ein modernerer Baustein dazwischen.

Von Hauptspeicher zu Festplatte gibt es ein Access Time Gap.

Das Potential von Festplatten ist ausgereizt durch physikalische Grenzen.

Datenbank-Layerarchitektur – Man kann die folgenden 5 Layer unterscheiden:

  • Datenmodell – SQL, Tabellen
  • Logischer Zugriff – Wie wird der Zugriff gehandhabt
  • Memory – Indexstrukturen usw.
  • Pufferverwaltung – Optimierung von Zugriffen
  • Betriebssystem – Zugriff auf Festplatte, typischerweise für kleine Dateien optimiert -> Ansatz für Datenmanagement!

-> Nicht jede Datenbank hat zwingend alle Layer!

Access Methods – von der Festplatte wird nicht der einzelne Datensatz, sondern immer der gesamte Block gelesen. Indizes erleichtern das Auffinden. Ein wichtiger Index ist der B- und B*-Baum Index. Diese Indizes sind sehr flach und benötigen dadurch wenig Zugriffe. Für schnelle, zufällige Zugriffe eignet sich bspw. Hashing besser. Caching ermöglicht über verschiedene Strategien den Zugriff auf die Festplatte zu umgehen.

Query Processing – Eine Query (SQL) generiert einen Query Execution Plan, welcher die Verarbeitung der Daten bestimmt. Um den optimalen Plan zu finden gibt es entweder einen Rule-Based Optimizer oder Cost-Based Optimizer.

SAP Analytix-Fazit

Nun, SAP HANA zeigt es, schnelle Zugriffe durch die Haltung der Daten im Arbeitsspeicher sind heute State-of-the-Art. Große Caches helfen dabei natürlich auch, neben weiteren Techniken, Abfragen zu beschleunigen. So kann der Flaschenhals bzgl. des Zugriffs auf eine Festplatte umgangen werden.

Auch von der ABAP-Seite ist die Diskussion bekannt, wie interne Tabellen gehandhabt werden sollen. Hab ich eine sortierte Tabelle und frage diese dann per BINARY SEARCH ab. Oder definiere ich gleich eine Hash-Tabelle, welche für jedes lesen eine konstante, i. d. R. kurze Zeit benötigt.

Der BW-Berater kennt sich mit B-Bäumen aus. Wird dieser doch, soweit dies die Datenbank überhaupt unterstützt durch das Flag „Hohe Kardinalität“ in der Definition der Dimension eines InfoCubes generiert. Somit können schnelle selektive Zugriffe auf große Dimensionstabellen ermöglicht werden. Dem BW-Admin wird auch die Funkion, eine Statistik für die Daten aufzubauen gut gekannt sein. Damit kann der Cost-Based Optimizer einen optimalen Ausführungsplan ermitteln.

Alles in allem damit auch für den SAP-Kontext gute Grundlagen, dass Verständnis zu vertiefen.

 

Nächste Lecture: Big Data Stack

 

 

HPI – BD19/20 – Database Systems Recab

Als Teil der Lecture Series des HPI hier Teil 2 der Big Data-Vorlesung mit „Database System Recab„.

Teil 1 – Introduction

Einführend in dieser Vorlesung eine Zusammenfassung zu den wichtigesten Begriffen der Datenbankvorlesungen.

  • RDBM – Relation DataBase System
  • Client-Server
  • Datenrepresentation
    • Logische Ebene
    • Konzeptionelle Ebene
    • Physische Ebene
  • Relationales Datenmodell
  • ER-Modellierung
  • Normalformen
  • Relationale Algebra
  • SQL
  • Datenintegrität
  • ACID-Prinzip
  • Konkurrierende Zugriffe

 

SAP Analytix-Fazit

Sicherlich gut, auch wenn es dazu schon Vorlesungen gab, nochmal wichtige Grundlagen zu wiederholen. Sicherlich auch für Entwickler und HANA-Modellierer ein Thema. Im klassischen BI-Umfeld kann es ja zusätzlich auch immer noch vorkommen, dass diverse Datenbanken als Quelle integriert werden sollen.

 

Nächste Lecture: RDBMS Internals

HPI – BD19/20 – Introduction

Als Teil der Lecture Series des HPI hier Teil 1 der Big Data-Vorlesung mit „Introduction„.

Grundlegend eine Einführung in Big Data. Woher kommen die Daten (Messages, Tweets, Social Networks, Blogs, Click Stream, Logs, …)

-> Der Wert der Daten nimmt über die Zeit ab (=> niemand benötigt Click Stream-Informationen die 10 Jahre alt sind.)

Es gibt viele Definitionen von Big Data. Generell kann gesagt werden – wenn du die Daten mit klassischen Ansätzen nicht mehr verarbeiten kannst, ist es Big Data.

Big Data wird oft über die 3 Vs definiert: Volume / Velocity / Variety

Big Data hat auch Risiken:

  • Fehler: Falsche Korrelationen, Bias, Simpsons Paradox
  • Manipulation: Fit data to result, biased training, manipulative Visualisierungen
  • Misuse: Diskriminierung, Verletzung von Datenschutz, Spionage
  • Data Monopoly

Der Nutzen von Big Data ist u. a.:

  • Wirtschaft: Predictive Maintenance, Betrugserkennung, Kapazitätsplanung, Prozessoptimierung
  • Automotive: Verkehrsoptimierung, Selbstfahrende Autos, verbesserte Sicherheit
  • Health: Früherkennung, personalisierte Medizin, medizinische Assistenten, Kostenreduktion
  • Science: Evidenzbasierte Forschung, schnelle Datenanalyse und -wiederverwendung

=> Data Science ist der Prozess um aus Big Data nutzen zu ziehen.

Data Science vs. Data Engineering: DS organisiert und analysiert Daten um Probleme zu lösen. DE erstellt die Architektur, betreibt Datenpipelines und bring DS in einen produktiven Kontext.

Ethik: „With great power comes great responsibility.“

 

SAP Analytix-Fazit

Gute Einführung in das Thema. Hier ist sicherlich noch nicht viel zu sagen. SAP treibt das Thema toolmäßig mit SAP Data Hub bzw. SAP Data Intelligence und versucht damit Data Science und Data Engineering zu verbinden.

SAP hat die letzten Jahre viele Initiativen entwickelt, um Big Data zu bewältigen. SAP HANA, Vora, Big Data Service und nicht zuletzt den demnächst startenden HANA Cloud Service, welcher direkt eine Data Lake-Funktionalität mitbringt.

Bleiben wir gespannt, wie es anläuft.

Nächste Lecture: Database Systems Recab