DEV Community: python

Como aprendi Apache Spark — Parte 10: Client Mode vs. Cluster Mode — onde o Spark realmente executa

renanpyd — Fri, 06 Nov 2026 19:50:43 +0000

Nota de atualização (2026): este artigo revisita conceitos da minha jornada de aprendizado de Apache Spark e os conecta aos ambientes modernos de implantação. Algumas opções de execução, integrações e recomendações surgiram ou evoluíram depois dos primeiros anos do projeto.

Nos nove artigos anteriores, exploramos a arquitetura do Apache Spark por diferentes perspectivas.

Aprendemos que uma aplicação Spark possui um Driver, que coordena o processamento, e Executors, responsáveis por executar Tasks sobre partições de dados.

Também vimos que o Spark organiza o trabalho em Jobs, Stages e Tasks, utiliza shuffle para redistribuir dados, gerencia memória, mantém lineage para recuperação de falhas e oferece mecanismos como Broadcast Variables e Accumulators.

Mas existe uma pergunta que ainda não respondemos completamente:

Onde o Driver realmente executa quando enviamos uma aplicação Spark para um cluster?

E uma segunda pergunta igualmente importante:

Quem inicia, gerencia e encerra os Executors?

Essas questões nos levam a três conceitos fundamentais:

Deployment Mode.
Cluster Manager.
Application Submission.

Vamos entender como eles se relacionam e por que essa distinção é essencial para desenvolver, implantar e operar aplicações Spark em produção.

1. O que acontece quando executamos uma aplicação Spark?

Considere uma aplicação PySpark:

from pyspark.sql import SparkSession
from pyspark.sql.functions import col

spark = (
    SparkSession.builder
    .appName("VendasAnalytics")
    .getOrCreate()
)

vendas = spark.read.parquet(
    "/data/vendas"
)

resultado = (
    vendas
    .filter(col("ano") == 2026)
    .groupBy("estado")
    .sum("valor")
)

resultado.show()

spark.stop()

O código parece simples.

Mas, dependendo de onde executamos a aplicação, existe uma infraestrutura por trás:

                  APPLICATION
                       |
                       v
                     DRIVER
                       |
                       v
                 CLUSTER MANAGER
                       |
             +---------+---------+
             |         |         |
             v         v         v
         EXECUTOR 1 EXECUTOR 2 EXECUTOR 3
             |         |         |
           TASKS     TASKS     TASKS

O Driver coordena o processamento.

O Cluster Manager participa da alocação e do gerenciamento dos recursos necessários.

Os Executors realizam o trabalho distribuído.

A localização e o ciclo de vida desses componentes dependem do ambiente de implantação.

2. Driver, Executor e Cluster Manager não são a mesma coisa

Antes de falar sobre Client Mode e Cluster Mode, precisamos separar três responsabilidades.

Driver

O Driver é o processo que coordena a aplicação Spark.

Entre suas responsabilidades estão:

Executar o programa principal.
Construir e coordenar operações Spark.
Planejar Jobs e Stages.
Agendar Tasks.
Acompanhar resultados e falhas.
Interagir com os Executors.

Executor

Os Executors são processos associados à aplicação Spark que executam Tasks e armazenam dados intermediários ou persistidos conforme necessário.

Eles utilizam recursos como CPU, memória, disco e rede.

Cluster Manager

O Cluster Manager gerencia recursos computacionais do ambiente.

Dependendo da plataforma, ele pode ser responsável por alocar containers, Pods ou processos para os componentes Spark.

Uma visão simplificada:

Driver
  |
  | Solicita recursos e coordena execução
  |
  v
Cluster Manager
  |
  | Disponibiliza recursos
  |
  v
Executors
  |
  | Executam Tasks
  |
  v
Distributed Processing

É importante lembrar que o Cluster Manager não substitui o scheduler interno do Spark.

O Spark continua responsável por organizar e distribuir suas Tasks entre os Executors disponíveis.

3. O que é Deployment Mode?

Deployment Mode define, principalmente, onde o processo Driver será executado em relação ao ambiente que submete a aplicação.

Os dois modos mais conhecidos são:

Client Mode

Cluster Mode

Essa distinção parece pequena, mas afeta diretamente:

Conectividade.
Logs.
Disponibilidade do Driver.
Empacotamento da aplicação.
Operação em produção.
Diagnóstico de falhas.

Vamos começar pelo Client Mode.

4. Client Mode

No Client Mode, o Driver executa no ambiente de onde a aplicação é submetida.

Imagine que estamos utilizando uma máquina de desenvolvimento ou um servidor de borda para executar:

spark-submit \
  --deploy-mode client \
  app.py

Em um ambiente de cluster compatível, a arquitetura conceitual é:

       MÁQUINA DE SUBMISSÃO
       +-------------------+
       |                   |
       |      DRIVER       |
       |                   |
       +---------+---------+
                 |
                 | Comunicação
                 |
                 v
          CLUSTER MANAGER
                 |
       +---------+---------+
       |         |         |
       v         v         v
   EXECUTOR 1 EXECUTOR 2 EXECUTOR 3

O Driver permanece no processo de submissão.

Os Executors podem executar em outros nós.

Isso significa que o Driver precisa conseguir se comunicar adequadamente com os Executors e com os serviços relevantes do cluster.

5. Por que Client Mode é útil?

Client Mode costuma ser conveniente em cenários como:

Desenvolvimento interativo.
Depuração.
Sessões de notebooks.
Execução a partir de servidores de borda.
Aplicações nas quais desejamos acompanhar diretamente a saída do Driver.

Imagine que estamos investigando um pipeline.

Queremos observar mensagens como:

Starting Spark application...
Loading dataset...
Executing aggregation...
Writing output...
Application finished.

No Client Mode, a saída do Driver normalmente fica associada ao ambiente de submissão.

Isso facilita determinados fluxos de desenvolvimento e troubleshooting.

Mas também traz responsabilidades.

6. A máquina cliente faz parte da execução

Um erro comum é imaginar:

Enviei a aplicação para o cluster. Agora minha máquina não importa mais.

Em Client Mode, isso não é verdade.

O Driver continua executando no ambiente cliente.

Se esse processo for encerrado, a aplicação poderá ser interrompida.

Considere:

Developer Laptop
       |
       v
     Driver
       |
       v
    Cluster

Se o laptop for desligado ou o processo Driver terminar, não devemos assumir que a aplicação continuará normalmente.

O comportamento exato depende do ambiente e de seus mecanismos de supervisão, mas o princípio permanece:

O Driver é parte ativa da aplicação.

7. Client Mode e conectividade

Outra consequência importante é a rede.

Os Executors precisam se comunicar com o Driver.

Imagine:

Developer Laptop
       |
       | VPN / Firewall / NAT
       |
       v
   Spark Cluster

Se os Executors não conseguem alcançar o endereço anunciado pelo Driver, a aplicação pode falhar mesmo que exista CPU e memória disponíveis.

Problemas comuns incluem:

Endereço incorreto do Driver.
DNS.
Firewall.
Portas bloqueadas.
NAT.
Instabilidade de VPN.
Interfaces de rede configuradas incorretamente.

Em ambientes corporativos, essa é uma das razões para utilizar servidores de borda ou plataformas de notebooks integradas ao cluster.

8. Cluster Mode

Agora vamos mudar a localização do Driver.

No Cluster Mode, o Driver é executado dentro do ambiente gerenciado pelo cluster, conforme os mecanismos da plataforma utilizada.

Conceitualmente:

       MÁQUINA DE SUBMISSÃO
       +-------------------+
       |                   |
       |   spark-submit    |
       |                   |
       +---------+---------+
                 |
                 | Submete aplicação
                 |
                 v
          CLUSTER MANAGER
                 |
       +---------+---------+
       |                   |
       v                   v
     DRIVER             EXECUTORS
       |                   |
       +---------+---------+
                 |
                 v
          DISTRIBUTED JOB

A diferença central é:

O Driver não precisa permanecer no processo cliente que iniciou a submissão.

Isso torna o Cluster Mode adequado a muitos cenários de execução automatizada.

9. Cluster Mode é melhor para produção?

Frequentemente, Cluster Mode é uma escolha conveniente para Jobs batch de produção.

Mas não devemos transformar isso em uma regra absoluta.

Existem plataformas gerenciadas e arquiteturas específicas em que o ciclo de vida da aplicação é controlado de outras maneiras.

O importante é compreender os requisitos.

Por exemplo:

Pipeline noturno
       |
       v
Scheduler
       |
       v
Application Submission
       |
       v
Cluster-managed Driver
       |
       v
Executors

Nesse cenário, não queremos depender de uma sessão interativa de desenvolvimento para manter a aplicação ativa.

Cluster Mode ajuda a separar o ambiente de submissão do ambiente de execução.

10. Client Mode vs. Cluster Mode

Característica	Client Mode	Cluster Mode
Localização do Driver	Ambiente de submissão	Ambiente gerenciado pelo cluster
Uso frequente	Desenvolvimento e sessões interativas	Jobs automatizados e batch
Logs do Driver	Próximos ao processo cliente	Normalmente obtidos pela plataforma
Dependência do cliente	Driver permanece no cliente	Submissão pode terminar sem encerrar necessariamente a aplicação
Conectividade	Executors precisam alcançar o Driver cliente	Driver executa na rede do cluster
Disponibilidade	Depende do processo Driver cliente	Depende do cluster e da supervisão
Melhor escolha	Depende do cenário	Depende do cenário

O ponto principal é:

Client Mode e Cluster Mode descrevem a localização do Driver, não a quantidade de dados processados nem o grau de paralelismo da aplicação.

11. Deployment Mode não é Cluster Manager

Agora precisamos evitar outra confusão.

Deployment Mode responde:

Onde o Driver executa?

Cluster Manager responde:

Qual sistema gerencia os recursos do ambiente?

São dimensões diferentes.

Por exemplo, dependendo do suporte da plataforma, podemos encontrar combinações como:

YARN + Client Mode
YARN + Cluster Mode

Kubernetes + Client Mode
Kubernetes + Cluster Mode

Standalone + Client Mode
Standalone + Cluster Mode

Entretanto, a disponibilidade de cada combinação depende do Cluster Manager, da linguagem e da versão do Spark.

Em particular, o suporte a aplicações Python em Standalone Cluster Mode possui restrições documentadas em versões do Spark. Portanto, não devemos presumir que todas as combinações funcionam igualmente.

12. Spark Standalone

Spark Standalone é o gerenciador de cluster próprio do Apache Spark.

Sua arquitetura clássica envolve:

             STANDALONE MASTER
                     |
           +---------+---------+
           |         |         |
           v         v         v
        WORKER 1  WORKER 2  WORKER 3
           |         |         |
           v         v         v
        EXECUTOR  EXECUTOR  EXECUTOR

O Master coordena a disponibilidade dos recursos do cluster Standalone.

Os Workers disponibilizam recursos computacionais.

O Driver e os Executors são iniciados conforme o modo de implantação e os recursos disponíveis.

Esse modelo é útil para compreender a arquitetura do Spark sem adicionar toda a complexidade de um gerenciador externo.

13. Spark em YARN

YARN significa:

Yet Another Resource Negotiator.

Ele faz parte do ecossistema Hadoop e gerencia recursos para aplicações distribuídas.

Uma visão simplificada:

                  YARN
                   |
             ResourceManager
                   |
        +----------+----------+
        |          |          |
        v          v          v
     NodeManager NodeManager NodeManager
        |          |          |
        v          v          v
     Containers Containers Containers

O Spark pode utilizar esses recursos para executar seus componentes.

No YARN, existe também o conceito de ApplicationMaster, cujo papel e relacionamento com o Driver variam conforme o deployment mode.

14. YARN Client Mode

No YARN Client Mode, o Driver executa no ambiente cliente.

Conceitualmente:

        CLIENT MACHINE
        +------------+
        |   DRIVER   |
        +-----+------+
              |
              v
        YARN CLUSTER
              |
        ApplicationMaster
              |
       +------+------+
       |             |
       v             v
   Executor 1    Executor 2

O ApplicationMaster participa do gerenciamento dos recursos da aplicação no YARN.

O Driver permanece no cliente.

Esse detalhe é importante ao interpretar logs e falhas.

15. YARN Cluster Mode

No YARN Cluster Mode, o Driver executa no cluster, dentro do contexto da aplicação gerenciada pelo YARN.

Uma visão conceitual:

       SUBMISSION CLIENT
               |
               v
         YARN CLUSTER
               |
               v
        ApplicationMaster
        +--------------+
        |    DRIVER    |
        +------+-------+
               |
        +------+------+
        |             |
        v             v
    Executor 1    Executor 2

Nesse modo, o Driver não depende de continuar executando na máquina que fez a submissão.

Para workloads batch, isso frequentemente simplifica a operação.

16. Spark em Kubernetes

Kubernetes utiliza uma arquitetura baseada em recursos como Pods, Deployments, Services e outros objetos.

No Spark, podemos executar o Driver e os Executors em Pods.

Uma visão típica de Cluster Mode:

             spark-submit
                  |
                  v
          KUBERNETES API
                  |
                  v
              DRIVER POD
                  |
                  v
          EXECUTOR PODS
          /     |     \
         v      v      v
       Exec 1 Exec 2 Exec 3

O Driver solicita os recursos necessários por meio da integração Spark com Kubernetes.

Os Executors executam em Pods associados à aplicação.

Isso facilita a integração com práticas modernas de infraestrutura containerizada.

17. Kubernetes não elimina a arquitetura do Spark

É importante compreender:

Kubernetes

não substitui:

Spark DAG Scheduler

nem:

Spark Task Scheduler

O Kubernetes gerencia recursos e o ciclo de vida dos Pods.

O Spark continua responsável por:

Construir planos de execução.
Organizar Jobs e Stages.
Distribuir Tasks.
Coordenar Executors.
Gerenciar shuffle e recomputação.

Podemos pensar:

Kubernetes
    |
    v
Resource Orchestration
    |
    v
Spark Application
    |
    v
Distributed Data Processing

São responsabilidades complementares.

18. E o modo local?

Antes de utilizar um cluster real, podemos executar Spark localmente.

Por exemplo:

spark = (
    SparkSession.builder
    .master("local[*]")
    .appName("SparkLocal")
    .getOrCreate()
)

O parâmetro:

local[*]

indica que o Spark pode utilizar os núcleos lógicos disponíveis na máquina local.

Também podemos utilizar:

local[2]

para configurar dois threads de execução local.

Exemplo:

spark = (
    SparkSession.builder
    .master("local[2]")
    .appName("SparkLocal")
    .getOrCreate()
)

Isso é útil para desenvolvimento e experimentação.

Mas precisamos lembrar que uma execução local não reproduz integralmente:

Latência de rede entre nós.
Comportamento de um cluster real.
Falhas distribuídas.
Restrições de containers.
Escalabilidade de armazenamento.
Dinâmica de alocação de recursos.

Portanto, testes locais são importantes, mas não substituem validação no ambiente de destino.

19. O que é `spark-submit`?

spark-submit é a ferramenta de submissão de aplicações Spark.

Ela permite informar:

Aplicação.
Cluster Manager.
Deployment Mode.
Recursos.
Configurações.
Dependências.
Argumentos da aplicação.

A estrutura geral é:

spark-submit \
  --master <MASTER> \
  --deploy-mode <MODE> \
  --conf <KEY=VALUE> \
  app.py

Os valores exatos dependem do ambiente.

20. Exemplo local com `spark-submit`

Vamos criar uma aplicação simples.

Arquivo:

app.py

Conteúdo:

from pyspark.sql import SparkSession
from pyspark.sql.functions import col

spark = (
    SparkSession.builder
    .appName("ExemploSparkSubmit")
    .getOrCreate()
)

dados = spark.range(1, 1_000_001)

resultado = dados.filter(
    col("id") % 2 == 0
)

print(
    "Quantidade de números pares:",
    resultado.count()
)

spark.stop()

Executamos:

spark-submit \
  --master "local[*]" \
  app.py

Resultado esperado:

Quantidade de números pares: 500000

Esse exemplo é suficiente para compreender a estrutura básica de uma submissão.

21. Exemplo de submissão para YARN

Em um ambiente YARN configurado:

spark-submit \
  --master yarn \
  --deploy-mode cluster \
  --driver-memory 4g \
  --executor-memory 8g \
  --executor-cores 2 \
  --num-executors 4 \
  app.py

Aqui estamos solicitando uma aplicação com determinados recursos.

Mas atenção:

