Lyft constrói camada semântica própria para governar métricas e escalar definições de dados com precisão
Aprofundamento CEVIU
Aprofundamento
A Lyft não está só construindo uma camada semântica, está fechando o ciclo entre governança de dados e operação de IA com um sistema que codifica lógica de negócio em YAML e Jinja SQL, não em código Python ou em dashboards isolados. Isso é diferente do Metrics SQL da Rill (coberto em 9/4), que prioriza SQL puro como interface humana, mas não tem a mesma integração nativa com agentes de IA nem o modelo de donos compartilhados (negócio + operações) que a Lyft adotou. A solução também se distingue do sistema de armazenamento de métricas do Airbnb (22/4): lá o foco é escala e tolerância a falhas em séries temporais; aqui, é precisão semântica e propagação automática de mudanças, uma métrica atualizada no template Jinja reflete em todos os relatórios, APIs e agentes em minutos.
O Amundsen, criado pela própria Lyft em 2019, agora serve como o catálogo de referência para essa nova camada, mas com um giro: antes era um repositório passivo de metadados; hoje, é o ponto de descoberta ativa para métricas versionadas, com linhagem ligada à lógica SQL subjacente. Isso contrasta com o OpenMetadata, que ganha tração por ter governança embutida, mas ainda não oferece o mesmo nível de acoplamento entre definição de métrica e execução de IA. A tendência global confirma: camadas semânticas deixaram de ser experimentais, o mercado deve triplicar de valor até 2034, e a Gartner já classifica 'camadas compostas' como estratégia viável, já que uma única camada universal continua inalcançável.
O que mudou
Em abril, a CEVIU destacou o desafio conceitual do 'labirinto dos dados' (20/4), onde métricas divergentes geram conflito entre equipes, mas na época, a Lyft ainda não havia tornado pública sua solução interna. Em 22 de junho de 2026, ela revela não apenas que resolveu o problema, mas *como*: com Golden Metrics versionadas, responsabilidade compartilhada explícita e, crucialmente, com agentes de IA integrados como consumidores de primeira classe, não como add-ons. Isso transforma o que era teoria (governança para IA, discutida em 27/5 na Salesforce) em prática operacional: regras de acesso, segurança e conformidade são aplicadas em tempo real durante a execução da IA, não em aprovações prévias.
Por que isso importa
Isso importa porque elimina o principal gargalo de escalabilidade em analytics e IA: a duplicação manual de lógica. Quando um time de finanças muda a fórmula de 'Margem EBITDA Ajustado', métrica que a Lyft já usa desde 2023, a alteração não exige revisão em dezenas de dashboards, notebooks e pipelines. Ela vai direto para o template Jinja, é validada, versionada e propagada automaticamente. Para engenheiros de dados, isso reduz manutenção. Para analistas, significa confiança imediata nos números. Para agentes de IA, significa respostas baseadas em definições atualizadas, sem risco de usar uma versão obsoleta de 'Gross Bookings' numa consulta sobre desempenho trimestral.
Linha do tempo
Lyft lança o Amundsen como plataforma de metadados de código aberto
Lyft introduz novas métricas-chave, incluindo Gross Bookings e margem de EBITDA Ajustado
CEVIU cobre o Metrics SQL da Rill, destacando camadas semânticas nativas em SQL
CEVIU publica 'Dédalo e o Labirinto dos Dados', apontando a divergência semântica como principal gargalo
CEVIU analisa governança de agentes corporativos na Salesforce, com foco em identidade e APIs
Lyft revela sua Metric Semantic Layer interna, com governança de Golden Metrics e integração nativa com agentes de IA
Perguntas frequentes
Como a Metric Semantic Layer da Lyft se diferencia de ferramentas como dbt Semantic Layer ou Snowflake Semantic Views?
Ela é interna, altamente customizada para o ecossistema da Lyft e focada exclusivamente em métricas, não em modelos ou visualizações. Usa templates Jinja SQL + YAML, não depende de um vendor específico, e tem governança de IA nativa desde o início. Ferramentas como dbt ou Snowflake oferecem camadas genéricas; a da Lyft é uma infraestrutura de produto, com donos de negócio envolvidos diretamente na aprovação de versões.
Por que usar Amundsen se há alternativas como OpenMetadata?
A Lyft já tem domínio profundo do Amundsen, criou-o em 2019 e o mantém há anos. Integrar a nova camada semântica nele reduziu custo de adoção e garantiu consistência de linhagem. O OpenMetadata é mais rico em governança, mas exigiria migração de metadados e reengenharia de fluxos, algo desnecessário quando o objetivo era velocidade de entrega e controle total.
O que significa 'responsabilidade compartilhada entre donos de negócios e operações' na prática?
Um dono de negócio (ex.: head de finanças) aprova a definição e o propósito de uma métrica, como 'Rides Canceladas'. Um dono de operações (ex.: engenheiro de dados) valida a implementação técnica, testa a performance e garante a integração com APIs e agentes. Ambos assinam a versão no Git, e qualquer mudança requer nova aprovação conjunta.
Como os agentes de IA usam essa camada semântica?
Eles consultam a Metric UI ou chamam as APIs Python diretamente para obter definições válidas, filtros permitidos e dimensões disponíveis. A camada impõe restrições em tempo real: se um agente tenta calcular 'Margem EBITDA' com dados de 2022, mas a métrica só foi definida para 2024+, ele recebe erro, não um número incorreto.
Fontes
- eng.lyft.comfonte original
- Categoria
- CEVIU Dados
- Publicado
- 22 de junho de 2026
- Editoria
- CEVIU Dados
