<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Arquitetura on Wiliam Rosa | Lakehouse, Dados &amp; IA</title>
    <link>https://wiliamrosa.github.io/tags/arquitetura/</link>
    <description>Recent content in Arquitetura on Wiliam Rosa | Lakehouse, Dados &amp; IA</description>
    <image>
      <title>Wiliam Rosa | Lakehouse, Dados &amp; IA</title>
      <url>https://wiliamrosa.github.io/images/wiliam-rosa-blog-og.png</url>
      <link>https://wiliamrosa.github.io/images/wiliam-rosa-blog-og.png</link>
    </image>
    <generator>Hugo</generator>
    <language>pt-br</language>
    <lastBuildDate>Thu, 10 Sep 2026 15:00:00 -0300</lastBuildDate>
    <atom:link href="https://wiliamrosa.github.io/tags/arquitetura/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>A lacuna entre aplicações e analytics, e como o Lakebase a resolve</title>
      <link>https://wiliamrosa.github.io/articles/lakebase-lacuna-aplicacoes-analytics/</link>
      <pubDate>Thu, 10 Sep 2026 15:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/articles/lakebase-lacuna-aplicacoes-analytics/</guid>
      <description>Lakebase é um Postgres totalmente gerenciado e nativo da Databricks Data Intelligence Platform, pensado pra unificar workload transacional e analítico com governança única via Unity Catalog, sincronização bidirecional e recursos como autoscaling, scale-to-zero e database branching.</description>
    </item>
    <item>
      <title>Lakebase Postgres decide sozinho quando trocar de tamanho de máquina, usando HyperLogLog</title>
      <link>https://wiliamrosa.github.io/posts/lakebase-postgres-autoscaling-hyperloglog/</link>
      <pubDate>Tue, 01 Sep 2026 10:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/posts/lakebase-postgres-autoscaling-hyperloglog/</guid>
      <description>A Databricks detalhou como o Lakebase Postgres faz autoscaling automático de VM sem derrubar conexão, combinando uso de CPU, uso de memória e uma estimativa de working set feita com uma variante de HyperLogLog sensível a tempo.</description>
    </item>
    <item>
      <title>Lakebase Postgres: por que o banco transacional da era dos agentes começa pelo object storage</title>
      <link>https://wiliamrosa.github.io/posts/databricks-lakebase-postgres-arquitetura-agentes/</link>
      <pubDate>Tue, 01 Sep 2026 00:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/posts/databricks-lakebase-postgres-arquitetura-agentes/</guid>
      <description>A Databricks anunciou os detalhes de arquitetura do Lakebase Postgres. Minha leitura sobre por que separar compute e armazenamento pode ser o passo que faltava para bancos operacionais aguentarem cargas geradas por agentes.</description>
    </item>
    <item>
      <title>Databricks Apps ou Model Serving pra hospedar seu agente? A resposta depende de três coisas</title>
      <link>https://wiliamrosa.github.io/posts/databricks-apps-model-serving-agentes-ia/</link>
      <pubDate>Sun, 30 Aug 2026 09:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/posts/databricks-apps-model-serving-agentes-ia/</guid>
      <description>Databricks Apps virou o host recomendado pra agente novo, mas Model Serving ainda vence em cenário de baixo custo e alta escala, e a diferença de timeout entre os dois muda qual opção funciona pra que tipo de agente.</description>
    </item>
    <item>
      <title>O DNA do Neon Postgres dentro do Lakebase: o que a separação compute/storage muda para quem provisiona banco</title>
      <link>https://wiliamrosa.github.io/posts/databricks-lakebase-neon-postgres-compute-storage/</link>
      <pubDate>Tue, 25 Aug 2026 09:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/posts/databricks-lakebase-neon-postgres-compute-storage/</guid>
      <description>Na conversa com Nikita Shamgunov, VP de Engenharia da Databricks, fica mais claro de onde vem a arquitetura do Lakebase, e por que &amp;lsquo;agente provisionando banco sozinho&amp;rsquo; deixou de ser ficção científica.</description>
    </item>
    <item>
      <title>Omnigent: a Databricks aposta que orquestrar agentes importa mais do que escolher um só</title>
      <link>https://wiliamrosa.github.io/posts/databricks-omnigent-orquestracao-agentes-codigo/</link>
      <pubDate>Tue, 25 Aug 2026 08:30:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/posts/databricks-omnigent-orquestracao-agentes-codigo/</guid>
      <description>O Omnigent propõe uma camada compartilhada para orquestrar múltiplos agentes de código sem perder contexto entre eles. Acho que essa é a pergunta certa, mas a resposta ainda depende de execução.</description>
    </item>
    <item>
      <title>DeltaBus: o padrão que usa Delta Lake e Change Data Feed em vez de Kafka</title>
      <link>https://wiliamrosa.github.io/posts/deltabus-delta-lake-change-data-feed-sem-kafka/</link>
      <pubDate>Wed, 19 Aug 2026 09:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/posts/deltabus-delta-lake-change-data-feed-sem-kafka/</guid>
      <description>Em vez de mais um cluster Kafka pra manter, o padrão DeltaBus usa tabela Delta e Change Data Feed como barramento de eventos. O Databricks MVP Dr. Alan L. Dennis destacou o argumento por trás dessa escolha de arquitetura.</description>
    </item>
    <item>
      <title>Quando a chamada síncrona vira gargalo em escala de dezenas de milhões de VMs por dia</title>
      <link>https://wiliamrosa.github.io/articles/arquitetura-event-driven-configuracao-rede-serverless/</link>
      <pubDate>Thu, 13 Aug 2026 09:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/articles/arquitetura-event-driven-configuracao-rede-serverless/</guid>
      <description>A Databricks trocou um caminho de configuração de rede baseado em chamadas síncronas a múltiplos serviços por um pipeline assíncrono orientado a eventos, separando o caminho de gerenciamento do caminho de atendimento crítico. O resultado publicado: latência p99 caindo de cerca de 5 segundos pra 125 milissegundos e disponibilidade subindo de 99,8% para 99,99%.</description>
    </item>
    <item>
      <title>Quando o Unity Catalog vira coordenador de transação, não só o dicionário de tabelas</title>
      <link>https://wiliamrosa.github.io/articles/databricks-catalog-commits-unity-catalog-transacoes/</link>
      <pubDate>Sat, 06 Jun 2026 09:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/articles/databricks-catalog-commits-unity-catalog-transacoes/</guid>
      <description>Catalog Commits tira a coordenação de transação do Delta Lake do object storage e coloca dentro do Unity Catalog, habilitando transação atômica entre várias tabelas e leitura de metadado sem round-trip pra nuvem. O recurso central já é GA desde maio de 2026, com Delta Spark, Flink, Trino e DuckDB entre os engines suportados, mas escrita de engine externo continua em Beta e tabela Iceberg gerenciada em Private Preview.</description>
    </item>
    <item>
      <title>Por que juntar SIEM e lakehouse na mesma tabela muda o cálculo de custo e velocidade em SecOps</title>
      <link>https://wiliamrosa.github.io/articles/databricks-lakehouse-nativo-ciberseguranca/</link>
      <pubDate>Wed, 01 Oct 2025 09:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/articles/databricks-lakehouse-nativo-ciberseguranca/</guid>
      <description>Data Intelligence for Cybersecurity une Agent Bricks, Lakebase e o padrão aberto OCSF sobre Delta Lake pra tratar telemetria de segurança como dado de lakehouse governado, em vez de um silo isolado dentro de um SIEM proprietário caro por volume ingerido.</description>
    </item>
    <item>
      <title>Streaming não é sobre velocidade máxima, é sobre acertar o relógio certo pra cada dado</title>
      <link>https://wiliamrosa.github.io/articles/streaming-right-time-processing-databricks/</link>
      <pubDate>Fri, 10 Nov 2023 09:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/articles/streaming-right-time-processing-databricks/</guid>
      <description>A divisão rígida entre pipeline batch e pipeline streaming é mais uma escolha de ferramenta antiga do que uma necessidade real: Spark Structured Streaming trata os dois casos como pontos no mesmo espectro de latência, com o mesmo motor, o mesmo código e as mesmas garantias de tolerância a falha.</description>
    </item>
  </channel>
</rss>
