Data Driven культура от AW BI
1.08K subscribers
69 photos
5 videos
97 links
Вы на канале про Data Driven культуру, который бережно и старательно ведёт команда российского BI продукта Analytic Workspace — AW BI. Но здесь не про нас, а про ваc.

Про нас здесь: analyticworkspace.ru
https://tttttt.me/awcommunity
Сотрудничество: @GrekovM
Download Telegram
Приветствуем!
Вы на канале про 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 уровень: МУДРОСТЬ
На четвертом уровне находится мудрость, которая является результатом применения знаний в реальной жизни. Другими словами это способность действовать наиболее подходящим образом с учетом того, что известно (знания) и что приносит наибольшую пользу (этические и социальные соображения).

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

#знания
Про ad-hoc аналитику

Привет!
Пишет Михаил — Head of product AW BI 😉
В Мире BI есть как минимум два понятия, которые все часто употребляют, но которые все понимают по-своему.
1 — Self Service BI, 2 — ad-hoc аналитика (без дефиса тоже пишут — adhoc).

Про Self Service мы уже рассказали немного на vc. Давайте поговорим про ad-hoc (от лат. “по особому случаю”).
Если покопаться в интернетах — то можно составить следующее впечатление: ad-hoc аналитика — это когда ты достаёшь ответы на сиюминутные (спонтанные) запросы бизнеса. Если скрестить Self Service и ad-hoc, то получится так: бизнес пользователь сам из BI системы может достать ответы на свой спонтанный запрос.

Пока всё понятно, но — как понять BI-система может в ad-hoc или нет. Или даже так — насколько глубоко BI может в ad-hoc.
И здесь ответа уже не найти — каждый меряет в рамках своего BI кругозора.

Для кого-то ad-hoc — это покрутить сводную таблицу.
Для кого-то — написать обработку на питоне.

Интерактивный дашборд (с фильтрами и дрилами) — это, кстати, не ad-hoc, а его производная: когда-то поняли, что "спонтанные" вопросы повторяются слишком часто, и вынесли их на дашборд.

Я спросил у некоторых BI-экспертов — как они понимают ad-hoc.

Арслан Катеев, владелец продукта Alpha BI:
Для меня это, наверное, "когда гвоздями не прибито"
Смотришь на график/таблицу — вдруг захотелось "задать уточняющий вопрос", типа "а если скрыть вот эти", "если отфильтровать по дате с..." и когда такая возможность есть, это уже адхок.
Не буду перечислять широту необходимого поддерживаемого функционала, типа фильтр, группировка по и тд. Так как это про здесь и сейчас возникшие вопросы, а они могут быть разные.

Сергей Кравченко, BI-щик для души, дата-евангелист и автор телеграмм канала BI-done (для аналитиков, которые любят посмеяться)
Ad-hoc (или Self-service) аналитика — это не только набор инструментов которые дают рядовому пользователю супер-силу в виде способности видеть компанию буквально насквозь, но и самое главное это культура работа с данными, которая начинается с хранения данных и заканчивается доверием руководителя к выводам своих специалистов! А также методология и дата-грамотность сотрудников на всех уровнях!

В общем, ad-hoc аналитика — это очень "скользкое" понятие. Если вы выбираете BI и хотите, чтобы был ad-hoc, то лучше не полениться и написать конкретно, какие функции вам нужны.
Ad-hoc есть у всех, но у всех он свой. Как и Self Service 😉

А ещё про ad-hoc подробно высказался Директор по развитию партнёрской сети Qlik в СНГ — Георгий Нанеишвили.
Его комментарий отдельным постом ⬇️

#мнение #знания
Please open Telegram to view this post
VIEW IN TELEGRAM
Георгий Нанеишвили, директор по развитию партнёрской сети 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. Присваивайте столбцам логически обоснованные имена
При создании запроса мы можем просто переносить столбцы. Вместо этого рекомендуется называть их в соответствии с предполагаемым назначением.

#новичкам #знания
Ресурсы для развития навыков визуализации данных

Друзья, предлагаем вам шикарную подборку ресурсов для развития насмотренности в визуализации данных от Наталии Степановой автора канала Визуализируй это! — подписывайтесь, кстати, канал 🔥
Передаём перо Наталии ✍️

===
Можно многое рассказать о визуализациях, примерах, ресурсах и книгах, но здесь я постаралась собрать самое базовое.
Ответить на вопрос: «С чего начать и чем вдохновляться, чтобы научиться создавать красивые и полезные визуализации?». В полученный список, конечно, не вошло множество интересных книг и крутых специалистов, но чтобы охватить всё, потребовалось бы намного больше места.

Книги
1. Edward Tufte и его книги по информационному дизайну. "The Visual Display of Quantitative Information" — настоящая классика, которую можно назвать библией для графиков. Официального перевода не существует (автор не разрешает), но в сети можно найти неофициальные, а сама книга написана достаточно простым английским языком.

2. Don Norman, "The Design of Everyday Things". Эта книга — основа понимания дизайна и UX, заставляет задуматься о дизайне самых обыденных вещей. В России издана издательством МИФ.

Люди
1. Shirley Wu — shirleywu.studio
Меня очень вдохновляют её аккуратный дизайн и художественные абстракции в визуализациях. У неё много доступных лекций и воркшопов по программированию, их можно найти на YouTube.

2. Nadieh Bremer — visualcinnamon.com
Создаёт удивительные визуализации на самые разнообразные темы.

3. Valentina D'Efilippo — valentinadefilippo.co.uk
Больше фокусируется на дизайне и смыслах. Её выступления и рассказы о создании визуализаций, включая Effective Data Visualisation, также доступны на YouTube.

Сайты
1. Information is Beautiful — informationisbeautiful.net
Обширная коллекция инфографик на самые разные темы, от статистики пород собак до доходов правительства Великобритании.

2. Pudding — pudding.cool
Интерактивные визуальные эссе.

3. Flowing Data — flowingdata.com
Множество визуализаций и страниц с туториалами по их созданию.

4. Блог Datawrapper — blog.datawrapper.de
Статьи с примерами визуализаций и советами, например, по выбору цветовой палитры или подготовке данных.

5. D3.js — d3js.org
Не удержалась и всё-таки включила пункт про код. Но и не только, на сайте можно найти множество примеров от простых до сложных с подробным разбором их создания.
===

Канал Data Driven Культура — гид в мир данных и их представления
#визуал #книга #знания
Please open Telegram to view this post
VIEW IN TELEGRAM
Данные накапливаются, мудрость - нет

Пирамида 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) Несправедливый мир
Детальнее можно узнать здесь
#знания