# Looker và LookML năm 2026: Hướng dẫn Business Intelligence và Câu hỏi Phỏng vấn

> Hướng dẫn toàn diện về LookML dành cho data analyst năm 2026. Tìm hiểu semantic layer, mô hình hóa dữ liệu, derived tables và các câu hỏi phỏng vấn Looker phổ biến.

- Published: 2026-07-20
- Updated: 2026-07-20
- Author: SharpSkill
- Tags: looker, lookml, business-intelligence, data-analytics, interview
- Reading time: 12 min

---

Các câu hỏi phỏng vấn Looker thường tập trung vào việc mô hình hóa LookML, quy trình khám phá dữ liệu, và cách semantic layer chuyển đổi logic kinh doanh thành các định nghĩa có thể tái sử dụng. Hướng dẫn này đề cập đến các khái niệm cốt lõi của LookML, các pattern triển khai thực tế, và chính xác những câu hỏi mà data analyst phải đối mặt khi phỏng vấn cho các vị trí tập trung vào Looker trong năm 2026.

> **Khái niệm LookML quan trọng**
>
> LookML tách biệt việc mô hình hóa dữ liệu khỏi việc khám phá dữ liệu. Analyst định nghĩa dimensions, measures và relationships một lần trong model layer, sau đó người dùng kinh doanh có thể truy vấn dữ liệu mà không cần viết SQL—đây là pattern xuất hiện trong hầu hết mọi cuộc phỏng vấn kỹ thuật Looker.

## Hiểu về Semantic Layer trong LookML

LookML hoạt động như một lớp chuyển đổi giữa các bảng database thô và các metrics thân thiện với doanh nghiệp. Thay vì viết các SQL join phức tạp lặp đi lặp lại, analyst định nghĩa các relationships trong các file model mà Looker biên dịch thành các query được tối ưu hóa.

Semantic layer giải quyết ba vấn đề mà interviewer thường hỏi về:
- **Tính nhất quán**: Mọi người dùng đều thấy cùng một định nghĩa metric
- **Khả năng tái sử dụng**: Dimensions và measures tồn tại một lần, được tham chiếu ở mọi nơi
- **Quản trị**: Các thay đổi tự động lan truyền đến tất cả dashboards

