Diese Referenzarchitektur zeigt eine End-to-End-Pipeline zur Datenstromverarbeitung. Die vier Phasen dieser Pipeline sind Aufnahme, Prozess, Speicher und 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 dann zur weiteren Analyse gespeichert.
Eine Referenzimplementierung dieser Architektur ist auf GitHub verfügbar.
Aufbau
Laden Sie eine Visio-Datei dieser Architektur herunter.
Workflow
Der folgende Datenfluss entspricht dem vorherigen Diagramm:
In dieser Architektur gibt es zwei Datenquellen, die Datenströme in Echtzeit generieren. Der erste Stream enthält Fahrinformationen, und der zweite Stream enthält Tarifinformationen. Die Referenzarchitektur enthält einen simulierten Datengenerator, der aus einer Reihe statischer Dateien liest und die Daten an Azure Event Hubs überträgt. Die Datenquellen in einer echten Anwendung sind Geräte, die in den Taxikabinen installiert sind.
Event Hubs ist ein Ereignisaufnahmedienst. 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 ist eine Apache Spark-basierte Analyseplattform, die für die Microsoft Azure Cloud Services-Plattform optimiert ist. Azure Databricks wird verwendet, um die Taxifahrt- und Tarifdaten zu korrelieren und die korrelierten Daten mit Nachbarschaftsdaten zu bereichern, die im Azure Databricks-Dateisystem gespeichert sind.
Azure Cosmos DB- ist ein vollständig verwalteter Datenbankdienst mit mehreren Modellen. 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 es Ihnen, nahezu echtzeitbasierte Analysen zu betriebstechnischen Daten in Azure Cosmos DB auszuführen, ohne dass Leistungs- oder Kosteneffekte auf Ihre transaktionsbezogene Arbeitsauslastung auftreten. Sie können diese Ergebnisse erzielen, indem Sie serverlosen SQL-Pool und Spark poolsverwenden. Diese Analysemodule stehen im Azure Synapse Analytics-Arbeitsbereich zur Verfügung.
mit Spiegelung von Azure Cosmos DB für NoSQL in Microsoft Fabric können Sie Azure Cosmos DB-Daten in die restlichen Daten in Microsoft Fabric integrieren.
Log Analytics ist ein Tool in Azure Monitor, mit dem Sie Protokolldaten aus verschiedenen Quellen abfragen und analysieren können. Anwendungsprotokolldaten, die Azure Monitor erfasst werden, werden in einem Log Analytics-Arbeitsbereichgespeichert. Sie können Log Analytics-Abfragen verwenden, um Metriken zu analysieren und zu visualisieren und Protokollmeldungen zu prüfen, um Probleme innerhalb der Anwendung zu identifizieren.
Szenariodetails
Ein Taxiunternehmen sammelt Daten zu jeder Taxifahrt. In diesem Szenario wird davon ausgegangen, dass zwei separate Geräte Daten senden. Das Taxi verfügt über einen Meter, der Informationen über jede Fahrt sendet, einschließlich Dauer, Entfernung und Abholung und Rückgabeorte. Ein separates Gerät akzeptiert Zahlungen von Kunden und sendet Daten zu den Fahrpreisen. Um Fahrerschaftstrends zu erkennen, möchte das Taxiunternehmen die durchschnittliche Spitze pro Meile für jede Nachbarschaft in Echtzeit berechnen.
Datenerfassung
Um eine Datenquelle zu simulieren, verwendet diese Referenzarchitektur das New York City-Taxidatenset1. Dieses Dataset enthält Daten über Taxireisen in New York City von 2010 bis 2013. Es enthält Sowohl Fahr- als auch Tarifdatensätze. Die Fahrtdaten umfassen die Reisedauer, die Entfernung der Reise sowie die Abhol- und Rückgabeorte. Die Fahrpreisdaten enthalten die Beträge von Fahrpreis, Steuern und Trinkgeld. Felder in beiden Datensatztypen umfassen medallion number, hack license, and vendor ID. Die Kombination dieser drei Felder identifiziert ein Taxi und einen Fahrer eindeutig. 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 die Datensätze liest und an 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 direkt angeben. Andernfalls werden Datensätze nach einem Roundrobinverfahren Partitionen zugewiesen.
In diesem Szenario sollten Fahrdaten und Tarifdaten derselben Partitions-ID für ein bestimmtes Taxi-Taxi zugewiesen werden. Diese Zuordnung ermöglicht Es Databricks, einen Grad an Parallelität anzuwenden, wenn sie die beiden Datenströme korreliert. Beispielsweise entspricht ein Datensatz in Partition n der Fahrdaten einem Datensatz in Partition n der Tarifdaten.
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 einen expliziten Partitionsschlüssel bereitzustellen, wenn daten an Event Hubs gesendet werden.
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 automatisch aufblasenaktivieren. Dieses Feature skaliert automatisch die Durchsatzeinheiten basierend auf dem Datenverkehr bis zu einem konfigurierten Maximum.
Datenstromverarbeitung
In Azure Databricks führt ein Auftrag die Datenverarbeitung durch. Der Auftrag wird einem Cluster zugewiesen und anschließend darauf ausgeführt. Der Auftrag kann benutzerdefinierter Code sein, der in Java oder einem Spark Notizbuchgeschrieben wurde.
In dieser Referenzarchitektur ist der Auftrag ein Java-Archiv, das Klassen enthält, die in Java und Scala geschrieben wurden. Wenn Sie das Java-Archiv für einen Databricks-Auftrag angeben, gibt der Databricks-Cluster die Klasse für den Vorgang an. 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 den Nachbarschaftsinformationen
Die Fahrdaten umfassen die Breiten- und Längengradkoordinaten der Abhol- und Abgabestandorte. Diese Koordinaten sind nützlich, aber nicht einfach für die Analyse verbraucht. Daher werden diese Daten mit Nachbarschaftsdaten erweitert, die aus einer Shapefile-gelesen werden.
Das Shapefile-Format ist binär und kann nicht einfach analysiert werden. Die GeoTools--Bibliothek stellt jedoch Tools für Geospatialdaten bereit, die das Shapefile-Format verwenden. Diese Bibliothek wird in der com.microsoft.pnp.GeoFinder Klasse verwendet, um den Nachbarschaftsnamen basierend auf den Koordinaten für Die Abholung und Rückgabeorte zu bestimmen.
val neighborhoodFinder = (lon: Double, lat: Double) => {
NeighborhoodFinder.getNeighborhood(lon, lat).get()
}
Nehmen Sie an den Fahr- und Tarifdaten teil
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 Fahrdaten mit den Tarifdaten verknüpft:
val mergedTaxiTrip = rides.join(fares, Seq("medallion", "hackLicense", "vendorId", "pickupTime"))
Verarbeiten der Daten und Einfügen in Azure Cosmos DB
Der durchschnittliche Tarifbetrag für jede Nachbarschaft 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")
Der durchschnittliche Tarifbetrag wird dann in Azure Cosmos DB eingefügt:
maxAvgFarePerNeighborhood
.writeStream
.queryName("maxAvgFarePerNeighborhood_cassandra_insert")
.outputMode(OutputMode.Append())
.foreach(new CassandraSinkForeach(connector))
.start()
.awaitTermination()
Überlegungen
Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.
Sicherheit
Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für sicherheitsrelevante.
Der Zugriff auf den Azure Databricks-Arbeitsbereich wird mithilfe der Administratorkonsolegesteuert. Die Administratorkonsole enthält Funktionen zum Hinzufügen von Benutzern, zum Verwalten von Benutzerberechtigungen und zum Einrichten des einmaligen Anmeldens. Die Zugriffssteuerung für Arbeitsbereiche, Cluster, Aufträge und Tabellen kann ebenfalls über die Administratorkonsole festgelegt werden.
Verwalten von Geheimnissen
Azure Databricks enthält einen geheimen Speicher, der zum Speichern von Anmeldeinformationen und zum Verweisen auf sie in Notizbüchern und Aufträgen verwendet wird. Bereichspartitionsgeheimnisse im geheimen Azure Databricks-Speicher:
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
Verwenden Sie einen Azure Key Vault-gesicherten Bereich anstelle des systemeigenen Azure Databricks-Bereichs.
Im Code erfolgt der Zugriff auf Geheimnisse über die secrets-Hilfsprogramme von Azure Databricks.
Kostenoptimierung
Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Prüfliste für die Überprüfung der Kostenoptimierung.
Verwenden Sie den Azure-Preisrechner, um die voraussichtlichen Kosten zu ermitteln. Berücksichtigen Sie die folgenden Dienste, die in dieser Referenzarchitektur verwendet werden.
Überlegungen zu Den Kosten für Event Hubs
Diese Referenzarchitektur stellt Event Hubs auf der Standardebene bereit. Das Preismodell basiert auf Durchsatzeinheiten, Eingangsereignissen und Aufzeichnungsereignissen. Ein Eingangsereignis ist eine Dateneinheit mit 64 KB oder weniger. 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 weitere Aufbewahrungstage benötigen, sollten Sie die Dedizierte Stufe berücksichtigen. Diese Stufe bietet Bereitstellungen mit einem Mandanten, die strenge Anforderungen haben. Dieses Angebot erstellt einen Cluster, der auf Kapazitätseinheiten basiert und nicht von Durchsatzeinheiten abhängig ist. Die Standardebene wird auch basierend auf Eingangsereignissen und Durchsatzeinheiten abgerechnet.
Weitere Informationen finden Sie unter Event Hubs-Preise.
Überlegungen zu Azure Databricks-Kosten
Azure Databricks bietet die Standardebene und die Premium-Stufe, die beide drei Workloads unterstützen. Diese Referenzarchitektur stellt einen Azure Databricks-Arbeitsbereich auf der Premium-Ebene bereit.
Datenverarbeitungsworkloads sollten auf einem Auftragscluster ausgeführt werden. Dateningenieure verwenden Cluster zum Erstellen und Ausführen von Aufträgen. Datenanalyseworkloads sollten auf einem allzweckorientierten Cluster ausgeführt werden und sind für Datenwissenschaftler vorgesehen, um Daten und Erkenntnisse interaktiv zu untersuchen, zu visualisieren, zu bearbeiten und freizugeben.
Azure Databricks bietet mehrere Preismodelle.
Pay-as-you-go-Plan
Sie werden virtuellen Computern (VMs) in Clustern und Azure Databricks-Einheiten (DBUs) basierend auf der ausgewählten VM-Instanz in Rechnung gestellt. Ein DBU ist eine Einheit der Verarbeitungsfunktion, die pro Sekunde in Rechnung gestellt wird. Der DBU-Verbrauch hängt von der Größe und dem Typ der Instanz ab, die in Azure Databricks ausgeführt wird. Die Preise hängen von der gewählten Arbeitsauslastung und -stufe ab.
Vorkaufplan
Sie verpflichten sich, DBUs als Azure Databricks-Einheiten für ein oder drei Jahre zu übernehmen, um die Gesamtbetriebskosten für diesen Zeitraum im Vergleich zum Pay-as-you-go-Modell zu reduzieren.
Weitere Informationen finden Sie unter Azure Databricks-Preis.
Überlegungen zu Azure Cosmos DB-Kosten
In dieser Architektur schreibt der Auftrag Azure Databricks eine Reihe von Datensätzen in Azure Cosmos DB. Sie werden für die von Ihnen reservierte Kapazität belastet, die in Anforderungseinheiten pro Sekunde (RU/s) gemessen wird. Diese Kapazität wird verwendet, um Einfügevorgänge auszuführen. 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 mithilfe des Portals oder der Azure CLI erhöhen, bevor Sie Schreibvorgänge ausführen und dann den Durchsatz nach Abschluss dieser Vorgänge verringern. Der Durchsatz für den Schreibzeitraum ist die Summe des minimalen Durchsatzes, der für die spezifischen Daten und den für den Einfügevorgang erforderlichen Durchsatz benötigt wird. Bei dieser Berechnung wird davon ausgegangen, dass keine andere Arbeitsauslastung ausgeführt wird.
Beispielkostenanalyse
Angenommen, Sie konfigurieren einen Durchsatzwert von 1.000 RU/s in einem Container. Es wird für 24 Stunden für 30 Tage bereitgestellt, insgesamt 720 Stunden.
Der Container wird pro Stunde mit 10 Einheiten von 100 RU/s pro Stunde in Rechnung gestellt. Zehn Einheiten mit 0,008 $ (pro 100 RU/s pro Stunde) werden bei 0,08 $ pro Stunde berechnet.
Für 720 Stunden oder 7.200 Einheiten (von 100 RUs) werden Sie für den Monat 57,60 $ in Rechnung gestellt.
Der Speicher wird auch für jede GB in Rechnung gestellt, die für Ihre gespeicherten Daten und den Index verwendet wird. Weitere Informationen finden Sie unter Azure Cosmos DB – Preismodell.
Verwenden Sie den Azure Cosmos DB-Kapazitätsrechner für eine schnelle Schätzung der Workloadkosten.
Operative Exzellenz
Operational Excellence deckt die Betriebsprozesse ab, mit denen eine Anwendung bereitgestellt und in der Produktion ausgeführt wird. Weitere Informationen finden Sie unter Prüfliste für die Überprüfung von Operational Excellence.
Überwachung
Azure Databricks basiert auf Apache Spark. Sowohl Azure Databricks als auch Apache Spark verwenden Apache Log4j als Standardbibliothek für die Protokollierung. Zusätzlich zur Standardprotokollierung, die Apache Spark bereitstellt, können Sie die Protokollierung in Log Analytics implementieren. Weitere Informationen finden Sie unter Überwachung von Azure Databricks.
Da die com.microsoft.pnp.TaxiCabReader Klasse Fahr- und Tarifmeldungen verarbeitet, ist eine Nachricht möglicherweise falsch formatiert und daher ungültig. In einer Produktionsumgebung ist es wichtig, diese falsch formatierten Nachrichten zu analysieren, um ein Problem mit den Datenquellen zu identifizieren, damit es schnell behoben werden kann, um Datenverluste zu vermeiden. Die com.microsoft.pnp.TaxiCabReader Klasse registriert einen Apache Spark Accumulator, der die Anzahl der falsch formatierten Fahrdatensätze und Fahrdatensätze verfolgt:
@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 zum Senden von Metriken. Einige der nativen Dropwizard-Metrikfelder sind mit Log Analytics nicht kompatibel, weshalb diese Referenzarchitektur eine benutzerdefinierte Dropwizard-Spüle und Reporter enthält. Es formatiert die Metriken im Format, das Log Analytics erwartet. Wenn Apache Spark Metriken meldet, werden auch die benutzerdefinierten Metriken für die falsch formatierten Fahrt- und Fahrpreisdaten gesendet.
Sie können die folgenden Beispielabfragen in Ihrem Log Analytics-Arbeitsbereich verwenden, um den Betrieb des Streamingauftrags zu überwachen. Das Argument ago(1d) in jeder Abfrage gibt alle Datensätze zurück, die am letzten Tag generiert wurden. Sie können diesen Parameter anpassen, um einen anderen Zeitraum anzuzeigen.
Während des Datenstromabfragevorgangs protokollierte Ausnahmen
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
Auftragsvorgang 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
Ressourcenorganisation und -bereitstellungen
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 Infrastruktur-as-Code-Prozess bereitzustellen. Mithilfe von Vorlagen können Sie Bereitstellungen mit Azure DevOps-Diensten oder anderen kontinuierlichen Integrations- und Fortlaufendbereitstellungslösungen (CI/CD) problemlos automatisieren.
Platzieren Sie jede Workload in einer separaten Bereitstellungsvorlage, und speichern Sie die Ressourcen in Quellcodeverwaltungssystemen. Sie können die Vorlagen gemeinsam oder einzeln im Rahmen eines CI/CD-Prozesses bereitstellen. Dieser Ansatz vereinfacht den Automatisierungsprozess.
In dieser Architektur werden Event Hubs, Log Analytics und Azure Cosmos DB als einzelne Workload identifiziert. Diese Ressourcen sind in einer einzigen Azure Resource Manager-Vorlage enthalten.
Erwägen Sie ein Staging Ihrer Workloads. Stellen Sie in verschiedenen Phasen bereit, und führen Sie Überprüfungen in jeder Phase aus, bevor Sie zur nächsten Phase wechseln. Auf diese Weise können Sie steuern, wie Sie Updates an Ihre Produktionsumgebungen übertragen und unerwartete Bereitstellungsprobleme minimieren.
In dieser Architektur gibt es mehrere Bereitstellungsphasen. Erwägen Sie das Erstellen einer Azure DevOps-Pipeline und das Hinzufügen dieser Phasen. Sie können die folgenden Phasen automatisieren:
- Starten Sie einen Databricks-Cluster.
- Konfigurieren sie databricks CLI.
- Installieren Sie Scala-Tools.
- Fügen Sie die Geheimschlüssel von Databricks hinzu.
Erwägen Sie das Schreiben automatisierter Integrationstests, um die Qualität und Zuverlässigkeit des Databricks-Codes und seines Lebenszyklus zu verbessern.
Bereitstellen dieses Szenarios
Führen Sie zum Bereitstellen und Ausführen der Referenzimplementierung die Schritte in der GitHub-Infodateiaus.