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.
Eine Referenzimplementierung dieser Architektur ist auf GitHub verfügbar.
Aufbau
Laden Sie eine Visio-Datei dieser Architektur herunter.
Workflow
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.
Azure Cosmos DB. Der Azure Databricks-Auftrag gibt eine Reihe von Datensätzen aus, die in Azure Cosmos DB for Apache Cassandra geschrieben werden. Azure Cosmos DB for Apache Cassandra wird verwendet, da es Modellierung von 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 Azure Cosmos DB-Daten basiert.
Szenariodetails
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.
Mögliche Anwendungsfälle
Diese Lösung ist für den Einzelhandel optimiert.
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.
Laden Sie eine Visio-Datei dieser Architektur herunter.
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:
// Create a token credential using Managed Identity
val credential = new DefaultAzureCredentialBuilder().build()
val rideEventHubOptions = EventHubsConf(rideEventHubEntraIdAuthConnectionString)
.setTokenProvider(EventHubsUtils.buildTokenProvider(..., credential))
.setConsumerGroup(conf.taxiRideConsumerGroup())
.setStartingPosition(EventPosition.fromStartOfStream)
val rideEvents = spark.readStream
.format("eventhubs")
.options(rideEventHubOptions.toMap)
.load
val fareEventHubOptions = EventHubsConf(fareEventHubEntraIdAuthConnectionString)
.setTokenProvider(EventHubsUtils.buildTokenProvider(..., credential))
.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 Azure 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"),
(sum($"fareAmount")/count("*")).as("averageFareAmount"),
(sum($"tipAmount")/count("*")).as("averageTipAmount")
)
.select($"window.start", $"window.end", $"pickupNeighborhood", $"rideCount", $"totalFareAmount", $"totalTipAmount", $"averageFareAmount", $"averageTipAmount")
Das Ergebnis wird schließlich in Azure Cosmos DB eingefügt:
maxAvgFarePerNeighborhood
.writeStream
.queryName("maxAvgFarePerNeighborhood_cassandra_insert")
.outputMode(OutputMode.Append())
.foreach(new CassandraSinkForeach(connector))
.start()
.awaitTermination()
Überlegungen
Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.
Sicherheit
Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.
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 umfasst einen Geheimnisspeicher, in dem Anmeldeinformationen gespeichert werden können und auf die dann in Notebooks und Aufträgen verwiesen werden kann. 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 sollte 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.
Überwachung
Azure Databricks basiert auf Apache Spark. Beide Lösungen verwenden log4j als Standardbibliothek für die Protokollierung. Zusätzlich zur Standardprotokollierung, die von Apache Spark bereitgestellt wird, können Sie die Protokollierung in Azure Log Analytics implementieren, indem Sie den Artikel Überwachen von Azure Databricks befolgen.
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.
Im Folgenden finden Sie Beispielabfragen, die Sie in Ihrem Azure Log Analytics-Arbeitsbereich verwenden können, um die Ausführung des Streamingauftrags zu überwachen. Das Argument ago(1d) in jeder Abfrage gibt alle Datensätze zurück, die am letzten Tag generiert wurden, und kann so angepasst werden, dass ein anderer Zeitraum angezeigt wird.
Ausnahmen, die während der Ausführung von Datenstromabfragen protokolliert wurden
SparkLoggingEvent_CL
| where TimeGenerated > ago(1d)
| where Level == "ERROR"
Kumulation falsch formatierter Fahrpreis- und Fahrtdaten
SparkMetric_CL
| where TimeGenerated > ago(1d)
| where name_s contains "metrics.malformedrides"
| project value_d, TimeGenerated, applicationId_s
| render timechart
SparkMetric_CL
| where TimeGenerated > ago(1d)
| where name_s contains "metrics.malformedfares"
| project value_d, TimeGenerated, applicationId_s
| render timechart
Auftragsausführung im Laufe der Zeit
SparkMetric_CL
| where TimeGenerated > ago(1d)
| where name_s contains "driver.DAGScheduler.job.allJobs"
| project value_d, TimeGenerated, applicationId_s
| render timechart
Weitere Informationen finden Sie unter Überwachung von Azure Databricks.
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 Azure 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.
Kostenoptimierung
Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.
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 das Azure-Portal oder Event Hubs-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 Azure 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 – Preismodell.
Verwenden Sie den Kapazitätsrechner von Azure Cosmos DB, um eine schnelle Schätzung der Workloadkosten zu erhalten.
Weitere Informationen finden Sie im Abschnitt zu Kosten im Microsoft Azure Well-Architected Framework.
Bereitstellen dieses Szenarios
Führen Sie zum Bereitstellen und Ausführen der Referenzimplementierung die Schritte aus der GitHub-Infodatei aus.