Напомню, кто забыл - 1 декабря начинается Advent of Code. Если вдруг не знаете что это - это 25 дней ежедневных заданий на программирование. В день - две задачи. Первая обычно попроще, вторая - отражает рабочие реальности :) когда выясняется что тз на первом шаге совсем не то не совсем то и надо снова решить задачу с учётом новых обстоятельств. Сложность задач варьируется - от совсем простых минут на 15 до довольно неочевидных алгоритмов. Но в целом до уровня hard задач на литкоде точно не дотягивает. Решаю уже третий год - искренне рекомендую попробовать. Я свои две звезды за сегодня уже забрал

Напомню, как выглядит таблица

Даже если не ищу работу - с удовольствием хожу на собеседования (к слову - рекомендую всем делать это регулярно). И на последнем меня красиво посадили в лужу. Нашёл просто грубейший пробел в своих знаниях - как работает count(), и как ни странно - на качестве моих SQL-запросов это никак не отражалось все эти годы :)

Получил пустяковую задачу - прокинуть данные из таблицы-источника в целевую витрину. Точнее, данные и так уже идут, но в некоторых колонках некоторых источников часть данных удаляется. Сделано это потому что целевая витрина - реально огромная (клики по рекламе за месяц) и содержит ещё и несколько проекций (всё работает на Vertica), поэтому невостребованные данные по возможности выкидываются. Эта самая витрина служит источником для личных кабинетов рекламодателей и размещателей рекламы, максимально оптимизирована под из запросы. Ну вот собственно часть текстовых строк, которые раньше затирались пустой строкой, надо довести до итога как есть.

Последние две-три недели мир сильно сузился: блог забросил, учёбу запустил — заканчивался испытательный срок, а список задач что-то перестал убывать. Это, в общем-то, логично: то, что было понятно и привычно, сделал сразу, остались темы, в которых нужно разбираться с нуля. Список под ноль так и не добил, но — испытательный срок прошёл успешно. В обратной связи отметили самостоятельность, наметили зоны роста (всё по делу, согласен на все 100%).

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

Наткнулся в Vertica на интересную фишку - обработка данных при загрузке из файла,

Есть даг, работающий с очередью тасков - запускает их сообразно своим критериям. Очередь хранится в таблицах внутри БД Airflow. Таблицы не дефолтные, а специально созданные. Потребовалось расширить функционал - добавил ещё одну таблицу и получил неожиданную ошибку на операции INSERT:

MySQLdb.OperationalError: (1105, 'Percona-XtraDB-Cluster prohibits use of DML command on a table (airflow.dag_launcher_threads) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER')

pxc_strict_mode в зависимости от заданного режима определяет как БД будет относиться к предупреждениям и нештатным функциям:

Когда работал в Сбере и в Тинькофф - было очень удобно. Днём, перед обедом, перешёл на несколько этажей - и в моём распоряжении корпоративный спортзал. Штанга, силовая рама, скамья, турник и даже гимнастический зал с матами для разминки. В Вайлдберриз корпоративного спортзала не было, но был просто спортзал в том же здании - тоже хорошо. К слову, спортзал и питание - наверное главная причина почему я предпочитал работать из офиса :) Тренировался по программе Вендлера 5-3-1 - не требует много времени, позволяет быть в хорошей форме и не спеша прогрессировать.

С праздником! - 256 день года :)

В рамках онбординга получил несложную задачу. Есть даг worker_heartbeat, который стартует каждую минуту, и отсылает пинг со своего хоста в InfluxDB. Данные в InfluxDB контролирует tick-скрипт deadman, который поднимает тревогу, если с какого то из хостов airflow в течении 15 минут не было сигнала. Проблема в том, что примерно раз в месяц выскакивает ложный алерт, хотя все воркеры работают без поломок.

В linux-командах удобно использовать перенаправление потоков - stdin/stdout - либо подавая на вход данные из файла, либо наоборот, сохраняя результат в файл. Но есть ещё третий поток (правда под номером 2 - нумерация начинается с 0) - stderr. Использовал его считанные разы - но есть одна команда, которую без перенаправления stderr практически не использую.

Когда работал в Тинькофф - проводил технические собеседования по SQL для дата-инженеров и аналитиков. В какой-то момент к обязательной SQL-секции добавили ещё минут 20-30 на проверку базовых навыков программирования.

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

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

Продолжаю свою историю. Первая компания, где я работал дата-инженером - Вайлдберриз. И мне реально повезло с этой компанией.

Есть такая шкала стрессовых ситуаций - за последние месяца три я набрал уже наверное суммарно баллов 200 по ней. Увольняюсь с одной работы, выхожу на другую, прошёл кучу собеседований, переезжаю на новую квартиру плюс огромный список “горячих проектов”, дел, которые нельзя пустить на самотёк. Выручает то самое “мышление письмом”, о котором говорил в заметке про ADR.

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

Получил ОЧЕНЬ вкусный оффер, так что четыре недели, чтобы спокойно доделать/передать дела в Тинькофф, потом три недели отпуска - и здравствуй новая работа! Всё в новинку - полная удалёнка, оплата через ИП, куча новых инструментов. По списку задач это выглядит не как чистый дата-инженеринг, а гремучая смесь DE, BDA, разработки, SRE и возможно чего ещё :) Где-то это бы скорее напугало, но тут компания стабильно работает и зарабатывает, так что похоже процессы отлажены и у них эта схема нормально работает.

