Utilisation de l'apprentissage automatique d'Amazon Aurora avec Aurora Postgre SQL

En utilisant l'apprentissage automatique Amazon Aurora avec votre cluster de SQL base de données Aurora Postgre, vous pouvez utiliser Amazon Comprehend, Amazon SageMaker ou Amazon Bedrock, selon vos besoins. Ces services prennent chacun en charge des cas d'utilisation spécifiques de l'apprentissage automatique.

L'apprentissage automatique Aurora est pris en charge dans certains Régions AWS et pour des versions spécifiques d'Aurora Postgre SQL uniquement. Avant d'essayer de configurer l'apprentissage automatique d'Aurora, vérifiez la disponibilité de votre SQL version d'Aurora Postgre et de votre région. Pour plus de détails, consultez Apprentissage automatique Aurora avec Aurora Postgre SQL.

Conditions requises pour utiliser l'apprentissage automatique Aurora avec Aurora Postgre SQL

AWS les services d'apprentissage automatique sont des services gérés qui sont configurés et exécutés dans leurs propres environnements de production. L'apprentissage automatique Aurora prend en charge l'intégration avec Amazon Comprehend et Amazon SageMaker Bedrock. Avant d'essayer de configurer votre cluster de SQL base de données Aurora Postgre pour utiliser l'apprentissage automatique Aurora, assurez-vous de bien comprendre les exigences et prérequis suivants.

Fonctionnalités et limites prises en charge de l'apprentissage automatique Aurora avec Aurora Postgre SQL

L'apprentissage automatique Aurora prend en charge tout SageMaker point de terminaison capable de lire et d'écrire le format de valeur séparée par des virgules (CSV) via une ContentType valeur de. text/csv Les SageMaker algorithmes intégrés qui acceptent actuellement ce format sont les suivants.

Lorsque vous utilisez Amazon Bedrock avec le machine learning Aurora, les limites suivantes s'appliquent :

Configuration de votre cluster de SQL base de données Aurora Postgre pour utiliser l'apprentissage automatique Aurora

Pour que l'apprentissage automatique Aurora fonctionne avec votre cluster de SQL base de données Aurora Postgre, vous devez créer un AWS Identity and Access Management (IAM) rôle pour chacun des services que vous souhaitez utiliser. Le IAM rôle permet à votre cluster de SQL base de données Aurora Postgre d'utiliser le service d'apprentissage automatique Aurora pour le compte du cluster. Vous devez également installer l'extension du machine learning Aurora. Dans les rubriques suivantes, vous pouvez trouver des procédures de configuration pour chacun de ces services de machine learning Aurora.

Configuration d'Aurora Postgre SQL pour utiliser Amazon Bedrock

Dans la procédure suivante, vous devez d'abord créer le IAM rôle et la politique qui autorisent votre Aurora Postgre SQL à utiliser Amazon Bedrock au nom du cluster. Vous associez ensuite la politique à un IAM rôle que votre cluster de SQL base de données Aurora Postgre utilise pour fonctionner avec Amazon Bedrock. Pour des raisons de simplicité, cette procédure utilise AWS Management Console pour terminer toutes les tâches.

Le rôle (avec sa politique) est associé au cluster de SQL base de données Aurora Postgre. Lorsque le processus est terminé, le rôle est répertorié dans la liste IAM des rôles actuels pour ce cluster, comme indiqué ci-dessous.

La IAM configuration d'Amazon Bedrock est terminée. Poursuivez la configuration de votre Aurora Postgre SQL pour qu'il fonctionne avec l'apprentissage automatique Aurora en installant l'extension comme indiqué dans Installation de l'extension du machine learning Aurora

Configuration d'Aurora Postgre SQL pour utiliser Amazon Comprehend

Dans la procédure suivante, vous devez d'abord créer le IAM rôle et la politique qui donnent à votre Aurora Postgre SQL l'autorisation d'utiliser Amazon Comprehend au nom du cluster. Vous associez ensuite la politique à un IAM rôle que votre cluster de SQL base de données Aurora Postgre utilise pour fonctionner avec Amazon Comprehend. Par souci de simplicité, cette procédure utilise le AWS Management Console pour terminer toutes les tâches.

Le rôle (avec sa politique) est associé au cluster de SQL base de données Aurora Postgre. Lorsque le processus est terminé, le rôle est répertorié dans la liste IAM des rôles actuels pour ce cluster, comme indiqué ci-dessous.

