Metodologia de sucesso de implementação do Azure Synapse: avaliar o ambiente

Observação

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

A primeira etapa ao implementar o Azure Synapse Analytics é conduzir uma avaliação de seu ambiente. Uma avaliação oferece a oportunidade de coletar todas as informações disponíveis sobre o ambiente existente, os requisitos ambientais, os requisitos de projeto, as restrições, as linhas do tempo e as dificuldades. Essas informações formarão a base das atividades posteriores de avaliação e ponto de verificação. Elas serão fundamentais quando chegar a hora de fazer a validação e a comparação com a solução de projeto em relação ao planejamento, o design e o desenvolvimento. Recomendamos que você dedique um bom tempo para coletar todas as informações e realizar todas as discussões necessárias com os grupos relevantes. Os grupos relevantes podem incluir partes interessadas do projeto, usuários empresariais, designers de soluções e SMEs (especialistas no assunto) da solução e do ambiente existentes.

A avaliação será um guia para ajudar você a avaliar o design da solução e fazer recomendações de tecnologia informadas para implementar o Azure Synapse.

Avaliação da carga de trabalho

A avaliação da carga de trabalho está relacionada a: ambiente, funções da carga de trabalho analítica, ETL/ELT, rede e segurança, ambiente do Azure e consumo de dados.

Ambiente

Quanto ao ambiente, avalie os pontos a seguir.

• Descreva a carga de trabalho analítica existente:
  • Quais são as cargas de trabalho (como data warehouse ou Big Data)?
  • Como essa carga de trabalho está ajudando os negócios? Quais são os cenários de caso de uso?
  • Qual é o incentivo comercial para essa plataforma analítica e uma possível migração?
  • Colete detalhes sobre as opções de arquitetura, design e implementação existentes.
  • Colete detalhes sobre todos os componentes e consumidores dependentes upstream e downstream existentes.
• Você está migrando um data warehouse existente (como Microsoft SQL Server, APS (Microsoft Analytics Platform System), Netezza, Snowflake ou Teradata)?
• Você está migrando uma plataforma de Big Data (como Cloudera ou Hortonworks)?
• Colete os diagramas de arquitetura e fluxo de dados do ambiente analítico atual.
• Onde estão localizadas as fontes de dados das cargas de trabalho analíticas planejadas (Azure, outros provedores de nuvem ou ambiente local)?
• Qual é o tamanho total dos conjuntos de dados existentes (históricos e incrementais)? Qual é a taxa atual de crescimento dos conjuntos de dados? Qual é a taxa projetada de crescimento dos conjuntos de dados para os próximos dois a cinco anos?
• Você já tem um data lake? Colete o máximo de detalhes possível sobre tipos de arquivo (como Parquet ou CSV), tamanhos de arquivo e configuração de segurança.
• Você tem dados semiestruturados ou não estruturados para processar e analisar?
• Descreva a natureza do processamento de dados (processamento em lote ou em tempo real).
• Você precisa de exploração interativa de dados relacionais, data lake ou outras fontes?
• Você precisa de análise e exploração de dados em tempo real de fontes de dados operacionais?
• Quais são as dificuldades e as limitações no ambiente atual?
• Quais ferramentas de controle do código-fonte e de DevOps você está usando hoje?
• Você tem um caso de uso para criar uma solução analítica híbrida (nuvem e local), somente na nuvem ou em várias nuvens?
• Colete informações sobre o ambiente de nuvem existente. Você usa um provedor de nuvem única ou um provedor de várias nuvens?
• Reúna planos sobre o futuro ambiente de nuvem. Você usará um provedor de nuvem única ou um provedor de várias nuvens?
• Quais são os requisitos de RPO/RTO/HA/SLA no ambiente existente?
• Quais são os requisitos de RPO/RTO/HA/SLA no ambiente planejado?

Funções da carga de trabalho analítica

Quanto às funções da carga de trabalho analíticas, avalie os pontos a seguir.

