Die Self-Service-Daten-Roadmap

Kapitel 4. Feature Store Service

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Bisher haben wir die verfügbaren Datensätze und Artefakte entdeckt, die zur Gewinnung der benötigten Erkenntnisse genutzt werden können. Im Falle von ML-Modellen gibt es einen zusätzlichen Schritt, nämlich die Ermittlung von Merkmalen. Ein Modell zur Umsatzprognose, das trainiert werden muss, benötigt zum Beispiel die bisherigen Umsatzzahlen nach Markt, Produktlinie usw. als Input. Ein Merkmal ist ein Datenattribut, das entweder direkt extrahiert oder durch Berechnung aus einer oder mehreren Datenquellen abgeleitet werden kann - z. B. das Alter einer Person, eine von einem Sensor ausgegebene Koordinate, ein Wort aus einem Text oder ein Gesamtwert wie die durchschnittliche Anzahl der Einkäufe innerhalb der letzten Stunde. Historische Werte des Datenattributs sind erforderlich, um ein Merkmal in ML-Modellen zu verwenden.

Datenwissenschaftler verbringen einen großen Teil ihrer Zeit mit der Erstellung von Trainingsdatensätzen für ML-Modelle. Der Aufbau von Datenpipelines zur Generierung von Merkmalen für das Training und für die Inferenz ist ein erhebliches Problem. Erstens müssen Data Scientists Low-Level-Code für den Zugriff auf Datenspeicher schreiben, was Data-Engineering-Kenntnisse erfordert. Zweitens gibt es für die Pipelines zur Generierung dieser Merkmale mehrere Implementierungen, die nicht immer einheitlich sind, d. h. es gibt separate Pipelines für das Training und die Inferenz. Drittens wird der Code der Pipeline in allen ML-Projekten dupliziert und ist nicht wiederverwendbar, da er in die Modellimplementierung eingebettet ist. Schließlich gibt es kein Änderungsmanagement und keine Kontrolle über die Funktionen. Diese Aspekte wirken sich auf die Gesamtzeit bis zur Erkenntnis aus. Dies gilt vor allem deshalb, weil die Datennutzer in der Regel nicht über die technischen Fähigkeiten verfügen, um robuste Pipelines zu entwickeln und sie in der Produktion zu überwachen. Außerdem werden Feature-Pipelines immer wieder von Grund auf neu erstellt, anstatt sie über ML-Projekte hinweg gemeinsam zu nutzen. Der Aufbau von ML-Modellen ist ein iterativer Prozess und erfordert das Ausprobieren verschiedener Merkmalskombinationen.

Idealerweise sollte ein Feature Store Service gut dokumentierte, kontrollierte, versionierte und kuratierte Features für das Training und die Inferenz von ML-Modellen bereitstellen (wie in Abbildung 4-1 dargestellt). Datennutzer sollten in der Lage sein, Features zu suchen und zu nutzen, um Modelle mit minimalem Data Engineering zu erstellen. Die Implementierungen der Feature-Pipeline für das Training und die Inferenz sind einheitlich. Darüber hinaus werden die Merkmale zwischengespeichert und in allen ML-Projekten wiederverwendet, was die Trainingszeit und die Kosten für die Infrastruktur reduziert. Die Erfolgskennzahl dieses Dienstes ist die Zeit für die Featurisierung. Je mehr Merkmale der Feature Store Service enthält, desto mehr Skaleneffekte werden erzielt, da die Erstellung neuer Modelle einfacher und schneller wird.

Abbildung 4-1. Der Merkmalsspeicher ist das Repository für Merkmale, die für das Training und die Inferenz von Modellen über mehrere Datenprojekte hinweg verwendet werden.

Reisekarte

Die Entwicklung und Verwaltung von Merkmalen ist ein wichtiger Bestandteil der Entwicklung von ML-Modellen. Oft haben Datenprojekte einen gemeinsamen Satz von Merkmalen, so dass dieselben Merkmale wiederverwendet werden können. Eine höhere Anzahl von Merkmalen senkt die Kosten für die Implementierung neuer Datenprojekte (siehe Abbildung 4-2). Es gibt viele Überschneidungen bei den Merkmalen zwischen den Projekten. In diesem Abschnitt werden die wichtigsten Szenarien in der Journey Map für den Feature Store Service erläutert.

