O processo de ingestão com análise à escala da cloud no Azure
O Azure fornece vários serviços para ingerir e libertar dados para plataformas nativas e de terceiros. Podem ser utilizados diferentes serviços, dependendo do volume, velocidade, variedade e direção. Alguns destes serviços são:
- Azure Data Factory é um serviço criado para todas as necessidades e níveis de competências de todas as aplicações de dados (alinhadas com a origem). Escreva o seu próprio código ou construção, extraia, carregue e transforme processos no ambiente visual intuitivo e sem código. Com mais de 90 conectores criados nativamente e sem manutenção, integre visualmente origens de dados sem custos adicionais. Os engenheiros podem utilizar pontos finais privados e ligar serviços para se ligarem de forma segura aos recursos da plataforma como um serviço (PaaS) do Azure sem utilizar os pontos finais públicos do recurso PaaS. Os engenheiros podem utilizar runtimes de integração para expandir pipelines para ambientes de terceiros, como origens de dados no local e outras clouds.
Alguns destes conectores suportam a utilização como origem (leitura) ou como sink (escrita). Os serviços nativos do Azure, Oracle, SAP e outros podem ser utilizados como origem ou sink, mas nem todos os conectores o suportam. Nestes casos, pode utilizar conectores genéricos como Conectores Open Database Connectivity (ODBC), o sistema de ficheiros ou conectores SSH File Transfer Protocol (SFTP).
O Azure Databricks é um serviço de análise rápido, fácil e colaborativo baseado no Apache Spark. Para um pipeline de macrodados, pode ingerir os dados (não processados ou estruturados) no Azure através do Data Factory em lotes ou transmitidos em fluxo quase em tempo real com o Apache Kafka, Hubs de Eventos do Azure ou Hub IoT. Estes dados aterram num data lake para armazenamento persistente de longo prazo no Azure Data Lake Storage. O Azure Databricks pode ler dados de várias origens de dados como parte do fluxo de trabalho.
O Microsoft Power Platform fornece conectores a centenas de serviços que podem ser orientados por eventos, agendas ou push. O Microsoft Power Automate pode atuar em eventos e acionar fluxos de trabalho otimizados para registos únicos ou pequenos volumes de dados.
As ferramentas nativas e de terceiros proprietárias fornecem capacidades de nicho para integrar com sistemas especializados e replicação quase em tempo real.
- O Azure Data Share suporta organizações para partilhar dados de forma segura com vários clientes e parceiros externos. Assim que criar uma conta de partilha de dados e adicionar produtos de dados, os clientes e parceiros podem ser convidados para a partilha de dados. Os fornecedores de dados controlam sempre os dados que partilharam. O Azure Data Share facilita a gestão e monitorização dos dados partilhados, quando foram partilhados e quem os partilhou.
Importante
Cada zona de destino de dados tem um grupo de recursos de ingestão de metadados que existe para empresas com um motor de ingestão agnóstico de dados. Se não tiver este motor de arquitetura, o único recurso recomendado é implementar uma área de trabalho de análise do Azure Databricks, que seria utilizada por integrações de dados para executar ingestão complexa. Veja o motor de ingestão de dados agnóstico para obter potenciais padrões de automatização.
Considerações sobre a ingestão de Azure Data Factory
Se tiver um motor de ingestão agnóstico de dados, deve implementar um único Data Factory para cada zona de destino de dados no grupo de recursos de ingestão e processamento. A área de trabalho do Data Factory deve ser bloqueada aos utilizadores e apenas os principais de serviço e identidade gerida terão acesso para implementar. As operações de zona de destino de dados devem ter acesso de leitura para permitir a depuração do pipeline.
A aplicação de dados pode ter aí o próprio Data Factory para movimento de dados. Ter um Data Factory em cada grupo de recursos de aplicações de dados suporta uma experiência completa de integração contínua (CI) e implementação contínua (CD) ao permitir apenas a implementação de pipelines a partir do Azure DevOps ou do GitHub.
Todas as áreas de trabalho do Data Factory utilizarão principalmente a funcionalidade de rede virtual gerida (VNet) no Data Factory ou o runtime de integração autoalojado para a respetiva zona de destino de dados na zona de destino de gestão de dados. Os engenheiros são encorajados a utilizar a funcionalidade VNet gerida para se ligarem de forma segura ao recurso PaaS do Azure.
No entanto, é possível criar mais runtimes de integração para ingerir a partir de clouds no local, de terceiros e de origens de dados de software como serviço (SaaS) de terceiros.
Considerações de ingestão para o Azure Databricks
Esta documentação de orientação explica as informações em:
Proteger o acesso ao Azure Data Lake Storage Gen2 do Azure Databricks
Utilizar o Azure Databricks na análise à escala da cloud no Azure
Para o desenvolvimento, as operações de integração devem ter os seus próprios ambientes do Azure Databricks antes de verificar o código a implementar na única área de trabalho do Azure Databricks durante os testes e a produção.
O Data Factory no grupo de recursos da aplicação de dados (alinhado com a origem) deve fornecer a arquitetura para chamar tarefas do Azure Databricks.
Os principais de serviço podem ajudar a montar data lakes nesta área de trabalho. Para obter mais informações, veja Padrão 1 – acesso através do principal de serviço para obter mais informações.
As equipas de aplicações de dados podem implementar tarefas curtas e automatizadas no Azure Databricks e esperar que os clusters comecem rapidamente, executem a tarefa e terminem. É recomendado configurar conjuntos do Azure Databricks para reduzir o tempo que os clusters demoram a criar tarefas.
Recomendamos que as organizações utilizem o Azure DevOps para implementar uma arquitetura de implementação para novos pipelines. A arquitetura será utilizada para criar as pastas do conjunto de dados, atribuir listas de controlo de acesso e criar uma tabela com ou sem impor controlos de acesso à tabela do Databricks.
Ingestão de fluxos
As organizações poderão ter de suportar cenários em que os publicadores geram fluxos de eventos de alta velocidade. Para este padrão, é recomendada uma fila de mensagens, por exemplo, Hubs de Eventos ou Hub IoT, para ingerir estes fluxos.
Os Hubs de Eventos e Hub IoT são serviços de processamento de eventos dimensionáveis que podem ingerir e processar grandes volumes de eventos e dados com baixa latência e elevada fiabilidade. Os Hubs de Eventos foram concebidos como um serviço de transmissão em fluxo de macrodados e ingestão de eventos. Hub IoT é um serviço gerido que serve como um centro de mensagens central para comunicação bidirecional entre uma aplicação IoT e os dispositivos que gere. A partir daí, os dados podem ser exportados para um data lake em intervalos regulares (lote) e processados com o Azure Databricks em tempo quase real através do Apache Spark Streaming, do Azure Data Explorer, do Stream Analytics ou do Time Series Insights.
Os últimos Hubs de Eventos ou a zona de destino do Apache Kafka dentro da zona de destino específica do caso de utilização devem enviar os respetivos dados agregados para a camada não processada do data lake numa das zonas de destino de dados e para os Hubs de Eventos relacionados com o grupo de recursos da aplicação de dados (alinhada com a origem) na zona de destino de dados.
Monitorizar a ingestão
A monitorização de pipelines de Azure Data Factory pode ser utilizada para monitorizar e resolver problemas das exceções dos pipelines do Data Factory. Reduz o esforço de desenvolvimento de uma solução de monitorização e relatórios personalizada.
A monitorização incorporada é um dos principais motivos para utilizar Azure Data Factory como ferramenta de orquestração principal e Azure Policy podem ajudar a automatizar esta configuração.
Mapear origens de dados para serviços
A documentação de orientação nesta secção mapeia os serviços de ingestão e processamento para origens que normalmente precisam de ser ingeridas ou libertadas do Azure.
Serviços de ingestão:
| ID | Mecanismo | Nota |
|---|---|---|
| A | Data Factory | Conectores incorporados e genéricos (ODBC, SFTP e REST) |
| B | Azure Databricks | Código personalizado (JDBC, JAR e muito mais) |
| C | Terceiros | WANdisco, Qlik e Oracle GoldenGate |
| D | Outro | Por exemplo, capacidades nativas |
| E | Microsoft Power Platform e Azure Logic Apps | Conectores do Microsoft Power Automate |
Mapeamento de origens de dados para serviços:
| Fornecedor | Tipo | Alojado | Categoria | Notas | Ingestão de carga completa | Ingestão de carga incremental | Ingestão em tempo real | Saída de carga completa | Saída de carga incremental | Saída em tempo real |
|---|---|---|---|---|---|---|---|---|---|---|
| Oracle | Tabular | IaaS | Base de Dados | GoldenGate para Azure Data Lake Storage | A, B | A, B | C | A, B | A, B | C |
| Microsoft SQL Server | Tabular | IaaS | Base de Dados | Sap Landscape Transformation e Qlik | A, B | A, B | C, D2 | A, B | A, B | C, D2 |
| MySQL | Tabular | IaaS | Base de Dados | Sap Landscape Transformation e Qlik | A, B | A, B | C, D2 | A, B | A, B | C, D2 |
| SAP BW/4HANA | Tabular | IaaS | Base de Dados | Sap Landscape Transformation e Qlik | A, B, C, D | A, B, C, D | C | - | - | - |
| SAP HANA | Tabular | IaaS | Base de Dados | Sap Landscape Transformation e Qlik | A, B, C, D | A, B, C, D | C | A, B | A, B | - |
| Apache Impala | Tabular | IaaS | Base de Dados | - | A, B | A, B | - | B | B | - |
| Microsoft SharePoint | Lista | SaaS | Arquivo de Registos | - | A, E | A, E | E | A, E | A, E | E |
| REST | REST | Vários | REST | XML, JSON, CSV | A, B, E | A, B, E | A, B, E | A, B, E | A, B, E | A, B, E |
| Microsoft Outlook | SaaS | REST | XML, JSON, CSV | E | E | E | E | E | E |
Dependendo do destino, Azure Database Migration Service podem replicar a partir de bases de dados no local e de terceiros, como o Microsoft SQL Server, PostgreSQL, MySQL ou Oracle para um arquivo de dados baseado no Azure.