watsonx.data Les API renvoient une réponse vide dans le plan watsonx.data Lite (catalogue sample_data)

Les points de terminaison API watsonx.data suivants renvoient des réponses vides pour les exemples de catalogues Hive ( IBM compartiment COS):

API Unity

• /api/2.1/unity-catalog/schemas/{catalog_name}.{schema_name}
• /api/2.1/unity-catalog/tables?catalog_name={catalog_name}&schema_name={schema_name}

API console

• /v3/tables/{table_name}?catalog_name={catalog_name}&schema_name={schema_name}
• /v3/columns?catalog={catalog_name}&schema={schema_name}
• /v3/schemas/{schema_name}?catalog={catalog_name}
• /v3/schemas?catalog={catalog_name}

Les applications Spark ne s'affichent pas dans la console lorsque vous utilisez des points de terminaison privés

Lorsque vous activez les points de terminaison privés virtuels (VPE) pour renforcer la sécurité, les applications Spark soumises à des points de terminaison privés ne sont pas visibles dans la watsonx.data console. La liste des applications n'apparaît que lorsque les points de terminaison publics sont également activés.

Solution de contournement : vous pouvez accéder à la liste des applications depuis votre VPC à l'aide de la passerelle VPE.

ANALYZE TABLE Les opérations sur les tables du sample_data catalogue ne sont pas prises en charge

Importation/exportation CPG non prise en charge pour les instances watsonx.data au niveau du compte

Pour les watsonx.data instances, qui sont désormais limitées au compte, la fonctionnalité d'importation/exportation de la passerelle de stratégie commune (CPG) n'est pas prise en charge. Toute tentative d'utilisation de ces fonctionnalités échouera et renverra le message d'erreur suivant : import/export features will not be supported for this instance: <instanceID>.

Spark 4.0 ne parvient pas à exécuter les requêtes SQL en mode ANSI avec la configuration fournie

Lorsque vous exécutez des requêtes SQL sur Spark 4.0 avec le mode ANSI activé (spark.sql.ansi.enabled=true), les requêtes échouent en ExtendedAnalysisException raison de l'application stricte des types dans le mode ANSI. Ce problème se produit même lorsque vous utilisez des configurations qui fonctionnent sur Spark 3.5.

Solution de contournement : utilisez le mode non ANSI en définissant le paramètre : "spark.sql.ansi.enabled": "false"

Désactivez le mode ANSI dans Spark 4.0 pour éviter les échecs des requêtes TPC-DS

Lorsque vous utilisez Spark 4.0 comme environnement d'exécution, le mode ANSI est activé par défaut. Cela provoque des échecs lors de l'exécution des requêtes TPC-DS standard. Pour éviter ces problèmes, le mode ANSI doit être désactivé dans les modèles 4.0 Spark en définissant la configuration spark.sql.ansi.enabled": "false". Cela garantit que le mode ANSI n'est pas activé automatiquement et évite les incompatibilités de requêtes.

Échecs d'accès lorsque Context-based restrictions est activé

Lorsque Context-based restrictions est activé, les tâches d'ingestion échouent. De plus, les autres opérations qui nécessitent un accès administrateur au métastore échouent également. Les opérations d'ingestion et de niveau administrateur fonctionnent comme prévu lorsque CBR est désactivé.

watsonx.data L'opération d'assistance échoue en raison de la context-based restrictions politique réseau

Lorsque vous essayez de récupérer des informations pour une watsonx.data instance via watsonx.data l'assistant, la demande peut échouer avec une erreur d'authentification si Context-based restrictions est activé au niveau du compte. Cela se produit lorsque watsonx.data l'assistant n'est pas inclus dans les adresses IP approuvées définies dans la Context-based restrictions politique, ce qui entraîne le refus de la demande API.

Erreur « Accès refusé » dans les Presto requêtes et Spark lorsque le service Hadoop Ranger est intégré

Lors de l'intégration du service Hadoop Ranger dans watsonx.data, les requêtes SQL exécutées à l'aide du Presto moteur échouent avec l'erreur suivante : Access denied: USE. Cela se produit lors d'opérations telles que la création de schémas dans le catalogue par défaut via l'espace de travail de requête. De plus, si le service Presto Ranger est configuré et que la requête est exécutée à l'aide du moteur Spark, la requête échouera également avec la même erreur.

Échec du filtrage des colonnes DATE, TIME, TIMESTAMP et VARBINARY à l'aide de la clause WHERE dans MongoDB Connector

Lorsque vous utilisez le MongoDB connecteur dans Presto, les requêtes avec une WHERE clause échouent à renvoyer des enregistrements lors du filtrage sur des colonnes des types de données suivants :

• DATE
• PÉRIODE
• HORODATAGE
• VarBinary

Cette limitation a un impact sur les scénarios où les règles de gouvernance telles que ROW FILTER s'appuient sur la clause WHERE sous-jacente pour l'évaluation.

La synchronisation manuelle du métastore Query Optimizer n'est pas disponible pour le forfait Lite

Pour les instances Lite de watsonx.data, la synchronisation manuelle et la synchronisation initiale du métastore pour Query Optimizer ne sont pas prises en charge dans la version 2.3. Si la synchronisation initiale échoue, les requêtes des clients seront renvoyées vers l'optimiseur natif de Presto au lieu de l 'optimiseur de requêtes. Pour plus d'informations, consultez la section Synchronisation manuelle de Query Optimizer avec le métastore.

Erreur de connexion à watsonx.data à partir de l'écran Chat with Document

Lorsqu'ils tentent d'établir une connexion avec watsonx.data à partir de l'écran Chat with Document (en particulier dans la région de Ca-Tor), les utilisateurs rencontrent l'erreur suivante : Erreur : A data source of the specified type [null] does not exist.

La désactivation de l'interface utilisateur de l'ACL n'empêche pas le filtrage des rangées dans l'interface utilisateur de l'ACL Presto

La désactivation des ACL GenAI via l'interface utilisateur de la console n'empêche pas totalement le filtrage au niveau des lignes dans Presto. Cela se produit parce que Presto vérifie l'état de l'ACL en interrogeant l'API GET /acl_storage sur la présence du seau ACL. Si le seau est toujours enregistré, le filtrage se poursuit même si les ACL ont été désactivées dans l'interface utilisateur.

Solution : Après avoir désactivé les ACL via l'interface utilisateur, supprimez manuellement le seau d'ACL à partir de watsonx.data.

Accès non autorisé à une colonne dans des tables dont les champs du schéma sont identiques

Si un utilisateur se voit accorder l'accès à une table spécifique au sein d'un schéma, il est inopinément en mesure de visualiser et d'interroger les colonnes d'autres tables du même schéma si ces tables partagent les mêmes noms de colonnes. Cela se produit même si l'utilisateur n'a pas de règles d'accès explicites pour les autres tables.

EXT_METASTORE_SYNC échoue en raison d'une incompatibilité de nom de catalogue

Les utilisateurs peuvent ne pas connaître le nom du catalogue stocké dans les métadonnées. Par conséquent, si le nom du catalogue utilisé dans l'interface utilisateur watsonx.data diffère de celui spécifié dans le fichier de métadonnées, EXT_METASTORE_SYNC échouera, ce qui empêchera l'utilisation de Query Optimizer.

Solution : Créer un catalogue avec le même nom que dans les fichiers de métadonnées.

Node délai d'affectation lors du redémarrage du moteur

Pendant la phase de redémarrage, le moteur ne parvient pas à affecter un nœud en raison de sa disponibilité limitée. En conséquence, la création des schémas est considérablement retardée.

La page Détails du stockage dans l'interface utilisateur de l'historique de Spark est vide

La page Détails du stockage dans l'interface utilisateur de l'historique Spark n'affiche aucun contenu. Pendant le chargement de la page, celle-ci reste complètement vide, ce qui empêche les utilisateurs de consulter ou de gérer les informations relatives au stockage. Pour capturer des informations détaillées sur le stockage (mise à jour des blocs) dans les journaux d'événements, vous devez activer la configuration spark.eventLog.logBlockUpdates.enabled lors de la soumission de la demande. Pour plus d'informations, voir Soumettre une application Spark en utilisant le moteur Spark natif et Accéder au serveur d'historique Spark.

L'application Spark ne s'exécute pas lorsque le nom de fichier contient des espaces ou des caractères spéciaux

