Dies ist ein Gastbeitrag von Dr. Yannick Misteli, Lead Cloud Platform and ML Engineering in Global Product Strategy (GPS) bei Roche.
Kürzlich wurde die Initiative Roche Data Insights (RDI) ins Leben gerufen, um unsere Vision durch neue Arbeitsweisen und Zusammenarbeit zu verwirklichen, um gemeinsame, interoperable Daten und Erkenntnisse mit föderierter Governance zu erstellen. Darüber hinaus soll eine vereinfachte & integrierte Datenlandschaft aufgebaut werden, um Insights Communities zu stärken. Einer der ersten Bereiche, der sich an diesem Programm beteiligt, ist der Bereich Go-to-Market (GTM), der Verkauf, Marketing, medizinischen Zugang und Marktangelegenheiten bei Roche umfasst. Die GTM-Domain ermöglicht es Roche, Kunden zu verstehen und letztendlich wertvolle Dienstleistungen zu entwickeln und bereitzustellen, die ihren Bedürfnissen entsprechen. GTM als Domäne erstreckt sich über Angehörige der Gesundheitsberufe (HCPs) hinaus auf ein größeres Ökosystem des Gesundheitswesens, das aus Patienten, Gemeinschaften, Gesundheitsbehörden, Kostenträgern, Anbietern, Hochschulen, Wettbewerbern usw. besteht. Daher sind Daten und Analysen der Schlüssel zur Unterstützung der internen und externen Stakeholder in ihren Entscheidungsprozessen durch umsetzbare Erkenntnisse.
Roche GTM baute auf AWS eine moderne Plattform für Daten und maschinelles Lernen (ML) auf und nutzte Best Practices von DevOps. Das Mantra von Everything as Code (EaC) war der Schlüssel zum Aufbau eines vollständig automatisierten, skalierbaren Data Lake und Data Warehouse auf AWS.
In diesem Beitrag erfahren Sie, wie Roche AWS-Produkte und -Services wie z Amazon App-Flow, AWS Lake-Formation und Amazon RedShift um ihren Data Lake bereitzustellen und zu füllen; wie sie Daten bezogen, transformiert und in das Data Warehouse geladen haben; und wie sie Best Practices in den Bereichen Sicherheit und Zugangskontrolle umgesetzt haben.
In den folgenden Abschnitten tauchen Sie tief in die skalierbare, sichere und automatisierte moderne Datenplattform von Roche ein. Wir demonstrieren, wie Sie die Datenerfassung und Sicherheitsstandards automatisieren und Best Practices von DevOps nutzen, um die Verwaltung Ihrer modernen Datenplattform auf AWS zu vereinfachen.
Architektur der Datenplattform
Das folgende Diagramm veranschaulicht die Datenplattformarchitektur.
Die Architektur enthält die folgenden Komponenten:
Sicherheit der Lake-Formation
Wir verwenden Lake Formation, um alle Daten zu sichern, wenn sie im Data Lake landen. Die Aufteilung jeder Data-Lake-Schicht in verschiedene S3-Buckets und -Präfixe ermöglicht fein abgestufte Zugriffskontrollrichtlinien, die Lake Formation implementiert. Dieses Konzept erstreckt sich auch auf das Sperren des Zugriffs auf bestimmte Zeilen und Spalten und das Anwenden von Richtlinien auf bestimmte IAM-Rollen und Benutzer. Governance und Zugriff auf Data Lake-Ressourcen sind schwierig zu verwalten, aber Lake Formation vereinfacht diesen Prozess für Administratoren.
Um den Zugriff auf den Data Lake mit Lake Formation zu sichern, werden die folgenden Schritte mithilfe des AWS CDK mit angepassten Konstrukten automatisiert:
- Registrieren Sie die S3-Daten-Buckets und -Präfixe sowie die entsprechenden AWS Glue-Datenbanken bei Lake Formation.
- Fügen Sie Data Lake-Administratoren hinzu (GitLab-Runner-IAM-Bereitstellungsrolle und Administrator-IAM-Rolle).
- Gewähren Sie den IAM-Rollen des AWS Glue-Auftrags Zugriff auf die spezifischen AWS Glue-Datenbanken.
- Gewähren Sie die AWS Lambda IAM-Rollenzugriff auf die Amazon AppFlow-Datenbanken.
- Gewähren Sie den aufgelisteten IAM-Rollen Zugriff auf die entsprechenden Tabellen in den AWS Glue-Datenbanken.
AWS Glue-Datenkatalog
Der AWS Glue Data Catalog ist der zentrale Registrierungs- und Zugriffspunkt für alle Datenbanken und Tabellen, die sowohl im Data Lake als auch in Amazon Redshift erstellt werden. Dies bietet zentralisierte Transparenz für alle Ressourcen zusammen mit ihren Schemas und dem Speicherort aller Daten, auf die verwiesen wird. Dies ist ein kritischer Aspekt für alle Datenoperationen, die innerhalb der Lake House-Plattform durchgeführt werden.
Datenbeschaffung und -aufnahme
Daten werden mithilfe von AWS Glue-Jobs und Amazon AppFlow bezogen und in den Data Lake geladen. Die aufgenommenen Daten werden im Amazon Redshift Data Warehouse durch verfügbar gemacht Amazon Redshift-Spektrum Verwendung externer Schemas und Tabellen. Der Prozess zum Erstellen der externen Schemas und zum Verknüpfen mit dem Datenkatalog wird später in diesem Beitrag beschrieben.
Amazon AppFlow Salesforce-Aufnahme
Amazon AppFlow ist ein vollständig verwalteter Integrationsservice, mit dem Sie Daten aus Quellen wie Salesforce, SAP und Zendesk abrufen können. Roche lässt sich in Salesforce integrieren, um Salesforce-Objekte sicher in ihren Data Lake zu laden, ohne benutzerdefinierten Code schreiben zu müssen. Roche sendet ML-Ergebnisse auch zurück an Salesforce, indem Amazon AppFlow verwendet wird, um den Prozess zu vereinfachen.
Salesforce-Objekte werden zuerst vollständig in Amazon S3 geladen und dann auf einen täglichen inkrementellen Ladevorgang umgestellt, um Deltas zu erfassen. Die Daten landen im Rohzonen-Bucket im Parquet-Format, wobei das Datum als Partition verwendet wird. Die Amazon AppFlow-Flows werden mithilfe einer YAML-Konfigurationsdatei erstellt (siehe folgenden Code). Diese Konfiguration wird von der AWS CDK-Bereitstellung verwendet, um die entsprechenden Flows zu erstellen.
Die YAML-Konfiguration erleichtert die Auswahl, ob Daten aus einem S3-Bucket zurück in Salesforce oder von Salesforce in einen S3-Bucket geladen werden sollen. Diese Konfiguration wird anschließend von der AWS CDK-App und den entsprechenden Stacks gelesen, um sie in Amazon AppFlow-Flows zu übersetzen.
Die folgenden Optionen sind in der vorhergehenden YAML-Konfigurationsdatei angegeben:
- Quelle – Der Speicherort, von dem Daten abgerufen werden sollen (Amazon S3, Salesforce)
- Reiseziel – Das Ziel, an das Daten gesendet werden sollen (Amazon S3, Salesforce)
- Objekt_Name – Der Name des Salesforce-Objekts, mit dem interagiert werden soll
- inkrementelle_Last – Ein boolescher Wert, der angibt, ob die Last inkrementell oder vollständig sein soll (0 bedeutet vollständig, 1 bedeutet inkrementell)
- Zeitplanausdruck – Der Cron- oder Rate-Ausdruck zum Ausführen des Flows (
na
macht es auf Anfrage) - s3_prefix – Das Präfix zum Pushen oder Pullen der Daten im S3-Bucket
- Connector_Profil – Der Amazon AppFlow-Connector-Profilname, der beim Herstellen einer Verbindung mit Salesforce verwendet werden soll (kann eine CSV-Liste sein)
- Umwelt – Die Umgebung, in der dieser Amazon AppFlow-Flow bereitgestellt werden soll (
all
bedeutet Dev und Prod bereitstellen,dev
bedeutet Entwicklungsumgebung,prod
bedeutet Produktionsumgebung) - upsert_field_list – Der Satz von Salesforce-Objektfeldern (kann eine CSV-Liste sein), die verwendet werden, wenn ein Upsert-Vorgang zurück zu Salesforce durchgeführt wird (gilt nur, wenn Daten aus einem S3-Bucket zurück zu Salesforce geladen werden)
- bookmark_col – Der Name der Spalte, die im Datenkatalog zum Registrieren der Zeichenfolgenpartition für das tägliche Ladedatum verwendet werden soll
Registrieren Sie Salesforce-Objekte im Datenkatalog
Führen Sie die folgenden Schritte aus, um in den Data Lake geladene Daten mit Data Catalog zu registrieren und sie mit Amazon Redshift zu verknüpfen:
- Sammeln Sie Salesforce-Objektfelder und entsprechende Datentypen.
- Erstellen Sie eine entsprechende AWS Glue-Datenbank im Datenkatalog.
- Führen Sie eine Abfrage für Amazon Redshift aus, um ein externes Schema zu erstellen, das mit der AWS Glue-Datenbank verknüpft ist.
- Erstellen Sie Tabellen und Partitionen in der AWS Glue-Datenbank und den Tabellen.
Auf die Daten kann über den Datenkatalog und das Amazon Redshift-Cluster zugegriffen werden.
Dynamische Felderfassung von Amazon AppFlow
Um das Schema des geladenen Salesforce-Objekts im Data Lake zu erstellen, rufen Sie die folgende Python-Funktion auf. Der Code nutzt einen Amazon AppFlow-Client aus Boto3 um die Salesforce-Objektfelder dynamisch zu sammeln, um das Schema des Salesforce-Objekts zu erstellen.
Wir verwenden die Funktion sowohl für die Erstellung des Amazon AppFlow-Flows über die AWS CDK-Bereitstellung als auch für die Erstellung der entsprechenden Tabelle im Data Catalog in der entsprechenden AWS Glue-Datenbank.
Erstellen Sie eine Amazon CloudWatch Events-Regel, eine AWS Glue-Tabelle und eine Partition
Um neue Tabellen (eine pro Salesforce-Objekt, die in Amazon S3 geladen werden) und Partitionen automatisch zum Datenkatalog hinzuzufügen, erstellen Sie eine Amazon CloudWatch-Ereignisse Regel. Mit dieser Funktion können Sie die Daten sowohl in AWS Glue als auch in Amazon Redshift abfragen.
Nachdem der Amazon AppFlow-Flow abgeschlossen ist, ruft er eine CloudWatch Events-Regel und eine entsprechende Lambda-Funktion auf, um entweder eine neue Tabelle in AWS Glue zu erstellen oder eine neue Partition mit der entsprechenden Datumszeichenfolge für den aktuellen Tag hinzuzufügen. Die CloudWatch Events-Regel sieht wie im folgenden Screenshot aus.
Die aufgerufene Lambda-Funktion verwendet die Amazon SageMaker Data Wrangler Python-Paket um mit dem Datenkatalog zu interagieren. Unter Verwendung der vorangehenden Funktionsdefinition können die Objektfelder und ihre Datentypen an den folgenden Funktionsaufruf übergeben werden:
Wenn die Tabelle bereits vorhanden ist, erstellt die Lambda-Funktion eine neue Partition, um das Datum zu berücksichtigen, an dem der Flow abgeschlossen wurde (falls noch nicht vorhanden):
Externe Amazon Redshift-Schemaabfrage
Für jedes Amazon AppFlow-Connector-Profil, das in der vorherigen Konfiguration vorhanden ist, wird eine AWS Glue-Datenbank erstellt. Die Objekte, die von Salesforce in Amazon S3 geladen werden, werden als Tabellen im Datenkatalog unter der entsprechenden Datenbank registriert. Um die Datenbank im Data Catalog mit einem externen Amazon Redshift-Schema zu verknüpfen, führen Sie die folgende Abfrage aus:
Das angegebene iam_role
Der Wert muss eine im Voraus erstellte IAM-Rolle sein und die entsprechenden Zugriffsrichtlinien müssen angegeben sein, um den Amazon S3-Standort abzufragen.
Jetzt können alle im Data Catalog verfügbaren Tabellen mit SQL lokal in Amazon Redshift Spectrum abgefragt werden.
Amazon AppFlow Salesforce-Ziel
Roche trainiert und ruft ML-Modelle mit Daten aus dem Amazon Redshift Data Warehouse auf. Nachdem die ML-Modelle abgeschlossen sind, werden die Ergebnisse zurück in Salesforce übertragen. Durch die Verwendung von Amazon AppFlow können wir die Datenübertragung erreichen, ohne benutzerdefinierten Code schreiben zu müssen. Das Schema der Ergebnisse muss mit dem Schema des entsprechenden Salesforce-Objekts übereinstimmen, und das Format der Ergebnisse muss entweder im JSON-Zeilen- oder im CSV-Format geschrieben werden, um in Salesforce zurückgeschrieben zu werden.
AWS Glue-Jobs
Um lokale Datenfeeds in den Data Lake einzuspeisen, hat Roche eine Reihe von AWS Glue-Jobs in Python erstellt. Es gibt verschiedene externe Quellen, darunter Datenbanken und APIs, die direkt in den S3-Bucket der Rohzone geladen werden. Die AWS Glue-Jobs werden täglich ausgeführt, um neue Daten zu laden. Die geladenen Daten folgen dem Partitionierungsschema von YYYYMMDD
Format, um Datensätze effizienter zu speichern und abzufragen. Die geladenen Daten werden dann für effizientere Abfrage- und Speicherzwecke in das Parquet-Format konvertiert.
Amazon EKS und KubeFlow
Um ML-Modelle auf Amazon EKS bereitzustellen, verwendet Roche Kubeflow auf Amazon EKS. Die Verwendung von Amazon EKS als Backbone-Infrastruktur erleichtert das Erstellen, Trainieren, Testen und Bereitstellen von ML-Modellen und die Interaktion mit Amazon Redshift als Datenquelle.
Firewall-Manager
Als zusätzliche Sicherheitsebene trifft Roche zusätzliche Vorsichtsmaßnahmen durch die Verwendung von Firewall Manager. Dies ermöglicht es Roche, eingehenden und ausgehenden Datenverkehr durch die Verwendung von zustandsbehafteten und zustandslosen Regelsätzen explizit zu verweigern oder zuzulassen. Dies ermöglicht es Roche auch, bestimmten ausgehenden Zugriff auf externe Websites zuzulassen und Websites zu verweigern, auf die Ressourcen innerhalb ihrer Amazon VPC keinen Zugriff haben sollen. Dies ist insbesondere beim Umgang mit sensiblen Datensätzen von entscheidender Bedeutung, um sicherzustellen, dass die Daten gesichert sind und keine Chance haben, extern verschoben zu werden.
CI / CD
Die gesamte im Architekturdiagramm skizzierte Infrastruktur wurde automatisiert und mithilfe einer Pipeline für kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) in mehreren AWS-Regionen bereitgestellt GitLab-Runner als Orchestrator. Die GitFlow -Modell wurde zum Verzweigen und Aufrufen automatisierter Bereitstellungen für die AWS-Konten von Roche verwendet.
Infrastruktur als Code und AWS CDK
Best Practices für Infrastructure as Code (IaC) wurden verwendet, um die Erstellung der gesamten Infrastruktur zu erleichtern. Das Roche-Team verwendet das Python AWS CDK, um alle Änderungen bereitzustellen, zu versionieren und zu warten, die an der Infrastruktur in ihrem AWS-Konto vorgenommen werden.
AWS CDK-Projektstruktur
Die oberste Ebene der Projektstruktur in GitLab umfasst die folgenden Ordner (obwohl nicht nur auf diese Ordner beschränkt), um Infrastruktur und Code an einem Ort zu halten.
Um die verschiedenen Ressourcen zu erleichtern, die im Roche-Konto erstellt werden, wurde die Bereitstellung wie folgt aufgeteilt AWS CDK-Apps, die mehrere umfassen Stapeln:
core
data_lake
data_warehouse
Das core
app enthält alle Stacks im Zusammenhang mit der Kontoeinrichtung und dem Konto-Bootstrapping, wie zum Beispiel:
- VPC-Erstellung
- Anfängliche IAM-Rollen und -Richtlinien
- Sicherheitsleitplanken
Das data_lake
app enthält alle Stacks im Zusammenhang mit der Erstellung des AWS Data Lake, wie zum Beispiel:
- Lake Formation Einrichtung und Registrierung
- AWS Glue-Datenbankerstellung
- S3-Bucket-Erstellung
- Amazon AppFlow-Flow-Erstellung
- Einrichtung des AWS Glue-Auftrags
Das data_warehouse
App enthält alle Stacks im Zusammenhang mit der Einrichtung der Data-Warehouse-Infrastruktur, wie z. B.:
- Amazon Redshift-Cluster
- Load Balancer zum Amazon Redshift-Cluster
- Protokollierung
Die beschriebene AWS CDK-Projektstruktur wurde gewählt, um die Bereitstellung flexibel zu halten und aufeinander aufbauende Stacks logisch zusammenzufassen. Diese Flexibilität ermöglicht es, Bereitstellungen nach Funktionen aufzuschlüsseln und nur dann bereitzustellen, wenn es wirklich erforderlich und erforderlich ist. Durch diese Entkopplung verschiedener Teile der Bereitstellung bleibt die Flexibilität bei der Bereitstellung erhalten.
AWS CDK-Projektkonfiguration
Projektkonfigurationen sind flexibel und werden als YAML-Konfigurationsdateien extrapoliert. Beispielsweise hat Roche den Prozess zum Erstellen eines neuen Amazon AppFlow-Flows vereinfacht und kann Flows nach Bedarf hinzufügen oder entfernen, indem es einfach einen neuen Eintrag in seiner YAML-Konfiguration hinzufügt. Wenn die GitLab-Runner-Bereitstellung das nächste Mal erfolgt, übernimmt sie die Änderungen in der AWS CDK-Synthese, um einen neuen Änderungssatz mit den neuen Ressourcen zu generieren. Diese Konfiguration und Einrichtung hält die Dinge dynamisch und flexibel, während die Konfiguration vom Code entkoppelt wird.
Netzwerkarchitektur
Das folgende Diagramm veranschaulicht die Netzwerkarchitektur.
Wir können die Architektur wie folgt unterteilen:
- Alle AWS-Services werden in zwei Availability Zones bereitgestellt (außer Amazon Redshift)
- Nur private Subnetze haben Zugriff auf die lokale Roche-Umgebung
- Dienste werden in Back-End-Subnetzen bereitgestellt
- Perimeterschutz mit AWS-Netzwerk-Firewall
- Ein Netzwerk-Load-Balancer veröffentlicht Dienste in der lokalen Umgebung
Netzwerksicherheitskonfigurationen
Infrastruktur, Konfiguration und Sicherheit sind als Code in AWS CDK definiert, und Roche verwendet eine CI/CD-Pipeline, um sie zu verwalten und bereitzustellen. Roche verfügt über eine AWS CDK-Anwendung zur Bereitstellung der Kerndienste des Projekts: VPC, VPN-Konnektivität und AWS-Sicherheitsdienste (AWS-Konfiguration, Amazon-Wachdienst und AWS-Sicherheits-Hub). Die VPC enthält vier Netzwerkschichten, die in zwei Availability Zones bereitgestellt werden, und sie haben VPC-Endpunkte für den Zugriff auf AWS-Services wie Amazon S3, Amazon DynamoDB und Amazon Simple Queue-Dienst (Amazon-SQS). Sie beschränken den Internetzugang mithilfe der AWS Network Firewall.
Die Infrastruktur ist als Code definiert und die Konfiguration ist getrennt. Roche führte die VPC-Einrichtung durch Ausführen der CI/CD-Pipeline durch, um ihre Infrastruktur bereitzustellen. Die Konfiguration befindet sich in einer bestimmten externen Datei; Wenn Roche einen Wert der VPC ändern möchte, müssen sie einfach diese Datei ändern und die Pipeline erneut ausführen (ohne neue Codezeilen einzugeben). Wenn Roche Konfigurationen ändern möchte, möchten sie keinen Code ändern müssen. Es macht es Roche leicht, Änderungen vorzunehmen und sie einfach in ihrer Umgebung bereitzustellen, wodurch die Änderungen transparenter und einfacher zu konfigurieren sind. Die Nachvollziehbarkeit der Konfiguration ist transparenter und vereinfacht die Freigabe der Änderungen.
Der folgende Code ist ein Beispiel für die VPC-Konfiguration:
Die Vorteile dieses Ansatzes sind wie folgt:
- Es ist nicht erforderlich, den AWS CDK-Konstruktor zu ändern und neuen Code zu erstellen, um die VPC-Konfiguration zu ändern
- Zentraler Punkt zum Verwalten der VPC-Konfiguration
- Nachvollziehbarkeit von Änderungen und Historie der Konfiguration durch Git
- Stellen Sie die gesamte Infrastruktur in wenigen Minuten in anderen Regionen oder Konten neu bereit
Betrieb und Alarmierung
Roche hat ein automatisiertes Warnsystem entwickelt, wenn ein Teil der End-to-End-Architektur auf Probleme stößt, wobei der Schwerpunkt auf Problemen beim Laden von Daten aus AWS Glue oder Amazon AppFlow liegt. Die gesamte Protokollierung wird standardmäßig zu Debugging-Zwecken in CloudWatch veröffentlicht.
Die Betriebswarnungen wurden für den folgenden Workflow erstellt:
- AWS Glue-Jobs und Amazon AppFlow-Flows nehmen Daten auf.
- Wenn ein Job fehlschlägt, gibt er ein Ereignis an eine CloudWatch Events-Regel aus.
- Die Regel wird ausgelöst und ruft eine Lambda-Funktion auf, um Fehlerdetails an eine zu senden Amazon Simple Notification Service Thema (Amazon SNS).
- Das SNS-Thema hat einen Lambda-Abonnenten, der aufgerufen wird:
- Die Lambda-Funktion liest bestimmte Webhook-URLs aus AWS Secrets Manager.
- Die Funktion löst eine Warnung an die spezifischen externen Systeme aus.
- Die externen Systeme erhalten die Nachricht und die entsprechenden Parteien werden mit Details über das Problem informiert.
Die folgende Architektur skizziert die Alarmierungsmechanismen, die für die Lake House-Plattform entwickelt wurden.
Zusammenfassung
Die GTM-Domäne (Go-To-Market) hat es ihren Geschäftsinteressenten, Dateningenieuren und Datenwissenschaftlern erfolgreich ermöglicht, eine Plattform bereitzustellen, die auf viele Anwendungsfälle, mit denen Roche konfrontiert ist, erweiterbar ist. Es ist ein wichtiger Wegbereiter und Beschleuniger für die GTM-Organisation bei Roche. Durch eine moderne Datenplattform ist Roche nun in der Lage, Kunden besser zu verstehen und letztendlich wertvolle Dienstleistungen zu entwickeln und bereitzustellen, die ihren Bedürfnissen entsprechen. Es erstreckt sich über Angehörige der Gesundheitsberufe (HCPs) hinaus auf ein größeres Ökosystem des Gesundheitswesens. Die Plattform und Infrastruktur in diesem Blog helfen dabei, sowohl interne als auch externe Stakeholder in ihren Entscheidungsprozessen durch umsetzbare Erkenntnisse zu unterstützen und zu beschleunigen.
Die Schritte in diesem Beitrag können Ihnen dabei helfen, den Aufbau einer ähnlichen modernen Datenstrategie mit verwalteten AWS-Services zu planen, um Daten aus Quellen wie Salesforce aufzunehmen, automatisch Metadatenkataloge zu erstellen und Daten nahtlos zwischen dem Data Lake und dem Data Warehouse auszutauschen und bei Bedarf Warnungen zu erstellen eines orchestrierten Daten-Workflow-Fehlers. In Teil 2 dieses Beitrags erfahren Sie, wie das Data Warehouse mithilfe eines agilen Datenmodellierungsmusters aufgebaut wurde und wie ELT-Jobs schnell entwickelt, orchestriert und konfiguriert wurden, um automatisierte Datenqualitätstests durchzuführen.
Besonderer Dank gilt dem Roche-Team: Joao Antunes, Krzysztof Slowinski, Krzysztof Romanowski, Bartlomiej Zalewski, Wojciech Kostka, Patryk Szczesnowicz, Igor Tkaczyk, Kamil Piotrowski, Michalina Mastalerz, Jakub Lanski, Chun Wei Chan, Andrzej Dziabowski für ihre Projektabwicklung und Unterstützung mit diesem Beitrag.
Über den Autor
Dr. Yannick Misteli, Roche – Dr. Yannick Misteli leitet Cloud-Plattform- und ML-Engineering-Teams im Bereich Global Product Strategy (GPS) bei Roche. Er hat eine Leidenschaft für Infrastruktur und die Operationalisierung datengesteuerter Lösungen und verfügt über umfassende Erfahrung in der Steigerung der Wertschöpfung von Unternehmen durch Datenanalyse.
Simon Dimaline, AWS – Simon Dimaline ist seit mehr als 20 Jahren auf Data Warehousing und Datenmodellierung spezialisiert. Derzeit arbeitet er für das Data & Analytics-Team innerhalb von AWS Professional Services und beschleunigt die Kundenakzeptanz von AWS-Analyseservices.
Matt Noyce, AWS – Matt Noyce ist Senior Cloud Application Architect im Bereich Professional Services bei Amazon Web Services. Er arbeitet mit Kunden zusammen, um Lösungen auf AWS für ihre Geschäftsanforderungen zu entwerfen, zu entwerfen, zu automatisieren und zu erstellen.
Chema Artal Banon, AWS – Chema Artal Banon ist Sicherheitsberater bei AWS Professional Services und arbeitet mit AWS-Kunden zusammen, um ihre Sicherheit zu entwerfen, aufzubauen und zu optimieren, um das Geschäft voranzutreiben. Er ist darauf spezialisiert, Unternehmen dabei zu helfen, ihren Weg in die AWS Cloud so sicher wie möglich zu beschleunigen, indem er Kunden hilft, Vertrauen und technische Fähigkeiten aufzubauen.
Ein besonderes Dankeschön geht an die folgenden Personen, deren Fachwissen diesen Beitrag von AWS ermöglicht hat:
- Thiyagarajan Arumugam – Principal Analytics Specialist Solutions Architect
- Taz sagte – Analytics-Tech-Leiter
- Glenith Paletta – Enterprise-Service-Manager
- Mike Murphy – Globaler Account-Manager
- Natacha Maheshe – Senior Produktmarketing Manager
- Derek Jung - Führender Produkt Bereichsleiter
- Jamie Campbell – Amazon AppFlow-Produktmanager
- Kamen Sharlandjiev – Leitender Lösungsarchitekt – Amazon AppFlow
- Sunil Jethwani - Hauptarchitekt für Kundenlieferungen
- Vinay Shukla – Hauptproduktmanager von Amazon Redshift
- Nausheen sagte - Progamm Manager
- '
- "
- &
- 100
- 11
- 9
- LiveBuzz
- Beschleuniger
- Zugang
- Konto
- Adoption
- agil
- Alle
- bereits
- Amazon
- Amazon Web Services
- Analytik
- APIs
- App
- Anwendung
- Architektur
- Bereich
- Automatisiert
- Verfügbarkeit
- verfügbar
- AWS
- Balancer
- Sein
- BESTE
- Best Practices
- Blog
- bauen
- Building
- Geschäft
- rufen Sie uns an!
- österreichische Unternehmen
- Übernehmen
- Schecks
- Cloud
- Cloud-Plattform
- Code
- Zusammenarbeit
- Kolonne
- Communities
- Unternehmen
- Konkurrenz
- Vertrauen
- Konfiguration
- Konnektivität
- Berater
- verbrauchen
- kontinuierlich
- Erstellen
- kritischem
- Strom
- Kunden
- technische Daten
- Datenanalyse
- Datensee
- Datenqualität
- Datensatz
- Datenstrategie
- Data Warehouse
- Datenbase
- Datenbanken
- Tag
- Behandlung
- Lieferanten
- Demand
- Bereitstellen
- Design
- Entwickler
- Entwicklung
- DevOps
- anders
- Tut nicht
- Domains
- Fahren
- Ökosystem
- ermächtigen
- Entwicklung
- Ingenieure
- Unternehmen
- Arbeitsumfeld
- insbesondere
- etablierten
- Event
- Veranstaltungen
- Beispiel
- ERFAHRUNGEN
- Gesichter
- Scheitern
- Felder
- Vorname
- Flexibilität
- Fluss
- Format
- gefunden
- voller
- Funktion
- erzeugen
- Global
- Governance
- gps
- Gruppe an
- GUEST
- Guest Post
- Gesundheit
- Gesundheitspflege
- Gesundheitswesen
- Hilfe
- Geschichte
- Häuser
- Ultraschall
- Hilfe
- HTTPS
- IAC
- IAM
- Einschließlich
- Infrastruktur
- Initiative
- Einblicke
- Integration
- Internet
- Probleme
- IT
- Job
- Jobs
- Reise
- Wesentliche
- führen
- führenden
- LERNEN
- lernen
- Niveau
- Limitiert
- LINK
- Liste
- Belastung
- örtlich
- Standorte
- Maschinelles Lernen
- Making
- Management
- Mantra
- Karte
- Markt
- Marketing
- Spiel
- Materie
- sowie medizinische
- ML
- Modell
- Modellieren
- mehr
- erforderlich
- Netzwerk
- Benachrichtigung
- Einkauf & Prozesse
- Optionen
- Auftrag
- Organisation
- Andere
- Patienten
- Schnittmuster
- Personen
- pii
- Plattform
- Politik durchzulesen
- Gegenwart
- Principal
- privat
- Prozessdefinierung
- Produkt
- Produktion
- Produkte
- Profis
- Profil
- Programm
- Projekt
- Sicherheit
- bietet
- Öffentlichkeit
- Python
- Qualität
- Roh
- Registrierung:
- Downloads
- Antwort
- Die Ergebnisse
- Rückgabe
- Rollen
- Führen Sie
- Laufen
- sagemaker
- Vertrieb
- salesforce
- Saft
- Wissenschaftler
- Sicherheitdienst
- Lösungen
- kompensieren
- Einstellung
- Teilen
- von Locals geführtes
- ähnlich
- Einfacher
- So
- Lösungen
- spezialisiert
- SQL
- Normen
- Lagerung
- speichern
- Strategie
- erfolgreich
- Support
- System
- Systeme und Techniken
- Tech
- Technische
- Test
- Testen
- Durch
- Zeit
- gemeinsam
- Top
- Rückverfolgbarkeit
- der Verkehr
- schult Ehrenamtliche
- Transparenz
- Anwendungsfälle
- Nutzer
- Wert
- Version
- Seh-
- VPN
- Warehouse
- Lagerung
- Netz
- Web-Services
- Webseiten
- .
- ohne
- Arbeitsablauf.
- arbeiten,
- Werk
- Schreiben
- Jahr
- Jahr
- Zendesk