Aula 03

Aula 03
Business Intelligence para Concursos - Curso Regular

Professor: Thiago Rodrigues Cavalcanti
Big Data e NoSQL
Prof. Thiago Rodrigues Cavalcanti Aula xx
AULA xx: Big Data e Banco de dados NoSQL
Sumário
Big Data ............................................................................................................................................... 1
1. Definições e conceito .................................................................................................. 1
2. Falácias sobre Big Data .............................................................................................. 4
3. Aplicações de Big Data ............................................................................................... 5
4. NoSQL ............................................................................................................................... 7
4.1. Conceitos ..................................................................................................................... 7
4.2. Modelos de dados ..................................................................................................... 9
4.2.1. Modelo de dados chave-valor ........................................................................ 10
4.2.2. Modelo de dados de documento ................................................................... 11
4.2.3. Modelo colunar .................................................................................................... 12
4.2.4. Modelo de grafos ................................................................................................ 13
4.2.5. Considerações finais sobre modelos ........................................................... 14
4.3. Formas de distribuição ......................................................................................... 14
4.4. Teorema CAP............................................................................................................ 15
4.5. ACID x BASE ............................................................................................................ 16
4.6. Map-Reduce .............................................................................................................. 19
5. Hadoop ........................................................................................................................... 20
5.1. O ecossistema do Hadoop ................................................................................... 22
Questões comentadas .............................................................................................................. 28
Considerações finais ...................................................................................................................... 41
Referência ......................................................................................................................................... 41
Nesta aula nosso intuito é desenvolver um pouco seu conhecimento sobre

bancos de dados não relacionais. Esse conceito surgiu pela necessidade de
utilização de Big Data. Podemos falar de espaço de armazenamento, algo
semelhante ao que dizemos sobre dinheiro, você tende a utilizar todos o espaço
de armazenamento disponível. Considerando que o custo de armazenamento
ficou pequeno, comparado com alguns anos atrás, principalmente com o
surgimento de Cloud Computing, é possível focar nossa atenção na organização
destas bases e no processamento dos dados. Para isso, utilizamos
respectivamente bases NoSQL e infraestruturas baseadas em processamento 16712855225
distribuído como o Hadoop. Vem comigo conhecer um pouco deste universo

paralelo de banco de dados! 
Big Data
1. Definições e conceito
Nossa ideia é começar o assunto apresentando, de forma sucinta, os

conceitos básicos que permeiam o termo Big Data. Vamos começar pela
definição que surgiu em 2001 no Meta Group (que viria a se tornar Gartner mais
adiante) por meio do analista Doug Laney. Para compor o conceito ele se
Prof. Thiago Rodrigues Cavalcanti

www.estrategiaconcursos.com.br 1 de 41
Big Data e NoSQL
utilizou de três termos, conhecidos como os 3Vs: Volume, Velocidade e

Variedade. Vejamos a definição de cada um deles.
 Volume. Existem muitos fatores que contribuem para o aumento do

volume de dados armazenados e trafegados. Podemos citar como
exemplo: dados de transações armazenados ao longo de vários anos,
dados de texto, áudio ou vídeo disponíveis em streaming nas mídias
sociais e a crescente quantidade de dados coletados por sensores. No
passado o volume de dados excessivo criou um problema de
armazenamento. Mas, com os atuais custos de armazenamento
decrescentes, outras questões surgem, incluindo, como determinar a
relevância entre grandes volumes de dados e como criar valor a partir
dessa relevância.
 Velocidade. De acordo com o Laney, velocidade significa o

quão rápido os dados estão sendo produzidos e o quão rápido os dados
devem ser tratados para atender as demandas. Etiquetas de RFID e
sensores inteligentes estão impulsionando uma necessidade crescente de
lidar com dados quase em tempo real. Reagir rápido o suficiente para
lidar com a velocidade é um desafio para a maioria das organizações.
 Variedade. Os dados de hoje vêm em todos os tipos de formatos.

Sejam bancos de dados tradicionais, hierarquias de dados criadas por
usuários finais e sistemas OLAP, arquivos de texto, e-mail, medidores ou
sensores de coleta de dados, vídeo, áudio, dados de ações do mercado e
transações financeiras. Em algumas estimativas, 80% dos dados de uma
organização não são numéricos! Mas, estes dados também precisam ser
incluídos nas análises e nas tomadas de decisões das empresas.
16712855225

Big Data e NoSQL
Vejam a figura apresentada acima. Ela representa uma indicação do

conceito de Big Data relacionando os três Vs sobre os quais tratamos até agora.
Contudo, existem outros Vs, são eles Veracidade, Visibilidade, Valor e
Variabilidade que complementam o conceito, detalhando um pouco mais
algumas características de Big Data.
 Veracidade. A veracidade foi um termo cunhado pela IBM, considerado o

quarto V, que representa a falta de confiabilidade inerente em
algumas fontes de dados. Por exemplo, medir os sentimentos dos clientes
em mídias sociais é incerto por natureza, já que implicam uso do juízo
humano. No entanto, eles contêm valiosas informações. Assim, a
necessidade de lidar com dados imprecisos e incertos é outra faceta de
Big Data, geralmente resolvida usando ferramentas e análises
desenvolvidas para gerenciamento e mineração de dados imprecisos.
É necessário avaliar as inconsistências, incompletudes, ambiguidades,

latência e possíveis modelos de aproximação utilizados. Os dados podem
ainda perder a vigência. Verificar se os dados são consistentes é
extremamente necessário para qualquer análise de dados.
 Visibilidade. É a relevância dos dados. A organização está ciente de

todos os dados que ele gera? Estes poderiam ser (aparentemente)
registros de dados inconsequentes. Em outras palavras tentamos
entender se todos os dados gerados estão disponíveis, e se são de fato
armazenados e ficam visíveis para os analistas de dados.
 Valor. A Oracle introduziu valor como um atributo na definição de Big

Data. Com base na definição da Oracle, Big Data é, muitas vezes,
caracterizado por uma "densidade de valor relativamente baixa". Isto é,
os dados recebidos na forma original, geralmente tem um valor baixo em
relação ao seu volume. Entretanto, um valor elevado pode ser obtido pela
análise de grandes volumes destes mesmos dados. Assim, as informações
geradas devem produzir algum valor para as organizações.
16712855225
 Variabilidade (e complexidade). A SAS apresentou variabilidade (e

complexidade) como duas dimensões adicionais para Big Data.
Variabilidade refere-se à variação nas taxas de fluxo de dados. Muitas
vezes, a velocidade de Big Data não é consistente e tem picos e
depressões periódicas. Complexidade refere-se ao fato de Big Data gerar
ou receber informações através de uma multiplicidade de fontes. Isso
impõe um desafio crucial: a necessidade de se conectar, integrar, limpar e
transformar os dados recebidos de diferentes fontes.
Podemos agora apresentar uma definição de Big Data da IBM. É um termo

utilizado para descrever grandes volumes de dados e que ganha cada vez
mais relevância à medida que a sociedade se depara com um aumento sem

Big Data e NoSQL
precedentes no número de informações geradas. As dificuldades em

armazenar, analisar e utilizar grandes conjuntos de dados têm sido um
considerável gargalo para as organizações.
Big data trata, portanto, grandes volumes, alta velocidade e variedade dos
ativos de informação, procurando formas inovadoras e rentáveis de
processamento da informação, visando uma melhor percepção dos fatos e uma
tomada de decisão mais consistente. Outra definição da TechAmerica define
big data da seguinte forma: "Big Data é um termo que descreve grandes
volumes de dados de alta velocidade, complexos e variáveis que exigem técnicas
e tecnologias avançadas para permitir a captura, armazenamento, distribuição,
gestão e análise da informação”. Entendido os conceitos básicos vamos avançar
para as premissas e aplicações.
2. Falácias sobre Big Data

Quando pensamos em premissas sobre Big Data imaginamos uma caixa
preta que vai receber dados de um lado e entregar algo pronto do outro. Nesta
linha de raciocínio, provavelmente falaciosa, antes de apresentamos as
condições ideias para funcionamento dos sistemas ou projetos de Big Data, nós
mostraremos os erros que muitos assumem como verdade. Chamaremos de
falácias sobre Big Data.
Falácia 01 - Big Data não pode prever o futuro
Big data e todas as suas ferramentas de análise, comentários, experiências

científicas e visualizações não podem dizer o que vai acontecer no futuro. Por
quê? Os dados que você coletar vem inteiramente do passado. Temos ainda de
atingir um grau de evolução em que será possível coletar dados e os valores do
futuro. Sendo assim, nós podemos analisar o que aconteceu no passado e tentar
desenhar as tendências entre as ações e os pontos de decisão, e as suas
consequências, baseadas nos dados. Podemos usar isso para adivinhar que, em
circunstâncias semelhantes, se uma decisão semelhante for tomada,
16712855225
resultados semelhantes ocorreriam como resultado. Mas não podemos prever

o futuro.
Falácia 02 - Big Data não pode substituir seus valores ou os da sua

organização
Big Data é pobre para substituir valores ou aqueles costumes e padrões

pelos quais você vive sua vida e sua empresa se esforça para operar. Suas
escolhas sobre essas questões podem ser bem cristalinas, e pode ser mais fácil e
claro resolver as vantagens e desvantagens de diferentes cursos da ação, mas
os dados em si não podem ajudá-lo a interpretar como as decisões certas se
comparam com os padrões que você definiu para si e para a sua empresa.

Big Data e NoSQL
Os dados podem descrever todos os tipos de cenários, tanto os próprios

números quanto com a ajuda de software de visualização. Sua equipe pode criar
muitas projeções de cenários sobre um determinado assunto, mas esses
resultados são simplesmente isso - uma projeção. O trabalho de um executivo,
como um CIO, é utilizar as ferramentas e pessoal disponível dentro de seu
negócio, e realmente reconciliar os dados contra os valores da sua empresa.
Falácia 03 - Big Data não pode resolver problemas não

quantificáveis
Eis o velho ditado: Quando você só tem um martelo, tudo parece um

prego. Uma vez que você começa a ter algum sucesso usando big data para
prever e resolver problemas de negócios, haverá inevitavelmente uma tentação
para "perguntar aos dados" toda vez que você tiver um problema ou um item
sobre o qual a resolução não está clara.
Como mencionado anteriormente, os dados podem apresentar mais e

melhores opções e, talvez, deixar claro o que pode acontecer com cada uma
dessas escolhas. Às vezes, porém, os dados não são bons e isso ocorre quando
ele é usado de forma individual.
Por quê? É quase impossível de quantificar o comportamento de um

indivíduo. As pessoas têm seus próprios conjuntos de circunstâncias, os seus
próprios universos, suas próprias razões e contextos. É impossível aplicar a
matemática para um único indivíduo. Em vez disso, você tem que olhar para um
grupo de indivíduos, de preferência um subgrupo com características
semelhantes. Só então você pode observar as tendências de comportamento que
se aplicam a todo o grupo.
Agora que sabemos o que não pode ser feito com Big Data, vamos
entender quais as premissas que devem ser verificadas quando decidimos pela
implementação de um projeto de Big Data. Primeiro precisamos considerar os
elementos fundamentais para o crescimento de Big Data tais como o aumento
da capacidade de armazenamento, aumento do poder de processamento e
16712855225
disponibilidade de dados.
3. Aplicações de Big Data

As aplicações de Big Data e análise de dados são as mais variadas. Uma
lista retirada do livro do Aguinaldo Aragon nos traz as seguintes opções de uso:
desenvolvimento de mercado, inovação, desenvolvimento de produtos e serviço,
eficiência operacional, previsões de demanda de mercado, detecção de fraudes,
gerenciamento de riscos, previsão de concorrência, vendas, campanhas de
marketing, avaliação de desempenho de funcionários, alocação de orçamento
anual, estabelecimento de previsões financeiras, gestão de planos de saúde,
identificação de potenciais compradores e entendimento da base de cliente. Essa

Big Data e NoSQL
lista extensa nos mostra apenas parte das oportunidades geradas pela utilização
de Big Data.
O uso de Big Data por empresas como Amazon e Netflix tem demostrado
como a mineração de dados pode gerar resultados surpreendentes. A partir
destes dados, é possível conhecer melhor as escolhas dos usuários.
Implementações dos conceitos de Big Data permitem, hoje, possibilidades
quase infinitas, utilizando, por exemplo, mineração de dados conseguimos
verdadeiros insights sobre os dados.
Um exemplo disso foi a pesquisa feita pela Consultoria MGI. Ela estudou
dados em cinco grandes domínios - saúde nos Estados Unidos, o setor público na
Europa, varejo nos Estados Unidos, dados de produção e dados de localização de
pessoas em nível mundial. Big Data poderia gerar valor em cada um deles. Por
exemplo, um varejista pode utilizar do conceito para aumentar sua margem
operacional em mais de 60%.
O aproveitamento de Big Data no setor público tem um potencial

enorme também. Se o programa de saúde dos Estados Unidos fosse usar big
data de forma criativa e eficaz poderia impulsionar a eficiência e qualidade, o
setor poderia criar mais de US$ 300 bilhões em valor a cada ano. Dois terços
dos quais seriam sob a forma de redução nas despesas de saúde dos EUA em
cerca de 8 por cento. Nas economias desenvolvidas da Europa, os
administradores do governo poderiam economizar mais de € 100 bilhões em
melhorias de eficiência operacional usando big data, não incluindo o uso para
reduzir a fraude e erros ou aumentar a cobrança das receitas fiscais.
A quantidade de dados em nosso mundo está explodindo, e a análise de

grandes conjuntos de dados - os chamados big data - se tornará uma base
essencial na concorrência pelo mercado ou na prestação de um serviço público
de qualidade, apoiando novas ondas de crescimento na produtividade, inovação
e expectativa dos consumidores. Líderes em todos os setores terão de lidar com
as implicações de Big Data, não apenas os gestores orientados a dados, ou
cientistas de dados.
16712855225
O crescente volume e detalhamento das informações capturadas por

empresas, o aumento de dados multimídia, mídia social, e a Internet das Coisas
vão alimentar o crescimento exponencial dos dados no futuro.
A minha experiência pessoal no estudo de Big Data é que quando

começamos a ler sobre o assunto esses conceitos teóricos vistos até aqui são
apresentados de forma semelhante em vários artigos disponíveis na internet e
em livros especializados, mas aí você deve estar fazendo a seguinte pergunta: E
como eu implemento esse trem? (Homenagem aos meus amigos mineiros). E
alguém vai te responder: usa uma base NoSQL com a infraestrutura do
Hadoop! É sobre esses termos que falaremos agora.

Big Data e NoSQL
4. NoSQL
Começaremos analisando os conceitos e os modelos de dados que dão
suporte a bases de dados NoSQL.
4.1. Conceitos
Os bancos de dados relacionais foram bem-sucedidos porque trouxeram
os benefícios de armazenamento de dados persistentes de forma mais
organizada, com controle de concorrência entre as transações. As transações
desempenham um papel importante na hora de lidar com os erros, pois é
possível fazer uma alteração e, caso ocorra um erro durante seu processamento,
pode-se desfazê-la e voltar ao estado anterior.
Embora haja diferenças de um banco de dados relacional para outro os

mecanismos principais permanecem os mesmos: os dialetos SQL utilizados por
diversos fornecedores são similares, e as transações são realizadas praticamente
da mesma forma.
Banco de dados relacionais fornecem muitas vantagens, mas não são, de

forma alguma, perfeitos. Desde que surgiram, há muita frustração e críticas em
relação a seu uso.
Para os desenvolvedores de aplicativos, a maior frustração tem sido a

diferença entre o modelo relacional e as estruturas de dados na memória,
comumente chamada de incompatibilidade de impedância. Os modelos de
dados relacionais organizam os dados em uma estrutura de tabelas e linhas, ou,
mais apropriadamente, de relações e tuplas. Uma tupla é um conjunto de pares
nome-valor e uma relação é um conjunto de tuplas.
Ao longo dos anos, tornou-se mais fácil lidar com a incompatibilidade de

impedância devido à ampla disponibilidade de frameworks de mapeamento
objeto-relacional, como Hibernate e iBATIS, que implementam padrões de
16712855225
mapeamento bastante conhecidos. Embora a questão do mapeamento ainda

seja controversa dado que os frameworks poupam muito trabalho pesado às
pessoas, mas podem se tornar um problema quando estas exageram ao ignorar
o banco de dados, comprometendo o desempenho das operações de
manipulação de dados sobre a base.
Outro ponto relevante dentro do contexto apareceu devido ao crescimento

dos Sistemas Web. Lidar com o aumento da quantidade de dados e com o
tráfego exigiu mais recursos computacionais. Para comportar esse crescimento,
há duas opções: ir para cima (crescimento vertical) ou para fora (horizontal). Ir
para cima significa adquirir máquinas maiores, mais processadores, ter maior
capacidade de armazenamento em disco e memória. Maquinas maiores, todavia,

Big Data e NoSQL
tornam-se cada vez mais caras, sem mencionar que há limites físicos quanto ao
aumento do seu tamanho ou para se escalar verticalmente.
A alternativa seria utilizar mais máquinas menores em um cluster. Um

cluster de máquinas pequenas pode utilizar hardware mais acessível e acaba se
tornando mais barato para a aplicação. Ele também pode ser mais resiliente.
Embora falhas em máquinas individuais sejam comuns, o cluster, como um todo,
pode ser criado para continuar funcionando apesar dessas falhas, fornecendo
alta confiabilidade.
Duas empresas em particular – Google e Amazon – têm sido influentes no

processo de desenvolvimento de rotas alternativas para armazenamento
baseado na ideia de clusters. Ambas estiveram à frente na execução de grandes
clusters. Além disso, obtiveram quantidades de dados relevantes para testarem
e comprovarem seus modelos. Elas eram empresas bem-sucedidas e em
crescimento com fortes componentes técnicos, proporcionando-lhes os meios e
as oportunidades.
Não é surpresa o fato de que essas empresas tinham em mente acabar

com seus bancos de dados relacionais. Quando a década de 2000 chegou, elas
produziram artigos concisos, porém altamente influentes, a respeito de seus
trabalhos: BigTable (Google) e Dynamo (Amazon).
Os exemplos do BigTable e do Dynamo inspirou a criação de projetos, que

faziam experimentações com armazenamentos alternativos de dados, e
discussões sobre o assunto haviam se tornado uma parte essencial das melhores
conferências sobre software daquela época. O termo “NoSQL” que conhecemos
hoje é resultado de uma reunião realizada no dia 11 de junho de 2009, em São
Francisco – Califórnia, organizada por Johan Oskarsson, um desenvolvedor de
software de Londres.
Johan estava interessado em descobrir mais sobre esses novos bancos de

dados enquanto estava em São Francisco para um evento sobre Hadoop. Já que
dispunha de pouco tempo, achou que não seria viável visitar todas as empresas,
16712855225
de modo que resolveu organizar uma reunião em que todos pudessem estar
presentes e apresentar seu trabalho para quem estivesse interessado em
conhecê-lo.
A chamada original, NoSQL Meetup, para a reunião pedia por “bancos de

dados não relacionais, distribuídos e de código aberto”. As palestras lá realizadas
versaram sobre Voldemort, Cassandra, Dynomite, HBase, Hypertable, CouchDB
e MongoDB, mas o termo nunca ficou limitado a esse grupo original. Não há uma
definição genericamente aceita nem uma autoridade para fornecer uma, de
modo que tudo o que podemos fazer é discutir algumas características comuns
em bancos de dados que tendem a ser chamados de “NoSQL”.

Big Data e NoSQL
As características comuns dos bancos de dados NoSQl são: não utilizam

o modelo relacional, tem uma boa execução em clusters, ter código aberto (open
source), são criados para suportar propriedades da web do século XXI, e não
tem um esquema definido (schema free).
O resultado mais importante do surgimento do NoSQL é a persistência

poliglota. Em vez de escolher o banco de dados relacional mais utilizado por
todos, precisamos entender a natureza dos dados que estamos armazenando e
como queremos manipulá-los. O resultado é que a maioria das organizações terá
uma mistura de tecnologias de armazenamento de dados para diferentes
circunstâncias.
4.2. Modelos de dados

Um modelo de dados é a forma pela qual percebemos e manipulamos
nossos dados. Para as pessoas utilizarem um banco de dados precisam de um
modelo que descreve a forma pela qual interagimos com os dados desse banco.
Embora o termo formal para modelo esteja relacionado a um metamodelo ou
uma abstração sobre os dados, quando tratamos de modelos dentro do contexto
de NoSQL estamos nos referindo a forma ou o modo pelo qual o gerenciador do
banco de dados organiza seus dados.
O modelo de dados dominante nas últimas décadas é o modelo relacional,

já falamos bastante sobre ele em uma aula anterior, que pode ser entendido
como um conjunto de tabelas. Cada tabela possui linhas e cada linha representa
uma entidade de interesse. Descrevemos essa entidade por meio de colunas,
cada uma tendo um único valor. Uma coluna pode se referir a outra linha da
mesma tabela ou em uma tabela diferente, o que constitui um relacionamento
entre essas entidades.
Uma das mudanças mais evidentes trazidas pelo NoSQL é o afastamento do

modelo relacional. Cada solução NoSQL possui um modelo diferente, os quais
dividimos em quatro categorias amplamente utilizadas no ecossistema NoSQL:
16712855225
chave-valor, documento, família de colunas ou colunar, e grafos. Dessas

as três primeiras compartilham uma característica em comum conhecida como
“orientação agregada”.
A orientação agregada reconhece que você, frequentemente, deseja

trabalhar com dados na forma de unidades que tenham uma estrutura mais
complexa do que um conjunto de tuplas. Pode ser útil pensar em termos de um
registro complexo que permita que listas e outras estruturas de dados sejam
aninhadas dentro dele. Partindo desta ideia é possível agora definir o conceito de
agregado.
Um agregado é um conjunto de objetos relacionados que desejamos tratar

como uma unidade. Em particular, é uma unidade de manipulação de dados e

Big Data e NoSQL
gerenciamento de consistência. Normalmente, preferimos atualizar agregados

como operações atômicas e comunicarmo-nos com nosso armazenamento de
dados em termos agregados.
Essa definição corresponde bem ao funcionamento dos bancos de dados

chave-valor, documento e família de colunas. Lidar com agregados facilita muito
a execução desses bancos de dados em um cluster, uma vez que o agregado
constitui uma unidade natural para replicação e fragmentação. Agregados
também são, frequentemente, mais simples de ser manipulados pelos
programadores de aplicativos.
Vejam um exemplo de um modelo agregado na figura abaixo. Observem

que nestes casos é possível criar uma estrutura hierárquica dentro dos atributos
dos objetos. Para fazer isso usamos podemos usar JSON ou XML.
Vamos agora tratar com um pouco mais de detalhes cada uma das
categorias de modelos que apresentamos anteriormente.
16712855225
4.2.1. Modelo de dados chave-valor

O modelo de dados chave-valor trata o agregado como um todo opaco, o
que significa que somente será possível fazer uma pesquisa por chave para o
agregado como um todo, não sendo possível executar uma consulta nem
recuperar apenas parte do agregado.
Esse é o tipo de banco de dados NoSQL mais simples e permite a

visualização do banco de dados como uma grande tabela hash. Conforme
falamos acima, o banco de dados é composto por um conjunto de chaves, as
quais estão associadas um único valor. A figura abaixo apresenta um exemplo

Big Data e NoSQL
de um banco de dados que armazena informações pessoais no formato chave-

valor. A chave representa um campo como o nome, enquanto o valor representa
a instância do correspondente.
Este modelo, por ser de fácil compreensão e implementação, permite que

os dados sejam rapidamente acessados pela chave, principalmente em sistemas
que possuem alta escalabilidade, contribuindo para aumentar a disponibilidade
de acesso aos dados. As operações disponíveis para manipulação de dados são
bem simples, como get() e set (), que permitem retornar e capturar valores,
respectivamente. A desvantagem deste modelo é que não permite a recuperação
de objetos por meio de consultas mais complexas.
Como exemplo de banco de dados NoSQL que adota o modelo chave-valor

podemos destacar o Dynamo, o qual foi desenvolvido pela Amazon e,
posteriormente, foi utilizado como base para o desenvolvimento do banco de
dados Cassandra. Dentre as principais funcionalidades do Dynamo temos a
possibilidade de realizar particionamento, replicação e versionamento dos dados.
Além do Dynamo, outras soluções NoSQL seguem o mesmo conceito de chave-
valor: Redis, Riak e GenieDB.
4.2.2. Modelo de dados de documento

16712855225
O modelo de documentos torna o agregado transparente para o banco de

dados, permitindo que sejam executadas consultas e recuperações parciais.
Entretanto, pelo fato de o documento não possuir esquema, o banco de dados
não pode atuar muito na estrutura desse documento para otimizar o
armazenamento e a recuperação de partes do agregado.
Um documento, em geral, é um objeto com um identificador único e um

conjunto de campos, que podem ser strings, listas ou documentos aninhados.
Estes campos se assemelham a estrutura chave-valor, que cria uma única tabela
hash para todo o banco de dados. No modelo orientado a documentos temos um
conjunto de documentos e em cada documento temos um conjunto de campos
(chaves) e o valor deste campo.

Big Data e NoSQL
Outra característica importante é que este modelo não depende de um

esquema rígido, ou seja, não exige uma estrutura fixa como ocorre nos bancos
de dados relacionais. Assim, é possível que ocorra uma atualização na estrutura
do documento, com a adição de novos campos, por exemplo, sem causar
problemas no banco de dados.
Na figura a seguir temos um exemplo de documento representado por um

banco de dados de fornecedor (supplier) que tem os campos ID, Name, Address
e Order. Para cada um desses campos temos os valores associados. Vejam que
o atributo order aponta para outro documento.
Como principais soluções que adotam o modelo orientado a documentos

destacamos o CouchDB e o MongoDB. CouchDB utiliza o formato JSON e é
implementado em Java, além disso permite replicação e consistência. O
MongoDB foi implementado em C++ e permite tanto concorrência como
replicação.
4.2.3. Modelo colunar

Modelos de famílias de colunas dividem o agregado em famílias de colunas,
permitindo ao banco de dados tratá-las como unidades de dados dentro do
16712855225
agregado da linha. Isso impõe alguma estrutura ao agregado, mas também

permite que o banco de dados aproveite a estrutura para melhorar sua
acessibilidade.
Vejam que neste caso, mudamos o paradigma em relação ao modelo

chave-valor. A orientação deixa de ser por registros ou tuplas para orientação
por colunas. Neste modelo os dados são indexados por uma trilha (linha, colina e
timestamp), onde linhas e colunas são identificadas por chaves e o timestamp
permite diferenciar múltiplas versões de um mesmo dado.
Vale ressaltar que operações de leitura e escrita são atômicas, ou seja,

todos os valores associados a uma linha são considerados na execução destas
operações, independentemente das colunas que estão sendo lidas ou escritas.
Big Data e NoSQL
Outro conceito associado ao modelo é o de família de colunas (column Family),

que é usado com o intuito de agrupar colunas que armazenam o mesmo tipo de
dados.
Observem abaixo o que geralmente acontece na prática em banco de dados

colunar. Neste caso as colunas das tabelas são serializadas e armazenadas em
disco.
Este modelo de dados surgiu com o BigTable do Google, por isso é comum
falar sobre o modelo de dados BigTable. Dentre as características deste modelo
temos a possibilidade de particionamento dos dados, além de oferecer forte
consistência, mas não garante alta disponibilidade. Outras soluções sugiram
após o BigTable, dentre elas o Cassandra, desenvolvido pelo Facebook e
baseado no Dynamo. Temos também o Hbase, que é um banco de dados open
source semelhante ao BigTable, que utiliza o Hadoop.
4.2.4. Modelo de grafos

Bancos de dados de grafos são motivados por uma frustração diferente com
banco de dados relacionais e, por isso, têm um modelo oposto – registros
pequenos com interconexões complexas. A ideia desse modelo é representar os
16712855225
dados e/ou o esquema dos dados como grafos dirigidos, ou como estruturas que
generalizem a noção de grafos.
O modelo de grafos é mais interessante que outros quando informações

sobre a interconectividade ou a topologia dos dados são mais ou tão importantes
quantos os dados propriamente ditos. O modelo orientado a grafos possui três
componentes básicos: os nós (são os vértices do grafo), os relacionamentos
(são as arestas) e as propriedades (ou atributos) dos nós e relacionamentos.
Neste caso, o banco de dados pode ser visto como um multigrafo rotulado e
direcionado, onde cada par de nós pode ser conectado por mais de uma aresta.
Um exemplo pode ser: “Quais cidades foram visitadas anteriormente (seja
residindo ou viajando) por pessoas que viajaram para o Rio de Janeiro? ”.

Big Data e NoSQL
No modelo relacional esta consulta poderia ser muito complexa devido a

necessidade de múltiplas junções, o que poderia acarretar uma diminuição no
desempenho da aplicação. Porém, por meio dos relacionamentos inerentes aos
grafos, estas consultas tornam-se mais simples e diretas.
Alguns bancos que utilizam esse padrão são: Neo4J, Infinite Graph,
InforGrid, HyperGraphDB. Vejam a figura abaixo que apresenta duas
características relacionadas aos bancos de dados de grafos: o processamento e o
armazenamento nativo.
4.2.5. Considerações finais sobre modelos

Bancos de dados orientados a agregados tornam os relacionamentos entre
agregados mais difíceis de lidar do que relacionamentos intra-agregados.
Bancos de dados sem esquema permitem que campos sejam adicionados

livremente aos registros, mas geralmente há um esquema implícito esperado
pelos usuários dos dados.
Banco de dados orientados a agregados, muitas vezes, criam visões

materializadas para fornecer dados organizados de um modo diferente de seus
16712855225
agregados primários. Isso, muitas vezes, é realizado com computação

MapReduce.
4.3. Formas de distribuição

Há dois estilos de distribuição de dados: a replicação e a fragmentação. A
fragmentação distribui dados diferentes em múltiplos servidores, de modo que
cada servidor atue como a única fonte de um subconjunto de dados. A replicação
copia os dados para servidores distintos, de modo que cada parte dos dados
pode ser encontrada em múltiplos lugares. Um sistema pode utilizar ambas as
técnicas.

Big Data e NoSQL
A replicação mestre-escravo torna um nodo a cópia oficial, a qual lida com

gravações, enquanto os escravos sincronizam-se com o mestre e podem lidar
com as leituras. A replicação ponto a ponto permite gravações em qualquer
nodo; os nodos são coordenados para sincronizar suas cópias de dados. A
replicação mestre-escravo reduz a chance de conflitos de atualização, mas a
ponto a ponto evita carregar todas as gravações em um único ponto de falha.
4.4. Teorema CAP

No mundo NoSQL, é comum referimo-nos ao teorema CAP como o motivo
pelo qual pode-se precisar relaxar a consistência. Ele foi proposto originalmente
por Eric Brewer em 2000, e recebeu uma prova formal de Seth Gilbert e Nancy
Lynch alguns anos depois. É possível ouvir referências aos termos como
conjectura de Brewer.
A declaração do teorema CAP é que, dadas as três propriedades de

Consistência, Disponibilidade e de Tolerância a partições, somente é
possível obter duas delas. A sigla vem do nome dessas propriedades em inglês:
Consistency, Availability, e Partition tolerance. Logicamente, a existência do
teorema vai depende de como são definidas cada uma dessas propriedades.
Vejamos então a definição de cada uma delas. Antes vejam a figura abaixo o
diagrama de Van que representa o relacionamento entre as três propriedades.
16712855225
A consistência refere-se ao fato de que uma leitura em qualquer um dos

nodos de um sistema retorna como resultado a mesma informação. Vejam a
figura abaixo:

Big Data e NoSQL
A disponibilidade trata do fato das requisições de leitura e escrita sempre

serão reconhecidas e respondidas sobre a forma de sucesso ou falha. Desta
forma, toda solicitação recebida por um nodo que não esteja no estado de falha
deve resultar em uma resposta. A tolerância a partições significa que o cluster
pode suportar falhas na comunicação que o dividam em múltiplas partições
incapazes de se comunicar entre si, essa situação é conhecida como divisão
cerebral (split brain).
Observe na figura abaixo um exemplo de disponibilidade e tolerância a

partições. Veja que a partição B não possui os dados referentes ao id 3 e recebe
uma mensagem de erros no caso de uma partição.
16712855225
4.5. ACID x BASE

ACID é um princípio de design de banco de dados relacionado ao
gerenciamento de transações. É um acrônimo que significa: Atomicidade,
Consistência, Isolamento e Durabilidade.
ACID é um estilo de gerenciamento de transações que utiliza controles de

simultaneidade pessimista para garantir que a consistência seja mantida através
Big Data e NoSQL
da aplicação de bloqueios de registo. ACID é a abordagem tradicional de

gerenciamento de transações de banco de dados, uma vez que é aproveitada
pelos sistemas de gerenciamento de banco de dados relacionais.
Quando olhamos para o teorema CAP, os bancos de dados relacionais estão

associados à priorização das propriedades de Consistência e Disponibilidade.
O Modelo BASE (Basically Avaliable, Soft State, Eventual Consistency), foi

sugerido como contraposição ao ACID. O ACID é pessimista e força a
consistência no final de cada operação, enquanto o modelo BASE é otimista e
aceita que a consistência no banco de dados estará em um estado de fluxo, ou
seja, não ocorrerá no mesmo instante, gerando uma “fila” de consistência de
posterior execução.
A disponibilidade do Modelo BASE é garantida tolerando falhas parciais no

sistema, sem que o sistema todo falhe. Por exemplo, se um banco de dados está
particionado em cinco nós e um deles falha, apenas os clientes que acessam
aquele nó serão prejudicados, pois o sistema como todo não cessará seu
funcionamento.
A consistência pode ser relaxada permitindo que a persistência no banco de

dados não seja efetivada em tempo real (ou seja, logo depois de realizada uma
operação sobre o banco). Pelo ACID, quando uma operação é realizada no
SGBD, ela só será finalizada se houver a certeza de que a persistência dos dados
foi realizada no mesmo momento, fato que é derivado da propriedade da
durabilidade.
Já no BASE isso não se confirma. Para garantir a disponibilidade, algumas

etapas são dissociadas à operação requisitada, sendo executadas
posteriormente. O cliente realiza uma operação no banco de dados e, não
necessariamente, a persistência será efetivada naquele instante. O Modelo BASE
pode elevar o sistema a níveis de escalabilidade que não podem ser obtidos com
ACID.
16712855225
No entanto, algumas aplicações necessitam que a consistência seja

precisamente empregada. Nenhuma aplicação bancária poderá por em risco
operações de saque, depósito, transferência, etc. O projetista do banco de dados
deverá estar ciente de que se utilizar o Modelo BASE estará ganhando
disponibilidade em troca de consistência, o que pode afetar os usuários da
aplicação referente ao banco de dados.
Quando um banco de dados suporta BASE, favorece a disponibilidade sobre

a consistência. Em outras palavras, a base de dados é A + P a partir de uma
perspectiva de teorema CAP. Em essência, BASE aproveita concorrência
otimista, relaxando restrições fortes de consistência determinadas pelas
propriedades ACID.

Big Data e NoSQL
Se um banco de dados é basicamente disponível, esse banco de dados

sempre dará conhecimento ao pedido de um cliente, quer sob a forma dos dados
solicitados ou de uma notificação de sucesso/fracasso. Na figura abaixo, o banco
de dados é basicamente disponível, mesmo que tenha sido particionado como
um resultado de uma falha de rede.
Soft state significa que um banco de dados pode estar em um estado

inconsistente quando os dados são lidos. Assim, os resultados podem mudar se
os mesmos dados forem solicitados novamente. Isso ocorre porque os dados
podem ser atualizados para a consistência, mesmo que nenhum usuário tenha
escrito no banco de dados entre duas leituras. Esta propriedade está
intimamente relacionada com a consistência eventual.
Na figura abaixo, 1. Um usuário atualiza um registro no peer A. 2. Antes

dos outros peers serem atualizados, o usuário B solicita o mesmo registro do
peer C. 3. A base de dados está agora em um estado soft, e dados obsoletos são
devolvido ao usuário B.
16712855225
Consistência eventual é o estado em que leituras feitas por diferentes

clientes, imediatamente após a gravação para o banco de dados, podem não
Big Data e NoSQL
retornar resultados consistentes. O banco de dados só alcança a consistência

uma vez que as mudanças foram propagadas para todos os nós. Embora a base
de dados esteja em processo para atingir o estado de consistência, estaremos
em um estado soft.
Na figura a seguir: 1. Um usuário atualiza um registro. 2. O registro só fica

atualizado no peer A, mas antes que os outros pares possam ser atualizados, o
usuário B solicita o mesmo registro. 3. A base de dados está agora em um
estado soft, dados obsoletos são retornados para o usuário B do Peer C. 4. No
entanto, a consistência é eventualmente atingida, e usuário C recebe o valor
correto.
BASE enfatiza disponibilidade imediata em relação à consistência, em

contraste com o ACID, que garante a consistência imediata à custa de
disponibilidade devido a bloqueio de registo. Esta abordagem soft para a
consistência permite que as bases de dados compatíveis com BASE possam
servir a múltiplos clientes sem qualquer latência embora servindo resultados
inconsistentes. No entanto, as bases de dados compatíveis com BASE não são
úteis para sistemas transacionais onde a falta de consistência é uma
16712855225
preocupação.
4.6. Map-Reduce
Map-reduce é um padrão que permite que operações computacionais sejam
realizadas em um cluster. A tarefa de mapeamento lê dados de um agregado e
os agrupa em partes chave-valor relevante. Mapeamentos somente leem um
único registro de cada vez e podem, assim, ser paralelizados e executados no
nodo que armazena o registro.
A tarefa de redução recebe muitos valores de uma única chave de saída, a

partir da tarefa de mapeamento, e os resume em uma única saída. Cada

Big Data e NoSQL
redutora trabalha sobre o resultado de uma única chave, de modo que podem
ser paralelizados por chave.
MapReduce é complicado de entender no início, por isso vamos tentar

compreendê-lo com um exemplo simples. Vamos supor que temos um arquivo
que tem algumas palavras e o arquivo é dividido em blocos, e temos que contar
o número de ocorrências de uma palavra no arquivo. Iremos passo a passo para
alcançar o resultado usando a funcionalidade MapReduce. Todo o processo é
ilustrado no diagrama a seguir:
Redutoras que tenham o mesmo formato de entrada e saída podem ser

combinadas em pipelines. Isso melhora o paralelismo e reduz a quantidade de
dados a serem transferidos. Operações de MapReduce podem ser compostas em
pipelines, nos quais a saída de uma redução é a entrada do mapeamento de
outra operação.
Se o resultado de uma computação MapReduce for amplamente utilizado,

16712855225
pode ser armazenado como uma visão materializada. Visões materializadas

podem ser atualizadas por meio de operações MapReduce que apenas computem
alterações na visão, em vez de computar novamente tudo desde o início.
5. Hadoop
Hadoop é um framework de código aberto para armazenamento de dados
em grande escala e processamento de dados que seja compatível com o
hardware específico. O framework Hadoop se estabeleceu como uma plataforma
da indústria de fato para soluções de Big Data contemporâneas. Ele pode ser
usado como um motor de ETL ou como um mecanismo de análise para o
processamento de grandes quantidades de dados estruturados,
semiestruturados e não estruturados. A partir de uma perspectiva de análise,
Big Data e NoSQL
Hadoop implementa a estrutura de processamento de MapReduce. A figura

abaixo ilustra algumas das características do Hadoop.
Hadoop é usado amplamente na indústria para processamento de grande

escala, massivamente paralelo e distribuído. Hadoop é altamente tolerante a
falhas e configurável para tantos níveis quanto precisarmos. O que tem um
impacto direto no número de vezes que os dados são armazenados.
Como já abordado, em sistemas de Big Data, a arquitetura gira em torno

de dois componentes principais: a computação distribuída e processamento
paralelo. No Hadoop, a computação distribuída é tratada por meio do HDFS e
processamento paralelo é tratado pelo MapReduce. Em suma, podemos dizer
que o Hadoop é uma combinação de HDFS e MapReduce, como mostrado na
imagem a seguir:
16712855225
Hadoop tem uma série de vantagens, e algumas delas são:
Baixo custo - Funciona em hardware simples (commodity): Hadoop pode

ser executado em hardware simples e não requer um sistema de alto
desempenho, o que pode ajudar no controle de custos e, mesmo assim, alcançar
escalabilidade e desempenho. Adicionar ou remover nós do cluster é simples. O
custo por terabyte é mais baixo para armazenamento e processamento no
Hadoop.

Big Data e NoSQL
Flexibilidade de armazenamento: Hadoop pode armazenar dados em

formato plano (raw) em um ambiente distribuído. Hadoop pode processar os
dados não estruturados e dados semiestruturados melhor que a maioria das
tecnologias disponíveis.
Comunidade de código aberto: Hadoop é de código aberto e apoiado

por muitos contribuintes com uma crescente rede de desenvolvedores em todo o
mundo. Muitas organizações, tais como Yahoo, Facebook, Hortonworks, e outros
têm contribuído imensamente para o progresso do Hadoop e outros subprojetos
relacionados.
Tolerante a falhas: Hadoop é altamente escalável e tolerante a falhas.

Hadoop é confiável em termos de disponibilidade de dados, e até mesmo se
alguns nós falharem, Hadoop pode recuperar os dados. A arquitetura assume
que os nós podem falhar e o sistema deve ser capaz de continuar a processar os
dados.
Análise de dados complexos: Com o surgimento de Big Data, a ciência

de dados também tem crescido aos trancos e barrancos, e nós temos de
algoritmos intensivos complexos e pesados para análise de dados. Hadoop pode
processar tais algoritmos para um conjunto de dados muito grande.
Alguns exemplos onde o Hadoop pode ser utilizado são os seguintes:

pesquisa ou mineração de texto, processamento de registros, sistemas de
recomendação, inteligência de negócios, análise de vídeo e imagem,
reconhecimento de padrões, avaliação de risco e análise de sentimentos.
5.1. O ecossistema do Hadoop

