ETL (extração, transformação e carregamento) reversa com o Azure Cosmos DB for NoSQL

Data warehouses de nuvem e data lakes enriquecem dados, centralizam informações e permitem análises avançadas. Mas o valor real dos dados reside em transformar insights em decisões reais e experiências do cliente. Para atingir essa meta, dados limpos e confiáveis devem ser transferidos de armazenamentos/lagos de dados para sistemas operacionais. A ETL reversa move dados da camada do data warehouse, como o Delta Lake no Azure Databricks ou o Microsoft Fabric, de volta para sistemas operacionais. Essa etapa de migração permite que os aplicativos downstream usem os dados enriquecidos mais recentes para análise operacional em tempo real. O ETL reverso desempenha um papel crucial para desbloquear todo o potencial de seus ativos de dados, fazendo a ponte entre a análise e as operações, permitindo uma melhor tomada de decisão.

O Azure Cosmos DB para NoSQL foi projetado para latência ultra baixa, distribuição global e escalabilidade noSQL, tornando-o ideal para aplicativos em tempo real. Com o ETL Reverso, você pode sincronizar dados enriquecidos com Delta no Azure Cosmos DB, habilitando a análise operacional em tempo real. Você pode usar esse padrão para enviar dados por push, como catálogos de produtos, informações personalizadas do cliente, atualizações de preços, dados de inventário e recomendações de recursos. Você pode enviar esses dados por push para o armazenamento de dados operacional, capacitando aplicativos downstream a tomar decisões controladas por dados instantaneamente.

Arquitetura da solução

Uma arquitetura simplificada para implementar o ETL reverso é composta por Apache Spark e Azure Databricks. Essa arquitetura extrai dados limpos e enriquecidos de fontes como Tabelas Delta e grava os dados de volta no repositório operacional no Azure Cosmos DB para NoSQL.

Este diagrama inclui os seguintes componentes:

• Fontes de dados que incluem dados como; dados do produto, dados de CRM, informações de pedido e informações de anúncios.

• Fluxo de trabalho ETL movendo dados das fontes de dados originais para um data warehouse ou data lake para armazenar e enriquecer os dados usando soluções como o Azure Databricks ou o Microsoft Fabric.

• Fluxo de trabalho de ETL reverso para migrar os dados enriquecidos para um armazenamento de dados operacional usando Apache Spark e tabelas Delta

• O Armazenamento de dados de operação como o Azure Cosmos DB for NoSQL para usar os dados enriquecidos em aplicativos em tempo real.

O processo de ETL reverso habilita cenários como:

• Real-Time Decisões: Aplicativos têm acesso aos dados mais recentes sem precisar de analistas ou SQL.

• Ativação de dados: Os insights são direcionados para onde são necessários, não apenas nos painéis de controle.

• Fonte Unificada da Verdade: Delta Lake atua como a camada canônica, garantindo consistência entre sistemas.

Estágios de ingestão de dados

Para cenários como repositório de recursos, mecanismos de recomendação, detecção de fraudes ou catálogos de produtos em tempo real, é importante separar o fluxo de dados em dois estágios. Esses estágios pressupõem que você tenha um pipeline de ETL reverso do Delta Lake para o Azure Cosmos DB para NoSQL.

Os estágios neste diagrama consistem em:

1. Carga inicial: a carga inicial é uma etapa de processo em lote única para ingerir todos os dados históricos de Tabelas Delta no Azure Cosmos DB para NoSQL. Ele define a base para o pipeline de ETL reversa, garantindo que o armazenamento de dados operacional tenha dados históricos completos. Essa carga é uma etapa fundamental antes de iniciar a sincronização incremental de dados.

2. Sincronização da CDA (captura de dados de alterações): esta etapa implementa uma sincronização incremental e contínua de alterações das Tabelas Delta para o Azure Cosmos DB for NoSQL. As alterações na tabela delta podem ser capturadas depois de habilitar o CDF (Feed de dados de alteração delta). Você pode implementar a sincronização de CDA baseada em lote ou baseada em streaming.

Há duas opções para sincronização CDC no Azure Cosmos DB para NoSQL:

• Sincronização de CDA em lote: essa opção é executada em um agendamento (por exemplo, diariamente ou por hora) e carrega um instantâneo incremental dos dados com base nas alterações capturadas desde a última versão ou carimbo de data/hora.

  Dica

  Alterne para um instantâneo mais recente do Azure Cosmos DB para evitar inconsistências de dados quando grandes volumes incrementais estiverem sendo carregados de uma tabela delta para o Azure Cosmos DB for NoSQL. Por exemplo, ao gravar em um novo contêiner ou usar um sinalizador de versão, redirecione um ponteiro para a versão mais recente da captura de tela uma vez que os novos dados estejam totalmente carregados.

• Sincronização de CDA em fluxo: essa opção sincroniza continuamente as alterações incrementais quase em tempo real, mantendo o sistema de destino atualizado com o mínimo de atraso. Essa opção usa o streaming estruturado do Apache Spark para capturar e gravar continuamente as alterações. A tabela delta atua como uma fonte de streaming com readChangeData = true e o conector do Azure Cosmos DB for NoSQL atua como um coletor de streaming.

  Dica

  Especifique um local de ponto de verificação para garantir que o progresso seja acompanhado e as gravações duplicadas sejam evitadas.

Práticas recomendadas

• Use trabalhos em lote do Apache Spark com o conector do Azure Cosmos DB for NoSQL para executar a etapa de carga inicial.

• Otimize a taxa de transferência de ingestão alternando para a taxa de transferência provisionada padrão se espera-se que a carga inicial consuma uma grande quantidade de RU/s em relação à taxa de transferência alocada. Especificamente, use a taxa de transferência provisionada padrão se as unidades de solicitação máximas por segundo (RU/s) forem utilizadas consistentemente durante a maior parte da duração do processo de carga inicial. Não use a taxa de transferência de dimensionamento automático para a etapa de carga inicial neste cenário.

  Dica

  Se a métrica de consumo de RU normalizada for consistentemente 100%, a métrica indicará que a carga inicial consome consistentemente as RUs (unidades de solicitação de dimensionamento automático) máximas. Esse limiar é um indicador claro de que esse cenário se aplica à sua carga de trabalho e você deve usar o throughput provisionado padrão.

• Escolha uma chave de partição eficaz que maximiza o paralelismo. Para obter mais informações, consulte as Recomendações de chave de partição e particionamento.

• Planeje o número total de partições e RU totais em todas as partições para grandes ingestões de dados. Para obter mais informações e diretrizes, consulte as recomendações para particionamento e taxa de transferência.

• Use o controle de taxa de transferência do Apache Spark para limitar o consumo de RU de trabalhos. O controle de throughput ajuda a evitar sobrecarga no contêiner operacional de destino.

• Use a taxa de transferência de dimensionamento automático quando possível no Azure Cosmos DB for NoSQL para sincronizar de CDA à medida que o dimensionamento automático aumenta/reduz dinamicamente as RU com base no uso. A taxa de transferência de dimensionamento automático é ideal para cargas de trabalho periódicas e com picos, como trabalhos de sincronização de CDA agendados. Para obter mais informações, consulte as Recomendações de taxa de transferência.

• Estimar a duração inicial da ingestão para a etapa inicial de carregamento de dados. Para obter mais informações e um exemplo, consulte a estimativa de taxa de transferência.

Próxima etapa