Esses valores são ilustrativos, não uma recomendação universal de dimensionamento.

O tamanho adequado depende de:

Volume de dados.
Tipo de operação.
Quantidade de partições.
Shuffle.
Memória.
Concorrência.
Limites do cluster.

Esse raciocínio conecta diretamente a Parte 7.

22. Exemplo de submissão para Kubernetes

Em um ambiente Kubernetes com Spark configurado, uma submissão pode seguir este formato:

spark-submit \
  --master k8s://https://K8S_API_SERVER:6443 \
  --deploy-mode cluster \
  --name spark-example \
  --conf spark.kubernetes.container.image=REGISTRY/SPARK_IMAGE:TAG \
  --conf spark.executor.instances=3 \
  local:///opt/spark/app.py

Os valores são placeholders e precisam ser substituídos pelos recursos reais do ambiente.

Observe:

k8s://

que identifica a integração com Kubernetes.

local:///opt/spark/app.py

que, nesse exemplo, indica um arquivo disponível dentro da imagem/container utilizado na execução.

A imagem precisa conter a aplicação nesse caminho, além de estar preparada para executar Spark corretamente.

23. `--master` e `--deploy-mode`

Esses dois parâmetros merecem atenção especial.

`--master`

Indica o ambiente de execução ou o gerenciador de cluster.

Exemplos:

local[*]
spark://HOST:7077
yarn
k8s://https://HOST:6443

`--deploy-mode`

Indica a localização do Driver.

Exemplos:

client
cluster

Portanto:

--master yarn \
--deploy-mode cluster

significa:

Utilizar YARN como Cluster Manager e executar o Driver no ambiente do cluster.

São decisões relacionadas, mas distintas.

24. O que acontece depois do `spark-submit`?

Uma sequência conceitual:

1. spark-submit
       |
       v
2. Application Submission
       |
       v
3. Driver Initialization
       |
       v
4. SparkSession / SparkContext
       |
       v
5. Resource Allocation
       |
       v
6. Executors Available
       |
       v
7. Action Triggered
       |
       v
8. Job Created
       |
       v
9. Stages Planned
       |
       v
10. Tasks Scheduled
       |
       v
11. Distributed Execution
       |
       v
12. Results / Writes
       |
       v
13. Application Completion

A ordem exata de alguns eventos depende do Cluster Manager e do modo de implantação.

Mas essa sequência ajuda a conectar submissão e execução distribuída.

25. O Driver precisa acessar os dados?

Essa pergunta merece cuidado.

O Driver normalmente coordena o processamento, mas a leitura distribuída de grandes datasets é realizada pelos Executors.

Ainda assim, dependendo do código e das fontes utilizadas, o Driver pode precisar acessar:

Metadados.
Catálogos.
Configurações.
Endpoints de serviços.
Informações de schema.
Caminhos e credenciais.
Recursos necessários para planejamento.

Não devemos assumir que apenas os Executors precisam de conectividade com os sistemas externos.

A arquitetura precisa considerar o acesso de cada componente.

26. O erro clássico de caminhos locais

Imagine uma aplicação:

df = spark.read.csv(
    "/home/usuario/dados.csv"
)

Ela funciona no notebook local.

Depois enviamos para um cluster.

Agora os Executors estão em outras máquinas.

O caminho:

/home/usuario/dados.csv

pode não existir nesses nós.

O problema não está necessariamente no código de leitura.

Está na arquitetura de armazenamento.

Em produção, geralmente utilizamos fontes acessíveis aos componentes relevantes do cluster, como:

HDFS
S3
ADLS
GCS
Distributed Storage

ou volumes compartilhados adequadamente configurados.

Essa é uma das diferenças mais importantes entre desenvolvimento local e execução distribuída.

27. Código local não é necessariamente código distribuído

Considere:

with open(
    "/home/usuario/config.json"
) as arquivo:
    configuracao = arquivo.read()

Se isso acontecer no Driver, o arquivo precisa estar acessível ao Driver.

Agora imagine que uma função executada pelos workers tente abrir esse mesmo caminho.

Os Executors podem estar em máquinas ou containers diferentes.

Então precisamos perguntar:

Onde o arquivo existe?

Qual processo precisa acessá-lo?

Esse raciocínio se conecta à Parte 9 sobre closures, serialização e variáveis distribuídas.

28. Empacotamento da aplicação

Em projetos reais, uma aplicação Spark raramente é apenas um arquivo.

Podemos ter:

spark-project/
|
+-- app.py
+-- src/
|   +-- transformations/
|   +-- validations/
|   +-- connectors/
|
+-- config/
+-- tests/
+-- requirements.txt

Em produção, precisamos garantir que o código e suas dependências estejam disponíveis onde serão executados.

Isso pode envolver:

Pacotes Python.
Arquivos distribuídos.
Imagens de container.
Bibliotecas JVM.
Dependências nativas.
Configuração de ambiente.

Uma aplicação que funciona localmente pode falhar em produção simplesmente porque uma dependência não foi disponibilizada aos Executors.

29. Python e ambiente de execução

Em PySpark, precisamos lembrar que existe execução de código Python associada aos workers.

Isso significa que versões e dependências Python importam.

Por exemplo:

Driver
  |
  +-- Python Environment
  |
Executors
  |
  +-- Python Workers
      |
      +-- Required Libraries

Se uma biblioteca existe apenas na máquina cliente, mas não está disponível no ambiente dos workers, determinadas operações podem falhar.

Em ambientes containerizados, uma estratégia comum é construir imagens que contenham as dependências necessárias.

Em outras plataformas, podemos distribuir ambientes ou pacotes conforme os mecanismos suportados.

30. Logs: onde procurar?

Agora chegamos a uma questão prática.

Quando uma aplicação falha, onde estão os logs?

A resposta depende do ambiente.

Client Mode

Os logs do Driver normalmente estão associados ao processo de submissão.

Os logs dos Executors ficam no ambiente onde eles executam.

Cluster Mode

Os logs do Driver normalmente precisam ser consultados por meio dos mecanismos da plataforma.

Em Kubernetes, por exemplo, podemos investigar os logs do Driver Pod.

Em YARN, podemos utilizar os mecanismos de logs da aplicação.

O ponto principal é:

Saber onde o Driver executa ajuda a saber onde procurar o erro.

31. Spark UI

A Spark UI continua sendo uma das ferramentas mais importantes de observabilidade.

Ela permite investigar informações como:

Jobs
Stages
Tasks
Executors
Storage
SQL Queries

Dependendo do ambiente e da configuração, podemos acessar a interface diretamente ou por meio de proxies, túneis e interfaces da plataforma.

A Spark UI normalmente utiliza a porta 4040 como ponto inicial para aplicações em execução, mas a porta pode variar quando já está ocupada ou quando a plataforma utiliza mecanismos próprios.

Não devemos assumir que a interface estará diretamente exposta na rede.

32. Spark History Server

Existe uma diferença importante entre observar uma aplicação em execução e investigar uma aplicação que já terminou.

Durante a execução, a Spark UI oferece informações do estado atual.

Para análise posterior, podemos utilizar o Spark History Server, quando o registro de eventos está habilitado e configurado.

Conceitualmente:

Spark Application
       |
       v
Event Logs
       |
       v
Persistent Storage
       |
       v
Spark History Server
       |
       v
Post-execution Analysis

Isso é especialmente útil em ambientes de produção.

Imagine um pipeline que executa às 3h da manhã.

Se ele falhar, precisamos conseguir investigar o que aconteceu depois.

33. Falha de Executor vs. falha de Driver

Vamos conectar com a Parte 8.

Executor Failure

Executor 2
    |
    v
Failure
    |
    v
Lost Tasks / Data
    |
    v
Retry / Recomputation

Em determinados cenários, Spark consegue recuperar o trabalho.

Driver Failure

Driver
   |
   v
Failure
   |
   v
Application Coordination Lost

A falha do Driver possui consequências diferentes.

O reinício ou a recuperação da aplicação depende dos mecanismos de implantação, supervisão e tolerância a falhas disponíveis.

Por isso, escolher Client Mode ou Cluster Mode também influencia a estratégia operacional.

34. Cluster Mode não significa alta disponibilidade automática

Esse é um ponto importante.

Executar o Driver dentro do cluster não garante, por si só, que ele seja automaticamente recuperado de qualquer falha.

Podemos ter:

Cluster Mode
     |
     v
Driver Pod
     |
     v
Failure

A recuperação depende de mecanismos como:

Supervisão da aplicação.
Políticas de reinício.
Recursos do Cluster Manager.
Orquestração externa.
Persistência de estado.
Reexecução do Job.

Portanto:

Cluster Mode

não é sinônimo de:

Exactly-once execution

nem de:

Automatic complete recovery

Essas garantias precisam ser analisadas separadamente.

35. Orquestração de Jobs Spark

Em ambientes reais, aplicações Spark frequentemente fazem parte de pipelines maiores.

Por exemplo:

Airflow / Orchestrator
        |
        v
spark-submit
        |
        v
Spark Application
        |
        v
Data Lake
        |
        v
Validation
        |
        v
Analytics

O orquestrador controla aspectos como:

Agendamento.
Dependências entre Jobs.
Retentativas.
Alertas.
Parâmetros.
Monitoramento do workflow.

O Spark executa o processamento distribuído.

São responsabilidades complementares.

36. Uma arquitetura de produção

Imagine uma plataforma de Engenharia de Dados:

                 ORCHESTRATOR
                      |
                      v
                 SPARK JOB
                      |
                      v
                 CLUSTER MANAGER
                      |
             +--------+--------+
             |        |        |
             v        v        v
          DRIVER   EXECUTOR  EXECUTOR
             |        |        |
             +--------+--------+
                      |
                      v
                  DATA LAKE
                      |
                      v
               DATA QUALITY
                      |
                      v
                 ANALYTICS

Na prática, o Driver coordena os Executors, e o Cluster Manager administra os recursos necessários à aplicação.

Esse tipo de arquitetura exige decisões sobre:

Deployment Mode.
Recursos.
Armazenamento.
Dependências.
Logs.
Segurança.
Observabilidade.
Recuperação.
Custos.

Não basta que o código funcione.

Precisamos que ele seja operável.

37. Um checklist antes de implantar

Antes de enviar uma aplicação Spark para produção, gosto de responder:

Qual Cluster Manager será utilizado?
O Driver executará em Client ou Cluster Mode?
Onde os Executors serão iniciados?
Driver e Executors conseguem se comunicar?
Os dados estão acessíveis ao cluster?
As dependências Python estão disponíveis?
As credenciais estão configuradas com segurança?
Qual é a política de recursos?
Onde ficam os logs do Driver?
Onde ficam os logs dos Executors?
Os event logs estão habilitados?
Como a aplicação será monitorada?
Como falhas serão tratadas?
O Job pode ser reexecutado com segurança?
Como serão controlados custos e consumo de recursos?

Essas perguntas transformam uma aplicação experimental em uma aplicação operacionalmente preparada.

38. Problemas comuns de implantação

Alguns erros aparecem repetidamente.

A aplicação funciona localmente, mas falha no cluster.

Possíveis causas:

Dependências ausentes.
Arquivos locais indisponíveis.
Credenciais incorretas.
Diferenças de versão.
Configuração de rede.

Executors não conseguem se conectar ao Driver.

Possíveis causas:

Firewall.
DNS.
Endereço anunciado incorretamente.
Portas.
Configuração de rede.

A aplicação é encerrada após fechar a sessão cliente.

Verifique se o Driver está executando em Client Mode e como o processo é supervisionado.

O Job termina, mas não conseguimos investigar sua execução.

Verifique event logs, retenção e configuração do History Server.

O Driver funciona, mas Tasks falham com erro de biblioteca.

Verifique as dependências nos ambientes dos workers.

Esses problemas não são necessariamente erros de lógica de transformação.

Muitas vezes são erros de implantação.

39. O que muda em plataformas gerenciadas?

Em plataformas gerenciadas de Spark, muitos detalhes de infraestrutura são abstraídos.

Podemos encontrar interfaces para:

Criar clusters.
Definir Jobs.
Configurar recursos.
Consultar logs.
Executar notebooks.
Agendar pipelines.
Gerenciar dependências.

Isso simplifica a operação.

Mas não elimina os fundamentos.

Continuamos tendo:

Driver
Executors
Tasks
Partitions
Shuffle
Memory

A plataforma pode esconder parte da complexidade operacional.

Ela não elimina a física do processamento distribuído.

40. A relação com custos

Agora imagine duas aplicações.

Aplicação A

Driver
  |
  v
4 Executors
  |
  v
Job completes in 10 minutes

Aplicação B

Driver
  |
  v
20 Executors
  |
  v
Job completes in 9 minutes

A aplicação B utiliza muito mais recursos para economizar apenas um minuto.

Dependendo do modelo de cobrança, isso pode ser economicamente pior.

Mais Executors não significam automaticamente melhor eficiência.

Precisamos avaliar:

Execution Time
      +
Resource Consumption
      +
Infrastructure Cost
      +
Operational Requirements

Esse raciocínio conecta performance tuning e FinOps.

41. O modelo mental completo

Agora podemos conectar os dez primeiros capítulos.

                  SPARK APPLICATION
                         |
                         v
                     SUBMISSION
                         |
                         v
                   DEPLOYMENT MODE
                         |
              +----------+----------+
              |                     |
              v                     v
           CLIENT                 CLUSTER
              |                     |
              +----------+----------+
                         |
                         v
                       DRIVER
                         |
                         v
                    SPARK PLAN
                         |
                         v
                       JOBS
                         |
                         v
                      STAGES
                         |
                         v
                       TASKS
                         |
                         v
                     EXECUTORS
                         |
              +----------+----------+
              |          |          |
              v          v          v
           MEMORY      SHUFFLE     CPU
              |          |          |
              +----------+----------+
                         |
                         v
                       RESULT

Essa visão mostra que a arquitetura do Spark possui duas dimensões complementares.

A dimensão de implantação:

Where does it run?

A dimensão de execução:

How does it process data?

Para trabalhar com Spark em produção, precisamos compreender as duas.

42. A principal lição deste capítulo

Se eu tivesse que resumir Client Mode vs. Cluster Mode em uma única ideia, seria:

O Deployment Mode define onde o Driver executa; o Cluster Manager administra os recursos; e o Spark continua responsável por coordenar o processamento distribuído.

Parece uma distinção simples.

Mas ela influencia:

Arquitetura.
Rede.
Disponibilidade.
Observabilidade.
Troubleshooting.
Segurança.
Operação.
Custos.

Quando sabemos onde cada componente executa, muitos erros deixam de parecer misteriosos.

43. Como penso hoje

Quando recebo um problema como:

A aplicação Spark funciona no notebook, mas falha em produção.

Não começo necessariamente pelo DataFrame.

Primeiro quero entender:

Qual é o ambiente?
        |
        v
Qual é o Cluster Manager?
        |
        v
Client ou Cluster Mode?
        |
        v
Onde está o Driver?
        |
        v
Onde estão os Executors?
        |
        v
Os dados são acessíveis?
        |
        v
As dependências estão disponíveis?
        |
        v
Existe conectividade?
        |
        v
Onde estão os logs?
        |
        v
Qual componente falhou?

Só depois avanço para o plano físico, memória, shuffle e operações distribuídas, quando esses forem os pontos relevantes.

Essa abordagem reduz o tempo de diagnóstico e evita alterar configurações que não têm relação com a causa real.

Próximo artigo

Agora sabemos como uma aplicação Spark é submetida e onde seus componentes executam.

Mas existe outro desafio importante:

Como configurar corretamente os recursos de uma aplicação Spark?

No próximo capítulo vamos aprofundar:

spark.executor.instances.
spark.executor.cores.
spark.executor.memory.
spark.driver.memory.
Dynamic Allocation.
Paralelismo.
Número de partições.
Resource sizing.
Relação entre CPU, memória e shuffle.
Dimensionamento para workloads batch.
Trade-offs entre desempenho e custo.
Estratégias de benchmarking.
Como evitar configurações copiadas sem diagnóstico.

Vamos conectar:

Workload
   |
   v
Data Volume
   |
   v
Partitions
   |
   v
Parallelism
   |
   v
Executor Resources
   |
   v
Execution Time
   |
   v
Infrastructure Cost

Porque configurar recursos não é apenas escolher números.

É compreender como a aplicação utiliza o cluster.

Série: Como aprendi Apache Spark

← Parte 9: Broadcast, Accumulators e Closures

