Databricks

Salut, sunt Alex de la DEV STORIES DOT EU. Databricks, episodul 1 din 15. Ani de zile, companiile au plătit de două ori pentru a stoca exact aceleași date doar pentru a-și mulțumi atât inginerii de machine learning, cât și analiștii de business. Stocarea datelor brute într-un sistem și copierea lor în altul creează bătăi de cap nesfârșite cu sincronizarea. Databricks rezolvă acest lucru prin introducerea unei abordări unificate numite Data Lakehouse. Istoric vorbind, organizațiile și-au împărțit arhitectura de date pe două căi separate. Mai întâi, au construit Data Lakes. Acestea sunt sisteme de cloud storage ieftine și extrem de scalabile, perfecte pentru a stoca cantități masive de date nestructurate. Data scientists le adoră pentru antrenarea modelelor de machine learning. Dar Data Lakes sunt groaznice pentru query-uri SQL rapide și fiabile. Pentru a rezolva asta, companiile au introdus Data Warehouses pentru echipele lor de business intelligence. Acest lucru creează o povară operațională masivă. Ia ca exemplu un startup în creștere. Echipa lor de data engineers salvează event logs brute într-un cloud storage bucket. Își rulează scripturile Python acolo. Dar echipa financiară are nevoie de dashboards. Așa că inginerii trebuie să construiască pipelines complexe pentru a extrage acele date, a le transforma și a le încărca într-un data warehouse separat. Compania plătește pentru stocare de două ori. Plătește pentru compute-ul necesar ca să mute datele. Și în momentul în care datele ajung în warehouse, sunt deja învechite. Databricks elimină complet acest pipeline cu arhitectura Data Lakehouse. Un Lakehouse combină stocarea ieftină și flexibilă a unui data lake cu fiabilitatea și performanța unui data warehouse. Îți păstrează datele într-un singur format deschis, direct în cloud storage. Nu le copiezi într-o bază de date proprietară. În schimb, Databricks adaugă un strat tranzacțional direct peste data lake-ul tău existent. Iată ideea cheie. Datele tale rămân într-un singur loc, dar diferiți profesioniști interacționează cu ele exact așa cum au nevoie. Data scientists pot scrie Python sau Scala pentru a antrena modele direct pe fișierele brute. Simultan, analiștii de business pot rula query-uri SQL de înaltă performanță pe exact aceleași date pentru a-și alimenta tool-urile de raportare. Oamenii cred adesea în mod eronat că Databricks este doar o altă bază de date SQL sau pur și simplu un managed wrapper în jurul Apache Spark. Nu este niciuna dintre acestea. Este o platformă cuprinzătoare de Data Intelligence. Prin fuzionarea lake-ului și a warehouse-ului, fuzionezi și securitatea și guvernanța. În modelul vechi, trebuia să gestionezi permisiunile de acces în cloud storage pentru ingineri și separat în data warehouse pentru analiști. Cu Databricks, un strat de guvernanță unificat gestionează controlul accesului pentru fiecare tabel, fișier și model de machine learning. Definești o politică de acces la date o singură dată, iar aceasta se aplică peste tot, indiferent de limbajul sau tool-ul folosit pentru a face query-uri. Adevărata putere a arhitecturii Lakehouse nu constă doar în economisirea banilor pe storage pipelines redundante; ci în faptul că modelele tale de inteligență artificială și dashboards-urile financiare se uită în sfârșit la exact aceleași numere, în exact același timp. Dacă vrei să ajuți la susținerea show-ului, poți căuta DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Mulțumesc pentru audiție și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Databricks, episodul 2 din 15. Dacă firma ta folosește mai multe workspace-uri pentru a procesa date, probabil ai mai multe locuri unde gestionezi permisiunile de securitate. Această fragmentare reprezintă un risc masiv de compliance, pentru că menținerea politicilor sincronizate în medii deconectate se bazează în întregime pe update-uri manuale. Unity Catalog elimină acest risc schimbând fundamental modul în care funcționează data governance-ul în Databricks. Înainte să explicăm mecanismele, trebuie să clarificăm o concepție greșită foarte comună. Unity Catalog nu este un data dictionary pasiv. Nu este doar o listă de tabele unde userii intră să citească descrieri. Este un policy engine central care aplică activ regulile de securitate în întreaga ta arhitectură. Unity Catalog rezolvă problema constantă de a ști exact cine are acces la ce. Oferă un model de securitate unificat, bazat pe standardul ANSI SQL. În loc să configurezi separat rolurile de cloud identity, permisiunile la nivel de workspace și access control-ul la nivel de cluster, folosești comenzi familiare precum grant și revoke direct pe datele și asset-urile tale de inteligență artificială. Pentru că Unity Catalog stă la nivel de cont, în loc să fie legat de un workspace individual, definești o regulă de securitate o singură dată. Acea regulă este apoi aplicată instant și universal în fiecare workspace atașat acelui catalog. Gândește-te la o situație în care un auditor îi cere unui CTO să demonstreze exact cine a dat query pe un anumit tabel cu numere de carduri de credit marțea trecută, și să identifice fiecare raport downstream care folosește în prezent acele numere. În trecut, ca să răspunzi la asta trebuia să parsezi log-uri de sistem deconectate din diferite tool-uri, să citești manual job-urile de transformare programate și să speri că nu ai ratat niciun pas intermediar. Unity Catalog gestionează asta nativ prin următorii săi doi piloni: auditare built-in și lineage automat. În primul rând, capturează audit log-uri detaliate, la nivel de user, out of the box. De fiecare dată când un user sau un service principal accesează date, catalogul înregistrează evenimentul. Aici e ideea cheie. Unity Catalog nu face tracking doar pe cine a dat query pe un tabel; urmărește ce se întâmplă cu datele mai departe prin lineage automat. Pe măsură ce pipeline-urile tale programate rulează, sistemul citește continuu execution plan-urile și construiește o hartă a modului în care circulă datele. Urmărește care tabele sursă alimentează care dataset-uri intermediare, până la dashboard-urile finale. Face acest tracking atât la nivel de tabel, cât și la nivel de coloană. Când auditorul întreabă despre datele cardurilor de credit, nu trebuie să ghicești. Te uiți pe lineage graph și vezi instant fiecare pas de transformare și fiecare access point. Ultimul pilon major este data sharing securizat. Organizațiile au adesea nevoie să facă share la dataset-uri cu vendori externi sau cu business unit-uri separate. În loc să exporte flat file-uri sau să duplice date în bucket-uri separate de cloud storage, Unity Catalog integrează un protocol numit Delta Sharing. Asta îți permite să acorzi părților externe acces guvernat la date live, fără să le copiezi. Consumatorul extern citește datele in place, iar accesul lui este logat și controlat de exact același creier central. Adevărata valoare a Unity Catalog este că elimină complet decalajul periculos dintre scrierea unei politici de securitate pe hârtie și executarea ei efectivă în data silos izolate. Asta e tot pentru acest episod. Mersi că m-ai ascultat și keep building!

Salut, sunt Alex de la DEV STORIES DOT EU. Databricks, episodul 3 din 15. Cea mai ușoară modalitate de a-ți epuiza bugetul de cloud este să lași un server masiv să ruleze în gol tot weekendul. Vrei putere de procesare exact atunci când ai nevoie de ea și facturare zero atunci când nu ai. Exact despre asta vorbim astăzi în Navigarea prin Workspace și Compute. Punctul tău de intrare în Databricks este workspace-ul. Gândește-te la workspace ca la mediul unificat în care echipa ta își organizează toate asset-urile Databricks. Acesta oferă o interfață web pentru a-ți gestiona notebook-urile, obiectele de date, experimentele de machine learning și resursele de compute de la bază. Workspace-ul reunește toate tool-urile tale de colaborare într-o singură vizualizare organizată, asigurându-se că diferite echipe pot interacționa cu aceleași date de la bază fără să se calce pe picioare. Sub capotă, Databricks se bazează pe o arhitectură decuplată. Datele tale trăiesc persistent în cloud object storage, în timp ce puterea de compute folosită pentru a procesa acele date este pornită complet separat. Această separation of concerns îți dictează facturarea. Deoarece partea de compute este izolată de storage, faci provision și plătești pentru instanțele de server doar atunci când rulezi cod în mod activ. Când treaba este gata, resursa de compute se oprește, dar datele tale rămân stocate în siguranță și accesibile. Pentru a gestiona această putere de procesare, Databricks oferă diferite tipuri de resurse de compute adaptate pentru workflow-uri specifice. Primul este un cluster All-Purpose. Îl folosești pentru muncă interactivă, ad-hoc. Să zicem că un data analyst are nevoie de un mediu foarte capabil pentru a rula un query pe un miliard de rânduri într-o după-amiază de marți. Acesta pornește un cluster All-Purpose, își atașează notebook-ul și începe să exploreze. Pentru a preveni surprizele la facturare în weekend, aceste clustere se bazează pe auto-termination. Dacă analistul pleacă acasă la cinci și lasă notebook-ul deschis, clusterul se monitorizează singur pentru inactivitate și se oprește automat după o limită de timp specificată. Iată ideea cheie legată de automatizare. O greșeală frecventă pe care o fac echipele este programarea pipeline-urilor de producție automate să ruleze pe aceste clustere All-Purpose interactive. Evită să faci asta. Clusterele All-Purpose au un cost de utilizare mai mare, iar rularea mai multor workflow-uri diferite pe un cluster interactiv partajat poate introduce conflicte de librării sau resource contention. În schimb, pipeline-urile de producție ar trebui să folosească Job clusters. Un Job cluster este complet efemer. Când un pipeline automat este declanșat, job scheduler-ul Databricks face provision pentru un Job cluster dedicat strict pentru acel workload. Rulează codul, iar în secunda în care job-ul se termină, clusterul se închide singur. Asta garantează o izolare strictă a resurselor pentru pipeline-ul tău și te asigură că plătești cea mai mică rată de compute posibilă pentru task-urile automatizate. În cele din urmă, dacă workload-ul tău este pur analitic, poți folosi un SQL warehouse. Aceasta este o resursă de compute optimizată special pentru rularea comenzilor SQL și a query-urilor de dashboard. Dacă folosești Serverless SQL warehouses, Databricks gestionează automat partea de compute de la bază. Face scale up instantaneu atunci când apare un val de query-uri și face scale down atunci când coada se golește, eliminând complet nevoia de a-ți configura tu însuți infrastructura. Potrivirea tipului de compute potrivit cu natura exactă a task-ului tău este cea mai eficientă modalitate de a garanta că infrastructura ta de cloud rămâne puternică în timpul orelor de vârf și extrem de cost-efficient atunci când treaba este gata. Asta e tot pentru acest episod. Mulțumesc pentru audiție și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Databricks, episodul 4 din 15. Construiești un data lake, dar în câteva luni nimeni nu mai știe unde sunt datele de producție, cine le deține sau dacă un anumit tabel este într-adevăr sigur pentru a face un query. Diferența dintre un data lake impecabil și un data swamp imposibil de gestionat stă în exact trei niveluri de adâncime. Astăzi ne uităm la Organizarea datelor: Object Model. Unity Catalog aduce ordine în datele tale printr-o ierarhie strictă și previzibilă. Containerul de la cel mai înalt nivel este metastore-ul, care conține metadata organizației tale. Dar interacțiunile tale zilnice se bazează pe namespace-ul principal pe trei niveluri. Fiecare query pe care îl scrii țintește un asset folosind formatul catalog punct schema punct object. Primul nivel este catalog-ul. Acesta oferă o graniță largă pentru data assets. De obicei, folosești cataloage pentru a separa logic mediile, cum ar fi să ai un catalog pentru producție și unul complet separat pentru development. Al doilea nivel este schema, care mai este denumită și database. Schemele trăiesc în interiorul cataloagelor și organizează dataset-uri corelate. Poți crea o schemă pentru evenimente raw ingerate și o alta pentru analytics rafinat. Al treilea nivel este object-ul în sine. Acesta este tabelul tău propriu-zis, un view sau un volume care conține fișiere non-tabulare. Prin impunerea acestei convenții de denumire din trei părți, Unity Catalog oferă fiecărei bucăți de date o adresă clară și lipsită de ambiguitate. Când un analist face un query pe production punct sales punct customers, locația, stadiul de lifecycle și scopul acelor date sunt instantaneu evidente. Iată ideea de bază. Odată ce ajungi la nivelul de tabel, trebuie să înțelegi cum interacționează Unity Catalog cu storage-ul tău propriu-zis. Există două tipuri principale de tabele: managed tables și external tables. Managed tables sunt default. Când creezi un managed table, Unity Catalog deține atât metadata, cât și datele subiacente. El se ocupă de file layout și gestionează întregul lifecycle al datelor. Fișierele propriu-zise sunt salvate într-o locație de storage desemnată, pe care o configurezi la nivel de metastore, catalog sau schemă. External tables funcționează diferit. Folosești un external table atunci când ai fișiere care stau deja într-un cloud storage bucket și vrei să le lași exact acolo unde sunt. Cu un external table, Unity Catalog înregistrează structura și guvernează accesul, dar deține doar metadata. Tu păstrezi controlul complet asupra fișierelor fizice. Această distincție devine critică în timpul operațiunilor distructive. Ia în considerare un scenariu în care un data engineer execută accidental o comandă drop table. Dacă dă drop la un managed table, Unity Catalog elimină tabelul din metastore și șterge automat fișierele subiacente din cloud storage-ul tău. Datele sunt distruse. Dacă dă drop la un external table, Unity Catalog elimină pur și simplu linkul de metadata. Tabelul dispare din interfața de workspace, dar fișierele raw din cloud storage rămân perfect intacte și neatinse. Folosește mereu managed tables atunci când vrei ca acest catalog să optimizeze și să guverneze întregul lifecycle al storage-ului, și rezervă external tables pentru datele pe care trebuie să le protejezi de ștergerea accidentală sau să le partajezi direct cu alte sisteme externe. Mersi că ai stat pe aici. Sper că ai învățat ceva nou.