La IAM configuration d'Amazon Comprehend est terminée. Poursuivez la configuration de votre Aurora Postgre SQL pour qu'il fonctionne avec l'apprentissage automatique Aurora en installant l'extension comme indiqué dans Installation de l'extension du machine learning Aurora

Configuration d'Aurora Postgre SQL pour utiliser Amazon SageMaker

Avant de pouvoir créer la IAM politique et le rôle de votre cluster de SQL base de données Aurora Postgre, vous devez disposer de la configuration de votre SageMaker modèle et de votre point de terminaison.

Le rôle (avec sa politique) est associé au cluster de SQL base de données Aurora Postgre. Une fois le processus terminé, le rôle est répertorié dans la liste IAM des rôles actuels pour ce cluster.

La IAM configuration de SageMaker est terminée. Poursuivez la configuration de votre Aurora Postgre SQL pour qu'il fonctionne avec l'apprentissage automatique Aurora en installant l'extension comme indiqué dansInstallation de l'extension du machine learning Aurora.

Configuration d'Aurora Postgre SQL pour utiliser Amazon S3 for SageMaker (Advanced)

Pour l'utiliser SageMaker avec vos propres modèles plutôt que d'utiliser les composants prédéfinis fournis par SageMaker, vous devez configurer un bucket Amazon Simple Storage Service (Amazon S3) que le cluster de base de données Aurora SQL Postgre pourra utiliser. Il s'agit d'une rubrique avancée qui n'est pas entièrement documentée dans ce Guide de l'utilisateur Amazon Aurora. Le processus général est le même que pour intégrer le support SageMaker, comme suit.

Pour plus d'informations de base, consultez Exportation de données vers Amazon S3 pour l'entraînement des SageMaker modèles (niveau avancé).

Installation de l'extension du machine learning Aurora

Les extensions d'apprentissage automatique Aurora aws_ml 1.0 fournissent deux fonctions que vous pouvez utiliser pour appeler les SageMaker services Amazon Comprehend et aws_ml 2.0 fournissent deux fonctions supplémentaires que vous pouvez utiliser pour appeler les services Amazon Bedrock. L'installation de ces extensions sur votre cluster de SQL base de données Aurora Postgre crée également un rôle administratif pour la fonctionnalité.

labdb=> CREATE EXTENSION IF NOT EXISTS aws_ml CASCADE;
NOTICE:  installing required extension "aws_commons"
CREATE EXTENSION
labdb=> 

L'installation des aws_ml extensions crée également le rôle aws_ml administratif et trois nouveaux schémas, comme suit.

Le rds_superuser rôle se voit attribuer le rôle aws_ml administratif et est constitué OWNER de ces trois schémas d'apprentissage automatique Aurora. Pour permettre aux autres utilisateurs de la base de données d'accéder aux fonctions de machine learning Aurora, rds_superuser doit accorder des privilèges EXECUTE sur les fonctions de machine learning Aurora. Par défaut, les privilèges EXECUTE sont révoqués de PUBLIC sur les fonctions des deux schémas de machine learning Aurora.

Dans une configuration de base de données à locataires multiples, vous pouvez empêcher les locataires d'accéder aux fonctions de machine learning d'Aurora en utilisant REVOKE USAGE sur le schéma de machine learning Aurora spécifique que vous souhaitez protéger.

Utilisation d'Amazon Bedrock avec votre cluster de base de données Aurora Postgre SQL

Pour Aurora PostgreSQL, l'apprentissage automatique Aurora fournit la fonction Amazon Bedrock suivante pour travailler avec vos données texte. Cette fonction n'est disponible qu'après avoir installé l'extension aws_ml 2.0 et terminé toutes les procédures de configuration. Pour de plus amples informations, veuillez consulter Configuration de votre cluster de SQL base de données Aurora Postgre pour utiliser l'apprentissage automatique Aurora.

Les entrées et sorties de cette fonction sont les suivantes.

L'exemple suivant montre comment invoquer un modèle Anthropic Claude 2 pour Bedrock à l'aide de invoke_model.

