Ngân hàng đề — Google Cloud Associate Data Practitioner

Đáp án

D — DENSE_RANK()

Vì sao đúng

Đề nêu hai yêu cầu về cách xếp hạng: giá trị bằng nhau phải cùng hạng, và dãy hạng phải LIÊN TỤC, KHÔNG có khoảng trống. Chỉ DENSE_RANK() thoả cả hai.

⚠ Điểm mấu chốt — so ba hàm trên chính ví dụ của đề:

Doanh số: 1000, 950, 950, 900

ROW_NUMBER()  → 1, 2, 3, 4
                ⚠ hai người bằng nhau
                  vẫn khác hạng

RANK()        → 1, 2, 2, 4
                ⚠ cùng hạng, nhưng
                  BỎ QUA số 3

DENSE_RANK()  → 1, 2, 2, 3      ← đề yêu cầu
                ✓ cùng hạng
                ✓ liên tục, không hụt

⚠ Truy vấn hoàn chỉnh:

SELECT
  employee_id,
  sales_month,
  total_sales,
  DENSE_RANK() OVER (
    PARTITION BY sales_month
    ORDER BY total_sales DESC
  ) AS hang
FROM `du_an.sales_performance`;

        ↓
    PARTITION BY sales_month
      → xếp hạng RIÊNG trong TỪNG THÁNG
    ORDER BY total_sales DESC
      → cao nhất là hạng 1

⚠ Mẹo nhớ tên gọi:

DENSE = "đặc, không có lỗ hổng"
        ↓
    → DENSE_RANK cho dãy ĐẶC,
      không hụt số
        ↓
    RANK thường thì "thưa" — có lỗ hổng
    sau mỗi lần đồng hạng

Vì sao các phương án khác sai

• A (RANK()) — đây là phương án gần nhất và đúng vế "cùng hạng khi bằng nhau", nhưng nó bỏ qua số tiếp theo: cho ra 1, 2, 2, 4 thay vì 1, 2, 2, 3. Đề cấm điều này.

• C (ROW_NUMBER()) — luôn cho số khác nhau, hai người bằng nhau vẫn bị xếp khác hạng.

• B (NTILE(100)) — chia dữ liệu thành 100 nhóm bằng nhau (phân vị), không phải xếp hạng theo yêu cầu.

Ghi nhớ

⚠ Bốn hàm xếp hạng — bảng phải thuộc: | Hàm | Với 1000, 950, 950, 900 | Đặc điểm | |---|---|---| | ROW_NUMBER() | 1, 2, 3, 4 | luôn khác nhau | | RANK() | 1, 2, 2, 4 | cùng hạng, CÓ khoảng trống | | DENSE_RANK() | 1, 2, 2, 3 | cùng hạng, KHÔNG khoảng trống | | NTILE(n) | chia thành n nhóm | phân vị | | Mẹo nhớ | DENSE = đặc = không hụt số |

Từ khoá nhận diện:

"đồng hạng, không được hụt số" → DENSE_RANK() "đồng hạng, hạng tiếp theo nhảy cóc" → RANK() "mỗi dòng một số duy nhất" → ROW_NUMBER() "chia thành nhóm phần trăm" → NTILE() "lấy dòng mới nhất mỗi nhóm" → ROW_NUMBER() + WHERE rn = 1

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có trường hợp đồng hạng không | GROUP BY sales_month, total_sales HAVING COUNT(*) > 1 | | Hạng có hụt số không | SELECT DISTINCT hang ORDER BY 1 | | Xếp hạng đúng phạm vi chưa | kiểm tra PARTITION BY có đúng cột tháng |

Và một cú pháp rất đáng biết của BigQuery giúp truy vấn kiểu này gọn hơn hẳn: QUALIFY. Thay vì bọc cả truy vấn vào một lớp subquery chỉ để lọc theo hạng, QUALIFY DENSE_RANK() OVER (...) <= 3 làm đúng việc đó trong một dòng — và truy vấn đọc lên giống hệt cách bạn mô tả yêu cầu bằng lời.

Đáp án

D — Tạo MỘT topic và HAI subscription riêng, mỗi hệ thống một cái.

Vì sao đúng

Trong Pub/Sub, mỗi subscription nhận một BẢN SAO ĐỘC LẬP của MỌI thông điệp trong topic. Đó chính là cơ chế để hai hệ thống hạ nguồn đều nhận đủ mọi thông điệp.

⚠ Điểm mấu chốt — subscription là ranh giới của việc phân phát:

        TOPIC "trang-thai"
              │
    ┌─────────┴─────────┐
    │                   │
SUBSCRIPTION A     SUBSCRIPTION B
    │                   │
Dataflow            Cloud Function
(cảnh báo)          (ghi log)
        ↓
    ⚠ MỖI subscription có HÀNG ĐỢI RIÊNG
    ⚠ MỖI subscription nhận ĐỦ mọi thông điệp
    ⚠ Ack ở A KHÔNG ảnh hưởng B

⚠ ⚠ Vì sao dùng CHUNG một subscription là sai hoàn toàn:

Hai hệ thống cùng đọc MỘT subscription
        ↓
    Pub/Sub coi chúng là HAI WORKER
    của CÙNG một bên nhận
        ↓
    → thông điệp được CHIA cho hai bên
    → mỗi thông điệp chỉ MỘT bên nhận
        ↓
    ⚠ Dataflow nhận ~50%
    ⚠ Cloud Function nhận ~50%
    ⚠ Không bên nào có đủ dữ liệu
        ↓
    → đây là lỗi thiết kế kinh điển

⚠ Vì sao hai topic riêng cũng không đúng:

Hai topic
        ↓
    Ứng dụng phải PUBLISH HAI LẦN
        ↓
    ⚠ Publish lần một thành công,
      lần hai lỗi → dữ liệu LỆCH nhau
    ⚠ Thêm hệ thống thứ ba → SỬA MÃ ứng dụng
        ↓
    Trái hẳn với mục tiêu TÁCH RỜI

⚠ Tạo cấu hình đúng:

gcloud pubsub topics create trang-thai

gcloud pubsub subscriptions create sub-canh-bao \
  --topic=trang-thai            # Dataflow pull

gcloud pubsub subscriptions create sub-ghi-log \
  --topic=trang-thai \
  --push-endpoint=https://...  # Cloud Function push

Xem thêm câu #12949 (cùng lô): cùng tình huống fan-out nhưng hỏi CHỌN DỊCH VỤ nào → khoá là Pub/Sub. Câu này hỏi CẤU HÌNH thế nào → một topic, hai subscription. Hai câu bổ sung nhau, hoàn toàn nhất quán.

Vì sao các phương án khác sai

• C (một topic, hai hệ thống đọc chung MỘT subscription) — đây là phương án bẫy chính: thông điệp bị CHIA ĐÔI giữa hai bên nhận, không bên nào có đủ.

• B (hai topic riêng) — buộc ứng dụng publish hai lần, dễ lệch dữ liệu, và mất tính tách rời.

• A (topic đẩy thẳng tới cả hai) — topic KHÔNG đẩy trực tiếp tới đâu cả; việc phân phát luôn đi qua subscription.

Ghi nhớ

⚠ Topic ↔ Subscription — bảng phải thuộc: | Khái niệm | Vai trò | |---|---| | Topic | nơi PUBLISH thông điệp | | Subscription | hàng đợi RIÊNG cho MỘT bên nhận logic | | Nhiều subscription trên một topic | mỗi cái nhận ĐỦ mọi thông điệp (fan-out) | | Nhiều worker trên MỘT subscription | CHIA việc cho nhau (load balancing) | | Nhớ | fan-out ở tầng SUBSCRIPTION, không phải tầng worker |

Từ khoá nhận diện:

"hai hệ thống độc lập đều nhận đủ" → hai SUBSCRIPTION "nhiều worker chia tải cùng một việc" → một subscription, nhiều worker "nạp thẳng vào BigQuery" → BigQuery subscription "ghi thành tệp trong GCS" → Cloud Storage subscription "lọc bớt thông điệp cho một bên nhận" → subscription filter

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Topic có mấy subscription | gcloud pubsub topics list-subscriptions <topic> | | Mỗi bên nhận có tồn đọng không | num_undelivered_messages theo từng subscription | | Hai bên có nhận đủ như nhau không | so số bản ghi ở hai đích |

Và một phép kiểm tra rất đáng làm sau khi dựng xong kiến trúc này: so số bản ghi ở hai đích trong cùng một khoảng thời gian. Nếu hai con số xấp xỉ một nửa của nhau, gần như chắc chắn hai hệ thống đang chia nhau một subscription duy nhất — triệu chứng đó dễ bị nhầm thành "một bên xử lý chậm" và có thể tồn tại rất lâu trước khi ai đó phát hiện.

Đáp án

D — Connected Sheets.

Vì sao đúng

Yêu cầu là ngay trong Google Sheets, nối dữ liệu hạn mức trong Sheet với dữ liệu bán hàng trong BigQuery, và làm mới dễ dàng. Connected Sheets sinh ra cho đúng việc này.

⚠ Điểm mấu chốt — Sheets nói chuyện trực tiếp với BigQuery:

Google Sheets
        ↓
    Data → Data connectors → Connect to BigQuery
        ↓
    Chọn bảng company_sales.all_transactions
        ↓
    ⚠ Dữ liệu KHÔNG được tải hết vào Sheet
    → Sheet chỉ giữ một KẾT NỐI
    → mọi phép tính chạy Ở PHÍA BIGQUERY
        ↓
    → làm việc được với bảng HÀNG TỈ DÒNG
      trong một bảng tính

⚠ Vì sao "hàng tỉ dòng trong Sheets" là chuyện có thật:

Google Sheets giới hạn khoảng
    10 triệu ô
        ↓
    Nhập một bảng lớn → KHÔNG THỂ

Connected Sheets
        ↓
    Chỉ hiển thị PHẦN KẾT QUẢ
    (preview, pivot, biểu đồ, hàm)
        ↓
    Phép tính đẩy xuống BigQuery
        ↓
    → giới hạn ô không còn là vấn đề

⚠ Nối dữ liệu Sheet với dữ liệu BigQuery:

Sheet 1: hạn mức theo vùng (nhập tay)
Sheet 2: PIVOT TABLE từ Connected Sheets
         → doanh số thực tế theo vùng
        ↓
    Sheet 3: dùng VLOOKUP hoặc QUERY
             ghép hai bảng lại
        ↓
    → báo cáo so sánh hạn mức và thực tế
        ↓
    Bấm "Refresh" → số liệu mới nhất
    Hoặc đặt LỊCH làm mới tự động

Vì sao các phương án khác sai

• C (xuất BigQuery ra CSV rồi nhập vào Sheets) — đây là phương án gần nhất về mặt "làm được", nhưng nó thủ công, không làm mới được, và giới hạn số ô của Sheets chặn ngay với dữ liệu lớn.

• A (Looker) — nền tảng BI mạnh, nhưng đề nói rõ báo cáo phải nằm TRONG Google Sheets, và người dùng là nhà phân tích quen bảng tính.

• B (Dataflow) — công cụ xử lý dữ liệu quy mô lớn, hoàn toàn quá tay và không tạo ra báo cáo trong Sheets.

Ghi nhớ

⚠ Connected Sheets — điều cần nhớ: | Điểm | Nội dung | |---|---| | Bản chất | Sheets nối THẲNG tới BigQuery | | Dữ liệu | KHÔNG tải hết vào Sheet — phép tính chạy ở BigQuery | | Công cụ dùng được | pivot table, biểu đồ, hàm, bộ lọc | | Làm mới | thủ công hoặc THEO LỊCH | | Quyền | người dùng cần quyền BigQuery của chính họ | | Chi phí | mỗi lần làm mới là một truy vấn tính tiền |

Từ khoá nhận diện:

"phân tích BigQuery ngay trong Google Sheets" → Connected Sheets "dashboard chia sẻ rộng" → Looker Studio "chỉ số thống nhất toàn công ty" → Looker "phân tích bằng Python" → Vertex AI Notebooks "xuất CSV rồi nhập tay" → hầu như luôn là phương án kém nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết nối trỏ vào bảng nào | menu Data → Data connectors trong Sheet | | Mỗi lần làm mới tốn bao nhiêu | INFORMATION_SCHEMA.JOBS trong BigQuery | | Ai xem được | quyền chia sẻ của Sheet và quyền BigQuery của từng người |

Và một lựa chọn kiến trúc đáng cân nhắc nếu bảng hạn mức được dùng ở nhiều báo cáo: đưa chính Sheet đó vào BigQuery làm external table. Quản lý viên vẫn cập nhật hạn mức trong Sheet như cũ, nhưng phép so sánh hạn mức với thực tế chuyển hẳn sang SQL — và mọi báo cáo khác đều dùng chung một nguồn thay vì mỗi người tự VLOOKUP một kiểu.

Đáp án

A — Tạo một Cloud Run function với trigger từ Cloud Storage, hàm này gọi Dataproc API để nộp job.

Vì sao đúng

Điểm quyết định của đề là tệp được tải lên vào một thời điểm KHÔNG ĐOÁN TRƯỚC ĐƯỢC mỗi ngày, và job phải chạy NGAY KHI tải lên xong. Chỉ kiến trúc hướng sự kiện đáp ứng được.

⚠ Điểm mấu chốt — sự kiện finalized báo tệp đã ghi XONG:

Tải tệp Parquet lên bucket
        ↓
    Cloud Storage phát sự kiện
    object.v1.FINALIZED
        ↓
    ⚠ "finalized" = ghi HOÀN TẤT,
      không phải "bắt đầu tải"
        ↓
    Cloud Run function được gọi
        ↓
    Hàm gọi Dataproc API nộp job
    lên cụm đang có
        ↓
    → tự động hoàn toàn, không có độ trễ chờ

⚠ Nội dung hàm — rất ngắn:

from google.cloud import dataproc_v1

def xu_ly(event, context):
    ten = event['name']
    if not ten.endswith('.parquet'):
        return                       # lọc theo đuôi
    client = dataproc_v1.JobControllerClient(...)
    client.submit_job(project_id=..., region='...',
        job={'placement': {'cluster_name': 'cum-cua-toi'},
             'spark_job': {...,
               'args': [f"gs://{event['bucket']}/{ten}"]}})

        ↓
    ⚠ Hàm chỉ NỘP job rồi trả về ngay
    → không chờ Spark chạy xong
    → tránh chạm giới hạn thời gian

⚠ Vì sao Cloud Scheduler không dùng được ở đây:

Cloud Scheduler chạy theo GIỜ CỐ ĐỊNH
        ↓
    Tệp tới lúc 2h → job chạy lúc 23h
    → trễ 21 giờ

    Tệp tới lúc 23h30 → job chạy lúc 23h
    → xử lý tệp của HÔM QUA
        ↓
    ⚠ Thời điểm không đoán trước
      → lịch cố định luôn sai

Xem thêm câu #12934 (cùng lô): cũng là tự động hoá, nhưng ở đó công việc chạy đúng 1 giờ sáng mỗi ngày → khoá là Cloud Scheduler. Hai khoá khác nhau vì một bên theo LỊCH, một bên theo SỰ KIỆN — hoàn toàn nhất quán.

Vì sao các phương án khác sai

• D (Cloud Scheduler chạy job vào giờ cố định mỗi đêm) — đây là phương án gần nhất và tự động thật, nhưng không phản ứng theo sự kiện: có thể chạy khi tệp chưa tới, hoặc trễ nhiều giờ sau khi tệp đã tới.

• C (Cloud Monitoring tạo cảnh báo để kích hoạt job) — Monitoring dùng cho chỉ số và cảnh báo vận hành, không phải cơ chế kích hoạt luồng dữ liệu; đường đi vòng và không đáng tin.

• B (theo dõi thủ công rồi bấm chạy) — không tự động, trái yêu cầu.

Ghi nhớ

⚠ Lịch ↔ Sự kiện — bảng phải thuộc: | Kích hoạt theo | Khi nào dùng | Công cụ | |---|---|---| | LỊCH | thời điểm biết trước, đều đặn | Cloud Scheduler | | SỰ KIỆN | thời điểm KHÔNG đoán trước | Cloud Run function + trigger, Eventarc | | PHỤ THUỘC | nhiều bước nối nhau | Cloud Composer | | THỦ CÔNG | việc một lần | console, CLI | | Nhận diện | "không đoán trước được" → sự kiện |

Từ khoá nhận diện:

"ngay khi tệp được tải lên" → trigger Cloud Storage "đúng 1 giờ sáng mỗi ngày" → Cloud Scheduler "nhiều bước phụ thuộc nhau" → Cloud Composer "sự kiện từ nhiều dịch vụ GCP" → Eventarc "đợi cả một nhóm tệp tới đủ" → sensor trong Composer, hoặc tệp báo hiệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàm có được gọi không | Logs Explorer, lọc theo tên hàm | | Job đã nộp chưa | gcloud dataproc jobs list --region=<r> | | Có nộp trùng không | đếm số job cho cùng một tệp |

