Padrões de Design para MapReduce

Nokia Institute of Technology

Padrões de Design para MapReduce

TDC 2013 – São Paulo

Your natural partner to develop innovative solutions

Felipe Ferreira

Karla Okada Gomes

Wellington Chevreuil

Agenda

• Introdução

• Padrões de Sumarização

• Padrões de Filtragem

• Padrões de Organização de Dados

• Padrões de Join

• Padrões de Input e Output


Introdução

MapReduce Overview


Introdução

MapReduce Design Patterns

1. Sumarização: sumarizando e agrupando dados 2. Filtragem: ter a visão de subconjuntos de dados 3. Organização de Dados: reorganizar dados para

trabalhar com outros sistemas, ou para facilitar a análise de MapReduce

4. Join: analizar diferentes data sets agrupados para descobrir relacionamentos

5. Metapattern: unificar vários padrões para solucionar problemas multi-stage ou para realizar diversas análise no mesmo job

6. Input e Output: customizar a maneira como você usa Hadoop para carregar e armazenar dados

• 23 Padrões no total


Padrões de Sumarização

• Grandes volumes de dados são produzidos diariamente

• Proporcionar uma visão resumida de alto nível de grandes data sets.

• Possibilitar análises sobre os dados, identificar padrões

• Exemplos de Padrões:

• Sumarização Numérica

• Sumarização de Índice Invertido

• Contadores


Padrões de Sumarização Sumarização Numérica

• Objetivo - Agrupar registros por um key field e calcular uma agregação numérica por grupo

• Motivação - Data sets muito grandes para análise mais simples (Ex: terabytes de logs de websites)

• Aplicabilidade – Dados numéricos ou contagem. Os dados podem ser agrupados por campos específicos

• Consequências – Arquivos contendo um único registro (key, vlrs agregados) por grupo

• Ex: - word/record count, min/max/count, average, median, standard deviation


Padrões de Sumarização Sumarização Numérica

• Performance

• Combiners podem ser usados para melhorar a execução

• Distorções nos reducers: muito mais k/v com uma chave específica que outras keys. Um reducer pode ficar mais sobrecarregado que outros


Padrões de Sumarização Sum. Numérica – Código Exemplo

• Caso de Uso: Dada uma lista de comentários de usuários de um blog, determinar o primeiro(Min) e último comentário(Max) e o número total de comentários (Count) por usuário


Padrões de Sumarização Índice Invertido

• Objetivo - Gerar Índice de um data set

• Motivação – Indexar grandes data sets em keywords facilita a busca por valores específicos

• Aplicabilidade – Necessidade de consultas rápidas.

• Consequências – Arquivo contendo (keywords -> [ids] )


Padrões de Sumarização Índice Invertido

• Performance

• Cardinalidade de index keys aumenta o número de reducers

• Nro de conteúdo p/ a key “de” pode ser muito maior que os demais

• Um partitioner customizado pode ajudar no load balance


Padrões de Sumarização Índice Invertido - Exemplo

• Caso de Uso: Dado um conjunto de comentários de usuários de um blog, construir um Índice de URLs da Wikipedia para um conjunto de Ids de respostas postadas em um blog. Analisar cada resposta de um blog para encontrar hyperlinks para Wikipedia


Padrões de Filtragem

• Encontrar um subset dos dados sem alterar seu estado atual.

• Filtragem permite uma análise mais detalhada de pequenas partes dos dados. Ex: Encontrar os registros de um usuário específico

• Alguns padrões: Filtragem simples, Filtragem Bloom, Top Ten, Distinct


Padrões de Filtragem Filtragem Simples

• Objetivo - Filtrar registros que não interessam. Reter somente os interessantes

• Motivação – Data sets muito grandes. Necessidade de analisar um subset.

• Aplicabilidade – Registros que podem ser filtrados baseados em um critério

• Consequências – Subset de dados. Se o formato for mantido, um mesmo job que executa sobre o data set original, pode executar sobre o subset.

• Ex: Distributed Grep


Padrões de Filtragem Filtragem Simples

• Performance

• Sem Reducers

• Dados não precisam ser transmitidos entre map e reducers

• Não necessita de ambas as fases: sort e reducer (mais rápido)


Padrões de Filtragem Filtragem Simples - Exexmplo: Distributed Grep


Padrões de Organização dos Dados

• Hadoop e MapReduce muitas vezes são uma pequena parte em uma plataforma de análise de dados

• Dados precisam ser transformados para tornar possível sua análise através de MapReduce

• Exemplos de padrões: Structured to Hierarchical, Partitioning, Binning, Total Order Sorting


Padrões de Organização dos Dados Structured to Hierarchical

• Objetivo - Transformar os dados para um formato de hierarquia. Ex: JSON, XML

• Motivação – Migração de dados de um RDBMS para o Hadoop. Table Joins. Reformatar os dados em uma forma mais clara.

