Отвлечёмся от новых айфонов на ночное-полезное: нашёл «библию дата-инженеров» — репозиторий, где собрано всё для входа в профессию и максимальный буст скиллов.

— 25+ книг, от базовых вроде «Fundamentals of Data Engineering» до сложных «Designing Data-Intensive Applications»;
— Топовые комьюнити и разные комнаты для общения (Discord, Slack, Data Talks Club);
— Обзоры компаний и утилит: от Airflow и Dagster до ClickHouse, dbt и DuckDB;
— Подкасты, блоги, ютуб-каналы и рассылки для постоянного апдейта;
— Подборка курсов и сертификаций от Google, Microsoft, AWS, Databricks.

Данные — сила

#заметкинаполях #depatterns

Чтение о книги о шаблонах движется пока очень медленно, тем не менее, разговор продолжаем.

«Фигура вторая, инкрементальная…» (квиз по советским фильмам не отпускает)

Используется, если есть нечто, что позволяет отделить новые данные от уже обработанных. Это может быть колонка в таблице или же отдельный файл/партиция. Сей шаблон позволяет значительно уменьшить объемы передаваемых данных.

Но…

Если в источнике данные удаляются, то вы об этом вряд ли узнаете.

Ежели вам все же хочется знать об удалениях или же сократить интервалы между «поглощениями» данных, то вашим выбором может стать шаблон под номером 3, именуемый Change Data Capture, а народе же более известный как CDC.

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

Продолжение следует…

Bill Inmon - «Building the Data WareHouse» 

Параллельно перечитываю фундаментальный труд от легенды мира данных, автора таких концепций, как Data Warehouse и Data Lakehouse, человека с лицом солиста советского ВИА «Верасы», «малиновки голосок заслышавшего». 

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

Владимир Ильич Ленин писал: «Кодд и Дейт разбудили Инмона. Инмон развернул революционную агитацию. Ее подхватили, расширили, укрепили, закалили дата-специалисты по всему миру».

Методология Инмона - классическое итальянское «катеначчо»  - предполагает построение DWH «от обороны», «страшно далек он от конечного пользователя», все равно они не знают, чего хотят, а «самое красивое в футболе - это счет на Tableau». 

Подход отличает основательность, продуман каждый аспект, «в футболе мелочей не бывает». Но… это все только на самом верхнем уровне, погружаться в детали Инмон не считает нужным. «Бей вперед - игра придет», в общем…

Очевидно, что при таком подходе главными действующими лицами в дата-команде становятся «плеймейкеры», классические «десятки» вроде Сандро Маццолы или Джанни Риверы - главные носители знаний о корпоративных данных и процессах, их движущих. Именно они отвечают за доставку данных к конечным пользователям.Подобные исполнители - «штучный товар», при их уходе у компании могут возникнуть серьезные проблемы.

Читайте классику, в общем… 

P.S. Встретил у Инмона интересное слово «fiefdom», что в переводе означает «вотчина». Предлагаю в качестве импортозамещения перестать использовать слово «офис» и заменить его исконно русским. Вотчина данных - это же прекрасно, а CDO, соответственно, - боярин над данными. Лепота!

#напочитать

Teradata row partitioning (PPIs) VS Snowflake clustering

Неожиданный пост в контексте недоступности этих вендоров в России, но очень интересный в тематике канала.

Недавно наткнулся на заметку широко известного в узких кругах автора Roland Wenzlofsky. В ней автор раскрывает тонкости реализации партиционирования в Teradata и Snowflake.
T - каждый блок данных, удовлетворяющий условию партиционирования физически лежит отдельно, таким образом чтение/изменение данных по ключу затрагивают всегда ожидаемый набор блоков;
S - абсолютно все данные рабиваются на мелкие микро-партиции, а уже для выполнения условия партиционирования собираются отдельные файлы статистики, которые указывают в каких микро-партициях находятся искомые данные по ключу партицирования, таким образом чтение/изменение данных по ключу затрагивает всегда случайный набор блоков.

Исходя из этих знаний можно найти плюсы и минусы одинаковой с точки зрения маркетинга функции:

Teradata Row Partitioning
➕Явное указание партиций → предсказуемость всегда.
➕Отличная производительность, когда предикаты совпадают с ключами разделения.
➕Нулевые затраты на выполнение запросов сверх начальной настройки.
➖Жёсткая структура. Изменение ключа партиционирования требует перезаписи всей таблицы.
➖Требует специальных знаний для проектирования структуры.
➖Неправильный дизайн = плохая производительность вплоть до необходимости редизайна.

Snowflake Clustering
➕Работает из коробки всегда, даже если вы явно не указали на необходимость партиционирования.
➕Гибкость: условия партиционирования могут быть добавлены, изменены или удалены в любое время
➕Нет необходимости заранее проектировать структуру.
➖Недетерминированность: качество проброски запроса к данных зависит от укладки данных в микро-партиции.
➖Поддержка кластеризации потребляет вычислительные ресурсы всегда.
➖Большие беспорядочные обновления быстро ухудшают эффективность.
➖Постоянный мониторинг или автоматическая кластеризация увеличивают операционные расходы.

#depatterns #заметкинаполях

Возвращаемся DE Patterns. Семейство шаблонов под номером 4 называется репликацией данных. Суть их всех сводится к простому копированию из одной локации в другую. Применяется при движении данных между однородными хранилищами, в идеале с сохранением атрибутов метаданных (первичных ключей в БД, к примеру), но «в действительности все не так, как на самом деле».

Итоги про репликацию от Data Whisperer

Шаблон под номером 5 предназначен для решения «проблемы маленьких файлов», известной инженерам с незапамятных практически времен. Решение очевидно - хранить меньше файлов, но большего размера. Впрочем, см сюда...

Следующий шаблон снова отсылает нас к ресторанной тематике: «Вам по готовности или все сразу?» Его задача помочь определить правильный момент для начала процесса поглощения данных. Как узнать, что загрузка какого-либо закончена, и можно запускать последующие процессы обработки?
В объектных хранилищах решение может быть легко реализовано при помощи флаг-файлов, таким как многим знакомый _SUCCESS, например.

Но и здесь не обошлось без подводных камней…

Продолжение следует…

Московский марафон (пятничное лирическое отступление)

Эпиграф

«Московский марафон, ветер северный,
На старте в Лужниках в старых трениках
…
Но не стена обычно губит,
А излишне быстрый старт»
(Популярная песня из 90х)

В времена оны, когда я «на почте служил ямщиком», работал руководителем инженерии данных в одном крупном DIY-ритейлере, ко мне постоянно стучались «косматые геологи», инженеры, (да и не только они, в общем-то), с просьбой выдать им список чудодейственных материалов, которые помогут им стать «лучшей версией себя» и достичь просветления в профессии.

Естественно, списки я им давал. Я вообще обожаю составлять списки, мое ОКР не даст соврать. Они были прекрасны, многое я и сейчас готов рекомендовать (и рекомендую), «но что-то его держало».

Путем долгой рефлексии (слово-то какое красивое) я понял причину. Ни один из этих материалов, ни даже все они в совокупности не стали для меня лично каким-то прорывом. Настоящим же прорывом, скачком в гиперпространство, разделившим мою карьеру на «до и после», стало решение пробежать Московский Марафон.

Подготовка к забегу научила меня распределять силы по дистанции, терпеть, восстанавливаться и расслабляться, «просто делать и делать просто», справляться с «перетреном».
В обучении тоже, кстати, есть свой вариант «перетрена» - «синдром вечного студента» - состояние, когда думаешь, что еще одна книга, еще один курс и все, сразу стану самым умным и богатым, но в результате получаешь заход на очередной штрафной круг, а то и тяжелую психологическую травму, отбрасывающую далеко назад.

А после финиша пришло понимание, что для меня теперь нет ничего невозможного, я справлюсь с любой задачей, рабочей и не только.

Наивный… Я тогда не знал про 400 метров… Ни один самый едкий комментарий самого токсичного код-ревьюера не доставит вам столько боли и страданий, сколько эта, короткая, казалось бы, дистанция.

Так что, «всем бег». Это сейчас самый популярный вид спорта в России. Футбольные фанаты не согласны, но сколько их придет даже в Derby Day, если матч назначить на 5 утра, а цена билета будет около 3000?

И легких ног, конечно же, всем участвующим!

#московскиймарафон #лирическое отступление

#заметкинаполях #depatterns

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

Думаю, вы догадались, кем вас окрестят за незнание там наверху…

Итак, только в идеальном мире сферические лошади побеждают согласно расписанию. В менее идеальных мирах, к коим относится мир данных, порой бывает сложно предугадать момент для начала процесса поглощения. Предыдущий шаблон, казалось бы задачу решает, но в этом случае потребитель самолично ответственен за проверку наличия новых данных (Pull Semantics).

А что, если взять и «изменить мышление всей компании, распределив ответственность» и
обязав источник данных оповещать потребителей, перейдя тем самым от пассивного поглощения к событийно-ориентированному (Push Semantics)?

