常见问题解答

要绕过输出行限制，请在查询中应用“LIMIT 0”。 例如：

SELECT * FROM customers LIMIT 0;

如果查询超时，建议使用以下一个或多个解决方案。

• 将查询转换为CTAS查询并计划运行。 可以通过通过UI或API计划运行。
• 通过应用额外的筛选条件，对较小的数据区块执行查询。
• 执行EXPLAIN命令以收集更多详细信息。
• 查看数据集内数据的统计信息。
• 将查询转换为简化形式，然后使用准备好的语句重新运行。

以下步骤描述了如何通过UI显示数据集的表格视图，包括拼合表单中的所有嵌套字段和列。

• 登录Experience Platform后，在UI的左侧导航中选择​ 数据集 ​以导航到数据集仪表板。
• 数据集浏览选项卡打开。 您可以使用搜索栏来优化可用选项。 从显示的列表中选择数据集。

• 将显示数据集活动屏幕。 选择​ 预览数据集 ​以打开XDM架构的对话框和选定数据集中拼合数据的表格视图。 有关更多详细信息，请参阅预览数据集文档

• 从架构中选择任意字段以在拼合列中显示其内容。 列的名称显示在页面右侧其内容的上方。 您应该复制此名称以用于查询此数据集。

请参阅文档，了解有关如何使用查询编辑器或第三方客户端处理嵌套数据结构的完整指南。

如果查询在非常小的数据集上花费了很长时间，请联系客户支持。

查询在处理过程中可能卡住的原因有很多。 要确定确切的原因，需要逐案进行深入分析。 联系Adobe客户支持以成为此流程。

Adobe客户支持电话号码的完整列表可在Adobe帮助页面上找到。 或者，可通过完成以下步骤在线查找帮助：

• 在Web浏览器中导航到https://www.adobe.com/。
• 选择顶部导航栏右侧的​ 登录。

• 使用已在您的Adobe许可证中注册的Adobe ID和密码。
• 从顶部导航栏中选择​ 帮助和支持。

此时会出现一个下拉横幅，其中包含帮助和支持部分。 选择​ 联系我们 ​以打开Adobe客户关怀虚拟助手，或选择​ 企业支持 ​以获得大型组织的专用帮助。

匿名块功能允许您链接一个或多个按顺序执行的SQL语句。 它们还允许使用例外处理选项。

有关详细信息，请参阅匿名块文档。

有两种方法可以实施自定义归因：

1. 使用现有Adobe定义的函数的组合来确定是否满足用例需求。
2. 如果前面的建议不满足您的使用案例，则您应使用窗口函数的组合。 窗口函数查看一个序列中的所有事件。 还允许您查看历史数据，并且可以任意组合使用。

要检索特定查询的错误日志，您必须首先使用查询服务API获取查询日志详细信息。 HTTP响应包含调查查询错误所需的查询ID。

使用GET命令检索多个查询。 有关如何调用API的信息可在示例API调用文档中找到。

从响应中，确定要调查的查询，并使用其id值发出另一个GET请求。 可以在按ID检索查询中找到完整说明。

成功的响应返回HTTP状态200并包含errors数组。 为简短起见，已缩短答复。

{
    "isInsertInto": false,
    "request": {
                "dbName": "prod:all",
                "sql": "SELECT *\nFROM\n  accounts\nLIMIT 10\n"
            },
    "clientId": "8c2455819a624534bb665c43c3759877",
    "state": "SUCCESS",
    "rowCount": 0,
    "errors": [{
      'code': '58000',
      'message': 'Batch query execution gets : [failed reason ErrorCode: 58000 Batch query execution gets : [Analysis error encountered. Reason: [sessionId: f055dc73-1fbd-4c9c-8645-efa609da0a7b Function [varchar] not defined.]]]',
      'errorType': 'USER_ERROR'
      }],
    "isCTAS": false,
    "version": 1,
    "id": "343388b0-e0dd-4227-a75b-7fc945ef408a",
}

查询服务API参考文档提供了有关所有可用端点的详细信息。

“验证架构时出错”消息意味着系统无法找到架构中的字段。 您应该阅读在查询服务中组织数据资产的最佳实践文档，然后阅读创建表作为选择文档。

以下示例演示了CTAS语法和结构数据类型的使用：

CREATE TABLE table_name WITH (SCHEMA='schema_name')

AS SELECT '1' as _id,

 STRUCT

  ('2021-02-17T15:39:29.0Z' AS taskActualCompletionDate,

    '2020-09-09T21:21:16.0Z' AS taskActualStartDate,

    'Consulting' AS taskdescription,

    '5f6527c10011e09b89666c52d9a8c564' AS taskguide,

    'Stakeholder Consulting Engagement' AS taskname,

    '2020-09-09T15:00:00.0Z' AS taskPlannedStartDate,

    '2021-02-15T11:00:00.0Z' AS taskPlannedCompletionDate

  ) AS _workfront ;

配置文件操控板中显示的数字自上次快照以来是准确的。 配置文件导出表中生成的数字完全取决于导出查询。 因此，查询符合特定受众资格的用户档案数量是造成这种差异的常见原因。

最可能的原因是查询的范围太窄。 在开始看到某些数据之前，您应该系统地删除WHERE子句的一个部分。

您还可以使用小型查询来确认您的数据集包含数据，例如：

SELECT count(1) FROM myTableName

首先，检查日志以了解错误的详细信息。 有关在日志中查找错误的常见问题解答部分提供了有关如何执行此操作的更多信息。

您还应该查看文档以了解有关如何在UI🔗中以及通过API执行计划查询的指导。

请注意，使用Query Editor时，您只能向已创建并保存的查询添加计划。 这不适用于Query Service API。

您可以运行返回零行的查询，以仅获取响应中的元数据。 此示例查询仅返回指定表的元数据。

SELECT * FROM <table> WHERE 1=0

您可以创建临时表，以便在具体化查询以供使用之前对其进行快速迭代和试验。 还可以使用临时表来验证查询是否有效。

例如，您可以创建一个临时表：

CREATE temp TABLE temp_dataset AS
SELECT *
FROM actual_dataset
WHERE 1 = 0;

然后可以使用临时表，如下所示：

INSERT INTO temp_dataset
SELECT a._company AS _company,
a._id AS _id,
a.timestamp AS timestamp
FROM actual_dataset a
WHERE timestamp >= TO_TIMESTAMP('2021-01-21 12:00:00')
AND timestamp < TO_TIMESTAMP('2021-01-21 13:00:00')
LIMIT 100;

Adobe Experience Platform以UTC（协调世界时）时间戳格式保留数据。 UTC格式的示例为2021-12-22T19:52:05Z

查询服务支持内置SQL函数，以将给定时间戳转换为UTC格式或从UTC格式转换给定时间戳。 to_utc_timestamp()和from_utc_timestamp()方法都采用两个参数：时间戳和时区。

转换为UTC时间戳

to_utc_timestamp()方法解释给定参数并将其​ 以UTC格式转换为本地时区 ​的时间戳。 例如，韩国首尔的时区是UTC/GMT +9小时。 通过提供仅用于日期的时间戳，该方法使用上午午夜的默认值。 时间戳和时区会转换为UTC格式，从该区域的时间转换为您本地区域的UTC时间戳。

SELECT to_utc_timestamp('2021-08-31', 'Asia/Seoul');

查询会返回以用户的本地时间表示的时间戳。 在这个例子中，前一天下午3点，首尔提前了9个小时。

2021-08-30 15:00:00

作为另一个示例，如果给定时间戳为Asia/Seoul时区的2021-07-14 12:40:00.0，则返回的UTC时间戳为2021-07-14 03:40:00.0

查询服务UI中提供的控制台输出是更易于用户识别的格式：

8/30/2021, 3:00 PM

从UTC时间戳转换

from_utc_timestamp()方法从本地时区​ 的时间戳中解释给定参数，并以UTC格式提供所需区域的等效时间戳。 在下面的示例中，小时是用户本地时区的下午2:40。 作为变量传递的首尔时区比当地时区早九小时。

SELECT from_utc_timestamp('2021-08-31 14:40:00.0', 'Asia/Seoul');

查询会返回作为参数传递的时区的时间戳（UTC格式）。 结果比运行查询的时区早九小时。

8/31/2021, 11:40 PM

如何过滤时间序列数据？

SELECT a._company  AS _company,
       a._id       AS _id,
       a.timestamp AS timestamp
