Artigo implementando o cubo de dados eficientemente
Download
1 / 36

Artigo: Implementando o cubo de dados eficientemente - PowerPoint PPT Presentation


  • 52 Views
  • Uploaded on

Universidade Federal de São Carlos Centro de Ciências Exatas e de Tecnologia Departamento de Computação. Artigo: Implementando o cubo de dados eficientemente. Venky Harinarayan Anand Rajaraman Jeffrey D. U1lman. Walter Coelho Pereira de Magalhães Junior PPGCC/DC Agosto / 2009.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Artigo: Implementando o cubo de dados eficientemente' - theola


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Artigo implementando o cubo de dados eficientemente

Universidade Federal de São Carlos

Centro de Ciências Exatas e de Tecnologia

Departamento de Computação

Artigo: Implementando o cubo de dados eficientemente

VenkyHarinarayan

AnandRajaraman

Jeffrey D. U1lman

Walter Coelho Pereira de Magalhães Junior

PPGCC/DC

Agosto / 2009


Organiza o desta apresenta o
Organização desta apresentação

  • Introdução

  • Framework lattice

  • Modelo de custo de consultas utilizado neste artigo

  • Otimizando o cubo de dados lattice

  • Hipercubo lattice

  • Conclusões e trabalhos futuros


Introdu o
Introdução

Breve revisão de conceitos básicos

1) Modelos multidimensionais e conceitos associados

  • Observam as relações inerentes aos dados para gerar matrizes multidimensionais:

    • Bidimensionais (planilhas)

    • Tridimensionais (cubo de dados)

    • Acima de três dimensões (hipercubo)

      Cada célula no cubo de dados contém dados de cada dimensão e consiste em uma medida (agregação) de

      interesse. Os valores de muitas destas células são dependentes dos valores de outras células.

      Os dados podem ser consultados diretamente em qualquer combinação de dimensões, evitando consultas

      complexas no banco de dados

      O desempenho de consultas em matrizes multidimensionais pode ser muito superior comparativamente ao

      modelo relacional

      Em um cubo de dados a mudança de uma hierarquia dimensional para outra é realizada por meio de uma

      técnica de rotação (pivotamento)... Mostrar exemplo


Introdu o1
Introdução

  • Modelos multidimensionais proporcionam visões hierárquicas conhecidas como apresentações:

    • “roll-up”: agregação, sumarização, maior granularidade, move-se para cima na hierarquia, agrupa em unidades maiores ao longo de uma hierarquia...

      Exemplo: sumarização de dados mensais por trimestre ou por ano

    • “drill-down”: desagregação, granularidade mais fina, move-se para baixo na hierarquia..

      Exemplo: desagrupar vendas nacionais em regionais ou por unidade produtiva

  • Um modelo de armazenamento multidimensional envolve dois tipos de tabelas:

    • de dimensão, consistindo de uma tupla de atributos da dimensão

    • de fatos, uma tupla para cada fato identificado por ponteiros para as tabelas de dimensão

  • Esquemas multidimensionais comuns são:

    • Estrela, única tabela de fatos e única tabela para cada dimensão

    • Snowflake, possui tabelas de dimensão normalizadas

      “Constelação de fatos, conjunto de tabelas de fatos compartilhando tabelas de dimensão...”


Introdu o2
Introdução

  • Modelagem multidimensional: os sistemas de banco de dados tradicionais utilizam a normalização no formato de dados visando garantir consistência aos dados e uma minimização do espaço de armazenamento necessário. Entretanto, algumas transações e consultas em bases de dados normalizadas podem tornar-se lentas devido às operações de junção entre tabelas. Um DataWarehouse utiliza dados em formato de-normalizados. Isto aumenta o desempenho das consultas e, adicionalmente, o processo de consulta torna-se mais intuitivo para os usuários comuns.

    2) Sistemas de apoio à decisão (DSS) e Banco de dados para apoio à decisão – Data Warehouse:

  • Aplicações de suporte à decisão envolvem consultas complexas em banco de dados muito grandes e fazem forte uso de agregação de dados - Uma vez que o tempo de resposta deve ser pequeno, a otimização de consultas é crítica...

    Uma técnica comum e poderosa para otimização de consultas é “materializar algumas ou todas estas

    células (visões)” ao invés de computá-las, cada vez, a partir de dados brutos

    As visões materializadas consistem na principal opção para aprimorar o desempenho em um DW,

    entretanto:

    • otimizadores e técnicas de avaliação de consultas podem ser aprimoradas para lidar melhor com agregações

    • podemos usar diferentes estratégias de indexação, tais como índices de bitmap e índices de junção

    • outras opções

      Uma visão materializada é uma consulta cujo resultado já foi computado e está armazenado na base de dados...

      As consultas que puderem utilizar as visões já armazenadas, podem ser executadas de forma muito mais rápida.

      Conforme a complexidade e o volumes de dados, podem ser reduzidas de horas ou dias para segundos ou minutos.


