В управленческом учёте и во внедрении BI работаю порядка 15 лет, с разными системами, по четырём из них сертифицирована, веду разные курсы и образовательные мероприятия. Компания занимается тем, что внедряет аналитику и BI, помогает компаниям становиться более цифровыми и доводит аналитические идеи до управленческих решений и внедрения в бизнес-процессы. Параллельно проводим вебинары: стараемся уменьшать количество продающей информации и повышать количество технической и полезной, чтобы вы потратили своё время с пользой и ушли довольными. Небольшая информация о том, чем мы можем быть полезны, будет в конце вместе с бонусом.

Кратко посмотрим на Power BI как на лидера рынка: почему он, несмотря на рыночные ситуации, остаётся лидером, как долго и что этому способствует. Потом — пять этапов построения дашборда: от подключения к источникам данных до публикации и выдачи доступа пользователям. Весь маршрут подготовки дашборда постараемся собрать за полтора часа; есть небольшой риск, что получится чуть дольше, но я постараюсь держаться в тайминге — на каждый этап размечено, сколько минут заложено. В конце — приятный бонус только для онлайн-участников. Вопросы в чат можно задавать в любой момент: буду отвечать сразу либо откладывать на конец.
Работаем по такому принципу: 2–3 слайда с небольшой теоретической информацией, переходим в Power BI, делаем, возвращаемся, переходим к следующему блоку — и так пять раз.

Исследование оценивает BI-системы по двум критериям — полнота функциональности и простота внедрения — и делит на четыре квадранта. Чем правее и выше квадратик, тем ближе система к лидерам; в крайней правой верхней точке этого квадранта 19 лет занимает Microsoft Power BI. Поэтому лидер он не только в нашей стране, но и в мире в принципе.

Недавно был вебинар про выбор BI-систем — записи выложены во все наши каналы. Там я приводила исследование «Пульс BI» от компании Visiology, которое проводится второй год: оно анализирует рынок не с точки зрения того, какие системы есть, а с точки зрения того, какие системы используют. Смотрят по вакансиям, по активности в каналах и на различных ресурсах, по косвенным признакам, беседуют с заказчиками и вендорами и агрегируют всё это в общую картину. В топ-10 лидеров за последние пять лет Power BI, несмотря на все санкционные запреты и ограничения, остаётся на первом месте нерушимо все эти пять лет, и до этого было точно так же.

Что касается упоминания в вакансиях — отрыв колоссальный: более половины вакансий на текущий момент требуют знаний Power BI. Есть даже такой тренд: компания, которая ищет аналитика, может пользоваться другой системой, но требования формулирует в основном опираясь на Power BI. Потому что это не просто система-лидер, это своеобразная классика аналитики, с которой должны уметь работать практически все аналитики. Знать её, уметь с ней работать, уметь строить в ней дашборды — навык номер один для аналитика, в какую бы BI-систему он потом ни перешёл.

Первая причина — экосистема Microsoft в целом. Это сложившаяся история, которая работает много лет. У Microsoft помимо Power BI очень большое количество продуктов, и они помогают не только организовать офисную работу — все мы работали с Excel, Word, PowerPoint и другими полезными инструментами для офисных сотрудников. Очень много инструментов преимущественно для разработчиков: разные среды разработки, организация баз данных и прочий инструментарий, который в разных комбинациях используется в разных компаниях. Заменить BI-систему, которая идёт бонусом в этом комплекте, означает не просто заменить BI-систему — это означает уйти от продуктов Microsoft в принципе. А это всегда большой стресс, и не всегда удаётся всё это заменить скопом. Поэтому очень многие компании до сих пор остаются с продуктами Microsoft и, соответственно, с Power BI в целом.

Вторая причина — возможности для построения аналитики и её относительная простота: это как раз те самые критерии, на которые опирается исследование Гартнера. Power BI славится минимальным, пожалуй, порогом входа для аналитиков: вникнуть в него, понять, как на нём строить дашборды, проще, чем на какой-либо другой системе, большинству аналитиков.

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

Четвёртая причина — обновления и поддержка. Несмотря на то, что Microsoft ушёл с рынка РФ, остаётся сообщество — не компании и не вендора, а сообщества, потому что кадров и экспертизы на рынке достаточно много.

На слайде перечислено далеко не всё, возможностей кратно больше. Если сравнивать, например, с текущим рынком российских систем, Power BI имеет ряд неоспоримых преимуществ. Это система, сочетающая в себе не только аналитические возможности, но и возможности для хранения и преобразования информации. Очень мощный ETL-движок, который позволяет преобразовывать данные, прежде чем анализировать. Огромное количество коннекторов — редкая система покажет 200 с лишним коннекторов; я буквально пересчитывала и сверяла списки, и количество постепенно растёт, добавляются новые системы, как правило зарубежные. Но для подключения к большинству систем, которые используем мы с вами в нашей стране, есть коннекторы, закрывающие эту задачу на 100%. Можно писать SQL-запросы к базам данных, обращаться к разным REST API, к OData, к БД и так далее. Я не встречала ещё ни одной системы, из которой данные не удалось бы забрать Power BI: обязательно найдётся коннектор, который данные заберёт, если система сама эти данные отдаёт.
Мощный ETL-движок позволяет выполнять огромное количество преобразований, прежде чем мы начнём эти данные анализировать: порядка 700 различных функций в языке Power Query. Можно строить визуальные модели — не каждая BI-система этим похвастается, и не всем удобно отсутствие такой возможности; Power BI даёт возможность достаточно гибко выстраивать визуальные схемы данных, на основании которых будет строиться дальнейшее вычисление и визуализация. Для вычислений есть язык DAX с почти 300 различных функций, закрывающих все возможности запросов к вычислениям и настройки столбцов, мер и таблиц. Визуализации — стандартная база 40+ визуализаций, на основании которых можно закрыть 90 с лишним процентов задач, и возможность для каких-то эксклюзивных кейсов что-то импортировать, докупить либо написать своё. Публикация — сегодня говорим про Power BI в контексте только онлайн-версии, самой простой, базовой, но самой используемой в мире: есть сервис онлайн, который позволяет опубликовать отчёты и предоставить доступ коллегам — с ограничениями или без ограничений видимости данных, с расписанием обновления, сформировать всё это в приложение и предоставить доступ к аналитике.
На схеме оранжевая стрелка в обратную сторону показывает важный момент. Все возможности складываются в путь данных от источника до пользователя: подключаемся к данным, обрабатываем, связываем, настраиваем вычисления, визуализируем, отдаём пользователю. И обратного хода нет (есть незначительные исключения). Я часто сталкиваюсь с этим вопросом: всё, что сделано на DAX, не знает Power Query; всё, что сделано в Power Query, не знает источник данных, и так далее. То есть всё, что мы с данными делаем непосредственно в Power BI, не попадает в наши источники.

Несмотря на то, что система — лидер, если мы её взяли, вооружились и пошли делать аналитику, без остального успеха, вероятно, не получится либо он получится сильно не сразу. Чего не даёт система-лидер:

• Понимание инструмента. Инструменту надо учиться, инструмент надо понимать — это касается любого инструмента, лидера или не лидера.
• Понимание пользователей и их задач. Никакая BI-система не объяснит, что от вас хотят пользователи и как лучше предоставить им информацию, чтобы она была читабельной и понятной максимально быстро.
• Умение проектировать дашборды оптимально с учётом того, какие у вас есть данные, что хотят пользователи, как собрать всё в рабочую конструкцию, которая не будет виснуть на каждом шаге.
• Умение встраивать дашборды в процессы бизнеса — отдельная история, которая в коробочке Power BI не включена.
• Умение делать дашборды, которые работают. Всё это аналитику нужно осваивать самостоятельно и дополнять владение инструментом разными особенностями проектного управления и внедрения BI в компанию.

Для подключения в Power BI богатый ассортимент коннекторов — больше 200 штук, и они совершенно разные; на слайд все не поместились. Для реальной жизни аналитика в наших реалиях нужно штук 10–15 коннекторов, с которыми придётся работать. Коннектор — это соединитель с какой-то системой, с каким-то типом файлов, с каким-то протоколом, по которому Power BI может забрать данные к себе.

