Concepts de la zone de consommation Analytics

Les fonctionnalités analytiques natives d’Azure Data Manager for Energy, fournies via une zone de consommation analytique (ACZ), facilitent l’accès aux données énergétiques pour l’analyse et l’IA. ADME synchronise certaines données OSDU® vers un stockage appartenant au client au format ouvert Delta Parquet, ce qui permet de les exploiter avec Microsoft Fabric, Azure Databricks, Snowflake et d’autres plateformes d’analyse compatibles sans créer ni gérer de pipelines de données personnalisés.

Analytics Consumption Zone (ACZ) exporte les données d’entité sélectionnées de Azure Data Manager for Energy vers votre compte Azure Data Lake Storage Gen2. ACZ écrit les données Azure Data Manager for Energy au format ouvert Delta Parquet. Les services tels que Microsoft Fabric et Azure Databricks peuvent lire ce format directement.

Pour activer ACZ, voir Activer la zone de consommation analytique.

Qu’est-ce que ACZ ?

ACZ est une couche de synchronisation managée. Il exporte les données d’entité de votre instance Data Manager for Energy Azure vers un compte de stockage Azure Data Lake Storage Gen2 que vous possédez. Vous pouvez ensuite connecter ces données à des outils d’analytique, de création de rapports et d’apprentissage automatique.

La mise en place d’ACZ comporte deux volets. Vous activez ACZ une seule fois sur une ressource Azure Data Manager for Energy dans le portail Azure. Ensuite, vous créez une ou plusieurs instances ACZ en utilisant les API ACZ. Chaque instance ACZ est une configuration d’exportation au sein d’une partition de données qui définit les types de données exportés par ACZ et leur destination. ACZ exporte uniquement les données pour les instances ACZ que vous créez.

Principales caractéristiques d’ACZ :

• Stockage appartenant au client : vous créez et gérez un compte de stockage Data Lake Storage Gen2 où vos données sont envoyées. Nous recommandons un compte de stockage dans la même région que votre instance Azure Data Manager for Energy. Si vous avez des exigences de résidence des données, vous êtes responsable de choisir un compte de stockage dans la région appropriée.
• Format ouvert : Vos exportations de données au format Delta Parquet. Les moteurs d’analyse prennent largement en charge ce format.
• Synchronisation sélective : Vous choisissez les types d’entités à synchroniser. Les options incluent les types de catalogue et les types Wellbore Domain Gestion des données Service (DDMS) (aperçu).
• Synchronisation historique et incrémentielle : vous obtenez un instantané initial des données existantes à partir d’ACZ. AcZ synchronise ensuite les modifications au fur et à mesure qu’elles se produisent.
• Gestion du portail et des API : Vous activez ACZ dans le portail Azure, et vous créez et gérez des instances ACZ en utilisant des API REST.

Architecture

Le diagramme suivant montre le flux de données ACZ.

Fonctionnement d’ACZ

Types d’entités pris en charge

ACZ synchronise deux catégories de types d’entité d’Azure Data Manager for Energy.

ACZ peut également exporter les données d’appartenance aux droits d’accès OSDU au moyen de l’exportation des droits d’accès (préversion).

Lorsque vous créez une instance ACZ, vous spécifiez les types d’entités à synchroniser en fournissant :

• catalogKinds: liste de modèles de type catalogue (par exemple, osdu:wks:master-data--Well:*).
• wellboreDDMSKinds: Une liste des motifs de type Wellbore DDMS (par exemple, osdu:wks:work-product-component--WellLog:*).

Ces modèles de type agissent comme des filtres qui déterminent quel Azure Data Manager for Energy enregistre les exportations ACZ et conserve la synchronisation.

Utiliser l’indicateur allCatalogSync

L’indicateur allCatalogSync est un paramètre booléen facultatif que vous pouvez spécifier lorsque vous créez une instance ACZ. Lorsqu’il est défini sur true, il synchronise tous les types de catalogues depuis la partition de données.

Comportements clés :

• allCatalogSync est spécifié en dehors de la configuration section dans le corps de la requête.
• Quand allCatalogSync: true, ACZ exporte automatiquement tous les types de catalogues.
• Les tableaux catalogKinds et wellboreDDMSKinds de la configuration sont ignorés pour les données de catalogue.
• Les téléchargements de fichiers en bloc DDMS Wellbore ne sont pas affectés par cet indicateur. Les fichiers sont téléchargés uniquement pour les types explicitement répertoriés dans wellboreDDMSKinds.

Exemples de configurations :

