APRENDER. PRATICAR. EVOLUIR.1. Definir o que significa retomar
Num fecho bancário fictício, o incidente terminou do ponto de vista da infraestrutura: o ambiente voltou a responder e o scheduler arrancou. A equipa quer libertar imediatamente todos os jobs pendentes. Antes de o fazer, identifica o estado que cada componente recuperou. O histórico do orquestrador pode representar as 20 h, enquanto uma tabela de destino já contém a publicação das 21 h. Retomar sem comparar estes dois factos pode repetir efeitos e consumir capacidade necessária para o próximo fecho. Prepara uma lista de intervalos, identificadores de publicação, destinos e evidências. Classifica cada intervalo como confirmado, ausente ou por esclarecer. Não reescrevas o significado de um estado desconhecido para facilitar o plano. A investigação deve determinar se faltam dados, se falta apenas a confirmação no histórico ou se existe uma publicação parcial. Cada caso pode exigir uma ação diferente e um responsável diferente. Define também os critérios de saída: dados reconciliados, dependências disponíveis, prazo ainda viável, consumidor autorizado e equipa RUN preparada. Um job terminado constitui apenas uma parte desta evidência. Os exemplos desta aula são originais e fictícios; não representam procedimentos BNP Paribas. O planeador local serve para explorar capacidade e ordem de admissão, sem autorizar uma recuperação real nem reproduzir os schedulers dos serviços cloud.
2. Recuperar o orquestrador sem repetir efeitos
A documentação de Managed Airflow, nas páginas de Cloud Composer, alerta para novas execuções após carregar um snapshot. O histórico recua ao momento capturado. Uma publicação posterior pode continuar no destino, mas deixar de ser conhecida pelo agendamento. A opção catchup=False não elimina todos estes casos, incluindo o exemplo documentado de um DAG diário executado e restaurado no mesmo dia. Num ensaio, cria uma cronologia com quatro acontecimentos: captura, execução, confirmação no destino e carregamento do snapshot. Marca o que cada sistema sabe depois do carregamento. Essa representação torna visível por que razão um retry não deve depender apenas do histórico restaurado. O contrato de publicação pode precisar de um identificador de intervalo estável, de uma verificação do efeito existente e de uma decisão explícita para resultados divergentes. Não inventes uma confirmação para evitar trabalho: conserva evidência suficiente para sustentar a classificação. Revê também o próprio carregamento. O destino precisa de existir, estar num estado compatível e usar uma versão Airflow igual ou posterior à do snapshot. Uma operação parcialmente concluída pode surgir como falhada e ainda ter instalado pacotes ou alterado parte da configuração. Lê o detalhe e inventaria o estado antes de repetir. A conclusão do restauro técnico deve preceder a validação das dependências e a aceitação operacional, com responsáveis identificados em cada passagem.
3. Distinguir capacidade observada de capacidade disponível
Um ensaio rápido não garante um fecho rápido. Em BigQuery, parte dos slots usados pode ter vindo de capacidade ociosa de outras reservas. Quando o proprietário precisa deles, pode recuperá-los. O plano deve distinguir a capacidade própria das oportunidades de empréstimo, sobretudo se o ensaio ocorreu fora do horário de maior concorrência. Regista a carga simultânea que acompanhou cada medição de tempo. A procura de paralelismo de uma consulta também não equivale ao número de slots comprados. Unidades de trabalho podem aguardar capacidade; a espera não se transforma automaticamente em cobrança on-demand extra numa consulta atribuída a uma reserva. Para analisar custo e desempenho, separa procura, capacidade alocada, utilização e duração. Uma única média pode esconder o período exato em que o trabalho crítico ficou bloqueado. O exercício usa units abstratas e durações fixas. Se um job pede uma unidade e demora vinte segundos, aumentar capacity de um para dois não o torna duas vezes mais rápido. Pode permitir outro job em simultâneo. Antes de aplicar esta intuição ao serviço real, mede a concorrência, os limites do destino e o comportamento da consulta. Uma otimização que acelera leitura mas satura a base de destino pode simplesmente deslocar o incidente. Define qual o recurso limitante e qual a evidência que justificaria alterar a capacidade.
4. Ler o contrato do planeador
O ficheiro run.py recebe capacity e até cinquenta jobs independentes. Cada job tem id, priority, releaseAt, duration, units e deadline. Um número de prioridade menor é mais urgente. releaseAt indica o primeiro instante permitido para iniciar. duration inclui todo o trabalho que decidiste representar, incluindo validação se ela for necessária para cumprir o compromisso. O programa não acrescenta automaticamente tempo de aceitação. Em cada instante relevante, liberta primeiro os recursos dos jobs terminados. Ordena os candidatos disponíveis por prioridade, depois deadline e finalmente id. Percorre essa ordem e admite os pedidos que cabem. Um pedido grande que não cabe pode ser ultrapassado por outro menor; não há reserva antecipada de capacidade. Depois avança para a próxima disponibilidade ou conclusão. Uma heap mantém os eventos de conclusão ordenados, tornando a simulação determinística. A política não interrompe trabalho iniciado e não espera deliberadamente por um job crítico futuro. Também não divide pedidos, estima tempos, cria retries ou calcula dependências. Um pedido maior que a capacidade fica em blockedTooLarge; os restantes continuam a ser planeados. Esta escolha permite identificar o impedimento sem esconder os resultados dos jobs viáveis. Os tempos e unidades são inteiros limitados; a validação rejeita campos extra e identificadores repetidos. Uma lista vazia cumpre todos os prazos declarados de forma trivial, o que não demonstra recuperação de qualquer serviço.
5. Executar a fixture e testar uma alternativa
A partir da raiz do projeto, executa python 3 content/labs/pde-capacity-plan/run.py < content/labs/pde-capacity-plan/case.json. O código apresentado nesta aula é o mesmo executável. Não usa rede, credenciais ou serviços cloud. Lê o JSON, calcula o plano em memória e escreve o resultado. Antes de executar, desenha a linha temporal: routine começa em 0, ocupa a única unidade até 10 e critical fica disponível em 1, com duração 1 e deadline 2. Prevê o atraso. A prioridade de critical é maior, mas a unidade está ocupada e não há preempção. O job só começa em 10 e termina em 11. lateJobIds contém critical. O resultado não prova que os prazos sejam impossíveis: esperar até 1, executar critical entre 1 e 2 e depois routine entre 2 e 12 permite cumprir ambos. O programa não procura esse calendário porque admite imediatamente trabalho disponível. Numa cópia da fixture, adia releaseAt de routine para 2 e compara. Explica que alteraste uma condição de admissão para representar uma decisão operacional; não descobriste automaticamente o calendário ótimo. Depois aumenta capacity para 2 na fixture original e observa a concorrência. Acrescenta um job que pede três unidades e verifica blockedTooLarge. Em cada variante, guarda o input e o resultado, identifica qual a hipótese alterada e evita comparar números sem explicar a decisão que os produziu.
6. Investigar o atraso antes de escolher a mitigação
O planeador só calcula consequências das hipóteses fornecidas. No serviço real, uma duração pode mudar porque o input cresceu, uma junção multiplicou linhas, outros jobs consumiram recursos ou o destino ficou mais lento. Para investigar, compara execuções equivalentes e identifica onde o tempo aumentou. Usa o grafo de execução e as métricas do período afetado, em vez de concluir imediatamente que é necessário comprar mais capacidade. Em BigQuery, os insights de desempenho dão pistas distintas. Um aumento de input deve levar à revisão de volumes e filtros. Pressão de shuffle exige observar dados intermédios, operações como JOIN e GROUP BY e sobreposição com outras consultas. Pode fazer sentido reduzir dados antes dessas operações ou separar workloads no tempo. Mede o efeito da mudança e confirma que a transformação continua a produzir o resultado correto. No orquestrador, verifica também o significado de sucesso. A documentação Airflow descreve o caso de uma tarefa folha com all_done que termina bem e pode deixar o DAG Run verde apesar de uma falha intermédia. A limpeza de recursos é útil, mas não deve apagar a falha relevante para a entrega. Define uma verificação explícita das tarefas críticas e dos outputs reconciliados. No relatório de incidente, separa o sinal observado, a hipótese, o teste realizado e o resultado; isso facilita a revisão por outra equipa.
7. Parar processamento sem perder a história dos efeitos
Uma decisão de paragem deve distinguir modo do pipeline, estado observado e efeitos no destino. Em Dataflow, drain aplica-se a streaming e permite concluir dados em buffer enquanto cessa nova ingestão. Não é uma opção de drain para batch. Cancelar pode deixar dados já escritos acessíveis no sink e pode perder trabalho em curso. O pedido de paragem não é, por si, uma confirmação de rollback nem de conclusão. O fecho das janelas merece atenção. Drain pode encerrar uma janela antes do limite temporal habitual e produzir um resultado parcial. Se o novo job escrever outro segmento com o mesmo nome de ficheiro baseado apenas na hora, pode ocorrer colisão no destino. Prepara um exemplo com uma janela horária e uma paragem a meio; identifica os segmentos e a regra que os combina sem sobrescrever dados válidos. A solução depende do contrato do sink e precisa de ensaio próprio. Também não prometas que drain resolve um pipeline bloqueado. Timers que se reagendam indefinidamente podem impedir a conclusão. Recolhe o estado, identifica o comportamento que mantém trabalho pendente e avalia uma correção ou outra forma de paragem com impacto explícito. Comunica a decisão juntamente com o que foi processado, o que permanece por confirmar e o plano para retomar. Preserva a relação entre job, intervalo e artefactos para que a equipa seguinte não tenha de reconstruir tudo durante o incidente.
8. Entregar um plano que o RUN consegue executar
Conclui a aula com um plano de retoma de uma página. Lista os jobs que realmente precisam de executar, as publicações que já existem, as dependências ainda por validar e os compromissos de prazo. Para cada job, indica a origem da estimativa e as condições em que foi medida. Se a estimativa depende de capacidade emprestada ou de um destino sem concorrência, escreve essa condição junto do valor. Anexa a fixture e o resultado do planeador como material de discussão. Explica que units não são slots BigQuery e que a política local não reproduz Airflow. Se o plano local falhar, revê a admissão e as hipóteses; não apresentes o resultado como prova matemática de impossibilidade. Se passar, confirma no ambiente real os recursos, as durações e o efeito dos mecanismos que o modelo não inclui. Uma margem de segurança tem de ser explícita e acordada. Define o ponto de decisão antes de cada publicação: evidência necessária, responsável, alternativa se houver atraso e condição para interromper a retoma. Pode ser aceitável adiar trabalho não crítico ou conservar uma publicação anterior aprovada, desde que o negócio aceite a atualidade e o impacto. Não escondas um atraso conhecido num estado técnico verde. Resume a passagem ao RUN com os identificadores, os sinais de bloqueio e a forma de verificar que uma ação já produziu efeito antes de a repetir.
Preparar uma tentativa e gerir o tempo
Escolhe um dos três simulados e reserva 120 minutos sem interrupções. Cada formulário contém 50 perguntas originais do percurso. Os formulários não partilham perguntas entre si, mas podes reconhecer perguntas das aulas ou de tentativas anteriores. Regista essa familiaridade: recordar a opção correta pode aumentar a percentagem sem demonstrar que sabes resolver uma situação nova. Os 144 segundos por pergunta são uma média para gerir a sessão, não uma duração obrigatória por decisão. Faz uma primeira leitura dos requisitos, responde quando consegues justificar a escolha e assinala as dúvidas para revisão. Evita consumir toda a margem numa pergunta enquanto deixas várias por ler. Antes de comparar alternativas, identifica origem, destino, identidade de execução e fronteira temporal. Num pipeline, o instante de ocorrência do evento pode diferir da publicação, da chegada e do processamento. Num restauro, o estado recuperado do orquestrador pode diferir dos efeitos que já ficaram no destino. Escreve mentalmente a garantia pedida: conservar movimentos válidos, limitar acesso, cumprir uma janela ou recuperar sem repetir um efeito externo. A alternativa adequada deve responder a essa garantia dentro das condições do enunciado. Uma tecnologia familiar não é suficiente para justificar a escolha. Quando forem pedidas duas respostas, seleciona ambas; nesta plataforma, uma seleção incompleta ou com opções a mais não recebe crédito parcial. Cada resposta integralmente correta vale um ponto local, até 50. Esta regra de treino não descreve a classificação oficial.
Separar recuperação, reconciliação e publicação
Considera um caso fictício, fora das perguntas pontuadas. Um pipeline prepara posições para um relatório de fecho. O orquestrador foi restaurado para as 20 h, mas o destino contém resultados publicados às 20 h 15. A aplicação de notificações confirmou que enviou alguns avisos. Às 20 h 30, a equipa recebe autorização para recuperar o serviço. O plano propõe repetir tudo desde as 20 h e usar o estado verde do DAG como aceitação. Começa por separar três perguntas: que dados foram calculados, que resultados foram publicados e que efeitos externos ocorreram? A autorização permite executar o plano aprovado; não demonstra que estes estados estejam reconciliados. Uma resposta fundamentada identifica a população e a fronteira de comparação. Confronta as chaves e os valores relevantes no destino com a referência aprovada para o mesmo instante lógico. Um total global igual pode esconder movimentos atribuídos à carteira errada. Conserva a evidência dos avisos já enviados e define como evitar a repetição antes de reativar esse efeito. Calcula a margem disponível para o trabalho necessário, considerando concorrência e capacidade observada, em vez de assumir que a duração do ensaio é garantida. Valida também o acesso com a identidade que irá consumir o resultado. Se a reconciliação não terminar antes do comité, comunica a lacuna, o impacto e o responsável pela decisão de adiar ou limitar a publicação. Nos simulados, aplica esta separação sem acrescentar requisitos que o enunciado não contém. Se a pergunta pede a próxima verificação, uma solução arquitetural completa pode ultrapassar o que a evidência permite decidir. Se já existe uma divergência concreta, mudar o relatório de estado não corrige os dados. Procura a relação entre sintoma, causa provável, ação e evidência esperada.
Converter erros num plano de prática
Depois da tentativa, revê a explicação da resposta correta e de cada alternativa rejeitada. Para cada erro, regista o domínio, a tarefa, o pressuposto que falhou e a prática seguinte. Evita escrever apenas o nome do produto. Por exemplo, se confundiste a identidade do utilizador com a do worker, desenha quem lança o job e quem lê o objeto; identifica a permissão necessária em cada ligação. Se confundiste resultado acumulado com incremento, constrói dois resultados sucessivos e calcula o efeito das duas interpretações no consumidor. Se aceitaste um benchmark com dados em cache, define uma comparação que consiga separar reutilização de resultados e execução do SQL. Volta à aula e à referência correspondente. Quando existir um exercício local, executa-o com o caso válido e com uma condição que viole o contrato. Explica o resultado antes de consultar a solução. Esses exercícios usam modelos delimitados e dados fictícios; passar um deles não valida uma configuração Google Cloud. Num ambiente de prática apropriado, identifica separadamente a observação que seria necessária para confirmar o comportamento real. Compara depois os tipos de erro entre formulários. Uma melhoria útil é conseguir justificar por que a alternativa anterior falhava e quando poderia ser adequada. Cada formulário representa as 19 tarefas do guia e aproxima os pesos dos cinco domínios, com 11, 12, 10, 8 e 9 perguntas. Isso não demonstra cobertura de todos os subtópicos nem dificuldade psicométrica equivalente. PT-PT é uma adaptação da DR; os idiomas oficiais publicados para este exame são inglês e japonês. A percentagem local não tem limiar oficial de aprovação, não prevê o resultado do exame e não atribui certificação. Usa-a para orientar estudo e prática, mantendo a revisão especializada independente como trabalho pendente.
"""Bounded fictional, non-preemptive scheduler. Not a cloud scheduler or optimizer."""
import heapq
import json
import re
import sys
def keys(value, expected):
if not isinstance(value, dict) or set(value) != set(expected):
raise ValueError('Unexpected object fields')
def integer(value, lo, hi):
if type(value) is not int or not lo <= value <= hi:
raise ValueError('Integer outside contract')
def plan(data):
keys(data, ['capacity', 'jobs'])
capacity = data['capacity']; integer(capacity, 1, 100)
if not isinstance(data['jobs'], list) or len(data['jobs']) > 50:
raise ValueError('Expected at most50jobs')
seen = set()
for job in data['jobs']:
keys(job, ['id', 'priority', 'releaseAt', 'duration', 'units', 'deadline'])
if not isinstance(job['id'], str) or re.fullmatch(r'[A-Za-z0-9_-]{1,48}', job['id']) is None:
raise ValueError('Invalid job identifier')
if job['id'] in seen:
raise ValueError('Duplicate job identifier')
seen.add(job['id'])
for field, lo, hi in [('priority',0,10),('releaseAt',0,86400),
('duration',1,86400),('units',1,100),('deadline',0,172800)]:
integer(job[field],lo,hi)
blocked = sorted(j['id'] for j in data['jobs'] if j['units'] > capacity)
pending = [dict(j) for j in data['jobs'] if j['units'] <= capacity]
running = []; scheduled = []; now = 0; free = capacity; peak = 0
while pending or running:
while running and running[0][0] <= now:
_, _, units = heapq.heappop(running); free += units
ready = sorted((j for j in pending if j['releaseAt'] <= now),
key=lambda j:(j['priority'],j['deadline'],j['id']))
for job in ready:
if job['units'] > free:
continue
finish = now + job['duration']; free -= job['units']
heapq.heappush(running,(finish,job['id'],job['units']))
scheduled.append(dict(id=job['id'],start=now,finish=finish,
units=job['units'],wait=now-job['releaseAt'],
deadline=job['deadline'],deadlineMet=finish<=job['deadline']))
pending.remove(job); peak=max(peak,capacity-free)
events = [j['releaseAt'] for j in pending if j['releaseAt'] > now]
if running:
events.append(running[0][0])
if events:
now = min(events)
elif pending:
raise AssertionError('A fitting pending job must eventually be admitted')
scheduled.sort(key=lambda j:j['id'])
return dict(schedule=scheduled,blockedTooLarge=blocked,
lateJobIds=sorted(j['id'] for j in scheduled if not j['deadlineMet']),
peakUnits=peak,makespan=max((j['finish'] for j in scheduled),default=0),
allDeclaredDeadlinesMet=not blocked and all(j['deadlineMet'] for j in scheduled),
optimalityProven=False,cloudScheduleValidated=False,
runtimeEstimatesValidated=False,productionRecoveryApproved=False,
policy='ready priority,deadline,id; admit fitting jobs; no preemption or future reservation')
def unique_object(pairs):
obj={}
for k,v in pairs:
if k in obj:raise ValueError('Duplicate JSON key')
obj[k]=v
return obj
if __name__=='__main__':
try:
raw=sys.stdin.buffer.read(2000001)
if len(raw)>2000000:raise ValueError('Input exceeds2MB')
print(json.dumps(plan(json.loads(raw,object_pairs_hook=unique_object)),sort_keys=True))
except (ValueError,TypeError,UnicodeError,RecursionError) as exc:
print(json.dumps({'error':str(exc)}),file=sys.stderr);sys.exit(2)
Fecho fictício: o histórico restaurado ignora uma publicação existente e um job de rotina ocupa a capacidade antes da chegada do job crítico.
Armadilhas comuns
Repetir efeitos após restauro; prometer capacidade emprestada; confundir prioridade com preempção; assumir optimalidade do planeador; aceitar cleanup verde como prova de entrega; ignorar janelas parciais.
Tópicos relacionados: Histórico e idempotência · Capacidade e prazos · Paragem de streaming
Reconcilia antes de reexecutar, explicita a política de admissão e observa os efeitos e a conclusão antes de confirmar recuperação.
Referência: Professional Data Engineer standard exam guide · Current linked standard guide (document title v4.2); edition date unconfirmed (2026-09-30 inspection)