Предыдущие посты серии:
1. Документация по промптам.
2. Выбор нейронок.
3. Подготовка к разработке.
4. Оптимизация кода.
5. Если код не "летает".
6. Минимизируем вычисления.
7. Фатальный пример вычислений.
8. Порядок обработки данных.
9. Смерть производительности. Часть 1.
10. Смерть производительности. Часть 2.
11. Плохие и хорошие примеры.
Выносим сортировку из ETL-процесса в Power Query на уровень отчета в следующих случаях:
1️⃣ Для визуального представления.
Если сортировка нужна только для того, чтобы видеть таблицу красиво (по алфавиту, по убыванию цены). Excel и Power BI сортируют данные в визуальных элементах (графиках, матрицах) мгновенно, используя оптимизированные движки, не нагружая процесс обновления данных.
2️⃣ Для интерактивности.
Если хотим иметь возможность менять порядок сортировки (кликом по заголовку столбца). Жесткая сортировка в Power Query лишает отчет гибкости.
3️⃣ При использовании Top-N фильтров в Power BI.
Движок VertiPaq (DAX) вычисляет "Топ-10" в визуализациях быстрее, чем Power Query готовит пред-отсортированную таблицу.
————
Оставляем сортировку в Power Query только если она влияет на логику расчетов:
1️⃣ Для вычисления индекса строки (Index Column).
2️⃣ Для расчета нарастающего итога (Running Total).
3️⃣ Для функций заполнения (Fill Down, Fill Up). В этих случаях обязательно используем
Table.Buffer после сортировки.Во всех остальных случаях сортировка в Power Query — ошибка и излишняя нагрузка.
————
⚫️ Не сортируем, если можем агрегировать.
Всегда проверяем, можно ли получить результат через Max, Min, Sum или Group. Это золотой стандарт оптимизации.
⚫️ Ранняя фильтрация.
Никогда не сортируем данные до фильтрации. Сначала используем
Table.SelectRows, чтобы отсечь все лишнее, и уменьшить количество строк. Сортировка 1000 строк в 100 раз быстрее, чем сортировка 100.000 строк (спасибо, кэп).⚫️ Используем буферизацию с умом.
Если отсортировали таблицу для сложного расчета и многократного обращения к результатам, берём этот шаг в
Table.Buffer. Иначе Power Query может выполнять сортировку заново для каждой последующей строки вычислений.⚫️ Разделяем данные и представление.
Если сортировка нужна только для презентации, делаем её в модели данных или элементах визуализации данных, а не в ETL.
⚫️ Query Folding — приоритет (но не поддерживается при работе с локальными файлами на ПК, а только с базой данных).
Table.Sort при работе с SQL часто прерывает Query Folding — свертывание запросов. Если сортировка неизбежна и данные не лежат на ПК, выполняем её на стороне сервера, а не в памяти Power BI.Итого:
➕ Нужно Макс/Мин значение? Используем List.Max, List.Min (вместо Sort+First).
➕ Нужен Топ-N? Используем List.MaxN (вместо Sort+FirstN).
➕ Нужен уникальный список? Используем List.Distinct (вместо Sort+RemoveDuplicates).
➕ Нужно найти соответствие? Используем Table.Join (вместо SelectRows внутри AddColumn).
➕ Нужна красота в отчете? Сортируем в Excel/Power BI, а не в Power Query.
✅ Хороший код Power Query:
— Выполняется за секунды или минуты, а не часы.
— Работает за время O(n) или O(n+m).
— Масштабируется с тысяч до миллионов строк.
❌ Плохой код Power Query:
— Сортирует "на всякий случай".
— Сортирует в циклах.
— Сортирует ради отображения.
— Отдаёт ошибку нехватки памяти.
Для использования самых быстрых альтернатив сортировки, спрашиваем у нейросети:
Как по каждому значению столбца X получить значение из столбца Y, которое соответствует наибольшему значению метрики Z, но:
— Не используя при этом сортировок.
— Используя функцию, которая сразу возьмёт максимальное значение.
В каждом промпте про оптимизацию скорости кода обязательно явно указываем на минимизацию количества вычислений из «Big O» нотации:
1. Используй операции с вычислительной сложностью: O(1), O(log n), O(n), O(n + m), но как можно меньшее из них.
2. Не используй операции вычислительной сложностью: O(n log n), O(n × m), O(n²), O(nᵏ), O(2ⁿ), O(n!).
В следующем посте — о параметризации кода переменными для его использования в разных проектах.
via @ppc_bigbrain