Databricks

Olá, daqui fala o Alex da DEV STORIES DOT EU. Databricks, episódio 1 de 15. Durante anos, as empresas pagaram duas vezes para armazenar exatamente os mesmos dados, apenas para manter os seus engenheiros de machine learning e os seus business analysts satisfeitos. Armazenar dados brutos num sistema e copiá-los para outro cria dores de cabeça intermináveis de sincronização. O Databricks resolve isto introduzindo uma abordagem unificada chamada Data Lakehouse. Historicamente, as organizações dividiam a sua arquitetura de dados em dois caminhos separados. Primeiro, construíam Data Lakes. Estes são sistemas de cloud storage baratos e altamente escaláveis, perfeitos para despejar quantidades massivas de dados não estruturados. Os data scientists adoram-nos para treinar modelos de machine learning. Mas os Data Lakes são péssimos para queries SQL rápidas e fiáveis. Para resolver isso, as empresas introduziram Data Warehouses para as suas equipas de business intelligence. Isto cria uma enorme carga operacional. Pensa numa startup em crescimento como exemplo. Os seus data engineers despejam raw event logs num bucket de cloud storage. Eles correm os seus scripts de Python lá. Mas a equipa financeira precisa de dashboards. Por isso, os engenheiros têm de construir pipelines complexos para extrair esses dados, transformá-los e carregá-los num data warehouse separado. A empresa paga pelo storage duas vezes. Paga pelo compute necessário para mover os dados. E no momento em que os dados chegam ao warehouse, já estão desatualizados. O Databricks elimina este pipeline por completo com a arquitetura Data Lakehouse. Um Lakehouse combina o storage barato e flexível de um data lake com a fiabilidade e a performance de um data warehouse. Mantém os teus dados num formato único e aberto diretamente no teu cloud storage. Não os copias para uma base de dados proprietária. Em vez disso, o Databricks adiciona uma camada transacional diretamente por cima do teu data lake existente. Aqui está o ponto-chave. Os teus dados ficam num único local, mas diferentes profissionais interagem com eles exatamente da maneira que precisam. Os data scientists podem escrever Python ou Scala para treinar modelos diretamente nos ficheiros raw. Em simultâneo, os business analysts podem correr queries SQL de alta performance nesses mesmos dados para alimentar as suas ferramentas de reporting. As pessoas muitas vezes pensam erradamente que o Databricks é apenas mais uma base de dados SQL ou simplesmente um managed wrapper à volta do Apache Spark. Não é nada disso. É uma Data Intelligence Platform abrangente. Ao fundir o lake e o warehouse, também fundes a segurança e a governance. No modelo antigo, tinhas de gerir as permissões de acesso no cloud storage para os engenheiros e, separadamente, no data warehouse para os analistas. Com o Databricks, uma camada de governance unificada trata do access control em todas as tabelas, ficheiros e modelos de machine learning. Defines uma data access policy uma única vez, e ela aplica-se em todo o lado, independentemente da linguagem ou ferramenta usada para fazer a query. O verdadeiro poder da arquitetura Lakehouse não é apenas poupar dinheiro em pipelines de storage redundantes; é que os teus modelos de inteligência artificial e os teus dashboards financeiros estão finalmente a olhar para exatamente os mesmos números, exatamente ao mesmo tempo. Se quiseres ajudar a manter o podcast no ar, podes procurar por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Databricks, episódio 2 de 15. Se a tua empresa usa vários workspaces para processar dados, provavelmente tens vários locais onde geres as permissões de segurança. Essa fragmentação é um risco enorme de compliance, porque manter as policies sincronizadas entre ambientes desconectados depende inteiramente de updates manuais. O Unity Catalog elimina este risco ao mudar fundamentalmente a forma como a data governance funciona no Databricks. Antes de explicar a mecânica, precisamos de esclarecer um equívoco muito comum. O Unity Catalog não é um data dictionary passivo. Não é apenas uma lista de tabelas onde os utilizadores vão para ler descrições. É o policy engine central que aplica ativamente as regras de segurança em toda a tua arquitetura. O Unity Catalog resolve o problema persistente de saber exatamente quem tem acesso a quê. Fornece um modelo de segurança unificado baseado no standard ANSI SQL. Em vez de configurares cloud identity roles, permissões ao nível do workspace e access controls ao nível do cluster separadamente, usas comandos familiares como grant e revoke diretamente nos teus dados e assets de inteligência artificial. Como o Unity Catalog fica ao nível da conta, em vez de estar preso a um workspace individual, defines uma regra de segurança apenas uma vez. Essa regra é depois aplicada instantânea e universalmente em todos os workspaces associados a esse catalog. Imagina uma situação em que um auditor pede a um CTO para provar exatamente quem fez uma query a uma tabela específica com números de cartão de crédito na última terça-feira, e para identificar todos os reports downstream que usam atualmente esses números. Historicamente, responder a isto significava fazer o parsing de system logs desconexos em diferentes tools, ler manualmente transformation jobs agendados e esperar que nenhum step intermédio tivesse falhado. O Unity Catalog lida com isto nativamente através dos seus dois pilares seguintes: built-in auditing e automated lineage. Primeiro, captura audit logs detalhados ao nível do utilizador, out of the box. Sempre que um utilizador ou um service principal acede a dados, o catalog regista o evento. Aqui está o insight principal. O Unity Catalog não faz apenas o tracking de quem fez uma query a uma tabela; faz o tracking do que acontece aos dados a seguir através de automated lineage. À medida que os teus scheduled pipelines correm, o sistema lê continuamente os execution plans e constrói um mapa de como os dados fluem. Faz o tracking de quais source tables alimentam quais datasets intermédios, até chegar aos dashboards finais. Faz este tracking tanto ao nível da tabela como ao nível da coluna. Quando o auditor pergunta sobre os dados dos cartões de crédito, não precisas de adivinhar. Vês o lineage graph e instantaneamente percebes cada transformation step e cada access point. O último grande pilar é o secure data sharing. As organizações frequentemente precisam de partilhar datasets com vendors externos ou business units separadas. Em vez de exportares flat files ou duplicares dados para cloud storage buckets separados, o Unity Catalog integra um protocolo chamado Delta Sharing. Isto permite-te dar a terceiros governed access a live data sem a copiares. O external consumer lê os dados in place, e o seu acesso é registado e controlado exatamente pelo mesmo cérebro central. O verdadeiro valor do Unity Catalog é que elimina completamente o gap perigoso entre escrever uma security policy no papel e executá-la de facto em data silos isolados. É tudo por este episódio. Obrigado por ouvires, e keep building!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Databricks, episódio 3 de 15. A maneira mais fácil de gastares todo o teu orçamento de cloud é deixares um servidor enorme a correr em vazio durante todo o fim de semana. Tu queres poder de processamento exatamente quando precisas, e zero faturação quando não precisas. É exatamente isso que abordamos hoje em Navegar no Workspace e Compute. O teu ponto de entrada no Databricks é o workspace. Pensa no workspace como o ambiente unificado onde a tua equipa organiza todos os seus assets do Databricks. Fornece uma interface web para gerires os teus notebooks, data objects, experiências de machine learning e os recursos computacionais subjacentes. O workspace reúne todas as tuas ferramentas colaborativas numa vista organizada, garantindo que diferentes equipas possam interagir com os mesmos dados subjacentes sem se pisarem umas às outras. Por debaixo do capô, o Databricks depende de uma arquitetura desacoplada. Os teus dados vivem de forma persistente em cloud object storage, enquanto o poder de compute usado para processar esses dados é provisionado de forma completamente separada. Esta separation of concerns dita a tua faturação. Como o compute é isolado do storage, tu só provisionas e pagas por instâncias de servidor quando estás ativamente a correr código. Quando o trabalho termina, o compute desliga-se, mas os teus dados permanecem guardados com segurança e acessíveis. Para gerir este poder de processamento, o Databricks oferece diferentes tipos de recursos de compute adaptados a workflows específicos. O primeiro é um All-Purpose cluster. Usas isto para trabalho interativo e ad-hoc. Imagina que um data analyst precisa de um ambiente altamente capaz para fazer uma query a mil milhões de linhas numa tarde de terça-feira. Ele levanta um All-Purpose cluster, faz attach do seu notebook e começa a explorar. Para evitar surpresas na faturação ao fim de semana, estes clusters dependem de auto-termination. Se o analista for para casa às cinco e deixar o notebook aberto, o cluster monitoriza-se por inatividade e desliga-se automaticamente após um limite de tempo especificado. Aqui está o insight principal em relação à automação. Um erro frequente que as equipas cometem é agendar pipelines de produção automatizados para correrem nestes All-Purpose clusters interativos. Evita fazer isto. Os All-Purpose clusters têm um custo de utilização mais elevado, e correr vários workflows diferentes num cluster interativo partilhado pode introduzir conflitos de libraries ou resource contention. Em vez disso, os pipelines de produção devem usar Job clusters. Um Job cluster é totalmente efémero. Quando um pipeline automatizado é acionado, o job scheduler do Databricks provisiona um Job cluster dedicado estritamente para esse workload. Ele corre o código, e no exato segundo em que o job termina, o cluster encerra-se. Isto garante um isolamento de recursos rigoroso para o teu pipeline e assegura que pagas a taxa de compute mais baixa possível para tarefas automatizadas. Por fim, se o teu workload for puramente analítico, podes usar um SQL warehouse. Este é um recurso de compute otimizado especificamente para correr comandos SQL e queries de dashboards. Se usares Serverless SQL warehouses, o Databricks gere o compute subjacente automaticamente. Ele faz scale up instantaneamente quando ocorre um pico de queries, e faz scale down quando a queue fica vazia, removendo completamente a necessidade de configurares a infraestrutura tu mesmo. Adequar o tipo de compute certo à natureza exata da tua tarefa é a maneira mais eficaz de garantires que a tua infraestrutura de cloud permanece poderosa durante as horas de ponta e altamente eficiente em termos de custos quando o trabalho está concluído. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. Databricks, episódio 4 de 15. Tu constróis um data lake, mas em poucos meses ninguém sabe onde estão os dados de produção, quem é o dono, ou se é realmente seguro fazer uma query a uma tabela específica. A diferença entre um data lake impecável e um pântano de dados incontrolável está exatamente a três níveis de profundidade. Hoje vamos olhar para a Organização dos Teus Dados: O Object Model. O Unity Catalog traz ordem aos teus dados através de uma hierarquia estrita e previsível. O container de topo absoluto é o metastore, que guarda os metadados da tua organização. Mas as tuas interações diárias dependem do namespace principal de três níveis. Cada query que escreves aponta para um asset usando o formato catalog ponto schema ponto object. O primeiro nível é o catalog. Este fornece uma fronteira ampla para os data assets. Normalmente, usas catalogs para separar ambientes logicamente, como ter um catalog para produção e outro completamente separado para desenvolvimento. O segundo nível é o schema, que também é referido como database. Os schemas vivem dentro dos catalogs e organizam datasets relacionados. Podes criar um schema para eventos raw ingeridos e outro para analytics refinados. O terceiro nível é o object em si. Esta é a tua tabela, uma view, ou um volume que contém ficheiros não tabulares. Ao impor esta convenção de nomenclatura de três partes, o Unity Catalog dá a cada pedaço de dados um endereço claro e inequívoco. Quando um analista faz uma query a production ponto sales ponto customers, a localização, a fase do lifecycle, e o propósito desses dados ficam instantaneamente óbvios. Aqui está a ideia principal. Assim que chegas ao nível da tabela, tens de perceber como o Unity Catalog interage com o teu storage real. Existem dois tipos principais de tabelas: managed tables e external tables. As managed tables são o default. Quando crias uma managed table, o Unity Catalog é dono tanto dos metadados como dos dados subjacentes. Ele trata do layout dos ficheiros e gere todo o lifecycle dos dados. Os ficheiros reais são guardados numa storage location designada que tu configuras ao nível do metastore, catalog, ou schema. As external tables funcionam de maneira diferente. Usas uma external table quando já tens ficheiros num bucket de cloud storage e queres deixá-los exatamente onde estão. Com uma external table, o Unity Catalog regista a estrutura e governa o acesso, mas é dono apenas dos metadados. Tu manténs o controlo total sobre os ficheiros físicos. Esta distinção torna-se crucial durante operações destrutivas. Considera um cenário onde um data engineer executa acidentalmente um comando drop table. Se ele fizer drop a uma managed table, o Unity Catalog remove a tabela do metastore e apaga automaticamente os ficheiros subjacentes do teu cloud storage. Os dados são destruídos. Se ele fizer drop a uma external table, o Unity Catalog simplesmente remove o link dos metadados. A tabela desaparece da interface do teu workspace, mas os ficheiros raw no teu cloud storage permanecem perfeitamente intactos e intocados. Usa sempre managed tables quando quiseres que o catalog otimize e governe todo o storage lifecycle, e reserva as external tables para dados que precisas de proteger contra eliminação acidental ou partilhar diretamente com outros sistemas externos. Obrigado por estares aí. Espero que tenhas aprendido algo novo.

