Estratégias para o Carregamento Massivo de Dados num Data Warehouse

Estratégias para o Carregamento Massivo de Dados num Data Warehouse André Vilaça e Jorge Abreu Departamento de Informática, Escola de Engenharia, Universidade do Minho Campus de Gualtar, 471-57 Braga, PORTUGAL {andrevilaca, jorgeabreu.lesi}@gmail.com Abstract. O povoamento é uma das actividades mais importantes de um sistema de data warehousing. A criticidade desta actividade está muitas vezes associada ao enorme volume de dados envolvido. Quanto maior é este volume, mais tempo é necessário para o seu processamento e para o seu consequente carregamento no data warehouse. Porém, o tempo disponível para esta operação (janela de oportunidade) é finito e, por vezes, torna-se insuficiente, por exemplo, quando se verificam falhas no processo. Assim, neste artigo, abordam-se três estratégias gerais, e respectivas variantes, para melhorar o carregamento de dados num data warehouse com particular ênfase em tabelas de factos com o objectivo de reduzir o seu tempo de processamento, permitindo assim maiores aberturas em termos de janela de oportunidade. Através da realização de testes intensivos, são ainda exploradas possíveis optimizações a essas estratégias. Keywords: Carregamento, ETL, Bulk Loading, Prepared Statements, Batches. 1 Introdução Diariamente, as empresas com grande volume de dados a processar pelos seus sistemas de povoamento de Data Warehouses debatem-se com grandes problemas de optimização. Os problemas surgem ao longo das três fases dos sistemas de povoamento de um data warehouse, também denominados de sistemas de ETL (do inglês Extract- Transform-Load), devido principalmente ao constante aumento da quantidade e complexidade da informação a processar [15]. Os sistemas de ETL são os responsáveis pela recolha da informação proveniente das fontes de dados, pelo seu tratamento e posterior carregamento nos sistemas de data warehousing, executando de forma parcialmente automática esta complicada passagem da informação dos sistemas operacionais (organizados segundo um modelo relacional) para os sistemas de data warehousing (organizados segundo um modelo dimensional) [6]. É vital para o sucesso de um sistema de ETL que todo o processo seja executado durante a janela de oportunidade (espaço de tempo, habitualmente diminuto, disponível para a execução das 3 fases de ETL), prevendo desde logo possíveis falhas

em sub-processos, e consequente reinício dos mesmos, acessos impossíveis às fontes ou complexidades na transformação dos dados. De facto, a tarefa de transformação da informação é a mais complexa em todo o processo, devido principalmente ao facto de ser aquela que mais dependente está das regras de negócio envolvidas. Por esse facto, existe muito trabalho efectuado ao nível do fluxo de dados, tendo em vista a optimização desta etapa. Já nas fases de Extracção e Carregamento, as estratégias de optimização disponibilizadas revelam-se mais genéricas, ou seja, são facilmente aplicáveis a qualquer sistema. Desta forma, torna-se mais aliciante e motivador o estudo destas últimas. Neste caso de estudo, a atenção recai sobre o processo de carregamento. A etapa final de qualquer processo de ETL consiste no carregamento dos dados para as estruturas dimensionais, e é tida como uma das operações críticas do data warehouse. Este carregamento não ocorre continuamente, mas sim num curto espaço de tempo, não podendo haver lugar a atrasos, e envolvendo um grande volume de informação [3]. No entanto, e apesar da sua criticidade, o carregamento dos dados é muitas vezes menosprezado aquando da construção dos sistemas de ETL [12]. De facto, este menor interesse revelado por esta etapa deve-se à aparente simplicidade da mesma, que consiste na passagem dos registos tratados da área de retenção para o data warehouse. No que concerne à optimização da operação de loading, ao serem implementadas estratégias que visam a diminuição do tempo de processamento e carregamento dos dados, liberta-se desta forma tempo precioso para as outras etapas de ETL. Da mesma forma, previnem-se também possíveis baixas de performance que possam ocorrer aquando de aumentos consideráveis no volume de dados a integrar, num futuro próximo. Com este artigo, pretende-se então abordar algumas técnicas de carregamento de grandes quantidades de dados num data warehouse, com particular ênfase nas tabelas de factos (devido à enorme quantidade de registos envolvidos), de forma a permitir uma diminuição significativa do tempo de execução desta tarefa e, consequentemente, do tempo de execução de todo o processo de ETL. Pretende-se igualmente analisar o comportamento destas estratégias e verificar se revelam quebras de performance para determinados volumes de dados. O restante artigo está organizado da seguinte forma. No capítulo a seguir são abordadas três estratégias de carregamento de dados. Na terceira secção, apresentamos algumas dicas de optimização que podem ser aplicadas a cada estratégia. No capítulo 4 descrevem-se o ambiente de testes e as fontes de dados utilizadas. Os testes efectuados, respectivos resultados, e consequente análise, estão presentes na secção 5. Por último, o capítulo 6 refere as conclusões retiradas da elaboração deste estudo, e os aspectos que poderão ser alvo de aperfeiçoamento. 2 Estratégias de Carregamento de Dados Muitas das soluções para a redução do tempo de processamento em inserções de grande volume de dados em tabelas passam pela eliminação temporária dos índices criados sobre essa tabela e posterior reconstrução dos mesmos, conseguindo-se

