GSP1020

개요

Looker는 대화식으로 데이터를 분석하고 시각화하는 데 사용할 수 있는 Google Cloud의 최신 데이터 플랫폼입니다. LookML 개발자는 새 필드, 테이블, 뷰, Explore를 만들어 데이터 워크플로를 맞춤설정하고 정리함으로써 비즈니스 사용자가 사용하는 데이터를 선별하고 커스텀 데이터 애플리케이션을 제작합니다.

이 실습에서는 비즈니스 사용자와 개발자의 환경을 모두 개선하는 LookML 코드 작성 권장사항을 알아봅니다. 대표적인 권장사항은 기존 객체를 재사용하고 설명이 포함된 이름 지정 규칙을 적용하여 LookML 프로젝트의 사용성과 지속 가능성을 개선하는 것입니다. 또한 LookML 파라미터를 사용하여 추가 컨텍스트를 제공하고 비즈니스 사용자에게 표시되는 객체를 맞춤설정하여 Explore의 사용성을 개선할 수도 있습니다.

기본 요건

LookML에 대한 기본적인 이해가 필요합니다. 이 실습을 시작하기 전에 Looker의 LookML 이해 과정을 완료하는 것이 좋습니다.

실습할 내용

• 설명이 포함된 필드 이름을 사용하여 측정기준과 측정을 정의합니다.
• 추가 파라미터를 활용하여 데이터를 정리하고 데이터에 대한 컨텍스트를 더 많이 제공합니다.
• 최대한 적은 수의 필드와 Explore를 만들어 표시합니다.
• 쉽게 업데이트하고, 유지관리하고, 재사용할 수 있는 지속 가능한 모듈식 LookML 코드를 작성합니다.

설정 및 요건

실습 시작 버튼을 클릭하기 전에

다음 안내를 확인하세요. 실습에는 시간 제한이 있으며 일시중지할 수 없습니다. 실습 시작을 클릭하면 타이머가 시작됩니다. 이 타이머는 Google Cloud 리소스를 사용할 수 있는 시간이 얼마나 남았는지를 표시합니다.

실무형 실습을 통해 시뮬레이션이나 데모 환경이 아닌 실제 클라우드 환경에서 직접 실습 활동을 진행할 수 있습니다. 실습 시간 동안 Google Cloud에 로그인하고 액세스하는 데 사용할 수 있는 새로운 임시 사용자 인증 정보가 제공됩니다.

이 실습을 완료하려면 다음을 준비해야 합니다.

• 표준 인터넷 브라우저 액세스 권한(Chrome 브라우저 권장)

참고: 이 실습을 실행하려면 시크릿 모드 또는 시크릿 브라우저 창을 사용하세요. 개인 계정과 학습자 계정 간의 충돌로 개인 계정에 추가 요금이 발생하는 일을 방지해 줍니다.

• 실습을 완료하기에 충분한 시간(실습을 시작하고 나면 일시중지할 수 없음)

참고: 계정에 추가 요금이 발생하지 않도록 하려면 개인용 Google Cloud 계정이나 프로젝트가 이미 있어도 이 실습에서는 사용하지 마세요.

실습을 시작하고 Looker에 로그인하는 방법

1. 준비가 되면 실습 시작을 클릭합니다.

   이 실습에서 사용해야 하는 임시 사용자 인증 정보가 '실습 세부정보' 창에 표시됩니다.

   실습 비용을 결제해야 하는 경우 결제 수단을 선택할 수 있는 팝업이 열립니다.

   '실습 세부정보' 창에 표시된 실습 사용자 인증 정보를 확인합니다. 이 실습에서 Looker 인스턴스에 로그인할 때 이 정보를 사용합니다.

   참고: 다른 사용자 인증 정보를 사용하면 오류가 발생하거나 요금이 부과됩니다.

2. Looker 열기를 클릭합니다.

3. 제공된 사용자 이름과 비밀번호를 이메일 및 비밀번호 입력란에 입력합니다.

   사용자 이름:

   {{{looker.developer_username | Username}}}

   비밀번호:

   {{{looker.developer_password | Password}}} 중요: 이 페이지의 '실습 세부정보' 창에 표시된 사용자 인증 정보를 사용해야 합니다. Google Cloud Skills Boost 사용자 인증 정보를 사용하지 마세요. 개인용 Looker 계정이 있더라도 이 실습에 사용하지 마세요.

4. 로그인을 클릭합니다.

   로그인이 완료되면 이 실습에서 사용할 Looker 인스턴스가 표시됩니다.

LookML 코드 작성 권장사항

이 섹션에서는 비즈니스 사용자와 개발자의 환경을 모두 개선하는 LookML 코드 작성에 적용할 수 있는 상위 5가지 권장사항을 간략하게 설명합니다. 이 실습에서는 처음 네 가지 항목을 중점적으로 살펴봅니다.

설명이 포함된 필드 이름 사용

설명이 포함된 필드 이름을 사용하여 측정기준과 측정을 정의하면 비즈니스 사용자와 개발자 모두가 필요한 항목을 쉽게 찾을 수 있습니다(권장사항의 첫 번째 항목). 이에 해당하는 예는 다음과 같습니다.

• 관련 집계 함수나 일반적인 용어를 사용해 측정의 이름을 지정합니다(예: 합계의 경우 total_[FIELD], 개수의 경우 count_[FIELD], 평균의 경우 avg_[FIELD] 사용).
• 비율의 이름을 설명적으로 지정합니다. percent_orders_by_returning_customer가 percent_returning보다 더 알기 쉽습니다.
• yesno 필드의 이름을 알기 쉽게 지정합니다. returned 대신 order_is_returned나 is_order_returned로 지정하는 식입니다.
• 측정기준 그룹에 'date' 또는 'time'과 같은 단어를 사용하지 않습니다. Looker는 이미 측정기준 이름 끝에 각 기간을 추가하고 있습니다. 예를 들어 created_date는 created_date_date가 됩니다.

추가 파라미터 활용

추가 파라미터를 활용하면 비즈니스 사용자에게 노출되는 데이터를 정리하고 더 많은 컨텍스트를 제공할 수 있습니다. 워크플로에 사용할 필드와 Explore를 비즈니스 사용자가 쉽게 식별할 수 있도록 라벨과 설명을 포함해야 합니다(권장사항의 첫 번째 항목과 네 번째 항목).

또한 group_label 파라미터를 사용하여 유사한 필드와 Explore를 논리적 카테고리로 그룹화해 탐색 용이성을 개선해야 합니다(권장사항의 두 번째 항목).

마지막으로, drill_fields를 사용하여 데이터 탐색 중 테이블 셀 값을 클릭했을 때 비즈니스 사용자에게 표시되는 추가 옵션을 선별해야 합니다.

최대한 적은 수의 필드와 Explore를 만들어 표시

비즈니스 사용자가 필요한 답변에 쉽게 액세스할 수 있게 하면서도 필드와 Explore를 최대한 적게 만들어 표시하는 일은 대단히 유익한 권장사항입니다(권장사항의 세 번째 항목). 필드와 Explore의 최적 개수는 비즈니스마다 다르지만, 각 항목의 수가 너무 많으면 최종 사용자가 혼란스러울 수 있습니다.

fields 파라미터를 사용하여 개별 Explore에서 비즈니스 사용자에게 표시되는 필드를 제한하고, hidden 파라미터를 사용하여 전체 모델에서 필드나 Explore를 숨길 수 있습니다.

지속 가능한 모듈식 LookML 코드 작성

쉽게 업데이트하고, 유지관리하고, 재사용할 수 있는 지속 가능하고 유지관리가 용이한 LookML 코드를 작성하는 것은 기능 프로젝트 유지의 핵심 요소입니다.

기본 LookML 코드의 구성과 품질은 즉시 드러나지 않을 수 있지만 전반적인 비즈니스 사용자 경험에 영향을 미칠 수도 있습니다. 특히 LookML 개발자가 기본 코드를 작성하고 유지관리하는 시간을 줄일 수 있다면 비즈니스 사용자가 요청하는 속성과 기능을 더 빠르게 수정하거나 구현할 수 있습니다.

다음은 지속 가능한 모듈식 LookML 코드를 작성하는 몇 가지 팁입니다.

• 코드 전체에서 대체 연산자를 사용하여 기본 데이터베이스에 대한 하드 코딩된 참조를 최소화합니다.
• SQL 파생 테이블과 기본 파생 테이블에 적합한 사례를 식별합니다.
  • 기본 파생 테이블은 사용자 모델의 기존 LookML 객체를 활용하여 기본 데이터베이스에 아직 존재하지 않는 새로운 구조 또는 집계를 정의함으로써 코드 재사용성을 촉진합니다.
  • SQL 파생 테이블은 기본 파생 테이블로 쉽게 수행할 수 없는 더 맞춤화되거나 복잡한 집계에 사용됩니다.
• 확장 또는 상세검색을 사용하여 기존 뷰와 Explore를 확장합니다.
  • 뷰 또는 Explore를 확장하여 원본 객체의 사본을 만들고 수정사항을 적용할 수 있습니다. 자세한 내용과 실습은 확장을 사용하여 LookML 코드 모듈화 실습을 참조하세요.
  • 또한 기존 뷰나 Explore가 포함된 LookML 파일을 직접 수정하지 않고도 이러한 뷰나 Explore를 조정할 수 있는 상세검색을 생성할 수 있습니다. 자세한 내용과 실습은 LookML 쿼리의 성능 최적화하기 실습을 참고하세요.

Explore 쿼리 성능 최적화

비즈니스 사용자를 위해 Explore 쿼리의 성능을 최적화하려면 다음 단계를 따르세요.

• Explore에서 불필요한 뷰를 조인하지 않습니다.
• 뷰 파일에서 기본 키를 선언하고 relationship 파라미터를 사용하여 조인 관계를 정의해 올바른 집계를 생성하도록 합니다.
• 가장 세분화된 수준의 뷰에서 가장 개략적인 정보를 가진 수준의 뷰까지 연결하는 many_to_one 조인을 정의합니다.
• 실행하는 데 시간이 오래 걸리는 복잡한 쿼리 또는 다수의 사용자나 애플리케이션이 자주 사용하는 쿼리의 경우 영구 파생 테이블을 사용합니다.

