Looker 6 — Looks, dashboards & visualization

Từ mô hình đến màn hình người dùng

Năm bài trước dựng nền: LookML cơ bản, Explores & joins, Dimensions & measures, và Derived tables/PDT. Tất cả những thứ đó là tầng ngữ nghĩa (semantic layer) — nó quyết định dữ liệu đúng là gì. Bài này bước sang tầng cuối cùng: trình bày — làm sao đưa con số đó lên màn hình để một trưởng phòng, một kiểm soát viên, hay một CEO đọc được trong ba giây.

Quy ước quen thuộc vẫn giữ: Looker là công cụ BI, không phải SQL sandbox. Các đoạn LookML dưới đây là minh hoạ khái niệm. Ba đối tượng trình bày của Looker theo thứ tự tăng dần độ đóng gói: Explore (khám phá ad-hoc) → Look (một truy vấn/biểu đồ đã lưu) → Dashboard (tập nhiều tile).

Look — một truy vấn đã lưu

Trong Explore, người dùng kéo field, chọn visualization, áp filter... nhưng khi rời trang thì tất cả biến mất. Look là hành động "đóng băng" trạng thái đó lại: một truy vấn + một cách hiển thị đã lưu, có tên, nằm trong một thư mục (folder), có URL riêng.

Look có ba giá trị: tái dùng (mở lại bất cứ lúc nào, số liệu luôn tươi), chia sẻ (gửi link, cấp quyền theo folder, hoặc nhúng vào dashboard làm tile), và nhúng (embed) ra ngoài Looker.

Một điểm dễ nhầm: Look không phải là snapshot tĩnh. Nó lưu định nghĩa truy vấn, không lưu kết quả. Mỗi lần mở, Looker chạy lại (hoặc dùng cache còn hạn). Vì thế "Look doanh thu tháng" luôn phản ánh dữ liệu mới nhất mà không cần ai cập nhật thủ công.

Dashboard — tập nhiều tile

Dashboard ghép nhiều tile (ô) trên một lưới. Mỗi tile thường là một visualization; ngoài ra có tile văn bản (text), tile nút bấm (button), và tile ảnh. Sức mạnh của dashboard không nằm ở chỗ gom nhiều biểu đồ, mà ở chỗ các tile nghe chung một bộ lọc và cho phép khoan xuống chi tiết — biến một trang tĩnh thành một công cụ điều tra.

Looker có hai loại dashboard với triết lý khác nhau, đây là phần cốt lõi cần phân biệt rõ.

User-defined dashboard — tạo trên UI

Đây là dashboard người dùng tạo bằng giao diện: kéo-thả tile, chỉnh kích thước, thêm filter, chọn màu — không viết code. Nó được lưu trong cơ sở dữ liệu nội bộ của Looker (không phải trong Git).

• Ưu: nhanh, ai cũng làm được, lặp thử nghiệm tức thì, tự do bố cục.
• Nhược: không nằm trong version control (khó theo dõi thay đổi, khó review), khó chuẩn hoá hàng loạt, dễ "trôi" mỗi người một kiểu, và khó tái tạo y hệt khi cần khôi phục hay nhân bản qua nhiều instance.

LookML dashboard — dashboard as code

Đây là dashboard được định nghĩa bằng code trong file .dashboard.lkml, nằm trong repo LookML, đi qua Git như mọi thứ khác. Đây chính là tinh thần dashboard as code.

• Ưu: có version control (diff, review, rollback), tái tạo được y hệt ở mọi môi trường, chuẩn hoá được — một định nghĩa nguồn cho báo cáo dùng chung, sửa một chỗ áp cho tất cả.
• Nhược: sửa phải qua code + commit (chậm hơn kéo-thả), người dùng nghiệp vụ khó tự làm, và người dùng không sửa trực tiếp được trên UI (họ chỉ có thể "Save as" ra một bản user-defined riêng để tuỳ biến).

Nguyên tắc chọn: báo cáo chuẩn hoá, quan trọng, dùng chung toàn tổ chức → LookML dashboard (đóng băng chuẩn, kiểm soát thay đổi). Khám phá, ad-hoc, cá nhân, thử nghiệm nhanh → user-defined. Nhiều đội bắt đầu bằng user-defined để thử, khi ổn thì "chuyển hoá" (Looker cho phép trích xuất LookML từ một dashboard UI) sang LookML dashboard để đưa vào Git.

Ví dụ một LookML dashboard rút gọn