SELECT aws_bedrock.invoke_model (
    model_id    := 'anthropic.claude-v2',
    content_type:= 'application/json',
    accept_type := 'application/json',
    model_input := '{"prompt": "\n\nHuman: You are a helpful assistant that answers questions directly and only using the information provided in the context below.\nDescribe the answer 
    in detail.\n\nContext: %s \n\nQuestion: %s \n\nAssistant:","max_tokens_to_sample":4096,"temperature":0.5,"top_k":250,"top_p":0.5,"stop_sequences":[]}'
);

Les entrées et sorties de cette fonction sont les suivantes.

L'exemple suivant montre comment générer une intégration à l'aide du modèle d'intégration de texte Titan Embeddings G1 pour l'expression Postgre I/O monitoring views. SQL

SELECT aws_bedrock.invoke_model_get_embeddings(
   model_id      := 'amazon.titan-embed-text-v1',
   content_type  := 'application/json',
   json_key      := 'embedding',
   model_input   := '{ "inputText": "PostgreSQL I/O monitoring views"}') AS embedding;

Utilisation d'Amazon Comprehend avec votre cluster de base de données Aurora Postgre SQL

Pour Aurora PostgreSQL, l'apprentissage automatique Aurora fournit la fonction Amazon Comprehend suivante pour travailler avec vos données texte. Cette fonction n'est disponible qu'après avoir installé l'extension aws_ml et effectué toutes les procédures de configuration. Pour de plus amples informations, veuillez consulter Configuration de votre cluster de SQL base de données Aurora Postgre pour utiliser l'apprentissage automatique Aurora.

Les entrées et sorties de cette fonction sont les suivantes.

Voici des exemples qui montrent comment utiliser cette fonction.

SELECT feedback, s.sentiment,s.confidence 
    FROM support,aws_comprehend.detect_sentiment(feedback, 'en') s 
    ORDER BY s.confidence DESC;
 feedback                         | sentiment | confidence
 ----------------------------------------------------------+-----------+------------
 Thank you for the excellent customer support!            | POSITIVE  |   0.999771
 The latest version of this product stinks!               | NEGATIVE  |   0.999184
 Your support team is just awesome! I am blown away.      | POSITIVE  |   0.997774
 Your product is too complex, but your support is great.  | MIXED     |   0.957958
 Your support tech helped me in fifteen minutes.          | POSITIVE  |   0.949491
 My problem was never resolved!                           | NEGATIVE  |   0.920644
 When will the new version of this product be released?   | NEUTRAL   |   0.902706
 I cannot stand that chatbot.                             | NEGATIVE  |   0.895219
 Your support tech talked down to me.                     | NEGATIVE  |   0.868598
 It took me way too long to get a real person.            | NEGATIVE  |   0.481805
 
 (10 rows)

Pour éviter qu'une détection de sentiment vous soit facturée plusieurs fois par ligne de table, vous pouvez matérialiser les résultats. Faites-le sur les lignes qui vous intéressent. Par exemple, les notes du clinicien sont mises à jour afin que seules celles en français (fr) utilisent la fonction de détection des sentiments.

UPDATE clinician_notes
SET sentiment = (aws_comprehend.detect_sentiment (french_notes, 'fr')).sentiment,
    confidence = (aws_comprehend.detect_sentiment (french_notes, 'fr')).confidence
WHERE
    clinician_notes.french_notes IS NOT NULL AND
    LENGTH(TRIM(clinician_notes.french_notes)) > 0 AND
    clinician_notes.sentiment IS NULL;

Pour de plus amples informations sur l'optimisation de vos appels de fonction, veuillez consulter Considérations relatives aux performances liées à l'utilisation de l'apprentissage automatique Aurora avec Aurora Postgre SQL.

Utilisation SageMaker avec votre cluster de SQL base de données Aurora Postgre

Après avoir configuré votre SageMaker environnement et intégré Aurora Postgre SQL comme indiqué dans la sectionConfiguration d'Aurora Postgre SQL pour utiliser Amazon SageMaker , vous pouvez appeler des opérations à l'aide de la aws_sagemaker.invoke_endpoint fonction. La aws_sagemaker.invoke_endpoint fonction se connecte uniquement à un point de terminaison du modèle dans le même Région AWS. Si votre instance de base de données possède des répliques en plusieurs Régions AWS assurez-vous de configurer et de déployer chaque SageMaker modèle sur chaque Région AWS.

Les appels à aws_sagemaker.invoke_endpoint destination sont authentifiés à l'aide du IAM rôle que vous avez configuré pour associer votre cluster de SQL base de données Aurora Postgre au SageMaker service et au point de terminaison que vous avez fournis lors du processus de configuration. SageMaker les points de terminaison du modèle sont limités à un compte individuel et ne sont pas publics. Le endpoint_name URL ne contient pas l'identifiant du compte. SageMaker détermine l'ID de compte à partir du jeton d'authentification fourni par le SageMaker IAM rôle de l'instance de base de données.

Les entrées et sorties de cette fonction sont les suivantes.

Création d'une fonction définie par l'utilisateur pour invoquer un modèle SageMaker

Créez une fonction distincte définie par l'utilisateur à appeler aws_sagemaker.invoke_endpoint pour chacun de vos SageMaker modèles. Votre fonction définie par l'utilisateur représente le SageMaker point de terminaison hébergeant le modèle. La fonction aws_sagemaker.invoke_endpoint s'exécute dans la fonction définie par l'utilisateur. Les fonctions définies par l'utilisateur offrent de nombreux avantages :

Pour spécifier une fonction définie par l'utilisateur, utilisez l'instruction SQL CREATE FUNCTION data definition language (DDL). Lorsque vous créez cette fonction, vous spécifiez les éléments suivants :

La fonction définie par l'utilisateur renvoie l'inférence calculée par le SageMaker point de terminaison après avoir exécuté le modèle sur les paramètres d'entrée. L'exemple suivant crée une fonction définie par l'utilisateur pour un SageMaker modèle avec deux paramètres d'entrée.

CREATE FUNCTION classify_event (IN arg1 INT, IN arg2 DATE, OUT category INT)
AS $$
    SELECT aws_sagemaker.invoke_endpoint (
        'sagemaker_model_endpoint_name', NULL,
        arg1, arg2                        -- model inputs are separate arguments
        )::INT                            -- cast the output to INT
$$ LANGUAGE SQL PARALLEL SAFE COST 5000;

Notez ce qui suit :

Transmission d'un tableau en entrée à un SageMaker modèle

La aws_sagemaker.invoke_endpoint fonction peut avoir jusqu'à 100 paramètres d'entrée, ce qui est la limite pour les SQL fonctions Postgre. Si le SageMaker modèle nécessite plus de 100 paramètres du même type, transmettez-les sous forme de tableau.

L'exemple suivant définit une fonction qui transmet un tableau en entrée au modèle de SageMaker régression. La sortie est convertie à une valeur REAL.

CREATE FUNCTION regression_model (params REAL[], OUT estimate REAL)
AS $$
    SELECT aws_sagemaker.invoke_endpoint (
      'sagemaker_model_endpoint_name',
      NULL,
      params                            
      )::REAL
$$ LANGUAGE SQL PARALLEL SAFE COST 5000;

Spécification de la taille du lot lors de l'appel d'un modèle SageMaker

L'exemple suivant crée une fonction définie par l'utilisateur pour un SageMaker modèle qui définit la taille du lot par défaut surNULL. La fonction vous permet également de fournir une taille de lot différente lorsque vous l'invoquez.

CREATE FUNCTION classify_event (
    IN event_type INT, IN event_day DATE, IN amount REAL, -- model inputs
    max_rows_per_batch INT DEFAULT NULL,  -- optional batch size limit
    OUT category INT)                     -- model output
AS $$
    SELECT aws_sagemaker.invoke_endpoint (
        'sagemaker_model_endpoint_name', max_rows_per_batch,
        event_type, event_day, COALESCE(amount, 0.0)
        )::INT              -- casts output to type INT
$$ LANGUAGE SQL PARALLEL SAFE COST 5000;

Remarques :

Invoquer un SageMaker modèle comportant plusieurs sorties

L'exemple suivant crée une fonction définie par l'utilisateur pour un SageMaker modèle qui renvoie plusieurs sorties. Votre fonction doit convertir la sortie de la fonction aws_sagemaker.invoke_endpoint en un type de données correspondant. Par exemple, vous pouvez utiliser le type de SQL point Postgre intégré pour les paires (x, y) ou un type composite défini par l'utilisateur.

Cette fonction définie par l'utilisateur renvoie des valeurs à partir d'un modèle renvoyant plusieurs sorties à l'aide d'un type composite pour les sorties.

CREATE TYPE company_forecasts AS ( 
    six_month_estimated_return real,
    one_year_bankruptcy_probability float);
CREATE FUNCTION analyze_company (
    IN free_cash_flow NUMERIC(18, 6),
    IN debt NUMERIC(18,6),
    IN max_rows_per_batch INT DEFAULT NULL,
    OUT prediction company_forecasts) 
AS $$
    SELECT (aws_sagemaker.invoke_endpoint('endpt_name',
       max_rows_per_batch,free_cash_flow, debt))::company_forecasts;                                                                                                                  
$$ LANGUAGE SQL PARALLEL SAFE COST 5000;

Pour le type composite, utilisez les champs dans le même ordre que celui dans lequel ils apparaissent dans la sortie du modèle et convertissez la sortie aws_sagemaker.invoke_endpoint en votre type composite. L'appelant peut extraire les champs individuels par leur nom ou avec la notation Postgre SQL « .* ».

Exportation de données vers Amazon S3 pour l'entraînement des SageMaker modèles (niveau avancé)

Nous vous recommandons de vous familiariser avec l'apprentissage automatique Aurora et SageMaker d'utiliser les algorithmes et les exemples fournis plutôt que d'essayer de former vos propres modèles. Pour plus d'informations, consultez Get Started with Amazon SageMaker

Pour entraîner SageMaker des modèles, vous exportez des données vers un compartiment Amazon S3. Le compartiment Amazon S3 est utilisé SageMaker pour entraîner votre modèle avant son déploiement. Vous pouvez interroger les données d'un cluster de SQL base de données Aurora Postgre et les enregistrer directement dans des fichiers texte stockés dans un compartiment Amazon S3. SageMaker Consomme ensuite les données du compartiment Amazon S3 à des fins d'entraînement. Pour en savoir plus sur la formation des SageMaker modèles, consultez la section Entraîner un modèle avec Amazon SageMaker.

Pour de plus amples informations sur l'exportation de vos données, veuillez consulter Exportation de données depuis un cluster de SQL base de données Aurora Postgre RDS S3.

Considérations relatives aux performances liées à l'utilisation de l'apprentissage automatique Aurora avec Aurora Postgre SQL

Amazon Comprehend et ses SageMaker services effectuent la majeure partie du travail lorsqu'ils sont invoqués par une fonction d'apprentissage automatique Aurora. Cela signifie que vous pouvez adapter ces ressources selon vos besoins, de manière indépendante. Pour votre cluster de SQL base de données Aurora Postgre, vous pouvez rendre vos appels de fonction aussi efficaces que possible. Vous trouverez ci-dessous certaines considérations relatives aux performances à prendre en compte lors de l'utilisation de l'apprentissage automatique Aurora à partir d'Aurora PostgreSQL.

Présentation du mode par lots et des fonctions de machine learning d'Aurora

Postgre SQL exécute généralement les fonctions ligne par ligne. Le machine learning Aurora peut réduire cette surcharge en combinant en lots les appels au service de machine learning Aurora externe pour de nombreuses lignes avec une approche appelée exécution en mode traitement par lots. En mode traitement par lots, le machine learning Aurora reçoit les réponses d'un lot de lignes d'entrée, puis retransmet les réponses à la requête en cours d'exécution une ligne à la fois. Cette optimisation améliore le débit de vos requêtes Aurora sans limiter l'optimiseur de SQL requêtes Postgre.

Aurora utilise automatiquement le mode traitement par lots si la fonction est référencée à partir de la liste SELECT, d'une clause WHERE ou d'une clause HAVING. Notez que les expressions CASE simples de niveau supérieur sont éligibles à l'exécution en mode traitement par lots. Les expressions CASE recherchées de niveau supérieur sont également éligibles à l'exécution en mode traitement par lots à condition que la première clause WHEN soit un prédicat simple avec un appel de fonction en mode traitement par lots.

Votre fonction définie par l'utilisateur doit être une fonction LANGUAGE SQL et doit spécifier PARALLEL SAFE et COST 5000.

Migration de fonctions de l'SELECTinstruction vers la FROM clause

Habituellement, une fonction aws_ml éligible à l'exécution en mode traitement par lots est automatiquement migrée par Aurora vers la clause FROM.

La migration des fonctions éligibles en mode batch vers la FROM clause peut être examinée manuellement au niveau de chaque requête. Pour ce faire, vous utilisez EXPLAIN les instructions (etVERBOSE) ANALYZE et trouvez les informations « Traitement par lots » en dessous de chaque mode par lotsFunction Scan. Vous pouvez également utiliser EXPLAIN (avecVERBOSE) sans exécuter la requête. Vous observez ensuite si les appels à la fonction apparaissent sous la forme Function Scan sous une jointure de boucle imbriquée qui n'a pas été spécifiée dans l'instruction d'origine.

Dans l'exemple suivant, l'opérateur de jointure de boucle imbriquée dans le plan montre que Aurora a migré la fonction anomaly_score. Il a migré cette fonction de la SELECT liste vers la FROM clause, où elle est éligible à une exécution en mode batch.

EXPLAIN (VERBOSE, COSTS false) 
SELECT anomaly_score(ts.R.description) from ts.R;
                         QUERY PLAN                          
-------------------------------------------------------------
 Nested Loop
   Output: anomaly_score((r.description)::text)
   ->  Seq Scan on ts.r
         Output: r.id, r.description, r.score
   ->  Function Scan on public.anomaly_score
         Output: anomaly_score.anomaly_score
         Function Call: anomaly_score((r.description)::text)

Pour désactiver l'exécution en mode traitement par lots, définissez le paramètre apg_enable_function_migration sur false. Cela empêche la migration des aws_ml fonctions de la FROM clause SELECT to. L'exemple suivant indique comment procéder.

SET apg_enable_function_migration = false;

Le apg_enable_function_migration paramètre est un paramètre Grand Unified Configuration (GUC) reconnu par l'SQLapg_plan_mgmtextension Aurora Postgre pour la gestion des plans de requêtes. Pour désactiver la migration des fonctions dans une session, utilisez la gestion des plans de requêtes pour enregistrer le plan résultant en tant que plan approved. Lors de l'exécution, la gestion des plans de requêtes applique le plan approved avec son paramètre apg_enable_function_migration. Cette application a lieu quel que soit le réglage des apg_enable_function_migration GUC paramètres. Pour de plus amples informations, veuillez consulter Gestion des plans d'exécution des requêtes pour Aurora Postgre SQL.

Utilisation du paramètre max_rows_per_batch

Les fonctions aws_comprehend.detect_sentiment et aws_sagemaker.invoke_endpoint ont toutes deux un paramètre max_rows_per_batch. Ce paramètre indique le nombre de lignes qui peuvent être envoyées au service de machine learning Aurora. Plus le jeu de données traité par votre fonction est grand, plus vous pouvez augmenter la taille du lot.

Les fonctions en mode traitement par lots améliorent l'efficacité en créant des lots de lignes qui répartissent le coût des appels de fonction du machine learning Aurora sur un grand nombre de lignes. Toutefois, si une instruction SELECT se termine prématurément en raison d'une clause LIMIT, le lot peut être construit sur plus de lignes que la requête n'en utilise. Cette approche peut entraîner des frais supplémentaires pour votre AWS . Pour profiter des avantages de l'exécution en mode traitement par lots tout en évitant de créer des lots trop volumineux, utilisez une valeur plus petite pour le paramètre max_rows_per_batch dans vos appels de fonction.

Si vous effectuez une action EXPLAIN (VERBOSE, ANALYZE) sur une requête qui utilise l'exécution en mode traitement par lots, vous voyez un opérateur FunctionScan qui se trouve sous une jointure de boucle imbriquée. Le nombre de boucles rapporté par EXPLAIN équivaut au nombre de fois où une ligne a été extraite à partir de l'opérateur FunctionScan. Si une instruction utilise une LIMIT clause, le nombre d'extractions est constant. Pour optimiser la taille du lot, définissez le paramètre max_rows_per_batch sur cette valeur. Cependant, si la fonction de mode traitement par lots est référencée dans un prédicat dans la clause WHERE ou HAVING, vous ne pouvez probablement pas connaître le nombre d'extractions à l'avance. Dans ce cas, utilisez les boucles comme guide et testez l'élément max_rows_per_batch pour trouver un paramètre optimisant les performances.

Vérification de l'exécution en mode traitement par lots

Pour voir si une fonction a été exécutée en mode batch, utilisez EXPLAIN ANALYZE. Si l'exécution en mode traitement par lots a été utilisée, le plan de requêtes inclura les informations dans une section « Batch Processing (Traitement par lots) ».

EXPLAIN ANALYZE SELECT user-defined-function();
 Batch Processing: num batches=1 avg/min/max batch size=3333.000/3333.000/3333.000
                                avg/min/max batch call time=146.273/146.273/146.273

