Environnements d’exécution pour les applications Streamlit¶

Streamlit in Snowflake propose deux types d’environnements d’exécution pour les applications Streamlit :

Runtime de conteneur (avant-première) : Fournit une application sous forme de service de longue durée et crée une instance dédiée de l’application qui est partagée entre tous les utilisateurs.
Runtime d’entrepôt : S’exécute à la demande et crée une instance personnelle de l’application pour chaque utilisateur.

Note

Si vous utilisez la commande CREATE STREAMLIT avec le paramètre ROOT_LOCATION, votre application peut uniquement utiliser un runtime d’entrepôt et est soumise à des limitations supplémentaires. Cette page couvre les applications créées avec le paramètre FROM. Pour plus d’informations, voir Comprendre les différents types d’objets Streamlit.

Le tableau suivant compare les fonctionnalités prises en charge par les runtimes d’entrepôt et les runtimes de conteneur pour les applications Streamlit in Snowflake.

Fonctionnalités prises en charge	Runtime d’entrepôt	Runtime de conteneur
Calcul	Entrepôt virtuel pour le code d’application et les requêtes internes.	Nœud de pool de calcul pour le code d’application. Entrepôt virtuel pour les requêtes internes.
Image de base	Linux dans une procédure stockée Python.	Linux dans un conteneur Snowpark.
Versions de Python	3.9, 3.10, 3.11	3,11
Versions de Streamlit	1.22+ (sélection limitée).	1.49+ (toute version, y compris les versions `streamlit-nightly`).
Dépendances	Paquets du canal Snowflake Conda via `environment.yml`.	Paquets d’un index de paquets externe comme PyPI via `pyproject.toml` ou `requirements.txt`.
	Épingler les versions avec l’opérateur `=`.	Épingler les versions avec l’opérateur `==`.
	Utiliser des plages de versions avec le caractère générique `*`.	Utiliser des plages de versions avec `<`, `<=`, `>=`, `>`, et des listes séparées par des virgules.
Emplacement du point d’entrée	Racine de votre répertoire source.	Racine ou sous-répertoire dans votre répertoire source.
Serveur Streamlit	Instance temporaire et individuelle du serveur Streamlit pour chaque session de visualisation.	Instance de serveur persistante et partagée pour toutes les sessions de visualisation.
	Ne partage pas les ressources de disque, de calcul et de mémoire entre les sessions de visualisation.	Partage les ressources de disque, de calcul et de mémoire entre les sessions de visualisation.
	Ne prend pas en charge la mise en cache entre les sessions.	Prend entièrement en charge les fonctionnalités de mise en cache de Streamlit.
Horodatages de démarrage	Plus lent par session de visualisation en raison de la création d’applications à la demande.	Plus rapide par session de visualisation, mais déploiement plus lent en raison du démarrage du conteneur.
Accès	Nécessite des droits de propriété pour le modifier.	Identique au runtime d’entrepôt.
	Utilise les droits des propriétaires pour les requêtes, limités de manière similaire aux procédures stockées des droits des propriétaires.	Utilise les droits du propriétaire pour les requêtes, avec la possibilité d’utiliser les droits de l’appelant pour certaines ou toutes les requêtes.

Runtimes de conteneur¶

Un runtime de conteneur fournit une instance dédiée de votre application Streamlit qui est partagée entre tous les utilisateurs. Chaque utilisateur se connecte à la même instance de l’application, ce qui signifie que les utilisateurs se connectent rapidement à une application déjà en ligne. Les conteneurs coûtent nettement moins cher que les entrepôts par minute et constituent généralement une solution d’hébergement plus rentable, en particulier pour les applications fréquemment utilisées.

Les runtimes de conteneur partagent les ressources de disque, de calcul et de mémoire entre les sessions de visualisation. Cela signifie que vous pouvez tirer pleinement parti des fonctionnalités de mise en cache de Streamlit pour améliorer les performances. Une conception efficace des applications est importante avec les runtimes de conteneur pour garantir une expérience fluide pour tous les utilisateurs.

Avec une intégration d’accès externe, vous pouvez installer des paquets Python à partir de PyPI ou d’autres index de paquets qui prennent en charge l’API de référentiel simple. Cela rend les runtimes de conteneur plus flexibles. Vous aurez toujours accès à la dernière version de Streamlit, dont les versions streamlit-nightly.

Runtimes d’entrepôt¶

Les runtimes d’entrepôt fournissent une instance personnelle et à la demande de l’application Streamlit pour chaque utilisateur. Lorsqu’un utilisateur ouvre l’application, une nouvelle instance de l’application est créée pour cet utilisateur. Chaque utilisateur dispose de son propre environnement isolé, ce qui augmente les temps de chargement pour les utilisateurs. Bien que les deux runtimes exécutent des requêtes SQL à l’aide des privilèges du propriétaire, les applications utilisant les runtimes d’entrepôt sont soumises à des restrictions similaires à celles des procédures stockées avec droits de propriétaire. Pour plus d’informations, voir Procédures stockées de droits du propriétaire.

Lignes directrices relatives à la sélection de ressources dans Streamlit in Snowflake¶

Lorsque vous exécutez une application Streamlit dans Streamlit in Snowflake, de nombreux facteurs peuvent affecter les performances, notamment la complexité de l’application Streamlit, la disponibilité des entrepôts et la latence. Les sections suivantes fournissent des orientations générales pour l’utilisation des entrepôts virtuels et des pools de calcul dans Streamlit in Snowflake.

Sélectionner un pool de calcul¶

Lorsque vous utilisez un runtime de conteneur, vous devez sélectionner un pool de calcul pour exécuter l’application Streamlit. Chaque application Streamlit s’exécute sur un seul nœud de pool de calcul. La taille du nœud du pool de calcul affecte les performances de l’application. Des nœuds plus grands peuvent être utilisés si votre application nécessite plus de mémoire. Toutefois, étant donné que Streamlit s’exécute sous la forme d’un processus unique, il est peu probable que votre application bénéficie de plusieurs CPUs. Pour plus d’informations, voir Création d’un pool de calcul.

Astuce

Afin de réduire les frictions lorsque vous ajoutez d’autres applications à l’avenir, définissez MAX_NODES pour tenir compte des futures applications Streamlit.
Pour que la création d’applications soit rapide, créez votre pool de calcul avec MIN_NODES égal au nombre d’applications que vous avez l’intention d’exécuter simultanément, y compris les tests et les expériences.
Pour réduire les coûts, utilisez des tailles de nœuds plus petites.
La quantité et la taille du nœud ont une incidence sur les coûts. Pour plus d’informations, voir Calculer le coût du pool de calcul.

Par exemple, la commande suivante crée un pool de calcul pour exécuter deux à cinq applications Streamlit simultanément :

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

Copy

Sélection d’un entrepôt virtuel¶

Pour optimiser les coûts, les performances et la surveillance, utilisez des ressources de calcul distinctes pour l’exécution de votre application et l’exécution des requêtes au sein de votre application. Si vous utilisez un runtime de conteneur vos ressources de calcul sont automatiquement séparées parce que le code de votre application s’exécute sur un nœud de pool de calcul et que ses requêtes s’exécutent sur un entrepôt virtuel. Si vous utilisez un runtime d’entrepôt, votre application utilisera le même entrepôt pour exécuter le code de votre application et les requêtes, sauf si vous activez un entrepôt de requêtes différent dans le code de votre application.

Par exemple, avec un runtime d’entrepôt, vous pouvez utiliser un entrepôt X-Small pour exécuter votre code Python et activer un entrepôt de requêtes Large dans votre application pour exécuter des requêtes complexes.

Note

Pour les commandes CREATE STREAMLIT et ALTER STREAMLIT, le paramètre QUERY_WAREHOUSE doit être utilisé différemment selon le type de runtime :

Pour les runtimes de conteneurs, QUERY_WAREHOUSE définit l’entrepôt de requêtes pour l’exécution des requêtes dans l’application.
Pour les runtimes d’entrepôt, QUERY_WAREHOUSE définit l’entrepôt de code pour l’exécution du code d’application. Si vous n’activez pas d’entrepôt différent dans le code de votre application, le même entrepôt sera utilisé pour exécuter les requêtes.

Bonnes pratiques pour les entrepôts de requêtes¶

Dans une application Streamlit, pour sélectionner un entrepôt de requêtes, suivez les mêmes orientations générales que pour toute autre charge de travail Snowflake. Lors de la sélection d’une taille d’entrepôt, tenez compte de la complexité des requêtes, de la taille des données interrogées et de la simultanéité attendue.

Si votre application utilise un runtime de conteneur, utilisez le paramètre QUERY_WAREHOUSE pour définir l’entrepôt de requêtes lorsque vous créez ou modifiez l’application Streamlit. Toutefois, si votre application utilise un runtime d’entrepôt, utilisez le paramètre QUERY_WAREHOUSE pour définir votre entrepôt de code. Vous devez généralement utiliser un entrepôt dédié plus petit pour exécuter le code de l’application et passer manuellement à un autre entrepôt de requêtes dans le code de votre application.

Exemple : Runtime de conteneur

Lorsque vous utilisez un runtime de conteneur, définissez un entrepôt de requêtes suffisamment grand pour exécuter les requêtes internes de votre application :

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

Exemple : Runtime d’entrepôt

Lorsque vous utilisez un runtime d’entrepôt, définissez un petit entrepôt de code dédié à l’exécution des applications Streamlit :

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

Copy

Dans le code de votre application, passez à un autre entrepôt pour les requêtes :

import streamlit as st

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

Copy

Bonnes pratiques pour les entrepôts de code¶

Lorsque vous utilisez un runtime d’entrepôt dans Streamlit in Snowflake, sélectionnez l’entrepôt le plus petit possible pour exécuter le code de votre application.

Les entrepôts mettent en cache les paquets Python utilisés par les applications Streamlit, ce qui améliore les performances lors des chargements ultérieurs des applications. Le cache est supprimé lorsque l’entrepôt est suspendu, ce qui peut ralentir le chargement initial de l’application après la réactivation de l’entrepôt. Si l’entrepôt réactivé exécute davantage d’applications, le cache des paquets se reconstruit et améliore les performances de chargement.

La facturation à la seconde et la suspension automatique permettent de commencer avec des entrepôts plus petits et d’ajuster les tailles selon les besoins. Vous pouvez augmenter la taille de l’entrepôt à tout moment. Pour plus d’informations, voir Modifier l’entrepôt d’une application Streamlit.

Snowflake recommande d’utiliser un entrepôt dédié pour les applications Streamlit afin d’isoler les coûts et d’améliorer potentiellement les temps de chargement en évitant d’autres charges de travail. Dans le code de votre application, activez un entrepôt différent pour les requêtes, selon les besoins.

Pour plus d’informations, voir Considérations relatives aux entrepôts.

Astuce

Définissez la suspension automatique sur au moins 30 secondes pour éviter la suspension de l’entrepôt pendant l’initialisation.
Configurez les temps de mise en veille et les délais d’attente WebSocket pour vos applications Streamlit afin de réduire les coûts. Pour plus d’informations, voir Minuterie de mise en veille personnalisée pour une application Streamlit.