A história da transformação digital de um jornal de 130 anos
G1. 2008~2014: foco em recomendações de notícias com base nos artigos lidos. Baseado em SQL Server
G2. 2014~2016: introdução de ETL. Análise de dados em grande escala, novas perguntas e aumento do volume de dados
→ O SQL Server virou gargalo. Migração para Redshift + framework de ETL
→ Automação do agendamento para executar SQL várias vezes por dia
→ Suporte a modelos de dados complexos com SQL + Python
G3. 2016~2018: início do Big Data @ FT
→ Objetivo de minimizar a latência dos dados. A ingestão de dados acontecia uma vez por dia (24h). Era preciso reduzir isso para reagir mais rápido às tendências
→ Desenvolvimento de uma biblioteca própria de tracking capaz de enviar todas as interações dos leitores
→ Todos os eventos passavam por AWS SNS → SQS → Kinesis → Parquet → Redshift
→ Criação de um servidor NodeJS para processar eventos brutos, combinar dados internos e externos, enriquecer os eventos e então enviá-los ao Kinesis
→ Uso do Kinesis Firehose para transformar eventos em CSV e armazená-los no S3
→ Como havia situações de duplicação de eventos, foi criado um cluster Redshift separado para tratar isso, mas isso acabou aumentando a latência
G4. 2019: reconstrução da plataforma com foco em agregar valor de negócio
→ Queriam transformar a plataforma de dados em PaaS
→ Adoção de Kubernetes. De ECS para EKS
→ Adoção de Airflow
→ AWS SNS → SQS → Kinesis → Parquet → Airflow → Redshift
G5. 2020: agora é a era dos dados em tempo real
→ O G4 foi bom, mas ainda não permitia tempo real
→ Migração da configuração complexa de SNS, SQS e Kinesis para Kafka (Amazon MSK)
→ A plataforma de stream processing é Apache Spark
→ kafka → spark → parquet(delta lake, redshift) ↔ airflow
→ Adoção do Apache Avro para validação de dados: Data Contract
→ Uso de Presto para consultar Redshift, S3, Kafka etc.
Planos futuros
→ Atualmente os dados entram por três componentes, Airflow, Spark e Kafka, e isso deve ser alterado para um modelo baseado em CDC (Change Data Capture)
→ Mudança para que todos possam acessar dados em tempo real. Melhorar a Data UI para permitir stream processing com drag & drop
4 comentários
Ah, eu gosto desse tipo de post de blog. Dá para ver as preocupações de cada geração da arquitetura. Até empresas de mídia projetam uma plataforma de dados desse porte.
Aliás, eles conectaram algo como SQS -> loop em Node.js -> Kinesis. Fico me perguntando se não daria para resolver só com o Kinesis. Ainda não manjo muito de AWS, aff
Obrigado pelo ótimo resumo do artigo!
Se quiser ver a explicação dos termos mencionados aqui,
Consulte também o texto acima e o vídeo "Entendendo a infraestrutura de dados moderna" no YouTube do GeekNews.
E, de forma semelhante, veja também o caso do New York Times, que teve sucesso na transformação digital.
Como o NYT teve sucesso na digitalização — New York Times que não fracassa
https://youtu.be/K2qiAFTzDLU
New York Times (que não fracassa) https://pt.news.hada.io/topic?id=3172