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

Este artigo mostra-lhe como fazer a transição gradual das suas cargas de trabalho analíticas do Azure Data Explorer para o Eventhouse no Fabric Real-Time Intelligence sem indisponibilidade. 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 não puderes esperar que os teus dados no ADX envelheçam e precisares de os copiar para o Eventhouse, considera a ferramenta open source Kusto Copy.

Consumir dados do ADX no Fabric

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

• Atalho da base de dados do Fabric (seguidor)

  Crie um atalho para base de dados para uma base de dados do Azure Data Explorer e consulte-a sem migrar dados para o Fabric. Um atalho de base de dados na carga de trabalho do Fabric Real-Time Intelligence é uma referência incorporada numa base de dados Kusto Query Language (KQL) para uma base de dados de origem no Azure Data Explorer. O comportamento do atalho do banco de dados é semelhante a um banco de dados de seguidores. É só de leitura, sincroniza novos dados com um ligeiro atraso (de segundos a minutos) e permite que todos os itens do Fabric visualizem e consultem dados do ADX sem necessidade de os reingerir.

• Anexar o cluster ADX como uma fonte consultável

  No Fabric, verifique se você tem uma conexão com o cluster ADX. Adicione uma origem do Azure Data Explorer ao queryset KQL, o que permite que certos itens do Fabric, como o queryset e os dashboards em tempo real, consultem dados do ADX. Para obter mais informações, consulte Consultar dados 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 em seus dados ADX. Execute todos os seus painéis e consultas no Fabric enquanto a ingestão continua a acontecer no ADX. Quando estiver pronto para migrar totalmente, 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 uma nova base de dados KQL no Fabric com esquema ADX
2. Criar uma exibição com o operador union que acessa a tabela no banco de dados KQL e a tabela no banco de dados ADX
3. Redirecionar pontos finais de consulta para o KQL Database no Fabric Eventhouse
4. Alternar a ingestão de dados para o Fabric
5. Descontinuar o cluster ADX

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

Criar banco de dados KQL no Fabric com esquema ADX

1. Crie um banco de dados KQL vazio em uma casa de eventos Fabric que eventualmente substitui o banco de dados ADX. Ele deve ter o mesmo esquema de tabelas e funções que seu 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 Fabric KQL. SyncKusto é uma ferramenta dedicada que sincroniza esquemas de banco de dados Kusto (tabelas, funções, etc.) entre ambientes.

   Alternativamente, pode executar o comando KQL: .show database schema as csl script no ADX, que gera um script com todas as definições de tabelas, funções e políticas, e depois executar o script gerado na base de dados KQL no Fabric usando .execute database script.

3. Verificar esquema

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

Crie visualizações de união para acesso contínuo 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 de malha. Essa abordagem permite que as consultas retornem um conjunto de dados completo durante a transição:

1. Definir vistas de união

   Para cada tabela, crie uma função armazenada em Malha (com .create function with (view=true)) que una a tabela Malha 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
   }
   

   Esta vista devolve a união da tabela local MyTable na base de dados KQL do Fabric, que está atualmente vazia ou a receber novos dados, e da tabela remota MyTable na base de dados ADX.

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

   O Fabric e o ADX podem estar em clusters diferentes ou em tenants diferentes. Se o comando de criação indicar um erro relativo à referência externa, use a opção skipvalidation=true ao criar a função, que por vezes é necessária para funções entre clusters.

2. Testar a visualização

   Execute uma consulta de contagem ou exemplo na exibição (por exemplo, MyTable | count) para garantir que ela retorne dados do ADX. O banco de dados Fabric KQL 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 finais de consulta para a KQL Database no Eventhouse do Fabric

Agora atualize suas ferramentas e aplicativos para consultar o novo banco de dados 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, já que os nomes das tabelas e o KQL não foram alterados, mas agora são executados no Fabric. Devido à exibição de união criada na etapa anterior, os usuários que consultam o banco de dados 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. Relatórios de teste e aplicativos

   Certifique-se de que os painéis e scripts estejam obtendo os resultados esperados do banco de dados Fabric KQL. O desempenho pode diferir ligeiramente. O Fabric poderá colocar em cache alguns dados ADX se tiver utilizado um atalho. Esta etapa move efetivamente os endpoints de consulta para o Fabric. A partir daqui, 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 fluxos de ingestão

   Altere todos os produtores de dados, como dispositivos IoT, trabalhos de extração-transformação-carregamento (ETL), ligações do Event Hubs e outros que anteriormente ingeriam dados na base de dados ADX, para que passem a ingeri-los na base de dados KQL do Fabric. Este passo pode incluir alterar URLs de cluster, a autenticação ou atualizar cadeias de ligação no Azure Data Factory, Stream Analytics ou aplicações personalizadas para utilizar o ponto final ou URI de ingestão da base de dados KQL.

2. Verificar novo fluxo de dados

   Verifique se os novos registros estão em tabelas no banco de dados KQL. O banco de dados KQL no Fabric começa a acumular dados. Como está a usar as vistas de união, as consultas no Fabric continuam a mostrar um conjunto de dados unificado. Com o tempo, os dados no ADX tornam-se obsoletos porque nenhum novo dado é ingerido no ADX após essa mudança.

Descontinue o cluster do ADX

Quando tiver certeza de que todos os dados necessários estão disponíveis no Fabric, encerre os recursos antigos do ADX:

1. Remover referências de união

   Altere ou solte as visualizações de união para que as consultas não sejam extraídas do cluster ADX. Por exemplo, atualize a definição de função para MyTable { MyTable } usar apenas dados locais ou descarte a função se a tabela física no Fabric tiver todos os dados. Verifique se as suas consultas e dashboards funcionam como esperado com dados exclusivamente 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 eles envelhecessem), considere exportar esses dados para o Fabric antes do desligamento. Caso contrário, continue se os dados do ADX excederem os requisitos de retenção.

3. Desativar ADX

   Quando o Fabric serve consultas e ingestão, desligue ou exclua o cluster ADX para economizar custos. Todos os usuários devem se conectar ao Fabric agora.

Resumo

Seguindo as etapas neste artigo, você migra do ADX para o Fabric com o mínimo de interrupção. Começa por mover a camada de consumo para o Fabric, o que disponibiliza funcionalidades como o Copilot, o Power BI, os Notebooks e o Activator, e depois migra gradualmente o back-end para o Fabric. Agora, a inteligência em tempo real (Eventhouse) do Fabric lida com a ingestão e consulta de seus dados, e o ADX não está em uso.