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

Đáp án

D — Dataflow.

Vì sao đúng

Đề nêu bốn điều: luồng sự kiện thời gian thực, quy tắc kiểm tra và làm giàu PHỨC TẠP, TUỲ BIẾN, định nghĩa trong một THƯ VIỆN JAVA riêng, và cần không máy chủ, chạy ở quy mô lớn. Dataflow là dịch vụ duy nhất khớp cả bốn.

⚠ Điểm mấu chốt — Beam chạy được mã Java tuỳ ý của bạn:

public class KiemTraVaLamGiau extends DoFn<Event, Event> {
  private transient QuyTacNghiepVu quyTac;  // thư viện riêng

  @Setup
  public void setup() {
    quyTac = new QuyTacNghiepVu();  // khởi tạo một lần
  }

  @ProcessElement
  public void process(@Element Event e, OutputReceiver<Event> out) {
    if (quyTac.hopLe(e)) {
      out.output(quyTac.lamGiau(e));
    }
  }
}

        ↓
    ⚠ Thư viện JAR riêng đóng gói cùng pipeline
    ⚠ Chạy song song trên hàng trăm worker
    ⚠ Không máy chủ nào phải quản lý

⚠ Vì sao ba phương án kia không phù hợp:

CLOUD DATA FUSION
    → kéo thả, dựa trên PLUGIN
    → logic tuỳ biến phức tạp trong
      thư viện riêng KHÔNG diễn đạt được
      bằng các node có sẵn

CLOUD FUNCTIONS
    → xử lý TỪNG sự kiện độc lập
    → không có mô hình luồng, không cửa sổ
    → kém hiệu quả ở thông lượng cao

DATAPROC SERVERLESS
    → chạy SPARK, thiên về XỬ LÝ THEO LÔ
    → Spark Structured Streaming có, nhưng
      Dataflow là lựa chọn chuẩn của GCP
      cho luồng không máy chủ

⚠ Đóng gói thư viện riêng vào pipeline Dataflow:

Java:
    → gói JAR vào uber-jar bằng Maven Shade
    → hoặc dùng Flex Template với container riêng

Python:
    → --requirements_file
    → --setup_file cho gói nội bộ
    → hoặc custom container image
        ↓
    ⚠ Đây là điểm mạnh: bạn mang
      logic nghiệp vụ CÓ SẴN lên đám mây

Xem thêm câu #13038 (cùng lô): nêu chính tiêu chí phân biệt — code-first (Dataflow) hay low-code (Data Fusion). Câu này là ứng dụng trực tiếp: có thư viện Java riêng → code-first → Dataflow. Hai câu nhất quán.

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

• C (Dataproc Serverless) — đây là phương án gần nhất vì cũng không máy chủ và chạy được mã Java/Scala, nhưng nó dựa trên Spark và thiên về xử lý theo LÔ; với luồng thời gian thực trên GCP, Dataflow là lựa chọn chuẩn.

• A (Cloud Data Fusion) — kéo thả dựa trên plugin, không phải nơi chạy logic tuỳ biến phức tạp trong thư viện riêng.

• B (Cloud Functions) — xử lý từng sự kiện độc lập, không có mô hình luồng và kém hiệu quả ở quy mô lớn.

Ghi nhớ

⚠ Chọn engine theo bản chất logic — bảng phải thuộc: | Logic | Engine | |---|---| | Tuỳ biến phức tạp, có thư viện riêng, LUỒNG | Dataflow | | Diễn đạt được bằng plugin, kéo thả | Cloud Data Fusion | | Tuỳ biến phức tạp, LÔ, đã có Spark | Dataproc / Dataproc Serverless | | Nhỏ, độc lập, theo sự kiện | Cloud Run function | | Chỉ là SQL | BigQuery / Dataform |

Từ khoá nhận diện:

"thư viện riêng, logic phức tạp, luồng, serverless" → Dataflow "kéo thả, plugin sẵn" → Cloud Data Fusion "job Spark có sẵn" → Dataproc Serverless "một sự kiện, một hành động nhỏ" → Cloud Run function "biến đổi bằng SQL" → Dataform

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline có theo kịp không | Data freshness trong Job metrics | | Logic tuỳ biến có tốn CPU không | Cloud Profiler trên worker | | Bản ghi hỏng có được giữ không | kiểm tra bảng dead-letter |

Và một chi tiết kỹ thuật rất đáng nhớ khi mang thư viện riêng vào Dataflow: khởi tạo đối tượng nặng trong @Setup, không phải trong @ProcessElement. Một quy tắc nghiệp vụ nạp cấu hình từ tệp mà bị khởi tạo lại cho từng bản ghi sẽ biến một pipeline đáng lẽ chạy vài phút thành một job kéo dài hàng giờ — và biểu đồ CPU sẽ trông hoàn toàn bình thường.

Đáp án

B — Dataproc trên Compute Engine (Dataproc tiêu chuẩn).

Vì sao đúng

Đề nêu ba yêu cầu, và cả ba đều đòi hỏi một cụm thật do bạn kiểm soát: cụm Spark THƯỜNG TRỰC, chạy lâu dài, phục vụ truy vấn tương tác của nhiều nhà phân tích, và tuỳ biến sâu về loại máy cùng thư viện bên thứ ba.

⚠ Điểm mấu chốt — ba yêu cầu loại bỏ mọi phương án không có cụm:

"THƯỜNG TRỰC, chạy lâu dài"
    → cụm phải luôn sẵn sàng
    → serverless không có cụm để mà tồn tại

"truy vấn TƯƠNG TÁC từ nhiều nhà phân tích"
    → cần cụm sẵn sàng ngay, không chờ dựng
    → nhiều người dùng chung một cụm

"loại máy cụ thể + thư viện bên thứ ba"
    → cần initialization action
    → cần chọn machine type
        ↓
    → Dataproc trên Compute Engine

⚠ Tuỳ biến mà chỉ cụm thật mới có:

--initialization-actions gs://.../cai-dat.sh
    → cài phần mềm bên thứ ba lúc tạo cụm

--master-machine-type / --worker-machine-type
    → chọn đúng cấu hình cần

--optional-components=JUPYTER,ZEPPELIN
    → notebook tương tác NGAY TRÊN cụm

--properties spark:spark.executor.memory=8g
    → tinh chỉnh Spark

--enable-component-gateway
    → truy cập giao diện web của Spark, YARN

⚠ Cụm thường trực không có nghĩa là lãng phí:

Bật AUTOSCALING POLICY
    → số worker co giãn theo tải
    → giữ vài worker tối thiểu cho
      truy vấn tương tác

Dùng SECONDARY WORKER là Spot VM
    → phần co giãn rẻ hơn nhiều

Đặt lịch tắt ngoài giờ làm việc
    → nếu nhà phân tích chỉ làm giờ hành chính

Xem thêm câu #13043 (cùng lô): khoá Dataproc Serverless vì ở đó mục tiêu là KHÔNG quản lý vòng đời cụm. Và #12997 (lô 135): nêu chính đánh đổi giữa hai phương án. Ba câu nhất quán — khoá khác nhau vì yêu cầu về cụm khác nhau.

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

• D (Dataproc Serverless) — đây là phương án gần nhất và cũng chạy Spark, nhưng nó KHÔNG CÓ CỤM THƯỜNG TRỰC: mỗi lần nộp là một batch riêng, không phục vụ được truy vấn tương tác, và tuỳ biến hạn chế hơn nhiều.

• A (BigQuery) — là kho dữ liệu SQL, không phải cụm Spark; không chạy được thư viện Spark bên thứ ba.

• C (Cloud Functions) — chạy đoạn mã ngắn theo sự kiện, hoàn toàn không phù hợp.

Ghi nhớ

⚠ Ba cách chạy Spark trên Google Cloud — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Dataproc trên Compute Engine | cụm thật, tuỳ biến sâu, thường trực được | | Dataproc Serverless | KHÔNG có cụm, tự co giãn, tuỳ biến hạn chế | | Dataproc trên GKE | chạy Spark trong cụm Kubernetes có sẵn | | BigQuery | không phải Spark — SQL, và có Spark stored procedure | | Chọn cụm thật khi | thường trực, tương tác, tuỳ biến sâu |

Từ khoá nhận diện:

"cụm thường trực, tương tác, nhiều người dùng" → Dataproc trên Compute Engine "không muốn quản lý cụm" → Dataproc Serverless "job Spark có tham số, chạy rồi xoá cụm" → Workflow Template + managed cluster "đã có GKE" → Dataproc trên GKE "chỉ cần SQL" → BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cụm cấu hình thế nào | gcloud dataproc clusters describe <ten> --region=<r> | | Tài nguyên có bị lãng phí không | YARN UI qua Component Gateway | | Chi phí bao nhiêu | billing export, lọc SKU Dataproc |

Và một cấu hình rất đáng dựng cùng lúc với cụm thường trực: Dataproc Metastore dùng chung. Nó tách siêu dữ liệu Hive ra khỏi vòng đời của cụm, nên khi bạn cần dựng lại cụm với cấu hình mới — điều chắc chắn sẽ xảy ra — các bảng mà nhà phân tích đã tạo vẫn còn nguyên.

Đáp án

A — Dataproc Serverless.

Vì sao đúng

Đề nêu ba điều rất rõ: giảm tối đa công vận hành, HOÀN TOÀN tránh quản lý vòng đời cụm, và chỉ muốn nộp mã rồi để Google lo mọi việc cấp phát và dọn dẹp hạ tầng. Đó là định nghĩa của Dataproc Serverless.

⚠ Điểm mấu chốt — nộp job, không có cụm:

gcloud dataproc batches submit pyspark \
  gs://bucket/huan_luyen.py \
  --region=asia-southeast1 \
  --deps-bucket=gs://bucket-tam
        ↓
    ⚠ KHÔNG có tên cụm
    ⚠ KHÔNG có số worker
    ⚠ KHÔNG có gì để tắt sau khi xong
        ↓
    Google tự:
      cấp tài nguyên → chạy → thu hồi

⚠ Vì sao hợp với job huấn luyện hằng ngày:

Job chạy MỘT LẦN mỗi ngày, rồi kết thúc
        ↓
    Cụm thường trực
        ↓
    ⚠ nhàn rỗi hơn 95% thời gian
    ⚠ vẫn tính tiền 24/7

Serverless
        ↓
    → trả tiền ĐÚNG thời gian job chạy
    → không có thời gian dựng cụm
    → không ai quên tắt

⚠ Vẫn tuỳ biến được, chỉ là ít hơn:

--properties spark.executor.memory=8g
    → tinh chỉnh Spark

--container-image gs://.../image
    → CUSTOM CONTAINER cho thư viện riêng

--version 2.2
    → chọn runtime version

--subnet
    → chạy trong VPC của bạn
        ↓
    ⚠ Không tuỳ biến được: machine type
      cụ thể, initialization action,
      thành phần như Hive/Presto

Xem thêm câu #13042 (cùng lô): khoá Dataproc trên Compute Engine vì cần cụm THƯỜNG TRỰC cho truy vấn tương tác và tuỳ biến sâu. Và #12997 (lô 135): nêu chính đánh đổi — ít kiểm soát, đổi lấy đơn giản vận hành. Ba câu nhất quán.

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

• D (Dataproc trên Compute Engine) — đây là phương án gần nhất và chạy được, nhưng nó đòi quản lý vòng đời cụm — đúng thứ đề muốn tránh hoàn toàn. (Workflow Template với managed cluster gần hơn nữa, nhưng vẫn có khái niệm cụm.)

• B (Dataproc trên GKE) — đòi có sẵn và quản lý một cụm Kubernetes; công vận hành còn cao hơn.

• C (tự cài Spark trên VM) — công vận hành cao nhất: tự cài, tự vá, tự co giãn, tự tắt.

Ghi nhớ

⚠ Bốn cách chạy Spark — theo công vận hành: | Cách | Công vận hành | |---|---| | Dataproc Serverless | thấp nhất — không có cụm | | Workflow Template + managed cluster | thấp — cụm tự tạo và tự xoá | | Dataproc trên Compute Engine | trung bình — bạn quản cụm | | Dataproc trên GKE | cao — thêm cả cụm Kubernetes | | Tự cài trên VM | cao nhất |

Từ khoá nhận diện:

"không muốn quản lý cụm chút nào" → Dataproc Serverless "cụm thường trực, tương tác" → Dataproc trên Compute Engine "job có tham số, dùng lại" → Workflow Template "đã có GKE" → Dataproc trên GKE "tự cài Spark" → luôn là phương án kém nhất trong đề thi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Job chạy thế nào | gcloud dataproc batches describe <id> --region=<r> | | Tốn bao nhiêu tài nguyên | chỉ số của batch trong Monitoring | | Có cụm nào bị bỏ quên không | gcloud dataproc clusters list |

Và một khoản chi phí nên rà soát nếu tổ chức đã dùng Dataproc lâu năm: danh sách cụm đang chạy nhưng không ai còn dùng. Đây là loại lãng phí mà Dataproc Serverless loại bỏ về mặt cấu trúc chứ không phải bằng kỷ luật — khi không có cụm nào tồn tại giữa các lần chạy, không có gì để quên tắt.

Đáp án

B — Bảng PHẢI được phân vùng theo một cột kiểu ngày hoặc dấu thời gian.

Vì sao đúng

Cả hai chiến lược trong đề — tự xoá phân vùng sau 36 tháng và giảm chi phí lưu cho phân vùng từ 90 ngày tới 36 tháng — đều thao tác ở cấp PHÂN VÙNG. Không có phân vùng thì không có gì để áp chính sách lên.

⚠ Điểm mấu chốt — cả hai cơ chế đều cần phân vùng:

TỰ XOÁ SAU 36 THÁNG
    → partition_expiration_days
        ↓
    ⚠ Chỉ tồn tại với bảng CÓ PHÂN VÙNG
    → không phân vùng thì phải DELETE thủ công,
      tốn tiền và chậm

GIẢM CHI PHÍ CHO DỮ LIỆU 90 NGÀY – 36 THÁNG
    → long-term storage
        ↓
    ⚠ Tính theo TỪNG PHÂN VÙNG
    → bảng không phân vùng: MỘT dòng ghi mới
      RESET đồng hồ cho TOÀN BỘ bảng

⚠ Vì sao điều thứ hai quan trọng hơn người ta tưởng:

Bảng chuỗi thời gian, KHÔNG phân vùng
        ↓
    Mỗi ngày ghi thêm dữ liệu mới
        ↓
    → "lần sửa cuối" luôn là HÔM NAY
    → KHÔNG BAO GIỜ đạt 90 ngày
    → KHÔNG BAO GIỜ được giá long-term
        ↓
    ⚠ Trả giá đầy đủ cho toàn bộ lịch sử,
      mãi mãi

⚠ Có phân vùng thì cả hai chạy tự động:

CREATE TABLE `du_an.chuoi_thoi_gian`
PARTITION BY DATE_TRUNC(event_date, MONTH)
OPTIONS (
  partition_expiration_days = 1096  -- 36 tháng
) AS SELECT ...;

        ↓
    → phân vùng cũ hơn 36 tháng: TỰ XOÁ
    → phân vùng không sửa 90 ngày:
      TỰ được giá long-term (~50%)
        ↓
    ⚠ Không có job nào phải chạy

Xem thêm câu #13039 (cùng lô): áp dụng chính partition expiration để xoá sau 48 tháng. Và #12979 (lô 134): phân vùng để giảm chi phí QUÉT. Và #12944 (lô 134): long-term storage giảm ~50%. Bốn câu cùng chỉ về một điều kiện nền: PHÂN VÙNG.

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

• D (phải nạp bằng Storage Write API) — đây là phương án gần nhất về mặt "liên quan tới cách ghi dữ liệu", nhưng cách nạp không quyết định gì về chính sách vòng đời; Storage Write API chỉ là một giao diện ghi hiệu quả.

• A (phải bật BigQuery reservations) — reservation là mô hình TÍNH TIỀN theo slot cho TRUY VẤN, không liên quan tới lưu trữ hay vòng đời.

• C (phải sao lưu sang Cloud Storage hằng ngày) — là một thực hành có thể tốt, nhưng không phải điều kiện để đặt chính sách vòng đời.

Ghi nhớ

⚠ Những gì PHÂN VÙNG mở khoá — bảng phải thuộc: | Lợi ích | Nội dung | |---|---| | Partition pruning | giảm mạnh byte quét khi lọc theo ngày | | partition_expiration_days | tự XOÁ phân vùng quá tuổi | | Long-term storage theo TỪNG phân vùng | phân vùng cũ tự giảm ~50% giá | | Ghi đè một phân vùng | nạp lại một ngày mà không đụng ngày khác | | require_partition_filter | chặn truy vấn quét cả bảng | | DELETE theo phân vùng | rẻ hơn nhiều |

Từ khoá nhận diện:

"chính sách vòng đời theo thời gian" → bảng phải PHÂN VÙNG "tự xoá dữ liệu cũ" → partition expiration "tự giảm giá lưu sau 90 ngày" → long-term storage (tự động) "giảm chi phí truy vấn" → partition pruning "reservations" → chi phí TRUY VẤN, không phải lưu trữ

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 | | Bao nhiêu dữ liệu ở long-term | INFORMATION_SCHEMA.TABLE_STORAGE → LONG_TERM_LOGICAL_BYTES | | Có bao nhiêu phân vùng | INFORMATION_SCHEMA.PARTITIONS |

Và một hệ quả tài chính rất dễ bị bỏ qua với bảng chuỗi thời gian không phân vùng: nó sẽ không bao giờ hưởng giá long-term storage. Chỉ cần thêm một dòng mỗi ngày là đồng hồ 90 ngày của toàn bộ bảng bị reset — nên với dữ liệu lịch sử nhiều terabyte, việc phân vùng không chỉ giúp truy vấn nhanh hơn mà còn cắt đôi hoá đơn lưu trữ.

Đáp án

C — Giám đốc cần quyền 'View' trên folder chứa dashboard để xem trực tiếp, còn trưởng phòng cần một SCHEDULED DELIVERY để nhận báo cáo tĩnh.

Vì sao đúng

Hai yêu cầu trong đề là hai kiểu tiêu thụ dữ liệu khác nhau, và Looker có hai cơ chế riêng cho chúng.

⚠ Điểm mấu chốt — "xem bất cứ lúc nào" ↔ "nhận vào thứ Sáu":

GIÁM ĐỐC
    "xem TRỰC TIẾP, TƯƠNG TÁC,
     BẤT CỨ LÚC NÀO"
        ↓
    → phải ĐĂNG NHẬP Looker
    → cần QUYỀN trên folder chứa dashboard
        ↓
    Quyền 'View' là đủ

TRƯỞNG PHÒNG
    "báo cáo TĨNH, gửi qua email
     mỗi thứ Sáu"
        ↓
    → KHÔNG cần đăng nhập Looker
    → cần SCHEDULED DELIVERY
        ↓
    Looker tự chạy và gửi vào giờ đã đặt

⚠ Scheduled delivery — cấu hình gì:

Từ dashboard: Schedule delivery
        ↓
    - Đích: email, Slack, GCS, SFTP,
            webhook
    - Định dạng: PDF, PNG, CSV, XLSX
    - Lịch: mỗi thứ Sáu, giờ cụ thể
    - Bộ lọc: cố định cho lần gửi này
    - Điều kiện: chỉ gửi khi thoả điều kiện
        ↓
    ⚠ Người nhận KHÔNG cần tài khoản Looker

⚠ Một lưu ý bảo mật quan trọng của scheduled delivery:

Báo cáo chạy dưới danh nghĩa
NGƯỜI TẠO LỊCH GỬI
        ↓
    ⚠ Nếu có access_filter theo user attribute,
      dữ liệu trong PDF là dữ liệu mà
      NGƯỜI TẠO LỊCH thấy được
        ↓
    → không phải dữ liệu của người NHẬN
        ↓
    Muốn mỗi người nhận dữ liệu riêng
      → dùng "Send to each recipient"
        (delivery theo từng người)

Xem thêm câu #13013 (lô 135): về quyền nội dung bằng folder + group. Câu này thêm chiều thứ hai: cách tiêu thụ — trực tiếp hay theo lịch. Hai câu bổ sung nhau.

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

• B (đảo ngược hai vế) — đây là phương án gần nhất và dùng đúng hai cơ chế, nhưng gán nhầm cho từng người: giám đốc cần xem trực tiếp (quyền folder), trưởng phòng cần bản tĩnh (scheduled delivery).

• A (cả hai đều dùng scheduled delivery) — giám đốc muốn xem bất cứ lúc nào và tương tác; một bản PDF gửi định kỳ không đáp ứng được.

• D (cả hai đều chỉ cần quyền 'View') — trưởng phòng muốn nhận email tự động; quyền xem không tự gửi gì cả.

Ghi nhớ

⚠ Hai cách tiêu thụ nội dung Looker — bảng phải thuộc: | Cách | Cơ chế | Người dùng | |---|---|---| | Xem trực tiếp, tương tác | quyền 'View' trên folder | cần tài khoản Looker | | Nhận báo cáo tĩnh theo lịch | scheduled delivery | KHÔNG cần tài khoản | | Nhúng vào ứng dụng khác | signed embed | không cần tài khoản Google | | Cảnh báo khi vượt ngưỡng | Looker Alerts | | | Truy cập bằng mã | Looker API | |

Từ khoá nhận diện:

"xem bất cứ lúc nào, tương tác" → quyền folder "gửi email định kỳ, bản tĩnh" → scheduled delivery "người nhận không có tài khoản Looker" → scheduled delivery "nhúng vào sản phẩm SaaS" → signed embed "báo khi số vượt ngưỡng" → Looker Alerts

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lịch gửi cấu hình đúng chưa | Admin → Schedules | | Người nhận thấy dữ liệu của ai | kiểm tra ai tạo lịch và có bật per-recipient không | | Giám đốc xem được dashboard chưa | impersonate (sudo) và thử |

Và một câu hỏi nên đặt ra trước khi bật báo cáo gửi tự động ra ngoài đội: bản PDF này chứa dữ liệu của ai? Với mô hình có access_filter, báo cáo chạy dưới quyền người tạo lịch chứ không phải người nhận — nên một lịch gửi do quản trị viên tạo có thể vô tình gửi toàn bộ dữ liệu công ty cho một người lẽ ra chỉ được xem phần của phòng mình.

Đáp án

B — Tạo user attribute cho sales_region, gán vùng tương ứng cho từng quản lý, và dùng tham số access_filter trong explore của LookML.

Vì sao đúng

Đề nêu hai ràng buộc: mỗi quản lý chỉ thấy dữ liệu vùng của mình, và giải pháp phải mở rộng được, KHÔNG nhân bản dashboard. Bảo mật cấp dòng bằng user attribute là cách chuẩn của Looker.

⚠ Điểm mấu chốt — cấu hình một lần, áp cho mọi người:

explore: doanh_so {
  access_filter: {
    field: doanh_so.sales_region
    user_attribute: vung_ban_hang
  }
}

        ↓
    Mỗi quản lý có thuộc tính
      vung_ban_hang = "Mien Bac" / "Mien Nam"...
        ↓
    Looker TỰ THÊM vào mọi truy vấn:
      WHERE sales_region = '<vùng của họ>'
        ↓
    ⚠ MỘT dashboard duy nhất
    ⚠ N quản lý, mỗi người thấy vùng mình
    ⚠ Thêm vùng mới: chỉ gán thuộc tính

⚠ Vì sao lọc ở TẦNG MÔ HÌNH mới là bảo mật:

Lọc trong dashboard hoặc trên URL
        ↓
    ⚠ Người dùng SỬA ĐƯỢC bộ lọc
    ⚠ Sửa URL là xem được vùng khác
        ↓
    → đó là TIỆN LỢI, không phải BẢO MẬT

access_filter trong explore
        ↓
    → điều kiện được thêm vào SQL
      TRƯỚC KHI truy vấn chạy
    → người dùng KHÔNG nhìn thấy,
      KHÔNG gỡ được

⚠ Vì sao "mỗi người một dashboard" là phản mẫu:

5 vùng → 5 dashboard hôm nay
        ↓
    Thêm vùng mới → dashboard thứ 6
    Sửa một biểu đồ → sửa 6 lần
    Một lần quên → 6 bản không còn giống nhau
        ↓
    ⚠ Và vẫn KHÔNG bảo mật: quản lý vùng A
      mở được URL dashboard vùng B nếu
      có quyền folder

Xem thêm câu #13035 (cùng lô): gần như cùng một câu hỏi (một dashboard chung, mỗi nhân viên chỉ thấy tài khoản của mình) và CÙNG KHOÁ: user attribute + access_filter. Hai câu hoàn toàn nhất quán — chỉ khác ở chỗ #13035 nêu thêm phần cấp quyền folder cho group. Và #12978 (lô 134) dùng cùng cơ chế cho nhúng đa khách hàng.

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

• C (tạo 5 bản sao dashboard với bộ lọc cố định) — đây là phương án gần nhất về mặt "cũng ra kết quả đúng", nhưng không mở rộng được và không phải bảo mật: bộ lọc cứng trong dashboard không ngăn ai mở dashboard khác.

• A (yêu cầu mỗi quản lý tự thêm bộ lọc) — không phải cơ chế bảo mật nào cả; hoàn toàn dựa vào kỷ luật của người dùng.

• D (xây một LookML model riêng cho mỗi vùng) — nhân bản mô hình, còn tệ hơn nhân bản dashboard về mặt bảo trì.

Ghi nhớ

⚠ Bảo mật cấp dòng trong Looker — bảng phải thuộc: | Thành phần | Việc | |---|---| | User attribute | giá trị riêng của từng người dùng | | access_filter | lọc DÒNG theo user attribute | | access_grant | ẩn/hiện TRƯỜNG hoặc explore | | sql_always_where | lọc cứng cho mọi truy vấn của explore | | Folder permission | ai thấy dashboard nào | | Nguyên tắc | lọc ở TẦNG MÔ HÌNH, không ở giao diện |

Từ khoá nhận diện:

"một dashboard, mỗi người dữ liệu riêng" → user attribute + access_filter "ẩn một số trường" → access_grant "cho cả nhóm xem" → folder + group "nhân bản dashboard cho từng người" → luôn là phương án SAI "tự thêm bộ lọc" → không phải bảo mật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thuộc tính đã gán chưa | Admin → Users → user attributes | | Bộ lọc có áp không | tab SQL trong Explore | | Có lách được không | impersonate và thử nghiệm chéo |

Và một trường hợp biên phải xử lý trước khi mở cho toàn đội: quản lý CHƯA được gán vung_ban_hang sẽ thấy gì? Tuỳ cấu hình, họ có thể thấy toàn bộ dữ liệu mọi vùng — nên hãy đặt giá trị mặc định là một chuỗi không khớp với bất kỳ vùng nào, và kiểm thử đúng tình huống ấy trước khi coi là đã xong.

Đáp án

C — Dataproc Workflow Templates.

Vì sao đúng

Đề nêu ba điều quyết định: ba job chạy tuần tự, toàn bộ trên MỘT cụm Dataproc, và KHÔNG phụ thuộc dịch vụ Google Cloud nào khác — với mục tiêu giảm tối đa độ phức tạp và công quản lý.

⚠ Điểm mấu chốt — luồng nằm gọn trong Dataproc:

Spark job → Hive job → shell script dọn dẹp
        ↓
    ⚠ CẢ BA đều là job của Dataproc
    ⚠ KHÔNG có bước nào gọi BigQuery,
      Cloud Storage API, hay gửi thông báo
        ↓
    → Workflow Template là đủ
    → Cloud Composer là quá tay

⚠ Khai template với ba bước phụ thuộc:

gcloud dataproc workflow-templates create luong-hang-ngay \
  --region=asia-southeast1

gcloud dataproc workflow-templates add-job spark \
  --workflow-template=luong-hang-ngay \
  --step-id=buoc-spark ...

gcloud dataproc workflow-templates add-job hive \
  --workflow-template=luong-hang-ngay \
  --step-id=buoc-hive --start-after=buoc-spark ...

gcloud dataproc workflow-templates add-job pig \
  --workflow-template=luong-hang-ngay \
  --step-id=buoc-don --start-after=buoc-hive ...

        ↓
    ⚠ --start-after chính là PHỤ THUỘC
    → bước sau chỉ chạy khi bước trước XONG

⚠ Và managed cluster loại bỏ việc quản lý cụm:

gcloud dataproc workflow-templates \
  set-managed-cluster --workflow-template=luong-hang-ngay \
  --cluster-name=cum-tam --num-workers=4
        ↓
    Mỗi lần chạy template:
      1. TỰ TẠO cụm
      2. Chạy ba bước theo thứ tự
      3. TỰ XOÁ cụm
        ↓
    ⚠ Không có cụm nào nằm không
    ⚠ Không ai quên tắt

Xem thêm câu #12954 (lô 134): cùng khoá Workflow Template, cho job Spark dùng lại có tham số. Và #13015 (lô 135): nêu chính ranh giới — Composer khi luồng chạm NHIỀU dịch vụ. Câu này luồng chỉ trong Dataproc → Workflow Template. Ba câu hoàn toàn nhất quán.

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

• B (Cloud Composer) — đây là phương án gần nhất và chắc chắn làm được, nhưng nó đòi dựng một môi trường Airflow thường trực với chi phí nền đáng kể — trái mục tiêu "giảm tối đa độ phức tạp và công quản lý" cho một luồng nằm gọn trong Dataproc.

• A (script tuỳ chỉnh trên một VM Compute Engine) — thêm một máy phải nuôi và vá, tự lo thử lại và theo dõi.

• D (Cloud Functions) — chạy đoạn mã ngắn; ghép ba job Dataproc bằng hàm là tự dựng lại một bộ điều phối tồi.

Ghi nhớ

⚠ Chọn công cụ điều phối theo PHẠM VI — bảng phải thuộc: | Phạm vi luồng | Công cụ | |---|---| | Chỉ trong Dataproc | Dataproc Workflow Template | | Chỉ trong BigQuery (SQL) | Dataform | | Vài bước xuyên dịch vụ, nhẹ | Cloud Workflows | | Nhiều dịch vụ, phụ thuộc phức tạp | Cloud Composer | | Một lời gọi theo giờ | Cloud Scheduler | | Nguyên tắc | chọn mức NHẸ NHẤT còn đủ dùng |

Từ khoá nhận diện:

"nhiều job, chỉ trong Dataproc" → Workflow Template "chạm tới BigQuery, GCS, thông báo" → Cloud Composer "một job theo giờ" → Cloud Scheduler "chuỗi SQL trong BigQuery" → Dataform "script trên VM" → luôn là phương án kém nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Template khai gì | gcloud dataproc workflow-templates describe <ten> --region=<r> | | Lần chạy gần nhất | gcloud dataproc operations list | | Có cụm bị bỏ quên không | gcloud dataproc clusters list |

Và một cách kiểm tra nhanh mỗi khi phân vân giữa Workflow Template và Cloud Composer: liệt kê từng bước rồi ghi tên dịch vụ bên cạnh. Nếu cột dịch vụ chỉ toàn chữ "Dataproc" như trong đề này, bạn đang định trả chi phí thường trực cho một thứ mà Workflow Template làm được miễn phí.

Đáp án

D — Bucket Lock kèm retention policy 10 năm.

Vì sao đúng

Yêu cầu là BẤT BIẾN TUYỆT ĐỐI: không ai — kể cả quản trị viên — được xoá hay sửa bản ghi trong 10 năm. Chỉ Bucket Lock cho mức bảo đảm đó.

⚠ Điểm mấu chốt — retention policy chặn xoá, Bucket Lock chặn cả việc gỡ chính sách:

RETENTION POLICY
        ↓
    Đối tượng KHÔNG XOÁ, KHÔNG GHI ĐÈ được
    trước khi đủ tuổi
        ↓
    ⚠ Nhưng quản trị viên vẫn GỠ ĐƯỢC
      chính sách rồi xoá

BUCKET LOCK
        ↓
    KHOÁ retention policy lại
        ↓
    ⚠ KHÔNG AI gỡ được — kể cả chủ project
    ⚠ KHÔNG rút ngắn được thời gian giữ
    ⚠ KHÔNG xoá được bucket khi còn
      đối tượng chưa hết hạn
        ↓
    → đây mới là "bất biến" đúng nghĩa

⚠ Cấu hình:

gcloud storage buckets update gs://ho-so-benh-nhan \
  --retention-period=10y

gcloud storage buckets update gs://ho-so-benh-nhan \
  --lock-retention-period
        ↓
    ⚠ Lệnh thứ hai là MỘT CHIỀU
    ⚠ KHÔNG có cách nào hoàn tác
        ↓
    → phải chắc chắn về con số 10 năm
      TRƯỚC KHI khoá

⚠ Vì sao IAM một mình không đủ:

Gỡ quyền storage.objects.delete
        ↓
    ⚠ Nhưng ai có quyền IAM
      TỰ CẤP LẠI được
    ⚠ Chủ project luôn có thể
        ↓
    → IAM là kiểm soát QUYỀN,
      không phải bảo đảm BẤT BIẾN
        ↓
    Kiểm toán viên phân biệt rất rõ
    hai điều này

Xem thêm câu #12992 (lô 135): dùng lifecycle rule để chuyển lớp và dọn dẹp. Và #13011 (lô 135): giữ 7 năm bằng cách xuất sang Archive. Bổ sung nhau: lifecycle DỌN DẸP theo tuổi, retention policy CẤM XOÁ trước tuổi — và retention THẮNG lifecycle.

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

• A (gỡ quyền storage.objects.delete bằng IAM chi tiết) — đây là phương án gần nhất và có tác dụng thực tế, nhưng quản trị viên tự cấp lại quyền được; nó không phải bảo đảm bất biến mà quy định đòi hỏi.

• B (Object Versioning) — giữ phiên bản cũ khi bị ghi đè hoặc xoá, nhưng các phiên bản đó vẫn xoá được; nó là cơ chế khôi phục, không phải bất biến.

• C (lifecycle chuyển sang Archive sau một ngày) — chỉ giảm chi phí lưu, không ngăn xoá chút nào.

Ghi nhớ

⚠ Bốn cơ chế của Cloud Storage — bảng phải thuộc: | Cơ chế | Việc | |---|---| | Retention policy | CẤM XOÁ/GHI ĐÈ trước khi đủ tuổi | | Bucket Lock | KHOÁ retention policy — không gỡ được | | Object Versioning | giữ phiên bản cũ — vẫn xoá được | | Lifecycle rule | tự chuyển lớp hoặc XOÁ theo tuổi | | Object hold | giữ MỘT đối tượng vô thời hạn | | Ưu tiên | retention policy THẮNG lifecycle |

Từ khoá nhận diện:

"bất biến, kể cả admin cũng không xoá được" → Bucket Lock "giữ N năm để tuân thủ" → retention policy (+ Bucket Lock nếu bắt buộc) "khôi phục khi lỡ ghi đè" → Object Versioning "tự xoá dữ liệu cũ" → lifecycle rule Delete "giữ riêng một tệp cho vụ kiện" → object hold

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Retention đã khoá chưa | gcloud storage buckets describe gs://b → retentionPolicy.isLocked | | Thời gian giữ là bao lâu | cùng lệnh trên → retentionPeriod | | Có ai xoá được không | thử xoá một đối tượng chưa hết hạn — phải bị từ chối |

Và một lời cảnh báo cần nói thật rõ trước khi chạy lệnh khoá: Bucket Lock không thể hoàn tác, mãi mãi. Một con số thời gian giữ nhập nhầm — 10 năm thành 100 năm — sẽ khoá bạn với chi phí lưu trữ đó suốt cả thế kỷ, và không có đường lùi nào kể cả qua hỗ trợ của Google. Hãy thử trên một bucket riêng với retention vài phút trước khi làm thật.

Đáp án

C — ELT (Extract, Load, Transform — trích xuất, nạp, biến đổi).

Vì sao đúng

Đề mô tả đúng thứ tự của ELT: nạp tệp nhật ký THÔ vào bảng staging trong BigQuery TRƯỚC, rồi mới dùng các script SQL để làm sạch, loại trùng và nối dữ liệu thành bảng production.

⚠ Điểm mấu chốt — biến đổi xảy ra SAU khi nạp, và NGAY TRONG kho:

E — Trích xuất tệp nhật ký từ Cloud Storage
        ↓
L — NẠP vào bảng STAGING trong BigQuery
        ↓        (dữ liệu vẫn còn THÔ)
        ↓
T — Chạy SQL để làm sạch, loại trùng, join
        ↓
    Bảng PRODUCTION
        ↓
    ⚠ Biến đổi bằng SQL, TRONG BigQuery
    → đây chính là ELT

⚠ Cấu trúc tầng mà đề mô tả:

STAGING  → dữ liệu thô như nguồn
             (bản ghi gốc, chạy lại được)
        ↓
PRODUCTION → đã sạch, đã loại trùng,
             đã nối — sẵn sàng dùng
        ↓
    ⚠ Thêm một tầng RAW phía trước
      là mô hình ba tầng đầy đủ

⚠ Vì sao mô hình này phổ biến với BigQuery:

- Nạp theo lô vào BigQuery MIỄN PHÍ
- BigQuery biến đổi hàng tỉ dòng
  nhanh và rẻ
- Giữ được dữ liệu thô ở staging
  → chạy lại khi logic đổi
- Không cần hạ tầng biến đổi riêng
- Đội chỉ cần biết SQL

Xem thêm câu #12958 (lô 134), #12989 và #12993 (lô 135): cùng chủ đề ELT — nhận diện luồng, ưu điểm, khác biệt cơ bản với ETL. Bốn câu hoàn toàn nhất quán. Và #13032 (cùng lô) khoá ETL vì ở đó phải làm sạch trước khi dữ liệu sẵn sàng phân tích.

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

• B (ETL) — đây là phương án đối lập trực tiếp: nó biến đổi TRƯỚC khi nạp, còn đề nói rõ dữ liệu thô được nạp vào staging trước.

• A (Reverse ETL) — đưa dữ liệu TỪ kho NGƯỢC RA các hệ thống nghiệp vụ như CRM. Hướng ngược lại.

• D (Streaming Ingestion) — mô tả cách NẠP theo luồng; đề nói tệp nhật ký hằng ngày, tức là theo lô.

Ghi nhớ

⚠ ETL ↔ ELT — bảng phải thuộc: | | ETL | ELT | |---|---|---| | Thứ tự | E → T → L | E → L → T | | Nơi biến đổi | công cụ ngoài | trong kho, bằng SQL | | Dữ liệu thô trong kho | không | có (staging) | | Chạy lại logic mới | trích xuất lại từ nguồn | chạy lại từ staging | | Hợp khi | PII không được vào kho | hầu hết trường hợp | | Công cụ | Dataflow, Data Fusion | BigQuery SQL, Dataform |

Từ khoá nhận diện:

"nạp thô vào staging rồi chạy SQL" → ELT "làm sạch trước khi nạp" → ETL "kho → CRM, công cụ marketing" → Reverse ETL "nạp theo luồng thời gian thực" → streaming ingestion — cách nạp, không phải mô hình "che PII trước khi vào kho" → bắt buộc ETL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Staging có khớp nguồn không | so số dòng với số dòng trong tệp | | Loại trùng có đúng không | so COUNT(*) và COUNT(DISTINCT khoa) | | Chạy lại có ra cùng kết quả không | kiểm thử tính lặp lại được |

Và một điều nên chốt sớm khi vận hành mô hình này: giữ bảng staging bao lâu. Nó là thứ cho phép bạn chạy lại toàn bộ phép biến đổi khi logic thay đổi — nhưng nếu không có chính sách phân vùng và hạn dùng, nó cũng là thứ âm thầm chiếm phần lớn dung lượng kho sau vài năm.

Đáp án

B — BigQuery Data Owner (roles/bigquery.dataOwner).

Vì sao đúng

Trong bốn phương án được đưa ra, đây là vai trò duy nhất cho phép SỬA ĐỔI dữ liệu và cấu trúc (tạo bảng, đổi lược đồ, xoá dữ liệu) mà vẫn giới hạn ở phạm vi DATASET, không phải toàn quyền BigQuery.

⚠ Điểm mấu chốt — loại trừ từng phương án:

BigQuery Data Viewer
    → CHỈ ĐỌC
    → không tạo, không sửa, không xoá ✗

BigQuery Job User
    → chỉ CHẠY JOB
    → không đọc, không ghi bảng nào ✗

BigQuery Admin
    → TOÀN QUYỀN trên CẢ PROJECT
    → chính là thứ đề nói phải tránh ✗

BigQuery Data Owner              ← còn lại
    → tạo/sửa/xoá bảng và dữ liệu
    → phạm vi DATASET, không phải project ✓

⚠ dataOwner gồm những gì:

= tất cả quyền của dataEditor
    tạo, sửa, xoá BẢNG và VIEW
    đọc và ghi DỮ LIỆU
        ↓
  + quản lý QUYỀN của chính dataset
  + xoá dataset
        ↓
    ⚠ Vẫn KHÔNG có quyền trên
      dataset khác hay reservation
    → đúng nghĩa "không phải toàn quyền
      môi trường BigQuery"

⚠ Cấp đúng phạm vi:

bq add-iam-policy-binding \
  --member="serviceAccount:sa@du-an.iam.gserviceaccount.com" \
  --role="roles/bigquery.dataOwner" \
  du_an:dataset_can_quan_ly
        ↓
    ⚠ Cấp trên DATASET, không cấp trên project

Ghi nhớ về chất lượng câu hỏi

Trong thực tế, roles/bigquery.dataEditor mới là vai trò tối thiểu cho đúng ba việc mà đề liệt kê (tạo bảng, đổi lược đồ, xoá dữ liệu) — dataOwner thêm quyền quản lý IAM của dataset và xoá dataset, vốn không cần thiết.

Nhưng dataEditor KHÔNG có trong bốn phương án, nên trong phạm vi câu hỏi này, B là đáp án đúng duy nhất còn cho quyền sửa đổi.

Đối chiếu: câu #12995 (lô 135) và #12975 (lô 134) cùng chủ đề nhưng khoá là dataEditor — vì ở đó dataEditor CÓ trong danh sách phương án. Ba câu không mâu thuẫn: khoá khác nhau vì bộ phương án khác nhau. Quy tắc khi làm bài: chọn phương án hẹp nhất CÓ TRONG DANH SÁCH mà vẫn đủ dùng.

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

• C (BigQuery Admin) — đây là phương án gần nhất về năng lực, nhưng nó cho toàn quyền trên CẢ PROJECT: mọi dataset, reservation, cấu hình — chính là "toàn quyền quản trị môi trường BigQuery" mà đề loại bỏ.

• A (BigQuery Data Viewer) — chỉ đọc, không tạo hay xoá được gì.

• D (BigQuery Job User) — chỉ chạy job, không có quyền trên dữ liệu.

Ghi nhớ

⚠ Các vai trò BigQuery theo mức tăng dần — bảng phải thuộc: | Vai trò | Quyền | |---|---| | bigquery.metadataViewer | thấy tên bảng và lược đồ, KHÔNG đọc dữ liệu | | bigquery.dataViewer | đọc dữ liệu | | bigquery.dataEditor | + tạo, sửa, xoá bảng; ghi dữ liệu | | bigquery.dataOwner | + quản lý QUYỀN dataset, xoá dataset | | bigquery.jobUser | chỉ chạy job (trục riêng) | | bigquery.user | jobUser + tạo dataset mới | | bigquery.admin | toàn quyền cả project |

Từ khoá nhận diện:

"tạo/sửa/xoá bảng, không đụng dataset khác" → dataEditor (nếu có), nếu không thì dataOwner "quản lý ai được vào dataset" → dataOwner "chỉ đọc" → dataViewer "chạy truy vấn" → jobUser (kèm quyền dữ liệu) "Admin cho chắc" → luôn sai trong câu hỏi quyền tối thiểu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có quyền trên dataset | bq show --format=prettyjson <dataset> → access | | Vai trò gồm permission nào | gcloud iam roles describe roles/bigquery.dataOwner | | Có quyền thừa không | IAM Recommender |

Và một chiến lược làm bài đáng nhớ cho mọi câu hỏi về quyền tối thiểu: đáp án đúng là phương án hẹp nhất CÓ TRONG DANH SÁCH, không phải vai trò hẹp nhất tồn tại. Khi dataEditor không được đưa ra, dataOwner trở thành lựa chọn đúng — nhưng ngoài phòng thi, hãy luôn kiểm tra xem có vai trò hẹp hơn không trước khi cấp.