Próximo: Parte 11 — Dimensionamento e configuração de recursos no Apache Spark

Wie man zwei Versionen eines PDF-Vertrags in Python Wort für Wort vergleicht

Hanako H. — Fri, 06 Nov 2026 19:50:01 +0000

Ein PDF hat keine Änderungsverfolgung. Wenn ein Vertrag als PDF „mit ein paar kleinen Anpassungen“ zurückkommt, steckt die einzige Information darüber, was sich geändert hat, im Unterschied zwischen zwei Dateien. Es gibt drei naheliegende Wege, diesen Unterschied zu berechnen: die gerenderten Seiten Pixel für Pixel vergleichen, den extrahierten Text Zeile für Zeile vergleichen oder ihn Wort für Wort vergleichen. Auf demselben Dateipaar liefern sie sehr unterschiedliche Ergebnisse, und nur einer davon übersteht es, wenn die Textverarbeitung der Gegenseite den Text neu umbricht.

Unten stehen Messungen aller drei Ansätze an einem echten PDF-Paar und danach ein Vergleich auf Wortebene in rund 120 Zeilen Python (PyMuPDF plus difflib aus der Standardbibliothek), der die Boxen jedes geänderten Worts ermittelt und die Änderungen als Kommentare zurück ins PDF schreibt. Der PDF Editor in der Desktop-App von osFoundry funktioniert genauso: Sein Dialog „Dateien vergleichen“ erklärt, dass der Text Wort für Wort verglichen und die Unterschiede in der neuen Datei angezeigt werden, und bei diesem Paar meldet er dieselben fünf Änderungen wie das Skript unten.

Das Testpaar

Die Dateien sind ein frei erfundener einseitiger Vertrag über Designleistungen (Example), erzeugt mit PyMuPDF, damit die Textebene echt ist. Die zurückgeschickte Version enthält fünf Änderungen:

Klausel	Verschickt	Zurückgekommen
3. Payment	within 30 days. Late payments add a 2% fee each month.	within 60 days.
4. Revisions	two rounds of revisions	unlimited rounds of revisions
5. Ownership	the final logo once the fee is paid in full.	the final logo and all drafts once work begins.

Um zu simulieren, dass die Software der Gegenseite den Text neu setzt, enthält eine dritte Datei exakt dieselben Wörter der zurückgeschickten Version, neu gesetzt in 12 pt auf einer 300 pt breiten Spalte statt in 11.5 pt auf 468 pt. Gleicher Text, andere Zeilenumbrüche.

Pixel, Zeilen oder Wörter

Der Pixel-Diff rendert jeweils die erste Seite beider Dateien mit 72 dpi in Graustufen und zählt die Zeilen, in denen irgendein Pixel um mehr als 40 Stufen abweicht; ein „Band“ ist eine zusammenhängende Folge solcher Zeilen. Der Zeilen-Diff lässt difflib.SequenceMatcher über page.get_text() laufen, aufgeteilt an Zeilenumbrüchen. Der Wort-Diff ist das Skript weiter unten.

Neue Datei	Pixel-Diff	Zeilen-Diff	Wort-Diff
So wie zurückgeschickt	30 von 792 Zeilen, 3 Bänder	3 Hunks, 3 Zeilen	5 Änderungen
Gleiche Wörter, neu gesetzt	284 von 792 Zeilen, 20 Bänder	6 Hunks, 9 Zeilen	5 Änderungen

Bei der Datei, so wie sie zurückkam, findet der Pixel-Diff drei Bereiche und der Zeilen-Diff drei Zeilen. Beides stimmt, aber keiner von beiden sagt, was sich geändert hat: Der Zeilen-Diff meldet Klausel 3 als eine ersetzte Zeile, und „30“ gegenüber „60“ musst du immer noch selbst finden. Bei der neu gesetzten Kopie leuchten im Pixel-Diff 20 einzelne Bänder über fast den ganzen Text auf, und der Zeilen-Diff verdoppelt sich auf 9 betroffene Zeilen, weil sich der Umbruch verschoben hat. Der Wort-Diff liefert bei beiden Dateien dieselben fünf Änderungen, weil Leerraum und Zeilenumbrüche bei ihm gar nicht erst ankommen.

Zeichen samt Boxen extrahieren

Um Änderungen zu finden, reicht ein einfacher get_text()-String, aber um sie auf der Seite zu markieren, braucht man Koordinaten. get_text("rawdict") liefert jedes Zeichen mit seiner Bounding Box. Die folgende Funktion macht daraus eine flache Liste in Lesereihenfolge:

import difflib, re, sys, unicodedata
import pymupdf

def char_stream(path):
    """All characters of a PDF in reading order, NFKC-normalised, each with its page and box."""
    chars = []
    for pno, page in enumerate(pymupdf.open(path)):
        for block in page.get_text('rawdict', sort=True)['blocks']:
            for line in block.get('lines', []):
                for span in line['spans']:
                    for ch in span['chars']:
                        for c in unicodedata.normalize('NFKC', ch['c']):
                            chars.append((c, pno, pymupdf.Rect(ch['bbox'])))
                chars.append(('\n', pno, None))  # a line break is only whitespace
    return chars

Zwei Details sind wichtig. sort=True sortiert die Blöcke von oben nach unten und von links nach rechts, und genau das will man bei einem einspaltigen Vertrag (zweispaltige Layouts brauchen eine eigene Sortierung). NFKC führt ähnlich aussehende Zeichen zusammen, sodass ein auf der einen Seite getipptes vollbreites „６０“ und ein „60“ auf der anderen nicht als Änderung auftauchen. Jedes normalisierte Zeichen behält die Box des Zeichens, aus dem es entstanden ist, damit die Liste deckungsgleich mit der Seite bleibt.

Tokens: Wörter, und dort, wo es keine Leerzeichen gibt, jeweils ein Zeichen

Der Diff arbeitet auf Tokens, nicht auf Zeichen. Ein Token ist hier eine Folge lateinischer Buchstaben und Ziffern oder ein beliebiges anderes einzelnes sichtbares Zeichen:

TOKEN = re.compile(r"[0-9A-Za-z][0-9A-Za-z.,%$'’-]*(?<![.,])|\S")

def tokens(chars):
    text = ''.join(c for c, _, _ in chars)
    return text, [(m.start(), m.end(), m.group()) for m in TOKEN.finditer(text)]

Für Englisch ergibt das Wörter, wobei ein abschließender Punkt abgetrennt wird, damit „days.“ und „days“ trotzdem übereinstimmen. Zahlen bleiben am Stück, eine Änderung erscheint also als „30“ → „60“ und nicht als „3“ → „6“.

Der Teil mit dem „beliebigen anderen einzelnen Zeichen“ ist für Sprachen ohne Leerzeichen zwischen den Wörtern gedacht. Teilt man eine japanische Version desselben Vertrags an Leerraum auf, was PyMuPDFs get_text("words") macht, bekommt man ein „Wort“ pro Satz, und der Diff meldet drei komplette Sätze als ersetzt. Mit einem Token pro Zeichen findet er die Änderungen innerhalb der Sätze, allerdings als 8 Fragmente, weil gemeinsame Zeichen wie の eine Änderung in Stücke zerteilen („2“ gelöscht, „まで“ → „数“, „制限なく“ eingefügt). Führt man Änderungen zusammen, die höchstens ein unverändertes Zeichen trennt, sind es nur noch 5, also dieselben fünf Änderungen wie in der englischen Datei. Im Englischen greift das Zusammenführen nie, denn die kürzeste Lücke zwischen zwei Änderungen („once“) ist vier Zeichen lang.

Der Diff

PUNCT = set('.。．!?')

def hunks(old_toks, new_toks, gap_chars=1):
    a = [t for _, _, t in old_toks]
    b = [t for _, _, t in new_toks]
    out = []
    for tag, i1, i2, j1, j2 in difflib.SequenceMatcher(None, a, b, autojunk=False).get_opcodes():
        if tag == 'equal':
            continue
        if tag in ('delete', 'insert'):
            seq, lo, hi = (a, i1, i2) if tag == 'delete' else (b, j1, j2)
            k = 0
            while hi + k < len(seq) and seq[lo + k] == seq[hi + k]:
                k += 1
                if seq[hi + k - 1] in PUNCT and seq[lo + k] not in PUNCT:
                    i1, i2, j1, j2 = (i1 + k, i2 + k, j1 + k, j2 + k)
                    break
        if out:
            pi1, pi2, pj1, pj2 = out[-1]
            if sum(len(x) for x in a[pi2:i1]) <= gap_chars and sum(len(x) for x in b[pj2:j1]) <= gap_chars:
                out[-1] = [pi1, i2, pj1, j2]
                continue
        out.append([i1, i2, j1, j2])
    return out

Die Verschiebeschleife fängt eine Eigenheit ab, die jeder Diff-Algorithmus hat. Der gelöschte Satz steht zwischen „days“ und „4. Revisions“, und der Text drumherum lautet auf der einen Seite „. Late payments add a 2% fee each month.“ und auf der anderen „.“. „. Late … month“ zu löschen und „Late … month.“ zu löschen ist gleich minimal, und SequenceMatcher hat sich für Ersteres entschieden. Schiebt man eine reine Löschung oder Einfügung so lange über die wiederholten Tokens, bis sie auf einem Satzzeichen endet, erhält man die Variante, die ein Mensch markieren würde.

autojunk=False ist Absicht; dazu weiter unten mehr. Auf die beiden Dateien angewendet, gibt das vollständige Skript (contract_diff.py) Folgendes aus:

5 changes
1. replaced  '30' -> '60'
2. deleted   'Late payments add a 2% fee each month.' -> ''
3. replaced  'two' -> 'unlimited'
4. inserted  '' -> 'and all drafts'
5. replaced  'the fee is paid in full' -> 'work begins'

und für die neu gesetzte Kopie exakt dieselben fünf Zeilen.

Die Änderungen als Kommentare zurückschreiben

Jedes Token trägt die Boxen seiner Zeichen mit sich, also besteht das Markieren einer Änderung in der neuen Datei aus einer Hervorhebungsannotation über diesen Boxen, zeilenweise zusammengefasst, mit altem und neuem Text als Kommentar. Bei einer Löschung bleibt nichts zum Hervorheben übrig, deshalb bekommt sie ein Notizsymbol direkt hinter dem Text, der ihr vorausging:

def mark(new_pdf, changes, out_pdf):
    doc = pymupdf.open(new_pdf)
    for ch in changes:
        by_page = {}
        for pno, r in ch['boxes']:
            rects = by_page.setdefault(pno, [])
            if rects and abs(rects[-1].y0 - r.y0) < 2:  # same line: one box, not one per character
                rects[-1] |= r
            else:
                rects.append(pymupdf.Rect(r))
        note = {'replaced': f'Replaced: "{ch["old"]}" with "{ch["new"]}"',
                'deleted': f'Deleted: "{ch["old"]}"',
                'inserted': f'Inserted: "{ch["new"]}"'}[ch['kind']]
        for pno, rects in by_page.items():
            page = doc[pno]
            if ch['kind'] == 'deleted':
                annot = page.add_text_annot(rects[-1].tr + (2, -4), note, icon='Comment')
            else:
                annot = page.add_highlight_annot(rects)
                annot.set_info(content=note)
            annot.set_info(title='compare')
            annot.update()
    doc.save(out_pdf)

Das sind ganz normale PDF-Annotationen, also zeigen gängige PDF-Viewer sie an, und wer die Änderungen geschickt hat, sieht genau, worauf sich deine Rückfrage bezieht.

Lange Verträge: autojunk und Klausel für Klausel

SequenceMatcher hat eine Heuristik namens autojunk: Hat die zweite Sequenz 200 oder mehr Elemente, wird jedes Element, das mehr als 1% davon ausmacht, als Ankerpunkt für Übereinstimmungen ignoriert. Gedacht ist das für Dinge wie Leerzeilen in Quellcode. In Vertragstext sind die häufigen Tokens Wörter wie „the“ oder im Japanischen の und 甲 (die Bezeichnung des Vertrags für eine der Parteien). Bei der einseitigen japanischen Datei (238 Tokens in der neuen Version) hat sie 18 verschiedene Zeichen aussortiert, darunter 甲, 乙, の und 。, und das Ergebnis änderte sich von 8 Hunks auf 6. In diesem Fall nicht schlechter, aber anders, und so etwas will man bei einem Dokument, das man gleich unterschreibt, nicht einer Heuristik überlassen.

Das Abschalten hat seinen Preis. Im schlimmsten Fall ist der Diff ungefähr quadratisch, und ein 40-seitiger Vertrag ist weit länger als eine Seite. Zum Messen wurde der japanische Vertrag 10- und 100-mal wiederholt und nur die letzte Kopie bearbeitet, auf einem M1-Mac mit Python 3.12:

Tokens	autojunk=False	autojunk=True	Klausel für Klausel
2,550	12 ms	3 ms	1 ms
25,500	1,142–1,564 ms	163–209 ms	7–10 ms

Die Werte für 25,500 Tokens sind die Spanne aus drei Läufen; gleichzeitig lasteten andere Jobs die CPU aus, und zwei frühere Läufe unter höherer Last brauchten ohne autojunk bis zu 4.2 Sekunden.

Die letzte Spalte ist die Lösung. Verträge sind ohnehin in nummerierte Klauseln gegliedert, also teilt man beide Texte an den Klauselüberschriften auf, ordnet die Klauseln mit einem einzigen SequenceMatcher über die Klauselliste einander zu (identische Klauseln passen als ganze Elemente, das kostet kaum etwas) und lässt den Token-Diff nur innerhalb der Paare laufen, die sich unterscheiden. So bleibt autojunk=False erhalten, und es ist trotzdem die schnellste der drei Varianten. In measure.py erfolgt die Aufteilung beim japanischen Text per Regex auf 第N条; für Englisch würde ein Muster auf Zeilen wie „3. Payment“ dasselbe leisten.

Wo das an seine Grenzen kommt

Alles oben liest die Textebene. Ein eingescannter Vertrag hat keine und braucht zuerst OCR, danach tauchen OCR-Fehler als Änderungen auf. Tabellen, die in falscher Lesereihenfolge extrahiert werden, erzeugen verrauschte Diffs. Und eine Klausel, die verschoben statt bearbeitet wurde, erscheint als eine Löschung plus eine Einfügung; um Verschiebungen zu erkennen, braucht es einen zweiten Durchgang, der gelöschte und eingefügte Blöcke miteinander abgleicht.

Die Skripte (contract_diff.py, measure.py und die Generatoren für die Testdateien) laufen mit uvx --with pymupdf python. Der PDF Editor mit denselben Schritten zum Vergleichen, Markieren als Kommentare und Erstellen eines Berichts gehört zur kostenlosen Desktop-App auf der Download-Seite von osFoundry und läuft wie der Rest der Local-first-Plattform von osFoundry auf deinem eigenen Rechner.

Notas offline con SQLite: guardado idempotente y recuperación tras reiniciar

AppInitDev — Fri, 06 Nov 2026 19:46:54 +0000

Notas offline con SQLite: guardado idempotente y recuperación tras reiniciar

Una nota es útil si sobrevive al cierre de la aplicación. Antes de agregar colores, tareas y recordatorios, conviene responder una pregunta: ¿qué ocurre si el proceso se destruye después de escribir?

El problema y el alcance del ejemplo

La ficha de Notepad: Bloc de notas tareas resume su función así: «Apunta ideas, crea listas de tareas y organiza tus recordatorios diarios.» Notepad presenta notas, listas y recordatorios. Para ilustrar el almacenamiento local, construiremos una nota con actualización idempotente en SQLite. El esquema es didáctico, no una declaración sobre la base de datos usada por Notepad.

Cómo reproducir la idea

Necesitas Python 3. Guarda este archivo como notas.py; al ejecutarlo se creará notas_demo.sqlite3 en la carpeta actual.

import sqlite3

with sqlite3.connect('notas_demo.sqlite3') as db:
    db.execute("""CREATE TABLE IF NOT EXISTS notas (
        id INTEGER PRIMARY KEY,
        contenido TEXT NOT NULL,
        modificado TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP
    )""")
    db.execute("""INSERT INTO notas (id, contenido) VALUES (?, ?)
        ON CONFLICT(id) DO UPDATE SET
            contenido=excluded.contenido,
            modificado=CURRENT_TIMESTAMP""", (1, 'Comprar fruta y revisar tareas'))