Дальше все подключения к данным, несмотря на то, что мы делаем их из самого интерфейса Power BI, происходят во встроенном модуле, который называется Power Query. Этот модуль закрывает две большие задачи: извлекает данные из источника и позволяет эти данные преобразовать. Я называю Power Query своеобразными «воротами» в Power BI, через которые проходят все внешние данные: если в дашборде подразумеваются какие-то внешние данные, мимо Power Query они пройти физически не могут, они гарантированно пройдут через него. Все коннекторы живут там, все преобразования тоже живут там. Это определённая фаза, которую данные проходят и потом уже прогружаются в модель для дальнейших действий с ними.
У этого модуля есть свой встроенный язык, на котором пишутся все преобразования. Но сразу не пугаемся: пишут на нём те, кто уже готов писать, а по умолчанию есть целый набор кнопок на панели инструментов. Система относится к классу low-code, что означает, что очень много действий можно сделать, не написав ни строчки кода: есть кнопочки и диалоговые окошки, в которых настраиваем и вводим определённые данные и таким образом настраиваем преобразование. Но надо понимать, что кнопочки дают не всё, очень многое скрыто от кнопочек и сделать можно только кодом. Поэтому кратко познакомиться с языком — хорошая задача, которую аналитику можно и нужно преодолеть.

М — встроенный язык Power Query (MS Excel и MS Power BI), предназначенный для работы с табличными данными. Он регистрозависимый, и все преобразования собираются в определённые цепочки. Если делаем все действия кнопочками, цепочка — просто шаг 1, 2, 3, 4, 5 и так далее. Если кодом — можем делать различные ветвления и собирать более сложные цепочки, но сделать это можем только непосредственно за кодом.
У Microsoft как минимум два очень полезных справочника, которые прямо must-have для аналитиков в Power BI: справочник языка M (либо всего Power Query) и справочник языка DAX, о котором скажу позже. Ссылка на справочник M — по QR-коду на слайде.

Старт в Power BI Desktop. У меня открыт абсолютно пустой свежий Power BI, ничем не заполненный, без шаблонов и заготовок — хотя в целом они есть, и, возможно, где-то для сокращения времени я к ним прибегу. Мы видим стандартное окно программного продукта Power BI Desktop, в котором собирается вся аналитика изначально. Desktop — десктопное приложение, бесплатное: можно для себя, даже не имея подписок и лицензий, не нарушая абсолютно ничего, скачать с сайта Microsoft, установить и пользоваться для собственной аналитики, чтобы что-то настроить, посмотреть, проанализировать. Десктопной версии для Mac на текущий момент нет: чтобы работать с Mac, нужна либо виртуалка с Windows, либо какие-то обходные пути, но напрямую Power BI работает только на Windows.

В окне есть панель инструментов с различными разделами и командами — классическая для BI, и панель слева, которая даёт несколько разделов — разные представления одних и тех же загруженных данных:

• Представление отчёта — где рисуется сам дашборд, где видны визуализации, где можно с ними взаимодействовать и настраивать интерактивность; то, что будут видеть пользователи.
• Представление таблицы — сейчас здесь пусто, потому что данных пока нет, но они появятся буквально через несколько минут. Оно даёт возможность посмотреть, что в наших данных в модели на текущий момент есть, взаимодействовать с таблицами, фильтровать, сортировать и искать какие-то отклонения непосредственно в представленных моделях данных, чтобы понять, то у нас считается или не то.
• Представление модели — здесь данные будут связываться между собой.

Во всех трёх сегодня поработаем. Снизу есть ещё два представления — запросов и табличной модели, но в них сегодня не пойдём.

Справа есть три плашки: плашка с данными (здесь будет структура всех загруженных данных: таблицы, поля, меры и так далее), визуализации (характерно для представления отчёта) и фильтры (тоже для представления отчёта); вкладка данных присутствует везде, у представления модели есть ещё свойства.

Подключение к базе данных. Первое, к чему подключимся, — база данных PostgreSQL. Для подключения есть кнопочка «Получить данные» на панели инструментов; её же можно найти в самом Power Query, когда провалимся, и в разных других местах — она рассеяна везде, мимо неё не пройдём. Здесь есть список некоторых часто используемых вариантов коннекторов и «Другие», откуда виден полный список, сгруппированный по категориям. Нам понадобится одна из баз данных — конкретно PostgreSQL. Чтобы подключиться к базе данных, необходимо знать про неё сервер, порт, саму базу данных и иметь логин, пароль с доступом как минимум на чтение нужных таблиц. Здесь у меня уже есть сервер, порт, база данных — подключаюсь. Есть возможность писать SQL-запросы; сегодня этого не коснёмся, но такая опция есть — этими запросами можно получать данные уже преобразованными, как нужно. Мы подключаемся без них. Если подключаюсь к базе данных впервые, он запрашивает логин и пароль; но так как база рабочая и я подключаюсь к ней достаточно часто, логин и пароль не запросил и в базу пустил — в рамках одной моей учётной записи ПК пароли внутри сохраняются, повторно их вводить не нужно.

Специфика дашборда. Кратко о том, что мы собираем. Собираем простенький дашборд по образовательной сфере: некоторая компания на сайте продаёт курсы — почти как мы. Эти курсы кто-то оплачивает; курсы разные — есть семинары, вебинары, непосредственно курсы разной тематики с разными стоимостями. Есть таблица с заказами этих курсов: один заказ — один курс, зашёл, нажал кнопочку «купить» и отправился в покупку. Покупка может быть совершена либо нет, поэтому есть статусы оплаты: что-то завершили, что-то не завершили, за что-то денежки пришли, а где-то пользователь повис на середине — это нам тоже важно понимать. Есть информация о заказчиках: все данные искусственные, никто от персональных данных не пострадал, совпадения случайны — имя, фамилия, идентификатор. Есть информация о менеджерах, которые связываются с заказчиками по работе над заказом. Есть промокоды на скидку — на разные образовательные мероприятия часто есть свои промокоды. И есть товары — товарными мы называем наши образовательные мероприятия, у них есть категории: курсы, вебинары, семинары. Механика примерно такая, как у каждого, кто когда-нибудь покупал курс или небольшой образовательный продукт.

Выбор таблиц. Намеренно не захватываю менеджеров и продукты — их заберём из файлов, чтобы рассмотреть вариативность подключения. Итак, берём заказы, заказчиков, статусы оплаты, промокоды и категории — пять таблиц. Я их выбрала в навигаторе; на каждую таблицу виден предпросмотр. Можно сразу нажать «Загрузить» — тогда они проскочат через Power Query, обогатятся какими-то минимальными автоматически добавленными преобразованиями и приедут в модель сразу, но это не входит в наши планы. Поэтому нажимаю «Преобразовать»: сделаем то же самое, но вникнем в процесс. Открывается второе окно Power Query; эти окна могут работать параллельно, друг друга не блокируют — я могу работать и там, и там. Единственное: все изменения, которые делаю в Power Query, нужно применить, чтобы они попали непосредственно в модель Power BI.

Знакомство с Power Query. Окно отчасти похожее: та же панель инструментов, те же вкладочки — типичная схема для всех продуктов Microsoft, загляните куда угодно и получите примерно такую же конструкцию. Слева находятся запросы: все запросы нашего файла Power BI будут храниться в одном Power Query — на каждый файл своя область; можно открыть пять разных окон и наблюдать, что происходит. Не все запросы могут прогружаться в модель: какие-то могут быть внутренними, исключительно промежуточными. У каждого запроса есть свои шаги преобразования. Если бы в навигаторе нажали сразу «Загрузить», те шаги, которые сейчас здесь прописаны, применились бы, и таблица загрузилась бы без нашего вмешательства.
На таблице с БД преобразований минимум, потому что они уже в том виде, в котором нужны BI. Самый простенький запрос — на категории товаров (курсы, вебинары, семинары), у него два шага; с двумя сильно не разгуляешься, но шаги кликабельные, и щелчок на каждый шаг показывает предпросмотр того, что на этом шаге сделано. Два шага соответствуют тому, что мы делали в самом Power BI: подключались к данным и потом выбирали в навигаторе таблицу. В строке формул показывается подключение к источнику — здесь подключение к БД по конкретному адресу; с другим подключением, другим источником будет написано что-то другое. Вторым шагом предпросматриваем и видим тот же список таблиц, которые видели в навигаторе; шаг навигации выбирает конкретную таблицу из этой БД. Аналогично у всех остальных — только в шаге навигации выбрана какая-то другая таблица. Эти таблицы пока оставляем как есть.