// Selective catalog sync - only Wells and Fields
{
  "allCatalogSync": false,
  "configuration": {
    "catalogKinds": [
      "osdu:wks:master-data--Well:*",
      "osdu:wks:master-data--Field:*"
    ]
  }
}

// Sync all catalog kinds using allCatalogSync flag
{
  "allCatalogSync": true,
  "configuration": {
    // catalogKinds is ignored when allCatalogSync is true
  }
}

// Sync all catalog kinds, but Wellbore DDMS files only for specified kinds
{
  "allCatalogSync": true,
  "configuration": {
    "wellboreDDMSKinds": [
      "osdu:wks:work-product-component--WellLog:*"
    ]
  }
}

Types de versions

Lorsque vous créez une instance ACZ, vous choisissez comment gérer les versions d’entité.

États du cycle de vie

Chaque ACZ passe par les états suivants :

Instantané historique

Lorsque vous créez une instance ACZ, le service prend un instantané historique. Cet instantané exporte tous les enregistrements existants qui correspondent aux types d’entités configurés (catalogKinds et wellboreDDMSKinds). L’instantané passe par les états suivants :

Une fois l’instantané terminé, ACZ bascule vers le mode incrémentiel. Il capture les enregistrements nouveaux et mis à jour en quasi-temps réel.

Comment ACZ gère les modifications des données

ACZ propage les enregistrements créés, mis à jour et supprimés de Azure Data Manager for Energy aux tables Delta.

• Creations et mises à jour : lorsque vous créez un enregistrement ou modifiez son bloc de données, Azure Data Manager for Energy crée une nouvelle version. ACZ détecte la modification et écrit une nouvelle ligne dans la table Delta.
• Mises à jour uniquement sur les métadonnées : lorsqu’une opération PATCH modifie la liste de contrôle d’accès, les mentions légales ou les balises sans créer une nouvelle version, ACZ met à jour la ligne pour la version existante.
• Suppressions réversibles : Lorsque vous supprimez de façon réversible un enregistrement dans Azure Data Manager for Energy, ACZ règle le champ isActive sur False au lieu de supprimer la ligne. Pour les instances ACZ qui utilisent ALL_VERSIONS, toutes les versions stockées de l’enregistrement sont marquées comme inactives. Les suppressions logiques conservent l’historique à des fins d’audit et de requêtes de voyage dans le temps.
• Purges : lorsque vous purgez un enregistrement dans Azure Data Manager for Energy, ACZ supprime définitivement l’enregistrement de la table Delta. La ligne est supprimée et ne peut pas être récupérée à partir des données ACZ.

Identifier les enregistrements nouveaux, mis à jour et supprimés

ACZ n’active pas le flux de données de modification de Delta Lake sur ses tables. Si vous l’activez vous-même, chaque mise à jour d’enregistrement apparaît comme une suppression suivie d’une insertion. Pour traiter les modifications de manière incrémentielle, utilisez ingestTime comme repère temporel. ACZ actualise ingestTime chaque fois qu’il écrit une modification dans une ligne, notamment pour :

• Les nouveaux enregistrements et les nouvelles versions d’enregistrements.
• Les mises à jour uniquement sur les métadonnées, comme les modifications des tags, ne créent pas une nouvelle version d’enregistrement.
• Suppressions réversibles. ACZ fixe isActive à False.

Les enregistrements purgés sont supprimés de la table Delta. Pour retirer les enregistrements purgés des tables en aval, rapprochez-les périodiquement avec la table ACZ actuelle ou reconstruisez-les.

Pour consulter une implémentation de référence, reportez-vous à l’exemple de notebook ADME ACZ Silver Layer.

Format de sortie de données

ACZ écrit des données au format Delta Lake avec des fichiers encodés en Parquet (DELTA_PARQUET). Delta Lake prend en charge les transactions d’atomicité, de cohérence, d’isolation et de durabilité. Il prend également en charge le voyage dans le temps et les lectures incrémentielles efficaces.

structure de dossiers Data Lake Storage Gen2

ACZ écrit les données sur le compte de stockage que vous spécifiez lors de la création d’une instance ACZ. Le premier segment de la propriété optionnelle basePath est le conteneur, et tous les segments supplémentaires sont des dossiers dans ce conteneur. Le premier segment doit être un nom de conteneur valide. Pour les règles de nommage, voir Dénomination et référencement des conteneurs, blobs et métadonnées. Si vous ne spécifiez pas de chemin de base, ACZ utilise un conteneur nommé <aczId>. ACZ crée le conteneur s’il n’existe pas et écrit ses données dans un dossier nommé <aczId>. Pour des exemples, voir Créer une instance ACZ.

