Migre data pipelines

Este documento descreve como pode migrar os seus pipelines de dados a montante, que carregam dados no seu data warehouse. Pode usar este documento para compreender melhor o que é um pipeline de dados, que procedimentos e padrões um pipeline pode usar e que opções e tecnologias de migração estão disponíveis para uma migração de armazém de dados.

O que é um pipeline de dados?

Na informática, um pipeline de dados é um tipo de aplicação que processa dados através de uma sequência de passos de processamento associados. Como conceito geral, os pipelines de dados podem ser aplicados, por exemplo, à transferência de dados entre sistemas de informação, à extração, transformação e carregamento (ETL), ao enriquecimento de dados e à análise de dados em tempo real. Normalmente, os pipelines de dados são operados como um processo de lote que executa e processa dados quando é executado ou como um processo de streaming que é executado continuamente e processa dados à medida que ficam disponíveis para o pipeline.

No contexto do armazenamento de dados, os pipelines de dados são usados frequentemente para ler dados de sistemas transacionais, aplicar transformações e, em seguida, escrever dados no armazém de dados. Cada uma das transformações é descrita por uma função e a entrada para qualquer função específica é a saída da função ou das funções anteriores. Estas funções associadas são descritas como um gráfico e este gráfico é frequentemente denominado gráfico acíclico orientado (DAG), ou seja, o gráfico segue uma direção (da origem ao destino) e é acíclico. A entrada de qualquer função não pode depender do resultado de outra função a jusante no DAG. Por outras palavras, não são permitidos ciclos. Cada nó do gráfico é uma função e cada aresta representa os dados que fluem de uma função para a seguinte. As funções iniciais são origens ou ligações a sistemas de dados de origem. As funções finais são destinos ou ligações a sistemas de dados de destino.

No contexto dos pipelines de dados, as origens são normalmente sistemas transacionais, por exemplo, um RDBMS, e o destino estabelece ligação a um armazém de dados. Este tipo de gráfico é denominado DAG de fluxo de dados. Também pode usar DAGs para orquestrar o movimento de dados entre pipelines de dados e outros sistemas. Esta utilização é denominada orquestração ou DAG de fluxo de controlo.

Quando migrar os pipelines de dados

Quando migra um exemplo de utilização para o BigQuery, pode optar por transferir ou migrar totalmente.

Por um lado, quando descarrega um exemplo de utilização, não tem de migrar os respetivos pipelines de dados a montante antecipadamente. Primeiro, migre o esquema e os dados do exemplo de utilização do seu armazém de dados existente para o BigQuery. Em seguida, estabelece uma cópia incremental do antigo para o novo data warehouse para manter os dados sincronizados. Por último, migre e valide os processos a jusante, como scripts, consultas, painéis de controlo e aplicações empresariais.

Neste ponto, os seus pipelines de dados a montante permanecem inalterados e continuam a escrever dados no seu data warehouse existente. Pode incluir novamente os exemplos de utilização transferidos na lista de pendências da migração para serem totalmente migrados numa iteração subsequente.

Por outro lado, quando migra totalmente um exemplo de utilização, os pipelines de dados a montante necessários para o exemplo de utilização são migrados para o Google Cloud. A migração completa requer que descarregue primeiro o exemplo de utilização. Após a migração completa, pode descontinuar as tabelas antigas correspondentes do armazém de dados nas instalações, uma vez que os dados são carregados diretamente para o BigQuery.

Durante uma iteração, pode escolher uma das seguintes opções:

  • Transfira apenas o seu exemplo de utilização.
  • Migrar totalmente um exemplo de utilização que foi anteriormente descarregado.
  • Migre totalmente um exemplo de utilização desde o início, descarregando-o primeiro na mesma iteração.

Quando todos os seus exemplos de utilização estiverem totalmente migrados, pode optar por desativar o armazém antigo, o que é um passo importante para reduzir as despesas gerais e os custos.

Como migrar os pipelines de dados

O resto deste documento aborda a forma de migrar os pipelines de dados, incluindo a abordagem e os procedimentos a usar, bem como as tecnologias a empregar. As opções variam desde a reutilização de pipelines de dados existentes (redirecionando-os para carregar para o BigQuery) até à reescrita dos pipelines de dados para tirar partido dos serviços geridos pela Google CloudGoogle.

Procedimentos e padrões para pipelines de dados

Pode usar pipelines de dados para executar vários procedimentos e padrões. Estes pipelines são os mais usados no armazenamento de dados. Pode ter pipelines de dados em lote ou pipelines de dados de streaming. Os pipelines de dados em lote são executados em dados recolhidos durante um período (por exemplo, uma vez por dia). Os pipelines de dados de streaming processam eventos em tempo real gerados pelos seus sistemas operacionais, por exemplo, alterações de linhas de CDC geradas pelas suas bases de dados de processamento de transações online (OLTP).

Extrair, transformar e carregar (ETL)

No contexto do armazenamento de dados, os pipelines de dados executam frequentemente um procedimento de extração, transformação e carregamento (ETL). As tecnologias ETL são executadas fora do armazém de dados, o que significa que os recursos do armazém de dados podem ser usados principalmente para consultas simultâneas, em vez de para preparar e transformar dados. Uma desvantagem da execução da transformação fora do data warehouse é que requer que aprenda ferramentas e linguagens adicionais (além do SQL) para expressar as transformações.

O diagrama seguinte mostra um procedimento de ETL típico.

Fluxo que mostra a origem (extração) a passar por uma ou mais transformações (transformação), depois para um destino e, finalmente, para um armazém de dados (carregamento)

Figura 1. Um procedimento ETL típico.

Um pipeline de dados ETL típico extrai dados de um ou mais sistemas de origem (de preferência, o menor número possível para evitar falhas causadas por problemas como sistemas indisponíveis). Em seguida, o pipeline executa uma série de transformações, incluindo a limpeza de dados, a aplicação de regras empresariais, a verificação da integridade dos dados e a criação de dados agregados ou desagregados. Para mais informações, consulte o artigo Ciclo de ETL na vida real.

É comum ter vários pipelines de dados. O primeiro pipeline foca-se na cópia de dados do sistema de origem para o data warehouse. Os pipelines subsequentes aplicam lógica empresarial e transformam os dados para utilização em vários data marts, que são subconjuntos do data warehouse focados numa unidade de negócio específica ou num foco empresarial.

Quando tem vários pipelines de dados, tem de os orquestrar. O diagrama seguinte mostra o aspeto que este processo de orquestração pode ter.

Orchestrator (DAG) a gerir dois processos ETL (DAGs secundários)

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 mais amplo, por exemplo, preparar dados para uma unidade de negócio para que os analistas de negócios possam executar os respetivos painéis de controlo ou relatórios.

Extrair, carregar e transformar (ELT)

O ELT é uma alternativa ao ETL. Com a ELT, o pipeline de dados é dividido em duas partes. Primeiro, uma tecnologia ELT extrai os dados do sistema de origem e carrega-os no armazém de dados. Em segundo lugar, os scripts SQL na parte superior do armazém de dados executam as transformações. A vantagem desta abordagem é que pode usar SQL para expressar as transformações. A desvantagem é que pode consumir recursos do armazém de dados necessários para consultas simultâneas. Por este motivo, os lotes de ELT são frequentemente executados durante a noite (ou fora de horas) quando os recursos do sistema do data warehouse estão menos solicitados.

O diagrama seguinte mostra um procedimento de ELT típico.

Fluxo que mostra a origem (extração) a passar por uma ou mais transformações (transformação), depois para um destino e, finalmente, para um armazém de dados (carregamento).

Figura 3. Um procedimento ELT típico.

Quando adota uma abordagem ELT, é comum separar a extração e o carregamento num DAG e as transformações nos seus próprios DAGs. Os dados são carregados no data warehouse uma vez e, em seguida, transformados várias vezes para criar as diferentes tabelas que são usadas a jusante nos relatórios, etc. Estes DAGs, por sua vez, tornam-se sub-DAGs num DAG de orquestração maior (conforme mostrado na secção ETL).

Quando migra pipelines de dados de um armazém de dados nas instalações congestionado para a nuvem, é importante lembrar que os sistemas de armazém de dados na nuvem, como o BigQuery, são tecnologias de processamento de dados massivamente paralelas. Na verdade, no caso do BigQuery, pode comprar mais recursos para suportar o aumento das exigências de ELT e de consultas simultâneas. Para mais informações, consulte a Introdução à otimização do desempenho das consultas.

Extrair e carregar (EL)

Pode usar o procedimento de extração e carregamento (EL) de forma independente ou seguido de transformações, caso em que se torna ELT. A EL é mencionada separadamente porque existem vários serviços automatizados que realizam esta tarefa, o que mitiga a necessidade de criar o 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 captura de dados de alterações (CDC) é um dos vários padrões de design de software usados para acompanhar as alterações de dados. É frequentemente usado no armazenamento de dados porque o armazém de dados é usado para reunir e monitorizar dados e as respetivas alterações de vários sistemas de origem ao longo do tempo.

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

Fluxo de ETL que mostra registos individuais com informações de versão atribuídas na extração e indicações de tempo adicionadas no carregamento.

Figura 4. Como a CDC funciona com a ELT.

A CDC funciona bem com a ELT porque quer armazenar o registo original antes de fazer alterações a jusante.

Para que a parte EL aconteça, pode processar registos da base de dados através de software de CDC, como o Datastream, ou ferramentas de código aberto, como o Debezium, e escrever os registos no BigQuery através do Dataflow. Em seguida, pode usar uma consulta SQL para determinar a versão mais recente antes de aplicar mais transformações. Segue-se 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

Quando refatorar ou criar novos pipelines de dados, considere usar o padrão de CDC aplicado como um procedimento de ELT. Esta abordagem garante que tem um histórico completo das alterações de dados a montante e oferece uma boa segregação de responsabilidades, por exemplo:

  • As equipas do sistema de origem garantem a disponibilidade dos respetivos registos e a publicação dos respetivos eventos de dados.
  • A equipa da plataforma de dados garante que a ordenação da ingestão dos registos originais inclui datas/horas no armazém de dados.
  • As equipas de engenharia de dados e de analistas agendam uma série de transformações para preencher os respetivos data marts.

Ciclos de feedback com pipelines de dados operacionais

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

Os sistemas operacionais referem-se a sistemas que processam as transações diárias da organização, como bases de dados OLTP, sistemas de gestão das relações com clientes (CRM), sistemas de gestão de catálogos de produtos (PCM), entre outros. Uma vez que estes sistemas atuam frequentemente 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 operacional é apresentado no diagrama seguinte.

Pipeline ETL que alimenta um armazém de dados e, em seguida, um pipeline operacional que alimenta o sistema de origem que alimenta o pipeline ETL.

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

O exemplo seguinte descreve um pipeline de dados operacional que escreve os preços dos produtos num sistema PCM. Um sistema PCM é o sistema autoritário para informações de produtos relacionadas com vendas, como cores, canais de vendas, preço e sazonalidade. Segue-se o fluxo de dados completo:

  • Os dados relacionados com os preços estão disponíveis a partir de várias origens. Estes dados podem incluir o preço atual por região do PCM, os preços dos concorrentes de um serviço de terceiros, a previsão da procura e a fiabilidade dos fornecedores de sistemas internos, entre outros.
  • Um pipeline de ETL extrai os dados das origens, transforma-os e escreve o resultado no armazém de dados. Neste caso, a transformação é um cálculo complexo que envolve todas as origens com o objetivo de produzir um preço base ideal para cada produto no PCM.
  • Por último, o pipeline operacional obtém os preços base do armazém de dados, faz transformações simples para ajustar os preços a eventos sazonais e escreve os preços finais de volta no PCM.

Sistema PCM que alimenta o sistema ETL.

Figura 6. Um pipeline de dados operacional que escreve os preços dos produtos num sistema de PCM.

Um pipeline de dados operacional é um tipo de processo a jusante, enquanto os pipelines de dados que implementam ETL, ELT ou CDC são processos a montante. No entanto, as ferramentas usadas para implementar ambas podem sobrepor-se. Por exemplo, pode usar o Dataflow para definir e executar todos os DAGs de processamento de dados, o GoogleSQL para definir transformações que são executadas no BigQuery e o Cloud Composer para orquestrar o fluxo de dados completo.

Escolher uma abordagem de migração

Esta secção descreve diferentes abordagens que pode adotar para migrar os seus pipelines de dados.

Redirecione pipelines de dados para escrever no BigQuery

Nas seguintes condições, pode considerar se uma tecnologia que usa oferece um destino do BigQuery incorporado (conetor de gravação):

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

Os fornecedores de software independentes (ISV) oferecem tecnologias de processamento de dados com conetores do BigQuery, incluindo o seguinte:

Se a tecnologia de pipeline de dados não suportar o carregamento de dados para o BigQuery, considere usar uma variação desta abordagem que escreve os dados temporariamente em ficheiros que são posteriormente carregados pelo BigQuery.

Pipeline de dados que está bloqueada de ser introduzida no sistema antigo e, em vez disso, é introduzida no BigQuery.

Figura 7. Reescrever ou reconfigurar a última função de um pipeline de dados para escrever dados no BigQuery.

A um nível elevado, o trabalho envolvido diz respeito à reescrita ou à reconfiguração da última função do pipeline de dados para escrever dados no BigQuery. No entanto, tem várias opções que podem exigir alterações adicionais ou novo trabalho, por exemplo:

Funcional

  • Mapeamentos de dados: uma vez que o esquema da tabela da base de dados de destino pode mudar, pode ter de reconfigurar estes mapeamentos.
  • Validação de métricas: tem de validar os relatórios históricos e novos, porque o esquema e as consultas podem mudar.

Não funcional

  • Pode ser necessário configurar firewalls para permitir a transferência de dados de saída das instalações para o BigQuery.
  • Podem ser necessárias alterações à rede para criar largura de banda adicional, para acomodar a transferência de dados de saída.

Redirecione pipelines de dados usando ficheiros como um veículo intermédio

Quando a tecnologia de pipeline de dados no local existente não suporta as APIs Google ou se tiver restrições quanto à utilização das APIs Google, pode usar ficheiros como um veículo intermédio para que os seus dados cheguem ao BigQuery.

Esta abordagem é semelhante à abordagem de redirecionamento, mas, em vez de usar um destino nativo que possa escrever no BigQuery, usa um destino que possa escrever num sistema de ficheiros nas instalações. Quando os seus dados estão no sistema de ficheiros, pode copiar os ficheiros para o Cloud Storage. Para mais detalhes, consulte a vista geral das opções de carregamento para o Cloud Storage e os critérios envolvidos na escolha de uma opção de carregamento.

O passo final é carregar os dados do Cloud Storage para o BigQuery seguindo as diretrizes em Carregar dados em lote.

O diagrama seguinte mostra a abordagem descrita nesta secção.

Pipeline de ETL que alimenta um sistema de ficheiros em vez do armazém de dados antigo. O sistema de ficheiros, por sua vez, alimenta o Cloud Storage e, a partir daí, o BigQuery.

Figura 8. Redirecionar pipelines de dados através da utilização de ficheiros como veículo intermédio.

No que diz respeito à orquestração do pipeline de ETL, tem de executar dois passos separados:

  1. Reutilize a orquestração de pipeline no local existente para escrever os dados transformados no sistema de ficheiros. Estenda esta orquestração para copiar os ficheiros do seu sistema de ficheiros no local para o Cloud Storage ou crie um script adicional que seja executado regularmente para realizar o passo de cópia.
  2. Quando os dados estão no Cloud Storage, use uma transferência do Cloud Storage para agendar carregamentos recorrentes do Cloud Storage para o BigQuery. As alternativas às transferências do Cloud Storage são os acionadores do Cloud Storage e o Cloud Composer.

Na Figura 8, repare como também é possível que a orquestração emGoogle Cloud use um modelo de obtenção ao obter os ficheiros através de um protocolo, como o SFTP.

Migre pipelines ELT existentes para o BigQuery

Os pipelines ELT consistem em duas partes: a parte que carrega os dados no seu data warehouse e a parte que transforma os dados através de SQL para que possam ser consumidos a jusante. Quando migra pipelines ELT, cada uma destas partes tem a sua própria abordagem para a migração.

Para a parte que carrega dados no seu data warehouse (a parte EL), pode seguir as diretrizes na secção Redirecione pipelines de dados, exceto os conselhos sobre transformações, que não fazem parte de um pipeline EL.

Se as suas origens de dados forem suportadas pelo Serviço de transferência de dados do BigQuery (DTS) diretamente ou através de integrações de terceiros, pode usar o DTS para substituir o seu pipeline de EL.

Migrar pipelines de dados de OSS existentes para o Dataproc

Quando migra o seu pipeline de dados para o Google Cloud, pode querer migrar algumas tarefas antigas escritas com uma framework de software de código aberto, como o Apache Hadoop, o Apache Spark ou o Apache Flink.

O Dataproc permite implementar clusters Hadoop e Spark rápidos, fáceis de usar e totalmente geridos de uma forma simples e económica. O Dataproc integra-se com o conetor do BigQuery, uma biblioteca Java que permite ao Hadoop e ao Spark escrever dados diretamente no BigQuery através de versões abstratas das classes InputFormat e OutputFormat do Apache Hadoop.

O Dataproc facilita a criação e a eliminação de clusters para que, em vez de usar um cluster monolítico, possa usar muitos clusters efémeros. Esta abordagem tem várias vantagens:

  • Pode usar diferentes configurações de cluster para tarefas individuais, eliminando o encargo administrativo da gestão de ferramentas em várias tarefas.
  • Pode dimensionar clusters para se adequarem a tarefas individuais ou grupos de tarefas.
  • Só paga pelos recursos quando as suas tarefas os estão a usar.
  • Não precisa de manter os clusters ao longo do tempo, porque são configurados de novo sempre que os usa.
  • Não precisa de manter uma infraestrutura separada para desenvolvimento, testes e produção. Pode usar as mesmas definições para criar quantas versões diferentes de um cluster precisar quando precisar delas.

Quando migrar os seus trabalhos, recomendamos que adote uma abordagem incremental. Ao migrar de forma incremental, pode fazer o seguinte:

  • Isolar tarefas individuais na sua infraestrutura Hadoop existente da complexidade inerente a um ambiente desenvolvido.
  • Examine cada tarefa isoladamente para avaliar as respetivas necessidades e determinar o melhor caminho para a migração.
  • Resolva problemas inesperados à medida que surgem sem atrasar as tarefas dependentes.
  • Crie uma prova de conceito para cada processo complexo sem afetar o seu ambiente de produção.
  • Mova os seus trabalhos para o modelo efémero recomendado de forma ponderada e deliberada.

Quando migra as suas tarefas existentes do Hadoop e Spark para o Dataproc, pode verificar se as dependências das suas tarefas estão cobertas pelas versões do Dataproc suportadas. Se precisar de instalar software personalizado, pode considerar criar a sua própria imagem do Dataproc, usar algumas das ações de inicialização (por exemplo, para o Apache Flink), escrever a sua própria ação de inicialização ou especificar requisitos de pacotes Python personalizados.

Para começar, consulte os guias de início rápido do Dataproc e os exemplos de código do conetor do BigQuery.

Realoje pipelines de dados de terceiros para execução no Google Cloud

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

Para mover estes pipelines para a nuvem, tem várias alternativas, consoante as capacidades do software que está a usar e também consoante os termos de licenciamento, apoio técnico e manutenção.

As secções seguintes apresentam algumas destas alternativas.

De forma geral, tem as seguintes alternativas para executar o seu software de terceiros no Google Cloud, do menos para o mais complexo:

  • O seu fornecedor de software estabeleceu uma parceria com Google Cloud para oferecer o respetivo software no Google Cloud Marketplace.
  • O fornecedor de software de terceiros pode ser executado no Kubernetes.
  • O seu software de terceiros é executado numa ou mais máquinas virtuais (VMs).

Se o seu software de terceiros fornecer uma solução do Cloud Marketplace, o trabalho envolvido é o seguinte:

Esta alternativa é a mais simples porque integra os seus pipelines de dados na nuvem através da plataforma familiar fornecida pelo seu fornecedor. Também pode usar ferramentas proprietárias do seu fornecedor para facilitar a migração entre o ambiente original e o novo ambiente no Google Cloud.

Se o seu fornecedor não oferecer uma solução do Cloud Marketplace, mas o respetivo produto puder ser executado no Kubernetes, pode usar o Google Kubernetes Engine (GKE) para alojar os seus pipelines. O trabalho envolve o seguinte:

  • Crie um cluster do GKE seguindo as recomendações do seu fornecedor para garantir que o produto de terceiros pode tirar partido da paralelização de tarefas que o Kubernetes oferece.
  • Instale o software de terceiros no cluster do GKE seguindo as recomendações do fornecedor.
  • Selecione e migre os seus exemplos de utilização seguindo a abordagem iterativa explicada no artigo Migrar armazéns de dados para o BigQuery: vista geral.

Esta alternativa oferece um meio-termo em termos de complexidade. Tira partido do suporte nativo do fornecedor para o Kubernetes de modo a dimensionar e paralelizar a execução dos seus pipelines. No entanto, requer que crie e faça a gestão de um cluster do GKE.

Se o seu fornecedor não suportar o Kubernetes, tem de instalar o respetivo software num conjunto de VMs para ativar o aumento da escala e a paralelização do trabalho. Se o software do fornecedor suportar nativamente a distribuição de trabalho a várias VMs, use essas funcionalidades fornecidas, possivelmente agrupando as instâncias de VM num grupo de instâncias geridas (GIG) para aumentar e diminuir a escala conforme necessário.

O processamento da paralelização do trabalho não é trivial. Se o seu fornecedor não oferecer capacidades para distribuir tarefas a diferentes VMs, recomendamos que use um padrão de processamento de tarefas para distribuir o trabalho a VMs num MIG. O diagrama seguinte ilustra esta abordagem.

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

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

Neste diagrama, cada VM no MIG executa o software de pipeline de terceiros. Pode acionar a execução de um pipeline de várias formas:

Essencialmente, todos estes métodos enviam uma mensagem para um tópico do Pub/Sub predefinido. Cria um agente simples para ser instalado em cada VM. O agente ouve um ou mais tópicos do Pub/Sub. Sempre que chega uma mensagem ao tópico, o agente extrai a mensagem do tópico, inicia um pipeline no seu software de terceiros e aguarda a respetiva conclusão. Quando o pipeline estiver concluído, o agente obtém a mensagem seguinte dos tópicos que está a ouvir.

Em todos os cenários, recomendamos que trabalhe com o seu fornecedor para agir em conformidade com os termos de licenciamento adequados para que os seus pipelines funcionem no Google Cloud.

Reescreva pipelines de dados para usar serviços geridos pela Google Cloud

Em alguns casos, pode optar por reescrever alguns dos seus pipelines de dados existentes para usar novas estruturas e serviços totalmente geridos no Google Cloud. Esta opção funciona bem se os seus pipelines existentes tiverem sido originalmente implementados com tecnologias que já foram descontinuadas ou se prevê que a portabilidade e a manutenção desses pipelines inalterados na nuvem sejam demasiado impraticáveis ou dispendiosas.

As secções seguintes apresentam serviços totalmente geridos Google Cloud que lhe permitem fazer transformações de dados avançadas em grande escala: Cloud Data Fusion e Dataflow.

Cloud Data Fusion

O Cloud Data Fusion, criado com base no projeto de código aberto CDAP é um serviço de integração de dados totalmente gerido para criar e gerir pipelines de dados através de uma interface gráfica.

Desenvolve os pipelines de dados na IU do Cloud Data Fusion associando origens a transformações, destinos e outros nós para formar um DAG. Quando implementa o pipeline de dados, o planeador do Cloud Data Fusion transforma este DAG numa série de cálculos paralelos que são executados como uma tarefa do Apache Spark no Dataproc.

Quando usa o Cloud Data Fusion, pode ligar-se à base de dados de um sistema de origem através dos controladores Java Database Connectivity (JDBC) para ler dados, transformá-los e carregá-los num destino à sua escolha (por exemplo, o BigQuery), sem ter de escrever código. Para tal, tem de carregar um controlador JDBC para a sua instância do Cloud Data Fusion e configurá-lo para que o possa usar nos seus pipelines de dados. Para mais detalhes, consulte o guia sobre como usar controladores JDBC com o Cloud Data Fusion.

O Cloud Data Fusion expõe plug-ins para origens, transformações, agregações, destinos, coletores de erros, publicadores de alertas, ações e ações pós-execução como componentes personalizáveis. Os plug-ins pré-criados oferecem acesso a uma ampla gama de origens de dados. Se não existir um plug-in, pode criar o seu próprio plug-in através das APIs de plug-ins do Cloud Data Fusion. Para mais informações, consulte a Vista geral dos plug-ins.

Com os pipelines do Cloud Data Fusion, pode criar pipelines de dados em lote e de streaming. Ao fornecerem acesso a registos e métricas, os pipelines de dados também oferecem formas de os administradores operacionalizarem os respetivos fluxos de trabalho de processamento de dados sem precisarem de ferramentas personalizadas.

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

Dataflow

O Dataflow é um serviço totalmente gerido para executar tarefas do Apache Beam em grande escala. O Apache Beam é uma framework de código aberto que oferece um conjunto avançado de primitivas de análise de janelas e sessões, bem como um ecossistema de conetores de origens e destinos, incluindo um conetor para o BigQuery. O Apache Beam permite-lhe transformar e enriquecer dados nos modos de stream (tempo real) e de lote (histórico) com igual fiabilidade e expressividade.

A abordagem sem servidor do Dataflow remove a sobrecarga operacional com o desempenho, a escalabilidade, a disponibilidade, a segurança e a conformidade processados automaticamente. Isto permite-lhe focar-se na programação em vez de gerir clusters de servidores.

Pode enviar tarefas do Dataflow de diferentes formas, através da interface de linha de comandos, do SDK Java ou do SDK Python. Além disso, estamos a desenvolver uma estrutura de portabilidade para oferecer interoperabilidade total entre todos os SDKs e executores.

Se quiser migrar as suas consultas de dados e pipelines de outras frameworks para o Apache Beam e o Dataflow, leia acerca do modelo de programação do Apache Beam e explore a documentação oficial do Dataflow.

Para ver exemplos práticos, consulte os inícios rápidos e os tutoriais do Dataflow.

Orquestração e agendamento

A um nível elevado, a orquestração é a coordenação automática de vários sistemas, enquanto o agendamento refere-se ao acionamento automático do trabalho de orquestração.

  • Aumentar zoom: um pipeline de dados é, em si mesmo, uma orquestração de transformações de dados descritas por um DAG, que é um DAG de tratamento de dados.
  • Diminuir o zoom: quando um pipeline de dados depende do resultado de outros pipelines de dados, precisa de orquestração de vários pipelines. Cada pipeline constitui um sub-DAG num DAG maior, que é um DAG de orquestração.

Esta configuração é típica no armazenamento de dados. A Figura 1 na secção ETL mostra um exemplo de configuração. As secções seguintes focam-se na orquestração de vários pipelines de dados.

Dependências

As dependências podem ser fan-in, em que vários Data pipelines são unidos num vértice de um DAG de orquestração; fan-out, em que um único Data pipeline aciona vários outros; ou, muitas vezes, ambos, conforme mostrado no diagrama seguinte.

Vários pipelines etiquetados como A, B e C confluem para o pipeline D. O pipeline D ramifica-se nos pipelines E, F e G. Tudo isto é orquestrado por um DAG de orquestração.

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

Em ambientes subótimos, algumas dependências resultam de limitações na quantidade de recursos disponíveis. Por exemplo, um data pipeline é executado e produz alguns dados comuns como subproduto. Outros pipelines de dados dependem destes dados comuns simplesmente para evitar o recálculo, mas não estão relacionados com o pipeline de dados que criou os dados. Se este primeiro pipeline encontrar problemas funcionais ou não funcionais, as falhas propagam-se para os pipelines de dados dependentes, o que, na melhor das hipóteses, os força a esperar ou, na pior das hipóteses, impede a respetiva execução, conforme mostrado no diagrama seguinte.

O pipeline A sofre uma falha. Os pipelines B e C dependem do resultado do pipeline A, pelo que também falham.

Figura 11. As falhas em cascata numa conduta de dados impedem a execução de condutas dependentes.

No Google Cloud, tem à sua disposição uma grande quantidade de recursos de computação e ferramentas especializadas para otimizar a execução dos seus pipelines e a respetiva orquestração. As secções restantes abordam estes recursos e ferramentas.

Trabalho de migração envolvido

É uma prática recomendada simplificar as suas necessidades de orquestração. A orquestração torna-se mais complexa à medida que aumenta o número de dependências entre os seus pipelines de dados. A migração para o Google Cloud oferece uma oportunidade de examinar os seus DAGs de orquestração, identificar as suas dependências e determinar como otimizar essas dependências.

Recomendamos que otimize as suas dependências de forma incremental, da seguinte forma:

  1. Numa primeira iteração, mova a orquestração tal como está para o Google Cloud.
  2. Em iterações posteriores, analise as suas dependências e paralelize-as se for viável.
  3. Por fim, reorganize a orquestração extraindo tarefas comuns para os seus próprios DAGs.

A secção seguinte explica este método com um exemplo prático.

Um exemplo prático

Suponhamos que uma organização tem dois pipelines relacionados:

  • O primeiro pipeline calcula os lucros e as perdas (P&L) de 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 em passos de transformação subsequentes e, por fim, escritas numa tabela.
  • O segundo pipeline calcula o crescimento das vendas anual e mensal de diferentes produtos para que o departamento de marketing possa ajustar os respetivos esforços de campanhas publicitárias. Este pipeline precisa dos dados de vendas mensais calculados anteriormente pelo pipeline de dados de lucros e perdas.

A organização considera que o pipeline de dados de lucros e perdas tem uma prioridade mais elevada do que o pipeline de marketing. Infelizmente, como o P&L é um pipeline de dados complexo, consome uma grande quantidade de recursos, o que impede a execução de outros pipelines em simultâneo. Além disso, se o pipeline de lucros e perdas falhar, o pipeline de marketing e outros pipelines dependentes não têm os dados necessários para serem executados e têm de aguardar uma nova tentativa de lucros e perdas. O diagrama seguinte ilustra esta situação.

O pipeline de lucros e perdas cria um artefacto de "vendas mensais" necessário para o pipeline de marketing. O pipeline de lucros e perdas pode sofrer atrasos e outros problemas.

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

A organização está a migrar para o BigQuery. Identificou os dois exemplos de utilização (lucros e perdas e crescimento das vendas de marketing) e incluiu-os na lista de pendências da migração. Ao planear a próxima iteração, a organização prioriza o exemplo de utilização de lucros e perdas e inclui-o na lista de pendências da iteração porque está severamente limitado pelos recursos no local atuais e causa regularmente atrasos. Alguns dos respetivos exemplos de utilização dependentes também estão incluídos, entre eles o exemplo de utilização de marketing.

A equipa de migração executa a primeira iteração. Optam por mover os exemplos de utilização de marketing e de lucros e perdas Google Cloud através de uma abordagem de redirecionamento. Não fazem alterações aos passos do pipeline nem à orquestração. Uma diferença importante é que, agora, o pipeline de lucros e perdas pode usar uma capacidade de computação quase ilimitada e, por isso, é executado muito mais rapidamente do que no local. O pipeline escreve os dados mensais de vendas numa tabela do BigQuery que o pipeline de crescimento de marketing usa. O diagrama seguinte ilustra estas alterações.

O pipeline de lucros e perdas é o mesmo de antes, mas não sofre atrasos.

Figura 13. Acelerar um pipeline de dados complexo através de uma abordagem de redirecionamento.

Embora Google Cloud tenha ajudado a resolver os problemas não funcionais de lucros e perdas, ainda existem problemas funcionais. Algumas tarefas não relacionadas que precedem o cálculo das vendas mensais causam frequentemente erros que impedem a realização desse cálculo e impedem o início dos pipelines dependentes.

Numa segunda iteração, a equipa espera melhorar o desempenho incluindo ambos os exemplos de utilização na lista de pendências da iteração. A equipa identifica as etapas do processo para calcular as vendas mensais no processo de demonstração de resultados. Os passos constituem um DAG secundário, conforme mostrado no diagrama seguinte. A equipa de migração copia o sub-DAG para o pipeline de marketing para que esse pipeline possa ser executado independentemente do P&L. Ter potência de computação suficiente permite que ambos os pipelines sejam executados em simultâneo. Google Cloud

O pipeline de lucros e perdas e o pipeline de marketing são agora executados como sub DAGs separados, pelo que o pipeline de marketing já não é afetado se existirem problemas no pipeline de lucros e perdas.

Figura 14. Pipelines executados em simultâneo através de um sub-DAG.

A desvantagem é que a duplicação da lógica do sub-DAG cria uma sobrecarga de gestão de código, porque agora a equipa tem de manter ambas as cópias da lógica do sub-DAG sincronizadas.

Numa terceira iteração, a equipa revê os exemplos de utilização e extrai o sub-DAG de vendas mensais para um pipeline independente. Quando o novo pipeline de vendas mensal estiver concluído, aciona ou ramifica-se no P&L, no crescimento do marketing e noutros pipelines dependentes. Esta configuração cria um novo DAG de orquestração geral, com cada um dos pipelines a ser um dos seus sub-DAGs.

O pipeline de vendas mensal é agora o primeiro, alimentando o pipeline de lucros e perdas e o pipeline de marketing.

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

Nas iterações subsequentes, a equipa de migração pode resolver quaisquer problemas funcionais restantes e migrar os pipelines para usar os seguintes serviços geridos pelaGoogle CloudGoogle, entre outros:

Embora o Airflow suporte sub-DAGs nativamente, esta funcionalidade pode limitar o respetivo desempenho e, por isso, é desaconselhada. Em alternativa, use DAGs independentes com o operador TriggerDagRunOperator.

O que se segue?

Saiba mais sobre os seguintes passos na migração do armazém de dados:

Também pode saber como fazer a migração de tecnologias de armazém de dados específicas para o BigQuery: