O processo de ingestão com a análise de escala de nuvem no Azure
O Azure fornece vários serviços para ingerir e liberar dados para plataformas nativas e de terceiros. Diferentes serviços podem ser usados, dependendo do volume, da velocidade, da variedade e da direção. Alguns desses serviços são:
- Azure Data Factory é um serviço criado para todas as necessidades e níveis de habilidade do aplicativo de dados (alinhados à origem). Escreva seu próprio código ou construa, extraia, carregue e transforme processos dentro do ambiente visual intuitivo e sem código. Com mais de 90 conectores desenvolvidos nativamente e sem manutenção, integre visualmente fontes de dados sem custo adicional. Os engenheiros podem usar pontos de extremidade privados e serviços de link para se conectar com segurança aos recursos de PaaS (plataforma como serviço) do Azure sem usar os pontos de extremidade públicos do recurso PaaS. Os engenheiros podem usar os runtime de integração de integração para estender pipelines para ambientes de terceiros, como fontes de dados locais e outras nuvens.
Alguns desses conectores dão suporte ao uso como uma fonte (leitura) ou como um coletor (gravação). Os serviços nativos do Azure, Oracle, SAP e outros podem ser usados como origem ou coletor, mas nem todos os conectores dão suporte a ele. Nesses casos, você pode usar conectores genéricos como ODBC (Open Database Connectivity), o sistema de arquivos ou os conectores SFTP (protocolo FTP do SSH).
O Azure Databricks é um serviço analítico rápido, fácil e colaborativo baseado no Apache Spark. Para um pipeline Big Data, você pode ingerir os dados (brutos ou estruturados) no Azure por meio de Data Factory em lotes ou transmitidos quase em tempo real com Apache Kafka, Hubs de Eventos do Azure ou Hub IoT. Esses dados chegam em um data lake para armazenamento persistente de longo prazo, no Azure Data Lake Storage. O Azure Databricks pode ler dados de várias fontes de dados como parte do fluxo de trabalho.
O Microsoft Power Platform fornece conectores para centenas de serviços que podem ser controlados por eventos, agendados ou por push. O Microsoft Power Automate pode agir em eventos e disparar fluxos de trabalho otimizados para registros únicos ou pequenos volumes de dados.
Ferramentas proprietárias nativas e de terceiros fornecem recursos de nicho para integração com sistemas especializados e replicação quase em tempo real.
- O Azure Data Share dá suporte às organizações para compartilhem dados com vários clientes e parceiros externos de modo seguro. Depois de criar uma conta de compartilhamento de dados e adicionar produtos de dados, clientes e parceiros poderão ser convidados para o compartilhamento de dados. Provedores de dados estão sempre no controle dos dados que compartilharam. O Azure Data Share facilita o gerenciamento e o monitoramento dos dados compartilhados, quando compartilhados e quem os compartilhou.
Importante
Cada zona de destino de dados tem um grupo de recursos de ingestão de metadados que existe para empresas com um mecanismo de ingestão independente de dados. Se você não tiver esse mecanismo de estrutura, o único recurso recomendado será implantar um workspace de análise do Azure Databricks, que seria usado por integrações de dados para executar ingestão complexa. Consulte o mecanismo de ingestão independente de dados para possíveis padrões de automação.
Ingerir considerações sobre segurança para o Azure Data Factory
Se você tiver um mecanismo de ingestão independente de dados, deverá implantar um único Data Factory para cada zona de destino de dados no grupo de recursos de ingestão e processamento. O espaço de trabalho do Data Factory deve ser bloqueado para os usuários e somente identidade gerenciada e entidades de serviço terão acesso à implantação. As operações da zona de destino de dados devem ter acesso de leitura para permitir a depuração do pipeline.
O aplicativo de dados pode ter um Data Factory próprio para movimentação de dados. Ter um Data Factory em cada grupo de recursos de aplicativo de dados dá suporte a uma experiência completa de CI (integração contínua) e CD (implantação contínua), permitindo apenas que pipelines sejam implantados do Azure DevOps ou do GitHub.
Todos os espaços de trabalho do Data Factory usarão principalmente o recurso de VNet (rede virtual gerenciada) no Data Factory ou o runtime de integração auto-hospedada para sua zona de destino de dados dentro da zona de destino de gerenciamento de dados. Os engenheiros são incentivados a usar o recurso de VNet gerenciada para se conectar com segurança ao recurso de PaaS do Azure.
No entanto, é possível criar mais runtime de integração para ingerirem de nuvens locais, de terceiros e de fontes de dados SaaS (software como serviço) de terceiros.
Ingerir considerações sobre segurança para o Azure Databricks
Este guia elabora as informações em:
Proteger o acesso ao Azure Data Lake Storage Gen2 do Azure Databricks
Usar o Azure Databricks na análise de escala de nuvem no Azure
Para o desenvolvimento, as operações de integração devem ter seus próprios ambientes de Azure Databricks antes de fazer check-in do código a ser implantado em um único espaço de trabalho do Azure Databricks durante o teste e a produção.
O Data Factory no grupo de recursos do aplicativo de dados (alinhado à origem) deve fornecer a estrutura para chamar trabalhos do Azure Databricks.
As entidades de serviço podem ajudar a montar os data Lake nesse espaço de trabalho. Para obter mais informações, consulte Padrão 1-acesso por meio da entidade de serviço para obter mais informações.
As equipes de aplicativos de dados podem implantar trabalhos curtos e automatizados no Azure Databricks e esperar que seus clusters comecem rapidamente, executem o trabalho e terminem. É recomendável configurar pools do Azure Databricks para reduzir o tempo que leva para que os clusters se desativem para trabalhos.
Recomendamos que as organizações usem o Azure DevOps para implementar uma estrutura de implantação para novos pipelines. A estrutura será usada para criar as pastas do conjunto de arquivos, atribuir listas de controle de acesso e criar uma tabela com ou sem impor controles de acesso à tabela do Databrick.
Ingestão de fluxo
As organizações podem precisar dar suporte a cenários em que os editores gerem fluxos de eventos de alta velocidade. Para esse padrão, uma fila de mensagens é recomendada, por exemplo, Hubs de Eventos do Azure ou Hub IoT, para ingerir esses fluxos.
Os Hubs de Eventos do Azure e o Hub IoT são serviços de processamento de eventos escalonáveis que podem ingerir e processar grandes volumes de eventos e dados com baixa latência e alta confiabilidade. Os Hubs de Eventos do Azure são projetados como um fluxo de Big Data e um serviço de ingestão de eventos. O Hub IoT é um serviço gerenciado que funciona como um hub central de mensagens para a comunicação bidirecional entre um aplicativo de IoT e os dispositivos que ele gerencia. A partir daí, os dados podem ser exportados para um data Lake em intervalos regulares (lote) e processados com Azure Databricks em tempo quase real via Apache Spark streaming, Azure Data Explorer, Stream Analytics ou 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 uso devem enviar seus dados agregados à camada bruta do data lake em uma das zonas de destino de dados e aos Hubs de Eventos relacionados ao grupo de recursos do aplicativo de dados (alinhado à origem) na zona de destino de dados.
Monitorar ingestão
O monitoramento de pipeline do Azure data Factory pronto para uso pode ser usado para monitorar e solucionar problemas das exceções dos pipelines de Data Factory. Ele reduz o esforço de desenvolver uma solução de monitoramento e relatório personalizada.
O monitoramento interno é um dos principais motivos para usar o Azure Data Factory como uma ferramenta de orquestração principal e o Azure Policy pode ajudar a automatizar essa configuração.
Mapear fontes de dados para serviços
As diretrizes nesta seção mapeiam a ingestão e o processamento de serviços para fontes que normalmente precisam ser ingeridas ou liberadas do Azure.
Serviços de ingestão:
| ID | Mecanismo | Observação |
|---|---|---|
| Um | Data Factory | Conectores internos e genéricos (ODBC, SFTP e REST) |
| B | Azure Databricks | Código personalizado (JDBC, JAR e mais) |
| C | Terceiros | WANdisco, Qlik Sense e Oracle GoldenGate |
| D | Outro | Por exemplo, recursos nativos |
| E | Microsoft Power Platform e Aplicativos Lógicos do Azure | Conectores do Microsoft Power Automate |
Mapeamento de fontes de dados para serviços:
| Provedor | Type | Hospedado | Categoria | Observações | Ingestão de carga completa | Ingestão de carga incremental | Ingestão em tempo real | Saída de carregamento completo | Saída de carga incremental | Saída em tempo real |
|---|---|---|---|---|---|---|---|---|---|---|
| Oracle | Tabular | IaaS | Banco de dados | GoldenGate para Azure Data Lake Storage | A, B | A, B | C | A, B | A, B | C |
| Microsoft SQL Server | Tabular | IaaS | Banco de dados | Transformação do cenário SAP e Qlik | A, B | A, B | C, D2 | A, B | A, B | C, D2 |
| MySQL | Tabular | IaaS | Banco de dados | Transformação do cenário SAP e Qlik | A, B | A, B | C, D2 | A, B | A, B | C, D2 |
| SAP BW/4HANA | Tabular | IaaS | Banco de dados | Transformação do cenário SAP e Qlik | A, B, C, D | A, B, C, D | C | - | - | - |
| SAP HANA | Tabular | IaaS | Banco de dados | Transformação do cenário SAP e Qlik | A, B, C, D | A, B, C, D | C | A, B | A, B | - |
| Apache Impala | Tabular | IaaS | Banco de dados | - | A, B | A, B | - | B | B | - |
| Microsoft SharePoint | Lista | SaaS | Armazenamento de Registros | - | 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, o Serviço de Migração de Banco de Dados pode replicar de bancos de dados locais e de terceiros, como Microsoft SQL Server, PostgreSQL, MySQL ou Oracle, para um armazenamento com base no Azure.