Olá, daqui fala o Alex da DEV STORIES DOT EU. Databricks, episódio 5 de 15. Podes facilmente restringir quem vê uma coluna numa base de dados relacional, mas como é que garantes o controlo de acesso num bucket de cloud storage cheio de milhares de PDFs raw? A resposta é: Domar Dados Não Estruturados com Volumes. Antes de entrarmos em detalhe sobre como funcionam, vamos esclarecer uma confusão comum. Os volumes servem estritamente para acesso a ficheiros baseado em paths. Não servem para dados tabulares. Se estiveres a fazer queries a linhas e colunas com SQL, usas uma tabela. Se estiveres a ler imagens, documentos de texto ou ficheiros de áudio, usas um volume. Um volume é um objecto dentro do Unity Catalog. Representa um espaço de storage lógico no teu ambiente cloud. Ao criares um volume, colocas os dados não estruturados debaixo do mesmo guarda-chuva de segurança que as tuas tabelas estruturadas. Em vez de gerires identity policies na AWS ou role assignments no Azure apenas para ler um ficheiro, controlas o acesso usando permissões standard diretamente no Databricks. Imagina um hospital a treinar um modelo de machine learning para detetar anomalias em imagens de raio-X. Não podem colocar milhares de imagens de alta resolução numa tabela de uma base de dados. Precisam de as guardar como ficheiros raw em cloud object storage. Como se trata de ficheiros de pacientes altamente sensíveis, uma governance rigorosa é fundamental. Ao colocar os raios-X dentro de um volume do Databricks, a equipa de engenharia consegue controlar exatamente quais os data scientists que têm permissão para ler aquele diretório específico. Existem dois tipos de volumes: managed e external. Um managed volume é totalmente gerido pelo Databricks. Quando crias um, não especificas um storage path. O Databricks simplesmente reserva espaço no storage location default atribuído ao teu schema atual. Fazes o upload de ficheiros diretamente para lá. Se alguma vez fizeres drop a um managed volume, o Databricks apaga também os ficheiros subjacentes. Isto torna-os ideais para ficheiros temporários de workspace ou dados gerados inteiramente dentro das tuas pipelines do Databricks. Um external volume aponta para um diretório de cloud storage existente que já te pertence. Primeiro, registas um cloud storage path como uma external location no Unity Catalog. A seguir, crias um volume por cima. Isto dá-te uma governance rigorosa sobre dados produzidos por outros sistemas. Se uma aplicação separada escrever log files num bucket do Azure Data Lake, um external volume permite que os utilizadores do Databricks leiam esses ficheiros com segurança. Se fizeres drop a um external volume, a metadata é removida, mas os ficheiros subjacentes no teu cloud bucket ficam completamente intactos. Esta abordagem baseada em paths é exatamente o que a IA moderna exige. As libraries open-source de machine learning normalmente esperam ler dados de um file system local. Não sabem como autenticar com interfaces proprietárias de cloud storage. Os volumes resolvem isto ao expor um directory path que se parece e comporta como uma pasta local standard. O teu script de treino de modelo simplesmente abre um file path. O Unity Catalog interceta esse request e verifica as permissões do utilizador de forma transparente. Aqui está o ponto-chave. Os volumes eliminam a desconexão entre como governas as tuas bases de dados estruturadas e como proteges os teus ficheiros raw, permitindo-te correr workloads de machine learning em dados não estruturados sem contornar a segurança enterprise. É tudo por este episódio. Obrigado por ouvires, e keep building!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Databricks, episódio 6 de 15. Se os teus data engineers ainda estão a colar access keys da cloud diretamente nos scripts, a tua empresa está a um erro de distância de um data breach massivo. A solução para ligares de forma segura o teu workspace ao teu cloud storage sem expores secrets é o Bulletproof Cloud Security: External Locations. Quando um utilizador faz login no Databricks, usa um identity token. Esse token prova quem ele é perante o workspace. Mas essa identidade não significa absolutamente nada para o teu cloud provider subjacente, seja a AWS, o Azure ou a Google Cloud. Para ler um ficheiro de um cloud bucket, o próprio workspace precisa de se autenticar na infraestrutura cloud. Historicamente, os developers contornavam esta desconexão ao fazerem hardcode de IAM keys da cloud diretamente nos seus notebooks ou environment variables. Isto cria uma vulnerabilidade de segurança grave, pois qualquer pessoa com read access ao código pode roubar as keys. O Unity Catalog resolve isto através de uma abstração rigorosa em duas partes. A primeira parte é a Storage Credential. Uma Storage Credential representa um mecanismo de autenticação e autorização diretamente ligado ao teu cloud provider. Ela mapeia para uma IAM role na AWS, uma Managed Identity no Azure, ou uma Service Account na Google Cloud. Em vez de entregar raw cloud keys a um developer, o teu cloud admin concede privilégios de acesso a esta Storage Credential. O Unity Catalog detém a autoridade para assumir esta role, mantendo a credential em si completamente fora do alcance dos utilizadores do workspace. Agora, uma Storage Credential por si só é demasiado abrangente. Essa IAM role pode ter permissão para aceder a dezenas de buckets diferentes em todo o teu cloud environment. É aqui que entra a segunda parte. Uma External Location associa uma Storage Credential a um cloud storage path específico, como um URI de um S3 bucket ou um container path do Azure Data Lake Storage. Define exatamente onde essa credential tem permissão para operar. Podes pensar nisto como uma fronteira geográfica para as tuas cloud credentials. Imagina um cenário concreto. Um developer precisa de analisar system logs armazenados num S3 bucket altamente seguro. Num setup legacy, um admin geraria access keys da AWS e enviava-as ao developer, na esperança de que ele não fizesse commit acidentalmente dessas keys para um code repository público. Com o Unity Catalog, o workflow muda completamente. O admin cria uma Storage Credential configurada com uma IAM role que consegue ler o target bucket. A seguir, o admin cria uma External Location a apontar estritamente para o S3 path que contém os system logs, e faz attach dessa Storage Credential à mesma. Finalmente, utilizando SQL standard, o admin concede ao developer permissão para ler ficheiros exclusivamente nessa External Location. Quando o developer corre uma query nos logs, o Unity Catalog entra em ação e lida de forma transparente com a cloud authentication em seu nome. O developer nunca vê uma key da AWS. Não gere secrets nem configura cloud profiles. Apenas faz query ao path permitido. Mais tarde, podes criar external tables ou external volumes diretamente sobre esta location para organizar ainda mais os dados. Se o developer for para outra equipa, o admin simplesmente revoga o seu grant à External Location dentro do Databricks. A configuração subjacente de cloud IAM permanece completamente intacta. Aqui está o ponto-chave. As External Locations fazem decouple da segurança da tua cloud infrastructure da tua governance diária de data access. Ao manter as IAM roles fora do user code e ao ancorá-las a paths explícitos, garantes que cada data request é auditado, seguro e restrito exclusivamente aos dados que pretendes partilhar. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui fala o Alex da DEV STORIES DOT EU. Databricks, episódio 7 de 15. Os engenheiros de dados passam uma quantidade inacreditável de tempo apenas a tentar evitar que scripts frágeis de ingestão de APIs falhem. Quando um endpoint altera a sua lógica de paginação ou um rate limit desce, o teu pipeline falha, e passas a tarde a fazer debugging de JSON em vez de construíres modelos de dados. A solução para esta dor de cabeça específica é o Lakeflow Connect. Antes de vermos como funciona, vamos esclarecer uma confusão comum de nomenclatura. O Databricks tem o Lakeflow Jobs e o Lakeflow Connect. O Lakeflow Jobs trata da orchestration, ou seja, corre tasks numa sequência específica. O Lakeflow Connect é estritamente sobre ingestão. É o mecanismo para trazer raw data de sistemas externos para o teu ambiente Databricks. Na sua essência, o Lakeflow Connect fornece Managed Connectors. Estas são integrações nativas, criadas especificamente para aplicações enterprise e bases de dados. Normalmente, quando precisas de extrair dados de sistemas externos, escreves código Python custom. Esse código tem de gerir a autenticação, lidar com retries quando o servidor vai abaixo, fazer o tracking de que records já foram ingeridos, e fazer o parse de paginação complexa. Os Managed Connectors eliminam toda essa camada de infraestrutura custom. O Databricks trata do compute subjacente, das interações com a API e do state tracking necessário para leituras incrementais. Como o Lakeflow Connect corre em serverless compute, não precisas de configurar ou gerir clusters apenas para extrair dados. O serviço escala automaticamente com base no volume de dados recebidos. Também se integra diretamente com o Unity Catalog, o que significa que os dados que ingeres são imediatamente governados e ficam disponíveis para querying. Considera um requisito standard. A tua equipa de marketing precisa de dados atualizados do Salesforce no teu lakehouse. Se construíres isto do zero, podes passar uma semana a escrever um script custom que faz queries à API do Salesforce. Tens de escrever lógica para te manteres abaixo dos limites rígidos da API, gerir token refreshes, e fazer merge de updates nas tuas tabelas Delta existentes sem duplicar records. Com um Managed Connector no Lakeflow Connect, evitas completamente o código custom. Forneces as credenciais de ligação, selecionas os objects específicos do Salesforce de que queres fazer tracking, e defines um catalog e um schema de destino. O setup demora alguns minutos. O Databricks assume a execução. Extrai o snapshot histórico inicial dos teus dados e, em seguida, passa a capturar continuamente as alterações incrementais à medida que acontecem. Aqui está o insight principal. Ao transferir o workload de ingestão para um Managed Connector, deixas de manter polling scripts. Quando uma especificação de API externa muda, o Databricks atualiza o connector nos bastidores. O teu pipeline simplesmente continua a correr. Isto liberta-te para te focares na verdadeira business logic, como transformar raw data em tabelas agregadas ou treinar modelos de machine learning, em vez de andares a tomar conta de um script de extração que falhou. O verdadeiro valor do Lakeflow Connect não está apenas no setup rápido, mas na remoção permanente de código de ingestão custom do teu backlog de manutenção. Se quiseres ajudar a manter o podcast a andar, podes procurar por DevStoriesEU no Patreon e apoiar-nos por lá. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui fala o Alex da DEV STORIES DOT EU. Databricks, episódio 8 de 15. Tens um pipeline ETL complexo em que uma tabela é atualizada a cada hora, outra é atualizada continuamente, e a orquestração das dependências requer centenas de linhas de código de state-management. E se pudesses simplesmente declarar as tabelas finais que queres, e deixar o engine construir a infraestrutura para as manter atualizadas? Essa é a premissa do Automated ETL usando Declarative Pipelines. Num pipeline imperativo tradicional, dizes ao sistema exatamente como executar a sua tarefa. Escreves o código para gerir checkpoints, lidar com retries, mapear dependências e provisionar clusters. Os pipelines declarativos invertem este modelo. Simplesmente defines como a tabela final deve ficar, geralmente com uma query SQL standard ou uma função Python. O engine subjacente constrói o graph de execução, gere a infraestrutura e lida com as transições de state automaticamente. Para que isto funcione, o Databricks utiliza dois tipos de tabela específicos. Um erro comum é tratá-las como intercambiáveis. Não são. Deves separar claramente os teus dados de eventos append-only das tuas agregações complexas. O primeiro tipo é a Streaming Table. As Streaming Tables são concebidas estritamente para processamento incremental e append-only. Leem continuamente ou em batches de uma data source, processam apenas os novos registos e fazem append ao destino. Imagina processar uma stream massiva de cliques num site vindos do Kafka. Escreves uma query para popular uma Streaming Table a partir desse topic do Kafka. Não escreves código para monitorizar offsets ou lembrar que mensagens já foram lidas. O pipeline mantém o state internamente, garantindo que cada clique é processado exatamente uma vez, mesmo que o sistema seja reiniciado. Agora, a segunda parte disto. Depois de armazenares os teus raw events com segurança, geralmente precisas de os transformar. É aqui que entram as Materialized Views. Enquanto as Streaming Tables lidam com o ingest inicial de novos dados, as Materialized Views são criadas para agregações complexas, joins e registos que são atualizados ou apagados ao longo do tempo. Voltando aos cliques do nosso site, precisas de um dashboard executivo diário que mostre o total de cliques agrupados por região. Defines uma Materialized View que faz um select da tua Streaming Table e executa a agregação. Quando o pipeline corre, o engine avalia a Materialized View. Ele determina a forma mais eficiente de atualizar a view. Se puder computar as alterações de forma incremental, vai fazê-lo. Se for necessário um recompute completo, ele lida com isso automaticamente. Nunca escreves a lógica que dita quando fazer refresh ou como fazer merge das novas agregações. Aqui está o ponto chave. Como defines tanto as Streaming Tables como as Materialized Views de forma declarativa, o engine do Databricks entende toda a lineage dos teus dados. Ele sabe que a Materialized View depende da Streaming Table. Ele encadeia-as num graph de pipeline unificado. Se um compute node falhar a meio do processamento, o pipeline baseia-se nesse graph para pausar, fazer retry e retomar sem duplicar registos ou corromper o dashboard final. A tua codebase já não está cheia de scaffolding operacional. Contém apenas a business logic pura que define como os dados fluem da source para o destino. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex da DEV STORIES DOT EU. Databricks, episódio 9 de 15. Se o teu processamento de dados noturno depende de uma chain de agendamentos cron independentes, estás basicamente a torcer para que o step anterior tenha terminado a tempo. Estás a voar às cegas. Para evitar silent failures e garantir a ordem de execução, precisas de Master Orchestration com Lakeflow Jobs. Primeiro, uma breve distinção. Os Lakeflow Pipelines lidam com dependências de dados ao nível da tabela. Os Lakeflow Jobs, nos quais nos estamos a focar agora, orquestram tasks a um nível macro. Pensa nos pipelines a mover dados dentro do data warehouse, enquanto os jobs encadeiam notebooks, scripts Python e modelos de machine learning num workflow maior. Um job no Databricks é o container principal para a tua orquestração. Dentro desse container, defines várias tasks. Uma task é uma unidade de trabalho isolada. Pode ser executar um notebook de Databricks, submeter uma Spark application, correr um projeto dbt ou disparar uma query SQL. Ao interligar estas tasks, constróis um graph de execução onde uma task só começa quando os seus pré-requisitos específicos são concluídos com sucesso. Vamos analisar um cenário prático para ver como o control flow lida com a fiabilidade. Tens um processo diário que ingere raw data, verifica a sua qualidade, transforma-a e alerta a equipa caso algo corra mal. Começas por definir uma task de ingestão. A seguir, ligas uma task de data quality que corre estritamente após a conclusão da ingestão. Aqui está a ideia principal. Em vez de escreveres error handling customizado no teu código Python para decidir o que acontece a seguir, usas o control flow nativo do job. Adicionas uma task de condição if-else imediatamente após o quality check. A condição avalia uma variável devolvida pela tua task de data check. Se os dados estiverem limpos, o job segue o if-branch e faz trigger à tua task de transformação downstream. Se os dados estiverem corrompidos, o job segue o else-branch e faz trigger a uma task de webhook que faz ping a um canal de Slack. Também geres o state usando condições de task run-if. Podes configurar uma task de alerting para executar apenas se a task anterior tiver falhado completamente, enquanto o resto do pipeline para em segurança. Isto evita a clássica cascata de silent failures, onde um step de ingestão que falhou faz trigger silenciosamente a um modelo de machine learning para treinar em tabelas completamente vazias. Para iniciar este workflow, aplicas um trigger. Os jobs podem correr on demand, num intervalo agendado tradicional, ou continuamente. Também podem executar com base num evento, como a chegada de um novo ficheiro a um bucket de cloud storage externo. Uma vez feito o trigger, o Databricks fornece observabilidade built-in. Não tens de adivinhar onde ocorreu a falha. A plataforma regista um run history completo com uma matrix view, mostrando-te exatamente qual task teve sucesso, qual task estagnou e quanto tempo cada step demorou. Podes configurar notificações ao nível do job ou ao nível da task para enviar emails automatizados ou webhooks no momento em que o execution state muda. O verdadeiro valor deste modelo de orquestração é transferir o failure handling dos teus scripts individuais para a infraestrutura da plataforma, garantindo que o teu sistema sabe exatamente como fazer o routing da execução quando as coisas inevitavelmente falharem. É tudo por agora. Obrigado por ouvirem, e continuem a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Databricks, episódio 10 de 15. Mover dados do teu data lake apenas para que a tua equipa de business intelligence possa correr queries é lento, caro e completamente desnecessário. Acabas por manter pipelines frágeis só para copiar dados de um sistema para outro, introduzindo atrasos e duplicando custos de storage. É exatamente este o problema que o Databricks SQL resolve. Existe a ideia errada de que o Databricks é estritamente para data engineers e data scientists que escrevem em Python ou Scala. O Databricks SQL desfaz esse mito. É um workspace dedicado, construído inteiramente para profissionais de SQL. Imagina uma equipa de business intelligence a migrar de um data warehouse legacy. Historicamente, eles esperavam que os engenheiros corressem jobs de extração noturnos para carregar os dados do data lake para o warehouse. Só depois disso é que podiam começar a criar reports. O Databricks SQL elimina toda essa camada de extração. Permite que os analistas corram queries ANSI-SQL standard diretamente no data lake. Tens a escala massiva do storage open lake, mas interages com ele usando a interface familiar e rápida de um warehouse relacional tradicional. O engine que alimenta estas queries é o Serverless SQL Warehouse. Um SQL warehouse é simplesmente um recurso de compute configurado especificamente para workloads SQL. Em arquiteturas mais antigas, tinhas de provisionar clusters manualmente, configurar regras de scaling e esperar vários minutos para que as virtual machines fizessem boot antes de correr uma query. Aqui está o ponto chave. Como estes SQL warehouses são serverless, a camada de compute arranca quase instantaneamente. Faz scale out automaticamente quando os teus analistas disparam workloads concorrentes pesados, e desliga-se quando as queries terminam. A gestão da infraestrutura é completamente abstraída, deixando os analistas focarem-se exclusivamente nos seus dados. Para escrever e executar estas queries, a plataforma fornece um editor SQL built-in. Esta é a interface principal para explorar os dados. Dentro do editor, os utilizadores podem escrever standard SQL, navegar por data catalogs, examinar schemas de tabelas e ver o histórico de execução. Quando uma query devolve dados, o analista não tem de os exportar para os perceber. Podem criar visualizações diretamente no editor e organizá-las em dashboards customizados que atualizam automaticamente. A plataforma também inclui uma feature de alerting. Os analistas podem escrever uma query que verifica uma métrica específica, e configurar o sistema para enviar um email ou uma notificação web se essa métrica ultrapassar um threshold definido. Muitas organizações já têm ferramentas de visualização estabelecidas. O Databricks SQL integra-se diretamente com ferramentas standard de terceiros, como o Power BI e o Tableau. Estas aplicações externas ligam-se ao Serverless SQL Warehouse e tratam o data lake exatamente como se fosse uma base de dados de alta performance. A mudança aqui tem fundamentalmente a ver com a proximidade aos teus dados. Ao trazer compute de nível de warehouse e standard SQL diretamente para o lake, deixas de copiar dados e começas a analisar a tua single source of truth no momento em que eles aterram. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Databricks, episódio 11 de 15. Se três departamentos diferentes criarem três dashboards diferentes para acompanhar a receita, e trouxerem três números diferentes para a reunião executiva, não tens um problema de data pipeline. Tens um problema de semantic layer. A solução é estabelecer uma semantic layer como a única source of truth, e no Databricks SQL, fazes isso usando Metric Views. Os dados raw raramente estão estruturados da forma como os utilizadores de negócio pensam. As tabelas da base de dados contêm nomes de colunas obscuros, joins complexos e transaction logs raw. Uma semantic layer faz a ponte, traduzindo esses dados subjacentes em conceitos de negócio familiares. Vamos ver um cenário clássico onde isto falha. A tua equipa de marketing e a tua equipa de finanças fazem relatórios sobre Monthly Active Users. O marketing escreve uma query no seu dashboard que conta qualquer pessoa que tenha aberto a aplicação. As finanças escrevem uma query diferente numa ferramenta separada, que conta apenas os utilizadores que concluíram uma transação. Ambas as equipas chamam à sua métrica Monthly Active Users. Quando os números não batem certo, a confiança organizacional nos dados colapsa. Definir os Monthly Active Users como uma Metric View dentro do Unity Catalog resolve isto para sempre. Para perceber porquê, precisamos de esclarecer o que esta feature realmente é. Uma Metric View não é a mesma coisa que uma SQL View standard. Uma SQL View standard simplesmente guarda uma query que devolve linhas e colunas raw, deixando inteiramente ao critério do utilizador final decidir como somar, calcular a média ou agrupar esses dados mais tarde. Uma Metric View é muito mais rigorosa. Ela impõe cálculos de agregação e dimensionalidade específicos diretamente ao nível do catalog. Quando crias uma Metric View, fixas a business logic exata. Defines a measure, como um distinct count de user IDs com base em critérios de transação específicos. Também defines as dimensions permitidas. Isto significa que determinas explicitamente que esta métrica só pode ser segmentada por atributos específicos, como a data da transação, a região do utilizador ou o tipo de dispositivo. Aqui está o insight principal. Assim que essa Metric View é publicada no Unity Catalog, torna-se a única definição autorizada de Monthly Active Users para toda a empresa. Quando os analistas se ligam ao Databricks SQL, não escrevem custom logic para agregar os dados. Não fazem join de tabelas nem escrevem cláusulas where para filtrar estados ativos. Simplesmente fazem uma query à Metric View. Isto desacopla completamente a definição da métrica da presentation layer. Não importa se o Marketing está a usar o Tableau, as Finanças estão a usar o Power BI, e a equipa de produto está a usar os dashboards nativos do Databricks. A ferramenta de Business Intelligence apenas pede a métrica, e o Databricks realiza o cálculo predefinido no server side. Como a lógica vive centralmente no Unity Catalog, é impossível que diferentes departamentos inventem acidentalmente a sua própria matemática. Todos obtêm exatamente o mesmo número, garantindo uma consistência perfeita em toda a organização. O verdadeiro poder de uma semantic layer não é a eficiência técnica; é tirar a business logic de downstream tools desconectadas e incorporá-la diretamente na base da própria data platform. É tudo por este episódio. Obrigado por ouvirem, e continuem a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. Databricks, episódio 12 de 15. E se o teu diretor de vendas pudesse simplesmente enviar uma mensagem para o teu data warehouse para obter business insights instantâneos, sem nunca ter de submeter um ticket à equipa de dados? Pedidos de dados ad-hoc interrompem constantemente os workflows de engenharia, e os business users odeiam esperar dias por uma simples query. A solução para este bottleneck é uma feature da Databricks chamada Genie Spaces, que faz parte da sua oferta mais abrangente de AI/BI. O AI/BI é um produto de business intelligence construído sobre um sistema de AI composto. Foi desenhado para entender a semântica específica dos teus dados. Os Genie Spaces servem como a interface conversacional para este sistema. Um Genie Space parece e funciona como uma aplicação de chat standard, mas está ligado diretamente ao teu data warehouse. Os business users escrevem perguntas em linguagem natural, e o Genie responde com dados reais, visualizações e respostas. Quando as pessoas ouvem falar de AI a fazer queries a dados, preocupam-se imediatamente com alucinações. Assumem que o modelo vai adivinhar nomes de colunas, inventar métricas ou devolver respostas erradas com toda a confiança. O Genie evita isto ao basear-se inteiramente na metadata governada guardada no teu Unity Catalog. Não está a enviar um prompt cego para um language model genérico. A AI está ancorada no teu schema real, nos teus data types, nas tuas relações de foreign key e nas métricas predefinidas que a tua equipa estabeleceu. Para que isto funcione, um analista primeiro cria e configura o Genie Space. Seleciona os datasets relevantes do Unity Catalog e fornece um conjunto de instruções. Pode adicionar queries de exemplo, definir terminologia de negócio específica e clarificar termos ambíguos. Por exemplo, pode dizer ao sistema que, quando um utilizador diz "cliente ativo", isso significa especificamente um cliente que comprou nos últimos noventa dias. Este setup inicial restringe a AI a um domínio bem definido. Quando é feita uma pergunta, o sistema orquestra vários passos. Lê o prompt em linguagem natural e verifica o contexto fornecido. Faz o match da intenção do utilizador com as tabelas e colunas exatas no catalog. A seguir, gera uma query SQL precisa, corre essa query no compute engine de SQL da Databricks e formata os resultados. Imagina um gestor de vendas não técnico a usar um Genie Space preparado. Ele escreve: "Mostra-me as vendas na Europa por produto do último trimestre." O sistema faz o parse do pedido com base no seu treino. Reconhece "Europa" como uma dimensão de região, localiza as tabelas de produtos e traduz "último trimestre" num filtro de data preciso. Em segundos, a AI gera o SQL, executa-o e devolve um gráfico interativo a mostrar o breakdown. Se o gestor depois responder: "Agora exclui a Alemanha", o Genie modifica a query subjacente e atualiza o gráfico instantaneamente, mantendo o contexto conversacional. Este workflow muda fundamentalmente a forma como os pedidos ad-hoc são tratados. Data engineers e analistas passam uma parte enorme da sua semana a escrever queries SQL one-off para os stakeholders. Mudar esta exploração para os Genie Spaces dá aos business stakeholders respostas imediatas, ao mesmo tempo que liberta o tempo da equipa de engenharia para tarefas complexas. Além disso, todo o processo permanece completamente governado. O Genie respeita estritamente todos os controlos de acesso ao nível da row e da column definidos no Unity Catalog. Se o utilizador que faz a pergunta não tiver permissão para ver dados financeiros sensíveis, a AI simplesmente não fará a query. Aqui está o insight principal. A eficácia da exploração de dados conversacional é determinada pela qualidade do teu data model e metadata subjacentes, e não apenas pela inteligência do language model. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. Databricks, episódio 13 de 15. Treinar um modelo de machine learning é a parte divertida, mas fazer o seu deploy como uma REST API segura e de alta disponibilidade é onde a maioria dos projetos de data science acaba por morrer. Passar de uma experiência num notebook para um endpoint pronto para produção exige configurar o scaling, load balancing e uma governança rigorosa. Para resolver isto, usas o Mosaic AI Model Serving. Esta funcionalidade oferece uma interface unificada para fazer deploy, governar e consultar modelos de IA. Um equívoco comum é achar que o Databricks Model Serving serve apenas para modelos que tu próprio treinas dentro do Databricks. Isso é incorreto. Na verdade, funciona como um AI Gateway central. Lida com três tipos distintos de modelos: custom models, foundation models e modelos externos. Primeiro, os custom models. Estes são os modelos que tu crias, fazes log com o MLflow e registas no Unity Catalog. O Model Serving provisiona um container serverless, carrega as dependências do teu modelo e expõe o modelo como uma REST API. Tu não geres a infraestrutura. Faz scale up quando há picos de tráfego e scale down para zero quando está idle. Segundo, foundation models alojados no Databricks. Estes são grandes modelos open-source que o Databricks aloja em compute otimizado. Tens acesso instantâneo a arquiteturas state-of-the-art sem te preocupares com o provisionamento de GPUs. Terceiro, modelos externos. É aqui que configuras endpoints que apontam para serviços de terceiros. Porquê encaminhar o tráfego externo pelo Databricks em vez de chamar os providers externos diretamente? Pensa em governança e controlo de custos. Supõe que a tua empresa quer usar o GPT-4 para uma aplicação interna. Se cada developer fizer hardcode de uma API key no seu script, perdes a visibilidade. Não consegues monitorizar os custos rigorosamente, gerir rate limits, ou aplicar filtros para impedir que os funcionários enviem dados sensíveis de clientes para um provider externo. Ao encaminhar todas as requests pelo Mosaic AI Model Serving, forças esse tráfego por um único gateway seguro. Geres um único conjunto de credenciais. Aplicas controlos de acesso através do Unity Catalog, ditando exatamente quem ou o que pode consultar o modelo. Também tens tracking centralizado de utilização, erros e latência. O fluxo lógico é simples. Defines um serving endpoint no Databricks. Para um custom model, apontas o endpoint para um modelo MLflow registado e defines o tamanho do compute e os limites de scaling. O Databricks trata da containerização automaticamente. Para um modelo externo, forneces o nome do provider externo e uma API key armazenada com segurança. Assim que o endpoint estiver ativo, as tuas aplicações downstream enviam um JSON payload standard através de uma HTTP request para o URL do endpoint. A resposta é devolvida num formato consistente, independentemente de o modelo estar a correr em serverless compute do Databricks ou alojado num data center externo. Aqui está o ponto-chave. O Mosaic AI Model Serving remove a fricção do deploy, ao mesmo tempo que garante a segurança. Padroniza a tua application layer, de modo que o teu client code comunica apenas com um único endpoint do Databricks, completamente abstraído de onde ou como o modelo subjacente está alojado. Já agora, se quiseres apoiar o programa, podes procurar por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Daqui fala o Alex da DEV STORIES DOT EU. Databricks, episódio 14 de 15. Tens dez mil raw logs de suporte ao cliente numa tabela de base de dados, e o negócio precisa que eles sejam resumidos e categorizados por sentimento até ao fim do dia. Normalmente, extrair este tipo de insights requer um pipeline complexo em Python, uma gestão cuidadosa de API keys e lógica customizada de batching para alimentar o texto num Large Language Model. E se pudesses executar todo esse workload usando um comando básico de base de dados? Esse é exatamente o problema resolvido pelas AI Functions, que embutem LLMs diretamente nas tuas queries SQL. As AI Functions preenchem a lacuna entre a Generative AI de ponta e o data analytics do dia a dia. Elas pegam numa capacidade que geralmente exige engenharia de machine learning especializada e entregam-na a qualquer pessoa que saiba escrever SQL. Em vez de construir uma infraestrutura separada para extrair dados, enviá-los para um modelo e gravar as previsões de volta, as AI Functions trazem o modelo diretamente para onde os dados já estão. A principal ferramenta para isto é um comando built-in chamado A I query. Usas este comando exatamente como uma função standard de processamento de texto dentro de um select statement. Forneces o nome do endpoint do modelo que queres usar e, em seguida, forneces o prompt. Voltando àqueles dez mil logs de suporte, o teu workflow torna-se trivial. Escreves uma query a fazer select do teu customer ID e do texto do log. Em seguida, adicionas uma nova coluna usando a função A I query. O teu prompt diz ao modelo para ler o texto, extrair a principal reclamação e determinar se o sentimento é positivo, neutro ou negativo. Passas a coluna que contém o teu raw log text para esse prompt. Quando corres a query, o database engine distribui automaticamente este pedido. Ele processa cada uma das linhas através do Large Language Model especificado. O modelo avalia o texto e devolve o resumo e o sentimento. Como tudo isto acontece em SQL, o output chega como colunas estruturadas standard. Podes filtrar imediatamente os resultados para mostrar apenas o sentimento negativo, fazer join desses resultados com uma tabela de billing de clientes, e agregar os dados para descobrir qual produto está a causar mais frustração. Aqui está o insight principal. Podes presumir que dar acesso a Large Language Models aos data analysts significa distribuir API keys sensíveis por toda a tua organização. Mas não. As AI Functions estão fortemente integradas com o Databricks Model Serving. As ligações reais a modelos externos, ou modelos open-source self-hosted, são configuradas pelos administradores ao nível da plataforma. O data analyst nunca vê uma API key, um token ou um secret. Apenas referencia o nome do endpoint pré-configurado na sua query. Toda a operação permanece completamente segura. Cada query é registada em log, e todos os controlos de acesso aplicados aos dados e aos modelos são rigorosamente aplicados pela framework de governance da plataforma. Ao remover a fricção da infraestrutura e a gestão de credenciais, mudas a natureza da data exploration. Transformas a análise complexa de texto não estruturado numa simples operação de filtragem, aumentando instantaneamente o poder analítico de toda a tua equipa. Obrigado por ouvirem. Fiquem bem.