Подключение к файлам. Нам нужно подключить ещё две таблицы — с менеджерами и с продуктами; они хранятся в файлах. Можно это сделать из самого главного окна Power BI, а можно из Power Query создать источник — окно будет то же самое. Нам нужен файл текстовый или CSV и путь к этому файлу: это менеджеры. Здесь другое подключение и другой вариант навигатора — для каждого подключения свой вариант; автоматически определилось с кодировкой, с разделителем, и файл принял вполне приемлемый вид. Принимаем. Появляется новый запрос, и шаги у него уже свои: в источнике — путь к файлу; в повышенных заголовках первая строка CSV переехала в заголовки; третьим шагом Power Query автоматически типизировал все столбцы. Ещё один источник — тоже файл, тот же тип, та же папка, только там были менеджеры, а сейчас будут продукты. Несмотря на то, что там был CSV, а здесь XLSX, механизм очень похожий: оба файла обрабатываются по одному и тому же принципу, разве что в параметрах есть некоторые нюансы.

Итого семь таблиц — практически полная информация, которая нужна для дальнейших действий. Единственное, что сейчас сделаю, — приведу в порядок названия, чтобы в них ориентироваться и не было лишних слов: заказы, заказчики, статусы оплат, промокоды, категории продуктов, менеджеры и продукты. Чтобы эти семь таблиц попали в Power BI, нажимаю «Закрыть и применить» — произойдёт загрузка, все шаги, которые были прописаны у каждого запроса, применятся, и данные загрузятся непосредственно в модель и покажутся в «Данных» в виде этих семи таблиц. Визуализация пока пустая, но в табличном виде мы уже можем походить по таблицам и посмотреть, что там хранится. В модели теперь присутствуют схемы таблиц, но со связями будем разбираться чуть позже, на следующем этапе.

Преобразования. Данные загрузили, но практически никак не коснулись преобразований. Возвращаемся в Power Query и смотрим, какие преобразования нужны. Попасть в него можно несколькими способами: из любого запроса через «Изменить запрос» либо с панели инструментов «Преобразования данных» с любого раздела — так или иначе в Power Query попаду.
В заказах есть лишние столбцы. В БД я не все таблицы перечислила: там ещё есть информация о прохождении самих курсов, о том, как заказчики участвуют в занятиях, какие рейтинги получают, и так далее — нам эта информация сегодня не нужна. В таблице с заказами нажимаю на панели инструментов «Выбор столбцов» и снимаю галочки с ненужных, оставив, по сути, набор айдишников для связи со всеми остальными таблицами, дату заказа и идентификатор заказа. Столбцов стало меньше.

В таблице с промокодами процент скидки представлен вот таким числом: 11 процентов представлено как 11. По-хорошему, по правильному, 11 процентов должны быть представлены процентами. Дело даже не в том, что нарисуется значок с процентами, а в том, что это должно быть 0,11, а не 11: оперируя таким числом, нам придётся каждый раз помнить, что надо поделить на 100, а это не очень правильно. Поэтому делим на 100 сразу. Создаём дополнительный столбец — этот можно оставить, но можно удалить. Для создания дополнительного столбца отправляемся на панель «Добавление столбца» и добавляем настраиваемый столбец. Здесь как раз пригодится написание формул — не из серии «поделить на 100», как сейчас, но в целом для написания этих формул очень полезно знать, какие в принципе возможности у Power Query есть: порядка 700 различных функций, которые можно использовать очень по-разному; какие-то из них зашиты в кнопки, но очень многие — нет. Создаём столбец, называем его «Процент скидки»: он будет очень простой — берём из доступных столбцов наш процент и делим на 100. Если бы я делала аналитику по правильному, я бы ещё прошлась по всем столбцам, всё переименовала так, чтобы это билось и называлось идентично везде, но сейчас не буду тратить на это драгоценные минуты вебинара. Поэтому оставляем немного неконсистентное формирование названий.
Когда я добавляю столбец, он у меня по умолчанию не типизирован. Здесь я бы очень хотела рекомендовать следить за типами данных и присваивать их всем столбцам без ограничений и исключений. Тип данных можно прописать прямо в формуле добавления столбца либо поменять, просто нажав на пиктограмму типа данных у столбца. Итак, «Процент скидки» — и в принципе пока всё.
Был в планах ещё календарь, но календарь оставим на попозже. Чтобы эти изменения попали в модель, нужно нажать волшебную кнопочку «Закрыть и применить».

Вопрос из чата: если Power Query не определил тип данных и показывает ошибку, что делать? Power Query по умолчанию пытается определить тип данных у загруженных данных: если вы данные загружаете, он, как правило, их определяет; если определить не может, всё отправляет в текст. Текст — такой универсальный тип, в который можно засунуть всё что угодно. За этим надо следить, потому что он может отправить в текст то, что текстом не является, или как-то ещё определить автоматически некорректно. Поэтому контролируем это — первый момент. Если показывает ошибку, есть два варианта: либо он на самом деле определил тип и сам промахнулся, либо у вас в принципе ошибочный тип подъехал — надо смотреть, что у вас в исходных данных. Если появляется какая-то ошибка в ячейке, вы можете щёлкнуть в пустом месте — и там, где вывелось значение, выводится причина ошибки, и вы с ней работаете. С ошибками можно ещё по-разному работать: по-разному их выуживать, отслеживать и нейтрализовывать, есть такие инструменты.
Пока преобразовали немного, но преобразовали: в таблице с промокодами появился дополнительный столбец «Процент скидки», и он теперь представлен числом 0,11. На этом эту фазу завершим. Повторюсь, календарик мы не сделали, но если будет опция в конце — вернёмся. Он, конечно, очень нужен, но я рискую не вписаться в полтора часа, поэтому экономим на чём можем.

Очень часто, когда мы только-только начинаем работать, мы делаем неправильные шаги: добавляем столбцы с неправильной формулой, которые неправильно нам считают. Как я это часто вижу, смотрю студенческую работу: добавление столбца, удаление столбца, добавление, удаление, добавление, удаление — добавили, поняли, что он неправильный, удалили. Каждое наше действие Power Query протоколируется отдельным шагом со своим кодом. И здесь правильно не нейтрализовывать неправильное действие, а исправлять — то есть сделать неправильное правильным; ну либо, в конце концов, удалять само действие неправильное. Потому что каждый шажочек, запротоколированный в Power Query как шаг преобразования, отъезжает: на маленьких табличках вы этого не заметите, а на больших вполне можете какое-то время при обновлении данных, потому что весь этот путь преобразований будет проходить система, когда данные будут обновляться — при загрузке в модель либо уже в дашборд для пользователей.
Определять типы данных — всегда, и следить за тем, чтобы они были корректными. Базовая оптимизация цепочек шагов: шаги можно и нужно группировать по смыслу — например, добавили столбец, изменили тип, добавили, изменили; удаление столбцов и ряд других действий можно сгруппировать в один шаг, чтобы хотя бы ваш код для вас самих был более читабельным. У любого шага абсолютно у любого есть код, который всегда можно скорректировать. И заглядывайте почаще в документацию: очень много моментов, которые вы кнопочками сделать не сможете. Даже добавление столбца: функция добавления столбца имеет у себя параметр сразу типизации, то есть она может определять тип, а можно определённым аргументом прописать тип данных для создаваемого столбца — но в интерфейсе этого нет: когда мы создаём столбец, он создаётся без типа. Поэтому заглядывайте в документацию, относитесь критично к собственному коду, оптимизируйте, учитесь делать код максимально простым, понятным и со встроенной последовательностью шагов.