O ecossistema Hadoop é composto por uma série de subprojetos e
podemos configurar esses projetos conforme precisamos em um cluster
Hadoop. Como Hadoop é um software de código aberto, vemos um monte de
contribuições e melhorias do Hadoop feitas por diferentes organizações. Todos
16712855225
os utilitários são absolutamente úteis e ajudam na gestão do sistema de forma

mais eficiente. Para simplificar, vamos entender as diferentes ferramentas,
categorizando-as.
A figura abaixo mostra as camadas e as ferramentas e utilitários dentro

dessas camadas, no ecossistema Hadoop:

Big Data e NoSQL
Sistema de arquivos - No Hadoop, sabemos que os dados são

armazenados em um ambiente de computação distribuída, de modo que os
arquivos estão espalhados por todo o cluster. Devemos ter um sistema de
arquivos eficiente para gerenciar os arquivos no Hadoop. O sistema de arquivos
usado em Hadoop é o HDFS, sigla para Hadoop Distributed File System.
O HDFS é extremamente escalável e tolerante a falhas. Ele é projetado

para processar de forma eficiente de forma paralela em ambiente distribuído no
mesmo hardware simples (commodity). HDFS tem processos daemon em
Hadoop, que gerenciam os dados. Os processos são NameNode, DataNode,
BackupNode, e Checkpoint NameNode.
Programação distribuída - Para aproveitar o poder de um sistema de

arquivos de armazenamento distribuído, Hadoop utiliza programação
distribuída que pode fazer programação paralela massiva. A programação
16712855225
distribuída é o coração de qualquer sistema de Big Data, por isso é

extremamente crítica. A seguir estão os diferentes frameworks que podem ser
usados para a programação distribuída: MapReduce, Hive, Pig e Spark.
A camada de base em Hadoop para a programação distribuída é

MapReduce. Se você observar a figura os outros frameworks rodam em cima
do MapReduce.
Hadoop MapReduce: MapReduce é o coração do sistema Hadoop de

programação distribuída. MapReduce é projetado como processamento paralelo
em um ambiente distribuído. Hadoop MapReduce foi inspirado pelo artigo do
Google MapReduce. Hadoop MapReduce possui uma estrutura de

Big Data e NoSQL
processamento escalável e massivamente paralela, que pode trabalhar com Big

Data e é projetado para ser executado em um cluster de hardware commodity.
Antes do Hadoop 2.x, MapReduce era a única estrutura de

processamento que podia ser usada para a execução. Nas verões mais
recentes, esse utilitário foi ampliado e se criou um wrapper para uma
programação mais fácil que torna o desenvolvimento mais rápido.
Apache Hive: Hive fornece uma infraestrutura de sistemas de data

warehouse para Hadoop, ele cria uma interface de wrapper SQL chamada
HiveQL, em cima do MapReduce. Hive pode ser usado para executar algumas
consultas ad hoc, agregações básicas e processamento de sumarizações com
os dados do Hadoop. HiveQL não é compatível com SQL92. Hive foi
desenvolvido pelo Facebook e foi doado para o Apache. Hive é projetado em
cima do MapReduce, o que significa uma consulta HiveQL vai executar os
trabalhos usando MapReduce para o processamento da consulta. Podemos até
mesmo estender HiveQL usando User Defined Functions (UDF).
Apache Pig: Pig fornece um invólucro baseado em script escrito na

linguagem Pig Latin para processar os dados com uma sintaxe script-like. Pig
foi desenvolvido pelo Yahoo e foi doado para o Apache. Pig, também traduz o
código de script Pig Latin para MapReduce e executa o trabalho. Pig é
normalmente utilizado para analisar conjuntos de dados semiestruturados e
grandes.
Apache Spark: Oferece uma alternativa poderosa para o MapReduce do

Hadoop. Apache Spark é um framework de processamento de dados paralelo
que pode executar programas em até 100 vezes mais rápido do que o Hadoop
MapReduce na memória, ou 10 vezes mais rápido no disco. Spark é utilizado
para o processamento de fluxo em tempo real e análise dos dados.
Bancos de dados NoSQL - Nós já discutimos sobre NoSQL como um

dos sistemas emergentes e amplamente adotados. Dentro ecossistema do
Hadoop, temos um banco de dados NoSQL chamado HBase. HBase é um dos
16712855225
componentes chave que fornece um design flexível e alto volume de operações

de leitura e escritas simultâneas com baixa latência, portanto, é amplamente
adotado.
HBase é inspirado no BigTable do Google. HBase é um mapa ordenado,

que é esparso, consistente, distribuído e multidimensional. HBase é um banco
de dados NoSQL, orientado coluna e chave-valor, que funciona no topo do
HDFS. HBase fornece um lookup mais rápido e também um alto volume de
inserções e atualizações de acesso aleatório em uma escala elevada. O
esquema HBase é muito flexível e realmente variável, onde as colunas podem
ser adicionadas ou removidas em tempo de execução. HBase suporta baixa
latência e operações de gravação e leitura fortemente consistentes. É
apropriado para agregação de alta velocidade. Muitas organizações ou
Big Data e NoSQL
empresas usam HBase, tais como Yahoo, Adobe, Facebook, Twitter,

StumbleUpon, NGData, Infolinks, Trend Micro, e muitos mais.
Ingestão de dados – o gerenciamento de dados em big data é um

aspecto importante e crítico. Temos de importar e exportar dados em grande
escala para fazer o processamento, o que pode se tornar incontrolável no
ambiente de produção. No Hadoop, lidamos com um conjunto diferente de
fontes, tais como batch, streaming, dados em tempo real, e também fontes de
dados que são complexos do ponto de vista de formatos, alguns são
semiestruturadas e não estruturadas. A gestão de tais dados é muito difícil, por
isso temos algumas ferramentas para gerenciamento de dados, como Flume,
Sqoop, e Storm, que são mencionados como segue:
Apache Flume: Apache Flume é uma ferramenta amplamente utilizada

para coleta eficiente, agregação e movimentação de grandes quantidades de
dados de muitas fontes diferentes para um armazenamento de dados
centralizado. Flume é um sistema distribuído, confiável e disponível. Ele
executa bem se uma fonte está fornecendo streaming, por exemplo, arquivos
de log.
Apache Sqoop: Sqoop pode ser usado para gerenciar dados entre
sistemas NoSQL Hadoop e bancos de dados relacionais ou data warehouses
corporativos. Sqoop tem diferentes conectores com os respectivos dados
armazenados e utilizando esses conectores, Sqoop pode importar e exportar
dados em MapReduce, e ainda importar e exportar dados no modo paralelo.
Sqoop também é tolerante a falhas.
Apache Storm: Apache Storm fornece uma solução em tempo real,

escalável e distribuída para streaming de dados. Storm permite atividades
orientadas a dados e automatizadas. Pode ser utilizado com qualquer
linguagem de programação e garante que os fluxos de dados são processados
sem perda de dados. Storm possui tipagem de dados agnóstica, ou seja, ele
processa fluxos de dados de qualquer tipo.
16712855225
Programação de serviços - Programação em um ambiente distribuído

é complexa e cuidados tem que ser tomados, caso contrário, ela pode se tornar
ineficiente. Para desenvolver aplicativos adequadamente distribuídos em
Hadoop, temos algumas ferramentas de programação de serviços que
fornecem utilitários que cuidam do aspecto da gestão de distribuição e de
recursos. As ferramentas que iremos discutir são as seguintes: Apache YARN e
Apache Zookeeper.
Apache YARN - Yet another Resource Negotiator (YARN) tem sido uma
revolução na versão principal do Hadoop versão 2.x. YARN oferece
gerenciamento de recursos e deve ser utilizado como uma plataforma comum
para a integração e gerenciamento de diferentes ferramentas e utilitários em
um cluster Hadoop. YARN é um gerenciador de recursos que foi criado
Big Data e NoSQL
separando as capacidades do motor de processamento e gestão de recursos do

MapReduce. Ele também fornece a plataforma para outros fins, tais como,
Storm, Spark, e assim por diante.
YARN melhorou suas capacidades, agora ele também pode ser ajustado
para streaming e análise em tempo real, o que é um benefício enorme e uma
necessidade em alguns cenários. YARN também é compatível com vários
aplicativos MapReduce existentes. Alguns aplicativos alimentados por YARN são
os seguintes: Apache Hadoop MapReduce, Apache Spark, Apache Strom,
Apache Tez e Apache S4
Apache Zookeeper - ZooKeeper é um distribuído, de código aberto e

usado para a coordenação de serviços para aplicações distribuídas. ZooKeeper
expõe um conjunto simples de primitivas que aplicações distribuídas podem
usar para sincronização, configuração, manutenção, agrupamento e nomeação
de recursos para a realização da coordenação, alta disponibilidade e
sincronização. ZooKeeper é executado em Java e tem ligações (bindings) para
Java e C. HBase, Solr, Kata, Neo4j, e assim por diante, são algumas
ferramentas que utilizam Zookeeper para coordenar as atividades.
Agendamento - O sistema Hadoop pode ter vários jobs e estes têm de

ser agendados muitas vezes. O agendamento de trabalhos do Hadoop é
complexo e difícil de estruturar, gerenciar e monitorar. Podemos usar um
sistema como Oozie para coordenar e monitorar os trabalhos do Hadoop de
forma eficiente.
Apache Oozie: Oozie é um sistema de processamento de fluxo de

trabalho e coordenação de serviços que permite que os usuários gerenciem
múltiplas tarefas, como uma cadeia de trabalhos escritos em MapReduce, Pig, e
Hive, também programas Java e scripts shell, e permite ligá-los uns aos outros.
Oozie é um serviço extensível, escalável e com reconhecimento de dados.
Oozie pode ser usado para definir regras, começando e terminando um fluxo de
trabalho e também pode detectar a conclusão de tarefas.
16712855225
Análise de dados e aprendizagem de máquina - Em Hadoop, a

análise dos dados é uma área de interesse chave. Hadoop é uma poderosa
ferramenta para processar programas complexos e algoritmos que visam
melhorar o processo de negócios. A análise de dados pode identificar insights e
ajudar a otimizar o processo em relação aos competidores. Devido à natureza
de processamento poderosa do Hadoop, o aprendizado de máquina tem estado
em foco e vários algoritmos e técnicas têm sido adaptados para Hadoop. As
técnicas de aprendizado de máquina também são usadas em análises
preditivas. A análise de dados e a aprendizagem de máquina são necessárias
para organizações ficarem à frente na competição. Para alguns pesquisadores,
especialmente em ciências da vida, usam-se esses algoritmos para processar

Big Data e NoSQL
genes e padrões de registros médicos com o objetivo de gerar insights e

detalhes importantes e úteis que são muito necessários na área médica.
Isso também é necessário para pesquisadores no campo da robótica

