Guia estratégico de POC do Synapse: data warehouse com pool de SQL dedicado no Azure Synapse Analytics
Este artigo apresenta uma metodologia de alto nível para preparar e executar um projeto de POC (prova de conceito) eficaz do Azure Synapse Analytics para o pool de SQL dedicado.
Observação
Este artigo faz parte da série de artigos Guia estratégico de prova de conceito do Azure Synapse. Para obter uma visão geral da série, consulte Guia estratégico de prova de conceito do Azure Synapse.
Dica
Se você for iniciante com pools de SQL dedicados, recomendamos que trabalhe no roteiro de aprendizagem Trabalhar com Data Warehouses usando o Azure Synapse Analytics.
Preparação para a POC
Antes de decidir sobre suas metas da POC do Azure Synapse, recomendamos primeiro ler o artigo Arquitetura de SQL do Azure Synapse para se familiarizar sobre como um pool de SQL dedicado separa a computação e o armazenamento para fornecer desempenho líder do setor.
Identificar responsáveis e potenciais bloqueios
Quando você estiver familiarizado com o Azure Synapse, é hora de verificar se a POC tem o suporte necessário e não terá empecilhos. Você deve:
- Identificar quaisquer restrições ou políticas que sua organização tenha com relação a mover dados e armazenar dados na nuvem.
- Identificar o patrocínio executivo e empresarial para um projeto de data warehouse baseado em nuvem.
- Verificar se a carga de trabalho é apropriada para o Azure Synapse. Para saber mais, confira Pool de SQL dedicado no Azure Synapse Analytics.
Definir a linha do tempo
Uma POC é um exercício de escopo limitado por tempo com metas e métricas específicas e mensuráveis que definem o sucesso. Idealmente, ela deve ter alguma base na realidade empresarial para que os resultados sejam significativos.
As POCs têm o melhor resultado quando estão em timebox. O timebox aloca uma unidade de tempo fixa e máxima para uma atividade. Em nossa experiência, duas semanas são tempo suficiente para concluir o trabalho sem a obrigação de muitos casos de uso ou matrizes de teste complexas. Ao trabalhar dentro desse período de tempo fixo, sugerimos que você siga esta linha do tempo:
- Carregamento de dados: três dias ou menos
- Consultas: cinco dias ou menos
- Testes de valor agregado: dois dias ou menos
Aqui estão algumas dicas:
- Faça estimativas realistas do tempo necessário para concluir as tarefas em seu plano.
- Reconheça que o tempo para concluir a POC estará relacionado ao tamanho do seu conjunto de dados, ao número de objetos de banco de dados (tabelas, exibições e procedimentos armazenados), à complexidade dos objetos de banco de dados e ao número de interfaces que você testará.
- Se você estimar que sua POC será executada por mais de quatro semanas, considere reduzir o escopo para se concentrar apenas nas metas mais importantes.
- Obtenha suporte de todos os principais recursos e patrocinadores para a linha do tempo antes de iniciar a POC.
Após determinar que não há obstáculos imediatos e definir a linha do tempo, você poderá definir um escopo de uma arquitetura de alto nível.
Criar uma arquitetura com escopo de alto nível
Uma arquitetura futura de alto nível provavelmente conterá muitas fontes de dados e consumidores de dados, componentes de Big Data e, possivelmente, consumidores de dados de IA e aprendizado de máquina. Para manter suas metas de POC alcançáveis (e dentro dos limites da linha do tempo definida), decida quais desses componentes farão parte da POC e quais serão excluídos.
Além disso, caso já esteja usando o Azure, identifique o seguinte:
- Todos os recursos existentes do Azure que você pode usar durante a POC. Por exemplo, os recursos podem incluir o Microsoft Entra ID ou o Azure ExpressRoute.
- Quais regiões do Azure sua organização prefere.
- Uma assinatura que você pode usar para trabalho de POC de não produção.
- A taxa de transferência da sua conexão de rede com o Azure.
Importante
Verifique se sua POC pode consumir parte dessa taxa de transferência sem ter um efeito adverso nas soluções de produção.
Aplicar opções de migração
Se você estiver migrando de um sistema de data warehouse herdado para o Azure Synapse, aqui estão algumas perguntas a serem consideradas:
- Você está migrando e deseja fazer o menor número possível de alterações nos processos ETL (Extrair, Transformar e Carregar) existentes e no consumo do data warehouse?
- Você está migrando, mas deseja fazer algumas melhorias extensas ao longo do percurso?
- Você está criando um ambiente de análise de dados totalmente novo (às vezes chamado de projeto greenfield)?
Em seguida, você precisa considerar seus problemas encontrados.
Identificar os atuais problemas encontrados
Sua POC deve conter casos de uso para comprovar possíveis soluções para resolver seus atuais problemas encontrados. Aqui estão algumas perguntas a serem feitas:
- Quais lacunas na implementação atual você espera que o Azure Synapse preencha?
- Quais são as novas necessidades de negócios que você deve dar suporte?
- Quais SLAs (contratos de nível de serviço) você precisa cumprir?
- Quais serão as cargas de trabalho (por exemplo, ETL, consultas em lote, análise, consultas de relatório ou consultas interativas)?
Em seguida, é necessário definir os critérios de sucesso da POC.
Definir critérios de sucesso da POC
Identifique o motivo de estar fazendo uma POC e certifique-se de definir metas claras. Também é importante saber quais saídas você deseja de sua POC e o que você planeja fazer com elas.
Tenha em mente que uma POC deve ser um esforço curto e focado para comprovar ou testar rapidamente um conjunto limitado de conceitos. Se você tiver uma longa lista de itens para comprovar, talvez queira aprofundá-los em várias POCs. As POCs podem ter portões entre elas para que você possa determinar se deseja prosseguir para a próxima POC.
Aqui estão alguns exemplos de metas de POC:
- Precisamos saber se o desempenho da consulta para nossas consultas de relatórios grandes e complexas atenderá aos nossos novos SLAs.
- Precisamos saber o desempenho de consulta para nossos usuários interativos.
- Precisamos saber se nossos processos de ETL existentes estão bem ajustados e onde há necessidade de fazer melhorias.
- Precisamos saber se podemos reduzir nossos runtimes de ETL e por quanto.
- Precisamos saber se o Synapse Analytics tem recursos de segurança suficientes para proteger adequadamente nossos dados.
Em seguida, é necessário criar um plano de teste.
Criar um plano de deste
Usando suas metas, identifique testes específicos a serem executados para dar suporte a essas metas e fornecer as saídas identificadas. É importante garantir que você tenha pelo menos um teste para cada meta e a saída esperada. Identifique consultas, relatórios, ETL e outros processos específicos que serão executados para fornecer resultados quantificáveis.
Refine seus testes adicionando vários cenários de teste para esclarecer todas as questões de estrutura de tabela que surgirem.
Um bom planejamento geralmente define uma execução efetiva da POC. Verifique se todas as partes interessadas concordam com um plano de teste escrito que vincula cada meta da POC a um conjunto de casos de teste claramente definidos e medidas de sucesso.
A maioria dos planos de teste gira em torno do desempenho e da experiência esperada do usuário. A seguir está um exemplo de um plano de teste. É importante personalizar o plano de teste para atender aos seus requisitos de negócios. Definir claramente o que você está testando será benéfico mais adiante neste processo.
| Goal | Teste | Resultados esperados |
|---|---|---|
| Precisamos saber se o desempenho da consulta para nossas consultas de relatórios grandes e complexas atenderá aos nossos novos SLAs | - Teste sequencial de consultas complexas - Teste de simultaneidade de consultas complexas em relação a SLAs declaradas |
- Consultas A, B e C concluídas em 10, 13 e 21 segundos, respectivamente - Com 10 usuários simultâneos, as consultas A, B e C foram concluídas em 11, 15 e 23 segundos, em média |
| Precisamos saber o desempenho de consulta para nossos usuários interativos | - Teste de simultaneidade de consultas selecionadas em um nível de simultaneidade esperado de 50 usuários. - Execução da consulta anterior com o cache do conjunto de resultados |
- Em 50 usuários simultâneos, espera-se que o tempo médio de execução seja inferior a 10 segundos e sem o cache do conjunto de resultados - Em 50 usuários simultâneos, espera-se que o tempo médio de execução seja inferior a cinco segundos com o cache do conjunto de resultados |
| Precisamos saber se nossos processos de ETL existentes podem ser executados dentro do SLA | - Execução de um ou dois processos de ETL para imitar cargas de produção | - Carregamento incremental em uma tabela de fatos principal deve ser concluído em menos de 20 minutos (incluindo preparo e limpeza de dados) - O processamento de dimensões precisa levar menos de cinco minutos |
| Precisamos saber se o data warehouse tem recursos de segurança suficientes para proteger nossos dados | - Examinar e habilitar a segurança de rede (VNet e pontos de extremidade privados), controle de acesso (segurança em nível de linha, mascaramento dinâmico de dados) | - Comprovar que os dados nunca saem do locatário. - Garantir que o conteúdo do cliente é protegido facilmente |
Em seguida, é necessário identificar e validar o conjunto de dados da POC.
Identificar e validar o conjunto de dados da POC
Usando os testes com escopo, agora é possível identificar o conjunto de dados necessário para executar esses testes no Azure Synapse. Examine seu conjunto de dados considerando o seguinte:
- Verifique se o conjunto de dados representa adequadamente o seu conjunto de dados de produção em termos de conteúdo, complexidade e escala.
- Não use um conjunto de dados muito pequeno (menor que 1 TB), pois talvez você não obtenha um desempenho representativo.
- Não use um conjunto de dados muito grande, pois o objetivo da POC não é concluir uma migração completa de dados.
- Identifique o padrão de distribuição, a opção de indexação e o particionamento para cada tabela. Se houver alguma dúvida sobre distribuição, indexação ou particionamento, adicione testes à POC para respondê-los. Tenha em mente que talvez você queira testar mais de uma opção de distribuição ou de indexação para algumas tabelas.
- Verifique com os proprietários de negócios se há impedimentos para mover o conjunto de dados da POC para a nuvem.
- Identifique as preocupações de segurança ou de privacidade.
Importante
Verifique com os proprietários de negócios se há impedimentos antes de mover os dados para a nuvem. Identifique todas as preocupações de segurança ou de privacidade ou necessidades de ofuscação de dados que devem ser feitas antes de mover dados para a nuvem.
Em seguida, é necessário montar a equipe de especialistas.
Montar a equipe
Identifique os membros da equipe e compromisso deles em apoiar sua POC. Os membros da equipe devem incluir:
- Um gerente de projeto para executar o projeto de POC.
- Um representante comercial para supervisionar os requisitos e os resultados.
- Um especialista em dados de aplicativos para obter os dados do conjunto de dados da POC.
- Um especialista do Azure Synapse.
- Um consultor especialista para otimizar os testes de POC.
- Qualquer pessoa que será necessária para tarefas específicas do projeto de POC, mas não por toda a sua duração. Esses recursos de suporte podem incluir administradores de rede, administradores do Azure ou administradores do Microsoft Entra.
Dica
É recomendável contratar um consultor especialista para auxiliar em seu POC. A comunidade de parceiros da Microsoft tem disponibilidade global de consultores especialistas que podem ajudá-lo a apurar, avaliar ou implementar o Azure Synapse.
Agora que você está totalmente preparado, chegou a hora de colocar sua POC em prática.
Colocar a POC em prática
É importante ter em mente o seguinte:
- Implemente seu projeto de POC com a disciplina e o rigor de qualquer projeto de produção.
- Execute a POC de acordo com o plano.
- Tenha um processo de solicitação de alteração vigente para impedir que o escopo da POC cresça ou mude.
Antes de iniciar os testes, é necessário configurar o ambiente de teste. Isso envolve quatro estágios:
- Instalação
- Carregamento de dados
- Consultas
- Testes de valor agregado
Instalação
Você pode configurar uma POC no Azure Synapse seguindo estas etapas:
- Use este início rápido para provisionar um workspace do Synapse e configurar armazenamento e permissões de acordo com o plano de teste da POC.
- Use este início rápido para adicionar um pool de SQL dedicado ao workspace do Synapse.
- Configure a rede e segurança de acordo com suas necessidades.
- Conceda acesso apropriado aos membros da equipe da POC. Confira este artigo sobre autenticação e autorização para acessar pools de SQL dedicados.
Dica
Recomendamos a você desenvolver código testes de unidade usando o nível de serviço DW500c (ou abaixo). Recomendamos a você executar testes de carga e desempenho usando o nível de serviço DW1000c (ou superior). Você pode pausar a computação do pool de SQL dedicado a qualquer momento para interromper a cobrança de computação, o que economizará nos custos.
Carregamento de dados
Depois de configurar o pool de SQL dedicado, você pode seguir estas etapas para carregar dados:
- Carregue os dados no Armazenamento de Blobs do Azure. Para uma POC, recomendamos usar uma conta de armazenamento V2 de uso geral com LRS (armazenamento com redundância local). Embora existam várias ferramentas para migrar dados para o Armazenamento de Blobs do Azure, a maneira mais fácil é usar o Gerenciador de Armazenamento do Azure, que pode copiar arquivos para um contêiner de armazenamento.
- Carregue os dados no pool de SQL dedicado. O Azure Synapse dá suporte a dois métodos de carregamento T-SQL: PolyBase e a instrução COPY. Você pode usar o SSMS para se conectar ao pool de SQL dedicado para usar qualquer um dos métodos.
Ao carregar dados no pool de SQL dedicado pela primeira vez, é necessário considerar qual padrão de distribuição e opção de índice usar. Embora um pool de SQL dedicado dê suporte a uma variedade de ambos, é uma melhor prática confiar nas configurações padrão. As configurações padrão usam distribuição round robin e um índice columnstore clusterizado. Se necessário, é possível ajustar essas configurações mais tarde, as quais são descritas posteriormente neste artigo.
O exemplo a seguir mostra o método de carga COPY:
--Note when specifying the column list, input field numbers start from 1
COPY INTO
test_1 (Col_1 default 'myStringDefault' 1, Col_2 default 1 3)
FROM
'https://myaccount.blob.core.windows.net/myblobcontainer/folder1/'
WITH (
FILE_TYPE = 'CSV',
CREDENTIAL = (IDENTITY = 'Storage Account Key' SECRET = '<Your_Account_Key>'),
FIELDQUOTE = '"',
FIELDTERMINATOR = ',',
ROWTERMINATOR = '0x0A',
ENCODING = 'UTF8',
FIRSTROW = 2
);
Consultas
A principal finalidade de um data warehouse é executar análise, o que requer consultar o data warehouse. A maioria das POCs começa executando um pequeno número de consultas representativas no data warehouse, primeiro sequencialmente e, em seguida, simultaneamente. Você precisa definir ambas as abordagens em seu plano de teste.
Testes de consultas sequenciais
É fácil executar testes de consultas sequenciais no SSMS. É importante executar esses testes utilizando um usuário com uma classe de recurso suficientemente grande. Classes de recursos são limites de recursos predeterminados no pool de SQL dedicado que controlam recursos de computação e simultaneidade para execução da consulta. Para consultas simples, recomendamos usar a classe de recurso staticrc20 predefinida. Para consultas mais complexas, recomendamos usar a classe de recurso staticrc40 predefinida.
Observe que a primeira consulta a seguir usa um rótulo de consulta para fornecer um mecanismo para acompanhar a consulta. A consulta a seguir usa o modo de exibição de gerenciamento dinâmico sys.dm_pdw_exec_requests para pesquisar pelo rótulo.
/* Use the OPTION(LABEL = '') Syntax to add a query label to track the query in DMVs */
SELECT TOP (1000)
*
FROM
[dbo].[Date]
OPTION (LABEL = 'Test1');
/* Use sys.dm_pdw_exec_requests to determine query execution duration (ms) */
SELECT
Total_elapsed_time AS [Elapsed_Time_ms],
[label]
FROM
sys.dm_pdw_exec_requests
WHERE
[label] = 'Test1';
Testes de consultas simultâneas
Após registrar o desempenho de consulta sequencial, execute várias consultas simultaneamente. Dessa forma, é possível simular uma carga de trabalho de business intelligence em execução no pool de SQL dedicado. A maneira mais fácil de executar esse teste é baixar uma ferramenta de teste de estresse. A ferramenta mais popular é o Apache JMeter, que é uma ferramenta de código aberto de terceiros.
A ferramenta relata durações mínimas, máximas e medianas de consulta para um determinado nível de simultaneidade. Por exemplo, suponha que você queira simular uma carga de trabalho de business intelligence que gere 100 consultas simultâneas. Você pode configurar o JMeter para executar essas 100 consultas simultâneas em um loop e, em seguida, examinar a execução em estado estável. Isso pode ser feito com o cache do conjunto de resultados ativado ou desativado para avaliar a adequação desse recurso.
Certifique-se de documentar os resultados. Aqui está um exemplo de alguns resultados:
| Simultaneidade | Nº de consultas executadas | DWU | Durações mínimas | Durações máximas | Durações medianas |
|---|---|---|---|---|---|
| 100 | 1,000 | 5\.000 | 3 | 10 | 5 |
| 50 | 5\.000 | 5\.000 | 3 | 6 | 4 |
Testes de cargas de trabalho mistas
O teste de carga de trabalho mista é uma extensão dos testes de consultas simultâneas. Ao adicionar um processo de carregamento de dados à mistura de cargas de trabalho, a carga de trabalho simulará melhor uma carga de trabalho de produção real.
Otimizar os dados
Dependendo da carga de trabalho de consulta em execução no Azure Synapse, talvez seja necessário otimizar as distribuições e índices do data warehouse e executar novamente os testes. Para saber mais, consulte Melhores práticas para pools de SQL dedicados no Azure Synapse Analytics.
Os erros mais comuns vistos durante a configuração são:
- Consultas grandes são executadas com uma classe de recurso muito baixa.
- As DWUs de nível de serviço do pool de SQL dedicado são muito baixas para a carga de trabalho.
- Tabelas grandes exigem distribuição de hash.
Para aprimorar o desempenho de consulta, você pode:
- Criar exibições materializadas, as quais podem acelerar consultas que envolvem agregações comuns.
- Replicar tabelas, especialmente para tabelas de dimensões pequenas.
- Distribuir em hash tabelas de fatos grandes que são unidas ou agregadas.
Testes de valor agregado
Depois que o teste de desempenho de consulta for concluído, será um bom momento para testar recursos específicos para verificar se eles satisfazem os casos de uso pretendidos. Esses recursos incluem:
- Segurança em nível de linha
- Segurança ao nível da coluna
- Mascaramento de dados dinâmicos
- Escala intra-cluster por meio de isolamento da carga de trabalho
Por fim, é necessário interpretar os resultados da POC.
Interpretar os resultados da POC
Após obter os resultados de teste para o data warehouse, é importante interpretar esses dados. Uma abordagem comum que você pode adotar é comparar as execuções em termos de preço/desempenho. Simplificando, o preço/desempenho elimina as diferenças de preço por DWU ou hardware de serviço e fornece um único número comparável para cada teste de desempenho.
Veja um exemplo:
| Teste | Duração do teste | DWU | $/h para DWU | Custo do teste |
|---|---|---|---|---|
| Teste 1 | 10 min | 1000 | $ 12/h | U$2 |
| Teste 2 | 30 min | 500 | $ 6/h | U$3 |
Este exemplo facilita ver que o Teste 1 na DWU1000 é mais econômico em $ 2 por execução de teste, em comparação com $ 3 por execução de teste.
Observação
Também é possível usar essa metodologia para comparar resultados entre fornecedores em uma POC.
Em resumo, após concluir todos os testes de POC, você estará pronto para avaliar os resultados. Comece avaliando se as metas da POC foram atingidas e se as saídas desejadas foram coletadas. Anote onde os testes adicionais são garantidos e as questões adicionais que foram levantadas.