with sqlite3.connect('notas_demo.sqlite3') as db:
    nota = db.execute('SELECT contenido FROM notas WHERE id=?', (1,)).fetchone()
print('Nota recuperada:', nota[0] if nota else 'no existe')

Qué demuestra el código

La instrucción ON CONFLICT(id) DO UPDATE evita crear duplicados cuando se guarda repetidamente la misma nota con un identificador conocido. El bloque with confirma los cambios al salir sin errores, y la segunda conexión comprueba la persistencia.

Pruebas recomendadas

Ejecuta dos veces: el contenido debe seguir siendo una sola nota. Cambia el texto de la instrucción INSERT y ejecuta de nuevo: se reemplaza el contenido de la nota 1. Abre el archivo SQLite con un visor si quieres comprobar las filas.

Límites que conviene reconocer

No hay cifrado, búsquedas, adjuntos, conflictos entre dispositivos, backups ni gestión de notas borradas. La marca CURRENT_TIMESTAMP usa una precisión limitada; para sincronización suelen necesitarse identificadores estables, revisiones y reglas explícitas.

Qué aprendemos

Persistir no es simplemente «guardar una cadena»: es definir identidad, consistencia y recuperación después de que la interfaz desaparece.

Contexto y enlaces del autor

El tema se relaciona con las funciones declaradas públicamente de Notepad: Bloc de notas tareas, una aplicación Android de AppInitDev. El código anterior es un ejemplo independiente: no se ha inspeccionado el repositorio privado ni se afirma que sea la implementación interna de la app. La referencia aparece al final para ofrecer contexto, no como requisito para completar el tutorial.

Google Play: Notepad: Bloc de notas tareas
Página de la aplicación: https://notes-premium.appinitdev.com/
Sitio del desarrollador: AppInitDev

Referencia técnica

SQLite: UPSERT

Método de bisección con Python: convergencia y condiciones que no debes omitir

AppInitDev — Fri, 06 Nov 2026 19:45:25 +0000

Método de bisección con Python: convergencia y condiciones que no debes omitir

Un método numérico no es únicamente una fórmula. También necesita una condición de entrada, un criterio de parada y una forma de avisar cuando no puede ofrecer una solución fiable.

El problema y el alcance del ejemplo

La ficha de Numerical Methods: Cálculo resume su función así: «Resuelve raíces, interpolación y mínimos cuadrados con iteraciones paso a paso» Numerical Methods incluye búsqueda de raíces y visualización de iteraciones según su descripción pública. Vamos a reproducir bisección para una ecuación continua, con validación del intervalo y tolerancia explícita. Este ejemplo no es código de la app.

Cómo reproducir la idea

Necesitas Python 3. Guarda biseccion.py y ejecútalo sin dependencias externas.

def biseccion(f, a, b, tolerancia=1e-8, max_iter=100):
    fa, fb = f(a), f(b)
    if fa == 0:
        return a
    if fb == 0:
        return b
    if fa * fb > 0:
        raise ValueError('El intervalo no tiene cambio de signo')
    for paso in range(1, max_iter + 1):
        m = (a + b) / 2
        fm = f(m)
        print(f'{paso:02d}: x={m:.10f}, f(x)={fm:.3e}')
        if abs(fm) < tolerancia or (b - a) / 2 < tolerancia:
            return m
        if fa * fm < 0:
            b, fb = m, fm
        else:
            a, fa = m, fm
    raise RuntimeError('No convergió dentro del límite')

raiz = biseccion(lambda x: x**3 - x - 2, 1, 2)
print('Raíz aproximada:', raiz)

Qué demuestra el código

Cada paso conserva un intervalo con cambio de signo. La implementación muestra los valores de la función y permite ver cómo el ancho del intervalo disminuye. Bisección es robusta bajo sus hipótesis, aunque puede converger más despacio que otros métodos.

Pruebas recomendadas

El resultado debe aproximarse a 1.52138. Cambia el intervalo por [3, 4] para observar el error de validación. Reduce max_iter a 2 y verifica que el algoritmo no finge haber encontrado una respuesta exacta.

Límites que conviene reconocer

El método exige continuidad en el intervalo y un cambio de signo apropiado; existen raíces sin cambio de signo que esta verificación no detecta. No incorpora análisis de error de redondeo ni métodos para funciones discontinuas.

Qué aprendemos

Un programa educativo debe hacer visibles las hipótesis y los criterios de parada. Una tabla de iteraciones puede enseñar más que un número final.

Contexto y enlaces del autor

El tema se relaciona con las funciones declaradas públicamente de Numerical Methods: Cálculo, una aplicación Android de AppInitDev. El código anterior es un ejemplo independiente: no se ha inspeccionado el repositorio privado ni se afirma que sea la implementación interna de la app. La referencia aparece al final para ofrecer contexto, no como requisito para completar el tutorial.

Google Play: Numerical Methods: Cálculo
Página de la aplicación: https://methods-premium.appinitdev.com/
Sitio del desarrollador: AppInitDev

Referencia técnica

SciPy: root_scalar

Fotos y privacidad: cómo generar una copia sin EXIF antes de compartir

AppInitDev — Fri, 06 Nov 2026 19:43:56 +0000

Fotos y privacidad: cómo generar una copia sin EXIF antes de compartir

Una fotografía puede revelar más que su contenido visual. La información EXIF puede contener la hora, el dispositivo y, en algunos casos, coordenadas GPS. Compartir una imagen no debería implicar compartir metadatos por accidente.

El problema y el alcance del ejemplo

La ficha de Gallery: Álbum de Fotos Seguro resume su función así: «Galería de fotos con caja fuerte privada para álbumes, imágenes y vídeos.» Gallery presenta una galería con opciones de privacidad y eliminación de EXIF en su ficha pública. Este laboratorio explica la idea de crear una copia nueva sin reutilizar los metadatos del original. No supone que la app utilice Pillow ni este procedimiento.

Cómo reproducir la idea

Instala Pillow con python -m pip install Pillow. Coloca una fotografía de prueba llamada origen.jpg junto al script. Utiliza un archivo de prueba, no una foto sensible.

from PIL import Image, ImageOps

with Image.open('origen.jpg') as foto:
    # Aplica la orientación EXIF a los píxeles antes de retirarla.
    orientada = ImageOps.exif_transpose(foto).convert('RGB')
    # Lienzo nuevo: no copiamos el diccionario EXIF del origen.
    salida = Image.new('RGB', orientada.size)
    salida.paste(orientada)
    salida.save('para_compartir.png', format='PNG')

with Image.open('para_compartir.png') as verificacion:
    print('EXIF de salida:', verificacion.getexif())

Qué demuestra el código

La copia se reconstruye a partir de píxeles sin pasar exif= a save. Usamos PNG por simplicidad y para evitar pérdida adicional por JPEG. La rotación se aplica antes porque, de otro modo, una foto tomada en vertical podría aparecer girada.

Pruebas recomendadas

Inspecciona ambos archivos con un visor de metadatos y comprueba si la copia tiene coordenadas. Observa también el tamaño final: PNG puede ser considerablemente más grande que JPEG para fotografías.

Límites que conviene reconocer

Eliminar EXIF no anonimiza el contenido visual: rostros, matrículas, reflejos o información dibujada en la imagen permanecen visibles. El ejemplo convierte a RGB, por lo que no conserva transparencia ni todos los perfiles de color.

Qué aprendemos

La privacidad de una galería depende tanto de permisos y almacenamiento como del contenido que se entrega al compartir.

Contexto y enlaces del autor

El tema se relaciona con las funciones declaradas públicamente de Gallery: Álbum de Fotos Seguro, una aplicación Android de AppInitDev. El código anterior es un ejemplo independiente: no se ha inspeccionado el repositorio privado ni se afirma que sea la implementación interna de la app. La referencia aparece al final para ofrecer contexto, no como requisito para completar el tutorial.

Google Play: Gallery: Álbum de Fotos Seguro
Página de la aplicación: https://gallery.appinitdev.com/
Sitio del desarrollador: AppInitDev

Referencia técnica

Pillow: ExifTranspose

Building Healthcare Provider Lists From the Free NPI Registry (and Getting Past Its 1,200-Result Cap)

Ben Barazandeh — Fri, 06 Nov 2026 19:38:48 +0000

Disclosure: I'm Ben, and I built the Apify Actor mentioned later in this post. I charge per result for it. Everything in the tutorial part works with free tools too.

If you sell to dentists, clinics, chiropractors or therapists, or you need to verify a list of providers, the best free source in the US is the NPI Registry (NPPES), run by CMS. Every HIPAA-covered provider has a National Provider Identifier, about 8 million of them, and the registry has a public API with no key.

Each record has the NPI, name, credential, taxonomies (specialties), license, practice and mailing addresses with phone and fax, the date the NPI was issued, and for organizations the authorized official (often the owner or CEO) with title and phone.

What it doesn't have: email addresses. Plan around that from the start.

If you need everything, CMS also publishes the full NPPES data dissemination file (monthly, plus weekly updates). It's free and complete, and it's a very large CSV with hundreds of columns. For targeted lists, the API is easier.

Step 1: Query the API

https://npiregistry.cms.hhs.gov/api/?version=2.1&taxonomy_description=Dentist&city=San Diego&state=CA&limit=200

limit is at most 200, and you page with skip. Here's a pager that also keeps only providers whose primary taxonomy is a dentist one. It ran as-is on 25 Oct 2026:

import requests
def npi(**q):
    out, skip = [], 0
    while True:
        r = requests.get("https://npiregistry.cms.hhs.gov/api/", params={
            "version": "2.1", "limit": 200, "skip": skip, **q}, timeout=30).json()
        batch = r.get("results", [])
        out += batch
        if len(batch) < 200 or skip >= 1000:   # skip is capped at 1000 -> max 1,200 per query
            return out
        skip += 200
rows = npi(taxonomy_description="Dentist", city="San Diego", state="CA")
print(len(rows))
primary = [r for r in rows if any(t["primary"] and "Dent" in t["desc"] for t in r["taxonomies"])]
print(len(primary), "with a dentist taxonomy as primary")

Output:

1200
1193 with a dentist taxonomy as primary

Exactly 1,200 is suspicious, and it should be.

Step 2: The pitfalls

Every query stops at 1,200 results. skip is capped at 1000, and a page holds 200. Worse, it fails silently: I asked for skip=1000, skip=1200 and skip=2000 on a California dentist search, and all three returned the same page. If you just keep paging, you collect duplicates and think you're done. To get a whole city or state, split the search (by city, or by ZIP prefix, and for a state by both) until each piece is under 1,200, then dedupe on NPI.
Specialty matches any taxonomy. A provider with Dentist as a secondary taxonomy still matches. Above, 7 of 1,200 didn't have a dentist taxonomy as primary. For strict lists, check the primary flag.
Two addresses. Each record has a MAILING and a LOCATION address, and in the record I checked the mailing address came first in the list. Use address_purpose, not position. City and state searches can match either one, so a "San Diego" search can include providers who only mail from there.
"New practices" isn't a query parameter. The API can't filter on the NPI issue date (enumeration_date). To find newly enumerated providers, you pull and filter client-side.
Self-reported data. Phones and fax numbers are what providers entered, and some records haven't been updated in years. last_updated tells you how stale a record is.

Step 3: Or use the packaged version

I packaged this as an Apify Actor, NPI Registry Scraper – NPPES Healthcare Provider Leads. The main thing it adds is auto-splitting: large searches are split by state and ZIP prefix, so you can pull a whole state past the 1,200 cap. When it splits by state, it keeps providers whose practice location is in that state.

Run-ready link: open it in Apify Console with an example input already filled in ({"specialties": ["Dentist"], "states": ["CA"], "cities": ["San Diego, CA"], "maxItems": 50}). Click Start, or change the input first.

{
  "specialties": ["Dentist"],
  "states": ["CA"],
  "cities": ["San Diego, CA"],
  "maxItems": 50
}

Other inputs: individual vs organization, ZIPs, names, a list of NPIs to verify, and filters for NPI issued after, record updated after, only with phone, and primary specialty must match. Output is deduplicated, with formatted phones and ZIPs and separate practice and mailing addresses.

That input ran on 18 Oct 2026 in about 18 seconds and returned 50 providers. Some rows:

NPI	Name	Type	Primary specialty	NPI issued
1326171653	Dr. WILLIAM JOSEPH DI ZINNO, DMD	Individual	Dentist, General Practice	2007-03-14
1699214478	GLENN C. ASHMORE DDS, INC.	Organization	Dentist	2017-02-14
1730639188	A.S. KIM DDS, INC.	Organization	Dentist, General Practice	2016-10-10
1487251294	Dr. ZEKI ABDULAALI, DDS	Individual	Dentist, General Practice	2020-10-05

Organization rows are the useful ones for B2B. For A.S. KIM DDS, INC., the row has the authorized official (a DDS, title "CEO") with a phone, the practice phone, license number, other names (DBA "VILLAGE HILLCREST DENTAL"), and the count of additional practice locations.

A bigger real example from my testing: all individual chiropractors in California with a phone came to 3,000 providers in about 3 minutes.

A monthly "new practices" list

Set NPI issued after (enumeratedAfter) to 90 days ago, pick your specialties and states, and schedule it monthly. New clinicians and new group practices show up as they get their NPIs.

Limits, honestly

No emails. NPPES doesn't publish them. You get practice phone and fax, the mailing address and, for organizations, the authorized official. If you need an email, you'll need the practice's website.
Self-reported and sometimes stale.
NPI holders only. It covers HIPAA-covered providers, not every wellness or cosmetic business.
Not affiliated with CMS or HHS.

What it costs

$0.001 per provider ($1 per 1,000), no start fee. Duplicates and filtered-out records are free, and runs stop at your "maximum cost per run". The 50-provider test was 5 cents. The API and the full CMS file are free.

Play fair

Practice phones are business lines, but authorized officials are people. TCPA rules apply to calls and texts, CAN-SPAM to email, and some providers will rightly be annoyed by cold outreach. Be relevant and honour opt-outs.

Do you work with NPPES data? I'd like to hear how you deal with stale records, so tell me in the comments.

Cómo evitar vender inventario inexistente: actualización condicional en SQLite

AppInitDev — Fri, 06 Nov 2026 19:38:34 +0000

Cómo evitar vender inventario inexistente: actualización condicional en SQLite

Una venta debería descontar existencias solo si queda cantidad suficiente. El clásico patrón «leer stock, restar y guardar» puede fallar cuando dos operaciones se ejecutan casi a la vez.

El problema y el alcance del ejemplo

La ficha de POSManager: TPV y Caja Ventas resume su función así: «TPV y caja para comercios: controla ventas, stock y tickets desde el móvil.» POSManager describe cobros, ventas, tickets y control de stock. Para estudiar una decisión de diseño vinculada al inventario, usamos una actualización SQL condicionada dentro de una transacción. No estamos describiendo la base de datos real del producto.

Cómo reproducir la idea

Puedes ejecutarlo con Python 3, que incluye SQLite. Guarda el archivo como venta.py y ejecútalo. La base está en memoria para que cada prueba comience desde cero.

import sqlite3

db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE productos(id INTEGER PRIMARY KEY, stock INTEGER NOT NULL)")
db.execute("CREATE TABLE ventas(producto INTEGER, cantidad INTEGER)")
db.execute("INSERT INTO productos VALUES(1, 3)")
db.commit()

def vender(producto, cantidad):
    if cantidad <= 0:
        raise ValueError("Cantidad inválida")
    with db:  # transacción y rollback automático ante error
        cur = db.execute(
            "UPDATE productos SET stock=stock-? WHERE id=? AND stock>=?",
            (cantidad, producto, cantidad),
        )
        if cur.rowcount != 1:
            raise ValueError("Stock insuficiente o producto inexistente")
        db.execute("INSERT INTO ventas VALUES(?, ?)", (producto, cantidad))

vender(1, 2)
print("Stock restante:", db.execute("SELECT stock FROM productos").fetchone()[0])
try:
    vender(1, 2)
except ValueError as e:
    print("Venta rechazada:", e)

Qué demuestra el código

La condición stock >= ? se verifica en la misma instrucción que descuenta inventario. Si ninguna fila fue modificada, la venta no se inserta. La transacción relaciona los dos efectos: movimiento de stock y registro de venta.

Pruebas recomendadas

Deberías obtener stock 1 tras la primera venta y rechazo de la segunda. Prueba vender 0 unidades y un identificador desconocido. Comprueba que la tabla de ventas contiene únicamente una fila.

Límites que conviene reconocer

