Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La zone de consommation Analytics exporte les données d’entité sélectionnées de Azure Data Manager for Energy vers votre compte Azure Data Lake Storage (ADLS) 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.
Important
Analytics Consumption Zone est actuellement en préversion. Consultez les Conditions d’utilisation supplémentaires pour les préversions Microsoft Azure pour les conditions légales qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou qui ne sont pas encore publiées en disponibilité générale.
Note
Dans le cadre de la préversion, ACZ est disponible uniquement sur les instances du niveau Developer et nécessite une autorisation préalable. Suivez les instructions de How to enable the Analytics Consumption Zone (ACZ) et contactez votre représentant Microsoft.
Qu’est-ce que ACZ ?
ACZ est une couche de synchronisation managée. Il exporte les données d’entité de votre instance de Azure Data Manager for Energy vers un compte de stockage ADLS 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.
Principales caractéristiques d’ACZ :
- Stockage appartenant au client : les données sont envoyées à un compte de stockage ADLS Gen2 que vous créez et gérez. Vous êtes responsable de la sélection d’un compte de stockage de destination géographique si vous avez des exigences de résidence des données.
- Format ouvert : 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 du service de gestion des données du domaine des puits (DDMS).
- Synchronisation historique et incrémentielle : ACZ prend un instantané initial des données existantes, puis synchronise les modifications au fur et à mesure qu’elles se produisent.
- Piloté par l’API : vous configurez et gérez entièrement ACZ par le biais d’API REST.
Architecture
Ce diagramme montre le flux de données ACZ :
diagramme de flux 
Fonctionnement d’ACZ
Types d’entités pris en charge
ACZ synchronise deux catégories de types d’entités d’Azure Data Manager for Energy :
| Category | Description | Exemples de types |
|---|---|---|
| Types de catalogues | Données principales et données de référence du service de stockage |
osdu:wks:master-data--Well:*, osdu:wks:reference-data--UnitOfMeasure:* |
| Types de DDMS Wellbore | Entités du service de gestion des données du domaine Wellbore | osdu:wks:work-product-component--WellLog:* |
Lorsque vous créez une application ACZ, vous spécifiez les types d’entités à synchroniser en fournissant les éléments suivants :
-
catalogKinds : liste de modèles de type catalogue (par exemple,
osdu:wks:master-data--Well:*) -
wellboreDDMSKinds : liste de modèles 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.
Types de versions
Lorsque vous créez un acz, vous choisissez comment gérer les versions d’entité :
| Type | Description |
|---|---|
| LATEST_VERSION | Exporte uniquement la dernière version de chaque entité. Valeur par défaut et recommandée. |
| ALL_VERSIONS | Exporte toutes les versions de chaque entité. Conserve l’historique complet des versions. |
États du cycle de vie
Chaque ACZ passe par les états suivants :
| État | Description |
|---|---|
| ACTIVE | Opérationnel. ACZ synchronise les modifications de façon incrémentielle. |
| ÉCHEC | Une erreur a arrêté l’installation ou la synchronisation. |
| ACCESS_DENIED | ACZ ne peut pas atteindre le compte de stockage ADLS de destination. |
Instantané historique
Lorsque vous créez une application 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 :
| État | Description |
|---|---|
| TRAITEMENT | Exportation active des données. |
| TERMINÉ | Toutes les données historiques exportées. |
| ÉCHEC | Une erreur s’est produite. |
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 des métadonnées uniquement : une opération PATCH peut modifier la liste de contrôle d’accès (ACL), Juridique ou Balises sans créer de nouvelle version. ACZ détecte cette modification et exécute une opération de fusion (upsert) sur la ligne existante.
-
Suppressions logiques : lorsque vous effectuez une suppression logique d’un enregistrement dans Azure Data Manager for Energy, ACZ définit le champ
isActivesurFalsedans la ligne au lieu de le supprimer. Les suppressions réversibles conservent l’historique des requêtes d’audit et 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.
Avertissement
ACZ est une synchronisation unidirectionnelle et en lecture seule de Azure Data Manager for Energy vers ADLS Gen2.
- Les flux de données proviennent uniquement de Azure Data Manager for Energy vers ADLS Gen2
- Ne modifiez pas, supprimez ou ajoutez des fichiers directement dans les dossiers ACZ dans ADLS Gen2
- Les modifications manuelles apportées aux données ACZ endommagent la synchronisation et provoquent des incohérences de données
- ACZ gère toutes les opérations Delta Lake (journaux des transactions, points de contrôle, compactage)
Pour l’analytique et la création de rapports, traitez les données exportées en lecture seule. Toutes les modifications de données doivent se produire dans Azure Data Manager for Energy.
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 ACID, les déplacements temporels et les lectures incrémentielles efficaces.
Structure de dossiers ADLS Gen2
ACZ organise les données dans votre compte de stockage ADLS Gen2 par dossier. Chaque ACZ dispose de son propre dossier dans le conteneur ou dans le chemin d’accès de base si vous en avez spécifié un. Les partitions ACZ cataloguent les tables Delta Lake par type. Un dossier par type d’entité DDMS et ID d’enregistrement.
Disposition des dossiers
Détails essentiels
| Élément | Description |
|---|---|
| Dossier de niveau supérieur | Nommé <acz-id> sous le conteneur, ou sous <base-path> si spécifié. Un dossier par ACZ. |
osducatalog/ |
Une table Delta pour tous les types de catalogue. Partitionné par type (par exemple, kind=osdu:wks:master-data--Well:1.0.0). |
_delta_log/ |
Journal des transactions Delta Lake. Suit toutes les modifications apportées aux tables pour les transactions ACID et le voyage dans le temps. |
| Dossiers d’entité DDMS | Un dossier par type d’entité DDMS (par exemple, work-product-component--WellLog). Contient les fichiers parquet spécifiques à DDMS selon le type d’entité et l’ID d’enregistrement. |
| Fichiers Parquet | Fichiers de données compressés avec Snappy. Les mises à jour créent des fichiers. ACZ exécute VACUUM et OPTIMIZE pour compacter les petits fichiers et en supprimer d’anciens. |
Schéma de table delta
La table Delta comporte les champs suivants :
| Champ | Type | Description |
|---|---|---|
id |
String | ID d’enregistrement OSDU®. |
version |
String | Numéro de version. |
kind |
String | Type OSDU® entièrement qualifié. |
data |
String | Bloc de données (JSON). |
meta |
String | Métadonnées (JSON). |
acl |
String | Liste de contrôle d’accès. |
legal |
String | Balises légales. |
tags |
String | Balises définies par l’utilisateur. |
createUser |
String | Utilisateur qui a créé l’enregistrement. |
createTime |
Horodatage | Lors de la création de l’enregistrement |
ingestTime |
Horodatage | Quand ACZ a ingéré l’enregistrement |
isActive |
Boolean |
True si elle est active.
False s’il est supprimé temporairement. |
Note
Les entités DDMS Wellbore ont également des champs fileDownloadTime, fileDownloadState et fileDownloadFolder pour le suivi des fichiers.
Limites et accès
Limites d’aperçu
| Contrainte | Limite |
|---|---|
| Nombre maximal d’ACZ par partition de données | Three |
| Unicité du nom ACZ | Doit être unique dans une partition de données |
| Format cible | Delta Parquet uniquement |
| Type de stockage | ADLS Gen2 uniquement |
| Prise en charge des niveaux d’instance | Niveau développeur uniquement pendant la préversion |
Authentification et autorisation
ACZ nécessite :
-
Accès à l’API : vous devez appartenir au
users@{data-partition-id}.dataservices.energygroupe pour appeler les API ACZ. - 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 ADLS Gen2. Durant la préversion, partagez les informations d’identité avec Microsoft pour ajouter l’identité à la liste d’autorisation.
- Azure Data Manager for Energy access : l’identité managée doit être affectée à la ressource Azure Data Manager for Energy.