Questions fréquentes sur Query Service et Data Distiller

Pour contourner la limite du nombre de lignes de sortie, appliquez « LIMIT 0 » dans la requête. Par exemple :

SELECT * FROM customers LIMIT 0;

Nous recommandons l’une ou plusieurs des solutions suivantes en cas d’expiration des requêtes.

• Convertissez la requête en requête CTAS et planifiez l’exécution. Vous pouvez planifier une exécution via l’interface utilisateur ou l’API.
• Exécutez la requête sur un bloc de données plus petit en appliquant des conditions de filtrage supplémentaires.
• Exécutez la commande EXPLAIN pour en savoir plus.
• Examinez les statistiques des données du jeu de données.
• Convertissez la requête en formulaire simplifié pour l’exécuter à nouveau à l’aide d’instructions préparées.

Les étapes suivantes décrivent comment afficher une vue tabulaire d’un jeu de données via l’interface utilisateur, y compris tous les champs et colonnes imbriqués dans un formulaire aplati.

• Une fois connecté(e) à Experience Platform, sélectionnez Jeux de données dans le volet de navigation de gauche de l’interface utilisateur pour accéder au tableau de bord Jeux de données.
• L’onglet pour Parcourir les jeux de données s’ouvre. Vous pouvez utiliser la barre de recherche pour affiner les options disponibles. Sélectionnez un jeu de données dans la liste.

• L’écran Activité des jeux de données s’affiche. Sélectionnez Prévisualiser le jeu de données pour ouvrir une boîte de dialogue du schéma XDM et une vue tabulaire des données aplaties du jeu de données sélectionné. Vous trouverez plus de détails dans la documentation sur la prévisualisation d’un jeu de données.

• Sélectionnez un champ du schéma pour afficher son contenu dans une colonne aplatie. Le nom de la colonne s’affiche au-dessus de son contenu sur le côté droit de la page. Vous devez copier le nom pour interroger ce jeu de données.

Consultez la documentation pour obtenir des conseils complets sur comment travailler avec des structures de données imbriquées à l’aide de Query Editor ou d’un client tiers.

Si la requête a pris beaucoup de temps sur un très petit jeu de données, contactez le service clientèle.

Une requête peut être bloquée pendant le traitement pour plusieurs raisons. Pour déterminer la cause exacte, il faut effectuer une analyse approfondie au cas par cas. Contactez le service clientèle d’Adobe pour lancer ce processus.

Une liste complète des numéros de téléphone du service clientèle d’Adobe est disponible sur la page d’aide d’Adobe. Vous pouvez également trouver de l’aide en ligne en procédant comme suit :

• Accédez à https://www.adobe.com/ dans votre navigateur web.
• Sur le côté droit de la barre de navigation supérieure, sélectionnez Se connecter.

• Utilisez l’Adobe ID et le mot de passe associés à votre licence Adobe.
• Sélectionnez Aide et assistance dans la barre de navigation supérieure.

Une bannière déroulante s’affiche avec une section Aide et assistance. Sélectionnez Nous contacter pour ouvrir l’assistant virtuel de l’assistance clientèle Adobe ou sélectionnez Assistance aux entreprises pour obtenir une aide destinées aux grandes organisations.

La fonction de bloc anonyme vous permet d’enchaîner une ou plusieurs instructions SQL exécutées de manière séquentielle. Les blocs anonymes permettent également de gérer les exceptions.

Pour en savoir plus, consultez la documentation sur les blocs anonymes.

Il existe deux façons de mettre en œuvre l’attribution personnalisée :

1. Utilisez une combinaison de fonctions existantes définies par Adobe pour déterminer si les besoins du cas d’utilisation sont satisfaits.
2. Si la suggestion précédente ne répond pas à votre cas d’utilisation, vous devez utiliser une combinaison de fonctions de fenêtre. Les fonctions de fenêtre examinent tous les événements d’une séquence. Elles permettent également de consulter les données historiques et peuvent être utilisées dans n’importe quelle combinaison.

Pour récupérer les journaux d’erreur d’une requête spécifique, vous devez d’abord utiliser l’API Query Service pour récupérer les détails du journal de la requête. La réponse HTTP contient les identifiants de requête requis pour rechercher une erreur de requête.

