Opções de infraestrutura para pipelines de dados em publicidade (parte 2)

O foco deste artigo são os pipelines de dados e as tarefas de machine learning que são comuns às diferentes plataformas de publicidade. Ele é complementar a Opções de infraestrutura para disponibilização de cargas de trabalho de publicidade (parte 1). Em ambos os artigos, você terá o contexto necessário para a série:

Este artigo faz parte da série a seguir:

Para ter uma visão geral de como essas plataformas funcionam juntas e conhecer da terminologia de tecnologia de anúncios usada em toda essa série, consulte Como criar plataformas de publicidade (visão geral).

Os armazenamentos de dados (na parte 1) usados nos pipelines de dados são o armazenamento de perfis de usuário (exclusivo), o armazenamento de contexto (na parte 1) e o armazenamento de painéis/relatórios (na parte 1). Esses armazenamentos de dados são alimentados por duas fontes principais: eventos e dados de terceiros. O foco deste artigo é o gerenciamento de eventos. Para mais informações sobre dados de terceiros e o uso deles no enriquecimento de dados de usuários, consulte enriquecimento de dados (na parte 4).

Ciclo de vida do evento

O pipeline de dados de eventos brutos para dados úteis pode ser dividido nestas partes:

  • Coleta e armazenamento (ingestão): por meio de um sistema de mensagens ou uploads recorrentes de arquivos para um sistema de armazenamento.
  • Processamento: em lotes ou no modo de streaming para processamento em tempo real, quando a atualização de dados é importante.
  • Exportar (ou carregar): diretamente da ferramenta de processamento de dados ou por meio de um fluxo de trabalho personalizado. Destinos são normalmente os locais de armazenamento mencionados acima.

Os eventos mais comuns na tecnologia de anúncios são estes:

  • Solicitações de anúncios e lances: geralmente recebidas de um sistema externo. As solicitações contêm detalhes que fazem parte da entrada para a seleção de anúncios.
  • Impressões: criativos carregados em uma página da Web, mas nem sempre visíveis.
  • Impressões faturáveis: impressões renderizadas e/ou visíveis.
  • Cliques: ações que um usuário pode realizar clicando em um criativo.
  • Conversões: ações que um usuário alvo realiza no site do anunciante.

Eventos associados a lances em tempo real são abordados em Opções de infraestrutura para bidders de RTB (parte 4)

Como realizar a coleta

Eventos podem ser criados assim:

  • Instâncias de solicitação de anúncio ou lance: as instâncias que recebem uma solicitação retornam um URL para o criativo ou uma resposta de lance.
  • Instâncias de coletor: instâncias que retornam um pixel invisível para registrar impressões e/ou coletar ações que um usuário segmentado realizou em um anúncio (ações como cliques ou reproduções de vídeo).
  • Cloud Logging: em alguns casos, a geração de registros pode substituir instâncias do coletor e arquivos de registros do servidor.

Os eventos podem ser coletados assim:

  • Um código personalizado que publica o evento em um sistema de mensagens (como o Pub/Sub) ou que grava em um arquivo de registros local.
  • Ferramentas de terceiros ou funcionalidade de registros nativa do seu servidor da Web
  • Um agente de geração de registros do Google Cloud compatível com um software de terceiros selecionado e que tenha integração com o Cloud Logging.

Os eventos podem ser ingeridos assim:

  • em tempo quase real, quando os arquivos de registro são gravados localmente e depois copiados periodicamente para um armazenamento compartilhado como o Cloud Storage ou o BigQuery Capacitor para processamento. O armazenamento do BigQuery é normalmente usado se esse processamento envolver consultas analíticas;
  • Em tempo real, ao usar o Cloud Logging ou quando os coletores gravam diretamente em um armazenamento de dados ou sistema de mensagens de baixa latência, como Pub/Sub, Apache Kafka (em inglês) ou RabbitMQ (em inglês). Sistemas de processamento em tempo real geralmente usam essa opção.

O Cloud Logging pode facilitar muitas dessas tarefas, já que consegue capturar os dados diretamente dos produtos do Google Cloud, como do Compute Engine, do Google Kubernetes Engine e até mesmo do balanceamento de carga HTTP. O Logging também pode exportar dados diretamente para o BigQuery para análises ad-hoc, transmitir para o Pub/Sub para fins de alertas e processamento em tempo real e exportar em lote para o Cloud Storage para fazer backup ou análises federadas.

Aqui estão alguns exemplos que ilustram os pontos anteriores e que consideram as operações, o custo e a atualização de dados:

Opção Custo Trabalho operacional Atualização de dados
Copiar os arquivos de registros para o Cloud Storage a cada X segundos e, em seguida, para o BigQuery usando o bq load Nenhum custo de ingresso para o Cloud Storage

Nenhum custo de processamento para o BigQuery

Custos de armazenamento do BigQuery
Requer o gerenciamento de arquivos, falhas, novas tentativas e sincronização Quase em tempo real
Copiar os arquivos de registros para o Cloud Storage a cada X segundos e, em seguida, para o BigQuery usando o Cloud Functions Nenhum custo de ingresso para o Cloud Storage

Nenhum custo de processamento para o BigQuery

Custo extra com o Cloud Functions

Custos de armazenamento do BigQuery
O Cloud Functions facilita o gerenciamento de carga. A lógica ainda precisa ser codificada. Quase em tempo real
Usar o Cloud Logging com exportação para o Pub/Sub Custos do Pub/Sub Baixo Em tempo real
Usar um daemon local para enviar registros ao Kafka Custos de armazenamento e computação necessários para executar o Kafka Configurar e gerenciar o Kafka, a menos que seja usada a opção gerenciada pelo Google Cloud (em inglês). Em tempo real ou quase, dependendo de como o Kafka está configurado

Dica: ao usar instâncias de computação para coletar os eventos, pense sempre no uso de VMs preemptivas, conforme explicado na seção Plataforma de computação, para reduzir os custos.

Como armazenar dados

O local em que você armazena seus dados é influenciado pelo formato deles, por como eles são acessados e usados e também pelo custo de armazená-los. Se o formato de dados não for estruturado ou precisar ser armazenado antes do processamento, conforme recomendado anteriormente, considere o uso do Cloud Storage. Para dados estruturados, você também precisa considerar o esforço necessário para acessar os registros. O diagrama a seguir pode ajudá-lo a avaliar o padrão de acesso para minimizar o número de operações e o custo.

Recomendações para ajudar a exportar dados

Os padrões de armazenamento de leitura pesada (na parte 1) abordam as opções usadas para armazenamento e disponibilização. O restante desta seção abrange os armazenamentos de dados analíticos usados tanto com o streaming quanto com o processamento em lote.

No streaming, você processa dados brutos antes de armazená-los. Se você também quiser disponibilizar os dados imediatamente para consultas pontuais, considere a possibilidade de fazer streaming para o BigQuery. Isso pode ser feito facilmente com este modelo do Dataflow do Pub/Sub para o BigQuery.

No processamento em lote recorrente, você consolida os dados armazenando-os em um ambiente compartilhado e escalonável. Um padrão comum é mover os arquivos de registros em intervalos de poucos minutos de seu local para o armazenamento de objetos. Os nomes de arquivos geralmente são prefixados e sufixados, por exemplo: logs_serverABC_timestamp123.txtt.

É possível executar suas cargas de trabalho de análise nos sistemas de armazenamento a seguir:

  • Cloud Storage: com as classes de armazenamento padrão Nearline e Coldline, é possível salvar os dados para acesso rápido, backup ou arquivamento. Configure o armazenamento padrão, a opção recomendada para análise, como um bucket regional sempre que for possível. Configure o armazenamento na mesma região que os recursos de computação que processam os dados. O Cloud Storage pode ser acessado por meio da maioria dos produtos do Google Cloud, como Dataproc, Dataflow, Dataprep by Trifacta e BigQuery.
  • BigQuery: o BigQuery não é apenas um poderoso mecanismo de consulta. Ele também tem o próprio armazenamento, chamado Capacitor. O Capacitor permite armazenar exabytes de dados, e o armazenamento do BigQuery pode ser acessado por meio do Dataproc, Dataflow e mecanismo de consulta do BigQuery. Com o armazenamento de longo prazo do BigQuery, os custos de armazenamento caem em aproximadamente 50% para partições que não foram editadas por 90 dias.
  • Cloud Bigtable: com bilhões de eventos coletados todos os dias, o Cloud Bigtable é uma ótima opção se você precisar de gravações e leituras pesadas em milissegundos de dígito único. É acessível por meio da API HBase e outros clientes. O Cloud Bigtable também pode ser usado com o ecossistema do Big Data para gráficos, séries temporais e análises.

Fazemos as recomendações gerais a seguir:

  • Armazene dados brutos no BigQuery em paralelo a qualquer outro processamento. É fácil fazer agrupamentos de hora em hora, diariamente, semanalmente ou mensalmente. As opções de carregamento dependem dos seus requisitos. Leia mais na documentação sobre carregamento de dados do BigQuery.
  • Se quiser evitar custos, carregue dados armazenados no Cloud Storage no BigQuery gratuitamente ou a um preço inferior ao de streaming. Basta usar o bq load, Cloud Functions, a API job ou as consultas federadas. As duas primeiras opções estão sujeitas a cotas.
  • Use os recursos de armazenamento do BigQuery, como partições e clustering, para minimizar o tempo e os custos de consulta.

Como processar eventos

Ao escolher uma tecnologia para criar seus pipelines de processamento, considere os aspectos a seguir:

  • Latência: decida quais dados precisam ser processados em tempo real. Por exemplo, você pode precisar calcular os contadores de orçamento o mais rápido possível.
  • Exatidão: alguns valores precisam ser calculados com exatidão, mas talvez não imediatamente. Por exemplo, valores de faturamento.
  • Alta disponibilidade: com bilhões de entradas de dados todos os dias, alguns minutos de inatividade podem resultar em um impacto financeiro significativo.
  • Sobrecarga operacional: "manter as luzes acesas" pode não ser o melhor uso de seus recursos técnicos.

Veja o exemplo a seguir.

  • Registros de balanceamento de carga HTTP são ingeridos em tempo real usando o Cloud Logging.
  • Alguns registros precisam ser processados imediatamente para calcular o orçamento restante.
  • As contagens de impressões são agregadas e exigidas por hora. Os limites de frequência da campanha, diariamente.

É comum que as empresas utilizem a arquitetura lambda para equilibrar os pipelines de processamento de dados:

  • Aproximações rápidas por meio de um pipeline de processamento em tempo real
  • Exatidão por meio de um pipeline extra de processamento em lote off-line

Pipeline de processamento de dados Lambda

Nesta seção, abordamos alguns produtos do Google Cloud que podem ser usados para implementar as arquiteturas de processamento de dados lambda e kappa, além do Dataflow:

  • Dataproc (lote e streaming): se você já tiver jobs e scripts do Hadoop ou do Spark, poderá migrá-los como estão para o Dataproc, Spark gerenciado pelo Google Cloud ou Hadoop.
  • Dataflow (lote e streaming): se você tiver novas cargas de trabalho, pretender usar recursos avançados de streaming ou quiser um modelo de programação unificado, o Dataflow fornece um serviço totalmente gerenciado que executa o Apache Beam (em inglês), disponibilizado em código aberto pelo Google. Ele também é compatível com muitas entradas e saídas (em inglês), como o Cloud Pub/Sub e o Kafka. O Dataflow oferece um modelo de programação unificado para dados em lote e de stream que aceitam processamento único (em inglês).
  • BigQuery (lote): ao considerar uma abordagem ELT (extrair, carregar e transformar) ou ao realizar transformações subsequentes após os dados serem carregados no armazenamento de dados, é possível usar o BigQuery para as transformações SQL. Ele é gerenciado e também fornece funções definidas pelo usuário. Use o Cloud Composer, gerenciado pelo Apache Airflow, para a orquestração dessas consultas.
  • Ferramentas de terceiros: é possível instalar e gerenciar ferramentas do ecossistema do Hadoop ou de ferramentas como o Storm no Compute Engine ou no Google Kubernetes Engine (GKE).

