자주 묻는 질문

출력 행 제한을 무시하려면 쿼리에 "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 참조 설명서를 참조하세요.

"스키마 유효성 검사 오류" 메시지는 시스템이 스키마 내에서 필드를 찾을 수 없음을 의미합니다. Query Service에서 데이터 자산 구성에 대한 모범 사례 문서 다음에 Select 설명서로 테이블 만들기를 읽어야 합니다.

다음 예에서는 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

먼저 로그를 확인하여 오류의 세부 사항을 확인합니다. 로그 내에서 오류 찾기에 대한 FAQ 섹션에서 이 작업을 수행하는 방법에 대한 자세한 정보를 제공합니다.

또한 UI에서 예약된 쿼리 및 API를 통해 수행하는 방법에 대한 지침을 보려면 설명서를 확인해야 합니다.

Query Editor을(를) 사용할 때는 이미 만들어져 저장된 쿼리에만 일정을 추가할 수 있습니다. Query Service API에는 적용되지 않습니다.

0개의 행을 반환하는 쿼리를 실행하여 응답에서 메타데이터만 가져올 수 있습니다. 이 예제 쿼리는 지정된 테이블에 대한 메타데이터만 반환합니다.

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는 특정 타임스탬프를 UTC 형식으로 변환하는 기본 제공 SQL 함수를 지원합니다. to_utc_timestamp() 및 from_utc_timestamp() 메서드는 모두 timestamp와 timezone의 두 매개 변수를 사용합니다.

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분입니다. 변수로 통과한 서울 시간대가 현지 시간대보다 9시간 앞선다.

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

쿼리는 매개 변수로 전달된 시간대에 대해 타임스탬프를 UTC 형식으로 반환합니다. 결과는 쿼리를 실행한 시간대보다 9시간 빠릅니다.

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 IN을(를) 사용하는 대신 NOT EXISTS 또는 LEFT OUTER JOIN을(를) 사용할 수 있습니다.

예를 들어 다음 테이블을 만든 경우:

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

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');

시스템이 쿼리 서비스에 연결되면 대화형 또는 일괄 처리 엔진에 연결됩니다. 이로 인해 처리된 데이터를 반영하기 위해 로드 시간이 길어질 수 있습니다.

대시보드의 응답 시간을 향상시키려면 Query Service와 BI 도구 간에 Business Intelligence(BI) 서버를 캐싱 레이어로 구현해야 합니다. 일반적으로 대부분의 BI 도구에는 서버를 위한 추가 기능이 있습니다.

캐시 서버 계층을 추가하는 목적은 쿼리 서비스의 데이터를 캐시하고 대시보드에 활용하여 응답 속도를 높이는 것입니다. 이는 실행되는 쿼리의 결과가 매일 BI 서버에서 캐시되기 때문에 가능합니다. 그런 다음 캐싱 서버는 동일한 쿼리가 있는 모든 사용자에 대해 이러한 결과를 제공하여 지연을 줄입니다. 이 설정에 대한 자세한 내용은 사용 중인 유틸리티 또는 서드파티 도구의 설명서를 참조하십시오.

history_meta() 메서드는 데이터 집합에서 스냅숏에 액세스하는 데 사용됩니다. 이전에는 Azure 데이터 레이크 저장소(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.