Приветствуем!
Вы на канале про Data Driven культуру, который бережно и старательно ведёт команда российского BI продукта Analytic Workspace.
Но мы не будем рассказывать здесь про наш продукт и нахваливать его, хотя нам есть чем хвастать 😉

Здесь мы делимся информацией из мира больших и малых данных — из мира, в который мы ежедневно окунаемся.
Про что мы здесь пишем:
— Интересные примеры визуализаций.
— Дата сторителлинг.
— ML в BI. BI без ML. ML без BI.
— Кейсы из практики внедрения (как удалось объединить необъединяемое, например).
— Культура DD в общем смысле.
— Тренды на рынке BI.
— Статистика с рынка BI: рост/падение популярности профессии, профиль специалиста и т.п.
— Что почитать.
— Где и чему учиться.

Для удобной навигации используем теги:
#новичкам – знания, точно полезные для тех, кто только погружается в тему.
#профи – информация для тех, кто уже в теме BI.
#ru_bi – информация из мира российских BI.
#визуал – пример классного (или страшного) дашборда.
#практика – примеры из практики, датасеты и прочее.
#мнение – оно и есть мнение.
#технологии – о технологиях в BI.
#статья – полезная статья из мира данных.
#книга – рекомендация книги.
#интервью – интервью с представителями отрасли.
#история – интересная история из мира данных.
#жиза – смешные и не очень зарисовки из Data Driven будней.
#дайджест – подборка ссылок на полезное, увиденное нами.
#мероприятия — анонс или запись классного мероприятия.
#знания — ценные знания из мира данных.

———————————
analyticworkspace.ru — это наш сайт.
@awcommunity — сообщество взаимопомощи специалистов, которые работают с Analytic Workspace.

В чем разница между данными и информацией?

В области управления данными часто используется аббревиатура DIKW (Data - Данные, Information - Информация, Knowledge - Знание, Wisdom - Мудрость) – это сокращение, которое представляет каждый уровень информационной пирамиды.
💠Пирамида знаний – информационная иерархия, где каждый уровень добавляет определённые свойства к предыдущему. Каждый следующий уровень характеризуется большим уровнем зрелости (пригодностью к продолжению жизни) и кратно меньшим объёмом сведений.

1 уровень: ДАННЫЕ
Это дискретные результаты наблюдений в виде фактов и цифр.

2 уровень: ИНФОРМАЦИЯ
На втором уровне находится информация, которая получается из данных, которым придан смысл посредством добавления контекста.

3 уровень: ЗНАНИЕ
Совокупность данных и информации к которым добавляются экспертные мнения, опыт, другие знания.

4 уровень: МУДРОСТЬ
На четвертом уровне находится мудрость, которая является результатом применения знаний в реальной жизни. Другими словами это способность действовать наиболее подходящим образом с учетом того, что известно (знания) и что приносит наибольшую пользу (этические и социальные соображения).

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

#знания

Георгий Нанеишвили, директор по развитию партнёрской сети Qlik в СНГ, про Ad-hoc аналитику (и про Self-Service тоже)

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

Давайте начнем с общего понимания терминов:

Ad hoc (букв. — «к этому») — латинская фраза, означающая «для данного случая», «специально для этого». Как правило, фраза обозначает способ решения специфической проблемы или задачи, который невозможно приспособить для решения других задач и который не вписывается в общую стратегию решений, составляет некоторое исключение.

Adhoc запрос — это «разовый» запрос, зачастую на языке запросов SQL для извлечения данных, связанных с какой либо задачей, обычно аналитической, но совсем не обязательно: у нас как-то слетело время на одном из серверов приложений и мы потаблично запрашивали данные с некорректным временем, а потом отдельным запросом исправляли их.

Adhoc аналитика — это тоже решение конкретной аналитической задачи, обычно в поиске ответа «почему это произошло», то есть задачи диагностической аналитики или так называемого «Business Discovery». То есть не составить отчет, которым будут пользоваться регулярно, а найти ответ на конкретный возникший от бизнеса вопрос или ряд вопросов:
— Почему упали продажи?
— По рознице все а пределах стандартных отклонений, а вот падение по интернет-торговле выходит за рамки.
— Почему выходит за рамки, разберитесь
— Потому что сервер лежал в пятницу вечером такого-то числа.
— Хорошо, сколько мы потеряли?
— Примерно столько-то, но, возможно, чуть меньше так как в субботу был повышенный спрос, видимо отложенный.

