Thermal Data: Qual é a temperatura do seu dado analítico?

Em 2018, no re:Invent, principal evento de lançamento de serviços, apresentações e cases da AWS, Ben Snively fez uma palestra com o título “Big Data Analytics Architectural Patterns and Best Practices”.

Na apresentação, ele traz uma pergunta: “qual é a temperatura do seu dado analítico?” (em tradução livre). Para responder a questão, precisamos compreendê-la antes.

Característica de acesso ao dado

O conceito “Thermal Data” se baseia em uma matriz, onde cruzamos seis requisitos de acesso aos dados com as três temperaturas deles: Hot, Warm e Cold. Quanto mais quente o dado, mais rápido será seu acesso – porém, mais caro também. Da mesma maneira, quanto mais frio o dado, menor será o custo para acessá-lo e mantê-lo.

A matriz citada pode ser utilizada para tomar decisões referentes ao investimento em dados, por exemplo:

Em uma API, onde a resposta deve ser próxima da instantaneidade, faz-se necessária a utilização de um repositório de dados de alta performance. Ou seja, você precisaria utilizar um conjunto de dados Hot para atender esta necessidade e precisaria investir alguns reais por gigabyte.  

O caso de uma equipe de inteligência de negócios que analisa dashboards e está olhando diversas fontes de dados para a tomada de decisões é diferente. Pela volumetria de dados e a quantidade de cruzamentos necessários entre as diferentes fontes para a geração de indicadores e insights, esse time necessita de estruturas de dados analíticas, data warehouses e data marts. Caracterizando, assim, um público para um Warm Data.

Por fim, equipes de ciência de dados, que procuram o maior histórico e conjunto de dados para execução de uma hipótese, porém, que fazem consultas pontuais dentro deste dataset, necessitam de um Data Lake analítico para consumo. Assim, temos um caso para Cold Data, exigindo um investimento de alguns centavos de real por gigabyte. 

Princípios de Arquitetura

Alguns princípios arquiteturais do ecossistema de Big Data estão relacionados à temperatura do dado. Garantem uma performance adequada e um custo condizente com seu benefício. Veja alguns exemplos:

Processe em sistemas desacoplados

O desacoplamento é uma boa prática de desenvolvimento de software, não importa qual o objetivo. Desacoplar evita dependências, facilita manutenções e faz com que o sistema não pare por completo por causa de um erro específico. Da mesma maneira, precisamos pensar a arquitetura de dados do ecossistema de big data. 

Esse desacoplamento se faz necessário porque alguns conjuntos de dados podem ter requisitos de tempo real para acesso, enquanto outros conjuntos necessitam de agrupamentos prévios ou precisam rodar em processos batch.

Para esses tipos de situações, em que as necessidades de acessos aos dados são diferentes, não existem ferramentas ideais para ambos os casos.

Ou seja, não há uma solução que atenda todos os cenários. Assim, um conjunto poderá escrever primeiramente em uma estrutura de streaming e data lake e, posteriormente, fazer o processamento analítico.

Use a ferramenta certa para o serviço certo

Para escolher a ferramenta certa, leve em conta a estrutura de dados necessária, assim como a latência (para processamentos em cloud, por exemplo), taxa de transferência e padrões de acesso ao dado.

Gestão dos serviços

Garanta o padrão da gestão do serviço a ser utilizado para a entrega do seu dataset, no que se refere à escalabilidade, disponibilidade, resiliência, segurança, administração e monitoria.

Tenha consciência dos custos

Um ecossistema de big data é diferente de ter um ecossistema de “big cost”. Usar as ferramentas adequadas para as necessidades existentes gera um custo operacional inteligente.

Sabendo que não existe uma ferramenta única para todas as necessidades, mas sim a ferramenta certa para cada necessidade, torna-se possível implementar um ecossistema de dados com uma alta performance, atendendo a todas as utilizações de diferentes consumidores de dados.

Por Tomaz Lanfredi Lago é data engineer na ilegra, empresa global de design, inovação e software.