Звучит как план…

Шаблон «Внешний импульс» (External trigger) состоит из трех основных частей:

▪️Первый шаг соединяет ваши конвейеры с внешним миром путем подписки на канал с уведомлениями. Теперь вы ничего не пропустите.

▪️Шаг второй заключается в реакции на сообщения из внешнего мира (нужно принять решение, запускать ли конвейеры, а, если запускать, то какие?)

▪️Шаг третий - это, собственно, запуск нужных конвейеров.

Засим (кажется, тайное общество «симитов» затянуло и меня) с этой главой все.

Продолжение следует…

Прямое включение с конференции Data Internals 2025

Посетил вчера новую конференцию по миру данных - Data Internals. Первый блин, однозначно, комом не вышел. Организация была на очень высоком уровне, да и локация была выбрана удачно - одна из моих самых любимых в Москве.

Про доклады, наверно, пока рано говорить, посетил я немного (но постараюсь посмотреть все), да и то в отношении двух могу быть предвзят, ибо к зарождению описываемых в докладах кейсах имел самое непосредственное отношение. Было приятно увидеть, что проекты не просто живы, а сильно выросли, что коллеги проделали огромную работу для их развития. Кое-что взял на заметку.

Речь идет о докладах представителей «Лемана Тех»: Артемия Наумова «Ревью без боли: DataOps-подход к управлению изменениями в DWH» и Михаила Зотова « Airflow еще доступнее: опыт self-service-оркестрации в Lemana Tech». Среди дата-докладчиков появились две новые звезды. Парни, так держать!

Еще понравился доклад Владислава Заболоцкого (Райффайзен Банк) «Как подготовить платформу данных к миграции уже сейчас?», особенно в части работы с владельцами данных.

Смазал общее итоговое впечатление круглый стол на тему «Как вырастить специалиста по базам данных?» Тема интересная и актуальная, которую можно было развить в занимательную дискуссию. Вместо этого шесть Александров Мостовых целый час рассуждали на тему: «Как научить футболиста чеканить мяч?»
Весь разговор свелся к крайнему случаю: «Как вырастить специалиста по базам данных из студентов МФТИ и МГУ?» А такую задачу провалить можно, только если вас зовут Сергей Семак…

Посещением я очень доволен, тем более, что конференции - это все-таки не только ценный мех интересные доклады, но и встречи с теми, кого давно не видел, а также новые знакомства. Еще раз всех обнял.

Заметки на полях DataInternals

Главным лейтмотивом докладов, на которых я побывал, стала фраза: «Все лгут могут ошибаться». Не раз и не два докладчики повторяли тезисы:
- Если у кого-то получилось, то не факт, что получится у вас.
- Если у кого-то случился факап, то, у вас то может получиться.

Все топят за то, что нужно проводить эксперименты и RnD. Только выделив время и людей на детальный тест технологий можно быть убеждённым, что именно эта связка именно под вашей нагрузкой именно с вашими сотрудниками будет работать так, чтобы закрывать ваши потребности 🎯

Возможно, это знание вынужденное из-за ухода вендоров с их методичками и необходимости проводить тесты Open Source инструментов самостоятельно, возможно, отрасль выросла. Но, так или иначе, я горячо поддерживаю такие выводы и считаю, что просмотра доклада с удачным внедрением недостаточно для внедрения у себя, как прочтения статьи о неудаче недостаточно для отказа.

Всем тест! 😉

P.S. Очередной раз убеждаюсь, что главное на любой конференции - это люди, а мир даты достаточно тесен. Организаторам, несмотря на молодость конференции, удалось собрать отличных спикеров, которые хорошо раскрывали темы своих докладов. А в промежутках между докладами было приятно обсудить технологии со старыми знакомыми и бывшими коллегами.

Архитектор данных в очередной раз в своих публикациях затрагивает интересную тему. А примерно год назад мой любимый канал о системном мышлении также подбирался к подобному, рассказывая о книге Курта Воннегута «Пожалейте читателя». Вдохновившись этими двумя повествованиями, я решил, что пост о написании постов идеально подходит для пятничного лирического отступления.

Мне кажется, что для хорошего архитектора или инженера данных никаких сложностей с написанием текстов различных размеров, форматов и тематического наполнения возникать не должно. Рутинная, в общем-то, задача: собрать из подходящих под решение инструментов «архитектуру» текста и написать «код», обеспечивающий устойчивый «поток данных» между отдельными блоками. Только в качестве языка здесь используется русский, а не Python, Java или Scala, а владеющих им в мире данных, увы, намного меньше, чем знающих вышеупомянутые языки программирования.