이러한 주제에 대한 자세한 내용은 Looker 권장사항 및 금지사항과 LookML 쿼리의 성능 최적화하기를 참고하세요.

작업 1. 기존 필드와 설명이 포함된 이름 지정 규칙을 활용하는 필드 만들기

새 측정기준과 측정을 만들 때는 항상 모델의 기존 LookML 객체를 검토하여 재사용할 수 있는지 확인하세요. 코드 업데이트를 쉽게 진행하려면 코드 전체에서 대체 연산자를 사용하여 기본 데이터베이스의 객체에 대한 하드 코딩된 참조를 최소화하는 것이 좋습니다.

기존 객체 활용에 더해, 새 객체를 만들 때 설명이 포함된 이름을 선택하면 개발자와 비즈니스 사용자가 코드 또는 분석에 사용할 필드를 쉽게 찾을 수 있습니다. 이 작업에서는 기존 상태 측정기준을 활용하여 취소된 주문을 식별하는 새로운 yesno 측정기준을 만들고, 기존 객체를 활용하여 취소된 주문으로 인한 수익 손실 비율을 계산하는 새 측정을 만들고, 새 측정기준과 측정에 설명이 포함된 이름 지정 규칙을 적용합니다.

기존 측정기준을 활용하여 yesno 측정기준 만들기

1. 전환 버튼을 클릭하여 개발 모드로 전환합니다.

2. 개발 메뉴에서 qwiklabs_ecommerce 프로젝트를 선택합니다.

3. views에서 order_items.view를 엽니다.

4. 상태라는 이름의 측정기준을 검토합니다.

   문법은 뷰 파일 상단의 sql_table_name 파라미터에 식별된 테이블의 열을 참조하는 대체 연산자인 ${TABLE}.column_name을 사용합니다.

   이 경우 ${TABLE}.status는 cloud-training-demos.looker_ecomm.order_items 테이블 내의 상태 열을 참조합니다. 이 기존 측정기준을 활용하면 주문이 취소 상태인지를 식별하는 새 yesno 측정기준을 만들 수 있습니다.

order_is_canceled와 is_order_canceled는 설명이 포함된 이름을 사용한다는 권장사항을 준수합니다. 취소된 객체를 주문으로 명확하게 식별하기 때문입니다. 팀은 두 이름 지정 규칙 중에서 무엇을 선택할지 결정할 수 있습니다.

5. status 측정기준에 새 yesno 측정기준에 대한 다음 코드를 추가합니다.

dimension: order_is_canceled { type: yesno sql: ${status} = "" ;; }

문법은 현재 뷰 내의 기존 측정기준 또는 측정을 참조하는 대체 연산자인 ${field_name}을 사용합니다. 이 경우 ${status}는 order_items 뷰 내의 status 측정기준을 참조합니다.

또한 이 코드에는 아직 상태 값이 포함되어 있지 않습니다. 기존 상태 측정기준을 활용할 수 있지만 취소된 주문을 식별하는 데 사용되는 측정기준의 값은 반드시 알아야 합니다.

기술적으로는 이러한 모든 옵션을 사용하여 올바른 값을 식별할 수 있습니다. 하지만 이런 방식의 추측은 비효율적이며 잘못된 값을 산출할 수 있습니다. 예상한 결과가 나올 때까지 Explore에서 새 측정기준에 대한 쿼리를 실행하여 코드를 계속 테스트해야 합니다.

주문 항목 Explore의 주문 항목 뷰에서 상태 측정기준에 대해 쿼리를 실행하면 측정기준 값이 표시되지만 Explore에 표시되는 값은 LookML 코드로 적용된 추가 형식을 반영할 수 있습니다.

SQL Runner에서 order_items 테이블에 대한 쿼리를 직접 실행하면 상태 열의 원시 데이터 값을 확인할 수 있습니다.

6. IDE의 브라우저 탭은 열어 두고 새 브라우저 탭에서 새 Looker 창을 엽니다.

7. 개발 > SQL Runner로 이동합니다.

8. 연결 옆에 있는 설정()을 클릭한 다음 공개 프로젝트 검색을 클릭합니다.

9. 프로젝트에 cloud-training-demos를 입력한 후 Enter 키를 누릅니다.

10. 데이터 세트로 looker_ecomm을 선택합니다.
    이 BigQuery 데이터 세트에서 사용 가능한 테이블 목록이 표시됩니다.

11. status 열에서 고유한 값을 선택하려면 SQL 쿼리 창에 다음 쿼리를 추가한 후 실행을 클릭합니다.

SELECT distinct(status) FROM cloud-training-demos.looker_ecomm.order_items ORDER BY status 참고: 값에는 미국 영어 철자인 Canceled 대신, 영국 영어 철자('l'이 두 번 들어감)인 Cancelled가 포함되어 있습니다.

12. SQL Runner의 브라우저 탭을 닫고 IDE의 브라우저 탭으로 돌아갑니다.

13. 새 yesno 측정기준의 LookML 코드를 완성합니다.

dimension: order_is_canceled { type: yesno sql: ${status} = "Cancelled" ;; }

14. 변경사항 저장을 클릭합니다.

    이 브라우저 탭을 Looker IDE용으로 열어 둡니다.

15. 브라우저 탭에서 새 Looker 창을 엽니다.

16. Explore > 주문 항목으로 이동합니다.

17. '데이터' 창에서 SQL 탭을 클릭합니다.

18. 주문 항목 > 측정기준에서 다음을 선택합니다.

• 주문 ID
• 주문이 취소됨(예/아니요)

쿼리를 실행하기 전에 CASE 문은 order_item.status 값이 Cancelled와 동일한지 여부에 따라 예 또는 아니요 결과를 반환한다는 점에 유의하세요.

CASE WHEN order_items.status = "Cancelled" THEN 'Yes' ELSE 'No' END

19. 실행을 클릭합니다.

20. 결과 탭을 열어 결과를 확인합니다.

21. Explore의 브라우저 탭을 닫고 IDE의 브라우저 탭으로 돌아갑니다.

기존 측정기준 및 측정을 기반으로 새 측정 만들기

1. order_items.view를 엽니다.

2. total_revenue_from_completed_orders라는 측정을 검토합니다.

   이 이름은 합계 측정에 관한 권장사항을 준수합니다. 값이 합산됨 또는 총액임을 명확하게 나타내기 위해 'total'로 시작하기 때문입니다. 또한 값이 완료인 기존 상태 측정기준에 필터가 포함되어 있습니다.

total_canceled_orders는 total로 시작하지만 합계가 주문 합계가 아닌 수익 합계임을 명확하게 표시하지 않습니다. 반면 revenue_from_canceled_orders에는 설명 세부정보가 포함되어 있지만 이름 시작 부분에 total이 누락되어 있습니다.

3. 이 측정 뒤에 다음 코드를 추가하여 두 개의 새 측정을 만듭니다.

measure: total_revenue_from_canceled_orders { type: sum sql: ${sale_price} ;; filters: [order_is_canceled: "Yes"] value_format_name: usd } measure: percent_revenue_canceled_orders { type: number value_format_name: percent_2 sql: 1.0*${total_revenue_from_canceled_orders} /NULLIF(${total_revenue}, 0) ;; }

첫 번째 측정인 total_revenue_from_canceled_orders는 total이라는 단어로 시작하기 때문에 동일한 합계 측정 이름 지정 권장사항을 준수하며, 합계가 취소된 주문 수익의 합계임을 명확하게 표시합니다.

하지만 필터가 다릅니다. total_revenue_from_canceled_orders는 상태 측정기준 대신 이전 단계에서 만든 yesno 측정기준을 사용합니다. 두 옵션 모두 모델에 사용 가능한 객체에 따라 기존 LookML 객체를 재사용한다는 권장사항을 준수합니다.

두 번째 측정은 percent 및 canceled orders라는 단어를 포함하기 때문에 비율에 설명을 포함한 이름을 지정해야 한다는 권장사항을 준수합니다. 또한 이 측정은 두 가지 기존 측정(첫 번째 측정과 total_revenue 측정)을 활용하여 취소된 주문에 기인한 수익의 비율을 계산합니다.입니다.

4. 변경사항 저장을 클릭합니다.

   이 브라우저 탭을 Looker IDE용으로 열어 둡니다.

5. 브라우저 탭에서 새 Looker 창을 엽니다.

6. Explore > 주문 항목으로 이동합니다.

7. '데이터' 창에서 SQL 탭을 클릭합니다.

8. 주문 항목 > 측정에서 다음을 선택합니다.

• 취소된 주문의 총수익
• 총수익
• 취소된 주문의 수익 비율

쿼리를 실행하기 전에 CASE 문에 주목하세요. 이 문은 이제 SUM과 함께 사용되어 order_items.status가 Cancelled와 같을 때 order_items.sale_price의 합계를 계산한 다음 order_items.sale_price의 모든 값의 합계로 나눕니다.

SUM(CASE WHEN order_items.status = "Cancelled" THEN order_items.sale_price ELSE NULL END), 0) / NULLIF(COALESCE(SUM(order_items.sale_price ), 0), 0)

9. 실행을 클릭합니다.

10. 결과 탭을 열어 결과를 확인합니다.

11. Explore 쿼리의 브라우저 탭을 닫고 Looker IDE가 있는 브라우저 탭으로 돌아갑니다.

12. 프로젝트 상태()를 클릭합니다.

13. 프로젝트 상태 > LookML 검증 섹션에서 LookML 검증을 클릭합니다.

LookML 오류가 발견되지 않아야 합니다.

변경사항 커밋 및 프로덕션에 배포

1. LookML 검사를 클릭한 다음 변경사항 커밋 및 푸시를 클릭합니다.

