Dimensionar análises em escala de nuvem no Azure
Uma plataforma de dados escalável é fundamental para acomodar o rápido crescimento dos dados. Grandes quantidades de dados são geradas a cada segundo em todo o mundo. Prevê-se que a quantidade de dados disponíveis continue a crescer exponencialmente nos próximos anos. À medida que a taxa de geração de dados aumenta, a velocidade de movimentação de dados também aumenta.
Não importa a quantidade de dados que você tenha, seus usuários exigem respostas rápidas de consulta. Esperam esperar minutos, não horas, pelos resultados. Este artigo explica como você pode dimensionar sua solução de análise em escala de nuvem do Azure e continuar a atender às demandas de velocidade dos usuários.
Introdução
Muitas empresas têm grandes monólitos de plataforma de dados. Esses monólitos são criados em torno de uma única conta do Azure Data Lake Gen2 e, às vezes, de um único contêiner de armazenamento. Uma única assinatura do Azure geralmente é usada para todas as tarefas relacionadas à plataforma de dados. O dimensionamento do nível de assinatura está ausente na maioria das plataformas de arquitetura, o que pode impedir a adoção contínua do Azure se os usuários se depararem com qualquer uma das limitações de nível de serviço ou assinatura do Azure. Mesmo que algumas das restrições sejam limites suaves, atingi-las ainda pode ter um efeito negativo significativo na sua plataforma de dados.
Ao estruturar sua plataforma de dados, considere a estrutura da sua organização. Observe a propriedade dos dados e as responsabilidades funcionais de suas equipes. Se sua organização oferece às equipes grandes graus de autonomia e propriedade distribuída, uma arquitetura de malha de dados é sua melhor opção.
Evite situações que tenham equipes diferentes responsáveis pelas várias tarefas de uma solução — tarefas como ingestão, limpeza, agregação e serviço. Dependendo de várias equipes pode causar uma perda dramática de velocidade. Por exemplo, se os consumidores de dados na camada de serviço precisarem integrar novos ativos de dados ou implementar alterações funcionais para um determinado ativo de dados, eles deverão passar por um processo de várias etapas. Para este exemplo, as etapas são:
- O consumidor de dados envia um tíquete para cada equipe responsável por um estágio de pipeline de dados.
- As equipes devem trabalhar juntas em sincronia porque as camadas estão interconectadas. Os novos serviços exigem alterações na camada de limpeza de dados, o que leva a alterações na camada de agregação de dados, o que leva a alterações na camada de serviço. As alterações podem afetar todos os estágios do pipeline.
- É difícil para as equipes ver os efeitos potenciais das alterações de processamento, porque elas não têm uma visão geral de todo o ciclo de vida de ponta a ponta. Eles devem trabalhar juntos para projetar um plano de liberação bem definido que minimize os efeitos sobre os consumidores e pipelines existentes. Esse gerenciamento de dependência aumenta a sobrecarga de gerenciamento.
- Como regra, as equipes não são especialistas no assunto do ativo de dados que o consumidor de dados solicita. Para entender os novos recursos do conjunto de dados ou valores de parâmetros, eles precisam consultar um especialista.
- Depois que todas as alterações são implementadas, o consumidor de dados é notificado de que o novo ativo de dados está pronto para uso.
Cada grande organização tem milhares de consumidores de dados. Um processo complicado como o descrito diminui drasticamente a velocidade em grandes arquiteturas, uma vez que equipes centralizadas se tornam um gargalo para as unidades de negócios. O resultado é menos inovação e eficácia limitada. Potencialmente, as unidades de negócios podem decidir deixar o serviço e construir sua própria plataforma de dados.
Métodos de dimensionamento
A análise em escala de nuvem aborda os desafios de dimensionamento usando dois conceitos principais:
- Usando zonas de aterrissagem de dados para dimensionamento
- Usando produtos de dados ou integrações de dados para escala, a fim de tornar possível a propriedade de dados distribuídos e descentralizados
Você pode implantar uma única zona de aterrissagem de dados ou várias. As zonas de aterrissagem de dados possibilitam que você descubra e gerencie dados conectando-se a uma zona de aterrissagem de gerenciamento de dados. Cada zona de aterrissagem de gerenciamento de dados está dentro de uma única assinatura do Azure.
As subscrições são as unidades de gestão, faturação e escala do Azure. Eles desempenham um papel crítico em seu plano de adoção do Azure em grande escala.
Dimensionamento com zonas de aterrissagem de dados
Os conceitos centrais da análise em escala de nuvem são a zona de aterrissagem de gerenciamento de dados e a zona de pouso de dados. Você deve colocar cada um em sua própria assinatura do Azure. Separá-los permite separar claramente as tarefas, seguir o princípio do menor privilégio e resolver parcialmente os problemas de escala de assinatura mencionados anteriormente. Uma configuração mínima de análise em escala de nuvem inclui uma única zona de aterrissagem de dados e uma única zona de aterrissagem de gerenciamento de dados.
No entanto, uma configuração mínima não é suficiente para implantações de plataforma de dados em grande escala. As empresas criam plataformas de grande escala e fazem investimentos para escalar de forma consistente e eficiente seus esforços de dados e análises ao longo do tempo. Para superar as limitações no nível da assinatura, a análise em escala de nuvem usa assinaturas como a unidade de dimensionamento, conforme discutido nas zonas de aterrissagem do Azure. Essa técnica torna possível aumentar a pegada da plataforma de dados adicionando mais zonas de aterrissagem de dados à arquitetura. A adoção dessa técnica também resolve o problema de um Azure Data Lake Gen2 ser usado para toda a organização, já que cada zona de aterrissagem de dados inclui três data lakes. Projetos e atividades de vários domínios podem ser distribuídos em mais de uma assinatura do Azure, proporcionando assim maior escalabilidade.
Decida quantas zonas de aterrissagem de dados sua organização precisa antes de implementar uma arquitetura de análise em escala de nuvem. Tomar a decisão certa estabelece as bases para uma plataforma de dados eficaz e eficiente.
O número de zonas de aterragem de dados necessárias depende de muitos fatores, especialmente:
- Alinhamento organizacional, como quantas unidades de negócios precisam de sua própria zona de aterrissagem de dados
- Considerações operacionais, como como sua organização alinha recursos operacionais e recursos específicos de uma unidade de negócios.
O uso do modelo correto de zona de aterrissagem de dados minimiza os esforços futuros para mover produtos de dados e ativos de dados de uma zona de aterrissagem para outra. Ele também ajuda você a dimensionar de forma eficaz e consistente os esforços de big data e análise no futuro.
Considere os seguintes fatores ao decidir sobre o número de zonas de aterrissagem de dados a serem implantadas.
| Fator | Descrição |
|---|---|
| Estrutura organizacional e propriedade dos dados | Considere como sua organização está estruturada e como os dados são de propriedade de sua organização. |
| Região e localização | Se você implantar em várias regiões, decida qual região ou regiões devem hospedar as zonas de dados. Certifique-se de honrar todos os requisitos de residência de dados. |
| Quotas | As cotas de assinatura não são garantias de capacidade e são aplicadas por região. |
| Soberania dos dados | Devido aos regulamentos de soberania de dados, os dados devem ser armazenados em uma região específica e seguir políticas específicas da região. |
| Políticas do Azure | As zonas de aterrissagem de dados devem seguir os requisitos de várias políticas do Azure. |
| Limites de gestão | As assinaturas fornecem um limite de gerenciamento para governança e isolamento que separa claramente as preocupações. |
| Rede | Cada zona de desembarque tem uma rede virtual. Como uma rede virtual reside em uma única região, cada nova região requer uma nova zona de pouso. As redes virtuais devem ser redes virtuais de mesmo nível para permitir a comunicação entre domínios. |
| Limites | Uma subscrição tem limites. Ao ter várias assinaturas, você pode mitigar os perigos de atingir esses limites. |
| Alocação de custos | Considere se os serviços compartilhados, como contas de armazenamento pagas centralmente, devem ser divididos por unidade de negócios ou domínio. O uso de uma assinatura separada cria um limite para a alocação de custos. Você pode obter a mesma funcionalidade usando tags. |
| Classificações de dados e dados altamente confidenciais | Os mecanismos de segurança podem afetar o desenvolvimento de produtos de dados e a usabilidade de uma plataforma de dados. Considere classificações de dados e decida se conjuntos de dados altamente confidenciais exigem tratamento especial, como acesso just-in-time, chaves gerenciadas pelo cliente (CMK), controles de rede refinados ou mais criptografia. |
| Outras implicações jurídicas ou de segurança | Considere se existem outros requisitos legais ou de segurança que exijam a separação lógica ou física dos dados. |
Se você implementar uma arquitetura de malha de dados, considere os seguintes fatores ao decidir como distribuir suas zonas de aterrissagem de dados e domínios de dados.
| Fator | Descrição |
|---|---|
| Domínios de dados | Considere os domínios de dados que sua organização usa e decida quais estarão em sua plataforma de dados. Considere o tamanho de seus domínios de dados individuais. Para obter mais informações, consulte O que são domínios de dados? |
| Latência | Os domínios que colaboram em grandes quantidades de dados podem transferir uma grande quantidade de dados entre zonas de aterrissagem. Considere alocar seus domínios na mesma zona ou região de destino. Separá-los aumenta a latência e pode aumentar os custos em domínios entre regiões. |
| Segurança | Algumas implantações ou configurações de serviço exigem privilégios elevados em uma assinatura. Conceder esses privilégios a um usuário em um domínio implicitamente dá a esse usuário os mesmos privilégios em outros domínios dentro da mesma assinatura. |
Você pode encontrar mais considerações nas diretrizes da estrutura de adoção de nuvem para assinaturas.
Muitas organizações querem um dimensionamento eficiente de sua plataforma de dados corporativos. As unidades de negócios devem ser capazes de criar suas próprias soluções de dados e aplicativos para atender às suas necessidades exclusivas. Fornecer essa capacidade pode ser um desafio, porque muitas plataformas de dados existentes não são construídas em torno dos conceitos de escalabilidade e propriedade descentralizada. Essa falha é claramente vista na arquitetura, na estrutura da equipe e no modelo de operações dessas plataformas de dados.
As zonas de aterrissagem de dados não criam silos de dados em sua organização. A configuração de rede recomendada para análise em escala de nuvem permite o compartilhamento seguro e in-loco de dados entre zonas de aterrissagem, o que, por sua vez, permite a inovação entre domínios de dados e unidades de negócios. Para saber mais, consulte Considerações sobre arquitetura de rede.
O mesmo vale para a camada de identidade. Ao usar um único locatário do Microsoft Entra, você pode conceder acesso de identidades a ativos de dados em várias zonas de aterrissagem de dados. Para saber mais sobre o processo de autorização de usuário e identidade, consulte Gerenciamento de acesso a dados.
Nota
Se você tiver várias zonas de aterrissagem de dados, cada zona poderá se conectar a dados hospedados em outras zonas. Isso permite que grupos colaborem em toda a sua empresa.
A análise em escala de nuvem usa uma arquitetura comum para defender uma governança consistente. Sua arquitetura define recursos e políticas de linha de base. Todas as zonas de aterragem de dados obedecem à mesma auditoria e controlos. Suas equipes podem criar pipelines de dados, ingerir fontes e criar produtos de dados, como relatórios e painéis. As equipes também podem fazer análises Spark/SQL conforme necessário. Você pode aumentar os recursos da zona de aterrissagem de dados adicionando serviços ao recurso na política. Por exemplo, uma equipe pode adicionar um mecanismo gráfico de terceiros para atender a um requisito de negócios.
A análise em escala de nuvem coloca uma forte ênfase na catalogação e classificação central para proteger os dados e possibilitar que vários grupos descubram produtos de dados.
Atenção
Recomendamos não consultar dados entre regiões. Em vez disso, certifique-se de que os dados estão próximos da computação que os utiliza, respeitando os limites regionais.
A arquitetura de análise em escala de nuvem e o conceito de zonas de aterrissagem de dados possibilitam que sua organização aumente facilmente o tamanho de sua plataforma de dados ao longo do tempo. Você pode adicionar mais zonas de aterrissagem de dados em uma abordagem em fases. Seus clientes não precisam ter várias zonas de pouso no início. Ao adotar essa arquitetura, priorize algumas zonas de aterrissagem de dados e os produtos de dados que elas contêm. A priorização adequada ajuda a garantir o sucesso de sua implantação de análise em escala de nuvem.
Dimensionamento com produtos de dados ou integrações de dados
Dentro de cada zona de destino, sua organização pode ser dimensionada usando aplicativos de dados. Os aplicativos de dados são unidades ou componentes de sua arquitetura de dados que encapsulam a funcionalidade que fornece produtos de dados otimizados para leitura para consumo por outros aplicativos de dados. No Azure, os aplicativos de dados são ambientes na forma de grupos de recursos que possibilitam que equipes multifuncionais implementem soluções de dados e cargas de trabalho. Uma equipe associada cuida do ciclo de vida completo da solução de dados, que inclui ingestão, limpeza, agregação e execução de tarefas.
A análise em escala de nuvem aborda as questões de integração de dados e responsabilidade que foram discutidas anteriormente. Em vez de responsabilidades funcionais monolíticas para ingestão de tabelas e integração do sistema de origem, o design de referência fornece uma arquitetura distribuída que é orientada por domínios de dados. As equipes multifuncionais assumem a responsabilidade funcional de ponta a ponta e a propriedade do escopo de dados.
Em vez de ter uma pilha técnica centralizada e uma equipe responsável por todas as tarefas do seu fluxo de trabalho de processamento de dados, você pode distribuir a responsabilidade de ponta a ponta entre várias equipes autônomas de integração de dados multifuncionais. Cada equipe possui um domínio ou subdomínio e é incentivada a fornecer conjuntos de dados conforme exigido pelos consumidores de dados.
Essas diferenças arquitetônicas levam ao aumento da velocidade em sua plataforma de dados. Seus consumidores de dados não precisam mais depender de um conjunto de equipes centralizadas ou lutar para que as alterações solicitadas sejam priorizadas. À medida que equipes menores se apropriam do seu fluxo de trabalho de integração de ponta a ponta, o ciclo de feedback entre o provedor de dados e o consumidor de dados é muito mais curto. Essa abordagem resulta em priorização mais rápida, ciclos de desenvolvimento mais rápidos e um processo de desenvolvimento mais ágil. Suas equipes não precisam mais sincronizar processos e liberar planos entre si, porque a equipe de integração de dados multifuncional tem plena consciência da pilha técnica de ponta a ponta e das implicações das alterações. Ele pode usar práticas de engenharia de software para executar testes de unidade e integração para minimizar o efeito geral sobre os consumidores.
Idealmente, a equipe que possui os sistemas de integração de dados também possui os sistemas de origem. Essa equipe deve ser composta por engenheiros de dados que trabalham nos sistemas de origem, especialistas no assunto (PMEs) para os conjuntos de dados, engenheiros de nuvem e proprietários de produtos de dados. A criação desse tipo de equipe multifuncional reduz a quantidade de comunicação necessária com equipes externas e é essencial ao desenvolver sua pilha completa, desde a infraestrutura até os pipelines de dados reais.
A base da sua plataforma de dados são conjuntos de dados integrados a partir de sistemas de origem. Esses conjuntos de dados possibilitam que suas equipes de produtos de dados inovem em tabelas de fatos de negócios e melhorem a tomada de decisões e os processos de negócios. Suas equipes de integração de dados e equipes de produtos de dados devem oferecer SLAs aos consumidores e garantir que todos os contratos sejam cumpridos. Os SLAs oferecidos podem estar relacionados à qualidade dos dados, pontualidade, taxas de erro, tempo de atividade e outras tarefas.
Resumo
Ao utilizar os mecanismos de dimensionamento da sua arquitetura de análise à escala da nuvem, a sua organização aumenta o seu património de dados no Azure ao longo do tempo, evitando limitações técnicas bem conhecidas. Ambos os métodos de dimensionamento descritos neste artigo ajudam você a superar diferentes complexidades técnicas e podem ser usados de forma simples e eficiente.