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

Este artigo mostra como fazer a transição gradual das cargas de trabalho de análise do Azure Data Explorer para o Eventhouse no Fabric Real-Time inteligência 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.

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 do banco de dados 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 no conjunto de consultas KQL, que permite que determinados itens do Fabric, como conjunto 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 assistidas por Copilot, Notebooks, Ativador e relatórios do Power BI em seus dados do ADX. Execute todos os dashboards e consultas no Fabric enquanto a ingestão continua a acontecer 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 de união que acessa a tabela no banco de dados KQL e na tabela no banco de dados ADX
3. Redirecionar pontos de extremidade 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 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 no Fabric.

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 exibições de união para acesso contínuo a 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 exibiçõ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
   }
   

   Essa exibição retorna a união do local MyTable no banco de dados do Fabric KQL, que atualmente está vazio ou recebendo novos dados, e a tabela MyTable remota no banco de dados do 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 pontos de extremidade de consulta para o Banco de Dados KQL no 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. Essa etapa move efetivamente os pontos de extremidade de consulta para o Fabric. Daqui em diante, todas as operações de leitura/consulta ocorrem no Fabric.

Alternar 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 etl (extração-transformação-carga), conexões de Hubs de Eventos e outros que ingerem anteriormente no banco de dados ADX, para que eles ingeram no banco de dados KQL do Fabric. Esta etapa pode incluir a alteração de URLs de cluster, autenticação ou atualização de cadeias de conexão no Azure Data Factory, Stream Analytics ou aplicativos personalizados para usar o ponto de extremidade ou URI de ingestão de 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 de união

   Altere ou solte as exibições de união para que as consultas não efetuem pull do cluster do 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 estiverem além dos requisitos de retenção.

3. Desativar o ADX

   Quando o Fabric atende consultas e ingestão, desligue ou exclua o cluster ADX para economizar custo. 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.