Escolha a configuração do runtime de integração correta para o seu cenário

O runtime de integração (IR) é a infraestrutura de computação que o Microsoft Purview utiliza para ativar a análise de dados em diferentes ambientes de rede. Este artigo apresenta os diferentes tipos de runtime de integração disponíveis no Microsoft Purview e fornece orientações sobre como escolher a configuração de runtime de integração certa para o seu cenário.

Tipos de runtimes de integração

O Purview fornece os seguintes tipos de runtimes de integração:

  • Azure integration runtime: o Azure integration runtime é uma computação elástica e totalmente gerida que pode utilizar para analisar Azure ou origens de dados não Azure. O Azure IR suporta ligações a arquivos de dados e serviços de computação com pontos finais acessíveis publicamente. É o runtime de integração predefinido que não precisa de criar nada para começar.

  • Runtime de integração Rede Virtual gerido: pode criar um runtime de integração do Managed Rede Virtual, que reside num Rede Virtual Gerido do Purview. Pode utilizar pontos finais privados para ligar e analisar de forma segura as origens de dados suportadas. Saiba mais em Pontos finais privados geridos e Rede Virtual geridos.

  • Runtime de integração autoalojado: o runtime de integração autoalojado pode ser utilizado para analisar origens de dados numa rede no local ou numa rede virtual. Pode instalá-la num computador no local ou numa máquina virtual dentro da sua rede privada. Saiba mais em Criar e gerir runtimes de integração autoalojados.

  • Runtime de integração autoalojado suportado pelo Kubernetes: este runtime de integração está alojado num cluster do Kubernetes e pode ser utilizado para analisar origens de dados numa rede no local ou numa rede virtual. O suporte do Kubernetes melhora o desempenho geral e permite que o runtime de integração seja dimensionado com a tarefa. Saiba mais em Criar e gerir runtimes de integração autoalojados suportados pelo Kubernetes.

  • Runtime de integração do AWS: o runtime de integração do AWS é uma computação totalmente gerida e elástica alojada pelo Microsoft Purview no AWS. É aplicável ao analisar origens de dados da Amazon, como S3, RDS.

Escolher o runtime de integração certo

Escolha o runtime de integração certo para as suas necessidades. Considere a arquitetura e os requisitos existentes para a integração de dados. Pense também em como satisfazer as crescentes necessidades empresariais e em qualquer aumento futuro da carga de trabalho.

As seguintes considerações podem ajudá-lo a tomar a sua decisão:

  1. Que tipos de origem de dados pretende analisar?

    Consulte a secção origens de dados suportadas para saber mais sobre os tipos de IR suportados para as origens de dados que pretende analisar.

  2. Qual é o controlo de acesso à rede na sua origem de dados?

    Diferentes origens de dados têm diferentes definições de firewall de rede para as proteger contra acesso aleatório através da Internet. Estas definições aplicam-se a arquivos de dados SaaS, cloud e no local. A tabela seguinte lista algumas opções comuns de firewall. Escolha o tipo de IR suportado de acordo com o seu cenário.

    Firewall da origem de dados ir de Azure IR Rede Virtual Gerido SHIR SHIR suportado pelo Kubernetes
    Permitir acesso público
    Permitir Azure serviço ou serviço fidedigno
    Permitir o acesso a partir de uma rede virtual de Azure específica ✓ (com suporte para pontos finais privados geridos)
    Permitir um intervalo ip/IP específico
    Outro acesso à rede no local ou privado
  3. Qual é a definição da firewall do Microsoft Purview?

    O Purview fornece diferentes opções de firewall de rede. Saiba mais em Configurar a firewall do Microsoft Purview. Escolha o tipo de IR suportado de acordo com o seu cenário.

    Firewall do Purview ir de Azure IR Rede Virtual Gerido SHIR SHIR suportado pelo Kubernetes
    Ativado a partir de todas as redes
    Desativado a partir de todas as redes ✓ (ponto final privado gerido necessário) ✓ (é necessário criar um ponto final privado a partir da sua rede) ✓ (é necessário criar um ponto final privado a partir da sua rede)
  4. Que nível de segurança precisa durante a transmissão de dados?

    A localização do runtime de integração define a localização da computação de back-end e onde as operações de análise são executadas. Para consideração sobre a residência dos dados:

    • Quando utiliza Azure IR, o Purview deteta automaticamente a localização da origem de dados e utiliza o IR nessa região. Se o Purview não conseguir detetar a região, utiliza a região da conta do Purview.

    • Quando utiliza o IR Rede Virtual Gerido, este é executado na região que configura para a rede virtual gerida.

    • Quando utiliza o SHIR, pode decidir totalmente a localização nas suas máquinas virtuais no local ou Azure.

      Para proteger contra ataques man-in-the-middle durante a transmissão de dados, utilize um ponto final privado e uma ligação privada para garantir a segurança dos dados.

    • Pode criar pontos finais privados geridos para os seus arquivos de dados ao utilizar o Managed Rede Virtual IR. O serviço Purview mantém os pontos finais privados na rede virtual gerida.

    • Também pode criar pontos finais privados na sua rede virtual e o SHIR pode utilizá-los para aceder a arquivos de dados.

  5. Que nível de manutenção consegue fornecer?

    Manter a infraestrutura, os servidores e o equipamento é uma das tarefas importantes do departamento de TI de uma empresa. Normalmente, demora muito tempo e esforço.

    • Ao utilizar Azure IR e o IR Rede Virtual Gerido, não precisa de se preocupar com a manutenção, como atualizações, patches e versões. O serviço Purview trata de todos os esforços de manutenção.
    • Uma vez que o SHIR está instalado nos seus computadores e o SHIR suportado pelo Kubernetes está nos clusters do Kubernetes, tem de gerir a manutenção.
  6. Desempenho e escalabilidade

    Utilize o IR de Azure totalmente gerido e dimensionado automaticamente, o IR Rede Virtual Gerido ou o runtime de integração autoalojado suportado pelo Kubernetes sempre que aplicável. Ao utilizar a elasticidade, podem proporcionar-lhe um melhor desempenho e escalabilidade, especialmente ao analisar sistemas de dados em grande escala.

