• O Pacto da Branquitude, por Cida Bento: na minha opinião leitura essencial para nós, pessoas brancas, para refletirmos e compreendermos como já nascemos com as estatísticas (e outras pessoas brancas) trabalhando a nosso favor;
• A Vida Não É Útil, por Ailton Krenak: esse livro me fez pensar, além de várias outras coisas, em todas as bobagens contadas no LinkedIn, tech brows e a sana em destruir tudo para satisfazer investidores.

Esse ano de 2025, para minha própria surpresa, li 15 livros completos e foi bem interessante notar como fui de realizar uma atividade meio chata e forçada para um hábito como escovar os dentes. Estes foram os livros técnicos que li em 2025:

• Domain Driven Design Distilled
• How AI Works
• Software Architecture Patterns
• Artificial Intelligence, a guide for thinking humans
• Product Management in Practice
• Prompt Engineering for LLMs
• Identity Security for Software Development
• Concurrency in Go
• Web Security for Developers

Domain Driven Design Distilled

Já ouvi falar que o livro clássico Domain Driven Design é muito denso e difícil de ler, então achei melhor começar por esse. É um livro enxuto, rápido de ler e sumariza os principais conceitos de DDD.

Acredito que vale a leitura, porém, creio que faltou um pouco de revisão. Exemplo: em um único parágrafo o autor repete a mesma coisa três vezes, uma atrás da outra, além de apontar uma coisa óbvia de uma imagem. Essa percepção de escrita meio enrolada me acompanhou em alguns momentos, mas foi uma percepção pessoal, creio que não invalida a importância desse livro. Em algum momento irei ler outras alternativas como “Learning Domain-Driven Design”, que é um livro com bons reviews e parece ter uma proposta parecida.

Recomendo a leitura, porém, como é apenas teoria, estou fazendo o projeto prático do “Domain-Driven Design with Golang” para consolidar melhor os conceitos. DDD definitivamente não é simples (deveria ser?).

How AI Works

Não se engane, esse é um livro técnico apesar da capa fofinha da No Starch Press. Inicialmente achei que encontraria algo parecido com o “Artificial Intelligence Basics” que li ano passado, mas esse livro passa por conceitos bem profundos e complexos, apesar de evitar fórmulas matemática (mas falando de conceitos dela). Apesar disso é extremamente didático de uma forma muito engajante.

Eu não tinha intenção de ler esse livro esse ano, acontece que eu folheei algumas página no Kindle e simplesmente fui fisgada. Como a intenção dessas leituras é principalmente filosófica, ser fisgada por um livro técnico é tudo que eu queria mesmo. Acredito que ajudou a, de certa forma, acalmar meus nervos com relação a inteligência artificial.

Por fim: altamente recomendado. Leia 5 páginas, se você não for fisgado(a) por esse livro, você está morto(a) por dentro 😆

Software Architecture Patterns

Este é um report da O’Reilly, o que significa que é um livro pequeno, um relatório mesmo, focado em falar sobre padrões de arquitetura de software. Achei bem enxuto e direto ao ponto, porém, não sei se houve algum valor real ao ler esse livro. Talvez seja interessante para quem só quer manter um hábito saudável de leitura, ou apenas quer revisar alguns pontos dos tipos de arquitetura. Mas vale frisar que escolhi esse livro por causa do autor Mark Richards, que é quem escreveu juntamente com Neal Ford o “Fundamentals of Software Architecture”. Achei que seria uma boa começar por esse reporte, assim como fiz com o Domain Driven Design Distilled.

Artificial Intelligence, a guide for thinking humans

Que livro fantástico! Tem um pouco de “How AI Works” nos quesitos históricos e de funcionamento, mas não vai tão a fundo tecnicamente quanto ele, no lugar da profundidade técnica tem um quê filosófico, de questionamentos críticos, e tons pessoais da autora cuja história está entrelaçada com o tema. Melanie Mitchell é professora de ciência da computação e em 1990 já estava escrevendo teses sobre inteligência artificial.

Recomendo fortemente.

Product Management in Practice

Não, não tenho interesse no cargo, mas decidi ler esse livro por curiosidade para entender um pouco melhor sobre esse papel, e reponder a pergunta “por que alguém faria isso a si mesmo?”.

O livro começa bem filosófico, o que não era minha expectativa. Minha expectativa inicial era ler um livro recheado de termos técnicos com muita informação sobre frameworks para o trabalho de gerenciamento de produto em si, mas não foi sobre isso. Na realidade, uns 90% desse livro é só sobre comunicação, interna, externa, entre diferentes camadas de atuação e liderança, com colaboradores e clientes, e sobre gerenciamento de expectativas e de egos, dos nossos e dos outros. Uma verdadeira terapia.

O autor Matt LeMay dá dicas de padrões de comportamentos comuns, tanto positivos quanto negativos, no contexto de produto de uma empresa, e sugere comunicações, frases prontas mesmo, para lidar com diversas situações.

Prompt Engineering for LLMs

No início do ano, por ignorância, eu achava que prompt engineering descrevia apenas a situação de escrever bons prompts para um LLM em um chat na web, porém, entendi que o termo não se refere apenas a essa situação. Esse livro foca em prompt engineering do ponto de vista de uma aplicação intermediária, que manipula o prompt escrito pelo usuário, o adequa para o caso de uso, otimiza para um resposta eficiente e o modela num JSON para realizar uma chamada para um modelo de LLM, como o GPT-4.1. Aborda vários aspectos, tanto de otimização do prompt, como alguns parâmetros de exemplo da API da OpenAI, como atenta para questões de preço pelo token, etc.

No geral achei bem interessante a leitura, importante para sair da completa ignorância no assunto. Não tenha vergonha, somos todos burros, só no LinkedIn todo mundo parece ter mestrado em inteligência artificial.

Identity Security for Software Development

Esse é um livro focado em práticas de segurança em gerenciamento de identidades, tanto humana (como autenticação, autorização, ciclo de vida de usuário, acesso privilegiado, etc) quanto máquina (secrets, certificates, mecanismo de autenticação e autorização para acessar outras máquinas, etc). Esse é o tipo de assunto que ainda está meio amorfo na minha mente, mas esse livro serviu para me dar uma visão mais macro sobre isso: segurança de identidades no código, soluções de gerenciamento, na cloud, no Kubernetes e pipelines de CI/CD.

Concurrency in Go

A autora tem uma escrita excelente e engajante, o que eu não esperava de um livro técnico e prático. É necessário ir rodando e testando os exemplos do livro pois concorrência é assunto muito desconfortável e não-natural, é o típico “só acredito vendo; eu vendo: não acredito”.

Os primeiros capítulos já entregam muito conteúdo e exemplos, e fica claro que este livro é mais adequado a quem já tem conhecimento em programação e na linguagem Go.

Web Security for Developers

Como andei preocupada com temas de segurança em tempos de AI peguei também esse livro para ler. É bastante acessível, sumarizando do zero conceitos basilares, como funcionamento de browsers e protocolos de internet. É um equilíbrio interessante entre dar contexto e depos explicar os tipos de ataques. São 18 capítulos e na parte II vemos com detalhes os tipos.

No geral, um livro excelente e recomendado.

Esse ano farei diferente e irei listar os não-técnicos também, afinal, ler apenas conteúdos técnicos é a forma mais rápida para ficar bitolado e sem diversidade de assuntos. Eis os livros:

• Babel: vou ser honesta, não achei esse livro grande coisa, mas creio que estava tão faminta por livros de ficção que devorei em pouco tempo. A melhor parte do livro para mim foi o tópico de linguística, diretamente entrelaçado com a trama fantasiosa. A autora é a R. F. Kuang;
• Watchmen: um clássico do Alan Moore e Dave Gibbons, porém nunca havia lido. Li a edição DC Campact, que tem o mesmo formato que um livro comum, é muito cozy para ler;
• Leviathan Wakes: já havia lido, então esse foi o segundo round e, nossa, que série fantástica. O Daniel Abraham e Ty Franck sabem como te envolver na trama e fazer um filme na sua cabeça. Ainda irei tatuar a Enterprise, a Serenity e a Rocinante juntas, as melhores naves de ficção de todos os tempos;
• Calibans War: começa mais devagar do que o primeiro livro, mas a construção até a ação é muito boa, com muito mais partes de política internacional, e Avasarala e Bobbie são sensacionais;
• Hipocritões e Olhigarcas: excelente livro do Rui Tavares. Fala sobre guerras culturais (assuntos que exaltam os ânimos, dividem as opiniões com polarização extrema, centrado em temas de identidades, valores e narrativas), coisa diretamente interligada com o desenvolvimento tecnológico da humanidade. Extremamente recomendado;
• Abbadon’s Gate: também começa devagar, com menos tempo com a equipa, mas depois que amarra os fios fica brutal, com muita ação e decisões que são a carinha da humanidade.

Atualmente estou lendo Cibola Burn, pensando nos conflitos internacionais que a colonização de Marte irá causar no nosso mundo. De livro técnico estou lendo Tidy First, mas estou na parte menos interessante, sem código (hehe!).

• Hands-On Dependency Injection in Go
• Clean Code in Python

Para atualizar os exemplos de Python do “Clean Code in Python” utilizaremos também o artigo do Real Python. Aqui iremos falar sobre o open/closed principle, ou princípio aberto/fechado em português. Perguntas para guiar nosso estudo:

• O que é e para que serve o open/closed principle?
• Como aplicar o open/closed principle em Python?
• Como aplicar o open/closed principle em Go?

O que é e para que serve o open/closed principle?

Você já deve ter ouvido a frase “aberto para extensão, fechado para modificação”, mas talvez não tenha entendido perfeitamente o que isso quer dizer. Quando estamos escrevendo uma classe, um módulo, etc, queremos que seja possível extendê-lo porque requisitos mudam e ao longo do tempo sempre surgem novas features, novas funcionalidades e comportamentos para o nosso software. Quando extender um software é muito difícil ou parece impossível de ser feito, temos um problema. Em outras palavras, queremos que seja fácil adicionar comportamentos, mas não queremos modificar o que já existe (podendo quebrar funcionalidades), e é justamente para isso que serve o princípio open/closed.

Corey Scott sobre esse princípio:

Essas duas características podem parecer contraditórias, mas a peça que falta no quebra-cabeça é o escopo. Quando falamos em ser aberto, estamos falando do design ou da estrutura do software. Dessa perspectiva, ser aberto significa que é fácil adicionar novos pacotes, novas interfaces ou novas implementações de uma interface existente.

Como bem sublinha Mariano Anaya, o princípio open/closed é aplicável a diversas abstrações de software, podendo ser uma classe, módulo, função, etc, a ideia é a mesma.

Como aplicar o open/closed principle em Python?

O Mariano Anaya dá um exemplo interessante em seu livro, acompanhe meus comentários no código dele:

from dataclasses import dataclass

# O decorator `dataclass` dá a classe Python uma série de métodos e atributos básicos built-in
# sem que a gente precise escrevê-los na mão, como um `__init__(self, raw_data: dict)`, por exemplo
@dataclass
class Event:
    """`Event` é uma classe que define um evento"""
    raw_data: dict

# Cada classe abaixo herda do `Event` e especifica um tipo de evento. Imagine uma implementação
# hipotética do que cada uma faz ou tem
class UnknownEvent(Event):
    pass

class LoginEvent(Event):
    pass

class LogoutEvent(Event):
    pass

class SystemMonitor:
    """`SystemMonitor` identifica eventos na aplicação"""

    # Inicializando o `SystemMonitor` com um atributo `event_data`
    def __init__(self, event_data):
        self.event_data = event_data

    # Método para identificar um evento: se é um `LoginEvent`, `LogoutEvent` ou `UnknownEvent`
    def identify_event(self):
        if (
            self.event_data["before"]["session"] == 0
            and self.event_data["after"]["session"] == 1
        ):
            return LoginEvent(self.event_data)
        elif (
            self.event_data["before"]["session"] == 1
            and self.event_data["after"]["session"] == 0
        ):
            return LogoutEvent(self.event_data)

        return UnknownEvent(self.event_data)

Agora, imagine que queremos adicionar mais 3 eventos a essa aplicação. Você diria que o SystemMonitor está “aberto para extensão, fechado para modificação”? Pense bem na parte de “modificação”. Para extender o monitoramento, além da inevitável adição de um novo evento (nova subclasse) precisaríamos modificar o SystemMonitor com um novo elif. Para conseguir cumprir o princípio precisamos, de alguma forma, fazer com que a lógica do SystemMonitor “seja uma só” e que a “responsabilidade” da nova feature seja justamente do novo código, do novo evento. Uma forma de fazer isso é como no código abaixo:

from dataclasses import dataclass

# A classe `Event` é a nossa classe "genérica"
@dataclass
class Event:
    raw_data: dict

    # Queremos abstrair a identificação do evento, e aqui exemplificamos uma interface comum para
    # todos os eventos seguirem
    @staticmethod
    def meets_condition(event_data: dict):
        return False

class UnknownEvent(Event):
    pass

class LoginEvent(Event):
    # Agora cada nova subclasse de `Event` implementa seu próprio `meets_condition`. Esse método
    # recebe um dicionário `event_data` e computa uma lógica para definir se é o tipo de evento em
    # questão ou não
    @staticmethod
    def meets_condition(event_data: dict):
        return (
            event_data["before"]["session"] == 0
            and event_data["after"]["session"] == 1
        )

class LogoutEvent(Event):
    @staticmethod
    def meets_condition(event_data: dict):
        return (
            event_data["before"]["session"] == 1
            and event_data["after"]["session"] == 0
        )

# Novo evento. Repare em como basta implementar sua lógica, seguindo a "interface" da classe genérica
class TransactionEvent(Event):
    @staticmethod
    def meets_condition(event_data: dict):
        return event_data["after"].get("transaction") is not None

class SystemMonitor:
    def __init__(self, event_data):
        self.event_data = event_data

    def identify_event(self):
        # Agora para identificar o evento usamos o método mágico (dunder/magic method)
        # `__subclasses__()` para "olhar" as subclasses do `Event`
        for event_cls in Event.__subclasses__():
            try:
                # Chamando a implementação de clada subclasse passando o `event_data`, e a partir
                # daí a lógica é responsabilidade de cada evento
                if event_cls.meets_condition(self.event_data):
                    # Se satisfaz a condição para ser o evento, retorne a subclasse com os dados do
                    # evento
                    return event_cls(self.event_data)
            except KeyError:
                continue
        return UnknownEvent(self.event_data)

Com o exemplo acima não precisamos ficar alterando o SystemMonitor toda vez que um evento novo for criado, bastará apenas criar uma nova subclasse e implementar a interface da classe genérica Event.

Poxa, mas não tem um exemplo mais moderno e mais simples não, sem usar __subclasses__()?

Exatamente o que pensei ao ler o código, e pensei logo no pacote abc do Python. Logo em seguida o autor Mariano Anaya citou a possiblidade de fazer de outras formas, justamente com o abc. Vejamos o exemplo do site Real Python:

from math import pi

class Shape:
    # Inicializamos a class recebendo um `shape_type` e `kwargs`
    def __init__(self, shape_type, **kwargs):
        self.shape_type = shape_type
        # Para definir `height` e `width` vamos de `if` e `elif` até dizer chega
        if self.shape_type == "rectangle":
            self.width = kwargs["width"]
            self.height = kwargs["height"]
        elif self.shape_type == "circle":
            self.radius = kwargs["radius"]

    # Método para calcular a área a depender do tipo de forma
    def calculate_area(self):
        if self.shape_type == "rectangle":
            return self.width * self.height
        elif self.shape_type == "circle":
            return pi * self.radius**2

Consegue ver o padrão se repetir aqui? Adicionar mais tipos de formas, de shapes, faz com que tenhamos que modificar a classe com mais if. Podemos utilizar essa classe para criar diferentes formas, e ela funciona, mas não segue o princípio open/closed. Uma possível solução:

from abc import ABC, abstractmethod
from math import pi

# Finalmente, estamos usando o pacote `abc`! Na nossa classe genérica, `Shape`, também chamada de
# classe abstrata, e herdamos de `ABC`
class Shape(ABC):
    def __init__(self, shape_type):
        self.shape_type = shape_type

    # E aqui criamos um método abstrato com o `abstractmethod`. Quem quiser que implemente 😒💅
    @abstractmethod
    def calculate_area(self):
        pass

# `Circle`, um tipo de `Shape`, herda de `Shape`, nossa classe abstrata
class Circle(Shape):
    def __init__(self, radius):
        # Chamando o construtor da superclasse, passando o tipo de forma
        super().__init__("circle")
        self.radius = radius

    # Implementando o `calculate_area` do `Circle`
    def calculate_area(self):
        return pi * self.radius**2

class Rectangle(Shape):
    def __init__(self, width, height):
        super().__init__("rectangle")
        self.width = width
        self.height = height

    # Implementando o `calculate_area` do `Rectangle` e por aí vai. Quem pegou o bonde andando não
    # senta na janela: implemente sua poha
    def calculate_area(self):
        return self.width * self.height

Agora podemos dizer que nosso Shape aberto para extensão e fechado para modificação.

Como aplicar o open/closed principle em Go?

Agora vamos ver como isso funciona em Go. Vejamos um exemplo do autor Corey Scott de uma função que formata um output a depender do tipo do arquivo:

func BuildOutput(r http.ResponseWriter, format string, p Person) {
	var err error
	switch format {
	case "csv":
		err = outputCSV(r, p)
	case "json":
		err = outputJSON(r, p)
	}
	if err != nil {
		r.WriteHeader(http.StatusInternalServerError)
		return
	}

	r.WriteHeader(http.StatusOK)
}

// Função específica hipotética para csv
func outputCSV(writer io.Writer, person Person) error {
	// TODO: implementar
	return nil
}

// Função específica hipotética para json
func outputJSON(writer io.Writer, person Person) error {
	// TODO: implementar
	return nil
}

type Person struct {
	Name  string
	Email string
}

Se quisermos trabalhar com outro formato, xml, por exemplo, teremos que fazer algumas coisas nesse código acima:

• Adicionar mais um case para cada novo formato;
• Adicionar novas funções de output específicas;
• Os métodos que chamam essa função precisam ser adaptados;
• Novos testes precisarão ser adicionados.

Geralmente, quanto mais coisas precisamos modificar no código para abarcar a mudança, mais difícil fica de não quebrar algo. Existe uma outra forma de escrever esse código:

func BuildOutput(r http.ResponseWriter, pf PersonFormatter, p Person) {
  err := pf.Format(r, p) // Chamamos um método hipotético Format de uma interface PersonFormatter
  if err != nil {
    r.WriteHeader(http.StatusInternalServerError)
    return
  }

  r.WriteHeader(http.StatusOK)
}

// Definindo comportamento/contrato através de uma interface
type PersonFormatter interface {
	Format(writer io.Writer, person Person) error
}

type CSVPersonFormatter struct{}

// Implementação do Format para csv
func (c *CSVPersonFormatter) Format(writer io.Writer, person Person) error {
	// TODO: implement
	return nil
}

type JSONPersonFormatter struct{}

// Implementação do format para JSON
func (j *JSONPersonFormatter) Format(writer io.Writer, person Person) error {
	// TODO: implement
	return nil
}

type Person struct {
	Name  string
	Email string
}

No código acima abstraímos o switch por uma “caixa preta”: definimos um comportamento e quem quiser implementar esse comportamento basta criar seu código específico, seguindo as “regras” da interface. No fim das contas, cortamos a necessidade de ficar adicionando uma lista enorme de switch e precisamos alterar um lugar a menos no código. Quanto menos lugares para alterar, melhor.

O Corey Scott menciona um benefício interessante do open/closed principle: ajudar a reduzir o escopo de novos bugs para apenas o novo código, o que faz bastante sentido já que se adicionarmos um novo formato, como o xml, já sabemos onde precisamos olhar se os testes quebrarem:

...
type XMLPersonFormatter struct{}

func (c *XMLPersonFormatter) Format(writer io.Writer, person Person) error {
	// Se passou a quebrar depois do PR que implementa isso aqui, estamos diante de uma implementação
    // safada com bug
	return nil
}

Flash da Jequiti para lembrar os princípios:

Fontes:

ANAYA, Mariano. Clean Code in Python. Packt, 2021.

SCOTT, Corey. Hands-On Dependency Injection in Go. Packt, 2018.

SOLID Principles: Improve Object-Oriented Design in Python - Real Python

• Hands-On Dependency Injection in Go
• Clean Code in Python

Aqui iremos falar sobre o single responsibility principle, ou princípio de responsabilidade única em português. Perguntas para guiar nosso estudo:

• O que é e para que serve o single responsibility principle?
• Como aplicar o single responsibility principle em Python?
• Como aplicar o single responsibility principle em Go?

O que é e para que serve o single responsibility principle?

De todos os princípios SOLID esse é provavelmente o mais simples de entender. A ideia do single responsibility principle é reduzir complexidade decompondo o código em partes menores, mais fáceis de entender, constatando que um componente de software, uma classe, por exemplo, deve ter apenas uma responsabilidade.

Esse princípio também está relacionado ao separation of concerns, onde temos a ideia de manter a coesão do código definindo bem quais são as “preocupações”, ou responsabilidades, que determinado componente possui.

Uma outra forma de pensar sobre o single responsibility principle (por vezes abreviado para SRP) é que, caso uma classe não siga esse princípio e apresente várias responsabilidades, isso também significa que essa classe tem vários motivos para acarretar mudanças. Se tivesse uma única responsabilidade, caso fosse necessário mudar algo isso seria feito de uma vez só.

Além do já citado, o SRP possivelmente aumenta a reusabilidade de código uma vez que as responsabilidades estão bem separadinhas e desacopladas de um componente específico. E na linha do desacoplamento até escrever testes é potencialmente mais simples.

Como aplicar o single responsibility principle em Python?

Vejamos o código extraído do Clean Code in Python:

class SystemMonitor:
    # Responsabilidade 1
    def load_activity(self):
        pass

    # Responsabilidade 2
    def identify_events(self):
        pass

    # Responsabilidade 3
    def stream_events(self):
        pass

A mesma classe SystemMonitor é responsável por várias coisas e cada uma dessas coisas pode apresentar motivos para mudar, considerando seus contextos e fluxo. Exemplo: imagine que precisamos fazer alguma transformação adicional na hora de fazer stream de eventos; teríamos que adaptar a função stream_events, e assim sucessivamente com cada coisa do “universo” de cada responsabilidade que a class contém.

O ideal seria desacoplar essas múltiplas responsabilidades em outras classes:

O UML acima pode ser interpretado desse forma em Python:

class Event:
    pass

class ActivityWatcher:
    pass

class SystemMonitor:
    pass

class Output:
    pass

class AlertSystem:
    def __init__(self):
        self._activity_watcher = ActivityWatcher()
        self._system_monitor = SystemMonitor()
        self._output_system = Output()
    ...

Como aplicar o single responsibility principle em Go?

Aqui temos um ponto importante: Go não tem classes, mas podemos pensar na aplicação do SRP em Go em termos de objetos (structs, functions, interfaces ou packages). Utilizando um exemplo do Hands-On Dependency Injection in Go:

type Calculator struct {
	data map[string]float64
}

// Responsabilidade 1
func (c *Calculator) Calculate(path string) error {
}

// Responsabilidade 2
func (c *Calculator) Output(writer io.Writer) {
}

As funções acima não estão seguindo o SRP, temos mais de uma responsabilidade sendo implementada nesse struct. Se quisermos adicionar uma forma de printar o output em csv:

type Calculator struct {
	data map[string]float64
}

// Responsabilidade 1
func (c *Calculator) Calculate(path string) error {
}

