Microbatch, NRT ou RTM no DB

Saudações, pessoal! Tudo em riba?

Hoje iremos falar sobre um assunto hypado, mas raramente analisado com a profundidade que merece e com a ponderação dedivda dos tradeoffs envolvidos. Estamos falando da escolha da arquitetura para modelos de AI/ML que precisam intervir extremamente rápido nas operações financeiras do negócio, ou os modelos em (quase-)tempo real. Vou ilustrar a maioria dos argumentos deste artgigo com prevenção a fraudes financeiras, mas o raciocínio se generaliza bem para qualquer modelo que tenha requisitos de baixa latência, ok? Adeque conforme o seu caso de uso :) Bora lá?

Sábias palavras, Dwight

Índice

· Contexto · Velocidade e Simplicidade: um Tradeoff · Os Três Regimes ∘ 1. Microbatch (Spark Puro Triggado) ∘ 2. Near Real-Time (NRT) via Lakebase ∘ 3. Real-Time Mode (RTM) · One Table to Rule Them All · Cenário de Referência do Databricks ∘ Anatomia do pipeline: cinco estágios ∘ E ML nisso tudo? · Como decidir a sua arquitetura? · Considerações Finais · Referências · Uso Responsável de IA

Contexto

No mercado financeiro, uma fraude costuma se desenrolar na casa dos (mili-)segundos. Um número de cartão roubado por um fraudador alimenta dezenas de compras em poucos minutos e, depois que as transações são de fato efetuadas e liquidadas, chorar sobre o leite derramado não ajuda muita coisa. Conforme o tempo passa, recuperar o dinheiro vai ficando cada vez mais burocrático e mais difícil. Tão difícil a ponto de muitas vezes as empresas assumirem o prejuízo financeiro como fundo perdido só para evitar um desgaste maior com as partes interessadas.

Ah, Gustavo, mas essa discussão está muito abstrata. Qual é o tamanho do buraco que estamos falando? Você tem uma estimativa de quanto a gente costuma perder nas transações fraudulentas? Então, segundo o Nilson Report, as perdas globais somente via fraude com cartão de crédito somaram mais de US$ 33,41 bilhões em 2024. Um número realmente assustador, não é mesmo?

OMG! Quanto dinheiro na mão dos cibercriminosos.

Apesar das cifras impressionantes, vale notar, contudo, ele cai 1,2% frente ao relatório da mesma empresa de 2023. E essa foi a primeira queda em vários anos, atribuída justamente ao amadurecimento dos modelos de detecção de fraude. Ou seja, felizmente, em termos percentuais, o valor de fraudes financeiras via cartão de crédito está diminuindo. Ainda assim, a projeção é que até 2030 tenhamos US$ 41,06 bilhões perdidos via fraude, acompanhando o crescimento do volume financeiro transacionado em plataformas digitais.

Qual é o big deal, então? O ponto é que na eterna briga de gato e rato entre fraudadores e quem trabalha para evitar que as fraudes aconteçam, a maior parte das instituições financeiras já tem algum modelo de IA/ML para mitigar as fraudes. Por que ainda assim este número continua tão expressivo? Pois é, pequeno gafanhoto… Na conjectura atual, o gargalo raramente será a capacidade de detecção do modelo em si. Existem centenas de soluções antifraude disponíveis no mercado. A grande questão costuma ser se este modelo consegue intervir rápido o suficiente, antes de o dinheiro sair da conta e o leite ser derramado.

A eterna briga de gato e rato entre hackers criminosos e os hackers de segurança da informação

O problema, portanto, deixa de ser exclusivo da modelagem dos times de ML e DS e passa a ser também questão de Engenharia de ML e de Plataforma. Escrevo esse texto no meio de uma migração de infraestrutura feita exatamente para atender a um requisito de velocidade das features de um modelo antifraude. O que trago aqui é menos uma receita de bolo de como fazer as coisas funcionarem e mais um norte de como escolher seu ponto de parada no espectro de latência, entre o “rápido o suficiente para o seu caso de uso” e “o mais rápido que a plataforma permite”.

