Datenstromverarbeitung mit Azure Databricks

Cosmos DB
Databricks
Event Hubs
Log Analytics
Monitor

Diese Referenzarchitektur zeigt eine End-to-End-Pipeline zur Datenstromverarbeitung. Dieser Pipelinetyp hat vier Phasen: Erfassung, Verarbeitung, Speicherung und Analyse/Berichterstellung. In dieser Referenzarchitektur erfasst die Pipeline Daten aus zwei Quellen, verknüpft verwandte Datensätze aus den einzelnen Datenströmen, reichert das Ergebnis an und berechnet einen Durchschnitt in Echtzeit. Die Ergebnisse werden zur weiteren Analyse gespeichert.

GitHub-Logo Eine Referenzimplementierung dieser Architektur ist auf GitHub verfügbar.

Referenzarchitektur für Datenstromverarbeitung mit Azure Databricks

Szenario: Ein Taxiunternehmen erfasst Daten zu jeder Taxifahrt. In diesem Szenario gehen wir davon aus, dass zwei separate Geräte Daten senden. Das Taxi verfügt über ein Messgerät, das Informationen zu jeder Fahrt sendet – die Dauer, die Strecke sowie die Abhol- und Zielorte. Ein separates Gerät akzeptiert Zahlungen von Kunden und sendet Daten zu den Fahrpreisen. Das Taxiunternehmen möchte Fahrgasttrends ermitteln und dazu für jedes Stadtviertel in Echtzeit das durchschnittliche Trinkgeld pro gefahrener Meile berechnen.

Aufbau

Die Architektur umfasst die folgenden Komponenten.

Datenquellen: In dieser Architektur gibt es zwei Datenquellen, die Datenströme in Echtzeit generieren. Der erste Datenstrom enthält Informationen zur Fahrt und der zweite Informationen zum Fahrpreis. Die Referenzarchitektur umfasst einen simulierten Datengenerator, der aus einem Satz von statischen Dateien liest und die Daten an Event Hubs pusht. Bei einer echten Anwendung stammen die Daten von Geräten, die in den Taxis installiert sind.

Azure Event Hubs: Event Hubs ist ein Ereigniserfassungsdienst. Die hier gezeigte Architektur verwendet zwei Event Hub-Instanzen, eine für jede Datenquelle. Jede Datenquelle sendet einen Datenstrom an den zugehörigen Event Hub.

Azure Databricks: Databricks ist eine Apache Spark-basierte Analyseplattform, die für die Microsoft Azure-Clouddienstplattform optimiert ist. Sie wird verwendet, um die Taxifahrtdaten und die Fahrpreisdaten zu korrelieren und die korrelierten Daten mit den gespeicherten Stadtvierteldaten aus dem Databricks-Dateisystem anzureichern.

Cosmos DB: Der Azure Databricks-Auftrag gibt eine Reihe von Datensätzen aus, die unter Verwendung der Cassandra-API in Cosmos DB geschrieben werden. Die Cassandra-API wird verwendet, da sie Modelle mit Zeitreihendaten unterstützt.

  • Azure Synapse Link für Azure Cosmos DB ermöglicht Ihnen die Ausführung von Analysen über Betriebsdaten in Azure Cosmos DB in Quasi-Echtzeit ohne Auswirkungen auf die Leistung oder Kosten Ihrer Transaktionsworkload, indem Sie die beiden in Ihrem Azure Synapse-Arbeitsbereich verfügbaren Analyse-Engines verwenden: SQL (serverlos) und Spark-Pools.

Azure Log Analytics: Die von Azure Monitor erfassten Anwendungsprotokolldaten werden in einem Log Analytics-Arbeitsbereich gespeichert. Mithilfe von Log Analytics-Abfragen können Metriken analysiert und visualisiert sowie Protokollmeldungen auf Probleme innerhalb der Anwendung untersucht werden.

Alternativen

  • Synapse Link ist die von Microsoft bevorzugte Lösung für Analysen, die auf Cosmos Db-Daten basiert.

