Guia Estratégico de Prova de Conceito Do Azure Synapse Analytics

White paper
Guia estratégico de
prova de conceito do
Azure Synapse Analytics
Guia estratégico de prova de conceito do Azure Synapse Analytics 2
03 / 22
22
Identifique os recursos da POC
Defina um cronograma para a POC
23 Execute o projeto de POC
Resumo executivo 24 Avaliar e apresentar os resultados
24 Próximas etapas
24 Referências
04 /
Data Warehousing com pool 25 /
de SQL dedicado
4 Preparação para a prova de conceito
Análise de big data com o pool
4 Identifique patrocinadores e potenciais blockers do Apache Spark
5 Definição do cronograma 25 Preparação para a prova de conceito
6 riação de uma arquitetura com escopo de prova de conceito
C 27 Definir as metas para a POC
de alto nível 30 Planeje o projeto de POC
6 Considerações de migração 33 Avalie o conjunto de dados da POC
7 Identificação dos pontos problemáticos atuais 33 Crie uma arquitetura de alto nível para a sua POC
7 Definição das metas 34 Identifique os recursos da POC
8 Criação de um plano de teste 35 Defina o cronograma da POC
9 Identificar e validar o conjunto de dados de prova de conceito 35 Execute o projeto de POC
10 Montar sua equipe 37 Avaliar e apresentar os resultados
11 Colocando em prática 37 Próximas etapas
11 Configuração 38 References
12 Carregamento de dados
13 Consulta
15
15
Testes de valor agregado
Interpretação dos resultados
39 /
Conclusão
16 /
Exploração de data lake com pool de
SQL sem servidor
16 Preparação para a prova de conceito
18 Definir as metas para a POC
20 Planeje o projeto de POC
21 Avalie o conjunto de dados da POC
21 Crie uma arquitetura de alto nível para a sua POC
Resumo executivo
Seja uma migração de data warehouse corporativo, uma redefinição de plataformas de big
data ou uma implementação de áreas novas; cada projeto normalmente começa com uma
prova de conceito.
Este guia estratégico de prova de conceito fornece uma metodologia de alto nível para planejar,
preparar e rodar um projeto de prova de conceito eficaz. Uma prova de conceito eficaz valida
o fato de que certos conceitos têm o potencial para aplicação de produção prática. O objetivo
geral de uma prova de conceito é validar possíveis soluções para problemas técnicos, como
a forma pela qual os sistemas podem ser integrados ou como os resultados podem ser
alcançados por meio de uma configuração específica.
Este guia estratégico ajudará você a avaliar o uso do Azure Synapse Analytics para a migração
de um workload existente. Ele foi criado com os seguintes leitores em mente:
• Especialistas técnicos que planejam um projeto interno pessoal de prova de conceito
do Azure Synapse
• Proprietários de empresas que farão parte da execução ou avaliação de um projeto
de prova de conceito do Azure Synapse
• Qualquer pessoa que procure saber mais sobre projetos de prova de conceito de data
warehouse
O guia estratégico fornecerá o seguinte:

• Orientação sobre o que torna uma prova de conceito eficaz
• Orientação sobre como fazer comparações válidas entre sistemas
• Orientação sobre os aspectos técnicos da operação de uma prova de conceito do
Azure Synapse
• Um roteiro para conteúdo técnico relevante do Azure Synapse
• Orientação sobre como avaliar resultados de prova de conceito para apoiar decisões
de negócios
• Orientação sobre como obter ajuda adicional
Vamos começar.
Data Warehousing com pool

de SQL dedicado
Preparação para a prova de conceito
Antes de passar pelo processo de criação de metas para o Azure Synapse Analytics POC,
vale a pena reservar um tempo para entender os recursos do serviço e como eles se aplicam
à sua POC. Para aproveitar ao máximo o tempo de execução da POC, leia sobre isso na Visão
geral do serviço. Além disso, convém ler a Visão geral arquitetônica de pools de SQL do
Azure Synapse para se familiarizar com a forma como pools de SQL separam a computação
e o armazenamento para oferecer performance líder da indústria.
Por fim, assista aos nossos vídeos e verifique casos de uso e novos comunicados sobre
o Azure Synapse.
Identifique patrocinadores e potenciais blockers

Agora você está familiarizado com o Azure Synapse. É hora de garantir que a prova de
conceito tenha o apoio necessário, sem obstáculos.
É hora de:
• Identificar as restrições ou diretrizes da organização sobre a movimentação de dados para
a nuvem.
• Identificar o patrocínio executivo e de negócios para um projeto de data warehouse
baseado em nuvem.
• Verificar se o workload é adequado ao Azure Synapse. Leia mais aqui.
Definição do cronograma
Uma prova de conceito é um exercício com escopo, temporário, com metas específicas
mensuráveis e métricas de sucesso. O ideal é que se baseie na realidade dos negócios
para que os resultados sejam significativos.
Em nossa experiência, a prova de conceitos tem o melhor resultado quando é condensada

em duas semanas. Isso dá tempo suficiente para que o trabalho seja concluído sem
a sobrecarga de casos de uso e matrizes de teste complexas.
Ao respeitar esse cronograma, você pode seguir esta agenda aproximada:

• Carregamento: três dias ou menos
• Consulta: cinco dias ou menos
• Testes de valor agregado: dois dias ou menos
Essa agenda serve mais como diretriz do que regra.
Veja algumas dicas:

• Faça estimativas realistas do tempo necessário para concluir as tarefas no seu plano.
• O tempo para concluir a prova de conceito será influenciado pelo tamanho do conjunto
de dados, o número de objetos do banco de dados (por exemplo, tabelas, exibições
e procedimentos armazenados), a complexidade dos objetos do banco de dados
e o número de interfaces testadas.
• Se você acredita que a prova de conceito leve mais de quatro semanas, procure reduzir
o escopo para se concentrar nas metas de maior prioridade.
• Obtenha o apoio de todos os recursos de lead e patrocinadores para o cronograma antes
de continuar.
Após determinar que não há bloqueadores imediatos e definir o cronograma, vamos passar
para o escopo de uma arquitetura.
Criação de uma arquitetura com escopo de prova de conceito de alto nível

Sua arquitetura futura de alto nível provavelmente conterá muitas fontes de dados, inúmeros
consumidores de dados, componentes de Big Data e, possivelmente, consumidores de
machine learning e de dados de IA. Para que a meta da prova de conceito continue viável
no cronograma definido, decida quais desses componentes farão parte da prova de conceito
e quais serão excluídos dele.
Além disso, se você já estiver usando o Azure, precisará identificar o seguinte:

• Os recursos disponíveis no Azure (por exemplo, Azure Active Directory, ExpressRoute)
que possam ser usados durante a prova de conceito.
• As regiões do Azure que a organização prefere.
• Uma assinatura de trabalho de prova de conceito, que não seja de produção.
• A taxa de transferência da conexão de rede para o Azure. Além disso, verifique com
outros usuários corporativos se a prova de conceito pode consumir parte dessa taxa
de transferência sem prejudicar as soluções de produção.
Considerações de migração
Se você estiver migrando de um sistema de data warehouse herdado para o Azure Synapse,
considere as seguintes perguntas:
• Você está migrando e deseja fazer o mínimo possível de alterações no extrato, na
transformação, no processo de carga (ETL) e no consumo de data warehouse existentes?
• Você está migrando, mas deseja fazer várias melhorias ao longo do caminho?
• Você está criando um ambiente de data warehouse totalmente novo (áreas novas)?
Em seguida, você precisa considerar os pontos problemáticos.

Identificação dos pontos problemáticos atuais

Sua prova de conceito deve conter casos de uso para demonstrar soluções potenciais
para abordar os pontos problemáticos atuais. Algumas perguntas a considerar:
• Quais lacunas na implementação atual esperamos que o Azure Synapse preencha?
• Que novas necessidades de negócios você precisa apoiar?
• Quais contratos de nível de serviço (SLAs) você precisa cumprir?
• Quais serão os workloads (por exemplo, ETL, consultas em lote, análises, consultas
de relatórios ou consultas interativas)?
A próxima etapa é definir as metas.
Definição das metas

Identifique por que você está criando uma prova de conceito e escreva metas claras. Antes
de iniciar o serviço, é importante saber os resultados desejados com a prova de conceito
e o que fará com eles.
Lembre-se de que uma prova de conceito deve ser um esforço breve e focado para provar
ou testar rapidamente um conjunto limitado de conceitos. Se você tem uma longa lista de
itens para provar, talvez queira mais do que uma prova de conceito com portões entre eles,
em que determina se precisa do próximo.
Aqui estão alguns exemplos de metas de prova de conceito:

• Precisamos saber que a performance da consulta para consultas de relatórios grandes
e complexas atenderá aos novos SLAs.
• Precisamos saber a performance da consulta dos usuários interativos.
• Precisamos saber se os processos ETL existentes são adequados e onde são necessários
aprimoramentos.
• Precisamos saber se e até que ponto podemos encurtar os tempos de execução de ETL.
• Precisamos saber que o data warehouse corporativo (EDW) tem recursos de segurança
suficientes para proteger nossos dados.
A próxima etapa é planejar os testes.

Criação de um plano de teste

Usando suas metas, identifique testes específicos para execução a fim de dar suporte a essas
metas e fornecer os resultados identificados. É importante garantir que você tenha pelo menos
um teste para dar suporte a cada objetivo e ao resultado esperado. Identifique consultas,
relatórios, ETL e outros processos específicos que serão executados para que um conjunto
de dados muito específico possa ser identificado.
Refine testes adicionando vários cenários de teste para esclarecer eventuais perguntas
da estrutura de tabela.
A execução eficaz de prova de conceito costuma ser definida por um bom planejamento.
Verifique se todos os stakeholders concordam com um plano de teste escrito que vincula
cada objetivo de prova de conceito a um conjunto de casos de teste e medições de sucesso
declarados de forma clara.
A maioria dos planos de teste giram em torno da performance e da experiência de usuário

esperada. Veja a seguir um exemplo de plano de teste. É importante personalizar o plano
de teste para atender aos seus requisitos de negócios. Definir claramente o que você está
testando compensará mais tarde neste processo.
Meta Teste Resultados esperados
• Precisamos saber • Teste sequencial de • As consultas A, B e C terminaram

que a performance consultas "complexas" em 10, 13 e 21 segundos,
da consulta para • Teste de simultaneidade respectivamente
consultas de de consultas complexas • Com 10 usuários simultâneos,
relatórios grandes em relação a SLAs as consultas A, B e C terminaram
e complexas atenderá declarados em 11, 15 e 23 segundos,
aos novos SLAs em média
• Precisamos saber • Teste de simultaneidade • Com 50 usuários simultâneos,
a performance da de consultas espera-se que o tempo médio
consulta dos usuários selecionadas em um de execução seja inferior
interativos nível de simultaneidade a 10 segundos e sem cache
esperado de 50 com conjunto de resultados
usuários • Com 50 usuários simultâneos,
• Execute o cache espera-se que o tempo médio
anterior com conjunto de execução seja inferior
de resultados a cinco segundos com cache
com conjunto de resultados
Meta Teste Resultados esperados
• Precisamos saber • Execute um ou dois • O carregamento incremental

se os processos ETL processos ETL para para uma tabela de fatos
existentes podem ser imitar as cargas principal deve ser concluído em
executados no SLA de produção menos de 20 minutos (incluindo
a preparação e a limpeza
de dados)
• O processamento dimensional
precisa levar menos de cinco
minutos
• Precisamos saber • Revise e habilite • Comprove que os dados
que o EDW tem a segurança de rede nunca deixam nosso locatário
recursos de segurança (VNET e pontos de • Garanta que a PII seja facilmente
suficientes para extremidade privados), protegida
proteger nossos segurança de dados
dados (row-level security,
máscara de dados
dinâmicos)
A próxima etapa é identificar seu conjunto de dados.
Identificar e validar o conjunto de dados de prova de conceito

Nos testes com escopo, você pode identificar os dados necessários no Azure Synapse para
executar esses testes. Agora, dedique algum tempo para revisar este conjunto de dados,
considerando o seguinte:
• Você precisa verificar se o conjunto de dados representará adequadamente o processamento
futuro no Azure Synapse em conteúdo, complexidade e escala.
• Não use um conjunto de dados muito pequeno (com menos 1 TB), pois não terá
performance representativa.
• Não use um conjunto de dados muito grande, pois sua prova de conceito não se destina
a concluir a migração completa de dados.
• Identifique o padrão de distribuição e a opção de indexação para cada tabela.
• Em caso de dúvidas sobre distribuição, Indexação ou particionamento, adicione testes
à prova de conceito para responder as perguntas.
• Lembre-se de que talvez você queira testar mais de uma opção de distribuição ou opção
de indexação para determinadas tabelas.
• Verifique com os empresários se há bloqueadores para migrar esses dados para a nuvem.
• Identifique preocupações de segurança ou privacidade.
Em seguida, você precisa montar uma equipe.
Montar sua equipe

Identifique especificamente os membros da equipe necessários e o compromisso
exigido para dar suporte à prova de conceito. Os membros da equipe devem incluir:
• Um gerente de projeto para executar o projeto de prova de conceito.
• Um representante de negócios para supervisionar os requisitos e os resultados.
• Um especialista em dados de aplicação para obter os dados para a prova de conceito.
• Um especialista no Azure Synapse.
• Um consultor especializado para otimizar os testes de prova de conceito.
• Os recursos necessários para componentes específicos do projeto de prova de conceito, mas
não necessariamente exigidos o tempo todo. Esses recursos podem incluir administradores
de rede, administradores do Azure e administradores do Active Directory.
Já que você está avaliando uma nova plataforma, recomendamos interagir com um consultor
especialista para ajudar na prova de conceito. A comunidade de parceiros da Microsoft tem
disponibilidade global de consultores especializados, prontos para demonstrar os recursos
e a performance do Azure Synapse Analytics.
Agora que você está totalmente preparado, é hora de colocar a prova de conceito em prática.
Colocando em prática
É importante lembrar-se de:
• Implementar o projeto de prova de conceito com a disciplina e o rigor de qualquer projeto
de produção.
• Executá-lo de acordo com o plano.
• Ter um processo de solicitação de mudança no local para evitar a expansão e mudanças
da prova de conceito além do controle.
Configuração
Antes de começar os testes, você precisa configurar o ambiente de teste e carregar os dados:
Carregamento Testes de
Configuração Consulta
de dados valor agregado
Configurar uma prova de conceito no Azure Synapse é tão fácil quanto clicar em alguns botões.
Execute as seguintes etapas:

• No portal do Azure, siga este tutorial para criar um pool de SQL do Azure Synapse.
• Garanta que os firewalls do pool de SQL estejam abertos para o computador cliente.
• Faça o download e instale o SQL Server Management Studio (SSMS).
Ao configurar o pool de SQL, você pode definir as Unidades de Data Warehouse (DWUs).
As DWUs variam de 100 a 30.000 e definem as características de performance do pool de SQL.
Esse valor pode ser alterado a qualquer momento pela escala do pool de SQL.
Sugerimos o desenvolvimento de testes de código e unidade em DW500c ou inferior

e a execução de testes de carga e performance em DW1000c ou superior. Em qualquer
ponto, você pode pausar o pool de SQL para reduzir custos.
Carregamento de dados
Agora que o pool de SQL foi criado, é hora de carregar alguns dados.
Faça o seguinte:
• Se você ainda não tiver feito isso, carregue alguns dados em um blob de Armazenamento
do Azure. Aconselhamos o uso de um blob de armazenamento V2 de uso geral com
armazenamento localmente redundante para uma prova de conceito. Há várias ferramentas
para migrar dados para um blob de Armazenamento do Azure. A maneira mais fácil
é usar o Gerenciador de Armazenamento do Azure e copiar arquivos no contêiner de
armazenamento.
• Agora que você tem dados no contêiner de armazenamento do Azure, pode carregá-los
no pool de SQL. O Azure Synapse oferece suporte a dois métodos de carregamento T-SQL:
PolyBase e instrução COPY.
Para carregar dados, você precisa se conectar ao pool de SQL do Azure Synapse por meio
de uma ferramenta, como SSMS. Após conectar-se ao banco de dados, você poderá usar
PolyBase ou a instrução COPY INTO.
Ao carregar dados pela primeira vez em pools SQL do Azure Synapse, uma dúvida comum
é quanto à distribuição e ao índice a serem escolhidos. Embora pools de SQL do Azure Synapse
ofereçam suporte a ambos, é uma prática recomendada usar os padrões de distribuição
alternada e o índice columnstore clusterizado. A partir daqui, você pode ajustar seu ambiente,
assunto que será abordado em uma seção posterior.
Este é um exemplo de COPY INTO:

-- Observe que, ao especificar a lista de colunas, os números de campo de entrada
começam por 1
COPY INTO test_1 (Col_one default ‘myStringDefault’ 1, Col_two 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
)
Vamos falar sobre a consulta.
Consulta
O principal objetivo da verificação de um data warehouse é a obtenção de análises a partir dos
dados. Então, vejamos como aproveitar ao máximo o banco de dados. A maioria das provas
de conceitos começam com um pequeno número de consultas representativas em relação
ao data warehouse, primeiro em sequência e, depois, simultaneamente. Isso deve ser definido
no plano de teste.
Teste de consulta sequencial

É muito fácil executar consultas sequencialmente com o SSMS. É importante executar esses
testes com um usuário que tenha uma classe de recurso suficientemente grande. Para consultas
simples, é recomendável o Static 20. Para consultas mais complexas, sugerimos o Static 40.
A consulta SQL a seguir usa um rótulo de consulta para rastrear a primeira consulta em
Exibições de Gerenciamento Dinâmico (DMV). Depois, ela usa sys.dm_pdw_exec_requests
para determinar a duração da execução da consulta:
Dica útil: usar um rótulo de consulta é uma ótima maneira de rastrear as consultas.
/* Use a sintaxe OPTION(LABEL = ‘’) para adicionar um rótulo de consulta para rastrear
a consulta em DMVs */
SELECT TOP (1000) * FROM [dbo].[Date] OPTION (LABEL = ‘Test1’)
/* Use sys.dm_pdw_exec_requests para determinar a duração da execução da consulta (ms) */
Selecione Total_elapsed_time como [Elapsed_Time_ms],
[label]
FROM sys.dm_pdw_exec_requests
ONDE [label] = ‘Test1’
Teste de consulta simultâneo

Após a performance de consulta única de linha de base, muitos clientes avaliam a execução
de várias consultas de leitura simultaneamente. O objetivo é imitar um cenário de business
intelligence executado no pool de SQL. A maneira mais fácil de executar esse teste é fazer
o download de uma ferramenta de teste de estresse. A ferramenta mais conhecida para
isso é o Apache JMeter.
Um resultado esperado deste teste é um tempo de execução mínimo, máximo e médio

em determinado nível de simultaneidade. Por exemplo, suponha que você queira imitar
um workload de business intelligence que gere 100 consultas simultâneas. Você configuraria
JMeter para executar essas 100 consultas simultâneas em um loop e analisaria a execução
de estado estável. Isso pode ser feito com o armazenamento do conjunto de resultados
em cache para mostrar os benefícios desse recurso.
Documente os resultados que mostrem claramente os resultados.
№ de
Duração Duração Duração
Simultaneidade consultas DWU
mínima (s) máxima (s) média (s)
executadas
100 1.000 5.000 3 10 5
50 5.000 5.000 3 6 4
Teste de workload misto

O teste de workload misto é simplesmente uma adição ao teste de consulta simultâneo.
Ao adicionar uma declaração de atualização de dados, como algo do processo de carregamento,
à mistura de workload, o workload simula melhor um workload de produção real.
Ajuste dos testes de consulta

Dependendo do workload de consulta em andamento no Azure Synapse, talvez seja necessário
ajustar as distribuições e os índices do data warehouse. Para obter orientação, consulte nosso
Guia de práticas recomendadas.
Estes são os erros mais comuns observados durante a configuração:

• Consultas grandes são executadas com uma classe de recursos muito pequena.
• Os DWUs são pequenos demais para o workload.
• Tabelas grandes exigem distribuição de hash.
Estas são alterações de ajuste comuns que podem ser aplicadas:

• As exibições materializadas são usadas para acelerar agregações comuns.
• Replicar tabelas de pequena dimensão.
• Distribuir em hash grandes tabelas de fatos que são associadas ou agregadas.
Vejamos testes de valor agregado.

Testes de valor agregado

Depois que o teste de performance de preço principal for concluído, é um bom momento
para testar recursos específicos para verificar se eles atendem ao caso de uso pretendido.
Os recursos costumam ser os seguintes:
• Segurança em nível de coluna
• Row-level security
• Máscara de dados dinâmicos
• Escala intracluster por meio do isolamento do workload
Por fim, você precisa interpretar os resultados.
Interpretação dos resultados

Agora que você tem dados brutos referentes à performance do data warehouse, é importante
contextualizar esses dados. Uma tática comum é comparar as execuções em termos de preço/
performance. Simplificando, preço/performance remove 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 performance.
Vejamos um exemplo:
Duração USD/hr
Teste DWU Custo do teste
do teste para DWU
Teste 1 10 min 1.000 USD 12/hr USD 2
Teste 1 30 min 500 USD 6/hr USD 3
No exemplo anterior, é possível perceber que a execução do Teste 1 em DWU1000 é mais

rentável, com USD 2 por execução de teste, em vez de USD 3 por execução de teste. Essa
metodologia pode ser usada para comparar resultados entre fornecedores em um cenário
de prova de conceito.
Resumindo, ao concluir todos os testes de prova de conceito, a próxima etapa será avaliar
os resultados:
• Comece avaliando se as metas de prova de conceito foram atendidas e os resultados
desejados coletados.
• Anote onde são necessários testes adicionais ou onde problemas adicionais foram levantados.
Exploração de data lake com pool de

SQL sem servidor
Um projeto de prova de conceito (PoC) pode ajudar você a tomar uma decisão de negócios
embasada sobre a implementação de um ambiente de big data e Advanced Analytics em
uma plataforma baseada em nuvem, aproveitando a funcionalidade do pool de SQL sem
servidor no Azure Synapse.
Se você precisar explorar dados no data lake, obter insights a partir dele ou otimizar seu
pipeline de transformação de dados existente, poderá se beneficiar do uso do recurso
pool de SQL sem servidor. Ele é adequado para os seguintes cenários:
• Descoberta e exploração básica – argumentar rapidamente sobre os dados em vários
formatos (Parquet, CSV, JSON) em seu data lake, para que você possa planejar como
extrair insights dele.
• Data warehouse lógico – forneça uma abstração relacional sobre dados brutos ou díspares
sem realocar e transformar dados, permitindo uma visão sempre atualizada deles.
• Transformação de dados – maneira simples, escalável e eficiente de transformar dados
no lake usando T-SQL, para que possa ser alimentado com BI e outras ferramentas, ou
carregado em um armazenamento de dados relacional (pools de SQL dedicados em
Sinapse Azure, banco de dados Azure SQL, etc.).
Diferentes funções profissionais podem se beneficiar do pool de SQL sem servidor:

• Os engenheiros de dados podem explorar o lake, transformar e preparar dados usando
esse serviço e simplificar seus pipelines de transformação de dados.
• Os cientistas de dados podem rapidamente argumentar sobre o conteúdo e a estrutura dos
dados no lake, graças a recursos como OPENROWSET e inferência automática de esquema.
• Os analistas de dados podem explorar dados e tabelas externas Spark criadas por cientistas
ou engenheiros de dados usando a linguagem T-SQL familiar ou suas ferramentas favoritas,
que podem se conectar ao pool de SQL sem servidor.
• Os profissionais de BI podem criar rapidamente relatórios do Power BI com base nos
dados nas tabelas do Spark e do lake.
Em apoio aos seus cenários de negócios, um projeto POC de pool de SQL sem servidor
identificará seus principais objetivos e drivers de negócios com os quais um pool de
SQL sem servidor está alinhado para oferecer suporte, além de testar os principais recursos
e coletar métricas para apoiar suas decisões de implementação.
Uma prova de conceito é um projeto rapidamente executado que se concentra em questões-

chave e não se destina à implantação em um ambiente de produção, mas sim à execução
de testes rápidos e ao descarte posterior.
Antes de começar a planejar seu projeto POC de pool de SQL sem servidor, faça o seguinte:
• Identifique as restrições ou diretrizes da organização sobre a migração de dados para
a nuvem.
• Identifique o patrocínio executivo/empresarial de um projeto de plataforma de big data
e soluções analíticas garanta que haja suporte para serem migrados para a nuvem.
• Identifique a disponibilidade de usuários de negócios e SME técnicos para oferecer suporte
a você e fornecer detalhes durante a execução da POC.
A essa altura, você já deve ter determinado que não há bloqueadores imediatos e poderá
começar a se preparar para a POC. Se você não conhece o pool de SQL sem servidor do
Azure Synapse Analytics, consulte a documentação do pool de SQL sem servidor, que
fornece uma visão geral dos recursos e benefícios.
Se você não conhece os pools de SQL sem servidor no Azure Synapse, solicite os
seguintes materiais de aprendizagem:
Criar soluções de análise de dados usando pools de SQL sem servidor do Azure Synapse
Definir as metas para a POC

