为什么我的次要合并结果查询中有 null 值?

合并结果是一项便捷的功能,用于快速合并来自不同探索的数据,而无需在 LookML 中进行开发。合并的结果有效地在主查询和次要查询之间执行左联接,这意味着字段名称、匹配值和最终结果表取决于次要查询中的数据与主要查询的匹配方式。

在探索之间执行合并时,这可能会导致意外的结果。合并结果文档解决了其中的一些情况,例如:

但是,如果您预期次要查询的值与主要查询中的值匹配,但最终结果显示 null 值,该怎么办?

本页介绍了如何对这种意外结果进行问题排查。

用例示例

以下示例用例基于一个包含用户和订单信息的示例电子商务数据集。在本例中,您希望将一个查询(按城市划分的用户数,即每个城市的用户数(按用户城市分组的用户数)与次要查询合并,即按用户城市和用户状态分组的订单数(订单数))与次要查询进行合并:

主要查询

主要查询是按“用户城市”分组的“用户数”:

探索显示主要查询结果的合并结果数据表。

次要查询

次要查询是按“用户城市”和“用户状态”分组的“订单数”:

探索显示次要查询结果的合并结果数据表。

合并规则设置为按“用户城市”合并这两个查询,该字段为两个查询的通用字段。熟悉之前链接的文档所介绍的数据集和预期的合并结果行为,您知道在每行中,每个城市都应该与州/省级行政区和用户计数相匹配。您希望合并的结果与所有值匹配,且不显示 null 值。

不过,结果中有 null 值。超过一半的城市与州或订单数不匹配:

显示次要查询字段的 null 值的合并结果数据表。

解决方案

不必担心。如果您确定数据中存在匹配的值(请尝试运行单独的查询来确认情况确实如此),可通过以下几种解决方案来解决此问题,包括:

  • 以相同的方式对每个源查询进行排序。
  • 提高源查询的行数上限。

以相同的方式对每个源查询进行排序

由于合并的结果基于探索,而探索的默认行限制为 500 行,因此有时合并的查询结果不会包含在最终结果中。

要解决此问题,您可以对各个来源查询进行修改排序,以便更好地相互匹配。 

在示例用例中,主要查询按 Users City(用户城市)升序排序。而次要查询则不然。为了更好地匹配这两个查询的结果,您可以采用与主要查询相同的方式对次要查询排序,在本例中,按用户所在城市的升序排序。

按照与主查询类似的方式对次要查询进行排序,可以在最终合并中更准确地匹配结果:

合并结果数据表,显示主要和次要查询字段的非 null 值。

提高源查询的行数上限

与之前介绍的第一种解决方案类似,意外的 null 值可能是由于源查询中设置的行数限制所致。具体而言,在此示例中,次要查询(默认限制为 500 行)没有足够的行来匹配主要查询生成的所有行,导致在最终合并中显示 null 结果。

如需增加次要查询中与主查询匹配的行数,您可以提高次要查询的行数上限。这样一来,与主要查询匹配的行可能会更多,而次要查询列中的 null 值也会减少:

合并结果数据表,显示主要和次要查询字段的非 null 值。

摘要

如果遇到意外的合并结果,您可以按照以下步骤进行问题排查:

  1. 从“探索”的齿轮菜单中选择清除缓存并刷新选项,以确保查询提取最新结果。
  2. 确认显示 null 值的源查询之间存在匹配值,如“合并结果”文档的如果一个查询没有匹配的数据值,该怎么办?部分中所述。
  3. 对来源查询进行排序,以便更好地相互匹配。
  4. 提高来源查询的行数上限,使其超出默认值,以公开更多可匹配和合并的行。
  5. 如果此处讨论的所有解决方案都无法解决该行为,请尽可能将join逻辑硬编码到 LookML 中,以获取更精确的结果。