Pré-processamento de dados para ML: opções e recomendações

Este documento é o primeiro de uma série de duas partes que explora o tópico de engenharia de dados e engenharia de recursos para aprendizado de máquina (ML), com foco em tarefas de aprendizado supervisionado. Esta primeira parte discute as práticas recomendadas para pré-processamento de dados em um pipeline de ML no Google Cloud. O documento se concentra no uso do TensorFlow e da biblioteca de código aberto TensorFlow Transform ( tf.Transform ) para preparar dados, treinar o modelo e servir o modelo para previsão. Este documento destaca os desafios do pré-processamento de dados para ML e descreve as opções e cenários para realizar a transformação de dados no Google Cloud de maneira eficaz.

Este documento pressupõe que você esteja familiarizado com BigQuery , Dataflow , Vertex AI e a API TensorFlow Keras .

O segundo documento, Pré-processamento de dados para ML com Google Cloud , fornece um tutorial passo a passo sobre como implementar um pipeline tf.Transform .

Introdução

O ML ajuda você a encontrar automaticamente padrões complexos e potencialmente úteis nos dados. Esses padrões são condensados ​​em um modelo de ML que pode então ser usado em novos pontos de dados – um processo chamado de fazer previsões ou realizar inferências .

Construir um modelo de ML é um processo de várias etapas. Cada etapa apresenta seus próprios desafios técnicos e conceituais. Esta série de duas partes concentra-se em tarefas de aprendizagem supervisionada e no processo de seleção, transformação e aumento dos dados de origem para criar sinais preditivos poderosos para a variável de destino. Essas operações combinam conhecimento do domínio com técnicas de ciência de dados. As operações são a essência da engenharia de recursos .

O tamanho dos conjuntos de dados de treinamento para modelos de ML do mundo real pode facilmente ser igual ou superior a um terabyte (TB). Portanto, são necessárias estruturas de processamento de dados em grande escala para processar esses conjuntos de dados de forma eficiente e distribuída. Ao usar um modelo de ML para fazer previsões, você deve aplicar as mesmas transformações usadas para os dados de treinamento nos novos pontos de dados. Ao aplicar as mesmas transformações, você apresenta o conjunto de dados dinâmico ao modelo de ML da maneira que o modelo espera.

Este documento discute esses desafios para diferentes níveis de granularidade das operações de engenharia de recursos: agregações em nível de instância, passagem completa e janela de tempo. Este documento também descreve as opções e cenários para realizar a transformação de dados para ML no Google Cloud.

Este documento também fornece uma visão geral do TensorFlow Transform ( tf.Transform ), uma biblioteca do TensorFlow que permite definir a transformação de dados em nível de instância e de passagem completa por meio de pipelines de pré-processamento de dados. Esses pipelines são executados com Apache Beam e criam artefatos que permitem aplicar as mesmas transformações durante a previsão como quando o modelo é servido.

Pré-processamento de dados para ML

Esta seção apresenta operações de pré-processamento de dados e estágios de preparação de dados. Também discute os tipos de operações de pré-processamento e sua granularidade.

Engenharia de dados comparada à engenharia de recursos

O pré-processamento dos dados para ML envolve engenharia de dados e engenharia de recursos. Engenharia de dados é o processo de conversão de dados brutos em dados preparados . A engenharia de recursos então ajusta os dados preparados para criar os recursos esperados pelo modelo de ML. Esses termos têm os seguintes significados:

Dados brutos (ou apenas dados )

Os dados na sua forma original, sem qualquer preparação prévia para ML. Neste contexto, os dados podem estar na sua forma bruta (num data lake) ou numa forma transformada (num data warehouse). Os dados transformados que estão em um data warehouse podem ter sido convertidos de sua forma bruta original para serem usados ​​em análises. No entanto, neste contexto, dados brutos significam que os dados não foram preparados especificamente para a sua tarefa de ML. Os dados também são considerados dados brutos se forem enviados de sistemas de streaming que eventualmente chamam modelos de ML para previsões.

Dados preparados

O conjunto de dados no formato pronto para sua tarefa de ML: as fontes de dados foram analisadas, unidas e colocadas em um formato tabular. Os dados preparados são agregados e resumidos com a granularidade correta – por exemplo, cada linha no conjunto de dados representa um cliente único e cada coluna representa informações resumidas do cliente, como o total gasto nas últimas seis semanas. Em uma tabela de dados preparada, colunas irrelevantes foram eliminadas e registros inválidos foram filtrados. Para tarefas de aprendizagem supervisionada, o recurso alvo está presente.

Recursos projetados

O conjunto de dados com os recursos ajustados esperados pelo modelo, ou seja, recursos criados pela execução de determinadas operações específicas de ML nas colunas do conjunto de dados preparado e pela criação de novos recursos para seu modelo durante o treinamento e a previsão, conforme descrito posteriormente. em Operações de pré-processamento . Exemplos dessas operações incluem dimensionamento de colunas numéricas para um valor entre 0 e 1, valores de recorte e recursos categóricos de codificação one-hot .

O diagrama a seguir, figura 1, mostra as etapas envolvidas na preparação de dados pré-processados:

Na prática, os dados da mesma fonte estão frequentemente em diferentes estágios de preparação. Por exemplo, um campo de uma tabela no seu data warehouse pode ser usado diretamente como um recurso de engenharia. Ao mesmo tempo, outro campo na mesma tabela pode precisar passar por transformações antes de se tornar um recurso de engenharia. Da mesma forma, as operações de engenharia de dados e engenharia de recursos podem ser combinadas na mesma etapa de pré-processamento de dados.

Operações de pré-processamento

O pré-processamento de dados inclui várias operações. Cada operação é projetada para ajudar o ML a construir modelos preditivos melhores. Os detalhes destas operações de pré-processamento estão fora do escopo deste documento, mas algumas operações são brevemente descritas nesta seção.

Para dados estruturados, as operações de pré-processamento de dados incluem o seguinte:

• Limpeza de dados: remoção ou correção de registros que possuem valores corrompidos ou inválidos de dados brutos e remoção de registros que estão faltando um grande número de colunas.
• Seleção e particionamento de instâncias: seleção de pontos de dados do conjunto de dados de entrada para criar conjuntos de treinamento, avaliação (validação) e teste . Este processo inclui técnicas para amostragem aleatória repetível, sobreamostragem de classes minoritárias e particionamento estratificado.
• Ajuste de recursos: melhorar a qualidade de um recurso para ML, que inclui dimensionamento e normalização de valores numéricos, imputação de valores ausentes, recorte de valores discrepantes e ajuste de valores com distribuições distorcidas.
• Transformação de recursos: conversão de um recurso numérico em um recurso categórico (por meio de bucketização ) e conversão de recursos categóricos em uma representação numérica (por meio de codificação one-hot, aprendizado com contagens , incorporação de recursos esparsos, etc.). Alguns modelos funcionam apenas com recursos numéricos ou categóricos, enquanto outros podem lidar com recursos de tipos mistos. Mesmo quando os modelos lidam com ambos os tipos, eles podem se beneficiar de diferentes representações (numéricas e categóricas) do mesmo recurso.
• Extração de recursos: reduzindo o número de recursos criando representações de dados mais poderosas e de menor dimensão usando técnicas como PCA , extração de incorporação e hashing .
• Seleção de recursos: selecionar um subconjunto de recursos de entrada para treinar o modelo e ignorar os irrelevantes ou redundantes, usando métodos de filtro ou wrapper . A seleção de recursos também pode envolver a simples eliminação de recursos se os recursos estiverem faltando um grande número de valores.
• Construção de recursos: criação de novos recursos usando técnicas típicas, como expansão polinomial (usando funções matemáticas univariadas) ou cruzamento de recursos (para capturar interações de recursos). Os recursos também podem ser construídos usando a lógica de negócios do domínio do caso de uso de ML.

Quando você trabalha com dados não estruturados (por exemplo, imagens, áudio ou documentos de texto), o aprendizado profundo substitui a engenharia de recursos baseada em conhecimento de domínio, integrando-os à arquitetura do modelo. Uma camada convolucional é um pré-processador automático de recursos. Construir a arquitetura do modelo correto requer algum conhecimento empírico dos dados. Além disso, é necessária alguma quantidade de pré-processamento, como o seguinte:

• Para documentos de texto: lematização e lematização , cálculo TF-IDF e extração de n-gramas , pesquisa de incorporação.
• Para imagens: recorte, redimensionamento, corte, desfoque gaussiano e filtros canário.
• Para todos os tipos de dados (incluindo texto e imagens): transferência de aprendizagem , que trata todas as últimas camadas do modelo totalmente treinado como uma etapa de engenharia de recursos.

Granularidade de pré-processamento

Esta seção discute a granularidade dos tipos de transformações de dados. Ele mostra por que essa perspectiva é crítica ao preparar novos pontos de dados para previsões usando transformações aplicadas em dados de treinamento.

As operações de pré-processamento e transformação podem ser categorizadas da seguinte forma, com base na granularidade da operação:

• Transformações em nível de instância durante treinamento e previsão . Estas são transformações simples, onde apenas valores da mesma instância são necessários para a transformação. Por exemplo, as transformações em nível de instância podem incluir o recorte do valor de um recurso para algum limite, a expansão polinomial de outro recurso, a multiplicação de dois recursos ou a comparação de dois recursos para criar um sinalizador booleano.

  Essas transformações devem ser aplicadas de forma idêntica durante o treinamento e a previsão, porque o modelo será treinado nos recursos transformados, não nos valores brutos de entrada. Se os dados não forem transformados de forma idêntica, o modelo se comportará mal porque serão apresentados dados que possuem uma distribuição de valores com os quais não foi treinado. Para obter mais informações, consulte a discussão sobre distorção de serviço de treinamento na seção Desafios de pré-processamento .

