Laufzeitumgebungen für Streamlit-Apps

Streamlit in Snowflake bietet zwei Arten von Laufzeitumgebungen für Streamlit-Apps:

  • Container-Laufzeit (Vorschau): Dient einer App als lang laufender Dienst und erstellt eine dedizierte Instanz der App, die von allen Betrachtenden gemeinsam genutzt wird.

  • Warehouse-Laufzeit: Wird bei Bedarf ausgeführt und erstellt für jeden Betrachtenden eine persönliche Instanz der App.

Bemerkung

Wenn Sie den CREATE STREAMLIT-Befehl mit dem ROOT_LOCATION-Parameter verwenden, kann Ihre App nur eine Warehouse-Laufzeit verwenden und unterliegt zusätzlichen Einschränkungen. Diese Seite behandelt Apps, die mit dem FROM-Parameter erstellt wurden. Weitere Informationen dazu finden Sie unter Erläuterungen zu den verschiedenen Typen von Streamlit-Objekten.

Die folgende Tabelle vergleicht die Features, die von Warehouse-Laufzeiten und Container-Laufzeiten für Streamlit in Snowflake-Apps unterstützt werden.

Unterstützte Features

Warehouse-Laufzeit

Container-Laufzeit

Compute

Virtuelles Warehouse für App-Code und interne Abfragen.

Computepool-Knoten für App-Code. Virtuelles Warehouse für interne Abfragen.

Basisbild

Linux in einer gespeicherten Python-Prozedur

Linux in einem Snowpark-Container

Python-Versionen

3.9, 3.10, 3.11

3.11

Streamlit-Version

1.22+ (begrenzte Auswahl)

1.49+ (jede Version, einschließlich streamlit-nightly-Versionen).

Abhängigkeiten

Pakete aus dem Snowflake Conda-Kanal über environment.yml

Pakete aus einem externen Paketindex wie PyPI über pyproject.toml oder requirements.txt

Pin-Versionen mit dem =-Operator

Pin-Versionen mit dem ==-Operator

Verwenden Sie Versionsbereiche mit dem Platzhalter *.

Verwenden Sie Versionsbereiche mit <, <=, >=, > und durch Kommas getrennte Listen.

Einstiegspunkt

Stammverzeichnis Ihres Quellverzeichnisses.

Stammverzeichnis oder Unterverzeichnis innerhalb Ihres Quellverzeichnisses.

Streamlit-Server

Temporäre, individuelle Instanz des Streamlit-Servers für jede Betrachtersitzung.

Persistente, gemeinsam genutzte Serverinstanz für alle Betrachtersitzungen.

Festplatten-, Compute- und Arbeitsspeicherressourcen werden nicht gemeinsam von Betrachtersitzungen genutzt.

Betrachtersitzungen nutzen Festplatten-, Compute- und Arbeitsspeicherressourcen gemeinsam.

Unterstützt kein Zwischenspeichern zwischen Sitzungen.

Unterstützt die Zwischenspeicherfunktionen von Streamlit vollständig.

Startzeiten

Langsam pro Betrachtersitzung aufgrund der App-Erstellung bei Bedarf.

Schneller pro Betrachtersitzung, aber langsamere Bereitstellung durch Container-Start.

Zugriff

Erfordert die Eigentümerschaft zum Bearbeiten.

Identisch mit Warehouse-Laufzeit.

Verwendet Eigentümerrechten für Abfragen, beschränkt ähnlich wie bei gespeicherten Prozeduren mit Eigentümerrechten.

Verwendet Eigentümerrechte für Abfragen mit der Option, Aufruferrechte für einige oder alle Abfragen zu verwenden.

Container-Laufzeiten

Eine Container-Laufzeit bietet eine dedizierte Instanz Ihrer Streamlit-App, die von allen Betrachtenden gemeinsam genutzt wird. Jeder Betrachtende verbindet sich mit derselben Instanz der App, was bedeutet, dass die Betrachtenden schnell eine Verbindung zu einer bereits bestehenden App herstellen können. Container kosten pro Minute deutlich weniger als Warehouses und sind im Allgemeinen eine kostengünstigere Hosting-Lösung, insbesondere für Apps mit häufiger Nutzung.

Container-Laufzeiten teilen sich Festplatten-, Compute- und Arbeitsspeicherressourcen zwischen Betrachtersitzungen. Das bedeutet, dass Sie die Vorteile der Zwischenspeicherfunktionen von Streamlit zur Verbesserung der Leistung voll ausschöpfen können. Bei Container-Laufzeitumgebungen ist ein effizientes App-Design wichtig, um sicherzustellen, dass alle Betrachtenden eine gute Nutzungerfahrung haben.

Mit einer Integration für den externen Zugriff können Sie Python-Pakete von PyPI oder anderen Paketindizes installieren, die die einfache Repository-API unterstützen. Dies macht die Container-Laufzeiten flexibler. Sie haben immer Zugriff auf die neueste Version von Streamlit, einschließlich streamlit-nightly-Versionen.

Warehouse-Laufzeiten

Warehouse-Laufzeiten bieten jedem Betrachtenden eine persönliche Instanz der Streamlit-App. Wenn ein Betrachtender die App öffnet, wird eine neue Instanz der App für diesen Betrachtenden erstellt. Jeder Betrachtende hat seine eigene isolierte Umgebung, was die Benutzer-Ladezeiten erhöht. Während beide Laufzeiten SQL-Abfragen mit den Eigentümerrechten ausführen, unterliegen Apps, die Warehouse-Laufzeitumgebungen verwenden, ähnlichen Einschränkungen wie gespeicherte Prozeduren mit Eigentümerrechten. Weitere Informationen dazu finden Sie unter Gespeicherte Prozeduren mit Eigentümerrechten.

Richtlinien für die Auswahl von Ressourcen in Streamlit in Snowflake

Wenn Sie eine Streamlit-App in Streamlit in Snowflake ausführen, können sich mehrere Faktoren auf die Leistung auswirken, darunter die Komplexität der Streamlit-App, die Verfügbarkeit von Warehouses und die Latenz. Die folgenden Abschnitte enthalten allgemeine Richtlinien für die Verwendung von virtuellen Warehouses und Computepools in Streamlit in Snowflake.

Auswählen eines Computepools

Wenn Sie eine Container-Laufzeit verwenden, müssen Sie einen Computepool auswählen, um die Streamlit-App auszuführen. Jede Streamlit-App wird auf einem einzigen Computepool-Knoten ausgeführt. Die Größe des Computepool-Knotens wirkt sich auf die Leistung der App aus. Wenn Ihre App mehr Arbeitsspeicher benötigt, können Sie größere Knoten verwenden. Da Streamlit jedoch als ein einzelner Prozess ausgeführt wird, ist es unwahrscheinlich, dass Ihre App von mehreren CPUs profitiert. Weitere Informationen dazu finden Sie unter Erstellen von Computepools.

Tipp

  • Um Reibung zu vermeiden, wenn Sie in Zukunft weitere Apps hinzufügen, legen Sie MAX_NODES so fest, dass zukünftige Streamlit-Apps berücksichtigt werden.

  • Um sicherzustellen, dass die Erstellung der App schnell ist, erstellen Sie Ihren Computepool mit MIN_NODES gleich der Anzahl der Apps, die Sie gleichzeitig ausführen möchten, einschließlich zu Test- und Experimentierzwecken.

  • Um die Kosten zu senken, verwenden Sie kleinere Knotengrößen.

  • Sowohl die Anzahl der Knoten als auch die Knotengröße wirken sich auf die Kosten aus. Weitere Informationen dazu finden Sie unter Computepool-Kosten.

Der folgende Befehl erstellt zum Beispiel einen Computepool, um zwei bis fünf Streamlit-Apps gleichzeitig auszuführen:

CREATE COMPUTE POOL streamlit_compute_pool
 MIN_NODES = 2
 MAX_NODES = 5
 INSTANCE_FAMILY = CPU_X64_XS;
Copy

Auswählen eines virtuellen Warehouses

Um Kosten, Leistung und Überwachung zu optimieren, verwenden Sie separate Computeressourcen für die Ausführung Ihrer App und die Ausführung von Abfragen innerhalb Ihrer App. Wenn Sie eine Container-Laufzeit verwenden, werden Ihre Computeressourcen automatisch getrennt, da Ihr App-Code auf einem Computepool-Knoten und dessen Abfragen in einem virtuellen Warehouse ausgeführt werden. Wenn Sie eine Warehouse-Laufzeit verwenden, verwendet Ihre App dasselbe Warehouse, um Ihren App-Code und Abfragen auszuführen, es sei denn, Sie aktivieren ein anderes Abfrage-Warehouse innerhalb Ihres App-Codes.

Mit einer Warehouse-Laufzeit können Sie zum Beispiel ein Warehouse der Größe X-Small verwenden, um Ihren Python-Code auszuführen, und ein Abfrage-Warehouse der Größe Large in Ihrer App aktivieren, um komplexe Abfragen auszuführen.

Bemerkung

