常见问题
你可能会假设,如果对数据进行排序,则任何下游操作都保留排序顺序。
例如,如果对销售表进行排序,以便首先显示每个商店的最大销售额,则可能需要执行“删除重复项”操作只会返回每个商店的最高销售额。 事实上,此操作可能会正常工作。 但是,无法保证此行为。
由于 Power Query 优化某些操作的方式,包括跳过这些操作或将其卸载到数据源(可以具有其自己的唯一排序行为),因此无法保证通过聚合(如 Table.Group
)、合并(如 Table.NestedJoin
)或重复项删除(如 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 将列的数据类型推断为 Date。 此推理导致将非日期文本值视为类型转换错误。
由于类型检测适用于前 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 中提取数据的替代方法(遵循数据源最佳做法)。
从 2020 年 10 月 30 日开始,我们的服务器已弃用以下密码套件。
- "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"
密码套件用于加密消息,以保护客户端/服务器与其他服务器之间的网络连接。 我们正在删除上列密码套件以遵守我们当前的安全协议。 从 2021 年 3 月 1 日开始,客户只能使用我们的标准密码套件。
这些是服务器连接到的密码套件,必须支持从 Power Query Online 或 Power BI 进行连接。
在 Power Query Desktop(Power BI、Excel)中,不会控制密码套件。 如果尝试连接到 Power Platform(例如 Power Platform 数据流)或 Power BI 服务,则需要在 OS 上启用其中一个密码套件。 您可以升级 Windows 版本或更新 Windows TLS 注册表,以确保您的服务器终结点支持这些密码之一。
要验证服务器是否符合安全协议,可以使用 TLS 密码和扫描仪工具执行测试。 一个示例可能是 SSLLABS。
客户必须在 2021 年 3 月 1 日之前升级服务器。 有关配置 TLS 密码套件顺序的详细信息,请参阅管理传输层安全性 (TLS)。
即将推出的 Power BI Desktop 版本会导致当 SSL 链中的任何证书缺少证书吊销状态时,来自 Desktop 的 SSL 连接失败。 这是对当前状态的更改,在显式吊销证书的情况下,吊销仅导致连接失败。 其他证书问题可能包括签名无效和证书过期。
由于有一些配置可能会取消吊销状态,例如使用公司代理服务器,我们将提供另一个选项来忽略没有吊销信息的证书。 此选项允许在某些情况下取消吊销信息的情况,但你不希望完全降低安全性,以便继续工作。
不建议这样做,但用户可以继续完全关闭吊销检查。
Power Query 在禁用后台分析时返回消息“评估已取消”,并且用户在查询之间切换或在刷新查询过程中关闭查询编辑器。
Power Query 可能会返回一个错误,指出 该键与表中的任何行不匹配,原因有很多。 出现此错误时,Mashup 引擎无法找到要搜索的表名称。 此错误发生的原因包括:
- 表名称已更改,例如数据源本身中。
- 用于访问表的帐户没有足够的权限来读取表。
- 使用个人云连接时,单个数据源可能有多个凭据,Power BI 服务不支持该凭据。 例如,当数据源是云数据源且多个帐户用于使用不同凭据同时访问数据源时,可能会发生此错误。 如果数据源在本地,则需要使用本地数据网关。
将 Windows 身份验证与本地网关配合使用时,需要将网关计算机加入域。 这适用于使用“Windows 身份验证通过网关*设置的任何连接。 用于访问数据源的 Windows 帐户可能需要对 Windows 目录中的共享组件和网关安装具有读取访问权限。
如果要使用 OAuth2 从 Power BI 服务连接到数据源,则该数据源必须与 Power BI 服务位于同一租户中。 目前,OAuth2 不支持多租户连接方案。
Power BI 服务不支持使用自定义 Active Directory 联合身份验证服务 (AD FS) 身份验证端点的功能。 用户可能会遇到以下错误:资源报告的令牌服务不受信任。
目前不支持使用租户的来宾帐户通过 Power Query 连接器连接到数据。
堆栈溢出错误可能是由 M 代码中的 Bug 引起的。 例如,以下函数会生成堆栈溢出,因为它反复调用自身,而无需任何种类的结束条件。 这样调用其本身的函数称为“递归”函数。
let f = (x) => @f(x + 1) in f(0)
下面是在 M 代码中解决堆栈溢出的一些常见方法。
- 确保递归函数在达到预期结束条件时实际终止。
- 将递归替换为迭代(例如,通过使用 List.Transform、List.Generate 或 List.Accumulate 等函数)。
“内存不足”错误(或 OOM)可能是针对非常大的表执行过多内存密集型操作造成的。 例如,以下 M 代码会生成 OOM,因为它尝试一次将十亿行加载到内存中。
Table.Buffer(Table.FromList({1..1000000000}, Splitter.SplitByNothing()))
要解决内存不足错误,请优化内存密集型操作,例如排序、联接、分组和非重复项,方法是确保它们折叠到源,或者尽可能将其完全删除。 例如,通常不需要排序。
有时会启动数据流刷新,但在启动数据流后,意识到在刷新数据之前需要再更改一项内容。 在这种情况下,必须等到刷新完成。 当前不支持在中间停止刷新,因为进程已经在处理获取数据和更新工作区或环境中的表。
我们确实计划在未来添加对取消数据流刷新的支持。