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

Đáp án

D — Notebook có thể được CHẠY LẠI mỗi ngày để thực thi cùng đoạn mã, tự động lấy dữ liệu mới và cập nhật các biểu đồ.

Vì sao đúng

Đề mô tả đúng tình huống mà notebook toả sáng: cấu trúc báo cáo KHÔNG đổi, chỉ có dữ liệu bên dưới thay đổi liên tục. Mã đã viết một lần, chạy lại là ra báo cáo mới.

⚠ Điểm mấu chốt — mã là thứ tái sử dụng được:

Notebook chứa:
    truy vấn BigQuery
    + phép biến đổi bằng pandas
    + mã vẽ biểu đồ
        ↓
    Chạy lại toàn bộ notebook
        ↓
    → truy vấn lấy dữ liệu MỚI NHẤT
    → biểu đồ tự vẽ lại
        ↓
    ⚠ Không phải làm lại thao tác nào
    ⚠ Kết quả LẶP LẠI ĐƯỢC — cùng mã,
      cùng logic, chỉ khác dữ liệu

⚠ Và có thể tự động hoá hẳn:

Colab Enterprise / Vertex AI
        ↓
    LÊN LỊCH chạy notebook
    (notebook executor)
        ↓
    → chạy mỗi sáng, lưu bản đã thực thi
        ↓
    Hoặc:
      papermill để tham số hoá và chạy
      Cloud Composer để điều phối

⚠ Vì sao ba phương án kia sai:

"Notebook TỰ ĐỘNG gửi email báo cáo"
    → KHÔNG phải tính năng sẵn có;
      phải tự viết mã gửi mail

"Notebook là công cụ DUY NHẤT
 truy vấn được BigQuery"
    → SAI hoàn toàn: giao diện BigQuery,
      bq CLI, Looker Studio, Connected Sheets...

"Notebook cung cấp môi trường cộng tác
 an toàn cấp doanh nghiệp"
    → Colab Enterprise CÓ điều này,
      nhưng đó KHÔNG phải lợi ích
      của việc dùng notebook cho
      TÁC VỤ LẶP LẠI như đề hỏi

Xem thêm câu #13029 (cùng lô) và #12922 (lô 134): cùng về Colab Enterprise / Vertex AI Notebooks — chọn công cụ. Câu này về lợi ích khi dùng nó cho báo cáo định kỳ.

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

• C (môi trường cộng tác an toàn cấp doanh nghiệp) — đây là phương án gần nhất và là một ưu điểm CÓ THẬT của Colab Enterprise, nhưng nó không trả lời câu hỏi: đề hỏi lợi ích cho tác vụ LẶP LẠI hằng ngày.

• A (tự động gửi email báo cáo) — không phải tính năng sẵn có của notebook.

• B (công cụ duy nhất truy vấn được BigQuery) — sai rõ ràng.

Ghi nhớ

⚠ Khi nào notebook là lựa chọn đúng — bảng phải thuộc: | Tình huống | Notebook có hợp không | |---|---| | Phân tích tuỳ hứng, khám phá | rất hợp | | Báo cáo cùng cấu trúc, dữ liệu đổi | hợp — chạy lại là xong | | Cần Python, pandas, thư viện vẽ | hợp | | Dashboard cho người dùng nghiệp vụ | KHÔNG — dùng Looker Studio | | Pipeline sản xuất quan trọng | KHÔNG — tách mã thành module | | Chia sẻ rộng, nhiều người xem | KHÔNG — dùng công cụ BI |

Từ khoá nhận diện:

"cùng mã, dữ liệu mới, chạy lại" → lợi ích của notebook "dashboard cho lãnh đạo" → Looker Studio "pipeline sản xuất" → tách mã, dùng Composer/Pipelines "gửi email tự động" → phải tự viết, hoặc dùng scheduled query + Looker Studio "phân tích một lần rồi thôi" → notebook cũng hợp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Notebook có chạy lại được từ đầu không | Restart & Run All | | Có phụ thuộc ngày cứng không | tìm chuỗi ngày hard-code trong mã | | Kết quả có được lưu lại không | kiểm tra bảng hoặc tệp đầu ra |

Và một phép thử đơn giản quyết định notebook có thật sự "chạy lại được" hay không: Restart & Run All. Rất nhiều notebook chỉ chạy đúng theo thứ tự mà tác giả từng bấm, và phụ thuộc vào một biến còn sót lại từ ô lệnh đã xoá — chạy lại từ đầu là cách duy nhất để biết ngày mai nó còn hoạt động hay không.

Đáp án

A — Mô hình ETL, dùng Dataflow.

Vì sao đúng

Đề nêu ba điều: luồng click thời gian thực, phải kiểm tra và làm sạch, loại bỏ bản ghi không hợp lệ, và làm việc đó TRƯỚC KHI dữ liệu sẵn sàng để phân tích trong BigQuery. Biến đổi xảy ra trước khi nạp — đó là ETL, và Dataflow là engine luồng.

⚠ Điểm mấu chốt — thứ tự trong đề quyết định mô hình:

"kiểm tra và làm sạch"
    TRƯỚC KHI
"sẵn sàng cho phân tích trong BigQuery"
        ↓
    → biến đổi ĐI TRƯỚC nạp
    → ETL, không phải ELT
        ↓
    Và vì là LUỒNG thời gian thực
        ↓
    → engine phải là DATAFLOW

⚠ Kiến trúc đầy đủ:

Ứng dụng di động
        ↓
    Pub/Sub  (thu nhận, làm bộ đệm)
        ↓
    Dataflow (streaming)
      - kiểm tra tính hợp lệ
      - loại bản ghi hỏng → DEAD-LETTER
      - chuẩn hoá kiểu
        ↓
    BigQuery — phân tích ngay

⚠ Vì sao hai phương án ELT không dùng được:

ELT với Cloud Data Fusion
    → Data Fusion thiên về XỬ LÝ THEO LÔ
    → không phải công cụ luồng độ trễ thấp

ELT với scheduled query
    → chạy THEO LỊCH, không phải thời gian thực
    → và dữ liệu bẩn ĐÃ VÀO kho rồi
        ↓
    ⚠ Đề nói "sẵn sàng cho phân tích NGAY"
      → không thể chờ tới lần chạy kế tiếp

⚠ Bản ghi không hợp lệ đi đâu — đừng bỏ im lặng:

Dataflow tách hai nhánh:
    hợp lệ  → bảng chính trong BigQuery
    hỏng    → bảng lỗi (dead-letter)
        ↓
    ⚠ "Loại bỏ" KHÔNG có nghĩa là XOÁ
    → giữ lại để biết vì sao hỏng

Xem thêm câu #12989 và #12993 (lô 135): nói về ưu điểm của ELT và khác biệt cơ bản ETL/ELT. Câu này chọn ETL vì đề yêu cầu làm sạch trước khi dữ liệu sẵn sàng phân tích. Không mâu thuẫn — ELT là mặc định, ETL khi có ràng buộc rõ ràng như ở đây.

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

• D (ELT với scheduled query) — đây là phương án gần nhất về mặt "làm sạch bằng SQL", nhưng scheduled query chạy theo lịch, không đáp ứng được yêu cầu phân tích ngay, và dữ liệu bẩn đã nằm trong kho.

• C (ELT với Cloud Data Fusion) — Data Fusion là công cụ ETL trực quan thiên về lô, không phải engine luồng.

• B (ETL với BigQuery Data Transfer Service) — DTS không biến đổi gì cả và không xử lý luồng thời gian thực.

Ghi nhớ

⚠ Chọn mô hình và engine — bảng phải thuộc: | Yêu cầu | Mô hình | Engine | |---|---|---| | Làm sạch TRƯỚC khi vào kho, thời gian thực | ETL | Dataflow | | Nạp thô rồi biến đổi bằng SQL | ELT | BigQuery + Dataform | | Làm sạch trước, theo lô, không lập trình | ETL | Cloud Data Fusion | | Chỉ nạp, không biến đổi | — | Pub/Sub BigQuery subscription | | Nạp theo lịch từ SaaS | — | BigQuery Data Transfer Service |

Từ khoá nhận diện:

"làm sạch trước khi phân tích, thời gian thực" → ETL + Dataflow "nạp thô rồi biến đổi trong kho" → ELT "không cần biến đổi" → Pub/Sub subscription ghi thẳng "che PII trước khi vào kho" → ETL bắt buộc "theo lịch" → không phải thời gian thực

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline có theo kịp không | Data freshness trong Job metrics | | Tỉ lệ bản ghi hỏng | COUNT(*) bảng lỗi so với bảng chính | | Dữ liệu tới BigQuery chưa | SELECT MAX(<thời điểm>) |

Và một quyết định nên làm rõ ngay khi thiết kế bước kiểm tra: "loại bỏ bản ghi không hợp lệ" nghĩa là vứt đi hay giữ riêng? Vứt đi thì pipeline sạch nhưng bạn mất khả năng biết nguồn đang hỏng như thế nào; giữ riêng vào một bảng lỗi tốn rất ít mà cho bạn đúng thông tin cần để sửa từ gốc.

Đáp án

D — Dataflow.

Vì sao đúng

Đề cần MỘT pipeline THỐNG NHẤT xử lý cả dữ liệu luồng thời gian thực lẫn nhật ký lịch sử theo lô. Đó chính là lời hứa cốt lõi của Apache Beam — mô hình lập trình mà Dataflow triển khai.

⚠ Điểm mấu chốt — Beam thống nhất lô và luồng:

Apache Beam
        ↓
    MỘT mô hình lập trình duy nhất
        ↓
    Cùng một đoạn mã biến đổi
      chạy được cho:
        - PCollection VÔ HẠN (luồng)
        - PCollection HỮU HẠN (lô)
        ↓
    Chỉ khác ở NGUỒN ĐỌC:
      PubsubIO.readStrings()   → luồng
      TextIO.read().from(...)  → lô
        ↓
    ⚠ Logic làm sạch, biến đổi
      KHÔNG PHẢI VIẾT HAI LẦN

⚠ Vì sao "một pipeline thống nhất" lại đáng giá:

Không có mô hình thống nhất
        ↓
    Viết HAI hệ thống:
      một cho luồng, một cho lô
        ↓
    ⚠ Hai bộ mã phải giữ đồng bộ
    ⚠ Logic lệch nhau → SỐ LIỆU LỆCH NHAU
    ⚠ Sửa lỗi phải sửa hai chỗ
        ↓
    Đây chính là vấn đề mà kiến trúc
    Lambda gặp phải, và Beam sinh ra để giải

⚠ Cùng logic, hai nguồn:

PCollection<String> luong = p.apply(
    PubsubIO.readStrings().fromTopic("..."));
PCollection<String> lo = p.apply(
    TextIO.read().from("gs://..."));

PCollection<String> tatCa =
    PCollectionList.of(luong).and(lo)
        .apply(Flatten.pCollections())
        .apply(ParDo.of(new LamSach()));
        ↓
    ⚠ LamSach() dùng chung cho cả hai

Xem thêm câu #13030 (lô 135): khoá Dataflow vì tiêu chí hiệu năng và ít tài nguyên. Câu này chọn Dataflow vì thống nhất lô và luồng. Hai câu cùng khoá, hai lý do bổ sung nhau — nhất quán.

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

• C (Cloud Data Fusion) — đây là phương án gần nhất vì cũng là công cụ ETL đa năng, nhưng nó thiên về xử lý THEO LÔ (chạy trên Dataproc) và không phải engine luồng độ trễ thấp; nó cũng không có mô hình thống nhất như Beam.

• A (BigQuery Data Transfer Service) — chỉ nạp theo lịch từ nguồn định sẵn, không xử lý luồng, không biến đổi.

• B (Storage Transfer Service) — chuyển TỆP giữa các kho đối tượng, hoàn toàn không liên quan.

Ghi nhớ

⚠ Dataflow và Apache Beam — điều cần thuộc: | Điểm | Nội dung | |---|---| | Mô hình | Apache Beam — thống nhất LÔ và LUỒNG | | Ngôn ngữ | Java, Python, Go | | Không máy chủ | tự co giãn, trả tiền theo tài nguyên dùng | | PCollection | hữu hạn (lô) hoặc vô hạn (luồng) | | Cùng logic biến đổi | dùng chung cho cả hai | | Template | pipeline dựng sẵn, chạy không cần viết mã |

Từ khoá nhận diện:

"một pipeline cho cả luồng và lô" → Dataflow "kéo thả, không lập trình" → Cloud Data Fusion "đã có Spark" → Dataproc "chỉ nạp theo lịch" → Data Transfer Service "chuyển tệp" → Storage Transfer Service

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Job đang chạy chế độ nào | Dataflow console — Batch hay Streaming | | Nhánh lô và luồng có cho kết quả nhất quán không | đối chiếu số liệu trên cùng khoảng thời gian | | Bước nào là nút thắt | Job graph, xem throughput từng bước |

Và một lợi ích của mô hình thống nhất mà chỉ thấy rõ sau vài tháng vận hành: khi logic nghiệp vụ thay đổi, bạn sửa đúng một chỗ. Với hai hệ thống riêng cho lô và luồng, mỗi lần đổi cách tính là một lần phải nhớ sửa cả hai — và lần quên đầu tiên sẽ tạo ra hai con số khác nhau cho cùng một chỉ số, thứ rất khó giải thích trong một cuộc họp.

Đáp án

A — BigQuery ML.

Vì sao đúng

Đề nêu ba điều: dữ liệu đã nằm trong BigQuery, nhà phân tích giỏi SQL nhưng KHÔNG biết Python hay framework học máy, và cần tạo, huấn luyện, dự đoán NGAY TRONG kho bằng SQL. Đó chính là lý do BigQuery ML tồn tại.

⚠ Điểm mấu chốt — toàn bộ vòng đời mô hình bằng SQL:

-- 1. HUẤN LUYỆN
CREATE OR REPLACE MODEL `du_an.du_doan_roi_bo`
OPTIONS(
  model_type = 'LOGISTIC_REG',
  input_label_cols = ['da_roi_bo'],
  auto_class_weights = TRUE
) AS
SELECT * FROM `du_an.lich_su_khach_hang`;

-- 2. ĐÁNH GIÁ
SELECT * FROM ML.EVALUATE(MODEL `du_an.du_doan_roi_bo`);

-- 3. DỰ ĐOÁN
SELECT * FROM ML.PREDICT(
  MODEL `du_an.du_doan_roi_bo`,
  (SELECT * FROM `du_an.khach_hang_hien_tai`));

        ↓
    ⚠ Không một dòng Python nào
    ⚠ Dữ liệu KHÔNG rời khỏi BigQuery

⚠ Vì sao "dữ liệu không phải di chuyển" lại quan trọng:

Cách truyền thống
    → xuất dữ liệu ra khỏi kho
    → đưa vào môi trường huấn luyện
    → nhập kết quả về
        ↓
    ⚠ thêm một bản sao dữ liệu khách hàng
      cần bảo vệ
    ⚠ thêm bước, thêm chỗ hỏng, thêm thời gian

BQML
    → mô hình chạy TẠI CHỖ
    → ít rủi ro tuân thủ hơn hẳn

⚠ Với bài toán rời bỏ khách hàng — hai điều phải nhớ:

1. DỮ LIỆU RẤT MẤT CÂN BẰNG
    tỉ lệ rời bỏ thường vài phần trăm
        ↓
    → auto_class_weights = TRUE
    → đọc AUC, precision, recall
      thay vì accuracy

2. RÒ RỈ DỮ LIỆU (data leakage)
    → loại các cột chỉ tồn tại
      SAU KHI khách đã rời bỏ
      (ví dụ "ngày huỷ hợp đồng")
        ↓
    ⚠ Mô hình sẽ đạt độ chính xác
      gần như hoàn hảo — và vô dụng

Xem thêm câu #12919 (lô 133): cùng tình huống dự đoán rời bỏ/vỡ nợ bằng SQL, cùng khoá BigQuery ML. Hai câu hoàn toàn nhất quán. Và #12983 (lô 135) về cú pháp CREATE MODEL, #12962 (lô 134) về ML.PREDICT.

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

• B (AutoML) — đây là phương án gần nhất vì cũng hướng tới người ít kinh nghiệm ML, nhưng nó là giao diện của Vertex AI, đòi đưa dữ liệu vào Vertex AI và làm việc ngoài SQL. (BQML gọi được AutoML qua model_type='AUTOML_CLASSIFIER', nhưng bản thân AutoML không phải "chỉ dùng SQL trong kho".)

• C (Vertex AI Workbench) — môi trường notebook viết Python, đúng thứ nhà phân tích không làm được.

• D (Dataflow) — công cụ xử lý dữ liệu, không phải nền tảng học máy.

Ghi nhớ

⚠ Chọn công cụ ML theo kỹ năng — bảng phải thuộc: | Kỹ năng của đội | Công cụ | |---|---| | Chỉ SQL, dữ liệu đã ở BigQuery | BigQuery ML | | Python, cần kiểm soát chi tiết | Vertex AI (Workbench, Training) | | Muốn tự động chọn mô hình | AutoML (qua Vertex AI hoặc BQML) | | Cần mô hình dựng sẵn | API của Vertex AI — ảnh, ngôn ngữ, giọng nói | | Điều phối luồng ML | Vertex AI Pipelines |

