SÓCRATES: Dois papiros e nenhum aberto. Ou os dois são ruins, ou tu não sabes qual ler primeiro.

GLAUCO: Nenhum dos dois, Sócrates. São bons demais, e esse é o problema. Este é de Dámon, com quem estudo há três anos. Aquele é de Teófilo, que conheci no inverno. Nunca ouvi ninguém explicar as coisas como esses dois.

SÓCRATES: E qual é a aflição de ter dois bons mestres ?

GLAUCO: Ontem citei Teófilo diante de Dámon. Ele fez silêncio, depois disse que Teófilo é um charlatão e que eu perderia meu tempo. Hoje contei a Teófilo, e ele riu e disse que Dámon é um velho que repete o que leu aos vinte anos. Cada um deles é tudo o que admiro. E cada um despreza o outro.

SÓCRATES: E o que tu concluis disso ?

GLAUCO: Que um dos dois está errado, e que preciso descobrir qual, para seguir o certo.

SÓCRATES: Diz-me primeiro uma coisa. Por que procuraste um mestre ?

GLAUCO: Porque não se aprende sozinho. Quem já percorreu o caminho poupa os outros de tropeçar nas mesmas pedras.

SÓCRATES: Isso é verdade, e é bom que tenhas procurado. Mas responde com honestidade: quando encontraste Dámon, foi só o caminho que te interessou, ou também o descanso ?

GLAUCO: Que descanso ?

SÓCRATES: O descanso de não precisar mais decidir. Ter alguém a quem perguntar “está certo ?” e aceitar a resposta. Dormir sabendo que, se errares, o erro foi de quem te ensinou.

GLAUCO: Não gosto de como soa, mas sim. Havia descanso nisso.

SÓCRATES: Não te envergonhes. Todo homem quer esse descanso, e é por isso que todo homem procura um mentor com tanta pressa. Não é só o saber que buscamos; é alguém em quem pousar o peso de julgar. E repara: enquanto tinhas um só mestre, o descanso funcionava. O que o quebrou foi o segundo.

GLAUCO: Porque agora um diz uma coisa e o outro diz outra.

SÓCRATES: Não. Sobre a maior parte das coisas, os dois dizem o mesmo, ou tu não admirarias ambos. O que quebrou o teu descanso foi outra coisa: descobriste que a admiração que sentes por um não obriga o outro a sentir o mesmo. Tu querias que teus mestres se amassem como tu os amas. Eles não têm esse dever.

GLAUCO: Mas se Dámon é sábio, e diz que Teófilo é charlatão, não devo ao menos considerar ?

SÓCRATES: Deves, e também deves considerar o contrário. Mas vamos devagar. Quando Dámon te ensina geometria, de onde vem a autoridade dele ?

GLAUCO: De saber geometria.

SÓCRATES: E quando ele te diz que Teófilo é charlatão, de onde vem a autoridade ?

GLAUCO: De… conhecer Teófilo, suponho.

SÓCRATES: E conhece ? Já o ouviu ensinar ? Já leu o que ele escreve ? Ou conhece a fama, uma frase dita numa discussão, a lembrança de uma rixa antiga que ninguém mais sabe como começou ?

GLAUCO: Não sei. Nunca perguntei.

SÓCRATES: Então aqui está a primeira coisa a guardar. Um homem pode ser mestre em uma arte e ser tão ignorante quanto qualquer um numa segunda. Saber geometria não torna ninguém juiz de caráter. Quando tu aceitas o juízo de Dámon sobre Teófilo com a mesma confiança com que aceitas o teorema, estás estendendo a autoridade dele para um terreno onde ele não a conquistou. E ele, se for honesto, não a reivindicaria.

GLAUCO: Então nem um nem outro está errado sobre geometria. Estão errados um sobre o outro.

SÓCRATES: Talvez. Ou talvez um deles tenha razão, e tu ainda não saibas. Mas repara no que acabaste de fazer: há um minuto, o problema era “qual dos dois seguir”. Agora é “o que cada um sabe de fato, e sobre o quê”. É uma pergunta melhor.

GLAUCO: É uma pergunta que me devolve o trabalho.

SÓCRATES: Esse trabalho sempre foi teu, Glauco. Tu só o tinhas emprestado. Já conversamos, noutra tarde, sobre a tábua da praça: o rótulo que alguém te cola não te dispensa de examinar. O mesmo vale para o rótulo que um mestre cola no outro. “Charlatão” e “velho que repete” são pedras atiradas, não razões. Pede as razões. Se vierem, pesa-as. Se não vierem, deixa as pedras no chão.

GLAUCO: E se eu pesar e concluir que Dámon, que tanto me ensinou, errou sobre Teófilo ? O que faço com isso ?

SÓCRATES: O que fazes quando o teu cavalo tropeça ?

GLAUCO: Levanto-o e sigo. Não vendo o cavalo.

SÓCRATES: E por que venderias o mestre ? Glauco, ouve bem isto, porque é a parte que mais custa aos jovens: o teu mestre vai errar. Não “pode errar”, vai. Vai errar sobre pessoas, vai errar sobre fatos, vai ter dias de ciúme, de cansaço e de teimosia. E quando isso acontecer, tu terás duas saídas erradas e uma certa. A primeira errada é fingir que não viste, para proteger o descanso. A segunda errada é derrubar o homem inteiro, porque uma coluna rachou. A certa é mais difícil: continuar a aprender geometria com quem sabe geometria, e guardar para ti o juízo sobre as pessoas.

GLAUCO: Soa como ter menos confiança nele.

SÓCRATES: Soa como ter a confiança certa, em vez da confiança inteira. A confiança inteira é a que se dá aos deuses, e nem a esses tanto. Dar a um homem a confiança que cabe a um deus não é honrá-lo. É condená-lo a te decepcionar, porque ele não tem como pagar a dívida que tu mesmo inventaste.

GLAUCO: Então o mentor é um homem como eu.

SÓCRATES: Que foi um pouco mais longe num caminho. Só isso, e isso já é muito. Repara que é justamente o erro que te permite reconhecer nele um igual. Um mestre que nunca errasse não seria mestre, seria um oráculo, e diante de oráculos não se aprende, obedece-se. Um homem que erra e corrige, que mostra onde tropeçou, te ensina duas vezes: ensina a arte e ensina que a arte cabe numa vida humana. O erro é a prova de que o caminho que ele percorreu é um caminho que tu também podes percorrer.

GLAUCO: Nunca tinha pensado que o erro do mestre fosse um presente.

SÓCRATES: Não é um presente, é um fato. Mas é um fato que te liberta, se o aceitares. Enquanto o teu mestre for perfeito, tu serás eternamente aluno. No dia em que o vires errar, e continuares a respeitá-lo mesmo assim, terás começado a ter opinião própria. E ter opinião própria sobre as pessoas, inclusive sobre quem mais admiras, é o começo de ser alguém, e não a sombra de alguém.

GLAUCO: E Teófilo ? Continuo a ouvi-lo ?

SÓCRATES: Continua a ouvir os dois. Aprende de cada um o que cada um sabe. E quando um falar mal do outro, faz o que farias com qualquer outra afirmação: pergunta “por quê ?”, escuta, e decide tu. É possível que um dia descubras que um deles tinha razão. É possível que descubras que os dois estavam sendo pequenos, como homens às vezes são. Nos dois casos terás aprendido algo que nenhum deles poderia te ensinar: que os teus olhos também valem.

GLAUCO: E se os meus olhos errarem ?

SÓCRATES: Vão errar, e então serás como eles. É isso que nos faz humanos, Glauco: não a ausência do erro, mas o dever de julgar mesmo sabendo que podemos errar, e a decência de continuar a honrar quem errou antes de nós.

..então Glauco guardou os dois papiros na mesma sacola, Sócrates comentou que a sacola parecia mais leve, e os dois foram tomar uma cerveja.

Glossário

• ágora: praça central das cidades gregas, onde se reunia o povo
• papiro: material em que se escrevia antes do papel, enrolado em rolos
• oráculo: lugar ou pessoa que, na Grécia antiga, dava respostas tidas como vindas dos deuses

Nota

Este diálogo é uma continuação do Diálogo sobre os Rótulos e a Verdade. Lá, a questão era o rótulo que os outros colam em nós. Aqui, é o rótulo que as pessoas que admiramos colam umas nas outras.

Todo mundo procura um mentor, e a necessidade é legítima: ninguém aprende tudo sozinho. O problema não está em confiar, está na quantidade. É muito fácil entregar a alguém que admiramos não só o que ele sabe, mas também o que ele acha, inclusive sobre outras pessoas. E quando duas pessoas que respeitamos não se respeitam, o conforto de ter um guia desaba, porque descobrimos que o juízo delas sobre o mundo não era um só.

A saída não é escolher um lado nem abandonar os dois. É aceitar que todos erram, o mentor incluído, e que ter opinião própria sobre as pessoas, formada com as nossas razões e os nossos olhos, não é desrespeito. É a única forma de respeito que não exige que o outro seja mais do que humano.

Sempre admirei a medicina, especialmente aqueles médicos que dedicam seus esforços, seu tempo e cada célula do próprio corpo à busca pela excelência. Entre as especialidades, uma sempre despertou minha admiração: a cardiologia.

Um dos nomes que carrego como referência é o de Enéas Carneiro. Muitos o admiravam por sua inteligência, mas eu sempre enxerguei nele algo que considero ainda mais importante e menos questionável: a vontade.

Enéas tinha vontade. Sabia o que queria, defendia suas convicções e desejava um Brasil melhor. Além disso, dedicou parte de sua vida ao estudo do coração, tornando-se cardiologista.

Mas a vida encontrou uma maneira de transformar essa admiração em algo muito mais profundo.

No dia 13 de novembro de 2025, nasceu minha filha, Luna, com uma cardiopatia congênita grave. Ela precisou passar por uma cirurgia cardíaca no Hospital Vila da Serra, em Nova Lima, Minas Gerais.

Naquele momento, tudo aquilo que eu admirava na medicina deixou de ser algo distante, quase abstrato, e passou a fazer parte da minha própria história.

O que antes eu admirava, hoje eu venero.

Creio que Deus abençoou a equipe de cardiologistas daquele hospital. Homens e mulheres que dedicaram suas vidas ao conhecimento, à ciência e ao aperfeiçoamento de suas habilidades e que, por meio de tudo aquilo que o ser humano foi capaz de aprender e desenvolver, receberam a oportunidade de salvar a vida da minha filha.

É difícil encontrar palavras que expressem a dimensão da minha gratidão. Existe algo profundamente admirável em alguém que dedica a própria existência a adquirir conhecimentos e habilidades que, um dia, poderão significar a diferença entre a vida e a morte de outra pessoa.

Deixo aqui meu mais profundo respeito e minha eterna gratidão aos profissionais da saúde, especialmente à equipe que cuidou da Luna, e a todas as pessoas que estão dentro dos hospitais movidas por uma intenção verdadeira e por um propósito maior: salvar vidas.

Se antes eu admirava a medicina pelo conhecimento e pela excelência de seus profissionais, hoje a admiro também por algo que nenhuma teoria seria capaz de me ensinar: a oportunidade de continuar vendo minha filha crescer.

“O dado mais importante que separa o ser humano de todos os seus irmãos e primos da escala filogenética é o conhecimento; só o conhecimento liberta o homem, só através do conhecimento o homem é livre e, em sendo livre, ele pode aspirar a uma condição melhor de vida para ele e todos os seus semelhantes. Só consigo entender uma sociedade na qual o conhecimento seja a razão de ser precípua que o governo dá para a formação do cidadão. Minha mensagem é positiva: é de que o homem tem de saber, conhecer e, em conhecendo, ele é livre.”

— Dr. Enéas Ferreira Carneiro (Rio Branco, 5 de novembro de 1938 — Rio de Janeiro, 6 de maio de 2007)

Arquiteturas de referência

Três jeitos de ligar as ferramentas acima num stack que funciona. Todas têm as mesmas três camadas, ingestão, processamento e armazenamento, mais o que quer que consuma o resultado.

1. Lakehouse em batch

ELT noturno e de hora em hora. O padrão quando a latência é medida em horas.

  flowchart TB
  subgraph ing["Ingestão"]
    airbyte["Airbyte"]
    debezium["Debezium + Kafka Connect"]
  end
  subgraph proc["Processamento"]
    spark["Apache Spark"]
    dbt["dbt"]
    ge["Great Expectations"]
  end
  subgraph sto["Armazenamento"]
    iceberg["Apache Iceberg"]
    s3["MinIO / S3"]
    polaris["Apache Polaris"]
  end
  subgraph out["Consumo"]
    trino["Trino"]
    superset["Apache Superset"]
  end

  airbyte --> spark
  debezium --> spark
  spark --> dbt --> ge --> iceberg
  s3 -.- iceberg
  polaris -.- iceberg
  iceberg --> trino --> superset

O Apache Airflow fica fora do desenho, disparando cada seta acima.

2. Streaming

Segundos em vez de horas. Dois ramos saindo de um único job: a tabela para o histórico, o store OLAP para o dashboard.

  flowchart TB
  subgraph ing["Ingestão"]
    debezium["Debezium"]
    kafka["Apache Kafka"]
  end
  subgraph proc["Processamento"]
    flink["Apache Flink"]
  end
  subgraph sto["Armazenamento"]
    paimon["Apache Paimon no S3"]
    clickhouse["ClickHouse"]
  end
  subgraph out["Consumo"]
    trino["Trino"]
    grafana["Grafana"]
  end

  debezium --> kafka --> flink
  flink --> paimon --> trino
  flink --> clickhouse --> grafana

O Airflow continua necessário aqui, não para agendar o job, mas para rodar a compactação e a expiração de snapshots que a tabela precisa, porque o job nunca para de escrever.

3. ML e inferência

Features escritas pelo mesmo pipeline que alimenta o treino, e um modelo servido a partir de um registry.

  flowchart TB
  subgraph ing["Ingestão"]
    kafka["Apache Kafka"]
  end
  subgraph proc["Processamento"]
    flink["Apache Flink"]
    spark["Apache Spark"]
  end
  subgraph sto["Armazenamento"]
    feast["Feast"]
    delta["Delta Lake no S3"]
    qdrant["Qdrant"]
  end
  subgraph train["Treino"]
    ray["Ray"]
    mlflow["MLflow Registry"]
  end
  subgraph serve["Serving"]
    kserve["KServe"]
    vllm["vLLM"]
  end

  kafka --> flink
  kafka --> spark
  flink --> feast
  flink --> qdrant
  spark --> delta
  delta --> ray --> mlflow --> kserve
  feast --> kserve
  qdrant --> vllm

Repositórios oficiais

• Airbyte: ELT baseado em conectores para carregar dados num warehouse ou lake.
• Amundsen: Descoberta de dados e busca de metadados para analistas.
• Apache Airflow: Agenda e monitora pipelines escritos como DAGs em Python.
• Apache Arrow: Formato colunar em memória compartilhado entre engines e linguagens.
• Apache Atlas: Governança de metadados e linhagem para o ecossistema Hadoop.
• Apache Avro: Formato de serialização orientado a linhas que carrega o próprio schema.
• Apache Beam: Um único modelo de pipeline que roda em várias engines de batch e streaming.
• Apache Doris: Banco analítico MPP voltado a relatórios em tempo real.
• Apache Flink: Processamento de streams com estado, event time e exactly-once.
• Apache Hudi: Formato de tabela de lake com upserts e leituras incrementais.
• Apache Iceberg: Formato de tabela aberto com commits ACID, evolução de schema e time travel.
• Apache Kafka: Log distribuído para publicar e consumir streams de eventos.
• Apache NiFi: Roteamento e transformação baseados em fluxo, com editor visual.
• Apache ORC: Formato de arquivo colunar feito para leituras grandes no estilo Hive.
• Apache Paimon: Formato de tabela de lake projetado para ser escrito continuamente pelo Flink.
• Apache Parquet: O formato de arquivo colunar em que a maior parte do lake é armazenada.
• Apache Polaris: Catálogo aberto para que várias engines vejam as mesmas tabelas Iceberg.
• Apache Pulsar: Mensageria e streaming com armazenamento separado do serving.
• Apache Spark: Engine geral para batch, SQL e ML sobre grandes volumes de dados.
• Apache Superset: BI web com dashboards e exploração em SQL.
• Argo Workflows: Roda workflows nativos de contêiner como objetos do Kubernetes.
• BentoML: Empacota um modelo e suas dependências num serviço.
• ClickHouse: Column store para consultas analíticas rápidas em escala.
• Dagster: Orquestrador construído em torno de data assets em vez de tarefas.
• Dataform: Workflows de transformação em SQL com gestão de dependências.
• DataHub: Plataforma de metadados para catálogo, linhagem e ownership.
• dbt: Transforma selects em SQL em modelos testados, documentados e versionados.
• Debezium: Lê os logs de mudança do banco e os publica como eventos.
• Deequ: Checagens de qualidade de dados expressas como jobs Spark.
• Delta Lake: Camada de armazenamento transacional sobre arquivos Parquet.
• Dremio: Engine de consulta e camada semântica sobre o armazenamento do lake.
• DuckDB: Banco analítico que roda dentro do seu processo, sem servidor.
• Feast: Feature store que serve as mesmas features para treino e inferência.
• Flyte: Workflows tipados e versionados para dados e ML no Kubernetes.
• Grafana: Dashboards sobre métricas, logs e traces.
• Great Expectations: Declara expectativas sobre os dados e as valida.
• Hive Metastore: O catálogo de tabelas e partições que muitas engines ainda leem.
• Hopsworks: Feature store e plataforma de ML.
• Jupyter: Notebooks para análise interativa.
• KServe: Serve modelos no Kubernetes com autoscaling e canaries.
• Kubeflow: Plataforma de ML montada a partir de componentes do Kubernetes.
• Kubeflow Pipelines: Compõe e executa pipelines de ML como contêineres.
• LightGBM: Gradient boosting otimizado para velocidade em dados tabulares grandes.
• Marquez: Servidor de referência que coleta e armazena eventos OpenLineage.
• Metabase: BI que deixa quem não é engenheiro fazer perguntas ao banco.
• Metaflow: Workflows em Python para data science, da Netflix.
• Milvus: Banco vetorial para busca por similaridade em escala.
• MinIO: Object storage compatível com S3 que você mesmo roda.
• MLflow: Acompanha experimentos, empacota modelos e mantém o registry.
• NumPy: Arrays e computação numérica, a base do stack Python.
• NVIDIA Triton: Servidor de inferência para modelos em GPU e CPU.
• OpenLineage: Padrão aberto para pipelines reportarem o que leram e escreveram.
• OpenMetadata: Catálogo, linhagem, qualidade e governança num lugar só.
• OpenTelemetry: Padrão neutro de fornecedor para traces, métricas e logs.
• Pandas: DataFrames para manipulação de dados em Python.
• pgvector: Tipos e índices vetoriais dentro do PostgreSQL.
• Polars: DataFrames rápidos escritos em Rust, com engine de consulta lazy.
• Prefect: Orquestração para workflows em Python, feita para execuções dinâmicas.
• Presto: Engine SQL distribuída que consulta os dados onde eles estão.
• Project Nessie: Branches e commits no estilo Git para tabelas do lake.
• Prometheus: Banco de séries temporais e alertas para métricas.
• Python: A linguagem em que a maior parte deste stack é escrita e operada.
• PyTorch: Framework de deep learning com grafos dinâmicos.
• Qdrant: Engine de busca vetorial com filtros, escrita em Rust.
• R: Linguagem e ambiente para estatística.
• Ray: Runtime distribuído em Python para treino, tuning e serving.
• Redpanda: Broker compatível com Kafka sem JVM e sem ZooKeeper.
• Scikit-learn: Algoritmos clássicos de machine learning em Python.
• SciPy: Computação científica construída sobre o NumPy.
• Seldon: Faz deploy e monitora modelos no Kubernetes.
• Soda: Checagens de qualidade de dados escritas como regras legíveis.
• SQLMesh: Transformações com linhagem por coluna e ambientes virtuais.
• StarRocks: Banco OLAP MPP para consultas abaixo de um segundo sobre o lake.
• TensorFlow: Framework de deep learning com toolchain de produção.
• Trino: SQL distribuído que federa consultas entre muitas fontes.
• vLLM: Serving de alto throughput para grandes modelos de linguagem.
• Weaviate: Banco vetorial com módulos de embedding embutidos.
• XGBoost: Biblioteca de gradient boosting, o cavalo de batalha dos dados tabulares.

