Aplicações de dados (alinhadas com a origem)
Se optou por não implementar um motor agnóstico de dados para ingerir dados uma vez a partir de origens operacionais ou se as ligações complexas não forem facilitadas no motor agnóstico de dados, deve criar uma aplicação de dados alinhada com a origem. Deve seguir o mesmo fluxo que um motor agnóstico de dados ao ingerir dados de origens de dados externas.
Descrição Geral
O grupo de recursos da aplicação é responsável pela ingestão e melhoramento de dados apenas a partir de origens externas, como telemetria, finanças ou CRM. Esta camada pode funcionar em tempo real, em lotes e em micro-lotes.
Esta secção explica a infraestrutura implementada para cada grupo de recursos de aplicações de dados (alinhadas com a origem) dentro da zona de destino de dados.
Dica
Para a malha de dados, pode optar por implementar uma destas por origem ou uma por domínio. Os princípios da uniformização de dados, da qualidade dos dados e da linhagem de dados ainda têm de ser seguidos. As equipas de operações de plataformas de dados podem desenvolver fragmentos de código padrão e pedir-lhes que o alcancem.
Para cada grupo de recursos de aplicação de dados (alinhado com a origem) na zona de destino de dados, deve criar:
- Um Key Vault do Azure
- Uma Azure Data Factory, para executar pipelines de engenharia desenvolvidos que transformam dados de não processados para enriquecidos
- Um principal de serviço utilizado pela aplicação de dados (alinhada com a origem) para implementar tarefas de ingestão no Azure Databricks (apenas se utilizar o Azure Databricks)
Também pode criar instâncias de outros serviços, como Hubs de Eventos do Azure, Hub IoT do Azure, Azure Stream Analytics e Azure Machine Learning.
Nota
Tem de utilizar um motor spark como o Azure Synapse Spark ou o Azure Databricks para impor o padrão do delta lake.
Se decidir utilizar o Azure Databricks, recomendamos que implemente Azure Data Factory em vez de Azure Synapse área de trabalho do Analytics para reduzir a área de superfície apenas às funcionalidades necessárias.
No entanto, se precisar de uma área de desenvolvimento abrangente com pipelines e spark, utilize o Azure Synapse Analytics. Aplique uma política para permitir apenas a utilização do Spark e dos pipelines para evitar criar silos num conjunto de SQL Azure Synapse.
Azure Key Vault
Utilize a funcionalidade Key Vault do Azure para armazenar segredos no Azure sempre que possível.
Cada grupo de recursos ou domínio de dados (se malha) de cada aplicação de dados (alinhado com a origem) terá um Key Vault do Azure. Isto garante que a chave de encriptação, o segredo e a derivação do certificado cumprem os requisitos do seu ambiente. Isto permite uma melhor separação dos deveres administrativos e também reduz o risco de misturar chaves, integrações e segredos de classificações diferentes.
Todas as chaves relacionadas com a sua aplicação de dados (alinhadas com a origem) devem estar contidas no seu Key Vault do Azure.
Importante
Os cofres de chaves da aplicação de dados (alinhados com a origem) devem seguir o modelo com menos privilégios e evitar limites de escala de transações e partilha de segredos entre ambientes.
Azure Data Factory
Implemente uma Azure Data Factory para permitir que os pipelines escritos pela sua equipa de aplicações de dados levem dados de não processados para enriquecidos através de pipelines desenvolvidos. Utilize fluxos de dados de mapeamento para transformações e parta para utilizar a área de trabalho do Azure Databricks (ingestão) ou Azure Synapse Spark para transformações complexas.
Deve ligar Azure Data Factory à instância de DevOps do repositório da aplicação de dados (alinhada com a origem). Esta ligação permite implementações de CI/CD.
Hubs de Eventos
Se a sua aplicação de dados (alinhada com a origem) tiver um requisito para transmitir dados em fluxo, pode implementar Hubs de Eventos a jusante no grupo de recursos da aplicação de dados (alinhados com a origem).