Begrepp för analyskonsumtionszon

Inbyggda analysfunktioner i Azure Data Manager for Energy, levererade via en analysförbrukningszon (ACZ), gör energidata lättillgängliga för analys och AI. ADME synkroniserar utvalda OSDU-data® till kundägd lagring i öppet Delta Parquet-format, vilket möjliggör användning med Microsoft Fabric, Azure Databricks, Snowflake och andra kompatibla analysplattformar utan behov av att bygga och underhålla egna datapipelines.

ACZ (Analytics Consumption Zone) exporterar valda entitetsdata från Azure Data Manager for Energy till ditt Azure Data Lake Storage Gen2 konto. ACZ skriver Azure Data Manager for Energy-data i öppet Delta Parquet-format. Tjänster som Microsoft Fabric och Azure Databricks kan läsa det här formatet direkt.

För att aktivera ACZ, finns information i Aktivera Analytics Consumption Zone.

Vad är ACZ?

ACZ är ett hanterat synkroniseringslager. Den exporterar entitetsdata från din Azure Data Manager for Energy-instans till ett Azure Data Lake Storage Gen2 lagringskonto som du äger. Du kan sedan ansluta dessa data till analys-, rapporterings- och maskininlärningsverktyg.

Att sätta upp ACZ har två delar. Du aktiverar ACZ när du har en Azure Data Manager for Energy-resurs i Azure-portalen. Sedan skapar du en eller flera ACZ-instanser genom att använda ACZ-API:erna. Varje ACZ-instans är en exportkonfiguration i en datapartition som definierar vilka typer ACZ exporterar och var den skriver dem. ACZ exporterar data endast för de ACZ-instanser du skapar.

Viktiga egenskaper för ACZ:

• Kundägd lagring: Du skapar och hanterar ett Data Lake Storage Gen2 lagringskonto där dina data hamnar. Vi rekommenderar ett lagringskonto i samma region som din Azure Data Manager för Energy-instansen. Om du har krav på dataresidens är du ansvarig för att välja ett lagringskonto i rätt region.
• Öppet format: Dina dataexporter i Delta Parquet-format. Analysmotorer har brett stöd för det här formatet.
• Selektiv synkronisering: Du väljer vilka entitetstyper som ska synkroniseras. Alternativ inkluderar katalogtyper och Wellbore Domain Data Management Service (DDMS)-typer (förhandsvisning).
• Historisk och inkrementell synkronisering: Du får en första ögonblicksbild av befintliga data från ACZ. Sedan synkroniserar ACZ ändringar när de inträffar.
• Portal- och API-hantering: Du aktiverar ACZ i Azure-portalen och skapar samt hanterar ACZ-instanser genom att använda REST-API:er.

Arkitektur

Följande diagram visar ACZ-dataflödet.

Så här fungerar ACZ

Entitetstyper som stöds

ACZ synkroniserar två kategorier av Azure Data Manager för energientitetstyper.

ACZ kan också exportera OSDU-behörighetsmedlemsdata via Entitlements Export (förhandsgranskning).

När du skapar en ACZ-instans anger du vilka entitetstyper som ska synkroniseras genom att ange:

• catalogKinds: En lista över mönster för katalogtyp (till exempel osdu:wks:master-data--Well:*).
• wellboreDDMSKinds: En lista över Wellbore DDMS-typmönster (till exempel osdu:wks:work-product-component--WellLog:*).

Dessa typmönster fungerar som filter som avgör vilka Azure Data Manager för energi registrerar ACZ-exporter och håller synkroniserade.

Använda flaggan allCatalogSync

Flaggan allCatalogSync är en valfri boolesk parameter som du kan ange när du skapar en ACZ-instans. När värdet är inställt på truesynkroniseras alla katalogtyper från datapartitionen.

Viktiga beteenden:

• allCatalogSync specificeras utanför avsnittet configuration i begärans brödtext.
• När allCatalogSync: trueexporterar ACZ alla katalogtyper automatiskt.
• Matriserna catalogKinds och wellboreDDMSKinds i konfigurationen ignoreras för katalogdata.
• Wellbore DDMS massfilnedladdningar påverkas inte av den här flaggan. Filer laddas bara ned för typer som uttryckligen anges i wellboreDDMSKinds.

Exempelkonfigurationer:

// 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:*"
    ]
  }
}

Versionstyper

När du skapar en ACZ-instans väljer du hur du ska hantera entitetsversioner.

Livscykeltillstånd

Varje ACZ går igenom dessa tillstånd:

Historisk ögonblicksbild

När du skapar en ny ACZ-instans tar tjänsten en historisk ögonblicksbild. Den här ögonblicksbilden exporterar alla befintliga poster som matchar de konfigurerade entitetstyperna (catalogKinds och wellboreDDMSKinds). Ögonblicksbilden fortsätter genom följande tillstånd:

När ögonblicksbilden är klar växlar ACZ till inkrementellt läge. Den hämtar nya och uppdaterade poster i nära realtid.

Så hanterar ACZ dataändringar

ACZ överför skapade, uppdaterade och borttagna poster från Azure Data Manager for Energy till Delta-tabellerna.

• Skapa och uppdatera: När du skapar en post eller ändrar dess datablock skapar Azure Data Manager for Energy en ny version. ACZ identifierar ändringen och skriver en ny rad till Delta-tabellen.
• Uppdateringar av enbart metadata: När en PATCH-operation ändrar åtkomstkontrollistan, juridisk information eller taggar utan att skapa en ny version, uppdaterar ACZ raden för den befintliga versionen.
• Mjuka borttagningar: När du mjuktar bort en post i Azure Data Manager för Energy sätter ACZ fältet isActive till False i stället för att ta bort raden. För ACZ-instanser som använder ALL_VERSIONS, markeras alla lagrade versioner av posten som inaktiva. Mjuka borttagningar bevarar historiken för gransknings- och tidsresefrågor.
• Rensningar: När du rensar bort en post i Azure Data Manager for Energy tar ACZ permanent bort posten från Delta-tabellen. Raden tas bort och kan inte återställas från ACZ-data.

Identifiera nya, uppdaterade och borttagna poster

ACZ aktiverar inte Delta Lake-ändringsdataflödet i sina tabeller. Om du aktiverar den själv visas varje postuppdatering som en borttagning följt av en insättning. För att bearbeta förändringar stegvis, använd ingestTime som vattenmärke. ACZ uppdaterar ingestTime varje gång den skriver en ändring i en rad, inklusive:

• Nya poster och nya postversioner.
• Uppdateringar endast av metadata, såsom ändringar i taggar, som inte skapar en ny postversion.
• Mjuka raderingar. ACZ ställer in isActive till False.

Rensade poster tas bort från Delta-tabellen. För att ta bort rensade poster från underordnade tabeller, stäm av dem periodiskt mot den aktuella ACZ-tabellen eller bygg om dem.

För en referensimplementation, se ADME ACZ Silver Layer exempelnotebook.

Utdataformat

ACZ skriver data i Delta Lake-format med Parquet-kodade filer (DELTA_PARQUET). Delta Lake stöder transaktioner med atomaritet, konsekvens, isolering och varaktighet. Det stöder också tidsresa och effektiv inkrementell läsning.

Data Lake Storage Gen2 mappstruktur

ACZ skriver data till det lagringskonto du anger när du skapar en ACZ-instans. Det första segmentet i den valfria basePath egenskapen är containern, och eventuella ytterligare segment är mappar i den containern. Det första segmentet måste vara ett giltigt containernamn. För namngivningsregler, se Namngivning och referenser av behållare, blobs och metadata. Om du inte specificerar en basväg använder ACZ en container som heter <aczId>. ACZ skapar containern om den inte existerar och skriver sin data till en mapp som heter <aczId>. För exempel, se Skapa en ACZ-instans.