<storage-account>/
└── <container>/                      ← first segment of basePath, or <aczId>
    └── [<more basePath folders>/]
        └── <aczId>/
            ├── osducatalog/          ← Delta table, partitioned by kind
            │   └── _delta_log/
            ├── wellboreDDMS/         ← Wellbore DDMS bulk files (Parquet and JSON)
            │   ├── work-product-component--WellLog/
            │   └── work-product-component--WellboreTrajectory/
            └── entitlements/         ← Delta table (preview), only when entitlements export is enabled

Pour plus d’informations sur la table des droits, voir Exportation des droits dans Analytics Consumption Zone (aperçu).

Détails essentiels

ACZ effectue régulièrement des opérations de maintenance sur ses tables Delta, notamment VACUUM, qui supprime les anciens fichiers de données. Les requêtes de voyage dans le temps peuvent lire uniquement les versions récentes des tables. Pour conserver un historique plus long, copiez les données dans votre propre stockage à intervalles réguliers. Si vous avez des exigences spécifiques concernant l’historique des tables, créez une demande de support.

Schéma de table delta

La table Delta comporte les champs suivants :

Versions de schéma

La catalogSchemaVersion propriété de la réponse API ACZ montre quel schéma une instance ACZ utilise :

Les instances ACZ existantes conservent leur version de schéma. Pour utiliser le schéma actuel, créez une nouvelle instance ACZ. Il n’y a pas de migration de la version 1 à la version 2.

Export des droits (aperçu)

ACZ peut en option exporter les données d’adhésion aux droits OSDU vers une entitlements table Delta Lake en plus des données du catalogue. Vous pouvez utiliser ces données pour mettre en place un filtrage conscient des droits dans les plateformes d’analyse en aval. ACZ ne configure ni n’applique la sécurité au niveau des lignes dans les systèmes en aval.

L’exportation des droits est désactivée par défaut. Pour l’activer, créez une demande de support. Pour plus de détails, voir Exportation des droits dans la zone de consommation analytique (aperçu).

Limites et accès

Limites

Authentification et autorisation

ACZ nécessite :

• Accès API : Pour appeler des API ACZ, vous devez appartenir aux groupes users@{data-partition-id}.dataservices.energy, users.datalake.ops@{data-partition-id}.dataservices.energy et service.entitlements.user@{data-partition-id}.dataservices.energy.
• Accès au stockage : l’identité managée a besoin du rôle Contributeur aux données blob de stockage (ou équivalent) sur le conteneur Data Lake Storage Gen2.
• Azure Data Manager for Energy access : L’identité gérée est attribuée à la ressource Azure Data Manager for Energy lorsque vous activez ACZ dans le portail Azure. Pour les étapes, voir Activer la zone de consommation analytique.

Sauvegarde et restauration

ACZ n'est pas inclus dans Azure Data Manager for Energy pour la sauvegarde et la restauration. Si vous restaurez une ressource ou une partition de données Azure Data Manager for Energy à partir d’une sauvegarde, les données ACZ dans votre compte de stockage ne correspondent plus aux données restaurées. Une fois la restauration terminée, créez de nouvelles instances ACZ, qui prendront un nouvel instantané historique.

Continuité des activités et récupération d’urgence

ACZ n'est pas inclus dans Azure Data Manager for Energy pour la reprise après sinistre interrégion. Après un basculement régional, ACZ peut ne pas reprendre la synchronisation ou ne pas contenir certaines modifications survenues pendant la période de basculement. Un instantané historique en cours de création lors d’un basculement peut ne pas aboutir. Pour restaurer ACZ, créez de nouvelles instances ACZ, qui prennent un nouvel instantané historique.

Pour préparer :

• Configurez la redondance pour votre compte de destination Data Lake Storage Gen2. ACZ écrit dans le compte de stockage que vous indiquez et ne le réplique pas. Pour les options, voir la redondance du stockage Azure.
• Conservez les configurations ACZ, notamment les types de données, basePath et le compte de stockage, nécessaires pour recréer vos instances ACZ.

Pour plus d’informations, consultez Fiabilité d’Azure Data Manager for Energy.

Contenu connexe

• Activer la zone analytique de consommation
• Tutoriel : Utiliser les API ACZ
• Connecter des données ACZ à Fabric
• Connectez les données ACZ à Azure Databricks
• Exportation des droits d’accès dans la zone de consommation analytique (préversion)