Designing Data-Intensive Applications - Martin Kleppmann
04.07.2017 Thomas Mohme
Designing Data-Intensive Applications
Das Buch
Autor: Martin Kleppmann
Verlag: O'Reilly Media
Veröffentlichung: March 2017
Taschenbuch, 614 Seiten
Print ISBN:978-1-4493-7332-0 | ISBN 10:1-4493-7332-1
Ebook ISBN:978-1-4919-0308-7 | ISBN 10:1-4919-0308-2
Der Autor
Martin Kleppmann arbeitet als Forscher im Bereich von verteilten Systemen an der Universität von Cambridge.
Zuvor hat er mehrere Unternehmen gegründet, die u.a. von LinkedIn aufgekauft wurden.
Seine Blog findet sich unter martin.kleppmann.com.
Worum geht es?
Was sind "Data-Intensive Applications"? Der Autor meint damit Systeme, bei denen nicht die CPU-Leistung der limitierende Faktor ist, sondern die Menge an zu verarbeitenden Daten, die Komplexität der Daten und die Änderungsrate.
Der Untertitel bring anschließend auf den Punkt, welchen Inhalt man von dem Buch erwarten kann:
The Big Ideas Behind Reliable, Scalable, and Maintainable Systems.
Das Buch bietet eine systematische Vorstellung all der Tools und Techniken, die uns zur Verfügung stehen, um die Datenflut zu bändigen und die Business-Probleme zu lösen.
Der Autor geht zwar auch am Rande auf einige Produkte ein, aber diese dienen nur als "real existierende Beispiele" für die beschriebenen fundamentalen, zeitlosen Ideen und Konzepte.
Das Buch verfolgt das Ziel, dem Leser Wissen zu vermitteln, um selber informierte Design-Entscheidungen treffen zu können.
Hierzu werden grundsätzliche Eigenschaften, Vor- und Nachteile sowie Grenzen unterschiedlicher Verfahren vorgestellt.
Die Spanne reicht hier von grundsätzlichem wie Daten-Modellen (Relational, Dokumente, Graphen) und zugehörigen Abfrage-Sprachen über verteilte Systeme mit ihren speziellen Problemen bis hin zu den unterschiedlichen Klassen von Verfahren zur Verarbeitung der Datenmengen.
Aufbau
Der Aufbau des Buches ist didaktisch gelungen. In den einzelnen Bereichen wird zunächst ein Überblick gegeben, bevor tiefer in die Materie eingestiegen wird. Man kann das Buch durchaus von vorne bis hinten durchlesen, muss es aber nicht.
Die Beschreibungen / Analysen der Probleme gehen teilweise sehr tief ins Detail ("Tracking happens-before relationships") und dürften so manchen Leser punktuell abhängen.
Aber man kann man einzelne Unterabschnitte auch überspringen, ohne inhaltlich den Anschluss zu verlieren.
Am Ende eines jeden Kapitels finden sich eine Zusammenfassung, sowie die Fußnoten mit dutzenden Referenzen auf andere interessante Quellen. Will man auch nur einen kleinen Teil dieser Quellen näher betrachten, dann vervielfacht sich die Lesezeit nochmals.
Foundations of Data Systems
Es beginnt mit einem Überblick über die Anforderungen. Im Gegensatz zu anderen Fachbüchern geht es hier aber bereits schnell in die Details und es werden interessante Fragen aufgeworfen.
Weiter geht es mit Datemodellen, von denen der Autor meint:
Data models are perhaps the most important part of developing software, because they have such a profound effect: not only on how the software is written, but also how we think about the problem that we are solving.
Das Buch bietet eine gute Gegenüberstellung der Eigenschaften historischer (Hierarchische- und Netzwerkdatenbanken) und aktueller Modellierungsansätze (Relational, Dokument, Graphen).
Auch der Hinweis auf die Konvergenz dieser Ansätze fehlt nicht: RDBMS unterstützen Json und XML Dokumente, Dokument-DBs unterstützen Joins.
Weil in echten Projekten vielfach das Wissen um die Eigenschaften der verschiedenen Modellierungsansätze (und der entsprechenden Implementierungen in Form konkreter DBMS Produkte) fehlt, kommt es häufig zu Fehlentscheidungen, die vermeidbare "accidental complexity" mit all ihren Problemen in die Software bringt.
In kleinen Systemen mag dies noch hinnehmbar sein. In großen Systemen (insbesondere im Hinblick auf die zu bewältigenden Datenmengen) bedeutet ein solches Vorgehen aber schnell das Scheitern des Projektes.
Das in dem Buch vermittelte Wissen kann dabei helfen, solche Fehler zu vermeiden.
Weiter geht es mit einer Vorstellung verschiedener Storage- und Retrieval-Techniken, die Datenbanken intern benutzen.
Zwar kommt ein "normaler" Anwendungsentwickler oder Architekt mit diesen Verfahren wohl nie direkt in Kontakt, aber dieses Wissen ist sehr nützlich bei der Auswahl einer geeigneten Datenbank für das erwartete Anforderungsprofil.
Ein weiterer grundlegender Bereich ist die Frage, wie Informationen kodiert werden. Dies gilt besonders für die Übergabe von Informationen von einem Subsystem an ein anderes, aber auch für die Kodierung innerhalb eines Systems im zeitlichen Verlauf (schema evolution, backward- und forward-compatibility, rolling upgrade).
Es werden Probleme angesprochen, die nicht auf den ersten Blick offensichtlich sind.
Auch hier werden die Vor- und Nachteile verschiedener Ansätze mit Beispielen aktueller Produkte einander gegenübergestellt.
Distributed Data
Der erste Abschnitt konzentrierte sich noch auf die Dinge, die schon bei einem verhältnismäßig einfachen System mit einem Computer zu beachten sind.
In zweiten Abschnitt wird das Ganze um die Probleme erweitert, die hinzukommen, wenn mehrere Computer an der Speicherung und Verarbeitung der Daten beteiligt sind.
Verschiedene Replizierungs-Ansätze unterschiedlicher Produkte werden diskutiert.
Da die meisten Produkte nur ein Replizierungs-Verfahren unterstützen, lohnt es sich diese zu kennen, um bei einer Produkt-Auswahl dessen Grenzen beurteilen zu können.
Insbesondere der Abschnitt "Problems with Replication Lag" sei all denen ans Herz gelegt, die den Versprechen der (insbesondere NoSQL-) DB-Hersteller glauben.
Ein reality-check bei aphyr.com schadet ebenfalls nicht... (Der Vortrag von Kyle Kingsbury bei den ScalaDays 2017 darüber, was man wirklich von verteilten Datenbanken erwarten kann, wird so manchen zu staunen bringen.)
Weiter geht es mit den Vor- und Nachteilen von Partitionierung.
Bei vielen Lesern dürfte der Begriff "Transaktion" mit "ACID", wenn es hoch kommt noch mit "BASE", assoziiert sein. Martin Kleppman zeigt auf, dass hinter dem so exakt geglaubten Begriff eine Grauzone lauert. Kaum einem Verwender der dominierenden relationen Datenbanken dürfte bewusst sein, dass er mit seiner Wahl des Transaction Isolation Levels aus seinem vermeintlich vollständig konsistenten System sehr schnell ein "eventual consistent" System macht.
In einem eigenen Kapitel wird auf die speziellen Probleme und Fehler-Modi eingegangen, die spezifisch für verteilte Systeme sind.
Der Abschnitt wird schließlich mit einem theoretischen Kapitel ("Consistency and Consensus") abgeschlossen.
Derived Data
Im ersten und zweiten Teil geht es vor allem um die Speicherung und Verarbeitung von Daten in einem (möglicherweiser verteilten) System.
Häufig stehen solche Systeme jedoch nicht allein, sondern interagieren mit anderen Systemen, d.h. es existiert ein "System of Record" und weitere Systeme, die mit abgeleiteten Daten aus diesem führenden System arbeiten.
Im dritten Teil geht es dementsprechend um Strategien, diese Zusammenarbeit zu organisieren. Ausgehend von einer simplen Batch-Verarbeitung wird zunächst die Klasse der Map-Reduce-Verfahren mit den ihnen eigenen Fallstricken besprochen.
Anschließend werden die Stream Processing Verfahren ausführlich unter die Lupe genommen.
Ein sehr interessannter Aspekt hierbei ist die Nutzung von Streams, um mehrere Systeme synchron zu halten.
Die Betrachtung reicht von Application-Level Verfahren mit Domain-Events (CQRS, Event Sourcing) bis hinunter zu Tools zur Nutzung des Write-Ahead-Logs von Datanbanken für eigene Zwecke.
Auch die Frage der initialen Versorgung sekundärer Systeme wird nicht ausgespart.
Hierauf folgt ein Kapitel zur zukünftigen Entwicklung. Der Autor wagt hier weniger eine Prognose über zu erwartende Technologien.
Vielmehr abstrahiert er die zuvor im Buch vorgestellten Konzepte weiter und kommt so zu zwei möglichen Entwicklungsrichtungen, von denen er eine ("The unbundled database") klar favorisiert.
Bis hierhin war das gesamte Buch rein sachlich und betrachtete die besprochenen Technologien wertfrei.
Im letzten Kapitel ("Doing the Right Thing") wird dann noch auf den gesellschaftlich-ethischen Hintergrund eingegangen: Schließlich kommen die besprochenen Technologien vor allem dann zum Einsatz, wenn es um die Verarbeitung und Analyse riesieger Datenmengen geht - und wozu diese Daten genutzt werden ist nicht mehr wertfrei.
Unter "Predictive Analytics" wird beschrieben, wie eingesetzte Analysemethoden systematisch diskriminierend sein können und welche Probleme hieraus für die Opfer resultieren. Insbesondere wird auf das Fehlen von Möglichkeiten, sich zur Wehren, eingegangen.
In "Privacy and tracking" schärft er mit einem einfachen Gedankenexperiment ("... try replacing the word data with surveillance ...") das Bewusstsein für weitere gesellschaftliche Gefahren der Datensammlung.
a thought experiment, try replacing the word data with surveillance, and observe if common phrases still sound so good. How about this: “In our surveillance-driven organization we collect real-time surveillance streams and store them in our surveillance warehouse. Our surveillance scientists use advanced analytics and surveillance processing in order to derive new insights."
Fazit
Man merkt, dass sehr viel praktische Erfahrung in das Buch eingeflossen ist.
Es enthält eine Fülle von Hinweisen auf Problemquellen, die nicht offensichtlich sind und die jemand ohne entsprechende einschlägige Erfahrung wahrscheinlich übersehen würde.
Mit der Breite der abgedeckten Themen, der Qualität des präsentierten Wissens und der guten Gliederung hat das Buch das Potenzial, dauerhaft als Nachschlagewerk genutzt zu werden.
Einsteiger dürften mit der vorgestellten Welt überfordert sein, aber Leser die bereits erste größere Systeme designed haben, werden mit viel Wissen für die nächsten Schritte belohnt.
Auf der Website von O'Reilly hat das Buch derzeit bei 30 Bewertungen die bestmögliche Note "5.0". Ich kann mich dieser positiven Meinung nur anschließen. Das Buch bietet eine derartige Fülle von fundiertem Wissen, wie man sie selten findet.