Um projeto POC bem-sucedido exige planejamento. Identifique por que você está fazendo
uma POC, as motivações reais para ele (como modernização, economia de custos, melhoria
de performance, experiência integrada, etc.). Anote metas claras para a POC e quais critérios
definirão o sucesso dela. Quais resultados da POC você deseja e o que você fará com eles?
Quem utilizará os resultados? O que definirá uma PoC bem-sucedida?
Tenha em mente que uma POC deve ser um esforço breve e focado para provar ou testar
rapidamente um conjunto limitado de conceitos e recursos – o que é representativo do
workload global. Se você tem uma longa lista de itens para provar, talvez queira mais do
que uma POC com portões entre elas, em que você determina se precisa da próxima POC.
Consideradas as diferentes funções profissionais que podem fazer uso de um pool de SQL sem
servidor e os vários cenários onde ele pode ser usado, você pode optar por planejar e executar
várias POCs, incluindo pool de SQL sem servidor; uma concentrada nos cenários do cientista
de dados, como a descoberta e a exploração de dados em vários formatos, outra voltada para
as necessidades da engenharia de dados, como a transformação de dados, e outra que explore
a criação de um data warehouse lógico.
Ao considerar a POC, tenha em mente algumas das seguintes perguntas para ajudar
a moldar seus objetivos:
• Você está migrando de uma plataforma de soluções analíticas e big data existente (seja
na infraestrutura local ou na nuvem)?
• Você está migrando e deseja fazer o menor número possível de alterações na ingestão
e no processamento de dados existentes?
• Você está migrando, mas deseja fazer várias melhorias ao longo do caminho?
• Você está desenvolvendo uma plataforma de soluções analíticas e big data totalmente
nova (nova oportunidade)?
• Quais são seus problemas atuais, se houver – como escalabilidade, performance,
flexibilidade, etc.?
• Quais SLAs você precisa cumprir?

• Quais serão os workloads – exploração de dados de vários formatos, exploração básica,
um data warehouse lógico, preparação e/ou transformação de dados, análise interativa
T-SQL, consulta TSQL de tabelas do Spark, relatórios de consultas sobre o data lake?
• Quais são as habilidades dos usuários que serão os proprietários do projeto depois
que a POC se tornar real?
Alguns EXEMPLOS da configuração de metas da POC

• Por que estamos elaborando uma POC?
- Precisamos saber se todos os formatos de arquivos brutos que recebermos poderão
ser explorados usando o pool de SQL sem servidor
- Precisamos saber se nossos engenheiros de dados podem avaliar rapidamente
novos feeds de dados
- Precisamos saber se a performance da consulta de dados do data lake que usa
o pool de SQL sem servidor atenderá às nossas necessidades de exploração de dados
- Precisamos saber se o pool de SQL sem servidor é uma boa escolha para algumas
de nossas visualizações e relatórios
- Precisamos saber se o pool de SQL sem servidor é uma boa escolha para
algumas de nossas necessidades de processamento e ingestão de dados
- A migração para o Azure Synapse atenderá às nossas metas de custo
• Ao final desta PoC:
- Teremos os dados para identificar as transformações de dados adequadas ao pool
de SQL sem servidor
- Teremos os dados para identificar onde o servidor pode ser mais bem utilizado
durante a visualização de dados
- Teremos os dados para saber se será fácil para os nossos engenheiros e cientistas
de dados adotarem a nova plataforma
- Teremos obtido insights para estimar melhor o esforço necessário para concluir
a implementação do projeto de migração completo
- Teremos uma lista de itens que poderão precisar de mais testes
Nossa POC será bem-sucedida se tivermos os dados necessários e concluirmos os testes

identificados para determinar como o pool de SQL sem servidor no Azure Synapse oferecerá
suporte à nossa plataforma de big data e Advance Analytics baseada em nuvem. Teremos
determinado se podemos passar para a próxima fase ou se serão necessários testes adicionais
da POC para finalizar nossa decisão. Poderemos tomar uma decisão de negócios sólida apoiada
pelos pontos de dados.
Planeje o projeto de POC

Usando seus objetivos, identifique os testes específicos a serem executados para apoiar
essas metas e fornecer os resultados identificados. É importante garantir que você tenha
pelo menos um teste para apoiar cada objetivo e resultado esperado. Identifique tarefas
de exploração e análise de dados específicas, determinadas transformações, processamento
existente específico que você deseja testar para que um conjunto de dados e base de
código muito específicos possam ser identificados.
Exemplo do nível de especificidade necessário no planejamento:

• (Objetivo) Precisamos saber se a equipe de engenharia de dados pode executar
o processamento equivalente do processo ETL existente "Validação diária de arquivos
brutos em lote" dentro do SLA necessário.
• (Resultado) Teremos os dados para determinar se o TSQL sem servidor pode ser usado
para executar os requisitos de "Validação de arquivos brutos de lote diário" do nosso
processamento existente e atender ao seu SLA.
- (Teste) As consultas de validação A, B e C são identificadas pela equipe de engenharia
de dados e representam as necessidades gerais de processamento de dados. Compare
a performance dessas consultas com o benchmark obtido do sistema existente.
Avalie o conjunto de dados da POC

A partir dos testes específicos identificados, agora você pode identificar o conjunto de
dados necessário para apoiar esses testes. Dedique um tempo para revisar esse conjunto
de dados. Agora você precisa verificar se o conjunto de dados representará adequadamente
o processamento futuro em conteúdo, complexidade e escala. Não use um conjunto de dados
muito pequeno, pois não terá performance representativa. Não use um conjunto de dados
muito grande, pois durante a execução da POC não é o momento para concluir a migração
completa de dados. Obtenha também os benchmarks apropriados dos sistemas existentes,
que você usará para comparações de performance.
Verifique com os empresários se há bloqueadores para migrar esses dados para a nuvem.
Identifique todas as preocupações de segurança ou privacidade ou necessidades de
ofuscação de dados que precisam ser atendidas antes de migrar dados para a nuvem.
Crie uma arquitetura de alto nível para a sua POC

Com base na arquitetura de alto nível de sua arquitetura de estado futura proposta,
identifique os componentes que farão parte da POC. Sua arquitetura de estado futuro de
alto nível provavelmente contém muitas fontes de dados, inúmeros consumidores de dados,
componentes de big data e, possivelmente, consumidores de machine learning e de dados de
IA. Crie uma arquitetura para a POC que identifique especificamente os componentes que farão
parte dela e identifique claramente quais componentes não farão parte dos testes da POC.
Se você já estiver usando o Azure, identifique todos os recursos já disponíveis (Azure Active
Directory, ExpressRoute, etc.) que possam ser usados durante a POC. Também identifique
as regiões do Azure utilizadas pela sua organização. Agora é um ótimo momento para
identificar a taxa de transferência da sua conexão ExpressRoute e verificar com outros usuários
de negócios que sua POC pode consumir parte dessa taxa de transferência sem efeito
adverso nas soluções de produção.
Identifique especificamente os recursos técnicos e os compromissos relativos ao tempo que

serão necessários para apoiar a POC.
• Um representante de negócios para supervisionar os requisitos e os resultados

• Um especialista em dados de aplicações para fornecer os dados para a POC e fornecer
conhecimento do processo/lógica existente
• Um especialista em pool de SQL sem servidor do Azure Synapse
• Um consultor especializado para otimizar os testes da POC
• Os recursos necessários para componentes específicos do projeto de POC, mas não
necessariamente exigidos por toda a duração da POC. Esses recursos podem incluir
recursos de administração da rede, recursos de administração do Azure, administradores
do Active Directory, administradores do Portal do Azure, etc.
• Garanta que todos os recursos necessários dos serviços do Azure tenham sido provisionados
e que o nível de acesso necessário tenha sido fornecido a esses serviços, incluindo o acesso
a contas de armazenamento
• Garanta que você tenha uma conta que tenha a permissão de acesso a dados necessária
para extrair dados de todas as fontes de dados no escopo da POC
especialista para ajudar na POC. A comunidade de parceiros da Microsoft tem disponibilidade
global de consultores especializados, prontos para demonstrar os recursos e a performance
do Azure Synapse. Você pode encontrar parceiros locais em Solution Providers Home.
Defina um cronograma para a POC

Revise os detalhes do planejamento da POC e das necessidades de negócios para identificar
uma restrição de tempo para a POC. Faça estimativas realistas do tempo necessário para
concluir as tarefas no seu plano. O tempo para concluir a POC será influenciado pelo tamanho
do seu conjunto de dados da POC, o número de testes, a complexidade e o número de interfaces
que você está testando, etc. Se você achar que a execução da sua POC levará mais de 4 semanas,
considere a redução do escopo para manter o foco nos objetivos de maior prioridade. Obtenha
o apoio de todos os recursos de lead e patrocinadores para o cronograma antes de continuar.
Execute o projeto de POC

Execute o projeto de POC com a disciplina e o rigor de qualquer projeto de produção.
Execute-o de acordo com o plano e tenha um processo de solicitação de alteração em
vigor para evitar que a POC aumente e fique fora de controle.
Exemplo de tarefas de alto nível

• Provisionar espaço de trabalho Synapse, contas de armazenamento e todos os recursos
do Azure identificados no plano de POC
• Configurar a rede e a segurança de acordo com os requisitos
• Fornecer o acesso necessário ao ambiente para membros da equipe da POC
• Carregar o conjunto de dados da POC
• Implementar e configurar testes identificados e/ou migrar o código existente para scripts
e exibições do pool de SQL sem servidor
• Executar testes
- Muitos testes podem ser executados em paralelo
- Registrar seus resultados em um formato consumível e prontamente compreensível
• Monitorar para solução de problemas e performance
• Avaliar os resultados e apresentar as descobertas
• Planejar as próximas etapas
Avaliar e apresentar os resultados

Quando todos os testes de POC forem concluídos, você poderá avaliar os resultados. Comece
avaliando se as metas de POC foram atendidas e os resultados desejados coletados. Observe
onde são necessários testes adicionais ou onde surgiram problemas adicionais.
Próximas etapas
Trabalhe com stakeholders técnicos e empresas para planejar a próxima fase do projeto,
seja uma POC de acompanhamento ou a implementação de produção.
Referências
• Pool de SQL sem servidor no Azure Synapse Analytics
• Criar soluções de análise de dados usando pools de SQL sem servidor do Azure Synapse
• Solution Providers Home

Análise de big data com o pool

do Apache Spark
Um projeto de prova de conceito (PoC) pode ajudar você a tomar uma decisão de negócios
embasada sobre a migração da sua plataforma de big data e soluções analíticas na
infraestrutura local para um serviço de big data e Advanced Analytics baseado em nuvem,
aproveitando o Azure Synapse Analytics para workloads do Apache Spark.
Um projeto de POC do Spark identificará suas metas principais e os impulsionadores de

negócios aos quais a plataforma de big data e soluções analíticas baseada em nuvem
deve oferecer suporte, além de testar as principais métricas e comprovar os principais
comportamentos que são fundamentais para o sucesso de sua engenharia de dados,
necessidades de criação de modelos de machine learning e treinamento, etc. Uma prova de
conceito é um projeto rapidamente executado que se concentra em questões-chave e não
se destina à implantação em um ambiente de produção, mas sim à execução de testes rápidos
e ao descarte posterior.
Antes de começar a planejar o projeto de POC do Spark, faça o seguinte:

• Identifique as restrições ou diretrizes da organização sobre a migração de dados para
a nuvem.
• Identifique o patrocínio executivo/empresarial de um projeto de plataforma de big data
e soluções analíticas e garanta que haja suporte para serem migrados para a nuvem.
• Identifique a disponibilidade de usuários de negócios ou SMEs técnicos para oferecer
suporte a você e fornecer detalhes durante a execução da POC.
A essa altura, você já deve ter determinado que não há bloqueadores imediatos e poderá
começar a se preparar para a POC do Spark. Se você não conhece os Pools do Apache
Spark no Azure Synapse Analytics, consulte esta documentação para obter uma visão
geral da arquitetura Spark e saber como ela funciona no Azure Synapse.
Desenvolva uma compreensão destes conceitos-chave:

• Apache Spark e sua arquitetura distribuída
• Conceitos de RDD e partições (in-memory e físicas) no Spark
• Espaço de trabalho do Azure Synapse, diferentes mecanismos de computação,
pipeline e monitoramento
• Separação de computação e armazenamento no pool do Spark
• Autenticação e autorização no Azure Synapse
• Conectores nativos para integração com o pool de SQL dedicado no Azure Synapse,
no Azure Cosmos DB, etc.
O Azure Synapse dissocia os recursos de computação do armazenamento para que você

possa gerenciar melhor suas necessidades de processamento de dados e controlar os
custos. Com a arquitetura sem servidor do pool do Spark, você pode montar e desmontar,
aumentar ou reduzir o cluster do Spark, seja qual for o armazenamento. É possível pausar
inteiramente (ou configurar a pausa automática) em um cluster do Spark para que você
pague por computação somente quando estiver em uso e, quando não estiver, só pagar
pelo armazenamento. Você pode aumentar o cluster do Spark para atender a necessidades
de processamento de grandes volumes de dados ou cargas e, em seguida, reduzi-lo durante
intervalos de processamento menos intenso ou desligá-lo completamente quando não for
necessário. É possível escalá-lo e pausá-lo de forma eficaz para reduzir os custos. Seus testes
de POC Spark devem incluir a ingestão e o processamento de dados em diferentes escalas
(pequenas, médias e grandes) para comparar preço e performance em uma variedade de
escalas. Leia sobre como escalar automaticamente os pools do Azure Synapse Analytics
Apache Spark para saber mais.
Entender a diferença entre diferentes conjuntos de APIs do Spark ajudará a decidir o que
funciona melhor para seu cenário, e você poderá escolher um deles para obter melhor
performance ou facilidade de uso ou aproveitar os conjuntos de habilidades já existentes das
suas equipes. Leia Um conto de três APIs do Apache Spark: RDDs vs DataFrames e conjuntos
de dados.
O particionamento de dados e arquivos funciona um pouco diferente no Spark e a compreensão

das diferenças ajudará a otimizar a performance. Leia Descoberta de partições e Opções de
configuração de partições para saber mais.
Definir as metas para a POC

Um projeto POC bem-sucedido exige planejamento. Identifique por que você está fazendo
uma POC, as motivações reais para ele (como modernização, economia de custos, melhoria
de performance, experiência integrada, etc.). Anote metas claras para a POC e quais critérios
definirão o sucesso dela. Quais resultados da POC você deseja e o que você fará com eles?
Quem utilizará os resultados? O que definirá uma POC bem-sucedida?
Tenha em mente que uma POC deve ser um esforço breve e focado para provar ou testar
rapidamente um conjunto limitado de conceitos e recursos – o que é representativo do
workload global. Se você tem uma longa lista de itens para provar, talvez queira mais do que
uma POC com portões entre elas, em que você determina se precisa da próxima POC. Para
o exemplo de POC do Spark, você pode ter duas POCs, a primeira concentrada em engenharia
de dados (ingestão e processamento), e a segunda concentrada em desenvolvimento de
modelos de machine learning.
Ao considerar a POC, tenha em mente algumas das seguintes perguntas para ajudar
a moldar seus objetivos:
• Você está migrando de uma plataforma de soluções analíticas e big data existente (seja
na infraestrtura local ou na nuvem)?
• Você está migrando e deseja fazer o mínimo de alterações no processamento de dados
e ingestão existente, por exemplo, se é uma migração de Spark para Spark ou uma
migração do Hadoop/Hive para Spark?
• Você está migrando, mas deseja fazer algumas melhorias extensas durante o processo, por
exemplo, reescrever trabalhos do MapReduce ou do Spark, ou converter código baseado
em RDD herdado para código baseado em Dataframe/conjunto de dados, etc.?
• Você está desenvolvendo uma plataforma de soluções analíticas e big data totalmente
nova (nova oportunidade)?
• Quais são seus problemas atuais, se houver – como escalabilidade, performance,
flexibilidade, etc.?

• Quais SLAs você precisa cumprir?
• Quais serão os workloads: ETL, processamento em lotes, processamento de fluxo,
treinamento de modelo de machine learning, ferramentas analíticas, relatórios de
consultas, consultas interativas?
• Quais são as habilidades dos usuários que serão os proprietários do projeto após a POC
se tornar real (habilidades do PySpark vs Scala, experiência em Notebook vs IDE, etc.)?
Alguns EXEMPLOS da configuração de metas da POC

• Por que estamos elaborando uma POC?
- Precisamos saber que a performance do processamento e da ingestão de dados para
nosso workload de big data atenderá aos novos SLAs.
- Precisamos saber se o processamento de fluxo próximo ao tempo real é possível e qual
é a taxa de transferência compatível. Ele apoiará nossos requisitos de negócios?
- Precisamos saber se nossos processos de transformação e ingestão de dados existentes
são adequados e onde serão necessários aprimoramentos.
- Precisamos saber se e até que ponto podemos encurtar os tempos de execução de
integração de dados.
- Precisamos saber se nossos cientistas de dados podem criar e treinar modelos de
machine learning e aproveitar bibliotecas de IA/ML conforme necessário no pool
do Spark e usar o pool de SQL, AML ou Azure Kubernetes para a implantação de
modelos treinados para fazer a pontuação.
- A migração para o Synapse baseado em nuvem atenderá às nossas metas de custo?
• Ao final desta POC:

- Teremos os dados para determinar se nossos requisitos de performance de
processamento de dados (para lote e fluxo em tempo real) poderão ser atendidos.
- Teremos testado a ingestão e o processamento de todos os nossos diferentes tipos
de dados (estruturados, semi e não estruturados) que oferecem suporte aos nossos
casos de uso.
- Teremos testado uma parte de nosso processamento complexo de dados e poderemos

identificar o trabalho que precisará ser concluído para migrar nosso portfólio de
integração de dados para o novo ambiente.
- Teremos testado a ingestão e o processamento de dados e teremos os pontos de
dados para calcular o esforço necessário para a migração inicial e a carga de dados
históricos, bem como calcular o esforço necessário para migrar nossa ingestão de
dados (ADF, Distcp, Databox, etc.).
- Teremos testado a ingestão e o processamento de dados e poderemos determinar
se nossos requisitos de processamento de ETL/ELT poderão ser atendidos.
- Teremos obtido insights para estimar melhor o esforço necessário para concluir
a implementação do projeto.
- Teremos testado opções de escala e dimensionamento e teremos os pontos de dados
para configurar melhor nossa plataforma para obter melhores configurações de preço/
performance.
- Teremos uma lista de itens que poderão precisar de mais testes.
Nossa POC será bem-sucedida se tivermos os dados necessários e concluirmos os testes

identificados para determinar se o Azure Synapse Analytics oferecerá suporte à nossa
plataforma de big data baseada e soluções analíticas em nuvem. Teremos determinado
se podemos passar para a próxima fase ou se serão necessários testes adicionais da POC
para finalizar nossa decisão. Poderemos tomar uma decisão de negócios sólida apoiada
pelos pontos de dados.
Planeje o projeto de POC

Usando suas metas, identifique testes específicos a serem executados para oferecer suporte
a essas metas e fornecer os resultados identificados conforme necessário para tomar
decisões baseadas em dados. É importante garantir que você tenha pelo menos um teste
para dar suporte a cada objetivo e ao resultado esperado. Identifique a ingestão de dados,
o processamento em lotes ou de fluxo de dados específicos e todos os outros processos que
serão executados para que um conjunto de dados e uma base de código muito específicos
possam ser identificados. Esse conjunto de dados e base de código específicos definirão
o escopo da POC.
Exemplos do nível de especificidade necessário no planejamento:

• (Objetivo) Precisamos saber se nosso requisito de ingestão de dados e processamento
de lotes de dados pode ser atendido de acordo com nosso SLA definido.
• (Resultado) Teremos os dados para determinar se a ingestão e o processamento de dados
em lote podem atender aos requisitos de processamento de dados e o SLA.
- (Teste) O processamento das consultas A, B e C é identificado como bom teste de
performance, pois é executado normalmente pela equipe de engenharia de dados
e representa as necessidades gerais de processamento de dados.
- (Test) O processamento de consultas X, Y e Z é identificado como bons testes de
performance, pois contêm requisitos de processamento de fluxo próximo do tempo real
e representam as necessidades gerais de processamento com base em eventos.
- (Test) Compare a performance dessas consultas em diferentes escalas do cluster do Spark
(número variável de nós de trabalho, tamanho dos nós de trabalho como pequeno,
médio e grande, número e tamanho dos executores) com o benchmark obtido do sistema
existente. Mantenha a "lei do rendimento decrescente" em mente: adicionar mais recursos
(pela expansão ou ampliação) pode ajudar a alcançar o paralelismo, no entanto, há um
certo limite, exclusivo para cada cenário, para alcançar o paralelismo. Descubra o ponto
ideal para cada caso de uso identificado em seus testes. Você pode considerar consultar
a seção Apêndice que fornece diretrizes para identificar esse ponto ideal.
• (Objetivo) Precisamos saber se nossos cientistas de dados existentes podem criar e treinar
modelos de machine learning nesta plataforma
• (Resultado) Testaremos alguns de nossos modelos de machine learning treinando em dados
no Spark ou no pool de SQL e aproveitando diferentes bibliotecas de machine learning.
Isso ajudará a determinar quais modelos de machine learning podem ser migrados para
o novo ambiente
- (Teste) Estes 2 a 3 modelos de machine learning (....) serão testados como parte da POC
- (Teste) Teste bibliotecas de machine learning base fornecidas com o Spark (Spark MLLib),
juntamente com a biblioteca adicional, que pode ser instalada no Spark (como o scikit)
para atender ao requisito.
• (Objetivo) Teremos testado a ingestão de dados e teremos os pontos de dados para
1) calcular o esforço para a nossa migração de dados históricos inicial para o data lake e/ou
pool dedicado e 2) planejar uma abordagem para migrar dados históricos.
• (Resultado) Testaremos e determinaremos a taxa de ingestão de dados alcançável em
nosso ambiente e poderemos determinar se nossa taxa de ingestão de dados é suficiente
para migrar dados históricos durante a janela de tempo disponível.
- (Testar) Teste diferentes abordagens de migração de dados históricos
Transferência de dados de e para o Azure
Casos de uso: Azure Data Box
- (Teste) Identifique a largura de banda alocada do ExpressRoute e se há alguma
configuração de limitação implementada pela equipe de infraestrutura
O que é o Azure ExpressRoute: opções de largura de banda
- (Teste) Teste a taxa de transferência de dados para migração de dados online e offline
Performance e escalabilidade de cópias que podem ser obtidas com o ADF
- (Teste) Teste a transferência de dados do data lake para o pool de SQL usando
ADF, Polybase ou o comando Copy
Estratégias de carregamento de dados para o pool de SQL do Synapse
Dados de carga em massa usando o extrato de COPY
• (Objetivo) Testaremos a taxa de ingestão de dados de carregamento de dados incremental
e teremos os pontos de dados para calcular a janela de tempo de ingestão e processamento
de dados para o data lake e/ou o pool de SQL.
• (Resultado) Teremos testado a taxa de ingestão de dados e poderemos determinar

se nossos requisitos de ingestão e processamento de dados podem ser atendidos com
a abordagem identificada
- (Teste) Teste a ingestão e o processamento de dados de atualização diária
- (Teste) Teste a carga de dados processados na tabela de pool de SQL do pool do Spark
Importe e exporte dados com o Apache Spark
- (Teste) Execute o processo de atualização de carga diária simultaneamente com
consultas de usuário final.
Refine seus testes adicionando vários cenários: a flexibilidade do Azure Synapse facilita o teste
em diferentes escalas (número variável de nós de trabalho, tamanho dos nós de trabalho,
como pequeno, médio e grande) para comparar a performance e o comportamento.
• (Teste do pool do Spark) Executaremos o processamento de dados em vários tipos

de nó (pequeno, médio, grande) e em um variado de nós de trabalho.
• (Teste do pool do Spark) Vamos carregar/recuperar dados processados do pool
do Spark para o pool de SQL dedicado com o conector rápido do pool de SQL.
• (Teste do pool do Spark) Vamos carregar/recuperar dados processados do pool
do Spark para o Cosmos DB com o Azure Synapse Link.
• (Teste do pool de SQL) Executaremos testes n, m e p usando escala de 500DWU,
1000DWU, 2000DWU.
• (Teste do pool de SQL) Teste cenários de carga A e B usando diferentes grupos
de recursos dinâmicos e estáticos.
Avalie o conjunto de dados da POC

No pipeline de ingestão e processamento de dados específico identificado, agora você
identificará o conjunto de dados necessário para oferecer suporte a esses testes. Agora
dedique um tempo para revisar esse conjunto de dados. Agora você precisa verificar se
o conjunto de dados representará adequadamente o processamento futuro no pool do Spark
em conteúdo, complexidade e escala. Não use um conjunto de dados muito pequeno (< 1TB),
pois não terá performance representativa. Não use um conjunto de dados muito grande, pois
durante a execução da POC não é o momento para concluir a migração completa de dados.
Peça para o cliente compartilhar benchmarks dos sistemas existentes, que você usará para
comparação de performance.
Verifique com os empresários se há bloqueadores para migrar esses dados para a nuvem.
Identifique todas as preocupações de segurança ou privacidade ou necessidades de
ofuscação de dados que precisam ser atendidas antes de migrar dados para a nuvem.
Crie uma arquitetura de alto nível para a sua POC

