Looker 1 — Tổng quan & kiến trúc mô hình hoá

Mở đầu: Looker là một "loài" BI khác

Nếu bạn đến với Looker sau khi đã quen Power BI hay Tableau, phản xạ đầu tiên thường là đi tìm nút "import dữ liệu" — và bạn sẽ không tìm thấy. Đó không phải thiếu sót, mà là triết lý thiết kế cốt lõi: Looker không hút dữ liệu về mình. Nó là một nền tảng BI của Google Cloud xây quanh một tầng ngữ nghĩa (semantic layer) được mã hoá bằng ngôn ngữ LookML, và mọi câu hỏi của người dùng cuối cuối cùng đều biến thành SQL chạy trực tiếp trên kho dữ liệu (data warehouse) của bạn.

Sự khác biệt tưởng nhỏ này lại kéo theo hàng loạt hệ quả về hiệu năng, chi phí, quản trị và cách tổ chức đội ngũ. Bài này là tấm bản đồ tổng thể của loạt Looker & LookML chuyên sâu: Looker là gì, kiến trúc in-database hoạt động ra sao, LookML đóng vai trò "nguồn sự thật" về metric như thế nào, và — quan trọng để tránh nhầm lẫn — Looker khác gì với Looker Studio (tên cũ Data Studio).

Một lưu ý quy ước xuyên suốt loạt bài: đây là công cụ BI, không phải SQL sandbox. Mọi đoạn LookML trong bài chỉ là minh hoạ khái niệm, không phải để chạy trực tiếp ở đâu đó.

Looker là gì — nền tảng BI cộng semantic layer

Về bản chất, Looker gồm hai lớp gắn chặt vào nhau:

1. Lớp nền tảng BI: nơi người dùng cuối khám phá dữ liệu (Explore), xây biểu đồ, lưu Look (một truy vấn/biểu đồ đã lưu) và dựng Dashboard, nhúng phân tích vào ứng dụng khác (embedding), hoặc gọi qua API.
2. Lớp mô hình hoá (semantic layer): nơi lập trình viên định nghĩa dữ liệu có ý nghĩa gì bằng LookML — bảng nào là gì, cột nào là chiều (dimension), phép đo (measure) tính ra sao, các bảng nối với nhau thế nào.

Điểm mấu chốt phân biệt Looker với hầu hết công cụ BI: người dùng cuối gần như không viết SQL. Họ vào một Explore — một "khung khám phá" đã được dựng sẵn — kéo thả các chiều và phép đo, và Looker tự sinh SQL đằng sau. Vì mọi định nghĩa metric đã được mã hoá một lần trong LookML, câu trả lời của mọi người luôn nhất quán. "Doanh thu thuần" hay "tỷ lệ nợ xấu" chỉ được định nghĩa đúng một chỗ, không ai tự chế mỗi người một công thức.

Kiến trúc in-database: Looker sinh SQL, warehouse chạy

Đây là ý tưởng cần nắm chắc nhất. Trong Power BI theo chế độ Import, dữ liệu được hút vào một mô hình in-memory (VertiPaq) nằm trong file/dataset, và mọi truy vấn chạy trên bản sao đó. Looker đi hướng ngược lại: nó giữ dữ liệu ở nguyên trong warehouse và chỉ đóng vai trò "bộ dịch".

Khi người dùng kéo thả trong Explore, chuỗi sự kiện diễn ra như sau: Looker đọc mô hình LookML để hiểu ý định → sinh ra câu SQL phù hợp với "phương ngữ" (dialect) của warehouse → đẩy câu SQL đó xuống warehouse chạy → warehouse trả về kết quả tổng hợp (thường đã group/aggregate, nhỏ gọn) → Looker vẽ thành bảng/biểu đồ.

Cách tiếp cận này gọi là query pushdown hoặc in-database analytics. Looker hỗ trợ nhiều warehouse: BigQuery, Snowflake, Redshift, Databricks, PostgreSQL... (BigQuery đặc biệt gần gũi vì cùng hệ sinh thái Google Cloud).

Ưu điểm của kiến trúc này:

• Dữ liệu luôn tươi: không có bước "làm mới" định kỳ như mô hình import; mỗi truy vấn chạy trên dữ liệu hiện tại của warehouse.
• Không giới hạn bởi RAM của công cụ BI: sức tính toán là của warehouse, vốn được thiết kế để quét hàng tỷ dòng.
• Một nguồn duy nhất: không tạo ra vô số bản sao dữ liệu rải rác trong các file báo cáo.

Cái giá phải trả (đánh đổi) cũng rất thật:

• Phụ thuộc hiệu năng warehouse: mỗi lần bấm là một truy vấn thật. Warehouse chậm thì dashboard chậm.
• Chi phí truy vấn: với BigQuery tính tiền theo lượng dữ liệu quét, hay Snowflake tính theo thời gian compute, một dashboard đông người xem có thể sinh chi phí đáng kể nếu không tối ưu.
• Đòi hỏi kỷ luật tối ưu: cần đánh index/partition/cluster hợp lý, dùng cache của Looker, và cân nhắc bảng dẫn xuất (derived tables/PDT) để giảm tải — chủ đề của Looker 5 — Derived tables & PDT.

Vì thế Looker và warehouse là một cặp không thể tách rời. Muốn hiểu sâu phần warehouse phổ biến nhất đi kèm Looker, xem BigQuery — Tổng quan.

LookML: mô hình hoá như một "nguồn sự thật"

LookML (Looker Modeling Language) là ngôn ngữ khai báo (declarative) — bạn mô tả dữ liệu là gì, không viết logic thủ tục. Cú pháp trông giống YAML/khối lồng nhau. Bốn khái niệm xương sống:

• view: đại diện cho một bảng (hoặc một truy vấn) trong warehouse; bên trong chứa các dimension và measure.
• dimension: một thuộc tính để nhóm/lọc — ánh xạ tới một cột hoặc một biểu thức SQL (ví dụ: region, order_date, customer_segment).
• measure: một phép tổng hợp — sum, count, average, count_distinct... (ví dụ: total_revenue = sum(amount)).
• explore: điểm vào để người dùng khám phá, gom nhiều view lại qua các phép join, quyết định người dùng được nhìn thấy gì. Xem sâu ở Looker 3 — Explores & joins.
• model: tệp gói kết nối tới một warehouse cụ thể và tập hợp các explore.

Sức mạnh nằm ở chỗ: định nghĩa một lần, tái dùng mọi nơi. Khi bạn khai báo measure "doanh thu thuần" trong một view, mọi Explore, Look, Dashboard dùng view đó đều tính giống hệt. Đây chính là ý nghĩa single source of truth (nguồn sự thật duy nhất) về metric — điều mà các công cụ để mỗi người tự viết công thức trong từng báo cáo rất khó đảm bảo.

LookML còn được quản lý bằng Git: toàn bộ mô hình là mã nguồn, có version control, review, nhánh (branch), lịch sử thay đổi. Điều này biến việc mô hình hoá dữ liệu thành một quy trình kỹ thuật phần mềm nghiêm túc thay vì "chỉnh tay trong giao diện". Chi tiết ở Looker 7 — Quản trị & triển khai.

Dưới đây là một view LookML rút gọn (minh hoạ) — không nhằm để chạy, chỉ để bạn hình dung hình dạng của ngôn ngữ:

# view: orders  (minh hoạ LookML rút gọn)
view: orders {
  sql_table_name: analytics.orders ;;

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

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

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

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

  measure: order_count {
    type: count
  }
}

Điều đáng chú ý: measure total_revenue được viết đúng một lần ở đây. Khi Looker sinh SQL, nó sẽ dịch thành đại loại SUM(orders.amount) — nhưng người dùng cuối không bao giờ phải gõ dòng SQL đó. Họ chỉ chọn "Total Revenue" trong Explore. Cú pháp cụ thể (khối, tham số, ${TABLE}, ;;) sẽ được mổ xẻ ở Looker 2 — LookML cơ bản.

Sơ đồ luồng: từ LookML tới biểu đồ

Toàn bộ triết lý của Looker gói gọn trong một vòng đời truy vấn:

Chú ý hai điều: dữ liệu không rời khỏi warehouse (chỉ kết quả tổng hợp đi lên), và LookML nằm ở thượng nguồn — mọi thứ người dùng thấy đều bắt nguồn từ mô hình mà developer đã dựng.

