А для тех, кому лень заморачиваться с доступом, я продублирую в telegra.ph. Только картинки там чото не грузятся...
Upd. Вроде грузятся

https://telegra.ph/Generaciya-sinteticheskih-dannyh-10-10

А ещё я принял активное участие в написании наших (Денвика) статей по созданию интересных визуализаций в DataLens. Сегодня их как раз опубликовали в общем доступе)

Чарты с использованием функций AGO() и AT_DATE()
https://vk.cc/cQfqKe

Добавление всплывающей подсказки в чарт-таблицу
https://vk.cc/cQfqMD

#Яндекс #Yandex #DataLens #Денвик

Всем привет!
Наконец-то я занялся финальным проектом в своём обучении. Сначала создал БД и таблицы в ней для будущей выгрузки.
Написал на Python сбор данных от предоставленного API с последующей выгрузкой полученных данных в PostgreSQL.
Создал пока что первую страницу дашборда, которая должна дать общую картину состояния бизнеса, показать ключевые метрики и их динамику во времени. Это "дашборд для руководителя", который отвечает на вопрос "Как идут наши продажи в целом?"
Когда я доделаю всё, и работу оценят, я выложу исходники + ссылку на дашборд)

@nullpp #Python #PostgreSQL #Учеба

А давайте я немного поясню, что происходит)
Вторая вкладка "Анализ продаж маркетплейса" позволяет понять портрет и поведение клиентской базы. Ответить на вопросы "Кто наши клиенты?" и "Насколько они лояльны?". На ней, кроме индикаторов (которые и так понятны), присутствует ещё несколько табличек.
В списках Топ покупателей по количеству заказов и по сумме затрат можно менять количество значений с помощью селектора.
Таблица RFM-анализа формируется "на лету" по SQL-запросу к БД, учитывая параметры ПЕРИОДА, и выдаёт актуальный результат на заданный период в дашборде.
Когортный анализ формируется "на лету" по SQL-запросу, учитывая параметры ПЕРИОДА. Анализ строит помесячные когорты, так как покупки сами по себе дорогие и нечастые. Показывает % уникальных клиентов от первого периода.
LTV также формируется "на лету" по SQL-запросу, учитывая параметры ПЕРИОДА. Сам анализ строит помесячные когорты, так как покупки сами по себе дорогие и нечастые. Показывает среднюю выручку на уникального клиента.

Третья вкладка "Анализ товаров" позволяет оценить эффективность товарного ассортимента. Ответить на вопросы "Какие товары продаются хорошо?", "На каких товарах мы больше всего зарабатываем?" и "Какие товары неликвидны?".
В списках Топ и Антитоп можно менять количество значений с помощью соответствующего селектора.
Особенность таблицы ABC/XYZ-анализа в том, что она (как и на предыдущей вкладке было) формируется "на лету" по SQL-запросу к БД, учитывая параметры ПЕРИОДА и МАСШТАБА. То есть выдаёт актуальный результат на заданный период в дашборде.
+ Есть градация по цвету для ABC/XYZ (зелёный-жёлтый-красный) для быстрого понимания результата.
P.S. на второй вкладке по цветам также сделан RFM-анализ

Всем привет!
Мою работу проверили и дали отличный фидбек. Все советы и замечания я уже поправил, поэтому могу представить на общее обозрение)
Гит: https://github.com/mishandri/DA-final-project
Сам дашборд (светлая тема): https://datalens.yandex/6eiukr5xyukyr?_theme=light
Сам дашборд (тёмная тема): https://datalens.yandex/6eiukr5xyukyr?_theme=dark

А ещё я очень рад, что завершил данный курс обучения. Это было очень классно, познавательно и очень-очень интересно.

В планах у меня теперь завершить курс по "BI-аналитике" (остались финальные задания), а затем я приступлю к курсу "Инженер данных", который тоже обещает быть не менее клёвым

Всем привет!
Ведёте ли вы записи того, что возможно потом пригодится?
Перед тем, как я начал учиться на аналитика данных, я просто сохранял все найденные интересные страницы в закладках, а интересные посты в ВК или в ТГ просто в избранном. И там до сох пор большущая куча неразобранных статей, до которых уже очень долгое время не доходят руки, чтобы всё разобрать и каталогизировать.
Я стал задаваться вопросом: а как бы поудобнее всё это начать хранить, чтобы потом ещё и искать было легко.
Простое гугление предлагало использовать всякие сервисы по типу OneNote (в общем-то я его уже использовал, но он слишком тормознутый и глючный как по мне), Evernote (тоже как-то было дело, но отказался из-за ограничений в бесплатной версии) или Notion, который ушёл из России и судя по новостям начал удалять все данные даже тех, у кого была подписка...
Были предложены и другие сервисы, но практически все они либо были платными, либо бесплатные версии были настолько ограничены, что ими было бы невозможно пользоваться.
К тому же, ситуация с Notion показала, как можно потерять все свои записи по желанию их создателей.
И я наткнулся на Obsidian, который умел всё, что мне было необходимо + все данные можно хранить локально в формате MarkDown.
Что мне очень понравилось:
+ Гибкая настройка практически всего, чего можно. Очень много всяких настроек.
+ Приятный и интуитивный интерфейс + куча готовых цветовых схем на любой вкус.
+ Возможность устанавливать всякие расширения.
+ Использование тегов для каталогизации документов.
+ Создание и использование нескольких хранилищ.
Но не обошлось и без минусов... И самый главный - это платная синхронизация между устройствами.
Все советовали создать приватный репозиторий на гитхабе и выгружать всё в него. Но это надо было постоянно делать лишние действия пуши перед редактированием и пуллы после...
Но тут я решил пойти более простым путём и реализовать это всё "своими силами") Почему в кавычках? Потому что это делает за меня Я.Диск =)
Я просто создал папку в Я.Диске, в которой у меня хранятся все мои хранилища данных.
Например, если я правлю документ на компьютере, он сразу же выгружается на мой Я.Диск, а затем синхронизируется с Я.Диском на ноуте. И наоборот. Работает идеально!
На телефоне сделал аналогичную штуку: в Я.Диске можно настроить автоматическую синхронизацию помеченных папок.
К тому же, Я.Диск позволяет восстанавливать удалённые или изменённые файлы, то есть я имею возможность работать с резервными копиями, если вдруг что.
+ в браузере есть расширение Markdown Web Clipper, которое в один клик делает из страницы md-файлик, готовый для размещения в Obisdian.

@nullpp #обучение #obsidian #записи

Всем привет!)
Пригласили меня в эфир =) Поделиться своим опытом обучения, и не только

🎓 Как наши студенты «входят в аналитику с ноги» — истории, которые вдохновляют

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

На нашем вебинаре вы услышите реальные истории студентов Simulative, которые начинали с нуля и уже работают аналитиками. А пока — ловите короткие истории первых героев (в кружочках выше)👆

Ждем вас на вебинаре, чтобы услышать полные версии!

📅 Сегодня, 11 ноября, 19:00 МСК
🎁 Среди участников — розыгрыш сертификатов на обучение!

До встречи!

Всем привет!
На этой неделе новости такие: Мне выдали (пока что в электронном виде) мой диплом о переквалификации).
Получается, я уже теперь точно дипломированный и профессиональный аналитик данных.
Бумажный вариант пришлют скоро)
Я очень рад, что всё-таки решил пойти учиться. Узнал много нового и очень хорошо закрепил полученные знания на практических кейсах из реального бизнеса.

Кстати, это один из трёх шагов (дипломов) на пути становления Fullstack-аналитика данных

@nullpp #обучение #диплом

Всем привет!
Это пост-проверка. Я всё-таки решил добавить комментарии в канал, чтобы можно было что-то тут обсудить (желательно по теме, ахахах). В старых постах, как я понимаю, не будет обсуждений, ну и ладно)

@nullpp #обсуждение

Всем привет!
Когда я делал свой дипломный проект и арендовал виртуальный сервер, при первичной настройке выполнения скриптов по расписанию, я не мог понять почему они не выполняются в нужное время.
Мне подсказали, что нужно бы проверить таймзону самого сервера - и действительно, оказалось, что она была UTC+0 вместо привычной для меня UTC+3. Это я к чему?
К тому, что у СУБД таймзона может как совпадать с сервером, так и отличаться. Да и вообще, при работе с датой-временем надо иметь в виду, что таймзоны могут повлиять на результаты не только работы, но и аналитических выводов, которые можно получить, если мы неправильно их будем интерпретировать из-за этого.
В PostgreSQL есть два основных типа для работы со временем:
- TIMESTAMP(или TIMESTAMP WITHOUT TIME ZONE) - хранит только дату и время, без привязки к часовому поясу. Это просто число, означающее "настенные часы в определённый момент". При сохранении 2023-10-25 15:30:00 база не знает, было это в Лондоне, в Москве или в Токио.
- TIMESTAMPTZ (или TIMESTAMP WITH TIME ZONE) - рекомендуемый к использованию тип. Он не хранит пояс отдельно внутри себя. Вместо этого он конвертирует переданное значение в время по UTC (Всемирное координированное время) для хранения. При извлечении данных он преобразует это UTC-время в часовой пояс текущей сессии.
Опять же многое будет зависеть от параметров как на самом сервере, так и от параметров СУБД.
Для определённой сессии можно задать таймзону так:

SET timezone = 'Europe/Moscow';

(кстати, на это нужны определённые права для учётки PostgreSQL.
И при выполнении запросов, например

SELECT doc_dt FROM ticket;

мы получим данные вида 2025-05-12 09:23:48.000 в том случае, если типом поля doc_dt является TIMESTAMP. Впрочем, такой ответ мы получили бы и не устанавливая таймзону перед этим. То есть СУБД принимает "на веру" то, что TIMESTAMP всегда в том часовом поясе, который указан в параметрах.
Мы можем преобразовать таймзону вручную при конкретном запросе (для этого не нужно особых прав):

SELECT doc_dt::TIMESTAMP AT TIME ZONE 'Europe/Moscow' FROM ticket;

В результате получим результат вида: 2025-05-12 09:23:48.000 +0300. Как видите, в самом конце будет указан часовой пояс, причём такой, какой указан в настройках. Точнее, он его просто "припишет".
С TIMESTAMPZ ситуация иначе. Смещение во времени автоматически записывается в БД. И тогда при применении AT TIME ZONE к полю TIMESTAMPZ, он наоборот преобразует в нужный временной пояс.

SET timezone = 'Europe/Moscow';
SELECT doc_dt FROM ticket;

Результат: 2025-05-12 09:23:48.000 +0300

SELECT doc_dt::TIMESTAMP AT TIME ZONE 'Europe/Moscow' FROM ticket;

Результат: 2025-05-12 09:23:48.000 +0300

Сменим таймзону:

SET timezone = 'UTC';
SELECT doc_dt FROM ticket;

Выдаст такой же результат:

2025-05-12 09:23:48.000 +0300

А вот

SELECT doc_dt::TIMESTAMP AT TIME ZONE 'Europe/Moscow' FROM ticket;

Даст нам:

2025-05-12 06:23:48.000 +0300

Как видите AT TIME ZONE - мощный оператор для явного преобразования.
Если применить к TIMESTAMPTZ, он "снимает" пояс и возвращает TIMESTAMP в указанной зоне.
Если применить к TIMESTAMP (без пояса), он "надевает" на него указанный пояс и возвращает TIMESTAMPTZ.

Что делать?
1. Храните всё в UTC. Настройте часовой пояс сервера на UTC. Это стандарт де-факто для backend-разработки и избегает путаницы.
2. Используйте тип TIMESTAMPTZ. Позволяет PostgreSQL делать всю грязную работу по конвертации.
3. Преобразование в локальное время делайте на уровне приложения. Ваше приложение лучше знает, в каком часовом поясе находится пользователь. Передавайте данные в UTC, а финальное отображение делайте на клиенте.

#SQL #PostgreSQL #timezone @nullpp

Всем привет!
Мой дашборд разместили в DataLens Gallery =) Йээээ
https://datalens.ru/gallery/gx1h48lns7le1