Hibernação do runtime de integração da rede virtual gerida

Se o runtime de integração estiver inativo (sem análises no runtime de integração durante mais de 90 dias), o Managed Rede Virtual Integration Runtime entra automaticamente em hibernação. O respetivo status é apresentado como Hibernado quando seleciona o runtime de integração.

O que significa esta alteração para si

  1. Quando executa a Ligação de Teste num runtime de integração hibernado, a ligação de teste falha. Verá uma mensagem para experimentar a Ligação de Teste após 15 minutos. Por esta altura, o Rede Virtual Gerido regressa a um estado normal. Depois disso, pode executar normalmente as Suas Ligações de Teste e Análises.

  2. Quando executa uma análise diretamente através das opções Executar análise agora ou Editar Análise sem executar uma Ligação de Teste primeiro a partir de um Integration Runtime hibernado ou executa uma análise através da API, verá uma mensagem a indicar que esta análise demora até 15 minutos extra. Este tempo extra destina-se ao Integration Runtime hibernado para reativar e o processo de análise começar. Verá a sua análise status como Queued_Waking IR Superior em vez do estado Em fila que vê em caso de análise normal. Após a primeira análise, pode executar normalmente todas as análises seguintes.

Origens de dados suportadas

A tabela seguinte mostra todas as origens de dados suportadas pela análise do Purview e os tipos de runtime de integração suportados.

Categoria Arquivo de dados suportado IR do Azure/IR do AWS IR Rede Virtual Gerido SHIR Kubernetes SHIR
Azure Várias origens
Azure Storage Blob ✓ (incluindo o ponto final privado gerido)
Azure Cosmos DB (API para NoSQL) ✓ (incluindo o ponto final privado gerido)
Azure Data Explorer ✓ (apenas v2)
Azure Data Lake Storage Gen1 ✓ (apenas v2)
Azure Data Lake Storage Gen2 ✓ (incluindo o ponto final privado gerido)
Banco de Dados do Azure para MySQL ✓ (incluindo o ponto final privado gerido)
Banco de dados do Azure para PostgreSQL ✓ (incluindo o ponto final privado gerido)
Metastore do Hive do Azure Databricks
Catálogo do Unity no Azure Databricks ✓ (apenas v2, incluindo o ponto final privado gerido)
Pool de SQL Dedicado do Azure (antigo SQL DW) ✓ (incluindo o ponto final privado gerido)
Arquivos do Azure ✓ (incluindo o ponto final privado gerido)
Banco de Dados SQL Azure ✓ (incluindo o ponto final privado gerido)
Instância Gerenciada de SQL do Azure ✓ (incluindo o ponto final privado gerido)
Azure Synapse Analytics (Área de Trabalho) ✓ (incluindo o ponto final privado gerido)
Banco de dados Amazon RDS
Amazon Redshift
Cassandra ✓ (apenas v2)
DB2
BigQuery do Google
Banco de Dados do Metastore do Hive
Mongodb
MySQL ✓ (apenas v2)
Oracle
PostgreSQL ✓ (apenas v2)
Warehouse de Negócios do SAP
SAP HANA
Snowflake ✓ (apenas v2, incluindo o ponto final privado gerido)
SQL Server
SQL Server no Azure Arc
Teradata
Arquivo Amazon S3
HDFS
Serviços e aplicações Dataverse ✓ (apenas v2)
Erwin
Looker ✓ (apenas v2)
Recursos de Infraestrutura ✓ (apenas v2)
Power BI ✓ (apenas v2)
Qlik Sense ✓ (apenas v2)
Salesforce ✓ (apenas v2)
SAP ECC
SAP S/4HANA
Tableau ✓ (apenas v2)