Netflix

A métrica norte da Netflix é engajamento. Todo artwork na home, toda linha "porque você assistiu", todo preview em autoplay é escolhido por um modelo treinado em centenas de bilhões de eventos por dia. O trabalho da plataforma de dados é tornar isso possível sem que o time escreva 100 pipelines sob medida.

Duas restrições definem tudo:

• Latência: personalização precisa refletir o que você acabou de assistir — medido em segundos, não horas.
• Escala: centenas de petabytes de dados de viewing, feature stores que sustentam milhares de modelos, tudo rodando em storage commodity S3 em vez de um warehouse proprietário.

Todo evento de cliente — play, pause, joinha, impressão de artwork — flui pro Keystone, o pipeline de eventos gerenciado da Netflix em cima do Kafka. Keystone não é "só Kafka". É uma camada self-service onde times de produto registram um tópico, definem um schema, e ganham:

• Roteamento automático pra sinks downstream (S3/Iceberg, Elasticsearch, Druid, jobs Flink customizados)
• Evolução de schema com checks de backward-compatibility
• Uma frota Kafka multi-cluster gerenciada que o producer nunca vê

O time publica ~1 trilhão de eventos por dia via Keystone. Producers só conhecem o nome do tópico; o Keystone cuida de durabilidade, replay e fan-out. É o padrão que a maioria das empresas eventualmente redescobre: o valor não é o Kafka, é a plataforma em cima dele.

A Netflix escreveu o Apache Iceberg porque tabelas Hive em S3 não sobreviviam a escritas concorrentes, mudanças de schema ou evolução de partição na escala deles. Iceberg deu:

• Commits ACID em object storage — jobs batch e streaming podem escrever a mesma tabela sem corromper
• Time travel — todo commit é um snapshot; SELECT ... AS OF TIMESTAMP simplesmente funciona
• Particionamento oculto — o esquema de partição pode mudar sem reescrever queries
• Planejamento via manifest — poda de arquivos sem listar o S3

Uma leitura típica de tabela Iceberg na Netflix parece assim:

-- Lê o estado da tabela de eventos como estava 3h atrás
SELECT event_type, count(*)
FROM prodhive.datalake.viewing_events
FOR TIMESTAMP AS OF current_timestamp - INTERVAL '3' HOUR
WHERE event_date = current_date - INTERVAL '1' DAY
GROUP BY event_type;

Time travel não é feature de demo — é como eles debugam pipelines, fazem backfill com segurança e reproduzem datasets de treino de ML.

A Netflix roda uma camada de compute poliglota em cima do lakehouse Iceberg:

• Apache Spark — ETL batch pesado, geração de features, preparo de dados de treino de ML. Roda na plataforma de containers interna, com autoscale.
• Apache Flink — milhares de jobs stateful de streaming. Features em tempo real, agregações near-real-time alimentando personalização.
• Presto / Trino — o engine de SQL interativo que todo analista e engenheiro usa pra explorar o lake. Sustenta dashboards internos e a camada de query ad-hoc.
• Metaflow — o framework de workflows de ML que a Netflix open-sourceou; fica acima do Spark e da camada de orquestração pra dar aos cientistas de dados uma experiência Python-nativa.

Mesmas tabelas, três engines. É esse o ponto do lakehouse — o storage É a API.

O caminho de um clique até uma linha personalizada na home:

1. Você aperta play. O cliente emite um evento; o Keystone deposita no Kafka. 2. Um job Flink atualiza seu estado de interação de curto prazo em segundos (materializado num store de baixa latência). 3. Um job Spark batch (noturno ou a cada poucas horas) recomputa features de horizonte longo e as escreve num feature store sustentado por Iceberg + Cassandra + EVCache. 4. Quando você abre o app, o serviço de recomendação consulta o feature store, roda o modelo de ranking e devolve a home personalizada.

O truque é que online (serving do modelo) e offline (treino) leem as *mesmas* features do *mesmo* store lógico. Sem skew entre o que o modelo viu no treino e no serving. Esse é um dos problemas mais duros em sistemas de ML, e o lakehouse é o motivo de conseguirem resolver uma vez em vez de por modelo.

Você não tem o tráfego da Netflix. Você provavelmente não deveria construir um Keystone. Mas as ideias transferem:

• Dono do seu formato de tabela, não do seu warehouse. Iceberg em S3 com Trino te dá 80% do que Snowflake vende, a 20% do custo, e seus dados continuam portáveis.
• Time travel é ferramenta de debug, não de demo. Ligue no dia em que constrói a tabela, não no dia em que tem o primeiro incidente.
• O pipeline de eventos é um produto. Se seus producers sabem que existe um broker, você sub-investiu. Dê a eles um nome de tópico e um schema registry, esconda o resto.
• Mesmas features, online e offline. Desenhe seu feature store pra que dados de treino e dados de serving sejam literalmente as mesmas linhas, em pontos diferentes no tempo. Snapshots do Iceberg tornam isso barato.