• Aplicabilidade – Dados ligados por foreing keys. Dados estruturados e “row-based”

• Ex: Preparar dados para o Hbase


Padrões de Organização dos Dados Structured to Hierarchical - Overview

Fonte: MapReduce Design Patterns by Donald Miner and Adam Shook (2012)


Padrões de Organização dos Dados Exemplo – Post/Comment

• Caso de Uso: Dado uma lista de posts e comentários, criar uma hierarquia estruturada em XML para aninhar os comentários com seu post


Padrões de Organização dos Dados Post/Comment - Driver


Padrões de Organização dos Dados Post/Comment - Mappers


Padrões de Organização dos Dados Post/Comment - Reducer


Padrões de Join Sobre Joins

• Inner Join A B

A + B

• Left Outer Join A + B

• Right Outer Join A + B


Padrões de Join Sobre Joins

• Full Outer Join A B A + B

• Anti Join = Full Outer Join - Inner join

• Produto Cartesiano


Padrões de Join Para MapReduce

• Reduce Side Join

• Replicated Join

• Composite Join

• Cartesian Product


Padrões de Join Reduce Side Join

• Objetivo • Unir múltiplas bases de dados através de uma chave

• Motivação

• Simples de implementar

• Suporta todos os tipos de “Joins”

• Sem restrição de limite quanto ao tamanho das bases de dados

• Aplicabilidade

• Múltiplas bases de dados agrupadas por uma chave

• Flexibilidade de poder executar qualquer operação de join



• Performance

• Tráfego de dados na rede para a fase de reduce

• Não apresenta otimizações se puder, melhor utilizar outro padrão de Join

Em SQL

Caso de Uso: Dado um conjunto de informações sobre usuários e uma lista de comentários de um blog, enriquecer os comentários com informações sobre os usuários que criaram os mesmos



• Estrutura



Padrões de Join

• Driver Code

Reduce Side Join


Reduce Side Join

Padrões de Join

Input A <User> ...<\User>

Output Mapper A

Fase Map

Key = UserID Value = “A” + User Data

Input B <Comment> ...<\Comment>

Output Mapper B

Key = UserID Value = “B” + Comment Data


Padrões de Join

List A List B

Output executeJoinLogic

Reducer

A + B

Reduce Side Join

executeJoinLogic


Padrões de Join Replicated Join

• Objetivo • Unir uma base de dados grande e várias pequenas,

eliminando a fase de Reduce

• Motivação • Execução apenas na fase de map

• Suporta Inner Join e Left Outer Join

• Aplicabilidade

• Quando Inner ou Left Outer Join são necessários, com a base de dados grande sendo a parte “left” na operação

• As bases pequenas devem caber na memória, sendo carregadas durante a fase de setup de cada tarefa de map



• Performance • O Replicated Join pode ser o tipo mais rápido de padrão de

Join, por fazer acesso a memória e não necessitar da fase de reduce

• Limitações quanto a quantidade de dados que podem ser armazenados na JVM



• Estrutura



Context-Aware Recommender Systems

Context Information


• Distributed Cache

Distributed Cache

Mapper Setup

Key (UserID) Value (User Data) 3 New York 4 New York 5 San Diego 9 Oakland


Contextual Intelligence

Context-Aware Recommender Systems Context-Aware Recommender Systems

Context Information


• Mapper

Recupera dados em memória para fazer o join




Context Information

Padrões de Join Composite Join

• Objetivo • Unir bases de dados pre-formatadas através de uma chave,

com a execução apenas na fase de map

• Motivação

• Particularmente útil para unir bases grandes, mas exige um pre-processamento dos dados

• Suporta Inner e Full Outer Join

• Aplicabilidade

• Quando desejado um Inner ou Full Outer Join entre bases grandes

• As bases devem ser ordenadas e particionadas pela chave estrangeira e lidas de uma maneira específica




Context Information

Padrões de Join Composite Join Pré-processamento

• Todas as bases devem ser lidas com a chave estrangeira sendo a chave de input para o mapper

• Todas as bases devem possuir o mesmo número de partições

• Cada partição é ordenada pela chave estrangeira, e todas as chaves devem residir na partição associada de cada base de dados





Context Information

Padrões de Join Composite Join

• Estrutura:





Context Information

Padrões de Input e Output

• Customizar Input e Output no Hadoop • Configurar como chuncks de input são gerados a partir

dos blocos do HDFS • Configurar como registros aparecem na fase de map • RecordReader and InputFormat classes • RecordWriter and OutputFormat classes • Padrões: • Generating Data • External Source Output • External Source Input • Partition Pruning

Obrigado!

Felipe Ferreira [email protected]

Karla Okada Gomes

@karlaokada [email protected]

INdT - Instituto Nokia de Tecnologia www.indt.org.br

Manaus – Am

mailto:[email protected]

mailto:[email protected]

http://www.indt.org.br/

Padrões de Design para MapReduce

Technology

Transcript of Padrões de Design para MapReduce