Tài liệu [Looker của Google Cloud](https://cloud.google.com/looker/docs/what-is-lookml) mô tả LookML là ngôn ngữ "dependency-aware"—khi một định nghĩa thay đổi, các tham chiếu downstream tự động cập nhật. Tính năng dependency awareness này trở nên quan trọng khi duy trì các model quy mô doanh nghiệp.

## Views và Explores trong LookML: Các Thành phần Cơ bản

Views định nghĩa các cột có sẵn từ một bảng đơn hoặc derived table. Explores kết hợp các views thông qua joins và hiển thị chúng cho người dùng kinh doanh.

```lookml
# views/orders.view.lkml
view: orders {
  sql_table_name: `analytics.orders` ;;

  dimension: order_id {
    primary_key: yes
    type: number
    sql: ${TABLE}.order_id ;;
  }

  dimension_group: created {
    type: time
    timeframes: [raw, date, week, month, quarter, year]
    sql: ${TABLE}.created_at ;;
  }

  dimension: status {
    type: string
    sql: ${TABLE}.status ;;
  }

  measure: total_orders {
    type: count
    drill_fields: [order_id, created_date, status]
  }

  measure: total_revenue {
    type: sum
    sql: ${TABLE}.amount ;;
    value_format_name: usd
  }
}
```

Khai báo `dimension_group` tạo ra nhiều dimensions dựa trên thời gian từ một cột timestamp duy nhất. Interviewer thường yêu cầu ứng viên giải thích tại sao pattern này giảm việc trùng lặp code và đảm bảo xử lý ngày tháng nhất quán trong toàn bộ model.

Tham số `drill_fields` định nghĩa những gì người dùng thấy khi nhấp vào giá trị measure—chi tiết UX thể hiện sự hiểu biết về cách analyst thực sự tương tác với Looker.

## Joins và Relationships trong LookML

Explores định nghĩa cách các views kết nối thông qua SQL joins. Loại join và khai báo relationship trực tiếp ảnh hưởng đến hiệu suất truy vấn và độ chính xác của aggregation.

```lookml
# models/ecommerce.model.lkml
explore: orders {
  label: "Order Analysis"
  description: "All orders with customer and product details"

  join: customers {
    type: left_outer
    sql_on: ${orders.customer_id} = ${customers.customer_id} ;;
    relationship: many_to_one
  }

  join: order_items {
    type: left_outer
    sql_on: ${orders.order_id} = ${order_items.order_id} ;;
    relationship: one_to_many
  }

  join: products {
    type: left_outer
    sql_on: ${order_items.product_id} = ${products.product_id} ;;
    relationship: many_to_one
  }
}
```

Tham số `relationship` cho Looker biết cách xử lý aggregations. Relationship `one_to_many` có nghĩa là measure nên được aggregate ở phía "one" để tránh đếm trùng. Sai sót trong việc này gây ra tổng số không chính xác—một tình huống debugging phổ biến trong các cuộc phỏng vấn.

Symmetric aggregates tự động giải quyết vấn đề fanout. Khi join các bảng có granularity khác nhau, Looker tạo ra SQL tính toán measures ở mức chính xác trước khi thực hiện join.

## Derived Tables cho các Transformations Phức tạp

Derived tables tạo các bảng ảo từ các SQL queries hoặc aggregations được định nghĩa bằng LookML. Native derived tables sử dụng cú pháp LookML; SQL-derived tables nhúng SQL thô.

```lookml
# views/customer_order_facts.view.lkml
view: customer_order_facts {
  derived_table: {
    explore_source: orders {
      column: customer_id { field: customers.customer_id }
      column: first_order_date { field: orders.created_date }
      column: lifetime_orders { field: orders.total_orders }
      column: lifetime_revenue { field: orders.total_revenue }
      derived_column: customer_tenure_days {
        sql: DATE_DIFF(CURRENT_DATE(), first_order_date, DAY) ;;
      }
    }
    datagroup_trigger: daily_etl
    indexes: ["customer_id"]
  }

  dimension: customer_id {
    primary_key: yes
    hidden: yes
    type: number
  }

  dimension: first_order_date {
    type: date
    sql: ${TABLE}.first_order_date ;;
  }

  dimension: lifetime_orders {
    type: number
    sql: ${TABLE}.lifetime_orders ;;
  }

  dimension: customer_tier {
    type: string
    sql: CASE
      WHEN ${lifetime_orders} >= 10 THEN 'Gold'
      WHEN ${lifetime_orders} >= 5 THEN 'Silver'
      ELSE 'Bronze'
    END ;;
  }
}
```

`datagroup_trigger` kiểm soát thời điểm Looker xây dựng lại derived table—thường là sau khi ETL upstream hoàn thành. Persistent derived tables (PDTs) được materialize trong database, đánh đổi storage để lấy tốc độ truy vấn.

Interviewer hỏi về chiến lược rebuild PDT. Tham số `sql_trigger_value` chạy một SQL query; khi kết quả thay đổi, Looker xây dựng lại PDT. Pattern phổ biến sử dụng `SELECT MAX(updated_at) FROM source_table`.

## Câu hỏi Phỏng vấn Looker: Thiết kế Model

Các cuộc phỏng vấn kỹ thuật cho vị trí Looker tập trung nhiều vào các quyết định mô hình hóa LookML. Những câu hỏi này đánh giá liệu ứng viên có hiểu các tradeoffs giữa tính linh hoạt và hiệu suất hay không.

**Câu hỏi: Làm thế nào để mô hình hóa một fact table với nhiều date dimensions?**

Câu trả lời liên quan đến việc tạo các dimension groups riêng biệt và đặt tên joins một cách rõ ràng:

```lookml
# views/orders.view.lkml
view: orders {
  dimension_group: order_created {
    type: time
    timeframes: [date, week, month, year]
    sql: ${TABLE}.created_at ;;
  }

  dimension_group: order_shipped {
    type: time
    timeframes: [date, week, month, year]
    sql: ${TABLE}.shipped_at ;;
  }

  dimension: days_to_ship {
    type: number
    sql: DATE_DIFF(${order_shipped_date}, ${order_created_date}, DAY) ;;
  }
}
```

**Câu hỏi: Khi nào sử dụng PDT so với dbt model?**

PDTs phù hợp cho các aggregations đặc thù Looker thay đổi theo model. Các transformations [dbt](https://docs.getdbt.com/docs/introduction) phù hợp cho datasets được chia sẻ sử dụng bởi nhiều tools. Pattern [tích hợp dbt + Looker](https://cloud.google.com/looker/docs/db-config-dbt) sử dụng dbt cho các transformations nặng và PDTs cho các metrics cuối cùng.

**Câu hỏi: Làm thế nào để xử lý slowly changing dimensions trong LookML?**

Các bảng SCD Type 2 yêu cầu lọc đến record hiện tại. Thêm một dimension lọc các hàng và sử dụng `always_filter` trong explore:

```lookml
# views/customer_history.view.lkml
view: customer_history {
  dimension: is_current {
    type: yesno
    sql: ${TABLE}.end_date IS NULL ;;
  }
}

# In the explore
explore: orders {
  join: customer_history {
    sql_on: ${orders.customer_id} = ${customer_history.customer_id} ;;
    relationship: many_to_one
  }
  always_filter: {
    filters: [customer_history.is_current: "Yes"]
  }
}
```

## Liquid Templating cho Models Động

Liquid templating cho phép logic điều kiện trong các định nghĩa LookML. User attributes, giá trị filter và permissions có thể sửa đổi SQL được tạo ra.

```lookml
# views/regional_orders.view.lkml
view: regional_orders {
  sql_table_name: 
    {% if _user_attributes['region'] == 'EMEA' %}
      analytics.orders_emea
    {% elsif _user_attributes['region'] == 'APAC' %}
      analytics.orders_apac
    {% else %}
      analytics.orders_us
    {% endif %}
  ;;

  dimension: amount {
    type: number
    sql: ${TABLE}.amount ;;
    html: 
      {% if value > 1000 %}
        <span style="color: green;">{{ rendered_value }}</span>
      {% else %}
        {{ rendered_value }}
      {% endif %}
    ;;
  }
}
```

User attributes điều khiển row-level security và lựa chọn bảng động. Object `_user_attributes` cung cấp quyền truy cập vào các giá trị được gán trong admin panel của Looker.

Tham số `html` tùy chỉnh cách giá trị được hiển thị trong bảng và visualizations—conditional formatting thường xuất hiện trong các dự án take-home phỏng vấn.

## Các Pattern Tối ưu hóa Hiệu suất

Looker tạo SQL từ các định nghĩa LookML. Tối ưu hóa đòi hỏi hiểu biết cả model layer và database cơ bản.

**Aggregate awareness** pre-compute các aggregations phổ biến ở các mức grain khác nhau:

```lookml
# views/orders.view.lkml
view: orders {
  aggregate_table: daily_orders {
    query: {
      dimensions: [created_date]
      measures: [total_orders, total_revenue]
    }
    materialization: {
      datagroup_trigger: daily_etl
    }
  }

  aggregate_table: monthly_orders {
    query: {
      dimensions: [created_month]
      measures: [total_orders, total_revenue]
    }
    materialization: {
      datagroup_trigger: daily_etl
    }
  }
}
```

Looker tự động định tuyến các queries đến aggregate table nhỏ nhất thỏa mãn yêu cầu. Một query dashboard hàng tháng đọc từ `monthly_orders` thay vì quét toàn bộ fact table.

Các cài đặt mức connection ảnh hưởng đáng kể đến hiệu suất. Các kết nối BigQuery nên kích hoạt [query caching](https://cloud.google.com/bigquery/docs/cached-results) và thiết lập timeouts phù hợp. Tham số `max_connections` kiểm soát concurrent query slots.

Đối với data analyst đang chuẩn bị phỏng vấn, [hướng dẫn SQL window functions](/blog/data-analytics/sql-window-functions-ctes-advanced-queries) đề cập đến các query patterns bổ sung cho kỹ năng mô hình hóa LookML.

## Access Controls và Content Management

Row-level security, model permissions và tổ chức nội dung xuất hiện trong các cuộc phỏng vấn Looker cấp cao. Cơ chế access_grant kiểm soát tính khả dụng của tính năng:

```lookml
# models/ecommerce.model.lkml
access_grant: can_view_pii {
  user_attribute: department
  allowed_values: ["data_team", "compliance"]
}

explore: customers {
  access_filter: {
    field: customers.region
    user_attribute: allowed_regions
  }
}

view: customers {
  dimension: email {
    type: string
    sql: ${TABLE}.email ;;
    required_access_grants: [can_view_pii]
  }
}
```

`access_filter` động thêm các mệnh đề WHERE dựa trên user attributes. Một sales manager chỉ thấy dữ liệu của vùng họ quản lý. Tham số `required_access_grants` ẩn dimensions khỏi người dùng không có grant được chỉ định.

Tổ chức nội dung tuân theo phân cấp thư mục. Dashboards production nằm trong shared spaces; công việc development ở trong personal folders cho đến khi được xác thực. LookML validator bắt lỗi cú pháp trước khi deployment.

## Các Sai lầm Phỏng vấn Phổ biến cần Tránh

Các cuộc phỏng vấn kỹ thuật Looker tiết lộ những hiểu lầm phổ biến:

**Khai báo relationship không chính xác** gây ra inflation metric. Một relationship `one_to_one` trên join `one_to_many` tạo ra aggregates sai. Luôn xác minh cardinality bằng các queries `SELECT COUNT(*), COUNT(DISTINCT key)`.

**Phụ thuộc quá mức vào SQL-derived tables** thay vì native derives. Native derived tables tích hợp với dependency tracking của Looker; SQL-derived tables yêu cầu quản lý thủ công.

**Bỏ qua datagroup caching.** Không có cache invalidation đúng cách, dashboards hiển thị dữ liệu cũ. Định nghĩa datagroups phù hợp với lịch ETL và gán chúng cho explores.

Để chuẩn bị phỏng vấn toàn diện về các khái niệm mô hình hóa dữ liệu và analytics, [hướng dẫn câu hỏi phỏng vấn data analytics](/blog/data-analytics/data-analytics-interview-questions-2026) đề cập đến các chủ đề rộng hơn ngoài kiến thức Looker cụ thể.

## Kết luận

Thành công trong các cuộc phỏng vấn Looker đòi hỏi thể hiện cả kiến thức cú pháp LookML và sự hiểu biết về lý do tại sao kiến trúc semantic layer mang lại lợi ích cho tổ chức:

- LookML views định nghĩa dimensions và measures; explores kết hợp views thông qua joins được khai báo với các loại relationship rõ ràng
- Derived tables materialize các transformations phức tạp; datagroups kiểm soát cache invalidation và lịch rebuild PDT
- Liquid templating cho phép tạo SQL động dựa trên user attributes và các lựa chọn filter
- Aggregate awareness pre-compute metrics ở nhiều grains, tự động định tuyến queries đến bảng tối ưu
- Access controls kết hợp row-level filters, access grants và content permissions cho governed self-service
- Tối ưu hóa hiệu suất đòi hỏi căn chỉnh các patterns LookML với tuning đặc thù database (BigQuery slots, Snowflake warehouses)

Thực hành xây dựng các LookML models với sample datasets trước các cuộc phỏng vấn. [BigQuery public datasets](https://cloud.google.com/bigquery/public-data) cung cấp các schemas thực tế cho các bài tập mô hình hóa.

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/vi/blog/data-analytics/looker-lookml-business-intelligence-interview-2026