Модель данных — это схема, где изображены таблицы и связи между ними. Таблицы описаны через название таблицы и наименование всех столбцов. Поэтому важно, чтобы все ваши столбцы назывались в соответствии с тем, какие данные они хранят. Однажды у меня был опыт, когда мне передали дашборд на доработку, а там было примерно следующее: таблицы назывались «Дашборд 1», поля — «Колонка 1», «Колонка 2», «Колонка 3», весь дашборд такой, полтора десятка таблиц и достаточно большое количество полей, и всё названо вот так, пронумеровано. Для человека, который даже это разработал, — через неделю, через день, кто-то через пять минут забудет, что нумеровал под номером 7. Поэтому называем всё в соответствии с тем, что у нас там лежит.

Связи могут быть разные. Ключевое отличие связей: очень часто, когда мы смотрим на модель, нам кажется, что это примерно то же самое, что база данных, потому что если вы знаете, как выглядит схема базы данных, вы увидите примерно такую же визуально картинку. Важное отличие: когда мы видим связь между таблицами в БД, эта связь обозначает непосредственно связь — есть компания, есть сотрудники, они связаны между собой, у них есть что-то общее, есть поля, по которым мы понимаем, в какой компании какие сотрудники. Связь в моделях BI — это и связь смысловая, и кое-что ещё: это фильтрация. Поэтому у каждой связи есть направление кросс-фильтрации. Какие-то BI-системы позволяют только однонаправленные связи; в Power BI могут быть однонаправленными и двунаправленными.

Что значит фильтрация: если у нас есть, например, источники сделок и клиентов и есть сделки, и у стрелочки между источниками и сделками направление от источника к сделкам, это означает, что выбранный источник на визуализации отфильтрует сделки, а выбранная сделка не отфильтрует источник. И получается, что когда мы строим визуализацию, каждый наш визуальный элемент, каждый график, каждая таблица внутри себя под капотом занимается этой фильтрацией. Если мы рисуем сделки по источникам, то источник, для которого система должна посчитать количество сделок, будет косвенно фильтровать всё непосредственно по связям в вашей модели. Поэтому правильная модель — я когда-то очень сильно недооценивала этот шаг, но сейчас знаю, что это ключевая история — это залог и оптимального дашборда, и быстрой его работы, и оптимальной поддержки в последующем.
Связи могут быть разные по кратности — это соотношение количества строк одной таблицы со стороны связи и другой таблицы с другой стороны. Есть три классических: один ко многим (или многие к одному — в зависимости от того, с какой таблицы смотрим), один к одному и многие ко многим. Один ко многим означает, что одна строка в одной таблице соответствует нескольким в другой — например, те же источники со сделками: одна строка в таблице источников соответствует нескольким строкам в таблице со сделками. Один к одному означает, что ровно одна строчка тут, одна строчка там — не больше (меньше, может быть). Многие ко многим — когда у нас много строчек там и много строчек тут. Но будьте внимательны: когда Power BI не даёт вам поставить никакую связь кроме многие ко многим — это считайте красный флаг, который вам вывесила система и намекает, что здесь что-то не так. Потому что в норме и по правильному связь хоть и есть технически, но лучше её избегать: и при визуализации, и при расчётах она может давать очень товарный эффект, который не всегда можно в моменте быстро отследить и понять, что вообще происходит. Самым надёжным способом типичная классическая модель построена, как правило, на связях один ко многим.
Про фильтрацию я уже сказала: если у нас связь двунаправленная, то мы в обе стороны можем фильтровать. Например, когда у продаж есть покупатели и товары и связь между покупателями и продажами, товарами и продажами двунаправленная, то косвенно через продажи покупатели видят и могут фильтровать товары, а товары могут фильтровать покупателей. В случае, когда у нас связь однонаправленная между этими таблицами, такой фильтрации не происходит. Есть такой нюанс, что двунаправленные связи в силу их работы внутри Power BI считаются менее оптимальными, поэтому опытные аналитики стараются их тоже избегать. Но если у вас небольшая модель, как у нас сегодня в примере, то в этом ничего страшного как минимум точно нет.

Есть так называемые классические модели — «звезда» и «снежинка», иногда упоминается ещё «созвездие». Они построены на нескольких постулатах. Как минимум первый: все таблицы можно условно поделить на два типа — таблицы фактов и таблицы измерений. Страшные слова для начинающих аналитиков. Таблица измерений — это таблица-справочник. Таблица фактов — это, как правило, очень объёмная таблица с теми фактами внутри компании, которые происходят и которые предполагается анализировать. Например, источники — это таблица измерений, справочник в чистом виде; сделки — таблица фактов, они привязаны к дате и их достаточно много, кратно больше, чем источников.
Считается, что для правильных «звёзд» и «снежинок» соотношение таблиц фактов и измерений должно быть: фактов — много, измерений — один, то есть все связи между ними должны быть один ко многим.

Модель «звезда» — когда у нас есть одна таблица фактов и вокруг неё какое-то количество таблиц измерений, между которыми ни в коем случае не должно быть своих связей: все связи между таблицами измерений реализуются чисто через таблицу фактов, сквозняком. Для «звезды» характерно также то, что у нас только один уровень таблиц измерений.

Для «снежинки» правило одного уровня таблиц измерений неприменимо: по сути, «звезда» — частный случай «снежинки», и для «снежинки» характерно, что у неё могут быть некие связи между таблицами измерений, в том числе, но таблица фактов также одна, и она также условно центр всей вселенной. Чтобы положить модель в эту классику, надо, по сути, привести всю нашу историю с теми данными, которые у нас есть, в ситуацию, когда у нас таблица фактов одна, иначе мы её не положим. Для ситуаций, когда положить не можем, упоминается ещё «созвездие» — там таблиц фактов несколько, но тоже модель достаточно специфичная. Чаще всего у аналитиков встречается такая модель, которую я называю «паутина», в которой очень тяжело разбираться и которая очень тяжело отслеживается и оптимизируется. Поэтому классика — надо, и классика — чтобы к ней стремиться; но жизнь чуть сложнее, и есть подходы, как уложить реальную бизнес-модель в «снежинку» — об этом можно было бы поговорить на отдельном вебинаре.

Возвращаемся в Power BI. У нас вот такой набор таблиц, и здесь достаточно классическая «снежинка», ну даже почти «звезда». У нас есть заказы — это таблица фактов, такая, скажем, неопоримая, и набор таблиц измерений, или справочников: заказчики, менеджеры, категории продуктов, продукты, промокоды, статусы оплат. Всё это относится к заказам по соотношению один ко многим: на одного заказчика может быть один или несколько заказов, на одного менеджера тоже; у заказа только один заказчик, только один менеджер, только один продукт, промокод и статус. Из такого принципа мы сейчас настраиваем связи.
Связи настраиваются достаточно просто технически — их не просто продумать, но настроить буквально минуты. У нас есть какое-то поле в одной таблице и какое-то поле в другой, и связь настраиваем, по сути, перетаскиванием поля над полем. Можно, конечно, открыть диалоговое окошко и там всё выбрать в списках, но здесь кому как удобней. Когда настраиваем связь, открывается окошко, где видим выбранный столбец с одной таблицей и выбранный столбец с другой; если промахнулись — корректируем, но глазками контролируем, что столбцы содержат одно и то же. Это важно. Во-первых, связывать таблицы можно только по одному столбцу: связь в принципе подразумевает только один столбец в одной и в другой таблице раз. Второй момент: тип данных должен быть одинаковый железобетонно. Если у нас в одной таблице Power Query интерпретировал столбец с ID как число, а в другой почему-то решил, что это текст, или мы так решили, то связь, конечно, свяжется, нарисуется, но работать не будет, и вы об этом узнаете, когда будете строить дашборд и не будете понимать, а что у нас и почему всё так.

Заказчики к заказам — один ко многим, оставляем направление перекрёстной фильтрации в обе стороны, связь будет активной. Есть ещё неактивные связи — тоже отдельная история. Сохраняем — рисуется стрелочка с двумя направлениями. По образу и подобию, уже не сильно поясняя, связываем менеджеров — один ко многим, оба сохранить; категории продуктов — они относятся к продуктам, продукты — к заказам, это вот та самая часть «снежинки»; промокоды — то же самое; статусы оплат — ID. Простое техническое действие. Но для того, чтобы собрать именно такую модель, нужно, чтобы таблицы к нам приехали вот в таком виде, чтобы мы такую модель собрать смогли. Потому что чаще всего, когда мы начинаем работать с таблицами, а не с проектирования модели, мы получаем набор таблиц и не понимаем вообще, как это связано. К этому надо подходить осмысленно. Вот она, наша модель — классическая «снежинка». Запомнили, идём дальше.