• Transformações de passagem completa durante o treinamento, mas transformações em nível de instância durante a previsão . Neste cenário, as transformações têm estado, porque utilizam algumas estatísticas pré-computadas para realizar a transformação. Durante o treinamento, você analisa todo o corpo de dados de treinamento para calcular quantidades como mínimo, máximo, média e variância para transformar dados de treinamento, dados de avaliação e novos dados no momento da previsão.

  Por exemplo, para normalizar um recurso numérico para treinamento, você calcula sua média (μ) e seu desvio padrão (σ) em todos os dados de treinamento. Este cálculo é chamado de operação de passagem completa (ou análise ). Quando você fornece o modelo para previsão, o valor de um novo ponto de dados é normalizado para evitar distorções no fornecimento de treinamento. Portanto, os valores μ e σ calculados durante o treinamento são usados ​​para ajustar o valor do recurso, que é a seguinte operação simples em nível de instância :

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  As transformações de passagem completa incluem o seguinte:

  • Recursos numéricos de escalonamento MinMax usando mínimo e máximo calculados a partir do conjunto de dados de treinamento.
  • Recursos numéricos de escalonamento padrão (normalização de pontuação z) usando μ e σ calculados no conjunto de dados de treinamento.
  • Bucketização de recursos numéricos usando quantis.
  • Imputação de valores faltantes usando a mediana (características numéricas) ou a moda (características categóricas).
  • Converter strings (valores nominais) em inteiros (índices) extraindo todos os valores distintos (vocabulário) de um recurso categórico de entrada.
  • Contagem da ocorrência de um termo (valor do recurso) em todos os documentos (instâncias) para cálculo do TF-IDF.
  • Calculando o PCA dos recursos de entrada para projetar os dados em um espaço dimensional inferior (com recursos linearmente dependentes).

  Você deve usar apenas os dados de treinamento para calcular estatísticas como μ, σ, min e max . Se você adicionar os dados de teste e avaliação para essas operações, estará vazando informações dos dados de avaliação e teste para treinar o modelo. Isso afeta a confiabilidade dos resultados do teste e da avaliação. Para garantir que você aplique uma transformação consistente a todos os conjuntos de dados, use as mesmas estatísticas calculadas a partir dos dados de treinamento para transformar os dados de teste e avaliação.

• Agregações históricas durante treinamento e previsão . Isso envolve a criação de agregações, derivações e sinalizadores de negócios como sinais de entrada para a tarefa de previsão – por exemplo, criação de métricas de atualidade, frequência e monetárias (RFM) para que os clientes construam modelos de propensão. Esses tipos de recursos podem ser pré-computados e armazenados em um armazenamento de recursos para serem usados ​​durante o treinamento do modelo, pontuação em lote e serviço de previsão on-line. Você também pode realizar engenharia de recursos adicionais (por exemplo, transformação e ajuste) nessas agregações antes do treinamento e da previsão.

• Agregações históricas durante o treinamento, mas agregações em tempo real durante a previsão . Essa abordagem envolve a criação de um recurso resumindo valores em tempo real ao longo do tempo. Nesta abordagem, as instâncias a serem agregadas são definidas através de cláusulas de janela temporal. Por exemplo, você pode usar essa abordagem se quiser treinar um modelo que estime o tempo de viagem de táxi com base nas métricas de tráfego da rota nos últimos 5 minutos, nos últimos 10 minutos, nos últimos 30 minutos e em outras ocasiões. intervalos. Você também pode usar essa abordagem para prever a falha de uma peça do motor com base na média móvel dos valores de temperatura e vibração calculados nos últimos 3 minutos. Embora essas agregações possam ser preparadas off-line para treinamento, elas são computadas em tempo real a partir de um fluxo de dados durante o serviço.

  Mais precisamente, quando você prepara dados de treinamento, se o valor agregado não estiver nos dados brutos, o valor será criado durante a fase de engenharia de dados. Os dados brutos geralmente são armazenados em um banco de dados com formato (entity, timestamp, value) . Nos exemplos anteriores, entity é o identificador do segmento de rota para as rotas de táxi e o identificador da peça do motor para a falha do motor. Você pode usar operações de janelamento para calcular (entity, time_index, aggregated_value_over_time_window) e usar os recursos de agregação como entrada para o treinamento do seu modelo.

  Quando o modelo para previsão em tempo real (online) é servido, o modelo espera recursos derivados dos valores agregados como entrada. Portanto, você pode usar uma tecnologia de processamento de fluxo como o Apache Beam para calcular as agregações dos pontos de dados em tempo real transmitidos para o seu sistema. A tecnologia de processamento de fluxo agrega dados em tempo real com base em janelas de tempo à medida que novos pontos de dados chegam. Você também pode realizar engenharia de recursos adicionais (por exemplo, transformação e ajuste) nessas agregações antes do treinamento e da previsão.

Pipeline de ML no Google Cloud

Esta seção discute os principais componentes de um pipeline típico de ponta a ponta para treinar e servir modelos do TensorFlow ML no Google Cloud usando serviços gerenciados. Ele também discute onde você pode implementar diferentes categorias de operações de pré-processamento de dados e desafios comuns que você pode enfrentar ao implementar tais transformações. A seção Como funciona o tf.Transform mostra como a biblioteca TensorFlow Transform ajuda a enfrentar esses desafios.

Arquitetura de alto nível

O diagrama a seguir, figura 2, mostra uma arquitetura de alto nível de um pipeline de ML típico para treinar e servir modelos do TensorFlow. Os rótulos A, B e C no diagrama referem-se aos diferentes locais do pipeline onde o pré-processamento de dados pode ocorrer. Detalhes sobre essas etapas são fornecidos na seção a seguir.

O pipeline consiste nas seguintes etapas:

1. Depois que os dados brutos são importados, os dados tabulares são armazenados no BigQuery, e outros dados, como imagens, áudio e vídeo, são armazenados no Cloud Storage. A segunda parte desta série usa dados tabulares armazenados no BigQuery como exemplo.
2. A engenharia de dados (preparação) e a engenharia de recursos são executadas em escala usando o Dataflow. Essa execução produz conjuntos de treinamento, avaliação e teste prontos para ML que são armazenados no Cloud Storage. Idealmente, esses conjuntos de dados são armazenados como arquivos TFRecord , que é o formato otimizado para cálculos do TensorFlow.
3. Um pacote de treinamento de modelo do TensorFlow é enviado ao Vertex AI Training, que usa os dados pré-processados ​​das etapas anteriores para treinar o modelo. A saída desta etapa é um SavedModel treinado do TensorFlow que é exportado para o Cloud Storage.
4. O modelo treinado do TensorFlow é implantado no Vertex AI Prediction como um serviço que tem uma API REST para que possa ser usado para previsões on-line. O mesmo modelo também pode ser usado para trabalhos de previsão em lote.
5. Depois que o modelo for implantado como uma API REST, os aplicativos cliente e os sistemas internos poderão invocar a API enviando solicitações com alguns pontos de dados e recebendo respostas do modelo com previsões.
6. Para orquestrar e automatizar esse pipeline, você pode usar o Vertex AI Pipelines como um agendador para invocar as etapas de preparação de dados, treinamento de modelo e implantação de modelo.

Você também pode usar o Vertex AI Feature Store para armazenar recursos de entrada para fazer previsões. Por exemplo, você pode criar periodicamente recursos de engenharia a partir dos dados brutos mais recentes e armazená-los no Vertex AI Feature Store. Os aplicativos cliente buscam os recursos de entrada necessários no Vertex AI Feature Store e os enviam ao modelo para receber previsões.

Onde fazer o pré-processamento

Na figura 2, os rótulos A, B e C mostram que as operações de pré-processamento de dados podem ocorrer no BigQuery, Dataflow ou TensorFlow. As seções a seguir descrevem como cada uma dessas opções funciona.

Opção A: BigQuery

Normalmente, a lógica é implementada no BigQuery para as seguintes operações:

• Amostragem: seleção aleatória de um subconjunto dos dados.
• Filtragem: remoção de instâncias irrelevantes ou inválidas.
• Particionamento: divisão dos dados para produzir conjuntos de treinamento, avaliação e teste.

Os scripts SQL do BigQuery podem ser usados ​​como uma consulta de origem para o pipeline de pré-processamento do Dataflow, que é a etapa de processamento de dados na figura 2. Por exemplo, se um sistema for usado no Canadá e o data warehouse tiver transações de todo o mundo, filtrando para obter dados de treinamento somente no Canadá é melhor feito no BigQuery. A engenharia de recursos no BigQuery é simples e escalonável e oferece suporte à implementação de transformações de recursos de agregações históricas e em nível de instância.

No entanto, recomendamos que você use o BigQuery para engenharia de recursos somente se usar seu modelo para previsão em lote (pontuação) ou se os recursos forem pré-calculados no BigQuery, mas armazenados no Vertex AI Feature Store para serem usados ​​durante a previsão on-line. Se você planeja implantar o modelo para previsões on-line e não tiver o recurso projetado em um repositório de recursos on-line, será necessário replicar as operações de pré-processamento SQL para transformar os pontos de dados brutos gerados por outros sistemas. Em outras palavras, você precisa implementar a lógica duas vezes: uma vez no SQL para pré-processar os dados de treinamento no BigQuery e uma segunda vez na lógica do aplicativo que consome o modelo para pré-processar pontos de dados on-line para previsão.

Por exemplo, se seu aplicativo cliente for escrito em Java, você precisará reimplementar a lógica em Java. Isso pode introduzir erros devido a discrepâncias de implementação, conforme descrito na seção de distorção de serviço de treinamento em Desafios de pré-processamento, posteriormente neste documento. Também é uma sobrecarga extra manter duas implementações diferentes. Sempre que você alterar a lógica no SQL para pré-processar os dados de treinamento, será necessário alterar a implementação Java de acordo para pré-processar os dados no momento da veiculação.

