Radikale Einfachheit im Knowledge Engineering | von Cai Parry-Jones | Jul, 2024

Lernen Sie von Softwareentwicklern und entdecken Sie die Freude am „Schlechter ist besser“-Denken

Vor kurzem hatte ich das Glück, mit einer Reihe von Dateningenieuren und Datenarchitekten über die Probleme zu sprechen, die sie in ihren Unternehmen mit Daten haben. Die wichtigsten Problempunkte, die ich immer wieder hörte, waren:

• Ich weiß nicht, warum etwas kaputtgegangen ist
• Hohe Cloud-Computing-Kosten
• Das Erstellen von Datenlösungen/Abschließen von Datenprojekten dauert zu lange
• Fachwissen zu vielen Instruments und Technologien erforderlich

Diese Probleme sind nicht neu. Ich habe sie erlebt, Sie haben sie wahrscheinlich auch erlebt. Dennoch scheinen wir keine Lösung zu finden, die all diese Probleme langfristig löst. Sie denken sich vielleicht: „Punkt eins kann mit {hier Datenbeobachtungstool einfügen} gelöst werden“, oder „Punkt zwei erfordert nur einen strengeren Datenverwaltungsplan“. Das Downside bei dieser Artwork von Lösungen ist, dass sie zusätzliche Komplexitätsebenen hinzufügen, wodurch die letzten beiden Schwachstellen noch schwerwiegender werden. Die Gesamtsumme der Probleme bleibt dieselbe, nur die Verteilung auf die vier Punkte ist anders.

Dieser Artikel zielt darauf ab, einen gegenteiligen Stil der Problemlösung vorzustellen: radikale Einfachheit.

Kurz zusammengefasst

• Softwareentwickler haben mit der Umsetzung der Einfachheit enormen Erfolg gehabt.
• Übermäßiges Engineering und Streben nach Perfektion können zu aufgeblähten Datensystemen führen, deren Entwicklung langsam verläuft, was für das Unternehmen enorme Kosten verursacht.
• Datenteams sollten in Erwägung ziehen, zugunsten der Einfachheit und Geschwindigkeit auf einige Funktionen zu verzichten.

Eine Lektion von diesen Software program-Leuten

1989 battle der Informatiker Richard P. Gabriel schrieb einen relativ berühmten Aufsatz über Computersysteme mit dem paradoxen Titel „Schlimmer ist besser“. Ich werde nicht ins Element gehen, Sie können den Aufsatz lesen Hier wenn Sie so wollen, aber die zugrunde liegende Botschaft battle, dass die Softwarequalität nicht unbedingt besser wird, wenn die Funktionalität zunimmt. Mit anderen Worten: Manchmal kann man Vollständigkeit zugunsten der Einfachheit opfern und dadurch ein von Natur aus „besseres“ Produkt erhalten.

Für die Computerpioniere der 1950er/60er Jahre battle das eine seltsame Idee. Die Philosophie der damaligen Zeit battle: Ein Computersystem muss rein sein, und das kann es nur sein, wenn es alle möglichen Szenarien berücksichtigt. Dies lag wahrscheinlich daran, dass die meisten führenden Informatiker damals Akademiker waren, die die Informatik unbedingt als eine Naturwissenschaft behandeln wollten.

Am MIT, der damals führenden Establishment für Informatik, begannen Wissenschaftler mit der Arbeit am Betriebssystem für die nächste Computergeneration, genannt Multics. Nach quick einem Jahrzehnt der Entwicklung und Investitionen in Millionenhöhe veröffentlichten die Leute vom MIT ihr neues System. Es battle zweifellos das fortschrittlichste Betriebssystem seiner Zeit, allerdings battle die Set up aufgrund der hohen Rechenleistung mühsam und aufgrund der Größe der Codebasis waren Funktionsupdates langsam. Daher konnte es sich nur an einigen wenigen Universitäten und in einigen Branchen durchsetzen.

