Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Os armazéns de dados na cloud e os data lakes enriquecem os dados, centralizam a informação e permitem análises poderosas. Mas o verdadeiro valor dos dados reside em transformar insights em decisões do mundo real e experiências do cliente. Para alcançar este objetivo, dados limpos e fiáveis devem sair do armazém/data lakes para sistemas operacionais. O ETL reverso move dados da sua camada de armazém de dados, como Delta Lake no Azure Databricks ou Microsoft Fabric, de volta para sistemas operacionais. Esta etapa de migração permite que as aplicações a jusante utilizem os dados mais recentes e enriquecidos para análises operacionais em tempo real. O ETL reverso desempenha um papel crucial no desbloqueio total do potencial dos seus ativos de dados, ao colmatar a lacuna entre análise e operações, permitindo uma melhor tomada de decisão.
O Azure Cosmos DB para NoSQL foi concebido para latência ultra-baixa, distribuição global e escalabilidade NoSQL, tornando-o ideal para aplicações em tempo real. Com o Reverse ETL, pode sincronizar dados enriquecidos com Delta no Azure Cosmos DB, permitindo análises operacionais em tempo real. Pode usar este padrão para enviar dados como catálogos de produtos, informações personalizadas de clientes, atualizações de preços, dados de inventário e recomendações de funcionalidades. Pode enviar estes dados para o seu armazenamento operacional, permitindo que as aplicações posteriores tomem decisões baseadas em dados instantaneamente.
Arquitetura de soluções
Uma arquitetura simplificada para implementar ETL reverso é composta por Apache Spark e Azure Databricks. Esta arquitetura extrai dados limpos e enriquecidos de fontes como as Delta Tables e grava os dados de volta para o armazenamento operacional no Azure Cosmos DB para NoSQL.
Este diagrama inclui os seguintes componentes:
Fontes de dados que incluem dados como; dados de produto, dados de CRM, informações de encomendas e informações de anúncios.
Fluxo de trabalho ETL que consiste em transferir dados das fontes originais para um data warehouse ou data lake, para armazenar e enriquecer os dados usando soluções como Azure Databricks ou Microsoft Fabric.
Fluxo de trabalho ETL inverso para migrar os dados enriquecidos para um armazenamento operacional de dados usando tabelas Apache Spark e Delta
Base de dados operacional, como o Azure Cosmos DB para NoSQL, para utilizar os dados enriquecidos em aplicações em tempo real.
O processo de ETL inverso permite cenários como:
Decisões em Tempo Real: Os aplicativos têm acesso aos dados mais recentes sem depender de analistas ou SQL.
Ativação de Dados: Os insights são colocados onde são necessários — não apenas em dashboards.
Fonte Unificada da Verdade: Delta Lake atua como a camada canónica, garantindo consistência entre sistemas.
Etapas de ingestão de dados
Para cenários como feature store, motores de recomendação, deteção de fraude ou catálogos de produtos em tempo real, é importante separar o fluxo de dados em duas fases. Estas fases assumem que tens um pipeline de ETL inverso do Delta Lake para o Azure Cosmos DB para NoSQL.
As etapas deste diagrama consistem em:
Carregamento inicial: O carregamento inicial é um passo de processo em lote único para ingerir todos os dados históricos das Tabelas Delta no Azure Cosmos DB para NoSQL. Estabelece a base para o seu pipeline de ETL inverso ao garantir que o armazenamento operacional de dados tem dados históricos completos. Esta carga é um passo fundamental antes de iniciar a sincronização incremental dos dados.
Sincronização de captura de dados de alterações (CDC): Este passo implementa uma sincronização incremental e contínua das alterações das Tabelas Delta para o Azure Cosmos DB para NoSQL. Alterações na tabela delta podem ser capturadas após a ativação do Feed de Dados de Alteração Delta (CDF). Pode implementar a sincronização de captura de dados de alteração (CDC) com base em lote ou em streaming.
Existem duas opções para sincronizar CDC no Azure Cosmos DB para NoSQL:
Sincronização CDC em lote: Esta opção é executada com base num calendário (ex. diariamente ou a cada hora) e carrega um instantâneo incremental dos dados com base nas alterações captadas desde a última versão ou marca temporal.
Sugestão
Mude para um snapshot mais recente do Azure Cosmos DB para evitar inconsistências de dados quando grandes volumes incrementais estão a ser carregados de uma tabela delta para o Azure Cosmos DB para NoSQL. Por exemplo, ao escrever para um novo contentor ou usar um indicador de versão, mude um ponteiro para uma captura de ecrã mais recente assim que os novos dados estiverem totalmente carregados.
Stream CDC sync: Esta opção sincroniza continuamente as alterações incrementais quase em tempo real, mantendo o sistema alvo atualizado com o mínimo de atraso. Esta opção utiliza streaming estruturado do Apache Spark para capturar e escrever continuamente alterações. A tabela delta atua como fonte de streaming com
readChangeData = true, e o conector Azure Cosmos DB para NoSQL atua como um sumidouro de streaming.Sugestão
Especifique uma localização de ponto de controlo para garantir que o progresso é acompanhado e que se evitam escritas duplicadas.
Melhores práticas
Use trabalhos em batch do Apache Spark com o conector para NoSQL do Azure Cosmos DB para realizar a etapa inicial de carregamento.
Otimize o throughput de ingestão alternando para o throughput provisionado padrão se for esperado que a carga inicial consuma uma grande quantidade de RU/s em relação ao seu throughput alocado. Especificamente, utilize a largura de banda provisionada padrão se as unidades máximas de pedido por segundo (RU/s) forem utilizadas de forma consistente durante a maior parte da duração do processo inicial de carga. Não uses o débito automático de escalabilidade para a etapa inicial de carregamento neste cenário.
Sugestão
Se a métrica de consumo de RU normalizada for consistentemente 100%, isso indica que a carga inicial consome as unidades máximas de pedido de autoscale (RUs). Este limiar é um indicador claro de que este cenário se aplica à sua carga de trabalho e deverá utilizar o débito provisionado padrão.
Escolha uma chave de partição eficaz que maximize o paralelismo. Para mais informações, consulte particionamento e recomendações de chaves de partição.
Planeie o número total de partições e o total de RU/s em todas as partições para grandes ingestões de dados. Para mais informações e orientações, consulte as recomendações para particionamento e throughput.
Use controlo de throughput do Apache Spark para limitar o consumo de unidades de solicitação (RU) de tarefas. O controlo de throughput ajuda a evitar sobrecarregar o contentor operacional alvo.
Use o throughput autoscale sempre que possível no Azure Cosmos DB para NoSQL, para a sincronização de CDC, pois o autoscale ajusta dinamicamente as Unidades de Pedido (RU/s) de acordo com o uso. O conceito de largura de banda de autoescala é ideal para cargas de trabalho periódicas e irregulares, como tarefas de sincronização CDC agendadas. Para mais informações, consulte as recomendações de rendimento.
Estima a duração inicial da ingestão para a tua etapa inicial de carga de dados. Para mais informações e uma amostra, consulte estimativa de rendimento.