So sánh với Power BI và Tableau

Không có công cụ "tốt nhất" tuyệt đối; mỗi loại tối ưu cho một triết lý khác nhau.

Looker mạnh ở:

• Governance & metric tập trung: LookML ép mọi định nghĩa vào một nơi, có Git; cực hợp cho tổ chức lớn cần "một phiên bản sự thật".
• In-database: dữ liệu luôn tươi, tận dụng sức warehouse, không nhân bản dữ liệu.
• Embedding & API: sinh ra để nhúng phân tích vào sản phẩm/ứng dụng bên ngoài một cách tự nhiên.

Power BI mạnh ở:

• Mô hình in-memory + DAX: engine VertiPaq nén và tính toán cực nhanh trên bản sao dữ liệu; ngôn ngữ DAX biểu đạt phép đo phức tạp theo ngữ cảnh.
• Hệ sinh thái Microsoft: gắn liền Excel, Azure, Microsoft 365, và trung tâm của Microsoft Fabric; chi phí khởi đầu thấp (Desktop miễn phí).
• Xem loạt riêng bắt đầu ở Power BI 1 — Tổng quan.

Tableau mạnh ở:

• Khám phá trực quan (visual analytics): trải nghiệm kéo thả để "vẽ ra câu hỏi" rất mượt, linh hoạt về loại biểu đồ; có thể chạy cả chế độ live (in-database) lẫn extract (import).

Một cách nhớ đơn giản: Looker đặt cược vào tầng mô hình hoá dùng chung (code-first, in-database); Power BI đặt cược vào engine in-memory mạnh cùng hệ sinh thái MS; Tableau đặt cược vào trải nghiệm khám phá trực quan. Nhiều tổ chức thực tế dùng song song.

Looker vs Looker Studio — đừng nhầm hai sản phẩm

Đây là điểm gây nhầm lẫn nhiều nhất, vì cùng thương hiệu "Looker" của Google Cloud nhưng là hai sản phẩm hoàn toàn khác nhau:

Nói ngắn gọn: Looker Studio là công cụ kéo thả nhanh, miễn phí, không có tầng mô hình hoá — hợp cho dashboard marketing, báo cáo nhỏ, cắm thẳng vào Google Analytics/Sheets/BigQuery. Looker là nền tảng doanh nghiệp có phí, xoay quanh LookML, hợp cho tổ chức cần quản trị metric nghiêm ngặt và nhúng sâu. Khi ai đó nói "Looker", hãy hỏi lại họ đang nói về cái nào — chúng khác nhau về gần như mọi phương diện.

Các thành phần của một triển khai Looker

Ghép lại, một triển khai Looker điển hình gồm:

• Looker instance: máy chủ Looker (thường host trên Google Cloud) — nơi chạy engine sinh SQL, phục vụ giao diện, quản lý người dùng và quyền.
• Kết nối database (connection): cấu hình trỏ tới warehouse (BigQuery/Snowflake/...), gồm thông tin đăng nhập và dialect.
• LookML project: kho mã LookML, gắn với Git repository để version control.
• Explores: các điểm vào khám phá do developer định nghĩa trong LookML.
• Looks & Dashboards: kết quả người dùng lưu lại — một Look là một truy vấn/biểu đồ, một Dashboard gom nhiều Look/tile.
• Embedding: nhúng Explore/Dashboard vào ứng dụng khác (private embed, signed embed).
• API: điều khiển Looker bằng lập trình — chạy truy vấn, quản lý người dùng, tự động hoá.

Luồng làm việc: từ developer tới business user

Quy trình chuẩn trong Looker phân vai rõ ràng:

1. Developer viết LookML: kết nối warehouse, khai báo view/dimension/measure, dựng explore với các join, commit lên Git, deploy lên môi trường production.
2. Business user khám phá Explore: mở một Explore, kéo thả chiều và phép đo, thêm bộ lọc, chọn kiểu biểu đồ — hoàn toàn không viết SQL.
3. Lưu Look/Dashboard: khi có kết quả hữu ích, người dùng lưu thành Look hoặc ghim vào Dashboard để chia sẻ, lên lịch gửi email, hoặc để đồng nghiệp cùng xem.

