Wählen Sie einen Kinesis-Dienst für die Streaming-Erfassung.
→Verarbeitung im Sub-Sekunden-Bereich, vom Consumer gesteuert → Kinesis Data Streams. Vollständig verwaltete Lieferung an S3/Redshift/OpenSearch mit optionaler Formatkonvertierung → Kinesis Data Firehose.
Warum: KDS speichert Datensätze (24h–365d) und unterstützt mehrere Consumer. Firehose hat keine Wiederholungsmöglichkeit; tauscht Wiederholung gegen Zero-Ops-Lieferung ein.
Referenz↗
Der Stream erreicht während der Spitzenlast ProvisionedThroughputExceeded-Fehler.
→Resharding. Jeder Shard unterstützt 1 MB/s oder 1.000 Datensätze/s Ingest, 2 MB/s Egress. Verwenden Sie einheitliche Partitionsschlüssel; aktivieren Sie Enhanced Fan-Out für >2 MB/s pro Consumer.
Warum: Hot-Partitionsschlüssel konzentrieren den Traffic auf einen Shard. Zufällige oder Hash-basierte Schlüssel verteilen die Last.
Referenz↗
Streaming-Workload ist sprunghaft und unvorhersehbar; manuelles Resharding ist operativer Aufwand.
→Kinesis Data Streams im On-Demand-Kapazitätsmodus. Skaliert standardmäßig automatisch auf 200 MB/s; Abrechnung pro Datenvolumen.
Referenz↗
Mehrere Consumer, die denselben Stream lesen, erreichen das Leselimit von 2 MB/s/Shard.
→Enhanced Fan-Out. Jeder Consumer erhält dedizierte 2 MB/s/Shard über Push-basiertes HTTP/2 SubscribeToShard.
Referenz↗
Maximieren Sie den Ingest-Durchsatz von der Producer-seitigen Anwendung.
→Kinesis Producer Library (KPL) mit Aggregation + Sammlung. Batcht mehrere Benutzerdatensätze zu einem Kinesis-Datensatz bis zu 1 MB; reduziert die PUT-Kosten.
Warum: Einzeldatensatz PutRecord ist ratenbegrenzt und teuer bei 50k Ereignissen/s. KPL aggregiert clientseitig.
Referenz↗
JSON-Clickstream in S3 als Parquet speichern, partitioniert nach Ereigniszeit.
→Firehose mit Datensatzformatkonvertierung (JSON → Parquet) unter Verwendung einer Glue Data Catalog-Tabelle + dynamischer Partitionierung auf dem Ereignis-Timestamp.
Warum: Parquet + Partitionierung senkt die Athena-Scan-Kosten drastisch. Dynamische Partitionierung vermeidet einen separaten ETL-Schritt.
Referenz↗
Einige Datensätze schlagen bei der Firehose-Transformation oder -Lieferung fehl; müssen für die Wiederholung erfasst werden.
→S3-Backup mit `AllData` oder `FailedDataOnly` konfigurieren. Fehlgeschlagene Datensätze landen im konfigurierten Präfix mit Fehlermetadaten.
Referenz↗
Stellen Sie sicher, dass in MSK keine Daten verloren gehen, wenn eine Broker-AZ ausfällt.
→Replikationsfaktor ≥ 3 über 3 AZs und `min.insync.replicas=2` mit Producer `acks=all`. Aktivieren Sie Multi-AZ über ZooKeeper-loses KRaft oder 3-AZ Broker-Platzierung.
Referenz↗
Streamen Sie von MSK nach S3, OpenSearch oder RDS, ohne einen Kafka Connect-Cluster verwalten zu müssen.
→MSK Connect mit verwaltetem Connector (Confluent S3 Sink, Debezium für CDC). Skaliert Worker pro WCU automatisch.
Referenz↗
Ein Thema speichert die neueste Version eines Datensatzes pro Schlüssel; alte Versionen können verworfen werden.
→Setzen Sie `cleanup.policy=compact` für das Thema. Kafka behält den neuesten Wert für jeden Schlüssel; ältere Datensätze mit demselben Schlüssel können verdichtet werden.
Referenz↗
Wiederkehrende wöchentliche Übertragung von 10 TB von On-Premises NFS nach S3 über Direct Connect.
→AWS DataSync mit On-Premises-Agent + geplanter Aufgabe. Überprüft die Datenintegrität, unterstützt inkrementelle Übertragungen, parallel.
Warum: DataSync ist schneller als aws-cli sync und handhabt Bandbreitenbegrenzung, Wiederholungsversuche und Verifizierung nativ.
Referenz↗
Daten von SaaS-APIs (Salesforce, ServiceNow, Zendesk) planmäßig in S3 ziehen.
→AWS AppFlow. Verwaltete Konnektoren, OAuth wird gehandhabt, geplant oder ereignisgesteuert, schreibt Parquet nach S3.
Referenz↗
Laufende Änderungen von On-Premises SQL Server auf Aurora MySQL mit minimaler Ausfallzeit replizieren.
→AWS DMS mit Full-Load + CDC-Aufgabe. Verwenden Sie vor DMS das Schema Conversion Tool (SCT) für heterogene Schema-/Codekonvertierung.
Referenz↗
DMS-Replikationsinstanz fällt aus — Replikation unterbricht.
→Multi-AZ für die Replikationsinstanz aktivieren. Synchroner Standby in einer anderen AZ; automatisches Failover.
Referenz↗
Benötigen Sie Analysen nahezu in Echtzeit auf OLTP Aurora-Daten ohne ETL-Pipeline.
→Aurora Zero-ETL-Integration zu Redshift. Kontinuierliche Replikation von Aurora-Daten nach Redshift; Abfragen sehen neue Daten innerhalb von Sekunden.
Warum: Eliminiert DMS / Glue / benutzerdefinierte CDC-Pipelines für den OLTP-zu-Warehouse-Anwendungsfall.
Referenz↗
100 TB historisches Archiv von On-Premises nach S3 verschieben; Bandbreite begrenzt.
→AWS Snowball Edge Storage Optimized. Physisches Gerät wird zum Standort geliefert; Daten kopieren; zurücksenden.
Referenz↗
Quell-JSON hat verschachtelte Arrays; nachgeschaltete relationale Analyse erfordert abgeflachte Zeilen.
→Glue PySpark `Relationalize`-Transformation (oder `explode()` in DataFrame) glättet verschachtelte Arrays in separate Zeilen/Tabellen.
Referenz↗
Glue Crawler leitet aus unordentlichen CSV-Daten mehrdeutige Typen (`choice<int,string>`) ab.
→Wenden Sie die `ResolveChoice`-Transformation an – Umwandlung in spezifischen Typ oder Projektion in Struct. Oder beheben Sie dies an der Quelle durch Erzwingung eines Schemas.
Referenz↗
Glue ETL-Job läuft stündlich auf wachsenden S3-Daten; es müssen nur neue Dateien verarbeitet werden.
→Glue Job-Lesezeichen aktivieren. Glue verfolgt verarbeitete Dateien/Partitionen und überspringt diese bei erneuten Läufen.
Warum: Vermeidet die erneute Verarbeitung des gesamten Datensatzes. Erforderlich für inkrementelle ETL-Pipelines.
Referenz↗
Glue Spark-Job schlägt mit OutOfMemoryError auf dem Driver während großer Aggregationen fehl.
→Wechseln Sie zu G.2X- oder G.4X-Workern (mehr Driver-Speicher) oder aktivieren Sie `--enable-glue-datacatalog` Pushdown-Prädikate, um die Shuffle-Daten zu reduzieren.
Referenz↗
Kontinuierliches Spark Structured Streaming gegen eine Kinesis-Quelle mit verwalteter Infrastruktur ausführen.
→AWS Glue Streaming ETL-Job. Spark Structured Streaming unter der Haube; Checkpointing nach S3.
Referenz↗
Business Analyst muss Daten bereinigen und transformieren, ohne Code schreiben zu müssen.
→AWS Glue DataBrew. Visuelle rezeptbasierte Transformationen (250+), Profiling, Lineage. Ausgabe nach S3, Redshift, RDS.
Referenz↗
Glue ETL-Job erst nach erfolgreicher Aktualisierung des Data Catalog durch Crawler ausführen.
→Glue Workflow mit bedingten Triggern. Crawler-Erfolg → ETL-Job auslösen. Fehler → überspringen / alarmieren.
Referenz↗
Crawler leitet alle CSV-Spalten als `string` ab — benötigt Datum- und Zahlentypen.
→Fügen Sie vor dem Crawling einen benutzerdefinierten Glue-Klassifikator (Grok-Muster oder Spaltenhinweis) hinzu. Alternativ schreiben Sie eine Header-Zeile mit expliziten Typen vor.
Referenz↗
Mehrere Producer/Consumer auf Kafka benötigen Schema-Evolution, ohne sich gegenseitig zu stören.
→AWS Glue Schema Registry mit Kompatibilitätsregeln (BACKWARD/FORWARD/FULL). Producer registrieren Schema; Consumer holen + validieren.
Referenz↗
Wählen Sie zwischen EMR und Glue für Spark ETL.
→Langlaufendes benutzerdefiniertes Spark mit detaillierter Abstimmung, mehreren Frameworks (Hive, Presto, Flink) → EMR. Serverless Pay-per-Job ETL mit Glue Data Catalog-Integration → Glue. Sprunghaftes/unvorhersehbares Spark → EMR Serverless.
Referenz↗
Intermittierende Spark/Hive-Jobs; gewünscht sind Zero Cluster Ops und keine Leerlaufzeiten.
→EMR Serverless. Vorinitialisierte Kapazitätspools für Starts mit geringer Latenz; skaliert pro Job; Abrechnung pro vCPU-Stunde.
Referenz↗
Mix aus On-Demand-Core- und Spot-Task-Nodes für kostenoptimiertes EMR.
→Instance Fleets mit Zielkapazität pro Typ. Core-Flotte On-Demand für HDFS-Stabilität; Task-Flotte Spot mit diversifizierten Instanztypen.
Referenz↗
Standardisierung auf Kubernetes; EMR Spark-Jobs sollen Cluster mit anderen Workloads teilen.
→EMR on EKS. Spark läuft als Pods auf bestehendem EKS-Cluster; Infrastruktur und IAM-Rollen über IRSA teilen.
Referenz↗
Zustandsbehaftetes Streaming mit Fenster-Aggregationen und Exactly-Once-Semantik.
→Kinesis Data Analytics for Apache Flink. Verwaltete Flink-Laufzeit; Checkpoints nach S3; auto-skaliert.
Referenz↗
Leichte Per-Record-Transformation auf einem Kinesis-Stream (<1 ms pro).
→Lambda mit Event Source Mapping auf KDS. `BatchSize`, `MaximumBatchingWindowInSeconds` und `ParallelizationFactor` optimieren.
Warum: Lambda ist günstiger als KCL/Glue Streaming für kleine Per-Record-Arbeiten.
Referenz↗
Step Functions-Schritt schlägt gelegentlich aufgrund vorübergehender Drosselung fehl; Wiederholung, dann Alarm.
→`Retry`-Block hinzufügen mit `ErrorEquals: ["Lambda.ThrottlingException", "States.TaskFailed"]`, `IntervalSeconds`, `MaxAttempts`, `BackoffRate=2`. Plus `Catch` zu einem Benachrichtigungsstatus.
Referenz↗
500.000 JSON-Dateien parallel über Lambda-Transformation verarbeiten.
→Step Functions Distributed Map-Zustand mit `MaxConcurrency` und ItemReader von S3. Fan-out über Tausende paralleler Lambda-Aufrufe.
Referenz↗
Komplexer DAG mit Cross-Service-Abhängigkeiten (Glue + Redshift COPY + Lambda + E-Mail) und Lineage-Anforderungen.
→Amazon MWAA (Managed Workflows for Apache Airflow). Native Airflow-Operatoren für AWS-Dienste; Git-gesteuerte DAG-Synchronisation.
Referenz↗
Müssen DAG-Änderungen zurücksetzen, falls eine Bereitstellung zu Fehlern führt.
→DAGs in einem versionierten S3-Bucket speichern + Synchronisierung über S3-Versioning. Oder DAG-Repo in Git mit Environment-pro-Branch + S3-Synchronisierung über CI pflegen.
Referenz↗