Se você estiver usando seu modelo apenas para previsão em lote (por exemplo, usando a previsão em lote do Vertex AI) e se os dados para pontuação forem provenientes do BigQuery, você poderá implementar essas operações de pré-processamento como parte do script SQL do BigQuery. Nesse caso, você pode usar o mesmo script SQL de pré-processamento para preparar dados de treinamento e pontuação.

As transformações com estado de passagem completa não são adequadas para implementação no BigQuery. Se você usar o BigQuery para transformações de passagem completa, precisará de tabelas auxiliares para armazenar quantidades necessárias para transformações com estado, como médias e variações para dimensionar recursos numéricos. Além disso, a implementação de transformações de passagem completa usando SQL no BigQuery cria maior complexidade nos scripts SQL e cria uma dependência complexa entre o treinamento e os scripts SQL de pontuação.

Opção B: fluxo de dados

Conforme mostrado na Figura 2, você pode implementar operações de pré-processamento computacionalmente caras no Apache Beam e executá-las em escala usando o Dataflow. O Dataflow é um serviço de escalonamento automático totalmente gerenciado para processamento de dados em lote e stream. Ao usar o Dataflow, você também pode usar bibliotecas externas especializadas para processamento de dados, diferentemente do BigQuery.

O Dataflow pode realizar transformações em nível de instância e transformações de recursos de agregação histórica e em tempo real. Em particular, se seus modelos de ML esperam um recurso de entrada como total_number_of_clicks_last_90sec , as funções de janelas do Apache Beam podem calcular esses recursos com base na agregação de valores de janelas de tempo de dados de eventos em tempo real (streaming) (por exemplo, eventos de clique). Na discussão anterior sobre granularidade de transformações , isso foi referido como "agregações históricas durante o treinamento, mas agregações em tempo real durante a previsão".

O diagrama a seguir, figura 3, mostra a função do Dataflow no processamento de dados de stream para previsões quase em tempo real.

Conforme mostrado na figura 3, durante o processamento, eventos chamados pontos de dados são ingeridos no Pub/Sub . O Dataflow consome esses pontos de dados, calcula recursos com base em agregações ao longo do tempo e, em seguida, chama a API do modelo de ML implantado para fazer previsões. As previsões são então enviadas para uma fila de saída do Pub/Sub. No Pub/Sub, as previsões podem ser consumidas por sistemas downstream, como monitoramento ou controle, ou podem ser enviadas de volta (por exemplo, como notificações) ao cliente solicitante original. As previsões também podem ser armazenadas em um armazenamento de dados de baixa latência, como o Cloud Bigtable, para busca em tempo real. O Cloud Bigtable também pode ser usado para acumular e armazenar essas agregações em tempo real para que possam ser consultadas quando necessário para previsão.

A mesma implementação do Apache Beam pode ser usada para processar em lote dados de treinamento provenientes de um armazenamento de dados off-line, como o BigQuery, e processar dados em tempo real para fornecer previsões on-line.

Em outras arquiteturas típicas, como a mostrada na Figura 2, o aplicativo cliente chama diretamente a API do modelo implantado para previsões on-line. Nesse caso, se as operações de pré-processamento forem implementadas no Dataflow para preparar os dados de treinamento, as operações não serão aplicadas aos dados de previsão que vão diretamente para o modelo. Portanto, transformações como essas devem ser integradas ao modelo durante a veiculação de previsões online.

O Dataflow pode ser usado para realizar a transformação de passagem completa, calculando as estatísticas necessárias em escala. No entanto, essas estatísticas precisam ser armazenadas em algum lugar para serem usadas durante a previsão para transformar os pontos de dados de previsão. Usando a biblioteca TensorFlow Transform ( tf.Transform ), você pode incorporar diretamente essas estatísticas no modelo em vez de armazená-las em outro lugar. Essa abordagem é explicada posteriormente em Como funciona o tf.Transform .

Opção C: TensorFlow

Conforme mostrado na Figura 2, você pode implementar operações de pré-processamento e transformação de dados no próprio modelo do TensorFlow. Conforme mostrado na figura, o pré-processamento implementado para treinar o modelo do TensorFlow torna-se parte integrante do modelo quando o modelo é exportado e implantado para previsões. As transformações no modelo do TensorFlow podem ser realizadas de uma das seguintes maneiras:

• Implementar toda a lógica de transformação em nível de instância na função input_fn e na função serving_fn . A função input_fn prepara um conjunto de dados usando a API tf.data.Dataset para treinar um modelo. A função serving_fn recebe e prepara os dados para previsões.
• Colocar o código de transformação diretamente em seu modelo do TensorFlow usando camadas de pré-processamento Keras ou criando camadas personalizadas .

O código lógico de transformação na função serving_fn define a interface de serviço do seu SavedModel para previsão online. Se você implementar as mesmas transformações que foram usadas para preparar dados de treinamento no código lógico de transformação da função serving_fn , isso garantirá que as mesmas transformações sejam aplicadas a novos pontos de dados de previsão quando eles forem servidos.

No entanto, como o modelo do TensorFlow processa cada ponto de dados de forma independente ou em um lote pequeno, não é possível calcular agregações de todos os pontos de dados. Como resultado, as transformações de passagem completa não podem ser implementadas no seu modelo do TensorFlow.

Desafios de pré-processamento

A seguir estão os principais desafios da implementação do pré-processamento de dados:

• Desvio de serviço de treinamento . A distorção entre treinamento e serviço refere-se a uma diferença entre eficácia (desempenho preditivo) durante o treinamento e durante o serviço. Essa distorção pode ser causada por uma discrepância entre como você lida com os dados no treinamento e nos pipelines de serviço. Por exemplo, se o seu modelo for treinado em um recurso transformado logaritmicamente, mas for apresentado com o recurso bruto durante a veiculação, a saída da previsão poderá não ser precisa.

  Se as transformações se tornarem parte do próprio modelo, poderá ser simples lidar com as transformações no nível da instância, conforme descrito anteriormente na Opção C: TensorFlow . Nesse caso, a interface de serviço do modelo (a função serving_fn ) espera dados brutos, enquanto o modelo transforma internamente esses dados antes de calcular a saída. As transformações são as mesmas que foram aplicadas nos pontos de dados brutos de treinamento e previsão.

• Transformações de passagem completa . Não é possível implementar transformações de passagem completa, como transformações de dimensionamento e normalização, no modelo do TensorFlow. Nas transformações de passagem completa, algumas estatísticas (por exemplo, valores max e min para dimensionar recursos numéricos) devem ser calculadas previamente nos dados de treinamento, conforme descrito na Opção B: Fluxo de dados . Os valores então devem ser armazenados em algum lugar para serem usados ​​durante o serviço do modelo para previsão para transformar os novos pontos de dados brutos como transformações em nível de instância, o que evita distorções no serviço de treinamento. Você pode usar a biblioteca TensorFlow Transform ( tf.Transform ) para incorporar diretamente as estatísticas em seu modelo do TensorFlow. Essa abordagem é explicada posteriormente em Como funciona o tf.Transform .

• Preparar os dados antecipadamente para melhorar a eficiência do treinamento . A implementação de transformações no nível da instância como parte do modelo pode degradar a eficiência do processo de treinamento. Essa degradação ocorre porque as mesmas transformações são aplicadas repetidamente aos mesmos dados de treinamento em cada época. Imagine que você tem dados de treinamento brutos com 1.000 recursos e aplica uma combinação de transformações em nível de instância para gerar 10.000 recursos. Se você implementar essas transformações como parte de seu modelo e, em seguida, alimentar o modelo com os dados brutos de treinamento, essas 10.000 operações serão aplicadas N vezes em cada instância, onde N é o número de épocas. Além disso, se você estiver usando aceleradores (GPUs ou TPUs), eles ficarão ociosos enquanto a CPU executa essas transformações, o que não é um uso eficiente de seus aceleradores caros.

  Idealmente, os dados de treinamento são transformados antes do treinamento, usando a técnica descrita na Opção B: Dataflow , onde as 10.000 operações de transformação são aplicadas apenas uma vez em cada instância de treinamento. Os dados de treinamento transformados são então apresentados ao modelo. Nenhuma outra transformação é aplicada e os aceleradores ficam ocupados o tempo todo. Além disso, usar o Dataflow ajuda a pré-processar grandes quantidades de dados em escala, usando um serviço totalmente gerenciado.

  Preparar os dados de treinamento antecipadamente pode melhorar a eficiência do treinamento. No entanto, implementar a lógica de transformação fora do modelo (as abordagens descritas na Opção A: BigQuery ou Opção B: Dataflow ) não resolve o problema da distorção do fornecimento de treinamento. A menos que você armazene o recurso projetado no armazenamento de recursos para ser usado tanto para treinamento quanto para previsão, a lógica de transformação deverá ser implementada em algum lugar para ser aplicada em novos pontos de dados que chegam para previsão, porque a interface do modelo espera dados transformados. A biblioteca TensorFlow Transform ( tf.Transform ) pode ajudá-lo a resolver esse problema, conforme descrito na seção a seguir.

Como funciona o tf.Transform

A biblioteca tf.Transform é útil para transformações que exigem uma passagem completa. A saída da biblioteca tf.Transform é exportada como um gráfico do TensorFlow que representa a lógica de transformação no nível da instância e as estatísticas calculadas a partir de transformações de passagem completa, para serem usadas para treinamento e veiculação. Usar o mesmo gráfico para treinamento e saque pode evitar distorções, porque as mesmas transformações são aplicadas em ambos os estágios. Além disso, a biblioteca tf.Transform pode ser executada em escala em um pipeline de processamento em lote no Dataflow para preparar os dados de treinamento antecipadamente e melhorar a eficiência do treinamento.