Sự phân vai này chính là lý do Looker được yêu thích ở tổ chức lớn: logic phức tạp nằm trong tay đội dữ liệu (được review, versioned), còn việc khám phá tự phục vụ (self-service) mở ra cho hàng trăm người mà vẫn đảm bảo con số nhất quán.

Use case thực tế

Bối cảnh: Một ngân hàng số đã đưa toàn bộ dữ liệu giao dịch, khoản vay, khách hàng vào BigQuery. Đội phân tích muốn cho khoảng 200 người dùng nghiệp vụ (quản lý sản phẩm, rủi ro, vận hành) tự truy vấn số liệu mà không cần biết SQL, đồng thời phải đảm bảo mọi người tính "tỷ lệ nợ xấu", "số dư bình quân" theo đúng một công thức được kiểm soát.

Cách Looker giải quyết:

1. Đội dữ liệu tạo connection từ Looker tới BigQuery.
2. Trong LookML project (gắn Git), họ khai báo các view cho bảng khoản vay, khách hàng, chi nhánh, thời gian; định nghĩa measure như bad_debt_ratio, avg_balance một lần duy nhất, có review qua pull request.
3. Dựng các Explore như "Phân tích khoản vay" nối (join) khoản vay với chi nhánh và thời gian; giới hạn chiều/phép đo mà người dùng được thấy.
4. Người dùng nghiệp vụ vào Explore, kéo thả để trả lời "nợ xấu theo chi nhánh tháng này", "xu hướng số dư 12 tháng" — Looker sinh SQL đẩy xuống BigQuery, dữ liệu luôn tươi.
5. Họ lưu Dashboard giám sát rủi ro, chia sẻ cho ban lãnh đạo, lên lịch gửi định kỳ.
6. Đội dữ liệu tối ưu chi phí bằng cache của Looker và PDT cho các bảng tổng hợp nặng, đồng thời dùng phân quyền để mỗi khối chỉ thấy dữ liệu của mình.

Kết quả: một "nguồn sự thật" về metric rủi ro dùng chung toàn ngân hàng, tự phục vụ cho 200 người, mà logic vẫn nằm gọn trong mã LookML được version control.

Ghi nhớ

• Looker = nền tảng BI + semantic layer (LookML) của Google Cloud; người dùng cuối khám phá qua Explore mà không viết SQL.
• Kiến trúc in-database: Looker không hút dữ liệu; nó sinh SQL từ LookML và đẩy xuống warehouse (BigQuery/Snowflake/Redshift...) chạy. Ưu điểm: dữ liệu tươi, tận dụng sức warehouse, không nhân bản. Đánh đổi: phụ thuộc hiệu năng và chi phí truy vấn warehouse → cần tối ưu và PDT/cache.
• LookML định nghĩa view/dimension/measure/explore/model một lần → tái dùng, tạo single source of truth về metric, quản lý bằng Git.
• So với Power BI (in-memory + DAX + hệ sinh thái Microsoft) và Tableau (khám phá trực quan), Looker nổi bật ở governance, metric tập trung, in-database và embedding.
• Looker ≠ Looker Studio: Looker là nền tảng doanh nghiệp có phí, có LookML; Looker Studio (trước là Data Studio) là công cụ kéo thả nhẹ, có bản miễn phí, không có LookML. Hay bị nhầm — luôn hỏi rõ đang nói về cái nào.
• Thành phần: Looker instance, connection, LookML project (Git), Explores, Looks/Dashboards, embedding, API.
• Phân vai: developer viết LookML → business user khám phá Explore → lưu Look/Dashboard.
• Đây là công cụ BI, không phải SQL sandbox: mọi đoạn LookML ở loạt bài này là minh hoạ để hiểu khái niệm.

Bài tiếp theo

Đã có bức tranh tổng thể, ta đi vào từng lớp. Bài kế tiếp mở nắp ngôn ngữ mô hình hoá — cú pháp, khối và tham số nền tảng — trong Looker 2 — LookML cơ bản. Sau đó tìm hiểu cách gom bảng và nối dữ liệu ở Looker 3 — Explores & joins, tối ưu bằng Looker 5 — Derived tables & PDT, và khép lại phần vận hành ở Looker 7 — Quản trị & triển khai.