Modelle mit der Snowflake Model Registry verwalten¶

Die Snowflake Model Registry vereinfacht den Prozess der Überführung eines Modells des maschinellen Lernens von der Entwicklung in die Produktion. Eine gut organisierte Modellregistrierung dient als zentraler Knotenpunkt und einzige Quelle für alle Modelle, ihre Metriken und Metadaten. Die Protokollierung Ihres Modells in der Registrierung ist der erste und wichtigste Schritt auf Ihrer Reise mit Snowflake ML Ops. Sie bringen Ihre Operationen des maschinellen Lernens unter die Kontrolle, Sicherheit und Governance, für die Snowflake bekannt ist.

Die Snowflake Model Registry ist flexibel genug, um eine breite Palette von Anwendungsfällen und Szenarien für die Verwaltung von Modellen auf ML zu unterstützen. In diesem Thema werden wird eine Anleitung geboten, wie Sie die Registrierung am besten nutzen, um Modelle von der Entwicklung bis zur Produktion nahtlos zu verwalten:

Wie Sie den Zugriff auf Modelle kontrollieren, damit die richtige Gruppe von Benutzern oder Rollen verschiedene Operationen durchführen kann.
Wie Sie die Metriken und andere Metadaten all Ihrer Modelle abfragen.
Wie Sie den Lebenszyklus eines Modells von der Entwicklung bis zur Produktion verwalten.
Wie Sie eine neue Version eines Modells ohne Änderungen am Produktionscode einführen.

Governance¶

Da Modelle für maschinelles Lernen First-Class-Objekte in Snowflake sind, können Sie alle standardmäßigen Snowflake-Governance-Funktionen mit ihnen nutzen, einschließlich der rollenbasierten Zugriffssteuerung und des Informationsschemas.

Rollenbasierte Zugriffssteuerung¶

Modellobjekte haben zwei Berechtigungen: OWNERSHIP und USAGE.

Berechtigung	Beschreibung
OWNERSHIP	Vollständige Kontrolle über das Modell, einschließlich der Verwaltung von Modellversionen, des Zugriffs auf Artefakte und der Aktualisierung von Modellmetadaten. Nur eine Rolle kann das Modell besitzen, aber Sie können diese Rolle mehreren Benutzern oder anderen Rollen zuweisen.
USAGE	Schreibgeschützter Zugriff auf das Modell, der Inferenz (Vorhersage) und die Verwendung der Befehle SHOW MODELS und SHOW VERSIONS IN MODEL ermöglicht. Rollen, die nur über USAGE verfügen, haben keinen Zugriff auf den Modellcode, die Gewichte oder andere Artefakte.

Der Eigentümer eines Modells kann einer beliebigen Rolle wie folgt Zugriff gewähren:

GRANT USAGE ON MODEL my_model TO ROLE prod_role;

Copy

Abfragen zum Informationsschema¶

Wie alle Snowflake-Objekte werden Modelle in einer Ansicht in der Snowflake Information Schema dargestellt. Die Ansicht für Modelle und ihre Versionen lautet INFORMATION_SCHEMA.MODEL_VERSIONS. Die Informationen zur Version des Modells sind eine Obermenge der Informationen zu den Modellen, daher gibt es keine separate MODEL-Ansicht.

Über diese Ansicht können Sie die Registrierung selbst abfragen. Nehmen Sie zum Beispiel an, dass Sie eine Genauigkeitsmetrik pflegen und diese zu jeder Version des Modells hinzufügen, indem Sie SQL wie folgt verwenden.

ALTER MODEL my_model MODIFY VERSION v1
    SET METADATA = '{"metric": {"accuracy": 0.769}}';

Copy

Bemerkung

Sie können auch Metriken mit der Python-Registry API einstellen.

mv = reg.get_model("my_model").version("v1").set_metric("accuracy", 0.769)

Copy

Nachdem Sie diese Metrik zu allen Versionen Ihrer Modelle hinzugefügt haben, können Sie eine Abfrage wie die folgende verwenden, um Informationen über alle Modellobjekte abzurufen und sie in der Reihenfolge der höchsten Genauigkeit bis zur niedrigsten aufzulisten.