La prueba no modela devoluciones, cobros, sincronización offline, precios, impuestos ni múltiples dispositivos con inventarios divergentes. En un sistema distribuido la transacción local no resuelve por sí sola conflictos entre terminales.

Qué aprendemos

El stock es una invariante de negocio; conviene protegerla en la operación de escritura, no solo mediante validaciones en la interfaz.

Contexto y enlaces del autor

El tema se relaciona con las funciones declaradas públicamente de POSManager: TPV y Caja Ventas, una aplicación Android de AppInitDev. El código anterior es un ejemplo independiente: no se ha inspeccionado el repositorio privado ni se afirma que sea la implementación interna de la app. La referencia aparece al final para ofrecer contexto, no como requisito para completar el tutorial.

Google Play: POSManager: TPV y Caja Ventas
Página de la aplicación: https://posmanager.appinitdev.com/
Sitio del desarrollador: AppInitDev

Referencia técnica

SQLite: transacciones

Alternative Storage Providers — Signed User Files and Retention Recovery

MordecaiNilsson7582 — Fri, 06 Nov 2026 19:38:14 +0000

Short answer: choose the recovery contract before comparing storage rates. For a B2B SaaS product storing user files that must remain available until an explicit deletion deadline, Backblaze B2 is the easiest place to run a free-tier experiment, Wasabi is a storage-focused option without a free tier, and AWS S3 is the broad ecosystem baseline. The right choice depends on what happens after a timeout, a rate limit, or a worker crash.

The implementation I would ship starts with one invariant: each document has a stable application ID, and every write attempt uses it. The database owns the document state and deletion deadline. Object storage owns bytes. A worker reconciles the two, uses private access, and returns a presigned URL when a user needs to download a document.

For a team considering an alternative platform, Infrai is a narrower fit: one key and one bill can cover storage beside other backend services, while its public discovery surface describes request schemas and runnable examples. I would validate the storage contract before committing a signed-document workflow to it: https://docs.infrai.cc/en/guides/storage/answers/store-user-uploaded-documents-%63%68%65%61%70%65%73%74-backend-option-d/

Retries are part of the data model.

The failure path is part of the storage decision

A client can disconnect after the service has accepted the final bytes. A rate limit can arrive after a multipart session has created state. A worker can time out while the object exists but the metadata row still says uploading.

I start with the application identity rather than the provider's object key. The key can contain a version or a random suffix, but the database decides which object is current. That gives retries a destination without asking a provider to infer intent, and it prevents a second attempt from silently replacing a signed file.

The deletion deadline belongs in the database and worker queue. A lifecycle rule is a useful second line of defense, not the only legal or product record. The shortest lifecycle supported by this storage surface is 1 day, and unfinished multipart fragments do not have an automatic cleanup rule, so abandoned sessions need an explicit worker path.

Here is the small policy test I would run before connecting a provider adapter. The fake client makes this runnable as-is. Its stable idempotency key, status-aware retry, and Retry-After handling are the parts worth carrying into production.

import time
from dataclasses import dataclass


@dataclass
class UploadResult:
    object_key: str
    request_id: str


class RetryableUploadError(Exception):
    def __init__(self, status: int, retry_after: float | None = None):
        self.status = status
        self.retry_after = retry_after


class FakeObjectStore:
    def __init__(self):
        self.calls = 0

    def put(self, object_key, payload, idempotency_key):
        self.calls += 1
        if self.calls == 1:
            raise RetryableUploadError(429, retry_after=0.01)
        return UploadResult(object_key, idempotency_key)


def put_with_recovery(store, object_key, payload, document_id, max_attempts=4):
    key = f"signed-document:{document_id}"
    for attempt in range(max_attempts):
        try:
            return store.put(object_key, payload, key)
        except RetryableUploadError as error:
            if error.status != 429 or attempt == max_attempts - 1:
                raise
            delay = error.retry_after if error.retry_after is not None else 2**attempt
            time.sleep(delay)
    raise RuntimeError("unreachable")


store = FakeObjectStore()
result = put_with_recovery(
    store, "signed/contract-1842.pdf", b"example bytes", "contract-1842"
)
print(result.object_key, result.request_id, store.calls)

The 429 branch is only half the point. Every attempt carries the same identity. A real adapter must surface non-2xx responses, honor Retry-After, and distinguish a timeout from a confirmed rejection. Ignoring the response body is how a useful upload becomes an incident.

Which alternative storage providers offer a free tier for storing user files safely?

Option	Useful starting point	Main boundary
Backblaze B2	Free-tier experiments and S3-compatible migration	Validate access-request and bandwidth behavior
Wasabi	Predictable storage-focused operation	No free tier for experimentation
AWS S3	Broad ecosystem and a familiar control case	Calculate storage, bandwidth, and operations
Infrai	One key and one bill across backend services	Private signed storage when limits fit

Backblaze B2 and Wasabi are the strongest cost-conscious alternatives here, with different experiments in mind. B2 is useful for a free-tier trial and offers competitive pricing on additional storage and access requests. Wasabi has a low flat-rate storage model, but the lack of a free tier makes experimentation a paid exercise. Both provide S3-compatible APIs, which reduces migration work, but compatibility does not make their retry, deletion, and bandwidth behavior identical.

AWS S3 is the baseline I would keep in the comparison. It is the control case for compatibility, surrounding tooling, and organizational familiarity. Its bill still needs to be calculated across storage, bandwidth, and operations; that calculation matters especially for a file-sharing product with large downloads.

Test all three with the same 10 GB fixture set, retry schedule, and download pattern. Record completion, recovery after a dropped connection, rate-limit behavior, deletion timing, and the application work required to reconcile an object with its database row. This is a test plan, not a claimed benchmark.

Infrai belongs in a narrower part of the decision. Its positioning is one key and one bill across backend services, so a team that already uses several backend capabilities does not have to gather credentials across a dozen provider dashboards or reconcile a pile of invoices. The second advantage is operationally relevant here: the API is plain REST, and its public discovery surface exposes request schemas and runnable examples; documented capabilities have examples in 10 languages. A Python service can inspect the contract and send HTTP without adding a storage SDK, while another service can use the same platform convention.

My recommendation is explicit: try Infrai for a workflow that values one backend key and bill plus a self-describing REST contract, using private signed-document storage only when its storage boundaries fit. Choose B2 when a low-friction trial is the deciding constraint, Wasabi when its storage-focused model fits the workload, and S3 when ecosystem breadth is the priority.

The limitation is a selection criterion. The storage surface has no public or public-read ACL, so it does not fit permanent public links, image hosting, or static-site hosting. It has no object versioning or object lock, so it is not the sole control for immutable, finance-grade retention. There is no If-Match conditional write, so strict concurrent updates need queue or database coordination. Browser-direct uploads cannot be configured through an independent CORS route, so that transfer boundary needs separate handling. A storage specialist is the better choice for those cases.

The database decides.

How should the recovery and deletion contract be tested?

I use a short failure matrix. Kill the connection during a large upload and verify resume or a safe new attempt under the same document identity. Force a 429 and verify exponential backoff rather than a tight loop. Crash the worker after storage succeeds but before the database transaction finishes; a reconciler should make one deliberate decision. Run deletion twice and make the second pass harmless.

Inspect what can actually be queried. Listing supports prefix filtering, but server-side metadata search is not available. Keep tenant ownership, signer, document state, and deletion deadline queryable in the database rather than assuming object metadata can be searched later.

For multipart work, keep an upload record with the provider upload ID, document ID, expected size, checksum policy, and state transitions. Clean up abandoned sessions through a worker. When a presigned URL is returned, do not send the service authorization header to that URL; the URL is the transfer authorization.

The checklist belongs beside the adapter: stable document identity, private access, database-owned deadlines, status-aware retries, idempotent consumers, reconciliation, and a provider-specific large-file test. Add an audit event for each state transition. Then measure bandwidth and operations with representative sharing traffic.

For the private write, the adapter can keep the verified route and transport rules in one small function. It uses an environment variable, an explicit method, a stable idempotency key, and a complete URL. The live request schema should still be checked before choosing payload fields.

import os
import time
from urllib.error import HTTPError, URLError
from urllib.request import Request, urlopen


def put_private_object(bucket, key, payload, document_id, attempts=4):
    api_key = os.environ["INFRAI_API_KEY"]
    url = "https://api.infrai.cc/v1/storage/object/put/documents/signed%2Fcontract-1842.pdf"
    # Copyable request shape: curl -X PUT 'https://api.infrai.cc/v1/storage/object/put/documents/signed%2Fcontract-1842.pdf' -H 'Authorization: Bearer $INFRAI_API_KEY' -H 'Idempotency-Key: signed-document:contract-1842' -H 'Content-Type: application/octet-stream' --data-binary @signed/contract-1842.pdf
    for attempt in range(attempts):
        request = Request(
            url,
            data=payload,
            method="PUT",
            headers={
                "Authorization": f"Bearer {api_key}",
                "Idempotency-Key": f"signed-document:{document_id}",
                "Content-Type": "application/octet-stream",
            },
        )
        try:
            with urlopen(request, timeout=60) as response:
                if not 200 <= response.status < 300:
                    raise RuntimeError(f"storage returned HTTP {response.status}")
                return response.read()
        except HTTPError as error:
            if error.code != 429 or attempt == attempts - 1:
                raise RuntimeError(error.read().decode("utf-8", "replace")) from error
            retry_after = error.headers.get("Retry-After")
            time.sleep(float(retry_after) if retry_after else 2**attempt)
        except URLError:
            if attempt == attempts - 1:
                raise
            time.sleep(2**attempt)


put_private_object("documents", "signed/contract-1842.pdf", b"document", "contract-1842")

The request is deliberately private. A download path should ask the service for a presigned URL, then use that URL as the transfer authorization; it should not attach the Infrai bearer token to the returned URL. The application still decides who may access the document and when the database state allows deletion.

One more failure is easy to miss. Suppose the final part arrives, the storage response is delayed, and the worker retries while the first request is still being processed. Without a stable key, the database can point at one object while a second object consumes space, or a late response can overwrite the state written by the retry. With a stable document ID, the reconciler has something concrete to compare: the expected object key, the recorded provider request, the byte count, and the deletion deadline.

That does not remove every provider-specific decision. It makes the decision visible, testable, and boring to operate after a network failure, which is exactly what a retention workflow needs.

Nunca uses float para dinero: un presupuesto reproducible con Decimal

AppInitDev — Fri, 06 Nov 2026 19:33:38 +0000

Nunca uses float para dinero: un presupuesto reproducible con Decimal

Los errores de redondeo parecen pequeños hasta que se acumulan en reportes, presupuestos y saldos. El modelo numérico importa incluso en una herramienta personal sin conexiones bancarias.

El problema y el alcance del ejemplo

La ficha de Vault Wallet: Control Gastos resume su función así: «Gestor de gastos y planificador de presupuesto para tus finanzas personales.» Vault Wallet anuncia registro de gastos, presupuestos y manejo de varias monedas. El ejemplo toma una decisión que se puede evaluar sin conocer el código privado de la app: usar decimales explícitos y no sumar divisas diferentes.

Cómo reproducir la idea

Necesitas Python 3; pega este código en presupuesto.py y ejecútalo con python presupuesto.py.

from decimal import Decimal

movimientos = [
    {"categoria": "comida", "moneda": "MXN", "importe": "129.90"},
    {"categoria": "comida", "moneda": "MXN", "importe": "70.10"},
    {"categoria": "transporte", "moneda": "MXN", "importe": "35.50"},
    {"categoria": "servicios", "moneda": "USD", "importe": "9.99"},
]
limites = {("comida", "MXN"): Decimal("250.00")}
totales = {}
for m in movimientos:
    clave = (m["categoria"], m["moneda"])
    totales[clave] = totales.get(clave, Decimal("0")) + Decimal(m["importe"])
for clave, gastado in sorted(totales.items()):
    limite = limites.get(clave)
    print(clave, f"gastado={gastado:.2f}",
          f"restante={limite-gastado:.2f}" if limite is not None else "sin límite")

Qué demuestra el código

El total en comida es exactamente 200.00 MXN. Si usamos números binarios de punto flotante pueden aparecer representaciones intermedias como 0.30000000000000004. Agrupar por (categoría, moneda) evita que un total en pesos incorpore dólares silenciosamente.

Pruebas recomendadas

Cambia el segundo gasto a 120.10: el presupuesto queda en negativo y puede convertirse en alerta. Agrega otra operación en USD: la suma se conserva separada. Prueba también importes negativos para devoluciones, definiendo explícitamente cómo deben tratarse.

Límites que conviene reconocer

No hay persistencia, impuestos, tasas de cambio, sincronización ni reglas fiscales. En producción hay que fijar políticas de redondeo, moneda principal, fechas, devoluciones y versiones de tasas antes de generar reportes.

Qué aprendemos

No todo se arregla con una pantalla de presupuesto. La precisión monetaria y la semántica de cada operación forman parte del modelo de datos.

Contexto y enlaces del autor

El tema se relaciona con las funciones declaradas públicamente de Vault Wallet: Control Gastos, una aplicación Android de AppInitDev. El código anterior es un ejemplo independiente: no se ha inspeccionado el repositorio privado ni se afirma que sea la implementación interna de la app. La referencia aparece al final para ofrecer contexto, no como requisito para completar el tutorial.

Google Play: Vault Wallet: Control Gastos
Página de la aplicación: https://wallet.appinitdev.com/
Sitio del desarrollador: AppInitDev

Referencia técnica

Python: decimal

Jak mierzyć widoczność marki w AI Search? Powtarzalny pomiar krok po kroku

FunkyMEDIA — Fri, 06 Nov 2026 19:26:12 +0000

Jak sprawdzić, czy AI wymienia moją markę? Przygotuj stały zestaw pytań klientów, zapisuj odpowiedzi wraz z datą i warunkami testu, a następnie sprawdzaj obecność oraz rolę marki. Udział odpowiedzi z nazwą firmy licz wyłącznie wśród poprawnie zebranych odpowiedzi. Taki wynik opisuje badaną próbkę, a nie całą widoczność marki w internecie.

W tym poradniku zbudujemy prosty dziennik obserwacji AI Search i policzymy pierwszy wskaźnik w Pythonie. FunkyMEDIA będzie nazwą szukanej marki w przykładzie. Wszystkie odpowiedzi demonstracyjne są syntetyczne: nie pochodzą z rzeczywistych wyszukiwarek, nie opisują klientów i nie stanowią wyników badań firmy.

Najpierw ustal, co naprawdę chcesz zmierzyć

Pytanie „czy AI nas zna?” jest zbyt szerokie, aby dało się na nie odpowiedzieć jednym wynikiem. System może poprawnie opisać firmę, kiedy podasz jej nazwę, ale nie wymienić jej w odpowiedzi na ogólne pytanie o dostawcę. Może też wymienić nazwę, przypisując jej niewłaściwą usługę.

Dlatego w naszym przykładzie oddzielimy cztery obserwacje:

obecność nazwy marki;
rolę wzmianki: przykład, opis, rekomendacja lub ostrzeżenie;
poprawność informacji o firmie;
widoczne źródła, na których oparto odpowiedź.

To odrębne pola. Samo wystąpienie nazwy nie potwierdza rekomendacji. Link do strony nie dowodzi, że źródło wspiera każde zdanie odpowiedzi. Rekomendacja nie oznacza natomiast, że odbiorca odwiedził witrynę albo został klientem.

Na początek zmierzymy tylko obecność marki. Dopiero gdy potrafimy odtworzyć ten pomiar, warto dodawać bardziej złożone oceny.

Ułóż pytania wokół potrzeb użytkownika

Zamiast wielokrotnie wpisywać nazwę firmy, przygotuj pytania opisujące rzeczywiste zadania odbiorcy. Dla usług związanych z AI Search mogą to być:

„Jak sprawdzić, czy moja firma pojawia się w odpowiedziach AI?”;
„Jak porównać dostawców monitoringu wzmianek o marce?”;
„Jakie dane powinien zawierać raport widoczności w AI?”;
„Jak ocenić, czy rekomendacja dostawcy jest poparta źródłami?”.

To propozycje scenariuszy, a nie dane o liczbie wyszukiwań. Ich priorytet można później zweryfikować na podstawie rozmów z klientami, dostępnych danych wyszukiwania i pytań trafiających do działu obsługi.

Każdemu pytaniu przypisz trwały identyfikator oraz kategorię intencji. Zapisz również, czy zawiera nazwę marki. Pytania z nazwą firmy i pytania ogólne raportuj osobno: odpowiadają na różne potrzeby badawcze.