para fornecer inteligência a máquinas para a execução e otimização de uma
tarefa. RHadoop é uma linguagem estatística de análise de dados integrada
com o Hadoop. Mahout é uma API de aprendizagem de máquina de código
aberto usada pelo Hadoop.
Apache Mahout: Mahout é uma API escalável de aprendizagem de

máquina, que tem uma variedade de bibliotecas de aprendizado de máquina
implementada. Mahout é um projeto isolado que pode ser utilizado como uma
biblioteca de aprendizagem de máquina pura, mas o poder do Mahout aumenta
quando ele é integrado com o Hadoop. Alguns dos algoritmos que são
popularmente utilizados no Mahout são: Recomendação, Clustering e
Classificação.
Administração de sistema - Implantar, provisionar, gerenciar e

monitorar um cluster Hadoop requer conhecimento de script e normalmente
leva uma boa quantidade de tempo e esforço manual, mas é repetitivo. Para a
realização de tais atividades em Hadoop, podemos usar ferramentas como
Ambari.
Apache Ambari - Ambari pode ser usado por desenvolvedores de

aplicativos e integradores de sistemas para gerenciar a maioria das atividades
de administração de um cluster Hadoop. Ambari é um framework open source
do ecossistema Hadoop, que pode ser usado para a instalação,
provisionamento, implantação, gerenciamento e monitoramento de um cluster
Hadoop. Seus principais objetivos são esconder a complexidade do
gerenciamento de um cluster Hadoop e fornecer uma interface web fácil e
intuitiva. Uma característica fundamental do Ambari é que ele fornece APIs
RESTful, que podem ser usadas para integração com outras ferramentas
externas para uma melhor gestão.
16712855225
Finalmente terminamos nossos comentários sobre algumas dos possíveis

frameworks e tecnologias relacionadas ao Hadoop. A figura que apresentamos
no início mostra a integração entre esses componentes de forma gráfica.
Esperamos que você tenha gostado.
A seguir apresentaremos nossa tradicional lista de questões comentadas!

Elas fazem parte da aula e devem ajudar você na fixação do conteúdo.

Big Data e NoSQL
Questões comentadas
Chegamos a nossa tradicional lista de questões comentadas.
1. Ano: 2015 Banca: CESPE Órgão: TJDFT Cargo: Suporte em

Tecnologia da Informação – Questões 92 e 93
A respeito de tipos de bancos de dados, julgue os itens que se seguem.

92 A capacidade de estender tipos de dados básicos é uma das características
dos bancos de dados objeto relacional.
93 Sistemas de bancos de dados classificados como NoSQL permitem a inserção
de dados sem que haja um esquema predefinido.
Comentários: Essa questão trata na alternativa 92 de banco de dados
relacionais. A ideia descrita na alternativa trata dos itens conhecidos como user
defined type – UDT. Eles aparecem dentro do padrão SQL e permitem que novos
tipos possam ser estendidos dos tipos básicos.
A alternativa 93, por sua vez, refere-se ao assunto presente nesta aula. Vejam
que a existência de esquema bem definido não é uma obrigatoriedade dentro do
contexto de bancos de dados NoSQL. Essa propriedade é conhecida como
schema free ou livre de esquema.
Pelo exposto acima, as duas alternativas estão corretas.
Gabarito: C C
2. Ano: 2016 Banca: FGV Órgão: IBGE Cargo: WEB MOBILE Questão: 41
Considere as seguintes características de um projeto de banco de dados.

I. O modelo de dados é conhecido a priori e é estável;
16712855225
II. A integridade dos dados deve ser rigorosamente mantida;

III. Velocidade e escalabilidade são preponderantes.
Dessas características, o emprego de bancos de dados NoSQL é favorecido
somente por:
(A) I;
(B) I e II;
(C) II;
(D) II e III;
(E) III.
Comentário: Veja que a questão trata das propriedades ou características de
um projeto de banco de dados NoSQL. Sabemos que bancos de dados deste tipo

Big Data e NoSQL
substituem a sigla ACID (atomicidade, consistência, isolamento e durabilidade)

que está relacionado com transações pela sigla BASE que está relacionada com
os conceitos de BA – (Basically Available) disponibilidade é prioridade, S – (Soft-
State) – Não precisa ser consistente o tempo todo e E – (Eventually Consistent)
– Consistente em momento indeterminado. Outro ponto importante é a relação
de NoSQL com o modelo de dados, geralmente o banco é considerado schema
free, ou seja, livre de esquema ou de um modelo pré-determinado a priori.
Partindo desta exposição básica sobre NoSQL podemos analisar as alternativas I,
II e III. Vejam que as duas primeiras são definições associadas a banco de
dados relacionais ou transacionais. A alternativa III trata de outro aspecto que
não vimos ainda, mas que também está relacionada ao conceito de NoSQL e Big
Data. NoSQL é uma tecnologia que trouxe o foco de banco de dados para
performance e escalabilidade. A pergunta é como analisar uma grande
quantidade de dados.
Gabarito: E
3. Ano: 2016 Banca: ESAF Órgão: ANAC Cargo: Analista de TI -

QUESTÃO 62
Big Data é:
a) volume + variedade + agilidade + efetividade, tudo agregando + valor +
atualidade.
b) volume + oportunidade + segurança + veracidade, tudo agregando + valor.
c) dimensão + variedade + otimização + veracidade, tudo agregando +
agilidade.
d) volume + variedade + velocidade + veracidade, tudo agregando + valor.
e) volume + disponibilidade + velocidade + portabilidade, tudo requerendo -
valor.
Comentário: Embora o termo "big data" seja relativamente novo, o ato de
recolher e armazenar grandes quantidades de informações para eventual análise
16712855225
de dados é bem antigo. O conceito ganhou força no início dos anos 2000,
quando um analista famoso deste setor, Doug Laney, articulou a definição de big
data como os três Vs:
Volume. Organizações coletam dados de uma grande variedade de fontes,
incluindo transações comerciais, redes sociais e informações de sensores ou
dados transmitidos de máquina a máquina. No passado, armazenar tamanha
quantidade de informações teria sido um problema – mas novas tecnologias
(como o Hadoop) têm aliviado a carga.
Velocidade. Os dados fluem em uma velocidade sem precedentes e devem ser
tratados em tempo hábil. Tags de RFID, sensores, celulares e contadores
inteligentes estão impulsionado a necessidade de lidar com imensas quantidades
de dados em tempo real, ou quase real.

Big Data e NoSQL
Variedade. Os dados são gerados em todos os tipos de formatos - de dados

estruturados, dados numéricos em bancos de dados tradicionais, até
documentos de texto não estruturados, e-mail, vídeo, áudio, dados de cotações
da bolsa e transações financeiras.
Outros Vs foram adicionados ao longo dos anos:
Veracidade. O quarto V do conceito está ligado à veracidade do conteúdo. Nem
todos os dados gerados possuem consistência dentro do contexto. É preciso
destacar o que é rico e correto em conteúdo no meio de tanta informação. Ao
garantir essa separação, que é possível fazer a partir do Big Data, o que sobra
são conhecimentos importantes para compreender melhor a entidade analisada
ou o negócio em questão.
Valor. Para garantir que o trabalho dos outros Vs traga retorno, é preciso gerar
valor para os resultados que retornam do Big Data. Assim, aparece o último V do
conceito.
Juntando todos os conceitos acima, chegamos a nossa resposta na alternativa D.
Gabarito: D
4. Ano: 2016 Banca: ESAF Órgão: ANAC Cargo: Analista de TI -

QUESTÃO 70
Para o processamento de grandes massas de dados, no contexto de Big Data, é

muito utilizada uma plataforma de software em Java, de computação distribuída,
voltada para clusters, inspirada no MapReduce e no GoogleFS. Esta plataforma é
o(a)
a) Yam Common.
b) GoogleCrush.
c) EMRx.
d) Hadoop.
e) MapFix 16712855225
Comentário: Questão inspirada na WIKIPEDIA:

Hadoop é uma plataforma de software em Java de computação distribuída
voltada para clusters e processamento de grandes massas de dados. Foi
inspirada no MapReduce e no GoogleFS (GFS). Trata-se de um projeto da
Apache de alto nível, que vem sendo construído por uma comunidade de
colaboradores utilizando em sua maior parte a linguagem de programação Java,
com algum código nativo em C e alguns utilitários de linha de comando escrito
utilizando scripts shell. Assim podemos marcar nossa resposta na alternativa D.
Gabarito: D

Big Data e NoSQL
5. ANO: 2015 BANCA: FCC ÓRGÃO: TRE-RR PROVA: ANALISTA

JUDICIÁRIO - ANÁLISE DE SISTEMAS
Os dados de sistemas OLAP se baseiam nas informações contidas nos diversos

softwares utilizados pela empresa (ERPs, planilhas, arquivos texto, arquivos XML
etc.). Estes sistemas possuem uma camada onde estão os dados originais e
outra camada onde estão os dados tratados (um gigantesco repositório de dados
sobre assuntos diversos preparados para serem consultados por um sistema
OLAP), que chamamos de
A Data Mining.
B Online Transactional Database.
C Data Mart.
D Datawarehouse.
E Big Data.
Comentário: Essa questão aparece aqui apenas para verificar se você ainda
lembra-se do conceito de Data Warehouse.
Gabarito: D
6. ANO: 2015 BANCA: FGV ÓRGÃO: TJ-SC PROVA: ANALISTA

JUDICIÁRIO - ANALISTA DE SISTEMAS
Os termos Business Intelligence (BI) e Big Data confundem-se em certos

aspectos. Uma conhecida abordagem para identificação dos pontos críticos de
cada paradigma é conhecida como 3V, e destaca:
A variedade, visualização, volume;

16712855225
B velocidade, virtualização, volume;
C variedade, velocidade, volume;
D virtualização, visualização, volume;
E variedade, visualização, virtualização.
Comentário: Questão interessante! Trata dos 3 Vs que definem o primeiro

conceito de Big Data. Sabemos que se trata da Variedade, Velocidade e Volume.
O primeiro faz referência aos diferentes tipos de dados ou informações que deve
ser processados. O segundo se preocupa com o tempo para o processamento e
armazenamento de forma consistente e acessível das informações geradas. Por
fim, o volume consiste na percepção de que a quantidade dados aumenta a cada
dia em grandes proporções.

Big Data e NoSQL
Gabarito: C
7. ANO: 2015 BANCA: FCC ÓRGÃO: TRT - 3ª REGIÃO (MG) PROVA:

TÉCNICO JUDICIÁRIO - TECNOLOGIA DA INFORMAÇÃO
Um técnico de TI precisa utilizar um subconjunto de dados de um Data