O Kafka Connect vem dentro de apache/kafka, o dbt Tests dentro de dbt-core e o Ray Serve dentro de ray-project/ray, então compartilham os repositórios acima.

Sem repositório público, por serem proprietários ou serviços gerenciados: Power BI, Tableau, Fivetran, Amazon S3, Google Cloud Storage, Azure Data Lake Storage, AWS Glue Catalog, Databricks, Starburst, Snowflake, BigQuery, Redshift, Tecton, Pinecone, Weights & Biases, Neptune, Comet, Vertex AI, SageMaker e Azure ML.

GLAUCO: Sócrates, achei a ferramenta que resolve tudo. Li a documentação ontem à noite, subi um exemplo em vinte minutos e funcionou de primeira. Vou reescrever o sistema inteiro em cima dela.

SÓCRATES: Vinte minutos. Quando você faz test drive de um carro, quanto tempo dura ?

GLAUCO: Uns quinze minutos. Uma volta no quarteirão com o vendedor do lado.

SÓCRATES: E você já descobriu algum defeito de carro numa volta no quarteirão ?

GLAUCO: Nunca. Os defeitos aparecem depois. Na estrada, na chuva, no trânsito parado.

SÓCRATES: Então nesses vinte minutos você conheceu a ferramenta, ou conheceu o percurso que o autor dela escolheu pra você fazer ?

GLAUCO: O percurso. Mas gostei do percurso.

SÓCRATES: Gostar já é alguma coisa. Deixa eu te fazer umas perguntas, então. Só não me responde o que você imagina. Me responde o que você sabe.

GLAUCO: Pode perguntar.

SÓCRATES: Quantos registros passaram por ela no seu teste ?

GLAUCO: Uns mil.

SÓCRATES: E num dia comum, lá dentro ?

GLAUCO: Uns dez milhões.

SÓCRATES: E o que ela faz quando não dá conta ? Segura o que está chegando, descarta, ou cai junto ?

GLAUCO: Não sei. Nunca cheguei nesse ponto.

SÓCRATES: Ninguém chega, no teste. E repara: a escala não inventa defeito nenhum. Ela promove os que já estavam ali e ninguém via. Uma operação lenta em mil registros é invisível. Em dez milhões, ela é o sistema inteiro. Você não vai descobrir defeitos novos em produção, vai descobrir o tamanho real dos que já tinha.

SÓCRATES: Em que linguagem ela foi escrita ?

GLAUCO: Isso importa ? Ela roda num contêiner, eu nem preciso saber.

SÓCRATES: É a única parte dela que você não vai poder trocar depois. A linguagem já decidiu, antes de você chegar, um monte de coisa que você só vai sentir em produção. Qual é ?

GLAUCO: Rust.

SÓCRATES: Então ela é compilada, e isso te dá coisas boas de graça. Vai chegar como um arquivo só, sem interpretador nem dependência solta pra você carregar junto, e sobe num piscar. Ferramenta interpretada te obriga a cuidar dela e do interpretador dela pelo resto da vida.

GLAUCO: Ótimo. Então é a escolha certa.

SÓCRATES: É uma escolha, e toda escolha tem o outro lado virado pra baixo. Aquele arquivo único carrega dentro dele as bibliotecas que o autor escolheu, nas versões que ele escolheu, no dia em que ele compilou. Quando aparecer um problema numa dessas bibliotecas, você não troca a peça. Você espera ele compilar de novo.

GLAUCO: Não tinha pensado nisso.

SÓCRATES: É o mesmo pacote, olhado do outro lado. Segunda coisa: Rust não tem coletor de lixo(Garbage Collector).

GLAUCO: Isso é bom, não é ?

SÓCRATES: É bom pra uma coisa específica. Linguagem com coletor tem um faxineiro que limpa a casa na hora que ele escolhe, não na hora que você pede, e isso aparece como uma lentidão que chega sem avisar e vai embora sozinha, justo quando o volume cresce. Sem coletor, o tempo de resposta é previsível, e previsível vale muito.

GLAUCO: Então não tenho com que me preocupar de memória.

SÓCRATES: Tem, e de um tipo mais silencioso. Sem coletor nada é varrido por acaso: o que a ferramenta segurar, ela segura até o fim. Uma fila sem limite ou um cache que ninguém mandou parar não aparecem como pausa, aparecem como uma linha subindo devagar por uma semana até alguém ser acordado de madrugada. Coletor de lixo é barulhento e avisa. A falta dele é silenciosa.

GLAUCO: Dá pra saber isso antes ?

SÓCRATES: Duas perguntas resolvem. Quanta memória ela consome depois de uma semana ligada, e não nos dez primeiros minutos. E quantos núcleos ela usa de verdade, porque uma coisa é a linguagem saber usar oito, outra é a ferramenta ter sido escrita pra isso.

GLAUCO: Isso muda o desenho inteiro.

SÓCRATES: Muda, e é bem melhor mudar agora, enquanto ainda é papel. Próxima: como uma pessoa prova pra ela que é quem diz ser ?

GLAUCO: Usuário e senha, criados ali dentro mesmo.

SÓCRATES: E na sua empresa, como as pessoas provam isso em todo o resto ?

GLAUCO: Pelo LDAP.

SÓCRATES: Então ela vai ser o único lugar da empresa onde uma pessoa existe duas vezes, e quem for desligado numa sexta vai sair de todos os lugares menos de um. Agora a outra metade: depois que a pessoa entra, quem decide o que ela pode fazer ?

GLAUCO: Quem entra pode tudo, eu acho.

SÓCRATES: Você acabou de tratar como uma coisa só o que são duas. Uma é quem entra. Outra é o que cada um faz depois de entrar. Ferramenta de uma pessoa não precisa separar as duas, porque a pessoa é você.

GLAUCO: É que ninguém no meu time ia fazer estrago de propósito.

SÓCRATES: Quase nunca é de propósito. Permissão não existe por desconfiança, existe pra limitar o tamanho do erro de uma pessoa distraída numa terça-feira. Quando todo mundo pode tudo, todo mundo carrega o poder de derrubar tudo, e ninguém pediu esse poder.

GLAUCO: Nunca tinha pensado assim.

SÓCRATES: E quando alguém apagar o que não devia, você descobre quem foi ?

GLAUCO: Não sei se ela guarda isso.

SÓCRATES: Pergunta. Registro não existe pra acusar ninguém, existe justamente pra que ninguém precise ser acusado. Sem ele, no dia do problema todo mundo que tinha acesso é suspeito, e a conversa vira memória contra memória. Memória é a testemunha mais interessada que existe.

SÓCRATES: Quando saiu a última versão dela ?

GLAUCO: Faz uns dois meses, acho.

SÓCRATES: E antes dessa ?

GLAUCO: Não olhei.

SÓCRATES: Olha, porque o intervalo entre as versões é o relógio no qual você vai amarrar o seu. E olha uma coisa mais fina: entre uma versão grande e outra, saem versões pequenas, só com correção ?

GLAUCO: Não reparei.

SÓCRATES: Repara. Se saírem, no dia de um problema sério você atualiza uma casa decimal e volta a dormir. Se não saírem, o conserto só chega junto da próxima versão grande, com tudo que ela muda de quebra, e um problema de uma tarde vira uma migração inteira num dia que você não escolheu.

GLAUCO: Isso eu consigo verificar hoje.

SÓCRATES: Verifica junto com esta: quantas pessoas de fato mantêm isso ?

GLAUCO: O repositório tem oito mil estrelas e centenas de contribuidores.

SÓCRATES: Estrela é aplauso, e aplauso não conserta nada. Contribuidor, na maioria dessas listas, é qualquer um que já corrigiu uma vírgula na documentação. Conta outra coisa: nos últimos seis meses, quantos nomes diferentes mexeram no core da ferramenta ? E desses, quantos sobram depois que você tira o primeiro ?

GLAUCO: Não sei. Imagino que poucos.

SÓCRATES: Se sobrar um, você não escolheu uma ferramenta. Escolheu uma pessoa, e essa pessoa não assinou nada com você.

GLAUCO: Falta muita pergunta ?

SÓCRATES: Uma. Você disse que ela faz quase tudo que você precisa. E o quase ?

GLAUCO: O que faltar eu abro uma issue e peço.

SÓCRATES: Sempre ? Toda vez que aparecer uma necessidade nova, o caminho vai ser pedir e esperar ?

GLAUCO: É o que dá pra fazer.

SÓCRATES: Então repara no que você aceitou: o ritmo do que você entrega passa a ser decidido por gente que não conhece o seu problema e não deve nada a você. Existe outro caminho, e ele é a diferença entre uma ferramenta e uma parede: um lugar onde você mesmo escreve o que faltou. Um plugin, um encaixe, um script que ela chama na hora certa. Quando esse lugar existe, o que falta hoje é trabalho seu. Quando não existe, o que falta hoje é espera.

GLAUCO: Sócrates, eu não soube responder quase nada.

SÓCRATES: E é a melhor coisa que te aconteceu hoje. Repara que você não descobriu que a ferramenta é ruim. Descobriu que você não conhece ela. São coisas muito diferentes, e só uma das duas tem conserto.

GLAUCO: Mas eu estava seguro.

SÓCRATES: Estava seguro do que viu, e você viu vinte minutos escolhidos por outra pessoa. Todo mundo está seguro no começo. A diferença é que uns descobrem as perguntas antes de instalar, e outros descobrem depois, com o sistema inteiro em pé em cima delas.

GLAUCO: Então eu desisto dela ?

SÓCRATES: Não foi isso que eu disse. Talvez ela seja ótima. Vai atrás de cada resposta e volta com elas. Se forem boas, você instala sabendo o que instalou. Se forem ruins, você já sabe onde vai doer, e às vezes se instala mesmo assim, de propósito, porque doer naquele lugar é aceitável.

GLAUCO: E se eu errar mesmo tendo perguntado tudo ?

SÓCRATES: Vai errar de vez em quando, e tudo bem. Põe o novo onde o erro sai barato, numa borda que você desliga numa tarde sem acordar ninguém, e deixa o meio chato e previsível. Antes de perguntar o que uma ferramenta faz, pergunta quanto custa sair dela. Essa é a única resposta que ninguém escreve na documentação.

GLAUCO: Vou refazer o diagrama.

SÓCRATES: Hoje não. Guarda uma semana e abre de novo. Entusiasmo é bom combustível e péssimo motorista.

..então Sócrates fechou o notebook, Glauco salvou o diagrama sem apagar nada, e os dois foram tomar uma cerveja.

Nota

A ideia foi pegar o modelo de diálogo de A República, de Platão, e aplicar num caso de tecnologia. Só a forma é emprestada: perguntas curtas, uma ideia de cada vez, a resposta do interlocutor abrindo a pergunta seguinte.

O caso é familiar pra quem trabalha com isso. Toda semana aparece uma ferramenta nova, open source, com interface bonita, exemplo que sobe em cinco minutos e um gráfico de estrelas subindo. Nesse ponto parece tudo resolvido, e o entusiasmo é legítimo.

As coisas ficam mais complicadas quando as perguntas começam. Como ela se comporta em escala. O que acontece no dia em que você precisa de algo que o autor não previu. Quanto tempo um bug report leva pra virar correção, e se alguém sequer responde. Quantos mantenedores de verdade existem por trás dos números do repositório, e de quantas empresas diferentes eles são. Quem decide o rumo do projeto, e em que lugar essa decisão é discutida. Como ela faz autenticação, e se isso conversa com o login que o resto da empresa já usa. O que ela faz quando um pedaço dela cai. Se dá pra auditar depois quem fez o quê lá dentro. E quanto trabalho é, de fato, integrá-la ao que você já tem de pé.

Quase nenhuma dessas respostas está na primeira página. A maioria aparece uns seis meses depois, quando trocar já não sai de graça.

Como usar: nem todo repo precisa de todos os itens. Os itens marcados com (A) são avançados, valem para projetos OSS, monorepos ou qualquer coisa com contribuidores externos. Tudo que não está marcado é o mínimo.

As seções marcadas como condicionais só se aplicam quando o repo é aquele tipo de projeto (um serviço HTTP, um app em contêiner, um workload Kubernetes).

Índice

• 1. Documentação
  • 1.1 README.md
  • 1.2 Arquivos de governança e política
  • 1.3 Docs mais profundas (docs/)
  • 1.4 Changelog e releases
• 2. Código
  • 2.1 Layout e convenções
  • 2.2 Configuração
  • 2.3 Fonte única de verdade / código gerado (A)
• 3. Testes
  • 3.1 Testes unitários
  • 3.2 Integração e end-to-end
  • 3.3 Performance e robustez (A)
  • 3.4 Cobertura
• 4. Artefatos de API (condicional: serviços HTTP/gRPC)
• 5. Build e runtime (condicional: apps em contêiner)
  • 5.1 Docker
  • 5.2 Docker Compose
  • 5.3 Kubernetes (condicional)
• 6. CI/CD
  • 6.1 Checagens básicas
  • 6.2 Segurança
  • 6.3 Dependências
  • 6.4 Automação do repositório (A)
• 7. Metadados do repositório
• Conjunto mínimo viável

1. Documentação

1.1 README.md

• Visão geral do projeto: o que ele faz e, mais importante, por que existe
• Badges de status: build do CI, cobertura de testes, última release, nível de estabilidade
• Nível de estabilidade / maturidade (development → alpha → beta → stable → deprecated)
• Política de suporte: quem mantém, onde perguntar, tempo de resposta esperado
• Instruções de instalação
• Como rodar o app localmente
• Como configurar o ambiente (.env.example commitado, .env no git-ignore)
• Exemplos de uso (copiáveis e realmente testados)
• Diagrama de arquitetura ou uma seção curta de “como as peças se encaixam”
• Link para o guia de contribuição
• Informação de licença
• Um README por módulo/subpacote, não só na raiz (A)
• Seções de status geradas automaticamente, delimitadas por marcadores, para nunca ficarem defasadas (A)

1.2 Arquivos de governança e política

• LICENSE (+ NOTICE se você redistribui código de terceiros)
• CONTRIBUTING.md: setup local, como rodar os testes, regras de título e descrição de PR, expectativas de review
• CODEOWNERS: ownership por diretório, dispara pedidos de review automáticos
• SECURITY.md: como reportar uma vulnerabilidade, em privado
• CODE_OF_CONDUCT.md
• AGENTS.md / CLAUDE.md: política de contribuição assistida por IA (trailer de divulgação, o que agentes podem e não podem fazer)
• .github/pull_request_template.md
• .github/ISSUE_TEMPLATE/: bug report, feature request, mais um config.yml apontando para os canais de suporte
• Política de triagem de issues: labels, prioridades, política de stale (A)
• Papéis de mantenedor/aprovador e como chegar lá (A)