Com base na arquitetura de alto nível de sua arquitetura de estado futura, identifique
os componentes que farão parte da POC. Sua arquitetura de estado futuro de alto nível
provavelmente contém muitas fontes de dados, inúmeros consumidores de dados, componentes
de big data e, possivelmente, consumidores de machine learning e de dados de IA. Crie uma
arquitetura para a POC que identifique especificamente os componentes que farão parte dela
e identifique claramente quais componentes não farão parte dos testes da POC.
Se você já estiver usando o Azure, identifique todos os recursos já disponíveis no Azure

(AAD, ExpressRoute, etc.) que possam ser usados durante a POC. Também identifique as regiões
do Azure de preferência da sua organização. Agora é um ótimo momento para identificar
a taxa de transferência da sua conexão ExpressRoute, fazer uma verificação com outros usuários
de negócios e examinar se sua POC pode consumir parte dessa taxa de transferência sem
efeito adverso nas soluções de produção.
Saiba mais sobre arquiteturas de big data.

Identifique especificamente os recursos técnicos ou o SME e o compromisso relativo

ao tempo que serão necessários para apoiar a POC.
• Um representante de negócios para supervisionar os requisitos e os resultados
• Um especialista em dados de aplicações para fornecer os dados para a POC e fornecer
conhecimento do processo/lógica existente
• Um especialista em Apace Spark e pool do Spark
• Um consultor especializado para otimizar os testes da POC
• Os recursos necessários para componentes específicos do projeto de POC, mas não
necessariamente exigidos por toda a duração da POC. Esses recursos podem incluir
recursos de administração da rede, recursos de administração do Azure, administradores
do Active Directory, etc.
• Garanta que todos os recursos necessários dos serviços do Azure tenham sido provisionados
e que o nível de acesso necessário tenha sido fornecido a esses serviços, incluindo o acesso
a contas de armazenamento (Colaborador de Armazenamento e Colaborador de Dados
de Blob de Armazenamento).
• Garanta que você tenha uma conta que tenha a permissão de acesso a dados necessária
para extrair dados de todas as fontes de dados no escopo da POC.
especialista para ajudar na POC. A comunidade de parceiros da Microsoft tem disponibilidade
global de consultores especializados, prontos para demonstrar os recursos e a performance
do Azure Synapse. Você pode encontrar parceiros locais em Solution Providers Home.
Defina o cronograma da POC

Revise os detalhes do planejamento da POC e das necessidades de negócios para identificar
uma restrição de tempo para a POC. Faça estimativas realistas do tempo necessário para
concluir as tarefas no seu plano. O tempo para concluir a POC será influenciado pelo tamanho
do seu conjunto de dados da POC, o número de trabalhos de processamento de dados,
a complexidade e o número de interfaces que você está testando, etc. Se você achar que
a execução da sua POC levará mais de 4 semanas, considere a redução do escopo para manter
o foco nos objetivos de maior prioridade. Obtenha o apoio de todos os recursos de lead
e patrocinadores para o cronograma antes de continuar.
Você pode considerar verificar a seção "Escopo da POC do Spark" no Apêndice para obter
mais dicas e truques para melhorar o escopo, além de calcular e definir o cronograma da
POC do Spark.
Execute o projeto de POC

Execute o projeto de POC com a disciplina e o rigor de qualquer projeto de produção.
Execute-o de acordo com o plano e tenha um processo de solicitação de alteração em vigor
para evitar que a POC aumente e fique fora de controle.
Exemplo de tarefas de alto nível

• Provisione um espaço de trabalho Synapse, pools do Spark e de SQL, contas de
armazenamento e todos os recursos do Azure identificados no plano de POC.
• Carregue o conjunto de dados da POC.
- Disponibilize dados no Azure extraindo-os da fonte ou criando dados de exemplo
no Azure, conforme necessário.
Transferência de dados de e para o Azure
Casos de uso: Azure Data Box
Performance e escalabilidade de cópias que podem ser obtidas com o ADF
Estratégias de carregamento de dados para o pool de SQL do Synapse
Dados de carga em massa usando o extrato de COPY
- Teste o conector dedicado para o Spark e o pool de SQL dedicado.
• Migre o código existente para o Spark

- Se você estiver realizando a migração do Spark, provavelmente seu esforço será simples,
pois o pool do Spark utiliza a distribuição do Spark de código aberto. No entanto, se
você estiver usando recursos específicos do fornecedor com os recursos essenciais do
Spark, precisará mapear esses recursos corretamente com os recursos do pool do Spark.
- Se você estiver realizando a migração de um sistema que não seja o Spark, seu esforço
variará de acordo com a complexidade envolvida.
- Nos dois casos, você pode considerar verificar a seção "Execução de uma POC do Spark"
no Apêndice para obter mais práticas recomendadas, diretrizes, dicas e truques para
executar com êxito a POC do Spark.
• Execute testes
- Muitos testes podem ser executados paralelamente (ou seja, vários trabalhos de
processamento e ingestão de dados podem ser executados paralelamente em vários
clusters do pool do Spark)
- Registrar seus resultados em um formato consumível e prontamente compreensível
- Você pode considerar verificar as seções "Estratégia de teste" e "Análise e leitura dos
resultados" do Apêndice para obter mais detalhes
• Monitorar para solução de problemas e performance
- Monitorar: atividades do Apache Spark
- Monitorar: interface do usuário do Spark ou Spark History Server
- Monitoramento da utilização de recursos e atividade de consulta no
Azure Synapse Analytics
• Monitore a distorção de dados, a defasagem de tempo e a porcentagem de uso do executor

na guia Diagnóstico do Spark History Server:
Avaliar e apresentar os resultados

Quando todos os testes de POC forem concluídos, você poderá avaliar os resultados. Comece
avaliando se as metas de POC foram atendidas e os resultados desejados coletados. Observe
onde são necessários testes adicionais ou onde surgiram problemas adicionais.
Próximas etapas
Trabalhe com stakeholders técnicos e partes interessadas de negócios para planejar a próxima
fase do projeto, seja outra POC de acompanhamento ou a migração da produção.
Referências
• Escale automaticamente os pools do Azure Synapse Analytics Apache Spark
• Transferência de dados de e para o Azure
• Performance e escalabilidade de cópias que podem ser obtidas com o ADF
• Importe e exporte dados com o Apache Spark
• Monitorar: atividades do Apache Spark
• Monitorar: interface do usuário do Spark ou Spark History Server
• Monitoramento da utilização de recursos e atividade de consulta no Azure Synapse Analytics
• Gerencie bibliotecas para o Apache Spark no Azure Synapse Analytics
• Azure Cosmos DB Connector para Apache Spark
• Acelere a análise de Big data usando o conector do Apache Spark para Azure Cosmos DB
• O que é o Azure Synapse Link para o Azure Cosmos DB?
• Conector do Azure Synapse Apache Spark para Synapse SQL
• Escolha a abstração de dados
• Otimize junções e ordem aleatória

Conclusão
Os projetos de prova de conceito de dados eficazes começam com um plano bem projetado
e terminam com resultados de teste mensuráveis que podem ser usados para tomar decisões
de negócios com suporte de dados.
O Azure Synapse é um serviço de análise ilimitado baseado em nuvem com um tempo

incomparável de insight que acelera a entrega de BI, IA e aplicações inteligentes para empresas.
Você obterá muitos benefícios do Azure Synapse, incluindo performance, velocidade, maior
segurança e conformidade, elasticidade, infraestrutura gerenciada, escalabilidade e redução
de custos.
Este guia forneceu uma metodologia de alto nível para preparação e execução de uma prova
de conceito a fim de ajudar a usar o Azure Synapse como um data warehouse com pool de
SQL dedicado, um data lake com pool de SQL sem servidor e/ou para análise de big data com
o pool do Apache Spark.
Sucesso na jornada de prova de conceito!
Comece agora
Inscreva-se para ter uma conta gratuita do Azure
Veja mais informações em um

e-book técnico gratuito da Packt
Fale com um especialista em vendas para receber

ajuda em relação a preços, práticas recomendadas
e implementação de uma prova de conceito
Apêndice
Muitos clientes estão interessados em outras áreas do Azure Synapse. Segue uma tabela
dividida de acordo com tópicos de interesse, contendo informações adicionais e links
para a documentação aplicável.
Tópico de
Azure Synapse
interesse
Provisionamento • O Synapse está no seu locatário do Azure. Ele pode habilitar pontos
e disponibilidade de extremidade privados para que dados sejam sempre privados
regional e dentro de seu locatário.
Carregamento • O Azure Synapse tem dois utilitários de carregamento integrados