ganhos consideráveis. Assim, muito é o trabalho desenvolvido nesta área, com vista à optimização do tempo de reconstrução dos índices. Neste artigo, serão estudadas soluções limpas da actuação de índices, ou seja, os índices são eliminados, não havendo assim preocupação com a sua influência no carregamento de dados. Obviamente, esta opção revela algumas vantagens, pois não existe preocupação com o desempenho das queries lançadas sobre as tabelas, onde os índices desempenham um papel de extrema importância. Consequentemente, existirão elevados ganhos em termos de performance, sendo esse ganho directamente proporcional à complexidade do índice (quanto maior a complexidade do índice, maiores serão os ganhos conseguidos ao ignorar os mesmos). No entanto, sempre que necessário, irá ser referida a título exemplificativo a sua influência. 2.1 Estratégia Convencional Grande parte dos sistemas de data warehousing adoptam esta estratégia, que consiste no carregamento individual e sequencial dos registos para as estruturas do data warehouse, imediatamente após o tratamento do mesmo. Não existe uma diferenciação entre a fase de Transformação e a fase de Carregamento, visto que cada registo é integrado no data warehouse no momento em que as transformações sobre o mesmo terminam. Esta estratégia é típica de data warehouses assíncronos ou data warehouses em tempo real, como facilmente é perceptível, dadas as características e exigências destes. A instrução de SQL INSERT assume o principal papel nesta estratégia, dado que o carregamento de cada registo é feito através da mesma, revelando assim algumas parecenças com os sistemas operacionais, tipicamente caracterizados pela sua optimização para a inserção de registos. O carregamento é efectuado da forma mais trivial, recorrendo quase unicamente a simples instruções de inserção na tabela de factos. A complexidade desta estratégia prende-se com o facto de o motor de base de dados necessitar de efectuar um conjunto de operações de forma a determinar a melhor forma de executar a instrução pedida (query plan), antes de proceder à inserção do registo. Para tal, o motor de BD executa as seguintes tarefas [14]: Análise da sintaxe da query; Identificação de existência de índices, constraints ou triggers; Identificação da localização da tabela destino, bem como dos seus índices; Determinação dos atributos envolvidos na query; Definição da melhor forma de efectuar a query. Como é de fácil percepção, na inserção de grandes quantidades de registos, todo este processo de preparação da query começa a ter um peso significativo, tornando-se uma opção de fraca viabilidade. Como forma de colmatar este problema podemos recorrer ao uso de Prepared Statements.

