Herstellerfreie Datenwissenschaft

Wir werden oft von Kunden gefragt, welche Anbieterlösung(en) wir für ihre Data Science-Anforderungen vorschlagen. In diesem Blogbeitrag versuche ich zusammenzufassen, warum die Antwort (fast immer) ein Open-Source-Tool ist.

Wir machen kein Geheimnis daraus, dass GoDataDriven Open Source liebt. Aber warum ist das so?

Open Source Software kann nicht alles leisten

Dies bedarf einiger Erklärung. Wenn Menschen ein Open-Source-Produkt oder -Projekt entwickeln und veröffentlichen, denken sie wahrscheinlich, dass das, was sie getan haben, für die gesamte Gemeinschaft interessant ist. Ihr Ziel ist erreicht, wenn die Menschen anfangen, ihre Software zu nutzen. Aber, besonders in der Datenwissenschaft, geben sie nicht vor, alles für Sie zu tun.

Vielleicht sind sie gut im Umgang mit Daten. Vielleicht sind sie gut im Planen. Vielleicht sind sie gut in der Verarbeitung großer Datenmengen.

Da sie nicht versuchen, alles zu tun, sind sie (oder sollten es sein) extrem flexibel, wenn es um die Verbindung mit anderen Teilen Ihrer Infrastruktur, Pipelines oder Tools geht.

Das bedeutet, dass die Verwendung eines bestimmten Tools Sie nicht dazu zwingt, alle anderen Tools, die Sie verwenden, zu ändern.

Dies ist auch wichtig, wenn es um die Tools geht, die Sie in Ihrem Arbeitsablauf verwenden.

Nehmen Sie zum Beispiel Git: Ich bin der festen Überzeugung, dass Git oder jedes andere verteilte Versionskontrollsystem von grundlegender Bedeutung ist, wenn es um die Entwicklung und Produktion von Data-Science-Lösungen geht.

Sei es, dass wir in der Zeit zurückgehen, sei es, dass wir uns in Ihr Build-System integrieren, sei es, dass wir gemeinsam an derselben Funktion arbeiten.

Auf der anderen Seite gibt es viele kommerzielle Anbieter¹ versuchen, Ihnen alles aus einer Hand zu bieten, was Sie für Ihre Data Science brauchen. Sie kümmern sich um Ihren Code, Ihr Datenmanagement, Ihre Datenverarbeitung, Ihre Modelle und die Überführung Ihrer Modelle in die Produktion. Und sie bieten keine ausgereiften Versionskontrollsysteme an und sind auch nicht in diese integriert.

Selbst wenn Sie den Preis nicht berücksichtigen, könnten Sie argumentieren, dass dieser Ansatz attraktiver ist, da Sie sich nicht um die vielen beweglichen Teile kümmern müssen. Es nimmt Ihnen jedoch eine Menge Freiheit: Wenn ein neues, in gewisser Weise besseres System für die Datenverarbeitung auf den Markt kommt, können Sie dieses in den meisten Fällen nicht einfach ersetzen: Es liegt im Interesse des Anbieters, Sie in der Regel zu behalten.² in seiner Plattform zu halten.

Das bedeutet, dass es keine (einfache) Möglichkeit gibt, mit One-Stop-Shops zu kombinieren.

Open Source beruht auf ausgereiften Prinzipien der Softwareentwicklung

Wenn ich das zum ersten Mal erwähne, sind die Leute verwirrt und fragen sich, wovon zum Teufel ich da rede. In der Regel erkläre ich dann, warum Software-Engineering für Data Science wichtig ist.

Es läuft darauf hinaus, dass Data Science die Disziplin der Softwareentwicklung benötigt.

Da Open-Source-Projekte auf Software-Engineering-Prinzipien beruhen, liegt es auf der Hand, dass sie so aufgebaut sind, dass Sie bei ihrer Nutzung auch diese Prinzipien befolgen können.

Beispiel

Ich werde Ihnen ein Beispiel geben, nur für den Fall, dass Ihnen der Kopf schwirrt. Wenn ich ein Tool wie Airflow verwende, kann ich Git für alle meine Import-Pipelines verwenden. Das Ziel von Airflow ist es, die Pipelines zu orchestrieren und nicht, meinen Arbeitsablauf zu übernehmen. Und da Airflow Git für seine Entwicklung verwendet, ist es sinnvoll, dass sie dies auch ihren Benutzern ermöglichen.

Ein weiteres Beispiel ist Spark. Wenn Sie Spark-Code schreiben, sollten Sie unbedingt auch die dazugehörigen Unit-Tests schreiben. Spark bietet Ihnen die Möglichkeit, diese Tests zu schreiben, denn, raten Sie mal, Spark wird auch ausgiebig getestet. ³

Leute, die an Open-Source-Tools gewöhnt sind, werden vielleicht erstaunt sein, dass einige Anbieter sich nicht in Ihr Versionskontrollsystem integrieren lassen oder das Schreiben von Unit-Tests nicht erlauben. Aber es gibt sie. Mathematica zum Beispiel hat erst in Version 10 ein Unit-Testing-Framework hinzugefügt. SAS und SPSS bieten meines Wissens nach kein Unit-Testing-Framework an.