O diagrama a seguir, figura 4, mostra como a biblioteca tf.Transform pré-processa e transforma dados para treinamento e previsão. O processo é descrito nas seções a seguir.

Transforme dados de treinamento e avaliação

Você pré-processa os dados brutos de treinamento usando a transformação implementada nas APIs tf.Transform Apache Beam e executa-os em escala no Dataflow. O pré-processamento ocorre nas seguintes fases:

• Fase de análise: durante a fase de análise, as estatísticas necessárias (como médias, variações e quantis) para transformações com estado são calculadas nos dados de treinamento com operações de passagem completa. Esta fase produz um conjunto de artefatos de transformação, incluindo o gráfico transform_fn . O gráfico transform_fn é um gráfico do TensorFlow que possui a lógica de transformação como operações em nível de instância. Inclui as estatísticas calculadas na fase de análise como constantes.
• Fase de transformação: durante a fase de transformação, o gráfico transform_fn é aplicado aos dados brutos de treinamento, onde as estatísticas computadas são usadas para processar os registros de dados (por exemplo, para dimensionar colunas numéricas) em nível de instância.

Uma abordagem de duas fases como esta aborda o desafio de pré-processamento de realizar transformações de passagem completa.

Quando os dados de avaliação são pré-processados, apenas as operações em nível de instância são aplicadas, usando a lógica no gráfico transform_fn e as estatísticas calculadas a partir da fase de análise nos dados de treinamento. Em outras palavras, você não analisa os dados de avaliação de maneira completa para calcular novas estatísticas, como μ e σ, para normalizar recursos numéricos nos dados de avaliação. Em vez disso, você usa as estatísticas computadas dos dados de treinamento para transformar os dados de avaliação em nível de instância.

Os dados de treinamento e avaliação transformados são preparados em escala usando o Dataflow, antes de serem usados ​​para treinar o modelo. Este processo de preparação de dados em lote aborda o desafio de pré-processamento de preparar os dados antecipadamente para melhorar a eficiência do treinamento. Conforme mostrado na Figura 4, a interface interna do modelo espera recursos transformados.

Anexe transformações ao modelo exportado

Como observado, o gráfico transform_fn produzido pelo pipeline tf.Transform é armazenado como um gráfico de tensorflow exportado. O gráfico exportado consiste na lógica de transformação como operações no nível da instância e todas as estatísticas calculadas nas transformações de passagem completa como constantes gráficas. Quando o modelo treinado é exportado para servir, o gráfico transform_fn é anexado ao SalvedModel como parte de sua função serving_fn .

Embora esteja servindo ao modelo de previsão, a interface de servir de modelo espera pontos de dados no formato bruto (ou seja, antes de qualquer transformação). No entanto, a interface interna do modelo espera os dados no formato transformado.

O gráfico transform_fn , que agora faz parte do modelo, aplica toda a lógica de pré -processamento no ponto de dados de entrada. Ele usa as constantes armazenadas (como μ e σ para normalizar os recursos numéricos) na operação no nível da instância durante a previsão. Portanto, o gráfico transform_fn converte o ponto de dados bruto no formato transformado. O formato transformado é o que é esperado pela interface interna do modelo para produzir previsão, como mostrado na Figura 4.

Esse mecanismo resolve o desafio de pré-processamento da inclinação que serve para o treinamento, porque a mesma lógica (implementação) usada para transformar os dados de treinamento e avaliação é aplicada para transformar os novos pontos de dados durante a previsão.

Resumo das opções de pré -processamento

A tabela a seguir resume as opções de pré -processamento de dados que este documento discutiu. Na tabela, "N/A" significa "não aplicável".

^* Com o tensorflow, transformações como cruzamento, incorporação e codificação de uma vez devem ser executadas declarativamente como colunas feature_columns .

O que vem a seguir

• Para implementar um pipeline tf.Transform e executá -lo usando o DataFlow, leia a parte dois desta série, pré -processamento de dados para ML usando o TensorFlow Transform .
• Pegue a especialização do Coursera no ML com o TensorFlow no Google Cloud .
• Aprenda sobre as melhores práticas para a engenharia de ML em regras de ML .
• Para mais arquiteturas de referência, diagramas e práticas recomendadas, explore as soluções de nuvem TFX .

Este documento é o primeiro de uma série de duas partes que explora o tópico de engenharia de dados e engenharia de recursos para aprendizado de máquina (ML), com foco nas tarefas de aprendizado supervisionado. Esta primeira parte discute as melhores práticas para pré -processamento de dados em um pipeline ML no Google Cloud. O documento se concentra no uso da biblioteca TensorFlow e da Biblioteca de Tensorflow de código aberto ( tf.Transform ) para preparar dados, treinar o modelo e servir o modelo para previsão. Este documento destaca os desafios do pré -processamento de dados para o ML e descreve as opções e cenários para executar a transformação de dados no Google Cloud de maneira eficaz.

Este documento pressupõe que você esteja familiarizado com o BigQuery , Dataflow , Vertex AI e a API do TensorFlow Keras .

O segundo documento, o pré-processamento de dados para ML com o Google Cloud , fornece um tutorial passo a passo sobre como implementar um tf.Transform Pipeline.

Introdução

O ML ajuda a encontrar automaticamente padrões complexos e potencialmente úteis nos dados. Esses padrões são condensados ​​em um modelo de ML que pode ser usado em novos pontos de dados - um processo chamado de fabricação de previsões ou execução de inferência .

Construir um modelo ML é um processo de várias etapas. Cada etapa apresenta seus próprios desafios técnicos e conceituais. Esta série de duas partes se concentra nas tarefas de aprendizado supervisionado e no processo de seleção, transformação e aumento dos dados de origem para criar poderosos sinais preditivos para a variável de destino. Essas operações combinam o conhecimento do domínio com as técnicas de ciência de dados. As operações são a essência da engenharia de recursos .

O tamanho dos conjuntos de dados de treinamento para os modelos ML do mundo real pode ser facilmente igual ou superior a um terabyte (TB). Portanto, você precisa de estruturas de processamento de dados em larga escala para processar esses conjuntos de dados com eficiência e distribuição. Quando você usa um modelo ML para fazer previsões, você deve aplicar as mesmas transformações que você usou para os dados de treinamento sobre os novos pontos de dados. Ao aplicar as mesmas transformações, você apresenta o conjunto de dados ao vivo ao modelo ML da maneira que o modelo espera.

Este documento discute esses desafios para diferentes níveis de granularidade das operações de engenharia de recursos: agregações de nível de instância, passagem completa e janela do tempo. Este documento também descreve as opções e cenários para executar a transformação de dados para ML no Google Cloud.

Este documento também fornece uma visão geral do TensorFlow Transform ( tf.Transform ), uma biblioteca para o TensorFlow que permite definir a transformação de dados de nível de instância e passa-integral por meio de pipelines de pré-processamento de dados. Esses oleodutos são executados com feixe Apache e criam artefatos que permitem aplicar as mesmas transformações durante a previsão que quando o modelo é servido.

Dados de pré -processamento para ML

Esta seção apresenta operações de pré -processamento de dados e estágios de prontidão de dados. Também discute os tipos de operações de pré -processamento e sua granularidade.

Engenharia de dados em comparação com a engenharia de recursos

O pré -processamento dos dados para ML envolve engenharia de dados e engenharia de recursos. A engenharia de dados é o processo de conversão de dados brutos em dados preparados . A engenharia de recursos sintoniza os dados preparados para criar os recursos esperados pelo modelo ML. Estes termos têm os seguintes significados:

Dados brutos (ou apenas dados )

Os dados em seu formulário de origem, sem qualquer preparação prévia para ML. Nesse contexto, os dados podem estar em sua forma bruta (em um lago de dados) ou em uma forma transformada (em um data warehouse). Os dados transformados que estão em um data warehouse podem ter sido convertidos de sua forma bruta original para ser usada para análises. No entanto, nesse contexto, dados brutos significam que os dados não foram preparados especificamente para sua tarefa ML. Os dados também são considerados dados brutos se forem enviados a partir de sistemas de streaming que eventualmente chamam os modelos ML para previsões.

Dados preparados

O conjunto de dados no formulário pronto para sua tarefa ML: as fontes de dados foram analisadas, unidas e colocadas em uma forma tabular. Os dados preparados são agregados e resumidos para a granularidade certa - por exemplo, cada linha no conjunto de dados representa um cliente exclusivo, e cada coluna representa informações de resumo para o cliente, como o total gasto nas últimas seis semanas. Em uma tabela de dados preparada, colunas irrelevantes foram descartadas e registros inválidos foram filtrados. Para tarefas de aprendizado supervisionado, o recurso de destino está presente.

Recursos de engenharia

O conjunto de dados com os recursos ajustados que são esperados pelo modelo-ou seja, recursos criados através da execução de certas operações específicas de ML nas colunas no conjunto de dados preparado e criando novos recursos para o seu modelo durante o treinamento e a previsão, conforme descrito posteriormente em operações de pré -processamento . Exemplos dessas operações incluem escalonamento de colunas numéricas para um valor entre 0 e 1, valores de recorte e recursos categóricos de codificação única .

O diagrama a seguir, Figura 1, mostra as etapas envolvidas na preparação de dados pré -processados:

Na prática, os dados da mesma fonte geralmente estão em diferentes estágios de prontidão. Por exemplo, um campo de uma tabela no seu data warehouse pode ser usado diretamente como um recurso de engenharia. Ao mesmo tempo, outro campo na mesma tabela pode precisar passar por transformações antes que se torne um recurso de engenharia. Da mesma forma, as operações de engenharia de dados e engenharia de recursos podem ser combinadas na mesma etapa de pré -processamento de dados.

