Прочитать на английском

Поделиться через


Распространенные проблемы

Power Query

Сохранение сортировки

Предположим, что при сортировке данных все подчиненные операции сохраняют порядок сортировки.

Например, если вы сортируете таблицу продаж так, чтобы в каждом магазине отображалось наибольшее продажу, вы можете ожидать, что операция "Удалить дубликаты" возвращает только первую продажу для каждого магазина. И эта операция, по сути, может работать. Однако это поведение не гарантируется.

Из-за того, как Power Query оптимизирует определенные операции, в том числе пропуская их или выгружая их в источники данных (которые могут иметь собственное уникальное поведение упорядочения), порядок сортировки не гарантируется для сохранения путем агрегирования (Table.NestedJoinнапримерTable.Group, слияний ) или дублирования (например, удаления).Table.Distinct

Существует несколько способов обойти эту проблему. Ниже приведено несколько вариантов:

  • Выполните сортировку после применения нижестоящей операции. Например, при группировке строк сортируйте вложенную таблицу в каждой группе перед применением дальнейших шагов. Ниже приведен пример кода M, демонстрирующий этот подход: Table.Group(Sales_SalesPerson, {"TerritoryID"}, {{"SortedRows", each Table.Sort(_, {"SalesYTD", Order.Descending})}})
  • Буферизуйте данные (используя) Table.Bufferперед применением нижестоящей операции. В некоторых случаях эта операция приводит к тому, что нижестоящей операции сохраняется порядок буферизованной сортировки.
  • Используйте ранжирование. Например, вместо использования Table.Distinctможно упорядочить столбцами, содержащими повторяющиеся значения, ранжировать на основе столбца разбиения связи (например modified_date), а затем фильтровать, чтобы сохранить только строки ранжирования 1.

Вывод типа данных

Иногда Power Query может неправильно обнаружить тип данных столбца. Это связано с тем, что Power Query выводит типы данных, используя только первые 200 строк данных. Если данные в первых 200 строках каким-то образом отличаются от данных после строки 200, Power Query может в конечном итоге получить неправильный тип. (Помните, что неправильный тип не всегда создает ошибки. Иногда полученные значения просто неверны, что затрудняет обнаружение проблемы.)

Например, представьте столбец, содержащий целые числа в первых 200 строках (например, все нули), но содержит десятичные числа после строки 200. В этом случае Power Query определяет тип данных столбца, который должен быть целым числом (Int64.Type). Это вывод приводит к усеканию десятичных частей любых не целых чисел.

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

Так как обнаружение типов работает на первых 200 строках, но профилирование данных может работать по всему набору данных, можно использовать функцию профилирования данных, чтобы получить ранние указания в Редактор запросов об ошибках (от обнаружения типов или любого количества других причин) за пределами верхних N строк.

Подключения принудительно закрыты удаленным узлом

При подключении к различным API может появиться следующее предупреждение:

Data source error: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host

Если возникла эта ошибка, скорее всего, возникла проблема с сетью. Как правило, первые пользователи, с которыми нужно ознакомиться, являются владельцами источника данных, к которому вы пытаетесь подключиться. Если они не думают, что они закрывают подключение, то возможно, что-то на пути (например, прокси-сервер, промежуточные маршрутизаторы или шлюзы и т. д.).

Независимо от того, воспроизводится ли это только с любыми данными или только большими размерами данных, скорее всего, есть время ожидания сети где-то в маршруте. Если это только с большими данными, клиенты должны обратиться к владельцу источника данных, чтобы узнать, поддерживает ли их API разбиение по страницам, чтобы они могли разделить свои запросы на небольшие блоки. При сбое следует использовать альтернативные способы извлечения данных из API (следующие рекомендации по источнику данных).

Наборы шифров TLS RSA устарели

Начиная с 30 октября 2020 г. следующие наборы шифров становятся устаревшими на наших серверах.

  • "TLS_RSA_WITH_AES_256_GCM_SHA384"
  • "TLS_RSA_WITH_AES_128_GCM_SHA256"
  • "TLS_RSA_WITH_AES_256_CBC_SHA256"
  • "TLS_RSA_WITH_AES_128_CBC_SHA256"

Ниже приведен список поддерживаемых наборов шифров:

  • "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
  • "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"
  • "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  • "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
  • "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"
  • "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384"
  • "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
  • "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"

Наборы шифров используются для шифрования сообщений для защиты сетевого соединения между клиентами/серверами и другими серверами. Мы удаляем приведенный выше список комплектов шифров, чтобы соответствовать нашим текущим протоколам безопасности. Начиная с 1 марта 2021 года клиенты могут использовать только наши стандартные наборы шифров.

Это наборы шифров, к которому вы подключаетесь, должны поддерживать подключение из Power Query Online или Power BI.

В Power Query Desktop (Power BI, Excel) мы не контролируем наборы шифров. Если вы пытаетесь подключиться к Power Platform (например, Power Platform Dataflows) или службе Power BI, вам потребуется один из этих наборов шифров, включенных в ос. Вы можете либо обновить версию Windows или обновить реестр Windows TLS, гарантировать, что конечная точка вашего сервера поддерживает один из этих шифров.

Чтобы убедиться, что сервер соответствует протоколу безопасности, можно выполнить тест с помощью шифра TLS и средства проверки. Одним из примеров может быть SSLLABS.

Клиенты должны обновить свои серверы до 1 марта 2021 г. Для получения дополнительной информации о порядке настройки набора шифров TLS см. в разделе Управление протоколом безопасности транспортного уровня (TLS).

Отзыв сертификатов

Следующая версия Power BI Desktop приводит к сбою SSL-подключений из Desktop, когда все сертификаты в цепочке SSL отсутствуют в состоянии отзыва сертификатов. Это изменение текущего состояния, в котором отзыв приводил только к сбою подключения в случае явного отзыва сертификата. Другие проблемы с сертификатами могут включать недопустимые подписи и срок действия сертификата.

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

Это не рекомендуется, но пользователи могут продолжать полностью отключать проверки отзыва.

Ошибка: оценка отменена

Power Query возвращает сообщение "Оценка была отменена" при отключении фонового анализа, а пользователь переключается между запросами или закрывает Редактор запросов во время обновления запроса.

Ошибка: ключ не соответствовал строкам в таблице

Существует множество причин, по которым Power Query может возвращать ошибку, из-за которой ключ не соответствовал ни одной строке в таблице. При возникновении этой ошибки подсистема Mashup не может найти имя таблицы, которую он ищет. Причины возникновения этой ошибки:

  • Имя таблицы было изменено, например в самом источнике данных.
  • Учетная запись, используемая для доступа к таблице, не имеет достаточных привилегий для чтения таблицы.
  • Существует несколько учетных данных для одного источника данных, который не поддерживается в службе Power BI при использовании личных облачных подключений. Эта ошибка может произойти, например, если источник данных является облачным источником данных, а несколько учетных записей используются для доступа к источнику данных одновременно с разными учетными данными. Если источник данных находится в локальной среде, необходимо использовать локальный шлюз данных.

Ограничение. Требование к присоединению к домену для компьютеров шлюза при использовании проверка подлинности Windows

Использование проверка подлинности Windows с локальным шлюзом требует, чтобы компьютер шлюза был присоединен к домену. Это относится к любым подключениям, настроенным с помощью проверка подлинности Windows через шлюз*. Учетные записи Windows, используемые для доступа к источнику данных, могут потребовать доступа на чтение к общим компонентам в каталоге Windows и установке шлюза.

Ограничение. Обновление OAuth2 между клиентами не поддерживается в служба Power BI

Если вы хотите подключиться к источнику данных из служба Power BI с помощью OAuth2, источник данных должен находиться в том же клиенте, что и служба Power BI. В настоящее время сценарии подключения с несколькими клиентами не поддерживаются в OAuth2.

Ограничение. Пользовательская конечная точка проверки подлинности AD FS не поддерживается в служба Power BI

Возможность использования пользовательской конечной точки проверки подлинности службы федерации Active Directory (AD FS) (AD FS) не поддерживается в служба Power BI. Пользователи могут столкнуться со следующей ошибкой: служба маркеров, сообщаемая ресурсом, не является доверенной.

Ограничение. Гостевые учетные записи не поддерживаются

Использование гостевых учетных записей клиента для подключения к данным с помощью соединителей Power Query в настоящее время не поддерживается.

Expression.Error: оценка привела к переполнению стека и не может продолжиться

Ошибки переполнения стека могут быть вызваны ошибкой в коде M. Например, следующая функция создает переполнение стека, так как она многократно вызывается обратно в себя без какого-либо конечного условия. Функция, которая вызывает себя, как это, называется "рекурсивной" функцией.

let f = (x) => @f(x + 1) in f(0)

Ниже приведены некоторые распространенные способы устранения переполнения стека в коде M.

  • Убедитесь, что рекурсивные функции фактически завершаются после достижения ожидаемого конечного условия.
  • Замените рекурсию итерацией (например, с помощью таких функций, как List.Transform, List.Generate или List.Accumulate).

Expression.Error: оценка закончилась из памяти и не может продолжить

Ошибки "Вне памяти" (или OOM) могут быть вызваны слишком большим объемом операций с большими таблицами. Например, следующий код M создает OOM, так как он пытается загрузить миллиард строк в память одновременно.

Table.Buffer(Table.FromList({1..1000000000}, Splitter.SplitByNothing()))

Чтобы устранить ошибки памяти, оптимизируйте операции с большим объемом памяти, такие как сортировки, соединения, группировки и отличия, обеспечивая их свертывание в источник или путем их удаления в целом по возможности. Например, сортировки часто не нужны.

Потоки данных

Отмена обновления потока данных

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

Мы планируем добавить поддержку отмены обновления потока данных в будущем.