La historia de la transformación digital de un periódico de 130 años
G1. 2008~2014: enfoque en recomendaciones de noticias basadas en los artículos leídos. Basado en SQL Server
G2. 2014~2016: introducción de ETL. Análisis de datos a gran escala, nuevas preguntas y aumento en el volumen de datos
→ SQL Server se convirtió en un cuello de botella. Migración a Redshift + framework ETL
→ Automatización de la programación para ejecutar SQL varias veces al día
→ Soporte para modelos de datos complejos con SQL + Python
G3. 2016~2018: inicio de Big Data@FT
→ Objetivo de minimizar la latencia de los datos. La ingesta de datos se hacía una vez al día (24 h). Había que reducir eso para responder más rápido a las tendencias
→ Desarrollo de una biblioteca de tracking propia capaz de enviar todas las interacciones de los lectores
→ Todos los eventos pasan por AWS SNS → SQS → Kinesis → Parquet → Redshift
→ Crearon un servidor NodeJS para procesar los eventos raw, enriquecerlos combinando datos internos y externos, y luego subirlos a Kinesis
→ Uso de Kinesis Firehose para convertir eventos a CSV y almacenarlos en S3
→ Como ocurrían duplicados de eventos, crearon un clúster de Redshift separado para manejarlo, pero eso hizo más lenta la latencia
G4. 2019: reconstrucción de la plataforma con foco en agregar valor de negocio
→ Querían convertir la plataforma de datos en un PaaS
→ Adopción de Kubernetes. De ECS a EKS
→ Adopción de Airflow
→ AWS SNS → SQS → Kinesis → Parquet → Airflow → Redshift
G5. 2020: ahora es la era de los datos en tiempo real
→ G4 estuvo bien, pero todavía no era posible el tiempo real
→ Migración de la compleja configuración de SNS, SQS y Kinesis a Kafka (Amazon MSK)
→ La plataforma de stream processing es Apache Spark
→ kafka → spark → parquet(delta lake, redshift) ↔ airflow
→ Adopción de Apache Avro para validar datos: Data Contract
→ Uso de Presto para consultar Redshift, S3, Kafka, etc.
Planes a futuro
→ Actualmente los datos entran por tres componentes: Airflow, Spark y Kafka. Planean cambiar esto a un enfoque basado en CDC (Change Data Capture)
→ Cambiar para que todas las personas puedan acceder a datos en tiempo real. Mejorar la Data UI para que el procesamiento de streams pueda hacerse con drag & drop
4 comentarios
Oh, este tipo de posts de blog me encantan. Se nota la reflexión detrás de cada generación de la arquitectura. Incluso una empresa de medios diseña una plataforma de datos de esta escala.
Por cierto, conectaron algo como SQS -> bucle de Node.js -> Kinesis. Me pregunto si no se podría resolver simplemente con solo Kinesis. Todavía no conozco muy bien AWS, así que :(
¡Gracias por el buen resumen del artículo!
Si quieren ver la explicación de los términos que aparecen aquí,
consulten el texto anterior y el video de GeekNews en YouTube "Entendiendo la infraestructura de datos moderna".
Y, de forma similar, también revisen la historia de The New York Times, que logró con éxito la transformación digital.
The New York Times que no fracasa: ¿cómo logró el NYT digitalizarse con éxito?
https://youtu.be/K2qiAFTzDLU
The New York Times (que no fracasa) https://es.news.hada.io/topic?id=3172