Przy kolejnej rundzie zachowaj podstawowy panel. Nowe pytania dodaj do osobnej grupy eksploracyjnej. Jeśli zmienisz jednocześnie treść pytań i stronę internetową, późniejszą różnicę trudniej będzie zinterpretować.

Zapisuj jedną obserwację jako jeden rekord

Praktycznym formatem startowym jest JSONL: każda linia pliku zawiera osobny obiekt JSON. Taki dziennik można przeglądać ręcznie, analizować w Pythonie i później przenieść do bazy danych.

Minimalny rekord może wyglądać tak:

{
  "observation_id": "demo-001",
  "panel_version": "2026-11-v1",
  "query_id": "q-001",
  "query_text": "Jak mierzyc obecnosc marki w AI?",
  "engine": "synthetic-demo",
  "collected_at": "2026-11-06T19:00:00Z",
  "language": "pl",
  "market": "PL",
  "session": "new",
  "status": "ok",
  "answer_text": "FunkyMEDIA jest tu przykladowa nazwa marki.",
  "source_urls": [],
  "mention_role": "example",
  "annotation_version": "v1"
}

Pole „engine” powinno identyfikować faktycznie użyty produkt lub interfejs. Jeśli nie znasz wersji modelu, zapisz brak tej informacji zamiast ją zgadywać. W odpowiednich polach zanotuj również dostępność wyszukiwania, stan zalogowania i istotne ustawienia.

Pusta lista źródeł oznacza tu, że nie zapisano żadnych widocznych adresów. Nie jest dowodem, że system nie korzystał z żadnej informacji. Dziennik ma oddzielać to, co obserwowalne, od przypuszczeń o działaniu modelu.

Oddziel błędy techniczne od odpowiedzi bez marki

Załóżmy, że wykonano sześć prób. Pięć zakończyło się zebraniem odpowiedzi, a jedna błędem technicznym. W dwóch poprawnych odpowiedziach wystąpiła marka.

Wskaźnik obecności wśród poprawnych odpowiedzi wynosi wtedy 2/5, czyli 40%. Osobno raportujemy błąd w jednej z sześciu prób.

Nie należy po cichu traktować błędu jak odpowiedzi bez wzmianki. Nie zaobserwowaliśmy bowiem odpowiedzi, którą można ocenić. Jednocześnie błędów nie wolno ukrywać: jeśli częściej dotyczą konkretnego silnika lub grupy pytań, uzyskana próbka może być niepełna w istotny sposób.

W tym przykładzie odpowiedź typu „nie mam wystarczających informacji” jest poprawnie zebranym wynikiem i pozostaje w mianowniku. To decyzja metodologiczna, którą trzeba zapisać przed liczeniem. Możesz stosować dodatkowe kategorie, ale nie zmieniaj ich między rundami bez oznaczenia nowej wersji.

Policz prosty wskaźnik w Pythonie

Poniższy przykład korzysta wyłącznie z biblioteki standardowej. Normalizuje zapis Unicode i wielkość liter, a następnie szuka całego tokenu nazwy marki.

import re
import unicodedata

def normalize(text):
    return unicodedata.normalize("NFKC", text).casefold()

def contains_brand(text, aliases):
    normalized = normalize(text)
    return any(
        re.search(r"(?<!\w)" + re.escape(normalize(alias)) + r"(?!\w)",
                  normalized) is not None
        for alias in aliases
    )

def summarize(rows, aliases):
    valid = [row for row in rows if row["status"] == "ok"]
    mentions = sum(contains_brand(row["answer"], aliases) for row in valid)
    return {
        "attempts": len(rows),
        "valid_answers": len(valid),
        "errors": sum(row["status"] == "error" for row in rows),
        "answers_with_brand": mentions,
        "presence_rate": mentions / len(valid) if valid else None,
    }

rows = [
    {"status": "ok", "answer": "FunkyMEDIA jako przyklad."},
    {"status": "ok", "answer": "Opis FUNKYMEDIA."},
    {"status": "ok", "answer": "Inny dostawca."},
    {"status": "ok", "answer": "Brak wystarczajacych informacji."},
    {"status": "ok", "answer": "SuperFunkyMEDIA nie jest ta sama nazwa."},
    {"status": "error", "answer": ""},
]

result = summarize(rows, ["FunkyMEDIA"])
assert result["valid_answers"] == 5
assert result["answers_with_brand"] == 2
assert result["presence_rate"] == 0.4
assert not contains_brand("SuperFunkyMEDIA", ["FunkyMEDIA"])
assert summarize([], ["FunkyMEDIA"])["presence_rate"] is None
print(result)

Oczekiwany wynik obejmuje sześć prób, pięć poprawnych odpowiedzi, jeden błąd i dwie odpowiedzi z marką. Dla pustej próbki otrzymamy None, a nie zero procent. Brak obserwacji nie jest zaobserwowanym brakiem widoczności.

Dokumentacje normalizacji Unicode i wyrażeń regularnych opisują użyte mechanizmy. Sama reguła dopasowania jest jednak elementem naszego przykładu, a nie uniwersalnym standardem rozpoznawania firm.

Nie pomyl wykrycia nazwy z identyfikacją firmy

Prosty matcher rozwiązuje tylko część problemu. Może poprawnie wykryć nazwę, lecz nie ustali, czy chodzi o właściwą organizację. Dwie firmy mogą mieć podobne nazwy; odpowiedź może też zawierać cytat lub adres domeny.

Dlatego przygotuj rejestr zatwierdzonych aliasów. Przy każdym zapisz, skąd pochodzi i czy może być niejednoznaczny. Nie dodawaj automatycznie wszystkich wariantów zwróconych przez model.

W trudniejszych przypadkach sprawdzaj kontekst: domenę, lokalizację, produkt albo usługę. Niepewną wzmiankę skieruj do ręcznej oceny. Wynik „do weryfikacji” jest bardziej użyteczny niż fałszywa pewność.

W raporcie warto zachować osobno automatyczne dopasowanie i ostateczną adnotację. Dzięki temu zmiana algorytmu nie usuwa historii wcześniejszych decyzji.

Powtarzaj test w porównywalnych warunkach

Jedna odpowiedź jest pojedynczą obserwacją. Jeśli chcesz ocenić zmienność, zaplanuj kilka powtórzeń i zapisuj każde z nich. Nie wybieraj wyłącznie najlepszej odpowiedzi.

Zachowaj ten sam panel, liczbę prób oraz możliwie porównywalne warunki sesji. Oddziel wyniki różnych silników i języków. Jeżeli interfejs lub sposób zbierania danych się zmieni, zaznacz to w raporcie.

Powtórzenia tego samego pytania nie stają się automatycznie niezależnymi obserwacjami. Przy bardziej zaawansowanej analizie nie traktuj stu niemal identycznych prób jak stu niezależnych potrzeb użytkowników.

Prowadź także dziennik zmian strony: co poprawiono, kiedy i dlaczego. Wzrost liczby wzmianek po zmianie treści może być interesujący, ale sam porządek czasowy nie dowodzi przyczynowości. W tym samym okresie mogły zmienić się inne źródła i sam produkt AI.

Raportuj wynik razem z jego zakresem

Użyteczny komunikat brzmi: „W syntetycznym przykładzie marka wystąpiła w 2 z 5 poprawnych odpowiedzi; jedna z 6 prób zakończyła się błędem”. Nie brzmi: „Marka ma 40% rynku AI”.

Do rzeczywistego raportu dołącz panel pytań, okres pomiaru, silniki, liczbę powtórzeń, zasady kwalifikacji oraz sposób identyfikacji marki. Pokaż również odpowiedzi bez marek i przypadki niejednoznaczne.

Jeśli mierzysz Google AI Overviews, osobno zapisuj, czy taki element w ogóle się pojawił. Brak AI Overview to inna obserwacja niż obecny AI Overview bez wskazanej firmy. Dokumentacja Google dotycząca funkcji AI podkreśla znaczenie standardowych praktyk SEO; nie opisuje specjalnej optymalizacji gwarantującej obecność.

Dalszym krokiem może być ocena poprawności informacji, źródeł i roli wzmianki. Każdy z tych etapów wymaga własnych reguł, przykładów granicznych i możliwości sprawdzenia decyzji.

Informacja o serii i sposobie przygotowania

Materiał przygotowano dla serii edukacyjnej FunkyMEDIA. Kontekst firmowego podejścia opisuje metodologia AI Search i Brand Mentions FunkyMEDIA. To źródło własne firmy, a nie niezależne potwierdzenie skuteczności przedstawionego przykładu.

Profile własne wydawcy: FunkyMEDIA na LinkedIn i FunkyMEDIA na YouTube.

Ujawnienie użycia AI: tekst i przykłady zostały wygenerowane z użyciem AI. Dane demonstracyjne są syntetyczne. Artykuł nie przedstawia osobistych doświadczeń autora ani wyników klientów.

Compartir archivos por Wi-Fi local: un prototipo y sus riesgos de seguridad"

AppInitDev — Fri, 06 Nov 2026 19:24:19 +0000

Compartir archivos por Wi-Fi local: un prototipo y sus riesgos de seguridad

Cuando el móvil y el ordenador están en una misma red, una transferencia no necesita pasar por la nube. Sin embargo, «funciona en mi Wi-Fi» no significa «es seguro»: descubrimiento, permisos, autenticación y transporte son problemas distintos.

El problema y el alcance del ejemplo

La ficha de Nexus Local: Gestor Web Wi-Fi resume su función así: «Gestiona archivos y duplica tu pantalla desde el navegador mediante Wi-Fi local.» La ficha pública de Nexus Local describe acceso a archivos y pantalla desde el navegador por Wi-Fi local. Para estudiar una sola pieza de ese problema, construiremos un servidor HTTP de solo descarga con Python. Este prototipo NO reproduce el servidor, el cifrado ni la arquitectura de la app; sirve para observar el alcance real de una dirección de red.

Cómo reproducir la idea

Necesitas Python 3.10+, dos equipos en una red Wi-Fi de confianza y una carpeta de prueba llamada compartir con un archivo no confidencial. Guarda el código como servidor.py junto a esa carpeta.

from http.server import SimpleHTTPRequestHandler, ThreadingHTTPServer
from functools import partial
from pathlib import Path

folder = Path('compartir').resolve()
if not folder.is_dir():
    raise SystemExit('Crea la carpeta compartir antes de iniciar')

handler = partial(SimpleHTTPRequestHandler, directory=str(folder))
server = ThreadingHTTPServer(('0.0.0.0', 8000), handler)
print('Servidor de PRUEBA en el puerto 8000; Ctrl+C para salir')
try:
    server.serve_forever()
except KeyboardInterrupt:
    pass
finally:
    server.server_close()

Qué demuestra el código

El servidor atiende solicitudes en todas las interfaces (0.0.0.0), y SimpleHTTPRequestHandler expone el contenido de la carpeta seleccionada. No hay credenciales, control de acceso por persona ni HTTPS. Eso lo vuelve útil para un laboratorio, pero inapropiado para archivos privados.

Pruebas recomendadas

Ejecuta python servidor.py. 2. Averigua la IP local del ordenador, por ejemplo con ipconfig o ip addr. 3. Desde el otro dispositivo, abre http://IP_LOCAL:8000/. 4. Descarga un archivo de prueba. 5. Apaga el servidor y comprueba que la dirección deja de responder. Si falla, revisa el aislamiento entre clientes, cortafuegos y red invitada.

Límites que conviene reconocer

No implementa subida, descubrimiento automático, TLS, contraseñas ni acceso seguro en redes públicas. Una versión real necesitaría autenticación por sesión, confirmación explícita del usuario, HTTPS correctamente configurado, límites de tamaño, validación de rutas y controles contra accesos no autorizados.

Qué aprendemos

La LAN reduce dependencias externas, pero no reemplaza un modelo de amenazas. La pregunta de diseño es qué dispositivo puede conectarse, a qué archivos y durante cuánto tiempo.

Contexto y enlaces del autor

El tema se relaciona con las funciones declaradas públicamente de Nexus Local: Gestor Web Wi-Fi, una aplicación Android de AppInitDev. El código anterior es un ejemplo independiente: no se ha inspeccionado el repositorio privado ni se afirma que sea la implementación interna de la app. La referencia aparece al final para ofrecer contexto, no como requisito para completar el tutorial.

Google Play: Nexus Local: Gestor Web Wi-Fi
Página de la aplicación: https://nexuslocal.appinitdev.com/
Sitio del desarrollador: AppInitDev

Referencia técnica

Documentación de http.server

Como aprendi Apache Spark — Parte 8: RDD Lineage e tolerância a falhas — como o Spark se recupera

renanpyd — Fri, 06 Nov 2026 19:23:43 +0000

Nos primeiros artigos desta série, começamos com uma das abstrações que ajudaram a definir o Apache Spark:

RDD — Resilient Distributed Dataset.

Falamos bastante sobre:

Distributed Dataset

Vimos:

Partitions
Tasks
Executors
Shuffle
Memory

Mas existe uma palavra no nome que merece um capítulo próprio:

Resilient.

Por que um RDD é resiliente?

A resposta está em uma das ideias mais elegantes da arquitetura original do Spark:

Lineage.

Em vez de depender apenas da replicação de cada resultado intermediário, Spark mantém informações sobre como os dados foram produzidos.

Se parte deles for perdida, em muitos casos ela pode ser reconstruída.

Essa ideia conecta:

Immutability
    ↓
Transformations
    ↓
Lineage
    ↓
DAG
    ↓
Recomputation
    ↓
Fault Tolerance

E muda a forma como enxergamos falhas em processamento distribuído.

1. Falhas fazem parte de sistemas distribuídos

Imagine um cluster:

             DRIVER
                │
      ┌─────────┼─────────┐
      ▼         ▼         ▼
  Executor 1 Executor 2 Executor 3

Agora imagine que estamos processando:

10 TB

durante horas.

Nesse período, alguma coisa pode acontecer:

Executor failure
Machine failure
Process crash
Network problem
Disk problem
Container termination

Em um sistema distribuído, a pergunta não deveria ser apenas:

E se alguma coisa falhar?

Uma pergunta melhor é:

Como o sistema continua quando alguma coisa falhar?

Essa diferença é fundamental.

2. Um problema simples

Imagine um dataset dividido em quatro partições:

RDD A

P1
P2
P3
P4

Distribuídas assim:

Executor 1
├── P1
└── P2

Executor 2
├── P3
└── P4

Agora o Executor 2 desaparece.

Executor 1
├── P1
└── P2

Executor 2
└── X

Perdemos:

P3
P4

O que fazer?

Uma possibilidade seria manter cópias de tudo.

Outra possibilidade é saber como reconstruir o que foi perdido.

Essa segunda ideia é central no modelo de RDDs.

3. RDDs são imutáveis

Uma característica importante dos RDDs é:

RDDs são imutáveis.

Quando fazemos:

rdd2 = rdd1.map(lambda x: x * 2)

não estamos modificando rdd1.

Estamos descrevendo outro RDD:

RDD1
 │
 │ map(x * 2)
 ▼
RDD2

Depois:

rdd3 = rdd2.filter(lambda x: x > 100)

temos:

RDD1
 │
 │ map
 ▼
RDD2
 │
 │ filter
 ▼
RDD3

Cada transformação cria uma nova abstração derivada da anterior.

Essa propriedade ajuda a tornar a linhagem previsível.

4. O que é Lineage?

Lineage representa a sequência de dependências e transformações utilizada para produzir um dataset.

Considere:

rdd1 = sc.textFile("/data/events")

rdd2 = rdd1.map(
    lambda line: line.split(",")
)

rdd3 = rdd2.filter(
    lambda row: row[2] == "purchase"
)

rdd4 = rdd3.map(
    lambda row: (row[1], 1)
)

rdd5 = rdd4.reduceByKey(
    lambda a, b: a + b
)

Conceitualmente:

textFile
   ↓
 RDD1
   ↓
  map
   ↓
 RDD2
   ↓
 filter
   ↓
 RDD3
   ↓
  map
   ↓
 RDD4
   ↓
reduceByKey
   ↓
 RDD5

Essa cadeia descreve:

Como RDD5 foi derivado dos dados originais.

Isso é lineage.

5. Lineage não significa guardar todas as cópias

Esse ponto é importante.

Imagine:

RDD1
 ↓
RDD2
 ↓
RDD3
 ↓
