Lernprogramm: Ändern der Speicherebene von seismischen Datasets

Verwenden Sie den Seismischen DDMS Change Tier-Vorgang in Azure Data Manager for Energy, um Datasets basierend auf der Zugriffshäufigkeit zwischen Hot-, Cool- und Cold Storage-Ebenen zu verschieben. Das Verschieben selten zugänglicher Daten auf kühlere Ebenen reduziert die Speicherkosten, während aktive Datasets auf der Hot-Ebene eine optimale Leistung gewährleisten. Dieser Vorgang ist besonders nützlich für die seismische Datenverwaltung, bei der große Mengen an historischen Daten für zukünftige Analysen oder Compliance verfügbar bleiben müssen, aber keinen häufigen Zugriff erfordern.

In diesem Tutorial lernen Sie Folgendes:

Grundlegendes zu Speicherebenen

Seismic DDMS unterstützt die folgenden Speicherebenen, die den Speicherklassen des zugrunde liegenden Cloudanbieters zugeordnet sind:

Jede Ebene hat einen Mindestaufbewahrungszeitraum. Das Verschieben von Daten aus einer Ebene vor Ablauf des Mindestaufbewahrungszeitraums kann zu vorzeitigen Löschungsgebühren führen.

Voraussetzungen

Bevor Sie beginnen, stellen Sie sicher, dass Sie die folgenden Voraussetzungen erfüllen:

• Eine Azure Data Manager for Energy-Ressource, bei der Seismic DDMS konfiguriert wurde.
• Ein registrierter tenant und subproject im Seismic DDMS-Dienst.
• Die subproject.admin Rolle, die Ihrem Benutzerkonto zugewiesen ist.
• Ein Bearertoken für die API-Authentifizierung. Informationen zum Generieren eines Authentifizierungstokens.
• Mindestens ein Dataset, das im Ziel-Teilprojekt registriert ist.

Initiieren eines Änderungsebenenvorgangs

Bevor Sie die Anforderung übermitteln, anhalten Sie alle Schreib- und Löschvorgänge auf dem Zielpfad. Das Hinzufügen oder Löschen von Datasets, während ein Änderungsebenenvorgang ausgeführt wird, kann zu inkonsistenten Ergebnissen führen.

