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

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

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

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

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

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

Больше интересно такое сравнение автора:

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

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

Каждый из них, что-то да готовит хорошо😉 Какие мысли по этому поводу?

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

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

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

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

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

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

Картинка к посту выше

Это интересно🤔💭

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

На мой взгляд, пункты про pvalue, AB тесты имеют более высокий уровень, а вот начинать следует со сбора логов.

Признаки дата-карго-культа (источник)

А как у вас обстоит дело с поиском багов?
Признавайтесь, вы же только и делаете, что используете `print`ы😀

Какую штуку нашел😎
Пакет ipython-sql

SQL внутри Jupyter. Magic %%sql позволяет писать SQL-запросы прямо в ячейке Jupyter и получать результат в виде pd.DataFrame, всё как мы любим❤️

Подготовил для вас google colab, в нем автоматически подготавливается БД (ну а вдруг её у вас нет😉) и показаны примеры работы с расширением.

Расширение имеет право на жизнь, но есть минусы:
- нет подсветки синтаксиса SQL (да, к хорошему привыкаешь быстро)
- нашлись ошибки (расширение падает с ошибкой при использовании оконных функций)

Попробуйте посмотреть🤨
#python #sql #jupyter

Картинка, для привлечения внимания к следующему посту (красота простой графики)🤝

Пиу-пиу, сегодня по SQLite💡

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

🚫Все limitations (https://runebook.dev/ru/docs/sqlite/limits) по-русски

Она точно вам подойдет, если вы хотите:
- поработать с данными самостоятельно, но не хочется плодить CSV\JSON
- хотите почувствовать себя Data Engineer и реализовывать модели данных\pipelines и тд
- создать petproject используя Flask\Django или другой web-framework

Если заглянуть в доку, то обнаружим что весьма крупные компании пользуются этой крошкой:
-🗳 DropBox - на клиентской стороне
- 📱Во всех Android смартфонах используется SQLite
- 🐍она включена в стандартную библиотеку нашего любимого Python
Полный список тут

(https://www.sqlite.org/famous.html) И напоследок список ресурсов, ознакомьтесь ближе с этой маленькой, но такой БОЛЬШОЙ субд:
- Интервью (https://habr.com/ru/company/macloud/blog/566396/) с создателем SQLite
- Цикл (https://habr.com/ru/post/149356/) статей
- Это вам не игрушка
(https://habr.com/ru/post/547448/)
- Антон Жиянов создал обучающий курс (https://antonz.ru/sqlite-course/)(а еще он существенно расширил возможности SQLite, его telegram (https://news.1rj.ru/str/sqliter) канал)

А вы используете линтеры?✏️

Линтер - программа, которая сделает ваш код как у синьора-помидора🍅
Если на пальцах, для Python - линтер проверит соблюдение правил PEP8 (вы же помните, что они есть или пишите спагетти-код🍝) и выдаст рекомендации по улучшению, ну или сам поправит.

Вводная про линтеры

К чему это всё, прочел статью Груг, против сложности, автор которой потрудился и проверил весь Python-код в статьях на хабре - рекомендую к прочтению, можно найти много практических советов😉

Из полезного:
- у автора есть сервис по авторевью кода (там навороченный линтер, как мелкий брюзга проверить ваш код)
- по результатам есть описание типовых ошибок
- если не хотите ждать авторевью (оно занимает до 24 часов), устанавливаете flake8, качаете авторский .flake8 и начинаете улучшать свой код
......................

Помните в посте выше про ipython-sql мы писали
немного кода, я собрал его в py-файл и отправил на проверку, результат по ссылке или кратко:
- отсутствуют аннотации типов (да, еще не добрался до их применения)
- ненужный код
- лишнее создание объектов

Оценка - 2️⃣.7️⃣8️⃣% при общей в по всем ревью 8.5% - отличный результат🥇

В общем готовьте код правильно!

Как же без картинки, спагетти-кода🙃

🎙Хей-хей, сегодня небольшой квиз

И не говорите, что вы не любите порешать интересные задачки на Python или SQL🤩

Не часто в описании вакансии встретишь намеки на тестовое, а тут на днях обнаружил такое:


Напишите запрос, который найдет три машины, получившие наибольшее кол-во чаевых в апреле 2022 года.
Выведите, как изменялась эта сумма в последующие месяцы в процентах по сравнению с предыдущим в таблице со столбцами:
- taxi_id
- year_month
- tips_sum
- tips_changes

В качестве источника используйте bigquery-public-data.chicago_taxi_trips

Устроим небольшой SQL challenge💪

В комменты добавлю видео где найти этот датасет 🎥

Буду ждать ваших решений, если возникнут проблемы, смело пишите в комменты, разберемся🙃

Итого в решении должно быть:
- запрос 1 (топ 3 машины)
- запрос 2 (сравнение величины чаевых за месяц с предыдущим в процентах)
- будет круто если график изменения чаевых реализуете в виде дашборд 📈 (варианты: Tableau Public, Google Data Studio, Yandex DataLens, Redash) и поделитесь ссылкой
➖➖➖➖➖➖➖➖➖➖

Ну, что погнали😉

#sql #dashboard #challenge

☝️Как говорил известный герой Случайности не случайны

Начав новый рабочий ML проект, через пару дней наткнулся на стартующий курс от ODS - ML System Design Course.
Естественно вписался, думал, послушаю лекции, узнаю чего нового, а тут активностей накидали:
- 🎥 Видео лекции
- 📝 За время курса (до середины января 2023) необходимо подготовить доклад\tutorial (в идеале статья habr\medium) на выбранную тему (например, Airflow или DVC)
- 📆 все студенты собираются в команды и будут пилит pet-project. К окончанию курса, должно быть работающее MVP
- 📚 куча дополнительных материалов, только успевай читать

Первая лекция прошла - она была обо всем по-немногу (что будет в курсе, чего не будет). Тк участвую в достаточном кол-ве ML проектов, то меня привлек слайд про управление ML проектами (рисунок будет в комментариях).
Приглянулся двухфазный подход к ML проектам:
- 🕔 Discovery (фиксированное время). За отведенное время выполняем research по данным, генерим гипотезы, проверяем, формулируем и тд. Так сказать готовим почву для второго этапа
- 🚰 Delivery (фиксированные задачи). Задачи выявленные в ходе research здесь обретают форму и результаты.

Кажется, так просто и понятно, но объяснить заказчику необходимость Discovery бывает очень трудно, тк ему кажется, что всё это как бы прилагается и задача (которую он придумал) точно решается.

Пятница плавно подошла к своему вечеру😎

Люблю когда всё ОК....

#python #unittest #tests

Навеяно просмотром фильма Человек, который изменил всё 📺
Хороший однако фильм и посвящен отчасти нашим data-делам.

В общем рекомендую к просмотру, ну и знать статистику тоже рекомендую😉

#mem

И снова Python-интересности 🧐

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

Смотрите видео и не попадайтесь на такие уловки💡
#python #test #unittest

Кажется, я нашел, на что еще можно смотреть бесконечно😍

Вот что бывает, когда есть умелые руки и современные технологии:
- Python
- raspberry pi
- шепотка DeepLearning (хотя там может просто библиотека OpenCV)

🐔🐔🐔

https://pikabu.ru/story/turel_protiv_kur_9528819?utm_source=linkshare&utm_medium=sharing

#video #почтимем

Черный лебедь🦢

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

Чтобы обсуждение не ушло далеко, я решил бегло просмотреть данные и понять так ли это. Немного контекста: данные находятся в контуре заказчика, до которого надо пройти небольшие круги ада с VPN + RDS —> то есть не самый приятный и удобный способ посмотреть данные.

Данные просмотрены 👀, говорю коллегам: Параметр изменяется реже 1 раза в неделю, дискуссия прерывается, конфа заканчиватся.

Но сомнения от быстрого просмотра не дали мне покоя, пошел писать SQL для подсчета кол-ва изменений по недельно. Результат ☝️ на картинке: При крайне низкой вероятности 1 изменения в неделю я показаательно попал в эту цифру (это несомненно успешный успех)🙃
.
.
💡 Не делайте поспешных выводов из анализа на скорую руку