A arquitetura a seguir descreve uma recomendação com base nestes requisitos:

  • ingestão de eventos em tempo real
  • Computação de alguns contadores a cada segundo
  • Visualização completa da contagem de impressões a cada hora
  • Cálculo diário da taxa de cliques do anúncio

Um pipeline de processamento de dados que usa o Pub/Sub

O fluxo de processamento de dados é este:

  1. Eventos são gravados no Pub/Sub.
  2. O Dataflow grava os dados do nível do evento diretamente no BigQuery.
  3. O Dataflow também exibe os dados em intervalos de 1 segundo para executar as agregações necessárias, assim como grava os contadores em instâncias regionais do Cloud Bigtable.
  4. O BigQuery executa periodicamente uma consulta para acumular os dados e materializar os resultados. Isso pode ser programado por meio de cron jobs ou usando as opções de programação do Apache Airflow por meio do Cloud Composer.
  5. Os front-ends do usuário podem usar o BigQuery como um banco de dados OLAP. Para saber mais, consulte relatórios (na parte 1).
  6. Os servidores de anúncios regionais consultam instâncias próximas do Cloud Bigtable para recuperar rapidamente os contadores.

Siga estas recomendações gerais para criar um pipeline de processamento de dados:

  • Use o Pub/Sub para reduzir a sobrecarga operacional ou execute o Apache Kafka como um serviço gerenciado no Google Cloud.
  • Considere gravar seu pipeline com o Apache Beam para abordar lote e streaming por meio de um modelo de programação unificado.
  • Execute o Apache Beam no Dataflow para ter os benefícios de um serviço totalmente gerenciado que pode escalonar automaticamente o número de workers durante o ciclo de vida do job e reequilibrar dinamicamente o trabalho para diminuir o tempo de processamento geral do job.

Se você tiver eventos ou outros dados que queira limpar, preparar e explorar visualmente para a análise, use o Dataprep. Não é preciso escrever o código, e o Dataprep permite exportar os modelos do Dataflow, que podem ser reutilizados e programados.

Exportações

Quando os eventos forem ingeridos e processados, os resultados podem ser exportados para estes fins:

  • Armazenamentos off-line, como o BigQuery ou o Cloud Storage, para processamento off-line, incluindo agrupamentos e análises.
  • Armazenamentos de disponibilização como o Cloud Bigtable, o Datastore, o Memorystore e armazenamentos de terceiros. Os servidores front-end usam esses repositórios para, por exemplo, recuperar informações sobre perfis de usuários e fazer a atualização de contadores quando os anúncios são selecionados.
  • Sistemas de mensagens como o Pub/Sub ou o Kafka, quando os dados exigem mais processamento downstream ou estão sendo enviados como um alerta (por exemplo, ao gerenciar orçamentos).

A replicação de dados é outro caso de uso de exportação. Por exemplo, quando você precisa que os dados estejam próximos de seus servidores front-end ou até mesmo possivelmente nos servidores, há duas abordagens:

  • Em alguns casos, se sua escolha tecnológica oferecer suporte, será possível usar os recursos de replicação nativos. Algumas tecnologias, como Redis e Aerospike, são compatíveis com a replicação dentro das regiões. No entanto, a replicação entre regiões distintas pode ser mais desafiadora.
  • Outras tecnologias podem não oferecer suporte à replicação. Nesse caso, é possível implementá-la com um sistema de mensagens e processadores em execução no Compute Engine ou no Pub/Sub.

No diagrama a seguir, mostramos algumas abordagens diferentes:

Estrutura da replicação de dados com armazenamentos do Google Cloud

