Десять отчётов тянут одну и ту же 1С, и в каждом — своя копия Power Query: те же чистки, те же справочники. Источник дёргают десять раз, логика расходится, правка повторяется десятикратно. Решение — вынести подготовку данных в облачный, переиспользуемый слой ETL: это dataflows.
Power Query (чистка, merge/append) разбирался в базовом курсе — но там он жил внутри одного .pbix. Dataflow — это тот же Power Query, но в Power BI Service, как общий ресурс для многих моделей.
Что такое dataflow
Dataflow — это Power Query, вынесенный в Power BI Service. Вы описываете преобразования (те же шаги: источник → чистка → merge), а результат сохраняется в облаке (в Azure Data Lake под капотом) как готовые таблицы. К ним затем подключаются много .pbix/моделей — каждая берёт уже подготовленные данные.
Ключевая идея — разделение слоёв: подготовка данных (dataflow) живёт отдельно от модели и отчёта (датасет). Один dataflow «Справочник товаров» питает пять моделей. Поправили логику очистки в одном месте — обновилось у всех. Это устраняет дублирование Power Query по файлам.
Зачем это в эксплуатации
- Единая логика. Одна чистка/один справочник для всех — нет расхождений между отчётами.
- Меньше нагрузки на источник. Источник опрашивается dataflow'ом, а не каждым отчётом отдельно.
- Разделение труда. Инженер ведёт dataflows (подготовку), аналитики строят модели поверх готовых таблиц.
- Переиспользование между dataflow. Можно строить вычисляемые сущности поверх других dataflow (linked entities).
Dataflow vs семантическая модель
Не путайте два «общих» ресурса из этого курса:
| Dataflow | Семантическая модель (датасет) | |
|---|---|---|
| Слой | подготовка данных (ETL) | модель: связи, меры (DAX) |
| Аналог | Power Query в облаке | то, к чему подключают отчёты |
| Отдаёт | очищенные таблицы | меры и измерения для визуалов |
Порядок слоёв: dataflow готовит и чистит данные → семантическая модель строит на них связи и меры → отчёт их показывает. Dataflow не заменяет модель и не содержит DAX-мер; он кормит модель чистыми таблицами. Это разные этажи одного конвейера.
Когда оправдано
- одни и те же источники/справочники используются многими моделями;
- подготовка данных тяжёлая, и не хочется гонять её в каждом отчёте;
- нужно отделить роль «инженер данных» от «аналитик отчётов».
Для единственной модели одного автора dataflow — лишний слой и лишнее обновление: проще оставить Power Query внутри .pbix. Dataflow окупается переиспользованием — когда одну и ту же подготовку делят несколько моделей. Нет переиспользования — нет смысла выносить.
Что дальше
Это завершает текущий контур экспертного курса: шлюз и обновление, RLS, инкрементальное обновление, оптимизация, calculation groups, корпоративные модели, организация публикации (workspaces, pipelines, Git/CI-CD), мониторинг и dataflows. Полный цикл production-эксплуатации Power BI. Курс пополняется.