// Responsabilidade 2
func (c *Calculator) Output(writer io.Writer) {
}

// Adicionando mais responsabilidade
func (c Calculator) OutputCSV(writer io.Writer) {
}

O exemplo abaixo demonstra como desacoplar as várias responsabilidades atreladas ao Calculator:

// Objeto para calcular
type Calculator struct {
    data map[string]float64
}

// Calcular é uma responsabilidade
func (c *Calculator) Calculate(path string) error {
}

func (c *Calculator) getData() map[string]float64 {
}

// Comportamento
type Printer interface {
    Output(data map[string]float64)
}

// Objeto para printar
type DefaultPrinter struct {
    Writer io.Writer
}

// Printar é outra responsabilidade, implementando o comportamento Output
func (d *DefaultPrinter) Output(data map[string]float64) {
}

// Objeto para printar em CSV
type CSVPrinter struct {
  Writer io.Writer
}

// Outra responsabilidade, que implementa seu próprio comportamento Output
func (d *CSVPrinter) Output(data map[string]float64) {
}

Flash da Jequiti para lembrar os princípios:

Fontes:

ANAYA, Mariano. Clean Code in Python. Packt, 2021.

SCOTT, Corey. Hands-On Dependency Injection in Go. Packt, 2018.

• O que é engenharia de dados?
• O ciclo de vida de engenharia de dados

O que é engenharia de dados?

Engenharia de dados não é exatamente uma coisa nova e já existia de alguma forma em empresas, mas tomou mais foco e cresceu mais ou menos no mesmo período em que big data e ciências de dados começaram a aparecer nos holofotes da bolha tech.

De forma resumida, podemos dizer que pessoas engenheiras de dados configuram e operam a infraestrutura de dados de um empresa, preparando esses dados para analistas de dados, cientistas de dados, etc. Segundo Reis e Housley:

Engenharia de dados é o desenvolvimento, implementação e manutenção de sistemas e processos que recebem dados brutos e produzem informações consistentes e de alta qualidade que dão suporte a casos de uso posteriores, como análise e aprendizado de máquina. Engenharia de dados é a interseção de segurança, gerenciamento de dados, DataOps, arquitetura de dados, orquestração e engenharia de software. Um engenheiro de dados gerencia o ciclo de vida da engenharia de dados, começando com a obtenção de dados de sistemas de origem e terminando com o fornecimento de dados para casos de uso, como análise ou aprendizado de máquina

Ou seja, engenharia de dados foca em receber ou extrair dados crus e trabalhar esses dados para que possam ser repassados para vários casos de usos. Considerando toda a infrastrutura que isso abarca, é muito comum que as pessoas profissionais da área tenham um background em engenharia de software, já que ferramentas como Python, SQL, Java, Scala, bash, entre outros, são bastante utilizadas aqui.

O ciclo de vida de engenharia de dados

Há uma imagem no livro Fundamentos de Engenharia de Dados que é excelente para visualizar o ciclo de vida de um pipeline de dados:

Ou seja, uma pessoa engenheira de dados tem algumas responsabilidades técnicas:

• Geração de dados
• Armazenamento de dados
• Ingestão de dados
• Transformação de dados
• Servir dados para diferentes casos de uso

Os casos de uso, que podem ser vistos como downstream de dados servidos por um pipeline desses, incluem análise de dados, machine learning, ciência de dados, reverse ETL (engenharia reversa de ETL), etc.

Fontes:

REIS, Joe; HOUSLEY, Matt. Fundamentos de Engenharia de Dados. O’Reilly, 2022.

• Propósito geral e alto nível
• Tipagem dinâmica e forte
• Linguagem intepretada com um passo de compilação
• Roda em diferentes plataformas

Propósito geral e alto nível

Consideramos Python como de propósito geral pois suas características são úteis para diversas áreas de software. Iremos encontrar Python em REST APIs, scripts, machine learning, análises estatísticas, web scraping, etc. Python já era bastante utilizada na área de inteligência artificial e, com o boom dos LLMs, me parece que muitas áreas tornamram a linguagem como o padrão de uso. Se procurarmos por vagas de machine learning engineer, data engineer e por aí vai é muito comum encontrar o Python como requisito.

A consideramos como de alto nível por possuir um alto nível de abstração, se afastando bastante da linguagem de máquina que um computador de fato entende. Além disso, a linguagem é bem “parecida” com uma leitura em inglês, o que é muito atrativo. Outros exemplos de linguagens de alto nível são Java, JavaScript, entre outras.

Tipagem dinâmica e forte

Acredito que esse tópico gere uma certa dúvida. Eu particularmente precisei revisitar esses conceitos diversas vezes até entender. O Python tem tipagem dinâmica, ou seja, não te obriga a declarar o tipo de uma variável, você pode declarar um a = "texto" e o interpretador, por debaixo dos panos, vai inferir que a variável é do tipo string. Ao mesmo tempo, é fortemente tipada, pois o interpretador mantém controle dos tipos de variáveis que estão sendo declaradas no programa, coisa que não acontece numa linguagem fracamente tipada como o JavaScript, por exemplo. No JavaScript você pode fazer 'x' + 3 resultar em 'x3' e não dará erro; se você tentar fazer isso em Python verá:

TypeError: can only concatenate str (not "int") to str

Sobre ser dinamicamente tipada e fortemente tipada ao mesmo tempo, vejamos esse excerto do Wiki do Python:

Python é fortemente tipado, pois o interpretador mantém o controle de todos os tipos de variáveis. Ele também é muito dinâmico, pois raramente usa o que sabe para limitar o uso de variáveis. Em Python, é responsabilidade do programa usar funções internas como isinstance() e issubclass() para testar tipos de variáveis ​​e uso correto. Python tenta ficar fora do seu caminho enquanto fornece tudo o que você precisa para implementar a verificação de tipo forte.

Falando em “Python tenta ficar fora do seu caminho enquanto fornece tudo o que você precisa para implementar a verificação de tipo forte”, pegamos o gancho para falar de “type hints” ou “type annotations”. Type annotations são uma feature mais recente (PEP 484 de de 2014) do Python que nos permite “anotar” o tipo de dado que estamos lidando no código. Do livro “Python in a Nutshell”:

Anotar seu código Python com informações de tipo é uma etapa opcional que pode ser muito útil durante o desenvolvimento e a manutenção de um projeto grande ou de uma biblioteca. Verificadores de tipo estático e ferramentas lint ajudam a identificar e localizar incompatibilidades de tipo de dados em argumentos de função e valores de retorno. IDEs podem usar essas anotações de tipo (também chamadas de dicas de tipo) para melhorar o preenchimento automático e fornecer documentação pop-up. Pacotes e frameworks de terceiros podem usar anotações de tipo para personalizar o comportamento do tempo de execução ou para gerar automaticamente código com base em anotações de tipo para métodos e variáveis.

É daí que temos libs como mypy e Pydantic para checar e validar tipos.

Linguagem intepretada com um passo de compilação

O Python é considerado interpretado com um passo de compilação: uma linguagem ser interpretada significa que ela não é executada diretamente pela máquina, e sim é interpretada e executada por outro programa. Aqui temos um catch que confunde bastante, pois na real o CPython, que é o interpretador referência da linguagem, é um compilador de bytecode e também interpretador: ele compila o código Python e, com o resultado dessa compilação (que chamamos de bytecode ou intermediary language), roda esse resultado diretamente em uma máquina virtual. Recomendo fortemente a aula do Eduardo Mendes sobre isso:

Aí você pode ser perguntar:

Mas qual a diferença entre esse processo e um processo de compilação de um linguagem como Java?

Para ficar mais claro, veja que em uma linguagem 100% compilada a linguagem intermediária é transformada para linguagem de máquina, para então ser rodada pelo computador de fato. Para ilustrar um pouco melhor esse processo acompanhe esse slide da aula do Eduardo Mendes:

Roda em diferentes plataformas