Os dados são processados em tempo real usando o Dataflow e off-line usando o BigQuery. Veja o que acontece depois disso:

  • O Dataflow grava dados diretamente em um cluster do Redis, usando o IO do Apache Beam Redis (em inglês), que, por sua vez, replica dados para os workers locais dele.
  • O Dataflow publica mensagens no Pub/Sub. Em seguida, as mensagens são lidas por um pool de assinantes com escalonamento automático, implantado no Compute Engine, que os grava em um cluster do Aerospike que está sendo executado no Compute Engine.
  • Os registros dos jobs off-line do BigQuery, programados por meio do Cloud Composer, são exportados para os clusters do Redis e do Aerospike.

Ao exportar dados, siga estas recomendações:

  • Certifique-se de que o armazenamento de dados escolhido possa processar seus padrões de leitura e gravação. Caso contrário, pense no desacoplamento da infraestrutura de leitura, conforme detalhado nos padrões de armazenamento de leitura pesada (na parte 1).
  • Para análise, use o BigQuery com clustering e particionamento a fim de minimizar os custos e as durações das consultas.
  • Para leituras e gravações com um dígito de milissegundos, considere a possibilidade de usar o Cloud Bigtable. Ative a replicação para alta disponibilidade.
  • Para gravações em tempo real no BigQuery, use a API Streaming padrão do IO do BigQuery do Apache Beam. Com o SDK para Java do Apache Beam, é possível gravar em microlotes por meio do Cloud Storage. Use FILE_LOADS para reduzir custos.
  • Para gravações pesadas com menos de 1 milissegundo, use um armazenamento de dados terceirizado instalado no Compute Engine ou no Pub/Sub.

Automação

Seu pipeline de dados pode ter um dos vários fluxos off-line para:

Para automação de ponta a ponta e gerenciamento de falhas, use o Cloud Composer para o Apache Airflow. O Airflow é a tecnologia de código aberto recomendada para gerenciar fluxos de trabalho no Google Cloud. Os DAGs podem ser acionados manualmente por um evento ou programados para execução recorrente.

Se você precisar de uma ação orientada por eventos mais simples, poderá acionar o Cloud Functions em novos arquivos criados no Cloud Storage ou em novos eventos publicados no Pub/Sub. O Cloud Functions é totalmente gerenciado, o que elimina a sobrecarga operacional. Para opções sem servidor mais personalizadas, considere ler sobre o Knative, um complemento promissor baseado no Kubernetes para criar, implantar e gerenciar cargas de trabalho sem servidor.

Analytics

O BigQuery é nosso armazenamento de dados recomendado para processamento analítico e consultas ad-hoc porque:

  • é totalmente gerenciado;
  • fornece uma camada de armazenamento otimizada e um mecanismo de consulta escalonável;
  • permite a realização de consultas ad-hoc em terabytes de dados usando SQL padrão, incluindo funções de janela e UDFs;
  • oferece opções de preços para o uso de consultas por meio de preços sob demanda ou de taxa fixa;
  • oferece preços de armazenamento de longo prazo com uma taxa de longo prazo;
  • fornece recursos de aprendizado de máquina com o BigQuery ML;
  • tem controle de custos e monitoramento integrado.

Dicas:

Considere usar as visualizações autorizadas do BigQuery. Uma visualização autorizada permite compartilhar os resultados da consulta sem conceder acesso às tabelas subjacentes e restringe as colunas que os usuários podem consultar.

Se você estiver interessado em migrar do Hive, considere o carregamento de arquivos do Parquet para o BigQuery.

Ainda que seja recomendável usar o BigQuery para análise e processamento off-line com base em SQL, o Google Cloud também oferece outras opções:

  • Para cargas de trabalho do Hadoop, incluindo Apache Spark, Hive e Pig, use o Dataproc. O conector do Dataproc permite que você execute jobs do Apache Spark e do Hadoop no Cloud Storage e tem diversos benefícios, incluindo alta disponibilidade de dados, interoperabilidade com outros serviços do Google Cloud e compatibilidade com HDFS.
  • É possível instalar e gerenciar ferramentas terceirizadas no Compute Engine ou no Pub/Sub. O Druid é comumente usado além do BigQuery como um banco de dados OLAP de baixa latência para usuários front-end.

Criar recursos de machine learning