1.3 Docs mais profundas (docs/)

• Processo de release, escrito e repetível
• Guia de testes: como rodar cada camada de teste localmente
• Guia de onboarding para novos módulos/componentes (A)
• ADRs (Architecture Decision Records): o porquê por trás do design
• Runbook / docs operacionais: alertas, dashboards, falhas comuns
• Docs de referência geradas: cada opção de config, default e métrica emitida, produzidas a partir da fonte de verdade em vez de escritas à mão (A)

1.4 Changelog e releases

• CHANGELOG.md seguindo SemVer / Keep a Changelog
• Fragmentos de changelog: um arquivo pequeno por PR, montados na hora da release. Mata conflitos de merge e obriga o autor a declarar o impacto para o usuário (A)
• Changelog separado para mudanças de API/breaking vs. mudanças visíveis ao usuário (A)
• Releases com tag e release notes geradas a partir do changelog
• Política de versionamento e de deprecação documentada

2. Código

2.1 Layout e convenções

• Layout de projeto consistente e documentado
• Cabeçalho de licença/SPDX em todo arquivo-fonte, cobrado pelo linter
• Comentário de documentação por pacote (doc.go ou equivalente)
• Config do linter commitada, com conjunto explícito de linters e exceções justificadas por caminho, não os defaults da ferramenta
• Formatador cobrado no CI, não deixado para o revisor
• Restrições de import cobradas (nenhum import proibido/interno vazando) (A)
• Um task runner (Makefile / justfile / npm scripts) com alvos padrão: test, lint, fmt, build, run, integration-test, tidy
• Os mesmos comandos funcionam na raiz e dentro de cada módulo (A)

2.2 Configuração

• Struct de config tipada com Validate() explícito e mensagens de erro claras
• Falhar rápido com config inválida na inicialização, nunca no meio de um request
• Config de exemplo commitada, carregada por um teste de verdade
• Schema de config publicado (JSON Schema / equivalente) para autocomplete no editor e validação no CI (A)
• examples/ com configurações completas baseadas em cenário: não trechos
• Segredos nunca em arquivos de config nem no repo; injetados em runtime
• Logging estruturado, métricas e tracing plugados e documentados

2.3 Fonte única de verdade / código gerado (A)

• Arquivo de metadados declarativo por componente (owners, estabilidade, config, telemetria emitida)
• Código, docs e seções do README gerados a partir dele
• O CI verifica que a saída gerada está atualizada: defasagem vira build quebrado em vez de documentação velha

3. Testes

3.1 Testes unitários

• Testes unitários que realmente afirmam comportamento, não só executam linhas
• Testes table-driven para lógica cheia de ramificações
• Determinísticos: sem sleeps, sem relógio real, sem rede
• Fixtures de teste (testdata/) versionadas, com um comando para regenerá-las

3.2 Integração e end-to-end

• Testes de integração isolados atrás de uma build tag / comando separado para não atrasarem a execução unitária
• Dependências reais via contêineres efêmeros (Testcontainers ou equivalente)
• Testes end-to-end contra um deploy realista (A)
• Testes de contrato para APIs consumidas e fornecidas (A)

3.3 Performance e robustez (A)

• Benchmarks para os caminhos quentes, com um jeito documentado de comparar execuções
• Testes de carga com uma baseline de performance declarada
• Testes de fuzz para tudo que faz parse de entrada externa
• Detecção de vazamento: goroutines, conexões, file descriptors
• Race detector habilitado no CI

3.4 Cobertura

• Relatório de cobertura gerado no CI e publicado
• Limite de cobertura commitado no repo, dividido em alvos de projeto e de patch (ex.: 85% no total, 95% no diff)
• Cobertura por módulo/componente, para um repo grande não esconder um canto ruim atrás de uma média boa (A)

4. Artefatos de API (condicional: serviços HTTP/gRPC)

• Spec OpenAPI / Swagger, versionada no repo
• Spec gerada a partir do código ou validada contra ele, para não ficar defasada
• Coleção do Postman / Insomnia / Bruno
• Arquivos de request .http (executáveis a partir do editor)
• curl.txt com exemplos copiáveis
• Fluxo de autenticação documentado
• Catálogo de erros: códigos, significados e como se recuperar
• Versionamento e caminho de deprecação documentados para os endpoints

5. Build e runtime (condicional: apps em contêiner)

5.1 Docker

• Dockerfile com build multi-stage
• Imagem base mínima e pinada (distroless/slim), usuário non-root
• .dockerignore
• Healthcheck definido
• Builds reproduzíveis: dependências pinadas, nada de latest
• Scan de vulnerabilidade da imagem no CI (A)
• SBOM gerado e publicado junto com a imagem (A)

5.2 Docker Compose

• docker-compose.yml que sobe o stack inteiro com um comando
• Overrides por ambiente (docker-compose.dev.yml, .prod.yml)
• Dependências (banco, broker, cache) incluídas, para um dev novo não precisar de mais nada

5.3 Kubernetes (condicional)

• Manifests, ou um Helm chart com values.yaml documentado
• Requests e limits de recursos definidos
• Probes de liveness / readiness / startup
• Gestão de segredos (External Secrets, SOPS, sealed-secrets, nunca em texto puro)
• Configuração de Ingress
• Overlays por ambiente (Kustomize) ou arquivos de values
• NetworkPolicy, PodDisruptionBudget, security context (A)
• Manifests lintados e validados no CI (kubeconform, helm lint) (A)

6. CI/CD

6.1 Checagens básicas

• Lint
• Checagem de formatação
• Testes unitários
• Relatório de cobertura + cobrança do limite
• Build do artefato (binário e/ou imagem)
• Testes de integração, num job separado
• Status checks obrigatórios configurados na branch protegida
• Matriz de build entre os SOs/versões suportados (A)
• Detecção de escopo: rodar só o que o diff realmente afeta (A)
• Sharding de jobs para manter o tempo de parede são em repos grandes (A)

6.2 Segurança

• Scan de vulnerabilidades em dependências
• SAST (CodeQL ou equivalente)
• Secret scanning habilitado
• Checagem de conformidade de licença nas dependências
• Os próprios arquivos de workflow lintados (actionlint, zizmor) (A)
• Scripts shell lintados (shellcheck) (A)
• permissions: mínimas por workflow; actions de terceiros pinadas por SHA
• OpenSSF Scorecard (A)

6.3 Dependências

• Atualizações automáticas (Renovate / Dependabot) com estratégia de agrupamento
• Lockfile commitado
• Checagem automática de tidy/prune para o manifesto não ficar defasado
• Checagem de compatibilidade da API pública entre versões (A)

6.4 Automação do repositório (A)

• Atribuição automática de revisores a partir do CODEOWNERS
• Labels automáticas em PRs e issues por área afetada
• Avisar os owners em issues novas que tocam a área deles
• Tratamento de issues/PRs stale
• Boas-vindas a contribuidores de primeira viagem
• Congelamento de merge durante a janela de release
• Relatório periódico de saúde do repo (issues abertas, áreas sem dono)
• Preparação de release automatizada (bump de versão, montagem do changelog, tag)

7. Metadados do repositório

• Topics/tags com as tecnologias usadas, para ser encontrável
• Descrição do repositório clara, de uma linha
• Regras de proteção na branch padrão
• Commits assinados ou tags assinadas (A)
• Aviso de arquivamento/deprecação quando um repo deixa de ser mantido

Conjunto mínimo viável

Se você só fizer dez coisas, faça estas:

1. README que coloca alguém rodando localmente em menos de cinco minutos
2. LICENSE
3. CONTRIBUTING.md
4. .env.example commitado, segredos fora do repo
5. Testes unitários com limite de cobertura cobrado no CI
6. Lint + formatação cobrados no CI
7. Dockerfile multi-stage e um docker-compose up de um comando só
8. CHANGELOG.md e releases com tag
9. Scan de dependências e vulnerabilidades
10. Proteção de branch com checks obrigatórios

• Índice
• Introdução
• Meu objetivo
• O problema que o Flink resolve
• Casos de uso reais
• A arquitetura, em poucas peças
• Fontes e destinos
• Paralelismo
• Redistribuição e data skew
• Operator chaining
• Rich functions
• Tempo: a parte que quebra a intuição
• Watermarks
• Janelas
• ProcessFunction
• Estado
• Checkpoints e savepoints
• Flink SQL
• In praxi (“na prática”)
• Deploy
  • Modos de execução
  • Kubernetes
  • Memória
  • CPU e slots
  • Disco local
  • S3 e o sistema de arquivos remoto
• O ecossistema em volta
• Complexidades
• O que ficou

Introdução

Este texto é o resultado do que estudei e experimentei ao longo desta semana. Não é um tutorial de quem domina Apache Flink, nem pretende ser uma referência sobre o assunto. É mais como um caderno de anotações de alguém que está aprendendo, testando algumas coisas na prática e compartilhando o que conseguiu entender e descobrir até aqui.

Sempre achei que explicar é a melhor forma de descobrir o que a gente realmente entendeu. Quando escrevo, os buracos aparecem sozinhos..

O Apache Flink é interessante principalmente porque tratou streaming como o caso geral, e não como um remendo sobre processamento em lote. Enquanto concorrentes da época simulavam fluxo contínuo com micro-batches, o Flink processa registro a registro, com latência baixa e throughput alto, mantendo estado distribuído consistente através de snapshots assíncronos (uma variação do algoritmo de Chandy-Lamport) que garantem semântica exactly-once mesmo após falhas. Ele também oferece noção de tempo de evento com watermarks, o que permite lidar corretamente com dados que chegam fora de ordem ou atrasados, algo essencial no mundo real. Sua origem é acadêmica: nasceu em 2010 como Stratosphere, projeto de pesquisa da TU Berlin em parceria com a Universidade Humboldt e o Hasso Plattner Institute, sob liderança de Volker Markl. Em 2014 o código foi doado à Apache Software Foundation, rebatizado de Flink (“ágil”, em alemão, daí o esquilo do logo) e promovido a projeto de topo ainda em dezembro daquele ano. Os criadores fundaram a data Artisans para comercializá-lo, empresa comprada pelo Alibaba em 2019 e renomeada Ververica. O próprio Alibaba já mantinha um fork interno (Blink) para lidar com o volume do Singles’ Day, e boa parte dessas melhorias voltou para o projeto principal, ajudando a consolidar o Flink como padrão de fato em processamento de streams em empresas como Netflix, Uber e Stripe.

Meu objetivo

Meu objetivo é usar o Apache Flink conectado ao Kafka para processar dados OTLP do OpenTelemetry (traces, métricas e logs) e extrair mais inteligência dessa telemetria em tempo real, em vez de apenas armazená-la e consultá-la depois. A ideia é usar esse pipeline como laboratório para testar casos como detecção de anomalias em séries temporais de métricas e latências, geração de alertas com contexto e supressão de ruído, análise de causa raiz (RCA) correlacionando spans, logs e métricas de serviços afetados, predição de degradação e saturação de recursos antes que o incidente aconteça, e detecção de dados sensíveis trafegando indevidamente em atributos de span e mensagens de log. Além disso, quero explorar outros cenários em que o Flink se encaixa bem: enriquecimento e sampling inteligente de traces, decidindo com estado quais traces reter com base no que aconteceu na requisição inteira (tail-based sampling) em vez de descartar aleatoriamente na borda; cálculo contínuo de SLIs e error budgets por serviço, com janelas deslizantes e agregações por endpoint, time e versão de deploy; e detecção de mudança de comportamento após releases, comparando o perfil de tráfego, erros e latência entre versões para identificar regressões introduzidas por um deploy específico. Pretendo detalhar tudo isso em breve (:

O problema que o Flink resolve

Durante muito tempo o mundo de dados foi organizado em torno do lote(batch). Você acumula dados durante o dia, roda um job à meia-noite, e de manhã o relatório está pronto. Isso funciona, e continua funcionando para muita coisa. O problema é quando a resposta precisa vir antes. Detectar uma fraude de cartão dez horas depois da compra é o mesmo que não detectar. Um alerta de infraestrutura que chega no dia seguinte é um post-mortem, não um alerta. Nesses casos, você não quer perguntar aos dados de tempos em tempos, você quer que os dados respondam continuamente. Essa é a inversão que o processamento de streams propõe:

• Batch: a consulta é permanente, os dados são finitos. Você roda a query contra um conjunto parado.
• Streaming: os dados são infinitos, a consulta é que fica parada. Ela é registrada uma vez e reage a cada evento que passa.

O Apache Flink é um motor de processamento distribuído voltado para a construção desse segundo tipo de aplicação. Sua premissa fundadora: tudo é um stream. Um arquivo CSV de ontem é um stream que tem começo e fim (bounded). O tópico Kafka com cliques do seu site é um stream que nunca acaba (unbounded). Um dos pontos que mais me chamou atenção durante o estudo foi o modelo unificado de processamento: no Flink, batch pode ser entendido como um caso particular de streaming, em que o fluxo de dados possui um início e um fim definidos. Isso significa que o modelo de execução não depende de dois motores completamente distintos, mas de uma mesma arquitetura capaz de processar tanto fluxos contínuos quanto conjuntos de dados finitos.

Casos de uso reais

Vale olhar onde isso aparece na prática, porque a lista ajuda a entender que tipo de problema o Flink resolve bem:

• Detecção de fraude, em bancos e fintechs. Cada transação é avaliada em milissegundos contra o histórico do cliente, mantido como estado por chave (keyBy no id do cliente). Regras como “3 compras em cidades diferentes em 10 minutos” são expressas com janelas, timers e a biblioteca de detecção de padrões complexos (CEP).
• Pipelines de CDC para data lake. O Flink CDC acompanha o log de transações do banco (o binlog no MySQL, o WAL via replicação lógica no Postgres) e replica cada insert, update e delete em tempo real para formatos de tabela como Apache Iceberg, Paimon ou Hudi. A Stripe é um dos casos públicos de captura de mudanças em escala com Flink.
• Analytics e dashboards em tempo real. Agregações por janela (pedidos por minuto, receita por região) alimentando painéis ao vivo. Uber, Netflix e Alibaba operam milhares de jobs Flink com esse perfil.
• Aplicações orientadas a eventos. Aqui a lógica de negócio vive dentro do stream, e não em um serviço que consulta um banco: matching de corridas, precificação dinâmica, motores de alerta, atualização de feature stores para modelos de machine learning.
• IA sobre streams. Inferência de modelos aplicada a eventos conforme eles passam, e o Flink Agents, subprojeto novo voltado a agentes de IA que reagem a eventos em tempo real.

A arquitetura, em poucas peças

Um job é representado como um grafo de operadores, composto por fontes (source), transformações (map, filter, keyBy, window) e destinos (sink). A partir desse grafo, o Flink determina o paralelismo de cada operador e distribui suas instâncias entre os slots disponíveis no cluster.

O keyBy merece atenção especial porque é responsável pelo particionamento dos dados. Quando você define keyBy(event -> event.getUserId()), está determinando que eventos com a mesma chave sejam direcionados para a mesma instância paralela do operador seguinte. Esse particionamento é fundamental para o processamento com estado por chave, pois permite que cada instância mantenha e gerencie o estado associado às chaves sob sua responsabilidade, sem a necessidade de coordenação distribuída a cada evento.

Fontes e destinos

Fonte e destino são os dois pontos em que o job encosta no mundo. Na linha 2.x eles passam por uma API só, env.fromSource(...) de um lado e stream.sinkTo(...) do outro.

As três fontes que aparecem em quase todo projeto:

E os três destinos:

O formato do código é sempre o mesmo, um builder de um lado e outro do outro:

KafkaSource<String> source = KafkaSource.<String>builder()
    .setBootstrapServers("kafka:9092")
    .setTopics("otlp-spans")
    .setGroupId("flink-otlp")
    .setStartingOffsets(OffsetsInitializer.earliest())
    .setValueOnlyDeserializer(new SimpleStringSchema())
    .build();

KafkaSink<String> sink = KafkaSink.<String>builder()
    .setBootstrapServers("kafka:9092")
    .setRecordSerializer(KafkaRecordSerializationSchema.builder()
        .setTopic("otlp-alerts")
        .setValueSerializationSchema(new SimpleStringSchema())
        .build())
    .setDeliveryGuarantee(DeliveryGuarantee.EXACTLY_ONCE)
    .setTransactionalIdPrefix("otlp-")
    .build();

env.fromSource(source, watermarkStrategy, "otlp-spans")
   .process(new AnomalyDetector())
   .sinkTo(sink);

Duas coisas nesse código não são detalhe de sintaxe. A primeira é que a fonte não faz commit de offset por conta própria: o offset é estado do Flink, entra no checkpoint junto com o resto e volta com ele numa recuperação. É por isso que não se gerencia offset na mão aqui, e é por isso também que o painel de consumer lag do Kafka pode discordar da realidade do job, já que o commit para o Kafka é só informativo.

A segunda é que o exactly-once no destino é uma propriedade do destino, não do Flink. O KafkaSink só alcança isso porque escreve dentro de uma transação que é confirmada quando o checkpoint fecha, e por isso ele exige um transactionalIdPrefix estável entre reinícios. O FileSink funciona pela mesma lógica: os arquivos ficam com sufixo de “em progresso” até o checkpoint confirmar, o que costuma assustar quem olha o bucket no meio do caminho e acha que nada está sendo escrito. Já o JdbcSink não tem transação distribuída, então a garantia que ele oferece depende de você escrever com chave primária e deixar a repetição ser inofensiva.

Vale insistir na parte do versionamento, porque ela morde. Com exceção dos conectores de sistema de arquivos e do datagen, que vêm dentro da distribuição, cada conector é um projeto separado, com repositório próprio, release próprio e numeração que não tem relação nenhuma com a do Flink. O flink-connector-kafka está na 5.0.0 enquanto o Flink está na 2.3. Os dois números não conversam, e não existe “a versão do conector que combina com a minha” por dedução.

O que existe é uma matriz de compatibilidade, publicada na página de downloads, e conferir essa matriz é passo obrigatório antes de escolher a versão do Flink de um projeto novo. O motivo é que a migração para a linha 2.x não foi simultânea, e boa parte do ecossistema ficou para trás. Alguns exemplos de como isso estava quando escrevi:

O conector do Prometheus é o caso mais eloquente, e é um que me interessa de perto, porque ele é a saída natural para métricas derivadas de telemetria. Ele existe, é oficial, e escreve via a API de remote write do Prometheus. É só sink, não há fonte correspondente, o que faz sentido: o Prometheus é onde a série temporal termina, não de onde ela vem. Só que a 1.0.0 ainda é da linha 1.x do Flink e não atravessou para a 2.x. Quem quiser esse destino hoje escolhe entre ficar na 1.20, que é LTS, ou escrever a integração na mão.

E repare que nem o Kafka lista a 2.3 na tabela acima. A defasagem de um release entre o núcleo e os conectores é o estado normal das coisas, não uma exceção. Se o seu pipeline depende de um conector específico, é ele que decide qual versão do Flink você pode rodar, e não o contrário.

Paralelismo

Paralelismo é o número de instâncias de cada operador rodando ao mesmo tempo. Um job com paralelismo 8 tem oito cópias do source, oito do map e oito do sink, cada uma processando uma fatia dos dados e ocupando um slot. Cada uma dessas cópias é uma subtask, e é por isso que a interface web mostra métricas repetidas com índices de 0 a 7.

Ele pode ser definido em três alturas, da mais ampla para a mais específica. No job inteiro, com env.setParallelism(8) no código ou parallelism.default no config.yaml. No deploy, pelo campo parallelism do FlinkDeployment, que é o que aparece no manifesto mais adiante. E operador a operador, encadeando .setParallelism(2) na chamada, o que sobrescreve os anteriores. O caso típico do override é um sink que conversa com um banco que não aguenta oitenta conexões simultâneas: o resto do job continua largo e só a escrita é estrangulada de propósito.

Para o valor inicial, um ponto de partida razoável é igualar o paralelismo ao número de partições do tópico Kafka de entrada. A razão de não passar disso é específica e vale entender, porque o sintoma é confuso: as subtasks de fonte que sobram não recebem partição nenhuma, ficam ociosas e nunca emitem watermark. Como o watermark de um operador é o menor entre todas as suas entradas, uma fonte parada segura o relógio do job inteiro, e o resultado é uma janela que nunca fecha e um job que parece travado sem nenhum erro no log. Dá para contornar declarando withIdleness() na estratégia de watermark, que manda o Flink ignorar as entradas silenciosas, MAS É MAIS SIMPLES NÃO CRIAR O PROBLEMA. Ficar abaixo do número de partições também tem custo, menor: você deixa vazão do tópico na mesa, porque uma subtask passa a ler mais de uma partição.

Depois disso, o ajuste é por medição, não por conta. Os dois números que interessam na interface web são o backpressure, que mostra qual operador está segurando o fluxo, e o busy time, que mostra a fração do tempo em que cada subtask esteve realmente trabalhando em vez de esperando. Aumentar o paralelismo de um operador que passa o dia ocioso não melhora nada. Falo mais sobre esse dimensionamento na seção de CPU e slots.

Falta uma peça para o rescale fazer sentido, e ela é interna: o Flink não distribui chave por chave. Ele passa cada chave por um hash e a coloca em um key group, e o que é distribuído entre as subtasks são os key groups, em faixas contíguas. O key group é a unidade de movimentação de estado, ou seja, quando você muda o paralelismo, o que migra de uma máquina para outra são grupos inteiros, nunca chaves avulsas. Não se mexe nisso diretamente quase nunca, mas o termo aparece em log e em qualquer conversa sobre rescaling.

O número de key groups que existem é exatamente o maxParallelism. Daí vêm as duas propriedades que importam. Ele é o teto absoluto do paralelismo, porque não dá para ter mais subtasks do que grupos para distribuir entre elas. E ele não pode mudar depois, porque alterar a quantidade de grupos muda a que grupo cada chave pertence, o que invalida todo o estado já salvo.

A armadilha está no valor padrão. Sem configuração, o Flink calcula esse número a partir do paralelismo inicial: algo em torno de uma vez e meia ele, arredondado para cima, com piso de 128 e teto de 32768. Um job que sobe com paralelismo 8 fica com 128 e ninguém repara, porque nada quebra. O problema chega no dia em que esse job precisa de paralelismo 200, e a única saída é reconstruir o estado do zero.

Definir na mão desde a primeira execução resolve, e env.setMaxParallelism(1024) é um valor confortável. O que não vale é colocar 32768 por precaução: alguns state backends mantêm estruturas internas que crescem com o número de key groups, então exagerar cobra em desempenho. Um cuidado extra que sai de graça é escolher um valor divisível pelo paralelismo pretendido, porque assim os grupos se distribuem por igual. Com 128 grupos e paralelismo 12, algumas subtasks ficam com 11 e outras com 10, uma assimetria pequena mas evitável.

Redistribuição e data skew

Entre dois operadores existe sempre uma decisão sobre para qual subtask seguinte cada evento vai. Na maior parte do tempo ela é tomada pelo Flink sem que você peça, mas dá para escolher, e as opções são poucas:

O broadcast merece nota porque é a base de um padrão inteiro: um stream pequeno de regras é transmitido para todas as subtasks, que o guardam em estado, enquanto o stream grande de eventos passa particionado por chave. É assim que se troca a lógica de um job sem redeploy.

Vale lembrar também que rebalance e rescale ganharam distribuição adaptativa na 2.3, olhando a carga real do destino em vez de fazer round-robin cego, e é uma opção que precisa ser ligada, como descrevo no post sobre o Flink 2.3.

Nada disso resolve o problema que mais dói, que é o data skew. Skew é quando a distribuição das chaves é desigual: um cliente que sozinho responde por metade das transações, um produto que viralizou, um tenant gigante no meio de mil pequenos. Como o keyBy garante que a mesma chave vai sempre para a mesma subtask, essa subtask vira o gargalo, as outras ficam ociosas, e o job inteiro anda na velocidade da mais lenta. Aumentar o paralelismo não ajuda em nada, porque a chave pesada continua indo para um lugar só.

O diagnóstico é direto na interface web, e é por isso que o busy time importa tanto: skew aparece como backpressure concentrado em uma subtask e como uma instância em 100% de ocupação enquanto as vizinhas estão em 10%. Se todas estivessem em 90%, o problema seria de capacidade, e a resposta seria outra.

As saídas são três, em ordem de esforço. A primeira, e a mais usada, é agregar em duas fases: você acrescenta um sufixo aleatório à chave, algo como cliente-42#0 até cliente-42#9, agrega parcialmente sobre essa chave inflada, e só então agrega de novo sobre a chave real. O trabalho pesado passa a ser dividido por dez subtasks, e a segunda etapa recebe apenas dez resultados parciais por chave em vez de milhões de eventos. A segunda, quando se está no SQL, é deixar o motor fazer isso: ligar o mini-batch e a otimização de agregação em duas fases resolve o caso comum sem reescrever consulta nenhuma, e existe até uma opção específica para dividir agregações com DISTINCT, que é a versão automática do mesmo truque. A terceira é aceitar que a chave-baleia é um caso à parte e tratá-la fora do fluxo normal, com um pipeline dedicado(clássica).

Operator chaining

O grafo que você escreve não é exatamente o grafo que roda. Antes de executar, o Flink funde operadores adjacentes em uma única task, e isso se chama operator chaining. Uma sequência como map, filter e flatMap vira uma coisa só, executada na mesma thread.

A fusão só acontece sob três condições: a ligação entre os operadores precisa ser forward, eles precisam ter o mesmo paralelismo e precisam estar no mesmo grupo de compartilhamento de slot. Um keyBy ou um rebalance quebram a corrente, porque nesses casos o registro precisa mesmo sair de uma instância e ir para outra.

O ganho é maior do que parece à primeira vista. Dentro de uma corrente, passar um registro de um operador para o próximo é uma chamada de método, e o objeto continua sendo o mesmo na memória. Entre duas tasks, o registro é serializado, vai para um buffer de rede e é desserializado do outro lado, e isso acontece mesmo quando as duas estão dentro do mesmo TaskManager. O chaining elimina esse custo inteiro.

É também a explicação para uma confusão comum na interface web: as caixas do grafo não correspondem aos seus operadores, elas correspondem às correntes. Você escreve seis operadores e vê duas caixas, cada uma listando dentro de si os nomes que absorveu.

A armadilha aparece na hora de investigar um problema. Métricas e backpressure são medidos por task, não por operador, então uma corrente inteira reporta um número só, e não dá para saber qual dos operadores fundidos está segurando o fluxo. Para descobrir, dá para quebrar a corrente de propósito: .disableChaining() isola um operador dos dois lados, e .startNewChain() começa uma corrente nova a partir dele. Isso é ferramenta de diagnóstico, não configuração para deixar ligada. O custo de serialização que você reintroduziu é real, então vale reverter depois de medir.

Rich functions

Toda interface de função tem uma versão “rich”: MapFunction tem RichMapFunction, FilterFunction tem RichFilterFunction, e assim por diante. A diferença é que a versão rich acrescenta ciclo de vida e contexto, e é isso que separa uma função que apenas transforma um registro de uma função que precisa de recursos externos ou de memória.

O open() é chamado uma vez por instância paralela, antes do primeiro evento chegar. É o lugar de abrir conexão com um banco, carregar um cache de enriquecimento, compilar uma expressão regular e, principalmente, registrar os descritores de estado. Vale reparar no “por instância paralela”: com paralelismo 8 ele roda oito vezes, uma em cada subtask, e o que ele cria não é compartilhado entre elas. O close() é o par dele, chamado no encerramento, e serve para devolver o que foi aberto.

O getRuntimeContext() é a porta de entrada para o que o runtime sabe. É por ele que se chega ao estado por chave, às métricas customizadas que você queira expor, ao índice da subtask atual e ao paralelismo do operador.

Se isso soar familiar quando você chegar na seção de estado, é porque o exemplo de lá já usa os dois: o AnomalyDetector sobrescreve open() e chama getRuntimeContext().getState(...) para criar o ValueState. Ele não tem “Rich” no nome, mas KeyedProcessFunction estende AbstractRichFunction e herda o mesmo ciclo de vida. As process functions já vêm ricas de fábrica.

Uma nota de versão que economiza tempo: até a 1.x a assinatura era open(Configuration parameters). Na 2.x ela foi removida, e o método passou a receber um OpenContext. Exemplo copiado de tutorial antigo não compila por causa disso.

Tempo: a parte que quebra a intuição

Essa foi a seção que mais me fez parar e reler. Em streaming existem, no mínimo, dois tempos diferentes:

• Event time: quando o evento aconteceu de verdade. Está gravado dentro do próprio evento.
• Processing time: quando o Flink viu o evento. É o relógio da máquina.

Parece detalhe, mas não é. O celular de alguém ficou sem sinal no metrô e sincronizou vinte minutos depois. Um broker teve um pico de latência. Uma partição do Kafka ficou atrasada em relação às outras. Em todos esses casos, os eventos chegam fora de ordem e atrasados.

Se você agrupar por processing time, o resultado depende de quando o job rodou. Reprocessar o mesmo dia amanhã dá um número diferente. Se você agrupar por event time, o resultado é o mesmo sempre, independente de quando o processamento aconteceu. Essa reprodutibilidade é o motivo de event time ser o padrão em quase todo pipeline sério.

Mas isso cria um problema novo: se os eventos chegam fora de ordem, como saber quando uma janela de tempo pode ser fechada? Nunca chega um evento dizendo “acabou, pode contar”.

Watermarks

A resposta do Flink são as watermarks. Uma watermark é um marcador que viaja junto com o stream carregando uma afirmação:

“Acredito que não vou mais receber eventos com timestamp anterior a T.”

É uma aposta, não uma certeza. E é exatamente por ser uma aposta que ela é útil: ela transforma uma pergunta impossível (“já chegou tudo?”) em uma decisão configurável (“quanto atraso eu tolero?”).

WatermarkStrategy
    .<Event>forBoundedOutOfOrderness(Duration.ofSeconds(10))
    .withTimestampAssigner((event, ts) -> event.getTimestamp());

Esse código diz: tolere até 10 segundos de desordem. Se o maior timestamp já visto é 12:00:30, a watermark vale 12:00:20, e qualquer janela que termine antes disso pode ser fechada e emitida.

O trade-off aparece na hora:

• Watermark agressiva (pouco atraso tolerado) → resultado rápido, mais eventos perdidos por chegarem tarde.
• Watermark conservadora (muito atraso tolerado) → resultado correto, mas você espera mais para ver qualquer coisa.

Não existe valor certo. Existe o valor que combina com o seu negócio, e essa é uma decisão de produto disfarçada de configuração técnica.

Para eventos que chegam após o avanço da watermark, o Flink oferece mecanismos específicos para tratar dados atrasados. O allowedLateness permite manter a janela aberta por um período adicional, possibilitando o processamento de eventos tardios e a atualização dos resultados já produzidos. Outra alternativa é utilizar side output, direcionando os eventos que ultrapassaram o limite de atraso para um stream separado. Esse mecanismo pode ser útil para auditoria, métricas de qualidade dos dados ou para identificar problemas na configuração da estratégia de watermark.

Janelas

Como o stream é infinito, agregações só fazem sentido dentro de recortes.

• Tumbling: janelas fixas que não se sobrepõem. “A cada 5 minutos, quantos pedidos?”
• Sliding: janelas fixas que se sobrepõem. “Nos últimos 10 minutos, atualizando a cada 1 minuto.” Um mesmo evento cai em várias janelas.
• Session: janelas definidas por inatividade. “Agrupe a atividade de um usuário até ele ficar 30 minutos parado.” O tamanho da janela é dado pelos dados, não por você.

stream
    .keyBy(Event::getUserId)
    .window(TumblingEventTimeWindows.of(Time.minutes(5)))
    .aggregate(new EventCounter());

Um detalhe que eu não tinha entendido de cara: prefira reduce/aggregate a process quando puder. O process recebe todos os eventos da janela de uma vez, o que significa guardar todos eles em estado até o fechamento. Já aggregate mantém apenas o acumulador. Em janelas grandes, essa diferença é a diferença entre um job estável e um job que morre de OOM.

ProcessFunction

Os operadores prontos cobrem muita coisa, mas eles impõem uma forma. map transforma um evento em outro, window agrupa por recorte de tempo, aggregate acumula. Quando a lógica não cabe em nenhum desses moldes, o caminho é descer um nível e escrever uma ProcessFunction, que é o operador de mais baixo nível e mais poderoso da DataStream API. É a faca suíça do Flink, e não é exagero dizer que quase toda lógica de negócio realmente complicada acaba dentro de uma.

O que ela dá, a cada evento, são três coisas que os operadores prontos não dão juntas: acesso direto ao estado da chave, a capacidade de registrar timers e a de emitir para side outputs. As três chegam pelo mesmo lugar, aquele parâmetro ctx que aparece na assinatura do processElement.

O timer é a parte que muda o que dá para construir, porque é ele que permite reagir à passagem do tempo, e não só à chegada de um evento. Você registra um instante futuro e o Flink chama o seu onTimer quando ele chega:

@Override
public void processElement(Event event, Context ctx, Collector<Alert> out) {
    ctx.timerService().registerEventTimeTimer(event.getTimestamp() + 600_000);
}

@Override
public void onTimer(long timestamp, OnTimerContext ctx, Collector<Alert> out) {
    // dez minutos de event time se passaram desde aquele evento
}

Duas propriedades desse mecanismo importam. A primeira é que um timer de event time não dispara quando o relógio da máquina chega lá, e sim quando a watermark passa daquele instante, o que amarra os timers na mesma noção de tempo das janelas: se a watermark não avança, o timer não dispara, e voltamos ao problema da fonte ociosa que descrevi antes. A segunda é que timers são estado, pertencem a uma chave e entram no checkpoint. Um job que reinicia não perde os timers pendentes, e é isso que torna viável escrever “se não acontecer nada nos próximos trinta minutos, alerte” e confiar na frase.

O side output é a segunda porta. Já apareceu aqui como destino de eventos atrasados, mas serve para qualquer bifurcação: registros que não passaram na validação, eventos que dispararam uma regra, amostras para auditoria. Você declara um OutputTag, chama ctx.output(tag, valor) e recupera esse fluxo depois com getSideOutput(tag). A vantagem sobre um filter duplicado é que o evento é examinado uma vez só, e a vantagem sobre lançar uma exceção é que o job não morre por causa de um registro malformado.

Existem algumas variantes, e escolher a errada é um erro comum. A KeyedProcessFunction é a que vem depois de um keyBy e a única com estado por chave e timers. A ProcessFunction pura funciona sobre um stream não particionado e não tem nem uma coisa nem outra. A CoProcessFunction recebe dois streams e é o caminho para juntar um fluxo de eventos com um fluxo de regras ou de dados de referência. E a ProcessWindowFunction é a que roda no fechamento de uma janela, com todos os eventos dela em mãos.

O preço de descer para esse nível é que o Flink para de cuidar das coisas por você. Uma janela sabe quando terminar e joga fora o que acumulou; um estado que você criou dentro de uma ProcessFunction fica lá para sempre, para cada chave que já apareceu, até você apagá-lo explicitamente ou configurar TTL. É a mesma liberdade e o mesmo risco de qualquer abstração de baixo nível, e é o motivo de a recomendação continuar sendo usar o operador pronto sempre que ele couber.

Estado

Comecei a estudar o Flink escrevendo, antes dele, meu próprio consumer Kafka. A ideia era responder uma pergunta só: o que um framework de processamento distribuído resolve além de ler eventos de um tópico ?

A resposta apareceu rápido, e ela é uma lista. Gerenciamento de estado, paralelismo, particionamento, tolerância a falhas, recuperação depois de uma queda, event time, watermarks, coordenação entre as etapas do processamento. No consumer manual, cada item desses vira código seu. No Flink, quase todos fazem parte do runtime, e o que sobra para a aplicação é a lógica de processamento.

Qualquer processamento mais interessante em streaming precisa manter algum tipo de memória, seja para contar eventos, realizar deduplicação, detectar padrões, correlacionar dados ou comparar valores anteriores. Em um consumer tradicional, essa responsabilidade acaba ficando muito mais próxima da aplicação. No Flink, o estado é gerenciado pelo runtime e pode ser distribuído, particionado por chave, armazenado de forma persistente e recuperado após uma falha por meio dos mecanismos de checkpoint e recuperação. Isso muda bastante a forma de construir uma aplicação de streaming, principalmente quando começamos a pensar em escala, falhas e processamento contínuo.

O Flink oferece estado como uma primitiva de primeira classe, com tipos como ValueState, ListState e MapState, sempre associados a uma chave depois do keyBy.

Que caralhos é uma Primitiva de primeira classe ??

Vem da teoria de linguagens de programação. Algo é de primeira classe quando o sistema o trata como um cidadão pleno, com todos os direitos, em vez de um apêndice que você tem que gerenciar por fora.. significa que você não precisa de um banco. Aqui está a parte que realmente importa. A alternativa óbvia seria guardar esse acúmulo num Redis ou Postgres externo. O Flink faz diferente: o estado vive dentro do próprio operador, no processo do TaskManager, gerenciado pelo framework. Isso traz três consequências.

Primeira, é local. Ler estado é acesso a memória ou a um RocksDB no disco local da máquina, não uma chamada de rede. Isso é a diferença entre microssegundos e milissegundos por evento, e a razão pela qual o Flink consegue processar milhões de eventos por segundo com lógica que depende de histórico.

Segunda, entra nos checkpoints. Periodicamente o Flink tira um snapshot consistente de todo o estado de todos os operadores e grava num storage durável (S3, HDFS). Se um TaskManager morrer, o job reinicia do último checkpoint com o estado exatamente como estava, e os offsets do Kafka voltam junto. Isso é o que sustenta a semântica exactly-once que mencionamos antes. Com Redis externo, você teria que resolver essa consistência entre “o que já consumi do Kafka” e “o que já escrevi no Redis” na mão, e é notoriamente difícil.

Terceira, é redimensionável. Ao aumentar o paralelismo do job, o Flink redistribui o estado entre as novas instâncias automaticamente, a partir de um savepoint.

public class AnomalyDetector extends KeyedProcessFunction<String, Event, Alert> {

    private transient ValueState<Double> lastValue;

    @Override
    public void open(OpenContext openContext) {
        lastValue = getRuntimeContext().getState(
            new ValueStateDescriptor<>("last-value", Double.class));
    }

    @Override
    public void processElement(Event event, Context ctx, Collector<Alert> out)
            throws Exception {
        Double previous = lastValue.value();
        if (previous != null && event.getValue() > previous * 3) {
            out.collect(new Alert(event, previous));
        }
        lastValue.update(event.getValue());
    }
}

Esse estado é particionado por chave: cada usuário tem o seu próprio lastValue, e o operador só enxerga a chave do evento atual. Também dá para configurar TTL, o que evita o problema clássico de estado que só cresce até estourar o disco.

Onde esse estado fica guardado é uma escolha, e são três opções na linha 2.x:

O padrão, se você não configurar nada, é o HashMapStateBackend. Isso costuma surpreender quem leu que “o Flink usa RocksDB”, e a troca é uma linha em state.backend.type, que aceita hashmap, rocksdb ou forst.

A regra prática que eu tirei disso tem três casos. Estado de poucos gigabytes com latência crítica pede HashMap, porque a ausência de serialização é justamente o que você está comprando. Estado grande, de dezenas de gigabytes a terabytes, pede RocksDB com checkpoint incremental, e vale notar que ele é o único dos dois clássicos que oferece isso: com HashMap, todo checkpoint copia o estado inteiro. E estado enorme em nuvem, com autoscaling agressivo, é o caso para avaliar o ForSt, que é a aposta da série 2.x e sobre o qual escrevo mais no final.

Checkpoints e savepoints

O estado só é confiável porque existe um mecanismo de tolerância a falhas por trás dele.

Periodicamente, o JobManager injeta barreiras de checkpoint nas fontes. Essas barreiras fluem pelo grafo junto com os dados; quando um operador recebe a barreira, ele persiste seu estado em armazenamento durável (S3, HDFS, o que for) e repassa a barreira adiante. Quando todos os operadores terminam, o checkpoint está completo.

O algoritmo é uma variação do Chandy-Lamport para snapshots distribuídos. Achei bonito descobrir que uma coisa tão prática está apoiada num paper de 1985.

Na falha, o Flink restaura o último checkpoint completo, reposiciona os offsets das fontes e retoma. Daí vem o famoso exactly-once, que eu entendi errado durante bastante tempo. Não significa que cada evento é processado uma única vez fisicamente. Na recuperação, eventos são sim reprocessados. Significa que o efeito sobre o estado é como se cada evento tivesse sido processado uma vez só. É uma garantia sobre o resultado, não sobre a execução.

Estender essa garantia até o sink é outro assunto, e depende de o destino suportar escrita transacional ou idempotente (Kafka com transações, por exemplo).

A diferença entre checkpoint e savepoint também levou um tempo para assentar:

Savepoint é o que permite parar um job, subir uma versão nova do código e continuar exatamente de onde parou, com o estado intacto. Na prática, é isso que torna um job de streaming algo que se pode operar por anos.

Flink SQL

Nem tudo precisa de Java. O Flink expõe uma Table API e SQL sobre o mesmo motor, e a mesma consulta roda tanto sobre dados finitos quanto sobre um stream infinito:

SELECT
    user_id,
    TUMBLE_START(event_time, INTERVAL '5' MINUTE) AS window_start,
    COUNT(*) AS total
FROM orders
GROUP BY
    user_id,
    TUMBLE(event_time, INTERVAL '5' MINUTE);

O conceito que sustenta isso é a dualidade stream/tabela: um stream é o log de mudanças de uma tabela, e uma tabela é o estado acumulado de um stream. São a mesma informação vista de dois ângulos.

Isso deixa de ser abstrato assim que você roda um GROUP BY no cliente SQL e olha a coluna op:

+----+------+-------+
| op | name | total |
+----+------+-------+
| +I |    a |     1 |
| +I |    b |     1 |
| -U |    a |     1 |
| +U |    a |     2 |
+----+------+-------+

O a entra com 1, é retratado (-U) e reemitido com 2 (+U). Não é uma tabela sendo preenchida aos poucos, é o log de mudanças dela passando na tela. O resultado de uma query em streaming não é um valor final, é uma sequência de correções sobre o valor anterior.

São quatro tipos de linha ao todo: +I para inserção, -U e +U para o antes e o depois de uma atualização, e -D para remoção. E é a combinação de tipos que uma consulta produz que define com que tipo de stream você está lidando, o que na prática decide onde ele pode ser gravado:

A diferença entre retract e upsert é sutil e importa na hora de escolher o destino. No modo retract, o Flink emite duas linhas para cada correção, e quem recebe precisa saber subtrair a antiga antes de somar a nova. No modo upsert, ele emite só a linha nova, e quem recebe sobrescreve o que tinha naquela chave. O segundo é mais barato e é o que bancos relacionais e índices de busca esperam, mas só é possível quando existe uma chave que identifique a linha.

Isso leva à armadilha clássica, que dá para prever antes de cair nela. Você escreve um GROUP BY contínuo e aponta o resultado para um tópico Kafka comum. O conector Kafka padrão é append-only, e o resultado da sua consulta é um fluxo de correções, não de inserções. O job não chega nem a subir: o planejador rejeita a consulta com uma mensagem do tipo “table sink doesn’t support consuming update changes which is produced by node GroupAggregate”. A falha na hora do planejamento é uma boa notícia, porque o modo silencioso de errar isso seria gravar as retrações como se fossem eventos normais e ter um consumidor lá na frente somando tudo duas vezes.

Existem três saídas, e a escolha diz mais sobre o problema do que sobre o Flink. A primeira é usar um sink que aceite atualizações, como upsert-kafka ou JDBC com chave primária declarada. A segunda é fazer o resultado parar de mudar, agrupando por janela em vez de agrupar de forma contínua: quando a janela fecha, o valor é final e vira uma inserção só. A terceira, disponível a partir da 2.3, é converter explicitamente entre as formas com FROM_CHANGELOG e TO_CHANGELOG, que é o que descrevo no post sobre o Flink 2.3.

Para quem vem de dados, essa é a porta de entrada mais rápida, dá para chegar longe sem escrever uma linha de Java.

In praxi (“na prática”)

Subir um cluster local é mais simples do que eu imaginava. Comecei com dois docker run soltos, mas troquei por um docker-compose.yml assim que quis mais de um TaskManager:

name: flink-lab

services:
  jobmanager:
    image: flink:2.3.0-java21
    container_name: jobmanager
    command: jobmanager
    ports:
      - "8081:8081"
    environment:
      - |
        FLINK_PROPERTIES=
        jobmanager.rpc.address: jobmanager
        rest.address: 0.0.0.0
        rest.bind-address: 0.0.0.0
        jobmanager.memory.process.size: 1024m
    healthcheck:
      test: ["CMD-SHELL", "curl -sf http://localhost:8081/overview || exit 1"]
      interval: 5s
      timeout: 3s
      retries: 20
      start_period: 10s

  taskmanager:
    image: flink:2.3.0-java21
    command: taskmanager
    depends_on:
      jobmanager:
        condition: service_healthy
    deploy:
      replicas: 2
    environment:
      - |
        FLINK_PROPERTIES=
        jobmanager.rpc.address: jobmanager
        taskmanager.numberOfTaskSlots: 2
        taskmanager.memory.process.size: 1728m

Um docker compose up -d e a Web UI responde em localhost:8081.

Três escolhas aí não são detalhe. Duas réplicas de TaskManager com dois slots cada dão quatro slots, e é isso que faz o paralelismo deixar de ser sempre 1: sem folga de slots, todo grafo de job aparece na UI como uma fila reta. O healthcheck combinado com depends_on: service_healthy existe porque, sem ele, o TaskManager sobe antes de o JobManager estar de pé, falha ao registrar e enche o log de erro antes de funcionar na segunda tentativa. E os limites de memória estão explícitos porque o padrão do Flink é generoso: com esses valores o cluster inteiro fica em torno de 4,5 GB e cabe em qualquer máquina.

Antes de submeter qualquer coisa, a API REST diz se o cluster está inteiro de forma mais direta que a UI:

curl -s localhost:8081/overview

{"taskmanagers": 2, "slots-total": 4, "slots-available": 4, "flink-version": "2.3.0"}

Os dois TaskManagers registrados e os quatro slots livres são a confirmação de que o cluster formou. A imagem ainda traz jobs de exemplo, então dá para ver um grafo em execução sem escrever uma linha:

docker exec jobmanager ./bin/flink run -d \
  /opt/flink/examples/streaming/TopSpeedWindowing.jar

Com ele rodando, slots-available cai para 3 e a UI finalmente tem o que mostrar.

A Web UI foi onde eu mais aprendi. Ela mostra o grafo do job, o paralelismo real de cada operador, o histórico de checkpoints (duração e tamanho) e, principalmente, o backpressure: quando um operador não consegue acompanhar o ritmo do anterior e a pressão se propaga para trás até a fonte. Ver isso acontecendo em tempo real ensina mais do que qualquer diagrama.

Para SQL, o caminho mais curto é o cliente interativo:

docker exec -it jobmanager ./bin/sql-client.sh

Deploy

O docker-compose.yml acima é um laboratório. Ele sobe um cluster, mas esconde quase todas as decisões que aparecem quando o job precisa rodar por meses sem alguém olhando. Essa foi a parte que mais me obrigou a ler manual, porque aqui não tem intuição que salve: é conta, é limite de container e é escolha de onde o estado vai parar.

Modos de execução

Antes de escolher onde rodar, é preciso escolher como. O Flink tem dois modos vivos hoje, e a diferença entre eles é o ciclo de vida do cluster.

No session mode, o cluster sobe primeiro e fica de pé esperando. Você submete vários jobs para o mesmo JobManager, e todos disputam os mesmos TaskManagers. É o que o meu compose faz, e é o modo certo para exploração, para o cliente SQL e para jobs curtos que não compensam o custo de subir um cluster novo. O preço é a ausência de isolamento: um job que estoura a memória derruba o TaskManager, e junto com ele vão as tarefas de todos os outros jobs que tinham slots naquele processo.

No application mode, cada aplicação ganha o seu próprio cluster dedicado, que nasce com ela e morre com ela. A diferença mais importante é sutil e está no main(): em vez de rodar na máquina de quem submete, ele roda dentro do JobManager. Isso tira do cliente a responsabilidade de baixar dependências e montar o grafo do job, e é o que torna o modo adequado para automação, porque não existe mais um processo cliente de fora que precisa continuar vivo. Para produção, é a resposta padrão.

Existiu ainda um terceiro modo, o per-job, que também dava um cluster por job mas mantinha o main() no cliente. Ele foi descontinuado e não faz mais parte da linha 2.x. Se você encontrar -t yarn-per-job em algum tutorial, é material de uma versão anterior.

Ortogonal a isso está o gerenciador de recursos: standalone (você mesmo sobe os processos, que é o caso do Docker Compose), Kubernetes ou YARN. A combinação que vejo recomendada com mais frequência hoje é application mode sobre Kubernetes.

Kubernetes

No Kubernetes existem três caminhos, e vale entender a diferença porque eles resolvem problemas distintos.

O primeiro é standalone no Kubernetes: você escreve dois Deployment, um para o JobManager e outro para o TaskManager, um Service e um ConfigMap com o flink-conf.yaml. O Flink não sabe que está no Kubernetes, ele só vê processos que se registram. Funciona, e é transparente, mas a escala é sua: mudar paralelismo é mudar réplicas na mão, e fazer upgrade com savepoint é uma sequência de comandos que alguém precisa lembrar de executar na ordem certa.

O segundo é o native Kubernetes, em que o próprio JobManager fala com a API do Kubernetes e cria os pods de TaskManager que faltam para atender o paralelismo pedido. Você submete com flink run-application -t kubernetes-application e não escreve manifesto de TaskManager nenhum. O cluster passa a se dimensionar de acordo com o job, e não o contrário.

O terceiro, e o que eu usaria, é o Flink Kubernetes Operator. Ele instala CRDs e transforma o job em um objeto declarativo do cluster:

apiVersion: flink.apache.org/v1beta1
kind: FlinkDeployment
metadata:
  name: otlp-processor
spec:
  image: registry.example.com/otlp-processor:1.4.0
  flinkVersion: v2_0
  serviceAccount: flink
  flinkConfiguration:
    taskmanager.numberOfTaskSlots: "4"
    state.backend.type: rocksdb
    state.checkpoints.dir: s3://flink-state/otlp-processor/checkpoints
    state.savepoints.dir: s3://flink-state/otlp-processor/savepoints
    execution.checkpointing.interval: "60s"
    high-availability.type: kubernetes
    high-availability.storageDir: s3://flink-state/otlp-processor/ha
  jobManager:
    resource:
      cpu: 1
      memory: 2048m
  taskManager:
    replicas: 3
    resource:
      cpu: 4
      memory: 8192m
  job:
    jarURI: local:///opt/flink/usrlib/otlp-processor.jar
    parallelism: 12
    upgradeMode: savepoint

O que esse manifesto compra é operação. O upgradeMode: savepoint significa que, quando eu trocar a tag da imagem e aplicar de novo, o operator dispara um savepoint, para o job, sobe a versão nova e restaura o estado a partir dele, sem que ninguém precise executar flink stop --savepointPath manualmente às três da manhã. Ele também cuida de rollback quando o job novo não estabiliza, e traz um autoscaler que observa o backpressure real dos operadores e ajusta o paralelismo, que é bem diferente de um HPA olhando uso de CPU do pod.

Dois detalhes que não são opcionais. O primeiro é a serviceAccount: o JobManager precisa de permissão de RBAC para criar pods e para ler e escrever ConfigMaps, porque é em ConfigMap que a alta disponibilidade nativa guarda quem é o líder e qual é o último checkpoint. O segundo é o high-availability.storageDir: o ConfigMap guarda só o ponteiro, os metadados de verdade vão para armazenamento durável. Sem esse diretório configurado, um JobManager que morre volta sem saber de onde retomar, e o estado inteiro se perde apesar dos checkpoints existirem.

Memória

Essa é a conta que mais dá trabalho, porque o Flink não tem um número de memória, tem uma árvore deles. O valor que você configura é o taskmanager.memory.process.size, e ele é o total que o processo pode ocupar no sistema operacional. Tudo o mais é subdivisão.

Dentro dele, o Flink separa primeiro o que pertence à JVM e não ao Flink: o metaspace (taskmanager.memory.jvm-metaspace.size, 256m por padrão) e um overhead para pilhas de thread, buffers internos e código nativo (taskmanager.memory.jvm-overhead.fraction, 10% do process size). O que sobra é a memória do Flink propriamente dita, e ela se divide em quatro partes:

• O heap de tarefa, onde vivem os seus objetos e o estado quando o backend é o de heap.
• A memória gerenciada, que é off-heap e é onde o RocksDB aloca seus block caches e write buffers. Em job batch, é também onde acontecem sort e hash join.
• A memória de rede, que são os buffers de troca de dados entre tarefas.
• Um pedaço reservado para o framework, que raramente se mexe.

A regra que importa acima de todas: o process.size tem que caber no limite de memória do container. Se você der 8Gi de limite no pod e configurar process.size: 8192m, o pod vai ser morto por OOMKill, porque o cgroup conta também páginas de arquivo, alocações nativas do RocksDB fora do que o Flink contabiliza e o que o próprio kernel usa. Deixar uma folga de 10 a 15% resolve. Para 8Gi de limite, eu configuraria em torno de 7000m e dormiria melhor.

A segunda decisão é como dividir. Se o estado é grande e o backend é RocksDB, a memória gerenciada é a que faz diferença, porque é ela que determina o tamanho do cache antes de o acesso virar leitura de disco. Uma divisão de partida razoável é 40% de memória gerenciada e o resto entre heap e rede. Se o estado é pequeno e cabe em heap, o caminho inverso: taskmanager.memory.managed.fraction: 0.1 e todo o resto para o heap.

A memória de rede é a que mais surpreende. Ela é 10% da memória do Flink por padrão, limitada a 1 GB, e o consumo cresce com o número de conexões entre tarefas, que por sua vez cresce com o quadrado do paralelismo em trocas do tipo keyBy. Um job com paralelismo 4 que passa para 200 pode começar a falhar com erro de buffers insuficientes sem que uma linha do código tenha mudado. É um dos poucos casos em que aumentar o paralelismo piora as coisas antes de melhorar.

CPU e slots

Slot não é CPU. Um slot é uma fatia de memória e um lugar no escalonamento, mas as threads de todos os slots de um TaskManager competem pelos mesmos cores da JVM. Não há isolamento de CPU entre slots.

Por isso a regra de partida é simples: taskmanager.numberOfTaskSlots igual ao número de cores que o container tem de limite. Quatro cores, quatro slots. Ir muito acima disso não aumenta a vazão, só aumenta a troca de contexto e o tempo de pausa que o coletor de lixo tem que administrar.

O paralelismo total do job então é o número de TaskManagers vezes os slots de cada um, e essa multiplicação é o número que aparece no manifesto. Três TaskManagers de quatro slots dão doze, que é o paralelismo do exemplo acima.

Para chegar ao número certo de TaskManagers, eu não tentaria calcular por primeiros princípios. O caminho que faz sentido é medir: subir o job com paralelismo baixo, injetar carga conhecida e olhar numRecordsInPerSecond por subtarefa na UI ou no Prometheus. Isso dá uma vazão por slot. Divide o pico esperado por esse número, adiciona uma folga de uns 30% para picos e para reprocessamento (porque depois de uma queda o job precisa correr mais rápido do que a produção para alcançar o presente) e o resultado é quantos slots são necessários. Um job de filtro e projeção pode fazer centenas de milhares de eventos por segundo em um slot; um job com janela grande, estado em RocksDB e deserialização de JSON pode fazer alguns milhares. A diferença entre esses dois casos é de ordens de grandeza, e é exatamente por isso que não dá para adivinhar.

Vale lembrar que mudar o paralelismo de um job com estado depois não é livre: o estado é redistribuído entre as novas subtarefas na restauração, e o teto continua sendo o maxParallelism fixado na primeira execução, pelo motivo que descrevi na seção de paralelismo.

Disco local

Com o RocksDB, o estado de trabalho não fica em memória, fica em arquivos no disco local do TaskManager, apontado por io.tmp.dirs. Isso é o que permite ter estado maior que a RAM, e é também o que faz o tipo de disco importar.

Precisa ser SSD local, não volume de rede. O RocksDB é uma LSM tree: escreve em arquivos ordenados e depois compacta esses arquivos em segundo plano, reescrevendo dados que já estavam lá. Essa amplificação de escrita, somada a leituras aleatórias a cada acesso de estado, é exatamente o padrão de I/O que um disco de rede atende mal. Já vi o mesmo job ir de estável a inutilizável só pela troca do tipo de volume.

Para o tamanho, a conta parte do estado lógico: número de chaves ativas vezes o tamanho do estado por chave, dividido pelo paralelismo, dá o estado por TaskManager. Depois disso, multiplique. Duas a três vezes é uma margem razoável, porque a compactação precisa de espaço para escrever os arquivos novos antes de apagar os antigos, e porque os checkpoints incrementais mantêm arquivos referenciados por snapshots anteriores que ainda não foram descartados. Dez milhões de chaves com 1 KB de estado cada dão 10 GB de estado lógico; em três TaskManagers, isso é algo entre 7 e 10 GB de disco em cada um.

No Kubernetes, isso significa escolher entre emptyDir e volume persistente. Com emptyDir, o disco morre com o pod, e um restart obriga o TaskManager a baixar o estado inteiro do armazenamento remoto antes de voltar a processar, o que em estados grandes é a diferença entre segundos e muitos minutos de recuperação. Com um volume persistente e state.backend.local-recovery: true, a cópia local sobrevive ao restart e a recuperação lê do disco em vez da rede. É mais complexidade em troca de tempo de recuperação, e a escolha depende de quanto o atraso custa.

S3 e o sistema de arquivos remoto

Aqui está a confusão que eu mesmo tinha antes de estudar: o S3 não é onde o estado vive, é onde as cópias dele são guardadas. O estado quente está no heap ou no disco local do TaskManager, e é lá que ele é lido e escrito a cada evento. O S3 entra em quatro momentos, e todos eles são periódicos ou excepcionais.

O primeiro são os checkpoints. A cada intervalo configurado, cada operador escreve seu estado em state.checkpoints.dir. É isso que sobrevive à perda simultânea de todos os pods.

O segundo são os savepoints, em state.savepoints.dir, que é o mesmo mecanismo com outro ciclo de vida: eles são seus, não são apagados pelo Flink, e é deles que sai o upgrade sem perder estado.

O terceiro são os metadados de alta disponibilidade, em high-availability.storageDir. O ConfigMap do Kubernetes é pequeno demais para guardar o grafo do job e os ponteiros completos, então ele guarda apenas a referência e o conteúdo fica no armazenamento remoto.

O quarto, quando existe, são os próprios dados: uma fonte que lê Parquet de um bucket, ou um sink que escreve resultados particionados por hora.

A razão de ser S3, e não um disco compartilhado, é que a durabilidade precisa ser independente do cluster. Um checkpoint que está no mesmo hardware que o job não protege contra a perda desse hardware. O armazenamento de objetos é barato, replicado e continua existindo depois de o cluster inteiro deixar de existir, que é precisamente a propriedade que faz um job de streaming ser recuperável. GCS, Azure Blob e HDFS ocupam o mesmo lugar na arquitetura, com outra letra no esquema da URI.

A configuração tem uma pegadinha que custa tempo. O Flink traz duas implementações de S3, e elas não são intercambiáveis. A flink-s3-fs-presto é a indicada para checkpoints, porque é rápida com arquivos pequenos e não depende de renomear objetos, operação que o S3 não tem de forma atômica e que emula com uma cópia seguida de uma remoção. A flink-s3-fs-hadoop é a que suporta escrita recuperável, que é o que o sink de arquivos precisa para fazer upload multipart e confirmar só no checkpoint. Muita gente instala as duas e usa s3p:// para o estado e s3a:// para os dados. As duas são plugins e precisam ir para /opt/flink/plugins/, cada uma em seu próprio diretório, e não para lib/. No lib/ elas carregam no classloader principal e conflitam entre si.

O último ponto é sobre o intervalo de checkpoint, que parece uma configuração de latência e é também uma conta de custo. Cada checkpoint escreve pelo menos um arquivo por subtarefa com estado. Um job com paralelismo 200 e checkpoint a cada 10 segundos produz na ordem de setenta mil objetos por hora, e o S3 cobra por requisição além de limitar a taxa por prefixo. Isso aparece como latência de checkpoint subindo e, no limite, como checkpoint expirando por timeout. Duas defesas ajudam: subir o state.storage.fs.memory-threshold para que estados pequenos viajem dentro do arquivo de metadados em vez de virarem objetos separados, e aceitar um intervalo maior. Um minuto entre checkpoints é um valor comum, e o que ele custa é apenas a quantidade de trabalho que precisa ser refeita depois de uma falha.

O ecossistema em volta

O Flink raramente aparece sozinho. Ele é um motor de processamento, e um motor precisa de algo que alimente, de algum lugar onde depositar e de gente que leia o que ele produziu. Boa parte do trabalho de montar um pipeline é escolher essas peças, então vale mapear as que mais aparecem ao lado dele e, principalmente, por que aparecem.

Três dessas escolhas têm um detalhe que só aparece depois, e vale adiantar.

O primeiro é o problema dos arquivos pequenos. O sink do Iceberg confirma o que escreveu quando o checkpoint fecha, então o intervalo de checkpoint deixa de ser só uma decisão de recuperação e passa a determinar quantos arquivos e quantos snapshots a tabela ganha por hora. Checkpoint a cada dez segundos em um job com paralelismo alto produz uma tabela com milhares de arquivos minúsculos por dia, que é o pior formato possível para quem for lê-la depois. A solução não é evitar o Iceberg, é aceitar que compactação e expiração de snapshot são trabalho recorrente, e é justamente esse trabalho que costuma justificar um Airflow ao lado de um pipeline que, no papel, não tinha nada de agendado.

O segundo é o catálogo, que quase sempre é lembrado tarde. É fácil pensar no formato de tabela e esquecer que alguém precisa saber que a tabela existe. Sem catálogo configurado, o CREATE TABLE do Flink SQL vive só na sessão e some quando o cliente fecha, e o Trino do outro lado não enxerga nada do que foi criado. Escolher o catálogo é o que faz Flink e os outros motores estarem falando da mesma tabela, em vez de dos mesmos arquivos por coincidência.

O terceiro é a razão de existir uma feature store, que demorei a entender. O problema que ela resolve não é de armazenamento, é de consistência: se a feature “média de compras nos últimos 30 minutos” é calculada por um job Flink na inferência e por uma query SQL no treino, as duas vão discordar em algum detalhe, e o modelo passa a ver em produção dados diferentes dos que viu ao aprender. Manter uma definição só, alimentada pelo mesmo job, é o ponto. E vale notar que parte disso está migrando para dentro do próprio Flink com as funções de modelo da 2.1 e 2.2, que descrevo no post sobre o Flink 2.3.

Complexidades

• Ajuste fino de RocksDB e o comportamento do estado quando ele cresce muito além da memória.
• Estratégias de join entre streams, principalmente interval joins e temporal joins.
• A biblioteca de CEP, citada lá em cima nos casos de uso e ainda não testada por mim.
• Como isso tudo se comporta de verdade em produção sob carga irregular, a parte que nenhuma documentação ensina.

O que ficou

Terminei a semana com uma impressão que não esperava ter: a parte difícil de streaming não é distribuir o processamento. Isso o Flink resolve. A parte difícil é o tempo: aceitar que os dados chegam desordenados, que “completo” é uma aposta e não um fato, e que quase toda decisão técnica aqui é, no fundo, uma escolha entre latência e correção.

Escrever isto me forçou a admitir umas três ou quatro coisas que eu achava que sabia e não sabia. Valeu pelo esforço.

Falta dizer por que fui atrás disso, porque não é Flink pelo Flink. O que eu quero é processar OTLP, o formato que o OpenTelemetry Collector fala, e na prática isso significa os quatro sinais: logs, spans, métricas e profiles.

O Collector recebe, transforma e encaminha muito bem, mas ele é feito para o dado passar. No momento em que a pergunta precisa de memória entre eventos, de janela por event time ou de correlacionar sinais que chegam separados e fora de ordem, ela cai exatamente no que este texto descreve: keyBy, estado por chave e watermark. É esse encaixe que eu quero testar na próxima rodada.

Próxima semana no cronograma: revisar o roadmap de Data Engineer. Continuo escrevendo enquanto aprendo.

O que é a República ? É uma das obras mais importantes e conhecidas de Platão, escrita provavelmente no século IV a.C., por volta de 375 a.C. A obra é construída principalmente na forma de diálogos, tendo Sócrates como personagem central.

Um dos grandes problemas que orientam a discussão é uma pergunta aparentemente simples, mas bastante incômoda: vale a pena ser justo ? O que é a justiça ? É melhor ser justo por si mesma ou apenas pelas vantagens e recompensas que ela pode trazer ? Em outras palavras: vale a pena agir corretamente quando a injustiça poderia trazer mais benefícios ?

A partir dessas questões, Platão desenvolve uma longa investigação sobre a justiça, a educação, a organização da cidade, a natureza da alma e o modo como devemos viver.

É nesse contexto que aparece o Mito de Er, encerrando a obra. O mito narra a experiência de Er, um homem que teria morrido em batalha e retornado à vida para contar o que viu após a morte. Seu relato aborda o destino das almas, as consequências de suas escolhas e a possibilidade de escolher uma nova vida.

Por estar no final da República, o Mito de Er funciona como uma conclusão simbólica da obra e retoma uma de suas questões fundamentais: quais são as consequências de nossas escolhas e que tipo de vida devemos escolher ? Ele não deve ser entendido simplesmente como “a resposta final” de Platão, mas como uma narrativa que encerra e amplia a investigação filosófica desenvolvida ao longo do diálogo.

Quem conta a história ? Sócrates, que foi o professor de Platão e é o personagem principal de quase todos os seus livros. É pela boca dele que o mito é narrado.

O cenário

Er é um guerreiro que morre em batalha. O corpo dele fica dias no campo sem apodrecer e, na hora de ser cremado, ele acorda e conta tudo o que viu do outro lado.

Basicamente: o primeiro relato de experiência de quase-morte da história da filosofia.

O que Er descreve é o processo pelo qual as almas retornam ao mundo sensível. Traduzindo o termo técnico: “mundo sensível” é simplesmente o mundo que a gente enxerga, toca, cheira, o mundo material, O DAQUI. Platão acreditava que a alma existe antes e depois do corpo, e que ela vai e volta. O que Er viu foi justamente o balcão de embarque dessa volta. E lá tem gente trabalhando. As Moiras, três figuras da mitologia grega que controlam o destino de cada pessoa, representadas como fiandeiras (mulheres que fiam, ou seja, produzem linha). A ideia é que a sua vida é um fio, e elas cuidam desse fio:

• Cloto: a que fia, ou seja, produz o fio da sua vida.
• Láquesis: a que mede e distribui, sorteia e organiza os destinos.
• Átropos: a que corta o fio. Ela é a morte. O nome dela significa literalmente “a inflexível”, a que não volta atrás.

Guarde esse detalhe, porque ele importa: as Moiras estão lá, o destino existe na história. Platão não está negando o destino. Ele vai fazer algo mais esperto do que isso.

As regras do jogo

Agora vem a parte boa. O renascimento das almas segue regras bem específicas.. e cada uma delas carrega um recado.

1. Acontece um sorteio

Quando as almas estão prontas pra renascer, elas participam de um sorteio. Só que o sorteio não define a vida que você vai ter. Ele define apenas a ordem em que cada alma vai escolher. É senha de fila, não prêmio. Você não sorteia o que vai levar; você sorteia quando vai poder pegar.

2. Sobra vida pra todo mundo

E aqui está o ponto central do mito: há mais opções de vida do que almas. O acaso participa do processo. O sorteio existe e determina a ordem em que cada alma escolherá, mas a escolha da vida que cada uma levará é, em última instância, sua. E, junto com a escolha, vem também a responsabilidade por ela. Essa ideia me atingiu de uma forma inesperada. Foi o tipo de passagem que me fez parar a leitura e ficar olhando para o teto por um bom tempo.

3. Os deuses não têm culpa

Platão bate nessa tecla com força total. A frase que aparece no mito é praticamente uma sentença: a culpa é de quem escolhe, e a divindade não tem culpa nenhuma. Ninguém empurrou nada goela abaixo de ninguém. Cada alma escolhe seu caminho conforme a sabedoria que tem ou conforme a falta dela. Isso, no contexto grego, era uma provocação e tanto. A cultura da época estava cheia de histórias em que os deuses arruinavam a vida das pessoas por capricho, ciúme ou vingança. Platão está cortando essa desculpa pela raiz.

O cardápio de vidas

E o que estava disponível pra escolher ? De tudo. Vidas ricas, vidas pobres, vidas de tirano, vidas de gente famosa, vidas de anônimo, vidas simples, vidas de bicho até. Um bufê completo de existências possíveis. Só que é aí que a coisa complica de verdade. Porque a vida que parece boa nem sempre é boa. A vida de tirano brilha de longe: poder, dinheiro, todo mundo te obedecendo. De perto, é uma máquina de produzir injustiça e, segundo Platão, quem produz injustiça acaba destruindo a si mesmo por dentro. No mito, tem uma cena ótima: uma alma se atira em cima da vida de tirano, agarra ela com tudo, e só depois percebe o que veio junto no pacote. Aí sai se lamentando e culpando os deuses. Mas ela mesma escolheu. Ela só não olhou direito. Então o desafio real nunca foi escolher a vida mais chamativa. O desafio era ter autoconhecimento suficiente pra escolher uma vida que levasse à virtude e não à injustiça.

Rapidinho sobre esses dois termos, porque eles são o coração do texto:

• Virtude, pra Platão, não é ser “bonzinho” nem seguir regras de etiqueta moral. É a alma funcionar bem, em ordem, com a razão no comando, como um instrumento afinado.
• Injustiça é o contrário: a alma bagunçada, desgovernada, com os impulsos mandando. Pra Platão, isso é uma espécie de doença da alma. E é por isso que ser injusto é ruim pra você, mesmo que ninguém descubra e mesmo que você lucre com isso.

E tem um detalhe cruel: o caráter

O caráter o jeito de ser, a estrutura moral da pessoa é muito difícil de mudar depois que a escolha é feita. Ou seja: você não escolhe só as circunstâncias da sua vida. Você escolhe também, junto e embutido, o tipo de pessoa que vai ser dentro dela. Vem tudo no mesmo pacote. Por isso o mito insiste tanto que a habilidade mais importante do mundo é conseguir prever o bem e o mal que uma vida pode trazer. Saber olhar pra uma opção e enxergar não o brilho da superfície, mas o que ela vai fazer com você por dentro, a longo prazo. Sem isso, você está apostando no escuro com o próprio destino.

E por que a gente não lembra de nada disso?

Boa pergunta, o mito responde. Antes de reencarnar, as almas atravessam uma planície árida e bebem a água do Rio do Esquecimento (em grego, Lete, palavra que significa literalmente “esquecimento”). Um gole e pronto: apagou tudo. Por isso ninguém chega aqui lembrando da própria escolha. A gente nasce sem o manual, sem o recibo, sem a memória de ter assinado embaixo. O que é meio sacana, admito. Mas também é exatamente o que torna a vida uma vida de verdade, e não a execução de um roteiro que você já leu antes.

O que Platão realmente quis dizer com tudo isso

1. É um ataque frontal ao fatalismo

Fatalismo é a crença de que está tudo escrito e não adianta nada fazer nada, “se tem que ser, vai ser”. O primo dele, o determinismo, é a ideia de que tudo o que você faz já foi causado por coisas fora do seu controle: genética, criação, sociedade, acaso. Repare no que Platão faz: ele não nega que exista destino. As Moiras estão lá, tecendo. O sorteio existe. O acaso existe e interfere de verdade. Ele poderia simplesmente ter dito “destino não existe”, mas não disse. O que ele faz é mais sofisticado: ele mostra que, mesmo dentro do destino, sobra liberdade. Você não escolhe a posição na fila. Você escolhe o que faz com ela. E como sempre sobra opção boa na mesa, a desculpa “eu não tinha alternativa” simplesmente não cola.

Essa é a tese central: o ser humano é livre e, por ser livre, é responsável pelo caminho que trilha.

2. É um recado sobre de quem é a culpa

Toda a estrutura do mito serve pra fechar as saídas de emergência que a gente usa pra fugir da responsabilidade.

Culpar os deuses ?? Negado.. a divindade é inocente. Culpar o sorteio ?? Negado.. sobrava vida boa. Culpar a falta de opção ?? Negado.. o cardápio era enorme. Culpar quem escolheu antes de você ?? Negado.. pergunte ao Ulisses.

Sobra o quê ?? Sobra você =)))))