Datenerfassung

Um eine Datenquelle zu simulieren, verwendet die Referenzarchitektur das Dataset New York City Taxi Data[1]. Dieses Dataset enthält Daten zu Taxifahrten in New York City für einen Zeitraum von vier Jahren (2010–2013). Es umfasst zwei Datensatztypen: Fahrtdaten und Fahrpreisdaten. Die Fahrtdaten enthalten die Fahrtdauer, die Fahrtstrecke sowie die Abhol- und Zielorte. Die Fahrpreisdaten enthalten die Beträge von Fahrpreis, Steuern und Trinkgeld. Gemeinsame Felder in beiden Datensatztypen sind die Taxinummer (Medallion), die Taxilizenz (Hack license) und die Anbieter-ID (Vendor ID). Anhand dieser drei Felder werden ein Taxi und ein Fahrer eindeutig identifiziert. Die Daten werden im CSV-Format gespeichert.

[1] Donovan, Brian; Work, Dan (2016): New York City Taxi Trip Data (2010 – 2013). Universität Illinois in Urbana-Champaign. https://doi.org/10.13012/J8PN93H8

Der Datengenerator ist eine .NET Core-Anwendung, die Datensätze liest und an Azure Event Hubs sendet. Der Generator sendet Fahrtdaten im JSON-Format und Fahrpreisdaten im CSV-Format.

Event Hubs verwendet Partitionen zum Segmentieren der Daten. Partitionen ermöglichen es einem Consumer, die einzelnen Partitionen gleichzeitig zu lesen. Wenn Sie Daten an Event Hubs senden, können Sie den Partitionsschlüssel explizit angeben. Andernfalls werden Datensätze nach einem Roundrobinverfahren Partitionen zugewiesen.

In diesem Szenario sollen Fahrtdaten und Fahrpreisdaten für ein bestimmtes Taxi die gleiche Partitions-ID erhalten. Dies ermöglicht Databricks eine gewisse Parallelität beim Korrelieren der beiden Datenströme. Ein Datensatz in der Partition n der Fahrtdaten entspricht einem Datensatz in der Partition n der Fahrpreisdaten.

Diagramm der Datenstromverarbeitung mit Azure Databricks und Event Hubs

Im Datengenerator enthält das gemeinsame Datenmodell für beide Datensatztypen eine PartitionKey-Eigenschaft, bei der es sich um die Verkettung von Medallion, HackLicense und VendorId handelt.

public abstract class TaxiData
{
    public TaxiData()
    {
    }

    [JsonProperty]
    public long Medallion { get; set; }

    [JsonProperty]
    public long HackLicense { get; set; }

    [JsonProperty]
    public string VendorId { get; set; }

    [JsonProperty]
    public DateTimeOffset PickupTime { get; set; }

    [JsonIgnore]
    public string PartitionKey
    {
        get => $"{Medallion}_{HackLicense}_{VendorId}";
    }

Diese Eigenschaft wird verwendet, um beim Senden der Daten an Event Hubs einen expliziten Partitionsschlüssel bereitzustellen:

using (var client = pool.GetObject())
{
    return client.Value.SendAsync(new EventData(Encoding.UTF8.GetBytes(
        t.GetData(dataFormat))), t.PartitionKey);
}

Event Hubs

Die Durchsatzkapazität von Event Hubs wird in Durchsatzeinheiten gemessen. Sie können einen Event Hub automatisch skalieren, indem Sie die Funktion für automatische Vergrößerung aktivieren. Dadurch werden die Durchsatzeinheiten basierend auf dem Datenverkehr automatisch bis zu einem konfigurierten Höchstwert hochskaliert.

Datenstromverarbeitung

Die Datenverarbeitung in Azure Databricks erfolgt durch einen Auftrag. Der Auftrag wird einem Cluster zugewiesen und darin ausgeführt. Bei dem Auftrag kann es sich um benutzerdefinierten Java-Code oder um ein Spark-Notebook handeln.

In dieser Referenzarchitektur ist der Auftrag ein Java-Archiv mit Klassen (geschrieben in Java und Scala). Bei Angabe des Java-Archivs für einen Databricks-Auftrag wird die Klasse für die Ausführung durch den Databricks-Cluster angegeben. Hier enthält die main-Methode der Klasse com.microsoft.pnp.TaxiCabReader die Datenverarbeitungslogik.

Lesen des Datenstroms aus den beiden Event Hub-Instanzen

Die Datenverarbeitungslogik verwendet strukturiertes Spark-Streaming, um Daten aus den beiden Azure Event Hub-Instanzen zu lesen:

val rideEventHubOptions = EventHubsConf(rideEventHubConnectionString)
      .setConsumerGroup(conf.taxiRideConsumerGroup())
      .setStartingPosition(EventPosition.fromStartOfStream)
    val rideEvents = spark.readStream
      .format("eventhubs")
      .options(rideEventHubOptions.toMap)
      .load