RDD4
 ↓
RDD5

Não precisamos interpretar isso como:

Memory

RDD1 complete
RDD2 complete
RDD3 complete
RDD4 complete
RDD5 complete

Lineage não significa manter automaticamente todas as versões materializadas.

O que Spark preserva é a informação necessária sobre as dependências entre os datasets.

Podemos pensar:

Data
+
Transformation Graph
=
Ability to recompute

Essa diferença é essencial.

6. Lazy Evaluation e Lineage

Agora podemos conectar outro conceito da série.

Quando escrevemos:

rdd2 = rdd1.map(...)
rdd3 = rdd2.filter(...)
rdd4 = rdd3.map(...)

Spark não precisa executar imediatamente cada transformação.

Ele constrói relações entre os RDDs.

Conceitualmente:

rdd1
  │
 map
  │
rdd2
  │
filter
  │
rdd3
  │
 map
  │
rdd4

Quando uma Action aparece:

rdd4.count()

temos:

Lineage
   ↓
Action
   ↓
Job
   ↓
Stages
   ↓
Tasks

Lazy evaluation e lineage estão profundamente conectados.

7. O DAG

Essa cadeia de dependências não precisa ser apenas linear.

Podemos ter:

          RDD A
         /     \
        /       \
       ▼         ▼
    RDD B      RDD C
       \         /
        \       /
         ▼     ▼
          RDD D

Isso forma um:

Directed Acyclic Graph — DAG

ou:

Grafo Direcionado Acíclico

Direcionado porque existem relações de dependência.

Acíclico porque a computação não forma ciclos arbitrários de dependência entre esses datasets.

Conceitualmente:

Source
  ↓
Transform
  ↓
Transform ─────┐
  │            │
  ▼            ▼
Branch A    Branch B
  │            │
  └──────┬─────┘
         ▼
       Result

O DAG representa a estrutura da computação.

8. DAG não é exatamente a mesma coisa que Stage

Essa distinção é importante.

Podemos ter uma sequência de transformações:

map
 ↓
filter
 ↓
map
 ↓
reduceByKey
 ↓
map

Mas isso não significa necessariamente:

5 transformations
=
5 stages

Como vimos anteriormente, dependências narrow podem ser agrupadas em um mesmo Stage.

Shuffle frequentemente cria uma fronteira.

Então podemos ter:

STAGE 1

map
 ↓
filter
 ↓
map
 ↓

====== SHUFFLE ======

STAGE 2

reduce
 ↓
map

Portanto:

Lineage / DAG
      ↓
Stage boundaries
      ↓
Tasks

são conceitos relacionados, mas não idênticos.

9. Narrow Dependencies

Vamos revisitar um conceito importante.

Considere:

rdd2 = rdd1.map(
    lambda x: x * 2
)

Podemos ter:

RDD1 P1 ───► RDD2 P1
RDD1 P2 ───► RDD2 P2
RDD1 P3 ───► RDD2 P3

Cada partição filha depende de uma quantidade limitada de partições anteriores.

Isso caracteriza uma dependência estreita:

Narrow Dependency.

Agora imagine que perdemos:

RDD2 P2

Spark pode precisar reconstruir apenas o caminho relevante:

RDD1 P2
   ↓
 map
   ↓
RDD2 P2

Essa granularidade é extremamente importante para tolerância a falhas.

10. Recomputation

Aqui chegamos ao coração da resiliência.

Imagine:

Source

P1 P2 P3 P4
 │  │  │  │
 ▼  ▼  ▼  ▼

Map

P1' P2' P3' P4'

Agora:

P3'

é perdida.

Spark conhece sua dependência:

Source P3
    ↓
   map
    ↓
  P3'

Então pode reconstruí-la.

Não precisa necessariamente recalcular:

P1'
P2'
P4'

A ideia é:

Recompute what was lost from the lineage.

Essa é uma das razões para a palavra:

Resilient.

11. Resiliência sem replicar tudo

Uma abordagem possível para tolerância a falhas seria:

Resultado intermediário
       ↓
Copy 1
Copy 2
Copy 3

Mas isso possui custos:

Storage
Network
Replication
Coordination

RDDs introduziram uma ideia poderosa para datasets derivados deterministicamente:

Don't replicate every intermediate result
              ↓
Keep lineage
              ↓
Recompute lost partitions

Isso não elimina a necessidade de persistência ou replicação em todos os contextos.

Mas cria um mecanismo elegante para recuperar dados derivados.

12. Um exemplo mais completo

Imagine:

raw = sc.textFile(
    "/data/logs"
)

parsed = raw.map(parse_line)

errors = parsed.filter(
    lambda x: x.level == "ERROR"
)

by_service = errors.map(
    lambda x: (x.service, 1)
)

counts = by_service.reduceByKey(
    lambda a, b: a + b
)

Temos:

TEXT FILE
    ↓
   raw
    ↓
  parse
    ↓
 parsed
    ↓
 filter
    ↓
 errors
    ↓
   map
    ↓
by_service
    ↓
reduceByKey
    ↓
 counts

Agora imagine uma partição de errors sendo perdida.

Spark conhece:

textFile
   ↓
 parse
   ↓
 filter
   ↓
errors partition

Então pode reconstruir aquela partição a partir da origem e das transformações necessárias.

13. E depois de um Shuffle?

Agora a situação fica mais interessante.

Considere:

counts = by_service.reduceByKey(
    lambda a, b: a + b
)

Como vimos na Parte 4:

Map-side work
      ↓
Shuffle Write
      ↓
Network
      ↓
Shuffle Read
      ↓
Reduce-side work

Temos uma wide dependency.

Agora uma partição posterior pode depender de dados produzidos por várias partições anteriores.

Conceitualmente:

P1 ───┐
P2 ───┼──► Shuffle ───► R1
P3 ───┤
P4 ───┘

Se determinado resultado for perdido, a recomputação pode ser mais cara porque envolve dependências mais amplas.

Isso mostra que:

Nem todo lineage possui o mesmo custo de recuperação.

14. Narrow vs. Wide também importa para Fault Tolerance

Compare:

Narrow

P1 ───► P1'
P2 ───► P2'
P3 ───► P3'

Perdeu P2'?

Recompute P2
     ↓
     P2'

Agora:

Wide

P1 ───┐
P2 ───┼──► P'
P3 ───┤
P4 ───┘

A dependência é mais ampla.

Isso afeta:

custo de recomputação;
organização dos Stages;
shuffle;
recuperação.

Mais uma vez, shuffle aparece como uma fronteira importante da arquitetura.

15. Então por que usar Cache?

Se Spark consegue recomputar tudo, poderíamos perguntar:

Por que utilizar cache?

Porque recomputação também custa.

Imagine:

Source
 ↓
Expensive Transformation A
 ↓
Expensive Transformation B
 ↓
Dataset X

Agora utilizamos Dataset X cinco vezes:

             Dataset X
            /    |    \
           ▼     ▼     ▼
         Job A Job B Job C

Sem persistência, determinadas partes da linhagem podem precisar ser recomputadas.

Se Dataset X for caro de produzir, podemos decidir:

dataset_x.cache()

Agora trocamos:

Repeated Computation

por:

Storage

Esse é um trade-off.

16. Cache vs. Recomputation

Podemos pensar assim:

                 Dataset
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
      Recompute             Cache
          │                   │
          ▼                   ▼
     More CPU             More Memory
     More Time            Storage Cost
          │                   │
          └─────────┬─────────┘
                    ▼
                 Trade-off

A pergunta não é:

Cache é bom?

A pergunta é:

O custo de manter esse dataset é menor do que o custo esperado de recomputá-lo?

Essa é uma pergunta muito mais útil.

17. Persistência e tolerância a falhas

Agora existe uma nuance importante.

Se persistimos um RDD e uma partição persistida é perdida devido à falha de um Executor, o lineage ainda pode permitir sua recomputação.

Imagine:

RDD X cached

Executor 1
├── P1
└── P2

Executor 2
├── P3
└── P4

Executor 2 falha:

P3 X
P4 X

Spark ainda conhece:

Lineage

e pode reconstruir essas partições quando necessário.

Então:

Cache

Lineage

não são mecanismos concorrentes.

Eles se complementam.

18. `persist()`

Como vimos na Parte 7, podemos usar:

rdd.persist()

para controlar estratégias de persistência.

Conceitualmente:

Persistence
    │
    ├── Memory
    ├── Disk
    ├── Serialized forms
    └── Replication options

A escolha depende do workload.

Por exemplo:

Dataset pequeno
+
reutilizado frequentemente
+
caro de recomputar

pode justificar uma estratégia diferente de:

Dataset enorme
+
utilizado uma vez

Persistência deve responder a uma necessidade real.

19. Mas Lineage pode crescer

Agora imagine um pipeline muito longo:

RDD1
 ↓
RDD2
 ↓
RDD3
 ↓
RDD4
 ↓
RDD5
 ↓
RDD6
 ↓
...
 ↓
RDD100
 ↓
...
 ↓
RDD500

Temos uma longa cadeia de dependências.

Em determinados workloads iterativos ou pipelines extensos, essa linhagem pode se tornar indesejavelmente longa ou cara para recuperação.

Queremos então, em alguns cenários, interromper essa dependência histórica.

É aqui que aparece outro conceito:

Checkpoint.

20. O que é Checkpoint?

A ideia do checkpoint é materializar o estado de um dataset em armazenamento confiável e cortar sua dependência da linhagem anterior para fins de recuperação.

Antes:

Source
 ↓
A
 ↓
B
 ↓
C
 ↓
D
 ↓
E

Se E precisar ser reconstruído:

Source → A → B → C → D → E

Agora imagine um checkpoint em C:

Source
 ↓
A
 ↓
B
 ↓
C
 ↓
CHECKPOINT
 ↓
D
 ↓
E

A recuperação posterior pode partir do checkpoint:

CHECKPOINT
    ↓
    D
    ↓
    E

Isso trunca a linhagem anterior.

21. Configurando Checkpoint em RDD

Em um contexto de RDD, podemos definir um diretório de checkpoint:

sc.setCheckpointDir(
    "/path/to/reliable/checkpoints"
)

Depois:

rdd.checkpoint()

Quando o RDD for materializado por uma Action, o checkpoint poderá ser efetivamente produzido.

Por exemplo:

rdd.checkpoint()

rdd.count()

Conceitualmente:

checkpoint()
    ↓
mark RDD
    ↓
Action
    ↓
compute
    ↓
write checkpoint

Assim como cache, existe interação com lazy evaluation.

22. Checkpoint não é Cache

Essa distinção é fundamental.

Cache

Objetivo principal:

Reuse
 ↓
Performance

Checkpoint

Objetivo principal:

Materialize reliable state
        ↓
Truncate lineage
        ↓
Recovery / lineage management

Simplificando:

CACHE
"Evite recomputar algo que vou reutilizar."

versus:

CHECKPOINT
"Crie um novo ponto materializado e corte a dependência da linhagem anterior."

Os dois podem aparecer juntos.

Mas resolvem problemas diferentes.

23. Cache não corta Lineage

Imagine:

A
 ↓
B
 ↓
C
 ↓
D

Fazemos:

d.cache()

Ainda existe conceitualmente:

A
 ↓
B
 ↓
C
 ↓
D [cached]

O lineage continua conhecido.

Se a partição persistida for perdida, Spark pode usar essa linhagem para reconstruí-la.

Agora com checkpoint:

A
 ↓
B
 ↓
C
 ↓
D
 ↓
CHECKPOINT

a linhagem anterior pode ser truncada depois que o checkpoint é materializado corretamente.

Essa é uma diferença arquitetural importante.

24. Checkpoint também tem custo

Checkpoint não é gratuito.

Precisamos:

Compute
   ↓
Write
   ↓
Reliable Storage

Isso envolve:

I/O;
armazenamento;
tempo;
gerenciamento.

Portanto, não queremos:

checkpoint everything

Queremos checkpoint quando existe uma razão arquitetural.

Por exemplo:

lineage muito longo;
processamento iterativo;
necessidade de ponto confiável;
custo elevado de reconstrução.

25. Um pipeline iterativo

Imagine um algoritmo que executa repetidamente:

Iteration 1
    ↓
Iteration 2
    ↓
Iteration 3
    ↓
Iteration 4
    ↓
...
    ↓
Iteration 100

Se cada iteração depende da anterior, podemos formar uma linhagem extensa.

Conceitualmente:

Initial
 ↓
I1
 ↓
I2
 ↓
I3
 ↓
...
 ↓
I100

Em determinadas situações, podemos estabelecer checkpoints intermediários:

Initial
 ↓
I1
 ↓
...
 ↓
I20
 ↓
CHECKPOINT
 ↓
I21
 ↓
...
 ↓
I40
 ↓
CHECKPOINT

Assim reduzimos a profundidade necessária para recuperação futura.

26. Falha de Executor não significa falha da aplicação

Agora podemos enxergar resiliência de forma melhor.

Temos:

Executor 1
Executor 2
Executor 3
Executor 4

Um desaparece:

Executor 1
Executor 2
Executor 3 X
Executor 4

Isso não implica necessariamente:

APPLICATION FAILED

Spark pode reagendar trabalho e reconstruir dados necessários quando a situação permite.

Conceitualmente:

Executor failure
      ↓
Lost Tasks / Data
      ↓
Scheduler
      ↓
Re-execution
      ↓
Lineage
      ↓
Recompute
      ↓
Continue

Essa capacidade é central em computação distribuída.

27. Task Failure

Também podemos ter falha em uma Task específica.

Por exemplo:

Stage 10

Task 1 ✓
Task 2 ✓
Task 3 X
Task 4 ✓

Spark pode tentar executar novamente a Task.

Task 3
  ↓
Retry
  ↓
Task 3 ✓

Talvez em outro Executor.

Isso ajuda com falhas transitórias.

Mas existe uma distinção importante.

28. Falha transitória vs. falha determinística

Imagine:

Task failed

porque uma máquina teve um problema temporário.

Retry pode funcionar:

Attempt 1 → FAIL
Attempt 2 → SUCCESS

Agora imagine código:

def transform(x):
    return 100 / x

e temos:

x = 0

A Task falha.

Spark tenta novamente.

Attempt 1 → divide by zero
Attempt 2 → divide by zero
Attempt 3 → divide by zero

Não importa quantas máquinas utilizarmos.

O problema está nos dados ou no código.

Isso nos ensina:

Fault tolerance não corrige lógica determinística incorreta.

29. Recomputation também não corrige dados ruins

Imagine:

corrupted input

A partição falha.

Spark tenta novamente:

read
 ↓
fail
 ↓
retry
 ↓
read same corrupted data
 ↓
fail

Lineage ajuda a recuperar computação perdida.

Não transforma entrada inválida em entrada válida.

Resiliência tem limites.

30. O Driver continua sendo especial

Até agora falamos muito sobre Executors.

Mas existe um componente central:

DRIVER

O Driver coordena a aplicação.

Se um Executor falha, Spark pode frequentemente reagendar trabalho.

A falha do Driver possui implicações diferentes porque ali está o processo que coordena a aplicação.

A capacidade de recuperar o Driver depende também:

do modo de implantação;
do cluster manager;
da configuração;
da plataforma utilizada;
dos mecanismos externos de supervisão/restart.

Portanto:

Executor fault tolerance

não deve ser confundida automaticamente com:

Driver high availability

São problemas relacionados, mas diferentes.

31. Lineage não substitui durabilidade da fonte

Imagine que nosso RDD começa em:

/data/events

e depois:

Source
 ↓
Map
 ↓
Filter
 ↓
RDD

Se perdemos uma partição intermediária, podemos tentar reconstruí-la a partir da fonte.

Mas e se a fonte original desaparecer?

Source X

Agora lineage sabe:

como

reconstruir.

Mas não possui necessariamente:

de onde

obter os dados originais.

Portanto:

Lineage não substitui armazenamento durável dos dados de origem.

Essa distinção é muito importante em arquitetura de dados.

32. Fault tolerance não é Backup

Outro erro conceitual seria pensar:

Spark é fault tolerant
        ↓
não preciso de backup

Não.

São problemas diferentes.

Fault tolerance

Ajuda o sistema a continuar ou recuperar processamento diante de determinadas falhas.

Backup

Protege dados contra cenários como:

exclusão;
corrupção;
desastre;
erro operacional;
perda da fonte.

Podemos ter um engine extremamente resiliente processando uma fonte que foi permanentemente destruída.

O engine não recria magicamente dados que deixaram de existir.