# (minh hoạ) một LookML dashboard: KPI + biểu đồ + filter dùng chung
- dashboard: giam_sat_tin_dung
  title: "Giám sát danh mục tín dụng"
  layout: newspaper          # lưới 24 cột, tự sắp xếp
  auto_run: true
  crossfilter_enabled: true

  filters:
    - name: ky_bao_cao
      title: "Kỳ báo cáo"
      type: date_filter
      default_value: "last 30 days"
    - name: chi_nhanh
      title: "Chi nhánh"
      type: field_filter
      model: banking
      explore: loans
      field: loans.branch_name
      allow_multiple_values: true

  elements:
    - name: du_no
      title: "Tổng dư nợ"
      type: single_value
      model: banking
      explore: loans
      measures: [loans.total_outstanding]
      listen:                       # tile này "nghe" filter dashboard
        ky_bao_cao: loans.disbursed_date
        chi_nhanh:  loans.branch_name
      row: 0
      col: 0
      width: 6
      height: 4

    - name: no_xau_theo_thang
      title: "Tỷ lệ nợ xấu theo tháng"
      type: looker_line
      model: banking
      explore: loans
      dimensions: [loans.disbursed_month]
      measures: [loans.npl_ratio]
      listen:
        ky_bao_cao: loans.disbursed_date
        chi_nhanh:  loans.branch_name
      row: 0
      col: 6
      width: 18
      height: 8

Đọc từ trên xuống: layout: newspaper là lưới 24 cột mặc định; khối filters khai báo hai bộ lọc cấp dashboard; mỗi phần tử trong elements là một tile với type (loại viz), nguồn (model/explore), field (dimensions/measures), vị trí (row/col/width/height), và quan trọng nhất là listen — ánh xạ filter dashboard nào áp vào field nào của tile đó. Chính listen biến "một filter" thành "áp cho nhiều tile".

Visualization — chọn đúng loại

Looker có sẵn một bộ visualization phủ hầu hết nhu cầu. Nắm cả cái gì có lẫn khi nào dùng:

• Table (bảng) — dữ liệu thô, nhiều cột, cần con số chính xác. Có bảng thường và bảng "table next-gen" hỗ trợ subtotal, conditional formatting.
• Column / Bar — so sánh giá trị giữa các hạng mục rời rạc (doanh thu theo chi nhánh). Column = cột đứng, bar = cột ngang (tốt khi nhãn dài).
• Line / Area — xu hướng theo thời gian là ứng dụng chính. Area thêm cảm giác "khối lượng tích luỹ".
• Pie / Donut — tỷ trọng phần trên tổng. Chỉ dùng khi ít hạng mục (2–5); nhiều lát cắt là khó đọc — thường nên thay bằng bar.
• Scatter — quan hệ giữa hai biến số (rủi ro vs lợi suất), phát hiện outlier.
• Map — dữ liệu địa lý (theo tỉnh/thành, toạ độ).
• Single value — một con số KPI lớn, thường kèm so sánh kỳ trước và ngưỡng màu. Là "trái tim" của hàng KPI đầu dashboard.
• Funnel — tỷ lệ chuyển đổi qua các bước (hồ sơ vay: nộp → thẩm định → duyệt → giải ngân).

Ngoài bộ dựng sẵn, Looker hỗ trợ custom visualization (viz tuỳ biến bằng JavaScript, cài từ marketplace hoặc tự viết) khi cần dạng biểu đồ đặc thù (sankey, gauge, waterfall...).

Việc chọn đúng loại không phải chuyện thẩm mỹ mà là chuyện đọc đúng. Nguyên tắc thiết kế BI chung — so sánh dùng cột, xu hướng dùng đường, tỷ trọng hạn chế pie, KPI dùng single value — được nói kỹ ở thiết kế báo cáo Power BI; cùng một triết lý áp cho Looker, chỉ khác cái tên nút bấm.

Bộ lọc & tương tác

Dashboard filters — một filter, nhiều tile

Filter cấp dashboard là thứ khiến dashboard "sống". Bạn khai báo một filter (ví dụ "Chi nhánh"), rồi mỗi tile listen filter đó tới field tương ứng của mình. Người dùng chọn "Chi nhánh Hà Nội" một lần, cả trang cùng lọc lại. Các loại filter: date_filter, number_filter, string_filter, và field_filter (dựa trên một field cụ thể, gợi ý giá trị từ dữ liệu, cho phép chọn nhiều — allow_multiple_values).

Điểm tinh tế: mỗi tile khai báo filter dashboard áp vào field nào của nó. Filter "Kỳ báo cáo" ở tile A áp vào disbursed_date, ở tile B có thể áp vào payment_date — cùng một filter, ánh xạ khác nhau tuỳ ngữ nghĩa từng tile.

Cross-filtering — click để lọc