    val fareEventHubOptions = EventHubsConf(fareEventHubConnectionString)
      .setConsumerGroup(conf.taxiFareConsumerGroup())
      .setStartingPosition(EventPosition.fromStartOfStream)
    val fareEvents = spark.readStream
      .format("eventhubs")
      .options(fareEventHubOptions.toMap)
      .load

Anreichern der Daten mit Stadtviertelinformationen

Die Fahrtdaten enthalten die Koordinaten (Längen- und Breitengrad) des Start- und Zielorts. Diese Koordinaten sind zwar hilfreich, eignen sich aber nicht besonders für die Analyse. Daher werden die Daten mit Stadtvierteldaten aus einer Shape-Datei angereichert.

Das Shape-Dateiformat ist binär und lässt sich nicht so einfach analysieren. Die Bibliothek GeoTools bietet jedoch Tools für Geodaten, die das Shape-Dateiformat verwenden. Diese Bibliothek wird in der Klasse com.microsoft.pnp.GeoFinder verwendet, um auf der Grundlage der Koordinaten des Start- und Zielorts den Namen des Stadtviertels zu bestimmen.

val neighborhoodFinder = (lon: Double, lat: Double) => {
      NeighborhoodFinder.getNeighborhood(lon, lat).get()
    }

Verknüpfen von Fahrt- und Fahrpreisdaten

Zunächst werden die Fahrt- und Fahrpreisdaten transformiert:

    val rides = transformedRides
      .filter(r => {
        if (r.isNullAt(r.fieldIndex("errorMessage"))) {
          true
        }
        else {
          malformedRides.add(1)
          false
        }
      })
      .select(
        $"ride.*",
        to_neighborhood($"ride.pickupLon", $"ride.pickupLat")
          .as("pickupNeighborhood"),
        to_neighborhood($"ride.dropoffLon", $"ride.dropoffLat")
          .as("dropoffNeighborhood")
      )
      .withWatermark("pickupTime", conf.taxiRideWatermarkInterval())