SELECT
    catalog_name,
    schema_name,
    model_name,
    model_version_name,
    metadata:metric:accuracy AS accuracy,
    comment,
    owner,
    functions,
    created_on,
    last_altered_on
FROM my_database.INFORMATION_SCHEMA.MODEL_VERSIONS
ORDER BY accuracy DESC;

Copy

Sie können komplexere Abfragen erstellen, die sich mit anderen Ansichten des Informationsschemas oder anderen Tabellen zusammenfassen, um eine detailliertere Analyse durchzuführen.

Verwalrten des Lebenszyklus eines Modells¶

Um den unterschiedlichen Anforderungen von kleinen und großen Unternehmen gerecht zu werden, bietet Snowflake Model Registry vier einfache, aber leistungsstarke Schemata für die Verwaltung des Lebenszyklus eines Modells von der Entwicklung bis zur Produktion. Wählen Sie je nach der von Ihnen bevorzugten Struktur die für Sie am besten geeignete aus.

Verwendung der Standardversion
Verwenden von Aliasnamen
Verwenden von Tags
Verwenden mehrerer Schemata

Verwendung der Standardversion¶

Modelle sind versioniert, und eine Version wird als Standardversion bezeichnet. Sie können die Standardversion eines Modells per Konvention als die Produktionsversion behandeln; der Produktionscode ruft immer nur die Standardversion des Modells auf.

In diesem Szenario befördern Sie eine Version eines Modells in die Produktion, indem Sie sie einfach als Standardversion einstellen, vielleicht nachdem sie die Anforderungen Ihres Workflows für die Modellbewertung oder die Leistungsbewertung erfüllt hat. Dies ist der einfachste Weg, um zu kontrollieren, welche Version eines Modells in der Produktion verwendet wird.

Diese Methode verwenden, wenn:

Der Eigentümer des Modells hat die Befugnis zu entscheiden, welche Version in der Produktion verwendet werden soll.
Neben der Entwicklung/Produktion brauchen Sie keine weiteren Stagingbereiche zu verfolgen.

Ersteinrichtung¶

Der Eigentümer des Modells gewährt einer Produktionsrolle die Nutzung des Modells.

GRANT USAGE ON MODEL my_model TO ROLE prod_role;

Copy

Wenn das Modell zum ersten Mal protokolliert wird, ist seine einzige Version die Standardversion, und diese Version kann verwendet werden.

Wichtig

Ein Modell muss immer eine Standardversion haben. Nach diesem Schema können Sie also ein Modell nicht als eine Version bezeichnen, die noch nicht in Produktion ist. Wenn Sie verhindern möchten, dass Modelle verwendet werden, bevor sie fertig sind, können Sie eine erste Version protokollieren, die sofort einen Fehler auslöst. Diese Version würde die Standardversion bleiben, bis eine andere Version fertig ist.

Förderung eines Modells für die Produktion¶

Wenn eine neue Version, die unter SQL als new_version bezeichnet wird, die Qualitätsleiste gelöscht hat, können Sie sie als Standardversion festlegen, um sie als Produktionsversion zu kennzeichnen.

ALTER MODEL my_model SET DEFAULT_VERSION = new_version;

Copy

Verwendung des Modells in der Produktion¶

In der Produktion rufen Sie das Modell direkt auf, um die Standardversion zu verwenden.

SELECT my_model!predict(...) ... ;

Copy

Entwicklung und Tests¶

Um eine Pre-Release-Version zu verwenden, nennen Sie die gewünschte Version des Modells beim Namen:

WITH my_version AS MODEL my_model VERSION new_version
    SELECT my_version!predict(...) ...;

Copy

Verwenden von Aliasnamen¶

Viele Unternehmen verwalten die Lebenszyklen von Modellen in mehreren Stagingbereichen, z. B. Entwicklung, Canary, Staging, Produktion und Ausmusterung. Modellversionen können Aliasnamen, benutzerdefinierte Etiketten oder Tags haben, die Sie exklusiv an jede Version eines Modells anhängen können. Sie können Aliasnamen verwenden, um die Stagingbereiche in Ihrem Unternehmen darzustellen.