Operações de pré -processamento

O pré -processamento de dados inclui várias operações. Cada operação foi projetada para ajudar o ML a criar melhores modelos preditivos. Os detalhes dessas operações de pré -processamento estão fora do escopo deste documento, mas algumas operações são descritos brevemente nesta seção.

Para dados estruturados, as operações de pré -processamento de dados incluem o seguinte:

• Limpeza de dados: removendo ou corrigindo registros que corromperam ou inválidos dos dados brutos e removendo registros que estão faltando um grande número de colunas.
• Seleção e particionamento de instâncias: selecionando pontos de dados no conjunto de dados de entrada para criar treinamento, avaliação (validação) e conjuntos de testes . Esse processo inclui técnicas para amostragem aleatória repetível, aulas minoritárias superampos e partição estratificada.
• Ajuste do recurso: Melhorando a qualidade de um recurso para ML, que inclui dimensionar e normalizar valores numéricos, imputar valores ausentes, cortar outliers e ajustar valores que têm distribuições distorcidas.
• Transformação do recurso: convertendo um recurso numérico em um recurso categórico (por meio de baldes ) e convertendo recursos categóricos em uma representação numérica (através de uma codificação em um hot, aprendendo com contagens , incorporações esparsas, etc.). Alguns modelos funcionam apenas com recursos numéricos ou categóricos, enquanto outros podem lidar com recursos do tipo misto. Mesmo quando os modelos lidam com os dois tipos, eles podem se beneficiar de diferentes representações (numéricas e categóricas) do mesmo recurso.
• Extração de recursos: reduzindo o número de recursos, criando representações de dados mais poderosas e mais poderosas usando técnicas como PCA , incorporando extração e hash .
• Seleção de recursos: selecionando um subconjunto dos recursos de entrada para treinar o modelo e ignorar os irrelevantes ou redundantes, usando métodos de filtro ou wrapper . A seleção de recursos também pode envolver simplesmente soltar recursos se os recursos estiverem faltando um grande número de valores.
• Construção de recursos: Criando novos recursos usando técnicas típicas, como expansão polinomial (usando funções matemáticas univariadas) ou cruzamento de recursos (para capturar interações com recursos). Os recursos também podem ser construídos usando a lógica de negócios a partir do domínio do caso de uso do ML.

Quando você trabalha com dados não estruturados (por exemplo, imagens, áudio ou documentos de texto), o aprendizado profundo substitui a engenharia de recursos baseada em domínio-conhecimento, dobrando-os na arquitetura do modelo. Uma camada convolucional é um pré -processador automático de recurso. A construção da arquitetura do modelo correta requer algum conhecimento empírico dos dados. Além disso, é necessária uma quantidade de pré -processamento, como a seguinte:

• Para documentos de texto: Stemming e Lemmatização , Cálculo TF-IDF e Extração de N-Gram , incorporando a pesquisa.
• Para imagens: recorte, redimensionamento, corte, desfoque gaussiano e filtros canários.
• Para todos os tipos de dados (incluindo texto e imagens): Transfer Learning , que trata as camadas de todas as coisas, mas as saliências do modelo totalmente treinado como uma etapa de engenharia de recursos.

Granularidade de pré -processamento

Esta seção discute a granularidade dos tipos de transformações de dados. Ele mostra por que essa perspectiva é fundamental ao preparar novos pontos de dados para previsões usando transformações aplicadas nos dados de treinamento.

As operações de pré -processamento e transformação podem ser categorizadas da seguinte maneira, com base na Operação Granularidade:

• Transformações no nível da instância durante o treinamento e previsão . Essas são transformações diretas, onde apenas valores da mesma instância são necessários para a transformação. Por exemplo, as transformações no nível da instância podem incluir o corte do valor de um recurso em algum limite, expandindo o polinomialmente outro recurso, multiplicando dois recursos ou comparando dois recursos para criar um sinalizador booleano.

  Essas transformações devem ser aplicadas de forma idêntica durante o treinamento e a previsão, porque o modelo será treinado nos recursos transformados, não nos valores de entrada bruta. Se os dados não forem transformados de forma idêntica, o modelo se comporta mal porque é apresentado com dados que possuem uma distribuição de valores com os quais não foi treinado. Para obter mais informações, consulte a discussão sobre a distorção que serve para o treinamento na seção de desafios de pré-processamento .

• Transformações passadas durante o treinamento, mas transformações no nível da instância durante a previsão . Nesse cenário, as transformações são de estado, porque usam algumas estatísticas pré -computadas para realizar a transformação. Durante o treinamento, você analisa todo o corpo de dados de treinamento para calcular quantidades como mínimo, máximo, médio e variação para transformar dados de treinamento, dados de avaliação e novos dados no tempo de previsão.

  Por exemplo, para normalizar um recurso numérico para treinamento, você calcula sua média (μ) e seu desvio padrão (σ) em todos os dados de treinamento. Este cálculo é chamado de uma operação de passagem completa (ou analisa ). Quando você serve o modelo de previsão, o valor de um novo ponto de dados é normalizado para evitar a inclinação de serviço de treinamento. Portanto, os valores μ e σ que são calculados durante o treinamento são usados ​​para ajustar o valor do recurso, que é a seguinte operação em nível de instância :

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  As transformações passa-integral incluem o seguinte:

  • Recursos numéricos de escala Minmax usando MIN e Max calculados a partir do conjunto de dados de treinamento.
  • Recursos numéricos de escala padrão (normalização do escore z) usando μ e σ calculados no conjunto de dados de treinamento.
  • Recursos numéricos de baldes usando quantis.
  • Imputando valores ausentes usando a mediana (recursos numéricos) ou o modo (recursos categóricos).
  • Strings de conversão (valores nominais) em números inteiros (índices) extraindo todos os valores distintos (vocabulário) de um recurso categórico de entrada.
  • Contando a ocorrência de um termo (valor do recurso) em todos os documentos (instâncias) para calcular o TF-IDF.
  • Computando o PCA dos recursos de entrada para projetar os dados em um espaço dimensional inferior (com recursos linearmente dependentes).

  Você deve usar apenas os dados de treinamento para calcular estatísticas como μ, σ, min e máx . Se você adicionar os dados de teste e avaliação para essas operações, estará vazando informações dos dados de avaliação e teste para treinar o modelo. Isso afeta a confiabilidade dos resultados do teste e avaliação. Para garantir que você aplique uma transformação consistente a todos os conjuntos de dados, você usa as mesmas estatísticas calculadas a partir dos dados de treinamento para transformar os dados de teste e avaliação.

• Agregações históricas durante o treinamento e previsão . Isso envolve a criação de agregações de negócios, derivações e sinalizadores como sinais de entrada para a tarefa de previsão - por exemplo, criação de métricas de recência, frequência e monetário (RFM) para os clientes criarem modelos de propensão. Esses tipos de recursos podem ser pré -computados e armazenados em uma loja de recursos a serem usados ​​durante o treinamento do modelo, a pontuação do lote e a previsão on -line. Você também pode executar engenharia adicional de recursos (por exemplo, transformação e ajuste) para essas agregações antes do treinamento e previsão.

• Agregações históricas durante o treinamento, mas agregações em tempo real durante a previsão . Essa abordagem envolve a criação de um recurso resumindo valores em tempo real ao longo do tempo. Nesta abordagem, as instâncias a serem agregadas são definidas através de cláusulas de janela temporal. Por exemplo, você pode usar essa abordagem se deseja treinar um modelo que estima o tempo de viagem de táxi com base nas métricas de tráfego para a rota nos últimos 5 minutos, nos últimos 10 minutos, nos últimos 30 minutos e em outro intervalos. Você também pode usar essa abordagem para prever a falha de uma peça do motor com base na média móvel dos valores de temperatura e vibração calculados nos últimos 3 minutos. Embora essas agregações possam ser preparadas offline para treinamento, elas são calculadas em tempo real a partir de um fluxo de dados durante a porção.

  Mais precisamente, quando você prepara os dados de treinamento, se o valor agregado não estiver nos dados brutos, o valor será criado durante a fase de engenharia de dados. Os dados brutos geralmente são armazenados em um banco de dados com um formato de (entity, timestamp, value) . Nos exemplos anteriores, entity é o identificador do segmento de rotas para as rotas de táxi e o identificador da peça do motor para a falha do motor. Você pode usar operações de janela para calcular (entity, time_index, aggregated_value_over_time_window) e usar os recursos de agregação como uma entrada para o seu treinamento de modelo.

  Quando o modelo para previsão em tempo real (online) é servido, o modelo espera recursos derivados dos valores agregados como entrada. Portanto, você pode usar uma tecnologia de processamento de fluxo, como o Apache Beam, para calcular as agregações dos pontos de dados em tempo real transmitidos para o seu sistema. A tecnologia de processamento de fluxo agrega dados em tempo real com base nas janelas de tempo à medida que os novos pontos de dados chegam. Você também pode executar engenharia adicional de recursos (por exemplo, transformação e ajuste) para essas agregações antes do treinamento e previsão.

ML Pipeline no Google Cloud

Esta seção discute os componentes principais de um pipeline de ponta a ponta típico para treinar e servir modelos TensorFlow ML no Google Cloud usando serviços gerenciados. Ele também discute onde você pode implementar diferentes categorias das operações de pré -processamento de dados e desafios comuns que você pode enfrentar quando implementar essas transformações. A seção de como tf.Transform Works mostra como a biblioteca de transformação do tensorflow ajuda a enfrentar esses desafios.

Arquitetura de alto nível

