Data Engineer

Еще один экземпляр из бумажной коллекции. Начал читать.

Anthropic наконец-то опубликовали свой секретный рецепт для агентной аналитики, и это… Моделирование данных по Кимбаллу (Kimball Data Modeling) Шутка здесь в том, что многие ожидают увидеть какой-то революционный AI-фреймворк, сложную агентную архитектуру или новый research paper, а оказывается, что в основе агентной аналитики лежат старые добрые принципы построения аналитических хранилищ данных по Кимбаллу: факты, измерения, схема звезда, понятные бизнес-сущности и качественно подготовленные данные. Для дата-инженеров и аналитиков это примерно звучит как: Секрет успешных AI-агентов? Сделайте нормальный DWH @tldr_data

Databricks объявил конец эпохи пайплайнов. На Data + AI Summit 2026 компания представила новую архитектуру LTAP (Lake Transactional/Analytical Processing), которая должна объединить транзакционные системы, аналитику, стриминг и AI на одной копии данных. Идея радикальная: приложения, BI-системы и AI-агенты работают с одним источником данных напрямую, без CDC, ETL и бесконечных репликаций между OLTP и аналитическими хранилищами. Последние двадцать лет типичная архитектура выглядела примерно так: PostgreSQL → CDC → Kafka → ETL → Data Warehouse → BI → AI Каждый новый слой добавлял задержки, повышал стоимость владения и создавал новые точки отказа. Особенно болезненно это стало с появлением AI-агентов, которым нужны актуальные данные в реальном времени, а не копия пятиминутной давности. Ответ Databricks — хранить операционные и аналитические данные в одном месте. В основе подхода лежит Lakebase, PostgreSQL-совместимая система, работающая поверх объектного хранилища и интегрированная с Lakehouse. Компания называет это первым LTAP-подходом, который должен заменить как традиционные ETL-процессы, так и многочисленные реплики баз данных. Конечно, заявления о «смерти пайплайнов» стоит воспринимать осторожно. Интеграции между компаниями, обмен данными с внешними системами, специализированные стриминговые сценарии и гибридные архитектуры никуда не денутся. Но сам тренд выглядит очень интересным. Если раньше индустрия спорила, что лучше — Data Lake или Data Warehouse, то теперь главный вопрос звучит иначе: Нужно ли вообще перемещать данные между системами, если все сервисы, аналитика и AI могут работать поверх одной копии данных? Похоже, именно вокруг этого вопроса и будет строиться следующая большая битва в мире Data Engineering. @tldr_data

DEMate - тот, кто тебя заменит Meta пошарила статью про DEmate - внутреннего AI-ассистента для data engineering, который не просто SQL / питон генератор кода, а готовый AI-слой для полноценного цикла разработки (ака накидаем md в контекст в первых версиях😂), учитывающим специфику внутренних систем Meta (а там без пол-литра иногда и не разобраться 🍺). Главный поинт в том, что LLM становятся полезными в enterprise-инженерии не тогда, когда им дают полный yolo, а когда их ограничивают контекстом, проверками, рецептами и автоматической валидацией (вот это поворот 🤯) https://medium.com/@AnalyticsAtMeta/how-we-built-demate-taming-llms-for-data-engineering-at-meta-d134e69637c5 Один из уровней это Recipe Architecture - архитектура “рецептов”, которая направляет LLM через структурированный процесс. Когда ленивый дата инженер (то есть я 🧐) просит модель “сделай pipeline” и надеется на хороший результат, DEmate выбирает подходящий рецепт, подставляет нужный контекст, генерирует изменения и затем прогоняет проверки. На выходе не просто сгенерированный код, а уже проверенный результат, адаптированный под внутренние стандарты. Еще сделан Recipe Chaining, или цепочка рецептов. Реальная engineering-задача состоит из набора шагов: сначала нужно построить pipeline, затем добавить data quality checks, потом оптимизировать SQL или подготовить тесты 😺. DEmate не загружает модель огромным md сразу, а постепенно раскрывает инструкции по мере необходимости (ого, неужто workflow 😃). Это снижает шум в контексте и уменьшает вероятность ошибок (якобы 👍) Meta также использовала AI для ревью самих AI-рецептов (ну а фигли, бесплатные токены же 🔼). По мере роста DEmate разные команды начали добавлять собственные рецепты, и ручная проверка стала узким местом. Для этого ввели автоматизированные проверки: инструкции должны быть не размытыми, без лишнего текста, содержать явные шаги валидации, не конфликтовать друг с другом, не дублировать существующие рецепты и иметь тестовые positive/negative