Diese Methode verwenden, wenn:

Der Eigentümer des Modells hat die Autorisierung, Entscheidungen im Stagingbereich des Lebenszyklus des Modells zu treffen.
Sie möchten mehrere Stagingbereiche des Lebenszyklus verfolgen, nicht nur Entwicklung/Produktion.

Das folgende Beispiel verwendet zwei Stagingbereiche für die Vorproduktion (alpha und beta) und einen Stagingbereich für die Produktion (production).

Ersteinrichtung¶

Der Eigentümer des Modells gewährt einer Produktionsrolle die Nutzung des Modells.

GRANT USAGE ON MODEL my_model TO ROLE prod_role;

Copy

Förderung der ersten Version des Modells¶

Wenn Sie das Modell protokollieren, stellen Sie den Alias production so ein, dass er auf die erste Version verweist, die hier v1 heißt.

ALTER MODEL my_model VERSION v1 SET ALIAS = production;

Copy

Management von Vorproduktionsversionen¶

Zunächst ist das Modell nicht als Version alpha oder beta gekennzeichnet. Wenn Sie eine neue Version hinzufügen, geben Sie ihr zunächst den Namen alpha.

ALTER MODEL my_model VERSION v2 SET ALIAS = alpha;

Copy

Später, um die nev Version zu beta zu befördern:

ALTER MODEL my_model VERSION v2 UNSET ALIAS;
ALTER MODEL my_model VERSION v2 SET ALIAS = beta;

Copy

Förderung der nachfolgenden Versionen des Modells¶

Wenn eine neue Version eines Modells die Prüfung bestanden hat, entfernen Sie den production-Alias von der aktuellen Produktionsversion, hier v1, und wenden ihn auf die neue Version an, hier v2.

ALTER MODEL my_model VERSION v1 UNSET ALIAS;
ALTER MODEL my_model VERSION v2 UNSET ALIAS;
ALTER MODEL my_model VERSION v2 SET ALIAS = production;

Copy

Verwendung des Modells in der Produktion¶

Rufen Sie die Produktionsversion des Modells über den production-Alias auf.

WITH my_version AS MODEL my_model VERSION production
    SELECT my_version!predict(...) ...;

Copy

Entwicklung und Tests¶

Um Vorabversionen zu verwenden, rufen Sie das Modell stattdessen über den Alias alpha oder beta auf. Zum Beispiel, um die Alpha-Version zu testen:

WITH my_version AS MODEL my_model VERSION alpha
    SELECT my_version!predict(...) ...;

Copy

Verwenden von Tags¶

Die bereits beschriebenen Schemata Standardversion und Alias für die Verwaltung von Lebenszyklen setzen voraus, dass der Eigentümer des Modells in der Lage ist, Lebenszyklen zu verwalten. In vielen Unternehmen liegt diese Verantwortung jedoch bei einer separaten Rolle in der Produktionstechnik, und Data Scientists haben nicht die Befugnis, Versionen von Modellen in die Produktion zu überführen. Da Modelle First-Class-Objekte von Snowflake sind, können Sie zu diesem Zweck die Tags auf sie anwenden. Tags sind durch eine rollenbasierte Zugriffssteuerung sicherbar und eignen sich für diese Trennung der Verantwortlichkeiten.

Diese Methode verwenden, wenn:

Eine andere Rolle als der Eigentümer des Modells bestimmt, wann eine Version eines Modells von einem Stagingbereich in den nächsten verschoben werden soll.

Ersteinrichtung¶

Der Eigentümer des Modells gewährt einer Produktionsrolle die Nutzung des Modells.

GRANT USAGE ON MODEL my_model TO ROLE prod_role;

Copy

Die Produktionsrolle benötigt auch die Möglichkeit, die Tags auf einem Modell zu sehen und die Tag-Werte zu lesen. Ersteres wird hier erreicht, indem der Rolle die umfassende APPLY TAG ON ACCOUNT-Berechtigung zuerkannt wird. Letzteres wird durch die Gewährung von USAGE für das Schema erreicht.

USE ROLE ACCOUNTADMIN;
GRANT APPLY TAG ON ACCOUNT ON MODEL my_model TO ROLE prod_role;
GRANT USAGE ON SCHEMA model_database.model_schema TO ROLE prod_role;

Copy

Um Tags zu erstellen, benötigt eine Rolle die CREATE TAG ON SCHEMA-Berechtigung.

Erstellen Sie ein Tag namens live_version in einem Schema, das prod_role gehört, um den Namen der aktuellen Produktionsversion des Modells zu speichern.

USE ROLE prod_role;
USE SCHEMA prod_db.prod_schema;

CREATE TAG live_version;

Copy

Bemerkung

Hier wird das Tag im Produktionsschema erstellt, da es von der Produktionsrolle verwaltet wird. Wenn Sie es in anderen Schemas verwenden, verwenden Sie seinen vollqualifizierten Namen.

Förderung der ersten Version des Modells¶

Um ein Modell in der Produktion verfügbar zu machen, wenden Sie das live_version-Tag auf das Modell an und geben als Wert des Tags die ursprüngliche Produktionsversion an.

USE ROLE prod_role;
USE SCHEMA prod_db.prod_schema;

ALTER MODEL model_database.model_schema.my_model
    SET TAG live_version = 'V1';

Copy

Förderung der nachfolgenden Versionen des Modells¶

Wenn eine neue Version des Modells fertig ist, aktualisieren Sie das live_version-Tag mit dem Namen dieser Version.

USE ROLE prod_role;

ALTER MODEL model_database.model_schema.my_model
    SET TAG prod_db.prod_schema.live_version = 'V2';

Copy

Verwendung des Modells in der Produktion¶

Rufen Sie die Produktionsversion des Modells auf, indem Sie den Wert des live_version-Tags mit SYSTEM$GET_TAG vom Modell abrufen und dann die Version des Modells mit diesem Namen aufrufen. Die folgende SQL zeigt diesen zweistufigen Prozess.

Bemerkung

Die SQL-Domäne der Modelle, zur Verwendung mit SYSTEM$GET_TAG, ist MODULE.

-- get production model version from live_version tag
SET live_version = (SELECT
    SYSTEM$GET_TAG('prod_db.prod_schema.live_version', 'my_model', 'MODULE'));

-- call that version
WITH my_version AS MODEL my_model VERSION IDENTIFIER($live_version)
    SELECT my_version!predict(...) ... ;

Copy

Entwicklung und Tests¶

Für Pre-Release-Versionen können Sie die gleiche Methode mit zusätzlichen Tags (wie alpha_version und beta_version) verwenden. In vielen Unternehmen wird jedoch nur die Beförderung zur Produktion vom Engineering verwaltet, und es ist sinnvoll, die Stagingbereiche vor dem Release mit der einfacheren Methode Alias zu verwalten.

Verwenden mehrerer Schemata¶

Sie können mehrere Schemas verwenden, um Stagingbereiche zu verwalten. Bei diesem Ansatz ruft der Code ausschließlich Modelle in einem bestimmten Produktionsschema auf, das nur Modelle enthält, die in der Produktion verwendet werden. Modelle in anderen Stagingbereichen werden an anderer Stelle gespeichert. Wenn eine Version eines Modells für die Produktion bereit ist, wird sie in das Produktionsschema kopiert. Da es sich bei den Produktionsmodellen um separate Objekte mit eigener Zugriffssteuerung handelt, können Sie sie vor versehentlichen Änderungen schützen, während die Modellentwickler im Stagingbereich freie Hand haben.

Diese Methode verwenden, wenn:

Eine andere Rolle als der Eigentümer des Modells befördert Modelle zur Produktion.
Sie möchten eine starke Trennung zwischen Entwicklungs- und Produktionsumgebung.

Ersteinrichtung¶