2. 커밋 메시지를 추가하고 커밋을 클릭합니다.

3. 마지막으로 프로덕션에 배포를 클릭합니다.

Looker IDE의 브라우저 탭에서 다음 작업을 계속 진행합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 기존 필드와 설명이 포함된 이름 지정 규칙을 활용하는 필드 만들기

작업 2. 라벨과 설명을 사용하여 필드와 Explore에 컨텍스트 제공

LookML 객체에 라벨과 설명을 추가하면 비즈니스 사용자가 워크플로에 사용할 필드와 Explore를 쉽게 식별할 수 있습니다. 이 작업에서는 이전 작업에서 만든 새 yesno 측정기준과 측정에 라벨과 설명을 추가합니다. 기존 주문 항목 Explore에 라벨과 설명을 추가하여 이러한 필드를 비즈니스 사용자에게 노출하는 작업도 합니다.

측정기준에 라벨 및 설명 추가

1. 새 브라우저 탭에서 새 Looker 창을 엽니다.

2. Explore > 주문 항목으로 이동합니다.

3. 주문 항목을 펼치고 주문이 취소됨(예/아니요)이라는 측정기준 위로 마우스 포인터를 가져가 추가 옵션을 확인합니다.

4. 정보()를 클릭하여 이 측정기준의 세부정보를 확인합니다.

   정보 컨트롤은 SQL 파라미터 같은 세부정보를 제공하지만 SQL 지식이 제한적인 비즈니스 사용자가 측정기준의 용도를 쉽게 이해할 수 있는 추가 설명이 제공되지는 않습니다. 다음 단계에서는 비즈니스 사용자를 위한 추가 컨텍스트를 제공하기 위해 주문이 취소됨 측정기준에 description 파라미터를 추가합니다.

5. Explore 브라우저 탭을 열어 둔 상태로 Looker IDE 브라우저 탭으로 돌아갑니다.

6. order_items.view를 엽니다.

7. 이전에 만든 order_is_canceled 측정기준에 대한 설명을 추가합니다.

dimension: order_is_canceled { description: "값이 Yes인 경우 주문이 취소된 상태임을 의미합니다. 값이 No인 경우 주문이 취소된 상태가 아님을 의미합니다." type: yesno sql: ${status} = "Cancelled" ;; }

8. 변경사항 저장을 클릭한 다음 LookML 검증을 클릭합니다.

9. 주문 항목 Explore 브라우저 탭으로 돌아가서 페이지를 새로고침합니다.

10. 주문 항목을 펼치고 주문이 취소됨(예/아니요)이라는 측정기준 위로 마우스 포인터를 가져가 추가 옵션을 확인합니다.

11. 정보()를 클릭하여 이 측정기준의 세부정보를 확인합니다.

    이제 비즈니스 사용자는 명확한 설명을 통해 측정기준의 값을 해석하는 방법을 파악할 수 있습니다.

12. Explore 브라우저 탭을 열어 둔 상태로 Looker IDE 브라우저 탭으로 돌아갑니다.

13. order_is_canceled 측정기준의 LookML 코드를 다시 검토합니다.

    label 파라미터는 필요하지 않으므로 포함되지 않았습니다. 측정기준 이름이 이미 '주문이 취소됨(예/아니요)'으로 Explore에 명확하게 표시되어 있습니다.

    다음 단계에서는 이전 작업에서 만든 측정에 설명과 라벨을 모두 추가하여 Explore에서 측정 이름이 표시되는 방식을 수정하고 측정 값을 해석하는 방법에 관한 세부정보를 추가할 수 있습니다.

측정에 라벨 및 설명 추가

1. order_items.view에서 total_revenue_from_canceled_orders 및 percent_revenue_canceled_orders라는 측정에 설명과 라벨을 추가합니다.

measure: total_revenue_from_canceled_orders { label: "취소된 주문으로 인한 총수익 손실" description: "Sum of sale price for orders with canceled status." type: sum sql: ${sale_price} ;; filters: [order_is_canceled: "Yes"] value_format_name: usd } measure: percent_revenue_canceled_orders { label: "취소된 주문으로 인한 수익 손실 비율" description: "전체 주문의 총수익에서 취소된 주문으로 인한 총수익 손실의 비율" type: number value_format_name: percent_2 sql: 1.0*${total_revenue_from_canceled_orders} /NULLIF(${total_revenue}, 0) ;; }

2. 변경사항 저장을 클릭한 다음 LookML 검증을 클릭합니다.

   이러한 측정에 라벨을 추가하면 취소된 주문이 손실된 수익을 나타낸다는 점을 강조할 수 있으며, 설명을 추가하면 측정 유형과 SQL 파라미터를 해석하는 방법에 관한 추가 컨텍스트를 제공할 수 있습니다.

3. 주문 항목 Explore 브라우저 탭으로 돌아가서 페이지를 새로고침합니다.

4. 주문 항목을 펼치면 취소된 주문으로 인한 수익 손실 비율 및 취소된 주문으로 인한 총수익 손실이라는 두 측정의 라벨이 수정된 것을 확인할 수 있습니다.

