Выполнение реального проекта заказчика

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

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

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

В рамках работы от меня требуется:
▫️ разобраться с API системы учета задачи и времени
▫️ спроектировать логическую и физическую модель данных
▫️настроить ETL процесс
▫️сформировать витрины
▫️визуализировать данных

Я решил, что решать задачу буду разными подходами и инструментами. Единственное что пока будет постоянным, это база данных: PostgreSQL

Если вам будет интересно следить за ходом работы по проекту накидайте 🔥 под этим постом

Что такое API и для чего его можно использовать

Основным источником информации у меня является сервис, в котором логируется время по выполнению отдельных задач сотрудниками на проектах. Нужно каким-то образом забрать из него необходимую информацию. Как это сделать?

С помощью API. Большинство сервисов предоставляют такую возможность. Через API можно взаимодействовать с ними и получать от них нужные данные.

API – Application Programming Interface, программный интерфейс приложения

Как правило, чтобы получить что-то от сервиса нужно отправить запрос используя API. Для этого необходимо обратиться на некоторый специальный URL адрес с дополнительными параметрами и получить ответ. Делается это с помощью POST или GET метода.

Вот пример фрагмента адреса для получения списка пользователей, в нем нет никаких параметров, он вернет всех пользователей

https://example.kaiten.ru/api/latest/users

Если вы думаете, что любой желающий может подобрать адрес и получить данные с сервиса, вы ошибаетесь. Существуют методы авторизации, чтобы исключить бесконтрольный доступ. О них мы поговорим позже.

Чтобы отправлять запросы можно использовать различные инструменты. Например, можно с помощью скрипта на Python или через low-code ETL инструмент. Иногда, можно даже через адресную строку браузера.

Если нужно просто проверить корректность запроса, отладить его или посмотреть, что он возвращает рекомендую использовать специальную программу Postman. В ней очень удобно формировать запросы, указывать методы, параметры запроса и авторизации. О ней мы тоже поговорим позже.

Итак, чтобы забрать откуда-то данные мы можем использовать API системы источника. Формируем запрос - отправляем. Получаем результат, обрабатываем и сохраняем для использования

В следующий раз планирую рассказать, в каком виде приходят данные, при запросах по API. Если интересно, поддержите 🔥

Для решения своей задачи я выбрал Python скрипты, но в развитие темы и вариантов решения помимо этого буду использовать:
- облачные функции
- Apache Airflow
- Apache NiFi

JSON — формат обмена и хранения данных

Итак, продолжаем разбирать тему работы с API (начало здесь).

Как правило, ответ на запрос приходит в формате JSON (JavaScript Object Notation). Если очень просто сказать о нем, то это массив данных где данные хранятся в виде пар: ключ : значение.

Можно использовать множество типов данных, от обычных текстовых строк, до сложных структур. Но везде принцип будет прост: зная ключ можем обратиться и получить значение.

Вот пример выпадающего меню для работы с файлом:

{"menu": {
  "id": "file",
  "value": "File",
  "popup": {
    "menuitem": [
      {"val": "New", "click": "New()"},
      {"val": "Open", "click": "Open()"},
      {"val": "Close", "click": "Close()"}
    ]
  }
}}

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

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

Работая с JSON файлами лучше использовать редактор, который умеет его форматировать. Если все данные сжать в одну строку, она будет практически не читаема. Я использую Notepad++ , в котором есть плагины упрощающие работу.

Аналогично и при работе с API, например, в Postman можно посмотреть на результат запроса в удобном виде.

Где можно почитать про JSON:

🔗 www.json.org
🔗 ru.wikipedia.org
🔗 developer.mozilla.org
🔗 www.w3schools.com

После того, как результат в формате JSON получен его нужно обработать. Сделать это можно разными способами. Например, в Python есть специализированная библиотека JSON, с помощью которой можно "распарсить" или "разобрать" полученные данные. В следующий раз поговорим об этой теме

Как устроена работа с DWH в Lamoda

Data Warehouse (DWH) — это централизованное хранилище данных, агрегирующее данные из разных систем-источников, на которых можно проводить анализ исторических и текущих данных.

DWH состоит из пяти слоев:

▫️ Data Layer (DL)
▫️ Intelligence Layer (IL)
▫️ Business Layer (BL)
▫️ Metadata Layer (ML)
▫️ Operational Data Store (ODS Report)

Читать полностью здесь

Перенос в prod доработанного дашборда

Сегодня хочу поделиться своим личным опытом и советом по этой теме. Я работаю на крупном проекте, где в Power BI Service используется много рабочих областей, одна из которых является тестовой, а еще одна продуктивной. Все изменения по запросам от бизнеса происходят в тестовой рабочей области, после проверки и принятия правок дашборды переносятся в продуктивную среду.

Перенос дашбордов между рабочими областями осуществляется с помощью функциональной возможности Deployment pipeline коллегами, которые отвечают «за порядок» в облачном Power BI Service. Чтобы перенести дашборд с одной рабочей области на продуктивную мне необходимо подготовить запрос для этой команды.

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

Периодически возникает необходимость внести правки или в визуальную составляющую, или поправить / добавить меру для расчета показателя, иногда изменить структуру таблицы или поправить модель данных. Выполнив свою работу, я прошу коллег перенести дашборд в прод.

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

Чтобы экономить время коллег обсуждайте изначально с бизнес-пользователями пул доработок, которые необходимо выполнить с дашбордом. Таким образом:
1️⃣ вы будете выполнять больший объем работы по одному из дашбордов
2️⃣ результат будет иметь большую ценность
3️⃣ ресурсы команды будут использоваться более оптимально

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

Кто сталкивался с тем, что часто просят что-то поправить в дашборде ставьте 🔥

OLAP - online analytical processing

Если вы работаете с BI или занимаетесь анализом данных, то могли использовать или слышать про OLAP, иногда можно встретить определение как «кубы данных».

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

При использовании OLAP в BI данные содержатся в таких кубах в памяти компьютеров (локального или сервера) за счет чего увеличивается скорость обработки запросов и дашборд перестраивается в режиме реального времени по клику на его различных интерактивных элементах.

Чтобы понять принципы работы таких кубов необходимо изменить подход к хранению данных от привычного реляционного к многомерному. Не всегда это сделать просто, т. к. понятие «куб» условно, на самом деле такая модель может и не быть классическим кубом, какой он представляется в нашем воображении.

Когда у меня возникла необходимость изучения этого вопроса я пытался найти ответы в различных источниках. Больше всего мне понравились следующие лекции, в которых даются фундаментальные знания и максимально подробно освещается эта тема:

https://www.youtube.com/watch?v=xD5sbSjAY-Q
ММД-1. OLAP-куб: концепция многомерной модели

https://www.youtube.com/watch?v=1rL1XlS7oK4
ММД-2. OLAP-куб: измерения

Надеюсь они будут полезны и вам

После некоторого перерыва на следующей неделе планирую публикацию материалов:

- про создание скрипта на Python для ETL процессов
- про библиотеки визуализации данных
- про процесс документирования мер, созданных в Power BI

Где бесплатно изучить Apache Superset?

Хочу поделиться с вами своей подборкой материалов, которые можно использовать для изучения такого BI инструмента как Apache Superset. Советую посмотреть, даже если не планируете пока его использовать, в целом достаточно интересно. Используется на различных проектах как альтернатива тройке мировых лидеров BI инструментов.

1️⃣ Как всегда на первом месте официальная справка

2️⃣ Для тех кто любит видео ролики, открытый курс от Ростелекома

3️⃣ Почитать на русском языке можно в документации у Сбера

4️⃣ А для тех, кто любит локальные pdf файлы, есть руководство (см. вложение)

Если вы еще не знаете, что представляет из себя Apache Superset, то на официальном сайте можно познакомиться с ним

Superset is fast, lightweight, intuitive, and loaded with options that make it easy for users of all skill sets to explore and visualize their data, from simple line charts to highly detailed geospatial charts

Сегодня рассуждал о вопросе «Что такое BI?». Как бы я ответил на него, если меня спросили и надо было ответить максимально быстро, но при этом емко.

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

Напишите свои ответы в комментариях

BI это данные представленные в графическом в виде

Таков мой ответ на вопрос выше. Любой виджет на дашборде это данные, виджет это вариант их графического представления, коллекция виджетов это дашборд.

Я думаю, что имея такое представление о BI можно понять, что действительно нужно знать и уметь BI специалисту. Ответ содержит два ключевых понятия «данные» и «представление»

1️⃣ Данные. Если говорим о них, то сразу возникает цепочка: источник -> обработка -> хранение. Теперь зная это можно набросать для себя вопросы, что нужно уметь:
- проанализировать источник и понять, что в нем и в каком виде находится
- получить данные из источника
- выполнить трансформацию данных (привести к нужным типам, сгенерировать составные ключи и пр.)
- организовать хранение (хранение «сырых» данных, построение моделей и витрин)

2️⃣ Представление. Правила и способы визуализации данных. Если погружаться в эту тему, то появляются следующие требования:
- подбор нужного типа диаграммы для ответа на поставленный вопрос
- компоновка элементов на дашборде (управление внимание пользователя, выравнивание и т.п.)
- выбор цветов, шрифтов

Конечно это далеко не все, что требуется сегодня от BI специалиста, но не много углубившись в достаточно простой вопрос можно сделать для себя много интересных выводов, а также более широко посмотреть на некоторый предмет или направление

Этапы разработки дашборда

1️⃣ Сбор команды или заинтересованной группы лиц
2️⃣ Проведение интервью с заказчиком и формулирование задачи
3️⃣ Формирование портрета пользователя
4️⃣ Формулирование вопросов, на которые должен отвечать дашборд и какие бизнес-решения могут быть приняты на его основе
5️⃣ Уточнение где и как будет использоваться дашборд
6️⃣ Анализ источников данных
7️⃣ Определение основных смысловых блоков, типов виджетов
8️⃣ Разработка MVP, тестирование
9️⃣ Запуск в эксплуатацию

Если вам интересно разобрать каждый из этапов накидайте 🔥

Этапы разработки дашборда - Сбор команды или заинтересованной группы лиц

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

Минимальный набор ролей следующий:
- заказчик разработки дашборда
- разработчик дашборда (BI специалист)
- дата инженер

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

Разработчик дашборда (BI специалист) – соберет все требования к дашборду, информацию по источникам данных. Поставит задачу дата инженеру для организации сбора и хранения необходимых для дашборда данных. Подготовит эскизы и/или MVP, презентует его заказчику. Соберет обратную связь и выполнит доработку дашборда до требований, которые устроят заказчика.

Дата инженер – обеспечит извлечение данных из источников, перенос их в хранилище. При необходимости выполнит трансформацию и предобработку исходных данных.

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

Также хочу обратить внимание, что это «стандартный» минимальный набор ролей. На практике BI специалист может совмещать роль с дата инженером. Определить такие совмещения можно при анализе вакансий, но это отдельная тема для обсуждения. Также работая на большом проекте можете встретить отдельную роль специалиста по хранилищам данных или базам данных. Его задача создать хранилище для задач BI, в этом случае эти работы снимаются с дата инженера.

Если у вас есть вопросы по данному этапу – оставляйте комментарии, подискутируем

Исследование рынка BI 2024 года

Интересное исследование от Visiology рынка BI. В нем утверждается, что тройка мировых лидеров по-прежнему сильно лидирует на отечественном рынке и спрос на спецов по ним высокий. Чтобы я хотел дополнительно посмотреть, так это на сегменты бизнеса.

Крупный бизнес и гос. компании вряд ли будут активно развивать направление BI на ушедших инструментах, а это основной рынок для вендоров и внедрения их партнерами. Также растить свою экспертизу внутри на инструментах, которые официально не поддерживаются для них большой риск.

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

Ради интереса посмотрел динамику запросов по тройке лидеров в Wordstat от Яндекса. По Power BI и Qlick в целом изменений не заметно, а вот по Tableau явный тренд на снижение.

Интересно узнать ваше мнение по рынку и по обзору

Этапы разработки дашборда - Проведение интервью с заказчиком и формулирование задачи

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

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

Необходимо начать с понимания – используется ли сейчас BI у заказчика. Если нет, то стоит обратить внимание на работы по подготовке к внедрению. Это сбор данных и организация их централизованного хранения. Вероятно, что сами задачи по BI будут актуальны после решения этих вопросов. Если BI уже используется – какой инструмент внедрен, устраивает ли он заказчика, не планируется переход на другой и т.п.

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

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

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

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

Несколько слов про BI специализацию

В одном из каналов ответил на публикацию автора, хочу поделиться с вами.

❓ Ожидание от BI
BI это не только рисование графиков, это сильно больше!

❓ Низкий порог входа
Действительно не высокий. НО! Собрать требования, организовать хранилище, понять как дата инженеру поставить задачу (или сделать самому!) тоже нужно знать и уметь. Читайте внимательно вакансии

❓ Куда переходить из BI направления
Перейти можно в инженерию данных и хранилища, это наиболее близкие специализации

❓ Уровень з/п у BI специалистов не высокий
Зависит от компании и обязанностей. Чем больше совмещения с DE И DWH, тем выше з/п. Можно работать у вендора (либо консалтинге) на внешних внедрениях, либо в компании на внутренних задачах. В целом согласен, не самые высоки з/п среди IT специальностей

❓ BI не только "рисует графики"
Можно потратить день на причину "почему не работает дашборд", в итоге окажется, что не отработала выгрузка данных или в ней ошибка. "Рисование" это финальный этап в работе BI специалиста

❓ Тенденции рынка по технологиям
С учетом ипортозамещения меняется набор инструментов. Я бы не смотрел в сторону Tableau если в планах нет работы на внешнем рынке. Qlick встречается на внутреннем рынке. Power BI - живет. Отечественные вендоры - зависит от компании, в которой работать, везде свой стек. Из минусов - не так все хорошо как у лидеров, нужно учить JS, CSS, HTML на базовом уровне для разработки чего-то похожего на тройку лидеров

❓ Нужны ли А/Б тесты BI специалисту
Если это есть в позиции, значит это не BI, а уже анализ данных или продуктовые вопросы, а это другие компетенции и стек

Кто согласен ставьте 🔥, кому есть что добавить - делитесь в комментариях

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

Почему важен дизайн дашборда?

Дашборд - это визуальное представление информации. Его цель - представить сложную информацию в удобном для восприятия формате.

Удобный дашборд должен быть:

1️⃣ Понятным: хороший дашборд четко отображает необходимую информацию. Когда пользователь смотрит на него, он должен иметь возможность понять ее назначение в течение первых 5 секунд. Ему не нужно тратить несколько минут на это

2️⃣ Значимым: дашборд содержит значимую информацию. Значимая информация описывает то, что разработчик дашборда хочет передать с помощью него

3️⃣ Последовательным: информативные дашборды отображают информацию в последовательном формате. Необходимо позаботиться о согласованности его макета, организации и содержания

4️⃣ Простым: сложный дашборд не выполняет свою цель, которая заключается в представлении сложной информации в простой форме. Если визуальное представление информации не делает ее простой, то есть проблемы с дизайном дашборда

Подготовлено на основе 10 Rules of Dashboard Design

Актуальные BI системы на январь 2025 года

Год назад я проводил опрос, который показал, что основной инструмент, используемый для разработки дашбордов это Power BI, второе место занял DataLens, на третьем Superset.

Интересно узнать как изменилась структура за прошедший год. Есть ли влияние импортозамещения и внедрения Open Source решений.

Если не найдете свой инструмент в перечне - напишите в комментариях, учту его в следующий раз.

Если у вас есть возможность - поделитесь опросом в своих каналах, чтобы охватить большее число специалистов

Разбор возможного описания вакансии BI специалиста

Смотрим на задачи, среди прочего описания обращайте внимание на следующие формулировки:

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

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

Презентация аналитических выводов и рекомендаций для заказчиков с целью их успешного внедрения и повышения понимания

Стоит уточнить, что имеется ввиду под презентацией. Если задача рассказать как работает дашборд и что он отображает, то это задача BI специалиста. Если обсуждение показателей в плане их экспертной оценки и т.п., то опять же, скорее задача из области работы с данными

Настройка и оптимизация ETL-пайплайнов для решения аналитических задач

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

Владение технологическим стеком: Python (pandas, numpy), SQL, Git, Docker, Airflow. Опыт разработки и оптимизации ETL-пайплайнов

Это флаг, указывающий на решение задач дата инженера. Если нет компетенции - обсуждайте, если умеете все делать - повод увеличивать сумму ожидания по з/п.

Опыт работы с инструментами визуализации данных (Tableau, Power BI, DataLens, Superset)

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

Если интересно проводить такие разборы описаний накидайте 🔥, если нет 💩