Looker 7 — Quản trị, phân quyền & triển khai

Khép lại series: từ mô hình hoá đến vận hành

Suốt series này bạn đã đi từ Tổng quan Looker, qua LookML cơ bản, explore & join, dimension/measure, rồi Derived tables & PDT và Dashboards & visualization. Tất cả những phần đó trả lời câu hỏi "làm sao mô tả dữ liệu và trình bày nó". Bài cuối này trả lời câu hỏi khác, khó hơn về mặt tổ chức: ai được thấy cái gì, thay đổi được đưa lên production ra sao, và làm thế nào để hoá đơn warehouse không tăng phi mã.

Quy ước không đổi: Looker là công cụ BI, không phải một SQL sandbox để bạn gõ lệnh chạy thử. Mọi đoạn LookML dưới đây là minh hoạ khái niệm — cấu trúc và tên tham số là thật, nhưng bạn khai báo chúng trong project LookML rồi để Looker sinh SQL, chứ không "chạy" trực tiếp ở đâu cả.

Quản lý nội dung: folder, quyền, chứng nhận

Nội dung mà người dùng cuối tương tác — Look (một truy vấn đã lưu), dashboard, và board (trang tổng hợp link tới nội dung) — đều nằm trong hệ thống folder (thư mục).

Có hai loại folder cần phân biệt:

• Personal folder: mỗi user có một thư mục cá nhân. Nội dung ở đây mặc định chỉ chủ sở hữu thấy. Đây là nơi người ta "nháp".
• Shared folders: cây thư mục dùng chung của tổ chức. Đây mới là nơi nội dung được coi là "chính thức" và chia sẻ giữa các nhóm.

Trên mỗi shared folder, admin (hoặc người được uỷ quyền) gán quyền cho từng group:

• View access: nhóm được xem nội dung trong folder.
• Manage access, edit: nhóm được tạo, sửa, xoá nội dung và quản lý chính folder đó.

Quyền folder tách bạch với quyền dữ liệu (phần sau). Một người có thể thấy một dashboard trong folder nhưng vẫn không thấy được số liệu nếu không có quyền truy cập model bên dưới hoặc bị access_filter chặn.

Certified content (nội dung được chứng nhận) là một thực hành quản trị quan trọng: khi số lượng dashboard tăng lên hàng trăm, người dùng không biết cái nào "đúng". Nhiều tổ chức lập một shared folder riêng (ví dụ "Certified / Official") chỉ đội data quản lý được, để đánh dấu rõ đâu là báo cáo đã qua kiểm định. Đây là mẫu tổ chức tương đương với việc gắn nhãn "endorsed/certified" ở các nền tảng BI khác.

Phân quyền trong Looker: role = permission set + model set

Đây là mô hình quyền cốt lõi và rất dễ nhầm. Trong Looker, một role được ghép từ hai phần:

role  =  permission set   +   model set        (minh hoạ)
         (ĐƯỢC LÀM GÌ)         (TRÊN MODEL NÀO)

• Permission set: tập các hành động (permission) được phép, ví dụ access_data, see_looks, explore, create_table_calculations, download_with_limit, develop, deploy, manage_models... Permission develop là thứ cho phép một người vào dev mode để sửa LookML.
• Model set: danh sách các model (file .model) mà người dùng được truy cập. Nếu model finance không nằm trong model set của bạn, bạn không thấy explore nào thuộc model đó — bất kể permission set rộng đến đâu.

Tách rời hai chiều này rất mạnh: cùng một permission set "Explorer" (được explore & download) có thể ghép với model set "Sales" cho nhóm kinh doanh và model set "Finance" cho nhóm tài chính, tạo ra hai role khác nhau về phạm vi dữ liệu nhưng giống nhau về hành động.

Cấu trúc gán quyền theo tầng:

User  →  Group(s)  →  Role(s)  =  Permission set + Model set     (minh hoạ)

Nguyên tắc vận hành: luôn gán role cho group, không gán trực tiếp cho user. User được đưa vào group (thường đồng bộ từ SSO/LDAP/SAML/OIDC), group nhận role. Khi một nhân viên chuyển bộ phận, bạn chỉ đổi group của họ ở nguồn danh tính, quyền tự cập nhật. Đây là điểm gặp nhau giữa quản trị Looker và IAM của tổ chức.

