Veröffentlicht am Schreiben Sie einen Kommentar

Big Data als Programmierparadigma

Big Data als Programmierparadigma

Wir kennen Paradigmenwechsel: Der Übergang von prozeduraler Programmierung zu objektorientierter Programmierung gilt als solcher.

In der objektorientierten Programmierung gilt, was die Prozedurale ausmacht und es kommen weitere Eigenschaften dazu.

Ähnlich verhält es sich mit der funktionalen Programmierung – auch ein Paradigmenwechsel: Das Objektorientierte gilt noch und es kommen weitere Eigenschaften dazu.

Und wie passt da “Big Data” ins Bild?

“Big Data” heißt ja nichts anderes als “große Daten”. Per se ist “Big Data” ja kein definierender Begriff, nicht einmal ein beschreibender Begriff.

Definitionen gibt es viele – Wikipedia hilft wie folgt:

 “Der aus dem englischen Sprachraum stammende Begriff Big Data (von englisch big ‚groß‘ und data ‚Daten‘, deutsch auch Massendaten) bezeichnet Datenmengen, welche beispielsweise zu groß, zu komplex, zu schnelllebig oder zu schwach strukturiert sind, um sie mit manuellen und herkömmlichen Methoden der Datenverarbeitung auszuwerten.”

Quelle: Wikipedia

Und gleich stellt sich die Anschlussfrage: Was sind denn bitte schön “herkömmliche Methoden der Datenverarbeitung”?

Und was ist schon “groß” und “zu groß” – in welcher Hinsicht “groß” und zu “groß”.

Big Data – das sind die 3V

Hier hilft dieser Definitionsversuch:  “Big Data – das sind die 3V”. Na ja, auch nicht hilfreich. Was sind 3V und warum sind 3V denn große Daten – also “Big Data”? Oder waren es nicht 4V? Auch von 6V war schon die Rede…

Nehmen wir die 3V – sie können im Gartner IT Glossary nachgelesen werden:

Big data is high-volume, high-velocity and/or high-variety information assets that demand cost-effective, innovative forms of information processing that enable enhanced insight, decision making, and process automation. “

Quelle: Gartner IT Glossary

Big Data sind also Technologien, mit denen Daten, die in großem Volumen, mit hoher Geschwindigkeit und großer Vielfalt verarbeitet werden sollen und dazu braucht es innovative Formen der Informationsverarbeitung.

Hmmmm – was ist denn schon “innovativ”?

Und nein – ich werde jetzt keine eigene Definition beisteuern …

Bleiben wir beim Paradigmenwechsel:

Wer erinnert sich an die Zeit in den späten 90er, als objektorientierte Programmierung aufkam?

Alle waren an die gute alte prozedurale Programmierung gewöhnt, und jetzt kam da etwas Neumodisches, das besser sein sollte. Man versprach sich, weniger Codierarbeit, weil der Code ja optimal wiederverwendet werden kann und das dank geschicktem Design von Klassen und Objekten und Methoden. (In Klammern: Hat sich das denn auch bewahrheitet?)

Manch einem routinierten prozeduralen Programmierer fiel die Umstellung schwer – einige sind gar auf der Strecke geblieben.

Nehmen wir den nächsten Schritt, denjenigen zum Paradigma der funktionalen Programmierung.

Wer kann die Hand heben und guten Gewissens von sich behaupten, die funktionale Programmierung voll und ganz begriffen zu haben und sie tagtäglich erfolgreich einzusetzen?

Meine Behauptung: manch eine Hand wird unten bleiben. Viele Programme können bestens ohne funktionale Elemente geschrieben werden.

Manche halt nicht – und das sind gerade diejenigen, die diese mythischen big-data-riesigen Datenmengen auswerten.

Noch eine Umfrage:

Wer kann die Hand heben und mit guten Gewissen von sich behaupten, wirklich tagtäglich mit big-data-mäßigen Mengen arbeiten zu dürfen?

Meine Beobachtung: manch eine Hand bleibt unten. Gute alte Objektorientierung reicht heute in vielen Fällen aus.

Sind da noch die Datenbanken

Alle Informatiker werden relational gedrillt und können mehr oder weniger gut mit relationalen Datenbanken umgehen. Ist doch klar, die gab’s ja schon immer…

Oder wer erinnert sich an die Zeit anfangs 90er, als einige Pioniere den großen und mutigen Schritt wagten, und relationale Datenbanken für ihre Projekte einsetzten?

Heute sind sie Gang und Gäbe. Und mit ihnen das deklarative Programmierparadigma der standardisierten Abfragesprache SQL. Diese gehört zum Skill-Set eines jeden Informatikers – hoffentlich.

