Pedro Feitosa

Este espaço nunca teve um propósito claramente definido. Ele continua sendo o lugar onde tento expressar ideias e compartilhar conhecimento com a comunidade. Inspirado pelo LinuxTips, sempre quis que fosse um espaço acessível - um lugar onde as pessoas pudessem evoluir junto com meus desafios, experiências e reflexões. O público-alvo não mudou: engenheiros de software e gestores em qualquer etapa da carreira. Essa é uma decisão que não pretendo revisar. Após quase oito anos trabalhando em empresas brasileiras, comecei a sentir que era hora de seguir em frente. Sempre tive curiosidade sobre o que significaria trabalhar em um ambiente internacional, mas um fator em especial acabou me afastando disso por bastante tempo. ...

Em 2025 passei por muitas mudanças em como me organizo, tanto por motivos pessoais quanto profissionais. Nós queremos sempre estar melhorando como pessoas, e meu lado viciado em internet sempre me faz ler artigos ou assistir vídeos que me guiam nesse sentido. Meu desafio no consumo desse conteúdo é o de balancear esse peso que nos é passado de ser um gestor de si - em que temos sempre que estar bem organizados e produtivos - com os desafios e prazeres que a vida nos dá, balanceando hobbies mais ligados à tecnologia e/ou programação com os hobbies mais culturais como leituras, estudos, assistir filmes e principalmente o tempo de qualidade com a família. ...

Integrar o Spark com o Kafka é um desafio que pode envolver todos os usuários de um cluster Kafka, ainda assim algumas boas práticas podem nos auxiliar a acelerar o desenvolvimento desta ligação e otimizar nossos resultados. Toda a parte de produção de mensagens no Kafka utilizando Spark pode ser considerada experimental por escrever utilizando o modo continuous, desta forma nós engenheiros de dados acabando nos preocupando mais com o consumo dos dados do serviço. Para quem já é habituado com o Kafka, o comportamento do Consumer Group no Spark se mostra incomum: o commit das mensagens é integrado diretamente com os checkpoints, e não são repassados ao broker; isso por um lado traz um baixo overhead na integração dos sistemas, mas para quem é habituado a acompanhar o consumo dos eventos via alguma UI (como KafkaUI ou o Kafka Prometheus Exporter) pode se chocar com a ausência desses metadados. ...

Decidir a arquitetura para processamento dos dados é mais um caso no mundo tech onde não há bala de prata. A escolha entre Kappa e Lambda pode partir de duas questões, uma acerca da origem e outra do destino: A fonte dos dados é puramente um stream? Ou seja, o único meio de recuperar dados históricos é conectando ao stream? No destino, o dado proveniente do stream deve se unir a dados do mesmo contexto com outra fonte? Respondidas as perguntas fica mais clara a decisão, sendo a Kappa a mais ligada aos “streams puros”, que não se mostra necessidade de obter dados históricos, nem se deve importar com dados pre-existentes na tabelas. ...

Ao fazer a leitura de dados em streaming, temos duas opções para retirar um frame desse conjunto infinito; sendo o default deles o microbatch, que possibilita a acumulação de eventos de forma configurável, com limites superior e inferior de volume. Documentos do Spark abordam que um intervalo mínimo performático entre execuções de microbatches seja a partir de 100ms. A escrita de microbatches é subdivida em 3 modos: complete, append e update. O primeiro mantém todos os registros já lidos pelo stream em memória por todo o tempo de execução da aplicação e sempre os reescreve no destino. O segundo escreve no destino apenas novos dados, se diferenciando do último por não escrever dados que foram atualizados. Os modos de saída se diferem para cada tipo de query, na documentação oficial é demonstrada a matriz de compatibilidade. ...

Ao trabalhar com cargas em batch, idealmente temos a visão completa ou parcialmente limitada de um dataset, como em pipelines incrementais. Tal visão holística dos dados garante que agregações ou visões do passado vão nos dar resultados ao mínimo constantes no passar do tempo. O consumo de dados que estão em constante movimento, nos obriga a pausar o processo de leitura caso necessário observar o que já foi lido. Aqui as agregações, por terem um contexto bem delimitado da visão observada durante o tempo, são possíveis mas exigem controles vindo de conceitos como watermarking e stateful streaming, que abordaremos em outra seção. ...

No meio clássico de uso do Spark, nós temos um grupo de máquinas que executam um ETL em um conjunto de dados previsível, onde já se conhece previamente o tamanho e quantidade de dados (finita) a serem processados, ou seja, conseguimos ajustar o tamanho desse cluster ao longo do tempo. Por outro lado, ao ler dados em streaming, podemos ter de zero a infinitos números de registros, que podem variar seu throughput ao longo do tempo. A partir dessa imprevisibilidade que os conceitos principais surgem, como também nos levará a bloqueios em certas features nativas do Spark. ...

Lidar com dados em larga escala exige diversas precauções sob o meio que vamos fazer a leitura, escrita e as iminentes transformações. O Spark traz garantias de tolerância à falhas e também escalabilidade quando desejamos trabalhar com grande volumes. Ele junto às novas APIs de Structured Streaming podem ser a solução ideal quando precisamos de armazenamento em estruturas de datalake ou data lakehouse. Vamos desvendar aqui um pouco sobre o vocabulário, alguns conceitos e pontos de partida para uso da ferramenta. ...

Quando usamos o Spark em ferramentas gerenciadas como o Databricks, muito que precisamos é fornecido com facilidade pela plataforma, e mesmo quando o cenário não nos favorece, podemos instalar bibliotecas com poucos passos, seguindo a documentação da plataforma. Já em casos que precisamos ter maior controle sobre todo o ambiente de execução, seja por questões de custo, ou por limitações - quem sabe a falta de um contrato com o Databricks ou ferramentas semelhantes - instalar bibliotecas, sejam elas Jars adicionais para o funcionamento do Spark, ou libs Python, para organizar o funcionamento do código, simplicidade é uma palavra que não se aplica. ...

Depois de um período muito grande com meus microcontroladores engavetados, conhecer o TinyGo foi o que me fez querer voltar a estudar o assunto. A linguagem nativa do Arduino era uma ferramenta pessoalmente limitante, pois apesar de C++ não ser uma linguagem muito fora do meu contexto, ter que me adaptar a uma linguagem diferente é algo que atrapalha o “compromisso” com os estudos de automação, entra então o TinyGo, que compila projetos orientados a embarcados e WASM. ...