Utilisez la commande GET pour récupérer plusieurs requêtes. Découvrez comment effectuer un appel à l’API dans la documentation sur les exemples d’appels d’API.

À partir de la réponse, identifiez la requête que vous souhaitez analyser et effectuez une autre requête GET à l’aide de sa valeur id. Vous trouverez des instructions complètes dans la documentation sur la récupération d’une requête à l’aide de l’ID.

Une réponse réussie renvoie un statut HTTP 200 et contient le tableau errors. Par souci de concision, la réponse a été raccourcie.

{
    "isInsertInto": false,
    "request": {
                "dbName": "prod:all",
                "sql": "SELECT *\nFROM\n  accounts\nLIMIT 10\n"
            },
    "clientId": "8c2455819a624534bb665c43c3759877",
    "state": "SUCCESS",
    "rowCount": 0,
    "errors": [{
      'code': '58000',
      'message': 'Batch query execution gets : [failed reason ErrorCode: 58000 Batch query execution gets : [Analysis error encountered. Reason: [sessionId: f055dc73-1fbd-4c9c-8645-efa609da0a7b Function [varchar] not defined.]]]',
      'errorType': 'USER_ERROR'
      }],
    "isCTAS": false,
    "version": 1,
    "id": "343388b0-e0dd-4227-a75b-7fc945ef408a",
}

La documentation de référence sur l’API Query Service fournit plus d’informations sur tous les points d’entrée disponibles.

Le message « Erreur de validation du schéma » signifie que le système ne peut pas localiser un champ dans le schéma. Nous vous recommandons de lire le document des bonnes pratiques relatives à l’organisation des ressources de données dans Query Service ainsi que la documentation sur la requête Create Table As Select (CTAS).

L’exemple suivant illustre l’utilisation d’une syntaxe CTAS et d’un type de données struct :

CREATE TABLE table_name WITH (SCHEMA='schema_name')

AS SELECT '1' as _id,

 STRUCT

  ('2021-02-17T15:39:29.0Z' AS taskActualCompletionDate,

    '2020-09-09T21:21:16.0Z' AS taskActualStartDate,

    'Consulting' AS taskdescription,

    '5f6527c10011e09b89666c52d9a8c564' AS taskguide,

    'Stakeholder Consulting Engagement' AS taskname,

    '2020-09-09T15:00:00.0Z' AS taskPlannedStartDate,

    '2021-02-15T11:00:00.0Z' AS taskPlannedCompletionDate

  ) AS _workfront ;

Les nombres affichés dans le tableau de bord du profil sont précis à partir du dernier instantané. Les nombres générés dans le tableau d’exportation du profil dépendent entièrement de la requête d’exportation. L’interrogation du nombre de profils admissibles pour une audience particulière constitue donc une cause courante de cette incohérence.

La cause la plus probable est que la portée de votre requête est trop limitée. Vous devez supprimer systématiquement une section de la clause WHERE jusqu’à ce que vous commenciez à voir des données.

Vous pouvez également confirmer que votre jeu de données contient des données à l’aide d’une requête courte telle que :

SELECT count(1) FROM myTableName

Commencez par consulter les journaux pour connaître les détails de l’erreur. La section Questions fréquentes sur la recherche d’erreurs dans les journaux fournit des informations supplémentaires sur la manière de procéder.

Vous pouvez également consulter la documentation pour obtenir des conseils sur la manière d’effectuer des requêtes planifiées dans l’interface utilisateur et par le biais de l’API.

N’oubliez pas que lorsque vous utilisez le Query Editor, vous ne pouvez ajouter qu’un planning à une requête qui a déjà été créée et enregistrée. Ceci ne s’applique pas à l’API Query Service.

Vous pouvez exécuter une requête qui renvoie zéro ligne pour obtenir uniquement les métadonnées en réponse. Cet exemple de requête renvoie uniquement les métadonnées de la table spécifiée.

SELECT * FROM <table> WHERE 1=0

Vous pouvez créer des tables temporaires pour itérer rapidement une requête et l’expérimenter avant de la matérialiser pour l’utiliser. Vous pouvez également utiliser des tables temporaires pour vérifier si une requête est fonctionnelle.

Vous pouvez, par exemple, créer une table temporaire :

CREATE temp TABLE temp_dataset AS
SELECT *
FROM actual_dataset
WHERE 1 = 0;

Vous pouvez ensuite utiliser la table temporaire comme suit :