Velocidade e Simplicidade: um Tradeoff

A discussão de streaming para a prevenção de fraudes costuma ser apresentada como uma balança com dois pratinhos. De um lado a velocidade, do outro a simplicidade. O tradeoff entre ambos costuma ser explícito nas soluções dos times de arquitetura e engenharia.

O equilíbrio frágil entre velocidade e simplicidade

Do lado da velocidade, sabemos que uma transação fraudulenta precisa ser avaliada em algumas dezenas ou centenas de milissegundos. Quadrilhas costumam testar credenciais com microtransações em sequência gerando picos de requisições, explorando anomalias geográficas com mudança de IP ou testando os limites da transação. Neste contexto, o modelo deve ser altamente responsivo e facilmente monitorável em tempo real.

Do outro lado, temos a simplicidade. O time que constrói os modelos de IA/ML, geralmente quer experimentar, construir, treinar, versionar e monitorar o modelo em uma única plataforma, com governança unificada, facilidade de uso, etc. Ninguém quer manter uma stack de streaming adicional complexa, totalmente apartada do fluxo de desenvolvimento, só para dar conta da etapa final na inferência do modelo.

Historicamente, atender o requisito de latência significava colocar uma engine especializada acoplada ao seu processamento Spark. Tipicamente o Apache Flink costumava ser esta engine e trazia um fluxo conforme abaixo:

Fluxo típico de uma arquitetura Apache Flink. Fonte: https://www.linkedin.com/pulse/introduction-apache-flink-shanoj-kumar-v/

O resultado, já conhecido pela grande maioria dos desenvolvedores, é que temos dois sistemas rodando em paralelo, o Spark cuidando do treino e do batch, o Flink cuidando do scoring da inferência em tempo real. Cada um com sua própria lógica de deploy, cada um com o seu próprio ciclo de release, cada um com sua própria linguagem ou paradigma de programação.

E como as duas engines precisam enxergar, pelo menos em parte, o mesmo dado em momentos diferentes (treino e inferência), duplicamos informações para diferentes padrões de consumo de dados. Nem precisamos dizer que sincronizar isso, sem gerar desvios e inconsistências entre treino e inferência costuma virar um projeto de MLOps à parte, não é mesmo?

Essa duplicação de infraestrutura tem efeito cascata no resto da operação. Primeiro, a governança fica fragmentada, porque agora você tem duas fontes de verdade para auditar, versionar e explicar para o compliance quando alguém perguntar “por que o modelo decidiu isso aqui?”. Segundo, você acabou de criar uma segunda escala de plantonistas, já que o Flink costuma quebrar na madrugada de um jeito diferente do Spark, exigindo pessoas com conhecimento específico para debugar. Terceiro, o saldo final costuma ser um time gastando mais tempo administrando pipeline, lidando com questões de backpressure (o que fazer quando quem consome os dados não dá conta do ritmo de quem produz?), checkpoint (se o pipeline cair, ele retoma de onde parou?) e watermarking (qual é o limite de espera por dados atrasados antes de fechar uma janela de agregação?), do que efetivamente melhorando o sinal do modelo que deveria bloquear transações suspeitas.

Diante deste cenário de atrito operacional, cabe perguntar se a escolha binária que gerou tudo isso era realmente necessária. Apresentar velocidade e simplicidade como uma bifurcação em nosso tradeoff esconde outros conjuntos de soluções intermediárias em termos de custo e complexidade operacional. A pergunta útil, então, não é simplesmente “vou de streaming ou batch?”. Na real, a pergunta é: até onde nesse espectro o meu requisito de velocidade me obriga a ir, e quanto custa, financeira e operacionalmente, cada degrau adicional?

Os Três Regimes