1. Senden Sie eine PUT-Anfrage mit dem Pfad und der Zielstufe. Verwenden Sie einen nachgestellten / für Verzeichnispfade (z. B. sd://tenant/subproject/a/b/c/) und keinen nachgestellten Schrägstrich für ein einzelnes Dataset (z. B. sd://tenant/subproject/a/b/c/dataset-name):

   • Alle Datasets in einem Pfad:

     PUT <instance>.energy.azure.com/seistore-svc/api/v3/operation/change-tier?path=sd://{tenant}/{subproject}/{path}/&tier=Cool
     Authorization: Bearer {access_token}
     Content-Type: application/json
     

   • Einzelner Datensatz

     PUT <instance>.energy.azure.com/seistore-svc/api/v3/operation/change-tier?path=sd://{tenant}/{subproject}/{path}/{dataset_name}&tier=Cool
     Authorization: Bearer {access_token}
     Content-Type: application/json
     

2. Speichern Sie die operation_id Datei aus der 202 Accepted Antwort. Sie benötigen ihn, um den Vorgang zu überwachen.

   {
     "operation_id": "c3d282e6-e7d1-40d8-8ac2-edc15b6d174c"
   }
   

Status des Betriebs überwachen

Nachdem Sie den Vorgang zum Ändern der Stufe eingeleitet haben, rufen Sie den Status-Endpoint ab, um den Fortschritt zu verfolgen.

1. Überprüfen Sie den Statusendpunkt mit dem operation_id, bis statusCompleted oder Failed ist.

   GET <instance>.energy.azure.com/seistore-svc/api/v3/operation/change-tier/{operation_id}
   Authorization: Bearer {access_token}
   data-partition-id: {data_partition_id}
   

2. Überprüfen Sie das status Feld in der Antwort. Während der Vorgang ausgeführt wird:

   {
     "operation_id": "c3d282e6-e7d1-40d8-8ac2-edc15b6d174c",
     "created_at": "2026-03-10T06:15:00Z",
     "created_by": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
     "last_updated_at": "2026-03-10T06:17:30Z",
     "status": "Running",
     "dataset_cnt": 500,
     "completed_cnt": 342,
     "failed_cnt": 0,
     "target_tier": "Cool"
   }
   

   Wenn der Vorgang abgeschlossen ist, status ändert sich zu Completed. Überprüfen Sie auf Teilfehler: failed_cnt

   {
     "operation_id": "c3d282e6-e7d1-40d8-8ac2-edc15b6d174c",
     "created_at": "2026-03-10T06:15:00Z",
     "created_by": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
     "last_updated_at": "2026-03-10T06:25:00Z",
     "status": "Completed",
     "dataset_cnt": 500,
     "completed_cnt": 497,
     "failed_cnt": 3,
     "target_tier": "Cool"
   }
   

Abrufen von Fehlerdetails

Verwenden Sie den show_details=true Parameter, um Fehlerinformationen pro Dataset für alle Datasets abzurufen, die während der Ebenenänderung fehlschlagen.

1. Fügen Sie show_details=true zur Statusanforderung hinzu.

   GET <instance>.energy.azure.com/seistore-svc/api/v3/operation/change-tier/{operation_id}?show_details=true&limit=100
   Authorization: Bearer {access_token}
   data-partition-id: {data_partition_id}
   

   Die folgenden Abfrageparameter steuern die Antwort:

   Parameter	Erforderlich	Typ	Beschreibung
   show_details	No	boolean	Stellen Sie auf true ein, um das Array failed_datasets in die Antwort einzuschließen. Standardwert: false.
   limit	No	ganze Zahl (1–1000)	Maximale Anzahl fehlgeschlagener Datasets, die pro Seite zurückgegeben werden sollen. Standardwert: 100. Gilt nur, wenn show_details=true.
   cursor	No	Schnur	Base64 URL-sicher kodierter Cursor aus einer vorherigen Antwort, um die nächste Seite der Fehler abzurufen.

2. Überprüfen Sie das failed_datasets Array in der Antwort:

   {
     "operation_id": "c3d282e6-e7d1-40d8-8ac2-edc15b6d174c",
     "created_at": "2026-03-10T08:00:00Z",
     "created_by": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
     "last_updated_at": "2026-03-10T08:45:00Z",
     "status": "CompletedWithErrors",
     "dataset_cnt": 2000,
     "completed_cnt": 1994,
     "failed_cnt": 6,
     "target_tier": "Cold",
     "failed_datasets": [
       {
         "sdpath": "sd://opendes/project-alpha/seismic/survey-2024-001",
         "error": "Failed to change tier for 12 blob(s)"
       },
       {
         "sdpath": "sd://opendes/project-alpha/seismic/survey-2024-002",
         "error": "Access denied: user is not authorized to modify this dataset (ACL validation failed)"
       },
       {
         "sdpath": "sd://opendes/project-alpha/seismic/survey-2024-003",
         "error": "Failed to acquire lock"
       },
       {
         "sdpath": "sd://opendes/project-alpha/seismic/survey-2024-004",
         "error": "Dataset has no associated storage location"
       },
       {
         "sdpath": "sd://opendes/project-alpha/seismic/survey-2024-005",
         "error": "Dataset storage location has invalid format"
       },
       {
         "sdpath": "sd://opendes/project-alpha/seismic/survey-2024-006",
         "error": "Tier changed but metadata update failed after retries"
       }
     ],
     "cursor": "ZXlKamIyNTBhVzUxWVhScGIyNVViMnRsYmlJNkltVjRZVzF3YkdVaWZRPT0"
   }
   

   Wenn die Antwort einen cursor Wert enthält, übergeben Sie ihn in der nächsten Anforderung, um die nächste Seite mit Fehlern abzurufen.

Aufbewahrungsrichtlinien für Speicherebene

Jede Speicherebene erzwingt einen mindesten Aufbewahrungszeitraum. Wenn Sie Daten von einer kühleren Ebene auf eine wärmere Stufe verschieben, bevor der Aufbewahrungszeitraum abläuft, können Gebühren für vorzeitige Löschungen anfallen.

Befolgen Sie die folgenden Methoden, wenn Sie Änderungen der Speicherebene verwalten:

• Vor dem Ändern von Ebenen prüfen – Verwenden Sie die Datasetlisten-API, um zu identifizieren, welche Datasets Kandidaten für Tieränderungen sind, bevor Sie eine Massenoperation initiieren.
• Beachten Sie Aufbewahrungszeiträume – Das Verschieben von Daten aus Cool- oder Cold-Tiers vor dem Mindestaufbewahrungszeitraum verursacht Gebühren für vorzeitige Löschung.
• Überwachen Sie die Vorgänge bis zum Abschluss – Überprüfen Sie stets den Status des Vorgangs, bis statusCompleted oder Failed. Gehen Sie nach der 202 Accepted Antwort nicht von Erfolg aus.
• Behandeln von Fehlern ordnungsgemäß – Verwenden Sie show_details=true, um Fehlerinformationen pro Dataset abzurufen und die Hauptursachen (Berechtigungen, fehlende Blobs, Aufbewahrungsverstöße) zu beheben, bevor ein neuer Versuch unternommen wird.
• Planen für Änderungen an der Zugriffslatenz – Datensätze in den Ebenen "Cool" und "Cold" können eine höhere First-Byte-Latenz aufweisen. Stellen Sie sicher, dass nachgeschaltete Verbraucher über potenzielle Latenzsteigerungen informiert sind.

Bereinigen von Ressourcen

In diesem Lernprogramm werden keine abrechnenden Azure-Ressourcen erstellt. Wenn Sie Speicherebenen zu Testzwecken geändert haben, stellen Sie sie wieder her, indem Sie einen anderen Änderungsstufenvorgang ausführen.

Verwandte Inhalte

• Lernprogramm: Arbeiten mit seismischen Daten mithilfe von seismischen DDMS-APIs
• Übersicht über Azure Blob Storage-Zugriffsebenen
• Azure Blob Storage-Lifecycle-Verwaltungsrichtlinien
• Preise für Azure Blob Storage
• Seismische DDMS-API-Referenz