Và một chi tiết nên xử lý ngay trong hàm ngay từ phiên bản đầu: đặt job id suy ra từ tên tệp. Sự kiện Cloud Storage có thể được phát lại, và một job Spark nặng chạy hai lần trên cùng một tệp vừa tốn tiền vừa có thể sinh dữ liệu trùng ở đầu ra — một job id cố định khiến lần nộp thứ hai bị từ chối thay vì âm thầm chạy song song.

Đáp án

A — BigQuery Data Editor (roles/bigquery.dataEditor) trên DATASET.

Vì sao đúng

Service account chỉ cần GHI bản ghi vào một bảng trong logs_dataset. dataEditor cho đúng quyền đó, và cấp trên dataset thay vì trên project là mức hẹp nhất phù hợp.

⚠ Điểm mấu chốt — dataEditor cho đúng thứ cần:

roles/bigquery.dataEditor
        ↓
    CÓ:
      bigquery.tables.updateData   ← GHI dữ liệu
      bigquery.tables.getData      ← đọc
      bigquery.tables.create/update/delete
      bigquery.tables.list
        ↓
    KHÔNG CÓ:
      quản lý QUYỀN của dataset
      động tới dataset khác

⚠ Vì sao cấp trên DATASET, không cấp trên project:

Cấp trên project
        ↓
    → ghi được vào MỌI dataset
    → kể cả những cái không liên quan

Cấp trên logs_dataset
        ↓
    → chỉ ghi được vào đúng nơi cần
        ↓
    ⚠ Cùng một vai trò, khác phạm vi
      = khác biệt rất lớn về rủi ro

⚠ Một điểm quan trọng về jobUser:

Ghi bằng STORAGE WRITE API hoặc
streaming insert
        ↓
    → KHÔNG tạo job
    → chỉ cần dataEditor
        ↓
Ghi bằng LOAD JOB hoặc INSERT bằng SQL
        ↓
    → CÓ tạo job
    → cần thêm roles/bigquery.jobUser
        ↓
    ⚠ Đề chỉ nói "ghi bản ghi vào bảng"
      và hỏi MỘT vai trò
      → dataEditor là đáp án

Xem thêm câu #12957 (cùng lô): ở đó nhà phân tích CHẠY TRUY VẤN nên cần dataViewer + jobUser. Câu này là service account GHI dữ liệu → dataEditor. Hai khoá khác nhau vì hành động khác nhau, nhất quán với nhau.

Vì sao các phương án khác sai

• C (BigQuery Data Owner trên dataset) — đây là phương án gần nhất và ghi được, nhưng nó thêm quyền quản lý IAM của dataset — rộng hơn mức cần.

• B (BigQuery Job User trên project) — cho phép chạy job nhưng không đọc ghi được bảng nào; một mình nó không đủ.

• D (BigQuery Admin) — toàn quyền BigQuery trên toàn project, rộng hơn hẳn.

Ghi nhớ

⚠ Vai trò BigQuery theo hành động — bảng phải thuộc: | Hành động | Vai trò | |---|---| | Chỉ đọc dữ liệu | bigquery.dataViewer | | GHI dữ liệu vào bảng | bigquery.dataEditor | | Quản lý quyền của dataset | bigquery.dataOwner | | Chạy job (truy vấn, nạp, xuất) | bigquery.jobUser | | Chạy job + tạo dataset riêng | bigquery.user | | Toàn quyền | bigquery.admin | | Chỉ xem lược đồ | bigquery.metadataViewer |

Từ khoá nhận diện:

"ứng dụng GHI dữ liệu vào bảng" → dataEditor trên dataset "nhà phân tích chạy SELECT" → dataViewer + jobUser "quản lý ai được vào dataset" → dataOwner "cấp ở project cho nhanh" → thường là phương án SAI "Admin" → gần như luôn quá rộng trong câu hỏi quyền tối thiểu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | SA có quyền gì trên dataset | bq show --format=prettyjson logs_dataset → access | | Hàm chạy dưới danh nghĩa ai | gcloud functions describe <ten> --gen2 → serviceAccountEmail | | Vì sao bị từ chối | Policy Troubleshooter |

Và một thói quen đáng có với mọi dịch vụ mới triển khai: tạo service account riêng ngay từ đầu, kể cả khi thấy phiền. Dùng tạm tài khoản mặc định "để chạy được đã" là quyết định gần như không bao giờ được quay lại sửa — và nó lặng lẽ cấp cho một hàm ghi log quyền sửa đổi gần như toàn bộ project.

Đáp án

C — Looker.

Vì sao đúng

Đề liệt kê ba yêu cầu, và cả ba đều là những thứ Looker có mà Looker Studio không có: lớp ngữ nghĩa được quản trị tập trung, có quản lý phiên bản, API mạnh để tích hợp, và bảo mật ở cấp DÒNG rất chi tiết.

⚠ Điểm mấu chốt — ba yêu cầu ánh xạ vào ba tính năng:

"lớp ngữ nghĩa quản trị tập trung,
 có quản lý phiên bản"
        ↓
    LOOKML — lưu trong Git,
    review được, có môi trường dev/prod

"API mạnh để tích hợp ứng dụng bên thứ ba"
        ↓
    LOOKER API — quản lý mọi thứ bằng mã,
    nhúng dashboard, chạy truy vấn

"bảo mật cấp dòng chi tiết"
        ↓
    USER ATTRIBUTES + ACCESS_FILTER
    trong chính mô hình LookML

⚠ Bảo mật cấp dòng của Looker khai ngay trong mô hình:

explore: don_hang {
  access_filter: {
    field: don_hang.khu_vuc
    user_attribute: khu_vuc_cua_nguoi_dung
  }
}

        ↓
    Mỗi người dùng có thuộc tính "khu_vuc"
        ↓
    → Looker TỰ THÊM điều kiện lọc
      vào mọi truy vấn của họ
        ↓
    ⚠ Áp cho MỌI dashboard, MỌI Look
    → không phải nhớ lọc ở từng báo cáo

⚠ Vì sao Looker Studio không đáp ứng được:

Looker Studio
        ↓
    - KHÔNG có lớp mô hình tập trung
    - KHÔNG có quản lý phiên bản
    - Lọc dòng phải làm THỦ CÔNG
      ở từng báo cáo, hoặc dựa vào
      row-level security của BigQuery
    - API hạn chế hơn nhiều
        ↓
    → hợp với báo cáo nhanh,
      không hợp với yêu cầu doanh nghiệp

Xem thêm câu #12946 (cùng lô): cũng khoá Looker, cũng vì LookML. Hai câu nhất quán, nhấn mạnh hai khía cạnh khác nhau của cùng một lý do. Và #12947 (cùng lô) khoá Looker Studio vì yêu cầu ở đó là miễn phí và đơn giản — khác hoàn toàn.

Vì sao các phương án khác sai

• B (Looker Studio) — đây là phương án gần nhất về tên gọi và cũng là công cụ BI, nhưng không có lớp ngữ nghĩa quản trị tập trung, không có quản lý phiên bản, và API hạn chế.

• D (Vertex AI Notebooks) — môi trường phân tích bằng mã, ngược hoàn toàn với yêu cầu nhất quán và quản trị.

• A (BigQuery Geo Viz) — công cụ nhỏ để vẽ dữ liệu địa lý lên bản đồ, không phải nền tảng BI.

Ghi nhớ

⚠ Looker ↔ Looker Studio cho doanh nghiệp — bảng phải thuộc: | Yêu cầu | Looker | Looker Studio | |---|---|---| | Lớp ngữ nghĩa tập trung | LookML | không có | | Quản lý phiên bản | Git | không | | Row-level security | access_filter + user attribute | dựa vào nguồn dữ liệu | | API | mạnh, đầy đủ | hạn chế | | Nhúng | signed embed, đa khách hàng | nhúng cơ bản | | Chi phí | có phí | bản cơ bản miễn phí |

Từ khoá nhận diện:

"lớp ngữ nghĩa, quản trị, phiên bản, API, row-level" → Looker "dashboard nhanh, miễn phí" → Looker Studio "bản đồ từ truy vấn BigQuery" → BigQuery Geo Viz "phân tích bằng Python" → Vertex AI Notebooks "bảng tính" → Connected Sheets

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số định nghĩa ở đâu | tìm measure trong kho LookML | | Ai thấy được dòng nào | kiểm tra user attribute của người đó | | Ai đổi mô hình gần đây | lịch sử Git của dự án LookML |

Và một điều nên tính vào chi phí ngay từ khi chọn Looker: cần người bảo trì LookML. Lớp ngữ nghĩa mang lại sự nhất quán, nhưng nó là mã — cần người review pull request, quản lý môi trường và cập nhật khi mô hình dữ liệu đổi. Đó là cái giá hợp lý cho doanh nghiệp lớn, và là gánh nặng không cần thiết cho một đội năm người.

Đáp án

A — Thường xuyên sao lưu DAG, dữ liệu và cấu hình của môi trường sang bucket Cloud Storage đa vùng, và sẵn sàng triển khai lại.

Vì sao đúng

Môi trường Cloud Composer gắn với MỘT Region và không tự chuyển sang Region khác được. Vì vậy chiến lược khôi phục thảm hoạ phải là giữ đủ nguyên liệu để DỰNG LẠI môi trường ở Region khác.

⚠ Điểm mấu chốt — cần sao lưu ba thứ:

1. DAG
    → nằm trong bucket của môi trường,
      thư mục /dags
    → nên là NGUỒN TỪ GIT chứ không phải
      chỉ có bản trong bucket

2. CẤU HÌNH môi trường
    → biến Airflow, connection,
      gói Python cài thêm,
      cấu hình môi trường (kích thước, phiên bản)

3. DỮ LIỆU phụ trợ
    → /data, /plugins trong bucket

⚠ Vì sao mục tiêu "trong vòng vài giờ" là hợp lý:

Tạo mới một môi trường Composer
        ↓
    Mất khoảng 20–30 PHÚT
        ↓
    + Chép DAG và cấu hình vào
    + Nhập lại biến và connection
    + Kiểm tra kết nối tới các dịch vụ
        ↓
    → tổng cộng VÀI GIỜ
        ↓
    ⚠ Đúng bằng RTO mà đề nêu

⚠ Vì sao HA của Composer không giải quyết được:

Bật HA cho môi trường Composer
        ↓
    → nhiều scheduler, nhiều zone
      TRONG CÙNG MỘT REGION
        ↓
    ⚠ Chống được hỏng một ZONE
    ⚠ KHÔNG chống được mất CẢ REGION
        ↓
    → giống hệt trường hợp Cloud SQL:
      HA là chuyện trong Region,
      DR là chuyện giữa các Region

⚠ Cách làm cho việc dựng lại thật sự nhanh:

- DAG lưu trong GIT, đồng bộ vào bucket
  bằng CI/CD → dựng lại chỉ là chạy pipeline
- Môi trường khai bằng TERRAFORM
  → terraform apply với region khác
- Biến và connection lưu trong
  SECRET MANAGER, không gõ tay
- ⚠ DIỄN TẬP định kỳ

Vì sao các phương án khác sai

• D (chụp snapshot môi trường hằng ngày) — đây là phương án gần nhất và Composer 2 thật sự có tính năng snapshot, hữu ích cho việc sao lưu và di chuyển. Nhưng snapshot khôi phục vào môi trường cùng phiên bản và bản thân nó không phải chiến lược DR đa Region hoàn chỉnh — vẫn cần bản sao ở nơi khác và quy trình dựng lại. Phương án A mô tả đúng chiến lược đầy đủ.

• C (bật HA cho môi trường) — chống được hỏng zone, không chống được mất Region.

• B (tăng số scheduler và worker) — cải thiện hiệu năng và khả năng chịu tải, không liên quan tới khôi phục thảm hoạ.

Ghi nhớ

⚠ HA ↔ DR — bảng phải thuộc: | | HA (sẵn sàng cao) | DR (khôi phục thảm hoạ) | |---|---|---| | Chống | hỏng ZONE, hỏng thành phần | mất CẢ REGION | | Phạm vi | trong một Region | giữa các Region | | Thời gian phục hồi | tự động, vài giây tới phút | thủ công, vài giờ | | Composer | nhiều scheduler, nhiều zone | dựng lại ở Region khác | | Ghi nhớ | HA không thay thế DR |

Từ khoá nhận diện:

"mất cả Region, khôi phục trong vài giờ" → DR, dựng lại từ bản sao "chịu được hỏng một zone" → HA "RPO / RTO" → luôn là câu hỏi về DR "snapshot môi trường Composer" → công cụ hỗ trợ, không phải cả chiến lược "tăng worker" → hiệu năng, không phải DR

Ba việc kiểm chứng: | Việc | Cách | |---|---| | DAG có trong Git không | kiểm tra kho mã, không chỉ bucket | | Biến và connection lưu ở đâu | Secret Manager, hoặc bản xuất định kỳ | | Dựng lại mất bao lâu thật | DIỄN TẬP một lần và bấm giờ |

Và điểm may mắn nên nói rõ khi bàn về DR cho Cloud Composer: nó không giữ dữ liệu nghiệp vụ nào cả. Mất môi trường nghĩa là mất lớp điều phối và lịch sử chạy, còn dữ liệu vẫn nằm nguyên trong BigQuery và Cloud Storage — nên mục tiêu khôi phục chỉ là làm cho các luồng chạy lại, và đó là mục tiêu dễ đạt hơn nhiều so với khôi phục một cơ sở dữ liệu.

Đáp án

C — Looker, dùng API sinh signed embed URL có kèm user attribute (như customer_id), rồi access_filter trong mô hình LookML dùng thuộc tính đó để lọc dữ liệu.

Vì sao đúng

Đề nêu bốn ràng buộc, và chỉ Looker đáp ứng đủ: nhúng vào ứng dụng SaaS, cách ly dữ liệu giữa các khách hàng, xác thực do ứng dụng SaaS lo, và người xem KHÔNG có tài khoản Google.

⚠ Điểm mấu chốt — signed embed giải quyết bài toán "không có tài khoản Google":

Người dùng đăng nhập vào ứng dụng SaaS
        ↓
    Ứng dụng biết họ là khách hàng nào
        ↓
    Ứng dụng SINH signed embed URL:
      - ký bằng embed secret của Looker
      - nhúng USER ATTRIBUTES,
        ví dụ customer_id = "KH123"
      - có thời hạn
        ↓
    ⚠ Looker TIN chữ ký đó
    → không cần người dùng có tài khoản Google
    → không cần tài khoản Looker riêng

⚠ Và access_filter biến thuộc tính đó thành bộ lọc:

explore: du_lieu_khach_hang {
  access_filter: {
    field: du_lieu_khach_hang.customer_id
    user_attribute: customer_id
  }
}

        ↓
    Mọi truy vấn của phiên nhúng đó
    TỰ ĐỘNG kèm điều kiện
      customer_id = 'KH123'
        ↓
    ⚠ Lọc áp ở TẦNG MÔ HÌNH,
      không phải ở URL hay ở giao diện
    → khách hàng KHÔNG thể sửa URL
      để xem dữ liệu của người khác

⚠ Vì sao "lọc bằng tham số trên URL" là lỗ hổng:

Nhúng kèm ?filter=customer_id=KH123
        ↓
    ⚠ Người dùng SỬA URL thành KH124
        ↓
    → xem được dữ liệu khách hàng khác
        ↓
    ⚠ Đây chính là điểm yếu của
      phương án Looker Studio trong đề
    → bộ lọc trên URL KHÔNG PHẢI
      cơ chế bảo mật

Xem thêm câu #12946 và #12976 (cùng lô): cùng khoá Looker, vì LookML và vì quản trị doanh nghiệp. Ba câu nhất quán — câu này nhấn mạnh nhúng và đa khách hàng.

Vì sao các phương án khác sai

• B (Looker Studio, truyền email người dùng làm tham số lọc trên URL) — đây là phương án gần nhất và trông có vẻ chạy được, nhưng tham số trên URL sửa được, nên không phải cơ chế bảo mật; hơn nữa Looker Studio cần người xem có tài khoản Google.

• D (Looker Studio Pro, mỗi khách hàng một dashboard riêng) — không mở rộng nổi: hàng trăm khách hàng là hàng trăm dashboard phải bảo trì, và vẫn không giải quyết được vấn đề tài khoản.

• A (BigQuery ML, mỗi khách hàng một mô hình) — hoàn toàn lạc đề: đây là bài toán hiển thị và phân quyền, không phải học máy.

Ghi nhớ

⚠ Bốn cách nhúng của Looker — bảng phải thuộc: | Cách | Dùng khi | |---|---| | Signed embed (SSO embed) | nhúng cho người dùng KHÔNG có tài khoản Looker | | Private embed | người xem đã đăng nhập Looker | | Public embed | dữ liệu công khai — cẩn thận | | API + giao diện tự dựng | toàn quyền kiểm soát hiển thị | | Với SaaS đa khách hàng | signed embed là lựa chọn duy nhất hợp lý |

Từ khoá nhận diện:

"nhúng vào SaaS, người xem không có tài khoản Google" → Looker signed embed "mỗi khách chỉ thấy dữ liệu của mình" → user attribute + access_filter "lọc bằng tham số URL" → KHÔNG phải cơ chế bảo mật "dashboard nội bộ, có tài khoản Google" → Looker Studio "lọc dòng ngay trong BigQuery" → row-level security

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bộ lọc có thật sự áp không | xem SQL Looker sinh ra trong tab SQL | | Khách A có thấy dữ liệu khách B không | thử nghiệm chéo, bắt buộc | | Embed secret có bị lộ không | rà soát mã phía client và kho mã |

Và một phép kiểm thử phải làm trước mỗi lần phát hành trong kịch bản đa khách hàng: đăng nhập bằng danh tính của khách hàng A rồi tìm mọi cách để nhìn thấy dữ liệu của khách hàng B. Sửa tham số URL, đổi bộ lọc trong giao diện, tải kết quả về — nếu lớp access_filter được cấu hình đúng, mọi cách đều thất bại; và đó là thứ duy nhất chứng minh được rằng nó đúng.

Đáp án

C — Tạo lại bảng với PHÂN VÙNG (partition) theo cột event_date.

Vì sao đúng

Truy vấn gần như luôn lọc theo event_date, và phân vùng cho phép BigQuery bỏ qua hoàn toàn những phân vùng không thoả điều kiện — giảm cả thời gian lẫn chi phí.

⚠ Điểm mấu chốt — partition pruning:

Bảng 10 TB, phân vùng theo ngày
        ↓
    WHERE event_date > '2026-08-01'
        ↓
    BigQuery đọc SIÊU DỮ LIỆU phân vùng
        ↓
    → chỉ QUÉT các phân vùng thoả điều kiện
    → 30 ngày gần nhất thay vì 3 năm
        ↓
    ⚠ Quét ~1% dữ liệu
    → nhanh hơn và RẺ HƠN khoảng 100 lần

⚠ ⚠ Phân vùng ↔ phân cụm — phải phân biệt dứt điểm:

PARTITIONING (phân vùng)
        ↓
    CHIA VẬT LÝ bảng thành các phần
    theo NGÀY, số nguyên, hoặc thời điểm nạp
        ↓
    → BỎ QUA HẲN phân vùng không cần
    → chi phí GIẢM MẠNH và ĐOÁN TRƯỚC ĐƯỢC
    → tối đa 4.000 phân vùng

CLUSTERING (phân cụm)
        ↓
    SẮP XẾP dữ liệu TRONG mỗi phân vùng
    theo tối đa 4 cột
        ↓
    → bỏ qua các khối không liên quan
    → mức giảm KHÔNG đoán trước được
    → chi phí ước tính trước không phản ánh

⚠ Vì sao chỉ phân cụm theo event_date là chưa tối ưu:

Cluster theo event_date
        ↓
    → CÓ giúp, nhưng ít hơn hẳn
    → không loại bỏ dữ liệu ở mức phân vùng
    → BigQuery không báo trước
      chi phí sẽ giảm bao nhiêu
        ↓
    Với cột NGÀY dùng để lọc thường xuyên,
    PHÂN VÙNG luôn là lựa chọn đúng
        ↓
    Tốt nhất: PHÂN VÙNG theo ngày
              + PHÂN CỤM theo cột lọc khác

⚠ Tạo lại bảng có phân vùng:

CREATE TABLE `du_an.sales_events_moi`
PARTITION BY DATE(event_date)
CLUSTER BY khu_vuc, san_pham
OPTIONS(
  require_partition_filter = TRUE
) AS
SELECT * FROM `du_an.sales_events`;

        ↓
    ⚠ require_partition_filter = TRUE
    → BẮT BUỘC mọi truy vấn phải lọc
      theo cột phân vùng
    → chặn hẳn những câu SELECT quét cả bảng

Vì sao các phương án khác sai

• A (tạo lại bảng và PHÂN CỤM theo event_date) — đây là phương án gần nhất và có giúp một phần, nhưng phân cụm chỉ sắp xếp dữ liệu; nó không cắt bỏ hẳn phần dữ liệu như phân vùng, và mức giảm chi phí không đoán trước được.

• B (mua thêm slot) — có thể làm truy vấn nhanh hơn, nhưng vẫn quét đúng lượng dữ liệu đó — không giải quyết gốc rễ và thường tốn hơn.

• D (xuất ra Cloud Storage rồi dùng federated query) — chậm hơn hẳn và mất các tính năng tối ưu của bảng gốc.

Ghi nhớ

⚠ Phân vùng ↔ phân cụm — bảng phải thuộc: | | Partitioning | Clustering | |---|---|---| | Cơ chế | chia bảng thành các phần vật lý | sắp xếp trong phân vùng | | Số cột | MỘT | tối đa 4, có thứ tự | | Kiểu cột | DATE, TIMESTAMP, DATETIME, INT64 | hầu hết kiểu | | Giảm chi phí | mạnh và ĐOÁN TRƯỚC ĐƯỢC | không đoán trước được | | Giới hạn | 4.000 phân vùng | không | | Dùng chung | nên dùng CẢ HAI |

Từ khoá nhận diện:

"luôn lọc theo NGÀY" → phân vùng theo ngày "lọc theo nhiều cột khác nhau" → phân cụm "bảng nhỏ hơn 1 GB" → phân cụm thôi, phân vùng không lợi "quá 4.000 phân vùng" → phân vùng theo THÁNG, hoặc phân cụm "truy vấn chậm nhưng quét ít" → mới cần nghĩ tới slot

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng có phân vùng chưa | bq show <dataset>.<bảng> → Time Partitioning | | Truy vấn có cắt được không | --dry_run — so số byte trước và sau | | Phân vùng nào lớn nhất | truy vấn INFORMATION_SCHEMA.PARTITIONS |

Và một tuỳ chọn rất đáng bật cùng lúc với việc phân vùng: require_partition_filter = TRUE. Nó buộc mọi truy vấn phải kèm điều kiện lọc theo cột phân vùng, và biến một câu SELECT * gõ vội trên bảng 10 TB từ một hoá đơn bất ngờ thành một thông báo lỗi vô hại.

Đáp án

A — BigLake table kết hợp với policy tag.

Vì sao đúng

Đề nêu ba yêu cầu: truy cập TẠI CHỖ các tệp Parquet trong Cloud Storage, truy vấn qua BigQuery, và che dữ liệu nhạy cảm ở cấp CỘT một cách TẬP TRUNG. Chỉ BigLake làm được cả ba.

⚠ Điểm mấu chốt — BigLake là bảng ngoài CÓ kiểm soát chi tiết:

EXTERNAL TABLE thường
        ↓
    BigQuery đọc tệp trong GCS
        ↓
    ⚠ Người dùng phải có quyền TRÊN CHÍNH BUCKET
    ⚠ KHÔNG hỗ trợ column-level security
    ⚠ KHÔNG hỗ trợ row-level security
        ↓
    → ai truy vấn được cũng đọc thẳng
      tệp gốc được

BIGLAKE TABLE                     ← đề này
        ↓
    Truy cập qua CONNECTION có
    service account riêng
        ↓
    ⚠ Người dùng KHÔNG cần quyền trên bucket
    ⚠ CÓ column-level security (policy tag)
    ⚠ CÓ row-level security
    ⚠ CÓ dynamic data masking
        ↓
    → BigQuery trở thành CỬA DUY NHẤT
      vào data lake

⚠ Cách dựng:

-- 1. Tạo connection (service account của BigQuery)
--    cấp cho SA đó roles/storage.objectViewer trên bucket

-- 2. Tạo BigLake table
CREATE EXTERNAL TABLE `du_an.ho_du_lieu.khach_hang`
WITH CONNECTION `du_an.asia-southeast1.ket-noi-gcs`
OPTIONS (
  format = 'PARQUET',
  uris = ['gs://ho-du-lieu/khach-hang/*.parquet']
);

-- 3. Gắn policy tag vào cột nhạy cảm trong lược đồ
-- 4. Ai không có Fine-Grained Reader → không đọc được cột đó

⚠ Vì sao "tập trung" là từ khoá quan trọng:

Policy tag định nghĩa MỘT LẦN trong
    Dataplex / Data Catalog
        ↓
    Gắn vào cột ở NHIỀU BẢNG,
    kể cả BigLake table trên data lake
        ↓
    → cùng một chính sách áp cho
      cả dữ liệu trong BigQuery
      lẫn dữ liệu trong GCS
        ↓
    ⚠ Đây chính là "governed access"
      mà đội quản trị dữ liệu cần

Xem thêm câu #12965 (cùng lô): cũng dùng policy tag nhưng trên bảng thường của BigQuery. Câu này áp cùng cơ chế lên tệp trong data lake nhờ BigLake. Cùng khoá về cơ chế, nhất quán.

Vì sao các phương án khác sai

• B (external table thường + authorized view) — đây là phương án gần nhất và che cột được bằng view, nhưng external table thường đòi người dùng có quyền trên bucket trong nhiều kịch bản, và cách này không phải kiểm soát TẬP TRUNG ở cấp cột — phải tạo và bảo trì view cho từng bảng.

• D (bảng quản lý của BigQuery + IAM) — đòi NẠP dữ liệu vào BigQuery, trái yêu cầu truy cập tại chỗ.

• C (Datastream với biến đổi thời gian thực) — Datastream dùng cho CDC từ CSDL quan hệ, không liên quan tới data lake Parquet.

Ghi nhớ

⚠ Ba loại bảng đọc dữ liệu ngoài — bảng phải thuộc: | Loại | Đặc điểm | |---|---| | Bảng quản lý (managed) | dữ liệu NẠP vào BigQuery — nhanh nhất, đầy đủ tính năng | | External table | đọc tại chỗ, người dùng cần quyền trên nguồn, không có bảo mật chi tiết | | BigLake table | đọc tại chỗ + BẢO MẬT CHI TIẾT + không cần quyền trên bucket | | Object table | bảng trỏ vào tệp phi cấu trúc (ảnh, video) | | Chọn BigLake khi | data lake cần quản trị |

Từ khoá nhận diện:

"data lake + quản trị + che cột" → BigLake + policy tag "truy vấn tại chỗ, không cần bảo mật chi tiết" → external table "hiệu năng tốt nhất" → nạp vào bảng quản lý "ảnh, video trong GCS" → object table "CDC từ Oracle/MySQL" → Datastream

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng có phải BigLake không | bq show --format=prettyjson → có trường connectionId | | Cột nào mang policy tag | bq show --schema --format=prettyjson | | Người dùng có đọc được bucket không | không nên — kiểm tra IAM của bucket |

Và một điểm khiến BigLake khác biệt hẳn so với external table thường, đáng nhấn mạnh với đội quản trị: người dùng không cần và không nên có quyền trên bucket. Khi mọi truy cập đều đi qua BigQuery, bạn có một điểm duy nhất để áp chính sách và một dòng audit log duy nhất để kiểm tra — thay vì phải theo dõi song song cả quyền BigQuery lẫn quyền Cloud Storage.