Несколько моментов, которые я отчасти уже проговорила. Контролируем типы данных и их содержание, контролируем пустоты — у нас сегодня будет кейс, когда пустота проявится, мы её увидим, но сделать с ней уже, наверное, не успеем. Модель строится, проектируется до того, как собирается дашборд: то есть вам нужно до того, как вы начнёте что-то визуализировать и собирать в Power BI, подумать, как будет выглядеть модель, чтобы вы могли на этой модели нарисовать тот дашборд, который вам нужен, и собрать эту модель из тех данных, которые у вас есть. Это очень творческий и нетривиальный местами процесс. Таблицы фактов и измерений — по ситуации: хоть их и называют фактами и измерениями, есть некоторые ситуации, когда одна и та же таблица в разных дашбордах может быть в разной роли. Классические модели — «звезда», «снежинка», «созвездие». Важно знать, с какой детализацией, с каким уровнем детализации у вас данные в таблицах: гранулярность данных влияет и на модель, и на возможности визуализации. И неправильная организация модели, если мы о ней не подумали заранее, обрекает вас на грандиозные переделки, на вот такие вычисления потом, чтобы из этой модели собрать дашборд, который вам нужен. Поэтому с модели, с визуализации, с продумывания мы всё это дело начинаем.

DAX — это встроенный язык в Power BI, с помощью которого мы можем создавать вычисляемые столбцы, вычисляемые таблицы, меры, а также с помощью вычислений на DAX настраиваем ограничение видимости данных для наших пользователей. Справочник DAX по QR-коду.

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

Когда мы пишем, у нас есть автозаполнение и подсказки: DAX нас немножко контролирует — когда начинаем что-то вводить, он подбирает, что подходит вот в это конкретное место этой формулы с таким началом или с таким содержимым буковок, которые мы уже ввели. Иногда бывают ситуации, когда мы хотим использовать какой-то столбец, какую-то меру или что-то ещё, а в списке нет. Хороший повод задуматься, а то ли мы хотим использовать и там ли: если нет в списке, скорее всего, именно здесь именно так это использовать нельзя — либо мы что-то не дописали, либо мы хотим совершить ошибку, и нас от этого предостерегают. Аргументы, как я уже сказала, в скобочках описываем; они точно так же вываливаются в подсказках. Наряду с функциями вываливаются таблицы, столбцы, меры — все допустимые вариации, которые на данный момент в данном месте доступны.
У нас есть разные объекты, которые мы создаём с помощью DAX, и упоминаются они немного по-разному. Таблица упоминается либо, если она состоит из одного слова на латинице, без ничего — просто словом; если слов несколько либо они на русском — мы их пишем в одинарных кавычках. В квадратных скобках мы упоминаем столбцы; столбцы всегда упоминаются вместе с таблицей, если они из другой таблицы, а если из текущей, то можно без таблицы — и так понятно. Меры — без привязки к таблице, просто в квадратных скобках. Аргументы функций — в круглых скобках. Не запутаемся: одинарные кавычки — таблицы, квадратные — меры и столбцы, круглые — аргументы функций. Если с формулой всё в порядке, мы использовали то, что нужно, там, где нужно, — в случае столбцов она считается, в случае мер сохраняется; но так или иначе происходит проверка на ошибки и либо сохранение, либо сообщение об ошибке.
Важно, что и Power Query, и DAX — это языки, которые работают с табличными данными: они работают целиком с таблицами, целиком со столбцами. Они не работают как Excel — «дай, пожалуйста, мне ячейку A1» — такого нет. Мы можем хитро, выдуманно сходить по адресам конкретных ячеек и достучаться, но это совершенно не имеет никакого смысла, потому что обновятся данные, и те же данные встанут в другую ячейку — и всё, приехали. Поэтому запоминаем и учимся с этим работать: и Power Query, и DAX работают целиком со столбцами и таблицами. И когда нам в какой-то момент нужно взять не весь столбец, а какую-то его часть, мы это делаем через фильтрацию: берём весь столбец, отфильтрованный по каким-то критериям, и таким образом забираем те значения, которые нам нужны. Понимаем, что можем забирать местами какое-то конкретное — например, по связи достучаться, забрать; или забираем что-то и понимаем, что там значений несколько — здесь нужно учитывать, нужно нам это агрегировать или нет. Понимание вот этих вещей, в принципе, открывает путь в DAX и даёт возможность быстро собирать формулы. По кнопочке Enter запускаем нашу формулу в работу.

Мы можем создавать столбцы и меры. Столбцы — это то, что мы сейчас в Power Query создавали: создаём его в DAX и наблюдаем непосредственно в таблице; он будет выглядеть и использоваться точно так же, как любой столбец, который к нам уже приехал в модель, — мы создаём свой или он уже приехавший вместе с данными, разницы в этом плане не будет. Так или иначе это столбец, который виден, посчитан для каждой строки и имеет свои особенности; в случае с DAX он ещё имеет формулу. Меры в таблице не видны; в принципе, они видны только тогда, когда мы начинаем их визуализировать. Мера — это динамическое вычисление, которое будет пересчитываться в зависимости от того, с чем вместе мы её поместим на визуализацию, от того, как мы отфильтруем визуализацию, и так далее: все взаимодействия пользователей с визуализациями влияют на то, как будут пересчитываться меры.
Отличия:

• Момент вычисления. У столбцов значения вычисляются моментально после создания; меры вычисляются только во время визуализации: когда вы меру написали, нажали Enter — она не вычисляется, сохранилась только формула, проверилась на корректность, уложилась в модель, и всё; вычисление происходит тогда, когда мы её визуализируем и когда пользователь работает с визуализацией — что-то фильтрует, что-то меняет, и меры пересчитываются.
• Память. Значения столбцов хранятся в оперативной памяти и сохраняются в модели; для мер в модели хранится только формула. Отсюда: чем больше у вас вычисляемых столбцов, тем тяжелее ваш файлик Power BI; а от мер файлик резко не увеличивается.
• Контекст. Столбцы вычисляются в контексте одной строки той таблицы, для которой мы их считаем, на основании значений столбца; так как это уже заведомо понятные и предрассчитанные значения, мы их видим и можем понимать, сколько у нас таких значений, на основании этих значений могут создаваться фильтры и срезы, эти значения мы можем вытаскивать на оси наших графиков — на какие-то блоки графиков, где подразумевается, что должны быть измерения. Меры усложняются контекстом, так как пересчитываются в зависимости от визуализации: нужно понимать, как эта визуализация влияет на конкретно вашу созданную меру и где что может пойти не так.
• Срезы. На основе значений столбцов могут быть созданы фильтры или срезы; на основе мер — нет. Так как у мер заведомо заранее нет никаких предрассчитанных значений, мы не можем поместить их в фильтр. Есть одно исключение — в боковой панели, но на визуализации нет никаких способов вытащить меру в фильтр и по ней фильтровать данные на дашборде.