O processamento de eventos não envolve somente a limpeza e a agregação. Ao adicionar recursos de machine learning ao seu pipeline de dados, você pode adicionar inteligência, como a recomendação de anúncios melhores ou a criação de segmentos de usuários virtuais que podem ser usados como recursos do modelo. O Google Cloud oferece uma gama completa de elementos básicos de IA para machine learning, incluindo:

Com bilhões de eventos diários sendo coletados e armazenados em seu data lake ou armazenamento de dados, seja o Cloud Storage ou o BigQuery, é possível usar esses dados para treinar modelos poderosos relacionados a lances, por exemplo:

  • Decidir se quer dar um lance ou não.
  • Estimar o CTR.
  • Otimizar o preço do lance.
  • Segmentar clientes.
  • Calcular os valores da vida útil do cliente (LTVs).
  • Recomendar um anúncio para selecionar.

Ao escolher sua plataforma de machine learning, é necessário responder a algumas perguntas:

  • Quão bem conheço meus dados?
  • Quantos dados eu tenho?
  • Quantos dados serão usados para treinamento?
  • O treinamento vai ser on-line ou off-line?
  • As predições vão ser feitas on-line ou off-line?
  • A disponibilização pode acontecer independentemente da predição?

No diagrama a seguir, mostramos um fluxo de machine learning comum, com as etapas a seguir:

  1. Limpe/prepare os conjuntos de dados com o BigQuery.
  2. Exporte os conjuntos de dados de treinamento e avaliação para o Cloud Storage.
  3. Treine o modelo usando o AI Platform
  4. Exporte o modelo para o Cloud Storage.
  5. Quando um worker for inicializado, importe o modelo do Cloud Storage.
  6. Use o modelo do TensorFlow no local para executar previsões em baixa latência.

Um fluxo comum de machine learning

Como preparar dados e engenharia de atributos

Antes que os dados estejam prontos para serem alimentados em um modelo de machine learning, execute as tarefas a seguir:

  1. Explore o conjunto de dados para entender a adequação dos dados para a tarefa em questão.
  2. Limpe e prepare o conjunto de dados unindo dados de várias tabelas e filtrando registros não aplicáveis.
  3. Extraia, construa e selecione atributos, criando propriedades informativas e discriminativas daquilo que está sendo observado.

O BigQuery é adequado para essas tarefas com dados armazenados nele e para fontes externas de dados federados. É possível usar o BigQuery para consultar e explorar os dados antes de exportar seus conjuntos de dados selecionados e filtrados para o Cloud Storage para engenharia de atributos.

Dica: além de usar o BigQuery para a exploração de dados, é possível conectar o Dataprep ao BigQuery para fazer amostragem e análise visual dos dados.

A próxima tarefa normalmente exige que você considere se as predições serão feitas on-line ou off-line. Ao fazer predições on-line, é importante considerar como os atributos serão extraídos dos dados de solicitação da predição:

  • Para predições on-line, você precisa executar as mesmas etapas de criação de atributos durante o treinamento e a predição para evitar desvios. tf.Transform permite que você defina essas etapas de pré-processamento, aproveite o Apache Beam para realizar esse trabalho em escala durante o treinamento e a avaliação, além de exportar as etapas como parte de um gráfico do TensorFlow para disponibilizar as predições. Este blog fornece ótimas informações sobre como esse processo funciona.
  • Para predições off-line, é possível usar a mesma abordagem durante as fases de treinamento e predição. Use o BigQuery para criar os recursos como parte do pré-processamento de lotes. Por exemplo, é possível vetorizar recursos usando uma função hash ou procurar um valor associativo por meio de uma união.

Treinamento e avaliação

