Migrar pipelines de dados

Neste documento, descrevemos como migrar os pipelines de dados upstream, que carregam dados no data warehouse. É possível usar este documento para entender melhor o que é um pipeline de dados, quais procedimentos e padrões um pipeline pode empregar e quais opções e tecnologias de migração estão disponíveis para uma migração de data warehouse.

O que é um pipeline de dados?

Na computação, um pipeline de dados é um tipo de aplicativo que processa dados por meio de uma sequência de passos de processamento conectados. Como conceito geral, pipelines de dados são aplicados, por exemplo, na transferência de dados entre sistemas de informação, na extração, transformação e carregamento (ETL), no enriquecimento de dados e na análise de dados em tempo real. Normalmente, os pipelines de dados são operados como um processo em lote que executa e processa dados quando executados ou como um processo de streaming que executa continuamente e processa dados à medida que eles são disponibilizados para o pipeline.

No contexto do armazenamento de dados, os pipelines de dados são, em geral, usados para ler dados de sistemas transacionais, aplicar transformações e gravar dados no armazenamento de dados. Cada uma das transformações é descrita por uma função, e a entrada para qualquer função é a saída da anterior ou das anteriores. Essas funções conectadas são descritas como um gráfico, que com frequência é chamado de gráfico acíclico dirigido (DAG). O gráfico segue uma direção (de origem para destino) e é acíclico: não é possível que a entrada de qualquer função dependa da saída do downstream de outra função no DAG. Em outras palavras, não são permitidas repetições. Cada nó do grafo é uma função, e cada borda representa os dados que fluem de uma função para a próxima. As funções iniciais são origens ou conexões a sistemas de dados de origem. As funções finais são coletores ou conexões a sistemas de dados de destino.

No contexto de pipelines de dados, as origens geralmente são sistemas transacionais (por exemplo, um RDBMS) e o coletor se conecta a um armazenamento de dados. Esse tipo de grafo é chamado de DAG de fluxo de dados. Também é possível usar DAGs para orquestrar a movimentação de dados entre pipelines de dados e outros sistemas. Esse uso é chamado de orquestração ou de DAG de fluxo de controle.

Quando migrar os pipelines de dados

Ao migrar um caso de uso para o BigQuery, é possível optar por descarregar ou migrar completamente.

Por um lado, ao descarregar um caso de uso, não é necessário migrar os pipelines de dados upstream antecipadamente. Primeiro, migre o esquema de caso de uso e os dados do armazenamento atual para o BigQuery. Em seguida, estabeleça uma cópia incremental do armazenamento de dados antigo para o novo de modo a manter os dados sincronizados. Por fim, migre e valide processos downstream, como scripts, consultas, painéis e aplicativos de negócios.

Nesse momento, os pipelines de dados upstream não serão alterados e ainda gravarão dados no armazenamento atual. É possível incluir os casos de uso descarregados no backlog de migração outra vez para que sejam completamente migrados em uma iteration posterior.

Por outro lado, ao migrar completamente um caso de uso, os pipelines de dados upstream necessários para o caso de uso são migrados para o Google Cloud. Na migração completa, é necessário descarregar o caso de uso primeiro. Após a migração completa, será possível suspender o uso das tabelas legadas correspondentes do armazenamento de dados no local, porque os dados serão ingeridos diretamente no BigQuery.

Durante uma iteração, é possível escolher uma das seguintes opções:

  • Transferir somente seu caso de uso.
  • Migrar totalmente um caso de uso anteriormente transferido.
  • Migrar totalmente um caso de uso do zero, transferindo-o primeiro na mesma iteração.

Ao migrar todos os casos de uso totalmente, será possível desativar o antigo armazenamento, o que é um passo importante para reduzir a sobrecarga e os custos.

Como migrar os pipelines de dados

No restante deste documento, você verá como migrar os pipelines de dados, incluindo que abordagem e procedimentos usar e quais tecnologias empregar. As opções variam do redirecionamento de pipelines de dados (redirecionando-os para o carregamento no BigQuery) até a regravação dos pipelines de dados para aproveitar os serviços gerenciados pelo Google Cloud.

Procedimentos e padrões para pipelines de dados

É possível usar pipelines de dados para executar diversos padrões e procedimentos. Eles são os mais usados no armazenamento de dados e podem ser de dados em lote ou de streaming. Os em lote são executados em dados coletados durante um determinado tempo (por exemplo, uma vez por dia). Os pipelines de dados de streaming lidam com eventos em tempo real sendo gerados pelos sistemas operacionais. Por exemplo, nas alterações de linha da CDC sendo geradas pelos bancos de dados de processamento de transações on-line (OLTP).

