Расчет недельных продаж с помощью DAX в LuckyTemplates
В этом руководстве показано, как в конечном итоге можно рассчитать разницу между еженедельными результатами продаж с помощью DAX в LuckyTemplates.
Измерение в LuckyTemplates: советы и методы оптимизации
В этом руководстве вы узнаете, как оптимизировать меру в LuckyTemplates. Оптимизация мер в вашем отчете повышает производительность ваших кодов в получении ценных идей и данных. Вы также узнаете о различных методах оценки и о том, как их применять для оптимизации отчета. Вы можете посмотреть полное видео этого урока в нижней части этого блога.
Оглавление
- 1. Анализ производительности кода
- 2. Анализ меры в LuckyTemplates
- 3. Используйте методы оценки кода
- 4. Оптимизируйте показатель в LuckyTemplates
- 5. Оптимизируйте другие показатели в LuckyTemplates
- Заключение
1. Анализ производительности кода
В этом примере вам нужно оптимизировать этот отчет:
Это модель данных, которую вы собираетесь использовать:
Таблица «Работы» содержит всю информацию о любой работе, выполненной за определенный период времени.
Эта таблица является основой всех мер, которые вы собираетесь оптимизировать:
Во-первых, вам нужно проверить производительность отчета.
Перейдите на вкладку «Вид» и выберите «Анализатор производительности» . Затем нажмите «Начать запись и обновить изображения» . Подождите, пока анализатор отобразит изображение.
После этого откройте список Incentive Breakdown и нажмите Copy Query .
Затем выберите «Внешние инструменты» , чтобы перейти в DAX Studio и просмотреть код, сгенерированный LuckyTemplates.
Затем вставьте скопированный запрос в рабочую область.
Переменные в мере
Первая переменная — DateClosed , которая представляет собой слайсер на панели инструментов. Он использует столбец из таблицы фактов для получения значений определенных периодов в слайсере.
Следующая переменная — JobLost , которая проверяет наличие ложных или пустых данных о потерянных заданиях.
Последняя переменная — MatrixVisual . Это сердце кода. Он показывает итоговый столбец, созданный LuckyTemplates для заполнения визуальных элементов матрицы. Он группирует тип потери работы в этой матрице и внедряет фильтры, поступающие от слайсеров. Затем он добавляет расширенные столбцы.
Как только столбец сводки завершит выполнение, вы увидите результаты на панели под кодом.
LuckyTemplates использует результат для заполнения визуальных элементов матрицы.
Холодный кэш для DAX Studio
Затем вам нужно проверить время, затраченное на выполнение всего кода. Для этого включите Server Timings и затем выберите Clear Cache Then Run .
Когда вы пытаетесь оптимизировать меру в LuckyTemplates с помощью DAX Studio , лучше работать в сценарии с холодным кэшем, чтобы получить правильное время. После этого нажмите F5 и дождитесь завершения операции во вкладке Server Timings .
Как только он завершится, вы увидите, что общее время выполнения составляет 3,6 секунды. Он провел большую часть времени в подсистеме формул и провел 57 миллисекунд в подсистеме хранения.
Вы также можете видеть, что было найдено 383 запроса к подсистеме хранения. Из всех этих запросов 327 приводятся в память, чтобы их можно было использовать повторно.
2. Анализ меры в LuckyTemplates
Далее вам нужно оптимизировать эти 3 одинаковых показателя.
Вы должны извлечь эти меры в другой файл и подключить его к используемой модели данных.
После этого запустите Server Timings, чтобы увидеть время, затрачиваемое тремя показателями при заполнении визуальных элементов.
Результаты выполнения показывают, что измерениям требуется 1,85 секунды для получения результата.
Результат показывает таблицу, состоящую из 10 строк и 3 расширенных столбцов, которые относятся к суммированным столбцам.
Столбец «Тип убытка» содержит 10 уникальных значений, которые код вычисляет для получения процентов поощрения.
Время, затрачиваемое на код, экспоненциально велико. Вот где и когда вам нужно их оптимизировать.
Показатель RB Incentive% в LuckyTemplates
Это показатель RB Incentive% в LuckyTemplates. Это одна из трех основных мер, используемых в этом примере.
Вы можете видеть, что он пытается рассчитать процент поощрения.
У него есть переменная JobType, которая извлекает значение Lost Type в текущем контексте фильтра. Он также проверяет, отображается ли в текущем контексте фильтра только одно значение. Вам нужно использовать функцию , чтобы каждый раз, когда условие выполняется, оно давало соответствующий результат.
Этот код меры создает много смазки для двигателя хранения, что увеличивает время в общей продолжительности кода.
Теперь вернитесь в DAX Studio, чтобы проверить количество запросов к подсистеме хранения, создаваемых мерой.
Вы можете видеть, что для выполнения потребовалось 600 миллисекунд и 43 запроса механизма хранения, чтобы просто получить данные для 10 строк.
Данные из механизма хранения
Теперь проверьте данные, которые запрашиваются у механизма хранения. В первом запросе есть тип потери работы и значение DCUNT для типа потери работы.
В следующем запросе есть дата закрытия заданий, полученная из среза в отчете.
В третьем коде вы увидите другой тип потери работы с идентификатором данных обратного вызова.
В другой строке вы увидите наиболее важные строки кода.
Первое, что вы видите, — это полученных платежей, выставленных счетов и фактических расходов.
Далее следует функция WHERE , в которой указывается условие и соответствующий ему результат. Результат зависит от выбора слайсера и оператора switch в показателе RB Incentive%.
Вы также заметите, что код в строках 12 и 14 одинаков.
Если пролистать вправо, то можно увидеть, что есть строки с одинаковыми запросами. Запросы в строках направляются оператором switch в показателе RB Incentive%.
Если вы вернетесь к показателю RB Incentive% в LuckyTemplates, вы увидите, сколько раз повторяется запрос и как это отражается в запросах механизма хранения.
Логика IF и Switch
Теперь, чтобы понять, почему запросы выполняются несколько раз, вам нужно понять логику функций и ПЕРЕКЛЮЧЕНИЯ .
Вам нужно выполнить их отдельно в плане запроса. Но перед этим обязательно подключитесь к базе данных и включите план запросов.
Выполните оператор SWITCH в плане запроса. Затем выделите оператор и нажмите клавишу ввода.
Это создаст логический план запроса с различными операциями.
Затем выполните оператор IF , выделив оператор и нажав клавишу ввода.
Вы можете видеть, что он генерирует тот же план логического запроса.
Это связано с тем, что всякий раз, когда вы используете функцию SWITCH , движок внутренне преобразует эту функцию в оператор IF . Но оператор SWITCH рекомендуется, поскольку он повышает читабельность вашего кода.
После этого вам нужно понять, как код выполняется внутри функции ЕСЛИ или ПЕРЕКЛЮЧАТЕЛЯ .
Это пример кода, внутри которого есть инструкция SWITCH .
Он имеет показатели валовой прибыли, общей оценки и общей суммы счетов-фактур, которые представляют собой СУММУ различных столбцов. Он также имеет функцию над типа потери работы, а также оператор SWITCH и TRUE .
Когда вы выполните этот код, вы увидите логику функций.
Первый запрос получает отдельный тип потери рабочих мест из таблицы рабочих мест.
Помимо типа потери рабочих мест, он также получает сумму оценки рабочих мест.
Внутри условия WHERE вы также можете увидеть значения, существующие в столбце «Тип потери рабочих мест».
3. Используйте методы оценки кода
В DAX существует 3 метода оценки кодов:
- Строгая оценка
- Нетерпеливая оценка
- IF.Eager Оценка
Эти методы помогут вам оптимизировать код или измерить в LuckyTemplates.
1-й метод: строгая оценка
В приведенном ниже примере используется метод строгой оценки.
Логика этого заключается в том, что если контекст типа потери рабочих мест равен A, он обеспечит валовую прибыль. В противном случае он дает общую оценку. Код делает это для каждой строки в типе потери рабочих мест.
Это еще один пример меры в LuckyTemplates, в которой используется строгая оценка.
Когда вы выполняете этот код, он сгенерирует 5 запросов механизма хранения.
При строгой оценке код предоставляет общую оценку, если валовая прибыль, умноженная на 1,4, превышает среднюю оценку. В противном случае это даст валовую прибыль.
Использование Strict Evaluation создает больше запросов к подсистеме хранения, поскольку оператор IF многократно проверяет конкуренцию валовой прибыли и в конечном итоге снижает производительность всей операции.
2-й метод: нетерпеливая оценка
Это тот же код, что и в предыдущем примере.
Но вместо того, чтобы вычислять меры внутри оператора IF , он вычислял все в перед RETURN .
Это означает, что перед проверкой отчетов он получает все значения валовой прибыли и общей оценки для всех типов потерь рабочих мест.
Когда вы выполняете этот код, количество механизмов хранения уменьшается до 3.
Это повышает производительность всей операции.
В первом запросе операции он получает тип потери рабочих мест и сумму оценки рабочих мест и валовой прибыли.
Следующий запрос получает сумму оценки рабочих мест из стабильной работы. Это используется при расчете средней оценки.
Последний запрос дает отдельный тип потери рабочих мест для значений, записанных в ADDCOLUMNS .
Использование Eager Evaluation позволяет получить все в одном кэше данных. Данные также оцениваются и повторяются в обработчике формул. Оператор IF вернет либо общую оценку, либо валовую прибыль в зависимости от истинности или ложности оценки.
Eager Evaluation — не всегда лучший метод оптимизации кода. Строгая оценка приведет к лучшей производительности, если у вас есть сложные коды. Все зависит от функций, которые вы используете внутри кода DAX.
Недостатком Eager Evaluation является то, что если вы создаете значения перед оператором IF или SWITCH и используете эти переменные внутри оператора, который никогда не должен выполняться, движок все равно будет вычислять эти переменные.
Недостатки нетерпеливой оценки
Вот пример минуса:
В идеале, если тип потери рабочих мест равен A, он должен получить валовую прибыль. В противном случае он получает общую оценку.
Поскольку в столбце «Тип потери работы» нет значения, равного A, он всегда должен иметь значение «Общая оценка». Тем не менее, он по-прежнему обеспечивает валовую прибыль в кэше данных.
Если вы посмотрите на первый запрос, он получит тип потери рабочих мест и сумму валовой прибыли и оценки рабочих мест.
В следующем запросе он получает отдельный тип потери рабочих мест из таблицы рабочих мест.
3-й метод: оценка IF.EAGER
Следующий метод — это оценка функции ЕСЛИ.EAGER , которая повторяет поведение Eager Evaluation.
Он позволяет вам написать код, представляющий строгую оценку, и выполнить его с нетерпеливой оценкой.
Если вы посмотрите на этот пример кода, он точно такой же, как код Strict Evaluation. Единственное отличие состоит в том, что здесь используется функция IF.EAGER вместо IF .
Перед выполнением кода обязательно подключитесь к модели LuckyTemplates и включите синхронизацию сервера. После этого нажмите F5.
Вы можете видеть, что он сгенерировал 3 запроса механизма хранения.
Первый запрос получает тип потери рабочих мест и сумму оценки рабочих мест и валовой прибыли.
Второй запрос получает сумму оценки рабочих мест.
Последний запрос получает отдельный тип потери рабочих мест из таблицы рабочих мест.
Вы заметите, что он ведет себя так же, как Eager Evaluation.
Резюме методов оценки
Пытаясь повысить производительность ваших вычислений, вы должны помнить следующее:
- Строгая оценка используется для сложных кодов. Это также применимо, когда вы не хотите оценивать все значения, предоставленные таблицей.
- Eager Evaluation лучше использовать, если ваши коды просты.
- Используйте IF.EAGER, если вы хотите писать коды, используя Strict Evaluation, и выполнять их с помощью Eager Evaluation.
Но обратите внимание, что вам нужно протестировать эти три метода, чтобы выяснить, какой из них действительно лучше всего использовать в вашем отчете.
4. Оптимизируйте показатель в LuckyTemplates
Основной урок в этом руководстве — оптимизация ваших кодов.
Вернитесь назад и посмотрите на меру RB Incentive% , которая выполняется с использованием строгой оценки. Затем попробуйте оценить его с помощью Eager Evaluation.
Начните с создания переменных и ввода функции RETURN .
Измените ссылки на меры с помощью переменных.
После этого подтвердите меру и перейдите в DAX Studio, чтобы узнать, улучшилась ли производительность.
Он показывает, что общее время составляет 642 миллисекунды, а общее количество запросов к подсистеме хранения сократилось до 39.
Теперь создайте переменные для всех данных и измените все ссылки на меры на соответствующие им переменные.
Затем подтвердите меру и выполните код в студии DAX.
Общее время выполнения и общее количество запросов механизма хранения были сокращены с 600 миллисекунд до 170 миллисекунд и с 43 запросов до 15 запросов соответственно.
Вы также можете видеть, что дубликатов нет. Наличие переменных в вашем коде улучшает его читабельность и производительность.
Расширенная оптимизация меры в LuckyTemplates
Далее вам необходимо дополнительно оптимизировать коды DAX.
Вместо использования используйте функцию .
HASONEVALUE подсчитывает количество значений, доступных в контексте фильтра, что является очень интенсивной операцией. Тем временем ISINSCOPE проверяет, используется ли предоставленный столбец для группировки или нет.
После изменения функций подтвердите измерение и выполните его в DAX Studio.
Вы можете видеть, что количество запросов к движку хранения теперь равно 12. Общее время выполнения также стало 105 миллисекунд.
Во втором запросе вы увидите идентификатор данных обратного вызова.
Это иногда происходит, когда вы используете SELECTEDVALUE с текстовым полем. Когда вы видите данные обратного вызова, механизм хранения вызывает механизм формул, чтобы решить сложность кода. Это снижает производительность вашей меры.
Удалить данные обратного вызова
Вам нужно удалить данные обратного вызова, чтобы улучшить производительность вашего отчета. Для этого вам нужно создать таблицу конфигурации в модели данных.
Перейдите к опции «Ввести данные» и вставьте данные. Назовите таблицу LossTypeConfigTable .
Затем нажмите «Изменить», чтобы изменить тип данных столбца, который вы собираетесь импортировать.
Тип данных идентификатора типа потери должен быть значением учителя, чтобы его можно было использовать внутри функции SELECTEDVALUE .
После загрузки в модель создайте связь между таблицей Jobs и таблицей LossTypeConfigTable на основе типа потерь.
После создания связи перейдите в таблицу Jobs и добавьте новый столбец. Назовите его Loss ID, а затем введите формулу.
Используйте функцию для таблицы конфигурации, а затем извлеките идентификатор типа потери.
Затем вернитесь к показателю RB Incentive% и укажите числовое поле вместо текстового поля. Внутри SELECTEDVALUE замените Loss Type на Loss ID.
Затем измените все меры внутри кода. Используйте целочисленное значение вместо текстовых значений при проверке типа задания.
После изменения кода подтвердите меру и выполните ее в DAX Studio.
Идентификатор данных обратного вызова исключается из запроса, а время выполнения кода сокращается до 93 миллисекунд.
Показатель RB Incentive% теперь полностью оптимизирован.
5. Оптимизируйте другие показатели в LuckyTemplates
Вам также необходимо оптимизировать показатели WR Incentive% и QB Incentive%.
Скопируйте и вставьте точный код, используемый в показателе RB Incentive%. Затем запустите 3 меры вместе.
Общее время выполнения оптимизировано и уменьшено с 1855 миллисекунд до 213 миллисекунд. Есть также только 12 запросов механизма хранения.
Первые два запроса создают контекст фильтра, а остальные представляют точное количество значений в столбце Jobs Loss Type.
Поскольку все меры были оптимизированы, запустите исходный код и посмотрите, как изменилась производительность. Данные показывают, что теперь он вычисляется за 1,9 секунды.
Производительность всего кода теперь оптимизирована, что делает ваш отчет быстрее и лучше.
Оптимизируйте функции DAX с помощью этого нового курса
Простые преобразования LuckyTemplates для более оптимизированных данных
Оптимизируйте формулы LuckyTemplates с помощью расширенного DAX
Заключение
В отчетах LuckyTemplates меры должны быть оптимизированы, чтобы обеспечить бесперебойную работу ваших кодов DAX. Это также повышает общую производительность вашего отчета.
Вы узнали о различных методах оптимизации показателя в LuckyTemplates и узнали, как оценить, какой из них следует использовать в зависимости от контекста вашего отчета.
Что такое self в Python: примеры из реального мира
Что такое self в Python: примеры из реального мира
Как сохранить и загрузить файл RDS в R
Вы узнаете, как сохранять и загружать объекты из файла .rds в R. В этом блоге также рассказывается, как импортировать объекты из R в LuckyTemplates.
Новый взгляд на первые N рабочих дней — решение для языка кодирования DAX
В этом руководстве по языку программирования DAX вы узнаете, как использовать функцию GENERATE и как динамически изменять название меры.
Продемонстрируйте идеи с помощью метода многопоточных динамических визуализаций в LuckyTemplates
В этом учебном пособии рассказывается, как использовать технику многопоточных динамических визуализаций для создания аналитических сведений из динамических визуализаций данных в ваших отчетах.
Введение в фильтрацию контекста в LuckyTemplates
В этой статье я пройдусь по контексту фильтра. Контекст фильтра — одна из основных тем, с которой должен ознакомиться любой пользователь LuckyTemplates.
Лучшие советы по использованию приложений в онлайн-службе LuckyTemplates
Я хочу показать, как онлайн-служба LuckyTemplates Apps может помочь в управлении различными отчетами и аналитическими данными, созданными из различных источников.
Анализ изменений маржи прибыли с течением времени — аналитика с LuckyTemplates и DAX
Узнайте, как рассчитать изменения вашей прибыли, используя такие методы, как разветвление показателей и объединение формул DAX в LuckyTemplates.
Идеи материализации кэшей данных в DAX Studio
В этом руководстве будут обсуждаться идеи материализации кэшей данных и то, как они влияют на производительность DAX при предоставлении результатов.
Бизнес-отчетность с использованием LuckyTemplates
Если вы все еще используете Excel до сих пор, то сейчас самое подходящее время, чтобы начать использовать LuckyTemplates для своих бизнес-отчетов.