Um guia para usar o Apache Cassandra como uma loja de recursos em tempo real

Este é um guia prático para usar o Apache Cassandra como um armazenamento de recursos em tempo real. Exploramos a IA em tempo real e os atributos exclusivos de desempenho e custo do Cassandra que o tornam um excelente banco de dados para uma loja de recursos e, em seguida, mergulhamos nos fundamentos das lojas de recursos e sua função em aplicativos em tempo real. O Cassandra é usado como uma loja de recursos por grandes empresas, incluindo Uber e Netflix; sob condições do mundo real, ele pode fornecer recursos para inferência em tempo real com um tp99 < 23ms.

O guia é dividido em várias seções principais. Começamos apresentando o Cassandra e seus recursos que o tornam a escolha ideal para uma loja de recursos. Em seguida, explicamos os fundamentos dos armazenamentos de recursos, incluindo o que são e como podem ser usados em aplicativos de tempo real. Depois disso, exploramos os detalhes de implementação da criação de uma loja de recursos usando Cassandra. Isso inclui modelagem de dados, ingestão e recuperação de recursos e manipulação de atualizações de dados. Por fim, oferecemos práticas recomendadas e dicas para usar o Cassandra como um armazenamento de recursos para garantir desempenho e escalabilidade ideais - desde requisitos de latência até requisitos de métricas de desempenho estimados para arquiteturas de referência e compatibilidade com ecossistemas.

Este guia não discute oaspectos da ciência de dados do aprendizado de máquina em tempo real ou o aspectos de gerenciamento do ciclo de vida dos recursos em um loja de recursos . As práticas recomendadas que abordaremos são baseadas em conversas técnicas com profissionais de grandes empresas de tecnologia, como Google, Facebook, Uber , AirBnB , e Netflix sobre como eles fornecem experiências de IA em tempo real para seus clientes em suas infraestruturas nativas de nuvem. Apesar de focarmos especificamente em como implementar o armazenamento de recursos em tempo real com Cassandra, as diretrizes de arquitetura realmente se aplicam a qualquer tecnologia de banco de dados, incluindo Redis, MongoDB e Postgres.

O que é IA em tempo real?

A IA em tempo real faz inferências ou modelos de treinamento com base em eventos recentes . Tradicionalmente, modelos de treinamento e inferências (previsões) com base em modelos são feitos em lote – geralmente durante a noite ou periodicamente ao longo do dia. Hoje, os sistemas modernos de aprendizado de máquina realizam inferências dos dados mais recentes para fornecer a previsão mais precisa possível. Um pequeno grupo de empresas como TikTok e Google ampliou ainda mais o paradigma de tempo real, incluindo treinamento em tempo real de modelos à medida que novos dados chegam.

Devido a essas mudanças na inferência e mudanças que provavelmente ocorrerão no treinamento do modelo, a persistência dos dados de recursos – dados usados para treinar e realizar inferências para um modelo de ML – também precisa se adaptar. Ao terminar de ler este guia, você terá uma visão mais clara de como o Cassandra e o DataStax Astra DB, um serviço gerenciado criado no Cassandra, atende às necessidades de IA em tempo real e como eles podem ser usados em conjunto com outras tecnologias de banco de dados para inferência e treinamento de modelos.

O que é uma loja de recursos?

Um armazenamento de recursos é um sistema de dados específico para aprendizado de máquina (ML) que:

• Executa pipelines de dados que transformam dados brutos em valores de recursos
• Armazena e gerencia os próprios dados do recurso e
• Serve dados de recursos de forma consistente para fins de treinamento e inferência

A IA em tempo real coloca demandas específicas em um armazenamento de recursos que Cassandra é exclusivamente qualificado para atender, especificamente quando se trata de armazenamento e serviço de recursos para serviço de modelo e treinamento de modelo.

Melhores Práticas

**Implementar consultas de baixa latência para veiculação de recursos

Para inferência em tempo real, os recursos precisam ser devolvidos aos aplicativos com baixa latência em escala. Os modelos típicos envolvem cerca de 200 recursos espalhados por cerca de 10 entidades. As inferências em tempo real exigem que o tempo seja orçado para coletar recursos, transformações de dados leves e realizar uma inferência. De acordo com a pesquisa a seguir (também confirmada por nossas conversas com profissionais), os repositórios de recursos precisam retornar os recursos a um aplicativo que executa inferência em menos de 50ms.

