May 14

Бесит Tableau, плюсы ищут только рядовые юзеры

Сори любители tableau, но я сгорел с него. Более года с ним рука об руку сижу, за это время многому чему научился, но его логика убивает меня как человека который каждый день пишет sql запросы в бд и поддерживает софт на python.

Прошу отнестись с пониманием)))

Мой tg: @Data_Iceberg

Миф №1: "SQL и Excel не нужны, Tableau всё сделает за вас"

Это самая большая ложь, которую я слышал. Когда тебе говорят, что для работы в Tableau не нужны знания SQL или Excel, это как сказать, что для вождения машины не нужна физика. Да, на базовом уровне ты можешь перетаскивать поля и строить простенькие графики, но не забывать что данные он группирует по умолчанию и приходится тащить хоть что-то напоминающее id, в SQL такой хуйни нет. Сумма продаж по регионам? Легко. Подсчёт заказов? Без проблем. Но как только ты сталкиваешься с реальной задачей — например, рассчитать динамические проценты в зависимости от фильтра, как в моём недавнем кошмаре с производителями, — без SQL и Excel ты просто утонешь в не понимании того "а какого хуя?".

  • SQL: Без понимания группировок, джойнов и агрегаций ты не разберёшься, почему твой фильтр ломает расчёты или почему данные дублируются. Tableau работает с данными на уровне источника, и если ты не понимаешь, как там всё устроено, твои графики будут выдавать чушь. Хочешь сделать что-то сложнее, чем SUM([Sales])? Без SQL-логики ты будешь часами гуглить, почему твой {FIXED} не работает.
  • Excel: В Excel ты видишь данные и можешь пошагово разобрать формулу. В Tableau всё спрятано за красивым интерфейсом, и если ты не понимаешь, как работает порядок операций (фильтры, агрегации, Table Calculations), ты обречён. Пример: в Excel ты делаешь сводную таблицу с процентами за минуту. В Tableau тебе нужно создать расчётное поле, разобраться с TOTAL и LOD, и молиться, чтобы фильтр не сломал всё.

Боль: Мне надоело слушать, что "Tableau — это для всех" или то что "В tableau не обязательно знания sql или excel". Это для всех, кто делает тривиальные дашборды с продажами по месяцам, ну или аватары которые овладели всеми 4-мя стихиями. В реальной жизни данные грязные, требования сложные, и без SQL или хотя бы Excel ты просто не поймёшь, почему твой график показывает бред на уровне хуйни. Tableau не заменяет эти навыки — он требует их, да ещё и заставляет учить свою собственную, порой нелогичную, ОГРАНИЧЕННУЮ, логику, тут не все гибко как в python или sql, а собственный набор функций который должен как-то работать в связке с фильтрами, параметрами и расчетными полями. это пздц товарищи.

По итогу: Ок, знания SQL и Excel тебя спасут, вам не обязательно знать их на уровне "ебать какого продвинутого пользователя", а достаточно иметь опыт или осознание логики работы с бд.

Миф №2: "Синтаксис Tableau похож на Excel или SQL, всё просто!"

Ох, как же я устал от этого. Синтаксис Tableau — это не SQL, не Excel, а какой-то инопланетный язык, который притворяется простым. На базовом уровне всё выглядит знакомо: SUM([Sales]), COUNT([Orders]) — ну ок, похоже на SQL. Но как только ты пытаешься сделать что-то сложнее, начинается ад.

  • Синтаксис: Хочешь написать простое условие IF [Column] = 1 THEN [OtherColumn] ELSE 0 END? Если [Column] — мера, а [OtherColumn] — dimension, Tableau плюнет тебе в лицо ошибкой "cannot mix aggregate and non-aggregate". В SQL ты бы написал CASE WHEN, в Excel — IF, и всё работало бы. В Tableau ты должен оборачивать всё в MIN, MAX или ATTR, и это уже не синтаксис, а шаманство, а новые проекты или отчеты на поддержку тупа сломают тебя, ибо из-за этих MIN, MAX или ATTR тебе будет казаться что там РЕАЛЬНО выводить надо что то минимально или максимальное. Почему нельзя сравнить что-то так же ПРЯМО как в sql или python? а?
  • Логика: Порядок операций в Tableau — это отдельный круг ада. Фильтры применяются до агрегаций, Table Calculations — после, а LOD вообще живёт в своей параллельной вселенной. Если ты не знаешь, как это работает, твои проценты или ранги будут полной ерундой. Например, я недавно пытался сделать динамические проценты в зависимости от фильтра по производителю. В SQL это CASE WHEN и GROUP BY, в Tableau — каскад расчётных полей с {FIXED} и TOTAL, которые ещё и ломаются, если фильтр в контексте и все эти результаты должны расчитываться в зависимости от выбора в фильтре по категориям. Думай как связать фильтр с параметром, расчетными полями, добавь к этому аггрегацию, определи от чего будет зависеть выбор расчетных полей (с формулами для подсчета в зависимости от фильтра) и молись чтобы все работало правильно и успеть к дедлайну.