Salut, sunt Alex de la DEV STORIES DOT EU. Databricks, episodul 5 din 15. Poți restricționa cu ușurință cine vede o coloană într-o bază de date relațională, dar cum aplici access control pe un cloud storage bucket plin cu mii de PDF-uri raw? Răspunsul este: Stăpânirea datelor nestructurate cu ajutorul volumelor. Înainte să intrăm în detalii despre cum funcționează, hai să clarificăm o confuzie frecventă. Volumele sunt strict pentru acces la fișiere bazat pe path. Nu sunt pentru date tabelare. Dacă faci query-uri pe rânduri și coloane cu SQL, folosești un tabel. Dacă citești imagini, documente text sau fișiere audio, folosești un volum. Un volum este un obiect din Unity Catalog. Reprezintă un spațiu logic de stocare în mediul tău de cloud. Prin crearea unui volum, aduci datele nestructurate sub exact aceeași umbrelă de securitate ca și tabelele tale structurate. În loc să gestionezi identity policies în AWS sau role assignments în Azure doar ca să citești un fișier, controlezi accesul folosind permisiuni standard direct în Databricks. Gândește-te la un spital care antrenează un model de machine learning pentru a detecta anomalii în radiografii. Nu pot pune mii de imagini high-resolution într-un tabel dintr-o bază de date. Trebuie să le stocheze ca fișiere raw în cloud object storage. Pentru că acestea sunt fișiere extrem de sensibile ale pacienților, o guvernanță strictă este esențială. Punând radiografiile într-un volum Databricks, echipa de engineering poate controla exact care data scientists au voie să citească acel director specific. Există două tipuri de volume: managed și externe. Un volum managed este administrat complet de Databricks. Când creezi unul, nu specifici un storage path. Databricks pur și simplu alocă spațiu în locația de default storage atribuită schemei tale curente. Uploadezi fișiere direct în el. Dacă dai vreodată drop la un volum managed, Databricks șterge și fișierele subiacente. Asta le face ideale pentru fișiere temporare de workspace sau pentru date generate în întregime în pipeline-urile tale Databricks. Un volum extern pointează către un director de cloud storage existent pe care îl deții deja. Mai întâi, înregistrezi un cloud storage path ca external location în Unity Catalog. Apoi, creezi un volum peste el. Asta îți oferă o guvernanță strictă asupra datelor produse de alte sisteme. Dacă o aplicație separată scrie log files într-un bucket Azure Data Lake, un volum extern permite utilizatorilor Databricks să citească acele fișiere în siguranță. Dacă dai drop la un volum extern, metadatele sunt șterse, dar fișierele subiacente din cloud bucket-ul tău rămân complet neatinse. Această abordare bazată pe path este exact ceea ce necesită AI-ul modern. Librăriile de machine learning open-source se așteaptă de obicei să citească date dintr-un sistem de fișiere local. Nu știu cum să se autentifice cu interfețe proprietare de cloud storage. Volumele rezolvă asta prin expunerea unui directory path care arată și se comportă ca un folder local standard. Scriptul tău de antrenare a modelului deschide pur și simplu un file path. Unity Catalog interceptează acel request și verifică în mod transparent permisiunile utilizatorului. Iată ideea principală. Volumele elimină deconectarea dintre modul în care îți guvernezi bazele de date structurate și modul în care îți securizezi fișierele raw, permițându-ți să rulezi workload-uri de machine learning pe date nestructurate fără să ocolești enterprise security. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Databricks, episodul 6 din 15. Dacă data engineerii tăi încă dau paste la chei de acces cloud direct în scripturile lor, compania ta e la o singură greșeală distanță de o breșă masivă de date. Soluția pentru a conecta în siguranță workspace-ul și cloud storage-ul fără a expune secrete este Bulletproof Cloud Security: External Locations. Când un utilizator se loghează în Databricks, folosește un identity token. Acel token dovedește workspace-ului cine este. Dar acea identitate nu înseamnă absolut nimic pentru cloud provider-ul din spate, fie că este vorba de AWS, Azure sau Google Cloud. Pentru a citi un fișier dintr-un cloud bucket, workspace-ul în sine trebuie să se autentifice la infrastructura cloud. În trecut, developerii ocoleau această problemă prin hardcodarea cheilor cloud IAM direct în notebook-uri sau în environment variables. Acest lucru creează o vulnerabilitate severă de securitate, deoarece oricine are read access la cod poate fura cheile. Unity Catalog rezolvă acest lucru printr-o abstracție strictă în două părți. Prima parte este Storage Credential. Un Storage Credential reprezintă un mecanism de autentificare și autorizare direct legat de cloud provider-ul tău. Se mapează la un IAM role în AWS, un Managed Identity în Azure sau un Service Account în Google Cloud. În loc să dea chei cloud raw unui developer, administratorul tău de cloud acordă privilegii de acces acestui Storage Credential. Unity Catalog deține autoritatea de a-și asuma acest rol, ținând credential-ul propriu-zis complet departe de utilizatorii workspace-ului. Acum, un Storage Credential singur este prea general. Acel IAM role ar putea avea permisiunea de a accesa zeci de bucket-uri diferite din mediul tău cloud. Aici intervine a doua parte. Un External Location asociază un Storage Credential cu un cloud storage path specific, cum ar fi un S3 bucket URI sau un Azure Data Lake Storage container path. Definește exact unde are voie să opereze acel credential. Te poți gândi la el ca la o graniță geografică pentru credentialele tale de cloud. Ia un scenariu concret. Un developer trebuie să analizeze logurile de sistem stocate într-un S3 bucket extrem de securizat. Într-un setup legacy, un admin ar genera AWS access keys și i le-ar trimite developerului, sperând că nu va da accidental commit la acele chei într-un public code repository. Cu Unity Catalog, workflow-ul se schimbă complet. Adminul creează un Storage Credential configurat cu un IAM role care poate citi target bucket-ul. Apoi, adminul creează un External Location care pointează strict către S3 path-ul ce conține logurile de sistem și îi atașează acel Storage Credential. În cele din urmă, folosind SQL standard, adminul îi dă developerului permisiunea de a citi fișiere exclusiv pe acel External Location. Când developerul rulează un query pe loguri, Unity Catalog intervine și gestionează transparent cloud authentication-ul în numele său. Developerul nu vede niciodată un AWS key. Nu gestionează secrete și nu configurează cloud profiles. Doar face query pe path-ul permis. Ulterior, poți construi external tables sau external volumes direct peste acest location pentru a organiza și mai bine datele. Dacă developerul se mută la altă echipă, adminul pur și simplu îi revocă grant-ul pe External Location-ul din Databricks. Configurația cloud IAM din spate rămâne complet neatinsă. Iată ideea principală. External Locations decuplează securitatea infrastructurii cloud de guvernanța zilnică a accesului la date. Ținând IAM roles în afara codului utilizatorului și ancorându-le de path-uri explicite, garantezi că fiecare request de date este auditat, securizat și restricționat în întregime la datele pe care intenționezi să le partajezi. Mersi că ai petrecut câteva minute cu mine. Până data viitoare, toate bune.