5. 각 측정의 정보()를 클릭하여 세부정보를 확인합니다.

   이제 라벨에 더해 유용한 설명까지 추가되어 비즈니스 사용자는 이러한 측정의 값을 해석하는 방법을 파악할 수 있습니다.

6. 주문 항목 > 측정기준에서 주문이 취소됨(예/아니요)을 선택합니다.

7. 주문 항목 > 측정에서 다음을 선택합니다.

• 취소된 주문으로 인한 총수익 손실
• 총수익
• 취소된 주문으로 인한 수익 손실 비율

8. '데이터' 창에서 열 이름 위로 마우스를 가져가면 주문이 취소됨, 취소된 주문으로 인한 총수익 손실, 취소된 주문으로 인한 수익 손실 비율에 대해 정보 버튼에 제공된 것과 동일한 설명이 표시됩니다.

9. 실행을 클릭합니다.

   이 쿼리는 주문이 취소됨 측정기준을 기준으로 두 행을 반환합니다. 하나는 예에 대한 행이고 다른 하나는 아니요에 대한 행입니다. 이제 결과에 대해 궁금한 점이 있는 비즈니스 사용자는 이러한 측정기준과 측정의 설명을 참고하여 자세한 컨텍스트를 파악할 수 있습니다.

Explore에 라벨 및 설명 추가

1. Explore의 브라우저 탭을 닫고 Looker IDE의 브라우저 탭으로 돌아갑니다.

2. models에서 training_ecommerce.model을 엽니다.

3. users 조인 전에 기존 주문 항목 Explore에 라벨과 설명을 추가합니다.