Si vous téléchargez un fichier Python (.py) dont le nom contient des espaces ou des caractères spéciaux (par exemple, wordcount (1).py), le job Spark ne s'exécute pas. Le système ne gère pas ces noms de fichiers, ce qui entraîne l'erreur suivante lors de la soumission du travail.

/opt/ibm/entrypoint/start-spark-job-wrapper.sh: eval: line 293: syntax error near unexpected token (' /opt/ibm/entrypoint/start-spark-job-wrapper.sh: eval: line 293: spark-submit --master spark://spark-master-headless-b778988f-24ff-49c2-aa05-a56f3c204f0b:7077 s3a://sparkqa-donotdelete-pr-7aqi2frntm5vlz/spark_jobs/uploads/8f472c67-23aa-4f94-8ed6-c9f2dbe13e20/application/wordcount (1).py '/opt/ibm/spark/examples/src/main/resources/people.txt''

Solution : Pour éviter ce problème, vous devez renommer le fichier de l'application Python en supprimant les espaces et les caractères spéciaux avant de le télécharger. Par exemple, renommez wordcount (1).py en wordcount_1.py.

L'instruction préparée échoue pour les longues requêtes SQL en raison des limites de taille de l'en-tête dans IBM watsonx.data Presto

Les instructions préparées pour les requêtes SQL longues et complexes peuvent échouer lorsqu'elles sont exécutées par l'intermédiaire de Flight service ou de clients JDBC (par exemple, DBeaver). Cet échec est dû à des erreurs internes du serveur résultant du dépassement des limites par défaut de la taille de l'en-tête HTTP dans le moteur Presto. Le problème est reproductible dans Watsonx BI lors de l'enrichissement des données métriques avec des requêtes SQL d'une taille d'environ 14KB.

Il ne s'agit pas d'une limitation de PrestoDB, mais plutôt d'une conséquence du fonctionnement de l'API JDBC PreparedStatement. Lorsqu'un client ou un outil de veille stratégique utilise PreparedStatement,, le texte SQL et les métadonnées des paramètres sont sérialisés et transmis au coordinateur Presto dans le cadre des en-têtes de la requête HTTP. Ce comportement est standard pour les implémentations du pilote JDBC et n'est pas spécifique au moteur de requête de Presto.

Solution de contournement : Pour atténuer ce problème, envisagez les approches suivantes en fonction de votre charge de travail :

1. Augmenter les limites de taille des en-têtes

   Mettez à jour la configuration du moteur Presto avec les paramètres suivants pour prendre en charge des requêtes plus importantes :

   • http-server.max-request-header-size=128kB
   • http-server.max-response-header-size=128kB Ces propriétés sont déjà inscrites sur la liste blanche et peuvent être modifiées à l'aide de l'API de personnalisation.

   La valeur par défaut actuelle est définie en fonction de la taille typique des requêtes. Toutefois, l'augmentation par défaut de la taille limite de l'en-tête de la requête peut entraîner certains compromis. Une taille d'en-tête plus importante augmente le risque d'attaques par déni de service ( DoS DoS), car elle permet d'envoyer davantage de données dans chaque requête. De plus, chaque HTTP requête consommera davantage de mémoire, ce qui peut devenir significatif en cas de forte concurrence. Par conséquent, ces valeurs doivent être ajustées avec prudence en fonction de votre environnement et de vos schémas d'interrogation.

2. Évitez d'utiliser PreparedStatement pour les requêtes volumineuses

   Si votre outil de BI ou votre charge de travail a tendance à générer des requêtes SQL très volumineuses, envisagez de désactiver PreparedStatement et d'utiliser createStatement à la place. Cela évite de transmettre de grandes charges utiles SQL via les en-têtes HTTP et peut constituer une approche plus évolutive.

Milvus et Presto edit details page montre une erreur de serveur interne initialement après la création

Il se peut que vous rencontriez une erreur 500 Internal Server Error lorsque vous essayez de modifier la description sur la page de détails des moteurs Milvus et Presto peu de temps après avoir créé le moteur. Ce problème survient généralement lors des premières tentatives, car le système retarde la propagation de la politique en raison de la mise en cache.

Retard dans la mise à jour de la politique

Les mises à jour des politiques de la CPG et de l'AMS peuvent prendre un peu plus de temps pour être répercutées dans l'ensemble du système. Ce délai est dû à la nouvelle méthode de mise en cache et est un comportement attendu.

Le moteur Spark externe ne parvient pas à se connecter au stockage Amazon S3

Lors de l'utilisation d'un moteur Spark externe pour accéder aux données stockées dans un bucket amazon_s3 configuré avec l'authentification IAM basée sur les rôles, le moteur ne parvient pas à se connecter ou à récupérer les données.

La conversion des tableaux MOR en COW échoue dans Spark 4.0

La conversion de la table MOR en table COW n'est pas supportée par l'application Spark 4.0.

Solution de contournement : Utilisez les versions de Spark 3.4 ou 3.5 pour effectuer la conversion des tables MOR vers COW.

Le tableau de bord de prévisualisation affiche des valeurs nulles avec le moteur Presto (C++) en raison de la non-concordance des noms de colonnes du catalogue Hive

Le moteur Presto (C++) fait en sorte que le tableau de bord de prévisualisation affiche toutes les valeurs nulles pour certaines tables en raison d'une incohérence entre les noms de colonnes dans les fichiers Parquet et la configuration du catalogue Hive.

Solution : Appliquez la propriété de session suivante :

   set session [catalog_name].file_column_names_read_as_lower_case=true;

Les applications Manta ne fonctionnent pas sur Spark 4.0

Les applications Manta (Iceberg, Hudi, Hive, Delta) ne s'exécutent pas lorsqu'elles sont soumises à Spark 4.0.

Solution de contournement : Exécutez les applications Manta en utilisant d'autres versions de Spark disponibles.

Le test de connexion pour les connecteurs de flèches échoue dans les clusters compatibles FIPS

La connexion de test pour les connecteurs de flèches peut échouer lorsqu'elle est déployée dans des clusters compatibles FIPS en raison de restrictions cryptographiques. Cela concerne les connecteurs tels que Greenplum, MariaDB, et Salesforce, qui s'appuient sur des sources de données ou des bibliothèques sous-jacentes incompatibles avec le mode FIPS lors de la validation de la connexion.

Apache Kafka la connexion de test échoue dans les clusters compatibles FIPS

Pour Apache Kafka, la connexion de test peut échouer à moins que le SASL_MECHANISM ne soit explicitement défini sur " SCRAM-SHA-512 ". Ce mécanisme est compatible avec les exigences FIPS et doit être utilisé pour garantir la réussite des tests de connexion dans les environnements FIPS.

Caractères spéciaux non pris en charge dans la création de schémas et de tables via l'interface utilisateur d'Ingestion

Les caractères spéciaux suivants ne sont pas pris en charge lors de la création de schémas et de tables via l'interface utilisateur d'ingestion : % et + Ces restrictions sont appliquées en raison des limitations des moteurs de stockage sous-jacents tels que Hive, Delta et Hudi. Alors que la page du gestionnaire de données peut autoriser un plus grand nombre de caractères spéciaux (par exemple, !, @, #, &, _, -, =, +, ], }, <, et >), le flux d'ingestion applique une validation plus stricte pour garantir la compatibilité entre les services.

L'exécution de la requête échoue temporairement après la mise à jour d'identifiants de stockage ou de base de données expirés

Après la mise à jour d'informations d'identification expirées pour une ressource de stockage ou de base de données associée à un moteur Presto, l'exécution de la requête dans l'espace de travail de la requête échoue pendant environ 30 à 40 secondes. Après ce délai, les requêtes s'exécutent sans problème.

La tâche de synchronisation des statistiques reste bloquée pendant l'exécution

Les tâches de synchronisation des statistiques peuvent rester bloquées pendant l'exécution en raison de conditions inconnues. Lorsque cela se produit, les utilisateurs peuvent consulter les journaux pour voir l'état de la tâche dans l'optimiseur ou à l'adresse Db2. Si le statut du travail est NOTRECEIVED, NOTRUN ou UNKNOWN, les utilisateurs doivent forcer manuellement la suppression du travail.

Une fois le travail bloqué supprimé :

• Si des travaux se trouvent actuellement dans la liste des travaux en attente, le premier d'entre eux passera automatiquement dans la liste des travaux actifs et commencera à être exécuté.
• Si aucun travail n'est en file d'attente, les utilisateurs peuvent soumettre manuellement un nouveau travail.

Définitions des statuts :

• NOTRECEIVED: Le système n'a pas reçu d'appel pour l'ID de tâche donné.
• NOTRUN: Une erreur a empêché l'ordonnanceur d'invoquer la procédure de la tâche.
• UNKNOWN: La tâche a commencé à s'exécuter, mais l'ordonnanceur n'a pas enregistré le résultat en raison d'une condition inattendue.

Problème de compatibilité : Spark ne parvient pas à lire les tables d'icebergs écrites par presto avec Parquet V2

Spark ne parvient pas à lire les données insérées dans les tables iceberg par Presto lorsque Presto est explicitement configuré pour utiliser l'auteur Parquet V2. Ce problème survient parce que Spark ne prend pas en charge les lectures vectorisées pour certains encodages Parquet V2, tels que DELTA_BINARY_PACKED. Un message d'erreur typique est UnsupportedOperationException: Cannot support vectorized reads for column [CustomerID] optional int32 CustomerID = 1 with encoding DELTA_BINARY_PACKED. Disable vectorized reads to read this table/file at org.apache.iceberg.arrow.vectorized.parquet.VectorizedPageIterator.initDataReader(VectorizedPageIterator.java:98).

Solution : Si vous rencontrez cette erreur lors de la lecture d'une table, en particulier une table créée à l'aide de versions antérieures de watsonx.data, définissez la configuration Spark suivante.

   config("spark.sql.iceberg.vectorization.enabled", "false")

Limitation de l'interrogation de la table information_schema relative aux rôles pour les connecteurs tpcds ou tpch

Les utilisateurs rencontrent une erreur lorsqu'ils interrogent la table information_schema relative aux rôles pour les connecteurs tpcds ou tpch. Ce comportement est intentionnel et attendu pour ces connecteurs dans Presto, car tpcds et tpch sont des connecteurs de référence qui ne prennent pas en charge les fonctions de sécurité basées sur les rôles.

Solution : Pour éviter les erreurs, évitez d'interroger les tables information_schema liées aux rôles (telles que applicable_roles, enabled_roles et roles) pour les connecteurs tpcds ou tpch.

Utiliser des noms de schémas, de tables et de colonnes valides pour garantir la fiabilité des requêtes

Lors de la création de tables dans l'espace de travail Query, évitez d'utiliser des espaces en tête ou à la fin des noms de schémas, de tables ou de colonnes. Bien que la création puisse réussir, ces espaces supplémentaires peuvent entraîner des problèmes lors de l'interrogation ou de l'interaction. Pour garantir un fonctionnement régulier et fiable, utilisez toujours des noms propres sans espaces supplémentaires.

Limites de la prise en charge des BLOB et des CLOB dans les Presto

Presto peut lire et écrire dans des connecteurs qui comprennent des tables avec des colonnes BLOB et CLOB. Toutefois, il ne permet pas d'utiliser BLOB ou CLOB comme types de données de colonne dans les instructions CREATE TABLE.

Retard dans l'application des politiques de contrôle d'accès dans les Milvus

Il existe un délai entre la création de politiques de contrôle d'accès et leur mise en œuvre sur le site Milvus. Ce retard est dû au temps nécessaire à la synchronisation des politiques.

Les vues SQL ne peuvent pas être interrogées à travers les moteurs (Spark et Presto )

Les vues SQL créées par un moteur doté du catalogue iceberg Hive sont reconnues par les autres moteurs, mais ne peuvent pas être interrogées d'un moteur à l'autre, car un moteur ne peut pas comprendre le dialecte SQL d'un autre moteur.

Les détails du pilote et du groupe de ressources manquent dans la réponse de l'API Tiny Presto

L'API GET presto_engines renvoie actuellement null pour driver et resource_groups lors de l'interrogation de Tiny Presto engines, car la nouvelle architecture omet les détails du driver dans les appels get_presto_engine ; cependant, les utilisateurs existants peuvent toujours accéder aux informations sur le driver via le point de terminaison /driver_registration.

Impossible de supprimer les données des colonnes dont le nom contient des caractères spéciaux

Impossible de supprimer les données des colonnes dont le nom contient des caractères spéciaux, car les caractères spéciaux ne sont pas pris en charge dans les noms de colonnes de la clause WHERE.

L'erreur se produit après une utilisation prolongée de l'assistant watsonx.data

Après avoir utilisé watsonx.data Assistant pendant une période prolongée, il génère l'erreur suivante. There is an error with the message you just sent, but feel free to ask me something else.

Solution de contournement : Recharger le navigateur.

Impossible de réenregistrer SAL après avoir supprimé l'enregistrement existant

L'utilisateur non expérimental n'est pas en mesure de réenregistrer SAL après avoir supprimé l'enregistrement existant.

Solution de contournement : procédez comme suit :

1. Ajouter un accès pour l'utilisateur dans le compte IAM access cloud.

2. Utilisez l'API SAL suivante pour supprimer l'intégration.

   curl -X 'DELETE' \ 'https://api.dataplatform.cloud.ibm.com/semantic_automation/v1/wxd_integrations/<wxd-instance-id>' \ -H 'accept: */*' \ -H 'Authorization: Bearer <iam_bearer_token>'

3. Utilisez l'API suivante pour vérifier l'état de l'intégration et vous assurer que l'intégration est supprimée.

   curl -X 'GET' \ 'https://api.dataplatform.cloud.ibm.com/semantic_automation/v1/wxd_integrations/<wxd-instance-id>' \ -H 'accept: */*' \ -H 'Authorization: Bearer <iam_bearer_token>'

4. Réenregistrer SAL.

La création d'une table matérialisée dans l'espace de travail Query réussit mais échoue dans le notebook Spark en utilisant les mêmes permissions

Lors de la création d'une table matérialisée à l'aide d'une requête SQL dans l'espace de travail Query, l'opération est réussie. L'utilisateur a un accès en lecture au seau et aux politiques d'accès appropriées (insertion, mise à jour, sélection, suppression) pour le catalogue Iceberg par défaut. Cependant, lorsque la même instruction SQL est exécutée dans un notebook Spark à l'aide du modèle Spark watsonx.data, l'erreur suivante est générée : the action is not allowed.

Solution de contournement : Définissez la politique L3 pour le stockage iceberg-bucket dans la page Create access control policy.

Le seau QHMM ne s'associe au moteur que lorsque celui-ci est en marche

Si vous associez un catalogue QHMM au moteur pendant l'état de provisionnement, le système renverra une erreur indiquant que le catalogue n'existe pas du côté de l'aptitude au service. Cependant, le système associe automatiquement le catalogue QHMM lorsque le moteur est en marche.

Les utilisateurs peuvent rencontrer une erreur "test connection failure error due to invalid credentials"

Les utilisateurs peuvent rencontrer une erreur "test connection failure error due to invalid credentials" pour certaines sources de données même si les informations d'identification de la source de données sont correctes. Ce problème peut se produire malgré des informations d'identification valides, empêchant la réussite des tests de connexion pour les sources de données.

Solution : Si vous rencontrez cette erreur, vous devez contacter le support IBM.

L'absence de statistiques NDV dans les colonnes des tables Iceberg conduit à des plans de requête sous-optimaux

Dans la mise en œuvre actuelle, pour les tables Iceberg dans Presto ( Java ) et Presto (C++), les statistiques de la colonne NDV (Number of Distinct Values) ne sont pas utilisées lorsqu'elles sont disponibles dans MDS. Les NDV sont importants pour générer des plans d'interrogation optimaux. Sans eux, les performances peuvent se dégrader de manière significative.

Solution de contournement : Pour les tables non partitionnées, utilisez SET SESSION <iceberg_catalog>.hive_statistics_merge_strategy='USE_NULLS_FRACTION_AND_NDV';.

Cette solution ne s'applique pas aux tables partitionnées.

Limitation de la configuration du réseau privé virtuel

Les points de terminaison privés ne sont pas pris en charge pour les moteurs externes tels que IBM Db2 Warehouse, IBM Netezza et IBM Analytics Engine (Spark).

HDFS l'ajout de godets n'est pas pris en charge par le CPDCTL

L'ajout de buckets HDFS n'est actuellement pas pris en charge par le plugin cpdctl wx-data.

IBM watsonx.data Presto le connecteur dans Software Hub 5.1.1 et plus tard ne peut pas se connecter à IBM watsonx.data Cloud instance

IBM watsonx.data Presto connector ne parvient pas à se connecter à l'instance IBM watsonx.data en raison d'une erreur de 520 Cloudflare. Ce problème survient lorsque plusieurs appels simultanés sont effectués à l'API GET /engines, en particulier lorsque l'instance watsonx.data possède un grand nombre de politiques.

La modification des informations d'identification du seau d'origine du moteur Spark peut perturber les données et les opérations

La mise à jour des identifiants d'accès à une unité de stockage désignée comme unité de base du moteur Spark au cours du processus de provisionnement peut entraîner des problèmes d'accès aux données et des défaillances opérationnelles.

Les administrateurs du métastore et les observateurs du métastore ne peuvent pas voir les détails du schéma et de la table

Un utilisateur disposant des privilèges d'administrateur du métastore et de visualiseur du métastore dans l'espace de travail des requêtes et dans le gestionnaire de données ne peut pas afficher les détails du schéma et de la table, sauf si une stratégie d'affichage est définie pour les schémas et les tables.

Les scénarios d'évolution des schémas échouent dans Presto (C++)

Lorsque vous supprimez et/ou ajoutez des colonnes de table, les requêtes peuvent échouer. Par exemple, voir la séquence d'instructions ci-dessous, après laquelle les requêtes sur la table échouent.

   create table ice.s3.tessch.12 (age int, name varchar(25), place varchar(25)
   insert into ice.s3.tessch.t12 values (35, 'ken', 'paris')
   alter table ice.s3.tessch.t12 drop column age
   select * from ice.s3.tessch.t12
   alter table ice.s3.tessch.t8 add column place varchar(25)

Solution de contournement : Pour PARQUET, exécutez la commande suivante dans la session :

   set session <catalog-name>.parquet_use_column_names=true;

Remplacer <catalog-name> par le catalogue utilisé.

Ou définissez hive.parquet.use-column-names=true dans les propriétés du catalogue. Pour ORC, définissez hive.orc.use-column-names=true dans les propriétés du catalogue.

Problème avec le caractère turc majuscule İ dans la base de données Oracle utilisant le jeu de caractères WE8ISO8859P9 ( ORA-00911 Error)

Dans une base de données Oracle utilisant le jeu de caractères WE8ISO8859P9, le caractère turc majuscule İ n'est pas pris en charge dans le mode OFF (par défaut), ce qui entraîne des erreurs de caractères invalides ORA-00911:.

Solution de contournement : Mettez l'indicateur de cas mixte sur ON.

La vue d' information_schema s par défaut d'un catalogue répertorie les schémas et les tables d'autres catalogues

Si un utilisateur dispose de plusieurs catalogues, la vue d' information_schema s par défaut affichera également les schémas et les tables des autres catalogues, quels que soient les catalogues associés au moteur.

Hive les noms de colonnes externes avec des lettres majuscules de largeur complète ne peuvent pas être reconnus lorsque file-column-names-read-as-lower-case est défini sur true

Lorsque la propriété presto worker catalog file-column-names-read-as-lower-case est définie sur true, elle convertit les noms de champ en lettres ASCII majuscules en lettres ASCII minuscules. Par conséquent, les données dont les noms de colonnes comportent des caractères majuscules ne seront pas reconnues et apparaîtront comme « nulles ».

Échec de la tâche Spark en raison de l'expiration de la signature ADLS pendant l'opération d'écriture/suppression/mise à jour

Le job Spark échoue avec l'erreur suivante lorsqu'il effectue une opération d'écriture/suppression/mise à jour dans un stockage ADLS- Gen1. Cela se produit parce que la signature ADLS expire au milieu du processus. java.io.IOException: Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature

Solution: Définissez la durée d'expiration de la signature ADLS sur une valeur élevée. Configurez la propriété spark.hadoop.spark.hadoop.wxd.cas.sas.expiry.period pour contrôler le délai d'expiration de la signature ADLS. Mettez à jour la valeur par défaut de 300s à 43200s.

Presto Limitation de la taille du mot de passe CLI

Presto CLI prend en charge une taille de mot de passe maximale de 1 Ko (1 024 octets). Si le mot de passe dépasse cette taille, le système ne peut pas l'accepter dans le champ du mot de passe; il doit être exporté.

Le type de données timestamptz n'est pas pris en charge pour une table ORC lors de la mise à jour de la console web watsonx.data.

Les noms de bases de données contenant des tirets ou des espaces ne peuvent pas être interrogés par le moteur Spark dans un notebook d' Python, même lorsque l'extension de contrôle d'accès Spark appropriée a été ajoutée.

Les conditions commerciales restent en vigueur après la suppression de l'intégration de la couche d'automatisation sémantique d' IBM watsonx.data

Les termes commerciaux qui ont été importés dans IBM Knowledge Catalog pour une intégration de la couche d'automatisation sémantique (SAL) dans watsonx.data ne sont pas supprimés lorsque l'intégration est supprimée. Cela peut entraîner la duplication des conditions commerciales si une nouvelle intégration SAL est ensuite activée et que des conditions commerciales identiques ou similaires sont à nouveau téléchargées.

Solution: pour éviter la duplication des termes commerciaux, l'administrateur de cluster ou l'utilisateur qui a créé l'enregistrement SAL doit supprimer manuellement tous les termes commerciaux importés pour l'intégration SAL.

La clause EXISTS sur les tables d' Apache Phoenix s génère une exception lors de l'exécution de la requête

Les requêtes impliquant la clause EXISTS sur les tables d' Apache Phoenix s peuvent échouer de manière inattendue, même lorsque la colonne référencée est valide. Cela est dû aux limites de l'interprétation de la clause EXISTS par l' Apache Phoenix, en particulier dans les cas où les structures de requête sont ambiguës ou mal alignées.

Solution de contournement : pour remédier à cette limitation, appliquez l’une des stratégies suivantes :

• Établir une relation claire entre la sous-requête et la requête principale. Introduire une condition de filtre dans la sous-requête pour créer une relation significative entre la sous-requête et la requête principale. Par exemple, lorsque department_id_bigint n'est PAS NULL dans la sous-requête. Pour plus d'informations, reportez-vous à l'exemple suivant :

  SELECT DISTINCT t1.first_name_varchar, t2.performance_rating_real, t1.team_head_varchar
  FROM phoenix.tm_lh_engine.employee t1, phoenix.tm_lh_engine.departments t2
  WHERE EXISTS (
     SELECT 1
     FROM phoenix.tm_lh_engine.departments
     WHERE department_id_bigint IS NOT NULL
  )
  

• Établir une relation claire entre les tables concernées en les joignant explicitement dans la sous-requête. Cela garantit que la sous-requête est contextuellement pertinente et résout le problème d'exécution. Par exemple, où t3.department_id_bigint = t2.department_id_bigint dans la sous-requête. Pour plus d'informations, reportez-vous à l'exemple suivant :

  SELECT DISTINCT t1.first_name_varchar, t2.performance_rating_real, t1.team_head_varchar
  FROM phoenix.tm_lh_engine.employee t1, phoenix.tm_lh_engine.departments t2
  WHERE EXISTS (
     SELECT 1
     FROM phoenix.tm_lh_engine.departments t3
     WHERE t3.department_id_bigint = t2.department_id_bigint
  )
  

Le catalogue Hive ne prend pas en charge le format CSV pour la création d'une table avec une colonne de type int

Le catalogue Hive ne prend pas en charge le format CSV pour la création d'une colonne de type int. L'erreur suivante s'affiche :

presto> create table  hive_data.hive_schema.intcsv ( type int ) with ( format = 'CSV' ) ;
Query 20241017_021409_00059_fmcyt failed: Hive CSV storage format only supports VARCHAR (unbounded). Unsupported columns: type integer

Solution: Utilisez les options suivantes pour le catalogue Hive:

• Créer une table en varchar.
• Créez une vue qui convertit les colonnes dans leurs types de données d'origine.

Comportement incohérent lors de l'ingestion de fichiers CSV et Parquet

Bien que les spécifications de conception indiquent que les fichiers CSV ne doivent être intégrés que dans des tables créées à partir de fichiers CSV et que les fichiers parquet ne doivent être intégrés que dans des tables créées à partir de fichiers parquet, il existe une divergence dans le comportement réel des utilisateurs qui peuvent intégrer des fichiers CSV dans des tables parquet. Cela peut entraîner des résultats inattendus, des problèmes de qualité des données ou des problèmes de performance si le schéma ou le formatage du fichier CSV ou parquet ne correspond pas à la structure attendue de la table cible.

Associations de fichiers invalides dans le groupe de ressources Presto à travers l'interface utilisateur et problèmes de redémarrage du moteur

Lorsqu'un fichier invalide est associé à un moteur dans le groupe de ressources Presto via l'interface utilisateur watsonx.data, le moteur est redémarré. Cependant, l'interface utilisateur peut afficher de manière incorrecte que le moteur utilise le nouveau fichier attribué.

Modèle de contournement: Si vous constatez que le nouveau fichier n'est pas associé à l'environnement watsonx.data, contactez l'assistance IBM pour obtenir de l'aide supplémentaire.

Prise en charge des types de données temporelles dans Hive et Iceberg

Hive: Le catalogue Hive ne prend pas en charge le type de données time.

Iceberg : Iceberg prend en charge le type de données temps.

Solution: Pour permettre le traitement correct des données temporelles dans les tables Iceberg, la propriété " hive.parquet-batch-read-optimization-enabled " doit être définie sur " false".

Les fichiers ayant des schémas différents produisent des valeurs nulles

watsonx.data prend désormais en charge l'ingestion des types de fichiers pris en charge avec différents schémas. Toutefois, lorsque les colonnes de ces fichiers ont des schémas distincts, les valeurs de ces colonnes sont définies comme nulles.

Caractères spéciaux non pris en charge dans la création de schémas, de tables et d'emplacements de stockage

Les caractères spéciaux suivants ne sont pas pris en charge lors de la création de schémas, de tables et d'emplacements de stockage :

Schémas ( Hive et Iceberg): $, ^, +, ?, *, {, [, (, ) et /.

Tables ( Hive ): $ ^, +, ?, *, {, [, (, ), /, }, ", et '(La création de tables dans un nom de schéma qui commence par le caractère spécial @ entraînera une erreur).

Tables (Iceberg):$, ^, +, ?, *, {, [, (, ), /, @, }, ", et '.

Lieu de stockage : $ ^, +, ?, *, {, [, (, }, @, ", et '.

Il est recommandé de ne pas utiliser de caractères spéciaux tels que le point d'interrogation (?), le tiret (-), l'astérisque (*) ou les caractères délimiteurs tels que \r, \n, et \t dans les noms de tableaux, de colonnes et de schémas. Bien que ces caractères spéciaux soient pris en charge et que des tables, des colonnes et des schémas puissent être créés, leur utilisation peut poser problème lors de l'exécution de la commande INSERT ou de l'application de politiques d'accès pour celle-ci.

Pour garantir une expérience fluide, veuillez suivre la liste ci-dessous :

• Les noms de schéma peuvent contenir des lettres, des chiffres ou l'un des éléments suivants : !, #, &, ], }, <, >, =, % et @.
• Les noms de tables peuvent contenir des lettres, des chiffres ou l'un des caractères suivants : !, #, &, ], }, <, >, = et ;.
• Les colonnes peuvent contenir des lettres, des chiffres, un des caractères suivants : !, #, &, [, ], < >, _, : et @.

ALTER TABLE l'opération échoue dans la soumission d'un job Spark

Les jobs Spark qui créent un schéma, une table, puis tentent une opération ALTER TABLE peuvent rencontrer un authz.AccessControlException en raison de permissions insuffisantes.

Cela se produit parce que, même si la création du schéma et de la table est réussie, le job tente d'exécuter l'opération ALTER TABLE avant que les données du métastore ne soient mises à jour avec les détails du schéma et de la table nouvellement créés.

Modèle de contournement: Pour éviter les erreurs de refus d'accès, vous devez prévoir un délai entre chaque opération impliquant la création de nouveaux schémas ou tables dans le même Python.

Solution : Vous pouvez désactiver le DAS ou vous assurer que vos buckets ou le stockage d'objets sont configurés avec des points d'extrémité HTTPS.

La tentative de lecture des tables Parquet v2 par Presto (C++) entraîne une erreur

Lorsque vous tentez de lire les tables Parquet v2 via Presto (C++) qui ont été créées via le gestionnaire de données dans watsonx.data, vous obtenez l'erreur suivante :

Error in ZlibDecompressionStream::Next

Contournement: Presto (C++) ne prend actuellement pas en charge la lecture des tables Parquet v2. Vous devez copier les données dans un nouveau tableau au format v1 pour qu'elles soient compatibles avec la lecture à l'aide de Presto (C++).

1. Définissez la propriété de la session à PARQUET_1_0:

   set session <catalog_name>.parquet_writer_version = 'PARQUET_1_0';
   

2. Exécutez la commande suivante pour copier les données dans une nouvelle table :

   create table <catalog name>.<schema name>.<table name> as (select * from <originaltablename>;
   

Actuellement, l'ingestion Spark ne prend pas en charge les caractères spéciaux tels que les guillemets, les tics arrière et les parenthèses pour les noms de colonnes des tables partitionnées.

Les tentatives d'interrogation des tables liées à la gestion de l'historique et du suivi des requêtes (QHMM) à l'aide des moteurs Presto (C++) peuvent donner lieu à des erreurs

Lorsque vous tentez d'interroger les tables liées au QHMM à l'aide des moteurs Presto (C++), vous pouvez rencontrer des erreurs dues à des formats de fichiers non pris en charge. Presto (C++) ne supporte que les formats Parquet v1. Vous ne pouvez pas utiliser Presto (C++) pour interroger des données ou des tables dans d'autres formats.

Contournement: Vous pouvez utiliser les moteurs Presto (Java) pour interroger les tables liées au QHMM.

Erreur de limite de simultanéité du serveur atteinte dans le serveur de vol

Il se peut que vous rencontriez une erreur "Server concurrency limit reached" lorsque vous utilisez le serveur de vol pour exécuter des requêtes. Cela se produit lorsque le serveur connaît une utilisation élevée de la mémoire en raison d'un grand nombre de requêtes simultanées.

Solution : Augmentez le nombre de nacelles de vol ou restructurez pour simplifier les requêtes afin de réduire le nombre de sous-requêtes. Ajustez le nombre de répliques en fonction de la charge de votre système et des ressources disponibles.

Utilisez la commande suivante pour augmenter le nombre de pods pour le déploiement wdp-connect-flight:

oc scale deployment wdp-connect-flight --replicas=<number of replicas>

Par exemple, si vous devez augmenter le nombre de modules à 36, exécutez la commande suivante :

oc scale deployment wdp-connect-flight --replicas=36

Reconnaissance incorrecte des dates grégoriennes dans Presto avec Hive tables Parquet

Presto présente des problèmes lors du traitement de dates historiques antérieures à 0200-01-01, en particulier lorsqu'elles sont stockées dans des tables Hive formatées en Parquet. Ce problème est dû à la conversion entre les calendriers grégorien et julien, qui ont été mis en œuvre dans 1582-10-15. Les dates antérieures à cette date limite sont mal interprétées par Presto.

Informations incomplètes sur la longueur des colonnes dans la sortie SHOW COLUMNS

La requête SHOW COLUMNS dans Presto fournit actuellement des informations sur les colonnes, notamment le nom, le type de données, les détails supplémentaires (extra) et les commentaires. Ce problème met en évidence le fait que la fonctionnalité existante manque de détails sur la longueur des types de données à base de caractères (CHAR et VARCHAR). Si certains connecteurs renvoient la longueur réelle définie lors de la création de la table, d'autres peuvent fournir une valeur par défaut ou aucune information.

Pour remédier à cette limitation, trois nouvelles colonnes ont été ajoutées à la sortie SHOW COLUMNS:

• Échelle : Applicable au type de données DECIMAL, indiquant le nombre de chiffres après la virgule.

• Précision : Applicable aux types de données numériques, spécifiant le nombre total de chiffres. (Valeur par défaut : 10)

• Longueur : Destinée aux types de données CHAR et VARCHAR, elle représente le nombre maximal de caractères autorisés.

Limitations actuelles :

• La longueur indiquée dans la colonne Length peut ne pas toujours refléter la taille réelle définie dans le schéma de la table en raison des limitations du connecteur.

• Les connecteurs qui ne fournissent pas d'informations sur la longueur afficheront une valeur par défaut ou nulle selon le connecteur.

Erreur de calcul pour OPT_SORTHEAP dans Query Optimizer

En raison d'une erreur de calcul dans les paramètres de configuration de Query Optimizer pour la valeur de OPT_SORTHEAP, les performances de Query Optimizer peuvent être affectées.

Modèle de contournement: Pour résoudre l'erreur de calcul pour OPT_SORTHEAP dans Query Optimizer, effectuez les étapes suivantes pour mettre à jour la configuration de OPT_SORTHEAP= <initial_value> à OPT_SORTHEAP <initial_value>/20.

1. Configurez la variable d'environnement PROJECT_CPD_INSTANCE pointant vers l'espace de noms où watsonx.data est installé.

export PROJECT_CPD_INSTANCE=<wxd_namespace

2. Modifiez la valeur de OPT_SORTHEAP en OPT_SORTHEAP <initial_value>/20 en exécutant la commande suivante.

oc edit db2uinstance lakehouse-oaas -n $PROJECT_CPD_INSTANCE

3. Attendez un peu que le STATE se transforme en Ready pour le lakehouse-oaas et exécutez la commande suivante.

watch "oc get db2uinstance  -n $PROJECT_CPD_INSTANCE"

Limites -Presto (C++)

• Presto Le moteur (C++) ne prend actuellement pas en charge les catalogues de bases de données.
• Parquet est le seul format de fichier pris en charge.
• Hive Le connecteur est pris en charge.
• La table Iceberg par défaut ne prend en charge que la lecture au format Parquet v1.
• Les requêtes TPC-H/TPC-DS sont prises en charge.
• DELETE FROM et CALL SQL les déclarations ne sont pas prises en charge.
• START,COMMIT, et ROLLBACK les transactions ne sont pas prises en charge.
• Types de données CHAR,TIME, et TIME WITH TIMEZONE ne sont pas pris en charge. Ces types de données sont subsumés par VARCHAR,TIMESTAMP, et TIMESTAMP WITH TIMEZONE.
  • IPADDRESS,IPPREFIX,UUID,kHYPERLOGLOG,P4HYPERLOGLOG,QDIGEST, et TDIGEST ne sont pas pris en charge.
  • VARCHAR ne prend en charge qu’une longueur limitée.Varchar(n) avec une limite de longueur maximale n'est pas pris en charge.
  • TIME et TIME WITH TIMEZONE est soutenu dans le développement communautaire.
  • TIMESTAMP les colonnes des fichiers Parquet ne peuvent pas être lues.
• Fonctions scalaires :
  • IPFunctions,QDigest,HyperLogLog et l'internationalisation géospatiale ne sont pas pris en charge.
• Fonctions agrégées :
  • QDigest, les métriques de classification et l'entropie différentielle ne sont pas prises en charge.
• S3 etS3 les systèmes de fichiers compatibles (en lecture et en écriture) sont pris en charge.

Presto (C++) ne parvient pas à interroger une table partitionnée externe

Lorsque vous interrogez une table externe avec CHAR colonnes de type de données, la requête ne parvient pas à s'exécuter. Ce problème se produit en raison de la limitation quePresto (C++) ne prend pas en charge CHAR Types de données.

Modèle de contournement: Remplacez la colonne CHAR data type par VARCHAR data type.

Accès aux tables Hive et Iceberg dans le même catalogue de métamagasin glue

Lors de l'utilisation duAWS Glue Data Catalog pour gérer un compartiment ou un emplacement de stockage contenant à la fois Iceberg etHive tables, en essayant d'accéder aux tables Iceberg à partir duHive le catalogue donne,Not a Hive table erreur et tentative d'accèsHive les tableaux du catalogue Iceberg donnent,Not an Iceberg table erreur.

Utiliser l'ID comme nom de colonne dansCassandraCREATE TABLE

DansCassandra, vous ne pouvez pas créer une table avec une colonne nommée ID tout en utilisant unCassandra connecteur à traversPresto. Ceci est dû au fait ID est un mot-clé réservé auCassandra pilote utilisé parPresto, qui génère automatiquement un UUID pour chaque ligne. Toute tentative de création d'une table avec un ID de nom de colonne entraîne un message d'erreur indiquant une déclaration de colonne en double comme suit : Colonne en double id déclaration pour la table tm_lakehouse_engine_ks.testtable12

Contournement: Évitez d'utiliser ID comme nom de colonne lorsque vous créez des tables Cassandra via Presto.

Le rôle d'utilisateur avec la politique CreateCollection L3 ne parvient pas à créer une collection dans Milvus

Les utilisateurs de User role qui créent des collections dans Milvus avec pymilvus peuvent échouer lorsqu'ils utilisent les méthodes ORM Connection et MilvusClient Connection.

Contournement: Vous devez suivre les instructions :

ORM Connection  : L'utilisateur a besoin des deuxDescribeCollection etCreateCollection privilèges accordés dans leL3 page de politique. Vous devez sélectionner toutes les collections dans une base de données tout en accordant DescribeCollection privilège dans leL3 politique via la console Web.

MilvusClient Connection: Seulement CreateCollection le privilège est nécessaire dans leL3 page de politique. Cependant, la première tentative de création d’une collection échouera.

1. Exécutez le create_collection fonctionner une fois.
2. Réexécutez le create_collection fonctionner à nouveau. Cela permet aux stratégies de se synchroniser et la création de la collection réussira.

Caractères spéciaux et casse mixte impactant la synchronisation des données

Lors de la synchronisation de données entre des compartiments contenant des tables ou des schémas comportant des caractères spéciaux ou des lettres de casse mixtes dans leurs noms, vous pouvez rencontrer les comportements inattendus suivants :

• Tableaux ou schémas avec certains caractères spéciaux %,,,{,),(,@,$,[,: verront leurs données entièrement ignorées lors de la synchronisation.
• Les tableaux ou schémas avec des lettres mixtes ou majuscules seront convertis en minuscules avant la synchronisation.

Solution palliative: évitez d'utiliser des caractères spéciaux et des majuscules et des minuscules dans les noms de table et de schéma. Renommez les tables et les schémas existants pour n'utiliser que les caractères pris en charge.

Validation de données manquante pour les noeuds finaux de stockage Amazon S3

Actuellement, l'interface utilisateur n'effectue pas de validation de données pour les noeuds finaux associés au type de stockage Amazon S3.

Utilisation d'alias incorrecte dans la clause WITH et USE catalog.schema

Clause WITH: lors du référencement de données dans la clause WITH, utilisez le nom d'alias exact affecté lors de sa définition. L'utilisation d'un alias incorrect déclenche le message d'erreur suivant.

Schema must be specified when session schema is not set

Utilisation de USE catalog.schema avec la clause WITH: lorsque des tables sont spécifiées à l'aide de WITH et USE catalog.schema, les requêtes avec des noms d'alias incorrects génèrent l'erreur suivante.

Table does not exist

Interprétation littérale de chaîne dansPresto (Java )

Presto (Java ), interprète par défaut les chaînes littérales comme VARCHAR, contrairement à de nombreux autres systèmes de bases de données qui les traitent comme CHAR.

DansPresto (Java ), les comparaisons de chaînes sont effectuées sur les caractères réels présents dans la chaîne, à l'exclusion des espaces de fin. Les requêtes peuvent alors renvoyer des résultats incorrects lors de l'utilisation de chaînes pouvant contenir des espaces de fin, car ces espaces ne sont pas pris en compte lors de la comparaison.

Noms de table avec plusieurs points

Presto (Java ) ne prend pas en charge la création ou l'interrogation de noms de tables contenant au moins trois points consécutifs dans leur nom. Les tentatives de référencement de ces tables dans les requêtes peuvent générer des erreurs.

L'utilisateur est toujours visible dans la page de contrôle d'accès d'un moteur après avoir supprimé l'utilisateur d'IAM.

L'authentification LDAP n'est pas prise en charge pour le connecteur Teradata.

Le connecteur watsonx.data Teradata ne prend actuellement pas en charge LDAP (Lightweight Directory Access Protocol) pour l'authentification d'utilisateur.

Solution: Si vous rencontrez l'erreur 502, rechargez la page de l'interface utilisateur de l'historique Spark après une attente de 1 à 5 secondes. Cela devrait laisser suffisamment de temps pour que le serveur soit opérationnel.

Anomalie de création de schéma de catalogue croisé dans Presto.

Une anomalie existe dans la création de schémas pour les catalogues Hive et Iceberg gérés par Presto. Lors de l'utilisation d'un service de métastore Hive commun pour plusieurs catalogues (par exemple, un catalogue Iceberg et un catalogue Hive, ou deux catalogues Iceberg ou Hive ), la création d'un schéma dans un catalogue peut entraîner sa création dans un catalogue erroné. Cela se produit si l'emplacement spécifié lors de la création du schéma appartient à un catalogue différent de celui prévu.

Solution : Vous devez toujours fournir explicitement le chemin de stockage correct associé au catalogue cible lors de l'utilisation d'instructions CREATE SCHEMA dans Presto. Cela garantit que le schéma est créé à l'emplacement souhaité.

Presto (Java ) requêtes avec de nombreuses colonnes et une taille dépassant la limite par défaut.

Presto (Java ) requêtes impliquant plusieurs tables avec un grand nombre de colonnes (par exemple, 1 000 colonnes par table ou plus) dans le SELECT Cette clause peut rencontrer des problèmes de performances dans tous les environnements de déploiement.

L'optimiseur itératif arrive à expiration lorsque max_reorder_joins est défini sur 5 ou une valeur supérieure (le délai d'attente par défaut est de 3 minutes) et génère l'erreur suivante:

The optimizer exhausted the time limit of 180000 ms

Pour les requêtes dépassant la valeur par défaut max-task-update-size limite (16MB dansPresto (Java )), vous pourriez observer un TaskUpdate size exceeding this limit erreur (la valeur spécifique de la limite dépend de la requête réelle).

Solution de contournement :

• Vous pouvez améliorer les performances des requêtes en désactivant temporairement la règle reorder_joins à l'aide de la propriété de session suivante:

  set session reorder_joins = false;
  

• Augmenter le max-task-update-size valeur dans le config.properties déposer si le problème implique un TaskUpdate size exceeding the limit erreur et redémarragePresto (Java ).

Exemple :

experimental.internal-communication.max-task-update-size=64MB

Limitation: les transactions ne sont pas prises en charge dans les bases de données Informix non consignées.

Dans watsonx.data, lorsque vous tentez d'exécuter des requêtes ayant des implications transactionnelles sur des bases de données Informix non consignées, les requêtes échouent. En effet, les bases de données Informix non consignées ne prennent pas en charge les transactions.

Limitation: limitation de l'instruction INSERT Netezza Performance Server.

Netezza Performance Server ne prend actuellement pas en charge l'insertion de plusieurs lignes directement dans une table à l'aide de la clause VALUES. Cette fonctionnalité est limitée aux insertions d'une seule ligne. Pour plus de détails sur l'instruction INSERT, voir le Netezza Performance Server documentation officiel.

L'exemple suivant utilisant VALUES pour plusieurs lignes n'est pas pris en charge:

INSERT INTO EMPLOYEE VALUES (3,'Roy',45,'IT','CityB'),(2,'Joe',45,'IT','CityC');

Solution palliative: utilisez une sous-requête avec SELECT et UNION ALL pour construire un ensemble de résultats temporaire et l'insérer dans la table cible.

INSERT INTO EMPLOYEE SELECT * FROM(SELECT 4,'Steve',35,'FIN','CityC' UNION ALL SELECT 5,'Paul',37,'OP','CityA') As temp;

Problème : Milvus ne répond pas aux demandes de renseignements.

Milvus peut ne pas répondre aux requêtes lorsqu'il tente de charger des collections ou des partitions qui dépassent la capacité de mémoire disponible. En effet, toutes les opérations de recherche et d'interrogation dans Milvus sont exécutées en mémoire, ce qui nécessite le chargement de l'ensemble de la collection ou de la partition avant l'interrogation.

Solution de contournement :

• Tenez compte des limites de mémoire de votre déploiement Milvus et évitez de charger des collections ou des partitions trop volumineuses.

• Si Milvus ne répond plus aux requêtes, utilisez l'API Milvus appropriée pour décharger ou libérer certaines collections de la mémoire. Un exemple utilisant le SDK Python: collection.release()

Problème : Décompte inexact des lignes après les suppressions dans Milvus.

La propriété collection.num_entities peut ne pas refléter le nombre réel de lignes dans une collection Milvus après les opérations de suppression. Cette propriété fournit une estimation et ne peut pas prendre en compte les entités supprimées.

Pour obtenir un nombre précis de lignes, exécutez une requête count(*) sur la collection. Cela fournit un comptage précis même après les suppressions.

Syntaxe Pymilvus:

collection = pymilvus.Collection(...)
collection.query(expr='', fields=['count(*)'])

Limitations: Opérations Db2 non prises en charge.

watsonx.data ne prend actuellement pas en charge l'opération ALTER TABLE DROP COLUMN pour les tables organisées par colonnes Db2.

Par défaut, Db2 les instances créent des tables au format organisé en colonnes.

watsonx.data ne prend pas en charge la création de tables organisées par lignes dans Db2.

Limitations: Traitement des valeurs nulles dans Elasticsearch.

Le connecteur Elasticsearch requiert une définition explicite des mappages d'index pour que les zones traitent les valeurs null lors du chargement des données.

Limitations: Chargement de JSON imbriqué avec Elasticsearch.

Le connecteur Elasticsearch requiert que les utilisateurs spécifient explicitement les structures JSON imbriquées sous forme de tableaux de type ROW pour le chargement et l'interrogation appropriés. Pour traiter ces structures, utilisez l'opération UNNEST.

Limitation : Les utilisateurs peuvent créer 3 instances du service Milvus pour une seule instance de watsonx.data dans IBM Cloud

Problème : Impossible de créer des vues dans Presto.

Presto décrit une vue dans une base de données mappée comme une TABLE plutôt qu'une VUE. Ceci est apparent pour le programme JDBC qui se connecte au moteur Presto.

Problème: L'utilisateur n'est pas supprimé du contrôle d'accès au catalogue lors de la révocation de l'accès aux données.

Lorsque vous accordez un accès utilisateur à un utilisateur en l'ajoutant aux stratégies de contrôle des données à l'aide de l'écran Contrôle d'accès, l'utilisateur est correctement répertorié dans le catalogue. Lors de la révocation de l'accès utilisateur à partir de la page Contrôle d'accès, l'utilisateur reste répertorié dans le catalogue et dispose toujours de l'accès utilisateur.

Problème : Impossible d'afficher les catalogues attendus à partir dePresto (Java ).

Les utilisateurs disposant de privilèges d'administrateur ne peuvent pas afficher les informations attendues.Hive etPostgreSQL catalogues dePresto (Java ).

Problème: L'interface utilisateur de la console répertorie les utilisateurs non valides.

watsonx.data utilisateur (user1 ) invite un nouvel utilisateur (user2 ) au compte en utilisant le Gérer les accès et les utilisateurs écran (Gérer > Accès (IAM) > Gérer l'accès et les utilisateurs ) et donne accès à un rôle (MetastoreAccess, Visionneuse, Opérateur, Editeur, Administrateur). User2 obtient l'accès aux ressources de l'instance watsonx.data via le compte user1. De plus, l'utilisateur user2 se voit accorder un accès aux données au niveau de la ressource en l'ajoutant aux stratégies de contrôle des données à l'aide de l'écran Contrôle d'accès. Lorsque user1 supprime user2 du compte user1, user2 est toujours répertorié dans l'onglet Contrôle d'accès au niveau de la ressource.

Problème: Impossible d'afficher le schéma créé.

Lorsqu'un utilisateur disposant du rôle Utilisateur et de l'accès Créer (l'utilisateur ne dispose que de l'accès Créer) est ajouté à une base de données externe, il ne peut pas voir les schémas qu'il a créés. Bien que l'utilisateur puisse créer des schémas, il ne peut pas les afficher. La réponse du système est la suivante:

presto:default> show schemas;
Schema
--------
(0 rows)

Solution palliative: Fournissez un privilège de sélection pour le schéma créé par l'utilisateur.

Problème: Accès refusé lors de l'interrogation d'une base de données externe.

Lorsqu'un utilisateur disposant du rôle Utilisateur et de l'accès Créer (l'utilisateur dispose uniquement de l'accès Créer) est ajouté à une base de données externe, il ne peut pas exécuter la requête de sélection à partir de la table qu'il a créée. Bien que l'utilisateur puisse se connecter auPresto (Java ) et créent des tables et des schémas, ils ne peuvent pas interroger la table. Le système affiche un message Access Denied.

Query 20230608_132213_00042_wpmk2 failed: Access Denied: Cannot select from columns [id] in table or view tab_appiduser_01

Solution palliative: Fournissez un privilège de sélection pour la table créée par l'utilisateur.

Problème: Schéma créé sous un catalogue différent.

Les schémas sont disponibles dans les catalogues Iceberg et Hive. Lorsqu'un schéma est créé sous le catalogue Iceberg, il est répertorié sous le catalogue Hive et vice versa.

Problème:Presto (Java ) ne prend pas en charge la suppression des tables Iceberg.

Problème: DROP SCHEMA dans Db2.

Dans Db2, le schéma ne peut être supprimé que s'il est vide. Le lancement d'une instruction DROP SCHEMA sur un schéma non vide peut entraîner une Db2 SQLCODE=-478 et SQLSTATE=42893.

Problème: L'instruction CREATE VIEW qui est partiellement prise en charge par Db2.

Le connecteur Db2 prend partiellement en charge l'instruction CREATE VIEW. LePresto (Java ) la syntaxe SQL prise en charge n'inclut pas la création de vues avec des noms de colonnes personnalisés (différents des noms de colonnes de la table).

Problème: instruction CREATE VIEW partiellement prise en charge par NPSaaS.

Le connecteur NPSaaS prend partiellement en charge l'instruction CREATE VIEW. LePresto (Java ) La syntaxe SQL prise en charge n'inclut pas la création de vues avec des noms de colonnes personnalisés (différents des noms de colonnes de la table).

Problème:Presto (Java ) ne reconnaît pas le chemin comme un répertoire.

Lorsque vous créez une nouvelle table avec unPresto (Java )Hive connecteur qui utilise unS3 dossier à partir d'un emplacement externe,Presto (Java ) ne reconnaît pas le chemin en tant que répertoire et une erreur peut se produire.

Par exemple, lors de la création d'une table client dans le répertoire cible DBCERT/tbint dans un compartiment appelé dqmdbcertpq à l'aide de la console IBM Cloud UX et Aspera S3, l'erreur suivante est détectée: External location must be a directory.

CREATE TABLE "hive-beta"."dbcert"."tbint" (
RNUM int , CBINT bigint
) WITH (
format='PARQUET', external_location = 's3a://dqmdbcertpq/DBCERT/tbint'
);
Query 20230509_113537_00355_cn58z failed: External location must be a directory

Les objets d'un système de fichiers sont stockés en tant qu'objets et leur chemin d'accès. L'objet et le chemin doivent être associés à des métadonnées. Si le chemin n'est pas associé aux métadonnées,Presto (Java ) ne parvient pas à reconnaître l'objet et répond que le chemin n'est pas un répertoire.

Problème: attribution d'un privilège d'octroi ou de révocation.

L'affectation du privilège Accorder ou Révoquer à un utilisateur via une règle d'accès ne fonctionne pas comme prévu dans les scénarios suivants:

1. User_A ajoute un compartiment et un catalogue Hive (par exemple, useracat02).

2. User_A crée un schéma et une table.

3. Les rôles User_B et User_C sont affectés à User dans le catalogue.

4. User_A ajoute une règle d'octroi d'autorisation à User_B.

5. User_B se connecte au catalogue et exécute grant select sur User_C.

   presto:default> grant select on useracat02.schema_test_01.tab_1 to "6ff74bf7-b71b-42f2-88d9-a98fdbaed304";
   

6. Lorsque l'utilisateur C se connecte au catalogue et exécute la commande select sur la table, la commande échoue avec un message d'accès refusé.

   presto:default> select * from useracat02.schema_test_01.tab_1;
   Query 20230612_073938_00132_hthnz failed: Access Denied: Cannot select from columns [name, id, salary, age] in table or view tab_1
   

Problème: Création d'un schéma sans emplacement.

Lorsque vous créez un schéma sans emplacement, il n'est pas répertorié dans la liste des schémas d'un catalogue. Par exemple, si vous créez un schéma sans spécifier l'emplacement du compartiment, le schéma est créé dans HMS et non dans le compartiment. Lorsque vous essayez de créer un nouveau schéma avec le même nom, il échoue et répond que le schéma existe déjà.

Solution palliative: Indiquez l'emplacement du compartiment lors de la création d'un schéma.

Problème: Noms uniques pour le schéma et le compartiment.

Un schéma et un compartiment ne peuvent pas être créés avec le même nom. Par exemple, si vous créez un schéma nommé "sales" dans un catalogue, le même nom ne peut pas être utilisé pour un autre schéma dans un autre catalogue. De même, si vous enregistrez un compartiment avec le nom "salesbucket", un autre compartiment avec le même nom ne peut pas être enregistré, même si le compartiment se trouve dans une librairie différente.

Solution palliative: Utilisez des noms uniques lors de la création de schémas et de compartiments.

Problème: Création d'un schéma pour la table cible.

Vous devez créer un schéma pour la table cible si le schéma n'existe pas.

Problème: L'ingestion échoue si le fichier CSV contient un enregistrement incorrect.

L'outil ibm-lh ne prend pas en charge l'omission du nombre maximal d'enregistrements incorrects pour les fichiers CSV si la zone de non-concordance est supérieure à la définition de table.

Problème: Création de l'emplacement de schéma avec le chemin.

Utilisez l'une des options d'emplacement suivantes lors de la création d'un schéma:

• Emplacement pointant vers un compartiment / sous-chemin sans / de fin.
• Emplacement pointant vers un compartiment / sous-chemin avec un / de fin-Recommandé pour une meilleure structuration.

Bien que vous puissiez utiliser un emplacement pointant vers un compartiment uniquement avec ou sans / de fin, cela peut entraîner un échec. Par conséquent, il est recommandé d'utiliser un sous-chemin.

Problème:Presto (Java ) ne supporte pas AS OF avec des tables d'icebergs.

Presto (Java ) ne supporte pas AS OF <time stamp> commande dans une requête SELECT.

Solution palliative: Appelez CALL iceberg_data_rollback_to_snapshot pour passer à l'horodatage requis.

Si vous utilisez CALL iceberg_data_rollback_to_snapshot avec un horodatage, vous ne pouvez pas appeler la procédure mémorisée pour passer à un horodatage ultérieur. Utilisez Spark SQL comme alternative.

Problème: Seul le créateur dispose d'un accès DROP sur la table dans l' Apache Hive (API).

Seul le créateur d'une table peut supprimer la table créée dans le catalogue Apache Hive. Les autres utilisateurs ne peuvent pas supprimer la table même s'ils disposent d'un accès DROP explicite à la table. Ils reçoivent le message Access Denied.

Problème: Les certificats fournis par l'utilisateur ne sont pas pris en charge par watsonx.data.

Actuellement, les certificats fournis par l'utilisateur ne sont pas pris en charge dans watsonx.data lors de l'ajout de connexions de base de données, de compartiments de librairie ou lors de l'utilisation de l'utilitaire ibm-lh.

Problème: Aucune colonne à analyser à partir d'une erreur de fichier.

Lorsque vous tentez d'ingérer un dossier depuis AWS S3 à l'aide de l'outil ibm-lh, l'erreur suivante peut se produire s'il n'y a pas de fichiers vides dans le dossier:

No columns to parse from file

Solution palliative: répertoriez d'abord les dossiers dans le compartiment à l'aide de la commande aws s3 ls. Si aucun fichier vide n'est répertorié, copiez tous les fichiers dans un autre dossier à l'aide de la commande aws s3 cp.

Les caractères spéciaux dans les noms de table cible peuvent entraîner des échecs d'ingestion.

L'ingestion échoue si un nom de table cible contient des caractères spéciaux lors de l'ingestion via la console Web.

Solution palliative: Vous pouvez ingérer des données à l'aide de l'ingestion via l'interface de ligne de commande Spark.

Limitation:Presto (Java ) ne supporte pas VARBINARY Type de données.

La version actuelle dePresto (Java ) ne prend pas en charge les chaînes binaires avec une longueur. L'exécution d'une instruction ALTER TABLE sur une base de données génère l'erreur suivante:

Unknown type 'varbinary(n)' for column 'testcolumn'

Il s'agit d'une limitation dans Preso et non d'une limitation dans watsonx.data.

Limitation : Sauvegardez vos données pour éviter toute perte de données lorsque vous travaillez avec l'environnement de développement VS Code - Spark Labs.

Les laboratoires Spark étant éphémères par nature, vous devez sauvegarder les données stockées périodiquement afin d'éviter toute perte de données potentielle lors de mises à jour ou d'un crash du maître Spark.