Data Engineer

Наткнулся на весьма занятную рекомендацию по найму от Александра Прохорова, автора «Русской модели управления» (которую сейчас читаю, к слову).

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

Помимо этого, вплоть до такого фактора – к какому домашнему труду с детства приучен.

Тут же представил как бы выглядело резюме моего деревенского детства в условиях, приравненных к Крайнему Северу:

✔️ Принимал участие в трансформации сырых чурок до уровня атомарного полена посредством колуна, периодически привлекая подрядчиков в лице команды друзей размером от 3 до 5 человек.

✔️ Спроектировал с нуля модель детального слоя по методологии «классическая поленница» и разработал потоки дров в нее из сырого хранения;

✔️ Организовал регулярное обновление на ежедневной основе дашбор-дров конечных пользователей;

✔️ Двумя бакетами объемом до 12 литров доставлял воду из системы-источника на расстояние до 200 метров в гору;

✔️ Организовывал и принимал участие в футбольных матчах в условиях экстремально низких (до - 50) температур;

Интересно, как быстро всякого рода коучи начнут помогать накручивать и подобный опыт?

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

«Что с тобой сделал русский рок бизнес, парень?»

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

«Только,» - писал Тарковский-старший в своем замечательном стихотворении - «этого мало».

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

«начинать надо не с того, как станет хорошо, а с того, как не станет плохо».

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

Намедни в одном подозрительно уютном заведении сто-лицы развернулась жаркая дискуссия на тему: «Что выдаст запрос EXPLAIN ANALYZE DROP DATABASE my_data?» - а коль скоро так, то результатом стал немедленно вытащенный из рюкзака ноутбук за-ради скорейшей проверки рабочих гипотез на практике.

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

Спойлер: все продовые базы остались целы.

И как тут не вспомнить любимое?

Посмотрел почти все доклады со SmartData-2025. В самом конце наткнулся на весьма интересный «Критерии хорошей платформы данных от Яндекс Доставки» Владислава Гоцуляка.

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

Зато теперь я знаю как…

Кто там аналогии с Джойсом заказывал? Начну с самой очевидной, пожалуй…

Пока не получается совсем уйти в дата-детокс, букдолг затягивает - перечитал, вот, «Data Quality Fundamentals». Со второго захода книга понравилась больше, видимо, будучи инженером, в прошлый раз я ожидал найти чисто техническое решение данного вопроса. Ну, какой, блин, Data Mesh в книге про качество данных?

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

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

«Если хочешь стать тренером - убей в себе игрока». Ну, или хотя бы научись его контролировать…

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

Не знаю, что у них там с функционалом, но за название низкий поклон от меня.

Прекрасное нашел на просторах интернета...

Декабрь уж наступил,
Усталость накопилась,
Не хочется писать о данных мне совсем…
Мне грустно и легко,
Египетская сила!
Как будто в мире нет пера достойных тем.


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

В общем, автор уходит в дата-детокс, ретрит «или что там них»…

«Что завтра будет - неизвестно, хотя нетрудно предсказать…» (Маргарита Пушкина)

Привет! Книжного Клуба анонс!

У нас с коллегами дата инженерами появилась идея по/перечитать книги, связанные с дата инженерией!

Первая книгу, которую мы хотели бы обсудить - Data Engineering Desing Patterns.

Планируем делать созвоны на еженедельной основе - вторник 19:30 MSK (17:30 CET).

Первый созвон - следующий вторник 25 ноября, разберем первые паттерны по полной и инкрементальным загрузкам.

Все детали книжного клуба будут в @de_zoomcamp, если вам интересно, залетайте в канал

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

Всем, кто уже начал готовиться или же только планирует начать, рекомендую к прочтению книгу сооснователя и бывшего президента AES - одной из так называемых «бирюзовых» компаний - Денниса Бакке «Работа в радость». Особенно будет полезна адептам подхода Data Mesh, ибо Data Mesh - это и есть «бирюзовая» data, чтобы увидеть сие не нужно даже обладать «зрением» Освальда Шпенглера.

Как известно из определения, Data Mesh - это социотехнический подход, но почти все в нем обращают внимание на «технический» (этому посвящены и статьи, и доклады, и книги даже), но мало кто смотрит на «социо». Из-за этого за словами «у нас Data Mesh» довольно часто скрывается обычный Data Bardaque.

Когда я предложил перевести сочетание «Data Mesh» на русский как «улей данных», потому что данное сочетание слов лучше, на мой взгляд, отражает суть, чем ужасное «сетка данных» то даже не подозревал, что Деннис Бакке опередил меня лет так на двадцать - тридцать со своей концепцией «сот». Так что книга являет собой прекрасное пособие для тех, кто хочет понять, как должен быть устроена концепция Жамак Дегани с точки зрения «социо».

Как обычно, немного любимых цитат:

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

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

Быть дисциплинированным — значит получать удовольствие от паса, а не от броска. Быть дисциплинированным — значит всегда помнить, что вы — часть команды.

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

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

Основные идеи Apache Iceberg одной картинкой

1️⃣ Метаданные важнее данных. Может лежать много паркетов, но если нет их описания в манифестах, то никто их читать не будет

2️⃣ Древовидная структура данных и метаданных, сходящаяся к одному корневому файлу. Записать и удалить много файлов - не-атомарная операция, но заменить один главный файл можно атомарно всегда в любой системе хранения. Отсюда почти-транзакционность.

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

4️⃣ (Мета)Каталог как вспомогательный сервис. Для MVCC и честного ACID, для хранения статистики, RBAC и других обслуживающих функций


💾💾💾💾💾💾💾💾💾💾💾

Архитектор Данных

Следующую книгу в моем списке я в очередной раз позаимствовал из статьи «Лемана Про», ссылку на которую я уже несколько раз давал в канале. Книга называется «Дата Йога: грамотная работа с данными» от Александры Усачевой и Андрея Демидова.

Выбрал ее я по двум причинам:

▪️Книги по данным от отечественных авторов попадаются мне крайне редко.

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

Книгу можно скачать здесь.

Подошел к концу первый мой полноценный сезон в роли Head of Data. Можно заняться подведением итогов.

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

Орбита лидера подтверждает мою догадку

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

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

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

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

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

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

Канал переименовывать смысла не вижу потому что «бывших инженеров не бывает».

Дочитал «Data Engineering Design Patterns». Книга действительно являет собой вольное продолжение «Fundamentals of Data Engineering», как автор и заявлял во вступительной части. Стоит добавить сюда ещё «Data Pipelines Pocket Reference», и тогда сложится своеобразный порядок чтения, которому я рекомендовал бы следовать.

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

Отличное дополнение - примеры кода, причем для различных технологий.

В общем, у книги есть все шансы на долгую жизнь.

Придумал название для описания сего явления: «Мертвосервисная архитектура».

Upd Вариант, предложенный в комментах - «некросервисная» - звучит гораздо круче🔥

Пятничное

Две плохие новости за последний месяц: Fivetran купила SQLMesh и dbt.

Почему это плохо.
SQLMesh относительно молодая компания, ей около трех лет. То, что ее продали, означает, что они не смогли сделать выручку или не хватило амбиций фаундеров.
Думаю, что сейчас фаундеры SQLmesh ходят грустные.

Про dbt не скажу, но SQLMesh наступала ей на пятки.
И такая консолидация плохо повлияет на развитие инструментов.

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

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

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

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

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

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

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

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

Ребус дня