Und jetzt gibt es diese neumodischen NoSQL-Datenbanken

Um NoSQL-Datenbanken ranken sich noch immer einige Mythen:

“Sie sind BASE und nicht ACID – so wie wir es von relationalen Datenbanken gewohnt sind. Auf NoSQL kann man sich ja nicht verlassen.”

“NoSQL ist etwas für Softies – für alle, die es mit der Vollständigkeit der Daten nicht so genau nehmen.”

Das habe ich alles schon gehört. Von scheinbar gestandenen IT Experten. Und auch: “Diese NoSQL-Datenbanken verlieren also Daten,” sagen sie, “sind keine rechten Datenbanken und überhaupt …”

Lassen wir die Ironie und schauen wir also seriös hin: Was ist überhaupt eine “NoSQL-Datenbank”?

Wohl eine Datenbank, man nicht mit SQL abfragt? Immerhin sagt die Bezeichnung doch so etwas aus. Wikipedia hilft uns schon wieder

NoSQL […] bezeichnet Datenbanken, die einen nicht-relationalen Ansatz verfolgen und damit mit der langen Geschichte relationaler Datenbanken brechen. Diese Datenspeicher benötigen keine festgelegten Tabellenschemata und versuchen Joins zu vermeiden. Sie skalieren dabei horizontal. “

Quelle: Wikipedia

Also “not only” – als Abkürzung für “NO”.

Aber: “not only” bedeutet doch, dass es auch NoSQL-Datenbanken gibt, die SQL können, oder? Und dann “versuchen” sie erst noch, Joins zu vermeiden.

Eben: diese “Definition” hilft ja nicht wirklich weiter, oder?

Es ist so ähnlich wie bei “Big Data” auch “NoSQL” ist ein Begriff, der eigentlich nichts aussagt, aber gerne verwendet wird.

Die Definition in Wikipedia ist dennoch hilfreich: NoSQL-Datenbanken sind nicht-relationale Datenbanken. 

Wir können dort also Daten speichern, ohne immer gleich vorher die 5. Normalform herzustellen.

Das ist doch eine gute Neuigkeit: Es erleichtert das Leben in vielen Fällen, in denen die Normalisierung eigentlich überflüssig ist. Beispielsweise wenn Daten als Einheit gespeichert werden sollen, wie der Inhalt eines Warenkorbes in einer E-Commerce-Anwendung. Und übrigens: NoSQL-Datenbanken verlieren nicht mehr und nicht weniger Daten, als relationale Datenbanken.

Was hat es jetzt mit BASE vs. ACID auf sich? Auch da hilft die Definition aus Wikipedia, wenn auch erst auf den zweiten Blick:

Und sie skalieren horizontal

NoSQL-Datenbanken skalieren horizontal! 

Nochmals: NoSQL-Datenbanken skalieren horizontal!

Sie skalieren, können also wachsen. Horizontal und nicht vertikal.

Vertikal: Wir brauchen immer größere Festplatten, bis der RAID-Controller platzt (und das ist ja schon eine beachtliche Menge).

Horizontal: Wir brauchen immer mehr Rechner und noch mehr Rechner und noch mehr Rechner.

Und auf diese vielen Rechner verteilen wir die Daten und noch mehr Daten – bis Big Data eben – diese diffusen Mengen im TB, PB-Bereich.

“Werden denn da Datenanalysen je fertig?” Diese Frage ist mehr als berechtigt. Immerhin ist es so in der “herkömmlichen” schon-lange-nicht-mehr-innovativen relationalen und objektorientierten Welt.

Horizontal skalieren – funktional programmieren – Big Data

Und da fängt das Innovative an und auch das Funktionale:

Ja, Berechnungen werden fertig auch auf diffus großen Datenmengen. 

Weil: Die Berechnungen werden verteilt auf allen Rechnern gleichzeitig ausgeführt, da wo die Daten liegen.

Das ist so ähnlich wie bei der Weinlese: Du kannst den Weinberg allein ernten (“herkömmlich”) oder du holst eine Gruppe von Lesehelfern, teilst die Arbeit geschickt auf, koordinierst die Leute und lässt sie alle gleichzeitig Trauben pflücken. Das geht schneller. Die Arbeit wird also verteilt – so wie Big Data Berechnungen, verteilt werden.

Und so wird die Verarbeitung auch sehr großer Datenmengen innert nützlicher Frist beendet.

Und in verteilten Systemen ist das Realisieren der ACID-Eigenschaft sehr aufwändig und hat seinen Preis. Der Hintergrund ist in Brewers’s Conjecture zu finden.

Big Data Rechnen ist also “verteiltes Rechnen”.

