Metodologia de sucesso da implementação do Synapse: Avaliar o design do espaço de trabalho

O espaço de trabalho Synapse é uma experiência gráfica unificada do usuário que une seus mecanismos analíticos e de processamento de dados, data lakes, bancos de dados, tabelas, conjuntos de dados e artefatos de relatório, juntamente com a orquestração de código e processos. Considerando o número de tecnologias e serviços integrados ao espaço de trabalho Synapse, certifique-se de que os principais componentes estejam incluídos no seu design.

Revisão do design do espaço de trabalho Synapse

Identifique se o design da solução envolve um espaço de trabalho Synapse ou vários espaços de trabalho. Determine os drivers desse design. Embora possa haver diferentes motivos, na maioria dos casos, o motivo para vários espaços de trabalho é a segregação de segurança ou a segregação de cobrança. Ao determinar o número de espaços de trabalho e os limites do banco de dados, lembre-se de que há um limite de 20 espaços de trabalho por assinatura.

Identifique quais elementos ou serviços em cada espaço de trabalho precisam ser compartilhados e com quais recursos. Os recursos podem incluir data lakes, tempos de execução de integração (IRs), metadados ou configurações e código. Determine por que esse design específico foi escolhido em termos de sinergias potenciais. Pergunte-se se essas sinergias justificam o custo extra e as despesas gerais de gestão.

Revisão do projeto do data lake

Recomendamos que o data lake (se fizer parte da sua solução) seja hierarquizado corretamente. Você deve dividir seu data lake em três áreas principais relacionadas aos conjuntos de dados Bronze, Prata e Ouro. O Bronze - ou a camada bruta - pode residir em sua própria conta de armazenamento separada porque tem controles de acesso mais rígidos devido a dados confidenciais não mascarados que pode armazenar.

Revisão do projeto de segurança

Analise o design de segurança do espaço de trabalho e compare-o com as informações coletadas durante a avaliação. Certifique-se de que todos os requisitos são cumpridos e que todas as restrições foram tidas em conta. Para facilitar o gerenciamento, recomendamos que os usuários sejam organizados em grupos com perfis de permissões apropriados: você pode simplificar o controle de acesso usando grupos de segurança que se alinham com funções. Dessa forma, os administradores de rede podem adicionar ou remover usuários de grupos de segurança apropriados para gerenciar o acesso.

Os pools SQL sem servidor e as tabelas do Apache Spark armazenam seus dados em um contêiner do Azure Data Lake Gen2 (ADLS Gen2) associado ao espaço de trabalho. As bibliotecas do Apache Spark instaladas pelo usuário também são gerenciadas nessa mesma conta de armazenamento. Para habilitar esses casos de uso, os usuários e a identidade de serviço gerenciado (MSI) do espaço de trabalho devem ser adicionados à função de Colaborador de Dados de Blob de Armazenamento do contêiner de armazenamento ADLS Gen2. Verifique este requisito em relação aos seus requisitos de segurança.

Pools SQL dedicados fornecem um rico conjunto de recursos de segurança para criptografar e mascarar dados confidenciais. Os pools SQL dedicados e sem servidor habilitam a área de superfície completa das permissões do SQL Server, incluindo funções internas, funções definidas pelo usuário, autenticação SQL e autenticação do Microsoft Entra. Analise o design de segurança para o pool SQL dedicado da sua solução e o acesso e os dados do pool SQL sem servidor.

Reveja o plano de segurança para o seu data lake e todas as contas de armazenamento ADLS Gen2 (e outras) que farão parte da sua solução Azure Synapse Analytics. O armazenamento ADLS Gen2 não é em si um mecanismo de computação e, portanto, não tem uma capacidade interna de mascarar seletivamente atributos de dados. Você pode aplicar permissões do ADLS Gen2 no nível da conta de armazenamento ou do contêiner usando o RBAC (controle de acesso baseado em função) e/ou no nível de pasta ou arquivo usando listas de controle de acesso (ACLs). Reveja o design cuidadosamente e esforce-se para evitar complexidade desnecessária.

Aqui estão alguns pontos a considerar para o design de segurança.

• Verifique se os requisitos de configuração do Microsoft Entra ID estão incluídos no design.
• Verifique se há cenários entre locatários. Esses problemas podem surgir porque alguns dados estão em outro locatário do Azure, ou precisam ser movidos para outro locatário, ou precisam ser acessados por usuários de outro locatário. Certifique-se de que esses cenários sejam considerados em seu projeto.
• Quais são as funções para cada espaço de trabalho? Como eles usarão o espaço de trabalho?
• Como a segurança é projetada dentro do espaço de trabalho?
  • Quem pode visualizar todos os scripts, blocos de anotações e pipelines?
  • Quem pode executar scripts e pipelines?
  • Quem pode criar/pausar/retomar pools SQL e Spark?
  • Quem pode publicar alterações no espaço de trabalho?
  • Quem pode confirmar alterações no controle do código-fonte?