Introdu o3
Introdução

Outra questão importante é que ao materializarmos uma consulta (mesmo que relativamente

infrequente) podemos ser capazes de responder a outras rapidamente...

3) Este artigo:

  • Investiga a questão de qual célula (visão) materializar, quando for muito caro materializar todas as visões.

  • Um framework lattice (entrelaçado) é usado para expressar as dependências entre as visões e juntamente com algorítimos, permitem escolher um bom conjunto de consultas a serem materializadas e indicar a ordem em que devem ser materializadas.

    TPC-D: Banco de dados de apoio à decisão - Data warehouse

  • Existem três dimensões nas quais estamos interessados: peça, fornecedor e consumidor.

  • A medida de interesse é o total de vendas.

  • Em cada célula (p,s,c) neste cubo de dados 3-D armazenamos as vendas de peças “p” que foram compradas do fornecedor “s” e vendidas ao consumidor “c”.

    “Embora uma dimensão possa ter muitos atributos, usa-se os termos dimensões e atributos de

    forma alternada nesta seção”


Introdu o4
Introdução

Suponha que os usuários estão interessados nas vendas consolidadas...

Qual é o total de vendas de uma peça “p” para um consumidor “c”

Sugere-se acrescentar um valor adicional “ALL” para o domínio de cada dimensão:

Qual o total de vendas da peça “p” para o consumidor “c” para “todos” os fornecedores

A consulta será respondida observando o valor da célula (p, ALL, c), que será computada como a soma dos

valores das células de (p, s1, c),...,(p, sn, c), onde “n” representa o número de fornecedores

Quanto mais células nós materializamos, melhor será o desempenho das consultas. Contudo, para grandes

cubos, nós podemos ser capazes de materializar somente uma pequena fração de células devido ao espaço e

outras restrições. Por isto é muito importante escolhermos as células corretas para materializar...

Qualquer célula que tenha o valor “ALL” como um dos componentes em seu endereço é uma “célula

dependente”, cujo valor é computável a partir de outras células no cubo de dados. Se uma célula não possui

“ALL” como componente, seu valor não pode ser computado por outras células e nós precisaremos consultar

os dados brutos para computar seu valor.

O número de células contendo “ALL” como um de seus componentes é normalmente uma grande parte do

total de células no cubo de dados... No TPC-D 70% das células do cubo de dados são dependentes...


Introdu o5
Introdução

  • Alternativas de implementação do cubo de dados:

    • Materialização completa do cubo de dados

      • Melhor tempo de reposta

      • Alternativa não factível para grandes cubos de dados - espaço de armazenamento

      • Espaço consumido causa impacto na indexação

    • Nenhuma materialização

      • Problemas com tempo de resposta: “precisamos ir até os dados brutos e computar cada célula...”

      • Nenhum espaço extra é solicitado, além do exigido para os dados brutos

    • Materializar somente parte do cubo de dados

      • Aproveitar o conceito de células dependentes no cubo de dados, sabendo que os valores de muitas células são computáveis a partir de outras

        “Esta dependência é similar a uma planilha onde o valor das células pode ser calculado em função de outras...”

  • A questão de onde armazenar o cubo de dados materializado, facilita o processamento de dados multidimensionais - OLAP

    • Sistema relacional: escalável, suporta DW muito grandes, técnicas para melhorar desempenho

    • Banco de dados multidimensional proprietário (MDDB)+API’s para OLAP: melhor desempenho

      “Implementação comum: dados brutos em sistema relacional e o cubo em MDDB...”


Introdu o6
Introdução

  • Este artigo assume que:

    • O cubo de dados está implementado em tabelas resumo em um sistema relacional

    • Os conjuntos de células do cubo de dados estão associados a diferentes tabelas e agrupados segundo a posição do operador “ALL” em seus endereços

      Assim, todas as células que batem com o endereço ( _, ALL, _) estão colocadas no mesmo conjunto...

    • Cada um deste conjuntos de células correspondem a diferentes consultas SQL...

      A saída da consulta

      “SELECT Part, Customer, SUM(SP) AS Sales FROM R GROUP BY Part, Customer”

      é o conjunto de células no formato (_, ALL, _)

      Observações:

    • Em geral, atributos com valores “ALL” no conjunto de células não aparecem na cláusula GROUP BY

    • Os atributos de agrupamento diferenciam as consultas SQL que formam os conjuntos de dados

    • Decidir qual conjunto de células materializar é equivalente a decidir qual consulta (visão) materializar

    • O custo de resposta a uma consulta é proporcional ao número de linhas examinadas

    • As visões não possuem índices...


