Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=3XscYNAA2sk
[$] Custom page-cache policies with BPF
Post Syndicated from corbet original https://lwn.net/Articles/1073103/
The kernel’s page cache is charged with maintaining pages (or, more
correctly, folios) containing copies of
data from files in the filesystem; its performance has a big effect on the
performance of the system as a whole. One of the key decisions the kernel
must make is when to evict folios from the page cache. At the 2026 Linux Storage,
Filesystem, Memory Management, and BPF Summit, Tal Zussman ran a
memory-management-track session on how the page cache could be better
customized for specific workloads. It will not be much of a spoiler to say
that it involves BPF.
CISA Security Leak
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/05/cisa-security-leak.html
Crazy story:
Until this past weekend, a contractor for the Cybersecurity & Infrastructure Security Agency (CISA) maintained a public GitHub repository that exposed credentials to several highly privileged AWS GovCloud accounts and a large number of internal CISA systems. Security experts said the public archive included files detailing how CISA builds, tests and deploys software internally, and that it represents one of the most egregious government data leaks in recent history.
News article.
[$] Toward better handling of major page faults
Post Syndicated from corbet original https://lwn.net/Articles/1073071/
A major page fault occurs when a process attempts to access a page that is
not currently present in RAM; satisfying such faults usually involves I/O, and can thus take some time. When many threads
sharing an address space are generating page faults, the result can be
significant lock contention while that I/O
takes place. During the memory-management track at the 2026 Linux Storage,
Filesystem, Memory Management, and BPF Summit, Barry Song led a session
to try, yet again, to find an enduring solution to this problem.
Security updates for Friday
Post Syndicated from corbet original https://lwn.net/Articles/1074040/
Security updates have been issued by AlmaLinux (firefox), Debian (chromium, nss, openvpn, and thunderbird), Fedora (cockpit, kernel, and linux-firmware), Oracle (gdk-pixbuf2, kernel, and libsndfile), SUSE (container-suseconnect, cpp-httplib, dnsmasq, firefox, glibc, GraphicsMagick, java-1_8_0-openj9, kernel, mozjs115, php8, python-urllib3, rekor, rootlesskit, rsync, tiff, ucode-intel, util-linux, and xz), and Ubuntu (bind9, bubblewrap, libarchive, linux-intel-iot-realtime, postgresql-14, postgresql-16, postgresql-17, postgresql-18, and xdg-desktop-portal).
Как се дресира опозиция
Post Syndicated from Емилия Милчева original https://www.toest.bg/kak-se-dresira-opozitsiya/
Най-сетне, 20 години след създаването си, ГЕРБ има шанса да бъде истинска опозиция. Но нито иска, нито знае как. Групата от 39 депутати на партията на Бойко Борисов и коалиционният ѝ придатък СДС е най-малката в парламентарната история на „Граждани за европейско развитие на България“.
Могъществото на Румен Радев и неговата „Прогресивна България“ (ПБ) е потискащо за Борисов. Но проблемът на партията е по-дълбок от едно смачкано его, било то и лидерско. ГЕРБ така и не се научи да бъде опозиция, защото никога истински не е била извън управлението.
Дори когато не управлява пряко, ГЕРБ остава вградена във властта – монополист е в местното управление, с влияние в регулатори и съдебна власт. Партия, свикнала да бъде част от държавата, трудно влиза в ролята на неин коректив.
За ГЕРБ опозицията никога не е била политическа идентичност, а временен режим.
Ако човек не знае, че в 52-рия парламент има парламентарна група на ГЕРБ–СДС, трудно би го разбрал по поведението ѝ. Новото мнозинство управлява по начин, болезнено познат от годините на Борисов – с концентрация на власт около премиера и автоматизирано парламентарно мнозинство. Само че ГЕРБ изглежда необичайно кротка.
Така моделът оцелява дори когато участниците в него се сменят.
А Румен Радев не просто се възползва от слабостта на ГЕРБ. Той случи и на раздробена и снишена опозиция, чийто общ сбор народни представители е по-малък от неговите 131 депутати.
Команда „Равнис!“ смени вятъра на промяната
След новата власт тръгна цялата държава в строй – прокурори се оттеглят, бизнесмени сменят роли, охрани падат, институции внезапно проработват, а доскорошни врагове козируват в синхрон. Само цените отказват да се подчинят на командата „Равнис!“. Там ще е първият тест. Коментар на Емилия Милчева.
Емилия Милчева
Изобщо, изборите произведоха странна картина в 52-рия парламент – комфортно мнозинство срещу едновременно шумна и немощна опозиция. Именно ГЕРБ–СДС и ДПС („Ново начало“) – партиите на модела, срещу който бяха последните големи протести – днес са особено кон-струк-тив-ни.
Консолидиране на властта
ДПС продължава с тактиката публичните говорители да са предимно жени, а Атидже Вели очевидно влиза в тази роля. Партията демонстрира готовност за ситуативни мнозинства и внимателно избягва челни сблъсъци с новата власт.
Самият Пеевски е минал в режим на дистанционно управление през Facebook постове. Борисов пък все повече заприличва на разказвач за доброто старо време пред партийния актив и е с интонацията на човек, който още не може да приеме, че губи властта – след държавната охрана.
Новата власт вече подменя втория управленски ешелон с ускорени темпове. Сред сменените изпъкват шефовете на митниците, ДАНС, БЕХ, АЕЦ „Козлодуй“. Любопитното е, че точно в енергетиката някои ключови фигури остават непокътнати – като изпълнителните директори на „Булгартрансгаз“ и „Булгаргаз“ Владимир Малинов, свързван с разширението на газохранилището „Чирен“ и неизгодния договор с „Боташ“, и Веселин Синабов.
Новината обаче е, че енергийната министърка Ива Петрова ще преговаря по условията на 13-годишната сделка с „Боташ“, която носи огромни загуби за България и беше сключена от служебен кабинет на Радев като президент. България не плаща дължимите по нея 500 000 долара на ден за достъп до втечнен газ от Турция, който не използва, защото е много скъп.
Показателен за стила на новото управление е случаят с особения управител на активите на „Лукойл“ в България Румен Спецов. Скоро ще се разбере дали назначеният на 14 ноември 2025 г. бивш директор на НАП ще бъде сменен, за което съобщиха най-напред депутати от ПБ.
Със законови промени управляващите обаче ограничават правомощията на особения управител, а контролът върху действията му се премества от парламента към изпълнителната власт. Временната бюджетна комисия реши той да се отчита всеки месец пред министъра на икономиката вместо пред парламентарната Комисия по икономика.
Най-сетне ще бъде наложен съдебен контрол върху действията на особения управител, тъй като в момента те са необжалваеми. Поправките предвиждат финансови задължения извън обичайното управление да бъдат нищожни, ако не са предварително одобрени от Министерския съвет. Ограничават се и разпоредителните сделки с акции и дялове без пазарна оценка и разрешение от правителството.
Освен срещу дружеството, искове ще могат да се предявяват и срещу държавата и особения търговски управител, за да се осигури защита… на интересите на държавата. Появиха се обаче съмнения, че така се улесняват руските собственици, които вече заплашиха с арбитражен иск България.
В същото време кабинетът превръща мерките за контрол на цените в една от основните си публични кампании въпреки съмнителния им ефект и не бърза да вади скелети от гардеробите на предишните правителства. Макар че такива са обещани след проверките на цялостното състояние на министерствата.
Пирамидата
Абсолютното мнозинство на „Прогресивна България“ пренарежда властовия модел и предлага централизиран контрол с бързи решения и по всяка вероятност слаб отпор. Кой с какви заявки влиза в 52-рия парламент? От Емилия Милчева.
Емилия Милчева
Вицепремиерът и министър на финансите Гълъб Донев говори за икономии, но те се оказват политически селективни. Идеята е да спрат автоматичните увеличения на заплатите и да се орежат с 10% разходите в публичния сектор. Но армията, МВР, службите, Националната служба за охрана, учителите и лекарите остават защитени. Вдига се и максималният осигурителен доход – на 2300 евро.
Обещани са съкращения на незаетите 5729 бройки в държавната администрация. Броят им е константен от няколко години и благодарение на него на всеки 3 месеца се раздават „допълнителни материални стимули“.
Лимит за опозицията
Правителството се опитва да овладее растящите разходи, включително като изземва 100-процентово дивидента на държавните дружества – практика, въведена от Асен Василев през 2023 г. В парламента депутатите на ПБ осигуряват на правителството и нещо не по-малко важно – репутационен комфорт.
Правилникът за работа на 52-рото Народно събрание е променен така, че министрите могат да се измъкват от парламентарен контрол колкото пъти поискат. Премахнат беше досегашният им лимит за максимум две отсъствия, както и задължението им да дават лични обяснения при отговори, забавени до 10 дни.
Този замисъл е продиктуван от тактически съображения: голямата група на „Прогресивна България“ е пълна с нови депутати, които тепърва навлизат в парламентарната рутина. Колкото по-строго е режисиран процесът, толкова по-малък е рискът от неприятни изненади.
Затова и Правилникът започва да прилича на инструмент за управление на „другите“ – чрез ограничаване на изказванията, времето за реакции и възможностите за временни комисии. Някои от тези ограничения са разумни, защото намаляват процедурните хватки.
Срещу ограничаването на възможностите за парламентарен контрол този път възразиха и от ГЕРБ, освен от ДБ, ПП и „Възраждане“. ДПС отново бяха въздържани.
По идея на ПБ председателят на парламента ще предлага точки в дневния ред, без да са консултирани на председателски съвет. Eдна от най-сериозните промени е свързана с временните комисии. За създаването им вече ще са нужни 48 депутати – брой, с който не разполага нито една опозиционна формация сама по себе си.
Прагът е същият като за вот на недоверие или сезиране на Конституционния съд. ГЕРБ–СДС разполагат с 39 депутати, ДБ – с 25, ДПС наброяват 21, ПП – 12, „Възраждане“ са представени също с 12 депутати. Ако някоя от опозиционните парламентарни групи настоява за временна комисия, ще се наложи да преговаря с останалите.
Ако темата е значима, то тя трябва да намери изражение в по-голямо мнозинство.
Петър Витанов, председател на ПГ на „Прогресивна България“
Парламентът не е просто място, в което мнозинството само преброява гласовете си. То е мястото, където властта трябва да бъде питана и да дава отговори. Ако тук няма реален контрол, демокрацията се изпразва от съдържание.
Надежда Йорданова, съпредседателка на ПГ на „Демократична България“
Дори Бойко Борисов и Делян Пеевски не са се опитвали да ограничат така правата на опозицията.
Николай Денков, председател на ПГ на „Продължаваме промяната“
Всяка първа сряда от месеца, когато е денят на опозицията и се правят предложения за дневен ред, няма да се изслушват министри. Така излиза, че министрите ще се явяват предимно когато собственото им мнозинство „прецени“. Или когато е медийно комфортно.
Всичко това може да изглежда процедурно. Но всъщност парламентът постепенно се пренастройва така, че да създава по-малко шум, по-малко риск и по-малко неудобства за мнозинството. Неслучайно дори времето за запознаване със законопроектите беше орязано от 72 на 24 часа.
Същинският проблем
Истинският проблем не е, че опозицията е слаба. А че е раздробена и неспособна да произведе усещане за алтернатива. Това оставя управлението на Румен Радев почти без сериозен политически натиск – освен ако не се самовзриви.
А механизмите за обещаното от Радев разграждане на олигархичния модел все още изглеждат неясни. Дали ще има реален демонтаж на тази система, тепърва ще се вижда в съдебната власт и в новите антикорупционни механизми.
Радев, ще удряш ли с юмрука?
Абсолютното мнозинство дава възможност за бързи решения без оправдания. Първият тест е кадровият – ВСС, главен прокурор, регулатори. От него ще се види към обещаната промяна ли се върви, или „юмрукът“ ще пренарежда същата система с други лица. От Емилия Милчева.
Емилия Милчева
Както се разбра тази седмица, вот за нов състав на Висшия съдебен съвет от професионалната квота ще има в края на октомври. Първи тест ще бъде формирането на новата антикорупционна комисия, след като предишната беше закрита от парламента. За първо четене вече е одобрен законопроектът за новата комисия, подготвен от служебния правосъден министър Андрей Янкулов. Нейният състав ще е петчленен – с по един представител на парламента, Президентството, общите събрания на съдиите от върховните съдилища и на Висшия адвокатски съвет.
Именно при конструирането на бъдещата антикорупционна комисия ще стане ясно дали системата се променя, или просто сменя центъра на тежестта.
Когато властта се консолидира без особена съпротива, безалтернативността постепенно започва да изглежда естествена. И онзи вдигнат юмрук се превръща в новата нормалност.
Father of the Two Ocean Navy: Carl Vinson
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=LQ4FlrPEHds
На второ четене: „Мрак по пладне“
Post Syndicated from Стефан Иванов original https://www.toest.bg/na-vtoro-chetene-mrak-po-pladne/
„Мрак по пладне“ от Артур Кьостлер
превод от английски Алфред Криспин, София: изд. „Нике“, 2025
Романът е част от онези произведения, които демонтират самата възможност за история като последователен разказ. Той е едновременно политически роман, психологически трактат и нещо като философска аутопсия на ХХ век, извършена отвътре, с инструментите на самата идеология, която умира на масата.
Повечето романи за тоталитаризма разчитат на ужаса като движеща сила, на сцените на насилие и на документалния шок. Кьостлер избира друг път. Той кара читателя да мисли заедно с палача, което е много по-страшно, защото в определен момент логиката на палача започва да изглежда убедителна.
Още в първите страници се усеща една от ключовите черни иронии на текста. Тоталитаризмът функционира като прекалено добре подреден свят.
Разгръща се логическа система, стигнала до крайността си. Ужасът идва от самата завършеност на мисленето. Килията е чиста. Разпитите следват ритъма си. Дори екзекуцията е навреме. В света на романа насилието притежава формата на бюрократичен документ, който е подпечатан, заверен и архивиран. Точно тази тъй наречена нормалност прави нещата толкова непоносими. Злото тук има перфектна граматика.
Централният персонаж Рубашов е продукт на собствената си вяра. Неговият вътрешен разпад произтича от вътрешна логика много повече, отколкото от натиска на разпитите. Той приема вината си, защото е виновен в метафизичен смисъл. Поставил е абстрактното човечество над конкретния човек. Това е може би най-радикалната тема на романа. Разривът между идеята и тялото, между историята (с главно И) и човешкия живот като такъв. Рубашов е мислил, че може да реши уравнението на справедливостта с алгебрични средства и да изчисли по-малкото зло и да остойности страданието. В крайна сметка самият той се оказва в графата на допустимите загуби.
Тук заслужава внимание самият механизъм на „граматическата абстракция“ – термин, който Кьостлер въвежда чрез Рубашов. Азът като субект, като неделимо ядро, човекът като такъв, е фикция, която системата отказва да признае. Революцията говори в първо лице множествено число. Единственото число е ерес. Рубашов, затворен в килията, започва да усеща отново пулсирането на този забранен Аз като фантомна болка в ампутиран крайник. Връщането на субективността е последната форма на съпротива, макар закъсняла и безсилна.
В тази точка Кьостлер влиза в диалог с голямата традиция на европейската литературна мисъл. Ако при Достоевски вината е винаги лична и неотменима, вградена в самото тяло на човека, в неговата плът и молитва, то при Кьостлер тя е разтворена в колективното. При Кафка абсурдът идва от непрозрачността на властта, а тук извира от нейната прекомерна прозрачност. Всичко е логично, обяснимо и затова е и непоносимо. Това е анти-Кафка. Убива прекалено добре разбраният закон. Тук обвиняемият познава съдиите лично, пил е с тях, воювали са рамо до рамо.
Достоевски предлага на героите си изход през страданието или през вярата. Рубашов получава куршум в тила и никакъв метафизичен хоризонт отвъд него. Кьостлер пише в свят, от който Бог вече е евакуиран и на неговото място стои Партията. Божествено взискателна, абсолютна и без никакво обещание за спасение. Единственото трансцендентно, което остава, е „океанското усещане“, онова неясно, почти физиологично чувство за връзка с нещо по-голямо от себе си, което Рубашов изпитва в моменти на самота.
Паралелът с „1984“ на Джордж Оруел е почти неизбежен. При Оруел властта действа отвън и е брутална. Тя смазва, наблюдава и изтрива. При Кьостлер тя е интериоризирана и вградена в самия начин на мислене. Рубашов е съавтор на системата. Това прави трагедията му по-близка до античната. Той пада, защото е бил прекалено последователен в собствената си вяра. Оруел показва какво прави властта с тялото. Кьостлер показва какво се случва, когато умът доброволно ѝ се подчинява.
Има и друга, по-рядко коментирана разлика. Оруел описва система, в която лъжата е очевидна за всички. При Кьостлер системата функционира по-коварно, защото самата тя вярва в собствените си тези. Глеткин, вторият разпитващ, е искрено убеден в правотата на своите методи. Той представлява ново поколение хора, които никога не са познавали друга реалност и за които революцията е административен процес.
Пълното отсъствие на ирония е може би най-страшната форма на тоталитарно съзнание.
Един от най-смущаващите мотиви в романа е доброволното самопризнание. Това е философски парадокс. Човек се съгласява да бъде виновен, за да запази истинността на системата, в която е вярвал. В самопризнанието на Рубашов има нещо мъченическо, но обърнато наопаки. Рубашов умира, за да свидетелства за лъжата, в която е вярвал като в истина.
Тук си заслужава да се спрем и на Иванов, първия разпитващ, стария другар на Рубашов. Иванов е интелектуалният конформист, който е запазил достатъчно ирония, за да знае какво прави, и достатъчно цинизъм, за да продължи да го прави. Той е по-близък до Рубашов, отколкото и двамата биха искали да признаят, и точно затова системата го отстранява. В тоталитарния свят иронията е по-опасна от несъгласието. Ако не си съгласен, ще те смажат, но иронията е заразна и разяжда отвътре.
Ако направим крачка към съвременността, неудобството става по-голямо. Защото светът на романа се е трансформирал и не е изчезнал. Днес живеем в епоха, в която идеологиите са по-малко монолитни, но механизмите на самооправдание са също толкова ефективни. Днес липсва нужда от централен „Първи“, защото алгоритмите, социалните мрежи, икономиката и медийните екосистеми вършат сходна работа – по-меко, по-разсеяно и уж по-демократично.
Тоталитарната логика при Кьостлер е имала поне тежестта на трагедията и мащабът на жертвата е бил съизмерим с мащаба на вярата. Съвременният еквивалент има по-скоро текстурата на мека зависимост. Човек се отказва от малки порции автономия ежедневно и незабележимо. В замяна получава удобство, принадлежност и ценностна ориентация. Никой не те води на разпит, не е нужно, нужното се чува и чете. Алгоритъмът знае какво искаш, преди ти самият да го знаеш. Романът днес може да се мисли и като предупреждение за начина, по който се формира съгласието. За пътя до онази точка, в която доброволното престава да бъде наистина доброволно.
В днешна България паралелът е особено деликатен. Ние живеем сред остатъчни структури на мислене. Подозрителността, склонността към конспиративни обяснения, недоверието към институциите, вярата в месии (списъкът може да се допълва) – всичко това е като слаб радиационен фон от един отминал и неприключил съвсем свят. Рубашов е интелектуалец, който твърде дълго е оправдавал компромисите си с по-голямата цел. В българския контекст тази фигура е архетипна. Такива са както участниците в изграждането на социалистическата държава, така и съвременните уж реалполитици, които обясняват всеки компромис с прагматизъм.
Ако при Кьостлер героите умират за идеята, днес по-често биха я разменили за нещо с по-широко валутно обращение. Ако тоталитаризмът е бил трагедия, посттоталитарното общество понякога прилича на фарс с елементи на черен хумор, който ти засяда в гърлото. Вацлав Хавел е описал точно тази трансформация. „Животът в лъжа“ е ежедневие, от което е изтекъл целият драматичен заряд и е останала само инерцията. Кьостлер описва света, в който хората умират за абсурда. Хавел разказва за света, в който хората живеят с него, без дори да го забелязват. Днес сме някъде по средата.
Стилът на Кьостлер е сух, аскетичен, лишен от излишна литературна тлъстина и това усилва усещането за безизходица. Отсъства всякакъв лиризъм и опит за утеха. Прозата е оголена до кост. Всяка дума е под подозрение и може би точно в това се съдържа скритата тема на романа.
В тоталитарния свят самият език е развален и заразен.
В крайна сметка това е роман за опасността от всяка идея, която претендира за абсолютна валидност. Най-страшното е, че системата в някакъв перверзен, абсурден и изкривен смисъл може да убеди всеки в правотата си. Точно там, в тази пукнатина между правота и човечност, се ражда истинският мрак по пладне. И този мрак има една особена характеристика. Той е невидим за онези, които стоят в самия му център. Те мислят, че виждат ясно. Те вярват фанатично, че светлината е силна и логиката е безупречна. Мракът по пладне е слепота от яркост.
Никой от нас не чете единствено най-новите книги. Тогава защо само за тях се пише? „На второ четене“ е рубрика, в която отваряме списъците с книги, публикувани преди поне година, четем ги и препоръчваме любимите си от тях. За нея медията „Тоест“ е отличена с Националната награда „Христо Г. Данов“ (2025) за принос в представянето на българската книга.
Рубриката е част от партньорската програма Читателски клуб „Тоест“, благодарение на която активните дарители на „Тоест“ получават 20% отстъпка от коричната цена на всички книги на включените издателства. Изборът на заглавия обаче е единствено на авторите Стефан Иванов, Севда Семер и Антония Апостолова, които биха ви препоръчали тези книги и ако имаше как да се разходите с тях в книжарницата.
Equal1 Single Rack Quantum Computer at Dell Tech World 2026
Post Syndicated from Patrick Kennedy original https://www.servethehome.com/equal1-single-rack-quantum-computer-at-dell-tech-world-2026/
At Dell Tech World 2026, we saw an Equal1 single rack quantum computer that allows quantum deployment in standard data center racks
The post Equal1 Single Rack Quantum Computer at Dell Tech World 2026 appeared first on ServeTheHome.
The Hugo evolution: Engineering Grab’s unified, one-click data ingestion platform with Apache Flink
Post Syndicated from Grab Tech original https://engineering.grab.com/one-click-data-ingestion-platform-with-apache-flink
Introduction
Data drives every decision we make at Grab. As our operations scale, so does our need for robust, real-time data ingestion and processing frameworks. Enter Hugo: our self-service data platform that has long empowered teams to seamlessly route data into our Data Lake. Today, Hugo is evolving. We have taken previously siloed onboarding workflows and transformed them into one seamless, unified journey to truly democratize data ingestion and maximize efficiency.
In this blog, we’ll share how Hugo turns complex engineering hurdles into a frictionless, self-service reality. By moving away from siloed workflows, we’ve achieved a unified pipeline experience where one-click RDS CDC and self-service Kafka ingestion are the new standard.
Background
Hugo was originally designed as a self-service platform for batch-oriented data ingestion into the Data Lake, built on a single computation engine, Spark. It provided a centralized and streamlined onboarding experience for data sources such as MySQL, Aurora, PostgreSQL, and DynamoDB.
As the organization’s data platform evolved toward near real-time ingestion, Hugo expanded to support streaming pipelines from Kafka and MySQL binlog. This evolution introduced a more distributed architecture, where ingestion workflows spanned multiple systems, including Kafka Connect, Sprinkler (an in-house Go-based S3 writer), and Hugo.
The siloed past: A multi-platform hurdle
While powerful, the expanded architecture introduced significant onboarding friction. Creating a single data pipeline now requires users to coordinate across multiple platforms, each with its own configuration model and operational semantics. As a result, the onboarding journey became fragmented and difficult to navigate, especially for new users.
The common challenge during onboarding was helping users understand how configurations mapped across systems.
For MySQL CDC pipelines, users often asked, “I’ve already configured Kafka Connect, what values do I need to provide in Hugo?” after setting up a Kafka Connect job. This revealed a gap in abstraction between systems, requiring users to manually translate concepts and configurations across different platforms.
For Kafka pipelines, users frequently struggled with schema evolution in the data lake. Common questions included: “How should I update the data lake schema?” and “I’ve already updated the Protobuf schema for this Kafka topic, why isn’t the latest schema reflected in the data lake?” These issues highlighted unclear expectations around schema propagation and synchronization across the pipeline.
This multi-step, cross-system dependency increased cognitive load, slowed down onboarding, and created coordination overhead between platform teams and users.
The Hugo evolution: A unified ingestion platform
Hugo’s new, deeply automated ingestion framework, built with a custom automation layer and Apache Flink, has unified workflows and retired Sprinkler and Kafka Connect. This evolution converted manual, artisanal work into a streamlined, self-service experience, with custom automation serving as the “intelligent chassis” for the entire user journey.
The Hugo ingestion architecture: Engineering a unified flow
One-click MySQL CDC pipelines
The transition to a unified modernized pipeline powered by Flink CDC shifts the data ingestion architecture from a fragmented, high-maintenance toolchain into a single, end-to-end orchestrated platform. By reading the database binlog directly and embedding the lifecycle within a centralized control plane, the modernized approach drastically reduces operational overhead, eliminates data mismatch risks, and cuts onboarding times from days to minutes. Below are the core advantages of adopting Flink:
- Minimal operational overhead: It reduces the footprint from 4 disparate components (Kafka Connect, topics, Sprinkler app, and Spark) to just 2 core components managed via a single control plane.
- Eliminated schema risk: It replaces brittle, manually coded Go DTOs, which caused frequent schema deviations, with automated schema detection and dynamic validation.
- Streamlined architecture: It eliminates the intermediary Kafka hop. Flink reads the MySQL binlog directly and pushes straight to a queryable Hive table via an integrated Spark compaction process.
- Instant onboarding: It shifts deployment from a multi-team, ticket-heavy process taking days to a single-engineer, self-service setup completed in minutes.
Self-service Kafka ingestion
The most significant architectural shift in the self-service Kafka ingestion pipeline is the move from manual, fragile schema handling to an automated, resilient system. This comparison highlights the operational pain points eliminated by adopting Flink’s approach.
Legacy Sprinkler approach (manual and static)
- Static registration and hardcoding: It required manual registration of streams within the Go monorepo and relied on hardcoded mappings in
entities.goto convert Protobuf to Avro. - Custom dependencies: Avro schema was generated indirectly from custom DTO structs, not directly from the Protobuf definition.
- Manual schema evolution: Any field change required a multi-step manual process: updating
.pb.goand entity files, followed by a manual pipeline rebuild.
New Flink approach (automated and dynamic)
- Dynamic runtime fetching: Flink pipelines dynamically retrieve the Protobuf schema from Confluent Schema Registry on startup, removing the need for hardcoding and manual stream registration.
- Reduced operational overhead for schema changes: Schema updates are propagated through the CI pipeline to the Schema Registry, removing the need for hardcoded mapping changes. The Flink pipeline can detect updated schemas and resume from the latest checkpoint after restart, though manual restart intervention is still required.
- Click-to-query: Engineers can now ingest streaming data from Kafka topics into queryable Hive tables through a few clicks in the Hugo UI. Hugo automatically orchestrates the multi-stage background work, from Flink consumption and S3 writing to Spark compaction, ensuring data is query-optimized and ready for immediate use.
Impact
The platform’s new onboarding workflow has significantly reduced a previously multi-day process to mere minutes, enabling faster iteration and improving overall onboarding efficiency. This dramatic change has fundamentally altered how our teams interact with data.
The onboarding workflow is intentionally designed with early validation guardrails to proactively surface prerequisite and governance-related issues before pipeline creation proceeds.
- For Kafka sources, user drop-offs between the “Create Kafka Source” and “Kafka Sink” stages are primarily driven by validation checks such as topic ownership verification and topic activity requirements, for example topics with zero message volume. Additional drop-offs between the “Kafka Sink” and “Create Source Pipeline” stages typically occur when the proposed output table name already exists in the data lake, preventing duplicate table creation.
- For MySQL sources, drop-offs are mainly associated with unmet database onboarding prerequisites, including credential setup, binlog user configuration, binlog format requirements, and binlog expiration settings.
In addition, the streamlined self-service experience encourages exploratory usage, allowing teams to familiarize themselves with the onboarding workflow and platform capabilities before fully committing to pipeline creation.
Summary
The new architecture engineered a custom automation layer that successfully retired the reliance on Kafka Connect and Sprinkler for the data lake, turning artisanal work into a streamlined, one-click experience. This transformation provides a direct boost to developer productivity.
The key impact metrics are:
- Onboarding time reduction: The time required to set up data pipelines has been dramatically reduced and is now measured in minutes.
- Kafka pipelines: approximately 6 minutes.
- MySQL CDC pipelines: approximately 3 minutes.
- Adoption: Since the release, the number of new Kafka and CDC pipelines onboarded in the last year is more than the total number of pipelines onboarded in the previous five years.
What’s next
These enhancements are just one step in our broader vision for optimized and self-service data ingestion. Currently, Flink is the default only for Kafka source pipelines. Flink onboarding for MySQL CDC pipelines is impact- and cost-driven. Our strategic roadmap includes:
- Next-generation formats: We are investigating the adoption of Apache Iceberg as the data lake table format to further improve pipeline SLA and costs, and improve performance.
- Seamless schema evolution: Schema changes still require some manual effort from pipeline owners, including manually restarting Flink pipelines. In Hugo, we aim to make schema evolution a zero-touch experience by automatically detecting changes, validating compatibility, and updating tables without disruption.
Join us
Grab is Southeast Asia’s leading superapp, serving over 900 cities across eight countries (Cambodia, Indonesia, Malaysia, Myanmar, the Philippines, Singapore, Thailand, and Vietnam). Through a single platform, millions of users access mobility, delivery, and digital financial services, including ride-hailing, food delivery, payments, lending, and digital banking via GXS Bank and GXBank. Founded in 2012, Grab’s mission is to drive Southeast Asia forward by creating economic empowerment for everyone while delivering sustainable financial performance and positive social impact.
Powered by technology and driven by heart, our mission is to drive Southeast Asia forward by creating economic empowerment for everyone. If this mission speaks to you, join our team today!
FINALLY! AMD GPU Acceleration in Project NOMAD (Plus Regional Map Downloads)
Post Syndicated from Crosstalk Solutions original https://www.youtube.com/watch?v=7c5bnvtZ8VY
Comic for 2026.05.22 – Language
Post Syndicated from Explosm.net original https://explosm.net/comics/language
New Cyanide and Happiness Comic
Neutrino Project
Post Syndicated from xkcd.com original https://xkcd.com/3249/
This Ebola Outbreak Will Be Hard to Contain
Post Syndicated from The Atlantic original https://www.youtube.com/shorts/O_71uQ8K9Ms
Vulnerabilities in various GTK-based PDF readers
Post Syndicated from corbet original https://lwn.net/Articles/1073944/
Michael Catanzaro has disclosed a
command-injection vulnerability affecting a number of GTK-based PDF
readers; exploits included:
They contain a script for building malicious polyglot PDFs that are
simultaneously both valid PDF files and also valid ELF
binaries. When the user opens the PDF in the PDF viewer and clicks
on a malicious link embedded in the PDF, the PDF abuses the command
injection vulnerability to load itself as a GTK module using the
`–gtk-module` command line flag. It can then execute arbitrary
code via its library constructor. That flag was removed in GTK 4,
which is why the vulnerability is much less serious for Papers than
it is for Evince, Atril, and Xreader.
2026-05-21 OpenFest 2026
Post Syndicated from Vasil Kolev original https://vasil.ludost.net/blog/?p=3527
Та, ще случваме OpenFest 2026. В Интерпред, 7-8 ноември 2026.
И около това има разни въпроси, дето се мотаят, и които не се отговарят толкова лесно по официалните канали, и може би им е тук мястото.
Има въпросът “защо чак ноември” от една група хора, които държат много да е в средата на октомври. Отговорът е сравнително прост – в нашата държава нищо не се случва до края на август, а септември хората полудяват да се занимават с училища и т.н.. Съответно, ако имаме събитие, което искаме да е в средата на октомври и неговата програма да е online поне месец, то тя трябва да е готова в средата на септември. Което значи, че последните предложения за лекции трябва да са дошли до първата седмица на септември, за да може програмния комитет във втората седмица да направи програмата.
Разбира се, и двете не се случват – лекторите се бавят, пращат в последния момент и са заети, програмния комитет не успява да се събере и т.н. и т.н.. Тук дори не обсъждам всичките други неща, дето имат да се подготвят за два месеца и нещо от хора, които това го правят в малкото си свободно време.
Има и въпросът “защо да го правим”. Тези дни трябваше да пиша нещо по темата, основно за да убеждавам малко спонсори, че има смисъл да ни спонсорират, и аз самият се замислих, защо изобщо го правим?
В последните години беше горе-долу ясно – фирмите имаха нужда от хора, хората идваха на OpenFest, виждаха там фирмите и се харесваха по някакъв начин. Сега обаче всички са се скатали по всякакви причини, някои уважителни (фалираха), някои не (“AI-то ще премахне нуждата от хора”), и всякакви по средата.
Това цялото е страничен ефект. Важността на едно такова независимо, общностно, свободно достъпно за всички събитие (и защо аз се занимавам, освен, че има забавни моменти в организирането) е на друго място.
Open-source технологиите всеки може да ги пипне, и да си играе с тях. Те са някакъв основен притегателен център на ентусиасти и хора, дето технологиите и всичко такова им е интересно, които се занимават с това и в свободното си време.
Това е и групата хора, отговорна за повечето пробиви и сериозни разработки. Зад голяма част от интересните неща, направени в България или доразработени тук, и изобщо реализирани стои по един или няколко от тези хора. В много фирми има някой, дето знае повечето неща, или към който се допитват, като нямат идея какво да направят, и поне в нашата държава повечето от тези хора са в тази група – на ентусиастите.
Същата тая група се разширява в общи линии като заразна болест – като има някакво количество от тези хора някъде на публично място (ако ще и да е само един), някакви други хора виждат, че тая нашата област е интересна и забавна, и се захващат и те.
Та, една от целите на OpenFest е била да даде място за срещане и изява на тази група. Като лектори, посетители, доброволци – всеки каквото му е на сърце.
(има около 400-500 човека, минали като доброволци през събитието по годините, и голяма част от тях след това отидоха да организират/правят неща, за които се научиха при нас, което винаги много ме е радвало)
(по същия начин, it турнето, дето се случва и което почнахме едно време, има за идея да направи същото, в по-малък мащаб, но из страната. Защото, като изключим Пловдив с TuxCon и едно време PlovDev, няма някой да се занимава с такива дейности.
Другото такова полезно място са hackerspace-овете, които обаче съвсем намаляха в последно време, и освен init Lab и VarnaLab, донякъде BurgasLab, не са останали. Те също са много важни, но за тях друг път)
Без тези събития и общностите, които се поддържат, съдбата на тая общност не е особено ясна. Няма да се изхвърлям и да казвам, че без нас общността ще умре, но определено няма да помогне. Може би аз съм в някаква такава странна позиция, но аз основно виждам как някакви по-малки групи се затварят и няма как да обменят идеи, няма някакви свестни дори online форми. За сметка на това конференции като FOSDEM (където участвам в организацията) и Chaos Communications Congress нямат възможност да съберат всички желаещи на едно място, и се вижда колко полезно е да се случват.
Та, тази година ще се случи. Не знам за следващата. Може пък да ни е дошло време да отмрем, знае ли човек 🙂
AWS KY3P report now available for third-party supplier due diligence
Post Syndicated from Michael Murphy original https://aws.amazon.com/blogs/security/aws-ky3p-report-now-available-for-third-party-supplier-due-diligence/
We’re excited to announce that Amazon Web Services (AWS) has completed the S&P Global Know Your Third Party (KY3P) assessment of its security posture. This assessment demonstrates our continued commitment to meet the heightened expectations of cloud service providers. Customers can now use the AWS KY3P assessment to reduce their supplier due diligence burden.
KY3P, also known as the S&P Global Comprehensive Assessment (formerly TruSight), is a validated, evidence-based assessment designed to support regulatory compliance and efficient, standardized risk data exchange between AWS and our clients. KY3P’s globally recognized methodology provides organizations with enhanced visibility into supply chain risks by validating the actual implementation and operation of controls – not just policies or attestations.
As cloud adoption accelerates across industries, AWS has become a critical component of customers’ third-party environments. Regulated customers, such as those in the financial services sector, are held to high standards by regulators and auditors when it comes to exercising effective due diligence on third parties.
To better manage risks from their evolving third-party environments and drive operational efficiencies, many customers rely on third-party risk management services such as KY3P. In support of these efforts, AWS has completed its annual KY3P security posture assessment, conducted by KY3P security assessors.
KY3P’s risk assessment methodology includes over 200 controls across 26 control categories and nine risk domains. These topics include Privacy, Network Management, Logical Access Management, and Physical and Environmental Security. The assessment criteria were developed by a consortium of leading financial institutions.
Customers can use the KY3P results to map AWS against commonly used industry frameworks and standards, such as NIST CSF v2, PCI DSS 4.0, and ISO 27001:2022 to instantly gain visibility into controls coverage.
For details on how to access the report, see our AWS KY3P assessment page.
If you have feedback about this post, submit comments in the Comments section below. To learn more about our other compliance and security programs, see AWS Compliance Programs.
Automate deployment of data and AI applications with Amazon SageMaker Unified Studio CI/CD CLI
Post Syndicated from Saurabh Bhutyani original https://aws.amazon.com/blogs/big-data/automate-deployment-of-data-and-ai-applications-with-amazon-sagemaker-unified-studio-ci-cd-cli/
Organizations building data and AI applications in Amazon SageMaker Unified Studio combine multiple AWS services, including AWS Glue, Amazon Athena, Amazon Managed Workflows for Apache Airflow (Amazon MWAA), Amazon SageMaker AI, and Amazon Quick Sight, into single applications. Promoting these applications from development to test and production stages requires substituting service-specific configurations for each stage and provisioning resources in the correct order.
Data teams understand which services their applications need but lack continuous integration and continuous delivery (CI/CD) expertise, while DevOps teams understand deployment automation but must learn each AWS service’s provisioning requirements.
The CI/CD CLI for Amazon SageMaker Unified Studio (aws-smus-cicd-cli) is an open source command line tool that automates deployment of multi-service data and AI applications across pipeline stages. Data teams define their application once in a YAML manifest, DevOps teams deploy with a single command, and the CLI handles configuration substitution, dependency ordering, and resource provisioning automatically. For details, see the CI/CD CLI documentation.
In this post, we walk through how the CI/CD CLI works, show you how to deploy a real application across environments, and demonstrate how it fits into your existing CI/CD workflows.
Customer spotlight
Bureau Veritas, a global leader in testing, inspection, and certification, operates across multiple SageMaker Unified Studio environments to support its data and AI teams. With their data and DevOps teams working on different parts of the application lifecycle, Bureau Veritas needed a controlled way to promote workloads from development through test to production while preserving clear ownership boundaries between the two teams.
“We need to promote data and AI applications across SageMaker Unified Studio environments in a controlled way that respects the boundaries between our data teams and our DevOps teams. The CI/CD CLI does exactly that — a single manifest from the data team, a single deploy command from DevOps, and full control over what goes to production.”
— Gilles Kempf, Architecture Manager, Bureau Veritas
How the CI/CD CLI works
The CI/CD CLI introduces a clean separation of concerns between data teams and DevOps teams.
Data teams define what to deploy in a declarative YAML manifest (manifest.yaml). The manifest describes the application’s resources, including AWS Glue extract, transform, and load (ETL) jobs, Athena queries, Airflow directed acyclic graphs (DAGs), Quick Sight dashboards, and SageMaker training jobs, along with stage-specific configurations for each environment.
DevOps teams define how and when to deploy using their existing CI/CD systems. They retain full control over their deployment methodology. They choose whether to promote content through git branches, a bundle artifactory, or both; they decide the shape of the pipeline, including which stages to include (dev, staging, pre-prod, prod) and which manual approvals or security gates are required. They run aws-smus-cicd-cli deploy inside GitHub Actions, Jenkins, or GitLab CI workflows without needing to understand which AWS services the application uses or how SageMaker Unified Studio projects are structured. The CLI is a utility for AWS analytics service deployment, not a CI/CD methodology. Your team’s existing conventions for branches, approvals, and pipeline shape stay exactly as they are.
The CLI is the abstraction layer between the two. It reads the manifest, substitutes stage-specific configurations (S3 paths, AWS Identity and Access Management (IAM) roles, account IDs, and connection strings), provisions resources in dependency order, and handles all AWS service interactions.The following diagram illustrates this separation:
Key concepts
Application manifest
Each stage maps to a dedicated SageMaker Unified Studio project. This one-stage-to-one-project mapping is the foundation of CI/CD isolation: each project has its own domain, IAM boundaries, connections, and data, so changes in dev can never affect prod. For stronger isolation, projects can span different AWS accounts and AWS Regions. For example, dev in a sandbox account and prod in a production account in a different Region. Because each stage is a real SageMaker Unified Studio project, teams can open it in the console at any time to observe workflows, inspect resources, and troubleshoot deployments. Project membership is managed per project, so you control exactly who has access to each stage. For example, developers in dev and a release team in prod.The manifest file is the single source of truth for your application. It declares:
- Content: application code from git repositories, data files from S3, Quick Sight dashboards, and workflow definitions.
- Stages: environment-specific project mappings (dev, test, prod, etc.), each isolated as described earlier.
- Configuration: stage-specific settings that are substituted automatically at deploy time.
Here is an example manifest for an analytics application with AWS Glue ETL and Quick Sight:
applicationName: SalesAnalyticsDashboard
Each stage must map to a separate SageMaker Unified Studio project, providing full isolation between environments. The CLI substitutes variables like ${AWS_ACCOUNT_ID} and ${AWS_REGION} at deploy time based on the target environment.
Bundles
A bundle is an immutable, versioned archive of your application. The bundle command reads from a source stage (typically dev) and packages the application code, workflow definitions, and resolved configurations into a self-contained artifact. The deploy command then applies that artifact to one or more target stages (test or prod).
This stage-to-bundle-to-stage promotion model supports controlled rollout through quality gates:
The same artifact is deployed at every stage without rebuilding, providing audit trails and reproducible deployments for regulated industries.
SageMaker Catalog integration
The CLI manages Amazon SageMaker Catalog resources as part of the deployment process. You can define catalog assets, glossaries, glossary terms, form types, asset types, and metadata forms, in your manifest. During deployment, the CLI searches for assets in the catalog, creates subscription requests for required data access, and waits for approval before proceeding. This automates the data governance workflow that teams previously handled manually.
CLI commands
The CI/CD CLI provides commands that cover the full deployment lifecycle:
| Command | Description |
| describe | Validates the manifest, checks that target projects exist, and confirms the execution role has required permissions. Use –connect to validate against live AWS environments. |
| bundle | Reads from a source stage and packages application code, workflow definitions, and configurations into an immutable, versioned archive. |
| deploy | Applies bundle contents to one or more target stages. Provisions resources in dependency order. |
| test | Runs post-deployment validation to confirm services are running and ready for workloads. |
| create | Generates a starter manifest from an existing SageMaker Unified Studio project. |
| run | Triggers Airflow workflow execution on MWAA or Airflow Serverless connections. |
| monitor | Monitors workflow execution status in real time. |
| logs | Fetches and streams workflow execution logs. |
| destroy | Removes deployed resources and projects for cleanup or failure recovery. |
Walkthrough: deploying a Quick Sight dashboard with AWS Glue ETL
In this section, we walk through deploying an analytics application that uses AWS Glue for ETL, Athena for queries, and Quick Sight for dashboards. This example is available in the GitHub repository.
Use case
An analytics team owns a Sales Analytics Dashboard built on AWS Glue ETL, Athena, and Quick Sight. They want to promote changes from a development environment to production with reproducible builds, automated validation, and a clear approval gate between stages, without writing custom deployment scripts or exposing data engineers to AWS provisioning details.
Solution overview
We use a sample application from the CI/CD CLI GitHub repository that includes AWS Glue ETL scripts, an Airflow workflow definition, a Quick Sight dashboard bundle, and integration tests. A single manifest.yaml describes the application and its dev and prod stages. The CLI handles the full lifecycle: bundle the app from dev, deploy it to test, run validation, and promote the same immutable artifact to prod.
Prerequisites
Before you begin, make sure you have the following:
- Python 3.8 or later.
- AWS credentials with permissions to deploy to your SageMaker Unified Studio projects. For details on configuring credentials, see Configuration and credential file settings in the AWS CLI.
- Existing SageMaker Unified Studio projects for your target stages.
Solution architecture
Each stage in the manifest maps to a dedicated SageMaker Unified Studio project (see the separation-of-concerns diagram in “How the CI/CD CLI works” earlier in this post). At deploy time, the CLI uploads ETL scripts and workflow definitions to the project’s S3 storage connection, provisions the Airflow workflow in MWAA Serverless, runs the workflow to create AWS Glue jobs and databases, and imports the Quick Sight dashboard. The same bundle artifact is applied to every downstream stage, ensuring dev, test, and prod stay in sync while remaining fully isolated.
Solution implementation
Step 1: Install the CLI
Install the CLI from PyPI:
Step 2: Create or customize a manifest
Clone the repository and start from the analytics example:
The example includes AWS Glue ETL scripts, an Airflow workflow definition, a Quick Sight dashboard bundle, and integration tests. Open manifest.yaml and update the project, domain, and deployment_configuration values under each stage so they match your own SageMaker Unified Studio projects and connection names.Alternatively, generate a manifest from an existing project: aws-smus-cicd-cli create --domain-id <your-domain-id> --dev-project-id <your-project-id>
Step 3: Validate your configuration
Run the describe command with --connect to verify your environment is ready. This connects to your AWS environment and validates that target projects exist, the execution role has the required permissions, and connections are reachable. Fix any issues before deploying.
Step 4: Deploy
Run the deployment:
- Uploads ETL scripts and workflow definitions to S3 using the project’s storage connection.
- Creates the Airflow workflow in MWAA Serverless.
- Runs the workflow, which provisions AWS Glue jobs, creates databases, and runs ETL transformations.
- Imports the Quick Sight dashboard and refreshes datasets with the latest data.
- Processes any catalog asset subscriptions defined in the manifest.
Step 5: Validate
Run post-deployment validation to confirm services are running and ready for workloads:
Step 6: Promote to production
Promote the same bundle artifact that was validated in the test stage to production. This guarantees the exact same artifact runs in prod:
Integrating with GitHub Actions
The CLI works with existing CI/CD solutions. The GitHub repository includes reusable workflow templates that DevOps teams can adopt directly.The following is an example of a GitHub Actions workflow that implements a full bundle-based deployment pipeline:
The CLI also works with Jenkins, GitLab CI, and Azure DevOps. See the CI/CD integration guide for additional examples.
In the next section, we cover which AWS services and workload types the CLI supports.
Supported workloads
The CLI deploys applications that span the following AWS services through Airflow workflow definitions:
- Analytics and BI: AWS Glue ETL jobs and crawlers, Amazon Athena queries, Amazon Quick Sight dashboards, Amazon EMR jobs, Amazon Redshift queries.
- Machine learning: SageMaker training jobs, ML model endpoints, SageMaker AI Pipelines.
- Code and workflows: Jupyter notebooks, Python scripts, Airflow DAGs (MWAA and MWAA Serverless).
- Data and storage: S3 data files, Git repositories, SageMaker Catalog resources (glossaries, glossary terms, form types, asset types, assets, data products, metadata forms).
The examples directory includes working applications for each of these patterns, with manifests, workflow definitions, and integration tests.
Failure recovery
If a deployment fails, the CLI stops at the point of failure and reports the error with a detailed stack trace. To recover:
- Run
aws-smus-cicd-cli describe --connectto check which resources exist and which permissions are missing. - Fix the issue and rerun
aws-smus-cicd-cli deploy. - For bundle-based deployments, redeploy a previous bundle version.
- Use
aws-smus-cicd-cli destroy --targets <target> --forceto clean up a failed deployment.
For detailed rollback procedures, see the Rollback Guide.
Conclusion
In this post, you learned how the Amazon SageMaker Unified Studio CI/CD CLI gives data and DevOps teams a clean separation of concerns: data teams describe their application once in a YAML manifest, and DevOps teams deploy it with a single command through their existing CI/CD pipelines. You saw how stages map to isolated SageMaker Unified Studio projects (optionally spanning AWS accounts and Regions), how bundles provide immutable, reproducible promotion through test and production, and how the CLI integrates with GitHub Actions, Jenkins, GitLab CI, and Azure DevOps. You also walked through deploying a Glue-and-Quick-Sight analytics application from dev through to prod.
Get started
The CI/CD CLI is available at no additional cost in all AWS Regions where Amazon SageMaker Unified Studio is available. You pay only for the underlying AWS resources provisioned during deployment.
Use the following steps to try it out:
- Install the CLI:
- Browse the example applications for analytics and ML patterns.
- Follow the CI/CD CLI documentation to deploy your first application in 10 minutes.
- Review the Admin Guide for infrastructure setup.
For feedback and bug reports, open an issue on the GitHub repository.
About the authors
Capture data lineage of Amazon EMR spark jobs into Amazon SageMaker Unified Studio
Post Syndicated from Jose Romero original https://aws.amazon.com/blogs/big-data/capture-data-lineage-of-amazon-emr-spark-jobs-into-amazon-sagemaker-unified-studio/
Data engineers running Apache Spark jobs on Amazon EMR face a persistent challenge: understanding how data moves through Spark pipelines as it’s transformed, joined, and written to downstream tables . Tracking these transformations manually requires examining job logs, reviewing code, and piecing together transformation logic across multiple sources. As pipelines scale, this process becomes complex. The visibility gap affects key business activities: troubleshooting data quality issues takes longer – impact analysis for schema changes requires more effort – and compliance audits need extensive documentation of data provenance.
Amazon SageMaker is the center for all your data and analytics where you can find and access all the data in your organization and act on it using tools across various use case. This unified platform addresses the data visibility challenge by bringing together data governance, collaboration, and discovery into a single interface. At the heart of this platform is Amazon SageMaker Catalog, a centralized hub that enables organizations to catalog, govern, and discover all their data assets with complete visibility into lineage. By capturing data lineage across your entire data ecosystem from raw sources through transformations to final outputs, SageMaker Catalog enables you to track data provenance across your entire platform, enable collaboration with clear visibility into data ownership and quality metrics, build trust through comprehensive data lineage that supports compliance and confident decision-making, and accelerate discovery of trustworthy, governance-ready data assets. You can access and visualize this lineage directly in Amazon SageMaker Unified Studio, which serves as the unified interface to explore data relationships and collaborate across your analytics workflows.
Amazon EMR, starting from version 7.11, now includes native OpenLineage support that automates lineage capture. OpenLineage is an open-source framework for data lineage that automatically emits lineage metadata from your data transformation jobs directly into Amazon SageMaker Catalog, or other data governance solutions, without requiring customizations.
This EMR native support of OpenLineage is part of a growing set of integrations across AWS analytics services including AWS Glue, Amazon EMR Serverless, and Amazon Redshift. The complete list of services with native OpenLineage integration can be found in the data lineage support matrix.
In this post, you’ll walk through a practical, step-by-step example that shows how to capture and track data lineage from Spark jobs running on Amazon EMR directly into Amazon SageMaker Catalog using OpenLineage. You’ll see how lineage metadata flows automatically and explore data relationships and dependencies across your workflows in Amazon SageMaker Unified Studio.
Solution overview
Imagine you’re part of a large enterprise that relies on HR analytics to optimize workforce planning, compensation strategies, and talent retention practices. Your data engineering team owns the delivery of these analytical products by processing raw HR datasets (including employee records, attendance logs, and compensation details), with Spark jobs running on your Amazon EMR infrastructure.
With time, Spark jobs have grown in complexity. Your team now struggles to maintain visibility into how data moves through pipelines, who modified it, and how to map dependencies between datasets and final analytical products.
The following solution demonstrates how you can address these challenges by automatically capturing data lineage end-to-end from Spark jobs running on your EMR infrastructure and visualizing it in Amazon SageMaker Unified Studio so that you and the business understand data provenance of the final analytical products.
The architecture includes a Data Layer with CSV files containing employee, attendance, salary, and bonus data stored in Amazon S3 (Simple Storage Service), representing typical HR and payroll source systems.
The Processing Layer uses Amazon EMR cluster running Apache Spark jobs that transform raw data into analytical tables. The first Spark job joins employee and attendance data while the second Spark job combines attendance with compensation data. Both jobs use Apache Iceberg table format to provide ACID (Atomic, Consistent, Isolated, and Durable) transactions and time travel capabilities.
The Metadata Layer uses AWS Glue Data Catalog to store Iceberg table metadata, making tables discoverable and accessible across AWS analytics services. A Lineage Layer uses the OpenLineage integration in EMR to automatically track input/output datasets (CSV files and Iceberg tables), transformation logic at column level (joins, filters, aggregations), and job execution metadata.
Finally, the Data Governance Layer uses Amazon SageMaker Catalog to capture and process OpenLineage events posted by the EMR Spark jobs and automatically build a comprehensive lineage graph that shows complete data provenance from CSV source files through Spark transformations to Iceberg analytical tables.
Before you deploy this solution, make sure you have the following resources in place.
Prerequisites
For this walkthrough, you should have the following prerequisites:
- An AWS account.
- Your assumed role should have full access to Amazon EMR serverless, Amazon S3, Amazon Identity and Access Management (IAM) and AWS Lambda. Note that for production workloads, minimum permissions are recommended.
- A Amazon VPC (Virtual Private Cloud) with at least one subnet with internet access. You can provision this VPC as you create the Amazon SageMaker domain next.
- An existing Amazon SageMaker Unified Studio domain and project. To get started, use the quick setup option as explained here. To create a project, follow the instructions here.
- An S3 bucket with the sample data files and Spark scripts uploaded (see Prepare Your Source Data below)
- Default EMR service roles — if this is your first time using EMR in this account, run `aws emr create-default-roles` from the AWS CLI or CloudShell to create them.
With these prerequisites in place, let’s examine what the AWS CloudFormation template will deploy to your AWS environment.
Architecture components
The deployment creates several interconnected components that work together to capture and visualize lineage:
- An S3 bucket to store all data and artifacts for the solution.
- An EMR cluster (v 7.12.0) with Apache Iceberg support enabled and OpenLineage integration pre-installed, ready to run Spark jobs with lineage tracking.
- A set of IAM policies that grant the necessary permissions to the EMR cluster to post lineage events to your SageMaker Unified Studio domain.
- A set of AWS Lake Formation permissions that grant the EMR cluster to create, alter, and drop Iceberg tables in your specified Glue database.
With an understanding of what will be deployed, you’re ready to launch the CloudFormation stack.
Deploy the solution
Note: While this walkthrough uses the AWS EMR console and AWS CLI to verify the cluster and run Spark jobs, you can also perform these steps directly from Amazon SageMaker Unified Studio. SMUS provides a unified interface to create and manage EMR clusters, submit Spark jobs, and monitor execution — all within the same environment where you’ll later explore the lineage captured in Amazon SageMaker Catalog.
Prepare your source data
Before deploying the CloudFormation stack, clone or download the following git repository.PutHereGitRepo
Upload the CSV files downloaded from git to the input/ prefix and the spark scripts in scripts/ prefix. You can run the following command to upload the files:
aws s3 cp employees.csv s3://YOUR-BUCKET/input/
aws s3 cp attendance.csv s3://YOUR-BUCKET/input/
aws s3 cp salary_adjustments.csv s3://YOUR-BUCKET/input/
aws s3 cp bonus_payments.csv s3://YOUR-BUCKET/input/
aws s3 cp emr-lineage-spark-job.py s3://YOUR-BUCKET/scripts/
aws s3 cp emr-lineage-compensation-job.py s3://YOUR-BUCKET/scripts/To deploy the solution, complete the following steps in CloudFormation console:
- Create new stack by specifying the CloudFormation yaml file previously download from git repository
PutHereThe YMLFileName - Enter a stack name (e.g.,
emr-lineage-demo) and provide the following parameters:- SourceS3BucketName: S3 bucket containing your CSV files and Spark scripts
- SourceCSVPrefix: S3 prefix where CSV files are located
- SourceScriptsPrefix: S3 prefix where Spark scripts are located
- GlueDatabaseName: The name of the Glue database associated to your Amazon SageMaker Unified Studio project.
- DataZoneDomainId: Your SageMaker Unified Studio domain ID.
- VpcId: The id of the VPC that was deployed as part of the prerequisites.
- For EMRReleaseLabel, MasterInstanceType, CoreInstanceType and CoreInstanceCount, keep the default values.
- Acknowledge IAM resource creation, choose Next and then Submit. The CloudFormation stack takes approximately 10 to 15 minutes to complete.
- In the EMR console, wait for the cluster status to show as WAITING before moving to the next step.
Now that the EMR cluster is running with OpenLineage enabled, let’s examine how the Spark jobs are configured to capture lineage metadata.
Explore data lineage configuration in EMR
When submitting Spark jobs to EMR, specific configurations enable OpenLineage to create and post lineage events to SageMaker Unified Studio as the job runs:
spark.hadoop.hive.metastore.client.factory.class– Configures Spark to use AWS Glue as the Hive metastore.spark.jars– Path to the pre-installed OpenLineage library (available on EMR 7.11+).spark.extraListeners– Registers an OpenLineage listener to capture metadata of input / output datasets and transformations.spark.openlineage.transport.type– Uses the OpenLineage DataZone transport option to send lineage events directly into SageMaker Catalog.spark.openlineage.transport.domainId– The ID of your SageMaker Unified Studio domain, that serves as the target for lineage events.spark.glue.accountId– Your AWS account ID for Glue data catalog operations.
Now that you understand the configuration that enables automatic lineage capture, you’re ready to run the data pipeline.
When running this two-step pipeline, you will calculate the total employee compensation by combining salary adjustments, bonuses, and attendance data. The final analytical asset will serve payroll processing and budgeting.
Run employee attendance analysis job
The first job reads employee details (in employees.csv dataset) and attendance records (in attendance.csv dataset), joins the datasets on EmployeeID and creates a unified dataset (employee_attendance Iceberg table) in your Glue database.
Follow the steps below to run this first job:
- In the CloudFormation console, navigate to the stack’s Outputs tab
- Copy the value of the
Job1SubmitCommandoutput key. Note that this is the command you’ll use to submit the first job in EMR with the right configuration.
- Run the command in your terminal or AWS CloudShell.
- Monitor the job in the Amazon EMR console under Steps.
Run employee compensation analysis job
Now, you will calculate the total employee compensation (Iceberg table) by combining salary adjustments (salary_adjustments.csv dataset), bonuses (bonus_payments.csv dataset), and attendance (calculated in the last step):
- Repeat the steps 1 to 4 to run Job 2.
- After completion, open the AWS Glue console.
- Navigate to Data Catalog, then Tables and select your SageMaker project’s database.
- Confirm that
employee_attendanceandemployee_compensationtables are listed.
With both Spark jobs complete, you can now visualize the complete data lineage graph in Amazon SageMaker Unified Studio.
Visualizing lineage in SageMaker Unified Studio
SageMaker Unified Studio provides a graph-based data lineage visualization that helps data engineers, analysts, and data scientists clearly understand which source datasets (files or tables) feed into each dataset, what transformations and logic are applied at every step, which downstream analytics assets consume the data, and how changes to upstream data or transformations may impact the rest of the data pipeline.
Now that the data pipeline run successfully, let’s review the captured lineage for the HR data in SageMaker Unified Studio:
- Navigate to the SageMaker Unified Studio console, sign in to your domain.
- Open your project and go to Data Sources
- Find your AWS Glue Data Catalog source
- Click RUN. Two new assets will be created.
- Navigate to Assets and Click on employee_compensation. Under the LINEAGE tab you’ll find the lineage graph view that SageMaker builds based on the OpenLineage metadata captured from the EMR Spark jobs as they run.
-
- You’ll first see three lineage nodes from left to right: one representing the EMR Spark job that created the final Iceberg table, a second one representing the actual Iceberg table in the Glue catalog, and a third one representing the data asset in the SageMaker Catalog inventory that maps to the Glue table.
- Click on any lineage node to view its underlying metadata in the details pane, including dataset names, S3 locations, schema, data types, job execution details and more.
- Expand the lineage to the left by clicking on the double arrow next to the first lineage node. Keep expanding until you hit the originating datasets.
-
- Expanding the graph to the left reveals the complete data pipeline back to original CSV source files. You can see how compensation data depends on upstream attendance analytics.
- Note how each lineage node represents an element in the data pipeline you run, including both Spark jobs and even the intermediate employee_attendance Iceberg table that connects them.
- You can expand column-level lineage by clicking on the column section of a lineage node of a dataset or data asset. This allows you to understand how data changes at a column level as it goes downstream your data pipeline.
Cleanup
To avoid ongoing charges, clean up the resources:
- First, empty the destination bucket by running the following command in your terminal or with AWS CloudShell.
aws s3 rm s3://${DEST_BUCKET}/ --recursive
- Delete the CloudFormation stack.
- On the AWS CloudFormation console, choose Stacks in the navigation pane.
- Choose the stack you created, then choose Delete and then Delete stack when prompted.
Conclusion
In this post, you explore how to capture data lineage from Spark jobs in Amazon EMR (v7.11+) directly into Amazon SageMaker Unified Studio. You learned how to set up an Amazon EMR cluster with native OpenLineage support to automatically track lineage metadata from Spark jobs processing your data. You also configured the integration between EMR and Amazon SageMaker Catalog to ensure lineage information flows seamlessly into your governance platform. Finally, you explored the resulting lineage graph in SageMaker Unified Studio and saw how it provides comprehensive visibility into data transformations, from source CSV files through Spark processing jobs to final analytical tables using Apache Iceberg format.
We encourage you to now test these capabilities with your own data pipelines running on EMR. By implementing automated lineage tracking, many customers have strengthened their governance frameworks while gaining valuable insights into data dependencies, impact analysis, and compliance requirements. This approach enables data teams to build trust in their analytics outputs while maintaining the agility needed to derive business value from their data assets.
About the authors
Announcing Claude Compliance API support with Cloudflare CASB
Post Syndicated from Abe Carryl original https://blog.cloudflare.com/casb-anthropic-integration/
Today, we are extending Cloudflare’s cloud access security broker (CASB) to support the Claude Compliance API. Security and compliance teams can now monitor Claude usage directly in the Cloudflare dashboard. No endpoint agents required.
Enterprise security teams have long struggled to see how users interact with sanctioned and unsanctioned applications. The rapid adoption of AI applications has made this harder. Employees spend significant time in these new surface areas, and their interactions differ from traditional SaaS: users upload files, share freeform prompts, and providers generate content that may contain sensitive data.
Cloudflare CASB helps solve this problem. One API integration gives you out-of-band visibility and control over the applications your organization uses. This integration builds on our existing support for AI governance, extending coverage over the most common tools security teams now manage.
AI adoption has outpaced security governance. While IT and security teams raced to enable AI tools for productivity, the controls lagged behind. Most organizations today operate with partial visibility: they may block unauthorized AI tools at the network layer, but they cannot see what happens inside sanctioned ones.
This matters because AI tools are not like traditional SaaS applications. They are conversational, persistent, and deeply integrated into workflows through APIs and agent frameworks. An employee might paste customer data into a prompt. A developer might accidentally share an API key and leave it unrotated for months. An AI application might generate content which contains company secrets. Each of these actions creates compliance risks that conventional security tools cannot detect.
Organizations are moving fast to adopt AI, but these tools require a different security model. They do not just read data; they generate it, act on it, and connect to multiple systems of record in a single workflow. Security needs to cover the full lifecycle: from how an application calls an API, to what data it handles, to where that data lives at rest. Cloudflare gives organizations the tools to do this at every point of the workflow:
-
Cloudflare AI Gateway sits between your applications and AI providers like Anthropic, giving you observability into requests, token spend, and model performance. This allows administrators to enforce rate limits, cache responses, and make fine-grained routing decisions.
-
Cloudflare Gateway and Data Loss Prevention inspect AI traffic for sensitive data, blocking prompts that contain customer personally identifiable information or confidential material before they reach the model.
-
Cloudflare Access with MCP server portals centralizes agent connections to corporate tools behind a single protected endpoint. Administrators control which users and agents can reach which systems, and every request is logged for audit.
-
Cloudflare CASB now extends this same unified approach to data at rest inside Claude, scanning for misconfigurations and sensitive data without endpoint agents.
These capabilities run side by side, on the same metal, making each service both composable and programmable. More importantly, that means traffic never hairpins through multiple vendors or clouds to be secured.
Cloudflare CASB helps organizations connect to, scan, and monitor third-party SaaS applications for misconfigurations, improper data sharing, and other security risks through lightweight API integrations. Organizations can regain visibility and control over their growing investments in SaaS apps.
As enterprises deploy Claude at scale, security and compliance teams need the same visibility into Claude usage that they have for every other enterprise application in their stack. Anthropic recognized this gap and built the Claude Compliance API to give enterprises programmatic access to security-relevant data about their Claude organizations, workspaces, and usage.
Cloudflare CASB now consumes this endpoint to surface actionable security findings without requiring inline traffic inspection or endpoint agents.
With this integration, Cloudflare One customers can monitor Claude Enterprise activity using the detection and remediation workflows they already rely on. Cloudflare CASB connects to Claude via the Compliance API and scans for security findings.
Starting today, Cloudflare supports security findings for the following assets:
-
Projects: Detect projects shared across the organization or a subset of users and groups
-
Project attachments: Files and documents added to projects that violate DLP policies
-
Chat files: User-uploaded and provider-generated files that violate DLP policies
-
Chat messages: User prompts and provider responses that violate DLP policies
-
Artifacts: Provider-generated documents and files that violate DLP policies
These findings appear directly in the Cloudflare dashboard alongside posture and content findings from your other SaaS applications. Findings are grouped by category and ordered by severity level. Security teams can triage, assign, and remediate Claude-specific risks using the same workflows they use for Microsoft 365, Google Workspace, or Salesforce.
For Claude Enterprise, CASB surfaces compliance data such as organizations, projects, chats, and roles. It also retrieves conversation content, including messages and uploaded files through dedicated read-only endpoints to prevent data loss.
For Claude Platform, CASB will continue to surface member and workspace changes, API key creation, and file create or download events. In the near future, we will add support for the Activity Feed.
CASB turns findings into action. A detected security finding in Claude, such as a user uploading files containing sensitive data, can become a Gateway policy in minutes. You can use Gateway to block uploads to Claude for specific users, restrict access to the application entirely, or limit functionality until the issue is resolved. This moves security teams from visibility to action by combining CASB findings with Cloudflare’s existing in-line policy engine.
To enable the Claude Compliance API integration:
-
Ensure you have a Claude Enterprise account.
-
Request Compliance API access from Claude for your organization.
-
In the Cloudflare dashboard, go to Zero Trust > Integrations > Cloud & SaaS.
-
Select Add Integration > Anthropic and enter your Compliance API key.
-
Configure DLP profiles if you want to scan uploaded files for sensitive data.
The integration begins scanning immediately and surfaces findings in the dashboard within minutes.
For new Cloudflare customers, you can sign up and start with your first two integrations for free. Existing customers can enable the integration directly in the dashboard.
We are continuing to expand CASB coverage for AI tools as providers release new enterprise security APIs. We are also deepening integrations within CASB to allow customers to create custom findings and build workflows which automatically remediate security findings.
The shift to agentic AI is here, and we believe the best way to help organizations safely adopt it is by providing a unified platform to build, deploy, and govern agents. To stay up to date, check our developer documentation or subscribe to get updated automatically.