Editar

Consultar um data lake ou lakehouse usando o Azure Synapse serverless

Azure Data Lake
Azure Data Lake Storage
Azure Synapse Analytics
Azure Blob Storage

Este artigo descreve uma abordagem alternativa para projetos de data warehouse chamada análise exploratória de dados (EDA). Essa abordagem pode reduzir os desafios das operações de extração, transformação e carga (ETL). Ele se concentra primeiro na geração de insights de negócios e, em seguida, se volta para resolver as tarefas de modelagem e ETL.

Arquitetura

Diagram that shows a sample EDA architecture.

Transfira um ficheiro do Visio desta arquitetura.

Para EDA, você está preocupado apenas com o lado direito do diagrama. O Azure Synapse SQL serverless é usado como o mecanismo de computação sobre os arquivos do data lake.

Para realizar a AED:

  • As consultas T-SQL são executadas diretamente no Azure Synapse, SQL serverless ou Azure Synapse Spark.
  • As consultas são executadas a partir de uma ferramenta de consulta gráfica como o Power BI ou o Azure Data Studio.

Recomendamos que você persista todos os dados da lakehouse usando o Parquet ou o Delta.

Você pode implementar o lado esquerdo do diagrama (ingestão de dados) usando qualquer ferramenta de extração, carga, transformação (ELT). Não tem qualquer efeito sobre a AED.

Componentes

Alternativas

  • Você pode substituir ou complementar pools sem servidor Synapse SQL com o Azure Databricks.

  • Em vez de usar um modelo lakehouse com pools sem servidor Synapse SQL, você pode usar pools SQL dedicados do Azure Synapse para armazenar dados corporativos. Analise os casos de uso e as considerações neste artigo e os recursos relacionados para decidir qual tecnologia usar.

Detalhes do cenário

Esta solução mostra uma implementação da abordagem EDA para projetos de armazém de dados. Essa abordagem pode reduzir os desafios das operações de ETL. Ele se concentra primeiro na geração de insights de negócios e, em seguida, se volta para a resolução de tarefas de modelagem e ETL.

Potenciais casos de utilização

Outros cenários que podem se beneficiar desse padrão de análise:

  • Análise prescritiva. Faça perguntas sobre os seus dados, como a Next Best Action, ou o que fazemos a seguir? Use os dados para ser mais orientado por dados e menos orientado para o instinto. Os dados podem ser não estruturados e provenientes de muitas fontes externas de qualidade variável. Você pode querer usar os dados o mais rápido possível para avaliar sua estratégia de negócios sem realmente carregar os dados em um data warehouse. Pode eliminar os dados depois de responder às suas perguntas.

  • ETL de autoatendimento. Faça ETL/ELT quando fizer suas atividades de sandbox de dados (EDA). Transforme dados e torne-os valiosos. Isso pode melhorar a escala de seus desenvolvedores de ETL.

Sobre a análise exploratória de dados

Antes de analisarmos mais de perto como o EDA funciona, vale a pena resumir a abordagem tradicional para projetos de data warehouse. A abordagem tradicional tem a seguinte aparência:

  • Levantamento de requisitos. Documente o que fazer com os dados.

  • Modelagem de dados. Determine como modelar os dados numéricos e de atributos em tabelas de fatos e dimensões. Tradicionalmente, você faz essa etapa antes de adquirir os novos dados.

  • ETL. Adquira os dados e massageie-os no modelo de dados do data warehouse.

Essas etapas podem levar semanas ou até meses. Só então você pode começar a consultar os dados e resolver o problema do negócio. O usuário vê o valor somente depois que os relatórios são criados. A arquitetura da solução geralmente se parece com esta:

Diagram that shows the traditional data warehouse architecture.

Você pode fazer isso de outra maneira que se concentra primeiro na geração de insights de negócios e, em seguida, se volta para resolver as tarefas de modelagem e ETL. O processo é semelhante aos processos de ciência de dados. Tem a seguinte aparência:

Diagram that describes data sandboxing.

Na indústria, esse processo é chamado de EDA, ou análise exploratória de dados.

Eis os passos:

  • Aquisição de dados. Primeiro, você precisa determinar quais fontes de dados você precisa ingerir em seu data lake / sandbox. Em seguida, você precisa trazer esses dados para a área de pouso do seu lago. O Azure fornece ferramentas como o Azure Data Factory e os Aplicativos Lógicos do Azure que podem ingerir dados rapidamente.

  • Área restrita de dados. Inicialmente, um analista de negócios e um engenheiro especializado em análise exploratória de dados por meio do Azure Synapse Analytics sem servidor ou SQL básico trabalham juntos. Durante essa fase, eles estão tentando descobrir a visão do negócio usando os novos dados. A AED é um processo iterativo. Pode ser necessário ingerir mais dados, conversar com PMEs, fazer mais perguntas ou gerar visualizações.

  • Avaliação. Depois de encontrar a visão de negócios, você precisa avaliar o que fazer com os dados. Talvez você queira manter os dados no data warehouse (para passar para a fase de modelagem). Em outros casos, você pode decidir manter os dados no data lake / lakehouse e usá-los para análise preditiva (algoritmos de aprendizado de máquina). Ainda em outros casos, você pode decidir preencher seus sistemas de registro com os novos insights. Com base nessas decisões, você pode obter uma melhor compreensão do que precisa fazer a seguir. Talvez não seja necessário fazer ETL.

Esses métodos são o núcleo da verdadeira análise de autoatendimento. Usando o data lake e uma ferramenta de consulta como o Azure Synapse serverless que entende os padrões de consulta do data lake, você pode colocar seus ativos de dados nas mãos de pessoas de negócios que entendem um mínimo de SQL. Você pode reduzir radicalmente o tempo de implantação usando esse método e remover parte do risco associado às iniciativas de dados corporativos.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Disponibilidade

Os pools sem servidor SQL do Azure Synapse são um recurso de plataforma como serviço (PaaS) que pode atender aos seus requisitos de alta disponibilidade (HA) e recuperação de desastres (DR).

Pools sem servidor estão disponíveis sob demanda. Eles não exigem escala, para baixo, para dentro ou para fora ou administração de qualquer tipo. Eles usam um modelo de pagamento por consulta, portanto, não há capacidade não utilizada em nenhum momento. Os pools sem servidor são ideais para:

  • Explorações ad-hoc de ciência de dados em T-SQL.
  • Prototipagem antecipada para entidades de armazém de dados.
  • Definir modos de exibição que os consumidores podem usar, por exemplo, no Power BI, para cenários que podem tolerar atraso de desempenho.
  • Análise exploratória de dados.

Operations

Synapse SQL serverless usa T-SQL padrão para consultas e operações. Você pode usar a interface do usuário do espaço de trabalho Synapse, o Azure Data Studio ou o SQL Server Management Studio como a ferramenta T-SQL.

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

  • O preço do Armazenamento Data Lake depende da quantidade de dados armazenados e da frequência com que os utiliza. O preço de amostra inclui um TB de dados armazenados, com outras suposições transacionais. Um TB refere-se ao tamanho do data lake, não ao tamanho do banco de dados herdado original.

  • O pool do Azure Synapse Spark baseia os preços no tamanho do nó, no número de instâncias e no tempo de atividade. O exemplo pressupõe um pequeno nó de computação com utilização entre cinco horas por semana e 40 horas por mês.

  • O pool SQL sem servidor do Azure Synapse baseia os preços em TBs de dados processados. A amostra pressupõe 50 TBs processados por mês. Esta figura refere-se ao tamanho do data lake, não ao tamanho do banco de dados herdado original.

Contribuidores

Este artigo está sendo atualizado e mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

Próximos passos