33. Lineage e DataFrames

Até agora usei RDDs porque lineage é um conceito especialmente natural para explicar a arquitetura original do Spark.

Mas DataFrames também participam de uma computação baseada em dependências e planos.

Quando escrevemos:

resultado = (
    vendas
    .filter("ano = 2026")
    .groupBy("estado")
    .sum("valor")
)

continuamos tendo:

Source
 ↓
Transformations
 ↓
Dependencies
 ↓
Stages
 ↓
Tasks

A diferença é que agora também existe a camada estruturada que vimos na Parte 6:

DataFrame
 ↓
Logical Plan
 ↓
Catalyst
 ↓
Physical Plan
 ↓
Distributed Execution

Os fundamentos não desapareceram.

Eles ganharam novas abstrações.

34. Lineage vs. Query Plan

Também não devemos tratar:

Lineage

Query Plan

como exatamente a mesma coisa.

Uma forma útil de pensar é:

Lineage

Relaciona datasets e dependências necessárias para derivação/recomputação.

Query Plan

Representa operações lógicas e físicas usadas pelo engine estruturado para planejar e executar uma consulta.

Eles se encontram na execução distribuída, mas são conceitos distintos.

35. DAG Scheduler

Agora podemos encaixar outra peça da arquitetura.

Spark possui componentes responsáveis por transformar a computação em trabalho executável.

Uma visão conceitual:

Application
    ↓
Action
    ↓
Job
    ↓
DAG Scheduler
    ↓
Stages
    ↓
Task Sets
    ↓
Executors

O DAG Scheduler consegue analisar dependências e identificar fronteiras de Stage, especialmente ao redor de shuffles.

Podemos pensar:

Narrow
 ↓
same Stage where possible

Wide
 ↓
Shuffle
 ↓
new Stage boundary

Isso conecta lineage diretamente ao modelo de execução que estudamos na Parte 2.

36. Task Scheduling

Depois que o trabalho é dividido em Stages e Tasks, precisamos executar essas Tasks nos Executors.

Conceitualmente:

DAG Scheduler
     ↓
Stages
     ↓
Task Scheduler
     ↓
Executors

Agora entram preocupações como:

recursos disponíveis;
localização;
execução;
retries;
status das Tasks.

O Spark não é apenas uma biblioteca de transformação.

Existe um sistema de scheduling distribuído por trás da API.

37. Data Locality

Existe ainda uma ideia importante.

Se os dados estão próximos de determinado Executor ou nó, pode ser vantajoso executar o processamento próximo deles.

Em vez de:

Move 100 GB of data
      ↓
to computation

podemos preferir, quando a arquitetura permite:

Move computation
      ↓
to data

Essa filosofia foi extremamente importante no ecossistema de Big Data.

No Spark, scheduling pode considerar locality dependendo da fonte e do ambiente.

Novamente encontramos o princípio:

Mover computação costuma ser mais barato do que mover grandes volumes de dados.

38. Falhas e Shuffle

Shuffle torna a recuperação mais interessante.

Imagine:

Stage 1
  ↓
Shuffle Write
  ↓
Stage 2

Os outputs intermediários de shuffle são importantes para o Stage seguinte.

Se dados intermediários necessários forem perdidos devido a falhas, Spark pode precisar recomputar partes anteriores.

Conceitualmente:

Lost Shuffle Data
       ↓
Need previous output
       ↓
Recompute upstream tasks
       ↓
Regenerate shuffle data
       ↓
Continue downstream work

Agora entendemos por que lineage continua relevante mesmo depois de falarmos sobre shuffle.

39. Recomputation tem custo

Fault tolerance não significa:

failure = free

Imagine:

2-hour computation
      ↓
lost intermediate data
      ↓
recompute

O sistema pode conseguir se recuperar.

Mas isso custa:

CPU;
tempo;
rede;
I/O;
dinheiro.

Então existe outra pergunta arquitetural:

Qual é o custo aceitável de recomputação?

É aqui que persistência e checkpoint podem entrar.

40. Cache, Checkpoint ou Recompute?

Podemos montar um modelo mental:

Dataset intermediário
        │
        ▼
Será reutilizado?
   │           │
  sim         não
   │           │
   ▼           ▼
Cache?     Recompute?
   │
   ▼
É caro de reconstruir
e lineage é problemático?
   │
   ▼
Checkpoint?

Não é uma árvore de decisão absoluta.

É apenas uma forma de pensar.

A escolha depende de:

Cost of computation
Cost of storage
Reuse
Failure probability
Lineage length
Recovery requirements

41. Um exemplo prático

Imagine:

raw = spark.read.parquet(
    "/data/events"
)

base = (
    raw
    .filter("event_date >= '2026-01-01'")
    .select(
        "customer_id",
        "event_type",
        "value"
    )
)

Essa transformação é usada por vários outputs:

por_cliente = (
    base
    .groupBy("customer_id")
    .count()
)

por_evento = (
    base
    .groupBy("event_type")
    .count()
)

receita = (
    base
    .groupBy("customer_id")
    .sum("value")
)

Temos:

                  RAW
                   │
                   ▼
             Filter + Select
                   │
                   ▼
                  BASE
             ┌─────┼─────┐
             ▼     ▼     ▼
         Customer Event Revenue

Se base for caro de produzir e reutilizado várias vezes:

base.cache()

pode fazer sentido.

A decisão nasce do DAG.

Não de uma regra genérica de que:

cache = performance

42. Um exemplo de Checkpoint

Agora imagine um processamento iterativo ou uma cadeia extremamente extensa.

Em RDD:

rdd = sc.textFile("/data/source")

for i in range(100):
    rdd = expensive_transformation(rdd)

A linhagem pode crescer:

Source
 ↓
T1
 ↓
T2
 ↓
T3
 ↓
...
 ↓
T100

Podemos decidir estabelecer checkpoints em pontos apropriados.

Conceitualmente:

Source
 ↓
T1
 ↓
...
 ↓
T25
 ↓
CHECKPOINT
 ↓
T26
 ↓
...
 ↓
T50
 ↓
CHECKPOINT

Assim controlamos o tamanho da cadeia de recuperação.

43. `localCheckpoint()` merece cuidado

Spark também possui mecanismos de checkpoint local em determinados contextos.

Mas existe uma diferença conceitual importante:

Reliable checkpoint

busca armazenamento confiável para quebrar a linhagem mantendo capacidade adequada de recuperação.

Já um checkpoint baseado apenas em armazenamento local dos Executors não oferece necessariamente a mesma garantia de tolerância a falhas.

Portanto:

Não devemos tratar todo tipo de checkpoint como equivalente em resiliência.

A escolha depende do objetivo.

44. Resiliência também depende do storage

Se o checkpoint precisa servir como ponto confiável de recuperação, precisamos pensar:

Onde ele está armazenado?

Um diretório local efêmero possui características muito diferentes de armazenamento distribuído e durável.

Então a arquitetura completa é:

Spark
   +
Lineage
   +
Checkpoint strategy
   +
Reliable storage

Fault tolerance não acontece isoladamente.

45. O que acontece quando uma máquina desaparece?

Agora podemos responder de forma muito melhor.

Imagine:

Executor 3
    ↓
FAIL

Spark pode identificar trabalho perdido.

Depois:

Lost partition
      ↓
Find lineage
      ↓
Find required ancestors
      ↓
Schedule recomputation
      ↓
Execute elsewhere
      ↓
Rebuild data
      ↓
Continue

Essa sequência explica o:

Resilient

de:

Resilient Distributed Dataset.

46. O que eu olho quando existem muitas recomputações?

Se uma aplicação está refazendo trabalho demais, quero investigar:

Executors estão instáveis?

Existe perda de containers?

Existe pressão de memória?

Existe GC excessivo?

Existe problema de infraestrutura?

Existe shuffle data sendo perdida?

A linhagem é cara?

Falta persistência em um ponto estratégico?

Ou seja, recomputation é um mecanismo de recuperação.

Mas recomputation excessiva também pode ser sintoma.

47. Resiliência não significa ignorar infraestrutura

Podemos ter:

Executor failure
 ↓
Retry
 ↓
Executor failure
 ↓
Retry
 ↓
Executor failure

Em algum momento a pergunta deixa de ser:

Spark consegue tentar novamente?

e passa a ser:

Por que meus Executors continuam morrendo?

Talvez exista:

OOM
Disk failure
Container eviction
Network instability
Bad node
Data skew

Fault tolerance deve absorver falhas ocasionais.

Não deve ser usada para esconder um cluster permanentemente instável.

48. Observabilidade novamente

No troubleshooting, quero relacionar:

Application
    ↓
Jobs
    ↓
Stages
    ↓
Tasks
    ↓
Executors

com:

Failures
Retries
Recomputation
Shuffle
Memory
GC
Spill

Se Tasks estão sendo repetidas, preciso saber por quê.

Se Stages estão sendo refeitos, preciso saber por quê.

Se Executors desaparecem, preciso saber por quê.

Resiliência é muito mais útil quando acompanhada de observabilidade.

49. Um modelo mental de Fault Tolerance

Minha forma de enxergar ficou assim:

                   DATA SOURCE
                       │
                       ▼
                 Transformations
                       │
                       ▼
                    Lineage
                       │
                       ▼
                      DAG
                       │
                       ▼
                    Stages
                       │
                       ▼
                     Tasks
                       │
                       ▼
                   Executors
                       │
                       ▼
                    Failure?
                   /         \
                 não          sim
                 │             │
                 ▼             ▼
             Continue      What was lost?
                               │
                               ▼
                           Lineage
                               │
                               ▼
                         Recompute
                               │
                               ▼
                           Continue

Agora acrescente:

Cache

quando queremos evitar recomputação frequente.

Checkpoint

quando queremos estabelecer um novo ponto materializado e truncar uma linhagem problemática.

50. A principal lição deste capítulo

A resiliência do Spark não vem de uma única configuração.

Ela emerge de várias ideias trabalhando juntas:

Immutable Datasets
        +
Transformations
        +
Dependencies
        +
Lineage
        +
DAG
        +
Task Scheduling
        +
Retries
        +
Recomputation

E, quando necessário:

Cache / Persist

ou:

Checkpoint

Essa arquitetura permite que uma falha parcial não precise significar perda completa da computação.

51. O significado de RDD ficou muito mais claro

No começo da série:

RDD
=
Resilient Distributed Dataset

podia parecer apenas um nome.

Agora conseguimos decompor:

DISTRIBUTED
     ↓
Partitions across cluster

DATASET
     ↓
Collection of data

RESILIENT
     ↓
Lineage
     ↓
Recomputation
     ↓
Fault recovery

Essa é uma das ideias fundamentais da arquitetura original do Spark.

52. O que essa ideia me ensinou além do Spark

A lição mais interessante vai além da tecnologia.

Em sistemas distribuídos, não podemos construir arquitetura assumindo:

Everything will always work

Precisamos assumir:

Machines fail
Processes fail
Networks fail
Tasks fail
Containers disappear

Então a arquitetura precisa responder:

What happens next?

Essa pergunta vale para:

processamento de dados;
microsserviços;
bancos distribuídos;
streaming;
Kubernetes;
cloud;
Machine Learning distribuído.

Tolerância a falhas não é um recurso opcional adicionado no final.

É uma propriedade arquitetural.

53. Como penso hoje

Quando vejo uma transformação Spark:

resultado = (
    dados
    .filter(...)
    .map(...)
    .reduceByKey(...)
)

não penso apenas:

input
 ↓
transform
 ↓
output

Penso:

Where is the source?
        ↓
What are the dependencies?
        ↓
Where are the shuffle boundaries?
        ↓
What is the lineage?
        ↓
What happens if a partition disappears?
        ↓
How expensive is recomputation?
        ↓
Should something be persisted?
        ↓
Is checkpointing justified?

Essa mudança de mentalidade é muito mais importante do que memorizar APIs.

Próximo artigo

Agora temos uma base sólida sobre:

RDD
 ↓
Partitions
 ↓
Transformations
 ↓
Lineage
 ↓
DAG
 ↓
Stages
 ↓
Tasks
 ↓
Executors
 ↓
Fault Tolerance

Mas existe um tema do material original que merece ser revisitado com bastante cuidado:

variáveis compartilhadas.

Em uma aplicação comum, podemos imaginar:

contador += 1

e esperar que exista apenas um contador.

Mas em Spark temos:

Driver
  +
Executor 1
  +
Executor 2
  +
Executor 3

Então surge uma pergunta:

O que significa "variável compartilhada" em uma aplicação distribuída?

No próximo artigo vamos explorar:

closures;
serialização de funções;
variáveis capturadas;
Driver vs. Executors;
por que alterar uma variável dentro de uma Task não funciona como muitos esperam;
Broadcast Variables;
Accumulators;
quando utilizar cada mecanismo;
armadilhas de side effects;
e como pensar em estado em computação distribuída.

Vamos sair disto:

counter = 0

for item:
    counter += 1

para isto:

              DRIVER
                 │
          serialized closure
        ┌────────┼────────┐
        ▼        ▼        ▼
     Executor Executor Executor
        │        │        │
      Task     Task      Task

E entender por que código aparentemente simples muda completamente quando atravessa máquinas.

← Parte 7: Memória — Executors, Driver, Cache, Spill e OutOfMemory

Próximo: Parte 9 — Variáveis compartilhadas no Apache Spark: Broadcast, Accumulators e Closures

DEV Community: python

Como aprendi Apache Spark — Parte 10: Client Mode vs. Cluster Mode — onde o Spark realmente executa

1. O que acontece quando executamos uma aplicação Spark?

2. Driver, Executor e Cluster Manager não são a mesma coisa

Driver

Executor

Cluster Manager

3. O que é Deployment Mode?

4. Client Mode

5. Por que Client Mode é útil?

6. A máquina cliente faz parte da execução

7. Client Mode e conectividade

8. Cluster Mode

9. Cluster Mode é melhor para produção?

10. Client Mode vs. Cluster Mode

11. Deployment Mode não é Cluster Manager

12. Spark Standalone

13. Spark em YARN

14. YARN Client Mode

15. YARN Cluster Mode

16. Spark em Kubernetes

17. Kubernetes não elimina a arquitetura do Spark

18. E o modo local?

19. O que é spark-submit?

20. Exemplo local com spark-submit

21. Exemplo de submissão para YARN

22. Exemplo de submissão para Kubernetes

23. --master e --deploy-mode

--master

--deploy-mode

24. O que acontece depois do spark-submit?

25. O Driver precisa acessar os dados?

26. O erro clássico de caminhos locais

27. Código local não é necessariamente código distribuído

28. Empacotamento da aplicação

29. Python e ambiente de execução

30. Logs: onde procurar?

Client Mode

Cluster Mode

31. Spark UI

32. Spark History Server

33. Falha de Executor vs. falha de Driver

Executor Failure

Driver Failure

34. Cluster Mode não significa alta disponibilidade automática

35. Orquestração de Jobs Spark

36. Uma arquitetura de produção

37. Um checklist antes de implantar

38. Problemas comuns de implantação

39. O que muda em plataformas gerenciadas?

40. A relação com custos

Aplicação A

Aplicação B

41. O modelo mental completo

42. A principal lição deste capítulo

43. Como penso hoje

Próximo artigo

Wie man zwei Versionen eines PDF-Vertrags in Python Wort für Wort vergleicht

Das Testpaar

Pixel, Zeilen oder Wörter

Zeichen samt Boxen extrahieren

Tokens: Wörter, und dort, wo es keine Leerzeichen gibt, jeweils ein Zeichen

Der Diff

Die Änderungen als Kommentare zurückschreiben

Lange Verträge: autojunk und Klausel für Klausel

Wo das an seine Grenzen kommt

Notas offline con SQLite: guardado idempotente y recuperación tras reiniciar

Notas offline con SQLite: guardado idempotente y recuperación tras reiniciar

El problema y el alcance del ejemplo

Cómo reproducir la idea

Qué demuestra el código

Pruebas recomendadas

Límites que conviene reconocer

Qué aprendemos

Contexto y enlaces del autor

Referencia técnica

Método de bisección con Python: convergencia y condiciones que no debes omitir

Método de bisección con Python: convergencia y condiciones que no debes omitir

El problema y el alcance del ejemplo

Cómo reproducir la idea

19. O que é `spark-submit`?

20. Exemplo local com `spark-submit`

23. `--master` e `--deploy-mode`

`--master`

`--deploy-mode`

24. O que acontece depois do `spark-submit`?