Erstellen Sie eine Rolle (z. B. ml_admin), die sowohl auf das Entwicklungs- als auch auf das Produktionsschema Zugriff hat. In diesem Beispiel ist der Zugriff auf diese beiden Umgebungen in bestehenden Rollen mit den Namen model_owner und prod_role gekapselt, die Berechtigungen wie USAGE und CREATE MODEL auf das Entwicklungs- bzw. Produktionsschema enthalten. Die neue ml_admin-Rolle erhält die Berechtigungen, die sie benötigt, indem ihr diese Rollen zugewiesen werden.

USE ROLE ACCOUNTADMIN;
CREATE ROLE ml_admin;

USE ROLE model_owner;
GRANT ROLE model_owner TO ROLE ml_admin;

USE ROLE prod_role;
GRANT ROLE prod_role TO ROLE ml_admin;

Copy

Förderung der ersten Version des Modells¶

Verwenden Sie die ml_admin-Rolle, um Modellversionen aus dem Entwicklungsschema in das Produktionsschema zu kopieren, wobei Sie die erste Kopie mit CREATE MODEL … FROM MODEL durchführen, um nur die gewünschte Version zu kopieren. Sie können denselben Bezeichner für die Produktionsversion verwenden oder ein anderes Nummerierungsschema für die Produktion festlegen. Hier wird aus der V12-Entwicklungsversion die V1-Produktionsversion.

USE ROLE ml_admin;

CREATE MODEL prod_db.prod_schema.prod_model WITH VERSION V1
    FROM MODEL dev_db.dev_sch.dev_model VERSION V12;

Copy

Nachdem Sie die erste Produktionsversion des Modells erstellt haben, erteilen Sie den Rollen, die das Modell in der Produktion verwenden werden, die USAGE-Berechtigung und alle anderen erforderlichen Berechtigungen.

USE ROLE ml_admin;

GRANT USAGE ON MODEL my_model TO ROLE prod_role;

Copy

Förderung der nachfolgenden Versionen des Modells¶

Wenn eine neue Version des Modells für die Produktion bereit ist, kopieren Sie nur die neue Version des Modells in die Produktionsumgebung. Hier wird die V24-Entwicklungsversion zur V2-Produktionsversion. V2 wird dann als Standardversion festgelegt.

USE ROLE ml_admin;

ALTER MODEL prod_db.prod_schema.prod_model ADD VERSION V2
    FROM MODEL dev_db.dev_schema.dev_model VERSION V24;

ALTER MODEL prod_db.prod_schema.prod_model
    SET DEFAULT_VERSION = V2;

Copy

Tipp

Es ist eine gute Idee, frühere Produktionsversionen aufzubewahren, für den Fall, dass Sie ein Rollback durchführen müssen. Dies können Sie tun, indem Sie die Standardversion auf eine frühere Version einstellen, wie unten gezeigt.

ALTER MODEL prod_db.prod_schema.prod_model SET DEFAULT_VERSION = V1;

Copy

Legen Sie eine Richtlinie fest, wie viele alte Versionen Sie aufbewahren und wie lange Sie diese aufbewahren.

Verwendung des Modells in der Produktion¶

In der Produktion rufen Sie die Standardversion des Modells auf.

SELECT prod_model!predict(...) ... ;

Copy

Entwicklung und Tests¶

Zur Verwaltung von Pre-Release-Versionen können Sie zusätzliche Schemas verwenden und die Versionen von einem Stagingbereich zum nächsten befördern, indem Sie sie von einem Schema zum nächsten kopieren. Wenn der Eigentümer des Modells Stagingbereiche für die Vorproduktion anlegen kann, können Sie eine einfachere Methode wie Aliases verwenden, um diese Versionen zu verwalten. Die Verwendung zusätzlicher Schemata kann dennoch sinnvoll sein, um mehrere Umgebungen in der Vorproduktionsphase zu trennen, z. B. Entwicklung und Test, wenn einer oder mehrere dieser Stagingbereiche von einer anderen Rolle verwaltet werden.