Processos Automatizados (batches)

men_at_workDê ao homem certo a ferramenta certa e este operará verdadeiros milagres. Agora, dê a ferramenta errada ao cara errado, e o desastre é certo! Venho insistindo nisto já faz algum tempo, e, creio que não custa batermos nesta tecla uma vez mais.

As bases de dados estão crescendo rápido. E não, não estou falando de big data. As bases OLTP estão crescendo, e, com isso a quantidade de informação a ser escrutinada em busca de conhecimento fica maior a cada dia.

Não dá para vencer esta guerra com um único e simples bando de SELECT’s. Não, não dá!

À medida que nossas bases crescem, crescem também sua complexidade no quesito manutenção e otimização. Fica mais dificil, e lento, extrair resultados estatísticos e gerenciais das mesmas.

Quando falta ferramenta tem de sobrar Inteligência e Criatividade.

Big Data não é a resposta para tudo. Acreditem! Tem coisas que devem ficar no seu bom e velho RDBMS (seja ele qual for).

Dito isto, chega de enrolação, e vamos ao que interessa: Processos Automatizados. O bom e velho batch! Titio começou a trabalhar com TI em 1981. Um precoce 🙂

Mas, a TI de verdade se mostrou para mim por volta de 1984. Em 1986 já tinha que lidar com problemas de gente grande, àquela época tínhamos de ser criativos, afinal, nossos poderosos “minis” não tinham muito mais que 256KB (isto mesmo!) de memória e discos rígidos com seus poderosos 5MB (isto mesmo!). Tudo naquela época baseava-se me processamento OFF LINE ou BATCH.

A “moda” voltou faz uns 8 anos, e, agora mais do que nunca se faz necessário. E voltou até por consequência do aumento das bases de dados.

Mas que raio é isso? É assumirmos que não temos capacidade computacional para processarmos na velocidade da luz tudo o que precisamos.

Tenho vistos consultas em bases de dados com 100, 200, 300 e até 500 milhões de linhas sem a menor necessidade. Sem menor inteligência, ou, sendo mais claro: sem a menor vontade de escrever um “códigozinho” mais bacana.

Um ponto que pretendo dedicar em outro artigo é sobre a real necessidade de manter tantas linhas em produção, na base quente.

Algumas das principais consultas que tenho visto em tabelas, realmente, grandes:

– Vendas acumuladas por período por: cliente, produto, vendedor, unidade de negócio, região, macro e micro região, categoria, subcategoria, etc;resume-7-overused-phrases

– Relacionamento de clientes integrando: propostas, vendas, produtos, devoluções, serviços, contatos, etc;

– Análise de crédito e risco: capacidade de pagamento, compras informadas por parceiros, apontamentos em serviços de crédito, etc;

Poderia ficar citando uma infinidade de outros, mas, acredito que 3 exemplos diferentes possa dar uma dimensão ao que quero propor.

Tentar extrair estas informações de bases quentes, tentando resolver o problema e ao mesmo tempo resumindo-o a um único SQL, não é inteligente. Passa-se uma infinidade de tempo tentando montar este SQL com tantos INNER ‘s e OUTER’s JOIN’s, Subqueries que deixaram o seu RDBMS maluco, e, o usuário desapontado com a performance.

Estou evitando usar nome de RDBMS, pois, isso se aplica a qualquer um. Lembre-se sempre: Dividir para Conquistar, que significa quebrar um SQL problemático em vários performáticos.

Muito bem, mas, a questão aqui é: Voce não deve ir à base quente para informações estatísticas ou mesmo gerenciais que envolvam uma grande massa de dados! Fazendo isso, voce poderá gerar travamento, indisponibilidade, lentidão, e o pior: fregueses insatisfeitos.

Portanto, para criar consultas oriundas de bases grandes temos que usar um pouco mais de tutano, e sermos mais inteligentes e criativos. E aí é que entram os batches, os tais processos automatizados.

Precisamos criar tabelas denormalizadas (ou desnormalizadas) para guardar uma infinidade de dados acumulados de forma inteligente e pragmática. Por exemplo, se precisamos buscar ao longo da régua de tempo a informação de quanto o cliente comprou de cada linha de produto, criamos uma tabela que guarda exatamente isso, e mais, com nome do cliente e nome do produto, enfim, com todas as informações necessárias a ponto de que um único SELECT sem JOIN resolva a consulta.

Um processo batch que roda de tempo em tempo (1 em 1 hora, diário, semanal, conforme sua necessidade) lê a base de dados quente, com todas suas tabelas normalizadas e grava os resultados acumulados nesta única tabela denormalizada. Esta técnica também é conhecida como tabela sumarizada. Isto é muito mais racional, e, economiza toneladas de processamento de dados. Imagine que obter quanto foi vendido de determinada categoria de produto nos últimos 5 anos, seja necessário ler 10 tabelas, e, a principal (com os dados de vendas) tenha 500 milhões de linhas. Se voce tiver 8 chamadas desta consulta em um dia, literalmente, voce estará na roça!

Agora, imagine, implementando um processo automatizado batch, que colete todas as informações de todos os produtos, categorias, clientes, períodos, enfim todas as possíveis combinações e grave estes dados em uma tabela sumarizada, diariamente. Ao invés de ler as tais 500 milhões de linhas, agora, voce não precisaria ler mais que algumas centenas. Faz sentido?

Na maioria dos bancos de dados existem opções para que sejam criadas processos automatizados. No MySQL temos os EVENTs, no Oracle os JOBs. Novamente, quero cobrir isto noutro artigo.

Mas, existem outras formas de criar e gerenciar suas tarefas automatizadas, quais sejam:

A/ Via Sistema Operacional

– Linux/Unix: Através do uso de CRON’s (crontab) é possível programar o sistema operacional para fazer chamadas de scripts SQL, PHP, Perl, Java, Python etc. A grande vantagem do CRON em relação aos batches embarcados nos RBMS é a liberdade de escolha de linguagem de programação, além, é claro da maior flexibilidade e recursos entregues por estas linguagens.

– Windows: Viu? Titio não é tão xiita, escrevi windows certinho 🙂 No windows pode-se utilizar o Schedule, tal como o CRON.

B/ Ferramentas de Batch

– SpringBatch (http://static.springsource.org/spring-batch/): é um framework para processamento de grandes quantidades de dados, em ambiente corporativo e de missão crítica. Não dá para comparar com o CRON. O SpringBatch não é um simples agendador que sai disparando tarefas. Está mais para um orquestrador, que permite total controle das atividades (batches) rodando embaixo de seu servidor de tarefas. Os códigos fonte podem ser escritos em JAVA, trabalha bem com o conceito de reusabilidade de código, SOA, filas, plataforma WEB. Vale a pena conferir. O SpringBatch faz parte do famoso framework de desenvolvimento java Spring, mantido pela SpringSource.

– Quartz (http://www.quartz-scheduler.org): Ao contrário do SpringBatch que faz parte de uma plataforma de desenvolvimento, o Quartz é o produto, o meio e o fim. Em outras palavras: mais especializado e focado. Nos testes que fiz, fiquei impressionado com a quantidade de opções e parametrizações. Realmente, este cara é para missão crítica e para alto volume de dados. Gratuito. Pode ser clusterizado, tem balanceamento de carga e failover. Assim como o SpringBatch, pode rodar qualquer classe Java.

Existem muitos outros, no meu dia-a-dia, eu uso o bom e velho Crontab do sistema operacional, e, obviamente o Event do MySQL e o Job do Oracle. Graças ao grande Lord Darth Vader nunca tive que usar o schedule do windows 🙂 (não poderia faltar esta né?). Se alguém pensou em PHPScheduler não prestou atenção ao artigo -:)

Atualmente, venho utilizando o SpringBatch e o Quartz, sendo que este último conquistou meu respeito pela sua simplicidade e recursos.

Não consigo pensar em uma empresa e/ou entidade que não tenha algumas tarefas que possam ou mesmo que devam ser processadas em batch. E, não tenho dúvidas que os ganhos ao lançar mão desta prática são muitos: performance, maior controle dos processos, segurança, e mais importante: fregueses felizes!

Deixe um comentário

O seu endereço de e-mail não será publicado.

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.