Download Now
O'Reilly's Book "Building ML Systems" First Chapter Available!
.svg){kind=small}
Der Feature Store ist ein Data Warehouse mit Features für maschinelles Lernen (ML). Architektonisch unterscheidet es sich vom traditionellen Data Warehouse dadurch, dass es sich um eine duale Datenbank handelt, wobei eine Datenbank (zeilenorientiert) Funktionen mit geringer Latenz für Online-Anwendungen bereitstellt und die andere Datenbank (spaltenorientiert) große Mengen an verwendeten Funktionen speichert. Letztere werden einerseits von Data Scientists zum Erstellen von Trainings-/Testdatensätzen verwendet und andererseits von Batch-Anwendungen benutzt, um Offline-Modellbewertungen durchzuführen.
Data Warehouses demokratisierten einst den Zugriff auf Unternehmensdaten, indem sie Daten auf einer einzigen Plattform zentralisierten und dann Geschäftsanalysten mit visuellen Tools wie Tableau und Power BI ausstatteten. Für Analysten war es dementsprechend nicht mehr länger notwendig zu wissen, wo sich die Daten befanden und wie diese abzufragen seien. Mithilfe von BI-Tools konnten sie historische Einblicke in das Unternehmen gewinnen.
Heutzutage erstellen Data Scientists hingegen Vorhersagemodelle, um geschäftliche Erkenntnisse abzuleiten. Der Feature Store ist das Data Warehouse für Data Science – es ist ein zentraler Tresor zum Speichern dokumentierter, kuratierter und zugriffsgesteuerter Features, die in vielen verschiedenen Modellen verwendet werden können. Der Feature Store nimmt Daten aus den vielen verschiedenen Quellen des Unternehmens auf, nachdem er die Daten transformiert, aggregiert und validiert hat.
Ein Feature Store benötigt daher sogenannte Feature-Pipelines, um sicherzustellen, dass Daten zuverlässig aus vorhandenen Quellen fließen und in einem Format verfügbar sind, das bereit ist, von ML-Modellen verwendet zu werden.
Die meisten Data Scientists haben derzeit keinen Feature Store. Sie verbringen die meiste Zeit damit, Daten zu suchen, zu bereinigen und zu kennzeichnen. Daher das (sehr reale) Klischee, dass 80 % der Datenwissenschaft aus Datengerangel besteht. Data Scientists ohne Feature Store arbeiten in einer Ära, die der Arbeitsweise von Business Analysten vor dem Aufkommen von Data Warehouses ähnelt, mit geringer individueller und organisatorischer Produktivität.
Beide Plattformen sind also ein zentraler Speicher für kuratierte Daten, die verwendet werden, um Einblicke in die Daten zu gewinnen. Beide Plattformen verfügen über Pipelines (ETL bzw. Feature-Pipelines), um Daten aus einer oder mehreren unterschiedlichen Quellen (operative Datenbanken, Data Lakes usw.) aufzunehmen.
Weiterhin profitieren beide von Metadatenkatalogen zur Organisation von Datensätzen und Zugriffskontrollen, um Daten nur mit autorisierten Akteuren zu teilen. Sie können so konzipiert werden, dass sie auf standardisierter Hardware skaliert und große Datenmengen speichern können.
Der Hauptunterschied zwischen einem Data Warehouse und einem Feature Store besteht darin, dass das Data Warehouse in der Regel eine einzelne spaltenorientierte Datenbank ist, während der Feature Store in der Regel als zwei Datenbanken implementiert ist:
Der Offline Feature Store stellt üblicherweise große Mengen an Daten effizient bereit, während der Online Feature Store Feature Vektoren mit sehr geringer Latenzzeit (z. B. < 10 ms) zur Verfügung stellt. Beispiele für Datenbanken, die für den Offline-Funktionsspeicher verwendet werden, sind Apache Hive und BigQuery, und Beispiele für Online-Funktionsspeicher sind MySQL Cluster, Redis und DynamoDB.
Beachten Sie, dass Ihre Datenbank oder Anwendung Features zusammenfügen muss, wenn Sie Features in verschiedenen Trainings-/Testdatensätzen für unterschiedliche Modelle wiederverwenden möchten. Dies gilt sowohl für die Offline- als auch für die Online Feature Stores. Wenn Ihr Feature Store das Verbinden von Features nicht unterstützt, d. h. wenn Sie Features nicht über verschiedene Modelle hinweg wiederverwenden, müssen Sie (oder ein System) eine neue Aufnahmepipeline für jedes neue Modell erstellen, das Sie in der Produktion unterstützen.
In der folgenden Tabelle sehen wir einen Überblick über die wichtigsten architektonischen Unterschiede zwischen Feature Stores und Data Warehouses. Data Warehouses werden hauptsächlich von Geschäftsanalysten für interaktive Abfragen und zum Erstellen historischer Berichte/Dashboards über das Unternehmen verwendet. Feature Stores werden sowohl von Datenwissenschaftlern als auch von Online-/Batch-Anwendungen verwendet und mit Daten über Feature-Pipelines versorgt, die normalerweise in Python oder Scala/Java geschrieben werden.
Data Scientists verwenden in der Regel Python-Programme, um Trainings-/Test-Datasets zu erstellen, indem sie vorhandene Features im Feature Store zusammenfügen und die Trainings-/Test-Datasets in einem Dateiformat materialisieren, das am besten für das Framework geeignet ist, in dem sie ihre Modelle trainieren (z. B. TFRecord for TensorFlow, NPY für PyTorch). Data Warehouses und SQL fehlt derzeit die Fähigkeit, Trainings-/Testdatensätze in ML-Dateiformaten zu erstellen.
Die Tabelle zeigt auch die Unterschiede in den gespeicherten Datentypen sowie wie die Art und Weise, wie Daten gespeichert, validiert und abgefragt werden. Ein Data Warehouse speichert Daten in Tabellen zusammen mit Schemata zur Beschreibung des Datentyps und Einschränkungen für Spalten. In ähnlicher Weise speichert der Feature-Speicher typisierte Daten (normalerweise in Tabellen), aber da Features typischerweise als gebrauchsfertige numerische Werte oder Vektoren (Einbettungen) oder Tensoren gespeichert werden, besteht im Vergleich weniger Bedarf an unterschiedlichen Spaltentypen. Fremdschlüsseleinschränkungen werden normalerweise in Feature Stores nicht unterstützt, da es schwierig ist, solche Einschränkungen zwischen Online- und Offline-Stores durchzusetzen.
Da das Modelltraining sehr empfindlich auf fehlerhafte Daten reagiert (Nullwerte und Ausreißer verursachen numerische Instabilität und fehlende Werte), sollten Feature-Daten vor der Aufnahme validiert werden. Datenvalidierungs-Frameworks wie Great Expectations und Deequ helfen bei der Implementierung von Feature-Pipelines, die Prädikate (Datenvalidierungsregeln) auf alle in den Feature-Store aufgenommenen Features anwenden und so eine hohe Datenqualität im Feature-Store sicherstellen.
Domänenspezifische Sprachen (DSL) werden manchmal verwendet, um die Feature-Transformationen, Aggregationen und Datenvalidierungsregeln in Feature-Pipelines zu definieren, aber Allzwecksprachen (Python, Scala) werden häufig verwendet, wenn komplizierteres Feature-Engineering erforderlich ist.
Data Scientists sind einer der Hauptnutzer des Feature Stores. Sie verwenden ein Feature-Repository, um explorative Datenanalysen (EDA) durchzuführen. Diese beinhalten das Suchen nach verfügbaren Features und das Überprüfen von Feature-Werten/Schemata/Statistiken. Data Scientists verwenden hauptsächlich Python, um Funktionen zum Erstellen von Trainings-/Testdatensätzen auszuwählen. Dies beinhaltet in der Regel das Zusammenfügen von Features, um einen Trainings-/Testdatensatz im Dateiformat ihrer Wahl (.tfrecord, .csv, .npy, .petastorm usw.) zu erstellen. Manchmal unterstützen Feature Stores eine DSL (domänenspezifische Sprache), um Trainings-/Testdatensätze oder andere Sprachen wie Scala/Java zu erstellen.
Online-Anwendungen verwenden den Online Feature Store, um Featurewerte mit geringer Latenz abzurufen, um Feature-Vektoren zu erstellen, die für Vorhersagen an Modelle gesendet werden. Im Gegensatz zu Data Warehouses mit höherer Latenz müssen Feature-Stores möglicherweise Feature-Vektoren mit einer Latenzzeit von einer Millisekunde zurückgeben – was nur in zeilenorientierten oder Key-Value-Stores wirklich möglich ist.
Das typische Zugriffsmuster zum Abrufen von Features ist eine Primärschlüsselsuche, aber wenn Features im Online Feature Store wiederverwendet werden sollen, sind erneut Joins erforderlich (entweder in der Datenbank oder in der Anwendung). In einigen Datenbanken (z.B. MySQL Cluster) kann eine kleine Anzahl von Joins mit sehr geringer Latenz ausgeführt werden.
Deskriptive Statistiken (z. B. Mittelwert, Standardabweichung) für Features sind auch nützlich, wenn Datenabweichungen in Online-Modellen identifiziert werden. Eine Überwachungsinfrastruktur kann Statistiken zum Live-Vorhersage-Traffic berechnen und diese Statistiken mit den Werten im Feature Store vergleichen, um einen Daten-Drift für den Live-Traffic zu identifizieren, was möglicherweise ein erneutes Training des Modells erforderlich macht.
Temporale Datenbanken unterstützen Zeitreisen: die Fähigkeit, Daten so abzufragen, wie sie zu einem bestimmten Zeitpunkt waren, oder Datenänderungen in einem bestimmten Zeitintervall herauszurechnen. Die „AS OF SYSTEM TIME“-Syntax wurde in SQL 2011 eingeführt, um Point-in-Time-Abfragen zu standardisieren, während die „VERSIONS BETWEEN SYSTEM TIME ... AND ...“-Syntax eingeführt wurde, um die versionierten Änderungen an Daten in einem Zeitintervall zu identifizieren. Zeitreisen werden in einigen Data Warehouses unterstützt, haben aber keine universelle Unterstützung für alle Anbieter.
Für einen Feature-Store hat die Zeitreise mehrere wichtige Verwendungszwecke beim Erstellen von Trainings-/Testdaten (bspw. sind Trainingsdaten Daten aus den Jahren 2010–2018, während Testdaten Daten aus dem Zeitraum 2019–2020 sind). Zeitreisen sind nützlich, um Änderungen an einem Datensatz vorzunehmen (z. B. einen fehlerhaften Commit von Daten in den Datensatz rückgängig zu machen) oder um Metadaten (Statistiken) für Funktionen und deren Änderung im Laufe der Zeit zu vergleichen. Wir benötigen selten Zeitreisen für Funktionen, die beim Serving verwendet werden. Zeitreisen sind auch wichtig, wenn Point-in-Time-Joins durchgeführt werden, bei denen wir sicherstellen, dass es keine Datenlecks aus der Zukunft gibt, wenn wir Trainings-/Test-Datensätze aus historischen Daten erstellen.
Data Warehouses verfügen in der Regel über zeitgesteuerte Auslöser zum Ausführen von ETL-Jobs (oder Datenpipelines), um die neuesten Daten aus Betriebsdatenbanken, Nachrichtenwarteschlangen und Data Lakes aufzunehmen. In ähnlicher Weise können Feature-Pipelines zeitgesteuerte Auslöser zum Transformieren und Aggregieren der neuesten Daten aus verschiedenen Quellen haben, bevor sie sowohl im Online- als auch im Offline-Feature-Store gespeichert werden, um von Online- und Offline-Anwendungen bewertet zu werden. Zusätzliche Pipelines können jedoch auch Features in den Feature Store einspeisen.
Vorhersagen von Modellen können zusammen mit den Ergebnissen für diese Vorhersagen im Feature Store gespeichert werden. Es kann lange Verzögerungen von sogar Tagen, Monaten oder Jahren geben, bevor Ergebnisse verfügbar sind – z. B. eine Vorhersage, ob ein Kredit zurückgezahlt wird oder nicht), aber wenn sie eintreffen, werden neue Trainingsdaten verfügbar, die verwendet werden können, um ein erneutes Training auszulösen.
Data Warehouses können verwendet werden, um vorberechnete Features zu speichern, aber für ML-Pipelines bieten sie darüber hinaus nicht viel. Wenn Data Scientists Trainings-/Testdaten mit Python erstellen müssen oder wenn Online-Features (zum Bereitstellen von Features für Online-Modelle) mit geringer Latenz benötigt werden, benötigen Sie einen Feature Store. Wenn Sie einen Feature- oder Daten-Drift erkennen möchten, benötigen Sie Unterstützung bei der Berechnung von Feature-Statistiken und der Identifizierung von Drift.
© Hopsworks 2024. All rights reserved. Various trademarks held by their respective owners.