• Descreva as diferentes funções (cientista de dados, engenheiro de dados, analista de dados e outros).
• Descreva o requisito de controle de acesso da plataforma analítica para essas funções.
• Identifique o proprietário da plataforma responsável por provisionar recursos de computação e permitir acesso.
• Descreva como as diferentes funções de dados colaboram no momento.
• Há várias equipes colaborando na mesma plataforma analítica? Se sim, quais são os requisitos de controle de acesso e de isolamento para cada uma dessas equipes?
• Quais são as ferramentas cliente que os usuários finais usam para interagir com a plataforma analítica?

ETL/ELT, transformação e orquestração

Quanto a ETL/ELT, transformação e orquestração, avalie os pontos a seguir.

• Quais ferramentas você está usando hoje para ingestão de dados (ETL ou ELT)?
• Onde essas ferramentas existem no ambiente atual (localmente ou na nuvem)?
• Quais são os requisitos atuais de carregamento e atualização de dados (em tempo real, microlote, por hora, diário, semanal ou mensal)?
• Descreva os requisitos de transformação de cada camada (Big Data, data lake, data warehouse).
• Qual é a abordagem de programação atual para transformar os dados (sem código, pouco código, programação como SQL, Python, Scala, C# ou outros)?
• Qual é a abordagem de programação planejada preferencial para transformar os dados (sem código, pouco código, programação como SQL, Python, Scala, C# ou outros)?
• Quais ferramentas de orquestração de dados estão sendo usadas no momento para automatizar o processo controlado por dados?
• Onde estão localizadas as fontes de dados do ETL existente (Azure, outro provedor de nuvem ou ambiente local)?
• Quais são as ferramentas de consumo de dados existentes (relatórios, ferramentas de BI, ferramentas de software livre) que exigem integração com a plataforma analítica?
• Quais são as ferramentas de consumo de dados planejadas (relatórios, ferramentas de BI, ferramentas de software livre) que exigirão integração com a plataforma analítica?

Rede e segurança

Quando à rede e segurança, avalie os pontos a seguir.

• Quais são os requisitos regulatórios em relação aos dados?
• Se os dados contêm conteúdo do cliente, dados do PCI (setor de cartões de pagamento) ou da lei americana HIPAA (Health Insurance Portability Accountability Act) de 1996, seu grupo de segurança certificou o Azure para esses dados? Nesse caso, para quais serviços do Azure?
• Descreva os requisitos de autorização e autenticação de usuário.
• Há problemas de segurança que podem limitar o acesso aos dados durante a implementação?
• Há dados de teste disponíveis para uso durante o desenvolvimento e o teste?
• Descreva os requisitos organizacionais de segurança de rede na computação analítica e no armazenamento (rede privada, rede pública ou restrições de firewall).
• Descreva os requisitos de segurança de rede para que as ferramentas cliente acessem a computação analítica e o armazenamento (rede emparelhada, ponto de extremidade privado ou outros).
• Descreva a configuração de rede atual entre o ambiente local e o Azure (Azure ExpressRoute, site a site ou outros).

Use as listas de verificação de possíveis requisitos a seguir para orientar a avaliação.

• Proteção de dados:
  • Criptografia de dados em trânsito
  • Criptografia de dados inativos (chaves padrão ou chaves gerenciadas pelo cliente)
  • Descoberta e classificação de dados
• Controle de acesso:
  • Segurança em nível de objeto
  • Segurança em nível de linha
  • Segurança ao nível da coluna
  • Mascaramento de dados dinâmicos
• Autenticação:
  • Logon do SQL
  • ID do Microsoft Entra
  • MFA (autenticação multifator)
• Segurança de rede:
  • Redes virtuais
  • Firewall
  • Azure ExpressRoute
• Proteção contra ameaças:
  • Detecção de ameaças
  • Auditoria
  • Avaliação de vulnerabilidade

Para obter mais informações, confira o White paper sobre a segurança do Azure Synapse Analytics.

Ambiente do Azure

Quanto ao ambiente do Azure, avalie os pontos a seguir.

• Você está usando o Azure no momento? Ele é usado para cargas de trabalho de produção?
• Se você está usando o Azure, quais serviços está usando? Quais regiões você está usando?
• Você usa o Azure ExpressRoute? Qual é a largura de banda?
• Você tem aprovação de orçamento para provisionar os serviços do Azure necessários?
• Como você provisiona e gerencia recursos no momento [ARM (Azure Resource Manager) ou Terraform]?
• Sua equipe principal está familiarizada com o Synapse Analytics? É necessário fazer algum treinamento?

Consumo de dados

Quanto ao consumo de dados, avalie os pontos a seguir.

• Descreva quais ferramentas você usa no momento para executar atividades como ingestão, exploração, preparação e visualização de dados e como esses processos são realizados.
• Identifique quais ferramentas você planeja usar para executar atividades como ingestão, exploração, preparação e visualização de dados.
• Quais aplicativos estão planejados para interagir com a plataforma analítica (Microsoft Power BI, Microsoft Excel, Microsoft SQL Server Reporting Services, Tableau ou outros)?
• Identifique todos os consumidores de dados.
• Identifique os requisitos de exportação de dados e compartilhamento de dados.

Avaliação de serviços do Azure Synapse

A avaliação de serviços do Azure Synapse está relacionada aos serviços no Azure Synapse. O Azure Synapse tem os seguintes componentes para computação e movimentação de dados:

• SQL do Synapse: um sistema de consulta distribuído para T-SQL (Transact-SQL) que permite cenários de armazenamento de dados e virtualização de dados. Ele também estende o T-SQL para abordar cenários de streaming e ML (machine learning). O SQL do Synapse fornece modelos de recursos sem servidor e dedicados.
• Pool de SQL sem servidor: é um sistema de processamento de dados distribuído, criado para funções computacionais e de dados em grande escala. Não há uma infraestrutura a ser configurada nem clusters a serem mantidos. Esse serviço é adequado para cargas de trabalho não planejadas ou com intermitência. Os cenários recomendados incluem a exploração rápida de dados em arquivos diretamente no data lake, data warehouse lógico e transformação de dados brutos.
• Pool de SQL dedicado: representa uma coleção de recursos de análise que são provisionados quando o SQL do Synapse é usado. O tamanho do pool de SQL dedicado (antigo SQL DW) é determinado pelas DWU (unidades de data warehouse). Esse serviço é adequado para um data warehouse com cargas de trabalho contínuas, previsíveis e de alto desempenho em dados armazenados em tabelas SQL. 
• Pool do Apache Spark: integra-se total e perfeitamente ao Apache Spark, que é o mecanismo de Big Data de software livre mais popular usado para preparação de dados, engenharia de dados, ETL e ML.
• Pipelines de integração de dados: o Azure Synapse contém o mesmo mecanismo e as mesmas experiências de integração de dados que o ADF (Azure Data Factory). Eles permitem que você crie pipelines ETL avançados em escala sem sair do Azure Synapse.

Como ajuda para determinar o tipo de pool de SQL (dedicado ou sem servidor) mais adequado, avalie os pontos a seguir.

• Deseja criar um data warehouse relacional tradicional reservando energia de processamento para dados armazenados em tabelas SQL?
• Seus casos de uso exigem desempenho previsível?
• Deseja criar um data warehouse lógico com base em um data lake?
• Deseja consultar dados diretamente de um data lake?
• Deseja explorar dados de um data lake?

A tabela a seguir compara os dois tipos de pool de SQL do Synapse.

Comparação	Pool de SQL dedicado	Pool de SQL sem servidor
Propostas de valor	Funcionalidades totalmente gerenciados de um data warehouse. Desempenho previsível e alto para cargas de trabalho contínuas. Otimizado para dados gerenciados (carregados).	Fácil de começar a explorar dados do data lake. Melhor TCO (custo total de propriedade) para cargas de trabalho ad hoc e intermitentes. Otimizado para consultar dados em um data lake.
Cargas de trabalho	Ideal para cargas de trabalho contínuas. O carregamento aumenta o desempenho, com mais complexidade. A cobrança por DWU (quando bem dimensionada) beneficiará os custos.	Ideal para cargas de trabalho ad hoc ou intermitentes. Não é necessário carregar dados, portanto, é mais fácil de ser iniciado e executado. A cobrança por uso beneficiará os custos.
Desempenho de consulta	Fornece alta simultaneidade e baixa latência. Dá suporte a opções avançadas de cache, incluindo exibições materializadas. Existe a capacidade de compará-lo com o WLM (gerenciamento de carga de trabalho) e escolher a melhor opção.	Não é adequado para consultas de dashboard. Tempos de resposta de milissegundos não são esperados. Funciona somente em dados externos.

Avaliação do pool de SQL dedicado

Em relação à avaliação do pool de SQL dedicado, avalie os pontos de plataforma a seguir.

• Qual é a plataforma de data warehouse atual (Microsoft SQL Server, Netezza, Teradata, Greenplum ou outra)?
• Para uma carga de trabalho de migração, determine o tipo e o modelo do dispositivo de cada ambiente. Inclua detalhes de CPUs, GPUs e memória.
• Para uma migração de dispositivo, quando o hardware foi comprado? O dispositivo já foi totalmente depreciado? Caso contrário, quando a depreciação terminará? E quanto de despesas de capital sobrará?
• Há diagramas de arquitetura de hardware e rede?
• Onde estão localizadas as fontes de dados do data warehouse planejado (Azure, outro provedor de nuvem ou ambiente local)?
• Quais são as plataformas de hospedagem de dados das fontes de dados do data warehouse (Microsoft SQL Server, Banco de Dados SQL do Azure, DB2, Oracle, Armazenamento de Blobs do Azure, AWS, Hadoop ou outros)?
• Alguma das fontes de dados é um data warehouse? Se sim, quais?
• Identifique todos os cenários de ETL, ELT e carregamento de dados (janelas em lote, streaming, quase em tempo real). Identifique os SLAs (Contratos de Nível de Serviço) existentes para cada cenário e documente os SLAs esperados no novo ambiente.
• Qual é o tamanho atual do data warehouse?
• Qual taxa de crescimento do conjunto de dados está sendo direcionada ao pool de SQL dedicado?
• Descreva os ambientes que você está usando hoje (desenvolvimento, teste ou produção).
• No momento, quais ferramentas estão em vigor para movimentação de dados (ADF, SSIS (Microsoft SQL Server Integration Services), Robocopy, Informatica, SFTP ou outros)?
• Você planeja carregar dados em tempo real ou quase em tempo real?

Avalie os pontos sobre banco de dados a seguir.

• Qual é o número de objetos em cada data warehouse (esquemas, tabelas, exibições, procedimentos armazenados e funções)?
• O design é um esquema em estrela, um esquema floco de neve ou outros?
• Quais são as maiores tabelas em termos de tamanho e número de registros?
• Quais são as tabelas mais largas em termos de número de colunas?
• Já existe um modelo de dados projetado para o data warehouse? É um design de esquema kimball, inmon ou em estrela?
• Há SCDs (Dimensões de Alteração Lenta) em uso? Se sim, quais tipos?
• Uma camada semântica será implementada usando data marts relacionais, o Analysis Services (tabular ou multidimensional) ou outro produto?
• Quais são os requisitos de HA, RPO, RTO e arquivamento de dados?
• Quais são os requisitos de replicação de região?

Avalie as seguintes características da carga de trabalho.

• Qual é o número estimado de usuários ou trabalhos simultâneos que acessam o data warehouse durante o horário de pico?
• Qual é o número estimado de usuários ou trabalhos simultâneos que acessam o data warehouse fora do horário de pico?
• Em algum período de tempo não haverá usuários nem trabalhos?
• Quais são as expectativas de desempenho de execução de consulta para consultas interativas?
• Quais são as expectativas de desempenho de carregamento de dados para atualizações ou carregamentos de dados diários, semanais e mensais?
• Quais são as expectativas de execução de consulta para relatórios e consultas analíticas?
• Qual o grau de complexidade das consultas que serão mais executadas?
• Qual é o percentual do tamanho total do conjunto de dados é o conjunto de dados ativo?
• Aproximadamente qual percentual da carga de trabalho está previsto para carregamento ou atualização, processamento ou relatório em lote, consulta interativa e processamento analítico?
• Identifique os padrões e as plataformas de consumo de dados:
  • Método e ferramentas de relatório atuais e planejados.
  • Quais aplicativos ou ferramentas analíticas acessarão o data warehouse?
  • Número de consultas simultâneas?
  • Número médio de consultas ativas o tempo todo?
  • Qual é a natureza do acesso a dados (interativo, ad hoc, exportação ou outros)?
  • Funções de dados e descrição completa dos respectivos requisitos de dados.
  • Número máximo de conexões simultâneas.
• Padrão de SLA de desempenho de consulta por:
  • Usuários de dashboard.
  • Relatório em lote.
  • Usuários de ML.
  • Processo de ETL.
• Quais são os requisitos de segurança do ambiente existente e do novo ambiente (segurança em nível de linha, segurança em nível de coluna, controle de acesso, criptografia e outros)?
• Existe o requisito de integrar a pontuação de modelo de ML ao T-SQL?

Avaliação do pool de SQL sem servidor

O pool de SQL sem servidor do Azure Synapse dá suporte a três casos de uso principais.

• Descoberta e exploração básicas: tire conclusões rapidamente sobre os dados em vários formatos (Parquet, CSV, JSON) no data lake, para poder planejar a maneira de extrair insights.
• Data warehouse lógico: forneça uma abstração relacional com base em dados brutos ou díspares sem realocá-los nem transformá-los, permitindo uma exibição sempre atualizada dos dados.
• Transformação de dados: maneira simples, escalonável e de alto desempenho para transformar dados no lake usando T-SQL, para que eles alimentem as ferramentas de BI e de outros processos ou sejam carregados em um armazenamento de dados relacional (bancos de dados SQL do Synapse, Banco de Dados SQL do Azure ou outros).

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

• Os engenheiros de dados podem explorar o data lake, transformar e preparar dados usando esse serviço e simplificar os respectivos pipelines de transformação de dados.
• Os cientistas de dados podem tirar conclusões rapidamente sobre o conteúdo e a estrutura dos dados no data lake, graças a recursos como o OPENROWSET e a inferência automática de esquemas.
• Os analistas de dados podem explorar dados e tabelas externas do Spark criadas por cientistas de dados ou engenheiros de dados usando uma linguagem T-SQL familiar ou as ferramentas que preferirem.
• Os profissionais de BI podem criar relatórios do Power BI rapidamente com base em dados do data lake e em tabelas do Spark.

Observação

A linguagem T-SQL é usada no pool de SQL dedicado e no pool de SQL sem servidor, no entanto, há algumas diferenças no conjunto de recursos com suporte. Para obter mais informações sobre os recursos T-SQL com suporte no SQL do Synapse (dedicado e sem servidor), confira os recursos do Transact-SQL com suporte no SQL do Azure Synapse.

Quanto à avaliação do pool de SQL sem servidor, avalie os pontos a seguir.

• Você tem casos de uso em que precisa descobrir e explorar dados de um data lake usando consultas relacionais (T-SQL)?
• Você tem casos de uso em que precisa criar um data warehouse lógico com base em um data lake?
• Identifique se há casos de uso que precisam transformar dados no data lake sem primeiro transferir os dados do data lake.
• Os dados já estão no ADLS (Azure Data Lake Storage) ou no Armazenamento de Blobs do Azure?
• Se os dados já estão no ADLS, você tem uma boa estratégia de partição no data lake?
• Você tem dados operacionais no Azure Cosmos DB? Você tem casos de uso de análise em tempo real no Azure Cosmos DB sem afetar as transações?
• Identifique os tipos de arquivo no data lake.
• Identifique o SLA de desempenho da consulta. Seu caso de uso exige desempenho e custo previsíveis?
• Você tem cargas de trabalho SQL analíticas não planejadas ou intermitentes?
• Identifique os padrões e as plataformas de consumo de dados:
  • Método e ferramentas de relatório atuais e planejados.
  • Quais aplicativos ou ferramentas analíticas acessarão o pool de SQL sem servidor?
  • Número médio de consultas ativas o tempo todo.
  • Qual é a natureza do acesso a dados (interativo, ad hoc, exportação ou outros)?
  • Funções de dados e descrição completa dos respectivos requisitos de dados.
  • Número máximo de conexões simultâneas.
  • Complexidade da consulta?
• Quais são os requisitos de segurança (controle de acesso, criptografia e outros)?
• Qual é a funcionalidade T-SQL necessária (procedimentos armazenados ou funções)?
• Identifique o número de consultas que serão enviadas ao pool de SQL sem servidor e o tamanho do conjunto de resultados de cada consulta.

Dica

Se você não estiver familiarizado com pools de SQL sem servidor, recomendamos que percorra o roteiro de aprendizagem Criar soluções de análise de dados usando pools de SQL sem servidor do Azure Synapse.

Avaliação do Pool do Spark

Os pools do Spark no Azure Synapse permitem os cenários principais a seguir.

• Engenharia de dados/preparação de dados: o Apache Spark inclui vários recursos de linguagem para dar suporte à preparação e ao processamento de grandes volumes de dados. A preparação e o processamento podem aumentar o valor dos dados e permitir que eles sejam consumidos por outros serviços do Azure Synapse. Isso é possibilitado por meio das várias linguagens (C#, Scala, PySpark, Spark SQL) e bibliotecas fornecidas para processamento e conectividade.
• Machine learning: o Apache Spark vem com a MLlib, uma biblioteca de ML criada com base no Spark que pode ser usada por meio de um Pool do Spark. Os Pools do Spark também incluem o Anaconda, que é uma distribuição Python que compreende vários pacotes de ciência de dados, incluindo ML. Além disso, o Apache Spark no Azure Synapse fornece bibliotecas pré-instaladas para o Microsoft Machine Learning, que é uma estrutura de ML tolerante a falhas, elástica e RESTful. Quando combinado com o suporte interno para notebooks, oferece um ambiente avançado para criação de aplicativos de ML.

Observação

Para obter mais informações, confira Apache Spark no Azure Synapse Analytics.

Além disso, o Azure Synapse é compatível com o Linux Foundation Delta Lake. O Delta Lake é uma camada de armazenamento open-source que traz transações ACID (atomicidade, consistência, isolamento e durabilidade) para o Apache Spark e cargas de trabalho de Big Data. Para obter mais informações, confira O que é o Delta Lake?.

Quanto à avaliação do Pool do Spark, avalie os pontos a seguir.

• Identifique as cargas de trabalho que exigem engenharia de dados ou preparação de dados.
• Defina claramente os tipos de transformações.
• Identifique se há dados não estruturados a serem processados.
• Quando você está migrando de uma carga de trabalho existente do Spark/Hadoop:
  • Qual é a plataforma de Big Data existente (Cloudera, Hortonworks, serviços de nuvem ou outras)?
  • Se for uma migração do ambiente local, o hardware foi depreciado ou as licenças expiraram? Em caso negativo, quando a depreciação ou a expiração ocorrerá?
  • Qual é o tipo de cluster existente?
  • Quais são as bibliotecas e as versões do Spark necessárias?
  • É uma migração do Hadoop para o Spark?
  • Quais são as linguagens de programação atuais ou preferenciais?
  • Qual é o tipo de carga de trabalho (Big Data, ML ou outros)?
  • Quais são as ferramentas cliente e as plataformas de relatório existentes e planejadas?
  • Quais são os requisitos de segurança?
  • Há dificuldades ou limitações atuais?
• Você planeja usar ou está usando o Delta Lake no momento?
• Como você gerencia pacotes hoje?
• Identifique os tipos de cluster de computação necessários.
• Identifique se a personalização do cluster é necessária.

Dica

Se você não estiver familiarizado com pools do Spark, recomendamos que percorra o roteiro de aprendizagem Executar engenharia de dados com os Pools do Apache Spark do Azure Synapse.

Próximas etapas

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