Кэширование моделей

Примечание

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

Glarus BI может сохранять результаты ваших моделей в виде таблиц БД, чтобы модели (и запросы, основанные на этих моделях) загружались быстрее.

Вы можете использовать сохранённые результаты модели (в виде таблицы БД) для создания новых запросов, получая лучшую производительность и удобство за счёт хранения результатов в одной широкой таблице. Расширенный механизм кэширования позволяет копировать данные из различных СУБД в целевую ClickHouse, более приспособленную для больших данных.

Кэширование моделей включается и настраивается администратором системы. Общее расписание настраивает администратор. Ручное обновление выбранной модели требует права управления соответствующей БД; одного чтения данных и доступа к коллекции недостаточно.

На практике:

• пользователь создаёт запрос;
• сохраняет запрос в доступную коллекцию;
• преобразует запрос в модель;
• возможно, дополнительно настраивает представление полей (метаданные модели);
• срабатывает механизм кэширования: по расписанию или в результате ручного запуска;
• в целевой БД (и соответственно, в интерфейсе Glarus BI, если БД подключена) появляется новая таблица с данными модели;
• при стандартном кэшировании подходящий запрос к модели может использовать сохранённую таблицу в исходной БД. Расширенное кэширование создаёт отдельную таблицу в ClickHouse: запрос к самой модели автоматически в эту таблицу не перенаправляется. Для работы с расширенным кэшем выберите соответствующую таблицу ClickHouse как источник нового запроса.

В системе есть два различных механизма кэширования моделей:

1. Стандартный — сохраняет таблицу модели в тот же экземпляр сервера БД, где находятся данные, на основе которых она создана:

   • работает в рамках одной СУБД. Не позволяет копировать данные между СУБД;
   • доступен для PostgreSQL, GreenPlum, ClickHouse, MySQL и Redshift;
   • целевое хранилище не настраивается — всегда используется то же подключение;
   • таблица сохраняется в новую схему или БД (в зависимости от возможностей СУБД), но не выходит за пределы сервера БД;
   • БД или схема именуется как metabase_cache_хэш_число;
   • таблицы используют фрагмент названия модели в системе (после транслитерации в латиницу);
   • запрещается строить запросы к таблицам metabase_cache_* напрямую — вместо этого вы можете выбрать модель в запросе.

2. Расширенный (рекомендуется) — сохранение в выбранную администратором БД под управлением ClickHouse:

   • источник данных — СУБД, поддерживающая драйвер JDBC (PostgreSQL, ClickHouse, MySQL, MariaDB, SQL Server, Oracle и т.д.);
   • целевое хранилище — только СУБД ClickHouse, одно целевое подключение используется для одного или нескольких источников;
   • сохраняет модели в виде таблиц рядом с другими данными витрины;
   • вы можете узнать такие таблицы по ID модели в круглых скобках в конце названия таблицы. В названии также содержится фрагмент названия модели (после транслитерации в латиницу). ID модели вы можете найти в URL страницы, просматривая модель;
   • допускается построение запросов напрямую к соответствующим таблицам моделей;
   • поддерживается репликация в ClickHouse;
   • SQL Server может выступать источником через JDBC-драйвер; целевым хранилищем расширенного кэша остаётся ClickHouse. Наличие драйвера не заменяет проверку типов и доступов конкретного подключения.

Подсказка

Мы рекомендуем использовать расширенный механизм кэширования моделей, когда это возможно. Он даёт больше преимуществ.

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

Независимо от выбранного механизма, вам или другому администратору системы потребуется включить кэширование для:

1. Экземпляра системы.
2. Определённых баз данных.

Смешанный режим: кэшированные модели и живые таблицы

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

Механизм	Что выбрать в запросе	С чем соединять
Стандартный	Выберите модель. Если её кэш готов и соответствует определению модели, конструктор прозрачно использует таблицу в схеме metabase_cache_* исходной БД.	С живой таблицей через то же подключение к БД.
Расширенный	Выберите физическую таблицу кэша в целевом ClickHouse или укажите её в SQL. Название содержит название и идентификатор модели.	С живой таблицей в том же подключении ClickHouse, например оперативной таблицей витрины.

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

Для расширенного механизма сначала настройте ClickHouse как хранилище кэша и дождитесь заполнения таблицы. Затем начните новый запрос с подключения ClickHouse, выберите таблицу кэша и добавьте живую таблицу этого же подключения; тот же JOIN можно написать в SQL. Запрос к самой исходной модели автоматически в ClickHouse не перенаправляется.

Один запрос работает в рамках одного подключения к БД. Нельзя непосредственно соединить кэш в ClickHouse с живой таблицей PostgreSQL или другой СУБД. Конструктор предлагает левое, правое, внутреннее и полное соединения в зависимости от поддержки выбранного подключения; наличие кэша не добавляет СУБД новые типы JOIN.

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