Normalmente, os modelos exigem “junções internas” em várias entidades lógicas – combinando valores de linhas de várias tabelas que compartilham um valor comum; isso representa um desafio significativo para o serviço de recursos de baixa latência. Veja o caso do Uber Eats, que prevê a hora de entregar uma refeição. Os dados precisam ser unidos a partir das informações do pedido, que são unidas às informações do restaurante, que são unidas ainda pelas informações de tráfego na região do restaurante. Nesse caso, são necessárias duas junções internas (veja a ilustração abaixo).

Para obter uma junção interna no Cassandra, pode-se desnormalizar os dados após a inserção ou fazer duas consultas sequenciais ao Cassandra + executar a junção no lado do cliente. Embora seja possível realizar todas as junções internas ao inserir dados no banco de dados por meio da desnormalização, ter uma proporção de 1:1 entre o modelo e a tabela é impraticável porque significa manter um número excessivo de tabelas desnormalizadas. As melhores práticas sugerem que o armazenamento de recursos precisa permitir 1-2 consultas sequenciais para junções internas, combinadas com desnormalização.

Aqui está um resumo das métricas de desempenho que podem ser usadas para estimar os requisitos para pipelines de ML em tempo real:

Condições de teste:

• características = 200

• número de tabelas (entidades) = 3

• número de junções internas = 2

• Consulta TPS: 5000 consultas/segundo

• TPS de gravação: 500 registros/segundo

• Tamanho do cluster: 3 nós no AstraDB*

  
  

Resumo do desempenho da latência (as incertezas aqui são desvios padrão):

• tp95 = 13,2(+/-0,6) ms

• tp99 = 23,0(+/-3,5) ms

• tp99,9 = 63(+/- 5)ms

  
  

Efeito da compactação:

• tp95 = insignificante
• tp99, tp999 = insignificante, capturado pelos sigmas citados acima

Efeito da captura de dados alterados (CDC):

• tp50, tp95 ~ 3-5 ms

• tp99 ~ 3ms

• tp999 ~ insignificante

  
  

*Os testes a seguir foram feitos no nível gratuito do Astra DB do DataStax, que é um ambiente sem servidor para Cassandra. Os usuários devem esperar desempenho de latência semelhante quando implantados em três notas usando as seguintes configurações recomendadas .

O impacto mais significativo na latência é o número de junções internas. Se apenas uma tabela for consultada em vez de três, o tp99 cairá 58%; para duas mesas, é 29% menor. O tp95 cai 56% e 21%, respectivamente. Como o Cassandra é escalonável horizontalmente, a consulta de mais recursos também não aumenta significativamente a latência média.

Por fim, se os requisitos de latência não puderem ser atendidos imediatamente, o Cassandra tem dois recursos adicionais: a capacidade de oferecer suporte a dados desnormalizados (e, portanto, reduzir junções internas) devido aos recursos de alta taxa de transferência de gravação e a capacidade de replicar dados seletivamente para caches de memória (por exemplo, Redis) por meio do Change Data Capture. Você pode encontrar mais dicas para reduzir a latência aqui.

Implemente gravações tolerantes a falhas e de baixa latência para transformações de recursos

Um componente-chave da IA em tempo real é a capacidade de usar os dados mais recentes para fazer uma inferência de modelo, por isso é importante que novos dados estejam disponíveis para inferência o mais rápido possível. Ao mesmo tempo, para casos de uso corporativo, é importante que as gravações sejam duráveis porque a perda de dados pode causar desafios de produção significativos.

*Os armazenamentos de objetos (por exemplo, S3 ou HIVE) podem ser substituídos por outros tipos de sistemas orientados a lotes, como data warehouses.

Há uma compensação entre gravações duráveis de baixa latência e serviço de recurso de baixa latência. Por exemplo, é possível armazenar apenas os dados em um local não durável (por exemplo, Redis), mas falhas de produção podem dificultar a recuperação dos recursos mais atualizados porque exigiria uma grande recomputação de eventos brutos .