Дочитал «Архитектуры данных» Джеймса Серры. Товарищ сей мне весьма симпатичен, было время, когда я наблюдал за его каналом на YouTube. Мне импонировало то, что, рассказывая про Data Mesh, он не пытался эксплуатировать тему «самого лучшего кунг-фу», а просто рассказывал свое видение ситуации и предлагал свой критерий соответствия функции данных в компании методологии имени Жамак Дегани. Серра почти 40 лет в IT, 15 из них в хранилищах, «я здесь давно, мне можно верить», короче. Книгу он решил написать, поскольку обратил внимание, что архитектуры данных сложны и «большинство людей не понимают их концепций, если вообще что-то знают о них». Он попытался объективно рассказать о достоинствах и недостатках каждой из представленных архитектур. На мой взгляд, у него получилось. Особенно порадовала глава о проведении дизайн-сессий по разработке архитектуры - хорошее практическое пособие для начинающих архитекторов. Ну, или чек-лист вопросов, которые имеет смысл задать на собеседовании по System Design. По части Data Mesh Серра не стал отделываться общими словами, а прикинул, как оно будет выглядеть на практике. Его вердикт сродни: «Чистого спирта не бывает. Максимум - 96 градусов!». По его мнению, из тех, кто назовет свое решение Data Mesh: ▪️ ~90% внедрят доменное владение ▪️ ~70% данные как продукт ▪️ ~треть осилит самообслуживаемую инфраструктуру ▪️ ~половина федеративное управление В суть Data Mesh вообще мало проник, кроме Трента Кримма, разве что. Сам Серра, по собственному признанию, десятки раз перечитывал блоги Дегани и до сих пор иногда обнаруживает, что понял что-то неправильно. В завершение, как обычно, парочка любимых цитат: «Слухи о смерти реляционных хранилищ данных сильно преувеличены» «Стандартных определений концепций и архитектур данных не существует. Иначе эта книга была бы не нужна.» «Хотя технологии и шагнули далеко вперед, дело не в них - а в людях и процессах, и мы не так хорошо продвинулись в работе с ними. Вы можете придумывать новые крутые

#напочитать Даниэль Пинк - «Драйв» Типичная книга из серии «Литература для бизнеса», построенная по формуле «Проблема-Следствие-Аргументы-Выгода». Много воды, различного рода кейсов из жизни деревень Вилларибо и Виллабаджо. В Вилларибо все еще используют обычное моющее средство и вследствие этого кипятятся, а в Виллабаджо уже рубят. И да, мы идем к вам. Суть первых двух частей можно свести к простой мысли: для творческих задач внутренняя мотивация важнее внешней. Для рутинных задач внешний стимул в короткой перспективе может стать отличным импульсом. Мотивируют людей, согласно Пинку, всего три вещи: 🔹 Автономность - наше стремление к самоуправлению 🔹 Мастерство - побуждение становиться все лучше и лучше в своем деле 🔹 Целеустремленность - явная отсылка к Фейербаху - желание быть частью чего-то большего, чем мы сами Самая полезная - третья часть - полный комплект подсказок, упражнений и ресурсов, призванных помочь создавать условия для поведения, определяемого внутренними желаниями. Ради нее и стоит читать книгу. Цитаты: «Одна из главных причин фрустрации на рабочем месте - несоответствие между тем, что люди должны делать, и тем, что они могут. Слишком простые задачи заставляют их скучать, слишком сложные - тревожиться» «Когда вы будете размышлять о своей цели в жизни, начните с важного вопроса: как звучит ваша главная фраза?» Когда я заступал на пост Head of DE в зеленом (тогда) DIY-ритейлере, у меня была похожая идея с отсылкой на японских императоров, которые в начале своего правления тоже должны были представить некий девиз. Я тогда что-то придумал, следовал выбранному курсу, но нигде это не афишировал, а коль скоро так, то и у меня из головы это вылетело. Но наверняка там что-то было про непрерывное развитие…