    val fares = transformedFares
      .filter(r => {
        if (r.isNullAt(r.fieldIndex("errorMessage"))) {
          true
        }
        else {
          malformedFares.add(1)
          false
        }
      })
      .select(
        $"fare.*",
        $"pickupTime"
      )
      .withWatermark("pickupTime", conf.taxiFareWatermarkInterval())

Anschließend werden die Fahrtdaten mit den Fahrpreisdaten verknüpft:

val mergedTaxiTrip = rides.join(fares, Seq("medallion", "hackLicense", "vendorId", "pickupTime"))

Verarbeiten der Daten und Einfügen in Cosmos DB

Der durchschnittliche Fahrpreis für jedes Stadtviertel wird für ein bestimmtes Zeitintervall berechnet:

val maxAvgFarePerNeighborhood = mergedTaxiTrip.selectExpr("medallion", "hackLicense", "vendorId", "pickupTime", "rateCode", "storeAndForwardFlag", "dropoffTime", "passengerCount", "tripTimeInSeconds", "tripDistanceInMiles", "pickupLon", "pickupLat", "dropoffLon", "dropoffLat", "paymentType", "fareAmount", "surcharge", "mtaTax", "tipAmount", "tollsAmount", "totalAmount", "pickupNeighborhood", "dropoffNeighborhood")
      .groupBy(window($"pickupTime", conf.windowInterval()), $"pickupNeighborhood")
      .agg(
        count("*").as("rideCount"),
        sum($"fareAmount").as("totalFareAmount"),
        sum($"tipAmount").as("totalTipAmount")
      )
      .select($"window.start", $"window.end", $"pickupNeighborhood", $"rideCount", $"totalFareAmount", $"totalTipAmount")

Das Ergebnis wird schließlich in Cosmos DB eingefügt:

maxAvgFarePerNeighborhood
      .writeStream
      .queryName("maxAvgFarePerNeighborhood_cassandra_insert")
      .outputMode(OutputMode.Append())
      .foreach(new CassandraSinkForeach(connector))
      .start()
      .awaitTermination()

Sicherheitshinweise

Der Zugriff auf den Azure Databricks-Arbeitsbereich wird über die Administratorkonsole gesteuert. Über die Administratorkonsole können Benutzer hinzugefügt, Benutzerberechtigungen verwaltet und einmaliges Anmelden eingerichtet werden. Die Zugriffssteuerung für Arbeitsbereiche, Cluster, Aufträge und Tabellen kann ebenfalls über die Administratorkonsole festgelegt werden.

Verwaltung geheimer Schlüssel

Azure Databricks enthält einen Geheimnisspeicher zum Speichern von Geheimnissen (beispielsweise Verbindungszeichenfolgen, Zugriffsschlüssel, Benutzernamen und Kennwörter). Geheimnisse werden im Azure Databricks-Geheimnisspeicher nach Bereichen partitioniert:

databricks secrets create-scope --scope "azure-databricks-job"

Geheimnisse werden auf der Bereichsebene hinzugefügt:

databricks secrets put --scope "azure-databricks-job" --key "taxi-ride"

Hinweis

Anstelle des nativen Azure Databricks-Bereichs kann auch ein Azure Key Vault-basierter Bereich verwendet werden. Weitere Informationen finden Sie unter Azure Key Vault-backed scopes (Azure Key Vault-basierte Bereiche).

Im Code erfolgt der Zugriff auf Geheimnisse über die secrets-Hilfsprogramme von Azure Databricks.

Aspekte der Überwachung

Azure Databricks basiert auf Apache Spark. Beide Lösungen verwenden log4j als Standardbibliothek für die Protokollierung. Zusätzlich zur von Apache Spark bereitgestellten Standardprotokollierung sendet diese Referenzarchitektur auch Protokolle und Metriken an Azure Log Analytics.

Die Klasse com.microsoft.pnp.TaxiCabReader konfiguriert das Apache Spark-Protokollierungssystem so, dass dessen Protokolle an Azure Log Analytics gesendet werden. Hierbei werden die Werte aus der Datei log4j.properties verwendet. Die Meldungen der Apache Spark-Protokollierung liegen als Zeichenfolgen vor. Für Azure Log Analytics werden jedoch Protokollmeldungen im JSON-Format benötigt. Die Klasse com.microsoft.pnp.log4j.LogAnalyticsAppender transformiert die Meldungen in das JSON-Format:


    @Override
    protected void append(LoggingEvent loggingEvent) {
        if (this.layout == null) {
            this.setLayout(new JSONLayout());
        }

        String json = this.getLayout().format(loggingEvent);
        try {
            this.client.send(json, this.logType);
        } catch(IOException ioe) {
            LogLog.warn("Error sending LoggingEvent to Log Analytics", ioe);
        }
    }

Bei der Verarbeitung von Fahrt- und Fahrpreismeldungen durch die Klasse com.microsoft.pnp.TaxiCabReader kann es zu Problemen mit der Formatierung und somit zu ungültigen Meldungen kommen. In einer Produktionsumgebung müssen diese falsch formatierten Meldungen unbedingt analysiert werden, um ein Problem mit den Datenquellen zu erkennen und schnell zu beheben, damit keine Daten verloren gehen. Die Klasse com.microsoft.pnp.TaxiCabReader registriert einen Apache Spark-Akkumulator zur Nachverfolgung der Anzahl falsch formatierter Fahrpreis- und Fahrtdatensätze:

    @transient val appMetrics = new AppMetrics(spark.sparkContext)
    appMetrics.registerGauge("metrics.malformedrides", AppAccumulators.getRideInstance(spark.sparkContext))
    appMetrics.registerGauge("metrics.malformedfares", AppAccumulators.getFareInstance(spark.sparkContext))
    SparkEnv.get.metricsSystem.registerSource(appMetrics)

Apache Spark verwendet die Dropwizard-Bibliothek, um Metriken zu senden. Einige der nativen Dropwizard-Metrikfelder sind jedoch nicht mit Azure Log Analytics kompatibel. Daher enthält diese Referenzarchitektur eine benutzerdefinierte Dropwizard-Senke und einen entsprechenden Reporter. Die Metriken werden so formatiert, wie es von Azure Log Analytics erwartet wird. Wenn Apache Spark Metriken meldet, werden auch die benutzerdefinierten Metriken für die falsch formatierten Fahrt- und Fahrpreisdaten gesendet.

Als letzte Metrik wird im Azure Log Analytics-Arbeitsbereich der kumulative Fortschritt des strukturierten Spark-Streamingauftrags protokolliert. Hierzu wird in der Klasse com.microsoft.pnp.StreamingMetricsListener ein benutzerdefinierter StreamingQuery-Listener implementiert. Diese Klasse wird beim Ausführen des Auftrags bei der Apache Spark-Sitzung registriert:

spark.streams.addListener(new StreamingMetricsListener())

Die Methoden in „StreamingMetricsListener“ werden von der Apache Spark-Runtime aufgerufen, wenn ein strukturiertes Streamingereignis auftritt. Dabei werden Protokollmeldungen und Metriken an den Azure Log Analytics-Arbeitsbereich gesendet. Zur Überwachung der Anwendung können Sie in Ihrem Arbeitsbereich die folgenden Abfragen verwenden:

Wartezeit und Durchsatz für Streamingabfragen

taxijob_CL
| where TimeGenerated > startofday(datetime(<date>)) and TimeGenerated < endofday(datetime(<date>))
| project mdc_inputRowsPerSecond_d, mdc_durationms_triggerExecution_d
| render timechart

Ausnahmen, die während der Ausführung von Datenstromabfragen protokolliert wurden

taxijob_CL
| where TimeGenerated > startofday(datetime(<date>)) and TimeGenerated < endofday(datetime(<date>))
| where Level contains "Error"

Kumulation falsch formatierter Fahrpreis- und Fahrtdaten

SparkMetric_CL
| where TimeGenerated > startofday(datetime(<date>)) and TimeGenerated < endofday(datetime(<date>))
| render timechart
| where name_s contains "metrics.malformedrides"

SparkMetric_CL
| where TimeGenerated > startofday(datetime(<date>)) and TimeGenerated < endofday(datetime(<date>))
| render timechart
| where name_s contains "metrics.malformedfares"

Auftragsausführung zur Nachverfolgung der Resilienz

SparkMetric_CL
| where TimeGenerated > startofday(datetime(<date>)) and TimeGenerated < endofday(datetime(<date>))
| render timechart
| where name_s contains "driver.DAGScheduler.job.allJobs"

Weitere Informationen finden Sie unter Überwachung von Azure Databricks.

Überlegungen zu DevOps

  • Erstellen Sie separate Ressourcengruppen für Produktions-, Entwicklungs- und Testumgebungen. Separate Ressourcengruppen erleichtern das Verwalten von Bereitstellungen, das Löschen von Testbereitstellungen und das Zuweisen von Zugriffsrechten.