O diagrama a seguir, a Figura 2, mostra uma arquitetura de alto nível de um pipeline típico de ML para treinamento e servir modelos de tensorflow. Os rótulos A, B e C no diagrama se referem aos diferentes locais do pipeline em que o pré -processamento de dados pode ocorrer. Detalhes sobre essas etapas são fornecidos na seção a seguir.

O oleoduto consiste nas seguintes etapas:

1. Depois que os dados brutos são importados, os dados tabulares são armazenados em BigQuery e outros dados como imagens, áudio e vídeo, são armazenados no armazenamento em nuvem. A segunda parte desta série usa dados tabulares armazenados em BigQuery como exemplo.
2. Engenharia de dados (preparação) e engenharia de recursos são executadas em escala usando o DataFlow. Essa execução produz conjuntos de treinamento, avaliação e teste prontos para ML, armazenados no armazenamento em nuvem. Idealmente, esses conjuntos de dados são armazenados como arquivos TFRecord , que é o formato otimizado para cálculos de tensorflow.
3. Um pacote de treinadores de modelos TensorFlow é enviado ao Treinamento da AI da Vertex, que usa os dados pré -processados ​​das etapas anteriores para treinar o modelo. A saída desta etapa é um modelo de tensorflow treinado que é exportado para armazenamento em nuvem.
4. O modelo treinado de tensorflow é implantado na previsão da AI da Vertex como um serviço que possui uma API REST para que possa ser usada para previsões on -line. O mesmo modelo também pode ser usado para trabalhos de previsão de lote.
5. Depois que o modelo é implantado como uma API REST, os aplicativos do cliente e os sistemas internos podem invocar a API enviando solicitações com alguns pontos de dados e recebendo respostas do modelo com previsões.
6. Para orquestrar e automatizar este pipeline, você pode usar os pipelines da AI da Vertex como um agendador para invocar a preparação de dados, o treinamento de modelos e as etapas de implantação de modelos.

Você também pode usar a loja de recursos da AI da Vertex para armazenar recursos de entrada para fazer previsões. Por exemplo, você pode criar periodicamente recursos de engenharia a partir dos dados brutos mais recentes e armazená -los na loja de recursos da AI da Vertex. Os aplicativos do cliente buscam os recursos de entrada necessários da loja de recursos da Vertex AI e os enviam para o modelo para receber previsões.

Onde fazer pré -processamento

Na Figura 2, os rótulos A, B e C mostram que as operações de pré -processamento de dados podem ocorrer em BigQuery, Dataflow ou Tensorflow. As seções a seguir descrevem como cada uma dessas opções funciona.

Opção A: BigQuery

Normalmente, a lógica é implementada em BigQuery para as seguintes operações:

• Amostragem: selecionando aleatoriamente um subconjunto dos dados.
• Filtragem: removendo instâncias irrelevantes ou inválidas.
• Particionamento: dividindo os dados para produzir conjuntos de treinamento, avaliação e testes.

Os scripts BigQuery SQL podem ser usados ​​como uma consulta de fonte para o pipeline de pré -processamento de fluxo de dados, que é a etapa de processamento de dados na Figura 2. Por exemplo, se um sistema for usado no Canadá e o data warehouse possui transações de todo o mundo, filtrando para Obtenha os dados de treinamento somente no Canadá, são melhores em BigQuery. A engenharia de recursos em BigQuery é simples e escalável, e suporta a implementação de agregações no nível da instância e históricas apresentam transformações.

No entanto, recomendamos que você use o BigQuery para engenharia de recursos apenas se você usar seu modelo para previsão de lote (pontuação) ou se os recursos forem pré -computados em BigQuery, mas armazenados na loja de recursos da AI da Vertex a serem usados ​​durante a previsão on -line. Se você planeja implantar o modelo para previsões on -line e se você não tiver o recurso de engenharia em uma loja de recursos on -line, precisará replicar as operações de pré -processamento do SQL para transformar os pontos de dados brutos que outros sistemas geram. Em outras palavras, você precisa implementar a lógica duas vezes: uma vez no SQL para pré -processar dados de treinamento em bigQuery e uma segunda vez na lógica do aplicativo que consome o modelo para pré -processar pontos de dados on -line para previsão.

Por exemplo, se o seu aplicativo cliente estiver escrito em Java, você precisará reimplementar a lógica em Java. Isso pode introduzir erros devido a discrepâncias de implementação, conforme descrito na seção Skew que serve para o treinamento de desafios de pré-processamento posteriormente neste documento. Também é uma sobrecarga extra para manter duas implementações diferentes. Sempre que você altera a lógica no SQL para pré -processar os dados de treinamento, é necessário alterar a implementação do Java de acordo para o pré -processamento de dados no horário de servir.

Se você estiver usando seu modelo apenas para previsão de lote (por exemplo, usando a previsão de lote AI do vértice) e se seus dados para pontuação forem provenientes da BigQuery, poderá implementar essas operações de pré -processamento como parte do script BigQuery SQL. Nesse caso, você pode usar o mesmo script SQL de pré -processamento para preparar dados de treinamento e pontuação.

As transformações com estado de passagem total não são adequadas para implementação em BigQuery. Se você usar o BigQuery para transformações de passagem completa, precisará de tabelas auxiliares para armazenar quantidades necessárias para transformações estabelecidas, como meios e variações para escalar recursos numéricos. Além disso, a implementação de transformações de passagem completa usando o SQL no BigQuery cria maior complexidade nos scripts SQL e cria intrincada dependência entre o treinamento e os scripts SQL de pontuação.

Opção B: DataFlow

Conforme mostrado na Figura 2, você pode implementar operações de pré -processamento computacionalmente caras no Apache Beam e executá -las em escala usando o DataFlow. O DataFlow é um serviço de autocaling totalmente gerenciado para processamento de dados em lote e fluxo. Quando você usa o DataFlow, você também pode usar bibliotecas especializadas externas para processamento de dados, diferentemente do BigQuery.

O DataFlow pode executar transformações no nível da instância e transformações de agregação histórica e em tempo real. Em particular, se seus modelos ML esperam um recurso de entrada como total_number_of_clicks_last_90sec , as funções de janela do feixe Apache podem calcular esses recursos com base na agregação dos valores das janelas de tempo dos dados de eventos em tempo real (streaming) (por exemplo, cliques). Na discussão anterior da granularidade das transformações , isso foi referido como "agregações históricas durante o treinamento, mas agregações em tempo real durante a previsão".

O diagrama a seguir, a Figura 3, mostra o papel do fluxo de dados no processamento de dados do fluxo para previsões quase em tempo real.

Conforme mostrado na Figura 3, durante o processamento, os eventos chamados de pontos de dados são ingeridos no pub/sub . O DataFlow consome esses pontos de dados, calcula os recursos com base em agregados ao longo do tempo e, em seguida, chama a API do modelo ML implantada para previsões. As previsões são então enviadas para um pub/sub -fila de saída. No pub/sub, as previsões podem ser consumidas por sistemas a jusante, como monitoramento ou controle, ou podem ser empurrados para trás (por exemplo, como notificações) para o cliente solicitante original. As previsões também podem ser armazenadas em um armazenamento de dados de baixa latência, como o Cloud BigTable para buscar em tempo real. A Cloud BigTable também pode ser usada para acumular e armazenar essas agregações em tempo real, para que possam ser procuradas quando necessário para a previsão.

A mesma implementação do feixe Apache pode ser usada para dados de treinamento em processamento em lote, provenientes de um armazenamento de dados offline, como dados em tempo real do BigQuery e Stream-Process para servir previsões on-line.

Em outras arquiteturas típicas, como a arquitetura mostrada na Figura 2, o aplicativo cliente chama diretamente a API do modelo implantado para previsões on -line. Nesse caso, se as operações de pré -processamento forem implementadas no DataFlow para preparar os dados de treinamento, as operações não serão aplicadas aos dados de previsão que vão diretamente ao modelo. Portanto, transformações como essas devem ser integradas no modelo durante a servir para previsões on -line.

O fluxo de dados pode ser usado para executar a transformação de passagem completa, calculando as estatísticas necessárias em escala. No entanto, essas estatísticas precisam ser armazenadas em algum lugar a ser usado durante a previsão para transformar pontos de dados de previsão. Ao usar a biblioteca TensorFlow Transform ( tf.Transform ), você pode incorporar diretamente essas estatísticas no modelo em vez de armazená -las em outros lugares. Essa abordagem é explicada posteriormente em como o TF.Transform funciona .

Opção C: Tensorflow

Conforme mostrado na Figura 2, você pode implementar operações de pré -processamento e transformação de dados no próprio modelo TensorFlow. Conforme mostrado na figura, o pré -processamento que você implementa para treinar o modelo TensorFlow se torna parte integrante do modelo quando o modelo é exportado e implantado para previsões. As transformações no modelo Tensorflow podem ser realizadas de uma das seguintes maneiras:

• Implementando toda a lógica de transformação no nível da instância na função input_fn e na função serving_fn . A função input_fn prepara um conjunto de dados usando a API tf.data.Dataset para treinar um modelo. A função serving_fn recebe e prepara os dados para previsões.
• Colocando o código de transformação diretamente no seu modelo TensorFlow usando camadas de pré -processamento de Keras ou criando camadas personalizadas .

O código da lógica de transformação na função serving_fn define a interface de porção do seu SalvedModel para previsão on -line. Se você implementar as mesmas transformações usadas para preparar dados de treinamento no código lógico de transformação da função serving_fn , ele garante que as mesmas transformações sejam aplicadas a novos pontos de dados de previsão quando forem servidos.

No entanto, como o modelo TensorFlow processa cada ponto de dados de forma independente ou em um pequeno lote, você não pode calcular agregações de todos os pontos de dados. Como resultado, as transformações passadas completas não podem ser implementadas no seu modelo Tensorflow.