Olá, daqui é o Alex do DEV STORIES DOT EU. Databricks, episódio 15 de 15. O teu chatbot padrão é educado, informativo e completamente passivo. Pode dizer-te como corrigir um pipeline com problemas com base num manual, mas não consegue, de facto, corrigir o pipeline por ti. Passar de uma IA que apenas fala para uma IA que executa tarefas ativamente exige uma mudança fundamental na arquitetura. Essa mudança é o AI Agent Framework. Vamos já esclarecer uma confusão comum. As pessoas confundem frequentemente aplicações simples de Retrieval-Augmented Generation com verdadeiros agentes. Uma aplicação RAG é essencialmente um motor de busca com um modelo de linguagem por cima. Recupera documentos e resume-os. Apenas lê. Um verdadeiro AI Agent tem tools. Consegue escrever. Consegue correr queries SQL, fazer trigger a jobs e chamar APIs externas. Altera o estado dos teus sistemas. O Agent Framework do Databricks fornece a infraestrutura para construir, avaliar e fazer deploy destes agentes autónomos com segurança dentro do Lakehouse. O mecanismo central aqui é o tool calling combinado com multi-step reasoning. Em vez de simplesmente gerar uma resposta numa só passagem, o modelo de linguagem atua como um motor de raciocínio. Dás-lhe um objetivo e um conjunto de tools, que são basicamente funções que definiste. O agente decide qual tool usar, espera pelo resultado e, depois, decide o que fazer a seguir. Pensa num agente desenhado para monitorizar data pipelines. Quando ocorre uma falha, o agente não fica simplesmente parado à espera de um prompt do utilizador. O framework permite-lhe fazer trigger a um workflow. Primeiro, o agente precisa de contexto. Usa uma tool personalizada que forneceste para correr uma query SQL nos teus system logs no Databricks. O framework executa esta query e devolve o resultado ao agente. Aqui está o ponto-chave. O agente avalia esses logs, identifica a root cause da falha e, depois, passa para o passo seguinte. Percebe que a equipa de engenharia precisa de saber. Então, seleciona outra tool, uma integração de API com a aplicação de chat da tua empresa. Chama essa tool para redigir e enviar uma mensagem a detalhar o erro exato e a correção proposta. Isto é multi-step reasoning em ação. O agente planeou uma sequência, executou código, observou o resultado e comunicou-o, tudo de forma autónoma. Dar a um modelo de linguagem a capacidade de executar queries e fazer trigger a APIs é um enorme risco de segurança se for mal gerido. É por isso que a abordagem do Databricks integra fortemente o Agent Framework ao Unity Catalog. Quando fazes deploy de um agente usando o Databricks Model Serving, não lhe estás a dar acesso total à tua infraestrutura. Registas as tuas tools como funções específicas dentro do Unity Catalog. O Unity Catalog impõe uma governança rigorosa sobre o que essas funções podem fazer. Se deres a um agente uma tool para fazer query a tabelas de logs, o Unity Catalog garante que ele só consegue ler essas tabelas específicas. Se o modelo de linguagem tiver uma alucinação e tentar usar a tool de SQL para fazer drop a uma base de dados de produção, o framework impede-o, porque a função subjacente não tem as permissões necessárias. O agente está estritamente limitado pelas regras de governança do teu Lakehouse. Esta capacidade transforma o Lakehouse de uma camada de storage passiva num ambiente ativo e automatizado. A terminar esta série, encorajo-te a consultar a documentação oficial e a tentares construir tu mesmo um agente simples de tool-calling. Se quiseres sugerir tópicos para a nossa próxima série, passa por devstories dot eu. A transição de chatbots para agentes é a mudança que define a forma como construímos aplicações de IA hoje em dia. É tudo por agora. Obrigado por ouvires, e continua a construir!