Dans cet exemple, 1 lot contenait 3 333 lignes, dont le traitement a duré 146,273 ms. La section « Batch Processing (Traitement par lots) » contient les éléments suivants :

En général, le lot final est plus petit que le reste, ce qui entraîne souvent une taille de lot minimale bien inférieure à la taille moyenne.

Pour renvoyer les premières lignes plus rapidement, définissez le paramètre max_rows_per_batch sur une valeur plus petite.

Pour réduire le nombre d'appels en mode traitement par lots au service ML lorsque vous utilisez une clause LIMIT dans votre fonction définie par l'utilisateur, définissez le paramètre max_rows_per_batch sur une valeur plus petite.

Améliorer les temps de réponse grâce au traitement parallèle des requêtes

Pour obtenir des résultats le plus rapidement possible à partir d'un grand nombre de lignes, vous pouvez combiner le traitement des requêtes parallèles avec le traitement par lots. Vous pouvez utiliser le traitement des requêtes en parallèle pour les instructions SELECT, CREATE TABLE AS SELECT et CREATE MATERIALIZED VIEW.

Le traitement des requêtes en parallèle se produit à la fois dans la base de données et dans le service ML. Le nombre de cœurs dans la classe d'instance de la base de données limite le degré de parallélisme pouvant être utilisé lors de l'exécution d'une requête. Le serveur de base de données peut construire un plan d'exécution de requêtes en parallèle qui partitionne la tâche entre un ensemble d'unités de travail parallèles. Ensuite, chacune de ces unités de travail peut créer des requêtes par lots contenant des dizaines de milliers de lignes (ou autant que ce qui est autorisé par chaque service).

Les demandes groupées provenant de tous les travailleurs parallèles sont envoyées au SageMaker point de terminaison. Le degré de parallélisme que le point de terminaison peut prendre en charge est limité par le nombre et le type d'instances qui le prennent en charge. Pour obtenir K degrés de parallélisme, vous avez besoin d'une classe d'instance de base de données ayant au moins K cœurs. Vous devez également configurer le SageMaker point de terminaison de votre modèle pour qu'il comporte K instances initiales d'une classe d'instance suffisamment performante.

Pour utiliser le traitement des requêtes en parallèle, vous pouvez définir le paramètre de stockage parallel_workers de la table qui contient les données que vous prévoyez de transmettre. Vous définissez parallel_workers sur une fonction en mode traitement par lots telle que aws_comprehend.detect_sentiment. Si l'optimiseur choisit un plan de requête parallèle, AWS Les services ML peuvent être appelés à la fois par lots et en parallèle.

Vous pouvez utiliser les paramètres suivants avec la fonction aws_comprehend.detect_sentiment pour obtenir un plan avec un parallélisme à quatre voies. Si vous modifiez l'un des deux paramètres suivants, vous devez redémarrer l'instance de base de données pour que les modifications soient effectives

-- SET max_worker_processes to 8;  -- default value is 8
-- SET max_parallel_workers to 8;  -- not greater than max_worker_processes
SET max_parallel_workers_per_gather to 4;  -- not greater than max_parallel_workers

-- You can set the parallel_workers storage parameter on the table that the data
-- for the Aurora machine learning function is coming from in order to manually override the degree of
-- parallelism that would otherwise be chosen by the query optimizer
--
ALTER TABLE yourTable SET (parallel_workers = 4);

-- Example query to exploit both batch-mode execution and parallel query
EXPLAIN (verbose, analyze, buffers, hashes) 
SELECT aws_comprehend.detect_sentiment(description, 'en')).*
FROM yourTable
WHERE id < 100;

Pour plus d'informations sur le contrôle des requêtes parallèles, consultez la section Plans parallèles dans la SQL documentation Postgre.

Utilisation des vues matérialisées et des colonnes matérialisées

Lorsque vous invoquez un AWS service tel que SageMaker Amazon Comprehend depuis votre base de données, votre compte est débité conformément à la politique tarifaire de ce service. Pour minimiser les frais sur votre compte, vous pouvez matérialiser le résultat de l'appel au AWS service dans une colonne matérialisée afin que AWS le service n'est pas appelé plus d'une fois par ligne d'entrée. Si vous le souhaitez, vous pouvez ajouter une colonne d'horodatage materializedAt pour enregistrer l'heure à laquelle les colonnes ont été matérialisées.