Desafios de pré -processamento

A seguir, são apresentados os principais desafios da implementação do pré -processamento de dados:

• Skew que serve para treinamento . A inclinação que serve para o treinamento refere-se a uma diferença entre a eficácia (desempenho preditivo) durante o treinamento e durante a porção. Essa inclinação pode ser causada por uma discrepância entre como você lida com dados no treinamento e nos pipelines de servir. Por exemplo, se o seu modelo for treinado em um recurso logaritmicamente transformado, mas é apresentado com o recurso bruto durante a porção, a saída de previsão pode não ser precisa.

  Se as transformações se tornarem parte do próprio modelo, pode ser direto para lidar com transformações no nível da instância, conforme descrito anteriormente na opção C: Tensorflow . Nesse caso, a interface de serviço do modelo (a função serving_fn ) espera dados brutos, enquanto o modelo transforma esses dados internamente antes de calcular a saída. As transformações são as mesmas que foram aplicadas nos pontos de dados brutos de treinamento e previsão.

• Transformações passadas . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .

• Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.

  Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.

  Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

• Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
• Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.

The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

^* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

What's next

• To implement a tf.Transform pipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform .
• Take the Coursera specialization on ML with TensorFlow on Google Cloud .
• Learn about best practices for ML engineering in Rules of ML .
• For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .

This document is the first in a two-part series that explores the topic of data engineering and feature engineering for machine learning (ML), with a focus on supervised learning tasks. This first part discusses the best practices for preprocessing data in an ML pipeline on Google Cloud. The document focuses on using TensorFlow and the open source TensorFlow Transform ( tf.Transform ) library to prepare data, train the model, and serve the model for prediction. This document highlights the challenges of preprocessing data for ML, and it describes the options and scenarios for performing data transformation on Google Cloud effectively.

This document assumes that you're familiar with BigQuery , Dataflow , Vertex AI , and the TensorFlow Keras API.

The second document, Data preprocessing for ML with Google Cloud , provides a step-by-step tutorial for how to implement a tf.Transform pipeline.

Introdução

ML helps you automatically find complex and potentially useful patterns in data. These patterns are condensed in an ML model that can then be used on new data points—a process called making predictions or performing inference .

Building an ML model is a multistep process. Each step presents its own technical and conceptual challenges. This two-part series focuses on supervised learning tasks and the process of selecting, transforming, and augmenting the source data to create powerful predictive signals to the target variable. These operations combine domain knowledge with data science techniques. The operations are the essence of feature engineering .

The size of training datasets for real-world ML models can easily be equal to or greater than one terabyte (TB). Therefore, you need large-scale data processing frameworks in order to process these datasets efficiently and distributedly. When you use an ML model to make predictions, you have to apply the same transformations that you used for the training data on the new data points. By applying the same transformations, you present the live dataset to the ML model the way that the model expects.

This document discusses these challenges for different levels of granularity of feature engineering operations: instance-level, full-pass, and time-window aggregations. This document also describes the options and scenarios to perform data transformation for ML on Google Cloud.

This document also provides an overview of TensorFlow Transform ( tf.Transform ), a library for TensorFlow that lets you define both instance-level and full-pass data transformation through data preprocessing pipelines. These pipelines are executed with Apache Beam , and they create artifacts that let you apply the same transformations during prediction as when the model is served.

Preprocessing data for ML

This section introduces data preprocessing operations and stages of data readiness. It also discusses the types of the preprocessing operations and their granularity.

Data engineering compared to feature engineering

Preprocessing the data for ML involves both data engineering and feature engineering. Data engineering is the process of converting raw data into prepared data . Feature engineering then tunes the prepared data to create the features that are expected by the ML model. These terms have the following meanings:

Raw data (or just data )

The data in its source form, without any prior preparation for ML. In this context, the data might be in its raw form (in a data lake) or in a transformed form (in a data warehouse). Transformed data that's in a data warehouse might have been converted from its original raw form to be used for analytics. However, in this context, raw data means that the data hasn't been prepared specifically for your ML task. Data is also considered raw data if it's sent from streaming systems that eventually call ML models for predictions.

Prepared data

The dataset in the form ready for your ML task: data sources have been parsed, joined, and put into a tabular form. Prepared data is aggregated and summarized to the right granularity—for example, each row in the dataset represents a unique customer, and each column represents summary information for the customer, like the total spent in the last six weeks. In a prepared data table, irrelevant columns have been dropped, and invalid records have been filtered out. For supervised learning tasks, the target feature is present.

Engineered features

The dataset with the tuned features that are expected by the model—that is, features that are created by performing certain ML-specific operations on the columns in the prepared dataset, and creating new features for your model during training and prediction, as described later in Preprocessing operations . Examples of these operations include scaling numerical columns to a value between 0 and 1, clipping values, and one-hot-encoding categorical features.

The following diagram, figure 1, shows the steps that are involved in preparing preprocessed data:

In practice, data from the same source is often at different stages of readiness. For example, a field from a table in your data warehouse might be used directly as an engineered feature. At the same time, another field in the same table might need to go through transformations before it becomes an engineered feature. Similarly, data engineering and feature engineering operations might be combined in the same data preprocessing step.

Preprocessing operations

Data preprocessing includes several operations. Each operation is designed to help ML build better predictive models. The details of these preprocessing operations are outside the scope of this document, but some operations are briefly described in this section.

For structured data, data preprocessing operations include the following:

• Data cleansing: removing or correcting records that have corrupted or invalid values from raw data, and removing records that are missing a large number of columns.
• Instances selection and partitioning: selecting data points from the input dataset to create training, evaluation (validation), and test sets . This process includes techniques for repeatable random sampling, minority classes oversampling, and stratified partitioning.
• Feature tuning: improving the quality of a feature for ML, which includes scaling and normalizing numeric values, imputing missing values, clipping outliers, and adjusting values that have skewed distributions.
• Feature transformation: converting a numeric feature to a categorical feature (through bucketization ), and converting categorical features to a numeric representation (through one-hot encoding, learning with counts , sparse feature embeddings, etc.). Some models work only with numeric or categorical features, while others can handle mixed type features. Even when models handle both types, they can benefit from different representations (numeric and categorical) of the same feature.
• Feature extraction: reducing the number of features by creating lower-dimension, more powerful data representations using techniques such as PCA , embedding extraction, and hashing .
• Feature selection: selecting a subset of the input features for training the model, and ignoring the irrelevant or redundant ones, using filter or wrapper methods . Feature selection can also involve simply dropping features if the features are missing a large number of values.
• Feature construction: creating new features by using typical techniques, such as polynomial expansion (by using univariate mathematical functions) or feature crossing (to capture feature interactions). Features can also be constructed by using business logic from the domain of the ML use case.

When you work with unstructured data (for example, images, audio, or text documents), deep learning replaces domain-knowledge-based feature engineering by folding it into the model architecture. A convolutional layer is an automatic feature preprocessor. Constructing the right model architecture requires some empirical knowledge of the data. In addition, some amount of preprocessing is needed, such as the following:

• For text documents: stemming and lemmatization , TF-IDF calculation, and n-gram extraction, embedding lookup.
• For images: clipping, resizing, cropping, Gaussian blur, and canary filters.
• For all types of data (including text and images): transfer learning , which treats all-but-last layers of the fully trained model as a feature engineering step.

Preprocessing granularity

This section discusses the granularity of types of data transformations. It shows why this perspective is critical when preparing new data points for predictions using transformations that are applied on training data.

Preprocessing and transformation operations can be categorized as follows, based on operation granularity:

• Instance-level transformations during training and prediction . These are straightforward transformations, where only values from the same instance are needed for the transformation. For example, instance-level transformations might include clipping the value of a feature to some threshold, polynomially expanding another feature, multiplying two features, or comparing two features to create a Boolean flag.

  These transformations must be applied identically during training and prediction, because the model will be trained on the transformed features, not on the raw input values. If the data isn't transformed identically, then the model behaves poorly because it is presented with data that has a distribution of values that it wasn't trained with. For more information, see the discussion of training-serving skew in the Preprocessing challenges section.

• Full-pass transformations during training, but instance-level transformations during prediction . In this scenario, transformations are stateful, because they use some precomputed statistics to perform the transformation. During training, you analyze the whole body of training data to compute quantities such as minimum, maximum, mean, and variance for transforming training data, evaluation data, and new data at prediction time.

  For example, to normalize a numeric feature for training, you compute its mean (μ) and its standard deviation (σ) across the whole of the training data. This computation is called a full-pass (or analyze ) operation. When you serve the model for prediction, the value of a new data point is normalized to avoid training-serving skew. Therefore, μ and σ values that are computed during training are used to adjust the feature value, which is the following simple instance-level operation:

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  Full-pass transformations include the following:

  • MinMax scaling numerical features using min and max computed from the training dataset.
  • Standard scaling (z-score normalization) numerical features using μ and σ computed on the training dataset.
  • Bucketizing numerical features using quantiles.
  • Imputing missing values using the median (numerical features) or the mode (categorical features).
  • Converting strings (nominal values) to integers (indexes) by extracting all the distinct values (vocabulary) of an input categorical feature.
  • Counting the occurrence of a term (feature value) in all the documents (instances) to calculate for TF-IDF.
  • Computing the PCA of the input features to project the data into a lower dimensional space (with linearly dependent features).

  You should use only the training data to compute statistics like μ, σ, min , and max . If you add the test and evaluation data for these operations, you are leaking information from the evaluation and test data to train the model. Doing so affects the reliability of the test and evaluation results. To ensure that you apply a consistent transformation to all datasets, you use the same statistics computed from the training data to transform the test and evaluation data.

