Escalar a análise de escala de nuvem no Azure
Uma plataforma de dados escalonável é crítica para se adaptar ao rápido crescimento dos dados. Grandes volumes de dados são geradas a cada segundo ao redor do mundo. Espera-se que o volume de dados disponíveis continue a crescer exponencialmente nos próximos anos. À medida que a taxa de geração de dados aumenta, a velocidade da movimentação de dados também aumenta.
Não importa a quantidade de dados que você tenha, seus usuários exigem respostas de consulta rápidas. A expectativa dos usuários é esperar minutos, e não horas, para receber os 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 uma única conta do Azure Data Lake Gen2 e, às vezes, um único contêiner de armazenamento. Geralmente, uma única assinatura do Azure é usada para todas as tarefas relacionadas à plataforma de dados. A escala de nível de assinatura está ausente na maioria das plataformas de arquitetura, o que pode dificultar a adoção contínua do Azure, caso os usuários se deparem com qualquer uma das limitações de nível de serviço ou de assinatura do Azure. Mesmo que algumas das restrições sejam limites suaves, atingi-las ainda pode ter um efeito negativo significativo em sua plataforma de dados.
Ao estruturar sua plataforma de dados, considere a estrutura de sua organização. Observe a propriedade dos dados e as responsabilidades funcionais de suas equipes. Se a organização fornecer às equipes altos níveis de autonomia e propriedade distribuída, uma arquitetura de malha de dados será a melhor opção.
Evite situações que tenham diferentes equipes 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 determinado ativo de dados, eles devem passar por um processo de várias etapas. Para este exemplo, as etapas são:
- O consumidor de dados envia um ticket 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 verem 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 lançamento 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 sobre o ativo de dados que o consumidor de dados solicita. Para entender novos recursos de conjunto de dados ou valores de parâmetro, elas 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 criar sua própria plataforma de dados.
Métodos para escala
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 dimensionamento, 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 destino de gerenciamento de dados reside em uma única assinatura do Azure.
As assinaturas são unidades de gerenciamento, cobrança e escala do Azure. Eles desempenham um papel crítico em seu plano de adoção do Azure em larga escala.
Escala com zonas de destino de dados
Os conceitos centrais da análise de escala de nuvem incluem a zona de destino de gerenciamento de dados e a zona de destino 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 de privilégios mínimos e resolver parcialmente os problemas de escala de assinatura mencionados anteriormente. Uma configuração mínima de análise de escala de nuvem inclui uma única zona de destino de dados e uma única zona de destino 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 constroem 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 o espaço ocupado pela 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 uma organização inteira, 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, fornecendo 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 aterrissagem 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 a forma como sua organização alinha os recursos operacionais e os recursos específicos de uma unidade de negócios.
O uso do modelo de zona de aterrissagem de dados correto 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 escalar 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 de dados | Considere como sua organização está estruturada e como os dados são de propriedade em 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. |
| Cotas | As cotas de assinatura não são garantias de capacidade e são aplicadas por região. |
| Soberania de 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. |
| Limite de gerenciamento | As assinaturas fornecem um limite de gerenciamento para governança e isolamento, o que separa claramente as preocupações. |
| Rede | Cada zona de pouso tem uma rede virtual. Como uma rede virtual reside em uma única região, cada nova região requer uma nova zona de aterrissagem. As redes virtuais devem ser redes virtuais de mesmo nível para permitir a comunicação entre domínios. |
| Limites | Uma assinatura 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 alocação de custo. Você pode obter a mesma funcionalidade usando marcas. |
| 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 as 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 legais ou de segurança | Considere se há outros requisitos legais ou de segurança que exijam 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 destino 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 dos 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 volumes de dados podem transferir um grande volume de dados entre zonas de destino. Aloque os domínios na mesma zona de destino ou região. 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. Dar 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 na 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 a seus requisitos exclusivos. Fornecer essa capacidade pode ser um desafio, pois muitas plataformas de dados existentes não são criadas com base nos conceitos de escalabilidade e propriedade descentralizada. Essa deficiência é claramente vista na arquitetura, estrutura de equipe e modelo de operações dessas plataformas de dados.
As zonas de destino de dados não criam silos de dados na organização. A configuração de rede recomendada para análise de escala de nuvem permite o compartilhamento de dados seguro e in-loco entre zonas de destino, o que, por sua vez, permite a inovação entre domínios de dados e unidades de negócios. Para saber mais, confira Considerações de 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 destino de dados. Para saber mais sobre o processo de autorização de usuário e identidade, consulte Gerenciamento de acesso a dados.
Observação
Se você tiver várias zonas de aterrissagem de dados, cada zona poderá se conectar a dados hospedados em outras zonas. Isso permite que os grupos colaborem em toda a empresa.
A análise de escala de nuvem usa uma arquitetura comum para defender uma governança consistente. A arquitetura define as funcionalidades e as políticas de linha de base. Todas as zonas de destino de dados aderem aos mesmos controles e processos de auditoria. As 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 a análise do Spark/SQL, conforme necessário. É possível aumentar os recursos da zona de destino de dados adicionando serviços à funcionalidade 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 centrais para proteger os dados e possibilitar que vários grupos descubram produtos de dados.
Cuidado
Não recomendamos consultar dados entre regiões. Em vez disso, certifique-se de que os dados estejam próximos da computação que os usa, respeitando os limites regionais.
A arquitetura de análise em escala de nuvem e o conceito de zonas de destino 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 destino 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.
Escala com produtos de dados ou integrações de dados
Dentro de cada zona de aterrissagem, sua organização pode escalar 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 tarefas de serviço.
A análise em escala de nuvem aborda os problemas de integração de dados e responsabilidade que foram discutidos 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 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 recurso de domínio ou subdomínio e é incentivada a servir 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 fluxo de trabalho de integração de ponta a ponta, o loop de comentários entre o provedor de dados e o consumidor de dados é muito menor. 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 planos de lançamento entre si, porque a equipe de integração de dados multifuncionais tem plena consciência da pilha técnica de ponta a ponta e das implicações das mudanças. 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 proprietária dos 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. Criar esse 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 que são 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
Usando os mecanismos de dimensionamento de sua arquitetura de análise em escala de nuvem, sua organização aumenta seu estado de dados no Azure ao longo do tempo, evitando limitações técnicas conhecidas. Ambos os métodos de dimensionamento descritos neste artigo ajudam a superar diferentes complexidades técnicas e podem ser usados de maneira simples e eficiente.