O Google Cloud oferece várias opções para treinamento e avaliação de modelos, como:

  • Uso do AI Platform para executar as tarefas de treinamento e avaliação do XGboost, Scikit-Learn e TensorFlow em um ambiente totalmente gerenciado. O AI Platform também fornece recursos extras, como ajuste automatizado de hiperparâmetros e treinamento distribuído.

  • Execução das tarefas de treinamento e avaliação nas instâncias do Compute Engine diretamente. Você terá que instalar os pacotes de software desejados. Também é possível aproveitar as vantagens de GPUs, TPUs ou VMs preemptivas, quando for apropriado, para reduzir custos e tempo de processamento.

  • Uso do Kubeflow para instalar e executar o Tensorflow e muitas ferramentas de machine learning, como o Notebook, em um ambiente de contêiner no Kubernetes.

  • Uso do BigQuery ML diretamente da interface do SQL para treinar off-line em dados estruturados.

A escolha de sua plataforma ML depende dos requisitos:

  • Para minimizar os custos, use o Compute Engine com VMs preemptivas.
  • Se você precisar de um ambiente totalmente gerenciado para treinamento, implantação e disponibilização, use o AI Platform.
  • Para criar ambientes ML extensíveis e reproduzíveis, que podem ser executados em qualquer cluster do Kubernetes, use o Kubeflow.
  • Use o BigQuery ML quando você tiver dados estruturados, para fazer predições off-line e quando quiser implementar uma regressão linear ou logística.

Como fazer a predição

A predição é feita off-line ou on-line, com os mesmos produtos mencionados na seção de treinamento. Para fazer predições, o TensorFlow Serving pode ser usado pelo Compute Engine, Kubeflow e AI Platform. As diferenças entre essas opções são a sobrecarga operacional, as opções de ajuste e o preço.

Se a baixa latência for um requisito crítico, você também pode usar o modelo serializado ou compilado diretamente, o que também pode ser útil em pipelines de dados. Consulte a seção A seguir para links adicionais.

Disponibilização

A predição e disponibilização às vezes são consideradas a mesma tarefa, o que é verdade para predições on-line. No entanto, se você tornar as predições off-line e, em seguida, persistir os resultados em um armazenamento de dados, precisará disponibilizar as predições desse armazenamento à medida que elas forem solicitadas.

Disponibilizar predições rápidas é uma troca entre eficácia e eficiência. É possível usar abordagens diferentes ou uma combinação de algumas delas. Se decidir usar o TensorFlow Serving para fazer predições em tempo real, use aceleradores, como GPUs ou TPUs e um dos métodos a seguir para otimizar seu modelo para disponibilização:

Se você decidir usar predições criadas previamente de um armazenamento de chave-valor rápido, precisará criar chaves com base nas permutações de atributos. Suponha que você queira prever se é boa ideia dar um lance ou não com base no continente e no tipo de dispositivo:

  1. Crie todas as combinações possíveis de nomes de continente e dispositivo móvel/Web.
  2. Armazene o resultado das predições para essas combinações.

    Chave Previsão
    antarctica_mobile 0
    antarctica_web 1
    asia_mobile 1
    asia_web 0
    europe_mobile 1
    europe_web 0
    northamerica_mobile 1
    northamerica_web 1
    southamerica_mobile 1
    southamerica_web 0
    oceania_mobile 1
    oceania_web 0

    Você pode fazer uma busca rápida na chave correta quando receber uma solicitação. O Redis, o Aerospike e o Cloud Bigtable são bons candidatos para esse caso de uso.

Antes de implementar, tenha isto em mente:

  • Se você tiver muitos atributos, o tamanho da combinação poderá ser maior que o tamanho máximo permitido para uma chave.
  • Para aceitar um grande número de solicitações e um grande número de chaves, considere a distribuição de chaves e faça o hash (de parte) da chave, se necessário, para evitar pontos de acesso em linhas específicas. O Cloud Bigtable tem uma ferramenta visualizadora de chave para ajudar a diagnosticar esses problemas.
  • Se você não tiver dados categóricos para um valor contínuo desse tipo, será necessário colocá-los em intervalos. Determinar o tamanho do bucket para cada atributo é uma tarefa em si.
  • Use os embeddings para calcular a distância entre as chaves. Se a chave não existir, será possível encontrar o vizinho mais próximo. Há diferentes técnicas para criar hash sensível à localização. A computação desses hashes é uma tarefa de machine learning.

A seguir