Processamento de Dados Massivos/Aspectos gerais do ambiente de Big Data
O ambiente de execução
[editar | editar código-fonte]Dados massivos estão frequentemente relacionados ao modelo de computação em nuvem. Nesse caso, serviços são oferecidos de forma transparente de localização e adaptando-se às demandas dos usuários. O processamento real e, de forma relacionada, o armazenamento dos grandes volumes de dados envolvidos, se dá em datacenters instalados em algum lugar da rede. Para melhor entendermos os modelos de processamento de dados massivos devemos, então, entender como esse ambiente se organiza e como os dados são armazenados.
Arquitetura de datacenters
[editar | editar código-fonte]Em um datacenter, recursos computacionais são organizados de forma concentrada, a fim de melhor controlar o consumo de energia necessária para o funcionamento dos equipamentos e para a refrigeração dos mesmos [1]. Dada a economia de escala envolvida, os computadores utilizados são computadores convencionais, “off-the-shelf”, cada um com boa capacidade de processamento, memória e discos. Os computadores são instalados em racks, com dezenas de máquinas por rack. Em cada rack é instalado um comutador (switch) Ethernet, denominado switch de topo de rack (TOR), que interliga as máquinas do rack à velocidade de 1 Gigabit por segundo, de forma não bloqueante (todas as máquinas podem se comunicar a 1 Gpbs, desde que o padrão de comunicação seja igualmente distribuído entre elas). Os switches TOR são então interligados por switches de backbone utilizando diversos links para cada rack, ou mesmo links de 10 Gpbs. Uma representação geral dessa infraestrutura é ilustrada na figura a seguir. Em datacenters muito grandes, pode até existir um segundo nível de comutadores, para expandir o alcance da rede [2].
No caso de ambientes em nuvem essa tende a ser a organização mais comum para as unidades de processamento, sem servidores de armazenamento dedicados, pois eles se tornam gargalos para os grandes volumes de processamento envolvidos. Qualquer solução de armazenamento e processamento deve, então, considerar que todos os elementos do sistema têm arquitetura semelhante, apesar de poderem ser heterogêneos em capacidade. Além disso, é importante manter em mente que a comunicação entre unidades em um mesmo rack pode se dar a uma velocidade maior que entre máquinas de racks diferentes, uma vez que a capacidade dos links que ligam os switches TOR ao backbone é quase sempre menor que a capacidade agregada das máquinas em um rack. Por exemplo, um rack pode ter de 20 a 40 máquinas, cada uma com pelo menos uma interface Ethernet Gigabit. Usualmente, a conexão dos TORs para o backbone não passará de quatro links de 1 Gbps ou, no máximo, um link de 10 Gbps.
Para tornar as coisas ainda mais desafiadoras, por serem equipamentos semelhantes e sem recursos especiais para tolerância a falhas, qualquer elemento (computadores e switches) pode falhar a qualquer instante. De fato, dado o grande número de equipamentos normalmente agrupados em um datacenter, as chances de alguma falha ocorrer é relativamente alta. Qualquer solução de armazenamento e processamento nesse caso deve ser capaz de lidar com falhas de forma transparente para o usuário.
Armazenamento de dados
[editar | editar código-fonte]Considerando-se essa arquitetura, para garantir o melhor desempenho durante o processamento, dados devem ser distribuídos entre os discos das diversas máquinas de forma que possam ser lidos em paralelo, para serem processados também em paralelo. Apesar de algumas soluções mais simples deixarem a tarefa de organizar os dados dessa forma a cabo do usuário, idealmente essa funcionalidade deve ser oferecida por um sistema de armazenamento distribuído. Historicamente, sistemas de arquivo paralelos [3] foram desenvolvidos para esse fim no contexto de sistema de processamento de alto desempenho (HPC). Entretanto, no contexto de dados massivos, observou-se que os padrões de acesso aos dados tendem a ser mais simples que nos ambientes de HPC e soluções particulares têm se mostrado mais adequadas nesse contexto . O modelo mais adotado para esse fim tem sido o modelo proposto pelo Google File System (GFS) [4] e também implementado pelo Hadoop File System (HDFS) [5].
No Google File System, arquivos são escritos sequencialmente quando criados, ou dados são acrescentados sequencialmente ao final de um arquivo já existente (append). Alterações não são possíveis depois que um dado é escrito e o objetivo é tornar eficiente padrões de acesso que percorram todo o arquivo de cada vez. Para isso, arquivos são dividos em blocos grandes (usualmente 64 MB), que são distribuídos pelos discos de diversas máquinas do sistema e replicados para aumentar a disponibilidade dos mesmos.
No GFS (e HDFS), cada sistema de arquivos tem uma máquina escolhida como servidor do espaço de nomes (namenode), responsável também por armazenar os metadados de cada arquivo. A estrutura de arquivos do GFS é isolada e independente da árvore de diretórios usual acessada por cada máquina. Os acessos se dão através de uma biblioteca especial e não através da interface de chamadas de sistema.
Ao criar um arquivo, um cliente registra seu nome com o namenode e começa a escrever os blocos em máquinas escolhidas no mesmo rack em que executa o processo escritor (para aproveitar a melhor banda entre máquinas no mesmo rack). Uma vez escrita essa primeira cópia o cliente continua seu processamento, enquanto o servidor de armazenamento do GFS que recebeu o bloco (denominado datanode) passa a replicar o mesmo em um outro datanode, escolhido normalmente em um outro rack (para evitar problemas com falhas que afetem um rack inteiro). Usualmente cada bloco é replicado três vezes (apesar desse número poder ser configurado pelo usuário para cada arquivo) e uma terceira cópia é feita então pelo segundo datanode para um outro datanode no mesmo rack (de novo, aproveitando a banda local).
Ao abrir um arquivo para leitura, o cliente se comunica como namenode e recebe dele a lista de blocos do arquivo, com a identificação dos namenodes que armazenam cada bloco. O cliente pode então escolher de qual namenode requisitar os dados de que necessita baseado em critérios de proximidade. Dessa forma, vários clientes podem escolher ler partes diferentes do arquivo a partir de datanodes diferentes, aumentando a banda de leitura dos dados.
Periodicamente, processos administrativos verificam a disponibilidade de cada datanode e os blocos armazenados em cada um, comandando novas cópias ou movendo blocos entre nós para garantir o balanceamento entre eles. Esses processos também cuidam de comandar a redistribuição de blocos quando novos datanodes são acrescentados ao sistema, ou comandar novas replicações quando algum nó falha.
Esses são elementos importantes do ambiente normalmente utilizado para processamento de dados massivos. A seção a seguir discute os principais aspectos de escalabilidade e eficiência que precisam ser considerados nesse caso, para então discutirmos nas seções seguintes os modelos de processamento disponíveis.
Referências
[editar | editar código-fonte]- ↑ Barroso, L., e Holzle, U. The Datacenter as a Computer: An Introduction to the Design of Warehouse-scale Machines. Synthesis lectures in computer architecture. Morgan & Claypool, 2009.
- ↑ Greenberg, A., Hamilton, J., Maltz, D. A., and Patel, P. The cost of a cloud: research problems in data center networks. SIGCOMM Computer Communication Review 39(1), Dec. 2008, 68–73.
- ↑ Nagle, D., Serenyi, D., and Matthews, A. The panasas activescale storage cluster: Delivering scalable high bandwidth storage. In Proceedings of the 2004 ACM/IEEE conference on Supercomputing (Washington, DC, USA, 2004), SC ’04, IEEE Computer Society, pp. 53–.
- ↑ Ghemawat, S., Gobioff, H., and Leung, S.-T. The google file system. SIGOPS: Operation Systems Review 37(5), 2003, 29–43
- ↑ Borthakur, D. The Hadoop Distributed File System: Architecture and Design. The Apache Software Foundation, 2007.