Объясняем, как Power Query переносит вычисления в источник, какие шаги ломают folding и как это проверить. Начнём с обычного вопроса: какое решение из этого должен принять бизнес? А уже потом будем крутить формулы и фильтры.
Что получите после чтения
Поймёте query folding, проверите план запроса и переставите шаги так, чтобы источник делал тяжёлую работу сам. Без универсального норматива из воздуха: формула, пример с числами и следующий шаг будут прямо в статье.
Что это такое простыми словами
Query folding — способность Power Query перевести шаги подготовки данных в запрос источника. Тогда фильтр, выбор колонок и часть объединений выполняет база, а не компьютер с Power BI. В модель приходит уже нужный набор строк.
Какой вопрос мы на самом деле решаем
Фразы «query folding power query», «сворачивание запросов power query», «как проверить query folding», «view native query power query» звучат по-разному, но задача одна: поймёте query folding, проверите план запроса и переставите шаги так, чтобы источник делал тяжёлую работу сам. Поэтому ниже не будет парада терминов — будет порядок действий.
Что это даёт бизнесу
Folding уменьшает объём передачи, время обновления и нагрузку на gateway. Особенно заметно это на больших SQL-таблицах и при incremental refresh.
Для этой задачи польза начинается с шага «Подключитесь через поддерживаемый коннектор». Дальше у результата должны появиться владелец, дата проверки и действие. Иначе даже правильная цифра просто сидит на экране и никого не трогает (тихая карьера).
Порядок действий
- Подключитесь через поддерживаемый коннектор
- Оставьте фильтр и выбор колонок в начале
- Проверяйте View Native Query или Query Plan
- Найдите первый шаг без folding
- Перенесите тяжёлую логику в источник
- Сравните время и число строк
- Добавьте контроль после изменений
Первый проход делаем на маленьком, но честном примере. Особенно важен шаг «Оставьте фильтр и выбор колонок в начале»: он показывает, где методика расходится с реальным процессом. Когда сверка сошлась, можно автоматизировать.
Формула и логика расчёта
Эффект можно оценить так: переданные строки до оптимизации ÷ строки после фильтра. Если из 100 млн операций нужны 2 млн, folding потенциально сокращает объём в 50 раз ещё до gateway.
Рядом с расчётом подписываем период, единицу и дату среза. Для «Проверяйте View Native Query или Query Plan» это особенно важно: две похожие цифры могут отвечать на разные вопросы. Рядом держим объём данных и контрольный итог.
Исключения не прячем. Отдельно проверяем риск «Считать наличие View Native Query единственным доказательством» и показываем долю неизвестных значений. Иногда именно эта доля объясняет «улучшение» быстрее, чем ещё один график.
Подробный пример с числами
Запрос читает 80 млн строк за пять лет, затем локально фильтрует последние 90 дней — 3,6 млн строк. Обновление идёт 48 минут. Переносим фильтр даты до пользовательской функции и сохраняем folding. Источник возвращает только 3,6 млн строк, обновление занимает 9 минут. Контрольная сумма выручки и число заказов совпадают, значит ускорение не изменило смысл.
Как объяснить результат
Для темы «Query Folding в Power Query» сначала называем факт, затем базу сравнения, потом причину и действие. Без «всё плохо»: что изменилось, где возникла разница и что проверяем до следующей даты. Такой формат спокойно переживает встречу с собственником.
Как собрать рабочий отчёт
Для «Найдите первый шаг без folding» на первом экране оставляем только результат, базу сравнения и два-три разреза, которые меняют решение. Деталь уводим на следующий уровень, чтобы общая картина не превращалась в обои из таблицы.
Перед шагом «Перенесите тяжёлую логику в источник» показываем дату обновления и статус качества. Если загрузка задержалась, пишем об этом прямо. Вчерашняя правильная цифра сегодня легко становится неправильным решением.
К шагу «Сравните время и число строк» сохраняем версию методики: формулу, исключения, источник, владельца и дату. Когда правило меняется, историю либо честно пересчитываем, либо отмечаем границу. Тайные улучшения доверия не добавляют.
После «Добавьте контроль после изменений» ответственный коротко пишет, что изменилось, какая причина уже подтверждена, а что остаётся гипотезой. Так команда не выдаёт первое удобное объяснение за факт.
Как проверить данные до автоматизации
- Сверьте общую сумму и количество объектов с источником
- Возьмите пять крупных и пять случайных записей
- Проверьте даты, статусы, идентификаторы и исключения
- Повторите расчёт вручную на маленькой выборке
- Попросите владельца процесса подтвердить смысл результата
При риске «Ставить пользовательскую функцию перед фильтром» проверяем и крупные, и случайные объекты. Крупные помогают найти весомое расхождение, случайные — системную ошибку. Одна выборка не заменяет другую.
Чтобы не повторить «Загружать ненужные колонки», сохраняем короткий протокол: период, источник, версия, контрольная сумма, расхождения и принятое правило. На следующем обновлении не придётся вспоминать договорённость по памяти.
Как автоматизировать и не потерять контроль
Автоматизация здесь должна защищать от риска «Оптимизировать без сверки результата». На входе контролируем свежесть, число строк и ключевые поля. На выходе — итог и долю неизвестных. Ошибка идёт конкретному владельцу, а не на общий ящик в пятницу вечером.
Для «Query Folding в Power Query» храним снимки результата: они помогают сравнить ожидание с фактом и объяснить изменение. Перезаписанная история удобна отчёту, но мешает команде учиться на своих допущениях.
Как читать динамику без поспешных выводов
Сравнивайте одинаковые рабочие циклы. Понедельник с пятницей, праздничную неделю с обычной и новый сегмент со зрелым смешивать можно технически, но вывод получится слабым. Сначала отделите изменение состава данных от изменения самого процесса. Рядом с линией показателя держите объём выборки и отметки о релизах, акциях, переносах и смене правил.
Один скачок — повод проверить данные и контекст, а не немедленно перестраивать команду. Для регулярного управления задайте коридор обычных колебаний и минимальный срок наблюдения. Если изменение повторяется несколько сопоставимых периодов и видно на исходных объектах, появляется основание действовать. После действия заранее назначьте дату проверки и показатель, который должен измениться. Иначе любое движение легко объявить успехом (особенно на красивом слайде).
Ограничения и типичные ошибки
- Считать наличие View Native Query единственным доказательством
- Ставить пользовательскую функцию перед фильтром
- Загружать ненужные колонки
- Оптимизировать без сверки результата
- Забывать про нагрузку на production-базу
Ограничение не делает метрику бесполезной. Оно показывает границу, внутри которой ей можно доверять. Честная подпись рядом с числом полезнее ещё одного знака после запятой.
Как я использую это в работе
Я сначала измеряю: длительность шага, строки на входе и выходе. Потом двигаю один фильтр и снова измеряю. Если запрос ускорился, сверяю сумму и несколько записей. Производительность без проверки данных — очень быстрый способ получить неправильный отчёт.
После первой встречи я не прошу команду сразу перестроить весь процесс. Мы выбираем один участок, фиксируем исходное значение и дату проверки. Если результат подтверждается, правило масштабируем. Если нет — сохраняем вывод и меняем гипотезу. Так аналитика помогает действовать, а не просто доказывает, что у нас много данных.
Что получает каждая роль
- Собственник — понятный риск, диапазон результата и решение
- Руководитель — участок процесса и ответственного
- Маркетолог — связь трафика или спроса с бизнес-результатом
- Аналитик — согласованное определение и контрольные примеры
- Команда — один следующий шаг вместо общего призыва улучшить всё
Что сделать прямо сейчас
Откройте самый долгий запрос, найдите первый шаг, после которого folding пропадает, и проверьте, можно ли поставить фильтр и выбор колонок раньше.
Для «Query Folding в Power Query» этого достаточно, чтобы получить первую честную точку. Не пытайтесь за один вечер починить весь процесс. Нам нужен один проверяемый результат и дата следующей проверки. После неё уже будет понятно: масштабировать решение, менять гипотезу или сначала починить данные. Запишите ещё, кто принимает решение, какой результат он ожидает и где команда увидит факт. Это и будет нашей короткой проверкой на пользу.
Сохраните исходную выгрузку и правило расчёта. Через один полный рабочий цикл вернитесь к цифре и сравните ожидание с фактом. Запишите, какое допущение подтвердилось, а какое пришлось изменить. Именно эта обратная связь превращает показатель в инструмент управления, а не в очередную карточку отчёта.