Während Multics entwickelt wurde, wurde eine kleine Gruppe, die die Entwicklung von Multics unterstützte, von den steigenden Anforderungen an das System frustriert. Sie beschlossen schließlich, sich aus dem Projekt zurückzuziehen. Mit dieser Erfahrung im Rücken nahmen sie sich vor, ihr eigenes Betriebssystem zu entwickeln, eines mit einer grundlegenden Philosophieänderung:

Das Design muss einfach sein, sowohl in der Implementierung als auch in der Schnittstelle. Die Einfachheit der Implementierung ist wichtiger als die Einfachheit der Schnittstelle. Einfachheit ist die wichtigste Überlegung bei einem Design.

— Richard P. Gabriel

Fünf Jahre nach der Veröffentlichung von Multics veröffentlichte die Splittergruppe ihr Betriebssystem, UnixLangsam aber sicher gewann es an Zugkraft und in den 1990er Jahren wurde Unix zur ersten Wahl für Pc, mit über 90 % der 500 schnellsten Supercomputer der Welt es zu benutzen. Bis heute wird Unix noch häufig verwendet, vor allem als das System, das macOS zugrunde liegt.

Es gab offensichtlich noch andere Faktoren als seine Einfachheit, die zum Erfolg von Unix führten. Aber sein leichtgewichtiges Design battle und ist noch immer ein äußerst wertvoller Vorteil des Methods. Das konnte nur erreicht werden, weil die Entwickler bereit waren, Funktionalität zu opfern. Die Datenindustrie sollte keine Angst haben, genauso zu denken.

Zurück zu Daten im 21. Jahrhundert

Wenn ich an meine eigenen Erfahrungen zurückdenke, battle die Philosophie der meisten Huge Knowledge Engineering-Projekte, an denen ich gearbeitet habe, ähnlich der von Multics. Es gab beispielsweise ein Projekt, bei dem wir die Standardisierung der Rohdaten aller unserer Kunden automatisieren mussten. Wir entschieden uns, dies im Knowledge Warehouse über dbt zu tun, da wir dann einen vollständigen Überblick über die Datenherkunft von den Rohdateien bis hin zur standardisierten Einzeltabellenversion und darüber hinaus haben konnten. Das Downside bestand darin, dass die erste Section der Transformation sehr manuell battle. Es musste jede einzelne Rohdatei des Kunden in das Warehouse geladen werden, dann erstellt dbt ein Modell zum Bereinigen der Datei jedes Kunden. Dies führte dazu, dass Hunderte von dbt-Modellen generiert werden mussten, die alle im Wesentlichen dieselbe Logik verwendeten. Dbt wurde so aufgebläht, dass es Minuten dauerte, bis das Datenherkunftsdiagramm auf der dbt-Dokumenten-Web site geladen battle, und unsere GitHub-Aktionen für CI (kontinuierliche Integration) dauerte für jeden Pull Request über eine Stunde.

Dies hätte ziemlich einfach gelöst werden können, wenn die Leitung uns erlaubt hätte, die erste Transformationsebene außerhalb des Knowledge Warehouse mit AWS Lambda und Python durchzuführen. Aber nein, das hätte bedeutet, dass die von dbt erstellte Datenherkunft nicht zu 100 % vollständig wäre. Das battle es. Das battle der einzige Grund, das Projekt nicht massiv zu vereinfachen. Ähnlich wie die Gruppe, die sich vom Multics-Projekt abgewendet hat, habe ich dieses Projekt mitten im Aufbau verlassen. Es battle einfach zu frustrierend, an etwas zu arbeiten, das so offensichtlich viel einfacher hätte sein können. Während ich dies schreibe, habe ich herausgefunden, dass sie immer noch an dem Projekt arbeiten.

Additionally, was zum Teufel ist radikale Einfachheit?

