Проектирование масштабируемых вычислений

  • 7 мин

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

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

Группы расчета

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

Проблема, которую решают группы вычислений

Рассмотрим организацию с 50 базовыми мерами (например, Общая выручка, Общая стоимость, Прибыль и Продажи единиц). Для каждой меры требуются расчеты с начала года, начала квартала и начала месяца. Без групп вычислений это 50 × 3 = 150 дополнительных показателей. Добавьте сравнения с предыдущим годом, и вам придется учесть более 250 показателей для отслеживания.

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

Как работают группы вычислений

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

// Year-to-Date
CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD('Date'[Date])
)

// Quarter-to-Date
CALCULATE(
    SELECTEDMEASURE(),
    DATESQTD('Date'[Date])
)

// Month-to-Date
CALCULATE(
    SELECTEDMEASURE(),
    DATESMTD('Date'[Date])
)

Когда пользователь добавляет группу расчетов в визуальный элемент, он может переключаться между YTD, QTD и MTD для любой метрики (например, Total Sales, Profit или Units Sold) без отдельных метрик для каждой комбинации.

Строки динамического формата

Строки динамического формата изменяют формат отображения на основе контекста элемента вычисления. Например, процентные вычисления должны отображаться в процентах, а валютные вычисления — как валюта, даже если они применяются к той же базовой мере.

// In the format string expression for a YoY % calculation item:
"0.0%"

Строки динамического формата снижают потребность в отдельных отформатированных мерах и сохраняют согласованность форматирования в модели.

Подсказка

Дополнительные сведения о том, как создать группы вычислений в Power BI.

Когда следует использовать группы вычислений

Используйте группы вычислений, если у вас есть три или более мер, которые нуждаются в одном и том же шаблоне вычисления. Распространенные варианты использования включают аналитику времени (YTD, QTD, MTD), преобразование валют и расчеты отклонений (фактические данные и бюджет).

Дисциплина удобочитаемости DAX

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

Переменные

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

Profit Margin =
VAR TotalRevenue = SUM(Sales[Revenue])
VAR TotalCost = SUM(Sales[Cost])
VAR ProfitAmount = TotalRevenue - TotalCost
RETURN
    DIVIDE(ProfitAmount, TotalRevenue)

Без переменных одно и то же SUM(Sales[Revenue]) выражение может повторяться три раза в сложной мере. Переменные оценивают выражение один раз и повторно используют результат.

Подсказка

Дополнительные сведения об использовании переменных для улучшения формул DAX.

Соглашения об именах

Согласованное именование имеет решающее значение, если модель имеет сотни мер, поддерживаемых несколькими людьми. Устанавливать конвенции для:

  • Имена мер: используйте четкие, описательные имена, такие как "Total Sales" или "YoY Revenue Growth". Избегайте аббревиаций, которые понимает только исходный автор.
  • Имена переменных: используйте описательные имена, которые объясняют промежуточное значение (напримерTotalRevenue, а неx).temp
  • Элементы группы вычислений: имя элементов по тому, что они делают, а не как они работают (например, "Дата—дата", а не "Оболочка DATEYTD").

Описательное именование также имеет значение для использования ИИ. Когда Copilot или агент данных запрашивает вашу модель, он использует названия показателей и описания, чтобы определить, какие вычисления включить. Мера с именем YoY Revenue Growth дает лучшие результаты ИИ, чем "Calc7_v2".

Подсказка

Copilot в Power BI поможет писать и объяснять формулы DAX. При работе с сложными мерами используйте Copilot, чтобы предложить улучшения или объяснить существующую логику.

Итераторы и агрегатные функции

Функции итератора (SUMX, AVERAGEX, MAXX) вычисляют выражение по строкам в таблице. Функции агрегирования (SUM, , AVERAGEMAX) работают с одним столбцом. При больших объемах данных выбор имеет значение:

  • Используйте функции агрегирования при обобщении одного столбца. Они быстрее, так как подсистема может использовать предварительно созданные структуры данных.
  • Итераторы используются, если вычисление требует выражения уровня строки (например, Quantity × UnitPrice для каждой строки).

Замечание

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

Информационные функции для оборонительных шаблонов

Такие информационные функции, как ISBLANK, HASONEVALUE и ISINSCOPE создают оборонительные шаблоны для мер, используемых несколькими отчетами с различными контекстами фильтров:

Sales per Customer =
IF(
    HASONEVALUE(Customer[CustomerID]),
    DIVIDE(SUM(Sales[Amount]), 1),
    DIVIDE(SUM(Sales[Amount]), DISTINCTCOUNT(Sales[CustomerID]))
)

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

Aggregations

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

Агрегации как проектное решение

Решение о добавлении агрегатов и о том, какая степень детализации является решением по проектированию. Мониторинг производительности и настройка являются отдельными операционными проблемами, но вы делаете структурный выбор во время проектирования модели.

Учитывайте агрегации, когда:

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

Как поведение агрегирования отличается от режима хранения

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

В режиме Direct Lake таблицы Delta могут служить источниками агрегирования. Так как Direct Lake считывает файлы columnar Parquet, подсистема может обрабатывать большие объемы данных без агрегирования во многих сценариях. Добавляйте агрегаты только в том случае, если шаблоны запросов подтверждают необходимость.

Подсказка

Дополнительные сведения о агрегатах, определяемых пользователем, в Power BI.