2.2 Estratégia com uso de Prepared Statements O uso de prepared statements constitui mais um dos métodos de optimização de querying. Segundo a literatura actual, sempre que uma query é usada várias vezes, podemos optimizar significativamente o seu desempenho, recorrendo a prepared statements [14, 11]. Como abordado na estratégia anterior, em cada query de inserção é criado um novo plano de execução, tornando grande parte do trabalho do motor de base de dados repetitivo. É neste ponto que as prepared statements são mais eficientes, fazendo uma reutilização do mesmo plano de execução para todas as utilizações da query. Por exemplo, na abordagem anterior, para 1 inserções, seriam realizados 1 planos de execução contra apenas um plano aquando do uso de prepared statements. No entanto, com o uso de prepared statments, o motor de base de dados tem de disponibilizar recursos para guardar o plano de execução e, dependendo do tipo de detalhe da query, terá ainda de garantir a validade do plano de execução caso surjam mudanças na BD [14]. No caso em estudo, e visto que o número de tabelas de factos é reduzido, este factor negativo não se aplica, pois apenas é realizada uma instrução de inserção, sendo o seu plano válido desde o começo até ao final da operação de carregamento em cada tabela de factos. 2.3 Estratégia de Bulk Load A estratégia de bulk load é uma das estratégias mais eficazes para a inserção massiva de dados e está implementada nativamente na maioria dos motores de Bases de Dados conhecidos. Consiste numa boa alternativa à inserção no data warehouse de um registo de cada vez, como se de um sistema transaccional se tratasse. A maior vantagem desta estratégia é a possibilidade de, paralelamente, desactivar o logging da base de dados e carregar os registos. De facto, a escrita do log provoca uma grande sobrecarga em operações de leitura/escrita, e pode revelar-se desnecessária em data warehouses [6]. Pouco se sabe sobre o seu método de funcionamento. As ferramentas de bulk load são vistas como caixas negras que geram programas que não são facilmente costumizáveis [1]. Esta falta de informação deve-se em grande parte às diferentes formas de implementação utilizadas por cada empresa desenvolvedora dos sistemas de gestão de bases de dados. Entre a literatura actual, revelou-se um grande obstáculo encontrar fontes credíveis que fornecessem informações sobre a especificação do método de funcionamento/implementação das estratégias de bulk load. Por norma, o tipo de informação disponível prende-se mais com factores de utilização ou formas de optimização. No que ao Oracle diz respeito, sabe-se que é usado um conjunto privado de buffers para inserir as páginas do disco, contendo os novos registos, na tabela. Só após a confirmação do fim da operação de inserção é que os novos registos ficam disponíveis para leitura na tabela [2]. A estratégia de bulk load utiliza como única fonte de dados um simples ficheiro de texto no sistema de ficheiros. Estes ficheiros de texto podem ser de dois formatos: comprimento fixo e delimitado. No primeiro são especificados todos os campos

existentes no ficheiro, bem como o nome do ficheiro, onde começa cada campo, o seu comprimento e o tipo de dados, sendo por vezes fornecida também a posição final. Já os ficheiros de texto no formato delimitado incluem separadores (por norma vírgula, ponto-e-vírgula, pipe ou tabulação) entre cada campo, como alternativa à indicação da posição de início e fim de cada campo. A partir do momento em que o ficheiro segue uma destas delimitações, o processador de bulk load consegue abrir o ficheiro, ler os registos presentes no ficheiro e efectuar a sua integração no data warehouse [6]. Uma das limitações da estratégia de bulk é o facto de não permitir a manipulação/tratamento dos dados durante o processo, pelo que todos os tratamentos desejados devem ser efectuados previamente, na fase de Transformação do processo de ETL [4]. Para que se obtenha o máximo de desempenho possível no carregamento bulk de um ficheiro, é aconselhado que o mesmo seja copiado previamente para a mesma máquina em que se encontra o servidor de BD. Desta forma, o desempenho da operação não fica sujeita a qualquer tipo de limitação de transferência da rede [4]. Por fim, é de salientar ainda algumas das configurações que, por exemplo, o bulk insert (implementação do SQLServer) considera aquando da sua utilização mais básica. O bulk insert, independentemente do tamanho/cardinalidade do ficheiro, carrega todos os dados numa única transacção [1], ou seja, num ficheiro de 1 milhão de entradas, a confirmação (commit) da inserção dos dados só é efectuada no final de tudo. Isto pode ser visto como uma vantagem por muitos utilizadores, pois evita sucessivos commits. No entanto, tem a desvantagem de, no caso de ocorrer um erro no processo, todos os dados voltam a ser retirados (rollback), regressando ao início da operação, o que pode ter um grande impacto no tempo total de realização do processo. No entanto, este problema pode ser parcialmente resolvido com a utilização de batches (lotes de registos). A existência de triggers revela-se como um dos responsáveis pela degradação na importação de dados. No entanto, nem sempre nos queremos ver livres deles. Por isso, deve-se ter em atenção o facto do bulk insert ter a particularidade de, por omissão, os desactivar. Um outro aspecto a ter em consideração é a presença de valores nulos, em que um simples Insert mantém o atributo como nulo. Já o bulk insert, caso exista um valor por omissão para o atributo a nulo, irá colocar este em substituição do nulo [9]. 3 Dicas para um melhor desempenho Independentemente dos mecanismos de inserção utilizados, existe uma variedade de outros aspectos a ter em consideração que podem oferecer uma melhoria significativa ao processo de carregamento de dados. De seguida, apresentamos os que consideramos mais influentes. Como já foi referido, um dos principais, senão o principal factor de degradação na inserção de grandes volumes de dados, passa pela existência de índices na tabela de factos. Nesta situação, terá de se proceder à actualização dos mesmos ao longo da inserção, operação esta que com o passar do tempo vai ficando cada vez mais penosa

