이 페이지는 Looker에서 Explore를 만들기 위해 LookML을 사용하려고 하는 사용자를 위해 작성되었습니다. SQL에 능숙하다면, 특히 내부 조인과 외부 조인의 차이를 이해하면 페이지를 더 쉽게 이해할 수 있습니다. 내부 조인과 외부 조인의 차이점에 대한 간략한 설명은 SQL 조인에 관한 w3schools 문서를 참조하세요.
Looker는 회사의 강력한 SQL 엔진이 될 수 있습니다. LookML의 추상 모델링을 사용하면 데이터 팀과 IT 팀이 항상 진실인 일반 규칙을 세울 수 있으며, 비즈니스 분석가는 데이터 팀이 필요성을 예상하지 못했더라도 항상 옳은 조건으로 쿼리를 작성할 수 있습니다. 이 기능의 핵심 동인은 대칭 집계 알고리즘으로, SQL 조인으로 업계 전반의 문제를 해결합니다. 그러나 알고리즘을 활용하려면 두 가지를 올바르게 실행해야 합니다. 기본 키는 측정이 포함된 모든 뷰(일반적으로 모두)에서 정확해야 하며 relationship 매개변수는 모든 조인에서 정확해야 합니다.
기본 키
어떤 식으로든 테이블의 기본 키를 이해하는 것은 기본적으로 테이블의 정의와 수행 가능한 작업을 이해하는 것과 같습니다. 반드시 기본 키로 선택한 열(또는 연결된 열 조합)에 반복되는 값이 없어야 합니다.
relationship 매개변수
이제 기본 키를 인증했으므로 조인의 relationship 매개변수에 올바른 값을 결정할 수 있습니다. relationship 매개변수의 목적은 조인이 SQL 쿼리에 작성될 때 대칭 집계를 호출할지 여부를 Looker에 알리는 것입니다. 여기에서 가능한 접근 방식은 Looker가 항상 이 함수를 호출하도록 하여 항상 정확한 결과를 얻도록 하는 것입니다. 그러나 이 경우 성능 비용이 발생하므로 대칭 집계를 신중하게 사용하는 것이 좋습니다.
올바른 값을 확인하는 프로세스는 내부 조인과 외부 조인 간에 약간 다릅니다.
내부 조인
예를 들어 기본 키가 order_id인 주문 테이블이 있다고 가정해 보겠습니다.
| order_id | amount | customer_id |
|---|---|---|
| 1 | $25.00 | 1 |
| 2 | $50.00 | 1 |
| 3 | $75.00 | 2 |
| 4 | $35.00 | 3 |
또한 기본 키가 customer_id인 고객 테이블이 있다고 가정해 보겠습니다.
| customer_id | 이름 | 성 | 방문 수 |
|---|---|---|---|
| 1 | Amelia | Earhart | 2 |
| 2 | Bessie | Coleman | 2 |
| 3 | Wilbur | Wright | 4 |
두 테이블 모두에 있는 customer_id 필드에서 이러한 테이블을 조인할 수 있습니다. 이 조인은 LookML에서 다음과 같이 표현됩니다.
explore: orders {
join: customers {
type: inner
sql_on: ${orders.customer_id} = ${customers.customer_id} ;;
relationship: many_to_one
}
}
이 LookML 조인의 결과는 다음과 같이 하나의 조인된 테이블로 표시할 수 있습니다.
| order_id | amount | customer_id | customer_id | 이름 | 성 | 방문 수 |
|---|---|---|---|---|---|---|
| 1 | $25.00 | 1 | 1 | Amelia | Earhart | 2 |
| 2 | $50.00 | 1 | 1 | Amelia | Earhart | 2 |
| 3 | $75.00 | 2 | 2 | Bessie | Coleman | 2 |
| 4 | $35.00 | 3 | 3 | Wilbur | Wright | 4 |
여기에서 many_to_one 관계는 각 테이블에서 조인 필드(customer_id)의 값 하나가 표시되는 횟수를 나타냅니다. orders 테이블(왼쪽 테이블)에서 단일 고객 ID는 여러 번 표시됩니다(이 경우 여러 행에 있는 ID가 1인 고객).
customers 테이블(오른쪽 테이블)에서 customer_id는 해당 테이블의 기본 키이므로 모든 고객 ID가 한 번만 표시됩니다. 따라서 orders 테이블의 레코드에 customers 테이블의 단일 값에 대한 많은 일치 항목이 있을 수 있습니다. customer_id가 customers 테이블의 모든 행에서 고유하지 않으면 관계는 many_to_many이 됩니다.
기본 키를 확인하여 프로그래매틱 방식으로 올바른 관계 값을 확인하려면 다음 단계를 따르세요.
- 먼저
many_to_many를 관계로 작성합니다. 기본 키가 올바르면 Looker가 항상 대칭 집계 알고리즘을 트리거하고 정확성을 적용하기 때문에 항상 정확한 결과가 생성됩니다. 그러나 알고리즘은 쿼리를 복잡하게 만들고 실행 시간을 추가하기 때문에 한쪽 또는 양쪽을many대신one으로 변경하는 것이 좋습니다. - 왼쪽 테이블에서
sql_on절에 있는 필드를 확인합니다. 하나 이상의 필드가 왼쪽 테이블의 기본 키를 형성하는 경우relationship매개변수의 왼쪽을one으로 변경할 수 있습니다. 그렇지 않은 경우 일반적으로many로 유지되어야 합니다. (특수 케이스에 대한 자세한 내용은 이 페이지의 뒷부분에 있는 고려사항 섹션을 참조하세요.) - 다음으로
sql_on절에서 오른쪽 테이블을 나타내는 필드를 살펴보겠습니다. 하나 이상의 필드가 오른쪽 테이블의 기본 키를 형성하는 경우 오른쪽을one으로 변경할 수 있습니다.
등호 왼쪽에 표시되는 왼쪽 테이블과 오른쪽에 있는 오른쪽 테이블로 시작하는 sql_on 구문을 작성하는 것이 좋습니다. sql_on 매개변수의 조건 순서는 데이터베이스의 SQL 언어와 관련이 없는 경우 중요하지 않습니다. sql_on 매개변수의 경우 이 방법으로 필드를 정렬할 필요는 없지만 등호의 왼쪽과 오른쪽이 relationship 매개변수를 왼쪽에서 오른쪽으로 읽는 방식과 일치하도록 sql_on 조건을 정렬하면 관계를 결정하는 데 도움이 됩니다. 또한 이 방법으로 필드를 정렬하면 Explore에서 새 테이블을 조인할 기존 테이블을 한눈에 쉽게 식별할 수 있습니다.
외부 조인
외부 조인의 경우, 조인 중에 null 레코드가 추가될 때 팬아웃이 발생할 수 있다는 사실도 고려해야 합니다. Looker에서 왼쪽 외부 조인이 기본값이므로 특히 중요합니다. null 레코드는 합계 또는 평균에 영향을 미치지 않지만 Looker에서 type: count의 측정을 실행하는 방식에 영향을 미칩니다. 이 작업을 잘못 수행하면 null 레코드가 계산됩니다(바람직하지 않음).
전체 외부 조인에서 조인 키에 다른 테이블에 있는 값이 누락된 경우 각 테이블에 null 레코드를 추가할 수 있습니다. 이 내용은 orders 테이블이 포함된 다음 예시에서 확인할 수 있습니다.
| order_id | amount | customer_id |
|---|---|---|
| 1 | $25.00 | 1 |
| 2 | $50.00 | 1 |
| 3 | $75.00 | 2 |
| 4 | $35.00 | 3 |
예를 들어 다음 customers 테이블도 있다고 가정해 보겠습니다.
| customer_id | 이름 | 성 | 방문 수 |
|---|---|---|---|
| 1 | Amelia | Earhart | 2 |
| 2 | Bessie | Coleman | 2 |
| 3 | Wilbur | Wright | 4 |
| 4 | Charles | Yeager | 3 |
이러한 테이블이 조인되면 조인된 테이블은 다음과 같이 표시될 수 있습니다.
| order_id | amount | customer_id | customer_id | 이름 | 성 | 방문 수 |
|---|---|---|---|---|---|---|
| 1 | $25.00 | 1 | 1 | Amelia | Earhart | 2 |
| 2 | $50.00 | 1 | 1 | Amelia | Earhart | 2 |
| 3 | $75.00 | 2 | 2 | Bessie | Coleman | 2 |
| 4 | $35.00 | 3 | 3 | Wilbur | Wright | 4 |
| null | null | null | 4 | Charles | Yeager | 3 |
내부 조인과 마찬가지로 테이블의 기본 키 간의 관계는 many_to_one입니다. 하지만 추가된 null 레코드는 왼쪽 테이블에도 대칭 집계가 필요합니다. 따라서 이 조인을 수행하면 왼쪽 테이블의 카운트가 중단되므로 relationship 매개변수를 many_to_many로 변경해야 합니다.
이 예시가 왼쪽 외부 조인인 경우 null 행이 추가되지 않고 추가 고객 레코드가 삭제되었습니다. 이 경우에도 관계는 many_to_one이 됩니다. 이는 기본 테이블이 분석을 정의한다고 가정하므로 Looker 기본값입니다. 이 경우 고객이 아닌 주문을 분석합니다. 고객 테이블이 왼쪽에 있으면 상황이 달라집니다.
다단계 조인
일부 Explore에서는 기본 테이블이 하나 이상의 뷰에 조인되며, 결과적으로 하나 이상의 추가 뷰에 조인되어야 합니다. 이 예시에서는 테이블이 고객 테이블에 조인된다는 것을 의미합니다. 이러한 상황에서는 relationship 매개변수를 평가할 때 작성 중인 개별 조인만 살펴보는 것이 가장 좋습니다. 영향을 받는 뷰가 실제로 팬아웃을 만든 조인에 없는 경우에도 Looker는 다운스트림 팬아웃이 쿼리에 영향을 미치는 시점을 파악합니다.
Looker를 어떻게 활용할 수 있나요?
Looker에는 관계 값이 올바른지 확인하는 메커니즘이 있습니다. 하나는 기본 키 고유성을 확인하는 것입니다. 측정을 계산하기 위해 팬아웃 및 대칭 집계가 필요할 때마다 Looker는 사용된 기본 키의 고유성을 확인합니다. 고유하지 않은 경우 쿼리 실행 시 오류가 표시됩니다(이 경우 LookML 검사기 오류가 없음).
또한 Looker가 팬아웃을 처리할 방법이 없는 경우(일반적으로 기본 키가 표시되지 않는 경우), 해당 뷰에 있는 Explore에 측정 항목이 표시되지 않습니다. 이 문제를 해결하려면 필드를 기본 키로 지정하여 Explore로 이동할 수 있습니다.
고려사항
대칭 집계를 위한 언어 지원
Looker는 대칭 집계를 지원하지 않는 일부 언어와 연결할 수 있습니다. symmetric_aggregates 문서 페이지에서 언어 목록 및 대칭 집계 지원 목록을 확인할 수 있습니다.
예외 상황
이 페이지 앞부분의 내부 조인 섹션에서 올바른 관계 값을 판단하려면 왼쪽 테이블의 sql_on 절에 있는 필드 중 하나를 확인해야 합니다. '하나 이상의 필드가 왼쪽 테이블의 기본 키를 형성하는 경우 relationship 매개변수의 왼쪽을 one으로 변경할 수 있습니다. 그렇지 않은 경우 일반적으로 many로 유지되어야 합니다.'라는 메시지가 표시되는데, 이는 테이블에 반복 레코드가 없는 열이 여러 개 있는 경우에 한합니다. 이 경우 primary_key: yes 열이 지정된 열이 아니더라도 관계를 설정할 때 이러한 열을 기본 키처럼 취급할 수 있습니다.
이전 단락의 문이 지정된 열에 대해 항상 참이 되도록 소프트웨어 규칙을 마련하면 편리합니다. 그렇다면 이대로 처리하고 다른 사용자가 나중에 참조할 수 있도록 뷰 파일에 특별한 속성을 기록해 둡니다. SQL Runner 링크를 사용하여 이를 증명합니다. 하지만 필드가 기본 키로 지정되면 Looker에서 암시적 고유성의 진실을 확인하지만 다른 필드에서는 그렇지 않다는 점에 유의하세요. 단순히 대칭 집계 알고리즘을 호출하지 않습니다.