--- title: "Gérer les attributs de table dans le Lakehouse Manager" description: "La page Attributes regroupe tous les attributs de votre lakehouse Manager par noms d'attribut uniques" url: https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/lakehouse-manager-attributes lang: fr lastUpdated: 2026-09-14 --- > For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt. # Gérer les attributs de table dans le Lakehouse Manager ## Objectif La page Attributes regroupe tous les attributs de votre lakehouse Manager par **noms d'attribut uniques**. Chacun de ces attributs fait partie d'un domaine : _physical_ ou _virtual_. ![attr](/images/public-cloud/data-platform/product/lakehouse-manager/attributes/picts/attributes-1.png) ## Attributs physiques Les attributs physiques sont les attributs physiquement stockés dans les [tables du Lakehouse Manager](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/lakehouse-manager-tables.md). Vous pouvez éditer leur catégorie, leur type et d'autres informations au niveau de la table. Ils sont regroupés par nom sur la page Attributes, ce qui vous permet d'observer d'un coup d'œil les différentes catégories et types que prend chaque attribut à travers tout votre data warehouse / data lake. ![attr](/images/public-cloud/data-platform/product/lakehouse-manager/attributes/picts/attributes-2.png) Chaque attribut peut être déplié afin d'obtenir le lineage complet sur les objets de votre Projet qui utilisent cet attribut : - [Tables](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/lakehouse-manager-tables.md) du Lakehouse Manager - [Actions](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-dpe-actions.md) du Data Processing Engine - [Requêtes](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/analytics-manager-queries.md) de l'Analytics Manager ![attr](/images/public-cloud/data-platform/product/lakehouse-manager/attributes/picts/attributes-3.png) Certains attributs peuvent être une clé pour un **dictionnaire**. Dans ce cas, un autre attribut est utilisé comme label pour cet attribut, afin d'être automatiquement affiché dans les applications à la place de la clé. Les labels peuvent être définis au niveau d'une table (contenant la clé du dictionnaire comme clé primaire) dans l'écran [Tables](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/lakehouse-manager-tables.md). ### Types d'attributs pris en charge Les attributs prennent en charge les types primitifs suivants : `integer`, `bigint`, `float`, `real`, `double`, `decimal`, `varchar`, `boolean`, `timestamp`, `date`. Il n'existe pas de type `GEOMETRY` natif, et les structures complexes ou imbriquées ne sont pas stockées nativement. Les patterns ci-dessous couvrent les besoins les plus courants en attendant. :::info Les types métier personnalisés avec validation native dans le schéma (SIRET, IBAN, coordonnées GPS) ne sont pas pris en charge. Stockez un SIRET ou un IBAN en tant que `varchar`, sans validation au niveau du schéma. ::: ### Travailler avec des données non structurées ou complexes **Documents (PDF, Word, ...)** 1. Stockez le fichier brut dans un [bucket](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/lakehouse-manager-buckets.md). 2. Extrayez son contenu dans une [action Custom](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-dpe-actions.md) (Python, avec des bibliothèques telles que `pypdf` ou `python-docx` installées via _Python Requirements_). 3. Écrivez les métadonnées et le texte extrait dans une table afin qu'il puisse être interrogé. **Objets géographiques** Il n'existe aujourd'hui aucun chemin natif. Deux options : - Stockez la géométrie en tant que texte **WKT** dans un attribute `varchar`, ou en **WKB** dans un attribute `VARBINARY`. - Exécutez les calculs spatiaux en dehors du schéma, avec **Apache Sedona** (ajouté comme dépendance Git dans une action Custom PySpark) ou avec `geopandas` / `shapely` dans un Notebook. :::info Trino expose les fonctions spatiales standard (`ST_*`) lorsque la version déployée les inclut. Vérifiez la disponibilité pour votre projet avant de vous y fier dans une requête. ::: **JSON semi-structuré** - Utilisez un champ `ROW` / `MAP` dans Iceberg lorsque le schéma est stable. - Utilisez un attribute `varchar` associé aux fonctions `json_*` de Trino (`json_extract`, `json_parse`) lorsque le schéma varie. **Recherche full-text / vectorielle** Il n'existe aucun chemin natif. Le pattern recommandé consiste à exporter vers un service externe (un Elasticsearch managé, une base de données vectorielle) via une action Custom en sortie. :::info Un moteur de stockage **PostgreSQL** est sur la feuille de route et sera, à terme, la meilleure réponse pour les données géographiques via PostGIS. ::: ### Contraintes Un attribut physique peut porter des contraintes qui sont appliquées à la table lorsqu'elle est construite : - **Required :** le champ ne peut jamais contenir NULL. - **Required + Identifier :** le champ est requis _et_ utilisé pour définir l'unicité d'une ligne pour les opérations d'[upsert](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-jobs-preferences.md#strat%C3%A9gie-d%C3%A9criture). Un champ identifiant ne peut pas être un `double` ou un `decimal`. Vous définissez ces contraintes lors de l'[ajout ou de l'édition d'un attribut](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/lakehouse-manager-manage-tables.md#contraintes-dattribut) sur une table. :::info Les contraintes s'appliquent uniquement aux attributs physiques. Les attributs virtuels ne peuvent pas être Required ou Identifier. ::: ## Conventions de nommage Les noms d'attribut sont **uniques par table**, mais la platform les agrège **par nom au niveau du Projet** sur la page Attributes. Ceci est utile pour repérer les incohérences, par exemple le même attribute `code` typé en `integer` dans une table et en `bigint` dans une autre, mais cela ne les **empêche pas**. Les règles générales de nommage et la liste des mots réservés s'appliquent aux attributs comme aux tables : consultez [Conventions de nommage](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/lakehouse-manager-tables.md#conventions-de-nommage) et [Mots réservés](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/lakehouse-manager-tables.md#mots-r%C3%A9serv%C3%A9s) sur la page Tables. :::warning `VALUE` figure dans la liste des mots réservés. Préférez plutôt `amount`, `metric_value` ou `entity_value`. ::: ### Gérer les attributs homonymes Lorsque des attributs tels que `code`, `libelle` ou `value` proviennent de sources différentes avec des types différents, appliquez les pratiques suivantes : 1. **Préfixez par domaine ou par source.** Utilisez `clt_code`, `clt_libelle`, `clt_value` pour les clients, `prd_code`, `prd_libelle` pour les produits, `cmd_code` pour les commandes, etc. Un préfixe transforme `code` en `entity_code` et supprime toute ambiguïté, à la fois à la lecture et dans les formules à détection automatique. 2. **Si le renommage n'est pas possible, harmonisez le type entre les tables.** Choisissez le type le plus large (`decimal` ou `bigint`) et faites un `CAST` au moment de l'`INSERT` dans les tables sources. Cela supprime au moins l'incohérence de type sur la page Attributes. 3. **Documentez avec des tags et une description** pour distinguer les usages lorsqu'un nom est ambigu. 4. **Réservez les noms génériques courts** (`code`, `libelle`, `value`, `id`, `name`, `status`) à un usage transversal, ou évitez-les complètement. ## Documenter les attributs partagés : le dictionnaire de données La Data Platform ne propose pas de catalogue de données externe complet, mais plusieurs mécanismes intégrés agissent déjà comme un dictionnaire de données fonctionnel : - **La page Attributes.** Une entrée par nom d'attribut à travers tout le Projet, une répartition des types et catégories qu'il prend à travers les tables (idéal pour repérer `code` en `integer` vs `bigint` vs `decimal`), et le lineage complet sur les objets qui le consomment, comme décrit [ci-dessus](#attributs-physiques). - **Les Policy tags.** Bien que les [policy tags](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/lakehouse-manager-policy-tags.md) aient été conçus pour le contrôle d'accès, ils peuvent également être réutilisés pour catégoriser vos données : `domain: finance`, `sensitivity: high`, `pii: true`, `glossary_term: client_id`. Les policy tags sont [hérités](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/lakehouse-manager-policy-tags.md#h%C3%A9ritage) du dataset vers la table puis vers l'attribute, un tag défini sur un dataset s'applique donc à tout attribute non tagué en dessous. Cela vous permet de définir une base et de la surcharger si nécessaire. - **Les Dictionnaires.** Le mécanisme de dictionnaire (clé → label) décrit [ci-dessus](#attributs-physiques) gère les tables de référence code → label. Les descriptions enrichies par attribut, un glossaire métier, la gestion de la propriété (ownership), et l'intégration avec un catalogue externe (Collibra, DataHub) ne sont pas disponibles. Pour ces besoins, un outil externe complémentaire reste nécessaire. ## Attributs virtuels Les attributs virtuels sont utilisés pour calculer de nouvelles formules sur vos données. Ils ne sont pas stockés dans la base de données mais sont calculés à la volée pour une [requête](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-analytics-manager.md) ou un tableau de bord/graphique de restitution. ![attr](/images/public-cloud/data-platform/product/lakehouse-manager/attributes/picts/attributes-4.png) ### Formule d'attribut virtuel L'élément le plus important d'un attribut virtuel est sa définition SQL. ![attr](/images/public-cloud/data-platform/product/lakehouse-manager/attributes/picts/attributes-5.png) Écrivez une formule contenant une combinaison de mots-clés SQL et d'[attributs physiques](#attributs-physiques). :::info La formule doit être écrite en utilisant une syntaxe SQL **conforme à ANSI** pour garantir la portabilité de votre Projet. La syntaxe spécifique à un moteur n'est pas prise en charge par la Data Platform. ::: #### Exemple de formule d'attribut virtuel `SUM(rides)/COUNT(DISTINCT CONCAT(CAST(date AS VARCHAR), CAST(station_id AS VARCHAR)))` Ici, _rides_, _date_, et _station\_id_ sont des attributs physiques provenant d'une table du Lakehouse Manager. La Platform les détectera automatiquement, ainsi que la table la plus pertinente à interroger (si elle n'est pas explicitement définie dans votre formule). ### Options des attributs virtuels ![attr](/images/public-cloud/data-platform/product/lakehouse-manager/attributes/picts/attributes-6.png) #### Attributs requis la platform détecte automatiquement les [attributs physiques](#attributs-physiques) nécessaires à l'exécution de la formule de l'attribut virtuel. Vous pouvez les éditer dans les options avancées de l'attribut virtuel. Les raisons d'éditer le type incluent (sans s'y limiter) : un attribut physique dans la formule est détecté comme un mot-clé SQL au lieu d'un attribut requis, ou l'inverse. #### Type Le type de l'attribut virtuel est automatiquement déduit lors de sa création. Ce type permet à la platform d'automatiser la planification des [requêtes](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/analytics-manager-queries.md) qui utilisent l'attribut virtuel. Vous pouvez l'éditer dans les options avancées de l'attribut virtuel. Les raisons d'éditer le type incluent (sans s'y limiter) : des valeurs de filtre basées sur un attribut virtuel sont automatiquement converties vers un autre type, faisant échouer les requêtes résultantes dans l'[Analytics Manager](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/analytics-manager-queries.md). ## Aller plus loin Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur [ce lien](https://www.ovhcloud.com/fr/professional-services/) pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services. Posez vos questions, faites-nous part de vos commentaires et interagissez directement avec l’équipe qui développe la Data Platform sur le [canal Discord](https://discord.gg/ovhcloud) dédié. Si vous avez besoin d'une assistance concernant vos services OVHcloud, créez une demande depuis notre [centre d'aide](https://help.ovhcloud.com/csm?id=csm_get_help). Rejoignez notre [communauté d'utilisateurs](https://community.ovhcloud.com/).