Abbildung 4-2. Der Zeit- und Arbeitsaufwand für neue Datenprojekte sinkt, wenn die Anzahl der verfügbaren Features im Feature Store wächst.

Verfügbare Funktionen finden

In der Explorationsphase suchen die Datenwissenschaftler nach verfügbaren Merkmalen, die für die Erstellung des ML-Modells genutzt werden können. Das Ziel dieser Phase ist die Wiederverwendung von Merkmalen und die Reduzierung der Kosten für die Erstellung des Modells. Dabei wird analysiert, ob die verfügbaren Merkmale von guter Qualität sind und wie sie derzeit genutzt werden. Da es kein zentrales Feature-Repository gibt, überspringen Data Scientists oft die Suchphase und entwickeln Ad-hoc-Trainingspipelines, die mit der Zeit immer komplexer werden. Wenn die Zahl der Modelle steigt, wird daraus schnell ein schwer zu bewältigender Pipeline-Dschungel.

Erzeugung von Trainingssätzen

Bei der Modellschulung werden Datensätze benötigt, die aus einem oder mehreren Merkmalen bestehen, um das Modell zu trainieren. Der Trainingssatz, der die historischen Werte dieser Merkmale enthält, wird zusammen mit einem Vorhersage-Label erstellt. Der Trainingssatz wird vorbereitet, indem Abfragen geschrieben werden, die die Daten aus den Datenquellen extrahieren und die historischen Datenwerte der Merkmale umwandeln, bereinigen und erzeugen. Die Entwicklung des Trainingssets nimmt viel Zeit in Anspruch. Außerdem muss die Merkmalsmenge ständig mit neuen Werten aktualisiert werden (ein Prozess, der als Backfilling bezeichnet wird). Mit einem Merkmalspeicher sind die Trainingsdatensätze für die Merkmale bereits während der Erstellung der Modelle verfügbar.

Feature Pipeline für Online-Inferenz

Bei der Modellinferenz werden die Merkmalswerte als Eingabe für das Modell bereitgestellt, das dann die vorhergesagte Ausgabe erzeugt. Die Pipeline-Logik für die Generierung von Merkmalen während der Inferenz sollte mit der Logik übereinstimmen, die während des Trainings verwendet wurde, sonst sind die Modellvorhersagen falsch. Neben der Pipeline-Logik ist eine weitere Anforderung eine niedrige Latenzzeit, um die Merkmale für das Inferencing in Online-Modellen zu erzeugen. Heutzutage sind die in die ML-Pipeline eingebetteten Feature-Pipelines nicht einfach wiederverwendbar. Außerdem werden Änderungen in der Trainings-Pipeline-Logik möglicherweise nicht korrekt mit den entsprechenden Modell-Inferenz-Pipelines koordiniert.

Minimiere die Zeit bis zur Fertigstellung

Der Zeitaufwand für die Feature-Erstellung ist die Zeit, die für die Erstellung und Verwaltung von Features aufgewendet wird. Heutzutage wird der Zeitaufwand grob in zwei Kategorien unterteilt: Feature-Berechnung und Feature-Verwaltung. Die Feature-Berechnung umfasst Datenpipelines zur Erzeugung von Features sowohl für das Training als auch für die Inferenz. Das Feature-Serving konzentriert sich auf die Bereitstellung großer Datensätze während des Trainings, auf Feature-Werte mit geringer Latenz für die Modellinferenz und darauf, den Datennutzern die Suche nach und die Zusammenarbeit mit den Features zu erleichtern.

Berechnung von Merkmalen

Die Merkmalsberechnung ist der Prozess der Umwandlung von Rohdaten in Merkmale. Dazu müssen Datenpipelines aufgebaut werden, um historische Trainingswerte des Merkmals sowie aktuelle Merkmalswerte für die Modellinferenz zu erzeugen. Die Trainingsdatensätze müssen kontinuierlich mit neueren Stichproben aufgefüllt werden. Bei der Berechnung von Merkmalen gibt es zwei große Herausforderungen .

