Metodologia de sucesso da implementação Synapse: Avalie o design do pool SQL sem servidor
Nota
Este artigo faz parte da série de artigos de sucesso da implementação do Azure Synapse by design . Para obter uma visão geral da série, consulte Azure Synapse implementation success by design.
Você deve avaliar seu design de pool SQL sem servidor para identificar problemas e validar se ele atende às diretrizes e requisitos. Ao avaliar o design antes do início do desenvolvimento da solução, você pode evitar bloqueadores e alterações inesperadas no projeto. Dessa forma, você protege o cronograma 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 frequentemente usado. Ele proporciona economia de custos e mais flexibilidade, permitindo o dimensionamento independente sob demanda de seu armazenamento e computação. Synapse SQL serverless estende esse padrão adicionando a capacidade de consultar seus dados de data lake diretamente. Não há necessidade de se preocupar com o gerenciamento de computação ao usar tipos de cargas de trabalho de autoatendimento.
Análise de lacunas de ajuste
Ao planejar a implementação de pools sem servidor SQL no Azure Synapse, primeiro você precisa garantir que os pools sem servidor sejam adequados para suas cargas de trabalho. Você deve considerar a excelência operacional, a eficiência de desempenho, a confiabilidade e a segurança.
Excelência operacional
Para excelência operacional, avalie os seguintes pontos.
- Ambiente de desenvolvimento de soluções: Dentro desta metodologia, há uma avaliação do ambiente de desenvolvimento de soluções. Identifique como os ambientes (desenvolvimento, teste e produção) são projetados para dar suporte ao desenvolvimento de soluções. Geralmente, você encontrará ambientes de produção e não produção (para desenvolvimento e teste). Você deve encontrar espaços de trabalho Synapse em todos os ambientes. Na maioria dos casos, você será obrigado a separar seus usuários e cargas de trabalho de produção e desenvolvimento/teste.
- Design do espaço de trabalho Synapse: Dentro desta metodologia, há uma avaliação do design do espaço de trabalho Synapse. Identifique como os espaços de trabalho foram projetados para sua solução. Familiarize-se com o design e saiba se a solução usará um único espaço de trabalho ou se vários espaços de trabalho fazem parte da solução. Saiba por que um design de espaço de trabalho único ou múltiplo foi escolhido. Um design de vários espaços de trabalho é frequentemente escolhido para impor limites de segurança rigorosos.
- Implantação: o SQL serverless está disponível sob demanda em todos os espaços de trabalho do Synapse, portanto, não requer nenhuma ação de implantação especial. Verifique a proximidade regional do serviço e da conta do Azure Data Lake Storage Gen2 (ADLS Gen2) à qual ele está conectado.
- Monitoramento: verifique se o monitoramento interno é suficiente e se algum serviço externo precisa ser implementado para armazenar dados históricos de log. Os dados de log permitem analisar alterações no desempenho e permitem definir alertas ou ações acionadas para circunstâncias específicas.
Eficiência de desempenho
Ao contrário dos mecanismos de banco de dados tradicionais, o SQL serverless não depende de sua própria camada de armazenamento otimizada. Por essa razão, seu desempenho depende fortemente de como os dados são organizados no ADLS Gen2. Para eficiência de desempenho, avalie os seguintes pontos.
- Ingestão de dados: analise como os dados são armazenados no data lake. Os tamanhos dos ficheiros, o número de ficheiros e a estrutura de pastas têm um impacto no desempenho. Lembre-se de que, embora alguns tamanhos de arquivo possam funcionar para SQL sem servidor, eles podem impor problemas para processamento ou consumo eficientes por outros mecanismos ou aplicativos. Você precisará avaliar o design de armazenamento de dados e validá-lo em relação a todos os consumidores de dados, incluindo SQL serverless e quaisquer outras ferramentas de dados que façam parte da sua solução.
- Posicionamento de dados: avalie se seu design unificou e definiu padrões comuns para o posicionamento de dados. Certifique-se de que a ramificação de diretório possa suportar seus requisitos de segurança. Existem alguns padrões comuns que podem ajudá-lo a manter seus dados de séries cronológicas organizados. Seja qual for a sua escolha, certifique-se de que também funciona com outros motores e cargas de trabalho. Além disso, valide se ele pode ajudar na descoberta automática de partições para aplicativos Spark e tabelas externas.
- Formatos de dados: Na maioria dos casos, o SQL serverless oferecerá o melhor desempenho e melhor compatibilidade em termos de recursos usando um formato Parquet. Verifique seus requisitos de desempenho e compatibilidade, porque enquanto o Parquet melhora o desempenho - graças à melhor compactação e redução de E/S (lendo 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 suportam nativamente o Parquet como um formato de exportação, isso pode levar a mais etapas de transformação em seus pipelines e/ou dependências em sua arquitetura geral.
- Exploração: Cada indústria é diferente. Em muitos casos, no entanto, há padrões comuns de acesso a dados encontrados nas consultas executadas com mais frequência. 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 com a quantidade de dados lidos/descartados pelas consultas executadas com mais frequência. Valide se as informações no data lake estão organizadas para favorecer seus requisitos e expectativas de exploração. Para as consultas identificadas em seu design e em sua avaliação, veja se você pode eliminar partições desnecessárias em seu parâmetro de caminho OPENROWSET ou - se houver tabelas externas - se a criação de mais índices pode ajudar.
Fiabilidade
Para maior fiabilidade, avalie os seguintes pontos.
- Disponibilidade: valide quaisquer requisitos de disponibilidade que tenham sido identificados durante a etapa 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 de execução mais longa da sua avaliação e valide-as em relação ao seu design SQL sem servidor. Um tempo limite de 30 minutos pode quebrar as expectativas para sua carga de trabalho e aparecer como um problema de serviço.
- Consistência: SQL serverless é projetado principalmente para cargas de trabalho de leitura. Portanto, valide se todas as verificações de consistência foram realizadas durante o processo de provisionamento e formação de dados do data lake. Mantenha-se a par dos novos recursos, como a camada de armazenamento de código aberto Delta Lake , que fornece suporte para garantias ACID (atomicidade, consistência, isolamento e durabilidade) para transações. Esse recurso permite que você implemente arquiteturas lambda ou kappa eficazes para suportar casos de uso de streaming e em lote. Certifique-se de avaliar seu design em busca de oportunidades para aplicar novos recursos, mas não às custas do cronograma ou custo do seu projeto.
- Backup: analise todos os requisitos de recuperação de desastres identificados durante a avaliação. Valide-os em relação ao seu design SQL sem servidor para recuperação. O SQL serverless em si não tem sua própria camada de armazenamento e isso exigiria o tratamento de instantâneos e cópias de backup de seus dados. O armazenamento de dados acessado pelo SQL sem servidor é externo (ADLS Gen2). Analise o design de recuperação em seu projeto para esses conjuntos de dados.
Segurança
A organização dos seus dados é importante para a construção de bases de segurança flexíveis. Na maioria dos casos, diferentes processos e usuários exigirão permissões e acesso diferentes a subáreas específicas do seu data lake ou data warehouse lógico.
Para segurança, avalie os seguintes pontos.
- Armazenamento de dados: usando as informações coletadas durante o estágio de avaliação, identifique se as áreas típicas do data lake Raw, Stage e Curated precisam ser colocadas na mesma conta de armazenamento em vez de contas de armazenamento independentes. Esta última pode resultar numa maior flexibilidade em termos de funções e permissões. Ele também pode adicionar mais capacidade de operações de entrada/saída por segundo (IOPS) que podem ser necessárias se sua arquitetura tiver que suportar cargas de trabalho de leitura/gravação pesadas e simultâneas (como cenários de IoT ou em tempo real). Valide se você precisa segregar ainda mais mantendo suas áreas de dados mestre e em área restrita em contas de armazenamento separadas. A maioria dos usuários não precisará atualizar ou excluir dados, portanto, não precisará de permissões de gravação no data lake, exceto para áreas restritas e privadas.
- A partir das suas informações de avaliação, identifique se algum requisito depende de recursos de segurança como Always Encrypted, mascaramento dinâmico de dados ou segurança em nível de linha. Valide a disponibilidade desses recursos em cenários específicos, como quando usado com a função OPENROWSET. Antecipe possíveis soluções alternativas que possam ser necessárias.
- A partir das informações da sua 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 o melhor método de autenticação como parte do design.
Outras considerações
Reveja o seu desenho ou modelo e verifique se implementou as melhores práticas e recomendações. Dê atenção especial à otimização e agrupamento de filtros para garantir que a flexão de predicados funcione corretamente.
Próximos passos
No próximo artigo da série Azure Synapse success by design, saiba como avaliar o design do pool do Spark para identificar problemas e validar se ele atende às diretrizes e requisitos.