explore: order_items { label: "주문 및 사용자" description: "이 Explore를 사용하여 인벤토리, 제품, 유통센터 정보를 포함하는 주문 및 사용자에 대한 세부정보를 검토하세요." join: users { type: left_outer sql_on: ${order_items.user_id} = ${users.id} ;; relationship: many_to_one }

4. 변경사항 저장을 클릭한 다음 LookML 검증을 클릭합니다.

5. IDE의 브라우저 탭은 열어 두고 새 브라우저 탭에서 새 Looker 창을 엽니다.

6. Explore를 클릭하여 Explore의 메뉴 목록을 확인합니다.

주문 항목 Explore에 주문 및 사용자라는 새 라벨이 지정됩니다. 이제 Explore 이름 옆에 정보 컨트롤도 표시됩니다.

7. 정보() 위로 마우스 포인터를 가져가면 Explore의 세부정보를 확인할 수 있습니다.

   비즈니스 사용자가 이 Explore가 워크플로에 적합한지 쉽게 판단할 수 있도록 Explore에서 사용할 수 있는 데이터에 관한 세부정보가 포함된 명확한 설명이 제공됩니다.

8. Explore의 브라우저 탭을 닫고 IDE의 브라우저 탭은 열어 둡니다.

변경사항 커밋 및 프로덕션에 배포

1. LookML 검사를 클릭한 다음 변경사항 커밋 및 푸시를 클릭합니다.

2. 커밋 메시지를 추가하고 커밋을 클릭합니다.

3. 마지막으로 프로덕션에 배포를 클릭합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 라벨과 설명을 사용하여 필드와 Explore에 컨텍스트 제공

작업 3. 특정 Explore에 필요한 필드로만 제한

모델에서 새 LookML 객체를 만들 때는 비즈니스 사용자가 직접 액세스해야 하는 필드와 Explore를 신중하게 고려하세요. 특정 필드와 Explore만 선별하여 표시하면 비즈니스 사용자는 필요한 데이터를 신속하게 찾을 수 있습니다.

이 작업에서는 hidden 파라미터를 사용하여 전체 training_ecommerce 모델에서 추가 필드를 숨기고, fields 파라미터를 활용하여 기존 주문 항목 Explore에서 비즈니스 사용자에게 표시되는 필드를 제한합니다.

LookML 모델의 모든 Explore에서 필드 숨기기

1. 새 브라우저 탭에서 새 Looker 창을 엽니다.

2. Explore > 이벤트로 이동합니다.

3. 사용자를 펼칩니다.

4. 새 브라우저 탭에서 다른 새 Looker 창을 엽니다.

5. Explore > 주문 및 사용자로 이동합니다.

6. 사용자를 펼치고 두 Explore를 비교합니다.

이벤트 Explore의 사용자에게는 주문 및 사용자와 동일한 측정기준이 표시됩니다. 비즈니스 사용자에게 항상 표시하고 싶지 않을 수 있는 위도 및 경도 측정기준도 포함됩니다.

도움말: Looker 문서에서 각 파라미터를 검색할 수 있습니다.

7. 두 Explore의 브라우저 탭을 모두 열어 둔 상태에서 Looker IDE로 돌아갑니다.

8. views에서 users.view를 엽니다.

9. 위도 및 경도 측정기준에 hidden 파라미터를 추가합니다.

dimension: latitude { hidden: yes type: number sql: ${TABLE}.latitude ;; } dimension: longitude { hidden: yes type: number sql: ${TABLE}.longitude ;; }

10. 변경사항 저장을 클릭한 다음 LookML 검증을 클릭합니다.

11. 주문 및 사용자 Explore의 브라우저 탭으로 돌아가 페이지를 새로고침합니다.

12. 사용자를 펼치고 사용 가능한 측정기준을 검토합니다.

    위도 및 경도 측정기준이 주문 및 사용자 Explore에 더 이상 표시되지 않습니다.

13. 이벤트 Explore의 브라우저 탭으로 돌아가 페이지를 새로고침합니다.

14. 사용자를 펼치고 사용 가능한 측정기준을 검토합니다.

    위도 및 경도 측정기준이 두 Explore에 더 이상 표시되지 않습니다. 하지만 모든 Explore에서 측정기준이나 측정을 숨기는 대신 특정 Explore에서만 숨기려고 한다고 가정해 보겠습니다. 예를 들어 이벤트 Explore에는 주문 및 사용자 Explore와 동일한 사용자 정보가 모두 포함되어 있지만, 이러한 필드 중 상당수는 이벤트 Explore에 실제로 필요한 것보다 많은 개인 식별 정보를 제공합니다.

    다음 단계에서는 대부분의 측정기준과 측정을 사용자 뷰에서 숨김 처리하지만 사용자를 선택하거나 일반적인 추세를 파악하기 위해 최소한의 정보만 필요한 이벤트 Explore에서는 숨기지 않습니다.

특정 Explore에서 필드를 선택적으로 숨기기

1. Explore의 브라우저 탭은 열어 둔 상태에서 IDE의 브라우저 탭으로 돌아갑니다.

2. training_ecommerce.model을 엽니다.

3. event_session_facts의 join 앞에서, 기존 이벤트 Explore에 fields 파라미터를 추가합니다.

explore: events { fields: [ALL_FIELDS*, -users.city, -users.email, -users.first_name, -users.gender, -users.last_name, -users.state] join: event_session_facts { type: left_outer sql_on: ${events.session_id} = ${event_session_facts.session_id} ;; relationship: many_to_one }

fields 파라미터의 문법은 Explore에서는 모든 필드가 표시되지만 필드 이름 앞에 마이너스 기호(-)가 있는 필드(예: users.city)는 Explore에서 숨김 처리된다는 사실을 나타냅니다.

4. 변경사항 저장을 클릭한 다음 LookML 검증을 클릭합니다.

5. 주문 및 사용자 Explore의 브라우저 탭으로 돌아가 페이지를 새로고침합니다.

6. 사용자를 펼치고 사용 가능한 측정기준을 검토합니다.

   주문 및 사용자 Explore에서 추가 측정기준이 숨김 처리되지 않았습니다.

7. 이벤트 Explore의 브라우저 탭으로 돌아가 페이지를 새로고침합니다.

8. 사용자를 펼치고 사용 가능한 측정기준을 검토합니다.

   fields 파라미터에서 마이너스 기호(-)로 명시적으로 식별되지 않은 사용자에 대한 측정기준만 이벤트 Explore에서 사용할 수 있습니다.

   이제 이벤트 Explore에서는 사용자 및 이벤트에 대한 더 일반적인 분석을 지원하며, 주문 및 사용자 Explore에는 개인 식별 정보와 같은 더 구체적인 사용자 세부정보가 포함됩니다.

9. 사용자 > 측정기준에서 국가를 선택합니다.

10. 사용자 > 측정에서 개수를 선택합니다.

11. 이벤트 > 측정기준에서 이벤트 유형을 선택합니다.

12. 실행을 클릭합니다.

    이 쿼리는 국가 값이 null인 사용자를 포함한 각 이벤트 유형의 국가별 사용자 수를 반환합니다.

13. Explore에 대해 열려 있는 브라우저 탭을 모두 닫고 IDE의 브라우저 탭은 열어 둡니다.

변경사항 커밋 및 프로덕션에 배포

1. LookML 검사를 클릭한 다음 변경사항 커밋 및 푸시를 클릭합니다.

2. 커밋 메시지를 추가하고 커밋을 클릭합니다.

3. 마지막으로 프로덕션에 배포를 클릭합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 특정 Explore에 필요한 필드로만 제한

작업 4. 유사한 필드 또는 Explore를 유용한 카테고리로 그룹화

LookML 개발자는 group_label 파라미터를 사용하여 유사한 필드 또는 Explore를 논리적 카테고리로 그룹화해 Explore의 탐색 용이성을 개선할 수 있습니다. 이 작업에서는 users.view의 다양한 위치 측정기준을 그룹화하고, training_ecommerce.model의 주문 및 사용자 Explore와 이벤트 Explore에 대해 별도의 그룹을 만든 후 팀별로 라벨이 지정된 서로 다른 제목을 부여합니다.

뷰에 있는 유사한 필드 그룹화

1. users.view를 열고 사용 가능한 측정기준을 검토합니다.

여러 측정기준에 도시, 국가, 주, 우편번호와 같은 위치 정보가 포함되어 있습니다.

필드의 group_label 파라미터에 관한 문서를 기반으로 group_label: "Group Name"의 LookML 문법을 여러 측정기준에 추가하여 단일 카테고리로 그룹화할 수 있습니다.

2. 도시, 국가, 주, 우편번호 측정기준에 group_label 파라미터를 추가하여 '위치'라는 이름의 단일 카테고리로 그룹화합니다.

dimension: city { group_label: "위치" type: string sql: ${TABLE}.city ;; } dimension: country { group_label: "위치" type: string map_layer_name: countries sql: ${TABLE}.country ;; } dimension: state { group_label: "위치" type: string sql: ${TABLE}.state ;; map_layer_name: us_states } dimension: zip { group_label: "위치" type: zipcode sql: ${TABLE}.zip ;; }

3. 변경사항 저장을 클릭한 다음 LookML 검증을 클릭합니다.

4. IDE의 브라우저 탭을 열어 둔 상태에서 새 브라우저 탭에서 새 Looker 창을 엽니다.

5. Explore > 주문 및 사용자로 이동합니다.

6. 사용자를 펼치고 사용 가능한 측정기준을 검토합니다.

7. 사용자 > 측정기준 > 위치에서 다음을 선택합니다.

• 도시
• 국가
• 주
• 우편번호

8. 실행을 클릭하여 결과를 확인합니다.

9. 주문 및 사용자 Explore의 브라우저 탭을 닫고 IDE의 브라우저 탭으로 돌아갑니다.

다양한 제목의 Explore 그룹 만들기

1. training_ecommerce.model을 엽니다.

15번째 줄의 모델 수준 label 파라미터값이 '전자상거래 교육'입니다. 이 값은 현재 Explore 메뉴에 표시되는 제목입니다. 주문 및 사용자 Explore와 이벤트 Explore가 모두 Explore 메뉴의 이 제목에 정리되어 있습니다.

Explore의 group_label에 관한 문서 페이지를 검토한 후 다음 질문에 답하세요.

2. label 파라미터 앞에서 주문 항목 Explore에 '전자상거래 - 인벤토리팀'이라는 group_label을 추가합니다.

explore: order_items { group_label: "전자상거래 - 인벤토리팀" label: "주문 및 사용자"

3. fields 파라미터 앞에서 이벤트 Explore에 '전자상거래 - 마케팅팀'이라는 group_label을 추가합니다.

explore: events { group_label: "전자상거래 - 마케팅팀" fields: [ALL_FIELDS*, -users.city, -users.email, -users.first_name, -users.gender, -users.last_name, -users.state]

4. 변경사항 저장을 클릭한 다음 LookML 검증을 클릭합니다.

5. 새 브라우저 탭에서 새 Looker 창을 엽니다.

6. Explore 메뉴를 펼치고 옵션을 검토합니다.

이제 각 Explore에 자체 제목이 설정되었습니다. 새 Explore를 추가할 때는 동일한 group_label 값을 사용하여 기존 그룹을 계속 확장할 수 있고, 새 group_label 값을 할당하여 자체 제목이 있는 새 그룹을 만들 수도 있습니다.

변경사항 커밋 및 프로덕션에 배포

1. LookML 검사를 클릭한 다음 변경사항 커밋 및 푸시를 클릭합니다.

2. 커밋 메시지를 추가하고 커밋을 클릭합니다.

3. 마지막으로 프로덕션에 배포를 클릭합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 유사한 필드 또는 Explore를 유용한 카테고리로 그룹화

수고하셨습니다

이 실습에서는 기존 객체를 재사용하고, 설명이 포함된 이름 지정 규칙을 적용하고, fields 및 hidden과 같은 추가 파라미터를 사용하여 LookML 프로젝트의 사용성과 지속 가능성을 개선했습니다. 그런 다음 특정 Explore에 필요한 필드로만 필드를 제한하고 group_label 파라미터를 사용하여 유사한 필드와 Explore를 논리적 카테고리로 그룹화하여 Explore의 탐색 용이성을 개선했습니다.

다음 단계/더 학습하기

• LookML 빠른 참조
• LookML 용어 및 개념
• Looker 커뮤니티
• 추가 LookML 기본사항
• 권장사항: Looker 사용자를 위한 긍정적인 환경 만들기

Google Cloud 교육 및 자격증

Google Cloud 기술을 최대한 활용하는 데 도움이 됩니다. Google 강의에는 빠른 습득과 지속적인 학습을 지원하는 기술적인 지식과 권장사항이 포함되어 있습니다. 기초에서 고급까지 수준별 학습을 제공하며 바쁜 일정에 알맞은 주문형, 실시간, 가상 옵션이 포함되어 있습니다. 인증은 Google Cloud 기술에 대한 역량과 전문성을 검증하고 입증하는 데 도움이 됩니다.

설명서 최종 업데이트: 2026년 2월 2일

실습 최종 테스트: 2025년 12월 3일

Copyright 2026 Google LLC. All rights reserved. Google 및 Google 로고는 Google LLC의 상표입니다. 기타 모든 회사명 및 제품명은 해당 업체의 상표일 수 있습니다.