data будни

Marc Lamberti написал короткий и понятный пост про путь данных из источников к Data Mart через Data Lake. а Руслан Фатхутдинов перевёл его . Получилось интересно.

проверить на одном айдишнике На одном из первых боевых проектов делал дашборд по когортному анализу на данных клиента. И вот вроде всё посчитал, получились когорты, время и метрики. Вывел на стандартный треугольный график с хитмапом — вроде похоже на правду. Уже можно показывать клиенту? Спросил совета у коллеги. Он сделал простую вещь — фильтранул данные до одного пользователя и стало очевидно, что расчёт неправильный: этот пользователь попадал сразу в несколько когорт. Что было незаметно на общих данных, стало явно на одном единственном айпишнике. Метод — универсальный. Студенты-инженеры с курса Практикума делают RFM анализ. Должны получиться айди пользователе и для каждого — метрики от 1 до 5. Написали запрос, получили результат; вроде похоже на правду. И сдают. А в результате расчёта пользователи с недавним заказом получают худшую метрику. И наоборот. А можно было проверить результат расчёта метрик на паре пользователях и увидеть ошибку. —- Ещё на тему: - Сравнение даты и строки в Postgres

#подкаст про работу программистом в Гугле Послушал интервью Ларисы Агарковой — менеджера и техлида уровня 6 в Гугле. - Про автоматические алерты: ни один тикет не игнорится; должно быть действие — либо решать проблему, либо менять правило генерации тикета. - Онкол всегда два человека: даже если вдруг один недоступен, второй должен оперативно отреагировать. - Если обсуждать проблемы в личке, то вокруг этого человека формируется Silo (замкнутая автономная экспертиза). Когда этот человек уйдет, и экспертиза тоже уйдет вместе с ним. Поэтому нужна документация на все действия (и обсуждение проблем через публичные каналы связи). - Работа в «рекламах» (Ads) учит налаживать процессы по стабильности. Если вдруг что-то упало, то через 5 минут CEO Ebay звонит твоему вице-президенту и тот приходит в твой кубикал, и не уходит пока ты не пофиксишь баг. Вице-президент — человек, конечно, приятный, но часто бывает его видеть у себя не хочешь, поэтому строят процессы и потом ещё процессы на процессы. - Всё обмазывается юнит-тестами и интеграционными тестами. - Как тестируют перед релизом: есть два тестовых кластера, изолированных от прода. На один кластер раскатывается бинарник с прода, на второй — новый свежесобранный. На кластеры на них посылаются одинаковые запросы с прода и сравнивается метрики. Плюс отлавливаются ошибки и мониторится потребление ресурсов. На тестинге всё крутится 2-3 дня перед релизом на прод, чтобы отловить возможные баги. Слушать в Overcast и iTunes Рекомендуемое чтение: SRE Book https://sre.google/sre-book/table-of-contents/ The Pragmatic Programmer https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/ Naval Ravicant (просто умный дядя из Долины) https://www.navalmanack.com/

В соседний отдел «внедрения запрещенных технологий» ищут коллегу, кто будет помогать прикручивать всякие распространённые штуки типа Flink и Spark к внутренним велосипедам Яндекса. Вижу тут два жирных плюса: ⁃ работать с известными «открытыми» инструментами отрасли инженерии данных; ⁃ работать в Яндексе: крутые технологии, куча данных, высокая экспертиза, толковые люди. Такое пересечение не часто встретишь =) То есть работа не про написание пайплайнов, как у «обычного» инженера данных, а именно про инструменты для написания пайплайнов. В описании пишут, что ищут разработчика с опытом инженерии данных, но, может, подойдёт и сильный инженер с опытом промышленной разработки: > Нам нужны сильные разработчики на Python/Java/Scala, которые готовы осваивать новые языки и технологии. Хорошо, если есть опыт работы с хранилищами данных, стримингом или батч-обработкой. Если интересно, откликайтесь на вакансию; или пишите мне @SashaMikhailov — могу переслать вопросы прямо ребятам или закинуть ваше резюме напрямую рекрутерам (понадобится короткое сопроводительное сообщение)

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

explain analyze select *
from sensors.weather w 
where w.ts between '2021-01-01 00:00:00' and now();

Второй - в условии экстрактим год и берем всё больше 2021

explain analyze select *
from sensors.weather w 
where extract ('year' from w.ts) >= 2021;

