Перейти к основному содержимому

Кэширование часто используемых запросов EnterpriseEnterprise +

Semantic Layer позволяет кэшировать часто используемые запросы, чтобы повысить производительность и сократить вычислительные затраты на дорогие запросы.

Существует два разных типа кэширования:

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

  • Кэширование результатов происходит автоматически за счёт использования кэша вашей платформы данных.
  • Декларативное кэширование позволяет «задекларировать» конкретные запросы, которые вы хотите кэшировать. В этом случае вам нужно заранее определить, какие запросы следует кэшировать.
  • Декларативное кэширование также позволяет динамически фильтровать дашборды, не теряя преимуществ кэширования по производительности. Это возможно потому, что фильтры по измерениям (которые уже указаны в конфигурации сохранённого запроса) будут использовать кэш.

Предварительные требования​

  • Тарифы dbt Enterprise или Enterprise+.
  • Окружения dbt должны быть на release tracks, а не на устаревших версиях dbt Core.
  • Успешный запуск job’ы и настроенное production environment.
  • Для декларативного кэширования необходимо, чтобы в YAML‑конфигурации saved queries были определены exports.

Кэширование результатов​

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

Ниже показано, как работает кэширование на примере Snowflake (аналогично и для других платформ данных):

  1. Запуск из холодного кэша — Когда вы выполняете запрос к semantic layer из BI‑инструмента, который не запускался в течение последних 24 часов, запрос сканирует весь набор данных и не использует кэш.
  2. Запуск из тёплого кэша — Если вы повторно выполните тот же запрос через 1 час, SQL, сгенерированный и выполненный в Snowflake, останется тем же. В Snowflake кэш результатов задаётся на пользователя сроком на 24 часа, что позволяет повторному запросу использовать кэш и возвращать результаты быстрее.

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

Декларативное кэширование​

Декларативное кэширование позволяет предварительно прогреть кэш с помощью saved queries, установив параметр кэша в true в настройках saved_queries. Это полезно для оптимизации производительности ключевых дашбордов или часто используемых ad‑hoc запросов.

подсказка

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

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

Подробности конфигурации см. в разделе Настройка декларативного кэширования.

Как работает декларативное кэширование:

  • Убедитесь, что в YAML‑файле конфигурации saved queries определены exports.
  • Запуск сохранённого запроса инициирует работу Semantic Layer, который:
    • Создаёт кэшированную таблицу на основе сохранённого запроса с определёнными exports в вашей платформе данных.
    • Обеспечивает, чтобы любые запросы, соответствующие входным параметрам сохранённого запроса, использовали кэш и возвращали данные быстрее.
    • Автоматически инвалидирует кэш при обнаружении новых или обновлённых данных в любых вышестоящих моделях, связанных с метриками в кэшированной таблице.
    • Обновляет (или пересобирает) кэш при следующем запуске сохранённого запроса.
📹 Посмотрите это видео‑демо, чтобы увидеть, как работает декларативное кэширование!

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

Обратитесь к следующей диаграмме, которая иллюстрирует, что происходит, когда Semantic Layer получает запрос:

Обзор процесса обработки запроса с использованием декларативного кэшаОбзор процесса обработки запроса с использованием декларативного кэша

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

Чтобы заполнить кэш, необходимо настроить export в YAML‑файле конфигурации saved query и установить параметр cache config в true. Нельзя кэшировать сохранённый запрос без определённого export.

semantic_model.yml
saved_queries:
  - name: my_saved_query
    ... # Rest of the saved queries configuration.
    config:
      cache:
        enabled: true  # Set to true to enable, defaults to false.
    exports:
      - name: order_data_key_metrics
        config:
          export_as: table

Чтобы включить saved queries на уровне проекта, можно задать конфигурацию saved-queries в файле dbt_project.yml. Это позволяет сэкономить время на настройке saved queries в каждом файле:

dbt_project.yml
saved-queries:
  my_saved_query:
    config:
      +cache:
        enabled: true

Запуск декларативного кэша​

После настройки декларативного кэширования в YAML‑конфигурации вы можете запускать exports с помощью планировщика job’ов dbt, чтобы создать кэшированную таблицу из сохранённого запроса в вашей платформе данных.

  • Используйте exports для настройки job’ы, чтобы запускать сохранённый запрос в dbt.
  • dbt Semantic Layer создаёт таблицу кэша в вашей платформе данных в выделенной схеме dbt_sl_cache.
  • Схема и таблицы кэша создаются с использованием ваших deployment‑учётных данных. Необходимо предоставить доступ на чтение к этой схеме для пользователя Semantic Layer.
  • Кэш обновляется (или пересобирается) по тому же расписанию, что и job’а сохранённого запроса.
Обзор процесса создания кэша.Обзор процесса создания кэша.

После успешного выполнения job’ы вы можете вернуться к своему дашборду и оценить скорость и преимущества декларативного кэширования.

Управление кэшем​

dbt использует метаданные из запусков dbt‑моделей для интеллектуального управления инвалидированием кэша. При запуске dbt‑job’ы система отслеживает время последнего выполнения моделей и проверяет свежесть метрик, находящихся выше по цепочке относительно вашего кэша.

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

Вы также можете вручную инвалидировать кэш через API dbt Semantic Layer, используя поле InvalidateCacheResult.

Часто задаваемые вопросы​

 Как кэширование взаимодействует с контролем доступа?

Нашли ошибку?

0
Loading