Пойдём на представление данных, представление таблиц, где непосредственно наши таблицы. Начнём с создания столбцов. Сейчас начну тихонько ускоряться и не буду писать формулы от руки — одну напишу, остальные по образу и подобию, потому что в полтора часа очевидно не впишемся.
Сумма заказа. Идём в заказы и обращаем внимание на следующую штуку: у нас в заказах нет денег. А где они есть? Деньги есть только в одном месте — в продуктах: у продуктов есть стоимость по прайсу, в соответствии с этой стоимостью курс выложен на сайте. Чтобы посчитать стоимость заказа, нужно учесть несколько вещей. Во-первых, каждая строчка заказа — это отсылка на какой-то продукт: я взяла рандомный, это 17-й продукт, то есть у него где-то в соседней таблице ценник есть. Но этот 17-й продукт продали с какой-то скидкой по промокоду — здесь промокода нет, окей, здесь нет скидки, но где-то там внизу они точно есть, а продали со скидкой. И более того, возможно, не дошли до нас деньги, потому что у нас есть три статуса оплаты, и только один из них успешный. Соответственно, чтобы посчитать итоговую сумму заказа, надо учесть стоимость по прайсу, учесть промокод на скидку, если он есть, и учесть статус оплаты: только в случае успешности статуса мы можем на какую-то сумму претендовать.
Создаю столбец «Сумма заказа». Начну с простого и буду наращивать вычисления по мере логики. Первое: вытащим ценник из продуктов, тот, который по прайсу. Так как продукты с заказами связаны, у нас есть функция, которая вытаскивает значения; их, на самом деле, две, они работают в разную сторону. Есть RELATED — вытаскивает значение из связанной таблицы в том случае, если оно единственное, то есть с той стороны, где связь один ко многим и стоит единичка: с той стороны мы можем вытащить значение, потому что оно априори должно быть единственным, если оно в принципе есть. RELATEDTABLE работает в обратную сторону, но обязательно с агрегацией. Я написала функцию RELATED, открыла скобочку — и у меня перечень всех полей, доступных мне в контексте этой функции; мне нужны продукты, мне нужна стоимость по прайсу. Скобочку не забываем закрывать. Я выбрала из списка, не писала ни кавычек, ни скобок. Из таблицы с продуктами колонка «Стоимость по прайсу» — для каждого продукта приедет значение. Нажимаю Enter и могу сходить в соседнюю таблицу и убедиться, что у 17-го продукта цена 37 500 — не больше, не меньше, это та сумма, которая пришла бы нам, если бы не было скидок и статусов оплаты. Но они есть.
Теперь учтём скидку. У нас есть промокоды, они тоже есть идентификаторы, не везде они есть, но по тому же принципу, что и стоимость продукта, мы можем вытащить скидку по промокоду и на неё умножить. Но умножим не на саму скидку — нам нужна единица минус скидка. Дальше — таблица с промокодами и наш процент скидки, который мы создавали в Power Query. Скобку закрыла, сейчас RELATED. Теперь что получилось: та цена по прайсу, которая была, умножается на единицу минус процент скидки — осталась та сумма, которая за вычетом скидки. В том случае, когда промокода нет, здесь просто будет пустота, и у нас останется единичка. Нажал Enter — выглядит так, как будто ничего не поменялось, но потому что промокода здесь нет. Если долистаем туда, где промокоды должны добавиться, — вот они, тут уже не такие ровные циферки, и мы понимаем, что скидка тут посчиталась.
Возвращаемся обратно. Мы учли два фактора, у нас ещё есть третий: статус оплаты. Мы должны посчитать сумму заказа только для ситуации, когда статус оплаты успешный. Сходим в таблицу со статусами оплаты и увидим, что у нас есть поле, отвечающее за успешность. Если для нашего заказа у статуса оплаты это поле true — то мы считаем, иначе не считаем. Здесь мы можем использовать функцию IF — она есть абсолютно, наверное, во всех языках программирования, где-то чуть различающихся вариантах синтаксиса; принимает все три аргумента: первое — утверждение, которое мы проверяем (статус оплаты истинен или не истинен), второй — то, что возвращается в случае, если проверенное утверждение истинно, и третий — если нет. Возвращаемся в заказы, в нашу формулу. Когда щёлкаем на столбец, высвечивается формула, мы можем её редактировать. Я сейчас эту штуку вырежу, то есть сохраню в буфере — главное не стереть, — и напишу следующее: IF, открываю скобку, у меня подсвечивается три аргумента — логическое выражение, результат если истинна и необязательный результат если ложь; если третий аргумент не указываем, получаем blank, пустое значение. Логическое выражение: опять же, та же функция RELATED — из статусов оплат вытаскиваем поле is_success. Если вот эта истина — то вставляем наше вычисление, и закрываем скобку, потому что ничего, кроме пустоты, нам на второй вариант возвращать не надо. Теперь у нас в строчках, где статус оплаты не успешный, такая веющая пустота, а мы посчитали сумму заказа.

Сумма заказа без учёта скидки. Скопирую, создам ещё один столбец — теперь чуть меньше пояснений — «Сумма заказа без учёта скидки». Она пригодится потом для визуализации. Это означает, что мы вот эту часть уберём — будет только стоимость по прайсу с учётом статуса.
Сама скидка. Создам столбец «Сама скидка». Копируем формулы (и не надо их копировать). Для успешных статусов — стоимость по прайсу, но без единички.
Упущенные заказы. Последняя формула, которую здесь добавлю, — «Упущенные заказы». Это как раз неуспешный статус оплаты: если статус оплаты не успешный, то берём стоимость по прайсу со всеми скидками, промокодами и прочим. Упущенные должны появиться там, где основной нету, где у нас сумма заказа пустая, — там у нас есть упущенная.
Заказчик (в таблице заказчиков). Одна колонка для заказчиков — она нам пригодится. У нас имя и фамилия в разных столбцах, мы сольём в одну строчку. Создаём также столбец в этой таблице — «Заказчик»: открываю квадратную скобку, пишу — и у меня подсказки столбцов из этой таблицы — Last Name, объединяем с пробечиком и объединяем с именем. Можно в обратной последовательности, дело вкуса.
Со столбцами закончили. Мы видим, что они физически появились, физически посчитались для каждой строчки наших таблиц, для которых мы их считали. А меры давайте создадим в момент, когда будем визуализировать, чтобы у нас сразу эта конструкция складывалась и её сразу можно было посмотреть.

На одни и те же действия у Power BI есть гораздо больше вариантов, не только DAX, и у Power Query тоже. Связывание данных: join на уровне SQL (если допустимо), join на уровне Power Query, связь в модели, подтягивание нужных данных с помощью DAX. Добавление вычислений: на уровне SQL (если допустимо), на уровне Power Query, столбцы DAX, меры DAX. Все четыре варианта в разных ситуациях допустимы, у каждого свои плюсы, минусы и ограничения — здесь творческий процесс. Есть вычисления, которые вы физически в Power Query не сделаете. Вычисления правильнее делать в Power Query, а не в DAX, потому что оперативки будет грузиться чуть меньше, когда всё уже предпосчитано, чем когда оно будет пересчитываться каждый раз в моменте; но не все вычисления легко сделать в Power Query — какие-то в силу оптимальности проще сделать в DAX, какие-то надо вынести вообще за пределы BI, какие-то, в принципе, не должны быть на столбцах, а должны быть на мерах. Сегодня у нас обзорный, больше ученический пример: в реальном кейсе с таким же дашбордом вычисления выглядели бы сильно компактнее и были бы все на мерах, но нам надо было посмотреть на столбцы.

Выбирая из этих вариантов, каждый из этих действий что-то нагружает: действия на стороне SQL нагружают базу данных; действия на стороне Power Query увеличивают время обновления; большое количество связей в модели усложняет работу, повышает риск ошибки, и не всегда связь вообще возможна — у вас может быть красивая «снежинка», и вот эта связь в принципе не вписывается в модель; столбцы DAX съедают оперативную память, увеличивают вес модели; меры DAX съедают оперативную память в момент работы визуала и делают его более медленным. И всегда есть вариант вообще вынести обработку за пределы BI. В рамках одного вебинара не смогу рассказать все нюансы, в каких ситуациях какие решения предпочтительнее, какие есть подводные камни. Есть общие паттерны: чем раньше мы преобразование сделали, тем лучше; чем меньше данных за эту модель, тем лучше. Но каждый раз, когда мы сталкиваемся с новым дашбордом, это всегда творческий процесс — как откалибровать всю систему так, чтобы ничего не перегрузить и чтобы было оптимально быстро, красиво и рабочее.

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

У каждого графика своя задача. Типично любой график решает как минимум одну из четырёх задач: позволяет что-то с чем-то сравнить; позволяет распределить что-то по какой-то детализации (скажем, сделки по источникам); показывает структуру — в долях чего и сколько; показывает взаимосвязь показателей. В интернете очень много разных так называемых чарт-чусеров, где, исходя из определённой логики, можно подобрать график, но сегодня мы туда не пойдём — это тоже можно провалиться и ещё на полтора часа остаться. Важно: у каждого графика своя задача. И то, что график выглядит красивым и кажется «ух ты, какой классный, сейчас мы как запилим — тут дашборд, все порадуются»: чем страннее, сложнее, витиеватее и необычнее график, тем больше шансов, что ваш пользователь его не поймёт, посмотрит и скажет: «А можно мне табличку, пожалуйста, простую?» А большинство классических задач для дашбордов закрывается буквально 5–7 типовыми графиками: гистограммы, пайчарты, таблицы, карточки, линейные графики. Это та база, которую надо просто знать, какой чарт где применять, и ей оперировать. Иногда для разнообразия либо для каких-то эксклюзивных задач выбирать графики, выпадающие из этого списка, но большинство задач решается вот этим набором.

Одни и те же гистограммы — казалось бы, целый спектр решений: четыре столбчатых и аналогично им четыре линейчатых. Даже если по столбчатым пройтись — вроде бы гистограмма, всё понятно, — а нет: одной мы показываем динамику и сравниваем показатели в разные месяцы друг с другом; другой показываем одновременно и динамику, и структуру; третьей показываем соотношение, распределение; четвёртой, по сути, тоже структуру в каком-то виде. Все вроде бы одни и те же гистограммы, но чуть-чуть разные. С линейчатыми примерно то же самое. У каждого графика свои кейсы, в которых они применимы и в которых смотрятся неуместно: если вы хотите что-то с чем-то сравнить, но при этом берёте неподходящую диаграмму — извольте, пользователь вас тоже не поймёт.

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

Все мы, когда компонуем дашборд, немножко дизайнеры, немножко психологи и немножко бизнес-консультанты — вот такой интересный процесс получается. Как дизайнеры мы должны уметь работать с цветом, с формой, с компоновкой, с сочетанием объектов рядом друг с другом. Как психологи мы должны понимать, как работает человеческий мозг при восприятии информации: что он видит, когда, что он думает — даже не успевает подумать, а как он реагирует, когда видит, например, дашборд, раскрашенный в прекрасные красные цвета весь. У меня, понятно, включается фильтр и насмотренность, но тем не менее где-то там мозг успевает немножко испугаться, выпустить какую-то толику адреналина и сказать, что что-то ужасное произошло, раз у нас тут всё красное. Мы должны понимать, как человеческий мозг реагирует на разные визуальные элементы, где он отреагирует позитивно, где негативно. Как бизнес-консультанты мы должны понимать, как дашборд вписывается в процесс компании: если он красивый, замечательно выверенный в цветах, замечательно воспринимается, но совершенно не подходит под то, как его собирается использовать пользователь — увы, переделываем всё.
Принципы компоновки — буквально несколько, весьма поверхностных. Самый важный — верхний левый угол: это и из психологии, и из дизайна интерфейсов; у нас всегда самое важное — левый верхний угол, а кнопочка «окей» и «отмена» всегда в правом нижнем. То есть мозг воспринимает информацию от левого верхнего к правому нижнему углу, соответственно, важность бывает именно в этом направлении. Связанное по смыслу — рядом, не растаскиваем по разным углам: если что-то не связанное, то, возможно, не надо это помещать рядом, потому что мозг будет считывать это как что-то рядышком. Выделение главного — размером, цветом, какими-то элементами, подсветками, условными форматированиями, стрелочками, значками, чем угодно: мы выделяем для пользователя главное, чтобы он за условные пять секунд увидел то, что ему важно увидеть в этом дашборде, — а для этого нужно понимать, что пользователю надо, и здесь у нас и про бизнес, и про консалтинг, и про всё подряд. У графика должен быть оптимальный размер: его должно быть можно прочитать, адекватно понять, что на нём изображено, у него не должно быть километровых скроллов. Заказчики, особенно перешедшие с Excel, очень часто хотят, чтобы это была таблица, уходящая в бесконечность вправо, влево и вниз тоже. И типичная компоновка идёт от общего к частному: мы начинаем с каких-то крупных вещей, спускаясь по мере прохождения глазами к более детальным; либо на одном дашборде информация, в принципе, одного уровня детальности, просто в разных ракурсах. Как правило, два таких паттерна: мы не ходим от мелкого к крупному — не помещаем сначала детальную таблицу, а карточки в конец с крупными показателями, это будет всегда наоборот. И единство стиля сквозь все дашборды компании, единство решений в принципе восприятия информации: чтобы пользователь, заходящий в один дашборд, а после этого во второй, не должен был переобуваться в воздухе, понимая, что тут изображено; чтобы у него паттерны восприятия подсветок и прочих визуальных вещей были одинаковыми. На основании этого мы всё это простраиваем на уровне компании.

Масса ошибок, которые делают в визуализации, — оставлю на самостоятельный пересмотр записи. Ошибок может быть много: круговая диаграмма на 5+ категорий, когда сектора становятся неразличимы; обрезанная ось Y, которая искажает восприятие разницы; 3D-эффекты, которые затрудняют чтение и не добавляют смысла; двойная ось Y с разными масштабами, где можно неверно интерпретировать связь; слишком много цветов (больше 6–8) — визуальный шум, трудно запомнить значения; неуместные цвета — красные и зелёные элементы несут свой смысл. И шуточный график тому в помощь.

Визуализация будет достаточно простой: набор срезов, пара карточек и буквально четыре графика.
Срезы. Начнём со срезов. Календаря у меня нет — я его не добавила; ладно, выкрутимся пока без него. Визуализация добавляется достаточно просто: щёлкаем, находясь в пустом месте дашборда, добавляется заготовка под график. Вынесем сюда единственную дату, которая есть в заказе: из даты вытащим год, вытащим месяц. График резко переобулся — сначала показывал диапазон, сейчас уже выпадающий список. У каждого графика, когда он выделен, доступны три вкладки: на первой настраивается состав данных, который будет в этом визуальном элементе; на второй — то, как он будет выглядеть визуально (там целое дерево вкладок); на третьей для некоторых визуальных элементов (для срезов недоступно, для гистограмм доступно) — разные статистические константы, линии, которые можно нарисовать отдельно, то есть пошла статистика. Зайдём во вторую вкладку и сделаем следующее: параметры среза поставим «раскрывающийся список». И ещё сокращу весь график-срез до нужных мне размеров и скопирую несколько раз. Дальше добавим сюда категории, наименование товаров. Я скопировала, чтобы не настраивать больше размер, удалю. Теперь отсюда поле с датами вытащу, из категории продуктов — название продукта и категории, из продуктов — сам продукт; когда мы вытаскиваем два поля, у нас получается иерархия. Из значений дальше копируем ещё раз, двигаем, ставим рядышком, вынесем туда промокод — промокод у нас в промокодах, сам код. Сделаю ещё четвёртую заготовку; тут исходя из размера — под 6, не под 6, под 5 нет, под 6, всё правильно. Здесь ещё два, но они появятся чуть позже, а здесь вместо промокода мы положим менеджеров. Вот такие у нас четыре среза.

Меры. Дальше идём в меры — те самые, которые пропустили на предыдущем этапе. Я добавлю таблицу: нажму «Введите данные», ничего вводить не буду — всех обхитрю, создам таблицу, и она будет пустой. Назову её «Меры», нажму «Загрузить», и она прокатится через Power Query, как ни странно. Появилась вот такая таблица «Меры», и теперь я в этой таблице создам меру. Мера создаётся в привязке к таблице: у неё таблица как контейнер, но смысла в этом никакого нет — без разницы, в какой таблице будет храниться мера, она из любой таблицы будет вести себя одинаково, она как бы сквозная через весь дашборд. Напишу очень простую меру: «Сумма продаж» — будет суммировать колонку в таблице с заказами, сумму заказа. Нажму Enter — добавилась мера, у неё такой специфический значок, не такой, как у столбцов. И теперь, когда у меня есть первая мера, я у этого столбца 1, который пустой, нажму «Скрыть» — и Power BI поймёт, что эта таблица создана под меры, присвоит ей определённую иконку и утащит её на самый верх, независимо от того, как она называется и как она по алфавиту должна быть. По образу и подобию добавлю ещё несколько мер: «Сумма продаж», «Сумма скидок» и аналогично «Упущенные продажи» — вот таким образом три меры.

