Обновление Power BI: как обнаружить изменение структуры исходной таблицы

Если отчет вчера обновлялся нормально, а сегодня падает без понятного объяснения, причина часто не в самом refresh, а в том, что источник уже не такой, как был при настройке запроса. Для Power BI это не мелочь: запрос опирается не только на данные, но и на конкретные имена столбцов, их наличие и дальнейшие шаги обработки. Поэтому полезно отвечать не на общий вопрос «почему обновление не сработало», а на более узкий: как быстро понять, что изменилась именно структура таблицы.

Ниже разберем практичный способ для Power BI Desktop и редактора Power Query. Он не обещает ничего про отдельные облачные сценарии и не заменяет полную проверку модели, но помогает поймать самое частое изменение схемы: столбец переименовали, удалили или добавили без предупреждения. Смысл подхода в том, чтобы вставить в запрос явный контрольный шаг и получать понятную ошибку раньше, чем сломаются типы, меры или визуалы.

Какая схема источника считается ожидаемой

Ожидаемая схема — это не абстрактный «похожий набор полей», а конкретный список столбцов, без которых ваш запрос теряет смысл. Для учебной и рабочей модели лучше зафиксировать этот список явно: какие столбцы обязательны, как именно они называются и где потом используются. Тогда при обновлении вы сравниваете не ощущения, а факт: совпал ли реальный набор колонок с тем, на который рассчитаны шаги запроса.

Здесь полезно разделить столбцы на две группы. Первая — критичные: ключ, дата, количество, сумма, код клиента и другие поля, без которых ломается фильтрация, агрегация или связь таблиц. Вторая — необязательные: например, новый комментарий или техническая пометка, которая пока нигде не участвует. Такое разделение нужно не для формальности, а чтобы выбрать поведение запроса. Для критичных полей разумно прерывать обновление сразу. Для лишних новых полей иногда достаточно зафиксировать их появление и потом решить, нужны ли они модели.

Если модель работает в режиме импорта, Power BI хранит в модели копию данных, а не читает источник заново при каждом открытии визуала. Поэтому обновление должно не только получить новые строки, но и пройти по тем же ссылкам на таблицы и столбцы, что были в момент настройки. Когда схема изменилась, «обновить данные» и «применить новую структуру» — это не одно и то же действие. Именно на этой границе и возникает большинство непонятных сбоев.

Что обычно происходит при переименовании или удалении столбца

Самый неприятный сценарий выглядит обманчиво просто: в источнике столбец Amount переименовали в Revenue, или поле Qty вообще убрали. Для человека это одно изменение в таблице, а для Power Query — обрыв цепочки шагов. Шаг смены типа, выборки столбцов, переименования, объединения запросов или вычисления может ссылаться на старое имя. В результате ошибка всплывает не там, где произошло изменение, а через несколько шагов дальше, и диагностика затягивается.

Важно понимать и вторую часть проблемы. Если изменилось имя или наличие столбца, последствия не ограничиваются одним запросом. После обновления схемы могут сломаться меры DAX, вычисляемые столбцы, отношения между таблицами и визуалы, если они зависели от этого поля. Поэтому задача на раннем этапе — не «починить любой ценой», а точно локализовать источник расхождения: какие колонки ожидались и какие пришли на самом деле.

Для моделей, опубликованных в Power BI Service, есть дополнительный нюанс: изменение структуры источника не применяется там так же, как в Desktop. По материалам Microsoft, переименование или удаление столбца в источнике может привести к сбою обновления в сервисе, а исправление требует обновления схемы в Power BI Desktop и повторной публикации модели. Поэтому даже если итоговая проблема проявилась уже после публикации, безопаснее разбирать ее сначала в Desktop, где видны шаги запроса и зависимые элементы модели.

Как поставить контрольный шаг загрузки в Power Query

Самая полезная точка для проверки — сразу после получения нужной таблицы из источника, но до смены типов, переименований и объединений. Тогда вы сравниваете фактические имена колонок с ожидаемым списком и, если есть расхождение, останавливаете запрос осмысленной ошибкой. Это лучше, чем ждать, пока сломается какой-нибудь поздний шаг вроде вычисления суммы или загрузки в модель.

Учебный пример. Среда примера — Power BI Desktop, Power Query, язык M. Допустим, вы подключаете в Desktop файл Excel, в книге есть таблица Sales, а ожидаемые столбцы — Date, Product, Qty, Amount. Путь к файлу и имя таблицы в примере условные. Ниже шаг, который проверяет схему и сообщает, каких колонок не хватает и какие появились лишними.

let
    Source = Excel.Workbook(File.Contents("C:\\Data\\sales.xlsx"), null, true),
    SalesTable = Source{[Item="Sales", Kind="Table"]}[Data],
    ExpectedColumns = {"Date", "Product", "Qty", "Amount"},
    ActualColumns = Table.ColumnNames(SalesTable),
    MissingColumns = List.Difference(ExpectedColumns, ActualColumns),
    ExtraColumns = List.Difference(ActualColumns, ExpectedColumns),
    #"Schema Check" =
        if List.Count(MissingColumns) > 0 or List.Count(ExtraColumns) > 0 then
            error Error.Record(
                "SchemaCheck",
                "Изменилась структура исходной таблицы",
                [
                    Missing = Text.Combine(MissingColumns, ", "),
                    Extra = Text.Combine(ExtraColumns, ", ")
                ]
            )
        else
            SalesTable,
    #"Selected Columns" = Table.SelectColumns(#"Schema Check", ExpectedColumns),
    #"Changed Type" = Table.TransformColumnTypes(#"Selected Columns", {
        {"Date", type date},
        {"Product", type text},
        {"Qty", Int64.Type},
        {"Amount", type number}
    })
in
    #"Changed Type"

Если ваш источник — не Excel-таблица, а лист или CSV, логика остается той же: сначала привести данные к таблице с заголовками, потом проверить имена колонок, и только после этого менять типы. Практический смысл шага Schema Check в том, что он переносит момент обнаружения ошибки ближе к источнику. Если схема изменилась, вы видите именно это, а не косвенный симптом вроде «столбец не найден» в конце длинной цепочки.

Как это выглядит на условных данных

Возьмем условную таблицу продаж. Вчера источник содержал столбцы Date, Product, Qty, Amount. Запрос обновлялся и загружал, например, 120 строк. Сегодня поставщик файла решил, что поле Amount надо назвать Revenue, а Qty убрать, потому что «оно больше не нужно». Число строк осталось тем же, и на глаз файл выглядит почти одинаково.

Без контрольного шага запрос может упасть позже, например на Table.TransformColumnTypes или на выборе столбцов для загрузки. Тогда пользователь видит техническую ошибку и начинает проверять типы, хотя настоящая причина возникла раньше. С контрольным шагом результат проверяемый и однозначный: Power Query сразу возвращает сообщение, что отсутствуют Qty и Amount, а появился лишний Revenue.

Практическая польза здесь не в том, что отчет сам чинится, а в сокращении времени на поиск. Вы быстро различаете два сценария. Первый: источник действительно изменили, и нужно согласовать новую схему. Второй: ошибка вызвана не схемой, а данными внутри тех же колонок, например пустыми значениями или текстом в числовом поле. Это разные задачи, и смешивать их в одной диагностике неудобно.

Протокол исправления: что делать после срабатывания проверки

Когда контрольный шаг сработал, не спешите сразу переписывать весь запрос. Полезнее пройти короткий протокол. Сначала сравните ожидаемый список с текущей таблицей источника и выясните, было ли изменение намеренным. Если столбец переименовали, решите, это новое постоянное имя или временная ошибка выгрузки. Если поле удалили, проверьте, не использовалось ли оно в связях, мерах, вычисляемых столбцах и визуалах.

Дальше действуйте по одному из двух путей. Если изменение ошибочное и источник должны вернуть к прежнему виду, лучше не менять модель, а зафиксировать проблему у владельца данных и дождаться исправления. Если изменение принято и станет новой нормой, тогда обновите шаги Power Query, проверьте типы, затем последовательно проверьте зависимые элементы: меры, связи, фильтры и визуалы. Важно именно последовательное исправление, иначе можно убрать одну ошибку и оставить скрытую поломку в модели.

Для учебной и регулярной работы удобно хранить рядом с запросом короткую памятку: обязательные столбцы, их смысл и места использования. Тогда после срабатывания контроля у вас есть не только ошибка, но и чек-лист исправления.

• Проверьте источник и подтвердите, какие столбцы должны быть обязательными.
• Сверьте новые и пропавшие имена с шагом Schema Check.
• Обновляйте выборку столбцов и типы только после согласования новой схемы.
• Проверьте, не сломались ли связи, меры и визуалы из-за исчезнувшего поля.
• Если модель публикуется, после исправления обновите PBIX в Desktop и заново опубликуйте модель.

Практический результат такого подхода простой и проверяемый: при следующем изменении структуры вы получите не абстрактный сбой обновления, а явное указание, каких колонок не хватает и что появилось нового. Это особенно полезно в учебных моделях, где важнее понять причину ошибки и порядок действий, чем просто дожать refresh любой ценой.

Если хотите потренировать такие задачи в учебном формате, можно посмотреть курс Excel academy + Power BI для анализа данных. По официальной программе у SF Education там заявлены блоки по Power Query и Power BI, расчетным столбцам, расчетным мерам и функциям CALCULATE, ALL и FILTER. Для темы контроля обновления это полезно потому, что исправление схемы почти всегда затрагивает и подготовку данных, и модель.