В исходной таблице есть индекс по полю ts. Добавим щепотку статистики, чтобы не сравнивать два случайных времени, выполним и тот и другой 100 раз, строим боксплоты. Вперед. Основной результат: отсуствие преобразований в WHERE дает 4х прирост к скорости выполнения запрос (естественно на этих данных и таком кол-ве, можно будет проверить как зависит от объема данных) Детальный результат - 2 рисунка плана выполнения запросов, как только появляется преобразование в WHERE то мы имеем дело с SeqScan, без EXTRACT планировщик использует Bitmap Heap Scan \ Bitmap Index Scan Вот такая арифметика, используйте SQL c умом #de #sql #lifehacks

Олег Юрьев погонял проверочные запросы через EXPLAIN ANALYZE. И на реальных данных проверил как влияет изменение поля фильтрации на скорость запроса. С Олегом мы вместе учились в Практикуме. Он уже давно ревьюит работы студентов и набил на этом руку. Это насмотревшись на него, я тоже решил пойти в ревьюеры. Подписывайтесь, уверен, что будет ещё много интересного: https://t.me/double_data/52

Применение любых функций к полям, участвующим в фильтрации или условии джойна, приводит к проблемам производительности. Оптимизатор не может использовать индексы или, в случае аналитических СУБД, ключи дистрибуции и секционирования. В результате производится полное сканирование таблицы, или большое перераспределение данных, что плохо по определению, для больших таблиц. А предотвратить это достаточно просто — не изменять данные, по которым производишь поиск

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

#подкаст про распределенные вычисления Егор Хайруллин из Яндекса пришёл рассказать что там есть кроме «мап-редьюс». Ниже мои заметки, что я услышал: Зачем нужны распределённые вычисления Когда данные для работы (и даже промежуточные результаты) не помещаются на одну машину. Или когда проще и дешевле вместо одной большой машины поставить две поменьше. Сначала можно написать вручную алгоритм для раскладывания файлов по машинам (вот прям sh-ники через scp). Второй раз делать такое уже не хочется, надо пилить инфраструктуру. Почему у всех «свой» Hadoop Например, у Гугла, Фейсбука, Яндекса. Почему не сделать «единый» опенсорсный. У всех свои проблемы: на 100 машинах — одни, на 10 000 — уже другие. Что там есть кроме мап-редьюс ⁃ Файловая система, где хранятся данные. ⁃ Шедулер, который планирует джобы (тысячи их) для работы с этими данными. ⁃ Интерфейс управления (SQL-like), откуда приходят задачи для шедулера. Почему плохо работают джойны? Удобно джйонить, когда данные на одной машине. Если данные разложены по кластеру, уже всё сложнее. Таблицы должны быть отсортированы одинаково и (их части) должны оказаться на одинаковых машинах, чтобы провести джойн Сами джойны тоже можно написать по-разному — какой применить именно тут? Чем отличаются операции класса мап-редьюс от реал-тайм? МР — операции могут занимать десятки минут РТ — «реалтайм»; пользователь кликнул на сайте, информация залилась в базу МР — загрузки большими кусками, последовательное чтение и запись РТ — много случайных записей и чтений. На каждое действие своя запись. МР — если упало, можно просто пересчитать последний кусок РТ — если упало, всё пропало, надо выискивать по кускам последние записи и исправлять. Мап-редьюс подход меняет мышление Удобно дебажить, когда у тебя одна машина и один лог. Когда машин несколько, начинается тёмная магия — куча логов, записей, связей по сети. Если упало, всё просто не работает. (А может оказаться, что на машину №ХХ данные пришли на секунду позже). Слушать в iTunes и Overcast

Сравнение даты и строки в Postgres Первый «улов» с поля проверок заданий студентов на курсе по DE. Коллега-ревьюер заметил, что у студента в работе теряются часть записей, когда в SQL запросе идёт проверка даты и строки: <..> WHERE created < '2022-04-03' Короткий поиск подкинул вопрос со StackOverflow. Оказывается, чтобы сравнить время со строкой, под капотом Постгрес приводит строку ко времени; тогда он наивно из ‘2022-04-03’ получается '2022-04-03 00:00:00’, то есть начало суток, а не конец, как ожидалось. Посмотреть подкапотную логику можно, прогнав запрос через EXPLAIN, там будет такая строка:

Filter: (created < '2022-04-03 00:00:00'::timestamp without time zone)

Как решение предлагают в запросах явно приводить дату-время к дате перед сравнением со строкой WHERE created::date < '2022-04-03' тогда под капотом будет сравнение дат с ожидаемым результатом:

Filter: ((сreted)::date <= '2022-04-03'::date)

Не доверять проду Когда начинал джуном, всё было просто: чужой код, который ты видишь в проде 100% лучше твоего. Смотри, вникай, учись. Но дальше всё стало сложнее. Оказывается, в продет тоже может быть плохой код (отдельная история, как он туда попал, но всё же). Делаешь ПР на основе текущего кода и на ревью узнаешь, что сделал плохо, хотя просто повторил что уже есть. И теперь прошлое правило не работает. Приходится читать текущий код и понимать: где написано хорошо,  а где — так себе. Ведь код после тебя должен становиться лучше, чем до. Такой вопрос я задал Фёдору Борщёву, а он ответил, что любой код — это компромисс между хотелками и временем. К каждой строке кода надо подходить с подозрением и критическим восприятием: почему здесь сделано именно так? Какие цели решал автор? Какие у него были ограничения?

Хочешь научиться — попробуй научить В этот раз я решил не записываться студентом на новый курс от Практикума (двух, пожалуй, хватит). Вместо этого зашёл с «черного хода» и записался туда ревьюером — буду проверять домашки у студентов. С уважением и немного завистью смотрю на ребят, которые уже третий год ревьюят работы студентов с «анализа данных». По их советам видно их технический уровень — как они могут предложить оптимальное и лаконичное решение любой проблемы на Pandas. Мне кажется это не в последнюю очередь из-за их работы со студентами. Зафиксирую свои ожидания, чтобы потом можно было сверить с фактическим результатам (да, как в настоящих АБ-тестах): ⁃ развить техническую насмотренность; ⁃ прокачать навык код-ревью; ⁃ посмотреть чему там учат. На первых работах заметил, что правда в каких-то местах могу подсказать как сделать оптимальнее или короче. Чертовски приятное ощущение. П.С.: ещё работает как метод эскапизма — найти вторую работу, придумать себе занятие, чтобы меньше времени оставалось читать новости.

