Migrar do ADX (Azure Data Explorer) para o Fabric Real-Time intelligence (Eventhouse)

Este artigo mostra como fazer a transição gradualmente das cargas de trabalho analíticas do Azure Data Explorer para o Eventhouse no Real-Time Intelligence do Fabric sem tempo de inatividade. Comece usando o Fabric como a camada de consulta enquanto o ADX continua ingerindo dados para explorar os recursos do Fabric. Quando estiver pronto, migre totalmente movendo o esquema e a ingestão para o Fabric.

Se você não puder esperar que seus dados no ADX expirem e precisar copiá-los para Eventhouse, considere a ferramenta de código aberto Kusto Copy.

Consumir dados do ADX no Fabric

Mantenha o ADX somente para ingestão e mova a consulta para o Fabric usando um desses dois métodos para usar dados do ADX do Fabric sem duplicar dados.

• Atalho de banco de dados do Fabric (seguidor)

  Crie um atalho de banco de dados para um banco de dados do Azure Data Explorer e consulte sem migrar dados para o Fabric. Um atalho de banco de dados na carga de trabalho de inteligência do Fabric Real-Time é uma referência inserida em um banco de dados KQL (Kusto Query Language) para um banco de dados de origem no Azure Data Explorer. O comportamento do atalho de banco de dados é semelhante a um banco de dados seguidor. É somente leitura, sincroniza novos dados com um pequeno atraso (segundos a minutos) e permite que todos os itens do Fabric exibam e consultem dados do ADX sem reingestá-los.

• Anexar o cluster do ADX como uma origem que pode ser consultada

  No Fabric, verifique se você tem uma conexão com o cluster do ADX. Adicione uma fonte do Azure Data Explorer em um conjunto de consultas KQL, o que permite que certos itens do Fabric, como conjuntos de consultas e painéis em tempo real, consultem dados do ADX. Para obter mais informações, consulte Os dados de consulta em um conjunto de consultas KQL – Microsoft Fabric.

  Experimente os recursos do Fabric, como geração de consultas assistida por Copilot, Notebooks, Activator e relatórios do Power BI com seus dados do ADX. Execute todos os dashboards e consultas no Fabric enquanto a ingestão continua ocorrendo no ADX. Quando estiver pronto para migrar completamente, siga as próximas etapas.

Etapas de migração de alto nível

Siga estas etapas para migrar do ADX para o Fabric:

1. Criar um novo banco de dados KQL no Fabric com o esquema ADX
2. Criar uma exibição com o operador union que acessa ambas as tabelas, uma no banco de dados KQL e outra no banco de dados ADX
3. Redirecionar endpoints de consulta para o banco de dados KQL no Fabric Eventhouse
4. Alternar a ingestão de dados para o Fabric
5. Desativar o cluster do ADX

As seções a seguir fornecem detalhes sobre cada etapa.

Criar um banco de dados KQL no Fabric com o esquema ADX

1. Crie um banco de dados KQL vazio em uma casa de eventos do Fabric que eventualmente substitui o banco de dados ADX. Ele deve ter o mesmo esquema de tabelas e funções que o banco de dados ADX. Para obter instruções, consulte Criar uma casa de eventos e um banco de dados KQL.

2. Replicar o esquema

   Use o Sync Kusto ou exporte o esquema do banco de dados ADX para recriá-lo no banco de dados KQL do Fabric. SyncKusto é uma ferramenta dedicada que sincroniza esquemas de banco de dados Kusto (tabelas, funções etc.) entre ambientes.

   Como alternativa, você pode executar o comando KQL: .show database schema as csl script no ADX, que gera um script de todas as definições, funções e políticas de tabela e, em seguida, executar o script gerado no banco de dados KQL em Fabric usando .execute database script.

3. Verificar esquema

   Confirme que todas as tabelas, colunas, tipos de dados e políticas relevantes (retenção, cache etc.) no banco de dados KQL correspondem às do banco de dados ADX. Neste ponto, o banco de dados KQL do Fabric está vazio, mas pronto para receber dados, e você também pode consultar o ADX usando métodos dos dados do Explore ADX na seção Fabric .

Criar visões de união para acesso integrado aos dados

Para evitar qualquer interrupção durante a migração de dados, crie exibições KQL no Fabric que combinem dados do banco de dados ADX antigo e do novo banco de dados KQL do Fabric. Essa abordagem permite que as consultas retornem um conjunto de dados completo durante a transição:

1. Definir visualizações de união

   Para cada tabela, crie uma função armazenada no Fabric (com .create function with (view=true)) que uniu a tabela Fabric com a tabela ADX correspondente. Nomeie a função exatamente igual à tabela para substituí-la de forma transparente. Por exemplo, para uma tabela MyTable, crie uma função usando o seguinte comando:

   .create function with (view=true) MyTable() {
       MyTable 
       | union cluster("YourADXCluster").database("YourDatabase").MyTable
   }
   

   Este modo de exibição retorna a união entre o MyTable local no banco de dados KQL do Fabric, que atualmente está vazio ou recebendo novos dados, e a tabela remota MyTable no banco de dados ADX.

   Como o nome da exibição é MyTable, qualquer consulta ou relatório usando esse nome de tabela consulta automaticamente ambas as fontes.

   Fabric e ADX podem estar em clusters ou locatários diferentes. Se o comando de criação reclamar da referência externa, use a opção skipvalidation=true na criação da função, que às vezes é necessária para funções entre clusters.

2. Testar a exibição

   Execute uma contagem ou uma consulta de exemplo na exibição (por exemplo) MyTable | countpara garantir que ela retorne dados do ADX. O banco de dados KQL do Fabric ainda está vazio agora, mas à medida que você migra a ingestão na próxima etapa, a exibição começa a retornar registros antigos e novos.

Redirecionar endpoints de consulta para o banco de dados KQL do Fabric Eventhouse

Agora atualize suas ferramentas e aplicativos para consultar o novo banco de dados do Fabric KQL em vez do banco de dados ADX:

1. Atualizar cadeias de conexão

   Altere aplicativos de análise, consultas KQL ou relatórios do Power BI para usar o ponto de extremidade do banco de dados KQL (URI de consulta), em vez do cluster ADX. As consultas permanecem as mesmas, pois os nomes de tabela e KQL não foram alterados, mas agora são executadas no Fabric. Devido à exibição de união criada na etapa anterior, os usuários que consultam o banco de dados do Fabric KQL ainda obtêm todos os dados históricos do ADX por meio da exibição, além de quaisquer novos dados ingeridos no Fabric.

2. Testar relatórios e aplicativos

   Verifique se os dashboards e scripts estão obtendo resultados conforme o esperado do banco de dados KQL do Fabric. O desempenho pode ser ligeiramente diferente. O Fabric poderá armazenar em cache alguns dados do ADX se você usou um atalho. Esta etapa, na prática, move os endpoints de consulta para o Fabric. Daqui em diante, todas as operações de leitura/consulta ocorrem no Fabric.

Mudar a ingestão de dados para o Fabric

Com as consultas agora atendidas pelo Fabric, direcione os fluxos de dados de entrada para o Fabric:

1. Redirecionar pipelines de ingestão

   Altere todos os produtores de dados, como dispositivos IoT, trabalhos de ETL, conexões do Event Hubs e outros que antes ingeriam dados no banco de dados ADX, para que passem a ingeri-los no banco de dados KQL no Fabric. Esta etapa pode incluir a alteração de URLs de cluster, do método de autenticação ou a atualização das cadeias de conexão no Azure Data Factory, Stream Analytics ou em aplicativos personalizados para usar o endpoint ou URI de ingestão do banco de dados KQL.

2. Verificar o novo fluxo de dados

   Verifique se os novos registros chegam às tabelas no banco de dados KQL. O banco de dados KQL no Fabric começa a acumular dados. Como você está usando as exibições de união, as consultas no Fabric ainda mostram um conjunto de dados unificado. Com o tempo, os dados no ADX ficam obsoletos porque nenhum novo dado é ingerido no ADX após essa opção.

Desativar o cluster do ADX

Quando você estiver confiante de que todos os dados necessários estão disponíveis no Fabric, desative os recursos antigos do ADX:

1. Remover referências sindicais

   Altere ou remova as views de união para que as consultas não consultem o cluster ADX. Por exemplo, atualize a definição de função para MyTable { MyTable } usar apenas dados locais ou solte a função se a tabela física no Fabric tiver todos os dados. Verifique se suas consultas e dashboards funcionam conforme o esperado com dados somente do Fabric.

2. Arquivar ou transferir dados históricos (se necessário)

   Se ainda houver dados históricos no ADX que não foram movidos (por exemplo, se você não esperou que ele envelhecesse), considere exportar esses dados para o Fabric antes do desligamento. Caso contrário, continue se os dados no ADX excederem o período de retenção exigido.

3. Desativar o ADX

   Quando o Fabric atende tanto às consultas quanto à ingestão, desligue ou exclua o cluster do ADX para economizar custos. Todos os usuários devem se conectar ao Fabric agora.

Resumo

Seguindo as etapas deste artigo, você migra do ADX para o Fabric com interrupção mínima. Você começa movendo a camada de consumo para o Fabric, que desbloqueia recursos como Copilot, Power BI, Notebooks e Ativador e, em seguida, gradualmente desloca o back-end para o Fabric. Agora, a inteligência em tempo real do Fabric (Eventhouse) manipula a ingestão e a consulta de seus dados, e o ADX não está em uso.