Предварительное заполнение (прогрев) кэша

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

1. Администратор включает кэширование в разделе Управление → Производительность → Персистентность моделей и выбирает интервал либо Произвольный… cron. Расписание общее для экземпляра и применяется к подключениям с включённым кэшированием. Например, каждые 15 минут: 0 0/15 * * * ? *.
2. В настройках подключения включите нужный механизм. Для стандартного нужны права учётной записи БД на схему кэша; для расширенного сначала выберите целевое хранилище ClickHouse, затем включите кэширование источника.
3. В информационном блоке модели исключите ненужные объекты переключателем Отключить кеширование для этой модели (отказ от кэширования, также называемый «Не кешировать»). Такая модель не обновляется ни плановым, ни ручным заданием, пока переключатель включён.
4. При необходимости задайте Приоритет обновления: большее значение обрабатывается раньше в цикле одного подключения; при равном значении порядок определяется идентификатором модели. Эта настройка не задаёт общее расписание и не создаёт зависимость между разными БД.
5. Дождитесь завершения задания и проверьте состояние и время последнего обновления в информационном блоке модели либо в Управление → Инструменты.

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

Ошибка обновления фиксируется в состоянии модели и передаётся механизму email-уведомлений. Администратор настраивает получателей; отправка требует настроенного почтового канала. До устранения ошибки не считайте прогрев завершённым.

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

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

Включение кэширования моделей для всего экземпляра Glarus BI

Чтобы включить кэширование моделей в вашем экземпляре Glarus BI, перейдите в Управление > Производительность > Персистентность моделей.

Вы можете настроить периодичность обновления моделей: каждый час, 2 часа и т.д. или выбрать опцию Произвольный…, чтобы использовать синтаксис cron (англ.) для указания собственного расписания.

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

Вы можете приблизить цикл кэширования для быстрого получения результата, затем снизить частоту запуска. Пример cron-выражения для кэширования моделей каждые 15 минут: 0 0/15 * * * ? *.

Планировщик cron использует часовой пояс отчёта, если он выбран. В противном случае планировщик будет использовать системный часовой пояс сервера приложений.

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

Если пользователь изменяет определение запроса модели, то изменения попадают в кэш не сразу, так как кэширование работает по расписанию или запускается вручную. Поэтому в отрезок времени до следующего кэширования:

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

В следующем цикле кэширования таблица модели обновится, и различие исчезнет.

Подсказка

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

Включение кэширования моделей в настройках подключений к БД

После того как вы включили кэширование моделей для экземпляра Glarus BI, вам нужно настроить его для используемых вашими пользователями подключений — в разделе "Базы данных". Далее действия зависят от выбранного вами механизма кэширования моделей.

Включение расширенного кэширования моделей

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

1. Перейдите в Управление > Базы данных > [целевая база данных].
2. Нажмите Включить расширенное кэширование моделей в эту БД. Сохранять настройки подключения не нужно, изменения применятся сразу.

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

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

1. Перейдите в Управление > Базы данных > [источник данных].
2. Нажмите Включить расширенное кэширование из этой БД.

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

Включение стандартного кэширования моделей

Предупреждение

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

Для включения стандартного кэширования:

1. Найдите подключение к БД, где хранятся модели пользователей: Управление > Базы данных > [ваша база данных].
2. Нажмите "Включить стандартное кэширование моделей".

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

• получите название схемы: щёлкните на значок информации, изучите подсказку. Название содержится в подсказке;
• вручную создайте схему в вашей базе данных. Например, если вы используете PostgreSQL в качестве хранилища данных, вы можете создать схему, запустив CREATE SCHEMA IF NOT EXISTS schema_name, где schema_name — это название схемы, которое Glarus BI показал вам в значке информации;
• убедитесь, что учётные данные, которые Glarus BI использует для подключения к вашему хранилищу данных, могут управлять этой схемой и записывать в неё.

Если кнопка отсутствует:

• убедитесь, что не забыли включить кэширование для экземпляра Glarus BI и настроить расписание;
• проверьте права управления подключением и права учётной записи БД на схему кэша. Расширенный режим настраивается отдельно и не запрещает включение стандартного;

Проверка результата

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

Подсказка

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

Просмотрите журнал сохранения модели. Нажав на значок шестерёнка в правом верхнем углу, выберите Управление > Инструменты и найдите результат кэширования по названию модели.

Журнал обновления должен быть доступен в Решение проблем > Журналы. См. Инструменты администратора или в журналах сервера приложений (контейнера). Ищите по тексту «metabase.task.persist-refresh».

В разделе «Базы данных» вы можете найти БД и новую таблицу кэша модели.

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

Запуск кэширования моделей вручную

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