Uma arquitetura comum sugere escrever recursos em um armazenamento off-line (por exemplo, Hive / S3) e replicar os recursos em um armazenamento on-line (por exemplo, cache na memória). Mesmo que isso forneça durabilidade e baixa latência para o fornecimento de recursos, isso acarreta o custo da introdução de latência para gravações de recursos, o que invariavelmente causa um desempenho de previsão inferior.

O Cassandra oferece uma boa compensação entre o serviço de recursos de baixa latência e as gravações de recursos "duráveis" de baixa latência. Os dados gravados no Cassandra normalmente foram replicados no mínimo três vezes e oferecem suporte à replicação multirregional. A latência da gravação até a disponibilidade para leitura geralmente é inferior a milissegundos. Como resultado, ao manter os recursos diretamente na loja online (Cassandra) e ignorar a loja offline, o aplicativo tem acesso mais rápido aos dados recentes para fazer previsões mais precisas. Ao mesmo tempo, o CDC, da loja online para a loja offline, permite o treinamento em lote ou a exploração de dados com as ferramentas existentes.

Implemente baixa latência e gravações para cache de previsão e monitoramento de desempenho

Além de armazenar a transformação de recursos, também é necessário armazenar previsões e outros dados de rastreamento para monitoramento de desempenho.

Existem vários casos de uso para armazenar previsões:

1. Armazenamento de previsão – neste cenário, um banco de dados usado para armazenar em cache as previsões feitas por um sistema em lote ou um sistema de streaming . A arquitetura de streaming é particularmente útil quando o tempo necessário para a inferência está além do aceitável em um sistema de solicitação-resposta.
2. Monitoramento do desempenho da previsão Freqüentemente, é necessário monitorar a saída da previsão de uma inferência em tempo real e comparar com os resultados finais. Isso significa ter um banco de dados para registrar os resultados da previsão e o resultado final.

O Cassandra é um armazenamento adequado para ambos os casos de uso por causa de seus recursos de alta taxa de transferência de gravação.

Planeje cargas de trabalho elásticas de leitura e gravação

O nível de transações de consulta e gravação por segundo geralmente depende do número de usuários simultaneamente usando o sistema. Como resultado, as cargas de trabalho podem mudar com base na hora do dia ou na época do ano. Ter a capacidade de aumentar e diminuir rapidamente o cluster para dar suporte a cargas de trabalho maiores é importante. O Cassandra e o Astra DB têm recursos que permitem o escalonamento dinâmico do cluster.

O segundo aspecto que pode afetar as cargas de trabalho de gravação é se houver alterações na lógica de transformação do recurso. Com um grande aumento nas cargas de trabalho de gravação, o Cassandra prioriza automaticamente a manutenção de consultas de baixa latência e a gravação de TPS em vez da consistência de dados, o que normalmente é aceitável para realizar inferência em tempo real.

Implemente suporte multirregional de baixa latência

Como a IA em tempo real se torna onipresente em todos os aplicativos, é importante garantir que os dados dos recursos estejam disponíveis o mais próximo possível de onde ocorre a inferência. Isso significa ter o armazenamento de recursos na mesma região que o aplicativo que faz a inferência. Replicar os dados no armazenamento de recursos entre regiões ajuda a garantir esse recurso. Além disso, replicar apenas os recursos em vez dos dados brutos usados para gerar os recursos reduz significativamente as taxas de saída da nuvem.

O Astra DB oferece suporte à replicação multirregional pronta para uso, com uma latência de replicação em milissegundos. Nossa recomendação é transmitir todos os dados brutos do evento para uma única região, executar a geração de recursos e armazenar e replicar os recursos para todas as outras regiões.

Embora teoricamente seja possível obter alguma vantagem de latência gerando recursos em cada região, os dados de eventos geralmente precisam ser unidos a dados de eventos brutos de outras regiões; do ponto de vista de correção e eficiência, é mais fácil enviar todos os eventos para uma região para processamento na maioria dos casos de uso. Por outro lado, se o uso do modelo fizer mais sentido em um contexto regional e a maioria dos eventos estiver associada a entidades específicas da região, faz sentido tratar os recursos como específicos da região. Quaisquer eventos que precisem ser replicados entre regiões podem ser colocados em keyspaces com estratégias de replicação global, mas, idealmente, isso deve ser um pequeno subconjunto de eventos. Em certo ponto, replicar tabelas de eventos globalmente será menos eficiente do que simplesmente enviar todos os eventos para uma única região para cálculos de recursos.

Planeje um suporte multinuvem econômico e de baixa latência

O suporte multinuvem aumenta a resiliência dos aplicativos e permite que os clientes negociem preços mais baixos. Lojas on-line de nuvem única, como o DynamoDB, resultam em maior latência para recuperação de recursos e custos significativos de saída de dados, mas também criam bloqueio a um único fornecedor de nuvem.

Bancos de dados de código aberto que oferecem suporte à replicação entre nuvens fornecem o melhor equilíbrio de custo de desempenho. Para minimizar o custo de saída, eventos e geração de recursos devem ser consolidados em uma nuvem, e os dados de recursos devem ser replicados para bancos de dados de código aberto nas outras nuvens. Isso minimiza os custos de saída.

Planeje o treinamento em lote e em tempo real dos modelos de produção

A infraestrutura de processamento em lote para construir modelos é usada para dois casos de uso: construir e testar novos modelos e construir modelos para produção. Portanto, normalmente era suficiente que os dados de recursos fossem armazenados em armazenamentos de objetos mais lentos para fins de treinamento. No entanto, os paradigmas de treinamento de modelos mais recentes incluem a atualização dos modelos em tempo real ou quase em tempo real (treinamento em tempo real); isso é conhecido como “aprendizagem online” (por exemplo , TikTok's Monolith ). O padrão de acesso para treinamento em tempo real fica em algum lugar entre a inferência e o treinamento em lote tradicional. Os requisitos de dados de taxa de transferência são maiores do que a inferência (porque geralmente não está acessando uma pesquisa de linha única), mas não tão altos quanto o processamento em lote que envolveria varreduras completas da tabela.

O Cassandra pode oferecer suporte a uma classificação de TPS de centenas de milhares por segundo (com um modelo de dados apropriado), que pode fornecer taxa de transferência suficiente para a maioria dos casos de uso de treinamento em tempo real. No entanto, caso o usuário queira manter o treinamento em tempo real de um armazenamento de objeto, o Cassandra consegue isso por meio do CDC para armazenamento de objeto. Para treinamento em lote, o CDC deve replicar os dados para o armazenamento de objetos. Vale a pena observar que estruturas de aprendizado de máquina como Tensorflow e PyTorch são particularmente otimizadas para treinamento paralelo de modelos de ML a partir do armazenamento de objetos.

Para uma explicação mais detalhada sobre “aprendizagem online”, consulte a explicação de Chip Huyuen sobreAprendizagem Contínua ou este artigo técnico de Gomes et. al .

Suporte para arquitetura Kappa

A arquitetura Kappa está gradualmente substituindo a arquitetura Lambda devido a custos e problemas de qualidade de dados devido à distorção online/offline. Embora muitos artigos discutam as vantagens de mudar de camadas separadas de computação em lote e em tempo real para uma única camada em tempo real, os artigos geralmente não descrevem como arquitetar a camada de serviço.

O uso da arquitetura Kappa para gerar recursos traz algumas novas considerações:

• Os recursos de atualização estão sendo atualizados em massa e podem resultar em um número significativo de gravações no banco de dados. É importante garantir que a latência da consulta não sofra durante essas grandes atualizações.
• A camada de serviço ainda precisa oferecer suporte a diferentes tipos de consultas, incluindo consultas de baixa latência para inferência e consultas de alto TPS para treinamento em lote de modelos.

O Cassandra oferece suporte à arquitetura Kappa das seguintes maneiras:

• Cassandra é projetado para gravações; um fluxo maior de gravações não reduz significativamente a latência das consultas. Cassandra opta por processar as gravações com consistência eventual em vez de consistência forte, o que normalmente é aceitável para fazer previsões.
• Usando o CDC, os dados podem ser replicados para armazenamento de objetos para treinamento e armazenamento na memória para inferência. O CDC tem pouco impacto na latência das consultas ao Cassandra.

Suporte para arquitetura Lambda

A maioria das empresas tem uma arquitetura Lambda, com um pipeline de camada de lote separado do pipeline em tempo real. Existem várias categorias de recursos neste cenário:

1. Recursos que são calculados apenas em tempo real e replicados para o armazenamento de recursos em lote para treinamento
2. Recursos que são calculados apenas em lote e são replicados para o armazenamento de recursos em tempo real
3. Os recursos são calculados em tempo real primeiro e depois recalculados no lote. As discrepâncias são atualizadas tanto no armazenamento em tempo real quanto no armazenamento de objetos.

Nesse cenário, no entanto, a DataStax recomenda a arquitetura descrita nesta ilustração:

As razões são as seguintes:

1. O Cassandra foi projetado para fazer uploads em lote de dados com pouco impacto na latência de leitura
2. Por ter um único sistema de registro, o gerenciamento de dados torna-se significativamente mais fácil do que se os dados fossem divididos entre o armazenamento de recursos e o armazenamento de objetos. Isso é especialmente importante para recursos que são calculados primeiro em tempo real e depois recalculados em lote.
3. Ao exportar dados do Cassandra via CDC para o armazenamento de recursos de objeto, a exportação de dados pode ser otimizada para treinamento em lote (um padrão comum usado em empresas como o Facebook ), o que reduz significativamente os custos de infraestrutura de treinamento.

Se não for possível atualizar os pipelines existentes ou se houver motivos específicos para que os recursos precisem estar no armazenamento de objetos primeiro, nossa recomendação é usar um caminho CDC bidirecional entre o armazenamento de recursos do Cassandra e o armazenamento de objetos, como ilustrado abaixo.

Garanta a compatibilidade com o ecossistema de software de ML existente

Para usar o Cassandra como um repositório de recursos, ele deve ser integrado a duas partes do ecossistema: bibliotecas de aprendizado de máquina que realizam inferência e treinamento e bibliotecas de processamento de dados que realizam a transformação de recursos.

As duas estruturas mais populares para aprendizado de máquina são TensorFlow e PyTorch. Cassandra tem drivers Python que permitem fácil recuperação de recursos do banco de dados Cassandra; em outras palavras, vários recursos podem ser buscados em paralelo ( consulte este código de exemplo ). As duas estruturas mais populares para realizar a transformação de recursos são Flink e Spark Structured Streaming . Conectores para Flink e Spark estão disponíveis para Cassandra. Os praticantes podem usar tutoriais para Flink e Spark Structured Streaming e Cassandra.

As lojas de recursos de código aberto, como FEAST, também têm um conector e um tutorial para Cassandra.

Entenda os padrões de consulta e a taxa de transferência para determinar os custos

O número de consultas de leitura para Cassandra como um armazenamento de recursos depende do número de solicitações de inferência recebidas. Supondo que os dados do recurso sejam divididos em várias tabelas ou se os dados puderem ser carregados em paralelo, isso deve fornecer uma estimativa do fanout entre a inferência em tempo real que pode ser feita. Por exemplo, 200 recursos em 10 entidades em 10 tabelas separadas oferecem uma proporção de 1:10 entre inferência em tempo real e consultas ao Cassandra.

O cálculo do número de inferências realizadas dependerá do padrão de tráfego de inferência. Por exemplo, no caso de “inferência de streaming”, uma inferência será realizada sempre que um recurso relevante for alterado, portanto, o número total de inferências depende da frequência com que os dados do recurso são alterados. Quando a inferência é realizada em uma configuração de “solicitação-resposta”, ela só é realizada quando um usuário a solicita.

Entenda os padrões de gravação em lote e em tempo real para determinar os custos

A taxa de transferência de gravação é dominada principalmente pela frequência com que os recursos mudam. Se ocorrer desnormalização, isso também pode afetar o número de recursos gravados. Outras considerações de taxa de transferência de gravação incluem inferências de cache para cenários de inferência em lote ou streaming.

Conclusão

Ao projetar um pipeline de ML em tempo real, é necessário prestar atenção especial ao desempenho e à escalabilidade do repositório de recursos. Os requisitos são particularmente bem atendidos por bancos de dados NoSQL, como Cassandra. Crie sua própria loja de recursos com Cassandra ou AstraDB e experimente o Feast.dev com o conector Cassandra .