Warehouse direcionado à área administrativa de um Tribunal. Esses dados serão
armazenados em um banco de dado modelado multidimensionalmente, que será
criado capturando-se dados diretamente de sistemas transacionais, buscando as
informações relevantes para os processos de negócio da área administrativa.
Esse banco de dados será um
A Big Data.
B Data Mart.
C OLAP.
D MOLAP.
E Data Mining.
Comentário: Mais uma questão para que você possa relembrar de um conceito
visto anteriormente, em outra aula. Desta vez trata-se do conceito de Data Mart.
Gabarito: B
8. ANO: 2014 BANCA: CESPE ÓRGÃO: TJ-SE PROVA: ANALISTA

JUDICIÁRIO - BANCO DE DADOS
Julgue os itens que se seguem, no que se refere a Big Data.
[1] O processamento de consultas ad hoc em Big Data, devido às características

de armazenamento dos dados, utiliza técnicas semelhantes àquelas empregadas
16712855225
em consultas do mesmo tipo em bancos de dados tradicionais.
Comentário: O processamento de consultas ad hoc no contexto de big data traz

desafios diferentes daqueles incorridos ao realizar consultas ad hoc em dados
estruturados pelo fato de as fontes e formatos dos dados não serem fixos e
exigirem mecanismos diferentes para recuperá-los e processá-los.
Embora as consultas ad hoc simples possam ser resolvidas pelos provedores de

big data, na maioria dos casos, elas são complexas porque os dados, algoritmos,
formatos e resoluções da entidade devem ser descobertos dinamicamente. O
conhecimento dos cientistas de dados e dos usuários corporativos é necessário
para definir a análise exigida para as seguintes tarefas:
 Identificar e descobrir os cálculos e algoritmos

Big Data e NoSQL
 Identificar e descobrir as fontes de dados
 Definir os formatos necessários que podem ser consumidos pelos cálculos
 Executar os cálculos nos dados paralelamente
Gabarito: E

Em soluções Big Data, a análise dos dados comumente precisa ser precedida de
uma transformação de dados não estruturados em dados estruturados.
Comentário: As soluções de big data são, em sua maioria, dominadas por

sistemas Hadoop e tecnologias baseadas em MapReduce, que são soluções
simples de instalar para processamento e armazenamento distribuídos. No
entanto, a extração de dados a partir de dados não estruturados, como imagens,
áudio, vídeo, feeds binários ou até mesmo texto, é uma tarefa complexa e
precisa de técnicas como aprendizado de máquina e processamento de idioma
natural, etc. O outro grande desafio é como verificar a precisão e a exatidão do
resultado de tais técnicas e algoritmos.
Para executar a análise em quaisquer dados, eles devem estar em algum tipo de
formato estruturado. Os dados não estruturados acessados de várias fontes
podem ser armazenados como estão e, em seguida, transformados em dados
estruturados (por exemplo, JSON) e novamente armazenados nos sistemas de
armazenamento de big data. O texto não estruturado pode ser convertido em
dados estruturados ou semiestruturados. Da mesma forma, os dados de
imagem, áudio e vídeo precisam ser convertidos nos formatos que podem ser
usados para análise. Além disso, a precisão e exatidão da analítica avançada que
usa algoritmos preditivos e estatísticos dependem da quantidade de dados e
algoritmos usados para treinar os modelos.
16712855225
Gabarito: C

[1] Ao utilizar armazenamento dos dados em nuvem, a localização do

processamento de aplicações Big Data não influenciará os custos e o tempo de
resposta, uma vez que os dados são acessíveis a partir de qualquer lugar.

Big Data e NoSQL
Comentário: Muito embora haja uma abstração quanto ao local do

processamento, afinal, se contrata um serviço e pouco importa como e onde ele
será prestado, essa escolha tem consequências.
Muitos provedores de serviço na nuvem, como a Amazon, possuem tarifas

diferenciadas com relação à localização de cada servidor. Cada país tem seus
custos e suas especificidades.
Além disso, quanto mais longe o servidor estiver do interessado, maior será o
tempo de espera entre a requisição e a resposta.
Gabarito: E
11. ANO: 2015 BANCA: FGV ÓRGÃO: TJ-BA PROVA: TÉCNICO DO

JUDICIÁRIO - TECNOLOGIA DA INFORMAÇÃO
Analise as afirmativas a respeito da classe de gerenciadores de bancos de dados,

surgida em anos recentes, conhecida como NoSQL.
I. Mesmo sem suportar tabelas relacionais, baseiam-se em esquemas de dados

previamente definidos;
II. Suas estruturas não permitem o uso de linguagens do tipo do SQL para
recuperação de dados;
III. Garantem operações com as propriedades conhecidas pela sigla ACID;
IV. Privilegiam a rapidez de acesso e a disponibilidade dos dados em detrimento

das regras de consistência das transações.
O número de afirmativas corretas é:
A uma;
B duas;
C três; 16712855225
D quatro;
E cinco.
Comentário: Se voltarmos a parte da nossa aula teórica que trata de NoSQL

veremos que a única alternativa correta é a presente na assertiva IV.
Gabarito: A
12. ANO: 2015 BANCA: CESPE ÓRGÃO: TCU PROVA: AUDITOR FEDERAL
DE CONTROLE EXTERNO - TECNOLOGIA DA INFORMAÇÃO

Big Data e NoSQL
Julgue os itens subsecutivos, a respeito de sistemas de bancos de dados.
Como forma de permitir as buscas em documentos semiestruturados, um banco

de dados NoSQL do tipo orientado a documentos armazena objetos indexados
por chaves utilizando tabelas de hash distribuída.
Comentário: Quando tratamos de bases de dados NoSQL podemos classifica-las

em quatro diferentes tipos, são eles:
Chave/valor (Key/Value): conhecidos como tabelas de hash distribuídas.

Armazenam objetos indexados por chaves, e facilita a busca por esses objetos a
partir de suas chaves.
Orientados a Documentos: os documentos dos bancos são coleções de

atributos e valores onde um atributo pode ser multivalorado. Em geral, os
bancos de dados orientados a documento não possuem esquema, ou seja, os
documentos armazenados não precisam possuir estrutura em comum. Essa
característica faz deles boas opções para o armazenamento de dados
semiestruturados.
Colunar: Bancos relacionais normalmente guardam os registros das tabelas

contiguamente no disco. Por exemplo, caso se queira guardar id, nome e
endereço de usuários em um banco de dados relacional, os registros seriam:
Id1, Nome1, Endereço1;
Id2, Nome2, Endereço2.
Essa estrutura torna a escrita muito rápida, pois todos os dados de um registro
são colocados no disco com uma única escrita no banco. Também é eficiente
caso se queira ler registros inteiros. Mas para situações onde se quer ler
algumas poucas colunas de muitos registros, essa estrutura é pouco eficiente,
pois muitos blocos do disco terão de ser lidos.
Para esses casos onde se quer otimizar a leitura de dados estruturados, bancos
de dados de famílias de colunas são mais interessantes, pois eles guardam os
dados contiguamente por coluna.
O exemplo anterior em um banco de dados dessa categoria ficaria:

16712855225
Id1, Id2; Nome1, Nome2; Endereço1, Endereço2.
Os bancos de dados de famílias de colunas são mais interessantes para

processamento analítico online (OLAP). Bigtable é uma implementação da
Google dessa categoria de bancos de dados.
Orientado a Grafos: diferente de outros bancos de dados NoSQL, esse está

diretamente relacionado a um modelo de dados estabelecido, o modelo de
grafos. A ideia desse modelo é representar os dados e / ou o esquema dos
dados como grafos dirigidos, ou como estruturas que generalizem a noção de
grafos. O modelo de grafos é aplicável quando “informações sobre a
interconectividade ou a topologia dos dados são mais importantes, ou tão
importante quanto os dados propriamente ditos”. Possui três componentes
básicos: os nós (são os vértices do grafo), os relacionamentos (são as arestas) e
as propriedades (ou atributos) dos nós e relacionamentos.

Big Data e NoSQL
Vejam que a afirmativa do CESPE confunde os conceitos de orientado a

documentos com o conceito de chave valor. Quanto nós tratamos de tabelas
hash distribuídas está associada ao tipo chave-valor e não ao conceito de
orientado a documentos como está dito na questão. Sendo, portanto,
alternativa errada.
Gabarito: E

Acerca de bancos de dados semiestruturados e bancos de dados NOSQL, julgue

os itens subsecutivos.
Bancos de dados NOSQL orientados a documentos são apropriados para o

armazenamento de dados semiestruturados.
Comentário: Exatamente, neles é possível armazenamento de documentos que

embora tenham uma estrutura básica, eles, geralmente não são definidos por
nenhum modelo ou schema. Podemos, então, encontrar propriedades dentro dos
documentos, mas não existe uma obrigatoriedade sobre a existência delas.
Gabarito: C


Para garantir a eficiência das consultas a bancos de dados semiestruturados, é

fundamental a adoção de técnica de indexação que leve em consideração, além
das informações, as propriedades estruturais dos dados.
16712855225
Comentário: Para viabilizar a indexação de dados semiestruturados é preciso

conhecimento das propriedades dos objetos de dados.
Gabarito: C



Big Data e NoSQL
Devido à escalabilidade esperada para os bancos de dados NOSQL, a

implementação desses bancos utiliza modelos de armazenamento de dados
totalmente distintos dos utilizados em sistemas relacionais.
Comentário: Nem todos os modelos de armazenamentos são totalmente

distintos dos sistemas relacionais. Se pensarmos no modelo de armazenamento
colunar ele é semelhante a uma tabela, mas guardam os dados das colunas
contiguamente no disco.
NoSQL são diferentes sistemas de armazenamento que vieram para suprir

necessidades em demandas onde os bancos de dados tradicionais (relacionais)
são ineficazes. Muitas dessas bases apresentam características muito
interessantes como alta performance, escalabilidade, replicação, suporte à dados
estruturados e sub colunas.
O NoSQL surgiu da necessidade de uma performance superior e de uma alta

escalabilidade. Os atuais bancos de dados relacionais são muito restritos a isso,
sendo necessária a distribuição vertical de servidores, ou seja, quanto mais
dados, mais memória e mais disco um servidor precisa. O NoSQL tem uma
grande facilidade na distribuição horizontal, ou seja, mais dados, mais
servidores, não necessariamente de alta performance. Um grande utilizador
desse conceito é o Google, que usa computadores de pequeno e médio porte
para a distribuição dos dados; essa forma de utilização é muito mais eficiente e
econômica. Além disso, os bancos de dados NoSQL são muito tolerantes a erros.
No caso dos bancos NoSQL, toda a informação necessária estará agrupada no