Für die Befehle CREATE STREAMLIT und ALTER STREAMLIT sollte der Parameter QUERY_WAREHOUSE je nach Laufzeittyp unterschiedlich verwendet werden:

  • Für Container-Laufzeiten: QUERY_WAREHOUSE legt das Abfrage-Warehouse für die Ausführung von Abfragen innerhalb der App fest.

  • Für Warehouse-Laufzeiten: QUERY_WAREHOUSE legt das Code-Warehouse für die Ausführung des App-Codes fest. Wenn Sie innerhalb Ihres App-Codes kein anderes Warehouse aktivieren, wird dasselbe Warehouse für die Ausführung von Abfragen verwendet.

Best Practices für Abfrage-Warehouses

Befolgen Sie für eine Streamlit-App bei der Auswahl eines Abfrage-Warehouses die gleichen allgemeinen Richtlinien wie bei jeder anderen Snowflake-Workload. Berücksichtigen Sie bei der Auswahl der Warehouse-Größe die Komplexität der Abfragen, den Umfang der abgefragten Daten und die erwartete Parallelität.

Wenn Ihre App eine Container-Laufzeit verwendet, verwenden Sie den QUERY_WAREHOUSE-Parameter, um das Abfrage-Warehouse festzulegen, wenn Sie die Streamlit-App erstellen oder ändern. Wenn Ihre App jedoch eine Warehouse-Laufzeit verwendet, verwenden Sie den QUERY_WAREHOUSE-Parameter, um Ihr Code-Warehouse festzulegen. Sie sollten im Allgemeinen ein kleineres, dediziertes Warehouse für die Ausführung des App-Codes verwenden und innerhalb Ihres App-Codes manuell zu einem anderen Abfrage-Warehouse wechseln.

Beispiel: Container-Laufzeit

Wenn Sie eine Container-Laufzeit verwenden, legen Sie ein ausreichend großes Abfrage-Warehouse fest, um die internen Abfragen Ihrer App auszuführen:

CREATE STREAMLIT my_app
FROM '@my_stage/app_folder'
MAIN_FILE = 'streamlit_app.py'
RUNTIME_NAME = 'SYSTEM$ST_CONTAINER_RUNTIME_PY3_11'
COMPUTE_POOL = streamlit_compute_pool
QUERY_WAREHOUSE = my_large_warehouse
;
Copy

Beispiel: Warehouse-Laufzeit

Wenn Sie eine Warehouse-Laufzeit verwenden, richten Sie ein kleines, dediziertes Code-Warehouse für die Ausführung von Streamlit-Apps ein:

CREATE STREAMLIT my_app
FROM '@my_stage/app_folder'
MAIN_FILE = 'streamlit_app.py'
QUERY_WAREHOUSE = my_small_warehouse;
Copy

Wechseln Sie innerhalb Ihres App-Codes zu einem anderen Warehouse für Abfragen:

import streamlit as st

conn = st.connection("snowflake")
session = conn.session()
session.use_warehouse("my_large_warehouse")
Copy

Best Practices für Code-Warehouses

Wenn Sie eine Warehouse-Laufzeit in Streamlit in Snowflake verwenden, wählen Sie das kleinstmögliche Warehouse aus, um Ihren App-Code auszuführen.

Warehouses speichern Python-Pakete, die von Streamlit-Apps verwendet werden, und verbessern so die Leistung beim nachfolgenden Laden von Apps. Der Zwischenspeicher wird entfernt, wenn das Warehouse angehalten wird, was das erstmalige Laden der App nach dem Fortsetzen des Warehouses verlangsamen kann. Wenn das fortgesetzte Warehouse mehr Apps ausführt, wird der Paketzwischenspeicher neu erstellt, und die Ladeleistung wird verbessert.

Die sekundengenaue Abrechnung und das automatische Anhalten bieten die Flexibilität, mit kleineren Warehouses zu beginnen und die Größen nach Bedarf anzupassen. Sie können die Warehouse-Größe jederzeit vergrößern. Weitere Informationen dazu finden Sie unter Das Warehouse einer Streamlit-App ändern.

Snowflake empfiehlt die Verwendung eines dedizierten Warehouses für Streamlit-Apps, um die Kosten zu isolieren und die Ladezeiten möglicherweise zu verbessern, indem andere Workloads vermieden werden. Aktivieren Sie innerhalb Ihres App-Codes bei Bedarf ein anderes Warehouse für Abfragen.

Weitere Informationen dazu finden Sie unter Hinweise zu Warehouses.

Tipp

  • Stellen Sie das automatische Anhalten auf mindestens 30 Sekunden ein, um während der Initialisierung das Anhalten des Warehouses zu vermeiden.

  • Konfigurieren Sie die Ruhezeiten und WebSocket-Timeouts für Ihre Streamlit-Apps, um die Kosten zu senken. Weitere Informationen dazu finden Sie unter Benutzerdefinierter Sleep-Timer für eine Streamlit-App.