Три недели спустя. HR-сводки. Самат Галимов с командой делают большую работу; в этот раз позвали в свой подкаст фаундера hr-агентства NewHR — Киру Кузьменко. Агентство работает со многими айти-компаниям тут и зарубежом, поэтому «колокольня» Киры одна из самых высоких в айтишечке; в подкасте она рассказывает что оттуда видно. ⌘⌘⌘ Компании срезают профессии «жирного времени», которые могут совмещать другие сотрудники: ⁃ тестировщики (разработчики могут тестить сами) ⁃ UI/UX дизайнеры (есть и другие дизайнеры более широкого профиля) ⁃ продуктовые аналитики (сейчас не до анализа продуктов; сохранить бы что есть) ⌘⌘⌘ «Астрологи Армении объявили неделю IT — количество специалистов в удвоилось». По официальным данным 25к специалистов прибыло в Армению и ещё 60к — в Грузию. Для сравнения — до этого в Армении было около 15 тысяч айтишников. Но нет никакого местного «IT-рынка». Нельзя будет найти «местную» вакансию. Это только как база для работы на какую-то мировую компанию. Сайдэффект: приехавшие заддосили инфраструктуру Еревана; всем нужно открыть юрлица и счета в банках, но количество «окон» не рассчитана на такой поток. Кто-то вывозит сотрудников отдельными чартерами (как Миро). Кира сняла большой дом для команды; получился такой коливинг. ⌘⌘⌘ Многие компании фризят найм. Некоторые даже отзывают выданные офферы. Ничего непонятно, нет возможности планировать. Был рынок кандидата, стал рынок работодателя (адекватного). Раньше количество вакансий было больше кандидатов, сейчас — наоборот. ⌘⌘⌘ «Джуны не нужны» (( Компании лучше будут вкладывать в удержание текущих сотрудников, чем в образование стажёров. Джунам и так было непросто найти работу, а стало в 10 раз сложнее. Совет джунам: кроме курсов надо сделать что-то своими руками. Есть публичные проекты от компаний, можно взять их. ⌘⌘⌘ Будет ли русофобия в зарубежных компаниях? В общем нет, а в частности может быть всякое. Точно нельзя будет физически платить в России. Если надо работать на зарубежную компанию, надо физически релоцироваться в нейтральные земли. ⌘⌘⌘ Обидно за державу. За последние годы наши специалисты стали цениться в мировых компаниях. Для примера топовые отрасли: ⁃ финтех ⁃ тревел ⁃ крипта ⌘⌘⌘ У кого всё будет хорошо? ⁃ диджитал- и перфоманс-маркетологи. По-прежнему надо покупать рекламу. Кто знает какую и почём — в шоколаде. ⁃ ДС и МЛ всё ещё в шоколаде. ⁃ Девопсы (настоящие) и SRE всегда нужны. ⁃ У айти-рекрутеров тоже работы будет достаточно. А вот менеджеру будет тяжело перейти — очень разные обязанности. Проще стать «обратно» синьором, перейти и там уже вырасти до тимлида. ⌘⌘⌘ Кира и команда NewHR стараются помогать в это непростое время и сделали цикл мероприятий: от горячей hr-линии до разбора резюме в прямом эфире. Больше подробностей в их блоге https://blog.newhr.ru/ ⌘⌘⌘ Слушать подкаст в iTunes и Overcast

Меня пугает, что пропаганда работает на людей (на меня скорее всего тоже). Она есть с обеих сторон и она давит на эмоции. Включайте критическое мышление (видео как это делать), находите данные и делайте выводы. Как никогда стало важным анализировать и рассказывать истории с помощью достоверных данных. К сожалению, такими они становятся не сразу, а сильно позже событий. Лучший пример сторителлинга данных, который я знаю, — проект Fallen 2015 года (интерактив и видео) про потери второй мировой войны. За счет изложения фактов визуализация объясняет происходившее и тоже вызывает эмоции. В основном страх, но в конце и надежду. Но помимо эмоций визуализация вызывает доверие за счет использования данных, а не уловок и фейков. Покажите эту визуализацию тем, кто забыл к каким жертвам приводит война.

про рынок найма в IT Подкаст был записан в довоенное время (просто приятно было послушать на отвлечённые темы), но тема актуальна и сейчас: руководитель HR-агентства рассказывал какие отношения складываются у зарубежных компаний с отечественными разработчиками. ⌘⌘⌘ С одной стороны после локдауна везде пришла удалёнка. Больше нет «региональной» разработки — к спецам Новосибирске сначала пришли столичные рекрутеры со своими предложениями, а следом за ними уже стучались их зарубежные коллеги с ещё большими зарплатами. в подкасте звучали зарплаты 300-500 у синьоров на нашем рынке и 500-700 на западном (просто для ориентира, без контекста) С другой — удалёнка пришла не только к нам. Фейсбуки с гуглами могут выбирать людей со всего мира. И тот же спец из Новосибирска будет конкурировать за место с ребятами из Индии или Аргентины. Возьмут не всех. Это простые тезисы, жизнь получается сложнее. Есть люди, которые предпочитают офис рядом, дружных коллег и зарплату на 30% меньше, а не удалёнку / релокацию в далёкие непонятные земли. Есть люди, которые возвращаются назад с опытом в FAANG и приносят сюда забугорный опыт. ⌘⌘⌘ Немного статистики про рынок найма: ⁃ если раньше разработчики хорошо шли на зарплату в 180К, то теперь «начинают думать» от 300К ₽. ⁃ чтобы вывести разработчика на вакансию рекрутер сейчас отправляет ~700 холодных сообщений потенциальным кандидатам (раньше было ~300) ⁃ чтобы расширить воронку найма некоторые компании нанимают местного англоговорящего лида, который потом набирает себе команду разработчиков без знания английского. Профит! ⌘⌘⌘ Слушать в iTunes и Overcast

Нет войне! Не представляю, каково это видеть дымные столбы из своего окна и бояться, что следующая ракета прилетит уже в твой дом. В детстве у меня были сны о том что в наш небольшой город пришёл Годзилла; и это ощущение беспомощности и неотвратимости перед большой угрозой вызывало у меня буквально панический страх. Война — это как Годзилла, только на самом деле. Насилие — это тупиковый путь в любом деле, так вопросы не решаются. В моменте это кажется неплохим вариантом, но негативные последствия каждый раз превышают сиюминутную выгоду. Больше всего пугает, что это осознанное и просчитанное решение. Где-то там существует документ, где строились эти планы и обсуждались альтернативы: « … а чтобы достичь ключевых подателей в 2022 предлагаем напасть на Украину … » и внизу печать УТВЕРЖДЕНО.

🤌 Цели как инструмент приоритезации задач Валидная цель должна помогать в рабочих вопрос, а не просто красиво смотреться на стене или в буклете. Хорошо сформулированная цель помогает определить какую из двух задача делать сегодня. Ещё одна полезная заметка Жени Козлова (автора поста про грейды аналитиков ↑). В ней приводятся примеры как цели помогли наладить работы отделов BI и DWH в Яндекс GO. про BI: > Мы решили, что работаем для того, чтобы в компании лучше принимались решения: более объективно, с опорой на данные. Посчитать долю качественных решений от всех решений — невозможно, поэтому мы придумали прокси-метрику. Это DAU отчетов, обладающих некоторым набором свойств, которые характеризуют качество этого отчета. Мы назвали такие отчеты сертифицированными. про DWH: > … в хорошем хранилище, аналитик пишет мало кода в SQL-запросах, делает минимум джойнов и вообще почти все запросы у него идут к красивому, причесанному, задокументированному слою витрин, а не к сырым слоям данных. https://telegra.ph/Pochemu-ne-tonut-korabli-ili-chto-takoe-horosho-sformulirovannaya-cel-12-23

👓 Витрины на вьюхах В вводном курсе Практкикума по DE повествование идёт от лица нового дата инженера, которому надо собрать дашборды для руководителя. На входе файлики, складывать в Постгрес, для дашбордов — Metabase. Это мне 1-в-1 напомнило первую работу инженером данных. Собрал данные из разных мест, сложил к себе и сверху налепил вьюху. Вьюхи хорошо работают как MVP, когда надо быстро собрать нужные данные в удобном для представления виде. Как раз случай быстрого вводного урока. Первые витрины я собирал именно так. Какое же хорошее изобретение эти вьюхи: не надо данные никуда переклаывать, никакого кода, кронов, дублей, идемпотентности — ле-по-та! Наклепал я так себе несколько вьюх каскадом. И был доволен. А потом решил доработать первую из них. И не смог. Вьюхи, на которых есть зависимости нельзя менять. Это был первый урок датаинженерской жизни. ⌘⌘⌘ Чем хорош Телеграм — он помнит всё. Вот Саша из 2020 спрашивает совета о получившейся архитектуре. https://t.me/deordie_chat/1673 К тому моменту я шестой месяц работал в отделе маркетинга торгового центра единственным аналитиком / инженером данных. У меня получилось собрать нечто, напоминающее простенькое ДВХ на основе Постгреса, наполняемого скриптами на кроне. Уже что-то слышал-читал про слои данных, но ещё боялся подступиться к Airflow. И вместо BI-слоя у меня были вьюхи =)

прошёл вводный модуль курса по DE Ну как прошёл — прочитал теорию, но практику пропустил 🌚 Кажется, задачей вводного курса было ответить на вопрос «чем же занимается инженер данных?». Получилось показательно: Собирать задачу с заказчиков Определять задачу через формулирование Definition of Done: ⁃ Если на входе файл, то где именно и когда обновляется? ⁃ Если показать метhику, то как её считать? ⁃ Если нужен результат, то где именно: на почте или в дашборде? Полезные вопросы. Уменьшать неопределённость — тоже часть работы. Как положить данные в хранилище (PostgreSQL) ⁃ делать простые таблицы из входных данных ⁃ проверять качество данных в них ⁃ называть таблицы правильно, чтобы потом в них не запутаться ⁃ строить простые агрегаты на основе подготовленных таблиц (тут использовали views — просто и материализованные) Как вывести данные на дашборд (Metabase) ⁃ строить графики по агрегатам ⁃ из графиков собрать дашборд для заказчиков В целом вышло го́дно — можно за несколько часов попробовать на себе шкуру инженера данных. Рекомендую.

💂‍♀️ источники → витрины на собесах меня спрашивали «в чём заключалась твоя работа?» и я так не очень уверенно рассказывал: «ну вот есть источники, мы там собираем данные, кладём к себе в хранилище, там как-то обрабатываем, собираем сущности и делаем денормализованные витринки для бизнеса». и походу это был правильный ответ =) потому сейчас занимаюсь примерно тем же самым: ⁃ есть источники; ⁃ оттуда надо забрать данные; ⁃ данные разные по формату, надо бы сделать одинаковые; ⁃ собрать сущности и метрики в одном месте; ⁃ по сущностям построить витринки, удобные для аналитиков; ⁃ ПРОФИТ! только масштаб другой: у одного бизнеса можно пересчитывать историю с начала времён одной командой за 30 минут; а в другом — нужно поднимать N машин, чтобы распределённо обработать данные за прошлую неделю (и ещё подождать полдня).