Erstens ist die Verwaltung des Pipeline-Dschungels komplex. Pipelines extrahieren die Daten aus den Quelldatenspeichern und wandeln sie in Features um. Diese Pipelines haben mehrere Transformationen und müssen mit den Eckfällen umgehen, die in der Produktion auftreten. Diese im Produktionsmaßstab zu verwalten, ist ein Albtraum. Außerdem wächst die Anzahl der Merkmalsdaten immer weiter an, vor allem bei Deep Learning-Modellen. Die Verwaltung großer Datensätze in großem Maßstab erfordert Optimierungen in der verteilten Programmierung für Skalierung und Leistung. Insgesamt ist der Aufbau und die Verwaltung von Datenpipelines in der Regel einer der zeitaufwändigsten Teile der Gesamtzeit bis zur Erkenntnis der Modellerstellung.

Zweitens werden getrennte Pipelines für das Training und die Inferenz für ein bestimmtes Merkmal geschrieben. Das liegt daran, dass es unterschiedliche Anforderungen an die Aktualität der Daten gibt, da die Modellschulung in der Regel Batch-orientiert ist, während die Modellinferenz im Streaming-Verfahren mit nahezu Echtzeit-Latenz erfolgt. Diskrepanzen bei der Berechnung von Trainings- und Inferenzpipelines sind ein Hauptgrund für Probleme mit der Modellkorrektheit und ein Albtraum bei der Fehlersuche im Produktionsmaßstab.

Merkmal Servieren

Beim Feature-Serving geht es darum, Feature-Werte in großen Mengen für das Training und mit geringer Latenz für die Inferenz bereitzustellen. Dazu müssen die Merkmale leicht zu finden sein und mit anderen vorhandenen Merkmalen verglichen und analysiert werden können. In einem typischen Großeinsatz unterstützt das Feature Serving Tausende von Modellinferenzen. Die Skalierung der Leistung ist eine der wichtigsten Herausforderungen, ebenso wie die Vermeidung von doppelten Merkmalen angesichts der schnellen Erkundung von Datennutzern in Hunderten von Modell-Permutationen während des Prototyping.

Heutzutage besteht eines der häufigsten Probleme darin, dass das Modell im Trainingsdatensatz gut abschneidet, in der Produktion aber nicht. Dafür kann es mehrere Gründe geben, aber das Hauptproblem wird als Label Leakage bezeichnet. Dies ist darauf zurückzuführen, dass für die Merkmale des Modells falsche Zeitpunkte verwendet werden. Es ist schwierig, die richtigen Werte für die Merkmale zu finden. Zur Veranschaulichung zeigen Zanoyan et al. ein Beispiel in Abbildung 4-3. Sie zeigt die Merkmalswerte, die im Training für die Vorhersage zum Zeitpunkt T1 ausgewählt wurden. Es sind drei Merkmale dargestellt: F1, F2, F3. Für die Vorhersage P1 müssen die Merkmalswerte 7, 3 und 8 für die Trainingsmerkmale F1, F2 bzw. F3 ausgewählt werden. Wenn stattdessen die Merkmalswerte nach der Vorhersage verwendet werden (z. B. der Wert 4 für F1), kommt es zu einem Leck in den Merkmalen, da der Wert das potenzielle Ergebnis der Vorhersage darstellt und fälschlicherweise eine hohe Korrelation während des Trainings anzeigt.

Abbildung 4-3. Die Auswahl der richtigen Zeitpunktwerte für die Merkmale F1, F2 und F3 während des Trainings für die Vorhersage P1. Das tatsächliche Ergebnis Label L wird für das Training des überwachten ML-Modells bereitgestellt.

Anforderungen definieren

Der Feature Store ist ein zentraler Speicher für Merkmale, der sowohl die historischen Werte von Merkmalen über lange Zeiträume wie Wochen oder Monate als auch zeitnahe Werte von Merkmalen über mehrere Minuten bereitstellt. Die Anforderungen eines Merkmalspeichers werden in Merkmalsberechnung und Merkmalsbereitstellung unterteilt.

Berechnung von Merkmalen

Die Berechnung von Merkmalen erfordert eine tiefe Integration mit dem Data Lake und anderen Datenquellen. Es gibt drei Dimensionen, die bei der Berechnung von Merkmalen zu berücksichtigen sind.

