Metodologia de sucesso de implementação do Azure Synapse: avaliar o design do pool de SQL sem servidor

Observação

Este artigo faz parte da série de artigos Sucesso por design da implementação do Azure Synapse. Para obter uma visão geral da série, confira Sucesso da implementação do Azure Synapse no design.

Você deve avaliar o design do pool de SQL sem servidor para identificar problemas e validar se ele atende às diretrizes e aos requisitos. Ao avaliar o design antes do início do desenvolvimento da solução, você pode evitar bloqueadores e alterações inesperadas de design. Dessa forma, você protege a linha do tempo e o orçamento do projeto.

A separação arquitetônica de armazenamento e computação para dados modernos, plataformas analíticas e serviços tem sido uma tendência e um padrão usado com frequência. Ela oferece economia de custos e mais flexibilidade, permitindo o dimensionamento independente sob demanda do armazenamento e da computação. O SQL do Synapse sem servidor estende esse padrão adicionando a funcionalidade para consultar os dados do data lake diretamente. Não é necessário se preocupar com o gerenciamento de computação ao usar tipos de cargas de trabalho de autoatendimento.

Análise de adequação e lacuna

Ao planejar a implementação de pools de SQL sem servidor no Azure Synapse, primeiro você precisa garantir que os pools sem servidor sejam adequados às cargas de trabalho. Considere a excelência operacional, a eficiência de desempenho, a confiabilidade e a segurança.

Excelência operacional

Quanto à excelência operacional, avalie os pontos a seguir.

• Ambiente de desenvolvimento de solução: dentro dessa metodologia, há uma avaliação do ambiente de desenvolvimento da solução. Identifique como os ambientes (desenvolvimento, teste e produção) são projetados para dar suporte ao desenvolvimento de soluções. Normalmente, você encontrará ambientes de produção e não produção (para desenvolvimento e teste). Os workspaces do Azure Synapse serão encontrados em todos os ambientes. Na maioria dos casos, você será obrigado a separar os usuários e as cargas de trabalho de produção e de desenvolvimento/teste.
• Design do workspace do Azure Synapse: dentro dessa metodologia, há uma avaliação do Design do workspace do Azure Synapse. Identifique como os workspaces foram projetados para sua solução. Familiarize-se com o design e saiba se a solução usará um workspace individual ou se vários workspaces fazem parte da solução. Entenda por que foi escolhido um design de workspace individual ou de vários workspaces. Um design de vários workspaces geralmente é escolhido para impor limites de segurança estritos.
• Implantação: o SQL sem servidor está disponível sob demanda em cada workspace do Azure Synapse, portanto, não requer nenhuma ação de implantação especial. Verifique a proximidade regional do serviço e da conta do ADLS Gen2 (Azure Data Lake Storage Gen2) à qual ele está conectado.
• Monitoramento: verifique se o monitoramento interno é suficiente e se algum serviço externo precisa ser colocado em vigor para armazenar dados de log históricos. Os dados de log permitem analisar alterações no desempenho e definir alertas ou ações disparadas em circunstâncias específicas.

Eficiência do desempenho

Ao contrário dos mecanismos de banco de dados tradicionais, o SQL sem servidor não depende da própria camada de armazenamento otimizada. Por esse motivo, seu desempenho depende muito de como os dados são organizados no ADLS Gen2. Quanto à eficiência de desempenho, avalie os pontos a seguir.

• Ingestão de dados: examine como os dados são armazenados no data lake. O tamanho dos arquivos, o número de arquivos e a estrutura de pastas afetam o desempenho. Tenha em mente que, embora alguns tamanhos de arquivo possam funcionar para o SQL sem servidor, eles podem impor problemas ao processamento ou consumo eficiente em outros mecanismos ou aplicativos. Você precisará avaliar o design do armazenamento de dados e validá-lo em relação a todos os consumidores de dados, incluindo o SQL sem servidor e outras ferramentas de dados que façam parte da solução.
• Posicionamento de dados: avalie se o design tem padrões comuns unificados e definidos para posicionamento de dados. Verifique se a ramificação de diretório dá suporte aos seus requisitos de segurança. Há alguns padrões comuns que ajudam a manter os dados de série temporal organizados. Seja qual for a sua escolha, verifique se ela também funciona com outros mecanismos e cargas de trabalho. Além disso, valide se ela pode ajudar na descoberta automática de partição para aplicativos Spark e tabelas externas.
• Formatos de dados: na maioria dos casos, o SQL sem servidor oferecerá o máximo desempenho e uma compatibilidade melhor entre recursos usando o formato Parquet. Verifique seus requisitos de desempenho e compatibilidade, pois embora o Parquet aprimore o desempenho, graças à melhoria da compactação e da redução de E/S (por ler apenas as colunas necessárias para análise), ele requer mais recursos de computação. Além disso, como alguns sistemas de origem não dão suporte nativo ao Parquet como formato de exportação, essa opção pode causar mais etapas de transformação nos pipelines e/ou nas dependências na arquitetura geral.
• Exploração: cada setor é diferente. Mas, em muitos casos, há padrões comuns de acesso a dados encontrados nas consultas com execução mais frequente. Os padrões normalmente envolvem filtragem e agregações por datas, categorias ou regiões geográficas. Identifique seus critérios de filtragem mais comuns e relacione-os à quantidade de dados que são lidos/descartados pelas consultas com execução mais frequente. Valide se as informações sobre o data lake estão organizadas para favorecer os requisitos e as expectativas de exploração. Nas consultas identificadas no design e na avaliação, veja se você pode eliminar partições desnecessárias no parâmetro de caminho OPENROWSET ou, caso haja tabelas externas, se a criação de mais índices pode ajudar.