Боль, очко, задница: Синтаксис Tableau только кажется простым. На деле он требует выучить кучу правил, которые нигде не объяснены нормально. Документация Tableau — это просто список функций без контекста, а форумы полны вопросов "почему это не работает". И нет, это не похоже ни на SQL, ни на Excel — это свой мир, где простая логика превращается в многострочные формулы, которые ты потом сам не можешь разобрать. Написать пример того как будет работать та или иная функция в зависимоти он того КАКАЯ ЭТА ФУНКЦИЯ С ФИЛЬРАМИ, ПАРМЕТРАМИ, LOD-ами и прочие... нет.. документация шлет прямо по адресу: "тебе нахуй", или будте задротами или энтузиастами все это разобрать.

LOD: Спасение и проклятие в одном флаконе

LOD-выражения (FIXED, INCLUDE, EXCLUDE) — это то, что делает Tableau мощным, но одновременно доводит до истерики. Они позволяют задавать уровень детализации, но их поведение — это какой-то сюрреализм.

  • Игнорирование фильтров: {FIXED : SUM([Sales])} игнорирует почти все фильтры, кроме тех, что поставлены прям на Data Source. Это значит, что если ты применил фильтр по категории, твоя сумма не изменится, пока ты не добавишь фильтр в контекст. В SQL фильтры в WHERE работают сразу, а в Tableau ты должен держать в голове, что контекстные фильтры — это отдельная сущность. Забыл убрать фильтр из контекста? Поздравляю, все расчёты сломались.
  • Отладка — это кошмар: Если LOD выдаёт неправильный результат, ты должен проверить всё: уровень детализации визуализации, какие поля на полке, какие фильтры применены, есть ли NULL или как у меня учитывать All в фильтре для подсчета конверсии. Например, я пытался посчитать процент для конкретного производителя (тут используется фильтр, нужно отдельно посчитать для All и отдельно для остальных), но {FIXED [Manufacturer] : SUM([Occurrences])} не работало, потому что фильтр был не в контексте. А когда я добавил его в контекст, сломались другие расчёты. Это как хождение по канату над пропастью. Как учитывать All? Посчитать количество производителей скажите вы не, если их более 1 то использовать FIXED без [Manufacturer], а если более, то полностью " {FIXED [Manufacturer] ", но производитель может быть 1, как вам поворот? Можно заюзать параметр, и он мне РЕАЛЬНО помог, НоОоО получется надо выбрать производителя в фильтре и производителя в параметре, какой директор или руководитель примет от вас такой дашборд? Ну ок, а как их синхранизовать? Да хз, хоть параметр был создан от производителя, он не будет подхватывать то что ты выбрал в фильтре будь ты его прородителем, но нет. Самое хуевое что решение по любому есть, но это будет отдельная дрочка со всем что я выше перечислел.
  • Непредсказуемость: LOD ведут себя по-разному в зависимости от того, какие поля ты положил на Rows или Columns. Если ты добавил лишнее измерение, твой {FIXED} может внезапно начать учитывать его, и всё, что ты рассчитал, идёт коту под хвост. Клева)))

Боль, очередная: LOD — это как ядерное оружие: мощное, но если не знаешь, как использовать, взорвёшь сам себя. Я потратил часы, чтобы понять, как решить проблему которую описал выше, и да, это не SQL, где ты явно пишешь GROUP BY — это Tableau, где ты должен угадать, как оно решит интерпретировать твою формулу. Ебаный автомат с механикой, оно и что то автоматезировть и какие-то кастыли ты должен ему прописывать.

Расчётные поля и параметры: Простая логика? Создай 10 полей!