Extração, transformação e carregamento (ETL)

No contexto do armazenamento de dados, os pipelines de dados geralmente executam um procedimento de extração, transformação e carregamento (ETL, na sigla em inglês). As tecnologias de ETL são executadas fora do armazenamento de dados, o que significa que os recursos do armazenamento podem ser usados principalmente para consultas simultâneas, em vez de preparar e transformar dados. Uma desvantagem da transformação executada fora do armazenamento de dados é que ela exige o conhecimento de outras ferramentas e linguagens (além do SQL) para expressar essas transformações.

O diagrama a seguir mostra um típico procedimento de ETL.

Fluxo que mostra a origem (extração), indo para uma ou mais transformações (transformação), depois, para um coletor e, por fim, para um armazenamento de dados (carregamento)

Figura 1. Um procedimento de ETL típico.j

Um pipeline de dados ETL típico extrai dados de um ou mais sistemas de origem. Preferencialmente, o mínimo possível para evitar falhas causadas por problemas como sistemas indisponíveis. Em seguida, realiza uma série de transformações, incluindo a limpeza de dados, a aplicação de regras de negócios, a verificação da integridade dos dados e a criação de agregações ou desagregações. Para mais informações, consulte o Ciclo de ETL da vida real (em inglês).

É comum ter vários pipelines de dados. O primeiro se concentra na cópia de dados do sistema de origem para o armazenamento de dados. Os pipelines subsequentes aplicam a lógica de negócios e transformam os dados para uso em vários data marts (em inglês), que são subconjuntos do armazenamento de dados com foco em uma unidade de negócios ou foco de negócios específico.

Se houver vários pipelines de dados, será preciso orquestrá-los. O diagrama a seguir mostra como esse processo pode ser.

Orquestrador (DAG) gerenciando dois processos de ETL (Sub-DAGs)

Figura 2. Processo de orquestração para vários pipelines de dados.

No diagrama, cada pipeline de dados é considerado um sub-DAG do DAG de orquestração. Cada DAG de orquestração abrange vários pipelines de dados para se alinhar com o objetivo maior, por exemplo, preparar dados para uma unidade de negócios de modo que os analistas de negócios possam executar painéis ou relatórios.

Extração, carregamento e transformação (ELT)

O ELT é uma alternativa ao ETL. Com o ELT, o pipeline de dados é dividido em duas partes. Primeiro, uma tecnologia de ELT extrai os dados do sistema de origem e os carrega no data warehouse. Em seguida, os scripts SQL na parte superior do armazenamento de dados realizam as transformações. A vantagem dessa abordagem é o uso do SQL para expressar as transformações, a desvantagem é que isso pode consumir recursos de armazenamento de dados necessários para consultas simultâneas. Por isso, os lotes ELT geralmente são executados durante a noite (ou fora do horário de pico), quando há menor demanda sobre os recursos do sistema de armazenamento de dados.

O diagrama a seguir mostra um típico procedimento de ELT.

Fluxo mostrando origem (extração) indo para uma ou mais transformações (transformação), depois, para um coletor e, por fim, para um armazenamento de dados (carregamento).

Figura 3. Um procedimento de ELT típico.

Ao adotar uma abordagem de ELT, é comum separar a extração e o carregamento em um DAG e as transformações nos próprios DAGs. Os dados são carregados no armazenamento de dados uma única vez e, depois, transformados várias vezes para criar as diferentes tabelas usadas downstream na geração de relatórios e assim por diante. Esses DAGs, por sua vez, se tornam sub-DAGs em um DAG de orquestração maior (como mostrado na seção do ETL).

Ao migrar os pipelines de dados de um armazenamento de dados local congestionado para a nuvem, lembre-se de que os sistemas de armazenamento de dados em nuvem, como o BigQuery, são tecnologias paralelas de processamento de dados. Na verdade, no caso do BigQuery, é possível comprar mais recursos para dar suporte às crescentes demandas por ELT e às consultas simultâneas. Para mais informações, consulte Introdução à otimização do desempenho da consulta.

Extração e carregamento (EL)

É possível usar o procedimento de extração e carregamento (EL) sozinho ou seguido por transformações. Nesse caso, ele se torna ELT. O EL é mencionado separadamente porque estão disponíveis vários serviços automatizados que executam essa tarefa, reduzindo a necessidade de criar seu próprio pipeline de dados de ingestão. Para mais detalhes, consulte o Serviço de transferência de dados do BigQuery.

Captura de dados de alterações (CDC)

A CDC [link em inglês] é um dos vários padrões de design de software usados para acompanhar alterações de dados. Muitas vezes, ela é usada no armazenamento de dados, já que este serve para agrupar e acompanhar dados e suas alterações de vários sistemas de origem ao longo do tempo.

O diagrama a seguir mostra um exemplo de como a CDC funciona com o ELT.

Fluxo de ETL que mostra registros individuais com informações de versão atribuídas na extração e carimbos de data/hora adicionados no carregamento.

Figura 4. Como a CDC funciona com o ELT.

A CDC funciona bem com o ELT para armazenar o registro original antes de fazer qualquer alteração no fluxo.

Para que a parte de EL aconteça, é possível processar registros de banco de dados usando um software de CDC, como o Datastream, ou ferramentas de código aberto, como o Debezium e gravar os registros no BigQuery usando o Dataflow. Em seguida, use uma consulta SQL para determinar a versão mais recente antes de aplicar outras transformações. Veja um exemplo:

WITH ranked AS (
  SELECT
    *,
    ROW_NUMBER() OVER (
      PARTITION BY RECORD KEY
      ORDER BY EVENT TIMESTAMP DESC
    ) AS rank
  FROM TABLE NAME
)
SELECT *
FROM ranked
WHERE rank = 1

Ao refatorar ou criar novos pipelines de dados, use o padrão da CDC aplicado como um procedimento ELT. Essa abordagem garante um histórico completo de alterações de dados no upstream e fornece uma boa segregação de responsabilidades, por exemplo:

  • As equipes do sistema de origem garantem a disponibilidade dos registros e a publicação dos eventos de dados.
  • A equipe da plataforma de dados garante que o agrupamento de ingestão dos registros originais inclua registros de data e hora no armazenamento de dados.
  • As equipes de engenharia e de análise de dados programam uma série de transformações para preencher os data marts.

Ciclos de feedback com pipelines de dados operacionais

Pipelines de dados operacionais são pipelines de processamento de dados que pegam dados do data warehouse, transformam-nos, se necessário e gravam o resultado em sistemas operacionais.

Sistemas operacionais se referem a sistemas que processam as transações diárias da organização, como bancos de dados de OLTP, sistemas de gestão de relacionamento com o cliente (CRM), sistemas de gerenciamento de catálogo de produtos (PCM) e assim por diante. Como esses sistemas geralmente atuam como uma origem de dados, os pipelines de dados operacionais implementam um padrão de ciclo de feedback.

O padrão do pipeline de dados operacionais é mostrado no diagrama a seguir.

Pipeline de ETL alimentando o armazenamento de dados e, em seguida, um pipeline operacional que alimenta o sistema de origem, que alimenta o pipeline de ETL.

Figura 5. Padrão para um pipeline de dados operacionais.

O exemplo a seguir descreve um pipeline de dados operacionais que grava preços de produtos em um sistema PCM. O PCM é o sistema autoritativo para informações de produtos relacionados a vendas, como cores, canais de vendas, preço e periodicidade. Veja o fluxo completo de dados:

  • Os dados relacionados a preços estão disponíveis em várias origens. Eles podem incluir o preço atual por região do PCM, o preço do concorrente de um serviço de terceiros, a previsão de demanda e a confiabilidade do fornecedor em sistemas internos, e assim por diante.
  • Um pipeline de ETL extrai os dados das origens, os transforma e grava o resultado no armazenamento de dados. A transformação, nesse caso, é um cálculo complexo envolvendo todas as origens com o objetivo de produzir um preço base ideal para cada produto no PCM.
  • Por fim, o pipeline operacional pega os preços base do data warehouse, realiza transformações leves para ajustar os preços de eventos sazonais e grava os preços finais de volta no PCM.

Alimentação do sistema PCM no sistema ETL.

Figura 6. Um pipeline de dados operacionais que grava preços de produtos em um sistema PCM.

Um pipeline de dados operacional é um tipo de processo downstream, enquanto pipelines de dados que implementam ETL, ELT ou CDC são processos upstream. Porém, é possível que as ferramentas usadas para implementar se sobreponham. Por exemplo, é possível usar o Dataflow para definir e executar todos os DAGs de processamento de dados, o GoogleSQL para definir transformações executadas no BigQuery, e o Cloud Composer para orquestrar o fluxo de dados de ponta a ponta.

Como escolher uma abordagem de migração

Nesta seção, você verá diferentes abordagens que podem ser adotadas para migrar os pipelines de dados.

Redirecionar os pipelines de dados para gravar no BigQuery

Nas condições a seguir, considere se uma tecnologia usada oferece um coletor integrado do BigQuery (conector de gravação):

  • O data warehouse legado é alimentado por pipelines de dados que executam um procedimento de ETL.
  • A lógica de transformação é executada antes de armazenar os dados no data warehouse.

Fornecedores independentes de software (ISV) oferecem tecnologias de processamento de dados com conectores do BigQuery, como os seguintes:

Se a tecnologia de pipeline de dados não for compatível com a ingestão de dados no BigQuery, use uma variação dessa abordagem que grave os dados temporariamente em arquivos posteriormente ingeridos pelo BigQuery.

O pipeline de dados que está impedido de alimentar o sistema legado e alimenta o BigQuery.

Figura 7. Reescrita ou reconfiguração da última função de um pipeline de dados para gravar dados no BigQuery.

Em geral, o trabalho foi de reescrever ou reconfigurar a última função do pipeline de dados para gravar dados no BigQuery. Porém, há diversas opções que podem exigir outras alterações ou novos trabalhos, por exemplo:

Funcional

  • Mapeamentos de dados: como o esquema da tabela de banco de dados de destino pode ser alterado, talvez seja necessário reconfigurar esses mapeamentos.
  • Validação da métrica: é preciso validar relatórios antigos e novos, porque o esquema e as consultas podem ser alterados.

Não funcional

  • Talvez seja necessário configurar os firewalls para permitir a transferência de dados de saída do local para o BigQuery.
  • Alterações de rede podem ser necessárias para criar largura de banda adicional e acomodar a transferência de dados de saída.

Redirecionar os pipelines de dados usando arquivos como um veículo intermediário

Quando a tecnologia de pipeline de dados locais atual não for compatível com APIs do Google ou se você não puder usar APIs do Google, use arquivos como um veículo intermediário para que seus dados alcancem o BigQuery.

Essa abordagem é semelhante a de redirecionamento, mas, em vez de usar um coletor nativo capaz de gravar no BigQuery, use um coletor que possa gravar em um sistema de arquivos local. Quando os dados estiverem no sistema de arquivos, copie os arquivos para o Cloud Storage. Para mais detalhes, consulte a visão geral das opções de ingestão do Cloud Storage e os critérios envolvidos na escolha de uma opção de ingestão.

A etapa final é carregar os dados do Cloud Storage no BigQuery seguindo as diretrizes em Carregamento de dados em lote.

O diagrama a seguir mostra a abordagem descrita nesta seção.

Pipeline de ETL que alimenta um sistema de arquivos em vez do armazenamento de dados legado. O sistema de arquivos, por sua vez, alimenta o Cloud Storage e, dali, o BigQuery.

Figura 8. Redirecionamento de pipelines de dados usando arquivos como um veículo intermediário.

Com relação à orquestração do pipeline de ETL, é preciso executar dois passos separados:

  1. Reutilize a orquestração do pipeline local atual para gravar os dados transformados no sistema de arquivos. Estenda essa orquestração para copiar os arquivos do sistema de arquivos local para o Cloud Storage ou crie outro script que seja executado regularmente para realizar a cópia.
  2. Quando os dados estiverem no Cloud Storage, use uma transferência do Cloud Storage para programar cargas recorrentes do Cloud Storage para o BigQuery. As alternativas às transferências do Cloud Storage são os gatilhos do Cloud Storage e o Cloud Composer.

Na Figura 8, observe como também é possível que a orquestração no Google Cloud use um modelo de pull recuperando os arquivos com um protocolo como o SFTP.

Migrar pipelines de ELT para o BigQuery

Os pipelines de ELT consistem em duas partes: a parte que carrega os dados no armazenamento de dados e a parte que transforma os dados usando SQL para que possam ser consumidos downstream. Ao migrar os pipelines de ELT, cada uma dessas partes tem sua própria abordagem para a migração.

Para a parte que carrega dados no data warehouse (a parte de EL), siga as diretrizes na seção de pipelines de dados de redirecionamento, exceto as orientações sobre transformações, que não fazem parte de um pipeline de EL.

Se as origens de dados forem compatíveis com o serviço de transferência de dados do BigQuery (DTS), de maneira direta ou por meio de integrações de terceiros, será possível usar o DTS para substituir o pipeline de EL.

Como migrar pipelines de dados de OSS para o Dataproc

Ao migrar o pipeline de dados para o Google Cloud, convém migrar alguns jobs legados escritos com um framework de software de código aberto, como Apache Hadoop, Apache Spark ou Apache Flink.

O Dataproc permite implantar clusters do Hadoop e do Spark rápidos, fáceis de usar e totalmente gerenciados de maneira simples e econômica. O Dataproc se integra ao conector do BigQuery, uma biblioteca Java que permite que o Hadoop e o Spark gravem dados diretamente no BigQuery usando versões abstratas das classes InputFormat e OutputFormat do Apache Hadoop.

O Dataproc facilita a criação e a exclusão de clusters para que, em vez de usar um cluster monolítico, seja possível usar muitos clusters efêmeros. Essa abordagem tem várias vantagens:

  • É possível usar configurações de cluster diferentes nos jobs individuais, eliminando a carga administrativa de gerenciar ferramentas em jobs.
  • É possível escalonar clusters para que se adaptem a jobs individuais ou a grupos de jobs.
  • Você paga pelos recursos apenas quando estão sendo usados pelos jobs.
  • Você não precisa manter clusters ao longo do tempo, porque eles são configurados novamente a cada uso.
  • Você não precisa manter uma infraestrutura separada para desenvolvimento, teste e produção. Caso precise de diferentes versões de um cluster, é possível usar as mesmas definições para criar quantas versões diferentes quanto forem necessárias.

Ao migrar jobs, recomenda-se a adoção de uma abordagem incremental. A migração de maneira incremental permite fazer o seguinte:

  • isolar jobs individuais na infraestrutura atual do Hadoop a partir da complexidade inerente a um ambiente maduro;
  • examinar cada job isoladamente para avaliar as necessidades dele e determinar o melhor caminho para a migração;
  • lidar com problemas inesperados à medida que surgem sem atrasar tarefas dependentes;
  • criar uma prova de conceito para cada processo complexo sem afetar o ambiente de produção;
  • mudar os jobs para o modelo efêmero recomendado de maneira estratégica e deliberada.

Ao migrar os jobs do Hadoop e do Spark para o Dataproc, é possível verificar se as dependências dos jobs são cobertas pelas versões compatíveis do Dataproc. Se você precisar instalar um software personalizado, crie sua própria imagem do Dataproc usando algumas das ações de inicialização disponíveis (por exemplo, para o Apache Flink), gravando sua própria ação de inicialização ou especificando os requisitos personalizados do pacote Python.

Para começar, consulte os guias de início rápido do Dataproc e os exemplos de código do conector do BigQuery. Consulte também os guias sobre como migrar jobs do Hadoop do local para o Dataproc e como migrar jobs do Apache Spark para o Dataproc.

Re-hospedar pipelines de dados de terceiros no Google Cloud

Um cenário comum ao criar pipelines de dados no local é usar software de terceiros para gerenciar a execução do pipeline e a alocação de recursos de computação.

Para mover esses pipelines para a nuvem, há várias alternativas, dependendo dos recursos do software usado e, além dos termos de licenciamento, suporte e manutenção.

Nas seções a seguir, você verá algumas dessas alternativas.

Em um nível alto, você tem as seguintes alternativas para executar seu software de terceiros no Google Cloud, da menos para a mais complexa:

  • O fornecedor de software fez uma parceria com o Google Cloud para oferecer o software no Google Cloud Marketplace.
  • O fornecedor de software de terceiros pode ser executado no Kubernetes (em inglês).
  • O software de terceiros é executado em uma ou mais máquinas virtuais (VMs).

Se o software de terceiros fornecer uma solução do Cloud Marketplace, o trabalho será o seguinte:

Essa alternativa é a mais simples porque integra os pipelines de dados à nuvem usando a plataforma conhecida oferecida pelo fornecedor. Talvez seja possível que você também use ferramentas de proprietário de seu fornecedor para facilitar a migração entre o ambiente original e o novo no Google Cloud.

Se o fornecedor não fornecer uma solução do Cloud Marketplace, mas o produto dele puder ser executado no Kubernetes, use o Google Kubernetes Engine (GKE) para hospedar os pipelines. Os trabalhos são os seguintes:

  • Crie um cluster do GKE seguindo as recomendações do fornecedor para garantir que o produto de terceiros aproveite o carregamento de tarefas em paralelo oferecido pelo Kubernetes.
  • Instale o software de terceiros no cluster do GKE seguindo as recomendações do fornecedor.
  • Selecione e migre os casos de uso seguindo a abordagem iterativa explicada em Visão geral da migração de data warehouses para o BigQuery.

Essa alternativa fornece um meio termo quanto à complexidade. Ela aproveita o suporte nativo do fornecedor para o Kubernetes de modo a escalonar e carregar em paralelo a execução dos pipelines. Porém, é necessário criar e gerenciar um cluster do GKE.

Se o fornecedor não for compatível com o Kubernetes, será preciso instalar o software em um pool de VMs para ativar o dimensionamento e o carregamento em paralelo do trabalho. Se o software do fornecedor for nativamente compatível com a distribuição de trabalho para várias VMs, use essas instalações, possivelmente agrupando as instâncias de VM em um grupo de instâncias gerenciadas (MIG) para escalonar conforme necessário.

Lidar com o carregamento em paralelo do trabalho não é comum. Se o fornecedor não fornecer recursos para a distribuição de tarefas em VMs diferentes, é recomendável usar um padrão de criação de tarefas para distribuir o trabalho para VMs em um MIG. O diagrama a seguir é uma ilustração dessa abordagem.

Várias entradas vão para o Pub/Sub, que cria tópicos. Os tópicos são lidos por MIGs diferentes.

Figura 9. Um grupo de instâncias gerenciadas (MIG) com três VMs.

Neste diagrama, cada VM no MIG executa o software do pipeline de terceiros. É possível acionar a execução de um pipeline de várias maneiras:

Em resumo, todos esses métodos enviam uma mensagem a um tópico do Pub/Sub predefinido. Você cria um agente simples para ser instalado em cada VM. O agente escuta um ou mais tópicos do Pub/Sub. Sempre que uma mensagem chega ao tópico, o agente efetua pull na mensagem do tópico, inicia um pipeline no software de terceiros e detecta a conclusão dele. Quando o pipeline é concluído, o agente recupera a próxima mensagem dos tópicos que está escutando.

Em todos os cenários, recomendamos que você trabalhe com seu fornecedor para obedecer aos devidos termos de licenciamento para que seus pipelines funcionem no Google Cloud.

Regravar pipelines de dados para usar serviços gerenciados pelo Google Cloud

Em alguns casos, é possível optar por regravar alguns dos pipelines de dados para que usem novos frameworks e serviços totalmente gerenciados no Google Cloud. Essa opção funciona bem se os pipelines tiverem sido originalmente implementados com tecnologias já obsoletas ou se você previr que a portar e continuar a manter esses pipelines não modificados na nuvem seria pouco prático ou caro demais.

As seções a seguir apresentam serviços totalmente gerenciados do Google Cloud que permitem realizar transformações avançadas de dados em escala: o Cloud Data Fusion e o Dataflow.

Cloud Data Fusion

O Cloud Data Fusion, criado no projeto CDAP de código aberto, é um serviço de integração de dados totalmente gerenciado para criar e gerenciar pipelines de dados por meio de uma interface gráfica.

Os pipelines de dados são desenvolvidos na IU do Cloud Data Fusion conectando origens a transformações, coletores e outros nós para formar um DAG. Ao implantar o pipeline de dados, o planejador do Cloud Data Fusion transforma esse DAG em uma série de cálculos paralelos que serão executados como um job do Apache Spark no Dataproc.

Ao usar o Cloud Data Fusion, é possível se conectar ao banco de dados de um sistema de origem usando os drivers Java Database Connectivity (JDBC) para ler, transformar e carregar dados no destino de sua preferência, por exemplo, no BigQuery. sem ter que escrever qualquer código. Para fazer isso, faça o upload de um driver JDBC para a instância do Cloud Data Fusion e configure-o para ser usado nos pipelines de dados. Para mais detalhes, consulte o guia sobre como usar drivers JDBC com o Cloud Data Fusion.

O Cloud Data Fusion expõe plug-ins para origens, transformações, agregações, coletores, coletores de erros, editores de alertas, ações e ações pós-execução como componentes personalizáveis. Os plug-ins pré-construídos oferecem acesso a uma ampla gama de origens de dados. Caso um plug-in não exista, é possível criar seu próprio plug-in usando as APIs de plug-in do Cloud Data Fusion. Para mais informações, consulte a Visão geral do plug-in.

Com os pipelines do Cloud Data Fusion, é possível criar pipelines de dados em lote e streaming. Ao fornecer acesso a registros e métricas, os pipelines de dados também oferecem maneiras para que os administradores operacionalizem seus fluxos de trabalho de processamento de dados sem precisar de ferramentas personalizadas.

Para começar, consulte a visão geral conceitual Cloud Data Fusion. Para exemplos práticos, consulte o guia de início rápido e o tutorial sobre como criar um pipeline de campanha de segmentação.

Dataflow

O Dataflow é um serviço totalmente gerenciado para executar jobs do Apache Beam em escala. O Apache Beam é um framework de código aberto que fornece um conjunto avançado de primitivos de gestão janelas e de análise de sessão, além de um ecossistema de conectores de origem e de coletor, incluindo um conector para o BigQuery (em inglês). O Apache Beam permite transformar e enriquecer dados nos modos de fluxo (tempo real) e lote (histórico) com a mesma confiabilidade e expressividade.

A abordagem sem servidor do Dataflow remove a sobrecarga operacional com desempenho, escalonamento, disponibilidade, segurança e conformidade gerenciados automaticamente. Isso permite que você se concentre na programação em vez de gerenciar clusters de servidor.

É possível enviar jobs do Dataflow de maneiras diferentes, por meio da interface da linha de comando, do SDK do Java (em inglês) ou do SDK do Python (em inglês). Além disso, estamos desenvolvendo um framework de portabilidade para oferecer total interoperabilidade entre todos os SDKs e executores.

Caso queira migrar as consultas e os pipelines de dados de outros frameworks para o Apache Beam e o Dataflow, leia sobre o modelo de programação do Apache Beam e acesse a documentação oficial do Dataflow.

Para exemplos práticos, consulte os guias de início rápido e os tutoriais do Dataflow.

Orquestração e programação

Em um nível alto, a orquestração é a coordenação automatizada de vários sistemas, enquanto a programação se refere ao acionamento automático do trabalho de orquestração.

  • Aumentando o zoom: um pipeline de dados é, por si só, uma orquestração de transformações de dados descrita por um DAG, que é um DAG de processamento de dados.
  • Diminuindo zoom: quando um pipeline de dados depende da saída de outros pipelines de dados, orquestração de vários pipelines é necessária. Cada pipeline constitui um sub-DAG em um DAG maior, que é um DAG de orquestração.

Essa configuração é típica no armazenamento de dados. A figura 1 na seção de ETL mostra um exemplo de configuração. Nas seções a seguir, o foco é a orquestração de vários pipelines de dados.

Dependências

Dependências podem ser fan-in, em que vários pipelines de dados se mesclam em um vértice de um DAG de orquestração, fan-out, em que um único pipeline de dados aciona vários outros ou, com frequência, ambos, como mostrado no diagrama a seguir.

Vários pipelines rotulados A, B e C são distribuídos para o pipeline D. O pipeline D distribui para os pipelines E, F e G. Tudo isso é orquestrado por um DAG de orquestração.

Figura 10. Dependências de fan-in e fan-out usadas em combinação.

Em ambientes não ideais, algumas dependências são resultado de limitações na quantidade de recursos disponíveis. Por exemplo, um pipeline de dados é executado e produz alguns dados comuns como subproduto. Outros pipelines de dados dependem desses dados comuns simplesmente para evitar o recálculo, mas não estão relacionados ao pipeline que criou os dados. Se esse primeiro pipeline encontrar problemas funcionais ou não funcionais, as falhas se propagarão em cascata até os pipelines de dados dependentes — na melhor das hipóteses, forçando-os a aguardar ou, na pior, impedindo que eles sejam executados, como mostrado no diagrama a seguir.

O pipeline A falha. Os pipelines B e C dependem da saída do pipeline A. Então, eles também falham.

Figura 11. Falhas se propagando em um pipeline de dados impedem a execução de pipelines dependentes.

No Google Cloud, há diversos recursos de computação e ferramentas especializadas disponíveis para otimizar a execução dos pipelines e a orquestração deles. Nas seções restantes, esses recursos e ferramentas são discutidos.

Trabalho de migração envolvido

É uma prática recomendada simplificar as necessidades de orquestração. A orquestração fica mais complexa com o número de dependências entre os pipelines de dados. A migração para o Google Cloud apresenta uma oportunidade de examinar os DAGs de orquestração, identificar as dependências e determinar como otimizá-las.

É recomendável otimizar as dependências incrementalmente, da seguinte maneira:

  1. Em uma primeira iteração, mova a orquestração como estiver para o Google Cloud.
  2. Nas iterações seguintes, analise as dependências e carregue-as em paralelo, se possível.
  3. Por fim, reorganize a orquestração extraindo tarefas comuns nos próprios DAGs.

Na próxima seção, esse método é explicado com um exemplo prático.

Um exemplo prático

Suponha que uma organização tenha dois pipelines relacionados:

  • O primeiro pipeline calcula os lucros e perdas (P&L, na sigla em inglês) para toda a organização. É um pipeline complexo que envolve muitas transformações. Parte do pipeline consiste no cálculo das vendas mensais, que são usadas nos passos de transformação subsequentes e, por fim, gravadas em uma tabela.
  • O segundo pipeline calcula o crescimento das vendas a cada ano ou mês para diferentes produtos, de modo que o departamento de marketing possa ajustar os esforços de campanha publicitária. Esse pipeline precisa dos dados mensais de vendas previamente calculados pelo pipeline de dados de P&L.