Khi bật crossfilter_enabled, người dùng click vào một phần tử biểu đồ (một cột, một lát pie) và cả dashboard lọc theo giá trị đó. Ví dụ: click cột "Chi nhánh Đà Nẵng" trong biểu đồ bên trái, mọi tile khác lập tức chỉ còn số của Đà Nẵng. Đây là tương tác khám phá nhanh, không cần đụng vào ô filter.

Drill — khoan xuống chi tiết

Drill trả lời câu hỏi "con số này gồm những gì?". Khi bạn định nghĩa drill_fields trên một measure/dimension trong LookML, click vào giá trị đó sẽ mở một cửa sổ hiển thị các dòng chi tiết đứng sau. Ví dụ: click vào "dư nợ 12 tỷ" của một chi nhánh → drill xuống danh sách từng khoản vay tạo nên con số đó.

# (minh hoạ) khai báo drill trên measure — click là khoan xuống
measure: total_outstanding {
  type: sum
  sql: ${outstanding_amount} ;;
  value_format: "#,##0 \"₫\""
  drill_fields: [loan_id, customer_name, branch_name, disbursed_date, outstanding_amount]
}

drill_fields liệt kê các field sẽ hiện khi khoan. Đây là cầu nối tự nhiên với dimension_group thời gian ở Dimensions & measures: người dùng có thể khoan từ năm → quý → tháng → ngày nếu bạn thiết kế drill theo cấp thời gian.

Value format & series

Trình bày đẹp là một nửa của việc truyền đạt đúng.

• Value format — định dạng số/tiền/phần trăm. Đặt ngay ở measure trong LookML (value_format_name: usd hoặc value_format: "#,##0 \"₫\"") để mọi tile hiển thị nhất quán; không nên chỉnh lẻ tẻ từng tile. Với tiền đồng, dùng dấu chấm phân cách nghìn và hậu tố ₫ như đã thống nhất từ bài trước.
• Series — cấu hình từng chuỗi dữ liệu trong biểu đồ: màu sắc, tên hiển thị, loại (một số tile hỗn hợp cột+đường), trục trái/phải cho hai thang đo khác nhau.
• Axes (trục) — đặt min/max, thang log, nhãn trục; căn hai trục Y khi vẽ hai đại lượng khác đơn vị (số món vay bên trái, tỷ lệ nợ xấu % bên phải).
• Conditional formatting — tô màu ô theo giá trị (đỏ khi vượt ngưỡng, xanh khi đạt). Có thể làm ở tầng viz (bảng), hoặc mạnh hơn là dùng html: + Liquid ngay trong measure (đã thấy ở bài Dimensions & measures) để logic màu đi cùng số liệu ở mọi nơi.

Actions & phân phối

Dashboard không chỉ để nhìn — nó là điểm phát tán số liệu và kích hoạt hành động.

• Data actions — gửi dữ liệu từ một điểm trên biểu đồ tới hệ thống ngoài qua Action Hub. Ví dụ: từ một dòng khách hàng, bấm để tạo ticket, gửi email, cập nhật CRM. Đây là "hành động từ dữ liệu" thay vì chỉ đọc.
• Scheduled delivery — lên lịch gửi Look/dashboard định kỳ tới email, Slack, webhook, Amazon S3, SFTP và các đích tích hợp khác. Kèm định dạng (PDF, PNG, CSV) và điều kiện gửi. Đây là cách "báo cáo tự đến hộp thư" mỗi sáng thứ Hai.
• Alerts (cảnh báo) — theo dõi một tile và gửi thông báo khi vượt ngưỡng (ví dụ tỷ lệ nợ xấu > 3%). Người dùng đặt trực tiếp trên tile, chọn điều kiện, tần suất kiểm tra, và người nhận.
• Download / export — tải một tile hoặc cả dashboard ra CSV, Excel, PDF, PNG.

Hiệu năng dashboard

Một dashboard 30 tile là 30 truy vấn có thể bắn xuống warehouse cùng lúc mỗi lần mở — đây là nơi hiệu năng dễ sụp nhất.

• Số tile & truy vấn — mỗi tile là một query. Gom bớt tile, tránh chục biểu đồ trùng ý. Nhiều tile chia sẻ chung filter sẽ dồn tải khi filter đổi.
• Cache & datagroup — tận dụng caching của Looker; dùng datagroup để nhóm nhiều tile/PDT cùng chu kỳ làm mới (ví dụ "làm mới sau ETL 6h sáng"), tránh chạy lại query khi dữ liệu chưa đổi.
• PDT — với tính toán nặng, đẩy xuống Persistent Derived Table để tile chỉ đọc bảng đã dựng sẵn thay vì tính lại mỗi lần; chi tiết ở Derived tables/PDT. Datagroup gắn PDT và dashboard vào cùng nhịp làm mới.
• Tránh tile quá nặng — bảng trả về hàng trăm nghìn dòng, biểu đồ vẽ quá nhiều điểm, hay filter mở toàn bộ lịch sử là các thủ phạm quen thuộc. Giới hạn hàng, đặt default filter thời gian hợp lý.

Nhúng (embedding)

Khi cần đưa Looker vào một ứng dụng nội bộ hay cổng khách hàng, dùng embed. Cách chuẩn cho production là SSO embed (signed embed): server của bạn ký một URL nhúng đã xác thực và gán quyền, người dùng thấy Look/dashboard Looker ngay trong app mà không cần đăng nhập Looker riêng. Chủ đề quyền hạn, chuẩn hoá và bảo mật khi nhúng thuộc về Quản trị & triển khai — ở đây chỉ cần nhớ: embedding là con đường đưa dashboard ra ngoài Looker một cách có kiểm soát.

Use case thực tế: dashboard giám sát tín dụng ngân hàng

Ghép mọi mảnh vào một bài toán quen thuộc — trang giám sát danh mục tín dụng cho ban lãnh đạo chi nhánh:

1. Hàng KPI trên cùng — bốn tile single_value: Tổng dư nợ, Số hồ sơ giải ngân trong kỳ, Tỷ lệ nợ xấu (NPL), Lãi dự thu. Mỗi tile so sánh với kỳ trước và tô màu theo ngưỡng.
2. Biểu đồ xu hướng — một tile looker_line NPL theo tháng (trục phải %) chồng số dư nợ (trục trái, cột) để thấy quan hệ tăng trưởng vs chất lượng.
3. Cơ cấu — một bar "dư nợ theo nhóm nợ (1–5)" và một bar "dư nợ theo sản phẩm".
4. Filter dùng chung — "Kỳ báo cáo" (date) và "Chi nhánh" (field_filter, chọn nhiều). Mọi tile listen hai filter này; đổi chi nhánh một lần, cả trang lọc lại.
5. Drill — click vào cột "Nhóm 5" (nợ có khả năng mất vốn) → khoan xuống danh sách từng khoản vay: mã HĐ, khách hàng, chi nhánh, ngày giải ngân, dư nợ. Kiểm soát viên đi thẳng từ tổng thể tới hồ sơ cụ thể.
6. Alert — cảnh báo khi NPL toàn danh mục vượt 3%, gửi Slack cho phòng quản lý rủi ro.
7. Scheduled delivery — bản PDF gửi email ban giám đốc mỗi sáng thứ Hai lúc 7h.

Nếu đây là báo cáo chuẩn của cả hệ thống ngân hàng → định nghĩa bằng LookML dashboard trong Git để mọi chi nhánh dùng đúng một định nghĩa, review được khi thay đổi công thức NPL, và tái tạo được khi chuyển môi trường.

Ghi nhớ

• Look = một truy vấn/biểu đồ đã lưu (lưu định nghĩa, không phải kết quả — luôn tươi); Dashboard = tập nhiều tile nghe chung filter.
• User-defined dashboard (UI, lưu trong DB Looker): nhanh, linh hoạt, nhưng không version control, khó chuẩn hoá. LookML dashboard (.dashboard.lkml, trong Git): dashboard as code — review/rollback/tái tạo được, hợp cho báo cáo chuẩn hoá; nhược là sửa phải qua code.
• listen là chìa khoá: ánh xạ filter dashboard tới field từng tile → một filter áp cho nhiều tile.
• Cross-filtering = click biểu đồ để lọc cả trang; drill (drill_fields) = khoan xuống chi tiết đứng sau một con số.
• Chọn viz theo mục đích: cột (so sánh), đường (xu hướng), single value (KPI), pie hạn chế, funnel (chuyển đổi) — cùng triết lý thiết kế BI như Power BI.
• Value format đặt ở measure để nhất quán toàn dashboard; conditional formatting tô màu theo ngưỡng.
• Phân phối: data actions (Action Hub), scheduled delivery (email/Slack/webhook/S3/SFTP), alerts (vượt ngưỡng), export.
• Hiệu năng: mỗi tile là một query — dùng cache/datagroup/PDT, giới hạn dòng, đặt default filter thời gian, tránh tile quá nặng.
• Embed SSO để đưa dashboard vào app ngoài một cách có kiểm soát.

Đọc tiếp: Derived tables & PDT để tối ưu tile nặng, và Quản trị & triển khai cho quyền hạn, Git workflow và embedding an toàn.