Adhoc аналитику часто приравнивают в Self-Service аналитике, хотя это и не совсем так. Дело в том, что как раз Self-Service должна позволять рядовому обученному сотруднику делать Adhoc аналитику и, возможно, даже Adhoc – запросы, когда он сможет поверх рассчитанных мастер-данных загрузить свои данные для решения какой-то разовой задачи или проверке теории. Это сильно упростит процесс принятия решений, радикально сократит время и разгрузит аналитиков и/или ИТ-отдел: представляете, что для решения подобных задач бизнес будет приходит и просить подготовить подобный отчет-расследование или загрузить данные? Аналитики тут же превратятся в «бутылочное горлышко», а вал запросов парализует команды, отвечающие за данные и их анализ.

Таким образом, Adhoc не означает Self-Service, потому что подготовленные аналитики как раз в основном им и занимаются, помимо разработки регламентной дескриптивной отчетности, а вот Self-Service как раз и означает Adhoc, так как пользоваться уже подготовленными отчетами это отнюдь не «Self-Service», как многие считают. Даже если подобную возможность пользователю и дать, то он тут же выгрузит данные в привычный ему инструмент который на «Ex» начинается и на «cel» заканчивается, в котором он и будет проводить дальнейший анализ, дозагружая туда данные из собственных источников и подпольных баз данных.

Полноценный же Self-Service подразумевает хорошее владение ограниченным кругом инструментов (в идеале – одним-двумя), с помощью которых обученный и подготовленный пользователь – «Гражданский Аналитик» сможет полноценно и самостоятельно решать свои задачи, не обращаясь к специалистам по данным или аналитическому отделу.

Тут сразу стоит сказать, что подобных инструментов, которые предоставят конечному пользователю возможность работы как с имеющимися в компании мастер-данными, например сертифицированными данными из хранилища или каталога данных, с возможностью загрузки собственных данных – не так много. И всегда возникают вопросы как доверия к «заливаемым» пользователям данным, так и вопросы безопасности доступа к данным компании, среди которых могут быть очень чувствительные. Так что Self-Service пока распространяется среди аналитиков и очень продвинутых «гражданских аналитиков» на уровне множества подразделений компании, и очень непростой и далекий путь сделать Adhoc-аналитику доступной каждому сотруднику. Хотя потихоньку мир движется именно в этом направлении.

#мнение #знания

Почему Clickhouse?

Точнее вопрос будет звучать так: почему в системах аналитики часто используется Clickhouse, а не традиционные БД(Postgres, MySQL, Oracle и т.д.)?
Ответ: из-за архитектурных особенностей баз данных.

В классических реляционных базах данные хранятся построчно, приблизительно так:

[A1, B1, C1], [A2, B2, C2], [A3, B3, C3]…

где A, B и С — это поля (столбцы), а 1,2 и 3 — номер записи (строки).

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

В случае аналитических систем наибольшая нагрузка создается тяжелыми выборками (select) сотен тысяч и миллионов записей, часто с группировками и расчетом агрегатов. Количество операций записи при этом невысоко, нередко менее 1% общего числа.

Однако что произойдет, если выбрать, например, только 3 поля из таблицы, в которой их всего 50? В силу построчного хранения данных в традиционных СУБД будут прочитаны абсолютно все строки целиком со всеми полями, пропущены через контроллер дискового ввода-вывода и переданы процессору, который уже отберет только необходимые для запроса.

Решить эту проблему призваны колоночные СУБД, к которым и относится Clickhouse. Основная идея колоночных СУБД — это хранение данных не по строкам, а по колонкам. С точки зрения SQL-клиента данные представлены как обычно в виде таблиц, при этом физически на диске значения одного поля хранятся последовательно друг за другом — приблизительно так:

[A1, A2, A3], [B1, B2, B3], [C1, C2, C3] и т.д.

Такая организация данных приводит к тому, что при выборе в SELECT 3 полей таблицы из 50, с диска физически будут прочитаны только 3 колонки. Это означает что нагрузка на канал ввода-вывода будет приблизительно в 50/3=17 раз меньше, чем при выполнении такого же запроса в традиционной СУБД. Кроме того, при поколоночном хранении данных появляется возможность сильно компрессировать данные, так как в одной колонке таблицы данные как правило однотипные, чего не скажешь о строке.

#новичкам #технологии #знания

Как писать красивые и читаемые SQL запросы :)

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

1. Отступы и пробелы необходимы для структурирования запросов
Старайтесь выносить операторы на новые строки, добавлять отступы и пробелы между структурными блоками. Согласитесь, легче воспринимается это:

SELECT 

    TA.id, 
    TA.client_name,
    TA.client_surname, 
    SUM(TB.client_spent_amount)   AS total_client_spent_amount, 
    SUM(TB.client_Discounts)      AS total_clients_discounts 
    
FROM table_A                      AS TA 
LEFT JOIN table_B                 AS TB 
    ON TA.id = TB.id 
WHERE TA.country = "France"
GROUP BY TA.id

чем это:

SELECT TA.id, TA.client_name, TA.client_surname, SUM(TB.client_purchases) AS total_client_purchases, sum(TB.client_Discounts) as total_clients_discounts 
FROM table_A AS TA LEFT JOIN table_B AS TB ON TA.id = TB.id WHERE TA.country = "France" GROUP BY TA.id

2. Пишите синтаксис SQL в верхнем регистре
Верхний регистр используется для ключевых слов SQL, а нижний — для таблиц и столбцов. Функции SQL также настоятельно рекомендуется писать в верхнем регистре.

3. Не используйте SELECT * при написании кода итоговых версий запросов
Перетаскивая все столбцы с собой, мы легко можем спровоцировать нарушение их работы. Потеря контроля над ними чревата получением лишних невостребованных данных и дублированных столбцов, усложняющих код. Перечисляем только нужные столбцы!

