Surveiller les charges de travail des tables hybrides¶

Surveillance des transactions¶

Les tables hybrides prennent en charge les fonctions de surveillance des transactions Snowflake, notamment SHOW TRANSACTIONS, DESCRIBE TRANSACTION, SHOW LOCKS et LOCK WAIT HISTORY.

Le comportement de ces commandes et de ces vues pour les tables hybrides est cohérent avec le comportement des tables Snowflake standards, à l’exception des modifications suivantes :

• Un nouveau type de verrou ROW a été introduit dans la commande SHOW LOCKS pour représenter les verrous de ligne sur les tables hybrides. Les verrous sont résumés pour montrer une transaction détenant (un ou plusieurs) verrous de ligne et une autre transaction en attente de ces verrous.

• LOCK WAIT HISTORY n’affiche pas les informations relatives au schéma.

• LOCK_WAIT_HISTORY ne résume pas les BLOCKER_QUERIES. Si une requête est bloquée par plusieurs bloqueurs, ceux-ci apparaîtront sous la forme de plusieurs enregistrements dans la vue et non sous la forme de plusieurs entrées dans le tableau JSON BLOCKER_QUERIES pour l’enregistrement en attente unique.

• Pour le résultat de SHOW LOCKS et la vue LOCK_WAIT_HISTORY :

  • Étant donné que les verrous de ligne sont résumés, la transaction qui détient le verrou est supposée acquérir le verrou lorsqu’elle démarre.

  • En raison du volume potentiellement élevé des transactions Unistore, seuls les verrous qui ont bloqué d’autres transactions pendant une période prolongée (environ 5 secondes) sont affichés.

  • Il se peut que la transaction en attente de verrous semble encore attendre les verrous, même si elle les a acquis (pendant 1 minute au maximum). La précision de signalement des verrous sera améliorée dans les prochaines versions.

  • Si une instruction qui a bloqué une requête en attente s’est terminée et qu’il s’agissait d’une requête de courte durée sur des tables hybrides, les informations suivantes concernant la requête bloquante n’apparaissent pas dans le champ BLOCKER_QUERY de l’enregistrement de la requête en attente :

    • UUID de requête de la requête de bloqueur

    • ID de session de la requête de bloqueur

    • Nom d’utilisateur de la requête de bloqueur

    • ID de base de données de la requête de bloqueur

    • Nom de base de données de la requête de bloqueur

Surveillance des charges de travail¶

Pour surveiller efficacement vos charges de travail opérationnelles, utilisez la vue Vue AGGREGATE_QUERY_HISTORY. Cette vue vous permet de surveiller la santé de votre charge de travail, de diagnostiquer les problèmes et d’identifier les pistes d’optimisation. La vue AGGREGATE_QUERY_HISTORY regroupe les statistiques d’exécution de requêtes d’une requête paramétrée répétée au cours d’un intervalle de temps, de sorte qu’il est plus facile et plus efficace d’identifier des tendances dans vos charges de travail et vos requêtes au fil du temps. Notez que toutes les charges de travail et requêtes Snowflake seront combinées dans la sortie de cette vue.

La vue AGGREGATE_QUERY_HISTORY vous aide à répondre aux questions suivantes sur vos charges de travail :

• Combien d’opérations sont exécutées par seconde dans mon entrepôt virtuel ?

• Quelles sont les requêtes qui consomment le plus de temps ou de ressources dans ma charge de travail ?

• Les performances d’une requête spécifique ont-elles beaucoup changé au fil du temps ?

Afin d’améliorer les performances et l’efficacité de votre charge de travail, les exécutions individuelles d’opérations à faible latence (moins d’une seconde) ne seront pas stockées dans Vue QUERY_HISTORY et ne généreront pas de profil de requête unique. En revanche, les statistiques agrégées des exécutions répétées de cette requête seront renvoyées dans la vue AGGREGATE_QUERY_HISTORY. Vous pourrez également afficher un profil de requête échantillonné de la requête au cours d’un intervalle de temps sélectionné. Pour plus d’informations sur ce comportement, voir Notes sur l’utilisation.

Surveillance de la santé de la charge de travail globale¶

Utilisez la vue AGGREGATE_QUERY_HISTORY pour surveiller le débit et la simultanéité de votre charge de travail globale et pour enquêter sur les pics ou les chutes imprévus de vos charges de travail. Par exemple :

SELECT
    interval_start_time
    , SUM(calls) as execution_count
    , SUM(calls) / 60 as queries_per_second
    , COUNT(DISTINCT session_id) as unique_sessions
    , COUNT(user_name) as unique_users