Betrachten wir zunächst die verschiedenen Arten von Merkmalen, die unterstützt werden sollen. Merkmale können mit einzelnen Datenattributen verbunden sein oder zusammengesetzte Aggregate darstellen. Außerdem können Merkmale relativ statisch sein und sich nicht ständig im Verhältnis zur nominalen Zeit ändern. Die Berechnung von Merkmalen erfordert in der Regel mehrere primitive Funktionen, die vom Merkmalsspeicher unterstützt werden müssen, ähnlich den Funktionen, die derzeit von Datennutzern verwendet werden, wie z. B.:

• Umwandlung kategorischer Daten in numerische Daten

• Daten normalisieren, wenn die Merkmale aus unterschiedlichen Verteilungen stammen

• One-Hot-Codierung oder Merkmalsbinarisierung

• Feature Binning (z. B. Umwandlung von kontinuierlichen Merkmalen in diskrete Merkmale)

• Hashing von Merkmalen (z. B. um den Speicherbedarf von einmalig kodierten Merkmalen zu reduzieren )

• Berechnung von Aggregatmerkmalen (z. B. Anzahl, Min, Max und Stdev)

Zweitens solltest du die Programmierbibliotheken berücksichtigen, die für das Feature Engineering unterstützt werden müssen. Spark wird von Nutzern, die mit großen Datensätzen arbeiten, für die Datenverarbeitung bevorzugt. Nutzer, die mit kleinen Datenmengen arbeiten, bevorzugen Frameworks wie NumPy und Pandas. Feature-Engineering-Aufträge werden mit Hilfe von Notebooks, Python-Dateien oder .jar-Dateien erstellt und auf Berechnungsframeworks wie Samza, Spark, Flink und Beam ausgeführt.

Drittens musst du die Quellsysteme berücksichtigen, in denen die Merkmalsdaten gespeichert sind. Bei den Quellsystemen kann es sich um eine Reihe von relationalen Datenbanken, NoSQL-Datenspeichern, Streaming-Plattformen sowie Datei- und Objektspeichern handeln.

Merkmal Servieren

Ein Feature Store muss eine gute Zusammenarbeit ermöglichen. Features sollten so definiert und erstellt werden, dass sie von allen Teams gemeinsam genutzt werden können.

Merkmal Gruppen

Ein Merkmalsspeicher hat zwei Schnittstellen: das Schreiben von Merkmalen in den Speicher und das Lesen von Merkmalen für das Training und die Inferenz. Die Merkmale werden normalerweise in eine Datei oder eine projektspezifische Datenbank geschrieben. Die Merkmale können weiter gruppiert werden, wenn sie von demselben Verarbeitungsauftrag oder aus demselben Rohdatensatz berechnet werden. Bei einem Mitfahrdienst wie Uber können zum Beispiel alle fahrtenbezogenen Merkmale für eine geografische Region als eine Merkmalsgruppe verwaltet werden, da sie alle von einem Auftrag berechnet werden können, der die Fahrtenhistorie durchsucht. Die Merkmale können mit Bezeichnungen (im Falle des überwachten Lernens) verknüpft und zu einem Trainingsdatensatz zusammengefasst werden. Merkmalsgruppen haben in der Regel eine gemeinsame Spalte, z. B. einen Zeitstempel oder eine Kunden-ID, die es ermöglicht, Merkmalsgruppen zu einem Trainingsdatensatz zusammenzufassen. Der Feature Store erstellt und verwaltet den Trainingsdatensatz, der als TFRecords, Parquet, CSV, TSV, HDF5 oder .npy-Dateien gespeichert wird.

Skalierung

In Bezug auf die Skalierung gibt es einige Aspekte zu beachten:

• Die Anzahl der Features, die im Feature Store unterstützt werden sollen

• Die Anzahl der Modelle, die den Feature Store für Online-Inferenzen aufrufen

• Die Anzahl der Modelle für die tägliche Offline-Inferenz sowie für das Training

• Die Menge der historischen Daten, die in die Trainingsdatensätze aufgenommen werden

• Die Anzahl der täglichen Pipelines zum Auffüllen der Merkmalsdatensätze, wenn neue Stichproben erzeugt werden

Darüber hinaus gibt es spezielle Anforderungen an die Leistungsskalierung für die Online-Modellinferenz, z. B. die TP99-Latenzzeit für die Berechnung des Merkmalswerts. Bei der Online-Schulung muss die Zeit berücksichtigt werden, die für das Auffüllen der Trainingssätze und für DB-Schema-Mutationen benötigt wird. In der Regel müssen historische Merkmale weniger als 12 Stunden alt sein und echtzeitnahe Merkmalswerte weniger als 5 Minuten alt sein.

Analyse der Merkmale

Merkmale sollten durchsuchbar und leicht verständlich sein, damit sie in allen ML-Projekten wiederverwendet werden können. Datennutzer müssen in der Lage sein, die Transformationen zu identifizieren und die Merkmale zu analysieren, um Ausreißer, Verteilungsdrift und Merkmalskorrelationen zu finden.

Nichtfunktionale Anforderungen

Ähnlich wie bei jedem Softwaredesign gibt es einige der wichtigsten NFRs, die bei der Entwicklung eines Feature-Store-Dienstes berücksichtigt werden sollten:

Automatisierte Überwachung und Alarmierung

Der Zustand des Dienstes sollte leicht zu überwachen sein. Bei Problemen in der Produktion sollten automatische Warnungen ausgegeben werden.

Reaktionszeiten

Es ist wichtig, dass der Dienst auf Suchanfragen in der Größenordnung von Millisekunden reagiert.

Intuitive Schnittstelle

Damit der Feature-Store-Dienst effektiv ist, muss er von allen Datennutzern innerhalb des Unternehmens angenommen werden. Daher ist es wichtig, dass die APIs, CLIs und das Webportal einfach zu bedienen und zu verstehen sind.

Muster für die Umsetzung

Entsprechend der bestehenden Aufgabenkarte gibt es zwei Automatisierungsstufen für den Feature Store Service (siehe Abbildung 4-4). Jede Stufe entspricht der Automatisierung einer Kombination von Aufgaben, die derzeit entweder manuell oder ineffizient sind:

Hybrides Berechnungsmuster für Merkmale

Definiert das Muster für die Kombination von Batch- und Stream-Verarbeitung zur Berechnung von Merkmalen.

Muster für die Registrierung von Merkmalen

Legt das Muster fest, das als Merkmal für das Training und die Inferenz dient.

Abbildung 4-4. Die verschiedenen Automatisierungsebenen für den Feature Store Service.

Feature-Store-Dienste werden immer beliebter: Uber's Michelangelo, Airbnb's Zipline, Gojek's Feast, Comcast's Applied AI, Logical Clock's Hopsworks, Netflix's Fact Store und Pinterest's Galaxy sind einige der populären Open Source Beispiele für einen Feature Store Service. Eine gute Liste mit neuen Feature Stores findest du unter featurestore.org. Aus architektonischer Sicht gibt es bei jeder dieser Implementierungen zwei wichtige Bausteine: die Berechnung von Features und die Bereitstellung.

Hybrides Berechnungsmuster für Merkmale

Das Modul für die Merkmalsberechnung muss zwei Arten von ML-Szenarien unterstützen:

• Offline-Training und -Schlussfolgerungen, bei denen historische Massendaten im Stundenrhythmus berechnet werden

• Online-Training und -Schlussfolgerungen, bei denen die Merkmalswerte alle paar Minuten berechnet werden

Bei der hybriden Merkmalsberechnung gibt es drei Bausteine (wie in Abbildung 4-5 dargestellt):

Batch Compute Pipeline

Die herkömmliche Batch-Verarbeitung läuft als ETL-Auftrag alle paar Stunden oder täglich, um historische Merkmalswerte zu berechnen. Die Pipeline ist für die Ausführung in großen Zeitfenstern optimiert .

Streaming Compute Pipeline

Streaming-Analysen werden auf Datenereignisse in einem Echtzeit-Nachrichtenbus angewendet, um Merkmalswerte mit geringer Latenz zu berechnen. Die Merkmalswerte werden in die historischen Massendaten aus der Batch-Pipeline eingefügt.

Merkmal Spezifikation