Свои тексты я пишу во время медленных пробежек, коктейль в крови из эндоканнабиоидов, алкоголя и молочной кислоты (мозг - главный ее утилизатор) весьма способствует креативной деятельности.

Читателя жалеть я не собираюсь. Мой стиль сформировался под влиянием классиков современной британской литературы: Ирвина Уэлша, Тибора Фишера и Джона Кинга (теперь вот еще и Джойс привязался…) Однако, для описания его лучше всего подходят цитаты отечественных мыслителей.

Автор первой - Роман Суслов - главный «отказник» отечественного рока, в далеком 1986 году в забытой уже телепередаче «Музыкальный Ринг» на вопрос, думает ли он, что на такую музыку будет когда-нибудь массовый спрос ответивший:

«Нет, ни в коем случае. И рады этому!»

Автор второй - Сергей Жариков - философ, публицист, писатель, бывший художественный руководитель легендарной запрещенной московской рок-группы ДК:

В постинформационную эпоху литература вынуждена быть похожей на компьютерный квест. Чтобы не исчезнуть как дирижабль. Писатель предлагает читателю не просто «продукт изящной словесности», а литературную игру, которую тому необходимо будет «пройти».

Авторство третьей народная молва приписывает легенде отечественного трейлраннинга, организатору ГРУТа и многих других топовых забегов Михаилу Долгому:

«Если есть финишеры, то это моя недоработка».

Здесь точно не будет откровенной, «ну, где же вы, девчонки, 18 мне уже», попсы, «мои мечты не для таких простых умов».
Я не планирую «киннить» тридцатилетних «подростков», засоряющих свои тексты в угоду молодежной аудитории обсценной лексикой и модными словечками вроде «кринж» или «краш», ибо «русский язык в умелых руках и в опытных устах – красив, певуч, выразителен, гибок, послушен, ловок и вместителен».

Мне нравится экспериментировать, смешивать стили, менять акценты, ритм, паузы, «нанизывать по принципу калейдоскопа на хрупкий перебор куда более изощренные ходы». Чтобы было «Просто», хотя и «не о том речь…»

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

#заметкинаполях #depatterns

Открывая новую главу «Шаблоны работы над ошибками», автор перефразирует Бенджамина Франклина:

«В мире данных ни в чем нельзя быть уверенным, за исключением ошибок и проблем с качеством данных.»

В сей главе обсуждаются такие частые случаи, как «необработанные записи», «опоздавшие данные» и даже «дубликаты».

Про «необработанные записи» они же «битые записи» - здесь.

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

Главный плюс такого решения - оно очень простое. Тем более, что, если «долеты» случаются каждый день, то и с логикой их определения и причинами возникновения заморачиваться не нужно. Зато, если их нет, то пересчет запускается впустую. Это статический вариант шаблона, период пересчета задается заранее и не изменяется в ходе выполнения задачи. Я всегда реализовывал именно такой вариант, даже не подозревая, что когда-нибудь прочитаю об этом в книге.

Динамический вариант подразумевает пересчет только тех периодов, которые содержат «долеты», но для этого их нужно сначала определить.

В реализации обоих варианта может помочь динамическое сопоставление задач - «фича», появившаяся в Apache Airflow версии 2.3, если мне память не изменяет. Рекомендую освоить, если еще не…

Продолжение следует…

Поделились тут со мной интересной статьей #напочитать на тему «Убьет ли ИИ дата-специалистов?» Речь идет только про дата-сайентистов, но я бы тут процитировал героиню Елены Яковлевой из «Интердевочки»: «Всех касается!»

Краткое содержание тем, кто не хочет лезть под VPN: нет, не убьет, но измениться заставит.

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


👶 Джуны

Делайте больше меньшими средствами: используйте ИИ, чтобы повысить эффективность и сделать свою работу заметной.

Развивайте soft skills: коммуникация, сторителлинг и т. д.


🧔🏻‍♂️👴🏻 мидлы и синьоры:

Эффективность: используйте ИИ, чтобы повысить эффективность своей работы и работы своей команды.

Внедрение: контролируйте, как ваша компания внедряет ИИ на практике.

Лидерство: устанавливайте стандарты, демонстрируя, как ИИ может влиять на бизнес-результаты.


Кроме того, автор представил список навыков, которые ИИ заменить не может и про которые почему-то (по его версии) никто не говорит (а вот тут было очень обидно):

▪️Влияние на бизнес: демонстрация того, как ваша работа связана с доходом, удержанием клиентов или эффективностью.

