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

Câu 201 Data Analysis and Presentation

A data analyst needs to explore BigQuery datasets using both SQL and Python in a browser-based Jupyter notebook without provisioning or managing any servers.

Which Google Cloud capability should they use?

A
BigQuery in-console notebooks (BigQuery Studio) to run SQL and Python against BigQuery without managing infrastructure.
B
Cloud Functions to execute queries and write results to Cloud Storage.
C
Vertex AI Workbench user-managed notebooks with a custom VM and manual package setup.
D
A Dataproc cluster with Jupyter Notebook installed on the master node.

Xem giải thích

Đáp án

A — Notebook tích hợp trong BigQuery (BigQuery Studio), chạy được cả SQL lẫn Python trên BigQuery mà không phải quản lý hạ tầng.

Vì sao đúng

Đề nêu bốn điều: khám phá dataset BigQuery, dùng CẢ SQL LẪN PYTHON, trong notebook Jupyter trên trình duyệt, và KHÔNG cấp phát hay quản lý máy chủ nào. BigQuery Studio đáp ứng cả bốn ngay trong giao diện BigQuery.

⚠ Điểm mấu chốt — notebook nằm ngay trong BigQuery:

BigQuery Studio
        ↓
    Mở notebook NGAY TRONG giao diện BigQuery
        ↓
    - ô SQL chạy thẳng trên BigQuery
    - ô Python với pandas, matplotlib
    - %%bigquery để lấy kết quả vào DataFrame
    - BigQuery DataFrames (bigframes)
        ↓
    ⚠ KHÔNG cấp phát VM
    ⚠ KHÔNG cài gói hệ thống
    ⚠ KHÔNG quản lý cụm

⚠ Vì sao hai phương án còn lại đòi quản lý hạ tầng:

VERTEX AI WORKBENCH user-managed
        ↓
    ⚠ "user-managed" nghĩa là BẠN quản lý
    → tạo VM, cài gói, vá lỗi, tắt máy
    → trái yêu cầu "không cấp phát,
      không quản lý"

DATAPROC + Jupyter trên node master
        ↓
    ⚠ Phải dựng và duy trì CẢ MỘT CỤM
    → nặng hơn nữa

⚠ BigQuery DataFrames — điểm rất đáng biết:

import bigframes.pandas as bpd

df = bpd.read_gbq("du_an.bang_lon")
df.groupby("khu_vuc")["doanh_so"].sum()
        ↓
    ⚠ Cú pháp GIỐNG pandas
    ⚠ Nhưng phép tính chạy Ở PHÍA BIGQUERY
        ↓
    → làm việc được với bảng hàng tỉ dòng
      mà không tràn bộ nhớ notebook

⚠ Xem thêm câu #13091 (cùng lô): khoá Colab Enterprise vì ở đó cần một TÀI LIỆU BÁO CÁO đầy đủ với Matplotlib, diễn giải dài, đóng gói và chạy lại. Câu này chỉ cần KHÁM PHÁ dataset BigQuery bằng SQL và Python, không quản hạ tầng → notebook tích hợp trong BigQuery Studio là câu trả lời trực tiếp nhất. Hai khoá khác nhau vì MỤC ĐÍCH khác nhau — không mâu thuẫn. Và #13029 (lô 135) khoá Colab Enterprise cho môi trường notebook được quản lý cho đội khoa học dữ liệu.

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

C (Vertex AI Workbench user-managed với VM tuỳ chỉnh và cài gói thủ công) — đây là phương án gần nhất vì cũng là notebook trên GCP, nhưng chữ "user-managed" và "cài gói thủ công" đi thẳng vào điều đề loại bỏ: phải cấp phát và quản lý hạ tầng.
D (cụm Dataproc với Jupyter trên node master) — phải dựng và duy trì cả một cụm; nặng hơn nhiều so với nhu cầu.
B (Cloud Functions chạy truy vấn rồi ghi ra Cloud Storage) — không phải notebook, không tương tác, không khám phá được.

Ghi nhớ

⚠ Các môi trường notebook trên Google Cloud — bảng phải thuộc: | Môi trường | Đặc điểm | |---|---| | BigQuery Studio notebook | ngay trong BigQuery, không quản hạ tầng | | Colab Enterprise | notebook được quản lý trong Vertex AI, cộng tác tốt | | Vertex AI Workbench (managed) | instance được quản lý, tuỳ biến hơn | | Vertex AI Workbench (user-managed) | BẠN quản lý VM | | Jupyter trên Dataproc | trong cụm Spark | | Tự cài trên Compute Engine | công vận hành cao nhất |

Từ khoá nhận diện:

"khám phá BigQuery bằng SQL và Python, không quản hạ tầng" → BigQuery Studio notebook "báo cáo đầy đủ có diễn giải, cộng tác" → Colab Enterprise "cần cài thư viện hệ thống, đĩa lớn" → Workbench "user-managed" → bạn phải quản lý — đọc kỹ chữ này "notebook trong cụm Spark" → Dataproc

BigQuery Studio — các tính năng	Tính năng
Notebook tích hợp	SQL và Python
Data canvas	khám phá trực quan bằng đồ thị
Truy vấn có hỗ trợ AI	gợi ý và giải thích SQL
Quản lý mã bằng Git	kết nối kho mã
`%%bigquery`	chạy SQL, trả DataFrame
BigQuery DataFrames	pandas API chạy trên BigQuery

Đọc dữ liệu lớn trong notebook	Cách
`to_dataframe()`	nạp vào RAM — cẩn thận với bảng lớn
`LIMIT`, `TABLESAMPLE`	lấy mẫu
Lọc theo cột phân vùng	giảm byte quét
`bigframes`	xử lý ở phía BigQuery
`--dry_run`	biết trước sẽ quét bao nhiêu
Chi phí	mỗi ô SQL là một truy vấn tính tiền

Chọn môi trường theo nhu cầu	Nhu cầu
Khám phá nhanh dữ liệu BigQuery	BigQuery Studio
Phân tích sâu, cộng tác, báo cáo	Colab Enterprise
Huấn luyện mô hình cần GPU	Vertex AI Workbench / Training
Xử lý bằng Spark	Dataproc
Nguyên tắc	chọn mức trừu tượng CAO NHẤT còn đủ dùng

"Managed" ↔ "user-managed" — đọc kỹ	Nội dung
Managed	Google lo hạ tầng
User-managed	BẠN lo VM, gói, vá lỗi
Trong đề thi	cụm từ này thường là dấu hiệu loại trừ
Chọn user-managed khi	thật sự cần tuỳ biến sâu
Còn lại	luôn ưu tiên bản được quản lý

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 | | Truy vấn tốn bao nhiêu | BigQuery → Job history | | Có tài nguyên nào đang chạy không | kiểm tra runtime trong Vertex AI |

Và một cụm từ rất đáng để ý trong các phương án của câu hỏi thi: "user-managed". Nó gần như luôn là dấu hiệu loại trừ khi đề nhấn mạnh "không cấp phát, không quản lý hạ tầng" — vì chính tên gọi đã nói rằng phần quản lý thuộc về bạn.

Câu 202 Data Analysis and Presentation

A business analyst has created a sales dashboard in Looker. They want to empower business users to dynamically filter the entire dashboard to see data for a specific sales region or product category.

What feature should the analyst add to the dashboard to enable this functionality?

A A custom visualization
B A scheduled delivery
C A new LookML view
D A dashboard filter

Xem giải thích

Đáp án

D — Thêm một DASHBOARD FILTER (bộ lọc dashboard).

Vì sao đúng

Yêu cầu là cho phép người dùng nghiệp vụ tự lọc TOÀN BỘ dashboard theo vùng hoặc danh mục sản phẩm. Dashboard filter là điều khiển được thiết kế cho đúng việc đó.

⚠ Điểm mấu chốt — một bộ lọc áp cho nhiều biểu đồ:

Thêm Dashboard Filter
        ↓
    Chọn trường: khu_vuc, danh_muc
        ↓
    Chọn các TILE mà bộ lọc áp vào
        ↓
    → người dùng chọn "Miền Bắc"
    → TẤT CẢ biểu đồ đã liên kết
      cùng lọc theo giá trị đó
        ↓
    ⚠ Không phải sửa từng biểu đồ
    ⚠ Không cần biết SQL hay LookML

⚠ Các kiểu điều khiển bộ lọc:

Dropdown (một hoặc nhiều giá trị)
Date range          → khoảng thời gian
Number range        → khoảng số
Text search         → tìm theo chuỗi
Tile-level filter   → chỉ áp cho một biểu đồ
        ↓
    ⚠ Cấu hình bằng giao diện, không viết mã

⚠ Vài tuỳ chọn nâng cao đáng biết:

- Giá trị mặc định khi mở dashboard
- Bắt buộc chọn (required filter)
  → tránh quét toàn bộ dữ liệu
- Liên kết bộ lọc với nhau
  (chọn vùng → danh sách tỉnh thu hẹp)
- Truyền giá trị qua URL
  → chia sẻ link đã lọc sẵn
        ↓
    ⚠ "Required filter" rất hữu ích
      với bảng lớn — giảm chi phí truy vấn

Xem thêm bộ ba Looker ở lô 136: #13070 (LookML), #13073 (Custom Field), #13079 (Table Calculation) — ba nơi TÍNH TOÁN. Câu này về điều khiển HIỂN THỊ, một tầng khác. Bốn câu bổ sung nhau. Và #13046/#13035 (lô 136): bộ lọc theo bảo mật dùng access_filter, khác hẳn dashboard filter.

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

B (scheduled delivery) — đây là phương án gần nhất trong các tính năng dashboard, nhưng nó gửi báo cáo TĨNH theo lịch, không cho người dùng lọc tương tác.
A (custom visualization) — thêm kiểu biểu đồ mới, không liên quan tới lọc.
C (tạo LookML view mới) — việc của developer, và không tạo ra điều khiển lọc cho người dùng cuối.

Ghi nhớ

⚠ Các tầng trong Looker — bảng phải thuộc: | Tầng | Thành phần | |---|---| | Mô hình | LookML: view, explore, model, measure | | Khám phá | Explore, Custom Field, Table Calculation | | Hiển thị | Look, dashboard, TILE, DASHBOARD FILTER | | Phân phối | scheduled delivery, alert, embed | | Bảo mật | folder permission, access_filter |

Từ khoá nhận diện:

"người dùng tự lọc toàn bộ dashboard" → dashboard filter "mỗi người chỉ thấy dữ liệu của mình" → access_filter + user attribute "gửi báo cáo tĩnh theo lịch" → scheduled delivery "tính % của tổng" → Table Calculation "chỉ số chính thức" → LookML measure

⚠ Dashboard filter ↔ `access_filter` — đừng lẫn	Nội dung
Dashboard filter	TIỆN LỢI — người dùng tự chọn, tự đổi
`access_filter`	BẢO MẬT — áp ở tầng mô hình, không gỡ được
Dashboard filter	người dùng thấy và sửa được
`access_filter`	người dùng không thấy, không sửa được
Sai lầm nghiêm trọng	dùng dashboard filter làm cơ chế bảo mật

Required filter — vì sao đáng dùng	Lý do
Bắt buộc chọn giá trị trước khi truy vấn
→ tránh quét TOÀN BỘ bảng lớn
→ giảm chi phí truy vấn đáng kể
Kết hợp với	bảng phân vùng theo ngày
Ví dụ	bắt buộc chọn khoảng ngày trước khi xem

Tối ưu dashboard cho hiệu năng	Cách
Bảng tổng hợp nhỏ	thay vì trỏ vào bảng giao dịch
Aggregate awareness trong LookML	Looker tự dùng bảng tổng hợp
Cache và datagroup	kiểm soát khi nào truy vấn lại
Required filter	tránh truy vấn toàn bảng
Giới hạn số tile mỗi dashboard	mỗi tile là một truy vấn

Chia sẻ dashboard đã lọc sẵn	Cách
Tham số bộ lọc nằm trong URL	sao chép link là đủ
Giá trị mặc định của bộ lọc	mở ra đã đúng ngữ cảnh
Bookmark trong trình duyệt
⚠ Lưu ý	URL không phải cơ chế bảo mật
Bảo mật thật	folder permission + `access_filter`

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bộ lọc có áp cho đúng tile không | kiểm tra phần liên kết trong cấu hình filter | | Truy vấn có nhẹ đi khi lọc không | xem SQL sinh ra và byte quét | | Người dùng có lọc được không | thử với tài khoản có quyền View |

Và một ranh giới rất quan trọng cần giữ rõ trong đầu: dashboard filter là tiện lợi, không phải bảo mật. Người dùng thấy nó, đổi được nó, và xoá được nó — nên nếu mục đích là giới hạn ai xem được dữ liệu nào, cơ chế đúng luôn là access_filter ở tầng mô hình, chứ không phải một bộ lọc trên giao diện.

Câu 203 Data Analysis and Presentation

A data science team is starting a new project to predict product demand. According to the standard machine learning project lifecycle, what is the most critical first step the team must take before any model development begins?

A Select a machine learning algorithm.
B Deploy the model to a production endpoint.
C Tune model hyperparameters.
D Define the business objective and success criteria.

Xem giải thích

Đáp án

D — Xác định MỤC TIÊU NGHIỆP VỤ và TIÊU CHÍ THÀNH CÔNG.

Vì sao đúng

Trong vòng đời một dự án học máy, bước đầu tiên và quan trọng nhất luôn là hiểu rõ bài toán nghiệp vụ và cách đo thành công — trước khi chạm vào dữ liệu hay thuật toán.

⚠ Điểm mấu chốt — không có mục tiêu thì không đánh giá được gì:

"Dự đoán nhu cầu sản phẩm"
        ↓
    ⚠ Nghe rõ ràng, nhưng chưa đủ:
      - dự đoán cho bao xa? tuần? tháng?
      - ở mức nào? từng SKU? từng nhóm?
      - sai lệch bao nhiêu là chấp nhận được?
      - dự đoán THIẾU và dự đoán THỪA
        cái nào tốn hơn?
        ↓
    → không trả lời được thì không biết
      mô hình nào là "đủ tốt"

⚠ Vì sao mọi bước sau đều phụ thuộc vào bước này:

Mục tiêu nghiệp vụ
        ↓
    quyết định BÀI TOÁN ML
      → hồi quy? phân loại? chuỗi thời gian?
        ↓
    quyết định CHỈ SỐ đánh giá
      → MAE? RMSE? precision? recall?
        ↓
    quyết định DỮ LIỆU cần thu thập
        ↓
    quyết định THUẬT TOÁN
        ↓
    ⚠ Đảo thứ tự là xây nhà từ mái

⚠ Vòng đời dự án ML chuẩn:

1. ĐỊNH NGHĨA BÀI TOÁN           ← đề này
     mục tiêu nghiệp vụ, tiêu chí thành công
2. THU THẬP và KHÁM PHÁ DỮ LIỆU
3. CHUẨN BỊ DỮ LIỆU
     làm sạch, tạo đặc trưng
4. HUẤN LUYỆN và THỬ NGHIỆM
     chọn thuật toán, tinh chỉnh
5. ĐÁNH GIÁ
     so với tiêu chí đã đặt ở bước 1
6. TRIỂN KHAI
7. GIÁM SÁT và HUẤN LUYỆN LẠI

Xem thêm câu #13116 (cùng lô): về Vertex AI Model Registry — công cụ cho bước 4 và 6. Hai câu ở hai đầu của cùng một vòng đời.

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

A (chọn thuật toán học máy) — đây là phương án gần nhất vì cũng là bước sớm trong phần kỹ thuật, nhưng không thể chọn thuật toán khi chưa biết bài toán là hồi quy hay phân loại, và chưa biết chỉ số nào quan trọng.
C (tinh chỉnh siêu tham số) — bước rất muộn, sau khi đã có mô hình cơ sở.
B (triển khai mô hình lên endpoint) — bước cuối cùng, sau khi mô hình đã đạt tiêu chí.

Ghi nhớ

⚠ Vòng đời dự án học máy — bảng phải thuộc: | Bước | Nội dung | |---|---| | 1. Định nghĩa bài toán | mục tiêu nghiệp vụ, tiêu chí thành công | | 2. Thu thập và khám phá dữ liệu | có đủ dữ liệu không | | 3. Chuẩn bị dữ liệu | làm sạch, tạo đặc trưng | | 4. Huấn luyện và thử nghiệm | chọn thuật toán, so sánh | | 5. Đánh giá | so với tiêu chí ở bước 1 | | 6. Triển khai | endpoint hoặc batch prediction | | 7. Giám sát và huấn luyện lại | chống trôi |

Từ khoá nhận diện:

"bước đầu tiên trong dự án ML" → định nghĩa mục tiêu nghiệp vụ "chọn thuật toán" → bước sau khi đã biết bài toán "tinh chỉnh siêu tham số" → bước muộn "triển khai" → bước cuối "quản lý phiên bản mô hình" → Model Registry

Một tiêu chí thành công tốt gồm gì	Thành phần
Chỉ số KỸ THUẬT	MAE, RMSE, AUC — đo mô hình
Chỉ số NGHIỆP VỤ	giảm tồn kho bao nhiêu %, tiết kiệm bao nhiêu tiền
Ngưỡng chấp nhận	dưới mức nào thì không triển khai
Đường cơ sở (baseline)	so với cách làm hiện tại
Ràng buộc	thời gian dự đoán, khả năng giải thích

Vì sao BASELINE quan trọng	Lý do
Cách làm hiện tại đang đạt bao nhiêu
Ví dụ	dự báo bằng "trung bình 4 tuần trước"
Mô hình phải TỐT HƠN baseline	mới đáng triển khai
Không có baseline	không biết mô hình có giá trị gì
Thực tế	nhiều mô hình phức tạp thua một quy tắc đơn giản

Với bài toán dự đoán nhu cầu	Đặc thù
Bài toán CHUỖI THỜI GIAN	→ `ARIMA_PLUS` trong BQML
Tính mùa vụ và ngày lễ	phải đưa vào mô hình
Dự đoán THIẾU ↔ THỪA	chi phí không đối xứng
Chỉ số	MAE hoặc MAPE thường dễ giải thích nhất
Mức dự đoán	từng SKU hay từng nhóm — quyết định ở bước 1

Sai lầm hay gặp khi bỏ qua bước 1	Sai lầm
Mô hình chính xác cao nhưng vô dụng	dự đoán sai thứ nghiệp vụ cần
Không ai biết khi nào là "xong"	dự án kéo dài vô tận
Chọn sai chỉ số	accuracy với dữ liệu mất cân bằng
Không có baseline	không chứng minh được giá trị
Hệ quả	dự án ML thất bại vì lý do NGHIỆP VỤ, không phải kỹ thuật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tiêu chí thành công đã viết ra chưa | tài liệu dự án | | Có baseline chưa | đo cách làm hiện tại | | Chỉ số có phản ánh nghiệp vụ không | thảo luận với bên đặt hàng |

Và một câu hỏi nên đặt ra trước khi viết dòng mã đầu tiên của bất kỳ dự án học máy nào: nếu mô hình đạt độ chính xác X, thì công ty sẽ làm gì khác đi? Nếu không ai trả lời được, dự án chưa sẵn sàng bắt đầu — và đó là nguyên nhân thất bại phổ biến hơn nhiều so với việc chọn sai thuật toán.

Câu 204 Data Management

A financial data provider wants to securely share its curated BigQuery datasets with its paying subscribers. The provider needs a solution that allows subscribers to query the data directly from their own Google Cloud projects without the provider having to make copies of the data.

Which Google Cloud service is designed for this secure, in-place data sharing use case?

A Analytics Hub
B Cloud Storage
C Cloud SQL Federation
D Dataplex

Xem giải thích

Đáp án

A — Analytics Hub.

Vì sao đúng

Đề nêu ba yêu cầu: chia sẻ dataset BigQuery cho người đăng ký trả phí, họ truy vấn TỪ CHÍNH PROJECT CỦA HỌ, và nhà cung cấp KHÔNG phải tạo bản sao. Analytics Hub được thiết kế cho đúng mô hình này.

⚠ Điểm mấu chốt — chia sẻ bằng con trỏ, không phải bản sao:

Nhà cung cấp tạo LISTING trong EXCHANGE
        ↓
    Người đăng ký ĐĂNG KÝ
        ↓
    Nhận LINKED DATASET trong
    PROJECT CỦA CHÍNH HỌ
        ↓
    ⚠ Dữ liệu vẫn nằm ở MỘT chỗ duy nhất
    ⚠ Người đăng ký truy vấn như bảng
      trong project mình
    ⚠ Cập nhật ở nguồn là thấy ngay
    ⚠ THU HỒI được bất cứ lúc nào

⚠ Mô hình chi phí rất hợp với việc bán dữ liệu:

NHÀ CUNG CẤP
    → trả phí LƯU TRỮ

NGƯỜI ĐĂNG KÝ
    → trả phí TRUY VẤN của chính họ
        ↓
    ⚠ Càng nhiều khách hàng truy vấn,
      nhà cung cấp KHÔNG tốn thêm
        ↓
    → mô hình kinh doanh dữ liệu
      trở nên khả thi

⚠ Ba khái niệm — nhắc lại:

EXCHANGE   → sàn trao đổi chứa các listing
             (riêng, hoặc công khai)
LISTING    → một dataset được công bố
             kèm mô tả và điều kiện
SUBSCRIPTION → bên nhận đăng ký
               → sinh LINKED DATASET

Xem thêm câu #13068 (lô 136) và #12945 (lô 134): cùng khoá Analytics Hub cho chia sẻ nội bộ và chia sẻ với đối tác. Ba câu hoàn toàn nhất quán. Câu này là biến thể thương mại hoá dữ liệu.

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

D (Dataplex) — đây là phương án gần nhất vì cũng thuộc nhóm quản trị dữ liệu, nhưng Dataplex lập danh mục và quản trị, không cấp quyền truy cập hay tạo linked dataset cho bên ngoài.
B (Cloud Storage) — chia sẻ tệp, và cách làm đó buộc phải tạo bản sao — trái yêu cầu.
C ("Cloud SQL Federation") — không phải tên dịch vụ chuẩn cho việc này; federated query của BigQuery dùng để truy vấn Cloud SQL, không phải chia sẻ dataset.

Ghi nhớ

⚠ Các cách chia sẻ dữ liệu BigQuery — bảng phải thuộc: | Cách | Dùng khi | |---|---| | Analytics Hub | chia sẻ ra ngoài, không sao chép, có quản trị và theo dõi | | IAM trên dataset | chia sẻ đơn giản trong nội bộ | | Authorized view | chỉ lộ MỘT PHẦN dữ liệu | | Dataset copy | bên nhận cần bản sao riêng | | bq extract sang GCS | bên nhận không dùng BigQuery | | Row/column-level security | giới hạn theo dòng và cột |

Từ khoá nhận diện:

"chia sẻ không sao chép, có đăng ký" → Analytics Hub "tìm kiếm và quản trị siêu dữ liệu" → Dataplex "chỉ cho xem vài cột" → authorized view / policy tag "bên nhận cần bản sao riêng" → dataset copy "chia sẻ tệp" → Cloud Storage — nhưng phải sao chép

Analytics Hub cho mô hình bán dữ liệu	Lợi ích
Không nhân bản dữ liệu	một bản, nhiều người dùng
Thu hồi tức thì	hết hạn hợp đồng là huỷ listing
Theo dõi mức sử dụng	biết khách hàng dùng bao nhiêu
Người đăng ký tự trả phí truy vấn	chi phí không tăng theo khách
Danh mục có mô tả	khách tự tìm hiểu trước khi đăng ký
Chia sẻ view thay vì bảng	kiểm soát phần lộ ra

Chuẩn bị trước khi công bố listing thương mại	Việc
Quét PII	Sensitive Data Protection
Chia sẻ VIEW, không chia sẻ bảng gốc	dễ đổi cấu trúc bên dưới
Mô tả rõ ràng	lược đồ, tần suất cập nhật, ý nghĩa cột
Điều khoản sử dụng	ghi trong mô tả
Chỉ định chủ sở hữu	ai chịu trách nhiệm
SLA về độ tươi dữ liệu	khách hàng trả phí sẽ hỏi

Chia sẻ VIEW — vì sao nên	Lý do
Lọc dòng, ẩn cột trước khi chia sẻ
Tổng hợp trước	không lộ bản ghi cá nhân
Đổi cấu trúc bảng gốc	người đăng ký không bị ảnh hưởng
Phiên bản hoá dữ liệu bán ra	view v1, v2
Kết hợp	authorized view + Analytics Hub

Kiểm soát người đăng ký	Cách
Exchange riêng cho từng nhóm khách
Domain Restricted Sharing	Organization Policy có thể chặn — cần ngoại lệ
Theo dõi mức sử dụng	phát hiện dùng bất thường
Huỷ subscription	khi hết hạn hợp đồng
Audit log	ai truy vấn gì, khi nào

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đang đăng ký | console → Analytics Hub → listing → Subscriptions | | Họ truy vấn bao nhiêu | số liệu của Hub | | Listing có lộ cột nhạy cảm không | kiểm tra định nghĩa view và policy tag |

Và một quyết định nên chốt trước khi công bố listing đầu tiên cho khách hàng trả phí: chia sẻ một VIEW, không chia sẻ bảng gốc. View cho bạn quyền đổi cấu trúc bên dưới, thêm cột, tái tổ chức dữ liệu mà không phá vỡ truy vấn của khách — và đó là thứ bạn chắc chắn sẽ cần trong năm đầu tiên.

Câu 205 Data Management

A data governance administrator is creating a new Cloud Storage bucket that will be used as a data lake. To simplify permissions management, they want to ensure that access to all objects in the bucket is controlled exclusively through IAM (Identity and Access Management) policies, disabling older object-level Access Control Lists (ACLs).

Which configuration should the administrator set on the bucket?

A Fine-grained access
B Public access
C Signed URLs
D Uniform bucket-level access

Xem giải thích

Đáp án

D — Uniform bucket-level access (truy cập đồng nhất ở cấp bucket).

Vì sao đúng

Yêu cầu là mọi truy cập được kiểm soát HOÀN TOÀN bằng IAM, và vô hiệu hoá ACL ở cấp đối tượng. Đó chính là định nghĩa của uniform bucket-level access.

⚠ Điểm mấu chốt — hai mô hình kiểm soát truy cập:

UNIFORM (đồng nhất)              ← đề này
        ↓
    CHỈ dùng IAM ở cấp bucket
    → ACL từng đối tượng bị VÔ HIỆU HOÁ
    → mọi đối tượng thừa hưởng quyền bucket
        ↓
    → đơn giản, dễ rà soát, khó cấu hình sai

FINE-GRAINED (chi tiết)
        ↓
    IAM cấp bucket + ACL riêng từng đối tượng
    → linh hoạt hơn
    → ⚠ RẤT DỄ để lộ một đối tượng
      mà IAM policy nhìn vẫn đúng

⚠ Bật:

# Lúc tạo bucket
gcloud storage buckets create gs://data-lake \
  --uniform-bucket-level-access

# Trên bucket đã có
gcloud storage buckets update gs://data-lake \
  --uniform-bucket-level-access
        ↓
    ⚠ Có 90 NGÀY để đổi ý và tắt lại
    ⚠ Sau 90 ngày thì KHÔNG quay lại được

⚠ Vì sao ACL từng đối tượng là nguồn rủi ro:

Với fine-grained
        ↓
    Một lần tải lên đặt allUsers:READ
        ↓
    → MỘT tệp công khai giữa hàng triệu tệp
    → IAM policy của bucket trông vẫn ĐÚNG
    → `get-iam-policy` KHÔNG THẤY gì bất thường
        ↓
    ⚠ Đây là nguyên nhân của rất nhiều
      vụ rò rỉ dữ liệu trên các đám mây

Xem thêm câu #12937 (lô 134): cùng tình huống, cùng khoá uniform bucket-level access. Hai câu hoàn toàn nhất quán. Và #13100 (cùng lô): Signed URL vẫn hoạt động bình thường với uniform access — đó là cách chia sẻ đúng khi đã tắt ACL.

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

A (fine-grained access) — đây là phương án đối lập trực tiếp: nó BẬT ACL từng đối tượng, đúng thứ đề muốn tắt.
C (Signed URL) — là cơ chế chia sẻ tạm thời một đối tượng, không phải chế độ kiểm soát truy cập của bucket. (Nó hoạt động được với uniform access, nhưng không trả lời câu hỏi.)
B (public access) — mở bucket ra Internet; ngược hoàn toàn với mục tiêu quản trị.

Ghi nhớ

⚠ Hai mô hình kiểm soát truy cập bucket — bảng phải thuộc: | | Uniform | Fine-grained | |---|---|---| | Cơ chế | chỉ IAM cấp bucket | IAM + ACL từng đối tượng | | ACL đối tượng | VÔ HIỆU HOÁ | có hiệu lực | | Rà soát quyền | dễ — một chỗ duy nhất | khó — phải quét từng đối tượng | | Rủi ro lộ dữ liệu | thấp | cao | | Khuyến nghị | MẶC ĐỊNH NÊN DÙNG | chỉ khi thật sự cần | | Đổi ý | 90 ngày để quay lại fine-grained |

Từ khoá nhận diện:

"chỉ dùng IAM, tắt ACL đối tượng" → uniform bucket-level access "cần quyền riêng cho từng tệp" → fine-grained — nên tránh "chia sẻ tạm thời một tệp" → Signed URL "chặn bucket công khai toàn tổ chức" → Public Access Prevention "data lake cần quản trị" → uniform + BigLake + Dataplex

Ba lớp nên bật cùng nhau cho data lake	Lớp
Uniform bucket-level access	tắt ACL đối tượng
Public Access Prevention	chặn `allUsers` và `allAuthenticatedUsers`
Organization Policy	ép hai điều trên cho MỌI bucket
Ràng buộc	`storage.uniformBucketLevelAccess`, `storage.publicAccessPrevention`
Kết quả	không ai vô tình mở dữ liệu ra Internet được

Chia sẻ khi đã bật uniform	Cách
IAM ở cấp bucket	cho người trong tổ chức
IAM condition theo tiền tố tên	giới hạn phạm vi trong bucket
Signed URL	tạm thời, cho người ngoài
BigLake table	truy vấn qua BigQuery, không cần quyền bucket
⚠ Không dùng được	ACL từng đối tượng

Trước khi bật uniform trên bucket đang chạy	Việc
Kiểm tra có ứng dụng nào dựa vào ACL không
Rà soát ACL hiện có	`gsutil acl get`
Chuyển các quyền đó sang IAM
Thử trên môi trường không sản xuất trước
Triệu chứng nếu bỏ sót	dịch vụ nhận 403 mà IAM nhìn vẫn đúng

Rà soát bucket có an toàn không	Việc
`get-iam-policy`	tìm `allUsers`
`uniformBucketLevelAccess`	đã bật chưa
`publicAccessPrevention`	nên là `enforced`
Security Command Center	tự phát hiện bucket công khai
Cloud Asset Inventory	quét toàn tổ chức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket dùng mô hình nào | gcloud storage buckets describe gs://b --format="value(uniformBucketLevelAccess)" | | Có ai truy cập công khai không | get-iam-policy, tìm allUsers | | Còn bao lâu để đổi ý | trường lockedTime trong describe |

Và một cấu hình nên bật cùng lúc với uniform access, vì hai thứ bổ sung nhau: Public Access Prevention. Uniform loại bỏ ACL từng đối tượng, còn Public Access Prevention chặn hẳn việc cấp quyền cho allUsers ở cấp bucket — cùng nhau, chúng đóng cả hai con đường phổ biến nhất dẫn tới một bucket vô tình công khai.

Câu 206 Data Analysis and Presentation

A machine learning engineer has trained several versions of a customer churn prediction model. They need a centralized location on Google Cloud to store, manage, and track these different model versions before deploying one for serving predictions.

Which service is designed for this purpose?

A Vertex AI Model Registry
B BigQuery
C Cloud Source Repositories
D Cloud Storage

Xem giải thích

Đáp án

A — Vertex AI Model Registry.

Vì sao đúng

Đề nêu bốn nhu cầu: nơi TẬP TRUNG, để lưu, quản lý và theo dõi nhiều PHIÊN BẢN mô hình, trước khi triển khai một phiên bản để phục vụ dự đoán. Model Registry là dịch vụ cho đúng việc đó.

⚠ Điểm mấu chốt — kho quản lý vòng đời mô hình:

Vertex AI Model Registry
        ↓
    - Đăng ký mô hình với TÊN và PHIÊN BẢN
    - Gắn NHÃN: default, staging, production
    - Lưu SIÊU DỮ LIỆU: chỉ số đánh giá,
      dữ liệu huấn luyện, thời điểm
    - So sánh các phiên bản
    - Triển khai một phiên bản lên ENDPOINT
    - Quay lui về phiên bản trước
        ↓
    ⚠ Một chỗ duy nhất trả lời:
      "mô hình nào đang chạy, và vì sao"

⚠ Vì sao Cloud Storage một mình là không đủ:

Lưu tệp mô hình trong GCS
        ↓
    ⚠ Chỉ là TỆP — không có siêu dữ liệu
    ⚠ Không biết phiên bản nào tốt hơn
    ⚠ Không biết phiên bản nào đang chạy
    ⚠ Không có cơ chế triển khai
        ↓
    → Model Registry lưu ARTIFACT ở GCS
      nhưng bổ sung toàn bộ lớp quản lý

⚠ Vòng đời một mô hình trong Registry:

Huấn luyện xong
        ↓
    ĐĂNG KÝ vào Model Registry
      → tạo version mới của cùng một model
        ↓
    So sánh chỉ số với version hiện tại
        ↓
    Nếu tốt hơn → TRIỂN KHAI lên endpoint
        ↓
    Theo dõi chất lượng khi chạy thật
        ↓
    Nếu suy giảm → QUAY LUI version cũ

Xem thêm câu #13113 (cùng lô): về vòng đời dự án ML — Model Registry phục vụ bước 4 tới bước 7. Hai câu ở hai đầu của cùng một quy trình. Và #12962/#13022 (lô 134, 135): dùng mô hình để dự đoán.

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

D (Cloud Storage) — đây là phương án gần nhất vì artifact của mô hình THẬT SỰ nằm ở GCS, nhưng nó chỉ là kho tệp: không có phiên bản có ý nghĩa, không có chỉ số, không có cơ chế triển khai.
C (Cloud Source Repositories) — kho MÃ NGUỒN, không phải kho mô hình đã huấn luyện.
B (BigQuery) — kho dữ liệu; BigQuery ML có lưu mô hình trong dataset, nhưng đó không phải nơi quản lý phiên bản và triển khai tập trung như đề mô tả.

Ghi nhớ

⚠ Các thành phần của Vertex AI — bảng phải thuộc: | Thành phần | Việc | |---|---| | Model Registry | lưu, phiên bản hoá, quản lý mô hình | | Endpoint | phục vụ dự đoán trực tuyến | | Batch prediction | dự đoán theo lô | | Pipelines | điều phối luồng ML | | Feature Store | quản lý đặc trưng dùng chung | | Experiments | theo dõi các lần thử nghiệm | | Model Monitoring | phát hiện trôi dữ liệu và chất lượng | | Workbench / Colab Enterprise | môi trường notebook |

Từ khoá nhận diện:

"lưu và quản lý nhiều phiên bản mô hình" → Model Registry "phục vụ dự đoán thời gian thực" → Endpoint "điều phối luồng huấn luyện" → Vertex AI Pipelines "phát hiện mô hình suy giảm" → Model Monitoring "kho mã nguồn" → Cloud Source Repositories / GitHub — khác hẳn

Model Registry — điều cần nhớ	Nội dung
Model	một "họ" mô hình, có nhiều version
Version alias	`default`, `staging`, `production`
Nguồn mô hình	AutoML, custom training, BigQuery ML, nhập từ ngoài
Metadata	chỉ số đánh giá, dữ liệu huấn luyện
Triển khai	một hoặc nhiều version lên cùng endpoint
Chia lưu lượng	A/B test giữa các version

Đưa mô hình BigQuery ML vào Registry	Cách
`CREATE MODEL ... OPTIONS(model_registry='vertex_ai')`	đăng ký tự động
Lợi ích	quản lý cùng chỗ với mô hình Vertex AI
Rồi	triển khai lên endpoint để phục vụ ngoài BigQuery
Hoặc	giữ trong BigQuery và dùng `ML.PREDICT`
Chọn theo	ai là bên tiêu thụ dự đoán

Triển khai an toàn — chia lưu lượng	Bước
1	Triển khai version mới với 0% lưu lượng
2	Thử nghiệm trên endpoint có tag
3	Chia 10% lưu lượng sang version mới
4	So chỉ số giữa hai version
5	Tăng dần tới 100%, hoặc quay lui
Đây là	canary deployment cho mô hình

Model Monitoring — vì sao cần	Lý do
Trôi dữ liệu (drift)	phân phối đầu vào thay đổi
Trôi khái niệm	quan hệ đặc trưng–nhãn thay đổi
Lệch giữa huấn luyện và phục vụ	training-serving skew
Phát hiện bằng	so phân phối với dữ liệu huấn luyện
Hành động	cảnh báo và huấn luyện lại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Version nào đang phục vụ | Model Registry → endpoint deployment | | Chỉ số của từng version | siêu dữ liệu trong Registry | | Mô hình còn tốt không | Model Monitoring |

Và một thói quen giúp việc quản lý mô hình bớt rối ngay từ dự án đầu tiên: luôn ghi chỉ số đánh giá và mô tả dữ liệu huấn luyện vào siêu dữ liệu của version. Sáu tháng sau, khi cần trả lời "vì sao chúng ta chọn version 7 chứ không phải version 5", đó là thông tin duy nhất còn lại — và nó không tự sinh ra nếu không ai điền.

Câu 207 Data Analysis and Presentation

A marketing analyst wants to use a Google-hosted Large Language Model (LLM) to generate a short, positive summary for each customer review in their BigQuery table. They have already created a remote model connection.

Which BigQuery ML function should they use to pass the review text to the LLM and get a summary?

A ML.PREDICT()
B ML.GENERATE_TEXT()
C ML.CREATE_MODEL()
D ML.TRANSCRIBE()

Xem giải thích

Đáp án

B — ML.GENERATE_TEXT()

Vì sao đúng

Đây là hàm của BigQuery ML dùng để gửi văn bản tới một mô hình ngôn ngữ lớn (LLM) qua remote model và nhận về văn bản sinh ra — đúng nhu cầu tóm tắt đánh giá khách hàng.

⚠ Điểm mấu chốt — cú pháp đầy đủ:

SELECT
  review_id,
  ml_generate_text_llm_result AS tom_tat
FROM ML.GENERATE_TEXT(
  MODEL `du_an.mo_hinh_gemini`,
  (
    SELECT
      review_id,
      CONCAT(
        'Tóm tắt đánh giá sau trong một câu, ',
        'giọng tích cực: ', noi_dung
      ) AS prompt
    FROM `du_an.danh_gia_khach_hang`
  ),
  STRUCT(
    0.2 AS temperature,
    128 AS max_output_tokens,
    TRUE AS flatten_json_output
  )
);

⚠ Hai bước chuẩn bị (đề nói đã làm xong bước connection):

1. Tạo CONNECTION tới Vertex AI
   + cấp roles/aiplatform.user cho
     service account của connection

2. Tạo REMOTE MODEL
   CREATE MODEL `du_an.mo_hinh_gemini`
   REMOTE WITH CONNECTION `...`
   OPTIONS (ENDPOINT = 'gemini-pro');
        ↓
    Rồi mới gọi ML.GENERATE_TEXT

⚠ Vì sao ML.PREDICT không dùng được ở đây:

ML.PREDICT
        ↓
    Dành cho mô hình BQML TỰ HUẤN LUYỆN
      LOGISTIC_REG, LINEAR_REG, KMEANS...
        ↓
    ⚠ Không gọi được mô hình NGÔN NGỮ
    → mô hình nền tảng dùng hàm riêng

Xem thêm câu #13022 (lô 135): cùng tình huống, cùng khoá ML.GENERATE_TEXT với remote model. Hai câu hoàn toàn nhất quán. Và #12962 (lô 134): khoá ML.PREDICT cho mô hình BQML tự huấn luyện — hàm khác vì loại mô hình khác.

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

A (ML.PREDICT()) — đây là phương án gần nhất và là hàm dự đoán quen thuộc nhất của BQML, nhưng nó dành cho mô hình BQML tự huấn luyện, không gọi được mô hình ngôn ngữ qua remote model.
C (ML.CREATE_MODEL()) — không phải tên hàm hợp lệ; tạo mô hình dùng câu lệnh CREATE MODEL.
D (ML.TRANSCRIBE()) — dùng để chuyển GIỌNG NÓI thành văn bản, không phải sinh văn bản từ văn bản.

Ghi nhớ

⚠ Các hàm AI trong BigQuery — bảng phải thuộc: | Hàm | Việc | |---|---| | ML.GENERATE_TEXT | sinh văn bản: tóm tắt, phân loại, trích xuất | | ML.GENERATE_EMBEDDING | vector nhúng cho tìm kiếm ngữ nghĩa | | ML.UNDERSTAND_TEXT | gọi Natural Language API | | ML.TRANSLATE | dịch | | ML.TRANSCRIBE | giọng nói → văn bản | | ML.ANNOTATE_IMAGE | phân tích ảnh (với object table) | | ML.PREDICT | mô hình BQML tự huấn luyện | | VECTOR_SEARCH | tìm kiếm theo vector |

Từ khoá nhận diện:

"tóm tắt, phân loại văn bản bằng LLM" → ML.GENERATE_TEXT "tìm kiếm ngữ nghĩa" → ML.GENERATE_EMBEDDING + VECTOR_SEARCH "dự đoán bằng mô hình tự huấn luyện" → ML.PREDICT "chuyển âm thanh thành chữ" → ML.TRANSCRIBE "ML.CREATE_MODEL" → KHÔNG TỒN TẠI — dùng CREATE MODEL

Tham số quan trọng của `ML.GENERATE_TEXT`	Tham số
`temperature`	thấp (0–0,2) cho tác vụ cần NHẤT QUÁN như tóm tắt
`max_output_tokens`	giới hạn độ dài
`flatten_json_output = TRUE`	trả cột phẳng, dễ dùng
`top_k`, `top_p`	điều khiển đa dạng
Prompt	dựng bằng `CONCAT` từ cột dữ liệu

Viết prompt cho kết quả ổn định	Thói quen
Nói rõ ĐỘ DÀI mong muốn	"trong một câu"
Nói rõ GIỌNG ĐIỆU	"tích cực", "trung lập"
Cho VÍ DỤ	few-shot giúp kết quả nhất quán hơn
`temperature` thấp	tránh mỗi lần một kiểu
Xử lý đầu vào rỗng hoặc quá dài	lọc trước khi gọi

Chi phí — điều phải biết trước	Nội dung
Tính theo số TOKEN gửi và nhận	không theo byte quét
Thử trên MẪU trước	`LIMIT 100` để ước lượng
Chỉ sinh cho bản ghi MỚI	không chạy lại toàn bảng
LƯU kết quả vào bảng	không gọi lại mỗi lần xem báo cáo
Hạn mức của Vertex AI	job lớn có thể bị giới hạn tốc độ

Với đánh giá khách hàng — lưu ý thêm	Lưu ý
Quét PII trước	đánh giá tự do hay chứa tên, số điện thoại
Kiểm tra tay một mẫu	mô hình có hiểu đúng tiếng Việt không
Mỉa mai và tiếng lóng	LLM dễ hiểu sai
Yêu cầu "giọng tích cực"	cẩn thận — có thể che mất phản hồi tiêu cực thật
Nên	giữ cả bản gốc bên cạnh bản tóm tắt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Connection có quyền chưa | service account cần roles/aiplatform.user | | Kết quả có hợp lý không | đọc tay 50 bản tóm tắt ngẫu nhiên | | Chi phí bao nhiêu | billing export, SKU Vertex AI |

Và một điều đáng cân nhắc về mặt nghiệp vụ khi yêu cầu mô hình "tóm tắt với giọng tích cực": bạn có thể đang che mất tín hiệu quan trọng nhất. Một đánh giá tiêu cực được tóm tắt theo hướng tích cực sẽ không lọt vào tầm mắt của đội chăm sóc khách hàng — nên hãy giữ cả bản gốc và một trường điểm cảm xúc bên cạnh bản tóm tắt.

Câu 208 Data Preparation and Ingestion

An analytics team is designing a new data pipeline that will load data into BigQuery for complex analytical queries. The source data is deeply nested and semi-structured. The team needs to choose a file format that is optimized for query performance in BigQuery, supports schema evolution, and is column-oriented.

Which file format is the best choice?

A JSON (JavaScript Object Notation)
B Plain Text (.txt)
C Apache Parquet
D CSV (Comma-Separated Values)

Xem giải thích

Đáp án

C — Apache Parquet.

Vì sao đúng

Đề nêu bốn yêu cầu, và Parquet đáp ứng cả bốn: dữ liệu lồng nhau và bán cấu trúc, tối ưu cho truy vấn trong BigQuery, hỗ trợ tiến hoá lược đồ, và lưu theo CỘT.

⚠ Điểm mấu chốt — "lưu theo cột" là yêu cầu quyết định:

"column-oriented" trong đề
        ↓
    ⚠ Loại ngay JSON, CSV, Plain Text
      — cả ba đều theo DÒNG hoặc văn bản
        ↓
    Chỉ còn Parquet (và ORC)
        ↓
    Parquet còn thoả nốt:
      - hỗ trợ CẤU TRÚC LỒNG đầy đủ
      - có tiến hoá lược đồ
      - nạp vào BigQuery rất nhanh

⚠ Ba cơ chế giúp Parquet quét ít:

COLUMN PRUNING
    → chỉ đọc cột cần

PREDICATE PUSHDOWN
    → mỗi row group có thống kê min/max
    → bỏ qua khối không thoả điều kiện

NÉN THEO CỘT
    → cùng cột = cùng kiểu, giá trị lặp nhiều
    → mã hoá từ điển, run-length rất hiệu quả
        ↓
    ⚠ BigQuery tính tiền theo BYTE QUÉT
    → quét ít = rẻ hơn và nhanh hơn

⚠ Parquet hỗ trợ cấu trúc lồng đầy đủ:

Parquet dùng mô hình Dremel
(chính là nền của BigQuery)
        ↓
    → biểu diễn được STRUCT và ARRAY
      lồng nhiều tầng
        ↓
    Nạp vào BigQuery
        ↓
    → giữ nguyên RECORD và REPEATED
    ⚠ Đúng yêu cầu "dữ liệu lồng sâu"

Xem thêm câu #13008 (lô 136): cùng khoá Parquet cho tối ưu truy vấn BigQuery. Và #12950 (lô 134): khoá Avro vì đề ở đó nhấn theo DÒNG. #13095/#13106 (cùng lô): CSV không lồng nhau được. Bốn câu nhất quán.

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

A (JSON) — đây là phương án gần nhất vì giữ được cấu trúc lồng, nhưng nó là văn bản, lưu theo DÒNG, cồng kềnh (lặp tên khoá mọi bản ghi), và không có predicate pushdown.
D (CSV) — phẳng hoàn toàn, không kiểu, không nén, không lồng nhau.
B (Plain Text) — không có cấu trúc gì cả.

Ghi nhớ

⚠ Bốn định dạng — bảng phải thuộc: | Định dạng | Kiểu | Lồng nhau | Hợp với | |---|---|---|---| | Parquet | nhị phân, theo CỘT | có | PHÂN TÍCH | | ORC | nhị phân, theo cột | có | tương tự Parquet | | Avro | nhị phân, theo DÒNG | có | NẠP, truyền tin, tiến hoá lược đồ | | JSON | văn bản, theo dòng | có | trao đổi, API | | CSV | văn bản, PHẲNG | KHÔNG | trao đổi đơn giản |

Từ khoá nhận diện:

"theo cột, phân tích, nén tốt" → Parquet "theo dòng, lược đồ nhúng, tiến hoá" → Avro "{} lồng nhau, đọc được bằng mắt" → JSON "bảng phẳng đơn giản" → CSV "lược đồ lồng + tối ưu truy vấn" → Parquet

Tiến hoá lược đồ trong Parquet	Nội dung
Thêm cột mới	tệp cũ vẫn đọc được, cột mới là NULL
Bỏ cột	truy vấn không chọn cột đó thì không sao
Đổi kiểu	hạn chế hơn Avro
So với Avro	Avro linh hoạt hơn về tiến hoá lược đồ
Với BigQuery	`--schema_update_option=ALLOW_FIELD_ADDITION`

Thiết kế tệp Parquet cho tốt	Thói quen
Kích thước tệp 128 MB – 1 GB	tránh hàng vạn tệp nhỏ
Row group vài trăm MB	cân bằng pushdown và chi phí
SẮP XẾP theo cột hay lọc	thống kê min/max mới hiệu quả
Phân vùng theo thư mục	`nam=2026/thang=09/`
Nén Snappy hoặc ZSTD	cân bằng tốc độ và tỉ lệ nén

Vấn đề "quá nhiều tệp nhỏ"	Nội dung
Triệu chứng	truy vấn chậm bất thường dù dữ liệu không lớn
Nguyên nhân	chi phí liệt kê và mở tệp lớn hơn chi phí đọc
Khắc phục	gộp tệp định kỳ (compaction)
Với BigLake	bật metadata caching
Phòng ngừa	ngưỡng dung lượng khi ghi

Nạp Parquet vào BigQuery	Nội dung
Rất nhanh	đọc song song tốt
Giữ nguyên kiểu và cấu trúc lồng
Nạp theo lô MIỄN PHÍ
Ký tự đại diện	`gs://b/prefix-*.parquet`
So với CSV	nhanh hơn và ít sai kiểu hơn nhiều

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lược đồ Parquet thế nào | parquet-tools schema, hoặc bq show --schema sau khi nạp | | Tệp có quá nhỏ không | gcloud storage ls -l xem phân bố kích thước | | Truy vấn quét bao nhiêu | --dry_run và total_bytes_billed |

Và một chi tiết ảnh hưởng tới hiệu năng nhiều hơn người ta tưởng: sắp xếp dữ liệu theo cột hay lọc trước khi ghi Parquet. Thống kê min/max của mỗi row group chỉ giúp bỏ qua dữ liệu khi các giá trị gần nhau nằm cùng chỗ — với dữ liệu ghi theo thứ tự ngẫu nhiên, mọi row group đều chứa đủ dải giá trị và predicate pushdown gần như mất tác dụng.

Câu 209 Data Management

A financial services company is designing an application that requires the highest possible availability and redundancy for its critical data stored in Cloud Storage. The data must remain accessible even in the event of a complete regional outage.

Which Cloud Storage location type should they choose for their bucket?

A Regional
B Multi-region
C Zonal
D Dual-region

Xem giải thích

Đáp án

B — Multi-region.

Vì sao đúng

Yêu cầu tuyệt đối của đề là: dữ liệu phải truy cập được NGAY CẢ KHI MẤT HOÀN TOÀN MỘT REGION. Chỉ vị trí multi-region cho mức dự phòng đó.

⚠ Điểm mấu chốt — dữ liệu được nhân bản qua nhiều Region:

MULTI-REGION (US, EU, ASIA)
        ↓
    Dữ liệu nhân bản qua NHIỀU REGION
    trong một khu vực địa lý lớn
        ↓
    ⚠ Mất HOÀN TOÀN một Region
    → dữ liệu VẪN truy cập được
        ↓
    SLA sẵn sàng cao nhất
    → 99,95% với lớp Standard

⚠ So bốn kiểu vị trí:

ZONAL
    → ⚠ Cloud Storage KHÔNG có kiểu này
    → (chỉ đĩa của Compute Engine mới có)

REGIONAL
    → dữ liệu trong MỘT Region
    → nhân bản qua các zone trong Region
    → ⚠ mất cả Region → KHÔNG truy cập được

DUAL-REGION
    → nhân bản qua HAI Region cụ thể
    → chịu được mất một trong hai
    → độ trễ thấp ở cả hai

MULTI-REGION                     ← đề này
    → nhân bản rộng hơn
    → sẵn sàng cao nhất

⚠ Đánh đổi phải nói rõ:

Multi-region
    Ưu:  sẵn sàng cao nhất
         phục vụ người dùng phân tán
    Nhược: ⚠ ĐẮT NHẤT
           ⚠ độ trễ tại một điểm cụ thể
             có thể cao hơn regional
           ⚠ dữ liệu nằm ở nhiều nước
             trong khu vực → cân nhắc
             yêu cầu chủ quyền dữ liệu

Xem thêm câu #13121 (cùng lô): khoá Regional vì ở đó người dùng tập trung ở europe-west1 và ưu tiên hiệu năng và chi phí. Hai khoá khác nhau vì yêu cầu khác nhau — hoàn toàn nhất quán. Và #12921 (lô 133), #12967 (lô 134): cùng bộ tiêu chí chọn vị trí bucket.

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

D (dual-region) — đây là phương án gần nhất và cũng chịu được mất một Region, nhưng đề yêu cầu "tính sẵn sàng và dự phòng CAO NHẤT có thể"; multi-region cho mức dự phòng rộng hơn.
A (regional) — dữ liệu chỉ trong MỘT Region; mất Region đó là không truy cập được.
C (zonal) — Cloud Storage KHÔNG có kiểu vị trí zonal.

Ghi nhớ

⚠ Ba kiểu vị trí bucket — bảng phải thuộc: | Kiểu | Phạm vi | SLA sẵn sàng (Standard) | Giá | |---|---|---|---| | Region | một Region | 99,9% | rẻ nhất | | Dual-region | hai Region cụ thể | 99,95% | trung bình | | Multi-region | nhiều Region trong một khu vực | 99,95% | đắt nhất | | Điểm chung | cùng độ bền 11 số 9 | | ⚠ Bẫy | KHÔNG có kiểu "zonal" cho Cloud Storage | | ⚠ Bẫy | vị trí KHÔNG ĐỔI ĐƯỢC sau khi tạo |

Từ khoá nhận diện:

"chịu được mất cả một Region, sẵn sàng cao nhất" → multi-region "hai Region cụ thể, độ trễ thấp ở cả hai" → dual-region "người dùng ở một khu vực, tối ưu chi phí" → region "phục vụ toàn cầu nhanh" → multi-region + Cloud CDN "dữ liệu phải ở trong một nước" → region cụ thể

Độ bền ↔ độ sẵn sàng — đừng lẫn	Nội dung
Độ bền (durability)	dữ liệu KHÔNG BỊ MẤT — 11 số 9 ở mọi kiểu
Độ sẵn sàng (availability)	truy cập được khi cần
Multi-region cải thiện	độ SẴN SÀNG, không phải độ bền
Regional cũng	nhân bản qua các zone — an toàn trước hỏng một zone
Kết luận	chọn vị trí là chọn mức SẴN SÀNG và GIÁ

Với dữ liệu tài chính — cân nhắc thêm	Cân nhắc
Chủ quyền dữ liệu	multi-region trải qua nhiều nước
Nếu quy định bắt ở một nước	→ region cụ thể + dual-region trong nước nếu có
CMEK	tự quản khoá
Bucket Lock	bất biến cho dữ liệu tuân thủ
Audit log	Data Access log

Đừng quên các lớp dự phòng khác	Lớp
Object Versioning	chống ghi đè và xoá nhầm
Retention policy	chống xoá sớm
Sao lưu sang bucket khác	Storage Transfer Service
Kiểm thử khôi phục	quan trọng nhất
Nhắc nhở	multi-region không chống được lỗi CON NGƯỜI

Vị trí không đổi được — hệ quả	Hệ quả
Muốn đổi	tạo bucket mới + sao chép toàn bộ
Chi phí	phí truyền dữ liệu và thao tác
Thời gian	với dữ liệu lớn có thể rất lâu
Vì vậy	quyết định đúng NGAY LẦN ĐẦU
Công cụ chuyển	Storage Transfer Service

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket ở đâu | gcloud storage buckets describe gs://b --format="value(location)" | | Kiểu vị trí là gì | cùng lệnh → locationType | | Có bản sao dự phòng không | rà soát chiến lược sao lưu |

Và một điều đáng nhắc khi bàn về "sẵn sàng cao nhất": multi-region bảo vệ khỏi sự cố HẠ TẦNG, không bảo vệ khỏi lỗi CON NGƯỜI. Một lệnh xoá nhầm sẽ được nhân bản đi khắp mọi Region cũng nhanh như dữ liệu — nên Object Versioning và retention policy vẫn là những lớp không thể thiếu bên cạnh lựa chọn vị trí.

Câu 210 Data Pipeline Orchestration

A development team needs to automatically trigger a serverless Cloud Run service every time a new image file (with a .jpg suffix) is uploaded to a specific Cloud Storage bucket. They want to use a managed, event-driven architecture.

Which Google Cloud service should they use to create the trigger that connects the Cloud Storage event to the Cloud Run service?

A Cloud Tasks
B Cloud Composer
C Cloud Scheduler
D Eventarc

Xem giải thích

Đáp án

D — Eventarc.

Vì sao đúng

Đề hỏi rõ: dịch vụ nào dùng để TẠO TRIGGER nối sự kiện Cloud Storage tới một dịch vụ Cloud Run. Eventarc là lớp định tuyến sự kiện của Google Cloud cho đúng việc đó.

⚠ Điểm mấu chốt — Eventarc là cầu nối sự kiện:

Cloud Storage: tệp .jpg được tải lên
        ↓
    Sự kiện google.cloud.storage.object.v1.finalized
        ↓
    EVENTARC TRIGGER
        ↓
    Gọi Cloud Run service qua HTTP
      (kèm OIDC token, định dạng CloudEvents)
        ↓
    ⚠ Được quản lý hoàn toàn
    ⚠ Không phải tự dựng cầu nối

⚠ Tạo trigger:

gcloud eventarc triggers create trigger-anh \
  --destination-run-service=xu-ly-anh \
  --destination-run-region=asia-southeast1 \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=bucket-anh" \
  --service-account=sa@du-an.iam.gserviceaccount.com
        ↓
    ⚠ Bộ lọc theo BUCKET và LOẠI SỰ KIỆN
    ⚠ KHÔNG lọc được theo ĐUÔI TỆP
      → lọc `.jpg` NGAY TRONG mã Cloud Run

⚠ Eventarc so với các cách khác:

EVENTARC
    → chuẩn hoá sự kiện (CloudEvents)
    → hơn 130 nguồn: GCS, Pub/Sub,
      Firestore, audit log của mọi dịch vụ
    → đích: Cloud Run, Cloud Run functions,
      Workflows, GKE
        ↓
    ⚠ Bên dưới vẫn dùng Pub/Sub,
      nhưng bạn không phải quản lý

Xem thêm câu #12912 (lô 133) và #13023 (lô 136): hai câu đó hỏi CHỌN DỊCH VỤ XỬ LÝ cho tác vụ nhẹ theo sự kiện → khoá là Cloud Run function. Câu này hỏi CƠ CHẾ TRIGGER nối sự kiện tới Cloud Run → Eventarc. Ba câu không mâu thuẫn: hai câu về "chạy cái gì", một câu về "kích hoạt bằng gì".

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

C (Cloud Scheduler) — đây là phương án gần nhất trong nhóm "kích hoạt dịch vụ", nhưng nó kích hoạt theo LỊCH cron, không phản ứng theo sự kiện.
B (Cloud Composer) — công cụ ĐIỀU PHỐI luồng nhiều bước; quá nặng và không phải cơ chế trigger sự kiện.
A (Cloud Tasks) — hàng đợi TÁC VỤ có kiểm soát tốc độ; bạn tự đẩy tác vụ vào, nó không tự nhận sự kiện từ Cloud Storage.

Ghi nhớ

⚠ Bốn cách kích hoạt một dịch vụ — bảng phải thuộc: | Cách kích hoạt | Công cụ | |---|---| | Theo SỰ KIỆN của dịch vụ GCP | Eventarc | | Theo LỊCH (cron) | Cloud Scheduler | | Theo thông điệp hàng đợi | Pub/Sub | | Tác vụ có kiểm soát tốc độ | Cloud Tasks | | Luồng nhiều bước có phụ thuộc | Cloud Composer / Workflows |

Từ khoá nhận diện:

"khi tệp được tải lên thì gọi Cloud Run" → Eventarc "đúng giờ mỗi ngày" → Cloud Scheduler "hàng đợi, kiểm soát tốc độ gửi" → Cloud Tasks "nhiều bước phụ thuộc" → Cloud Composer "tác vụ nhẹ theo sự kiện, chọn dịch vụ nào" → Cloud Run function

Eventarc — điều cần nhớ	Nội dung
Chuẩn	CloudEvents
Nguồn sự kiện	GCS, Pub/Sub, Firestore, và audit log của hơn 130 dịch vụ
Đích	Cloud Run, Cloud Run functions, Workflows, GKE
Bộ lọc	theo type, bucket, thuộc tính khác
Xác thực	OIDC token tới đích
Bên dưới	dùng Pub/Sub, nhưng được quản lý

Các sự kiện Cloud Storage	Sự kiện
`object.v1.finalized`	tệp mới ghi xong — hay dùng nhất
`object.v1.deleted`	tệp bị xoá
`object.v1.archived`	phiên bản bị lưu trữ
`object.v1.metadataUpdated`	metadata đổi
⚠ Lưu ý	`finalized` cũng phát khi GHI ĐÈ
⚠ Lưu ý	KHÔNG lọc được theo đuôi tệp ở trigger

Ba cái bẫy của kiến trúc hướng sự kiện	Bẫy
Sự kiện có thể tới NHIỀU LẦN	xử lý phải BẤT BIẾN
Ghi kết quả lại vào chính bucket đó	VÒNG LẶP VÔ TẬN
Nhiều tệp cùng lúc	hàng nghìn instance — dùng `--max-instances`
Không lọc được đuôi tệp	lọc ngay đầu hàm
Phòng ngừa	ghi kết quả sang bucket KHÁC

Quyền cần cho Eventarc	Quyền
Service account của trigger	`roles/run.invoker` trên dịch vụ đích
`roles/eventarc.eventReceiver`	nhận sự kiện
Service agent của Cloud Storage	`roles/pubsub.publisher`
Bật API	Eventarc, Pub/Sub, Cloud Run
Thiếu quyền	trigger tạo được nhưng sự kiện không tới

Cloud Run function trigger ↔ Eventarc	Nội dung
Cloud Run functions gen2	dùng Eventarc bên dưới
Khai bằng	`--trigger-event-filters` khi deploy hàm
Với Cloud Run service	phải tạo Eventarc trigger tường minh
Kết luận	Eventarc là cơ chế chung
Đề này	đích là Cloud Run service → Eventarc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trigger cấu hình thế nào | gcloud eventarc triggers describe <ten> --location=<r> | | Sự kiện có tới không | log của Cloud Run service | | Vì sao không tới | kiểm tra roles/run.invoker của service account |

Và một chi tiết phải xử lý ngay trong mã, vì trigger không làm thay được: lọc theo đuôi tệp. Eventarc lọc được theo bucket và loại sự kiện, nhưng không theo .jpg — nên dòng đầu tiên của dịch vụ Cloud Run luôn nên là một phép kiểm tra tên tệp, kèm việc thoát sớm nếu không khớp.

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

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