Open Source gibt Ihnen mehr Macht

Das bedeutet mehr Verantwortung! Außer in den Fällen, in denen Unternehmen beginnen, Support und Premium-Funktionen zusätzlich zu einem Open-Source-Projekt anzubieten, wie z.B. bei den Spark-Databricks, Kafka-Confluent und Cassandra-Datastax-Kombinationen, gibt es keinen Support für Open-Source-Projekte. Das bedeutet, dass Sie bei Fehlern oder Funktionen, die Sie gerne behoben oder implementiert sehen würden, den Betreuern des Projekts ausgeliefert sind. Das ist der Teil der Verantwortung.

Aber... ist das schlecht? Implementieren die Anbieter neue Funktionen oder beheben sie Fehler auf Ihren Wunsch hin und wenn Sie sie brauchen? Wie viel Geld müssen Sie Ihrem Datenbankanbieter zahlen, damit er Ihnen gibt, was Sie wollen?

Wenn es sich um ein Open-Source-Projekt handelt, können die Leute, die für Sie arbeiten, das Problem beheben, und Sie können dann entscheiden, ob Sie es der Gemeinschaft zurückgeben möchten.

Auf den ersten Blick mag es beängstigend erscheinen: Software zu ändern! Aber wenn Sie darüber nachdenken, läuft Ihr gesamtes Unternehmen mit Software, und einige, wenn nicht sogar die meisten dieser Programme wurden im Haus geschrieben. Das kann Ihre Berichtssoftware sein, Ihre Website, die SQL-Abfrage, die Ihre DBAs geschrieben haben, usw. Letztendlich ist das alles nur Code!

Inzwischen verstehen Sie wahrscheinlich die vielen Beiträge über unsere Open-Source-Beiträge. Wir finden neue Dinge, die wir uns von den Tools, die wir verwenden, wünschen, wir implementieren sie und geben der Gemeinschaft etwas zurück. Das berühmte Spiderman-Zitat sollte also eigentlich andersherum lauten, wenn es um Open Source Software geht:

Jetzt kommt der Teil, in dem die Einwender sagen werden, dass sie nicht über die personellen Ressourcen verfügen, um Fehler zu beheben oder neue Funktionen zu implementieren. Was sie jedoch oft nicht sehen, ist, dass das Geld, das Sie einsparen, wenn Sie sich nicht für einen Anbieter entscheiden⁴ viel besser in gute Mitarbeiter investiert werden kann, denen Sie mehr Zeit für diese Aufgaben geben. Gehen Sie nicht davon aus, dass Ihre Mitarbeiter oder Kollegen kein Interesse daran haben: Sie haben sich wahrscheinlich von vornherein für das Open-Source-Tool entschieden, und ich wette, sie würden der Gemeinschaft gerne etwas zurückgeben.

Alles, was es braucht, ist die Angst zu überwinden, die uns jedes Mal begleitet, wenn wir etwas zum ersten Mal tun.

Außerdem: Menschen sind mit Sicherheit das wichtigste Kapital, das Ihr Unternehmen hat.⁵: Würden Sie lieber die Mitarbeiter oder Ihren Verkäufer stärken?

Open Source beschleunigt die Innovation

Kein Anbieter spricht gerne über dieses Thema. Bevor Sie wissen, ob das, was Sie erreichen wollen (ein neuer Algorithmus, eine neue Datenspeicheroption usw.), realisierbar ist, müssen Sie mit der "Verkaufsabteilung" des potenziellen Anbieters sprechen: wie viel wird es Sie kosten, bevor Sie anfangen können. Wenn alles arrangiert ist, kann der Spaß beginnen. Der Algorithmus nimmt Gestalt an, die Ergebnisse werden validiert und Sie sind bereit, ihn in die Produktion zu übernehmen.

Warten Sie! Die Lizenz, die Sie haben, ist nicht wirklich für die Produktion geeignet. Sie brauchen eine andere Lizenz. Igitt!

Oder nehmen wir an, Sie erhalten eine neue spannende Datenquelle. Sie können es kaum erwarten, diese mit den übrigen Daten zu verbinden. Eine neue Datenbank wird erstellt, aber... Sie können keine neuen Datenbanken erstellen, da das Limit für das aktuelle Abonnement erreicht ist. Kontaktieren Sie den Vertrieb für ein Upgrade!

Ich habe das in vielen verschiedenen Unternehmen immer wieder gehört. Die Leute können nicht innovativ sein, weil alles so starr eingerichtet ist: Jeder Teil der Infrastruktur befindet sich in einem anderen Reich. Sie können es zwar schaffen, aber wenn Sie fertig sind, haben Sie keine Energie mehr für Innovationen.

Open Source ist transparent

Mit transparent meine ich, dass Sie sehen können, was vor sich geht und entsprechend handeln können. Dies ist für zwei Dinge relevant:

• Dokumentation;
• Qualitätssicherung.

Dokumentation

Dokumentation scheint albern, aber fragen Sie Programmierer, was sie dokumentieren. In der Regel wird in der Dokumentation erklärt, wie man eine API verwendet. Aber sie sagt nicht viel über die (Software-)Architektur aus, in der sie verwendet werden soll.

Ein aktuelles Beispiel von Heap analytics veranschaulicht dieses Problem am besten: Das Unternehmen nahm Tausende von Ereignissen pro Tag auf, um Echtzeitanalysen von Kundendaten zu ermöglichen. Wenn neue Datensätze in die Datenbank eingefügt wurden, sah der Prozess folgendermaßen aus: ein Datensatz für Kunde A, dann einer für Kunde B, dann C, dann D, dann wieder A, usw. Nach dem Zufallsprinzip.

Die von Heap verwendete Datenbanklösung PostgreSQL speichert einen Teil der Daten zwischen, wenn Sie Indizes für diese Datensätze erstellen⁶. Dieses zufällige Muster der Dateneingabe (Kunde A-B-C-D-A-???) führte jedoch dazu, dass der Cache für einen bestimmten Kunden praktisch sofort geleert wurde ( ).

Dieses zufällige Zugriffsmuster spielt in den meisten Größenordnungen keine Rolle. Dieses Verhalten wurde in der Dokumentation nicht erwähnt, da die Datenbank das tat, was man von einer guten Datenbank erwarten würde: die Daten in der gewünschten Reihenfolge schreiben und darüber hinaus die Daten zwischenspeichern, um die Dinge zu beschleunigen.

Für Heap war dies jedoch ein Problem: Es bedeutete, dass viele Kunden bis zu einer Stunde warten mussten, um ihre Daten in ihrem Dashboard zu sehen, da der Caching-Mechanismus nicht wirklich funktionierte.

Ein Ingenieur beschloss daher, sich das Problem genauer anzusehen. Schließlich las er den PostgreSQL-Quellcode und fand heraus, wo das Problem lag.

Er implementierte dann eine clientseitige Lösung (PostgreSQL war letztendlich nicht der Schuldige), die Heap Millionen von Dollar spart.⁷

Auch hier werden Sie, wenn Sie ein Gegner von Open Source sind, sagen: Aber wir haben doch Unterstützung von unserem Anbieter.

Ja, das ist wahr. Aber je archaischer der Randfall ist, desto näher müssen Sie an den Quellcode herankommen. Und ich kann Ihnen versichern, dass der First- und Second-Line-Support Ihres Anbieters nicht einmal Zugang zum Quellcode des von Ihnen verwendeten Produkts hat und auch nicht die Fähigkeiten besitzt, diesen zu verstehen!

Sobald Sie bei der dritten Linie angelangt sind, müssen diese wahrscheinlich Ihren Anwendungsfall verstehen, vielleicht wollen sie sogar einen Blick in Ihre Datenbank werfen (dann müssen NDAs unterzeichnet werden, die Ingenieure werden sich wahrscheinlich in den USA befinden und die Liste geht weiter). Sobald eine Lösung gefunden wurde, sind vielleicht 3 Monate vergangen und ein Teil Ihrer Kunden hat Sie bereits verlassen, weil Ihr Produkt zu langsam war.

Qualitätssicherung

Eine weitere knifflige Frage! Hier geht es um wissenschaftliche Software, den wissenschaftlichen Python-Stack im Allgemeinen und scikit-learn im Besonderen.

Scikit-learn ist eine Bibliothek mit Algorithmen für maschinelles Lernen, die in Python geschrieben wurden. Die Algorithmen werden von wissenschaftlichen Forschern aus der ganzen Welt geschrieben. Jeder Algorithmus, der in scikit-learn aufgenommen wird, ist von anderen Forschern gründlich geprüft worden.

Wenn Sie den Code verwenden, können Sie mit dieser Gewissheit ruhig schlafen. Aber wenn Sie unter Schlaflosigkeit oder Paranoia leiden, können Sie einen Texteditor öffnen, scikit-learn herunterladen und einen Blick darauf werfen.

Das gilt nicht nur für scikit-learn: Jedes Open-Source-Projekt kann daraufhin überprüft werden, ob es das tut, was es behauptet.

Was dann?

Die nächste wichtige Frage ist: Was ist der Rat von GoDataDriven? Nun, das Meme sagt alles: Wir verfolgen einen Ansatz, bei dem Open Source zuerst kommt und der Anbieter erst danach. Wenn die Lösung des Anbieters viel besser ist als das, was eine Open-Source-Lösung bietet, dann entscheiden wir uns für den Anbieter. Allerdings unter zwei Bedingungen! Es gibt keine Datenbindung und keine Code-Bindung. Dadurch wird eine Situation wie in Hotel California vermieden, in der Sie jederzeit auschecken können, aber nie wieder abreisen können.

Möchten Sie mehr darüber erfahren, was es bedeutet, so zu arbeiten? Wir stellen ein!