🖥 Этот график помогает лучше понять чувствительность и специфичность графически.

Вижу подзапрос → меняю на CTE

Многие студенты (да и не только студенты) обожают многоуровневые SQL-запросы. Пожалуйста, пожалуйста, пожалуйста, не пишите их. Используйте табличные выражения: https://antonz.ru/cte/

Описание Data Lineage в стиле "для самых маленьких".

Самому "наследию" дана ёмкая аналогия: "Data lineage is like a family tree but for data".

Есть проработанные описания основных сценариев применения с иллюстрациями:
🔹диагностика ошибок;
🔹анализ того, на что повлияют вносимые изменения;
🔹проверка качества данных;
🔹управление метаданными;
🔹проверка на соответствие нормам законодательства;
🔹очистка данных или их миграция.

🔗Ссылка

#инструменты #тренды

Eсть такой известный в узких кругах древний как бивни мамонта постер - Модель BI Зрелости от авторитетных ребят из TDWI. Прошло прилично времени, много BI продуктов родились и умерли, но постер все еще хороший и таки актуальный:

... сейчас кажется 95% компаний прям таки столпились на краю второй пропасти ("chasm") для шага из teenager в adult стадию. В этой точке сходятся кривые гибкости и стандартизованности. Выход - сложные переговоры и консолидация аналитики и BI ландшафта. Где-то в этой же точке происходит переход от Self-Service к Customized Delivery, открывающий перспективу роста для числа casual users в бизнесе. Похоже на правду.

Кажется авторитетные ребята шарят и уже тогда что-то знали..

P.S. Всем BI Зрелости в новом году)🎅 Побольше адекватности и драйва! С наступающим!

Постер в высоком разрешении
🔗 TDWI_BI_Maturity_Model_Poster

#biстратегия

Proof of Concept: Как проверить, что внедрение ML стоит свеч

Классный пост о том как правильно "продавать" внутренние проекты по машинному обучению.

https://habr.com/ru/company/ods/blog/438212/

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

Доска для сбора требований к дашбордам

https://miro.com/app/board/uXjVOOmjOqY=/?moveToWidget=3458764518437556371&cot=14

Пара здравых мыслей о приоритезации задач аналитиков из серии статей "How to Prioritize Analytical Work".

Например, вот советы из первой части по распределению времени на 4 типа проектов:
🔹Стратегические — 50%
🔹Операционные / Ad Hoc — 20%
🔹Обслуживание — 20%
🔹Исследования и эксперименты — 10%

А во второй части статьи - подробно расписанный пример бизнес-требований к таким проектам.
Для его составления последовательно отвечаем на вопросы из групп:
🔸Что требуется?
🔸Какая у этого бизнес-ценность?
🔸Какие верхнеуровневые шаги нужно предпринять?

🔗Ссылка на часть 1
🔗Ссылка на часть 2

#компетенции