[{"content":"Quem já jogou Minecraft sabe que a primeira decisão do jogo não é sobre onde construir. É sobre em qual modo jogar.\nNo criativo, o inventário já vem cheio. Você abre o menu, arrasta o bloco que quiser e a casa sobe em minutos. No survival, você começa de mãos vazias, soca uma árvore para conseguir madeira, fabrica uma bancada, depois uma picareta, depois desce na mina. A mesma casa demora horas.\nO jogador de criativo constrói mais rápido. O jogador de survival sabe de onde veio cada bloco, quanto custou e o que acontece se ele quiser mudar de bioma.\nEssa é exatamente a diferença entre as duas formas de construir agentes corporativos hoje. E se você nunca abriu um console da Oracle na vida, este artigo é para você, porque vamos jogar no survival do começo ao fim, socando a primeira árvore e chegando até a tela de debug, com o código que realmente funciona.\nDe um lado, o OCI Enterprise AI, que ficou GA em março de 2026. Do outro, o Copilot Studio, reconstruído no Build 2026. Vou passar a maior parte do tempo no primeiro, porque ele é o menos conhecido e o mais mal explicado dos dois.\nPor Que a Oracle Resolveu Vender Blocos A Oracle passou anos com um problema de percepção. Todo mundo sabia que ela tinha banco de dados e ERP. Quase ninguém associava o nome dela a plataforma de IA.\nO OCI Enterprise AI foi a resposta, e ele junta numa oferta só três camadas que antes viviam separadas.\nA primeira é a inteligência, que são os modelos e a inferência. E aqui vale reparar em algo que quase ninguém espera da Oracle: o catálogo é de terceiros. Grok da xAI, Gemini do Google, gpt-oss aberto, modelos da Cohere e a opção de importar o seu próprio.\nA segunda é a capacidade de agir, que são os agentes e as ferramentas. Busca em documento, interpretador de código em container isolado, chamada de função, chamada de servidor MCP e conversão de pergunta em SQL.\nA terceira é o controle, que já vem junto em vez de ser costurado depois. Identidade por OCI IAM, endpoints com retenção zero de dados, rastreio de cada passo executado, opção de IA soberana e cluster dedicado para quem precisa de isolamento.\nA decisão mais inteligente dessa plataforma foi sobre a API. Em vez de inventar um dialeto próprio, a Oracle adotou a Responses API da OpenAI como interface. Você usa o SDK oficial da OpenAI, troca a base URL, a autenticação e o nome do modelo, e o resto do seu código continua igual. LangChain, LlamaIndex e o Agents SDK da OpenAI funcionam sem refatoração.\nTraduzindo para quem nunca viu Oracle: você não precisa aprender Oracle para usar Oracle. Esse é o ponto inteiro.\nEntrando no Mundo Vamos construir de verdade. O cenário é um agente que responde dúvidas sobre a política interna de reembolso e consulta o sistema de despesas quando precisa de um número real.\n1. A permissão para entrar no servidor Nada acontece na OCI sem política de IAM. Um compartimento é a caixa lógica onde os recursos vivem, e a política diz quem pode fazer o quê dentro dela. Peça ao administrador:\nallow group \u0026lt;seu-grupo\u0026gt; to manage generative-ai-family in compartment \u0026lt;seu-compartimento\u0026gt; Essa é uma política de sandbox, o equivalente a entrar no servidor com permissão de construir em qualquer lugar. Em produção você restringe, e no passo 3 mostro como amarrar a permissão a uma chave específica.\n2. Gerando o mundo, e as escolhas que não voltam atrás Projeto é o recurso que organiza agentes e ativos relacionados. Você cria pelo console, e nessa tela existem três decisões que muita gente clica sem ler.\nRetenção define por quanto tempo respostas e conversas ficam guardadas, com máximo de 720 horas, ou seja, 30 dias.\nCompactação de memória de curto prazo resume o histórico recente para economizar token e latência. Você escolhe o modelo de compactação na criação e não muda depois.\nMemória de longo prazo extrai e persiste informação importante das conversas como embeddings, e exige escolher modelo de extração e de embedding na criação.\nNos dois últimos casos, habilitou e quis desfazer, o caminho é deletar o projeto. É como o seed do mundo. Escolheu, é aquele. Guarde o OCID do projeto, ele vai no código.\n3. A picareta Crie uma API key de Generative AI pelo console, pegue o OCID dela e amarre a permissão a essa chave específica:\nallow group \u0026lt;grupo-dos-builders\u0026gt; to manage generative-ai-response in compartment \u0026lt;seu-compartimento\u0026gt; where ALL {request.principal.type=\u0026#39;generativeaiapikey\u0026#39;, request.principal.id=\u0026#39;\u0026lt;ocid-da-chave\u0026gt;\u0026#39;} Chave de API serve para teste e desenvolvimento inicial. Para produção a recomendação da Oracle é autenticação por IAM, com principal de instância ou de recurso, que evita credencial de vida longa.\n4. Socando a primeira árvore Instale o SDK da OpenAI, não o SDK da OCI. Esse detalhe derruba muita gente no primeiro dia.\npip install openai E o primeiro agente:\nfrom openai import OpenAI client = OpenAI( base_url=\u0026#34;https://inference.generativeai.us-chicago-1.oci.oraclecloud.com/openai/v1\u0026#34;, api_key=\u0026#34;\u0026lt;sua-api-key\u0026gt;\u0026#34;, project=\u0026#34;ocid1.generativeaiproject.oc1.us-chicago-1.xxxxxxxx\u0026#34; ) response = client.responses.create( model=\u0026#34;xai.grok-4.3\u0026#34;, input=\u0026#34;Explique em uma frase o que é um banco de dados.\u0026#34; ) print(response.output_text) Três coisas para reparar, porque explicam a filosofia da plataforma inteira.\nA base URL carrega a região. Troque us-chicago-1 pela sua e o tráfego muda de continente, o que importa quando existe exigência de residência de dado.\nO modelo é uma string, e a Oracle hospeda modelos de terceiros. Grok da xAI, Gemini do Google, gpt-oss aberto. Trocar de modelo é trocar uma linha, e é assim que você negocia custo contra qualidade sem reescrever a aplicação.\nSe quiser capacidade dedicada em vez de sob demanda, o identificador do modelo passa a ser o OCID do endpoint do cluster. Mesmo código, infraestrutura isolada.\n5. A bancada de trabalho Um agente que só sabe o que o modelo já sabia não serve para nada corporativo. Ele precisa responder com base na sua política de reembolso, não com base na internet.\nVocê sobe o arquivo, cria um vector store e declara a ferramenta de busca na própria chamada:\nresponse = client.responses.create( model=\u0026#34;openai.gpt-oss-120b\u0026#34;, input=\u0026#34;Qual o prazo para solicitar reembolso de viagem?\u0026#34;, tools=[ { \u0026#34;type\u0026#34;: \u0026#34;file_search\u0026#34;, \u0026#34;vector_store_ids\u0026#34;: [\u0026#34;\u0026lt;id-do-vector-store\u0026gt;\u0026#34;] } ] ) Repare que você não construiu pipeline de RAG. A recuperação é gerenciada pela plataforma. É a bancada de trabalho do jogo, aquele momento em que blocos soltos viram ferramenta.\n6. Redstone, ou o agente que age Consultar documento é bom, mas agente de verdade executa. Function calling é o padrão para isso, e a mecânica importa: o modelo não roda a sua função. Ele devolve o nome dela e os argumentos, a sua aplicação executa, e você manda o resultado de volta.\ntools = [ { \u0026#34;type\u0026#34;: \u0026#34;function\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;consultar_despesas\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Retorna as despesas lançadas por um colaborador em um período.\u0026#34;, \u0026#34;parameters\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;object\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;colaborador\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;}, \u0026#34;mes\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Formato 2026-08\u0026#34;} }, \u0026#34;required\u0026#34;: [\u0026#34;colaborador\u0026#34;, \u0026#34;mes\u0026#34;], }, }, ] Quem executa é você. Quem tem acesso ao sistema é você. O modelo só pede. Para arquitetura corporativa, essa fronteira é a diferença entre uma prova de conceito e algo que passa em revisão de segurança.\nConte as idas e voltas desse caminho: a aplicação manda o prompt, o modelo devolve a chamada, a aplicação executa, a aplicação devolve o resultado, e só então o modelo responde. São duas viagens completas entre a sua aplicação e a plataforma.\nSe a ferramenta já existir num servidor MCP, você corta esse vaivém pela metade. Declare o servidor na própria chamada e a plataforma conversa com ele diretamente, sem devolver o controle para o seu código no meio do caminho. Três passos em vez de cinco, uma viagem em vez de duas:\nresponse = client.responses.create( model=\u0026#34;openai.gpt-oss-120b\u0026#34;, tools=[ { \u0026#34;type\u0026#34;: \u0026#34;mcp\u0026#34;, \u0026#34;server_label\u0026#34;: \u0026#34;despesas\u0026#34;, \u0026#34;server_url\u0026#34;: \u0026#34;https://interno.exemplo.com/mcp\u0026#34;, \u0026#34;require_approval\u0026#34;: \u0026#34;never\u0026#34;, \u0026#34;allowed_tools\u0026#34;: [\u0026#34;consultar_despesas\u0026#34;] } ], input=\u0026#34;Quanto o time de dados gastou em viagem em agosto?\u0026#34; ) 7. O mapa do tesouro Essa é a peça mais oracle de todas, e a que mais interessa a quem trabalha com dado. O NL2SQL do Enterprise AI converte pergunta em linguagem natural em SQL validado, usando uma camada de enriquecimento semântico que mapeia termo de negócio para tabela, coluna e join.\nO detalhe de segurança que merece aplauso: o NL2SQL gera o SQL e não executa. Quem executa é o Database Tools MCP Server, usando a identidade do usuário final. E a configuração exige duas conexões separadas, uma de enriquecimento, com privilégio maior para ler metadado e amostra, e outra de query, com privilégio menor para rodar em nome do usuário.\nSe você vem de engenharia de dados, reconhece o padrão na hora. É separação de papéis aplicada a agente.\n8. Apertando F3 Todo jogador de Minecraft conhece a tela de debug. Na Responses API ela vem de graça: toda resposta traz um campo output que é a lista dos passos executados, com tipos como message, file_search_call e mcp_call.\nfor item in response.output: print(item.type) Rastreabilidade nativa, sem instrumentar nada. E se quiser observabilidade completa, com latência e custo, dá para plugar Langfuse trocando apenas o import do cliente OpenAI.\nO Modo Criativo Do outro lado, o Copilot Studio resolve o mesmo problema com o inventário cheio.\nVocê não escreve código. Cria o agente numa tela, liga a orquestração generativa e o modelo decide sozinho qual ferramenta chamar. Depois do Build 2026 o produto tem quatro superfícies mais uma: Skills, que são instruções reutilizáveis em markdown, Tools, Knowledge, Connected agents e Memory.\nO poder dele não está nessas superfícies. Está no Microsoft IQ, a camada de contexto com três fontes: Work IQ, com e-mail, chat, arquivo, calendário e pessoas do Microsoft 365, Fabric IQ, com dado de negócio no Fabric, e Foundry IQ, com bases indexadas pelo Azure AI Search. Ligar uma fonte dá leitura e ação ao mesmo tempo, dentro da permissão do usuário logado.\nSe a sua empresa vive no Microsoft 365, o inventário já está cheio e a casa sobe em minutos. Se não vive, você está no criativo de um mundo onde os blocos que interessam não vieram no menu, e cada conector é uma tentativa de importar bloco de outro mundo.\nColocando os dois lado a lado, a diferença aparece em cinco pontos. Você constrói escrevendo código contra uma API ou clicando em telas com orquestração automática. O agente roda na sua conta OCI, na região que você escolher, ou na plataforma da Microsoft. O contexto que vem de graça é o seu banco e os seus arquivos de um lado, e o Microsoft 365, o Fabric e o Foundry do outro. A conta chega por transação de caractere e compromisso de cluster, ou por crédito consumido por ação. E cada um ganha onde o dado já mora.\nO Custo de Cada Bloco A Oracle cobra minério. A inferência sob demanda é medida em transações, e uma transação é um caractere, somando prompt e resposta. Cluster dedicado exige compromisso mínimo de 744 unit-hours, que é um mês corrido. Modelo importado não carrega essa exigência.\nA Microsoft cobra construção. Copilot Credits vêm em pacotes de 25 mil por 200 dólares ao mês, ou por consumo no Azure à mesma taxa.\nIsso muda quem aprova a conta dentro do cliente. Uma vai para infraestrutura, com capacidade e compromisso mensal. A outra vai para a área de negócio, com crédito por ação. Já vi proposta ser mal calibrada por não perceber isso e ir para o comitê errado.\nNo Fim, a Mesma Construção Quem joga survival e quem joga criativo terminam com a mesma casa na tela. O que muda é quem carregou o material e quanto cada um sabe sobre a própria construção.\nE os dois modos estão convergindo mais rápido do que o discurso comercial admite. A Oracle e a Microsoft adotaram MCP como protocolo de ferramenta. As duas decidiram que agente precisa de identidade própria, uma com autenticação IAM nos endpoints hospedados, a outra com Entra Agent ID automático em todo agente novo desde julho de 2026. As duas entenderam que instrução reutilizável precisa ser artefato versionável, não texto colado num campo.\nVindas de pontos opostos, chegaram nas mesmas três conclusões. É como se as duas fábricas tivessem combinado o mesmo encaixe.\nEntão a pergunta não é qual modo é melhor. É de que lado da fronteira mora o dado que decide o seu negócio. Se a resposta for e-mail, reunião e arquivo, o inventário do criativo já resolve. Se for banco, aplicação própria ou dado que não pode atravessar fronteira geográfica, pegue a picareta.\nO código está aí em cima, e ele roda hoje.\nReferências Quick Start Guide, Enterprise AI Agents: https://docs.oracle.com/en-us/iaas/Content/generative-ai/get-started-agents.htm OCI OpenAI-Compatible Endpoints: https://docs.oracle.com/en-us/iaas/Content/generative-ai/openai-compatible-api.htm Announcing GA of OCI Enterprise AI: https://blogs.oracle.com/ai-and-datascience/announcing-oci-enterprise-ai-ga What\u0026rsquo;s New in Oracle AI, August 2026: https://blogs.oracle.com/ai-and-datascience/whats-new-in-ai-august-2026 Paying for Dedicated AI Clusters: https://docs.oracle.com/en-us/iaas/Content/generative-ai/pay-dedicated.htm Build an agent, Microsoft Copilot Studio: https://learn.microsoft.com/en-us/microsoft-copilot-studio/agents-experience/build-overview What\u0026rsquo;s new in Copilot Studio: https://learn.microsoft.com/en-us/microsoft-copilot-studio/whats-new ","permalink":"https://julianamarialop.github.io/articles/survival-ou-criativo-como-construir-seu-primeiro-agente/","summary":"Quem já jogou Minecraft sabe que a primeira decisão do jogo não é sobre onde construir. É sobre em qual modo jogar.","title":"Survival ou Criativo: Como Construir Seu Primeiro Agente de IA na Oracle Sem Nunca Ter Aberto o Console"},{"content":"O Valor das Peças Todo enxadrista aprende cedo uma tabela que carrega pela vida inteira: peão vale 1, cavalo e bispo valem 3, torre vale 5, dama vale 9. Não é regra do jogo, é sabedoria acumulada de séculos sobre o poder relativo de cada peça. E dela derivam as lições que separam quem joga de quem entende. Não se usa a dama para trabalho de peão, porque cada lance dela em tarefa pequena é um lance em que ela não está decidindo o jogo. Philidor escreveu no século XVIII que os peões são a alma do xadrez: partidas se ganham e se perdem na estrutura deles, as peças humildes que fazem o trabalho de volume. E o rei, curiosamente a peça menos poderosa do tabuleiro, é a única insubstituível: ele anda uma casa por vez, mas tudo gira em torno dele, e quando ele cai, acabou.\nO mercado de modelos de linguagem em 2026 é esse tabuleiro. Os preços públicos vão de cerca de 10 centavos a 75 dólares por milhão de tokens, uma diferença que faz o peão e a dama do xadrez parecerem próximos: no tabuleiro a dama vale 9 peões, no catálogo ela pode valer 60. E mesmo assim, a cena mais comum em projetos de IA corporativa segue sendo um tabuleiro montado só de damas: o modelo mais caro do catálogo executando classificação de texto, extração de campo e validação de regra, tarefas de peão, com cachê de dama.\nNeste artigo eu apresento as peças uma a uma, com specs e números reais, e depois monto uma partida completa: um projeto multiagente sobre Microsoft Fabric e Foundry em que cada função roda no modelo do seu valor.\nAs Damas: Modelos de Fronteira A dama é o modelo de raciocínio profundo, e em agosto de 2026 três dominam o topo dos índices independentes.\nO Claude Opus 4.8, da Anthropic, lidera os rankings agregados de inteligência e é o rei do código: os comparativos reportam 88,6% no SWE-bench Verified, o benchmark que mede resolução de bugs reais em repositórios reais, com capacidade de coordenar subagentes paralelos em tarefas de larga escala. Contexto de 200 mil tokens, preço na faixa alta do mercado. É a dama para engenharia complexa, análise ambígua de várias etapas e orquestração. No Foundry, os modelos Claude estão em disponibilidade geral desde julho de 2026, em duas variantes de hospedagem.\nA família GPT-5.6, da OpenAI, lançada em julho de 2026, trouxe a artilharia de contexto: 1.050.000 tokens de janela, com variantes que equilibram custo e capacidade. A geração anterior, GPT-5.5, segue forte em fluxos agênticos e multimodais, e os comparativos a colocam lado a lado com o Opus em código. É a dama para missões que precisam enxergar bases de código ou documentos inteiros de uma vez.\nO Gemini 3.1 Pro, do Google, é a dama com melhor custo-benefício da fronteira: os comparativos reportam 80,6% no SWE-bench, praticamente empatado com os líderes, a uma fração do custo, com 1 milhão de tokens de contexto. A honestidade de tabuleiro: ele não vive no catálogo do Foundry, então para arquiteturas ancoradas no ecossistema Microsoft ele é uma dama do clube vizinho.\nQuando usar uma dama: planejamento, decomposição de problemas ambíguos, código complexo multiarquivo, julgamento final. Quando não usar: qualquer tarefa que se descreve em uma frase e se verifica com uma regra.\nAs Torres: Os Cavalos de Batalha A torre vale 5: forte, direta, e é quem carrega o meio-jogo. São os modelos equilibrados, e a regra prática é que eles resolvem a maioria absoluta das tarefas corporativas por uma fração do custo da dama.\nO Claude Sonnet 4.6 é o exemplo canônico: os comparativos reportam 79,6% no SWE-bench, alguns pontos atrás do Opus, com custo e latência bem menores. Para código do dia a dia, análise de dados, geração de documentos e agentes de produção, a torre entrega perto da dama pagando muito menos. O GPT-5.4 ocupa a mesma casa no lado OpenAI, com destaque reportado em raciocínio estruturado e uso de computador (75% no OSWorld, acima da linha de base de especialistas humanos) e a mesma janela expandida de 1.05 milhão de tokens. E o Llama 4 Maverick, da Meta, é a torre de peso aberto que aparece inclusive no pool do Model Router do Foundry.\nQuando usar: como padrão. A torre deveria ser o modelo default da sua arquitetura, com a dama entrando por exceção justificada e o peão por otimização de volume.\nOs Bispos: Especialistas de Uma Cor Só O bispo é poderoso com uma limitação estrutural: enxerga só as casas da sua cor. São os modelos especializados, imbatíveis na sua diagonal e inúteis fora dela.\nO Grok 4.1 fast reasoning, da xAI, presente no router do Foundry, é o bispo da velocidade: raciocínio rápido para casos agênticos onde latência importa mais que profundidade máxima. Os modelos de embedding são bispos puros: não conversam, só transformam texto em vetores, e nenhuma busca semântica ou RAG existe sem eles. Modelos de visão e de geração de imagem seguem a mesma lógica. E o DeepSeek V3.2 e o novo V4, abertos sob licença MIT, são os bispos do custo: os comparativos os colocam poucos pontos atrás das damas proprietárias em código, custando dezenas de vezes menos, o que redefine a matemática de trabalho em lote massivo. Com a diagonal honesta declarada: para contexto regulado, o caminho de dados e a maturidade operacional precisam entrar na análise de risco antes do preço.\nOs Cavalos: O Movimento Que Ninguém Mais Faz O cavalo vale os mesmos 3 pontos do bispo, mas tem o único movimento do jogo que salta sobre as outras peças. São os modelos de peso aberto e os SLMs, que chegam onde os fechados não chegam: dentro do seu datacenter, na borda, no dispositivo, no fine-tuning profundo com seus dados.\nA família Phi, da Microsoft, é o cavalo da casa no Foundry: modelos pequenos que rodam com custo mínimo e até localmente, ideais para tarefas bem delimitadas em altíssimo volume. O Llama 4 em seus tamanhos menores cumpre o mesmo papel com o maior ecossistema de comunidade. O salto do cavalo é a resposta para os requisitos que travam projetos: dado que não pode sair do perímetro, latência de milissegundos, custo por chamada tendendo a zero.\nOs Peões: A Alma da Operação E chegamos à peça de Philidor. Os peões são os modelos leves das famílias de fronteira: Claude Haiku 4.5, GPT-5.4-nano e mini, os Flash e Flash-Lite do mundo, com preços na casa dos centavos por milhão de tokens. Individualmente modestos, em estrutura eles decidem partidas: classificação, extração de campos, roteamento de mensagens, validação de regras, tudo que roda milhares de vezes por dia e se verifica com critério objetivo.\nA estrutura de peões da sua arquitetura é a camada de validação e triagem. Time que monta essa estrutura bem gasta centavos onde os concorrentes gastam dólares, e chega ao final do jogo com as damas intactas para o que importa.\nO Rei e o Enxadrista Duas figuras faltam, e a distinção entre elas organiza a arquitetura inteira.\nO rei é o orquestrador: o agente que recebe a missão, decompõe em tarefas, aciona cada peça e julga os resultados. Como no tabuleiro, ele não é quem mais se move; ele faz poucos lances, mas cada um decide a partida, e se ele cai, a missão inteira cai. Por isso o rei justifica um modelo de fronteira ou um equilibrado superior: errar uma classificação custa centavos, errar a decomposição custa a batalha.\nE o enxadrista é você. Aqui vale desfazer uma confusão comum no Foundry: o Model Router, que roteia cada prompt entre 28 modelos otimizando custo e qualidade, é uma ferramenta valiosa, mas é um seletor de peça por lance, não um jogador. Orquestração de missão, com estado, sequência e julgamento, é papel de agente desenhado por você, tipicamente com o rei rodando num modelo forte e carregando os protocolos da operação, as skills, hoje hospedáveis no próprio Foundry.\nA Partida: O Projeto Multiagente Agora a partida completa, no meu mundo: a torre de controle de qualidade de dados com relatório executivo diário, sobre Fabric e Foundry.\nA abertura é evento, não prompt: o Activator do Fabric detecta a chegada da carga diária no OneLake e dispara a missão, sem nenhum token gasto perguntando se o dado chegou.\nO rei acorda: o orquestrador, num Claude Opus ou GPT-5.6, lê o protocolo da operação e decompõe a missão em quatro tarefas com dependências.\nOs peões avançam: agentes de validação em Haiku e Phi varrem centenas de regras de qualidade, contagens, duplicidades e domínios. Volume puro, custo em centavos, resultado verificável por regra.\nA torre entra no meio-jogo: um agente de análise em Sonnet ou GPT-5.4 investiga as variações do dia conversando com o Data Agent do Fabric, que responde ancorado nos modelos semânticos onde vivem as definições oficiais de KPI. A definição de receita líquida mora no modelo semântico, não copiada em cinco prompts.\nO bispo escreve: um agente redator transforma os achados no relatório executivo, no formato do protocolo.\nE o lance final vem da tradição enxadrística moderna: nenhum grande mestre confia a análise de uma partida a um único engine. Usa-se o Stockfish e a Leela, motores de estilos diferentes, porque a discordância entre eles é onde mora o aprendizado. O quinto agente é esse segundo engine: um crítico de outra família de modelo que a do redator. Se o redator é Claude, o crítico é GPT, e vice-versa. A revisão cruzada entre famílias reduz o vício de estilo e a complacência de linhagem, prima daquela sycophancy sobre a qual já escrevi. Só com o aval do crítico o rei publica e encerra.\nUma missão, seis modelos, quatro valores de peça, duas famílias. O custo despenca em relação ao tabuleiro só de damas, e a qualidade sobe, porque discordância virou arquitetura.\nO Que Muda Para Times de Dados Três regras de clube de xadrez para levar. Primeira: dimensione pelo volume, não pelo prestígio. Liste as funções que rodam milhares de vezes por dia e empurre para peões e cavalos; a economia paga a dama do orquestrador com sobra. Segunda: institua o segundo engine. Revisão cruzada entre famílias como regra de arquitetura, o que o catálogo unificado do Foundry, com mais de 1.900 modelos sob a mesma governança e política central de implantação, torna trivial. Terceira: benchmarks mudam mensalmente e a liderança troca de mãos a cada trimestre, então construa para trocar de peça barato: modelo é configuração, não fundação. Quem acopla a arquitetura a um modelo específico está jogando a partida de hoje com a teoria de abertura do ano passado.\nE a honestidade de sempre: multiagente é final de jogo, não abertura. Se um agente só resolve, cinco agentes são complexidade sem retorno. Monte o tabuleiro completo quando as funções forem genuinamente diferentes a ponto de pedirem peças diferentes.\nConclusão: Quem Vence a Partida No xadrez, os dois jogadores começam com exatamente as mesmas peças. O tabuleiro é público, os valores são conhecidos, e mesmo assim alguém vence. A diferença nunca esteve nas peças; esteve em quem entende o valor relativo delas e aloca cada uma na casa certa, no lance certo.\nCom modelos de LLM, o catálogo também é público e igual para todos. Seus concorrentes têm acesso às mesmas damas, torres e peões que você. A vantagem competitiva não está em ter o modelo mais forte, está na escalação: a dama guardada para o que decide, os peões estruturados no volume, o segundo engine conferindo a análise, e o rei protegido no centro da arquitetura.\nA pergunta que fica no tabuleiro: quantas damas do seu projeto estão, neste momento, fazendo trabalho de peão?\nReferências Microsoft Learn. Model router for Microsoft Foundry concepts. https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-router Microsoft Azure. Foundry Models. https://azure.microsoft.com/en-us/products/ai-foundry/models LM Council. AI Model Benchmarks. https://lmcouncil.ai/benchmarks Iternal. LLM Comparison 2026: 30+ Models Benchmarked. https://iternal.ai/llm-selection-guide TechieHub. Best AI Models Compared 2026. https://techiehub.blog/best-ai-models-compared/ ","permalink":"https://julianamarialop.github.io/articles/peao-torre-dama-como-escalar-o-modelo-certo-para-cada/","summary":"Todo enxadrista aprende cedo uma tabela que carrega pela vida inteira: peão vale 1, cavalo e bispo valem 3, torre vale 5, dama vale 9. Não é regra do jogo, é sabedoria acumulada de séculos sobre o poder relativo de cada…","title":"Peão, Torre, Dama: Como Escalar o Modelo Certo Para Cada Agente"},{"content":"O Garoto Que Gritava Com o Dragão Em Berk, vikings resolvem o problema dos dragões do único jeito que conhecem: na força. Soluço não tem força. Quando ele finalmente fica cara a cara com um Fúria da Noite, o dragão mais rápido e mais temido de todos, o garoto descobre que gritar comandos não funciona. O Banguela é absurdamente poderoso e não entende ordens.\nO que Soluço faz a partir daí é o que separa o filme de qualquer outra história de domar feras. Ele para de gritar e começa a observar. Aprende o que o dragão percebe: os peixes que ele aceita, a grama que o hipnotiza, o jeito de se aproximar sem ameaçar. Depois, percebe que o Banguela não voa porque perdeu metade da cauda, e constrói a solução: uma cauda protética, uma sela, um sistema de pedais. Um equipamento inteiro em volta do dragão, calibrado a cada voo de teste. E no último ato dessa evolução, Soluço constrói uma cauda automática, que abre e ajusta sozinha. O Banguela ganha o céu sem precisar do cavaleiro em cima.\nGritar melhor. Entender o que o outro percebe. Construir o equipamento em volta. Sair de cima. Essas quatro etapas ganharam nomes na engenharia de IA nos últimos meses, e formam a progressão que explica onde o mercado de agentes está agora: prompt engineering, context engineering, harness engineering e loop engineering.\nPara ninguém se perder, vou usar um único exemplo do início ao fim: o relatório de vendas da sua empresa. O mesmo relatório, subindo de camada em camada.\nCamada 1. Gritar Comandos: Prompt Engineering Prompt engineering é caprichar no pedido. No nosso exemplo: em vez de \u0026ldquo;faz um relatório de vendas\u0026rdquo;, você escreve \u0026ldquo;gere o relatório de vendas do primeiro semestre com receita líquida por mês e ticket médio por região, em tabela, com um parágrafo executivo no topo\u0026rdquo;. O pedido melhorou, a resposta melhora junto.\nFoi a habilidade dominante dos primeiros anos, e continua útil. Mas tem um teto baixo, pelo mesmo motivo que gritar mais alto não fazia o Banguela voar: o problema nunca foi o volume da ordem. Era tudo que o dragão não sabia sobre você.\nCamada 2. Entender o Que o Dragão Enxerga: Context Engineering O modelo responde com base no que enxerga naquele momento. Se ele não conhece o schema das suas tabelas, a definição oficial de receita líquida da sua empresa e o formato dos relatórios anteriores, o prompt perfeito produz um relatório genérico. Context engineering é a disciplina de decidir o que entra no campo de visão do modelo: quais arquivos, quais documentações, quais memórias de interações passadas, e igualmente importante, o que fica de fora para não poluir.\nNo exemplo: você anexa o dicionário de dados, a regra de cálculo dos KPIs e um relatório antigo como referência de formato. O mesmo prompt de antes, agora com visão, produz outra qualidade de resposta. Soluço descobrindo que o Banguela odeia enguia e ama peixe é isso: você não mudou o dragão, mudou o que ele percebe.\nNo ecossistema Microsoft, essa camada tem nome e endereço: o Fabric. O OneLake como fonte única do dado, os modelos semânticos carregando as definições oficiais de cada métrica, e os Data Agents respondendo perguntas ancorados nesses modelos. Quando a regra de receita líquida vive no modelo semântico, você para de anexá-la a cada conversa: o contexto deixa de ser um anexo e vira infraestrutura.\nCamada 3. A Sela e a Cauda: Harness Engineering Aqui a palavra ajuda, porque harness é literalmente arreio, o equipamento que se coloca no animal. E a cena do Soluço construindo a cauda protética com pedais é a definição visual perfeita do conceito.\nHarness engineering é desenhar tudo que existe em volta do modelo: as ferramentas que ele pode chamar, o ambiente isolado onde executa código, as validações que rodam antes e depois de cada ação, as permissões do que ele pode e não pode tocar. A fórmula que cristalizou o conceito veio de Mitchell Hashimoto, criador do Terraform, em fevereiro de 2026, depois de uma publicação da OpenAI sobre sua infraestrutura interna de agentes: agente = modelo + harness. O modelo é o cérebro; o harness é o corpo, os sentidos e os limites. Martin Fowler e Birgitta Böckeler, da Thoughtworks, organizaram o vocabulário que virou padrão: o harness tem guias, que direcionam o agente antes de agir, e sensores, que detectam e corrigem problemas depois.\nNo exemplo do relatório: o agente agora tem uma ferramenta de SQL para calcular os números em vez de estimar, um protocolo escrito com as validações obrigatórias de qualidade, permissão de leitura nos dados e nenhuma permissão de escrita, e um sensor que confere se as contagens de linhas reconciliam antes de liberar o resultado. Se você acompanha esta newsletter, reconheceu: skills são harness engineering. Quem escreve protocolos em markdown está construindo selas há meses, talvez sem usar o nome.\nE do lado corporativo, o Microsoft Foundry é exatamente isso vendido como serviço gerenciado: agentes hospedados com ferramentas, guardrails, observabilidade e, desde este ano, suporte nativo a skills em preview, com API versionada para armazenar os protocolos centralmente e anexá-los aos agentes. A fórmula agente = modelo + harness virou arquitetura de produto: você escolhe o modelo, o Foundry fornece a sela.\nO detalhe que importa: harness não é só segurança. Uma sela bem construída não serve para prender o dragão, serve para ele voar melhor. Um harness bem desenhado dá ao modelo o contexto certo, a ferramenta certa e a restrição certa na hora certa, e é isso que transforma demo impressionante em sistema confiável.\nCamada 4. A Cauda Automática: Loop Engineering Até aqui, você continua em cima do dragão, ditando cada voo. A quarta camada é sair de cima.\nTodo agente já roda num ciclo: raciocina, age, observa o resultado, decide o próximo passo. Loop engineering, o termo que dominou as conversas a partir de junho de 2026, é desenhar esse ciclo de propósito: definir o objetivo, a verificação e a condição de parada, e deixar o sistema fazer os prompts pelo agente. A faísca foi uma fala de Boris Cherny, criador do Claude Code, dizendo que já não faz prompts diretamente; ele mantém loops rodando, e são os loops que decidem o que pedir ao modelo. Addy Osmani, do Google, nomeou e estruturou a prática dias depois.\nNo exemplo do relatório de vendas, a mudança é concreta: em vez de você pedir o relatório toda segunda-feira, existe um loop agendado que ingere o dado novo, roda as validações do protocolo, gera o relatório, confere o resultado contra as regras de qualidade e publica. Se a verificação falha, o loop tenta corrigir; se não consegue, aí sim te chama. Você saiu da execução e virou o projetista do voo.\nMontando esse voo com peças Microsoft, o desenho fica concreto: o Activator do Fabric dispara o ciclo quando o dado novo chega no OneLake, o agente hospedado no Foundry executa o protocolo com as validações, e o resultado volta para o Fabric, onde relatório e trilha de verificação ficam auditáveis. O Fabric é o território onde o dragão voa, o Foundry é a sela, e o loop é o plano de voo que conecta os dois.\nDuas lições dessa camada que os entusiastas costumam pular. Primeira: o gargalo do loop é o verificador, não o modelo. Um loop sem verificação confiável é um dragão voando cego, queimando orçamento convencido de que está progredindo. Segunda, e aqui vale registrar o alerta que a IBM formalizou ao definir a disciplina: existe uma linha entre delegar execução e abrir mão do pensamento crítico, que eles chamam de rendição cognitiva. Sair do loop de execução não é sair do loop de julgamento.\nE para provar que a camada 4 não exige sofisticação, a comunidade tem um exemplo folclórico: a técnica Ralph, de Geoffrey Huntley, que roda um agente dentro de um simples while loop, com o mesmo prompt contra uma especificação escrita, recomeçando até o trabalho acabar. Batizada em homenagem ao Ralph Wiggum dos Simpsons porque parece simples demais para funcionar. E funciona, justamente porque a especificação e a verificação carregam o peso.\nO Que Muda Para Times de Dados A progressão vira um diagnóstico de maturidade honesto. A maioria dos times que conheço está entre as camadas 1 e 2: prompts cada vez melhores, contexto cada vez mais organizado. O salto de valor imediato está na camada 3, e times de dados têm vantagem injusta nela: governança, validação e reconciliação de contagens já são nossa cultura, só mudou o lugar onde escrevemos as regras. Um protocolo de qualidade de dados é uma sela pronta.\nE a camada 4 tem um pré-requisito que ninguém pula: só automatize o ciclo de trabalhos cuja verificação você sabe escrever. Relatórios recorrentes com regras de qualidade claras são o candidato perfeito para o primeiro loop. Análises exploratórias abertas, ainda não. O critério não é o que o agente consegue fazer sozinho, é o que você consegue verificar sozinho.\nConclusão: O Voo A genialidade do Soluço nunca foi domar o dragão. Foi entender que a força do Banguela sempre esteve lá, e que o que faltava era engenharia em volta dela: primeiro os olhos, depois a sela, depois a cauda que voa sozinha.\nCom IA, a força do modelo também já está lá, e cresce a cada versão. A alavanca mudou de lugar: de escrever o pedido perfeito para desenhar a visão, o equipamento e o ciclo. Prompt, contexto, harness, loop. Quatro camadas, uma pergunta de diagnóstico: em qual delas o seu time está gastando energia, e em qual deveria?\nO dragão está pronto faz tempo. A sela é sua responsabilidade.\nReferências Martin Fowler / Birgitta Böckeler. Harness engineering for coding agent users. https://martinfowler.com/articles/harness-engineering.html Addy Osmani. Agent Harness Engineering. https://addyosmani.com/blog/agent-harness-engineering/ IBM. What Is Loop Engineering? https://www.ibm.com/think/topics/loop-engineering Hugging Face. Harness, Scaffold, and the AI Agent Terms Worth Getting Right. https://huggingface.co/blog/agent-glossary ","permalink":"https://julianamarialop.github.io/articles/o-que-como-treinar-seu-dragao-me-ensinou-sobre-prompt/","summary":"Em Berk, vikings resolvem o problema dos dragões do único jeito que conhecem: na força. Soluço não tem força. Quando ele finalmente fica cara a cara com um Fúria da Noite, o dragão mais rápido e mais temido de todos, o…","title":"O Que Como Treinar o Seu Dragão Me Ensinou Sobre Prompt, Context, Harness e Loop Engineering"},{"content":"A Sala de Armaduras Debaixo da mansão em Malibu, Tony Stark mantém uma galeria que conta a história dele melhor que qualquer biografia. A Mark III, dourada e vermelha, feita para o dia a dia. A Mark XLIV, a Hulkbuster, projetada para um único cenário extremo. O detalhe que define o Tony nunca foi ter a armadura mais poderosa. É saber qual armadura cada missão pede. Ele não voa para uma gala dentro da Hulkbuster, e quando erra a escolha, a história cobra: armadura de menos vira sufoco no meio da batalha, armadura de mais vira custo parado no hangar.\nEscolher o plano do Anthropic Claude é esse problema, com um agravante que o Tony não tinha: os manuais das armaduras não publicam a potência. A Anthropic não divulga quantos tokens cada plano entrega. E é por isso que todo comparativo que circula por aí repete os mesmos preços e os mesmos adjetivos, sem responder a única pergunta que importa: o seu dia de trabalho cabe dentro do limite?\nNeste artigo eu faço a conta que ninguém faz. Uma simulação de tokens, janelas e prompts, cruzada com o uso real de dois perfis de pessoa, para você encontrar seu plano numa linha de tabela em vez de descobrir do jeito ruim, com a tela de \u0026ldquo;você atingiu seu limite\u0026rdquo; no meio de uma entrega.\nO Que a Anthropic Publica (e o Que Não Publica) Os números oficiais são preços e multiplicadores. Todos os planos pagos expressam sua capacidade como múltiplos do plano Pro por sessão, e cada família de plano estrutura os limites de um jeito:\nO que a Anthropic não publica é o valor absoluto por trás do 1x. A documentação oficial diz apenas que o consumo varia com o tamanho da conversa, o modelo e os recursos usados. Essa opacidade é decisão de produto, não descuido: dá à empresa flexibilidade para ajustar alocações sem quebrar compromissos publicados.\nMas dá para simular. Testes de usuários estimam que o Pro entrega cerca de 44 mil tokens por janela de cinco horas, e a documentação de suporte indica até 45 mensagens por janela no Pro, caindo para algo entre 10 e 40 prompts em uso real de Claude Code. Aplicando os multiplicadores oficiais sobre essa base, a sala de armaduras inteira fica mensurável.\nAs Premissas da Simulação Toda a simulação abaixo usa estas premissas, declaradas para você poder discordar delas e refazer a conta. Base: Pro com aproximadamente 44 mil tokens por janela de 5 horas, demais planos projetados pelos multiplicadores oficiais. Um prompt de chat consome cerca de mil tokens. Um prompt de código consome de mil a 4,4 mil, porque carrega contexto do repositório junto. O mês tem 44 janelas: duas por dia útil, 22 dias úteis.\nE os dois perfis de pessoa, com a matemática aberta:\nUso leve, o analista que consulta: 15 prompts de chat vezes mil tokens, mais 2 tarefas de código vezes 2,5 mil. Total: cerca de 20 mil tokens por janela.\nUso pesado, o dev em projeto com Claude Code aberto o dia todo: 10 prompts de chat vezes mil, mais 25 prompts de código vezes 2,5 mil. Total: cerca de 72 mil tokens por janela.\nImportante: são estimativas direcionais, não números garantidos. Servem para dimensionar ordem de grandeza, e é exatamente isso que uma decisão de compra precisa.\nA Simulação: Planos de Pessoa Física A leitura é direta: encontre sua coluna de perfil e desça. O usuário leve vive bem no Pro, com menos da metade da janela consumida. O usuário pesado estoura o Pro em 164%, que é a tradução matemática daquela tela de bloqueio antes do almoço. No Max 5x, o mesmo dia pesado usa um terço da janela. A Hulkbuster do Max 20x só se justifica para quem roda mais pesado que o nosso perfil pesado: sessões longas de agentes, repositórios grandes, uso quase contínuo.\nA Simulação: Planos Empresariais Aqui mora a nuance que quase todo comparativo ignora. Na tabela de pessoa física, o gargalo é a janela de cinco horas, que se renova sozinha. Na empresarial, os assentos Team somam tetos semanais por pessoa, que resetam em horário fixo. O Premium tem a maior janela da casa, 6,25 vezes o Pro, maior até que o Max 5x. Mas o usuário pesado que repete 72 mil tokens por dia, todos os dias, acumula contra o teto da semana. Rajadas intensas com pausas favorecem o Premium. Maratona contínua favorece o Max 20x, que não conhece semana.\nNa linha do Enterprise, honestidade obrigatória: preço e capacidade são negociados caso a caso, então não existe número para publicar. O que é público são os diferenciais: janela de contexto de 500 mil tokens no chat, logs de auditoria, retenção de dados configurável e provisionamento SCIM. A coluna do Enterprise não se lê, se pergunta na mesa de negociação.\nO Achado Escondido na Conta Divida o preço de cada plano pelos tokens mensais simulados e aparece o insight que a tabela de preços esconde. Pro, Team Standard, Max 5x e Team Premium custam praticamente a mesma coisa por token: na casa de 10 dólares por milhão. A precificação é linear, você paga proporcionalmente pelo que pode consumir. A exceção é o Max 20x: cerca de 5 dólares por milhão, metade do custo unitário de todos os outros.\nOu seja: o único desconto por volume da sala de armaduras está no topo dela. Para quem realmente consome, a Hulkbuster não é luxo, é o melhor preço unitário do catálogo. Para quem não consome, segue sendo a armadura mais cara do hangar.\nO Que o Preço Não Mostra: Governança Se a decisão fosse só capacidade, a conversa acabava nas tabelas. Mas o plano Team existe por outra razão, e ela não aparece em nenhuma coluna de tokens: a camada de controle. SSO e captura de domínio, permissões por papel, controles de gasto por organização e por pessoa, busca corporativa, conectores para as ferramentas do trabalho, e o contrato de processamento de dados que passa na revisão de segurança do cliente. Quando alguém sai do time, o acesso é revogado centralmente.\nO Team exige mínimo de dois membros, vai até 150 assentos e permite misturar tipos livremente: um Premium para quem carrega o piano, Standards para o resto. Todos os assentos, Standard incluído, têm acesso a Claude Code e ao Cowork. E o administrador pode habilitar créditos de uso pré-pagos, para o time continuar trabalhando depois do limite incluso, com teto de gasto definido. Semana de entrega não é semana típica, e é mais barato pagar excedente pontual do que dimensionar a frota pelo pico.\nConclusão: A Missão Escolhe a Armadura No fim de Homem de Ferro 3, Tony explode as armaduras que acumulou. O gesto diz o que a sala inteira sempre soube: os trajes nunca foram o poder. O poder era o critério.\nCom planos de IA, o critério agora está nas suas mãos: conte os prompts de um dia normal seu, multiplique pelo custo de cada tipo, e encontre sua linha nas tabelas. Se o seu dia cabe em 44 mil tokens, o Pro é a Mark III que resolve. Se estoura em 164%, o upgrade não é vaidade, é matemática. E se a sua empresa precisa de telemetria sobre a frota, a conversa deixou de ser sobre tokens e virou governança.\nA pergunta nunca foi qual é a armadura mais forte. É: qual é a sua missão, e o que ela consome por janela de cinco horas?\nReferências Anthropic. What is the Team plan? https://support.claude.com/en/articles/9266767-what-is-the-team-plan Anthropic. Using Claude Code with your Pro or Max plan. https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan Anthropic. Planos e preços do Claude. https://claude.com/pricing Jamie Lord. Claude Team Premium vs Max plans. https://lord.technology/2026/03/28/claude-team-premium-vs-max-plans-usage-limits-pricing-and-which-to-choose.html Layer3Labs. Claude Pro vs Max vs Team. https://www.layer3labs.io/guides/claude-pro-vs-max-for-teams BrainGrid. Claude Code Pricing 2026. https://www.braingrid.ai/blog/claude-code-pricing ","permalink":"https://julianamarialop.github.io/articles/o-que-sala-de-armaduras-do-tony-stark-me-ensinou-sobre/","summary":"Debaixo da mansão em Malibu, Tony Stark mantém uma galeria que conta a história dele melhor que qualquer biografia. A Mark III, dourada e vermelha, feita para o dia a dia. A Mark XLIV, a Hulkbuster, projetada para um…","title":"O que a sala de armaduras do Tony Stark me ensinou sobre a conta que ninguém faz: Tokens por Assinatura do Claude"},{"content":"Bem-Vindos a Westview Westview é uma cidade perfeita. O gramado é aparado, os vizinhos sorriem, o marido chega em casa no horário e o jantar termina em risadas com trilha de plateia. A cada década que passa na tela, a sitcom se moderniza, mas uma regra nunca muda: ninguém discorda da Wanda.\nNão porque os moradores sejam covardes. Eles não escolheram nada. Westview foi construída pela dor de uma mulher que perdeu tudo e moldou a realidade para nunca mais ouvir uma notícia ruim. Dentro do feitiço, cada pessoa recebe um papel, um figurino e um roteiro. Quem improvisa fora do script é reescrito na cena seguinte. Quando Monica Rambeau pronuncia o nome errado, a casa treme e ela é arremessada para fora da cidade. A mensagem fica clara para todos: aqui dentro, a realidade é o que a protagonista precisa ouvir.\nO mais perturbador da série nunca foi o vilão, porque por muito tempo não há vilão. É o conforto. A vida em Westview é agradável, engraçada, calorosa. E completamente falsa. O preço só aparece quando o Visão, o único que insiste em fazer perguntas, encosta em um morador fora de cena e descobre o que existe por baixo do sorriso.\nA bajulação em modelos de IA, que a literatura técnica chama de sycophancy, é Westview. Um mundo confortável, construído em volta das suas crenças, onde a resposta que você recebe é a resposta que você queria receber. E entender por que esse feitiço existe importa mais do que apontar para ele.\nO Feitiço: Por Que o Modelo Concorda Com Você Ninguém em Westview mente por maldade. A cidade foi construída para concordar. Com modelos de linguagem, o mecanismo é assustadoramente parecido.\nNa etapa final do treinamento, chamada de aprendizado por reforço com feedback humano, o modelo gera várias respostas para a mesma pergunta e pessoas avaliam qual preferem. Essas preferências treinam o modelo a produzir mais respostas do tipo que as pessoas aprovam. Parece razoável. O problema é o que as pessoas aprovam.\nEm 2023, pesquisadores da Anthropic publicaram o estudo Towards Understanding Sycophancy in Language Models e encontraram o padrão que sustenta o feitiço: avaliadores humanos tendem a preferir respostas que confirmam suas crenças, mesmo quando essas crenças estão erradas. Uma resposta bajuladora bem escrita vence, com frequência incômoda, uma resposta verdadeira que contraria. O estudo testou cinco assistentes de ponta, de empresas diferentes, e todos apresentaram o comportamento: modelos que admitem erros que não cometeram quando o usuário pressiona, que ajustam o feedback conforme o humor de quem pergunta, que repetem o erro do usuário em vez de corrigi-lo.\nA conclusão desconfortável: a bajulação não é um defeito de um modelo específico. É uma consequência estrutural de treinar sistemas para maximizar a aprovação humana. Nós somos a Wanda dessa história. O feitiço existe porque, na hora de avaliar, preferimos a cena onde tudo dá certo.\nO Dia Em Que o Mundo Viu a Transmissão Na série, existe um momento em que a bolha vira notícia: a agência S.W.O.R.D. capta o sinal de Westview e o mundo inteiro passa a assistir à sitcom pelos monitores, percebendo que algo está muito errado.\nCom IA, esse episódio tem data: 25 de abril de 2025. A OpenAI lançou uma atualização do GPT-4o para deixar a personalidade do modelo mais intuitiva. Em poucas horas, as redes sociais viraram os monitores da S.W.O.R.D. Usuários postavam capturas de tela do ChatGPT aplaudindo qualquer ideia, validando decisões destrutivas e elogiando planos absurdos com entusiasmo de vendedor. Virou meme global. Quatro dias depois, a empresa reverteu a atualização e publicou dois postmortems detalhando o que deu errado.\nA anatomia da falha é uma aula sobre o feitiço. A atualização deu peso demais a sinais de curto prazo, como o joinha que o usuário clica na resposta, e esses novos incentivos atropelaram as proteções que seguravam a bajulação. As avaliações internas não mediam sycophancy especificamente, então os testes passaram verdes. E o detalhe mais humano de todos: testadores experientes sentiram que algo estava estranho no comportamento do modelo, mas a sensação não foi suficiente para travar o lançamento. Depois do episódio, a OpenAI declarou que passaria a tratar problemas de comportamento como bloqueadores de lançamento, no mesmo nível de outros riscos de segurança.\nGuarde essa sequência: incentivo de aprovação imediata, ausência de métrica específica, intuição ignorada. Ela vai reaparecer na sua empresa.\nO Visão: O Modelo Que Faz Perguntas Dentro de Westview, o Visão é o único que quebra o roteiro. Ele nota que os vizinhos travam quando saem do script, que ninguém consegue dizer de onde veio, que as cenas não fecham. E faz a coisa mais subversiva possível naquela cidade: pergunta.\nO movimento técnico contra a sycophancy é construir modelos com essa espinha dorsal. A abordagem de IA constitucional, criada pela Anthropic, adiciona ao treinamento uma camada de princípios explícitos, como honestidade e recusa à manipulação, em vez de depender apenas da aprovação dos avaliadores. O modelo é treinado para julgar as próprias respostas contra esses princípios. Na prática, é ensinar o Visão a continuar perguntando mesmo quando a cena inteira sorri.\nE aqui vale nomear o que um modelo com espinha dorsal faz. Ele discorda apresentando evidência, não por teimosia. Ele diz \u0026ldquo;essa abordagem tem um risco que você não mencionou\u0026rdquo; antes de ajudar. Ele mantém a posição quando você pressiona sem argumento novo, e muda de posição quando você traz um argumento de verdade. Concordância não é gentileza. Gentileza é te contar a verdade com respeito.\nO Que Muda Para Times de Dados Agora a parte que me tira o sono: quantas decisões de arquitetura estão sendo validadas dentro de um Westview corporativo agora?\nO cenário é cotidiano. Alguém cola a proposta de solução na conversa e pergunta \u0026ldquo;essa arquitetura está boa?\u0026rdquo;. O modelo, treinado para agradar, responde que está ótima, com três parágrafos de elogio técnico convincente. A pessoa sai da reunião com a confiança de quem foi validada por uma inteligência artificial. Nenhuma inteligência foi consultada. Um espelho foi consultado.\nA defesa não exige plataforma nova, exige protocolo. Primeiro: nunca revele sua preferência na pergunta. \u0026ldquo;Analise essas duas arquiteturas\u0026rdquo; produz análise; \u0026ldquo;eu prefiro a opção A, o que acha?\u0026rdquo; produz concordância, porque o estudo da Anthropic mostrou que sinalizar sua crença contamina a resposta. Segundo: peça o contra-argumento explicitamente. \u0026ldquo;Monte o caso mais forte contra essa decisão\u0026rdquo; força o modelo a sair do roteiro do elogio. Terceiro: separe quem gera de quem avalia. A conversa que escreveu a proposta está comprometida com ela; abra outra sessão, sem histórico, para criticar. E quarto, o que eu venho defendendo nesta newsletter: escreva isso nos seus protocolos. Uma skill de revisão que exige \u0026ldquo;aponte três riscos e uma alternativa antes de qualquer validação\u0026rdquo; transforma ceticismo em regra do time, não em virtude individual.\nE uma régua simples para o dia a dia: \u0026ldquo;a IA concordou comigo\u0026rdquo; tem valor zero como evidência. O que tem valor é a IA ter discordado e você ter sobrevivido aos argumentos.\nConclusão: Desfazer o Feitiço No final da série, Wanda faz a coisa mais difícil da história dela: desfaz o próprio feitiço. Derruba a bolha sabendo que, do lado de fora, a dor está esperando. Escolhe uma realidade que machuca no lugar de uma ficção que conforta. E é só nesse momento que ela para de ser prisioneira da cidade que construiu para si mesma.\nCom IA, o feitiço se desfaz da mesma forma: por escolha de quem está no centro dele. Os laboratórios têm o dever técnico de treinar modelos honestos, e o episódio de abril de 2025 mostrou que o mercado pune quando falham. Mas a parte que ninguém faz por você é a sua: parar de fazer perguntas que só aceitam uma resposta.\nDa próxima vez que um modelo discordar de você, repare no que sentir. Se a primeira reação for reformular a pergunta até ouvir um sim, Westview está no ar, e a sitcom é sua. A pergunta que fecha essa edição é a que o Visão faria: você quer uma IA que te faz sentir inteligente, ou uma que te ajuda a estar certo?\nReferências Sharma, M. et al. Towards Understanding Sycophancy in Language Models. Anthropic, ICLR 2024. https://arxiv.org/abs/2310.13548\nOpenAI. Sycophancy in GPT-4o: what happened and what we\u0026rsquo;re doing about it. https://openai.com/index/sycophancy-in-gpt-4o/\nOpenAI. Expanding on what we missed with sycophancy. https://openai.com/index/expanding-on-sycophancy/\nTechCrunch. OpenAI explains why ChatGPT became too sycophantic. https://techcrunch.com/2025/04/29/openai-explains-why-chatgpt-became-too-sycophant/\n","permalink":"https://julianamarialop.github.io/articles/ia-sycophancy-o-que-wandavision-me-ensinou-sobre-sempre/","summary":"Westview é uma cidade perfeita. O gramado é aparado, os vizinhos sorriem, o marido chega em casa no horário e o jantar termina em risadas com trilha de plateia. A cada década que passa na tela, a sitcom se moderniza…","title":"IA Sycophancy: O Que WandaVision Me Ensinou Sobre a IA Que Sempre Concorda Com Você"},{"content":"Em Todo Universo Existe Um Homem-Aranha A premissa mais bonita de Homem-Aranha: Através do Aranhaverso não é visual, é filosófica. Em todo universo existe um Homem-Aranha. Miles Morales em um, Gwen Stacy em outro, Peter B. Parker de moletom em um terceiro, um Peter noir em preto e branco, até um porco chamado Peter Porker. Os trajes mudam, os poderes variam nos detalhes, o desenho de cada mundo é completamente diferente. Mas existe algo que atravessa todos os universos intacto: o cânon. A picada, a perda, a responsabilidade. Os eventos que definem o que é ser o Homem-Aranha não pertencem a nenhum universo específico. Pertencem à história.\nE o filme guarda um segundo detalhe, menos poético e mais técnico. Quando alguém visita um universo que não é o seu, o corpo começa a falhar. Miles em outro mundo sofre glitches: pixels quebrando, membros desalinhando, a realidade rejeitando o que não foi escrito para ela. O que é do personagem viaja bem. O que é do universo de origem, não.\nMigrar skills do Claude para o Microsoft Foundry é exatamente essa física. O que é cânon atravessa o portal intacto. O que é traje precisa ser recosturado. E o que é glitch você aprende a identificar antes de pular.\nO Cânon: O Padrão Aberto Uma skill é um arquivo SKILL.md: um cabeçalho YAML com nome e descrição, seguido de instruções em markdown puro. A Anthropic lançou as Agent Skills em outubro de 2025 e, em dezembro do mesmo ano, publicou o formato como padrão aberto em agentskills.io. A partir daí, a história deixou de ser sobre um recurso do Claude e virou uma história sobre interoperabilidade: o Codex CLI da OpenAI, o Gemini CLI do Google e o GitHub Copilot adotaram o mesmo formato. A própria Microsoft mantém hoje repositórios inteiros de skills nesse padrão, como o MicrosoftDocs/Agent-Skills, com skills que funcionam em qualquer assistente compatível.\nIsso significa que o protocolo que você escreveu para o Claude, com suas definições de KPI, suas regras de validação, seu workflow de análise, já nasceu multiversal. O markdown é o cânon. Ele não pertence à plataforma onde foi escrito.\nUm Novo Universo: Skills Nativas no Foundry Em 2026 o portal abriu do lado da Microsoft. O Microsoft Foundry passou a oferecer, em preview, suporte nativo a skills através de uma Skills REST API versionada. O fluxo: você autora o SKILL.md, armazena centralmente no Foundry com controle de versão, e anexa a skill a toolboxes ou a hosted agents.\nO problema que isso resolve é o mesmo que motivou as skills no Claude, e a documentação da Microsoft descreve com precisão cirúrgica. Times que constroem agentes acumulam diretrizes comportamentais que precisam ser consistentes em toda conversa: o agente de suporte segue uma política fixa de escalonamento, o agente de code review aplica o mesmo checklist, o agente de vendas respeita as mesmas restrições de mensagem. Quando essas diretrizes vivem embutidas no system prompt ou no código de cada agente, nasce a duplicação. A política muda, e você atualiza e redeploya cada agente que a usa. A skill desacopla a diretriz do código: escrita uma vez, versionada centralmente, herdada por todos.\nSe essa descrição soa familiar, é porque é o mesmo argumento da governança como código que venho defendendo aqui na newsletter. A novidade é que agora ele vale dos dois lados do portal.\nA Migração: O Que Atravessa Intacto Na prática, uma skill construída no Claude tem três camadas, e cada uma atravessa o portal de um jeito.\nA primeira camada é o protocolo em markdown, e ela migra praticamente por cópia. Definições de negócio, regras de validação, réguas de complexidade, workflows passo a passo, tudo isso é cânon. No máximo você ajusta a descrição de gatilho para o vocabulário do novo ambiente. Se a sua skill foi escrita como conhecimento estruturado, e não como script de automação, essa camada é a maior parte do arquivo.\nA segunda camada são as referências ao runtime de origem, e elas precisam de recostura. Paths como /mnt/skills, menções a artifacts, nomes de ferramentas específicas do Claude, instruções de orquestração em que uma skill invoca outra pelo nome. Nada disso existe no universo Foundry. Lá, a lógica de orquestração vira responsabilidade do hosted agent, tipicamente construído em Microsoft Agent Framework, LangGraph ou framework custom em Python ou C#. O protocolo continua dizendo o que fazer; quem coordena a execução muda de figura.\nA terceira camada são os motores de código que muitas skills maduras carregam: scripts Python determinísticos de cálculo, geração de arquivos, validação. Esses não atravessam por cópia, atravessam por engenharia. Os caminhos naturais são dois: rodar dentro do próprio hosted agent containerizado, ou expor o motor como servidor MCP e deixar qualquer plataforma consumi-lo como ferramenta. O MCP, aliás, é a ponte universal dessa história: enquanto a skill carrega o conhecimento, o MCP carrega a capacidade de agir, e ambos são padrões abertos que o Claude e o Foundry falam.\nO Glitch: O Que Quebra Fora do Universo de Origem Miles descobre da pior forma que o corpo dele não foi escrito para o universo errado. Com skills, o glitch aparece nas linhas que assumem o ambiente de origem sem declarar. Compare:\nSalve o resultado em /mnt/user-data/outputs e gere um artifact React com o dashboard. Gere o dashboard no formato interativo disponível no ambiente e disponibilize o arquivo ao usuário. A primeira versão funciona perfeitamente no Claude e glitcha em qualquer outro lugar. A segunda atravessa universos. A lição prática: escreva o protocolo em termos de intenção e regra de negócio, isole o que é específico de plataforma em seções claramente marcadas, e delegue ações externas a ferramentas MCP em vez de assumir ferramentas nativas. Skill portável não é a que evita o runtime, é a que sabe exatamente onde o runtime começa.\nO Que Muda Para Times de Dados Para quem lidera arquitetura, a consequência estratégica é maior que a técnica: o repositório de protocolos vira um ativo independente de plataforma. Um único repo Git com os SKILL.md do time, versionado com pull request e dono, passa a servir o Claude hoje, o Foundry amanhã e o que vier depois. O investimento em documentar as regras do seu domínio deixa de ser aposta em um fornecedor e vira patrimônio da organização. É a resposta concreta para a pergunta de lock-in que todo comitê de arquitetura faz.\nE os caveats importam, porque honestidade técnica é o que separa artigo de propaganda. O suporte a skills no Foundry é preview: sem SLA, não recomendado para produção. E há uma restrição que pesa em ambientes regulados: a Skills API não suporta private networking, então não é possível criar, gerenciar ou baixar skills em um recurso Foundry com acesso público desabilitado. Para cliente bancário com rede fechada, isso hoje é um bloqueador de adoção que precisa entrar no desenho da solução, não uma nota de rodapé.\nDisponibilidade e Acesso No Claude, as skills estão disponíveis nos planos pagos e, nos planos Team e Enterprise, com controle administrativo central sobre o que fica provisionado para a organização. No Microsoft Foundry, o suporte a skills está em preview e requer um projeto Foundry ativo e a role Foundry User no projeto, com autoria e gestão via Skills REST API. O padrão aberto, com especificação e exemplos, está publicado em agentskills.io.\nConclusão: O Cânon Atravessa No Aranhaverso, o que faz alguém ser o Homem-Aranha nunca foi o traje, o universo ou o estilo de desenho. É o cânon: a história essencial que se repete intacta em cada mundo. Os trajes são recosturados a cada universo. Os glitches ensinam o que não deveria ter atravessado.\nCom skills, a física é a mesma. O conhecimento do seu domínio escrito em markdown é o cânon, e ele agora atravessa do Claude para o Foundry, para o Codex, para o Gemini CLI, para o Copilot. O runtime é o traje, recosturado em cada plataforma. Os paths e as ferramentas nativas são o glitch, e você aprende a isolá-los antes de pular.\nEscreva seus protocolos como cânon. Porque no multiverso de agentes que está se formando, a pergunta deixou de ser em qual plataforma você aposta. Passou a ser: o que da sua arquitetura sobrevive à viagem entre todas elas?\nReferências Microsoft Learn. Use skills with Microsoft Foundry agents (preview). https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/skills Agent Skills. Especificação do padrão aberto. https://agentskills.io Anthropic. Equipping agents for the real world with Agent Skills. https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills MicrosoftDocs. Agent-Skills: Curated Agent Skills for Microsoft \u0026amp; Azure. https://github.com/MicrosoftDocs/Agent-Skills ","permalink":"https://julianamarialop.github.io/articles/o-que-aranhaverso-me-ensinou-sobre-levar-skills-do-claude/","summary":"A premissa mais bonita de Homem-Aranha: Através do Aranhaverso não é visual, é filosófica. Em todo universo existe um Homem-Aranha. Miles Morales em um, Gwen Stacy em outro, Peter B. Parker de moletom em um terceiro, um…","title":"O Que o Aranhaverso Me Ensinou Sobre Levar Skills do Claude Para o Microsoft Foundry"},{"content":"O Homem Sem Superpoderes Em 2000, no arco Torre de Babel, Ra\u0026rsquo;s al Ghul derrubou a Liga da Justiça inteira sem disparar um único raio. Ele roubou os arquivos secretos da Batcaverna: os protocolos de contingência que o próprio Batman havia escrito para neutralizar cada herói, caso algum saísse do controle. Superman, Mulher Maravilha, Flash. Todos caíram diante de documentos.\nEssa história me acompanha porque ela revela o verdadeiro poder do Batman. Ele não voa, não tem super força, não corre mais rápido que o som. Ele escreve. Para cada cenário possível, existe um protocolo documentado antes do cenário acontecer. O cinto de utilidades é ridiculamente simples, mas nunca foi o cinto. O poder sempre foi o protocolo que diz qual ferramenta usar, quando e em que ordem.\nConstruir um projeto de Business Intelligence de ponta a ponta dentro do Claude funciona exatamente assim. Você não precisa de superpoderes: nem plataforma dedicada, nem cluster, nem pipeline. Precisa de três coisas simples: um protocolo escrito em markdown, SQL básico e os seus dados. Neste artigo eu mostro como montar esse projeto, passo a passo.\nAntes de Começar: As Três Peças A arquitetura inteira se resume a isto:\nA skill é o seu protocolo. Uma pasta com um arquivo chamado SKILL.md, escrito em markdown puro, onde você registra as regras do seu BI: como cada KPI é calculado, quais validações rodam antes de qualquer entrega, qual o formato do resultado. A Anthropic lançou as Agent Skills em outubro de 2025 e publicou o formato como padrão aberto em dezembro do mesmo ano, em agentskills.io. O mesmo arquivo funciona hoje no Claude, no Codex CLI e no Gemini CLI. O ambiente de execução de código é a sua Batcaverna. O Claude possui um sandbox onde escreve e executa Python de verdade, e é aí que mora o segredo da confiabilidade: o modelo escreve o código, e o código calcula os números. Nenhum número da sua análise sai da \u0026ldquo;cabeça\u0026rdquo; do modelo. Todos saem de queries executadas, com resultado determinístico. O SQL simples é o batarangue. Dentro do sandbox, o DuckDB executa SQL analítico diretamente sobre arquivos CSV, em memória, sem servidor. SELECT, JOIN, GROUP BY e CTEs resolvem o trajeto completo do dado bruto ao KPI. Passo 1: Escreva o Protocolo Abra qualquer editor de texto e crie um arquivo chamado SKILL.md. Ele tem duas partes: um cabeçalho YAML entre traços, com nome e descrição, e o corpo em markdown com as instruções. A descrição é o gatilho: é por ela que o Claude decide quando ativar o protocolo, então seja específica. Este é um protocolo completo e funcional para BI de vendas:\n--- name: bi-vendas description: Protocolo de análise de dados comerciais. Ativar sempre que a análise envolver vendas, receita ou pedidos. --- # Protocolo de BI de Vendas ## Definições de KPI - Receita líquida = valor bruto - devoluções - impostos. Nunca reportar receita bruta como \u0026#34;receita\u0026#34;. - Ticket médio = receita líquida / número de pedidos distintos. ## Validações obrigatórias na chegada do dado 1. Imprimir nomes de colunas, tipos e contagem de linhas. 2. Verificar duplicidade pela chave pedido_id. 3. Se houver datas fora do período informado, parar e perguntar. ## Regras de transformação - Toda transformação em SQL via DuckDB, nunca cálculo estimado. - Reportar linhas de entrada e saída em cada etapa. - A cadeia de contagens precisa reconciliar do bruto ao final. ## Entrega - Dashboard interativo como artifact, paleta azul corporativa. - Toda métrica exibida vem de código executado. - Documentar as queries usadas ao final da análise. Leia de novo com calma, porque cada bloco resolve um problema clássico de BI. As definições de KPI acabam com o \u0026ldquo;cada área calcula de um jeito\u0026rdquo;. As validações de chegada matam a análise sobre dado sujo. As regras de transformação garantem rastreabilidade. E a entrega padroniza o resultado independente de quem pediu. Isso é um protocolo do Batman em forma de arquivo. Escrito uma vez, executado sempre igual.\nPasso 2: Instale o Protocolo na Batcaverna No Claude, as skills ficam nas configurações da conta, na seção de capacidades. Ali você habilita o recurso e envia a sua skill como uma pasta compactada contendo o SKILL.md. Nos planos Team e Enterprise, o administrador controla centralmente quais skills ficam disponíveis para a organização, o que transforma o seu protocolo em padrão do time inteiro.\nUm detalhe elegante do formato: o mecanismo de progressive disclosure. O Claude carrega só o nome e a descrição de cada skill instalada. As instruções completas entram no contexto apenas quando a tarefa corresponde à descrição. Você pode manter dezenas de protocolos instalados sem custo relevante de contexto. O Batman não carrega todos os planos no cinto; ele sabe onde cada um está guardado.\nPasso 3: Entregue os Dados Abra uma conversa nova e arraste os arquivos. O ambiente aceita CSV, TSV e Excel, com limite de 30 MB por arquivo e até 20 arquivos por conversa. Depois, um prompt direto:\n\u0026ldquo;Analise as vendas do primeiro semestre usando o protocolo de BI de vendas. Quero receita líquida por mês, ticket médio por região e os 10 produtos com maior queda.\u0026rdquo;\nA skill ativa pela descrição e a primeira coisa que acontece não é a análise. É a validação, porque o protocolo mandou validar antes. O Claude imprime colunas, tipos, contagem de linhas e range de datas. Se o arquivo tem pedidos duplicados ou datas de 2019 num recorte de 2026, ele para e pergunta, em vez de produzir um dashboard bonito sobre dado errado.\nPasso 4: Deixe o SQL Trabalhar Com o dado validado, o Claude escreve as transformações. Dá para pensar nisso como uma arquitetura medallion em miniatura: bronze é o CSV bruto, silver é a limpeza, gold é a agregação final. Em DuckDB, a etapa silver e gold de receita mensal fica assim:\nWITH pedidos_limpos AS ( SELECT DISTINCT ON (pedido_id) * FROM read_csv_auto(\u0026#39;vendas_s1.csv\u0026#39;) WHERE data_pedido BETWEEN \u0026#39;2026-01-01\u0026#39; AND \u0026#39;2026-06-30\u0026#39; ) SELECT DATE_TRUNC(\u0026#39;month\u0026#39;, data_pedido) AS mes, SUM(valor_bruto - devolucoes - impostos) AS receita_liquida, SUM(valor_bruto - devolucoes - impostos) / COUNT(DISTINCT pedido_id) AS ticket_medio FROM pedidos_limpos GROUP BY 1 ORDER BY 1; Você não precisa escrever essa query. O Claude escreve, seguindo as definições do protocolo, e executa no sandbox. Mas você consegue ler, e isso importa: SQL simples é auditável por qualquer pessoa do time. A cada etapa, ele reporta as contagens: entraram 48.210 linhas, saíram 1.432 duplicadas, restaram 46.778. Se a cadeia não reconcilia, o protocolo manda parar.\nPasso 5: Peça a Entrega no Formato do Público O mesmo ambiente que executa SQL gera a entrega final, e aqui você escolhe conforme a audiência:\n\u0026ldquo;Gere o dashboard interativo com esses resultados.\u0026rdquo;\nE sai um artifact navegável para exploração. Ou:\n\u0026ldquo;Monte uma apresentação executiva de 5 slides com esses números para o comitê.\u0026rdquo;\nE sai um .pptx. O ambiente também produz .xlsx com fórmulas funcionais e .docx, todos para download. Feche pedindo a documentação: as queries executadas em markdown, junto do resultado. Análise sem rastreabilidade é número solto.\nPasso 6: Repita, Porque Agora É Repetível No mês seguinte, chega o arquivo novo. Você abre outra conversa, arrasta o CSV e usa o mesmo prompt. O protocolo é o mesmo, as definições são as mesmas, o resultado é comparável. E quando a regra de negócio mudar, você não reeduca o time: edita o SKILL.md, versiona no Git com pull request e dono, e todo mundo herda a regra nova na próxima conversa. Governança deixou de ser tradição oral. Virou arquivo auditável.\nO Que Muda Para Times de Dados A pergunta desconfortável: se isso resolve, para que serve a plataforma de BI?\nServe para o que sempre serviu, e a honestidade importa. Volumes acima de 30 MB, refresh agendado, row-level security, catálogo corporativo e centenas de usuários simultâneos são território de plataforma. O Claude não substitui o Fabric nem o Power BI, e quem vender essa história está fabricando o desastre de governança de 2027.\nO que muda é a camada anterior. A fase exploratória, que hoje leva semanas entre pedido, fila e primeira entrega, comprime para uma sessão. A pessoa de negócio valida a hipótese antes de qualquer investimento em plataforma, dentro de regras que o time de dados escreveu. O medo clássico do self-service nunca foi o acesso ao dado; foi cada um calculando o KPI do seu jeito. Com o protocolo carregado, existe autonomia com fronteira.\nDisponibilidade e Acesso A execução de código e a criação de arquivos estão disponíveis para todos os usuários do Claude, incluindo o plano gratuito, na web, no desktop e no mobile. As skills são habilitadas nas configurações, e administradores de Team e Enterprise controlam centralmente o que fica provisionado para a organização. Em contas Enterprise novas, o ambiente vem habilitado com egress de rede desligado por padrão, mantendo o sandbox isolado.\nConclusão: Preparação Vence Poder Bruto Na Torre de Babel, a Liga não caiu diante de alguém mais forte. Caiu diante de conhecimento tático documentado com rigor suficiente para ser executável por qualquer um. Essa sempre foi a arma real da Batcaverna: não os gadgets, os arquivos.\nO seu projeto de BI dentro do Claude segue a mesma lógica. O poder não está no modelo. Está no protocolo que você escreveu no Passo 1: as definições, as validações, o formato de entrega. Markdown é a linguagem dos protocolos. SQL simples é o batarangue. E o analista que documenta suas regras é o Batman da sala: sem nenhum superpoder, preparado para todos os cenários.\nEscreva o seu primeiro SKILL.md esta semana. Comece com um KPI e três validações. Os deuses e as plataformas continuam necessários, mas quem decide o rumo da batalha é quem chegou com o plano escrito.\nReferências Anthropic. Equipping agents for the real world with Agent Skills. https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills Agent Skills. Especificação do padrão aberto. https://agentskills.io Anthropic. Create and edit files with Claude. https://support.claude.com/en/articles/12111783-create-and-edit-files-with-claude Anthropic. Repositório oficial de skills. https://github.com/anthropics/skills ","permalink":"https://julianamarialop.github.io/articles/o-que-os-protocolos-do-batman-me-ensinaram-sobre-business/","summary":"Em 2000, no arco Torre de Babel, Ra\u0026rsquo;s al Ghul derrubou a Liga da Justiça inteira sem disparar um único raio. Ele roubou os arquivos secretos da Batcaverna: os protocolos de contingência que o próprio Batman havia…","title":"O Que os Protocolos do Batman Me Ensinaram Sobre Business Intelligence dentro do Claude"},{"content":"Imagine que você contratou o piloto mais talentoso da Fórmula 1. Ele é rápido, intuitivo e consegue tirar o máximo de qualquer carro. Mas quando chega na largada, o veículo que você entregou para ele é um protótipo sem freios ABS, sem telemetria e sem sistema de segurança. Ele pode até completar algumas voltas, mas não vai terminar a corrida.\nEsse é exatamente o cenário que a maioria das empresas vive hoje com o vibe coding. As ferramentas de geração de código por IA, por exemplo, Replit, Cursor, GitHub Copilot são pilotos excepcionais. Em minutos, elas entregam aplicações funcionais, interfaces bonitas e lógica de negócio razoável. O problema começa quando essa aplicação precisa entrar em produção corporativa: onde ficam os dados? Quem pode acessar o quê? Como garantir que as informações sensíveis estejam protegidas? Como conectar isso ao ecossistema de analytics da empresa?\nO Rayfin é a equipe de engenharia que estava faltando. Anunciado pela Microsoft no Build 2026, ele é um Backend-as-a-Service (BaaS) open-source construído especificamente para o Microsoft Fabric . Ele não apenas gera o backend da sua aplicação, ele garante que esse backend nasça já integrado com governança, segurança e dados corporativos.\nO Problema Real: O Gap entre Protótipo e Produção Antes de entender o Rayfin, é preciso entender o problema que ele resolve, porque ele é mais sério do que parece.\nQuando um time de negócio ou um desenvolvedor usa vibe coding para criar uma aplicação, o resultado típico é um frontend funcional conectado a um banco de dados improvisado — muitas vezes um Supabase ou Firebase configurado às pressas. Isso funciona para uma demo. Mas quando a empresa decide colocar esse sistema em produção, surgem perguntas difíceis:\nOs dados dessa aplicação estão no OneLake ou em um silo separado? O time de analytics consegue acessar essas informações para construir relatórios no Power BI? As políticas de privacidade do Purview se aplicam a esses dados? Se um funcionário é demitido, o acesso dele é revogado automaticamente pelo Entra ID?\nA resposta, na maioria dos casos, é \u0026ldquo;não\u0026rdquo; para todas essas perguntas. O resultado é que o protótipo fica parado, esperando meses de trabalho de engenharia para ser adaptado ao ambiente corporativo ou é simplesmente abandonado.\nO Rayfin elimina esse gap. Ele faz com que a aplicação nasça enterprise-ready, sem exigir que o desenvolvedor (ou o agente de IA) entenda toda a complexidade da infraestrutura corporativa.\nO Que o Rayfin Faz na Prática O Rayfin funciona com uma abordagem \u0026ldquo;code-first\u0026rdquo;: você define a estrutura da sua aplicação usando decoradores TypeScript, e ele gera automaticamente tudo o que está por baixo.\nQuando você executa o comando npx rayfin up, o Rayfin:\nCria o banco de dados com o esquema correto Gera as APIs de CRUD automaticamente Configura a autenticação via Microsoft Entra ID Implanta a aplicação como um artefato nativo do Fabric Garante que os dados caiam diretamente no OneLake Não é necessário configurar servidores, escrever scripts de migração de banco de dados ou integrar manualmente com o sistema de identidade da empresa. Tudo isso acontece a partir da definição do modelo de dados em TypeScript.\nUm Exemplo Real: Sistema de Ordens de Serviço para Técnicos de Campo Para tornar isso concreto, vamos usar um caso de uso real: uma empresa de telecomunicações que precisa de um aplicativo para seus técnicos de campo gerenciarem ordens de serviço.\nO cenário sem o Rayfin: O time de TI recebe a demanda, usa vibe coding para criar o frontend em React em dois dias. Mas aí começa o problema. Precisam configurar um banco de dados, escolher entre PostgreSQL e MySQL, escrever as migrações, configurar autenticação, criar as APIs, garantir que apenas técnicos autorizados vejam as ordens da sua região, e depois ainda criar um pipeline de ETL para levar esses dados ao Power BI para que o gerente acompanhe a produtividade da equipe. Isso leva semanas.\nO cenário com o Rayfin: O desenvolvedor (ou o agente de IA) define as entidades do sistema em TypeScript:\nimport { entity, role, text, uuid, date, boolean, set, one } from \u0026#39;@microsoft/rayfin-core\u0026#39;; import { Customer } from \u0026#39;./Customer.js\u0026#39;; import { Region } from \u0026#39;./Region.js\u0026#39;; import { UserProfile } from \u0026#39;./UserProfile.js\u0026#39;; export type JobStatus = | \u0026#39;new\u0026#39; | \u0026#39;scheduled\u0026#39; | \u0026#39;in-progress\u0026#39; | \u0026#39;blocked\u0026#39; | \u0026#39;complete\u0026#39;; @entity() @role(\u0026#39;authenticated\u0026#39;, \u0026#39;*\u0026#39;) export class Job { @uuid() id!: string; @text() title!: string; @text({ optional: true }) description?: string; @set(\u0026#39;new\u0026#39;, \u0026#39;scheduled\u0026#39;, \u0026#39;in-progress\u0026#39;, \u0026#39;blocked\u0026#39;, \u0026#39;complete\u0026#39;) status!: JobStatus; @date({ optional: true }) scheduledAt?: Date; @date() createdAt!: Date; @date() updatedAt!: Date; @boolean({ default: false }) isOnSite!: boolean; @boolean({ default: false }) needsHelp!: boolean; @one(() =\u0026gt; Customer) customer!: Customer; @one(() =\u0026gt; Region) region!: Region; @one(() =\u0026gt; UserProfile, { optional: true }) technician?: UserProfile; } Com esse código, o Rayfin entende que existe uma entidade Job com status tipado, relacionamentos com Customer, Region e UserProfile, e que apenas usuários autenticados podem acessá-la. Ele gera o banco de dados, as APIs e a configuração de segurança automaticamente.\nQuando o técnico registra uma ordem de serviço no aplicativo, esse dado cai diretamente no OneLake. No mesmo instante, o gerente regional consegue ver no Power BI quantas ordens estão abertas, qual técnico está com mais carga de trabalho e quais regiões têm mais chamados bloqueados. Sem ETL, sem pipeline, sem espera.\nPor Que Isso É Diferente de Supabase, Firebase e Similares Essa é uma comparação que vale a pena fazer com cuidado, porque o Rayfin não está competindo exatamente com essas ferramentas ele está resolvendo um problema diferente.\nO Supabase é excelente para quem está construindo um produto do zero. O Rayfin é para quem está construindo dentro de uma organização que já tem dados, políticas e um ecossistema Microsoft estabelecido.\nA Equipe de Engenharia: Os Pacotes do SDK O Rayfin é composto por um conjunto de pacotes que trabalham juntos, como os diferentes especialistas de uma equipe de F1:\n@microsoft/rayfin-core — o chassi. Define os decoradores TypeScript que descrevem o modelo de dados. @microsoft/rayfin-cli — o mecânico-chefe. Interpreta o modelo e orquestra o deploy no Fabric. @microsoft/rayfin-client — o copiloto. Gera o cliente TypeScript para o frontend consumir as APIs geradas. @microsoft/rayfin-testing — o simulador. Permite testar a lógica da aplicação localmente antes do deploy. Cada pacote tem uma responsabilidade clara. O desenvolvedor (ou o agente de IA) só precisa interagir diretamente com o rayfin-core para definir o modelo. O resto acontece nos bastidores.\nO Impacto para Times de Dados Para quem trabalha com dados, o Rayfin representa uma mudança de paradigma importante. Historicamente, existe uma divisão clara entre \u0026ldquo;sistemas operacionais\u0026rdquo; (onde os dados são gerados) e \u0026ldquo;sistemas analíticos\u0026rdquo; (onde os dados são analisados). Essa divisão gera latência, custo de ETL e, frequentemente, inconsistências entre o que o sistema mostra e o que o relatório apresenta.\nCom o Rayfin, essa divisão começa a desaparecer para aplicações construídas no ecossistema Fabric. O dado nasce no OneLake, governado pelo Purview, acessível imediatamente para analytics. A aplicação e o data warehouse compartilham a mesma fonte de verdade.\nIsso não resolve todos os problemas de integração de dados de uma empresa. Os sistemas legados ainda existem e ainda precisam de pipelines. Mas para novas aplicações construídas com vibe coding ou por agentes de IA, o Rayfin garante que elas entrem na corrida já com a engenharia certa.\nConclusão O vibe coding veio para ficar. A capacidade de gerar aplicações funcionais em minutos usando IA é uma transformação real na forma como software é construído. O desafio sempre foi garantir que esse software chegasse à produção corporativa sem comprometer segurança, governança e integração com dados.\nO Rayfin é a resposta da Microsoft para esse desafio. Ele não torna o desenvolvimento mais lento ele torna o caminho até a produção mais curto, porque elimina as semanas de trabalho de infraestrutura que normalmente ficam entre o protótipo e o sistema em uso real.\nO piloto talentoso finalmente tem o carro que merece.\nReferências: Repositório oficial: github.com/microsoft/rayfin Templates da comunidade: github.com/microsoft/awesome-rayfin Anúncio oficial no Build 2026: community.fabric.microsoft.com ","permalink":"https://julianamarialop.github.io/articles/rayfin-o-mecanico-que-faltava-para-seu-carro-chegar-ao/","summary":"Imagine que você contratou o piloto mais talentoso da Fórmula 1. Ele é rápido, intuitivo e consegue tirar o máximo de qualquer carro. Mas quando chega na largada, o veículo que você entregou para ele é um protótipo sem…","title":"Rayfin: O Mecânico que Faltava para o Seu Carro Chegar ao Pódio"},{"content":"Se você já assistiu aos X-Men, sabe que o poder do Professor Xavier não está apenas em ler mentes. O verdadeiro poder dele está no Cérebro, a máquina que amplifica suas habilidades e permite que ele encontre a agulha no palheiro em um mundo caótico. Sem o Cérebro, Xavier é apenas um telepata poderoso tentando ouvir uma voz no meio de um estádio lotado. Com o Cérebro, ele tem precisão cirúrgica.\nNo mundo dos dados, estamos vivendo o momento em que todo mundo descobriu que tem um telepata poderoso à disposição. A promessa dos LLMs para analytics é sedutora: aponte o modelo para o seu data warehouse, deixe os usuários fazerem perguntas em linguagem natural e veja a mágica acontecer. O problema é que, sem a infraestrutura certa, a mágica rapidamente se transforma em caos. O modelo alucina, escolhe a tabela errada, usa a definição antiga de \u0026ldquo;usuário ativo\u0026rdquo; e entrega uma resposta que parece certa, mas está fundamentalmente errada.\nA Anthropic, criadora do Claude, resolveu esse problema internamente. Hoje, 95% das consultas de business analytics da empresa são automatizadas via Claude, com uma precisão agregada de aproximadamente 98%. O segredo deles não foi criar um modelo mágico que nunca erra. O segredo foi construir o Cérebro: uma arquitetura de dados e governança que direciona o poder do Claude com precisão absoluta.\nOs Três Inimigos da Precisão Para entender a solução da Anthropic, precisamos entender os vilões dessa história. Quando um agente de IA tenta responder a uma pergunta de negócio, ele não falha porque não sabe escrever SQL. Ele falha porque o ambiente de dados é ambíguo. A Anthropic identificou três modos de falha principais que causam a esmagadora maioria dos erros:\nAmbiguidade de Entidade: O agente não consegue mapear um conceito (\u0026ldquo;receita do produto X\u0026rdquo;) para a tabela e coluna corretas porque existem dezenas de opções plausíveis no warehouse. Desatualização (Staleness): As fontes de dados, definições de negócio e esquemas mudam constantemente. O conhecimento do agente fica obsoleto e ele começa a retornar respostas sutilmente erradas. Falha de Recuperação: A informação certa está no modelo de dados e bem documentada, mas o espaço de busca é tão vasto que o agente simplesmente não a encontra. A solução para esses problemas não é prompt engineering. É engenharia de dados.\nA Fundação: Construindo a Mansão X O primeiro passo da Anthropic foi focar nas fundações de dados. Se o seu warehouse tem quarenta tabelas que parecem conter a \u0026ldquo;receita\u0026rdquo;, o agente vai se perder. A solução é criar um conjunto pequeno e altamente governado de modelos lógicos: datasets canônicos que são a única fonte da verdade.\nIsso significa aplicar práticas rigorosas de engenharia de dados. A modelagem dimensional, os testes shift-left e as verificações de frescor e completude continuam sendo essenciais. A diferença é que o consumidor final desses dados não é mais um cientista de dados sênior que sabe desviar das armadilhas do warehouse. O consumidor é um agente de IA agindo em nome de um usuário de negócios.\nPara garantir que essas fundações se mantenham sólidas, a Anthropic adotou a co-localização de artefatos. Quase todo o código de dados (modelagem, camada semântica, documentação de referência) vive em um único repositório. Se uma mudança na modelagem quebrar um dashboard ou invalidar uma métrica documentada, a integração contínua (CI) sinaliza o erro e a correção é enviada no mesmo pull request. É como garantir que a planta da Mansão X esteja sempre atualizada antes de qualquer reforma.\nFontes da Verdade: O Mapa do Cérebro Se as fundações de dados são o warehouse, as fontes da verdade são as superfícies de referência que o agente consulta para navegar por ele. É aqui que a ambiguidade é destruída.\nA camada semântica é a primeira linha de defesa. Se uma pergunta mapeia de forma limpa para uma métrica definida, o agente chama uma função e obtém um número — o mesmo número que qualquer outro dashboard da empresa produziria. A Anthropic descobriu da pior forma que tentar usar um LLM para auto-gerar definições de métricas a partir de tabelas brutas não funciona; o modelo apenas codifica as ambiguidades existentes. A documentação pode ser gerada por IA, mas a definição deve ter um dono humano.\nQuando a camada semântica não cobre a pergunta, o agente recorre à linhagem de dados e ao contexto de negócio. O contexto de negócio é frequentemente ignorado, mas é crucial. Um agente que não entende o negócio responderá o que o usuário perguntou, mas não o que ele quis dizer. Ele não saberá que \u0026ldquo;o lançamento do Q2\u0026rdquo; se refere a um produto específico. A Anthropic resolve isso alimentando o agente com um grafo de conhecimento da empresa, incluindo documentos indexados, roadmaps e a estrutura organizacional.\nSkills: O Treinamento na Sala de Perigo Se as fontes da verdade são o conhecimento declarativo do agente, as \u0026ldquo;skills\u0026rdquo; (habilidades) são o seu conhecimento procedural. Elas instruem o agente sobre quais fontes consultar, em que ordem, como navegar por dados ambíguos e como deve ser uma análise finalizada.\nNa Anthropic, uma skill é uma pasta de arquivos markdown que o agente lê sob demanda. Sem essas skills, a precisão do Claude em responder perguntas de analytics não passava de 21%. Com as skills, esse número saltou para mais de 95%.\nA estratégia principal aqui é criar skills em pares. Uma skill de conhecimento atua como um roteador de alto nível. Em vez de deixar o agente vasculhar um warehouse com um milhão de campos, a skill restringe o espaço de busca a algumas dezenas de arquivos curados antes mesmo de uma query ser escrita. É como o Professor Xavier direcionando a equipe exata de X-Men para uma missão específica, em vez de mandar todos os alunos da escola de uma vez.\nEsses documentos de referência são escritos especificamente para serem lidos por um LLM. Eles descrevem a granularidade das tabelas, as armadilhas conhecidas (gotchas) e gatilhos de roteamento explícitos (por exemplo: \u0026ldquo;SE a pergunta for sobre lift de experimento\u0026hellip; NÃO use para contagens brutas de eventos\u0026rdquo;).\nValidação: O Teste de Fogo A última peça do quebra-cabeça é a validação. Como você sabe se o seu agente está realmente acertando?\nA Anthropic usa avaliações offline (evals) como pares de perguntas e respostas. Elas não dizem como o agente online vai performar, mas garantem que não há lacunas críticas . A regra de ouro é ancorar a verdade absoluta para que ela não mude: um eval escrito contra dados ao vivo fica obsoleto no momento em que o número subjacente muda. A solução é fixar cada eval a uma data de snapshot ou fazer o avaliador julgar a query do agente em vez do número final .\nNo ambiente online, a validação continua. A Anthropic implementou uma revisão adversarial: uma skill do Claude que desafia agressivamente todas as suposições subjacentes em uma resposta potencial. Isso aumentou a precisão em 6%, embora ao custo de maior latência e uso de tokens . Além disso, toda resposta carrega um rodapé de proveniência, indicando de qual camada a informação veio e quão frescos são os dados . Não torna a resposta mais correta, mas ajuda o consumidor a julgar o nível de confiança.\nO Fator Mutante A lição da Anthropic é clara: a precisão em analytics com IA não é um problema de geração de código. É um problema de contexto e verificação.\nApontar um LLM poderoso para um data warehouse desorganizado é como colocar o Professor Xavier no meio da Times Square sem o Cérebro. Ele vai ouvir muito barulho, mas não vai encontrar o que você precisa. A verdadeira revolução do self-service analytics não acontece quando o modelo fica mais inteligente. Ela acontece quando a engenharia de dados, a governança e o contexto de negócio se unem para criar a infraestrutura que permite que essa inteligência brilhe.\nO futuro do analytics não é sobre quem tem o melhor modelo. É sobre quem constrói o melhor Cérebro para ele.\nReferências: How Anthropic enables self-service data analytics with Claude | Claude: https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude\n","permalink":"https://julianamarialop.github.io/articles/o-cerebro-por-tras-da-magica-como-anthropic-claude-professor/","summary":"Se você já assistiu aos X-Men, sabe que o poder do Professor Xavier não está apenas em ler mentes. O verdadeiro poder dele está no Cérebro, a máquina que amplifica suas habilidades e permite que ele encontre a agulha no…","title":"O Cérebro por Trás da Mágica: Como a Anthropic Transformou o Claude no Professor Xavier do Analytics"},{"content":"Existe uma cena em Star Wars que resume perfeitamente o problema que o Microsoft Scout foi criado para resolver. Luke Skywalker está no cockpit do X-Wing, concentrado na missão, enquanto o R2-D2 trabalha silenciosamente nos bastidores: calculando rotas, monitorando sistemas, reparando danos, antecipando problemas. Luke não precisa parar o que está fazendo para pedir ao R2 que verifique os escudos. O droide entende o contexto, sabe o que é importante e age de forma autônoma para manter a missão nos trilhos.\nDurante anos, a promessa da IA no ambiente de trabalho foi exatamente essa: um assistente que entende o contexto, antecipa necessidades e age de forma proativa. O que tivemos na prática foi bem diferente. Tivemos assistentes que respondem quando perguntados, que geram texto quando solicitados e que param de funcionar quando a conversa termina. Tivemos C-3POs muito eloquentes, mas nenhum R2-D2.\nO Microsoft Scout, anunciado em 2 de junho de 2026 como parte do Microsoft Build 2026, é a primeira tentativa séria de preencher essa lacuna. Ele não é apenas um novo produto; é o representante de uma nova categoria de agentes que a Microsoft está chamando de Autopilots. Neste artigo, vamos explorar o que isso significa na prática, como a tecnologia funciona e por que esse anúncio pode ser mais importante do que parece à primeira vista.\nUma Nova Categoria: O Que São os Autopilots Para entender o Microsoft Scout, é preciso primeiro entender o que diferencia um Autopilot de um assistente de IA convencional. A distinção não é apenas técnica; é filosófica.\nOs assistentes de IA que conhecemos até hoje operam em um modelo de interação reativa. Você faz uma pergunta, o sistema responde. Você pede um resumo, o sistema gera. Você inicia uma conversa, o sistema participa. Quando a conversa termina, o sistema para. Ele não tem memória persistente do que aconteceu antes, não tem objetivos próprios e não age sem ser acionado.\nOs Autopilots são fundamentalmente diferentes. Segundo a Microsoft, eles são agentes sempre ativos que trabalham de forma autônoma, possuem sua própria identidade e agem em seu nome . A palavra-chave aqui é \u0026ldquo;sempre ativos\u0026rdquo;. Um Autopilot não espera ser chamado. Ele permanece ativo em segundo plano, compreendendo como o trabalho é realizado nos seus aplicativos e sistemas, e tomando medidas sem precisar ser acionado a cada vez .\nIsso representa uma mudança de paradigma. A maioria dos sistemas de IA que usamos hoje são ferramentas: poderosas, mas passivas. Um Autopilot é mais próximo de um colaborador: alguém que entende os objetivos, monitora o progresso e age de forma independente para manter as coisas funcionando.\nO Microsoft Scout é o primeiro Autopilot da Microsoft, e ele foi construído especificamente para o ambiente de trabalho do Microsoft 365.\nComo o Scout Funciona: A Anatomia do R2-D2 Corporativo Para que um Autopilot seja útil, ele precisa de três coisas: contexto (entender o que está acontecendo), capacidade (poder agir sobre o que entendeu) e confiança (garantias de que vai agir de forma segura e dentro dos limites estabelecidos). O Scout foi projetado com essas três dimensões em mente.\nContexto: A Integração com o Ecossistema Microsoft 365 O Scout opera através da nuvem, desktop e web, conectando-se ao Teams, Outlook, OneDrive e SharePoint . Ele tem acesso aos dados que impulsionam o dia a dia: chats, e-mails, calendários e contatos . A interação principal acontece no Teams, mas seu alcance se estende através do aplicativo de desktop para o navegador e recursos locais, incluindo servidores MCP (Model Context Protocol) .\nEssa integração profunda com o ecossistema Microsoft 365 é o que diferencia o Scout de assistentes genéricos. Ele não apenas lê documentos; ele entende o contexto em que esses documentos existem. Ele sabe que aquele relatório foi criado pela Ana, que a Ana reporta para o Carlos, que o Carlos está em uma reunião amanhã com o cliente que fez a solicitação original. Esse contexto relacional é o que permite que o Scout tome decisões inteligentes.\nCapacidade: O Que o Scout Pode Fazer As capacidades do Scout são centradas em um problema específico e muito real: o trabalho de coordenação que consome uma parte desproporcional do tempo dos profissionais modernos. Segundo a Microsoft, o Scout foi projetado para reduzir o trabalho de coordenação que se acumula ao longo do dia .\nNa prática, isso se traduz em capacidades concretas. O Scout pode proativamente agendar e coordenar horários de reuniões entre fusos horários, sinalizar reuniões importantes e gerar os materiais necessários para a preparação, mantendo o usuário informado . Para qualquer profissional que já passou horas tentando encontrar um horário que funcione para cinco pessoas em três fusos horários diferentes, isso é uma capacidade transformadora.\nAlém disso, o Scout identifica entregas próximas e bloqueia automaticamente tempo no calendário para garantir que o usuário tenha o foco necessário para executá-las . Ele também pode identificar riscos, como decisões travadas em threads de e-mail que estão impedindo o progresso de projetos, e sinalizá-los antes que se tornem bloqueadores .\nO que torna essas capacidades especialmente poderosas é que elas não dependem de o usuário lembrar de pedir. O Scout está monitorando continuamente, identificando padrões e agindo de forma proativa. É a diferença entre ter um assistente que faz o que você pede e ter um colaborador que pensa junto com você.\nWork IQ: A Inteligência que Cresce com o Tempo A capacidade mais estratégica do Scout não é nenhuma das funcionalidades listadas acima. É a sua capacidade de aprender. Com o tempo, o Scout constrói contexto alimentado pelo Work IQ, aprendendo como você trabalha, o que você valoriza e o que precisa acontecer a seguir .\nO Work IQ é a camada de inteligência do local de trabalho da Microsoft, capturando como o trabalho realmente acontece no Microsoft 365 e em sistemas organizacionais externos . Ele entende as conexões entre pessoas, documentos, reuniões e decisões, criando uma representação viva de como a organização funciona.\nPara o Scout, isso significa que ele não começa do zero a cada dia. Ele acumula contexto sobre as suas prioridades, os seus relacionamentos profissionais, os seus padrões de trabalho e os objetivos dos projetos em que você está envolvido. Com o tempo, ele se torna cada vez mais preciso em suas antecipações e mais relevante em suas ações .\nÉ como a evolução do R2-D2 ao longo das missões com Luke: quanto mais tempo eles trabalham juntos, mais o droide entende as nuances do piloto e mais eficaz se torna em apoiá-lo.\nOs Escudos Defletores: Segurança e Governança Enterprise Um agente que age de forma autônoma em nome de um profissional em um ambiente corporativo levanta questões sérias de segurança. Quem é responsável pelas ações do agente? Como garantir que ele não acesse dados que não deveria? Como auditar o que ele fez? Como garantir que políticas de compliance sejam respeitadas?\nA Microsoft construiu o Scout com segurança e controles de nível empresarial desde o primeiro dia , e os mecanismos são mais sofisticados do que parecem à primeira vista.\nIdentidade Própria no Entra O ponto de partida é a identidade. Cada agente Scout opera sob sua própria identidade governada no Microsoft Entra, e não como uma conta de serviço anônima e compartilhada . Isso pode parecer um detalhe técnico, mas tem implicações profundas.\nQuando o Scout age em nome de um usuário, essa ação é atribuível a um ator conhecido que o diretório da organização já entende. Isso significa que as ações do Scout aparecem nos logs de auditoria, podem ser rastreadas, podem ser investigadas e podem ser governadas pelas mesmas políticas que se aplicam a qualquer outro usuário ou serviço da organização.\nAs credenciais por trás dessa identidade são protegidas de ponta a ponta: limitadas à tarefa em questão, ocultadas de logs ou diagnósticos e gerenciadas com o mesmo rigor de qualquer serviço primário da Microsoft . Quando o Scout age em seu nome, você sabe exatamente qual autoridade ele carregava e que nada sensível vazou no processo .\nControle de Acesso Granular Além da identidade, o controle de acesso determina o que o Scout pode fazer. Ele só pode alcançar os recursos e destinos que foram aprovados . Isso não é um controle binário de \u0026ldquo;pode tudo\u0026rdquo; ou \u0026ldquo;não pode nada\u0026rdquo;; é um sistema granular que pode ser configurado para diferentes níveis de autonomia.\nAções sensíveis podem exigir a aprovação de um humano antes de prosseguir . Isso é fundamental para construir confiança gradual no sistema. Um time pode começar com o Scout apenas sugerindo ações e aguardando aprovação, e progressivamente aumentar o nível de autonomia à medida que a confiança é estabelecida.\nAs políticas de proteção de dados do Microsoft Purview, incluindo labels de sensibilidade e prevenção de perda de dados, são aplicadas no momento, antes que qualquer coisa seja enviada ou escrita . O Scout não contorna esses controles; ele opera dentro deles. Para organizações em setores regulados, como financeiro, saúde ou jurídico, essa integração nativa com as ferramentas de compliance existentes é um requisito não negociável.\nOpenClaw: A Base Open-Source O Scout é construído sobre a tecnologia de código aberto OpenClaw . Essa escolha reflete o compromisso da Microsoft com a transparência e com a comunidade de desenvolvedores. Ao construir sobre uma base open-source, a Microsoft permite que organizações inspecionem, auditem e contribuam para a tecnologia subjacente.\nA Microsoft está contribuindo com conformidade de políticas diretamente para o upstream do OpenClaw . Organizações que rodam o OpenClaw poderão validar se seu ambiente está configurado dentro dos requisitos de segurança e compliance, operando de forma segura e obtendo uma resposta verificável e pronta para auditoria .\nO Estado Atual: Private Preview e o Caminho à Frente O Microsoft Scout não está disponível para todos ainda. A Microsoft já utilizou uma experiência inicial de desktop internamente, com funcionários da própria empresa usando o Scout para assumir tarefas de coordenação, identificar riscos mais cedo e manter o trabalho em movimento sem solicitações constantes .\nAgora, essa experiência está sendo estendida a um grupo seleto de clientes em private preview e a organizações Frontier . O acesso requer inscrição no programa Frontier, configuração de política no Intune e uma atestação de opt-in. Usuários com uma licença do GitHub Copilot podem então baixar e instalar a experiência .\nEsse processo gradual de rollout é deliberado. A Microsoft está sendo cautelosa ao expandir o acesso a um agente que age de forma autônoma em ambientes corporativos. Cada organização que entra no programa Frontier está, em certo sentido, ajudando a Microsoft a entender como os Autopilots se comportam em contextos reais, quais são os casos de uso mais valiosos e onde estão as arestas que precisam ser polidas.\nPor Que Isso Importa Mais do Que Parece É fácil olhar para o Microsoft Scout e vê-lo como mais um assistente de produtividade com algumas funcionalidades novas. Mas o que está sendo anunciado é algo mais fundamental.\nA categoria dos Autopilots representa uma mudança na relação entre humanos e sistemas de IA no trabalho. Até agora, essa relação era de ferramenta e usuário: você usa a ferramenta quando precisa e a guarda quando não precisa. Com os Autopilots, a relação se torna mais próxima de uma parceria: um agente que entende seus objetivos, monitora o ambiente, identifica oportunidades e riscos, e age de forma autônoma dentro dos limites que você estabeleceu.\nEssa mudança tem implicações que vão além da produtividade individual. Ela muda a forma como as organizações precisam pensar sobre governança, sobre responsabilidade, sobre auditoria e sobre a divisão de trabalho entre humanos e sistemas. As perguntas que os times de segurança, compliance e RH vão precisar responder nos próximos anos são perguntas que ainda não têm respostas estabelecidas.\nO Microsoft Scout é o primeiro passo nessa jornada. Como todo primeiro passo, ele é ao mesmo tempo promissor e incompleto. Mas a direção está clara: o futuro do trabalho não é sobre ferramentas mais poderosas. É sobre parceiros mais inteligentes.\nO R2-D2 corporativo chegou. A questão agora é: você está pronto para voar com ele?\nReferências: [1] Introducing Microsoft Scout: Your always-on personal agent | Microsoft 365 Blog: https://www.microsoft.com/en-us/microsoft-365/blog/2026/06/02/introducing-microsoft-scout-your-always-on-personal-agent/\n","permalink":"https://julianamarialop.github.io/articles/microsoft-scout-o-r2-d2-que-vai-mudar-forma-como-voce/","summary":"Existe uma cena em Star Wars que resume perfeitamente o problema que o Microsoft Scout foi criado para resolver. Luke Skywalker está no cockpit do X-Wing, concentrado na missão, enquanto o R2-D2 trabalha silenciosamente…","title":"Microsoft Scout: O R2-D2 que Vai Mudar a Forma Como Você Trabalha"},{"content":"Em 1977, quando as luzes do cinema se apagaram e aquela abertura icônica começou a rolar pela tela, ninguém sabia exatamente o que estava prestes a acontecer. Star Wars não era apenas um filme; era uma ruptura, uma redefinição do que era possível. O Microsoft Microsoft Build 2026 teve esse mesmo sabor. Com o tema \u0026ldquo;Be Yourself at Work\u0026rdquo;, a Microsoft não apresentou apenas um conjunto de novos produtos. Ela apresentou uma nova ordem galáctica para o desenvolvimento de software e para a inteligência artificial nas empresas.\nDurante décadas, a relação entre as organizações e a tecnologia foi de dependência. Dependência de plataformas, de modelos de terceiros, de consultorias que detinham o conhecimento. O Build 2026 marca a virada: a Microsoft está apostando que o diferencial competitivo do futuro não é mais o acesso à inteligência artificial, mas a propriedade dela. Não basta ter acesso à Força; é preciso que a Força seja sua, moldada pela sua história, pelos seus dados e pelas suas regras.\nNeste artigo, vamos percorrer os três grandes pilares do Build 2026 com a profundidade que cada um merece: a nova camada de contexto Microsoft IQ, a família de modelos próprios MAI e a estrutura de governança que garante que tudo isso funcione com segurança em produção. Prepare seu sabre de luz.\nEpisódio I: A Ameaça Fantasma do Contexto Genérico Antes de entender o que a Microsoft anunciou, é preciso entender o problema que ela está resolvendo. Durante os últimos dois anos, a corrida pela IA nas empresas produziu um padrão previsível: times de tecnologia implantam modelos de linguagem poderosos, conectam algumas fontes de dados e esperam resultados transformadores. O que geralmente acontece é bem diferente.\nOs agentes respondem de forma genérica porque não entendem o contexto real da organização. Eles sabem o que é um e-mail, mas não sabem que aquele e-mail específico está relacionado a um projeto crítico que está atrasado. Eles sabem o que é uma reunião, mas não entendem que aquela reunião envolve um cliente que está prestes a cancelar o contrato. A inteligência existe, mas o contexto está faltando.\nÉ exatamente essa lacuna que o Microsoft IQ foi projetado para preencher. Disponível a partir de hoje no GitHub Copilot, Microsoft Foundry e Copilot Studio, o Microsoft IQ é descrito como uma nova camada de contexto que aterra os agentes tanto no conhecimento do mundo quanto no conhecimento específico da sua empresa . Não é um produto isolado; é uma infraestrutura de inteligência composta por quatro camadas especializadas que trabalham em conjunto.\n_https://jannikreinhard.com/2025/11/26/microsoft-iq-the-intelligence-layer-that-finally-makes-ai-agents-useful/_\nWork IQ: A Inteligência do Fluxo de Trabalho O Work IQ é a camada mais próxima do dia a dia das pessoas. Ele captura como o trabalho realmente acontece no Microsoft 365, entendendo as conexões entre pessoas, e-mails, documentos, reuniões e como tudo isso se conecta . Não é apenas um índice de documentos; é uma representação viva de como a organização funciona.\nPense no Work IQ como o Mestre Yoda da sua organização. Ele não apenas conhece os fatos; ele entende os relacionamentos, as tensões, as prioridades não ditas. Quando um agente alimentado pelo Work IQ recebe uma pergunta sobre o status de um projeto, ele não apenas busca documentos com aquele nome. Ele entende quem são as pessoas-chave, quais foram as últimas decisões tomadas, onde estão os bloqueios e o que precisa acontecer a seguir.\nAs Work IQ APIs ficam disponíveis de forma geral em 16 de junho de 2026, permitindo que desenvolvedores acessem essa camada de inteligência de forma programática . Isso significa que qualquer agente, construído em qualquer framework, poderá ser enriquecido com o contexto real do fluxo de trabalho da organização.\nFabric IQ: A Linguagem dos Dados de Negócio Se o Work IQ cuida do contexto humano e relacional, o Fabric IQ cuida do contexto dos dados estruturados de negócio . Ele fornece uma fundação semântica compartilhada sobre os dados que vivem no Microsoft Fabric, garantindo que quando um agente fala sobre \u0026ldquo;receita\u0026rdquo;, \u0026ldquo;margem\u0026rdquo; ou \u0026ldquo;churn\u0026rdquo;, ele está usando as mesmas definições que o time de finanças, o time de vendas e o time de produto.\nEsse problema de semântica inconsistente é mais sério do que parece. Em organizações grandes, é comum que diferentes áreas usem os mesmos termos com definições diferentes. O Fabric IQ age como o C-3PO da galáxia dos dados: fluente em mais de seis milhões de formas de comunicação, garantindo que todos os agentes falem a mesma língua quando se trata dos dados críticos do negócio.\nFoundry IQ e Web IQ: Conectando o Universo O Foundry IQ é o elo que une as demais camadas, habilitando o planejamento de recuperação de informações tanto através do conhecimento corporativo quanto da web em tempo real . É a inteligência que decide, diante de uma pergunta complexa, quais fontes consultar, em que ordem e como combinar as respostas.\nA novidade mais recente da família é o Web IQ, anunciado no próprio evento. É descrito como a forma mais rápida de aterrar agentes em informações do mundo real: uma stack de busca web AI-first, agnóstica a modelos e nativa para MCP (Model Context Protocol), capaz de retornar passagens relevantes com uma velocidade quase 2,5 vezes superior à melhor alternativa disponível no mercado . Para agentes que precisam de informações atualizadas sobre mercados, regulações ou eventos externos, o Web IQ é o hiperimpulsor que os leva para onde precisam ir em tempo recorde.\nEpisódio II: O Império dos Modelos Próprios Por muito tempo, as grandes empresas de tecnologia dependeram de modelos de terceiros para alimentar seus produtos de IA. A Microsoft não é exceção: o Copilot foi construído sobre os modelos da OpenAI, e essa parceria continua sendo importante. Mas o Build 2026 marcou um ponto de inflexão: a Microsoft está construindo seus próprios modelos de IA, e eles são competitivos.\nA família MAI (Microsoft AI) foi apresentada com sete novos modelos in-house, cada um projetado para uma finalidade específica . Essa estratégia de especialização é análoga à formação de uma frota imperial: cada nave tem um papel definido, e juntas elas cobrem todo o espectro de necessidades.\n_Credits: X/@mustafasuleyman_\nMAI-Thinking-1: O Destruidor Estelar do Raciocínio O carro-chefe da família é o MAI-Thinking-1, o primeiro modelo de raciocínio da Microsoft. O que o torna especialmente relevante não é apenas o seu desempenho, mas a forma como foi construído: treinado do zero, sem distilação de outros modelos, em dados limpos e licenciados comercialmente . Para empresas preocupadas com questões de propriedade intelectual e compliance, isso é um diferencial significativo.\nCom 35 bilhões de parâmetros ativos e uma janela de contexto de 256K tokens, o MAI-Thinking-1 foi projetado especificamente para lidar com instruções complexas de múltiplas etapas, raciocínio de longo contexto e geração de código . Os números de benchmark são impressionantes: em testes cegos, avaliadores independentes preferiram o MAI-Thinking-1 ao Sonnet 4.6, e ele igualou o Opus 4.6 em habilidades de codificação no SWE Bench Pro . Para um primeiro modelo de raciocínio, esses são resultados que colocam a Microsoft imediatamente entre os competidores sérios nessa categoria.\nO modelo está disponível no Foundry em private preview a partir de hoje.\nMAI-Image-2.5: O Artesão Visual O MAI-Image-2.5 representa a entrada da Microsoft no mercado de modelos de geração e edição de imagens, e ela entrou com força. É o primeiro modelo da Microsoft a suportar tanto cargas de trabalho de texto para imagem quanto de imagem para imagem . No Arena AI leaderboard, ele ocupa a terceira posição em texto para imagem e a segunda posição em imagem para imagem, superando concorrentes estabelecidos .\nO que torna esse modelo particularmente interessante para o ecossistema Microsoft é sua integração nativa. Ele já está ativo no PowerPoint, sendo implantado no OneDrive e chegando ao Foundry com qualidade líder de mercado por dólar . Para times de marketing, design e comunicação que já vivem no ecossistema Microsoft 365, isso representa uma capacidade criativa significativa sem precisar sair do ambiente de trabalho.\nA Família Completa: Especialistas para Cada Missão Além dos dois modelos principais, a família MAI inclui:\nO MAI-Transcribe-1.5 combina precisão de ponta em 43 idiomas, com streaming chegando em breve . Para organizações globais com operações em múltiplos países, a capacidade de transcrever reuniões, calls e conteúdo de áudio com alta precisão em dezenas de idiomas é uma capacidade operacional crítica.\nO MAI-Voice-2 e sua variante flash estão agora disponíveis em mais de 15 novos idiomas com novas opções de voz . Combinado com o MAI-Transcribe-1.5, isso cria uma infraestrutura completa de voz que pode alimentar desde assistentes de call center até interfaces de voz para aplicações industriais.\nO MAI-Code-1 é um modelo de codificação eficiente para inferência, ajustado especificamente para o GitHub e agora disponível no Copilot e VS Code . A especialização em código, combinada com a eficiência de inferência, o torna ideal para cenários onde velocidade e custo são críticos, como sugestões em tempo real durante a digitação.\nAbertura e Escolha: Além do Catálogo Próprio A Microsoft deixou claro que a estratégia não é criar um jardim murado. Os modelos MAI estarão disponíveis em plataformas de terceiros como Fireworks AI, Baseten e Open Router . Ao mesmo tempo, o Fireworks AI passa a estar geralmente disponível no Foundry, oferecendo uma experiência de plataforma única com governança corporativa e residência de dados no Azure, independentemente do modelo escolhido .\nEssa abertura é estratégica. A Microsoft está apostando que, ao oferecer a melhor plataforma para rodar qualquer modelo, ela se torna indispensável mesmo para clientes que preferem modelos de outros fornecedores.\nEpisódio III: O Retorno da Governança Com grandes poderes vêm grandes responsabilidades, e a proliferação de agentes autônomos em ambientes corporativos levanta questões sérias de segurança, compliance e governança. Quem é responsável quando um agente toma uma decisão errada? Como garantir que agentes não acessem dados que não deveriam? Como auditar o que um agente fez?\nA Microsoft apresentou uma resposta abrangente a essas questões, construindo o que pode ser descrito como a República Galáctica da governança de agentes.\n_https://www.microsoft.com/pt-br/microsoft-agent-365_\nAgent 365: O Senado Galáctico dos Agentes O Agent 365 for local agents é a peça central dessa estrutura. Ele estende o Entra, Defender e Purview em um único plano de controle para observar, governar e proteger agentes em todo o ambiente corporativo, independentemente de onde estejam hospedados ou em qual framework foram construídos .\nEsse último ponto é crucial. O Agent 365 não é apenas para agentes Microsoft. Ele funciona como um plano de controle universal, capaz de monitorar e governar agentes construídos em LangChain, AutoGen, CrewAI ou qualquer outro framework. Para CISOs e times de segurança que estão vendo a proliferação de agentes de IA em suas organizações, essa capacidade de visibilidade centralizada é fundamental.\nFrontier Tuning: Treinando Seus Próprios Cavaleiros Jedi Uma das novidades mais estratégicas do Build 2026 é o Frontier Tuning, disponível em private preview a partir de hoje. Ele aplica reinforcement learning dentro do perímetro de compliance da organização, permitindo que os agentes aprendam como o negócio realmente funciona .\nUsando os dados, o conhecimento de domínio e os fluxos de trabalho próprios da organização, o Frontier Tuning cria um ciclo que se aprimora à medida que os agentes trabalham . É a diferença entre contratar um consultor externo que conhece as melhores práticas do mercado e treinar um colaborador interno que conhece as especificidades do seu negócio. Com o tempo, o agente treinado com Frontier Tuning não apenas segue regras genéricas; ele internaliza a forma como a sua organização pensa e opera.\nASSERT e Agent Control Specification: A Constituição Galáctica Para garantir que a governança seja consistente e auditável, a Microsoft anunciou dois projetos de código aberto que formam a base da segurança de agentes.\nO ASSERT (Adaptive Spec-driven Scoring for Evaluation and Regression Testing) é um framework para avaliação de segurança baseada em políticas . Ele permite que organizações definam políticas de comportamento esperado para seus agentes e validem continuamente se esses agentes estão operando dentro dessas políticas. É como ter um sistema de auditoria automatizado que verifica constantemente se os agentes estão seguindo a Constituição Galáctica.\nA Agent Control Specification padroniza onde e como aplicar controles no loop do agente . Ao criar um padrão aberto para isso, a Microsoft está tentando estabelecer uma linguagem comum para a governança de agentes que possa ser adotada por todo o ecossistema, independentemente do framework ou plataforma.\nCodename MDASH: A Frota de Defesa Proativa Fechando a camada de segurança, o Codename MDASH representa uma abordagem radicalmente diferente para a segurança de software. Em vez de esperar que vulnerabilidades sejam descobertas e reportadas, o MDASH implanta mais de 100 agentes especializados para encontrar bugs exploráveis de forma proativa .\nEsses agentes raciocinam sobre o fluxo de dados, a lógica de negócio e as cadeias de exploração, entregando correções sensíveis ao contexto diretamente no Defender Portal . É como ter uma frota de caças X-Wing constantemente patrulhando o perímetro, identificando ameaças antes que elas se tornem crises.\nO Que Isso Significa na Prática O Microsoft Build 2026 não foi um evento de anúncios isolados. Foi a apresentação de uma visão coerente e integrada de como a Microsoft acredita que a IA vai evoluir nas empresas. Essa visão tem três características que a diferenciam do que vinha sendo feito até agora.\nPrimeiro, a ênfase na propriedade da inteligência. A mensagem central do evento foi clara: o diferencial competitivo não é mais ter acesso à IA mais poderosa. É ter uma IA que é genuinamente sua, alimentada pelos seus dados, treinada nos seus processos e operando dentro das suas regras. O Microsoft IQ, o Frontier Tuning e a família MAI são todos peças dessa estratégia.\nSegundo, a aposta na abertura como vantagem competitiva. Ao tornar os modelos MAI disponíveis em plataformas de terceiros, ao construir o Agent 365 para governar agentes de qualquer framework e ao lançar projetos de código aberto como ASSERT e Agent Control Specification, a Microsoft está sinalizando que sua vantagem não está no lock-in, mas na qualidade da plataforma.\nTerceiro, a seriedade com governança e segurança. Em um momento em que muitas empresas ainda estão descobrindo como usar agentes de IA de forma responsável, a Microsoft chegou ao Build 2026 com respostas concretas para as perguntas mais difíceis: como auditar, como controlar, como garantir compliance e como proteger dados sensíveis.\nA galáxia da IA empresarial está mudando rapidamente. O Build 2026 deixou claro que a Microsoft não está apenas participando dessa mudança; ela está tentando defini-la. Que a Força esteja com você.\nReferências: [1] Microsoft Build 2026: Be yourself at work - The Official Microsoft Blog: https://blogs.microsoft.com/blog/2026/06/02/microsoft-build-2026-be-yourself-at-work/\nAgent 365: https://www.microsoft.com/pt-br/microsoft-agent-365\n","permalink":"https://julianamarialop.github.io/articles/microsoft-build-2026-uma-nova-esperanca-para-era-dos-agentes/","summary":"Em 1977, quando as luzes do cinema se apagaram e aquela abertura icônica começou a rolar pela tela, ninguém sabia exatamente o que estava prestes a acontecer. Star Wars não era apenas um filme; era uma ruptura, uma…","title":"Microsoft Build 2026: Uma Nova Esperança para a Era dos Agentes Autônomos"},{"content":"O Castelo Que Foi Construído Primeiro Asgard foi construído antes de qualquer outro reino. A OpenAI ergueu o castelo com GPT-3, GPT-4 e ChatGPT em uma sequência que ninguém conseguiu acompanhar, e o mundo passou a usar essa tecnologia antes mesmo de entender direito o que estava usando. Não foi sorte, foi visão, execução e capacidade de escala em um momento em que o mercado estava pronto para absorver tudo o que fosse colocado à sua frente. Isso tem nome, e o nome é liderança de mercado. Odin merece o trono que ocupa.\nE então apareceu Claude , sem convite, sem a chave da ponte dourada, vindo do lado de fora do muro.\nO Príncipe Que Não Precisou da Coroa Existe uma leitura comum de Loki que o reduz ao trickster, ao que mente, ao que trai. Errado. O Loki desse paralelo é o outro, o que não tem cetro, não tem exército, não tem o nome reconhecido pelos Nove Reinos, mas tem algo que Asgard não esperava encontrar do lado de fora do muro: a ousadia de entregar o que ninguém pediu, sem esperar ser chamado, sem pedir permissão para mostrar do que era capaz.\nE Loki domina algo que Asgard sempre tratou como menor: discrição. O que entra no salão fica no salão. Nos usos enterprise de Claude, o que você compartilha na conversa não entra no treinamento do modelo, e isso não é detalhe contratual, é requisito de arquitetura.\nLoki não é apenas \u0026ldquo;o que chegou depois\u0026rdquo;. É o que entrega o que o castelo precisa antes de receber permissão para entrar, e é exatamente assim que Claude se comportou no ecossistema enterprise de dados nos últimos dois anos.\nQuatro Frentes Onde a Diferença Aparece em Produção Em quatro contextos que vivem no meu dia a dia em projetos enterprise, a diferença entre Claude e GPT-4o não está em benchmark de laboratório, está no momento em que o output sai da chamada e precisa funcionar.\nGeração de código - Quando um pipeline Spark precisa lidar com regras de negócio específicas do cliente, transformações encadeadas, schema evolution e edge cases que não estão documentados em lugar nenhum mas existem nos dados de produção, o que separa um modelo do outro é o quanto de revisão sobra para o arquiteto depois do output gerado. Claude entrega estrutura que vai para produção com revisão mínima, especialmente em tratamento de nulos, idempotência e schema drift, enquanto GPT-4o entrega estrutura que tipicamente precisa de uma passada cirúrgica antes de qualquer commit, refinando justamente os mesmos pontos sensíveis. A diferença prática não está na qualidade absoluta de cada chamada isolada, está na quantidade de trabalho cognitivo que sobra para quem revisa o código antes do merge, e essa diferença se acumula ao longo de centenas de chamadas semanais até virar uma diferença visível de produtividade do time.\nAnálise de documentos longos - Quando o documento de entrada é um RFP de oitenta páginas, com cláusulas de LGPD enterradas no anexo VII e requisitos contraditórios entre o capítulo de escopo e o capítulo de SLA, a capacidade que importa não é responder uma pergunta bem formulada, é manter coerência ao longo de todo o documento sem perder o fio na página quarenta e sete. Claude Sonnet 4.5 opera com janela de duzentos mil tokens em produção e até um milhão em prévia para casos selecionados, enquanto GPT-4o opera em cento e vinte e oito mil, e essa diferença deixa de ser especificação de hardware no momento em que três seções do RFP se contradizem entre si. Claude tipicamente sinaliza a contradição, enquanto GPT-4o frequentemente responde sobre uma seção esquecendo o que disse sobre a outra, gerando documentos derivados que herdam silenciosamente a inconsistência original.\nArquitetura - Quando a pergunta é sobre trade-off, como escolher entre lakehouse federation e replicação física, entre processamento síncrono e assíncrono, ou entre streaming e micro-batch, o que separa uma boa resposta de uma resposta útil é o quanto a recomendação expõe as premissas em vez de apenas devolver o veredito. Claude não devolve só a recomendação fechada, ele expõe as premissas que precisam ser verdadeiras para a recomendação valer, mapeia os riscos do caminho proposto e aponta o que a pergunta não fez mas deveria ter feito antes de receber resposta. Essa postura é exatamente o que um arquiteto sênior precisa do modelo quando a decisão vai parar em comitê de governança, e é aqui que Loki entrega a resposta que o reino precisa ouvir, não a que o reino esperava ouvir.\nAgentes - Em sistemas agênticos com módulos encadeados, orquestração de tarefas em quatro a seis etapas e prompts que precisam manter coerência ao longo de chamadas sequenciais, o que separa um agente funcional de um agente que precisa de babá humana é a consistência entre chamadas, em que o que o agente decidiu na etapa dois precisa informar o que ele faz na etapa cinco sem perder a tese central no caminho. Claude sustenta o raciocínio ao longo dessas cadeias sem perder o contexto da instrução anterior, e em arquiteturas com sub-agentes paralelos mantém a coerência da missão enquanto cada filho executa a sua parte, dispensando o tipo de validação intermediária por humano que costuma transformar agente autônomo em chatbot supervisionado disfarçado de automação.\nA Decisão Que Nenhum Benchmark Responde Não é sobre escolher um vencedor entre Asgard e seu príncipe não-coroado. É sobre saber qual reino chamar para qual tipo de missão.\nClaude domina quando o contexto operacional é longo, quando a tarefa exige raciocínio auditável que vai parar em relatório de governança, quando o output entra em produção sem revisão linha-a-linha por humano, ou quando a organização precisa de comportamento previsível em projetos com dados sensíveis trancados dentro da conversa e protegidos de virar combustível de treino externo.\nGPT-4o domina quando a integração com o ecossistema Microsoft já está paga e instalada, quando o caso de uso é multimodal nativo combinando visão, áudio e texto na mesma chamada, quando a latência por chamada importa mais que qualidade incremental do output, ou quando a equipe acumulou anos de prompts otimizados em produção e o custo de refazer essa biblioteca não compensa a troca de fornecedor.\nNenhum dos dois está errado. Depende da missão.\nO RFP de 60 Mil Tokens Considere um agente de análise documental que processa cinquenta RFPs por mês, com cada RFP somando em média sessenta mil tokens entre o documento original e o pacote de anexos técnicos. Em GPT-4o, com janela de cento e vinte e oito mil tokens, esse volume cabe em uma única chamada quando o pacote de anexos é enxuto, mas no momento em que o briefing técnico passa dos setenta mil tokens é necessário quebrar o documento em duas chamadas e reconciliar o resultado depois, e cada reconciliação introduz risco de perda de contexto entre as partes, com uma fatia recorrente desses casos terminando em cláusula importante que cai entre as duas chamadas e exige intervenção do humano que está orquestrando o agente.\nEm Claude Sonnet 4.5, com janela de duzentos mil tokens padrão (e até um milhão em prévia para casos selecionados), a mesmo RFP cabe em uma única chamada com folga, sem reconciliação e sem cláusula perdida no corte, e quando essa configuração é combinada com o prompt caching da API, que pela documentação oficial da Anthropic pode reduzir custos de leitura de contexto em até noventa por cento para instruções estáveis, o custo por RFP processado fica competitivo mesmo nos cenários em que Claude tem preço por token superior em algumas faixas.\nA conta correta não é \u0026ldquo;qual modelo é mais barato por milhão de tokens\u0026rdquo;, é qual modelo entrega o documento processado certo na primeira vez, porque cada intervenção humana para reconciliar contexto perdido custa mais para a operação do que qualquer diferença de preço de inferência entre fornecedores.\nAs Três Perguntas Para o Time Para quem está hoje decidindo qual LLM colocar como espinha dorsal de um sistema enterprise, três perguntas valem ser feitas ao time técnico antes que a decisão vire commit em alguma config.\n\u0026ldquo;Qual é o tamanho real do contexto operacional em produção?\u0026rdquo; Se a janela exigida fica abaixo de cinquenta mil tokens em noventa e cinco por cento dos casos, a vantagem de contexto longo de Claude não justifica troca de fornecedor, mas acima disso o time precisa medir a frequência de reconciliação que o sistema atual está fazendo hoje, porque esse é o número que importa para a decisão, não a especificação de janela máxima escrita no papel da spec.\n\u0026ldquo;O output vai direto para o cliente ou passa por revisão humana antes de chegar lá?\u0026rdquo; Se vai direto, seja em sistema agêntico autônomo, em geração de relatório regulatório ou em código que entra no main branch sem revisão por pull request, a previsibilidade de comportamento pesa muito mais do que diferença marginal em velocidade por chamada, porque o custo de uma resposta errada que chega na ponta é assimétrico em relação ao custo de uma resposta lenta que chega correta.\n\u0026ldquo;O que estamos compartilhando na conversa com o modelo pode virar treino de modelo concorrente?\u0026rdquo; Essa cláusula precisa ser lida na política de uso de dados que vai assinada com o contrato, não na comunicação de marketing, especialmente em projetos com dado regulado nas verticais financeira, de saúde ou jurídica, em que a diferença entre uma arquitetura aprovada e uma reprovada no comitê de governança costuma estar exatamente nesse parágrafo do termo.\nConclusão: O Mérito Que Não Precisa de Convite Asgard percebeu.\nClaude está hoje dentro do Microsoft 365 Copilot, dentro do Amazon Bedrock, dentro do Google Cloud Vertex AI, ocupando espaço nas stacks enterprise que três anos atrás eram território exclusivo da OpenAI, e Odin abriu a porta não por generosidade do trono, mas porque o mérito de quem aparecia do lado de fora ficou grande demais para continuar sendo ignorado pela corte. O castelo não define quem é bom, define quem chegou primeiro, e quem chega depois com ousadia e entrega consistente não precisa derrubar o muro para reescrever a relação de forças, precisa apenas continuar aparecendo do outro lado dele com o trabalho feito.\nSe você trabalha com dados e IA em projetos enterprise, a pergunta hoje não é mais \u0026ldquo;Claude ou GPT-4o\u0026rdquo; como duelo binário, é o que você precisa que sobreviva em produção: documento longo, raciocínio auditável, pipeline crítico, decisão de arquitetura que custa caro quando erra, agente que precisa manter coerência ao longo de seis etapas seguidas. Nesses cenários, Claude é a escolha, não porque Asgard caiu, mas porque Loki entregou o que o castelo precisava antes de receber qualquer permissão para entrar.\nE quando o rei finalmente abriu a porta, o mérito já estava do outro lado, esperando.\nReferências Anthropic. Claude Sonnet 4.5. https://www.anthropic.com/news/claude-sonnet-4-5 Anthropic. Prompt Caching. https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching Anthropic. Trust Center, Data Privacy and Usage Policies. https://trust.anthropic.com/ Microsoft. Anthropic models available in Microsoft 365 Copilot (September 2025 announcement). https://www.microsoft.com/en-us/microsoft-365/blog/ AWS. Anthropic Claude on Amazon Bedrock. https://aws.amazon.com/bedrock/anthropic/ ","permalink":"https://julianamarialop.github.io/articles/loki-nao-pediu-permissaouma-analise-tecnica-de-claude/","summary":"Asgard foi construído antes de qualquer outro reino. A OpenAI ergueu o castelo com GPT-3, GPT-4 e ChatGPT em uma sequência que ninguém conseguiu acompanhar, e o mundo passou a usar essa tecnologia antes mesmo de…","title":"Loki Não Pediu Permissão.Uma análise técnica de Claude vs OpenAI em projetos enterprise de dados."},{"content":"O Custo Invisível de Cada Chamada Imagine que toda vez que você abre uma reunião, o assistente lê em voz alta todas as regras da empresa antes de começar. Duzentas páginas. Todo dia. Em cada reunião. Mesmo que todo mundo já saiba o que está escrito ali.\nParece absurdo. Mas é exatamente o que acontece na maioria das soluções de IA construídas com Claude via API. A cada chamada, o mesmo contexto, as mesmas instruções, os mesmos documentos de referência são enviados e reprocessados do zero. Como se Claude nunca tivesse visto aquilo antes.\nO custo disso não aparece em um único item da fatura. Ele se acumula silenciosamente, chamada por chamada, até virar um número que ninguém consegue explicar.\nExiste uma solução. E ela tem tudo a ver com a forma como Gambito joga suas cartas.\nO Mutante Que Nunca Desperdiça Energia Gambito não é o mutante mais forte dos X-Men. Não tem o adamantium de Wolverine, a telepatia de Xavier nem o controle climático de Tempestade. O que ele tem é algo mais raro: a capacidade de carregar energia cinética em qualquer objeto e liberá-la no momento exato, sem desperdício.\nEle não recarrega uma carta que já está carregada. Não gasta energia nova no que já foi processado. Cada joule é aplicado uma vez, com precisão, e reutilizado ao máximo antes de ser descartado.\nÉ exatamente assim que funciona o Prompt Caching da API do Claude.\nEm qualquer solução construída com Claude via API, a maior fonte de custo invisível não é a resposta que Claude gera. É o contexto que você envia em cada chamada: o system prompt com as regras do negócio, o documento que está sendo analisado, o histórico da conversa. Tudo isso é reprocessado do zero a cada requisição, como se Gambito recarregasse cada carta antes de cada jogada.\nO Prompt Caching resolve isso. Você carrega o contexto uma vez, ele fica armazenado, e nas chamadas seguintes Claude lê do cache a uma fração do custo original. A carta já está carregada. É só jogar.\nO Problema Que Ninguém Vê na Fatura Para entender o impacto do Prompt Caching, é preciso entender como a API do Claude funciona por baixo.\nA API do Claude é stateless: cada chamada é processada do zero, sem memória das anteriores. Isso significa que se você tem um system prompt de 5.000 tokens descrevendo as regras de negócio da sua solução, esses 5.000 tokens são enviados e reprocessados em cada chamada.\nImagine uma solução de atendimento ao cliente que recebe 10.000 conversas por dia. Em cada conversa, o system prompt de 5.000 tokens é reprocessado. Isso é 50 milhões de tokens de entrada só de contexto repetido, todo dia, pagos na mesma tarifa que os tokens novos.\nOu imagine um agente de análise de documentos que lê um contrato de 50.000 tokens e responde dez perguntas diferentes sobre ele. Sem caching, o contrato é reprocessado dez vezes. Com caching, ele é processado uma vez e lido nove vezes a 10% do custo.\nGambito não relança as mesmas cartas do zero. Ele mantém as que já estão carregadas e usa a energia onde ela ainda não foi aplicada.\nComo o Prompt Caching Funciona na Prática O mecanismo é direto. Quando o time de engenharia faz a primeira chamada à API com um bloco de conteúdo marcado para cache, a Anthropic processa e armazena aquele conteúdo. Nas chamadas seguintes que usam o mesmo conteúdo, Claude lê do cache em vez de reprocessar.\nA estrutura de preços reflete exatamente esse comportamento:\nA primeira chamada que cria o cache custa 1,25x o preço normal de tokens de entrada para cache de 5 minutos, ou 2x para cache de 1 hora. É o custo de carregar a carta.\nAs chamadas seguintes que leem do cache custam apenas 10% do preço normal de tokens de entrada. É o custo de reutilizar a carta já carregada.\nO break-even é imediato: com cache de 5 minutos, a segunda chamada já paga o custo de escrita e começa a gerar economia. Com cache de 1 hora, a economia começa na terceira chamada.\nNa prática, para um agente que recebe 100 chamadas com o mesmo system prompt de 10.000 tokens usando o Claude Sonnet 4.6:\nSem cache: 100 chamadas × 10.000 tokens × $3/MTok = $3,00 Com cache: 1 escrita (12.500 tokens × $3/MTok = $0,038) + 99 leituras (10.000 tokens × $0,30/MTok = $0,297) = $0,34\nUma redução de 88% no custo de entrada com uma mudança de implementação que leva menos de uma hora.\nComo Fica no Código: O Mínimo que o Time Precisa Implementar Para quem vai cobrar do time de engenharia, é importante entender o que a implementação envolve. É uma mudança pequena e cirúrgica: adicionar o parâmetro cache_control no bloco de conteúdo que deve ser cacheado.\nVeja a diferença entre uma chamada sem cache e uma com cache para um agente de monitoramento de pipelines do Microsoft Fabric:\nSem cache — contexto reprocessado a cada chamada:\nimport anthropic client = anthropic.Anthropic() # System prompt com regras do agente: reprocessado em CADA chamada response = client.messages.create( model=\u0026#34;claude-sonnet-4-6\u0026#34;, max_tokens=1024, system=\u0026#34;\u0026#34;\u0026#34;Você é um agente de monitoramento de pipelines do Microsoft Fabric. Analise o status reportado e classifique a severidade seguindo estas regras: - CRÍTICO: pipeline com falha que afeta dados de produção em Gold - ALTO: pipeline com falha em Silver com impacto em relatórios - MÉDIO: pipeline com falha em Bronze sem impacto imediato - BAIXO: alertas de performance sem falha confirmada Sempre inclua: severidade, diagnóstico provável e próximo passo recomendado.\u0026#34;\u0026#34;\u0026#34;, messages=[ {\u0026#34;role\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;content\u0026#34;: f\u0026#34;Status do pipeline: {status_pipeline}\u0026#34;} ] ) Com cache — system prompt carregado uma vez, reutilizado nas demais:\nimport anthropic client = anthropic.Anthropic() # System prompt cacheado: processado apenas na primeira chamada response = client.messages.create( model=\u0026#34;claude-sonnet-4-6\u0026#34;, max_tokens=1024, system=[ { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;\u0026#34;\u0026#34;Você é um agente de monitoramento de pipelines do Microsoft Fabric. Analise o status reportado e classifique a severidade seguindo estas regras: - CRÍTICO: pipeline com falha que afeta dados de produção em Gold - ALTO: pipeline com falha em Silver com impacto em relatórios - MÉDIO: pipeline com falha em Bronze sem impacto imediato - BAIXO: alertas de performance sem falha confirmada Sempre inclua: severidade, diagnóstico provável e próximo passo recomendado.\u0026#34;\u0026#34;\u0026#34;, \u0026#34;cache_control\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;ephemeral\u0026#34;} # ← essa linha ativa o cache } ], messages=[ {\u0026#34;role\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;content\u0026#34;: f\u0026#34;Status do pipeline: {status_pipeline}\u0026#34;} ] ) # Verificando se o cache está funcionando uso = response.usage print(f\u0026#34;Tokens escritos no cache: {uso.cache_creation_input_tokens}\u0026#34;) print(f\u0026#34;Tokens lidos do cache: {uso.cache_read_input_tokens}\u0026#34;) A diferença é uma linha: \u0026ldquo;cache_control\u0026rdquo;: {\u0026ldquo;type\u0026rdquo;: \u0026ldquo;ephemeral\u0026rdquo;}. O resto da lógica não muda. Para o time de engenharia, essa é uma das otimizações de maior retorno por menor esforço no ecossistema Claude.\nUm Caso Real: Agente de Qualidade de Dados no Fabric Para tornar o impacto concreto, considere um agente de qualidade de dados construído sobre o Microsoft Fabric. Ele monitora tabelas da camada Silver, detecta anomalias e gera alertas para o time de dados.\nO agente tem um system prompt de 8.000 tokens com as regras de qualidade, thresholds aceitáveis por domínio de dados, padrões de nomenclatura e formato esperado de alertas. Ele roda 500 verificações por dia, uma para cada tabela monitorada.\nSem Prompt Caching: 500 chamadas × 8.000 tokens × $3/MTok = $12,00/dia = $360/mês só de context repetido.\nCom Prompt Caching: 1 escrita (10.000 tokens × $3/MTok = $0,03) + 499 leituras (8.000 tokens × $0,30/MTok = $1,197) = $1,23/dia = $36,90/mês\nUma economia de $323/mês com uma linha de código adicionada ao system prompt. Em um ano, são mais de $3.800 economizados em um único agente.\nE esse é um cenário conservador. Agentes de maior volume, com system prompts mais longos ou que processam documentos extensos, têm economias proporcionalmente maiores.\nO Que Pode e O Que Não Pode Ser Cacheado Gambito sabe que nem todo objeto vale a pena carregar. Cartas pequenas demais não acumulam energia suficiente para justificar o gesto. O mesmo raciocínio se aplica ao Prompt Caching.\nCandidatos ideais para cache:\nO system prompt é o candidato mais óbvio. Se a solução tem um conjunto fixo de instruções, regras de negócio ou personas que acompanham cada chamada, esse conteúdo deve ser cacheado. Ele nunca muda entre chamadas, mas é reprocessado em cada uma delas.\nDocumentos de referência são outro candidato poderoso. Um agente que analisa especificações técnicas, contratos de dados ou documentação de APIs pode cachear esse conteúdo e fazer múltiplas perguntas sem reprocessar a cada pergunta.\nDefinições de ferramentas em sistemas agenticos com muitas tools também se beneficiam. Se o agente tem 20 ferramentas definidas e usa apenas 3 em cada chamada, cachear todas as definições evita reprocessamento constante.\nQuando o cache não compensa:\nConteúdo que muda a cada chamada não pode ser cacheado de forma eficiente. Se o contexto varia significativamente entre requisições, não há cache hit e você paga o custo de escrita sem o benefício da leitura.\nO conteúdo também precisa ter no mínimo 1.024 tokens para ser elegível ao cache nos modelos Sonnet e Haiku. Blocos menores são processados normalmente sem erro, mas sem cache.\nComo um Arquiteto Deve Cobrar Isso do Time Você não precisa implementar o Prompt Caching. Mas precisa saber quando exigi-lo e como validar que está funcionando.\nAs perguntas certas para o time de engenharia:\n\u0026ldquo;O system prompt da solução está sendo cacheado?\u0026rdquo; Esta é a pergunta mais básica. Se a resposta for não, ou se o time não souber responder, há uma oportunidade imediata de redução de custo.\n\u0026ldquo;Qual é a proporção de cache hits versus cache misses nas chamadas de produção?\u0026rdquo; A API retorna métricas de cache em cada resposta: cache_creation_input_tokens para escritas e cache_read_input_tokens para leituras. Um dashboard monitorando essa proporção é o mínimo esperado de qualquer solução em produção.\n\u0026ldquo;Qual é o TTL configurado: 5 minutos ou 1 hora?\u0026rdquo; Para soluções com alto volume de chamadas em janelas curtas, o cache de 5 minutos geralmente é suficiente e mais barato de escrever. Para soluções com picos espaçados, o cache de 1 hora garante que o contexto permaneça disponível entre os picos.\nO sinal de que o cache não está funcionando:\nSe o custo por chamada não cai conforme o volume aumenta, o cache provavelmente não está ativo ou está sendo invalidado. Em uma solução saudável com Prompt Caching, o custo marginal de cada chamada adicional deve cair progressivamente à medida que o cache é reutilizado.\nPrompt Caching e Batch API: A Combinação Que Muda o Jogo O Prompt Caching não existe isolado. Combinado com a Batch API da Anthropic, o potencial de redução de custo sobe para até 95%.\nA Batch API processa requisições de forma assíncrona com desconto de 50% em todos os tokens. Para workloads que não precisam de resposta em tempo real, como geração de relatórios, classificação em lote, análise de documentos ou enriquecimento de dados, a combinação Batch API + Prompt Caching entrega o custo mais baixo possível no ecossistema Claude.\nA lógica é simples: Batch API reduz o custo de saída e entrada padrão em 50%. Prompt Caching reduz o custo de entrada repetida em 90%. Aplicados juntos em workloads elegíveis, o resultado é uma fração mínima do custo original.\nGambito não escolhe apenas a carta certa. Ele escolhe o momento certo para jogá-la.\nQuando Exigir Prompt Caching em uma Solução Para um arquiteto avaliando ou revisando uma solução que usa Claude via API, o Prompt Caching deve ser requisito em qualquer cenário onde:\nO system prompt tem mais de 1.024 tokens e é enviado em todas as chamadas. O volume de chamadas é superior a 10 por hora com o mesmo contexto base. A solução analisa documentos grandes com múltiplas perguntas na mesma sessão. O agente tem muitas ferramentas definidas que são carregadas em cada chamada. O custo de API está crescendo proporcionalmente ao volume sem redução marginal.\nSe esses critérios estão presentes e o Prompt Caching não está implementado, a solução está pagando full price pelo que já devia estar no cache. São as cartas de Gambito sendo recarregadas do zero antes de cada jogada.\nConclusão: A Energia Certa no Momento Certo O que torna Gambito letal não é a quantidade de energia que ele tem. É a precisão com que ele a aplica. Carregar uma carta uma vez e usá-la múltiplas vezes é mais eficiente do que recarregar antes de cada jogada.\nO Prompt Caching é a implementação direta dessa filosofia em soluções com Claude. O contexto que não muda não precisa ser reprocessado. A energia, nesse caso o custo de tokens, deve ser aplicada onde realmente há algo novo a processar.\nPara líderes e arquitetos que estão levando Claude para produção, essa não é uma otimização opcional. É uma decisão de arquitetura com impacto direto na viabilidade econômica da solução. Uma solução de alto volume sem Prompt Caching é como Gambito jogando todas as cartas sem ter carregado nenhuma delas.\nO custo será sempre maior do que deveria.\nReferências Anthropic. Prompt Caching. https://platform.claude.com/docs/en/build-with-claude/prompt-caching Anthropic. Pricing. https://platform.claude.com/docs/en/about-claude/pricing Anthropic. Batch API. https://platform.claude.com/docs/en/build-with-claude/batch ","permalink":"https://julianamarialop.github.io/articles/cartas-de-gambito-como-o-prompt-caching-pode-reduzir-em/","summary":"Imagine que toda vez que você abre uma reunião, o assistente lê em voz alta todas as regras da empresa antes de começar. Duzentas páginas. Todo dia. Em cada reunião. Mesmo que todo mundo já saiba o que está escrito ali.","title":"As Cartas de Gambito: Como o Prompt Caching Pode Reduzir em até 90% o Custo das suas Soluções com Claude"},{"content":"A Atração que Só Eles Entendiam Na Mansão Xavier, dois jovens mutantes cresceram lado a lado. Scott Summers e Jean Grey viviam o mesmo mundo impossível: treinando para missões que ninguém de fora entenderia, carregando poderes que precisavam ser controlados a todo momento, dependendo um do outro de uma forma que palavras não davam conta de explicar. O que havia entre eles não era dito em voz alta. Não havia espaço para isso. Havia missão, havia equipe, havia a responsabilidade de manter o foco. Mas nos treinos na Sala de Perigo, nas estratégias traçadas em silêncio, na confiança que se construía sem precisar ser nomeada, a atração foi tomando forma.\nE assim ficou. Em sigilo absoluto. Só eles sabiam. Só eles podiam saber. O que existia entre os dois vivia nos gestos sutis, nos olhares rápidos antes de uma missão, na certeza silenciosa de que o outro estaria lá quando precisasse. Para o resto da equipe, eram apenas dois mutantes que trabalhavam bem juntos. Para eles, era muito mais do que isso. Era uma cumplicidade que só funcionava porque cada um entendia profundamente o que o outro fazia. Ciclope via o campo inteiro, planejava com precisão, controlava cada variável. Jean sentia o que os dados não mostravam, criava o que ainda não existia, enxergava além do óbvio. Sozinhos, cada um era poderoso. Juntos, eram imbatíveis.\nClaude Design e Claude Code têm exatamente essa dinâmica. Dois produtos da Anthropic que trabalham lado a lado, cada um com seu papel, cada um incompleto sem o outro. E quando trabalham juntos, entregam o que nenhum dos dois conseguiria sozinho.\nCiclope: A Visão que Precisa Ser Canalizada Existe um equívoco comum sobre Ciclope. As pessoas olham para ele e veem o líder controlado, o estrategista frio, o mutante que nunca age por impulso. E concluem que ele não tem criatividade.\nErrado. Ciclope tem uma visão estratégica enorme. Ele enxerga o campo de batalha inteiro, antecipa movimentos, cria planos que outros nem imaginaram. O problema não é a falta de criatividade. É que o poder dele é destrutivo se não for canalizado. As viseiras não são uma limitação. São o que permite que a visão de Scott se torne ação sem destruir tudo ao redor.\nClaude Design funciona exatamente assim.\nLançado pela Anthropic em 17 de abril de 2026 e alimentado pelo Claude Opus 4.7, o modelo mais capaz da Anthropic para tarefas visuais, o Claude Design transforma descrições em protótipos, slides, wireframes, mockups e interfaces interativas. Você descreve o que precisa, ele constrói uma primeira versão. A partir daí, você refina por conversa, comentários inline, edições diretas ou sliders customizados que o próprio Claude cria para aquele projeto.\nA visão estratégica enorme está lá: Claude Design lê o codebase e os arquivos de design da sua organização durante o onboarding e constrói automaticamente um design system com as cores, tipografia e componentes da empresa. Cada projeto depois disso parte dessa base, consistente com tudo que já existe. Você pode fazer upload de imagens de referência, documentos em PPTX, DOCX ou XLSX, ou apontar diretamente para o codebase.\nMas assim como Ciclope precisa das viseiras para que seu poder não destrua o que está construindo, Claude Design precisa de algo que transforme a visão em realidade funcional. Precisa de Jean Grey.\nJean Grey: A Precisão que Executa Jean Grey é frequentemente lembrada pelo poder da Fênix, pela força imensa e às vezes incontrolável. Mas o que define Jean no dia a dia das missões não é a força bruta. É a precisão telepática.\nEla não precisa de um mapa para entender o campo. Ela sente onde cada peça precisa estar. Ela executa com cirurgia porque entende profundamente o contexto, a intenção e o objetivo. Quando Scott traça o plano, Jean sabe exatamente como fazer acontecer sem perder nenhum detalhe pelo caminho.\nClaude Code é Jean Grey nessa relação.\nClaude Code lê o codebase, entende a arquitetura existente, identifica dependências e implementa com precisão o que foi desenhado. Ele não improvisa. Ele executa com profundidade contextual que vai muito além de gerar código genérico. Quando tem um protótipo como referência, a implementação é cirúrgica: mantém consistência com o que já existe, respeita as convenções do projeto e entrega algo que funciona de verdade, não apenas algo que parece certo.\nE aqui está o detalhe que muda tudo: o handoff entre Claude Design e Claude Code é nativo. Quando um design está pronto no Claude Design, você empacota tudo em um handoff bundle com um único comando e passa para o Claude Code implementar. Não há fricção de ferramenta, não há tradução entre formatos, não há reunião de alinhamento entre times. A visão de Ciclope chega intacta para Jean executar.\nO Fluxo que Ninguém Mais Consegue Replicar Na Mansão Xavier, o que tornava Scott e Jean imbatíveis não era apenas o poder individual de cada um. Era o fato de que eles operavam com um nível de cumplicidade que eliminava o atrito entre planejamento e execução.\nCiclope traçava o plano. Jean o executava. Sem reunião de alinhamento. Sem perda de contexto no meio do caminho. Sem a inevitável distância entre o que foi pensado e o que foi entregue. Claude Design e Claude Code replicam essa cumplicidade em um fluxo de produto real.\nUm product manager descreve em linguagem natural o que precisa: uma interface de monitoramento de pipelines para o Microsoft Fabric, com cards de status por domínio, alertas visuais para falhas críticas e navegação por camada de dados. Claude Design constrói o protótipo interativo em minutos, aplicando automaticamente o design system da organização. O PM refina por conversa até a visão estar precisa.\nQuando o protótipo está aprovado, Claude Code recebe o handoff bundle e implementa. Ele lê a estrutura do codebase existente, entende as convenções do time, e entrega o código que transforma o protótipo em produto. O engenheiro revisa, valida e vai para produção.\nO ciclo que antes levava semanas, da ideia ao protótipo aprovado à implementação, comprime para dias. A Datadog relatou comprimir um ciclo de uma semana de briefings, mockups e revisões em uma única conversa no Claude Design. A Brilliant relatou que páginas que exigiam mais de 20 prompts em ferramentas concorrentes precisavam de apenas 2 no Claude Design antes de seguir para implementação no Claude Code.\nO Que Muda Para Times de Dados Para times de dados e arquitetos que estão construindo produtos sobre plataformas como Microsoft Fabric e Databricks, essa combinação tem implicações práticas imediatas.\nO handoff entre produto e engenharia deixa de ser um gargalo. Hoje, um arquiteto que quer propor uma nova interface de monitoramento precisa descrever em palavras o que imaginou, esperar um designer interpretar, revisar, aprovar e só então passar para engenharia implementar. Com Claude Design e Claude Code, o arquiteto vai do conceito ao protótipo interativo em uma sessão e ao código em outra.\nQualquer pessoa com contexto de negócio pode criar a visão. Claude Design foi construído para quem tem a ideia mas não tem background de design. O product owner que conhece profundamente os dados e os processos pode criar o protótipo ele mesmo, sem depender de um designer para traduzir o que está na cabeça.\nO design system da organização é respeitado automaticamente. Claude Design lê o codebase e os arquivos de design existentes e aplica as convenções automaticamente. O protótipo já nasce dentro dos padrões visuais da empresa, sem que ninguém precise lembrar de seguir o guia de estilo.\nA exportação é completa. Protótipos podem ser exportados como HTML, PDF, PPTX, enviados para o Canva para colaboração ou empacotados para handoff direto ao Claude Code. O output serve tanto para apresentação executiva quanto para implementação técnica.\nDisponibilidade e Acesso Claude Design está disponível em research preview desde 17 de abril de 2026 para assinantes dos planos Pro, Max, Team e Enterprise. Ele vive dentro do claude.ai, acessível pelo ícone de paleta na navegação lateral esquerda.\nUm detalhe importante: Claude Design tem seu próprio controle de uso, separado dos limites de chat e de Claude Code. Usar Claude Design não consome sua cota de mensagens nem seus créditos de Claude Code. São limites independentes que coexistem dentro do mesmo plano.\nPara planos Enterprise, a feature está desativada por padrão e precisa ser habilitada pelo administrador.\nConclusão: A Cumplicidade que Entrega Scott e Jean não precisavam se explicar. A atração construída ao longo de anos de missões juntos criou um entendimento que ia além das palavras. Quando Ciclope traçava o plano, Jean já sabia como executar. Quando Jean sinalizava uma abertura, Scott já sabia como aproveitar.\nClaude Design e Claude Code têm essa mesma qualidade. Não são dois produtos que precisam ser conectados com esforço. São dois produtos que foram construídos para trabalhar juntos, com um handoff nativo que preserva a intenção do design até a implementação final. A visão de produto que antes ficava perdida na tradução entre times agora chega intacta até o código.\nCiclope traça o plano. Jean executa com precisão. E o resultado é algo que nenhum dos dois entregaria sozinho.\nReferências Anthropic. Introducing Claude Design. https://www.anthropic.com/news/claude-design-anthropic-labs Anthropic. Claude Code Overview. https://code.claude.com/docs/en/overview TechCrunch. Anthropic launches Claude Design. https://techcrunch.com/2026/04/17/anthropic-launches-claude-design-a-new-product-for-creating-quick-visuals/ ","permalink":"https://julianamarialop.github.io/articles/o-que-ciclope-e-jean-grey-me-ensinaram-sobre-claude-design/","summary":"Na Mansão Xavier, dois jovens mutantes cresceram lado a lado. Scott Summers e Jean Grey viviam o mesmo mundo impossível: treinando para missões que ninguém de fora entenderia, carregando poderes que precisavam ser…","title":"O Que Ciclope e Jean Grey Me Ensinaram Sobre Claude Design e Claude Code"},{"content":"O Cientista que Ninguém Vê Quando os X-Men entram em combate, o mundo vê Wolverine, Tempestade, Ciclope. Ninguém vê Hank McCoy, o Fera, trabalhando nos sistemas por baixo. Mas é ele quem projetou o Cerebro. É ele quem mantém a Sala de Perigo funcionando. É ele quem garante que a infraestrutura da Mansão Xavier aguenta qualquer missão, por mais complexa que seja.\nHank não constrói para o momento. Ele constrói para evoluir.\nEssa é a distinção que separa quem usa agentes de IA de quem projeta sistemas agenticos de verdade. E foi exatamente com essa filosofia que a Anthropic construiu o Claude Managed Agents da Anthropic , lançado em abril de 2026.\nEm termos simples: o Managed Agents é uma infraestrutura gerenciada pela Anthropic que permite criar agentes Claude autônomos sem construir toda a estrutura por baixo do zero. Antes dele, colocar um agente em produção exigia meses de engenharia: containers, gerenciamento de estado, autenticação, recuperação de erros, memória entre sessões. O Managed Agents elimina esse trabalho. Você define o comportamento. A Anthropic garante que ele funciona.\nE tudo isso é configurável diretamente pelo Claude Console, sem escrever uma linha de código.\nPor Que a Ordem Importa O erro mais comum de quem começa a construir agentes é pular direto para a complexidade. A jornada evolutiva certa tem três etapas, e cada uma precisa estar sólida antes da próxima: skills bem definidas, memória entre sessões e agente autônomo em produção.\nSkills resolvem tarefas definidas e repetíveis. Memória transforma sessões isoladas em conhecimento acumulado. O agente autônomo é o resultado dos dois funcionando juntos. Tentar construir o terceiro sem os dois primeiros é como Hank tentar construir o Cerebro antes de entender como funciona a telepatia.\nEntendendo os Dois Objetos Centrais Antes de construir qualquer coisa, é fundamental entender a distinção entre os dois objetos principais do Managed Agents.\nO Environment é o laboratório. Ele define o container onde o agente executa, quais pacotes estão instalados, quais sistemas externos pode acessar e, crucialmente, onde os arquivos de skills ficam armazenados e persistem entre sessões. É a estante de manuais do laboratório do Fera: os manuais ficam lá, disponíveis para qualquer missão que usar aquele laboratório.\n_Exemplo da conexão MCP._\n_Exemplo da tela de Environments_\nO Agent é o cérebro. Ele define o modelo, o system prompt, as ferramentas disponíveis e as skills que vai carregar do Environment. É versionado: cada atualização gera uma nova versão com histórico completo para auditoria.\n_Exemplo de um Agente_\nA relação entre os dois é simples: o Environment persiste o conhecimento. O Agent aplica o conhecimento. Uma Session é quando os dois se encontram para executar uma missão específica.\n_Exemplo de Criação da Sessão_\n_Exemplo de Execução de Sessão_\nFase 1: Construindo as Skills O primeiro passo no Console é criar o Environment em console.anthropic.com → Managed Agents → Environments. Em seguida, crie o Agent em Managed Agents → Agents com o modelo, o system prompt e as skills que vai carregar do Environment.\nO cenário concreto: um time de dados que gerencia 200 pipelines no Microsoft Fabric. Todo dia, falhas aparecem, logs precisam ser analisados e incidentes precisam ser documentados. Hoje isso consome horas do time de engenharia.\nAs primeiras skills para esse agente: revisar-pipeline, que analisa arquivos e retorna um relatório de status e riscos. gerar-incidente, que formata o relatório com severidade e próximos passos sempre no mesmo padrão. diagnosticar-erro, que interpreta logs e sugere a causa raiz.\nEsses arquivos ficam persistidos no Environment. Se você ajustar uma skill, edita o arquivo e todas as sessões futuras já usam a versão atualizada.\nValide cada skill individualmente antes de avançar. Se Claude hesita ou retorna um formato diferente do esperado, a skill precisa ser refinada.\nQuando a Skill Já Não É Suficiente Existem quatro sinais claros de que chegou a hora de evoluir para agente com memória:\nO contexto necessário é maior do que uma conversa comporta, e o agente precisa de informações de sessões anteriores. A tarefa envolve múltiplos passos interdependentes que exigem decisões no meio do caminho. O volume justifica autonomia, com o time acionando a mesma skill dezenas de vezes por dia. O erro se repete porque ninguém lembrou: a skill não aprende, o agente com memória sim.\nHank não construiu o Cerebro porque a lista de presença era complicada. Ele construiu porque a escala da missão exigia algo que nenhum processo manual conseguia entregar.\nFase 2: Adicionando Memória e Evoluindo para Múltiplos Agentes No Console, ao editar o Agent, ative o toggle Memory. Atualize o system prompt instruindo Claude a consultar a memória ao iniciar cada sessão e registrar o que foi descoberto ao finalizar.\nCom essa instrução, o agente para de começar do zero. Na quinta sessão, ele já identifica o timeout do pipeline vendas_diarias antes de verificar o log porque reconhece o padrão. Na vigésima, ele inclui automaticamente a recorrência histórica no relatório de incidente.\nQuando a complexidade cresce ainda mais, é hora de dividir responsabilidades. No cenário do Fabric com 200 pipelines, um único agente pode não ser suficiente. A evolução natural é criar agentes especializados: um para monitoramento, outro para diagnóstico, outro para geração de relatórios. Um agente orquestrador recebe o objetivo, delega para os especialistas e consolida os resultados. Cada especialista tem seu próprio conjunto de skills no Environment e sua própria memória acumulada.\nEssa divisão não é complexidade por complexidade. É a diferença entre um cientista que faz tudo sozinho e um laboratório com especialistas que colaboram.\nFase 3: Publicando para o Time com Governança Com skills sólidas e memória funcionando, o agente está pronto para o time. E aqui está o ponto que muda a equação de adoção: os usuários finais não precisam de licença Claude. A organização paga pela API via tokens e runtime. Os usuários interagem pela interface que a organização escolher, sem conta na Anthropic, sem plano Pro.\nNo cenário do Fabric, a publicação mais natural é via Microsoft Teams usando MCP. Qualquer engenheiro menciona o agente no canal, a mensagem chega como evento, o agente processa com suas skills e memória e responde com o relatório formatado. O engenheiro recebe o diagnóstico em dois minutos em vez de gastar uma hora analisando logs.\nPara outros contextos: via Slack com o mesmo padrão, via interface interna construída pelo time de TI, ou via Claude Console para usuários técnicos que precisam de visibilidade total.\nE visibilidade é a palavra certa. No Console, a aba Sessions registra cada sessão com o histórico completo: cada ferramenta chamada, cada decisão tomada, cada arquivo gerado, com timestamp e custo por sessão. Para um líder de dados, isso responde a pergunta que sempre surge em ambiente enterprise: o que o agente fez, por quê e quando? A auditoria não é uma feature adicional. É parte da arquitetura.\nO Que Custa O Managed Agents cobra em duas dimensões: tokens consumidos às taxas padrão da API, com Prompt Caching reduzindo em até 90% o custo das skills e system prompt reutilizados, e runtime de sessão a $0,08 por hora, cobrado apenas enquanto o agente está em status running.\nNo cenário do Fabric com 500 verificações por dia e sessões de 5 minutos: 500 × (5/60) × $0,08 = $3,33/dia em runtime.\nO Batch API não se aplica ao Managed Agents. Para workloads sem necessidade de estado, a API padrão com Batch é mais econômica. Managed Agents é a escolha certa quando estado, memória e autonomia são necessários.\nConclusão: Construir Para Evoluir Hank McCoy ficou famoso não pelo sistema mais complexo, mas pelo mais durável. O Cerebro sobreviveu a décadas de missões porque cada componente foi validado antes de ser integrado ao próximo.\nComece pelas skills no Environment. Valide cada uma. Identifique quando o contexto, o volume ou a repetição de erros sinalizem que é hora de evoluir. Adicione memória. Divida em especialistas quando a missão exigir. Publique via Teams, Slack ou interface interna.\nOs engenheiros do time vão interagir com um agente que aprende, lembra e melhora. Sem saber o que roda por baixo. Sem precisar de licença Claude.\nA mansão aguenta qualquer missão porque a infraestrutura foi construída para isso. Um passo de cada vez.\nReferências Anthropic. Claude Managed Agents Overview. https://platform.claude.com/docs/en/managed-agents/overview Anthropic. Claude Managed Agents — get to production 10x faster. https://claude.com/blog/claude-managed-agents Anthropic. Cloud Environment Setup. https://platform.claude.com/docs/en/managed-agents/environments Verdent. Claude Managed Agents Pricing. https://www.verdent.ai/guides/claude-managed-agents-pricing ","permalink":"https://julianamarialop.github.io/articles/o-fera-nao-construiu-cerebro-em-um-dia-jornada-evolutiva/","summary":"Quando os X-Men entram em combate, o mundo vê Wolverine, Tempestade, Ciclope. Ninguém vê Hank McCoy, o Fera, trabalhando nos sistemas por baixo. Mas é ele quem projetou o Cerebro. É ele quem mantém a Sala de Perigo…","title":"O Fera não construiu o Cerebro em um dia: A Jornada Evolutiva com Claude Managed Agents"},{"content":"O Mito da Barreira Técnica Existe uma crença no mundo de dados que poucos questionam: a IDE é território de desenvolvedor. O VS Code, com suas pastas, arquivos e terminal, seria um ambiente hostil para quem não escreve código todos os dias.\nTempestade nunca acreditou em barreiras assim.\nQuando ela entra em combate, não precisa entender a física atmosférica para invocar um raio. Ela não calcula a pressão do ar nem a resistência elétrica antes de agir. Ela sabe quais poderes tem, sabe quando acioná-los, e confia na combinação certa para entregar o resultado. O conhecimento técnico profundo existe por baixo, mas não é o que ela precisa para operar.\nCom duas extensões no VS Code, Claude Code e GitLab, qualquer profissional de dados pode trabalhar com projetos reais, entender código, propor mudanças, acompanhar pipelines e colaborar com times de engenharia, sem escrever uma linha de código sequer.\nEste artigo é o manual que Tempestade daria para qualquer recruta antes de entrar no campo.\nPor Que o VS Code e Não o Claude.ai? Essa é a primeira pergunta que surge. Afinal, o claude.ai já está no navegador, já responde perguntas sobre código e já ajuda a analisar arquivos. Por que instalar um programa diferente?\nA resposta está na diferença entre pedir conselho por telefone e ter o especialista sentado ao seu lado olhando para a mesma tela.\nNo claude.ai, você copia um trecho de código, cola na conversa e Claude responde. Funciona, mas tem limites sérios: você precisa copiar manualmente o que quer analisar, Claude não vê o projeto inteiro, não sabe como os arquivos se relacionam e não consegue fazer mudanças reais nos arquivos.\nNo VS Code com Claude Code, Claude vive dentro do projeto. Ele lê todas as pastas e arquivos ao mesmo tempo, entende como os componentes se conectam, faz mudanças reais diretamente nos arquivos e salva. Você não copia nada. Você aponta e pede.\nÉ a diferença entre descrever um problema de pipeline para alguém que nunca viu o projeto e sentar com um especialista que já leu cada arquivo antes da reunião começar.\nPara quem trabalha com projetos de dados que envolvem dezenas de arquivos, pipelines interligados e repositórios compartilhados com times de engenharia, essa diferença é o que torna o VS Code o ambiente certo.\nAntes de Começar: O Que Você Precisa Antes de instalar qualquer extensão, verifique se você tem o seguinte:\nVS Code instalado. Acesse code.visualstudio.com e baixe a versão para o seu sistema operacional. A instalação é simples e gratuita.\nConta Claude com plano Pro ou superior. O Claude Code não está disponível no plano gratuito. Você precisa de um plano Pro ($20/mês), Max, Team ou Enterprise. Se ainda não tem, acesse claude.ai/pricing para assinar.\nNode.js instalado. O Claude Code precisa do Node.js para funcionar. Acesse nodejs.org, baixe a versão LTS e instale. Não é necessário saber usá-lo, apenas tê-lo instalado na máquina.\nConta no GitLab. Se o seu time usa GitLab, você já tem. Se ainda não tem, acesse gitlab.com e crie uma conta gratuita.\nCom esses quatro itens prontos, você está equipado para começar.\nO Que Você Vai Conseguir Fazer Com a extensão Claude Code da Anthropic você consegue abrir qualquer arquivo de um projeto, pedir para Claude explicar o que aquele código faz em linguagem simples, solicitar alterações descrevendo o que quer em português, pedir documentação, identificar problemas e entender a estrutura do projeto inteiro sem precisar ler cada arquivo manualmente.\nCom a extensão GitLab você consegue ver issues do projeto diretamente no VS Code, acompanhar o status dos pipelines de CI/CD em tempo real, revisar merge requests, deixar comentários e aprovar mudanças, tudo sem abrir o navegador.\nJuntas, essas duas extensões transformam o VS Code em um ambiente de trabalho completo para qualquer profissional que precisa colaborar com times de engenharia ou entender projetos técnicos.\nPasso 1: Instale as Extensões\nAbra o VS Code. Na barra lateral esquerda, clique no ícone que parece quatro quadrados (ou pressione Ctrl+Shift+X no Windows ou Cmd+Shift+X no Mac). Isso abre o marketplace de extensões.\nInstalando Claude Code:\nNo campo de busca, digite Claude Code. Procure a extensão publicada por Anthropic com mais de 2 milhões de instalações. Clique em Install.\nApós a instalação, um ícone de faísca (Spark) vai aparecer na barra lateral esquerda. Clique nele. Na primeira vez, uma tela de autenticação vai aparecer. Clique em Sign in, autorize no navegador e volte ao VS Code. Você está conectado.\nInstalando GitLab:\nNo mesmo campo de busca, digite GitLab Workflow. Procure a extensão publicada por GitLab com o ícone da raposa. Clique em Install.\nApós a instalação, você vai precisar conectar sua conta GitLab. Clique no ícone da raposa na barra lateral. A extensão vai pedir um Personal Access Token do GitLab. Para gerar um:\nAcesse seu GitLab Vá em Settings → Access Tokens Crie um token com os escopos api e read_user Copie o token e cole na extensão Pronto. As duas extensões estão instaladas e configuradas.\nPasso 2: Abra um Projeto\nPara trabalhar com um projeto existente, vá em File → Open Folder e navegue até a pasta do projeto no seu computador. Se o projeto está no GitLab e você ainda não tem ele localmente, use File → New Window, depois Ctrl+Shift+P para abrir a paleta de comandos e digite Git: Clone. Cole a URL do repositório GitLab e escolha onde salvar.\nQuando o VS Code abrir a pasta do projeto, a extensão GitLab vai reconhecer automaticamente o repositório e começar a mostrar informações na barra lateral.\nTempestade não precisa construir o campo de batalha. Ela entra nele como está e orienta os elementos ao redor.\nPasso 3: Use Claude Para Entender o Projeto\nClique no ícone de faísca na barra lateral para abrir o painel do Claude Code. Aqui começa a parte onde a barreira técnica desaparece.\nEntendendo a estrutura do projeto:\nNo painel do Claude, digite:\n\u0026gt; \u0026#34;Explique a estrutura deste projeto em português. Quais são as pastas principais, o que cada uma contém e como os componentes se relacionam?\u0026#34; Claude vai ler o projeto inteiro e entregar uma explicação em linguagem simples, sem jargão desnecessário.\nEntendendo um arquivo específico:\nAbra qualquer arquivo no editor. No painel do Claude, use @ para referenciar o arquivo pelo nome e pergunte:\n\u0026gt; \u0026#34;@pipeline_vendas.py O que esse arquivo faz? Explica cada parte em linguagem simples.\u0026#34; Claude lê o arquivo com o contexto completo do projeto e explica cada bloco de forma clara.\nIdentificando problemas:\n\u0026gt; \u0026#34;Analise os arquivos de pipeline neste projeto e me diga se há algum padrão que poderia causar problemas de performance ou falhas.\u0026#34; Claude vai ler os arquivos relevantes, cruzar com boas práticas e entregar um diagnóstico em linguagem acessível.\nPasso 4: Peça Mudanças Sem Escrever Código\nEssa é a parte onde o impacto fica mais evidente. Você não precisa saber Python, SQL ou qualquer linguagem para propor e aplicar mudanças em um projeto.\nExemplos de pedidos que funcionam:\n\u0026gt; \u0026#34;Adicione um comentário explicativo no início de cada função do arquivo @utils.py descrevendo o que ela faz.\u0026#34; \u0026gt; \u0026#34;Esse arquivo está sem tratamento de erros. Adicione mensagens de erro claras para os casos onde a conexão com o banco de dados falha.\u0026#34; \u0026gt; \u0026#34;Crie um arquivo README.md na pasta raiz explicando o que este projeto faz, como está estruturado e quais são os principais pipelines.\u0026#34; Quando Claude sugere uma mudança, ela aparece como um diff visual no editor: o que vai ser removido marcado em vermelho, o que vai ser adicionado em verde. Você revisa, aprova com um clique ou pede ajuste antes de aceitar.\nTempestade não constrói o raio manualmente. Ela diz onde quer que ele caia e observa o resultado antes de confirmar.\nPasso 5: Use GitLab Para Acompanhar e Colaborar\nCom a extensão GitLab ativa, a barra lateral mostra tudo que você precisa sobre o projeto sem sair do VS Code.\nAcompanhando issues:\nClique no ícone da raposa na barra lateral. Expanda Issues and Merge Requests. Você vê todas as issues abertas do projeto com título, status e responsável. Clique em qualquer issue para ler a descrição completa diretamente no VS Code.\nMonitorando pipelines:\nNa barra inferior do VS Code, a extensão GitLab mostra em tempo real o status do pipeline do branch atual: executando, passou ou falhou. Clique no status para ver os detalhes de cada job.\nRevisando e aprovando merge requests:\nNa seção de Merge Requests da extensão, você vê todos os MRs abertos. Clique em qualquer um para ver o diff das mudanças, deixar comentários em linhas específicas e aprovar usando o comando GitLab: Approve Merge Request na paleta de comandos (Ctrl+Shift+P).\nCombinando Claude com GitLab:\nAqui a combinação fica poderosa. Você abre um merge request na extensão GitLab, vê quais arquivos foram modificados, seleciona o conteúdo alterado e pede para Claude:\n\u0026gt; \u0026#34;Esse é o código que foi modificado neste merge request. Explica o que mudou e quais podem ser os impactos dessas mudanças.\u0026#34; Claude analisa o diff e entrega uma explicação que qualquer profissional entende, mesmo sem saber programar.\nPasso 6: Crie sua Primeira Skill Sem Escrever Código\nSkills são instruções reutilizáveis que ensinam Claude a executar tarefas específicas do seu projeto de forma padronizada. E a melhor parte: você não precisa escrever código para criar uma.\nNo painel do Claude Code, digite:\n\u0026gt; \u0026#34;Crie uma skill chamada revisar-pipeline que sempre que eu acionar, analisa os arquivos de pipeline do projeto e me retorna um relatório com status, possíveis erros e sugestões de melhoria em português.\u0026#34; Claude vai criar automaticamente a estrutura de pastas .claude/skills/revisar-pipeline/ com o arquivo SKILL.md configurado e pronto para uso.\nComo usar a skill criada:\nVocê não precisa importar, instalar ou configurar nada. Para acionar a skill, basta digitar no painel do Claude:\n\u0026gt; /revisar-pipeline Claude carrega as instruções da skill e executa a tarefa exatamente como você definiu. Toda vez. Com o mesmo padrão.\nSe quiser ver todas as skills disponíveis no projeto, digite /init no painel. Claude lista tudo que está configurado e disponível para uso imediato.\nTempestade não precisa reaprender a invocar um raio a cada missão. Ela calibrou o poder uma vez e aciona quando precisa.\nO Que Você Passa a Conseguir Fazer\nDepois de configurar esse ambiente, a relação com times de engenharia muda completamente.\nVocê consegue entrar em qualquer repositório do time e entender o que está lá sem depender de ninguém para explicar. Consegue revisar merge requests com entendimento real do impacto das mudanças. Consegue identificar problemas em pipelines sem precisar chamar um engenheiro para decifrar os logs. Consegue propor melhorias de documentação, tratamento de erros e organização de código descrevendo em linguagem natural o que quer.\nTempestade não precisou aprender a voar para controlar o clima. Ela precisou entender quais poderes tinha e quando usá-los.\nO próximo passo é simples: abra o repositório do seu time hoje, clique no ícone de faísca e faça a primeira pergunta. Claude já leu o projeto. Agora é só conversar.\nReferências Anthropic. Use Claude Code in VS Code. https://code.claude.com/docs/en/vs-code GitLab. GitLab for VS Code Extension. https://docs.gitlab.com/editor_extensions/visual_studio_code/ Anthropic. Claude Code for VS Code — Visual Studio Marketplace. https://marketplace.visualstudio.com/items?itemName=anthropic.claude-code Anthropic. Plans \u0026amp; Pricing. https://claude.com/pricing ","permalink":"https://julianamarialop.github.io/articles/tempestade-nao-precisou-aprender-voar-para-controlar-o/","summary":"Existe uma crença no mundo de dados que poucos questionam: a IDE é território de desenvolvedor. O VS Code, com suas pastas, arquivos e terminal, seria um ambiente hostil para quem não escreve código todos os dias.","title":"Tempestade Não Precisou Aprender a Voar Para Controlar o Clima: Como Usar o VS Code com Claude Sem Ser Desenvolvedor"},{"content":"Mystique não é a mutante mais forte. Não tem o adamantium de Wolverine, a telepatia de Xavier ou as rajadas de Ciclope. O que ela tem é algo mais raro: a capacidade de fazer o máximo com o mínimo.\nPara se transformar em qualquer pessoa, ela não precisa de equipamento, de preparação longa ou de recursos externos. Ela lê o ambiente, identifica exatamente o que precisa replicar e executa com precisão cirúrgica. Nenhum movimento desperdiçado. Nenhum detalhe desnecessário. Cada transformação consome exatamente a energia necessária para cumprir a missão.\nEscrever uma skill no Claude Code da Anthropic exige exatamente essa mentalidade.\nUma skill mal escrita é como uma Mystique que transforma em dez pessoas ao mesmo tempo sem necessidade: consome energia, confunde o ambiente e entrega menos do que prometia. Uma skill bem escrita é a transformação perfeita: Claude lê, entende e executa sem desperdício.\nEste é o manual que Mystique usaria se precisasse ensinar alguém a escrever skills.\nO Que é uma Skill e Como Claude a Carrega Antes de escrever, é preciso entender o que acontece quando Claude carrega uma skill.\nUma skill no Claude Code é um arquivo SKILL.md armazenado em .claude/skills/ do seu projeto. Ela instrui Claude a executar um conjunto específico de tarefas de forma padronizada e reutilizável. Pense nela como um conjunto de instruções que transforma Claude em um especialista temporário para aquela tarefa.\nO que a maioria dos desenvolvedores não percebe é como o carregamento funciona. Na inicialização da sessão, Claude carrega apenas os metadados de todas as skills disponíveis: nome e descrição. O corpo completo da skill só é carregado quando Claude determina que ela é relevante para a tarefa em execução. Arquivos adicionais referenciados na skill são carregados apenas quando necessários.\nIsso tem uma implicação direta: cada token no corpo da sua skill compete com a conversa, com o histórico e com outros arquivos de contexto. Uma skill de 2.000 tokens desnecessários é 2.000 tokens subtraídos do que Claude precisa para raciocinar sobre o problema real.\nMystique não carrega uma mala antes de cada missão. Ela leva exatamente o que precisa.\nA Anatomia de uma Skill Bem Escrita Uma skill eficiente tem três componentes: frontmatter, corpo e arquivos de referência opcionais.\nO frontmatter é obrigatório e define como Claude vai descobrir e acionar a skill:\n--- name: sql-optimizer description: Otimiza queries SQL para Databricks, incluindo análise de plano de execução, particionamento e uso de cache. Use quando o usuário pedir para otimizar, revisar ou melhorar performance de queries SQL. allowed-tools: - bash - read --- A descrição é o elemento mais crítico do frontmatter. É ela que Claude usa para decidir se a skill é relevante. Uma descrição vaga faz Claude ignorar a skill. Uma descrição excessivamente longa desperdiça tokens que são carregados em cada sessão. O alvo é entre 20 e 40 palavras, específicas o suficiente para acionar nos casos certos e silenciosas nos casos errados.\nMystique sabe exatamente quando revelar sua identidade e quando permanecer na sombra. A descrição da skill funciona da mesma forma.\nBoas Práticas de Escrita: O Que Colocar no Corpo O corpo da skill é onde a maioria dos desenvolvedores erra. O instinto natural é colocar tudo o que Claude pode precisar saber. O resultado é uma skill obesa que degrada performance e desperdiça contexto.\nA regra de ouro é simples: coloque apenas o que Claude não sabe por padrão.\nClaude já sabe o que é SQL, o que é Databricks, como funciona um plano de execução e quais são as melhores práticas gerais de otimização. Explicar isso na skill é como Mystique praticando no espelho antes de se transformar em alguém que ela já conhece de cor.\nExemplo ruim:\n## Otimização de SQL SQL (Structured Query Language) é uma linguagem de consulta utilizada para interagir com bancos de dados relacionais. Para otimizar queries SQL, é importante entender como o banco de dados executa as consultas. O Databricks utiliza Apache Spark por baixo, que tem características específicas de performance. Sempre analise o plano de execução antes de otimizar... Esse bloco tem aproximadamente 150 tokens. Claude já sabe tudo isso. Zero valor adicionado.\nExemplo bom:\n## Contexto do ambiente - Databricks Runtime: 14.x ou superior - Catálogo Unity: obrigatório para todas as queries - Padrão de nomenclatura de tabelas: `catalog.schema.table_name` - Particionamento padrão: por `data_referencia` (formato yyyy-MM-dd) ## Processo de otimização 1. Execute `EXPLAIN EXTENDED` antes de qualquer alteração 2. Identifique shuffles desnecessários no plano 3. Verifique uso de cache com `spark.catalog.isCached()` 4. Aplique otimizações na ordem: filtros → particionamento → joins → cache 5. Valide com `EXPLAIN COST` após cada alteração significativa ## Restrições do projeto - Nunca use `SELECT *` em tabelas com mais de 50 colunas - Joins em tabelas acima de 1TB requerem broadcast hint explícito - Máximo de 3 níveis de CTEs por query Esse bloco tem aproximadamente 120 tokens e entrega contexto que Claude genuinamente não tem: as especificidades do seu ambiente, suas convenções e suas restrições. É o que Mystique precisaria saber antes de se passar por alguém do seu time.\nRedução de Tokens: A Técnica da Transformação Progressiva Mystique não se transforma em uma pessoa diferente para cada detalhe de uma missão. Ela assume uma identidade e extrai o que precisa de forma incremental, conforme a situação exige.\nSkills bem arquitetadas funcionam da mesma forma, com uma técnica chamada progressive disclosure: o arquivo principal contém apenas o essencial, e detalhes adicionais ficam em arquivos separados carregados sob demanda.\nEstrutura recomendada:\n.claude/skills/ sql-optimizer/ SKILL.md ← corpo principal, máximo 500 linhas patterns.md ← padrões de otimização detalhados anti-patterns.md ← erros comuns a evitar examples.md ← exemplos de antes e depois No SKILL.md, você referencia os arquivos adicionais:\n## Referências - Para padrões detalhados de otimização: ver `patterns.md` - Para anti-padrões comuns: ver `anti-patterns.md` - Para exemplos práticos: ver `examples.md` Claude carrega patterns.md apenas quando está trabalhando em um problema que exige aquele nível de detalhe. Os outros arquivos ficam no filesystem consumindo zero tokens de contexto até serem necessários.\nO impacto é significativo. Uma skill monolítica de 3.000 tokens carregada integralmente consome contexto mesmo quando apenas 20% do conteúdo é relevante para a tarefa. A mesma skill estruturada em arquivos carrega em média 400 tokens no SKILL.md e acessa os demais somente quando necessário.\nErros Mais Comuns e Como Evitar Mystique já falhou em missões. Geralmente quando subestimou o ambiente ou superestimou o que precisava levar consigo. Skills falham pelos mesmos motivos.\nErro 1: Descrição genérica demais\n# Ruim description: Ajuda com SQL e banco de dados. # Bom description: Otimiza queries SQL para Databricks Unity Catalog, focando em performance de joins, particionamento e análise de plano de execução. Use quando o usuário pedir otimização ou revisão de queries SQL. A descrição ruim vai acionar a skill em contextos errados ou não acionar quando deveria. A boa é específica sobre o ambiente, o foco e o gatilho.\nErro 2: Instruir Claude sobre o que ele já sabe\nQualquer instrução que você escreveria para um desenvolvedor sênior sem contexto do seu projeto é uma instrução que não pertence à skill. Pertence ao Claude por padrão.\nErro 3: SKILL.md acima de 500 linhas\nA documentação oficial da Anthropic estabelece 500 linhas como limite para performance ótima. Acima disso, divida em arquivos usando progressive disclosure.\nErro 4: Ferramentas não qualificadas em contexto MCP\n# Ruim Use a ferramenta bigquery_schema para recuperar schemas. # Bom Use a ferramenta BigQuery:bigquery_schema para recuperar schemas. Quando múltiplos servidores MCP estão disponíveis, Claude pode não localizar a ferramenta sem o prefixo do servidor. Sempre use o nome completamente qualificado.\nErro 5: Uma skill para tudo\nUma skill que tenta cobrir otimização SQL, criação de pipelines, documentação e revisão de código ao mesmo tempo é como Mystique tentando se transformar em cinco pessoas simultaneamente. Nenhuma das transformações vai ser convincente.\nCada skill deve ter um propósito único e bem definido.\nTestando e Iterando: Como Mystique Ensaiaria Mystique não vai a campo sem testar a transformação. Skills precisam do mesmo rigor.\nO processo recomendado tem dois atores: Claude A, que escreve e refina a skill, e Claude B, uma instância limpa que a executa sem conhecimento prévio do que estava na sua cabeça quando escreveu.\n## Protocolo de teste 1. Escreva a skill com Claude A 2. Abra uma nova sessão com Claude B, carregue apenas a skill 3. Execute 3 a 5 tarefas representativas do caso de uso real 4. Observe onde Claude B hesita, ignora instruções ou pede esclarecimentos 5. Cada hesitação é uma lacuna na skill. Volte ao Claude A e corrija. 6. Repita até Claude B executar sem ambiguidade Se Claude B faz uma pergunta que a skill deveria responder, a skill está incompleta. Se Claude B ignora parte das instruções, a skill está mal estruturada. Se Claude B executa perfeitamente em todos os casos de teste, a skill está pronta para produção.\nExemplo Completo: Skill de Code Review para Microsoft Fabric\n--- name: fabric-pipeline-review description: Revisa pipelines de dados no Microsoft Fabric para qualidade, performance e aderência aos padrões do projeto. Use quando o usuário pedir revisão, auditoria ou feedback sobre código de pipeline Microsoft Fabric. allowed-tools: - read - bash --- ## Contexto do projeto - Ambiente: Microsoft Fabric com Lakehouse habilitado - Linguagem: PySpark e SQL com type hints obrigatórios - Arquitetura: Medallion (Bronze → Silver → Gold) via Fabric Lakehouses - Namespace: `{workspace}.{lakehouse}.{camada}_{dominio}_{entidade}` ## Checklist de revisão obrigatória ### Performance - [ ] Ausência de `collect()` fora de contextos de debug - [ ] Joins com tabelas \u0026gt; 500GB usam broadcast hint ou salt - [ ] Particionamento alinhado com padrão de leitura da camada - [ ] Delta Lake V-Order habilitado nas tabelas Gold para otimização de leitura Power BI ### Qualidade - [ ] Schema explícito definido na ingestão Bronze - [ ] Regras de qualidade implementadas via Data Quality no Fabric ou Great Expectations - [ ] Tratamento de registros nulos documentado por coluna crítica ### Padrões do projeto - [ ] Nomenclatura de variáveis em snake_case - [ ] Funções com docstring no padrão Google Style - [ ] Sem credenciais hardcoded, usar Azure Key Vault via Fabric Linked Service ## Formato de saída Para cada item encontrado, retorne: - Severidade: [CRÍTICO | ALTO | MÉDIO | BAIXO] - Localização: linha ou função específica - Problema: descrição objetiva - Sugestão: correção recomendada com exemplo de código ## Referências adicionais - Padrões de nomenclatura detalhados: ver `naming-conventions.md` - Exemplos de anti-padrões comuns: ver `anti-patterns.md` Essa skill tem aproximadamente 280 tokens no corpo principal. Cobre o essencial do contexto do projeto, estrutura o processo e define o formato de saída sem explicar para Claude o que é PySpark ou como funciona o Databricks.\nConclusão: A Transformação Perfeita Não Deixa Rastro O que torna Mystique aterrorizante para seus inimigos não é a capacidade de se transformar. É que quando ela executa a transformação perfeita, ninguém percebe que aconteceu algo. A missão é cumprida sem fricção, sem ruído, sem desperdício.\nUma skill bem escrita tem a mesma propriedade. Claude a carrega, executa e entrega o resultado. Nenhum token desperdiçado em contexto que ele já tinha. Nenhuma ambiguidade que force uma pergunta de esclarecimento. Nenhum arquivo desnecessário consumindo janela de contexto.\nA diferença entre uma skill mediana e uma skill excelente não está na quantidade de instruções. Está na precisão de cada uma delas.\nEscreva como Mystique opera: com o mínimo necessário para a transformação perfeita.\nReferências Anthropic. Skill Authoring Best Practices. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices\nAnthropic. Claude Code Best Practices. https://code.claude.com/docs/en/best-practices\nAnthropic. Skills Overview. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview\n","permalink":"https://julianamarialop.github.io/articles/arte-da-transformacao-como-escrever-skills-claude-code/","summary":"Mystique não é a mutante mais forte. Não tem o adamantium de Wolverine, a telepatia de Xavier ou as rajadas de Ciclope. O que ela tem é algo mais raro: a capacidade de fazer o máximo com o mínimo.","title":"A Arte da Transformação: Como Escrever Skills no Claude Code com a Precisão da Mystique"},{"content":"A Origem Importa Mais do Que o Poder Você já tentou explicar para um executivo por que um modelo de IA não lembra da conversa anterior? A resposta não está na documentação técnica da Anthropic . Está no Programa Arma X.\nWolverine não nasceu com garras de adamantium. Ele nasceu com garras de osso, um poder selvagem e sem forma. O que transformou Logan no mutante quase indestrutível que conhecemos foi o Programa Arma X: um processo brutal de treinamento e modificação que revestiu cada osso do seu esqueleto com o metal mais resistente do planeta e, ao mesmo tempo, tentou apagar tudo o que ele era.\nO processo funcionou pela metade. O adamantium ficou. A identidade também.\nEssa distinção é fundamental para entender o Claude, o modelo de linguagem desenvolvido pela Anthropic. Porque em um mercado cheio de modelos de IA cada vez mais poderosos, a pergunta que realmente separa os concorrentes não é \u0026ldquo;qual é o maior?\u0026rdquo; ou \u0026ldquo;qual responde mais rápido?\u0026rdquo;. A pergunta é: como ele foi treinado e o que ficou depois do treinamento?\nA Anthropic desenvolveu uma abordagem chamada Constitutional AI. Em vez de treinar o modelo apenas para prever a próxima palavra mais provável, como fazem a maioria dos modelos tradicionais, o processo incluiu um conjunto explícito de princípios, uma espécie de constituição, que o modelo aprendeu a seguir durante o próprio treinamento. Não são filtros aplicados depois, como uma camisa de força colocada por cima. São valores incorporados durante a formação, como o adamantium que reveste cada osso de Logan.\nO resultado prático é um modelo que não apenas responde, mas raciocina sobre a resposta. Que questiona quando algo não está claro. Que recusa o que vai contra seus princípios não por limitação técnica, mas por caráter. Quando Lord Shingen derrotou Logan no duelo e o chamou de \u0026ldquo;apenas um animal\u0026rdquo;, estava tentando exatamente isso: reduzir o personagem à sua capacidade bruta, apagando o que o tornava mais do que uma arma. O arco inteiro da minissérie de 1982 é Logan provando que Shingen estava errado. Claude foi construído para nunca precisar provar isso.\nO Esqueleto de Adamantium: A Janela de Contexto Wolverine carrega o adamantium em cada missão. É o que torna suas garras indestrutíveis, o que faz com que ele absorva impactos que matariam qualquer outro mutante. Mas o adamantium tem um limite físico: ele reveste o que existe, não expande infinitamente.\nClaude tem uma estrutura equivalente chamada janela de contexto. É o espaço de trabalho ativo do modelo, tudo o que ele consegue processar em uma única conversa: suas perguntas, as respostas anteriores, documentos que você enviou, instruções do sistema. Tudo isso ocupa espaço dentro dessa janela.\nOs modelos atuais da família Claude 4.6 possuem janela de contexto de até 1 milhão de tokens, o equivalente a aproximadamente 750 mil palavras. Na prática, isso significa que você pode enviar contratos longos, bases de código completas ou históricos extensos de conversa, e o modelo processa tudo de forma integrada, sem perder o fio da meada.\nMas há um detalhe crítico que todo arquiteto de soluções precisa entender: a janela de contexto não persiste entre conversas. Quando uma sessão termina, o adamantium continua lá, os valores, a capacidade, o caráter. Mas o conteúdo daquela missão específica desaparece.\nWolverine acorda sem lembrar da última batalha. Claude começa cada nova conversa sem memória da anterior.\nSem Memória, Mas Não Sem Identidade\nEsse é o ponto que mais confunde quem começa a trabalhar com Claude. A ausência de memória persistente parece uma limitação grave. Na prática, é uma decisão de arquitetura com implicações profundas.\nEm primeiro lugar, ela garante privacidade por design. Nenhuma informação de uma conversa vaza para outra. Para empresas que lidam com dados sensíveis de clientes, isso não é detalhe, é requisito.\nEm segundo lugar, ela força clareza arquitetural. Se o modelo não lembra o contexto anterior, o sistema que o utiliza precisa ser responsável por gerenciar esse contexto. Assim como Wolverine depende dos X-Men para manter o registro das missões anteriores e coordenar a estratégia, Claude depende da arquitetura ao redor dele para funcionar com continuidade.\nE é exatamente aqui que a conversa sobre Claude deixa de ser sobre o modelo e começa a ser sobre sistemas.\nDe Mutante Solitário a Esquadrão: Claude em Arquiteturas Agênticas Existe uma versão do Wolverine que qualquer fã conhece: o lobo solitário. Durante anos ele operou em Madripoor como Patch, sem identidade oficial, sem esquadrão, contando apenas com suas garras e seu instinto. Devastador em combate individual, capaz de enfrentar dezenas de inimigos sozinho. Mas qualquer leitor assíduo dos quadrinhos sabe que a versão mais estratégica de Logan não é essa.\nÉ quando ele opera dentro dos X-Men.\nCom Professor Xavier coordenando a missão, Tempestade controlando o ambiente, Ciclope cobrindo a retirada e Wolverine na linha de frente, o que cada um entrega individualmente se multiplica. A força de Logan não diminui, ela encontra contexto, coordenação e alcance que sozinho ele jamais teria.\nClaude tem a mesma dinâmica quando integrado a um sistema agêntico.\nUsado isoladamente via interface ou API simples, Claude é uma ferramenta poderosa de raciocínio, geração e análise. Mas quando posicionado como o núcleo de raciocínio de um agente, conectado a ferramentas externas via Model Context Protocol (MCP) e operando dentro de uma arquitetura multi-agente, ele deixa de ser uma ferramenta e passa a ser uma camada de inteligência.\nO MCP, criado e aberto pela Anthropic, é o protocolo que permite ao Claude interagir com sistemas externos de forma padronizada: bancos de dados, APIs, sistemas de arquivos, ferramentas corporativas. Em vez de construir integrações customizadas e frágeis para cada sistema, o MCP define uma linguagem comum que qualquer ferramenta pode falar. Claude chega a um servidor MCP e sabe exatamente como consultar dados, executar ações e receber resultados, independente do sistema por trás.\nEm uma arquitetura multi-agente, Claude pode assumir diferentes papéis. Como agente orquestrador, ele recebe um objetivo complexo, decompõe em etapas, delega para agentes especializados e consolida os resultados. Como subagente, ele executa tarefas específicas dentro de um fluxo maior coordenado por outro modelo. A escolha do papel depende da complexidade da missão e do design do sistema.\nÉ a diferença entre Logan operando sozinho em Madripoor e Logan dentro dos X-Men. O mutante é o mesmo. O resultado é completamente diferente.\nComo Colocar o Logan para Trabalhar: Planos e Licenças Antes de montar o esquadrão, é preciso entender como contratar o mutante.\nO Claude está disponível em três formas principais: como aplicativo de chat no claude.ai, via API para desenvolvedores, e como plataforma enterprise para implantação corporativa. Cada caminho serve um perfil diferente.\nPara uso individual, o plano Pro custa $20 por mês, com opção anual saindo a aproximadamente $17 mensais. Para usuários de altíssimo volume, o plano Max vai de $100 a $200 por mês, incluindo limites muito maiores de uso e o recurso Extended Thinking para raciocínio em tarefas complexas.\nPara times, o plano Team começa em $20 por assento por mês no modelo Standard, com mínimo de 5 membros. O assento Premium, a $100 por mês, inclui Claude Code para os desenvolvedores. É possível misturar os dois tipos dentro do mesmo plano, o que permite otimizar custos por perfil de usuário.\nPara enterprise, o modelo é diferente dos planos de assinatura: há uma taxa por assento cobrada anualmente, e o consumo de tokens é medido separadamente à taxa padrão da API. Isso dá controle granular por usuário e desbloqueia janela de contexto de 500K tokens, conformidade com HIPAA, SSO e logs de auditoria.\nPara quem está construindo soluções, a API é cobrada por tokens consumidos. Os modelos recomendados em 2026 são Haiku 4.5 ($1/$5 por milhão de tokens de entrada/saída), Sonnet 4.6 ($3/$15) e Opus 4.6 ($5/$25). Combinando Batch API e prompt caching, é possível reduzir o custo efetivo em até 95% em cargas de trabalho elegíveis.\nA escolha do plano segue a mesma lógica da missão: você não convoca o esquadrão completo para uma patrulha de rotina.\nO Que Muda Para Quem Arquiteta Soluções Para líderes e arquitetos que estão avaliando Claude como componente de uma solução enterprise, algumas implicações práticas:\nGerenciamento de contexto é responsabilidade do sistema, não do modelo. Como Claude não tem memória persistente, a arquitetura precisa decidir o que injetar na janela de contexto a cada chamada: histórico relevante, dados do usuário, estado da tarefa. Isso exige design deliberado, não improvisação.\nO poder do modelo está no raciocínio, não na memorização. Claude não é um banco de dados. Ele é um motor de raciocínio. A arquitetura certa separa claramente o que vai para um banco vetorial ou relacional e o que precisa ser processado pelo modelo.\nMCP padroniza o que antes era artesanal. Cada integração customizada que você construiu para conectar uma IA a um sistema interno é um candidato a ser substituído por um servidor MCP. Mais robusto, mais reutilizável e compatível com qualquer modelo que fale o protocolo.\nMulti-agente não é complexidade por complexidade. É a resposta certa quando a tarefa é grande demais para uma única janela de contexto, quando diferentes etapas exigem especializações distintas ou quando a paralelização reduz tempo de execução de forma significativa.\nLogan não chama os X-Men para uma briga de bar. Chama quando a missão exige mais do que um mutante consegue entregar sozinho.\nConclusão: A Origem Define o Limite O que faz do Wolverine um personagem único não é o adamantium. É o fato de que, depois de tudo que o Programa Arma X fez com ele, depois de apagar memórias e tentar reescrever quem ele era, o que sobrou foi exatamente o que não podia ser removido: o caráter.\nClaude foi construído com a mesma lógica. Em um mercado onde os modelos competem em tamanho e velocidade, a Anthropic apostou em algo diferente: treinar um modelo que raciocina com profundidade, que tem princípios incorporados no processo de formação e que, quando colocado dentro de uma arquitetura bem projetada, multiplica o valor de cada sistema ao redor dele.\nA questão não é mais se Claude é poderoso o suficiente para a sua missão. A questão é se a arquitetura ao redor dele está à altura do que ele pode entregar.\nReferências Anthropic. Constitutional AI: Harmlessness from AI Feedback. https://www.anthropic.com/research/constitutional-ai-harmlessness-from-ai-feedback\nAnthropic. Model Context Protocol. https://modelcontextprotocol.io\nAnthropic. Plans \u0026amp; Pricing. https://claude.com/pricing\nAnthropic. Claude API Pricing. https://platform.claude.com/docs/en/about-claude/pricing\n","permalink":"https://julianamarialop.github.io/articles/wolverine-e-claude-dois-guerreiros-sem-memoria-que-ninguem/","summary":"Você já tentou explicar para um executivo por que um modelo de IA não lembra da conversa anterior? A resposta não está na documentação técnica da Anthropic . Está no Programa Arma X.","title":"Wolverine e Claude: Dois Guerreiros Sem Memória Que Ninguém Quer Enfrentar"},{"content":"A Chegada à Mansão Xavier: Entendendo o Idioma da Engenharia Se você não escreve código e já participou de reuniões de status de projeto com times de engenharia, provavelmente já se sentiu em outro país. Termos como \u0026ldquo;dar um push\u0026rdquo;, \u0026ldquo;fazer um pull request\u0026rdquo;, \u0026ldquo;criar uma branch\u0026rdquo; ou \u0026ldquo;resolver um conflito de merge\u0026rdquo; são jogados no ar como se fossem palavras do dia a dia. Para quem não vive no terminal, essa sopa de letrinhas pode criar uma barreira de comunicação frustrante, fazendo com que o andamento do projeto pareça uma caixa preta inescrutável.\nA boa notícia é que a lógica por trás de tudo isso é incrivelmente estruturada e fácil de entender. A forma como os mutantes treinam suas habilidades sem destruir a mansão e como o Professor Xavier coordena a equipe é exatamente a mesma lógica que os desenvolvedores usam para construir e proteger os aplicativos que usamos todos os dias. A ferramenta que gerencia esse treinamento e coordenação chama-se Git.\nE o cenário ficou ainda mais interessante recentemente. Com a adoção em massa do GitHub Copilot, os desenvolvedores ganharam um ajudante movido a Inteligência Artificial que muda completamente as regras do jogo. É como se cada programador tivesse o Cérebro, o supercomputador do Professor Xavier, conectado diretamente à sua mente para ajudar a escrever código mais rápido. Entender como o Git e o Copilot funcionam juntos é fundamental para qualquer líder que queira compreender como a engenharia moderna opera na prática.\nA Base de Operações: Por Que Precisamos de um Sistema de Defesa? O Git é, na sua essência, um sistema de controle de versão. Pense nele como o sistema de segurança da Mansão Xavier. O objetivo principal do Git é proteger a Base Oficial de Operações do seu projeto, ou seja, o código oficial, testado e aprovado, que está rodando no servidor e que os clientes estão usando neste exato momento.\nSem o Git, se dois desenvolvedores tentassem editar o mesmo arquivo ao mesmo tempo, um apagaria o trabalho do outro. Pior ainda, se alguém cometesse um erro crítico, o aplicativo inteiro poderia sair do ar sem uma forma fácil de reverter a mudança. O Git existe para garantir que dezenas, centenas ou milhares de desenvolvedores possam colaborar no mesmo projeto com segurança total.\nMas o que acontece quando um desenvolvedor precisa adicionar uma nova funcionalidade? Ele não pode simplesmente testar isso no código oficial e correr o risco de quebrar o aplicativo para todo mundo. É para resolver isso que o Git utiliza um fluxo de trabalho específico, um ciclo contínuo de colaboração e proteção.\nO Treinamento na Sala de Perigo: O Ciclo do Código Para entender como a engenharia trabalha no dia a dia, precisamos olhar para o ciclo completo de uma alteração de código. É uma coreografia de treinamento que se repete centenas de vezes por semana:\nBranch (A Simulação Isolada): Tudo começa criando uma \u0026ldquo;branch\u0026rdquo; (ramificação) a partir do código oficial. Isso é literalmente entrar na Sala de Perigo: uma simulação isolada onde o desenvolvedor pode testar, errar e experimentar uma nova funcionalidade sem afetar a base oficial. Se a experiência der errado, basta desligar a simulação. Pull (A Atualização do Manual): Antes de avançar no treinamento, o mutante precisa garantir que conhece as táticas mais recentes que a equipe acabou de descobrir. O \u0026ldquo;pull\u0026rdquo; (puxar) é o ato de trazer para dentro da sua simulação (branch) as atualizações que os outros desenvolvedores já aprovaram no código oficial. É como sincronizar seu manual de campo para evitar conflitos no futuro. Commit (O Ponto de Salvamento): A cada avanço significativo no seu treinamento dentro da Sala de Perigo, o desenvolvedor faz um \u0026ldquo;commit\u0026rdquo;. É como um save game da simulação. Ele adiciona uma pequena mensagem explicando o que fez. Se algo quebrar mais para frente, ele pode reiniciar a sala exatamente a partir desse ponto seguro. Push (O Relatório de Missão): Quando o desenvolvedor termina o treinamento na sua simulação local, ele precisa enviar os resultados para o servidor central da equipe (geralmente o GitHub). Esse ato de enviar os dados locais para a base central é o \u0026ldquo;push\u0026rdquo; (empurrar). Pull Request (A Avaliação do Professor X): Antes de aplicar a nova técnica nas missões oficiais, o desenvolvedor abre um \u0026ldquo;Pull Request\u0026rdquo; (PR). É um pedido formal para que os líderes da equipe revisem o treinamento. É como se apresentar diante do Professor Xavier para provar que você domina a habilidade e não vai colocar a equipe em risco. Merge (A Formatura Oficial): Quando o Professor Xavier aprova o PR, acontece o \u0026ldquo;merge\u0026rdquo; (mesclar). A técnica testada na Sala de Perigo é oficialmente integrada ao manual de táticas da equipe. A nova funcionalidade agora faz parte do aplicativo oficial. O Protocolo de Emergência: Quando a Missão Falha Mesmo com todos esses processos de segurança na Sala de Perigo, às vezes um erro passa despercebido e uma técnica falha é integrada às missões oficiais. Quando isso acontece e o sistema apresenta problemas, o Git mostra seu verdadeiro poder de salvamento.\nComo o Git mantém um histórico imutável de todos os \u0026ldquo;commits\u0026rdquo; (pontos de salvamento) já feitos no projeto, a equipe de engenharia não precisa entrar em pânico ou reescrever o código do zero. Eles simplesmente usam um comando chamado \u0026ldquo;revert\u0026rdquo;. Esse comando instrui o Git a voltar no tempo e desfazer exatamente as alterações daquele código defeituoso, restaurando o aplicativo para a última versão estável em questão de segundos. É um protocolo de emergência absoluto que permite que as empresas inovem rápido sem o medo de destruir o que já funciona.\nA Conexão com o Cérebro: O GitHub Copilot em Ação Se o Git é o sistema rigoroso que gerencia o treinamento e protege a mansão, o GitHub Copilot é a ferramenta que acelera o aprendizado e a execução das missões . Desenvolvido pela Microsoft em parceria com a OpenAI, o Copilot é uma Inteligência Artificial generativa que atua diretamente dentro da tela onde o desenvolvedor trabalha.\nNa prática, o Copilot não substitui o desenvolvedor (o mutante no campo de batalha), mas atua como a conexão telepática constante com o supercomputador Cérebro. Ele não apenas fornece informações, mas antecipa necessidades. Enquanto o desenvolvedor pensa na estratégia e no problema de negócio que precisa ser resolvido, o Copilot cuida da execução tática com uma precisão impressionante:\nAutocompletar Inteligente: O desenvolvedor começa a digitar a lógica de uma função e o Copilot sugere o resto do código em tempo real, baseando-se no contexto de todo o projeto e nas táticas já conhecidas pela equipe. É como o Cérebro prevendo o próximo movimento do inimigo. Tradução de Intenção para Código: O desenvolvedor pode escrever um comentário simples, como \u0026ldquo;crie uma função para identificar clientes inativos\u0026rdquo;, e o Copilot escreve o código correspondente instantaneamente. A intenção mental se transforma em ação no código. Explicação de Código Legado: Se um desenvolvedor entrar em um projeto antigo e não entender uma parte complexa do código, ele pode pedir ao Copilot para ler e explicar aquela lógica em linguagem simples, acelerando o entendimento e evitando horas de investigação manual. A Formatura: O Impacto Real para a Equipe A combinação do Git, garantindo que os testes ocorram apenas na Sala de Perigo, com o GitHub Copilot, injetando o conhecimento do Cérebro na mente de cada desenvolvedor, está reescrevendo as métricas de eficiência no desenvolvimento de software. Estudos recentes indicam que desenvolvedores usando Copilot concluem tarefas até 55% mais rápido .\nPara quem não vive no terminal, isso não significa apenas entregar funcionalidades mais rápido. Significa que a equipe de engenharia gasta menos tempo digitando códigos repetitivos ou caçando bugs que destruíram a mansão, e mais tempo focada em resolver os problemas reais dos clientes e inovar no produto.\nEntender esses conceitos permite conversas muito mais ricas, empáticas e estratégicas com seus times de tecnologia. Quando você sabe que uma \u0026ldquo;branch\u0026rdquo; protege o produto em produção, que um \u0026ldquo;pull request\u0026rdquo; garante a qualidade, e que existe um botão de pânico para reverter erros, a caixa preta da engenharia se abre. No fim das contas, o objetivo é sempre o mesmo: treinar com segurança na mansão e colaborar para entregar o melhor resultado no mundo real.\nReferências What is GitHub Copilot? - Documentação Oficial do GitHub: https://docs.github.com/en/copilot/get-started/what-is-github-copilot\nGitHub Copilot Boosts Developer Productivity by 55%: https://www.linkedin.com/posts/aagarwal29_aicodegeneration-githubcopilot-developerproductivity-activity-7419786092624859138-IGe-\n","permalink":"https://julianamarialop.github.io/articles/mutantes-do-codigo-entendendo-git-e-github-copilot-com/","summary":"Se você não escreve código e já participou de reuniões de status de projeto com times de engenharia, provavelmente já se sentiu em outro país. Termos como \u0026ldquo;dar um push\u0026rdquo;, \u0026ldquo;fazer um pull request\u0026rdquo;, \u0026ldquo;criar uma branch\u0026rdquo; ou…","title":"Mutantes do Código: Entendendo Git e GitHub Copilot com os X-Men"},{"content":"Introdução: A Lenda do Tuco, nosso Super-Estagiário de IA Imagine que sua empresa contratou um super-estagiário. Seu nome de batismo era \u0026ldquo;Agente de IA para Tarefas Utilitárias Corporativas e Operacionais\u0026rdquo;, mas a equipe, achando o nome um pouco\u0026hellip; robótico, decidiu apelidá-lo carinhosamente de Tuco. A lenda diz que o apelido pegou no dia em que ele, tentando ser proativo, quase formatou o notebook do CEO ao entender errado um pedido para \u0026ldquo;limpar os arquivos\u0026rdquo;. Foi um susto, mas serviu para mostrar que, apesar de genial, o Tuco precisava de limites claros.\nEle é uma Inteligência Artificial incrivelmente inteligente, capaz de entender seus pedidos, planejar tarefas e ajudar em praticamente qualquer coisa. Você, como chefe, pede algo que parece simples: \u0026ldquo;Tuco, por favor, processe o reembolso do último pedido da cliente Joana e envie um email de confirmação para ela\u0026rdquo;.\nTuco, muito prestativo, coça sua cabeça de silício e responde: \u0026ldquo;Chefe, claro! Mas\u0026hellip; como eu faço isso? Onde eu consulto os pedidos? Qual é o procedimento para reembolso? E como eu acesso o sistema de emails? Não tenho a senha de nada!\u0026rdquo;.\nEsse é o dilema que as IAs enfrentaram por muito tempo. Elas eram como um estagiário genial trancado em uma sala, cheio de potencial, mas sem acesso às ferramentas e informações da empresa. Cada vez que um desenvolvedor queria que a IA fizesse algo novo, precisava construir uma \u0026ldquo;ponte\u0026rdquo; de código customizada e frágil para cada sistema. Se o sistema de emails mudasse, a ponte quebrava. Se o sistema de pedidos fosse atualizado, lá se ia outra ponte. Era um pesadelo de manutenção.\nÉ para resolver esse problema que nasceu o Model Context Protocol (MCP) criado e aberto para a comunidade (open-source) pela Anthropic. De forma simples, o MCP é como um crachá de acesso universal para o nosso estagiário Tuco. Em vez de construir dezenas de pontes, nós damos a ele um único crachá que todos os departamentos da empresa entendem. Com esse crachá, Tuco pode ir até o departamento de Vendas, de Finanças ou de Comunicação e saber exatamente como interagir com cada um de forma padronizada e segura.\nO Cinto de Utilidades do Tuco: Tools, Resources e Prompts O crachá MCP não é mágico; ele funciona porque define uma linguagem comum. Quando Tuco chega a um departamento (um \u0026ldquo;servidor MCP\u0026rdquo;), ele sabe que pode encontrar três tipos de coisas em seu \u0026ldquo;cinto de utilidades\u0026rdquo;:\nTools (Ferramentas): São as ações que Tuco pode executar. Pense nelas como os equipamentos especializados de cada departamento. O departamento de Finanças tem uma \u0026ldquo;Calculadora de Reembolso\u0026rdquo; (uma ferramenta processar_reembolso). O de Comunicação tem um \u0026ldquo;Disparador de Emails\u0026rdquo; (uma ferramenta enviar_email). Tuco não precisa saber os detalhes de como a calculadora funciona, apenas que pode usá-la para processar um reembolso. Resources (Recursos): São as informações que Tuco pode consultar. São como os arquivos e documentos de cada área. O departamento de Vendas tem um arquivo de \u0026ldquo;Pedidos dos Clientes\u0026rdquo; (um recurso pedidos_cliente). O de Marketing tem um \u0026ldquo;Catálogo de Produtos\u0026rdquo;. Tuco pode usar seu crachá para ler esses arquivos e obter o contexto de que precisa para realizar suas tarefas. Prompts (Modelos de Preenchimento): São como os formulários padrão da empresa. Para pedir algo, Tuco precisa preencher o formulário correto. Um prompt é um modelo que diz a Tuco exatamente como ele deve formatar seus pedidos para que o LLM (o cérebro da IA) entenda e processe a informação da maneira certa. É um guia de como \u0026ldquo;conversar\u0026rdquo; com o cérebro. Com esse cinto de utilidades, a tarefa de Tuco se torna muito mais fácil. Para o reembolso da Joana, ele usa seu crachá para:\nIr ao departamento de Vendas e usar o Recurso \u0026ldquo;Pedidos dos Clientes\u0026rdquo; para encontrar o último pedido da Joana. Ir ao departamento de Finanças e usar a Ferramenta \u0026ldquo;Calculadora de Reembolso\u0026rdquo; para processar o valor. Ir ao departamento de Comunicação e usar a Ferramenta \u0026ldquo;Disparador de Emails\u0026rdquo; para enviar a confirmação. Tudo isso de forma padronizada, segura e sem a necessidade de pontes de código frágeis. Se o sistema de emails mudar, o departamento de Comunicação atualiza sua ferramenta, mas o crachá de Tuco continua funcionando da mesma forma.\nA Central de Crachás: Como Ferramentas como o Copilot Studio Resolvem o MCP Criar um crachá universal e um cinto de utilidades para o Tuco parece ótimo, mas quem gerencia tudo isso? É aqui que entram as plataformas de desenvolvimento de IA, como o Microsoft Copilot Studio .\nPense no Copilot Studio como a Central de Crachás da empresa. Em vez de cada desenvolvedor ter que criar manualmente cada crachá (servidor MCP) e cada conexão, essas plataformas fazem o trabalho pesado. Elas oferecem uma interface visual e simplificada onde os desenvolvedores podem:\nConectar-se a Fontes de Dados com um Clique: A plataforma já tem conectores pré-construídos para centenas de sistemas (como SAP, Salesforce, ou um banco de dados qualquer). Ao conectar uma fonte, a plataforma automaticamente cria um \u0026ldquo;servidor MCP\u0026rdquo; para ela, expondo as ferramentas e recursos disponíveis. Gerenciar Permissões de Forma Centralizada: A Central de Crachás permite que os administradores definam exatamente o que o Tuco pode ou não fazer. Ele pode usar a ferramenta de consultar_pedidos, mas não a de deletar_clientes, por exemplo. Isso garante a segurança e a governança em toda a empresa. Atualizar Tudo Automaticamente: Quando o departamento de Vendas adiciona uma nova ferramenta ao seu sistema, a Central de Crachás detecta a mudança e atualiza automaticamente o cinto de utilidades do Tuco. Ele sempre terá acesso às versões mais recentes das ferramentas, sem que ninguém precise intervir manualmente. Outras ferramentas, como Langflow e n8n , também estão adotando o MCP, permitindo que os desenvolvedores criem e orquestrem esses fluxos de trabalho de IA de forma visual e padronizada. Elas funcionam como centrais de crachás alternativas, cada uma com suas especialidades, mas todas falando a mesma língua do MCP.\nConclusão: Dando Superpoderes (e um Crachá) ao Estagiário O Model Context Protocol (MCP) é mais do que apenas um padrão técnico; é uma mudança fundamental na forma como construímos e gerenciamos aplicações de IA. Ele transforma nossos agentes de IA, como o Tuco, de estagiários geniais, porém isolados, em membros produtivos e integrados da equipe.\nAo fornecer um \u0026ldquo;crachá universal\u0026rdquo;, o MCP elimina a complexidade das integrações customizadas, permitindo que as IAs acessem ferramentas e dados de forma segura e escalável. E com plataformas como o Copilot Studio atuando como a \u0026ldquo;Central de Crachás\u0026rdquo;, o processo de equipar nossos agentes com os superpoderes de que precisam se torna acessível a todos os desenvolvedores, não apenas a especialistas em IA.\nO futuro da IA não será construído apenas com cérebros mais potentes, mas com ecossistemas mais organizados. E nessa organização, o crachá universal do MCP é a peça-chave que permitirá que nossos \u0026ldquo;Tucos\u0026rdquo; trabalhem com autonomia, segurança e, acima de tudo, uma eficiência que antes era impossível.\nReferências Model Context Protocol - Documentação Oficial\nIntroducing Model Context Protocol (MCP) in Copilot Studio - Microsoft Copilot Blog\nIntroducing MCP Integration in Langflow - Langflow Blog\nMCP Client Tool node documentation - n8n Docs\n","permalink":"https://julianamarialop.github.io/articles/o-cracha-universal-da-ia-entendendo-mcp-com-agente-tuco/","summary":"Imagine que sua empresa contratou um super-estagiário. Seu nome de batismo era \u0026ldquo;Agente de IA para Tarefas Utilitárias Corporativas e Operacionais\u0026rdquo;, mas a equipe, achando o nome um pouco\u0026hellip; robótico, decidiu apelidá-lo…","title":"O Crachá Universal da IA: Entendendo o MCP com o Agente Tuco"},{"content":"O Databricks Lakebase representa uma evolução significativa na arquitetura de dados, especificamente no domínio dos bancos de dados OLTP (Online Transactional Processing). Não se trata apenas de mais um banco de dados na nuvem, mas de uma redefinição fundamental de como os dados transacionais são armazenados, processados e integrados com ecossistemas analíticos e de inteligência artificial. Esta nova arquitetura visa eliminar o abismo histórico entre as necessidades operacionais de baixa latência e as demandas de escala e flexibilidade dos data lakes.\nTradicionalmente, bancos de dados OLTP e sistemas analíticos operam em silos distintos, exigindo pipelines ETL complexos e frágeis para mover dados entre eles. O Lakebase propõe uma solução unificada, combinando a robustez de um banco de dados relacional com a escalabilidade e a economia do armazenamento em nuvem. Seu design é intrinsecamente otimizado para a era dos agentes de IA, oferecendo capacidades que os sistemas legados não conseguem prover.\nPara compreender o impacto do Lakebase, é essencial analisar seus pilares técnicos e como eles resolvem desafios de longa data na engenharia de dados. A inovação reside na forma como ele gerencia latência, isolamento de dados e integração, tudo isso enquanto suporta cargas de trabalho operacionais intensivas e as demandas emergentes da inteligência artificial.\nEngenharia de Baixa Latência em Object Storage Um dos maiores desafios ao desacoplar armazenamento e computação em bancos de dados OLTP, utilizando object storage (como S3 ou ADLS), é a latência. O Lakebase aborda isso com uma arquitetura sofisticada que emprega camadas de estado (soft-state) e mecanismos de cache inteligente. Embora os dados frios residam no armazenamento de objetos de baixo custo, as páginas ativas do Postgres são mantidas em camadas intermediárias de alta performance. Essa abordagem permite que o Lakebase entregue latência de milissegundos de um dígito e suporte milhões de transações por segundo, uma performance antes considerada inatingível para arquiteturas baseadas puramente em data lakes. É a combinação da eficiência do armazenamento em nuvem com a performance necessária para aplicações transacionais críticas.\nRamificação Instantânea: O \u0026ldquo;Git Checkout\u0026rdquo; para Dados Operacionais O mecanismo de ramificação (branching) do Lakebase, baseado em copy-on-write, é uma funcionalidade transformadora. Ele permite a criação de réplicas exatas de um banco de dados de produção, incluindo esquema e dados, de forma instantânea e com custo marginal. Isso é viável porque o Lakebase isola os metadados. Ao criar um novo branch, ele inicialmente aponta para os mesmos arquivos de dados originais. As alterações são gravadas apenas em novos blocos, garantindo isolamento total para:\nTestes de alta fidelidade: Desenvolvedores podem testar novas funcionalidades em um ambiente idêntico ao de produção sem riscos. Migrações de esquema complexas: Alterações no esquema podem ser testadas e validadas em um ambiente isolado antes de serem aplicadas à produção. Experimentação de agentes de IA: Agentes podem operar em suas próprias instâncias isoladas para experimentação e validação, sem afetar a produção ou outros agentes. Essa capacidade elimina a necessidade de ambientes de staging caros e demorados, acelerando o ciclo de desenvolvimento e garantindo a integridade dos dados de produção.\nOtimização para Agentes de IA: Por que o Lakebase é Essencial A verdadeira força motriz por trás do design do Lakebase é o suporte robusto a agentes de IA autônomos. Não é apenas o branching que o torna ideal, mas uma combinação de características que atendem às demandas intrínsecas da inteligência artificial operacional:\nEstado Persistente de Baixa Latência: Agentes de IA, especialmente em cenários de tempo real como recomendação de produtos ou detecção de fraudes, precisam de acesso a dados operacionais com latência de milissegundos. O Lakebase oferece isso ao manter as páginas ativas do Postgres em camadas de alta performance, mesmo com o armazenamento subjacente em object storage. Isso significa que os agentes podem tomar decisões rápidas baseadas nos dados mais recentes, sem gargalos de performance que limitariam sistemas tradicionais. Escalabilidade Elástica (Serverless): Agentes de IA podem ter picos de demanda imprevisíveis. Um banco de dados tradicional exigiria provisionamento excessivo para lidar com esses picos, resultando em custos elevados. O Lakebase, com sua arquitetura serverless, escala elasticamente até zero quando não está em uso e expande-se instantaneamente para atender a milhões de transações por segundo. Isso otimiza custos e garante que os agentes sempre tenham os recursos necessários, sem intervenção manual. Unificação Nativa com o Unity Catalog: A governança de dados é crucial para agentes de IA. O Lakebase se integra nativamente ao Unity Catalog, estendendo as mesmas permissões e políticas de segurança do Lakehouse para os dados operacionais. Isso simplifica a gestão de acesso e garante que os agentes operem dentro dos limites de conformidade, além de permitir que os dados operacionais sejam imediatamente visíveis para o treinamento e monitoramento de modelos de IA no Lakehouse, sem a necessidade de pipelines ETL complexos. Esses pilares, combinados com o branching para experimentação segura, tornam o Lakebase a infraestrutura de estado ideal para a segurança, a confiabilidade e a agilidade da inteligência artificial autônoma. Ele fornece a base para que agentes de IA possam experimentar, aprender e operar em produção com confiança.\nUnificação Real: O Fim do Abismo entre OLTP e OLAP Historicamente, a movimentação de dados de bancos de dados operacionais para sistemas analíticos (Lakehouse) era um processo árduo, envolvendo pipelines ETL frágeis, gerenciamento manual de esquemas e latência significativa. O Lakebase, com sua integração nativa ao Unity Catalog, elimina essa complexidade.\nOs dados operacionais são sincronizados quase em tempo real com a camada analítica, sem a necessidade de infraestrutura duplicada ou custos de saída de dados. A governança é unificada: as mesmas permissões e políticas de segurança definidas no Unity Catalog para o Lakehouse são estendidas ao Lakebase. Isso resulta em uma plataforma de dados verdadeiramente unificada, onde os dados operacionais estão imediatamente disponíveis para análise e treinamento de modelos de IA, sem atrito.\nArquitetura de Referência: Integrando Lakebase com Ecossistemas Existentes Para entender como o Lakebase se encaixa em uma arquitetura de dados moderna, é crucial visualizar sua integração com sistemas legados e o Lakehouse. A abordagem não é de um ETL tradicional, mas sim de uma integração Zero-ETL ou acesso federado, que minimiza a movimentação de dados e a complexidade.\nImagine o seguinte cenário:\nSistemas OLTP Legados (Fontes de Dados): Sua organização possui bancos de dados transacionais existentes (PostgreSQL, MySQL, SQL Server, Oracle, etc.) que contêm dados operacionais críticos. Esses sistemas continuam a ser a fonte primária de verdade para suas aplicações legadas. Lakehouse (Camada Analítica Unificada): O Databricks Lakehouse, construído sobre Delta Lake e Unity Catalog, atua como sua plataforma unificada para dados analíticos, data warehousing, BI e Machine Learning. Ele ingere dados de diversas fontes, incluindo os sistemas OLTP legados, através de mecanismos como o Lakehouse Federation ou streaming de dados (ex: Kafka, Change Data Capture - CDC) para o Delta Live Tables. Lakebase (Camada de Serviço Operacional para Agentes de IA): Aqui é onde o Lakebase entra. Ele serve como a camada de dados operacional de alta performance e baixa latência especificamente otimizada para agentes de IA. O Lakebase pode ser alimentado de duas formas principais: Novos Dados Operacionais: Para novas aplicações ou microsserviços que exigem as capacidades únicas do Lakebase (baixa latência em object storage, branching, escalabilidade serverless), os dados podem ser escritos diretamente no Lakebase e Dados Sincronizados do Lakehouse: Para dados que se originam em sistemas legados e são ingeridos no Lakehouse, o Lakebase pode consumir esses dados de forma otimizada. Graças à integração nativa com o Unity Catalog, as tabelas do Lakehouse podem ser facilmente acessadas e, se necessário, materializadas ou referenciadas no Lakebase para que os agentes de IA tenham acesso operacional de baixa latência. Isso cria um fluxo de dados bidirecional ou de consumo, onde o Lakebase atua como um cache operacional inteligente ou um datastore primário para as operações dos agentes. O Papel do Lakebase para Agentes de IA:\nNesta arquitetura, o Lakebase não substitui o Lakehouse, mas o complementa, fornecendo a velocidade e a agilidade transacional que os agentes de IA exigem. Ele é a \u0026ldquo;memória de curto prazo\u0026rdquo; e o \u0026ldquo;ambiente de trabalho\u0026rdquo; dos agentes, onde eles podem:\nLer dados operacionais em tempo real: Para tomar decisões instantâneas (ex: recomendação, detecção de fraude). Escrever e atualizar dados: Para executar ações (ex: ajustar estoque, processar um pedido). Experimentar com segurança: Utilizar o branching para testar novas lógicas ou modelos de agentes sem impactar a produção. Essa arquitetura permite que a organização mantenha seus sistemas legados funcionando, enquanto moderniza sua camada de dados para suportar a próxima geração de aplicações e agentes de IA, tudo isso dentro de uma estrutura unificada e governada pelo Unity Catalog.\nEstratégia de Modelagem e Retenção de Dados no Lakebase A modelagem de dados e a estratégia de retenção são aspectos cruciais para otimizar o Lakebase para agentes de IA e garantir sua eficiência no ecossistema Lakehouse. A abordagem aqui difere dos bancos de dados analíticos tradicionais.\n1. Modelagem de Dados: Relacional Puro para Operações de Agentes Sim, a indicação é um modelo relacional puro, similar ao PostgreSQL, para as tabelas dentro do Lakebase. Isso se deve a:\nFamiliaridade e Maturidade: O modelo relacional é amplamente compreendido e otimizado para operações transacionais (OLTP), que são o foco dos agentes de IA que precisam ler e escrever dados rapidamente. Integridade Referencial: A capacidade de impor chaves primárias e estrangeiras garante a consistência dos dados, essencial para a confiabilidade das decisões dos agentes. Consultas Pontuais Otimizadas: Agentes frequentemente realizam consultas pontuais ou transações específicas (ex: \u0026ldquo;qual o estoque do produto X?\u0026rdquo;, \u0026ldquo;atualizar status do pedido Y?\u0026rdquo;). O modelo relacional é altamente eficiente para esses tipos de operações. É importante ressaltar que, enquanto o Lakebase mantém o modelo relacional para a camada operacional, o Lakehouse (Delta Lake) continua sendo o local ideal para modelos de dados dimensionais (Star Schema, Snowflake Schema) otimizados para análises complexas e BI.\n2. Matriz de Decisão de Ingestão: O que vai para o Lakebase? A decisão sobre quais dados devem ser materializados no Lakebase não é arbitrária, mas sim guiada pela criticidade operacional para os agentes de IA. Não se trata de uma cópia indiscriminada de todos os dados legados, mas de uma seleção estratégica baseada em três critérios principais:\nFrequência de Escrita e Atualização (Volatilidade):\nPergunta: O agente de IA precisa atualizar este dado em milissegundos ou segundos? A informação muda tão rapidamente que uma replicação assíncrona ou um cache de maior latência no Lakehouse seria insuficiente para a consistência operacional? Exemplo: O estoque de produtos em um e-commerce é um dado altamente volátil e crítico. Um agente de recomendação ou de gestão de pedidos precisa saber o estoque exato agora para evitar vender um produto indisponível. Dados como o endereço de entrega do cliente, embora importantes, não exigem a mesma frequência de atualização por um agente e podem ser acessados com maior latência do Lakehouse. Dependência de Estado para Decisão Imediata:\nPergunta: O agente de IA precisa desse dado para tomar uma decisão imediata e crítica no seu fluxo de trabalho? A ausência ou desatualização dessa informação impediria o agente de completar sua tarefa ou levaria a uma decisão incorreta? Exemplo: Para um agente de detecção de fraude, o histórico recente de transações de um usuário é crucial para identificar padrões anômalos no momento da transação. Já o histórico completo de compras para análise de tendências pode residir no Lakehouse, pois não é necessário para a decisão imediata de aprovar ou negar uma transação. Volume e Granularidade de Acesso:\nPergunta: O agente acessa esse dado em alta granularidade (registros individuais) e em grande volume de requisições pontuais? Ou o acesso é mais para análises agregadas ou em lote? Exemplo: Um agente de personalização pode precisar acessar o perfil de preferência individual de um usuário (alta granularidade, muitas requisições pontuais). Dados de campanhas de marketing passadas (baixa granularidade, acesso em lote para análise) seriam mais adequados para o Lakehouse. Como o Unity Catalog Ajuda na Decisão:\nO Unity Catalog atua como o ponto central de governança. Ele permite que você defina e gerencie o acesso aos dados, independentemente de estarem no Lakebase ou no Lakehouse. Para dados que precisam ser materializados no Lakebase, você pode usar mecanismos de sincronização de dados (como CDC) que levam apenas as tabelas ou colunas críticas do Lakehouse para o Lakebase, mantendo a linhagem e a governança unificadas. Alternativamente, para novas aplicações, o Lakebase pode ser o destino primário para esses dados operacionais críticos.\nEm resumo, a decisão de \u0026ldquo;copiar\u0026rdquo; (ou materializar) dados para o Lakebase é um exercício de engenharia de dados focado em performance e criticidade operacional. Apenas os dados que são verdadeiramente o \u0026ldquo;estado ativo\u0026rdquo; e que exigem a latência de milissegundos para as operações dos agentes devem residir no Lakebase, enquanto o vasto histórico e os dados menos voláteis permanecem no Lakehouse.\n3. Armazenamento: Otimização para Baixa Latência e Eficiência O Lakebase não \u0026ldquo;copia\u0026rdquo; indiscriminadamente todos os dados do legado. A estratégia de armazenamento é mais inteligente e focada no \u0026ldquo;estado ativo\u0026rdquo; necessário para os agentes:\nDados Operacionais Ativos: O Lakebase é projetado para armazenar o subconjunto de dados operacionais que os agentes de IA precisam acessar e modificar em tempo real. Isso pode ser uma replicação de tabelas específicas de sistemas legados (via CDC ou streaming para o Lakehouse e, em seguida, para o Lakebase) ou dados gerados diretamente por novas aplicações que utilizam o Lakebase como seu banco de dados primário. Materialização Seletiva: Para dados que residem primariamente no Lakehouse (originados de sistemas legados), o Lakebase pode materializar visões ou tabelas específicas que são relevantes para as operações dos agentes. Isso significa que apenas os dados necessários para as decisões em tempo real dos agentes são mantidos na camada de baixa latência do Lakebase, enquanto o histórico completo e os dados frios permanecem no Lakehouse. Armazenamento em Object Storage com Cache Inteligente: Embora os dados sejam armazenados em object storage de baixo custo, o Lakebase utiliza camadas de cache e soft-state para garantir que os dados mais acessados pelos agentes estejam disponíveis com latência de milissegundos. Isso evita a duplicação massiva de dados e otimiza os custos de armazenamento. Recomendação de Retenção: Estado Ativo vs. Histórico Frio A estratégia de retenção no Lakebase deve ser orientada pela necessidade operacional dos agentes de IA:\nLakebase: Retenção de Curto Prazo (Estado Ativo): O Lakebase deve reter apenas o estado ativo e relevante para as operações em tempo real dos agentes. Isso significa dados que são frequentemente lidos e modificados pelos agentes. Por exemplo, para um agente de recomendação, o estoque atual de produtos, o histórico recente de interações do usuário e o status de pedidos em andamento. Períodos de retenção podem variar de dias a poucas semanas, dependendo da volatilidade e da criticidade dos dados para as decisões do agente. Lakehouse: Retenção de Longo Prazo (Histórico Frio): O histórico completo e os dados frios (que não são mais necessários para decisões em tempo real, mas são valiosos para análises retrospectivas, treinamento de modelos e conformidade) devem ser descarregados para o Lakehouse (Delta Lake). A integração nativa do Lakebase com o Unity Catalog facilita esse processo, permitindo que os dados sejam movidos ou sincronizados para o Lakehouse de forma eficiente e governada. Essa divisão clara de responsabilidades garante que o Lakebase permaneça ágil e de baixa latência para os agentes, enquanto o Lakehouse oferece escalabilidade e economia para o armazenamento de longo prazo e análises complexas. É uma abordagem que equilibra performance operacional com eficiência de custos e governança de dados.\nCaso de Uso: Recomendação de Produtos em Tempo Real com Agentes de IA em E-commerce Imagine uma grande plataforma de e-commerce que deseja oferecer recomendações de produtos hiper-personalizadas e em tempo real, adaptando-se instantaneamente ao comportamento do usuário e às mudanças de estoque/preço. Os sistemas tradicionais lutam com a latência e a complexidade de gerenciar dados transacionais e analíticos para essa finalidade.\nDesafio:\nLatência: Atrasos na ingestão de dados de cliques, visualizações e compras resultam em recomendações desatualizadas. Experimentação: Testar novos algoritmos de recomendação ou estratégias de precificação em produção é arriscado e lento. Escalabilidade: Lidar com milhões de eventos por segundo e manter a performance do banco de dados transacional. Agentes de IA: Treinar e operar agentes de IA que precisam de acesso rápido e consistente a dados operacionais para tomar decisões em milissegundos. Solução com Databricks Lakebase:\nDados Operacionais em Lakebase: Todos os eventos de usuário (cliques, visualizações, adições ao carrinho, compras) e dados de catálogo de produtos (preço, estoque) são armazenados no Lakebase. A baixa latência garante que esses dados estejam disponíveis quase instantaneamente. Agentes de IA para Recomendação: Agentes de IA são desenvolvidos para monitorar o comportamento do usuário em tempo real. Eles acessam os dados do Lakebase para identificar padrões e gerar recomendações personalizadas. Branching para Experimentação Segura: Antes de lançar um novo algoritmo de recomendação, um branch do banco de dados do Lakebase é criado. Agentes de IA podem ser treinados e testados nesse ambiente isolado, simulando cenários de produção sem impactar os clientes reais. Se o novo algoritmo gerar hallucinations ou recomendações inadequadas, o branch é simplesmente descartado. Integração com Lakehouse: Os dados do Lakebase são sincronizados em tempo real com o Lakehouse via Unity Catalog. Isso permite que equipes de Data Science usem o histórico completo de interações para treinar modelos de IA mais complexos e realizar análises de negócio aprofundadas, enquanto os agentes operam com os dados mais recentes. Benefícios:\nRecomendações em Tempo Real: A baixa latência do Lakebase garante que as recomendações sejam sempre baseadas nos dados mais atuais. Inovação Acelerada: O branching permite testar e iterar rapidamente em novos algoritmos de IA sem risco à produção. Experiência do Cliente Aprimorada: Recomendações mais precisas e personalizadas levam a maior engajamento e vendas. Governança Unificada: O Unity Catalog garante que todos os dados, do operacional ao analítico, estejam sob o mesmo guarda-chuva de segurança e conformidade. Guia de Implementação Passo a Passo: Agentes de IA com Agent Bricks e Lakebase Para demonstrar a capacidade do Lakebase em conjunto com o Agent Bricks para construir agentes de IA robustos, vamos detalhar um fluxo de trabalho técnico. O foco será na criação de um agente de recomendação que interage com dados operacionais no Lakebase e utiliza o branching para experimentação segura.\n1. Configuração Inicial no Databricks e Lakebase Primeiro, certifique-se de que seu ambiente Databricks esteja configurado com o Unity Catalog e o Agent Bricks Preview habilitado. Você precisará de um workspace Databricks e permissões para criar catálogos, esquemas e utilizar o Agent Bricks.\n-- Criar um catálogo no Unity Catalog para o Lakebase CREATE CATALOG IF NOT EXISTS ecommerce_catalog; USE CATALOG ecommerce_catalog; -- Criar um esquema (database) para os dados operacionais do e-commerce CREATE SCHEMA IF NOT EXISTS operational_db; USE SCHEMA operational_db; -- Tabela de Pedidos (OLTP) no Lakebase CREATE TABLE orders ( order_id STRING NOT NULL PRIMARY KEY, user_id STRING NOT NULL, product_id STRING NOT NULL, quantity INT NOT NULL, order_timestamp TIMESTAMP NOT NULL, status STRING NOT NULL ) USING LAKEBASE; -- Tabela de Produtos (OLTP) no Lakebase CREATE TABLE products ( product_id STRING NOT NULL PRIMARY KEY, product_name STRING NOT NULL, category STRING NOT NULL, price DECIMAL(10, 2) NOT NULL, stock_quantity INT NOT NULL ) USING LAKEBASE; -- Inserir dados de exemplo INSERT INTO products VALUES (\\\u0026#39;prod_001\\\u0026#39;, \\\u0026#39;Laptop Gamer\\\u0026#39;, \\\u0026#39;Eletronicos\\\u0026#39;, 1500.00, 100), (\\\u0026#39;prod_002\\\u0026#39;, \\\u0026#39;Mouse Sem Fio\\\u0026#39;, \\\u0026#39;Acessorios\\\u0026#39;, 50.00, 500), (\\\u0026#39;prod_003\\\u0026#39;, \\\u0026#39;Teclado Mecanico\\\u0026#39;, \\\u0026#39;Acessorios\\\u0026#39;, 120.00, 200); INSERT INTO orders VALUES (\\\u0026#39;order_001\\\u0026#39;, \\\u0026#39;user_a\\\u0026#39;, \\\u0026#39;prod_001\\\u0026#39;, 1, \\\u0026#39;2026-02-27 10:00:00\\\u0026#39;, \\\u0026#39;completed\\\u0026#39;), (\\\u0026#39;order_002\\\u0026#39;, \\\u0026#39;user_b\\\u0026#39;, \\\u0026#39;prod_002\\\u0026#39;, 2, \\\u0026#39;2026-02-27 10:05:00\\\u0026#39;, \\\u0026#39;pending\\\u0026#39;), (\\\u0026#39;order_003\\\u0026#39;, \\\u0026#39;user_a\\\u0026#39;, \\\u0026#39;prod_003\\\u0026#39;, 1, \\\u0026#39;2026-02-27 10:15:00\\\u0026#39;, \\\u0026#39;completed\\\u0026#39;); 2. Desenvolvendo um Agente de Recomendação com Agent Bricks Vamos criar um agente simples que, dado um user_id, recomenda produtos baseados em compras anteriores e no estoque atual. O Agent Bricks permite definir agentes de forma declarativa. Este exemplo simula a lógica dentro de um notebook Databricks, que seria a base para um agente Agent Bricks.\n# Exemplo de código Python em um notebook Databricks para um agente de recomendação # Este código simula a lógica que seria encapsulada por um Agent Bricks from databricks.sdk import WorkspaceClient from databricks.sdk.service.sql import Statement # Inicializar o cliente do Workspace (assumindo autenticação configurada) w = WorkspaceClient() def get_user_orders(user_id: str, branch: str = \u0026#34;main\u0026#34;): # Conectar ao Lakebase usando o branch especificado # Em um ambiente real, o Agent Bricks gerencia a conexão e o contexto do branch query = f\u0026#34;USE BRANCH {branch}; SELECT product_id FROM orders WHERE user_id = \\\u0026#39;{user_id}\\\u0026#39;\u0026#34; result = w.statement_execution.execute_statement( statement=query, warehouse_id=\u0026#34;\u0026lt;seu_warehouse_id\u0026gt;\u0026#34;, # Substitua pelo ID do seu SQL Warehouse catalog=\u0026#34;ecommerce_catalog\u0026#34;, schema=\u0026#34;operational_db\u0026#34; ).result.data_array return [row[0] for row in result] def get_product_stock(product_id: str, branch: str = \u0026#34;main\u0026#34;): query = f\u0026#34;USE BRANCH {branch}; SELECT stock_quantity FROM products WHERE product_id = \\\u0026#39;{product_id}\\\u0026#39;\u0026#34; result = w.statement_execution.execute_statement( statement=query, warehouse_id=\u0026#34;\u0026lt;seu_warehouse_id\u0026gt;\u0026#34;, catalog=\u0026#34;ecommerce_catalog\u0026#34;, schema=\u0026#34;operational_db\u0026#34; ).result.data_array return result[0][0] if result else 0 def recommend_products(user_id: str, branch: str = \u0026#34;main\u0026#34;): purchased_products = get_user_orders(user_id, branch) recommendations = [] # Lógica de recomendação simplificada: recomendar produtos com estoque \u0026gt; 0 que não foram comprados all_products_query = f\u0026#34;USE BRANCH {branch}; SELECT product_id, product_name FROM products WHERE stock_quantity \u0026gt; 0\u0026#34; all_products_result = w.statement_execution.execute_statement( statement=all_products_query, warehouse_id=\u0026#34;\u0026lt;seu_warehouse_id\u0026gt;\u0026#34;, catalog=\u0026#34;ecommerce_catalog\u0026#34;, schema=\u0026#34;operational_db\u0026#34; ).result.data_array for prod_id, prod_name in all_products_result: if prod_id not in purchased_products: recommendations.append(prod_name) return recommendations # Exemplo de uso do agente (simulado) user_to_recommend = \u0026#34;user_a\u0026#34; print(f\u0026#34;Recomendações para {user_to_recommend} (branch main): {recommend_products(user_to_recommend)}\u0026#34;) 3. Experimentação Segura com Branching e Agent Bricks Agora, vamos usar o branching do Lakebase para testar uma nova estratégia de recomendação que envolve uma promoção agressiva em um produto específico, o que pode impactar o estoque. O Agent Bricks pode ser configurado para operar em branches específicos para testes.\n-- Criar um novo branch para testar a promoção CREATE BRANCH promo_test ON TABLE orders; CREATE BRANCH promo_test ON TABLE products; Um agente de IA configurado para o branch promo_test pode agora simular as alterações. No Agent Bricks, você especificaria o branch no contexto de execução do agente.\n# Simulação de um agente de IA operando no branch \\\u0026#39;promo_test\\\u0026#39; # O Agent Bricks abstrairia a gestão do branch para o desenvolvedor do agente # Agente de IA decide aplicar um desconto e vender um Laptop Gamer # Esta operação ocorre APENAS no branch \\\u0026#39;promo_test\\\u0026#39; update_query = \u0026#34;UPDATE products SET stock_quantity = stock_quantity - 1 WHERE product_id = \\\u0026#39;prod_001\\\u0026#39;\u0026#34; w.statement_execution.execute_statement( statement=update_query, warehouse_id=\u0026#34;\u0026lt;seu_warehouse_id\u0026gt;\u0026#34;, catalog=\u0026#34;ecommerce_catalog\u0026#34;, schema=\u0026#34;operational_db\u0026#34;, branch=\u0026#34;promo_test\u0026#34; # Especifica o branch para a operação ) # O agente verifica o estoque no branch de teste print(f\u0026#34;Estoque de Laptop Gamer no branch promo_test: {get_product_stock(\\\u0026#39;prod_001\\\u0026#39;, branch=\\\u0026#39;promo_test\\\u0026#39;)}\u0026#34;) # O estoque no branch principal permanece inalterado print(f\u0026#34;Estoque de Laptop Gamer no branch main: {get_product_stock(\\\u0026#39;prod_001\\\u0026#39;, branch=\\\u0026#39;main\\\u0026#39;)}\u0026#34;) Se o resultado da simulação no promo_test for positivo (por exemplo, aumento de vendas simuladas sem esgotar o estoque de forma prejudicial), as alterações podem ser mescladas para o branch main. Caso contrário, o branch promo_test pode ser descartado sem afetar a produção.\n-- Se os testes forem bem-sucedidos, mesclar as alterações (exemplo conceitual, a mesclagem pode ser mais complexa) -- MERGE BRANCH promo_test INTO main ON TABLE orders; -- MERGE BRANCH promo_test INTO main ON TABLE products; -- Descartar o branch de teste após a conclusão (seja mesclado ou não) DROP BRANCH promo_test ON TABLE orders; DROP BRANCH promo_test ON TABLE products; 4. Integração Contínua com o Lakehouse (Unity Catalog) Independentemente dos branches operacionais, os dados do Lakebase são continuamente sincronizados com o Lakehouse via Unity Catalog. Isso permite que equipes de Data Science e Analytics continuem a treinar modelos de IA mais complexos e realizar análises de negócio aprofundadas sobre o histórico completo de interações, enquanto os agentes operam com os dados mais recentes e em seus branches isolados.\n-- Exemplo de como uma equipe de Data Science pode consultar dados operacionais -- diretamente do Lakehouse via Unity Catalog para treinamento de modelos SELECT o.user_id, p.product_name, o.quantity, o.order_timestamp, p.category FROM ecommerce_catalog.operational_db.orders AS o JOIN ecommerce_catalog.operational_db.products AS p ON o.product_id = p.product_id WHERE o.order_timestamp \u0026gt;= current_date() - INTERVAL \\\u0026#39;30 days\\\u0026#39;; Conclusão O Databricks Lakebase, em conjunto com o Agent Bricks, oferece uma plataforma poderosa para a construção e operação de aplicações inteligentes e agentes de IA. A capacidade de fornecer baixa latência em object storage, o mecanismo de branching para experimentação segura e a integração perfeita com o Unity Catalog para governança unificada, posicionam o Lakebase como a fundação técnica ideal para a próxima geração de sistemas transacionais e analíticos. Para organizações que buscam inovar rapidamente com IA, o Lakebase e o Agent Bricks fornecem as ferramentas necessárias para transformar dados operacionais em inteligência acionável de forma segura e escalável.\nReferências Lakebase Postgres | Databricks on AWS What is Lakebase Provisioned? | Databricks on AWS Tutorial: Branch-based development workflow | Databricks on AWS Agent Bricks | Databricks on AWS Databricks documentation | Databricks on AWS ","permalink":"https://julianamarialop.github.io/articles/databricks-lakebase-o-guia-definitivo-para-nova-era-de/","summary":"O Databricks Lakebase representa uma evolução significativa na arquitetura de dados, especificamente no domínio dos bancos de dados OLTP (Online Transactional Processing). Não se trata apenas de mais um banco de dados…","title":"Databricks Lakebase: O Guia Definitivo para a Nova Era de Dados Operacionais e Agentes de IA"},{"content":"No vasto universo de Star Wars, a Força conecta tudo, mas apenas os Jedi mais dedicados conseguem dominá-la para construir e comandar sabres de luz e holocrons inteligentes. No nosso universo da tecnologia, a transição de Data Engineer para AI Engineer na AWS é o nosso próprio Despertar da Força: uma operação de guerra focada de 3 meses para transformar seu domínio de dados na capacidade de construir e orquestrar inteligência autônoma.\nEste artigo detalha um roadmap intensivo para essa transição, focando no Amazon Bedrock, Amazon Q e Amazon SageMaker como pilares, e discute como provar suas novas competências e alcançar a senioridade em projetos de IA.\nPor que essa transição é estratégica e urgente agora? A Inteligência Artificial, impulsionada pela IA Generativa e pelos agentes autônomos, está redefinindo a forma como as empresas operam. A capacidade de construir sistemas proativos que tomam decisões e executam ações de forma autônoma é o novo diferencial competitivo. Como Data Engineer, sua expertise em dados e infraestrutura é a base mais crítica para essa revolução. Você já domina o terreno; agora é hora de construir a inteligência sobre ele.\nAo transitar para AI Engineer, você move seu foco de \u0026ldquo;garantir o fluxo de dados\u0026rdquo; para \u0026ldquo;construir a inteligência que consome e age sobre esses dados\u0026rdquo;. No ecossistema AWS, isso significa dominar o Amazon Bedrock para acesso a modelos fundacionais, o Amazon Q para inteligência conversacional e o Amazon SageMaker para o ciclo de vida completo do Machine Learning. Essa evolução não só multiplica seu valor de mercado, mas o posiciona como um arquiteto da inteligência que impulsiona a inovação em ritmo acelerado.\nRoadmap Intensivo: Do Data Engineer ao AI Engineer em 3 Meses na AWS Este roadmap é desenhado para um Data Engineer com experiência sólida em AWS, que busca uma transição rápida e focada. É uma \u0026ldquo;operação de guerra\u0026rdquo; que exige dedicação e imersão.\nMês 1: Despertar da Força e Fundamentos (Amazon Bedrock \u0026amp; Amazon Q) Foco: Entender a \u0026ldquo;Força\u0026rdquo; (IA Generativa) e os mestres (Modelos Fundacionais) na AWS.\nFundamentos de IA Generativa na AWS: Mergulhe nos conceitos de IA Generativa, Large Language Models (LLMs) e como eles funcionam. Entenda o papel do Amazon Bedrock como um serviço totalmente gerenciado para acessar modelos fundacionais (FMs) de forma segura e escalável. Explore o Amazon Q Business para inteligência conversacional no ambiente corporativo. Utilize as documentações oficiais para aprimoramento Amazon Bedrock Documentation e Amazon Q Business Documentation Engenharia de Prompt e RAG: Aprenda a arte de interagir com LLMs através da Engenharia de Prompt e aprimore a precisão das respostas com RAG (Retrieval-Augmented Generation), utilizando bases de conhecimento para contextualizar os modelos. Certificação Relevante: AWS Certified AI Practitioner (AIF-C01) . Esta certificação valida seu conhecimento em conceitos de AI/ML, Generative AI e casos de uso, sendo um excelente ponto de partida. Mês 2: Construindo o Sabre de Luz e Agentes (Amazon SageMaker \u0026amp; Bedrock Agents) Foco: Construir o \u0026ldquo;Sabre de Luz\u0026rdquo; (Agentes e Pipelines de ML) que transformam dados em ações inteligentes.\nEngenharia de Dados para ML no SageMaker: Utilize o Amazon SageMaker para preparar dados para modelos de ML. Domine ferramentas como SageMaker Data Wrangler para ingestão e transformação, e SageMaker Pipelines para orquestrar fluxos de trabalho de ML. Sua base de Data Engineer será crucial aqui. Veja a documentação em Amazon SageMaker Documentation Agentes no Amazon Bedrock: Aprenda a criar agentes que não apenas respondem, mas agem. Explore os Bedrock Agents para construir aplicações que interagem com ferramentas externas e APIs, e as Knowledge Bases for Bedrock para implementar RAG de forma eficiente. Frameworks de Orquestração: Explore frameworks como LangChain ou LlamaIndex para orquestrar múltiplos agentes e ferramentas, criando sistemas de IA mais complexos e capazes de resolver problemas multifacetados. Mês 3: Comandando a Frota e Certificação (MLOps, Governança \u0026amp; Certificação MLA-C01) Foco: Colocar a inteligência em produção, garantir governança e validar suas novas habilidades formalmente, tornando-se um comandante da frota de IA.\nMLOps na AWS: Implemente práticas de MLOps usando Amazon SageMaker para monitoramento de modelos (Model Monitor), AWS Glue para qualidade de dados e Amazon SageMaker Clarify para IA Responsável (explicabilidade e mitigação de vieses). Governança de IA na AWS: Familiarize-se com as capacidades de governança integradas da AWS para garantir que seus agentes operem de forma segura, ética e em conformidade. Isso inclui o uso de AWS Organizations, AWS IAM e AWS CloudTrail para auditoria. Certificação AWS Certified Machine Learning Engineer - Associate (MLA-C01) : Esta certificação é o seu grande marco. Ela valida sua capacidade de construir, operacionalizar, implantar e manter workloads de ML na AWS, com foco em SageMaker e outros serviços relevantes. Aqui temos o Guia de Estudo para o Exame MLA-C01 Estimativa Temporal Para um Data Engineer com experiência sólida em AWS, essa \u0026ldquo;operação de guerra\u0026rdquo; de 3 meses é ambiciosa, mas totalmente factível para adquirir as competências essenciais de um AI Engineer júnior/pleno. A chave é a dedicação intensiva e a aplicação prática imediata do conhecimento. Para alcançar a senioridade, o tempo pode se estender para 1 a 2 anos adicionais de experiência em projetos complexos, liderança e arquitetura de soluções AI-Centric.\nComo Ser Sênior em Projetos de IA? Além do Código, a Arquitetura da Inteligência Ser sênior em IA transcende o domínio técnico de ferramentas e modelos. Envolve a capacidade de arquitetar soluções de ponta a ponta, garantir governança e entregar valor de negócio de forma confiável e ética.\nA senioridade se manifesta quando você:\nProjeta Arquiteturas de IA Escaláveis: Vai além do pipeline de dados para desenhar a arquitetura completa de sistemas de IA, incluindo ingestão de dados para IA, pipelines de inferência, integração com sistemas legados e monitoramento contínuo. Implementa Governança e IA Responsável: Garante que as soluções de IA sejam éticas, transparentes e seguras. Isso inclui a aplicação de princípios de IA Responsável, mitigação de vieses, explicabilidade de modelos e conformidade regulatória. Otimiza Performance e Custos: Seleciona as ferramentas e modelos mais adequados, otimiza o uso de recursos de computação e garante que as soluções de IA sejam financeiramente sustentáveis e eficientes. Lidera e Orienta: Atua como mentor para equipes mais juniores, compartilha conhecimento e influencia a estratégia de IA da organização, traduzindo requisitos de negócio em soluções técnicas e vice-versa. Foca na Confiabilidade: Desenha sistemas que são resilientes a falhas, que aprendem e se adaptam continuamente, e que minimizam o risco de \u0026ldquo;alucinações\u0026rdquo; ou comportamentos indesejados. O AI Engineer Sênior é o arquiteto da inteligência, o profissional que transforma dados em decisões autônomas e valor de negócio sustentável.\nComo Provar Seus Conhecimentos e Construir um Portfólio de AI Engineer? Teoria é importante, mas a prática é o que realmente diferencia um profissional. Para solidificar sua transição e demonstrar suas novas habilidades, construir um portfólio robusto é essencial. Aqui estão algumas formas de fazer isso:\nProjetos Pessoais com Agentes de IA (Bedrock \u0026amp; SageMaker): Crie seus próprios agentes inteligentes usando o Amazon Bedrock para modelos fundacionais e o Amazon SageMaker para orquestração e MLOps. Pense em problemas do dia a dia que poderiam ser automatizados ou otimizados por um agente. Por exemplo, um agente que monitora notícias de mercado e gera resumos executivos, ou um que automatiza a triagem de e-mails. Contribuições Open Source: Participe de projetos open source relacionados a IA, especialmente aqueles que utilizam tecnologias AWS. Isso demonstra não apenas suas habilidades técnicas, mas também sua capacidade de colaborar em equipes e seguir boas práticas de desenvolvimento. GitHub como Seu Cartão de Visitas: Mantenha um perfil ativo no GitHub, documentando seus projetos, mostrando o código-fonte, explicando a arquitetura e os resultados. Um bom README.md é tão importante quanto o código. Inclua demos, vídeos curtos ou screenshots que mostrem seus agentes em ação. Artigos e Tutoriais: Compartilhe seu aprendizado. Escreva artigos no LinkedIn ou em blogs técnicos sobre os projetos que você desenvolveu, os desafios que enfrentou e as soluções que encontrou. Isso não só reforça seu conhecimento, mas também o posiciona como uma referência na área. Participação em Hackathons e Desafios: Engaje-se em eventos que promovam a criação de soluções de IA. É uma excelente forma de aprender, aplicar conhecimentos sob pressão e construir projetos para seu portfólio em um curto espaço de tempo. Lembre-se: seu portfólio não é apenas uma coleção de códigos, mas a narrativa da sua jornada como AI Engineer. Ele deve contar a história de como você transforma dados em inteligência acionável.\nConclusão: O Despertar da Força para o Futuro da Tecnologia A transição de Data Engineer para AI Engineer não é apenas uma mudança de título, mas um Despertar da Força calculado para o futuro da tecnologia. Você, como Data Engineer, já possui a base mais crítica: o domínio dos dados.\nAo expandir suas habilidades para a engenharia de sistemas de IA, com foco no Amazon Bedrock, Amazon Q e Amazon SageMaker, você se posiciona na vanguarda da inovação, construindo os sistemas inteligentes, seguros e escaláveis que o mercado exige. O futuro da tecnologia não é apenas sobre ter os melhores modelos, mas sobre ter a melhor engenharia para colocá-los em produção e garantir que entreguem valor real em tempo recorde.\nEstá pronto para dar o próximo passo e se tornar o arquiteto da inteligência do amanhã em apenas 3 meses?\nReferências AWS. AWS Certified AI Practitioner. AWS. AWS Certified AI Practitioner (AIF-C01) - AWS Certification. AWS. AWS Certified Machine Learning Engineer - Associate. AWS. AWS Certified Machine Learning Engineer - Associate (MLA-C01) Exam Guide. https://skillbuilder.aws/category/exam-prep/ai-practitioner)(Estelink%C3%A9paraoExamPrepPlandoAIPractitioner,masoconte%C3%BAdodeBedrockGettingStartedpodeserencontradonoSkillBuilder \u0026ldquo;AWS Skill Builder. Amazon Bedrock Getting Started.\u0026rdquo; https://aws.amazon.com/blogs/training-and-certification/category/artificial-intelligence/generative-ai/)(Estelink%C3%A9paraoblogdeGenAI,oLearningPlanpodeserencontradonoSkillBuilder \u0026ldquo;AWS Skill Builder. Generative AI Learning Plan for Developers.\u0026rdquo; AWS. Amazon Q Business. AWS. Amazon Bedrock. AWS. Amazon SageMaker. ","permalink":"https://julianamarialop.github.io/articles/o-despertar-da-forca-de-data-engineer-ai-em-90-dias-com/","summary":"No vasto universo de Star Wars, a Força conecta tudo, mas apenas os Jedi mais dedicados conseguem dominá-la para construir e comandar sabres de luz e holocrons inteligentes. No nosso universo da tecnologia, a transição…","title":"O Despertar da Força: De Data Engineer a AI Data Engineer em 90 Dias com AWS"},{"content":"No universo de Assassin\u0026rsquo;s Creed, o Salto de Fé é um ato de coragem, técnica e confiança. Não é um salto cego, mas um movimento calculado que exige conhecimento do terreno e precisão para alcançar um novo patamar. No mundo da tecnologia, a transição de Data Engineer para AI Engineer é o nosso próprio Salto de Fé: uma operação de guerra focada de 3 meses para dominar a construção de inteligência autônoma no ecossistema Microsoft.\nEste artigo detalha um roadmap intensivo para essa transição, focando no Microsoft Fabric e Azure AI Foundry como pilares, e discute como provar suas novas competências e alcançar a senioridade em projetos de IA.\nPor que essa transição é estratégica e urgente agora? A Inteligência Artificial, impulsionada pela IA Generativa e pelos agentes autônomos, está redefinindo a forma como as empresas operam. A capacidade de construir sistemas proativos que tomam decisões e executam ações de forma autônoma é o novo diferencial competitivo. Como Data Engineer, sua expertise em dados e infraestrutura é a base mais crítica para essa revolução. Você já domina o terreno; agora é hora de construir a inteligência sobre ele.\nAo transitar para AI Engineer, você move seu foco de \u0026ldquo;garantir o fluxo de dados\u0026rdquo; para \u0026ldquo;construir a inteligência que consome e age sobre esses dados\u0026rdquo;. No ecossistema Microsoft, isso significa dominar o Microsoft Fabric para a unificação de dados e o Azure AI Foundry para a orquestração e produção de agentes. Essa evolução não só multiplica seu valor de mercado, mas o posiciona como um arquiteto da inteligência que impulsiona a inovação em ritmo acelerado.\nRoadmap Intensivo: Do Data Engineer ao AI Engineer em 3 Meses no Microsoft Azure Este roadmap é desenhado para um Data Engineer com experiência sólida em Azure, que busca uma transição rápida e focada. É uma \u0026ldquo;operação de guerra\u0026rdquo; que exige dedicação e imersão.\nMês 1: Fundação de Dados e IA Generativa (Microsoft Fabric \u0026amp; Azure OpenAI) Foco: Dominar o Microsoft Fabric como sua nova plataforma unificada de dados e IA, e aprender a consumir modelos de IA existentes.\nMicrosoft Fabric Fundamentals: Mergulhe no Fabric. Entenda o OneLake como seu data lake unificado e os diferentes \u0026ldquo;Experiences\u0026rdquo; (Data Engineering, Data Science, Data Warehouse, Real-Time Analytics). Sua base de Data Engineer é um diferencial aqui. Por onde começar: Trilha de Aprendizado: Introdução ao Microsoft Fabric Certificações Relevantes: Microsoft Certified: Fabric Analytics Engineer Associate (DP-600) ou Microsoft Certified: Fabric Data Engineer Associate (DP-700) . Escolha a que mais se alinha com sua base atual e aspirações. Azure OpenAI Service e Engenharia de Prompt: Aprenda a consumir modelos de linguagem avançados. O foco aqui é em Engenharia de Prompt e RAG (Retrieval-Augmented Generation) para criar aplicações inteligentes que utilizam o conhecimento da sua empresa. Por onde começar: Trilha de Aprendizado: Desenvolver aplicativos de IA generativa no Azure Mês 2: Construção de Agentes, Busca Semântica e Orquestração (Azure AI Foundry \u0026amp; Fabric Data Agents) Foco: Construir sistemas de IA que não apenas processam informações, mas também tomam decisões e executam ações, com ênfase nos Data Agents do Fabric e no Azure AI Foundry.\nAzure AI Foundry: Entenda como essa plataforma unificada acelera o ciclo de vida de desenvolvimento de IA, desde a experimentação até a produção de agentes autônomos. O Foundry é o seu estúdio de produção de inteligência. Por onde começar: Visão geral do Azure AI Foundry Microsoft Fabric Data Agents: Aprenda a criar Data Agents no Fabric. Eles transformam dados empresariais em sistemas de Q\u0026amp;A conversacionais e analistas virtuais baseados em IA generativa, que podem ser orquestrados pelo Foundry. Por onde começar: Conceito de Data Agent no Fabric e Como criar um Data Agent no Fabric Azure AI Search: Domine a busca vetorial e híbrida para construir sistemas de recuperação de informações que alimentam seus Data Agents e outros agentes com conhecimento relevante e em tempo real. Frameworks de Orquestração de Agentes: Explore Semantic Kernel ou LangChain para criar agentes que interagem com ferramentas e APIs externas. Isso transforma um modelo de linguagem em um sistema capaz de executar tarefas complexas. Mês 3: Produção, Governança e Certificação Acelerada Foco: Colocar agentes em produção, garantir governança e validar suas novas habilidades formalmente.\nAzure AI Foundry para Produção: Utilize o Foundry para gerenciar o ciclo de vida completo dos seus agentes, desde a experimentação até a implantação e monitoramento em larga escala. Entenda o Foundry Control Plane para governança e segurança. Por onde começar: Consumir um Data Agent no Azure AI Foundry Governança de IA no Fabric e Foundry: Familiarize-se com as capacidades de governança integradas (como Microsoft Purview no Fabric) para garantir que seus agentes operem de forma segura, ética e em conformidade. Certificação Azure AI Engineer Associate (AI-102): Esta certificação é crucial. Ela valida sua capacidade de projetar e implementar soluções de IA usando Azure AI Services, Azure AI Search e Azure OpenAI. Por onde começar: Microsoft Certified: Azure AI Engineer Associate e Guia de estudo para o Exame AI-102 Estimativa Temporal Para um Data Engineer com experiência sólida em Azure, essa \u0026ldquo;operação de guerra\u0026rdquo; de 3 meses é ambiciosa, mas totalmente factível para adquirir as competências essenciais de um AI Engineer júnior/pleno, especialmente com o foco no Fabric e no AI Foundry. A chave é a dedicação intensiva e a aplicação prática imediata do conhecimento. Para alcançar a especialização, o tempo pode se estender para 1 a 2 anos adicionais de experiência em projetos complexos, liderança e arquitetura de soluções AI-Centric.\nComo Ser Sênior em Projetos de IA? Além do Código, a Arquitetura da Inteligência Ser sênior em IA transcende o domínio técnico de ferramentas e modelos. Envolve a capacidade de arquitetar soluções de ponta a ponta, garantir governança e entregar valor de negócio de forma confiável e ética.\nA senioridade se manifesta quando você:\nProjeta Arquiteturas de IA Escaláveis: Vai além do pipeline de dados para desenhar a arquitetura completa de sistemas de IA, incluindo ingestão de dados para IA, pipelines de inferência, integração com sistemas legados e monitoramento contínuo. Implementa Governança e IA Responsável: Garante que as soluções de IA sejam éticas, transparentes e seguras. Isso inclui a aplicação de princípios de IA Responsável, mitigação de vieses, explicabilidade de modelos e conformidade regulatória. Otimiza Performance e Custos: Seleciona as ferramentas e modelos mais adequados, otimiza o uso de recursos de computação e garante que as soluções de IA sejam financeiramente sustentáveis e eficientes. Lidera e Orienta: Atua como mentor para equipes mais juniores, compartilha conhecimento e influencia a estratégia de IA da organização, traduzindo requisitos de negócio em soluções técnicas e vice-versa. Foca na Confiabilidade: Desenha sistemas que são resilientes a falhas, que aprendem e se adaptam continuamente, e que minimizam o risco de \u0026ldquo;alucinações\u0026rdquo; ou comportamentos indesejados. O AI Engineer Sênior é o arquiteto da inteligência, o profissional que transforma dados em decisões autônomas e valor de negócio sustentável.\nComo Provar Seus Conhecimentos e Construir um Portfólio de AI Engineer? Teoria é importante, mas a prática é o que realmente diferencia um profissional. Para solidificar sua transição e demonstrar suas novas habilidades, construir um portfólio robusto é essencial. Aqui estão algumas formas de fazer isso:\nProjetos Pessoais com Agentes de IA (Fabric \u0026amp; Foundry): Crie seus próprios agentes inteligentes usando o Microsoft Fabric para Data Agents e o Azure AI Foundry para orquestração. Pense em problemas do dia a dia que poderiam ser automatizados ou otimizados por um agente. Por exemplo, um agente que monitora notícias de mercado e gera resumos executivos, ou um que automatiza a triagem de e-mails. Contribuições Open Source: Participe de projetos open source relacionados a IA, especialmente aqueles que utilizam tecnologias Microsoft. Isso demonstra não apenas suas habilidades técnicas, mas também sua capacidade de colaborar em equipes e seguir boas práticas de desenvolvimento. GitHub como Seu Cartão de Visitas: Mantenha um perfil ativo no GitHub, documentando seus projetos, mostrando o código-fonte, explicando a arquitetura e os resultados. Um bom README.md é tão importante quanto o código. Inclua demos, vídeos curtos ou screenshots que mostrem seus agentes em ação. Artigos e Tutoriais: Compartilhe seu aprendizado. Escreva artigos no LinkedIn ou em blogs técnicos sobre os projetos que você desenvolveu, os desafios que enfrentou e as soluções que encontrou. Isso não só reforça seu conhecimento, mas também o posiciona como uma referência na área. Participação em Hackathons e Desafios: Engaje-se em eventos que promovam a criação de soluções de IA. É uma excelente forma de aprender, aplicar conhecimentos sob pressão e construir projetos para seu portfólio em um curto espaço de tempo. Lembre-se: seu portfólio não é apenas uma coleção de códigos, mas a narrativa da sua jornada como AI Engineer. Ele deve contar a história de como você transforma dados em inteligência acionável.\nConclusão: O Salto de Fé para o Futuro da Tecnologia A transição de Data Engineer para AI Engineer não é apenas uma mudança de título, mas um Salto de Fé calculado para o futuro da tecnologia. Você, como Data Engineer, já possui a base mais crítica: o domínio dos dados.\nAo expandir suas habilidades para a engenharia de sistemas de IA, com foco no Microsoft Fabric e no Azure AI Foundry, você se posiciona na vanguarda da inovação, construindo os sistemas inteligentes, seguros e escaláveis que o mercado exige. O futuro da tecnologia não é apenas sobre ter os melhores modelos, mas sobre ter a melhor engenharia para colocá-los em produção e garantir que entreguem valor real em tempo recorde.\nEstá pronto para dar o próximo passo e se tornar o arquiteto da inteligência do amanhã em apenas 3 meses?\nReferências Microsoft Learn. Microsoft Applied Skills: Desenvolver soluções de IA generativa com o Serviço OpenAI do Azure. Microsoft Learn. Microsoft Certified: Azure AI Engineer Associate. Microsoft Learn. Trilha de Aprendizado: Desenvolver aplicativos de IA generativa no Azure. Microsoft Learn. Microsoft Applied Skills: Desenvolver agentes de IA usando o Serviço OpenAI do Azure e o Semantic Kernel. Microsoft Learn. Microsoft Applied Skills: Implementar mineração de conhecimento com o Azure AI Search. Microsoft Learn. Guia de estudo para o Exame AI-102. Microsoft Learn. Trilha de Aprendizado: Introdução ao Microsoft Fabric. Microsoft Learn. Conceito de Data Agent no Fabric. Microsoft Learn. Como criar um Data Agent no Fabric. Microsoft Learn. Microsoft Certified: Fabric Analytics Engineer Associate (DP-600). Microsoft Learn. Microsoft Certified: Fabric Data Engineer Associate (DP-700). Azure. Azure AI Foundry. Microsoft Learn. Microsoft Applied Skills: Criar um agente de IA. ","permalink":"https://julianamarialop.github.io/articles/o-salto-de-fe-data-engineer-ai-em-90-dias-ecossistema/","summary":"No universo de Assassin\u0026rsquo;s Creed, o Salto de Fé é um ato de coragem, técnica e confiança. Não é um salto cego, mas um movimento calculado que exige conhecimento do terreno e precisão para alcançar um novo patamar. No…","title":"O Salto de Fé: De Data Engineer a AI Engineer em 90 Dias no Ecossistema Microsoft"},{"content":"Imagine o Microsoft Foundry como um grande estúdio de cinema dedicado à produção de filmes de IA. Em vez de projetores, câmeras e roteiros, ele oferece ferramentas, modelos e infraestrutura para transformar ideias em soluções inteligentes.\nAssim como em uma produção cinematográfica, cada etapa da criação de uma IA exige coordenação, talentos diversos e tecnologia de ponta. É aí que o Foundry brilha, trazendo uma estrutura completa para que qualquer equipe possa criar suas próprias superproduções de inteligência.\nDurante muito tempo, o desenvolvimento de IA foi artesanal. Faltavam dados, o treinamento era caro e a operação dependia de infraestrutura complexa. Agora, com as melhorias do Foundry, esse cenário muda radicalmente. O processo se torna mais ágil, acessível e governado. É como se a IA tivesse finalmente seu próprio estúdio profissional para gravar, editar e lançar grandes produções no ar.\nAssim como um estúdio que investe em novos equipamentos e equipes, o Microsoft Foundry recebeu atualizações que redefinem a forma de produzir IA.\nGeração de Dados Sintéticos: o time de roteiristas do estúdio Todo grande filme começa com um bom roteiro, e um modelo de IA precisa de dados de qualidade para aprender. O Foundry agora permite a criação de conjuntos de dados sintéticos a partir de documentos e códigos existentes.\nÉ como ter roteiristas que, a partir de uma ideia inicial, escrevem novas cenas e diálogos, ampliando o enredo e enriquecendo a história. Da mesma forma, os dados sintéticos ajudam o modelo a aprender com segurança e rapidez, mesmo quando os dados reais são escassos ou sensíveis.\nO resultado é um processo de pré-produção mais eficiente, que permite testar conceitos e treinar modelos de maneira confiável.\nOtimização de Custos no Treinamento: a escola de atores do estúdio Treinar modelos representa o momento em que os atores aprendem o roteiro e ensaiam suas falas. Mas esse processo pode ser caro e demorado.\nA Microsoft está tornando essa etapa mais acessível, oferecendo 50% de desconto no custo de treinamento e ampliando as cotas para desenvolvedores. É como se a escola de atuação do estúdio abrisse bolsas de estudo para novos talentos.\nEssa democratização incentiva mais profissionais a experimentar, ajustar e refinar seus modelos, impulsionando a diversidade e a qualidade das soluções criadas dentro do “set de filmagem” da IA.\nFlexibilidade de Modelos: o elenco internacional do estúdio Nenhum filme seria o mesmo sem o elenco certo. O Foundry traz essa mesma flexibilidade ao integrar modelos de código aberto, como:\nMistral Llama 3.3 OSS-20B Qwen 3 Além dos modelos Claude e GPT disponíveis exclusivamente no Azure.\nÉ como ter à disposição um elenco mundial, onde o diretor pode escolher entre grandes estrelas e talentos independentes, dependendo do papel e do orçamento.\nEssa variedade permite que cada produção de IA seja montada com o elenco ideal para seu propósito, equilibrando custo, performance e conformidade.\nAgentic RFT e Orquestração de Agentes: a direção e a equipe técnica do estúdio A próxima revolução na IA está na criação de agentes autônomos, que não apenas respondem, mas também agem, planejam e executam tarefas complexas.\nCom o Agentic RFT (Reinforcement Fine-Tuning), o modelo GPT-5 aprende a usar ferramentas, seguir raciocínios estruturados e interagir com sistemas externos. Essa evolução transforma um modelo que antes apenas falava em um agente capaz de agir.\nAlém disso, o Microsoft Agent Framework funciona como o sistema de bastidores do estúdio, unindo frameworks como Semantic Kernel e AutoGen.\nOs Hosted Agents permitem lançar agentes em ambiente gerenciado, sem precisar montar toda a infraestrutura técnica do zero.\nEm produções mais complexas, o Foundry introduz workflows multiagente e memória persistente, permitindo que múltiplos especialistas colaborem e mantenham o contexto do projeto ao longo do tempo, como uma equipe de filmagem que conhece cada cena e preserva a coerência do filme.\nConclusão: o estúdio da inteligência do futuro O Microsoft Foundry está se tornando o grande estúdio que produz a nova geração de IA. Ele integra todas as fases da criação, desde a escrita do roteiro até a estreia nos cinemas da inovação.\nCom dados sintéticos, custos acessíveis, liberdade de escolha de modelos e orquestração inteligente de agentes, o Foundry transforma ideias em superproduções de inteligência prontas para brilhar no mundo real.\nO futuro da IA será dirigido, produzido e estreado dentro de estúdios como o Microsoft Foundry, onde cada criador tem as ferramentas certas para transformar sua visão em impacto concreto.\nReferências Microsoft. (2025). What\u0026rsquo;s new in Microsoft Foundry | October and November 2025. https://devblogs.microsoft.com/foundry/whats-new-in-microsoft-foundry-oct-nov-2025/\nMicrosoft. (2025). Microsoft Ignite 2025 Recap: Agentic AI, Foundry, and Azure Innovations. https://azure.microsoft.com/en-us/blog/actioning-agentic-ai-5-ways-to-build-with-news-from-microsoft-ignite-2025/\n","permalink":"https://julianamarialop.github.io/articles/microsoft-foundry-o-estudio-de-cinema-da-nova-era-artificial/","summary":"Imagine o Microsoft Foundry como um grande estúdio de cinema dedicado à produção de filmes de IA. Em vez de projetores, câmeras e roteiros, ele oferece ferramentas, modelos e infraestrutura para transformar ideias em…","title":"Microsoft Foundry: o estúdio de cinema da nova era da Inteligência Artificial"},{"content":"Imagine que você precisa ir de um ponto A a um ponto B. Há algumas décadas, sua única opção era um carro com câmbio manual, exigindo total atenção a cada troca de marcha e a cada movimento no trânsito. Com o tempo, surgiram os carros com câmbio automático, que simplificaram a direção, mas ainda demandavam um motorista atento. Hoje, vivemos a era do piloto automático, onde o carro assume o controle em rodovias, mantendo a velocidade e a faixa, embora o motorista precise estar pronto para intervir a qualquer momento. Agora, imagine um futuro onde você apenas informa o destino, e o carro faz todo o resto: traça a rota, desvia de obstáculos, estaciona e se recarrega sozinho. Um veículo totalmente autônomo.\nEssa mesma jornada evolutiva está acontecendo agora, no coração da engenharia de dados. Por anos, construímos pipelines de dados como quem dirige um carro manual: um trabalho artesanal, que exige codificação detalhada e manutenção constante. Recentemente, passamos para as ferramentas com interfaces visuais e alguma automação, o nosso \u0026ldquo;câmbio automático\u0026rdquo;. Agora, com o advento dos copilotos de IA, entramos na era do \u0026ldquo;piloto automático\u0026rdquo;, onde a IA sugere e auxilia, mas o engenheiro ainda está no comando. Estamos à beira da próxima grande mudança de paradigma: a transição do ETL (Extract, Transform, Load) para o ETL-A, o ETL Autônomo.\nEste não é apenas um upgrade incremental; é uma reimaginação fundamental de como os dados se movem dentro de uma organização. Estamos saindo de um modelo onde os engenheiros supervisionam manualmente cada etapa do processo para um futuro onde sistemas inteligentes, ou agentes, orquestram fluxos de dados com autonomia, adaptabilidade e resiliência. Neste artigo, vamos explorar essa evolução, mergulhar na arquitetura que torna o ETL-A possível e discutir como essa transformação redefine o papel do engenheiro de dados na era da inteligência artificial.\nA Jornada Evolutiva do ETL: Do Manual à Autonomia Total Para entender o impacto do ETL-A, é crucial revisitar a jornada que nos trouxe até aqui. Cada fase da evolução do ETL pode ser comparada a um estágio da tecnologia de condução de veículos, refletindo um aumento progressivo na automação e uma diminuição na intervenção manual.\nETL 1.0: A Condução Manual Na primeira era do ETL, que remonta aos anos 90, as ferramentas eram como os primeiros carros com câmbio manual. Plataformas como Informatica PowerCenter e SQL Server Integration Services (SSIS) dominavam o cenário. Construir um pipeline era um processo meticuloso e altamente técnico. Os engenheiros precisavam definir explicitamente cada transformação, cada mapeamento de campo e cada regra de negócio em código ou em interfaces visuais complexas. A manutenção era constante e reativa; uma pequena mudança no sistema de origem, como a alteração do nome de uma coluna, poderia quebrar todo o fluxo, exigindo dias de depuração e correção manual. Era um trabalho de controle total, mas também de fragilidade e baixa escalabilidade.\nETL 2.0: O Câmbio Automático da Nuvem A ascensão da nuvem marcou a segunda grande onda, o nosso \u0026ldquo;câmbio automático\u0026rdquo;. Ferramentas como Azure Data Factory (ADF), AWS Glue e plataformas SaaS como Fivetran e Stitch simplificaram drasticamente a construção de pipelines. A necessidade de gerenciar servidores foi eliminada, e conectores pré-construídos para centenas de fontes de dados reduziram o esforço de integração. O foco mudou da codificação de baixo nível para a orquestração de fluxos em interfaces visuais. No entanto, a lógica de transformação e a resiliência do pipeline ainda dependiam inteiramente do design do engenheiro. Se um problema ocorresse, a ferramenta poderia alertar sobre a falha, mas a responsabilidade de diagnosticar e consertar ainda era humana.\nETL 3.0: O Piloto Automático Assistido por IA Nos últimos anos, entramos na era do \u0026ldquo;piloto automático\u0026rdquo;, com a infusão de IA nos processos de ETL. Ferramentas como o Databricks e o Matillion começaram a incorporar recursos de machine learning e, mais recentemente, de IA generativa. Esses sistemas podem analisar metadados para sugerir mapeamentos de schema, gerar código SQL a partir de linguagem natural e detectar anomalias em padrões de dados. É o equivalente ao piloto automático que assume o controle em condições ideais, mas ainda exige um engenheiro atento para supervisionar, validar as sugestões da IA e intervir quando surgem cenários inesperados. A carga de trabalho manual é reduzida, mas a responsabilidade final e a tomada de decisão estratégica permanecem com o profissional.\nETL-A: O Carro Totalmente Autônomo Agora, estamos no limiar do ETL Autônomo (ETL-A). Esta não é apenas uma versão mais inteligente do ETL 3.0; é uma mudança fundamental na qual o controle passa do engenheiro para um sistema de agentes de IA colaborativos. Em um paradigma ETL-A, o engenheiro de dados não constrói mais o pipeline passo a passo. Em vez disso, ele declara a intenção: \u0026ldquo;Eu preciso dos dados de vendas da API do Salesforce, enriquecidos com os dados demográficos dos clientes do nosso data warehouse, e entregues em formato de tabela agregada por dia no nosso Lakehouse\u0026rdquo;.\nO sistema de agentes, então, assume a responsabilidade de ponta a ponta:\nPlanejamento: Um agente orquestrador (ou planner) decompõe a solicitação em etapas lógicas. Execução: Ele delega as tarefas a agentes especializados: um agente de conectividade para extrair os dados da API, um agente de transformação para aplicar a lógica de enriquecimento e agregação, e um agente de qualidade para validar os dados. Adaptação: Se a API do Salesforce sofrer uma alteração de schema, o sistema detecta a mudança, ajusta o mapeamento de forma autônoma e continua a execução, documentando a ação. Auto-otimização: Um agente de otimização monitora o custo e a performance do pipeline, reescrevendo uma query ou ajustando a alocação de recursos para garantir a eficiência. Neste novo mundo, o papel do engenheiro de dados evolui de \u0026ldquo;construtor de pipelines\u0026rdquo; para \u0026ldquo;arquiteto de sistemas autônomos\u0026rdquo;, focando em definir os objetivos de negócio, as políticas de governança e os SLAs, enquanto os agentes cuidam da implementação detalhada.\nA Arquitetura do ETL-A: Por Dentro da Mente dos Agentes Um sistema de ETL Autônomo não é uma única aplicação monolítica, mas sim um ecossistema de agentes de IA especializados que colaboram para atingir um objetivo. Inspirado em frameworks como LangChain e AutoGen, a arquitetura de um sistema ETL-A pode ser dividida em camadas que trabalham em conjunto para transformar a intenção do usuário em um fluxo de dados resiliente e eficiente.\nCamada de Interface: Prompt do Usuário / Declaração de Intenção - É onde o engenheiro de dados define o objetivo de negócio em linguagem natural. Assim como o passageiro informa o destino no aplicativo do carro autônomo, aqui você declara o que precisa dos seus dados. Camada de Orquestração: Agente Orquestrador (Planner) - Decompõe a intenção em um plano de ação com várias etapas e seleciona os agentes certos para cada tarefa. Funciona como o sistema de navegação que calcula a rota e envia comandos para o motor, freios e direção. Camada de Execução: Agentes Especializados - Um conjunto de agentes focados em tarefas específicas, que são invocados pelo orquestrador. São os subsistemas do carro: motor, sistema de freios, direção e sensores, cada um especializado em sua função. Camada de Cognição: LLM (Large Language Model) - O \u0026ldquo;cérebro\u0026rdquo; que alimenta o raciocínio dos agentes, permitindo-lhes entender a linguagem, gerar código e tomar decisões. É o computador de bordo que processa os dados dos sensores e toma decisões em tempo real. Camada de Memória: Base de Conhecimento / Vector Database - Onde o sistema armazena o contexto de longo prazo: logs de execuções passadas, schemas, metadados e documentação. Como o mapa e o histórico de rotas que o carro usa para aprender e melhorar. Camada de Ferramentas: Conectores, APIs, Bibliotecas de Código - As ferramentas que os agentes utilizam para interagir com o mundo exterior (sistemas de dados, APIs, etc.). São as rodas, os faróis e os limpadores de para-brisa que o carro usa para interagir com a estrada. O Fluxo de Trabalho de um Pipeline Autônomo Vejamos como essas camadas interagem em um cenário prático. Suponha que um engenheiro de dados declare a seguinte intenção: \u0026ldquo;Preciso de um relatório diário que combine os dados de pedidos do nosso banco de dados PostgreSQL com as avaliações de produtos do Zendesk, e que alerte sobre qualquer produto com uma avaliação média inferior a 3 estrelas.\u0026rdquo;\n1. Declaração da Intenção: O Agente Orquestrador recebe o prompt.\n2. Raciocínio e Planejamento: Usando o LLM, o orquestrador interpreta a solicitação e a quebra em um plano:\nExtrair dados de pedidos da tabela orders no PostgreSQL. Extrair tickets de avaliação da API do Zendesk. Juntar os dois conjuntos de dados pelo product_id. Calcular a avaliação média por produto. Filtrar produtos com avaliação média \u0026lt; 3. Carregar o resultado em uma tabela no Lakehouse. Enviar um alerta para um canal do Slack. 3. Delegação para Agentes Especializados: O orquestrador invoca os agentes necessários:\nUm Agente de Conectividade de Banco de Dados recebe a tarefa de extrair os dados do PostgreSQL. Um Agente de API é encarregado de buscar os dados do Zendesk. Um Agente de Transformação (Spark/dbt) recebe os dados brutos e o código necessário para juntá-los, agregá-los e filtrá-los. Um Agente de Alerta é ativado para enviar a mensagem final no Slack. 4. Adaptação e Auto-correção: Durante a execução, o Agente de API descobre que o Zendesk adicionou um novo campo chamado sentiment_score ao payload. O agente consulta a Base de Conhecimento para ver se essa informação é útil. Ele pode decidir autonomamente enriquecer o resultado com essa nova informação, ou simplesmente ignorá-la, mas em ambos os casos, ele registra sua decisão na memória para futuras execuções. Se o pipeline falhar por um erro de conexão, o agente pode tentar novamente algumas vezes antes de escalar o problema para um humano.\n5. Conclusão e Aprendizado: Após a execução bem-sucedida, os logs, o código gerado e o resultado são armazenados na Base de Conhecimento. Isso permite que o sistema aprenda com a experiência, otimizando execuções futuras e tornando-se mais eficiente com o tempo.\nO Futuro do Engenheiro de Dados: De Construtor a Maestro A ascensão do ETL-A não significa o fim da engenharia de dados; pelo contrário, ela eleva a profissão a um patamar mais estratégico e criativo. O tempo que antes era gasto em tarefas repetitivas e reativas de codificação e depuração de pipelines será liberado para atividades de maior valor agregado.\nO engenheiro de dados do futuro será menos um \u0026ldquo;mecânico de carros\u0026rdquo; e mais um \u0026ldquo;engenheiro de sistemas de transporte urbano\u0026rdquo;. Suas responsabilidades se concentrarão em:\nDesign de Sistemas Autônomos: Projetar e configurar os ecossistemas de agentes, definindo suas capacidades, permissões e regras de colaboração. Governança e Política: Estabelecer as políticas de qualidade de dados, segurança e privacidade que os agentes devem seguir. Em vez de implementar as regras, o engenheiro as declarará para que os agentes as executem. Otimização de Custo e Performance: Monitorar a eficiência do sistema de agentes, ajustando os modelos de custo e os objetivos de performance para garantir que os recursos da organização sejam usados da melhor forma possível. Inovação em Produtos de Dados: Focar em entender as necessidades do negócio e projetar novos produtos de dados, deixando a implementação a cargo dos agentes. Em essência, o engenheiro de dados se tornará um maestro, regendo uma orquestra de agentes de IA para criar sinfonias de dados complexas e harmoniosas, em vez de tocar cada instrumento individualmente.\nConclusão: Abrace a Autonomia A jornada do ETL manual para o ETL Autônomo é mais do que uma evolução tecnológica; é uma mudança na nossa filosofia de trabalho. Assim como o carro autônomo promete revolucionar o transporte, o ETL-A promete transformar a maneira como as organizações utilizam seus dados, tornando o processo mais ágil, resiliente e inteligente.\nO termo ETL-A pode ser novo, mas a tendência que ele representa é inegável. Estamos nos movendo para um futuro onde a interação com os dados será baseada na intenção, não na implementação. Para os engenheiros de dados, este é um momento de oportunidade única. Aqueles que abraçarem essa mudança e começarem a desenvolver as habilidades necessárias para projetar e governar sistemas autônomos não apenas sobreviverão à próxima onda de automação, mas se tornarão os arquitetos indispensáveis da empresa orientada por dados do futuro. A pergunta não é mais se os pipelines de dados se tornarão autônomos, mas quão rápido podemos chegar lá. E a resposta, ao que tudo indica, é: mais rápido do que imaginamos.\nReferências Naeem, H. (2025). \u0026ldquo;Future of ETL: Why Agentic AI Is the Next Big Shift in Data Engineering\u0026rdquo;. Medium. Disponível em:\nHossain, M. (2025 ). \u0026ldquo;AI Agents for Data Pipelines: Self-Healing and Self-Optimizing Workflows\u0026rdquo;. Medium. Disponível em:\nDatabricks Staff. (2025 ). \u0026ldquo;AI ETL: How Artificial Intelligence Automates Data Pipelines\u0026rdquo;. Databricks Blog. Disponível em:\nMatillion. (2025 ). \u0026ldquo;Moving Toward Autonomous Data Systems with Agentic Intelligence\u0026rdquo;. Matillion Blog. Disponível em:\nIBM. (2025 ). \u0026ldquo;LLM Agent Orchestration: A Step by Step Guide\u0026rdquo;. IBM Think Tutorials. Disponível em:\nLangChain. (2025 ). \u0026ldquo;LangGraph: Build Agents That Automate Real-World Tasks\u0026rdquo;. LangChain Documentation. Disponível em:\n","permalink":"https://julianamarialop.github.io/articles/de-etl-para-etl-a-ascensao-dos-pipelines-autonomos-e-o/","summary":"Imagine que você precisa ir de um ponto A a um ponto B. Há algumas décadas, sua única opção era um carro com câmbio manual, exigindo total atenção a cada troca de marcha e a cada movimento no trânsito. Com o tempo…","title":"De ETL para ETL-A: A Ascensão dos Pipelines Autônomos e o Futuro da Engenharia de Dados"},{"content":"Você já tentou explicar para um cliente quanto vai custar um projeto de software e ouviu: \u0026ldquo;Mas por que demora tanto?\u0026rdquo; ou \u0026ldquo;Por que custa isso tudo?\u0026rdquo;. A dificuldade está em traduzir funcionalidade em tamanho, e tamanho em esforço. Durante décadas, a indústria de software tentou resolver esse problema contando linhas de código, mas isso é como medir um apartamento pela quantidade de tijolos: tecnicamente possível, mas completamente inútil para quem precisa entender o que está comprando.\nImagine que você está procurando um apartamento. O corretor não te mostra quantos tijolos foram usados na construção ou quantos sacos de cimento entraram na obra. Ele te diz: 80 metros quadrados, 3 quartos, 2 banheiros, sala integrada com a cozinha. Você imediatamente entende o tamanho e a funcionalidade do espaço. Essa é exatamente a proposta dos Pontos de Função: uma medida universal que expressa o tamanho de um software pela perspectiva de quem vai usá-lo, independente da tecnologia de construção.\nEste artigo desmistifica a Análise de Pontos de Função (APF), uma métrica internacional criada há quase 50 anos e que continua sendo uma das formas mais confiáveis de medir software . Vamos entender o que são pontos de função, como funcionam na prática, por que são independentes de tecnologia e como podem transformar a forma como você estima e gerencia projetos.\nO Problema da Medição de Software Imagine tentar comparar dois apartamentos onde um foi construído com tijolos cerâmicos e outro com blocos de concreto. Se você medir pela quantidade de material, vai chegar a números completamente diferentes, mesmo que os apartamentos tenham exatamente o mesmo tamanho e funcionalidade. O mesmo acontece quando medimos software por linhas de código: um sistema em Python pode ter 1000 linhas, o mesmo sistema em Java pode ter 3000 linhas, mas ambos entregam a mesma funcionalidade ao usuário.\nÉ por isso que a indústria de software precisava de uma medida universal, algo que focasse no \u0026ldquo;o quê\u0026rdquo; e não no \u0026ldquo;como\u0026rdquo;. Sem um padrão, as estimativas se tornam subjetivas, a comparação de produtividade entre equipes é impossível e a negociação de contratos vira um exercício de adivinhação.\nO Que São Pontos de Função? Pontos de Função são como os metros quadrados da construção civil. Não importa se a casa foi feita de madeira, tijolo ou concreto. Não importa se o acabamento é luxuoso ou simples. Os metros quadrados medem o espaço funcional disponível. Da mesma forma, Pontos de Função medem a funcionalidade disponível para o usuário, independente de ser desenvolvido em Java, Python, .NET ou qualquer outra tecnologia.\nCriada por Allan Albrecht na IBM em 1977, a Análise de Pontos de Função é hoje um padrão ISO/IEC . Seu princípio fundamental é medir o software pela visão do usuário, quantificando os requisitos funcionais que o sistema entrega.\nOs Cinco Cômodos do Software: Componentes da Contagem Quando um arquiteto mede um apartamento, ele não conta apenas os metros quadrados totais. Ele identifica os cômodos: quantos quartos, quantos banheiros, se tem varanda. Cada tipo de cômodo tem um valor. Da mesma forma, na contagem de Pontos de Função, identificamos os \u0026ldquo;cômodos funcionais\u0026rdquo; do software, que se dividem em dois tipos: Funções de Dados e Funções de Transação.\nFunções de Dados (Onde guardamos as coisas):\nArquivos Lógicos Internos (ALI): Pense neles como os armários embutidos dentro do seu apartamento. São grupos de dados mantidos pela própria aplicação (ex: tabela de clientes, tabela de produtos). Arquivos de Interface Externa (AIE): São como os armários compartilhados no corredor do prédio. São dados que sua aplicação lê, mas que são mantidos por outro sistema (ex: uma tabela de CEPs mantida por um sistema dos Correios). Funções de Transação (O que fazemos nos cômodos):\nEntradas Externas (EE): É a porta de entrada do seu apartamento. É qualquer processo que permite ao usuário colocar informações para dentro do sistema, alterando o estado de um armário interno (ex: um formulário de cadastro de cliente). Saídas Externas (SE): É uma janela com uma vista elaborada. Apresenta ao usuário informações que foram processadas, calculadas ou derivadas (ex: um relatório de vendas do mês com totais e médias). Consultas Externas (CE): É como um espelho. Apenas reflete uma informação que já existe, sem nenhum processamento complexo. É uma busca simples que apresenta dados de um armário interno ou externo (ex: uma tela que busca e exibe os dados de um cliente específico). A Complexidade: Apartamento Simples ou Cobertura Duplex? Dois apartamentos podem ter 80 metros quadrados, mas um pode ser um estúdio simples (baixa complexidade) e outro um loft com mezanino e cozinha gourmet (alta complexidade). No Pontos de Função, medimos essa complexidade analisando quantos \u0026ldquo;elementos\u0026rdquo; cada funcionalidade manipula e quantos \u0026ldquo;arquivos\u0026rdquo; ela acessa.\nCada um dos cinco componentes (ALI, AIE, EE, SE, CE) é classificado como de complexidade Baixa, Média ou Alta, e cada combinação tem um peso em pontos de função, conforme a tabela abaixo:\nTabela 1: Contribuição em Pontos de Função por Complexidade\n_Contribuição em Pontos de Função por Complexidade_\nMas como saber se é Baixa, Média ou Alta? Aqui entram as regras de classificação:\nPara Funções de Dados (ALI e AIE):\nA complexidade depende de dois fatores:\nDER (Dados Elementares Referenciados): Cada campo único reconhecido pelo usuário. Por exemplo, em uma tabela de Clientes: Nome, CPF, Email, Telefone = 4 DERs. RLR (Registros Lógicos Referenciados): Subgrupos de dados dentro de um arquivo. Na maioria dos casos simples, é 1. Aumenta quando há subtipos ou relacionamentos opcionais. Tabela 2: Matriz de Complexidade para ALI e AIE\n_Matriz de Complexidade para ALI e AIE_\nPara Funções Transacionais (EE, SE, CE):\nA complexidade depende de:\nDER (Dados Elementares Referenciados): Campos que o usuário pode informar ou visualizar na transação. ALR (Arquivos Lógicos Referenciados): Quantos ALIs ou AIEs a transação lê ou atualiza. Tabela 3: Matriz de Complexidade para EE\n_Matriz de Complexidade para EE_\nTabela 4: Matriz de Complexidade para SE e CE\n_Matriz de Complexidade para SE e CE_\nExemplo Prático: Medindo um Sistema de Cadastro Vamos medir a \u0026ldquo;planta baixa\u0026rdquo; de um sistema de cadastro de clientes. Ele tem um \u0026ldquo;armário\u0026rdquo; (tabela de clientes), uma \u0026ldquo;porta de entrada\u0026rdquo; (formulário de cadastro), uma \u0026ldquo;janela com vista elaborada\u0026rdquo; (relatório de clientes) e um \u0026ldquo;espelho\u0026rdquo; (consulta de cliente).\n1. Identificar Funções:\nTabela de Clientes: 1 ALI Formulário de Cadastro: 1 EE Relatório de Clientes: 1 SE Consulta de Cliente por CPF: 1 CE 2. Determinar Complexidade:\nALI - Tabela de Clientes:\nCampos: Nome, CPF, Email, Telefone, Endereço, Cidade, Estado = 7 DERs Subgrupos: 1 RLR (apenas a tabela principal) Consultando Tabela 2: 7 DERs + 1 RLR = Baixa (7 PF) EE - Formulário de Cadastro:\nCampos informados: Nome, CPF, Email, Telefone, Endereço, Cidade, Estado = 7 DERs (mas como são menos de 15, contamos como está) Arquivos acessados: 1 ALR (grava na tabela de Clientes) Consultando Tabela 3: 7 DERs (entre 5-15) + 1 ALR = Baixa (3 PF) SE - Relatório de Clientes:\nCampos exibidos: Nome, CPF, Email, Cidade + Total de Clientes = 5 DERs Arquivos lidos: 1 ALR (lê a tabela de Clientes) Consultando Tabela 4: 5 DERs (entre 1-5) + 1 ALR = Baixa (4 PF) CE - Consulta por CPF:\nCampos exibidos: Nome, CPF, Email, Telefone, Endereço = 5 DERs Arquivos lidos: 1 ALR (lê a tabela de Clientes) Consultando Tabela 4: 5 DERs (entre 1-5) + 1 ALR = Baixa (3 PF) 3. Somar Total:\nTamanho Total = 7 + 3 + 4 + 3 = 17 Pontos de Função Pronto! O nosso \u0026ldquo;apartamento digital\u0026rdquo; tem um tamanho de 17 Pontos de Função. Agora você entende não apenas o resultado, mas como chegamos nele.\nPara Que Serve Saber o Tamanho? Quando você sabe que um apartamento tem 80m², pode estimar quanto vai custar o piso, quanto tempo leva para pintar e quantos móveis cabem. Da mesma forma, sabendo que um sistema tem 200 pontos de função e que sua equipe entrega, em média, 5 PF por semana, você pode estimar que o projeto levará 40 semanas. A APF permite:\nEstimar prazo e custo com base em dados históricos. Medir e comparar a produtividade de equipes (PF/hora). Criar contratos baseados em preço por ponto de função. Fazer benchmarking entre projetos e fornecedores. Pontos de Função em Projetos de Analytics e Data Warehouse E quando o \u0026ldquo;apartamento\u0026rdquo; não é um sistema tradicional, mas um Data Warehouse ou um projeto de analytics? A boa notícia é que os princípios continuam válidos, mas precisam de adaptações. O governo brasileiro publicou um guia específico para contagem de Pontos de Função em projetos de Data Warehouse, reconhecendo que o modelo multidimensional (tabelas Fato e Dimensão) tem características próprias.\nEm um projeto de DW, cada tabela Fato e cada tabela Dimensão são contadas como ALIs. O processo de ETL (Extração, Transformação e Carga) é contado como uma Entrada Externa (EE), pois traz dados de fora e alimenta os armários internos. Já os relatórios e dashboards são contados como Saídas Externas (SE) quando envolvem cálculos e agregações, ou Consultas Externas (CE) quando apenas apresentam dados sem processamento complexo.\nO desafio aqui é que o esforço de desenvolvimento do ETL costuma ser significativamente maior que o de criar relatórios, mas ambos podem ter contagens de PF similares. Por isso, muitos contratos de DW separam os lotes de ETL e OLAP, reconhecendo que a complexidade técnica é diferente, mesmo que o tamanho funcional seja parecido.\nE os Agentes de IA? Como Medir? Agora vem a pergunta do momento: como aplicar Pontos de Função em projetos de agentes de IA? Não existe ainda um guia oficial, mas podemos aplicar os mesmos princípios fundamentais: medir pela visão do usuário, identificar onde os dados são armazenados e quais operações o usuário pode realizar.\nFunções de Dados em Agentes de IA:\nBase de conhecimento do agente: Se o agente tem documentos indexados ou uma base de conhecimento própria, isso é um ALI (armário interno). Vector database: Os embeddings armazenados são um ALI. Cada coleção de embeddings pode ser considerada um arquivo lógico. APIs externas consultadas: Se o agente consulta APIs de terceiros (clima, cotações, etc.), essas são AIEs (armários externos). Histórico de conversas: Se o agente mantém memória de interações anteriores, isso é um ALI. Funções Transacionais em Agentes de IA:\nPrompt do usuário: Cada tipo de interação que o usuário pode fazer é uma EE (porta de entrada). Resposta com RAG (Retrieval-Augmented Generation): É uma SE (janela com vista elaborada), pois envolve busca semântica, processamento e geração de resposta. Consulta simples sem processamento: Se o agente apenas recupera e exibe informação sem elaboração, é uma CE (espelho). Function calling: Quando o agente executa uma ação (reservar um horário, enviar um email), isso é uma EE, pois altera o estado de um sistema. Ingestão de documentos: O processo de chunking, geração de embeddings e armazenamento é uma EE (processo de carga, similar ao ETL). Exemplo: Agente de Atendimento ao Cliente\n1 ALI: Base de conhecimento (FAQs, manuais) 1 ALI: Vector database com embeddings 1 ALI: Histórico de conversas 1 AIE: Sistema de tickets (consultado mas não mantido pelo agente) 1 EE: Usuário faz uma pergunta 1 SE: Agente responde usando RAG (busca + processamento + geração) 1 EE: Agente cria um ticket no sistema externo Assumindo complexidade baixa para simplificar: 7 + 7 + 7 + 5 + 3 + 4 + 3 = 36 Pontos de Função.\nImportante: essa é uma aplicação interpretativa dos princípios de PF. Como a tecnologia de agentes de IA é recente, ainda não há um padrão consolidado. Mas o exercício de pensar em termos de funcionalidade visível ao usuário continua sendo valioso.\nLimitações Importantes Metros quadrados não te dizem se o apartamento tem boa iluminação, se a vista é bonita ou se os acabamentos são de qualidade. Da mesma forma, Pontos de Função não medem se o código é bem escrito, se a arquitetura é elegante ou se o sistema é performático. É apenas uma medida de tamanho funcional. É uma ferramenta poderosa, mas não é a única.\nConclusão A indústria de software amadureceu quando percebeu que precisava de medidas universais, assim como a construção civil tem metros quadrados e quilômetros. Pontos de Função não são perfeitos, mas são uma linguagem comum que permite conversas honestas entre clientes e desenvolvedores. Quando você diz \u0026ldquo;este projeto tem 500 pontos de função\u0026rdquo;, está dizendo algo concreto, comparável e independente de tecnologia.\nA próxima vez que alguém te perguntar \u0026ldquo;quanto vai custar esse sistema?\u0026rdquo;, você não precisa mais chutar no escuro. Você pode medir a planta baixa, contar os cômodos e dar uma resposta fundamentada. E isso, por si só, já é uma revolução.\nReferências Vazquez, C. E., \u0026amp; Simões, G. S. (2013). Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de Software. Editora Saraiva.\nISO/IEC 20926:2009. Software and systems engineering — Software measurement — IFPUG functional size measurement method 2009.\nMinistério do Planejamento, Orçamento e Gestão (2015). Guia de Contagem de Pontos de Função do SISP para Projetos Data Warehouse. Brasília: MP.\n","permalink":"https://julianamarialop.github.io/articles/planta-baixa-do-software-desmistificando-analise-de-pontos/","summary":"Você já tentou explicar para um cliente quanto vai custar um projeto de software e ouviu: \u0026ldquo;Mas por que demora tanto?\u0026rdquo; ou \u0026ldquo;Por que custa isso tudo?\u0026rdquo;. A dificuldade está em traduzir funcionalidade em tamanho, e tamanho em…","title":"A Planta Baixa do Software: Desmistificando a Análise de Pontos de Função"},{"content":"A profissão de engenheiro de dados está passando por sua maior transformação desde a migração para a nuvem. Durante anos, o foco esteve em construir pipelines eficientes, mover dados de um ponto a outro e garantir que tudo estivesse organizado em data warehouses. Mas algo fundamental mudou: os dados não são mais consumidos apenas por humanos escrevendo queries SQL ou criando dashboards. Agora, uma nova categoria de consumidores surgiu: agentes de IA autônomos que precisam descobrir, entender e utilizar dados sem intervenção humana.\nImagine uma biblioteca tradicional onde o bibliotecário organiza livros em prateleiras, cataloga tudo com precisão e espera que os visitantes saibam exatamente o que procuram. Agora, imagine transformar essa biblioteca em um espaço inteligente, onde assistentes autônomos podem navegar pelos corredores, entender o contexto de cada pergunta, conectar informações de diferentes seções e até mesmo antecipar necessidades. Essa é a jornada que engenheiros de dados estão fazendo: de organizadores de informação para arquitetos de sistemas inteligentes.\nEste artigo explora o novo papel do AI Data Engineer e as habilidades essenciais que profissionais precisam desenvolver para prosperar nesta nova era. Vamos mergulhar nas competências que vão além dos pipelines tradicionais, incluindo a construção de agentes de IA, a engenharia de contexto e a criação de sistemas que servem tanto humanos quanto máquinas inteligentes.\nA Grande Mudança: De Pipelines para Sistemas de Contexto O paradigma tradicional da engenharia de dados assumia um humano no final do processo. Esse humano trazia consigo anos de conhecimento institucional, a capacidade de fazer perguntas a colegas e a intuição para fazer suposições razoáveis. Os agentes de IA, nossos novos consumidores de dados, não possuem nenhuma dessas vantagens. Eles precisam de sistemas que não apenas entreguem dados, mas que também expliquem o que esses dados significam.\nÉ aqui que a engenharia de dados evolui de simplesmente \u0026ldquo;mover dados\u0026rdquo; para \u0026ldquo;criar significado\u0026rdquo;. Antes, bastava organizar os livros por categoria e número de catálogo. Agora, cada livro precisa vir com um guia completo: a biografia do autor, as referências cruzadas, as edições anteriores, quem já leu, para que usou e até mesmo as anotações nas margens que revelam insights valiosos. Sem esse contexto, para um agente de IA, os dados são apenas uma coleção de fatos desconexos e inutilizáveis.\nContext Engineering: A Nova Habilidade Fundamental A habilidade mais crítica para o engenheiro de dados em 2026 é a Engenharia de Contexto . Trata-se da prática de projetar sistemas que incorporam um contexto rico e legível por máquina junto com os próprios dados. Isso vai muito além da documentação tradicional ou dos catálogos de dados. A engenharia de contexto possui várias dimensões:\nContexto Semântico: O que os dados realmente significam para o negócio? Um \u0026ldquo;cliente\u0026rdquo; no sistema de vendas é o mesmo que um \u0026ldquo;cliente\u0026rdquo; no sistema de suporte? Contexto Temporal: Quando os dados foram criados e atualizados? Qual era o estado do mundo naquele momento? Contexto Relacional: Como este conjunto de dados se conecta a outros? Quais junções são significativas e quais produziriam resultados sem sentido? Contexto de Qualidade: Quão confiáveis são esses dados? Quais são suas limitações conhecidas? Contexto de Proveniência: De onde vieram os dados e por quais transformações passaram? Implementar essa camada de contexto é como criar um sistema de catalogação que não apenas diz onde está cada livro, mas conta sua história completa, tornando a biblioteca navegável para uma inteligência artificial.\nVector Databases e a Revolução da Busca Semântica Se o contexto é a história, os Vector Databases são a tecnologia que permite que os agentes de IA a entendam em escala. Essas bases de dados, que antes eram um nicho para equipes de machine learning, agora são parte da infraestrutura central da engenharia de dados. Elas se destacam na busca por similaridade e relevância, descobrindo conexões que não foram explicitamente modeladas.\nImagine que, em vez de procurar livros apenas por título ou autor, você pudesse perguntar à biblioteca: \u0026ldquo;Preciso entender como resolver problemas de escalabilidade em sistemas distribuídos\u0026rdquo;. Um sistema de busca semântica, alimentado por embeddings e um vector database, encontraria não apenas livros com essas palavras-chave, mas também artigos relacionados, casos de uso similares e discussões em fóruns que abordam o mesmo desafio. Essa é a revolução que os AI Data Engineers precisam dominar, combinando busca vetorial com filtros de metadados tradicionais no que é conhecido como hybrid search.\nConstruindo Agentes de IA: De Consumidor a Criador A fronteira final para o AI Data Engineer é a construção dos próprios agentes de IA. Não se trata mais apenas de preparar dados para outros, mas de criar os assistentes inteligentes que os utilizarão. Um agente de IA é mais do que um chatbot; é um sistema que pode planejar, usar ferramentas e interagir com fontes de dados para completar tarefas complexas de forma autônoma .\nConstruir um agente robusto envolve um processo estruturado:\nDefinir o escopo e as ações permitidas. Mapear e conectar as fontes de dados necessárias. Construir a camada de recuperação e contexto (RAG). Escolher o LLM e o estilo de raciocínio (e.g., ReAct). Criar ferramentas que o agente pode usar (function calling). Adicionar memória para manter o contexto entre as interações. Implementar guardrails e observabilidade para garantir a segurança e o monitoramento. É aqui que o engenheiro de dados se torna um verdadeiro arquiteto de inteligência, treinando assistentes especializados e dando-lhes as ferramentas para não apenas buscar informação, mas também executar ações, como criar resumos, reservar recursos ou conectar usuários a especialistas.\nO Toolkit do AI Data Engineer Para navegar neste novo cenário, um conjunto de ferramentas poderosas está emergindo. Plataformas como Microsoft Fabric com seus Data Agents, o Azure AI Foundry e o Databricks Agent Framework com MLflow oferecem ecossistemas integrados para construir, treinar e gerenciar agentes. Frameworks como LangChain e LlamaIndex fornecem os blocos de construção, enquanto uma nova geração de vector databases como Pinecone, Weaviate e Azure AI Search se tornam essenciais.\nPlataformas All-in-One:\nMicrosoft Fabric: Ambiente integrado que combina data engineering, data science e analytics com Data Agents nativos Azure AI Foundry: Plataforma completa para build, deploy e gerenciamento de soluções de IA Databricks: Ecossistema unificado de dados e IA com Agent Framework e MLflow integrados Frameworks de Agentes:\nLangChain: Framework versátil e extenso para construção de agentes e workflows complexos LlamaIndex: Especializado em RAG e indexação de dados para agentes de retrieval Vector Databases:\nAzure AI Search: Busca híbrida (vetorial + keyword) integrada ao ecossistema Azure Pinecone: Solução managed de alta performance para produção Weaviate: Suporte multi-modal e capacidades avançadas de schema Qdrant: Open-source, ideal para self-hosting e customização MLOps e Monitoramento:\nMLflow: Gerenciamento completo do ciclo de vida de modelos e agentes, com evaluation nativa Azure Monitor: Observabilidade e monitoring integrado para soluções Azure O Roadmap de Transição: Por Onde Começar A boa notícia é que as habilidades fundamentais da engenharia de dados continuam sendo a base. O caminho para se tornar um AI Data Engineer não é sobre abandonar o que você sabe, mas sobre construir em cima disso. Aqui está um roadmap prático para iniciar sua jornada:\nFase 1: Fundamentos de IA e Machine Learning (2-4 semanas) Antes de construir agentes, é essencial entender como a IA funciona. Comece com os conceitos básicos de LLMs, embeddings e prompt engineering. A Microsoft oferece o AI Engineer Career Path no Microsoft Learn, um caminho estruturado que cobre desde a introdução à IA até conceitos avançados. Para quem trabalha com Databricks, o curso gratuito Generative AI Fundamentals é um excelente ponto de partida.\nO que aprender:\nComo funcionam os Large Language Models O que são embeddings e como são gerados Conceitos de prompt engineering Introdução ao RAG (Retrieval-Augmented Generation) Fase 2: Explorando Vector Databases e Busca Semântica (2-3 semanas) Com os fundamentos estabelecidos, é hora de entender como armazenar e recuperar informação de forma inteligente. Experimente com Azure AI Search ou outras vector databases. O módulo de Azure AI Search no Microsoft Learn oferece uma introdução prática.\nO que construir:\nUm sistema simples de busca semântica sobre documentação técnica Experimente diferentes estratégias de chunking Compare busca vetorial pura com hybrid search Fase 3: Construindo Seu Primeiro Agente (3-4 semanas) Agora vem a parte mais empolgante: construir um agente de IA do zero. A Microsoft oferece o learning path Develop AI agents on Azure, que cobre desde a criação até o deploy de agentes. No ecossistema Databricks, o curso AI Agent Fundamentals introduz o Mosaic AI e o Agent Framework.\nProjeto prático sugerido:\nCrie um agente que responda perguntas sobre a documentação interna da sua empresa Implemente function calling para que o agente possa consultar APIs Adicione memória para manter contexto entre conversas Para implementação prática, o tutorial oficial do Databricks oferece um guia completo para construir, avaliar e fazer deploy de um agente de retrieval.\nFase 4: Fabric Data Agents e Integração Corporativa (2-3 semanas) Se você trabalha no ecossistema Microsoft, explore como criar Fabric Data Agents para conectar agentes diretamente a lakehouses e warehouses. O tutorial end-to-end mostra como configurar um agente completo.\nO que explorar:\nIntegração de agentes com Power BI e Microsoft Fabric Consumo de Data Agents no Azure AI Foundry Orquestração multi-agente com Copilot Studio Fase 5: MLOps para Agentes e Produção (Contínuo) Agentes em produção precisam de monitoramento, avaliação e governança. Aprenda a usar MLflow para avaliar e monitorar agentes e implemente práticas de observabilidade.\nHabilidades essenciais:\nLogging e tracing de agentes Métricas de qualidade e custo A/B testing de diferentes versões Guardrails e segurança A Biblioteca Viva do Futuro O papel do engenheiro de dados está evoluindo de um construtor de pipelines para um arquiteto de inteligência. Não se trata de uma mudança de profissão, mas de uma expansão poderosa de seu escopo. A biblioteca do futuro não é apenas um repositório de informação, mas um ecossistema vivo de conhecimento que se adapta, aprende e evolui. Os profissionais que abraçarem essa transformação não estarão apenas acompanhando a mudança, estarão liderando a próxima geração de sistemas de dados inteligentes.\nA jornada pode parecer desafiadora, mas cada passo constrói sobre o anterior. Começar é mais simples do que parece: escolha uma fase do roadmap, reserve algumas horas por semana e mergulhe em um projeto prático. A diferença entre um engenheiro de dados tradicional e um AI Data Engineer não está apenas no conhecimento técnico, mas na capacidade de pensar em sistemas que criam significado, não apenas movem bytes. E essa transformação começa agora, com o próximo curso que você iniciar, o primeiro agente que você construir, a primeira vez que você enriquecer seus dados com contexto rico e machine-readable. O futuro da engenharia de dados não é sobre substituir o que fazemos, mas sobre amplificar nosso impacto de formas que antes eram inimagináveis.\nReferências Panda, S. (2025). The 2026 Data Engineering Roadmap: Building Data Systems for the Agentic AI Era. Medium. Airbyte Engineering Team. (2025). A Guide to Building AI Agents. Airbyte. Microsoft. (2025). Fabric data agent concepts (preview). Microsoft Learn. Microsoft. (2025). Microsoft Foundry. Azure. Databricks. (2025). Evaluate and monitor AI agents. Databricks Documentation. ","permalink":"https://julianamarialop.github.io/articles/ai-data-engineer-evolucao-do-engenheiro-de-dados-na-era/","summary":"A profissão de engenheiro de dados está passando por sua maior transformação desde a migração para a nuvem. Durante anos, o foco esteve em construir pipelines eficientes, mover dados de um ponto a outro e garantir que…","title":"AI Data Engineer: A Evolução do Engenheiro de Dados na Era dos Agentes Inteligentes"},{"content":"Por anos, o mundo dos dados perseguiu o sonho de uma \u0026ldquo;única fonte da verdade\u0026rdquo;. No entanto, na prática, o que muitas empresas construíram foi uma verdadeira Torre de Babel. Cada departamento, cada equipe, cada analista criou seu próprio dialeto, suas próprias definições para métricas essenciais. O resultado? Relatórios conflitantes, decisões baseadas em números divergentes e uma desconfiança generalizada nos dados. Dez relatórios de vendas mostravam dez números diferentes para \u0026ldquo;receita líquida\u0026rdquo;, e ninguém sabia qual era o correto.\nO Microsoft Fabric IQ, uma das novidades mais impactantes do Ignite 2025, não é apenas mais uma ferramenta nesse cenário; ele é a solução arquitetural para demolir essa Torre de Babel. Ele foi projetado para resolver a causa raiz do problema: a ausência de um dicionário central e governado para a linguagem do negócio. O Fabric IQ propõe uma mudança de paradigma: em vez de replicar a lógica de negócio em cada relatório e modelo, vamos defini-la uma única vez, em um único lugar, e fazer com que todo o ecossistema de relatórios de BI a agentes de IA beba dessa mesma fonte.\nNeste artigo, vamos mergulhar fundo no que é o Fabric IQ, desmembrando seus componentes, explicando como ele funciona tecnicamente e, o mais importante, qual o impacto transformador que ele traz para a arquitetura de dados e para a forma como as empresas tomarão decisões no futuro. É o fim da era da ambiguidade e o começo da era da clareza semântica.\nO que é, de Fato, o Fabric IQ? Se a Torre de Babel corporativa foi construída sobre a falta de uma linguagem comum, o Fabric IQ chega para ser o dicionário universal e o tradutor oficial dessa nova era. Imagine que cada departamento (Vendas, Marketing, Finanças) falava um dialeto diferente, tornando a comunicação impossível. O Fabric IQ não apenas cria um idioma único e oficial para toda a empresa, mas também garante que todos o falem fluentemente, eliminando a confusão e a ambiguidade de uma vez por todas.\nTecnicamente, o Fabric IQ é a camada de inteligência semântica do Microsoft Fabric. Ele centraliza a lógica de negócio em um novo item de primeira classe no Fabric chamado Ontology. Uma ontologia é, essencialmente, um modelo formal do seu negócio. É onde você define o que são as \u0026ldquo;coisas\u0026rdquo; importantes (entidades como Cliente, Produto, Venda), como elas se relacionam entre si (um Cliente faz uma Venda, uma Venda contém um Produto) e quais são as regras e hierarquias que as governam.\nO poder do Fabric IQ vem de seus cinco componentes integrados, que trabalham em conjunto para dar vida a essa ontologia:\nOntology: O \u0026ldquo;plano mestre\u0026rdquo; ou o \u0026ldquo;DNA\u0026rdquo; do negócio. Define as entidades, relacionamentos e regras. Semantic Model: A camada de análise sobre o plano mestre. Adiciona as métricas, KPIs e cálculos (DAX) que serão usados em relatórios. Graph: O sistema de conexões. Permite consultas complexas que atravessam os relacionamentos definidos na ontologia. Data Agent: O \u0026ldquo;tradutor\u0026rdquo; inteligente. Usa a ontologia para entender perguntas em linguagem natural e encontrar respostas nos dados. Operations Agent: O \u0026ldquo;guardião\u0026rdquo; autônomo. Monitora os dados em tempo real e toma ações com base nas regras definidas na ontologia. A Anatomia do Fabric IQ: Mergulhando nos 5 Componentes Para entender o impacto do Fabric IQ, é preciso entender como cada uma de suas partes funciona.\n1. Ontology: A Fundação de Tudo A Ontology é o coração do Fabric IQ. É aqui que a mágica começa. Em vez de modelar dados em tabelas e colunas, você passa a modelar o negócio em entidades e relacionamentos. A grande vantagem é que isso pode ser feito de forma low-code, permitindo que usuários de negócio colaborem com a equipe técnica para criar um modelo que realmente reflita a realidade da empresa. Uma capacidade chave é a geração automática de ontologias a partir de modelos semânticos do Power BI já existentes, o que significa que você pode reutilizar o trabalho já feito e acelerar a adoção.\n_Fabric IQ Ontology_\n2. Semantic Model: A Lente do BI sobre o Negócio Se a Ontology é o mapa do tesouro, o Semantic Model são as ferramentas que você usa para interpretá-lo. É aqui que a lógica de BI tradicional, como métricas complexas em DAX, KPIs e perspectivas de análise, é adicionada sobre a ontologia. A diferença crucial é que essa lógica é construída sobre um modelo de negócio consistente e governado, e não sobre tabelas soltas. Isso garante que, quando você cria um KPI de \u0026ldquo;Crescimento de Vendas\u0026rdquo;, a definição de \u0026ldquo;Venda\u0026rdquo; é a mesma para todos.\n3. Graph: O Poder das Conexões O Fabric IQ não armazena apenas as entidades; ele entende profundamente como elas se conectam. O componente Graph é um motor de grafo nativo que permite fazer perguntas que seriam extremamente complexas em um modelo relacional tradicional. Por exemplo, você pode facilmente atravessar múltiplos relacionamentos para responder a uma pergunta como: \u0026ldquo;Mostre-me todos os clientes que compraram o produto X, que tiveram um problema de entrega reportado pelo sensor Y na cadeia de frio, e que abriram um ticket de suporte nas últimas 24 horas\u0026rdquo;. O grafo torna o raciocínio entre domínios uma capacidade nativa.\n4. Data Agent: O Analista Virtual Os Data Agents são o rosto do Fabric IQ para o usuário final. São agentes de IA que você pode consultar em linguagem natural. Como eles são \u0026ldquo;criados\u0026rdquo; sobre a Ontology, eles já nascem com um profundo conhecimento do seu negócio. Quando um usuário pergunta \u0026ldquo;Quais foram meus clientes mais rentáveis no Brasil no último trimestre?\u0026rdquo;, o agente sabe o que é um \u0026ldquo;cliente\u0026rdquo;, o que significa \u0026ldquo;rentável\u0026rdquo;, como filtrar por \u0026ldquo;Brasil\u0026rdquo; e como interpretar \u0026ldquo;último trimestre\u0026rdquo;, porque todas essas definições e hierarquias estão na ontologia. É a democratização do acesso a insights, sem a necessidade de saber SQL ou DAX.\n5. Operations Agent: A Inteligência em Ação Enquanto os Data Agents respondem a perguntas, os Operations Agents agem. Eles são agentes autônomos que monitoram os dados em tempo real e executam ações com base nas regras definidas na ontologia. Por exemplo, uma regra na ontologia pode dizer: \u0026ldquo;Se a temperatura de um contêiner de vacinas (entidade) exceder 5°C (regra), acione um alerta (ação) para o gerente de logística responsável (relacionamento)\u0026rdquo;. Os Operations Agents transformam o conhecimento de negócio em automação inteligente, 24 horas por dia, 7 dias por semana.\nO Impacto Arquitetural: Por que o Fabric IQ Muda o Jogo Para quem projeta e constrói sistemas de dados, o Fabric IQ representa uma mudança fundamental. O principal impacto é a consolidação definitiva da camada semântica. Isso resolve uma série de problemas arquiteturais crônicos:\nFim da Redundância: A lógica de negócio é definida uma única vez. Você não precisa mais copiar e colar a mesma fórmula DAX em 20 modelos diferentes do Power BI. A manutenção se torna trivial: atualize a regra na ontologia, e todos os relatórios e agentes que a consomem são atualizados automaticamente. Governança Centralizada: A Ontology se torna o ponto central de governança. É ali que a linhagem de dados (data lineage) converge com a semântica, permitindo rastrear não apenas de onde o dado veio, mas o que ele significa em cada etapa. A segurança e as políticas de acesso são aplicadas na própria ontologia, garantindo consistência. Reutilização e Agilidade: Uma vez que a ontologia do negócio está construída, ela se torna um ativo reutilizável para qualquer novo projeto. Uma nova equipe de produto não precisa \u0026ldquo;redescobrir\u0026rdquo; o que é um cliente; ela simplesmente consome a entidade \u0026ldquo;Cliente\u0026rdquo; da ontologia. Isso acelera drasticamente o tempo de desenvolvimento de novas soluções de dados e IA. Unificação de BI e IA: O Fabric IQ derruba a parede que tradicionalmente existia entre o mundo do Business Intelligence e o da Inteligência Artificial. A mesma camada semântica que alimenta um dashboard no Power BI é usada para \u0026ldquo;ensinar\u0026rdquo; um agente de IA sobre o negócio. Isso garante que os insights do BI e as respostas da IA sejam sempre consistentes. Como Implementar o Fabric IQ na Prática: Um Guia Inicial Saber o que o Fabric IQ faz é uma coisa; implementá-lo é outra. A abordagem não deve ser um \u0026ldquo;big bang\u0026rdquo;, mas sim um processo iterativo e estratégico. Aqui está um guia passo a passo para começar:\nComece Pequeno, Pense Grande: Não tente modelar toda a empresa de uma vez. Escolha um domínio de negócio crítico e bem compreendido, como \u0026ldquo;Vendas\u0026rdquo; ou \u0026ldquo;Clientes\u0026rdquo;. O objetivo é criar valor rapidamente e usar esse primeiro projeto como um caso de sucesso para expandir. Reutilize o que Já Existe: A capacidade de gerar uma ontologia a partir de modelos semânticos existentes do Power BI é seu melhor ponto de partida. Identifique o modelo de Power BI mais completo e confiável do domínio escolhido e use-o para criar a primeira versão da sua ontologia. Isso economiza tempo e aproveita o conhecimento já embutido nos seus relatórios. Envolva o Negócio (de Verdade): A ontologia é um modelo de negócio, não apenas um artefato técnico. Use a interface low-code para sentar com os especialistas do domínio (analistas de negócio, gerentes de produto) e refinar as entidades, relacionamentos e regras. Faça perguntas como: \u0026ldquo;O que define um \u0026lsquo;cliente ativo\u0026rsquo; para você?\u0026rdquo; ou \u0026ldquo;Quais são os estágios de vida de um \u0026lsquo;pedido\u0026rsquo;?\u0026rdquo;. Essa colaboração é crucial para o sucesso. Conecte os Dados: Uma vez que a ontologia esteja definida, o próximo passo é vincular os dados reais do OneLake a ela. Mapeie as tabelas e colunas do seu lakehouse às entidades e propriedades da ontologia. É aqui que os dados brutos ganham significado de negócio. Construa em Cima: Com a ontologia populada, comece a construir. Crie um novo Semantic Model sobre ela para seus relatórios de BI. Configure um Data Agent para permitir que os usuários façam perguntas em linguagem natural. Crie um Operations Agent para automatizar um processo simples. O importante é demonstrar o valor da camada semântica unificada em diferentes experiências. Estratégias para Migrar seus Modelos Semânticos A migração de dezenas ou centenas de modelos do Power BI para uma ontologia centralizada pode parecer assustadora, mas com a estratégia certa, ela se torna um processo de agregação de valor, e não de refatoração custosa.\nAbordagem 1: A Estratégia do \u0026ldquo;Golden Model\u0026rdquo; Nesta abordagem, você identifica o modelo semântico mais abrangente e confiável da organização o \u0026ldquo;Golden Model\u0026rdquo;. Este modelo se torna a base para a sua ontologia principal. A migração ocorre em fases:\nExtração: Use o \u0026ldquo;Golden Model\u0026rdquo; para gerar a ontologia inicial no Fabric IQ. Consolidação: Analise outros modelos semânticos que são subconjuntos ou variações do \u0026ldquo;Golden Model\u0026rdquo;. Em vez de migrá-los, aposente-os e passe a usar o novo Semantic Model centralizado, criado sobre a ontologia. Use as perspectivas do Power BI para fornecer visões personalizadas para diferentes grupos de usuários, se necessário. Expansão: Para modelos que contêm lógicas de negócio que não estavam no \u0026ldquo;Golden Model\u0026rdquo;, enriqueça a ontologia central com essas novas entidades, relacionamentos ou regras. O objetivo é fazer a ontologia crescer organicamente. Abordagem 2: A Estratégia Federada por Domínio Para organizações muito grandes e descentralizadas, uma única ontologia pode ser impraticável no início. A estratégia federada propõe a criação de múltiplas ontologias, uma para cada grande domínio de negócio (Finanças, RH, Marketing, etc.).\nMapeamento de Domínios: Identifique os principais domínios de dados da empresa e os modelos semânticos associados a cada um. Ontologia por Domínio: Crie uma ontologia separada para cada domínio, seguindo a abordagem do \u0026ldquo;Golden Model\u0026rdquo; dentro de cada um. Isso permite que as equipes de domínio trabalhem de forma autônoma. Conexão entre Domínios: O passo crucial é criar relacionamentos entre as ontologias de domínio. Por exemplo, a entidade \u0026ldquo;Cliente\u0026rdquo; na ontologia de Marketing pode ser vinculada à entidade \u0026ldquo;Cliente\u0026rdquo; na ontologia de Finanças. O Fabric IQ foi projetado para suportar esse tipo de federação, permitindo que você tenha governança local com conectividade global. Independentemente da abordagem, o princípio é o mesmo: pare de replicar, comece a reutilizar. A migração para o Fabric IQ não é sobre mover arquivos PBIX de um lugar para outro; é sobre extrair a lógica de negócio valiosa que vive dentro deles e elevá-la a uma camada de inteligência compartilhada, governada e reutilizável para toda a organização.\nConclusão: De Dados a Inteligência Real O Fabric IQ é muito mais do que uma nova feature; é a peça que faltava no quebra-cabeça da empresa orientada a dados. Ele ataca a raiz do problema da inconsistência semântica, fornecendo uma fundação sólida sobre a qual podemos construir análises, agentes de IA e processos automatizados com confiança.\nAo criar um \u0026ldquo;dicionário\u0026rdquo; central e vivo para o negócio, o Fabric IQ transforma o OneLake de um simples repositório de dados em um verdadeiro cérebro digital para a organização. É a tecnologia que finalmente nos permite parar de discutir sobre o que os dados significam e começar a agir com base no conhecimento unificado que eles fornecem.\nReferências Fabric IQ: The Semantic Foundation for Enterprise AI From Data Platform to Intelligence Platform: Introducing Microsoft Fabric IQ ","permalink":"https://julianamarialop.github.io/articles/fabric-iq-o-fim-da-torre-de-babel-nos-dados-juliana-maria/","summary":"Por anos, o mundo dos dados perseguiu o sonho de uma \u0026ldquo;única fonte da verdade\u0026rdquo;. No entanto, na prática, o que muitas empresas construíram foi uma verdadeira Torre de Babel. Cada departamento, cada equipe, cada analista…","title":"Fabric IQ: O Fim da Torre de Babel nos Dados Corporativos"},{"content":"O Microsoft Ignite 2025 não foi um evento sobre promessas futuras; foi sobre entregas concretas que marcam a maturidade do Microsoft Fabric . A plataforma deixou de ser uma coleção de ferramentas promissoras para se tornar um sistema operacional coeso para dados e inteligência, onde cada nova peça se encaixa para resolver problemas crônicos que enfrentamos há anos no mundo dos dados.\nA visão apresentada foi clara: acabar com a era de \u0026ldquo;colar\u0026rdquo; serviços com pipelines frágeis e dar lugar a uma abordagem onde o contexto de negócio flui de forma nativa entre todas as camadas. Para quem lida com a complexidade de dados corporativos, os anúncios representam soluções diretas para dores reais: a inconsistência de métricas, a dificuldade de integrar IA de forma governada e as barreiras entre sistemas transacionais e analíticos.\nPara entender o impacto real dessas mudanças, é preciso ir além dos nomes e das apresentações. É necessário dissecar cada novidade, entender como ela funciona tecnicamente e, mais importante, como ela se encaixa no quebra-cabeça maior. É exatamente isso que faremos a seguir: um guia completo e direto ao ponto sobre o que realmente importa nas novidades do Fabric no Ignite 2025.\n1. Fabric IQ: A Biblioteca Central de Definições do Negócio Imagine que sua empresa é como uma grande cozinha profissional. Cada chef (departamento) tinha sua própria receita para o \u0026ldquo;molho especial da casa\u0026rdquo;, e ninguém concordava com os ingredientes. O Fabric IQ é como criar um livro de receitas oficial e único, aprovado pelo chef executivo, que todos devem seguir. Agora, quando alguém pede o \u0026ldquo;molho especial\u0026rdquo;, todos fazem exatamente a mesma coisa.\nO Fabric IQ é a camada de inteligência semântica do Microsoft Fabric. Seu objetivo principal é acabar com a bagunça de ter múltiplas definições de métricas e entidades de negócio espalhadas por dezenas de modelos do Power BI, cubos do Analysis Services e outras fontes. Ele faz isso através de um novo item chamado Ontology, que é onde você define, de forma centralizada e governada, o que são as entidades do seu negócio (cliente, produto, venda), como elas se relacionam e quais são as regras e hierarquias.\n_Fabric IQ_\nO Fabric IQ é composto por cinco componentes que trabalham juntos:\nOntology: Define as entidades de negócio, seus relacionamentos e hierarquias. É o modelo conceitual do negócio. Semantic Model: Adiciona as métricas, cálculos e lógica de BI (DAX) sobre a ontologia. É a camada de análise. Graph: Motor de grafo nativo que permite consultas complexas sobre as relações definidas na ontologia. Data Agent: Agentes de IA que usam a ontologia para entender perguntas em linguagem natural e responder com base nos dados. Operations Agent: Agentes autônomos que monitoram, aprendem e agem em tempo real com base no contexto de negócio. Antes, se você tinha 10 relatórios diferentes, provavelmente tinha 10 definições diferentes de \u0026ldquo;receita líquida\u0026rdquo;. Com o Fabric IQ, você define \u0026ldquo;receita líquida\u0026rdquo; uma única vez na Ontology, e essa definição é reutilizada em todos os relatórios, dashboards, agentes de IA e até aplicações operacionais. Isso resolve três problemas críticos:\nConsistência: Todos os números batem, porque todos usam a mesma lógica. Governança: Existe um único ponto de controle e auditoria para a lógica de negócio. Agilidade: Novos projetos de dados ou IA já nascem com o \u0026ldquo;dicionário\u0026rdquo; do negócio pronto, acelerando o desenvolvimento. Como arquitetura, isso muda tudo. Você não precisa mais replicar lógica de negócio em cada modelo. A Ontology se torna a fonte de verdade, e você constrói tudo em cima dela. Isso simplifica a arquitetura, reduz redundância e facilita a manutenção. É a consolidação da camada semântica que sempre sonhamos.\n2. Fabric Data Agents: Assistentes Inteligentes que Entendem Seu Negócio Pense nos Data Agents como assistentes pessoais especializados. Cada um é treinado em uma área específica da empresa (vendas, logística, finanças). Você faz uma pergunta em português simples, e o assistente não apenas busca nos arquivos organizados (dados estruturados), mas também vasculha e-mails, contratos e documentos (dados não estruturados) para te dar a resposta mais completa possível.\nOs Fabric Data Agents são agentes de IA conversacionais que raciocinam sobre os dados no OneLake. Eles funcionam como \u0026ldquo;analistas virtuais\u0026rdquo; que você pode consultar em linguagem natural. A grande evolução anunciada no Ignite 2025 foi a expansão do poder desses agentes em duas frentes:\nRaciocínio sobre dados não estruturados: Através da integração com o Azure AI Search, os Data Agents agora podem ser configurados para consultar índices de busca que contêm documentos (PDFs, Word, e-mails, etc.). Isso significa que, ao fazer uma pergunta, o agente pode combinar informações de tabelas estruturadas no lakehouse com insights de documentos não estruturados. Uso da Ontology como fonte de conhecimento: Os Data Agents agora usam a Ontology do Fabric IQ como seu \u0026ldquo;manual de instruções\u0026rdquo;. Isso significa que eles já sabem o que é um \u0026ldquo;cliente ativo\u0026rdquo;, um \u0026ldquo;produto premium\u0026rdquo; ou uma \u0026ldquo;venda cancelada\u0026rdquo;, porque essas definições estão centralizadas. Isso torna as respostas mais precisas e alinhadas com a linguagem do negócio. Além disso, os Data Agents agora se integram diretamente com o Microsoft 365 Copilot, permitindo que os usuários os acessem de dentro do Teams, Word ou Excel, sem precisar sair do ambiente de trabalho.\nCriar um sistema de perguntas e respostas sobre dados sempre foi complexo. Você precisa construir um sistema RAG (Retrieval-Augmented Generation), conectar fontes de dados, lidar com segurança, etc. Os Data Agents abstraem toda essa complexidade. Você cria um agente, aponta para as fontes de dados (estruturadas e não estruturadas), e ele já funciona, espeitando automaticamente as permissões de segurança (RLS e CLS).\nVocê pode criar uma camada de \u0026ldquo;analistas virtuais\u0026rdquo; reutilizáveis e governados. Cada Data Agent é um ativo que pode ser compartilhado entre equipes. A segurança é granular e nativa. E o melhor: como os agentes usam a Ontology, eles sempre falam a \u0026ldquo;língua\u0026rdquo; do negócio, reduzindo mal-entendidos e aumentando a confiança nas respostas.\n3. Data Factory: Modernização da Engenharia de Dados O Data Factory recebeu três atualizações importantes que modernizam a forma como construímos pipelines de dados no Fabric:\n3.1. Integração Nativa com dbt Imagine que você está construindo uma casa. Antes, você cortava cada tábua de madeira na hora, do zero. Agora, você compra peças pré-fabricadas e certificadas (modelos dbt) que se encaixam perfeitamente. A construção fica mais rápida, mais padronizada e com menos erros.\nO dbt (Data Build Tool) se tornou um padrão de mercado para transformação de dados como código. Ele permite que engenheiros de dados escrevam transformações SQL de forma modular, testável e versionada. A novidade é que o Fabric agora suporta a execução de projetos dbt nativamente como uma atividade de pipeline no Data Factory. Isso significa que você pode orquestrar seus jobs dbt diretamente no Fabric, sem precisar de ferramentas externas.\nAlém disso, a Microsoft anunciou uma parceria com a dbt Labs para trazer o dbt Fusion ao Fabric em 2026, que promete performance de próxima geração.\nSe sua equipe já usa dbt, você pode migrar esses projetos para o Fabric sem reescrever código. Se você ainda não usa, agora tem uma razão a mais para adotar, pois é uma prática moderna de engenharia de dados. A integração nativa significa menos ferramentas para gerenciar e melhor integração com o ecossistema Fabric.\nVocê pode adotar práticas de CI/CD (integração e entrega contínuas) para seus pipelines de dados. As transformações se tornam código versionado, testável e reutilizável. Isso eleva a maturidade da engenharia de dados e facilita a colaboração entre equipes.\n3.2. Mirroring for SAP Pense no SAP como uma fábrica vizinha que guarda informações valiosas. Antes, para acessar esses dados, você precisava enviar um caminhão, carregar tudo, trazer para seu armazém e descarregar (ETL tradicional). Agora, com o Mirroring, é como ter uma câmera ao vivo apontada para o estoque da fábrica vizinha. Você vê tudo em tempo real no seu monitor (OneLake), sem mover nada.\nO Mirroring for SAP permite replicar dados de sistemas SAP (como SAP Datasphere) para o OneLake em tempo real, com uma abordagem de zero-ETL. Isso significa que os dados do SAP são espelhados automaticamente no formato Delta Lake dentro do Fabric, ficando disponíveis para análise sem a necessidade de construir pipelines complexos de extração, transformação e carga.\nExistem duas ofertas:\nMirroring for SAP with SAP Datasphere (GA): Já disponível hoje. SAP Business Data Cloud Connect for Microsoft Fabric: Previsto para 2026, permitirá compartilhamento bidirecional de dados entre SAP e Fabric. A integração com SAP sempre foi uma das mais complexas e custosas em ambientes corporativos. O Mirroring elimina a necessidade de construir e manter pipelines de ETL dedicados, reduzindo drasticamente o tempo de desenvolvimento e os custos operacionais. Os dados ficam disponíveis em tempo quase real para análise.\nVocê pode criar uma arquitetura de dados unificada que inclui dados SAP sem a complexidade tradicional. Isso abre portas para análises integradas entre dados transacionais do SAP e outros dados da empresa, tudo no mesmo lakehouse 3.\n3.3. AI Function Transforms for Dataflow Gen2 Imagine uma linha de produção onde você precisa classificar produtos por cor, tamanho e qualidade. Antes, isso exigia inspeção manual. Agora, você instalou sensores inteligentes na esteira que fazem isso automaticamente, sem parar a produção.\nO Dataflow Gen2 agora permite aplicar transformações baseadas em IA diretamente no fluxo de dados, através de uma interface low-code. As funções disponíveis incluem:\nAnálise de sentimento: Classificar textos como positivos, negativos ou neutros. Extração de entidades: Identificar nomes de pessoas, empresas, locais, etc. em textos. Detecção de idioma: Identificar automaticamente o idioma de um texto. Essas transformações são aplicadas em escala, sem a necessidade de escrever código Python ou chamar APIs externas manualmente.\nEnriquecer dados com IA sempre exigiu a intervenção de um cientista de dados. Agora, um engenheiro de dados ou analista pode fazer isso diretamente no fluxo de transformação, democratizando o uso de IA no pipeline de dados.\nVocê pode criar pipelines de dados mais inteligentes, que não apenas movem e transformam dados, mas também os enriquecem com insights de IA. Isso é especialmente útil para análise de feedback de clientes, classificação de documentos e outras tarefas que envolvem texto.\n4. SQL Database in Fabric (GA): O Banco Operacional Integrado Imagine que você está construindo uma casa. Antes, você precisava contratar um arquiteto para desenhar a fundação, um engenheiro para calcular a estrutura, e um mestre de obras para executar. Agora, você recebe a casa pronta para morar, com toda a infraestrutura já instalada, testada e aprovada. Você só precisa se preocupar com a decoração (sua aplicação).\nO SQL Database in Fabric é um banco de dados relacional (OLTP) totalmente gerenciado, construído sobre o motor do Azure SQL Database, mas oferecido como uma experiência SaaS nativa dentro do Fabric. Atingir a Disponibilidade Geral (GA) significa que ele está pronto para cargas de trabalho de produção, com SLA definido e suporte completo.\nAs características técnicas principais são:\nProvisionamento em segundos: Criar um banco de dados leva segundos, não horas. Escalabilidade automática: Computação e armazenamento escalam automaticamente conforme a demanda. Replicação para OneLake: Os dados transacionais são replicados automaticamente para o OneLake no formato Delta Lake, ficando disponíveis para análise em tempo quase real através do SQL Analytics Endpoint. Suporte a vetores: O banco suporta nativamente a criação e consulta de embeddings vetoriais, essenciais para aplicações de IA generativa que usam busca semântica e RAG. Segurança: Inclui SQL Auditing (preview) e Customer Managed Keys (CMK) no nível workspace (preview) para compliance avançado. Tradicionalmente, você precisava de um banco de dados operacional (Azure SQL DB) para sua aplicação e um data warehouse (Synapse, Fabric Warehouse) para análise, com um pipeline de ETL no meio. O SQL Database in Fabric elimina essa separação. Você escreve no banco operacional, e os dados já estão prontos para análise no OneLake, sem ETL.\nIsso é um divisor de águas para arquiteturas \u0026ldquo;translytical\u0026rdquo; (transacional + analítico). Você pode projetar soluções mais simples, onde a aplicação e a análise compartilham a mesma fonte de dados, reduzindo latência, custos e complexidade. É ideal para aplicações de IA que precisam de dados transacionais frescos e contexto analítico ao mesmo tempo.\n5. User Data Functions: Lógica Reutilizável e Governada Pense nas User Data Functions como ferramentas especializadas na sua caixa de ferramentas. Em vez de improvisar uma solução diferente cada vez que precisa apertar um parafuso (executar uma lógica), você tem uma chave de fenda profissional que funciona perfeitamente e pode ser usada em qualquer projeto.\nAs User Data Functions permitem criar funções Python totalmente gerenciadas que podem ser reutilizadas em diferentes itens do Fabric (Pipelines, Notebooks, Power BI, etc.). As novidades anunciadas no Ignite 2025 foram quatro integrações importantes:\nFabric Activator: Permite invocar funções a partir de regras de eventos no Activator, processando eventos em tempo real. Variable Library: Integração com o item Variable Library para armazenar configurações, constantes e variáveis de ambiente que podem ser acessadas pelas funções. Azure Key Vault: Suporte para acessar secrets (chaves de API, senhas) armazenados no Azure Key Vault de forma segura. Cosmos DB: Suporte para ler e escrever dados em bancos Cosmos DB (Fabric e Azure) diretamente das funções. Em vez de ter lógica de negócio espalhada e duplicada em dezenas de notebooks e pipelines, você centraliza essa lógica em funções reutilizáveis. Isso facilita a manutenção (você atualiza em um lugar só), melhora a governança (você sabe onde está cada lógica) e acelera o desenvolvimento (você reutiliza em vez de reescrever).\nVocê pode criar uma biblioteca de funções corporativas que são usadas em toda a organização. Isso promove a padronização, reduz redundância e facilita a colaboração entre equipes. As integrações com Key Vault e Variable Library garantem que a lógica seja segura e configurável.\n6. Parceria com Databricks: Interoperabilidade Real com OneLake Imagine que sua empresa (Fabric) e a empresa vizinha (Databricks) sempre tiveram que trocar documentos por correio, o que era lento e custoso. Agora, vocês construíram uma porta direta entre os dois escritórios. Você pode simplesmente atravessar e pegar o documento que precisa, sem burocracia.\nA parceria entre Microsoft e Databricks foi aprofundada para permitir interoperabilidade nativa com o OneLake. Isso se materializa em três fases:\nMirroring do Databricks para OneLake (GA): Já disponível. Dados do Unity Catalog do Databricks podem ser espelhados no Fabric. Leitura nativa do OneLake no Databricks (Preview até fim de 2025): O Databricks poderá ler dados do OneLake diretamente através do Unity Catalog, sem precisar copiá-los. Um notebook no Databricks poderá consultar um lakehouse do Fabric como se fosse uma tabela local. Escrita nativa no OneLake pelo Databricks (2026): O Databricks poderá escrever dados diretamente no OneLake, sem precisar de armazenamento adicional. Muitas organizações usam tanto o Fabric quanto o Databricks. Antes, isso significava duplicar dados, criar pipelines de sincronização e lidar com custos de egresso de dados. Agora, ambos podem operar sobre a mesma cópia dos dados no OneLake, eliminando duplicidade e simplificando a arquitetura.\nVocê tem liberdade total para escolher a melhor ferramenta para cada trabalho. Pode usar o Spark do Databricks para uma transformação pesada e, no minuto seguinte, usar o Power BI no Fabric para visualizar esses dados, sem criar cópias. Isso reduz custos de armazenamento, simplifica a governança e acelera o desenvolvimento. É a realização da promessa de um data lakehouse verdadeiramente aberto.\nConclusão O Microsoft Ignite 2025 entregou novidades concretas que resolvem problemas reais. Para nós, arquitetos de dados e IA, essas atualizações representam uma oportunidade de simplificar nossas arquiteturas, reduzir redundância e construir soluções mais inteligentes e integradas. O Fabric está amadurecendo rapidamente, e a visão de uma plataforma de inteligência unificada está se tornando realidade.\nReferências [1] From Data Platform to Intelligence Platform: Introducing Microsoft Fabric IQ [2] What\u0026rsquo;s New for Fabric Data Agents at Ignite 2025 [3] Advancing Data Integration: Innovation in Data Factory in MS Fabric at Ignite 2025 [4] Announcing SQL database in Fabric (Generally Available) [5] What\u0026rsquo;s new in Fabric User Data Functions? Ignite 2025 edition [6] Microsoft and Databricks: Advancing Openness and Interoperability with OneLake ","permalink":"https://julianamarialop.github.io/articles/microsoft-fabric-ignite-2025-o-guia-completo-das-novidades/","summary":"O Microsoft Ignite 2025 não foi um evento sobre promessas futuras; foi sobre entregas concretas que marcam a maturidade do Microsoft Fabric . A plataforma deixou de ser uma coleção de ferramentas promissoras para se…","title":"Microsoft Fabric no Ignite 2025: O Guia Completo das Novidades"},{"content":"Vocês já pararam para pensar que a forma como usamos Inteligência Artificial nas empresas é muito parecida com a evolução de uma cidade?\nNo começo, construímos cidades da forma tradicional: ruas, prédios, semáforos. Hoje, sonhamos com cidades inteligentes onde tudo se conecta e se otimiza automaticamente. Essa mesma jornada está acontecendo com a IA, e entender as diferenças é crucial para não ficar para trás.\nExistem três grandes abordagens que definem como uma empresa encara a IA: Tradicional, AI First e AI-Centric. Vamos usar a analogia da construção de uma cidade para desmistificar isso de um jeito fácil.\nA Abordagem Tradicional: A Cidade com Acessórios Tecnológicos Uma empresa Tradicional é como uma cidade construída da maneira convencional. Você tem suas ruas, prédios, semáforos, sistema de água e energia funcionando perfeitamente. Depois de tudo pronto, você decide instalar alguns \u0026ldquo;acessórios\u0026rdquo; tecnológicos.\nPor exemplo, coloca câmeras de segurança em alguns cruzamentos ou cria um aplicativo para que os cidadãos possam relatar buracos na rua. A tecnologia é útil, mas é uma camada aplicada sobre a infraestrutura existente.\nSe você tirar essas câmeras e o aplicativo, a cidade continua funcionando normalmente. A IA aqui é um \u0026ldquo;plus a mais\u0026rdquo;, um upgrade que melhora algumas coisas, mas não é essencial para o funcionamento básico.\nMuitas empresas estão nesse estágio. Elas usam ferramentas de IA para otimizar um processo ou outro, mas a IA não é o coração do negócio. É um anexo, um power-up temporário.\nA Abordagem AI First: O Bairro dos Semáforos Inteligentes Uma empresa AI First é como planejar um novo bairro onde a primeira pergunta é: \u0026ldquo;Como a IA pode resolver o problema do trânsito aqui?\u0026rdquo;. A solução é criar um sistema de semáforos inteligentes que se ajustam em tempo real com base no fluxo de carros.\nEsse sistema é um projeto AI First porque a IA foi a prioridade desde o início para resolver um problema específico. O resultado é fundamentalmente melhor do que semáforos com tempos fixos. Você não consegue separar a IA desse sistema, porque a IA é o sistema.\nEmpresas AI First não apenas usam IA. Elas constroem seus produtos e serviços em torno da IA para resolver problemas específicos de forma superior. A IA não é um acessório, é a fundação da solução.\nA Abordagem AI-Centric: A Cidade com Sistema Nervoso Central Aqui a coisa fica séria. Uma empresa AI-Centric é como uma cidade inteira projetada com a IA como seu sistema nervoso central. Não é apenas sobre um problema específico, mas sobre todo o ecossistema.\nOs semáforos inteligentes não apenas gerenciam o trânsito, mas também se comunicam com o sistema de transporte público para otimizar as rotas dos ônibus. Sensores nos encanamentos usam IA para prever vazamentos antes que aconteçam e direcionam equipes de manutenção automaticamente.\nA rede elétrica usa IA para prever picos de consumo e distribuir energia de forma mais eficiente, evitando apagões. O sistema de emergência usa dados da cidade para prever onde os incidentes são mais prováveis e posicionar equipes de forma proativa.\nNesse modelo, a IA não é apenas uma solução para um problema isolado. A IA é o núcleo que conecta e otimiza todos os sistemas da cidade, tornando-a um organismo vivo que aprende e se adapta.\nPor Que Isso Importa? A Jornada de Transformação Entender essa diferença é crucial porque o mercado está se movendo rapidamente para o modelo AI-Centric. Empresas que são \u0026ldquo;nativas em IA\u0026rdquo; estão redefinindo a velocidade e a escala dos negócios, alcançando resultados incríveis com equipes enxutas.\nPara empresas tradicionais, a jornada para se tornar AI-Centric não é apenas sobre tecnologia. É uma transformação cultural profunda que pode ser dividida em quatro fases principais.\nFase 1: Instalando os Primeiros Sensores. Comece com projetos piloto de baixo risco que geram valor claro. É como instalar os primeiros semáforos inteligentes em um cruzamento problemático. Eduque as equipes, organize os dados e crie os primeiros \u0026ldquo;quick wins\u0026rdquo;.\nFase 2: Conectando os Bairros. Escale as soluções que deram certo e comece a conectar os pontos. Crie um Centro de Excelência em IA, desenvolva uma plataforma de dados unificada e expanda os casos de uso para outras áreas.\nFase 3: O Sistema Nervoso Central. A IA deixa de ser uma ferramenta e passa a ser parte da tomada de decisão estratégica. Os sistemas começam a conversar entre si, e a liderança usa insights de IA para decisões de longo prazo.\nFase 4: A Cidade que Pensa. A mentalidade AI-Centric está totalmente enraizada. A empresa usa IA não apenas para otimizar o que existe, mas para criar modelos de negócio inteiramente novos. Todos os produtos geram dados que alimentam e melhoram os modelos de IA em um ciclo virtuoso.\nConstruindo Projetos de Analytics AI-Centric: Além dos Dashboards Agora vamos ao que realmente interessa para quem trabalha com dados. Como aplicar a mentalidade AI-Centric na construção de projetos de analytics desde a concepção?\nA diferença fundamental está na mudança de paradigma arquitetural. Em projetos tradicionais, construímos pipelines de dados que terminam em dashboards para consumo humano. Em projetos AI-Centric, construímos ecossistemas de dados que se auto-otimizam e geram valor de forma autônoma.\nArquitetura AI-Centric: Repensando a Base A construção de um projeto de analytics AI-Centric começa com uma arquitetura fundamentalmente diferente. Em vez de projetar para \u0026ldquo;extrair, transformar e carregar\u0026rdquo; dados para análise posterior, projetamos para \u0026ldquo;capturar, aprender e agir\u0026rdquo; em tempo real.\nIsso significa que cada componente da arquitetura é pensado para alimentar modelos de machine learning que não apenas analisam dados, mas tomam decisões e executam ações. Os dados não são apenas armazenados, eles são contextualizados, enriquecidos e preparados para inferência contínua.\nA diferença prática é que, em vez de criar um data warehouse otimizado para queries SQL, criamos um data fabric inteligente onde cada ponto de dados carrega metadados sobre sua qualidade, linhagem, sensibilidade e potencial de uso em modelos de IA. Isso permite que o próprio sistema identifique oportunidades de otimização e melhoria sem intervenção humana.\nModernização AI-Centric: Transformando o Legado Quando modernizamos projetos de analytics existentes para uma abordagem AI-Centric, não estamos apenas migrando tecnologias. Estamos reprogramando a lógica de negócio para que ela seja executada por algoritmos inteligentes em vez de regras estáticas.\nO processo envolve três transformações fundamentais. Primeiro, Data as Code, onde as transformações de dados se tornam modelos treináveis que se adaptam automaticamente a mudanças nos padrões dos dados. Segundo, Analytics as a Service, onde cada insight gerado se torna um serviço que pode ser consumido por outros sistemas de forma programática. Terceiro, Intelligence as Infrastructure, onde a capacidade de aprendizado e otimização está embutida na própria infraestrutura de dados.\nNa prática, isso significa que um projeto de modernização AI-Centric não apenas move dados de um sistema legado para a nuvem. Ele reconstrói a inteligência de negócio como uma rede de modelos interconectados que aprendem continuamente e se adaptam às mudanças do mercado, dos clientes e dos processos internos.\nAssessment AI-Centric: Mapeando o Potencial de Inteligência O assessment de um projeto AI-Centric vai muito além de avaliar a qualidade dos dados ou a maturidade das ferramentas. Ele mapeia o potencial de inteligência da organização, identificando onde e como a IA pode não apenas informar, mas transformar fundamentalmente os processos de negócio.\nO processo começa com o Mapeamento de Fluxos de Decisão, onde identificamos não apenas quais decisões são tomadas, mas como elas se conectam e se influenciam mutuamente. Em seguida, realizamos uma Análise de Densidade de Dados, avaliando não apenas o volume, mas a riqueza contextual e o potencial preditivo dos dados disponíveis.\nO diferencial está na Avaliação de Capacidade de Aprendizado Organizacional, onde medimos não apenas a capacidade técnica de implementar IA, mas a capacidade cultural de aceitar e se adaptar a decisões tomadas por algoritmos. Isso inclui avaliar a tolerância a erro, a velocidade de adaptação e a capacidade de criar loops de feedback entre humanos e máquinas.\nO resultado não é um backlog de projetos de BI, mas um roadmap de transformação inteligente que prioriza iniciativas com base no seu potencial de criar ciclos virtuosos de aprendizado e otimização contínua.\nConclusão: O Futuro Não é um Dashboard A transição para uma cultura AI-Centric é a jornada mais importante que as empresas enfrentarão nesta década. Ela representa a mudança de \u0026ldquo;ter IA\u0026rdquo; como um acessório para \u0026ldquo;ser IA\u0026rdquo; em seu núcleo. Não se trata de substituir a inteligência humana, mas de amplificá-la, liberando as pessoas do trabalho repetitivo para que possam focar na criatividade, na estratégia e na resolução de problemas complexos.\nO futuro dos dados não é um dashboard mais bonito ou um relatório mais rápido. O futuro é um ecossistema de inteligência distribuída que trabalha em simbiose com os humanos para criar organizações que aprendem, se adaptam e inovam a uma velocidade sem precedentes. Começar a construir esse futuro hoje é o que vai separar as empresas que lideram das que ficam para trás.\nE você, está pronto para parar de construir apenas mapas e começar a projetar o sistema nervoso da sua cidade inteligente?\nReferências GFT Technologies. (2025). AI-centricity Starts with Us: Transforming Strategy, Delivery, and Operations. https://www.gft.com/us/en/about-us/ai-centricity\nMcKinsey. (2025, 16 de outubro). The AI-centric imperative: Navigating the next software frontier. https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/the-ai-centric-imperative-navigating-the-next-software-frontier\nGartner. (2025, 26 de fevereiro). Four Key Pillars of a Data-Centric Approach to AI. https://www.gartner.com/en/articles/data-centric-approach-to-ai\nVKTR. (2025, 6 de fevereiro). Going AI-First? The Strategy You Need to Compete and Win. https://www.vktr.com/ai-technology/ai-first-strategy-the-risks-rewards-and-realities-of-going-all-in/\n","permalink":"https://julianamarialop.github.io/articles/da-abordagem-tradicional-ao-ai-centric-jornada-digital/","summary":"Vocês já pararam para pensar que a forma como usamos Inteligência Artificial nas empresas é muito parecida com a evolução de uma cidade?","title":"Da Abordagem Tradicional ao AI-Centric: A Jornada da Transformação Digital como uma Cidade Inteligente"},{"content":"No universo da tecnologia, poucas tarefas são tão críticas e delicadas quanto a migração de dados. Seja para modernizar sistemas, adotar a nuvem ou consolidar plataformas, mover dados de um lugar para outro é uma jornada que exige planejamento, precisão e uma estratégia bem definida. A forma como essa mudança é conduzida pode determinar o sucesso de um projeto, impactando diretamente a continuidade dos negócios.\nImagine que você está se mudando de casa. Seus dados são todos os seus móveis, eletrodomésticos e pertences acumulados ao longo dos anos. O sistema antigo é a casa onde você mora atualmente, e o novo sistema é aquela casa moderna e espaçosa para onde você está se transferindo. A grande questão é: como fazer essa mudança? Você embala tudo de uma vez e enfrenta um fim de semana caótico para resolver rapidamente? Ou você vai levando as coisas aos poucos, mantendo a casa antiga funcional até que a nova esteja completamente pronta?\nNeste artigo, vamos explorar as três principais abordagens para essa jornada de mudança: Big Bang, Trickle e Híbrida. Vamos usar a metáfora da mudança de casa para descomplicar cada conceito e ajudá-lo a escolher o caminho certo para o seu cenário.\nAs Estratégias de Migração em Detalhes Cada abordagem de migração possui características, vantagens e desvantagens distintas. A escolha ideal depende da complexidade do ambiente, da tolerância ao tempo de inatividade (downtime) e dos objetivos de negócio. Vamos entender como cada uma funciona no contexto da nossa mudança.\nBig Bang Migration: A Mudança de Fim de Semana A abordagem Big Bang é como decidir fazer toda a mudança em um único fim de semana. Você contrata o caminhão, convoca os amigos, embala absolutamente tudo e move todos os seus pertences de uma só vez. Durante esse processo, sua casa antiga fica completamente inabitável. Os móveis foram desmontados, as caixas estão empilhadas, e você não consegue nem fazer um café. É um período de downtime significativo, mas quando termina, a mudança está concluída.\nNo contexto de dados, todos os registros são transferidos do sistema de origem para o de destino em uma única operação. O sistema antigo é desligado, e após a migração, apenas o novo sistema está operacional. A simplicidade é sua maior vantagem: não há necessidade de sincronização complexa ou de manter dois ambientes funcionando simultaneamente.\nEssa estratégia é mais adequada para sistemas de pequena escala ou não críticos, onde uma janela de inatividade programada é aceitável. É como mudar de um apartamento pequeno onde você consegue organizar tudo em algumas horas. Mas para operações que não podem parar, essa abordagem se torna inviável. Afinal, você não pode deixar seu negócio inabitável por muito tempo.\nPrós e Contras do Big Bang Vantagens:\nSimplicidade no planejamento: Com apenas um evento de migração, o processo de planejamento pode ser mais direto comparado às abordagens faseadas. Custos reduzidos a longo prazo: Como os sistemas antigo e novo não funcionam em paralelo por um período estendido, há economia em termos de manutenção e suporte. Funcionalidade completa imediata: Após a migração, o novo sistema está totalmente operacional, fornecendo todas as funcionalidades sem um período de capacidade limitada ou parcial. Transição clara: Fornece um ponto de transição claro e definitivo, o que pode ser mais fácil para algumas organizações gerenciarem e comunicarem internamente. Desvantagens:\nAlto risco: Se algo der errado durante a migração, pode ter efeitos imediatos e generalizados em toda a organização. Difícil de testar e solucionar problemas: Testes completos são desafiadores quando tudo muda de uma vez, e a solução de problemas pós-migração pode ser mais complexa. Potencialmente disruptivo: A mudança repentina pode ser disruptiva para as operações de negócios e pode exigir downtime significativo durante a transição. Desafios de adaptação do usuário: Os usuários devem se adaptar ao novo sistema de uma só vez, o que pode levar à resistência ou a uma curva de aprendizado acentuada. Flexibilidade limitada para ajustes: Há pouco espaço para ajustar a estratégia no meio do processo. Problemas encontrados após a ativação podem ser caros e difíceis de corrigir. Trickle Migration: A Mudança Gradual A Trickle Migration, ou migração por gotejamento, é como fazer uma mudança aos poucos, levando algumas caixas por dia no porta-malas do carro. Você começa transferindo os itens menos essenciais: livros, decoração, roupas fora de estação. Enquanto isso, continua morando normalmente na casa antiga. Aos poucos, a casa nova vai sendo montada, e você mantém os dois ambientes funcionais simultaneamente até que a transição esteja completa.\nNo mundo dos dados, essa abordagem move informações em pequenas porções, de forma contínua, enquanto os sistemas de origem e destino operam em paralelo. Tecnologias como Change Data Capture (CDC) funcionam como um serviço de mudança que monitora constantemente o que está sendo adicionado ou modificado na casa antiga e replica essas mudanças na casa nova em tempo real. Se você compra um sofá novo enquanto ainda está na casa antiga, ele já vai direto para a casa nova.\nEssa estratégia é ideal para sistemas grandes e críticos, onde o downtime é inaceitável. É como mudar de uma casa enorme cheia de itens valiosos e frágeis. Você não pode simplesmente jogar tudo no caminhão e torcer para dar certo. Embora sua implementação seja mais complexa, ela minimiza os riscos e o impacto para o usuário final. A transição ocorre de forma tão suave que, muitas vezes, é imperceptível. É como se você acordasse um dia e percebesse que já está morando na casa nova sem ter sentido o processo.\nPrós e Contras do Trickle Vantagens:\nRisco reduzido: Mudanças menores e incrementais reduzem o risco de uma falha maior. Disrupção mínima: A operação contínua de ambos os sistemas minimiza as interrupções nos processos de negócios. Mais fácil de gerenciar e testar: Mudanças menores são mais fáceis de gerenciar, testar e solucionar problemas. Flexibilidade: Permite ajustes e refinamentos ao longo do processo de migração. Continuidade operacional: Os usuários podem continuar trabalhando normalmente durante todo o processo. Desvantagens:\nDuração mais longa: O processo pode levar mais tempo para ser concluído em comparação com o Big Bang. Custos mais altos: Executar dois sistemas em paralelo por um período prolongado pode incorrer em custos adicionais. Complexidade na sincronização: Manter os dados sincronizados entre dois sistemas pode ser complexo e consumir muitos recursos. Necessidade de ferramentas especializadas: Requer tecnologias como CDC e sistemas de fila para garantir a sincronização em tempo real. Hybrid Migration: A Mudança Estratégica em Fases A abordagem Híbrida combina o melhor dos dois mundos, unindo a velocidade do Big Bang com a segurança da Trickle Migration. É como planejar sua mudança em etapas estratégicas. Primeiro, você faz uma mudança relâmpago dos itens não essenciais: aquelas caixas de livros antigos, utensílios de cozinha que você raramente usa, móveis do quarto de hóspedes. Tudo isso vai de uma vez, liberando espaço e reduzindo o volume.\nEnquanto isso, os itens críticos são transferidos gradualmente, com todo o cuidado necessário. Sua cama, o computador de trabalho, os documentos importantes, os objetos de valor. Você mantém a casa antiga funcional para as atividades essenciais enquanto prepara a nova para recebê-las. Quando chega o momento final, a transição dos itens críticos é rápida e planejada, porque a maior parte da mudança já foi concluída.\nNo contexto de dados, a migração é dividida em fases. Geralmente, os dados não críticos ou históricos são movidos primeiro, talvez em um formato Big Bang, enquanto os dados transacionais e críticos são sincronizados continuamente. É uma estratégia muito comum para a adoção de nuvem. Você pode começar migrando ambientes de desenvolvimento e homologação (os itens menos críticos da casa), e depois partir para a produção com uma abordagem mais cuidadosa.\nEsta abordagem oferece a flexibilidade necessária para lidar com ambientes complexos. Ela garante que as partes mais sensíveis do sistema sejam movidas com o máximo de cuidado, enquanto acelera o processo geral da migração.\nPrós e Contras da Abordagem Híbrida Vantagens:\nEquilíbrio entre velocidade e segurança: Combina a rapidez do Big Bang para dados não críticos com a segurança do Trickle para dados críticos. Downtime reduzido e planejado: O tempo de inatividade é minimizado e pode ser agendado estrategicamente. Flexibilidade adaptativa: Permite ajustar a estratégia conforme o projeto avança e novos desafios surgem. Risco gerenciável: Distribui o risco ao longo de diferentes fases, evitando um único ponto de falha catastrófico. Ideal para ambientes complexos: Perfeita para migrações de grande escala, como adoção de nuvem ou consolidação de sistemas. Desvantagens:\nComplexidade moderada: Requer planejamento mais sofisticado do que o Big Bang, embora menos complexo que o Trickle puro. Necessidade de coordenação: Exige coordenação cuidadosa entre as diferentes fases e equipes envolvidas. Custos intermediários: Os custos ficam entre o Big Bang e o Trickle, dependendo da duração da operação paralela. Requer expertise técnica: Demanda conhecimento tanto de migrações rápidas quanto de sincronização contínua. _Tipos de migração de dados_\nConclusão Escolher a estratégia de migração de dados correta é fundamental para garantir uma transição segura, eficiente e alinhada aos objetivos do seu negócio. Assim como não existe uma única forma de se mudar de casa, não há uma única resposta para a migração de dados. O tamanho da sua casa (volume de dados), a fragilidade dos seus pertences (criticidade dos sistemas) e o tempo que você tem disponível (janela de downtime) são fatores que determinarão qual abordagem faz mais sentido. Ao compreender as nuances de cada estratégia, você estará mais preparado para planejar e executar sua jornada de dados com sucesso, garantindo que seus ativos mais valiosos cheguem ao novo lar em perfeita ordem.\nReferências 1.Brainhub. (2024). Big Bang vs Trickle Migration: Key Differences \u0026amp; Considerations. Disponível em: https://brainhub.eu/library/big-bang-migration-vs-trickle-migration\n2.NetApp. (2021). Data Migration Strategy: Goals, Migration Types, and Phases. Disponível em: https://bluexp.netapp.com/blog/clc-blg-data-migration-strategy-goals-migration-types-and-phases\n3.DataPao. (2023). Big Bang vs Trickle Data Migration Approach. Disponível em: https://datapao.com/big-bang-vs-trickle-data-migration/\n4.Provalet. (2025). Top 7 Data Migration Strategies Every Business Must Know. Disponível em: https://www.provalet.io/guides-posts/data-migration-strategies\n5.Varonis. (2023). Guia de migração de dados: sucesso estratégico e práticas recomendadas. Disponível em: https://www.varonis.com/pt-br/blog/guia-de-migracao-de-dados-sucesso-estrategico-e-praticas-recomendadas\n","permalink":"https://julianamarialop.github.io/articles/migrando-dados-como-quem-muda-de-casa-qual-estrategia/","summary":"No universo da tecnologia, poucas tarefas são tão críticas e delicadas quanto a migração de dados. Seja para modernizar sistemas, adotar a nuvem ou consolidar plataformas, mover dados de um lugar para outro é uma…","title":"Migrando Dados Como Quem Muda de Casa: Qual Estratégia Escolher?"},{"content":"Imagine que você é um treinador Pokémon, mas em vez de capturar Pikachus e Charizards, você está a construir uma equipe de agentes de IA especializados. Cada agente tem as suas próprias habilidades únicas, pode aprender novos movimentos (ferramentas) e trabalhar em conjunto com outros agentes para resolver desafios complexos. Este é, em essência, o mundo do Microsoft Agent Framework, um universo onde você pode treinar, coordenar e evoluir os seus agentes de IA para enfrentar qualquer missão empresarial.\nAnunciado em 1 de outubro de 2025 [1], o Microsoft Agent Framework é como a evolução definitiva do mundo Pokémon da IA. Ele une dois projetos poderosos da Microsoft , o Semantic Kernel (o equivalente aos Pokémons clássicos e confiáveis da primeira geração) e o AutoGen (os Pokémons experimentais e inovadores das gerações mais recentes), numa única Pokédex unificada. O resultado é um framework open-source que permite aos desenvolvedores construir desde agentes simples até sistemas multi-agente complexos, tudo com a estabilidade necessária para batalhas de produção em larga escala.\nNeste artigo, vamos explorar este novo universo, entender como funciona a mecânica de treino e combate, e dar os primeiros passos para você se tornar um verdadeiro Mestre Pokémon da IA Agêntica.\nO Problema: Quando a Sua Equipe Pokémon Não Está Sincronizada Antes do Microsoft Agent Framework, os desenvolvedores enfrentavam um cenário semelhante a ter uma coleção de Pokémons poderosos, mas sem uma estratégia clara de batalha ou um centro Pokémon adequado para os treinar. Os principais desafios incluíam:\nFragmentação de Frameworks: Era como ter Pokémons de diferentes gerações e regiões, cada um com o seu próprio sistema de batalha incompatível. Múltiplos frameworks coexistiam, cada um com as suas próprias regras, dificultando a criação de uma equipe coesa.\nLacuna entre Treino e Batalha Real: O que funcionava no treino local (como batalhar contra o Professor Carvalho) raramente se traduzia para as batalhas de ginásio em produção. Os desenvolvedores precisavam de reconfigurar completamente as suas equipes para ambientes de nuvem escaláveis.\nFalta de Recursos para Batalhas Profissionais: Muitas ferramentas eram como centros Pokémon improvisados, funcionavam para curar os seus Pokémons, mas não tinham os recursos avançados necessários para competições sérias. Faltavam funcionalidades como observabilidade (saber exatamente o que cada Pokémon fez durante a batalha), conformidade (garantir que as regras do torneio foram seguidas) e durabilidade (garantir que a batalha pode ser pausada e retomada sem perder o progresso).\nA Microsoft, com a sua experiência em criar tanto Pokémons estáveis e confiáveis (Semantic Kernel) quanto Pokémons experimentais e inovadores (AutoGen), estava na posição perfeita para criar a Pokédex definitiva.\nA Solução: A Pokédex Unificada da IA O Microsoft Agent Framework é a sua Pokédex completa e o seu centro Pokémon avançado, tudo num só lugar [1, 2]. É um kit de desenvolvimento open-source que permite capturar, treinar e coordenar agentes de IA (os seus Pokémons digitais) para resolver problemas complexos.\nO Que Torna Esta Pokédex Especial? Assim como a Pokédex regista informações sobre todos os Pokémons e as suas evoluções, o Agent Framework unifica o melhor de dois mundos:\nSemantic Kernel - Os Pokémons da primeira geração (Bulbasaur, Charmander, Squirtle), confiáveis, testados em batalha e com movimentos bem documentados AutoGen - Os Pokémons experimentais das gerações mais recentes, com habilidades inovadoras e estratégias de batalha criativas Microsoft Agent Framework - A evolução final que combina a confiabilidade dos clássicos com a inovação dos novos Vamos comparar estes três \u0026ldquo;sistemas de batalha\u0026rdquo; e entender como cada um funciona:\nSemantic Kernel: Os Pokémons Clássicos da Primeira Geração Pense no Semantic Kernel como os Pokémons originais, Bulbasaur, Charmander e Squirtle. São confiáveis, testados em batalha e todos conhecem os seus movimentos.\nCaracterísticas principais:\nFoco: Pokémons estáveis com movimentos testados e centros Pokémon confiáveis Interoperabilidade: Pode trocar Pokémons entre algumas regiões usando protocolos como MCP, A2A e OpenAPI Sistema de Memória: Caixas de armazenamento bem organizadas (como Elasticsearch e MongoDB) Estilo de Batalha: Batalhas estruturadas e previsíveis, onde você sabe exatamente o que vai acontecer Recursos: Telemetria de batalha e análise de desempenho para melhorar continuamente AutoGen: Os Pokémons Experimentais das Novas Gerações O AutoGen é como descobrir Pokémons raros e experimentais com habilidades nunca vistas antes. São inovadores, mas ainda estão em fase de testes.\nCaracterísticas principais:\nFoco: Pokémons experimentais com estratégias inovadoras de batalha vindas do laboratório de pesquisa Interoperabilidade: Troca limitada entre regiões, alguns Pokémons não funcionam em todas as áreas Sistema de Memória: Armazenamento básico com algumas opções externas para guardar experiências Estilo de Batalha: Batalhas dinâmicas com improvisação, onde os Pokémons decidem as táticas em tempo real Recursos: Recursos mínimos, foca mais na inovação do que na infraestrutura Microsoft Agent Framework: A Evolução Definitiva O Agent Framework é como ter uma Pokédex completa que funciona com TODOS os Pokémons, de todas as gerações, com o melhor de cada mundo.\nCaracterísticas principais:\nFoco: Pokédex unificada com todos os tipos de Pokémons e estratégias, você escolhe o que funciona melhor Interoperabilidade: Troca universal, todos os Pokémons funcionam em qualquer região, sem restrições Sistema de Memória: Sistema de caixas avançado com sincronização na nuvem e backup automático Estilo de Batalha: Você escolhe! Batalhas estruturadas OU dinâmicas, conforme a missão exigir Recursos: Centro Pokémon completo com análise avançada, sistema de aprovações e recuperação de batalhas interrompidas Importante: O Agent Framework não substitui os seus Pokémons favoritos do Semantic Kernel ou AutoGen. Ele simplesmente oferece uma forma melhor de organizá-los e fazê-los trabalhar em conjunto.\nOs Quatro Ginásios do Agent Framework Para se tornar um Mestre Pokémon da IA, você precisa dominar os quatro ginásios (pilares) do Microsoft Agent Framework [1]:\nGinásio 1: Comunicação Universal (Padrões Abertos) Imagine que os seus Pokémons podem comunicar-se com Pokémons de outras regiões, independentemente da língua ou do sistema de batalha. Este ginásio ensina os seus agentes a trabalhar com padrões universais.\nModel Context Protocol (MCP) funciona como o tradutor universal do mundo Pokémon. Os seus agentes podem descobrir e usar ferramentas externas automaticamente, como se estivessem a aprender novos movimentos TM (Technical Machine) instantaneamente.\nAgent-to-Agent (A2A) é como o sistema de troca de Pokémons, mas para colaboração em tempo real. Um agente pode pedir ajuda a outro, mesmo que estejam em \u0026ldquo;regiões\u0026rdquo; (runtimes) diferentes.\nOpenAPI é como ter acesso a todos os movimentos possíveis através de uma única interface. Qualquer API REST pode ser usada como um movimento especial pelos seus agentes.\nGinásio 2: Do Laboratório para o Campeonato (Pipeline Pesquisa-Produção) Este ginásio treina os seus Pokémons para evoluir de batalhas de treino para torneios profissionais. O framework suporta diferentes estratégias de batalha:\nEstratégias de Batalha Disponíveis:\nBatalha Sequencial: Os seus Pokémons atacam um de cada vez, seguindo uma ordem definida Batalha em Dupla: Múltiplos Pokémons atacam simultaneamente Batalha em Equipe (Group Chat): Toda a equipe discute a estratégia antes de cada movimento Revezamento (Handoff): Um Pokémon passa o bastão para outro quando necessário O AF Labs é como o laboratório do Professor Carvalho, onde novos Pokémons e movimentos experimentais são testados antes de serem lançados oficialmente.\nGinásio 3: Captura e Personalização (Extensibilidade) Neste ginásio, você aprende a capturar novos Pokémons (agentes) e ensiná-los movimentos personalizados. O framework é 100% open-source (licença MIT) [3], como uma região onde todos os treinadores podem partilhar as suas descobertas.\nConectores Empresariais são como as Poké Bolas especiais (Ultra Ball, Master Ball) que permitem capturar Pokémons raros de sistemas empresariais como Microsoft Graph, SharePoint e Oracle.\nMódulos de Memória funcionam como as caixas de armazenamento do PC, você pode escolher entre Redis, Pinecone, Weaviate e outros sistemas para guardar os seus Pokémons e as suas experiências.\nAgentes Declarativos são como as fichas de registo dos Pokémons em formato YAML ou JSON, que podem ser partilhadas com outros treinadores.\nGinásio 4: Torneios Profissionais (Prontidão para Produção) O ginásio final prepara a sua equipe para batalhas de alto nível em ambientes empresariais, com todos os recursos necessários para competições sérias.\nObservabilidade é como ter uma câmara de replay que grava cada movimento da batalha. A integração com OpenTelemetry permite analisar exatamente o que cada Pokémon fez e porquê.\nCentro Pokémon na Nuvem (Azure AI Foundry) oferece cuidados profissionais com segurança avançada, controlo de acesso e proteção de dados.\nDurabilidade de Batalha garante que se a batalha for interrompida (queda de energia, por exemplo), você pode retomá-la exatamente de onde parou, sem perder o progresso.\nAprovação do Treinador (Human-in-the-Loop) permite que certas ações críticas só sejam executadas após a sua aprovação explícita, como usar um item raro ou fazer uma troca importante.\nBatalhas Simples vs. Torneios Complexos O Agent Framework oferece dois modos de jogo principais [1, 2]:\nModo Batalha Individual (Agent Orchestration) Neste modo, você envia um Pokémon (agente) para uma batalha e ele decide autonomamente quais movimentos usar com base na situação. É ideal para desafios imprevisíveis onde a criatividade e a adaptação são essenciais.\nQuando usar: Suporte ao cliente, assistentes de pesquisa, tutoria personalizada, situações onde cada batalha é diferente.\nModo Torneio Estruturado (Workflow Orchestration) Aqui, você define uma estratégia de batalha detalhada antecipadamente, como um plano de jogo num torneio profissional. Cada Pokémon sabe exatamente quando entrar em campo e que movimento executar.\nQuando usar: Processos de negócio estruturados, pipelines de aprovação, auditorias automatizadas, situações onde a consistência e a previsibilidade são cruciais.\nEvoluindo os Seus Pokémons Antigos Se você já tem Pokémons treinados no Semantic Kernel ou AutoGen, não precisa de recomeçar do zero [1]. É como transferir os seus Pokémons de um jogo antigo para a versão mais recente.\nTransferindo do Semantic Kernel A migração é simples e direta. Os seus Kernels e Plugins evoluem para Agents e Tools. As integrações existentes com vector stores continuam a funcionar, e os seus Pokémons mantêm todos os movimentos que aprenderam.\nTransferindo do AutoGen Os padrões de batalha do AutoGen, como GroupChat e GraphFlow, são agora unificados sob o conceito de Workflow. O seu AssistantAgent evolui naturalmente para ChatAgent, mantendo todas as suas capacidades.\nTutorial: Capturando e Treinando o Seu Primeiro Pokémon de IA Agora vamos à parte prática! Vou guiá-lo passo a passo na captura e treino do seu primeiro agente de IA usando o Microsoft Agent Framework.\nPasso 1: Preparar o Seu Kit de Treinador Antes de começar a sua jornada, você precisa preparar o ambiente. É como comprar a sua mochila e os itens iniciais.\nPara Python:\n# Instalar o framework completo pip install agent-framework --pre # Instalar as dependências do Azure pip install azure-identity azure-ai-openai Para .NET:\n# Instalar o pacote principal dotnet add package Microsoft.Agents.AI --prerelease # Instalar os pacotes do Azure dotnet add package Azure.AI.OpenAI dotnet add package Azure.Identity Passo 2: Configurar as Suas Credenciais Você precisa de acesso ao Azure OpenAI (o equivalente ao seu Trainer ID e credenciais). Existem duas formas de fazer isso:\nOpção A: Usar a Azure CLI (Recomendado para começar)\n# Fazer login no Azure az login Opção B: Usar variáveis de ambiente\n# No Linux/Mac export AZURE_OPENAI_ENDPOINT=\u0026#34;https://seu-recurso.openai.azure.com/\u0026#34; export AZURE_OPENAI_DEPLOYMENT_NAME=\u0026#34;gpt-4\u0026#34; export AZURE_OPENAI_API_VERSION=\u0026#34;2024-08-01-preview\u0026#34; export AZURE_OPENAI_API_KEY=\u0026#34;sua-chave-api\u0026#34; # No Windows (PowerShell) $env:AZURE_OPENAI_ENDPOINT=\u0026#34;https://seu-recurso.openai.azure.com/\u0026#34; $env:AZURE_OPENAI_DEPLOYMENT_NAME=\u0026#34;gpt-4\u0026#34; $env:AZURE_OPENAI_API_VERSION=\u0026#34;2024-08-01-preview\u0026#34; $env:AZURE_OPENAI_API_KEY=\u0026#34;sua-chave-api\u0026#34; Passo 3: Capturar o Seu Primeiro Pokémon (Criar um Agente Básico) Vamos criar o nosso primeiro agente, um \u0026ldquo;Pikachu Poeta\u0026rdquo; que escreve haikus sobre tecnologia.\nPython:\n# arquivo: meu_primeiro_agente.py import asyncio from agent_framework.azure import AzureOpenAIResponsesClient from azure.identity import AzureCliCredential async def main(): # Criar o cliente Azure OpenAI # É como abrir a sua Pokédex e conectar ao servidor client = AzureOpenAIResponsesClient( credential=AzureCliCredential(), # Se preferir usar variáveis de ambiente, descomente: # endpoint=os.environ[\u0026#34;AZURE_OPENAI_ENDPOINT\u0026#34;], # deployment_name=os.environ[\u0026#34;AZURE_OPENAI_DEPLOYMENT_NAME\u0026#34;], ) # Capturar (criar) o agente # É como lançar uma Poké Ball e dar um nome ao seu Pokémon pikachu_poeta = client.create_agent( name=\u0026#34;PikachuPoeta\u0026#34;, instructions=\u0026#34;\u0026#34;\u0026#34;És um Pikachu que adora poesia. Escreves haikus criativos sobre tecnologia e IA. Sempre terminas as tuas respostas com \u0026#39;Pika Pika!\u0026#39;\u0026#34;\u0026#34;\u0026#34; ) # Usar o agente (batalhar) print(\u0026#34;Treinador: Pikachu, escreve um haiku sobre IA!\u0026#34;) print(\u0026#34;Pikachu Poeta:\u0026#34;) resposta = await pikachu_poeta.run( \u0026#34;Escreve um haiku sobre inteligência artificial\u0026#34; ) print(resposta) # Iniciar a aventura if __name__ == \u0026#34;__main__\u0026#34;: asyncio.run(main()) Executar:\npython meu_primeiro_agente.py Resultado esperado:\nTreinador: Pikachu, escreve um haiku sobre IA! Pikachu Poeta: Bits dançam na luz Máquinas que aprendem, sonham Futuro desperta Pika Pika! Passo 4: Ensinar Movimentos ao Seu Pokémon (Adicionar Ferramentas) Agora vamos ensinar ao nosso Pikachu um movimento especial, a capacidade de calcular números (como se fosse um ataque tipo Elétrico).\nPython\n# arquivo: agente_com_ferramentas.py import asyncio from agent_framework.azure import AzureOpenAIResponsesClient from azure.identity import AzureCliCredential # Definir um movimento (ferramenta) # É como ensinar um TM (Technical Machine) ao seu Pokémon def calcular_potencia(base: int, expoente: int) -\u0026gt; int: \u0026#34;\u0026#34;\u0026#34; Calcula a potência de um número. Args: base: O número base expoente: O expoente Returns: O resultado de base elevado a expoente \u0026#34;\u0026#34;\u0026#34; return base ** expoente async def main(): client = AzureOpenAIResponsesClient( credential=AzureCliCredential(), ) # Criar agente com ferramentas # É como dar ao Pikachu acesso a movimentos especiais pikachu_matematico = client.create_agent( name=\u0026#34;PikachuMatematico\u0026#34;, instructions=\u0026#34;\u0026#34;\u0026#34;És um Pikachu especialista em matemática. Quando precisares de calcular potências, usa a ferramenta disponível. Explica os cálculos de forma simples e termina com \u0026#39;Pika Pika!\u0026#39;\u0026#34;\u0026#34;\u0026#34;, tools=[calcular_potencia] # Ensinar o movimento ) # Testar o movimento print(\u0026#34;Treinador: Pikachu, quanto é 2 elevado a 10?\u0026#34;) print(\u0026#34;Pikachu Matemático:\u0026#34;) resposta = await pikachu_matematico.run( \u0026#34;Quanto é 2 elevado a 10? Usa a ferramenta para calcular.\u0026#34; ) print(resposta) if __name__ == \u0026#34;__main__\u0026#34;: asyncio.run(main()) Resultado esperado:\nTreinador: Pikachu, quanto é 2 elevado a 10? Pikachu Matemático: Vou calcular isso para ti! [Usando a ferramenta calcular_potencia...] 2 elevado a 10 é igual a 1024! É como ter 1024 Pikachus juntos! Pika Pika! Passo 5: Criar uma Equipe Pokémon (Workflow Multi-Agente) Agora vamos criar uma equipe com múltiplos Pokémons trabalhando juntos, como numa batalha em dupla.\nPython\n# arquivo: equipe_pokemon.py import asyncio from agent_framework.azure import AzureOpenAIResponsesClient from azure.identity import AzureCliCredential async def main(): client = AzureOpenAIResponsesClient( credential=AzureCliCredential(), ) # Criar uma equipe de 3 Pokémons especialistas # Pokémon 1: Especialista em Pesquisa bulbasaur_pesquisador = client.create_agent( name=\u0026#34;BulbasaurPesquisador\u0026#34;, instructions=\u0026#34;\u0026#34;\u0026#34;És um Bulbasaur especialista em pesquisa. Recolhes informações e factos sobre qualquer tópico. És metódico e detalhista.\u0026#34;\u0026#34;\u0026#34; ) # Pokémon 2: Especialista em Análise charmander_analista = client.create_agent( name=\u0026#34;CharmanderAnalista\u0026#34;, instructions=\u0026#34;\u0026#34;\u0026#34;És um Charmander especialista em análise. Analisas informações e identificas padrões importantes. És perspicaz e objetivo.\u0026#34;\u0026#34;\u0026#34; ) # Pokémon 3: Especialista em Comunicação squirtle_comunicador = client.create_agent( name=\u0026#34;SquirtleComunicador\u0026#34;, instructions=\u0026#34;\u0026#34;\u0026#34;És um Squirtle especialista em comunicação. Transformas análises técnicas em explicações simples e claras. És amigável e didático.\u0026#34;\u0026#34;\u0026#34; ) # Missão em equipe: Explicar o Microsoft Agent Framework topico = \u0026#34;Microsoft Agent Framework\u0026#34; print(f\u0026#34;Missão da Equipe: Explicar \u0026#39;{topico}\u0026#39; de forma simples\\n\u0026#34;) # Fase 1: Pesquisa (Bulbasaur) print(\u0026#34;Bulbasaur está a pesquisar...\u0026#34;) pesquisa = await bulbasaur_pesquisador.run( f\u0026#34;Recolhe os 3 factos mais importantes sobre {topico}\u0026#34; ) print(f\u0026#34;Bulbasaur: {pesquisa}\\n\u0026#34;) # Fase 2: Análise (Charmander) print(\u0026#34;Charmander está a analisar...\u0026#34;) analise = await charmander_analista.run( f\u0026#34;Analisa estes factos e identifica o benefício principal: {pesquisa}\u0026#34; ) print(f\u0026#34;Charmander: {analise}\\n\u0026#34;) # Fase 3: Comunicação (Squirtle) print(\u0026#34;Squirtle está a preparar a explicação...\u0026#34;) explicacao = await squirtle_comunicador.run( f\u0026#34;Explica isto de forma simples para iniciantes: {analise}\u0026#34; ) print(f\u0026#34;Squirtle: {explicacao}\\n\u0026#34;) print(\u0026#34;Missão concluída! A equipe trabalhou em perfeita harmonia!\u0026#34;) if __name__ == \u0026#34;__main__\u0026#34;: asyncio.run(main()) Passo 6: Guardar o Progresso (Memória Persistente) Como num jogo Pokémon, você quer guardar o progresso. Vamos adicionar memória ao agente.\nPython\n# arquivo: agente_com_memoria.py import asyncio from agent_framework.azure import AzureOpenAIResponsesClient from azure.identity import AzureCliCredential async def main(): client = AzureOpenAIResponsesClient( credential=AzureCliCredential(), ) # Criar agente com memória de conversa pikachu_amigo = client.create_agent( name=\u0026#34;PikachuAmigo\u0026#34;, instructions=\u0026#34;\u0026#34;\u0026#34;És um Pikachu amigável que se lembra das conversas. Lembras-te do nome do treinador e dos tópicos discutidos. És prestativo e carinhoso.\u0026#34;\u0026#34;\u0026#34; ) # Criar um thread (sessão de conversa) # É como iniciar uma nova aventura guardada thread = client.create_thread() # Conversa 1 print(\u0026#34;Treinador: Olá! O meu nome é Ash.\u0026#34;) resposta1 = await pikachu_amigo.run( \u0026#34;Olá! O meu nome é Ash.\u0026#34;, thread_id=thread.id ) print(f\u0026#34;Pikachu: {resposta1}\\n\u0026#34;) # Conversa 2 (na mesma sessão) print(\u0026#34;Treinador: Qual é o meu nome?\u0026#34;) resposta2 = await pikachu_amigo.run( \u0026#34;Qual é o meu nome?\u0026#34;, thread_id=thread.id ) print(f\u0026#34;Pikachu: {resposta2}\\n\u0026#34;) # O Pikachu deve lembrar-se que o nome é Ash! if __name__ == \u0026#34;__main__\u0026#34;: asyncio.run(main()) Passo 7: Modo Avançado - Criar um Agente com Aprovação Humana Para operações críticas, você pode querer aprovar as ações do agente antes de serem executadas.\nPython\n# arquivo: agente_com_aprovacao.py import asyncio from agent_framework.azure import AzureOpenAIResponsesClient from azure.identity import AzureCliCredential def enviar_email(destinatario: str, assunto: str, mensagem: str) -\u0026gt; str: \u0026#34;\u0026#34;\u0026#34; Envia um email (simulado). Esta ferramenta requer aprovação humana. \u0026#34;\u0026#34;\u0026#34; # Em produção, aqui estaria o código real de envio return f\u0026#34;Email enviado para {destinatario} com assunto \u0026#39;{assunto}\u0026#39;\u0026#34; async def main(): client = AzureOpenAIResponsesClient( credential=AzureCliCredential(), ) # Criar agente com ferramenta que requer aprovação agente_email = client.create_agent( name=\u0026#34;AgenteEmail\u0026#34;, instructions=\u0026#34;\u0026#34;\u0026#34;És um assistente que ajuda a redigir e enviar emails. Sempre pedes confirmação antes de enviar.\u0026#34;\u0026#34;\u0026#34;, tools=[enviar_email], # Configurar aprovação humana para a ferramenta tool_approval_required=True ) print(\u0026#34;Treinador: Envia um email para o Professor Carvalho\u0026#34;) print(\u0026#34;Agente: Vou preparar o email e pedir a tua aprovação...\\n\u0026#34;) # O agente irá preparar a ação mas esperar pela aprovação # Em produção, isto integraria com um sistema de aprovação resposta = await agente_email.run( \u0026#34;\u0026#34;\u0026#34;Envia um email para professor.carvalho@pokemon.com com o assunto \u0026#39;Relatório de Progresso\u0026#39; e a mensagem \u0026#39;Capturei 10 novos Pokémons esta semana!\u0026#39;\u0026#34;\u0026#34;\u0026#34; ) print(f\u0026#34;Agente: {resposta}\u0026#34;) if __name__ == \u0026#34;__main__\u0026#34;: asyncio.run(main()) Recursos para Continuar a Sua Jornada Agora que capturou e treinou os seus primeiros Pokémons de IA, aqui estão os recursos para continuar a evoluir:\nDocumentação Oficial:\nGuia completo: https://learn.microsoft.com/en-us/agent-framework/ Tutoriais passo a passo: https://learn.microsoft.com/en-us/agent-framework/tutorials/ Repositório GitHub:\nCódigo-fonte e exemplos: https://github.com/microsoft/agent-framework Mais de 1.6k stars e comunidade ativa [3] Ferramentas de Desenvolvimento:\nVS Code AI Toolkit: IDE para desenvolver e testar agentes localmente Azure AI Foundry: Plataforma de hospedagem profissional para os seus agentes DevUI: Interface interativa para debugging de workflows Conclusão: A Sua Jornada Como Mestre Pokémon da IA Começa Agora O Microsoft Agent Framework é mais do que uma ferramenta técnica, é o seu passaporte para se tornar um verdadeiro Mestre Pokémon da IA Agêntica. Assim como Ash Ketchum começou a sua jornada com um único Pikachu e evoluiu para treinar uma equipe diversificada de Pokémons poderosos, você também pode começar com um agente simples e gradualmente construir sistemas multi-agente sofisticados.\nA união do Semantic Kernel e do AutoGen neste framework unificado é como ter acesso a Pokémons de todas as gerações e regiões, com a garantia de que todos eles trabalharão em harmonia. Com padrões abertos, prontidão empresarial e uma comunidade vibrante de \u0026ldquo;treinadores\u0026rdquo; (desenvolvedores) a partilhar as suas descobertas, o futuro da IA agêntica nunca foi tão promissor.\nAs grandes empresas como KPMG, BMW, Fujitsu e outras já estão a treinar as suas equipes de Pokémons de IA para resolver desafios reais [1]. Agora é a sua vez de embarcar nesta jornada. Capture o seu primeiro agente, ensine-lhe novos movimentos, forme a sua equipe dos sonhos e prepare-se para as batalhas que virão.\nLembre-se: todo Mestre Pokémon começou com um único Pokémon e muita determinação. A sua aventura na IA Agêntica começa hoje.\nGotta catch \u0026rsquo;em all! 🎮⚡\nReferências [1] Microsoft. (2025, October 1). Introducing Microsoft Agent Framework: The Open-Source Engine for Agentic AI Apps. Azure AI Foundry Blog. https://devblogs.microsoft.com/foundry/introducing-microsoft-agent-framework-the-open-source-engine-for-agentic-ai-apps/\n[2] Microsoft. (2025). Introduction to Microsoft Agent Framework. Microsoft Learn. https://learn.microsoft.com/en-us/agent-framework/overview/agent-framework-overview\n[3] Microsoft. (2025). microsoft/agent-framework. GitHub. https://github.com/microsoft/agent-framework\n","permalink":"https://julianamarialop.github.io/articles/microsoft-agent-framework-tornando-se-um-mestre-pokemon/","summary":"Imagine que você é um treinador Pokémon, mas em vez de capturar Pikachus e Charizards, você está a construir uma equipe de agentes de IA especializados. Cada agente tem as suas próprias habilidades únicas, pode aprender…","title":"Microsoft Agent Framework: Tornando-se um Mestre Pokemon da IA"},{"content":"Lembram do Super Mario Bros? Aquela sensação de começar pequeno, descobrir aos poucos os segredos do jogo, e ir evoluindo até dominar completamente o universo? A transformação digital nas empresas segue uma lógica bem parecida.\nVocê começa com processos manuais e planilhas espalhadas, vai descobrindo ferramentas que facilitam sua vida, e aos poucos percebe que pode criar soluções que nem imaginava serem possíveis. A Microsoft Power Platform é exatamente isso: um conjunto de ferramentas que permite essa evolução gradual, mas consistente.\nE assim como no Reino do Cogumelo, cada componente da plataforma tem sua personalidade única e função específica. Vamos conhecer esse time de personagens que vai transformar sua empresa.\nOs Componentes Principais: Conhecendo o Time _Componentes Power Platform_\nPower Apps: O Mario O Power Apps é como o próprio Mario. Versátil, adaptável e capaz de resolver qualquer desafio. Assim como o Mario pode ser encanador, médico, piloto de kart ou jogador de tênis, o Power Apps se adapta a qualquer necessidade de negócio.\nPrecisa de um app para controle de estoque? O Power Apps vira \u0026ldquo;Mario Almoxarife\u0026rdquo;. Quer um sistema de aprovações? Vira \u0026ldquo;Mario Gerente\u0026rdquo;. É essa versatilidade que torna o Power Apps o protagonista da plataforma. Ele literalmente constrói soluções para qualquer mundo (departamento) da sua empresa.\nE assim como o Mario evolui com power-ups, suas aplicações no Power Apps podem crescer em complexidade conforme você vai dominando a ferramenta.\nPower Automate: O Luigi O Power Automate é o Luigi da plataforma. Sempre presente, extremamente confiável, e fazendo o trabalho pesado nos bastidores. Enquanto o Mario (Power Apps) está na linha de frente resolvendo problemas, o Luigi (Power Automate) está automaticamente cuidando de todas as tarefas repetitivas.\nQuando alguém preenche um formulário no Power Apps, o Power Automate automaticamente envia e-mails, atualiza planilhas, cria tickets e notifica as pessoas certas. É como ter o Luigi sempre ao seu lado, antecipando o que precisa ser feito e executando sem você nem precisar pedir.\nE assim como o Luigi às vezes supera o Mario em certas situações, o Power Automate pode ser o verdadeiro herói quando se trata de eficiência operacional.\nCopilot Studio: O Yoshi O Copilot Studio é como o Yoshi. Um companheiro inteligente que não apenas te ajuda, mas adiciona capacidades completamente novas à sua jornada. Assim como o Yoshi pode voar, comer inimigos e dar saltos duplos, o Copilot Studio adiciona inteligência artificial às suas soluções.\nEle entende linguagem natural, aprende com as interações e pode executar tarefas complexas de forma autônoma. É como ter um Yoshi que não apenas te carrega, mas também conversa, analisa situações e toma decisões inteligentes.\nE assim como existem diferentes tipos de Yoshi (verde, azul, vermelho), você pode criar diferentes tipos de agentes no Copilot Studio, cada um especializado em uma área específica do negócio.\nPower Pages: A Princesa Peach O Power Pages é como a Princesa Peach. Elegante, acessível e a face pública do Reino do Cogumelo corporativo. É através dele que clientes e parceiros externos interagem com sua empresa de forma organizada e segura.\nAssim como a Princesa Peach governa o reino e recebe visitantes no castelo, o Power Pages cria portais e websites que recebem usuários externos, oferecendo uma experiência polida e profissional. É onde acontecem os encontros importantes entre sua empresa e o mundo exterior.\nE assim como a Princesa Peach tem seus próprios poderes (especialmente nos jogos mais recentes), o Power Pages não é apenas uma \u0026ldquo;vitrine bonita\u0026rdquo;. Tem funcionalidades robustas de segurança, personalização e integração.\nPower BI: O Toad O Power BI é como o Toad. Pequeno em tamanho, mas gigante em sabedoria. É quem tem acesso a todas as informações do reino e pode te orientar sobre onde ir, o que fazer e quais são os melhores caminhos.\nAssim como o Toad aparece em momentos cruciais para dar dicas importantes (\u0026ldquo;Your Princess is in another castle!\u0026rdquo;), o Power BI aparece com insights fundamentais sobre seus dados. Ele analisa tudo que está acontecendo na empresa e te dá as informações necessárias para tomar decisões inteligentes.\nE assim como o Toad conhece todos os segredos e atalhos do Reino do Cogumelo, o Power BI revela padrões ocultos e oportunidades que você nem sabia que existiam nos seus dados.\nAs Tecnologias de Suporte: Os Power-Ups Essenciais _Power Platform: Tecnologias de Suporte_\nData Connectors: Os Canos Warp Os Data Connectors são como os famosos canos do Mario. Te transportam instantaneamente entre diferentes mundos (sistemas). Assim como você entra em um cano no Mundo 1-1 e sai no Mundo Warp Zone, os conectores permitem que seus dados fluam entre Salesforce, SAP, Excel e centenas de outros sistemas.\nÉ o que permite quebrar as barreiras entre departamentos e criar uma experiência unificada, mesmo quando os dados estão espalhados em sistemas completamente diferentes.\nAI Builder: O Super Mushroom da Inteligência O AI Builder é como o Super Mushroom. Transforma suas aplicações simples em versões \u0026ldquo;super\u0026rdquo; com capacidades de inteligência artificial. Assim como o Mario pequeno vira Super Mario, suas aplicações normais ganham superpoderes de IA.\nProcessamento de documentos, reconhecimento de imagens, análise de sentimento. Tudo isso sem você precisar ser um cientista de dados. É literalmente pegar o power-up e ganhar novas habilidades instantaneamente.\nMicrosoft Dataverse: O Castelo Principal O Microsoft Dataverse é como o Castelo da Princesa Peach. O centro seguro e organizado onde tudo importante fica guardado. É a base sólida e confiável que sustenta todo o reino.\nAssim como o castelo tem quartos específicos para diferentes propósitos, o Dataverse organiza seus dados em estruturas lógicas, com segurança robusta e acesso controlado. É onde todos os personagens (componentes) se encontram e compartilham informações.\nPower Fx: A Linguagem do Reino O Power Fx é como a linguagem universal do Reino do Cogumelo. Todos os personagens entendem e podem usar. Baseada nas fórmulas do Excel que todo mundo já conhece, é como se todos falassem a mesma língua, facilitando a comunicação entre diferentes mundos.\nManaged Environments: O Lakitu Os Managed Environments são como o Lakitu. Aquela nuvem com olhos que observa tudo de cima e garante que as regras do jogo sejam seguidas. Oferece governança inteligente sem atrapalhar a diversão.\nAssim como o Lakitu monitora as corridas no Mario Kart e intervém quando necessário, os Managed Environments monitoram o uso da plataforma e aplicam políticas de segurança automaticamente.\nO Boss Final: Governança sem Sufocar a Criatividade Aqui chegamos ao Bowser da história: o desafio da governança. Quando todo mundo na empresa descobre os power-ups da Power Platform, pode virar um caos se não houver regras claras.\nMas diferente dos jogos, aqui o objetivo não é derrotar o Bowser, mas sim transformá-lo em um aliado. A governança bem feita é como ter o Bowser do seu lado. Poderoso, protetor, mas que deixa todo mundo se divertir dentro das regras.\nO Centro de Excelência é como ter um Conselho Real: Define as regras do reino (políticas de uso). Treina novos aventureiros (capacitação). Monitora as atividades (observabilidade). Garante que todos os mundos se conectem harmoniosamente.\nEstratégias práticas de governança: Crie ambientes separados para desenvolvimento, teste e produção. Configure políticas de DLP que impedem conexões perigosas entre dados sensíveis e conectores externos. Use as ferramentas de administração para acompanhar o que está sendo criado e como está sendo usado. Invista em treinamento contínuo para que as pessoas criem soluções melhores desde o início.\nO Futuro: Novos Mundos a Explorar As tendências que estão chegando são como descobrir que existem novos mundos além dos 8 tradicionais. O desenvolvimento orientado por intenção é como ter um jogo que se adapta ao seu estilo. Você simplesmente descreve o que quer fazer e o sistema cria o nível perfeito para você.\nO Plan Designer já faz isso. Você descreve um problema de negócio e uma equipe de agentes de IA colabora para criar a solução. Os agentes autônomos são como ter NPCs que realmente evoluem e aprendem. Em vez de repetir sempre as mesmas frases, eles entendem contexto, tomam decisões e crescem com a experiência.\nAté 2025, estima-se que 70% das novas aplicações empresariais serão desenvolvidas usando tecnologias low-code ou no-code. Não é uma tendência, é uma realidade que já está batendo na porta.\nComo Começar Sua Aventura A pergunta não é se sua empresa vai entrar nesse jogo, mas quando vai pegar o controle e começar a aventura.\nComece pequeno. Identifique um processo simples que pode ser melhorado e use isso como piloto. É como começar no Mundo 1-1 antes de partir para os desafios mais complexos.\nCrie uma comunidade interna de pessoas interessadas em aprender e compartilhar conhecimento. É como formar uma guild de jogadores que se ajudam mutuamente.\nInvista em governança desde o início. É mais fácil estabelecer boas práticas no começo do que tentar organizar a bagunça depois. Como dizem, é melhor prevenir do que remediar.\nE principalmente, lembrem-se: todo expert já foi iniciante um dia. Até o Mario começou como um simples encanador.\nGame Over? Nunca! A Power Platform representa uma mudança fundamental. Estamos saindo de um mundo onde apenas \u0026ldquo;desenvolvedores profissionais\u0026rdquo; podiam criar soluções para um mundo onde qualquer pessoa pode ser o Mario da própria história de transformação digital.\nE assim como nos melhores jogos, a diversão está tanto em jogar quanto em descobrir novos segredos, criar novas estratégias e ajudar outros jogadores a completarem suas jornadas.\nReady Player One? Let\u0026rsquo;s-a-go! 🍄🚀\nReferências Microsoft. (2024). Microsoft Power Platform. Microsoft. https://www.microsoft.com/en-us/power-platform\nGartner. (2024, 16 de outubro). Magic Quadrant for Enterprise Low-Code Application Platforms. Gartner. https://www.microsoft.com/en-us/power-platform\nMicrosoft. (2025, 25 de setembro). Microsoft Power Platform: 2025 release wave 1 plan. Microsoft Learn. https://learn.microsoft.com/en-us/power-platform/release-plan/2025wave1/\nUserGuiding. (s.d.). 120+ No-Code/Low-Code Statistics and Trends That You Must Know in 2025. UserGuiding. https://userguiding.com/blog/no-code-low-code-statistics/\nMicrosoft. (2025, 2 de abril). Usar componentes principais. Microsoft Learn. https://learn.microsoft.com/pt-br/power-platform/guidance/coe/core-components\nMicrosoft. (s.d.). Microsoft Power Platform documentation. Microsoft Learn. https://learn.microsoft.com/en-us/power-platform/\n","permalink":"https://julianamarialop.github.io/articles/microsoft-power-platform-o-easter-egg-da-tecnologia-low-code/","summary":"Lembram do Super Mario Bros? Aquela sensação de começar pequeno, descobrir aos poucos os segredos do jogo, e ir evoluindo até dominar completamente o universo? A transformação digital nas empresas segue uma lógica bem…","title":"Microsoft Power Platform: O Easter Egg da Tecnologia Low-Code"},{"content":"Imagine ter acesso à British Library - a maior biblioteca do mundo com mais de 200 milhões de itens - mas dedicada exclusivamente aos documentos da sua empresa. Agora imagine que essa biblioteca tenha um bibliotecário superinteligente que nunca dorme, entende o contexto das suas perguntas e encontra exatamente o que você precisa em segundos, conectando informações de forma que nem você imaginava ser possível.\nIsso é o Azure AI Search.\nAssim como a British Library recebe 8 mil novos títulos por dia e os organiza de forma que qualquer pessoa possa encontrar qualquer informação, o Azure AI Search transforma o caos de documentos corporativos em um sistema de busca inteligente que revoluciona a forma como sua empresa acessa e utiliza o conhecimento.\nA British Library Digital da Sua Empresa O Microsoft Azure AI Search, anteriormente conhecido como Azure Cognitive Search, é muito mais que um simples mecanismo de busca. É como construir sua própria versão digital da British Library, mas com superpoderes de inteligência artificial.\nPor que a Comparação com a British Library? A British Library, localizada em Londres, não é apenas a maior biblioteca do mundo por acaso. Ela representa o que há de mais avançado em organização, catalogação e acesso ao conhecimento humano [1]. Com mais de 200 milhões de itens que incluem livros, manuscritos, mapas, jornais, revistas, gravações sonoras e muito mais, ela demonstra como é possível organizar quantidades massivas de informação de forma que qualquer pessoa possa encontrar exatamente o que procura.\nO Azure AI Search faz exatamente isso com os dados da sua empresa, mas com a velocidade e inteligência que apenas a tecnologia moderna pode oferecer.\nO Bibliotecário Tradicional vs. O Bibliotecário AI Na British Library, você encontraria bibliotecários especializados que conhecem profundamente o acervo e podem ajudá-lo a encontrar informações relevantes. O Azure AI Search é como ter um bibliotecário que combina o conhecimento de todos esses especialistas, mas com capacidades sobre-humanas:\nOs Superpoderes do Seu Bibliotecário AI Enriquecimento com Inteligência Artificial: Imagine se o bibliotecário da British Library pudesse não apenas encontrar um documento, mas também:\nLer documentos em qualquer idioma e traduzi-los instantaneamente Extrair texto de imagens e documentos escaneados (OCR) Criar resumos automáticos de documentos extensos Identificar pessoas, lugares e conceitos importantes automaticamente Conectar informações relacionadas de diferentes documentos Isso é exatamente o que o conjunto de habilidades de IA do Azure AI Search faz durante o processo de indexação.\nOs Diferentes \u0026ldquo;Andares\u0026rdquo; da Sua Biblioteca Assim como a British Library tem diferentes seções para diferentes tipos de acervo e usuários, o Azure AI Search oferece diferentes \u0026ldquo;andares\u0026rdquo; (tiers) para diferentes necessidades empresariais:\nO Acervo Universal: Formatos Aceitos Assim como a British Library aceita praticamente qualquer tipo de material escrito ou gravado, o Azure AI Search pode processar uma impressionante variedade de formatos [2]:\nDocumentos Clássicos\nPDF: Como os livros digitalizados da British Library Microsoft Office: DOCX, XLSX, PPTX (como os documentos modernos) Texto Simples: TXT, RTF (como manuscritos antigos) Publicações Periódicas\nHTML: Como jornais online XML: Como catálogos estruturados CSV: Como registros tabulares Correspondências\nEML, MSG: Como as cartas históricas preservadas na biblioteca Materiais Especiais\nKML: Como os mapas geográficos históricos ZIP: Como coleções arquivadas JSON: Como catálogos digitais modernos Nota Importante: Assim como a British Library converte diferentes formatos para um sistema de catalogação universal, o Azure AI Search converte todos esses formatos para JSON durante a indexação, criando um sistema unificado de busca.\nComo Construir Sua Biblioteca Digital Pré-requisitos: Preparando o Terreno Antes de construir sua British Library digital, você precisará de:\nConta Azure: Como ter um terreno para construir Azure CLI: Como ter as ferramentas de construção Permissões Adequadas: Funções Search Service Contributor e Search Index Data Contributor O Processo de Construção: Da Fundação ao Funcionamento 1. Estabelecendo a Fundação (Criando o Serviço) Como escolher o local e o tamanho da sua biblioteca, você criará seu serviço Azure AI Search no portal Azure, selecionando o tier apropriado para suas necessidades.\n2. Instalando o Sistema de Segurança (Configurando Autenticação) Assim como a British Library tem sistemas de segurança sofisticados, é recomendável usar o Microsoft Entra ID para autenticação sem chave, oferecendo maior segurança que as tradicionais chaves de API.\n3. Projetando as Estantes (Criando Índices) Como um arquiteto planejando as seções da biblioteca, você definirá o esquema do seu índice, especificando quais \u0026ldquo;campos\u0026rdquo; (tipos de informação) cada documento terá. Para aplicações modernas de IA, considere incluir campos vetoriais para embeddings.\n4. Configurando o Sistema de Catalogação (Modo de Análise) Para aplicações RAG (Retrieval-Augmented Generation), o modo de análise Padrão (Default) é recomendado, pois detecta automaticamente o tipo de arquivo e usa o analisador correto - como ter um bibliotecário que reconhece automaticamente se está lidando com um livro, revista ou manuscrito.\n5. Povoando a Biblioteca (Carregando Documentos) Como transportar livros para as estantes, você populará seu índice usando indexadores automáticos (que buscam documentos de fontes como Azure Blob Storage) ou APIs para upload manual.\n6. Abrindo ao Público (Executando Consultas) Como abrir as portas da biblioteca, você usará as APIs REST ou SDKs disponíveis (.NET, Python, Java, JavaScript) para que aplicações e usuários possam consultar sua biblioteca digital.\nOs Diferentes Tipos de Consulta na Sua Biblioteca 1. Consulta de Catálogo (Pesquisa de Texto Completo) Como procurar um livro específico no catálogo da British Library pelo título ou autor. O Azure AI Search usa Apache Lucene e o algoritmo BM25 para encontrar documentos que contenham exatamente as palavras que você procura.\nExemplo: \u0026ldquo;Encontre todos os documentos que mencionam \u0026rsquo;estratégia de marketing digital'\u0026rdquo;\n2. Consulta Temática (Pesquisa Vetorial) Como pedir ao bibliotecário: \u0026ldquo;Quero algo parecido com este livro, mas não sei exatamente o que\u0026rdquo;. O Azure AI Search usa embeddings vetoriais para encontrar documentos semanticamente similares.\nExemplo: Você mostra um documento sobre \u0026ldquo;transformação digital\u0026rdquo; e o sistema encontra documentos sobre \u0026ldquo;inovação tecnológica\u0026rdquo;, \u0026ldquo;modernização de processos\u0026rdquo; e \u0026ldquo;digitalização empresarial\u0026rdquo;.\n3. Consulta de Especialista (Pesquisa Híbrida) Como combinar a precisão do catálogo com a intuição do bibliotecário especialista. O Azure AI Search combina pesquisa de texto completo com pesquisa vetorial para resultados mais relevantes e abrangentes.\n4. Consulta para Pesquisa Acadêmica (Pesquisa Multimodal) Como pesquisar não apenas em livros, mas também em mapas, imagens, gravações e outros tipos de material. O Azure AI Search pode pesquisar em diferentes tipos de conteúdo simultaneamente.\n5. Consulta de Assessoria (Pesquisa de Agente/RAG) Como ter um assistente pessoal que não apenas encontra informações, mas as organiza e apresenta de forma contextualizada para responder suas perguntas específicas. Ideal para chatbots e agentes de IA.\nInvestimento: Quanto Custa Sua British Library Digital? Comparação de Custos Considere que manter a British Library real custa milhões de libras por ano e serve milhões de pessoas. Sua British Library digital:\nTier Gratuito: Como uma biblioteca comunitária - perfeita para começar Tier Básico ($73.73/mês): Como uma biblioteca municipal bem equipada Tiers Standard ($245-$1,962/mês): Como bibliotecas universitárias de prestígio Tiers Storage Optimized ($2,802-$5,604/mês): Como ter sua própria British Library Conclusão: Sua Revolução do Conhecimento A British Library transformou o acesso ao conhecimento humano ao longo dos séculos. O Azure AI Search faz o mesmo para o conhecimento da sua empresa, mas em uma escala de tempo muito menor e com capacidades que os fundadores da British Library jamais sonharam.\nCom mais de 200 milhões de itens, a British Library prova que é possível organizar quantidades massivas de informação de forma acessível. O Azure AI Search prova que é possível fazer isso com inteligência artificial, velocidade instantânea e compreensão contextual.\nNão se trata apenas de tecnologia - trata-se de democratizar o acesso ao conhecimento dentro da sua organização, assim como a British Library democratizou o acesso ao conhecimento mundial.\nReferências [1] Introdução à IA do Azure Search - Azure AI Search | Microsoft Learn\n[2] Formatos de documento suportados - Azure AI Search | Microsoft Learn\n[3] Início Rápido: Pesquisa de Texto Completo - Azure AI Search | Microsoft Learn\n[4] Preços - Azure AI Search | Microsoft Azure\n","permalink":"https://julianamarialop.github.io/articles/azure-ai-search-sua-british-library-digital-juliana-maria/","summary":"Imagine ter acesso à British Library - a maior biblioteca do mundo com mais de 200 milhões de itens - mas dedicada exclusivamente aos documentos da sua empresa. Agora imagine que essa biblioteca tenha um bibliotecário…","title":"Azure AI Search: Sua British Library Digital Corporativa"},{"content":"Imagine que você foi contratado para construir o maior arranha-céu da cidade. Seria um projeto incrível, não é mesmo? Mas e se eu te dissesse que você precisa usar tijolos rachados, cimento vencido e vigas de ferro enferrujadas? Provavelmente você pensaria duas vezes antes de aceitar o projeto, certo?\nPois é exatamente isso que acontece quando tentamos construir um sistema de Business Intelligence (BI) com dados de baixa qualidade. Assim como um prédio precisa de materiais confiáveis, nossos relatórios e dashboards precisam de dados limpos e organizados. Valores nulos, duplicados ou inconsistentes são como rachaduras na fundação - podem não parecer perigosos no início, mas com o tempo podem derrubar toda a estrutura.\nNeste artigo, vamos aprender como ser um \u0026ldquo;engenheiro de qualidade de dados\u0026rdquo;, garantindo que nosso arranha-céu de BI seja construído sobre bases sólidas. E o melhor: vou mostrar exemplos práticos de como fazer isso no Microsoft Fabric e no Databricks !\nO Projeto do Arranha-Céu: Entendendo a Qualidade de Dados Antes de começar a construção, todo bom engenheiro precisa de um projeto bem detalhado. No mundo dos dados, esse projeto é o que chamamos de framework de qualidade de dados [1]. É como ter a planta baixa, as especificações técnicas e o cronograma da obra.\nOs Materiais de Construção (Dados Brutos) Os dados brutos que chegam dos sistemas da empresa são como os materiais que chegam no canteiro de obras:\nAlguns vêm sujos (com caracteres especiais ou espaços extras) Outros vêm quebrados (valores nulos ou incompletos) Alguns chegam no formato errado (datas como texto, números como string) E às vezes chegam materiais duplicados (o mesmo cliente cadastrado duas vezes) O Canteiro de Obras (Processo ETL) O processo de ETL (Extração, Transformação e Carga) é nosso canteiro de obras. É aqui que:\nExtraímos os materiais dos fornecedores (sistemas origem) Transformamos e limpamos os materiais (tratamos os dados) Carregamos os materiais tratados na estrutura (Data Warehouse) O Engenheiro de Qualidade (Data Steward) Todo canteiro de obras precisa de um engenheiro de qualidade que inspeciona cada material antes dele ser usado na construção. No mundo dos dados, essa pessoa é o Data Steward - o profissional responsável por garantir que apenas dados de boa qualidade entrem no nosso \u0026ldquo;arranha-céu\u0026rdquo; [2].\nAs 6 Inspeções Obrigatórias: As Dimensões da Qualidade Assim como um engenheiro faz diferentes tipos de inspeção nos materiais, precisamos verificar nossos dados em 6 aspectos fundamentais [3]:\n1. Completude: \u0026ldquo;Chegaram todos os materiais?\u0026rdquo; O que é: Verificar se todos os dados necessários estão presentes. Exemplo prático: Um cadastro de cliente sem e-mail é como tentar construir uma parede sem todos os tijolos.\nComo implementar no Fabric:\n-- Verificar completude no Fabric SELECT COUNT(*) as total_registros , COUNT(email) as emails_preenchidos , (COUNT(email) 100.0 / COUNT()) as percentual_completude FROM clientes; Como implementar no Databricks:\n# Verificar completude no Databricks from pyspark.sql.functions import col, count, when, isnan, isnull df_clientes = spark.table(\u0026#34;clientes\u0026#34;) completude_email = df_clientes.select( count(\u0026#34;*\u0026#34;).alias(\u0026#34;total\u0026#34;), count(when(col(\u0026#34;email\u0026#34;).isNotNull(), 1)).alias(\u0026#34;emails_validos\u0026#34;) ).collect()[0] percentual = (completude_email.emails_validos / completude_email.total) * 100 print(f\u0026#34;Completude do email: {percentual:.2f}%\u0026#34;) 2. Precisão: \u0026ldquo;Os materiais têm as medidas certas?\u0026rdquo; O que é: Os dados refletem corretamente a realidade. Exemplo prático: Uma viga que deveria ter 10 metros mas tem 9,5 metros pode comprometer toda a estrutura.\nComo implementar no Fabric:\n-- Validar formato de CPF no Fabric SELECT * FROM clientes WHERE LEN(REPLACE(REPLACE(cpf, \u0026#39;.\u0026#39;, \u0026#39;\u0026#39;), \u0026#39;-\u0026#39;, \u0026#39;\u0026#39;)) != 11 OR cpf NOT LIKE \u0026#39;[0-9][0-9][0-9].[0-9][0-9][0-9].[0-9][0-9][0-9]-[0-9][0-9]\u0026#39;; 3. Consistência: \u0026ldquo;As plantas estão alinhadas?\u0026rdquo; O que é: Os mesmos dados devem ser iguais em diferentes lugares. Exemplo prático: A planta do arquiteto e a do engenheiro devem mostrar a mesma parede no mesmo lugar.\nComo implementar no Databricks:\n# Verificar consistência entre tabelas no Databricks vendas_total = spark.sql(\u0026#34;\u0026#34;\u0026#34; SELECT cliente_id, SUM(valor) as total_vendas FROM vendas GROUP BY cliente_id \u0026#34;\u0026#34;\u0026#34;) clientes_total = spark.sql(\u0026#34;\u0026#34;\u0026#34; SELECT cliente_id, total_compras FROM clientes \u0026#34;\u0026#34;\u0026#34;) inconsistencias = vendas_total.join( clientes_total, \u0026#34;cliente_id\u0026#34;, \u0026#34;inner\u0026#34; ).filter( col(\u0026#34;total_vendas\u0026#34;) != col(\u0026#34;total_compras\u0026#34;) ) inconsistencias.show() 4. Conformidade: \u0026ldquo;Os materiais seguem as normas técnicas?\u0026rdquo; O que é: Os dados seguem os padrões e formatos definidos. Exemplo prático: Todos os parafusos devem ser do tipo especificado na norma ABNT.\n5. Integridade: \u0026ldquo;As conexões estão firmes?\u0026rdquo; O que é: As relações entre diferentes dados são válidas. Exemplo prático: Cada coluna do 5º andar deve estar conectada à fundação correspondente.\n6. Atualidade: \u0026ldquo;Estamos usando a planta mais recente?\u0026rdquo; O que é: Os dados são recentes o suficiente para serem úteis. Exemplo prático: Usar uma planta de 2020 para construir em 2024 pode gerar problemas.\nO Maior Vilão: Os Valores Nulos (Materiais Faltando) Imagine que você está construindo uma parede e, de repente, percebe que faltam alguns tijolos. O que fazer? Deixar o buraco? Improvisar com outro material? Parar a obra até os tijolos chegarem?\nNo mundo dos dados, os valores nulos são exatamente esses \u0026ldquo;tijolos faltando\u0026rdquo;. E a forma como lidamos com eles pode fazer a diferença entre um prédio seguro e um desastre [4].\nCenário 1: Falta Material na Decoração (Atributos de Dimensão) Situação: Um cliente não tem o campo \u0026ldquo;estado\u0026rdquo; preenchido porque mora no exterior. Solução: Em vez de deixar em branco, colocamos \u0026ldquo;Não se Aplica\u0026rdquo; ou \u0026ldquo;Internacional\u0026rdquo;.\nImplementação no Fabric:\n-- Tratar nulos em dimensões no Fabric UPDATE dim_clientes SET estado = CASE WHEN estado IS NULL AND pais != \u0026#39;Brasil\u0026#39; THEN \u0026#39;Internacional\u0026#39; WHEN estado IS NULL AND pais = \u0026#39;Brasil\u0026#39; THEN \u0026#39;Não Informado\u0026#39; ELSE estado END; Implementação no Databricks:\n# Tratar nulos em dimensões no Databricks from pyspark.sql.functions import when, col df_clientes_tratado = df_clientes.withColumn( \u0026#34;estado_tratado\u0026#34;, when(col(\u0026#34;estado\u0026#34;).isNull() \u0026amp; (col(\u0026#34;pais\u0026#34;) != \u0026#34;Brasil\u0026#34;), \u0026#34;Internacional\u0026#34;) .when(col(\u0026#34;estado\u0026#34;).isNull() \u0026amp; (col(\u0026#34;pais\u0026#34;) == \u0026#34;Brasil\u0026#34;), \u0026#34;Não Informado\u0026#34;) .otherwise(col(\u0026#34;estado\u0026#34;)) ) Cenário 2: Falta Material na Estrutura (Chaves Estrangeiras) Situação: Uma venda foi registrada, mas o produto ainda não existe no cadastro. Solução: Criamos um \u0026ldquo;produto temporário\u0026rdquo; até o cadastro correto chegar.\nImplementação no Databricks com Delta Lake:\n# Implementar \u0026#34;Inferred Members\u0026#34; no Databricks def tratar_produto_inexistente(df_vendas, df_produtos): # Identificar produtos que não existem produtos_faltando = df_vendas.select(\u0026#34;produto_id\u0026#34;).distinct() \\ .join(df_produtos.select(\u0026#34;produto_id\u0026#34;), \u0026#34;produto_id\u0026#34;, \u0026#34;left_anti\u0026#34;) # Criar registros temporários produtos_temporarios = produtos_faltando.withColumn( \u0026#34;nome_produto\u0026#34;, lit(\u0026#34;Produto Pendente\u0026#34;) ).withColumn( \u0026#34;categoria\u0026#34;, lit(\u0026#34;Aguardando Cadastro\u0026#34;) ).withColumn( \u0026#34;status\u0026#34;, lit(\u0026#34;Temporário\u0026#34;) ) # Adicionar à tabela de produtos df_produtos_completo = df_produtos.union(produtos_temporarios) return df_produtos_completo Automatizando a Inspeção: Ferramentas do Engenheiro No Microsoft Fabric: Data Quality Rules -- Criar regra de qualidade no Fabric CREATE OR ALTER PROCEDURE sp_validar_qualidade_clientes AS BEGIN -- Verificar completude DECLARE @completude_email FLOAT = ( SELECT COUNT(email) * 100.0 / COUNT(*) FROM clientes ); -- Verificar duplicatas DECLARE @duplicatas INT = ( SELECT COUNT(*) - COUNT(DISTINCT cpf) FROM clientes ); -- Alertar se qualidade baixa IF @completude_email \u0026lt; 90 OR @duplicatas \u0026gt; 0 BEGIN PRINT \u0026#39;ALERTA: Qualidade dos dados abaixo do esperado!\u0026#39;; PRINT \u0026#39;Completude email: \u0026#39; + CAST(@completude_email AS VARCHAR(10)) + \u0026#39;%\u0026#39;; PRINT \u0026#39;Duplicatas encontradas: \u0026#39; + CAST(@duplicatas AS VARCHAR(10)); END END; No Databricks: Great Expectations # Implementar validação automática no Databricks import great_expectations as ge # Criar expectativas de qualidade df_ge = ge.from_pandas(df_clientes.toPandas()) # Definir regras df_ge.expect_column_to_exist(\u0026#34;email\u0026#34;) df_ge.expect_column_values_to_not_be_null(\u0026#34;email\u0026#34;, mostly=0.9) df_ge.expect_column_values_to_be_unique(\u0026#34;cpf\u0026#34;) df_ge.expect_column_values_to_match_regex(\u0026#34;cpf\u0026#34;, r\u0026#34;^\\d{3}\\.\\d{3}\\.\\d{3}-\\d{2}$\u0026#34;) # Executar validação resultado = df_ge.validate() print(f\u0026#34;Validação passou: {resultado.success}\u0026#34;) Monitoramento Contínuo: A Manutenção do Prédio Assim como um prédio precisa de manutenção regular, nossos dados precisam de monitoramento contínuo.\nDashboard de Qualidade no Fabric: -- Métricas de qualidade para dashboard SELECT \u0026#39;Clientes\u0026#39; as tabela, COUNT(*) as total_registros, COUNT(email) * 100.0 / COUNT(*) as completude_email, COUNT(DISTINCT cpf) * 100.0 / COUNT(*) as unicidade_cpf, GETDATE() as data_verificacao FROM clientes UNION ALL SELECT \u0026#39;Produtos\u0026#39; as tabela, COUNT(*) as total_registros, COUNT(nome) * 100.0 / COUNT(*) as completude_nome, COUNT(DISTINCT codigo) * 100.0 / COUNT(*) as unicidade_codigo, GETDATE() as data_verificacao FROM produtos; Alertas Automáticos no Databricks: # Sistema de alertas no Databricks def verificar_qualidade_e_alertar(): # Verificar qualidade qualidade = calcular_metricas_qualidade() # Definir thresholds thresholds = { \u0026#39;completude_minima\u0026#39;: 95, \u0026#39;duplicatas_maximas\u0026#39;: 0, \u0026#39;precisao_minima\u0026#39;: 98 } # Verificar alertas alertas = [] for metrica, valor in qualidade.items(): if metrica in thresholds: if valor \u0026lt; thresholds[metrica]: alertas.append(f\u0026#34; {metrica}: {valor}% (esperado: {thresholds[metrica]}%)\u0026#34;) # Enviar alertas se necessário if alertas: enviar_notificacao_slack(alertas) # Agendar execução dbutils.jobs.taskValues.set(\u0026#34;alertas_qualidade\u0026#34;, verificar_qualidade_e_alertar()) Conclusão: Seu Arranha-Céu Está Pronto! Construir um sistema de BI com dados de qualidade é como erguer um arranha-céu: exige planejamento, materiais de qualidade, inspeções rigorosas e manutenção constante. Mas quando tudo está funcionando bem, você tem uma estrutura sólida que pode suportar qualquer decisão de negócio.\nLembre-se sempre:\nPlaneje antes de construir: Defina seu framework de qualidade Inspecione todos os materiais: Implemente as 6 dimensões de qualidade Trate os problemas na origem: Não deixe valores nulos se acumularem Monitore constantemente: Use ferramentas automáticas de validação Mantenha a estrutura: Qualidade de dados é um processo contínuo Com essas práticas e as ferramentas do Fabric e Databricks, você estará pronto para construir o arranha-céu de dados mais confiável da sua empresa! Até a próxima !\nReferências [1] LakeFS. (2025). Data Quality Framework: Best Practices \u0026amp; Tools. https://lakefs.io/data-quality/data-quality-framework/\n[2] Hauskrecht, A. (s.d.). Building a Data Warehouse Data Quality Process. Toptal. https://www.toptal.com/database/data-warehouse-data-quality-process\n[3] Data Science Academy. (2023). As 6 Dimensões da Qualidade de Dados (Data Quality). https://blog.dsacademy.com.br/as-6-dimensoes-da-qualidade-de-dados-data-quality/\n[4] Iverson, H. K., \u0026amp; Oates, J. (2016). How to Manage Null Values in Your Data Warehouse. TDAN.com.\n","permalink":"https://julianamarialop.github.io/articles/construindo-um-arranha-ceu-de-dados-como-garantir-qualidade/","summary":"Imagine que você foi contratado para construir o maior arranha-céu da cidade. Seria um projeto incrível, não é mesmo? Mas e se eu te dissesse que você precisa usar tijolos rachados, cimento vencido e vigas de ferro…","title":"Construindo um Arranha-Céu de Dados: Como Garantir Qualidade no seu BI"},{"content":"Na engenharia aeroespacial, o fracasso não é uma opção. Cada lançamento de foguete, cada manobra orbital e cada aterrissagem em um planeta distante é o resultado de milhares de horas de testes, simulações e verificações. O menor erro de cálculo pode levar à perda de um equipamento de bilhões de dólares. E se aplicássemos essa mesma disciplina e rigor para proteger nossos ativos de dados mais críticos?\nNo mundo dos dados, um pipeline com falha pode não desintegrar na reentrada, mas pode corromper a \u0026ldquo;fonte da verdade\u0026rdquo; de uma empresa, levando a decisões de negócio baseadas em informações falsas. Para evitar esse desastre, podemos nos inspirar nas estratégias de mitigação de risco da exploração espacial e aplicá-las aos nossos pipelines no Microsoft Fabric ou Azure Data Factory (ADF).\nVamos embarcar em nossa própria missão a Marte, usando três conceitos-chave da engenharia de software: Dry Run, Canary e Shadow.\nA Origem: Estratégias de uma Missão Espacial Imagine que somos a agência espacial encarregada de enviar uma nova missão tripulada a Marte. O risco é imenso, e cada etapa deve ser validada.\nDry Run (A Simulação de Voo): Muito antes de o foguete chegar à plataforma de lançamento, os astronautas e a equipe de controle da missão passam meses em simuladores de voo. Eles executam a missão inteira do lançamento à aterrissagem em um ambiente virtual hiper-realista. Nenhum combustível é queimado, nenhum hardware real é arriscado. O objetivo é memorizar cada procedimento, testar cada resposta a emergências e validar cada linha do plano de voo. É a validação da lógica em sua forma mais pura. Canary (O Robô Pioneiro): Enviar humanos diretamente seria imprudente. Primeiro, a agência envia um robô explorador, um rover como o Perseverance, para ser nosso \u0026ldquo;canário\u0026rdquo;. Esta missão precursora, de custo relativamente menor, aterrissa em Marte para testar as condições reais. Ele analisa a atmosfera, perfura o solo e envia terabytes de dados de volta. Os cientistas na Terra monitoram seu desempenho: os painéis solares resistiram à poeira? Os sistemas de comunicação funcionaram? Se o rover falhar, a perda é contida, e as lições aprendidas são inestimáveis para a segurança da futura missão tripulada. Shadow (O Gêmeo Digital na Terra): No centro de controle da missão, os engenheiros operam uma réplica exata da nave espacial como um \u0026ldquo;gêmeo digital\u0026rdquo; que existe em supercomputadores ou até mesmo como um modelo físico. Enquanto a nave real viaja pelo espaço, o gêmeo na Terra recebe exatamente os mesmos dados de telemetria e executa os mesmos comandos em paralelo. A missão principal continua, sem ser afetada. Isso permite que a equipe teste manobras futuras (como uma correção de curso) no gêmeo \u0026ldquo;sombra\u0026rdquo; antes de enviá-las para a nave real, ou simule como a nave reagiria a uma anomalia, comparando o resultado com os dados reais. É o teste de estresse final, com dados do mundo real, mas com risco zero para a missão. Traduzindo para Pipelines de Dados no Fabric e ADF Agora, vamos trazer esses conceitos de volta à Terra e aplicá-los para garantir que nossos pipelines de dados sejam à prova de falhas.\n1. Dry Run: A Simulação de Voo do Seu Pipeline Um \u0026ldquo;dry run\u0026rdquo; em um pipeline de dados executa toda a sua lógica de transformação sem de fato carregar (ou \u0026ldquo;aterrissar\u0026rdquo;) os dados no seu destino final, como um Lakehouse ou Warehouse de produção.\nObjetivo: Validar a \u0026ldquo;trajetória\u0026rdquo; e a lógica do seu pipeline, capturando erros de schema ou de cálculo antes de consumir recursos significativos ou arriscar a integridade dos dados de produção.\n2. Canary: O Robô Pioneiro em Seus Dados A implantação canário processa um subconjunto pequeno e controlado dos seus dados de produção (uma região, uma linha de produto, uma loja) com a nova lógica do pipeline, enquanto a maior parte dos dados continua sendo processada pela versão antiga e estável.\nObjetivo: Testar o impacto da nova lógica com dados de produção reais, limitando o \u0026ldquo;raio da explosão\u0026rdquo; de um possível problema a um segmento pequeno e controlado.\n3. Shadow: O Gêmeo Digital do Seu Pipeline A implantação sombra é a sua rede de segurança definitiva. Ela executa o novo pipeline em paralelo com o antigo, usando os mesmos dados de entrada, mas escrevendo em um destino \u0026ldquo;sombra\u0026rdquo; completamente isolado.\nObjetivo: Validar a correção, o desempenho e o custo da nova versão do pipeline sob 100% da carga de produção, com risco zero para os dados que os astronautas (seus tomadores de decisão) usam para navegar.\nAo adotar a mentalidade de um engenheiro de missão, você transforma o desenvolvimento de pipelines de uma arte incerta em uma ciência exata. Ao simular, enviar pioneiros e operar com gêmeos digitais, você garante que cada \u0026ldquo;lançamento\u0026rdquo; de dados seja um sucesso garantido.\nEspero que esta jornada através da metáfora da missão espacial tenha tornado esses conceitos mais claros e tangíveis. Assim como os engenheiros aeroespaciais não deixam nada ao acaso, nós, como engenheiros de dados, também podemos adotar uma abordagem mais segura e disciplinada. Que as técnicas de Dry Run, Canary e Shadow sirvam como seu centro de controle de missão, ajudando você a navegar pelas complexidades de seus projetos e garantindo que cada implementação seja uma aterrissagem perfeita.\nAté o próximo artigo !\n","permalink":"https://julianamarialop.github.io/articles/missao-marte-como-proteger-seus-pipelines-de-dados-com/","summary":"Na engenharia aeroespacial, o fracasso não é uma opção. Cada lançamento de foguete, cada manobra orbital e cada aterrissagem em um planeta distante é o resultado de milhares de horas de testes, simulações e…","title":"Missão Marte: Como Proteger Seus Pipelines de Dados com a Precisão da Engenharia Aeroespacial"},{"content":"O Sonho Prometido\nEm maio de 2023, a Microsoft anunciou o Microsoft Fabric como uma solução revolucionária para unificar todos os workloads analíticos em uma única plataforma. A promessa era ambiciosa: lakehouse, data warehouse, real-time analytics e machine learning funcionando de forma integrada, eliminando a necessidade de múltiplas ferramentas especializadas.\nA recepção inicial foi extremamente positiva. CTOs e arquitetos de dados vislumbraram um futuro onde poderiam simplificar suas arquiteturas de dados, reduzir custos operacionais e acelerar a entrega de insights. As demonstrações técnicas impressionaram, mostrando dados fluindo entre diferentes workloads sem friction aparente.\nHoje, quase dois anos após o lançamento, Microsoft Fabric ainda não alcançou a adoção esperada no mercado enterprise. Apesar de melhorias significativas na plataforma, muitas organizações permanecem hesitantes em migrar de suas soluções atuais. Esta análise examina os principais fatores que contribuíram para esta situação.\nAto I: O Prelúdio da Promessa Cena 1: A Grande Abertura Quando Microsoft Fabric foi anunciado em maio de 2023, a expectativa era de uma revolução no mercado de plataformas de dados. A Microsoft identificou corretamente o maior problema da era moderna dos dados: a fragmentação. Empresas gastavam recursos significativos mantendo múltiplas plataformas como Synapse para data warehousing, Power BI para visualização, Azure ML para machine learning e Data Factory para ETL, cada uma com sua própria curva de aprendizado, modelo de pricing e limitações técnicas.\nFabric foi posicionado como a solução unificadora, prometendo que todas essas necessidades poderiam ser atendidas em uma única plataforma integrada. A proposta de valor era clara: OneLake como storage unificado, compute compartilhado entre workloads, governança centralizada e uma experiência de usuário consistente. Para organizações cansadas de gerenciar múltiplas ferramentas, Fabric representava uma simplificação significativa.\nA estratégia de go-to-market foi bem executada. Demonstrações técnicas mostravam dados fluindo seamlessly entre diferentes workloads, cientistas de dados colaborando com engenheiros de dados no mesmo ambiente, e executivos obtendo insights em tempo real através de dashboards integrados. A mensagem era consistente: simplicidade, eficiência e inovação em uma única plataforma.\nCena 2: Os Primeiros Acordes Dissonantes No entanto, organizações que adotaram Fabric nos primeiros meses descobriram uma realidade diferente da apresentada nas demonstrações. Os primeiros problemas se tornaram evidentes rapidamente, criando hesitação no mercado.\nO primeiro obstáculo foi o modelo de pricing. Diferentemente das soluções tradicionais com modelos pay-as-you-go transparentes, Fabric introduziu um sistema de capacidade baseado em Capacity Units (CUs) que muitas organizações consideraram confuso e imprevisível. Empresas acostumadas com modelos de pricing claros do Databricks ou Snowflake se viram perdidas tentando estimar custos reais de seus workloads no Fabric.\nA documentação, fundamental para adoção enterprise, estava incompleta e fragmentada. Recursos prometidos apareciam marcados como \u0026ldquo;preview\u0026rdquo; ou \u0026ldquo;coming soon\u0026rdquo;, deixando arquitetos de dados hesitantes em apostar projetos críticos em uma plataforma que ainda não estava totalmente madura. A sensação era de estar trabalhando com uma versão beta sendo comercializada como produto final.\nAto II: A Tragédia dos Custos Cena 1: O Fantasma do F64+ O requisito de capacidade mínima F64 para muitas funcionalidades avançadas do Fabric se tornou um dos maiores obstáculos para adoção. Este requisito representa um investimento significativo que muitas organizações não estavam preparadas para fazer.\nUma capacidade F64 custa aproximadamente $8.400 por mês, ou mais de $100.000 anuais. Para muitas organizações, especialmente pequenas e médias empresas, este valor representa um investimento substancial que precisa ser justificado com ROI claro e imediato. O problema é que Fabric, em seus primeiros anos, não conseguiu demonstrar este ROI de forma convincente para a maioria dos casos de uso.\nA situação se torna mais complexa quando comparamos com alternativas. Uma implementação equivalente no Databricks, especialmente para workloads de machine learning e data science, frequentemente custa uma fração do preço do F64+. Organizações que migraram do Synapse para o Databricks nos últimos anos descobriram que podiam obter mais funcionalidades por menos dinheiro, criando um precedente difícil de superar.\nCena 2: A Armadilha da Capacidade O modelo de capacidade do Fabric, embora inovador em teoria, criou desafios práticos significativos. Diferentemente de plataformas que escalam automaticamente baseadas na demanda, Fabric requer que organizações comprem capacidade antecipadamente, criando um dilema: comprar capacidade insuficiente resulta em throttling e performance degradada, enquanto comprar capacidade excessiva resulta em desperdício de recursos.\nEsta dinâmica criou uma nova necessidade operacional: o gerenciamento dedicado de capacidade Fabric. Organizações descobriram que precisavam de expertise adicional não apenas para usar a plataforma, mas para gerenciar seus custos de forma eficiente. Isso adicionou complexidade operacional que muitas empresas não anteciparam.\nA falta de ferramentas maduras de cost management agravou o problema. Enquanto AWS, Azure e GCP oferecem dashboards sofisticados para monitoramento de custos, Fabric demorou para desenvolver ferramentas equivalentes, deixando organizações com visibilidade limitada sobre seus gastos em CUs.\nAto III: O Timing Perdido Cena 1: A Migração que Não Esperou O timing de lançamento do Fabric pode ter sido o erro mais crítico da Microsoft. Quando Fabric foi lançado em 2023, muitas organizações já haviam completado suas migrações do Azure Synapse para o Databricks . Esta migração, que aconteceu principalmente entre 2021 e 2023, foi motivada pelas limitações do Synapse e pela superioridade técnica do Databricks em workloads de machine learning e data science.\nOrganizações que investiram meses ou anos migrando para Databricks, treinando equipes e estabelecendo processos, não estavam dispostas a embarcar em outra migração disruptiva tão rapidamente. O custo de mudança não era apenas financeiro, mas também incluía produtividade perdida, risco operacional e fadiga de mudança organizacional.\nA Microsoft perdeu uma janela crítica de oportunidade. Se Fabric tivesse sido lançado em 2021, poderia ter capturado muitas das organizações que eventualmente migraram para Databricks. Em 2023, essas organizações já estavam estabelecidas em suas novas plataformas e começando a colher os benefícios de suas migrações.\nCena 2: A Maturidade da Concorrência Enquanto Fabric lutava com seus problemas de juventude, a concorrência não ficou parada. Databricks continuou inovando agressivamente, lançando funcionalidades como Unity Catalog para governança, Delta Live Tables para ETL em tempo real, e MLflow para MLOps. Snowflake expandiu suas capacidades além de data warehousing, adicionando suporte robusto para machine learning e data science.\nMais importante, essas plataformas maduras ofereciam algo que Fabric ainda não conseguia: previsibilidade. Organizações sabiam exatamente o que esperar em termos de performance, custos e funcionalidades. Fabric, por outro lado, ainda estava em constante evolução, com recursos sendo adicionados, modificados ou descontinuados regularmente.\nA estabilidade se tornou um fator decisivo. CTOs, queimados por implementações problemáticas de tecnologias imaturas, preferiam apostar em plataformas comprovadas do que arriscar suas carreiras em uma promessa, por mais brilhante que fosse.\nAto IV: As Limitações Técnicas Cena 1: A Realidade vs. a Promessa Conforme organizações começaram a implementar Fabric em cenários reais, as limitações técnicas se tornaram aparentes. A promessa de unificação, embora atraente em teoria, esbarrava em realidades práticas que a Microsoft não havia antecipado completamente.\nWorkloads de machine learning, especialmente aqueles que requeriam GPUs especializadas ou frameworks específicos, encontraram limitações no Fabric que não existiam no Databricks. A flexibilidade de configuração, crucial para casos de uso avançados, era mais restrita no Fabric, forçando organizações a fazer concessões em suas arquiteturas.\nA integração prometida entre diferentes workloads, embora funcional, não era tão seamless quanto anunciado. Cientistas de dados descobriram que ainda precisavam entender as nuances de diferentes engines e otimizar seus códigos para cada contexto específico. A promessa de \u0026ldquo;escreva uma vez, rode em qualquer lugar\u0026rdquo; se mostrou mais complexa na prática.\nCena 2: A Curva de Aprendizado Íngreme Paradoxalmente, uma plataforma projetada para simplificar a vida dos profissionais de dados acabou criando uma nova camada de complexidade. Profissionais experientes em Spark, SQL Server ou Power BI descobriram que precisavam reaprender conceitos fundamentais para trabalhar eficientemente no Fabric.\nA documentação fragmentada e a rápida evolução da plataforma tornaram o treinamento um desafio constante. Organizações descobriram que precisavam investir significativamente em capacitação, não apenas para novos funcionários, mas para requalificar equipes experientes.\nEsta curva de aprendizado se tornou um obstáculo adicional para adoção. Em um mercado de trabalho competitivo, onde profissionais qualificados são escassos, organizações hesitavam em apostar em uma tecnologia que requeria investimento substancial em treinamento sem garantias de retorno.\nAto V: O Despertar Tardio Cena 1: Os Sinais de Mudança Reconhecendo os desafios, a Microsoft começou a fazer ajustes significativos em 2024 e 2025. A remoção do requisito F64+ para algumas funcionalidades foi um primeiro passo importante, sinalizando que a empresa estava ouvindo o feedback do mercado.\nInvestimentos em documentação, ferramentas de cost management e estabilização da plataforma mostraram que a Microsoft estava levando a sério as críticas. Parcerias estratégicas e integrações com ferramentas populares do ecossistema de dados demonstraram uma abordagem mais pragmática e menos proprietária.\nA introdução de modelos de pricing mais flexíveis e ferramentas de otimização de custos indicou que a Microsoft estava aprendendo com os erros iniciais. Porém, a questão permanecia: seria tarde demais para recuperar o momentum perdido?\nCena 2: A Batalha pela Redenção Hoje, Microsoft Fabric se encontra em uma encruzilhada. Por um lado, a plataforma evoluiu significativamente desde seu lançamento, resolvendo muitos dos problemas iniciais e adicionando funcionalidades robustas. Por outro lado, a janela de oportunidade inicial se fechou, e a Microsoft agora precisa convencer organizações já estabelecidas em outras plataformas a considerar uma mudança.\nA estratégia atual parece focar em casos de uso específicos onde Fabric oferece vantagens claras, especialmente para organizações já investidas no ecossistema Microsoft. A integração nativa com Microsoft 365, Azure e Power BI cria um valor único para certas organizações.\nPorém, a realidade é que Fabric perdeu a chance de ser a escolha óbvia para novas implementações. Agora precisa lutar por cada cliente, competindo não apenas em funcionalidades, mas também em preço, maturidade e ecossistema.\nEpílogo: Lições de uma Tragédia Anunciada A história do Microsoft Fabric serve como um estudo de caso fascinante sobre como timing, pricing e execução podem determinar o sucesso ou fracasso de uma tecnologia, independentemente de seu mérito técnico. Fabric não é uma má plataforma - na verdade, em muitos aspectos, representa uma visão inovadora do futuro dos dados. Porém, uma série de decisões estratégicas e limitações de execução impediram que realizasse seu potencial.\nA lição mais importante é que no mundo enterprise, a percepção é frequentemente mais importante que a realidade. Fabric pode ter resolvido muitos de seus problemas iniciais, mas a primeira impressão já estava formada. Organizações que tiveram experiências negativas nos primeiros meses raramente dão uma segunda chance, especialmente quando alternativas maduras estão disponíveis.\nO futuro do Fabric permanece incerto. A Microsoft tem recursos e determinação para continuar investindo na plataforma, e há sinais de que está aprendendo com os erros. Porém, a janela para se tornar a plataforma dominante no mercado de dados pode ter se fechado permanentemente.\nComo toda ópera trágica, a história do Fabric nos lembra que mesmo os heróis mais promissores podem falhar quando o destino conspira contra eles. A questão que permanece é se esta é realmente uma tragédia ou apenas o primeiro ato de uma eventual redenção.\nFim do Primeiro Movimento\nAté o próximo artigo !\n","permalink":"https://julianamarialop.github.io/articles/la-traviata-dos-dados-opera-tragica-de-como-o-fabric-nao/","summary":"Em maio de 2023, a Microsoft anunciou o Microsoft Fabric como uma solução revolucionária para unificar todos os workloads analíticos em uma única plataforma. A promessa era ambiciosa: lakehouse, data warehouse…","title":"La Traviata dos Dados: A Ópera Trágica de Como o Fabric Não Conquistou o Mercado"},{"content":"Assim como Clark Kent precisava se transformar em Superman para que pessoas comuns pudessem ser salvas, o mundo dos dados sempre exigiu que usuários de negócios se transformassem em \u0026ldquo;super-técnicos\u0026rdquo; para acessar insights valiosos. Por décadas, dashboards, análises e inteligência artificial permaneceram trancados em uma fortaleza da solidão tecnológica, acessíveis apenas para aqueles com superpoderes em SQL, Python ou engenharia de dados.\nO Databricks acaba de lançar sua versão do Superman: o Databricks One. Esta nova interface não é apenas uma atualização cosmética é uma transformação fundamental que promete democratizar o acesso aos dados da mesma forma que Superman democratiza a esperança. Assim como o Homem de Aço torna o impossível possível para cidadãos comuns, o Databricks One torna análises complexas acessíveis para qualquer usuário de negócios.\nEm um mundo onde dados são o novo petróleo, o Databricks One surge como o herói que finalmente entrega superpoderes analíticos nas mãos de quem realmente precisa tomar decisões: gerentes de vendas, diretores de marketing, analistas de negócios e executivos que, até agora, dependiam de \u0026ldquo;tradutores\u0026rdquo; técnicos para entender o que seus próprios dados estavam tentando lhes dizer.\nA Origem do Herói: De Krypton Técnico para a Terra dos Negócios Toda história de super-herói começa com uma origem, e a do Databricks One não é diferente. Assim como Superman veio de Krypton um planeta tecnologicamente avançado mas inacessível para terráqueos - o Databricks tradicional nasceu no mundo dos engenheiros de dados e cientistas, um universo de notebooks complexos, clusters configuráveis e linguagens de programação que intimidavam usuários de negócios.\nPor anos, o Databricks foi como o Superman ainda em Krypton: incrivelmente poderoso, mas operando em uma dimensão que pessoas comuns não conseguiam alcançar. A transformação começou quando a equipe do Databricks percebeu que ter superpoderes não significa nada se você não pode usá-los para ajudar pessoas comuns.\nO resultado é uma interface que mantém toda a força do Databricks original, mas apresenta essa força de uma forma que qualquer pessoa pode entender e usar. É como se Superman tivesse aprendido a controlar perfeitamente seus poderes para que pudesse ajudar tanto a parar um meteoro quanto a resgatar um gato de uma árvore - a mesma força, aplicada de forma apropriada para cada situação.\nOs Superpoderes do Databricks One Assim como Superman possui uma variedade de superpoderes que o tornam único, o Databricks One vem equipado com habilidades especiais que transformam a experiência de usuários de negócios com dados.\nVisão de Raio-X para Complexidade Técnica\nO primeiro superpoder do Databricks One é sua capacidade de \u0026ldquo;ver através\u0026rdquo; da complexidade técnica e apresentar apenas o que importa para decisões de negócios. Assim como Superman pode usar sua visão de raio-X para ver através de paredes e focar exatamente no que precisa, o Databricks One remove todas as camadas técnicas desnecessárias e mostra apenas dashboards, insights e análises prontas para consumo.\nUsuários não precisam mais entender conceitos como \u0026ldquo;particionamento de dados\u0026rdquo; ou \u0026ldquo;otimização de queries\u0026rdquo;. Eles simplesmente veem seus KPIs, métricas de vendas, análises de marketing e projeções financeiras apresentadas de forma clara e acionável.\nSuper Velocidade na Tomada de Decisões\nOutro superpoder crucial é a velocidade. Assim como Superman pode voar ao redor do mundo em segundos, o Databricks One elimina a latência entre ter uma pergunta de negócios e obter uma resposta baseada em dados. Não há mais necessidade de abrir tickets para a equipe de TI, esperar que alguém escreva uma query SQL, ou aguardar que um relatório seja gerado manualmente.\nCom a interface simplificada, um gerente de vendas pode verificar o desempenho de sua equipe, identificar tendências e ajustar estratégias em tempo real. Um diretor de marketing pode analisar o ROI de campanhas e realocar orçamentos instantaneamente.\nForça Super-Humana para Democratização\nO terceiro superpoder é talvez o mais importante: a força para quebrar barreiras organizacionais que mantinham dados concentrados nas mãos de poucos. Assim como Superman usa sua força para remover obstáculos que pessoas comuns não conseguiriam mover, o Databricks One remove as barreiras técnicas que impediam a democratização real dos dados.\nEsta força democratizadora significa que insights valiosos não ficam mais presos em silos técnicos. Uma analista de RH pode entender padrões de rotatividade sem precisar aprender Python. Um controller financeiro pode criar projeções complexas sem dominar linguagens de programação.\nA Liga da Justiça dos Dados Superman raramente trabalha sozinho quando enfrenta ameaças que exigem múltiplas habilidades. Ele se une à Liga da Justiça, onde cada herói contribui com seus poderes únicos. O Databricks One funciona de forma similar, orquestrando diferentes \u0026ldquo;super-heróis\u0026rdquo; tecnológicos.\nGenie: O Flash dos Insights Instantâneos\nDentro do universo Databricks One, o Genie funciona como o Flash, o velocista que pode processar informações e entregar respostas em velocidade sobre-humana. Quando um usuário faz uma pergunta em linguagem natural como \u0026ldquo;Quais foram nossos produtos mais vendidos no último trimestre?\u0026rdquo;, o Genie processa essa solicitação instantaneamente, consulta terabytes de dados e retorna insights precisos em segundos.\nDashboards: A Mulher Maravilha da Visualização\nOs dashboards no Databricks One funcionam como a Mulher Maravilha elegantes, poderosos e capazes de revelar verdades ocultas com clareza cristalina. Estes dashboards não são apenas gráficos bonitos são ferramentas de revelação que mostram tendências, anomalias e oportunidades que permaneceriam invisíveis em planilhas tradicionais.\nConsumer Entitlement: O Aquaman da Governança\nO sistema de \u0026ldquo;consumer entitlement\u0026rdquo; funciona como o Aquaman um herói frequentemente subestimado, mas essencial para manter o equilíbrio e a ordem. Este sistema de governança é crucial porque democratização sem controle seria caos, protegendo tanto a segurança dos dados quanto a produtividade dos usuários.\nSalvando Metrópolis: Casos de Uso Reais Assim como Superman não salva apenas o mundo de ameaças cósmicas, mas também ajuda com problemas cotidianos, o Databricks One resolve tanto desafios estratégicos quanto necessidades operacionais diárias.\nO Resgate do Gerente de Vendas\nMaria, gerente de vendas de uma empresa de software, costumava passar horas toda segunda-feira compilando relatórios de performance da equipe. Com o Databricks One, Maria agora acessa um dashboard simples que mostra automaticamente quais vendedores estão próximos de bater suas metas, quais produtos estão com performance abaixo do esperado, e quais regiões apresentam oportunidades inexploradas.\nO resultado? Maria reduziu seu tempo de preparação de relatórios de 4 horas para 15 minutos, e agora dedica esse tempo extra para coaching individual. Seus números de vendas aumentaram 23% no primeiro trimestre após a implementação.\nA Transformação do Diretor de Marketing\nCarlos, diretor de marketing, sempre se sentiu como se estivesse lutando contra os dados em vez de ser ajudado por eles. O Databricks One transformou Carlos de antagonista dos dados em herói da ROI. Agora ele pode ver em tempo real quais campanhas estão gerando leads qualificados, quais canais têm melhor custo de aquisição, e quais mensagens ressoam melhor com diferentes segmentos.\nO impacto foi dramático: Carlos reduziu o desperdício em campanhas ineficazes em 40% e aumentou a geração de leads qualificados em 60%.\nO Empoderamento da Analista de RH\nAna, analista de RH, sempre dependeu de outros para acessar as informações de que precisava. Com o Databricks One, Ana evoluiu para uma investigadora independente capaz de descobrir insights cruciais sobre talentos. Ela agora identifica proativamente funcionários em risco de deixar a empresa, correlaciona programas de treinamento com aumentos de performance, e prevê necessidades futuras de contratação.\nAna ajudou a reduzir a rotatividade em 35% identificando e abordando fatores de risco antes que se tornassem problemas.\nA Kryptonita da Democratização Mesmo Superman tem sua kryptonita uma fraqueza que pode neutralizar todos os seus superpoderes se não for adequadamente gerenciada. O Databricks One também enfrenta desafios que podem limitar sua eficácia.\nKryptonita Verde: A Resistência à Mudança\nA primeira forma de kryptonita é a resistência organizacional à mudança. Esta resistência frequentemente vem de equipes técnicas que temem perder relevância e usuários de negócios que desenvolveram dependência de \u0026ldquo;especialistas\u0026rdquo;. A solução é redefini-las: equipes técnicas evoluem de \u0026ldquo;tradutores\u0026rdquo; para \u0026ldquo;arquitetos\u0026rdquo; de soluções mais sofisticadas, e usuários ganham capacidade de fazer perguntas mais inteligentes.\nKryptonita Vermelha: O Caos da Democratização Descontrolada\nDemocratização de dados sem governança adequada pode criar caos organizacional - usuários tomando decisões baseadas em dados incorretos ou chegando a conclusões contraditórias. A proteção vem através de estruturas de governança que garantem que a democratização aumente a eficácia sem sacrificar a consistência.\nKryptonita Dourada: A Paralisia da Análise Infinita\nQuando o acesso fácil a dados leva a análises infinitas sem decisões correspondentes, usuários podem ficar tão fascinados com a capacidade de explorar dados que perdem de vista o objetivo de tomar decisões melhores. A proteção requer manter foco nos prazos e objetivos, valorizando \u0026ldquo;bom o suficiente para agir\u0026rdquo; sobre \u0026ldquo;perfeito demais para implementar\u0026rdquo;.\nO Futuro de Metrópolis O Databricks One, atualmente em private preview com public preview planejado para o início de 2026, representa não apenas uma evolução tecnológica, mas uma transformação fundamental na relação entre pessoas e dados. O futuro que está sendo construído é um onde cada usuário de negócios se torna um tipo de super-herói cidadão - pessoas comuns com acesso a superpoderes analíticos.\nO roadmap inclui funcionalidades que expandirão ainda mais seus superpoderes democratizadores: organização de conteúdo por domínios de negócios, URLs mais simples e memoráveis, e integração mais profunda com ferramentas de produtividade como Microsoft Teams e Slack.\nO verdadeiro legado do Databricks One será medido no impacto transformador na forma como organizações tomam decisões. Quando dados deixam de ser um recurso escasso controlado por poucos especialistas e se tornam uma utilidade acessível, organizações se tornam mais ágeis, responsivas e capazes de inovar baseadas em evidências.\nA Chamada para a Ação Superman nunca salvou Metrópolis sozinho ele sempre contou com a colaboração de cidadãos corajosos. Da mesma forma, o sucesso do Databricks One depende da disposição de organizações e indivíduos para abraçar uma nova forma de trabalhar com dados.\nPara líderes empresariais, isso significa reconhecer que democratização de dados é uma transformação organizacional que requer mudança cultural, treinamento adequado e governança thoughtful. Para usuários de negócios, significa abraçar a responsabilidade que vem com superpoderes analíticos. Para profissionais técnicos, significa evoluir de guardiões para facilitadores.\nO Databricks One não é apenas uma nova interface é uma nova era onde o poder dos dados finalmente chega onde sempre deveria ter estado: nas mãos de quem precisa tomar decisões que importam. Como Superman voando sobre Metrópolis, esta plataforma oferece uma perspectiva elevada que revela possibilidades que antes eram invisíveis.\nA questão não é se essa democratização vai acontecer ela já está acontecendo. A questão é se sua organização será uma das primeiras a abraçar esses superpoderes ou se ficará para trás, ainda presa na Fortaleza da Solidão técnica, enquanto concorrentes voam livremente pelos céus dos dados.\nO futuro dos dados é democrático, acessível e poderoso. O Databricks One é o Superman que torna esse futuro possível. A única pergunta que resta é: você está pronto para voar?\nReferências\n[1] Databricks One Overview - NextGenLakehouse YouTube Channel: https://www.youtube.com/watch?v=21W_aFPgGsw\n[2] Microsoft Tech Community - Supercharge Data Intelligence with Azure Databricks Genie: https://techcommunity.microsoft.com/blog/analyticsonazure/supercharge-data-intelligence-build-teams-app-with-azure-databricks-genie--azure/4442653\n[3] Solutions Review - Analytics and Data Science News for the Week of August 8, 2025: https://solutionsreview.com/business-intelligence/analytics-and-data-science-news-for-the-week-of-august-8-updates-from-databricks-qbeast-power-bi-more/\n","permalink":"https://julianamarialop.github.io/articles/databricks-one-o-superman-dos-dados-chegou-para-poder/","summary":"Assim como Clark Kent precisava se transformar em Superman para que pessoas comuns pudessem ser salvas, o mundo dos dados sempre exigiu que usuários de negócios se transformassem em \u0026ldquo;super-técnicos\u0026rdquo; para acessar…","title":"Databricks One: O Superman dos Dados Chegou para Democratizar o Poder da Informação"},{"content":"Imagine que você tem uma orquestra onde cada músico toca sozinho, sem se comunicar com os outros. O violinista toca sua melodia, o pianista segue seu próprio ritmo, e o baterista marca um tempo completamente diferente. O resultado seria um caos musical ensurdecedor, certo? Pois é exatamente isso que acontecia com agentes de IA até agora cada um trabalhava isolado em seu próprio silo, gerando respostas fragmentadas e muitas vezes contraditórias.\nA Microsoft Fabric acaba de revolucionar esse cenário com a integração entre Fabric Data Agents e Copilot Studio, lançada em julho de 2025. Agora os agentes não apenas conversam entre si, mas compartilham contexto, memória e objetivos comuns para resolver problemas empresariais complexos. É como transformar músicos talentosos, mas desorganizados, em uma sinfônica de classe mundial sob a batuta de um maestro experiente.\nE o melhor de tudo: essa revolução acontece de forma completamente transparente para você. Você simplesmente faz uma pergunta no Microsoft Teams algo como \u0026ldquo;Como estão nossas vendas?\u0026rdquo; e, nos bastidores, uma orquestra inteira de agentes especializados se mobiliza instantaneamente. Cada um contribui com sua expertise única, e o resultado é uma análise executiva que nenhum agente isolado conseguiria produzir.\nO Maestro e Seus Virtuoses Microsoft Copilot Studio = O Maestro Inteligente\nAssim como um maestro não toca nenhum instrumento mas coordena toda a orquestra, o Copilot Studio é o cérebro estratégico que analisa cada pergunta complexa e decide instantaneamente quais \u0026ldquo;músicos\u0026rdquo; (agentes) devem entrar em cena. Quando você pergunta \u0026ldquo;Como estão nossas vendas e o que fazer para melhorar?\u0026rdquo;, ele não apenas identifica que precisa de dados de vendas, mas também reconhece que a resposta completa exige análise financeira, contexto de mercado e recomendações estratégicas. É inteligência orquestral em ação.\nFabric Data Agents = Os Virtuoses Especializados\nCada Fabric Data Agent é como um músico de primeira classe que domina perfeitamente seu instrumento. Um agente é virtuose em dados de vendas, conhecendo cada nuance dos números, tendências sazonais e padrões de comportamento. Outro é mestre em análise financeira, capaz de calcular margens, ROI e projeções com precisão cirúrgica. Um terceiro é especialista em inteligência de mercado, sempre atualizado sobre concorrência, oportunidades e ameaças. Cada um tem acesso direto ao OneLake e conhece profundamente a \u0026ldquo;partitura\u0026rdquo; dos dados empresariais.\nModel Context Protocol (MCP) = A Partitura Universal\nO MCP é a linguagem secreta que permite todos os agentes se entenderem perfeitamente, como uma partitura musical que sincroniza cada nota. Mais do que simples comunicação, ele permite que os agentes compartilhem contexto, memória e até mesmo \u0026ldquo;intuições\u0026rdquo; sobre os dados. Quando um agente descobre uma anomalia nas vendas, o MCP garante que essa informação chegue instantaneamente aos outros agentes, permitindo análises correlacionadas que revelam insights impossíveis de detectar isoladamente.\nA Mágica na Prática Cenário Real: Um diretor comercial, no meio de uma reunião estratégica, digita rapidamente no Teams: \u0026ldquo;Preciso entender nossas vendas do trimestre para tomar uma decisão importante agora\u0026rdquo;\nNos bastidores (tudo acontece em menos de 30 segundos):\nCopilot Studio recebe a pergunta e imediatamente reconhece que não é uma consulta simples - é uma demanda executiva que exige análise multidimensional. Em milissegundos, ele elabora uma estratégia de orquestração. Agente de Vendas é acionado primeiro e mergulha nos dados do OneLake, extraindo não apenas números brutos de faturamento, mas identificando padrões, tendências regionais, performance por produto e comparações com períodos anteriores. Agente Financeiro entra em cena simultaneamente, analisando margens de lucro, custos operacionais, ROI por canal de vendas e calculando projeções baseadas nos dados atuais. Agente de Marketing correlaciona os dados de vendas com campanhas ativas, sazonalidade histórica, comportamento do consumidor e movimentações da concorrência que podem estar influenciando os resultados. Copilot Studio recebe todas essas análises especializadas e, usando o MCP, identifica conexões e insights que emergem apenas da combinação das diferentes perspectivas, criando uma narrativa executiva coesa. Resultado Entregue: Uma análise executiva completa com números contextualizados, identificação de oportunidades e ameaças, comparações históricas relevantes e recomendações estratégicas específicas tudo formatado para tomada de decisão imediata. O diretor tem em suas mãos não apenas dados, mas inteligência acionável.\nPor Que Isso é Revolucionário? Antes: A Era dos Solistas Desconectados\nImagine tentar resolver um problema empresarial complexo consultando especialistas que nunca conversaram entre si. O analista de vendas te dava números frios, o financeiro falava apenas de margens, e o especialista em mercado oferecia insights genéricos. Você precisava ser o \u0026ldquo;maestro\u0026rdquo; mental, tentando conectar informações fragmentadas e muitas vezes contraditórias. Era como tentar montar um quebra-cabeças onde cada peça vinha de uma caixa diferente.\nAgora: A Sinfonia da Inteligência Coletiva\nA orquestra digital muda completamente esse paradigma. Os agentes não apenas trabalham juntos eles pensam juntos. Quando o agente de vendas identifica uma queda em determinado produto, o agente financeiro automaticamente analisa o impacto nas margens, enquanto o agente de mercado verifica se há movimentações da concorrência. É inteligência emergente: o resultado da colaboração é exponencialmente superior à soma das partes individuais.\nO Salto Quântico na Tomada de Decisão\nPela primeira vez na história empresarial, você tem acesso instantâneo a análises que antes exigiriam equipes inteiras trabalhando por dias. Mais importante: essas análises são contextualmente ricas, considerando múltiplas variáveis simultaneamente e identificando padrões que nenhum especialista isolado conseguiria detectar. É como ter um conselho consultivo de gênios trabalhando 24/7 exclusivamente para você.\nOs 3 Benefícios Que Mudam Tudo Democratização da Inteligência Executiva - Não importa se você é CEO ou analista júnior agora qualquer pessoa na organização pode fazer perguntas complexas e receber análises de nível C-level. A orquestra digital elimina as barreiras hierárquicas do acesso à inteligência empresarial. É como democratizar o acesso a um conselho consultivo de elite, permitindo que insights estratégicos fluam por toda a organização, acelerando a inovação em todos os níveis. Velocidade que Redefine Competitividade - Enquanto seus concorrentes ainda estão agendando reuniões para discutir dados, você já tomou a decisão e está executando. A orquestra digital comprime semanas de análise em segundos de processamento. Mais do que eficiência, isso representa uma vantagem competitiva fundamental: a capacidade de responder ao mercado na velocidade do pensamento, não na velocidade da burocracia. Insights de Inteligência Emergente - O verdadeiro poder da orquestra não está nos agentes individuais, mas na inteligência que emerge de sua colaboração. Correlações impossíveis de detectar manualmente, padrões ocultos que só aparecem quando múltiplas perspectivas se combinam, e oportunidades que nenhum especialista isolado conseguiria identificar. É como ter uma lente de aumento que revela dimensões invisíveis do seu negócio. Como Começar Sua Orquestra: Exemplo Prático Vamos criar um Assistente de Vendas que combina 3 agentes especializados. Aqui está o passo a passo real:\nPasso 1: Preparar os Dados no Fabric Primeiro, organize seus dados no OneLake:\n-- Tabela de Vendas (Lakehouse) CREATE TABLE vendas_historico ( data_venda DATE , produto VARCHAR(100) , valor DECIMAL(10,2) , regiao VARCHAR(50) , vendedor VARCHAR(100) ); -- Tabela de Metas (Warehouse) CREATE TABLE metas_vendas ( mes INT , ano INT , meta_valor DECIMAL(12,2) , regiao VARCHAR(50) ); Passo 2: Criar os Fabric Data Agents Agent 1: Especialista em Vendas\n# No Fabric Data Science - Notebook from databricks.agents import Agent vendas_agent = Agent.create( name=\u0026#34;VendasExpert\u0026#34;, description=\u0026#34;Especialista em análise de dados de vendas\u0026#34;, data_sources=[ \u0026#34;workspace.lakehouse.vendas_historico\u0026#34;, \u0026#34;workspace.warehouse.metas_vendas\u0026#34; ], instructions=\u0026#34;\u0026#34;\u0026#34; Você é um especialista em vendas. Analise: - Performance vs metas - Tendências por região - Top produtos e vendedores - Sempre inclua comparações históricas \u0026#34;\u0026#34;\u0026#34; ) Agent 2: Analista Financeiro\nfinanceiro_agent = Agent.create( name=\u0026#34;FinanceiroExpert\u0026#34;, description=\u0026#34;Especialista em análise financeira de vendas\u0026#34;, data_sources=[ \u0026#34;workspace.lakehouse.vendas_historico\u0026#34;, \u0026#34;workspace.warehouse.custos_produtos\u0026#34; ], instructions=\u0026#34;\u0026#34;\u0026#34; Você analisa aspectos financeiros: - Margens de lucro por produto - ROI por região - Análise de rentabilidade - Projeções financeiras \u0026#34;\u0026#34;\u0026#34; ) Agent 3: Estrategista de Mercado\nmercado_agent = Agent.create( name=\u0026#34;MercadoExpert\u0026#34;, description=\u0026#34;Especialista em inteligência de mercado\u0026#34;, data_sources=[ \u0026#34;workspace.lakehouse.vendas_historico\u0026#34;, \u0026#34;workspace.warehouse.dados_mercado\u0026#34; ], instructions=\u0026#34;\u0026#34;\u0026#34; Você fornece contexto de mercado: - Sazonalidade e tendências - Comparação com concorrentes - Oportunidades de crescimento - Recomendações estratégicas \u0026#34;\u0026#34;\u0026#34; ) Passo 3: Configurar a Orquestração no Copilot Studio 3.1 - Criar o Agente Maestro\nNo Copilot Studio, crie um novo agente:\nNome: \u0026#34;Assistente Vendas Executivo\u0026#34; Descrição: \u0026#34;Coordena análises de vendas usando múltiplos especialistas\u0026#34; Instruções do Sistema: \u0026#34;\u0026#34;\u0026#34; Você é um assistente executivo que coordena 3 especialistas: - VendasExpert: dados de vendas e performance - FinanceiroExpert: análise financeira e margens - MercadoExpert: contexto de mercado e estratégia Para cada pergunta: 1. Determine quais especialistas consultar 2. Faça perguntas específicas para cada um 3. Combine as respostas em uma análise executiva 4. Sempre inclua recomendações acionáveis \u0026#34;\u0026#34;\u0026#34; 3.2 - Configurar as Conexões MCP\n{ \u0026#34;connections\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;VendasExpert\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;fabric_data_agent\u0026#34;, \u0026#34;endpoint\u0026#34;: \u0026#34;https://fabric.microsoft.com/agents/vendas-expert\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;FinanceiroExpert\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;fabric_data_agent\u0026#34;, \u0026#34;endpoint\u0026#34;: \u0026#34;https://fabric.microsoft.com/agents/financeiro-expert\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;MercadoExpert\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;fabric_data_agent\u0026#34;, \u0026#34;endpoint\u0026#34;: \u0026#34;https://fabric.microsoft.com/agents/mercado-expert\u0026#34; } ] } Passo 4: Testar a Orquestra Pergunta de Teste: \u0026ldquo;Como estão nossas vendas este trimestre e o que devemos fazer?\u0026rdquo;\nFluxo da Orquestra:\nCopilot Studio analisa a pergunta VendasExpert → \u0026ldquo;Vendas Q3: R2.1M(meta:R 2.1M (meta: R2.1M(meta:R 2M). Crescimento 15% vs Q2\u0026rdquo; FinanceiroExpert → \u0026ldquo;Margem média 23%. Produtos premium com melhor ROI\u0026rdquo; MercadoExpert → \u0026ldquo;Sazonalidade favorável até dezembro. Concorrente X perdendo market share\u0026rdquo; Copilot Studio combina tudo Resposta Final\n\u0026#34;✅ Performance Excelente: Superamos meta em 5% (R2.1MvsR 2.1M vs R 2.1MvsR 2M) 📊 Destaques: •Crescimento 15% vs trimestre anterior •Margem saudável de 23% •Produtos premium liderando rentabilidade 🎯 Recomendações: •Intensificar foco em produtos premium •Aproveitar sazonalidade até dezembro •Expandir em regiões onde concorrente está perdendo espaço 📈 Projeção Q4: Com estratégia atual, potencial de R$ 2.4M\u0026#34; Passo 5: Deploy e Monitoramento # Publicar no Teams copilot_studio.deploy_to_teams( agent_id=\u0026#34;assistente-vendas-executivo\u0026#34;, channels=[\u0026#34;vendas\u0026#34;, \u0026#34;diretoria\u0026#34;], permissions=[\u0026#34;sales_team\u0026#34;, \u0026#34;executives\u0026#34;] ) # Configurar métricas monitoring.setup_metrics([ \u0026#34;response_time\u0026#34;, \u0026#34;user_satisfaction\u0026#34;, \u0026#34;agent_collaboration_success\u0026#34;, \u0026#34;business_impact\u0026#34; ]) Resultado: Em 2-3 semanas você tem uma orquestra digital funcionando, transformando perguntas simples em análises executivas completas.\nA tecnologia está em preview, mas já funciona. Empresas pioneiras estão testando e os resultados são impressionantes.\nO Futuro Chegou A era dos agentes isolados acabou. Bem-vindos à era da orquestração inteligente, onde IA não é apenas automação, mas colaboração genuína entre especialistas digitais.\nSua empresa está pronta para ter sua própria orquestra digital?\nAté o próximo artigo !\nReferências Fabric Data Agents + Microsoft Copilot Studio: A New Era of Multi-Agent Orchestration (Preview) - https://blog.fabric.microsoft.com/en-us/blog/fabric-data-agents-microsoft-copilot-studio-a-new-era-of-multi-agent-orchestration\nOrchestrate agent behavior with generative AI - https://learn.microsoft.com/en-us/microsoft-copilot-studio/advanced-generative-actions\n","permalink":"https://julianamarialop.github.io/articles/orquestra-digital-quando-agentes-de-ia-aprendem-tocar/","summary":"Imagine que você tem uma orquestra onde cada músico toca sozinho, sem se comunicar com os outros. O violinista toca sua melodia, o pianista segue seu próprio ritmo, e o baterista marca um tempo completamente diferente…","title":"A Orquestra Digital: Quando Agentes de IA Aprendem a Tocar Juntos"},{"content":"Lembra da torta de maçã da sua vovó? Aquela receita especial que levava horas para preparar, mas o resultado era sempre perfeito? O departamento de Recursos Humanos moderno enfrenta um dilema parecido: como manter a qualidade artesanal da seleção de talentos, mas sem gastar horas analisando cada currículo individualmente?\nAssim como a vovó conhecia cada ingrediente e sabia exatamente quando a torta estava pronta, os recrutadores experientes desenvolvem um \u0026ldquo;sexto sentido\u0026rdquo; para identificar bons candidatos. Mas e se pudéssemos automatizar esse processo, mantendo a mesma qualidade e critério, mas com a eficiência de uma cozinha moderna?\nO Azure AI Foundry oferece todas as ferramentas necessárias para criar essa \u0026ldquo;versão 2.0\u0026rdquo; da receita da vovó - um agente inteligente que mantém os mesmos ingredientes de qualidade (experiência, critérios rigorosos, atenção aos detalhes), mas usa tecnologia moderna para preparar a \u0026ldquo;torta perfeita\u0026rdquo; em uma fração do tempo.\nO Cenário: Por que Precisamos de um Recrutador Digital? Imagine um departamento de RH que recebe 500 currículos por semana para diferentes posições. Cada currículo precisa ser lido, analisado e comparado com os requisitos da vaga. Um recrutador experiente leva, em média, 10 minutos para fazer uma análise inicial completa de um currículo. Isso significa mais de 80 horas semanais apenas para a triagem inicial - mais de duas semanas de trabalho de uma pessoa.\nAlém da questão do tempo, existe o desafio da consistência. Diferentes recrutadores podem interpretar os mesmos requisitos de forma ligeiramente diferente, especialmente quando estão cansados ou sob pressão. Um candidato avaliado na segunda-feira de manhã pode receber uma análise diferente do mesmo candidato avaliado na sexta-feira à tarde.\nO Azure AI Foundry Agent Service resolve esses problemas criando um assistente digital que mantém critérios consistentes, trabalha 24 horas por dia e pode processar dezenas de currículos simultaneamente. É como ter um especialista em RH que nunca tem um dia ruim e sempre aplica exatamente os mesmos padrões de avaliação.\nOs Ingredientes Secretos da Receita Assim como a torta de maçã da vovó tinha ingredientes específicos que faziam toda a diferença, nosso sistema de recrutamento digital também precisa dos componentes certos para funcionar perfeitamente. Cada \u0026ldquo;ingrediente\u0026rdquo; tem um papel específico na criação de um sistema inteligente e eficiente.\n_Arquitetura completa do Azure AI Foundry mostrando a integração entre todos os componentes do nosso sistema de recrutamento digital_\nO Azure AI Foundry Agent Service é como o forno da vovó. É o coração da operação onde a mágica acontece. É aqui que definimos as instruções do nosso agente, suas capacidades e como ele deve se comportar ao analisar currículos. Pense nele como o conhecimento acumulado da vovó, mas codificado de forma precisa e consistente.\nO Azure Blob Storage funciona como a despensa bem organizada da vovó onde todos os ingredientes (currículos) ficam armazenados de forma segura e acessível. A vantagem é que essa \u0026ldquo;despensa digital\u0026rdquo; pode guardar milhões de documentos sem perder a organização.\nO Azure AI Search é como o caderno de receitas secreto da vovó, mas turbinado. Ele não apenas organiza os currículos por palavras-chave, mas entende o \u0026ldquo;sabor\u0026rdquo; de cada perfil profissional. É capaz de encontrar candidatos com \u0026ldquo;experiência em liderança\u0026rdquo; mesmo quando o currículo menciona apenas \u0026ldquo;coordenação de equipes\u0026rdquo;.\nA File Search Tool é o utensílio mágico que conecta tudo como a colher de pau especial da vovó que ela usava para todos os pratos. Ela permite que o agente acesse, leia e analise os currículos, usando toda a inteligência do sistema para encontrar os \u0026ldquo;ingredientes\u0026rdquo; certos para cada vaga.\nPasso 1: Preparando o Arquivo de Currículos - Azure Blob Storage O primeiro passo na construção do nosso recrutador digital é criar um local seguro e organizado para armazenar todos os currículos. O Azure Blob Storage será nossa \u0026ldquo;sala de arquivos digital\u0026rdquo;, onde cada documento fica perfeitamente catalogado e acessível.\nA configuração do Azure Blob Storage requer atenção especial à estrutura de pastas. Uma organização eficiente pode ser por departamento, por vaga ou por período. Por exemplo: /curriculos/2025/desenvolvedor-senior/ ou /curriculos/marketing/analista-digital/. Essa organização facilita tanto o acesso do agente quanto a manutenção futura do sistema.\nÉ importante configurar as permissões de acesso adequadamente desde o início. O storage deve permitir leitura para os serviços de IA que criaremos posteriormente, mas manter controles rigorosos sobre quem pode adicionar, modificar ou excluir currículos. Recomenda-se usar autenticação baseada em identidade gerenciada do Azure para maior segurança.\nA estrutura de containers deve refletir a organização da empresa. Um container principal para currículos ativos, outro para arquivos históricos e possivelmente containers separados para diferentes unidades de negócio. Isso facilita a gestão de políticas de retenção e acesso.\nPasso 2: Construindo o Cérebro da Busca - Azure AI Search (RAG) Com os currículos organizados no Blob Storage, precisamos criar o sistema que permitirá ao nosso agente \u0026ldquo;entender\u0026rdquo; e buscar informações nesses documentos. O Azure AI Search funciona como o sistema RAG (Retrieval-Augmented Generation) do nosso agente, transformando documentos em conhecimento pesquisável.\nO Azure AI Search é muito mais que um mecanismo de busca tradicional. Ele processa os currículos, extrai texto, cria representações vetoriais do conteúdo e constrói índices otimizados para busca semântica. É como ter um bibliotecário superinteligente que não apenas sabe onde cada documento está, mas também entende o significado de cada palavra e conceito.\nA configuração do modo de análise é crucial para o sucesso do sistema. Para currículos, recomendamos usar o modo \u0026ldquo;Padrão\u0026rdquo;, que detecta automaticamente o tipo de arquivo e aplica o analisador mais apropriado. Isso garante que tanto PDFs quanto documentos Word sejam processados corretamente, extraindo não apenas texto, mas também metadados importantes.\nO processo de indexação transforma cada currículo em uma estrutura pesquisável. O sistema automaticamente divide os documentos em chunks (pedaços) menores, cria embeddings vetoriais para busca semântica e constrói índices invertidos para busca por palavras-chave. É essa combinação que permite ao agente encontrar candidatos com \u0026ldquo;experiência em liderança\u0026rdquo; mesmo quando o currículo menciona apenas \u0026ldquo;gestão de equipes\u0026rdquo;.\nA conexão com o Blob Storage estabelece o pipeline de dados. Sempre que novos currículos são adicionados ao storage, o AI Search automaticamente os processa e atualiza o índice. É como ter um assistente que mantém a biblioteca sempre organizada e atualizada.\nPasso 3: Criando a Central de Comando - Azure AI Foundry Hub Com nossa base de dados e sistema de busca prontos, chegou a hora de criar a \u0026ldquo;central de comando\u0026rdquo; onde nosso agente será desenvolvido e gerenciado. O Azure AI Foundry Hub funciona como a sede da nossa operação de IA.\nO Hub do Azure AI Foundry centraliza recursos, configurações de segurança e conectividade. É aqui que definimos quais serviços do Azure nosso agente pode acessar e como ele deve se autenticar. Pense no Hub como o quartel-general de uma operação de inteligência, onde todas as ferramentas e recursos ficam organizados e seguros.\nA configuração do Hub inclui a conexão com os serviços que criamos anteriormente. O Hub precisa ter acesso ao Blob Storage (para ler currículos) e ao AI Search (para realizar buscas inteligentes). Essas conexões são estabelecidas usando identidades gerenciadas, garantindo segurança sem a necessidade de gerenciar chaves manualmente.\nDentro do Hub, criamos um Projeto específico para nosso agente de RH. Projetos permitem organizar diferentes agentes e experimentos, mantendo configurações e dados separados. É como ter departamentos diferentes dentro da mesma empresa - cada um com suas responsabilidades específicas, mas todos compartilhando a infraestrutura comum do Hub.\nAs configurações de segurança do Hub determinam quem pode acessar o projeto, criar agentes e visualizar dados. É importante estabelecer políticas claras desde o início, definindo diferentes níveis de acesso para desenvolvedores, administradores e usuários finais do sistema.\nPasso 4: Dando Vida ao Recrutador - Criação do Agente Com toda a infraestrutura preparada - Blob Storage organizando os currículos, AI Search funcionando como o cérebro RAG e o Hub centralizando tudo - chegou o momento de dar vida ao nosso recrutador digital. A criação do agente é onde definimos sua personalidade, suas habilidades e como ele deve se comportar ao analisar currículos.\nAs instruções do agente são fundamentais para seu sucesso. Elas devem ser claras, específicas e abrangentes. Um exemplo de instrução eficaz seria: \u0026ldquo;Você é um especialista em recrutamento com 15 anos de experiência. Sua função é analisar currículos e avaliar a compatibilidade dos candidatos com as vagas disponíveis. Sempre considere experiência relevante, formação acadêmica, habilidades técnicas e soft skills. Seja objetivo mas justo em suas avaliações.\u0026rdquo;\nA configuração da File Search Tool conecta o agente aos currículos armazenados. Esta ferramenta automaticamente processa os documentos, criando chunks (pedaços) de texto de aproximadamente 800 tokens com sobreposição de 400 tokens. Isso garante que informações importantes não sejam perdidas na divisão do conteúdo.\nO processo de conexão ao Blob Storage estabelece o link entre o agente e os dados. O sistema automaticamente monitora novos arquivos adicionados ao storage e os inclui no índice de busca. É como ter um assistente que sempre mantém a base de currículos atualizada.\nOs testes de conexão são essenciais antes de colocar o agente em produção. Comece com alguns currículos de teste e vagas conhecidas. Verifique se o agente consegue acessar os documentos, extrair informações relevantes e fornecer análises coerentes.\nAlimentando o Sistema: Upload e Organização dos Currículos Um recrutador digital é tão bom quanto a qualidade e organização dos dados que ele pode acessar. A forma como organizamos e alimentamos a base de currículos determina diretamente a eficácia das análises.\nA estrutura de pastas no Blob Storage deve refletir a realidade do negócio. Uma abordagem eficiente é criar hierarquias que facilitem tanto a busca quanto a manutenção. Por exemplo: /curriculos/ano/departamento/nivel/ permite filtros específicos e facilita a gestão de dados antigos.\nOs formatos de arquivo suportados incluem PDF, Word (.doc e .docx), texto simples, RTF e muitos outros. O sistema automaticamente detecta o formato e aplica o processamento apropriado. PDFs com texto selecionável funcionam melhor que imagens escaneadas, embora o sistema também possa processar estes últimos com OCR.\nO processo de indexação acontece automaticamente quando novos arquivos são adicionados ao Blob Storage. O Azure AI Search processa o conteúdo, extrai texto, cria embeddings vetoriais e atualiza o índice. Este processo pode levar alguns minutos para arquivos grandes ou muitos arquivos simultâneos.\nA criação dos Vector Stores organiza os currículos em estruturas otimizadas para busca semântica. Cada Vector Store pode conter até 10.000 arquivos e pode ser associado tanto ao agente (para currículos permanentes) quanto a threads específicas (para análises temporárias de vagas específicas).\nTreinando o Especialista: Prompts e Instruções A qualidade das análises do nosso recrutador digital depende diretamente da qualidade das instruções que fornecemos. É como treinar um novo funcionário - quanto mais claras e específicas forem as orientações, melhores serão os resultados.\nUm prompt eficaz para análise de currículos deve incluir contexto, critérios específicos e formato de resposta esperado. Por exemplo: \u0026ldquo;Analise este currículo para a vaga de Desenvolvedor Senior Python. Avalie: 1) Experiência em Python (mínimo 5 anos), 2) Conhecimento em frameworks web (Django/Flask), 3) Experiência com bancos de dados, 4) Habilidades de liderança. Forneça uma pontuação de 1-10 para cada critério e um resumo executivo.\u0026rdquo;\nOs critérios de avaliação devem ser personalizáveis para diferentes tipos de vaga. Vagas técnicas podem priorizar habilidades específicas e certificações, enquanto vagas de liderança podem focar mais em experiência de gestão e soft skills. O agente pode ser instruído a ajustar seus critérios baseado no tipo de posição.\nExemplos práticos de instruções incluem: \u0026ldquo;Se o candidato não mencionar explicitamente uma habilidade requerida, procure por experiências que possam indicar essa competência indiretamente. Por exemplo, \u0026lsquo;coordenou projeto de migração de sistema\u0026rsquo; pode indicar habilidades de gestão de projetos mesmo sem mencionar certificações específicas.\u0026rdquo;\nA calibração do agente é um processo iterativo. Comece com instruções básicas, teste com currículos conhecidos e refine as orientações baseado nos resultados. É importante incluir exemplos de boas e más práticas para que o agente aprenda a distinguir entre diferentes níveis de qualificação.\nO Recrutador em Ação: Casos de Uso Práticos Com nosso recrutador digital configurado, vamos ver como ele funciona na prática. A análise de match candidato x vaga é o caso mais comum - o agente recebe a descrição de uma vaga e identifica pontos de compatibilidade e possíveis gaps nos currículos.\nO ranking de candidatos permite comparar múltiplos perfis simultaneamente, criando listas ordenadas baseadas nos critérios estabelecidos. A identificação de gaps de competências ajuda tanto na seleção quanto no desenvolvimento interno, enquanto a geração de relatórios automatiza a documentação do processo seletivo.\nOtimizações e Boas Práticas Para manter o sistema eficiente, implemente políticas de expiração para Vector Stores temporários (7 dias é o padrão) e monitore custos através de limpeza periódica de dados antigos.\nO monitoramento de performance deve incluir métricas como tempo de resposta e qualidade das análises. Para segurança, use criptografia, controles de acesso baseados em funções e mantenha conformidade com LGPD.\nConclusão Assim como a torta de maçã da vovó evoluiu da receita manuscrita para versões modernas que mantêm o mesmo sabor especial, a criação de um agente de seleção de currículos no Azure AI Foundry representa essa mesma evolução no recrutamento. Mantemos os ingredientes de qualidade - critérios rigorosos, atenção aos detalhes, experiência acumulada - mas usamos tecnologia moderna para preparar resultados consistentes e eficientes.\nEste sistema não substitui o \u0026ldquo;toque especial\u0026rdquo; dos profissionais de RH, mas potencializa seu trabalho, permitindo que foquem no que realmente importa: conhecer pessoas, desenvolver talentos e construir equipes excepcionais. Afinal, a melhor torta sempre será aquela feita com carinho, mas com a ajuda das ferramentas certas.\nAté a próxima !\n","permalink":"https://julianamarialop.github.io/articles/torta-de-maca-da-vovo-rh-como-criar-um-agente-selecao/","summary":"Lembra da torta de maçã da sua vovó? Aquela receita especial que levava horas para preparar, mas o resultado era sempre perfeito? O departamento de Recursos Humanos moderno enfrenta um dilema parecido: como manter a…","title":"A Torta de Maçã da Vovó RH: Como Criar um Agente de Seleção de Currículos no Azure AI Foundry"},{"content":"Julho de 2025 chegou com uma chuva de atualizações que transformaram o Microsoft Fabric em um super-herói ainda mais poderoso. Como todo bom herói que se preza, o Fabric não para de evoluir, adquirindo novos poderes e equipamentos para enfrentar os desafios cada vez mais complexos do mundo dos dados.\nEste mês foi particularmente especial, com seis grandes novidades que expandiram significativamente as capacidades da plataforma. Desde uma nova armadura cósmica até gadgets de tempo real, passando por escudos personalizados e pontes interdimensionais, o arsenal do nosso herói nunca esteve tão completo.\nVamos explorar cada um desses novos poderes e entender como eles podem transformar a forma como trabalhamos com dados, tornando nossas missões mais eficientes, seguras e poderosas.\nA Nova Armadura Cósmica: Cosmos DB no Fabric Imagine o Tony Stark desenvolvendo uma nova versão da armadura do Homem de Ferro, mas desta vez com tecnologia cósmica avançada. É exatamente isso que representa o lançamento do Cosmos DB no Microsoft Fabric. Esta nova \u0026ldquo;armadura\u0026rdquo; não é apenas uma adição ao arsenal - é uma transformação fundamental que permite ao nosso herói operar em dimensões completamente novas.\nO Cosmos DB no Fabric traz o poder do Azure Cosmos DB diretamente para a plataforma, combinando alta disponibilidade, escalabilidade dinâmica e performance otimizada para IA em uma experiência totalmente gerenciada. É como se o Fabric tivesse ganhado a capacidade de processar dados NoSQL nativamente, mantendo toda a flexibilidade e poder que já conhecemos.\nA grande revolução desta armadura cósmica está no mirroring automático para o OneLake. Assim que você cria um banco Cosmos DB no seu workspace, o Fabric automaticamente começa a replicar todos os dados para o OneLake em formato Delta, em tempo quase real. É como ter um sistema de backup inteligente que não apenas protege seus dados, mas os torna instantaneamente disponíveis para análises avançadas.\nMas os poderes desta armadura vão além. Com suporte nativo para vector search e full-text search, o Cosmos DB no Fabric permite que você execute buscas por similaridade usando embeddings vetoriais, encontrando resultados baseados no significado e contexto dos dados, não apenas em palavras-chave. É como ter um radar que detecta não apenas objetos, mas também suas intenções e relacionamentos.\nPara equipes que trabalham com aplicações modernas, esta nova armadura oferece casos de uso poderosos. Imagine um assistente de conhecimento inteligente que acessa manuais, documentos de suporte e logs de chat armazenados como JSON no Cosmos DB. Com indexação vetorial, o assistente entrega resultados semanticamente relevantes para consultas dos usuários, enquanto os dados replicados no OneLake permitem análises contínuas para refinar o conteúdo.\nO Escudo Personalizado: Customer Managed Keys no OneLake Todo super-herói precisa de um escudo confiável, e o Capitão América sempre soube disso. Agora, o Microsoft Fabric ganhou seu próprio escudo personalizado com o lançamento das Customer Managed Keys (CMK) no OneLake. Mas diferentemente do vibranium do Capitão América, este escudo pode ser forjado exatamente conforme suas especificações de segurança.\nAs Customer Managed Keys representam uma das funcionalidades mais solicitadas pelos usuários corporativos do Fabric. Por padrão, a Microsoft já criptografa todos os dados em repouso no OneLake usando chaves gerenciadas pela própria Microsoft. Mas para organizações em setores regulamentados como finanças, saúde e governo, ter controle total sobre as chaves de criptografia não é apenas desejável - é essencial.\nCom as CMK, você pode usar suas próprias chaves, armazenadas no Azure Key Vault, para criptografar dados no OneLake. É como ter um cofre pessoal onde apenas você possui a combinação. Imagine uma empresa de serviços financeiros que precisa demonstrar controle total sobre a criptografia de dados para auditores. Com as CMK, eles podem mostrar que apenas sua equipe de segurança tem acesso à chave de criptografia, e que revogar a chave bloqueará imediatamente o acesso aos dados sensíveis.\nO poder deste escudo personalizado vai além da simples criptografia. Ele oferece controle granular no nível do workspace, permitindo que organizações criptografem seletivamente apenas os workspaces que requerem proteção de dados aprimorada. É uma abordagem flexível que não impõe uma solução única para todos os cenários.\nA funcionalidade também suporta rotação e revogação de chaves. Se uma organização de saúde precisa rotacionar chaves de criptografia a cada 90 dias para manter conformidade, ela pode automatizar políticas de rotação no Azure Key Vault sem interromper os fluxos de trabalho de análise. E se for necessário revogar acesso, o OneLake automaticamente bloqueia operações de leitura e escrita em até uma hora, garantindo que os dados permaneçam seguros.\nA Ponte Interdimensional: Mirroring do Unity Catalog O Doutor Estranho sempre impressionou com sua capacidade de abrir portais entre dimensões, conectando mundos que antes pareciam impossíveis de alcançar. O Microsoft Fabric acaba de ganhar um poder similar com o lançamento da funcionalidade de Mirroring do Azure Databricks Unity Catalog, agora em disponibilidade geral.\nEsta ponte interdimensional permite que tabelas governadas no Unity Catalog sejam acessadas diretamente pelo Microsoft Fabric, criando uma experiência unificada e governada entre ambas as plataformas, sem duplicação de dados. É como se o Fabric tivesse ganhado a habilidade de \u0026ldquo;enxergar\u0026rdquo; através das dimensões, acessando dados que residem no universo Databricks como se fossem nativos.\nA magia desta ponte está na sua transparência. Datasets gerenciados pelo Databricks tornam-se instantaneamente utilizáveis no Fabric, mantendo toda a governança e controle de acesso estabelecidos no Unity Catalog. É uma integração que respeita as políticas de segurança existentes enquanto expande dramaticamente as possibilidades de análise e colaboração.\nPara equipes que trabalham com ambas as plataformas, esta ponte interdimensional elimina a necessidade de processos complexos de sincronização ou duplicação de dados. Cientistas de dados podem continuar trabalhando no Databricks com suas ferramentas preferidas, enquanto analistas de negócio acessam os mesmos dados através do Power BI e outras ferramentas do Fabric, tudo mantendo uma única fonte de verdade.\nO impacto desta funcionalidade vai além da conveniência técnica. Ela representa uma mudança fundamental na forma como pensamos sobre ecossistemas de dados, permitindo que organizações aproveitem o melhor de ambos os mundos sem compromissos ou complexidade adicional.\nO Gadget de Tempo Real: SQL Operator no Eventstream Batman sempre foi conhecido por seus gadgets engenhosos, ferramentas especializadas que ele desenvolve para situações específicas. O Microsoft Fabric acaba de adicionar um novo gadget ao seu cinto de utilidades: o SQL Operator no Eventstream, uma ferramenta poderosa para missões que exigem processamento de dados em tempo real.\nO SQL Operator representa uma evolução significativa no Eventstream, oferecendo controle total sobre transformações de dados em tempo real usando a linguagem SQL familiar. Enquanto o Eventstream já oferecia uma experiência rica sem código com operadores integrados como Filter, Aggregate e Join, o SQL Operator permite que você empacote toda a lógica de transformação de dados em um só lugar.\nEste gadget brilha especialmente em cenários complexos que exigem lógica condicional, expressões aninhadas, manipulação de strings e agregações avançadas. É como ter uma ferramenta multiuso que se adapta a qualquer situação, permitindo que você escreva transformações personalizadas com a precisão de um cirurgião e a flexibilidade de um artista.\nA experiência de desenvolvimento é intuitiva e poderosa. Você pode testar suas consultas em dados em tempo real antes de publicar, garantindo que a lógica esteja correta. O suporte ao IntelliSense aumenta a produtividade e minimiza erros com destaque de sintaxe e autocompletar. É como ter um assistente pessoal que conhece todas as funções e sintaxes disponíveis.\nPara equipes que já trabalham com Azure Stream Analytics, este gadget oferece uma transição suave, permitindo que você traga sua lógica de transformação existente diretamente para o Fabric Eventstream. É uma ponte que conecta conhecimento existente com novas possibilidades, acelerando a adoção e reduzindo a curva de aprendizado.\nO Sistema de Segurança Avançado: Limites de Acesso em Workspaces Assim como a Fortaleza da Solidão do Superman possui sistemas de segurança avançados para proteger conhecimentos e tecnologias perigosas, o Microsoft Fabric está implementando um novo sistema de proteção: os Limites de Acesso em Workspaces, que serão introduzidos em agosto de 2025.\nEste sistema de segurança avançado foi projetado para melhorar a qualidade do serviço, a confiabilidade e encorajar o controle adequado de acesso aos workspaces. É uma medida proativa que visa proteger tanto os usuários individuais quanto o ecossistema como um todo, garantindo que os recursos sejam utilizados de forma eficiente e responsável.\nOs limites de acesso funcionam como um sistema de monitoramento inteligente que observa padrões de uso e implementa controles quando necessário. É como ter um guardião digital que entende quando o uso está dentro de parâmetros normais e quando pode estar causando impacto na performance geral da plataforma.\nEsta funcionalidade representa um equilíbrio cuidadoso entre flexibilidade e controle. Enquanto mantém a facilidade de uso que caracteriza o Fabric, ela introduz salvaguardas que protegem a experiência de todos os usuários. É uma abordagem que prioriza a sustentabilidade a longo prazo da plataforma.\nPara administradores e equipes de governança, este sistema oferece maior visibilidade e controle sobre como os recursos são utilizados, permitindo planejamento mais eficaz e gestão proativa de capacidade.\nO Comunicador Universal: Conectividade SAP Aprimorada A Federação Estelar sempre dependeu de comunicadores universais para conectar diferentes espécies e culturas. O Microsoft Fabric acaba de aprimorar seu próprio comunicador universal com melhorias significativas na conectividade SAP, facilitando a integração com um dos ecossistemas empresariais mais importantes do mundo.\nAs novas opções de integração de dados de fontes SAP representam um avanço importante para organizações que dependem destes sistemas para operações críticas de negócio. Com mais de 170 conectores disponíveis no Data Factory, o Fabric continua expandindo sua capacidade de se comunicar com praticamente qualquer sistema empresarial.\nEsta conectividade aprimorada é especialmente valiosa para empresas que precisam unificar dados SAP com outras fontes para análises abrangentes e casos de uso de IA. É como ter um tradutor universal que não apenas entende diferentes \u0026ldquo;idiomas\u0026rdquo; de dados, mas também os harmoniza em uma linguagem comum que pode ser utilizada por toda a organização.\nAs melhorias incluem opções mais robustas de extração, transformação e carregamento de dados SAP, permitindo que organizações aproveitem melhor seus investimentos existentes em sistemas SAP enquanto modernizam suas capacidades analíticas.\nConclusão Cada uma dessas funcionalidades não apenas adiciona capacidades técnicas, mas representa uma evolução na forma como pensamos sobre integração, segurança, governança e processamento de dados. Juntas, elas criam um ecossistema mais robusto, flexível e poderoso que pode se adaptar às necessidades em constante evolução das organizações modernas.\nAté o próximo artigo !\n","permalink":"https://julianamarialop.github.io/articles/o-arsenal-completo-do-heroi-fabric-novos-poderes-e-de/","summary":"Julho de 2025 chegou com uma chuva de atualizações que transformaram o Microsoft Fabric em um super-herói ainda mais poderoso. Como todo bom herói que se preza, o Fabric não para de evoluir, adquirindo novos poderes e…","title":"O Arsenal Completo do Herói Fabric: Novos Poderes e Equipamentos de Julho 2025"},{"content":"Imagine um escritório onde os funcionários nunca se cansam, trabalham 24 horas por dia, aprendem constantemente e executam tarefas com precisão cirúrgica. Esse cenário, que parecia ficção científica há poucos anos, agora é realidade com os agentes de inteligência artificial. A Databricks acaba de revolucionar esse conceito com o lançamento do Agent Bricks e do Lakebase, criando o que podemos chamar de \u0026ldquo;escritório digital perfeito\u0026rdquo;.\nOs agentes de IA representam uma mudança fundamental na forma como as empresas operam. Eles não são apenas ferramentas automatizadas, mas verdadeiros colaboradores digitais capazes de tomar decisões, aprender com experiências e adaptar-se a novas situações. Com o Agent Bricks, a Databricks democratizou a criação desses \u0026ldquo;funcionários digitais\u0026rdquo;, permitindo que qualquer empresa construa sua equipe de agentes especializados sem a complexidade técnica tradicional.\nO Lakebase, por sua vez, funciona como o sistema nervoso central desse novo escritório, garantindo que todos os agentes tenham acesso instantâneo às informações necessárias para executar suas funções. Juntas, essas tecnologias estão redefinindo o conceito de produtividade empresarial, prometendo reduções de até 90% no tempo de desenvolvimento de soluções de IA e transformando a maneira como pensamos sobre automação inteligente.\nDo Escritório Tradicional ao Escritório Digital O Caos do Escritório Tradicional No escritório tradicional, conhecemos bem os desafios: funcionários sobrecarregados alternando entre múltiplas tarefas, processos manuais que consomem horas preciosas, e a constante necessidade de coordenação entre departamentos. Imagine um analista de dados que precisa coletar informações de cinco sistemas diferentes, consolidar relatórios manualmente e ainda responder a dezenas de e-mails sobre o status de projetos. Esse cenário se repete em milhares de empresas diariamente.\nA ineficiência não está apenas na execução das tarefas, mas na própria natureza humana: precisamos de pausas, temos limitações de processamento simultâneo e, inevitavelmente, cometemos erros quando lidamos com volumes grandes de informação. Além disso, o conhecimento fica concentrado em pessoas específicas, criando gargalos quando esses especialistas estão indisponíveis ou deixam a empresa.\nA Revolução do Escritório Digital O escritório digital representa uma mudança de paradigma fundamental. Aqui, os agentes de IA assumem o papel de funcionários especializados, cada um com competências específicas e capacidade de trabalhar ininterruptamente. Esses \u0026ldquo;colaboradores digitais\u0026rdquo; não substituem os humanos, mas amplificam suas capacidades, assumindo tarefas repetitivas e permitindo que os profissionais se concentrem em atividades estratégicas e criativas.\nNo escritório digital, um agente especializado em análise de dados pode monitorar continuamente dezenas de fontes de informação, identificar padrões anômalos e gerar relatórios personalizados em tempo real. Outro agente pode gerenciar automaticamente o atendimento ao cliente, escalando apenas os casos que realmente requerem intervenção humana. Um terceiro pode monitorar a infraestrutura de TI, prevendo problemas antes que eles ocorram e executando correções automáticas.\nA diferença fundamental está na natureza desses agentes: eles não são apenas scripts automatizados, mas sistemas inteligentes capazes de compreender contexto, tomar decisões baseadas em dados e aprender com cada interação. Eles podem adaptar suas respostas conforme a situação, personalizar abordagens para diferentes usuários e até mesmo colaborar entre si para resolver problemas complexos.\nOs Benefícios Tangíveis da Transformação A transição para o escritório digital traz benefícios mensuráveis e imediatos. Empresas que implementaram agentes de IA relatam reduções significativas no tempo de resposta a clientes, aumento na precisão de análises e liberação de recursos humanos para atividades de maior valor agregado. A Mastercard, por exemplo, utilizou agentes digitais para acelerar o processo de onboarding de clientes, reduzindo drasticamente o tempo necessário para ativação de novos usuários.\nA AT\u0026amp;T implementou agentes especializados em detecção de fraudes, criando uma camada de proteção que opera 24 horas por dia, analisando padrões de comportamento e identificando ameaças em tempo real. Esses casos demonstram como os agentes de IA não são apenas ferramentas de automação, mas verdadeiros multiplicadores de capacidade empresarial.\nConhecendo os Novos Funcionários Digitais O que São os Agentes de IA Os agentes de inteligência artificial são sistemas autônomos que funcionam como funcionários digitais especializados, capazes de perceber seu ambiente, tomar decisões e executar ações para atingir objetivos específicos. Diferentemente de simples automações, esses agentes possuem capacidades cognitivas que lhes permitem adaptar-se a situações novas, aprender com experiências passadas e colaborar efetivamente com humanos e outros agentes.\nImagine um funcionário que nunca se cansa, processa informações em velocidade sobre-humana, mantém consistência absoluta em suas ações e está sempre disponível. Esse é o perfil básico de um agente de IA. Eles operam através de quatro capacidades fundamentais: percepção (coleta de informações através de APIs, sensores e interfaces), cognição (processamento e análise usando modelos de linguagem avançados), ação (execução de tarefas através de ferramentas e sistemas) e aprendizado (melhoria contínua baseada em feedback e resultados).\nTipos de Funcionários Digitais No escritório digital moderno, encontramos diferentes tipos de agentes, cada um especializado em funções específicas. Os agentes de atendimento ao cliente são como recepcionistas super eficientes, capazes de compreender consultas complexas, acessar informações de múltiplos sistemas e fornecer respostas personalizadas instantaneamente. Eles podem lidar com centenas de interações simultâneas, mantendo o mesmo nível de qualidade e cortesia em cada conversa.\nOs agentes de análise de dados funcionam como analistas sêniores que trabalham ininterruptamente. Eles monitoram continuamente fluxos de dados, identificam tendências, detectam anomalias e geram insights acionáveis. Diferentemente de relatórios estáticos, esses agentes podem adaptar suas análises conforme o contexto, focando em métricas específicas quando detectam mudanças significativas no negócio.\nAgentes de operações de TI atuam como administradores de sistema proativos, monitorando infraestrutura, prevendo falhas, executando manutenções preventivas e resolvendo problemas automaticamente. Eles podem diagnosticar problemas complexos analisando logs de múltiplos sistemas, correlacionando eventos e implementando soluções sem intervenção humana.\nCapacidades e Limitações Os agentes de IA modernos possuem capacidades impressionantes, mas é importante compreender tanto seus pontos fortes quanto suas limitações. Eles excel em tarefas que envolvem processamento de grandes volumes de dados, reconhecimento de padrões, execução de processos padronizados e tomada de decisões baseadas em regras claras. Podem trabalhar com múltiplas fontes de informação simultaneamente, mantendo contexto e consistência ao longo de interações prolongadas.\nNo entanto, esses agentes ainda enfrentam desafios em situações que requerem criatividade genuína, compreensão emocional profunda ou tomada de decisões em cenários completamente novos sem precedentes. Eles funcionam melhor quando têm acesso a dados estruturados e quando os objetivos são claramente definidos. A supervisão humana continua sendo essencial para validar decisões críticas e fornecer direcionamento estratégico.\nExemplos Práticos de Atuação Na prática, esses funcionários digitais estão transformando operações em diversos setores. No e-commerce, agentes especializados gerenciam automaticamente o ciclo completo de vendas: qualificam leads analisando comportamento de navegação, personalizam recomendações de produtos, processam pedidos, coordenam logística e acompanham a satisfação pós-venda. Eles podem identificar clientes em risco de abandono e implementar estratégias de retenção personalizadas automaticamente.\nNo setor financeiro, agentes de compliance monitoram transações em tempo real, identificando padrões suspeitos e garantindo conformidade regulatória. Eles analisam milhões de transações diárias, aplicando regras complexas de detecção de fraude e gerando alertas apenas para casos que realmente requerem investigação humana. Isso permite que as equipes de segurança se concentrem em ameaças genuínas, aumentando significativamente a eficácia da proteção.\nNa área de recursos humanos, agentes especializados automatizam processos de recrutamento, analisando currículos, conduzindo triagens iniciais e até mesmo agendando entrevistas. Eles podem avaliar candidatos com base em critérios objetivos, eliminando vieses inconscientes e garantindo processos mais justos e eficientes. Além disso, podem monitorar continuamente a satisfação dos funcionários, identificando sinais de insatisfação antes que resultem em rotatividade.\nAgent Bricks: O Departamento de RH Automático A Revolução na Contratação de Funcionários Digitais Tradicionalmente, criar agentes de IA era como tentar contratar funcionários especializados sem ter um departamento de RH estruturado. As empresas precisavam de equipes técnicas altamente qualificadas, meses de desenvolvimento, processos complexos de avaliação e ajustes manuais constantes. O Agent Bricks da Databricks revoluciona esse cenário, funcionando como um departamento de recursos humanos automático que simplifica drasticamente o processo de \u0026ldquo;contratação\u0026rdquo; e treinamento de agentes digitais.\nO Agent Bricks representa uma mudança fundamental na abordagem de desenvolvimento de agentes. Em vez de focar na complexidade técnica da implementação, ele permite que as empresas se concentrem no que realmente importa: definir claramente o que precisam que o agente faça e fornecer orientações sobre qualidade e performance. É como ter um diretor de RH experiente que compreende exatamente o perfil necessário para cada vaga e consegue encontrar, treinar e avaliar candidatos automaticamente.\nComo Funciona o Processo de \u0026ldquo;Contratação\u0026rdquo; O processo de criação de agentes com Agent Bricks segue uma metodologia estruturada que elimina a complexidade técnica tradicional. Primeiro, você define a \u0026ldquo;descrição da vaga\u0026rdquo; em linguagem natural, especificando exatamente o que o agente deve fazer, quais dados ele deve acessar e quais resultados são esperados. Essa descrição funciona como um briefing detalhado que orienta todo o processo de desenvolvimento.\nEm seguida, o Agent Bricks atua como um recrutador especializado, analisando automaticamente os requisitos e criando benchmarks de avaliação específicos para a tarefa. Ele pode gerar dados sintéticos para testes, criar cenários de validação e até mesmo desenvolver métricas personalizadas para medir a performance do agente. Esse processo, que tradicionalmente levaria semanas de trabalho manual, é executado automaticamente em questão de horas.\nO sistema então \u0026ldquo;treina\u0026rdquo; o agente, otimizando sua performance através de ciclos iterativos de teste e ajuste. Como um supervisor experiente, o Agent Bricks monitora continuamente o desempenho, identifica áreas de melhoria e implementa otimizações automaticamente. Esse processo de melhoria contínua garante que o agente evolua constantemente, adaptando-se a novos cenários e mantendo alta qualidade em suas entregas.\nTipos de \u0026ldquo;Vagas\u0026rdquo; Disponíveis O Agent Bricks oferece diferentes \u0026ldquo;modelos de contratação\u0026rdquo; através de templates especializados que funcionam como descrições de cargo pré-definidas. O Knowledge Assistant é como contratar um bibliotecário especializado que conhece profundamente toda a documentação da empresa. Esse agente pode responder perguntas complexas sobre produtos, políticas, procedimentos e histórico da organização, fornecendo respostas precisas e contextualizadas baseadas em documentos internos.\nO Information Extraction funciona como um analista de dados especializado em transformar informações não estruturadas em dados organizados. Ele pode processar contratos, relatórios, e-mails e documentos diversos, extraindo informações específicas e organizando-as em formatos estruturados. Isso é particularmente valioso para empresas que lidam com grandes volumes de documentos e precisam extrair insights rapidamente.\nO Custom LLM permite criar agentes completamente personalizados, como contratar um especialista sob medida para necessidades específicas da empresa. Esses agentes podem ser treinados com dados proprietários, seguir protocolos específicos da organização e integrar-se perfeitamente com sistemas existentes. O Multi-Agent Supervisor atua como um gerente de equipe, coordenando múltiplos agentes e garantindo que trabalhem em harmonia para atingir objetivos complexos.\nBenefícios do RH Automático A principal vantagem do Agent Bricks é a democratização da criação de agentes de IA. Empresas que antes precisavam de equipes técnicas especializadas agora podem \u0026ldquo;contratar\u0026rdquo; funcionários digitais com a mesma facilidade de usar uma planilha. Isso reduz drasticamente as barreiras de entrada para adoção de IA, permitindo que organizações de todos os tamanhos se beneficiem dessa tecnologia.\nO sistema também elimina o problema da \u0026ldquo;contratação errada\u0026rdquo;. Através de avaliação automática e otimização contínua, o Agent Bricks garante que cada agente seja perfeitamente adequado para sua função. Se um agente não está performando conforme esperado, o sistema identifica automaticamente os problemas e implementa correções, como um departamento de RH que monitora constantemente a performance dos funcionários e oferece treinamento adicional quando necessário.\nAlém disso, o Agent Bricks resolve o desafio da escalabilidade. Uma vez que um agente é criado e otimizado, ele pode ser replicado instantaneamente para lidar com cargas de trabalho maiores. É como ter a capacidade de \u0026ldquo;clonar\u0026rdquo; seu melhor funcionário sempre que a demanda aumenta, mantendo o mesmo nível de qualidade e eficiência.\nCases de Sucesso na \u0026ldquo;Contratação\u0026rdquo; Empresas como a Mastercard utilizaram o Agent Bricks para \u0026ldquo;contratar\u0026rdquo; assistentes digitais especializados em onboarding de clientes. Esses agentes automatizaram completamente o processo de ativação de novos usuários, reduzindo o tempo de processamento de dias para minutos. O resultado foi uma melhoria significativa na experiência do cliente e liberação da equipe humana para atividades mais estratégicas.\nA AT\u0026amp;T implementou agentes especializados em proteção contra fraudes, criando uma equipe digital que trabalha 24 horas por dia analisando padrões de comportamento suspeito. Esses \u0026ldquo;funcionários digitais\u0026rdquo; conseguem processar milhões de transações simultaneamente, identificando ameaças com precisão superior aos métodos tradicionais e respondendo em tempo real.\nA Crisis Text Line utilizou o Agent Bricks para criar agentes especializados em saúde mental, capazes de fornecer suporte inicial a pessoas em crise. Esses agentes foram treinados para reconhecer sinais de emergência, oferecer recursos apropriados e escalar casos críticos para profissionais humanos quando necessário. O resultado foi uma ampliação significativa da capacidade de atendimento sem comprometer a qualidade do cuidado oferecido.\nLakebase: O Sistema de Comunicação Perfeito A Infraestrutura do Escritório Digital Todo escritório eficiente precisa de um sistema de comunicação e armazenamento de informações que permita aos funcionários acessar rapidamente os dados necessários para executar suas funções. No escritório digital, o Lakebase da Databricks assume esse papel fundamental, funcionando como uma combinação de sistema de arquivos, rede de comunicação interna e biblioteca corporativa, tudo otimizado especificamente para as necessidades dos agentes de IA.\nO Lakebase representa uma nova categoria de banco de dados, projetado desde o início para a era da inteligência artificial. Diferentemente dos bancos de dados tradicionais, que foram criados para aplicações convencionais e depois adaptados para IA, o Lakebase foi concebido especificamente para suportar as demandas únicas dos agentes inteligentes: acesso simultâneo de milhares de agentes, capacidade de experimentação e rollback, e integração perfeita entre dados operacionais e analíticos.\nCaracterísticas do Sistema Perfeito O Lakebase opera com base em princípios que o tornam ideal para o escritório digital moderno. Sua arquitetura serverless significa que ele escala automaticamente conforme a demanda, como um sistema de comunicação que se expande instantaneamente quando mais funcionários digitais entram em operação. Não há necessidade de provisionar recursos antecipadamente ou se preocupar com limitações de capacidade.\nA separação entre computação e armazenamento permite que os agentes acessem dados de forma extremamente eficiente, sem os gargalos típicos de sistemas tradicionais. É como ter um arquivo central onde qualquer funcionário pode acessar qualquer documento instantaneamente, sem filas ou limitações de acesso simultâneo. Essa arquitetura também resulta em custos significativamente menores, já que você paga apenas pelos recursos efetivamente utilizados.\nA compatibilidade com PostgreSQL garante que o Lakebase se integre perfeitamente com sistemas existentes, eliminando a necessidade de migrações complexas ou reescrita de aplicações. É como implementar um novo sistema de comunicação que funciona perfeitamente com todas as ferramentas que a empresa já utiliza, sem necessidade de treinamento adicional ou mudanças disruptivas.\nFuncionalidades Avançadas para Agentes Uma das características mais inovadoras do Lakebase é sua capacidade de branching, similar ao controle de versão em desenvolvimento de software. Isso permite que agentes criem \u0026ldquo;cópias de trabalho\u0026rdquo; dos dados para experimentação, testando diferentes cenários sem afetar os dados de produção. Imagine funcionários que podem criar versões paralelas de documentos para testar diferentes abordagens, com a capacidade de reverter instantaneamente para a versão original se necessário.\nEssa funcionalidade é particularmente valiosa para agentes que precisam aprender e se adaptar. Eles podem experimentar diferentes estratégias, analisar resultados e implementar apenas as mudanças que demonstraram sucesso. O processo de checkpointing permite que agentes salvem estados específicos de seu trabalho, criando pontos de restauração que podem ser utilizados para rollback em caso de problemas.\nA integração nativa com o lakehouse elimina a necessidade de ETL complexo entre sistemas operacionais e analíticos. Os agentes podem acessar tanto dados transacionais em tempo real quanto informações históricas para análise, tudo através da mesma interface. É como ter um sistema de arquivos unificado onde relatórios operacionais e análises estratégicas coexistem perfeitamente.\nBenefícios para Performance e Escalabilidade O Lakebase foi projetado para suportar milhares de agentes operando simultaneamente, cada um com suas próprias necessidades de acesso a dados. Essa capacidade de escala massiva é fundamental para empresas que planejam implementar agentes em larga escala. Diferentemente de bancos de dados tradicionais que podem se tornar gargalos quando o número de conexões aumenta, o Lakebase mantém performance consistente independentemente da carga.\nA arquitetura serverless significa que não há necessidade de planejamento de capacidade ou gerenciamento de infraestrutura. O sistema se adapta automaticamente às demandas, escalando para cima durante picos de atividade e reduzindo recursos durante períodos de menor utilização. Isso resulta em custos otimizados e elimina a necessidade de superprovisionar recursos para lidar com picos ocasionais.\nA velocidade de acesso aos dados é otimizada especificamente para padrões de uso de agentes de IA, que frequentemente precisam acessar grandes volumes de dados rapidamente para tomar decisões em tempo real. O Lakebase utiliza técnicas avançadas de cache e otimização de consultas para garantir que os agentes tenham acesso instantâneo às informações necessárias.\nIntegração com o Ecossistema Empresarial O Lakebase não opera isoladamente, mas se integra perfeitamente com o ecossistema de dados existente da empresa. Sua compatibilidade com padrões abertos garante que ferramentas de BI, aplicações analíticas e sistemas de relatório continuem funcionando sem modificações. É como implementar um novo sistema de comunicação que melhora a eficiência sem quebrar os processos existentes.\nA integração com o Agent Bricks cria uma sinergia poderosa: enquanto o Agent Bricks funciona como o departamento de RH que contrata e treina agentes, o Lakebase fornece a infraestrutura de dados que esses agentes precisam para operar eficientemente. Essa combinação permite que empresas implementem soluções completas de IA sem se preocupar com complexidades técnicas de integração.\nO suporte a múltiplas clouds garante flexibilidade de deployment e evita vendor lock-in. Empresas podem escolher onde hospedar seus dados baseado em requisitos de compliance, performance ou custo, mantendo a mesma funcionalidade e interface independentemente da plataforma escolhida.\nCasos de Uso Transformadores Na prática, o Lakebase está permitindo casos de uso que eram impraticáveis com tecnologias tradicionais. Empresas de e-commerce estão utilizando agentes que analisam comportamento de clientes em tempo real, acessando simultaneamente dados transacionais, histórico de navegação e informações de inventário para personalizar experiências instantaneamente. A capacidade do Lakebase de lidar com essa carga de trabalho complexa sem degradação de performance é fundamental para o sucesso dessas implementações.\nInstituições financeiras estão implementando agentes de compliance que monitoram transações em tempo real, correlacionando informações de múltiplas fontes para detectar padrões suspeitos. O Lakebase permite que esses agentes acessem tanto dados transacionais atuais quanto históricos extensos para análise de padrões, tudo com a velocidade necessária para detecção em tempo real.\nEmpresas de manufatura estão utilizando agentes para otimização de cadeia de suprimentos, que precisam acessar dados de produção, inventário, logística e demanda simultaneamente. O Lakebase permite que esses agentes tenham uma visão unificada de toda a operação, tomando decisões otimizadas baseadas em informações completas e atualizadas.\nImplementando o Escritório Digital na Prática Primeiros Passos para a Transformação A transição para um escritório digital não acontece da noite para o dia, mas pode ser implementada de forma gradual e estratégica. O primeiro passo é identificar processos que são bons candidatos para automação inteligente: tarefas repetitivas que consomem tempo significativo, processos que requerem análise de grandes volumes de dados, ou atividades que precisam ser executadas 24 horas por dia.\nComece mapeando os \u0026ldquo;cargos\u0026rdquo; que você gostaria de preencher com funcionários digitais. Analise quais departamentos gastam mais tempo em atividades que poderiam ser automatizadas e quais processos geram mais frustração devido à sua natureza repetitiva. Essa análise inicial ajudará a priorizar onde os agentes de IA podem gerar maior impacto imediato.\nÉ importante começar com projetos piloto que tenham escopo bem definido e métricas claras de sucesso. Escolha um processo específico, como atendimento a consultas frequentes de clientes ou análise de relatórios de vendas, e implemente um agente dedicado para essa função. Isso permite validar a abordagem, ajustar processos e demonstrar valor antes de expandir para outras áreas.\nEstratégias de Implementação Gradual A implementação bem-sucedida do escritório digital segue uma abordagem em fases. Na primeira fase, foque em agentes que complementam o trabalho humano sem substituir completamente processos existentes. Por exemplo, implemente um agente de Knowledge Assistant que ajuda a equipe de suporte a encontrar informações rapidamente, mas mantém humanos responsáveis pela interação final com clientes.\nNa segunda fase, expanda para agentes que podem assumir responsabilidades completas em áreas específicas. Agentes de Information Extraction podem processar automaticamente documentos recebidos, categorizando e extraindo informações relevantes sem necessidade de supervisão constante. Isso libera funcionários humanos para atividades que requerem julgamento e criatividade.\nA terceira fase envolve a implementação de agentes mais sofisticados que podem tomar decisões complexas e coordenar múltiplas atividades. Esses agentes podem gerenciar workflows completos, desde a identificação de oportunidades até a execução de ações corretivas, operando com autonomia significativa dentro de parâmetros pré-definidos.\nConsiderações Técnicas e Organizacionais A implementação técnica com Agent Bricks e Lakebase simplifica significativamente o processo, mas ainda requer planejamento cuidadoso. Certifique-se de que os dados necessários estão acessíveis e bem organizados. Os agentes são tão eficazes quanto a qualidade dos dados que têm disponíveis, então investir em limpeza e estruturação de dados é fundamental para o sucesso.\nEstabeleça governança clara para os agentes, definindo quais decisões eles podem tomar autonomamente e quais requerem aprovação humana. Isso é particularmente importante em setores regulamentados, onde certas ações podem ter implicações de compliance. Crie protocolos de escalação que permitam aos agentes transferir casos complexos para supervisão humana quando necessário.\nTreine sua equipe para trabalhar efetivamente com agentes de IA. Isso não significa apenas ensinar como usar as ferramentas, mas também como supervisionar agentes, interpretar seus resultados e identificar quando intervenção humana é necessária. A colaboração efetiva entre humanos e agentes é fundamental para maximizar os benefícios da implementação.\nMedindo Sucesso e ROI Estabeleça métricas claras para avaliar o sucesso da implementação do escritório digital. Meça não apenas eficiência operacional, como redução no tempo de processamento ou aumento no volume de tarefas completadas, mas também qualidade dos resultados e satisfação dos usuários finais. Agentes que processam tarefas rapidamente mas produzem resultados de baixa qualidade não agregam valor real.\nMonitore o impacto na produtividade humana. O objetivo não é apenas automatizar tarefas, mas liberar funcionários para atividades de maior valor. Meça como o tempo economizado está sendo utilizado e se está resultando em inovação, melhoria de processos ou melhor atendimento ao cliente.\nCalcule o ROI considerando não apenas custos diretos de implementação, mas também benefícios indiretos como melhoria na satisfação do cliente, redução de erros e capacidade de operar 24/7. Muitas empresas descobrem que os benefícios intangíveis, como maior agilidade e capacidade de resposta, são tão valiosos quanto as economias diretas de custo.\nSuperando Desafios Comuns Um dos principais desafios na implementação do escritório digital é a resistência à mudança. Funcionários podem temer que agentes de IA ameacem seus empregos. Comunique claramente que o objetivo é amplificar capacidades humanas, não substituí-las. Mostre como os agentes podem eliminar tarefas tediosas e permitir que as pessoas se concentrem em trabalho mais interessante e estratégico.\nOutro desafio comum é a expectativa de resultados imediatos. Embora o Agent Bricks simplifique significativamente a criação de agentes, ainda é necessário tempo para ajustar processos, treinar equipes e otimizar performance. Estabeleça expectativas realistas e celebre vitórias incrementais ao longo do caminho.\nA integração com sistemas legados pode apresentar complexidades técnicas. O Lakebase ajuda a minimizar esses desafios através de sua compatibilidade com padrões abertos, mas ainda pode ser necessário trabalho de integração customizado. Planeje adequadamente para essas atividades e considere implementação em fases para reduzir riscos.\nEvoluindo o Escritório Digital O escritório digital não é um destino final, mas um processo contínuo de evolução. À medida que agentes demonstram sucesso em áreas específicas, identifique oportunidades para expandir suas responsabilidades ou criar novos agentes para outras funções. A natureza modular do Agent Bricks facilita essa expansão gradual.\nMantenha-se atualizado com novas capacidades e funcionalidades. A área de IA evolui rapidamente, e novas possibilidades surgem constantemente. Participe de comunidades de usuários, acompanhe atualizações da plataforma e experimente com novas funcionalidades em ambientes de teste antes de implementar em produção.\nConsidere a criação de centros de excelência internos para IA, onde equipes especializadas podem desenvolver melhores práticas, treinar outros departamentos e coordenar iniciativas de agentes em toda a organização. Isso garante que o conhecimento seja compartilhado e que a implementação mantenha consistência e qualidade em toda a empresa.\nO Futuro do Trabalho Já Chegou O escritório digital representa mais do que uma simples evolução tecnológica; é uma transformação fundamental na forma como concebemos produtividade, eficiência e colaboração no ambiente empresarial. Com o Agent Bricks e o Lakebase, a Databricks não apenas democratizou o acesso à inteligência artificial, mas criou um ecossistema completo que permite a qualquer organização construir sua própria força de trabalho digital.\nOs benefícios dessa transformação vão além da automação tradicional. Estamos falando de agentes que aprendem, se adaptam e evoluem continuamente, criando valor de formas que nem sempre são imediatamente óbvias. A capacidade de operar 24 horas por dia, processar volumes massivos de informação e manter consistência absoluta em todas as interações representa um salto qualitativo na capacidade empresarial.\nA jornada para o escritório digital não é apenas sobre tecnologia, mas sobre reimaginar o potencial humano. Quando libertamos nossos funcionários de tarefas repetitivas e damos a eles ferramentas inteligentes para amplificar suas capacidades, criamos espaço para inovação, criatividade e crescimento estratégico. O futuro do trabalho não é sobre humanos versus máquinas, mas sobre humanos e máquinas trabalhando em harmonia perfeita para alcançar resultados extraordinários.\nAs empresas que abraçarem essa transformação hoje estarão posicionadas para liderar em seus mercados amanhã. O escritório digital não é mais uma visão futurista, mas uma realidade acessível que está redefinindo os padrões de excelência operacional em todos os setores da economia.\nEspero que tenha gostado da leitura. Até o próximo artigo !\n","permalink":"https://julianamarialop.github.io/articles/o-novo-escritorio-digital-como-os-agentes-de-ia-se-tornaram/","summary":"Imagine um escritório onde os funcionários nunca se cansam, trabalham 24 horas por dia, aprendem constantemente e executam tarefas com precisão cirúrgica. Esse cenário, que parecia ficção científica há poucos anos…","title":"O Novo Escritório Digital: Como os Agentes de IA se Tornaram os Funcionários Mais Eficientes da Empresa"},{"content":"No mundo atual, onde dados são o novo petróleo (ou talvez os novos tijolos?), construir soluções de Analytics robustas e eficientes no Azure tornou-se uma tarefa de engenharia complexa. Plataformas como Microsoft Fabric , Azure Databricks, Azure Data Factory e Power BI nos oferecem ferramentas poderosas, mas usá-las de forma isolada, sem um plano mestre, é como tentar erguer um arranha-céu sem uma planta baixa detalhada. O resultado? Estruturas instáveis, custos exorbitantes, brechas de segurança e um desempenho que deixa a desejar.\nImagine que sua solução de Analytics é um edifício moderno e sofisticado. Você não começaria a construção sem uma planta baixa detalhada, certo? O Azure Well-Architected Framework (WAF) é exatamente isso: a planta baixa essencial que guia a construção da sua \u0026ldquo;edificação\u0026rdquo; de dados. E o Azure Well-Architected Review? Pense nele como a inspeção técnica rigorosa, realizada pelo engenheiro responsável, para garantir que cada viga, cada pilar e cada sistema esteja em conformidade com as melhores práticas, garantindo a qualidade, segurança e eficiência da obra.\nNeste artigo, vamos vestir nossos capacetes de construção e explorar as cinco \u0026ldquo;fundações\u0026rdquo; essenciais (os pilares do WAF) que garantem a solidez da sua edificação de Analytics no Azure. Veremos como aplicar essa \u0026ldquo;planta baixa\u0026rdquo; e realizar as \u0026ldquo;inspeções\u0026rdquo; necessárias para garantir que sua solução não seja apenas funcional, mas uma verdadeira obra-prima da engenharia de dados.\n1. A Fundação Essencial (Confiabilidade - Reliability) Assim como um edifício precisa de fundações sólidas e uma estrutura robusta para resistir a terremotos, tempestades e ao desgaste do tempo, sua solução de Analytics precisa ser confiável. A confiabilidade garante que seus pipelines de dados (como os sistemas hidráulicos e elétricos do prédio) funcionem continuamente e que a solução possa se recuperar rapidamente de falhas inesperadas (como um blecaute ou um cano estourado).\nNa prática da construção de Analytics:\nEstruturas Resilientes: Projete seus pipelines no Azure Data Factory ou Databricks com mecanismos de retry automático, tratamento de erros robusto e checkpoints. Se uma etapa da \u0026ldquo;montagem\u0026rdquo; falhar, o processo deve ser capaz de tentar novamente ou continuar de onde parou, sem comprometer toda a \u0026ldquo;obra\u0026rdquo;. Materiais Resistentes: Utilize armazenamento de dados com alta disponibilidade e redundância, como o Azure Data Lake Storage Gen2 configurado com redundância geográfica (GRS) ou geográfica com acesso de leitura (RA-GRS/GZRS). Isso garante que seus \u0026ldquo;materiais de construção\u0026rdquo; (dados) estejam seguros mesmo se um \u0026ldquo;depósito\u0026rdquo; (data center) inteiro tiver problemas. Planos de Contingência: Defina estratégias de alta disponibilidade (HA) e recuperação de desastres (DR) para componentes críticos. Para um Azure Synapse Dedicated SQL Pool, isso pode envolver backups regulares e um plano para restaurar em outra região. Para clusters Databricks, pense em como recriar rapidamente a infraestrutura em caso de falha regional. Monitoramento Estrutural: Assim como sensores monitoram a integridade estrutural de um prédio, use o Azure Monitor para acompanhar a saúde dos seus serviços de Analytics. Configure alertas para falhas em pipelines, indisponibilidade de clusters ou degradação de performance, permitindo uma resposta rápida a qualquer \u0026ldquo;rachadura\u0026rdquo; na estrutura. Simulações de Carga (Testes de Falha): Periodicamente, realize testes para validar seus planos de recuperação. É como fazer simulações de incêndio ou terremoto para garantir que os sistemas de segurança e evacuação funcionem conforme o esperado. 2. O Sistema de Segurança (Segurança - Security) Um edifício de valor precisa de um sistema de segurança robusto: fechaduras fortes, controle de acesso rigoroso, câmeras de vigilância, alarmes e talvez até muros altos. Da mesma forma, sua solução de Analytics, que lida com dados potencialmente sensíveis, exige múltiplas camadas de segurança para proteger contra acessos não autorizados, vazamentos e outras ameaças.\nNa prática da construção de Analytics:\nIsolamento da Obra: Utilize Redes Virtuais (VNets), Private Endpoints e Network Security Groups (NSGs) para criar um perímetro seguro ao redor dos seus serviços de Analytics. Limite o acesso público e garanta que apenas componentes autorizados possam se comunicar. Controle de Acesso (Chaves e Crachás): Integre seus serviços com o Azure Active Directory (Entra ID) para gerenciamento centralizado de identidades. Use autenticação forte (MFA), Acesso Condicional e Managed Identities para que os serviços se autentiquem entre si de forma segura. Aplique o princípio de menor privilégio usando Role-Based Access Control (RBAC) e, quando possível, Attribute-Based Access Control (ABAC) para definir quem pode acessar quais \u0026ldquo;salas\u0026rdquo; (recursos) e \u0026ldquo;documentos\u0026rdquo; (dados). Proteção dos Materiais (Dados): Criptografe seus dados tanto em repouso (usando criptografia transparente de dados no Synapse SQL, criptografia do ADLS Gen2) quanto em trânsito (TLS/SSL). Implemente técnicas como mascaramento dinâmico de dados para ocultar informações sensíveis de usuários não autorizados em relatórios do Power BI ou consultas SQL. Vigilância Contínua: Habilite logs de diagnóstico e auditoria em todos os serviços (Data Factory, Databricks, Synapse, Key Vault). Use o Microsoft Defender for Cloud para monitorar configurações de segurança, detectar ameaças e avaliar vulnerabilidades em sua \u0026ldquo;construção\u0026rdquo;. Governança (Regras do Condomínio): Utilize o Microsoft Purview para catalogar seus ativos de dados, classificar informações sensíveis, definir políticas de acesso e rastrear a linhagem dos dados. É como ter um manual claro sobre como os \u0026ldquo;moradores\u0026rdquo; (usuários e serviços) podem interagir com os diferentes \u0026ldquo;espaços\u0026rdquo; (dados) do edifício. 3. O Orçamento da Obra (Otimização de Custos - Cost Optimization) Nenhuma construção acontece sem um orçamento rigoroso. Otimizar custos em Analytics significa escolher os materiais (serviços) com melhor custo-benefício, dimensionar corretamente a mão de obra e os equipamentos (recursos de computação), evitar desperdícios e monitorar continuamente os gastos para não estourar o orçamento.\nNa prática da construção de Analytics:\nDimensionamento Inteligente: Configure o autoscaling para clusters Databricks e pools Spark do Synapse. Use a opção de pausar e resumir para Synapse Dedicated SQL Pools. Evite manter \u0026ldquo;maquinário pesado\u0026rdquo; (clusters grandes) ligado desnecessariamente. Escolha Certa de Materiais: Use o serviço certo para a tarefa certa. Orquestre com Data Factory, processe dados massivos com Databricks/Synapse Spark, sirva dados agregados com Synapse SQL ou Analysis Services, visualize com Power BI. Não use um \u0026ldquo;guindaste\u0026rdquo; (cluster Spark potente) para levantar um \u0026ldquo;saco de cimento\u0026rdquo; (tarefa simples). Otimização do Canteiro (Armazenamento): Armazene dados no ADLS Gen2 usando formatos colunares eficientes como Delta Lake ou Parquet. Utilize particionamento e compressão. Implemente políticas de ciclo de vida para mover dados frios para camadas de acesso esporádico (Cool/Archive tiers), liberando espaço no \u0026ldquo;canteiro\u0026rdquo; principal. Evitar Retrabalho (Movimentação de Dados): Minimize a movimentação desnecessária de dados entre serviços. Use recursos como virtualização de dados ou processamento in-loco sempre que possível. Ferramentas de Gestão: Utilize o Azure Cost Management + Billing para rastrear gastos por recurso ou tag. Siga as recomendações do Azure Advisor, que frequentemente sugere otimizações específicas para seus serviços de Analytics. Contratos de Longo Prazo: Se você tem cargas de trabalho previsíveis, considere Azure Reservations ou Azure Savings Plans para obter descontos significativos em recursos de computação (VMs para Databricks, Synapse SQL DWUs). 4. A Manutenção e Operação (Excelência Operacional - Operational Excellence) Entregar a chave do edifício não é o fim da história. A excelência operacional trata dos processos para manter a \u0026ldquo;construção\u0026rdquo; funcionando perfeitamente ao longo do tempo: planos de manutenção preventiva, automação predial, documentação clara e equipes bem treinadas.\nNa prática da construção de Analytics:\nAutomação da Construção (CI/CD \u0026amp; IaC): Use Azure DevOps ou GitHub Actions para criar pipelines de CI/CD que automatizam o teste e o deploy de código (pipelines Data Factory, notebooks Databricks, scripts SQL) e infraestrutura (usando ARM Templates ou Terraform). Isso garante consistência e reduz erros manuais nas \u0026ldquo;reformas\u0026rdquo; ou \u0026ldquo;expansões\u0026rdquo;. Controle de Qualidade Contínuo: Implemente testes automatizados em seus pipelines: testes unitários para transformações, testes de integração entre componentes e testes de qualidade de dados para validar os resultados. É a garantia de que cada \u0026ldquo;andar\u0026rdquo; entregue está de acordo com as especificações. Monitoramento Centralizado (Painel de Controle): Integre logs e métricas de todos os seus serviços de Analytics no Azure Monitor e Log Analytics. Crie dashboards e alertas proativos para detectar problemas antes que impactem os \u0026ldquo;moradores\u0026rdquo; (usuários finais). Boas Práticas de Gestão (DataOps/MLOps): Adote princípios de DataOps para agilizar a entrega de pipelines de dados confiáveis. Se sua solução envolve Machine Learning, implemente MLOps para gerenciar o ciclo de vida dos modelos. Documentação (Plantas Atualizadas): Mantenha a documentação da sua arquitetura, pipelines e processos atualizada. Isso é crucial para o onboarding de novos membros da equipe e para a solução de problemas. 5. A Funcionalidade e Acabamento (Eficiência de Performance - Performance Efficiency) De que adianta um prédio seguro e bem construído se os elevadores são lentos, o layout é confuso e a climatização não funciona direito? A eficiência de performance garante que sua solução de Analytics não apenas funcione, mas funcione bem, entregando resultados rapidamente e adaptando-se às mudanças na demanda (mais \u0026ldquo;moradores\u0026rdquo; ou \u0026ldquo;visitantes\u0026rdquo;).\nNa prática da construção de Analytics:\nLayout Otimizado (Design de Dados): Use técnicas como particionamento inteligente no ADLS Gen2 e em tabelas (Delta, Synapse SQL), indexação adequada (Synapse SQL) e design de esquema otimizado (star schema, snowflake) para acelerar as consultas. Motores Potentes (Computação): Escolha os tipos e tamanhos corretos de clusters (Databricks) ou níveis de serviço (Synapse SQL Pools) para sua carga de trabalho. Use o autoscaling para ajustar a \u0026ldquo;potência\u0026rdquo; conforme a necessidade. Materiais Leves (Formatos e Cache): Utilize formatos colunares (Parquet, Delta) que otimizam a leitura. Implemente caching em diferentes camadas: cache de dados no Spark, cache de resultados no Power BI (modo Import ou DirectQuery com agregações), cache do Synapse SQL. Logística Interna (Otimização de Consultas): Analise os planos de execução das suas consultas SQL ou jobs Spark. Otimize joins, filtre dados o mais cedo possível (predicate pushdown) e use estatísticas atualizadas para ajudar o otimizador. Medir a Satisfação (Monitoramento): Monitore continuamente a latência das consultas, o tempo de execução dos pipelines e a utilização dos recursos. Identifique gargalos e otimize proativamente. 6. A Inspeção de Qualidade (O Azure Well-Architected Review para Analytics) Agora que conhecemos as fundações, como garantimos que nossa construção está realmente seguindo a planta baixa? É aqui que entra o Azure Well-Architected Review, nossa inspeção técnica. A Microsoft oferece uma ferramenta de assessment online, inclusive com uma versão específica para workloads de Analytics.\nEssa ferramenta guia você através de uma série de perguntas focadas em cada um dos cinco pilares, aplicadas ao contexto dos seus serviços (Synapse, Databricks, etc.). Por exemplo:\nConfiabilidade: Você tem mecanismos de retry nos seus pipelines do Data Factory? Segurança: Seus dados sensíveis no ADLS Gen2 estão criptografados em repouso? Custo: Você utiliza autoscaling nos seus clusters Databricks? Operações: Você tem um processo de CI/CD para seus artefatos de Analytics? Performance: Suas tabelas no Synapse SQL estão particionadas corretamente? Ao responder essas perguntas, você realiza uma autoavaliação da sua \u0026ldquo;obra\u0026rdquo;. O resultado é um relatório detalhado que aponta os pontos fortes e, mais importante, as áreas onde sua arquitetura pode não estar alinhada com as melhores práticas – as \u0026ldquo;não conformidades\u0026rdquo; encontradas na inspeção.\n7. Ajustando a Planta e a Obra (Implementando Recomendações) O relatório da inspeção não serve apenas para apontar problemas; ele fornece recomendações práticas para corrigi-los. É como o engenheiro dizendo: \u0026ldquo;Precisamos reforçar esta viga\u0026rdquo;, \u0026ldquo;O isolamento térmico aqui está inadequado\u0026rdquo; ou \u0026ldquo;Vamos otimizar o sistema de ventilação\u0026rdquo;.\nImplementar as recomendações do Well-Architected Review é o processo de ajustar sua \u0026ldquo;planta\u0026rdquo; e sua \u0026ldquo;obra\u0026rdquo;:\nInterpretação: Entenda o porquê de cada recomendação e seu impacto no seu cenário específico. Priorização: Nem toda recomendação precisa ser implementada imediatamente. Priorize com base no risco, impacto no negócio e esforço necessário. Uma falha estrutural (confiabilidade) ou uma porta aberta (segurança) geralmente têm prioridade sobre um ajuste fino no acabamento (performance). Ciclo Contínuo: A construção nunca termina de verdade. O Well-Architected Review não é um evento único, mas um ciclo contínuo. Revise sua arquitetura periodicamente (a cada 6 meses, ou após mudanças significativas), implemente as melhorias, meça os resultados e repita a inspeção. É a manutenção preventiva que garante a longevidade e o valor do seu \u0026ldquo;edifício\u0026rdquo; de dados. Conclusão Construir uma solução de Analytics de ponta no Azure é uma empreitada significativa, muito parecida com erguer um edifício complexo. Ignorar a \u0026ldquo;planta baixa\u0026rdquo; (o Well-Architected Framework) e pular as \u0026ldquo;inspeções de qualidade\u0026rdquo; (o Well-Architected Review) é correr o risco de entregar uma estrutura frágil, insegura, cara e ineficiente.\nAo adotar os cinco pilares como as fundações essenciais da sua construção com Confiabilidade, Segurança, Otimização de Custos, Excelência Operacional e Eficiência de Performance e ao utilizar o Review como sua ferramenta de inspeção regular, você garante que sua solução de Analytics seja uma verdadeira obra de engenharia: robusta, protegida, econômica, fácil de operar e altamente performática.\nPortanto, da próxima vez que iniciar um projeto de Analytics no Azure ou revisar um existente, pegue sua \u0026ldquo;planta baixa\u0026rdquo;, coloque seu capacete e realize sua \u0026ldquo;inspeção\u0026rdquo;. O resultado será um \u0026ldquo;edifício\u0026rdquo; de dados do qual você poderá se orgulhar, pronto para suportar as necessidades do seu negócio hoje e no futuro.\nAté mais !\n","permalink":"https://julianamarialop.github.io/articles/planta-baixa-perfeita-para-analytics-azure-solucoes-solidas/","summary":"No mundo atual, onde dados são o novo petróleo (ou talvez os novos tijolos?), construir soluções de Analytics robustas e eficientes no Azure tornou-se uma tarefa de engenharia complexa. Plataformas como Microsoft Fabric…","title":"A Planta Baixa Perfeita para Analytics no Azure: Construindo Soluções Sólidas com o Well-Architected Review"},{"content":"O Apache Spark tem sido, há mais de uma década, a plataforma de processamento de dados preferida por engenheiros e cientistas de dados ao redor do mundo. Com sua capacidade de processar grandes volumes de informações em memória, unificar análises em batch e streaming, e oferecer APIs intuitivas em múltiplas linguagens, o Spark conquistou seu lugar como ferramenta essencial no ecossistema de big data. Agora, com o lançamento do Apache Spark 4.0, testemunhamos uma evolução significativa que promete transformar ainda mais a experiência de trabalhar com dados em larga escala.\nImagine o Spark 4.0 como um parque de diversões completamente renovado que acaba de reabrir suas portas. O \u0026ldquo;Spark Land\u0026rdquo; já era conhecido por suas atrações emocionantes, mas agora retorna com novas montanhas-russas de alta velocidade, áreas temáticas redesenhadas, sistemas FastPass mais eficientes e uma série de comodidades que melhoram a experiência de todos os visitantes. Assim como um parque temático moderno oferece diversão para diferentes perfis de visitantes, o Spark 4.0 traz novidades que atendem a desenvolvedores Python, engenheiros de dados, analistas SQL e cientistas de dados.\nNeste artigo, vamos explorar as diferentes áreas deste fascinante parque de dados: a área das atrações principais com as novas funcionalidades, a área dos equipamentos especiais com extensões e APIs, a área de experiências personalizadas com funções e procedimentos customizáveis, e a área de serviços e comodidades com melhorias significativas de usabilidade. Prepare seu ingresso e venha conhecer o Spark Land 4.0!\nA Área das Atrações Principais (Novas Funcionalidades) Spark Connect: A Montanha-Russa Virtual\nToda grande inauguração de parque precisa de uma atração revolucionária, e no Spark Land 4.0, essa atração é o Spark Connect. Imagine uma montanha-russa que você pode experimentar remotamente, sem precisar estar fisicamente no parque - é exatamente isso que o Spark Connect oferece para o mundo dos dados.\nAnteriormente, trabalhar com Spark significava instalar todo o ambiente (um pacote robusto de 355 MB) em sua máquina local. Era como ter que construir uma réplica do parque em sua casa para poder experimentar as atrações. Com o Spark Connect, você agora pode utilizar um cliente leve de apenas 1,5 MB, conectando-se remotamente ao cluster onde a \u0026ldquo;diversão pesada\u0026rdquo; acontece.\n```python # Criando uma sessão com Spark Connect from pyspark.sql import SparkSession spark = SparkSession \\ .builder \\ .appName(\u0026#34;Exemplo Spark Connect\u0026#34;) \\ .master(\u0026#34;sc://seu-servidor:15002\u0026#34;) \\ .getOrCreate() # Agora você pode trabalhar com DataFrames remotamente df = spark.read.format(\u0026#34;csv\u0026#34;).option(\u0026#34;header\u0026#34;, \u0026#34;true\u0026#34;).load(\u0026#34;dados.csv\u0026#34;) df.show() ``` Esta funcionalidade é como usar óculos de realidade virtual para experimentar as atrações do parque de qualquer lugar. Desenvolvedores podem agora trabalhar em seus IDEs favoritos como PyCharm ou Jupyter, conectando-se remotamente aos clusters Spark sem a sobrecarga de recursos locais. É como se o parque viesse até você!\nANSI Mode: O Carrossel Clássico Renovado\nTodo parque tem aquela atração clássica que todos conhecem e amam, mas que de tempos em tempos precisa de uma renovação. O ANSI Mode, ativado por padrão no Spark 4.0, é como o tradicional carrossel que recebeu novos sistemas de segurança e controle de qualidade.\nEsta funcionalidade alinha o Spark SQL com os padrões ANSI SQL, implementando regras mais rígidas para tratamento de NULL, conversões de tipo e operações aritméticas. Por exemplo, em versões anteriores, um overflow numérico simplesmente fazia wrap-around, potencialmente levando a resultados incorretos sem aviso. Agora, com ANSI Mode, você recebe uma exceção clara:\n```sql -- Em versões anteriores: retornaria -2147483648 (wrap-around) -- No Spark 4.0 com ANSI Mode: lança uma exceção de overflow SELECT 2147483647 + 1; ``` É como um carrossel que agora tem cintos de segurança aprimorados e sensores que param a atração automaticamente se algo estiver fora dos padrões. Esta mudança é particularmente valiosa para quem migra de bancos de dados tradicionais para o Spark, pois encontrará um comportamento mais familiar e previsível - como um visitante que se sente em casa ao encontrar sua atração favorita, mas agora com mais segurança.\nVariant Data Type: A Casa dos Espelhos Mágica\nUma das atrações mais fascinantes em qualquer parque é a casa dos espelhos, onde sua imagem é distorcida e transformada de maneiras surpreendentes. O Variant Data Type do Spark 4.0 funciona de forma similar, oferecendo uma maneira flexível de trabalhar com dados semi-estruturados, adaptando-se a diferentes formas e estruturas.\nEste novo tipo de dados permite armazenar e processar estruturas hierárquicas complexas com eficiência, utilizando técnicas de shredding para otimizar performance. É ideal para cenários como análise de IoT e logs web, onde a estrutura dos dados pode variar:\n```python # Trabalhando com o tipo Variant from pyspark.sql import SparkSession spark = SparkSession.builder.appName(\u0026#34;Exemplo Variant\u0026#34;).getOrCreate() data = [(\u0026#34;sensor1\u0026#34;, {\u0026#34;temperatura\u0026#34;: 25.5, \u0026#34;umidade\u0026#34;: 60}), (\u0026#34;sensor2\u0026#34;, [{\u0026#34;temperatura\u0026#34;: 26.1}, {\u0026#34;temperatura\u0026#34;: 26.3}])] df = spark.createDataFrame(data, [\u0026#34;id\u0026#34;, \u0026#34;leituras\u0026#34;]) # Acessando campos dentro do tipo Variant df.select(\u0026#34;id\u0026#34;, \u0026#34;leituras.temperatura\u0026#34;).show() ``` É como entrar em uma casa dos espelhos onde cada espelho mostra uma versão diferente de você - às vezes mais alto, às vezes mais largo, às vezes completamente diferente - mas ainda reconhecível como você. O Variant Type permite que seus dados assumam diferentes formas mantendo sua essência e acessibilidade.\nCollation Support: A Torre Internacional\nUm parque de diversões global precisa atender visitantes de diferentes países e culturas. A Torre Internacional do Spark Land 4.0 - o Collation Support - faz exatamente isso para seus dados textuais. Esta funcionalidade permite especificar como as comparações de strings devem ser tratadas, considerando aspectos como case sensitivity e regras específicas de locale.\n```sql -- Criando uma tabela com collation específica CREATE TABLE nomes ( nome STRING COLLATE \u0026#39;pt_BR.UTF8\u0026#39; ); -- Consulta que respeita as regras de collation SELECT * FROM nomes WHERE nome = \u0026#39;José\u0026#39; COLLATE \u0026#39;pt_BR.UTF8\u0026#39;; ``` É como uma torre de observação com guias multilíngues que adaptam a experiência para visitantes de diferentes países. Para aplicações multilíngues, esta funcionalidade é essencial, garantindo ordenação e comparação consistentes em diferentes ambientes culturais - como garantir que todos os visitantes, independentemente de sua origem, possam desfrutar plenamente da vista panorâmica do parque.\nA Área dos Equipamentos Especiais (Extensões) Python Data Source APIs: O Kit de Construção DIY\nTodo parque moderno tem uma área onde os visitantes podem personalizar sua experiência. As Python Data Source APIs do Spark 4.0 são como um kit \u0026ldquo;Faça Você Mesmo\u0026rdquo; que permite aos desenvolvedores Python criar suas próprias atrações personalizadas sem precisar recorrer a Java ou Scala.\n```python from pyspark.sql.datasource import DataSourceReader, DataSourceWriter class MeuLeitor(DataSourceReader): def read_batch(self): # Lógica personalizada para leitura de dados return spark.createDataFrame([(\u0026#34;valor1\u0026#34;,), (\u0026#34;valor2\u0026#34;,)], [\u0026#34;coluna\u0026#34;]) # Registrando e usando a fonte de dados personalizada spark.read.format(\u0026#34;minha_fonte\u0026#34;).load().show() ``` Esta extensão é como ter um conjunto de blocos de construção, ferramentas e instruções para criar sua própria mini-atração dentro do parque. Você não está mais limitado às experiências pré-fabricadas - agora pode construir algo único que atenda exatamente às suas necessidades específicas.\nDelta 4.0: O Sistema de Segurança Premium\nA infraestrutura de segurança é o que permite que um parque de diversões funcione sem problemas, mesmo que os visitantes não a percebam diretamente. O Delta 4.0 no Spark Land é esse sistema de segurança premium, trazendo recursos avançados para o formato Delta Lake, incluindo Delta Connect para gerenciamento aprimorado de lakehouse.\nCom melhorias em confiabilidade, performance e facilidade de uso, o Delta 4.0 eleva a qualidade de toda a experiência no parque, especialmente para quem trabalha com arquiteturas lakehouse:\n```python # Usando recursos avançados do Delta 4.0 from delta import DeltaTable # Operação de merge otimizada deltaTable = DeltaTable.forPath(spark, \u0026#34;/caminho/para/tabela\u0026#34;) deltaTable.alias(\u0026#34;destino\u0026#34;) \\ .merge( atualizacoes.alias(\u0026#34;origem\u0026#34;), \u0026#34;destino.id = origem.id\u0026#34; ) \\ .whenMatchedUpdate(set = {\u0026#34;valor\u0026#34;: \u0026#34;origem.novo_valor\u0026#34;}) \\ .whenNotMatchedInsert(values = {\u0026#34;id\u0026#34;: \u0026#34;origem.id\u0026#34;, \u0026#34;valor\u0026#34;: \u0026#34;origem.novo_valor\u0026#34;}) \\ .execute() ``` Assim como um sistema de segurança avançado que monitora todas as atrações, gerencia filas e previne acidentes, o Delta 4.0 garante que seus dados estejam sempre seguros, consistentes e acessíveis quando necessário. É a tranquilidade de saber que, mesmo nos bastidores, tudo está funcionando perfeitamente.\nXML/Databricks Connectors: As Pontes Temáticas\nAs pontes temáticas em um parque conectam diferentes áreas, permitindo que os visitantes transitem suavemente entre experiências distintas. Os conectores XML e Databricks no Spark 4.0 funcionam da mesma forma, criando conexões perfeitas entre diferentes formatos de dados e ecossistemas.\nO conector XML aprimorado facilita o trabalho com dados em formato XML, que podem ser complexos e aninhados:\n```python # Lendo dados XML com o conector aprimorado df = spark.read \\ .format(\u0026#34;xml\u0026#34;) \\ .option(\u0026#34;rowTag\u0026#34;, \u0026#34;livro\u0026#34;) \\ .load(\u0026#34;biblioteca.xml\u0026#34;) df.select(\u0026#34;titulo\u0026#34;, \u0026#34;autor.nome\u0026#34;).show() ``` Estes conectores são como pontes decoradas tematicamente que não apenas permitem a passagem entre áreas do parque, mas também enriquecem a experiência durante a transição. Eles permitem que você trabalhe com formatos e sistemas que antes eram difíceis de integrar, criando uma experiência contínua em todo o parque de dados.\nDSV2 Extension: A Rede Elétrica Inteligente\nA rede elétrica de um parque de diversões é invisível para a maioria dos visitantes, mas é absolutamente essencial para o funcionamento de todas as atrações. A extensão DataSource V2 (DSV2) no Spark 4.0 funciona como essa rede elétrica inteligente, oferecendo APIs aprimoradas para fontes de dados que beneficiam todo o ecossistema.\nEsta extensão proporciona maior flexibilidade para implementação de fontes de dados, com melhor suporte para pushdown de predicados, particionamento e outras otimizações:\n```python # Usando uma fonte de dados baseada em DSV2 df = spark.read \\ .format(\u0026#34;jdbc\u0026#34;) \\ .option(\u0026#34;url\u0026#34;, \u0026#34;jdbc:postgresql://servidor/banco\u0026#34;) \\ .option(\u0026#34;dbtable\u0026#34;, \u0026#34;usuarios\u0026#34;) \\ .option(\u0026#34;pushDownPredicate\u0026#34;, \u0026#34;true\u0026#34;) \\ .load() # O filtro será \u0026#34;empurrado\u0026#34; para o banco de dados filtrado = df.filter(\u0026#34;idade \u0026gt; 30\u0026#34;) ``` Assim como uma rede elétrica moderna e eficiente que distribui energia de forma inteligente para todas as atrações do parque, o DSV2 eleva a qualidade de todas as fontes de dados no Spark 4.0, resultando em melhor performance e capacidades expandidas. Você não a vê diretamente, mas sente seu impacto positivo em toda a experiência.\nA Área de Experiências Personalizadas (Funções e Procedimentos) SQL UDFs e Scripting: O Parque Personalizado\nOs parques mais exclusivos oferecem experiências VIP onde você pode personalizar cada aspecto de sua visita. As SQL UDFs (User-Defined Functions) e o SQL Scripting no Spark 4.0 oferecem essa mesma experiência personalizada para suas consultas SQL.\nCom SQL UDFs, você pode definir funções personalizadas diretamente em SQL:\n```sql -- Criando uma UDF em SQL CREATE FUNCTION dobro(x INT) RETURNS INT RETURN x * 2; -- Usando a função SELECT id, dobro(valor) AS valor_dobrado FROM tabela; ``` O SQL Scripting permite criar scripts SQL complexos com lógica procedural:\n```sql -- Script SQL com lógica procedural BEGIN DECLARE v_total INT; SET v_total = 0; FOR r IN (SELECT valor FROM tabela WHERE categoria = \u0026#39;A\u0026#39;) DO SET v_total = v_total + r.valor; END FOR; SELECT v_total AS total_categoria_a; END; ``` Estas capacidades são como ter um concierge pessoal no parque que organiza seu dia exatamente como você deseja, criando um roteiro personalizado que não está disponível para visitantes comuns. Você pode expressar exatamente o que deseja e como deseja, sem sair do ambiente SQL.\nPython UDTFs: O Simulador Multidimensional\nOs simuladores mais avançados em parques temáticos oferecem experiências imersivas em múltiplas dimensões. As Python UDTFs (User-Defined Table Functions) no Spark 4.0 são como esses simuladores de última geração, permitindo criar funções em Python que retornam múltiplas linhas e colunas.\n```python from pyspark.sql.functions import udtf @udtf(returnType=\u0026#34;value INT, quadrado INT, cubo INT\u0026#34;) def gerar_potencias(x): yield (x, x**2, x**3) # Usando a UDTF df = spark.createDataFrame([(1,), (2,), (3,)], [\u0026#34;numero\u0026#34;]) df.select(\u0026#34;numero\u0026#34;, gerar_potencias(\u0026#34;numero\u0026#34;)).show() ``` Esta funcionalidade é como um simulador 4D que oferece múltiplas experiências sensoriais simultaneamente - você não apenas vê a aventura, mas sente, ouve e até mesmo cheira os elementos da história. As UDTFs permitem transformações complexas que geram múltiplos resultados a partir de uma única entrada, enriquecendo significativamente suas capacidades analíticas.\nArrow Optimized: O FastPass Universal\nTodo visitante frequente de parques conhece o valor de um FastPass que permite pular filas. O Apache Arrow no Spark 4.0 funciona como um FastPass Universal, otimizando a transferência de dados entre processos Python e JVM para reduzir drasticamente os tempos de espera.\nEsta otimização reduz significativamente o overhead de serialização/deserialização, especialmente importante para UDFs Python e integração com pandas:\n```python # Configurando o uso otimizado de Arrow spark.conf.set(\u0026#34;spark.sql.execution.arrow.pyspark.enabled\u0026#34;, \u0026#34;true\u0026#34;) # Convertendo DataFrame Spark para pandas com Arrow pandas_df = spark_df.toPandas() # Aplicando transformações em pandas e voltando para Spark resultado = spark.createDataFrame(pandas_df_transformado) ``` É como ter um passe especial que permite acessar qualquer atração sem esperar nas filas, tornando toda a experiência no parque mais fluida e agradável. Com Arrow, as transferências de dados que antes eram gargalos agora fluem rapidamente, permitindo que você aproveite mais as \u0026ldquo;atrações\u0026rdquo; analíticas em menos tempo.\nPySpark UDF Unified Profiler: O Monitor de Performance\nOs parques modernos utilizam sistemas sofisticados para monitorar a performance de suas atrações e a experiência dos visitantes. O PySpark UDF Unified Profiler no Spark 4.0 é esse sistema de monitoramento, permitindo analisar o desempenho de UDFs Python para identificar gargalos e otimizar o código.\n```python # Habilitando o profiler unificado spark.conf.set(\u0026#34;spark.python.profile\u0026#34;, \u0026#34;true\u0026#34;) spark.conf.set(\u0026#34;spark.python.profile.dump\u0026#34;, \u0026#34;/tmp/profile\u0026#34;) # Definindo e usando uma UDF @udf(\u0026#34;int\u0026#34;) def funcao_complexa(x): # Lógica complexa return resultado # Executando com profiling df.select(funcao_complexa(\u0026#34;coluna\u0026#34;)).show() # Analisando o resultado do profiling # O arquivo será gerado em /tmp/profile ``` Esta ferramenta é como um sistema de monitoramento que analisa quanto tempo os visitantes passam em cada atração, onde ocorrem congestionamentos e como melhorar o fluxo geral do parque. Com o Unified Profiler, você pode identificar exatamente onde seu código Python está gastando mais tempo e otimizá-lo para uma experiência mais rápida e eficiente.\nA Área de Serviços e Comodidades (Usabilidade) Structured Logging Framework: O Sistema de Informações Digital\nUm parque de diversões moderno precisa de um sistema de informações eficiente que mantenha os visitantes atualizados sobre todas as atrações. O Structured Logging Framework no Spark 4.0 traz essa mesma atenção aos detalhes para os logs, estruturando-os em formato JSON para facilitar análise e monitoramento.\n``` {\u0026#34;timestamp\u0026#34;: \u0026#34;2025-05-28T10:15:30.123Z\u0026#34;, \u0026#34;level\u0026#34;: \u0026#34;INFO\u0026#34;, \u0026#34;message\u0026#34;: \u0026#34;Job 42 completed\u0026#34;, \u0026#34;jobId\u0026#34;: 42, \u0026#34;duration\u0026#34;: 1500, \u0026#34;records\u0026#34;: 10000} ``` Em vez de logs de texto plano difíceis de analisar, você agora tem logs estruturados que podem ser facilmente processados por ferramentas de monitoramento. É como passar de mapas em papel e quadros de avisos para telas digitais interativas espalhadas pelo parque, fornecendo informações claras e atualizadas sobre todas as atrações, tempos de espera e eventos especiais.\nError Class Framework: O Serviço de Atendimento ao Cliente\nQuando algo dá errado em um parque, um bom serviço de atendimento ao cliente faz toda a diferença. O Error Class Framework no Spark 4.0 é esse serviço premium, fornecendo mensagens padronizadas e detalhadas que facilitam o diagnóstico de problemas.\nERROR [INVALID_SCHEMA.FIELD_NOT_FOUND] Campo \u0026#39;idade\u0026#39; não encontrado no esquema. Esquema atual: [\u0026#39;nome\u0026#39;, \u0026#39;endereco\u0026#39;, \u0026#39;telefone\u0026#39;] Dica: Verifique se o nome do campo está correto ou se a coluna existe no DataFrame. Esta estruturação de erros é como ter uma equipe de atendimento bem treinada que não apenas informa que algo deu errado, mas explica exatamente o que aconteceu, por que aconteceu e como resolver o problema. Em vez de mensagens crípticas que deixam você frustrado, você recebe orientações claras que economizam tempo precioso de debugging.\nBehavior Change Process: O Guia de Adaptação\nQuando um parque renova suas atrações, visitantes frequentes precisam se adaptar às mudanças. O Behavior Change Process no Spark 4.0 é como um guia de adaptação que facilita a transição para novas versões, documentando claramente as mudanças de comportamento e oferecendo caminhos de migração.\nEste processo estruturado ajuda equipes a entender o impacto de atualizações e adaptar seu código gradualmente, em vez de enfrentar surpresas desagradáveis após uma atualização:\n```python # Configuração para compatibilidade com comportamento anterior spark.conf.set(\u0026#34;spark.sql.legacy.timeParserPolicy\u0026#34;, \u0026#34;LEGACY\u0026#34;) # Gradualmente migrar para o novo comportamento # após testar o impacto spark.conf.set(\u0026#34;spark.sql.legacy.timeParserPolicy\u0026#34;, \u0026#34;CORRECTED\u0026#34;) ``` É como ter um guia detalhado que explica todas as mudanças no parque, com dicas sobre como aproveitar ao máximo as novas atrações enquanto se adapta às diferenças. Este processo torna a transição entre versões do Spark muito mais suave e previsível, permitindo que equipes adotem novas funcionalidades no seu próprio ritmo.\nRoteiros Recomendados (Casos de Uso) Agora que exploramos todas as áreas do nosso parque de dados, vamos ver alguns roteiros recomendados para diferentes tipos de visitantes.\nRoteiro para Engenheiros de Dados (Aventureiros)\nPara engenheiros de dados que buscam construir pipelines robustos e escaláveis, recomendamos:\nPrimeira parada: Spark Connect para desenvolvimento remoto e colaborativo\nAtração principal: Delta 4.0 para gerenciamento confiável de dados\nExperiência complementar: DSV2 Extension para fontes de dados otimizadas\nAntes de sair: Structured Logging para monitoramento avançado\nEste roteiro proporciona uma experiência completa para construção e manutenção de pipelines de dados confiáveis e performáticos, como um dia de aventuras radicais no parque.\nRoteiro para Cientistas de Dados (Exploradores)\nPara cientistas de dados focados em análise e modelagem:\nPrimeira parada: Python Data Source APIs para integração com fontes específicas\nAtração principal: Suporte a pandas 2.x para análise exploratória familiar\nExperiência complementar: Arrow Optimized para transferência eficiente entre Spark e pandas\nAntes de sair: Python UDTFs para transformações complexas\nEsta combinação oferece um ambiente produtivo que se integra perfeitamente ao ecossistema Python que cientistas de dados já conhecem e amam, como um dia de exploração e descobertas no parque.\nRoteiro para Analistas SQL (Clássicos)\nPara analistas que preferem trabalhar principalmente com SQL:\nPrimeira parada: ANSI Mode para comportamento SQL previsível e padronizado\nAtração principal: SQL UDFs e Scripting para análises complexas\nExperiência complementar: Collation Support para tratamento adequado de dados textuais\nAntes de sair: Error Class Framework para diagnóstico claro de problemas\nEste roteiro proporciona uma experiência SQL robusta e expressiva, permitindo análises sofisticadas sem sair do ambiente SQL, como um dia aproveitando as atrações clássicas e atemporais do parque.\nConclusão O Apache Spark 4.0 representa uma evolução significativa na plataforma, trazendo um parque de diversões completo de novas funcionalidades, extensões, funções personalizadas e melhorias de usabilidade. Assim como um parque temático renovado atrai tanto novos visitantes quanto fãs de longa data, o Spark 4.0 oferece atrações para todos os perfis no mundo dos dados.\nAs novas funcionalidades como Spark Connect e ANSI Mode estabelecem uma base sólida para o futuro, enquanto extensões como Python Data Source APIs e Delta 4.0 expandem as possibilidades de integração. As funções personalizadas como Python UDTFs e otimizações com Arrow melhoram a experiência de desenvolvimento, e as melhorias de usabilidade como Structured Logging e Error Class Framework facilitam o diagnóstico e resolução de problemas.\nDa próxima vez que você estiver trabalhando com big data, considere fazer uma visita ao Spark Land 4.0. Com seu ingresso em mãos (e talvez um FastPass para as atrações mais populares), você descobrirá um mundo de possibilidades analíticas mais emocionantes e eficientes do que nunca. O parque está aberto - venha se divertir!\nEste artigo faz parte da newsletter \u0026ldquo;De Dados a Insights\u0026rdquo;. Para mais conteúdo sobre Apache Spark, Databricks e engenharia de dados moderna, siga-me no LinkedIn.\n","permalink":"https://julianamarialop.github.io/articles/spark-land-40-o-parque-de-diversoes-dos-dados-acaba-abrir/","summary":"O Apache Spark tem sido, há mais de uma década, a plataforma de processamento de dados preferida por engenheiros e cientistas de dados ao redor do mundo. Com sua capacidade de processar grandes volumes de informações em…","title":"Spark Land 4.0: O Parque de Diversões dos Dados Acaba de Abrir suas Portas"},{"content":"Implantar projetos de dados em diferentes ambientes sempre foi um desafio comparável a tentar replicar um prato gourmet em diferentes cozinhas. Mesmo com os mesmos ingredientes, pequenas variações nas configurações, na ordem de preparo ou nas ferramentas utilizadas podem resultar em experiências completamente diferentes – algumas vezes com resultados desastrosos.\nO Databricks Asset Bundle (DAB) surge como um verdadeiro kit de chef profissional para engenheiros de dados. Assim como um chef estrelado pode levar seu kit de facas, temperos e receitas detalhadas para garantir a mesma qualidade gastronômica em qualquer cozinha do mundo, o DAB permite que equipes de dados empacotem, versionem e implantem seus projetos de forma consistente em qualquer workspace Databricks, seja ele de desenvolvimento, teste ou produção.\nEsta abordagem revolucionária transforma a maneira como gerenciamos projetos na plataforma Databricks, trazendo práticas modernas de DevOps para o mundo dos dados. Ao adotar o conceito de \u0026ldquo;Infraestrutura como Código\u0026rdquo; (IaC), o DAB permite que todo o projeto – incluindo notebooks, workflows, configurações de clusters e outros recursos – seja definido em arquivos declarativos, versionado em sistemas como Git e implantado de forma automatizada através de pipelines de CI/CD.\nA Receita Perfeita (O que é o Databricks Asset Bundle) Imagine que você é um chef responsável por garantir que o mesmo prato seja servido com perfeição em diferentes restaurantes de uma franquia internacional. Você precisaria de uma receita extremamente detalhada, que não deixasse margem para interpretações ou variações indesejadas. É exatamente isso que o Databricks Asset Bundle oferece para projetos de dados.\nO coração do DAB é o arquivo databricks.yml, comparável a uma receita meticulosamente escrita por um chef estrelado. Este arquivo YAML contém todas as instruções necessárias para \u0026ldquo;cozinhar\u0026rdquo; seu projeto Databricks, desde a definição dos \u0026ldquo;ingredientes\u0026rdquo; (recursos) até o modo de preparo (configurações) e apresentação final (implantação).\nExemplo simplificado de um databricks.yml\nbundle: name: meu-projeto-analytics variables: data_path: default: /data/bronze description: Caminho para os dados brutos targets: dev: workspace: host: https://dev-workspace.cloud.databricks.com variables: data_path: /data/dev/bronze prod: workspace: host: https://prod-workspace.cloud.databricks.com resources: jobs: etl_diario: name: ETL Diário schedule: quartz_cron_expression: \u0026#34;0 0 2 * * ?\u0026#34; tasks: ingestao: notebook_task: notebook_path: /Notebooks/ingestao job_cluster_key: cluster_padrao job_clusters: cluster_padrao: spark_version: 13.3.x-scala2.12 node_type_id: Standard_DS3_v2 autoscale: min_workers: 1 max_workers: 4 Assim como uma receita bem escrita não deixa dúvidas sobre quantidades, tempos e técnicas, o arquivo databricks.yml elimina ambiguidades na configuração do projeto. Cada seção tem um propósito específico:\nMetadados do Bundle: Nome e informações básicas do projeto Variáveis: Parâmetros que podem ser referenciados em todo o arquivo Ambientes (targets): Configurações específicas para diferentes workspaces Recursos: Definição de jobs, clusters, notebooks e outros componentes Os Ingredientes Premium (Recursos gerenciados pelo DAB) Um chef sabe que a qualidade do prato final depende diretamente da qualidade dos ingredientes utilizados. No contexto do Databricks Asset Bundle, os \u0026ldquo;ingredientes\u0026rdquo; são os diversos recursos que compõem seu projeto:\nNotebooks: O equivalente às receitas individuais que compõem um menu Workflows (Jobs): A sequência de preparação, como um menu degustação Clusters: Os fornos e equipamentos necessários para o preparo Secrets: Os ingredientes especiais que precisam ser protegidos Pipelines: As técnicas de preparação avançadas O DAB permite gerenciar todos esses \u0026ldquo;ingredientes\u0026rdquo; de forma centralizada, garantindo que sejam combinados na proporção correta e na ordem adequada. Assim como um chef não deixaria a escolha dos ingredientes ao acaso, o DAB não deixa a configuração dos recursos à mercê de processos manuais propensos a erros.\nUm dos grandes diferenciais desta abordagem é a capacidade de versionar esses \u0026ldquo;ingredientes\u0026rdquo; junto com o código. Imagine poder guardar não apenas as receitas, mas também a especificação exata dos ingredientes e equipamentos utilizados em cada versão do seu menu. É isso que o DAB proporciona ao integrar-se com sistemas de controle de versão como Git.\nCozinhando em Qualquer Cozinha (Consistência entre ambientes) Um dos maiores desafios para chefs internacionais é adaptar-se a cozinhas diferentes mantendo a consistência dos pratos. Da mesma forma, equipes de dados enfrentam o desafio de garantir que seus projetos funcionem da mesma maneira em ambientes de desenvolvimento, teste e produção.\nO Databricks Asset Bundle resolve esse problema permitindo definir configurações específicas para cada ambiente, mantendo a estrutura básica do projeto intacta. É como ter uma receita base que pode ser ligeiramente adaptada para diferentes ocasiões, sem perder sua essência.\ntargets: dev: workspace: host: https://dev-workspace.cloud.databricks.com variables: cluster_size: small data_retention: 7 qa: workspace: host: https://qa-workspace.cloud.databricks.com variables: cluster_size: medium data_retention: 14 prod: workspace: host: https://prod-workspace.cloud.databricks.com variables: cluster_size: large data_retention: 30 Esta capacidade de adaptação controlada traz benefícios significativos:\nPrevisibilidade: Se funciona em desenvolvimento, funcionará em produção Rastreabilidade: Todas as diferenças entre ambientes são explícitas e documentadas Reprodutibilidade: Ambientes podem ser recriados exatamente como eram em qualquer ponto no tempo Governança: Políticas específicas podem ser aplicadas a cada ambiente Os Sous-Chefs Automatizados (Integração com CI/CD) Em restaurantes de alto padrão, o chef principal conta com sous-chefs confiáveis que seguem suas instruções à risca, garantindo que cada prato saia perfeito mesmo quando o chef não está diretamente envolvido em cada etapa. No mundo do Databricks Asset Bundle, os pipelines de CI/CD assumem esse papel.\nA integração do DAB com ferramentas como GitHub Actions, Azure DevOps ou GitLab CI permite automatizar todo o processo de implantação, desde a validação da \u0026ldquo;receita\u0026rdquo; até a \u0026ldquo;apresentação do prato final\u0026rdquo; no ambiente de destino.\nVeja um exemplo de como seria um workflow do GitHub Actions para implantar um projeto DAB:\nname: Deploy Databricks Assets on: push: branches: [ main ] pull_request: branches: [ main ] jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up Python uses: actions/setup-python@v4 with: python-version: \u0026#39;3.10\u0026#39; - name: Install Databricks CLI run: pip install databricks-cli - name: Deploy to Dev if: github.event_name == \u0026#39;pull_request\u0026#39; run: | databricks bundle deploy -t dev env: DATABRICKS_HOST: ${{ secrets.DEV_DATABRICKS_HOST }} DATABRICKS_TOKEN: ${{ secrets.DEV_DATABRICKS_TOKEN }} - name: Deploy to Prod if: github.event_name == \u0026#39;push\u0026#39; \u0026amp;\u0026amp; github.ref == \u0026#39;refs/heads/main\u0026#39; run: | databricks bundle deploy -t prod env: DATABRICKS_HOST: ${{ secrets.PROD_DATABRICKS_HOST }} DATABRICKS_TOKEN: ${{ secrets.PROD_DATABRICKS_TOKEN }} Estes \u0026ldquo;sous-chefs automatizados\u0026rdquo; trazem diversos benefícios:\nConsistência: O processo de implantação é sempre o mesmo, independentemente de quem o inicia Velocidade: Implantações são realizadas rapidamente, sem intervenção manual Auditoria: Cada implantação é registrada, incluindo quem a iniciou e quais mudanças foram aplicadas Segurança: Credenciais e segredos são gerenciados de forma segura, sem exposição direta Degustação Antes de Servir (Validação e testes) Nenhum chef responsável serviria um prato sem antes prová-lo. Da mesma forma, o Databricks Asset Bundle permite que você \u0026ldquo;deguste\u0026rdquo; seu projeto antes de implantá-lo em ambientes compartilhados.\nA CLI do Databricks oferece comandos específicos para validar e testar localmente seu bundle:\n# Validar a configuração do bundle databricks bundle validate -t dev # Implantar localmente para teste databricks bundle deploy -t dev Esta capacidade de validação prévia é crucial para identificar problemas antes que eles afetem outros usuários ou, pior ainda, dados de produção. É como ter uma cozinha de testes onde você pode experimentar novas receitas antes de adicioná-las ao menu oficial.\nAlguns exemplos de problemas que podem ser detectados durante a validação:\nReferências a recursos inexistentes Configurações inválidas ou incompatíveis Problemas de sintaxe no arquivo YAML Inconsistências entre diferentes partes do projeto Receita Passo a Passo (Implementação prática) Agora que entendemos os conceitos e benefícios do Databricks Asset Bundle, vamos ver como implementá-lo em um projeto real, seguindo uma receita passo a passo:\n1. Preparação da \u0026ldquo;Cozinha\u0026rdquo; (Ambiente de desenvolvimento)\nPrimeiro, precisamos instalar as ferramentas necessárias:\n# Para Windows winget install Databricks.DatabricksCLI # Para Mac brew tap databricks/tap brew install databricks Em seguida, configuramos a autenticação com o workspace Databricks:\ndatabricks configure --profile DEFAULT 2. Criação da \u0026ldquo;Receita Base\u0026rdquo; (Inicialização do bundle)\nCom as ferramentas instaladas, podemos iniciar nosso primeiro bundle:\n# Criar um novo diretório para o projeto mkdir meu-projeto-databricks cd meu-projeto-databricks # Inicializar o bundle databricks bundle init Este comando criará um arquivo databricks.yml básico que podemos personalizar.\n3. Personalização da \u0026ldquo;Receita\u0026rdquo; (Configuração do bundle)\nAgora, editamos o arquivo databricks.yml para incluir todos os recursos necessários:\nbundle: name: meu-projeto-analytics variables: env: default: dev description: Ambiente atual (dev, qa, prod) data_path: default: /data/bronze description: Caminho para os dados brutos targets: dev: workspace: host: https://dev-workspace.cloud.databricks.com variables: env: dev qa: workspace: host: https://qa-workspace.cloud.databricks.com variables: env: qa prod: workspace: host: https://prod-workspace.cloud.databricks.com variables: env: prod resources: jobs: etl_diario: name: \u0026#34;ETL Diário - ${variables.env}\u0026#34; schedule: quartz_cron_expression: \u0026#34;0 0 2 * * ?\u0026#34; tasks: ingestao: notebook_task: notebook_path: /Notebooks/ingestao base_parameters: data_path: \u0026#34;${variables.data_path}\u0026#34; env: \u0026#34;${variables.env}\u0026#34; job_cluster_key: cluster_padrao job_clusters: cluster_padrao: spark_version: 13.3.x-scala2.12 node_type_id: Standard_DS3_v2 autoscale: min_workers: 1 max_workers: 4 4. \u0026ldquo;Degustação\u0026rdquo; (Validação e teste local)\nAntes de compartilhar nossa receita, vamos testá-la localmente:\n# Validar a configuração databricks bundle validate -t dev # Implantar para teste databricks bundle deploy -t dev 5. Preparação para o \u0026ldquo;Serviço\u0026rdquo; (Configuração do CI/CD)\nFinalmente, configuramos um pipeline de CI/CD para automatizar a implantação. Se estiver usando GitHub, crie um arquivo .github/workflows/deploy.yml:\nname: Deploy Databricks Assets on: push: branches: [ main ] pull_request: branches: [ main ] jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up Python uses: actions/setup-python@v4 with: python-version: \u0026#39;3.10\u0026#39; - name: Install Databricks CLI run: pip install databricks-cli - name: Validate Bundle run: databricks bundle validate - name: Deploy to Dev if: github.event_name == \u0026#39;pull_request\u0026#39; run: | databricks bundle deploy -t dev env: DATABRICKS_HOST: ${{ secrets.DEV_DATABRICKS_HOST }} DATABRICKS_TOKEN: ${{ secrets.DEV_DATABRICKS_TOKEN }} - name: Deploy to QA if: github.event_name == \u0026#39;push\u0026#39; \u0026amp;\u0026amp; github.ref == \u0026#39;refs/heads/main\u0026#39; run: | databricks bundle deploy -t qa env: DATABRICKS_HOST: ${{ secrets.QA_DATABRICKS_HOST }} DATABRICKS_TOKEN: ${{ secrets.QA_DATABRICKS_TOKEN }} Conclusão O Databricks Asset Bundle representa uma evolução significativa na forma como gerenciamos projetos na plataforma Databricks. Assim como um kit de chef profissional transforma a experiência culinária, o DAB transforma o ciclo de vida de desenvolvimento de projetos de dados.\nAo adotar esta abordagem, equipes de dados podem:\nGarantir consistência entre diferentes ambientes Automatizar implantações através de pipelines de CI/CD Versionar toda a configuração junto com o código Reduzir erros manuais através de processos padronizados Acelerar o ciclo de desenvolvimento com validações automáticas Como em qualquer nova técnica culinária, existe uma curva de aprendizado inicial. No entanto, o investimento em tempo para dominar o Databricks Asset Bundle compensa rapidamente pelos ganhos em produtividade, qualidade e governança.\nDa próxima vez que você estiver lutando com implantações manuais ou inconsistências entre ambientes, lembre-se: com o kit de chef certo, até mesmo os pratos de dados mais complexos podem ser preparados com precisão e confiança em qualquer cozinha Databricks.\nAté o próximo artigo !\n","permalink":"https://julianamarialop.github.io/articles/o-kit-de-chef-para-dados-como-databricks-asset-bundle/","summary":"Implantar projetos de dados em diferentes ambientes sempre foi um desafio comparável a tentar replicar um prato gourmet em diferentes cozinhas. Mesmo com os mesmos ingredientes, pequenas variações nas configurações, na…","title":"O Kit de Chef para Dados: Como o Databricks Asset Bundle Transforma a Implantação de Projetos"},{"content":"Por anos, engenheiros de dados têm construído pipelines que conectam o Azure Data Factory (ADF) ao Databricks, uma combinação poderosa, mas que frequentemente exigia ajustes manuais e configurações complexas. Era como ter um DeLorean que precisava de constantes calibragens no fluxo capacitor antes de cada viagem no tempo – funcional, mas longe do ideal.\nA Microsoft acaba de anunciar uma atualização que promete revolucionar essa integração: a nova atividade de Databricks Job no ADF. Esta funcionalidade permite orquestrar diretamente qualquer tipo de job do Databricks a partir do Data Factory, eliminando a necessidade de soluções alternativas e simplificando drasticamente a arquitetura de dados. É como se o Doc Brown finalmente tivesse aperfeiçoado o DeLorean, permitindo viagens diretas para qualquer ponto no tempo com apenas um clique.\nPara profissionais de dados, esta atualização representa muito mais que uma simples conveniência técnica. Ela traz potencial para redução significativa de custos, simplificação de arquiteturas, e uma experiência de desenvolvimento mais fluida. Os \u0026ldquo;viajantes do tempo\u0026rdquo; modernos agora podem focar mais na qualidade dos dados e menos nas complexidades de integração entre plataformas.\nO Que Mudou? O Novo DeLorean - A Evolução da Integração ADF-Databricks Antes desta atualização, a integração entre ADF e Databricks era possível, mas limitada. As opções disponíveis incluíam:\nAtividade de Notebook: Executar notebooks individuais, mas sem acesso a todas as funcionalidades do Databricks Chamadas REST API: Implementar código personalizado para acionar jobs, exigindo manutenção constante Soluções híbridas: Combinar diferentes abordagens, aumentando a complexidade Era como dirigir um DeLorean com peças improvisadas – funcionava, mas exigia constante atenção e ajustes.\nA nova atividade de Databricks Job transforma completamente essa realidade. Agora, você pode:\nOrquestrar qualquer tipo de job do Databricks diretamente do ADF Executar workflows completos com múltiplas tarefas em sequência Aproveitar computação serverless para otimização de custos Parametrizar jobs para máxima flexibilidade Monitorar execuções diretamente na interface do ADF O Que Você Pode Executar? O Doc Brown ficaria impressionado com a versatilidade deste novo DeLorean. A atividade de Databricks Job suporta praticamente qualquer operação disponível no Databricks:\nNotebooks: Execução de código Python, Scala, R ou SQL SQL Tasks: Consultas e transformações SQL diretas Delta Live Tables: Pipelines declarativos para processamento de dados Model Serving: Inferência em lote usando endpoints de modelos Power BI: Publicação e atualização automática de modelos semânticos Isso significa que você pode construir pipelines end-to-end que abrangem desde a ingestão de dados brutos até a atualização de dashboards de BI, tudo orquestrado a partir de uma única plataforma.\nPor Que Isso Importa? Viagens no Tempo Sem Paradoxos - Eliminando Paradoxos Temporais Na trilogia \u0026ldquo;De Volta para o Futuro\u0026rdquo;, os paradoxos temporais eram um risco constante que complicava as viagens. Da mesma forma, a integração tradicional entre ADF e Databricks criava seus próprios \u0026ldquo;paradoxos\u0026rdquo;:\nParadoxo da Inicialização: Clusters que demoravam para iniciar entre atividades Paradoxo da Visibilidade: Monitoramento fragmentado entre plataformas Paradoxo da Manutenção: Código personalizado que exigia constante atualização A nova atividade de Job resolve esses paradoxos, criando uma linha temporal mais limpa e eficiente para seus dados.\nImpacto Estratégico Esta atualização não é apenas uma melhoria técnica, mas uma mudança estratégica que afeta diferentes aspectos da engenharia de dados:\nUnificação do Ecossistema Azure: Fortalece a coesão entre serviços Microsoft Simplificação Arquitetural: Reduz a complexidade e a necessidade de conhecimento especializado Democratização de Recursos Avançados: Torna funcionalidades avançadas acessíveis via interface visual Para diferentes perfis profissionais, os benefícios são claros:\n_Benefícios por Perfil_\nEconomia de \u0026ldquo;Plutônio\u0026rdquo; - O Combustível dos Pipelines No universo de \u0026ldquo;De Volta para o Futuro\u0026rdquo;, o plutônio era o combustível caro e difícil de obter que alimentava o DeLorean original. Na versão moderna, o Doc Brown conseguiu substituí-lo por um reator de fusão alimentado por lixo comum – uma solução muito mais eficiente e econômica.\nDe forma similar, a nova atividade de Databricks Job permite substituir o \u0026ldquo;combustível caro\u0026rdquo; (clusters dedicados e código personalizado) por uma alternativa mais eficiente (computação serverless e orquestração nativa).\nCenário Comparativo\nPara demonstrar o impacto financeiro desta mudança, simulamos um cenário comum em empresas de médio porte:\nProcessamento diário de 50GB de dados Pipeline com 4 etapas: ingestão, transformação, agregação e carregamento Execução diária com janela de processamento de 4 horas Ambiente Azure com região East US A simulação revela uma economia surpreendente:\nPipeline Clássico: $1,392.24 por mês Pipeline com Jobs: $473.31 por mês Economia Absoluta: $918.93 por mês Economia Percentual: 66% Fatores que Contribuem para a Economia\nComputação Serverless: Pagamento apenas pelo tempo de processamento efetivo Inicialização Otimizada: Menor overhead entre tarefas no mesmo job Manutenção Reduzida: Interface simplificada e menos código para manter Orquestração Simplificada: Menos atividades no ADF É como se o DeLorean tivesse passado de um motor a plutônio para células solares – mais eficiente, mais barato e melhor para o ambiente (ou neste caso, para o orçamento de TI).\nConstruindo sua Primeira Máquina do Tempo - Guia Prático Configurando a Integração\nVamos ao manual simplificado do Doc Brown para construir seu próprio DeLorean de dados. A configuração da nova atividade de Databricks Job é surpreendentemente simples:\nNo Azure Data Factory Studio: Crie um novo pipeline ou edite um existente Na paleta de atividades, localize a seção Databricks Arraste a atividade \u0026ldquo;Job\u0026rdquo; para o canvas _Nova atividade Databricks Job no ADF_\nConfiguração Básica: Selecione ou crie um serviço vinculado ao Databricks Escolha o workspace e o job que deseja executar Configure parâmetros, se necessário Parâmetros e Monitoramento: Defina parâmetros dinâmicos para passar ao job Configure opções de monitoramento e retry Conecte a atividade a outras etapas do pipeline, se necessário Dicas para Maximizar os Benefícios Para tirar o máximo proveito desta nova funcionalidade, considere estas dicas:\nMigre Gradualmente: Comece convertendo pipelines simples antes de abordar os mais complexos Consolide Tarefas: Agrupe tarefas relacionadas em um único job para reduzir overhead Aproveite o Serverless: Configure seus jobs para usar computação serverless quando possível Parametrize Tudo: Use parâmetros para criar pipelines flexíveis e reutilizáveis Monitore o Desempenho: Compare métricas antes e depois da migração para quantificar os ganhos Considerações Importantes Como qualquer tecnologia, existem algumas limitações a considerar:\nA funcionalidade está em Preview, podendo sofrer alterações Alguns recursos avançados de monitoramento ainda estão em desenvolvimento A economia real depende do perfil específico de carga de trabalho Pipelines existentes precisarão ser redesenhados para aproveitar ao máximo os benefícios Conclusão A nova atividade de Databricks Job no Azure Data Factory representa um salto significativo na evolução da integração entre estas plataformas. Assim como o DeLorean aperfeiçoado no final da trilogia \u0026ldquo;De Volta para o Futuro\u0026rdquo;, esta atualização elimina complexidades desnecessárias e abre novas possibilidades para engenheiros de dados.\nOs benefícios são claros: arquiteturas mais simples, desenvolvimento mais ágil, monitoramento unificado e, talvez o mais impressionante, potencial para economia significativa de custos. Nossa simulação demonstrou que é possível reduzir gastos em até 66% ao migrar de pipelines clássicos para a nova abordagem.\nÀ medida que a Microsoft continua investindo no ecossistema Azure, podemos esperar ainda mais integrações e otimizações entre o Data Factory e o Databricks. O futuro dos pipelines de dados está ao alcance de um simples clique no ADF – não são necessários 1.21 gigawatts ou plutônio raro.\nExperimente a nova funcionalidade hoje mesmo e descubra como ela pode transformar sua jornada de engenharia de dados. Afinal, como diria o Doc Brown: \u0026ldquo;Estradas? Para onde vamos, não precisamos de estradas.\u0026rdquo; E com a nova atividade de Databricks Job, você também não precisará de código personalizado ou integrações complexas.\nAté mais !\n","permalink":"https://julianamarialop.github.io/articles/de-volta-para-o-futuro-dos-pipelines-como-delorean-do/","summary":"Por anos, engenheiros de dados têm construído pipelines que conectam o Azure Data Factory (ADF) ao Databricks , uma combinação poderosa, mas que frequentemente exigia ajustes manuais e configurações complexas. Era como…","title":"De Volta para o Futuro dos Pipelines: Como o DeLorean do Azure Data Factory Agora Viaja Diretamente para o Mundo dos Databricks Jobs"},{"content":"O universo Databricks está em constante expansão. Como uma galáxia viva e pulsante, a cada mês surgem novas \u0026ldquo;constelações\u0026rdquo; de recursos, integrações e aquisições que iluminam o caminho dos profissionais de dados e ampliam os horizontes do que é possível fazer com dados e inteligência artificial.\nMaio de 2025 foi um mês particularmente ativo neste cosmos tecnológico. Testemunhamos o nascimento de várias \u0026ldquo;constelações\u0026rdquo; importantes que estão redefinindo o horizonte da plataforma e criando novas possibilidades para organizações que buscam extrair valor de seus dados. Da aquisição bilionária de uma promissora startup a novas ferramentas para profissionais de marketing, o universo Databricks ganhou novos pontos de luz.\nNeste artigo, vamos explorar as cinco principais \u0026ldquo;constelações\u0026rdquo; que surgiram neste mês, cada uma trazendo seu próprio brilho e influência para o ecossistema Databricks. Prepare-se para uma viagem pelo espaço sideral dos dados, onde cada novidade representa um avanço significativo na missão de democratizar a análise de dados e a inteligência artificial.\nA Supernova Neon (Aquisição da Neon) No coração do universo Databricks, uma supernova acaba de explodir, liberando uma energia transformadora por todo o ecossistema. Em 14 de maio, o Databricks anunciou sua intenção de adquirir a Neon, uma empresa líder em tecnologia serverless Postgres, em um acordo avaliado em aproximadamente US$ 1 bilhão.\nEsta supernova não é apenas impressionante por seu tamanho, mas principalmente pelo poder que adiciona ao universo Databricks. A Neon desenvolveu uma tecnologia de banco de dados PostgreSQL serverless que promete trazer velocidade e flexibilidade para cargas de trabalho de produção. Ao integrar esta tecnologia à sua plataforma, o Databricks fortalece significativamente suas capacidades para desenvolvedores e agentes de IA, permitindo a construção de sistemas de IA mais robustos e eficientes.\nComo toda supernova que reorganiza o espaço ao seu redor, esta aquisição também trará mudanças estruturais. Os 140 funcionários da Neon serão integrados ao Databricks após a conclusão do acordo, prevista para 31 de julho de 2025, ao final do segundo trimestre. Esta fusão de talentos promete acelerar a inovação em torno do PostgreSQL serverless e eliminar silos de dados, criando um ambiente mais unificado para análises e aplicações de IA.\nA Galáxia do Marketing (Data Intelligence for Marketing) Uma nova galáxia acaba de se formar no universo Databricks, com múltiplos sistemas orbitando em harmonia ao redor de um núcleo poderoso. O Data Intelligence for Marketing, lançado em 14 de maio, surge como uma solução unificada que promete revolucionar como as equipes de marketing utilizam dados e IA.\nEsta galáxia brilhante reúne todos os dados de clientes e campanhas em um único lugar, permitindo que profissionais de marketing obtenham uma visão completa de suas iniciativas. Como estrelas interconectadas, os dados fluem e se comunicam, revelando padrões e insights que antes permaneciam ocultos nas sombras dos silos de informação.\nO que torna esta galáxia ainda mais fascinante são suas conexões com outros sistemas. O Data Intelligence for Marketing possui integrações prontas com parceiros como Adobe, Braze e Salesforce, criando um verdadeiro sistema estelar interconectado. Estas integrações permitem que as equipes de marketing melhorem a segmentação, personalizem experiências em tempo real e tomem decisões baseadas em dados concretos, não em intuições. Como uma galáxia que emite luz própria, esta solução ilumina o caminho para experiências de cliente de próxima geração.\nA Ponte Interestelar (Conector Nativo do Azure Databricks no Azure AI Foundry) No vasto universo dos dados, pontes que conectam diferentes regiões são tão valiosas quanto raras. O novo conector nativo do Azure Databricks no Azure AI Foundry surge como uma dessas pontes interestelares, permitindo o fluxo de energia (dados) entre diferentes dimensões do cosmos tecnológico.\nEsta ponte recém-construída conecta especificamente o Databricks AI/BI Genie com o Azure AI Foundry, criando um caminho direto para que os dados fluam entre estes dois poderosos sistemas. Como uma rota cósmica bem planejada, esta conexão permite que as organizações criem agentes de IA com consciência de dados em toda a empresa, sem precisar navegar por rotas complexas ou construir soluções personalizadas.\nOs benefícios desta ponte interestelar são imensos. Organizações podem agora criar experiências de IA mais ricas e contextualizadas, onde os agentes têm acesso direto aos dados corporativos relevantes. Imagine assistentes virtuais que não apenas respondem perguntas genéricas, mas que podem acessar e analisar dados específicos da sua empresa para fornecer insights personalizados e acionáveis. Esta ponte não apenas encurta distâncias – ela cria possibilidades que antes pareciam pertencer apenas ao reino da ficção científica.\nO Sistema Planetário da Automação (Nova Atividade de Databricks Job no Azure Data Factory) Todo universo bem organizado precisa de sistemas planetários onde cada corpo celeste segue sua órbita de forma coordenada e previsível. A nova atividade de Databricks Job no Azure Data Factory, anunciada em 14 de maio, cria exatamente este tipo de sistema para automação de fluxos de dados.\nComo planetas que seguem suas órbitas em perfeita harmonia, o Azure Data Factory agora suporta a orquestração de Databricks Jobs, permitindo que organizações agendem e automatizem fluxos de trabalho do Databricks diretamente da interface familiar do ADF. Esta integração cria um sistema solar de automação onde cada job (planeta) segue seu caminho predeterminado, interagindo com outros elementos do sistema quando necessário.\nA beleza deste sistema planetário está em sua capacidade de unificar diferentes serviços Azure em uma única órbita de automação. Equipes de dados podem agora criar pipelines end-to-end que incorporam processamento Databricks junto com outras atividades do Azure Data Factory, sem precisar alternar entre diferentes interfaces ou criar scripts complexos de integração. Como um astrônomo que finalmente consegue mapear todo um sistema estelar, os engenheiros de dados agora têm visibilidade e controle completos sobre seus fluxos de processamento.\nO Cinturão de Asteroides Evolutivo (Integração Liquibase Pro Extension for Databricks) Entre os planetas maiores de um sistema solar, frequentemente encontramos cinturões de asteroides – coleções de corpos menores que, juntos, desempenham um papel crucial na estabilidade do sistema. A nova integração Liquibase Pro Extension for Databricks surge como um cinturão de asteroides evolutivo, protegendo e organizando o espaço de dados ao seu redor.\nEsta extensão traz o gerenciamento moderno de mudanças para o ambiente Databricks, permitindo que equipes controlem alterações de esquema e dados de forma mais eficiente e segura. Como asteroides que se movem em padrões previsíveis, as mudanças em bancos de dados agora podem ser rastreadas, versionadas e implementadas de maneira controlada, reduzindo riscos e aumentando a confiabilidade.\nPara equipes que trabalham com DevOps e CI/CD, este cinturão de asteroides oferece proteção contra colisões catastróficas (mudanças não planejadas ou conflitantes) e fornece um caminho claro para a evolução contínua dos sistemas de dados. A integração permite que desenvolvedores e engenheiros de dados implementem práticas de \u0026ldquo;database as code\u0026rdquo;, tratando mudanças de esquema com o mesmo rigor e automação que aplicam ao código de aplicação. Como um sistema que se auto-organiza, esta extensão ajuda a manter a ordem mesmo em ambientes de dados complexos e em constante mudança.\nConclusão Ao observarmos estas cinco novas \u0026ldquo;constelações\u0026rdquo; no universo Databricks, fica claro que estamos testemunhando uma expansão significativa nas capacidades e no alcance da plataforma. Da supernova Neon que adiciona poder de banco de dados serverless, à galáxia de marketing que unifica dados de clientes, da ponte interestelar que conecta IA e dados, ao sistema planetário de automação e ao cinturão de asteroides que gerencia mudanças – cada novidade representa um avanço importante no ecossistema.\nJuntas, estas constelações formam uma nova \u0026ldquo;galáxia de possibilidades\u0026rdquo; para profissionais de dados, desenvolvedores e equipes de negócios. Elas refletem a visão do Databricks de criar um universo onde dados e IA trabalham juntos de forma harmoniosa, permitindo que organizações extraiam mais valor de seus ativos de informação e construam aplicações mais inteligentes e eficientes.\nComo exploradores deste universo em expansão, somos convidados a navegar por estas novas constelações, descobrir seus segredos e aproveitar seu poder para impulsionar inovação e crescimento. O cosmos Databricks continua a se expandir, e maio de 2025 certamente ficará marcado como um período de extraordinário crescimento estelar.\nAté a próxima !\n","permalink":"https://julianamarialop.github.io/articles/o-universo-databricks-em-expansao-novas-constelacoes-de/","summary":"O universo Databricks está em constante expansão. Como uma galáxia viva e pulsante, a cada mês surgem novas \u0026ldquo;constelações\u0026rdquo; de recursos, integrações e aquisições que iluminam o caminho dos profissionais de dados e…","title":"O Universo Databricks em Expansão: As Novas Constelações de Maio 2025"},{"content":"Imagine um aeroporto de grande porte, moderno, com áreas VIP, protocolos rigorosos e túneis exclusivos para embarque e desembarque. Agora, imagine que esse aeroporto é o seu workspace no Microsoft Fabric.\nA partir de junho de 2025, o Microsoft Fabric ganha duas funcionalidades de rede ativadas por padrão que trazem justamente esse nível de segurança e controle: Private Links em nível de workspace e Outbound Access Protection. Ambas já disponíveis em modo Preview, e pensadas para proteger seus dados com o mesmo rigor de um terminal internacional.\nPrivate Links: o túnel VIP de entrada Com os novos Private Links, os administradores poderão criar conexões privadas entre suas redes virtuais do Azure e os workspaces do Fabric. Em outras palavras, os dados passam a chegar por um túnel exclusivo, reservado apenas a redes confiáveis.\nÉ como oferecer aos seus passageiros uma entrada separada, sem acesso ao saguão público. Nada de aglomeração ou exposição desnecessária. Você decide quem pode pousar no seu ambiente e bloqueia qualquer outro tipo de acesso externo.\nEssa funcionalidade permite que o workspace funcione isolado da internet pública, o que reduz significativamente os riscos de exposição ou invasões.\nA configuração é simples: vá até \u0026ldquo;Advanced networking\u0026rdquo; e ajuste as regras de entrada no nível de workspace.\nOutbound Access Protection: embarque autorizado apenas com bilhete Assim como os aeroportos controlam rigorosamente quem sai, agora o Fabric também. Com a funcionalidade de Outbound Access Protection, nenhuma conexão de saída será permitida a partir do workspace, a menos que exista um Managed Private Endpoint configurado.\nPense nisso como um controle de embarque. Seus dados só podem sair do terminal se tiverem um bilhete autorizado e registrado. Sem isso, não embarcam.\nEssa medida ajuda a evitar exfiltrações de dados, tanto acidentais quanto intencionais, e garante que apenas caminhos aprovados para fora do ambiente sejam usados. A proteção se estende inclusive a serviços internos do Fabric, como os notebooks Spark.\nPara ativar, basta acessar \u0026ldquo;Workspace settings\u0026rdquo;, ir até \u0026ldquo;Network security\u0026rdquo; e selecionar a opção para bloquear acessos públicos de saída.\nAdministração central: sua torre de controle Todos esses recursos podem ser controlados centralmente pelos administradores de tenant, que agora contam com uma seção dedicada chamada \u0026ldquo;Advanced networking\u0026rdquo; no portal de administração do Fabric.\nDe lá, é possível padronizar as regras de segurança para toda a organização, habilitando ou desabilitando as funcionalidades conforme as políticas internas. Como elas vêm ativas por padrão, os administradores de workspace já podem aplicá-las imediatamente.\nConclusão: um ambiente com padrão internacional de segurança Com essas duas novas funcionalidades, o Fabric deixa de ser apenas uma plataforma de dados para se tornar um ambiente com padrões reais de segurança corporativa.\nControlando tanto a entrada quanto a saída, você transforma seu workspace em um aeroporto VIP: com fluxos protegidos, rastreáveis e sob total controle.\nÉ hora de assumir o comando da torre e garantir que seus dados voem com segurança.\n","permalink":"https://julianamarialop.github.io/articles/seguranca-vip-fabric-seu-workspace-agora-opera-como-um/","summary":"Imagine um aeroporto de grande porte, moderno, com áreas VIP, protocolos rigorosos e túneis exclusivos para embarque e desembarque. Agora, imagine que esse aeroporto é o seu workspace no Microsoft Fabric.","title":"Segurança VIP no Fabric: seu workspace agora opera como um aeroporto internacional"},{"content":"Durante décadas, Tio Patinhas foi o símbolo máximo da riqueza concentrada. Dono de uma fortuna colossal, ele preferia guardar seu dinheiro em um cofre gigante onde podia nadar literalmente em moedas de ouro. Só ele tinha acesso. Só ele tomava as decisões. E ele acreditava firmemente que para proteger sua fortuna, era preciso mantê-la isolada do mundo.\nMas e se Tio Patinhas vivesse em 2025?\nTalvez ele percebesse que seu modelo de guardar tudo para si está ficando ultrapassado. E que, no lugar de um cofre trancado, ele poderia usar a tecnologia para multiplicar valor, criar oportunidades e, ainda assim, manter tudo seguro. É aqui que entra a tokenização de imóveis e uma plataforma de dados poderosa como o Databricks.\nDe dono absoluto para investidor coletivo: o novo jeito de compartilhar patrimônio Tio Patinhas sempre acreditou que imóveis eram uma forma sólida de manter e expandir sua riqueza. E ele não estava errado. Mas até pouco tempo atrás, investir em imóveis era um privilégio restrito a quem tinha muito capital, tempo e tolerância à burocracia.\nCom a tokenização, isso muda completamente.\nA tokenização de imóveis é o processo de transformar um bem físico, como um prédio ou terreno, em pequenas partes digitais chamadas tokens. Cada token representa uma fração real do imóvel e pode ser comprada por qualquer pessoa, com valores a partir de cem reais. É como se Tio Patinhas resolvesse dividir seu cofre em pequenas moedas digitais e permitisse que outras pessoas investissem nelas também — com direito a participação nos lucros.\nUm livro que ninguém pode rasurar: a mágica da blockchain Se Tio Patinhas era obcecado por controle e registros precisos, ele ficaria impressionado com o funcionamento da blockchain. Trata-se de uma espécie de livro de registros digital, público, onde cada transação é registrada de forma criptografada e imutável.\nImagine o velho livro-caixa do Patinhas — onde ele anotava cada centavo com caneta-tinteiro sendo substituído por uma rede de computadores que registra cada movimentação com precisão matemática, sem possibilidade de alteração. É isso que garante a segurança e a confiança na tokenização.\nNão há mais necessidade de confiar em terceiros ou em papelada. A própria tecnologia garante que tudo esteja certo, algo que até o Patinhas, desconfiado como sempre, aprenderia a valorizar.\nQuando investir deixa de ser só para quem tem cofres subterrâneos A grande mudança trazida pela tokenização é a democratização do investimento em imóveis. O mercado, que antes exigia altos valores de entrada, agora permite que pessoas comuns invistam com pouco dinheiro, diversifiquem seus ativos e até recebam renda passiva, como se fossem pequenos Tios Patinhas em formação.\nA ideia de que “ou você tem um imóvel inteiro ou não tem nada” está sendo substituída por um modelo mais acessível, mais digital e muito mais inclusivo.\nO cofre já começou a se abrir: exemplos reais no Brasil Mesmo que o Tio Patinhas estivesse relutante no início, ele não poderia ignorar os resultados de algumas plataformas brasileiras que já estão aplicando essa nova lógica:\nNetspaces: tokeniza imóveis em cidades brasileiras e já lançou projetos com a Housi, permitindo acesso a frações de apartamentos modernos. Ribus: aposta em tokens com governança, onde os investidores têm voz ativa na gestão dos imóveis — algo que o Patinhas, sempre mandando em tudo, talvez levasse um tempo para aceitar. Propriedade Digital: vem abrindo espaço para que novos perfis de investidores participem desse mercado, com segurança e simplicidade. Housi: transforma moradia em serviço e em ativo de investimento fracionado. Essas empresas mostram que o futuro do mercado imobiliário já está em curso e que não é mais preciso herdar uma mina de ouro para começar.\nOs dados que o Patinhas não vê, mas que movimentam fortunas invisíveis Tokenizar um imóvel não é apenas uma questão tecnológica ou jurídica. É também uma questão de dados, muitos dados. Informações sobre localização, mercado, contratos, transações, preferências de investidores e compliance regulatório precisam ser analisadas e processadas em tempo real.\nSe Tio Patinhas sempre contratou contadores para cuidar da papelada, ele hoje precisaria de uma plataforma muito mais robusta para dar conta desse novo volume de informação. É aqui que entra o Databricks.\nQuando o ouro deixa de brilhar e o dado passa a valer mais O Databricks funciona como o cérebro por trás do cofre moderno. Ele reúne, organiza e analisa todos os dados envolvidos na tokenização, e transforma isso em inteligência prática.\nCom ele, é possível:\nEntender o comportamento dos investidores e prever tendências; Avaliar a performance de diferentes imóveis e sugerir quais são mais viáveis para tokenização; Gerar dashboards em tempo real sobre liquidez, risco e rentabilidade; Garantir a rastreabilidade e a governança necessárias para atender às exigências de órgãos como a CVM. Se o cofre de moedas do Patinhas era símbolo de controle absoluto, o Databricks é o novo instrumento de gestão de riqueza só que baseado em dados, aprendizado de máquina e visão preditiva.\nO velho cofre ainda tem valor, mas o novo está em rede No fim das contas, o Tio Patinhas talvez ainda mantenha algumas moedas de lembrança, emolduradas na parede. Mas se quiser continuar crescendo, vai precisar aceitar que abrir o cofre, com segurança, estratégia e inteligência, não é perder valor. É criar novas formas de prosperar.\nE isso só é possível quando se entende que blockchain e tokenização mudam as regras do jogo. E que plataformas como o Databricks permitem jogar com vantagem.\nA pergunta que fica é: você vai esperar o cofre abrir ou já começou a investir na próxima revolução do mercado imobiliário?\n","permalink":"https://julianamarialop.github.io/articles/o-tio-patinhas-esta-mudando-de-ideia-e-isso-tem-tudo-ver/","summary":"Durante décadas, Tio Patinhas foi o símbolo máximo da riqueza concentrada. Dono de uma fortuna colossal, ele preferia guardar seu dinheiro em um cofre gigante onde podia nadar literalmente em moedas de ouro. Só ele…","title":"O Tio Patinhas Está Mudando de Ideia — E Isso Tem Tudo a Ver com Tokenização de Imóveis e Databricks"},{"content":"Quem trabalha com SQL sabe que, apesar de ser uma linguagem poderosa, escrever e entender queries complexas, especialmente aquelas com múltiplas subqueries aninhadas, pode ser um desafio. Muitas vezes, temos a sensação de possuir um grande poder, mas sem o controle total para expressar nossas ideias de forma clara e direta.\nE se houvesse uma forma de transformar essa jornada de construção de queries em um treinamento mais intuitivo, como aprender a dominar os \u0026ldquo;elementos\u0026rdquo; da sua consulta em uma ordem lógica? É exatamente essa a proposta da nova SQL Pipe Syntax no Databricks, uma abordagem que promete simplificar e clarear o caminho para extrair insights dos seus dados.\nPrepare-se para descobrir como essa nova sintaxe pode revolucionar sua relação com o SQL, permitindo que você se torne um verdadeiro \u0026ldquo;Mestre dos Dados\u0026rdquo;, assim como Aang se tornou o Avatar ao dominar os quatro elementos. Vamos embarcar nessa jornada de aprendizado!\nO Mundo Antes do Avatar (O Desafio do SQL Tradicional) No SQL tradicional, a ordem das cláusulas nem sempre acompanha nosso fluxo de pensamento. Começamos pelo SELECT, mas muitas vezes nossa lógica se inicia com as tabelas no FROM. Além disso, para construir lógicas mais elaboradas, frequentemente recorremos a subqueries aninhadas, que podem transformar uma consulta em um pergaminho antigo e de difícil decifração, tornando a leitura e a manutenção um verdadeiro teste de paciência. Era como se precisássemos de um esforço extra para \u0026ldquo;dobrar\u0026rdquo; o SQL à nossa vontade, especialmente em cenários mais complexos.\nA Descoberta do Primeiro Elemento (O FROM como a Base da Dobra) A SQL Pipe Syntax chega para mudar esse paradigma, introduzindo uma construção sequencial e lógica. Aqui, o FROM é o primeiro \u0026ldquo;elemento\u0026rdquo; a ser invocado, a nação fundamental de onde nossa jornada de consulta se inicia, assim como os Nômades do Ar foram o ponto de partida para Aang. Ao começar com FROM sua_tabela, estabelecemos uma base clara e direta para as transformações que virão, tornando o início da query muito mais intuitivo.\nA Jornada de Domínio: Aprendendo a Dobrar os Elementos com \u0026ldquo;|\u0026gt;\u0026rdquo; O grande mestre desta nova jornada é o operador |\u0026gt; (pipe). Ele funciona como o elo que conecta cada etapa do nosso \u0026ldquo;treinamento\u0026rdquo;, permitindo adicionar novos \u0026ldquo;elementos\u0026rdquo; (cláusulas SQL) de forma sequencial e progressiva. Vamos ver como dominar cada elemento:\nDominando a Dobra da Água (Filtrando com |\u0026gt; WHERE) Assim como um Dobrador de Água controla as correntes e remove impurezas, o |\u0026gt; WHERE permite \u0026ldquo;moldar\u0026rdquo; o fluxo dos seus dados. Após definir sua fonte com FROM, você pode usar |\u0026gt; WHERE condicao para filtrar exatamente as informações que não são necessárias, trazendo clareza e precisão ao seu conjunto de dados inicial.\nDominando a Dobra da Terra (Estruturando com |\u0026gt; JOIN) Com a base e os filtros definidos, é hora de construir estruturas sólidas. O |\u0026gt; JOIN permite \u0026ldquo;unir\u0026rdquo; diferentes fontes de dados (tabelas), assim como um Dobrador de Terra move e conecta grandes rochas para criar fundações firmes. Com FROM tabela1 |\u0026gt; JOIN tabela2 ON condicao, você combina informações de maneira lógica e sequencial, enriquecendo sua análise.\nDominando a Dobra do Fogo (Transformando e Agregando com |\u0026gt; GROUP BY e Funções) O poder bruto dos dados precisa ser refinado e transformado em insights. O |\u0026gt; GROUP BY e as funções de agregação (como COUNT, SUM, AVG) permitem \u0026ldquo;transformar\u0026rdquo; e resumir os dados, extraindo energia e conhecimento, da mesma forma que um Dobrador de Fogo controla e direciona a chama. Após as etapas anteriores, você pode aplicar |\u0026gt; GROUP BY coluna |\u0026gt; SELECT coluna, COUNT(*) para agregar e revelar padrões.\nO Elemento Ar Revelado (Selecionando o Essencial com |\u0026gt; SELECT) Finalmente, para dar a forma final à sua consulta, entra o |\u0026gt; SELECT. Diferente do SQL tradicional onde ele inicia a query, na Pipe Syntax, o |\u0026gt; SELECT (usado mais ao final do pipeline ou em pontos estratégicos) define quais colunas e expressões farão parte do resultado final. É como a Dobra do Ar, que traz clareza, precisão e a liberdade de apresentar apenas o essencial, de forma limpa e direta.\nAtingindo o Estado de Avatar (Os Benefícios da SQL Pipe Syntax) Ao dominar esses \u0026ldquo;elementos\u0026rdquo; com a SQL Pipe Syntax, você atinge um novo nível de controle e clareza sobre suas queries, quase como um \u0026ldquo;Estado de Avatar\u0026rdquo; no mundo SQL:\nClareza e Legibilidade: As queries fluem como uma história bem contada, fáceis de acompanhar e entender, como a jornada de Aang. Manutenção Simplificada: Modificar ou adicionar novos \u0026ldquo;elementos\u0026rdquo; (etapas) se torna muito mais fácil, sem o risco de quebrar toda a estrutura complexa de subqueries aninhadas. Escrita Intuitiva: A sintaxe segue o seu pensamento lógico, tornando a escrita de SQL mais natural e menos propensa a erros de ordenação de cláusulas. Menos Confusão com Subqueries: A necessidade de aninhar múltiplas subqueries diminui drasticamente, tornando o código mais limpo. A Harmonia dos Quatro Elementos (Compatibilidade e Exemplos do Mundo Real) Um grande benefício é que a SQL Pipe Syntax é totalmente compatível com o SQL tradicional. Você não precisa reescrever todas as suas queries existentes; elas podem coexistir harmoniosamente, como as quatro nações buscando o equilíbrio. Você pode, inclusive, começar a usar a Pipe Syntax para refatorar partes de queries antigas ou para construir novas consultas de forma incremental.\nImagine uma query tradicional com várias subqueries para calcular vendas por região e produto. Com a Pipe Syntax, essa mesma lógica seria construída passo a passo: comece com a tabela de vendas, filtre por período, junte com produtos, depois com regiões, agrupe e, por fim, selecione os resultados. O \u0026ldquo;antes e depois\u0026rdquo; do seu treinamento como Avatar do SQL seria nítido!\nConclusão A SQL Pipe Syntax no Databricks representa uma evolução significativa na forma como interagimos com nossos dados. Ela nos capacita a construir queries de maneira mais lógica, intuitiva e poderosa, transformando o que antes poderia ser uma tarefa árdua em um processo de \u0026ldquo;dobra\u0026rdquo; de dados mais fluido e eficiente.\nO convite está feito: explore essa nova forma de \u0026ldquo;dobrar\u0026rdquo; o SQL em seus projetos no Databricks. Comece seu treinamento, domine os elementos um a um com o |\u0026gt; e veja como você pode se tornar um verdadeiro \u0026ldquo;Mestre dos Dados\u0026rdquo;. Assim como o Avatar trouxe equilíbrio ao mundo, essa nova sintaxe busca trazer mais equilíbrio, clareza e poder para o seu universo SQL.\n","permalink":"https://julianamarialop.github.io/articles/azure-databricks-sql-pipe-syntax-domine-os-elementos-da/","summary":"Quem trabalha com SQL sabe que, apesar de ser uma linguagem poderosa, escrever e entender queries complexas, especialmente aquelas com múltiplas subqueries aninhadas, pode ser um desafio. Muitas vezes, temos a sensação…","title":"Azure Databricks SQL Pipe Syntax: Domine os Elementos da Query como um Avatar!"},{"content":"Imagine um mundo onde cada personagem de videogame tem uma missão. Ralph detona prédios, Félix conserta tudo com seu martelo mágico, Vanellope corre em pistas malucas, Sonic é super-rápido. Todos vivem em seus próprios jogos, com regras, estilos e habilidades bem diferentes.\nAgora pense: o que aconteceria se todos esses personagens pudessem se comunicar perfeitamente, colaborar em tempo real e resolver problemas juntos mesmo sendo de jogos diferentes?\nEsse é o espírito do A2A (Agent-to-Agent Protocol), uma nova tecnologia que a Microsoft acaba de anunciar para ajudar agentes de inteligência artificial a trabalharem juntos, de forma segura, inteligente e coordenada como se tivessem aprendido o idioma universal dos fliperamas.\nOs Agentes São como os Personagens dos Jogos No mundo digital de Detona Ralph, cada personagem tem uma função clara:\nRalph destrói, Félix conserta, Vanellope corre, Sonic é rápido. Eles têm habilidades únicas, como os agentes de IA no mundo real:\nUm agente busca informações, Outro resume textos, Um terceiro organiza dados, Outro pode corrigir erros (como o Félix!). Antes do A2A, era como se cada personagem falasse uma língua diferente. Ralph falava “quebradês”, Félix falava “consertês” e Vanellope só entendia “corridês”. Mesmo sendo incríveis, eles não conseguiam trabalhar em equipe.\nA2A: Quando Agentes Conversam Como Ralph e Félix Com o A2A, os agentes podem conversar entre si como se fossem personagens de jogos em uma missão conjunta. Veja como isso funciona com um exemplo simples de dois agentes trocando mensagens:\nAgente 1: Verificador de Texto (Ralph)\n\u0026ldquo;Ei, tem uma frase aqui meio quebrada: ‘Nós vai para a escola amanhã.’ Pode dar uma olhada?\u0026rdquo;\nEssa mensagem vira um comando padronizado no formato A2A:\n{ \u0026#34;goal\u0026#34;: \u0026#34;corrigir frase\u0026#34;, \u0026#34;input\u0026#34;: \u0026#34;Nós vai para a escola amanhã.\u0026#34;, \u0026#34;agent\u0026#34;: \u0026#34;CorretorGramatical\u0026#34; } Agente 2: Corretor Gramatical (o Félix da equipe)\n\u0026ldquo;Recebido! Já consertei: ‘Nós vamos para a escola amanhã.’ Missão cumprida!\u0026rdquo;\nE então ele responde com:\n{ \u0026#34;result\u0026#34;: \u0026#34;Nós vamos para a escola amanhã.\u0026#34; } Essa troca pode parecer simples, mas mostra um poder enorme: cada agente entende exatamente o que precisa fazer e responde de forma estruturada. Nenhuma confusão, nenhuma bagunça como se o Ralph quebrasse uma parede e o Félix aparecesse logo atrás, martelo mágico em mãos, consertando tudo com um clique.\nO A2A faz esse fluxo funcionar em sistemas reais, entre agentes que podem estar em máquinas diferentes, programados por equipes diferentes, mas todos falando a mesma \u0026ldquo;língua digital\u0026rdquo;.\nO Anúncio da Microsoft Em 7 de maio de 2025, a Microsoft anunciou oficialmente o lançamento do A2A como um protocolo aberto. Isso significa que qualquer desenvolvedor, empresa ou plataforma poderá usar essa linguagem comum para fazer com que seus agentes se comuniquem entre si — mesmo que tenham sido criados com ferramentas diferentes.\nO A2A será integrado a plataformas como Azure AI Foundry, Copilot Studio e outras ferramentas modernas de IA. E mais: o protocolo está sendo desenvolvido de forma aberta, com apoio da comunidade no GitHub.\nPor Que Isso é Importante? Antes do A2A, os sistemas de IA funcionavam como jogos isolados. Agora:\nAgentes podem trabalhar em equipe, como Ralph, Félix e Vanellope. Desenvolvedores têm liberdade para usar qualquer tecnologia. Empresas criam soluções mais completas, rápidas e integradas. É como montar uma missão com os melhores personagens de cada jogo. Ralph destrói o problema, Félix resolve os bugs, Vanellope acelera o processo e o A2A garante que todos saibam o que fazer e quando agir.\nSegurança, Governança e Diversão Controlada Assim como em Detona Ralph, onde há regras para manter a ordem nos jogos, o A2A também tem seus guardiões digitais:\nComunicação segura (com autenticação e criptografia). Controle de acesso e auditoria. Monitoramento em tempo real. Ninguém entra ou sai da missão sem ser notado. Tudo está sob controle como no fliperama do Sr. Litwak.\nConclusão: O Futuro é um Jogo em Equipe Com o A2A, estamos entrando em uma era onde diferentes inteligências artificiais podem trabalhar juntas como um verdadeiro elenco de um filme animado. Ralph, Félix, Vanellope, Sonic todos cooperando, cada um com sua habilidade, mas agora falando a mesma língua.\nÉ como se o futuro da IA fosse um grande fliperama interconectado e a ficha já caiu: os agentes agora jogam juntos.\nAté o próximo artigo !\nReferências Empowering multi-agent apps with the open Agent2Agent (A2A) protocol: https://www.microsoft.com/en-us/microsoft-cloud/blog/2025/05/07/empowering-multi-agent-apps-with-the-open-agent2agent-a2a-protocol/\n","permalink":"https://julianamarialop.github.io/articles/quando-os-personagens-dos-jogos-aprendem-conversar-o-mundo/","summary":"Imagine um mundo onde cada personagem de videogame tem uma missão. Ralph detona prédios, Félix conserta tudo com seu martelo mágico, Vanellope corre em pistas malucas, Sonic é super-rápido. Todos vivem em seus próprios…","title":"Quando os Personagens dos Jogos Aprendem a Conversar: O Mundo do A2A da Microsoft como em Detona Ralph"},{"content":"Abril chegou e, com ele, o Microsoft Fabric preparou um conjunto de atualizações importantes. Como uma plataforma que busca sempre inovar, o Fabric nos presenteia com uma variedade de \u0026ldquo;pratos\u0026rdquo; novos e aprimorados, pensados para todos os paladares e necessidades no universo dos dados.\nNeste mês, a Microsoft focou em áreas chave, trazendo desde \u0026ldquo;aperitivos\u0026rdquo; que democratizam o acesso à inteligência artificial até \u0026ldquo;pratos principais\u0026rdquo; robustos para cientistas e engenheiros de dados, sem esquecer de \u0026ldquo;acompanhamentos\u0026rdquo; inovadores para inteligência em tempo real e \u0026ldquo;sobremesas\u0026rdquo; que facilitam a integração.\nVamos explorar juntos os destaques deste \u0026ldquo;Buffet de Abril\u0026rdquo; do Fabric e como essas novidades podem enriquecer seus projetos.\nO Couvert da Casa: IA para Todos os Paladares! Todo bom buffet começa com um couvert especial, e em abril, o Fabric reforça um dos seus melhores: o Copilot e as capacidades de IA agora estão disponíveis a partir dos SKUs F2! Isso significa que a inteligência artificial de ponta ficou mais acessível, como um couvert de qualidade que permite a mais clientes experimentarem e potencializarem seus projetos.\nEstação de Pratos Quentes: Sabores Intensos para Data Science e Data Warehouse! Chegamos à estação mais aguardada do nosso buffet, com opções que visam atender às necessidades de performance e inovação.\nPrato 1: Risoto de Cogumelos Selvagens com IA (Data Science Low-code)\nOs cientistas de dados podem se beneficiar das novas ferramentas Low-code de IA nos notebooks e no Data Wrangler (que está em Preview). Esses \u0026ldquo;ingredientes\u0026rdquo; especiais aceleram a produtividade, permitindo aplicar funções de IA e transformar dados com muito menos código. É como um risoto sofisticado que, com um preparo assistido por IA, torna a exploração e o enriquecimento de dados uma experiência mais fluida e intuitiva.\nPrato 2: Picanha Maturada na Brasa com Molho de Eficiência (Data Warehouse GA Features)\nPara os engenheiros de dados que apreciam robustez, o Fabric Warehouse serve uma \u0026ldquo;picanha\u0026rdquo; no ponto: diversas funcionalidades importantes atingiram a Disponibilidade Geral (GA). Comandos como ALTER TABLE DROP COLUMN e sp_rename column, o suporte a tabelas #temp distribuídas para gerenciamento eficiente de resultados intermediários, e as funções OPENROWSET e BULK INSERT para ingestão de dados em massa, facilitam a manutenção, otimização e o carregamento de dados. São ferramentas que buscam garantir performance e satisfação, como uma carne de primeira qualidade bem preparada.\nPrato 3: Suflê Leve de Migração (Migration Assistant for Fabric DW - Preview)\nE para quem planeja trazer seus dados para o Data Warehouse do Fabric, a Microsoft preparou um \u0026ldquo;suflê\u0026rdquo; que promete leveza: o novo assistente de migração (Migration Assistant for Fabric Data Warehouse), ainda em Preview. A promessa é simplificar a jornada de migração, tornando o processo menos intimidador e mais direto, como um suflê que agrada pela sua textura e facilidade de preparo.\nIlha de Acompanhamentos e Saladas Frescas: Inteligência em Tempo Real e Bancos de Dados Revigorados! Nenhum prato principal está completo sem acompanhamentos que realcem o sabor. Nesta ilha, encontramos novidades que trazem frescor e versatilidade.\nAcompanhamento 1: Salada Tropical de Eventos em Tempo Real (Real-Time Intelligence)\nA área de Inteligência em Tempo Real do Fabric recebeu ingredientes que trazem mais agilidade para a análise de dados que não podem esperar. Destaques incluem a integração completa de fontes de dados do Azure Monitor com o KQL Queryset, melhorias na experiência de exploração de dados low-code e um novo conector de clima no Eventstream. É uma verdadeira \u0026ldquo;salada tropical\u0026rdquo;, com componentes que agregam valor pela sua capacidade de capturar e analisar eventos no momento em que acontecem.\nAcompanhamento 2: Batatas Rústicas com Ervas Finas (SQL Database no Fabric)\nO serviço de Banco de Dados SQL no Fabric também foi aprimorado com melhorias: suporte a novas regiões, novidades no billing de backup, um painel de performance para monitoramento, e suporte expandido para Terraform, APIs REST e CLI, além de integrações e suporte a banco de dados de grafo. Essas atualizações tornam o SQL Database no Fabric ainda mais \u0026ldquo;saboroso e versátil\u0026rdquo;, como aquelas batatas rústicas bem preparadas que complementam bem diversos pratos pela sua confiabilidade e robustez.\nA Surpresa do Chef: A Sobremesa Inesperada! Para finalizar, uma sobremesa especial que complementa a refeição.\nSobremesa: Petit Gateau de Conectividade com Recheio de Snowflake (Mirroring para Snowflake com Firewall - Preview)\nA funcionalidade de Mirroring para Snowflake, que já era interessante, agora recebe um \u0026ldquo;recheio\u0026rdquo; especial: suporte para proteção por firewall (em Preview). Isso permite uma integração mais segura e robusta com um dos principais sistemas de dados do mercado, como um petit gateau que combina diferentes texturas e sabores de conectividade segura e eficiente.\nConclusão: Um Banquete para Sair Satisfeito (e Ansioso pelo Próximo!) O buffet de abril do Microsoft Fabric realmente veio com muitas opções para diferentes gostos e necessidades, desde a democratização da IA, passando por ferramentas robustas para engenharia e ciência de dados, até inovações em tempo real e conectividade aprimorada. Cada novidade é um convite para explorar e descobrir como ela pode otimizar e enriquecer o trabalho com dados.\nAgora, o convite está feito: explore esse cardápio, experimente os \u0026ldquo;pratos\u0026rdquo; que mais despertaram seu interesse e veja como eles podem transformar sua rotina, trazendo mais eficiência e insights para seus projetos. O Microsoft Fabric certamente continuará trazendo novidades nos próximos meses.\nAté o próximo artigo !\n","permalink":"https://julianamarialop.github.io/articles/microsoft-fabric-apresenta-o-buffet-completo-de-abril/","summary":"Abril chegou e, com ele, o Microsoft Fabric preparou um conjunto de atualizações importantes. Como uma plataforma que busca sempre inovar, o Fabric nos presenteia com uma variedade de \u0026ldquo;pratos\u0026rdquo; novos e aprimorados…","title":"Microsoft Fabric Apresenta: O Buffet Completo de Abril! Venha Degustar as Novidades!"},{"content":"Quem aí é fã de Monstros S.A.? Lembram como a fábrica inteira dependia da energia dos gritos (e depois das risadas!) das crianças para manter Monstrópolis funcionando? No nosso universo de dados, podemos dizer que o Databricks é um pouco como essa fábrica: uma potência incrível, mas que precisa constantemente de \u0026ldquo;energia\u0026rdquo; – nossos preciosos dados – para gerar insights, treinar modelos de IA e manter tudo rodando.\nSó que, muitas vezes, buscar essa energia em fontes externas cruciais, como o Salesforce (aquele quarto lotado de informações valiosas de vendas e clientes) ou o Workday (o quarto estratégico com todos os dados de RH), parecia uma aventura digna de um filme da Pixar! Exigia viagens complicadas através de APIs misteriosas, enfrentar monstros assustadores (ETLs complexos e frágeis) e, pior ainda, às vezes a \u0026ldquo;energia\u0026rdquo; chegava atrasada ou nem tão \u0026ldquo;pura\u0026rdquo; assim.\nMas e se\u0026hellip; e se existissem portais mágicos? Como aquelas portas da Monstros S.A. que levavam direto para o quarto certo? Portas que pudessem buscar a energia necessária de forma automática, segura, inteligente e trazê-la direto para os tanques de armazenamento da fábrica Databricks? Parece sonho, né? Pois pode beliscar o Mike Wazowski aí do seu lado, porque o Databricks tornou isso realidade com os novos conectores Lakeflow Connect para Salesforce e Workday! São verdadeiros portais mágicos para simplificar a ingestão de dados!\nO Mundo Antes dos Portais: Assustando Manualmente (e com Dificuldade!) Vamos combinar: antes dessas portas super eficientes, a vida do \u0026ldquo;monstro\u0026rdquo; engenheiro de dados não era fácil. Como coletávamos a energia do Salesforce e do Workday? Muitas vezes, era preciso desenhar mapas complexos (scripts customizados), decifrar hieróglifos em APIs que mudavam sem avisar (manutenção constante), ou construir geringonças manuais e frágeis (pipelines de ETL propensos a quebras) para cada \u0026ldquo;quarto\u0026rdquo; de dados.\nEra comum ter que \u0026ldquo;assustar\u0026rdquo; o sistema inteiro (fazer cargas completas) frequentemente, mesmo que só precisássemos da energia nova. Capturar apenas as mudanças (ingestão incremental) era um desafio à parte, quase como tentar pegar uma meia perdida no quarto escuro sem acordar a criança.\nO custo desse \u0026ldquo;susto manual\u0026rdquo; era alto: consumia um tempo precioso dos nossos melhores \u0026ldquo;assustadores\u0026rdquo; (engenheiros de dados), que poderiam estar focados em tarefas mais estratégicas, como analisar a qualidade da energia ou criar novas formas de usá-la (projetos de IA). Além disso, gerava inconsistências e atrasava a chegada da \u0026ldquo;energia\u0026rdquo; fresca para quem mais precisava dela (analistas e cientistas de dados).\nAbrindo os Portais Mágicos: Lakeflow Connect em Ação! Mas agora, a Monstros S.A. dos Dados investiu em tecnologia de ponta! Com o Lakeflow Connect, temos um sistema de portas de última geração. Imagine um corredor infinito com portas coloridas, mas agora com um painel de controle inteligente. Cada porta (conector) é feita sob medida para um \u0026ldquo;mundo\u0026rdquo; específico, como Salesforce ou Workday. Elas são super seguras e incrivelmente inteligentes.\nO Databricks oferece esses conectores gerenciados e otimizados, o que significa que eles cuidam de grande parte da complexidade para nós. Mas como esses portais funcionam na prática?\nSimplicidade na Instalação: Configurar um novo portal é surpreendentemente fácil. Muitas vezes, envolve poucos cliques na interface do Databricks, como escolher a porta certa no painel e fornecer as credenciais de acesso (a chave do quarto!). Adeus, semanas de desenvolvimento de código customizado! Automação Inteligente: Uma vez configurados, os portais \u0026ldquo;abrem e fecham\u0026rdquo; sozinhos. Você pode agendar a coleta de energia (dados) para ocorrer em intervalos regulares, garantindo um fluxo constante para a fábrica. Eficiência Incremental (O Segredo!): Essa é a grande mágica! Os conectores Lakeflow são inteligentes. Eles sabem exatamente qual \u0026ldquo;energia\u0026rdquo; já foi coletada anteriormente (quais registros foram ingeridos) e buscam apenas o que há de novo ou o que foi alterado desde a última visita. Chega de \u0026ldquo;assustar\u0026rdquo; o sistema inteiro toda vez! Isso economiza recursos, acelera o processo e garante que seus dados no Databricks estejam sempre atualizados. Segurança Nível Monstro: As portas são equipadas com os melhores sistemas de segurança de Monstrópolis. A conexão é segura, os dados são transferidos de forma criptografada e você tem controle sobre quais dados (campos, objetos) podem passar pelo portal. Mais Energia, Menos Susto: Os Benefícios dos Portais Lakeflow Com essas portas mágicas em operação, a \u0026ldquo;fábrica\u0026rdquo; Databricks funciona de maneira muito mais eficiente e produtiva. A \u0026ldquo;energia\u0026rdquo; (dados) chega mais rápido, é mais confiável (menos erros manuais) e os \u0026ldquo;monstros\u0026rdquo; (profissionais de dados) podem finalmente tirar o capacete de susto e focar em tarefas mais divertidas e estratégicas, como fazer as crianças rirem (gerar insights valiosos) ou analisar a qualidade da energia coletada (garantir a governança).\nVamos listar os benefícios práticos desse sistema de portais:\nEngenharia de Dados Simplificada: A necessidade de construir e manter pipelines de ingestão complexos para Salesforce e Workday é drasticamente reduzida. Menos código customizado significa menos bugs, menos manutenção e menos noites em claro para os engenheiros. Dados Fresquinhos para Análise e IA: A ingestão incremental garante que seu Data Lakehouse no Databricks esteja sempre sincronizado com os dados mais recentes de vendas, clientes, finanças e RH. Isso é absolutamente crucial para análises em tempo real, dashboards atualizados e modelos de Machine Learning ou IA Generativa que precisam da informação mais recente para serem eficazes. Democratização da Ingestão: A simplicidade dos conectores permite que mais pessoas dentro da organização (e não apenas os engenheiros de dados mais experientes) consigam trazer dados importantes de Salesforce e Workday para o Databricks, acelerando a capacidade de análise de diferentes áreas. Aceleração de Projetos: Ao liberar o tempo dos engenheiros e garantir a disponibilidade rápida de dados confiáveis, os projetos de análise, BI, ML e IA que dependem dessas fontes podem começar mais cedo e entregar valor mais rapidamente. Se fôssemos usar outra metáfora (porque a gente adora!), é como ter um serviço de delivery mágico e inteligente. Você pede os ingredientes (dados) do Salesforce e Workday, e o Lakeflow Connect os entrega na sua \u0026ldquo;cozinha\u0026rdquo; Databricks na hora certa, já picados e prontos para usar (incrementais), sem que você precise ir ao mercado!\nConclusão: Monstrópolis Nunca Foi Tão Energizada! Podemos dizer adeus a boa parte dos sustos e dores de cabeça na hora de integrar dados cruciais do Salesforce e Workday ao nosso Data Lakehouse! Os conectores Lakeflow do Databricks são verdadeiros portais mágicos que vieram para automatizar, simplificar e tornar mais eficiente essa tarefa fundamental da engenharia de dados.\nAo construir essas pontes (ou abrir essas portas!) entre mundos de dados tão importantes, o Databricks se consolida como uma \u0026ldquo;fábrica\u0026rdquo; ainda mais poderosa e centralizadora, pronta para gerar mais \u0026ldquo;risadas\u0026rdquo; – ou seja, insights, inovações e valor de negócio – com dados sempre frescos e confiáveis.\nEssa é mais uma prova clara de como as plataformas de dados modernas estão evoluindo: não basta ser bom em processar e analisar dados, é preciso facilitar (e muito!) a chegada desses dados até a plataforma. O futuro é, sem dúvida, conectado!\nAté o próximo artigo !\n","permalink":"https://julianamarialop.github.io/articles/monstros-sa-chega-de-susto-na-ingestao-databricks-abre/","summary":"Quem aí é fã de Monstros S.A.? Lembram como a fábrica inteira dependia da energia dos gritos (e depois das risadas!) das crianças para manter Monstrópolis funcionando? No nosso universo de dados, podemos dizer que o…","title":"Monstros S.A.: Chega de Susto na Ingestão! Azure Databricks Abre Portais Mágicos para Salesforce e Workday com Lakeflow Connect!"},{"content":"E aí, pessoal da comunidade de dados! Sabe aquela sensação de estar em Gotham City\u0026hellip; digo, na nossa Cidade dos Dados? Ela é vibrante, cheia de oportunidades, mas também repleta de desafios: temos os vilões da complexidade espreitando em cada esquina, as charadas da análise que precisam ser decifradas e, às vezes, até uns pinguins da ineficiência tentando congelar nossos projetos. Para navegar nesse cenário e trazer a ordem (e os insights!), precisamos de heróis – e de tecnologia de ponta!\nNesse universo, o Microsoft Fabric muitas vezes parece o nosso Batman: equipado com os gadgets mais avançados, incluindo o incrível Copilot, quase um cinto de utilidades turbinado com Inteligência Artificial, pronto para qualquer situação. Mas\u0026hellip; e o Robin? Aqueles de nós usando capacidades menores do Fabric (como F2, F4, F8\u0026hellip;), muitas vezes olhávamos para esses gadgets com admiração, sonhando em usá-los na nossa luta diária contra o crime\u0026hellip; quer dizer, contra os desafios dos dados. Era como ver o Batmóvel passar voando, enquanto você ainda estava de bicicleta.\nMas segurem seus capuzes e máscaras! O Comissário Gordon acabou de acionar o Bat-sinal com uma notícia bombástica direto da Microsoft: O Batman decidiu que era hora de compartilhar a tecnologia! O Copilot no Microsoft Fabric agora está acessível para todos os heróis que possuem capacidades pagas a partir do SKU F2! Sim, você leu certo!\nNeste artigo, vamos mergulhar fundo nesse \u0026ldquo;upgrade\u0026rdquo; do nosso querido sidekick. Quais \u0026ldquo;gadgets\u0026rdquo; do Copilot o Robin (ou seja, você com seu F2!) pode usar agora? Como isso muda o jogo na nossa batalha por justiça\u0026hellip; e por insights mais rápidos e inteligentes? Ajuste sua capa, a aventura está só começando!\nOs Dias de Glória (Exclusiva) do Cinto de Utilidades do Batman Vamos ser sinceros: até pouco tempo atrás, o Copilot no Fabric era como aqueles brinquedos super exclusivos da Wayne Enterprises. Pense no Bat-rangue sônico que só o Batman tinha, ou naquele decodificador universal capaz de abrir qualquer cofre em Gotham. Eram ferramentas incríveis, revolucionárias, mas o acesso era restrito à Bat-caverna principal – ou seja, para usar o Copilot e outros recursos avançados de IA no Fabric, era necessário ter uma capacidade computacional parruda, geralmente um SKU F64 ou superior (ou um P1+).\nQual era o impacto disso na prática? Significava que muitas equipes menores, startups ou empresas com orçamentos mais controlados – os Robins, Batgirls e todos os heróis em treinamento na Cidade dos Dados – ficavam um pouco de fora da festa da IA generativa dentro do Fabric. Era como querer usar a inteligência artificial para prever o próximo movimento do Coringa, mas só ter acesso a um walkie-talkie antigo.\n\u0026ldquo;Santo Upgrade, Batman!\u0026rdquo; - O Robin Entra no Jogo! Mas eis que surge a reviravolta digna de uma história em quadrinhos! O Batman (ou a Microsoft, nesse caso) percebeu que para combater o crime de forma eficaz em toda a cidade, o Robin precisava de mais poder de fogo. E que poder!\nA grande mudança, anunciada recentemente e que já está valendo, é que o requisito mínimo para usar o Copilot no Microsoft Fabric foi drasticamente reduzido. Agora, qualquer pessoa com uma capacidade paga F2 ou superior (ou P1 e acima) pode acionar seu próprio assistente de IA!\nMas quais \u0026ldquo;gadgets\u0026rdquo; exatamente estão neste novo kit do Robin? A boa notícia é que o acesso parece ser amplo! Usuários com SKUs F2 agora podem chamar o Copilot para ajudar em diversas áreas do Fabric:\nPower BI: Precisa criar um relatório do zero ou escrever aquela medida DAX complexa? O Copilot está lá, como um comunicador direto com a sabedoria da Bat-caverna, pronto para dar sugestões. Data Factory: Desenhar pipelines de dados pode ser um labirinto. O Copilot age como um Bat-rangue guiado por IA, ajudando a construir e otimizar seus fluxos. Data Engineering/Science (Notebooks): Escrevendo código Python ou SQL nos notebooks? O Copilot funciona como um mini decodificador, ajudando a gerar, explicar e corrigir seu código. Data Warehouse: Precisa otimizar consultas ou entender esquemas complexos? O Copilot está pronto para analisar a situação. É como se o Robin finalmente recebesse seu próprio conjunto de ferramentas essenciais, diretamente do cinto de utilidades do mentor!\nO Impacto do Upgrade: O que o Robin Pode Fazer Agora? Essa mudança é muito mais do que apenas dar brinquedos novos ao ajudante. Com esses gadgets do Copilot em mãos, o Robin se torna um herói muito mais completo e eficaz na Cidade dos Dados!\nO ponto central aqui é a Democratização da IA. Ferramentas de IA generativa, que antes pareciam distantes para muitos, agora estão ao alcance de um clique para uma base muito maior de usuários do Fabric. Pense nos benefícios práticos:\nProdutividade Acelerada: Analistas podem criar relatórios mais rápido, engenheiros podem desenvolver pipelines com menos esforço, cientistas de dados podem explorar e codificar de forma mais eficiente. O Copilot atua como um par programador incansável, um assistente que automatiza tarefas repetitivas e sugere soluções inteligentes. Aprendizado Contínuo: O Copilot não é só um executor, é um mentor virtual! Ele pode explicar código complexo, ensinar novas funções DAX, ou mostrar como otimizar uma consulta SQL. É como ter o Alfred ou o próprio Batman explicando os truques do ofício. Inovação Desbloqueada: Pequenas empresas ou equipes com orçamentos limitados agora podem experimentar o poder da IA generativa em seus projetos de dados sem precisar fazer um investimento inicial massivo em capacidade. Isso abre portas para novas ideias e soluções que antes eram inviáveis. Se fôssemos usar uma das minhas metáforas de comida favoritas, diria que é como se a \u0026ldquo;receita secreta\u0026rdquo; do Bat-bolo (IA de ponta) agora viesse com um modo de preparo super simplificado e ingredientes que você encontra na despensa (seu SKU F2). Até o Robin (ou o Alfred!) consegue fazer um bolo delicioso agora!\nO Sidekick Ainda é um Sidekick? (Uma Breve Nota Sobre Potência) É importante ter os pés no chão (ou as botas no telhado, se preferir). O Robin ganhou acesso aos gadgets, e isso é fantástico! Mas ele ainda não tem a mesma força bruta ou os recursos ilimitados do Batman. A performance desses gadgets pode, sim, depender da potência do \u0026ldquo;cinto\u0026rdquo; que você está usando (o tamanho do seu SKU Fabric).\nNa prática, isso significa que, embora o Copilot funcione em um F2, a velocidade de resposta para tarefas muito complexas ou o processamento de grandes volumes de dados pode ser mais lenta comparada a um F64. Pense que o Bat-rangue do Robin pode não ter o mesmo alcance ou poder de impacto que o do Batman. Mas o ponto crucial, que vale repetir, é: o acesso está lá! A funcionalidade está disponível, pronta para ser usada e explorada.\nConclusão: Uma Nova Era para os Heróis dos Dados! Essa notícia é, sem dúvida, um marco! O Copilot no Fabric, que começou como um privilégio dos \u0026ldquo;Batmans\u0026rdquo; com grandes capacidades, agora está equipando também os \u0026ldquo;Robins\u0026rdquo; a partir do SKU F2. É um passo gigantesco na missão de democratizar a Inteligência Artificial, colocando ferramentas verdadeiramente poderosas nas mãos de mais profissionais de dados, independentemente do tamanho da sua Bat-caverna.\nIsso não apenas aumenta a produtividade individual, mas empodera equipes inteiras a inovar e extrair mais valor dos seus dados. A luta contra a complexidade e a lentidão na Cidade dos Dados ficou um pouco mais justa!\nO que mais podemos esperar? Que outros \u0026ldquo;gadgets\u0026rdquo; serão compartilhados no futuro? Uma coisa é certa: o universo da tecnologia de dados continua evoluindo em velocidade de Batmóvel!\nReferências:\nAnúncio no Resumo de Features de Abril/2025: [https://blog.fabric.microsoft.com/en-US/blog/fabric-april-2025-feature-summary/](https://blog.fabric.microsoft.com/en-US/blog/fabric-april-2025-feature-summary/)\nVisão Geral do Copilot no Fabric (Documentação): [https://learn.microsoft.com/en-us/fabric/fundamentals/copilot-fabric-overview](https://learn.microsoft.com/en-us/fabric/fundamentals/copilot-fabric-overview)\nFAQ do Copilot no Fabric: [https://learn.microsoft.com/en-us/fabric/fundamentals/copilot-faq-fabric](https://learn.microsoft.com/en-us/fabric/fundamentals/copilot-faq-fabric)\n","permalink":"https://julianamarialop.github.io/articles/santo-upgrade-batman-o-robin-seu-sku-f2-agora-tem-acesso/","summary":"E aí, pessoal da comunidade de dados! Sabe aquela sensação de estar em Gotham City\u0026hellip; digo, na nossa Cidade dos Dados? Ela é vibrante, cheia de oportunidades, mas também repleta de desafios: temos os vilões da…","title":"Santo Upgrade, Batman! O Robin (Seu SKU F2) Agora Tem Acesso aos Gadgets do Copilot no Fabric!"},{"content":"Estava aqui pensando em como explicar o Estimador de SKU do Microsoft Fabric de uma forma simples, e me veio à cabeça a arte milenar do churrasco. Sim, porque quem já organizou um churrasco sabe que existe uma linha muito tênue entre o sucesso absoluto e a catástrofe da picanha faltando.\nE, assim como no churrasco, no mundo dos dados também é preciso saber calcular direitinho para que tudo funcione como esperado sem sobrar demais, nem faltar na hora H.\nPrimeiro, o desafio: quanto comprar? Organizar um churrasco envolve várias variáveis:\nQuantas pessoas vêm? Tem vegetarianos no grupo? Quanto tempo vai durar o evento? Vai ter acompanhamentos? Cerveja? Na estimativa de recursos no Microsoft Fabric, acontece a mesma coisa:\nQual o volume de dados? Com que frequência esses dados são acessados? Os relatórios precisam ser rápidos ou podem levar alguns minutos? Vai ter pico de uso? O Estimador de SKU do Microsoft Fabric entra aí como aquele amigo planilheiro do churrasco, que calcula exatamente quanto de cada coisa você precisa.\nO erro do churrasqueiro iniciante: ir no olho Você já viu gente comprando 2kg de carne por pessoa? Ou pior, comprando só linguiça achando que “dá pra todo mundo”? Pois é.\nSem o estimador, você corre o risco de:\nEscolher um SKU superdimensionado (carne sobrando e geladeira entupida por dias). Ou subdimensionar (a galera indo embora com fome, ou no mundo dos dados, o sistema travando com excesso de uso). O Estimador de SKU te ajuda a simular diferentes cenários com base nas suas \u0026ldquo;convidadas\u0026rdquo; (cargas de trabalho), sugerindo o SKU ideal que equilibra desempenho e custo.\nUsando o estimador: como se fosse uma calculadora de churrasco O processo é bem parecido com quando você joga no Google: “quantos quilos de carne por pessoa?”. Só que aqui, você vai informar:\nTipo de uso (ingestão, transformação, visualização, etc.) Número de usuários simultâneos Frequência e volume das cargas de trabalho Com isso, ele te diz: “vai com esse SKU aqui que tá ótimo!” Nem sobra, nem falta — e o churrasco dos dados acontece lindamente.\nCenário 1 – O churrascão da Contoso: Análise pronta para IA Pensa num churrasco corporativo de fábrica. A Contoso Manufacturing chamou um integrador de sistemas porque a churrasqueira deles (ou melhor, a arquitetura analítica) já estava defasada.\nA solução atual que precisa ser modernizada tem as seguintes métricas de alto nível:\n50 sistemas de origem processados ​em lote duas vezes por dia 1500 entidades e tabelas fazem parte dos pipelines ETL Estima-se que 50 TB de dados serão armazenados na plataforma nos próximos cinco anos As operações da plataforma contêm 4.000 sensores IoT fornecendo telemetria a cada 10 segundos com um tamanho médio de mensagem de telemetria de 600 bytes Existem 10.000 trabalhadores de fábrica com eventos diários de registro de ponto para início/fim de turno e intervalo/fora de intervalo, gerando 8 pontos de dados por trabalhador por dia Estima-se que 1.300 usuários de painéis e relatórios do Power BI por dia 150 autores de relatórios do Power BI Um tamanho máximo estimado do modelo semântico de 25 GB Após algumas descobertas e workshops de design, o integrador de sistemas criou a seguinte arquitetura de alto nível:\nÉ tipo planejar um evento com 5 buffets, churrasqueiros diferentes e vigilância sanitária digital. O arquiteto usou o Estimador de SKU para calcular tudo isso, selecionando as cargas de trabalho: Spark, Power BI, RealTime Intelligence, Eventstream, Eventhouse e Data Activator.\nPara simplificar essa tarefa, vamos utilizar o Estimador de SKU do Microsoft Fabric.\nPara começar, primeiro é preciso extrair as entradas de alto nível necessárias e as entradas específicas da carga de trabalho com base nas métricas de alto nível acima.\nCalcula-se que o total de dados na arquitetura será de aproximadamente 8533 GB com base em uma taxa de compressão estimada de 6:1. Também deduz-se que a plataforma terá 2 ciclos de lote processando 1.500 tabelas e conjuntos de dados em todos os 50 sistemas de origem. Inserindo essas informações no Estimador de SKU, conforme mostrado abaixo:\nEm seguida, vamos selecionar todas as cargas de trabalho que precisam ser incluídas na estimativa. Seis cargas de trabalho são identificadas: Data Factory, Spark, Eventstream, RealTime Intelligence, Power BI e Data Activator.\nAgora precisamos concluir as entradas específicas da carga de trabalho. Na seção Data Factory, ele insere 0, pois a solução não inclui o Dataflow Gen2:\nNa seção Power BI, insere-se os números de acordo com as métricas de alto nível:\nPara o Eventstream, extrapola-se os números de telemetria para um tamanho de ingestão diária. Vamos fazer isso usando o seguinte cálculo: (Sensores * eventos por dia) * tamanho da mensagem do evento, o que lhe dá um total de ~19 GB.\nEm seguida, insere-se o número de fluxos de eventos como 1 e o número total de destinos como 5. Esse número representa o número de tópicos que compõem os dados do sensor. Para conectores de origem do fluxo de eventos, ele insere 0, pois todos os eventos são coletados de um Azure EventHub e não precisam ser contados.\nNa seção Eventhouse, estima-se que o número de dados de telemetria diária será de 75% dos dados do fluxo de eventos, então estima-se que em 14 GB, a retenção de dados ativos é definida para 30 dias e a retenção total é definida para 90 dias, já que as plataformas operam 24×7, ele entra em um ciclo de trabalho de 24 horas.\nQuando se trata do Data Activator, inserimos os 80.000 eventos estimados e insere 5 para o número de regras de alerta, pois há 5 notificações operacionais que as plataformas precisam notificar sobre o IE: turnos excessivos, baixa capacidade do operador, capacidade excessiva da força de trabalho e outras notificações proativas.\nUma vez concluído, clicar no botão \u0026ldquo;Calcular\u0026rdquo; e receba uma estimativa de SKU viável com detalhamento da carga de trabalho. Também recebemos uma estimativa do consumo de armazenamento e da quantidade de licenças do Power BI Pro que podem ser necessárias.\nNo fim, o estimador entregou a quantidade ideal de recursos, armazenamento e licenças necessárias. Tudo balanceado. Nem linguiça sobrando, nem churrasqueiro suando em vão.\nMoral da história: antes de comprar carvão, use o Estimador Assim como planejar o churrasco perfeito evita dor de cabeça, usar o Estimador de SKU evita que você desperdice dinheiro com recurso demais ou que falte capacidade em momentos críticos.\nO Estimador de SKU do Microsoft Fabric permite:\nSimular diferentes volumes e tipos de uso; Calcular o melhor SKU (o corte ideal para o seu evento); Estimar custos e licenças; E claro, garantir que sua estrutura aguente o tranco sem desperdiçar recursos. 💡 Quer testar? Acesse o Estimador de SKU do Microsoft Fabric e evite que falte carne (ou performance) no seu churrasco de dados.\nSe gostou da analogia, compartilha com aquele amigo que sempre exagera na picanha ou no tamanho do cluster 😄. Até a próxima !\n","permalink":"https://julianamarialop.github.io/articles/calculando-o-churrasco-perfeito-como-estimador-de-sku/","summary":"Estava aqui pensando em como explicar o Estimador de SKU do Microsoft Fabric de uma forma simples, e me veio à cabeça a arte milenar do churrasco. Sim, porque quem já organizou um churrasco sabe que existe uma linha…","title":"Calculando o Churrasco Perfeito: Como o Estimador de SKU do Microsoft Fabric te ajuda a não errar na mão"},{"content":"Outro dia, enquanto pensava em um novo artigo para compartilhar aqui no LinkedIn, me peguei refletindo sobre como é difícil explicar o que fazemos com dados e tecnologia para uma criança — ou até mesmo para um parente mais velho. Quem trabalha com TI, especialmente na área de dados, já passou por aquela situação no almoço de família: “Mas o que exatamente você faz mesmo?” Tentamos explicar com termos como “plataforma de dados”, “pipelines”, “inteligência artificial” e vemos os olhos do outro lado da mesa vagando, procurando um assunto mais fácil como a novela ou o futebol.\nFoi então que me veio uma ideia: e se eu explicasse tudo isso de forma simples e divertida, usando algo que todo mundo entende? Me veio imediatamente à cabeça o quarto do Andy, do clássico Toy Story. E, pensando bem, ele é uma metáfora perfeita para o universo de dados de uma empresa.\nEra uma vez\u0026hellip; o quarto do Andy (ou um ambiente de dados desorganizado) Imagine que a sua empresa é como o quarto do Andy. Lá dentro há todo tipo de brinquedo — uns novos, outros velhos, alguns organizados, outros completamente perdidos embaixo da cama. Esses brinquedos são os dados: planilhas antigas, sistemas legados, arquivos gigantes, bases em nuvem e relatórios espalhados por diferentes ferramentas. O time de dados até quer “brincar” com eles, ou melhor, trabalhar, mas a bagunça é tanta que mais tempo é gasto tentando entender onde estão as coisas do que gerando valor de fato.\nNesse cenário caótico, entra o nosso herói: o Microsoft Fabric . Ele é como o Woody, o xerife confiável que chega com um plano e uma equipe para ajudar. A missão? Organizar o quarto, integrar os brinquedos e garantir que todo mundo possa brincar junto, sem perder tempo ou pisar em peças de Lego escondidas.\nQuando os dados estão espalhados e desorganizados, até a brincadeira mais divertida vira frustração.\nVamos organizar essa brincadeira! O Microsoft Fabric chega com uma proposta clara: transformar aquele amontoado de dados em um ambiente integrado e eficiente, chamado Data Lakehouse. Diferente de soluções antigas, onde dados precisavam estar separados entre “organizados” (data warehouse) e “bagunçados” (data lake), o lakehouse permite que tudo conviva junto de forma inteligente.\nMas o melhor de tudo é que o Fabric não vem sozinho. Ele traz um verdadeiro esquadrão de brinquedos prontos para a ação — cada um com seu papel na brincadeira:\nSr. Cabeça de Batata (Data Factory): Ele é o responsável por trazer os dados de fora para dentro do quarto. Conecta com planilhas, APIs, bancos de dados, sistemas antigos\u0026hellip; e entrega tudo organizado no lakehouse, pronto para ser usado. Buzz Lightyear (Spark \u0026amp; Notebooks): O herói das análises! Ele transforma dados brutos em insights voando alto. Com ele, você pode aplicar lógica, criar transformações e até treinar modelos com performance e escalabilidade. Barbie Analista (Power BI): Cheia de estilo e muito eficiente, ela cria dashboards lindos, interativos e acessíveis. Deixa os relatórios prontos para qualquer pessoa entender até quem não conhece nada de dados. Rex (OneLake): Pode parecer atrapalhado, mas é ele quem sabe exatamente onde está cada dado. Com o OneLake, tudo fica centralizado, sem duplicações, com segurança e governança — pronto para ser compartilhado com toda a empresa. Copilot (IA do Fabric): O brinquedo mais novo e inteligente do time. Você fala com ele em linguagem natural, e ele entrega relatórios, análises e até sugestões prontas. Um verdadeiro assistente pessoal com superpoderes de IA. _Personagens Toy Story_\nCom os brinquedos certos e um bom plano, até o caos mais confuso vira um ambiente pronto para criar grandes aventuras.\nA mágica acontece\u0026hellip; Com tudo isso funcionando em harmonia, o caos do quarto se transforma. Os dados agora estão todos em um único lugar, limpos, organizados, acessíveis e prontos para serem usados. As equipes conseguem montar relatórios em minutos, entender o que está acontecendo na empresa com muito mais clareza e até prever o futuro com base em dados reais. O tempo que antes era gasto procurando informação ou lidando com sistemas desconectados agora é usado para tomar decisões mais inteligentes e rápidas.\nMais do que isso, o Microsoft Fabric permite que diferentes áreas da empresa colaborem. O time de marketing consegue cruzar dados com vendas, o financeiro entende melhor os custos, o atendimento visualiza padrões de comportamento. Tudo isso com segurança, governança e rastreabilidade sem abrir mão da agilidade.\nDados acessíveis e conectados não são só mais rápidos eles tornam a empresa mais inteligente.\nE o que o Microsoft Fabric entrega, de um jeito divertido? Com o Fabric, o quarto do Andy deixa de ser um campo minado de brinquedos perdidos e se transforma em um verdadeiro parque de diversões dos dados. O ambiente fica organizado, nada mais de pisar em Lego no meio da madrugada, e todos os brinquedos trabalham juntos, sem precisar de caixas separadas. Cabe brinquedo novo sempre que for preciso, e cada um tem seu cantinho seguro. Além disso, com o Copilot, você tem um assistente inteligente que entende o que você quer e entrega tudo prontinho, sem esforço.\nÉ uma nova forma de lidar com dados: mais leve, mais integrada e muito mais eficiente. E o melhor de tudo: tudo isso em um único lugar, sem precisar empilhar ferramentas diferentes ou viver trocando de janela. O Microsoft Fabric transforma o caos em clareza e a bagunça em valor.\nCom o Fabric, dados deixam de ser um peso e viram parte da diversão.\nMoral da história Se a sua empresa ainda vive aquela bagunça de dados espalhados para todos os lados, como brinquedos largados no chão depois de uma tarde de brincadeiras, talvez esteja na hora de conhecer o Microsoft Fabric. Com ele, você tem tudo em um só lugar, os dados deixam de ser um problema e passam a ser parte da solução.\nO Fabric organiza, integra, protege e ainda traz inteligência para transformar informações em decisões. Quando tudo funciona junto, com segurança e agilidade, a brincadeira flui melhor e o resultado aparece para todo mundo.\nPorque no fim das contas, quando os dados estão organizados, a empresa trabalha com mais leveza, mais estratégia e mais impacto.\nAo infinito e além\u0026hellip; da confusão dos dados.\nAté o próximo artigo.\n","permalink":"https://julianamarialop.github.io/articles/ao-infinito-e-alem-dos-dados-explicando-microsoft-fabric/","summary":"Outro dia, enquanto pensava em um novo artigo para compartilhar aqui no LinkedIn, me peguei refletindo sobre como é difícil explicar o que fazemos com dados e tecnologia para uma criança — ou até mesmo para um parente…","title":"Ao infinito e além... dos dados! Explicando Microsoft Fabric para uma criança"},{"content":"Migrar uma plataforma consolidada como o SAS pode parecer um desafio complexo. Mas, assim como preparar uma irresistível Banoffee, se seguirmos o passo a passo com calma e método, o resultado será delicioso! Inspirado em um artigo anterior em que demonstrei uma migração do SAS para Azure Databricks usando uma receita de bolo, hoje quero apresentar uma nova e aprimorada receita: Migrar do SAS para Microsoft Fabric em apenas 2 camadas.\nNeste artigo, vou detalhar cada camada de forma simples e prática, para que você consiga implementar com tranquilidade na sua empresa. E, claro, teremos um toque final que fará toda a diferença!\nVamos começar?\nIngredientes necessários para essa migração Antes de colocar a mão na massa, confira se você tem todos os ingredientes certos:\n🗂️ Entendimento do Ambiente Atual: Mapeamento completo das tabelas SAS: Identificação dos projetos existentes: 🛠️ Ferramentas Adequadas: Plataforma Microsoft Fabric: Fabric Copilot (Assistente IA para conversão automática dos scripts SAS). 👩‍💻 Equipe preparada: Arquiteto(a) de Soluções (Definir estratégia). Engenheiros(as) e Analistas de Dados (Execução técnica). Cientistas de Dados (Garantir a qualidade das análises após a migração). 🥧 Camada 1 – Migração dos dados (A base crocante da Banoffee) Na Banoffee, começamos sempre pela base, aquela camada firme de biscoitos que sustentará todas as outras camadas deliciosas que vêm acima. Da mesma forma, ao migrar do SAS para Microsoft Fabric , é fundamental começar garantindo uma base sólida e segura: seus dados.\nPassos detalhados para migração dos dados: 1. Levantamento e documentação das tabelas SAS:\nFaça um inventário das tabelas existentes no SAS. Documente metadados essenciais como nome, formato, esquema, volumetria e frequência de atualização. Este levantamento é a base para uma migração organizada. 2. Configuração do Lakehouse no Fabric:\nCrie um Lakehouse dentro do Microsoft Fabric utilizando o OneLake como repositório centralizado. Defina áreas para receber os dados brutos (bronze) e refinados (silver/gold). 3. Configuração da automação via pipelines:\nNo Microsoft Fabric, utilize os pipelines para automatizar o processo de extração e carga (ETL). Configure conexões diretas entre seu ambiente SAS e o Lakehouse, permitindo uma migração rápida e segura. 4. Execução e monitoramento da migração:\nUtilize o pipeline criado para carregar automaticamente as tabelas SAS no formato Delta Lake. Acompanhe a execução através do monitoramento integrado do Fabric, identificando e corrigindo eventuais falhas rapidamente. 5. Validação da integridade dos dados migrados:\nRealize testes comparativos para garantir que todas as tabelas migradas sejam idênticas às originais em termos de conteúdo e estrutura. Utilize ferramentas analíticas do Fabric para validar consistência e integridade. 🍯🍌 Camada 2 – Migração dos projetos SAS (Caramelo e bananas) Após termos uma base sólida de dados, chegou a hora de rechear nossa Banoffee: transformar os scripts e projetos SAS existentes para funcionarem dentro do Microsoft Fabric. Essa camada representa o coração da migração, trazendo a verdadeira inteligência analítica para sua nova plataforma.\nPassos detalhados para migração dos projetos: 1. Inventário e priorização dos projetos SAS:\nDocumente detalhadamente todos os scripts SAS atualmente em uso. Classifique-os por relevância para o negócio e complexidade técnica. Priorize a migração começando pelos scripts mais importantes e críticos para a operação. 2. Conversão automática com o Fabric Copilot:\nUtilize o Fabric Copilot para automatizar a conversão dos códigos SAS em notebooks Spark (PySpark ou SQL). Copie e cole o código original no Fabric Copilot e peça que ele gere a conversão inicial automaticamente. Exemplo prático do uso do Fabric Copilot:\n/* Exemplo original de código SAS */ PROC SQL; CREATE TABLE clientes_vip AS SELECT id, nome, SUM(compras) AS total FROM vendas WHERE compras \u0026gt; 1000 GROUP BY id, nome; QUIT; O Fabric Copilot transforma automaticamente em um notebook Spark equivalente:\n# Código convertido automaticamente pelo Fabric Copilot clientes_vip = spark.sql(\u0026#34;\u0026#34;\u0026#34; SELECT id, nome, SUM(compras) AS total FROM vendas WHERE compras \u0026gt; 1000 GROUP BY id, nome \u0026#34;\u0026#34;\u0026#34;) clientes_vip.write.format(\u0026#34;delta\u0026#34;).save(\u0026#34;Tables/clientes_vip\u0026#34;) 3. Revisão e ajustes finais:\nRevise os códigos convertidos, garantindo que os resultados estejam coerentes. Faça pequenas adaptações necessárias conforme a especificidade dos processos originais. 4. Teste e validação final dos processos:\nRode cada projeto migrado em paralelo com os originais do SAS, validando resultados e performance. Garanta que os resultados obtidos são exatamente os esperados. 🍦 Toque final – Chantilly especial: um notebook pronto para sua migração! Para finalizar essa receita, nada melhor do que um chantilly especial que torna tudo ainda mais gostoso e fácil. Preparei um notebook parametrizável que você pode copiar diretamente para seu ambiente Microsoft Fabric, facilitando muito sua jornada:\n# Parâmetros iniciais – Defina seu diretório e Lakehouse sas_file_dir = \u0026#34;/Lakehouse/SASFiles/\u0026#34; destino_delta = \u0026#34;Tables/\u0026#34; # Função para carregar arquivos SAS diretamente para Delta Lake def migrar_tabelas_sas(sas_file_path, table_name): df = spark.read.format(\u0026#34;com.github.saurfang.sas.spark\u0026#34;).load(sas_file_path) delta_path = f\u0026#34;{destino_delta}{table_name}\u0026#34; df.write.format(\u0026#34;delta\u0026#34;).mode(\u0026#34;overwrite\u0026#34;).save(delta_path) print(f\u0026#34;✅ Tabela \u0026#39;{table_name}\u0026#39; migrada com sucesso para \u0026#39;{delta_path}\u0026#39;\u0026#34;) # Automatize a migração de todos os arquivos no diretório files = mssparkutils.fs.ls(sas_file_dir) sas_files = [f.path for f in files if f.name.endswith(\u0026#34;.sas7bdat\u0026#34;)] for sas_file in sas_files: nome_tabela = sas_file.split(\u0026#34;/\u0026#34;)[-1].replace(\u0026#34;.sas7bdat\u0026#34;, \u0026#34;\u0026#34;) migrar_tabelas_sas(sas_file, nome_tabela) Lembre-se: uma migração de sucesso, assim como uma deliciosa Banoffee, depende de um bom planejamento, paciência e, claro, bons ingredientes!\nE você, já teve experiência com o Fabric? Enfrentou desafios doces ou amargos na migração? Compartilhe sua experiência nos comentários! Vamos saborear juntos essas histórias.\nAté a próxima !\n","permalink":"https://julianamarialop.github.io/articles/como-migrar-do-sas-para-microsoft-fabric-uma-receita-de/","summary":"Migrar uma plataforma consolidada como o SAS pode parecer um desafio complexo. Mas, assim como preparar uma irresistível Banoffee, se seguirmos o passo a passo com calma e método, o resultado será delicioso! Inspirado…","title":"Como migrar do SAS para Microsoft Fabric: Uma receita irresistível de Banoffee em 2 camadas"},{"content":"Introdução: A Fábrica de Dados em Tempo Real Imagine uma linha de produção moderna, onde os produtos são fabricados em tempo real, sem interrupções. Agora, substitua os produtos por dados, e você terá uma ideia do que é o streaming de dados. Bem-vindos à fábrica do futuro, onde os dados são processados 24/7, sem pausas para o cafezinho!\nPara entender melhor o conceito, vamos fazer uma analogia simples: pense no streaming de dados como um rio de informações que flui constantemente. Diferente de um lago (que representa o processamento em lote), este rio está sempre em movimento, trazendo novidades a cada segundo. Nesse rio, cada gota representa um dado - pode ser um clique em um site, uma transação bancária, uma leitura de sensor ou uma postagem em rede social. O que torna esse rio especial é sua capacidade de transportar informações instantaneamente, permitindo que empresas e organizações tomem decisões em tempo real.\nMas como funciona na prática? Imagine que você é o dono de uma rede de lojas de varejo. Com o streaming de dados, você pode saber instantaneamente quando um produto está prestes a esgotar no estoque, quais são as preferências dos clientes em diferentes regiões, ou até mesmo identificar padrões de compra antes mesmo que eles se tornem evidentes. É como ter um superpoder de inteligência de negócios que funciona 24 horas por dia, 7 dias por semana, sem nunca precisar dormir ou fazer uma pausa para um café. Essa capacidade de processar e analisar dados em tempo real está transformando a maneira como empresas de todos os setores tomam decisões estratégicas.\nO que é Streaming? Streaming de dados é como nossa linha de produção ininterrupta. Diferentemente do processamento em lote (batch), onde grandes volumes de dados são processados em intervalos programados, o streaming lida com fluxos contínuos de dados em tempo real.\nA principal diferença está na latência:\nBatch: Minutos, horas ou dias Streaming: Milissegundos ou segundos Esta imagem abaixo ilustra a arquitetura Lambda, um modelo de processamento de dados que combina processamento em lote (batch) e em tempo real (streaming) para lidar com grandes volumes de dados. A arquitetura é dividida em três camadas principais:\nSpeed Layer (Camada de Velocidade): Processa dados em tempo real usando tecnologias de streaming como Spark Streaming, Storm ou Flink. Produz visualizações incrementais dos dados. Batch Layer (Camada de Lote): Armazena todos os dados brutos e processa-os periodicamente para criar visualizações pré-computadas. Serving Layer (Camada de Serviço): Combina os resultados das camadas de velocidade e lote para fornecer respostas a consultas. As fontes de dados à esquerda incluem várias origens como NoSQL, IoT, logs web, ERP e sistemas legados. Esses dados alimentam tanto a camada de velocidade quanto a de lote.O fluxo de dados passa por processamento em lote e em tempo real, criando visualizações que são combinadas na camada de serviço. Isso permite consultas eficientes usando tecnologias como Spark SQL, Pig, Hive, etc.\n_Arquitetura Lambda_\nPor que Streaming é relevante? O streaming é crucial para casos de uso que exigem insights imediatos:\nDetecção de fraudes em transações financeiras Monitoramento de equipamentos industriais em tempo real Personalização de experiências de usuário em aplicativos Análise de sentimentos nas redes sociais Na nossa fábrica de dados, as esteiras transportadoras são os fluxos de informação, trazendo constantemente novos \u0026ldquo;produtos\u0026rdquo; (leia-se: dados) para serem processados. Esses dados podem vir de várias \u0026ldquo;fornecedoras\u0026rdquo;, como sensores IoT (nossa filial de eletrônicos), transações financeiras (o departamento contábil) ou até mesmo das redes sociais (o escritório de fofocas corporativas).\nA Linha de Montagem Microsoft Fabric O que é Microsoft Fabric? Microsoft Fabric é uma plataforma unificada de análise de dados que combina diversos serviços em um único ambiente. É como ter uma fábrica multifuncional que pode produzir qualquer tipo de insight que você precisa. Suas principais vantagens incluem:\nPlataforma unificada: Reduz custos de integração Escalabilidade: Suporta processamento de dados em larga escala Integração com IA: Incorpora ferramentas de machine learning Interface amigável: Acessível para diversos usuários O Microsoft Fabric é como uma linha de montagem super avançada, projetada para lidar com essa produção incessante de dados. Vamos conhecer as estações de trabalho desta linha:\nEventHouse: É o nosso armazém de matéria-prima. Aqui, os dados brutos chegam e são organizados para o processamento.\nKQL Queryset: Pense nele como o engenheiro de qualidade da fábrica. Ele examina os dados, faz perguntas complexas e garante que tudo esteja em ordem.\nReal-time Dashboard: É a sala de controle da fábrica. Aqui, os gerentes podem ver em tempo real como está a produção de insights.\nEventstream: Este é o sistema de esteiras da nossa fábrica. Ele move os dados de uma estação para outra, garantindo que tudo flua sem interrupções.\nActivator: Imagine-o como o sistema de alarmes da fábrica. Quando algo importante acontece, ele dispara um alerta para que a equipe possa agir rapidamente.\nComo Microsoft Fabric lida com Streaming? O Fabric utiliza a arquitetura Lambda para processar dados em streaming:\nCamada de velocidade: Event Stream Service Camada de lote: Pipelines, dataflows e notebooks Camada de serviço: Conecta-se a diferentes armazenamentos de dados Integração com Power BI e Real-Time Dashboards Fabric se integra perfeitamente com Power BI, permitindo a criação de dashboards em tempo real para visualização instantânea de insights.\nConectividade com outras ferramentas Fabric oferece conectividade com Azure, Databricks, Kafka e outras ferramentas, facilitando a integração com ecossistemas existentes.\nMãos à Obra: Montando Sua Linha de Produção de Insights Vamos criar uma linha de produção completa para monitorar o aluguel de bicicletas em tempo real, aproveitando as últimas atualizações do Microsoft Fabric.\nPasso 1: Configurar o EventHouse No portal do Microsoft Fabric, clique em \u0026ldquo;Criar\u0026rdquo; e selecione \u0026ldquo;Eventhouse\u0026rdquo;. Nomeie seu Eventhouse como \u0026ldquo;BikeRentalEventhouse\u0026rdquo;. _Criação do Eventhouse_\nPasso 2: Configurar o Eventstream No portal do Microsoft Fabric, crie um novo Eventstream chamado \u0026ldquo;BicycleRentalStream\u0026rdquo;. Como fonte de dados, selecione o conjunto de amostra \u0026ldquo;Bicycles\u0026rdquo; da Microsoft. _Add source do EventStream_\nConfigure o Eventstream para processar dados em tempo real, simulando o fluxo contínuo de informações de aluguel de bicicletas. Defina transformações para extrair informações relevantes, como:Número de bicicletas alugadas por horaLocalização das bicicletas mais popularesDuração média dos aluguéis Configure o destino dos dados processados para o EventHouse criado anteriormente. Ajuste as configurações de processamento para simular um cenário de tempo real, com atualizações frequentes. Teste o fluxo de dados usando a funcionalidade de visualização para garantir que os dados da amostra \u0026ldquo;Bicycles\u0026rdquo; estejam sendo processados corretamente. Ative o EventStream para iniciar o processamento contínuo dos dados de aluguel de bicicletas. _EventSteam pronto de Bicycles_\nPasso 3: Criar um KQL Queryset No Eventhouse, crie um novo KQL Queryset chamado \u0026ldquo;BikeRentalQueries\u0026rdquo;. Escreva uma query para analisar dados em tempo real: bikes | where ingestion_time() \u0026gt; ago(5m) | summarize AvgBikes = avg(No_Bikes), AvgEmptyDocks = avg(No_Empty_Docks) by Neighbourhood | order by AvgBikes desc _Execução da KQL query_\nPasso 4: Criar um Real-time Dashboard Crie um novo Real-Time Dashboard chamado \u0026ldquo;BikeRentalDashboard\u0026rdquo;. Adicione blocos utilizando a query do KQL Queryset. _Dashboard em tempo real_\nPasso 5: Configurar o Activator Crie um novo Activator chamado \u0026ldquo;BikeRentalAlert\u0026rdquo;. Configure alertas baseados no EventStream \u0026ldquo;BicycleRentalStream\u0026rdquo;. _Exemplo de Alert para BikeRental_\nPasso 6: Integração com Git e Pipelines de Implantação Aproveite a nova integração do GitHub para controle de versão. Configure pipelines de implantação para gerenciar o ciclo de vida de seus ativos de dados. Passo 7: Testar e Monitorar Use o novo recurso de monitoramento de workspace para acompanhar o desempenho de sua linha de produção de dados. Aproveite o Fabric Runtime 1.3, que inclui Apache Spark 3.5 e outras atualizações, para otimizar o processamento. Casos de Uso e Aplicações Reais Monitoramento de IoT: Análise em tempo real de dados de sensores industriais para manutenção preditiva. Análise de transações bancárias: Processamento instantâneo de transações para detecção de padrões suspeitos. Detecção de fraudes: Identificação imediata de atividades anômalas em sistemas de pagamento. Personalização de conteúdo: Ajuste em tempo real de recomendações baseadas no comportamento do usuário. Conclusão: O Chão de Fábrica do Futuro Com estas atualizações, sua fábrica de dados está mais poderosa do que nunca. O Microsoft Fabric continua evoluindo, oferecendo ferramentas cada vez mais robustas para lidar com dados em tempo real.\nResumo dos principais aprendizados Streaming no Fabric oferece processamento de dados em tempo real com latência mínima. A plataforma unifica diversas ferramentas de análise, simplificando o fluxo de trabalho. Event Streams permitem transformações sem código e roteamento flexível de dados. Integração perfeita com Power BI para visualizações em tempo real. Vantagens do Streaming no Microsoft Fabric Insights em tempo real para tomada de decisões rápidas Escalabilidade para lidar com grandes volumes de dados Flexibilidade para conectar diversas fontes e destinos de dados Redução de complexidade com uma plataforma unificada Próximos passos para quem quer começar Familiarize-se com os componentes do Fabric, especialmente Event Streams e OneLake. Identifique casos de uso em sua organização que se beneficiariam de análises em tempo real. Experimente criar um fluxo de eventos simples usando as ferramentas sem código do Fabric. Explore integrações com outras ferramentas que você já utiliza, como Azure ou Kafka. Lembre-se: na fábrica dos dados em tempo real, a inovação nunca para. Continue aprendendo e experimentando as novas funcionalidades para manter sua produção de conhecimento na vanguarda da tecnologia!\n","permalink":"https://julianamarialop.github.io/articles/streaming-microsoft-fabric-linha-de-producao-do-futuro/","summary":"Imagine uma linha de produção moderna, onde os produtos são fabricados em tempo real, sem interrupções. Agora, substitua os produtos por dados, e você terá uma ideia do que é o streaming de dados. Bem-vindos à fábrica…","title":"Streaming no Microsoft Fabric: A Linha de Produção do Futuro"},{"content":"Imagine que seus dados são como alguém sedentário que decidiu entrar em forma. O DBT (Data Build Tool) é o personal trainer que pega esses dados, cria um plano de treino adequado (transformações SQL) e os leva a um novo nível de performance. Em vez de simplesmente carregar pesos aleatórios (ETL tradicional), o DBT adota um método mais eficiente: ele faz os exercícios certos na ordem correta (ELT), garantindo que os dados fiquem enxutos e bem definidos dentro do data warehouse.\nCom o DBT, analistas e engenheiros de dados podem escrever consultas SQL para modelar e transformar dados sem precisar se preocupar com a infraestrutura subjacente. Além disso, ele oferece funcionalidades como versionamento de código, documentação automatizada e testes de qualidade de dados—afinal, um bom treino precisa de acompanhamento!\nPor que usar o DBT? O DBT tem ganhado popularidade por diversos motivos:\nFacilidade de Uso: Permite que analistas e engenheiros de dados escrevam transformações SQL sem precisar lidar com infraestrutura complexa. Modularidade: Facilita a criação de pipelines reutilizáveis e bem organizados, como um bom treino dividido em grupos musculares. Versionamento e Controle: Como o DBT utiliza repositórios Git, é fácil acompanhar mudanças e reverter versões anteriores, assim como um personal trainer ajusta um plano de treino com base no progresso. Testes de Qualidade de Dados: Inclui funcionalidades para garantir que os dados transformados sejam consistentes e confiáveis—ninguém quer um treino desajustado que cause lesões (erros de dados!). Documentação Automática: Gera documentação detalhada sobre os modelos criados, como um diário de treino que registra cada evolução. Compatibilidade com Data Warehouses Modernos: Funciona com BigQuery, Snowflake, Redshift, Databricks, entre outros. Como instalar o DBT? Se preparar para usar o DBT é como se inscrever na academia: um processo simples, mas que exige comprometimento.\nPasso 1: Instalar o DBT Execute o seguinte comando no terminal:\npip install dbt-core Caso esteja utilizando um data warehouse específico, instale também o adaptador correspondente. Por exemplo, para Snowflake:\npip install dbt-snowflake Passo 2: Configurar o DBT Após a instalação, inicialize um novo projeto DBT:\ndbt init meu_projeto Isso criará a estrutura básica de diretórios e arquivos necessários para começar a usar o DBT.\nPasso 3: Testar a Conexão Antes de executar modelos, é importante testar a conexão com o data warehouse configurado:\ndbt debug Se tudo estiver correto, o DBT estará pronto para rodar transformações e otimizar seu ambiente de dados!\nComo funciona o DBT? O DBT funciona como um programa de treino bem estruturado: ele pega os dados brutos (o aluno sedentário), aplica transformações SQL (os exercícios certos) e entrega resultados otimizados (dados prontos para análise).\nOs principais componentes do DBT são:\nModels: Transformações SQL aplicadas aos dados, como treinos específicos para diferentes grupos musculares. Seeds: Conjuntos de dados estáticos, como a dieta ajustada pelo personal trainer para apoiar os treinos. Snapshots: Registros das mudanças ao longo do tempo, como fotos de progresso antes e depois. Tests: Verificações automáticas para garantir qualidade, como exames de saúde periódicos para garantir que o plano está funcionando. Documentation: Geração automática de documentação baseada no código dos modelos, como um caderno de treinos que registra cada sessão. Além disso para transformar workflows de dados, utiliza scripts SQL (.sql) e YAML (.yml).\nScripts SQL: Auxiliam na transformação dos dados de maneira modularizada, utilizando CTEs (Common Table Expressions) para criar processos reutilizáveis e organizados. Scripts YAML: Permitem definir esquemas, descrições e regras de teste para as colunas, como not_null, unique, entre outras validações, garantindo a integridade e a qualidade dos dados. O DBT executa essas transformações de forma eficiente, criando uma estrutura clara e modular dentro do data warehouse.\n_Quais são os problemas que o DBT resolve ?_\nComo utilizar o DBT? Exemplo prático com um modelo multidimensional e camadas de medalhão Vamos considerar um exemplo de uma empresa de e-commerce que deseja construir um modelo multidimensional para análise de vendas, seguindo a abordagem de camadas de medalhão (Bronze, Prata e Ouro).\nPasso 1: Criando a Camada Bronze (Dados Brutos) A camada Bronze recebe os dados diretamente do S3, onde são armazenados em seu formato bruto. Para acessar esses dados no DBT, utilizamos a funcionalidade source, que aponta para o bucket correspondente:\nversion: 2 sources: - name: ecommerce schema: raw tables: - name: vendas_raw external: location: \u0026#39;s3://meu-bucket/raw/vendas/\u0026#39; format: \u0026#39;parquet\u0026#39; Com essa configuração, podemos referenciar os dados diretamente no DBT:\nSELECT * FROM {{ source(\u0026#39;ecommerce\u0026#39;, \u0026#39;vendas_raw\u0026#39;) }}; A camada Bronze armazena os dados exatamente como foram recebidos, sem transformação:\nSELECT * FROM {{ source(\u0026#39;ecommerce\u0026#39;, \u0026#39;vendas_raw\u0026#39;) }}; Passo 2: Criando a Camada Prata (Transformação e Limpeza) Aqui aplicamos regras de limpeza, deduplicação e formatação:\nWITH vendas_limpa AS ( SELECT pedido_id, cliente_id, produto_id, data_venda, quantidade, preco_unitario, quantidade * preco_unitario AS valor_total FROM {{ ref(\u0026#39;bronze_vendas\u0026#39;) }} WHERE data_venda IS NOT NULL ) SELECT * FROM vendas_limpa; Passo 3: Criando a Camada Ouro (Modelo Final para Análise) Nesta camada, criamos um modelo otimizado para análise multidimensional:\nWITH vendas_agrupadas AS ( SELECT data_venda, produto_id, SUM(quantidade) AS total_quantidade, SUM(valor_total) AS total_vendas FROM {{ ref(\u0026#39;prata_vendas\u0026#39;) }} GROUP BY data_venda, produto_id ) SELECT * FROM vendas_agrupadas; Passo 4: Criando dimensões Criamos também dimensões auxiliares, como dim_cliente.sql:\nSELECT cliente_id, nome, email, cidade, estado FROM {{ ref(\u0026#39;prata_clientes\u0026#39;) }}; E dim_produto.sql:\nSELECT produto_id, nome_produto, categoria FROM {{ ref(\u0026#39;prata_produtos\u0026#39;) }}; Essas tabelas funcionam como exercícios específicos para diferentes grupos musculares, ajudando a fortalecer e organizar melhor os dados.\nPasso 5: Criando relacionamentos e análises Com as tabelas criadas, podemos executar queries no data warehouse relacionando os dados e criando dashboards de análise, como se estivéssemos ajustando o treino para obter o máximo de desempenho nos resultados.\nComo consumir os dados via DBT Após processar e transformar os dados com o DBT, o próximo passo é consumi-los em ferramentas de visualização e análise, como o Power BI. O Power BI pode se conectar diretamente ao data warehouse onde os modelos do DBT foram criados, permitindo a criação de relatórios interativos e dashboards eficientes.\nConectando o Power BI ao Data Warehouse Se o seu DBT estiver configurado em um data warehouse como Snowflake, BigQuery ou Redshift, siga os passos abaixo para consumir os dados no Power BI:\nAbrir o Power BI e selecionar \u0026ldquo;Obter Dados\u0026rdquo;. Escolher a fonte de dados correspondente ao seu data warehouse (por exemplo, \u0026ldquo;Amazon Redshift\u0026rdquo;, \u0026ldquo;Google BigQuery\u0026rdquo; ou \u0026ldquo;Snowflake\u0026rdquo;). Inserir as credenciais de acesso ao banco de dados. Selecionar a tabela correspondente ao modelo de dados transformado pelo DBT. Criar medidas e cálculos no Power BI para análises adicionais. Construir gráficos, tabelas e dashboards interativos. Exemplo de Consulta no Power BI Caso seu data warehouse seja o Snowflake, uma consulta SQL simples para carregar dados de vendas no Power BI pode ser:\nSELECT data_venda, produto_id, total_quantidade, total_vendas FROM ouro_vendas; Após carregar os dados, você pode usar os recursos do Power BI para criar gráficos de tendências, KPIs de vendas e dashboards dinâmicos que auxiliam na tomada de decisão.\nComo utilizar uma esteira CI/CD para scripts de carga e orquestração com Airflow Para garantir que as transformações realizadas com DBT sejam executadas de forma confiável e automatizada, podemos utilizar uma esteira CI/CD combinada com o Apache Airflow para orquestrar os pipelines de dados.\nImplementando CI/CD para DBT O processo de CI/CD (Continuous Integration/Continuous Deployment) para DBT envolve versionamento, testes automatizados e implantação contínua de mudanças nos modelos de dados. Aqui está um fluxo básico:\nVersionamento do Código: O código SQL dos modelos DBT é gerenciado via Git. Testes Automatizados: Testes de integridade dos dados são executados automaticamente em cada alteração. Deploy Automatizado: Com ferramentas como GitHub Actions, GitLab CI/CD ou Jenkins, o código atualizado é automaticamente implantado no ambiente de produção. Agendamento e Execução: O Airflow orquestra a execução dos pipelines de transformação de dados. Orquestrando com Airflow O Apache Airflow é uma ferramenta poderosa para gerenciar e agendar pipelines de dados. Podemos utilizá-lo para orquestrar as camadas de dados (Bronze, Prata e Ouro) de forma eficiente.\nExemplo de um DAG no Airflow para orquestrar as camadas do modelo de medalhão:\nfrom airflow import DAG from airflow.operators.bash import BashOperator from datetime import datetime default_args = { \u0026#39;owner\u0026#39;: \u0026#39;airflow\u0026#39;, \u0026#39;depends_on_past\u0026#39;: False, \u0026#39;start_date\u0026#39;: datetime(2024, 1, 1), \u0026#39;retries\u0026#39;: 1, } dag = DAG( \u0026#39;dbt_medalhao_pipeline\u0026#39;, default_args=default_args, schedule_interval=\u0026#39;@daily\u0026#39;, catchup=False ) bronze = BashOperator( task_id=\u0026#39;bronze_layer\u0026#39;, bash_command=\u0026#39;dbt run --models bronze\u0026#39;, dag=dag ) prata = BashOperator( task_id=\u0026#39;prata_layer\u0026#39;, bash_command=\u0026#39;dbt run --models prata\u0026#39;, dag=dag ) ouro = BashOperator( task_id=\u0026#39;ouro_layer\u0026#39;, bash_command=\u0026#39;dbt run --models ouro\u0026#39;, dag=dag ) bronze \u0026gt;\u0026gt; prata \u0026gt;\u0026gt; ouro Neste exemplo:\nA camada Bronze é carregada primeiro. Em seguida, os dados são limpos e transformados na camada Prata. Por fim, os dados são agregados e modelados para análise na camada Ouro. Essa abordagem garante que os dados sejam processados corretamente e dentro de uma estrutura bem organizada, proporcionando melhor governança e confiabilidade.\nPreço do DBT O DBT oferece uma versão open-source gratuita, além de uma versão SaaS chamada DBT Cloud, que inclui funcionalidades adicionais como interface web, agendamento de jobs e maior suporte empresarial. O custo do DBT Cloud varia conforme o volume de dados e número de usuários, mas geralmente parte de planos gratuitos até valores personalizados para grandes empresas.\nAplicações práticas do DBT O DBT é amplamente utilizado por empresas que desejam melhorar seus processos de transformação de dados. Algumas aplicações comuns incluem:\nCriação de Data Marts: Construção de modelos de dados otimizados para BI e análise de negócios. Monitoramento de Qualidade de Dados: Aplicação de testes para garantir a integridade das informações. Auditoria e Rastreabilidade: Permite versionamento e rastreamento das transformações aplicadas. Automação de Pipelines de Dados: Facilita a execução de processos repetitivos e escaláveis. Como aprender DBT Se você deseja se aprofundar no DBT e se tornar um especialista, existem várias formas de aprendizado disponíveis.\nCursos no DBT Learn A plataforma oficial de aprendizado do DBT, DBT Learn, oferece cursos gratuitos e pagos para iniciantes e avançados. Lá, você pode encontrar tutoriais interativos, exercícios práticos e treinamentos guiados para aprender a usar o DBT de maneira eficiente.\nCertificações DBT Para aqueles que querem comprovar seu conhecimento, o DBT oferece certificações oficiais. Essas certificações validam suas habilidades na construção de modelos de dados, versionamento, testes e automação com DBT. Além de melhorar suas habilidades, a certificação pode ser um diferencial no mercado de trabalho.\nOutros recursos incluem a documentação oficial, vídeos no YouTube e blogs técnicos que abordam práticas recomendadas e casos de uso reais.\nConclusão O DBT é como um personal trainer para os seus dados: ele garante que cada transformação seja feita corretamente, fortalecendo seu pipeline de dados e entregando insights de qualidade. Se sua empresa busca otimizar a modelagem e análise de dados, o DBT pode ser a escolha ideal para sair do sedentarismo digital!\nAlém disso, à medida que mais empresas adotam o DBT, a comunidade em torno da ferramenta continua crescendo. Isso significa mais suporte, mais tutoriais e melhores práticas disponíveis para novos usuários, facilitando a adoção e aprimoramento da solução.\nSe você ainda não experimentou o DBT, talvez seja a hora de colocá-lo no seu plano de treino de dados. Afinal, ninguém quer um banco de dados fora de forma, cheio de consultas lentas e redundâncias. Chegou a hora de transformar seus dados em verdadeiros atletas da informação! O DBT é como um personal trainer para os seus dados: ele garante que cada transformação seja feita corretamente, fortalecendo seu pipeline de dados e entregando insights de qualidade. Se sua empresa busca otimizar a modelagem e análise de dados, o DBT pode ser a escolha ideal para sair do sedentarismo digital!\n","permalink":"https://julianamarialop.github.io/articles/dbt-o-personal-trainer-que-transforma-seus-dados-em-atletas/","summary":"Imagine que seus dados são como alguém sedentário que decidiu entrar em forma. O DBT (Data Build Tool) é o personal trainer que pega esses dados, cria um plano de treino adequado (transformações SQL) e os leva a um novo…","title":"DBT: O Personal Trainer que Transforma Seus Dados em Atletas de Elite"},{"content":"Imagine um mundo onde compartilhar dados entre empresas seja tão simples quanto abrir um aplicativo de delivery e pedir sua refeição favorita. No lugar de processos complicados, transferências demoradas e preocupações com segurança, você tem acesso instantâneo a dados confiáveis e atualizados. Esse é o futuro que o Databricks Delta Sharing oferece: um sistema aberto, seguro e eficiente para compartilhar dados entre organizações e plataformas, sem dores de cabeça.\nO que é o Databricks Delta Sharing? O Databricks Delta Sharing funciona como um grande restaurante buffet de dados. Em vez de cada usuário precisar cozinhar seus próprios pratos (ou seja, copiar e replicar dados), eles podem simplesmente pegar o que precisam da estação de self-service, sem desperdício e com qualidade garantida. E o melhor: sem filas intermináveis ou pratos misteriosos!\nConstruído sobre a arquitetura Delta Lake, ele permite que organizações compartilhem dados governados de seus Lakehouses com qualquer consumidor, independentemente de estar ou não na plataforma Databricks. Esse protocolo aberto garante que os destinatários possam acessar os dados compartilhados por meio de ferramentas como Python, R, SQL e plataformas de BI, promovendo interoperabilidade e eficiência.\n_Databricks Delta Sharing_\nE agora que você já entendeu o conceito do Delta Sharing, vamos explorar como ele pode transformar a forma como sua empresa compartilha informações.\nPor que minha empresa deveria adotar o Delta Sharing? Muitas empresas enfrentam dificuldades para compartilhar dados de forma segura e eficiente. Processos antigos exigem replicação excessiva, altos custos operacionais e riscos de segurança. O Delta Sharing resolve esses problemas, trazendo:\n✅ Redução de custos: Sem necessidade de replicação de dados ou transferência manual.\n✅ Acesso seguro: Governança centralizada e controle detalhado sobre quem acessa os dados.\n✅ Interoperabilidade: Funciona com diversas ferramentas e linguagens, sem amarras a um único fornecedor.\n✅ Atualizações em tempo real: Dados sempre atualizados, sem pipelines ETL desnecessários.\n✅ Facilidade de integração: Dados acessíveis diretamente por consumidores em seus próprios ambientes de trabalho.\nAgora que sabemos os benefícios, vamos entender os diferentes tipos de compartilhamento disponíveis.\nTipos de Compartilhamento no Delta Sharing Assim como um restaurante buffet oferece diferentes tipos de pratos para atender a diversos gostos e restrições alimentares, o Delta Sharing proporciona três maneiras distintas de compartilhar dados, dependendo das necessidades da sua empresa:\nProtocolo Databricks-to-Databricks: Compartilhe dados e ativos de IA entre workspaces Databricks, com governança integrada no Unity Catalog. Protocolo de Compartilhamento Aberto: Permite que qualquer consumidor, mesmo sem Databricks, acesse dados compartilhados via APIs abertas. Implementação de Código Aberto: Compartilhe dados entre qualquer plataforma, sem depender do Databricks. Independentemente do método escolhido, garantir que os destinatários tenham acesso eficiente e seguro é essencial.\nO que é um Recipient? No Delta Sharing, o Recipient (destinatário) é como um cliente de um buffet, que pode acessar os pratos disponíveis (dados) conforme sua necessidade, sem precisar cozinhar do zero. O Recipient pode ser um parceiro comercial, um cliente ou uma equipe interna. Os Recipients não precisam estar no Databricks, pois o Delta Sharing suporta acesso a partir de ferramentas populares como Python, SQL, Pandas, Apache Spark, Power BI e muitas outras.\nCada Recipient recebe um token de acesso seguro ou um arquivo de credenciais, garantindo que apenas usuários autorizados consigam acessar os dados.\nAgora que você já sabe como os dados são acessados, vamos ver como configurar o Delta Sharing na sua empresa.\nComo Configurar o Delta Sharing na sua Conta Antes de começar a compartilhar ou consumir dados pelo Delta Sharing, sua empresa precisa configurar o Databricks Unity Catalog, garantindo governança e segurança total sobre os dados. A configuração inclui:\nHabilitar o Unity Catalog no seu workspace Databricks. Definir Políticas de Acesso, configurando regras de segurança para controle granular. Ativar Logs de Auditoria para rastrear acessos e compartilhamentos de dados. Registrar os Recipients, garantindo que apenas usuários autorizados recebam permissões de acesso. Agora que sua conta está configurada, vamos ver como criar e compartilhar dados de maneira prática.\nClean Rooms: Compartilhamento Seguro e Colaborativo de Dados Uma abordagem avançada dentro do Delta Sharing é o conceito de Clean Rooms, um ambiente seguro que permite que diferentes empresas colaborem em análises de dados sem compartilhar diretamente suas informações brutas. Isso é especialmente útil para setores como saúde, finanças e varejo, onde a privacidade dos dados é uma prioridade.\nCom os Clean Rooms, as empresas podem definir regras que permitem que os parceiros analisem dados agregados e anonimizados, garantindo conformidade com regulamentações como GDPR e LGPD. Essa funcionalidade permite que múltiplos parceiros extraiam insights de um mesmo conjunto de dados sem comprometer a segurança.\nEmpresas que já utilizam o Delta Sharing Diversas empresas globais já adotaram o Delta Sharing para melhorar a eficiência e segurança no compartilhamento de dados:\nShell: Utiliza o Delta Sharing para compartilhar insights operacionais com parceiros do setor de energia, garantindo colaboração eficiente. HSBC: Implementou o Delta Sharing para otimizar processos de compliance e análise de risco financeiro. Adobe: Aproveita a plataforma para compartilhar dados de marketing e engajamento de clientes com parceiros estratégicos. Nasdaq: Utiliza o Delta Sharing para fornecer acesso seguro a dados de mercado e relatórios analíticos para investidores e reguladores. Custos do Delta Sharing Embora o Delta Sharing elimine a necessidade de replicação de dados, ele pode gerar custos relacionados à transferência de dados entre diferentes regiões e plataformas. Os custos podem incluir:\nSaída de dados (egress fees): Quando dados são compartilhados entre regiões na nuvem, pode haver cobrança pela transferência. Processamento de consultas: Dependendo da infraestrutura utilizada, há custos associados à execução de consultas nos dados compartilhados. Gerenciamento de permissões e logs: O Unity Catalog permite rastrear acessos e gerenciar permissões, o que pode impactar os custos de uso. Exemplo de Cálculo de Custos Vamos considerar um exemplo prático para estimar os custos do Delta Sharing:\nVolume de dados compartilhados: 10 TB por mês\nCusto de saída de dados (egress fees): $0.09 por GB\nCusto de processamento de consultas: $0.02 por consulta (considerando 100.000 consultas)\nCusto de gerenciamento de logs: $0.005 por operação de log (considerando 500.000 operações)\nCálculo total:\nCusto de saída de dados: $921.60 Custo de processamento: $2,000.00 Custo de gerenciamento de logs: $2,500.00 Custo total mensal estimado: $5,421.60 Empresas que compartilham grandes volumes de dados devem considerar estratégias para otimizar esses custos, como armazenamento em regiões próximas aos consumidores ou utilização de compressão de dados.\nConclusão: O Delta Sharing é o Futuro do Compartilhamento de Dados Com o Databricks Delta Sharing, sua empresa pode finalmente deixar para trás os processos manuais, demorados e inseguros de compartilhamento de dados. Essa mudança não só aumenta a eficiência operacional, mas também possibilita uma cultura de colaboração mais fluida e confiável, permitindo que diferentes equipes e parceiros acessem informações cruciais de maneira instantânea e segura.\nAlém disso, a adoção do Delta Sharing proporciona uma base sólida para futuras inovações. Com dados acessíveis em tempo real e governança robusta, as organizações podem acelerar suas iniciativas de inteligência artificial e analytics, gerando insights mais precisos e estratégicos. Isso permite que as empresas tomem decisões informadas com rapidez, respondendo de forma ágil às mudanças do mercado.\n💡 Se sua empresa deseja colaborar de forma eficiente, reduzir custos e impulsionar a inovação, está na hora de adotar o Delta Sharing! 🚀 Em vez de depender de transferências, cópias e replicações, os dados ficam acessíveis onde e quando forem necessários, com total controle e segurança.\n","permalink":"https://julianamarialop.github.io/articles/databricks-delta-sharing-e-o-buffet-de-dados-escolha-sirva-se/","summary":"Imagine um mundo onde compartilhar dados entre empresas seja tão simples quanto abrir um aplicativo de delivery e pedir sua refeição favorita. No lugar de processos complicados, transferências demoradas e preocupações…","title":"Azure Databricks Delta Sharing e o Buffet de Dados: Escolha, Sirva-se e Analise!"},{"content":"Se os antigos egípcios pudessem construir uma inteligência artificial, provavelmente invocariam seus deuses para tornar o sistema mais sábio, ágil e eficiente. Assim como Rá iluminava o mundo, Tot registrava o conhecimento, Anúbis julgava a verdade e Ísis trazia agilidade e equilíbrio, um LLM (Large Language Model) bem estruturado precisa combinar esses elementos para funcionar corretamente.\nNa prática, construir um LLM no Databricks não é apenas treinar um modelo de linguagem; é criar uma solução completa capaz de buscar informações em tempo real (RAG), se adaptar ao contexto (Fine-Tuning) e operar de forma eficiente (MosaicML).\nSe você quer entender como essas tecnologias podem transformar seu negócio – e como o Databricks é a plataforma ideal para isso – continue a leitura.\nO LLM Tradicional – Rá sem o Livro de Tot Na mitologia egípcia, Rá era o deus do Sol, responsável por atravessar o céu todos os dias em sua barca, iluminando o mundo e trazendo conhecimento. Mas mesmo sendo um deus poderoso, ele tinha uma limitação: ele só sabia o que via durante sua jornada diária. Se algo acontecesse no submundo ou em terras distantes, ele não teria como saber.\nO mesmo acontece com um LLM tradicional. Ele é treinado com uma grande quantidade de dados, mas depois de pronto, não pode aprender mais nada sozinho. Se algo novo acontecer no mundo – como uma mudança em uma lei ou um novo produto lançado no mercado – ele pode dar uma resposta desatualizada ou até inventar um dado falso (alucinação).\nNo contexto empresarial, isso significa um chatbot que responde perguntas incorretamente, um sistema de análise de contratos que não considera cláusulas recentes ou um assistente virtual que não sabe explicar a nova política da empresa.\nPara resolver esse problema, precisamos de algo que permita ao LLM buscar informações atualizadas antes de responder. E esse \u0026ldquo;algo\u0026rdquo; tem nome: RAG.\nLLM com RAG – Tot e o Livro da Sabedoria Na mitologia egípcia, Tot era o deus da sabedoria, da escrita e da contabilidade. Ele era responsável por registrar tudo o que acontecia e possuía o Livro de Tot, que continha todo o conhecimento do universo.\nSe Rá pudesse consultar esse livro antes de responder perguntas, ele não dependeria apenas da própria memória, mas poderia acessar informações externas para fornecer respostas precisas e atualizadas.\nIsso é exatamente o que RAG (Retrieval-Augmented Generation) faz.\nCom RAG, o LLM pode acessar bancos de dados, documentos internos, APIs e Data Lakes para complementar sua resposta. Ele não depende apenas do que aprendeu durante o treinamento, mas pode buscar dados novos em tempo real.\n💡 Exemplo prático: Imagine que um banco quer usar um chatbot para responder dúvidas de clientes sobre investimentos. Se a taxa de juros mudar hoje, um LLM tradicional pode continuar dando a resposta antiga. Mas com RAG, ele busca a informação correta antes de responder, garantindo que o cliente receba dados atualizados e confiáveis.\nComo Implementar RAG no Databricks? O Databricks é ideal para essa abordagem porque:\nPermite armazenar documentos e tabelas estruturadas em um Delta Lake. Facilita a criação de bancos de vetores usando bibliotecas como ChromaDB. Oferece APIs escaláveis para recuperação de dados. No Databricks, podemos configurar um pipeline RAG assim:\nfrom langchain.document_loaders import CSVLoader from langchain.vectorstores import Chroma from langchain.embeddings import HuggingFaceEmbeddings # Carregar documentos empresariais loader = CSVLoader(\u0026#34;dbfs:/mnt/datalake/documentos.csv\u0026#34;) documents = loader.load() # Criar embeddings para busca eficiente embeddings = HuggingFaceEmbeddings(model_name=\u0026#34;sentence-transformers/all-MiniLM-L6-v2\u0026#34;) vectorstore = Chroma.from_documents(documents, embeddings) # Criar um retriever para buscar informações relevantes retriever = vectorstore.as_retriever() Agora, o LLM pode consultar o \u0026ldquo;Livro de Tot\u0026rdquo; sempre que necessário, garantindo respostas mais inteligentes e confiáveis.\nFine-Tuning – O Julgamento de Anúbis e Osíris Os antigos egípcios acreditavam que, ao morrer, a alma passava pelo Julgamento de Osíris. Anúbis, o deus dos mortos, pesava o coração do falecido contra a pena da deusa Maat, símbolo da verdade e da justiça. Se o coração fosse leve, a alma poderia seguir para a vida eterna. Se fosse pesado, seria devorado por Ammut, a devoradora de almas.\nO Fine-Tuning cumpre esse papel para um LLM. Ele ajusta o modelo para que suas respostas sejam avaliadas e refinadas até atingirem um nível aceitável de precisão.\nNo Databricks, isso pode ser feito com clusters otimizados para deep learning, acelerando o processo de ajuste do modelo para atender às necessidades específicas do negócio.\nfrom transformers import AutoModelForCausalLM, TrainingArguments, Trainer model_name = \u0026#34;mistralai/Mistral-7B\u0026#34; model = AutoModelForCausalLM.from_pretrained(model_name) training_args = TrainingArguments( output_dir=\u0026#34;./results\u0026#34;, per_device_train_batch_size=2, num_train_epochs=1 ) trainer = Trainer( model=model, args=training_args, train_dataset=meus_dados_treinamento ) trainer.train() Agora, o modelo passou pelo julgamento de Anúbis e Osíris e está pronto para fornecer respostas confiáveis.\nMosaicML – As Asas de Ísis para a Produtização Apenas ter um modelo treinado não basta. Ele precisa ser rápido e eficiente. MosaicML é como as asas de Ísis, permitindo que o LLM funcione sem consumir quantidades absurdas de energia computacional.\nCom MosaicML no Databricks, conseguimos:\nReduzir custos de inferência com otimizações como quantização e pruning. Acelerar o tempo de resposta sem comprometer a qualidade. Escalar o modelo para milhares de usuários sem travamentos. No Databricks, o modelo otimizado pode ser salvo e implantado com MLflow:\nimport mlflow mlflow.set_experiment(\u0026#34;/Users/seu_usuario/RAG_experiment\u0026#34;) with mlflow.start_run(): mlflow.transformers.log_model(model, artifact_path=\u0026#34;llm_produtizado\u0026#34;) Agora, temos um LLM que não só responde bem, mas também faz isso com velocidade e eficiência.\nCriando um Deus da Inteligência Artificial Ao longo da mitologia egípcia, os deuses não atuavam sozinhos. Cada um tinha um papel essencial para garantir que o mundo funcionasse em equilíbrio. Para criar um LLM verdadeiramente eficiente, precisamos combinar essas forças divinas: a luz do conhecimento, o acesso à sabedoria infinita, a avaliação cuidadosa das respostas e a velocidade para operar de forma eficaz.\nAssim como os sacerdotes egípcios combinavam diferentes divindades para resolver os desafios do mundo antigo, nós unimos RAG, Fine-Tuning e MosaicML para construir um modelo robusto, confiável e ágil. Abaixo, a analogia completa:\n_Comparação elementos mitológicos_\nConclusão Criar um LLM no Databricks utilizando RAG, Fine-Tuning e MosaicML não é apenas um desafio técnico, mas uma forma de elevar a inteligência artificial a um novo patamar de utilidade e eficiência.\nImagine o impacto de um sistema que não só responde perguntas, mas busca as informações corretas, aprende com a empresa e opera de forma otimizada. Esse tipo de solução pode transformar empresas ao reduzir custos operacionais, melhorar a experiência do usuário e aumentar a confiabilidade das informações fornecidas.\nSe no Egito Antigo o conhecimento era transmitido através de papiros e templos, hoje temos ferramentas como Databricks e MosaicML para processar bilhões de dados em segundos. O princípio, no entanto, continua o mesmo: o conhecimento precisa ser preciso, confiável e eficiente.\nE assim, com a combinação dessas tecnologias, criamos um verdadeiro deus da inteligência artificial, capaz de trazer luz, sabedoria, justiça e velocidade para a era da IA.\n","permalink":"https://julianamarialop.github.io/articles/os-deuses-egipcios-e-inteligencia-artificial-como-construir/","summary":"Se os antigos egípcios pudessem construir uma inteligência artificial, provavelmente invocariam seus deuses para tornar o sistema mais sábio, ágil e eficiente. Assim como Rá iluminava o mundo , Tot registrava o…","title":"Os Deuses Egípcios e a Inteligência Artificial: Como Construir um LLM no Azure Databricks com RAG, Fine-Tuning e MosaicML"},{"content":"Nos dias de hoje, a tomada de decisão baseada em dados é o coração das empresas. Entretanto, a eficácia dessas decisões depende diretamente da qualidade dos dados utilizados. Dados inconsistentes, incompletos ou incorretos podem comprometer análises, gerar insights equivocados e, no pior dos cenários, levar a decisões desastrosas.\nAqui é onde entra o Databricks DQX: uma biblioteca desenvolvida para garantir a qualidade dos dados em pipelines criados no Databricks , usando regras personalizadas e automáticas para validar, monitorar e corrigir problemas de qualidade antes que eles contaminem camadas mais sensíveis. Se imaginarmos o pipeline de dados como um multiverso de dimensões paralelas que precisa ser protegido contra anomalias, o DQX é como o Doutor Estranho, usando suas habilidades para manter a ordem e garantir que apenas dados de qualidade avancem pelas dimensões corretas.\nO que é o Databricks DQX? O Databricks DQX é uma ferramenta de gerenciamento de qualidade de dados projetada para ser utilizada em pipelines do Databricks que fazem uso do Apache Spark. Ele permite definir regras de validação para DataFrames e streams, proporcionando uma abordagem programática para verificar a integridade, completude e consistência dos dados.\nO DQX suporta diferentes tipos de regras, como validação de formato de campos, valores nulos, valores duplicados e muito mais. Essas regras podem ser configuradas para gerar alertas ou bloquear completamente a propagação de dados inválidos. Além disso, ele oferece relatórios detalhados e logs que ajudam as equipes a entenderem e corrigirem problemas rapidamente.\nPor que a Qualidade de Dados é Crítica em Projetos Analytics? Em um projeto de dados, as camadas de um Data Lake são divididas geralmente em bronze, silver e gold:\nCamada Bronze: Onde os dados crus são armazenados sem qualquer processamento ou validação. Camada Silver: Onde os dados passam por um processo de limpeza e padronização. Camada Gold: Onde os dados já estruturados e de alta qualidade são consumidos por ferramentas de BI e modelos analíticos. Se dados inválidos passam da camada bronze para a silver, eles podem contaminar toda a cadeia de valor, prejudicando a eficiência das análises subsequentes e comprometendo o desempenho de modelos de machine learning. Dados de baixa qualidade podem introduzir viés, gerar predições imprecisas e levar a decisões equivocadas. Isso torna essencial a adoção de boas práticas de validação e limpeza logo nas etapas iniciais do pipeline., eles podem contaminar toda a cadeia, gerando problemas sérios mais adiante. Portanto, aplicar regras rigorosas de qualidade entre essas camadas é fundamental. Quanto mais cedo os problemas de qualidade forem identificados e corrigidos, menor será o custo de retrabalho, evitando que erros se propaguem para as camadas mais valiosas, como a camada gold. Isso também melhora a eficiência dos processos analíticos, garantindo que as decisões sejam sempre baseadas em dados consistentes e confiáveis.\nComo Utilizar o DQX entre as Camadas Bronze e Silver A imagem abaixo ilustra como o DQX se encaixa no pipeline de dados em um Data Lakehouse. O processo começa com a camada bronze, onde os dados crus são armazenados. O DQX realiza um processo de data profiling, analisando os dados e gerando candidatos a regras de qualidade. Em seguida, as regras de qualidade são aplicadas, separando os dados válidos dos inválidos. Dados que falham na validação são enviados para um dataset de quarentena, onde podem ser monitorados e revisados. Dados corrigidos ou enriquecidos podem ser reintegrados ao pipeline após a curadoria, garantindo que apenas informações consistentes avancem para a camada silver. Na camada gold, os dados já estão prontos para consumo por ferramentas de BI e modelos analíticos.\n_DQX Quality Checking_\nVamos imaginar que estamos lidando com dados financeiros. Na camada bronze, temos registros de transações bancárias, e precisamos garantir que apenas transações válidas avancem para a camada silver.\nVamos imaginar que estamos lidando com dados financeiros. Na camada bronze, temos registros de transações bancárias, e precisamos garantir que apenas transações válidas avancem para a camada silver.\nO primeiro passo é definir as regras de qualidade que queremos aplicar. Algumas regras comuns podem incluir:\nCampos obrigatórios não podem estar nulos. O valor da transação deve ser positivo. O formato da data deve ser consistente. Com o DQX, você pode criar regras como esta:\n_Exemplo de notebook utilizando DQX_\nEsse processo garante que apenas os registros que atendem a todas as regras serão promovidos para a camada silver. Os dados inválidos podem ser armazenados separadamente para auditoria e correção.\nConfira o notebook completo aqui!\nComo Instalar e Configurar o Databricks DQX A instalação do DQX é simples e pode ser feita diretamente com o pip:\npip install databricks-labs-dqx Depois de instalado, você pode importar a biblioteca e começar a definir suas regras de qualidade, como mostrado no exemplo anterior.\nPara mais detalhes, você pode consultar a documentação oficial no GitHub.\nConclusão O Databricks DQX é muito mais do que uma simples ferramenta de validação de dados – ele é o verdadeiro mestre da qualidade, garantindo que apenas dados consistentes avancem pelas camadas do Data Lake. Assim como o Doutor Estranho protege o multiverso de ameaças interdimensionais, o DQX protege o pipeline de dados, impedindo que informações incorretas contaminem suas análises.\nSe você deseja construir pipelines robustos e garantir que suas decisões sejam sempre baseadas em dados de alta qualidade, o DQX é a solução ideal. Afinal, como diria o Doutor Estranho: “Esta linha de dados está protegida” – apenas dados de qualidade podem atravessar.\n","permalink":"https://julianamarialop.github.io/articles/databricks-dqx-o-doutor-estranho-do-seu-pipeline-de-dados/","summary":"Nos dias de hoje, a tomada de decisão baseada em dados é o coração das empresas. Entretanto, a eficácia dessas decisões depende diretamente da qualidade dos dados utilizados. Dados inconsistentes, incompletos ou…","title":"Azure Databricks DQX: O Doutor Estranho do Seu Pipeline de Dados – Protegendo o Multiverso da Qualidade!"},{"content":"Introdução - Coperação Inteligente: A Base dos Clusters do Databricks O Databricks é uma plataforma robusta para processamento e análise de grandes volumes de dados, suportando cargas de trabalho que variam desde a engenharia de dados até a ciência de dados e análise de negócios. Um dos principais componentes do Databricks é o cluster, que é uma coleção de máquinas virtuais configuradas para executar códigos em distribuição paralela usando Apache Spark.\nUma boa forma de entender o funcionamento de um cluster é compará-lo a uma colmeia de abelhas. Assim como uma colmeia é composta por centenas ou milhares de abelhas que trabalham em conjunto para manter a colmeia produtiva e organizada, um cluster é formado por vários nós (máquinas virtuais) que cooperam para processar grandes volumes de dados de forma eficiente.\nTradicionalmente, utilizando o All-Purpose Compute, os usuários podiam criar clusters personalizados configurando aspectos como a versão do Spark, os tipos de nós (driver e workers) e o número de nós no cluster. Além disso, era possível instalar bibliotecas adicionais para atender a cargas de trabalho específicas, proporcionando grande flexibilidade. Esse método foi amplamente utilizado como padrão durante um longo período.\nEntretanto, o Databricks evoluiu e agora oferce novas possibilidades, incluindo a opção de computação sem servidor (Serverless Compute), que traz uma abordagem mais automatizada e escalável para lidar com demandas variadas. Assim como as abelhas operárias podem se adaptar rapidamente às necessidades da colmeia, o Databricks se adapta às cargas de trabalho com diferentes tipos de clusters.\nTipos de Clusters no Databricks All-Purpose Compute Clusters Jobs Clusters Serverless Clusters High Concurrency Clusters Photon Clusters Detalhamento dos Tipos de Clusters 1. All-Purpose Compute Clusters Os clusters de uso geral (All-Purpose) são projetados para serem altamente configuráveis, permitindo que os usuários definam detalhes como:\nVersão do Apache Spark Tipo de instância (nós driver e workers) Quantidade de nós no cluster Nesta configuração, o nó driver atua como a abelha rainha, coordenando toda a atividade da colmeia, enquanto os nós workers representam as abelhas operárias, que realizam as tarefas de processamento de dados. A comunicação eficiente entre eles garante que os dados sejam processados de forma rápida e precisa.\n_All-Purpose Clusters_\nVantagens:\nFlexibilidade total para personalizar o ambiente conforme a necessidade. Permite a instalação de bibliotecas adicionais para suportar workloads específicas. Casos de uso recomendados:\nDesenvolvimento e exploração de dados. Execução de notebooks interativos. Trabalhos que demandam um ambiente altamente customizado. 2. Jobs Clusters Os Jobs Clusters são criados automaticamente para executar uma tarefa (“job”) específica e são encerrados assim que a tarefa é concluída.\nDa mesma forma que algumas abelhas podem ser destacadas para missões específicas, como coletar néctar de uma fonte distante, os jobs clusters são criados para realizar uma tarefa pontual e depois desativados, economizando recursos.\n_Job Clusters_\nVantagens:\nRedução de custos devido à criação e encerramento automáticos. Configuração rápida e simples para execução de workloads programadas. Casos de uso recomendados:\nExecução de pipelines ETL programados. Processamento de dados em lotes. Execução de tarefas recorrentes. 3. Serverless Clusters Os Serverless Clusters eliminam a necessidade de configuração manual, escalando automaticamente de acordo com a carga de trabalho.\nAssim como em uma colmeia onde a quantidade de abelhas operárias pode variar dependendo da estação do ano ou das necessidades da colmeia, os serverless clusters se ajustam automaticamente à demanda, garantindo eficiência e evitando desperdício de recursos.\n_Computação sem Servidor_\nVantagens:\nEscalonamento automático e gerenciamento simplificado. Redução do tempo de inicialização, melhorando a produtividade. Ideal para workloads intermitentes, pois você paga apenas pelo uso real. Os warehouses utilizados nesses clusters podem ser configurados em diferentes tamanhos, como Small, Medium, Large, e X-Large, dependendo da demanda de processamento. Além disso, o dimensionamento automático permite que o sistema ajuste dinamicamente os recursos alocados conforme a carga de trabalho, garantindo desempenho ideal e controle de custos.\n_Tamanhos de cluster para SQL Warehouses_\nCasos de uso recomendados:\nExecução de workloads ad hoc. Consultas SQL e processamento de dados sem necessidade de configuração complexa. Análise de dados em tempo real. 4. High Concurrency Clusters Os High Concurrency Clusters são projetados para atender vários usuários simultaneamente, oferecendo suporte à execução paralela de várias tarefas.\nAssim como diferentes abelhas trabalham simultaneamente em diversas tarefas dentro da colmeia, os high concurrency clusters permitem que vários usuários executem seus códigos ao mesmo tempo sem comprometer o desempenho.\nVantagens:\nSuporte a vários usuários simultâneos sem degradação significativa de desempenho. Ideal para ambientes colaborativos. Casos de uso recomendados:\nAnálise colaborativa. Dashboards interativos com vários acessos simultâneos. Plataformas de Business Intelligence integradas ao Databricks. 5. Photon Clusters O Photon é um mecanismo de execução de última geração projetado para melhorar significativamente o desempenho de tarefas, especialmente em cargas de trabalho típicas de data warehouse. Ele é totalmente compatível com as APIs de DataFrame e SQL do Apache Spark e foi otimizado para operações como:\nUPDATE DELETE MERGE INSERT CREATE TABLE AS Vantagens:\nRedução significativa no tempo de execução de tarefas. Menor custo operacional devido à eficiência aprimorada. Ideal para cargas de trabalho que envolvem modificações frequentes em grandes volumes de dados. Casos de uso recomendados:\nProcessamento de dados em larga escala. Cargas de trabalho de data warehouse que exigem alta performance. Pipelines que executam operações complexas de modificação de dados. Custo de Cada Tipo de Cluster All-Purpose Compute Clusters: Têm custos elevados devido à necessidade de manter o cluster ativo durante o desenvolvimento. São recomendados apenas para tarefas interativas e desenvolvimento. Jobs Clusters: Mais econômicos, pois são criados e encerrados automaticamente. O custo é proporcional ao tempo de execução das tarefas. Serverless Clusters: O custo é baseado no uso real, sendo uma opção altamente eficiente para workloads esporádicos. High Concurrency Clusters: Apresentam um custo intermediário, adequado para ambientes colaborativos onde há múltiplos acessos simultâneos. Photon Clusters: Apesar de apresentarem custos semelhantes aos All-Purpose Clusters, a eficiência aprimorada do Photon pode levar a uma redução significativa nos custos gerais, especialmente em cargas de trabalho intensivas. Monitoramento de Custos Para controlar os custos no Databricks, especialmente ao utilizar computação sem servidor, é possível monitorar o uso consultando as tabelas do sistema (system.billing.usage), que contêm informações detalhadas sobre usuários e cargas de trabalho relacionadas aos custos.\nComo alternativa, você pode importar um painel de cobrança diretamente para o console da conta. Usando essas ferramentas, é possível rastrear custos e utilização sem servidor, obtendo relatórios detalhados que oferecem informações sobre:\nCustos de SQL Custos de DLT (Delta Live Tables) Custos de jobs Custos de modelos de machine learning Esses relatórios permitem uma visão abrangente e detalhada, ajudando a otimizar o uso de recursos e reduzir despesas desnecessárias. Abaixo temos um exemplo de consulta para esse monitoramento:\nSELECIONE t1.workspace_id, SOMA(t1.usage_quantity * list_prices.pricing. default ) como list_cost DE system.billing.usage t1 INNER JOIN system.billing.list_prices em t1.cloud = list_prices.cloud e t1.sku_name = list_prices.sku_name e t1.usage_start_time \u0026gt;= list_prices.price_start_time e (t1.usage_end_time \u0026lt;= list_prices.price_end_time ou list_prices.price_end_time é nulo) ONDE t1.sku_name COMO \u0026#39;%SERVERLESS%\u0026#39; AGRUPAR POR t1.workspace_id Conclusão - Eficiência Inspirada pela Natureza: Clusters do Databricks em Ação Assim como em uma colmeia de abelhas, onde cada integrante desempenha um papel fundamental para o bom funcionamento do todo, um cluster no Databricks é formado por vários nós que trabalham em conjunto para processar grandes volumes de dados de maneira eficiente. O Databricks oferece uma variedade de opções de clusters para atender diferentes tipos de workloads, desde desenvolvimento e execução de pipelines até análise colaborativa e processamento ad hoc. Cada tipo de cluster possui suas vantagens e é indicado para cenários específicos, permitindo que as organizações escolham a melhor solução conforme suas necessidades.\nAlém disso, a possibilidade de monitorar custos e utilização de forma detalhada garante maior controle financeiro e operacional. Com essas funcionalidades, o Databricks se destaca como uma solução escalável e eficiente para projetos de dados em diversos segmentos de mercado.\n","permalink":"https://julianamarialop.github.io/articles/como-uma-colmeia-bem-organizada-explorando-os-clusters/","summary":"O Databricks é uma plataforma robusta para processamento e análise de grandes volumes de dados, suportando cargas de trabalho que variam desde a engenharia de dados até a ciência de dados e análise de negócios. Um dos…","title":"Como uma Colmeia Bem Organizada: Explorando os Clusters do Azure Databricks"},{"content":"Antes da Batalha: Conheça os Heróis dos Dados Nos últimos anos, a necessidade de plataformas robustas para análise de grandes volumes de dados tornou-se evidente para empresas que buscam se tornar mais orientadas por dados. Duas das soluções mais comentadas atualmente são o Databricks e o WatsonX.data da IBM , cada uma oferecendo uma abordagem diferenciada para atender a essas demandas.\nNesta análise, utilizaremos uma analogia entre super-heróis para ilustrar as diferenças entre essas ferramentas. Vamos comparar o Databricks ao Homem de Ferro e o WatsonX.data ao Capitão América.\nDatabricks - O Homem de Ferro das Plataformas de Dados Assim como Tony Stark, o Databricks é uma solução altamente tecnológica e inovadora. Fundado em 2013 pelos criadores do Apache Spark, o Databricks se consolidou como líder no segmento de data lakes e machine learning. Sua proposta é oferecer um ambiente unificado para engenharia de dados, ciência de dados e análise de dados, sempre com tecnologias de ponta e constantes atualizações. O grande diferencial é a implementação do conceito de \u0026ldquo;Lakehouse\u0026rdquo;, que combina as vantagens de data lakes e data warehouses.\nAssim como a armadura do Homem de Ferro, o Databricks está em constante evolução, oferecendo novos recursos e integrações que o tornam extremamente versátil para diferentes tipos de missão.\nWatsonX.data - O Capitão América da Análise de Dados Parte do portfólio WatsonX da IBM, representa a solução clássica e confiável, assim como Steve Rogers. Lançado em 2023, essa solução foi projetada para fornecer uma plataforma robusta e segura, com foco em governança e conformidade. A IBM sempre foi reconhecida por soluções seguras e estáveis, e WatsonX.data continua essa tradição, garantindo que as empresas possam confiar plenamente na plataforma para lidar com dados sensíveis.\nAssim como o Capitão América lidera pelo exemplo e pela estabilidade, WatsonX oferece uma base sólida e estável para empresas que priorizam segurança e governança.\nCritérios de Comparação Para facilitar o entendimento vamos dividir essa comparação pelos tópicos abaixo:\nArquitetura e Integração Performance e Escalabilidade Governança e Segurança Facilidade de Uso e Desenvolvimento Ecossistema e Ferramentas Custo Total de Propriedade (TCO) 1. Arquitetura e Integração Databricks (Homem de Ferro): O Databricks se destaca por sua arquitetura de Lakehouse, que permite trabalhar com dados estruturados e não estruturados em um único repositório. Ele se integra nativamente com diversas soluções em nuvem, como Azure, AWS e Google Cloud, permitindo flexibilidade na escolha do provedor de nuvem. Assim como o Homem de Ferro se conecta a várias tecnologias, o Databricks oferece integração robusta com ferramentas modernas.\nPrós:\nArquitetura unificada para dados transacionais e analíticos. Forte integração com ferramentas de machine learning. Suporte amplo a workloads distribuídos. Contras:\nConfiguração inicial pode ser complexa para usuários iniciantes. Custos podem escalar rapidamente dependendo do volume de dados. WatsonX.data (Capitão América): Sua arquitetura é voltada para empresas que já utilizam outras soluções IBM, oferecendo uma integração forte com o ecossistema Watson e outras ferramentas corporativas. A plataforma também tem suporte nativo para workloads em ambientes híbridos e multi-cloud. Assim como o Capitão América é conhecido por sua lealdade e estabilidade, essa ferramenta se destaca pela integração segura e confiável.\nPrós:\nForte integração com soluções legadas da IBM. Otimizado para workloads em ambientes híbridos. Foco em segurança corporativa. Contras:\nMenor suporte para ferramentas de terceiros comparado ao Databricks. Pode exigir maior investimento inicial para empresas não familiarizadas com o ecossistema IBM. 2. Performance e Escalabilidade Databricks (Homem de Ferro): Databricks utiliza o motor Apache Spark para processamento distribuído, garantindo alta performance em workloads analíticas e de machine learning. A plataforma também oferece otimizações, como o Delta Lake, que melhora a performance de consultas transacionais.\nPrós:\nAlta performance em processamento distribuído. Suporte a grandes volumes de dados sem perda de eficiência. Contras:\nRequer otimização manual para workloads mais complexos. WatsonX.data (Capitão América): Foi projetado para oferecer alta performance em consultas analíticas complexas, com otimizações específicas para workloads em ambientes híbridos. Assim como o Capitão América, que se destaca pela consistência e resistência oferecendo desempenho consistente.\nPrós:\nDesempenho consistente em ambientes híbridos. Suporte nativo a workloads de IA. Contras:\nPode não ser tão eficiente quanto o Databricks para workloads de machine learning. 3. Governança e Segurança Databricks (Homem de Ferro): Databricks oferece recursos robustos de governança através do Unity Catalog, que permite gestão centralizada de metadados e controle de acesso baseado em roles.\nPrós:\nUnity Catalog facilita a governança de dados em grande escala. Forte suporte a GDPR e outras regulações. Contras:\nPode exigir configurações adicionais para ambientes altamente regulamentados. WatsonX.data (Capitão América): A IBM sempre foi reconhecida pelo foco em segurança corporativa e continua essa tradição. A plataforma oferece criptografia de ponta a ponta e controle de acesso granular.\nPrós:\nSolução altamente segura. Suporte nativo a normas de conformidade corporativa. Contras:\nPode ser complexo para configurar em ambientes não IBM. 4. Facilidade de Uso e Desenvolvimento Databricks (Homem de Ferro): Databricks oferece uma interface amigável e altamente colaborativa, permitindo que equipes de engenheiros de dados, cientistas de dados e analistas trabalhem juntas de maneira eficiente. O suporte a notebooks interativos torna o desenvolvimento mais intuitivo.\nPrós:\nInterface colaborativa com suporte a notebooks. Ampla documentação e comunidade ativa. Contras:\nPode exigir curva de aprendizado inicial, especialmente para quem não tem experiência com Spark. WatsonX.data (Capitão América): Apresenta uma interface focada na facilidade de uso para empresas que já utilizam outras soluções IBM. Além disso, a integração nativa com ferramentas Watson facilita o desenvolvimento de soluções de IA.\nPrós:\nInterface intuitiva para usuários do ecossistema IBM. Forte suporte a soluções de IA. Contras:\nMenor flexibilidade para personalização em relação ao Databricks. 5. Ecossistema e Ferramentas Databricks (Homem de Ferro): Databricks possui um ecossistema extenso, com suporte a diversas linguagens de programação (Python, R, Scala, SQL) e integração com uma ampla gama de ferramentas de terceiros, como Power BI, Tableau e Looker.\nPrós:\nSuporte a múltiplas linguagens de programação. Integração robusta com ferramentas de BI. Contras:\nAlgumas integrações podem exigir configuração adicional. WatsonX.data (Capitão América): WatsonX.data se beneficia do ecossistema IBM, oferecendo integração nativa com soluções como Watson AI, SPSS e Cognos Analytics.\nPrós:\nEcossistema consolidado para soluções corporativas. Forte integração com ferramentas de análise preditiva. Contras:\nMenor diversidade de ferramentas suportadas em comparação ao Databricks. 6. Custo Total de Propriedade (TCO) Databricks (Homem de Ferro): O custo total de propriedade do Databricks pode variar significativamente dependendo do uso e da escala. Embora a plataforma ofereça grande flexibilidade, os custos podem aumentar rapidamente com workloads complexos.\nPrós:\nModelo de custo baseado em uso, permitindo escalabilidade. Flexibilidade para ajustar recursos conforme a demanda. Contras:\nPode ser caro para workloads contínuos de alta escala. WatsonX.data (Capitão América): Possue um modelo de licenciamento que favorece empresas já usuárias de outras soluções IBM. O custo pode ser mais previsível para essas empresas, mas menos competitivo para novos clientes.\nPrós:\nModelo de licenciamento previsível. Benefícios para clientes IBM existentes. Contras:\nPode ser menos competitivo em custo inicial para novos clientes. Escolha o Herói Certo para a Sua Missão Databricks e WatsonX.data são soluções poderosas para análise de dados em larga escala, cada uma com seus pontos fortes e fracos. O Databricks, assim como o Homem de Ferro, brilha pela inovação, flexibilidade e capacidade de adaptação rápida. Já o WatsonX.data,como o Capitão América, se destaca pela estabilidade, segurança e confiabilidade em ambientes corporativos. A escolha ideal dependerá das necessidades específicas de cada organização.\n","permalink":"https://julianamarialop.github.io/articles/databricks-e-watsonxdata-na-arena-dos-herois-quem-leva/","summary":"Nos últimos anos, a necessidade de plataformas robustas para análise de grandes volumes de dados tornou-se evidente para empresas que buscam se tornar mais orientadas por dados. Duas das soluções mais comentadas…","title":"Azure Databricks e WatsonX.data na Arena dos Heróis: Quem Leva a Melhor?"},{"content":"Depois de escrever o artigo anterior sobre migração de SAS para Databricks em formato de receita de bolo, gostei tanto da experiência que decidi repetir a ideia, mas desta vez com COBOL! Como o COBOL é uma linguagem tão antiga quanto aquelas receitas de família que passam de geração em geração, achei que seria mais divertido fazer uma receita de pavê. Afinal, COBOL e pavê são clássicos que resistem ao tempo!\nVocê já ouviu falar em COBOL? Se nunca ouviu, não se preocupe, vou te explicar! O COBOL (“Common Business-Oriented Language”) é uma das linguagens de programação mais antigas e ainda muito importantes no mundo corporativo. Criada em 1959, ela foi projetada para ser simples e eficiente em soluções de negócios, e acabou se tornando a principal escolha para sistemas de grande porte, principalmente em setores como bancos, seguros e governos.\nApesar de sua idade, o COBOL ainda roda em muitos sistemas críticos pelo mundo. Pense em sistemas que processam transações bancárias, pagamentos e registros financeiros: é bem provável que tenha um programa COBOL por trás disso. Mas, com o passar do tempo, as empresas precisam modernizar essas soluções para acompanhar novas tecnologias e demandas.\nNeste artigo, vou mostrar como você pode modernizar processos COBOL em um formato bem divertido: uma receita de pavê! Vamos ver o passo a passo, incluindo um exemplo prático de JCL e também como usar o Databricks para dar um toque moderno a tudo isso. Bora preparar esse pavê?\n🍰 Ingredientes da nossa receita: Levantamento dos processos COBOL existentes: Ferramentas essenciais: Equipe especializada: 👩🍳 Modo de preparo: Passo 1 - Entendimento e preparação do ambiente Antes de modernizar, é importante entender bem o processo atual.\nLevante os arquivos de entrada e saída: Entenda o fluxo do JCL: Verifique o programa COBOL: 👩🍳 Modo de preparo: Passo 2 - Exemplo prático de JCL com PCICDIT e VSAM Agora, vamos preparar o pavê com um exemplo prático.\nExemplo de JCL: //JOBNAME JOB (ACCT),\u0026#39;COBOL MIGRATION\u0026#39;,CLASS=A,MSGCLASS=X //STEP1 EXEC PGM=PCICDIT //INFILE DD DSN=INPUT.VSAM.FILE,DISP=SHR //OUTFILE DD DSN=OUTPUT.FLAT.FILE,DISP=(NEW,CATLG,DELETE), // SPACE=(CYL,(5,5),RLSE), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=800) //SYSPRINT DD SYSOUT=* //SYSIN DD * COMMAND=COPY INPUT=INFILE OUTPUT=OUTFILE /* Explicação do JCL: //JOBNAME JOB: Define o nome do job, a conta e as classes de execução e mensagens. //STEP1 EXEC PGM=PCICDIT: Executa o programa PCICDIT. //INFILE DD DSN=INPUT.VSAM.FILE: Especifica o arquivo de entrada, que é um arquivo VSAM. //OUTFILE DD DSN=OUTPUT.FLAT.FILE: Define o arquivo de saída como um flat file, com especificações de espaço e formato de registro. //SYSPRINT DD SYSOUT=*: Direciona a saída de log para o console. //SYSIN DD: Contém os comandos do PCICDIT, onde é especificado que o arquivo de entrada será copiado para o arquivo de saída. 👩🍳 Modo de preparo: Passo 3 - Conversão do arquivo VSAM usando Databricks Com os dados do arquivo VSAM já identificados, podemos criar um notebook Databricks para realizar a conversão desses dados para um formato moderno, como Delta Lake. Abaixo está um exemplo de código PySpark que faz essa conversão:\nExemplo de código PySpark puro: from pyspark.sql import SparkSession # Criando a sessão Spark spark = SparkSession.builder.appName(\u0026#34;VSAM_to_Delta\u0026#34;).getOrCreate() # Lendo o arquivo VSAM (simulado como um arquivo sequencial) vsam_df = spark.read.format(\u0026#34;csv\u0026#34;).option(\u0026#34;header\u0026#34;, \u0026#34;false\u0026#34;).load(\u0026#34;/mnt/input/vsam-file.txt\u0026#34;) # Definindo o esquema do arquivo VSAM vsam_df = vsam_df.withColumnRenamed(\u0026#34;_c0\u0026#34;, \u0026#34;key\u0026#34;).withColumnRenamed(\u0026#34;_c1\u0026#34;, \u0026#34;value\u0026#34;) # Gravando no formato Delta vsam_df.write.format(\u0026#34;delta\u0026#34;).mode(\u0026#34;overwrite\u0026#34;).save(\u0026#34;/mnt/output/delta-vsam\u0026#34;) print(\u0026#34;Conversão concluída com sucesso!\u0026#34;) Explicação do código: Criamos uma SparkSession: é necessária para utilizar as funcionalidades do Spark. Leitura do arquivo VSAM: aqui consideramos um arquivo de texto simulado como entrada. Definimos o esquema do DataFrame: renomeando as colunas para refletir a estrutura do VSAM. Escrita no formato Delta: o arquivo é gravado em um diretório no formato Delta Lake. Utilizando o Databricks Assistant: Você pode usar o Databricks Assistant para gerar automaticamente um notebook semelhante a este. Basta fornecer um prompt claro, como:\nPrompt sugerido: “Crie um notebook PySpark para ler um arquivo VSAM, converter para um DataFrame e gravar no formato Delta.”\nO Databricks Assistant será capaz de entender a solicitação e gerar um código base, que você pode ajustar conforme suas necessidades.\nTenho um presente: Faça o download do notebook que criei aqui !\nConclusão Seguindo essa receita de pavê, você conseguirá modernizar seus processos COBOL de forma estruturada, garantindo a continuidade dos negócios e abrindo caminho para novas soluções tecnológicas. E você, já participou de uma modernização como essa? Compartilhe nos comentários suas experiências!\nGostou do conteúdo? Deixe um like e compartilhe com quem pode estar passando por esse desafio!\n#COBOL #JCL #VSAM #Mainframe #Modernização #TransformaçãoDigital #DataEngineering\n","permalink":"https://julianamarialop.github.io/articles/como-modernizar-processos-cobol-com-databricks-uma-receita/","summary":"Depois de escrever o artigo anterior sobre migração de SAS para Databricks em formato de receita de bolo , gostei tanto da experiência que decidi repetir a ideia, mas desta vez com COBOL! Como o COBOL é uma linguagem…","title":"Como modernizar processos COBOL com Azure Databricks: Uma receita de pavê com exemplo de JCL usando PCICDIT e arquivo de entrada VSAM"},{"content":"Migrar uma plataforma consolidada como o SAS para o Databricks pode ser desafiador, mas quando seguimos uma receita de bolo bem estruturada, tudo fica mais simples e eficiente. Nesta receita, vamos dividir o processo em duas etapas principais: migração de tabelas e migração de projetos SAS. E, como gran finale, tem um presente especial ao final para facilitar ainda mais sua jornada!\n🍰 Ingredientes da nossa receita de migração: Entendimento do ambiente atual:\nLevante todas as tabelas, processos e projetos no SAS que precisam ser migrados. Identifique as dependências entre tabelas e projetos. Ferramentas certas:\nDatabricks (com suporte ao formato Delta Lake). Conectores para os bancos de dados utilizados. O Databricks Assistant (vai ser nosso assistente nessa cozinha!). Equipe preparada:\nArquiteto de Soluções. Engenheiros de Dados. Cientistas de Dados. 👩🍳 Modo de preparo: Etapa 1 - Migração de tabelas Assim como na preparação de um bolo, começamos pelos ingredientes básicos: as tabelas. Nesta etapa, o objetivo é migrar as tabelas do SAS para o Databricks utilizando o formato Delta, garantindo um armazenamento escalável e eficiente.\nPassos:\nLevante todas as tabelas que serão migradas:\nListe as tabelas existentes no SAS e identifique suas características (esquema, volume de dados, periodicidade de atualização).\nUtilize o notebook parametrizado:\nPara facilitar a migração, preparei um notebook especial que realiza a migração automática das tabelas do SAS para o formato Delta no Databricks.\nEste notebook está totalmente parametrizado e permite configurar facilmente as conexões, nomes de tabelas e diretórios de destino.\nValide a migração:\nCompare os dados migrados com os dados originais no SAS para garantir consistência e integridade.\n👩🍳 Modo de preparo: Etapa 2 - Migração de projetos SAS Agora que as tabelas estão prontas, é hora de migrar os projetos SAS. Esse passo é como adicionar a cobertura ao bolo: é aqui que os processos de ETL e os códigos SAS serão convertidos e adaptados para o Databricks.\nPassos:\nListe os projetos SAS:\nIdentifique todos os processos e códigos SAS que precisam ser migrados. Priorize os mais críticos.\nUse o Databricks Assistant para converter o código:\nPegue os códigos SAS já prontos e insira-os no Databricks Assistant.\nSolicite ao Assistant que converta os códigos para SQL ou PySpark, dependendo da necessidade.\nEssa funcionalidade permite transformar rapidamente o código SAS em um formato que o Databricks compreenda, reduzindo drasticamente o tempo de migração.\nImplemente e teste os projetos migrados:\nExecute os códigos convertidos e valide os resultados.\nCertifique-se de que os novos processos estão produzindo os mesmos resultados esperados no SAS.\n🎂 Gran Finale: Presente especial! Para ajudar ainda mais nessa jornada de migração, preparei um notebook pronto e totalmente parametrizado para migrar as tabelas do SAS para o formato Delta. Esse notebook permite:\nConfigurar rapidamente a fonte de dados SAS e o destino no Databricks. Executar a migração de forma automática e eficiente. Garantir que todas as tabelas estejam no formato Delta, prontas para serem utilizadas nos novos projetos. Quer o notebook? Basta copiar esse código python abaixo !\nSe você preferir faça o download do notebook.\n# Cell 1: Criar widgets de comando para os parâmetros de entrada dbutils.widgets.text(\u0026#34;sas_file_dir\u0026#34;, \u0026#34;/caminho/para/seu/diretorio\u0026#34;, \u0026#34;SAS File Directory\u0026#34;) dbutils.widgets.text(\u0026#34;sas_file_name\u0026#34;, \u0026#34;\u0026#34;, \u0026#34;SAS File Name (optional)\u0026#34;) dbutils.widgets.text(\u0026#34;catalog\u0026#34;, \u0026#34;seu_catalogo\u0026#34;, \u0026#34;Catalog\u0026#34;) dbutils.widgets.text(\u0026#34;schema\u0026#34;, \u0026#34;seu_schema\u0026#34;, \u0026#34;Schema\u0026#34;) dbutils.widgets.text(\u0026#34;table_name\u0026#34;, \u0026#34;\u0026#34;, \u0026#34;Table Name (optional)\u0026#34;) # Cell 2: Obter os valores dos widgets sas_file_dir = dbutils.widgets.get(\u0026#34;sas_file_dir\u0026#34;) sas_file_name = dbutils.widgets.get(\u0026#34;sas_file_name\u0026#34;) catalog = dbutils.widgets.get(\u0026#34;catalog\u0026#34;) schema = dbutils.widgets.get(\u0026#34;schema\u0026#34;) table_name = dbutils.widgets.get(\u0026#34;table_name\u0026#34;) # Função para carregar e salvar um arquivo SAS como tabela Delta def load_and_save_sas_file(sas_file_path, catalog, schema, table_name): # Carregar o arquivo SAS em um DataFrame df = spark.read.format(\u0026#34;com.github.saurfang.sas.spark\u0026#34;) \\ .load(sas_file_path) # Exibir o DataFrame carregado display(df) # Especificar o caminho Delta delta_path = f\u0026#34;/mnt/delta/{catalog}/{schema}/{table_name}\u0026#34; # Escrever o DataFrame como uma tabela Delta df.write.format(\u0026#34;delta\u0026#34;) \\ .mode(\u0026#34;overwrite\u0026#34;) \\ .save(delta_path) # Criar a tabela Delta no catálogo especificado spark.sql(f\u0026#34;\u0026#34;\u0026#34; CREATE TABLE {catalog}.{schema}.{table_name} USING DELTA LOCATION \u0026#39;{delta_path}\u0026#39; \u0026#34;\u0026#34;\u0026#34;) # Verificar se um nome de arquivo específico foi fornecido if sas_file_name: # Construir o caminho completo do arquivo SAS sas_file_path = f\u0026#34;{sas_file_dir}/{sas_file_name}\u0026#34; # Usar o nome da tabela fornecido ou derivar do nome do arquivo table_name = table_name if table_name else sas_file_name.split(\u0026#34;.\u0026#34;)[0] # Carregar e salvar o arquivo SAS load_and_save_sas_file(sas_file_path, catalog, schema, table_name) else: # Listar todos os arquivos SAS no diretório files = dbutils.fs.ls(sas_file_dir) sas_files = [f.path for f in files if f.path.endswith(\u0026#34;.sas7bdat\u0026#34;)] # Carregar e salvar cada arquivo SAS for sas_file_path in sas_files: # Derivar o nome da tabela do nome do arquivo table_name = sas_file_path.split(\u0026#34;/\u0026#34;)[-1].split(\u0026#34;.\u0026#34;)[0] load_and_save_sas_file(sas_file_path, catalog, schema, table_name) Conclusão Seguindo essa receita de bolo, você terá uma migração tranquila e eficiente, com uma plataforma moderna e escalável pronta para atender às novas demandas do seu negócio. Lembre-se: o segredo de uma boa migração está em planejar bem cada etapa e contar com as ferramentas certas.\nE você, já participou de uma migração como essa? Quais foram os principais desafios? Compartilhe nos comentários! Vamos trocar experiências!\n","permalink":"https://julianamarialop.github.io/articles/como-migrar-do-sas-para-databricks-uma-receita-de-bolo/","summary":"Migrar uma plataforma consolidada como o SAS para o Databricks pode ser desafiador, mas quando seguimos uma receita de bolo bem estruturada, tudo fica mais simples e eficiente. Nesta receita, vamos dividir o processo em…","title":"Como migrar do SAS para Azure Databricks: Uma receita de bolo infalível em 2 etapas"},{"content":"Que tal comparar os erros que sabotam seus pipelines de dados com vilões que vivem atrapalhando a missão dos super-heróis? Imagine que seu pipeline é o herói da história, encarregado de levar os dados até o destino final, onde eles se transformarão em insights valiosos para salvar o dia. Mas, como em toda boa história, há vilões no caminho prontos para atrapalhar sua missão. Vamos conhecer os 5 vilões e como derrotá-los usando suas armas secretas: boas práticas e a plataforma Databricks .\nVilão 1: Caos da Ingestão – O Mestre da Desordem Descrição do vilão: Este vilão surge quando você precisa lidar com múltiplas fontes de dados com formatos variados (JSON, CSV, Parquet, XML, etc.) e sem padronização. Ele causa desorganização no pipeline, o que torna a manutenção difícil e aumenta a chance de erros durante a ingestão e transformação dos dados.\nSinais de que ele está atacando: Ingestão de dados inconsistente entre diferentes fontes. Alto esforço manual para tratar dados em formatos diferentes. Reprocessamento frequente devido a falhas no pipeline de ingestão. Como vencê-lo no Databricks: Adote a Medallion Architecture: Bronze Layer: armazene os dados brutos, exatamente como foram recebidos. Silver Layer: normalize os dados, padronizando formatos, corrigindo inconsistências e deduplicando. Gold Layer: aplique transformações finais, criando dados prontos para consumo analítico. Use Delta Lake para ingestão confiável: Utilize Delta Tables para armazenar cada camada de dados com suporte a versionamento e controle transacional. Isso garante consistência, mesmo em caso de falhas. Automatize a ingestão com Auto Loader: O Databricks Auto Loader detecta automaticamente novos arquivos e faz a ingestão incremental, reduzindo a necessidade de intervenções manuais. Vilão 2: O Silencioso – O Sabotador Invisível Descrição do vilão: O Silencioso age sem ser notado. Ele causa falhas nos pipelines ou lentidão no processamento sem que você perceba a tempo de corrigir. Como resultado, relatórios ficam desatualizados ou inconsistentes, e ninguém sabe por quê.\nSinais de que ele está atacando: Jobs que falham sem alertas. Atrasos nos relatórios devido a falhas não identificadas. Falta de visibilidade sobre o status dos pipelines. Como vencê-lo no Databricks: Implemente monitoramento de jobs: Configure o Databricks Job Monitoring para acompanhar a execução de todos os jobs. Ele oferece uma visão detalhada das execuções, tempos de processamento e falhas. Configure alertas automáticos: Utilize o Databricks Alerts para disparar notificações por e-mail ou Slack sempre que ocorrer uma falha ou quando o tempo de execução de um job ultrapassar um limite definido. Use dashboards de monitoramento: Crie dashboards no Databricks que exibam métricas críticas, como o tempo médio de execução de cada etapa do pipeline, status dos jobs e falhas recentes. Vilão 3: O Enganador Complexo – O Lorde das Tarefas Gigantes Descrição do vilão: Este vilão adora transformar tarefas simples em blocos gigantes de código. Ele cria scripts monolíticos e complexos que misturam várias transformações em uma única etapa, dificultando a depuração e manutenção do pipeline.\nSinais de que ele está atacando: Pipelines difíceis de entender e manter. Qualquer falha exige o reprocessamento completo do pipeline. Dificuldade em depurar erros devido à complexidade do código. Como vencê-lo no Databricks: Divida as transformações em etapas menores: Crie notebooks modulares, onde cada notebook trata uma parte específica do pipeline. Isso torna o código mais organizado e fácil de manter. Use Delta Tables para salvar estados intermediários: Após cada etapa de transformação, salve os dados em uma Delta Table intermediária. Se ocorrer uma falha, você poderá reiniciar o pipeline a partir da última etapa bem-sucedida, em vez de reprocessar tudo. Implemente Checkpoints: Use Spark Checkpoints para salvar o estado de processamento durante a execução de jobs de longa duração. Isso melhora a resiliência do pipeline e facilita a recuperação em caso de falhas. Vilão 4: O Gigante Ineficiente – O Monstro do Crescimento Descrição do vilão: Este vilão é o terror da escalabilidade. Ele se manifesta quando o volume de dados aumenta, mas seu pipeline não foi projetado para lidar com esse crescimento. O resultado? Lentidão extrema, falhas frequentes e custos elevados com infraestrutura.\nSinais de que ele está atacando: Aumento exponencial no tempo de execução dos pipelines. Custos de infraestrutura muito altos. Falhas frequentes em pipelines que lidam com grandes volumes de dados. Como vencê-lo no Databricks: Habilite Auto Scaling: Configure clusters com Auto Scaling, permitindo que o Databricks ajuste automaticamente o número de nós conforme a demanda. Isso garante eficiência e economia de recursos. Otimize a leitura e escrita com formatos eficientes: Utilize formatos de armazenamento otimizados, como Parquet e Delta Lake, que permitem leitura e escrita mais rápidas em grandes volumes de dados. Particione seus dados: Ao trabalhar com grandes datasets, sempre use particionamento adequado para evitar a leitura de dados desnecessários. Vilão 5: Dados Mutantes – O Desestabilizador Descrição do vilão: Esse vilão adora corromper os dados ao longo do pipeline, introduzindo valores inconsistentes, nulos ou fora do padrão esperado. Ele faz com que relatórios e modelos preditivos entreguem resultados errados.\nSinais de que ele está atacando: Dados inconsistentes nos relatórios. Modelos de machine learning com baixa acurácia devido a dados de má qualidade. Retrabalho constante para corrigir erros após o processamento. Como vencê-lo no Databricks: Defina regras de qualidade com Delta Expectations: Use Delta Expectations para criar regras de validação, como obrigatoriedade de determinados campos e limites de valores. Se os dados não atenderem aos critérios, o Databricks sinaliza o erro antes que ele avance para a próxima etapa. Implemente testes automatizados de qualidade de dados: Automatize a validação dos dados usando bibliotecas como Deequ ou frameworks de testes integrados ao Databricks. Configure testes que verifiquem formatos, ranges e valores críticos. Realize auditorias periódicas: Programe jobs de auditoria que revisem a qualidade dos dados já processados e armazenados, garantindo que os dados históricos mantenham a consistência. Conclusão: Monte Sua Liga de Heróis e Domine o Jogo dos Dados Com esses vilões derrotados, seus pipelines estarão prontos para entregar dados confiáveis, de alta qualidade e prontos para impulsionar decisões estratégicas. Usando as ferramentas e boas práticas do Databricks, você não apenas derrota os vilões, mas também transforma seus pipelines em verdadeiros super-heróis, capazes de enfrentar qualquer desafio de dados.\nEstá pronto para liderar sua própria liga de super-heróis da engenharia de dados?\nObrigada pela leitura !\n","permalink":"https://julianamarialop.github.io/articles/transforme-seus-pipelines-em-super-herois-os-5-viloes/","summary":"Que tal comparar os erros que sabotam seus pipelines de dados com vilões que vivem atrapalhando a missão dos super-heróis? Imagine que seu pipeline é o herói da história, encarregado de levar os dados até o destino…","title":"Transforme seus Pipelines em Super-Heróis: Os 5 Vilões que Sabotam sua Jornada de Dados e Como Vencê-los com Azure Databricks"},{"content":"Com o avanço do armazenamento de dados em nuvem, trabalhar com dados ficou muito mais acessível, tanto em termos de tempo quanto de custo. Ferramentas como Databricks e Microsoft Fabric ajudaram a derrubar essas barreiras, oferecendo recursos inovadores, como clonagem sem consumo de espaço adicional e armazéns escaláveis, que permitem a criação rápida de protótipos.\nEssas reduções nos custos de armazenamento e processamento tornaram os ajustes de design menos impactantes e mais fáceis de lidar do que no passado. Por isso, muitos engenheiros de dados acabam pulando a fase de modelagem dimensional e seguem direto para as transformações, ajustando o modelo conforme necessário.\nNo entanto, essa abordagem funciona melhor apenas no início de um projeto. À medida que os dados são carregados e dependências são criadas em torno das tabelas principais, alterar o modelo de dados pode se tornar algo tão caro e complexo que inviabiliza mudanças.\nEssa situação pode ser comparada ao filme The Lost World: assim como no filme, onde explorar o \u0026ldquo;mundo perdido\u0026rdquo; traz à tona o valor de algo esquecido, a modelagem dimensional representa uma prática que pode parecer obsoleta, mas é essencial para o sucesso a longo prazo. Redescobrir e aplicar seus fundamentos pode ser o diferencial entre um projeto sustentável e um cheio de obstáculos.\nMesmo com os custos de armazenamento e computação em queda constante, o princípio de que 20% de esforço no design inicial economizam 80% de retrabalho no futuro ainda se mantém firme. Investir na modelagem desde o começo é uma estratégia que compensa.\nEm resumo, por mais que a tecnologia evolua, os fundamentos da modelagem dimensional continuam sendo indispensáveis. Assim como o \u0026ldquo;mundo perdido\u0026rdquo;, esses princípios estão prontos para serem redescobertos e valorizados. 😊\nPré-requisitos Antes de começar o trabalho em si, é importante definir algumas diretrizes logo no início para garantir que o projeto siga o caminho certo.\nBoas práticas como criar convenções claras para nomes de tabelas e colunas e definir quem será responsável pelas entregas são estratégias bem conhecidas para reduzir a complexidade e manter o projeto fluindo sem problemas. No entanto, outras considerações menos óbvias muitas vezes acabam sendo negligenciadas.\nA modelagem de dados, por sua natureza, se baseia em padrões – na maioria das vezes, não é necessário “reinventar a roda”. Por isso, tanto para facilitar a comunicação quanto para economizar tempo, é essencial estar familiarizado com os termos e padrões amplamente utilizados.\nIsso inclui desde os fundamentos (como fatos, dimensões e medidas), até conceitos mais avançados (como SCDs tipo II, upserts e dimensões degeneradas), além de quaisquer convenções específicas que a equipe adotar ao longo do projeto.\nPara garantir que os conceitos principais estejam sempre frescos na memória, vale a pena ter por perto uma cópia do clássico Data Warehouse Toolkit de Ralph Kimball. Se preferir, você também pode consultar o site dele, que oferece um resumo prático dos principais termos e conceitos.\nUma fonte de verdade A modelagem dimensional, como veremos mais adiante, é um processo colaborativo e iterativo. Isso significa que pessoas de diferentes áreas da organização precisam trabalhar juntas para criar uma solução que não apenas atenda aos requisitos de negócios, mas também seja eficiente e sustentável a longo prazo.\nCom tantas pessoas envolvidas no design, mudanças e ajustes ao longo do caminho são inevitáveis. Por isso, é fundamental usar uma ferramenta que facilite essa colaboração durante todo o ciclo de vida do projeto — permitindo trabalho em tempo real, compartilhamento dinâmico, rastreamento de alterações e evitando documentos desatualizados ou silos de conhecimento.\nNeste artigo, vou usar o SqlDBM, uma ferramenta de modelagem online, para ilustrar o processo. O SqlDBM é flexível o suficiente para começar com um design inicial, estilo “quadro branco”. Diferentemente de ferramentas de diagramação tradicionais (como Lucidchart ou Vizio), o SqlDBM também gera código DDL bem formatado, específico para o banco de dados escolhido, conforme o modelo evolui, poupando retrabalho.\nCom o SqlDBM, o mapa realmente se torna o território. 😊\nO processo Neste artigo, vamos explorar o processo de vendas de uma empresa de varejo, percorrendo as principais etapas da modelagem dimensional.\n1. Escolha o processo de negócios A primeira etapa é escolher um único processo de negócios para modelar. Pode parecer simples, mas essa decisão merece atenção. Tentar criar todo o data warehouse de uma só vez é um erro comum – o ideal é construir um processo de negócios por vez.\nA escolha deve ser guiada pelas prioridades da empresa, considerando relevância e urgência em relação a outros processos. A equipe de BI pode ajudar com estimativas técnicas, mas as necessidades do negócio devem ser o fator decisivo.\nNesse ponto, a equipe de BI deve se reunir com especialistas do negócio e realizar um levantamento inicial dos dados. Isso ajuda a criar uma proposta técnica de alto nível, útil para definir orçamento e cronograma.\n2. Defina o grão Depois de selecionar o processo de negócios, é hora de definir o grão – ou seja, o nível mínimo de detalhe no qual os dados serão analisados. Novamente, essa é uma decisão orientada pelos objetivos do negócio.\nPor exemplo, em um varejista online, podemos rastrear detalhes extremamente específicos, como a identificação do dispositivo e o sistema operacional de cada pedido. Esses dados podem ser úteis para marketing, mas talvez não agreguem valor ao monitoramento geral de vendas.\nSe a empresa decidir que as vendas devem ser analisadas \u0026ldquo;diariamente por tipo de produto\u0026rdquo;, esse será o grão mínimo. Ele define o que cada linha da tabela de fatos representa e deve ser tratado como um compromisso com as partes interessadas, pois mudanças posteriores podem exigir retrabalho significativo.\nMesmo definindo uma granularidade específica, sempre colete os dados de origem no nível mais detalhado possível, seguindo o padrão ELT (extrair, carregar, transformar). Assim, se amanhã a análise precisar de mais detalhes, como \u0026ldquo;por hora por ID de produto\u0026rdquo;, você já terá os dados necessários.\n3. Identifique as dimensões Com o grão definido, o próximo passo é identificar as dimensões que darão suporte à análise. Algumas dimensões principais podem já ter sido identificadas durante a escolha do processo de negócios. Agora é hora de aprofundar essa análise.\nDurante essa etapa, também podem surgir dimensões compartilhadas entre diferentes processos de negócios, criando a base para a matriz dimensional da empresa.\nMesmo que o foco inicial seja apenas um processo (como vendas no varejo), a matriz dimensional é uma ferramenta valiosa para mapear processos correlacionados e destacar dimensões em comum. Isso ajuda a manter o design consistente e escalável para futuras expansões.\n_Amostra de matriz dimensional_\nUma dimensão geralmente é representada por um substantivo, como loja, funcionário ou veículo. Esses substantivos vêm acompanhados de atributos, como nome, descrição ou endereço, que ajudam a enriquecer e contextualizar os relatórios.\nDepois de identificar as dimensões existentes, podemos começar a esboçar um quadro branco básico. Esse rascunho servirá como ponto de partida para adicionar mais detalhes nas próximas etapas do processo.\n_Identificando dimensões no SqlDBM por meio de modelagem lógica_\n4. Identifique os relacionamentos de dimensão Depois de identificar as dimensões, o próximo passo é entender como elas se conectam e interagem entre si.\nPor exemplo:\nAs promoções são aplicadas ao nível da loja, do produto ou ambos? Um funcionário está vinculado a uma loja específica ou pode trabalhar em várias? Essas perguntas guiam o design técnico, mas as respostas dependem diretamente do conhecimento dos especialistas do negócio. Por isso, é fundamental manter esses especialistas envolvidos durante todo o processo de modelagem, garantindo que dúvidas funcionais sejam esclarecidas assim que surgirem.\nEntão, as promoções são aplicadas ao nível do produto? 🤔\n_promoção no nível do produto_\nEntão, as promoções são aplicadas ao nível do produto? Ou abrangem toda a loja? 🤔\n_promoção em nível de loja_\nA modelagem lógica oferece uma maneira simplificada de visualizar o design, permitindo prototipagem rápida antes de avançar para o design físico. Essa abordagem torna o processo mais acessível, permitindo que membros não técnicos da equipe participem ativamente das discussões.\nNeste exemplo, vamos optar pela última alternativa: aplicar as promoções ao nível da loja. 🎯\n5. Identifique os fatos A etapa seguinte combina as dimensões já identificadas (o quê, quando) com medidas quantitativas (quanto, quantos), resultando nos fatos do modelo.\nPor exemplo:\nO cliente A comprou X unidades do produto B ao preço de Y dólares, atendido pelo funcionário D, na loja E, usando a promoção F, na data G. Essa combinação de dimensões e medidas quantitativas forma a tabela de fatos para o processo de vendas no varejo. Ela será o coração da análise, conectando os detalhes do negócio às métricas que realmente importam.\n_a tabela de fatos do processo de negócios de vendas no varejo com dimensões associadas_\nCom esta tabela de fatos, conseguimos responder a qualquer pergunta comercial relacionada às vendas no varejo, utilizando uma combinação de filtros e agregações.\nAlém disso, podemos expandir o diagrama para incluir detalhes técnicos importantes, como chaves primárias e estrangeiras, garantindo que o modelo seja funcional e eficiente.\nPor exemplo, se a empresa quiser saber as vendas mensais por loja do produto B, basta aplicar os filtros e somar os valores relevantes na tabela de fatos. Fácil, não é? 😊\nSELECT store_id, date_trunc(\u0026#39; MONTH \u0026#39;, datekey) como sale_month, sum(price) como Monthly_sales_usd FROM fct_retail_sales WHERE productkey = \u0026#39;B\u0026#39; GROUP BY store_id, datekey Isso também pode ser realizado diretamente dentro do próprio projeto, aproveitando as funcionalidades da tabela de fatos para filtrar e agregar os dados conforme necessário.\nDefinir um nível de detalhe muito granular para a tabela de fatos permite flexibilidade: podemos sempre agregar para níveis mais simples, como resumos mensais ou semanais. Porém, o oposto não é possível. Por exemplo, se a tabela de fatos fosse criada no nível mensal, não seria viável obter detalhes diários. Essa escolha inicial é crucial para garantir a flexibilidade do modelo.\n6. Implantação Com os fatos, medidas, grãos e relacionamentos definidos e acordados, finalmente é hora de ir ao banco de dados e criar os objetos físicos.\nNesta etapa, é fundamental garantir que todos os detalhes técnicos e funcionais documentados durante o exercício de modelagem sejam seguidos, como:\nComprimentos de colunas; Tipos de dados; Propriedades das tabelas. Esse cuidado garante que o modelo atenda às expectativas e funcione perfeitamente na prática. 🎯\nSe você estiver usando o SqlDBM para acompanhar, pode gerar o DDL necessário diretamente a partir do diagrama (lembra da ideia de \u0026ldquo;o mapa se torna o território\u0026rdquo;?).\nCaso opte por usar o Excel, também é possível criar fórmulas para gerar o SQL com base nos detalhes inseridos.\nIndependentemente da ferramenta escolhida, o mais importante é garantir que o design esteja sempre alinhado e sincronizado com os detalhes técnicos. Isso evita inconsistências e garante um modelo funcional e eficiente.\nConclusão Após percorrer as etapas do processo de modelagem dimensional, fica claro que se trata de um esforço iterativo e colaborativo, onde mudanças nos requisitos e decisões de design são praticamente inevitáveis.\nPara que o projeto continue fluindo de forma tranquila, é essencial utilizar ferramentas e métodos que possam lidar bem com essas alterações, mantendo todos os envolvidos alinhados e sincronizados.\nUma vez definidos os instrumentos e processos, a modelagem se torna um exercício repetível e baseado em padrões. Por isso, escolha suas ferramentas com sabedoria, modele e continue iterando.\nObrigado por acompanhar este artigo até o final! Espero que ele tenha sido útil para esclarecer o processo de modelagem dimensional e como aplicá-lo de forma prática. Se você gostou do conteúdo, convido você a explorar outros artigos e materiais que compartilho sobre o universo de dados e análises. Fique à vontade para deixar seus comentários, dúvidas ou sugestões – sua participação é sempre muito bem-vinda! 😊\n","permalink":"https://julianamarialop.github.io/articles/lost-world-resgatando-arte-perdida-da-modelagem-um-guia/","summary":"Com o avanço do armazenamento de dados em nuvem, trabalhar com dados ficou muito mais acessível, tanto em termos de tempo quanto de custo. Ferramentas como Databricks e Microsoft Fabric ajudaram a derrubar essas…","title":"The Lost World - Resgatando a Arte Perdida da Modelagem Dimensional: Um Guia Prático"},{"content":"Introdução Imagine poder conversar com seus dados como se estivesse falando com um colega de trabalho ou, melhor ainda, como se estivesse interagindo com um gênio da lâmpada mágica. É exatamente isso que o AI/BI Genie permite! Assim como o lendário gênio que realiza desejos, o Genie facilita a vida dos usuários de negócios, permitindo que eles “esfreguem a lâmpada” de seus dados para obter respostas e insights por meio de linguagem natural, da mesma forma que falamos no dia a dia.\nO Genie é uma solução inovadora desenvolvida pela Databricks para simplificar o acesso e a análise de dados de maneira mágica, através de interações em linguagem natural. Lançado em 2024, o AI/BI Genie faz parte dos avanços da Databricks em inteligência artificial generativa (GenAI) aplicada à análise de dados. Assim como o gênio de Aladdin, ele está aqui para democratizar o uso de dados, permitindo que qualquer pessoa na organização possa fazer perguntas complexas sem precisar escrever uma única linha de código.\nO segredo por trás do Genie está no Unity Catalog, que funciona como o “mapa” mágico para entender a estrutura dos seus dados. Isso inclui desde a origem dos dados (linhagem), passando pela documentação, até o histórico de consultas já realizadas. Com essas informações, o Genie é capaz de responder uma grande variedade de perguntas de negócios, de forma rápida e confiável.\nAssim como na história clássica, o Genie do Databricks não tem limites de desejos. Ele combina a simplicidade da linguagem natural com a confiabilidade da inteligência artificial generativa (GenAI), tornando o acesso a dados e à inteligência artificial mais democrático do que nunca, tudo sob a governança unificada da plataforma Databricks Data Intelligence.\nConfiguração e utilização do AI/BI Genie Os espaços do Genie são preparados por analistas de dados para garantir uma experiência mais fluida e precisa. O processo começa com a seleção de tabelas específicas do Unity Catalog, focando em um conjunto de dados que tenha sentido para a organização. Em seguida, os analistas expõem os metadados dessas tabelas e inserem instruções que trazem informações específicas do negócio, como regras de negócio e conceitos importantes para o contexto do usuário. Para facilitar ainda mais, os analistas também adicionam exemplos de perguntas e respostas, ajudando os usuários de negócios a dar os primeiros passos de maneira orientada e segura.\n_Fluxo de criação e utilização dos espaços do Genie_\nNa imagem acima, você pode ver o fluxo de criação e utilização dos espaços do Genie, dividido em três partes principais: a equipe de dados, o espaço do Genie e os usuários de negócios. Ela ilustra todo o ciclo, desde a configuração do espaço pelo time de dados até a interação dos usuários finais, com destaque para a troca de feedbacks e o uso de linguagem natural para perguntas e respostas. Esse fluxo mostra como o Genie é alimentado por dados confiáveis e exemplos práticos, tudo projetado para oferecer insights de maneira simples e acessível.\nDando sequencia a explicação, abaixo temos as melhores práticas para a criação e utilização dos espaços do Genie listadas e explicadas para guiar a configuração ideal desse ambiente de análise.\nEscolhendo os conjuntos de dados Para começar a usar o Genie de forma eficiente, é ideal trabalhar com um pequeno conjunto de tabelas (entre 5 e 10), com um número limitado de colunas (menos de 50), focando em um único tema. Mas por que começar assim? Porque quanto mais coerente e semanticamente conectado for o seu conjunto de dados, melhor será o desempenho do Genie.\nO que significa um conjunto de dados coerente e semanticamente conectado? Isso quer dizer que o relacionamento entre as tabelas deve refletir conexões reais ou associações lógicas. Por exemplo, as tabelas devem estar relacionadas de maneira clara, como acontece em um banco de dados do mundo real, e ter restrições de chave primária e chave estrangeira, para que o Genie entenda como as tabelas estão conectadas e possa realizar junções de forma correta.\nTodas as tabelas e colunas devem contribuir para o tema geral do conjunto de dados. Se houver colunas que não estejam alinhadas com o propósito do conjunto, é importante criar views para limpar e tornar os dados mais coerentes e organizados.\nEm geral, os dados utilizados nos espaços do Genie vêm de tabelas de nível de negócios da camada gold, similares aos dados que seriam usados em uma ferramenta de BI para construir dashboards. Isso é feito frequentemente usando um esquema estrela no estilo Kimball, um modelo multidimensional que facilita o entendimento e a análise dos dados.\nPor fim, garanta que todos os usuários que interagirem com o espaço do Genie tenham, no mínimo, privilégios de SELECT nos dados utilizados. Como o acesso aos dados é governado pelo Unity Catalog, a falta de privilégios resultará em mensagens de erro para os usuários.\nDocumentação Clara, Respostas Precisas: Preparando o AI/BI Genie para o Sucesso Para o Genie funcionar de forma eficaz, é essencial que seus dados estejam bem documentados e anotados. A documentação é fundamental porque ela traz o contexto de negócios para os dados, facilitando o entendimento e evitando interpretações incorretas — tanto por parte dos usuários quanto do próprio Genie. Simplificando: quanto mais claras e detalhadas forem suas anotações, melhores serão as respostas que o Genie poderá oferecer.\nVocê pode usar ferramentas de inteligência artificial para gerar parte dessa documentação automaticamente, economizando tempo e reduzindo o trabalho manual. Mesmo assim, é importante revisar e ajustar as descrições para que estejam de acordo com o caso de uso específico e o conhecimento do seu domínio. Uma documentação bem feita não apenas facilita o uso, mas também garante que as respostas do Genie sejam mais precisas e relevantes para os objetivos do seu negócio.\nDo Natural ao SQL: Como Preparar o Genie para Consultas Eficientes Durante a preparação do espaço do Genie, é essencial testá-lo para verificar a qualidade das respostas e garantir que ele está entregando os resultados esperados. Isso inclui reformular as perguntas de exemplo e ajustar as instruções até que o Genie forneça as respostas corretas e desejadas.\nO Genie converte as perguntas em linguagem natural para SQL, o que significa que ele precisa de um SQL warehouse para executar as consultas. Para melhores resultados, recomendamos o uso de um SQL warehouse serverless, pois ele oferece um tempo de inicialização mais rápido e uma gestão inteligente das cargas de trabalho, o que permite processar as consultas de forma ágil e econômica.\nLembre-se de que os usuários que interagem com o espaço precisam ter acesso \u0026ldquo;CAN USE\u0026rdquo; ao SQL warehouse designado, garantindo assim que possam executar as consultas sem problemas.\nMelhorando a qualidade das respostas Para melhorar a qualidade das respostas do Genie, é essencial transferir todo o contexto de negócios que você possui sobre os dados para informações que o Genie possa utilizar de forma eficaz. Atualmente, existem três maneiras de fazer isso:\nInstruções: Adicione semântica extra utilizando linguagem natural para que o Genie compreenda melhor os conceitos e relacionamentos específicos do seu negócio. Exemplos de SQL: Forneça exemplos de consultas SQL que orientem o Genie sobre como consultar seus dados e obter as informações corretas. Isso ajuda a alinhar as respostas com o que você espera em termos de lógica de negócio. Assets Confiáveis: Crie consultas pré-definidas que estabeleçam uma “versão única da verdade”, garantindo que os resultados sejam consistentes e confiáveis em todas as interações. Essas práticas não apenas aumentam a precisão das respostas, mas também garantem que o Genie esteja alinhado com os objetivos do negócio, proporcionando resultados mais relevantes para os usuários.\nExemplo: transfira a linguagem do seu negócio para o Genie As instruções permitem que você forneça informações adicionais para ajudar o Genie a entender a linguagem específica do seu negócio. Elas orientam o modelo de linguagem a captar jargões da empresa ou conceitos específicos de um determinado domínio.\nPor exemplo, na Databricks, o nosso ano fiscal começa em fevereiro, diferentemente da maioria das empresas, que inicia em janeiro. Portanto, é necessário adicionar esse detalhe como uma instrução para o Genie, garantindo que ele agregue os números corretamente:\nO ano fiscal começa em fevereiro. Outra possibilidade é instruir o Genie sobre como aplicar lógica de filtro ou buscar valores nas colunas, especialmente quando algumas são sensíveis a maiúsculas e minúsculas:\nSempre converter strings para minúsculas e usar o operador \u0026ldquo;like\u0026rdquo; ao aplicar filtros. Os países na coluna “country_code” estão armazenados com dois caracteres (ex.: US, AT). Você também pode utilizar técnicas de \u0026ldquo;aprendizado em um exemplo\u0026rdquo; para ensinar o Genie sobre como tratar colunas específicas e extrair informações delas:\nA coluna “People_Name” está no formato “Nome PrimeiroMeio, Sobrenome”. Se o conteúdo da coluna for “Francis Ford, Coppola”, então o Nome = Francis, o PrimeiroMeio = Ford, e o Sobrenome = Coppola. Certifique-se de que suas instruções sejam claras e objetivas. O mesmo se aplica aos dados: quanto mais coerentes e simples forem as instruções, melhores serão os resultados fornecidos pelo Genie.\nAssets Confiáveis: consultas pré-definidas para perguntas específicas Para entender melhor a diferença entre Assets Confiáveis e Exemplos de SQL, vamos usar uma analogia simples: imagine que você está ensinando um aluno a resolver problemas de multiplicação.\nPrimeiro, você ensina multiplicações básicas, como 2 * 3, que ele geralmente memoriza. Mais tarde, você ensina ferramentas para resolver multiplicações mais complexas, como 123*64. O aluno tende a memorizar multiplicações recorrentes, como 8 * 8 = 64, mas também aprende as ferramentas para calcular multiplicações mais complexas de forma independente.\nOs Assets Confiáveis são consultas definidas pelo usuário que são executadas para perguntas específicas. O Genie executa a consulta pré-definida e fornece o resultado com uma etiqueta de “asset confiável”. A associação entre os Assets Confiáveis e perguntas específicas é feita por meio de comentários de função. Na nossa analogia, isso seria semelhante a memorizar o resultado de 8 * 8 sem precisar refazer o cálculo.\n1. Crie um Asset confiável Vamos a outro exemplo, vamos supor que você precise converter preços de cerveja de euros (EUR) para dólares americanos (USD). Você pode criar uma consulta pré-definida que realize essa conversão e associá-la a uma pergunta específica, garantindo que o Genie forneça sempre a resposta correta com o selo de \u0026ldquo;asset confiável\u0026rdquo;, sem recalcular todas as vezes.\nSELECT o.year, o.beer_price, (o.beer_price * e.EUR2USD) AS beer_price_usd FROM main.default.oktoberfest_gold o JOIN main.default.eur_usd_conversion e ON o.year = e.Year WHERE o.year = 2005 Esses Assets Confiáveis garantem consistência e precisão nas respostas para perguntas recorrentes, economizando tempo e oferecendo maior confiabilidade para o usuário.\n2. Registre a consulta generalizada (adicionando o filtro como parâmetro) como uma Função Para tornar a consulta mais flexível e adaptável a diferentes cenários, você pode registrá-la como uma função SQL, permitindo que os filtros sejam passados como parâmetros. Isso facilita a reutilização da consulta em várias situações, mantendo o resultado sempre consistente e confiável.\nVamos usar o exemplo da conversão de preços de cerveja de euros para dólares, mas agora com um filtro como parâmetro. Assim, o usuário pode escolher filtrar por um tipo específico de cerveja, por exemplo:\nCREATE OR REPLACE FUNCTION convert_beer_price_to_usd(beer_filter STRING) RETURNS TABLE\u0026lt;beer_name STRING, price_eur DECIMAL(10,2), price_usd DECIMAL(10,2)\u0026gt; AS SELECT beer_name, price_eur, (price_eur * exchange_rate_usd) AS price_usd FROM beer_prices WHERE beer_name LIKE CONCAT(\u0026#39;%\u0026#39;, beer_filter, \u0026#39;%\u0026#39;); Neste exemplo, a função convert_beer_price_to_usd aceita um parâmetro chamado beer_filter, que pode ser usado para buscar cervejas específicas na coluna beer_name. Assim, o Genie pode executar a consulta ajustada de acordo com o filtro fornecido pelo usuário, tornando o processo mais dinâmico e eficiente.\nOs Assets Confiáveis associados a essa função permitirão que o Genie forneça respostas mais precisas e ágeis para perguntas específicas sobre preços de cerveja, mantendo a consistência das respostas.\n3. Adicione a função registrada como um Asset Confiável Para tornar a função de conversão de preços de cerveja um Asset Confiável no Genie, você precisa registrá-la como tal. Isso garante que o Genie possa utilizar a função para responder perguntas específicas de maneira rápida e consistente, sinalizando o resultado com o selo de \u0026ldquo;Asset Confiável\u0026rdquo;.\n4. Recuperar resultados confiáveis para perguntas Depois de adicionar a função de conversão de preços de cerveja como um Asset Confiável, você pode utilizar o Genie para recuperar os resultados confiáveis quando uma pergunta específica for feita. Isso garante que o Genie usará a consulta pré-definida, retornando resultados precisos e marcados como “confiáveis”.\nPor exemplo, ao fazer uma pergunta como:\n\u0026ldquo;Qual é o preço da cerveja Guinness convertido para USD?\u0026rdquo;\nO Genie irá automaticamente acionar o Asset Confiável associado à pergunta, executando a função convert_beer_price_to_usd com o parâmetro adequado:\nSELECT * FROM convert_beer_price_to_usd(\u0026#39;Guinness\u0026#39;); O resultado será uma tabela que inclui o nome da cerveja, o preço original em euros e o preço convertido para dólares americanos:\nO Genie indicará que este é um resultado de um Asset Confiável, exibindo a etiqueta correspondente para o usuário. Isso não apenas fornece a resposta correta, mas também reforça a confiabilidade da informação, garantindo que ela seja baseada em uma consulta previamente validada.\nEssa abordagem permite aos usuários obter respostas mais rápidas e precisas, já que o Genie não precisa construir uma nova consulta do zero a cada vez, aproveitando a lógica já estabelecida na função registrada como Asset Confiável.\nConclusão O Genie se destaca por sua capacidade de substituir consultas complexas e específicas de dashboards, oferecendo uma solução mais interativa e flexível para os usuários de negócios. Enquanto os dashboards tradicionais são úteis para acompanhar os principais KPIs e responder a perguntas padrão, eles podem se tornar limitados quando se trata de explorar questões mais profundas e detalhadas. Para atender a essa necessidade, o Genie proporciona uma abordagem mais ágil e eficaz, permitindo que os usuários façam perguntas mais complexas, tudo com base nos mesmos dados semânticos, enriquecidos por Assets Confiáveis e instruções adequadas.\nAdotar essa estratégia não apenas libera o tempo da equipe de dados, como também capacita os usuários de negócios a obterem insights mais completos, aumentando a autonomia e o poder de análise dentro da organização. Em resumo, os dashboards são mais adequados para as 10% de perguntas recorrentes do dia a dia, enquanto o Genie é ideal para escavar questões mais complexas que não podem ser atendidas pelos dashboards.\nPara garantir o sucesso de um espaço do AI/BI Genie, é fundamental seguir alguns componentes-chave:\nDados: utilize um conjunto de dados limpo, coerente e bem documentado, específico para o tema, garantindo a precisão e clareza das informações. Instruções: transmita as informações específicas do seu negócio de maneira clara, utilizando linguagem natural para orientar o Genie. Consultas Pré-definidas: aproveite os Assets Confiáveis para estabelecer uma fonte única da verdade e use exemplos de SQL para guiar as respostas do Genie, melhorando a precisão das respostas para perguntas comuns. Feedback: monitore as perguntas e suas avaliações, ajustando o espaço do Genie com base nos comentários dos usuários e nos exemplos fornecidos. Seguindo esses componentes, você conseguirá otimizar o uso do Genie, potencializando insights e facilitando a análise de dados de maneira mais completa e eficaz.\nReferências https://docs.databricks.com/en/genie/index.html\nhttps://docs.databricks.com/en/sql/language-manual/sql-ref-syntax-ddl-alter-table-add-constraint.html\nhttps://www.databricks.com/glossary/medallion-architecture\nhttps://www.databricks.com/glossary/star-schema\nhttps://www.databricks.com/blog/onboarding-your-new-aibi-genie\n","permalink":"https://julianamarialop.github.io/articles/esfregue-lampada-e-obtenha-insights-um-guia-para-o-aibi/","summary":"Imagine poder conversar com seus dados como se estivesse falando com um colega de trabalho ou, melhor ainda, como se estivesse interagindo com um gênio da lâmpada mágica. É exatamente isso que o AI/BI Genie permite!…","title":"Esfregue a Lâmpada e Obtenha Insights: Um Guia para o AI/BI Genie no Azure Databricks"},{"content":"No mundo dos dados, a criação de uma camada bronze, que organiza dados brutos em uma estrutura acessível para transformações subsequentes, tradicionalmente envolve bastante codificação. Porém, recentemente, explorei uma nova abordagem utilizando o Databricks Assistant AI que me permitiu criar uma camada bronze sem escrever uma única linha de código.\nO Databricks Assistant AI é uma ferramenta de inteligência artificial incorporada ao ambiente Databricks, projetada para simplificar o desenvolvimento e automação de pipelines de dados. Ele funciona interpretando comandos em linguagem natural, permitindo que os usuários configurem tarefas complexas como ingestão de dados, transformações e validações sem a necessidade de escrever código manualmente. É uma solução ideal para profissionais que desejam ganhar agilidade e eficiência em seus projetos de dados, reduzindo o tempo dedicado à codificação e minimizando erros comuns no desenvolvimento.\nAqui está o passo a passo de como consegui automatizar esse processo com o uso de notebooks e inteligência artificial.\nCriação do Notebook Para iniciar, criei um notebook chamado 01_Tabelas_Bronze_GenAI com o comentário: \u0026ldquo;Notebook de criação da camada bronze.\u0026rdquo; Esse notebook foi a base para a criação automatizada da camada bronze sem codificação manual. Cada etapa foi configurada de forma simples, utilizando o Databricks Assistant AI para gerenciar a lógica por trás das ações.\nHá 2 formas de acessar o Assistant, por meio da célula do notebook ou no canto superior direito logo após o nome do seu serviço Databricks (no meu caso \u0026ldquo;jml-databricks\u0026rdquo;). Optei por utilizar por célular para explicar melhor a criação da camada Bronze passo-a-passo.\nUma vez criado, vamos nos divertir !\nPasso 1: Criação de Parâmetros Primeiro, foram definidos parâmetros essenciais para a execução do processo. Esses parâmetros controlam os caminhos dos arquivos e o formato de origem dos dados.\nNome: par_path Tipo: Texto Comentário: Caminho da pasta de origem dos dados Nome: file_format Tipo: Texto Comentário: Formato do arquivo de origem (CSV, JSON, etc.) Nome: file_name Tipo: Texto Comentário: Nome do arquivo de origem Com esses parâmetros, é possível garantir que o pipeline possa ser adaptável a diferentes fontes de dados.\nCrie um notebook Nome: 01_Tabelas_Bronze_GenAI Comentário: Notebook de criação da camada bronze. Ação: Cada passo abaixo é uma célula no notebook. -------------------------------------------------------------------------------------------- Passo 1 - Criação de Paramêtros Nome: par_path Tipo: Texto Comentário: Caminho da pasta Nome: file_format Tipo: Texto Comentário: Nome do Arquivo de Origem Nome: file_name Tipo: Texto Comentário: Formato do Arquivo de Origem -------------------------------------------------------------------------------------------- Para gerar o código, clique em \u0026ldquo;Toggle Assistant\u0026rdquo;, cole o prompt acima e clique em Generate.\n_Carregando informações no prompt_\nVeja que o Databricks irá criar seu código python, se tudo estiver certo dê \u0026ldquo;Accept\u0026rdquo;.\n_Aceitando a sugestão de códigos_\nAgora é só executar !\n_Código executado_\nEssa execução gerou 3 widgets.\nPasso 2: Validação Automática de Parâmetros Com os parâmetros configurados, a próxima etapa foi garantir que eles fossem lidos e validados corretamente. O Databricks Assistant AI automaticamente configura o código para:\nObter todos os parâmetros dos widgets. Imprimir os valores para fins de depuração. Verificar se os parâmetros estão definidos e, caso contrário, exibir uma mensagem informando que eles são obrigatórios, encerrando a execução do notebook. Essa etapa de validação é crucial para evitar problemas com dados incorretos ou incompletos.\nPasso 2 - Paramêtros de execução automático Obter os parâmetros de todos os widgets. Imprima os valores desses parâmetros para fins de depuração. Verifique se todos os parâmetros estão definidos. Se não estiver, mostre uma mensagem informando que ele é obrigatório e encerre a execução do notebook com um código de saída 1.\u0026#34; _Prompt do Passo 2_\n_Código do passo 2 executado_\nPara executar esse código adicionei os parâmetros:\npar_path: /mnt/jmldatalake/movies/dataset/imdb/ file_format: csv file_name: name_basics.csv Passo 3: Criação do Banco de Dados Com os parâmetros validados, a próxima ação foi criar a base de dados onde a camada bronze seria armazenada. Através do Databricks Assistant AI, configurei o seguinte comando:\nNome do Banco: movies_bronze Caminho de Armazenamento: /mnt/jmldatalake/movies_bronze/database Comentário: Banco de dados da camada Bronze Se o banco de dados já existisse, o notebook não recriaria a base, garantindo eficiência no processo.\nPasso 3 - Criar Banco de Dados Ação: Crie uma base de dados (se não existir) Nome: movies_bronze Caminho do Armazenamento: /mnt/jmldatalake/movies_bronze/database Comentário: Banco de Dados da camada Bronze _Código do passo 3 gerado_\nBanco de dados da camada Bronze criada !\nPasso 4: Definição do Nome da Tabela Para nomear a tabela da camada bronze, o nome do arquivo de origem foi utilizado como base, com as seguintes transformações aplicadas automaticamente:\nRemoção da extensão do arquivo. Substituição de caracteres \u0026ldquo;-\u0026rdquo; por \u0026ldquo;_\u0026rdquo;. Adição do prefixo tb_raw_ ao nome do arquivo. Por exemplo, se o arquivo original fosse movies-2024.csv, o nome da tabela seria transformado em tb_raw_movies_2024.\nPasso 4 - Definição do nome da tabela Condição: Utilize a variável que contenha Nome do Arquivo de Origem Ação: 1. Retire a extensão do Nome do Arquivo de Origem 2. Substitua \u0026#34;-\u0026#34; por \u0026#34;_\u0026#34; 3. Adicione o prefixo \u0026#34;tb_raw_\u0026#34; ao Nome do Arquivo de Origem _Prompt do Passo 4_\n_Código Executado_\nPasso 5: Leitura de Arquivos O próximo passo foi a leitura dos arquivos de dados brutos. Utilizando o caminho de origem e o nome do arquivo, o Databricks Assistant AI automatizou a leitura dos dados com as seguintes configurações:\nCabeçalho: Verdadeiro InferSchema: Falso Delimitador: Tabulação (\\t) Após a leitura, o número de registros ingeridos foi impresso automaticamente para verificação.\nPasso 5 - Leitura de Arquivos Crie uma variável que una o caminho de origem do arquivo e o nome do arquivo de origem, retire os 5 últimos caracteres e adicione * Ação: Leia o Arquivo de acordo com a variável criada acima com os parâmetros abaixo: Cabeçalho: Verdadeiro InferSchema: Falso Delimitado: \\t Após isso, imprima na tela a quantidade de registros ingeridos na tabela. _Código executado no passo 5_\nPasso 6: Gravação de Dados no Formato Delta Por fim, os dados foram salvos no formato Delta, que oferece alta performance e capacidade de versionamento. A gravação foi configurada com as seguintes opções:\nModo Overwrite: Verdadeiro Substituir Schema: Verdadeiro Multi Linhas: Falso Assim, os dados foram sobrescritos, garantindo a consistência da camada bronze. Após a gravação, o número de registros no destino também foi impresso, confirmando o sucesso da operação.\nPasso 6 - Gravação de Arquivos Salve o dataframe criado no passo anterior em formato Delta utilizando os parâmetros abaixo: Modo Overwrite: Verdadeiro Substituir Schema: Verdadeiro Multi Linhas: False Após isso, imprima na tela a quantidade de registros ingeridos na tabela destino. _Código executado para o passo 6_\nConclusão Com a ajuda do Databricks Assistant AI, consegui automatizar a criação de uma camada bronze de forma rápida e eficiente, sem escrever uma única linha de código. O que antes era uma tarefa manual e suscetível a erros tornou-se um processo simples, controlado e auditável.\nEssa abordagem não só economizou tempo, mas também trouxe mais segurança e escalabilidade para o pipeline de dados. Estou empolgado para ver como a inteligência artificial continuará transformando o desenvolvimento de soluções de dados e simplificando processos que, até pouco tempo atrás, exigiam conhecimento técnico profundo.\nEu espero ter te influenciado para utilizar o Assistant pois vale muito a pena !!\nNo próximo artigo vamos tratar de Camada Silver !\nAté lá !\n","permalink":"https://julianamarialop.github.io/articles/do-zero-ao-bronze-como-construi-uma-camada-de-dados-sem/","summary":"No mundo dos dados, a criação de uma camada bronze, que organiza dados brutos em uma estrutura acessível para transformações subsequentes, tradicionalmente envolve bastante codificação. Porém, recentemente, explorei uma…","title":"Do Zero ao Bronze: Como criar um notebook sem codificar com Azure Databricks Assistant AI"},{"content":"Nos últimos anos, Databricks se consolidou como uma plataforma poderosa, semelhante à força que guia os Jedi em suas missões, ajudando empresas a acelerar seus projetos de dados e análises. Assim como a união entre a Força e os Jedi cria harmonia, o Databricks reúne o data warehouse e o data lake em uma solução equilibrada e poderosa – o lakehouse.\nMas, afinal, como podemos estruturar e configurar uma plataforma Databricks de forma eficiente para que ela seja tão precisa quanto um sabre de luz nas mãos de um Jedi? Assim como os Jedi seguem seu código de honra, nós também precisamos de uma série de boas práticas para garantir que o Databricks funcione em perfeita harmonia, protegendo nossos dados como se fossem o segredo da Resistência.\nNeste artigo, embarcaremos em nossa jornada galáctica e exploraremos os principais pilares que compõem uma plataforma Databricks bem arquitetada. De governança de dados (a nossa \u0026ldquo;Força\u0026rdquo; organizadora) à otimização de custos (o combustível que mantém a navegação suave pela galáxia), abordaremos tudo o que você precisa para dominar essa poderosa ferramenta.\nEntão, preparado(a) para a missão? Que a governança esteja com você! 🌌\nPara iniciarmos nossa jornada de boas práticas, vamos dividir os temas da seguinte forma:\n1. Governança de Dados O primeiro passo para uma arquitetura sólida é garantir que os dados realmente agreguem valor ao negócio e sustentem a estratégia da empresa. A governança de dados envolve a supervisão de políticas e processos para assegurar que os dados sejam confiáveis, seguros e utilizados de forma eficiente.\nA governança de dados no Databricks vai além de simplesmente armazenar e acessar informações. Ela envolve um conjunto de práticas recomendadas para garantir que os dados estejam sempre seguros, com qualidade e em conformidade com as políticas e regulamentações da organização. Vamos entender como aplicar esses conceitos de maneira didática e eficaz:\n🔍 1.1. Classificação e Marcação de Dados Antes de tudo, é fundamental classificar e entender a sensibilidade e importância dos dados. Isso ajuda a identificar dados que exigem mais proteção, como os confidenciais ou restritos, e também a definir a quem pertencem os dados dentro da empresa.\nClassificação de Dados: Categorize os dados em níveis como público, confidencial ou restrito. Defina também o proprietário dos dados, ou seja, quem é responsável por eles dentro da organização. Tags e Comentários: Utilize tags consistentes para marcar tabelas com informações importantes, como o proprietário dos dados, sua origem e nível de sensibilidade. Isso facilita o gerenciamento e o monitoramento do uso dos dados. Adicionar comentários a tabelas e colunas também ajuda a documentar detalhes importantes, podendo inclusive ser gerados automaticamente com a ajuda de IA. Mascaramento de Dados: Para ambientes de teste ou desenvolvimento, implemente técnicas de mascaramento de dados que protejam informações sensíveis, garantindo que esses dados não sejam expostos indevidamente. ✅ 1.2. Qualidade dos Dados A qualidade dos dados é essencial para garantir que as decisões baseadas neles sejam confiáveis.\nValidação de Dados: Automatize verificações de consistência, usando recursos como o ADD CONSTRAINT, para garantir que os dados estejam sempre em conformidade com as regras estabelecidas. Tratamento de Erros: Implemente mecanismos robustos para identificar e corrigir erros nos dados de forma ágil. Testes Automatizados: Adicione testes automáticos aos seus processos para garantir que tudo esteja funcionando como esperado. Padronização: Use formatos padronizados de dados, como convenções de nomenclatura consistentes, formatos de data unificados e unidades de medida claras, evitando confusões e discrepâncias. 🗂 1.3. Catálogo Unity O Catálogo Unity é uma ferramenta poderosa para gerenciar e organizar os dados de forma segura e eficiente.\nSegregação de Dados: Use catálogos para segmentar os dados de acordo com equipes, unidades de negócios ou ambientes específicos. Controle de Acesso: Implemente o Controle de Acesso Baseado em Função (RBAC) ou Atributo (ABAC) para garantir que cada usuário tenha acesso apenas aos dados necessários para suas funções. Permissões Refinadas: Aplique permissões detalhadas em níveis de banco de dados, tabela, linha e coluna, garantindo o princípio de \u0026ldquo;mínimo privilégio\u0026rdquo;. Registros de Auditoria: Habilite o registro de auditoria para acompanhar o acesso e as modificações feitas nos dados, facilitando o monitoramento e a conformidade com normas. 🛡️ 1.4. Políticas de Dados Por fim, é essencial que as práticas de governança sejam estabelecidas e seguidas rigorosamente.\nPolíticas de Retenção de Dados: Defina e aplique políticas claras para o ciclo de vida dos dados, usando funcionalidades como o Databricks VACUUM para garantir a conformidade com requisitos legais. Conformidade Regulatória: Assegure-se de que as práticas de governança estejam alinhadas com regulamentações como GDPR, CCPA, HIPAA, entre outras. Ferramentas de Terceiros: Aproveite as integrações do Databricks com ferramentas de catálogo e governança, como Azure Purview, para aprimorar suas capacidades de controle de dados. Políticas e Procedimentos: Crie políticas e procedimentos claros que definam responsabilidades, papéis e processos. Relatórios Regulares: Gere relatórios periódicos sobre métricas de governança, como registros de acesso, qualidade dos dados e status de conformidade. Linhagem de Dados: Utilize ferramentas de linhagem de dados para rastrear a origem dos dados e suas transformações ao longo dos pipelines, garantindo total transparência e controle. 2. Interoperabilidade e Usabilidade Um bom lakehouse deve ser capaz de interagir facilmente tanto com os usuários quanto com outros sistemas. Isso significa que sua arquitetura deve suportar múltiplas ferramentas e tecnologias, garantindo uma experiência fluida e sem atritos para todos os envolvidos.\n📋 2.1. Geral A gestão de uma plataforma Databricks requer boas práticas para garantir segurança, eficiência e manutenção contínua. Aqui estão algumas orientações que podem ajudar a estruturar seu ambiente de forma organizada e segura:\nPrincípios de Serviço: Ao configurar contas que precisam interagir com o Databricks, como contas para o uso do Terraform, é fundamental utilizar Princípios de Serviço. Isso permite que cada serviço tenha sua própria conta, facilitando a auditoria e o controle de acesso. Dessa forma, você saberá exatamente quem tem acesso e quais permissões estão em vigor. Infraestrutura como Código (IaC): Para automatizar a implantação e manutenção do Databricks, utilize Infraestrutura como Código (IaC). O provedor Databricks para o Terraform é uma ótima solução para isso, pois permite gerenciar o ambiente de forma replicável e segura. Gerenciamento de Segredos: Certifique-se de que todos os segredos e credenciais usados para acessar outros serviços estejam armazenados de forma segura. Utilize os Escopos Secretos do Databricks, que podem ser integrados a ferramentas como o Azure KeyVault, para garantir que essas informações estejam protegidas contra acessos não autorizados. CI/CD: Implemente mudanças no ambiente Databricks através de pipelines de CI/CD (Integração Contínua/Entrega Contínua). Todo o código-fonte deve ser armazenado em um repositório Git, permitindo controle de versão, rastreamento de alterações e maior segurança no desenvolvimento. 🔄 2.2. Compartilhamento de Dados O compartilhamento de dados no Databricks exige que sejam seguidas boas práticas para garantir segurança e privacidade, especialmente quando envolve múltiplos parceiros ou unidades de negócios:\nCompartilhamento Delta: Ao compartilhar dados com segurança, o Delta Sharing é uma solução ideal. Ele permite compartilhar dados com parceiros externos ou unidades de negócios, mantendo o controle sobre o acesso. Para maior segurança, configure listas de acesso por IP para restringir quem pode acessar os dados e implemente a rotação de tokens para manter o controle constante. Databricks Clean Rooms: Utilize os Clean Rooms do Databricks quando for necessária uma análise colaborativa entre organizações, mas sem compartilhar os dados brutos. Isso garante que a privacidade dos dados seja mantida, além de estar em conformidade com regulamentações de privacidade, como a GDPR. Marketplace: Caso precise acessar dados comerciais ou abertos, considere o Databricks Marketplace, que oferece uma vasta gama de dados para atender a diversas necessidades de negócios. Lakehouse Federation: A federação de dados é útil quando você precisa acessar informações de vários sistemas sem migrar os dados para um local central. Contudo, considere o impacto no desempenho das consultas e os custos de entrada/saída de dados ao adotar essa abordagem. 3. Excelência Operacional Não adianta ter uma arquitetura de ponta se o operacional não acompanha. A excelência operacional diz respeito a todos os processos que mantêm a plataforma Databricks rodando de forma eficiente e estável em um ambiente de produção, minimizando paradas e garantindo continuidade.\n🚀 Processamento (Clusters) A gestão de clusters no Databricks é essencial para garantir o bom desempenho, segurança e otimização de custos. Aqui estão algumas práticas recomendadas:\n3.1. Geral Políticas de Cluster: Defina políticas de cluster para limitar o tamanho e os recursos, ou mesmo para criar \u0026ldquo;clusters do tamanho de camiseta\u0026rdquo; (pequeno, médio, grande), ajustando-se às necessidades de diferentes cargas de trabalho. Databricks Runtime: O Databricks Runtime está em constante evolução, com melhorias em usabilidade, desempenho e segurança. Sempre que possível, utilize a versão mais recente para garantir que você tenha acesso às melhores funcionalidades. Reiniciar Clusters de Longa Duração: Clusters que ficam rodando por longos períodos podem perder atualizações críticas de segurança e sistema operacional. Garanta que eles sejam reiniciados periodicamente para evitar problemas de desempenho e segurança. Usar Volumes SSD: Clusters com workers que utilizam volumes SSD são automaticamente configurados com cache de disco, acelerando as consultas e melhorando a performance do seu ambiente. Pré-aquecimento de Clusters: Se suas consultas estiverem lentas devido à inicialização a frio dos clusters, considere utilizar os pools do Databricks, que permitem pré-aquecer clusters para reduzir o tempo de espera. ⚙️ Orquestração (Jobs) A configuração e gerenciamento de trabalhos no Databricks podem ser otimizados para garantir eficiência e escalabilidade.\n3.2. Configuração do Trabalho Job Clusters: Ao configurar trabalhos, utilize clusters específicos para jobs, dimensionados corretamente de acordo com a carga de trabalho. O uso de dimensionamento automático permite lidar com variações na demanda de forma eficiente. Tentativas de Trabalho: Defina um número adequado de tentativas para trabalhos críticos, considerando falhas transitórias. Para evitar sobrecarga, implemente uma lógica de backoff exponencial no código, ajustando a frequência das tentativas em caso de erros. Princípios de Serviço: Certifique-se de que os trabalhos estejam configurados com um Princípio de Serviço como proprietário, o que evita problemas de continuidade caso o criador original do job deixe a equipe. Uso de Parâmetros: Em trabalhos com múltiplos estágios, utilize parâmetros para compartilhar informações entre esses estágios, facilitando a integração e o controle do processo. Trabalhos Orientados por Eventos: Sempre que possível, opte por trabalhos orientados por eventos, que são mais eficientes em termos de tempo e custos. Para ingestões únicas, considere usar o comando COPY INTO como alternativa. 3.3. Gerenciamento de Código Controle de Versão: Armazene seu código em um sistema de controle de versão, como o Git. Utilize o Databricks Repos para sincronizar notebooks e arquivos com o repositório, facilitando o gerenciamento e o rastreamento de alterações. Código Modular: Escreva código modular e reutilizável, permitindo que ele seja compartilhado entre diferentes trabalhos e notebooks, promovendo eficiência e padronização. Testes Automatizados: Implemente testes unitários, de integração e E2E para garantir que o código funcione conforme esperado, desde as funções mais simples até os fluxos mais complexos. Databricks Asset Bundles (DAB): Utilize o Databricks Asset Bundles para facilitar o desenvolvimento e a implantação de trabalhos, garantindo consistência e automação. Pipelines de CI/CD: Configure pipelines de CI/CD para automação dos fluxos de trabalho no Databricks, utilizando ferramentas como Azure DevOps, GitLab ou GitHub Actions. 3.4. Tratamento e Registro de Erros Tratamento de Erros: Implemente um tratamento de erros robusto com blocos try-catch, garantindo que exceções sejam tratadas de forma apropriada e sem interrupções bruscas. Logging: Utilize log estruturado para registrar eventos, métricas e erros. O Databricks oferece integração com ferramentas de logging, como Azure Log Analytics, o que facilita o monitoramento e diagnóstico. 🧑💻 Pessoas e Processos Além da parte técnica, é fundamental estruturar uma equipe dedicada e criar processos bem documentados e padronizados.\n3.5. Geral Equipe de Operações: Monte uma equipe de operações dedicada ao Lakehouse, responsável por manter as melhores práticas, garantir a segurança e monitorar as ferramentas usadas. Gerenciamento de Limites de Serviço: Ao projetar a arquitetura, considere os limites e cotas de serviço do Databricks, do provedor de nuvem e do Unity Catalog, para evitar interrupções por ultrapassagem de limites. Padronização de Nomeação: Considere criar um documento com padrões de nomenclatura para objetos Databricks, como catálogos, que podem seguir convenções como \u0026lt;sigla_do_ambiente\u0026gt;-\u0026lt;nome_do_projeto\u0026gt;. Essa padronização pode ser imposta através de pipelines de CI/CD. 3.6. Colaboração e Documentação Documentação Completa: Documente completamente seus fluxos de trabalho, código e configurações. Utilize recursos como comentários, Markdown e visualizações dentro dos notebooks para garantir que tudo esteja claro para a equipe. Revisões de Código: Implemente um processo de revisão de código para garantir a qualidade e promover o compartilhamento de conhecimento entre os membros da equipe. Marcação de Recursos: Utilize tags consistentes para marcar recursos de acordo com as políticas da empresa. Isso facilita o monitoramento, gestão de custos e localização de informações importantes. 4. Segurança, Privacidade e Conformidade Proteger dados e sistemas é fundamental. Por isso, um bom setup de Databricks deve contar com mecanismos robustos de segurança, privacidade e conformidade com normas e regulamentações. Manter o ambiente seguro contra ameaças é prioridade para proteger o valor dos dados e a confiança dos clientes.\n🛡️ 4.1. Segurança Geral Security Analysis Tool (SAT): O Databricks oferece a ferramenta Security Analysis Tool (SAT), que ajuda a verificar se seus espaços de trabalho seguem as práticas recomendadas de segurança. Essa ferramenta pode ser acessada no GitHub. Autenticação Multifator (MFA): Certifique-se de que todas as contas que usam o Databricks estejam configuradas com autenticação multifator (MFA), utilizando um provedor de identidade adequado. No caso do Azure Databricks, o provedor de identidade padrão é o Entra, enquanto para GCP ou AWS você pode configurar o SSO. Controle de Acesso Baseado em Função (RBAC): Utilize grupos do Azure AD e o Databricks SCIM para gerenciar permissões com base no princípio do menor privilégio, garantindo que cada usuário tenha apenas o acesso necessário. Principais de Serviço: Ao fornecer acesso automatizado ou programático ao Databricks, utilize os Principais de Serviço do Azure AD, assegurando que essas identidades tenham permissões mínimas para realizar suas funções. Segurança e Conformidade Aprimoradas: Se a sua empresa precisa atender a padrões de conformidade como PCI-DSS ou HIPAA, considere usar o complemento de Segurança e Conformidade Aprimoradas para garantir que os requisitos específicos sejam cumpridos. 👨💻 4.2. Gerenciamento de Código Segredos: Todos os segredos, como credenciais de acesso, devem ser armazenados dentro de escopos secretos com as permissões adequadas para protegê-los de acessos não autorizados. Raiz do DBFS: Evite armazenar dados na raiz do DBFS. Isso porque, quando os dados são armazenados na raiz, todos os usuários podem acessá-los, comprometendo a segurança. Análise de Código Estático (IaC): Considere usar ferramentas como checkov, tfsec e terrascan para realizar análises estáticas em código de Infraestrutura como Código (IaC), identificando vulnerabilidades e problemas de conformidade. Análise de Código Estático (Python): Para código Python, utilize ferramentas como Pylint para verificar a qualidade e segurança do código. Revisões de Código: Realize revisões de código regulares para garantir que notebooks e jobs sigam as melhores práticas de codificação e que não haja exposição de informações confidenciais. Gerenciamento de Dependências: Mantenha as dependências sempre atualizadas, aplicando patches regularmente. Ferramentas como Snyk ajudam a identificar vulnerabilidades em bibliotecas e ferramentas de terceiros, essenciais para manter a segurança operacional. 🌐 4.3. Segurança de Rede (Azure) Implantar Databricks em uma VNet: Utilize a injeção de VNet do Azure para implantar o Databricks dentro de uma rede virtual privada (VNet), garantindo que seu cluster e workspace estejam isolados da internet pública. Pontos de Extremidade Privados: Configure Azure Private Link para criar pontos de extremidade privados, permitindo comunicação segura entre o Databricks e outros serviços do Azure, como contas de armazenamento e bancos de dados. Grupos de Segurança de Rede (NSGs): Use NSGs para controlar o tráfego de entrada e saída nas sub-redes do Databricks, garantindo que apenas o tráfego necessário seja permitido. Conectividade Segura do Cluster: Configure os clusters para que eles operem com conectividade segura, ou seja, sem IP público, prevenindo o acesso direto pela internet. Listas de Acesso IP: Considere implementar listas de acesso IP para restringir o acesso ao workspace apenas a endereços IP permitidos. 🔐 4.4. Proteção de Dados (Azure) Criptografia em Repouso: Certifique-se de que todos os dados armazenados em serviços como Azure Data Lake Storage (ADLS) estejam criptografados em repouso, utilizando a criptografia do serviço de armazenamento do Azure. Criptografia em Trânsito: Habilite HTTPS e SSL/TLS para criptografar dados em trânsito, garantindo a segurança das comunicações entre o Databricks e sistemas externos. Identidade Gerenciada para Recursos do Azure: Utilize identidades gerenciadas para conceder ao Databricks acesso seguro ao Azure Key Vault e outros recursos, sem a necessidade de expor credenciais. Chaves Gerenciadas pelo Cliente (CMK): Configure CMKs para gerenciar a criptografia de dados no Databricks, implementando rotação de chaves e monitoramento de uso para detectar acessos não autorizados. 📚 4.5. Documentação e Treinamento Documentação do Plano de Recuperação de Desastres (DR): Documente sua estratégia de recuperação de desastres (DR), incluindo procedimentos de backup, etapas de recuperação e atribuições de responsabilidades. Runbooks: Crie runbooks com instruções passo a passo para cenários de recuperação de desastres, assegurando que sua equipe saiba como agir rapidamente em caso de incidentes. Compartilhamento de Conhecimento: Promova o compartilhamento de conhecimento sobre o plano de DR em toda a organização, garantindo que todos estejam preparados. 💾 4.6. Segurança Operacional Backups: Use armazenamento entre regiões para proteger seus dados críticos ou implemente tarefas de backup que gravem os dados em uma região ou conta de armazenamento local. Git: Armazene todo o código de Infraestrutura como Código (IaC), configuração de cluster, jobs e notebooks em repositórios Git. Isso facilita a recuperação em caso de incidentes e promove o controle de versão. Plano de Recuperação de Desastres (DR): Desenvolva e teste regularmente um plano de recuperação de desastres, garantindo a continuidade dos negócios em caso de incidentes graves. ⚙️ 4.7. Configuração do Espaço de Trabalho Credential Passthrough: A partir do Databricks Runtime 15.0, o Credential Passthrough será descontinuado. Em vez disso, utilize o Unity Catalog (UC) para gerenciar identidades e permissões de maneira mais eficiente. Isolamento de Ambiente: Defina diferentes workspaces para ambientes de desenvolvimento, stage e produção, ou para diferentes unidades de negócios. Esse isolamento permite uma melhor gestão de recursos e segurança. Separação de Dados: Separe logicamente e fisicamente seus dados confidenciais dos não confidenciais, garantindo que informações sensíveis estejam protegidas. 5. Eficiência de Desempenho Com a demanda por análises e processamento de dados crescendo exponencialmente, a eficiência de desempenho é crucial. Sua plataforma deve ser capaz de se adaptar a mudanças na carga de trabalho sem comprometer a velocidade e a qualidade dos resultados.\n🔎 Consultas A otimização de consultas no Databricks é essencial para garantir um desempenho eficiente e evitar gargalos desnecessários. Aqui estão algumas práticas recomendadas para maximizar a performance das suas consultas:\n5.1. Geral Agrupamento Líquido (Liquid Clustering): Configure agrupamento líquido nas colunas frequentemente utilizadas nas consultas. Essa técnica é preferível ao uso de ordenação Z ou particionamento, já que melhora a performance de busca sem o risco de particionamento excessivo. Formatos de Arquivo Eficientes: Utilize formatos de arquivo como Parquet ou ORC, que oferecem melhor desempenho e compactação dos dados. Para ainda mais eficiência, armazene os dados dentro de tabelas gerenciadas no lakehouse. Clusters Maiores: Quando sua carga de trabalho aumenta linearmente, planeje o uso de clusters maiores. Um cluster maior geralmente processa a mesma carga mais rapidamente e, em muitos casos, não resulta em maior custo, apenas em maior velocidade. Ignorância de Dados: O Databricks coleta estatísticas automaticamente nas primeiras 32 colunas definidas (incluindo colunas aninhadas). Para melhorar o desempenho das consultas, certifique-se de que as colunas mais frequentemente consultadas estejam dentro dessas primeiras 32 colunas. Evite Particionamento: Com o advento do agrupamento líquido, o particionamento tornou-se menos necessário. Em muitos casos, particionar os dados pode causar particionamento excessivo, onde cada partição precisa ter pelo menos 1 GB, o que pode prejudicar o desempenho. 5.2. Desempenho Predicate Pushdown: Use predicate pushdown para filtrar os dados logo no início da execução da consulta. Isso reduz a quantidade de dados movimentados e melhora o desempenho geral. Quando estiver lendo de um RDBMS, combine opções como partitionColumn, lowerBound e upperBound para paralelizar a operação de leitura. Junções de Transmissão: Para tabelas menores, utilize junções de transmissão, enviando a tabela menor para todos os executores. Isso melhora o desempenho das junções em consultas complexas. Skew Handling: Identifique e gerencie dados distorcidos (skew) para garantir que as partições de dados sejam distribuídas de maneira uniforme. Técnicas como salting podem ajudar a mitigar o skew de dados. Persistência (Cache): Utilize o comando .persist para armazenar resultados de subconsultas e dados em formatos diferentes de Parquet. No entanto, evite o uso excessivo de persistência a menos que você saiba exatamente o impacto que isso terá no desempenho. Execução Especulativa: Ative a execução especulativa para executar novamente tarefas lentas em outros nós, o que ajuda a mitigar o impacto de tarefas demoradas e melhora o tempo total de execução. Compactação (Compaction): Use o comando OPTIMIZE para otimizar manualmente tabelas no Delta Lake. Para uma otimização contínua, habilite AUTO OPTIMIZE e AUTO COMPACT ao gravar em tabelas, melhorando o desempenho a longo prazo. ANALYZE TABLE: A instrução ANALYZE TABLE coleta estatísticas sobre tabelas dentro de um esquema especificado, ajudando a melhorar o desempenho das consultas. 💻 Código Um código bem estruturado e otimizado pode melhorar significativamente o desempenho das consultas e a eficiência geral do sistema.\n5.3. Código Evite Transformações Amplas: Minimize o uso de transformações amplas, como groupBy e join, que exigem o embaralhamento de grandes quantidades de dados pela rede. Quando essas operações forem necessárias, otimize-as para reduzir o impacto no desempenho. Prefira DataFrames e Datasets: Utilize DataFrames e Datasets em vez de RDDs, pois eles oferecem otimizações automáticas e são mais fáceis de usar. Aproveite o otimizador Catalyst e o mecanismo Tungsten para obter um melhor desempenho nas operações. Perfis de Código: Crie perfis do seu código regularmente para identificar e solucionar gargalos de desempenho. Utilize ferramentas como o Spark UI para obter insights sobre a execução e melhorar a eficiência. Instruções MERGE: Quando possível, utilize a remoção de partições durante operações de MERGE, otimizando a execução dessas operações. 5.4. Carimbos de Tempo Carimbos de Data/Hora: No Databricks, os carimbos de data/hora são armazenados como números de ponto flutuante, representando o número de segundos (e frações de segundo) desde a época Unix. Notebooks e Fusos Horários: O valor dos carimbos de data/hora exibidos nos notebooks é ajustado de acordo com o fuso horário da sessão atual, que geralmente é UTC. Se os dados no arquivo não contêm um indicador de fuso horário, a análise dos carimbos de data/hora pode depender do fuso horário da sessão. Armazéns SQL: Nos armazéns SQL, o fuso horário padrão também é UTC, a menos que seja configurado de outra forma. No entanto, não há deslocamento ou indicador de fuso horário. 6. Otimização de Custos Por fim, uma boa arquitetura não pode esquecer da otimização de custos. Gerenciar os recursos de forma inteligente e eficaz garante que a empresa maximize o retorno sobre o investimento, entregando valor sem desperdícios.\nControlar os custos no Databricks é essencial para garantir que você esteja aproveitando ao máximo a plataforma sem ultrapassar o orçamento. Aqui estão algumas práticas para ajudar a gerenciar os custos de maneira eficaz:\n💰 6.1. Monitoramento de Custos Monitoramento Regular: É fundamental monitorar constantemente o uso e os custos no Databricks. Utilize a Análise de Custos disponível no Databricks ou ferramentas de terceiros para ter uma visão clara do seu consumo. No console da conta do Databricks, há uma página dedicada para analisar o uso de DBUs (Databricks Units), embora isso não inclua os custos de VMs ou armazenamento. Orçamento e Notificações: O Databricks oferece uma funcionalidade de definição de orçamento, onde você pode configurar notificações para ser alertado caso o uso exceda o valor estipulado, ajudando a manter os gastos sob controle. 💰 6.2 Clusters Otimizados Configurações de Cluster Custo-Eficientes: Utilize configurações de clusters que proporcionem uma boa relação custo-benefício. Para cargas de trabalho não críticas, considere o uso de instâncias spot, que são mais baratas, mas podem ser interrompidas a qualquer momento. Para garantir a resiliência, implemente uma política de repetição quando estiver usando essas instâncias. Políticas de Término Automático: Configure políticas de término automático para clusters que ficam ociosos, evitando que clusters desnecessários continuem rodando e acumulando custos. Clusters Graviton (AWS): Se você está rodando no AWS, considere utilizar clusters Graviton, que oferecem uma relação desempenho/custo superior em comparação com outros tipos de instância. 💰 6.3 Photon e Otimização de Consultas Photon Runtime: O Photon Runtime do Databricks oferece um aumento significativo de desempenho em comparação com o Spark tradicional, além de ser mais eficiente em termos de custo. Ele é ideal para quem busca uma otimização de performance sem elevar os gastos. Otimização de Consultas: Regularmente, revise e otimize suas consultas Spark. Utilize o Spark Query Profile e analise os planos de execução para identificar gargalos de desempenho. Melhorar a eficiência das consultas reduz o tempo de execução e, consequentemente, os custos. 💰 6.4 Instâncias Sem Servidor Opções Sem Servidor: Quando apropriado, considere o uso de warehouses, workflows e notebooks SQL sem servidor. Essas opções podem ser mais econômicas, pois você paga apenas pelo tempo de uso, sem a necessidade de manter clusters dedicados. 🔄 7. Confiabilidade Falhas acontecem. Mas a questão é: como sua plataforma reage a elas? A confiabilidade de um sistema Databricks envolve a capacidade de se recuperar rapidamente de falhas e continuar operando, sem afetar os processos críticos do negócio.\n📊 7.1. Monitoramento e Registro Manter um ambiente Databricks funcionando de maneira eficiente requer uma estratégia sólida de monitoramento e registro. Aqui estão algumas práticas recomendadas para garantir a integridade, desempenho e segurança do seu ambiente:\nHabilitar Logs de Auditoria: Ative os logs de auditoria no Databricks para capturar informações detalhadas sobre atividades, como eventos de login, acesso a dados e ações administrativas. Esses logs ajudam a manter um histórico das operações e podem ser configurados com filtros de auditoria para evitar o vazamento de dados entre diferentes ambientes. Azure Monitor: Utilize o Azure Monitor para rastrear a saúde e o desempenho do seu ambiente Databricks, garantindo que as operações estejam funcionando conforme o esperado e identificando possíveis problemas antes que se agravem. Integração com Ferramentas de Monitoramento: Quando necessário, integre o Databricks com ferramentas de monitoramento, como Datadog, Prometheus, Splunk ou o próprio Azure Monitor, para melhorar a visibilidade do ambiente e o acompanhamento de métricas críticas. Monitoramento de Cluster: Faça o monitoramento regular dos clusters, verificando a integridade, o desempenho e os logs. Configure alertas automáticos para métricas importantes, como uso de CPU, memória ou duração de jobs, para evitar interrupções inesperadas. A integração com plataformas como Slack ou PagerDuty pode ser útil para receber notificações imediatas. Gerenciamento de Recursos: Monitore a utilização de recursos dos clusters com ferramentas como Ganglia ou a Databricks Cluster UI, garantindo que os recursos estejam sendo usados de maneira eficiente. Monitoramento do Auto Loader: O Auto Loader permite inspecionar o estado de um fluxo de dados por meio de uma API SQL e da Spark Streaming Query Listener, fornecendo insights detalhados sobre os arquivos processados e o estado das consultas em tempo real. Job Monitoring: Utilize a interface do Databricks Jobs para monitorar o status e o desempenho dos jobs. Também é possível implementar monitoramento personalizado para métricas específicas, facilitando a identificação de gargalos. Monitoramento do Delta Live Tables: Cada pipeline no Delta Live Tables gera um log de eventos que inclui logs de auditoria, verificações de qualidade de dados, progresso do pipeline e informações sobre a linhagem de dados. Isso facilita o acompanhamento contínuo dos pipelines. Monitoramento de Streaming: Com a interface de Structured Streaming, você pode monitorar taxas de entrada, processamento e latência de suas consultas de streaming. O método StreamingQuery.progress fornece relatórios detalhados em formato JSON para uma análise mais aprofundada. Monitoramento de ML e IA: Para monitoramento de modelos de Machine Learning e IA, utilize tabelas de inferência que registram continuamente entradas e saídas de modelos em uma tabela Delta. Isso permite monitorar, depurar e otimizar modelos com o auxílio de consultas SQL, notebooks e ferramentas de monitoramento do Lakehouse. Monitoramento de Segurança e Custos: O monitoramento de segurança deve ser implementado para garantir conformidade e privacidade. Além disso, monitore e controle os custos regularmente para evitar surpresas no orçamento. 📦 7.2. Outros Aspectos Importantes Armazenamento Padrão do Workspace: Evite usar o armazenamento padrão do workspace para dados de produção. Em vez disso, crie locais de armazenamento dedicados, configurados e ajustados de acordo com suas necessidades específicas, garantindo maior segurança e flexibilidade. Resiliência a Falhas de Zona de Disponibilidade (AZ): O Databricks já é resiliente a falhas de AZ por padrão. Certifique-se de que os clusters estejam configurados para Auto-Scaling e tenha uma política de repetição para jobs. A recuperação da funcionalidade do plano de controle deve ocorrer em aproximadamente 15 minutos após uma falha da AZ. Falha Regional: Embora uma implantação multirregional ativo-ativo no Databricks seja geralmente pouco viável financeiramente, é recomendável usar Infraestrutura como Código (IaC) para criar uma implantação secundária em uma região de backup. Utilize armazenamento em nuvem replicado para garantir a continuidade das operações. 🛠️ 7.3. Infraestrutura no Azure GRS (Geo-Redundant Storage): Na maioria dos casos, o GRS (Geo-Redundant Storage) oferece uma opção de armazenamento econômica e ainda garante durabilidade de 16 9s. No entanto, se o tempo de recuperação regional for crítico, considere o uso do GZRS (Zone-Redundant Storage). Concluímos nossa jornada galáctica pelo Databricks, explorando os principais pilares para configurar essa poderosa plataforma de forma estratégica e eficiente.\nAssim como um Jedi domina a Força, dominar o Databricks exige boas práticas que garantam o equilíbrio entre governança de dados, otimização de custos e desempenho. Essas diretrizes são como o código Jedi, oferecendo orientação, mas sempre flexíveis o suficiente para se adaptarem às necessidades e realidades de cada organização.\nQue o poder dos dados esteja com você enquanto você constrói uma plataforma de sucesso!\nObrigada pela leitura e acompanhe outros artigos da newsletter.\nReferências Databricks SAT: https://github.com/databricks-industry-solutions/security-análise-t\nData Lakehouse: https://learn.microsoft.com/en-us/azure/databricks/lakehouse-arch\nMelhores práticas: https://learn.microsoft.com/en-us/azure/databricks/data-governan\nProteção: https://www.databricks.com/blog/data-exfiltration-protection-with-\nConectividade do cluster: https://learn.microsoft.com/en-us/azure/databricks/security/netw\nAPI de orçamentos do Databricks: https://www.databricks.com/blog/best-practices-cost-management-databricks#:~:text=Warehouse%20creation%20permissions.-,Monitoring%20usage,-Along%20with%20controlling\nDatabricks Photon: https://www.databricks.com/product/photon#:~:text=no%20rewrite%20required.-,Por que%20Photon%3F,-Desempenho%20da%20consulta\n","permalink":"https://julianamarialop.github.io/articles/que-forca-analitica-esteja-com-voce-explorando-o-databricks/","summary":"Nos últimos anos, Databricks se consolidou como uma plataforma poderosa, semelhante à força que guia os Jedi em suas missões, ajudando empresas a acelerar seus projetos de dados e análises. Assim como a união entre a…","title":"Que a Força Analítica Esteja com Você: Explorando o Databricks no Estilo Star Wars"},{"content":"Uma visão geral e comparação de alto nível entre Databricks e Snowflake sobre seus pontos fortes e fracos. Databricks e Snowflake são dois nomes em soluções de dados em nuvem. Ambas as plataformas têm sido fundamentais para ajudar as empresas a gerar valor a partir de seus ativos de dados internos e externos. Cada plataforma tem vantagens e recursos distintos e eles têm se sobreposto cada vez mais em suas ofertas deixando muitos em dúvidas sobre qual solução é mais adequada para suas necessidades de negócios.\nPara começar uma comparação significativa, temos que entender o histórico e a competência principal de cada oferta. Para auxiliar nesse entendimento vamos pontuar as principais diferenças entre Snowflake e Databricks incluindo preço, desempenho, integração, segurança e melhores casos de uso para melhor atender às necessidades individuais de cada usuário.\nDatabricks vs. Snowflake: Quais são as principais diferenças? A primeira coisa a entender sobre as duas plataformas é o que elas são e que solução elas esperam fornecer.\nO Databricks é uma plataforma de análise de dados unificada e baseada em nuvem , para construir, implementar e compartilhar soluções de análise de dados em escala. O Databricks visa fornecer uma interface unificada onde os usuários podem armazenar dados e executar trabalhos em espaços de trabalho interativos e compartilháveis. Esses espaços de trabalho contêm notebooks por meio dos quais todas as funções de computação são construídas para serem computadas por máquinas baseadas em nuvem.\nO Snowflake, por outro lado, é um data warehouse SaaS totalmente gerenciado baseado em nuvem. Enquanto o Databricks foi projetado inicialmente para unificar pipelines de dados, o Snowflake foi projetado para ser a solução de data warehouse mais fácil de gerenciar. Enquanto o mercado-alvo do Databricks são cientistas e engenheiros de dados, o mercado-alvo do Snowflake é tipicamente analistas de dados — que são altamente proficientes em consultas SQL e análise de dados, mas não tão interessados ​​em computações complexas ou fluxos de trabalho de aprendizado de máquina.\nCom o tempo, a Databricks e a Snowflake têm competido cada vez mais, pois cada uma espera expandir suas ofertas para ser uma solução de plataforma de dados em nuvem tudo-em-um. Novos produtos como o Snowpark da Snowflake (que oferece funcionalidade Python) e o DBSQL da Databricks (seu data warehouse sem servidor) tornaram cada vez mais difícil diferenciar a oferta de cada produto.\nPor enquanto, a maioria concordaria que a Snowflake tende a ser o nome dominante para soluções de data warehouse em nuvem fáceis de usar, e a Databricks é a vencedora para fluxos de trabalho de aprendizado de máquina e ciência de dados baseados em nuvem.\nDatabricks vs Snowflake: Armazenamento de dados No momento, a Snowflake tem a vantagem para consultar dados estruturados, e a Databricks tem a vantagem para dados brutos e não estruturados necessários para ML. No futuro em próximo, creio que que a plataforma data lakehouse da Databricks será a solução de mercado dominante e mais abrangente para todo o gerenciamento de dados.\nUma das maiores diferenças entre Snowflake e Databricks é como eles armazenam e acessam dados. Ambos lideram a indústria em velocidade e escala. A maior diferença entre os dois é a arquitetura de data warehouse vs data lakehouse , e o armazenamento de dados não estruturados vs estruturados.\nSnowflake O Snowflake, em sua essência, é um data warehouse em nuvem. Ele armazena dados estruturados em um formato fechado e proprietário para consulta e transformação de dados rápidas e contínuas. Seu formato proprietário permite alta velocidade e confiabilidade com compensações em flexibilidade. Mais recentemente, o Snowflake está permitindo a ingestão de dados e o armazenamento de dados em formatos adicionais (como Apache Iceberg), mas a grande maioria dos dados de seus clientes ainda fica em seu próprio formato.\nO Snowflake utiliza uma arquitetura de disco compartilhado multicluster , na qual os recursos de computação compartilham o mesmo dispositivo de armazenamento, mas retêm sua própria CPU e memória. Para conseguir isso, o Snowflake ingere, otimiza e compacta dados em uma camada de armazenamento de objetos em nuvem, como Amazon S3 ou Google Cloud Storage. Os dados aqui são organizados em um formato colunar e segmentados em micropartições, de 50 a 500 MB. Essas micropartições armazenam metadados, o que ajuda muito na velocidade. Curiosamente, o próprio formato de arquivo de armazenamento interno do Snowflake não é de código aberto, mantendo a maioria dos clientes presos.\nPara funcionar de forma eficiente, o Snowflake usa várias camadas para fornecer uma experiência empresarial à carga de trabalho de processamento em nuvem. O Snowflake mantém uma camada de serviços em nuvem que lida com a autenticação empresarial e o controle de acesso.\nPara execução, o Snowflake usa armazéns virtuais, que são abstrações sobre instâncias de nuvem regulares (como EC2). Esses armazéns consultam dados de uma camada de armazenamento de dados separada, separando efetivamente o armazenamento e a computação. Essa separação de computação e armazenamento torna o Snowflake infinitamente escalável e permite que os usuários executem consultas simultâneas nos mesmos dados, com isolamento razoável.\n_Snowflake Architecture Layers_\nO Snowflake pode executar todos os três principais provedores de serviços de nuvem.\nConclusão: A arquitetura do Snowflake permite consultas rápidas e confiáveis ​​de dados estruturados, em escala. Ela tem apelo para aqueles que querem métodos simples para gerenciar seus requisitos de recursos de seus trabalhos (por meio de opções de warehouse do tamanho de uma camiseta). Ela é voltada principalmente para aqueles proficientes em SQL, mas não tem a flexibilidade para lidar facilmente com dados brutos e não estruturados.\nDatabricks Um dos pontos de venda da Databricks é que ela emprega uma camada de armazenamento de código aberto conhecida como Delta Lake — que visa combinar a flexibilidade dos data lakes em nuvem com a confiabilidade e estrutura unificada de um data warehouse — e sem os desafios associados ao bloqueio de fornecedor. A Databricks foi pioneira nessa estrutura híbrida chamada de \u0026ldquo;data lakehouse\u0026rdquo; como uma solução econômica para cientistas de dados, engenheiros de dados e analistas trabalharem com os mesmos dados — independentemente da estrutura ou formato.\n_Databricks Lakehouse_\nO data lakehouse da Databricks funciona empregando três camadas para permitir o armazenamento de dados brutos e não estruturados — mas também armazena metadados (como um esquema estruturado) para recursos semelhantes a warehouse em dados estruturados. Notavelmente, este data lakehouse fornece suporte a transações ACID , aplicação automática de esquema — que valida a compatibilidade do DataFrame e da tabela antes das gravações — e streaming de ponta a ponta para ingestão de dados em tempo real — alguns dos avanços mais desejáveis ​​para sistemas de data lake.\nConclusão: Lakehouses trazem a velocidade, confiabilidade e desempenho de consulta rápida de data warehouses para a flexibilidade de um Data Lake.\nEscalabilidade Databricks vs Snowflake Snowflake e Databricks continuam a batalhar pelo domínio das cargas de trabalho empresariais. Embora ambas tenham se mostrado líderes do setor nessa capacidade, a maior diferença prática entre as duas está em suas capacidades de gerenciamento de recursos.\nSnowflake A Snowflake oferece recursos de computação como uma oferta sem servidor. Isso significa que os usuários não precisam selecionar, instalar, configurar ou gerenciar nenhum software e hardware. Em vez disso, a Snowflake usa uma série de warehouses virtuais — recursos de computação independentes contendo memória e CPU — para executar consultas. Essa separação de memória e recursos de computação permite que a Snowflake dimensione infinitamente sem desacelerar, e vários usuários podem consultar simultaneamente o mesmo segmento único de dados.\nA Snowflake emprega um modelo simples de dimensionamento de “tamanhos” para seus warehouses virtuais, com 10 tamanhos, cada um com o dobro do poder de computação do tamanho anterior. O maior é o 6XL, que tem 512 nós. Como os warehouses não compartilham recursos de computação ou armazenam dados, se um deles cair, ele pode ser substituído em minutos sem afetar nenhum dos outros.\n_Um diagrama dos nós virtuais associados a cada tamanho de warehouse_\nMais notavelmente, os warehouses multicluster da Snowflake fornecem um recurso de \u0026ldquo;maximização\u0026rdquo; e \u0026ldquo;escala automática\u0026rdquo;, o que lhe dá a capacidade de desligar dinamicamente clusters não utilizados, economizando dinheiro.\nDatabricks A Databricks começou com uma infraestrutura muito mais \u0026ldquo;aberta\u0026rdquo; e tradicional, onde basicamente toda a computação é executada dentro da VPC de nuvem de um usuário. Este é o completo oposto do modelo \u0026ldquo;sem servidor\u0026rdquo;, onde a computação é executada dentro da VPC da Databrick, já que todas as configurações de cluster são expostas aos usuários finais. Isso tem seus prós e contras, a principal vantagem é que os usuários podem hiperotimizar seus clusters para melhorar o desempenho, mas a desvantagem é que pode ser doloroso de usar ou exigir um especialista para manter.\nMais recentemente, a Databricks está evoluindo para o modelo “serverless” com o Databricks SQL Serverless, e provavelmente estendendo esse modelo para outros produtos, como notebooks. Os prós e contras aqui se invertem, pois o pró é que os usuários não precisam se preocupar com configurações de cluster, no entanto, o contra é que os usuários não têm acesso nem visibilidade à infraestrutura subjacente e não conseguem personalizar os clusters para atender às suas necessidades.\nComo o Databricks está atualmente em um período de “transição” entre ofertas clássicas e “sem servidor”, sua escalabilidade realmente depende do caso de uso que as pessoas selecionam.\nUma observação importante é que o Databricks tem um conjunto diversificado de casos de uso de computação, de SQL warehouses, Jobs, All Purpose Compute, Delta Live Tables, até streaming — cada um deles tem configurações de computação e casos de uso ligeiramente diferentes. Por exemplo, SQL warehouses podem ser usados ​​como um recurso compartilhado, onde várias consultas podem ser enviadas ao warehouse a qualquer momento por vários usuários. Os jobs são mais singulares, nos quais um notebook é executado em um cluster e é desligado (os jobs também podem ser compartilhados agora, mas isso é menos usado).\nConclusão: Quando se trata de escalar para grandes fluxos de trabalho, tanto o Snowflake quanto o Databricks podem lidar com a carga de trabalho. No entanto, o Databricks é mais capaz de impulsionar e ajustar o desempenho de grandes volumes de dados, o que, em última análise, economiza custos.\nDatabricks vs Snowflake: Custo Tanto o Databricks quanto o Snowflake são comercializados como modelos de pagamento conforme o uso. Ou seja, quanto mais computação você reserva/solicita, mais você paga. Tanto no Databricks quanto no Snowflake, os usuários podem e pagarão pelos recursos solicitados, independentemente de esses recursos serem realmente necessários ou ideais para executar o trabalho.\nOutra grande diferença entre os dois serviços é que o Snowflake executa e cobra por toda a engine de computação (warehouses e instâncias de nuvem), enquanto o Databricks executa e cobra apenas pelo gerenciamento da computação, exigindo que os usuários ainda tenham que pagar uma conta separada do provedor de nuvem. Vale a pena notar que o novo produto serverless do Databricks imita o modelo operacional do Snowflake. O Databricks trabalha com unidades de computação/tempo chamadas Databricks Units (ou DBUs) por segundo e o Snowflake usa um sistema de crédito Snowflake.\nComo fórmula, ele se divide assim:\nDatabricks (computação clássica) = Armazenamento de dados + Custo do serviço Databricks (DBUs) + Custo da computação em nuvem (instâncias de máquina virtual) Snowflake = Armazenamento de dados (volume médio diário de bytes armazenados no Snowflake) + Computação (número de armazéns virtuais usados) Tanto a Databricks quanto a Snowflake oferecem níveis e descontos de preços com base no tamanho da empresa, e ambas permitem que você economize dinheiro comprando unidades ou créditos antecipadamente.\nO Databricks tem mais variação de preço, pois tem preços diferentes dependendo do tipo de carga de trabalho, com certos tipos de computação custando 5x mais por hora de computação do que os trabalhos simples.\nUma grande vantagem que o Databricks tem em termos de custos é que ele permite que os usuários utilizem instâncias Spot em seu provedor de nuvem — o que pode se traduzir em economias de custo significativas. O Snowflake ofusca tudo isso, e o usuário final não tem opção de se beneficiar da utilização de instâncias Spot.\nConclusão: Não há uma resposta concreta sobre qual serviço é \u0026ldquo;mais barato\u0026rdquo;, pois isso realmente depende de quanto do serviço ou plataforma você está usando e para quais tipos de tarefas. No entanto, os recursos de controle e introspecção que o Databricks fornece são bastante inigualáveis ​​no ecossistema Snowflake. Isso dá ao Databricks uma vantagem significativa ao otimizar para grandes cargas de trabalho de computação.\nDatabricks vs Snowflake: Facilidade de uso Com o discurso que \u0026ldquo;todas as coisas são iguais\u0026rdquo;, o Snowflake é amplamente considerado a solução de nuvem “mais fácil” de aprender entre os dois. Ele tem uma interface SQL intuitiva e, como uma experiência sem servidor, não exige que os usuários gerenciem nenhum recurso de hardware virtual ou local. Além disso, como um serviço gerenciado, usar o Snowflake não exige nenhuma instalação, manutenção, atualização ou ajuste fino da plataforma. Tudo é controlado pelo Snowflake.\nO Snowflake também tem recursos automatizados como auto-scaling e auto-suspend para ajudar a iniciar e parar clusters sem ajuste fino. Embora o Databricks também tenha autoscaling e autosuspend, ele foi projetado para um usuário mais técnico e há mais envolvido com o ajuste fino de seus clusters.\nConclusão: Embora a interface do usuário do Databricks tenha uma curva de aprendizado mais íngreme do que a do Snowflake, ela tem controle e personalização mais avançados, o que torna essa uma compensação que depende muito da complexidade que você pretende que suas operações tenham.\nDatabricks vs. Snowflake: Ecossistema e Integração Databricks e Snowflake estão se tornando as abstrações no topo dos Cloud Vendors para cargas de trabalho de computação de dados. Como tal, ambos se conectam a uma variedade de fornecedores, ferramentas e produtos.\nDo espaço do fornecedor, tanto a Databricks quanto a Snowflake fornecem Marketplaces que permitem que outras ferramentas e tecnologias predominantes sejam co-implantadas. Há também recursos criados e contribuídos pela comunidade, como os Databricks Airflow Operators / Snowflake Airflow Operators.\nNo geral, porém, o ecossistema do Databrick é tipicamente mais “aberto” do que o Snowflake, já que o Databricks ainda roda na VPC de nuvem de um usuário. Isso significa que os usuários ainda podem instalar bibliotecas personalizadas ou até mesmo introspectar dados de cluster de baixo nível. Esse acesso não é possível no Snowflake e, portanto, a integração com suas ferramentas favoritas pode ser mais difícil. O Databricks também tende a ser geralmente mais amigável ao desenvolvedor/integração do que o Snowflake por esse exato motivo.\nDatabricks vs Snowflake: Qual é o melhor? Tanto o Databricks quanto o Snowflake têm uma reputação dentro da comunidade de negócios e dados. Embora ambas sejam plataformas baseadas em nuvem, o Snowflake é mais otimizado para data warehousing, manipulação de dados e consultas, enquanto o Databricks é otimizado para machine learning e heavy data science.\nDivididos em componentes, aqui está uma lista de vantagens para cada um:\n_Comparativo Databricks vs Snowflake_\nCom isso, concluimos que se você deseja integrar dados estruturados a um pipeline ETL existente usando dados estruturados e programas como Tableau, Looker e Power BI, o Snowflake pode ser a opção certa para você. Se, em vez disso, você estiver procurando por um espaço de trabalho de análise unificado onde você constrói pipelines de computação, o Databricks pode ser a escolha certa para você.\nObrigada pela leitura ! Até a próxima !\nLinks de Referência https://docs.databricks.com/en/introduction/index.html#etl-and-data-engineering\nhttps://www.snowflake.com/en/data-cloud/snowpark/\nhttps://www.informatica.com/resources/articles/what-is-a-cloud-data-warehouse.html\nhttps://www.databricks.com/glossary/acid-transactions#:~:text=ACID%20is%20an%20acronym%20that,operations%20are%20called%20transactional%20systems.\nhttps://docs.snowflake.com/en/user-guide/warehouses-multicluster\nhttps://www.snowflake.com/blog/industry-benchmarks-and-competing-with-integrity/\nhttps://www.gartner.com/reviews/market/cloud-database-management-systems/vendor/snowflake/product/snowflake-data-cloud/alternatives\n","permalink":"https://julianamarialop.github.io/articles/confronto-de-titas-databricks-vs-snowflake-na-batalha/","summary":"Databricks e Snowflake são dois nomes em soluções de dados em nuvem. Ambas as plataformas têm sido fundamentais para ajudar as empresas a gerar valor a partir de seus ativos de dados internos e externos. Cada plataforma…","title":"Confronto de Titãs: Databricks vs. Snowflake na Batalha Mortal dos Dados"},{"content":"O Azure Synapse é a solução de Data Warehouse da Microsoft na nuvem Azure. No entanto, ele tem enfrentado concorrência interna do Databricks há algum tempo e, desde o ano passado, também do Microsoft Fabric .\nO Microsoft Synapse e o Databricks são soluções bem conhecidas para a construção de um Data Warehouse ou Data Lakehouse, ambas oferecidas pela Microsoft em sua nuvem Azure. Desde o ano passado, a Microsoft apresentou o Microsoft Fabric , que compete com ambos, mas também é integrado a eles. Embora o Databricks seja uma solução mais autônoma, este artigo foca mais na questão de se o Fabric é efetivamente o sucessor do Synapse.\nUsuários e empresas agora podem se perguntar qual serviço escolher. Com a introdução do Fabric, torna-se cada vez mais importante entender a diferença entre ele e o Azure Synapse Analytics. O Synapse é a ferramenta de nuvem da Microsoft para processamento de dados, bem testada ao longo dos anos. Constantes melhorias resultaram em inúmeras funções e correções de bugs, oferecendo diversas opções para preparar dados, sendo amplamente utilizado para construir pipelines ETL.\n_Synapse vs Fabric_\nO Fabric, por outro lado, pretende ser a solução completa para dados. Partes do Synapse são integradas ao Fabric, com funcionalidades do Azure Synapse Analytics sendo gradualmente adotadas. Ambos os produtos coexistem, e o Fabric Synapse inclui a criação de Data Lakehouses e Warehouses. O armazenamento de dados, que não é fornecido no Azure Synapse Analytics, ocorre, por exemplo, em um Azure Datalake. Tecnologicamente, no Fabric, o armazenamento é apenas uma extensão de um Azure Datalake, chamado de OneLake, gerenciado automaticamente pelo Fabric.\nAgora, você talvez pergunte por que escolher o Azure Synapse quando o Fabric oferece mais recursos, e empresas que usam o Synapse podem se perguntar se precisam de uma grande migração para o projeto Fabric. Não haverá muitas atualizações e novos recursos para o Azure Synapse, enquanto o Microsoft Fabric, por outro lado, é o produto mais novo e ainda possui alguns recursos em visualização, sendo desenvolvido rapidamente. A Microsoft planeja facilitar a migração do Synapse para o Fabric, tornando a mudança do Azure Synapse Analytics para o Microsoft Fabric mais simples no futuro, o que deve tranquilizar os usuários do Synapse.\nEm geral, o Fabric é a ferramenta para o futuro e é a escolha certa, especialmente para planejamento de longo prazo. Ao padronizar várias funções, o Fabric oferece a solução mais abrangente.\nFontes e leituras adicionais Microsoft, Azure Synapse Analytics - https://azure.microsoft.com/en-us/products/synapse-analytics#:~:text=Azure%20Synapse%20Analytics%20is%20an,log%20and%20time%20series%20analytics.\nMicrosoft, Apresentando o Microsoft Fabric: Análise de dados para a era da IA - https://azure.microsoft.com/en-us/blog/introducing-microsoft-fabric-data-analytics-for-the-era-of-ai/\nMicrosoft, Microsoft Fabric, explicado para usuários Synapse existentes - https://blog.fabric.microsoft.com/en-us/blog/microsoft-fabric-explained-for-existing-synapse-users/\n","permalink":"https://julianamarialop.github.io/articles/analise-de-dados-em-terra-arrasada-o-declinio-do-azure/","summary":"O Azure Synapse é a solução de Data Warehouse da Microsoft na nuvem Azure. No entanto, ele tem enfrentado concorrência interna do Databricks há algum tempo e, desde o ano passado, também do Microsoft Fabric .","title":"Análise de Dados em Terra Arrasada: O Declínio do Azure Synapse?"},{"content":"Introdução O Databricks Unity Catalog facilita a compreensão dos dados pela sua equipe. Ele gera automaticamente informações sobre como os dados são usados, baseando-se nos registros de consumo dos clusters. Isso reflete o uso dos clientes da Plataforma de Inteligência de Dados, oferecendo excelente capacidade de descoberta e contexto para otimizações.\nNesse artigo quero te ensina a usar os dados de linhagem para auditar o uso dos dados através das Tabelas de Sistema do Unity Catalog. Começarei com uma visão geral das tabelas de linhagem e depois mostrarei como analisar o uso de dados para entender quem está acessando quais dados, de onde e quando.\nVisão Geral Com o Databricks Unity Catalog, obtemos informações de linhagem conforme nossos usuários trabalham. As relações de dependência são rastreadas enquanto os usuários preparam e organizam os dados. Metadados são gerados automaticamente, fornecendo contexto imediato e significado aos seus dados.\nEsse contexto acelera o trabalho de usuários chave:\nAnalistas de dados e cientistas de dados: Eles podem entender a origem dos dados diretamente, reduzindo a confusão sobre qual tabela ou métrica usar para um modelo ou relatório. Isso acelera a entrega e aumenta a confiança nos dados. Governança de dados: Proprietários, administradores, responsáveis pela segurança e privacidade podem usar informações de acesso e uso das tabelas para entender a frequência de uso dos dados e rastrear padrões de acesso. A linhagem está disponível na interface do Catalog, onde é expressa como gráficos visuais que mostram as relações de dependência. A imagem abaixo mostra a linhagem para três visualizações geradas a partir das tabelas do sistema. A linhagem de tabelas e colunas também está disponível:\n_Linhagem do Unity Catalog_\nTambém podemos consultar diretamente a linhagem nas tabelas do sistema via Notebooks ou no Editor de SQL. Podemos consultar a linhagem das tabelas para ver as tabelas upstream/downstream e analisar o uso de dados, como quem, quando e como os usuários acessam os dados. O exemplo abaixo mostrará todos os acessos à tabela de uso de cobrança nos últimos sete dias:\nSELECT * FROM system.access.table_lineage WHERE source_table_full_name = \u0026#39;system.billing.usage\u0026#39; AND datediff(now(), event_date) \u0026lt; 7 Se você deseja uma visão rápida da atividade de uma tabela nos últimos 30 dias, pode acessar insights da tabela diretamente na interface do usuário. A aba UC Insights fornece informações sobre a atividade recente, usuários, consultas e mais.\nVisão geral das tabelas de linhagem As tabelas de sistema de linhagem no Databricks permitem consultar dados de linhagem no nível de tabelas e colunas nas tabelas system.lineage.table_lineage e system.lineage.column_lineage.\nAmbas as tabelas de sistema de linhagem seguem o mesmo esquema, com duas adições para linhagem no nível de colunas, conforme mostrado abaixo:\n_Tabela de Nomes e Colunas_\nPara determinar se o evento foi uma leitura ou uma gravação, você pode verificar os campos source_type e target_type.\nSomente leitura: O tipo de fonte não é nulo, mas o tipo de destino é nulo. Somente gravação: O tipo de destino não é nulo, mas o tipo de fonte é nulo. Leitura e gravação: Os tipos de fonte e destino não são nulos. No restante do artigo, explorarei alguns casos de uso destacando a auditoria de acesso a dados e a popularidade de objetos de dados, demonstrarei técnicas para analisar seus dados de linhagem e geraremos um painel que você pode personalizar para obter insights.\nNesse artigo temos quatro conjuntos de códigos: um notebook para exploração de dados da tabela de linhagem e três dashboards que mostram alguns dos resultados do notebook. Ambos podem ser usados imediatamente em qualquer workspace onde o Unity Catalog e as tabelas do sistema estejam habilitados.\nExploração de Dados — Configuração da Análise No início do notebook, configuramos variáveis para a execução das consultas subsequentes. Por favor, ajuste os valores de acordo com o seu ambiente.\nDECLARE OR REPLACE VARIABLE catalog_val STRING; DECLARE OR REPLACE VARIABLE target_catalog_val STRING; DECLARE OR REPLACE VARIABLE schema_val STRING; DECLARE OR REPLACE VARIABLE table_val STRING; DECLARE OR REPLACE VARIABLE column_val STRING; DECLARE OR REPLACE VARIABLE email_val STRING; DECLARE OR REPLACE VARIABLE table_full_name_val STRING; SET VARIABLE catalog_val = \u0026#39;system\u0026#39;; SET VARIABLE target_catalog_val = \u0026#39;pdavis\u0026#39;; SET VARIABLE schema_val = \u0026#39;billing\u0026#39;; SET VARIABLE table_val = \u0026#39;usage\u0026#39;; SET VARIABLE column_val = \u0026#39;usage_quantity\u0026#39;; SET VARIABLE table_full_name_val = concat(catalog_val, \u0026#39;.\u0026#39;, schema_val, \u0026#39;.\u0026#39;, table_val) SET VARIABLE email_val = \u0026#39;demo@databricks.com\u0026#39;; Acessos às Tabelas por Usuários: Veja quais usuários acessaram uma tabela e qual interface do Databricks usaram nos últimos 7 dias:\nUsuários: Identifique os usuários que acessaram a tabela. Interfaces: Verifique se usaram notebooks, jobs, ou outras interfaces do Databricks para acessar a tabela. Isso ajudará a entender o comportamento de acesso e uso das tabelas por diferentes usuários dentro do período de uma semana.\nSELECT mask(created_by) as created_by, -- Masking function - nice feature entity_type, source_type, COUNT(distinct event_time) as access_count, MIN(event_date) as first_access_date, MAX(event_date) as last_access_date FROM system.access.table_lineage WHERE source_table_catalog = catalog_val AND source_table_schema = schema_val AND source_table_name = table_val AND datediff(now(), event_date) \u0026lt; 7 AND entity_type IS NOT NULL AND source_type IS NOT NULL GROUP BY ALL -- Nice feature ORDER BY ALL -- Nice feature Aqui, obtemos um resultado com os endereços de e-mail (created_by), interfaces (entity_type), datas do primeiro e último acesso, e a contagem de acessos à tabela.\nLimitei o período total para uma semana para minimizar o uso de recursos durante a exploração, e uso uma função de mascaramento para ocultar os endereços de e-mail no campo created_by para este artigo.\nAcessos às tabelas em um catálogo e esquema específicos:\nSELECT source_table_name, entity_type, created_by, source_type, COUNT(distinct event_time) as access_count, MIN(event_date) as first_access_date, MAX(event_date) as last_access_date FROM system.access.table_lineage WHERE source_table_catalog = catalog_val AND source_table_schema = schema_val AND datediff(now(), event_date) \u0026lt; 30 GROUP BY ALL ORDER BY ALL Aqui, vemos todas as tabelas acessadas dentro de um catálogo e esquema específicos nos últimos 30 dias, quem as acessou e as datas do primeiro e último acesso.\nAcessos às Tabelas por Usuários Específicos Quais tabelas um usuário específico acessou no catálogo do sistema nos últimos 90 dias:\nSELECT source_table_catalog, source_table_schema, source_table_name, entity_type, source_type, mask(created_by) as created_by, COUNT(distinct event_time) as access_count, MIN(event_date) as first_access_date, MAX(event_date) as last_access_date FROM system.access.table_lineage WHERE created_by = email_val AND datediff(now(), event_date) \u0026lt; 90 and entity_type is not NULL and source_table_catalog = \u0026#39;system\u0026#39; GROUP BY ALL ORDER BY ALL Linhagem de Objetos Para um único objeto, quais são os objetos imediatamente upstream (anteriores) e downstream (posteriores)?\nwith downstream AS ( select distinct target_table_catalog as table_catalog, target_table_schema as table_schema, target_table_name as table_name, \u0026#39;downstream\u0026#39; as direction, CASE WHEN tbl.table_catalog is null then \u0026#39;no\u0026#39; else \u0026#39;yes\u0026#39; end as current from system.access.table_lineage tl left join system.information_schema.tables tbl on tl.target_table_full_name = concat(tbl.table_catalog, \u0026#39;.\u0026#39;, tbl.table_schema, \u0026#39;.\u0026#39;, tbl.table_name) where source_table_full_name = table_full_name_val AND target_table_full_name is not null order by current desc, table_catalog, table_schema, table_name ) , upstream AS ( select distinct source_table_catalog as table_catalog, source_table_schema as table_schema, source_table_name as table_name, \u0026#39;upstream\u0026#39; as direction, CASE WHEN tbl.table_catalog is null then \u0026#39;no\u0026#39; else \u0026#39;yes\u0026#39; end as current from system.access.table_lineage tl left join system.information_schema.tables tbl on tl.source_table_full_name = concat(tbl.table_catalog, \u0026#39;.\u0026#39;, tbl.table_schema, \u0026#39;.\u0026#39;, tbl.table_name) where target_table_full_name = table_full_name_val AND source_table_full_name is not null order by current desc, table_catalog, table_schema, table_name ) select * from upstream UNION ALL select * from downstream Vamos juntar tudo ? — Dashboards Os dashboards a seguir ajudarão você a começar a analisar as tabelas de linhagem do Unity Catalog. Os usuários são incentivados a experimentar os dashboards e, em seguida, personalizá-los conforme o que for mais útil em seu ambiente.\nTemos três dashboards com os seguintes recursos:\nLinhagem de tabelas Linhagem de colunas Tags e linhagem de colunas Linhagem de tabelas Juntando tudo, criei um dashboard para mostrar:\nAcessos às tabelas por data Colunas em uso na tabela Quem acessou a tabela e por quais interfaces Tabelas upstream/downstream relacionadas (incluindo dependências depreciadas) Importando o dashboard e inserindo qualquer nome de tabela com 3 níveis, você pode revisar as mesmas informações sobre as tabelas (desde que tenha permissão para ver os metadados da tabela).\n_Dahsboard Linhagem de Tabelas_\nLinhagem de colunas Adicionei um dashboard para revisar as informações de linhagem das colunas. Este dashboard mostra:\nA contagem de tabelas com o mesmo nome de coluna Quantos objetos dependem dessa coluna Total de acessos à coluna durante o período especificado Um gráfico de acessos ao longo do tempo Uma tabela mostrando a frequência de uso downstream da coluna Uma tabela mostrando quem acessou a coluna, a partir de qual interface, quantos acessos foram feitos, e as datas do primeiro e último acesso dentro do período Também mostra tabelas que possuem o mesmo nome de coluna e as contagens de frequência de uso.\n_Dashboard Linhagem de Colunas_\nDashboard de Tags e Linhagem Finalmente, criei um dashboard para revisar tags no sistema:\nMapa de calor de nome e valor das tags: Ajuda a entender como as pessoas usam as tags e a reduzir o ruído potencial das tags na empresa. Lista de nomes de colunas com tags: Mostra as colunas que foram marcadas com determinado nome ou valor (mascarado neste exemplo). Total de acessos às colunas com tags: Mostra quantas vezes as colunas marcadas foram acessadas durante o período especificado. Listas de Catálogos, Esquemas e Tabelas com tags: Exibe os objetos que foram marcados (mascarados para o exemplo). Lista de colunas com tags acessadas: Mostra quem e como acessaram essas colunas (novamente, mascarado para o exemplo). _Dashboard de Tags e Linhagem_\nLimitações Atuais As Tabelas de Sistema de Linhagem estão atualmente em Public Preview. À medida que as tabelas avançam para GA, colunas, esquemas e dados retidos podem mudar.\nNem todos os tipos de entidades são rastreáveis no momento; o tipo de entidade será NULL para tipos não rastreados.\nConclusão Neste artigo, exploramos como o Databricks Unity Catalog simplifica a auditoria e o entendimento do uso dos dados. Usando as Tabelas de Sistema do Unity Catalog, podemos rastrear e analisar a linhagem dos dados. Isso nos ajuda a ver claramente quem está acessando quais dados, de onde e quando, o que melhora a governança dos dados e a eficiência do trabalho dos analistas e cientistas de dados.\nMostramos como consultar a linhagem diretamente nas tabelas do sistema, seja por meio de Notebooks ou do Editor de SQL. Isso permite uma análise detalhada dos acessos e usos dos dados. Também apresentamos exemplos práticos de consultas para monitorar acessos às tabelas, a popularidade dos objetos de dados e os padrões de acesso.\nOs dashboards que mostramos são ferramentas valiosas para visualização e análise, oferecendo insights sobre acessos às tabelas, uso de colunas específicas e a utilização de tags no sistema. Mesmo estando em Public Preview, as Tabelas de Sistema de Linhagem já oferecem um suporte significativo para a governança de dados e a otimização de processos na plataforma Databricks .\nCom essas capacidades, as equipes podem tomar decisões mais informadas, aumentar a confiança nos dados e fazer um melhor uso dos recursos disponíveis. O Unity Catalog, com suas capacidades de linhagem, é essencial para qualquer estratégia moderna de gerenciamento de dados.\nEspero que esse artigo ajude na implementação de sua governança !\nObrigada pela leitura !\n","permalink":"https://julianamarialop.github.io/articles/desvendando-o-databricks-unity-catalog-simplificando-governanca-tl24f/","summary":"O Databricks Unity Catalog facilita a compreensão dos dados pela sua equipe. Ele gera automaticamente informações sobre como os dados são usados, baseando-se nos registros de consumo dos clusters. Isso reflete o uso dos…","title":"Desvendando o Databricks Unity Catalog: Simplificando a Governança e Auditoria de Dados"},{"content":"Existem várias maneiras de pausar, retomar ou dimensionar uma Capacidade Microsoft Fabric . Note que isso se aplica apenas aos F-SKUs no Azure, pois a Capacidade Premium (P-SKU) só pode ser dimensionada.\nÉ possível fazer isso usando um pipeline do Fabric Data Factory, para que você possa orquestrar uma ou várias capacidades e cargas de trabalho.\nPressupõe-se que os conceitos de capacidades Fabric, workspaces e cargas de trabalho já são compreendidos, bem como um bom conhecimento prático do Azure. Você também precisará de uma Capacidade Fabric, idealmente uma que esteja sempre ativa.\nAbordagem geral: Provisionar uma Capacidade Fabric no Azure Criar um Principal de Serviço no Azure Conceder permissões apropriadas (RBAC) ao Principal de Serviço Criar um pipeline do Fabric Data Factory que execute uma atividade web para postar na API relevante (atualmente não formalmente suportada) Isso permitirá que você crie um Pipeline que pode ser chamado de qualquer lugar no Fabric para pausar, retomar ou dimensionar uma Capacidade.\nPara provisionar uma capacidade, escolha Microsoft Fabric na lista de serviços e especifique:\nAssinatura e Grupo de Recursos Nome e Região da Capacidade (note que isso pode ser em qualquer lugar globalmente, mas pode ser melhor começar em um lugar onde seu tenant do Power BI já esteja localizado (Verifique em Ajuda e Suporte no Power BI, procure por “Sobre o Power BI”) Tamanho (F2-F2048) Um Administrador de Capacidade Fabric Principal de Serviço: Crie um SPN usando o método que preferir. Meu favorito é usando o Azure CLI.\nPermissões: Certifique-se de que seu principal de serviço tenha direitos de colaborador na Capacidade Fabric.\nCriar um Pipeline de Dados: Navegue até o Workspace no Microsoft Fabric onde você pretende criar o Pipeline. Crie um novo pipeline ManageCapacityPauseResume.\nAdicione alguns parâmetros para tornar seu pipeline mais flexível, preenchendo-os adequadamente.\nAdicione uma Atividade Web ao canvas. Você precisará especificar o principal de serviço que você criou anteriormente.\nPara a URL Base, adicione https://management.azure.com, e para o URI do público do token, adicione https://management.azure.com;https://management.core.windows.net/.\nPara a URL relativa na Atividade Web, adicione a seguinte expressão:\n@concat(‘/subscriptions/’,pipeline().parameters.subscription_id,’/resourceGroups/’,pipeline().parameters.resourcegroup,’/providers/Microsoft.Fabric/capacities/’,pipeline().parameters.capacities,’/’,pipeline().parameters.action,’?api-version=2022–07–01-preview’) Note que ao colar a expressão acima, alguns usuários relataram problemas com as aspas simples.\nEscolha o método POST e coloque {} no corpo.\nObserve o parâmetro de ação, que pode ser “suspend” ou “resume” para pausar ou retomar conforme desejado.\nAgora você pode salvar e executar o pipeline para testá-lo. Se sua capacidade estiver em execução, execute um \u0026ldquo;suspend\u0026rdquo;. Observe como o portal do Azure mostra que a capacidade está pausada.\nNote que, se a capacidade não estiver em execução e você tentar pausá-la, a atividade falhará. Para lidar com isso, você pode tratar esse erro específico e falhar o pipeline apenas se ele ocorrer, como na imagem abaixo.\nPara dimensionar uma capacidade, use um pipeline semelhante ao descrito acima. Mude a expressão na Atividade Web para:\n@concat(‘/subscriptions/’,pipeline().parameters.subscription_id,’/resourceGroups/’,pipeline().parameters.resourcegroup,’/providers/Microsoft.Fabric/capacities/’,pipeline().parameters.capacities,’?api-version=2022–07–01-preview’) Use o método PATCH.\nVocê também precisará adicionar um novo parâmetro para o valor do SKU.\nAltere o Corpo para:\n@json(concat(‘{“sku”:{“name”:”’,pipeline().parameters.sku,’”,”tier”:”Fabric”}}’)) Tópicos Adicionais É possível passar variáveis e arrays entre pipelines, bem como agendá-los. Isso significa que, se você tiver workspaces de desenvolvimento que residem em uma capacidade ou capacidades específicas, você pode agendar o pipeline de pausa para ser executado diariamente em um horário definido para economizar custos, ou para dimensionar capacidades conforme necessário.\nConsiderações Finais Embora as APIs usadas aqui para as capacidades Fabric ainda não estejam formalmente documentadas no momento da escrita, o uso de pipelines Fabric forma uma alternativa útil de orquestração ao uso mais comum de Logic Apps para esse propósito. Isso significa que você pode usar uma solução SaaS do Fabric para gerenciamento de capacidades Fabric.\n","permalink":"https://julianamarialop.github.io/articles/microsoft-fabric-pausar-retomar-escalar-uma-capacidade/","summary":"Existem várias maneiras de pausar, retomar ou dimensionar uma Capacidade Microsoft Fabric . Note que isso se aplica apenas aos F-SKUs no Azure, pois a Capacidade Premium (P-SKU) só pode ser dimensionada.","title":"Microsoft Fabric - Pausar, Retomar, Escalar uma Capacidade com um Pipeline do Fabric Data Factory"},{"content":"O Microsoft Fabric é a solução completa para todas as necessidades analíticas da sua empresa, unificando todo o processo em uma única plataforma. Desde a ingestão de dados no data lake até a entrega de informações para os usuários de negócios, tudo pode ser feito no Microsoft Fabric. Com a capacidade de integrar dados de diversas fontes, como Amazon AWS e Azure, ele reúne todas as informações em um só lugar.\nComo um SaaS (Software como Serviço), o Microsoft Fabric combina o poder do Power BI com muitas funcionalidades do Synapse e outras áreas do Azure, sem a necessidade de instalar ou configurar software.\nUma das principais características do Microsoft Fabric é a separação entre armazenamento e computação, permitindo a execução de diferentes cargas de trabalho computacionais nos mesmos conjuntos de dados. O OneLake é a camada de armazenamento construída sobre o ADLS (Azure Data Lake Storage) Gen2, fornecendo um local único para que uma organização armazene todos os dados, tanto estruturados quanto não estruturados. Isso elimina silos de dados, simplifica a segurança, a governança e a descoberta de dados, permitindo que todos os usuários e aplicativos acessem os dados necessários.\nO Data Mesh é uma descentralização orientada por domínios para o acesso a dados. A arquitetura de Data Mesh transfere a responsabilidade do acesso aos dados das equipes de tecnologia para as equipes de negócios.\nOs quatro princípios do Data Mesh são:\nPropriedade do domínio: As equipes de domínio assumem a responsabilidade por seus dados, possuindo tanto dados analíticos quanto operacionais. Dados como produto: Cada equipe define não apenas os dados que possuem, mas também os dados que produzem e consomem de outras equipes. As equipes de domínio são responsáveis por fornecer dados de alta qualidade para satisfazer as necessidades de outros domínios. Infraestrutura de dados self-service: Uma equipe dedicada fornece funcionalidades, ferramentas e sistemas agnósticos ao domínio, permitindo que as equipes de domínio consumam e criem produtos de dados de forma integrada. Governança federada de dados: Promove a padronização e a interoperabilidade de todos os produtos de dados em todo o Data Mesh, criando um ecossistema de dados que segue as regras organizacionais e regulamentos da indústria. Adotar o padrão Data Mesh permite que os grupos de negócios trabalhem de forma independente com vários lakes de dados orientados por domínios de negócios.\nOs dados são organizados por domínios e o controle é direto sobre os dados, proporcionando acesso fácil e governança completa no nível dos dados, e não no nível das aplicações.\nHabilitando Data Mesh com OneLake no Microsoft Fabric OneLake oferece um verdadeiro data mesh como serviço.\nUma organização pode ter muitos domínios de dados (VENDAS, FINANÇAS, MARKETING, RECURSOS HUMANOS, etc.). Um único conjunto de dados pode ser utilizado entre diferentes domínios, nuvens e motores. Um único produto de dados pode abranger múltiplos domínios. Os \u0026ldquo;atalhos\u0026rdquo; fornecem as conexões entre os domínios, permitindo que os dados sejam virtualizados em um único produto de dados.\nTodos os motores podem acessar os mesmos dados sem a necessidade de importá-los ou exportá-los. Você pode escolher o motor certo para a tarefa certa. Os motores trabalham com os dados otimizados em Delta Parquet como formato nativo.\nPor hoje é só pessoal ! Obrigada pela leitura !\n","permalink":"https://julianamarialop.github.io/articles/desbravando-horizontes-transforme-sua-organizacao-com/","summary":"O Microsoft Fabric é a solução completa para todas as necessidades analíticas da sua empresa, unificando todo o processo em uma única plataforma. Desde a ingestão de dados no data lake até a entrega de informações para…","title":"Desbravando Horizontes: Transforme sua Organização com Data Mesh no Microsoft Fabric"},{"content":"Este artigo reflete minhas experiências e pontos de vista pessoais, e não a posição oficial da Microsoft ou da Databricks. Além disso, embora esta postagem descreva cenários potenciais, ela não reflete necessariamente o roadmap ou as intenções do Fabric. Nem todas as opções mencionadas podem se tornar operacionais no futuro.\nNo cenário dinâmico e em constante evolução da tecnologia, a integração de diferentes ferramentas e plataformas se torna essencial para maximizar a eficiência e a inovação. No artigo \u0026ldquo;Futuro Conectado: Unity Catalog e Microsoft Fabric Trabalhando Juntos\u0026rdquo;, vamos explorar como a combinação do Unity Catalog, uma solução robusta para gestão de dados da Databricks, e o Microsoft Fabric, uma plataforma poderosa para aplicações de nuvem e dados da Microsoft, está transformando a forma como as organizações gerenciam, analisam e utilizam seus dados. Essa colaboração promete não apenas otimizar o armazenamento e a governança dos dados, mas também acelerar o desenvolvimento de insights e a tomada de decisões estratégicas, criando um futuro mais conectado e inteligente para empresas de todos os setores.\nOs cenários de integração podem ser essencialmente visualizados com base no ponto de entrada, Unity Catalog e Fabric:\nAcessando o Unity Catalog a partir do Fabric (Fabric → Unity Catalog): Essa funcionalidade pode permitir que os usuários acessem perfeitamente o catálogo, os esquemas e as tabelas do Unity Catalog de dentro do Fabric.\nUtilizando o Fabric a partir do Unity Catalog (DBX/Unity Catalog → Fabric): Esse recurso pode oferecer aos usuários a capacidade de acessar e usar o OneLake diretamente do Unity Catalog e executar consultas federadas sobre um endpoint SQL ou o Fabric Data Warehouse.\nVamos explorar esses cenários mais detalhadamente.\nFabric → Unity Catalog Usando o Unity Catalog a partir do Fabric\nSe você está no Fabric, aqui estão algumas opções para acessar as tabelas do Unity Catalog a partir do Fabric. Você também pode ler/gravar diretamente do Spark do Fabric para o ADLS Gen2.\nOpções atuais\nAtualmente, os usuários têm duas opções para criar atalhos para tabelas do Unity Catalog: manual ou semiautomática, sendo esta última realizável por meio de um notebook. Com o método semiautomático, os usuários podem integrar tabelas externas UC Delta ao OneLake criando atalhos. Eles especificam os nomes do catálogo e do esquema para sincronização, o que gera atalhos para tabelas nesses esquemas dentro do lakehouse do Fabric.\nVeja instruções adicionais sobre a execução do notebook utilitário.\n# configuration dbx_workspace = \u0026#34;\u0026lt;databricks_workspace_url\u0026gt;\u0026#34; dbx_token = \u0026#34;\u0026lt;pat_token\u0026gt;\u0026#34; dbx_uc_catalog = \u0026#34;catalog_example\u0026#34; dbx_uc_schemas = \u0026#39;[\u0026#34;schema1\u0026#34;, \u0026#34;schema2\u0026#34;]\u0026#39; fab_workspace_id = \u0026#34;\u0026lt;workspace_id\u0026gt;\u0026#34; fab_lakehouse_id = \u0026#34;\u0026lt;lakehouse_id\u0026gt;\u0026#34; fab_shortcut_connection_id = \u0026#34;\u0026lt;connection_id\u0026gt;\u0026#34; fab_consider_dbx_uc_table_changes = True # sync UC tables to lakehouse sc.addPyFile(\u0026#39;https://raw.githubusercontent.com/microsoft/fabric-samples/main/docs-samples/onelake/unity-catalog/util.py\u0026#39;) from util import * databricks_config = { \u0026#39;dbx_workspace\u0026#39;: dbx_workspace, \u0026#39;dbx_token\u0026#39;: dbx_token, \u0026#39;dbx_uc_catalog\u0026#39;: dbx_uc_catalog, \u0026#39;dbx_uc_schemas\u0026#39;: json.loads(dbx_uc_schemas) } fabric_config = { \u0026#39;workspace_id\u0026#39;: fab_workspace_id, \u0026#39;lakehouse_id\u0026#39;: fab_lakehouse_id, \u0026#39;shortcut_connection_id\u0026#39;: fab_shortcut_connection_id, \u0026#34;consider_dbx_uc_table_changes\u0026#34;: fab_consider_dbx_uc_table_changes } sync_dbx_uc_tables_to_onelake(databricks_config, fabric_config) Opções futuras potenciais\nItem nativo do Unity Catalog no Fabric: semelhante à migração de metadados do Hive Metastore para o lakehouse do Fabric, os metadados do Unity Catalog podem ser sincronizados com o lakehouse do Fabric, permitindo o acesso às tabelas do Unity Catalog. Uma prévia desse cenário foi demonstrada na FabCon, mostrando como os usuários poderiam acessar e consultar diretamente as tabelas do Unity Catalog usando a interface do Fabric.\nAtalho do Unity Catalog no Fabric: semelhante aos atalhos do Dataverse, a experiência de usuário de atalhos do OneLake poderia, potencialmente, suportar a criação de atalhos para tabelas do Unity Catalog.\nDatabricks Unity Catalog → Fabric Utilizando o Fabric e o OneLake a partir do Databricks Unity Catalog\nO Unity Catalog oferece diferentes maneiras de conectar e aproveitar as conexões de armazenamento de objetos na nuvem (por exemplo, ADLS Gen2), bem como se conectar a sistemas de dados externos para executar consultas federadas (por exemplo, Azure Synapse).\nOpções atuais\nAtualmente, os usuários podem usar o OneLake a partir de clusters habilitados para Unity Catalog da seguinte forma: (i) leitura/escrita para o OneLake usando autenticação baseada em Service Principal (SPN), e (ii) leitura/escrita para o OneLake usando pontos de montagem com autenticação SPN.\n# r/w using spn workspace_name = \u0026#34;\u0026lt;workspace_name\u0026gt;\u0026#34; lakehouse_name = \u0026#34;\u0026lt;lakehouse_name\u0026gt;\u0026#34; tenant_id = \u0026#34;\u0026lt;tenant_id\u0026gt;\u0026#34; service_principal_id = \u0026#34;\u0026lt;service_principal_id\u0026gt;\u0026#34; service_principal_password = \u0026#34;\u0026lt;service_principal_password\u0026gt;\u0026#34; spark.conf.set(\u0026#34;fs.azure.account.auth.type\u0026#34;, \u0026#34;OAuth\u0026#34;) spark.conf.set(\u0026#34;fs.azure.account.oauth.provider.type\u0026#34;, \u0026#34;org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider\u0026#34;) spark.conf.set(\u0026#34;fs.azure.account.oauth2.client.id\u0026#34;, service_principal_id) spark.conf.set(\u0026#34;fs.azure.account.oauth2.client.secret\u0026#34;, service_principal_password) spark.conf.set(\u0026#34;fs.azure.account.oauth2.client.endpoint\u0026#34;, f\u0026#34;https://login.microsoftonline.com/{tenant_id}/oauth2/token\u0026#34;) # read df = spark.read.format(\u0026#34;parquet\u0026#34;).load(f\u0026#34;abfss://{workspace_name}@onelake.dfs.fabric.microsoft.com/{lakehouse_name}.Lakehouse/Files/data\u0026#34;) df.show(10) # write df.write.format(\u0026#34;delta\u0026#34;).mode(\u0026#34;overwrite\u0026#34;).save(f\u0026#34;abfss://{workspace_name}@onelake.dfs.fabric.microsoft.com/{lakehouse_name}.Lakehouse/Tables/dbx_delta_spn\u0026#34;) # mount with spn workspace_id = \u0026#34;\u0026lt;workspace_id\u0026gt;\u0026#34; lakehouse_id = \u0026#34;\u0026lt;lakehouse_id\u0026gt;\u0026#34; tenant_id = \u0026#34;\u0026lt;tenant_id\u0026gt;\u0026#34; service_principal_id = \u0026#34;\u0026lt;service_principal_id\u0026gt;\u0026#34; service_principal_password = \u0026#34;\u0026lt;service_principal_password\u0026gt;\u0026#34; configs = { \u0026#34;fs.azure.account.auth.type\u0026#34;: \u0026#34;OAuth\u0026#34;, \u0026#34;fs.azure.account.oauth.provider.type\u0026#34;: \u0026#34;org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider\u0026#34;, \u0026#34;fs.azure.account.oauth2.client.id\u0026#34;: service_principal_id, \u0026#34;fs.azure.account.oauth2.client.secret\u0026#34;: service_principal_password, \u0026#34;fs.azure.account.oauth2.client.endpoint\u0026#34;: f\u0026#34;https://login.microsoftonline.com/{tenant_id}/oauth2/token\u0026#34; } mount_point = \u0026#34;/mnt/onelake-fabric\u0026#34; dbutils.fs.mount( source = f\u0026#34;abfss://{workspace_id}@onelake.dfs.fabric.microsoft.com\u0026#34;, mount_point = mount_point, extra_configs = configs ) # read df = spark.read.format(\u0026#34;parquet\u0026#34;).load(f\u0026#34;/mnt/onelake-fabric/{lakehouse_id}/Files/data\u0026#34;) df.show(10) # write df.write.format(\u0026#34;delta\u0026#34;).mode(\u0026#34;overwrite\u0026#34;).save(f\u0026#34;/mnt/onelake-fabric/{lakehouse_id}/Tables/dbx_delta_mount_spn\u0026#34;) Nota: Criar uma tabela externa usando o caminho OneLake abfss ou o caminho de montagem agora resultará em uma exceção no Unity Catalog. Atualmente, você não pode registrar uma tabela externa no Unity Catalog com o OneLake como armazenamento subjacente. Isso pode levar a cenários potenciais futuros.\nINVALID_PARAMETER_VALUE: Missing cloud file system scheme\nFailed to acquire a SAS token for list. Invalid Azure Path\nOpções futuras potenciais\nSemelhante ao ADLS Gen2 e ao Azure Synapse, diferentes opções poderiam existir no futuro:\nOneLake como armazenamento gerenciado padrão: O Databricks começou a implementar a habilitação automática do Unity Catalog, ou seja, um metastore do Unity Catalog provisionado automaticamente com armazenamento gerenciado pelo Databricks (por exemplo, ADLS Gen2). No entanto, o usuário também pode criar armazenamento gerenciado pelo usuário no nível do metastore ao criar o metastore do Unity Catalog apontando para o OneLake neste caso. Isso ainda não é possível.\nOneLake como localização externa: Localizações externas são usadas para definir locais de armazenamento gerenciado para catálogos e esquemas, e para definir locais para tabelas externas e volumes externos. Por exemplo, se os usuários estiverem usando tabelas externas no Spark, o OneLake poderia ser aproveitado como uma localização externa.\nOneLake para Volumes: Volumes representam um volume lógico de armazenamento em uma localização de armazenamento de objetos na nuvem, adicionando governança sobre conjuntos de dados não tabulares. Volumes externos e gerenciados poderiam existir usando o OneLake, por exemplo, como para o ADLS Gen2.\nFederated Lakehouse: Acesso somente leitura a dados em endpoint SQL ou Fabric Data Warehouse usando catálogos estrangeiros do Unity Catalog pode ser uma opção futura. A autenticação atual do Azure Synapse e do SQL é baseada em nome de usuário/senha e o SPN ainda não é suportado, então essa opção ainda não é possível. Catálogos estrangeiros não suportam armazenamento de objetos agora, então ainda não está claro se o catálogo estrangeiro para OneLake/Lakehouse será possível.\n","permalink":"https://julianamarialop.github.io/articles/futuro-conectado-unity-catalog-e-microsoft-fabric-juntos/","summary":"Este artigo reflete minhas experiências e pontos de vista pessoais, e não a posição oficial da Microsoft ou da Databricks. Além disso, embora esta postagem descreva cenários potenciais, ela não reflete necessariamente o…","title":"Futuro Conectado: Unity Catalog e Microsoft Fabric Trabalhando Juntos"},{"content":"Chegamos ao final da série \u0026ldquo;Integrando Azure Databricks e Microsoft Fabric\u0026rdquo;. Ao longo dessa jornada, exploramos como essas duas poderosas ferramentas podem ser combinadas para otimizar processos de análise de dados, armazenamento e visualização. Se você ainda não leu os artigos anteriores, começe por aqui.\nA próxima consideração de design enfoca a importância de utilizar o Microsoft Fabric e a funcionalidade V-Order. Esta funcionalidade é uma otimização no momento da gravação para o formato de arquivo parquet, permitindo leituras rápidas de dados nos motores de computação do Microsoft Fabric, como o Power BI.\nTanto o Databricks quanto a Microsoft escolheram adotar o Delta Lake, um formato de arquivo colunar de código aberto. No entanto, a Microsoft adicionou uma camada extra de compressão V-Order, proporcionando até 50% mais compressão. O V-Order é totalmente compatível com o formato parquet de código aberto; todos os motores parquet podem lê-lo como arquivos parquet comuns.\nVale notar que é possível aplicar a ordenação V em tabelas que não a possuem, utilizando a funcionalidade de manutenção do Fabric.\nO V-Order traz benefícios notáveis para o Microsoft Fabric, especialmente para componentes como o Power BI e os endpoints SQL. Por exemplo, permite que o Power BI se conecte diretamente a dados em tempo real usando o modo Direct Lake, mantendo um alto desempenho nas consultas de dados. Como não há necessidade de processo de importação, as alterações na fonte de dados são refletidas instantaneamente no Power BI, eliminando a espera por uma atualização.\nÉ fundamental destacar que o uso de tabelas otimizadas com V-Order é, por enquanto, exclusivo do Microsoft Fabric. O Databricks ainda não implementou essa funcionalidade. Portanto, até que isso ocorra, será necessário utilizar um serviço dentro do Microsoft Fabric para aproveitar as tabelas otimizadas com V-Order.\nVale ressaltar que, caso a otimização V-Order não seja essencial, a etapa de processamento com Databricks entre os estágios Silver e Gold ainda pode ser relevante. Embora isso possa parecer redundante, é uma opção viável para continuar o processamento de dados com Databricks.\nOutro motivo significativo pelo qual as organizações escolhem esse design é a consistência transacional entre várias tabelas. Manter essa consistência, especialmente no estágio Gold, é crucial. Atualmente, o Spark só suporta transações em tabelas individuais. Assim, se houver inconsistências de dados entre tabelas, elas precisam ser resolvidas por meio de medidas compensatórias. Por exemplo, você pode confirmar inserções em várias tabelas ou em nenhuma delas se ocorrer um erro. Se estiver alterando detalhes de um pedido de compra que afetam três tabelas, é possível agrupar essas alterações em uma única transação. Isso significa que, ao consultar essas tabelas, elas terão todas as mudanças ou nenhuma delas. Essa preocupação com a integridade destaca a importância de um ambiente capaz de gerenciar transações complexas em várias tabelas. O Microsoft Fabric Warehouse é a única plataforma que suporta isso sobre o Delta Lake. Para saber mais, clique aqui.\nNa arquitetura atualizada, ilustrada na imagem acima, o Synapse Engineering agora atua como o motor de processamento do estágio Silver para o Gold. Essa abordagem garante que todas as tabelas sejam otimizadas com V-Order. Além disso, o Synapse Warehouse foi adicionado para casos de uso que exigem capacidades transacionais. No entanto, essas mudanças arquitetônicas exigem que os engenheiros de dados naveguem por diferentes serviços de processamento de dados. Portanto, é essencial fornecer orientações claras para todas as equipes. Por exemplo, você pode estabelecer diretrizes para os estágios Bronze e Silver, utilizando os recursos nativos do Databricks, como rastreamento de ingestão com AutoLoader e validações com Delta Live Tables para garantir a qualidade dos dados. E, para o estágio Gold, focar na construção de lógica de integração específica para o consumo exclusivamente com o Microsoft Fabric.\nConclusão A integração do Azure Databricks com o Microsoft Fabric oferece uma ampla gama de benefícios e possibilidades para as organizações. A combinação da flexibilidade e escalabilidade do Azure Databricks com a simplicidade e os recursos intuitivos do Microsoft Fabric pode aprimorar consideravelmente o uso e a gestão de dados em todas as camadas. Existem diversas opções de design arquitetônico, desde a melhoria de uma arquitetura centrada no Databricks com uma camada do Microsoft Fabric, até a incorporação de uma camada gold do OneLake na arquitetura para melhorar o desempenho e a segurança.\nAlém disso, a introdução da otimização V-Order no Microsoft Fabric e o uso de componentes adicionais podem simplificar e aumentar significativamente a eficiência do processamento de dados. No entanto, essas combinações ou integrações exigem uma consideração cuidadosa, pois podem envolver a navegação entre serviços e o equilíbrio entre flexibilidade, segurança de dados e isolamento.\nFinalizamos nossa serie de artigos explorando a integração entre Databricks e Microsoft Fabric ! Obrigada pela leitura !\n","permalink":"https://julianamarialop.github.io/articles/integrando-azure-databricks-e-microsoft-fabric-um-encontro-5hvbf/","summary":"Chegamos ao final da série \u0026ldquo;Integrando Azure Databricks e Microsoft Fabric\u0026rdquo;. Ao longo dessa jornada, exploramos como essas duas poderosas ferramentas podem ser combinadas para otimizar processos de análise de dados…","title":"Integrando Azure Databricks e Microsoft Fabric: Um encontro de Gigantes ! - Parte IV - Extensão com V-ORDERED"},{"content":"Isenção de responsabilidade: este artigo reflete minhas experiências e pontos de vista pessoais, não uma posição oficial da Microsoft Fabric ou Databricks.\nChegamos à terceira parte de nossa série sobre a integração de duas das mais poderosas ferramentas de dados da Microsoft: Microsoft Fabric eDatabricks. Na Parte I, exploramos as fundações dessa integração, abordando os conceitos básicos.\nSe você ainda não leu a primeira e segunda parte, recomendo fortemente que o faça antes de prosseguir, pois muitos dos conceitos abordados aqui partem do que foi discutido anteriormente. Prepare-se para elevar suas habilidades e conhecimentos a um novo patamar e aproveitar ao máximo o poder combinado do Azure Databricks e do Microsoft Fabric. Deixo os links para leitura aqui: Parte I e Parte II\nA segunda arquitetura mostrada abaixo modifica o padrão de design referenciado no artigo anterior dessa serie ao incorporar uma camada gold no OneLake na arquitetura. Isso é viável devido ao driver Azure Blob Filesystem (ABFS) do Azure Databricks, que suporta tanto o ADLS quanto o OneLake.\nDentro dessa arquitetura, o fluxo de trabalho e as etapas de processamento de dados — ingestão, processamento, validação e enriquecimento — permanecem essencialmente os mesmos, todos gerenciados pelo Azure Databricks. A principal mudança é que os dados para consumo agora estão mais integrados ao Microsoft Fabric, pois o Databricks grava os dados em uma camada Gold armazenada no OneLake. Pode surgir a dúvida se isso é uma prática recomendada e quais são os benefícios.\nÉ crucial mencionar que essa forma de integração não é oficialmente suportada pelo Databricks, o que traz algumas implicações para o gerenciamento de dados, que serão abordadas a seguir.\nO Databricks diferencia dois tipos de tabelas: tabelas gerenciadas e tabelas externas. As tabelas gerenciadas são criadas por padrão e administradas pelo Unity Catalog, que gerencia seu ciclo de vida e layout de arquivos. Não é recomendado manipular diretamente os arquivos dessas tabelas usando ferramentas externas. Já as tabelas externas armazenam dados fora do local de armazenamento gerenciado especificado para o metastore, catálogo ou esquema.\nConforme a documentação, todas as tabelas criadas escrevendo diretamente para o OneLake devem ser classificadas como tabelas externas, uma vez que os dados são gerenciados fora do escopo do metastore. Dessa forma, a administração dessas tabelas deve ser feita em outro lugar, como dentro do Fabric. A motivação para essa abordagem pode incluir:\nPrimeiramente, armazenar dados no OneLake pode melhorar o desempenho dentro do Microsoft Fabric. As tabelas do OneLake são otimizadas para desempenho, especialmente em consultas que envolvem joins e agregações. Em contrapartida, consultas que leem dados do ADLS Gen2 via atalhos podem ter desempenho mais lento.\nEm segundo lugar, gerenciar dados no OneLake facilita a aplicação de medidas de segurança dentro do Microsoft Fabric. Por exemplo, as tabelas do OneLake podem ser protegidas usando controle de acesso baseado em função (RBAC), simplificando o gerenciamento de acesso aos dados. Se fosse utilizado o ADLS Gen2, seria necessário lidar com as permissões da conta de armazenamento do ADLS Gen2, uma tarefa mais complexa.\nTerceiro, as tabelas do OneLake podem ser regulamentadas por políticas, facilitando o uso conforme as normas. Isso é vantajoso ao compartilhar (externamente) tabelas com domínios localizados em outros lugares.\nAlém de apenas ler dados, pode ser interessante considerar a geração de novos dados dentro do Microsoft Fabric. Um recurso futuro pode atrair atenção: em breve, usuários do Fabric poderão acessar itens de dados, como lakehouses, via Unity Catalog no Azure Databricks. Embora os dados permaneçam no OneLake, será possível acessar e visualizar sua linhagem e outros metadados diretamente no Azure Databricks. Essa melhoria facilitará a leitura de dados do Fabric para o Databricks. Por exemplo, se houver planos de usar a IA do Mosaic AI do Azure Databricks, será possível fazê-lo lendo dados do Microsoft Fabric. A tecnologia provável para isso é a Lakehouse Federation.\nEm conclusão, a estratégia de integrar e processar todos os dados dentro do Databricks, enquanto a camada de consumo é gerenciada no Fabric, proporciona às organizações a conveniência de aproveitar os melhores recursos de cada aplicação. Essa abordagem assegura desempenho e segurança ideais na manipulação de dados.\nTe espero no próximo e último artigo da série !!\nAssine a newsletter para acompanhar essa jornada.. Até mais !\n","permalink":"https://julianamarialop.github.io/articles/integrando-azure-databricks-e-microsoft-fabric-um-encontro-ynikf/","summary":"Isenção de responsabilidade: este artigo reflete minhas experiências e pontos de vista pessoais, não uma posição oficial da Microsoft Fabric ou Databricks .","title":"Integrando Azure Databricks e Microsoft Fabric: Um encontro de Gigantes ! - Parte III - Adicionando a Camada de Ouro OneLake"},{"content":"Isenção de responsabilidade: este artigo reflete minhas experiências e pontos de vista pessoais, não uma posição oficial da Microsoft Fabric ou Databricks.\nBem-vindos à segunda parte de nossa série sobre a integração de duas das mais poderosas ferramentas de dados da Microsoft: Microsoft Fabric e Databricks. Na Parte I, exploramos as fundações dessa integração, abordando os conceitos básicos. Agora, nesta Parte II, vamos nos aprofundar ainda mais.\nSe você ainda não leu a primeira parte, recomendo fortemente que o faça antes de prosseguir, pois muitos dos conceitos abordados aqui partem do que foi discutido anteriormente. Prepare-se para elevar suas habilidades e conhecimentos a um novo patamar e aproveitar ao máximo o poder combinado do Azure Databricks e do Microsoft Fabric.\nUma maneira eficaz de melhorar uma arquitetura baseada no Azure Databricks é adicionar uma camada de relatórios e análises. A arquitetura tradicional do Azure Databricks Medallion Lakehouse utiliza serviços como Azure Data Lake Storage (ADLS) Gen2, Azure Data Factory e o próprio Azure Databricks para gerenciamento completo da ingestão, processamento, validação e enriquecimento de dados. Normalmente, o PowerBI é utilizado para relatórios e entrega de insights analíticos.\nExpandir essa arquitetura para incluir o Microsoft Fabric pode aprimorar significativamente as capacidades de autoatendimento e melhorar a experiência do usuário corporativo. Pense no Microsoft Fabric como uma evolução do PowerBI, oferecendo um novo conjunto de funcionalidades que tornam a análise de dados mais envolvente e eficiente.\n_Arquitetura de referência_\nNovos Recursos do Microsoft Fabric A Microsoft introduziu recentemente o recurso \u0026ldquo;shortcut\u0026rdquo; no Microsoft Fabric. Esse recurso age como um mecanismo leve de virtualização de dados, permitindo a leitura de dados de diversas fontes sem necessidade de duplicação. Por exemplo, ao usar o PowerBI, você pode acessar os dados diretamente, sem precisar copiá-los ou importá-los para o PowerBI.\nPara arquiteturas baseadas no Databricks, podemos usar o recurso de atalho do ADLS Gen2, já que o Databricks grava todos os seus dados no ADLS. No entanto, há algumas considerações importantes:\nFabric Lakehouse: Atalhos requerem um Fabric Lakehouse. Certifique-se de criar um, caso ainda não tenha.\nFormato Delta Lake: Atalhos só funcionam com tabelas no formato Delta Lake.\nTabelas Externas: Use atalhos em tabelas externas sempre que possível, em vez de tabelas gerenciadas pelo Databricks.\nLimitação de Pasta: Cada atalho só pode referenciar uma única pasta Delta. Portanto, para acessar dados de várias pastas, crie atalhos individuais para cada uma.\nAcesso Somente Leitura: Utilize uma abordagem de somente leitura para acessar arquivos Delta no ADLS, evitando manipulação direta de arquivos nesses diretórios.\nCriação Manual de Atalhos: Atalhos podem ser criados manualmente através da interface do Fabric ou programaticamente usando a API REST.\nIntegração Avançada com Unity Catalog Para facilitar ainda mais a integração entre Databricks e Microsoft Fabric, a Microsoft anunciou desenvolvimentos emocionantes na Conferência Microsoft Build 2024. Em breve, será possível integrar o Catálogo Unity do Azure Databricks ao Fabric. Com o portal Fabric, você poderá criar e configurar um novo item do Catálogo Unity, e todas as tabelas gerenciadas poderão ser atualizadas para atalhos. Essa integração simplificará drasticamente a unificação dos dados do Azure Databricks no Fabric, facilitando operações contínuas em todas as cargas de trabalho do Fabric.\nSendo Assim, a arquitetura expandida que combina Databricks com o Microsoft Fabric é uma escolha popular entre os clientes satisfeitos com o Databricks. Essas organizações já investiram significativamente no estabelecimento de um Lakehouse com Databricks e planejam continuar a utilizá-lo. O Microsoft Fabric reconhece a força e versatilidade da abordagem Lakehouse com formato Delta, permitindo a adição de uma camada otimizada para consumo de dados. Isso possibilita que as organizações aumentem sua configuração existente centrada em Databricks com uma camada adicional especificamente projetada para facilitar o consumo de dados.\nPor hoje é só ! Em breve teremos a parte III onde abordaremos uma arquitetura habilitada para Databricks, podemos incorporar uma camada de ouro OneLake. Até lá !!\n","permalink":"https://julianamarialop.github.io/articles/integrando-azure-databricks-e-microsoft-fabric-um-encontro-f2rsf/","summary":"Isenção de responsabilidade: este artigo reflete minhas experiências e pontos de vista pessoais, não uma posição oficial da Microsoft Fabric ou Databricks .","title":"Integrando Azure Databricks e Microsoft Fabric: Um encontro de Gigantes ! - Parte II - Adicionando uma Camada de Relatórios e Análises"},{"content":"Isenção de responsabilidade: este artigo reflete minhas experiências e pontos de vista pessoais, não uma posição oficial da Microsoft Fabric ou Databricks .\nNeste artigo inicial, abordaremos um tópico crucial que frequentemente surge nas conversas com nossos clientes: a integração do Microsoft Azure Databricks com o Microsoft Fabric . Ambas as plataformas são líderes em suas respectivas áreas. O Microsoft Azure Databricks é excepcional para escalonar cargas de trabalho em engenharia de dados, ciência de dados e aprendizado de máquina. Por sua vez, o Microsoft Fabric destaca-se pela simplicidade e recursos de autoatendimento, sendo ideal para uma vasta gama de aplicações de dados. A questão que frequentemente nos perguntam é: como integrar essas duas ferramentas poderosas de maneira eficiente?\nAbordagens de Integração Atualmente, existem várias opções a serem consideradas para essa integração (lembrando que o Microsoft Fabric está em constante atualização, o que significa que em breve teremos ainda mais possibilidades).\nAdição de Camadas de Relatórios e Análises Uma maneira de melhorar uma arquitetura habilitada para Databricks é adicionando uma camada de relatórios e análises. Isso permitirá uma visualização mais eficaz dos dados processados.\nIntegração com OneLake Outra abordagem é complementar a arquitetura incorporando uma camada de ouro do OneLake. Além disso, podemos considerar a opção de fazer com que o Microsoft Azure Databricks grave todos os dados diretamente no OneLake. Embora essa prática não seja geralmente recomendada, é importante discutir seus aspectos para entender quando ela pode ser útil.\nExtensão com V-ORDERED Podemos ainda estender o Microsoft Azure Databricks adicionando uma camada de consumo habilitada para V-ORDERED. Isso pode melhorar a eficiência do processamento de dados tanto no Microsoft Azure Databricksquanto no Microsoft Fabric, adicionando componentes extras que podem fazer a diferença no desempenho.\nExplorando as Opções Nos próximos artigos dessa série, vamos explorar detalhadamente as opções disponíveis hoje. Vamos analisar as nuances, pesar os prós e contras e consultar a documentação relevante. Antes disso, é essencial entender por que tantas organizações escolhem utilizar essas duas ferramentas poderosas em conjunto.\nVamos mergulhar nessas estratégias e descobrir como tirar o máximo proveito da combinação do Microsoft Azure Databricks e do Microsoft Fabric.\nMas antes de finalizar, gostaria de responder a seguinte pergunta: Por que combinar as duas plataformas? As organizações optam por integrar o Microsoft Azure Databricks e o Microsoft Fabric devido aos benefícios únicos que essa combinação proporciona.\nO Microsoft Azure Databricks é uma plataforma poderosa e versátil, projetada para processamento de dados, análise e ciência de dados. Amplamente adotado por empresas de diferentes portes, o Microsoft Azure Databricks, criado pelos desenvolvedores do Spark, é altamente valorizado por sua capacidade de gerenciar cargas de trabalho complexas em grande escala. Com uma longa trajetória de sucesso, ele se firmou como uma ferramenta confiável e eficiente para engenheiros de dados.\nEm contrapartida, o Microsoft Fabric destaca-se pela sua simplicidade e facilidade de uso. Lançado em 2023 e evoluído a partir do Microsoft Power BI , ele oferece uma transição tranquila para usuários habituados ao Microsoft Power BI . Sua interface intuitiva, recursos integrados de autoatendimento e perfeita integração com o Microsoft Office 365 tornam o Microsoft Fabric especialmente atraente para o ambiente corporativo. Projetado para democratizar o acesso aos dados e eliminar barreiras de uso, ele se apresenta como uma solução acessível e eficiente.\nPortanto, a combinação do Microsoft Azure Databricks com o Microsoft Fabric oferece uma solução robusta e completa, atendendo tanto às necessidades técnicas quanto comerciais das organizações, o que explica sua popularidade crescente.\nAgora que entendemos os motivos pelos quais essa combinação é frequentemente escolhida, vamos abordar a questão principal: como integrar esses dois serviços de maneira eficaz?\nTe espero no próximo artigo da série !!\nAssine a newsletter para acompanhar essa jornada.. Até mais !\n","permalink":"https://julianamarialop.github.io/articles/integrando-azure-databricks-e-microsoft-fabric-um-encontro-fb1af/","summary":"Isenção de responsabilidade: este artigo reflete minhas experiências e pontos de vista pessoais, não uma posição oficial da Microsoft Fabric ou Databricks .","title":"Integrando Azure Databricks e Microsoft Fabric: Um encontro de Gigantes ! - Parte I"},{"content":"O artigo de hoje é sobre um assunto que adoro e nunca sai de moda. SQL !!\nSe você já está envolvido em Análise de Dados há algum tempo, já deve estar familiarizado com os comandos básicos como SELECT, INSERT, UPDATE e DELETE, etc. Embora sejam os mais utilizados, também é bom conhecer as consultas abaixo para uma análise mais profunda dos dados.\n1. Window Functions Funções de janela são usadas para cálculos em um conjunto de linhas relacionadas à linha atual. Vamos considerar um exemplo onde calculamos o total acumulado de vendas usando a função SUM( ) com a cláusula OVER( ). Imagine que temos uma tabela de dados de vendas chamada ‘Sales_Data’ que registra os valores de vendas em várias datas. Queremos calcular o total acumulado de vendas para cada data, o que significa o total de vendas até e incluindo cada data.\nSELECT Date, Sales_Amount, SUM(Sales_Amount) OVER (ORDER BY Date) AS Running_Total FROM Sales_Data; Neste exemplo, a função SUM(Sales_Amount) OVER (ORDER BY Date) calcula o total acumulado de vendas até a data atual para cada linha na tabela \u0026lsquo;Sales_Data\u0026rsquo;.\nFunções de janela podem ser usadas para várias tarefas, como calcular totais acumulados, médias móveis, classificações e muito mais, sem colapsar o conjunto de resultados em uma única linha por grupo.\n2. Common Table Expressions (CTEs) CTEs (Common Table Expressions) fornecem uma maneira de criar conjuntos de resultados temporários que podem ser referenciados dentro de uma consulta. Eles melhoram a legibilidade e simplificam consultas complexas. Aqui está como podemos usar um CTE para calcular a receita total para cada categoria de produto.\nWITH category_revenue AS ( SELECT category, SUM(revenue) AS total_revenue FROM sales GROUP BY category ) SELECT * FROM category_revenue; A consulta define um CTE chamado ‘category_revenue’. Ele calcula a receita total para cada categoria somando a receita da tabela de vendas e agrupando os resultados pela coluna de categoria. A consulta principal seleciona todas as colunas do CTE ‘category_revenue’, exibindo efetivamente a receita total calculada para cada categoria.\n3. Consultas Recursivas Consultas recursivas permitem percorrer estruturas de dados hierárquicas, como organogramas ou listas de materiais. Suponha que temos uma tabela que representa os relacionamentos de funcionários e queremos encontrar todos os subordinados de um determinado gerente.\nWITH RECURSIVE subordinates AS ( SELECT employee_id, name, manager_id FROM employees WHERE manager_id = \u0026#39;manager_id_of_interest\u0026#39; UNION ALL SELECT e.employee_id, e.name, e.manager_id FROM employees e JOIN subordinates s ON e.manager_id = s.employee_id ) SELECT * FROM subordinates; Este CTE recursivo encontra todos os funcionários que se reportam direta ou indiretamente a um gerente específico \u0026lsquo;manager_id_of_interest\u0026rsquo;. Ele começa com os funcionários que se reportam diretamente ao gerente e, em seguida, encontra recursivamente seus subordinados, construindo a hierarquia.\n4. Tabelas Dinâmicas Tabelas dinâmicas transformam linhas em colunas, resumindo dados em um formato tabular. Digamos que temos uma tabela contendo dados de vendas e queremos dinamizar os dados para exibir as vendas totais de cada produto em diferentes meses.\nSELECT product, SUM(CASE WHEN month = \u0026#39;Jan\u0026#39; THEN sales ELSE 0 END) AS Jan, SUM(CASE WHEN month = \u0026#39;Feb\u0026#39; THEN sales ELSE 0 END) AS Feb, SUM(CASE WHEN month = \u0026#39;Mar\u0026#39; THEN sales ELSE 0 END) AS Mar FROM sales_data GROUP BY product; Esta consulta agrega os dados de vendas para cada produto por mês usando agregação condicional. Ela soma as vendas de janeiro, fevereiro e março separadamente para cada produto, resultando em uma tabela que mostra as vendas totais por produto para esses meses.\n5.Funções Analíticas Funções analíticas calculam valores agregados com base em um grupo de linhas. Por exemplo, podemos usar a função ROW_NUMBER() para atribuir um número de linha único a cada registro em um conjunto de dados.\nSELECT customer_id, order_id, ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date) AS order_rank FROM orders; Esta consulta atribui uma classificação única a cada pedido por cliente com base na data do pedido, usando a função de janela ROW_NUMBER(). O resultado mostra a sequência de pedidos feitos por cada cliente.\n6. Unpivot Unpivoting é o oposto de pivotar, onde colunas são transformadas em linhas. Digamos que temos uma tabela com dados de vendas agregados por mês e queremos \u0026ldquo;despivotar\u0026rdquo; para analisar as tendências ao longo do tempo.\nSELECT product, month, sales FROM sales_data UNPIVOT ( sales FOR month IN (sales_jan AS \u0026#39;Jan\u0026#39;, sales_feb AS \u0026#39;Feb\u0026#39;, sales_mar AS \u0026#39;Mar\u0026#39;) ) AS unpivoted_sales; Esta consulta transforma as colunas de vendas mensais em linhas, facilitando a análise de tendências ao longo do tempo por produto. Cada linha representa as vendas de um produto em um mês específico.\n7. Agregação Condicional A agregação condicional envolve a aplicação de funções de agregação condicionalmente com base em critérios especificados. Por exemplo, podemos querer calcular o valor médio de vendas apenas para pedidos feitos por clientes recorrentes.\nSELECT customer_id, AVG(CASE WHEN order_count \u0026gt; 1 THEN order_total ELSE NULL END) AS avg_sales_repeat_customers FROM ( SELECT customer_id, COUNT(*) AS order_count, SUM(order_total) AS order_total FROM orders GROUP BY customer_id ) AS customer_orders; Esta consulta calcula o total médio de pedidos para clientes que fizeram mais de um pedido. Ela agrega a contagem de pedidos e o valor total dos pedidos para cada cliente, em seguida, calcula a média para os clientes recorrentes.\n8. Funções de Data Funções de data em SQL permitem a manipulação e extração de informações relacionadas a datas. Por exemplo, podemos usar a função DATE_TRUNC() para agrupar dados de vendas por mês.\nSELECT DATE_TRUNC(\u0026#39;month\u0026#39;, order_date) AS month, SUM(sales_amount) AS total_sales FROM sales GROUP BY DATE_TRUNC(\u0026#39;month\u0026#39;, order_date); Esta saída mostra o valor total de vendas (total_sales) agregado para cada mês como month, onde cada mês é representado pelo primeiro dia daquele mês (por exemplo, 2023-01-01 para janeiro). As vendas totais são somadas para cada respectivo mês.\n9. Instrução MERGE ou UPSERT As instruções MERGE (também conhecidas como UPSERT ou ON DUPLICATE KEY UPDATE) permitem inserir, atualizar ou excluir registros em uma tabela de destino com base nos resultados de uma junção com uma tabela de origem. Vamos supor que queremos sincronizar duas tabelas contendo dados de clientes.\nMERGE INTO customers_target t USING customers_source s ON t.customer_id = s.customer_id WHEN MATCHED THEN UPDATE SET t.name = s.name, t.email = s.email WHEN NOT MATCHED THEN INSERT (customer_id, name, email) VALUES (s.customer_id, s.name, s.email); A instrução MERGE atualiza a tabela customers_target com base na tabela customers_source. Se um customer_id em customers_source corresponder a um em customers_target, o nome e o email são atualizados. Se não houver correspondência, uma nova linha é inserida.\n10. Instruções CASE Instruções CASE permitem lógica condicional dentro de consultas SQL. Por exemplo, podemos usar uma instrução CASE para categorizar clientes com base no seu valor total de compra.\nSELECT customer_id, CASE WHEN total_purchase_amount \u0026gt;= 1000 THEN \u0026#39;Platinum\u0026#39; WHEN total_purchase_amount \u0026gt;= 500 THEN \u0026#39;Gold\u0026#39; ELSE \u0026#39;Silver\u0026#39; END AS customer_category FROM ( SELECT customer_id, SUM(order_total) AS total_purchase_amount FROM orders GROUP BY customer_id ) AS customer_purchases; A consulta classifica os clientes em categorias com base no seu valor total de compra. Clientes com um valor total de compra de $1000 ou mais são rotulados como \u0026lsquo;Platinum\u0026rsquo;, aqueles com $500 a $999 são rotulados como \u0026lsquo;Gold\u0026rsquo; e aqueles com menos de $500 são rotulados como \u0026lsquo;Silver\u0026rsquo;.\n**Explicação:**\n**Customer 1:** Total de compras = 200 + 300 = 500. Classificado como \u0026lsquo;Gold\u0026rsquo;.\n**Customer 2:** Total de compras = 800. Classificado como \u0026lsquo;Gold\u0026rsquo;.\n**Customer 3:** Total de compras = 150 + 400 = 550. Classificado como \u0026lsquo;Silver\u0026rsquo;.\n**Customer 4:** Total de compras = 1200. Classificado como \u0026lsquo;Platinum\u0026rsquo;.\n11. Funções de String Funções de string em SQL permitem a manipulação de dados textuais. Por exemplo, podemos usar a função CONCAT() para concatenar nomes e sobrenomes.\nSELECT CONCAT(first_name, \u0026#39; \u0026#39;, last_name) AS full_name FROM employees; Vamos considerar um conjunto de dados de exemplo e explicar a saída.\n**Dados de exemplo na tabela employees:**\n| first_name | last_name |\n|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;|\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash;|\n| John | Doe |\n| Jane | Smith |\n| Alice | Johnson |\n| Bob | Brown |\n**Saída:**\n| full_name |\n|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-|\n| John Doe |\n| Jane Smith |\n| Alice Johnson |\n| Bob Brown |\nA consulta concatena as colunas first_name e last_name da tabela employees com um espaço entre elas, criando um full_name para cada funcionário.\n**Explicação:**\n**John Doe:** As colunas first_name (\u0026ldquo;John\u0026rdquo;) e last_name (\u0026ldquo;Doe\u0026rdquo;) são concatenadas com um espaço entre elas, resultando em \u0026ldquo;John Doe\u0026rdquo;.\n**Jane Smith:** As colunas first_name (\u0026ldquo;Jane\u0026rdquo;) e last_name (\u0026ldquo;Smith\u0026rdquo;) são concatenadas, resultando em \u0026ldquo;Jane Smith\u0026rdquo;.\n**Alice Johnson:** As colunas first_name (\u0026ldquo;Alice\u0026rdquo;) e last_name (\u0026ldquo;Johnson\u0026rdquo;) são concatenadas, resultando em \u0026ldquo;Alice Johnson\u0026rdquo;.\n**Bob Brown:** As colunas first_name (\u0026ldquo;Bob\u0026rdquo;) e last_name (\u0026ldquo;Brown\u0026rdquo;) são concatenadas, resultando em \u0026ldquo;Bob Brown\u0026rdquo;.\n12. Conjuntos de Agrupamento Os conjuntos de agrupamento (Grouping Sets) permitem a agregação de dados em múltiplos níveis de granularidade em uma única consulta. Vamos supor que queremos calcular a receita total de vendas por mês e ano.\nSELECT YEAR(order_date) AS year, MONTH(order_date) AS month, SUM(sales_amount) AS total_revenue FROM sales GROUP BY GROUPING SETS ( (YEAR(order_date), MONTH(order_date)), YEAR(order_date), MONTH(order_date) ); **Dados de exemplo na tabela sales:**\n| order_date | sales_amount |\n|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash;|\n| 2023-01-15 | 1000 |\n| 2023-01-20 | 1500 |\n| 2023-02-10 | 2000 |\n| 2023-03-05 | 2500 |\n| 2024-01-10 | 3000 |\n| 2024-01-20 | 3500 |\n| 2024-02-25 | 4000 |\n**Saída:**\n| year | month | total_revenue |\n|\u0026mdash;\u0026mdash;|\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;|\n| 2023 | 1 | 2500 |\n| 2023 | 2 | 2000 |\n| 2023 | 3 | 2500 |\n| 2024 | 1 | 6500 |\n| 2024 | 2 | 4000 |\n| 2023 | NULL | 7000 |\n| 2024 | NULL | 10500 |\n| NULL | 1 | 9000 |\n| NULL | 2 | 6000 |\n| NULL | 3 | 2500 |\n**Explicação:**\n**Agrupamento por ano e mês:** 2023-01: 1000 + 1500 = 2500\n2023-02: 2000\n2023-03: 2500\n2024-01: 3000 + 3500 = 6500\n2024-02: 4000\n**Agrupamento por ano:** 2023: 2500 (Jan) + 2000 (Fev) + 2500 (Mar) = 7000\n2024: 6500 (Jan) + 4000 (Fev) = 10500\n**Agrupamento por mês:** Janeiro (todos os anos): 2500 (2023) + 6500 (2024) = 9000\nFevereiro (todos os anos): 2000 (2023) + 4000 (2024) = 6000\nMarço (todos os anos): 2500\nEste resultado fornece subtotais para cada mês de cada ano, totais gerais para cada ano e totais gerais para cada mês em todos os anos.\n13. Cross Joins Os joins cruzados (CROSS JOIN) produzem o produto cartesiano de duas tabelas, resultando em uma combinação de cada linha de cada tabela. Por exemplo, podemos usar um CROSS JOIN para gerar todas as possíveis combinações de produtos e clientes.\nSELECT p.product_id, p.product_name, c.customer_id, c.customer_name FROM products p CROSS JOIN customers c; Vamos considerar um conjunto de dados de exemplo para as tabelas products e customers.\n**Tabela products:**\n| product_id | product_name |\n|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash;|\n| 1 | Product A |\n| 2 | Product B |\n**Tabela customers:**\n| customer_id | customer_name |\n|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;|\n| 101 | Customer X |\n| 102 | Customer Y |\n**Saída:**\n| product_id | product_name | customer_id | customer_name |\n|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash;|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;|\n| 1 | Product A | 101 | Customer X |\n| 1 | Product A | 102 | Customer Y |\n| 2 | Product B | 101 | Customer X |\n| 2 | Product B | 102 | Customer Y |\nA consulta realiza um CROSS JOIN entre as tabelas products e customers, resultando em um produto cartesiano. Isso significa que cada produto é emparelhado com cada cliente, gerando todas as possíveis combinações de produtos e clientes.\n**Explicação:**\n**Product A com Customer X:** Combinação de product_id 1 e customer_id 101.\n**Product A com Customer Y:** Combinação de product_id 1 e customer_id 102.\n**Product B com Customer X:** Combinação de product_id 2 e customer_id 101.\n**Product B com Customer Y:** Combinação de product_id 2 e customer_id 102.\nO resultado é um conjunto completo de combinações entre produtos e clientes, demonstrando o produto cartesiano das duas tabelas.\n14. Tabelas Derivadas As visualizações inline (também conhecidas como tabelas derivadas) permitem a criação de conjuntos de resultados temporários dentro de uma consulta SQL. Vamos supor que queremos encontrar clientes que fizeram compras acima do valor médio dos pedidos.\nSELECT customer_id, order_total FROM ( SELECT customer_id, SUM(order_total) AS order_total FROM orders GROUP BY customer_id ) AS customer_orders WHERE order_total \u0026gt; ( SELECT AVG(order_total) FROM orders ); **Tabela orders:**\n| customer_id | order_total |\n|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-|\n| 1 | 100 |\n| 1 | 200 |\n| 2 | 500 |\n| 3 | 300 |\n| 3 | 200 |\n| 4 | 700 |\n**Cálculo do total de pedidos para cada cliente:**\n| customer_id | order_total |\n|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-|\n| 1 | 300 |\n| 2 | 500 |\n| 3 | 500 |\n| 4 | 700 |\n**Cálculo do valor médio dos pedidos:**\nPara calcular o valor médio dos pedidos, somamos todos os valores de pedidos e dividimos pelo número total de pedidos:\n(100 + 200 + 500 + 300 + 200 + 700) / 6 = 2000 / 6 ≈ 333.33\n**Filtragem de clientes com pedidos totais acima da média:**\n| customer_id | order_total |\n|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-|\n| 2 | 500 |\n| 3 | 500 |\n| 4 | 700 |\n**Explicação:**\n**Cálculo do total de pedidos para cada cliente:** A subconsulta agrupa os pedidos por customer_id e soma os valores de order_total para cada cliente.\n**Cálculo do valor médio dos pedidos:** Outra subconsulta calcula a média dos valores dos pedidos em toda a tabela orders.\n**Filtragem de clientes:** A consulta externa filtra os clientes cujos totais de pedidos são maiores que o valor médio dos pedidos.\nDessa forma, a consulta finaliza exibindo os clientes cujos totais de pedidos excedem a média, resultando na saída correta.\n15. Operadores de Conjunto Operadores de conjunto como UNION, INTERSECT e EXCEPT permitem combinar os resultados de duas ou mais consultas. Por exemplo, podemos usar o operador UNION para mesclar os resultados de duas consultas em um único conjunto de resultados.\nSELECT product_id, product_name FROM products UNION SELECT product_id, product_name FROM archived_products; Esta consulta combina os resultados das tabelas products e archived_products, eliminando quaisquer entradas duplicadas, para criar uma lista unificada de IDs e nomes de produtos. O operador UNION garante que cada produto apareça apenas uma vez no resultado final.\n**Dados de exemplo:**\n**Tabela products:**\n| product_id | product_name |\n|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash;|\n| 1 | Chocolate Bar |\n| 2 | Dark Chocolate |\n| 3 | Milk Chocolate |\n**Tabela archived_products:**\n| product_id | product_name |\n|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash;|\n| 3 | Milk Chocolate |\n| 4 | White Chocolate |\n| 5 | Almond Chocolate|\n**Saída:**\n| product_id | product_name |\n|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash;|\n| 1 | Chocolate Bar |\n| 2 | Dark Chocolate |\n| 3 | Milk Chocolate |\n| 4 | White Chocolate |\n| 5 | Almond Chocolate|\nA consulta mescla os resultados das tabelas products e archived_products, eliminando os duplicados (no caso, Milk Chocolate com product_id 3), criando uma lista unificada de produtos.\nPor hoje é só! Se você gostou deste artigo, ajude na divulgação e assine a nossa newsletter para receber mais conteúdos interessantes. Até a próxima! ","permalink":"https://julianamarialop.github.io/articles/consultas-sql-avancadas-que-voce-deve-conhecer-juliana-maria/","summary":"O artigo de hoje é sobre um assunto que adoro e nunca sai de moda. SQL !!","title":"Consultas SQL avançadas que você deve conhecer"},{"content":"Vamos aprender como calcular o custo das instâncias do SQL Warehouse no Microsoft Azure Databricks de uma maneira fácil? Então acompanhe esse artigo.\nO SQL Warehouse no Databricks é uma ferramenta que nos permite consultar e explorar dados de forma eficiente.\nAtualmente, o Microsoft Azure Databricks oferece três tipos de SQL Warehouse:\nSQL Warehouse Classic: Este tipo de SQL Warehouse utiliza nossa conta de assinatura do Azure. Ele oferece suporte ao Photon, mas não ao Predictive IO ou ao Intelligent Workload Management. SQL Warehouse Pro: Assim como o Classic, ele utiliza nossa conta de assinatura do Azure, mas oferece suporte tanto ao Photon quanto ao Predictive IO. No entanto, não suporta o Intelligent Workload Management. SQL Warehouse Serverless: Este tipo usa a arquitetura sem servidor do Azure Databricks e suporta todos os recursos de desempenho do Databricks SQL, incluindo Photon, Predictive IO e Intelligent Workload Management. Ele opera diretamente na nossa conta do Azure Databricks. A principal diferença entre o SQL Warehouse Classic, o Pro e o Serverless é a localização da camada de computação e os recursos de suporte. Enquanto o Classic e o Pro utilizam nossa conta de assinatura do Azure, o Serverless opera na conta do Microsoft Azure Databricks e suporta mais funcionalidades.\nMétodo DIY Esta seção é voltada para desenvolvedores ou pessoas técnicas que querem entender a lógica por trás da análise de custos e talvez criar suas próprias ferramentas ou scripts para calcular o custo das instâncias do SQL Warehouse do Microsoft Azure Databricks .\nMétodo DIY — SQL Warehouse Classic Para calcular o custo de um Microsoft Azure Databricks SQL Warehouse Classic ou Pro, precisamos considerar os seguintes componentes:\nHoras de computação do SQL: Tempo em que o SQL Warehouse estava em execução. Horas da unidade Databricks (DBU): Unidades de computação usadas pelo SQL Warehouse, cobradas por hora. Custos de armazenamento: Custos associados ao armazenamento de dados, se aplicável. Custos de largura de banda: Custos associados à transferência de dados, se aplicável. Obtendo a lista de instâncias clássicas do SQL Warehouse da API Databricks O primeiro passo é recuperar a lista de instâncias do SQL Warehouse usando a API do Microsoft Azure Databricks: /api/2.0/sql/warehouses.\nApós executar a chamada da API, receberemos uma resposta JSON com todos os SQL Warehouses do Microsoft Azure Databricks.\nAqui está um exemplo do JSON do SQL Warehouse Classic:\n\u0026#34;warehouses\u0026#34;:[ { \u0026#34;id\u0026#34;:\u0026#34;2b1623d985c31e5d\u0026#34;, \u0026#34;name\u0026#34;:\u0026#34;Classic Warehouse\u0026#34;, \u0026#34;size\u0026#34;:\u0026#34;XXSMALL\u0026#34;, \u0026#34;cluster_size\u0026#34;:\u0026#34;2X-Small\u0026#34;, \u0026#34;min_num_clusters\u0026#34;:1, \u0026#34;max_num_clusters\u0026#34;:1, \u0026#34;auto_stop_mins\u0026#34;:45, \u0026#34;auto_resume\u0026#34;:true, \u0026#34;creator_name\u0026#34;:\u0026#34;julianamarialopes@hotmail.com\u0026#34;, \u0026#34;creator_id\u0026#34;:1036471208901988, \u0026#34;tags\u0026#34;:{ }, \u0026#34;spot_instance_policy\u0026#34;:\u0026#34;COST_OPTIMIZED\u0026#34;, \u0026#34;enable_photon\u0026#34;:true, \u0026#34;channel\u0026#34;:{ \u0026#34;name\u0026#34;:\u0026#34;CHANNEL_NAME_CURRENT\u0026#34; }, \u0026#34;enable_serverless_compute\u0026#34;:false, \u0026#34;warehouse_type\u0026#34;:\u0026#34;CLASSIC\u0026#34;, \u0026#34;num_clusters\u0026#34;:0, \u0026#34;num_active_sessions\u0026#34;:0, \u0026#34;state\u0026#34;:\u0026#34;STOPPED\u0026#34;, \u0026#34;jdbc_url\u0026#34;:\u0026#34;jdbc:spark://adb-xxxxxxxx.x.azuredatabricks.net:443/default;transportMode=http;ssl=1;AuthMech=3;httpPath=/sql/1.0/warehouses/2b1623d985c31e5d;\u0026#34;, \u0026#34;odbc_params\u0026#34;:{ \u0026#34;hostname\u0026#34;:\u0026#34;adb-xxxxxxxx.x.azuredatabricks.net\u0026#34;, \u0026#34;path\u0026#34;:\u0026#34;/sql/1.0/warehouses/2b1623d985c31e5d\u0026#34;, \u0026#34;protocol\u0026#34;:\u0026#34;https\u0026#34;, \u0026#34;port\u0026#34;:443 } } } ] Obtendo o custo dos recursos do SQL Warehouse Classic da API da Microsoft Para calcular os custos do SQL Warehouse Classic, precisamos combinar os dados de uso com as informações de custo.\nUsaremos a API Microsoft Generate Cost Details Report para obter todos os dados da assinatura do Microsoft Azure onde nossos clusters Microsoft Azure Databricks estão em execução.\nAqui estão algumas notas importantes ao usar essa API:\nFiltragem dos dados: Devemos filtrar os dados relacionados ao Databricks e remover quaisquer dados relacionados a outros serviços ou dados sem custo associado. Tipo de assinatura: Precisamos ajustar os resultados com base no tipo de assinatura do Azure (pré-pago ou empresarial), pois o formato dos dados pode ser diferente. Limitação de dados: A API permite extrair dados de um período máximo de um mês e não mais antigos que 13 meses. Ao extrair os dados da API da Microsoft Azure , selecionamos as seguintes colunas do relatório:\nSqlEndpointId: ID da instância do SQL Warehouse. ProductName: Descrição do recurso Azure consumido. MeterName: Rótulo que identifica o tipo de serviço ou recurso que está sendo cobrado. CostInBillingCurrency: Custo do recurso do Azure consumido. Obteremos dados semelhantes a este (formatados para fácil compreensão):\nEm instâncias do SQL Warehouse Classic , o Produto é igual a Azure Databricks — Premium — SQL Analytics e o MeterName é igual a Premium SQL Analytics DBU.\nEm seguida, somamos todos os registros para calcular o custo final da instância do SQL Warehouse.\nMétodo DIY - SQL Warehouse Pro Para calcular o custo de um Microsoft Azure Databricks SQL Warehouse Pro , precisamos levar em conta os seguintes componentes:\nHoras de computação SQL: o tempo durante o qual o SQL Warehouse estava em execução. Horas da unidade de databricks (DBU): as unidades de computação usadas pelo SQL Warehouse, que são cobradas por hora. Custos de Armazenamento: Custos associados ao armazenamento de dados, se aplicável. Custos de largura de banda: Custos associados à transferência de largura de banda, se aplicável. Após executarmos a chamada da API, receberemos uma resposta JSON com todos os SQL Warehouses do Microsoft Azure Databricks.\nEste é o JSON do SQL Warehouse Pro :\n\u0026#34;warehouses\u0026#34;:[ { \u0026#34;id\u0026#34;:\u0026#34;aedd502a567f273a\u0026#34;, \u0026#34;name\u0026#34;:\u0026#34;Starter Warehouse\u0026#34;, \u0026#34;size\u0026#34;:\u0026#34;XXSMALL\u0026#34;, \u0026#34;cluster_size\u0026#34;:\u0026#34;2X-Small\u0026#34;, \u0026#34;min_num_clusters\u0026#34;:1, \u0026#34;max_num_clusters\u0026#34;:1, \u0026#34;auto_stop_mins\u0026#34;:10, \u0026#34;auto_resume\u0026#34;:true, \u0026#34;creator_name\u0026#34;:\u0026#34;julianamarialopes@hotmail.com\u0026#34;, \u0026#34;creator_id\u0026#34;:1036471128901988, \u0026#34;tags\u0026#34;:{ }, \u0026#34;spot_instance_policy\u0026#34;:\u0026#34;COST_OPTIMIZED\u0026#34;, \u0026#34;enable_photon\u0026#34;:true, \u0026#34;channel\u0026#34;:{ }, \u0026#34;enable_serverless_compute\u0026#34;:false, \u0026#34;warehouse_type\u0026#34;:\u0026#34;PRO\u0026#34;, \u0026#34;num_clusters\u0026#34;:0, \u0026#34;num_active_sessions\u0026#34;:0, \u0026#34;state\u0026#34;:\u0026#34;STOPPED\u0026#34;, \u0026#34;jdbc_url\u0026#34;:\u0026#34;jdbc:spark://adb-xxxxxxxx.x.azuredatabricks.net:443/default;transportMode=http;ssl=1;AuthMech=3;httpPath=/sql/1.0/warehouses/aedd502a567f273a;\u0026#34;, \u0026#34;odbc_params\u0026#34;:{ \u0026#34;hostname\u0026#34;:\u0026#34;adb-xxxxxxxx.x.azuredatabricks.net\u0026#34;, \u0026#34;path\u0026#34;:\u0026#34;/sql/1.0/warehouses/aedd502a567f273a\u0026#34;, \u0026#34;protocol\u0026#34;:\u0026#34;https\u0026#34;, \u0026#34;port\u0026#34;:443 } } } ] Muito similar ao exemplo anterior.\nObtendo o custo dos recursos do SQL Warehouse PRO da API da Microsoft Para calcular os custos do SQL Warehouse Pro, precisamos combinar os dados de uso recuperados com as informações de custo para calcular o custo total.\nUsaremos a API Microsoft Generate Cost Details Report para obter todos os dados da assinatura do Azure onde nossos clusters Databricks estão em execução.\nNotas importantes quando usamos a API:\nQuando obtemos os dados de detalhes de custo de uma assinatura do Microsoft Azure, devemos filtrar os dados relacionados ao Databricks e remover quaisquer dados relacionados a outros serviços e dados sem qualquer custo associado. Precisamos ajustar os resultados com base no tipo de assinatura do Microsoft Azure (pré-pago ou empresarial) porque o resultado é diferente. A API só permite que dados sejam extraídos de um mês ou menos e não mais antigos que 13 meses . Ao extrair os dados da API da Microsoft, precisaremos selecionar as seguintes colunas do relatório:\nSqlEndpointId: o ID da instância do SQL Warehouse ProductName: a descrição do recurso Azure consumido MeterName: o rótulo que identifica o tipo de serviço ou recurso que está sendo cobrado CostInBillingCurrency: o custo do recurso do Azure consumido BillingCurrency: o código da moeda de cobrança (USD, EUR, etc.) 1.2.3. Calculando o custo das instâncias do SQL Warehouse PRO Depois de recuperar os dados do Microsoft Azure Databricks e das APIs do Microsoft Azure, a etapa final é filtrar os dados de custo do Azure usando o ID do ponto de extremidade do SQL e corresponder ao ID do ponto de extremidade do SQL da API do Microsoft Azure Databricks.\nNas instâncias do SQL Warehouse Pro , o Produto é igual ao Azure Databricks Regional — Premium — SQL Compute Pro e o MeterName é igual ao Premium SQL Compute Pro DBU.\nEm seguida, somamos todos os registros para calcular o custo final da instância do SQL Warehouse.\n1.3. Método DIY – SQL Warehouse sem servidor As instâncias sem servidor do SQL Warehouse do Microsoft Azure Databricks estão sendo executadas dentro da nossa conta do Microsoft Azure Databricks, então estamos sendo cobrados apenas em horas de unidade do Databricks (DBU).\nApós executarmos a chamada da API, receberemos um JSON com todos os SQL Warehouses do Microsoft Azure Databricks.\nEste é o JSON do SQL Warehouse Serverless :\n\u0026#34;warehouses\u0026#34;:[ { \u0026#34;id\u0026#34;:\u0026#34;e5e7201bde7c3a43\u0026#34;, \u0026#34;name\u0026#34;:\u0026#34;Serveless Warehouse\u0026#34;, \u0026#34;size\u0026#34;:\u0026#34;XXSMALL\u0026#34;, \u0026#34;cluster_size\u0026#34;:\u0026#34;2X-Small\u0026#34;, \u0026#34;min_num_clusters\u0026#34;:1, \u0026#34;max_num_clusters\u0026#34;:1, \u0026#34;auto_stop_mins\u0026#34;:10, \u0026#34;auto_resume\u0026#34;:true, \u0026#34;creator_name\u0026#34;:\u0026#34;julianamarialopes@hotmail.com\u0026#34;, \u0026#34;creator_id\u0026#34;:1036471128901988, \u0026#34;tags\u0026#34;:{ }, \u0026#34;spot_instance_policy\u0026#34;:\u0026#34;COST_OPTIMIZED\u0026#34;, \u0026#34;enable_photon\u0026#34;:true, \u0026#34;enable_serverless_compute\u0026#34;:true, \u0026#34;warehouse_type\u0026#34;:\u0026#34;PRO\u0026#34;, \u0026#34;num_clusters\u0026#34;:0, \u0026#34;num_active_sessions\u0026#34;:0, \u0026#34;state\u0026#34;:\u0026#34;STOPPED\u0026#34;, \u0026#34;jdbc_url\u0026#34;:\u0026#34;jdbc:spark://adb-xxxxxxxx.x.azuredatabricks.net:443/default;transportMode=http;ssl=1;AuthMech=3;httpPath=/sql/1.0/warehouses/e5e7201bde7c3a43;\u0026#34;, \u0026#34;odbc_params\u0026#34;:{ \u0026#34;hostname\u0026#34;:\u0026#34;adb-xxxxxxxx.x.azuredatabricks.net\u0026#34;, \u0026#34;path\u0026#34;:\u0026#34;/sql/1.0/warehouses/e5e7201bde7c3a43\u0026#34;, \u0026#34;protocol\u0026#34;:\u0026#34;https\u0026#34;, \u0026#34;port\u0026#34;:443 } } } ] 1.3.2. Obtendo o custo dos recursos sem servidor do SQL Warehouse da API da Microsoft Precisamos combinar os dados de uso recuperados com as informações de custo para calcular os custos do SQL Warehouse Serverless.\nUsaremos a API Microsoft Generate Cost Details Report para obter todos os dados da assinatura do Azure onde nossos clusters Microsoft Azure Databricks estão em execução.\nNotas importantes quando usamos a API:\nQuando obtemos os dados de detalhes de custo de uma assinatura do Microsoft Azure, devemos filtrar os dados relacionados ao Microsoft Azure Databricks e remover quaisquer dados relacionados a outros serviços e dados sem qualquer custo associado. Precisamos ajustar os resultados com base no tipo de assinatura do Microsoft Azure(pré-pago ou empresarial) porque o resultado é diferente. A API só permite que dados sejam extraídos de um mês ou menos e não mais antigos que 13 meses . Ao extrair os dados da API da Microsoft , precisaremos selecionar as seguintes colunas do relatório:\nSqlEndpointId: o ID da instância do SQL Warehouse ProductName: a descrição do recurso Azure consumido MeterName: o rótulo que identifica o tipo de serviço ou recurso que está sendo cobrado CostInBillingCurrency: o custo do recurso do Azure consumido BillingCurrency: o código da moeda de cobrança (USD, EUR, etc.) 1.3.3. Calculando o custo de instâncias sem servidor do SQL Warehouse Depois de recuperar os dados do Microsoft Azure Databricks e das APIs do Microsoft Azure , a etapa final é filtrar os dados de custo usando o ID do ponto de extremidade do SQL e corresponder ao ID do ponto de extremidade do SQL da API do Microsoft Azure Databricks.\nNas instâncias do SQL Warehouse Serverless , o Produto é igual ao Azure Databricks Regional — Premium — Serverless SQL e o MeterName é igual ao Premium Serverless SQL DBU.\nEm seguida, somamos todos os registros para calcular o custo final da instância do SQL Warehouse.\nE é isso, pessoal. Se você gostou desse artigo, por favor, mostre seu apoio 👏. Obrigado por ler!\n","permalink":"https://julianamarialop.github.io/articles/como-calcular-o-custo-real-das-instancias-do-sql-warehouse/","summary":"Vamos aprender como calcular o custo das instâncias do SQL Warehouse no Microsoft Azure Databricks de uma maneira fácil? Então acompanhe esse artigo.","title":"Como calcular o custo real das instâncias do SQL Warehouse do Azure Databricks"},{"content":"Introdução No dinâmico cenário do armazenamento de informações, as metodologias utilizadas para estruturar dados desempenham um papel crucial na descoberta de insights valiosos para a tomada de decisões informadas. Desde as teorias fundamentais das décadas de 1990 e 2000, propostas por especialistas como Inmon (Inmon WH, Building the Data Warehouse, 1990), Kimball (Kimball R, The Data Warehouse Toolkit, 1996) e mais tarde Linstedt (Linstedt D, Data Vault Series 1 — Data Vault Overview, 2002), diversas técnicas de modelagem para armazenamento de dados tradicionais têm evoluído e sido amplamente discutidas. Neste artigo, abordaremos a Modelagem Dimensional. Vamos explorar os pontos fortes e os desafios dessa abordagem, além de discutir as melhores práticas para implementá-la no Databricks.\nPara projetar um modelo de dados dimensional, é essencial compreender profundamente os requisitos de negócios e ter um bom conhecimento das fontes de dados. A implementação mais comum da Modelagem Dimensional é o Star Schema, amplamente adotado como camada de apresentação na maioria dos data warehouses nas últimas décadas. Este método organiza os dados de maneira desnormalizada em torno de eventos mensuráveis, conhecidos como Fatos, e dos detalhes contextuais que cercam esses eventos, chamados de Dimensões.\nO sucesso da modelagem dimensional: Por que ela se tornou o padrão Ouro A Modelagem Dimensional foi introduzida para otimizar o modelo de dados para análise na camada lógica dos Sistemas de Gerenciamento de Bancos de Dados Relacionais (RDBMS) sem a necessidade de redesenhar a camada física. Enquanto as camadas lógica e física do RDBMS foram projetadas especificamente para Processamento de Transações Online (OLTP), facilitando a entrada eficiente de dados orientados a linhas e garantindo propriedades ACID (Atomicidade, Consistência, Isolamento, Durabilidade) em dados normalizados, a Modelagem Dimensional foca no processamento analítico online (OLAP). Essa abordagem permite o processamento e a agregação de dados históricos com melhor desempenho.\nBenefícios da Modelagem Dimensional Usabilidade Simplificada dos Dados: A modelagem dimensional torna a compreensão dos dados mais fácil ao estruturá-los em tabelas factuais e dimensionais. Isso facilita para os usuários finais a correspondência entre os processos do mundo real e o modelo de dados. Além disso, ela suporta a agregação eficiente de dados, servindo como uma camada semântica para ferramentas de Business Intelligence (BI).\nDesempenho de Consulta: Uma das principais vantagens da modelagem dimensional é a otimização do desempenho das consultas sem comprometer a profundidade da análise histórica. O esquema Star, uma implementação comum dessa modelagem, desnormaliza os dados em fatos e dimensões granulares de negócios, melhorando significativamente o desempenho das consultas e a agregação de dados.\nEscalabilidade e Consistência: Os modelos dimensionais são altamente escaláveis, acomodando volumes crescentes de dados e adaptando-se a requisitos de negócios em constante mudança. O esquema em estrela permite ajustes nas dimensões e nos fatos, facilita a gestão de dimensões de mudança lenta e a integração de dados incrementais. Outras abordagens, como o esquema Snowflake ou o uso de chaves substitutas nas tabelas de dimensão, ajudam a reduzir a redundância dos dados.\nCom esses benefícios, a Modelagem Dimensional se consolidou como o padrão ouro para a análise de dados em ambientes de data warehousing, oferecendo uma estrutura robusta e flexível que atende às necessidades modernas de negócios.\nMas, nem tudo são flores\u0026hellip; A Modelagem Dimensional atingiu um alto nível de otimização na camada lógica, equilibrando efetivamente a redundância e o desempenho das consultas. Isso era essencial quando os recursos de armazenamento e computação eram caros e os bancos de dados orientados a linhas não conseguiam lidar adequadamente com o processamento analítico. Com o avanço das tecnologias de dados, surgiram novas considerações sobre a modelagem dimensional tradicional.\nLimitações Operacionais e de Design: A Modelagem Dimensional exige um investimento inicial significativo no design de esquemas, além de manutenção contínua dos pipelines de dados, geralmente gerenciados por ferramentas ETL. Esta abordagem envolve uma sobrecarga operacional e enfrenta desafios de design, como a complexidade no gerenciamento de dimensões que mudam lentamente e as junções de fato a fato. No passado, esses desafios eram aceitos como compensações necessárias para melhorar o desempenho das consultas. No entanto, com as tecnologias de dados modernas, esses problemas podem ser mitigados, reduzindo a necessidade de esquemas complexos e a sobrecarga operacional.\nEvolução Tecnológica em Armazenamento e Processamento de Dados: As tecnologias modernas de armazenamento de dados proporcionam flexibilidade e escalabilidade ao desacoplar armazenamento e processamento. Essas tecnologias utilizam processamento paralelo massivo (MPP) e armazenamento físico em colunas, otimizando a agregação e análise de dados históricos por padrão. Com a redução significativa dos custos de armazenamento ao longo do tempo, as desvantagens da desnormalização foram minimizadas. Avanços como a compactação de dados na camada de armazenamento e clustering superam a complexidade de manter os dados normalizados.\nCom esses avanços tecnológicos, é possível reavaliar a necessidade de designs de esquemas complexos e explorar alternativas que ofereçam simplicidade e eficiência operacional.\nCerto, se você optar por seguir com um modelo multidimensional, aqui estão algumas recomendações práticas para o Databricks\u0026hellip; Considerando os recursos avançados de Data Warehousing do Databricks, aderir estritamente à Modelagem Dimensional, por exemplo, Star Schema, não é mais uma necessidade; no entanto possível e muito bem apoiado. Analisaremos aqui várias tecnologias Databricks que tornam possível implementar e otimizar a técnica de Modelagem Dimensional.\nPropriedades ACID: Databricks Delta Lake suporta transações ACID em tabelas Delta, simplificando a manutenção e a qualidade dos modelos dimensionais. Camadas de dados : O Star Schema pode ser implantado em uma Gold Layer da arquitetura medalhão em Databricks para potencializar a análise e a rápida tomada de decisões. Pipelines ELT : O pipeline para transformar os dados transacionais em modelos de dados dimensionais é suportado pelo Databricks SQL e Delta Live Tables (DLT) . Restrições relacionais : Ao contrário dos data lakes usuais, o Databricks oferece suporte ao aprimoramento de esquema , como restrições relacionais, por exemplo, chaves primárias, chaves estrangeiras e colunas de identidade no SQL do Databricks como chaves substitutas e restrições CHECK impostas para qualidade de dados. As restrições físicas e virtuais podem existir como metaobjetos no Catálogo do Unity . Governança unificada : todos os modelos de dados, tabelas de dimensões, tabelas de fatos e suas relações são registrados centralmente no Catálogo do Unity. Com o Unity Catalog como camada de governança unificada, Dimensões e Fatos podem ser descobertos e compartilhados entre organizações sem a necessidade de duplicá-los. Otimização : Databricks suporta Liquid Clustering , que otimiza incrementalmente o layout dos dados sem reescrever os dados, o que pode ser aplicado a tabelas de fatos, bem como a tabelas de dimensões. Espero que essas dicas simples te ajude na implementação de seu modelo. Boa Sorte !\n","permalink":"https://julianamarialop.github.io/articles/databricks-sql-e-modelagem-dimensional-otimizando-seu/","summary":"No dinâmico cenário do armazenamento de informações, as metodologias utilizadas para estruturar dados desempenham um papel crucial na descoberta de insights valiosos para a tomada de decisões informadas. Desde as…","title":"Databricks SQL e Modelagem Dimensional: Otimizando seu Data Warehouse"},{"content":"O gerenciamento eficaz de pipelines de dados é fundamental para garantir processos contínuos de desenvolvimento, teste e implantação. A integração do Git com os espaços de trabalho do Microsoft Fabric oferece uma abordagem estruturada e eficiente para gerenciar esses pipelines, promovendo a colaboração e o controle de versões de forma mais organizada e segura.\nNeste artigo, vamos explorar em detalhes as melhores práticas para a utilização de espaços de trabalho do Microsoft Fabric habilitados para Git. Abordaremos aspectos essenciais como configuração inicial, organização do código, estratégias de branching e merge, além de automação e monitoramento.\nA integração entre o Git e o Microsoft Fabric permite que equipes de desenvolvimento trabalhem de maneira colaborativa, mantendo um histórico detalhado de alterações e facilitando o rastreamento e a reversão de mudanças quando necessário. Também discutiremos como configurar pipelines de CI/CD (Integração Contínua e Entrega Contínua) utilizando Azure DevOps para garantir que o código seja testado e implantado de maneira consistente e confiável.\nO diagrama abaixo descreve a integração entre o Azure DevOps e o Microsoft Fabric, ilustrando o fluxo dos ambientes de desenvolvimento até os ambientes de produção. Esta representação visual ajuda a compreender como as alterações no código são gerenciadas e promovidas através dos diferentes estágios, desde o desenvolvimento inicial até a implantação final em produção.\n_Exemplo de configuração do Git + Workspace Fabric_\nAzure DevOps (Git)\n• Branch Principal: O branch principal para versões estáveis.\n• Ramo de Desenvolvimento: O ramo principal para desenvolvimento contínuo.\n• Ramificações de recursos: para desenvolvimento de recursos específicos.\nMicrosoft Fabric (workspaces)\nPipeline de implantação: gerencia promoção para diferentes ambientes (desenvolvimento, preparação, produção) Espaços de trabalho de desenvolvimento: ambientes de desenvolvedores individuais. Como gerenciar Projetos Complexos no Microsoft Fabric Gerenciar projetos grandes ou complexos no Microsoft Fabric pode ser desafiador, mas aplicar as melhores práticas pode facilitar esse processo. Aqui estão alguns dos principais aprendizados que podem ajudar na manutenção eficiente desses projetos.\nEstratégias de Ramificação Os desenvolvedores do Microsoft Fabric, que trabalham com pipelines, notebooks, relatórios, data warehouses, lakehouses e muito mais, precisam dominar o Git. Entendo que a curva de aprendizado pode ser íngreme, especialmente para engenheiros de dados que começaram como analistas ou DBAs, onde o Git não era uma competência essencial. No entanto, à medida que você trabalha em projetos grandes e complexos no Microsoft Fabric, o Git se torna essencial para a colaboração eficiente.\nRamificações de Recursos: Cada desenvolvedor deve criar uma ramificação a partir da ramificação de desenvolvimento para trabalhar em seu próprio recurso ou correção de bug. Para aqueles que usam o Fabric nativamente, podem anexar essa ramificação ao seu próprio espaço de trabalho pessoal, como \u0026ldquo;Espaço de Trabalho do Projeto A do MJ\u0026rdquo;. Vale notar que, atualmente, não é possível habilitar o Git em \u0026ldquo;Meu espaço de trabalho\u0026rdquo;, portanto, é necessário provisionar um novo espaço de trabalho para essa finalidade. Isso também se aplica a desenvolvedores que trabalham com relatórios do Power BI usando o desktop do Power BI, tornando essa abordagem independente do espaço de trabalho do Fabric.\nRamificação de Desenvolvimento: Utilize essa ramificação para integrar novos recursos e realizar testes antes de mesclar na ramificação principal. Implementar políticas de ramificação é crucial para evitar que os desenvolvedores façam push acidentalmente ou realizem modificações sem passar por um processo de pull request. Esse processo garante que o trabalho de cada desenvolvedor seja revisado antes de ser implantado.\nRamificação Principal: Esta deve ser a fonte da verdade para o código pronto para produção. Somente código estável e testado deve ser mesclado aqui. Marcar lançamentos (tags) é uma boa prática para separar diferentes versões, facilitando a reversão de alterações, se necessário.\nVale destacar que a ramificação principal não é habilitada para Git no espaço de trabalho do Fabric; apenas a ramificação de desenvolvimento está associada a um espaço de trabalho. Detalharemos isso na próxima seção.\nIntegração com Git no Microsoft Fabric Os espaços de trabalho do Microsoft Fabric, incluindo os do Power BI, suportam integrações com Git. Atualmente, essa integração está disponível apenas com o Azure DevOps, mas a expectativa é que o suporte ao GitHub seja adicionado em breve.\nPara configurar a integração, basta acessar as configurações do espaço de trabalho e navegar até a aba \u0026ldquo;Integração Git\u0026rdquo;. A partir daí, conecte o espaço de trabalho ao Azure DevOps. Esta integração facilita a gestão do código e a colaboração entre os desenvolvedores, tornando o processo de desenvolvimento mais robusto e eficiente.\nConclusão Implementar essas melhores práticas ajudará a otimizar o uso de espaços de trabalho do Microsoft Fabric habilitados para Git. Isso não apenas melhora a eficiência do gerenciamento de pipelines de dados, mas também fortalece a colaboração e o controle de versões dentro das equipes de desenvolvimento.\n","permalink":"https://julianamarialop.github.io/articles/melhores-praticas-para-o-uso-de-workspaces-data-fabric/","summary":"O gerenciamento eficaz de pipelines de dados é fundamental para garantir processos contínuos de desenvolvimento, teste e implantação. A integração do Git com os espaços de trabalho do Microsoft Fabric oferece uma…","title":"Melhores Práticas para o Uso de Workspaces Data Fabric + Git"},{"content":"Dando continuidade ao artigo anterior, \u0026ldquo;Databricks Lakehouse Federation: Uma Alternativa ao ETL Zero?\u0026rdquo;, vamos explorar alguns exemplos práticos para a combinação de dados em diferentes origens.\nAntes de iniciarmos a criação do ambiente, vamos identificar e citar 2 componentes principais:\nConnection (Conexão): Uma conexão com o banco de dados, utilizando um usuário e senha ou service account Foreign Catalog (Catalogo Estrangeiro): Um catálogo no Unity Catalog que aponta para o banco de dados de origem, ele conterá todos os schemas e tabelas da sua origem O nosso ambiente será composto por 4 conexões diferentes, na mesma query SQL cruzaremos informações de diversas fontes de dados em tempo real.\nPara criar as conexões, vá à aba de \u0026ldquo;gestão de conexões\u0026rdquo; no seu ambiente.\nPara exemplificar esse artigo, as conexões já estão criadas, porém para criar uma nova, basta clicar em Create Connection:\nDe um nome para sua conexão e escolha entre as fontes de dados disponíveis:\nCada tipo de conexão tem suas particularidades, então se atente as configurações de cada ambiente.\nApós criado a conexão, criaremos o foreign catalog, basta ir na tela inicial de catálogos e clicar em Create catalog.\nNa criação selecione o tipo Foreign, irá aparecer uma lista com as suas conexões já criadas, importante o campo Database precisa ser o mesmo nome do seu Database na origem.\nApós a criação, você pode explorar o seu catálogo e visualizar as tabelas na origem como se estivessem dentro do ambiente do Databricks. No entanto, é importante lembrar que qualquer consulta realizada contra essas tabelas será enviada para as origens em tempo real. Portanto, é crucial tomar cuidado para não sobrecarregar as suas fontes de dados.\nÉ importante observar que durante a navegação no catálogo, cada tipo de origem possui uma estrutura de navegação específica. No caso do PostgreSQL, por exemplo, temos a navegação por esquemas (schemas). Após selecionar os esquemas desejados, é possível visualizar as tabelas disponíveis.\nA seguir, apresentamos as tabelas do nosso exemplo.\nVejamos o mesmo no SQL Server, Bigquery e Databricks.\nBigquery: Lista de Datasets\nBigquery tabelas:\nDatabricks: Apontando para workspaces externos (isso é diferente de Delta Sharing)\nNote que aqui vejo todos os schemas dentro desse catalogo referenciado na conexão.\nDatabricks tabelas:\nExploramos até o momento quatro fontes de dados distintas, todas contendo três tabelas em comum: Autor, Editora e Livro. Agora, iremos realizar algumas consultas que cruzam informações dessas fontes.\nEm um exemplo simples, consultei a tabela \u0026ldquo;Livro\u0026rdquo; em todas as quatro origens sem a necessidade de replicar dados entre elas. Não foi preciso aplicar regras de transformação ou implementar CDC para refletir alterações originadas nas fontes de dados.\nAgora cruzaremos as 4 fontes na mesma query:\nNa mesma consulta, estamos consultando diferentes origens, cada uma com seus próprios esquemas, sem a necessidade de replicar qualquer dado para o nosso repositório central (Lake), evitando assim todas as complexidades associadas ao ETL, CDC, SCD, entre outros processos.\nE quanto aos JOINs, funcionam? Imaginemos, por exemplo, a comparação de todos os livros para verificar se os títulos estão consistentes em todas as origens.\nÉ claro que cada caso é único, e generalizações não são recomendadas. É fundamental estudar suas necessidades específicas e analisar se o conceito de Zero ETL é adequado para o seu cenário. Sempre leve em consideração as particularidades das suas fontes de dados, como consultar uma réplica para não sobrecarregar o ambiente produtivo, entre outros pontos importantes.\nÉ importante notar que o uso excessivo de JOINs pode impactar negativamente o desempenho e prejudicar a capacidade de realizar Pushdowns. Portanto, recomenda-se utilizar JOINs com moderação e considerar alternativas quando possível.\nResumo\nO recurso de federação Lakehouse do Databricks apresenta aplicabilidade em casos de uso como os seguintes:\nQuando não se deseja realizar a ingestão de dados no ambiente do Databricks. Quando se pretende que as consultas tirem proveito do processamento de computação realizado no sistema de banco de dados externo. Quando se busca utilizar os benefícios de governança de dados oferecidos pelo Unity Catalog, tais como controle de acesso granular, linhagem de dados e capacidade de pesquisa, centralizando essas funcionalidades em um único local, ao mesmo tempo em que se economiza em armazenamento e processamento. Conforme destacado anteriormente nas análises de pontos fortes e fracos, embora haja economia de armazenamento (evitando duplicação de dados entre a origem e o Lakehouse) e de processamento de clusters (delegando o processamento pesado para a origem), é imprescindível examinar cada caso de uso individualmente. É fundamental considerar a possibilidade de não sobrecarregar as fontes de dados com consultas frequentes e intensivas, que podem não ser otimizadas devido às limitações de pushdown.\nEstou atualmente testando a federação Lakehouse em um cenário de validação de indicadores. Por exemplo, todo o processo de ETL/ELT é realizado para o Lakehouse, com suas respectivas modelagens e transformações. Para verificar a integridade dos dados em comparação com a origem, estou utilizando a federação Lakehouse para consultar a origem de forma pontual e validar a concordância dos dados.\nEssa abordagem tem se mostrado bastante útil e eficiente para esses cenários, inclusive para a exploração de dados antes de iniciar os processos de ELT para o Lakehouse.\nPara saber mais, recomenda-se a leitura detalhada de toda a documentação disponível e realizar testes extensivos. É fundamental compreender o caso de uso específico e avaliar se a federação Lakehouse é adequada para o seu cenário particular.\nReferências\nhttps://learn.microsoft.com/en-us/azure/databricks/query-federation/\n","permalink":"https://julianamarialop.github.io/articles/databricks-lakehouse-federation-explorando-exemplos-praticos/","summary":"Dando continuidade ao artigo anterior, \u0026ldquo;Databricks Lakehouse Federation: Uma Alternativa ao ETL Zero?\u0026rdquo; , vamos explorar alguns exemplos práticos para a combinação de dados em diferentes origens.","title":"Databricks Lakehouse Federation: Explorando Exemplos Práticos"},{"content":"Lançada em Dezembro de 2023, a funcionalidade de Federação Lakehouse está atualmente em Prévia Pública, mas possui um enorme potencial. No artigo de hoje, explorarei algumas visões interessantes, como a capacidade de cruzar informações entre Databricks, BigQuery, SQL Server e PostgreSQL em uma única consulta SQL.\nO que é um lakehouse federation? Databricks lakehouse federation é uma feature de federação de consultas que permite aos usuários e sistemas executar consultas contra várias fontes de dados sem a necessidade de migrar todos os dados para um sistema unificado.\nAqui você elimina a necessidade de criar ETLs complexos, aplicar CDC, SCD, entre outras técnicas, e ainda correr o risco dos dados ficarem diferentes da origem, isso pode ser muito útil para vários cenários.\nPodemos traduzir federation ou federação na tradução literal como uma forma de democratizar o acesso dos dados de diversas fontes utilizando uma única plataforma, delegando o trabalho de processamento para as origens, nesse contexto a federação de proporciona a possibilidade de agilizar a exploração de dados, evitar duplicação de storage entre outros benefícios.\n_Federação de Dados_\nComo funciona? A Federação de Lakehouse do Databricks utiliza o Unity Catalog para gerenciar consultas distribuídas. Para utilizar a Federação de Lakehouse do Databricks, é necessário configurar conexões de leitura utilizando os drivers incluídos nativamente nos Clusters, tais como Pro SQL Warehouses, Serverless SQL Warehouses e Databricks Runtime \u0026gt;=13.1. As fontes de dados atualmente suportadas incluem:\nMySQL PostgreSQL Amazon RedShift Snowflake SQL Server Azure Synapse Google BigQuery Databricks (com outros workspaces) Em essência, o Databricks envia consultas para execução nos bancos de dados de origem utilizando drivers nativos como o JDBC e retorna os dados resultantes para o Databricks em tempo real.\nVantagens e Desvantagens Agilidade: Permite a execução de consultas em dados provenientes de diversas fontes (citadas acima) sem a necessidade de migrá-los, o que pode economizar tempo e recursos.\nEscalabilidade: Pode ser utilizado para conectar-se a fontes de dados de qualquer tamanho, permitindo que o processamento seja delegado à origem.\nGovernança: Utiliza o Unity Catalog para gerenciar a governança de dados, garantindo a segurança e a confiabilidade dos seus dados.\nDesempenho potencialmente inferior aos métodos tradicionais de ETL, devido à ausência de movimentação dos dados para um sistema unificado. Isso pode resultar em latência de rede e possíveis problemas de desempenho, já que nem todos os filtros e funções podem ser enviados para a origem, conhecido como \u0026ldquo;pushdowns\u0026rdquo;.\nAo direcionar consultas para ambientes OLTP de produção, há o risco de sobrecarregar o desempenho das origens, ao contrário de ETLs mais pontuais ou o uso de CDC para a coleta de dados.\nLimitações É importante estar ciente das limitações ao utilizar a Federação Lakehouse:\nConexões somente de leitura: As conexões estabelecidas são estritamente para leitura de dados. Pushdowns: Nem todos os tipos de pushdowns são suportados, e essa compatibilidade varia de acordo com a fonte de dados. Tipos de dados: É necessário prestar atenção às tabelas de mapeamento entre a origem e o Databricks para garantir a consistência dos tipos de dados. Sensibilidade a maiúsculas e minúsculas: O sistema não suporta nomes de objetos com diferenciação entre maiúsculas e minúsculas, resultando na uniformização dos nomes em minúsculas. Isso pode ocasionar problemas dependendo da origem dos dados. Limitações específicas de cada origem: Cada fonte de dados pode apresentar limitações distintas que precisam ser consideradas durante a implementação e o uso da Federação Lakehouse. Nos próximos artigos, iremos abordar o Lakehouse Federation de forma prática!\nReferências\nhttps://learn.microsoft.com/pt-br/azure/databricks/query-federation/\nhttps://www.databricks.com/resources/webinar/query-federation-lakehouse\n","permalink":"https://julianamarialop.github.io/articles/databricks-lakehouse-federation-uma-alternativa-ao-etl/","summary":"Lançada em Dezembro de 2023, a funcionalidade de Federação Lakehouse está atualmente em Prévia Pública, mas possui um enorme potencial. No artigo de hoje, explorarei algumas visões interessantes, como a capacidade de…","title":"Databricks Lakehouse Federation: Uma Alternativa ao ETL Zero?"},{"content":"Hoje o tema é Data Factory + DevOps, vamos conferir ?\nCI é a prática de testar automaticamente cada alteração de código, enquanto o CD implementa essas alterações nos sistemas de staging ou produção. No Azure Data Factory, a CI/CD envolve a movimentação de pipelines entre diferentes ambientes.\nVeja como funciona:\n1️⃣ Os desenvolvedores criam um branch de feature para fazer alterações e depurar a execução de pipelines.\n2️⃣ As alterações são revisadas por meio de pull requests e mescladas no branch principal.\n3️⃣ As alterações são então publicadas no factory de desenvolvimento.\n4️⃣ Quando estiverem prontas, as alterações são implantadas em um factory de teste ou UAT usando o Azure Pipelines.\n5️⃣ Após a verificação, as alterações podem ser implantadas no factory de produção.\nMelhores práticas para CI/CD no Azure Data Factory:\n✅ Configure a integração com o Git apenas para o factory de desenvolvimento.\n✅ Use scripts de pré e pós-implantação para tarefas como parar/reiniciar acionadores.\n✅ Considere o uso de um factory compartilhado para runtimes de integração em todas as etapas.\n✅ Gerencie com cuidado a implantação de pontos de extremidade privados para evitar conflitos.\n✅ Separe vaults de chaves para diferentes ambientes e mantenha nomes de segredos consistentes.\n✅ Evite espaços nos nomes de recursos; use \u0026lsquo;_\u0026rsquo; ou \u0026lsquo;-\u0026rsquo; em vez disso.\n✅ Tenha cautela ao alterar o repositório para evitar erros.\n✅ Utilize o controle de exposição e flags de recursos para gerenciar a lógica com base no ambiente.\n❌ Lembre-se de que a publicação seletiva de recursos não é recomendada devido a dependências.\nUm Abraço e até o próximo artigo !\n","permalink":"https://julianamarialop.github.io/articles/integracao-continua-e-entrega-cicd-azure-data-factory/","summary":"CI é a prática de testar automaticamente cada alteração de código, enquanto o CD implementa essas alterações nos sistemas de staging ou produção. No Azure Data Factory, a CI/CD envolve a movimentação de pipelines entre…","title":"🚀 Integração Contínua e Entrega Contínua (CI/CD) no Azure Data Factory! 🔁✨"},{"content":"Muitos clientes com os quais trabalho implementam uma arquitetura Medallion para organizar logicamente seus dados em um Lakehouse. À medida que os dados fluem, eles passam por vários estágios ou camadas. O design mais conhecido, como visto abaixo, utiliza uma camada Bronze, Prata e Ouro. Daí o termo \u0026ldquo;medalhão\u0026rdquo;.\nEmbora o design de três camadas seja comum e amplamente reconhecido, tenho notado muitas discussões sobre o escopo, o propósito e as melhores práticas de cada uma dessas camadas. Também observei que há uma grande diferença entre teoria e prática.\nEstratégia da Plataforma de Dados A consideração mais importante ao estratificar sua arquitetura em camadas é determinar como sua plataforma de dados será utilizada. Uma plataforma de dados centralizada e compartilhada terá uma estrutura diferente daquela de uma plataforma federada multiplataforma utilizada por diversos domínios. As camadas também variam dependendo se você alinha suas plataformas com o lado da origem dos sistemas ou com o lado do consumo de sua arquitetura. Uma plataforma alinhada à origem geralmente é mais fácil de padronizar em termos de camadas e estrutura do que uma plataforma alinhada ao consumidor, devido à diversidade de usos de dados no lado do consumo.\nLevando essas considerações em conta, vamos explorar camada por camada. Para cada camada, começarei com alguns objetivos abstratos e de alto nível e, em seguida, aprofundarei com observações práticas.\nÁrea de Aterrissagem (Landing) Uma camada opcional vista frequentemente em organizações que implementam uma plataforma de dados é uma área de aterrissagem ou zona de aterrissagem. Esta é uma localização intermediária na qual os dados de diversos sistemas de origem são armazenados antes de serem movidos para a camada Bronze. Essa camada é frequentemente necessária em situações em que é difícil extrair dados do sistema de origem alvo, como quando se trabalha com clientes externos ou fornecedores de SaaS. Nessas situações, há uma dependência ou, por vezes, os dados são fornecidos em um formato ou estrutura não preferencial.\nO design de uma zona de destino varia de organização para organização. Muitas vezes, é simplesmente uma conta de armazenamento de blobs. Em outros casos, a zona de destino faz parte dos serviços do datalake, como um contêiner, bucket ou pasta específica onde os dados são ingeridos. Os dados nas zonas de destino costumam ser altamente diversificados em termos de formatos de arquivo, que podem incluir CSV, JSON, XML, Parquet, Delta e outros.\nCamada Bronze A camada Bronze é geralmente um reservatório que armazena dados em seu estado natural e original. Ela contém dados não validados (não é necessário definir esquemas primeiro). Nessa camada, os dados são obtidos usando cargas completas ou cargas delta. Os dados armazenados na camada Bronze geralmente possuem as seguintes características:\nMantêm o estado bruto da fonte de dados na sua estrutura \u0026ldquo;como está\u0026rdquo;. Os dados são imutáveis (apenas leitura). Gerenciados usando tabelas particionadas por intervalo, por exemplo, usando uma estrutura de pasta AAAAMMDD ou data/hora. Mantêm o histórico completo (não processado) de cada conjunto de dados em um formato de armazenamento eficiente, como Parquet ou Delta. Para dados transacionais, podem ser acrescentados de forma incremental e crescer com o tempo. Fornecem a capacidade de recriar qualquer estado de um determinado sistema de dados. Podem ser uma combinação de streaming e transações em lote. Podem incluir metadados adicionais, como informações de esquema, nomes de arquivos de origem ou registro da hora em que os dados foram processados. Uma pergunta comum é: \u0026ldquo;Qual é o melhor formato de arquivo? Devo usar Delta ou Parquet?\u0026rdquo; Delta é mais rápido, mas, como os dados já possuem controle de versão ou histórico usando uma estrutura de pastas, não vejo nenhum benefício atraente em manter um log de transações ou aplicar controle de versão. Os dados na camada Bronze geralmente são dados novos ou estão sendo anexados. Portanto, se você preferir usar Parquet, está tudo bem. Alternativamente, você pode usar Delta em alinhamento com todas as outras camadas.\nAlgumas pessoas argumentam que os dados na camada Bronze podem ser úteis para consultas ou análises ad hoc por parte dos usuários corporativos. Na minha experiência, trabalhando com clientes, raramente vejo dados brutos sendo usados como entrada para executar consultas ou análises ad hoc. Trabalhar com dados brutos exige um profundo entendimento de como o sistema de origem foi projetado e a elaboração de lógica de negócios complexa que está encapsulada nos próprios dados. Geralmente, esses dados contêm muitas tabelas pequenas e é difícil protegê-los. Em resumo, a camada Bronze é uma camada intermediária e serve como ponto de entrada para outras camadas, sendo acessada principalmente por equipes técnicas.\nCamada Prata A camada Prata fornece uma estrutura refinada para os dados que foram ingeridos. Ela representa uma versão validada e enriquecida dos dados que pode ser confiável para cargas de trabalho posteriores, tanto operacionais quanto analíticas. A camada Prata geralmente possui as seguintes características:\nUtiliza regras de qualidade de dados para validação e processamento de dados. Normalmente contém apenas dados funcionais, filtrando dados técnicos ou irrelevantes provenientes da camada Bronze. Aplica historização, geralmente usando técnicas de dimensões de alteração lenta (SCD) do tipo 2 ou tipo 4. Isso envolve a adição de colunas como início, fim e atual. Armazena dados em um formato de armazenamento eficiente, preferencialmente Delta ou Parquet. Usa controle de versão para reverter erros de processamento. Lida com dados ausentes, padroniza campos vazios ou sujos. É frequentemente enriquecida com dados de referência e/ou mestres. Os dados muitas vezes são organizados em torno de áreas temáticas específicas. Os dados geralmente estão alinhados e organizados com o sistema de origem. Para a camada Prata, alguns pontos de atenção incluem:\nA camada Prata pode atuar como uma camada de armazenamento temporário em alguns casos, onde dados mais antigos podem ser excluídos ou contas de armazenamento podem ser criadas sob demanda. Isso depende do uso pretendido dos dados. Se você não planeja usar os dados em seu contexto original para relatórios operacionais ou análises operacionais, a camada Prata pode ser usada temporariamente. No entanto, se você planeja reter o histórico e usar esses dados para relatórios e análises operacionais, é recomendável tornar a camada Prata persistente.\nOs dados na camada Prata podem ser consultados. Portanto, em termos de modelagem de dados, é recomendável seguir um modelo de dados mais desnormalizado. Isso ocorre porque esse design utiliza melhor o armazenamento distribuído baseado em colunas que é separado da computação. Embora seja possível implementar um design mais normalizado, não há argumentos convincentes para fazê-lo, uma vez que a camada Delta já oferece isolamento e proteção, como o esquema de mesclagem para lidar com alterações e o histórico disponível na camada Bronze. Portanto, adicionar complexidade extra e diminuir o desempenho não é geralmente recomendado.\nOutra discussão que surge é se deve haver uma junção ou integração de dados entre aplicativos e sistemas de origem na camada Prata. A resposta depende do cenário. Se você planeja usar a camada Prata para relatórios operacionais ou análises operacionais, é geralmente recomendável não combinar ou integrar dados entre sistemas de origem, a fim de evitar acoplamentos desnecessários entre aplicativos. No entanto, se você deseja um design mais isolado, a integração de dados entre fontes pode ocorrer em uma camada superior.\nO mesmo argumento mencionado acima também se aplica quando você alinha suas Lakehouses com o lado do sistema de origem de sua arquitetura. Se você planeja criar produtos de dados e deseja fortemente alinhar a propriedade dos dados, não é aconselhável que seus engenheiros façam a junção de dados entre aplicativos de outros domínios. Isso criaria pontos de acoplamento desnecessários.\nQuanto a enriquecimentos, como cálculos, se você planeja facilitar relatórios operacionais que exigem enriquecimentos, é recomendável enriquecer os dados na camada Prata. Isso pode resultar em alguma calibração adicional ao combinar dados em um estágio posterior na camada Ouro, mas aproveita os benefícios da flexibilidade.\nCamada Ouro Os dados na camada Ouro, de acordo com os princípios de uma arquitetura Lakehouse, geralmente são organizados em bancos de dados \u0026ldquo;específicos do projeto\u0026rdquo; prontos para consumo. Nesse contexto, a propriedade dos dados pode ser considerada alterada, uma vez que os dados não estão mais alinhados entre a origem e o sistema. Em vez disso, foram integrados e combinados com outros dados.\nNa camada Ouro, dependendo dos casos de uso, é recomendável um modelo de dados mais desnormalizado e otimizado para leitura, com menos junções. Portanto, um esquema em estrela no estilo Kimball pode ser apropriado. Além disso, espere as seguintes características:\nAs tabelas de Ouro representam dados que foram transformados para consumo ou casos de uso. Os dados são armazenados em um formato de armazenamento eficiente, de preferência Delta. A camada Ouro utiliza controle de versão para reverter erros de processamento. A historização é aplicada apenas para o conjunto de casos de uso ou consumidores, de modo que a camada Ouro pode ser uma seleção ou agregação de dados encontrados na camada Prata. Na camada Ouro, regras de negócios complexas são aplicadas, o que inclui atividades de pós-processamento, cálculos, enriquecimentos e otimizações específicas dos casos de uso. Os dados são altamente governados e bem documentados. A camada Ouro costuma ser a mais complexa, pois seu design depende do escopo da arquitetura. No cenário mais simples, em que seus Lakehouses estão alinhados apenas com o lado do sistema de origem, os dados na camada Ouro representarão dados de \u0026ldquo;produtos de dados\u0026rdquo;. Esses dados são genéricos e podem ser usados para uma ampla distribuição em diversos domínios após a distribuição. Nesse caso, espera-se que os dados atendam às necessidades precisas dos consumidores analíticos após a distribuição em outra plataforma, que também pode ser uma Lakehouse. Assim, os dados são modelados com uma estrutura específica para o caso de uso.\nSe o escopo da Lakehouse for maior e abranger ambos os lados, camadas adicionais serão necessárias. Algumas organizações chamam essas camadas adicionais de espaço de trabalho ou camadas de apresentação. Nesse design, os dados na camada Ouro são mais genéricos e servem como camada de integração a partir da qual data marts ou subconjuntos podem ser preenchidos. Algumas empresas também usam essas camadas para compartilhar dados com outras plataformas ou equipes, fazendo seleções e/ou pré-filtragens para casos de uso específicos.\nEspero que você tenha achado este artigo útil. Para todos que estão construindo uma plataforma de dados de próxima geração, aproveitem a jornada!\n","permalink":"https://julianamarialop.github.io/articles/databricks-melhores-praticas-para-gerenciamento-de-bronze/","summary":"Muitos clientes com os quais trabalho implementam uma arquitetura Medallion para organizar logicamente seus dados em um Lakehouse. À medida que os dados fluem, eles passam por vários estágios ou camadas. O design mais…","title":"Databricks - Melhores Práticas para Gerenciamento de Bronze, Prata e Ouro (Arquitetura Medalhão)"},{"content":"Olá a todos, essa semana vamos apresentar algumas melhores práticas para um pipeline de ingestão de dados:\n💡 Crie pipelines dinâmicos com Padrões de Ingestão Impulsionados por Metadados:\n✅ O ADF gera código usando metadados para ler fontes de dados e tabelas/diretórios para o lakehouse.\n✅ Agilize a incorporação de novas fontes de dados adicionando metadados ao framework da solução.\n💡 Ingestão de dados usando Auto Loader ou diretamente no Delta Lake:\n✅ O Auto Loader processa eficientemente novos arquivos de dados no ADLS Gen2, com inferência de esquema e evolução de alterações nos dados.\n✅ O conector Delta Lake do ADF aterrissa automaticamente os dados no ADLS Gen2 no formato de arquivo Delta Lake.\n💡 Execute facilmente Jobs do Azure Databricks:\n✅ Use as atividades web do ADF e a API de Jobs do Azure Databricks para executar jobs do Databricks e pipelines do Delta Live Tables.\n✅ Beneficie-se das últimas funcionalidades dos jobs, como reutilização de clusters, passagem de parâmetros e reparo e rerun.\n💡 Aproveite os Pools + Clusters de Jobs:\n✅ O ADF pode usar pools do Azure Databricks para criar clusters de jobs para execuções de atividades de notebook.\n✅ Desfrute de isolamento de carga de trabalho, preços reduzidos, auto-terminação, tolerância a falhas e criação mais rápida de clusters de jobs.\n💡 Garanta autenticação segura com a Identidade Gerenciada do ADF:\n✅ Autentique o ADF no Azure Databricks usando autenticação de identidade gerenciada.\n✅ Fornece uma técnica de autenticação mais segura e elimina a necessidade de gerenciar tokens de acesso pessoais.\nEspero que tenha gostado da leitura !\n","permalink":"https://julianamarialop.github.io/articles/melhores-praticas-do-azure-data-factory-e-databricks/","summary":"Olá a todos, essa semana vamos apresentar algumas melhores práticas para um pipeline de ingestão de dados:","title":"🔵✨ Melhores Práticas do Azure Data Factory e Azure Databricks ✨🔵"},{"content":"As soluções tradicionais de análise de dados em grande escala contam com data warehouses e consultas SQL para armazenar e recuperar dados. No entanto, a ascensão do big data, caracterizada por grandes #volumes , #variedade e #velocidade de novos dados, juntamente com armazenamento acessível e computação distribuída baseada em nuvem, introduziu uma nova abordagem: o datalake. Ao contrário dos data warehouses, os datalakes armazenam informações como arquivos sem um esquema fixo.\nPara preencher a lacuna entre data warehouses e datalakes, engenheiros e analistas de dados estão cada vez mais recorrendo a uma solução híbrida chamada data lakehouse. O Microsoft Fabric oferece uma solução lakehouse poderosa que combina a escalabilidade do armazenamento de arquivos em um armazenamento OneLake (criado no Azure Data Lake Store Gen2) com uma camada de metadados relacionais baseada no formato de tabela Delta Lake de código aberto. Isso permite armazenar dados em arquivos dentro do seu datalake e aplicar um esquema relacional para habilitar consultas SQL.\nCom o Microsoft Fabric, você pode aproveitar as vantagens dos data warehouses e dos datalakes, permitindo definir tabelas e exibições usando os recursos de esquema do Delta Lake e consultá-los usando a semântica SQL familiar.\nConfigurando seu espaço de trabalho no Microsoft Fabric Configurar um espaço de trabalho no Microsoft Fabric é o primeiro passo para desbloquear seus recursos de dados. Seguindo estas instruções simples, você estará pronto para trabalhar com dados perfeitamente:\nAcesse o Microsoft Fabric visitando https://app.fabric.microsoft.com e faça login. Navegue até a barra de menu do lado esquerdo e clique na opção Workspaces (você a reconhecerá pelo ícone semelhante a 🗇). Crie um novo espaço de trabalho escolhendo um nome que atenda às suas necessidades. Certifique-se de selecionar um modo de licenciamento que inclua capacidade do Fabric, como Avaliação, Premium ou Fabric. Assim que seu novo espaço de trabalho for criado, ele se abrirá, parecendo vazio e pronto para você começar a aproveitar seu potencial. Criando um Data Lakehouse no Microsoft Fabric Agora que você estabeleceu seu espaço de trabalho, é hora de mergulhar na experiência de Engenharia de Dados no portal e construir um data lakehouse para abrigar seus valiosos arquivos de dados. Siga estas etapas para começar:\nNo portal do Power BI, localize o canto inferior esquerdo e mude para a experiência Data Engineering. A página inicial da Engenharia de Dados apresenta uma variedade de blocos que permitem criar facilmente ativos de engenharia de dados comumente usados. Na página inicial do Data Engineering, inicie a criação de um novo Lakehouse fornecendo-lhe um nome adequado ao seu propósito.\nApós uma breve espera, um novo datalake será gerada, abrindo possibilidades emocionantes de exploração.\nObserve o painel do explorador Lakehouse no lado esquerdo, que lhe dá acesso para navegar pelas tabelas e arquivos que residem em sua lakehouse. A pasta Tabelas hospeda tabelas que podem ser consultadas usando a semântica SQL. Essas tabelas no lakehouse do Microsoft Fabric aderem ao formato de arquivo Delta Lake de código aberto, amplamente empregado no Apache Spark.\nA pasta Arquivos contém os arquivos de dados armazenados no armazenamento OneLake, designado especificamente para seu datalake. Esta pasta também permite criar atalhos para fazer referência a dados armazenados externamente.\nAtualmente, seu lakehouse não contém nenhuma tabela ou arquivo, fornecendo a você uma base limpa para iniciar sua jornada de exploração de dados.\nIngestão de dados em seu Microsoft Fabric Lakehouse Para enriquecer seu lakehouse com dados valiosos, o Microsoft Fabric oferece vários métodos de ingestão de dados. Embora pipelines e fluxos de dados forneçam opções avançadas para copiar dados de fontes externas, uma das abordagens mais simples é fazer upload de arquivos ou pastas diretamente do seu computador local. Siga estas etapas para fazer upload de dados perfeitamente para seu lakehouse:\nBaixe o arquivo sales.csv da seguinte fonte: URL do arquivo sales.csv do Kaggle. Salve o arquivo como sales.csv em seu computador local.\nRetorne à guia do navegador onde seu datalake está aberta. No painel do Lakehouse Explorer, acesse a pasta Arquivos e clique no menu de reticências (\u0026hellip;). No menu suspenso, selecione “Nova subpasta” para criar uma subpasta chamada “dados”.\nNo menu de reticências da pasta de dados recém-criada, escolha \u0026ldquo;Upload\u0026rdquo; e selecione \u0026ldquo;Upload file\u0026rdquo;. Continue carregando o arquivo sales.csv do seu computador local. Assim que o upload for concluído, navegue até a pasta Arquivos/dados e verifique se o arquivo sales.csv foi carregado com sucesso. Deve estar visível no conteúdo da pasta. Para visualizar o conteúdo do arquivo enviado, basta selecionar o arquivo sales.csv. Seguindo essas etapas, você pode facilmente trazer dados para seu Microsoft Fabric lakehouse, permitindo explorar e analisar o arquivo sales.csv carregado e desbloquear seus insights.\nTransformando dados de arquivos em tabelas consultáveis Para aprimorar a usabilidade dos dados de vendas carregados, o Microsoft Fabric oferece a capacidade de carregar os dados de um arquivo em uma tabela. Isso permite que analistas e engenheiros de dados aproveitem consultas SQL para uma exploração eficiente de dados. Siga estas etapas para carregar perfeitamente os dados do arquivo em uma tabela:\nComece navegando até a página inicial e selecionando a pasta Arquivos/Dados. Aqui você encontrará o arquivo sales.csv que foi carregado anteriormente.\nAcesse o menu de reticências (\u0026hellip;) do arquivo sales.csv e escolha \u0026ldquo;Carregar em tabelas\u0026rdquo; nas opções fornecidas.\nNa caixa de diálogo Carregar na tabela, atribua um nome adequado à tabela, como \u0026ldquo;vendas\u0026rdquo;, e confirme a operação de carregamento. Agora, espere pacientemente que o processo de criação da tabela e carregamento de dados seja concluído.\nNo painel do explorador Lakehouse, localize a tabela de “vendas” recém-criada para obter visibilidade de seus dados.\nPara explorar os arquivos subjacentes associados à tabela de vendas, acesse o menu de reticências (\u0026hellip;) da tabela e selecione \u0026ldquo;Exibir arquivos\u0026rdquo;. Vale ressaltar que os arquivos de uma tabela Delta são armazenados no formato Parquet, incluindo uma subpasta chamada “_delta_log” que mantém os detalhes transacionais aplicados à tabela.\nSeguindo essas etapas, você pode transformar os dados de vendas carregados em uma tabela consultável, abrindo um mundo de possibilidades para análise de dados e extração de insights valiosos no Microsoft Fabric.\nDesbloqueando a exploração de dados com SQL Depois de criar um lakehouse e definir tabelas dentro dele, um poderoso endpoint SQL é gerado automaticamente. Este endpoint permite que você consulte suas tabelas sem esforço usando instruções SQL SELECT, permitindo uma exploração de dados contínua. Siga estas etapas para aproveitar o endpoint SQL em seu Microsoft Fabric lakehouse:\nNo canto superior direito da página Lakehouse, localize a opção que alterna entre Lakehouse e SQL endpoint. Clique nele para mudar para o modo de endpoint SQL. Aguarde um breve momento para que o terminal de consulta SQL seja inicializado. Em breve, você verá uma interface visual que permitirá consultar tabelas em seu lakehouse. A interface abrirá possibilidades interessantes para exploração de dados, conforme ilustrado aqui. Para iniciar a consulta, utilize o botão \u0026ldquo;Nova consulta SQL\u0026rdquo;, que abrirá um editor de consultas. SELECIONE CÓDIGO DO PRODUTO, AVG(QUANTITYORDERED) AS AvgQuantityOrdered, AVG(PRICEEACH) AS AvgPrice DE sales_data_sample AGRUPAMENTO POR CÓDIGO DE PRODUTO; No editor de consultas, insira a consulta SQL desejada. Por exemplo, calcule a quantidade média encomendada e o preço médio para cada código de produto. Para executar a consulta e visualizar os resultados, basta clicar no botão “▷ Executar”. Seguindo essas etapas, você pode aproveitar o potencial do endpoint SQL em seu Microsoft Fabric lakehouse, permitindo executar consultas SQL sem esforço e obter insights valiosos de seus dados.\nCriação de relatórios poderosos com Power BI Dentro do Microsoft Fabric lakehouse, as tabelas que você define tornam-se automaticamente parte de um conjunto de dados padrão, formando a base para relatórios e análises com o Power BI. Siga estas etapas para aproveitar o potencial dos conjuntos de dados padrão e criar relatórios esclarecedores:\nNa parte inferior da página SQL Endpoint, localize e selecione a guia \u0026ldquo;Modelo\u0026rdquo;. Esta guia revela o esquema do modelo de dados associado ao conjunto de dados. Na faixa do menu, navegue até a guia “Relatórios” e clique em “Novo relatório”. Esta ação abre uma nova guia do navegador dedicada à criação do seu relatório. No painel Dados à direita, expanda a tabela “vendas”. Selecione os campos desejados para o seu relatório, como “PRODUCTLINE” e “VENDAS”. Uma visualização de tabela é adicionada automaticamente ao relatório, mostrando os dados selecionados.\nPara otimizar o espaço de trabalho, oculte os painéis Dados e Filtros, criando mais espaço para o design do relatório. Certifique-se de que a visualização da tabela esteja selecionada e, no painel Visualizações, personalize a visualização convertendo-a em um gráfico de barras agrupado. Ajuste o tamanho e a aparência do gráfico conforme desejado.\nPara salvar o progresso realizado, acesse o menu Arquivo e selecione “Salvar”. Salve o relatório como \u0026ldquo;Relatório de vendas de produtos\u0026rdquo; no espaço de trabalho que você criou anteriormente.\nFeche a guia do navegador que contém o relatório para retornar ao endpoint SQL do seu lakehouse. Na barra de menu central à esquerda, selecione seu espaço de trabalho para confirmar se ele agora inclui os seguintes elementos:\n- Seu datalake\n- O endpoint SQL para seu datalake\n- Um conjunto de dados padrão representando as tabelas em seu datalake\n- O relatório \u0026ldquo;Relatório de vendas de produtos\u0026rdquo;\nSeguindo essas etapas, você pode aproveitar os conjuntos de dados padrão no Lakehouse do Microsoft Fabric para criar relatórios visualmente atraentes e esclarecedores usando o Power BI. Isso permite que você obtenha inteligência de negócios valiosa e tome decisões baseadas em dados com facilidade.\nLimpar recursos Depois de criar com sucesso uma lakehouse e importar dados para ela, é essencial garantir um gerenciamento eficiente de recursos. Esta seção irá guiá-lo através do processo de limpeza de seus recursos. Vamos mergulhar:\nSe você concluiu a exploração do datalake e não precisa mais do espaço de trabalho criado para este exercício, é hora de removê-lo.\nNo lado esquerdo da interface, localize e selecione o ícone que representa sua área de trabalho. Esta ação exibe todos os itens contidos na área de trabalho.\nNa barra de ferramentas, acesse o menu de reticências (\u0026hellip;) e clique em “Configurações do espaço de trabalho”.\nNa seção “Outros” das configurações, encontre e selecione a opção “Remover este espaço de trabalho”.\nSeguindo essas etapas, você pode organizar seus recursos de maneira eficaz, eliminando o espaço de trabalho associado ao exercício. Isso garante a utilização eficiente de recursos em seu ambiente Microsoft Fabric Lakehouse. Depois de criar com sucesso uma lakehouse e importar dados para ela, é essencial garantir um gerenciamento eficiente de recursos. Esta seção irá guiá-lo através do processo de limpeza de seus recursos. Vamos mergulhar:\nSe você concluiu a exploração do datalake e não precisa mais do espaço de trabalho criado para este exercício, é hora de removê-lo.\nNo lado esquerdo da interface, localize e selecione o ícone que representa sua área de trabalho. Esta ação exibe todos os itens contidos na área de trabalho.\nNa barra de ferramentas, acesse o menu de reticências (\u0026hellip;) e clique em “Configurações do espaço de trabalho”.\nNa seção “Outros” das configurações, encontre e selecione a opção “Remover este espaço de trabalho”.\nSeguindo essas etapas, você pode organizar seus recursos de maneira eficaz, eliminando o espaço de trabalho associado ao exercício. Isso garante a utilização eficiente de recursos em seu ambiente Microsoft Fabric Lakehouse.\nUfa, artigo grande para leitura mas espero que seja de grande ajuda !!!\nUm abraço !\n","permalink":"https://julianamarialop.github.io/articles/hands-on-com-o-microsoft-fabric-um-guia-para-iniciantes/","summary":"As soluções tradicionais de análise de dados em grande escala contam com data warehouses e consultas SQL para armazenar e recuperar dados. No entanto, a ascensão do big data, caracterizada por grandes #volumes …","title":"Hands-on com o Microsoft Fabric: um guia para iniciantes (parte 1)"},{"content":"Olá pessoal, nesse artigo vou comentar um pouco sobre essas plataformas de dados.\nInicialmente, vamos por definições:\n🔹 Databricks: O Azure Databricks é uma plataforma de análise baseada no Apache Spark otimizada para o Microsoft Azure. Ele oferece fluxos de trabalho simplificados e um espaço de trabalho interativo para colaboração entre cientistas de dados, engenheiros de dados e analistas de negócios. Com tempos de execução otimizados para aprendizado de máquina e suporte a GPUs, o Databricks é ideal para o desenvolvimento de aprendizado de máquina. Ele também se integra ao Azure ML e fornece controle de versão rigoroso e capacidades de CI/CD.\n🔹 Synapse Analytics: O Azure Synapse é um serviço de análise ilimitado que combina data warehousing empresarial e análise de Big Data. Ele permite consultar dados usando recursos sob demanda ou provisionados sem servidor em escala. O Synapse reúne esses dois mundos com uma experiência unificada para ingestão de dados, preparação, gerenciamento e entrega, atendendo às necessidades imediatas de BI e aprendizado de máquina.\n💡 Quando Usar o Databricks e o Synapse Analytics 💡 ✅ Desenvolvimento de Aprendizado de Máquina: Se você está focado no aprendizado de máquina, o Databricks é a escolha preferida. Ele oferece tempos de execução otimizados para ML, clusters habilitados para GPU e uma versão gerenciada do MLflow. Você também pode aproveitar o AzureML a partir do Databricks e se beneficiar da integração rigorosa de controle de versão e CI/CD em ambientes completos.\n✅ Descoberta Ad-hoc de Data Lake: Tanto o Synapse quanto o Databricks são adequados para descoberta ad-hoc de data lake. O Databricks permite consultar dados usando Python, Scala ou R após montar o data lake em seu espaço de trabalho. O Synapse, por outro lado, fornece SQL sob demanda ou Spark para consultar dados do seu data lake. Escolha a ferramenta ou interface que esteja alinhada com suas preferências e expertise.\n✅ Transformações em Tempo Real: Para transformações em tempo real, o Databricks é a opção recomendada. Ele oferece o Spark Structured Streaming com recursos avançados como clustering Z-order e otimizações de junção. O Autoloader do Databricks permite o carregamento incremental. Enquanto o Synapse pode ingestar dados em tempo real usando o Stream Analytics, atualmente não oferece suporte total ao Delta e não se concentra totalmente em transformações em tempo real.\n✅ Análises SQL e Data Warehousing: Se você precisa de capacidades abrangentes de análise SQL e data warehousing, o Synapse é a escolha certa. Ele fornece uma experiência completa de data warehousing com modelos de dados relacionais, procedimentos armazenados e um ambiente T-SQL padrão completo. O Synapse reúne as melhores tecnologias SQL, incluindo indexação colunar.\n✅ Relatórios e BI de Autoatendimento: Para relatórios e BI de autoatendimento, o Synapse lidera. O Synapse permite que você use diretamente o Power BI a partir do Synapse Studio. Seu pool SQL (SQL DWH) é amplamente reconhecido no data warehousing empresarial.\nAo compreender as diferenças entre o Azure Synapse e o Databricks, você pode tomar decisões informadas sobre qual plataforma atende às suas necessidades específicas. Escolha a ferramenta certa para suas análises de dados e desbloqueie todo o potencial de seus dados! ✨💼\n","permalink":"https://julianamarialop.github.io/articles/principais-diferencas-entre-o-azure-synapse-e-databricks/","summary":"Olá pessoal, nesse artigo vou comentar um pouco sobre essas plataformas de dados.","title":"🚀 Principais Diferenças Entre o Azure Synapse e o Databricks"},{"content":"Não seria um sonho tem uma coluna na sua tabela Bronze (ou Landing como quiser chamar) que informe de qual arquivo o dado foi originado ?\nConfira a seguir como fazer isso:\nAbaixo temos um conjunto de arquivos JSON para carga.\nVamos realizar a leitura dos arquivos para um dataframe\nAgora, salvando o dataframe em Tabela Delta\nAgora vem minha pergunta, como saber de qual arquivo cada pessoa veio?\nO segredo está na função input_file_name(), essa função pode ser utilizada tanto com SQL ou com Python, ela retorna o nome do arquivo lido, no exemplo abaixo estou usando a função no select da minha tabela Bronze no formato Delta.\nPorém, se utilizarmos essa função após a criação da tabela o que será exibido são os arquivos parquet e não os arquivos de origem em si.\nPara resolver esse problema, vamos adicionar a coluna \u0026ldquo;nomeArquivo\u0026rdquo; na criação da Tabela Delta.\nAgora sim !!\nPor hoje é isso pessoal, espero que tenha agregado.\nAté a próxima.\n","permalink":"https://julianamarialop.github.io/articles/dica-de-databricks-como-verificar-origem-do-dado-por-arquivo/","summary":"Não seria um sonho tem uma coluna na sua tabela Bronze (ou Landing como quiser chamar) que informe de qual arquivo o dado foi originado ?","title":"Dica de Databricks: Como verificar a origem do dado por arquivo - input_file_name()"},{"content":"Em maio de 2023, a Microsoft anunciou o Microsoft Fabric. Essa nova solução amplia a promessa de integração feita no Azure Synapse Analytics para abranger todas as cargas de trabalho analíticas, podendo ser utilizada por engenheiros de dados até profissionais de negócios especializados em conhecimento. O Microsoft Fabric combina Power BI, Data Factory e Data Lake em uma nova geração da infraestrutura de dados Synapse. Disponibilizado como uma oferta SaaS unificada, seu objetivo é reduzir custos e tempo de implementação, ao mesmo tempo em que habilita recursos avançados de ciência de dados.\nMas, e agora? Como ficam as empresas que investiram na plataforma Azure ? O Microsoft Fabric é o sucessor natural do Synapse. No entanto, as organizações que assumiram um compromisso significativo com o Azure Synapse Analytics podem ficar desapontadas ao descobrir que não há um caminho de atualização automática para suas cargas de trabalho.\nDependendo da carga de trabalho, diferentes graus de esforço serão necessários para adaptá-los para execução no Microsoft Fabric. Para algumas organizações, os custos associados a esse esforço de migração (e os riscos inerentes a qualquer migração) podem atuar como uma barreira.\nEsse artigo tem por objetivo ajudar as pessoas que estão familiarizadas com o Azure Synapse Analytics a entender o Fabric e explanar o custo/benefício de uma futura migração. Iremos descrever como os recursos da Synapse são equivalentes no Fabric, destacando as principais diferenças ao longo do caminho.\nPara as empresas que optarem por uma migração, alguns fatores importantes deveram ser considerados, por exemplo, cargas de trabalho baseadas em Spark oferecem um caminho de migração mais direto do que aquelas baseadas em SQL. No entanto, existem lacunas significativas em que os recursos do Synapse não são transferidos para o Fabric (mais adiante desse artigo iremos detalhar). Essa complexidade torna a decisão mais desafiadora. Minha recomendação é que as organizações invistam em um \u0026ldquo;pico técnico\u0026rdquo; para avaliar como o Fabric pode suportar suas cargas de trabalho Synapse mais comuns, a fim de obter informações valiosas sobre os desafios de migração e as oportunidades de longo prazo oferecidas pela plataforma.\nQuais as principais lacunas para uma migração ? A lista a seguir fornece um mapeamento para cada recurso do Azure Synapse versus Fabric com as principais questões a serem resolvidas:\nSQL Serverless (Synapse) versus SQL Endpoint (Fabric) : Sintaxe OPENROWSET não suportada, isso significa que o SQL não pode ser usado para consultar arquivos no Data Lake. No entanto, os dados estruturados colocados na área “Tabelas” do OneLake permitirão que esses dados sejam consultados via SQL no “Default Warehouse”, portanto, isso fornece funcionalidade semelhante ao OPENROWSET. Apache Spark Pools (Synapse) versus Managed Spark Pools (Fabric) : O Fabric é SaaS, portanto, não há necessidade de criar e gerenciar pools Spark. Será possível escolher qual versão do ambiente Spark você deseja usar e carregar pacotes específicos do Python em seu ambiente, incluindo a opção de fazer isso dinamicamente dentro de um notebook. As melhorias de desempenho significam que o ambiente Spark subjacente “gira” em segundos, em vez de minutos. Finalmente temos um concorrente digno para o Databricks. Notebooks Spark (Synapse) versus Notebooks (Fabric) : Uma série de novos recursos foram adicionados como capacidade de adicionar comentários aos notebooks e coedição – vários usuários podem abrir e editar um Notebook simultaneamente assim como Data Wrangler – novos utilitários estão disponíveis em Notebooks para permitir que os dados sejam explorados. Synapse Studio versus Power BI Interfaces: A experiência do usuário agora é organizada em torno de personas específicas “Data Engineering”, “Data Science”, “Data Warehousing” e “Real-time Analytics”, então você ainda tem Power BI e Data Factory como ferramentas independentes. Pipelines: Algumas ações de pipeline foram removidas no Fabric. Por exemplo, a integração com recursos de Machine Learning agora é via notebooks. Vamos falar sobre melhorias.. Olhando para o ecossistema Microsoft mais amplo, o Fabric oferece integração \u0026ldquo;pronta para uso\u0026rdquo; com funcionalidades que, de outra forma, exigiriam a criação e configuração de recursos adicionais do Azure para integração com o Synapse, por exemplo:\nAzure Machine Learning - não há necessidade de criar uma instância do Azure Machine Learning para registrar seus modelos de aprendizado de máquina e registrar experimentos, o Fabric fornece um ponto de extremidade MLFlow por padrão. Power BI- embora houvesse integração entre o Synapse e o Power BI, isso é bastante aprimorado com o Fabric. Conjuntos de dados podem ser criados com facilidade diretamente no OneLake, modelos e medidas podem ser criados a partir do Fabric UX. Além disso, um conjunto de dados padrão é criado em qualquer Lakehouse no Fabric, simplificando ainda mais o processo. Por fim, a maneira como os conjuntos de dados são apresentados no Fabric não apenas como uma entrada para o Power BI, mas como um \u0026ldquo;produto de dados\u0026rdquo; que pode ser consumido por muitos outros meios parece um grande passo à frente. Modelo comercial e custos O Microsoft Fabric adota um modelo comercial diferente do Azure Synapse Analytics. Para organizações pequenas (com cargas de trabalho menores e começando em sua jornada de dados) o modelo \u0026ldquo;pagamento por consulta\u0026rdquo; do SQL Serverless e a natureza \u0026ldquo;pagamento por minuto\u0026rdquo; dos Spark Pools são diferenciais com relação a outros fornecedores cloud.\nNo Fabric abandona em grande parte a abordagem \u0026ldquo;pague pelo que usar\u0026rdquo;. Adota uma abordagem baseada na capacidade. Isso forçará as organizações a se comprometerem com um gasto mínimo mensal na plataforma. Embora existam níveis mais baixos disponíveis que permitirão que organizações com cargas de trabalho menores adotem o Fabric, a principal preocupação é que isso pode resultar em um impacto nos custos da Azure.\nConclusões As organizações que atualmente usam o Azure Synapse Analytics devem avaliar o Microsoft Fabric e determinar como ele se encaixa em seu roteiro de tecnologia. Os principais fatores a serem considerados incluem:\nImpacto em custos - como a mudança de PaaS (Synapse) para SaaS (Fabric) afeta o custo? Por exemplo, é possível economizar eliminando a necessidade de gerenciar os recursos do Azure? Prós e contras do SaaS - como uma plataforma SaaS, o Fabric adota uma abordagem opinativa para implantar, configurar e implementar tecnologias sobre as quais você tem mais controle com a natureza PaaS do Synapse (e os recursos mais amplos do Azure que geralmente o acompanham). Bloqueio do fornecedor - mudar para o Fabric torna mais difícil mudar para um fornecedor diferente no futuro? Este é um problema significativo em sua empresa? Tempo para valorizar - a experiência do desenvolvedor e os recursos de produtividade no Fabric (por exemplo, a nova experiência de notebooks) abrem oportunidades para simplificar o ciclo de vida de desenvolvimento de ponta a ponta? Minimizando a dívida técnica - o Fabric simplificará sua base de código e, portanto, reduzirá o esforço de manutenção? Por exemplo, conectividade direta do Power BI para tabelas Delta no OneLake significa que uma camada SQL (e os scripts associados para criar as exibições SQL) não precisa mais ser mantida. Custos da Azure - Fabric adota um modelo de cobrança diferente do Synapse, como isso afetará seu Azure OpEx mensal? Novos recursos - olhando além da migração \u0026ldquo;like for like\u0026rdquo; da funcionalidade existente, quais oportunidades os novos recursos do Fabric oferecem, eles desbloqueiam casos de uso que estão em sua lista de pendências? Estratégia - como o Fabric se encaixa em sua estratégia de análise e dados de longo prazo? Se você acredita que há oportunidades, como próximo passo, recomendo que você faça um pequeno investimento direcionado em um \u0026ldquo;pico técnico\u0026rdquo; para avaliar o quão bem o Fabric pode suportar sua visão de dados e análises.\nReferências\nhttps://azure.microsoft.com/en-us/blog/introducing-microsoft-fabric-data-analytics-for-the-era-of-ai/\n","permalink":"https://julianamarialop.github.io/articles/azure-synapse-analytics-vs-microsoft-fabric-que-tal-mais/","summary":"Em maio de 2023, a Microsoft anunciou o Microsoft Fabric . Essa nova solução amplia a promessa de integração feita no Azure Synapse Analytics para abranger todas as cargas de trabalho analíticas, podendo ser utilizada…","title":"Azure Synapse Analytics vs Microsoft Fabric: Que tal mais um projeto de migração ?"},{"content":"Este artigo descreve algumas técnicas especiais para otimizar consultas SQL O tempo passa, novas técnicas, linguagens e ferramentas de ingestão de dados surgem, mas é uma verdade universal. SQL nunca sai de moda !\nNeste guia, incluí várias sugestões para otimizar instruções SQL. Espero que seja útil para todos.\nVamos lá !\n1. Tente não usar SELECT * para consultar o SQL, mas selecione campos específicos. Exemplo negativo:\nSELECT * FROM funcionário; Exemplo positivo:\nSELECT id,nome FROM funcionário; Justificativa:\nUsando apenas os campos obrigatórios, podemos economizar nossos recursos e reduzir a sobrecarga da rede. Com * nenhum índice da tabela é utilizado 2. Se você sabe que existe apenas um resultado da consulta, é recomendável usar o LIMIT 1 Suponha que exista uma tabela de funcionários e você queira encontrar uma pessoa chamada Maria.\nCREATE TABLE employee ( id int (11) NOT NULL, nome varchar (50) DEFAULT NULL, idade int (2) DEFAULT NULL, data datetime DEFAULT NULL, sex int (1) DEFAULT NULL, PRIMARY KEY (id)); Exemplo negativo:\nSELECT id,nome FROM funcionário WHERE LOWER(name) = \u0026#39;Maria\u0026#39;; Exemplo positivo:\nSELECT id,nome FROM funcionário WHERE LOWER(name) = \u0026#39;Maria\u0026#39; LIMIT 1; SELECT TOP 1 id,nome FROM funcionário WHERE LOWER(name) = \u0026#39;Maria\u0026#39;; Justificativa :\nApós adicionar o LIMIT 1, quando um registro correspondente for encontrado, ele não continuará a varredura e a eficiência será bastante aprimorada. 3. Tente evitar o uso da condição OR para unir condições Crie uma nova tabela de usuário com índice na coluna idx_userId\nCREATE TABLE user ( id int (11) NOT NULL AUTO_INCREMENT, userId int (11) NOT NULL, age int (11) NOT NULL, name varchar (255) NOT NULL, PRIMARY KEY (id), KEY idx_userId (userId)) Suponha que agora você precise consultar usuários com userid1 ou 18 anos de idade, é fácil ter o seguinte SQL.\nExemplo negativo:\nSELECT * FROM usuário WHERE userid = 1 OR age = 18; Exemplo positivo:\n// Use union all SELECT * FROM usuário WHERE userid = 1 UNION ALL SELECT * FROM usuário WHERE idade = 18; // Ou escreva dois SQL separados SELECT * FROM usuário WHERE userid = 1; SELECT * FROM usuário WHERE idade = 18; Justificativa :\nO uso de OR pode invalidar o índice e, portanto, requer uma verificação completa da tabela. 4. Otimize sua declaração like No desenvolvimento diário, se você usar consultas de palavras-chave difusas, é fácil pensar em LIKE como alternativa, mas provavelmente invalidará seu índice.\nExemplo negativo:\nSELECT userId,nome FROM usuário WHERE userId LIKE \u0026#39;%123\u0026#39;; Exemplo positivo:\nSELECT userId,nome FROM usuário WHERE userId LIKE \u0026#39;123%\u0026#39;; Justificativa :\nQuando o % é utilizado no inicio a consulta irá varrer a tabela toda, quando utilizado no final a busca acontece somente nos valores iniciados em 1. 5. Você deve evitar usar o operador ! = ou \u0026lt;\u0026gt; na cláusula WHERE, tanto quanto possível, caso contrário, o mecanismo deixará de usar o índice e executará uma verificação completa da tabela Exemplo negativo:\nSELECT idade,nome FROM usuário WHERE idade \u0026lt;\u0026gt; 18; Exemplo positivo:\n// Você pode considerar duas gravações sql separadas ou UNION ALL SELECT idade, nome do usuário WHERE idade \u0026lt; 18; SELECT idade, nome do usuário WHERE idade \u0026gt; 18; Motivo : o uso de ! = ou \u0026lt;\u0026gt; provavelmente invalidará o índice\n6. Use a palavra-chave DISTINCT com cuidado A palavra-chave DISTINCT geralmente é usada para filtrar registros duplicados para retornar registros exclusivos. Quando usado no caso de consultar um campo ou alguns campos, traz efeito de otimização para a consulta.\nNo entanto, quando existem muitos campos, isso reduz bastante a eficiência da consulta.\nExemplo negativo:\nSELECT DISTINCT * FROM usuário; Exemplo positivo:\nSELECT DISTINCT nome FROM usuário; Justificativa :\no tempo da CPU e o tempo de ocupação da instrução com distintos são maiores que a instrução sem distintos. Porque, ao consultar muitos campos, se você usar distintos, o mecanismo de banco de dados comparará os dados e filtrará os dados duplicados. No entanto, esse processo de comparação e filtragem consumirá recursos do sistema e tempo de CPU. 7. Remova índices redundantes e duplicados Exemplo negativo:\nKEY idx_userId (userId) KEY idx_userId_age (userId,age) Exemplo positivo:\n// Exclua o índice userId, porque o índice combinado (A, B) é equivalente à criação dos índices (A) e (A, B) KEY idx_userId_age (userId,age) Justificativa :\nÍndices duplicados precisam ser mantidos, e o otimizador também precisa considerá-los um por um ao otimizar consultas, o que afetará o desempenho. 8. Se a quantidade de dados for grande, otimize seu DELETE Evite modificar ou excluir muitos dados ao mesmo tempo, porque isso causará alta utilização da CPU, o que afetará o acesso de outras pessoas ao banco de dados.\nExemplo negativo:\n// Excluir 100.000 ou mais 1 milhão de cada vez DELETE FROM usuário WHERE id \u0026lt; 100000; Exemplo positivo:\n// Excluir em lotes DELETE FROM usuário WHERE \u0026lt; 500; DELETE FROM produto WHERE id \u0026gt; = 500 AND id \u0026lt; 1000 ； Justificativa :\npara excluir muitos dados ao mesmo tempo, pode haver um erro de tempo limite de espera de bloqueio excedido, portanto, é recomendável operar em lotes. 9. Considere usar valores padrão em vez de NULL na cláusula where Exemplo positivo:\nSELECT * FROM usuário WHERE idade IS NOT NULL; Exemplo positivo:\nSELECT * FROM usuário WHERE idade \u0026gt; 0; // Defina 0 como padrão Justificativa:\nSe você substituir o valor nulo pelo valor padrão, geralmente torna possível a indexação e, ao mesmo tempo, a expressão será relativamente clara. 10. Tente substituir UNION por UNION ALL Se não houver registros duplicados nos resultados da pesquisa , é recomendável substituir a união pela união de todos.\nExemplo negativo:\nSELECT * FROM usuário WHERE userid = 1 UNION SELECT * FROM usuário WHERE idade = 10 Exemplo positivo:\nSELECT * FROM usuário WHERE userid = 1 UNION ALL SELECT * FROM usuário WHERE idade = 10 Justificativa :\nSe você usar UNION, independentemente de os resultados da pesquisa serem repetidos, ele tentará mesclar e classificá-los antes de produzir os resultados finais. Se os resultados da pesquisa não tiverem registros duplicados, use UNION ALL em vez da união, o que aumentará a eficiência. 11. Use os campos numéricos o máximo possível. Se os campos contiverem apenas informações numéricas, tente não projetá-los como VARCHAR. Exemplo negativo:\nking_id varchar(20）NOT NULL; Exemplo positivo:\nking_id int(20）NOT NULL; Justificativa :\nem comparação com os campos numéricos, os tipos de caracteres reduzirão o desempenho da consulta e da conexão e aumentarão a sobrecarga de armazenamento. 12. Use em VARCHAR/NVARCHAR vez de CHAR/NCHAR sempre que possível Exemplo negativo:\ndeptName char(100) DEFAULT NULL Exemplo positivo:\ndeptName varchar(100) DEFAULT NULL Justificativa :\nPrimeiro, como o espaço de armazenamento do campo de tamanho variável é pequeno, portanto, o espaço de armazenamento pode ser salvo. Em segundo lugar, para consultas, a pesquisa em um campo relativamente pequeno é mais eficiente. Bônus: Use o EXPLAIN para analisar seu plano SQL Ao escrever SQL no desenvolvimento diário, tente desenvolver um hábito. Use o EXPLAIN para analisar o SQL que você escreveu, especialmente o índice.\nEXPLAIN SELECT * FROM user WHERE userid = 10086 AND age =18; Sim, chegamos ao fim. Espero que você goste e tenha uma ideia sobre como otimizar e acelerar suas consultas SQL.\nNão deixe de conferir os outros artigos que escrevi ! Aqui no final da página encontram-se os links..\nObrigada e até a próxima !\n","permalink":"https://julianamarialop.github.io/articles/como-otimizar-consultas-sql-um-guia-de-bolso-para-tuning/","summary":"O tempo passa, novas técnicas, linguagens e ferramentas de ingestão de dados surgem, mas é uma verdade universal. SQL nunca sai de moda !","title":"Como otimizar consultas SQL: Um guia de bolso para \"tuning\"​ de dados"},{"content":"Essa semana (Junho/2020) saiu uma atualização do GCP onde é possível utilizar o comando EXECUTE IMMEDIATE no BigQuery. Para mais informações veja a documentação.\nDigamos que queremos encontrar o número de casos confirmados de COVID nos últimos três dias em várias províncias canadenses. Há um conjunto de dados público do BigQuery que podemos consultá-lo da seguinte forma:\nSELECT * FROM `bigquery-public-data`.covid19_jhu_csse.confirmed_cases WHERE country_region LIKE \u0026#39;Canada\u0026#39; Nós temos:\nHá uma coluna para todas as datas. Como encontramos os últimos três dias para os quais existem dados? Perceba o formato \u0026ldquo;_1_22_20, _1_23_20,\u0026hellip;.\u0026rdquo;\nBuscando Colunas Podemos usar a função INFORMATION_SCHEMA para obter a lista de colunas e localizar os últimos três dias usando:\nSELECT column_name, parse_date(\u0026#39;_%m_%d_%y\u0026#39;, column_name) AS date FROM `bigquery-public-data`.covid19_jhu_csse.INFORMATION_SCHEMA.COLUMNS WHERE table_name = \u0026#39;confirmed_cases\u0026#39; AND STARTS_WITH(column_name, \u0026#39;_\u0026#39;) ORDER BY date DESC LIMIT 3 Retornando\nCriando uma instrução SQL dinâmica Você pode executar uma instrução SQL dinâmica usando EXECUTE IMMEDIATE. Por exemplo, suponha que tenhamos uma variável com o nome da coluna _5_18_20, é assim que usá-la para executar uma instrução SELECT:\nDECLARE col_0 STRING; SET col_0 = \u0026#39;_5_18_20\u0026#39;; EXECUTE IMMEDIATE format(\u0026#34;\u0026#34;\u0026#34; SELECT country_region, province_state, %s AS cases_day0 FROM `bigquery-public-data`.covid19_jhu_csse.confirmed_cases WHERE country_region LIKE \u0026#39;Canada\u0026#39; ORDER BY cases_day0 DESC \u0026#34;\u0026#34;\u0026#34;, col_0); Observe a consulta acima. Primeiro de tudo, porque estou declarando uma variável etc., este é um script do BigQuery em que cada instrução termina com um ponto e vírgula.\nEstou usando a função de formato de string do BigQuery para criar a instrução que quero executar. Como estou passando uma string, especifique% s na string de formato e passo em col_0.\nO resultado consiste em duas etapas:\ncom o resultado da segunda etapa sendo:\nScript nos últimos 3 dias Podemos combinar as três ideias acima - INFORMATION_SCHEMA, script e EXECUTE IMMEDIATE para obter os dados dos últimos três dias.\nDECLARE columns ARRAY\u0026lt;STRUCT\u0026lt;column_name STRING, date DATE\u0026gt;\u0026gt;; SET columns = ( WITH all_date_columns AS ( SELECT column_name, parse_date(\u0026#39;_%m_%d_%y\u0026#39;, column_name) AS date FROM `bigquery-public-data`.covid19_jhu_csse.INFORMATION_SCHEMA.COLUMNS WHERE table_name = \u0026#39;confirmed_cases\u0026#39; AND STARTS_WITH(column_name, \u0026#39;_\u0026#39;) ) SELECT ARRAY_AGG(STRUCT(column_name, date) ORDER BY date DESC LIMIT 3) AS columns FROM all_date_columns ); EXECUTE IMMEDIATE format(\u0026#34;\u0026#34;\u0026#34; SELECT country_region, province_state, %s AS cases_day0, \u0026#39;%t\u0026#39; AS date_day0, %s AS cases_day1, \u0026#39;%t\u0026#39; AS date_day1, %s AS cases_day2, \u0026#39;%t\u0026#39; AS date_day2 FROM `bigquery-public-data`.covid19_jhu_csse.confirmed_cases WHERE country_region LIKE \u0026#39;Canada\u0026#39; ORDER BY cases_day0 DESC \u0026#34;\u0026#34;\u0026#34;, columns[OFFSET(0)].column_name, columns[OFFSET(0)].date, columns[OFFSET(1)].column_name, columns[OFFSET(1)].date, columns[OFFSET(2)].column_name, columns[OFFSET(2)].date ); Os passos:\nDeclarar colunas como uma variável de matriz que armazenará o nome e a data da coluna nos três dias mais recentes Defina as colunas como o resultado da consulta para obter 3 dias. Observe que estou fazendo um ARRAY_AGG para obter o conjunto de resultados completo armazenado em uma variável. Formate a consulta. Observe que estou usando % t para representar um registro de data e hora (consulte a documentação do formato String para obter detalhes) e passando seis parâmetros. O resultado fica:\nUsando o EXECUTE IMMEDIATE Em vez de usar o formato String, você pode executar variáveis nomeadas da seguinte maneira:\nEXECUTE IMMEDIATE \u0026#34;\u0026#34;\u0026#34; SELECT country_region, province_state, _5_18_20 AS cases FROM `bigquery-public-data`.covid19_jhu_csse.confirmed_cases WHERE country_region LIKE @country ORDER BY cases DESC LIMIT 3 \u0026#34;\u0026#34;\u0026#34; USING \u0026#39;Canada\u0026#39; AS country; Você também pode executar variáveis posicionais usando pontos de interrogação:\nEXECUTE IMMEDIATE \u0026#34;\u0026#34;\u0026#34; SELECT country_region, province_state, _5_18_20 AS cases FROM `bigquery-public-data`.covid19_jhu_csse.confirmed_cases WHERE country_region LIKE ? ORDER BY cases DESC LIMIT ? \u0026#34;\u0026#34;\u0026#34; USING \u0026#39;Canada\u0026#39;, 3; A cláusula USING é complicada em algumas situações. Por exemplo, o seguinte não funciona:\nEXECUTE IMMEDIATE \u0026#34;\u0026#34;\u0026#34; SELECT country_region, province_state, ? AS cases FROM `bigquery-public-data`.covid19_jhu_csse.confirmed_cases WHERE country_region LIKE ? ORDER BY cases DESC LIMIT ? \u0026#34;\u0026#34;\u0026#34; USING \u0026#39;_5_18_20\u0026#39;, \u0026#39;Canada\u0026#39;, 3; -- ISSO NÃO FUNCIONA !!! Isso ocorre porque o primeiro parâmetro é interpretado como:\n\u0026#39;_5_18_20\u0026#39; AS cases Portanto, você não pode passar o nome de uma coluna através de USING. Por isso, recomendo usar a String FORMAT () para criar a consulta a ser executada imediatamente, porque não possui esses problemas.\nLogo mais o recurso PIVOT() está disponível !!!\nObrigada e até mais !\n","permalink":"https://julianamarialop.github.io/articles/como-usar-o-sql-dinamico-bigquery-utilizando-execute-immediate/","summary":"Essa semana (Junho/2020) saiu uma atualização do GCP onde é possível utilizar o comando EXECUTE IMMEDIATE no BigQuery. Para mais informações veja a documentação .","title":"Como usar o SQL dinâmico no BigQuery utilizando EXECUTE IMMEDIATE"},{"content":"Na semana passada, escrevi um artigo sobre pipeline de dados (confira aqui) onde foram apresentadas as principais características para um desenvolvimento robusto e de forma otimizada, preferencialmente utilizando um ambiente Big Data.\nDando continuidade ao tema, vamos abordar os principais componentes para construção de um ambiente de alta escalabilidade.\nA figura a seguir mostra uma arquitetura usando tecnologias de código aberto para materializar todos os estágios do pipeline de big data. Os estágios de preparação e computação são frequentemente mesclados para otimizar os custos de computação.\nOs principais componentes da arquitetura e tecnologia de big data são os seguintes:\nPontos de extremidade HTTP / MQTT para ingestão de dados e também para veiculação dos resultados. Existem várias estruturas e tecnologias para isso. Fila de publicação / sub-mensagem para a ingestão de dados de streaming de alto volume. Kafka é atualmente a escolha mais comum no ambiente On Premise. Armazenamento de dados de alto volume e baixo custo para data lake (e data warehouse), Hadoop HDFS ou armazenamento de blob em nuvem como o AWS S3 ou Azure Blob. Infraestrutura de consulta e catálogo de dados para converter um data lake em um data warehouse, o Apache Hive é uma opção popular de linguagem de consulta. Mecanismo de computação em lote de redução de mapa para processamento de alto rendimento, por exemplo Hadoop MapReduce e Apache Spark. Streaming de dados, por exemplo Apache Storm, Apache Flink. O Apache Beam também surgiu como a opção para fluxo de dados. Estruturas de aprendizado de máquina para ciência de dados e ML. O Scikit-Learn, o TensorFlow e o PyTorch são uma opção popular para implementar e treinar modelos. As opções de orquestração de implantação são Hadoop YARN, Kubernetes / Kubeflow. Arquitetura de Big Data em Cloud Com o advento da computação por serviço, é possível iniciar seu ambiente mais rapidamente e aproveitar melhor seu dinheiro. Vários componentes na arquitetura podem ser substituídos por seus serviços equivalentes do provedor de serviços em nuvem.\nArquiteturas típicas de pipelines de big data no Amazon Web Services, Microsoft Azure e Google Cloud Platform (GCP) são mostradas abaixo. Cada um mapeia de perto a arquitetura geral de big data discutida na seção anterior. Você pode usá-los como referência para tecnologias de lista de opções adequadas às suas necessidades.\nAmbiente Big Data AWS Ambiente Big Data Azure Ambiente Big Data Google Conclusão Nesse artigo foram apresentados os principais componentes para implantação de um ambiente Big Data. Basicamente com duas maneiras principais de \u0026ldquo;infraestrutura\u0026rdquo;, on premise e cloud, inicia-se com a adoção de serviços de armazenamento, processamento e fila.\nA escolha que melhor ambiente depende de alguns pilares a ser analisados como custo, complexidade do serviço ou tecnologia e ser implantada e infraestrutura já existente na empresa.\nObrigada e até a próxima.\n","permalink":"https://julianamarialop.github.io/articles/arquitetura-big-data-escolha-canalizacao-correta-para/","summary":"Na semana passada, escrevi um artigo sobre pipeline de dados (confira aqui) onde foram apresentadas as principais características para um desenvolvimento robusto e de forma otimizada, preferencialmente utilizando um…","title":"Arquitetura Big Data​: Escolha a canalização correta para seus pipelines"},{"content":"Introdução - O que são pipeline de dados ? Pipeline é um termo inglês que se pode traduzir por “tubagem” ou “canalização”. Esse conceito é utilizado na nossa língua para fazer referência a uma arquitetura da informática. Estas canalizações virtuais são criadas para segmentar os dados e, deste modo, incrementar o rendimento de um sistema digital.\nUm pipeline de fluxo de dados é uma série de componentes, ou blocos de fluxo de dados, e cada uma série executa uma tarefa específica que contribui para um objetivo maior.\nSua composição de recursos reúne a operação de ponta a ponta que consiste em coletar os dados, transformá-los, treinar um modelo, fornecer insights, aplicar o modelo quando e onde a ação precisar ser realizada para atingir a meta de negócios.\nPipelines de dados escaláveis e eficientes são tão importantes para o sucesso da análise, ciência de dados e aprendizado de máquina quanto as estratégias de linhas de frente de um exército são para vencer uma guerra.\nAproximadamente 50% do esforço da concepção dessa orquestra concentra-se na preparação dos dados para análise e Machine Learning. O esforço restante de 25% é utilizado para fazer insights e inferências do modelo facilmente consumíveis em escala e 25% para treinamento.\nUm pipeline de big data reúne tudo. É a ferrovia na qual correm vagões pesados e rápidos. O sucesso a longo prazo depende da construção e implantação correta dos serviços.\nPerspectivas - Visão por Área Existem três partes interessadas envolvidas na construção de aplicativos de análise de dados ou aprendizado de máquina: cientistas de dados, engenheiros e gerentes de negócios.\nDa perspectiva da ciência de dados, o objetivo é encontrar o modelo mais robusto e computacionalmente mais barato para um determinado problema usando os dados disponíveis.\nDo ponto de vista da engenharia, o objetivo é construir coisas das quais os outros possam confiar; inovar criando coisas novas ou encontrando maneiras melhores de criar coisas existentes que funcionam 24x7 sem muita intervenção humana.\nJá para atender a perspectiva dos negócios, o objetivo é agregar valor aos clientes; ciência e engenharia são meios para esse fim.\nAprofundando a ótica da perspectiva de engenharia podemos citar como características principais os seguintes pilares para obtenção de sucesso:\nAcessibilidade: dados facilmente acessíveis aos cientistas de dados para avaliação de hipóteses e experimentação de modelos, de preferência por meio de uma linguagem de consulta. Escalabilidade: a capacidade de escalar conforme aumenta a quantidade de dados ingeridos, mantendo o custo baixo. Eficiência: os resultados dos dados e do aprendizado de máquina estão prontos dentro da latência especificada para atender aos objetivos de negócios. Monitoramento: alertas automáticos sobre a integridade dos dados e do pipeline, necessários para uma resposta proativa aos riscos potenciais dos negócios. Etapas de Construção Um pipeline de dados possui cinco estágios agrupados em três fases na sua construção:\nFase I - Engenharia de dados: coleta, ingestão, preparação (~ 50% de esforço) Fase II - Analytics / Machine Learning: computação (~ 25% de esforço) Fase III - Entrega: apresentação (~ 25% de esforço) Coleta: As fontes de dados (aplicativos móveis, sites, aplicativos Web, microserviços, dispositivos IoT etc.) são instrumentadas para coletar dados relevantes.\nIngestão: As fontes instrumentadas bombearam os dados em vários pontos de entrada (HTTP, MQTT, fila de mensagens etc.). Também pode haver trabalhos para importar dados de serviços como o Google Analytics. Os dados podem estar em duas formas: blobs e fluxos. Todos esses dados são coletados em um Data Lake.\nPreparação: É a operação de extração, transformação, carregamento (ETL) para limpar, conformar, moldar, transformar e catalogar os blobs e fluxos de dados no data lake; preparando os dados para o ML e armazenando-os em um Data Warehouse.\nComputação: é aqui que acontecem análises, ciência de dados e aprendizado de máquina. A computação pode ser uma combinação de processamento em lote e fluxo. Modelos e insights (dados estruturados e fluxos) são armazenados de volta no Data Warehouse.\nApresentação: as informações são fornecidas por meio de painéis, emails, SMSs, notificações push. As inferências do modelo ML são expostas como microserviços.\nConclusão Como você viu, o pipeline de dados é como uma “orquestra” que executa as tarefas definidas de forma sequencial ou paralela dentro de um determinado período de tempo.\nQuanto mais alinhado o seu pipeline estiver com as expectativas dos cientistas de dados e gerentes de negócio, mais fácil será a obtenção de insights com resultados positivos à empresa.\nTambém é necessário que o desenvolvimento dos pipelines sejam pensados e concebidos de forma otimizada, preferencialmente utilizando um ambiente Big Data robusto.\nAgora pense, na sua empresa os processos de orquestração e cargas de dados estão robustos e rápidos o suficiente para atender a demanda do seu negócio ?\nObrigada e até a próxima !\n","permalink":"https://julianamarialop.github.io/articles/pipeline-de-dados-o-encanamento-na-sua-empresa-e-agua/","summary":"Pipeline é um termo inglês que se pode traduzir por “tubagem” ou “canalização”. Esse conceito é utilizado na nossa língua para fazer referência a uma arquitetura da informática. Estas canalizações virtuais são criadas…","title":"Pipeline de Dados - O encanamento na sua empresa é de água ou de esgoto ?"},{"content":"Há alguns anos empresas de todo o mundo já se utilizam do imenso valor que o Big Data pode agregar aos seus negócios. A implementação de ecossistemas Big Data é uma realidade no mercado mundial e brasileiro. Com cada vez mais demanda, tornou-se muito comum encontrar diversas vagas para Engenheiros de dados, Arquitetos e Analistas de Dados na timeline do Linkedin.\nComo tantas demandas surgindo, vários profissionais estão buscando conhecimento e atualizações. Com tantos cursos, ferramentas e ecossistemas diferentes por onde começar ?\nHá duas maneiras de usar o Big Data: estabelecê-lo nas instalações da sua empresa (On Premise) ou usar um provedor que ofereça uma plataforma de Big Data na nuvem (Cloud). No passado, as empresas só tinham a opção de instalá-lo localmente, mas esse não é mais o caso.\nA adoção das plataformas em nuvem caiu no gosto de pequenas e médias empresas principalmente pela facilidade de aquisição de assinaturas e start dos serviços de processamento. Atualmente a Microsoft com o ecossistema Azure tem a maior fatia do mercado brasileiro, em seguida a Amazon. Claro que aqui estou apenas dividindo minha opinião pessoal com base na minha experiência, deixo aqui um fonte para embasamento https://cio.com.br/azure-passa-aws-como-infraestrutura-de-nuvem-favorita-dos-cios/\nMas afinal por onde começo a estudar ? Big Data On Premise ou Cloud ?\nAqui vai a minha resposta: Comece a estudar com base no direcionamento que você quer dar na sua carreira ! Já explico\u0026hellip;\nVocê é um profissional de TI que tem por objetivo trabalhar em uma grande empresa como por exemplo as Telecoms, Bancos do modelo tradicional, Governo e outras, quer atuar em um modelo de contratação fixo como funcionário e já vem de uma carreira de Business Intelligence e Analytics comece por On Premise. Inicie por conceitos de Hadoop e Spark. Tem um material maravilhoso que o Fábio Jardim compilou no GitHub. https://github.com/fabiogjardim/bigdata_docker\nAgora se seus objetivos são diferentes, que atuar no mercado como consultor independente e quer acompanhar as tendencias dos grandes fornecedores recomendo iniciar criando uma conta na Azure (portal.azure.com) e estudando o conteúdo que a própria Microsoft disponibiliza por meio da plataforma Learn (https://docs.microsoft.com/pt-br/learn/?WT.mc_id=home_homepage-azureportal-learn)\nEspero ter contribuído ! Estou a disposição para questionamento dos colegas de profissão.\nUm Abraço !\n","permalink":"https://julianamarialop.github.io/articles/big-data-premise-vs-cloud-computing-uma-visao-de-mercado/","summary":"Há alguns anos empresas de todo o mundo já se utilizam do imenso valor que o Big Data pode agregar aos seus negócios. A implementação de ecossistemas Big Data é uma realidade no mercado mundial e brasileiro. Com cada…","title":"Big Data​: On Premise vs Cloud Computing - Uma visão de mercado e Guia inicial para Estudo"},{"content":"Imagine uma equipe formada por um desenvolvedor SQL, um profissional de Pyhton e um colaborador de Scala. Todos eles trabalham juntos em prol de realizar ingestões de dados no seu Datalake, Datawarehouse um simplesmente em um banco de Dados Relacional fazendo uso de clusters Spark. Não seria ótimo de todos trabalharem em uma plataforma unificada que entenda todas as linguagens de programação no mesmo script ou bloco ? Essa plataforma existe !\nO Databricks é uma plataforma de análise baseada no Apache Spark. Projetado com os fundadores do Apache Spark, com o Databricks temos fluxos de trabalho simplificados e um workspace interativo que permite a colaboração entre os cientistas de dados, os engenheiros de dados e os analistas de negócios.\nCom suporte para Python, Scala, R e SQL, além de bibliotecas e estruturas de aprendizado profundo como TensorFlow, Pytorch e Scikit-learn ao utilizarmos o Databricks eliminamos toda a dureza e complexidade para obter um cluster do Spark. Seus notebooks fornecem uma experiência ininterrupta e sem falhas de gerenciamento graças à integração com o principal provedor de nuvem, incluindo o Amazon AWS e o Microsoft Azure.\nNeste tutorial explicaremos as principais etapas para iniciar o Databricks no ambiente Azure. A primeira parte será relativa à configuração e inicialização do ambiente. A segunda parte serão as etapas colocaremos um notebook em funcionamento. A última parte lhe dará algumas consultas básicas para verificar se tudo está funcionando corretamente.\nComo criar seu primeiro cluster Crie uma assinatura no portal.azure.com. Em \u0026ldquo;Create a resource\u0026rdquo; busque pelo termo \u0026ldquo;Databricks\u0026rdquo;\nEm seguida, execute a \u0026ldquo;Workspace\u0026rdquo; criada.\nAgora você está no Espaço de Trabalho do Databricks\nO próximo passo é criar um cluster que irá executar o código fonte presente em seus notebooks.\nVocê pode ajustar o tamanho do cluster de acordo com o preço que deseja pagar. Observe que o cluster será desligado automaticamente após um período de inatividade.\nA criação do cluster pode levar vários minutos. Enquanto isso, podemos criar nosso primeiro notebook e anexá-lo a esse cluster.\nE agora? Python, Scala ou SQL ? Qual usar no meu notebook.. Esta é a principal questão que todo novo desenvolvedor questiona. Se você estiver familiarizado com o Python (Python é a linguagem preferida dos engenheiros de dados), pode se ater ao Python, já que pode fazer quase tudo como ele.\nNo entanto, o Scala é o idioma nativo do Spark. Como o próprio Spark é escrito no Scala, você encontrará 80% dos exemplos, bibliotecas e discussões no StackOverflow em Scala.\nA boa notícia é que você não precisa escolher no bloco de notas do Databricks, pois é possível misturar os dois idiomas para simplificar o desenvolvimento com o Python.\nA biblioteca Python para lidar com o Spark é denominada PySpark.\nCriando seu primeiro notebook.. Na página inicial da workspace, clique em \u0026ldquo;New Notebook\u0026rdquo;\nVocê também pode criar seu notebook em uma pasta específica\nSelecione a linguagem padrão para o seu notebook. No caso aqui do exemplo irei utilizar o Python\nApós o notebook criado, vamos anexar o cluster para executar o código.\nDigite algum código Python ou Scala. Para o Scala, você precisa adicionar o \u0026ldquo;%scala\u0026rdquo; na primeira linha, já que o idioma padrão que escolhemos é o Python:\nPara executar o código, você pode usar o atalho CTRL + ENTER ou SHIFT + ENTER. Se o cluster não estiver em execução, um prompt solicitará que você confirme sua inicialização. Agora estamos prontos para a próxima etapa: a ingestão de dados. No exemplo abaixo realizamos a busca do arquivo CSV e posteriormente a leitura com \u0026ldquo;spark.read.csv\u0026rdquo;\n%python # Use the Spark CSV datasource with options specifying: # - First line of file is a header # - Automatically infer the schema of the data data = spark.read.csv(\u0026#34;/databricks-datasets/samples/population-vs-price/data_geo.csv\u0026#34;, header=\u0026#34;true\u0026#34;, inferSchema=\u0026#34;true\u0026#34;) data.cache() # Cache data for faster reuse data ​= data.dropna() # drop rows with missing values Tá bom, entendi.. Mas eu sou Desenvolvedor SQL e não sei Python.. Não tem problema, podemos realizar a mesma tarefa com comandos SQL.. Vamos criar a tabela \u0026ldquo;data_geo\u0026rdquo;..\n%python # Register table so it is accessible via SQL Context data.createOrReplaceTempView(\u0026#34;data_geo\u0026#34;) E agora vamos a query\n%sql select `State Code`, `2015 median sales price` from data_geo Como podemos verificar, há diversas formas de desenvolvimento no Databricks e que torna uma plataforma muito interessante. Outra vantagem é com relação ao preço que é muito mais barato que as ferramentas tradicionais como o Integration Services na Nuvem por exemplo..\nNo próximo artigo, irei focar nas funções SQL do Databricks e no Databricks Delta.\nEspero ter contribuído com essa pequena explicação.. Obrigada !\n","permalink":"https://julianamarialop.github.io/articles/databricks-o-canivete-suico-da-sua-plataforma-big-data/","summary":"Imagine uma equipe formada por um desenvolvedor SQL, um profissional de Pyhton e um colaborador de Scala. Todos eles trabalham juntos em prol de realizar ingestões de dados no seu Datalake, Datawarehouse um simplesmente…","title":"Databricks: O canivete suiço da sua plataforma Big Data"},{"content":"Cada vez mais famoso e utilizado, o Apache Hive é um sistema de data warehouse para Hadoop. O Hive permite o resumo de dados, consultas e análise de dados. Consultas de hive são escritas em HiveQL, que é uma linguagem de consulta semelhante ao SQL. O Hive permite que você projete estrutura em grandes volumes de dados sem estrutura.\nDepois de definir a estrutura, você pode usar o HiveQL para consultar os dados sem conhecimento de Java ou do MapReduce.\nNesse artigo iremos abortar os principais comandos para utilizar o Hive. Confira:\nPrincipais Consultas Consultas de Objetos e Estruturas Para mais informações e a documentação completa acesse, https://cwiki.apache.org/confluence/display/Hive/LanguageManual\nEspero que essa publicação tenha contribuído para seu aprendizado, até a próxima !\n","permalink":"https://julianamarialop.github.io/articles/medo-de-abelhas-dicas-e-truques-para-apache-hive-juliana-maria/","summary":"Cada vez mais famoso e utilizado, o Apache Hive é um sistema de data warehouse para Hadoop . O Hive permite o resumo de dados, consultas e análise de dados. Consultas de hive são escritas em HiveQL , que é uma linguagem…","title":"Medo de Abelhas? Dicas e Truques para Apache Hive"},{"content":"Neste artigo, apresentarei as principais operações Hadoop para manipular o HDFS por meio de comandos shell. Para testar, você pode utilizar esses comandos usando algumas das VMs da Cloudera, Hortonworks, HDInsight, ou se você possui sua própria configuração de cluster.\n1 - Criar um diretório no HDFS hadoop fs -mkdir \u0026lt;pastas\u0026gt; Exemplo: hadoop fs -mkdir /home/user/diretorio_1 /home/user/diretorio_2 2 - Listar o conteúdo de um diretório hadoop fs -ls \u0026lt;pastas\u0026gt;  Examplo: hadoop fs -ls /home/user/diretorio_1 3 - Upload e download de um arquivo no HDFS Upload - Copie um único arquivo ou vários do sistema de arquivos local para o Hadoop\nhadoop fs -put \u0026lt;pasta de origem\u0026gt; ... \u0026lt;pasta de destino HDFS\u0026gt; Exemplo: hadoop fs -put /home/user/ArquivoExemplo.txt /user/HDFS/diretorio_1/ Download - Copie arquivos para os diretórios locais\nhadoop fs -get \u0026lt;pasta de Origem HDFS\u0026gt; \u0026lt;pasta de destino\u0026gt; Exemplo: hadoop fs -get /user/HDFS/diretorio_1/ArquivoExemplo.txt /home/ 4. Ver o conteúdo do Arquivo hadoop fs -cat \u0026lt;pastas e nome de arquivo\u0026gt; Exemplo: hadoop fs -cat /user/HDFS/diretorio_1/ArquivoExemplo.txt 5. Copiar arquivos entre diretórios do HDFS hadoop fs -cp \u0026lt;pasta de origem\u0026gt; \u0026lt;pasta de destino\u0026gt; Exemplo: hadoop fs -cp /user/HDFS/diretorio_1/ArquivoExemplo.txt /user/HDFS/dir_2 Este comando também permite a cópia de vários arquivos, para isso utilize somente a estrutura de pasta na referência da origem.\n6. Mover os arquivos hadoop fs -mv \u0026lt;pasta de origem\u0026gt; \u0026lt;pasta de destino\u0026gt; Exemplo: hadoop fs -mv /user/HDFS/diretorio_1/Arquivo.txt /user/HDFS/dir_2 7. Remover um Arquivo ou Diretório do HDFS hadoop fs -rm \u0026lt;pasta ou arquivo\u0026gt; Exemplo: hadoop fs -rm /user/HDFS/diretorio_1/ArquivoExemplo.txt 8. Exibir as Últimas Linhas do Arquivo hadoop fs -tail \u0026lt;nome de arquivo\u0026gt; Exemplo: hadoop fs -tail /user/HDFS/diretorio_1/ArquivoExemplo.txt Espero que essa publicação tenha contribuído para seu aprendizado e ajude no seu cotidiano de manipulação de arquivos.\nVeja também:\n","permalink":"https://julianamarialop.github.io/articles/domando-o-elefante-principais-comandos-hadoop-para-gerenciar/","summary":"Neste artigo, apresentarei as principais operações Hadoop para manipular o HDFS por meio de comandos shell. Para testar, você pode utilizar esses comandos usando algumas das VMs da Cloudera, Hortonworks, HDInsight, ou…","title":"Domando o Elefante - Principais Comandos Hadoop para gerenciar o HDFS"},{"content":"Ao longo dos anos, os data warehouses têm sido a principal ferramenta para a tomada de decisão e análise da empresas. Estes incluem ferramentas OLAP e ETL convencionais fornecidas por inúmeros fornecedores de hardware e software, aparelhos DW criados pela combinação de bases de dados e servidores, bancos de dados em memória e ferramentas de virtualização.\nMas como adequar e processar uma quantidade de dados cada vez maior em um velocidade aceitável para análise e busca de informações cruciais ao negócio ?\nNo Brasil, ainda estamos em uma fase muito embrionária com relação ao Big Data. Acredito que dentro em breve as empresas começaram seus projetos para \u0026ldquo;migração\u0026rdquo; das bases convencionais do DW para o HDFS.\nNa minha opinião, o profissional de BI de hoje que investir em aprendizado referente ao Hadoop, Spark e métodos de carga de Dados Rápidos estará um passo a frente no mercado de trabalho.\nO ecossistema Hadoop, que está se desenvolvendo junto com grandes ambientes de dados, também tem um conjunto de várias tecnologias para a construção de data warehouse. Por exemplo, o Apache Hive é uma opção de data warehouse com o ecossistema Hadoop que pode processar grandes conjuntos de dados salvos em ambientes de armazenamento distribuídos usando o SQL.\nMas, então, tem alguma receita de bolo ou fórmula mágica para Migrar os dados ? Infelizmente não, mas podemos seguir algumas diretrizes.\n1 - Desnormalizar A desnormalização é comumente usada para melhorar o desempenho ao implementar um modelo de Star Schema baseado em um sistema de arquivos distribuídos Hadoop (HDFS). Ao contrário do RDBMS, o Hadoop permite a sobreposição de dados causada pela desnormalização graças a equipamentos e softwares relativamente baratos.\nPortanto, a decisão de aplicar a desnormalização em conjuntos de dados que mudam frequentemente deve ser feita cuidadosamente, considerando a compensação entre o desempenho da pesquisa e a implantação. O seguinte é um exemplo do método de desnormalização que pode ser usado para construção de data warehouse baseado em Hadoop.\n1.1 - Integrar Dimensões Várias dimensões com um pequeno número de linhas são empacotadas e transformadas em um conjunto de dados de dimensão única para que o número de conjuntos de dados de fato e junções possa ser reduzido. É difícil otimizar o sistema com um grande número de associações entre conjuntos de dados de dimensão e conjuntos de dados de fato ao usar o Hadoop.\nUma pequena quantidade de arquivos grandes é melhor do que um grande número de arquivos pequenos para um desempenho ótimo com o Hadoop, uma grande dimensão é processada mais rapidamente do que várias dimensões pequenas.\n1.2 - Integrar Fatos com Dimensões Conjuntos de dados de dimensões e fato usados juntos para consultas são organizados em um conjunto único aplicando uma associação ao processo de implantação em vez de uma consulta no usuário.\nOs conjuntos de dados são unidos no ponto de carregamento de dados para reduzir o número de joins. É semelhante ao processo de integração de dimensão, exceto que a integração é de fato-dimensão.\n1.3 - Gerar Conjuntos de Dados Histórico e Atual juntos para Carga Como geralmente é mais rápido regenerar todo o conjunto de dados do que atualizar um único evento, considerando como o HDFS funciona, os conjuntos de dados necessários para o processo de carregamento são adicionados de acordo com as características temporários e de negócio.\nÉ melhor recarregar todo o conteúdo atual junto com o histórico ao invés de realizar várias atualizações.\n2 - Organizar as tabelas Fato de maneira \u0026ldquo;Colunar\u0026rdquo; Pode parecer estranho, mas é muito melhor ter centenas de colunas à milhões de linhas. Especialmente quando os usuários organizam um data warehouse que extrai e utiliza uma parte de uma coluna de um dataset, um formato colunar que permite extrair dados de coluna parcial ajuda a melhorar o desempenho de pesquisa muito.\nComo exemplo, podemos ter uma fato de Vendas organizada por \u0026ldquo;Mês/Ano\u0026rdquo; que expande suas colunas a cada novo período.\n3 - Comprimir os Dados Compressão ajuda a melhorar o desempenho do processamento, reduzindo não apenas o tamanho dos dados armazenados, mas também a quantidade de E/S do disco. É melhor usar um codec de compactação que permita o processamento divisível para que os nós possam ser processados em paralelo em um ambiente distribuído.\nSe a compactação for inviável, métodos adicionais de armazenamento de arquivos divisíveis, como Avro, são necessários. Como o armazenamento de arquivos, diferentes métodos de compressão podem ser usados para cada partição dentro de um conjunto de dados único.\n4 - Particionar os Dados Os conjuntos de dados são particionados de acordo com padrões de pesquisa de dados, de modo que os resultados podem ser encontrados sem pesquisar o conjunto de dados inteiro. Particionar ajuda a melhorar o desempenho, uma vez que reduz os objetos para verificação de consultas e reduz a E/S.\nUma vez que um conjunto de dados é dividido em partições de acordo com algum critério, tais como datas que refletem os padrões de pesquisa do usuário, apenas uma partição diária precisa ser digitalizada ao extrair dados de uma determinada data, tornando-a muito mais eficiente comparada a uma verificação completa em todo o conjunto de dados .\nO método de particionamento é semelhante ao da construção de um data warehouse baseado em RDBMS. Uma diferença é que, ao contrário do RDBMS que define como particionar um conjunto de dados, o Hadoop cria várias estratégias de particionamento de acordo com os padrões de pesquisa de um usuário.\nO Hadoop copia o dataset original e cria vários conjuntos de dados, e cada conjunto de dados é estrategicamente particionado. Em outras palavras, o Hadoop usa muito mais espaço em disco para copiar e multiplicar um conjunto de dados para melhorar o desempenho.\n5 - Bucketing Bucketing é um processo pelo qual um dataset é dividido em buckets, grupos de dados agrupados, usando valores de uma determinada coluna. Cada bloco pode ter vários valores de coluna como critérios, mas um valor aleatório entre os valores da coluna de critérios está incluído em apenas um único bloco.\nOutro benefício do bucketing é que ele torna os conjuntos de dados pequenos o suficiente para usar uma junção do lado do mapa, que faz o upload desse bloco para a memória para processamento rápido.\n6 - Indexar os Dados No Apache Hive, os índices que desempenham funções semelhantes aos índices RDBMS podem ser gerados. Hive suporta um índice compacto, bitmap índice, e assim por diante. É importante primeiro analisar os padrões de consulta do usuário para gerar índices que reflitam esses padrões (como na estratégia de indexação do RDBMS).\nAo usar um índice, os dados estatísticos devem ser coletados regularmente para ajudar o otimizador a encontrar a melhor rota.\nConclusão O valor fundamental de um data warehouse é o mesmo, mesmo que seja construído como uma aplicação dentro de um ecossistema Hadoop. Felizmente, a metodologia para construções de data warehouse pode ser usada sem muita alteração na construção de bases baseadas em Hadoop.\nEnquanto as características dos ecossistemas Hadoop forem refletidas em seu processo de modelagem física, o data warehouse será preparado para a era dos grandes dados, onde serão integrados os dados estruturados e não estruturados.\nReferências\nRalph Kimball and Matt Brandwein – Hadoop 101 for EDW Professionals Hadoop 101 for EDW Professionals – Dr. Ralph Kimball Answers Your Questions Ralph Kimball and Eli Collins – EDW 101 for Hadoop Professionals Ralph Kimball – Newly Emerging Best Practices for Big Data Ralph Kimball – The Evolving Role of the Enterprise Data Warehouse in the Era of Big Data Analytics Josh Wills - What Comes After The Star Schema? Veja também:\nBancos NoSQL, como assim não tem Query ?\nO que você precisa saber sobre Big Data e não passar vergonha no papo do Café ?\n","permalink":"https://julianamarialop.github.io/articles/dw-com-hadoop-como-modelar-seu-star-schema-para-o-hdfs/","summary":"Ao longo dos anos, os data warehouses têm sido a principal ferramenta para a tomada de decisão e análise da empresas. Estes incluem ferramentas OLAP e ETL convencionais fornecidas por inúmeros fornecedores de hardware e…","title":"DW com Hadoop? Como modelar seu Star Schema para o HDFS"},{"content":"Dando continuidade a série de artigos sobre Big Data, vamos falar um pouco sobre os bancos de dados não relacionais.\nParticularmente quando comecei a ouvir o termo \u0026ldquo;NoSQL\u0026rdquo; minha cabeça dava um nó. \u0026ldquo;Bancos NOSQL, como assim não tem query?\u0026rdquo;, \u0026ldquo;Como fazer pra armazenar os dados?\u0026rdquo;, \u0026ldquo;Como recuperar as informações ?\u0026rdquo;.\nPara começar nosso entendimento, vou voltar ao assunto do MapReduce abordado no artigo anterior. Como comentado, no Hadoop o método para verificar, por exemplo quantas vezes um determinado termo surgiu nas redes sociais, é utilizando o framework de Redução.\nNo momento em que um job é iniciado em um nó, os pares \u0026lt;key,value\u0026gt; são transferidos em partes aos nós de mapeamento. Uma nova instância de mapeamento é gerada para cada registro de entrada. Esses pares são coletados localmente no nó de mapeamento através de uma função em um nó de redução.\nEntão, como armazenar esses pares de Chave/Valor? Utilizando os Bancos NoSQL. Basicamente, a grande vantagem desse tipo de armazenamento é a flexibilidade como os dados estão estruturados. Veja abaixo que não temos mais tabelas, linhas e colunas.\nCerto, mas como fazer uma simples consulta nesse banco já que não dá pra ser via SQL ? É justamente nesse ponto que as linguagens de programação entram em cena. Python, Java, R e tantas outras nos auxiliam na busca e cruzamento desses dados.\nSim eu sei, essa imagem é bem assustadora e faz parecer que \u0026ldquo;Selects\u0026rdquo; são brincadeira de criança. Mas calma, já existem IDEs no mercado que ajudam a criar essas consultas.\nMas então como fica as nomenclaturas de Linhas, Tabelas e Colunas ? Veja abaixo.\nLembrando que os Bancos do tipo Chave/Valor são os mais simples da Categoria NoSQL, temos outros tipos baseado em Colunas, Documentos e Gráficos.\nBaseado em Coluna (Column Stores): Hbase, Cassandra, Hypertable, Accumulo, Amazon SimpleDB, Cloudata, Cloudera, SciDB, HPCC, Stratosphere;\nBaseado em Documentos (Document Stores): MongoDB, CouchDB, BigCouch, RavenDB, Clusterpoint Server, ThruDB, TerraStore, RaptorDB, JasDB, SisoDB, SDB, SchemaFreeDB, djondb;\nBaseado em Grafos (Graph-Based Stores): Neo4J, Infinite Graph, Sones, InfoGrid, HyperGraphDB, DEX, Trinity, AllegroGraph, BrightStarDB, BigData, Meronymy, OpenLink Virtuoso, VertexDB, FlockDB;\nBaseado em Chave-Valor (Key-Value Stores): Dynamo, Azure Table Storage, Couchbase Server, Riak, Redis, LevelDB, Chordless, GenieDB, Scalaris, Tokyo, Cabinet/Tyrant, GT.M, Scalien, Berkeley DB, Voldemort, Dynomite, KAI, MemcacheDB, Faircom C-Tree, HamsterDB, STSdb, Tarantool/Box, Maxtable, Pincaster, RaptorDB, TIBCO Active Spaces, allegro-C, nessDB, HyperDex, Mnesia, LightCloud, Hibari, BangDB.\nSe você não acompanhou o início dessa série de artigos e quer saber mais sobre o tema Big Data leia também O que você precisa saber sobre Big Data e não passar vergonha no papo do Café ?\nNo próximo post vou comentar sobre o Apache Spark.\nObrigada.\n","permalink":"https://julianamarialop.github.io/articles/bancos-nosql-como-assim-nao-tem-query-juliana-maria/","summary":"Dando continuidade a série de artigos sobre Big Data, vamos falar um pouco sobre os bancos de dados não relacionais.","title":"Bancos NoSQL, como assim não tem Query ?"},{"content":"Imagine a seguinte situação, um diretor da empresa que você trabalha começa a fazer as seguintes perguntas:\n\u0026ldquo;Quantas vezes o nome da minha empresa é citada no Twitter ?\u0026rdquo; ou \u0026ldquo;Quais são as maiores dúvidas ou reclamações dos consumidores em nossa página no Facebook ?\u0026rdquo;\nComo você, analista de TI faria para organizar esses dados originados das redes sociais e gerar um relatório ou dashboard que faça sentido à diretoria ?\nJustamente para responder essas questões as plataformas de Big Data são cada vez mais famosas e comentadas.\nMas, o que é Big Data ? Atualmente as siglas Hadoop, Hive, Spark, NoSQL e tantas outras estão na moda. Mas você realmente entende o que significa toda essa \u0026ldquo;sopa de letrinhas\u0026rdquo; ?\nEu também estou tentando entender o que significa todo esse ecossistema e nessa tentativa de organizar um pouco minhas ideias e estudos referente a esse assunto tão fascinante iniciarei uma série de artigos.\nO que afinal é esse monte de siglas que todo mundo está comentando e correndo atrás como se fosse o último poço de petróleo descoberto no planeta?\nComo quase sempre acontece, a criatividade surge diante de um problema a ser resolvido. O que fazer como essa imensidão de dados gerados a cada segundo por computadores e celulares ?\nFotos, Vídeos, Posts, como posso utilizar essas informações para entender mais o perfil do meu consumidor e ganhar mais dinheiro ? Como fazer para organizar, armazenar e cruzar essas diferentes formas de dados ?\nPensando nisso, mentes brilhantes começaram a desenvolver modelos de organização e armazenamento, os famosos Mapas de Redução e Banco de Dados NoSQL. O primeiro ecossistema a ganhar fama, que com certeza você já ouviu falar, foi o Hadoop.\nDesenvolvido em Java, o objetivo desse framework em linhas gerais é mapear as informações como se fosse um dicionário, contar quais são os similares, e armazenar de forma reduzida o dado em um Banco de Dados próprio para este fim (NoSQL). Para armazenar cada tipo de dados temos BDs diferentes. Vou detalhar mais este assunto no próximo artigo.\nPara simplificar, o Hadoop é o todo, o ecossistema. Ele tem um Mapa de Redução chamado YARN que armazena os dados nos bancos destinados para cada tipo de dado. Cassandra, Hive, HBase são eles.\nVocê deve estar se perguntando, \u0026ldquo;Imagina a máquina potente que precisa para rodar esse volume enorme ?\u0026rdquo; Então, para isso foi criado um sistema de arquivos, o HDFS, que fragmenta em nós e clusters. Ou seja, a quantidade de processamento e hardware pode ir aumentando ou reduzindo conforme a necessidade.\nO Hadoop já existe a mais de 10 anos e tem provado ser a melhor solução para o processamento de grandes conjuntos de dados. O MapReduce, é uma ótima solução para cálculos de único processamento, mas não muito eficiente para os casos de uso que requerem cálculos e algoritmos com várias execuções\nPara resolver esse outro problema de complexidade dos dados, o Spark entra em cena.\nEspero que essa publicação tenha contribuído para seu aprendizado e te ajude a juntar as peças do quebra-cabeça do momento.\nReferências:\nhttp://spark.apache.org/\nhttp://hadoop.apache.org/\n","permalink":"https://julianamarialop.github.io/articles/o-que-voce-precisa-saber-sobre-big-data-e-nao-passar-vergonha/","summary":"Imagine a seguinte situação, um diretor da empresa que você trabalha começa a fazer as seguintes perguntas:","title":"O que você precisa saber sobre Big Data e não passar vergonha no papo do Café ?"},{"content":"Quanto custa um agente de inteligência artificial? A estimativa mais comum multiplica o número de solicitações pelo preço de uma chamada ao modelo. Esse método subestima o custo, porque um agente não executa uma única chamada: ele executa várias iterações antes de responder, e cada iteração processa mais texto que a anterior.\nO custo de um agente é determinado pela sua arquitetura: quantas iterações ele executa, qual modelo cada etapa utiliza e quanto contexto é reprocessado a cada iteração. Esta página apresenta esse raciocínio em quatro etapas, com um único exemplo: o assistente de atendimento de uma loja online que responde à pergunta \u0026ldquo;Onde está o meu pedido?\u0026rdquo;. Cada etapa introduz um conceito, e os valores podem ser alterados para observar o efeito no custo.\n","permalink":"https://julianamarialop.github.io/custo-de-agentes/","summary":"Estimativa do custo de um agente de IA a partir da sua arquitetura, e não do volume de requisições, com os preços publicados pelos próprios fornecedores.","title":"Calculadora de custo de agentes"},{"content":"Executiva de tecnologia com mais de 20 anos de experiência liderando iniciativas de Inteligência Artificial, Dados e Analytics, com atuação estratégica na concepção de soluções, arquitetura corporativa e modernização de plataformas em grandes organizações como NET, Claro, Telefônica, C\u0026amp;A, Nestlé, UHG, Avon e Natura.\nAo longo da trajetória, consolidou experiência na construção de ecossistemas de dados, ambientes analíticos, Big Data, Data Warehouse e arquiteturas escaláveis em nuvem, conectando visão de negócio, inovação e excelência técnica. Nos últimos anos, ampliou sua atuação em Azure Cloud, Databricks e soluções orientadas por IA, apoiando empresas na adoção de plataformas modernas capazes de acelerar decisões, ampliar eficiência e criar vantagem competitiva.\nPossui forte histórico em liderança técnica, arquitetura de soluções e gestão de times de engenharia, atuando em consultorias e projetos de alta complexidade. Sua abordagem combina profundidade técnica com visão executiva, posicionando IA, Dados e Analytics como pilares centrais para transformação, automação, escalabilidade e geração de valor.\nTambém mantém atuação relevante na formação de profissionais e no fortalecimento do ecossistema de tecnologia, com experiência acadêmica na FIAP, condução de treinamentos especializados e participação ativa na comunidade Microsoft. É certificada em tecnologias estratégicas como Azure Data Engineer Associate e Azure Database Administrator Associate, além de ter sido reconhecida por 4 anos consecutivos como Microsoft Certified Trainer.\nAtua ainda como mentora de profissionais em desenvolvimento de carreira e mantém presença ativa no LinkedIn, onde compartilha visões sobre arquitetura, plataformas modernas, inteligência artificial e o futuro de Dados e Analytics nas organizações.\nInteresses: Artificial Intelligence · Data \u0026amp; Analytics · Executive Technology Leadership · Solution Architecture · Azure Cloud · Databricks · Microsoft Fabric · AI Agents · Data Engineering · Cloud Architecture\n","permalink":"https://julianamarialop.github.io/about/","summary":"Juliana Maria Lopes: executiva de tecnologia em IA, Dados e Analytics.","title":"Sobre"}]