<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

För mer information om tabellen för behörigheter, se Export av behörigheter i Analytics Consumption Zone (förhandsversion).

Viktig information

ACZ utför regelbundet underhåll på sina Delta-tabeller, inklusive VACUUM, vilket tar bort äldre datafiler. Tidsresefrågor kan endast läsa de senaste tabellversionerna. För att behålla en längre historik, kopiera datan till din egen lagring enligt ett schema. Om du har specifika krav på tabellhistorik, skapa en supportförfrågan.

Deltatabellschema

Delta-tabellen har följande fält:

Schemaversioner

Egenskapen catalogSchemaVersion i ACZ API-svaret visar vilket schema en ACZ-instans använder:

Befintliga ACZ-instanser behåller sin schemaversion. För att använda det aktuella schemat, skapa en ny ACZ-instans. Det finns ingen migrering från version 1 till version 2.

Export av berättiganden (förhandsversion)

ACZ kan valfritt exportera OSDU-behörighetsmedlemsdata till en entitlements Delta Lake-tabell tillsammans med katalogdatan. Du kan använda dessa data för att implementera filtrering som tar hänsyn till behörigheter i nedströms analysplattformar. ACZ konfigurerar inte eller upprätthåller inte säkerhet på nedströms radnivå.

Export av rättigheter är inaktiverad som standard. För att aktivera det, skapa en supportförfrågan. För detaljer, se Export av berättiganden i Analytics Consumption Zone (förhandsvisning).

Gränser och åtkomst

Limits

Autentisering och auktorisering

ACZ kräver:

• API-åtkomst: För att anropa ACZ-API:er måste du tillhöra users@{data-partition-id}.dataservices.energy, users.datalake.ops@{data-partition-id}.dataservices.energy, och service.entitlements.user@{data-partition-id}.dataservices.energy grupperna.
• Lagringsåtkomst: Den hanterade identiteten behöver rollen Storage Blob Data Contributor (eller motsvarande) i den Data Lake Storage Gen2 containern.
• Azure Data Manager for Energy access: Den hanterade identiteten tilldelas Azure Data Manager for Energy-resursen när du aktiverar ACZ i Azure-portalen. För steg, se Aktivera Analytics Consumption Zone.

Säkerhetskopiering och återställning

ACZ ingår inte i Azure Data Manager for Energy säkerhetskopiering och återställning. Om du återställer en Azure Data Manager for Energy-resurs eller datapartition från en säkerhetskopia, matchar ACZ-data i ditt lagringskonto inte längre de återställda uppgifterna. Skapa nya ACZ-instanser efter att återställningen har slutförts, som får en ny historisk snapshot.

Affärskontinuitet och haveriberedskap

ACZ ingår inte i Azure Data Manager för energis haveriberedskap mellan regioner. Efter en regional failover kan ACZ kanske inte återuppta synkroniseringen, eller så kan ändringar saknas från failover-fönstret. En historisk ögonblicksbild som håller på att skapas under en failover kanske inte blir komplett. För att återställa ACZ, skapa nya ACZ-instanser som tar en ny historisk snapshot.

Så här förbereder du:

• Konfigurera redundans för ditt destinationskonto Data Lake Storage Gen2. ACZ skriver till det lagringskonto du anger, och det som skrivs dit replikeras inte. För alternativ, se Azure Storage redundancy.
• Behåll ACZ-konfigurationerna, såsom sorter, basePath, och lagringskonton, som du behöver för att återskapa dina ACZ-instanser.

För mer information, se Reliability in Azure Data Manager for Energy.

Relaterat innehåll

• Aktivera förbrukningszon för analys
• Självstudie: Använda ACZ-API:er
• Ansluta ACZ-data till Fabric
• Anslut ACZ-data till Azure Databricks
• Export av rättigheter i Analytics Consumption Zone (förhandsvisning)