data будни

Сравнение даты и строки в 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)

———
Продолжение: Олег Юрьев проверил через EXPLAIN

Не доверять проду

Когда начинал джуном, всё было просто: чужой код, который ты видишь в проде 100% лучше твоего. Смотри, вникай, учись.

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

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

Такой вопрос я задал Фёдору Борщёву, а он ответил, что любой код — это компромисс между хотелками и временем. К каждой строке кода надо подходить с подозрением и критическим восприятием: почему здесь сделано именно так? Какие цели решал автор? Какие у него были ограничения?

https://t.me/pmdaily/937

Хочешь научиться — попробуй научить

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

С уважением и немного завистью смотрю на ребят, которые уже третий год ревьюят работы студентов с «анализа данных». По их советам видно их технический уровень — как они могут предложить оптимальное и лаконичное решение любой проблемы на 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 машин, чтобы распределённо обработать данные за прошлую неделю (и ещё подождать полдня).

🎉 Новый курс «Инженер данных» на Яндекс Практикуме

Ура! Дождались) Выкатили курс по нашей специализации.

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

программа

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

Нравится, что программа начинается не с ETL-скриптов, а с моделей данных: как забрать с источника и как положить к себе в DWH. Вижу отдельные спринты по проектированию слоёв в хранилище и мониторингу за качеством данных (<3)

И потом весь топовых текущих технологий (место для шутки про Modern Data Stack):
⁃ Airflow, кажется это сейчас стандарт на рынке;
⁃ PostgreSQL, ClickHouse, MongoDB — основные типы баз данных;
⁃ ещё ElasticSearch, LogStash и Kibana для многообразия вариантов хранения данных;
⁃ Hadoop и Spark для распределенных хранения и вычисления;
⁃ Celery и Kafka для real-time стриминга данных (потоковой обработки);
⁃ В конце чуток про GCP и AWS; и много про Яндекс Облако (видимо, первые два для ознакомления, но деплоить надо будет на «своём» облаке)

И через 6.5 месяцев обучения должен получиться такой многорукий инженер-данных-всё-могу =)

Я пока прохожу бесплатный вводный спринт ради любопытства, там предлагают собрать базовый инженерский сетап из Airflow и Metabase на Докере — кажется закончу ближе к выходным. Если справитесь быстрее, напомню, что у меня есть промокод на 7% — @sashamikhailov

Стоит 95 000 ₽, первый запуск 21 марта
https://practicum.yandex.ru/data-engineer/

😱 ААА! Код-ревью

Прошёл тут эпичный код-ревью: 20 комментов в самом пулл-реквесте и ещё 43 сообщения в соответствующем треде в Слаке. Было жёстко, но интересно!

Всё началось как приключение на 20 минут: поправить в двух сущностях поля партиционирования и добавить ключей. А потом оказалось, что их в принципе неправильно спроектировали при создании и мои изменения порождают Х2 дублей в продовых таблицах.

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

Пришлось реально врубаться в код и узнавать у взрослых как будет правильно (а не просто копировать). Кажется, за эти дни я больше узнал про систему и инфраструктуру, чем за предыдущий месяц. Спасибо въедливому Кириллу (следущий ПР, естественно, я тоже к нему принёс))

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

🤓 Прошёл курс «Python-разработчик» от Практикума

Мой путь в инженерию данных начался в 2019 году с другого курса Практикума — по анализу данных. Так получилось, что первая работа была про сбор данных, а не их анализ; и пришлось писать пайплайны на питоне, а не вертеть датафреймами в пандасе.

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

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

⌘⌘⌘

Сам курс делится на три неравные части:
⁃ 6 месяцев по Джанго;
⁃ 2 месяца алгоритмы;
⁃ 1 месяц по инфраструктуре и деплою.

В конце три недели на диплом — полноценный бэк для сайта с рецептами (фронт давали готовый).

За время курса вдоволь написался хорошего кода на питон (как будто на работе было мало, хе-хе).

Наконец-то разобрался с классами: сразу после этого на работе породил первый собственный класс — коннектор с BigQuery. Потом сразу написал такой же для GoogleAnalytics. И потом ещё третий — отнаследовал от первых двух и получил етл-класс по экстракту из GA и заливке данных в BQ (идемпотентной, естественно).

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

В итоге на каждом спринте вымучивал эту Джангу. Вот в Пандасе всё удобно: если ошибка, то он сразу говорит где — не тот формат в колонку засунул или ещё что-то.

В Джанге же несколько независимых модулей, которые должны друг с другом работать. В итоге пишешь-пишешь, а оно не работает! И непонятно, какой из модулей виноват — просто в общего грендайзера они собираться отказываются. И сиди разбирайся, переписывай всё с нуля =/

Тут хочу поделиться безмерным уважением к ребятам, которые проходят этот курс реально с нулёвыми знаниями о программировании — вот где настоящие герои.

⌘⌘⌘

Хотя я слежу за успехами Практикума и благодарен им за пройденный опыт, в целом, у меня как-то мало поводов писать про них, а сейчас получилось сразу два: рассказать про прохождение курса по разработке ↑ и про повышение цен с 1 марта ↓

Практикум поднимает цены на часть курсов, в т.ч. и на анализ данных (70 → 84К), и на пайтон-разработчика (90 → 126К). Если давно хотели, то сейчас самое время.

Для тех, кто прошёл бесплатную вводную часть, у меня есть промокод на 7% скидки — @sashamikhailov

Туда же можно направлять вопросы про Практикум и обучение там — всегда рад поболтать про них ^_^

машинное обучение: финальное решение состоит настолько же из кода, сколько из данных

Андрей Татаринов — ко-фаундер Epoch8 и Agima.ai — пришёл в гости к Moscow Python рассказать чем отличается «хайповый МЛ из рекламы» и реальные задачи.

За время работы в Epoch8 я больше всего любил встречи, где участвовал Андрей. У него всегда было чёткое видение проблем и точные формулировки для любых тезисов: одно удовольствие слушать (и потом делать, хе-хе)

⌘⌘⌘

В отличие от конкурсов на Kaggle, в реальном мире задача сформулирована крайне куце: найти все склады на спутниковой карте Москвы. А все данные — это два скриншота таких складов.

Чаще всего данные нужно откуда-то достать, а потом ещё и разметить. Разметка — дорогая процедура; например, чтобы опознать и разметить 2000 деталей на ОДНОЙ фотографии с рассыпанным Лего, может уйти неделя чистого времени одного специалиста.

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

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

Подкаст в Apple Podcasts и Overcast

#подкаст

чувствую себя тупым

Почему? Вижу два фактора:
1. В Яндексе в принципе всё непросто: как в силу технологичности, так и из-за большого размера.
2. Почти все инструменты — внутренние, то есть нельзя просто загуглить ошибку из логов.

Раньше же было как: вот есть, например, Airflow и Docker. В интернете уже все проблемы давно порешали и на всё есть детальные инструкции (в основном на английском, правда).

Тут так не получается. И выходит так, что как минимум раз в день Саша «выходит на середину комнаты» и публично признаётся в своей технической несостоятельности, задавая «глупые» вопросы.

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

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

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

Вроде у стартапов есть такой подход — fail fast. Надо быстро-быстро пробовать новое и искать работающие варианты: пускай на один работающий будет девять неудач, но чем быстрее эти девять случатся, тем быстрее найдём тот один работающий вариант.

То же самое и с вопросами: лучше быстрее спросить и узнать как надо, чем сидеть с потенциально-неправильной информацией (и принимать на её основе другие решения!)

Чувствую себя тупым и, кажется, это нормально.

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

Будь я в России, то наверное пошел бы по проторённой дорожке: Hadoop, Postgres, Spark, Clickhouse,Kafka

Но так как я имею преимущество нахождения текущей инфры в хорошем облаке, почему бы этим не воспользоваться?
Тем более что от нескольких друзей я услышал про новый паттерн Data Lakehouse.

В классической истории есть Data Lake где хранится всякое и есть DWH где хранится всякое обработанное, вытащенное и очищенное из Data Lake

Что предлагает Data Lakehouse?
В существующих дата лейках, чтобы использовать какое-то BI или ML приложение, нужно под них налаживать ETL
LakeHouse позволяет всем приложениям (ML, BI, ...) иметь постоянный доступ ко всем данным без отладки ETL каждый раз заного, что гарантирует консистентные данные, собранные из различных источников в даталейке.

ETL встроен в мета слой. Без data management/governance слоя каждая команда к источникам подрубается своими etl процессами и создает свои датамарты, затем непонятно как их поддерживает что создает проблемы с переиспользованием и дупликацией.

Вторая часть приятных вещей - транзакционность, для этого вводится delta tables/files/transaction log/engine/storage layer

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


Из того что я видел, Lakehouse предлагает Google (на Bigquery к которому я подозрительно отношусь), Databricks и AWS
С ребятами из Датабрикс мне советовали встретиться давно, тем более что основатели Датабрикс - создатели Spark. В итоге они сами на меня вышли и на этой неделе я планирую провести с ними уже вторую встречу и послушать их Solution Architect

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

Кстати мне сейчас нужны дата инженеры, заниматься этим и многим другим. RVожно как фул ремоут, так и с релокейтом в Лондоне. Есть офисы в Майами и Буэнос Айресе. Платим мы примерно как ФБ, если говорить про зарплату про и бонус, смотри #BigTechLevelsCompensation в дополнение есть криптобонус и опционы, которых мы даем даже чуть больше ФБ в абсолютах и это при текущей оценке! Можно податься здесь

Head of ML в Blockchain.com готовит ЕТЛ-инфраструктуру. Интересно почитать рассуждения со стороны МЛ плюс тред на 100+ комментов.

А ещё там вакансии для инженеров данных с релокейтом в Лондон

🧪 ЭКСПЕРИМЕНТ! 👨‍🔬 пятничная флудилка

↓ здесь можно передать привет коллегам, маме или коту (если они, конечно, читают))

или скинуть последний мем…
или поделиться интересной ссылкой…
или спросить за жизнь…

ну или просто поздороваться с товарищами-читателями 👋

В опросе лидируют BI-разработчики, что в принципе логично 🙂

Рассказываю, как это было у нас: собрались, значит, все отделы вместе, чтобы рассказать кто что делает, какие есть успехи, в чём возникают проблемы и с чем надо помочь.


Выходят продакты
… делаем приложение удобным для заказа, проводим кастдевы, ездим в поля, а ещё активно считаем ретеншен и хотели бы получать валидные данные из источников в ДВХ!


Выходят маркетинговые аналитики
… значит, у нас тут перформанс, бюджеты, сегментация. Хотим, чтобы все расходы были в одном месте и подтягивались автоматически, чтобы мы могли сравнить их с выручкой — рассчитываем здесь на помощь ДВХ!


Выходит отдел b2b продаж
… в общем, у нас тут много продажников, у каждого есть клиенты в работе, они идут по воронке. А ещё есть несколько источников с ручным импортом, которые часто ломаются.
Вот бы ДВХ нам всё настроил по красоте и вывел данные по клиентам и менеджерам на единый дашборд!


Выходят BI-разработчики
… короче, есть куча дашбордов, часть метрик между ними повторяется, но почему-то значения у них различаются. Было бы классно, если бы ДВХ сделал так, чтобы одни и те же метрики на разных дашбордах показывали одинаковые значения 🙂


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