  • Verwenden Sie die Azure Resource Manager-Vorlage, um die Azure-Ressourcen gemäß dem IaC-Prozess (Infrastructure-as-Code) bereitzustellen. Vorlagen erleichtern das Automatisieren von Bereitstellungen mit Azure DevOps Services und anderen CI/CD-Lösungen.

  • Platzieren Sie jede Workload in einer separaten Bereitstellungsvorlage, und speichern Sie die Ressourcen in Quellcodeverwaltungssystemen. Sie können die Vorlagen zusammen oder einzeln im Rahmen eines CI/CD-Prozesses bereitstellen. Dies erleichtert den Automatisierungsprozess.

    In dieser Architektur werden Azure Event Hubs, Log Analytics und Cosmos DB als eine einzige Workload identifiziert. Diese Ressourcen sind in einer einzigen ARM-Vorlage enthalten.

  • Erwägen Sie ein Staging Ihrer Workloads. Nehmen Sie die Bereitstellung in verschiedenen Stages vor, und führen Sie auf jeder Stage Überprüfungen durch, bevor Sie zur nächsten Stage wechseln. Auf diese Weise können Sie mit umfassender Kontrolle Aktualisierungen in Ihre Produktionsumgebungen pushen, und Sie minimieren unerwartete Bereitstellungsprobleme.

    In dieser Architektur gibt es mehrere Bereitstellungs-Stages. Erwägen Sie, eine Azure DevOps-Pipeline zu erstellen und diese Stages hinzuzufügen. Hier sind einige Beispiele für Stages, die Sie automatisieren können:

    • Starten eines Databricks-Clusters
    • Konfigurieren der Databricks-Befehlszeilenschnittstelle
    • Installieren von Scala-Tools
    • Hinzufügen der Databricks-Geheimnisse

    Möglicherweise empfiehlt es sich, automatisierte Integrationstests zu schreiben, um Qualität und Zuverlässigkeit des Databricks-Codes und dessen Lebenszyklus zu verbessern.

  • Erwägen Sie, die Leistung Ihrer Pipeline zur Streamverarbeitung mithilfe von Azure Monitor zu analysieren. Weitere Informationen finden Sie unter Überwachung von Azure Databricks.

Weitere Informationen finden Sie im Microsoft Azure Well-Architected Framework unter Übersicht über die DevOps-Säule.

Kostenbetrachtung

Verwenden Sie den Azure-Preisrechner, um die voraussichtlichen Kosten zu ermitteln. Im Anschluss finden Sie einige Aspekte, die im Zusammenhang mit in dieser Referenzarchitektur verwendeten Diensten berücksichtigt werden müssen.

Event Hubs

Diese Referenzarchitektur stellt Event Hubs auf der Ebene Standard bereit. Das Preismodell basiert auf Durchsatzeinheiten, Eingangsereignissen und Aufzeichnungsereignissen. Ein Eingangsereignis ist eine Dateneinheit von höchstens 64 KB. Größere Nachrichten werden in Vielfachen von 64 KB abgerechnet. Sie geben Durchsatzeinheiten entweder über die Azure-Portal- oder Event Hub-Verwaltungs-APIs an.

Wenn Sie mehr Aufbewahrungstage möchten, sollten Sie die Ebene Dedicated in Erwägung ziehen. Diese Ebene bietet Bereitstellungen mit einem Mandanten mit äußerst anspruchsvollen Anforderungen. Bei diesem Angebot wird ein auf Kapazitätseinheiten basierender Cluster erstellt, der nicht durch Durchsatzeinheiten gebunden ist.

Die Ebene Standard wird ebenso basierend auf den Eingangsereignissen und Durchsatzeinheiten abgerechnet.

Informationen zu den Preisen von Event Hubs finden Sie unter Event Hubs – Preise.

Azure Databricks

Azure Databricks bietet zwei Ebenen: Standard und Premium. Beide unterstützen drei Workloads. Bei dieser Referenzarchitektur wird ein Azure Databricks-Arbeitsbereich auf der Ebene Premium bereitgestellt.

Die Workloads Datentechnik und Datentechnik Light dienen Datentechnikern zum Erstellen und Ausführen von Aufträgen. Mit der Workload zur Datenanalyse können Datenanalysten Daten und Erkenntnisse interaktiv durchsuchen, visualisieren, verändern und austauschen.

Azure Databricks bietet zahlreiche Preismodelle.