INSERT INTO temp_dataset
SELECT a._company AS _company,
a._id AS _id,
a.timestamp AS timestamp
FROM actual_dataset a
WHERE timestamp >= TO_TIMESTAMP('2021-01-21 12:00:00')
AND timestamp < TO_TIMESTAMP('2021-01-21 13:00:00')
LIMIT 100;

Adobe Experience Platform conserve les données au format d’heure et date UTC (temps universel coordonné). Exemple de format UTC : 2021-12-22T19:52:05Z.

Query Service prend en charge les fonctions SQL intégrées pour convertir une date et une heure données au format UTC et inversement à partir de ce format. Les deux méthodes to_utc_timestamp() et from_utc_timestamp() prennent deux paramètres : la date et l’heure, ainsi que le fuseau horaire.

Convertir en date et heure UTC

La méthode to_utc_timestamp() interprète les paramètres donnés et les convertit à l’heure et à la date de votre fuseau horaire local au format UTC. Par exemple, le fuseau horaire à Séoul, en Corée du Sud, est UTC/GMT +9 heures. En fournissant une date uniquement, la méthode utilise une valeur par défaut de minuit le matin. L’heure, la date et le fuseau horaire sont convertis au format UTC de l’heure de cette région en date et heure UTC de votre région locale.

SELECT to_utc_timestamp('2021-08-31', 'Asia/Seoul');

La requête renvoie une date et une heure à l’heure locale de l’utilisateur ou utilisatrice. Dans ce cas, la veille à 15h00 comme à Séoul, il y a neuf heures d’avance.

2021-08-30 15:00:00

Autre exemple : si la date et l’heure données ont été 2021-07-14 12:40:00.0 pour le fuseau horaire Asia/Seoul, la date et l’heure UTC renvoyées seraient 2021-07-14 03:40:00.0.

La sortie de console fournie dans l’interface utilisateur de Query Service est plus lisible :

8/30/2021, 3:00 PM

Convertir à partir de la date et heure UTC

La méthode from_utc_timestamp() interprète les paramètres donnés à partir de la date et de l’heure de votre fuseau horaire local, et fournit la date et l’heure équivalentes de la région souhaitée au format UTC. Dans l’exemple ci-dessous, l’heure est 14h40 dans le fuseau horaire local de l’utilisateur ou utilisatrice. Le fuseau horaire de Séoul passé en tant que variable est neuf heures en avance sur le fuseau horaire local.

SELECT from_utc_timestamp('2021-08-31 14:40:00.0', 'Asia/Seoul');

La requête renvoie une date et une heure au format UTC pour le fuseau horaire transmis en tant que paramètre. Le résultat est neuf heures en avance sur le fuseau horaire qui a exécuté la requête.

8/31/2021, 11:40 PM

Comment dois-je filtrer mes données de série temporelle ?

SELECT a._company  AS _company,
       a._id       AS _id,
       a.timestamp AS timestamp
FROM   dataset a
WHERE  timestamp >= To_timestamp('2021-01-21 12:00:00')
       AND timestamp < To_timestamp('2021-01-21 13:00:00')

Lors de l’utilisation de l’opérateur CAST pour convertir une date et une heure, vous devez inclure la date et l’heure.

Par exemple, l’absence du composant Heure, comme illustré ci-dessous, entraînera une erreur :

SELECT * FROM ABC
WHERE timestamp = CAST('07-29-2021' AS timestamp)

L’utilisation correcte de l’opérateur CAST est illustrée ci-dessous :

SELECT * FROM ABC
WHERE timestamp = CAST('07-29-2021 00:00:00' AS timestamp)

L’opérateur NOT IN est souvent utilisé pour récupérer les lignes qui ne figurent pas dans une autre table ou instruction SQL. Cet opérateur peut ralentir les performances et renvoyer des résultats inattendus si les colonnes comparées acceptent NOT NULL, ou si vous avez un grand nombre d’enregistrements.

Au lieu d’utiliser NOT IN, vous pouvez utiliser NOT EXISTS ou LEFT OUTER JOIN.

Par exemple, si vous avez les tables suivantes créées :

CREATE TABLE T1 (ID INT)
CREATE TABLE T2 (ID INT)
INSERT INTO T1 VALUES (1)
INSERT INTO T1 VALUES (2)
INSERT INTO T1 VALUES (3)
INSERT INTO T2 VALUES (1)
INSERT INTO T2 VALUES (2)