Ba tầng phân quyền này giải quyết được "user thấy được model/explore/nội dung nào". Nhưng chúng không giải quyết được "trong một explore mà user được phép xem, họ thấy những hàng dữ liệu nào". Đó là việc của LookML.

Bảo mật dữ liệu ngay trong LookML

Looker cung cấp ba cơ chế bảo mật khai báo ngay trong mã LookML — nghĩa là bảo mật đi cùng mô hình, được version-control, và review được như code.

access_grant + required_access_grants — bảo mật cấp đối tượng (object-level)

access_grant định nghĩa một "chìa khoá": nó gắn với một user_attribute và một danh sách allowed_values. Ai có user attribute rơi vào danh sách đó thì "cầm chìa".

# trong file .model — định nghĩa chìa khoá        (minh hoạ)
access_grant: can_view_pii {
  user_attribute: pii_clearance
  allowed_values: [ "yes" ]
}

access_grant: finance_dept {
  user_attribute: department
  allowed_values: [ "finance", "exec" ]
}

Sau đó required_access_grants gắn chìa khoá vào một cấu trúc để ẩn nó với người không có quyền. Tham số này dùng được ở cấp field, view, join, hoặc explore:

# ẩn field nhạy cảm ở cấp dimension              (minh hoạ)
view: customer {
  dimension: national_id {
    required_access_grants: [ can_view_pii ]
    sql: ${TABLE}.national_id ;;
  }
  dimension: name { sql: ${TABLE}.name ;; }
}

# ẩn nguyên explore                               (minh hoạ)
explore: gl_transactions {
  required_access_grants: [ finance_dept ]
}

Điểm quan trọng về ngữ nghĩa: khi liệt kê nhiều access grant trong required_access_grants, user phải có tất cả (AND) mới truy cập được. Và tác dụng là ẩn hoàn toàn — field/explore không xuất hiện trong danh sách, không phải chỉ "báo lỗi khi bấm vào". Đây chính là mô hình object-level / column-level security: che cột national_id khỏi những ai không có pii_clearance = yes.

access_filter — bảo mật cấp hàng (row-level security)

access_grant che cột/đối tượng. access_filter lọc hàng. Đây là row-level security (RLS) của Looker, khai báo trong explore:

# trong file .model — RLS theo chi nhánh          (minh hoạ)
explore: transactions {
  access_filter: {
    field: branch.branch_code       # field ĐẦY ĐỦ scope: view.field
    user_attribute: allowed_branch  # thuộc tính của user hiện tại
  }
}

Cách hoạt động: mỗi khi user chạy bất kỳ query nào trên explore transactions, Looker tự động thêm một điều kiện lọc vào SQL, so khớp branch.branch_code với giá trị user_attribute allowed_branch của chính user đó. Nhân viên chi nhánh Hà Nội (allowed_branch = "HN01") chỉ nhận về hàng có branch_code = HN01, còn nhân viên Đà Nẵng nhận hàng của Đà Nẵng — cùng một dashboard, cùng một explore, khác dữ liệu.

Hai lưu ý cú pháp quan trọng, dễ sai:

1. field phải ghi đầy đủ scope view_name.field_name (ví dụ branch.branch_code), không được viết tắt branch_code.
2. Nếu user attribute cho phép nhiều giá trị (ví dụ một quản lý vùng phụ trách HN01,HN02,HN03), Looker sẽ lọc theo kiểu IN (...). Bạn khai báo user attribute cho phép nhiều giá trị và ngăn cách bằng dấu phẩy.

sql_always_where — ràng buộc bổ sung, không bỏ qua được

Ngoài access_filter, explore còn có sql_always_where — một điều kiện WHERE luôn được thêm vào mọi query của explore đó, kể cả khi user không đặt filter nào. Nó không phụ thuộc user attribute (dùng cho ràng buộc chung, ví dụ luôn loại bản ghi test is_test = false), nhưng có thể kết hợp với Liquid để tham chiếu user attribute nếu cần logic phức tạp hơn access_filter.

explore: transactions {
  sql_always_where: ${status} != 'void' ;;   # luôn ẩn giao dịch huỷ  (minh hoạ)
}

So sánh với RLS của Power BI

Nếu bạn đã đọc Power BI 8 — Governance & deployment, điểm khác biệt kiến trúc rất đáng chú ý:

Điểm chung: cả hai đều tách ai là user (từ SSO) khỏi dữ liệu nào tương ứng (một bảng ánh xạ user → chi nhánh/vùng). Điểm khác cốt lõi: Looker in-database nên RLS trở thành mệnh đề WHERE trong SQL gửi xuống warehouse.

user_attribute — mảnh ghép nối user với dữ liệu

user_attribute (thuộc tính người dùng) là trung tâm của mọi thứ ở trên. Admin định nghĩa các thuộc tính (ví dụ allowed_branch, department, pii_clearance), rồi gán giá trị theo group hoặc theo từng user, và (rất tiện) đồng bộ giá trị từ SSO/SAML khi user đăng nhập.

User attribute được dùng ở nhiều nơi, không chỉ RLS:

• access_filter / access_grant: như đã trình bày.
• Tham số kết nối theo user: một số cấu hình cho phép chèn user attribute vào chuỗi kết nối database, để mỗi người thực sự kết nối bằng credential warehouse riêng — bảo mật được đẩy hẳn xuống tầng DB.
• Giá trị mặc định động: điền sẵn filter hoặc tham số dashboard theo vùng/chi nhánh của user.
• Trong Liquid: tham chiếu _user_attributes['name'] để tạo SQL/label động.

Chuỗi liên kết đầy đủ:

SSO/LDAP → group → user_attribute (allowed_branch = "HN01")
                        │
                        ▼
        access_filter thêm  WHERE branch.branch_code = 'HN01'
                        │
                        ▼
              SQL đẩy xuống warehouse → user chỉ thấy chi nhánh mình   (minh hoạ)

Git & vòng đời phát triển LookML

Đây là điểm phân biệt lớn giữa Looker và các công cụ BI kéo-thả: LookML là mã, và mọi project LookML gắn với một Git repository (GitHub, GitLab, Bitbucket, Azure DevOps...). Quản trị phát triển vì thế là quản trị Git.

Vòng đời một thay đổi:

Các khái niệm cần nắm:

• Development Mode (dev mode): một chế độ bật/tắt của mỗi developer. Trong dev mode, họ làm việc trên nhánh cá nhân riêng; thay đổi không ảnh hưởng ai khác cho tới khi được deploy. Người dùng thường luôn ở Production Mode.
• Validate: trước khi commit, chạy LookML Validator (kiểm cú pháp/tham chiếu), và nên chạy cả SQL validator (thử sinh SQL) và Content validator (phát hiện dashboard/Look bị hỏng do đổi tên field). Đây là "test" của thế giới LookML.
• Commit & PR: commit đưa thay đổi lên nhánh cá nhân. Nhiều tổ chức bật pull request workflow, buộc mọi thay đổi phải qua review trên Git provider trước khi merge vào nhánh production — đúng như quy trình review code.
• Deploy to Production: sau khi merge vào nhánh production, admin (hoặc webhook tự động) thực hiện deploy, đồng bộ mã production của Looker với commit mới nhất trên nhánh chính.
• Import project: một project LookML có thể import file từ project khác, cho phép tách phần dùng chung (ví dụ thư viện định nghĩa metric chuẩn) khỏi phần riêng của từng team — một dạng modular hoá và tái sử dụng.

Nguyên tắc quản trị: coi LookML như source code thật — nhánh, PR, review, môi trường tách biệt. Đây là lý do Looker phù hợp với các tổ chức muốn "analytics as code".

Vận hành & tối ưu chi phí warehouse

Kiến trúc in-database của Looker (đã bàn ở Tổng quan) có mặt trái về chi phí: Looker không lưu trữ dữ liệu, nên mỗi query của mỗi user đều là một truy vấn thật xuống warehouse — và với các warehouse tính tiền theo lượng dữ liệu quét hoặc thời gian tính toán (BigQuery, Snowflake...), mỗi lần bấm nút là một khoản chi. Một dashboard có 12 tile được 50 người mở mỗi sáng là hàng trăm query/ngày.

Các đòn bẩy tối ưu (đã giới thiệu rải rác trong series, đây là góc nhìn chi phí):

• Datagroup & caching: gắn datagroup với persist_for/sql_trigger để Looker phục vụ kết quả từ cache thay vì chạy lại query khi dữ liệu chưa đổi. Đây là công cụ tiết kiệm chi phí số một — trả lời từ cache là miễn phí với warehouse.
• PDT (Persistent Derived Tables): vật chất hoá kết quả nặng thành bảng, tính một lần theo lịch thay vì mỗi lần user query (xem Derived tables & PDT).
• Aggregate awareness: bạn khai báo sẵn các bảng tổng hợp (rollup) ở nhiều mức độ chi tiết; khi một query chỉ cần số liệu theo tháng, Looker tự chọn bảng tổng hợp nhỏ thay vì quét bảng fact chi tiết hàng tỷ dòng. Người dùng không cần biết — họ vẫn explore như thường, nhưng SQL sinh ra rẻ hơn nhiều bậc.
• Giới hạn query: đặt row limit mặc định, cấu hình query timeout, dùng permission download_with_limit thay vì cho tải không giới hạn.
• Giám sát bằng System Activity: Looker có sẵn model System Activity — chính là các dashboard/explore mô tả chính bản thân Looker: query nào chậm nhất, user nào chạy nhiều nhất, dashboard nào tốn tài nguyên, tỷ lệ cache hit. Admin dùng đây để tìm "query đắt" và tối ưu có trọng điểm.

Về mặt warehouse, xem thêm BigQuery — chi phí & hiệu năng: partitioning, clustering và tránh SELECT * ở tầng bảng bổ trợ trực tiếp cho việc giảm hoá đơn mà mỗi query Looker phải trả.

Use case thực tế: RLS chi nhánh trong ngân hàng

Bài toán: hệ thống báo cáo giao dịch dùng chung một dashboard "Hoạt động chi nhánh", nhưng mỗi nhân viên chi nhánh chỉ được xem dữ liệu chi nhánh của mình, giám đốc vùng xem được các chi nhánh trong vùng, ban lãnh đạo xem tất cả.

Thiết kế:

1. Nguồn danh tính: SSO đẩy sẵn thuộc tính chi nhánh khi đăng nhập. Trong Looker tạo user attribute allowed_branch (cho phép nhiều giá trị, ngăn bằng dấu phẩy).
2. Gán giá trị:
   • Nhân viên HN01 → allowed_branch = "HN01".
   • Giám đốc vùng Bắc → allowed_branch = "HN01,HN02,HN03".
   • Group "Ban lãnh đạo" → không đặt access_filter (hoặc user attribute nhận toàn bộ), thấy tất cả.
3. LookML:

explore: transactions {
  access_filter: {
    field: branch.branch_code
    user_attribute: allowed_branch
  }
}

# đồng thời che cột nhạy cảm với nhân viên thường  (minh hoạ)
view: customer {
  dimension: national_id {
    required_access_grants: [ can_view_pii ]
    sql: ${TABLE}.national_id ;;
  }
}

4. Kết quả: một dashboard duy nhất, một explore duy nhất. Nhân viên HN01 mở lên thấy SQL được Looker chèn WHERE branch.branch_code IN ('HN01'); giám đốc vùng thấy IN ('HN01','HN02','HN03'). Không ai bảo trì nhiều bản dashboard, không rò rỉ dữ liệu chéo chi nhánh, và cột national_id chỉ hiện với người có pii_clearance.

5. Quản trị: toàn bộ logic này nằm trong LookML → đi qua dev mode → validate → PR → deploy, có lịch sử Git, review được. Khi kiểm toán hỏi "ai được thấy gì", câu trả lời nằm trong repo.

Ghi nhớ

• Role = permission set (được làm gì) + model set (trên model nào). Luôn gán role cho group, đồng bộ group từ SSO/LDAP.
• Folder kiểm soát quyền nội dung (Look/dashboard/board); nó tách biệt với quyền dữ liệu. Dùng folder "certified" để đánh dấu báo cáo chính thức.
• required_access_grants + access_grant = bảo mật object/column-level (ẩn field/explore). Nhiều grant → phải có tất cả (AND).
• access_filter = row-level security: lọc hàng theo user_attribute, field phải ghi đầy đủ scope view.field. sql_always_where cho ràng buộc luôn áp dụng.
• user_attribute là mảnh nối user (từ SSO) với dữ liệu; còn dùng cho kết nối theo user, giá trị mặc định động và Liquid.
• LookML là source of truth: dev mode → validate → commit → PR/review → deploy to production. Coi analytics như code.
• In-database ⇒ mỗi query tốn tiền warehouse. Tối ưu bằng datagroup/cache, PDT, aggregate awareness, row limit, và giám sát System Activity để săn query đắt.

Đọc tiếp / liên quan: Looker 1 — Tổng quan · Looker 5 — Derived tables & PDT · Looker 6 — Dashboards & visualization · Power BI 8 — Governance & deployment · BigQuery — Chi phí & hiệu năng