Se você viu essa afirmação em algum lugar, perceba que isso é dito pois você pode escrever e rodar um programa Python em qualquer computador moderno que tenha Python instalado. “Instalar” significa ter o interpretador Python para rodar a linguagem. Em computadores com sistema operacional baseado em Unix, como Linux e MacOS, é comum que o interpretador Python já esteja instalado em alguma versão. No caso de Windows, até onde sei, você precisa ir lá no site no Python, baixar e instalar o interpretador.

Fontes:

Python in a Nutshell

Why is Python a dynamic language and also a strongly typed language

StackOverflow Compiled vs. Interpreted Languages

Como o interpretador do Python funciona? Live de Python #218

• Fortalecer o foco e forçar a atenção em conteúdos mais difíceis de se consumir;
• Exercitar o “não” a conteúdos de rede social/de conteúdo (exemplo: antes de ir dormir, ler, ao invés de ficar olhando o celular);
• Exercitar meu vocabulário (inglês e português);
• Ter contato inicial com temas específicos;
• Exercitar a reflexão.

Resolvi unir o últil ao agradável e separar alguns livros técnicos para ler durante o ano, por completo. Essas foram as leituras que fiz em 2024:

• Designing Data-Intensive Applications
• Artificial Intelligence Basics
• Database Internals
• Criando Microsserviços

E por fim separei algumas menções honrosas.

Designing Data-Intensive Applications

De longe o melhor que eu li no ano. É o tipo de livro para ser relido pelo menos umas 3 vezes, e isso é o que pretendo fazer. Foi graças a esse livro que consegui entender uma apresentação sobre um tema super complexo envolvendo escalabilidade em escrita de dados, de um time no trabalho. É também uma excelente forma de revisão sobre sistemas distribuídos, assunto que geralmente é tratado na faculdade.

O autor, Martin Kleppmann, escreve muito bem e a leitura não é de um feeling pesado acadêmico, é algo simples de ler com vários exemplos de tecnologias usadas hoje em dia. Não é a toa que esse livro já vendeu muito e tem trocentos bons reviews em várias plataformas. Recomendo a leitura.

Obs.: tem uma nova edição desse livro no forno prevista para dezembro de 2025 e espero que essa edicão seja traduzida para o português.

• Link para o livro Designing Data-Intensive Applications

Artificial Intelligence Basics

Fui de uma leitura bastante técnica e primorosa para um livro OK. Esse livro é bom para deixar a gente refletindo e ter algumas noções básicas sobre o assunto, mas não sei se é uma leitura útil para todas as pessoas da área tech. Para alguém de fora da área pode ser mais interessante. No meu caso foi últil para refletir sobre o assunto, apenas como leitura superficial mesmo, mas achei o último capítulo meio abaixo do resto. No geral, pessoalmente valeu a pena, por ser uma leitura leve e com alguns conceitos introdutórios.

Vale frisar que esse livro foi publicado em 2019, antes do hype de generative AI, então o autor, Tom Taulli, não estava apenas surfando a onda.

Se você é da área tech e quer ler algo profundo sobre AI, vá ler Norvig e Russell. Se quer colocar a mão na massa com algo atual, estou vendo bons reviews sobre Build a Large Language Model (from Scratch) do Sebastian Raschka.

• Link para o livro Artificial Intelligence Basics

Database Internals

É um livro bastante enxuto para os conceitos que trata. Em outras palavras, leitura extremamente difícil para mim, pois me faltavam vários conhecimentos prévios para entender o livro. Exemplo: funcionamento da estrutura de dados b-tree. O livro é pequeno e demorei horrores para terminar, pois estava voltando alguns parágrafos, pesquisando artigos na internet e olhando vídeos no YouTube toda hora para consolidar o entendimento. Felizmente isso me fez encontrar canais bem legais no YouTube como o Spanning Tree, com uma explicação visual bem legal sobre b-trees.

Recomendo para pessoas curiosas, quem trabalha na área de dados, banco de dados, etc. Pode ser uma leitura útil e interessante, mas vai depender bastante da pessoa. No meu caso posso dizer que valeu a pena, mas definitivamente não foi uma leitura que posso considerar “agradável”, já que fiquei empacando.

• Link para o livro Database Internals

Criando Microsserviços

Livro de referência completa para microsserviços e creio que o livro por si só já tenha esse status, a julgar pelos reviews e pelas vezes que já vi sendo citado. A leitura foi bem fácil e fluida, não só pela escrita, mas pelo fato da maioria dos temas e tecnologias já fazerem parte do meu dia a dia, ou pelo menos já ouvi falar e está próximo de mim. Li a versão em português e notei alguns erros, além da sensação esquisita de ver alguns termos traduzidos que eu só vejo em inglês no dia a dia, mas não foi nada que atrapalhasse a leitura.

Recomendo a leitura.

• Link para o livro Construindo Microsserviços

Menções honrosas

Precisei ler alguns capítulos de uns livros para a pós-gradução, então não li estes por completo:

• Cassandra The Definitive Guide: livro excelente e completo sobre o Apache Cassandra. Achei bem complexo entender o Cassandra e esse livro ajudou muito;
• MongoDB The Definitive Guide: livro completinho sobre MongoDB, me ajudou não só com a parte teórica, mas também tirei várias dúvidas quando estava fazendo o projeto prático.

• Configurando o Apache Cassandra com Docker
• O que é o Spark?
• Configurando o Jupyter com Pyspark no Docker
• Iniciando um sessão Spark conectada no Cassandra

Antes de começar, essa é a estrutura de pastas do projetinho:

cassandra-jupyter-spark-python
├── .gitignore
├── Makefile
├── README.md
├── data
│   └── csv-here.md
├── docker-compose.yml
├── jupyter
│   └── Untitled.ipynb
└── pyproject.toml

Você pode encontrar um projeto similiar a esse, completo, com análise de dados (porcamente feita por mim) no GitHub.

Configurando o Apache Cassandra com Docker

O Cassandra é um banco de dados NoSQL decentralizado, com escalabilidade elástica, altamente disponível, tolerante a falhas e orientado a linhas particionadas; escrevi um texto sobre o Cassandra aqui e você pode verificar a documentação do Cassandra aqui.

Para subir o Cassandra com Docker podemos fazer o seguinte:

services:
  cassandra1:
    image: cassandra:4.0.14
    container_name: cassandra1
    networks:
      - cassandra_network
    environment:
      - CASSANDRA_CLUSTER_NAME=cassandra_cluster
      - CASSANDRA_SEEDS=cassandra1
      - CASSANDRA_DC=datacenter1
      - CASSANDRA_RACK=rack1
      - CASSANDRA_ENDPOINT_SNITCH=GossipingPropertyFileSnitch
    volumes:
      - ./data:/data
    ports:
      - "9042:9042"

No código acima estamos criando um node do Cassandra 4.0.14 (versão escolhida para evitar problemas de compatibilidade nesse projeto) numa rede Docker chamada cassandra_network. Explicando as variáveis de ambiente no environment:

• CASSANDRA_CLUSTER_NAME: define o nome do cluster onde um ou mais nodes do Cassandra irão rodar. Cluster se refere a mais de uma máquina, geralmente para se referir a um sistema distribuído. No “docker-compose” do projeto chamamos de “cassandra_cluster”;
• CASSANDRA_SEEDS: indica os serviços (ou IPs) usados pelo gossip do Cassandra, para adicionar novos nodes ao cluster. O gossip é um protocolo utilizado para manter informações sobre o status dos nodes no cluster, para dar suporte a descentralização e tolerância a particionamento;
• CASSANDRA_DC: define o data center do node, que é um agrupamento lógico de racks. Não é necessário para rodar essa infraestrutura localmente em um notebook, como é o caso atual, mas seria utilizado caso estivéssemos utilizando o Cassandra com o uso adequado a que se propõe;
• CASSANDRA_RACK: define o rack do node, que é um agrupamento lógico de nodes. Novamente, não é necessário para a situação atual, mas seria utilizado em um caso real;
• CASSANDRA_ENDPOINT_SNITCH: define a implementação de snitch que esse node irá utilizar. O snitch provê informações sobre a topologia da rede onde o Cassandra está para redirecionar requisições de forma mais eficiente. Nesse caso aqui configuramos como “GossipingPropertyFileSnitch”, geralmente usado em produção, para considerar as informações de rack e datacenter.

