Lernprogramm: Ändern der Speicherebene von seismischen Datasets

Von Bedeutung

Dieses Feature befindet sich derzeit in der Vorschau und ist standardmäßig in der Entwickler-SKU verfügbar. Lesen Sie die Supplemental-Nutzungsbedingungen für Microsoft Azure Previews für rechtliche Bedingungen, die für Azure Features gelten, die sich in der Betaversion, vorschau oder auf andere Weise noch nicht in der allgemeinen Verfügbarkeit befinden.

Nutzen Sie die Operation "Seismic DDMS Change Tier" im Azure Data Manager for Energy, um Datensätze zwischen Hot-, Cool- und Cold-Speicherebenen basierend auf der Zugriffshäufigkeit 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:

  • Initiieren eines Änderungsebenenvorgangs für ein Dataset oder einen Pfad
  • Überwachen Sie den Betriebsstatus der Änderungsstufe.
  • Abrufen von Fehlerdetails für fehlgeschlagene Datasets

Grundlegendes zu Speicherebenen

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

Tarif Zugriffshäufigkeit Zugriffslatenz Speicherkosten Anwendungsfall
Heiß Häufig darauf zugegriffen Millisekunden Am höchsten Aktive Projekte, aktuelle Akquisitionen
Kühl Selten zugegriffen (30+ Tage) Millisekunden Niedriger Abgeschlossene Projekte, regelmäßige Neuverarbeitung
Kalt Selten zugegriffen (90+ Tage) Millisekunden bis Stunden Lowest Langfristige Speicherung, einhaltung gesetzlicher Vorschriften

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 für 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. Weitere Informationen finden Sie unter 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 für Verzeichnispfade ein abschließendes / (z. B. sd://tenant/subproject/a/b/c/) und keinen Schrägstrich für einen einzelnen Datensatz (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 failed_cnt auf Teilfehler:

    {
  "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.

Tarif Mindestaufbewahrungszeitraum
Heiß Nichts
Kühl 30 Tage
Kalt 90 Tage

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

  • Vor dem Ändern der Stufen prüfen—Verwenden Sie die Dataset-Listen-API, um festzustellen, welche Datasets für eine Stufenänderung in Frage kommen, bevor Sie eine Massenoperation starten.
  • Beachten Sie Aufbewahrungszeiträume—Das Verschieben von Daten aus den Kategorien „Cool“ oder „Cold“ vor Ablauf der Mindestaufbewahrungsfrist führt zu Gebühren für die vorzeitige Löschung.
  • Überwachen Sie die Vorgänge bis zum Abschluss – Überprüfen Sie stets den Status des Vorgangs, bis statusCompleted oder Failed ist. Gehen Sie nach der 202 Accepted Antwort nicht von Erfolg aus.
  • Fehler ordnungsgemäß behandeln—Verwenden Sie show_details=true, um Informationen zu Fehlern pro Datensatz abzurufen und die Ursachen (Berechtigungen, fehlende Blobs, Aufbewahrungsverletzungen) zu beheben, bevor Sie es erneut versuchen.
  • 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 Tutorial werden keine kostenpflichtigen 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

  • Last updated on