Từ khoá nhận diện:

"chỉ dùng SQL, ngay trong BigQuery" → BigQuery ML "đội Python, cần tuỳ biến sâu" → Vertex AI "gọi mô hình nền tảng từ SQL" → remote model + ML.GENERATE_TEXT "nhận dạng ảnh, dịch" → API dựng sẵn "xử lý dữ liệu" → Dataflow — không phải ML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình tốt tới đâu | ML.EVALUATE — nhìn AUC, không nhìn accuracy | | Đặc trưng nào quan trọng | ML.FEATURE_IMPORTANCE | | Có rò rỉ dữ liệu không | kiểm tra cột nào chỉ có SAU khi khách rời bỏ |

Và một dấu hiệu cảnh báo nên nhớ khi mô hình đầu tiên cho kết quả quá đẹp: AUC gần 1,0 với bài toán rời bỏ khách hàng gần như luôn là rò rỉ dữ liệu. Một cột như "lý do huỷ" hay "ngày kết thúc hợp đồng" lọt vào tập đặc trưng sẽ cho mô hình biết trước câu trả lời — và nó sẽ hoàn toàn vô dụng trên khách hàng chưa rời bỏ.

Đáp án

D — Cấp cho group "Sales" quyền 'View' trên folder, rồi dùng USER ATTRIBUTE FILTER để triển khai bảo mật ở cấp DÒNG.

Vì sao đúng

Đề cần hai thứ cùng lúc: mọi người dùng CHUNG một dashboard (nên không thể nhân bản dashboard), và mỗi người chỉ thấy dữ liệu của mình (nên phải lọc theo danh tính người xem).

⚠ Điểm mấu chốt — hai tầng, mỗi tầng giải một nửa:

TẦNG 1 — QUYỀN NỘI DUNG
    folder + group + View
        ↓
    → cả đội THẤY được dashboard
    → thêm người: chỉ cần thêm vào group

TẦNG 2 — QUYỀN DỮ LIỆU
    user attribute + access_filter
        ↓
    → Looker TỰ THÊM điều kiện lọc
      vào mọi truy vấn của người đó
        ↓
    ⚠ MỘT dashboard, N người xem,
      mỗi người thấy dữ liệu riêng

⚠ Cấu hình trong LookML:

explore: tai_khoan {
  access_filter: {
    field: tai_khoan.nhan_vien_email
    user_attribute: email_nguoi_dung
  }
}

        ↓
    Mỗi người dùng có thuộc tính
      email_nguoi_dung
        ↓
    → SQL sinh ra tự kèm
      WHERE nhan_vien_email = '<của họ>'
        ↓
    ⚠ Lọc áp ở TẦNG MÔ HÌNH
    → người dùng KHÔNG gỡ được

⚠ Vì sao "mỗi người một dashboard" là sai lầm:

50 nhân viên bán hàng
        ↓
    → 50 dashboard giống hệt nhau
        ↓
    ⚠ Sửa một biểu đồ → sửa 50 lần
    ⚠ Người mới vào → tạo dashboard mới
    ⚠ Không ai chắc 50 cái còn giống nhau
        ↓
    → không mở rộng được, và
      chắc chắn sẽ lệch nhau theo thời gian

Xem thêm câu #13013 (lô 135): chỉ hỏi về quyền NỘI DUNG → folder + group. Câu này thêm quyền DỮ LIỆU → user attribute. Và #12978 (lô 134): cùng cơ chế access_filter nhưng cho nhúng đa khách hàng. Ba câu nhất quán, mô tả các mức khác nhau của cùng một hệ thống.

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

• C (cấp 'Manage Access' trên folder cho từng người) — đây là phương án gần nhất vì cũng cấp quyền folder, nhưng nó quá nhiều quyền (họ cấp được quyền cho người khác) và không lọc dữ liệu — mọi người vẫn thấy toàn bộ tài khoản.

• B (tạo dashboard riêng cho từng người) — không mở rộng được, và trái yêu cầu "dùng CHUNG một dashboard".

• A (gửi PDF riêng theo lịch) — cho ảnh chụp tĩnh, không tương tác được, và vẫn phải cấu hình riêng cho từng người.

Ghi nhớ

⚠ Hai tầng quyền của Looker — bảng phải thuộc: | Tầng | Cơ chế | Trả lời câu hỏi | |---|---|---| | Quyền NỘI DUNG | folder permission + group | thấy được dashboard nào | | Quyền MÔ HÌNH | role = permission set + model set | truy cập được mô hình nào | | Quyền DỮ LIỆU (dòng) | user attribute + access_filter | thấy được DÒNG nào | | Quyền DỮ LIỆU (cột) | access_grant | thấy được TRƯỜNG nào | | Phải cấu hình | cả ba tầng đầu mới dùng được |

Từ khoá nhận diện:

"cùng dashboard, mỗi người dữ liệu riêng" → user attribute + access_filter "cho cả nhóm xem" → folder + group + View "ẩn một số trường" → access_grant "nhúng cho khách hàng ngoài" → signed embed + user attribute "mỗi người một dashboard" → luôn là phương án SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng có thuộc tính chưa | Admin → Users → xem user attribute | | Bộ lọc có áp không | xem SQL trong Explore | | Người khác có thấy được không | impersonate và thử |

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

Đáp án

A — Pub/Sub.

Vì sao đúng

Đề nêu bốn điều: khối lượng lớn từ hàng nghìn thiết bị toàn cầu, cần một bộ đệm BỀN VỮNG và CO GIÃN, để TÁCH RỜI thiết bị phát dữ liệu khỏi hệ thống xử lý phía sau, và phải không máy chủ. Đó là mô tả chính xác của Pub/Sub.

⚠ Điểm mấu chốt — "tách rời" nghĩa là gì trong thực tế:

KHÔNG có bộ đệm
        ↓
    Thiết bị gọi thẳng hệ thống xử lý
        ↓
    ⚠ Hệ thống xử lý chậm → thiết bị bị chặn
    ⚠ Hệ thống xử lý chết → MẤT DỮ LIỆU
    ⚠ Thêm hệ thống mới → sửa firmware thiết bị

CÓ PUB/SUB
        ↓
    Thiết bị chỉ publish rồi thôi
        ↓
    → bên nhận chết: thông điệp NẰM CHỜ
      (tới 7 ngày, tối đa 31 ngày)
    → thêm bên nhận: tạo subscription mới,
      KHÔNG đụng tới thiết bị
    → đỉnh tải: Pub/Sub hấp thụ,
      bên nhận xử lý theo tốc độ của nó

⚠ "Bền vững" và "co giãn" — hai từ khoá quan trọng:

BỀN VỮNG (durable)
    → thông điệp được nhân bản,
      không mất khi một máy hỏng
    → giữ tới 7 ngày mặc định

CO GIÃN (scalable)
    → KHÔNG phải khai trước dung lượng
    → tự chịu được từ vài thông điệp
      tới hàng triệu mỗi giây
        ↓
    ⚠ Toàn cầu: một endpoint duy nhất,
      thiết bị ở đâu cũng gửi tới được

⚠ Với IoT quy mô lớn — vài lưu ý:

Thiết bị dùng MQTT
    → cần cầu nối MQTT → Pub/Sub
    → (Cloud IoT Core đã ngừng, nay dùng
       giải pháp đối tác hoặc tự dựng)

Ordering key
    → bảo đảm thứ tự cho TỪNG thiết bị

Thông điệp trùng
    → at-least-once → xử lý phải BẤT BIẾN

Quy mô rất lớn, chi phí thấp hơn
    → cân nhắc Pub/Sub Lite (theo phân vùng)

Xem thêm câu #12949 (lô 134): cùng vai trò bộ đệm tách rời, cùng khoá Pub/Sub. Và #12972 (lô 134): cấu hình một topic, nhiều subscription. Ba câu hoàn toàn nhất quán.

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

• D (Dataflow) — đây là phương án gần nhất trong kiến trúc luồng và luôn đi cùng Pub/Sub, nhưng nó là engine XỬ LÝ, không phải bộ đệm thu nhận. Nó là bên nhận dữ liệu từ Pub/Sub.

• B (BigQuery) — kho phân tích, là đích đến cuối cùng, không phải lớp thu nhận.

• C (Cloud Composer) — công cụ ĐIỀU PHỐI luồng công việc, hoàn toàn không liên quan tới việc thu nhận dữ liệu luồng.

Ghi nhớ

⚠ Vai trò từng dịch vụ trong kiến trúc luồng — bảng phải thuộc: | Vai trò | Dịch vụ | |---|---| | Thu nhận, bộ đệm, tách rời | Pub/Sub | | Xử lý, biến đổi, tổng hợp | Dataflow | | Kho phân tích | BigQuery | | Tra cứu độ trễ cực thấp | Bigtable, Memorystore | | Điều phối luồng công việc | Cloud Composer | | Nhớ | mỗi dịch vụ MỘT vai trò |

Từ khoá nhận diện:

"bộ đệm, tách rời, thu nhận khối lượng lớn" → Pub/Sub "biến đổi, cửa sổ, làm giàu" → Dataflow "phân tích bằng SQL" → BigQuery "đọc ghi từng thiết bị, độ trễ mili giây" → Bigtable "quản lý thứ tự các bước" → Cloud Composer

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thông điệp tồn đọng không | Monitoring → num_undelivered_messages | | Bên nhận có theo kịp không | oldest_unacked_message_age | | Có thông điệp hỏng không | kiểm tra dead-letter topic |

Và một chỉ số nên đặt cảnh báo ngay từ ngày đầu với hệ thống IoT: tuổi của thông điệp chưa được xác nhận cũ nhất. Backlog tăng có thể chỉ là đỉnh tải tạm thời, nhưng một thông điệp nằm chờ nhiều giờ nghĩa là bên nhận đã ngừng theo kịp — và nếu vượt quá thời gian giữ, dữ liệu sẽ bị mất mà không có tín hiệu nào khác.

Đáp án

C — Các hàm AEAD (Authenticated Encryption with Associated Data).

Vì sao đúng

Đề nêu ba yêu cầu rất cụ thể: dữ liệu LUÔN được lưu ở dạng BẢN MÃ, nhà phân tích phải gọi tường minh một HÀM trong truy vấn, và phải có quyền trên KHOÁ mới thấy được giá trị. Chỉ AEAD thoả cả ba.

⚠ Điểm mấu chốt — mã hoá ngay trong cột, không phải che lúc đọc:

GHI:
INSERT INTO benh_nhan (cmnd_ma)
SELECT AEAD.ENCRYPT(
  (SELECT keyset FROM khoa_y_te),
  cmnd,
  CAST(benh_nhan_id AS STRING));
        ↓
    ⚠ Trên đĩa CHỈ CÓ BẢN MÃ
    → nhìn thẳng vào bảng: chuỗi byte

ĐỌC:
SELECT AEAD.DECRYPT_STRING(
  (SELECT keyset FROM khoa_y_te),
  cmnd_ma,
  CAST(benh_nhan_id AS STRING)) AS cmnd;
        ↓
    ⚠ Phải GỌI HÀM tường minh
    ⚠ Phải có quyền đọc KEYSET

⚠ "Associated data" — phần chữ AD trong AEAD:

Tham số thứ ba (ở đây là benh_nhan_id)
        ↓
    KHÔNG được mã hoá, nhưng ĐƯỢC XÁC THỰC
        ↓
    Giải mã với associated data KHÁC
        ↓
    → THẤT BẠI
        ↓
    ⚠ Chống việc COPY bản mã từ dòng này
      sang dòng khác
    → bản mã gắn chặt với ngữ cảnh của nó