Salut, sunt Alex de la DEV STORIES DOT EU. Databricks, episodul 7 din 15. Inginerii de date pierd enorm de mult timp doar încercând să prevină crăparea scripturilor fragile de ingestion din API. Când un endpoint își modifică logica de paginare sau scade un rate limit, pipeline-ul tău crapă, și îți petreci după-amiaza făcând debug pe JSON în loc să construiești modele de date. Soluția la această bătaie de cap specifică este Lakeflow Connect. Înainte să ne uităm la cum funcționează, hai să clarificăm o confuzie comună de naming. Databricks are Lakeflow Jobs și Lakeflow Connect. Lakeflow Jobs se ocupă de orchestration, adică rulează task-uri într-o secvență specifică. Lakeflow Connect este strict despre ingestion. Este mecanismul prin care aduci raw data din sisteme externe în mediul tău Databricks. În esență, Lakeflow Connect oferă Managed Connectors. Acestea sunt integrări native, construite special pentru aplicații și baze de date enterprise. De obicei, când trebuie să tragi date din sisteme externe, scrii cod Python custom. Acel cod trebuie să gestioneze autentificarea, să se ocupe de retries când serverul întrerupe o conexiune, să urmărească ce record-uri au trecut deja prin ingestion și să facă parse la o paginare complexă. Managed Connectors elimină tot acel layer de infrastructură custom. Databricks gestionează partea de compute din spate, interacțiunile cu API-ul și state tracking-ul necesar pentru citiri incrementale. Pentru că Lakeflow Connect rulează pe serverless compute, nu trebuie să configurezi sau să gestionezi clustere doar ca să tragi date. Serviciul face scale automat în funcție de volumul de date care intră. De asemenea, se integrează direct cu Unity Catalog, ceea ce înseamnă că datele care trec prin ingestion sunt imediat guvernate și disponibile pentru querying. Gândește-te la o cerință standard. Echipa ta de marketing are nevoie de date Salesforce la zi în lakehouse-ul tău. Dacă construiești asta de la zero, s-ar putea să pierzi o săptămână scriind un script custom care face query pe API-ul Salesforce. Trebuie să scrii logică pentru a rămâne sub limitele stricte de API, să gestionezi token refreshes și să faci merge la update-uri în tabelele tale Delta existente, fără să duplici record-uri. Cu un Managed Connector în Lakeflow Connect, sari complet peste codul custom. Oferi credențialele de conexiune, selectezi obiectele Salesforce specifice pe care vrei să le urmărești și setezi un catalog și o schemă de destinație. Setup-ul durează câteva minute. Databricks preia execuția. Extrage snapshot-ul istoric inițial al datelor tale, iar apoi trece la capturarea continuă a schimbărilor incrementale pe măsură ce se întâmplă. Iată ideea principală. Mutând workload-ul de ingestion către un Managed Connector, nu mai trebuie să menții scripturi de polling. Când o specificație de API extern se schimbă, Databricks face update la conector în spate. Pipeline-ul tău pur și simplu continuă să ruleze. Asta te eliberează ca să te poți concentra pe logica de business reală, cum ar fi transformarea de raw data în tabele agregate sau antrenarea de modele de machine learning, în loc să faci babysitting unui script de extracție stricat. Valoarea reală a Lakeflow Connect nu este doar setup-ul rapid, ci eliminarea permanentă a codului de ingestion custom din backlog-ul tău de mentenanță. Dacă vrei să ajuți emisiunea să meargă mai departe, poți căuta DevStoriesEU pe Patreon și ne poți susține acolo. Mersi că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.