O volume ./data:/data serve para que você coloque, por exemplo, arquivos .csv parte da sua análise de dados. No meu caso, criei um projeto para a pós-graduação, onde usei o comando COPY para repassar os dados tratados do .csv para o Cassandra.

Agora, criando um segundo node Cassandra:

cassandra2:
  image: cassandra:4.0.14
  container_name: cassandra2
  networks:
    - cassandra_network
  environment:
    - CASSANDRA_CLUSTER_NAME=cassandra_cluster
    - CASSANDRA_SEEDS=cassandra1
    - CASSANDRA_DC=datacenter1
    - CASSANDRA_RACK=rack1
    - CASSANDRA_ENDPOINT_SNITCH=GossipingPropertyFileSnitch
  volumes:
    - ./data:/data
  ports:
    - "9043:9042"
  depends_on:
    - cassandra1

Você pode usar somente um node, já que está rodando em seu computador, mas vale lembrar que um node só perde o propósito de uso do Cassandra. Esse banco é feito para ter diversos nodes no cluster.

Veja que esse segundo node aponta os seeds para o outro node. Isso é para que o cassandra2 se conecte com o cassandra1, para descrobrir a topologia do cluster e se unir a esse cluster.

O que é o Spark?

O Apache Spark é uma engine para engenharia e análise de dados, ciência de dados e machine learning em larga escala, onde é possível rodar para máquinas com um único nó ou cluster. Podemos usar Python, SQL, Scala, Java e R para interagir com o Spark, e aqui nesse projeto usaremos Python, com Pyspark.

Usos do Spark, segundo sua documentação:

• Batch/streaming: unifica o processamento dos dados em lotes e streaming em tempo real, usando Python, SQL, Scala, Java ou R
• Análise de SQL: executa consultas ANSI SQL rápidas e distribuídas para painéis e relatórios ad-hoc
• Ciência de dados em escala: executa Análise Exploratória de Dados (EDA) em dados em escala de petabytes sem precisar recorrer à redução de amostragem
• Aprendizado de máquina: treine algoritmos de aprendizado de máquina em um laptop e use o mesmo código para escalar para clusters tolerantes a falhas de milhares de máquinas.

Configurando o Jupyter com Pyspark no Docker

O Jupyter é uma tecnologia para computação interativa onde usamos uma linguagem de programação para, geralmente, fazer análises de dados e experimentos do tipo. Para rodá-lo no Docker:

  # Docker Hub Image. Uses spark-3.5.0-bin-hadoop3
  jupyter_pyspark:
    image: jupyter/pyspark-notebook:latest
    container_name: juptyer_pyspark
    environment:
      JUPYTER_ENABLE_LAB: "yes"
    ports:
      - "8888:8888"
    networks:
      - cassandra_network
    volumes:
      - ./jupyter:/home/jovyan
    depends_on:
      - cassandra1

networks:
  cassandra_network:
    driver: bridge

Essa imagem do Jupyter já vem com o Spark, mas vale apontar que aqui estamos usando a imagem do Docker Hub, que não recebe atualizações e está parada no Spark 3.5.0 e Hadoop 3, e não da Quay, que recebe atualizações. Tive muitos problemas tentando manter a compatibilidade entre as ferramentas, e a imagem do Docker Hub funcionou para o propósito.

O volume, assim como nos cassandras, é para poder salvar os notebooks no host. O container está na mesma rede que os outros e o JUPYTER_ENABLE_LAB é para que a gente não precise fazer login ou usar token, bastará abrir o browser no http://localhost:8888:

Iniciando uma sessão Spark conectada no Cassandra

Com o docker-compose.yml finalizado, podemos rodar os containers:

docker compose up --build

No http://localhost:8888, abrindo um novo arquivo no Jupyter, vamos importar uma sessão Spark da lib pyspark:

from pyspark.sql import SparkSession

E configurar a sessão:

spark = SparkSession.builder.appName("test").config("spark.jars.packages", "com.datastax.spark:spark-cassandra-connector_2.12:3.5.0").config("spark.cassandra.connection.host", "cassandra1").config("spark.cassandra.connection.port", "9042").getOrCreate()

Muita atenção aqui nessa parte. O código acima está:

• Iniciando uma sessão Spark
• Criando um novo “app” (o projeto em si) chamado “test”
• Configurando o Spark com um pacote jar, utilizando um conector de Spark para Cassandra
• Conectando com o serviço Cassandra chamado cassandra1
• Configurando a porta da conexão para o 9042, que é onde está nosso container
• Criando a conexão

Note que estamos usando um conector específico:

spark-cassandra-connector_2.12:3.5.0

Podemos olhar essas versões no site do Maven, e aqui nesse ponto foi onde mais topei com erros, especialmente de compatibilidade.

Se tudo der certo no comando anterior, depois rode esse comando para ver a sessão ativa:

spark.active()

Você verá algo assim:

Fontes:

Imagem Docker do Cassandra

Image Docker do Jupyter com Spark

Apache Spark

• O que é o Apache Cassandra?
• “Row-oriented”: o que isso significa?
• Quando utilizar o Cassandra?

O que é o Apache Cassandra?

O Cassandra é um banco de dados NoSQL de código aberto, decentralizado, com escalabilidade elástica, altamente disponível, tolerante a falhas e orientado a linhas particionadas, onde os dados são armazenados em tabelas hash multidimensionais esparsas. Vamos discutir esses pontos.

Bancos NoSQL (not only SQL) são bancos que não seguem os padrões de bancos relacionais, resolvendo problemas um pouco diferentes (em breve farei um texto sobre isso), sendo mais flexíveis (ou totalmente livres) no quesito de schema (como os dados são organizados, restrições lógicas como nome de tabelas, campos e seus tipos, etc), também chamados de schemaless ou de schema on read (schema reforçado apenas na leitura, e não na escrita como os relacionais). No caso do Cassandra podemos dizer que atualmente ele possui um schema flexível.

O Cassandra é capaz de rodar em várias máquinas como um sistema só, por isso é considerado distribuído e foi feito pensando nisso. Faz pouco sentido rodar o Cassandra em um único nó (node).

Grande parte de seu design e base de código são projetados especificamente não apenas para funcionar em muitas máquinas diferentes, mas também para otimizar o desempenho em vários racks de data center e até mesmo para um único cluster Cassandra em execução em data centers geograficamente dispersos. (CARPENTER and HEWITT, 2022)

O Cassandra também é descentralizado porque cada node é idêntico, no sentido de que nenhum node realiza tarefas especializadas como operações de organização; em outras palavras, o Cassandra possui uma arquitetura peer-to-peer. Como nenhum node é especializado podemos dizer que não há um único ponto de falha aqui (single point of failure).

Ser elasticamente escalável significa que o sistema pode continuar servindo para mais usuários sem degradar a performance, podendo escalar e desescalar perfeitamente, sem problemas.

A alta disponibilidade do Cassandra é devido a sua alta capacidade de atender requests. Isso está diretamente relacionado com teorema CAP: assumindo uma situação de partitioning, o Cassandra prioriza availability em detrimento de consistency. Entretanto, vale a pena esclarecer que a consistência no Cassandra é ajustável (tuneable consistency, é uma configuração). Em minhas leituras entendi que atualmente o CAP theorem é como knobs, como se pudéssemos ajustar um pouco mais uma ou outra configuração. Recomendo ler um pouco mais sobre o teorema CAP no capítulo 9 do Designing Data Intensive Application.

“Row-oriented”: o que isso significa?

Na pesquisa para fazer esse artigo e entender melhor o assunto encontrei informações discrepantes, o que me levou a crer que há muita confusão aqui e talvez seja bom evitar algumas fontes da internet. Felizmente estamos seguindo um livro base. Pela definição de Carpenter e Hewitt:

O modelo de dados do Cassandra pode ser descrito como um armazenamento de linha particionado, no qual os dados são armazenados em tabelas hash multidimensionais esparsas. “Esparso” significa que para qualquer linha dada você pode ter uma ou mais colunas, mas cada linha não precisa ter todas as mesmas colunas que outras linhas como ela (como em um modelo relacional). “Particionado” significa que cada linha tem uma chave de partição exclusiva usada para distribuir as linhas em vários armazenamentos de dados. (CARPENTER and HEWITT, 2022)

Ou seja, quando for ter uma “imagem mental” dos dados no Cassandra faz sentido pensar numa linha de banco relacional, dadas as devidas diferenças: cada linha pode ter uma ou mais colunas e não precisa ter as mesmas colunas que outra linha, além de ter uma chave de partição única.

Sobre a confusão de termos que citei anteriormente, você pode ter visto o termo column oriented, mas o livro base desse texto aborda isso:

O Cassandra tem sido frequentemente chamado de banco de dados orientado a colunas ou colunar, mas isso não é tecnicamente correto. O erro é baseado na confusão entre termos que soam semelhantes. Um banco de dados orientado a colunas é aquele em que os dados são armazenados por colunas, ao contrário de bancos de dados relacionais, que armazenam dados em linhas (daí o termo orientado a linhas). Bancos de dados orientados a colunas, como Apache HBase ou Apache Kudu, são projetados para casos de uso analítico. (CARPENTER and HEWITT, 2022)

Quando utilizar o Cassandra?

O Cassandra pode ser um bom fit para o seu projeto caso você precise lidar com:

• Grandes deployments: você precisa de muitos e muitos nodes para a sua aplicação, com a expectativa de escalar muito de forma fácil
• Muita escrita, estatística e análise: sua aplicação precisa de muita estatística e muita escrita concorrent, com poucas leituras. Exemplos: pesquisa documentos, uso de redes sociais, recomendações/avaliações, etc
• Distribuíção geográfica: o Cassandra tem suporte para distribuição geográfica de dados built in
• Nuvem híbrida e deployment multicloud: você precisa fazer deploy não só em múltiplos data centers, mas também em provedores de cloud diferentes. Exemplo: você precisa da maior disponibilidade possível para um aplicativo mission critical e por isso utiliza mais de um proveador (se houver problemas com um provedor ainda haverá o outro)

Fontes:

CARPENTER, Jeff; HEWITT, Eben. Cassandra: The Difinitive Guide. O’Reilly, 2022.

KLEPPMANN, Martin. Designing Data-Intensive Applications. O’Reilly, 2017.

What is a database schema? por IBM

• Transações (transactions)
• ACID
• Two-phase commit (2PC)
• Schema
• Sharding

Transações (transactions)?

Banco de dados relacionais suportam transações (transactions), que são como uma unidade de operação completa num banco relacional, que executa primeiro “virtualmente” e permite que a operação seja desfeita (rollback) se qualquer modificação tenha dado errado. No caso de dar tudo certo com todos os passos da transação, ela pode ser comitada (commited) com segurança no banco. Em outras palavras, uma transação pode ser compreendida como uma transformação de estado que possui as propriedades ACID.

ACID

ACID é um acrônimo para atômico, consistente, isolado e durável. Você pode encontrar a expressão ACID compliant para se referir a um banco que dê suporte a essas propriedades.

• Atômico (atomicity): significa “tudo ou nada” em uma transação. Se uma transação é executada, todas as operações que ela contém precisam ser um sucesso. Ou todas as operações são um sucesso ou a transação falha (pense em OR exclusivo aqui).
• Consitente (consistency): uma transação bem sucedida leva os dados de um estado consistente para outro, sem a possibilidade de usuários verem dados diferentes que não fazem sentido juntos.
• Isolado (isolation): as transações que forem executadas concorrentemente não afetarão umas as outras. Ou seja, se uma transação tentar modificar os mesmos dados que outra, ela terá que esperar.
• Durável (durable): uma transação bem sucedida não será perdida, por exemplo, caso ocorra algum desastre com o data center que contém o banco.

Two-phase commit (2PC)

Lidar com transações é um pouco mais difícil quando temos grandes cargas, com vários usuários realizando muitas operações no banco, e quando vamos escalar horizontalmente (adicionando mais máquinas e agora lidando com um sistema distribuído) para lidar com essa carga passamos a lidar também com transações distribuídas (distributed transactions). Com isso, para manter o banco com propriedades ACID, precisamos ter algum gerenciador de transações para conseguir orquestrar essas transações em vários nodes diferentes.

É aqui que entra a ideia de two-phase commit, que é um algortimo pensado para lidar com consenso entre nodes (máquinas) em um sistema distribuído. O 2PC possui duas fases, duas interações entre hosts: fase de preparação e fase de commit, as quais bloqueiam os recursos associados. Com esse lock (bloqueio) de recursos já podemos imaginar que algumas operações podem levar muito tempo para terminar.

Abaixo uma ilustração do livro Designing Data Intensive Application:

O 2PC espera um node responder, mesmo que o node já tenha morrido e, para não ter um loop rodando para sempre, esperando o node ficar vivo, podemos configurar um timeout. Ainda assim é possivel que ocorra um loop infinito pois um node pode responder OK para commitar a transação, esperar o gerenciador (coordenador) de transações e, se o coordenador está down, o node vai esperar para sempre. Para lidar com esse tipo de problema no mundo relacional temos a ideia de *compensation*, onde a transação é imediatamente comitada, e no caso de um erro ser reportado, uma nova operação é feita para retificar o estado.

Alguns problemas que o 2PC introduz:

• Perda de disponibilidade (availability)
• Maior latência (tempo para chegar de um ponto a outro na rede) em falhas parciais

Para manter o banco relacional ACID compliant é necessário levar em consideração esses problemas que surgem no cenário de um sistema distribuído.

Schema

Você pode representar seus objetos de domínio em um modelo relacional, onde temos entidades e relacionamentos. Geralmente nos referimos ao modelo relacional como schema on write, em contraste com o schema on read de bancos NoSQL, que são mais flexíveis. Schema on write é a característica de ter um schema mais rígido que é reforçado na hora da escrita no banco:

As bases de dados relacionais assumem frequentemente que todos os dados na base de dados estão em conformidade com um esquema: embora este esquema possa ser alterado (através de migrações de esquemas; ou seja, instruções ALTER), existe exatamente um esquema em vigor. Por outro lado, as bases de dados schema-on-read (“sem esquema”) não impõem um esquema, então a base de dados pode conter uma mistura de formatos de dados mais antigos e mais recentes escritos em diferentes momentos(…) (KLEPPMANN, 2017)

Sharding

Sharding é uma forma de escalar o banco de dados relacional dividindo os dados, ao invés de tê-los em um único servidor, ou tê-los replicados em todos os servidores do cluster. É como se dividíssemos porções dos dados horizontalmente, hospedados separadamente em mais de um node.

É necessário pensar muito bem qual será a lógica para dividir os dados. De nada adianta, por exemplo, dividir dados de forma que as partes mais acessadas (hot spots) continuem juntas, já que não iremos “desafogar”, escalar, o banco de fato.

Existem algumas estratégias bem conhecidas de sharding:

• Por feature (segmentação funcional)
• Por chave (key-based)

Recomendo fortemente a leitura do livro Designing Data Intensive Applications para navegar em assuntos complementares a esse texto:

Fontes:

CARPENTER, Jeff; HEWITT, Eben. Cassandra: The Difinitive Guide. O’Reilly, 2022.

KLEPPMANN, Martin. Designing Data-Intensive Applications. O’Reilly, 2017.

Abordarei os seguintes tópicos:

• O que é um processo?
• O que são threads?
• O que significa I/O bound e CPU bound?
• O que é o GIL do Python?
• O que é concorrência?
• O que é paralelismo?
• A biblioteca asyncio
• A biblioteca threading
• A biblioteca multiprocessing

O que é um processo?

Em computação um processo é uma instância de uma aplicação rodando. Se você abrir uma aplicação no seu computador, como o navegador, essa aplicação vai estar associada a algum processo. Um processo é composto por:

• Contexto de hardware: armazena conteúdo de registradores gerais e específicos da CPU
• Contexto de software: especifica os recursos que podem ser alocados pelo processo
• Espaço de endereçamento: especifica a área da memória que o processo pertence

A imagem a seguir foi retirada do livro do Francis Machado e do Luis Maia:

Essas informações são necessárias para a execução de um programa.

O que são threads?

Uma thread é uma sub-rotina de um programa, sendo a menor unidade de execução que um sistema operacional gerencia e componente de um processo.

As várias threads de um processo hipotético podem ser executadas concorrentemente (que entenderemos em breve), compartilhando recursos como memória. Diferentes processos não compartilham esses recursos.

A imagem abaixo foi retirada do Wikipedia:

Interpretando a imagem acima, podemos extrair que um programa fica salvo em disco (memória secundária, não-volátil) e inclui várias instruções, podendo ser instanciado (iniciado) em um ou mais processos, e esses por sua vez podem ter várias threads associadas.

O que significa I/O bound e CPU bound?

Essas duas expressões aparecem bastante na discussão sobre concorrência e podem aparecer em português com E/S (entrada/saída) e UCP (unidade central de processamento).

Quando falamos sobre I/O bound e CPU bound estamos falando dos fatores limitantes que previnem uma operação de rodar mais rápido em nosso computador, e podemos encontrar esse dois tipos de operações na mesma codebase.

Uma operação CPU bound faz uso intenso da CPU, e rodará mais rápido se a CPU for mais poderosa. Ou seja, se formos de 2GHz para 4GHz de velocidade de clock essa operação provavelmente rodará mais rápido. Estamos falando aqui de operações que realizam muitas computações, cálculos; a exemplo, como calcular Pi.

Uma operação I/O bound depende da velocidade da rede e velocidade dos dispositivos de entrada e saída. Fazer um request a um servidor web ou ler um arquivo do disco são operações I/O bound.

Ambos os tipos de operações podem se beneficiar do uso de concorrência.

O que é o GIL do Python?

GIL significa global interpreter lock (bloqueio do interpretador global), cujo objetivo é prevenir um processo Python de executar mais de um bytecode de instrução Python ao mesmo tempo. Para rodar uma thread é necessário “adiquirir” o GIL e enquanto uma thread detém o GIL outra thread não pode adiquiri-lo ao mesmo tempo. Isso não significa que não podemos ter mais de uma thread nesse contexto.

Aqui estamos considerando a implementação de referência do Python. O CPython é a implementação padrão do Python, usada como referência de como a linguagem se comporta. Existem outras implementações, como Jython ou IronPython. O GIL está presente no CPython e só recentemente tivemos uma PEP (Python Enhancement Proposal - proposta de melhoria do Python) propondo tornar o GIL opcional.

A ideia do GIL é prevenir race conditions, que podem surgir quando mais de uma thread precisa referenciar um objeto Python ao mesmo tempo. Se mais de uma thread modificar uma variável compartilhada essa variável pode ficar em um estado inesperado. Imagem retirada do livro do Matthew Fowler:

Na imagem acima duas threads estão tentando incrementar uma reference count simultaneamente, e aí ao invés da contagem dar 2, já que as duas estão incrementando 1, o resultado final dá 1 (cada thread é uma coluna).

O que é concorrência?

Concorrência em computação acontece quando lida-se com mais de uma tarefas, sem necessariamente estar executando essas duas tarefas exatamente ao mesmo tempo. Uma frase conhecida do Rob Pyke sobre o assunto:

Concorrência significa lidar com muitas coisas ao mesmo tempo. Paralelismo é fazer muitas coisas ao mesmo tempo.

Pense nessa situação hipotética: se você for fazer dois bolos, pode começar pré-aquecendo o forno e, enquanto isso, prepara a massa do primeiro bolo. Assim que o forno estiver na temperatura correta você já pode colocar a massa do primeiro bolo no forno e, enquanto aguarda o bolo crescer no forno, já pode preparar a massa do segundo bolo. A ideia de concorrência é basicamente essa, você não precisa ficar ocioso, travado, parado, enquanto aguarda uma tarefa completar, você pode fazer um switch e trocar de tarefa.

Nesse contexto, temos dois tipos de multitasking:

• Cooperative multitasking: nesse modelo explicitamos no código os pontos onde se pode fazer o switch de tarefas. No Python isso é alcançado com o uso de um event loop, um design pattern comum, usando apenas uma thread e um core de CPU, usando, por exemplo, o asyncio com async e await
• Preemptive multitasking: nesse modelo deixamos o sistema operacional lidar com o switch. No Python isso é alcançado com mais de uma thread e um core de CPU usando, por exemplo, a lib threading

A imagem abaixo ajuda a sumarizar concorrência em Python:

O que é paralelismo?

Paralelismo significa que mais de uma task está sendo executada ao mesmo tempo. Em outras palavras, paralelismo implica concorrência (lidar com mais de uma task), mas concorrência não implica paralelismo (tasks não estão necessariamente sendo executadas em paralelo, ao mesmo tempo). Para que paralelismo seja possível precisamos de mais de um core de CPU.

No Python paralelismo é alcançado, por exemplo, com a lib multiprocessing, onde teremos mais de um processo Python, cada um com seu GIL. A imagem ajuda a ilustrar paralelismo em Python:

A biblioteca asyncio

Existem formas diferentes de se atingir concorrência e paralelismo em Python e podemos utilizar algumas bibliotecas para otimizar nosso código, a depender do tipo de operação que estamos lidando, I/O bound ou CPU bound. O asyncio é uma lib para atingir concorrência usando o async e await. Pela documentação:

O asyncio é usado como uma base para várias estruturas assíncronas do Python que fornecem rede e servidores web de alto desempenho, bibliotecas de conexão de banco de dados, filas de tarefas distribuídas etc.

Como você pode imaginar, essa lib é adequada para otimizar tarefas I/O bound, onde temos tempo de espera de network, escrita em disco, etc. Numa operação CPU bound não há espera, dependemos apenas da velocidade de cálculo da CPU.

A biblioteca threading

A lib threading do Python nos permite operar mais de uma thread, porém, continuamos a lidar com um core de CPU e um processo Python, e lembre-se de que esse é um caso de preemptive multitasking onde o sistema operacional faz a troca de tarefas por nós. A lib também é mais útil para otimizar operações I/O bound.

Sobre o threading, o site Real Python traz alguns pontos importantes:

Porque o sistema operacional está no controle de quando uma task será interrompida e outra task irá começar, qualquer dado que for compartilhado entre as threads precisa ser protegido, ou thread-safe. Infelizmente requests.Session() não é thread-safe. Existem várias estratégias para fazer o acesso de dados thread-safe a depender de que dado é e como você está usando. Uma delas é usar estruturas de dados thread-safe como Queue do módulo queue do Python.

Encontramos a documentação do queue aqui.

A biblioteca multiprocessing

Sobre a lib multiprocessing na documentação do Python:

multiprocessing é um pacote que suporta gerar processos usando uma API similar ao módulo threading. O pacote multiprocessing oferece concorrência tanto local quanto remota, efetivamente desviando o GIL usando sub-processos ao invés de threads. Por isso o módulo multiprocessing permite o programador aproveitar múltiplos processadores em uma máquina.

Vale apontar que rodar mais de um processo em diferentes cores de CPU não significa desabilitar o GIL, e sim que cada processo terá o seu próprio GIL. Por aproveitar de mais de um core de CPU, compartilhando workloads pesados de CPU entre os múltiplos cores dispiníveis, a lib é mais adequada a CPU bound.

Fontes:

FOWLER, Matthew. Python Concurrency with asyncio. Manning Publications, 2022.

MACHADO, Francis Berenger; MAIA, Luiz Paulo. Arquitetura de Sistemas Operacionais: Incluindo Exercícios com o Simulador SOSIM e Questões do ENADE. Rio de Janeiro: LTC, 2013.

Thread (computing) por Wikipedia

Speed Up Your Python Program With Concurrency por Real Python