⚠ Vì sao đây là mức bảo vệ cao nhất trong bốn phương án:

Kẻ có quyền đọc bảng nhưng KHÔNG có khoá
        ↓
    → chỉ thấy chuỗi byte vô nghĩa
        ↓
    ⚠ Kể cả quản trị viên BigQuery
    ⚠ Kể cả khi bảng bị sao chép ra ngoài
        ↓
    Đây là điều mà masking và
    column-level security KHÔNG làm được —
    vì ở đó dữ liệu trên đĩa vẫn nguyên văn

Xem thêm câu #12982 (lô 135): yêu cầu dữ liệu lưu ở dạng NGUYÊN VĂN, che khi truy vấn → khoá Dynamic Data Masking. Và #13004 (lô 135): hỏi chính khác biệt giữa AEAD và masking. Ba câu nhất quán — khoá khác nhau vì yêu cầu về DẠNG LƯU TRỮ khác nhau.

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

• A (Dynamic Data Masking) — đây là phương án gần nhất và cũng bảo vệ cột nhạy cảm, nhưng dữ liệu trên đĩa vẫn là NGUYÊN VĂN; nó chỉ che lúc trả kết quả. Trái yêu cầu "luôn lưu ở dạng bản mã".

• D (CMEK) — quản lý khoá mã hoá ĐĨA cho toàn bộ dataset; nó không yêu cầu gọi hàm và không mã hoá riêng một cột.

• B (Authorized View) — kiểm soát ai thấy kết quả gì, nhưng dữ liệu gốc vẫn nguyên văn trong bảng.

Ghi nhớ

⚠ Bốn cơ chế bảo vệ dữ liệu BigQuery — bảng phải thuộc: | Cơ chế | Dữ liệu trên đĩa | Cách truy cập | |---|---|---| | AEAD | BẢN MÃ | gọi hàm giải mã + quyền trên khoá | | Dynamic data masking | nguyên văn | truy vấn bình thường, giá trị bị che | | Column-level security | nguyên văn | bị TỪ CHỐI nếu thiếu quyền | | CMEK | mã hoá đĩa (như mọi bảng) | trong suốt với người dùng | | Authorized view | nguyên văn | chỉ thấy kết quả của view |

Từ khoá nhận diện:

"luôn lưu ở dạng bản mã, phải gọi hàm" → AEAD "dữ liệu gốc nguyên vẹn, che khi đọc" → masking "chặn hẳn không cho đọc cột" → column-level security "tự quản khoá mã hoá đĩa" → CMEK "chia sẻ kết quả, giấu bảng gốc" → authorized view

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cột đang lưu gì | SELECT cmnd_ma LIMIT 5 — phải là chuỗi byte | | Ai đọc được keyset | quyền của bảng chứa keyset, hoặc IAM của khoá KMS | | Giải mã có đúng ngữ cảnh không | thử giải mã với associated data sai — phải thất bại |

Và một tính năng của AEAD đáng khai thác trong lĩnh vực y tế: crypto-shredding. Khi mỗi bệnh nhân có một khoá riêng, việc thực thi quyền được xoá dữ liệu trở nên đơn giản và chứng minh được — xoá khoá là dữ liệu của người đó vĩnh viễn không đọc lại được, kể cả trong các bản sao lưu đã tạo từ trước.

Đáp án

A — Đội thích cách tiếp cận VIẾT MÃ, tuỳ biến cao, hay cách tiếp cận TRỰC QUAN, ít mã, dựa trên trình kết nối dựng sẵn.

Vì sao đúng

Cả hai dịch vụ đều là ETL không máy chủ, xử lý được khối lượng lớn, ghi được vào nhiều đích. Điểm khác biệt quyết định là cách người ta xây pipeline.

⚠ Điểm mấu chốt — hai triết lý khác nhau:

DATAFLOW — code-first
        ↓
    Viết Apache Beam bằng Java/Python
        ↓
    → tuỳ biến gần như không giới hạn
    → quản lý phiên bản bằng Git
    → kiểm thử đơn vị được
    → đòi kỹ năng lập trình

CLOUD DATA FUSION — low-code
        ↓
    Kéo thả trong trình duyệt
        ↓
    → hơn 150 plugin dựng sẵn
    → nhìn thấy luồng bằng hình
    → nhà phân tích tự làm được
    → giới hạn ở những gì plugin hỗ trợ

⚠ Vì sao ba tiêu chí kia KHÔNG phân biệt được:

"Nguồn là lô hay luồng?"
    → CẢ HAI đều xử lý được cả hai
      (Dataflow mạnh hơn hẳn ở luồng,
       nhưng không phải tiêu chí ĐẦU TIÊN)

"Đích đến là gì?"
    → CẢ HAI ghi được vào BigQuery,
      Cloud SQL, GCS, và nhiều nơi khác

"Khối lượng dữ liệu?"
    → CẢ HAI mở rộng được
      (Data Fusion chạy trên Dataproc)

⚠ Bảng quyết định thực dụng:

Đội có kỹ sư Java/Python?
    CÓ    → cân nhắc Dataflow
    KHÔNG → Data Fusion

Cần luồng độ trễ rất thấp?
    CÓ    → Dataflow

Ưu tiên tốc độ triển khai và
nhiều nguồn khác nhau?
    CÓ    → Data Fusion

Ưu tiên hiệu năng và chi phí thấp nhất?
    CÓ    → Dataflow (không có chi phí nền)

Xem thêm câu #13021 (lô 135): khoá Data Fusion vì đội không lập trình. #13030 (lô 135): khoá Dataflow vì ưu tiên hiệu năng. #13020 (lô 135): chấp nhận cả hai vì đề không nêu tiêu chí phân biệt. Bốn câu, một khung quyết định duy nhất — hoàn toàn nhất quán.

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