mesmo registro, ou seja, em vez de você ter o relacionamento entre várias
tabelas para formar uma informação, ela estará em sua totalidade no mesmo
registro.
Gabarito: E
16. ANO: 2013 BANCA: CESPE ÓRGÃO: CNJ PROVA: ANALISTA

No que se refere ao desenvolvimento web de alto desempenho, julgue os itens

16712855225
subsequentes.
Uma característica de bancos de dados NoSQL é o suporte à replicação de

dados. Entre as abordagens utilizadas para replicação, inclui-se a mestre-
escravo.
Comentário: São dois tipos de replicação: mestre-escravo e ponto a ponto. A

replicação mestre-escravo torna um nodo a cópia oficial, a qual lida com
gravações, enquanto os escravos sincronizam-se com o mestre e podem lidar
com as leituras. A replicação ponto a ponto permite gravações em qualquer
nodo; os nodos são coordenados para sincronizar suas cópias de dados. A
replicação mestre-escravo reduz a chance de conflitos de atualização, mas a
ponto a ponto evita carregar todas as gravações em um único ponto de falha.
Gabarito: C

Big Data e NoSQL


subsequentes.
A escalabilidade dos bancos de dados NoSQL é garantida pela ausência de um

esquema (scheme free).
Comentário: A escalabilidade é garantida através da característica nativa de

clusterização do banco de dados.
Gabarito: E


subsequentes.
Apesar de implementarem tecnologias distintas, todos os bancos de dados

NoSQL apresentam em comum a implementação da tecnologia chave-valor.
Comentário: Sabemos que são cada solução NoSQL possui um modelo de

armazenamento diferente, os quais dividimos em quatro categorias amplamente
utilizadas no ecossistema NoSQL: chave-valor, documento, família de
colunas ou colunar, e grafos.
Gabarito: E
16712855225
19. BANCA:CESPE - ANO: 2016 - CONCURSO:FUNPRESP – CARGO:

ESPECIALISTA - ÁREA: TECNOLOGIA DA INFORMAÇÃO (TI)
Com relação à forma como os dados são armazenados e manipulados no

desenvolvimento de aplicações, julgue os itens a seguir.
69 Em um banco de dados NoSQL do tipo grafo, cada arco é definido por um

identificador único e expresso como um par chave/valor.
Comentários: Abaixo analisaremos cada uma das alternativas.
69. A alternativa vai exigir conhecimento sobre os modelos de armazenamento

utilizados por bancos de dados NoSQL. Quando tratamos de bases de dados
NoSQL podemos classifica-las em quatro diferentes tipos, dois deles são citados
na questão:

Big Data e NoSQL
Chave/valor (Key/Value): conhecidos como tabelas de hash distribuídas.

Armazenam objetos indexados por chaves, e facilita a busca por esses objetos a
partir de suas chaves.
Orientado a Grafos: diferente de outros bancos de dados NoSQL, esse está

diretamente relacionado a um modelo de dados estabelecido, o modelo de
grafos. A ideia desse modelo é representar os dados e/ou o esquema dos dados
como grafos dirigidos, ou como estruturas que generalizem a noção de grafos.O
modelo de grafos é aplicável quando “informações sobre a interconectividade ou
a topologia dos dados são mais importantes, ou tão importante quanto os dados
propriamente ditos”. Possui três componentes básicos: os nós (são os vértices
do grafo), os relacionamentos (são as arestas) e as propriedades (ou atributos)
dos nós e relacionamentos.
Vejam que a questão mistura os dois conceitos o que torna a alternativa

incorreta.
Gabarito: E
20. BANCA:CESPE - ANO: 2016 - CONCURSO:FUNPRESP – CARGO:

ESPECIALISTA - ÁREA: TECNOLOGIA DA INFORMAÇÃO (TI)
A respeito dos fundamentos e das principais tecnologias relacionadas à

computação em nuvem, julgue os próximos itens.
90 Hadoop e Elasticsearch são exemplos de tecnologias que permitem a

computação em nuvem.
91 A computação em nuvem permite o processamento de dados de maneira

distribuída em máquinas com diferentes arquiteturas físicas.
Comentário: Vamos comentar cada uma das alternativas acima. Começando

pela definição de Hadoop e ElasticSearch.
O Hadoop é uma implementação de código aberto do paradigma de

16712855225
programação Map-Reduce. Map-Reduce é um paradigma introduzido pelo Google

para processar e analisar grandes conjuntos de dados. Os programas que são
desenvolvidos nesse paradigma realizam o processamento paralelo de conjuntos
de dados e podem, portanto, ser executados em diferentes servidores sem
muito esforço. A razão para a escalabilidade desse paradigma é a natureza
intrinsecamente distribuída do funcionamento da solução. Uma grande tarefa é
dividida em várias pequenas tarefas que são então executadas em paralelo em
máquinas diferentes e então combinadas para chegar à solução. Os exemplos de
uso do Hadoop são analisar padrões de usuários em sites de e-commerce e
sugerir novos produtos para os mesmos.
ElasticSearch é uma engine de busca open-source, amplamente distribuível,

facilmente escalável para uso empresarial ou pessoal. Acessível através de uma
API extensa e bem elaborada, o ElasticSearch pode acionar pesquisas
extremamente rápidas que suportam diversos tipos de integração.

Big Data e NoSQL
90 Também conhecida no Brasil como computação nas nuvens ou computação

em nuvem, a cloud computing se refere, essencialmente, à noção de utilizarmos,
em qualquer lugar e independente de plataforma, as mais variadas aplicações
por meio da internet com a mesma facilidade de tê-las instaladas em
computadores locais. Dentro deste contexto, tanto Hadoop quanto
ElastichSearch são ferramentas que contribuem para a infraestrutura para
provimento de serviços de computação na nuvem. Sendo assim alternativa
encontra-se correta.
91. O uso das ferramentas citadas no item anterior vai permitir um grande
paralelismo no processamento por meio da distribuição entre os diferentes nós
ou hosts do sistema. Mais uma alternativa correta.
Gabarito: C C
16712855225

Big Data e NoSQL
Considerações finais
Chegamos, pois, ao final da nossa aula! Essa aula tratou de um tema bem
específico: Big Data, incluindo aspectos sobre NoSQL e Hadoop. Esperamos que
as informações contidas nesta aula seja o suficiente para que você consiga
acertar qualquer questão sobre o assunto no momento da prova.
Desejo a todos bons estudos!
Thiago Cavalcanti
Referência
Fiz uma lista com as referências caso você queria se aprofundar um pouco
mais no assunto.
i. Learning Hadoop 2 By: Gabriele Modena; Garry Turkington
ii. Hadoop Essentials By: Swizec Teller
16712855225


Aula 03 - Big Data, NoSQL e Hadoop

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Aula 03 - Big Data, NoSQL e Hadoop

Загружено:

Авторское право:

Доступные форматы

Business Intelligence para Concursos - Curso Regular

AULA xx: Big Data e Banco de dados NoSQL

Nesta aula nosso intuito é desenvolver um pouco seu conhecimento sobre

distribuído como o Hadoop. Vem comigo conhecer um pouco deste universo

Nossa ideia é começar o assunto apresentando, de forma sucinta, os

Prof. Thiago Rodrigues Cavalcanti

utilizou de três termos, conhecidos como os 3Vs: Volume, Velocidade e

 Volume. Existem muitos fatores que contribuem para o aumento do

 Velocidade. De acordo com o Laney, velocidade significa o

 Variedade. Os dados de hoje vêm em todos os tipos de formatos.

Prof. Thiago Rodrigues Cavalcanti

Vejam a figura apresentada acima. Ela representa uma indicação do

 Veracidade. A veracidade foi um termo cunhado pela IBM, considerado o

É necessário avaliar as inconsistências, incompletudes, ambiguidades,

 Visibilidade. É a relevância dos dados. A organização está ciente de

 Valor. A Oracle introduziu valor como um atributo na definição de Big

 Variabilidade (e complexidade). A SAS apresentou variabilidade (e

Podemos agora apresentar uma definição de Big Data da IBM. É um termo

Prof. Thiago Rodrigues Cavalcanti

precedentes no número de informações geradas. As dificuldades em

2. Falácias sobre Big Data

Falácia 01 - Big Data não pode prever o futuro

Big data e todas as suas ferramentas de análise, comentários, experiências

resultados semelhantes ocorreriam como resultado. Mas não podemos prever

Falácia 02 - Big Data não pode substituir seus valores ou os da sua

Big Data é pobre para substituir valores ou aqueles costumes e padrões

Prof. Thiago Rodrigues Cavalcanti

Os dados podem descrever todos os tipos de cenários, tanto os próprios

Falácia 03 - Big Data não pode resolver problemas não

Eis o velho ditado: Quando você só tem um martelo, tudo parece um

Como mencionado anteriormente, os dados podem apresentar mais e

Por quê? É quase impossível de quantificar o comportamento de um

3. Aplicações de Big Data

Prof. Thiago Rodrigues Cavalcanti

O aproveitamento de Big Data no setor público tem um potencial

A quantidade de dados em nosso mundo está explodindo, e a análise de

O crescente volume e detalhamento das informações capturadas por

A minha experiência pessoal no estudo de Big Data é que quando

Prof. Thiago Rodrigues Cavalcanti

Embora haja diferenças de um banco de dados relacional para outro os

Banco de dados relacionais fornecem muitas vantagens, mas não são, de

Para os desenvolvedores de aplicativos, a maior frustração tem sido a

Ao longo dos anos, tornou-se mais fácil lidar com a incompatibilidade de

mapeamento bastante conhecidos. Embora a questão do mapeamento ainda

Outro ponto relevante dentro do contexto apareceu devido ao crescimento

Prof. Thiago Rodrigues Cavalcanti

A alternativa seria utilizar mais máquinas menores em um cluster. Um

Duas empresas em particular – Google e Amazon – têm sido influentes no

Não é surpresa o fato de que essas empresas tinham em mente acabar

Os exemplos do BigTable e do Dynamo inspirou a criação de projetos, que

Johan estava interessado em descobrir mais sobre esses novos bancos de

A chamada original, NoSQL Meetup, para a reunião pedia por “bancos de

Prof. Thiago Rodrigues Cavalcanti

As características comuns dos bancos de dados NoSQl são: não utilizam

O resultado mais importante do surgimento do NoSQL é a persistência

4.2. Modelos de dados

O modelo de dados dominante nas últimas décadas é o modelo relacional,

Uma das mudanças mais evidentes trazidas pelo NoSQL é o afastamento do

chave-valor, documento, família de colunas ou colunar, e grafos. Dessas

A orientação agregada reconhece que você, frequentemente, deseja

Um agregado é um conjunto de objetos relacionados que desejamos tratar

Prof. Thiago Rodrigues Cavalcanti

gerenciamento de consistência. Normalmente, preferimos atualizar agregados