Si vous utilisez l’opérateur NOT EXISTS, vous pouvez répliquer à l’aide de l’opérateur NOT IN en utilisant la requête suivante :

SELECT ID FROM T1
WHERE NOT EXISTS
(SELECT ID FROM T2 WHERE T1.ID = T2.ID)

Si vous utilisez l’opérateur LEFT OUTER JOIN, vous pouvez répliquer à l’aide de l’opérateur NOT IN en utilisant la requête suivante :

SELECT T1.ID FROM T1
LEFT OUTER JOIN T2 ON T1.ID = T2.ID
WHERE T2.ID IS NULL

Le système ne possède pas d’index, car il ne s’agit pas d’une base de données, mais d’autres optimisations sont en place, liées à l’entrepôt de données. Les options suivantes sont disponibles pour régler vos requêtes :

• Filtre temporel basé sur les données de série temporelle.
• Optimisation du pushdown pour le type de données struct.
• Optimisation du coût et du pushdown de la mémoire pour les types de données de tableaux et de mappage.
• Traitement incrémentiel à l’aide d’instantanés.
• Format de données persistant.

Il existe trois approches pour restreindre l’accès. En voici la liste :

• Utilisez les instructions SELECT uniquement et accordez aux jeux de données un accès en lecture seule. Attribuez également l’autorisation de gestion des requêtes.
• Utilisez des instructions SELECT/INSERT/CREATE et accordez aux jeux de données un accès en écriture. Attribuez également l’autorisation de gestion des requêtes.
• Utilisez un compte d’intégration avec les suggestions précédentes et attribuez l’autorisation d’intégration de requête.

Oui. Les données peuvent être extraites de Query Service et il est également possible de stocker les résultats au format CSV via une commande SQL.

Il existe deux manières d’enregistrer les résultats d’une requête quand on utilise un client PSQL. Vous pouvez utiliser la commande COPY TO ou créez une instruction en respectant le format suivant :

SELECT column1, column2
FROM <table_name>
\g <table_name>.out

Les instructions sur l’utilisation de la commande COPY TO se trouvent dans la documentation de référence de syntaxe SQL.

Une cause courante de ce problème est l’interrogation de données de série temporelle sans filtre temporel. Par exemple :

SELECT * FROM prod_table LIMIT 1;

Doit être écrit comme suit :

SELECT * FROM prod_table
WHERE
timestamp >= to_timestamp('2022-07-22')
and timestamp < to_timestamp('2022-07-23');

Lorsque le système est connecté à Query Service, il est connecté à un moteur de traitement interactif ou par lots. Cela peut entraîner des temps de chargement plus longs pour refléter les données traitées.

Si vous souhaitez améliorer les temps de réponse de vos tableaux de bord, vous devez mettre en oeuvre un serveur Business Intelligence (BI) en tant que couche de mise en cache entre Query Service et les outils de BI. La plupart des outils de BI offrent une option de serveur dans leur assortiment.

L’ajout de la couche de serveur de mise en cache a pour but de mettre en cache les données de Query Service et d’utiliser les mêmes données pour les tableaux de bord, à des fins de temps de réponse réduits. Pour ce faire, les résultats des requêtes exécutées sont mis en cache sur le serveur BI quotidiennement. Le serveur de mise en cache fournit ensuite ces résultats à tout(e) utilisateur ou utilisatrice soumettant la même requête afin de réduire la latence. Pour plus d’informations sur cette mise en œuvre, consultez la documentation de l’utilitaire ou de l’outil tiers que vous utilisez.

La méthode history_meta() sert à accéder à un instantané d’un jeu de données. Auparavant, si vous deviez exécuter une requête sur un jeu de données vide dans Azure Data Lake Storage (ADLS), vous receviez un code d’erreur 58000 indiquant que le jeu de données n’existe pas. Consultez ci-dessous un exemple de l’ancienne erreur système.

ErrorCode: 58000 Internal System Error [Invalid table your_table_name. historyMeta can be used on datalake tables only.]

Cette erreur se produisait car aucune valeur n’était renvoyée pour la requête. Ce comportement est désormais corrigé et renvoie le message suivant :

Query complete in {timeframe}. 0 rows returned.