Карточки. Добавим карточки, растянем их на три графика и эти три наши меры сюда вытащим: сумму продаж, сумму скидок и упущенные продажи. Появится вот такая конструкция. Чуть подтянем её по высоте — хватит ей сотни; можно поиграться с цифрами, настроить оформление, как это всё будет выглядеть.

Гистограмма с переключателем показателей. Дальше я хочу настроить гистограмму: на оси X будут месяцы — скажем, год и месяц, — а на оси Y один из трёх показателей; хочу, чтобы была переключалка этих показателей. Как это сделаю? Пойду на вкладку «Моделирование» → «Создание параметра». Создадим параметр, назовём его «Показатели», и вот сюда в окошечко накидаем наши примеры: сумму продаж, сумму скидок, упущенные продажи. Создаём. У меня добавляется вот такая таблица (она тоже выглядит немножко с другими значками), появляется срез и появляется вот такое интересное вычисление, которое показывает, что у меня будет фильтр на мои показатели и будет отсылка этого фильтра на разные меры. Я теперь этот срез привожу к виду — говорю, что это будет раскрывающийся список размером 80 на 320, — вот сюда он у нас падает. И теперь на этот график, где уже на оси X у меня живёт год и месяц, я вытаскиваю «Показатель». Получилась интересная конструкция — просто потому, что у нас тут куча лет; давайте возьмём какой-нибудь один год, поставим 24-й. Что я вижу: я вижу сумму продаж — маленькую плашечку, это сумма скидок; то есть если бы мы не давали скидок, мы бы заработали вот на эту синюю полосочку больше. И оранжевым я вижу упущенные продажи. Здесь сейчас расцветка по умолчанию, стандартная какая-то схема стоит — чуть позже поменяем. Я могу видеть все три, а могу какой-то один — то есть я могу переключать те показатели, которые у меня есть на визуализации. Очень классная штука, которую очень часто заказчики просят в дашбордах. Добавим сюда метку итога, например, чтобы у нас какая-то циферка здесь была.

Линейчатая диаграмма с детализацией. Дальше я, например, хочу сумму продаж, но теперь сумму продаж в разных разрезах — то есть теперь параметр не показателя, а детализации. Та же самая конструкция: «Моделирование» → параметр поля, только теперь это будет не «Показатель», а «Детализация». В эти детализации — в разрезе чего я хочу смотреть на продажи — хочу в разрезе промокодов, продуктов, менеджеров; давайте категории продуктов, добавим четыре поля. Создаю. У меня добавляется ещё один такой же срез; мы уже помним, что с ним надо сделать: раскрывающийся список 80 на 320 и утащить в правый угол. Но так как мы пропустили фазу переименования полей и приведения их к человеческому виду, у меня в списке они называются так же не очень красиво. Давайте мы их найдём — это наша таблица с детализациями: «Промо коды» — прямо так и напишем, мы можем редактировать то, как будет названа наша детализация в списке: «Промокод», «Наименование» — ну, можно просто «Продукт», «Продукт», «Менеджер» и «Категория», пускай будет просто «Категория». Закрыли. Теперь в детализации создаём ещё один график — теперь это будет линейчатая диаграмма. На ось Y мы вытаскиваем нашу детализацию (ось Y — это то, что будет у нас в категориях у линейчатой диаграммы), а на ось X вытаскиваем сумму продаж из мер — и получаем вот такую конструкцию. Сейчас это выглядит специфично, потому что детализации выбраны все; надо полагать, что мы не хотим сразу видеть в разрезе всех четырёх — и в принципе это не очень удобно. Пойдём в настройки детализации, скажем, что у нас здесь будет единичный выбор, и, соответственно, промокод, продукт, менеджер — то есть в разрезе того, что мы выбрали, мы получаем наш показатель, добавим метки, получим в деньгах историю того, как у нас разбивалась сумма продаж по нашим категориям.
Это минимальная визуализация. Можно было бы ещё, но я уже что-то отправлю на контент и буду опубликовать уже после нашего вебинара.

Вопрос из чата: что в этом случае лучше — переименовать колонки в BI или создать доп. шаги в Power Query по замене названия колонок? Лучше и правильнее — в Power Query переименовывать, чтобы у вас в модель приезжало всё чистое и уже понятное, потому что иначе вы будете переименовывать на каждом шаге в DAX, и это будет неудобно; вы сами будете путаться, потому что названия кривые. Правильнее это всё оставить на этап обработки данных.

Когда вы работаете в Desktop, вы ни с кем ничем поделиться не можете, кроме самого файла, который сохраните: после завершения работы сохраняем файл и можем его выслать; тогда этот кто-то должен быть не на Mac, с установленным десктопом, — он может открыть, и всё. Вы в рассинхроне в любом случае будете — это как эксельки друг другу пересылать, то же самое; кто-то так живёт, но не самый хороший вариант. Для того чтобы иметь возможность шарить доступ, настраивать обновление по расписанию, ограничивать видимость данных, нужна лицензия.

Чтобы опубликовать, нам нужно мало того, что иметь лицензию: нужно, чтобы мы были под той учёткой, на которую куплена лицензия, залогинены в десктопе — то есть связка десктопа с сервисом Power BI осуществляется через ту самую учётку, на которую вы эту лицензию приобрели. Если эта процедура пройдена, нажав кнопочку «Опубликовать», мы получаем перечень рабочих областей.
Здесь вступают в силу нюансы использования Power BI в России, скажу о них буквально пару слов. Первый нюанс: мы не можем в чистом виде пойти и на свою российскую компанию или на российское физлицо купить лицензию — не можем, потому что Microsoft официально из России ушёл и лицензии не продаёт. Многие компании, которые Power BI используют, покупают через зарубежные юридические лица либо через каких-то посредников — так или иначе находят способы. Второй момент — 152-й федеральный закон о персональных данных, который говорит, что все данные граждан Российской Федерации должны храниться на серверах Российской Федерации. Поэтому если у вас такое сочетание, что и персональные данные, и юридического лица нет, то здесь сложности в некоторой степени возрастают. Кто-то идёт на риск, кто-то не идёт — дело каждого; я ни к какой версии не склоняю, просто говорю как есть.
Вопрос из чата: как лучше экспортировать файл, если нет лицензии, чтобы была возможность повзаимодействовать с графиками, поменять какие-нибудь значения, чтобы посмотреть, как изменится график? Файл не то чтобы экспортировать — мы в принципе в файле. Для того чтобы опубликовать, мы этот файл сохраним — других вариантов нет, придётся сохранять, — и только после этого сможем опубликовать куда-либо. Файлик у нас физически сохраняется: вы можете перетащить его с компа на комп, можете кому-то выслать, взаимодействовать с ним. Повторюсь, то же самое, как эксельку кому-то выслать, и этот кто-то должен иметь десктоп — тогда у него будут все те же возможности, что и у вас.

В самом сервисе, по большому счёту, всё крутится вокруг рабочих областей: есть рабочие области (демо, дашборды, тесты) и моя рабочая область, которая по умолчанию есть у всех. Это те самые рабочие области, в которых мы что-то публикуем и в которых непосредственно работаем. Выберем, скажем, «Демо, дашборды», нажмём «Выбрать» — происходит публикация. После того как она пройдёт, перейдём в «Демо, дашборды» и увидим, что у нас добавилось, вот тут с такой пимпочкой, как будто что-то новенькое, свеженькое — лампочка горит.

Добавилось наше демо, оно разделилось на две части: одна часть представляет собой семантическую модель — это наши связи, наши таблицы, наши вычисления; вторая — непосредственно отчёт. Если щёлкаем на отчёт, мы получаем ту нашу картинку, которую настроили, в том виде, в котором она есть. Отсюда мы можем предоставить доступ пользователям. Вот она, наша картинка, как она выглядит в вебе; сейчас он прогрузится, одумается и всё нам покажет. Она также кликабельная, интерактивная и позволяет пользователям работать с данными.
К слову, не так давно у Power BI появилась бесплатная однопользовательская веб-лицензия, которую в целом можно на себя получить. Если вы с персональными данными не работаете, для каких-то вот таких экспериментов — пожалуйста. Но она однопользовательская: вы с неё не сможете выдать доступ никому, кроме самого себя.