La latence d'une instruction INSERT ordinaire à une seule ligne est généralement beaucoup moins élevée que celle de l'appel d'une fonction en mode traitement par lots. Ainsi, vous risquez de ne pas être en mesure de répondre aux exigences de latence de votre application si vous appelez la fonction en mode traitement par lots pour chaque INSERT d'une seule ligne exécuté par votre application. Pour matérialiser le résultat de l'appel d'un AWS service dans une colonne matérialisée, les applications hautes performances doivent généralement remplir les colonnes matérialisées. Pour ce faire, elles émettent périodiquement une instruction UPDATE qui s'exécute sur un grand lot de lignes en même temps.

UPDATE applique un verrou au niveau de la ligne qui peut avoir un impact sur une application en cours d'exécution. Donc, vous pouvez avoir besoin d'utiliser SELECT ... FOR UPDATE SKIP LOCKED ou MATERIALIZED VIEW.

Les requêtes analytiques qui s'exécutent sur un grand nombre de lignes en temps réel peuvent combiner la matérialisation en mode traitement par lots et le traitement en temps réel. Pour ce faire, ces requêtes rassemblent sous la forme d'une opération UNION ALL les résultats prématérialisés avec une requête sur les lignes qui n'ont pas encore de résultats matérialisés. Dans certains cas, une telle opération UNION ALL est nécessaire à plusieurs endroits ou la requête peut être générée par une application tierce. Si tel est le cas, vous pouvez créer un VIEW pour encapsuler l'UNION ALLopération afin que ce détail ne soit pas exposé au reste de l'SQLapplication.

Vous pouvez utiliser une vue matérialisée pour matérialiser les résultats d'une instruction SELECT arbitraire à un moment dans le temps. Vous pouvez également l'utiliser pour actualiser la vue matérialisée à tout moment dans le futur. Actuellement, Postgre SQL ne prend pas en charge l'actualisation incrémentielle. Ainsi, chaque fois que la vue matérialisée est actualisée, la vue matérialisée est entièrement recalculée.

Vous pouvez actualiser les vues matérialisées avec l'option CONCURRENTLY, qui met à jour le contenu de la vue matérialisée sans appliquer de verrou exclusif. Cela permet à une SQL application de lire à partir de la vue matérialisée pendant son actualisation.

Surveillance du machine learning Aurora

Vous pouvez surveiller les fonctions aws_ml en définissant le paramètre track_functions de votre groupe de paramètres de cluster de bases de données personnalisé sur all. Par défaut, ce paramètre est défini sur pl, ce qui signifie que seules les fonctions du langage de procédure sont suivies. En le remplaçant par all, les fonctions aws_ml sont également suivies. Pour plus d'informations, consultez la section Statistiques d'exécution dans la documentation SQL Postgre.

Pour plus d'informations sur la surveillance des performances des SageMaker opérations appelées par les fonctions d'apprentissage automatique d'Aurora, consultez Monitor Amazon SageMaker dans le manuel Amazon SageMaker Developer Guide.

Avec track_functions défini sur all, vous pouvez interroger la vue pg_stat_user_functions pour obtenir des statistiques sur les fonctions que vous définissez et utilisez pour appeler les services de machine learning Aurora. Pour chaque fonction, la vue inclut le nombre de calls, total_time et self_time.

Pour consulter les statistiques des fonctions aws_sagemaker.invoke_endpoint et aws_comprehend.detect_sentiment, vous pouvez filtrer les résultats par nom de schéma à l'aide de la requête suivante.

SELECT * FROM pg_stat_user_functions 
    WHERE schemaname 
    LIKE 'aws_%';

Pour effacer les statistiques, procédez comme suit.

SELECT pg_stat_reset();

Vous pouvez obtenir le nom des SQL fonctions qui appellent la aws_sagemaker.invoke_endpoint fonction en interrogeant le catalogue du SQL pg_proc système Postgre. Ce catalogue contient des informations sur les fonctions, les procédures et plus encore. Pour plus d'informations, consultez pg_proc dans la documentation de Postgre. SQL Voici un exemple d'interrogation de la table pour obtenir les noms des fonctions (proname) dont la source (prosrc) inclut le texte invoke_endpoint.

SELECT proname FROM pg_proc WHERE prosrc LIKE '%invoke_endpoint%';