4. Используйте меньше подзапросов и больше CTE
Вложенные многоуровневые запросы усложняют чтение кода. Для тех кто в теме: проблема похожа на пирамиду вложенных вызовов в языках программирования. К примеру, в JavaScript ее решили введением promise`ов. Вывод: делайте структуру кода плоской, так код проще воспринимать.

5. Присваивайте столбцам логически обоснованные имена
При создании запроса мы можем просто переносить столбцы. Вместо этого рекомендуется называть их в соответствии с предполагаемым назначением.

#новичкам #знания

Данные накапливаются, мудрость - нет

Пирамида DIKW отражает стандартную модель структурных отношений между мудростью, знаниями, информацией и данными:

🔸данные создаются с помощью абстракции или измерения реального мира;
🔸информация — это данные, которые были обработаны, структурированы и встроены в контекст таким образом, что стали значимы для людей;
🔸знания — это информация, которая была интерпретирована и организована таким образом, чтобы появилась возможность действовать в соответствие с ней;
🔸мудрость — умение найти надлежащее применение знанию.

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

#знания

Почему одни SQL-запросы выполняются быстрее других или первое знакомство с планом выполнения

Спойлер: у этого поста нет цели научить вас за 5 минут оптимизировать запросы или разбираться в работе движка той или иной БД. Это больше вектор на область знаний, понимание которой поможет вам расти профессионально, глубже разбираться в том, что вы делаете.

План запроса - это внутренняя структура, создаваемая оптимизатором SQL базы данных для выполнения определенного SQL-запроса. План запроса содержит информацию о порядке выполнения операторов в запросе, а также об используемых индексах, таблицах и других объектах базы данных.

Выполнение запроса можно разделить на следующие этапы (подробнее о каждом этапе можно прочитать в источнике):
- Установка подключения к серверу СУБД
- Трансформация SQL-запроса
- Планирование запроса
- Исполнение запроса
- Завершение соединения

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

Для просмотра выбранного плана можно использовать команду EXPLAIN. В её выводе для каждого узла дерева плана отводится строка с описанием базового типа узла, оценки стоимости выполнения (cost), ожидаемое число строк (rows), ожидаемый средний размер строк (width). Команду EXPLAIN можно использовать с параметром ANALYSE, которая выполнит запрос и выведет фактический план, дополненный информацией о времени планирования и исполнения. Команду можно использовать для оценки фактического времени выполнения запроса, однако не стоит забывать, что использование параметра ANALYSE требует реального выполнения запроса в БД. Пример реального плана выполнения можно увидеть на картинке к посту.

Итого: понимание работы плана запроса является важным аспектом для оптимизации SQL-запросов и повышения производительности базы данных. Как минимум SQL-запросы станут для вас более предсказуемыми, вы будете тратить меньше времени на возникающие проблемы и их устранение :)

Источники:
https://club.directum.ru/post/361562
https://habr.com/ru/articles/203320/
http://bit.ly/3GPYWcX

#новичкам #знания

Мера неупорядоченности в аналитике данных

С понятием энтропии мы впервые сталкивались ещё в школе, тогда оно точно могло казаться очень загадочным и интригующим. С годами наши чувства к нему… совсем не изменились :)

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

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

Где именно мы встретим меру энтропии на практике ?

1. В Data Science понятие энтропии тесно связано с моделями предсказывающих деревьев — деревьями решений. Само дерево можно представить себе как цепь вопросов-математических критериев вида «Если x<40 , то True, последовательно уточняющих информацию об исследуемом объекте. Эти критерии задают условия к разным атрибутам объекта.
Структура данного математического алгоритма хорошо ложится на естественный язык, так что мы и сами легко можем построить дерево решений из простых понятных вопросов (если газета датирована предыдудыщей неделей — скорее всего она неактуальна). Для деревьев решений мера энтропии используется, как критерий оценки выборок, полученных после разделения деревом классификации. Допустим, после очередного заданного вопроса оказалось, что наши выборки стали более однородны — т.е. мера энтропии для каждой отдельной выборки уменьшилась. Значит наш вопрос для классификации сработал хорошо, и мы не зря его выбрали для узла дерева.

2. Мера энтропии применима для оценки сложности структур, в частности, схем. Для нас актуальным может оказаться оценка схемы реляционной базы данных. Например, статья рассказывает о классических способах оценки структуры БД и описывает способ оценки сложности с помощью энтропийного критерия.

3. Третье применение вытекает из второго пункта — описание геометрии сложных форм. Мы уже обсудили то, что мера энтропии может быть полезна для описания некоторых информационных и формальных структур. Конечно, тот же самый подход позволяет обратиться и к структурам физического мира. Некоторые из них с трудом сводятся к простым формам — облака, кровеносная система, кроны деревьев. Работой с ними занимается физика фракталов, и использует для исследований энтропийный подход. В ходе его применения на первый план ставится именно мера сложности их организации.

Надеемся, что помогли прокачать профессиональные навыки 😉 И теперь, когда кто-то в лифте скажет: "Да, энтропия нынче сильная ...", вы сможете вступить в дискуссию, а не просто помахать головой в знак согласия.

#знания

Трендвотчинг
Это отслеживание и анализ трендов в бизнесе, технологиях, обществе и мире в целом. Как правило, в компаниях им занимаются перед проведением стратегических сессий или при запуске нового продукта.
Отслеживанием трендов в компании может заниматься трендвотчер/форсайтер. Профессия пока малопопулярна, она входит в список «100 профессий будущего» от РБК.

Подборки трендбуков и трендбуки за 2023 год, которые заслуживают внимания:
▫️Подборка отчетов и трендбуков от «Экспертосферы» — папка в Google-диске с огромным количеством отчетов от ведущих консалтинговых, аналитических и трендвотчинговых сервисов
▫️ Трендбук от Wunderman Thompson — мирового агентства глобальных маркетинговых коммуникаций.
▫️ Трендбук по технологическим трендам на 2023 год от McKinsey & Company — всемирно известной консалтинговой компании
▫️ Трендбук по технологическим трендам на 2023 год от CB Insights
▫️ Подборка мегатрендов от TRENDONE
▫️ Отраслевые тренды 2023 года по версии консалтинговой фирмы FTI

Например по данным от Сбера 5 мегатрендов, которые определяют облик Мира 2035:
1) Превосходство серебряного мира
2) Развитие агломераций и деградация малых городов
3) AI-мир: трансформация рынка труда и образования
4) Phygital-мир
5) Несправедливый мир
Детальнее можно узнать здесь
#знания