Существует немало постов о том, как вообще коннектиться к этой базе, а сама команда Tableau опубликовала словарь данных целую вечность назад. Версии книг для редактирования можно найти в комьюнити (тык 1), (тык 2), а достать с сервера - вот так и так.

Какое-то время назад нам пришлось справляться с довольно распространенной проблемой - экстракты буквально толпились на сервере по утрам, и иногда данные не успевали подъехать в девайсы к стейкхолдерам к утреннему кофе. Даже без специального анализа было очевидно, что искать корень зла нужно в расписаниях, но совершенно не хотелось двигать отчеты наугад, а потому появилась идея посмотреть на несколько довольно тривиальных вещей в комплексе - время ожидания в очереди, время обновления, а также востребованность отчета. В тот момент у нас не было мгновенной возможности добавить ресурсов. Опытные знают, что существует встроенный отчет Background Tasks for Extracts, который минимально достаточен для того, чтобы составить первое впечатление об узких местах серверных процессов. Однако он строится от задач (jobs), и если мы хотим связать производительность каждого таска обновления с рабочей книгой или источником данных, в котором возникала задержка, а затем с проектом, в котором он находился - мы удивимся в первый раз.

Почему бы не присоединить таблицу background_jobs к таблице с книгами или источниками? Ведь наверняка эти сущности связаны между собой, и должен быть какой-то ID. Однако табличка с background_jobs не содержит ни workbook_id, ни datasource_id, как другие таблицы в схеме workgroup.

Как быть? Можно попробовать привязаться к названию отчета - есть поле Title, но это не уникально. Что произойдет, если у вас есть книга в двух разных проектах с одинаковым именем? Следить за принципиальной уникальностью имен довольно сложно, да и в конце концов, это не по фен-шую Tableau Server должен иметь возможность установить эту связь, ведь так?

Совершенно ясно, что ответ должен быть в таблице background_jobs, и ответ действительно обнаруживается там - в поле «args». Для таска «Extract refresh» значение «args» выглядит примерно так: как на картинке справа.

Оказывается, значение после «Workbook» — это workbook_id, которое нам поможет воссоединиться с workbooks. Для следующего шага нам потребуется немного регулярных выражений. Используя следующую конструкцию, мы можем преобразовать строку «args» в object_id:

cast(split_part(
(regexp_replace(args,'---','')),'- ',3
) as integer) as object_id

Таким образом, мы убираем дефисы и формируем число, которое можно связывать с workbooks.id в соответствующей самостоятельной таблице

Для решения моей задачи подошел такой кусок

select *,
subtitle as obj_type,
cast(split_part(
(regexp_replace(args, '---', '')), '- ', 3
) as integer) as object_id
from background_jobs
where job_name in ('Refresh Extracts', 'Increment Extracts')

Успех! Теперь можно построить вот такое соединение, или написать код для представления в вашей БД. А также проложить себе путь к дальнейшему исследованию Postgres'а имени Табло сервера.

Object_id позволяет нам привязаться к id.worbooks, id.datasources и так далее - и получить больше полезной информации для наших дашбордов.

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

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

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

Следующим этапом было определение правильного порядка - здесь я смотрела на время, к которому нужны данные в дашборде (и какой свежести) - и расставляла менее важные отчеты по менее загруженными расписаниям. Внутри расписания за порядок запуска отвечает приоритет, так что самые быстрые по времени реального обновления экстракты получали более высокий приоритет, чтобы обновиться в начале пути и не блочить остальных, Кроме прочего, если у вас есть published data sources - важно найти оптимальное место и для них тоже. Ну, или просто насыпать много ресурсов серверу :)

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

Без сомнения, решение задачи оптимизации - штука комплексная. И одной перетасовки могло быть недостаточно - например, если сразу после ты ловишь баг Табло с необновляющимися published data sources - и падает вообще все. Но это тоже уже другая история :)

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