Introdu o7
Introdução

Exemplo:

O banco de dados TPC-D possui três dimensões (atributos): peça, fornecedor, consumidor

A medida de interessesão as vendas

Oferece oito possibilidades de agrupamento dos atributos ...

formam oito consultas (visões) organizados em forma entrelaçada (lattice)

“Repare que basta mencionar os atributos na cláusula GROUP BY...”

Visõescandidatas a materialização:

1. part, supplier, customer (6 Milhões de linhas)

2. part, customer (6M)

3. part, supplier (0.8M)

4. supplier, customer (6M)

5. part (0.2 M)

6. supplier (0. 01 M)

7. customer (0.1 M)

8. none (1) – nenhum atributo na cláusula GROUP-BY


Introdu o8
Introdução

Trabalhando com as visões: exemplo de possíveis consultas solicitadas pelos usuários...

  • Total das vendas agrupadas por peça

    Temos uma visão materializada agrupada somente por (peça) - visão 5:

    • Processamento: basta varrer a visão inteira e mostrar a resposta

    • Custo de resposta da consulta: custo de processar 0,2 milhões de linhas (tamanho da view)

      Temos uma visão materializada agrupada por (peça,consumidor) – visão 2:

    • Processamento: para cada peça precisamos somar suas vendas por todos os consumidores

    • Custo de resposta da consulta: processar 6 milhões de linhas

  • Vendas de uma única peça

    A análise acima se aplica, exceto pelo fato de que no processamento da visão 5 poderíamos varrer a visão inteira ou metade na média

    Questões interessantes:

    • Quantas visões devemos materializar para obtermos uma performance razoável ?

    • Quais visões devemos materializar para minimizar o custo médio de consulta ? (Existe espaço)

      O framework lattice e os algorítimos, vistos mais a frente, ajudam a responder estas questões e fornecem resultados próximos ao ótimo...


  • Introdu o9
    Introdução

    Buscando a eficiência no processo de materialização:

    Na materialização de todo o cubo de dados do TPC-D as visões materializadas ocupariam mais de

    19 milhões de linhas...

    Procurando ser mais eficiente, podemos escolher adequadamente quais partes do cubo de dados

    materializar, aproveitando a “dependência das células (consultas, visões) e colher benefícios dramáticos:

    • Necessitamos materializar a visão agrupada (peça,fornecedor,consumidor) – visão 1 –

      “evitando consultar os dados brutos, uma vez que ela não pode ser construída a partir de outra”

    • Não existe nenhuma vantagem em materializar a visão (peça,consumidor) – visão 2 - “toda consulta direcionada à esta visão pode ser respondida por meio da visão 1, a qual também apresenta um custo de resposta na ordem de 6 milhões de linhas”

    • Pela mesma razão, não existe vantagem em materializar a visão (fornecedor,consumidor) – visão 4

      Conclusão:

      “... podemos obter quase o mesmo custo médio de consulta materializando um cubo de dados com apenas 7 milhões de linhas, representando um ganho de mais de 60% em termos de espaço consumido e no custo para criar o cubo de dados”


    Framework lattice
    Framework Lattice

    • Consiste em uma notação utilizada para descrever quando uma consulta ao cubo de dados pode ser respondida usando o resultado de outra...

      A notação de uma visão ou consulta apresenta seus atributos de agrupamento entre parênteses, por exemplo: (peça, fornecedor, consumidor)

      Q1 Q2 :: A consulta Q1 pode ser respondida usando os resultados da consulta Q2

      Q1 é dependente de Q2

      Exemplo: (peça,consumidor) (peça,fornecedor,consumidor)

      (peça,fornecedor) (peça,fornecedor,consumidor)

      Q1 Q2 :: A consulta Q1 não é comparável com a consulta Q2

      Exemplo: (peça) (consumidor)

    • Notação Lattice: (L, ) : L = conjunto de elementos (visões ou consultas) do lattice

      : = relação de dependência

      Para os elementos (visões) “a” e “b” do lattice dizemos que “b” é progenitora (mãe) de “a”

      se e somente se a b


    Framework lattice1
    Framework Lattice

    • Hierarquias

      Na maioria das aplicações do mundo real as dimensões de um cubo de dados possuem

      vários atributos e estão organizadas em hierarquias destes atributos

      “...organizar a dimensão tempo na hierarquia dia, mês, ano”

      Possibilitam as operações abaixo:

      TOTAL DE VENDAS

      “roll-up” : Vendas por dia, vendas por mês, vendas por ano

      Dia Mês Ano

      “drill-down” : Vendas por ano, vendas por mês, vendas por dia

      Lembrando:

      • Introduzem o conceito de “dependência de consultas” que devemos considerar quando formos materializar as consultas...

      • Drill-down é o processo de visualização de dados progressivamente até um nível mais detalhado, roll-up é o oposto


    Framework lattice2
    Framework Lattice

    • Com hierarquias a dependência lattice (L, ) é mais complexa que o hipercubo lattice...

      Usando a hierarquia com atributos da dimensão tempo Ano, Mês, Dia podemos agrupar as consultas em três possibilidades, conforme a granularidade, em (Ano), (Mês), (Dia) e assim temos que (Ano) (Mês) (Dia)

      “...se temos o total de vendas agrupado por mês, podemos usar os resultados para computar o total de vendas por ano”

      Em uma hierarquia Ano, Mês, Semana, Dia observe que (semana) (mês)

      (semana) (ano). Portanto, se agruparmos por semana não poderemos,

      a partir deste agrupamento, determinar o agrupamento por mês ou ano,

      e vice-versa, uma vez que nem mês nem ano podem ser divididos de uma

      maneira uniforme em semanas

      Composição lattice para múltiplas dimensões hierárquicas

      Estamos confrontados com dois tipos de “dependência de consultas”:

      • Dependência de consulta devido a interação entre diferentes dimensões

      • Dependência de consulta em uma mesma dimensão devido a hierarquia de atributos


    Framework lattice3
    Framework Lattice

    Para cada dimensão podemos criar visões agrupando por um membro da hierarquia ou nenhum...

    então cada visão pode ser representada por uma n-tupla (a1, a2, ..., an) onde cada elemento

    é um ponto nesta hierarquia da n-ézima dimensão

    Este lattice é denominado “produto direto do lattice dimensional”:

    (a1, a2,...,an) (b1,b2,..,bn), se e somente se, ai bi, para todo i.

    Exemplo:

    • As dimensões “peça” e “consumidor” estão organizadas em hierarquias...

    • No lattice dimensional os atributos de cada dimensão podem ser agrupados, formando as consultas:

      • na dimensão “consumidor”: individualmente (i), por nação(n) ou nenhum (none)

      • na dimensão “peça”: tamanho (s), tipo (t) ou nenhum (none) , observando que (s) (t)

        “Quando o valor da dimensão é “none” não especificamos a dimensão na consulta: (s,none) => (s)”


    Framework lattice4
    Framework Lattice

    • Framework lattice combinando duas dimensões hierárquicas

      Vantagens do framework lattice:

      1) Trata-se de um framework limpo para raciocinarmos com hierarquias dimensionais, uma vez que

      o produto direto lattice nem sempre é um hipercubo quando as hierarquias não são simples

      2) Podemos modelar melhor as consultas comuns solicitadas pelos usuários

      3) A abordagem lattice nos ajuda a determinar em que ordem materializar as visões…

      • Aousarmos as visõesquejátenhamsidomaterializadasparamaterializaroutrasvisões, podemosreduzir o acessoaos dados brutos e reduzir o tempo total de materialização

      • Uma simples ordenaçãodescendente no operadornosinforma a ordemrequeridaparamaterialização


    O modelo de custo
    O modelo de custo

    Modelo de custo linear adotado

    “O tempo para responder a uma consulta é considerado igual ao espaço ocupado pela visão a partir da

    qual a consulta é respondida...”

    Em um lattice (L, ) de visões para responder a uma consulta Q escolhemos visão materializada QA progenitora de Q.

    Para responder Q necessitamos processar a tabela correspondente a QA...

    Este artigo adota o modelo de custo mais simples:

    O custo para responder Q é o “número de linhas” presentes na tabela QA usada para construir Q, ou seja, o custo de Q está em função do tamanho da tabela QA

    Existem outros fatores não considerados que influenciam no custo da consulta, por exemplo:

    • cluster de visões materializadas sobre algum atributo

    • índices

      Modelos de custo mais complicados são certamente possíveis, mas o modelo de custo adotado é mais simples e realista, habilitando-nos a projetar e analisar algoritmos poderosos...

      A análise dos algoritmos detalhados mais a frente, reflete a performance sobre outros modelos de custo, tanto quanto, sobre o modelo de custo adotado...


    O modelo de custo1
    O modelo de custo

    Exame de um experimento do modelo de custo linear adotado

    Em uma validação experimental deste modelo de custo solicitamos o total de vendas para um único fornecedor

    usando visões de diferentes granulações...

    Encontramos um relacionamento quase linear entre o tamanho e o tempo de execução da consulta, expresso pela

    fórmula :

    T= M * S + C

    • T = tempo de execução da consulta

    • M = razão (taxa) entre o tempo da consulta e o tamanho da visão (T/S), após contabilizar o custo fixo

    • S = tamanho da visão

    • C = custo fixo (overhead para executar a consulta em uma visão de tamanho desprezível)

      Note que a taxa é quase sempre a mesma para diferentes visões....


    O modelo de custo2
    O modelo de custo

    Determinando os tamanhos das visões

    Os algorítmos usados neste artigo requerem o conhecimento do número de linhas presente em cada visão

    Existem muitas maneiras de estimar os tamanhos das visões sem materializar todas as visões...

    • Uma abordagem comumente usada éexecutar o algorítmo sobre um pequeno mas estatisticamente

      representativo subconjunto de dados brutos.

      Neste caso, nós podemos obter o tamanho das visões, na verdade, materializando as visões.

      Usamos este subconjunto de dados brutos para determinar quais visões nós queremos materializar.

      Podemos usar métodos de amostragem e análise para calcular o tamanho das diferentes visões se nós

      somente materializarmos o maior elemento no lattice (a visão agrupada pelo maior atributo em cada

      dimensão).

      Em uma visão, se sabemos que os atributos de agrupamento são estatisticamente independentes, podemos

      estimar o tamanho da visão, analiticamente, em relação ao tamanho da maior visão no lattice.

      De outra forma, nós podemos amostrar a maior visão ou dado bruto para estimar o tamanho de outras

      visões.

      O tamanho de uma visão é o número de valores distintos dos atributos que ela agrupa...

      Existem muitas técnicas de amostragem conhecidas que podemos usar para determinar o número de valores distintos dos atributos em uma relação


    Otimizando o cubo de dados lattice
    Otimizando o cubo de dados lattice

    Nosso mais importante objetivo é desenvolver técnicas para otimização de tempo e espaço quando

    implementamos um lattice de visões

    Iniciaremos com um simples problema de otimização:

    • Minimizar o tempo médio necessário para avaliar o conjunto de consultas que são idênticas às visões

    • Estamos restritos a materialização de um número fixo de visões não importando o espaço que ocupem

      Algorítmo ganancioso

      “...selecionamos uma sequência de visões sendo cada uma a melhor escolha dado o que aconteceu antes. Esta abordagem é sempre relativamente próxima à ótima, e em alguns casos produz a melhor seleção possível de visões a materializar...”

      Supondo:

      • existe um cubo de dados lattice com um custo de espaço (número de linhas) associado a cada visão

      • C(v) = custo da visão v

      • o conjunto de visões que materializaremos deve sempre incluir a visão superior (topo), porque não existe qualquer outra visão que possa ser utilizada para responder a uma consulta correspondente a esta visão...

      • existe um limite k para o número de visões, adicionalmente a visão superior que podemos selecionar

      • após selecionar o conjunto S de visões, o benefício da visão v relativa a S , denotado por B(v,S), é definido por:

        1) Para cada w v definir a quantidade Bw por:

        a) u é a visão de menor custo em S e w u

        b) se C(v) < C(u), então Bw = C(v) – C(u), senão Bw = 0


    Otimizando o cubo de dados lattice1
    Otimizando o cubo de dados lattice

    2)

    Ou seja, nós computamos o benefício da visão “v” considerando como ela pode aprimorar o custo de

    execução das visões “w” que podem ser respondidas a partir dela, incluindo também a si mesma

    Para cada visão “w” que “v” cobre, nós comparamos o custo de execução de “w” usando “v” X o custo

    de execução de “w” usando qualquer visão em S oferecida como a maneira mais barata de executar

    “w”

    Se “v” contribuiparaque o custo de “v” sejamenorquedasuaconcorrente, então a diferença

    representa parte do benefício de selecionar “v” comoumavisãomaterializada

    O benefício total B(v, S) é a soma dos benefícios de executartodas as visões “w” a partir de “v”,

    desdeque o benefíciosejapositivo

    Definimos o algorítmo gananciosoparaselecionar um conjunto de k visõesparamaterializar

    S = {top view};

    for i=l to k do begin

    select that view v not in S such that B(v, S) is maximized;

    S = S union {v};

    end;

    resulting S is the greedy selection;


    Otimizando o cubo de dados lattice2
    Otimizando o cubo de dados lattice

    Exemplo:

    O lattice ao lado possui oito visões (a ... h) com seus custos de espaço

    • A visão superior (a), com custo 100, precisa ser escolhida

    • Gostaríamos de escolher mais três visões para materializar

      Para executar o algorítmo ganancioso neste lattice precisamos fazer três

      escolhas sucessivas de visões para materializar...

      A coluna “Choice 1” informa os benefícios de escolha além de “a”

    • No cálculo do benefício assumimos que cada visão é avaliada

      usando “a” e portanto terá um custo de 100

    • Se primeiramente pegarmos a visão “b” para materializar

      reduziremos seu custo por 50 e para cada visão abaixo dela (d,e,g,h) ... O benefício será de 50 x 5 = 250

    • Se pegarmos “e” primeiro, entãoela e as visões (g,h) abaixodelaterãoseuscustosreduzidosem 70, ouseja, de 100 para 30. Assim o benefícioserá de 70 x 3 = 210

    • Então, elegemos a visão “b” nesteprimeiro round, como

      uma das visões a seremmaterializadas

    • Precisamosrecalcularosbenefícios de cadavisão “v”

      dado que a visãoserácriadaou a partir de “b” a um custo

      de 50 se “b” estiveracima de “v” , ou a partir de “a” a um

      custo de 100 se “b” nãoestiveracima de “v”


    Otimizando o cubo de dados lattice3
    Otimizando o cubo de dados lattice

    Os benefícios agora sãomostradosnacoluna “Choice 2”

    • O benefíciodavisão “c” é agora 50: 25 parasimesmo e f. Escolher “c” nãomelhora o custo de e, g ou h em 25 paraestasvisões

    • Escolher f gera um benefício de 60 parasimesma, de 100 para 40. Para “h” elagera um benefício de 10, de 50 para 40, umavezque a escolha de “b” jámelhorou o custoassociado com “h” em 50

    • A vencedora é “f” com um benefício de 70

      Nossaterceiraescolhaestáresumidanacoluna “Choise 3”

    • A vencedora do terceiro round é “d” com um benefício de 60 parasimesma e para “g”

      A seleçãogananciosasão as visões “b”, “f” e “d” quejuntamente com “a” reduzem o custo total paraexecutar

      todas as visões de 800 (casosomente “a” fosse materializada) para420. Atualmente, este é o custoótimo


    Otimizando o cubo de dados lattice4
    Otimizando o cubo de dados lattice

    Exemplo: O lattice ilustrado abaixo é tão ruim quanto um lattice pode ser para o caso k = 2

    “Um exemploonde a ganânciafaz mal…”

    O algorítmo gananciosoinicia com somente a visão top “a”.

    Primeiramentepega “c” cujobenefício é 4141. “c” e as 40 visõesabaixodelasãomelhoradas de 200 para 99,

    quandousamos “c” no lugar de “a” pararespondê-las

    Para nossasegundaescolha, podemospegarou “b” ou “d”. Ambos possuem o benefício de 2100. Em “b”

    observamosque ela melhora a si mesmo e os 20 nós na extremidade esquerda por 100 cada

    Assim, com k = 2 o algorítmo produz uma solução com um benefício de 6241


    Otimizando o cubo de dados lattice5
    Otimizando o cubo de dados lattice

    Contudo, a escolhaótima é pegar “b” e “d”, umavezque juntas estasduasvisõesmelhoramem 100 a simesmas e as outras 80 visõesnasquatrocadeias

    Desta forma, a soluçãoótimaapresenta um benefício superior de 8200

    A razão greedy / ótima é 6241 / 8200 = ¾

    “Em verdade, tornando o custo de “c” próximo a 100 e fazendo as quatro cadeias terem um número

    grande de visões, podemos encontrar exemplos para k = 2 com razão próxima a 3/4, mas não pior”

    Um experimento com o algorítmo ganancioso

    Executamos o algorítmo no lattice combinando 2 dimensõeshierárquicas (mostradoanteriormente)

    usando o banco de dados TPC-D

    A ordemresultante das visões a partirdaprimeira (top – obrigatória)

    para a última, é vista aolado

    As unidadesBenefícios, Tempo e Espaçoestãoemnúmero de linhas

    O tempo médiodaconsulta é o tempo total divididopelonúmero de

    linhas das 12 visões

    O exemplo a seguirmostraporque é importantematerializaralgumas

    visões e porquematerializartodas as visõesnão é boa escolha…


    Otimizando o cubo de dados lattice6
    Otimizando o cubo de dados lattice

    Para as primeiras visões que selecionamos com mínima adição de espaço, o tempo de consulta é reduzido

    substancialmente. Contudo, após a quintavisão, nãomelhoramos o tempo total de consultasubstancialmente,

    mesmousandograndesquantidades de espaço

    É claro quando parar de pegar visões...Para as cinco primeiras obtemos quase o tempo total mínimo possível

    enquanto o espaço total usado é pouco maior que o espaço obrigatório usado apenas para a visão “top”

    Tempo total

    Espaço consumido

    Número de visões


    Otimizando o cubo de dados lattice7
    Otimizando o cubo de dados lattice

    Um desempenho garantido para o algorítmo ganancioso

    O algorítmo ganancioso nunca executa “muito mal” qualquer que seja o lattice...

    possui ao menos 63% do benefício de um algorítmo ótimo

    Notação

    m = número de visões em um lattice

    suponha não existir nenhuma visão selecionada além da “top” (a qual é obrigatória), então

    o tempo T para responder cada consulta é exatamente o número de linhas da visão “top”

    V= {v1,v2,..,vk} conjunto de visões ordenadas escolhidas pelo algorítmo além da visão “top”

    Tv = tempo médio para responder a uma consulta

    T - Tv= benefício do conjunto de visões V: redução no tempo médio para responder a uma consulta

    “...minimizar o tempo médio para responder a uma consulta equivale a maximizar o benefício

    de um conjunto de visões...”

    v1,v2,...,vk= “k” visões selecionadas em ordem pelo algorítmo ganancioso

    ai = benefício alcançado pela seleção de vi pertencente ao conjunto V + top e onde i = 1,2,...,k

    W = {w1,w2,..,wk} conjunto ótimo de visões: fornecem o benefício total máximo

    bi = benefício alcançado pela seleção de wipertencente ao conjunto W (ordenado) + top e onde i = 1,2,..,k

    e


    Otimizando o cubo de dados lattice8
    Otimizando o cubo de dados lattice

    Bgreedy = T - Tv = A / m benefício do conjunto V escolhido pelo algorítmo

    Bopt = T - Tw = B / m benefício do conjunto W ótimo escolhido

    para k = 2 obtivemos A / B ≥ 3 / 4 .... O algorítmo ganancioso é ao menos 3/4 do ótimo

    mostramos um lattice que aproximou em 3/4 a razão entre o benefício dos algorítimos greedy e ótimo

    Em outro artigo mostramos que podemos construir um lattice tal que  k

    como k ->  , aproxima de 1/e, assim 1 – 1/e = (e – 1) / e = 0.63

    ou seja, para qualquer lattice o algorítmo ganancioso não dará benefício inferior a 63% do algorítmo

    ótimo. O exemplo “onde a ganância faz mal” mostra que esta razão não pode ser melhorada

    Os resultados estão sumarizados no seguinte teorema:

    “Para qualquer lattice onde

    Bgreedy seja o benefício de k visões escolhidas pelo algorítmo ganancioso

    Boptseja o benefício de um conjunto ótimo de k visões

    então

    e existem lattices onde é próximo a “


    Otimizando o cubo de dados lattice9
    Otimizando o cubo de dados lattice

    Situações onde o algorítmo ganancioso é ótimo e não necessitamos buscar outras soluções...

    • se a1 é muito maior que os outros a’s então o algorítmo ganancioso é próximo a ótimo

    • se todos os a’s são iguais então o algorítmo ganancioso é ótimo

      Extensões ao modelo básico

      Existem ao menos duas situações onde o modelo falha ao refletir a realidade...

    • As visões em um lattice não são sucetíveis de terem a mesma probabilidade de serem solicitadas em uma consulta... Em vista disto, devemos ser capazes associar uma probabilidade à cada visão representando a frequência na qual é solicitada

      Ao computarmos os benefícios, pesamos cada visão por sua probabilidade... O algorítmo terá os mesmos limites de desempenho: ao menos 63%...

    • Em vez de solicitar um número fixo de visões a materializar, nós poderíamos alocar uma quantidade fixa espaço para as visões (além da visão “top” que sempre deve ser materializada)

      Se não temos restrições ao número de visões selecionadas , mas sim ao espaço ocupado por elas, necessitamos considerar o benefício de cada visão por unidade de espaço utilizado na sua materialização... O algorítmo gananciosoterá uma complicação adicional, mas existe um teorema que afirma: “se ignoramos casos limite o desempenho garantido do algorítmo ganancioso é o mesmo dos casos simples...”

      Teorema: “SejaBgreedy o benefício e S o espaço ocupado por um conjunto de visões escolhidas pelo algorítmo ganancioso e Bopt o benefício de um conjunto ótimo de visões que ocupa não mais que S unidades de espaço, então “


    O hipercubo lattice
    O hipercubo lattice

    A classe mais importante de lattices são os hipercubos, nos quais as visões são vértices de um cubo

    n-dimensional, para qualquer “n”

    • Existem “n” atributos onde um agrupamento pode acontecer...

      Vimos um exemplo de hipercubo com n=3 para o banco de dados TPC-D

    • A visão “top” agrupa todos estes “n” atributos

    • Podemos visualizar as visões organizadas por “ranks” onde o i-ézimorank a partir do fundo são todas as visões agrupadas em “i” atributos. Existem visões no rank “i”

      Caso: tamanho de domínio igual

      Podemos aplicar o algorítmo ganancioso no hipercubo procurando:

    • um número fixo de visões para materializar ou

    • uma quantidade fixa de espaço para alocar para as visões

      Examinaremos em maiores detalhes as opções para seleção de visões para materialização...

      Assumimos ser improvável, na prática, que todos os atributos tenham o mesmo tamanho de domínio (r)

      • Consequentemente, podemos estimar facilmente o tamanho de qualquer visão...

      • Veremos à frente que a visão atual selecionada para materialização irá variar, mas as técnicas básicas não mudarão para acomodar esta situação

        Quando cada tamanho de domínio é “r” e os dados no cubo de dados estão distribuídos aleatoriamente, então existe uma maneira simples de estimar o tamanho das visões

      • Suponha que somente “m” células da visão topo de um lattice aparecem nos dados brutos

      • Se agruparmos em “i” atributos então o número de células no cubo resultante será “ri”


    O hipercubo lattice1
    O hipercubo lattice

    Se ri ≥ m então cada célula conterá no máximo um ponto de dados e “m” destas células não estarão vazias

    então, “m” será o tamanho de qualquer visão para a qual ri ≥ m

    Se ri < m então quase todas as “ri”células terão ao menos um ponto de dados

    Uma vez que podemos condensar todos os pontos de dados de uma célula em um valor agregado , o custo de espaço de uma visão com ri < m será de aproximadamente “ri”

    O gráfico mostra como o tamanho de uma visão cresce em função do número de atributos agrupados...

    O tamanho das visões cresce exponencialmente até atingir o tamanho dos dados brutos no rank

    o qual é o precipício no gráfico, e então pára de crescer

    Este padrão quase bate com o do banco de dados TPC-D: a visão “top” e as visões com 2 atributos agrupados possuem o mesmo “tamanho máximo”, exceto que a visão “ps” tem linhas a menos (0,8M)


    O hipercubo lattice2
    O hipercubo lattice

    A solução tempo e espaço ótima

    Uma questão natural a ser investigada: qual é o tempo médio para uma consulta quando o espaço é mínimo ?

    O espaço é minimizado quando materializamos somente a visão “top”... então, cada consulta leva um tempo “m” para ser executada e o custo de tempo total para todas as 2n consultas é m 2n

    Em um outro extremo nós podemos minimizar o tempo materializando cada consulta

    Entretanto, não ganharíamos muito materializando qualquer visão acima do “precipício” no gráfico... então, devemos evitar materializar aquelas visões...

    A solução tempo ótimo depende do rank ,onde o precipício ocorre, e o rank “j” onde seja maximizado

    O quadro abaixo resume o tempo e espaço para os três pontos estudados

    Estratégias de tempo ótimas para o hipercubo


    O hipercubo lattice3
    O hipercubo lattice

    Extensão para variações no tamanho do domínio

    Suponha agora que os domínios de cada atributo não tenham valores de “r” igualmente prováveis...

    O modelo deve então assumir que para cada dimensão valores são igualmente prováveis mas o número de valores varia, com rivalores na i-ézima dimensão para i = 1, 2,...,n

    Agora o precipício não ocorre em um particular rank mas encontra-se distribuído entre os ranks

    Entretanto, o comportamento fundamental sugerido no gráfico anterior, permanece inalterado


    Conclus es e trabalhos futuros
    Conclusões e trabalhos futuros

    Conclusões

    • Neste artigo investigamos o problema de decidir qual conjunto de células (visões) devemos materializar em um cubo de dados, visando minimizar o tempo de resposta às consultas

    • A materialização de visões é uma estratégia essencial para otimização de consultas em sistemas de apoio à decisão, e a correta seleção de visões a materializar é ponto crítico para o sucesso desta estratégia

    • Usando o banco de dados TPC-D, mostramos porque é importante materializar alguma parte do cubo de dados, mas não todo o cubo

    • A segunda contribuição é um framework lattice que modela análises multidimensionais muito bem

    • O algorítmo ganancioso trabalha neste lattice e seleciona corretamente as visões a materializar, sujeitas a várias restrições... “outros autores mostraram que nenhum algorítmo polinomial pode executar melhor”

    • Finalmente, observamos o caso mais comum de um hipercubo lattice e investigamos a negociação de tempo e espaço em detalhes

    • As visões, em algum sentido, formam uma memória hierárquica com diferentes tempos de acesso. Nas hierarquias de memória convencionais os dados são comumente associados a diferentes memórias de armazenamento (tais como cache ou memória principal) dinamicamente baseadas em padrões de acesso em tempo de execução

      Trabalhos futuros

    • Estamos atualmente investigando estratégias de materialização similares para o cubo de dados


    Obrigado
    Obrigado!

    Walter Coelho Pereira de Magalhães Junior

    [email protected]

    PPGCC/DC - UFSCar

    2009


    ad