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

Đáp án

B — Trong một REGION, ví dụ australia-southeast1 (Sydney).

Vì sao đúng

Người dùng chỉ ở Úc, và mục tiêu là độ trễ thấp nhất. Đặt dữ liệu ngay tại Region gần người dùng là cách trực tiếp nhất để đạt điều đó.

⚠ Điểm mấu chốt — độ trễ do KHOẢNG CÁCH VẬT LÝ quyết định:

Người dùng ở Sydney
        ↓
    Bucket ở australia-southeast1 (Sydney)
        ↓
    → vài mili giây

    Bucket ở multi-region US
        ↓
    → gói tin đi vòng nửa vòng Trái Đất
    → hàng TRĂM mili giây mỗi lượt
        ↓
    ⚠ Ứng dụng chia sẻ ảnh: tải lên và
      tải xuống liên tục → khác biệt rất rõ

⚠ Ba kiểu vị trí bucket — chọn theo NGƯỜI DÙNG Ở ĐÂU:

REGION (australia-southeast1)
    → người dùng TẬP TRUNG một nơi
    → độ trễ thấp nhất, GIÁ RẺ NHẤT   ← đề này

DUAL-REGION (asia1, us1...)
    → hai Region cụ thể
    → sẵn sàng cao + độ trễ thấp ở cả hai

MULTI-REGION (US, EU, ASIA)
    → người dùng PHÂN TÁN trên cả châu lục
    → sẵn sàng cao nhất, ĐẮT NHẤT

⚠ Và một điều quan trọng — không đổi được về sau:

⚠ VỊ TRÍ của bucket là CỐ ĐỊNH
        ↓
    Muốn đổi → tạo bucket mới +
    sao chép toàn bộ dữ liệu +
    trả phí truyền dữ liệu
        ↓
    → phải quyết định đúng NGAY LẦN ĐẦU

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

• A (dual-region) — đây là phương án gần nhất về mặt hiệu năng và cho sẵn sàng cao hơn, nhưng đắt hơn và đề chỉ yêu cầu độ trễ thấp nhất cho người dùng ở một nước. Không có yêu cầu chịu lỗi cả Region.

• C (multi-region châu Á) — ASIA không bao gồm Úc; dữ liệu sẽ nằm ở các Region châu Á, xa hơn hẳn.

• D (multi-region US) — xa nhất có thể, độ trễ cao nhất.

Ghi nhớ

⚠ Ba kiểu vị trí bucket — bảng phải thuộc: | Kiểu | Độ trễ | Sẵn sàng | Giá | |---|---|---|---| | Region | thấp nhất tại chỗ | 99,0% SLA (Standard) | rẻ nhất | | Dual-region | thấp ở cả hai | cao hơn | trung bình | | Multi-region | tốt cho người dùng phân tán | cao nhất | đắt nhất | | Điểm chung | cùng độ bền 11 số 9 | | Bẫy | vị trí KHÔNG ĐỔI ĐƯỢC sau khi tạo |

Từ khoá nhận diện:

"người dùng ở một nước, độ trễ thấp nhất" → region "người dùng khắp châu Âu" → multi-region EU "cần chịu lỗi cả một Region" → dual-region hoặc multi-region "dữ liệu phải ở trong lãnh thổ" → region cụ thể + Organization Policy "phục vụ toàn cầu nhanh" → Cloud CDN trước bucket

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket đang ở đâu | gcloud storage buckets describe gs://b --format="value(location)" | | Độ trễ thực tế | đo từ máy khách ở Úc | | Có chính sách giới hạn vùng không | Organization Policy gcp.resourceLocations |

Và một quyết định nên chốt cùng lúc với vị trí bucket: có đặt Cloud CDN phía trước hay không. Với ứng dụng chia sẻ ảnh, phần lớn lưu lượng là đọc lại cùng những tấm ảnh — CDN vừa giảm độ trễ cho người dùng ở xa, vừa cắt đáng kể chi phí truyền dữ liệu ra khỏi bucket.

Đáp án

B — Vertex AI Notebooks (ví dụ Colab Enterprise).

Vì sao đúng

Đề nêu ba điều: khám phá dữ liệu tuỳ hứng, vẽ biểu đồ, và quen viết Python với pandas, seaborn, scikit-learn. Đó là mô tả chính xác của một môi trường notebook được quản lý.

⚠ Điểm mấu chốt — notebook là nơi làm việc của nhà khoa học dữ liệu:

Vertex AI Notebooks
        ↓
    Jupyter được quản lý, chạy trên GCP
        ↓
    - pandas, numpy, scikit-learn,
      seaborn, matplotlib CÀI SẴN
    - GPU/TPU bật được khi cần
    - kết nối BigQuery bằng một dòng
    - chạy dưới service account,
      không cần khoá JSON

⚠ Đọc BigQuery vào pandas ngay trong notebook:

from google.cloud import bigquery
client = bigquery.Client()
df = client.query('''
    SELECT * FROM `du_an.bang` LIMIT 100000
''').to_dataframe()

import seaborn as sns
sns.histplot(df['gia_tri'])

        ↓
    Hoặc dùng magic ngay trong ô lệnh:
      %%bigquery df
      SELECT ...

⚠ Hai lựa chọn trong Vertex AI:

COLAB ENTERPRISE
    → khởi động nhanh, ít phải quản lý
    → hợp với khám phá tuỳ hứng

VERTEX AI WORKBENCH
    → instance cấu hình được sâu hơn
    → cài thư viện hệ thống, gắn đĩa lớn
    → hợp với công việc dài hạn

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

• D (BigQuery UI) — đây là phương án gần nhất vì cũng khám phá dữ liệu được và có biểu đồ cơ bản, nhưng nó là môi trường SQL, không chạy được pandas, seaborn hay scikit-learn.

• A (Looker Studio) — công cụ trực quan hoá và báo cáo, không phải môi trường lập trình.

• C (Cloud Shell Editor) — trình soạn thảo mã trong trình duyệt, không phải notebook tương tác và không có sẵn hạ tầng phân tích.

Ghi nhớ

⚠ Chọn công cụ theo cách làm việc — bảng phải thuộc: | Người dùng | Công cụ | |---|---| | Nhà khoa học dữ liệu, Python | Vertex AI Notebooks | | Nhà phân tích, SQL | BigQuery UI | | Người dùng nghiệp vụ, xem báo cáo | Looker Studio, Looker | | Kỹ sư, viết mã và triển khai | Cloud Shell Editor, IDE | | Đội ETL không lập trình | Cloud Data Fusion |

Từ khoá nhận diện:

"pandas, scikit-learn, notebook" → Vertex AI Notebooks "khám phá tuỳ hứng bằng SQL" → BigQuery UI "dashboard cho lãnh đạo" → Looker Studio "mô hình ngữ nghĩa dùng chung, LookML" → Looker "huấn luyện mô hình bằng SQL" → BigQuery ML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Notebook chạy dưới danh nghĩa ai | !gcloud auth list trong một ô lệnh | | Máy còn bao nhiêu bộ nhớ | !free -h, hoặc df.memory_usage(deep=True).sum() | | Truy vấn tốn bao nhiêu | thông tin job trong BigQuery → Job history |

Và một cài đặt nên bật ngay khi tạo notebook: tự động tắt khi rảnh. Một instance có GPU để quên qua cuối tuần tốn hơn cả tháng lưu trữ dữ liệu mà nó đang phân tích — và đây là khoản lãng phí phổ biến nhất của các đội khoa học dữ liệu mới lên đám mây.

Đáp án

B — Nearline.

Vì sao đúng

Đề mô tả rất chính xác: dữ liệu cũ được truy cập vài lần MỖI THÁNG, cần giảm chi phí lưu, và không chấp nhận độ trễ truy xuất lâu. Nearline khớp đúng tần suất đó.

⚠ Điểm mấu chốt — Nearline được thiết kế cho đúng tần suất này:

Nearline
        ↓
    Khuyến nghị: truy cập khoảng
    MỘT LẦN MỖI THÁNG
        ↓
    Đề nói "vài lần mỗi tháng"
    → nằm quanh ngưỡng này
        ↓
    Rẻ hơn Standard rõ rệt
    Phí truy xuất còn thấp
    Tối thiểu 30 ngày — dữ liệu CŨ nên đã qua

⚠ Vì sao Coldline lại là bẫy ở đây:

Coldline
        ↓
    Khuyến nghị: khoảng MỘT LẦN MỖI QUÝ
        ↓
    Với "vài lần mỗi tháng":
      - giá lưu rẻ hơn Nearline một chút
      - nhưng PHÍ TRUY XUẤT cao hơn nhiều
        ↓
    ⚠ Đọc thường xuyên hơn khuyến nghị
      → tổng chi phí có thể CAO HƠN

⚠ Và một hiểu lầm cần dẹp bỏ:

"Lớp lạnh thì đọc chậm"
        ↓
    ⚠ SAI với Google Cloud Storage
        ↓
    Cả bốn lớp đều truy cập ở
    ĐỘ TRỄ MILI GIÂY
        ↓
    → yêu cầu "không chờ lâu" trong đề
      KHÔNG loại được lớp nào
    → thứ quyết định là CHI PHÍ theo tần suất

Xem thêm câu #12918 (cùng lô): dữ liệu đọc liên tục → khoá Standard. Và #12588 (cùng lô): chuyển sang Coldline cho dữ liệu lạnh hơn. Ba câu, ba khoá, cùng một quy tắc: chọn theo TẦN SUẤT TRUY CẬP.

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

• A (Coldline) — đây là phương án gần nhất và cũng hợp lý về mặt "rẻ hơn", nhưng nó dành cho khoảng một lần mỗi quý. Với "vài lần mỗi tháng", phí truy xuất cao hơn có thể ăn hết phần tiết kiệm.

• C (Archive) — cho dữ liệu dưới một lần mỗi năm, phí truy xuất cao nhất, tối thiểu 365 ngày.

• D (Multi-Regional) — đây là kiểu VỊ TRÍ (nay gọi là multi-region), không phải lớp lưu trữ theo cách phân loại hiện tại.

Ghi nhớ

⚠ Chọn lớp theo tần suất — bảng phải thuộc: | Tần suất truy cập | Lớp | Tối thiểu | |---|---|---| | Liên tục, hằng ngày | Standard | không có | | ~1 lần/tháng | Nearline | 30 ngày | | ~1 lần/quý | Coldline | 90 ngày | | <1 lần/năm | Archive | 365 ngày | | Không đoán được | Autoclass | — |

Từ khoá nhận diện:

"vài lần mỗi tháng" → Nearline "vài lần mỗi quý" → Coldline "gần như không bao giờ đọc" → Archive "đọc liên tục" → Standard "multi-regional / regional" → VỊ TRÍ, không phải lớp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đối tượng đang ở lớp nào | gsutil stat gs://b/obj → Storage class | | Bucket có lifecycle rule gì | gcloud storage buckets describe gs://b --format="value(lifecycle)" | | Chi phí chia theo lớp | billing export, nhóm theo SKU |

Và một cách làm thực dụng khi phân vân giữa Nearline và Coldline: lấy số lần đọc thật trong ba tháng gần nhất từ Monitoring rồi tính hai kịch bản. Con số đó thường cho câu trả lời rõ ràng hơn mọi suy đoán — và nếu nó dao động mạnh giữa các tháng, đó chính là lúc Autoclass đáng giá hơn cả hai.

Đáp án

B — BigQuery Data Transfer Service.

Vì sao đúng

Đề nêu bốn điều: nguồn là Google Ads, đích là BigQuery, nạp tự động mỗi ngày, không viết mã. Data Transfer Service sinh ra đúng cho việc này.

⚠ Điểm mấu chốt — trình kết nối dựng sẵn cho Google Ads:

BigQuery Data Transfer Service
        ↓
    Chọn nguồn: Google Ads
    Nhập ID tài khoản, cấp quyền
    Đặt lịch: hằng ngày
    Chọn dataset đích
        ↓
    → BigQuery tự tạo bảng theo lược đồ
      chuẩn của Google Ads
    → tự nạp mỗi ngày
        ↓
    ⚠ KHÔNG viết một dòng mã nào

⚠ Các nguồn được hỗ trợ sẵn:

Của Google:
    Google Ads, Campaign Manager,
    Google Ad Manager, YouTube,
    Search Ads 360, Display & Video 360,
    Google Play, Cloud Storage

Ngoài Google:
    Amazon S3, Amazon Redshift,
    Teradata, Azure Blob Storage

⚠ Vì sao "dựng sẵn" lại quan trọng hơn vẻ ngoài:

Tự viết pipeline lấy dữ liệu Google Ads
        ↓
    Phải lo: xác thực OAuth, phân trang,
    giới hạn tần suất, LƯỢC ĐỒ THAY ĐỔI,
    dữ liệu bị điều chỉnh hồi tố
        ↓
    ⚠ Google Ads điều chỉnh số liệu
      của những ngày TRƯỚC ĐÓ
        ↓
    DTS xử lý sẵn: tự nạp lại cửa sổ
    (refresh window) vài ngày gần nhất

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 không cần lập trình, nhưng bạn vẫn phải tự dựng pipeline, tự xử lý xác thực và lược đồ, và trả phí instance thường trực. Nhiều công hơn hẳn cho một nguồn đã có sẵn trình kết nối.

• A (Database Migration Service) — dành cho chuyển CSDL (MySQL, PostgreSQL, Oracle) sang Cloud SQL/AlloyDB. Không liên quan Google Ads.

• D (Storage Transfer Service) — chuyển tệp giữa các kho đối tượng (S3, Azure, Cloud Storage), không nạp vào BigQuery.

Ghi nhớ

⚠ Bốn dịch vụ "transfer/migration" hay lẫn nhau — bảng phải thuộc: | Dịch vụ | Chuyển gì, tới đâu | |---|---| | BigQuery Data Transfer Service | nguồn SaaS và kho → BigQuery | | Storage Transfer Service | S3, Azure, HTTP, on-prem → Cloud Storage | | Database Migration Service | CSDL → Cloud SQL / AlloyDB | | Datastream | CDC từ CSDL → BigQuery, Cloud Storage | | Transfer Appliance | thiết bị vật lý cho dữ liệu rất lớn |

Từ khoá nhận diện:

"Google Ads / YouTube → BigQuery theo lịch" → Data Transfer Service "S3 → Cloud Storage" → Storage Transfer Service "MySQL tại chỗ → Cloud SQL" → Database Migration Service "đồng bộ thay đổi CSDL gần thời gian thực" → Datastream "hàng trăm TB, đường truyền chậm" → Transfer Appliance

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Transfer chạy có thành công không | BigQuery → Data transfers → Run history | | Dữ liệu mới nhất tới đâu | SELECT MAX(<cột ngày>) trên bảng đích | | Chạy dưới danh nghĩa ai | xem cấu hình transfer |

Và một chi tiết dễ gây tranh cãi khi so số liệu với giao diện Google Ads: múi giờ của tài khoản quảng cáo. Bảng trong BigQuery ghi ngày theo múi giờ mà tài khoản Ads cấu hình, nên báo cáo dựng theo giờ Việt Nam có thể lệch một ngày ở phần biên — kiểm tra điều này trước khi đi tìm lỗi trong truy vấn.

Đáp án

C — ORDER BY last_name ASC

Vì sao đúng

Yêu cầu là sắp xếp theo họ, từ A tới Z. ORDER BY là mệnh đề sắp xếp, và ASC là thứ tự tăng dần — với chuỗi nghĩa là A → Z.

⚠ Điểm mấu chốt — mỗi mệnh đề một việc:

WHERE     → LỌC dòng
GROUP BY  → GOM nhóm để tính tổng hợp
ORDER BY  → SẮP XẾP kết quả       ← đề này
LIMIT     → cắt bớt số dòng trả về
        ↓
    Chỉ ORDER BY mới đổi được THỨ TỰ

⚠ ASC là mặc định — nhưng vẫn nên viết ra:

ORDER BY last_name       -- tăng dần (mặc định)
ORDER BY last_name ASC   -- tăng dần, viết rõ
ORDER BY last_name DESC  -- giảm dần, Z → A

        ↓
    Viết ASC tường minh giúp người đọc
    không phải nhớ mặc định là gì

⚠ Thứ tự thực thi logic của SQL — vì sao ORDER BY ở gần cuối:

FROM  →  WHERE  →  GROUP BY  →  HAVING
      →  SELECT  →  ORDER BY  →  LIMIT
        ↓
    ⚠ ORDER BY chạy SAU SELECT
    → dùng được BÍ DANH đặt trong SELECT
    → còn WHERE thì KHÔNG

⚠ Vài chi tiết về sắp xếp chuỗi trong BigQuery:

NULL đứng ở đâu?
    ASC  → NULL đứng TRƯỚC
    DESC → NULL đứng SAU
    Đổi bằng: ORDER BY x ASC NULLS LAST

Chữ hoa và chữ thường:
    So sánh theo mã ký tự → 'Zebra' < 'anh'
    Muốn bỏ qua hoa/thường:
      ORDER BY LOWER(last_name)

Tiếng Việt có dấu:
    Cân nhắc COLLATE hoặc chuẩn hoá trước

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

• D (ORDER BY last_name DESC) — đây là phương án gần nhất và đúng mệnh đề, nhưng DESC sắp giảm dần: Z → A, ngược yêu cầu.

• A (WHERE last_name IS NOT NULL) — LỌC bỏ dòng thiếu họ, không sắp xếp gì cả.

• B (GROUP BY last_name) — GOM nhóm để tính tổng hợp; nó có thể làm kết quả trông như đã sắp xếp trong vài trường hợp, nhưng không bảo đảm thứ tự nào.

Ghi nhớ

⚠ Các mệnh đề SQL và việc của chúng — bảng phải thuộc: | Mệnh đề | Việc | |---|---| | SELECT | chọn cột | | FROM / JOIN | nguồn dữ liệu | | WHERE | lọc DÒNG trước khi gom nhóm | | GROUP BY | gom nhóm | | HAVING | lọc SAU khi gom nhóm | | ORDER BY | SẮP XẾP | | LIMIT | cắt số dòng trả về |

Từ khoá nhận diện:

"sắp xếp A → Z" → ORDER BY <cột> ASC "sắp xếp Z → A" → ORDER BY <cột> DESC "chỉ lấy dòng thoả điều kiện" → WHERE "tính tổng theo từng nhóm" → GROUP BY "lọc theo giá trị đã tính tổng" → HAVING

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết quả có đúng thứ tự không | nhìn vài dòng đầu và cuối | | NULL nằm ở đâu | thêm NULLS LAST nếu cần | | Truy vấn có tốn quá nhiều không | --dry_run, và thông tin job |

Và một điều rất hay gây nhầm khi làm việc với dữ liệu tiếng Việt: sắp xếp mặc định so sánh theo mã ký tự, không theo thứ tự bảng chữ cái tiếng Việt. "Ánh" và "Anh" sẽ không nằm cạnh nhau như người đọc mong đợi — nếu báo cáo hướng tới người dùng Việt Nam, hãy cân nhắc chuẩn hoá hoặc dùng COLLATE phù hợp trước khi sắp xếp.

Đáp án

C — String function (hàm xử lý chuỗi).

Vì sao đúng

Việc cần làm là biến 'john' thành 'John' — thao tác trên giá trị chuỗi của từng dòng. Đó là định nghĩa của hàm chuỗi.

⚠ Điểm mấu chốt — hàm cụ thể là INITCAP:

SELECT INITCAP(first_name) AS ten_hien_thi
FROM `du_an.nhan_vien`;

        ↓
    'john'          → 'John'
    'mary jane'     → 'Mary Jane'
    'o'brien'       → "O'Brien"
        ↓
    INITCAP viết hoa chữ CÁI ĐẦU
    của MỖI TỪ

⚠ Bốn nhóm hàm trong câu hỏi — phân biệt bằng ĐẦU VÀO:

HÀM CHUỖI (string)
    → nhận CHUỖI, trả CHUỖI hoặc số
    → UPPER, LOWER, INITCAP, CONCAT,
      SUBSTR, TRIM, REPLACE, SPLIT     ← đề này

HÀM NGÀY THÁNG (date)
    → DATE_ADD, DATE_DIFF, FORMAT_DATE

HÀM TỔNG HỢP (aggregate)
    → GOM NHIỀU DÒNG thành MỘT
    → SUM, COUNT, AVG, MAX

HÀM CỬA SỔ (window)
    → tính trên MỘT TẬP DÒNG nhưng
      GIỮ NGUYÊN số dòng
    → ROW_NUMBER() OVER (...), LAG, LEAD

⚠ Nếu chỉ muốn viết hoa chữ cái ĐẦU TIÊN của cả chuỗi:

SELECT CONCAT(
  UPPER(SUBSTR(first_name, 1, 1)),
  LOWER(SUBSTR(first_name, 2))
) AS ten_hien_thi
FROM `du_an.nhan_vien`;

        ↓
    INITCAP viết hoa MỌI TỪ
    → 'nguyen van an' → 'Nguyen Van An'
    → thường là điều bạn muốn với TÊN NGƯỜI

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

• B (Window function) — đây là phương án dễ chọn nhầm vì cũng "biến đổi mà giữ nguyên số dòng", nhưng hàm cửa sổ tính toán dựa trên MỘT TẬP DÒNG liên quan (xếp hạng, cộng dồn, so với dòng trước). Việc viết hoa chỉ dùng giá trị của chính dòng đó.

• D (Aggregate function) — gom nhiều dòng thành một giá trị; ở đây mỗi dòng vẫn phải giữ nguyên.

• A (Date function) — làm việc với ngày giờ, không liên quan.

Ghi nhớ

⚠ Bốn nhóm hàm — bảng phải thuộc: | Nhóm | Đặc điểm | Ví dụ | |---|---|---| | Chuỗi (scalar) | một dòng vào, một dòng ra | INITCAP, UPPER, CONCAT | | Ngày tháng | làm việc với thời gian | DATE_ADD, FORMAT_DATE | | Tổng hợp | NHIỀU dòng → MỘT giá trị | SUM, COUNT, AVG | | Cửa sổ | nhiều dòng vào, GIỮ NGUYÊN số dòng | ROW_NUMBER() OVER, LAG |

Từ khoá nhận diện:

"viết hoa chữ cái đầu" → INITCAP — hàm chuỗi "tính tổng theo nhóm" → hàm tổng hợp "xếp hạng trong từng nhóm" → hàm cửa sổ "cộng thêm 7 ngày" → hàm ngày tháng "so với dòng trước đó" → LAG — hàm cửa sổ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàm cho kết quả đúng chưa | thử SELECT INITCAP('nguyen van an') | | Có khoảng trắng thừa không | SELECT LENGTH(x), LENGTH(TRIM(x)) | | Có giá trị lạ không | lọc bằng REGEXP_CONTAINS |

Và một nguyên tắc đáng giữ khi xử lý tên người: đừng ghi đè dữ liệu gốc bằng bản đã viết hoa. Quy tắc viết hoa khác nhau giữa các nền văn hoá và luôn có ngoại lệ; giữ nguyên giá trị nguồn rồi định dạng ở lớp báo cáo cho phép bạn sửa quy tắc bất cứ lúc nào mà không mất thông tin.

Đáp án

C — Data in transit và data at rest (dữ liệu khi truyền và dữ liệu khi lưu), đều được mã hoá mặc định.

Vì sao đúng

Đề hỏi hai tình huống: khi dữ liệu được GHI XUỐNG ĐĨA và khi dữ liệu được GỬI QUA MẠNG. Đó đúng là hai trạng thái có tên riêng trong bảo mật dữ liệu.

⚠ Điểm mấu chốt — ba trạng thái của dữ liệu:

DATA AT REST (khi lưu)
        ↓
    Nằm trên đĩa, trong BigQuery, GCS...
    → mã hoá AES-256, MẶC ĐỊNH, không tắt được

DATA IN TRANSIT (khi truyền)
        ↓
    Đi trên mạng, giữa người dùng và dịch vụ,
    hoặc giữa các trung tâm dữ liệu
    → mã hoá TLS, MẶC ĐỊNH

DATA IN USE (khi đang xử lý)
        ↓
    Đang nằm trong BỘ NHỚ, đang được tính toán
    → cần CONFIDENTIAL COMPUTING

⚠ Điểm quan trọng nhất — mã hoá là MẶC ĐỊNH, không phải tuỳ chọn:

Google Cloud mã hoá TỰ ĐỘNG:
    - mọi dữ liệu khi lưu
    - mọi dữ liệu khi truyền qua
      hạ tầng của Google
        ↓
    ⚠ Bạn KHÔNG phải bật gì
    ⚠ Cũng KHÔNG tắt được
        ↓
    Câu hỏi thật sự chỉ là:
    AI QUẢN LÝ KHOÁ

⚠ Ba mức quản lý khoá — dẫn sang câu tiếp theo:

GMEK — Google quản lý khoá
    → mặc định, không phải làm gì

CMEK — bạn quản lý khoá bằng Cloud KMS
    → tự đặt lịch xoay khoá, tự thu hồi

CSEK — bạn tự cung cấp khoá mỗi lần gọi
    → Google không lưu khoá
    → chỉ áp dụng cho một số dịch vụ

Xem thêm câu #12931 (cùng lô): hỏi về chiến lược khoá khi cần toàn quyền kiểm soát → đáp án là CMEK với Cloud KMS. Hai câu bổ sung nhau: câu này về tên gọi hai trạng thái, câu kia về ai giữ khoá.

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

• A (data at rest và data in use) — đây là phương án gần nhất và một nửa đúng, nhưng "data in use" là dữ liệu đang nằm trong bộ nhớ khi xử lý — không phải "gửi qua mạng". Trạng thái truyền là in transit.

• B (CMEK và CSEK) — đây là hai cách QUẢN LÝ KHOÁ, không phải tên của hai trạng thái dữ liệu.

• D (logical và physical security) — cách phân loại chung về an ninh, không phải hai khái niệm mà đề mô tả.

Ghi nhớ

⚠ Ba trạng thái dữ liệu — bảng phải thuộc: | Trạng thái | Ở đâu | Bảo vệ bằng | |---|---|---| | At rest | trên đĩa, trong kho | AES-256, mặc định | | In transit | trên mạng | TLS, mặc định | | In use | trong bộ nhớ khi xử lý | Confidential Computing | | Điểm chung | hai cái đầu MẶC ĐỊNH BẬT, không tắt được |

Từ khoá nhận diện:

"ghi xuống đĩa + gửi qua mạng" → at rest và in transit "mã hoá cả khi đang xử lý trong RAM" → Confidential VM / Confidential Computing "tôi muốn tự quản khoá" → CMEK + Cloud KMS "tôi tự cung cấp khoá, Google không lưu" → CSEK "mặc định" → GMEK

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dataset dùng khoá nào | bq show --format=prettyjson <dataset> → defaultEncryptionConfiguration | | Khoá KMS xoay khi nào | gcloud kms keys describe → rotationPeriod | | Ai truy cập được khoá | gcloud kms keys get-iam-policy |

Và một điều nên nói rõ khi giải thích cho người mới: mã hoá mặc định của Google Cloud không phải thứ bạn "bật lên cho an toàn hơn" — nó luôn ở đó. Việc thật sự cần quyết định là ai giữ khoá, và câu trả lời cho điều đó đến từ yêu cầu tuân thủ chứ không từ mức độ lo lắng.

Đáp án

A — Clustering (phân cụm).

Vì sao đúng

Câu quyết định nằm ở chỗ: "họ KHÔNG BIẾT TRƯỚC các nhóm là gì" và muốn khám phá ra các nhóm tự nhiên. Đó là định nghĩa của học không giám sát, mà phân cụm là đại diện.

⚠ Điểm mấu chốt — có nhãn hay không quyết định loại mô hình:

CÓ NHÃN sẵn (biết trước câu trả lời đúng)
        ↓
    HỌC CÓ GIÁM SÁT
    → Classification: nhãn là DANH MỤC
    → Regression: nhãn là SỐ

KHÔNG có nhãn (không biết nhóm là gì)
        ↓
    HỌC KHÔNG GIÁM SÁT
    → CLUSTERING: tự tìm nhóm     ← đề này
        ↓
    Đề nói rõ "không biết trước"
    → không có nhãn để học

⚠ Trong BigQuery ML là KMEANS:

CREATE OR REPLACE MODEL `du_an.phan_khuc_khach_hang`
OPTIONS(
  model_type = 'KMEANS',
  num_clusters = 5,
  standardize_features = TRUE
) AS
SELECT tong_chi_tieu, so_don_hang,
       ngay_ke_tu_lan_mua_cuoi
FROM `du_an.khach_hang`;

        ↓
    ⚠ KHÔNG có input_label_cols
    → vì không có nhãn nào cả

⚠ Hai lựa chọn phải chú ý:

num_clusters
    → không khai thì BQML tự chọn
    → nên thử nhiều giá trị rồi so
      DAVIES-BOULDIN INDEX (càng nhỏ càng tốt)

standardize_features = TRUE
    ⚠ RẤT QUAN TRỌNG
    → K-means dùng KHOẢNG CÁCH
    → cột "chi tiêu" đơn vị triệu đồng sẽ
      át hoàn toàn cột "số đơn hàng"
      nếu không chuẩn hoá

Xem thêm câu #12919 (cùng lô): cùng nói về BigQuery ML nhưng ở đó là dự đoán vỡ nợ → mô hình phân loại. Và #12929 (cùng lô) dự đoán hạn mức tín dụng → hồi quy. Ba câu cùng công cụ, khác bài toán, khác loại mô hình — nhất quán.

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

• B (Classification) — đây là phương án dễ nhầm nhất vì cũng "chia khách hàng thành nhóm", nhưng phân loại cần biết trước các nhãn và có dữ liệu đã gán nhãn để học. Đề nói rõ là không biết trước.

• D (Regression) — dự đoán một giá trị SỐ, không phải tìm nhóm.

• C (Time Series) — dự báo theo thời gian, không liên quan tới phân khúc khách hàng.

Ghi nhớ

⚠ Ba nhóm bài toán học máy — bảng phải thuộc: | Nhóm | Có nhãn? | Trả về | Mô hình BQML | |---|---|---|---| | Classification | CÓ — nhãn danh mục | lớp | LOGISTIC_REG, BOOSTED_TREE_CLASSIFIER | | Regression | CÓ — nhãn SỐ | giá trị số | LINEAR_REG, BOOSTED_TREE_REGRESSOR | | Clustering | KHÔNG | nhóm | KMEANS | | Time series | có, theo thời gian | dự báo tương lai | ARIMA_PLUS | | Gợi ý | tương tác người–vật | đề xuất | MATRIX_FACTORIZATION |

Từ khoá nhận diện:

"không biết trước các nhóm" → clustering / KMEANS "dự đoán có hay không, thuộc loại nào" → classification "dự đoán một con số" → regression "dự báo doanh thu tháng tới" → time series / ARIMA_PLUS "gợi ý sản phẩm" → matrix factorization

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cụm có tách bạch không | ML.EVALUATE → Davies-Bouldin | | Mỗi cụm khác nhau ra sao | ML.CENTROIDS | | Cụm có mất cân bằng không | SELECT CENTROID_ID, COUNT(*) ... GROUP BY 1 |

Và một bước rất hay bị bỏ qua sau khi phân cụm xong: đặt tên nghiệp vụ cho từng cụm. "Cụm 3" không nói gì với đội marketing, còn "khách chi tiêu cao nhưng ba tháng chưa quay lại" thì gợi ra ngay một chiến dịch cụ thể — và đó mới là lúc mô hình bắt đầu tạo ra giá trị.

Đáp án

A — CREATE MODEL với MODEL_TYPE='LINEAR_REG'

Vì sao đúng

Đề nói rõ mục tiêu dự đoán là hạn mức tín dụng chính xác — một giá trị SỐ LIÊN TỤC. Bài toán dự đoán số liên tục là hồi quy, và hồi quy tuyến tính là mô hình cơ bản cho việc đó.

⚠ Điểm mấu chốt — kiểu của nhãn quyết định loại mô hình:

Nhãn là SỐ LIÊN TỤC
    (hạn mức, giá nhà, doanh thu)
        ↓
    HỒI QUY → LINEAR_REG            ← đề này

Nhãn là DANH MỤC
    (vỡ nợ / không vỡ nợ)
        ↓
    PHÂN LOẠI → LOGISTIC_REG

Không có nhãn
        ↓
    PHÂN CỤM → KMEANS

⚠ Câu lệnh đầy đủ:

CREATE OR REPLACE MODEL `du_an.du_doan_han_muc`
OPTIONS(
  model_type = 'LINEAR_REG',
  input_label_cols = ['han_muc']
) AS
SELECT thu_nhap, tuoi, diem_tin_dung, han_muc
FROM `du_an.ho_so_the_tin_dung`;

⚠ Cái bẫy tên gọi phải nhớ:

LOGISTIC_REG có chữ "REGRESSION"
        ↓
    ⚠ NHƯNG nó là mô hình PHÂN LOẠI
        ↓
    Nó dự đoán XÁC SUẤT thuộc về một lớp
    → đầu ra nằm giữa 0 và 1
        ↓
    → tên gọi lịch sử, rất dễ chọn nhầm
      trong đề thi

⚠ Đánh giá mô hình hồi quy — chỉ số khác hẳn phân loại:

ML.EVALUATE trả về:
    mean_absolute_error       (MAE)
    mean_squared_error        (MSE)
    root_mean_squared_error   (RMSE)
    r2_score                  (R²)
        ↓
    ⚠ KHÔNG có accuracy, precision, recall
    → những cái đó là của PHÂN LOẠI

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

• B (LOGISTIC_REG) — đây là phương án bẫy chính vì tên có chữ "regression", nhưng nó là mô hình PHÂN LOẠI: dự đoán xác suất thuộc về một lớp, không dự đoán được một hạn mức cụ thể.

• C (ARIMA_PLUS) — dự báo CHUỖI THỜI GIAN; đề không có yếu tố thời gian.

• D (KMEANS) — phân cụm không giám sát, không dự đoán giá trị nào.

Ghi nhớ

⚠ Chọn model_type trong BQML — bảng phải thuộc: | Bài toán | model_type | |---|---| | Dự đoán SỐ liên tục | LINEAR_REG, BOOSTED_TREE_REGRESSOR, DNN_REGRESSOR | | Phân loại hai lớp hoặc nhiều lớp | LOGISTIC_REG, BOOSTED_TREE_CLASSIFIER | | Phân cụm | KMEANS | | Dự báo theo thời gian | ARIMA_PLUS | | Gợi ý | MATRIX_FACTORIZATION | | Phát hiện bất thường | AUTOENCODER, PCA | | Tự động chọn mô hình | AUTOML_REGRESSOR / AUTOML_CLASSIFIER |

Từ khoá nhận diện:

"dự đoán một con số cụ thể" → hồi quy, LINEAR_REG "dự đoán có/không, loại nào" → LOGISTIC_REG "LOGISTIC_REG là hồi quy" → SAI — nó là PHÂN LOẠI "dự báo doanh thu theo tháng" → ARIMA_PLUS "tìm nhóm chưa biết trước" → KMEANS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sai số bao nhiêu tiền | ML.EVALUATE → mean_absolute_error | | Đặc trưng nào quan trọng | ML.FEATURE_IMPORTANCE hoặc trọng số của mô hình tuyến tính | | Vì sao một hồ sơ được hạn mức đó | ML.EXPLAIN_PREDICT |

Và một lý do rất thực tế để bắt đầu bằng LINEAR_REG thay vì mô hình mạnh hơn trong lĩnh vực tín dụng: khả năng giải thích. Mô hình tuyến tính cho phép nói rõ "mỗi triệu đồng thu nhập tăng thêm ứng với chừng này hạn mức" — thứ mà cơ quan quản lý và khách hàng đều hiểu được, và là điều nhiều mô hình chính xác hơn không làm được một cách thuyết phục.

Đáp án

A — Trong giao diện giám sát job của Dataflow (Dataflow jobs monitoring interface).

Vì sao đúng

Đề cần hình ảnh trực quan của pipeline: dòng dữ liệu qua từng bước biến đổi, cùng các chỉ số như độ tươi dữ liệu (data freshness) và thông lượng ở mỗi giai đoạn. Đó chính là những gì giao diện Dataflow hiển thị sẵn.

⚠ Điểm mấu chốt — Dataflow có sẵn màn hình đồ thị job:

Console → Dataflow → chọn job
        ↓
    JOB GRAPH
        → sơ đồ các bước biến đổi
        → mỗi node hiện thông lượng,
          số phần tử, thời gian
        ↓
    JOB METRICS
        → Data freshness
        → System latency
        → Throughput theo bước
        → Số worker đang chạy
        ↓
    ⚠ KHÔNG phải tự dựng dashboard

⚠ Hai chỉ số quan trọng nhất của pipeline luồng:

DATA FRESHNESS
    → dữ liệu cũ nhất chưa xử lý xong
      đã chờ bao lâu
        ↓
    Tăng dần → pipeline KHÔNG THEO KỊP

SYSTEM LATENCY
    → một phần tử mất bao lâu
      để đi hết pipeline
        ↓
    Hai chỉ số này là thứ đầu tiên
    phải nhìn khi nghi ngờ tắc nghẽn

⚠ Bốn màn hình dùng cho bốn việc khác nhau:

Dataflow job graph   → CẤU TRÚC và dòng chảy   ← đề này
Dataflow job metrics → chỉ số của chính job
Cloud Logging        → LOG và STACK TRACE
Cloud Monitoring     → dashboard và CẢNH BÁO
                       tổng hợp nhiều dịch vụ

Xem thêm câu #12920 (cùng lô): ở đó câu hỏi là tìm thông báo lỗi và stack trace → đáp án là Cloud Logging. Câu này hỏi xem trực quan cấu trúc và chỉ số của job → giao diện Dataflow. Hai khoá khác nhau vì hỏi hai việc khác nhau, nhất quán với nhau.

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

• B (Cloud Monitoring, tự tạo dashboard) — đây là phương án gần nhất và hoàn toàn làm được, nhưng phải tự dựng dashboard, trong khi Dataflow đã có sẵn màn hình chuyên biệt kèm đồ thị job mà dashboard tự dựng không có.

• D (Cloud Logging, lọc theo tên job) — cho log dạng chữ, không phải biểu diễn đồ hoạ của pipeline.

• C (BigQuery UI, Job history) — chỉ hiện các job của BigQuery, không hiện pipeline Dataflow.

Ghi nhớ

⚠ Bốn nơi xem thông tin về một job Dataflow — bảng phải thuộc: | Nơi | Cho gì | |---|---| | Dataflow → Job graph | sơ đồ các bước, dòng dữ liệu | | Dataflow → Job metrics | freshness, latency, throughput, worker | | Cloud Logging | log, stack trace | | Cloud Monitoring | dashboard tổng hợp và CẢNH BÁO | | Error Reporting | gom nhóm lỗi lặp lại |

Từ khoá nhận diện:

"xem trực quan dòng dữ liệu qua từng bước" → giao diện Dataflow "stack trace, thông báo lỗi" → Cloud Logging "cảnh báo khi vượt ngưỡng" → Cloud Monitoring "job SQL đã chạy" → BigQuery job history "hàm nào ngốn CPU" → Cloud Profiler

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline có theo kịp không | Job metrics → Data freshness | | Bước nào là nút thắt | Job graph — xem throughput từng bước | | Có bản ghi hỏng không | dead-letter và log lỗi |

Và một cảnh báo đáng đặt ngay từ ngày đầu chạy pipeline luồng: data freshness vượt ngưỡng. Job vẫn ở trạng thái "Running" và không có lỗi nào trong log, nhưng dữ liệu tới bảng đích chậm dần hàng giờ — nếu chỉ theo dõi trạng thái job, bạn sẽ chỉ biết khi có người hỏi vì sao dashboard đứng yên.