Um dos maiores desafios da nossa era é extrair, processar e entregar dados em tempo real. Não só isso, mas da melhor forma possível com latência de até 10 milissegundos, sim pode parecer fora da nossa realidade mas em diversos casos essa latência não é só necessária mas como crucial para a evolução de um negócio de sucesso.
Muito assim como eu utilizam o Apache Kafka para realizar essa tarefa, excelente plataforma de streaming que te garante robustez e componentes desacoplados, computação e armazenamento.
Porém assim como em qualquer mercado a competição e sempre melhor para o consumidor nesse caso nós engenheiros de dados, sendo assim para aumentar as nossas opções vem o Apache Pulsar.
Apache Pulsar foi criado no Yahoo em 2016 e se tornou um top level project da Apache Software foundation em 2018, mas o que o Apache Pulsar tem de tão diferente que pode ameaçar a hegemonia do apache Kafka?
Vamos ver a lista de recursos do Apache Pulsar:
- Cloud Native
- Multi tenant
- geo-replicação de eventos entre os clusters
- Persistência de eventos através do Apache BookKeeper (Zero Rebalance)
- Pulsar Functions
- Pulsar IO
- Pulsar Proxy
- Pulsar SQL
- Tiered Storage (open-source)
Iremos entrar em cada um desses recursos.
Cloud Native
Apache Pulsar foi criado após o sucesso do Apache Kafka, sendo assim ele já vem com melhorias para superar o seu competidor, como ser cloud native, ele foi desenhado para aproveitar o máximo dos recursos de nuvem, hoje a versão open-source está disponível para AWS por meio de Ansible, Kubernetes, VM e Docker.
Multi-Tenant
Para seguir hoje as maiores tendências no mercado, o Apache Pulsar foi desenvolvido para ser multi-tenant ou o tenant é a unidade mais básica de categorização de tópicos, aonde você pode associar um namespace, ou seja você pode criar vários tenant em 1 cluster de Pulsar é associar namespaces a essa tenant, garantindo assim autorização em nível do namespace, múltiplas aplicações com namespaces diferentes cada um lendo de um set de tópicos.
Geo-replicação
Esse é um dos pontos muito interessantes no Pulsar, de forma bem simples, podemos criar replicação de eventos entre diferentes cluster, por exemplo podemos produzir dados em uma região e realizar a leitura em outra que irá receber os dados replicados. Podemos trabalhar de 2 formas.
Geo-replicação [Assíncrono]
Os eventos são persistidos no cluster Local, eventualmente eles vão para os clusters remotos de forma assícrona, responsabilidade dos brokers. Neste modo não temos perda de performance pois o cluster local irá receber e em seguida enviar para os clusters remotos porém eu tenho baixa consistência entre os cluster pois podemos ter um lag de replicações de eventos que não persistiram ainda, não é síncrono.
Geo-replicação [Síncrono]
No modo síncrono, os dados são enviados para o cluster local porém o Apache BookKeeper fica responsável por replicar os eventos, só recebemos o acknowledgment, retorno de persistência, com sucesso depois de gravar em todos os clusters envolvidos na replicação. Neste caso temos a mais alta disponibilidade e consistência de dados, porém será necessário maior latência pois temos que receber o retorno de todos os clusters.
Podemos ver que em todos os modos de replicação temos pontos positivos e negativos, avalie bem o seu use case.
Apache BookKeeper
O Apache BookKeeper ou Bookie é o componente responsável pela persistência dos dados no storage, sendo um sistema distríbuido WAL (write-ahead log). BookKeeper é bem interessante pois ele habilita alguns coisas bem legais para o Apache Pulsar, que são:
- Ledgers = estrutura de dados incrementais (append-only) de gravação única e designado para os bookies (cluster de BookKeeper). Broker cria o ledger, acrescenta as entradas para o Ledge e fecha o Ledge, após isso um ledge só pode ser aberta como modo de leitura.
- Bookie oferece uma eficiente armazenamento de dados sequêncial que suporta entradas de replicação.
- Entradas e saídas (I/O) entre os bookies.
- Escalabilidade horizontal tanto para capacidade quanto performance.
Dentre vários outros benefícios, Bookie é realmente um característica marcante no Apache Pulsar, porém acrescenta uma complexidade a mais por se tratar de mais um componente que requer gerenciamento. Não existe almoço de graça em tecnologia.
Pulsar Functions
Além do bookie, na minha opinião esse componentes é muito interessante e deixa o Apache Pulsar mais atrativo.
Functions, sim e isso que você leu, no Apache Pulsar temos um framework de desenvolvimento serverless (não precisa de servidor) para processamento simples de eventos, ou seja o tópico entra e a função e executada e gerado um tópico de saída processado.
Linguagens disponíveis:
- Java
- Python
- Go
lembrando que esta é uma explicação resumida, em artigo futuros teremos maiores explicações sobre como utilizar esse recurso.
Lembrando que ele está usando o Apache Pulsar então não é um implementação separada. Muito interessante correto?
Pulsar IO
Pulsar IO tem o mesmo principio do Kafka Connect, desenvolver uma aplicação que lê dados de um data store e gravar no Pulsar em forma de um conector, o usuário só utiliza um arquivo de configuração.
Teste um pouco o Pulsar IO é ainda precisa de alguns ajustes se compararmos ao Kafka Connect, claro que o Kafka Connect tem mais tempo de mercado e dessa forma já está bem mais maduro, mas o Pulsar IO vem sendo acelerado para ser um concorrente direto e expressivo.
Pulsar SQL
Aqui temos uma integração do Pulsar e o PrestoSQL, podemos configurar um servidor de PrestoSQL e utilizar dentro do Pulsar para consultas SQL de forma simples e transparente, ou seja, consultar tópicos através de instruções SQL. Acredito que em pouco tempo teremos o Trino para a versão Kubernetes do Pulsar SQL.
Pulsar Proxy
Outro componente bem interessante é o Pulsar Proxy, aonde podemos criar um gateway opcional na frente do meu cluster de Brokers, a ideia é ao invés dos meus clientes acessarem diretamente os brokers através de uma lista de IPs, a chamada ser no Pulsar Proxy que ele irá se encarregar de fazer o networking load balance para que o cliente acesse o broker desejado.
Facilita muitas coisas além de aplicar uma camada de segurança na borda do cluster do Apache Pulsar, aonde ninguém de fora conhece o cluster de brokers.
Tiered Storage
Esse é uma opção que ainda não temos no Apache Kafka (open-source), que é o Tiered Storage, a ideia é mover os dados geralmente históricos que estão no Pulsar para um storage de longo termo mais barato, melhor que de forma automatizada. Por exemplo se o tópico atingiu o seu tempo de retenção, antes do expurgo dos dados, podemos mover para um AWS S3, GCS ou Azure Blob Storage, isso se torna interessante em empresas que precisam de rastreabilidade do dados por conta de auditorias.
Podemos ver que Apache Pulsar tem muitas features interessantes que irão elevar a competição no mundo de streaming, o que é muito bom para nós, engenheiros de dados que precisamos de mais tecnologias no nosso cinturão do batman!
Para fechar vamos ver a arquitetura do Apache Pulsar com algumas features mencionadas aqui?