FROM   dataset a
WHERE  timestamp >= To_timestamp('2021-01-21 12:00:00')
       AND timestamp < To_timestamp('2021-01-21 13:00:00')

使用CAST运算符转换时间戳时，需要同时包含日期​ 和 ​时间。

例如，缺少时间组件（如下所示）将导致错误：

SELECT * FROM ABC
WHERE timestamp = CAST('07-29-2021' AS timestamp)

CAST运算符的正确用法如下所示：

SELECT * FROM ABC
WHERE timestamp = CAST('07-29-2021 00:00:00' AS timestamp)

NOT IN运算符通常用于检索在另一个表或SQL语句中找不到的行。 此运算符可能会降低性能，如果进行比较的列接受NOT NULL，或者您有大量记录，则可能会返回意外结果。

您可以使用NOT EXISTS或LEFT OUTER JOIN，而不是使用NOT IN。

例如，如果您创建了以下表：

CREATE TABLE T1 (ID INT)
CREATE TABLE T2 (ID INT)
INSERT INTO T1 VALUES (1)
INSERT INTO T1 VALUES (2)
INSERT INTO T1 VALUES (3)
INSERT INTO T2 VALUES (1)
INSERT INTO T2 VALUES (2)

如果您使用NOT EXISTS运算符，则可以使用以下查询使用NOT IN运算符进行复制：

SELECT ID FROM T1
WHERE NOT EXISTS
(SELECT ID FROM T2 WHERE T1.ID = T2.ID)

或者，如果您使用LEFT OUTER JOIN运算符，则可以使用以下查询使用NOT IN运算符进行复制：

SELECT T1.ID FROM T1
LEFT OUTER JOIN T2 ON T1.ID = T2.ID
WHERE T2.ID IS NULL

系统没有索引，因为它不是数据库，但它具有绑定到数据存储的其他优化。 以下选项可用于调整查询：

• 基于时间系列数据的过滤器。
• 已针对结构数据类型优化向下推送。
• 优化了阵列和映射数据类型的成本和内存下推功能。
• 使用快照进行增量处理。
• 持久数据格式。

限制访问的方法有三种。 具体如下：

• 使用SELECT only语句并赋予数据集只读访问权限。 此外，分配管理查询权限。
• 使用SELECT/INSERT/CREATE语句并赋予数据集写入权限。 此外，分配查询管理权限。
• 使用具有上述建议的集成帐户，并分配查询集成权限。

是的。 数据可以从查询服务中提取，并且还可以选择通过SQL命令以CSV格式存储结果。

使用PSQL客户端时，有两种方式可保存查询结果。 您可以使用COPY TO命令或使用以下格式创建语句：

SELECT column1, column2
FROM <table_name>
\g <table_name>.out

有关使用COPY TO命令的指导可以在SQL语法参考文档中找到。

此问题的常见原因是查询时间序列数据时没有时间过滤器。 例如：

SELECT * FROM prod_table LIMIT 1;

应写为：

SELECT * FROM prod_table
WHERE
timestamp >= to_timestamp('2022-07-22')
and timestamp < to_timestamp('2022-07-23');

当系统连接到查询服务时，它会连接到交互式或批处理引擎。 这可能会导致加载时间较长以反映处理过的数据。

如果要缩短功能板的响应时间，应实施Business Intelligence(BI)服务器作为查询服务和BI工具之间的缓存层。 通常，大多数BI工具都为服务器提供了附加服务。

添加缓存服务器层的目的是缓存来自查询服务的数据，并利用该缓存服务让仪表板加快响应。 这是可能的，因为执行的查询的结果每天都会缓存在BI服务器中。 然后，缓存服务器会为具有相同查询的任何用户提供这些结果，以减少延迟。 有关此类设置的说明，请参阅您所使用的实用程序或第三方工具的文档。

history_meta()方法用于访问数据集中的快照。 以前，如果您对Azure Data Lake Storage (ADLS)中的空数据集运行查询，您将收到一个58000错误代码，指出该数据集不存在。 下面显示了旧系统错误的示例。

ErrorCode: 58000 Internal System Error [Invalid table your_table_name. historyMeta can be used on datalake tables only.]

出现此错误是因为查询没有返回值。 此行为现已修复为返回以下消息：

Query complete in {timeframe}. 0 rows returned.