A organização considera que o pipeline de dados de P&L tem prioridade mais alta que o de marketing. Infelizmente, como o P&L é um pipeline de dados complexo, ele consome uma grande quantidade de recursos, impedindo que outros pipelines sejam executados simultaneamente. Além disso, se o pipeline de P&L falhar, o pipeline de marketing e outros pipelines dependentes não terão os dados necessários para serem executados e precisarão aguardar uma nova tentativa de P&L. O diagrama a seguir ilustra essa situação.

O pipeline de P&L cria um artefato de "vendas mensais" necessário para o pipeline de marketing. É possível que o pipeline de P&L apresente atrasos e outros problemas.

Figura 12. Pipelines de dados complexos podem impedir a execução de pipelines com prioridade inferior.

A organização está migrando para o BigQuery. Ela identificou os dois casos de uso (P& L e crescimento das vendas de marketing) e os incluiu no backlog de migração. Ao planejar a próxima iteração, a organização prioriza o caso de uso de P&L e a inclui na lista de pendências das iterações porque ela está muito limitada pelos recursos no local atuais e causa atrasos regularmente. Alguns dos casos de uso dependentes também estão inclusos, entre eles o caso de uso de marketing.

A equipe de migração executa a primeira iteração. Eles optam por mover os casos de uso de P&L e de marketing para o Google Cloud usando uma abordagem de redirecionamento. Não fazem alterações nos passos nem na orquestração do pipeline. Uma diferença importante é que, agora, o pipeline de P&L tem uma capacidade de computação quase ilimitada e, portanto, a execução é muito mais rápida do que no local. O pipeline grava os dados mensais de vendas em uma tabela do BigQuery usada pelo pipeline de crescimento de marketing. O diagrama a seguir ilustra essas alterações.

O pipeline de P&L é o mesmo de antes, mas não apresenta atrasos.

Figura 13. Aceleração de um pipeline de dados complexo usando uma abordagem de redirecionamento.

Embora o Google Cloud tenha ajudado com os problemas não funcionais de P&L, os problemas funcionais ainda permanecem. Com frequência, algumas tarefas não relacionadas que precedem o cálculo das vendas mensais causam erros que o impedem que o cálculo aconteça e fazem com que os pipelines dependentes não sejam iniciados.

Em uma segunda iteração, a equipe espera melhorar o desempenho, incluindo os dois casos de uso no backlog da iteração. A equipe identifica os passos do pipeline para calcular as vendas mensais no pipeline de P&L. Esses passos se constituem de um sub-DAG, como mostrado no próximo diagrama. A equipe de migração copia o sub-DAG para o pipeline de marketing para que esse pipeline seja executado independentemente de P&L. Ter capacidade de computação suficiente no Google Cloud permite que ambos os pipelines sejam executados simultaneamente.

Agora, o pipeline de P&L e o pipeline de marketing são executados como sub-DAGs separados, de modo que o pipeline de marketing não será mais afetado se houver problemas no pipeline de P&L.

Figura 14. Pipelines em execução simultânea usando um sub-DAG.

A desvantagem é que a duplicação da lógica do sub-DAG cria sobrecarga de gerenciamento de código, porque, agora, a equipe precisa manter as duas cópias da lógica do sub-DAG em sincronia.

Em uma terceira iteração, a equipe revisita os casos de uso e extrai o sub-DAG mensal de vendas em um pipeline independente. Quando o novo pipeline de vendas mensais é concluído, ele aciona ou distribui os dados para o P&L, o crescimento do marketing e outros pipelines dependentes. Essa configuração cria um novo DAG de orquestração geral, sendo cada pipeline um dos sub-DAGs.

Agora, o pipeline de vendas mensais é o primeiro, alimentando o pipeline de P&L e o pipeline de marketing.

Figura 15. DAG de orquestração geral com cada pipeline no próprio sub-DAG.

Nas iterações subsequentes, a equipe de migração será capaz de resolver quaisquer problemas funcionais restantes e migrar os pipelines para usar os seguintes serviços gerenciados pelo Google Cloud, entre outros:

Embora o Airflow seja compatível com sub-DAGs de forma nativa, essa funcionalidade não é recomendada porque pode limitar seu desempenho. No lugar, use DAGs independentes com o operador TriggerDagRunOperator.

A seguir

Saiba mais sobre as seguintes etapas na migração do armazenamento de dados:

Também é possível aprender sobre a migração de tecnologias específicas do data warehouse para o BigQuery: