Get best of the week

Warum brauchen wir DevOps im Bereich ML-Daten?



Die Bereitstellung von maschinellem Lernen (ML) in der Produktion ist keine leichte Aufgabe, aber in der Tat um eine Größenordnung schwieriger als die Bereitstellung herkömmlicher Software. Infolgedessen werden die meisten ML-Projekte niemals das Licht der Welt erblicken - und die Produktion -, da die meisten Unternehmen aufgeben und aufgeben, ML zu verwenden, um ihre Produkte zu bewerben und Kunden zu bedienen.

Soweit wir sehen können, besteht das grundlegende Hindernis für die meisten Teams bei der Erstellung und Bereitstellung von ML in der Produktion im erwarteten Umfang darin, dass wir DevOps- Praktiken immer noch nicht einführen konntenim maschinellen Lernen. Der Prozess der Erstellung und Bereitstellung von ML-Modellen wird teilweise durch bereits veröffentlichte MLOps-Lösungen offenbart, die jedoch von einem der schwierigsten Aspekte von ML nicht unterstützt werden: Daten.

In diesem Artikel diskutieren wir, warum die Branche DevOps-Lösungen für ML-Daten benötigt und wie die einzigartigen Schwierigkeiten von ML-Daten die Bemühungen behindern, ML in die Praxis umzusetzen und in der Produktion einzusetzen. Der Artikel beschreibt das Vakuum im aktuellen ML-Infrastruktur-Ökosystem und schlägt vor, es mit Tecton, einer zentralen Datenplattform für maschinelles Lernen, zu füllen. Klicken Sie hier , um einen Artikel meines Mitbegründers Mike zu lesen und weitere Informationen zum Start von Tecton zu erhalten.

Tecton wurde von einem Team von Ingenieuren erstellt, die interne ML-Plattformen für Unternehmen wie Uber, Google, Facebook, Twitter, Airbnb, AdRoll und Quora erstellt haben. Die bedeutenden Investitionen dieser Unternehmen in ML ermöglichten die Entwicklung von Prozessen und Werkzeugen für den umfassenden Einsatz von ML für ihre Organisationen und Produkte. Die in diesem Artikel vorgestellten Lektionen sowie die Tecton-Plattform selbst basieren weitgehend auf den Erfahrungen unseres ML-Bereitstellungsteams in der Produktion in den letzten Jahren.

Erinnern Sie sich an die Zeit, als die Softwareversion lang und schmerzhaft war?


Der Softwareentwicklungs- und -bereitstellungsprozess vor zwanzig Jahren und der ML-Anwendungsentwicklungsprozess unserer Tage haben viele Gemeinsamkeiten: Feedback-Systeme erwiesen sich als unglaublich lang, und bis zur Veröffentlichung des Produkts waren Ihre anfänglichen Anforderungen und Ihr Design bereits veraltet. Ende der neunziger Jahre wurden dann eine Reihe von Best Practices für die Softwareentwicklung in Form von DevOps entwickelt , die Methoden zur Verwaltung des Entwicklungslebenszyklus bereitstellen und es uns ermöglichen, kontinuierliche und schnelle Verbesserungen zu erzielen.

Der DevOps-Ansatz ermöglicht es Ingenieuren, in einer genau definierten gemeinsamen Codebasis zu arbeiten. Sobald eine schrittweise Änderung zur Bereitstellung bereit ist, überprüft der Techniker sie über ein Versionskontrollsystem. Der Prozess der kontinuierlichen Integration und Bereitstellung (CD / CI) berücksichtigt die neuesten Änderungen, führt Komponententests durch, erstellt Dokumentationen, führt Integrationstests durch und gibt auf kontrollierte Weise Änderungen an der Produktion frei oder bereitet eine Freigabe für den Vertrieb vor.


Feige. 1: typischer DevOps-Prozess

Hauptmerkmale von DevOps:

  • Programmierer besitzen ihren Code von Anfang bis Ende. Sie sind befugt und voll verantwortlich für jede Codezeile in der Produktion. Dieses Gefühl der Eigenverantwortung verbessert im Allgemeinen die Qualität des Codes sowie die Verfügbarkeit und Zuverlässigkeit von Programmen.
  • Teams können Prozesse schnell wiederholen und sind nicht an monatelange Zyklen des Kaskadenmodells gebunden. Stattdessen können sie neue Funktionen fast sofort mit echten Benutzern testen.
  • Leistungs- und Zuverlässigkeitsprobleme werden schnell erkannt und analysiert. Wenn die Leistungsmetriken unmittelbar nach der letzten Bereitstellung sinken, wird ein automatischer Rollback ausgelöst, und die Änderungen, die die Bereitstellung im Code verursacht haben, führen sehr wahrscheinlich dazu, dass die Metriken fallen.

Heutzutage haben viele Entwicklungsteams einen solchen integrierten Ansatz als Grundlage genommen.

... Im Allgemeinen ist der Einsatz von ML immer noch langwierig und schmerzhaft


Im Gegensatz zur Softwareentwicklung gibt es keine genau definierten, vollautomatisierten Prozesse für eine schnelle Produktion in der Datenanalyse. Das Erstellen und Bereitstellen einer ML-Anwendung in einem Produkt besteht aus mehreren Schritten:


Abb. 2: Datenanalysespezialisten müssen ihre Arbeit zwischen mehreren Teams in verschiedenen Bereichen koordinieren

  • Ermittlung und Zugriff auf Quelldaten. Datenwissenschaftler in den meisten Unternehmen verbringen bis zu 80% ihrer Zeit damit, nach Quelldaten zu suchen, um ihr Problem zu modellieren. Dies erfordert häufig eine funktionsübergreifende Koordination mit Dateningenieuren und dem Regulierungsteam.
  • . , . , , .
  • . . ( ).
  • Bereitstellung und Integration des Modells. Dieser Schritt umfasst normalerweise die Integration in einen Dienst, der das Modell für die Prognose verwendet. Zum Beispiel die mobile Anwendung eines Online-Händlers, die ein Empfehlungsmodell verwendet, um Produktangebote vorherzusagen.
  • Überwachungssetup. Um sicherzustellen, dass das ML-Modell und die Datenprozesse ordnungsgemäß funktionieren, ist erneut die Hilfe von Programmierern erforderlich.

Infolgedessen stehen ML-Teams vor denselben Problemen wie Programmierer vor zwanzig Jahren:

  • Data-Science-Experten haben nicht die volle Verantwortung für den Lebenszyklus von Modellen und Funktionen. Um ihre Änderungen bereitzustellen und sie in der Produktion zu unterstützen, müssen sie sich auf andere verlassen.
  • data science . . . , , data science, , , , , .


. 3: ,

  • . data science, . , , , .

DevOps ML . DevOps ML data


Solche MLOps- Plattformen wie Sagemaker Kubeflow bewegen sich auf dem Weg in die richtige Richtung, um Unternehmen bei der Vereinfachung der ML-Produktion zu unterstützen. So können wir beobachten, wie MLOps Prinzipien und DevOps-Tools in ML einführt. Um loszulegen, benötigen sie recht ordentliche Vorabinvestitionen, aber nach ordnungsgemäßer Integration können sie die Fähigkeiten von Data-Science-Spezialisten auf dem Gebiet der Schulung, Verwaltung und Produktion von ML-Modellen erweitern.

Leider konzentrieren sich die meisten MLOps-Tools auf den Workflow rund um das Modell selbst (Schulung, Implementierung, Verwaltung), was für vorhandene MLs eine Reihe von Schwierigkeiten mit sich bringt. ML-Anwendungen werden durch Code, Modelle und Daten definiert.. Ihr Erfolg hängt von der Fähigkeit ab, qualitativ hochwertige ML-Daten zu erstellen und diese recht schnell und stabil an die Produktion zu liefern. Andernfalls ist dies ein weiterer „Müll rein, Müll raus“. Das folgende Diagramm, das speziell aus Googles Arbeiten zur technischen Verschuldung in ML ausgewählt und angepasst wurde , zeigt die "datenzentrierten" und "modellzentrierten" Elemente in ML-Systemen. Heutzutage helfen MLOps-Plattformen bei vielen „modellzentrierten“ Elementen, jedoch nur bei einigen wenigen „datenzentrierten“ Elementen oder wirken sich überhaupt nicht auf sie aus:


Abb. 4: Modell und atazentrische Elemente von ML-Systemen. Modellzentrierte Elemente werden heute weitgehend von MLOps-Systemen abgedeckt.

Der nächste Abschnitt zeigt einige der schwierigsten Tests, die wir bei der Vereinfachung der ML-Produktion erlebt haben. Sie sind keine umfassenden Beispiele, sondern sollen die Probleme aufzeigen, die bei der Verwaltung des ML-Datenlebenszyklus auftreten (Funktionen und Beschriftungen):

  • Zugriff auf korrekte Quelldatenquellen
  • Erstellen von Funktionen und Beschriftungen aus den Quelldaten
  • Funktionen in Trainingsdaten kombinieren
  • Berechnung und Ausgabe von Funktionen in der Produktion
  • Produktionsverfolgung

Eine kleine Erinnerung, bevor wir weiter tauchen: Die ML-Funktion sind die Daten, die als Eingabe für das Modell dienen, um eine Entscheidung zu treffen. Beispielsweise möchte ein Lebensmittel-Lieferservice die erwartete Lieferzeit in seiner Anwendung anzeigen. Dazu ist es notwendig, die Dauer der Zubereitung eines bestimmten Gerichts in einem bestimmten Restaurant zu einem bestimmten Zeitpunkt vorherzusagen. Eines der bequemen Signale für die Erstellung einer solchen Prognose - ein Indikator dafür, wie beschäftigt das Restaurant ist - ist die „Endabrechnung“ der eingehenden Bestellungen in den letzten 30 Minuten. Die Funktion wird basierend auf dem Fluss der Anfangsdaten der Auftragsreihenfolge berechnet:


Abb. 5: Die Anfangsdaten werden durch die Funktionstransformation in Funktionswerte geändert

Testdatum Nr. 1: Zugriff auf die richtigen Quelldaten


Um eine Funktion oder ein Modell zu erstellen, muss ein Data Science-Spezialist zunächst die richtige Datenquelle finden und Zugriff darauf erhalten. Es gibt mehrere Hindernisse auf dem Weg:

  • Datenermittlung: Fachleute müssen wissen, wo sich die Quelldaten befinden. Eine großartige Lösung sind Datenkatalogisierungssysteme (wie Lyfts Amundsen ), die jedoch noch nicht so universell eingesetzt werden. Oft existieren die notwendigen Daten einfach nicht und müssen daher erst erstellt oder katalogisiert werden.
  • Genehmigung des Zugriffs: Oft ist es ein obligatorischer Schritt auf dem Weg von Data-Science-Experten, zwischen Behörden herumzulaufen, um die Berechtigung zum Zugriff auf Daten zu erhalten, die Probleme lösen.
  • : , , . , .

- #2:


Die Quelldaten können aus vielen Quellen stammen, von denen jede ihre eigenen wichtigen Eigenschaften hat, die sich auf die aus ihnen extrahierten Funktionstypen auswirken. Diese Eigenschaften umfassen die Unterstützung von Datenquellen für Transformationstypen , die Datenrelevanz und die Menge des verfügbaren Datenarchivs :


Abb. 6: Unterschiedliche Datenquellen haben unterschiedliche Ansätze für unterschiedliche Arten der Datentransformation und bieten je nach Relevanz Zugriff auf unterschiedliche Datenmengen.

Es ist wichtig, diese Eigenschaften zu berücksichtigen, da die Arten von Datenquellen die Arten von Funktionen bestimmen, die ein Data Science-Spezialist aus den Quelldaten erhalten kann:

  • ( Snowflake Redshift) ( ). , , « ».
  • ( MongoDB MySQL) . , 24 .
  • ( Kafka) ( ). . , « 30 ».
  • Vorhersageabfragedaten sind die Anfangsdaten von Ereignissen, die unmittelbar vor der Erstellung einer ML-Prognose in Echtzeit auftreten, z. B. eine Abfrage, die der Benutzer gerade in die Suchleiste eingegeben hat. Selbst wenn solche Daten begrenzt sind, sind sie oft so „frisch“ wie möglich und enthalten ein leicht vorhersehbares Signal. Solche Daten werden mit einer Vorhersageanforderung geliefert und können in Echtzeitberechnungen verwendet werden, z. B. zum Suchen nach Ähnlichkeitsschätzungen zwischen der Suchabfrage eines Benutzers und Dokumenten in einem Sucharray.

Mit Blick auf die Zukunft machen wir darauf aufmerksam: Durch die Kombination von Daten aus verschiedenen Quellen mit komplementären Merkmalen können Sie wirklich gute Funktionen erstellen. Ein solcher Ansatz erfordert die Implementierung und Verwaltung fortgeschrittener Transformationen von Funktionen.

Testdatum Nr. 3: Kombinieren von Funktionen zu Trainingsdaten


Die Bildung von Trainings- oder Testdatensätzen erfordert die Kombination der Daten der entsprechenden Funktionen. In diesem Fall müssen viele Details verfolgt werden, die kritische Auswirkungen auf das Modell haben können. Die zwei heimtückischsten sind:

  • Datenverlust: Data-Science-Spezialisten müssen sicherstellen, dass ihr Modell auf die richtigen Informationen trainiert wird, und dürfen nicht zulassen, dass unerwünschte Informationen in die Trainingsdaten gelangen. Solche Daten können sein: Daten aus einer Testsuite, Daten aus der Grundwahrheit, Daten aus der Zukunft oder Informationen, die wichtige Vorbereitungsprozesse verletzen (z. B. Anonymisierung).
  • : — . ( ). , data science , .

- #4:


Nachdem das Modell in Echtzeit in Betrieb genommen wurde, um korrekte und relevante Prognosen zu erstellen, muss es ständig neue Funktionsdaten bereitstellen - häufig in großem Maßstab und mit minimaler Wartezeit.

Wie sollen wir diese Daten an Modelle weitergeben? Direkt von der Quelle? Das Empfangen und Übertragen von Daten aus dem Speicher kann Minuten, Tage, Stunden oder sogar Tage dauern, was für die Datenausgabe in Echtzeit zu lang ist und daher in den meisten Fällen nicht möglich ist.



In solchen Fällen müssen die Berechnung von Funktionen und der Verbrauch von Funktionen deaktiviert werden. Zur Vorberechnung (Vorberechnung)Funktionen und deren Versand an das für die Lieferung optimierte Produktions-Data-Warehouse sind ETL-Prozesse erforderlich. Diese Prozesse verursachen zusätzliche Schwierigkeiten und erfordern neue Wartungskosten:



Suche nach dem optimalen Kompromiss zwischen Relevanz und Rentabilität: Die Trennung von Berechnung und Verbrauch von Funktionen gibt der Dringlichkeit höchste Priorität. Aufgrund der gestiegenen Kosten können die Funktionsprozesse häufig ausgeführt werden und infolgedessen relevantere Daten erzeugen. Der richtige Kompromiss variiert je nach Funktion und Anwendungsfall. Beispielsweise ist die Aggregationsfunktion eines 30-minütigen endgültigen Rechnungsfensters für die Lieferung sinnvoll, wenn sie häufiger aktualisiert wird als eine ähnliche Funktion mit einem zweiwöchigen endgültigen Rechnungsfenster.



Integration von Funktionsprozessen:Um die Produktion von Funktionen zu beschleunigen, müssen Daten aus verschiedenen Quellen abgerufen werden. Daher ist die Lösung der damit verbundenen Probleme komplizierter als bei der Arbeit mit nur einer Datenquelle, die wir zuvor erörtert haben. Die Koordination solcher Prozesse und die Integration ihrer Ergebnisse in einen einzigen Funktionsvektor erfordert einen ernsthaften Ansatz der Datenentwicklung.



Verhinderung von Verzerrungen im Training ( Training / Serving-Skew ):Diskrepanzen zwischen Lernergebnissen und Arbeitsprozessen können zu Lernverzerrungen führen. Verzerrungen während des Trainings sind ziemlich schwer zu erkennen, und ihre Anwesenheit kann die Modellvorhersagen unbrauchbar machen. Das Modell kann sich chaotisch verhalten, wenn Schlussfolgerungen auf der Grundlage von Daten gezogen werden, die anders generiert wurden als die, auf denen es trainiert wurde. An sich verdient das Thema Verzerrung und die Arbeit mit ihnen eine separate Artikelserie. Es lohnt sich jedoch, zwei typische Risiken hervorzuheben:

  • : ( ) , . Null? ? . .


. 7 ,

  • ́ : - ( ). , , , . , , . — , , , .


Feige. 8: Die Grafik zeigt die endgültige Auftragsabrechnung: Auf (1) werden die Werte der Funktion angezeigt, die für die Prognose ausgegeben und alle 10 Minuten aktualisiert wurden. on (2) werden Trainingsdaten angezeigt, die die wahren Werte im Vergleich zu den für die Produktion ausgegebenen Funktionen viel deutlicher falsch anzeigen

Testdatum Nr. 5: Nachverfolgung von Funktionen in der Produktion


Trotz aller Versuche, die oben genannten Probleme richtig zu umgehen, wird etwas kaputt gehen. Wenn ein ML-System abstürzt, geschieht dies fast immer aufgrund einer „Verletzung der Datenintegrität“. Dieser Begriff kann viele verschiedene Gründe angeben, für die jeweils eine Nachverfolgung erforderlich ist. Beispiele für Verstöße gegen die Datenintegrität:

  • : , , . , , . , .
  • : , . , , (, ), .
  • : . , (, , ) .
  • Unklare Verantwortung für die Datenqualität: Wer ist letztendlich für die Qualität der Funktion verantwortlich, wenn Funktionen Quelldaten von verschiedenen Verteilungsquellen empfangen können? Der Data-Science-Spezialist, der die Funktion erstellt hat? Datenwissenschaftler, der das Modell trainiert hat? Besitzer des Datenfeed-Kanals? Der Programmierer, der die Integration des Modells in die Produktion durchgeführt hat? In Fällen, in denen die Verantwortlichkeiten unklar sind, bleiben Probleme zu lange ungelöst.

Solche Tests bilden selbst für die fortschrittlichsten Teams auf dem Gebiet der Datenwissenschaft und der ML-Technik einen nahezu unüberwindbaren Hindernislauf. Um sie zu lösen, ist etwas Besseres erforderlich als der unveränderte Status Quo der meisten Unternehmen, wenn individuelle, maßgeschneiderte Lösungen die einzige Antwort auf eine Teilmenge dieser Probleme bleiben.

Einführung in Tecton: Eine Plattform für maschinelles Lernen mit Datum


Bei Tecron schaffen wir eine Datumsplattform für maschinelles Lernen, um Unterstützung bei den häufigsten und schwierigsten Problemen im Bereich der Datenwissenschaft zu bieten.

Auf hohem Niveau hat die Tecron-Plattform:

  1. Funktionsprozesse , um Ihre Quelldaten in Funktionen und Beschriftungen umzuwandeln
  2. Funktions-Repository zum Speichern archivierter Funktions- und Tag-Daten
  3. Funktionsserver zur Ausgabe der neuesten Funktionswerte an die Produktion
  4. SDK zum Trainieren von Daten und zur Manipulation von Funktionsprozessen
  5. Web-Benutzeroberfläche zum Überwachen und Verfolgen von Funktionen, Beschriftungen und Datensätzen
  6. Überwachungs-Engine zum Ermitteln von Datenqualitäts- oder Driftproblemen und Warnungen



Feige. 9: Als zentrale Datenplattform für ML bietet Tecton Funktionen in Entwicklungsumgebungen und in der Produktion.

Mit dieser Plattform können ML-Teams DevOps-Praktiken auf ML-Daten übertragen:



  • Planung: Tecron-Funktionen werden in einem zentralen Repository gespeichert. Auf diese Weise können Data-Science-Spezialisten die Arbeiten des anderen teilen, finden und nutzen.
  • Code: Mit Tecton können Benutzer einfache und flexible Funktionstransformationsprozesse einrichten.
  • Build: Tecton kompiliert Funktionen zu leistungsstarken Datenverarbeitungsaufgaben.
  • Testen: Tecton unterstützt Funktions- und Integrationstests von Funktionen.
  • Release: Tecton integriert sich eng in Git. Alle Funktionsbeschreibungen haben Versionskontrolle und sind einfach zu reproduzieren.
  • : Tecton ( Spark). Tecron.
  • : Tecton data science , .
  • : Tecton .

Natürlich bieten ML-Daten ohne ML-Modell keine praktische Implementierung von ML. Daher bietet Tecton flexible APIs und lässt sich in vorhandene ML-Plattformen integrieren. Wir haben mit Databricks, SageMaker und Kuberflow begonnen und integrieren uns weiterhin in komplementäre Ökosystemkomponenten.

More articles:


All Articles