• Os pipelines acessarão os dados usando credenciais armazenadas ou a identidade gerenciada do espaço de trabalho?
• Os usuários têm o acesso apropriado ao data lake para navegar pelos dados no Synapse Studio?
• O data lake está adequadamente protegido usando a combinação apropriada de RBAC e ACLs?
• As permissões de usuário do pool SQL foram definidas corretamente para cada função (cientista de dados, desenvolvedor, administrador, usuário corporativo e outros)?

Revisão do design de rede

Aqui estão alguns pontos a considerar para o design da rede.

• A conectividade é projetada entre todos os recursos?
• Qual é o mecanismo de rede a ser usado (Azure ExpressRoute, Internet pública ou pontos de extremidade privados)?
• Você precisa ser capaz de se conectar com segurança ao Synapse Studio?
• A exfiltração de dados foi levada em consideração?
• Você precisa se conectar a fontes de dados locais?
• Você precisa se conectar a outras fontes de dados na nuvem ou mecanismos de computação, como o Azure Machine Learning?
• Os componentes de rede do Azure, como NSGs (grupos de segurança de rede), foram revisados para conectividade e movimentação de dados adequadas?
• A integração com as zonas DNS privadas foi levada em consideração?
• Você precisa ser capaz de navegar no data lake de dentro do Synapse Studio ou simplesmente consultar dados no data lake com SQL ou PolyBase sem servidor?

Por fim, identifique todos os seus consumidores de dados e verifique se a conectividade deles é contabilizada no design. Verifique se os postos avançados de rede e segurança permitem que seu serviço acesse as fontes locais necessárias e se seus protocolos e mecanismos de autenticação são suportados. Em alguns cenários, talvez seja necessário ter mais de um gateway de dados ou IR auto-hospedado para soluções SaaS, como o Microsoft Power BI.

Monitorização da revisão do projeto

Analise o design do monitoramento dos componentes do Azure Synapse para garantir que eles atendam aos requisitos e expectativas identificados durante a avaliação. Verifique se o monitoramento de recursos e acesso a dados foi projetado e se ele identifica cada requisito de monitoramento. Uma solução de monitoramento robusta deve ser implementada como parte da primeira implantação na produção. Dessa forma, as falhas podem ser identificadas, diagnosticadas e resolvidas em tempo hábil. Além da infraestrutura de base e das execuções de pipeline, os dados também devem ser monitorados. Dependendo dos componentes do Azure Synapse em uso, identifique os requisitos de monitoramento para cada componente. Por exemplo, se os pools do Spark fizerem parte da solução, monitore o armazenamento de registros malformado. 

Aqui estão alguns pontos a considerar para o design de monitoramento.

• Quem pode monitorar cada tipo de recurso (pipelines, pools e outros)?
• Por quanto tempo os logs de atividade do banco de dados precisam ser mantidos?
• O espaço de trabalho e a retenção de logs do banco de dados usarão o Log Analytics ou o Armazenamento do Azure?
• Os alertas serão acionados em caso de erro de pipeline? Em caso afirmativo, quem deve ser notificado?
• Qual nível de limite de um pool SQL deve disparar um alerta? Quem deve ser notificado?

Revisão do projeto de controle do código-fonte

Por padrão, um espaço de trabalho Synapse aplica alterações diretamente ao serviço Synapse usando a funcionalidade de publicação interna. Você pode habilitar a integração do controle do código-fonte, o que oferece muitas vantagens. As vantagens incluem melhor colaboração, controle de versão, aprovações e pipelines de liberação para promover alterações em ambientes de desenvolvimento, teste e produção. O Azure Synapse permite um único repositório de controle de origem por espaço de trabalho, que pode ser o Azure DevOps Git ou o GitHub.

Aqui estão alguns pontos a considerar para o design de controle do código-fonte.

• Se estiver usando o Azure DevOps Git, o espaço de trabalho Synapse e seu repositório estarão no mesmo locatário?
• Quem poderá acessar o controle do código-fonte?
• Quais permissões serão concedidas a cada usuário no controle do código-fonte?
• Foi desenvolvida uma estratégia de ramificação e fusão?
• Os pipelines de liberação serão desenvolvidos para implantação em diferentes ambientes?
• Será utilizado um processo de aprovação para a fusão e para as condutas de libertação?

Próximos passos

No próximo artigo da série Azure Synapse success by design, saiba como avaliar o design de integração de dados e validar se ele atende às diretrizes e requisitos.