FROM snowflake.account_usage.aggregate_query_history
WHERE warehouse_name = '<MY_WAREHOUSE>'
  AND interval_start_time > $START_DATE
  AND interval_start_time < $END_DATE
GROUP BY ALL;

Vous pouvez également utiliser l’historique de requêtes agrégé pour surveiller les problèmes potentiels liés aux erreurs, à la mise en file d’attente, au blocage de verrous ou aux limitations. Par exemple :

WITH time_issues AS
(
    SELECT
        interval_start_time
        , SUM(transaction_blocked_time:"SUM") as transaction_blocked_time
        , SUM(queued_provisioning_time:"SUM") as queued_provisioning_time
        , SUM(queued_repair_time:"SUM") as queued_repair_time
        , SUM(queued_overload_time:"SUM") as queued_overload_time
        , SUM(hybrid_table_requests_throttled_count) as hybrid_table_requests_throttled_count
    FROM snowflake.account_usage.aggregate_query_history
    WHERE WAREHOUSE_NAME = '<MY_WAREHOUSE>'
      AND interval_start_time > $START_DATE
      AND interval_start_time < $END_DATE
    GROUP BY ALL
),
errors AS
(
    SELECT
        interval_start_time
        , SUM(value:"count") as error_count
    FROM
    (
        SELECT
            a.interval_start_time
            ,e.*
        FROM
            snowflake.account_usage.aggregate_query_history a,
            TABLE(flatten(input => errors)) e
        WHERE interval_start_time > $START_DATE
          AND interval_start_time < $END_DATE
  )
  GROUP BY ALL
)
    SELECT
        ts.interval_start_time
        , error_count
        , transaction_blocked_time
        , queued_provisioning_time
        , queued_repair_time
        , queued_overload_time
        , hybrid_table_requests_throttled_count
    FROM time_issues ts
    FULL JOIN errors e ON e.interval_start_time = ts.interval_start_time
;

En règle générale, ces métriques devraient rester basses. Si vous constatez un pic imprévu, il est recommandé d’en rechercher la cause.

Identification et étude des requêtes répétées¶

Vous pouvez choisir d’optimiser ou d’étudier les performances des requêtes courantes et souvent exécutées afin d’améliorer l’efficacité de votre charge de travail. Utilisez la vue AGGREGATE_QUERY_HISTORY pour identifier les principales requêtes d’une charge de travail en fonction du nombre d’exécutions. Par exemple :

SELECT
    query_parameterized_hash
    , any_value(query_text)
    , SUM(calls) as execution_count
FROM snowflake.account_usage.aggregate_query_history
WHERE TRUE
          AND warehouse_name = '<MY_WAREHOUSE>'
          AND interval_start_time > '2024-02-01'
          AND interval_start_time < '2024-02-08'
GROUP BY
          query_parameterized_hash
ORDER BY execution_count DESC
;

Vous pouvez choisir d’afficher les métriques des requêtes les plus lentes. Par exemple :

SELECT
    query_parameterized_hash
    , any_value(query_text)
    , SUM(total_elapsed_time:"sum"::NUMBER) / SUM (calls) as avg_latency
FROM snowflake.account_usage.aggregate_query_history
WHERE TRUE
          AND warehouse_name = '<MY_WAREHOUSE>'
          AND interval_start_time > '2024-02-01'
          AND interval_start_time < '2024-02-08'
GROUP BY
          query_parameterized_hash
ORDER BY avg_latency DESC
;

Vous pouvez analyser les performances d’une requête donnée au fil du temps afin de mieux comprendre les tendances en matière de latence. Par exemple :

SELECT
    interval_start_time
    , total_elapsed_time:"avg"::number avg_elapsed_time
    , total_elapsed_time:"min"::number min_elapsed_time
    , total_elapsed_time:"p90"::number p90_elapsed_time
    , total_elapsed_time:"p99"::number p99_elapsed_time
    , total_elapsed_time:"max"::number max_elapsed_time
FROM snowflake.account_usage.aggregate_query_history
WHERE TRUE
          AND query_parameterized_hash = '<123456>'
          AND interval_start_time > '2024-02-01'
          AND interval_start_time < '2024-02-08'
ORDER BY interval_start_time DESC
;

Cette requête calcule le temps de requête total. Vous pouvez également modifier la requête pour obtenir des métriques plus granulaires sur les différentes phases d’une requête (compilation, exécution, mise en file d’attente et attente de verrou). Des statistiques agrégées seront renvoyées pour chaque phase.