Um Konsistenz zu gewährleisten, erstellen die Datennutzer keine Pipelines für neue Merkmale, sondern definieren eine Merkmalsspezifikation in einer domänenspezifischen Sprache (DSL). In der Spezifikation werden die Datenquellen und Abhängigkeiten sowie die für die Erstellung des Merkmals erforderliche Transformation angegeben. Die Spezifikation wird automatisch in Batch- und Streaming-Pipelines umgewandelt. Dadurch wird die Konsistenz des Pipeline-Codes für das Training und die Inferenz sichergestellt, ohne dass der Nutzer eingreifen muss.

Abbildung 4-5. Parallele Pipelines in der hybriden Merkmalsberechnungsstruktur.

Ein Beispiel für ein hybrides Berechnungsmuster ist Michelangelo von Uber. Es implementiert eine Kombination aus Apache Spark und Samza. Spark wird für die Berechnung von Batch-Features verwendet und die Ergebnisse werden in Hive gespeichert. Batch-Aufträge berechnen Feature-Gruppen und schreiben sie in eine einzelne Hive-Tabelle als ein Feature pro Spalte. Uber Eats (der Essenslieferdienst von Uber) verwendet die Batch-Pipeline zum Beispiel für Features wie die durchschnittliche Zubereitungszeit eines Restaurants in den letzten sieben Tagen. Bei der Streaming-Pipeline werden Kafka-Themen mit Samza-Streaming-Aufträgen verarbeitet, um nahezu in Echtzeit Merkmalswerte zu generieren, die in Cassandra im Schlüsselwertformat gespeichert werden. Die Vorberechnung und das Laden von historischen Merkmalen erfolgt regelmäßig von Hive nach Cassandra. Uber Eats zum Beispiel nutzt die Streaming-Pipeline für Merkmale wie die durchschnittliche Zubereitungszeit der letzten Stunde in einem Restaurant. Die Merkmale werden mithilfe einer DSL definiert, die die Merkmale auswählt, umwandelt und kombiniert, die zu den Trainings- und Vorhersagezeiten an das Modell gesendet werden. Die DSL ist als Untermenge von Scala implementiert, einer rein funktionalen Sprache mit einem vollständigen Satz häufig verwendeter Funktionen. Datennutzer haben außerdem die Möglichkeit, ihre eigenen benutzerdefinierten Funktionen hinzuzufügen .

Die Stärken des hybriden Berechnungsmusters für Merkmale:

• Sie bietet eine optimale Leistung der Merkmalsberechnung über Batch- und Streaming-Zeitfenster hinweg.

• Die DSL für die Definition von Merkmalen vermeidet Inkonsistenzen, die mit Diskrepanzen in der Pipeline-Implementierung für Training und Inferenz verbunden sind.

Schwäche des hybriden Merkmalsberechnungsmusters:

• Das Muster ist nicht trivial in der Produktion zu implementieren und zu verwalten. Es setzt voraus, dass die Datenplattform schon ziemlich ausgereift ist.

Das hybride Berechnungsmuster für Merkmale ist ein fortschrittlicher Ansatz für die Berechnung von Merkmalen, der sowohl für Batch als auch für Streaming optimiert ist. Programmiermodelle wie Apache Beam führen die Grenzen zwischen Batch und Streaming zunehmend zusammen.

Feature Registry Pattern

Das Feature-Registry-Muster stellt sicher, dass es einfach ist, Features zu entdecken und zu verwalten. Außerdem ist es leistungsfähig bei der Bereitstellung der Merkmalswerte für Online-/Offline-Training und Inferenz. Die Anforderungen für diese Anwendungsfälle sind sehr unterschiedlich, wie Li et al. festgestellt haben. Für Batch-Training und Inferenz ist ein effizienter Massenzugriff erforderlich. Für die Echtzeitvorhersage ist ein Zugriff mit niedriger Latenz pro Datensatz erforderlich. Ein einziger Speicher ist aus folgenden Gründen nicht optimal für historische und echtzeitnahe Merkmale: a) Datenspeicher sind entweder für punktuelle Abfragen oder für den Massenzugriff effizient, aber nicht für beides, und b) häufiger Massenzugriff kann sich negativ auf die Latenz von punktuellen Abfragen auswirken, so dass sie nur schwer nebeneinander bestehen können. Unabhängig vom Anwendungsfall werden die Merkmale über kanonische Namen identifiziert.