Radikale Einfachheit in der Datentechnik ist kein Framework oder Datenstapel-Toolkit, sondern einfach eine Geisteshaltung. Eine Philosophie, die einfache, unkomplizierte Lösungen gegenüber komplexen, allumfassenden Systemen bevorzugt.

Zu den wichtigsten Grundsätzen dieser Philosophie gehören:

1. Minimalismus: Konzentration auf die Kernfunktionen, die den größten Nutzen bieten, statt zu versuchen, jedem möglichen Szenario oder jeder möglichen Anforderung gerecht zu werden.
2. Kompromisse eingehen: Bereitwillig ein gewisses Maß an Vollständigkeit oder Perfektion zugunsten von Einfachheit, Geschwindigkeit und Wartungsfreundlichkeit opfern.
3. Pragmatismus statt Idealismus: Priorisierung praktischer, umsetzbarer Lösungen, die echte Geschäftsprobleme effizient lösen, statt theoretisch perfekte, aber übermäßig komplexe Systeme anzustreben.
4. Reduzierte kognitive Belastung: Entwicklung von Systemen und Prozessen, die einfacher zu verstehen, zu implementieren und zu warten sind, wodurch das erforderliche Fachwissen zu mehreren Instruments und Technologien reduziert wird.
5. Kosteneffizienz: Einführung einfacherer Lösungen, die häufig weniger Rechenressourcen und Humankapital erfordern, was zu niedrigeren Gesamtkosten führt.
6. Agilität und Anpassungsfähigkeit: Erstellen Sie Systeme, die sich bei veränderten Geschäftsanforderungen leichter ändern und weiterentwickeln lassen, anstelle von starren, überentwickelten Lösungen.
7. Konzentrieren Sie sich auf die Ergebnisse: Betonen Sie die Endergebnisse und den Geschäftswert, anstatt sich in den Feinheiten der Datenprozesse selbst zu verlieren.

Diese Denkweise kann im direkten Widerspruch zu modernen Knowledge-Engineering-Lösungen stehen, bei denen weitere Instruments, Prozesse und Schichten hinzugefügt werden. Daher müssen Sie damit rechnen, dass Sie für Ihre Sache kämpfen. Bevor Sie eine various, einfachere Lösung vorschlagen, sollten Sie sich ein umfassendes Verständnis des vorliegenden Issues verschaffen. Ich erinnere mich an das Zitat:

Es erfordert viel harte Arbeit, etwas einfach zu machen, die zugrunde liegenden Herausforderungen wirklich zu verstehen und elegante Lösungen zu finden. (…) Es geht nicht nur um Minimalismus oder die Abwesenheit von Unordnung. Es geht darum, sich durch die Tiefen der Komplexität zu graben. Um wirklich einfach zu sein, muss man wirklich tief gehen. (…) Man muss das Wesen eines Produkts genau verstehen, um die Teile loswerden zu können, die nicht wesentlich sind.

– Steve Jobs

Randbemerkung: Bedenken Sie, dass radikale Einfachheit nicht bedeutet, neue Instruments und fortschrittliche Technologien zu ignorieren. Tatsächlich ist eine meiner Lieblingslösungen für ein Knowledge Warehouse im Second die Verwendung einer neuen Open-Supply-Datenbank namens enteDB. Schaut es euch an, es ist ziemlich cool.

Abschluss

Die Lehren aus der Geschichte der Softwareentwicklung bieten wertvolle Einblicke in die heutige Datenlandschaft. Durch radikale Vereinfachung können Datenteams viele der Schwachstellen moderner Datenlösungen beheben.

Scheuen Sie sich nicht, in Ihrem Datenteam radikale Vereinfachung zu propagieren. Seien Sie der Katalysator für Veränderungen, wenn Sie Möglichkeiten zur Rationalisierung und Vereinfachung sehen. Der Weg zur Vereinfachung ist nicht einfach, aber die potenziellen Belohnungen können beträchtlich sein.