Adele Goldberg entwickelte in den 1970er Jahren in den Xerox-Labs mit Smalltalk eine objektorientierte Programmiersprache.

Und erst in den 1990er Jahren wurde die Objektorientierung langsam allgemein bekannt.

Schon in den 1960er-Jahren erdachte Edgar F. Codd bei IBM die relationalen Datenbanken.

Und erst Anfangs 1990er galt es in der Industrie als Pionierleistung, relationale Datenbanken produktiv einzusetzen.

Und so verhält es sich mit dem verteilten Rechnen.  In den Labors und der akademischen Welt 1970er sind die Theorien längst bekannt. Leslie Lamport erhielt dafür den Turing Award.

In den 2000er-Jahren wären die Internet-Riesen ohne verteiltes Rechnen längst in den Datenmengen untergegangen.

Und erst jetzt – 20 Jahre später – verbreitet sich diese Art der Berechnung unter dem Begriff Big Data.

Begründer eines Programmierparadigma: Adele Goldberg - Edgar F. Codd - Leslie Lamport
Adele Goldberg – Edgar F. Codd – Leslie Lamport (v.l.n.r.)

Der Lockruf der simplen APIs

Big-Data-APIs gaukeln einfache Handhabung vor, Herstellerfirmen umwerben uns mit verlockenden Cloud-Angeboten und versprechen, uns alle Schwierigkeiten von den Schultern zu nehmen.

“Big-Data-Technologien sind ja so einfach in der Handhabung”, sagen sie.

Datenanalysen mit SQL auf gigantischen Datenmengen werden sogar in Echtzeit (also Real Time) möglich und jeder Informatiker spricht doch SQL – was will man mehr?

Etwas mehr Know-How und deutlich weniger Kosten

Ein Blick in die Gegenwart: Wie sieht es aus, mit all den “klassischen” SQL-Queries gegen herkömmliche relationale Datenbanken, deren Ausführung einfach nicht enden will?

Wie viele Codierer sind heute unterwegs, die nicht wissen, was eine Transaktion ist, die nicht wissen, was ACID bedeutet und welche Vorkehrungen sie treffen müssen, damit die Datenbank nicht blockiert?

Zu viele – behaupte ich.

“Aber das macht ja nichts – wir nehmen einfach eine NoSQL-Datenbank und dann funktioniert gleich alles besser!” Das sagen sie dann und krempeln die Ärmel hoch, ziehen sich noch ein Gratis-Tutorial ein und bauen alles um.

Dabei hätte vielleicht nur die relationale Transaktion besser gestaltet werden müssen … etwas mehr Know-How und deutlich weniger Kosten.

Der Microservice wird’s richten

“Im Zweifelsfall machen wir einen Microservice draus. Da entkoppelt sich alles und skaliert erst noch”, sagen sie dann.

Und was muss man tun, damit die Microservices wirklich skalieren? Diese Frage stellte ich letzthin in einem ganz konkreten Fall. Die Antwort:

“Brauche ich nicht zu wissen – sind zwei Maus-Klicks im Spring-Boot-Framework.”

Ich prophezeie: Da kommen gruselig hohe Kosten auf den Besitzer dieses Microservices zu, wenn es darum gehen wird, wirklich zu skalieren.

Auch hier: Etwas mehr Know-How und deutlich weniger Kosten.

Und so verhält es sich auch mit den innovativen Big-Data-Technologien: Verteiltes Rechnen ist hochkomplexes Rechnen. Die scheinbar einfachen APIs kommen mit einer Vielzahl an Parametern mit Default-Werten, die von den Herstellern nach bestem Wissen und Gewissen gesetzt werden.

So wie das Autocommit in relationalen Datenbanken. Funktioniert meistens gut, kann aber verheerende Folgen haben, wenn es falsch angewandt wird.

Mit Know-How zum neuen Paradigma

Etwas mehr Know-How bedeutet unter dem Strich deutlich weniger Kosten – gerade wenn es darum geht, dem Lockruf in die innovativen Big-Data-Technologien zu folgen und sich auf das neue Paradigma des verteilten Rechnens mit Big Data einzulassen (wenn’s denn überhaupt ein neues Paradigma ist).

    • Seit mehr als 20 Jahren unterrichte ich Data Management und Data Engineering an mehreren Schweizer Fachhochschulen.
    • Seit etwa zehn Jahren sind Big-Data-Technologien dazu gekommen. Ein faszinierender Themenkreis, der sich an wachsendem Interesse erfreut und den ich auf diesem Weg einem breiteren Fachpublikum erschließen möchte.
    • Ursula Deriu
    • Klick hier, um mehr über mich zu erfahren
Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.