• Historical aggregations during training and prediction . This involves creating business aggregations, derivations, and flags as input signals to the prediction task—for example, creating recency, frequency, and monetary (RFM) metrics for customers to build propensity models. These types of features can be precomputed and stored in a feature store to be used during model training, batch scoring, and online prediction serving. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

• Historical aggregations during training, but real-time aggregations during prediction . This approach involves creating a feature by summarizing real-time values over time. In this approach, the instances to be aggregated are defined through temporal window clauses. For example, you can use this approach if you want to train a model that estimates the taxi trip time based on the traffic metrics for the route in the last 5 minutes, in the last 10 minutes, in the last 30 minutes, and at other intervals. You can also use this approach to predict the failure of an engine part based on the moving average of temperature and vibration values computed over the last 3 minutes. Although these aggregations can be prepared offline for training, they are computed in real time from a data stream during serving.

  More precisely, when you prepare training data, if the aggregated value isn't in the raw data, the value is created during the data engineering phase. The raw data is usually stored in a database with a format of (entity, timestamp, value) . In the previous examples, entity is the route segment identifier for the taxi routes and the engine part identifier for the engine failure. You can use windowing operations to compute (entity, time_index, aggregated_value_over_time_window) and use the aggregation features as an input for your model training.

  When the model for real-time (online) prediction is served, the model expects features derived from the aggregated values as an input. Therefore, you can use a stream-processing technology like Apache Beam to compute the aggregations from the real-time data points streamed into your system. Stream-processing technology aggregates real-time data based on time windows as new data points arrive. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

ML pipeline on Google Cloud

This section discusses the core components of a typical end-to-end pipeline to train and serve TensorFlow ML models on Google Cloud using managed services. It also discusses where you can implement different categories of the data preprocessing operations, and common challenges that you might face when you implement such transformations. The How tf.Transform works section shows how the TensorFlow Transform library helps to address these challenges.

High-level architecture

The following diagram, figure 2, shows a high-level architecture of a typical ML pipeline for training and serving TensorFlow models. The labels A, B, and C in the diagram refer to the different places in the pipeline where data preprocessing can take place. Details about these steps are provided in the following section.

The pipeline consists of the following steps:

1. After raw data is imported, tabular data is stored in BigQuery, and other data like images, audio, and video, is stored in Cloud Storage. The second part of this series uses tabular data stored in BigQuery as an example.
2. Data engineering (preparation) and feature engineering are executed at scale using Dataflow. This execution produces ML-ready training, evaluation, and test sets that are stored in Cloud Storage. Ideally, these datasets are stored as TFRecord files, which is the optimized format for TensorFlow computations.
3. A TensorFlow model trainer package is submitted to Vertex AI Training, which uses the preprocessed data from the previous steps to train the model. The output of this step is a trained TensorFlow SavedModel that is exported to Cloud Storage.
4. The trained TensorFlow model is deployed to Vertex AI Prediction as a service that has a REST API so that it can be used for online predictions. The same model can also be used for batch prediction jobs.
5. After the model is deployed as a REST API, client apps and internal systems can invoke the API by sending requests with some data points, and receiving responses from the model with predictions.
6. For orchestrating and automating this pipeline, you can use Vertex AI Pipelines as a scheduler to invoke the data preparation, model training, and model deployment steps.

You can also use Vertex AI Feature Store to store input features to make predictions. For example, you can periodically create engineered features from the latest raw data and store them in Vertex AI Feature Store. Client apps fetch the required input features from Vertex AI Feature Store and send them to the model to receive predictions.

Where to do preprocessing

In figure 2, the labels A, B, and C show that data preprocessing operations can take place in BigQuery, Dataflow, or TensorFlow. The following sections describe how each of these options work.

Option A: BigQuery

Typically, logic is implemented in BigQuery for the following operations:

• Sampling: randomly selecting a subset from the data.
• Filtering: removing irrelevant or invalid instances.
• Partitioning: splitting the data to produce training, evaluation, and test sets.

BigQuery SQL scripts can be used as a source query for the Dataflow preprocessing pipeline, which is the data processing step in figure 2. For example, if a system is used in Canada, and the data warehouse has transactions from around the world, filtering to get Canada-only training data is best done in BigQuery. Feature engineering in BigQuery is simple and scalable, and supports implementing instance-level and historical aggregations feature transformations.

However, we recommend that you use BigQuery for feature engineering only if you use your model for batch prediction (scoring), or if the features are precomputed in BigQuery, but stored in Vertex AI Feature Store to be used during online prediction. If you plan to deploy the model for online predictions, and if you don't have the engineered feature in an online feature store, you have to replicate the SQL preprocessing operations to transform the raw data points that other systems generate. In other words, you need to implement the logic twice: one time in SQL to preprocess training data in BigQuery, and a second time in the logic of the app that consumes the model to preprocess online data points for prediction.

For example, if your client app is written in Java, you need to reimplement the logic in Java. This can introduce errors due to implementation discrepancies, as described in the training-serving skew section of Preprocessing challenges later in this document. It's also extra overhead to maintain two different implementations. Whenever you change the logic in SQL to preprocess the training data, you need to change the Java implementation accordingly to preprocess data at serving time.

If you are using your model only for batch prediction (for example, using Vertex AI batch prediction ), and if your data for scoring is sourced from BigQuery, you can implement these preprocessing operations as part of the BigQuery SQL script. In that case, you can use the same preprocessing SQL script to prepare both training and scoring data.

Full-pass stateful transformations aren't suitable for implementation in BigQuery. If you use BigQuery for full-pass transformations, you need auxiliary tables to store quantities needed by stateful transformations, such as means and variances to scale numerical features. Further, implementation of full-pass transformations using SQL on BigQuery creates increased complexity in the SQL scripts, and creates intricate dependency between training and the scoring SQL scripts.

Option B: Dataflow

As shown in figure 2, you can implement computationally expensive preprocessing operations in Apache Beam, and run them at scale using Dataflow. Dataflow is a fully managed autoscaling service for batch and stream data processing. When you use Dataflow, you can also use external specialized libraries for data processing, unlike BigQuery.

Dataflow can perform instance-level transformations, and historical and real-time aggregation feature transformations. In particular, if your ML models expect an input feature like total_number_of_clicks_last_90sec , Apache Beam windowing functions can compute these features based on aggregating the values of time windows of real-time (streaming) events data (for example, click events). In the earlier discussion of granularity of transformations , this was referred to as "Historical aggregations during training, but real-time aggregations during prediction."

The following diagram, figure 3, shows the role of Dataflow in processing stream data for near real-time predictions.

As shown in figure 3, during processing, events called data points are ingested into Pub/Sub . Dataflow consumes these data points, computes features based on aggregates over time, and then calls the deployed ML model API for predictions. Predictions are then sent to an outbound Pub/Sub queue. From Pub/Sub, predictions can be consumed by downstream systems like monitoring or control, or they can be pushed back (for example, as notifications) to the original requesting client. Predictions can also be stored in a low-latency data store like Cloud Bigtable for real-time fetching. Cloud Bigtable can also be used to accumulate and store these real-time aggregations so they can be looked up when needed for prediction.

The same Apache Beam implementation can be used to batch-process training data that comes from an offline datastore like BigQuery and stream-process real-time data for serving online predictions.

In other typical architectures, such as the architecture shown in figure 2, the client app directly calls the deployed model API for online predictions. In that case, if preprocessing operations are implemented in Dataflow to prepare the training data, the operations aren't applied to the prediction data that goes directly to the model. Therefore, transformations like these should be integrated in the model during serving for online predictions.

Dataflow can be used to perform full-pass transformation, by computing the required statistics at scale. However, these statistics need to be stored somewhere to be used during prediction to transform prediction data points. By using the TensorFlow Transform ( tf.Transform ) library, you can directly embed these statistics in the model instead of storing them elsewhere. This approach is explained later in How tf.Transform works .

Option C: TensorFlow

As shown in figure 2, you can implement data preprocessing and transformation operations in the TensorFlow model itself. As shown in the figure, the preprocessing that you implement for training the TensorFlow model becomes an integral part of the model when the model is exported and deployed for predictions. Transformations in the TensorFlow model can be accomplished in one of the following ways:

• Implementing all of the instance-level transformation logic in the input_fn function and in the serving_fn function. The input_fn function prepares a dataset using the tf.data.Dataset API for training a model. The serving_fn function receives and prepares the data for predictions.
• Putting the transformation code directly in your TensorFlow model by using Keras preprocessing layers or creating custom layers .

The transformation logic code in the serving_fn function defines the serving interface of your SavedModel for online prediction. If you implement the same transformations that were used for preparing training data in the transformation logic code of the serving_fn function, it ensures that the same transformations are applied to new prediction data points when they're served.

However, because the TensorFlow model processes each data point independently or in a small batch, you can't calculate aggregations from all data points. As a result, full-pass transformations can't be implemented in your TensorFlow model.

Preprocessing challenges

The following are the primary challenges of implementing data preprocessing:

• Training-serving skew . Training-serving skew refers to a difference between effectiveness (predictive performance) during training and during serving. This skew can be caused by a discrepancy between how you handle data in the training and the serving pipelines. For example, if your model is trained on a logarithmically transformed feature, but it's presented with the raw feature during serving, the prediction output might not be accurate.

  If the transformations become part of the model itself, it can be straightforward to handle instance-level transformations, as described earlier in Option C: TensorFlow . In that case, the model serving interface (the serving_fn function) expects raw data, while the model internally transforms this data before computing the output. The transformations are the same as those that were applied on the raw training and prediction data points.

• Full-pass transformations . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .

• Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.

  Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.

  Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

• Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
• Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.

The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

^* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

What's next

• To implement a tf.Transform pipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform .
• Take the Coursera specialization on ML with TensorFlow on Google Cloud .
• Learn about best practices for ML engineering in Rules of ML .
• For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .