Fast Data – A Evolução do Big Data

A forma como os dados são usados em uma empresa muda constantemente, mas nos últimos anos as mudanças ocorreram em um ritmo realmente acelerado e as ferramentas consideradas úteis para aplicativos de Big Data, já não são mais suficientes. O desenvolvimento e expansão de negócios em áreas como IoT (Internet of Things), geolocalização, redes sociais, aplicativos móveis, etc…, mudou a forma como os dados são coletados, armazenados, distribuídos, processados e analisados. As decisões em tempo real já fazem parte do cenário e novas ferramentas e arquiteturas são necessárias para lidar com esses desafios de forma eficiente. Ou seja, estamos indo da era Do Big Data Para o Fast Data e estamos indo cada vez mais rápido! O Fast Data – A Evolução do Big Data, é o que vamos discutir neste artigo.

Este artigo aliás, é quase uma consultoria gratuita. Aproveite!

Pense nos 4 V’s do Big Data: volume, velocidade, variedade e veracidade. Por um tempo, o Big Data tinha como ênfase o volume de dados; atualmente, para as aplicações analíticas, a velocidade e a variedade são fundamentais. Duas tendências emergiram desta evolução: primeiro, a velocidade e a variedade dos dados que a empresa precisa para a tomada de decisões continuam a crescer. Esses dados incluem não apenas informações transacionais, mas também dados comerciais, métricas IoT, informações operacionais, dados de redes sociais, cliques em páginas web e logs de aplicativos. Em segundo lugar, a empresa moderna precisa tomar essas decisões em tempo real, com base em todos os dados coletados. Esses dados coletados em tempo real é o que chamamos de Fast Data e esta necessidade é melhor esclarecida, observando como os websites de compras funcionam.

Os websites de compras visam oferecer seus produtos a um cliente específico em um momento preciso. Precisamos conhecer as zonas de “calor” da página – os itens mais clicados – e porque existem zonas frias. Se uma pessoa estiver visualizando a seção A, o sistema deve oferecer a seção B, porque os dados mostram que muitos clientes passaram da seção A para a seção B. Mais uma vez, temos dois desafios: coletar todos esses dados de forma online, limpar, processar, e analisar também de forma online (praticamente não há mais processamento durante a noite). Em segundo lugar, com base nessas informações, precisamos fazer alterações na página web imediatamente, de modo que a análise deve ser precisa e vinculada dinamicamente ao cliente por um momento preciso. É realmente um mundo em tempo real.

 

Projetando Arquiteturas de Fast Data

Até pouco tempo atrás, Big Data significava usar Hadoop e bancos de dados NoSQL. O Hadoop nasceu na era de processamento “em lote” (batch) e “off-line”, quando os dados eram capturados, armazenados e processados periodicamente em lotes. Os motores de busca funcionavam com dados coletados por rastreadores web e depois processados durante a noite para oferecer resultados atualizados no dia seguinte. O Big Data era focado na captura de dados e na operação em lote e off-line. Como mostra o exemplo anterior do nosso website de compras online, os sistemas de “dados rápidos” (Fast Data) modernos reduzem o tempo entre os dados que chegam e a extração de valor desses dados. O processamento de eventos em tempo real é o oposto do processamento em batch. Em arquiteturas de Fast Data, os eventos individuais são processados à medida que chegam e estamos falando aqui em tempos de processamento de milissegundos, ou mesmo em microssegundos.

 

 

Construir arquiteturas de Fast Data que podem fazer esse tipo de processamento de milissegundos significa usar sistemas e abordagens que fornecem processamento de dados real-time (ou near real-time) e econômico focados na produtividade. Uma arquitetura de Fast Data deve satisfazer esses requisitos:

• – Aquisição e ingestão de dados atualizados e confiáveis
• – Armazenamento e consulta flexíveis
• – Ferramentas de análise sofisticadas

 

Também é importante mencionar que os componentes de arquitetura devem cumprir a regra dos R’s: reativos (escalabilidade com base na demanda), resilientes (contra falhas em todos os sistemas distribuídos) e responsivos (mesmo quando as falhas limitam a capacidade de fornecer serviços). Os modernos sistemas de Fast Data são compostos por quatro estágios de transformação:

• – Aquisição
• – Armazenamento
• – Processamento e análise
• – Apresentação e visualização

 

Vejamos cada uma dessas etapas e as principais ferramentas utilizadas.

 

Aquisição de Dados

Nesta etapa, os dados entram no sistema a partir de diversas fontes. O foco principal aqui é o desempenho, pois esta etapa afeta a quantidade de dados que todo o sistema pode receber em qualquer momento. A aquisição de dados com alto desempenho significa prestar atenção a alguns princípios fundamentais:

A transferência de dados deve ser assíncrona e evitar a contrapressão

Quando um sistema síncrono se torna assíncrono, temos que considerar dois fatores: o subsistema de tokens e o subsistema de transações. Isso parece fácil, mas existem duas maneiras de implementar um sistema assíncrono: usando transferência de arquivos ou usando um MOM (Message-Oriented-Middleware), uma infraestrutura que suporte mensagens em sistemas distribuídos. Imagine que os dados são gerados mais rapidamente do que são consumidos; Na concepção de sistemas distribuídos, isso é chamado de contrapressão. Um dos principais objetivos de qualquer sistema MOM e filas distribuídas é lidar com a contrapressão.

Parsing pode ser caro então paralelize quando possível

O passo mais caro da aquisição de dados é a transformação de dados – o passo em que o tempo e os recursos são consumidos. Se você pode usar um processo paralelo para transformar seus dados antes do processamento e de forma paralela, isso pode ser muito valioso. Outra economia de tempo é filtrar dados inválidos o mais cedo possível. O processamento deve funcionar com conjuntos de dados válidos, portanto, limpe e remova duplicatas antes de transformar os dados.

Tecnologias

Para esta etapa, você deve considerar as APIs de streaming e soluções de mensagens como:

• – Apache Kafka – plataforma de processamento de streaming
• – Akka Streams – processamento de streaming baseado no Akka
• – Amazon Kinesis – solução de processamento de streaming da Amazon
• – ActiveMQ – corretor de mensagens de código aberto com um cliente JMS em Java
• – RabbitMQ – corretor de mensagens de código aberto com um cliente JMS em Erlang
• – JBoss AMQ – MOM leve desenvolvido pela Red Hat
• – Oracle Tuxedo – plataforma de mensagens middleware da Oracle
• – Sonic MQ – plataforma de sistema de mensagens da Sonic

 

Para lidar com muitos desses princípios fundamentais de aquisição de dados, o vencedor é o Apache Kafka porque é de código aberto, focado em alto rendimento, baixa latência e lida com feeds de dados em tempo real.

 

 

Armazenamento de Dados

Há muitos pontos de vista para projetar essa camada, mas todos devem considerar duas perspectivas: lógica (ou seja, o modelo) e armazenamento de dados físicos. O foco principal para esta etapa é “experimentação” e flexibilidade.

Todo problema tem sua solução, mas não reinvente a roda

O termo banco de dados é muito abrangente e sempre tenha em mente que diferentes soluções possuem diferentes recursos: alguns são melhores com a leitura dos dados, alguns para inserção e alguns na atualização. Outra consideração importante – nem todos os dados são relacionais. Lembre-se que eficiência em cada etapa torna todos os processos mais rápidos e melhora o consumo de recursos para atividades como transferência de rede e espaço em disco.

Não existe mais configuração padrão

Não há mais configuração padrão “out-of-the-box”. A mesma solução pode ter duas configurações distintas, fazendo com que a mesma ferramenta se comporte de forma totalmente diferente. Para ser competitivo, um sistema de armazenamento deve ter a capacidade de modificar duas configurações chave: nível de replicação e nível de consistência. Um Engenheiro de Dados eficiente e profissional deve ser capaz de experimentar novas configurações até obter o comportamento desejado.

O relacional resolve o seu problema e a normalização ainda é uma opção?

Pense fora da caixa. Nos sistemas RDBM você precisa adaptar seu problema ao modelo relacional, então você deve encontrar suas entidades, relacionamentos, chaves e chaves estrangeiras. Na era do Fast Data, os sistemas de dados são modelados com base em casos de uso. Outra pergunta, que parecia absurda no passado, mas agora faz sentido, é decidir entre normalização dos dados e desempenho. A normalização dos dados começa a não fazer tanto sentido na era do Fast Data.

Tecnologias

Para este estágio, considere soluções distribuídas de armazenamento de banco de dados como:

• – Apache Cassandra – SGBD NoSQL distribuído
• – Couchbase – banco de dados NoSQL baseado em documentos
• – Amazon DynamoDB – banco de dados proprietários NoSQL totalmente gerenciado
• – Apache Hive – data warehouse construído sobre o Apache Hadoop
• – Redis – key-value store distribuído em memória
• – Riak – NoSQL key-value data store distribuído
• – Neo4J – sistema de gerenciamento de banco de dados baseado em grafos
• – MariaDB – com Galera formam um cluster de replicação baseado no MySQL
• – MongoDB – banco de dados orientado a documentos e multiplataforma
• – MemSQL – RDBMS SQL em memória e distribuído

 

Para lidar com muitos dos principais princípios de armazenamento de dados que acabamos de explicar, a escolha não é fácil, pois cada solução de armazenamento possui suas características, vantagens e desvantagens, que serão mais ou menos importantes dependendo da arquitetura e do objetivo final. MongoDB e Apache Cassandra são duas opções que tem muito destaque no mercado e são open-source. O Amazon DynamoDB vem crescendo de forma exponencial, pois é totalmente gerenciado e em nuvem, ou seja, não precisamos nos preocupar com hardware. Apache Hive, Redis e MemSQL também são boas opções. Mas a escolha depende do objetivo final do projeto.

 

 

Processamento de Dados

Anos atrás, houve discussão sobre se os sistemas de Big Data deveriam ser baseados em processamento de streaming ou processamento em batch. Hoje sabemos que a resposta correta, considerando um cenário de Fast Data, é que a maioria dos sistemas deve ser híbrida – com processamento tanto em batch quanto em streaming de dados em tempo real. O tipo de processamento agora é definido pelo próprio processo, e não pela ferramenta. O foco principal deste estágio é a “combinação”.

Segmente o seu processamento e considere o microbatching

Para ter competitividade, as ferramentas de Fast Data devem oferecer excepcional processamento em batch, excelente processamento de streaming, ou ambos. O objetivo é usar a ferramenta certa para a tarefa certa do seu processamento. Não use ferramentas de processamento em batch quando o processamento online for necessário e não tente mover todos os processos ETL tradicionais para arquiteturas de streaming modernas. Algumas ferramentas dividem dados em partes menores, onde cada pedaço é processado de forma independente em tarefas individuais. Algumas estruturas aplicam o processamento em batch em cada pedaço (chunk), o que é chamado micro-batch, e então processam como um único fluxo de dados.

Considerando a localização dos dados em memória ou em disco

Existem muitas soluções tradicionais baseadas em disco, e há muitas soluções modernas baseadas em memória. Você deve avaliar se seu sistema possui a infra-estrutura necessária para o processamento em memória. Nem todos os processos devem estar na memória; combine recursos para obter melhores resultados. Acima de tudo, nunca perca de vista a proximidade dos dados – o melhor desempenho acontece quando os dados estão disponíveis localmente. Quando os dados não estão próximos, há custo de transferência. A arte desta etapa é avaliar entre a transferência de dados ou a replicação, e entre os locais de processamento.

Tecnologias

Para este estágio, você deve considerar soluções de processamento de dados como:

• – Apache Spark – mecanismo para processamento de dados em grande escala
• – Apache Flink – estrutura de processamento de streaming
• – Apache Storm – sistema de computação em tempo real distribuído de código aberto
• – Apache Beam – modelo unificado para dados em lote e streaming
• – Tensorflow – biblioteca de código aberto para Machine Learning e Inteligência Artificial

 

Para gerenciar muitos dos princípios fundamentais do armazenamento de dados que acabamos de explicar, o vencedor é um empate entre Spark (microbatching) e Flink (streaming).

 

 

Visualização de Dados

A visualização comunica dados ou informações, codificando-os como objetos visuais em gráficos, de forma clara e eficiente para obter informações aos usuários. Este estágio não é fácil. É uma arte e uma ciência.

Não processar e minimizar cálculos

Este passo deve evitar o processamento. Alguns relatórios precisarão de cálculos em tempo de execução, mas sempre funcionam no mais alto nível de dados possível. Os dados devem sempre estar em tabelas de resultados resumidos, com agrupamentos que podem ser temporais (por período de tempo) ou categóricos (com base em classes de negócios).

Paralelismo e desempenho

O desempenho é melhor se os relatórios estiverem paralelizados. Além disso, o uso de cache sempre tem um impacto positivo no desempenho da camada de visualização.

Tecnologias

Para esta camada, você deve considerar as soluções de visualização nessas três categorias:

• – Relatórios em notebooks: Apache Zeppelin e Jupyter Notebook
• – Gráficos e mapas: Tableau e Power BI
• – Gráficos, mapas e gráficos personalizados: D3.js e Gephi

 

Gerenciamento da Infraestrutura do Fast Data

Mesmo depois de ter uma arquitetura sólida projetada para lidar com os quatro estágios de transformação de dados, é importante reconhecer que o processamento moderno de Fast Data também mudou as operações do centro de dados (datacenter).

O reinado do open-source

Não sei se você percebeu, mas o open-source é a principal razão pela evolução do Big Data e do Fast Data (e me arrisco dizer que também é um dos principais responsáveis pela evolução da tecnologia de um modo geral). O negócio está passando de supercomputadores especializados, proprietários e caros para a implantação em clusters feitos de máquinas commodities (de baixo custo) conectadas com uma rede de baixo custo. Agora, o custo total de propriedade (TCO) determina o destino, a qualidade e o tamanho de um datacenter. Uma prática comum é criar um cluster dedicado para cada tecnologia: um cluster Kafka, um cluster Spark, um cluster Cassandra, etc… A tendência é adotar soluções open-source e evitar duas dependências: fornecedores e suporte externo de entidades. A transparência é assegurada através de grupos definidos pela comunidade, como a Fundação Apache Software ou a Fundação Eclipse, que fornecem diretrizes, infraestrutura e ferramentas para desenvolvimento de tecnologia sustentável e justa.

Diversificação da data store, gravidade dos dados e localidade de dados

A proliferação NoSQL tem como consequência que agora temos que lidar com a sincronização dos data stores entre os datacenters. A gravidade dos dados significa considerar o custo total associado à transferência de dados, em termos de volume e ferramentas. Localidade de dados é a ideia de mover a computação para os dados em vez de mover os dados para a computação.

DevOps

DevOps significa práticas recomendadas para colaboração entre desenvolvimento de software e operações. Para evitar a reformulação, a equipe de desenvolvimento deve ter localmente o mesmo ambiente usado em produção. Isso permite testes mais precisos, além de detecção e prevenção a falhas.

Tecnologias

Para esta camada, você deve considerar as seguintes tecnologias de gerenciamento:

• – Apache Mesos – projeto de código aberto para gerenciar clusters de computadores
• – Mesosphere – plataforma para automatizar implantação e produção de contêineres e serviços de dados
• – Amazon Web Services – serviços de computação em nuvem
• – Docker – plataforma aberta para construir, enviar e executar aplicativos distribuídos
• – Kubernetes – sistema de código aberto para automatizar, implementar, dimensionar e gerenciar aplicativos em contêineres
• – Spinnaker – plataforma de entrega contínua multi-nuvem para liberar mudanças de software

 

Prestando atenção aos princípios descritos acima, à medida que você considera sua arquitetura de Fast Data,  suas ferramentas irão aproximá-lo do valor real em seus dados. Gerenciando e usando esses dados de forma eficaz – movendo-os através dos estágios de aquisição, armazenamento, processamento e análise e visualização, irá ajudá-lo a obter informações acionáveis e torná-lo competitivo neste mundo em tempo real.

Está esperando o que para entrar neste novo mundo do Fast Data?

---

Quer aprender a trabalhar de forma profissional e eficiente com Big Data e Fast Data? Então se inscreva hoje mesmo na Formação Engenheiro de Dados e avance sua carreira para outro nível, pois as técnicas e ferramentas descritas neste artigo serão estudadas em detalhes ao longo de 5 cursos incríveis e de alto nível. Clique no botão abaixo para saber mais!

 

 

Equipe DSA

 

Referências:

Formação Engenheiro de Dados

Big Data vs. Fast Data: What’s the Difference?

Oracle’s Fast Data Solutions

From big data to fast data

Fast data: The next step after big data

Fast Data: The New Big Data

What’s Fast Data all about?

Big Data, Fast Data, Smart Data

Fast Data Drives Real-Time Insights Into Big Data

‘Big Data’ Is No Longer Enough: It’s Now All About ‘Fast Data’

MOM – Message-oriented middleware