3. A “escolha” não aconteceu num além-vida, ela está acontecendo agora

Esse é o ponto mais importante, e é onde o mito deixa de ser uma história sobre reencarnação e vira uma história sobre hoje. Lembra que o caráter vem embutido na escolha e é quase impossível de mudar depois ? Lembra que a alma que agarrou a vida de tirano fez isso por impulso, sem examinar ? Então: essa é uma imagem do que a gente faz o tempo todo.

A cada decisão, o que estudar, com quem andar, o que aceitar, o que deixar passar, que tipo de pessoa se permitir ser numa discussão, você está de novo naquele campo, escolhendo um pacote de vida sem enxergar direito o que vem dentro. E, assim como no mito, depois de um tempo fica muito difícil desfazer. O Rio do Esquecimento é a imagem perfeita disso: a gente esquece que está escolhendo. Age no automático, culpa as circunstâncias, e só percebe o pacote quando já é tarde.

4. Por isso a filosofia importa.. e essa é a real conclusão do livro

Aqui tudo se encaixa. Se a única coisa que separa uma escolha boa de uma escolha desastrosa é a capacidade de examinar as opções antes de agarrar a primeira que brilha, então a habilidade mais valiosa que existe é aprender a examinar. É isso que Platão chama de filosofia. Não decoreba de nomes gregos: é o treino de olhar pras coisas com calma e enxergar o que elas realmente são, e não o que aparentam ser. É exatamente o que Ulisses fez enquanto todo mundo se atropelava.