▪️Знание предметной области: понимание отрасли, в которой вы работаете, и контекста, лежащего в основе данных.

▪️Выстраивание отношений с заинтересованными лицами: построение доверия и согласованности для эффективного использования ваших идей.

▪️Коммуникация и «травля баек»(сторителлинг) : преобразование анализа в решения, способствующие развитию бизнеса.

Overqualified or Yet Another Data Friday Lyrical Digression

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

До определенного момента я повсеместно утверждал, что, мол, мне все равно, и лишь бы деньги платили, но все же профдеформация, а именно: data-driven, проверка «всего и вся» данными - взяла свое. Проанализировав свой личный опыт, я обнаружил, что, все случаи (а подобное встречалось в моей карьере несколько раз), когда мне нужно было быть «потупее», я провалил, все они закончились уходом из компании, а некоторые - длительным выгоранием. Кажется, что, как минимум, для меня - это неподъемная задача.

«Если бы я был умный, я бы выдавал себя за дурака. Но я был дурак и потому выдавал себя за умного» (Владимир Войнович - «Москва 2042»)

В общем, если у кого-то есть успешные кейсы временного и осознанного отупения (постоянное не предлагать, а неосознанное я и сам регулярно практикую), делитесь, буду изучать продвинутые техники.

Проблемы дата-специалистов с неймингом общеизвестны. На мой взгляд, круглый стол на тему смерти Hadoop должен был называться “DEти хоронят коня Hadoop”.

Как по мне, SmartData 2025 удалась. Старые друзья и новые знакомства - 🔥 Жаль, что состояние здоровья не позволило выжать больше из этой части.

По докладам.

Саша Токарев - кумирище! Терпеть не могу Spark, но слушал с интересом и удовольствием. Даже кое-что понял.

Понравился доклад от Передовых Платежных Решений про Starrocks

Ну, и особое удовольствие получил от круглого стола про Hadoop.

Доклад окончен, с нетерпением жду новых встреч в эфире.

Как бы странно ни звучало , но, когда я покупал футболку с «котиком» в нагрузку к «высоконагруженному кабанчику», я ничего не знал об этой книге.

Наверняка, она даже лежала на том же прилавке, но мое внимание было занято чем-то другим.

Теперь придется читать, возможно, даже пополню бумажную коллекцию.

Ребус дня

#разговорпопятницам

Собеседования - важная часть жизни дата-специалиста. Все, кому не лень, говорят и пишут о необходимости посещать их время от времени, даже если в сей момент работу не ищете и вполне удовлетворены текущим местом, хотя бы поддержания спортивной формы ради. Я когда-то тоже так делал, но последние лет семь практикую бразильскую систему, набирая кондиции непосредственно во время поиска работы от одного интервью к другому. Первые два-три обычно бывают откровенно провальными. Да простят меня коллеги, чье время я так бездарно потратил.

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

Самым странным из посещенных мной собеседований я могу назвать одно, случившееся со мной, когда я был еще неопытным джуном, хватавшимся за любую возможность. Естественно, за давностью лет я не помню ни названия компании, ни личности и внешности человека, меня собеседовавшего. Зато хорошо помню, как он вошел в переговорку с пачкой листочков, которые при ближайшем рассмотрении оказались распечаткой оглавления книги Итцика Бен Гана по основам T-SQL. По этой самой распечатке он и гонял меня от первой главы и до последней, делая пометочки карандашиком напротив каждого пункта. Продолжалось сие действие часа два. Задав последний вопрос, интервьюер откинулся на спинку стула и занялся подсчетом баллов. Я же ловил ртом воздух и вытирал пот со лба рукавом специально подготовленной к этому случаю единственной рубашки, ожидая оглашения результата.
Интервьюер написал на листе какое-то число, обвел его кружочком и взглянул на меня. «Готовы продолжать?» - спросил он.

Оказалось, что у него с собой еще есть оглавление книжки по C#.

«Нет» - ответил я. Сославшись на то, что «у меня самолет и вообще дела-дела» с высокого старта ломанулся куда глаза глядят. Личный рекорд в беге до метро мной установлен был именно тогда.

А в ходьбе по граблям мне вообще равных нет (разве что певица Порева). Поэтому на подобного рода собеседования я попадал еще пару раз, но ни разу ранее двух часов оттуда не выходил, хотя и понимал, что работать в такой компании ни за что не буду.

P.S. Пост посвящается двум легендарным интервьюерам, запечатленным на фото. Мое почтение каждому, их узнавшему.