e transformação ao produto: PolyBase e COPY INTO. Os dois recursos dão suporte
de dados ao carregamento de arquivos CSV, ORC, PARQUET e JSON.
• As inserções, as atualizações e as exclusões no local têm suporte
em todas as tabelas do Azure Synapse.
• Os trabalhos de ETL podem ser orquestrados por meio de serviços
primários (Azure Data Factory) e de terceiros (Talend, informática
e coisas do gênero).
• O suporte a MERGE estará disponível em 2020.
• Os procedimentos armazenados em T-SQL garantem que toda
a lógica de negócios possa residir no banco de dados e seja
reutilizada pelos desenvolvedores.
Tópico de
Azure Synapse
interesse
Segurança O Azure Synapse é criado com a segurança como a maior prioridade:

Segurança e autenticação da rede:
• Links da rede privada
• Criptografia de dados transparente com módulos de segurança
de hardware (HSM)
• Azure Active Directory nativo
Segurança de dados:
• Segurança em nível de coluna
• Row-level security
• Máscara de dados dinâmicos
• Segurança em nível de objeto
Segurança avançada:
• Descoberta de dados
• Avaliação de vulnerabilidade
• Proteção avançada contra ameaças
• Auditoria de SQL
Conectividade • O Azure Synapse oferece suporte ao Power BI, ao Tableau

de BI e a muitas outras ferramentas de terceiros. Além disso, ele dá
suporte à conectividade JDBC e ODBC por meio de drivers do
SQL Server, ou seja, qualquer ferramenta com suporte do SQL
Server inerentemente tem conectividade do Azure Synapse.
Nossa abordagem oferece mais de 20 anos de ferramentas e valor
do ecossistema de parceiros para sua solução.
Tópico de
Azure Synapse
interesse
Preço/ • O benchmarking externo feito pela GigaOm mostra que o Azure

performance Synapse (SQL DW) tem o melhor preço/performance no TPC-H
de consulta 30 TB. Observação: o benchmark do snowflake no relatório da
GigaOm foi baseado no cluster padrão (USD 2 por crédito), não
no cluster crítico de negócios (USD 4 por crédito) exigido pelo
HCSC para recursos de segurança.
• Com 128 consultas simultâneas, os pools de SQL do Azure Synapse
oferecem a mais alta simultaneidade de banco de dados individual
de data warehouse na nuvem no mercado atual. Ao executar em
alta simultaneidade, você não precisa escalar para mais clusters,
o que geraria custos adicionais.
• Com o gerenciamento aprimorado do workload, você pode afinar
o data warehouse sem custo adicional. Essa capacidade aloca recursos
para as consultas certas com base no workload, garantindo que
todos os workloads tenham o necessário para execução. A alocação
de workload pode ser alterada em um cluster a qualquer momento,
com flexibilidade de escalar a performance do workload sem custos
adicionais para você.
Backup/ • O Azure Synapse obtém automaticamente pontos de restauração de

recuperação/ todos os data warehouses ativos ao longo do dia. Esses instantâneos
BCDR permitem ter um RPO de oito horas. Esses pontos de restauração são
retidos por 7 dias.
• Os pontos de restauração definidos pelo usuário podem ser obtidos
em qualquer ponto do tempo para fornecer tempos de restauração
mais granulares com base no workload. Há 42 pontos de restauração
disponíveis.
• Um banco de dados excluído pode ser recuperado por até sete dias
após a exclusão.
• Todas as instâncias do Azure Synapse implementam backups
geográficos. Um ponto de restauração é copiado automaticamente
para o datacenter emparelhado do seu datacenter para uso em
caso de falha do datacenter com um RPO de 24 horas.
Tópico de
Azure Synapse
interesse
Escala • Devido à arquitetura exclusiva do Azure Synapse que separa

a computação e o armazenamento, o Azure Synapse pode ser
escalado de 100 DWU a 30.000 DWU em minutos, seja qual
for o tamanho dos dados.
• O SQL DW fornece uma simultaneidade líder da indústria pronta
para uso de 128 consultas simultâneas em uma única instância,
reduzindo muito a necessidade de escalar o sistema além
de um tamanho de instância provisionado.
• Em um único cluster, o isolamento de workload permite criar regras
de alocação para workloads específicos. Essas regras podem ser
alteradas enquanto o banco de dados está online, possibilitando
a escala intracluster de workloads. Isso fornece uma metodologia
mais econômica para atribuir recursos com base em workloads
executados no data warehouse.
DevOps • O Azure Synapse dá suporte ao controle de origem nativo, interno,

e ao CICD com projetos de banco de dados. Isso permite que as
organizações simplifiquem o desenvolvimento e os testes de banco
de dados, reduzindo as chances de problemas não intencionais
resultantes de práticas de desenvolvimento ad hoc.
Gerenciamento • Como uma plataforma, o Azure tem recursos internos de

de custos gerenciamento de custos, inclusive para o Azure Synapse.
Essa experiência de monitoramento e gerenciamento fornece um
painel único de todos os componentes arquitetônicos e custos.
• Os alertas baseados em regras podem ser colocados em prática
para fornecer alertas se os gastos fugirem ao controle.

Guia Estratégico de Prova de Conceito Do Azure Synapse Analytics

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Guia Estratégico de Prova de Conceito Do Azure Synapse Analytics

Enviado por

Direitos autorais:

Formatos disponíveis

White paper

O guia estratégico fornecerá o seguinte:

Data Warehousing com pool

Identifique patrocinadores e potenciais blockers

Em nossa experiência, a prova de conceitos tem o melhor resultado quando é condensada

Ao respeitar esse cronograma, você pode seguir esta agenda aproximada:

Essa agenda serve mais como diretriz do que regra.

Veja algumas dicas:

Criação de uma arquitetura com escopo de prova de conceito de alto nível

Além disso, se você já estiver usando o Azure, precisará identificar o seguinte:

Em seguida, você precisa considerar os pontos problemáticos.

Identificação dos pontos problemáticos atuais

A próxima etapa é definir as metas.

Definição das metas

Aqui estão alguns exemplos de metas de prova de conceito:

A próxima etapa é planejar os testes.

Criação de um plano de teste

A maioria dos planos de teste giram em torno da performance e da experiência de usuário

Meta Teste Resultados esperados

• Precisamos saber • Teste sequencial de • As consultas A, B e C terminaram

Meta Teste Resultados esperados

• Precisamos saber • Execute um ou dois • O carregamento incremental

A próxima etapa é identificar seu conjunto de dados.

Identificar e validar o conjunto de dados de prova de conceito

Em seguida, você precisa montar uma equipe.

Montar sua equipe

Execute as seguintes etapas:

Sugerimos o desenvolvimento de testes de código e unidade em DW500c ou inferior

Este é um exemplo de COPY INTO:

Vamos falar sobre a consulta.

Teste de consulta sequencial

Teste de consulta simultâneo

Um resultado esperado deste teste é um tempo de execução mínimo, máximo e médio

Documente os resultados que mostrem claramente os resultados.

100 1.000 5.000 3 10 5

Teste de workload misto

Ajuste dos testes de consulta

Estes são os erros mais comuns observados durante a configuração:

Estas são alterações de ajuste comuns que podem ser aplicadas:

Vejamos testes de valor agregado.

Testes de valor agregado

Por fim, você precisa interpretar os resultados.

Interpretação dos resultados

No exemplo anterior, é possível perceber que a execução do Teste 1 em DWU1000 é mais

Exploração de data lake com pool de

Diferentes funções profissionais podem se beneficiar do pool de SQL sem servidor:

Uma prova de conceito é um projeto rapidamente executado que se concentra em questões-

Definir as metas para a POC

• Quais SLAs você precisa cumprir?

Alguns EXEMPLOS da configuração de metas da POC

Nossa POC será bem-sucedida se tivermos os dados necessários e concluirmos os testes

Planeje o projeto de POC

Exemplo do nível de especificidade necessário no planejamento:

Avalie o conjunto de dados da POC

Crie uma arquitetura de alto nível para a sua POC

Identifique os recursos da POC

Identifique especificamente os recursos técnicos e os compromissos relativos ao tempo que

• Um representante de negócios para supervisionar os requisitos e os resultados

Defina um cronograma para a POC

Execute o projeto de POC

Exemplo de tarefas de alto nível

Avaliar e apresentar os resultados

• Solution Providers Home