  • Plan für die nutzungsbasierte Bezahlung

    Ihnen werden VMs in Rechnung gestellt, die in Clustern und Databricks-Einheiten (Databrick Units, DBUs) basierend auf der ausgewählten VM-Instanz bereitgestellt werden. Eine DBU ist eine Prozessfähigkeitseinheit, die pro Sekunde abgerechnet wird. Der DBU-Verbrauch ist abhängig von der Größe und Art der Instanz, in der Azure Databricks ausgeführt wird. Die Preise richten sich nach der ausgewählten Workload und Ebene.

  • Plan mit Vorauszahlung

    Sie verpflichten sich für Azure Databricks-Einheiten (DBUs) als Databricks-Commit-Einheiten Units (Databricks Commit Units, DBCU) für ein Jahr oder drei Jahre. Im Vergleich zum Modell mit nutzungsbasierter Bezahlung können Sie bis zu 37 Prozent sparen.

Weitere Informationen finden Sie unter Azure Databricks – Preise.

Azure Cosmos DB

In dieser Architektur wird eine Reihe von Datensätzen durch den Azure Databricks-Auftrag in Cosmos DB geschrieben. Ihnen wird die von Ihnen reservierte Kapazität in Anforderungseinheiten (Request Units, RUs) pro Sekunde (RU/s) in Rechnung gestellt, die zum Ausführen von Einfügevorgängen verwendet werden. Die Abrechnungseinheit beträgt 100 RU/s pro Stunde. So liegen die Kosten für das Schreiben von Elementen mit 100 KB bei 50 RU/s.

Stellen Sie für Schreibvorgänge genügend Kapazität zur Verfügung, um die Anzahl der pro Sekunde erforderlichen Schreibvorgänge zu unterstützen. Sie können den bereitgestellten Durchsatz erhöhen, indem Sie das Portal oder die Azure CLI verwenden, bevor Sie Schreibvorgänge durchführen, und dann den Durchsatz nach Abschluss dieser Vorgänge verringern. Der Durchsatz für den Zeitraum der Schreibvorgänge errechnet sich aus dem für die jeweiligen Daten erforderlichen Mindestdurchsatz plus dem Durchsatz, der für den Einfügevorgang erforderlich ist (sofern keine anderen Workloads ausgeführt werden).

Beispielkostenanalyse

Angenommen, Sie konfigurieren einen Durchsatzwert von 1.000 RU/s für einen Container. Dieser wird für 30 Tage 24 Stunden lang bereitgestellt – also insgesamt 720 Stunden.

Der Container wird mit 10 Einheiten zu je 100 RU/s pro Stunde abgerechnet. 10 Einheiten zu 0,008 USD (pro 100 RU/s) werden mit 0,08 USD pro Stunde abgerechnet.

Für 720 Stunden oder 7.200 Einheiten (100 RUs) werden Ihnen 57,60 USD für den Monat in Rechnung gestellt.

Der Speicher wird außerdem pro genutztem Gigabyte (GB) berechnet, das für Ihre gespeicherten Daten und den Index verwendet wird. Weitere Informationen finden Sie unter Azure Cosmos DB – Preise.

Verwenden Sie den Cosmos DB Capacity Calculator, um eine schnelle Schätzung der Workloadkosten zu erhalten.

Weitere Informationen finden Sie im Abschnitt zu Kosten im Microsoft Azure Well-Architected Framework.

Bereitstellen der Lösung

Führen Sie zum Bereitstellen und Ausführen der Referenzimplementierung die Schritte aus der GitHub-Infodatei aus.

Nächste Schritte