Os três regimes que abordaremos são três pontos de parada que você deve avaliar ao seu aproximar das suas resposta em tempo real, cada um com o seu próprio custo e vocação. Vamos a eles.

1. Microbatch (Spark Puro Triggado)

O que popularmense se chama de microbatch é o Structured Streaming clássico, o carro-chefe do Spark que você provavelmente já conhece. Você define um trigger (pode ser um intervalo fixo, tipo “a cada 2 minutos”), o pipeline processa em lotes, e a latência vive na casa de segundos a minutos, dependendo de quão apertado você configura esse intervalo de trigger. O custo é baixo porque o cluster não precisa ficar de prontidão o tempo todo esperando evento por evento: ele acorda, processa o lote, e pode até desligar entre uma execução e outra.

Fluxo de Microbatch Padrão usando Spark

O tuning é simples (poucos knobs além do tamanho do trigger e do particionamento) e todo o ferramental do Spark que você já domina continua valendo sem adaptação nenhuma, ou seja, e monitoramento via Spark UI.

O microbatch costuma servir bem para features de janela longa. Alguns exemplos: gasto médio do portador do cartão nos últimos 30 dias, dispersão geográfica histórica das transações, perfil de merchant, taxa de chargeback acumulada por categoria, etc. Em síntese, todas as features que agregam um volume grande de histórico. O ponto aqui é que o volume grande de histórico não vira outro volume grande de histórico em três segundos. O gasto médio mensal de um cliente não muda de forma perceptível entre um lote e o próximo, então pagar muito mais pelo frescor de sub-segundo nelas é desperdício puro, você estaria comprando velocidade para um número que, na prática, anda no ritmo de um calendário, não de um cronômetro. Ninguém precisa saber em tempo real que o gasto médio mensal do cliente variou 0,1%.

2. Near Real-Time (NRT) via Lakebase

Esse aqui é o caminho do meio declarativo. Usamos Streaming Table para ingestão, Materialized View para a camada de agregação e Synced Table do Lakebase para o serving online. A plataforma do Databricks cuida da sincronização por trás dos panos, via um pipeline Lakeflow gerenciado, então você não precisa ficar orquestrando isso na mão.

Arquitetura Genérica de Fluxo de Streaming -> Streaming Table -> Materialized View (só falta adicionar a Synced Table da feature)

O que determina o frescor dos dados nessa opção é o modo de sincronização escolhido. Essencialmente, são três:

• Snapshot: refresh completo, sob demanda ou agendado. O mais simples dos três, e o único modo disponível quando a origem é uma view.
• Triggered: aplica apenas as mudanças incrementais quando o pipeline é executado. É o meio de caminho entre custo e latência.
• Continuous: o pipeline roda continuamente, aplicando mudanças à medida que chegam, com um piso de 15 segundos entre atualizações. É o de menor latência do trio, mas também o de maior custo de compute, e ainda assim não chega ao nível de sub-segundo, para isso existe o RTM, que a gente vê na próxima seção.

Antes de desenhar sua arquitetura em cima do NRT, contudo, vale conhecer algumas restrições que costumam aparecer um pouco tarde demais no design de solução:

• Triggered e Continuous exigem Change Data Feed habilitado na tabela de origem. Mais sobre isso aqui.
• Apenas mudanças aditivas de schema se propagam nesses dois modos. Renomear coluna ou trocar seu tipo não passará, infelizmente.
• Chave primária duplicada na origem quebra o pipeline, a menos que você configure deduplicação por timeseries key. Contudo, esse dedup acaba tendo um alto custo de performance.
• A sincronização é sempre unidirecional, do Unity Catalog para o Lakebase. A tabela no Postgres é sempre read-only.
• O throughput de escrita varia bastante conforme a modalidade: no Provisioned, Continuous e Triggered sustentam cerca de 1.200 linhas por segundo por Capacity Unit (CU), contra até 15.000 no Snapshot. No Autoscaling, os números caem ainda mais.

Esse último ponto, o de throughput, é o que eu recomendo calcular primeiro, antes de tomar qualquer outra decisão de design. Se o seu volume de eventos por segundo dividido pela taxa por CU der um número de CUs que não fecha no orçamento final, a decisão de arquitetura meio que já está tomada (mesmo que não tenha sido você que tenha tomado).

Ensinamento de um velho marceneiro. Kkkkk

Um exemplo rápido para dar corpo a isso: imagine que seu modelo de fraude precisa dar conta de 5.000 transações por segundo no pico (Black Friday, campanha de fim de ano, o que seja). No Autoscaling, com os ~150 linhas/segundo por CU do modo Continuous, isso significa algo em torno de 34 CUs só para não ficar para trás da esteira de eventos. No Provisioned, com os ~1.200 linhas/segundo por CU, o mesmo volume cai para umas 5 CUs. É uma diferença de quase sete vezes na conta final, e ela nasce inteira da escolha entre Autoscaling e Provisioned, antes mesmo de você pensar em qual sync mode faz mais sentido. Contudo, vale rodar essa conta com o seu volume real de pico (não a média) antes de comprometer a arquitetura com qualquer um dos dois.

Fazendo a conta de CUs Provisioned e Autoscaling

Do lado da leitura, a coisa é mais tranquila: o Lakebase entrega consultas na casa de sub-10 ms a partir de qualquer cliente Postgres padrão, o que é mais do que suficiente para feature serving dos seus modelos de IA/ML.

3. Real-Time Mode (RTM)

O RTM é uma evolução da engine do Spark Structured Streaming que habilita processamento sub-segundo nativamente, sem precisar sair do ecossistema Spark. Já está em GA (Generally Available, ou seja, saiu do estágio de preview) na Databricks, disponível para uso nas três clouds (AWS, GCP e Azure).

Comparações entre DB RTM e Apache Flink. Fonte: https://www.databricks.com/blog/breaking-microbatch-barrier-architecture-apache-spark-real-time-mode

Algumas informações que foram disponibilizadas pela Databricks, me chamaram bastante atenção:

• Solução até 92% mais rápido que o Apache Flink em workloads de transformação stateless, enriquecimento via join e agregação.
• O cliente Coinbase, elencado como caso de uso, usa RTM para computar mais de 250 features de ML, com latências P99 de processamento abaixo de 100 ms.
• No teste end-to-end do accelerator de fraude, P50 abaixo de 40 ms e P99 entre 215 e 392 ms.

Para mim, pessoalmente, o mais interessante do RTM nem é tanto o argumento da latência (super forte) mas o da simplicidade operacional. A ideia central é que o RTM vive dentro da engine que você já roda diariamente, e não ao lado dela em um fluxo paralelo. Isso traz três consequências práticas:

1. Em primeiro lugar, não temos drift lógico. As regras de scoring, o feature engineering e o preprocessing existem uma única vez. O mesmo código que roda no pipeline offline de treino é o que roda no scoring online, bastando habilitar um parâmetro.
2. Segundo, temos uma superfície operacional só. Usamos Spark UI para monitoramento de cluster, jobs, alertas, tudo normalmente. Todo o ferramental que o seu time já usa no dia a dia continua valendo, sem precisar aprender a operar uma engine nova.
3. Terceiro, reversibilidade. Se a conta ficou muito cara, voltar para um trigger mais lento é uma mudança de uma linha na direção oposta, sem tuning manual de paralelismo nem orquestração de shutdown e restart.

Na prática, no código do modelo, mudar de batch para real time é a diferença entre isso:

.trigger(processingTime="30 seconds")

e isso:

.trigger(realTime="5 minutes")

O mesmo código de transformação, a mesma query, só o trigger muda.

Vale um adendo só, para quem ficou curioso: esse “5 minutes” no realTime não é a frequência de processamento (que passa a ser contínua), é o intervalo de checkpoint. Ainda assim, do ponto de vista de quem mantém o pipeline, é literalmente uma linha de configuração indo e voltando para trocar o regime de operação.

Essa reversibilidade, aliás, é o que eu acho mais subestimado no anúncio do RTM (talvez porque eles não queiram que você volte a gastar pouco). Mas ele muda drasticamente o cálculo de risco da adoção da solução.

One Table to Rule Them All

Sumarizando tudo o que foi discutido até aqui em uma tabela:

[embed]

Cenário de Referência do Databricks

O Solution Accelerator disponibilizado pela Databricks implementa o caso completo para transações de cartão de crédito, no degrau mais alto do espectro visto: o do Spark RTM. Eu acho que vale darmos uma olhada como referência prática de arquitetura mesmo que você não vá clonar o repo.

No exemplo, as transações chegam de um message broker (Kafka, Kinesis). Cada evento carrega ID do cartão, valor, categoria do merchant, coordenadas geográficas e canal (online ou point of sale). O sistema avalia cada transação contra múltiplos sinais, atribui um score de risco e roteia para um de três desfechos: aprovada, sinalizada para revisão manual ou bloqueada. Tudo isso em menos de 300 ms.

A arquitetura de alto nível tem quatro componentes:

Fluxograma 1. Fonte: https://www.databricks.com/blog/how-build-real-time-fraud-detection-using-spark-real-time-mode-and-lakebase

Explicando brevemente cada caixinha:

• Kafka (source): faz o landing dos eventos raw.
• Spark RTM: processa o fluxo de streaming.
• Kafka / Lakebase: camada intermediária de baixa latência. O resultado pode voltar para o Kafka em algum tópico ou ir para o Lakebase, dependendo de quem consome.
• Databricks Apps: camada de aplicação para o usuário final, como um time de CCF (Combate a Crimes Financeiros).

Anatomia do pipeline: cinco estágios

Com a arquitetura RTM já definida, dá para pensar na arquitetura da solução em si, ainda na versão mais embrionária, só com hard rules rodando em uma única plataforma. O pipeline roda em cinco estágios contínuos:

Pipeline Baseado em Hard Rules

• Parsing. Pega o JSON cru do Kafka e estrutura em colunas tipadas.
• Velocity tracking. Usa o operador transformWithState, do Spark, para transformações stateful. No modelo de fraudes de cartão, isso significa que o pipeline mantém estado por cartão ao longo do stream. Quantas transações esse cartão fez nos últimos 60 segundos, por exemplo? Um cartão que dispara cinco transações em um minuto está exibindo comportamento clássico de card testing. Sem esse estado, cada transação seria avaliada como se fosse a primeira daquele cartão, perdendo justamente o padrão que caracteriza a fraude.
• Enrichment. Adiciona contexto de perfil de risco e dados do portador. É categoria de alto risco (gift card, joalheria)? Esse portador normalmente gasta R$ 50 ou R$ 5.000?
• Scoring. Combina cinco sinais ponderados (velocity, anomalia geográfica, desvio de valor, risco da categoria do merchant e risco do país) em um score de 0 a 100. Cada sinal é computado por uma UDF dedicada, e os pesos são configuráveis. O resultado é um score explicável em que dá para ver qual sinal contribuiu, e quanto.
• Routing. A decisão final. A transação é classificada como aprovada, sinalizada ou bloqueada, e escrita no tópico Kafka correspondente.

E ML nisso tudo?

Detecção baseada só em regras estáticas produz sistemas auditáveis e frágeis ao mesmo tempo. Nas hard rules, os thresholds costumam ser arbitrários: por que cinco transações em 60 segundos é suspeito? Por que não quatro ou seis? E, como não há aprendizado, o sistema nunca melhora com as decisões passadas. O upgrade para ML introduz duas peças adicionais:

Adicionando o Modelo

1. Lakebase como online serving layer. A implementação do accelerator de referência usa o foreach sink do Structured Streaming com um writer customizado, fazendo upsert direto nas tabelas do Lakebase. Ou seja, o desenvolvedor controla manualmente a conexão, o batch e a semântica de escrita. Nós preferimos uma abordagem mais declarativa e de Plataforma, encadeando Streaming Table, Materialized View e Synced Table via Lakeflow. A troca ao fazer isso é que perdemos controle fino sobre o momento exato da escrita, mas ganhamos menos infraestrutura para manter e lineage mais automático no Unity Catalog, sem precisar instrumentar nada manualmente.
2. MLflow para treino e serving. no exemplo do DB, um classificador Random Forest é treinado em dados históricos rotulados, com MLflow cuidando do experiment tracking e do versionamento. O pulo do gato é que o modelo treinado é carregado como uma Spark UDF e aplicado a cada transação dentro do próprio pipeline de streaming. Não há chamada HTTP para um endpoint de serving, não há hop de rede, não há serviço separado para escalar, o modelo roda no mesmo executor que já está processando o stream. Só que essa abordagem não serve para todo tipo de solução. Por exemplo, um modelo que dependa de GPU para inferência não cabe num executor Spark comum, e nesse caso um endpoint de model serving dedicado, com o hardware certo por trás, ainda é o caminho certo.

Combinado com as features vivas do Lakebase, o modelo de ML aqui neste exemplo captura relações não lineares entre sinais que regras duras não conseguem expressar, e melhora conforme novos dados rotulados aparecem. Com o app de monitoramento, a demo do DB se encerra.

Como decidir a sua arquitetura?

O erro que as pessoas costumam cometer com mais frequência é escolher o degrau de latência pela capacidade da plataforma de ML, não pelo requisito do modelo em si. A plataforma passou a suportar sub-300 ms, então isso vira meta, mesmo que signifique investir muito mais grana para pouco retorno.

Como assim?

Como decidir, então, na prática? Uma sequência de passos que ajuda a escolher entre Microbatch, NRT e RTM:

• Meça recall como função do orçamento de latência. Na prática, isso é um experimento offline: pegue seu dataset de treino e simule diferentes frescores de feature (recompute velocity como se ela fosse atualizada a cada 30 segundos, depois a cada 5, depois a cada 300 ms). Veja como o recall do modelo se comporta em cada cenário. Quanto de fraude você pega com frescor de 30 segundos? De 5? De 300 ms? Plote isso como curva. Se ela achatar em 3 segundos, ou seja, se ir de 3 segundos para 300 ms não pegar fraude adicional nenhuma, é sinal de despesa sem retorno.
• Separe as features por sensibilidade temporal. Velocity de 60 segundos e gasto médio de 30 dias mudam em escalas de tempo completamente diferentes, e forçar as duas a viverem na mesma pipeline de latência mínima é pagar caro por frescor que a segunda feature nunca vai usar. Na prática, seu pipeline de RTM pode processar só as features realmente sensíveis ao tempo (velocity, geolocalização), enquanto o resto (histórico de 30 dias, perfil de merchant) continua vindo de um job bem mais barato, e as duas se encontram só na hora do scoring.
• Calcule o throughput antes do desenho. A conta é simples: volume de eventos por segundo dividido pela taxa de escrita por CU (lembra do exemplo lá em cima, com ~150 linhas/segundo por CU no Autoscaling e ~1.200 no Provisioned?). Se o seu pico é de 5.000 TPS e isso resulta em um número de CUs que não fecha no orçamento, você já sabe que a solução está fora de cogitação, e economiza o tempo que gastaria desenhando uma arquitetura inviável.
• Meça o end-to-end, não o pipeline. O P99 de 392 ms do benchmark que citei antes é só o processamento dentro do Spark. Na vida real, entre o evento acontecer e a decisão chegar em quem vai bloquear a transação, existe rede (o evento saindo do ponto de venda até o Kafka), a camada de decisão (aplicar a política de negócio em cima do score) e o retry ocasional quando algo falha no meio do caminho. Some tudo isso e o SLA real pode estourar mesmo com um pipeline de streaming rapidíssimo. O número que importa para o negócio é o end-to-end, medido da perspectiva do fluxo transacional completo, não o que aparece isolado na Spark UI.
• Precifique o cluster sempre ligado. RTM exige um cluster dedicado rodando continuamente, mesmo nos horários de menor movimento, bem diferente do Microbatch, que só consome compute quando o job roda. Antes de adotar, vale fazer a conta de breakeven: quanto custa esse cluster ligado o mês inteiro, contra quanto em fraude você espera evitar ao ganhar aqueles milissegundos a mais de velocidade?

Considerações Finais

Recapitulando nosso espectro de soluções próximas do tempo real, temos três degraus: Microbatch, NRT via Lakebase e RTM (Spark Structured Streaming). Vimos que cada um traz seu preço em latência, custo e complexidade operacional, e a escolha entre eles não deveria nascer de “qual é o mais rápido que a nossa plataforma permite”, e sim das características da arquitetura e dos itens que vimos acima.

Dito isso, dois pontos merecem atenção independentemente do degrau em que você esteja. Primeiro, o train-serving skew não desaparece só porque você está escrevendo tudo em Spark e o código de feature engineering passou a ser o mesmo nos dois lados. A forma como os dados são tratados nas bordas (janela de agregação, valor ausente, corte temporal do dataset de treino) ainda pode divergir. Lembre-se: isso é uma decisão de cultura em engenharia de dados, não só de arquitetura.

Segundo, lock-in com Databricks é evidente no design de solução aqui proposto: Lakebase, Unity Catalog, MLflow gerenciado e Databricks Apps são quatro pontos de acoplamento com a plataforma. Este foi um trade-off legítimo e reconhecido pelo time. Trocamos agnosticismo de plataforma e portabilidade por velocidade de entrega, familiaridade dos funcionários com a stack e por não precisar manter esse ferramental por conta própria, já que ele vem gerenciado. Se amanhã, contudo, a conta do RTM não fechar mais, sair da Databricks seria bem mais caro do que descer um degrau dentro dela. Não é um problema per se, contanto que todos que importam estejam na mesa quando a decisão é tomada. Os princípios aqui explicados, contudo, têm equivalentes em outras plataformas. Veja aquilo que faz mais sentido para o seu contexto!

É isso, galera. Agradeço a tod@s pela leitura atenta. Espero que tenha feito sentido! Fiquem bem, até logo… e obrigado pelos peixes!

Referências

• Card Fraud Losses Worldwide 2024, Nilson Report
• Introduction to Apache Flink, Shanoj Kumar V
• Lakebase, Databricks
• Serve lakehouse data with synced tables, documentação Databricks
• Announcing General Availability of Real-Time Mode for Apache Spark Structured Streaming on Databricks
• Real-Time Mode: ultra low latency streaming com APIs do Spark
• Caso Coinbase, Databricks Customers
• How to Build Real-Time Fraud Detection using Spark Real-Time Mode and Lakebase, Databricks Blog
• Repositório do Solution Accelerator, GitHub

Uso Responsável de IA

Este texto foi escrito com apoio de IA em várias etapas: revisão de fluidez e clareza dos parágrafos, sugestões de transição entre seções, formatação de tabelas e listas, e fact-checking dos números técnicos citados (throughput do Lakebase, latências do RTM, comportamento dos modos de sincronização) contra a documentação oficial da Databricks e o repositório do Solution Accelerator no GitHub.

O raciocínio, as decisões de arquitetura, os cinco critérios da seção “Como decidir a sua arquitetura” e as opiniões expressas ao longo do texto (como a de que reversibilidade é o ponto mais subestimado do RTM) são meus, fruto da experiência de estar no meio dessa migração de infraestrutura enquanto escrevo. A IA ajudou a destravar frase, não a pensar o problema.