de realizar, sendo por isso aconselhável, à priori, proceder à destruição dos índices e posteriormente reconstruir os mesmos [6, 13]. Contudo, nem sempre esta degradação está presente, ou seja, no caso de um primeiro povoamento de uma tabela em que exista, por exemplo, um índice cluster, se se proceder à ordenação prévia dos dados sob a mesma forma, a diferença de desempenho pode não ser relevante [8]. Os triggers representam outro aspecto a levar em consideração. Os triggers são procedimentos que são executados na ocorrência de um evento de inserção, actualização ou remoção sobre uma tabela [6]. Dependendo do tipo de triggers existentes, estes podem provocar grandes sobrecargas no processamento. Assim sendo, deve-se, sempre que possível, evitar o seu uso em carregamentos de dados. Tomando como exemplo um simples trigger que faz o log para outra tabela de todas as operações efectuadas sobre a tabela em que estamos a proceder à inserção. Na prática, com a presença deste trigger, seriam realizadas o dobro das inserções. As constraints sobre determinados campos podem, em certos casos, ser um ponto a ter em consideração. No entanto, e lembrando que o tema de estudo são as estratégias para inserções em data warehouses, as constraints podem ser retiradas sem qualquer problema, pois os dados para inserção no DW são provenientes de um sistema totalmente controlado (ETL) [6]. Durante o processo de ETL, o processo de surrogate key pipeline 1 assegura a integridade referencial. Assim sendo, durante a inserção, esta verificação pode ser temporariamente desactivada para permitir um melhor desempenho. O tipo de log da BD pode ter um impacto relevante na eficácia do processo de inserção, podendo-se usar um tipo de log mais redutor durante mesmo, evitando assim um overhead adicional de escrita e processamento. A frequência com que os commits são efectuados contribui também para o desempenho das estratégias de carregamento. Nos termos de estudo, a execução de confirmações a cada registo inserido pode provocar um overhead excessivo, degenerando todo o processo de inserção. Segundo [16], executar o commit após a inserção de um conjunto de vários registos, pode levar a uma melhoria de desempenho até 1 vezes. Temos também a abordagem de processamento paralelo. Com este tipo de abordagem podemos tirar partido das máquinas multi-processador. Para tal pode-se dividir, por exemplo, uma fonte de dados em formato de texto, em várias fontes, e correr várias instâncias do mecanismo de inserção em paralelo. Em SDW, tipicamente existe uma janela de oportunidade para proceder à inserção de novos dados. Como tal, durante esse período, o data warehouse está 1% disponível para as inserções, o que deixa em aberto a possibilidade de controlarmos convenientemente o tipo de locks que são efectuados durante todo o processo de alimentação. Assim, o uso de lock à tabela, em vez de locks linha a linha, pode também oferecer uma melhoria de desempenho no carregamento de dados. Muitos mecanismos de carregamentos de dados inserem, por omissão, todos os dados de uma vez só, ou seja, são inseridos numa única transacção. Neste caso, se a transacção falhar, independentemente da quantidade de dados inserida, terá de se fazer rollback a toda a transacção. Este problema pode ser ultrapassado recorrendo ao 1 Processo de substituição das chaves naturais operacionais dos registos da tabela de factos pela chave do registo correspondente na dimensão [7].

uso de lotes de registos (batches). Com esta abordagem, pode-se especificar a quantidade de registos em cada batch de inserção. Desta forma, fragmenta-se uma grande e pesada transacção em pequenas e rápidas transacções. No caso de falha de uma das transacções, isso não implica fazer o rollback às transacções já terminadas com sucesso, podendo-se retomar o processo de inserção a partir do fim da última transacção bem sucedida. 4 Caracterização das Fontes e do Ambiente de Testes 4.1 Fontes de Dados Na impossibilidade de utilizar dados reais, provenientes de um sistema de povoamento já completamente implementado, tornou-se imperativa a simulação de grandes quantidades de registos, que conseguissem representar o melhor possível a informação contida num sistema real. Uma vez que as tabelas de factos contêm habitualmente valores inteiros, referentes às chaves de substituição e às medidas utilizadas, revela-se adequada a utilização de registos compostos unicamente por valores inteiros. Assim sendo, cada registo utilizado é composto por 11 atributos inteiros, com os seguintes nomes e gamas de valores: A1(1 a 5M), A2(5 a 2), A3(1 a 1), A4(1 a 2), A5(5 a 25), A6(2 a 8), A7(1 a 3), A8(1 a 1), A9(1 a 2), A1(1 a 5), A11(1 a 7). Uma vez que o objectivo consiste no estudo de estratégias de carregamento de elevados volumes de dados, é necessário testar cada estratégia para diferentes quantidades de registos. Para isso, foi criado um único ficheiro contendo 5 milhões de registos. Depois, estes 5 milhões de registos foram divididos por diversos outros ficheiros, com cardinalidades variáveis: 1 mil, 2 mil, 4 mil, 6 mil, 8 mil, 1 milhão, 2 milhões, 4 milhões, 6 milhões, 8 milhões, 1 milhões, 2 milhões, 3 milhões, 4 milhões, 5 milhões, 6 milhões, 7 milhões, 8 milhões, 9 milhões, 1 milhões, 2 milhões, 3 milhões e 4 milhões. Para a criação destes 24 ficheiros de texto foi usado um programa Java que, recorrendo à geração aleatória de valores, consegue assim simular os dados pretendidos. 4.2 Ambiente de Testes Todos os testes foram realizados na mesma máquina, tendo sido feitos todos os possíveis para simular exactamente as mesmas condições para cada teste. Em termos de hardware, foi utilizada uma máquina com processador Dual Core Intel Pentium E214, com frequência de relógio 1.6GHz, cache L1 32KB por core e cache L2 de 1MB; memória RAM 2x Kingston 1GB DDR2-667 double sided, CL5; disco rígido 3.5 Hitachi HDT72525VLA38 SATA-II de 25GB, 72RPM com 8MB de buffer.

Já no que ao software diz respeito, o Sistema Operativo instalado foi o Microsoft Windows XP Professional Service Pack 2, sendo o Sistema de Gestão de Bases de Dados utilizado o Microsoft SQL Server 25, Standard Edition. De referir apenas que foram realizados alguns testes complementares utilizando um disco externo 2.5 Western Digital, 54 RPM, tendo sido decidido abdicar deste, após a verificação de piores performances. O carregamento foi então realizado numa nova partição formatada do disco interno. 5 Avaliação Experimental 5.1 Melhoria das estratégias simples Para avaliar a performance de cada uma das estratégias expostas anteriormente, é então necessário proceder à realização de testes em condições idênticas para diferentes volumes de dados. Após a realização dos primeiros testes, verificou-se uma performance abaixo do esperado para as estratégias convencional e usando Prepared Statements. Assim, e aplicando desde logo algumas das optimizações propostas, procedeu-se à comparação (ver Fig. 1) dos tempos de carregamento da estratégia convencional básica (A1), em que se procede à confirmação (commit) da inserção a cada registo inserido, e a estratégia convencional ligeiramente optimizada (A2), em que se realiza o commit depois de finalizada toda a inserção da fonte em causa. Da mesma forma, comparamse também o desempenho da estratégia de Prepared Statements básica (B1) e optimizada (B2). t(min) 14 12 1 8 6 4 2 1 5 1 A1 A2 t(min) 14 12 1 8 6 4 2 1 5 1 B1 B2 Fig. 1. Impacto da realização de commit apenas no final do carregamento, comparativamente com commits após a inserção de cada registo. Verifica-se um ganho na ordem dos 5% em cada uma das estratégias quando se realiza apenas um commit no final do carregamento, como aliás era de esperar. Assim sendo, estas estratégias optimizadas passam agora a ser usadas para a realização dos testes seguintes. Denote-se que, para uma melhor compreensão das figuras presentes, adopta-se a seguinte nomenclatura: Carregamento convencional: estratégia A; Carregamento com Prepared Statements: estratégia B; Carregamento Bulk: estratégia C.

5.2 Carregamentos simples Por carregamento simples, entenda-se o carregamento dos registos dos ficheiros de texto para a tabela de factos destino, numa única transacção. A análise do desempenho das três estratégias anteriormente mencionadas é efectuada realizando vários testes para cada um dos diferentes volumes de registos e para cada estratégia. Para que os resultados demonstrem uma maior precisão, foram repetidos os testes para os volumes de dados mais pequenos, sendo o valor referido obtido pela média. t (min) 14 12 1 8 6 4 2 7 6 5 4 3 2 1 1 2 3 4 5 6 7 8 9 1 5 1 15 2 25 3 35 4 A B C Fig. 2. Comparação das Estratégias A, B e C, para o carregamento simples. As três estratégias revelam um comportamento linear ao longo da variação da cardinalidade. Existe um claro baixo desempenho da estratégia convencional, comportamento que se agrava com o aumento do volume de dados. Com o uso de prepared statements consegue-se um ganho superior a 3% relativamente à estratégia anterior, a partir de 1M de registos. No entanto, a estratégia de Bulk bate claramente qualquer uma das outras, conseguindo ganhos inesperados de 8-9% e 86-93%, a partir de volumes de dados de 1M de registos, quando comparado com a estratégia convencional e de prepared statements, respectivamente. Tomando como exemplo o carregamento de 2 milhões de registos, o carregamento convencional demora mais de 2h, sendo reduzido para quase 14h usando prepared statements, e com a estratégia de Bulk o carregamento demora apenas 1h2min. Para uma menor quantidade de registos, o Bulk continua a revelar-se como a melhor opção, apesar de os ganhos serem consideravelmente menores. 5.3 Optimização com recurso a lotes de registos Após a realização de alguns testes ocasionais às estratégias A e B, verificaram-se melhorias consideráveis aquando da utilização de batches durante o carregamento.

Tornou-se então essencial, para a correcta análise do desempenho destas estratégias, a utilização de lotes de registos. É de salientar que, de forma a melhorar o desempenho das estratégias A e B com recurso a batches, é executado um commit para a tabela de factos após o carregamento de cada batch. Esta modificação consegue um ganho variável de alternativa para alternativa, mas sempre superior a 2%, e conseguindo mesmo ser 5% melhor em alguns casos. De seguida, elaborou-se um estudo intensivo do comportamento dos primeiros carregamentos, comparando o carregamento simples com o carregamento através de diferentes batches, para cada estratégia. Para uma melhor avaliação do comportamento do carregamento via batches, é vital experimentar diferentes cardinalidades para cada lote, pelo que foram então testadas cinco alternativas: batches variáveis de 1% da cardinalidade original do ficheiro, de 5%, 1% e também batches de tamanho fixo de 5 mil e 1 mil registos. Mais alguns testes experimentais foram executados, no entanto, apenas serão disponibilizados os resultados de maior relevância. t(min) 14 12 1 8 8 6 4 2 1 2 3 4 5 6 7 8 9 1 x 1 6 4 2 5 1 15 2 25 3 35 4 A A(1%) A(5%) A(1%) A(5K) A(1K) Fig. 3. Comportamento das alternativas da estratégia convencional, com uso de batches. Como se pode verificar na Fig. 3, não foi possível efectuar os testes para as alternativas que utilizam batches de 1%, 5% e 1% a partir de determinados volumes de dados. Esta impossibilidade deveu-se ao consumo excessivo de memória, ao qual a máquina de testes não conseguiu dar resposta, cancelando o carregamento quase de imediato. Comparando as estratégias com batches de tamanho fixo, verifica-se que o uso de 5 mil registos por lote se revela melhor do que lotes de 1 mil registos. No entanto, para volumes de dados inferiores, o resultado é inverso, ou seja, batches de 1 mil são preferíveis aos de 5 mil, apesar de as diferenças serem muito ligeiras. Como já referido anteriormente, a utilização de batches bate significativamente a estratégia simples, conseguindo para um volume de 2 milhões de registos, por exemplo, uma passagem de mais de 21 horas de carregamento para menos de 6 horas (redução de mais de 7% do tempo total de carregamento).

t(min) 9 8 7 6 5 4 3 2 1 6 5 4 3 2 1 1 2 3 4 5 6 7 8 9 1 x 1 5 1 15 2 25 3 35 4 B B(1%) B(5%) B(1%) B(5K) B(1K) Fig. 4. Comportamento das alternativas da estratégia prepared statements, com uso de batches. No que diz respeito à estratégia de prepared statements, não foi novamente possível executar testes com 1%, 5% e 1% do volume total de dados, quando a cardinalidade de cada batch excedia os 1 mil registos. Seria necessário aumentar os 2GB de memória física da máquina de testes para os conseguir levar a cabo. Nesta estratégia, os lotes de 1 mil registos revelam-se sempre melhores que os lotes de 5 mil, apesar de as diferenças serem muito pequenas. Novamente, comparando com o carregamento sem batches, são conseguidos ganhos de aproximadamente 72% (redução de 14 horas para 4 horas), isto para um volume total de 2 milhões de registos. Mesmo para volumes de dados menores, o ganho médio conseguido através do uso de batches de 1 mil registos, é sempre superior a 7%. t(min) 18 16 14 12 1 8 6 4 2 1,5 1,25 1,75,5,25 1 2 3 4 5 6 7 8 9 1 x 1 5 1 15 2 25 3 35 4 C C(1%) C(5%) C(1%) C(5K) C(1K) Fig. 5. Comportamento das alternativas da estratégia de bulk loading, com uso de batches.