E aí a República fecha o círculo. A pergunta inicial era “vale a pena ser justo ?”. A resposta do mito é: vale, porque a justiça não é uma regra imposta de fora que te atrapalha, é o que mantém sua alma em ordem, e uma alma em ordem é a única coisa que consegue escolher bem. Ser injusto não te dá vantagem; te deixa cego na hora que mais importa enxergar.

“Sobre tudo o que se deve guardar, guarda o teu coração, porque dele procedem as fontes da vida.” — Provérbios 4:23

SÓCRATES: Glauco, sais da palestra como quem foge de um incêndio. Que aconteceu ?

GLAUCO: Uma discussão, Sócrates. Os jovens zombaram do velho Íkos, que ali ensina os lutadores. Diziam: “como pode ensinar a vencer quem nunca venceu em Olímpia ?”. E confesso que ri com eles, mas agora algo me incomoda.

SÓCRATES: O que te incomoda ?

GLAUCO: Íkos treinou três campeões. Nenhum de seus discípulos jamais perguntou por suas coroas, e todos saíram coroados. Como pode isso ?

SÓCRATES: Diz-me: o auriga que vence a corrida, vence pelos seus olhos ou pelos olhos do cavalo ?

GLAUCO: Pelos seus, suponho.

SÓCRATES: E aquele que, da arquibancada, percebe que o auriga aperta a curva cedo demais e perde meio corpo de vantagem, precisa ele próprio saber conduzir o carro ?