Хочешь сделать что-то простое, например, посчитать проценты в зависимости от фильтра? В SQL это один CASE WHEN или WITH, в Excel — пара формул. В Tableau? Добро пожаловать в мир расчётных полей и параметров, где каждая мелочь требует отдельного кода.

  • Расчётные поля: Чтобы проверить, выбран ли один производитель в фильтре, мне пришлось создать поле типа IF {FIXED : COUNTD([Manufacturer])} = 1 AND .... А потом ещё одно поле для процентов, ещё одно для обработки NULL, All, и так далее. В итоге у тебя десяток полей с названиями вроде -test_Cal1 или -test_Cal1111, и ты сам забываешь, что они делают.
  • Параметры: Параметры в Tableau — это статический кошмар. Хочешь, чтобы параметр автоматически обновлялся в зависимости от фильтра? Ха-ха-хи-ху-й, забудь. Я пытался синхронизировать фильтр по производителю с параметром, чтобы проценты считались правильно. В итоге пришлось писать расчётное поле, которое имитирует параметр, потому что сам параметр — это мёртвый груз, который нужно вручную переключать. А если у тебя 50 производителей? Вводи их в параметр вручную, удачи!
  • Комбинирование: Когда ты пытаешься объединить несколько расчётных полей, начинается ад с агрегациями. "Cannot mix aggregate and non-aggregate" — это как привет от Tableau каждые 10 минут. Приходится оборачивать всё в MIN, MAX, ATTR или SUM, и тебе это самому не нравиться, ведь все это просто нужна как заглушка, чтоб Tableau не выебывался, а потом сиди и объясняй, что твой SUM в SUM({FIXED: COUNT([Manufacturer])}) не делает ничего страшного, а операция происходит как в математике, считаем то что в скобках, например мы получили 100 из {FIXED:COUNT([Manufacturer]), а SUM() нужна как прокладка, чтоб не текла ошибка, и по итогу получим что нужно просуммировать 100, а это и есть 100, но не написав SUM() в контексте какой то формулы, это ошибка агрегации.

Боль, мука, проклятье: Простая задача, которая в SQL решается одной строкой, в Tableau требует каскада расчётных полей, которые ты потом боишься трогать, потому что всё рухнет. А параметры, которые должны упрощать жизнь, только добавляют головной боли, потому что они не динамические.

Переименование столбцов: Почему это так сложно?

Tableau не даёт нормально переименовать столбцы, если у них нет alias в источнике данных. Это мелочь, но она бесит до чёртиков.

  • Без alias — страдай: Если твой столбец называется col_123, а ты хочешь "Продажи", тебе нужно либо править источник данных (что часто невозможно), либо создавать расчётное поле [Sales] = [col_123]. Это лишняя работа, особенно если у тебя десятки столбцов с дебильными именами. Но шутки шутками, но реально, у вас нормально называется столбец, например id, вы перетаскиваете все нужные атрибуты для форировании какой-то общей таблицы для отчетности, но понимаете, что id не подходит, а нужен например "Уникальный идентификатор пользователя", а alies отсутствует)) вот вам и остается думать, переименновать источник и запомнить что там именно id (а в ОД там id) или нвое расчетно, ЛЮБИМОЕ, поле, нам же так нравиться пладить всякую ерунду, да tableau?) Это просто ломает мне голову как человеку которому приходится работать с 1-3НФ в бд.
  • UI-ограничения: Переименование в интерфейсе работает только для текущего листа, но в формулах ты всё равно видишь col_123. Хочешь нормальные имена в расчётах? Плоди расчётные поля, которые просто дублируют данные.

Боль, температура 37,7: Это как будто Tableau специально хочет, чтобы ты тратил время на ерунду. В Excel или SQL ты переименовал столбец и забыл, а тут — создавай поле, называй его, молись, чтобы не забыть, что оно делает. Какого хуя в tableau нельзя завести as как в SQL?

Прочие прелести Tableau: Производительность, фильтры и отладка

Tableau полон мелких и не очень мелких подстав, которые делают работу аналитика настоящим испытанием:

  • Производительность: Если у тебя миллион строк или медленный источник данных или сервер, Tableau будет грузиться так долго, что ты успеешь сходить за кофе. Экстракты помогают, но их создание и обновление — это отдельная боль.
  • Контекстные фильтры: Почему фильтр в контексте ломает половину расчётов, а без контекста — другую половину? Это как загадка, которую никто не объясняет.
  • Table Calculations: Они работают только на уровне визуализации, и если ты не знаешь, как настроить "Compute Using", твои проценты или ранги будут полной ерундой. А документация? "Выберите Compute Using и настройте." Спасибо, очень помогло, вкусно было.
  • Отладка: В Tableau нет нормального дебаггера. Если формула не работает, ты должен угадывать, где она сломалась. Ошибки типа "cannot mix aggregate and non-aggregate" — это не подсказка, а издевательство. В SQL ты видишь, где именно запрос упал, в Tableau — гадай на кофейной гуще.

Что делать?

Tableau — это не дьявол во плоти, но он требует терпения и знаний. Вот несколько советов, которые спасают мне жизнь:

  • Учи порядок операций: Пойми, как работают фильтры, LOD и Table Calculations. Это как карта в минном поле.
  • Делай подготовку в SQL: Если данные сложные, лучше обработать их в SQL, чем пытаться выкручиваться в Tableau.
  • Избегай параметров: Они хороши для статических сценариев, но для динамики используй расчётные поля.
  • Проверяй данные: NULL, дубли, неправильные типы данных — это твои враги номер один.
  • Ищи коммьюнити: Блоги вроде VizWiz, Reveal the Data, Product Analytics, настенька и графики, karpov.courses, Дашбордец и англоязычные ютуберы, особенно рекомендую этого немца Data with Baraa эти ребята иногда дают готовые решения, но готовься к тому, что половину времени ты будешь адаптировать их под свои данные, это сложно, но мы не гении.
  • ИИ решения: Используйте DeepSearch или глубокое мышление в любых ИИ, это очень сильно помогает, пробуйте использовать perplexity, а особенно Grok, это must have и просто ваши спасители, так как многие ИИ очень сильно тупят, а эти ИИ сильно выделяются на их фоне. Qwen, DeepSeek, ChatGPT тоже подойдут для не прям сильно сложных задач, Могу добавить, что модели ChatGPT: o1 и o3 хорошо себя показывают.