Implementação do Azure Data Factory

A instância é configurada para que as pipelines carreguem dados de forma fiável e repetível. Uma pipeline é uma sequência de atividades, como copiar dados ou iniciar um notebook. Um linked service descreve uma fonte ou um serviço de computação, e o integration runtime fornece a capacidade de processamento entre ambos. Um consultor de Azure Data Factory define o padrão de carregamento, os runtimes, os triggers e o percurso até à produção.

O ADF é a camada de carregamento de uma plataforma de dados e IA. Se pretende configurar toda a plataforma no Azure, incluindo armazenamento, rede e capacidade de processamento, leia sobre como configurar uma plataforma de dados no Azure.

Quando uma fonte está numa rede privada sem ligação direta à cloud, como um SQL Server nas suas instalações. O self-hosted runtime é executado numa máquina Windows atrás da sua firewall e estabelece apenas ligações HTTP de saída. Também é necessário para fontes que exigem um driver próprio, como SAP HANA e MySQL; nesses casos, o Java tem de estar instalado na mesma máquina.

Para garantir a disponibilidade, pode associar várias máquinas a um único runtime, que funcionam em modo ativo-ativo. Em CI/CD, o runtime tem de ter o mesmo nome e o mesmo tipo em todos os ambientes.

Um schedule trigger inicia pipelines a horas definidas e pode iniciar várias em simultâneo. Indica sucesso assim que uma execução começa, mesmo que esta falhe mais tarde. Um tumbling window trigger trabalha com intervalos de tempo consecutivos, aguarda o resultado da execução, permite carregar dados retroativamente e volta a tentar as execuções que falharam.

Por isso, para carregamentos incrementais de hora a hora ou diários, o tumbling window trigger é muitas vezes a opção mais segura. Para novos ficheiros numa storage account, utilize um storage event trigger.

Com parâmetros fornecidos em cada execução. A Microsoft dá o exemplo de um único linked service para diferentes bases de dados no mesmo SQL Server: define o nome da base de dados como parâmetro, em vez de criar um linked service por base de dados. Depois, uma pipeline consulta uma lista para saber que tabelas deve carregar.

Não parametrize palavras-passe. A Microsoft recomenda guardar os segredos no Azure Key Vault e utilizar apenas o nome do segredo como parâmetro.

Os programadores trabalham numa instância de desenvolvimento ligada ao Git, cada um no seu próprio branch. Após um pull request, a alteração passa pelo Azure Pipelines até aos ambientes de teste e produção, com templates do Resource Manager e parâmetros específicos para cada ambiente. Assim, ninguém precisa de alterar diretamente a instância em produção.

Tenha atenção às definições que não estão incluídas nesses templates, como o relatório de custos por pipeline. É necessário ativá-lo separadamente em cada instância.

Configure um alerta para a métrica de execuções de pipelines falhadas, para que a equipa receba uma notificação por cada erro. O Data Factory conserva os dados das execuções apenas durante um período limitado. Por isso, envie os logs para o Log Analytics através das definições de diagnóstico; aí também pode consultar várias instâncias em conjunto.

Em cada execução de uma pipeline, pode ver o consumo por unidade de medição. Se ativar o relatório de custos por pipeline, o Cost Management mostra quanto custa cada pipeline.

A Microsoft descreve o Data Factory no Fabric como a geração seguinte do ADF. Há três opções: adicionar a sua instância existente como item num workspace do Fabric, atualizar as pipelines com a funcionalidade de atualização integrada ou reconstruí-las. A atualização classifica cada pipeline como Ready, Needs review, Coming soon ou Not compatible.

Os linked services passam a ser ligações, os datasets ficam definidos na própria atividade e os parâmetros globais passam a integrar uma biblioteca de variáveis. Compare também com o Azure Synapse se as suas pipelines forem executadas aí.

Se tiver poucas fontes que o Power BI consegue atualizar por si só, ou se estiver a começar do zero e o Fabric já for a solução padrão, um ambiente ADF separado acrescenta trabalho de gestão sem trazer benefícios.

Se o problema não estiver no carregamento, mas no que acontece depois aos dados, como modelos, testes e qualidade dos dados, comece por data engineering.