• B (nguồn là lô hay luồng) — đây là phương án gần nhất và có ảnh hưởng thật (Dataflow mạnh hơn hẳn với luồng), nhưng cả hai đều xử lý được cả hai kiểu, nên đây không phải yếu tố quyết định đầu tiên.

• C (đích đến của dữ liệu) — cả hai ghi được vào hầu hết các đích phổ biến.

• D (khối lượng dữ liệu) — cả hai đều mở rộng được; Data Fusion chạy pipeline trên Dataproc.

Ghi nhớ

⚠ Dataflow ↔ Cloud Data Fusion — bảng phải thuộc: | | Dataflow | Cloud Data Fusion | |---|---|---| | Cách xây | viết mã (Apache Beam) | kéo thả | | Ngôn ngữ | Java, Python, Go | không cần | | Chi phí nền | KHÔNG có | instance thường trực | | Luồng độ trễ thấp | rất mạnh | hạn chế | | Trình kết nối dựng sẵn | ít hơn | hơn 150 plugin | | Quản lý phiên bản | Git, kiểm thử đơn vị | export/import pipeline | | Người dùng | kỹ sư | nhà phân tích |

Từ khoá nhận diện:

"code-first hay low-code" → tiêu chí phân biệt CHÍNH "đội không lập trình" → Data Fusion "hiệu năng, ít tài nguyên" → Dataflow "luồng thời gian thực phức tạp" → Dataflow "nhiều nguồn lạ, cần plugin sẵn" → Data Fusion

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí thực tế của hai phương án | Pricing Calculator với khối lượng thật | | Nguồn có plugin sẵn không | Data Fusion Hub | | Đội có viết được Beam không | thử một pipeline mẫu |

Và một câu hỏi thường quyết định lựa chọn tốt hơn cả các tiêu chí kỹ thuật: ai sẽ bảo trì pipeline này sau sáu tháng nữa? Một pipeline Beam viết đẹp nhưng cả đội chỉ một người đọc được là rủi ro lớn hơn nhiều so với chi phí nền của Data Fusion — và ngược lại, một luồng kéo thả phức tạp tới mức không ai hiểu cũng chẳng dễ bảo trì hơn.

Đáp án

A — Đặt PARTITION EXPIRATION 48 tháng cho bảng.

Vì sao đúng

Bảng đã được phân vùng theo ngày sự kiện, và BigQuery có sẵn cơ chế tự động xoá phân vùng khi quá tuổi — đúng thứ đề cần: tự động, hiệu quả, ngay trong BigQuery.

⚠ Điểm mấu chốt — một dòng cấu hình, chạy mãi:

ALTER TABLE `du_an.hoat_dong_nguoi_dung`
SET OPTIONS (
  partition_expiration_days = 1461  -- 48 tháng
);

        ↓
    BigQuery TỰ XOÁ mọi phân vùng
    quá 1461 ngày
        ↓
    ⚠ Không có job nào phải chạy
    ⚠ Không có mã nào phải bảo trì
    ⚠ Không có gì để quên
        ↓
    Khai khi tạo bảng:
      PARTITION BY DATE(event_date)
      OPTIONS(partition_expiration_days = 1461)

⚠ Vì sao xoá theo PHÂN VÙNG lại hiệu quả hơn DELETE:

DELETE FROM ... WHERE ngay < ...
        ↓
    → là một thao tác DML
    → phải QUÉT dữ liệu để tìm dòng cần xoá
    → TỐN TIỀN theo byte quét
    → chậm với bảng lớn

XOÁ PHÂN VÙNG
        ↓
    → chỉ bỏ đi cả một khối siêu dữ liệu
    → gần như tức thì
    → MIỄN PHÍ

⚠ Vài điều cần biết về partition expiration:

- Tính theo NGÀY của phân vùng,
  không phải theo thời điểm ghi
- Xoá là VĨNH VIỄN
  (còn khôi phục được trong cửa sổ
   time travel — mặc định 7 ngày)
- Áp cho TOÀN BỘ bảng, không đặt
  riêng cho từng phân vùng
- Khác với TABLE expiration
  (xoá cả bảng)

Xem thêm câu #13011 (lô 135): cũng về vòng đời dữ liệu, nhưng ở đó yêu cầu là GIỮ 7 năm để tuân thủ → khoá là xuất sang Cloud Storage Archive. Câu này yêu cầu XOÁ VĨNH VIỄN sau 48 tháng → partition expiration. Hai khoá khác nhau vì mục tiêu ngược nhau — hoàn toàn nhất quán.

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

• B (xuất sang Cloud Storage rồi xoá phân vùng) — đây là phương án gần nhất và cũng dọn được BigQuery, nhưng đề nói "XOÁ VĨNH VIỄN khỏi hệ thống"; xuất ra Cloud Storage là giữ lại một bản sao — vi phạm chính sách.

• D (chạy DELETE thủ công mỗi ngày) — thủ công, tốn kém, và dễ quên; đúng thứ mà "tự động, hiệu quả" muốn tránh.

• C (dựa vào long-term storage) — chỉ giảm CHI PHÍ LƯU TRỮ, không xoá gì cả.

Ghi nhớ

⚠ Vòng đời dữ liệu trong BigQuery — bảng phải thuộc: | Cơ chế | Việc | |---|---| | partition_expiration_days | tự XOÁ phân vùng quá tuổi | | expiration_timestamp của bảng | xoá cả BẢNG vào thời điểm định trước | | default_partition_expiration_days của dataset | áp cho bảng mới trong dataset | | Long-term storage | tự giảm ~50% GIÁ, không xoá | | bq extract + xoá | giữ bản sao ở GCS | | Time travel | khôi phục trong 7 ngày (cấu hình được) |

Từ khoá nhận diện:

"xoá vĩnh viễn sau N tháng" → partition expiration "giữ N năm để tuân thủ" → xuất sang GCS Archive + retention policy "giảm chi phí dữ liệu cũ" → long-term storage (tự động) "xoá cả bảng vào ngày X" → table expiration "DELETE thủ công" → luôn là phương án kém nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách đã đặt chưa | bq show --format=prettyjson <bảng> → partitionExpirationMs | | Dữ liệu cũ nhất còn lại | SELECT MIN(event_date) FROM ... | | Có bảng phái sinh giữ dữ liệu cũ không | rà soát các bảng tổng hợp |

Và một chỗ rất hay bị bỏ sót khi thực thi chính sách xoá dữ liệu: các bảng phái sinh. Bảng gốc được dọn đúng hạn, nhưng những bảng tổng hợp, bảng staging và bản sao tạo ra từ nó vẫn giữ nguyên dữ liệu cũ — nên hãy lập bản đồ toàn bộ đường đi của dữ liệu trước khi tuyên bố chính sách đã được thực thi.

Đáp án

A — Dùng Database Migration Service nhân bản CSDL sang Cloud SQL, rồi dùng BigQuery Data Transfer Service nạp dữ liệu từ Cloud SQL vào BigQuery.

Vì sao đúng

Đề nêu hai yêu cầu cốt lõi: bảo vệ CSDL tại chỗ khỏi áp lực của truy vấn phân tích, và dùng dịch vụ được quản lý, hiệu quả cho việc nạp gia tăng hằng ngày. Mẫu hai chặng đáp ứng cả hai.

⚠ Điểm mấu chốt — vì sao phải tách làm hai chặng:

CHẶNG 1 — DMS
    CSDL tại chỗ → Cloud SQL
        ↓
    Đọc NHẬT KÝ GIAO DỊCH (CDC)
        ↓
    ⚠ Tải lên nguồn rất NHẸ
    → khác hẳn việc quét bảng bằng truy vấn

CHẶNG 2 — BQDTS
    Cloud SQL → BigQuery
        ↓
    Nạp gia tăng theo LỊCH hằng ngày
        ↓
    ⚠ Mọi truy vấn phân tích chạy TỪ ĐÂY
    → CSDL sản xuất KHÔNG bị chạm tới

⚠ Vì sao ETL trực tiếp lại là vấn đề:

Dataflow đọc THẲNG CSDL tại chỗ
        ↓
    → truy vấn quét bảng lớn mỗi ngày
    → dùng CPU và I/O của máy chủ sản xuất
    → tranh chấp khoá với ứng dụng
        ↓
    ⚠ Ứng dụng khách hàng chậm đi
    ⚠ Đội quản trị CSDL phản đối — và họ đúng

⚠ Lợi ích kèm theo của chặng Cloud SQL:

- Có một BẢN SAO VẬN HÀNH trên đám mây
  → dùng cho môi trường thử, dự phòng
- Là bước trong lộ trình di chuyển lên đám mây
- Tách quyền: đội phân tích không cần
  quyền trên CSDL sản xuất
- Cloud SQL nằm TRONG Google Cloud
  → các dịch vụ khác kết nối dễ hơn nhiều

Xem thêm câu #13019 (lô 135): hỏi vai trò của DMS trong chính mẫu này. Và #13027 (lô 135): hỏi lợi ích lớn nhất của mẫu — bảo vệ CSDL sản xuất. Ba câu mô tả cùng một mẫu từ ba góc — hoàn toàn nhất quán.

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

• C (Dataflow nối thẳng tới CSDL tại chỗ) — đây là phương án gần nhất và hoàn toàn chạy được, nhưng nó đọc trực tiếp CSDL sản xuất — đúng thứ đề muốn tránh.

• B (Cloud Data Fusion nối thẳng tới CSDL tại chỗ) — cũng truy vấn thẳng hệ thống sản xuất, cùng vấn đề.

• D (sao lưu hằng ngày sang GCS rồi dùng Dataproc nạp) — cồng kềnh, độ trễ cao, phải tự dựng nhiều bước, và việc tạo bản sao lưu đầy đủ mỗi ngày cũng tạo tải lên nguồn.

Ghi nhớ

⚠ Mẫu "nhân bản rồi nạp" — bảng phải thuộc: | Chặng | Dịch vụ | Việc | |---|---|---| | On-prem → Cloud SQL | Database Migration Service | CDC, tải nhẹ lên nguồn | | Cloud SQL → BigQuery | BQDTS, Datastream, hoặc federated query | nạp gia tăng | | Biến đổi trong kho | Dataform, SQL | mô hình ELT | | Báo cáo | Looker Studio | | | Lợi ích chính | CSDL sản xuất không bị ảnh hưởng |

Từ khoá nhận diện:

"bảo vệ CSDL sản xuất khỏi truy vấn phân tích" → nhân bản rồi nạp "đọc nhật ký giao dịch" → CDC — tải nhẹ "CDC thẳng vào BigQuery" → Datastream — biến thể gọn hơn "biến đổi phức tạp trên đường" → Dataflow / Data Fusion "truy vấn thẳng CSDL sản xuất" → luôn đáng nghi trong câu hỏi thi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bản sao có bám kịp không | DMS console → replication delay | | BigQuery có dữ liệu mới không | SELECT MAX(<cột thời gian>) | | Nguồn có bị ảnh hưởng không | theo dõi CPU và I/O trên máy chủ nguồn |

Và một lợi ích thường quyết định lựa chọn này trong thực tế, ngoài lý do kỹ thuật: đội quản trị CSDL đồng ý. Một pipeline đọc thẳng vào hệ thống sản xuất luôn kéo theo tranh cãi kéo dài, còn nhân bản qua nhật ký giao dịch là cơ chế họ đã quen và tin tưởng — điều đó thường rút ngắn dự án hơn bất kỳ tối ưu kỹ thuật nào.