常見問答

若要略過輸出列限制，請在查詢中套用「LIMIT 0」。 例如：

SELECT * FROM customers LIMIT 0;

如果查詢逾時，建議使用下列一或多個解決方案。

• 將查詢轉換為CTAS查詢並排程執行。 排程執行可透過UI🔗或API完成。
• 套用其他篩選條件，對較小的資料區塊執行查詢。
• 執行EXPLAIN命令以收集更多詳細資料。
• 檢閱資料集中的資料統計資料。
• 將查詢轉換為簡化的表單，並使用準備的陳述式重新執行。

下列步驟說明如何透過UI顯示資料集的表格檢視，包括平面化表單中的所有巢狀欄位和欄。

• 登入Experience Platform後，請在UI的左側導覽中選取​ 資料集 ​以導覽至資料集儀表板。
• 資料集瀏覽索引標籤開啟。 您可以使用搜尋列來調整可用選項。 從顯示的清單中選取資料集。

• 資料集活動畫面會出現。 選取​ 預覽資料集 ​以開啟XDM結構描述的對話方塊，以及所選資料集中平面化資料的表格檢視。 如需詳細資訊，請參閱預覽資料集檔案

• 從結構描述中選取任何欄位，以在平面化欄中顯示其內容。 欄的名稱會顯示在頁面右側其內容的上方。 您應該複製此名稱以用來查詢此資料集。

請參閱檔案，以取得有關如何使用查詢編輯器或協力廠商使用者端處理巢狀資料結構的完整指引。

如果查詢在非常小的資料集上花費了很長的時間，請聯絡客戶支援。

查詢在處理期間卡住的原因不勝列舉。 若要判斷確切原因，需要逐案進行深入分析。 連絡Adobe客戶支援以成為此程式。

Adobe客戶支援電話號碼的完整清單可在Adobe說明頁面上取得。 或者，您也可以完成下列步驟，線上上取得說明：

• 在網頁瀏覽器中導覽至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

Query Service支援內建的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陳述式並賦予資料集唯讀存取權。 此外，指派管理查詢許可權。
• 使用SELECT/INSERT/CREATE陳述式，並賦予資料集寫入許可權。 此外，指派查詢管理許可權。
• 使用具有上述建議的整合帳戶，並指派查詢整合許可權。

是。 資料可從查詢服務中擷取，也可選擇透過SQL命令將結果儲存為CSV格式。

使用PSQL使用者端時，有兩種方式可儲存查詢的結果。 您可以使用COPY TO命令，或使用下列格式建立陳述式：

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

在SQL語法參考檔案中可找到COPY TO命令的使用指南。

此問題的常見原因是查詢沒有時間篩選的時間序列資料。 例如：

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)伺服器，作為Query Service和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.