L’histoire de la transformation numérique d’un journal vieux de 130 ans
G1. 2008~2014 : focalisation sur la recommandation d’actualités basée sur les articles lus. Basé sur SQL Server
G2. 2014~2016 : introduction de l’ETL. Analyse de données à grande échelle, nouvelles questions et augmentation du volume de données
→ SQL Server devient un goulot d’étranglement. Migration vers Redshift + framework ETL
→ Automatisation de la planification pour exécuter du SQL plusieurs fois par jour
→ Prise en charge de modèles de données complexes avec SQL + Python
G3. 2016~2018 : début du big data chez FT
→ Objectif : minimiser la latence des données. L’ingestion de données se faisait une fois par jour (24 h). Il fallait réduire cela pour pouvoir réagir plus vite aux tendances
→ Développement d’une bibliothèque de tracking maison capable d’envoyer toutes les interactions des lecteurs
→ Tous les événements passent par AWS SNS → SQS → Kinesis → Parquet → Redshift
→ Création d’un serveur NodeJS pour traiter les raw events, enrichir les événements en combinant des données internes et externes, puis les envoyer vers Kinesis
→ Utilisation de Kinesis Firehose pour transformer les événements en CSV et les stocker dans S3
→ Comme des doublons d’événements se produisaient, un cluster Redshift séparé a été créé pour les traiter, ce qui a ralenti la latence
G4. 2019 : reconstruction de la plateforme avec un accent sur l’ajout de valeur métier
→ Volonté de transformer la plateforme de données en PaaS
→ Introduction de Kubernetes. Migration d’ECS vers EKS
→ Introduction d’Airflow
→ AWS SNS → SQS → Kinesis → Parquet → Airflow → Redshift
G5. 2020 : l’ère des données en temps réel
→ G4 était une bonne base, mais le temps réel restait impossible
→ Migration de la configuration complexe SNS, SQS, Kinesis vers Kafka (Amazon MSK)
→ La plateforme de stream processing est Apache Spark
→ kafka → spark → parquet(delta lake, redshift) ↔ airflow
→ Introduction d’Apache Avro pour la validation des données : Data Contract
→ Utilisation de Presto pour interroger Redshift, S3, Kafka, etc.
Plans pour la suite
→ Aujourd’hui, les données arrivent depuis trois composants, Airflow, Spark et Kafka, mais cela doit évoluer vers une base CDC (Change Data Capture)
→ Changer la plateforme pour que tout le monde puisse accéder aux données en temps réel. Améliorer la Data UI afin de permettre le stream processing en drag & drop
4 commentaires
Oh, j’aime bien ce genre de billet de blog. On y voit bien les réflexions propres à chaque génération d’architecture. Même une entreprise de presse conçoit donc une plateforme de données de cette envergure.
Cela dit, ils ont relié ça sous la forme SQS -> boucle Nodejs -> Kinesis. Je me demande s’il n’était pas possible de tout régler simplement avec Kinesis seul. Je ne maîtrise pas encore très bien AWS, donc bon T_T
Merci pour cet excellent résumé de l'article !
Pour voir l’explication des termes mentionnés ici,
Référez-vous à l’article ci-dessus ainsi qu’à la vidéo GeekNews YouTube « Comprendre l’infrastructure de données moderne »
Et consultez aussi l’exemple du New York Times, qui a lui aussi réussi une transformation digitale similaire
Le New York Times qui ne rate pas son coup - Comment le NYT a réussi sa numérisation
https://youtu.be/K2qiAFTzDLU
Le New York Times (qui ne rate pas son coup) https://fr.news.hada.io/topic?id=3172