Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Os armazéns de dados na nuvem e os data lakes enriquecem os dados, centralizam as informações e permitem análises poderosas. Mas o verdadeiro valor dos dados está em transformar insights em decisões do mundo real e experiências do cliente. Para atingir esse objetivo, dados limpos e confiáveis devem sair dos armazéns de dados / lagos de dados para sistemas operacionais. O ETL reverso movimenta dados da camada de armazenamento de dados, como o Delta Lake no Azure Databricks ou Microsoft Fabric, de volta para sistemas operacionais. Esta etapa de migração permite que os aplicativos downstream usem os dados mais recentes e enriquecidos para análises operacionais em tempo real. O ETL reverso desempenha um papel crucial no desbloqueio de todo o potencial de seus ativos de dados, preenchendo a lacuna entre análises e operações, permitindo uma melhor tomada de decisões.
O Azure Cosmos DB para NoSQL foi projetado para latência ultrabaixa, 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, permitindo análises operacionais em tempo real. Você pode usar esse padrão para enviar dados 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 para seu armazenamento de dados operacionais, capacitando aplicativos downstream para tomar decisões orientadas por dados instantaneamente.
Arquitetura de soluções
Uma arquitetura simplificada para implementar ETL reverso é composta pelo 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 incluam dados como; dados do produto, dados do CRM, informações do pedido e informações do anúncio.
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 Azure Databricks ou Microsoft Fabric.
Reverse ETL workflow para migrar os dados enriquecidos para um armazenamento de dados operacional usando Apache Spark e tabelas Delta
Armazém de dados operacionais como o Azure Cosmos DB, que suporta NoSQL, para utilizar os dados enriquecidos em aplicações em tempo real.
O processo de ETL reverso permite cenários como:
Real-Time Decisões: Os aplicativos têm acesso aos dados mais recentes sem depender de analistas ou SQL.
Ativação de dados: As informações são enviadas para onde são necessárias, não apenas em painéis.
Fonte Unificada da Verdade: O Delta Lake atua como a camada canônica, garantindo a consistência entre os sistemas.
Etapas de ingestão de dados
Para cenários como armazenamento de recursos, mecanismos de recomendação, deteçã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 tenhas um fluxo de ETL inverso do Delta Lake para o Azure Cosmos DB de NoSQL.
As etapas deste diagrama consistem em:
Carga inicial: a carga inicial é uma etapa única do processo em lote para ingerir todos os dados históricos das Tabelas Delta no Azure Cosmos DB para NoSQL. Ele define a base para seu pipeline de ETL reverso, garantindo que o armazenamento de dados operacionais tenha dados históricos completos. Essa carga é uma etapa fundamental antes de iniciar a sincronização incremental de dados.
Sincronização de Captura de Mudanças de Dados (CDC): esta etapa implementa uma sincronização incremental e contínua de alterações nas Tabelas Delta no Azure Cosmos DB para NoSQL. As alterações na tabela delta podem ser capturadas depois de ativar o Delta Change Data Feed (CDF). Você pode implementar a captura de dados de alteração (CDC) sincronizada por lote ou por streaming.
Há duas opções para sincronização CDC no Azure Cosmos DB para NoSQL:
Sincronização CDC em lote: esta opção é executada num horário programado (por exemplo, diariamente ou por hora) e carrega um instantâneo incremental dos dados baseados nas alterações capturadas desde a última versão ou timestamp.
Sugestão
Mude para uma cópia mais recente do Azure Cosmos DB para evitar inconsistências de dados ao carregar grandes volumes incrementais de uma tabela delta para o Azure Cosmos DB NoSQL. Por exemplo, ao gravar num novo recipiente ou usar um indicador de versão, altere 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 alterações incrementais quase em tempo real, mantendo o sistema de destino atualizado com atraso mínimo. Esta opção usa o streaming estruturado do Apache Spark para capturar e gravar alterações continuamente. A tabela delta atua como uma fonte de streaming com
readChangeData = true, e o conector do Azure Cosmos DB para NoSQL atua como um destino de streaming.Sugestão
Especifique um local de ponto de verificação para garantir que o progresso seja controlado e gravações duplicadas sejam evitadas.
Melhores práticas
Utilize trabalhos em lote do Apache Spark com o conector do Azure Cosmos DB para bases de dados NoSQL para executar a etapa de carregamento inicial.
Otimize a largura de banda de ingestão mudando para a largura de banda provisionada padrão caso se preveja que a carga inicial consuma uma grande quantidade de RU/s comparado com a largura de banda alocada. Especificamente, use a taxa de transferência provisionada padrão se o máximo de unidades de solicitação por segundo (RU/s) for utilizado consistentemente durante a maior parte da duração do processo de carga inicial. Não use o dimensionamento automático da taxa de transferência para o passo inicial de carregamento neste cenário.
Sugestão
Se a métrica de consumo de RU normalizada for consistentemente de 100%, a métrica indica que a carga inicial consome consistentemente as unidades de solicitação de escala automática (RUs) máximas. Esse limite é um indicador claro de que esse cenário se aplica à sua carga de trabalho e você deve usar a taxa de transferência provisionada padrão.
Escolha uma chave de partição eficaz que maximize o paralelismo. Para obter mais informações, consulte recomendações de particionamento e chave de partição.
Planeje 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 obter mais informações e orientações, consulte recomendações para particionamento e taxa de transferência.
Utilize o controle de throughput do Apache Spark para limitar o consumo de unidades de solicitação (RU) de tarefas. O controle de taxa de transferência ajuda a evitar a sobrecarga do contêiner operacional de destino.
Utilizar taxa de transferência com ajuste automático sempre que possível no Azure Cosmos DB para NoSQL com sincronização CDC, pois o ajuste automático aumenta ou reduz automaticamente as Unidades de Pedido por segundo (RU/s) com base no uso. O dimensionamento automático de throughput é ideal para cargas de trabalho periódicas e irregulares, como tarefas agendadas de sincronização CDC. Para obter mais informações, consulte as recomendações de throughput.
Estime a duração da ingestão inicial para a etapa inicial de carregamento de dados. Para obter mais informações e um exemplo, consulte Estimativa de taxa de transferência.