A automação chegou ao Data Warehouse!

Tornar os dados prontos para uso pode se tornar um grande desafio corporativo, principalmente àqueles que ainda não sabem como prosseguir com o volume alto de dados captados diariamente. Nesse sentido, vale pontuar que não importa exatamente onde os dados vão estar, mas se estão preparados ou não para serem utilizados. Há infindáveis mecanismos e ferramentas para preparação de um repositório unificado de dados em forma de Data Warehouse (DW) ou Data Lake (DL).

Antes de escolher a estrutura é importante saber qual a destinação adequada para os dados, pois isso determina o tipo de "armazém" que se deseja criar e manter. DW e um DL são estruturas para dados com destinações distintas e não exatamente intercambiáveis. Ou seja, não é algo que se escolhe pelo calor do mercado; é pela destinação! Muitas e muitas companhias estão adotando Data Lakes como estruturas de dados para soluções analíticas que precisam garantir a integridade referencial. Mas será que esse requisito é mais bem atendido por essas soluções? Dito isso, antes de automatizar o destino dos dados é importante definir o que a companhia precisa.

O uso do Data Warehouse e Data Lake

Afinal, para que serve o Data Warehouse? O Data Lake é seu substituto? Cabe a companhia ter as duas estruturas? Migrar do DW para o DL ou o contrário? Quando escolher um, outro ou ambos?

Longe de ser um artigo sobre cada detalhe destas estruturas, a ideia é passar ao menos uma visão de onde se encaixa cada peça. Se fosse possível resumir os pontos principais de um DW, possivelmente incluiriam: DW hospeda grandes volumes de dados estruturados em formatos padrão; atua como repositório de dados para análises, pesquisas e insights de negócio; pode conter dados operacionais de diversos sistemas, incluindo fontes externas; capaz de reter o histórico das transações ao longo do tempo; construído e mantido localmente ou em serviços em nuvem.

Um DW não deveria (por regra geral) ter dados não estruturados como fotos, vídeos, e-mails e arquivos diversos. Nem tão pouco semiestruturados como nos formatos JSON, XML, entre outros. O foco do DW é ter dados estruturados (em tabelas, com linhas e colunas), de tal forma que possam ser utilizados para responder questões relacionadas a indicadores em diversos níveis. Se a estrutura para hospedar o DW é local ou em nuvem isso dependerá de outros parâmetros a serem observados pela arquitetura de dados da companhia. Aqui, neste artigo, independe.

Na outra ponta, um Data Lake hospeda dados em grandes volumes (tipicamente) e com formatos diversos. É de onde se deriva a sigla 5V (existem outros novos V), que contempla Volume, Variedade, Veracidade, Velocidade e Valor. Ou seja, é razoável considerar ao menos estes 5V quando a ideia passa por construir uma estrutura de Big Data que faça parte do Data Lake da companhia.

Quanto ao DL, pode-se resumir em: armazena massivos conjuntos de dados em formato puro (bruto); destinado à ciência de dados, inteligência artificial e machine learning; hospeda dados estruturados, semiestruturados e não estruturados; elasticidade que permite ampliar e reduzir o ambiente computacional; habilidade de hospedar ilimitados tipos de dados brutos em massivos volumes.

Uma vez separadas as finalidades, vale ressaltar que nenhuma delas é fácil (manualmente) de ser concebida. Por isso existemferramentas queapostam na automação. Mas, automação de quê?

O Dilema do Data Warehouse

Pensar em um Data Warehouse é pensar em reunir informações dispersas em inúmeros sistemas, arquivos, serviços e aplicações em um local preparado para responder às questões impostas pelo negócio. Negócio esse que, certamente, conta com sistemas construídos internamente, aplicações contratadas para segmentos específicos (ERP/CRM), SaaS, dados externos e afins.

Uma companhia que possui diversas bases remotas e locais, talvez escritórios regionais, em diferentes países ou cidades, não vai resolver sua estrutura de análise apenas com uma ferramenta de visualização. É inviável que todos os usuários construam visões a partir de inúmeras bases distribuídas. Isso remete aos problemas de equipes ilhadas, processos manuais, tempo de elaboração dos painéis/relatórios, inconsistência nos números, entre outras.

Existem inúmeros casos de sucesso de soluções que criaram um barramento de dados para construção dos seus painéis em uma ferramenta de visualização. Isso não exclui o fato de que a construção dessas estruturas contou com muito script, muito SQL e muito ETL, manualmente construídos e pouca ou nenhuma automação, nem documentação.

O dilema é que construir um Data Warehouse tipicamente envolve muito esforço, muito custo, muito prazo e pouco resultado. Um DW geralmente está desatualizado mesmo antes de concluído, pois as perguntas do negócio se movimentam mais rápido do que a estrutura consegue acompanhar. No modelo tradicional, centenas (normalmente milhares) de instruções de ETL (Extract, Transform and Load) precisam ser construídas por profissionais especializados em determinada ferramenta com alto custo de contratação, licenciamento, grandes equipes e grande frustração com os "resultados".

É provável já tenha ouvido falar em um projeto de DW que não deu certo. Os motivos são os mais diversos, mas é possível derivar um "Pareto" em que 80% dos fracassos têm 20% de causa. Algo como:

Muito trabalho manual: cada tabela (ou arquivo) precisa, no mínimo, de um extrator, um transformador e uma carga (ETL). Logo, são construídas centenas de instruções independentes uma da outra, geralmente por profissionais diferentes;
Trabalho repetitivo: cada tabela (ou arquivo) contará com três áreas onde serão depositadas (STAGE, DW, DATA MART). Cada área, três instruções (insert, update, delete) e, no mínimo, duas de definição (Create, Alter e as vezes Drop Table);
Desperdício: cada leitura das fontes de dados significa jogar o STAGE fora e carregar todos os dados novamente, causando um grande impacto nas origens. A falha de um processo pode desencadear uma parada total nos dados que se relacionam;
Moroso: modificações nos requisitos podem significar mudanças em todo o fluxo daquela fonte de dados. São centenas de modificações encadeadas, o que torna o processo lento;
Complexo: identificar uma falha geralmente envolve depurar (debug) uma dezena (ou mais) de instruções criadas por profissionais diferentes em ferramentas diversas. Por vezes, fazer de novo aquela etapa é menos lento do que tentar corrigir;
Engessado: mudanças nos sistemas de origem (como, por exemplo, adicionar um novo campo) significa alterar toda a cadeia de eventos, desde o primeiro create table até todas as dezenas de instruções que utilizam aquele novo atributo.

Sobre automação do Data Warehouse

Em um passado não muito distante, a criação de um Data Warehouse era para poucas empresas. Envolvia uma infraestrutura cara, profissionais especializados de alto custo, tempo para implementação e time qualificado para sustentação. Com a chegada das soluções in-cloud, o DW passou a estar ao alcance de mais companhias.

Embora existam ferramentas para cada etapa (Extract, Transform and Load), o processo de migrar, criar ou evoluir um DW mudou de lugar, mas não de desafios. Modelar, estruturar, carregar os dados e torná-los disponíveis continuam, seja localmente ou em nuvem. Aliás, in-cloud os desafios incluem transportar os dados que estão on-premises para a nuvem, o que é bastante comum nestes cenários.

Na linha de construir, manter, carregar os dados e propagar mudanças, automaticamente surgem as soluções que criam todo o fluxo de DW de ponta a ponta com mínimo de trabalho manual. Desde a concepção do modelo relacional (a forma como as tabelas se falam) até a construção de todas as instruções EL-T, passando ainda por validações, verificações e regras de negócio, incluindo a geração dos Data Marts com a documentação disponível e todos as "instruções" (comando) acessíveis ao engenheiro de dados.

Em suma, para tornar os dados prontos para consumo, é preciso ter uma estrutura que seja ágil o suficiente para acompanhar as expectativas do negócio. A automação reduz o custo, o tempo, a manutenção e o risco de decisões baseadas em estruturas desatualizadas. O Data Pipeline precisa ser contínuo, integrado, rápido e automatizado, com entregas recorrentes iniciando na captura dos dados e, imediatamente, preparados para as mais diversas áreas de decisão.