Confiabilidade

Quanto à confiabilidade, avalie os pontos a seguir.

• Disponibilidade: valide todos os requisitos de disponibilidade que foram identificados durante a fase de avaliação. Embora não haja SLAs específicos para SQL sem servidor, há um tempo limite de 30 minutos para a execução da consulta. Identifique as consultas com execução mais longa na avaliação e valide-as em relação ao design do SQL sem servidor. Um tempo limite de 30 minutos pode não atender às expectativas relacionadas à carga de trabalho e aparecer como um problema de serviço.
• Consistência: o SQL sem servidor foi projetado principalmente para cargas de trabalho de leitura. Portanto, valide se todas as verificações de consistência foram executadas durante o processo de provisionamento e formação de dados do data lake. Esteja sempre a par das novas funcionalidades, como a camada de armazenamento de software livre do Delta Lake, que dá suporte para garantias de ACID (atomicidade, consistência, isolamento, durabilidade) nas transações. Essa funcionalidade permite que você implemente arquiteturas lambda ou kappa eficazes para dar suporte a casos de uso de streaming e de lote. Avalie o design quanto a oportunidades de aplicar novas funcionalidades, mas sem prejudicar a linha do tempo ou o custo do projeto.
• Backup: examine todos os requisitos de recuperação de desastre que foram identificados durante a avaliação. Valide-os em relação ao design de recuperação do SQL sem servidor. O SQL sem servidor não tem a própria camada de armazenamento e isso exigiria o processamento de instantâneos e de cópias de backup dos dados. O armazenamento de dados acessado pelo SQL sem servidor é externo (ADLS Gen2). Examine o design de recuperação no projeto em relação a esses conjuntos de dados.

Segurança

A organização dos dados é importante para a criação de bases de segurança flexíveis. Na maioria dos casos, processos e usuários diferentes exigirão permissões diferentes e acesso a subáreas específicas do data lake ou do data warehouse lógico.

Quanto à segurança, avalie os pontos a seguir.

• Armazenamento de dados: usando as informações reunidas durante a fase de avaliação, identifique se as áreas típicas do data lake Bruta, De preparo e Coletada precisam ser colocadas na mesma conta de armazenamento e não em contas de armazenamento independentes. Essa última opção pode resultar em mais flexibilidade em termos de funções e permissões. Ela também pode adicionar mais operações de IOPS (entrada/saída por segundo) que poderão ser necessárias se a arquitetura precisar dar suporte a cargas de trabalho de leitura/gravação intensivas e simultâneas (como cenários de IoT ou em tempo real). Valide se você precisa de mais segregação para manter as áreas de dados restritas e mestras em contas de armazenamento separadas. A maioria dos usuários não precisará atualizar nem excluir dados, portanto, eles não precisam de permissões de gravação no data lake, exceto nas áreas restritas e privadas.
• Nas informações de avaliação, identifique se os requisitos dependem de recursos de segurança, como Always Encrypted, Máscara Dinâmica de Dados ou Segurança em Nível de Linha. Valide a disponibilidade desses recursos em cenários específicos, como quando usados com a função OPENROWSET. Antecipe possíveis soluções alternativas que possam ser necessárias.
• Nas informações de avaliação, identifique quais seriam os melhores métodos de autenticação. Considere as entidades de serviço do Microsoft Entra, a assinatura de acesso compartilhado (SAS) e quando e como a passagem de autenticação pode ser usada e integrada na ferramenta de exploração de escolha do cliente. Avalie o design e valide se o melhor método de autenticação está sendo usado.

Outras considerações

Examine o design e verifique se você colocou em prática as melhores práticas e recomendações. Dê atenção especial à otimização de filtro e à ordenação para garantir que o pushdown do predicado funcione corretamente.

Próximas etapas

No próximo artigo da série Sucesso do Azure Synapse no design, saiba como avaliar o design do Pool do Spark para identificar problemas e validar se ele atende às diretrizes e aos requisitos.