Für die Feature-Erkennung und -Verwaltung ist das Feature-Registry-Muster die Benutzerschnittstelle für die Veröffentlichung und Erkennung von Features und Trainingsdatensätzen. Das Feature Registry Pattern dient auch als Werkzeug, um die Entwicklung von Features im Laufe der Zeit zu analysieren, indem es Feature-Versionen vergleicht. Zu Beginn eines neuen Data-Science-Projekts durchsuchen Data Scientists in der Regel die Feature Registry nach verfügbaren Features und fügen nur neue Features hinzu, die noch nicht im Feature Store für ihr Modell vorhanden sind.

Das Feature Registry Pattern besteht aus den folgenden Bausteinen:

Merkmalswerte speichern

Speichert die Merkmalswerte. Gängige Lösungen für Massenspeicher sind Hive (verwendet von Uber und Airbnb), S3 (verwendet von Comcast) und Google BigQuery (verwendet von Gojek). Für Online-Daten wird normalerweise ein NoSQL-Speicher wie Cassandra verwendet.

Feature Registry Store

Speichert den Code für die Berechnung von Features, Feature-Versionsinformationen, Feature-Analysedaten und die Feature-Dokumentation. Die Feature-Registry bietet eine automatische Feature-Analyse, die Verfolgung von Feature-Abhängigkeiten, die Verfolgung von Feature-Jobs, eine Feature-Datenvorschau und eine Stichwortsuche in den Metadaten von Features, Feature-Gruppen und Trainingsdatensätzen.

Ein Beispiel für das Feature Registry Pattern ist der Hopsworks Feature Store. Nutzer/innen fragen den Feature Store per SQL oder programmatisch ab und der Feature Store gibt die Features als Datenrahmen zurück (wie in Abbildung 4-6 dargestellt). Feature-Gruppen und Trainingsdatensätze im Hopsworks-Feature-Store sind mit Spark/NumPy/pandas-Aufträgen verknüpft, wodurch die Features bei Bedarf reproduziert und neu berechnet werden können. Zusätzlich zu einer Feature-Gruppe oder einem Trainingsdatensatz führt der Feature Store einen Datenanalyseschritt durch, bei dem eine Clusteranalyse der Feature-Werte, eine Feature-Korrelation, Feature-Histogramme und deskriptive Statistiken betrachtet werden. Mit Hilfe von Feature-Korrelationsinformationen können beispielsweise redundante Features identifiziert werden, mit Feature-Histogrammen können Feature-Verteilungen zwischen verschiedenen Versionen eines Features überwacht werden, um Kovariatenverschiebungen zu entdecken, und mit der Clusteranalyse können Ausreißer erkannt werden. Der Zugriff auf solche Statistiken in der Feature-Registry hilft den Nutzern bei der Entscheidung, welche Features sie verwenden wollen.

Abbildung 4-6. Benutzerabfragen an den Feature Store erzeugen Datenrahmen (in gängigen Formaten, nämlich Pandas, NumPy oder Spark) (aus der Hopsworks-Dokumentation).

Die Stärken des Feature-Registers:

• Es bietet eine leistungsstarke Bereitstellung von Trainingsdatensätzen und Merkmalswerten

• Es reduziert die Zeit für die Merkmalsanalyse für Datennutzer

Schwachstellen des Feature-Registers:

• Der potenzielle Leistungsengpass bei der Bedienung von Hunderten von Modellen

• Skalierung für kontinuierliche Merkmalsanalysen mit einer wachsenden Anzahl von Merkmalen

Zusammenfassung

Heute gibt es keine prinzipielle Möglichkeit, während des Modells und des Trainings auf Merkmale zuzugreifen. Merkmale können nicht einfach zwischen verschiedenen ML-Pipelines wiederverwendet werden, und ML-Projekte arbeiten isoliert ohne Zusammenarbeit und Wiederverwendung. Da die Merkmale tief in die ML-Pipelines eingebettet sind, gibt es keine Möglichkeit, genau zu bestimmen, welche Merkmale neu berechnet werden müssen, wenn neue Daten eintreffen; vielmehr muss die gesamte ML-Pipeline zur Aktualisierung der Merkmale ausgeführt werden. Ein Feature Store behebt diese Probleme und ermöglicht Skaleneffekte bei der Entwicklung von ML-Modellen.