GLAUCO: Talvez não. Ver o erro e cometer o acerto parecem coisas distintas.

SÓCRATES: Então já encontraste duas artes onde julgavas haver uma. Há a arte de fazer, que mora nas mãos e nas pernas, e há a arte de ver e explicar, que mora nos olhos e na palavra. O corredor mais veloz de Atenas saberia dizer-te por que é veloz ?

GLAUCO: Duvido. Perguntei certa vez a um deles e respondeu apenas: “corro desde menino”.

SÓCRATES: Eis um homem que sabe e não sabe que sabe. Se o puseres a ensinar, dirá aos alunos “correi desde meninos”, e nada terá ensinado. E Íkos, que talvez jamais tenha derrubado um adversário, viu cair dez mil homens e sabe dizer de cada queda a causa. Qual dos dois formará o campeão ?

GLAUCO: Íkos, ao que parece. Então está resolvido: quem ensina não precisa ser exímio no que ensina.

SÓCRATES: Não corras tão depressa, Glauco, ou tropeçarás como o auriga da curva. Responde-me: aceitarias aprender a nadar com um homem que nunca entrou na água ?

GLAUCO: De modo algum!

SÓCRATES: E por quê, se há pouco concordamos que ensinar e fazer são artes distintas ?

GLAUCO: Porque… esse homem não conheceria a água. Falaria do mar como quem fala de um país que nunca visitou.

SÓCRATES: Muito bem. Então distingue comigo: uma coisa é exigir do mestre que seja o melhor dos praticantes; outra é exigir que conheça de dentro aquilo que ensina. Íkos lutou, caiu, sentiu a areia na boca. Não colheu coroas, mas colheu o conhecimento da luta. O que ele não tem é a glória; o que ele tem é a ciência.

GLAUCO: Mas então por que exigimos as coroas, Sócrates ? Por que a primeira pergunta que fazemos ao mestre é “o que venceste ?”, e não “o que compreendes ?”.

SÓCRATES: Porque as coroas se contam com os dedos, e a compreensão não se conta. O homem apressado prefere a prova que os olhos verificam num instante à prova que exige convivência e tempo. A coroa é um rótulo pendurado no peito, e já conversamos, noutra ocasião, sobre o quanto os rótulos poupam o trabalho de pensar.

GLAUCO: Então erramos ao cobrar reputação prática de quem ensina ?

SÓCRATES: Erramos e acertamos, Glauco, e é isso que te peço para não simplificar. Acertamos, porque a reputação prática é um indício: quem fez, provavelmente conhece. Erramos, porque tomamos o indício por prova: quem fez pode não saber explicar, e quem explica pode ter conhecido a coisa sem jamais brilhar nela. A coroa prova que o homem venceu; não prova que ele sabe por que venceu, e menos ainda que saiba fazer outro vencer.

GLAUCO: E o contrário também vale ? A ausência de coroa não prova ignorância ?

SÓCRATES: Assim como a ausência de riqueza não prova preguiça, nem a ausência de barba prova juventude. Mas nota: também não prova sabedoria. Há mestres sem coroa que são como Íkos, e há mestres sem coroa que são como o homem seco que ensina a nadar. A ausência do rótulo apenas te devolve o trabalho que o rótulo prometia poupar: o de examinar.

GLAUCO: E como examino, Sócrates ? Se não pelas vitórias do mestre, pelo quê ?

SÓCRATES: Pelos frutos que são propriamente seus. Os frutos do lutador são as quedas que provoca; os frutos do mestre são os lutadores que forma. Pergunta ao mestre não “o que venceste ?”, mas “quem aprendeu contigo, e o que se tornou ?”. E pergunta a ti mesmo, ao ouvi-lo: “compreendo mais agora do que antes ?”. Se a resposta for sim, tens diante de ti um mestre, tenha ele cem coroas ou nenhuma.

GLAUCO: Ainda assim, algo em mim resiste. Quando o mestre também executa com excelência, não é ele melhor ?

SÓCRATES: Talvez seja mais raro, Glauco, como é raro o cavalo que é belo e veloz ao mesmo tempo. Quando encontrares um homem que faz com excelência e explica com clareza, honra-o, pois a natureza foi generosa duas vezes. Mas não faças da generosidade dupla a medida de todos: exigirias de cada cavalo que fosse o mais belo e o mais veloz, e ficarias a pé.

GLAUCO: Então, afinal, é certo ou errado cobrar de quem ensina a reputação de quem executa ?

SÓCRATES: Essa balança, Glauco, não a carrego eu; carrega-a cada um que escolhe a quem confiar seu aprendizado. Eu apenas te mostro os pesos: de um lado, o indício honesto que a prática dá; do outro, a injustiça de medir uma arte com a régua de outra. Pesa-os tu mesmo, a cada mestre que encontrares, e desconfia de quem te vender a resposta pronta, inclusive de mim, que nunca venci luta alguma e passo os dias ensinando na praça.

..então Glauco ficou em silêncio, Sócrates sorriu do próprio exemplo..

Glossário

• palestra: escola de luta e exercícios físicos na Grécia antiga
• auriga: condutor de carros de corrida puxados por cavalos
• Olímpia: santuário onde se realizavam os Jogos Olímpicos da antiguidade
• Íkos: inspirado em Íkos de Tarento, atleta e depois célebre treinador grego

Nota

Quem ensina precisa dominar, de maneira prática, aquilo que ensina? A resposta parece óbvia, mas talvez não seja. Costumamos exigir de quem ensina o currículo de quem executa, como se a capacidade de explicar fosse consequência inevitável da experiência. No entanto, há quem nunca tenha alcançado os maiores feitos e ainda assim ensine com clareza e profundidade. Da mesma forma, há praticantes extraordinários incapazes de transmitir o que fazem.

Talvez a experiência prática seja um forte indício de competência, mas não uma prova definitiva da capacidade de ensinar. E a ausência dessa experiência também não basta, por si só, para invalidar um bom mestre. Entre a prática e a didática existe uma relação, mas não uma identidade. A questão permanece aberta: o que, afinal, qualifica alguém para ensinar ? Talvez a única certeza seja a lição socrática de que indícios não bastam e de que examinar cada caso continua sendo um trabalho sem atalhos.

Sem lenga lenga

Cuidado com uma armadilha cada vez mais comum nos vídeos que você assiste: a enrolação calculada. Ela tem até nomes técnicos. Padding é o ato de inflar um vídeo com conteúdo desnecessário apenas para aumentar sua duração. Burying the lede é esconder a informação principal até o final, fazendo você consumir muito conteúdo antes de chegar ao que realmente importa. Watch time baiting é prender sua atenção pelo maior tempo possível para aumentar as métricas de retenção. Fique atento aos sinais: promessas constantemente adiadas, recapitulações desnecessárias e a sensação de que a resposta está sempre “logo ali”. Quando perceber isso, lembre-se: o vídeo não foi feito para te informar, mas para maximizar o tempo que você passa assistindo. Seu tempo é valioso. Decida rapidamente se vale a pena continuar assistindo. Se o conteúdo demonstrar valor, consuma-o por completo. Se perceber que está sendo apenas retido, saia sem culpa.

Clickbait

Tome cuidado com títulos feitos para explorar sua curiosidade e seu medo de ficar de fora. Frases como “você precisa saber isso”, “sem isso você nunca vai conseguir”, “o erro que 99% das pessoas cometem” ou “ninguém está te contando isso” costumam apelar mais para a emoção do que para o conteúdo. Um bom conteúdo explica claramente o que você vai aprender. Um clickbait faz promessas vagas, exageradas ou urgentes para conquistar seu clique antes de conquistar sua confiança. Antes de abrir um vídeo, pergunte-se: o título descreve uma informação concreta ou apenas desperta ansiedade e curiosidade? Se a promessa for genérica demais, trate com ceticismo. Seu clique e sua atenção têm valor. Gaste-os apenas com conteúdos que entregam o que prometem.

Eu acho..

Tome cuidado com conteúdos que apresentam opiniões pessoais como se fossem fatos. Nem todo criador está transmitindo conhecimento; muitas vezes, está compartilhando sua própria visão de mundo, suas experiências e suas crenças, sem deixar isso explícito. Conhecimento pode ser verificado, questionado e comparado com evidências. Opiniões refletem interpretações individuais e podem variar de pessoa para pessoa. Quando essa diferença não é clara, é fácil absorver uma perspectiva particular como se fosse uma verdade universal. Pergunte-se: essa afirmação está sendo sustentada por dados, evidências ou fontes confiáveis, ou é apenas uma conclusão do autor? Desenvolver esse hábito ajuda a aprender de forma mais crítica e a construir suas próprias conclusões, em vez de apenas adotar as de outra pessoa.