Salut, sunt Alex de la DEV STORIES DOT EU. Databricks, episodul 8 din 15. Ai un pipeline ETL complex în care un tabel se actualizează din oră în oră, altul se actualizează continuu, iar orchestrarea dependențelor necesită sute de linii de cod de state-management. Cum ar fi dacă ai putea pur și simplu să declari tabelele finale pe care le vrei și să lași engine-ul să construiască infrastructura pentru a le menține actualizate? Asta este premisa de Automated ETL folosind pipeline-uri declarative. Într-un pipeline imperativ tradițional, îi spui sistemului exact cum să-și facă treaba. Scrii codul pentru a gestiona checkpoint-urile, a te ocupa de retries, a mapa dependențele și a proviziona clustere. Pipeline-urile declarative inversează acest model. Pur și simplu declari cum ar trebui să arate tabelul final, de obicei cu un query SQL standard sau o funcție Python. Engine-ul din spate construiește execution graph-ul, gestionează infrastructura și se ocupă automat de state transitions. Pentru ca asta să funcționeze, Databricks se bazează pe două tipuri specifice de tabele. O greșeală comună e să le tratezi ca fiind interschimbabile. Nu sunt. Trebuie să separi clar datele de evenimente de tip append-only de agregările complexe. Primul tip este Streaming Table. Streaming Tables sunt concepute strict pentru procesare incrementală, de tip append-only. Ele citesc continuu sau în batch-uri dintr-o sursă de date, procesează doar înregistrările noi și le fac append la target. Gândește-te la procesarea unui stream masiv de click-uri pe website care vin din Kafka. Scrii un query pentru a popula un Streaming Table din acel topic de Kafka. Nu scrii cod pentru a urmări offset-urile sau pentru a ține minte ce mesaje au fost deja citite. Pipeline-ul menține state-ul intern, asigurându-se că fiecare click este procesat exact o singură dată, chiar dacă sistemul își dă restart. Acum, a doua parte din asta. Odată ce ai stocat în siguranță evenimentele raw, de obicei trebuie să le transformi. Aici intervin Materialized Views. În timp ce Streaming Tables se ocupă de ingest-ul inițial de date noi, Materialized Views sunt construite pentru agregări complexe, join-uri și înregistrări care primesc update sau delete în timp. Revenind la click-urile noastre de pe website, ai nevoie de un dashboard executiv zilnic care să afișeze totalul de click-uri grupate pe regiune. Definești un Materialized View care dă select din Streaming Table-ul tău și rulează agregarea. Când rulează pipeline-ul, engine-ul evaluează Materialized View-ul. El determină cel mai eficient mod de a aduce view-ul la zi. Dacă poate face compute la modificări incremental, o va face. Dacă este necesar un recompute complet, se ocupă de asta automat. Nu scrii niciodată logica care dictează când să se facă refresh sau cum să se dea merge la noile agregări. Aici e ideea cheie. Pentru că definești atât Streaming Tables, cât și Materialized Views în mod declarativ, engine-ul Databricks înțelege întregul lineage al datelor tale. Știe că Materialized View-ul depinde de Streaming Table. Le leagă împreună într-un pipeline graph unificat. Dacă un compute node pică în mijlocul procesării, pipeline-ul se bazează pe acel graph pentru a da pause, retry și resume fără a duplica înregistrări sau a corupe dashboard-ul final. Codebase-ul tău nu mai este aglomerat cu scaffolding operațional. Conține doar business logic-ul pur care definește modul în care datele circulă de la sursă la destinație. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Databricks, episodul 9 din 15. Dacă procesarea ta de date din timpul nopții se bazează pe un chain de programări cron independente, practic speri că pasul anterior s-a terminat la timp. Zbori în orb. Pentru a opri acele silent failures și a garanta ordinea de execuție, ai nevoie de Master Orchestration cu Lakeflow Jobs. Mai întâi, o scurtă distincție. Lakeflow Pipelines gestionează dependențele de date la nivel de tabelă. Lakeflow Jobs, pe care ne concentrăm acum, orchestrează task-urile la nivel macro. Gândește-te la pipelines care mută date în interiorul warehouse-ului, în timp ce job-urile leagă între ele notebook-uri, script-uri Python și modele de machine learning într-un workflow mai mare. Un job în Databricks este containerul principal pentru orchestrarea ta. În interiorul acelui container, definești mai multe task-uri. Un task este o singură unitate izolată de lucru. Ar putea fi executarea unui notebook Databricks, lansarea unei aplicații Spark, rularea unui proiect dbt sau rularea unui query SQL. Prin conectarea acestor task-uri, construiești un graf de execuție în care un task începe doar atunci când dependențele sale specifice se finalizează cu succes. Să parcurgem un scenariu practic pentru a vedea cum gestionează control flow-ul fiabilitatea. Ai un proces zilnic care ingerează raw data, le verifică calitatea, le transformă și alertează echipa dacă ceva merge prost. Începi prin a defini un task de ingestie. Apoi, legi un task de data quality care rulează strict după finalizarea ingestiei. Iată ideea cheie. În loc să scrii error handling custom în codul tău Python pentru a decide ce se întâmplă mai departe, folosești control flow-ul nativ al job-ului. Adaugi un task cu o condiție if-else imediat după verificarea calității. Condiția evaluează o variabilă returnată de task-ul tău de data check. Dacă datele sunt curate, job-ul urmează ramura if și declanșează task-ul tău de transformare downstream. Dacă datele sunt corupte, job-ul urmează ramura else și declanșează un task webhook care dă ping unui canal de Slack. De asemenea, gestionezi state-ul folosind condiții de task run-if. Poți configura un task de alertare să se execute doar dacă task-ul anterior a picat complet, în timp ce restul pipeline-ului se oprește în siguranță. Asta previne clasica cascadă de silent failures, în care un pas de ingestie stricat declanșează silențios un model de machine learning să se antreneze pe tabele complet goale. Pentru a iniția acest workflow, aplici un trigger. Job-urile pot rula on demand, la un interval programat tradițional, sau continuu. De asemenea, se pot executa pe baza unui eveniment, cum ar fi un fișier nou care ajunge într-un bucket extern de cloud storage. Odată declanșat, Databricks oferă observabilitate built-in. Nu trebuie să ghicești unde a apărut o eroare. Platforma înregistrează un istoric complet de rulare cu un matrix view, arătându-ți exact ce task a avut succes, ce task s-a blocat și cât a durat fiecare pas. Poți configura notificări la nivel de job sau la nivel de task pentru a trimite email-uri automate sau webhook-uri în momentul în care un execution state se schimbă. Adevărata valoare a acestui model de orchestrare este mutarea părții de failure handling din script-urile tale individuale în infrastructura platformei, asigurându-te că sistemul tău știe exact cum să ruteze execuția atunci când lucrurile inevitabil se strică. Asta e tot pentru acest episod. Mersi pentru ascultare și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Databricks, episodul 10 din 15. Mutarea datelor din data lake-ul tău doar pentru ca echipa de business intelligence să poată rula query-uri pe ele este lentă, costisitoare și complet inutilă. Ajungi să menții pipelines fragile doar pentru a copia date dintr-un sistem în altul, introducând întârzieri și duplicând costurile de storage. Asta e exact problema pe care o rezolvă Databricks SQL. Există o concepție greșită destul de comună cum că Databricks ar fi strict pentru data engineers și data scientists care scriu Python sau Scala. Databricks SQL clarifică asta. Este un workspace dedicat, construit în întregime pentru cei care lucrează cu SQL. Imaginează-ți o echipă de business intelligence care migrează de pe un legacy data warehouse. În mod tradițional, așteptau ca inginerii să ruleze extraction jobs peste noapte pentru a încărca datele din data lake în warehouse. Abia atunci puteau începe să construiască rapoarte. Databricks SQL elimină tot acel extraction layer. Permite analiștilor să ruleze query-uri standard ANSI-SQL direct pe data lake. Obții scalabilitatea masivă a stocării de tip open lake, dar interacționezi cu el folosind interfața familiară și rapidă a unui relational warehouse tradițional. Motorul din spatele acestor query-uri este Serverless SQL Warehouse. Un SQL warehouse este pur și simplu o resursă de compute configurată special pentru SQL workloads. În arhitecturile mai vechi, trebuia să provizionezi manual clustere, să configurezi reguli de scaling și să aștepți câteva minute ca mașinile virtuale să booteze înainte să rulezi un query. Aici e ideea cheie. Pentru că aceste SQL warehouses sunt serverless, layer-ul de compute pornește aproape instantaneu. Face scale out automat atunci când analiștii tăi declanșează workloads concurente intense și se închide singur când query-urile se termină. Managementul infrastructurii este complet abstractizat, lăsându-i pe analiști să se concentreze exclusiv pe datele lor. Pentru a scrie și executa aceste query-uri, platforma oferă un editor SQL built-in. Asta e interfața principală pentru explorarea datelor. În editor, utilizatorii pot scrie SQL standard, pot naviga prin data catalogs, pot examina schemele tabelelor și pot vedea istoricul de execuție. Când un query returnează date, analistul nu trebuie să le exporte pentru a le înțelege. Pot construi vizualizări direct în editor și le pot aranja în custom dashboards care se actualizează automat. Platforma include, de asemenea, un feature de alerting. Analiștii pot scrie un query care verifică o anumită metrică și pot configura sistemul să trimită un email sau o notificare web dacă acea metrică depășește un threshold definit. Multe organizații au deja tool-uri de vizualizare consacrate. Databricks SQL se integrează direct cu tool-uri third-party standard, cum ar fi Power BI și Tableau. Aceste aplicații externe se conectează la Serverless SQL Warehouse și tratează data lake-ul exact ca pe o bază de date high-performance. Schimbarea aici ține fundamental de proximitatea față de datele tale. Aducând compute warehouse-grade și SQL standard direct în data lake, te oprești din copiat date și începi să-ți analizezi acel single source of truth în momentul în care datele ajung acolo. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Databricks, episodul 11 din 15. Dacă trei departamente diferite construiesc trei dashboard-uri diferite pentru a urmări veniturile și aduc trei cifre diferite la ședința executivă, nu ai o problemă de data pipeline. Ai o problemă de semantic layer. Soluția este stabilirea unui semantic layer ca o singură sursă de adevăr, iar în Databricks SQL, faci asta folosind Metric Views. Datele brute sunt rareori structurate așa cum gândesc utilizatorii de business. Tabelele din baza de date conțin nume de coloane obscure, join-uri complexe și log-uri de tranzacții brute. Un semantic layer acoperă acest decalaj traducând acele date subiacente în concepte de business familiare. Hai să ne uităm la un scenariu clasic în care treaba asta nu mai funcționează. Echipa ta de marketing și echipa ta de finanțe raportează ambele metrica de Monthly Active Users. Marketingul scrie un query în dashboard-ul lor care numără pe oricine a deschis aplicația. Finanțele scriu un query diferit într-un tool separat care numără doar utilizatorii care au finalizat o tranzacție. Ambele echipe își numesc metrica Monthly Active Users. Când numerele nu se potrivesc, încrederea organizației în date se prăbușește. Definirea Monthly Active Users ca un Metric View în Unity Catalog rezolvă asta pentru totdeauna. Ca să înțelegem de ce, trebuie să clarificăm ce este de fapt acest feature. Un Metric View nu este același lucru cu un SQL View standard. Un SQL View standard salvează pur și simplu un query care returnează rânduri și coloane brute, lăsând complet la latitudinea end user-ului să decidă cum să facă suma, media sau gruparea acelor date mai târziu. Un Metric View este mult mai strict. El impune calcule specifice de agregare și dimensionalitate direct la nivel de catalog. Când creezi un Metric View, blochezi exact logica de business. Definești măsura, cum ar fi un distinct count de user ID-uri pe baza unor criterii specifice de tranzacție. De asemenea, definești dimensiunile permise. Asta înseamnă că dictezi în mod explicit că această metrică poate fi segmentată doar după atribute specifice, cum ar fi data tranzacției, regiunea user-ului sau tipul de device. Aici e ideea cheie. Odată ce acel Metric View este publicat în Unity Catalog, devine singura definiție autorizată pentru Monthly Active Users din întreaga companie. Când analiștii se conectează la Databricks SQL, ei nu scriu logică custom pentru a agrega datele. Nu fac join între tabele și nu scriu clauze WHERE pentru a filtra stările active. Pur și simplu fac un query pe acel Metric View. Asta decuplează complet definiția metricii de presentation layer. Nu contează dacă Marketingul folosește Tableau, Finanțele folosesc Power BI, iar echipa de produs folosește dashboard-uri native Databricks. Tool-ul de business intelligence doar cere metrica, iar Databricks face calculul predefinit pe server side. Pentru că logica se află centralizat în Unity Catalog, este imposibil ca departamente diferite să își inventeze accidental propria matematică. Toate extrag exact același număr, asigurând o consistență perfectă în întreaga organizație. Adevărata putere a unui semantic layer nu este eficiența tehnică; este scoaterea logicii de business din tool-urile downstream deconectate și integrarea ei direct în fundația platformei de date. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și spor la construit!

