Когда сортировать данные можно и нельзя.

Предыдущие посты серии:

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