Nos testes realizados à estratégia de Bulk Loading, não se verificaram quaisquer problemas ao nível da memória física, uma vez que esta estratégia carrega directamente as páginas do disco para a tabela de factos, não havendo necessidade de colocar os registos em memória. Qualquer uma das alternativas com batches revelam um melhor desempenho relativamente ao bulk simples, sendo as diferenças entre cada uma delas relativamente pequenas. As estratégias de batches de dimensão variável apresentam-se como as melhores nos testes, com clarividência para o bulk loading com batches de 1%, verificando-se ainda um comportamento muito instável quando os lotes são constituídos por 1 mil registos ou menos. Note-se que, contrariamente ao carregamento simples, os carregamentos com uso de batches não revelam um comportamento linear, o que poderá demonstrar uma certa influência da máquina de testes, em particular do comportamento do disco. Regressando agora ao confronto entre as estratégias de carregamento, é importante comparar a utilização de batches para cada uma das estratégias. Ora, uma vez que não existem dados suficientes para a comparação do carregamento através de batches variáveis de 1%, 5% e 1% do total de registos, irão apenas ser analisados os carregamentos com lotes fixos, no caso, de 1 mil e 5 mil registos. t(min) 9 8 7 6 5 4 3 2 1 18 15 12 9 6 3 2 4 6 8 1 5 1 15 2 25 3 35 4 A(5K) A(1K) B(5K) B(1K) C(5K) C(1K) Fig. 6. Comparação das estratégias de carregamento com batches de dimensão fixa. Como já havia sido denotado no carregamento simples, também o carregamento com recurso a lotes de registos tem um comportamento semelhante. Verifica-se uma clara diminuição no tempo de processamento com prepared statements, relativamente à estratégia convencional, e uma melhoria ainda mais notável quando é aplicado o Bulk Loading. Fornecendo valores mais concretos, o ganho obtido quando se utilizam prepared statements reside nos 3-33% a partir de um volume total de 4 milhões de registos. Por sua vez, a estratégia de Bulk Loading representa ganhos médios de 79% e 87% relativamente ao carregamento com prepared statements e convencional, respectivamente.

5.4 The best of the best Para finalizar, efectua-se agora uma comparação entre a melhor alternativa testada para cada uma das estratégias de carregamento de dados. Como foi possível verificar na subsecção anterior, as estratégias que revelaram um melhor desempenho foram a estratégia convencional com recurso a batches de tamanho fixo 5 mil registos - A(5K); a estratégia com prepared statements recorrendo também a batches, de cardinalidade fixa 1 mil registos - B(1K); e ainda a estratégia de bulk loading com batches de tamanho variável, correspondente a 1% do número total de registos - C(1%). t(min) 7 6 5 4 3 2 1 5 1 15 2 25 3 35 4 A(5K) B(1K) C(1%) Fig. 7. Desempenho de cada uma das melhores alternativas testadas. Mesmo tendo por base de comparação a melhor implementação de cada alternativa, verifica-se uma esmagadora superioridade da estratégia de Bulk sobre as restantes. Concretizando, os ganhos obtidos por este tipo de carregamento rondam em média os 82 e 88 pontos percentuais, relativamente às estratégias B(1K) e A(5K), respectivamente. Esta diferença percentual corresponde, em tempo efectivo, e para um total de 4 milhões de registos, à passagem de mais de 11 horas de carregamento para 7 horas e meia (através do uso de Prepared Statements) ou 1 hora e 2 minutos no caso da utilização de bulk. Ainda assim, a estratégia B(1K) revela uma melhoria sobre a convencional, que varia entre 31 e 39% conforme o volume de dados testado. Por uma questão meramente indicativa, comparando a abordagem que revelou a pior performance com o carregamento de 2 milhões de registos através da melhor estratégia, verifica-se um ganho a rondar os 97%. Na primeira, o carregamento demoraria mais de 21 horas, enquanto na segunda bastariam uns meros 4 minutos para que todo o processo estivesse concluído. Estes resultados demonstram que o frequente desprezo demonstrado em relação à última fase do processo de povoamento dos sistemas de data warehousing, aquando da sua implementação, origina frequentemente uma grande deterioração do desempenho no carregamento dos dados para o data warehouse quando se verifica um grande aumento do volume de dados a inserir.

6 Conclusões e Trabalho Futuro Neste artigo, abordámos o problema do carregamento de elevados volumes de dados para as tabelas de facto de um data warehouse, tendo como fonte de dados ficheiros de texto. Apresentámos três tipos de estratégias para esse carregamento, bem como diversas formas de optimização das mesmas, com vista à redução do tempo levado a cabo por essa tarefa. Os testes experimentais demonstram que a estratégia de carregamento Bulk se revela notoriamente como a melhor para o caso testado, sendo a utilização de batches uma adição importante para a sua optimização. No entanto, não foi possível identificar o tamanho ideal de cada batch, devido a limitações de testes. Para os volumes de dados testados, não se verificaram pontos claros de degradação em qualquer uma das estratégias testadas, apesar de haver uma ligeira percepção de uma pioria na performance de algumas das estratégias, o que indica que estas poderão degenerar a partir de volumes de dados superiores aos testados. Num futuro próximo, pretende-se aplicar os testes a diferentes sistemas reais de povoamento, que utilizam estratégias com um maior nível de optimização, de forma a verificar se os resultados obtidos se mantêm válidos. Outra estratégia a comparar passa pela utilização do comando Import, presente no DB2, da IBM, que consiste basicamente numa optimização da estratégia convencional [5]. Pretendemos, adicionalmente, aprofundar os testes realizados, em especial para a determinação do tamanho ideal de cada lote de registos para a estratégia que implementa o Bulk Loading, de forma a criar um modelo de recomendação, em que, tomando como ponto de partida a estimativa do volume de dados para carregamento, seja possível indicar os parâmetros que permitam um desempenho óptimo. Referências 1. Amer-Yahia, S. and Cluet, S. 24. A declarative approach to optimize bulk loading into databases. ACM Trans. Database Syst., vol. 29, pp. 233--281 (24) 2. Bridge, W., Joshi, A., Keihl, M., Lahiri, T., Loaiza, J., MacNaughton, N.: The Oracle Universal Server Buffer Manager. In Proceedings of the 23rd International Conference on Very Large Data Bases (VLDB 97, Athens, Greece, Aug.). pp. 59--594 (1997) 3. Fenk, R., Kawakami, A., Markl, V., Bayer, R., and Osaki, S.: Bulk Loading a Data Warehouse Built Upon a UB-Tree. In Proceedings of the 2 international Symposium on Database Engineering & Applications, pp. 179--187. IDEAS. IEEE Computer Society, Washington (2). 4. Henderson, K.: The Guru's Guide to SQL Server Architecture and Internals. Addison Wesley, USA (23) 5. IBM, http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.l uw.admin.cmd.doc/doc/r834.html 6. Kimball, R., Caserta, J.: The Data Warehouse ETL Toolkit: Practical Techniques for Extracting, Cleaning, Conforming and Delivering Data. John Wiley & Sons, Indianapolis (24) 7. Kimball, R., Reeves, L., Ross, M., Thornthwaite, W., Becker, B.: The data Warehouse Lifecycle Toolkit: Practical Techniques for Building Data Warehouse and Business Intelligence Systems, Second Edition. Wiley Publishing, Inc., Indianapolis (28).

8. Microsoft Developer Network, http://msdn.microsoft.com/en-us/library/ms177445.aspx 9. Microsoft Developer Network, http://msdn.microsoft.com/en-us/library/ms187887.aspx 1. Microsoft Developer Network, http://msdn.microsoft.com/en-us/library/ms188365.aspx 11. Parsian, M.: JDBC Recipes: A Problem-Solution Approach. Apress, USA (25) 12. Raghavan, V. V. 1996. Loading the Data Warehouse Across Various Parallel Architectures. In Proceedings of the 22th international Conference on Very Large Data Bases, Morgan Kaufmann, San Francisco (1996) 13. Rausch, N.A. and Wills, N.J.: "Super Size It!!! Maximize the Performance of Your ETL Processes." Proceedings of the SAS Global Forum 27 Conference, (28) 14. Shirazi, J.: Java Performance Tuning, 2nd Edition. O'Reilly & Associates, Inc., California (23) 15. Venugopal, V., Bhat, S.G., Fang, J.: Performance Driven Data Integration: an optimized approach. SAS Global Forum (27) 16. Wilkins, B.: Tips for improving INSERT performance in DB2 Universal Database, IBM (24)