На каком то недавнем техинтервью с той стороны прозвучало противопоставление реляционных и колоночных СУБД. Я сказал своё мнение что одно другому не мешает, и дальше как то переключились на другой вопрос. А сегодня наткнулся в ТГ на вопрос “В чем разница между реляционными и колоночными БД?”

Сегодня проходил техническое интервью по python. Вообще с этим всё сложно :) Python люблю, условно 50% задач уровня medium на leetcode я успешно решаю в разумные сроки, но при этом есть ряд тем, в которых я вообще никак - например многопоточность и асинхронность. Ну и в теоретических вопросах, в правильной терминологии могу ошибаться - просто потому что дата инженеров спрашивают в основном SQL, а по python обычно дают какую нибудь простенькую задачу. Задачи и в этот раз были несложные, но вот вопрос про итераторы/генераторы поставил в тупик.

Заливал огромный csv файл в БД, возникла потребность глянуть как там внутри выглядят строки. Обычно, если большой файл не открыть в эксельке, то без проблем открываю в notepad++, но в этот раз файл был на 170 Гб :) На линуксовом сервере можно сделать head, а как это сделать на винде?

В бытность работы в Вайлдберриз, часто приходилось реализовывать загрузку таблицы частями - мой airflow-оператор успешно работал на кусках примерно по 100 тыс. - 1 млн. строк, в зависимости от ширины таблицы. Проблем с нарезкой не было - почти всегда было какое то непрерывно растущее поле - обычно целочисленное, условный row_id. Нашёл минимальное/максимальное значение и делаешь выборку

Проводил пробное собеседование по python для своего менти - узнал новое :) Как то коснулись темы форматирования строк, он быстро накидал примеры на f-strings, format() и %, и в конце - “… но если это именно пользовательский ввод, то безопаснее использовать шаблонные строки (template strings)”. Спрашиваю -“Подожди, что значит безопаснее? Какие могут быть риски?”

В курсе по алгоритмам попалась интересная задача - как очистить массив за O(1)?

Забавно читать взгляд на хакеров в художественной литературе :)

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

В IT до какого то предела (условно мидл плюс) самая эффективная стратегия карьерного роста - примерно раз в год переходить в новую компанию с плюс 20% к зарплате. В Тинькофф приходил с той же мыслью. Однако уже после первого года понял, что никуда особо не хочется. В Тинькофф - классно! На неделе проводил тех собес для кандидата - он в конце спросил, что мне не нравится в компании. Я реально завис :)

В Тинькофф, где сейчас работаю, хорошо выстроена система аттестации для подтверждения/повышения грейда. Не идеально - как я понял человек 20, кто как и я пришёл на роль бизнес-дата-инженера, с трудом вписываются в предлагаемые траектории развития. Но система понятная и в целом рабочая. Сегодня сдал скилл по оптимизации SQL запросов на третий (максимальный) уровень.

По наводке Сергея Бобровского прочитал презентацию Jeff Bay о практике Object Calisthenics. Практика представляет собой 9 простых правил по оформлению кода, что, как ни странно, позволяет (заставляет на самом деле :) ) писать более совершенный код (более лёгкий для понимания и поддержки).

Когда искал первую работу в IT - вопрос зарплаты вообще не волновал. Надо будет кстати написать про это… Потом, до определённого уровня - без проблем раз в год находилась работа с +20% к текущей зарплате.

Долго не писал код на питоне с тестами (зря, кстати) и как-то подзабыл зачем нужна конструкция

if __name__ == "__main__":

В рамках курса “Алгоритмы и структуры данных” каждый день пару хороших задач приходится делать, и без тестов не обойтись. Первую программу написал вроде нормально, оформил тесты для неё, но pytest в vs code ругается :( .

Прохожу сейчас курс “Алгоритмы и структуры данных - 2024” от Тинькофф. Услышал там интересную подсказку, как через условие задачи (сколько там прописано максимальное количество элементов n) можно примерно догадаться, какая ассимптотическая сложность должна быть у алгоритма

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

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

Решая очередную задачу на leetcode, столкнулся с тем, что переменная A в одних случаях вычисляется на основе параметра B, в других, если переменная B is None, переменной A присваивается конкретное значение. Понятно, что всё можно легко реализовать через if … else …, но, “лучшее - враг хорошего”. Какое-то время назад, изучая тему clean code, наткнулся на рекомендацию избегать if … else … (и вообще, по минимуму использовать if). Если следовать этому правилу, в коде реально проще разбираться, но местами кода становится заметно больше. Понятно, что для больших проектов это не так заметно, но когда вся задача на 20 строчек, плюс ещё 10 - очень заметно.

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

Решая задачу из Advent of code, неожиданно споткнулся. Если отбросить лишнее, из строки получаю набор ключей и проверяю их на списках, есть ли они там

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

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

При всей любви к программированию, никогда не писал большие проекты. По работе - чаще всего нужно написать даг для айрфлоу, максимум оператор - 100, от силы 200 строчек кода. Для себя - задачки с литкода или проект Эйлера - обычно ещё меньше, строк 50. А хочется что-то глобальное, хотя бы с десяток тысяч строк - попробовать себя на большом проекте, с кучей внутренних взаимосвязей.

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

В 2019 завёл этот блог, переезжая в Москву и рассчитывая стать DS-ом. Не сложилось. В итоге - стал дата-инженером и рад этому. Реально интересная работа.

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

Отослал 114 резюме, где-то 85% через HeadHunter.

Сколько пользуюсь Jupyter Notebook (ещё с той поры, когда он не был Jupyter) и только на днях попробовал запустить терминал из под него.

Вчера написал заявление на увольнение с нынешней работы. 31 октября получаю документы и на поезд до Москвы