Не секрет, что мощность и гибкость вычислений в Tableau это очень активно используемая история. За счёт довольно простого синтаксиса, подробной справки и массы ранее заданных и отвеченных вопросов в комьюнити, создание расчетных полей - это наша реальность. Чтобы не тратить кучу времени на то, чтобы создать удобную понятную конструкцию, или с легкостью восстановить прошлый полет собственной мысли - давайте разберем несколько полезных приемов. Пост обещает раскрыть методы, которые существенно упрощают создание, тестирование и поддержку расчётов в Tableau.
Можно долго спорить на тему перфоманса и удобства поддержки - вообще, это всё тот же давний холивар на тему, переносить расчёты в код источника или нет. Всё, как всегда, зависит от задачи - насколько гибкими должны быть расчеты в репорте, как часто они меняются, существует ли репозиторий с кодом источников в DWH, и доступен ли он аналитикам, занятым визуализацией.
Но для нашего сегодняшнего погружения - давайте представим, что мы строим сложносочинённые расчёты именно внутри отчета. Прежде всего, давайте определимся, что вообще считать сложным.
Вообще, даже если вы только начали свой путь, то вам могут казаться сложными любые расчёты дальше классических арифметических операций. Если вы в бою уже давно, то вы наверняка сталкивались со слоеными многоэтажными матерными конструкциями, которые через несколько вложений приводят к желаемому результату. Прекрасно то, что наши приемы пригодятся для вашего личного уровня сложности. Вычисления не будут нашей темой сами по себе, всё это так или иначе применимо и для создания кастомных полей при работе с текстом, группировкой элементов поля и прочей магией.
Итак, наш план таков:
Разделите логику на порции или этапы
Разложите исходные поля по папкам
Пронумеруйте поля и папки
Создайте валидационный лист
Прокомментируйте расчёты и добавьте pop-up описания
Всё! Если вы на опыте, то дальше можно не читать. Если же пояснения всё же нужны - давайте поговорим о каждом из приёмов чуть подробнее :)
1. Разделите логику на порции или этапы
Это однозначно то, с чего следует начать. Конечно, вполне можно добиться качественного результата и в одном калькулируемом поле - я видела, да и сама, признаться, когда-то создала немало таких примеров. Но читать портянку на несколько десятков строк довольно утомительно, иногда она банально не помещается на экране, а ещё бывает мучительно трудно найти все те закрывающие скобочки, которые вы упустили при изменении логики.
Tableau это, всё-таки, не IDE, функционал подсказок ограничен, а потому порционное деление облегчает отслеживание последовательности преобразований, которые мы применяем к данным.
А ещё иногда Tableau проще выполнять несколько вычислений по отдельности. Например, в случае табличных вычислений, таких как INDEX и WINDOW_SUM. Если вы поместите их оба в одну калькуляцию, вы рискуете потерять некоторую гибкость при вычислении таблицы, и, как следствие, контроль над результатом.
Проще всего применять хронологическое разделение, когда вы делите расчёт на отдельные шаги, выполняемые последовательно. Если по пути вы применяете какие-то типичные формулы - их гораздо легче будет воспринимать, если элементы этих формул будут представлять собой отдельные калькуляции, а финальная формула будет собрана из этих калькулируемых полей.
Еще одним неплохим способом будет разделение калькуляций на смысловые группы, применяемые к однотипным измерениям и мерам. Например, простенький план может выглядеть вот так:
Bonus base
Bonus values
Weights %
Coefficients
Final Bonus
Важно здесь то, что нам нужно сделать много разных мелких вычислений. Большинство из этих вычисляемых полей представляют собой пару строк - и их гораздо легче понять по отдельности. Если у вас всё-таки остались условно крупные куски логики - позаботьтесь об отступах, чтобы уровни было хорошо видно.
И, что не менее важно - контроль корректности. Вы строите один расчет, проверяете, что всё правильно, затем переходите к следующему шагу, постепенно наращивая цепочку до тех пор, пока не достигнете конечной цели.
2. Разложите по соответствующим папкам
Здесь стоит сказать очевидное - по умолчанию поля в панели слева будут расположены в алфавитном порядке. Если вы использовали джойны источников на уровне отчета - вы увидите ещё и группировку по источникам данных. Она полезна, когда достаточно просто знать источник, из которого берется поле, но все кастомные поля в таком случае будут лежать внизу списка, что тоже не всегда удобно.
Вот так выглядит дефолтный алфавитный порядок полей. Хорошо, когда полей штук десять, ну может двадцать. А если больше?
Если в вашем отчете будет много калькуляций - критически посмотрите на список полей и создайте смысловые папки для исходных полей тоже. Да, это отнимет дополнительное время, но его же (и даже больше) вы сэкономите в дальнейшем на розыск нужного поля. Для исходных полей это может быть группировка в разделы по смыслу, каждый из которых вы назовете таким образом, чтобы легко понимать, что лежит внутри.
3. Пронумеруйте поля и папки
А дальше можно работать с нумерацией самих полей, которые участвуют в реализации логики. Вернитесь к вашему плану из первого пункта и логическим порциям, присвойте им номера - и тогда каждое новое поле будет получать соответствующий номер, и вставать в списке полей на желаемое место в иерархии расчетов. Кроме прочего, теперь даже без погружения в каждое конкретное поле вы сможете понять, куда надо внести исправление.
После того, как основные расчеты будут написаны - создайте для них соответствующие папки. Компактность - наш лучший помощник.
На самом деле, иногда бывает уместно и папкам с исходниками дать какую-то нумерацию. Или a, b, c символы, чтобы добиться правильного порядка.
Да, если вам нужно выводить названия полей в визуализации - нумерация на уровне папки может быть предпочтительней нумерации на уровне поля, чтобы не озадачивать пользователей лишний раз.
В случае, если ваши этапы параллельны - добавьте уровень нумерации вроде 1.1, 1.2, и тогда вам будет понятно, что логика ветвится на этом конкретном шаге. В целом, имена однотипных полей должны начинаться одинаково, вы облегчите себе работу и в плане поиска, и в плане дальнейшей сборки последующих калькуляций. Это довольно крутая штука, когда в следующем уровне калькуляции можно копипастить, и при корректировке в названии поля достаточно исправить только окончание. Но здесь нужно быть особенно внимательным :)
4. Создайте валидационный лист
Итак, теперь, когда вы разбили свою логику на небольшие фрагменты и пронумеровали свои вычисления, чтобы упростить управление ими, как вы будете это всё тестировать? Зачастую, аналитики сразу начинают создавать чарты и добавлять фильтры на основе получившихся вычислений и группировок. Но гораздо надежнее будет не бросаться сразу в огонь - чарты прекрасны сами по себе, и порой процесс визуализации захватывает нас, кружит голову и отвлекает от проверки точности расчетов.
Вместо этого стоит начать с создания таблицы. Да-да, таблицы правят миром - а вы еще спрашиваете, почему пользователи просят у нас именно их?
Например вот так:
Это, конечно, выглядит жутковато. Но если не оставлять этот этап на сладкое, а последовательно добавлять расчеты в таблицу - вы сможете легко убедиться, что они соответствуют вашим ожиданиям. Именно это позволит вам поймать ошибку на одном из вложенных слоев и не потащить ее дальше.
Кроме того, этот валидационный лист может работать в качестве иллюстрации для промежуточных встреч с заказчиком - опять же, потому, что люди традиционно любят таблицы, вы повысите доверие к логике и отчету в целом, если каждый шаг этой логики будет явно виден. Конечно, это работает только в тех ситуациях, когда заказчик настроен на такой уровень погружения в процесс, и не падает в обморок от сотен цифр на экране.
5. Прокомментируйте расчеты прямо в полях
Мы все этим пренебрегаем в большей или меньшей степени, скорее в большей, но если вы реализуете сложный расчёт - убедитесь, что вы прокомментировали свои вычисляемые поля.
Основных причин две.
Первая - после выпуска отчета в продакшен может пройти значительное время, прежде чем вам снова понадобится внести какое-то изменение. Практика показывает, что восстановить даже свою собственную логику спустя месяцы и даже недели бывает непросто, особенно если применялись какие-то исключения или специфические модификации. Назначение расчетов, закрепленное в комментариях - это иногда еще и экономия времени при создании внешней документации
Вторая причина вытекает из первой - однажды вы будете передавать этот отчет коллеге, или сами получите отчет в наследство от другого человека. При передаче знаний вы можете столкнуться с нашей первой причиной и по ходу трансфера знаний мучительно вспоминать, что же было задумано. Если же человек получает легаси без доступа к телу разработчика - без комментариев процесс расследования займет куда больше времени. Совсем не обязательно замахиваться на лавры Толстого - будьте понятны сами себе, и всё будет хорошо. Вы помните, нас мало - пожалейте нервные клетки представителей Tableau комьюнити :)
Не стесняйтесь. Комментарии это не показатель вашей неуверенности в себе, это показатель профессионализма. К тому же, истории известны примеры приятных пасхалок и даже любовной милейшей переписки в комментариях к калькуляциям.
Еще одной малоиспользуемой (напрасно!) фичей является Comment, который можно добавить через настройки поля по умолчанию. Скажем так, путь добавления этого описания не самый быстрый - но зато вы сможете видеть комментарий, не заходя в поле. Даже если просто скопипастить туда текст, который вы уже написали внутри калькуляции - это помогает.
Итог
Теперь мы умеем делить, структурировать и раскладывать - вполне классическое определение анализа. Этот лонгрид во многом вдохновлен содержанием очень классного англоязычного поста, но я сдобрила его приличным куском отсебятины. Отвашатина, как всегда, приветствуется - буду рада, если поделитесь вашими идеями, как еще можно сделать процесс создания расчётов в Tableau и других BI тулах проще и приятнее ;)
13_beta2
Статья вроде толковая, методика в целом применима не только к табло, но и к другим системам. Но:
Калькулирование (от лат. calculatio - счёт, подсчёт) — способ определения себестоимости продукции или услуги, а также себестоимости производственных ресурсов.
Спасибо Вики за справку. Вы уверены, что именно это в заголовке имели ввиду?
NeoKamI Автор
Благодарю за комментарий! Да, не себестоимостью единой. Имеется в виду лишь один из популярных вариантов перевода понятия calculated fields. Мне чуть меньше нравится вариант "вычисляемые поля", а официального варианта, пожалуй, нет
В теме Табло статей уберечься от англицизмов вообще сложно - русификации интерфейса нет, и ко многим вещам адекватный перевод не желает подбираться