Для запуска кэширования выбранной модели администратору следует:

1. Открыть Управление > Инструменты.
2. Найти в списке искомую модель.
3. Справа нажать кнопку обновления кэша модели.

Если подраздела Инструменты нет в интерфейсе, используйте комбинацию CTRL + Shift + R для обновления страницы с её перезагрузкой в кэше браузера. Если подраздела нет и после перезагрузки страницы, проверьте настройки модели, расписание и настройки подключения к БД: когда кэширование недонастроено, подраздел Инструменты скрыт. Нужно исправить настройки кэширования.

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

Для запуска кэширования выбранной модели пользователю требуется:

1. Открыть Обзор > Модели.
2. Найти в списке искомую модель.
3. Нажать кнопку i для открытия информационного блока модели.
4. Справа в информационном блоке найти и нажать кнопку запуска кэширования.

Настройка приоритета кэширования моделей

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

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

Для изменения приоритета кэширования моделей:

1. Откройте Обзор > Модели.
2. Найдите в списке искомую модель.
3. Нажмите кнопку i для открытия информационного блока модели.
4. Справа в информационном блоке найдите поле ввода приоритета (Кэширование > Приоритет), измените значение. — Произойдёт автоматическое сохранение.

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

Настройка получателей уведомлений об ошибках обновления моделей

Если плановое или ручное обновление кэша персистентной модели завершается ошибкой, Glarus BI отправляет email-уведомление. По умолчанию такое уведомление уходит всем администраторам экземпляра.

Чтобы ограничить круг получателей конкретным подмножеством суперпользователей:

1. Откройте Управление → Настройки → Уведомления.
2. Найдите секцию уведомлений об ошибках обновления моделей (расположена рядом с остальными настройками уведомлений).
3. Выберите нужных суперпользователей из списка получателей.

Если ни один получатель не выбран, уведомления, как и раньше, уходят всем администраторам — поведение по умолчанию не меняется.

Отключение кэширования для отдельной модели

Помимо общесистемной настройки, кэширование можно отключить точечно, для одной конкретной модели — независимо от значения общей настройки уровня БД persist-models-enabled. Это полезно для моделей, которые сами являются финальной точкой запросов (например, широких моделей с сотнями полей и миллионами строк) и не нуждаются в дополнительном слое кэширования.

Чтобы отключить кэширование для одной модели:

1. Откройте Обзор > Модели.
2. Найдите в списке искомую модель.
3. Нажмите кнопку i для открытия информационного блока модели.
4. Справа в информационном блоке включите переключатель Отключить кеширование для этой модели.

При включении переключателя модель полностью исключается как из планового обновления кэша по расписанию, так и из ручного запуска обновления (persist-refresh) — до тех пор, пока переключатель не будет выключен обратно.

Отключение кэширования моделей

Отключение кэширования моделей производится в обратном включению порядке.

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

• отключите кэширование в источниках данных — в настройках подключений нажмите Отключить расширенное кэширование из этой БД;
• отключите хранилище кэша в настройках целевой БД.

Если вы используете стандартный механизм кэширования — нажмите Отключить стандартное кэширование моделей.

Затем отключите кэширование для экземпляра в Управление > Производительность > Персистентность моделей.

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

Общее отключение в Управление > Производительность > Персистентность моделей снимает настройки кэширования в подключениях и планирует удаление таблиц стандартного кэша. После повторного включения потребуется снова включить нужные механизмы в подключениях; это не временная пауза с сохранением всех настроек.

Перенос метаданных при кэшировании и влияние на данные

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

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

При записи в ClickHouse даты из Greenplum с типом timestamp, превышающей максимально допустимое значение (2106-й год и выше), значения будут преобразованы в 2100-01-01, тип datetime.

Особенности кэширования данных из Greenplum в ClickHouse

Предупреждение

Осторожнее с кэшированием из Greenplum!

СУБД Greenplum не гарантирует порядок следования записей при многократном выполнении запроса без явной сортировки. Во первых, это особенность данной СУБД, она хранит данные на множестве сегментов, каждый из которых обрабатывает свою часть запроса. Во-вторых, механизм кэширования Glarus BI с целью оптимизации разбивает массив данных на страницы и запрашивает каждую страницу отдельно. Поэтому при записи модели в таблицу ClickHouse могут наблюдаться дублирования строк, проблемы сортировки, отсутствие записей, расхождения итогов.

Чтобы обойти эту особенность и избежать проблем, всегда явно указывайте сортировку в запросе (ORDER BY) по уникальному ключу. В более сложных запросах с подзапросами на большом объёме данных используйте ORDER BY по уникальному ключу на каждом уровне иерархии запроса.

Сводное описание писем при сбое ручного и планового обновления кэша и выбора получателей: «Оповещения администраторов».