Produto perfeito (:

Lembre-se de que apresentação não é conteúdo. Produção impecável, animações, slides chamativos, edição acelerada e promessas grandiosas podem tornar uma mensagem mais convincente, mas não a tornam mais verdadeira ou mais útil. Avalie primeiro o que está sendo dito, não como está sendo apresentado. A forma pode chamar sua atenção; o conteúdo é o que deve justificar seu tempo e sua confiança.

Sofistas do Youtube

• usam títulos e miniaturas chamativos para parecerem especialistas;
• falam com muita confiança, mesmo quando o conteúdo é superficial;
• priorizam retenção de audiência e engajamento em vez de profundidade;
• vendem a sensação de aprendizado, mas entregam pouco conhecimento prático.

O valor de mercado de uma empresa é menos uma verdade absoluta e mais um retrato da percepção do mercado num dado momento.

Quando alguém decide estudar seriamente um assunto novo, quase sempre experimenta uma espécie de ansiedade intelectual. É um fenômeno compreensível. À medida que cresce o desejo de conhecer, cresce também a consciência da própria ignorância. Quanto mais se enxerga, mais se percebe aquilo que ainda permanece oculto. “Só sei que nada sei” — Sócrates.

Nesse momento surge um problema que antes não existia: a limitação do tempo. Já não basta desejar aprender; torna-se necessário discernir o que merece aprofundamento e o que pode permanecer no campo da informação geral. A maturidade intelectual consiste precisamente nisso: saber até onde é preciso ir e onde convém parar.

Observando a realidade, percebe-se que existem, em linhas gerais, três tipos de estudiosos. O primeiro é o generalista superficial: conhece um pouco de muitas coisas, mas raramente alcança a essência de qualquer uma delas. O segundo é o especialista restrito: domina profundamente poucos assuntos, sacrificando a amplitude em favor da profundidade. O terceiro reúne ambas as qualidades: possui vasta cultura e, ao mesmo tempo, conhecimento profundo dos temas que estudou. É o tipo mais raro, pois exige não apenas inteligência, mas disciplina, tempo e uma extraordinária capacidade de ordenar o próprio pensamento.

O problema é que esse terceiro ideal, embora admirável, torna-se praticamente inalcançável dentro do tempo médio de vida de um ser humano, sobretudo para aqueles que possuem curiosidade genuína por diversas áreas do conhecimento. Basta um exame sincero da realidade para perceber que não há tempo suficiente para absorver tudo o que a humanidade já produziu, muito menos para acompanhar o que continua produzindo.

É nesse ponto que surge o primeiro grande desafio intelectual: a delimitação. Traçar uma linha não é um ato de resignação, mas de prudência. Sem essa delimitação, o estudante corre o risco de viver permanentemente assombrado pela sensação de insuficiência, como se estivesse sempre atrasado diante da imensidão do conhecimento disponível. A definição clara de objetivos não empobrece a busca intelectual; ao contrário, confere-lhe direção e sentido.

Há, porém, um segundo problema igualmente importante. A humanidade produziu e continua produzindo uma quantidade colossal de conteúdo sobre praticamente todos os assuntos imagináveis. Entretanto, quantidade jamais foi sinônimo de qualidade. Grande parte dessa produção nasce da ingenuidade, da falta de rigor, da insuficiência de informações ou, pior ainda, da substituição dos fatos por opiniões travestidas de conhecimento. Nem todo autor merece confiança. Nem toda obra merece atenção.

Por isso, duas virtudes tornam-se indispensáveis ao estudante: a capacidade de delimitar o próprio campo de investigação e a capacidade de selecionar cuidadosamente suas fontes. Antes de iniciar uma jornada de estudos, reserve algum tempo para determinar o que realmente precisa aprender e qual nível de domínio é necessário para atingir seu objetivo. Ao alcançá-lo, considere a meta cumprida. Caso contrário, o estudo transforma-se numa busca interminável, incapaz de produzir qualquer sensação legítima de conclusão.

Da mesma forma, reserve tempo para identificar autores, professores e pensadores que tenham resistido ao julgamento do tempo e cuja reputação tenha sido construída sobre a seriedade intelectual. Prefira aqueles que demonstram prudência ao avaliar seus predecessores, que conhecem a tradição da qual falam e que possuem a honestidade de distinguir claramente entre aquilo que sabem, aquilo em que acreditam e aquilo que apenas supõem. Em matéria de estudo, escolher os guias corretos é, muitas vezes, mais importante do que escolher os temas corretos.

Todos falam sobre a importância de possuir uma base de conhecimento sólida, mas poucos realmente compreendem o que isso significa. Quando você estuda um assunto e sente que não está entendendo nada, ou quando abre um livro e já nas primeiras páginas o considera excessivamente difícil ou enfadonho, talvez o problema não esteja no assunto nem no livro. Frequentemente, falta algum fundamento anterior que tornaria aquela experiência inteligível.

Tente estudar Cálculo Diferencial e Integral sem antes dominar a álgebra básica. Eu vivi essa experiência e posso afirmar com segurança: não funciona. O intelecto não avança por saltos arbitrários. O conhecimento possui uma estrutura, e cada degrau pressupõe os anteriores.

Demorei muito tempo para compreender a importância da lógica, da linguagem, da matemática básica, da epistemologia, do método científico, da estatística e da história das ideias. Durante anos pensei: “Para que vou precisar disso ?”. E, sob certo aspecto, eu tinha razão. No mercado de trabalho e na vida cotidiana convencional, grande parte desses conhecimentos parece dispensável. Na maioria das profissões, é perfeitamente possível viver sem eles.

Mas existe uma diferença entre aquilo que é útil para ganhar a vida e aquilo que é necessário para compreender a vida. Para uma existência orientada pelo autoconhecimento e pela compreensão da realidade, esses estudos constituem fundamentos indispensáveis. São instrumentos de libertação intelectual.

Vale a pena perguntar a si mesmo: aquilo que estou estudando possui relação com quem eu sou ou apenas com o lugar onde trabalho ?? Está ligado à minha formação como ser humano ou apenas ao próximo objetivo profissional que desejo alcançar ?

Essa é uma decisão difícil. O que você aprenderá para desenvolver-se como pessoa ? E o que aprenderá para adquirir habilidades práticas, aumentar sua utilidade econômica e tornar-se mais valorizado no mercado de trabalho ? No final, ambas as dimensões são importantes. Acredito que o erro está em sacrificar completamente uma delas em favor da outra.

Gostaria de encerrar com uma reflexão..

Quantas pessoas do seu convívio você conhece que ainda carregam o título informal de “curandeiras”, guardiãs de saberes transmitidos de geração em geração ? Quantas existirão daqui a cem anos ? Depois de responder mentalmente, saia de casa, caminhe duas quadras e observe a realidade ao seu redor. Muito provavelmente você encontrará uma drogaria. Elas estão por toda parte: em esquinas, avenidas, centros comerciais e bairros residenciais, acessíveis a poucos minutos de distância para a maioria da população.

Não se trata de rejeitar os avanços da medicina nem de idealizar o passado. A questão é outra: estamos nos tornando cada vez mais dependentes de sistemas que compreendemos cada vez menos. Perdemos contato com tradições, conhecimentos locais e formas de entendimento que durante séculos fizeram parte da experiência humana.

Tenho a impressão de que estamos formando indivíduos cada vez mais especializados em operar mecanismos e menos capazes de compreender a si mesmos. O conhecimento cresce em volume, mas a sabedoria parece tornar-se mais rara.

Eu sei.. este texto começou falando sobre conhecimento e terminou com a minha indignação :/ . Talvez porque, no fundo, conhecimento não seja apenas acumular informações, mas compreender o lugar que ocupamos no mundo e a direção para a qual estamos caminhando.

Lembro, por fim, de uma frase que ouvi certa vez de um cardiologista já falecido:

“Somente o conhecimento liberta o homem.” — E.C.

Conhecimento x Inteligência x Sabedoria

Conhecimento é o conjunto de informações, conceitos e fatos que uma pessoa adquiriu por estudo, observação ou experiência. Trata-se daquilo que alguém sabe. Um médico conhece anatomia, fisiologia e farmacologia porque estudou essas disciplinas; um mecânico conhece o funcionamento de motores porque aprendeu sua estrutura e operação. O conhecimento responde principalmente à pergunta: “o que é ?”.

Inteligência é a capacidade de compreender, relacionar, analisar e utilizar o conhecimento para resolver problemas ou lidar com situações novas. Duas pessoas podem possuir a mesma quantidade de conhecimento, mas apresentar níveis diferentes de inteligência ao aplicá-lo. Um estudante que aprende as fórmulas da física possui conhecimento; aquele que consegue utilizá-las para resolver um problema inédito demonstra inteligência. A inteligência responde à pergunta: “como usar aquilo que sei ?”.

Sabedoria é a capacidade de julgar corretamente o valor, os limites e as consequências do conhecimento e da inteligência na vida real. É uma virtude ligada à prudência, ao discernimento e à compreensão da natureza humana. Um investidor pode ter conhecimento sobre economia e inteligência para identificar oportunidades financeiras, mas somente a sabedoria lhe permitirá perceber quando já possui o suficiente, quando o risco é excessivo ou quando a busca por dinheiro está sacrificando aspectos mais importantes da vida. A sabedoria responde à pergunta: “vale a pena fazer isso e quais serão suas consequências ?”.

Em termos simples, conhecimento é saber que o fogo queima; inteligência é entender como produzir, controlar ou utilizar o fogo; sabedoria é saber quando acendê-lo, quando apagá-lo e quando manter distância dele. O conhecimento acumula informações, a inteligência transforma informações em soluções, e a sabedoria orienta essas soluções para fins verdadeiramente bons e adequados.

Essa distinção aparece, sob diferentes formulações, em autores como Aristóteles, que diferenciava ciência, técnica e prudência, e também em pensadores modernos da epistemologia e da psicologia cognitiva. Em todas as tradições sérias de pensamento, a conclusão é semelhante: é possível possuir muito conhecimento sem ser inteligente, ser inteligente sem ser sábio, mas é impossível ser verdadeiramente sábio sem possuir algum grau de conhecimento e inteligência. A sabedoria não substitui os dois; ela os ordena.

Ser polímata

Um polímata é alguém cuja mente transcende as fronteiras artificiais entre os campos do conhecimento, identificando os princípios, padrões e estruturas que conectam áreas distintas em uma compreensão unificada da realidade. Em vez de apenas acumular informações, o polímata sintetiza, reconstrói e integra saberes, transformando aprendizado em percepção sistêmica. Sua cognição não opera de forma linear ou compartimentalizada, mas como uma rede dinâmica de conexões, na qual ciência, filosofia, psicologia, política, finanças e experiência humana revelam diferentes expressões das mesmas verdades fundamentais.

SÓCRATES: Glauco, vejo-te de cenho franzido. Que te aflige ?

GLAUCO: Descobri, Sócrates, que um poeta cuja obra muito amo sustenta opiniões políticas que me repugnam. E outro, cujas ideias partilho como irmão, escreve versos sofríveis. Sinto que devo escolher um e renegar o outro.

SÓCRATES: Diz-me: quando comes uma figueira, julgas o fruto pelo sabor, ou pelas opiniões do agricultor ?

GLAUCO: Pelo sabor.

SÓCRATES: E se o agricultor for homem perverso, mas seus figos doces, deixarás de comê-los ?

GLAUCO: Não, pois o figo nada tem com a perversidade do homem.

SÓCRATES: Então a obra, uma vez feita, vive por si, ou depende a cada instante de quem a fez ?

GLAUCO: Vive por si.

SÓCRATES: Logo, podemos julgar o figo pelo que ele é, sem nos obrigarmos a louvar o agricultor em tudo. E inversamente: o fato de o homem ser virtuoso não tornará doce um figo amargo. Mistura essas coisas, Glauco, e perderás duas vezes: perderás o gosto dos bons figos, e perderás a clareza para julgar o homem.

GLAUCO: Compreendo. Mas há ainda outra coisa nesta tábua que me incomoda. Está escrito sobre mim: “Glauco é tolo.”

SÓCRATES: Só isso ?

GLAUCO: Só isso.

SÓCRATES: E se eu te dissesse: “Glauco, és tolo porque, calculando o preço de três ânforas de azeite, multiplicaste por dois e perdeste uma dracma”, que farias ?

GLAUCO: Veria se é verdade, e, sendo verdade, corrigiria o erro.

SÓCRATES: E se eu apenas dissesse “és tolo”, sem mais ?

GLAUCO: Não saberia o que corrigir, nem se há algo a corrigir.

SÓCRATES: Então uma afirmação te entrega uma razão, um caminho. A outra te entrega apenas uma pedra atirada. Diz-me: confiarias teu cavalo a um homem que estende a mão pedindo as rédeas sem dizer quem é ?

GLAUCO: Jamais.

SÓCRATES: E o teu juízo sobre ti mesmo, coisa muito mais valiosa que um cavalo, entregarás a quem te rotula sem dizer por quê ?

GLAUCO: Seria mais tolo do que ele me acusa de ser.

SÓCRATES: Guarda então esta regra: a acusação sem razão é palha ao vento, ignora-a. A acusação com razão é semente que pode germinar em ti, examina-a. Mas nota bem, Glauco: ninguém pode examinar por ti. Nem eu, nem o autor da tábua, nem a multidão da praça.

GLAUCO: Como assim, Sócrates ?

SÓCRATES: Quero dizer que o trabalho de pesar as razões, aceitar o que se sustenta e descartar o que não se sustenta, é teu e somente teu. Não é apenas sobre homens que isto vale, Glauco. É sobre tudo o que encontras: uma lei que te impõem, um conselho que recebes, uma decisão que precisas tomar na tua casa ou na tua cidade. Em todas, alguém quererá pensar por ti.

GLAUCO: E se eu errar ao decidir sozinho ?

SÓCRATES: Errarás. E é isto que distingue o homem livre do escravo: o homem livre carrega as consequências do que conclui. Se decidires bem, colherás. Se decidires mal, perderás. Mas em ambos os casos terás aprendido algo que ninguém pode aprender por ti.

GLAUCO: E aquele que prefere que outro decida em seu lugar ?

SÓCRATES: Esse vive uma vida emprestada. Quando algo der certo, não terá o mérito. Quando algo der errado, culpará o outro, e nada aprenderá, pois o erro não foi propriamente seu. É a pior das condições, Glauco: a do homem que nunca falha por nunca ter ousado julgar.

GLAUCO: Então a liberdade tem o preço da responsabilidade.

SÓCRATES: Esse é seu preço, e também sua dignidade. Examina cada obra, cada acusação, cada situação. Pede sempre as razões. Decide. E quando a consequência vier, doce ou amarga, recebe-a como tua. É o único caminho para se tornar de fato alguém.

..então Sócrates ajeitou o manto, Glauco virou a tábua contra a parede, e ambos foram tomar uma cerveja.

Glossário

• ânforas: vasos antigos usados para guardar líquidos como vinho e azeite
• dracma: moeda usada na Grécia antiga
• pórtico: entrada com colunas na frente de um edifício
• cenho franzido: expressão de preocupação ou irritação; testa enrugada por tensão

Nota

Ler os textos gregos implica não tratá-los como meras construções discursivas, mas como registros de uma percepção efetiva da realidade, orientada pela busca de apreender a essência e os processos internos dos objetos da natureza.

Quando li A República, de Platão eu sabia que não tinha e talvez ainda não tenha a base suficiente para aproveitá-la plenamente, mesmo assim senti que era uma leitura que valia a pena. Quero relê-la em breve, justamente para perceber como a experiência com uma obra muda conforme amadurecemos como leitores.

Meu nome é Vinícius Gomes Batista. Antes de qualquer coisa, quero me apresentar brevemente e contar um pouco sobre o que você vai encontrar por aqui.

Como acontece com muita gente da área de tecnologia, meu interesse por computadores começou cedo. Antes mesmo de entrar no mercado de trabalho, eu já tinha alguma experiência, prestava serviços de maneira informal e demonstrava bastante interesse por infraestrutura e segurança da informação.

Sou da época das lan houses. Não sou tão velho assim, mas ainda peguei os disquetes, os monitores de tubo e aqueles gabinetes brancos enormes. Três nostalgias que deixo aqui apenas como curiosidade: Dracula: The Resurrection, MSN e Windows XP.

Passei boa parte da adolescência sentado em frente ao computador, conversando com pessoas no IRC. Foi um dos ambientes onde mais aprendi. Conheci pessoas de todos os tipos, com experiências, conhecimentos e habilidades completamente diferentes. Boa parte da minha curiosidade por tecnologia foi alimentada por keywords que surgiam nessas conversas.

Minha carreira profissional começou há seis anos, como desenvolvedor fullstack, trabalhando com .NET e Vue.js. Mais tarde, migrei para Engenharia de Confiabilidade (SRE).

Minha transição de desenvolvedor fullstack para SRE aconteceu principalmente porque eu gostava de ter uma visão holística dos sistemas, dos produtos e até das organizações. Por onde passei, sempre quis entender tudo. Não bastava saber como uma aplicação funcionava; eu queria entender onde ela rodava, de quais componentes dependia, com quais serviços se comunicava e o que aconteceria se alguma dessas partes deixasse de funcionar.

Foi essa mesma curiosidade que despertou meu interesse por observabilidade. A possibilidade de representar o comportamento dos sistemas, suas dependências e integrações por meio de métricas, traces, logs e dashboards sempre me chamou a atenção. Mas, para mim, nunca se tratou apenas de colocar gráficos em uma tela. O interessante era conseguir olhar para aqueles dados e compreender o que estava acontecendo, por que estava acontecendo e como o comportamento dos sistemas mudava ao longo do tempo.

Com o tempo, esse interesse me levou a uma segunda transição, dessa vez para Engenharia de Plataforma, mais especificamente para plataformas de observabilidade, área em que concentrei minha atuação nos últimos 12 meses.

E é mais ou menos desse percurso que surge a vontade de voltar a escrever.

Por aqui, pretendo compartilhar um pouco do que vivi ao longo desses anos trabalhando com tecnologia. Quero falar principalmente sobre experiências práticas, problemas que enfrentei, erros que cometi, lições que me custaram caro e coisas que gostaria que alguém tivesse me contado antes.

Também quero abordar os desafios de trabalhar em áreas técnicas de grandes organizações. Quem já passou por esse tipo de ambiente provavelmente conhece algumas das contradições: processos excessivamente rígidos, burocracias desnecessárias e culturas organizacionais que, muitas vezes, acabam dificultando o trabalho justamente em nome da estabilidade, da segurança e da eficiência que deveriam promover.

A ideia não é apenas criticar essas situações, mas refletir sobre elas, entender suas causas e discutir o que poderia ser feito de maneira diferente.

Mas não espere encontrar apenas conteúdo técnico.

Também gosto bastante de filosofia e de refletir sobre a vida fora do trabalho. Algumas leituras, conversas e experiências acabam despertando questões que ficam martelando na minha cabeça por dias. Escrever sempre me pareceu uma boa maneira de organizar esses pensamentos.

Quero aproveitar este espaço para comentar livros e outras obras, compartilhar reflexões e desenvolver ideias que nem sempre estarão completamente formadas. Afinal, nem tudo o que vale a pena escrever precisa começar com uma conclusão.

No fim das contas, este blog é uma forma de registrar o que aprendi, organizar minhas ideias e, quem sabe, trocar experiências com outras pessoas. Não tenho a pretensão de ensinar verdades absolutas, muito menos de parecer alguém que tem respostas para tudo. Pelo contrário, muitas vezes escrevo justamente porque ainda tenho perguntas que não consegui responder.

E acho que é isso. Não pretendo contar toda a minha história em uma única apresentação. Se você continuar aparecendo por aqui e acompanhando meus textos, provavelmente vai acabar me conhecendo um pouco melhor com o tempo. Além disso, pretendo fazer alguns appends nesta página de tempos em tempos, acrescentando lembranças, experiências e pensamentos que eu considere importantes o suficiente para deixar registrados.

No fundo, a ideia é que, quando eu me aposentar, exista algum registro dos caminhos que percorri, das coisas que aprendi e das experiências que vivi. É algo que escrevo de mim para o meu eu do futuro, uma espécie de memória que não quero deixar se perder. Mas, quem sabe, no meio de tudo isso, alguma coisa também possa ser útil para alguém que passar por aqui.

Me encontra no GitHub e no X.

“apolzek” is a nickname born from the combination of two people I met during the IRC chat days: Apol-0 and ZekAng3l