Раз уж вписался в ИИ-трансформацию, надо хотя бы делать вид, что понимаешь, что происходит. Обложился, в общем, специальной литературой, благо ее сейчас предостаточно, да и на русском выходит со скоростью Себастьяна Саве, устаревая примерно так же. Так что «не хайпа ради, а служебной пользы для». Да и стратегию защищать нужно... Чип Хьюен - персонаж в сфере сей довольно авторитетный: работала в NVIDIA, преподавала в Стэнфорде и даже написала книгу о машинном обучении. Которую я, конечно же, «ни при какой погоде не читал». Ну, не интересовала меня эта тема... Люблю, когда автор начинает с определения: «ИИ-инженерия - процесс создания приложений на основе доступных моделей» Сразу настраивает на рабочий лад. Далее Хьюен по шагам проводит читателя от знакомства с базовыми моделями до архитектуры ИИ-инженерии. Ровно посередине находится глава, посвященная промт-инжинирингу, который автор определяет как «процесс разработки инструкции, которая позволяет добиться от модели желаемого результата». Отмечая, что: «Проблема не в промт-инжиниринге. Это реальный и полезный навык. Проблема возникает, когда люди не знают ничего, кроме промт-инжиниринга. Вам будут нужны знания из области статистики, инженерии и классического ML для отслеживания экспериментов, оценки и редактирования наборов данных» Такой вот нас ждет «новый дивный мир»... Книга мне понравилась, подойдет тем, кто уже имеет некий инженерный опыт, но в ИИ еще не вляпался.

С недавних пор я официально являюсь сертифицированным руководителем отдела, закончив соответствующий курс в «Стратоплане». Оказывается, руководить людьми довольно просто - «развивай свои сильные стороны, а слабые закрывай шаблонами». Все по бразильской системе, короче… Пришел я сюда с целью «легитимизировать свой опыт», придать ему системный характер. В каком-то хаотичном виде он у меня и так присутствовал… Колес и велосипедов за свою управленческую карьеру я изобрел предостаточное количество. «Обломал немало веток, наломал немало дров», не один штрафной круг по граблям прошел. Мне бы вот все эти мои новые знания четыре года назад, глядишь, бы и не было затянувшегося творческого кризиса с обязательной сменой работы каждый год. А иногда и не один раз… Четыре месяца пролетели незаметно. Менялись темы, менялись преподаватели, неизменными были высокий уровень каждого занятия и заряд энергии, приобретаемый от общения с умными людьми на групповых занятиях. Что мне дал этот курс? 1️⃣ Помог лучше узнать себя, ближе к концу я разобрался, зачем я здесь, для чего это все мне нужно и что делать дальше. 2️⃣ Мой образ жизни стал несколько здоровее, я стал следить за сном, перестал терзать себя чрезмерными беговыми объемами, даже сбросил пару накопленных за период зимней спячки килограммов. «Вы где-нибудь видели топ-менеджера, который пихает в себя всякую гадость?» - в общем. 3️⃣ По DISC-классификации я желто-зеленый. Про желтый цвет и до этого понятно было, а вот зеленый удивил. Правда, после того, как я начал высыпаться, вместо зеленого стал проявляться красный. 4️⃣ GOSPA - очень простой и вместе с тем эффективный метод стратегического планирования. Настолько он меня поразил, что я прямо на занятии полез переписывать свою стратегию, а остаток лекции теперь придется пересматривать в записи. 5️⃣ Куча полезной литературы для дальнейшего самостоятельного развития. На пару лет точно хватит даже с моей скоростью чтения. 6️⃣ Я познакомился с большим количеством умных людей,

Раз уж чтение становится ключевым навыком инженера данных, а, по мнению голландских ученых, его лучше развивать при помощи бумажных книг, то прикупил себе сей чудесный экземпляр в бумажную коллекцию.

LLMSQLQueryOperator В Airflow появился новый декоратор task.llm_sql, который генерирует SQL из запроса на обычном языке. Вы описываете, какие данные нужны, передаёте схему — и LLM генерирует SQL. Главное — безопасность: Airflow разбирает SQL в AST и разрешает только SELECT, UNION, INTERSECT и EXCEPT. DELETE, DROP, UPDATE и INSERT блокируются. Также можно включить require_approval=True , чтобы человек проверил SQL перед продолжением DAG. Сам @task.llm_sql запрос не выполняет — только генерирует и валидирует его. @tldr_data