Where is data, Lebowski – Telegram
Where is data, Lebowski
237 subscribers
83 photos
2 videos
83 links
Канал про разное в data-мире:
- от библиотек визуализации до data egineering
- от графиков до элементов разработки
- от .csv до API
Download Telegram
Что-то полезное было днем, а сейчас просто картинка, где делается весь этот ваш/наш ML/DS😁
Недавно упоминался Spotify с его алгоритмами рекомендаций, нашел статью, которая в общем виде раскрывает завесу над тем, как же работают эти всякие ML рекомендашки

https://medium.com/the-sound-of-ai/spotifys-discover-weekly-explained-breaking-from-your-music-bubble-or-maybe-not-b506da144123
👍1
Интересные тренды на три самых популярных направления данных (хотя часто под каждой из них могут подразумевать несколько ролей).
Интересно, что аналитиков и дата саентистов "трясёт" одинаково, а дата инженеры отличаются стабильностью, берём на заметку и расширяем свои навыки👀

Где поучиться уже кажется известно 😉 Кстати, когда (около 1,5 лет назад) присматривался к курсам по DE, на горизонте был только OTUS и на тот момент его программа была слишком про багдату, чего мне не хотелось, поэтому старательно ждал курса от ЯПрактикума🤟

Дождался, теперь учусь магии уплотнять время, чтобы найти часы для учебы😅

Попробую освещать процесс учебы👀

Источник графиков - Google Trends
#de #course #trends
Немного читерства, мой друг, Саша Михайлов на своём канале, уже рассказал немного про free track на курсе DE😉

#de #course #yap
Forwarded from data будни (Саша Михайлов)
прошёл вводный модуль курса по DE

Ну как прошёл — прочитал теорию, но практику пропустил 🌚

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


Собирать задачу с заказчиков

Определять задачу через формулирование Definition of Done:
⁃ Если на входе файл, то где именно и когда обновляется?
⁃ Если показать метhику, то как её считать?
⁃ Если нужен результат, то где именно: на почте или в дашборде?

Полезные вопросы. Уменьшать неопределённость — тоже часть работы.


Как положить данные в хранилище (PostgreSQL)

⁃ делать простые таблицы из входных данных
⁃ проверять качество данных в них
⁃ называть таблицы правильно, чтобы потом в них не запутаться
⁃ строить простые агрегаты на основе подготовленных таблиц (тут использовали views — просто и материализованные)


Как вывести данные на дашборд (Metabase)

⁃ строить графики по агрегатам
⁃ из графиков собрать дашборд для заказчиков


В целом вышло го́дно — можно за несколько часов попробовать на себе шкуру инженера данных. Рекомендую.
Ну очень мощные f-strings💪
Уже довольно давно использую в арсенале f- строки, начинал по известному пути:
1⃣ Обычный print
2⃣ format -> "{%d}".format(123)
3⃣ f-strings

Попалась интересная статья про интересные возможности👇
https://towardsdatascience.com/python-f-strings-are-more-powerful-than-you-might-think-8271d3efbd7d

Есть у них один минус: их нельзя использовать для создания паттернов строк, а в остальном отличный инструмент👌
Рисунок к следующему посту, будем рассматривать как влияет преобразование данных в WHERE на скорость выполнения запроса
😁4
Интересности с SQL

Мой друг, Саша Михайлов, у себя на канале отметил некоторые особенности работы с временем, подробнее почитать можно у него (https://news.1rj.ru/str/data_days/246)💡

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


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

В сферу моих интересов входит наблюдение за погодой, поэтому берем погодные данные с 2021 года по нв (около 1.8млн строк) и тестируем. Кажется, столько строк будет в самый раз, чтобы оценить важность идеи.
🔥3
А вот и поучительная история
от Димы Аношина😉

У меня есть похожая, связана с ML.
Задача: Прогнозировать брак Получил данные, обследовал, составил датасет, ну почти как по учебнику. Попутно выяснилось несколько нюансов процесса, подправил датасет. Навертел моделей и таких и сяких, время 🕒 тестировать.
Прислали данных порцию, почистил, подготовил, кидаю на вход модели, на выходе 💩.
В общем никакие ухищрения не давали качества.

Из статанализа (ещё в самом начале) выудились некоторые зависимости на которых можно построить baseline (очень простой по сути).

Прогнал тест, метрики выше удовлетворительные👍

Итог: не усложняйте с самого начала, найдите простое и объяснимое решение в качестве baseline. Кто знает, может оно и станет лучшим😉

Бритва Оккама; не плодите сущностей сверх необходимых🧐

А вы часто ищете сразу сложные решения?
👍1
Forwarded from Инжиниринг Данных (Dmitry)
Мужик рассказывает какой он молодец, пришел на встречу, а на доске нарисованы всякие сервисы модные для стриминга, больших данных и тп. И он спрашивает - а что вы будете делать с данными?

Да ктож его знает, пока не придумали - отвечают инженеры

Тогда смелый мужичек взял стерку и все стер, оставил только S3 и Athena (Serverless SQL engine). И сказал им - раз не знаете, не надо усложнять, начните easy и как поймете, что бизнес хочет делать с данными, так и построите полноценное решение. А если будет все медленно - купите Snowflake.

Мораль простая, мы как инженеры, любим все усложнять, пробовать новые тулы, рисовать красивые архитектуры, и часто забываем, что нужно бизнесу, или вообще зачем мы это делаем. (1й модуль даталерн).
Давно заглядываюсь на разработчиков (привет техническое образование🖐). У меня есть мнение, что мир не сошелся на алгоритмах или нет особого смысла гонять кандидата по алгоритмам.
Нашел схожие мысли в статье.

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

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


Я предлагаю обобщить эту мысль, по крайней мере, на датастек специальностей: дата инженер\аналитик\специалист DS\ ML\ BI-разработчик и др.

Каждый из них, что-то да готовит хорошо😉 Какие мысли по этому поводу?
👍2
Прочел вводную статью про dbt - это тот инструмент, который отвечает за  T  в нашей любимой аббревиатуре  ETL\ELT (выбрать любимую😍).

Статья скорее более общая чем конкретная, но понравился подход команды автора к организации хранения  SQL скриптов (см рисунок): раскладывать скрипты по папкам, соответствующим назначению.

Пожалуй такой подход можно перенести на организацию любимых  jupyter notebooks. Сейчас у меня в ходу такая иерархия:

 ./project folder - корневая папка проекта
- materials folder - папка для артефактов (графики, таблицы, вспомогательные данные, модели, метрики и др.)
- - datasets folder - хранение датасетов
-  1.ipynb
- 2.ipynb
- ...


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

А как вы организуете хранение ваших скриптов\ jupyter-тетрадок🤔
#post #dbt
2
Картинка к посту выше
Это интересно🤔💭

А вы (не)делаете что-то из списка?

На мой взгляд, пункты про pvalue, AB тесты имеют более высокий уровень, а вот начинать следует со сбора логов.
Forwarded from Datalytics
Признаки дата-карго-культа (источник)
А как у вас обстоит дело с поиском багов?
Признавайтесь, вы же только и делаете, что используете `print`ы😀
😁3