Die Geschichte der digitalen Transformation einer 130 Jahre alten Zeitung
G1. 2008–2014: Fokus auf Nachrichtenempfehlungen auf Basis gelesener Artikel. Auf SQL Server basierend
G2. 2014–2016: Einführung von ETL. Analyse großer Datenmengen und neue Fragestellungen, wachsendes Datenvolumen
→ SQL Server wurde zum Engpass. Wechsel zu Redshift + ETL-Framework
→ Automatisierung der Planung, damit SQL mehrmals täglich ausgeführt wird
→ Unterstützung komplexer Datenmodelle mit SQL + Python
G3. 2016–2018: Der Beginn von Big Data@FT
→ Ziel war die Minimierung der Datenlatenz. Data Ingestion erfolgte einmal täglich (24h). Das musste reduziert werden, um schneller auf Trends reagieren zu können
→ Entwicklung einer eigenen Tracking-Bibliothek, die alle Interaktionen der Leser übertragen kann
→ Alle Events über AWS SNS → SQS → Kinesis → Parquet → Redshift
→ Erstellung eines NodeJS-Servers zur Verarbeitung von Raw Events, der interne und externe Daten kombiniert, Events anreichert und anschließend in Kinesis einspeist
→ Mit Kinesis Firehose wurden Events in CSV umgewandelt und in S3 gespeichert
→ Da es zu doppelten Events kam, wurde ein separater Redshift-Cluster zu deren Verarbeitung aufgebaut, was jedoch die Latenz erhöhte
G4. 2019: Neuaufbau der Plattform mit Fokus auf zusätzlichen Business Value
→ Die Datenplattform sollte in eine PaaS umgewandelt werden
→ Einführung von Kubernetes. Von ECS zu EKS
→ Einführung von Airflow
→ AWS SNS → SQS → Kinesis → Parquet → Airflow → Redshift
G5. 2020: Jetzt beginnt das Zeitalter von Echtzeitdaten
→ G4 war gut, aber Echtzeit war noch immer nicht möglich
→ Wechsel von der komplexen Konfiguration mit SNS, SQS und Kinesis zu Kafka (Amazon MSK)
→ Die Stream-Processing-Plattform ist Apache Spark
→ kafka → spark → parquet(delta lake, redshift) ↔ airflow
→ Einführung von Apache Avro zur Datenvalidierung: Data Contract
→ Einsatz von Presto, um Redshift, S3, Kafka usw. abzufragen
Zukünftige Pläne
→ Derzeit kommen Daten aus drei Komponenten: Airflow, Spark und Kafka. Das soll auf eine CDC(Change Data Capture)-Basis umgestellt werden
→ Umstellung, damit alle auf Echtzeitdaten zugreifen können. Verbesserung der Data UI, sodass Stream-Processing per Drag & Drop möglich wird
4 Kommentare
Oh, solche Blogbeiträge mag ich. Man merkt, dass darin die Überlegungen jeder Architektur-Generation stecken. Also entwerfen selbst Medienhäuser Datenplattformen in dieser Größenordnung.
Übrigens wurde das offenbar so verbunden: SQS -> Nodejs-Schleife -> Kinesis. Ich frage mich, ob man das nicht einfach allein mit Kinesis hätte abdecken können. Ich kenne mich mit AWS noch nicht besonders gut aus, daher …
Vielen Dank für die gute Zusammenfassung des Artikels!
Wenn Sie Erklärungen zu den hier vorkommenden Begriffen sehen möchten,
lesen Sie den obigen Beitrag und sehen Sie sich das GeekNews-YouTube-Video „Moderne Dateninfrastruktur verstehen“ an.
Und als ähnliches Beispiel für eine erfolgreiche digitale Transformation lesen Sie auch die Geschichte der New York Times.
Wie die New York Times ohne zu scheitern die Digitalisierung geschafft hat
https://youtu.be/K2qiAFTzDLU
Die New York Times (ohne zu scheitern) https://de.news.hada.io/topic?id=3172