Salut, sunt Alex de la DEV STORIES DOT EU. Databricks, episodul 12 din 15. Ce-ar fi dacă directorul tău de vânzări ar putea pur și simplu să dea un mesaj către data warehouse-ul tău pentru a obține instant business insights, fără să mai fie nevoie să deschidă un ticket la echipa de date? Request-urile ad-hoc de date întrerup constant workflow-urile de engineering, iar utilizatorii de business urăsc să aștepte zile întregi pentru un simplu query. Soluția la acest bottleneck este un feature Databricks numit Genie Spaces, care face parte din oferta lor mai largă de AI/BI. AI/BI este un produs de business intelligence construit pe un sistem compound AI. Este conceput pentru a înțelege semantica specifică a datelor tale. Genie Spaces funcționează ca interfață conversațională pentru acest sistem. Un Genie Space arată și se simte ca o aplicație de chat standard, dar este conectat direct la data warehouse-ul tău. Utilizatorii de business tastează întrebări în engleză simplă, iar Genie răspunde cu date reale, vizualizări și răspunsuri. Când oamenii aud despre un AI care face query-uri pe date, se îngrijorează imediat de halucinații. Ei presupun că modelul va ghici numele coloanelor, va inventa metrici sau va returna cu încredere răspunsuri greșite. Genie previne acest lucru bazându-se în întregime pe metadata guvernată stocată în Unity Catalog. Nu trimite un prompt orb către un language model generic. AI-ul este ancorat în schema ta reală, în data types, în relațiile de foreign key și în metricile predefinite pe care le-a stabilit echipa ta. Pentru ca asta să funcționeze, un analist creează și configurează mai întâi Genie Space-ul. El selectează dataset-urile relevante din Unity Catalog și oferă un set de instrucțiuni. Poate adăuga sample queries, poate defini terminologia specifică de business și poate clarifica termenii ambigui. De exemplu, îi poate spune sistemului că atunci când un utilizator spune „client activ”, se referă în mod specific la un client care a cumpărat ceva în ultimele nouăzeci de zile. Acest setup inițial limitează AI-ul la un domeniu bine definit. Când se pune o întrebare, sistemul orchestrează mai mulți pași. Citește prompt-ul în limbaj natural și verifică contextul furnizat. Potrivește intenția utilizatorului cu tabelele și coloanele exacte din catalog. Apoi generează un query SQL precis, rulează acel query pe compute engine-ul Databricks SQL și formatează rezultatele. Gândește-te la un manager de vânzări non-tehnic care folosește un Genie Space pregătit. El tastează: „Arată-mi vânzările în Europa per produs pentru ultimul trimestru”. Sistemul parsează request-ul pe baza antrenamentului său. Recunoaște „Europa” ca o dimensiune de regiune, localizează tabelele de produse și traduce „ultimul trimestru” într-un filtru de dată precis. În câteva secunde, AI-ul generează codul SQL, îl execută și returnează un chart interactiv care arată defalcarea. Dacă managerul răspunde apoi „Acum exclude Germania”, Genie modifică query-ul din spate și actualizează chart-ul instantaneu, menținând contextul conversațional. Acest workflow schimbă fundamental modul în care sunt gestionate request-urile ad-hoc. Data engineers și analiștii petrec o mare parte din săptămână scriind query-uri SQL one-off pentru stakeholders. Mutarea acestei explorări către Genie Spaces le oferă stakeholderilor de business răspunsuri imediate, eliberând în același timp timpul de engineering pentru task-uri complexe. În plus, întregul proces rămâne complet guvernat. Genie respectă cu strictețe toate regulile de access control la nivel de row și column definite în Unity Catalog. Dacă utilizatorul care pune întrebarea nu are permisiunea de a vedea date financiare sensibile, AI-ul pur și simplu nu va face query pe ele. Iată ideea principală. Eficacitatea explorării conversaționale a datelor este determinată de calitatea data model-ului și a metadata-ului din spate, nu doar de inteligența language model-ului. Asta e tot pentru acest episod. Mersi că m-ai ascultat și spor la construit!

Salut, sunt Alex de la DEV STORIES DOT EU. Databricks, episodul 13 din 15. Antrenarea unui model de machine learning este partea distractivă, dar deploy-ul lui ca un REST API securizat și cu high availability este punctul în care majoritatea proiectelor de data science mor. Trecerea de la un experiment într-un notebook la un endpoint production-ready necesită configurarea de scaling, load balancing și o guvernanță strictă. Pentru a rezolva asta, folosești Mosaic AI Model Serving. Acest feature oferă o interfață unificată pentru deploy, guvernanță și query pe modele AI. O concepție greșită comună este că Databricks Model Serving este doar pentru modelele pe care le antrenezi tu în interiorul Databricks. Asta este incorect. De fapt, acționează ca un AI Gateway central. Gestionează trei tipuri distincte de modele: modele custom, foundation models și modele externe. În primul rând, modelele custom. Acestea sunt modelele pe care le construiești, le faci log cu MLflow și le înregistrezi în Unity Catalog. Model Serving alocă un container serverless, încarcă dependențele modelului tău și expune modelul ca un REST API. Tu nu gestionezi infrastructura. Face scale up când traficul are un spike și face scale down la zero când este idle. În al doilea rând, foundation models găzduite de Databricks. Acestea sunt modele open-source mari pe care Databricks le găzduiește pe compute optimizat. Ai acces instant la arhitecturi state-of-the-art fără să îți faci griji de provisioning de GPU. În al treilea rând, modele externe. Aici configurezi endpoint-uri care pointează către servicii third-party. De ce să rutezi traficul extern prin Databricks în loc să apelezi direct providerii externi? Gândește-te la guvernanță și la controlul costurilor. Să presupunem că firma ta vrea să folosească GPT-4 pentru o aplicație internă. Dacă fiecare developer face hardcode la un API key în scriptul lui, pierzi vizibilitatea. Nu poți monitoriza strict costurile, nu poți gestiona rate limits și nu poți aplica filtre pentru a împiedica angajații să trimită date sensibile ale clienților către un provider extern. Rutând toate request-urile prin Mosaic AI Model Serving, forțezi acel trafic printr-un singur gateway securizat. Gestionezi un singur set de credentials. Aplici access controls prin Unity Catalog, dictând exact cine sau ce poate face query pe model. De asemenea, ai tracking centralizat pentru usage, erori și latență. Fluxul logic este simplu. Definești un serving endpoint în Databricks. Pentru un model custom, pointezi endpoint-ul către un model MLflow înregistrat și definești dimensiunea de compute și scaling limits. Databricks gestionează automat containerizarea. Pentru un model extern, furnizezi numele providerului extern și un API key stocat în siguranță. Odată ce endpoint-ul este activ, aplicațiile tale downstream trimit un payload JSON standard printr-un HTTP request către URL-ul endpoint-ului. Răspunsul se întoarce într-un format consistent, indiferent dacă modelul rulează pe compute serverless în Databricks sau stă într-un data center extern. Iată ideea principală. Mosaic AI Model Serving elimină fricțiunea de deploy, asigurând în același timp securitatea. Îți standardizează application layer-ul, astfel încât client code-ul tău comunică doar cu un singur endpoint Databricks, complet abstractizat de locul sau modul în care este găzduit modelul din spate. Apropo, dacă vrei să ajuți la susținerea emisiunii, poți căuta DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Mulțumesc pentru audiție și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Databricks, episodul 14 din 15. Ai zece mii de log-uri brute de customer support într-un tabel din baza de date, iar business-ul are nevoie de ele sumarizate și categorisite după sentiment până la sfârșitul zilei. În mod normal, extragerea acestui tip de insight-uri necesită un pipeline Python complex, o gestionare atentă de API keys și o logică custom de batching pentru a trimite textul într-un Large Language Model. Cum ar fi dacă ai putea executa tot acest workload folosind o simplă comandă de bază de date? Asta e exact problema rezolvată de AI Functions, care integrează LLM-uri direct în query-urile tale SQL. AI Functions fac o punte între Generative AI de ultimă generație și data analytics-ul de zi cu zi. Ele iau o capabilitate care necesită de obicei machine learning engineering specializat și o oferă oricui știe să scrie SQL. În loc să construiești o infrastructură separată pentru a extrage datele, a le trimite către un model și a scrie predicțiile înapoi, AI Functions aduc modelul direct acolo unde se află deja datele. Tool-ul principal pentru asta este o comandă built-in numită AI query. O folosești exact ca pe o funcție standard de procesare a textului în cadrul unui select statement. Specifici numele de endpoint al modelului pe care vrei să-l folosești, iar apoi introduci promptul. Revenind la acele zece mii de log-uri de suport, workflow-ul tău devine banal. Scrii un query prin care selectezi customer ID-ul și textul din log. Apoi, adaugi o coloană nouă folosind funcția AI query. Promptul tău îi spune modelului să citească textul, să extragă plângerea principală și să determine dacă sentimentul este pozitiv, neutru sau negativ. Pasezi coloana care conține textul brut din log în acel prompt. Când rulezi query-ul, motorul bazei de date distribuie automat acest request. Procesează fiecare rând prin Large Language Model-ul specificat. Modelul evaluează textul și returnează sumarul și sentimentul. Pentru că toate astea se întâmplă în SQL, output-ul vine sub formă de coloane structurate standard. Poți filtra imediat rezultatele pentru a afișa doar sentimentul negativ, poți face un join între aceste rezultate și un tabel de customer billing și poți agrega datele pentru a afla ce produs provoacă cea mai mare frustrare. Aici este insight-ul cheie. Ai putea presupune că a oferi acces data analiștilor la Large Language Models înseamnă să distribui API keys sensibile în întreaga organizație. Nu e așa. AI Functions sunt strâns integrate cu Databricks Model Serving. Conexiunile propriu-zise la modele externe, sau la modele open-source self-hosted, sunt configurate de administratori la nivel de platformă. Data analyst-ul nu vede niciodată un API key, un token sau un secret. El face referire doar la numele de endpoint preconfigurat în query-ul lui. Întreaga operațiune rămâne complet securizată. Fiecare query este logat, iar toate controalele de acces aplicate datelor și modelelor sunt strict impuse de framework-ul de guvernanță al platformei. Prin eliminarea fricțiunii de infrastructură și a credential management-ului, schimbi natura explorării datelor. Transformi analiza complexă de text nestructurat într-o simplă operațiune de filtrare, upgradând instant puterea analitică a întregii tale echipe. Mulțumesc pentru audiție. Aveți grijă de voi, tuturor.

Salut, sunt Alex de la DEV STORIES DOT EU. Databricks, episodul 15 din 15. Chatbot-ul tău standard este politicos, informativ și complet pasiv. Îți poate spune cum să repari un pipeline defect pe baza unui manual, dar nu poate de fapt să repare acel pipeline în locul tău. Trecerea de la un AI care doar vorbește la un AI care execută activ task-uri necesită o schimbare fundamentală de arhitectură. Această schimbare este AI Agent Framework. Să clarificăm imediat o confuzie frecventă. Lumea confundă adesea aplicațiile simple de tip Retrieval-Augmented Generation cu agenții adevărați. O aplicație RAG este în esență un motor de căutare cu un language model deasupra. Extrage documente și le rezumă. Doar citește. Un AI Agent adevărat are tool-uri. Poate să scrie. Poate rula query-uri SQL, poate da trigger la job-uri și poate apela API-uri externe. Schimbă starea sistemelor tale. Databricks Agent Framework oferă infrastructura pentru a construi, evalua și face deploy la acești agenți autonomi, în siguranță, în cadrul Lakehouse-ului. Mecanismul de bază aici este tool calling, combinat cu multi-step reasoning. În loc să genereze un răspuns dintr-o singură trecere, language model-ul acționează ca un reasoning engine. Îi oferi un obiectiv și un set de tool-uri, care sunt practic funcții pe care tu le-ai definit. Agentul decide ce tool să folosească, așteaptă rezultatul și apoi decide ce să facă mai departe. Gândește-te la un agent conceput să monitorizeze data pipelines. Când apare o eroare, agentul nu stă pur și simplu degeaba așteptând un prompt de la utilizator. Framework-ul îi permite să dea trigger unui workflow. În primul rând, agentul are nevoie de context. Folosește un custom tool pe care i l-ai furnizat pentru a rula un query SQL pe log-urile de sistem din Databricks. Framework-ul execută acest query și trimite rezultatul înapoi agentului. Aici este ideea principală. Agentul evaluează acele log-uri, identifică root cause-ul erorii și apoi trece la pasul următor. Își dă seama că echipa de engineering trebuie să afle. Așa că selectează un alt tool, o integrare API cu aplicația de chat a companiei tale. Apelează acel tool pentru a redacta și trimite un mesaj care detaliază eroarea exactă și fix-ul propus. Asta înseamnă multi-step reasoning în acțiune. Agentul a planificat o secvență, a executat cod, a observat rezultatul și a comunicat concluzia, totul în mod autonom. Să oferi unui language model capacitatea de a executa query-uri și de a da trigger la API-uri reprezintă un risc masiv de securitate dacă nu este gestionat corect. De aceea, abordarea Databricks cuplează strâns Agent Framework cu Unity Catalog. Când faci deploy la un agent folosind Databricks Model Serving, nu îi dai acces general la infrastructura ta. Îți înregistrezi tool-urile ca funcții specifice în cadrul Unity Catalog. Unity Catalog impune o guvernanță strictă asupra a ceea ce pot face aceste funcții. Dacă îi dai unui agent un tool pentru a rula query-uri pe tabelele de log-uri, Unity Catalog se asigură că poate citi doar acele tabele specifice. Dacă language model-ul are halucinații și încearcă să folosească tool-ul SQL pentru a da drop la o bază de date de producție, framework-ul îl oprește, deoarece funcția din spate nu are permisiunile necesare. Agentul este strict limitat de regulile de guvernanță ale Lakehouse-ului tău. Această capacitate transformă Lakehouse-ul dintr-un storage layer pasiv într-un mediu activ, automatizat. Acum că încheiem această serie, te încurajez să consulți documentația oficială și să încerci să construiești tu însuți un agent simplu de tool calling. Dacă vrei să sugerezi subiecte pentru următoarea noastră serie, intră pe devstories dot eu. Tranziția de la chatbots la agenți este schimbarea definitorie în modul în care construim aplicații AI astăzi. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!