Ngân hàng đề — Google Cloud Professional Data Engineer

🧩 Giải thích nội dung câu hỏi

Câu hỏi tập trung vào tình huống tổ chức lưu trữ dữ liệu cá nhân nhạy cảm cao trong BigQuery (Google Cloud Platform) và phải tuân thủ các quy định bảo mật dữ liệu nghiêm ngặt (như GDPR hoặc tương tự). Yêu cầu chính là đảm bảo dữ liệu nhạy cảm trở nên không thể đọc được (unreadable) ngay khi một nhân viên rời khỏi tổ chức. Điều này ngụ ý cần một cơ chế vĩnh viễn và không thể đảo ngược để bảo vệ dữ liệu, tránh tình trạng nhân viên cũ có thể truy cập hoặc khôi phục dữ liệu sau này. Không chỉ dừng ở việc thu hồi quyền truy cập, mà phải làm dữ liệu bị vô hiệu hóa hoàn toàn về mặt nội dung.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Use AEAD functions and delete keys when employees leave the organization.

Lý do:
AEAD (Authenticated Encryption with Associated Data) là các hàm mã hóa mạnh mẽ trong BigQuery (như AEAD.ENCRYPT và AEAD.DECRYPT), cho phép mã hóa dữ liệu nhạy cảm ngay trong các cột bảng một cách client-side hoặc deterministic. Khi nhân viên rời đi, chỉ cần xóa khóa mã hóa (key) là dữ liệu nhạy cảm sẽ vĩnh viễn không thể giải mã, trở nên hoàn toàn unreadable mà không ảnh hưởng đến dữ liệu khác. Đây là cách chính xác, linh hoạt và tuân thủ quy định vì mã hóa diễn ra ở mức dữ liệu cụ thể, không phụ thuộc vào quyền truy cập. Phương pháp này được khuyến nghị trong tài liệu BigQuery Security mới nhất (cập nhật 2024-2026) cho các trường hợp bảo mật cao.
📘 Nguồn tham khảo: BigQuery AEAD Encryption Documentation và BigQuery Security Best Practices.

🛠️ Phân tích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên nội dung văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên tính năng BigQuery phiên bản mới nhất (2026):

• ❌ Use column-level access controls with policy tags and revoke viewer permissions when employees leave the organization.
  Sai vì: Column-level access controls (sử dụng policy tags qua Data Catalog) chỉ hạn chế quyền truy cập cột dữ liệu, không làm dữ liệu unreadable. Thu hồi quyền (revoke viewer permissions) chỉ ngăn truy cập mới, nhưng nếu nhân viên cũ đã export dữ liệu trước đó, họ vẫn đọc được. Không đáp ứng yêu cầu "rendered unreadable" vĩnh viễn.

• ❌ Use dynamic data masking and revoke viewer permissions when employees leave the organization.
  Sai vì: BigQuery không hỗ trợ dynamic data masking native như AWS Redshift hoặc Snowflake (mặc dù có thể dùng DLP API để mask tĩnh). Kết hợp với revoke permissions chỉ ẩn dữ liệu tạm thời khi truy vấn, không làm dữ liệu gốc unreadable. Nhân viên cũ vẫn có thể truy cập dữ liệu đầy đủ nếu có quyền trước, vi phạm quy định bảo mật nghiêm ngặt.

• ❌ Use customer-managed encryption keys (CMEK) and delete keys when employees leave the organization.
  Sai vì: CMEK mã hóa toàn bộ dataset/table tại rest qua Cloud KMS. Xóa key làm toàn bộ dữ liệu unreadable (không chỉ sensitive data), gây gián đoạn lớn cho tổ chức. Không linh hoạt cho trường hợp "khi employee leaves" (cần targeted), và BigQuery khuyến nghị CMEK cho bảo mật chung chứ không phải per-employee.

• ✅ Use AEAD functions and delete keys when employees leave the organization.
  Đúng vì: Như đã giải thích ở trên, AEAD cho phép mã hóa chi tiết dữ liệu nhạy cảm trong cột, lưu key riêng biệt. Xóa key làm dữ liệu không thể giải mã vĩnh viễn, lý tưởng cho compliance. Hoàn hảo cho highly personal data mà không ảnh hưởng hệ thống lớn.
  🧩 Lưu ý bổ sung: Kết hợp với IAM và audit logs để theo dõi (theo best practices 2026).

🧩 Phân tích chi tiết câu hỏi

Câu hỏi tập trung vào việc thiết kế kế hoạch khôi phục thảm họa (Disaster Recovery - DR) cho dữ liệu bán hàng quan trọng được lưu trữ trong BigQuery dataset tại vùng us-central1 (Google Cloud).

• Yêu cầu chính:
  • Khôi phục dữ liệu sang vùng us-east1 nếu us-central1 bị gián đoạn.
  • RPO (Recovery Point Objective) = 24 giờ: Mức độ mất dữ liệu tối đa là 24 giờ (tức là dữ liệu mới nhất có thể mất không quá 1 ngày).
  • RTO (Recovery Time Objective) = 4 giờ: Thời gian khôi phục hệ thống tối đa là 4 giờ.
  • Ràng buộc: Giữ chi phí thấp nhất và độ phức tạp thấp nhất (minimum costs and complexity).

Mục tiêu là chọn giải pháp đơn giản, rẻ tiền, phù hợp với RPO/RTO mà không cần kiến trúc phức tạp như streaming real-time. Đây là tình huống thực tế trong Google Cloud BigQuery, nơi dữ liệu regional cần DR cross-region. (📘 Tài liệu tham khảo: BigQuery Disaster Recovery Best Practices và BigQuery Multi-Region Considerations, cập nhật đến 2026 với BigQuery v2.0+ hỗ trợ export/load nhanh hơn).

✅ Đáp án đúng: Manually export data to a CSV file in a multi-regional Cloud Storage bucket daily and use bq load to restore to us-east1.

Lý do chọn đáp án này:

• Phù hợp RPO 24h: Export hàng ngày (daily) đảm bảo mất dữ liệu ≤24h.
• Phù hợp RTO 4h: Sử dụng bq load (lệnh CLI BigQuery) để import từ CSV trong multi-regional Cloud Storage bucket (như us hoặc dual-region) rất nhanh – thường hoàn thành trong vài giờ tùy kích thước dữ liệu, dễ tự động hóa bằng Cloud Scheduler hoặc cron job.
• Chi phí & complexity thấp nhất 🛠️:
  • Export thủ công hoặc scheduled miễn phí (BigQuery storage read chỉ tính phí nhỏ).
  • Cloud Storage multi-regional rẻ (standard class), không cần Pub/Sub hay replication tự động.
  • Không yêu cầu kiến trúc phức tạp như streaming hay API liên tục.
• Đây là giải pháp best practice cho DR low-cost trong BigQuery regional datasets (không phải multi-region). (📘 Nguồn: BigQuery Export/Import Guide, DR Planning).

📋 Giải thích tất cả các phương án

• Set up continuous queries and Pub/Sub to stream data changes from BigQuery tables in us-central1 to us-east1. ❌
  Sai vì: Giải pháp này quá phức tạp và tốn kém. BigQuery không hỗ trợ "continuous queries" native (phải dùng Scheduled Queries + Pub/Sub notifications, nhưng không stream changes real-time hiệu quả). Pub/Sub tính phí theo volume, cộng với Dataflow/Cloud Functions để process – vượt RTO/RPO cần thiết (real-time không cần cho RPO 24h). Tăng complexity cao, chi phí hàng tháng lớn (không "minimum"). (🛠️ Không phù hợp low-cost).

• Manually export data to a CSV file in a multi-regional Cloud Storage bucket daily and use bq load to restore to us-east1. ✅
  Đúng vì: Như giải thích trên – đơn giản (export bq extract, load bq load), low-cost (chỉ phí storage ~$0.02/GB/tháng multi-regional), RPO/RTO đạt yêu cầu. Multi-regional bucket đảm bảo data accessible cross-region ngay lập tức. Best cho DR manual/low-frequency.

• Configure BigQuery cross-region dataset replication from us-central1 to us-east1. ❌
  Sai vì: BigQuery không hỗ trợ cross-region replication giữa hai regional datasets khác nhau (us-central1 → us-east1). Replication chỉ áp dụng cho multi-regional datasets (tự replicate across zones trong cùng multi-region như "US"), không phải copy thủ công cross-region cụ thể. Nếu dùng, phải migrate dataset sang multi-regional từ đầu (tăng complexity/cost). Không match "minimum complexity". (📘 Nguồn: BigQuery Replication Limits, cập nhật 2026: Vẫn chỉ intra-multi-region).

• Take daily BigQuery table snapshots in us-central1. ❌
  Sai vì: Snapshot (time-travel) chỉ lưu trong us-central1, không giúp restore sang us-east1 nếu region outage. Snapshot bị ảnh hưởng bởi outage primary region, không cross-region. Phải export snapshot thủ công mới dùng được, nhưng vẫn thiếu multi-region storage – không giải quyết DR đầy đủ, complexity tương đương nhưng kém hiệu quả hơn export CSV. (🛠️ Nguồn: BigQuery Table Snapshots).

🧩 Phân tích nội dung câu hỏi

Câu hỏi tập trung vào việc phát triển mô hình phát hiện gian lận (fraud detection) sử dụng BigQuery ML trên Google Cloud. Bạn có bộ dữ liệu giao dịch thô (raw transaction dataset) và cần tạo các đặc trưng mới (features) như:

• average_transaction_amount_last_24_hours: Trung bình số tiền giao dịch trong 24 giờ qua (yêu cầu tính tổng hợp - aggregation).
• time_since_last_transaction: Thời gian kể từ giao dịch cuối cùng (yêu cầu tính toán cửa sổ thời gian - time-window calculations).

Mục tiêu chính là đảm bảo các features này được áp dụng nhất quán (consistent) trong cả giai đoạn huấn luyện mô hình (training) và dự đoán (prediction), mà không cần can thiệp thủ công (manual intervention). Phương pháp phải hiệu quả (efficient) để chuẩn bị features cho mô hình.
📌 Thách thức cốt lõi: Xử lý aggregation và window functions trên dữ liệu thời gian thực tế, tận dụng sức mạnh SQL của BigQuery mà không làm phức tạp pipeline.

✅ Đáp án đúng

Use the TRANSFORM clause within the CREATE MODEL statement, leveraging SQL functions for aggregations and time-based calculations.

Lý do lựa chọn 🛠️:
TRANSFORM clause trong BigQuery ML (cú pháp CREATE MODEL ... TRANSFORM (...)) cho phép định nghĩa trực tiếp các features phức tạp bằng SQL ngay trong lệnh tạo mô hình. Nó hỗ trợ đầy đủ aggregation (AVG, SUM), window functions (OVER với PARTITION BY thời gian), và các hàm thời gian (TIMESTAMP_DIFF).

• Nhất quán tự động: BigQuery ML áp dụng chính xác cùng logic TRANSFORM cho cả training và serving (prediction), không cần join thủ công hay trigger riêng.
• Hiệu quả cao: Chạy hoàn toàn trong BigQuery, không export/import dữ liệu, tận dụng engine phân tán.
• Cập nhật 2026: Vẫn là best practice theo docs GCP mới nhất (BigQuery ML v2.x), hỗ trợ advanced features như time-series forecasting và fraud detection.
  📘 Nguồn tham khảo: BigQuery ML CREATE MODEL - TRANSFORM clause và Feature engineering in BigQuery ML.

📋 Giải thích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn, với ✅ đúng hoặc ❌ sai, kèm lý do cụ thể dựa trên best practices BigQuery ML:

• ❌ Implement a Cloud Run function that triggers on new transactions, calculates the features, and inserts them into a feature store before model serving.
  Phương án này sử dụng Cloud Run (serverless function) kích hoạt bởi Pub/Sub hoặc Eventarc trên giao dịch mới, tính features rồi lưu vào Feature Store (Vertex AI).
  Tại sao sai 🚫: Phức tạp, yêu cầu code custom (Python/SQL), dễ lỗi nhất quán giữa training/serving (batch vs streaming). Không "hiệu quả" cho BigQuery ML vì bỏ qua SQL native, tăng chi phí và latency. Không tự động cho historical data training.

• ❌ Export the BigQuery data to Cloud Storage, perform feature engineering using a custom Python script in a Dataflow job, and then re-import the engineered features into BigQuery.
  Xuất dữ liệu BigQuery ra GCS, dùng Dataflow (Apache Beam) với script Python tính features, rồi import lại.
  Tại sao sai 🚫: Quá nặng nề (heavyweight pipeline) cho task SQL đơn giản. Yêu cầu manual export/import, dễ lệch dữ liệu giữa training/prediction (staleness). Dataflow phù hợp big data ETL, không optimal cho BigQuery ML – vi phạm "không manual intervention" và kém hiệu quả chi phí.

• ✅ Use the TRANSFORM clause within the CREATE MODEL statement, leveraging SQL functions for aggregations and time-based calculations.
  Sử dụng TRANSFORM trong CREATE MODEL, tận dụng SQL cho aggregation/window calcs.
  Tại sao đúng 🏆: Xem phần "Đáp án đúng" ở trên. Đây là giải pháp native, scalable, consistent 100% cho BigQuery ML fraud models (ví dụ: TRANSFORM(AVG(amount) OVER (PARTITION BY user_id ORDER BY timestamp ROWS BETWEEN 1000 PRECEDING AND CURRENT ROW)).

• ❌ Create a separate BigQuery table containing pre-computed features using complex SQL queries and join this table with the raw data during model training and serving.
  Tạo bảng BigQuery riêng pre-compute features bằng SQL phức tạp, rồi JOIN với raw data khi train/serve.
  Tại sao sai 🚫: Yêu cầu JOIN thủ công mỗi lần train/predict, dễ không nhất quán (ví dụ: window calc lệch nếu dữ liệu update). Phải schedule materialized view hoặc query lặp lại – vẫn cần "manual intervention" gián tiếp. Không tận dụng BigQuery ML optimization, kém hiệu quả hơn TRANSFORM.

Kết luận 🎯: TRANSFORM clause là lựa chọn tối ưu, giúp pipeline đơn giản, scalable cho fraud detection real-time! Nếu cần ví dụ code SQL cụ thể, hãy hỏi thêm.

🧩 Phân tích nội dung câu hỏi

Câu hỏi mô tả một hệ thống xử lý giao dịch tài chính với các yêu cầu chính:

• Xử lý throughput cao (lượng lớn hoạt động đồng thời từ người dùng).
• Đọc/ghi độ trễ thấp (low-latency reads and writes) cho từng bản ghi riêng lẻ (individual records).
• Đảm bảo tuân thủ ACID (Atomicity, Consistency, Isolation, Durability) cho các giao dịch được xử lý.
• Sử dụng dịch vụ được quản lý bởi Google Cloud (Google Cloud managed service).

Mục tiêu là chọn giải pháp lưu trữ phù hợp nhất, tập trung vào cơ sở dữ liệu hỗ trợ giao dịch thời gian thực, mở rộng quy mô ngang (horizontal scaling), và tính nhất quán mạnh (strong consistency) – đặc biệt quan trọng cho ứng dụng tài chính nhạy cảm. Đây là câu hỏi trắc nghiệm điển hình trong kỳ thi Google Cloud Professional Data Engineer, kiểm tra kiến thức về các dịch vụ lưu trữ NoSQL/NewSQL của Google Cloud (cập nhật đến phiên bản Cloud Spanner v2.x năm 2026, hỗ trợ multi-region replication tự động).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Select Spanner.
🛠️ Lý do chi tiết: Cloud Spanner là dịch vụ cơ sở dữ liệu quan hệ phân tán toàn cầu (globally distributed relational database) được Google quản lý hoàn toàn, hỗ trợ ACID transactions đầy đủ (bao gồm multi-row transactions với TrueTime cho consistency mà không cần locking truyền thống). Nó xử lý high throughput concurrent operations với low-latency reads/writes (sub-10ms cho single-region, <100ms cross-region), tự động scale horizontally lên hàng triệu QPS. Hoàn hảo cho workload tài chính yêu cầu độ tin cậy cao, replication tự động (3+ replicas), và SQL chuẩn. Không có dịch vụ Google Cloud nào khác đáp ứng đầy đủ cả 4 tiêu chí này cùng lúc.

📋 Giải thích tất cả các phương án

Dưới đây là phân tích từng lựa chọn một cách chi tiết, dựa trên đặc tính kỹ thuật mới nhất (Google Cloud 2026):

• [SAI] Select Bigtable.
  ❌ Sai vì: Bigtable là NoSQL wide-column store tối ưu cho high-throughput sequential reads/writes (hàng triệu ops/sec), nhưng không hỗ trợ ACID transactions (chỉ single-row atomicity, không có multi-row transactions hoặc isolation đầy đủ). Nó phù hợp cho analytics lớn (như time-series data), nhưng không đảm bảo consistency cho giao dịch tài chính concurrent, dễ gặp race conditions. Không phải lựa chọn cho low-latency transactional workload.

• [SAI] Select BigQuery.
  ❌ Sai vì: BigQuery là data warehouse serverless cho phân tích lớn (analytics queries), hỗ trợ high-throughput batch processing nhưng không phải transactional database – thiếu ACID compliance, reads/writes có độ trễ cao hơn (seconds cho queries), và không hỗ trợ real-time updates/low-latency per-record operations. Chỉ dùng cho reporting, không phải OLTP (Online Transaction Processing) như giao dịch tài chính.

• [SAI] Select Cloud Storage.
  ❌ Sai vì: Cloud Storage là object storage cho dữ liệu không cấu trúc (files/blobs), hỗ trợ high-throughput cho uploads/downloads lớn nhưng hoàn toàn không hỗ trợ ACID transactions hay low-latency per-record reads/writes (strong consistency chỉ cho single object overwrite, không cho concurrent ops). Không có schema hay indexing, không phù hợp cho structured transactional records.

• [ĐÚNG] Select Spanner.
  ✅ Đúng vì: Như đã giải thích ở trên, Spanner đáp ứng toàn bộ yêu cầu: ACID full, low-latency (P99 <10ms reads trong region), high concurrent throughput (scale đến 10k+ nodes), managed service với global replication. Hỗ trợ SQL, auto-sharding, và backup tự động – lý tưởng cho financial transactions.

📘 Tài liệu tham khảo

• Cloud Spanner Transactions: cloud.google.com/spanner/docs/transactions (ACID & TrueTime).
• Bigtable vs Spanner Comparison: cloud.google.com/products/databases (cập nhật 2026).
• Google Cloud Data Engineer Exam Guide: cloud.google.com/learn/certification/guides/data-engineer – Phần "Choose Storage Solutions".
• Spanner Performance Benchmarks: cloud.google.com/spanner/docs/performance (low-latency metrics 2026).

Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀 Nếu cần ví dụ code hoặc case study, hãy hỏi thêm.

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào vấn đề training-serving skew (sự lệch lạc giữa dữ liệu huấn luyện và dữ liệu phục vụ) trong quy trình triển khai mô hình học máy trên Google Cloud Vertex AI Endpoints.

• Bối cảnh: Bạn đang chuẩn bị dữ liệu cho mô hình dự đoán nhu cầu bán hàng (sales demand prediction). Dữ liệu huấn luyện (training data) đã qua các bước tiền xử lý (pre-processing) bao gồm:
  • Scaling các đặc trưng số (numerical features) – ví dụ: chuẩn hóa về khoảng [0,1] hoặc z-score.
  • One-hot encoding các đặc trưng phân loại (categorical features) – chuyển đổi thành vector nhị phân.
• Mô hình: Đã được triển khai (deployed) trên Vertex AI Endpoints để phục vụ dự đoán thời gian thực (inference/production).
• Yêu cầu chính:
  • Ngăn chặn training-serving skew để đảm bảo dự đoán chính xác (accurate predictions).
  • Giải pháp phải dễ triển khai (easy to implement).

Training-serving skew xảy ra khi dữ liệu đầu vào phục vụ khác biệt về phân phối hoặc định dạng so với dữ liệu huấn luyện, dẫn đến mô hình dự đoán kém. Giải pháp cần đảm bảo dữ liệu phục vụ được xử lý giống hệt như dữ liệu huấn luyện trước khi đưa vào mô hình. Theo best practices của Vertex AI (cập nhật đến 2026), Vertex AI hỗ trợ pipelines cho cả training và inference, nhấn mạnh việc tái sử dụng logic pre-processing để tránh skew.

📘 Tài liệu tham khảo:

• Vertex AI Documentation: Prevent training-serving skew (Google Cloud, cập nhật 2025).
• Vertex AI Pipelines Best Practices – Khuyến nghị replicate pre-processing trong inference pipeline.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Replicate the exact same pre-processing logic in the inference pipeline that was used during model training.

Lý do 🛠️:

• Đây là giải pháp tiêu chuẩn và dễ triển khai nhất trên Vertex AI. Bạn chỉ cần sao chép (replicate) chính xác logic pre-processing (scaling + one-hot encoding) từ pipeline huấn luyện vào pipeline inference (sử dụng Vertex AI Pipelines hoặc custom container).
• Đảm bảo dữ liệu phục vụ có phân phối và định dạng giống hệt dữ liệu huấn luyện, loại bỏ hoàn toàn training-serving skew.
• Vertex AI hỗ trợ tích hợp dễ dàng qua Kubeflow Pipelines hoặc TensorFlow/PyTorch serving, không cần code phức tạp. Theo tài liệu 2025-2026, đây là recommended approach cho production MLOps.

📋 Giải thích tất cả các phương án (đúng/sai)

• ❌ [SAI] Implement a custom handler within the Vertex AI Endpoint to automatically perform data transformations before the model makes a prediction.
  Giải thích: Phương án này phức tạp và không dễ triển khai (vi phạm yêu cầu "easy to implement"). Custom handler yêu cầu phát triển code riêng (ví dụ: Python handler trong container), dễ gây lỗi và khó maintain. Vertex AI khuyến nghị tránh custom handler cho pre-processing đơn giản; thay vào đó dùng pipeline chuẩn để replicate logic.

• ✅ [ĐÚNG] Replicate the exact same pre-processing logic in the inference pipeline that was used during model training.
  Giải thích: Như đã phân tích ở trên, đây là cách tối ưu, dễ dàng và scalable. Sử dụng Vertex AI Pipelines để chain các bước pre-processing giống hệt training (ví dụ: TensorFlow Transform hoặc custom components), đảm bảo consistency 100%. Hỗ trợ auto-scaling và monitoring skew qua Vertex AI Model Monitoring (cập nhật 2026).

• ❌ [SAI] Store the raw, unprocessed data in a separate Cloud Storage bucket exclusively for serving.
  Giải thích: Lưu dữ liệu thô (raw) riêng chỉ làm tăng skew vì dữ liệu phục vụ vẫn cần pre-processing giống training, nhưng cách này không chỉ rõ cách xử lý. Dễ gây nhầm lẫn định dạng và tốn chi phí storage không cần thiết; không giải quyết vấn đề cốt lõi.

• ❌ [SAI] Ensure the serving data is a smaller, random sample of the training data.
  Giải thích: Sampling ngẫu nhiên (random sample nhỏ hơn) không liên quan đến pre-processing và có thể làm lệch phân phối dữ liệu, tăng skew thay vì giảm. Serving data thường là dữ liệu mới (real-time), không phải sample từ training; cách này không đảm bảo định dạng giống hệt (scaling/one-hot).

🧠 Kết luận: Tập trung replicate pre-processing là chìa khóa MLOps trên Vertex AI để production-ready! 🚀

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi xoay quanh vấn đề tối ưu hóa chi phí phân tích trên BigQuery (dịch vụ kho dữ liệu của Google Cloud). Công ty bán lẻ lo ngại về chi phí chạy query trên BigQuery, vì họ thường xuyên thực hiện các truy vấn lặp lại cùng một phép tổng hợp (aggregation) trên store ID (ID cửa hàng) và real-time sales volume (khối lượng bán hàng thời gian thực).
📊 Yêu cầu chính: Triển khai giải pháp tối ưu nhất để giảm chi phí phân tích (analytics spend) và trả về kết quả nhanh hơn.
🛠️ Bối cảnh: BigQuery tính phí dựa trên lượng bytes quét (scanned bytes), nên cần tránh lặp lại tính toán aggregation phức tạp trên dữ liệu lớn, đặc biệt với dữ liệu real-time.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Create a materialized view to minimize repetitive computations.

Lý do:
Materialized View trong BigQuery là một bảng vật lý hóa lưu trữ kết quả của query aggregation phức tạp (như trên store ID và sales volume). Nó tự động cập nhật khi dữ liệu nguồn thay đổi, giúp:

• 🚀 Giảm thời gian query bằng cách đọc trực tiếp từ view đã tính toán sẵn (không quét lại toàn bộ dữ liệu).
• 💰 Giảm chi phí vì chỉ tính phí lưu trữ view (rẻ hơn) và query trên view nhỏ gọn, tránh lặp lại aggregation trên dữ liệu real-time lớn.
  Theo tài liệu BigQuery cập nhật 2024-2026, Materialized Views hỗ trợ incremental refresh cho dữ liệu streaming/real-time, lý tưởng cho trường hợp này.

📘 Nguồn tham khảo:

• BigQuery Materialized Views Intro
• Best Practices for Cost Optimization (cập nhật 2025).

🔍 Giải thích tất cả các phương án (đúng/sai)

• [SAI] Create a new table from a CSV file with the repeated aggregation for the other queries to reference for faster processing.
  ❌ Sai vì: Tạo bảng mới từ CSV chỉ phù hợp dữ liệu tĩnh, không hỗ trợ real-time sales volume (dữ liệu streaming). Phải thủ công cập nhật CSV định kỳ → không tự động, dễ lỗi, và vẫn tốn chi phí quét dữ liệu gốc nếu aggregation thay đổi. Không tối ưu cho BigQuery real-time.

• [ĐÚNG] Create a materialized view to minimize repetitive computations.
  ✅ Đúng vì: Như giải thích ở trên, đây là giải pháp tối ưu nhất của BigQuery cho aggregation lặp lại. View tự động refresh (base refresh hoặc incremental), giảm scanned bytes lên đến 99% cho query phức tạp, phù hợp dữ liệu real-time từ Pub/Sub hoặc Streaming Inserts.

• [SAI] Use join acceleration with primary and foreign keys to increase query joining to live data.
  ❌ Sai vì: BigQuery không có tính năng "join acceleration" chính thức dựa trên primary/foreign keys (khác với một số RDBMS). Join trên live data vẫn quét toàn bộ, không giải quyết aggregation lặp lại. Thay vào đó, BigQuery dùng clustering/partitioning cho join, nhưng không phải "acceleration" như mô tả.

• [SAI] Leverage partitioning to minimize the number of bytes read.
  ❌ Sai vì: Partitioning (theo ngày/giờ) giúp giảm bytes quét cho query lọc thời gian, nhưng không trực tiếp tối ưu aggregation lặp lại trên store ID/sales. Vẫn phải tính toán aggregation mỗi lần query → chi phí cao với real-time data. Kết hợp partitioning + materialized view mới lý tưởng, nhưng partitioning đơn lẻ chưa đủ.

🧠 Kết luận: Materialized View là "vũ khí bí mật" của BigQuery cho workload analytics lặp lại, giúp tiết kiệm chi phí dài hạn! 🚀

🧩 Giải thích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào chiến lược quản trị dữ liệu (data governance) cho một bảng BigQuery mới chứa dữ liệu y tế (medical) và tài chính (financial) nhạy cảm. Mục tiêu là xây dựng giải pháp có khả năng mở rộng (scalable), đảm bảo:

• Nhà nghiên cứu lâm sàng (clinical researchers) chỉ truy cập dữ liệu y tế của bệnh nhân mà không có thông tin tài chính.
• Đội ngũ kế toán (accounting team) chỉ truy cập dữ liệu tài chính với các định danh bệnh nhân tối thiểu (minimal patient identifiers).

Vấn đề cốt lõi là phân tách quyền truy cập tinh tế (fine-grained access control) trên cùng một nguồn dữ liệu, tránh rò rỉ thông tin nhạy cảm, đồng thời dễ quản lý và mở rộng theo quy mô dữ liệu lớn trong BigQuery (Google Cloud). Giải pháp cần tận dụng các tính năng native của BigQuery như IAM, views, datasets để tuân thủ nguyên tắc least privilege và data masking/anonymization.

📘 Kiến thức cập nhật đến 2026: BigQuery (phiên bản mới nhất hỗ trợ Authorized Views với dynamic SQL, row/column filtering qua policies từ 2021+, và integration với Data Catalog cho governance). Không phải AWS (có lẽ nhầm lẫn chủ đề), mà là GCP thuần túy.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Create separate datasets with authorized views exposing only approved data.

Lý do 🛠️:

• Authorized Views là tính năng mạnh mẽ nhất của BigQuery để che giấu dữ liệu (data masking) và phân quyền chi tiết mà không cần duplicate dữ liệu gốc. Views được tạo trong datasets riêng biệt, chỉ expose (hiển thị) cột/dòng dữ liệu được phê duyệt (approved data).
• Scalable: Không copy dữ liệu, query trực tiếp từ base table qua views → tiết kiệm storage/cost, dễ maintain joins phức tạp giữa medical/financial data.
• Phù hợp yêu cầu:
  • Researchers: View chỉ select medical columns, filter bỏ financial.
  • Accounting: View select financial columns + minimal PII (e.g., anonymized IDs).
• IAM cấp quyền READ trên dataset chứa views, không chạm base table → an toàn cao.
• Best practice theo GCP cho sensitive data (HIPAA-compliant).

❌ Giải thích tất cả các phương án (đúng và sai)

• [SAI] Implement column-level security policies in BigQuery tables with IAM permissions.
  ❌ Sai vì: BigQuery không hỗ trợ native column-level security policies (như ACL trên từng cột). IAM chỉ control table/dataset level, không filter columns tinh tế. Dùng views để select columns là workaround, nhưng phương án này không scalable và không chính xác theo docs GCP (cập nhật 2026: vẫn chỉ có row-level policies beta, không column-level full).

• [SAI] Create separate tables for personally identifiable information (PII), financial data, and anonymized medical data. Use IAM permissions to control access to each table.
  ❌ Sai vì: Tách table riêng yêu cầu duplicate/anonymize dữ liệu thủ công, dẫn đến không scalable (storage nổ tung với dữ liệu lớn, khó sync changes, phức tạp joins giữa PII/financial/medical). IAM chỉ control table access thô, không linh hoạt cho "minimal patient identifiers" mà không leak data.

• [SAI] Implement row-level security policies in BigQuery tables with IAM permissions.
  ❌ Sai vì: Row-level security (RLS) trong BigQuery (từ 2021+) dùng policies để filter rows dựa condition (e.g., user role), nhưng không đủ cho column separation (researchers vẫn thấy financial columns nếu không filter). IAM bổ trợ nhưng không giải quyết expose chỉ "approved data" tinh tế; kém hiệu quả hơn views cho mixed data types.

• [ĐÚNG] Create separate datasets with authorized views exposing chỉ approved data.
  ✅ Đúng vì (như giải thích trên): Kết hợp datasets riêng + authorized views là giải pháp chuẩn GCP cho governance, hỗ trợ column/row filtering, sharing cross-project, và audit logs. Scalable 100%, zero-copy data.

📚 Tài liệu tham khảo

• GCP Docs: BigQuery Authorized Views (best practice cho data masking).
• GCP Architecture: Data Governance in BigQuery (cập nhật 2025+ với policies).
• Blog GCP: "Fine-grained Access Control with Views" (2023-2026 updates on dynamic views).
• Certification Guide: Google Cloud Professional Data Engineer study guide (Qwiklabs: BigQuery security labs).

Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀 Nếu cần demo code SQL views, hỏi thêm nhé!

🧩 Phân tích nội dung câu hỏi

Câu hỏi mô tả tình huống thiết kế data lake trên Google Cloud để lưu trữ lượng lớn dữ liệu tương tác khách hàng từ nhiều nguồn khác nhau (website, mobile app, social media). Dữ liệu đến ở định dạng đa dạng, cần:

• Catalog hóa nhất quán (ghi nhận metadata để dễ khám phá).
• Dễ dàng khám phá và sử dụng cho data analysts.
• Kiểm tra chất lượng dữ liệu cơ bản và biến đổi dữ liệu trước khi downstream apps sử dụng.
• Giải pháp governance tự động và managed (quản lý dữ liệu, metadata, lineage, quality).

Mục tiêu chính là data governance toàn diện cho data lake, sử dụng các dịch vụ Google Cloud managed, hỗ trợ multi-format data từ Cloud Storage (raw storage) và BigQuery (analytics). Kiến thức cập nhật đến 2026: Dataplex (phiên bản mới nhất với Universal Catalog) là giải pháp lý tưởng cho intelligent data lakehouse, tích hợp cataloging, discovery, quality checks, và transformations tự động. ❌ Không liên quan AWS vì câu hỏi thuần Google Cloud (có thể nhầm lẫn từ người dùng).

📘 Tài liệu tham khảo:

• Dataplex Overview (Google Cloud, cập nhật 2024-2026).
• Dataplex Universal Catalog.
• Data Lakes on Google Cloud.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Use Cloud Storage and BigQuery as repositories. Use Dataplex Universal Catalog for metadata discovery, data quality checks, and transformations.

Lý do 🛠️:

• Cloud Storage + BigQuery là combo chuẩn cho data lake (raw unstructured ở Storage, structured/processed ở BigQuery).
• Dataplex Universal Catalog (phần core của Dataplex) cung cấp metadata discovery tự động, data quality rules (checks qua Data Quality Scans), transformations (qua Dataflows hoặc integrations), và governance managed (lineage, access control, tagging). Hoàn hảo cho dữ liệu đa nguồn/đa format, tự động hóa toàn bộ pipeline mà không cần code custom. Đây là best practice cho data lakehouse trên Google Cloud từ 2023-2026.

📋 Giải thích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên tính năng Google Cloud mới nhất:

• [SAI] Use Cloud Storage as the central repository. Use Vertex AI to classify and process the data and perform data quality checks.
  ❌ Sai vì: Vertex AI tập trung vào ML/AI pipelines (classification, feature processing), không phải data governance/catalog managed. Không hỗ trợ catalog discovery nhất quán cho data lake đa nguồn, thiếu transformations tự động và quality checks governance-level. Phải tự build pipeline, không "automated and managed".

• [SAI] Stream all the data directly into BigQuery, where it is automatically cataloged and governed.
  ❌ Sai vì: BigQuery có Entry catalog nội bộ tốt cho structured data, nhưng không phù hợp data lake đa format/raw (streaming trực tiếp kém hiệu quả với unstructured data từ social/mobile). Thiếu governance toàn diện cho multi-repo (Storage cần thiết cho raw), không có Universal Catalog cross-service. BigQuery governance hạn chế so với Dataplex (không auto-discover metadata ngoài BigQuery).

• [ĐÚNG] Use Cloud Storage and BigQuery as repositories. Use Dataplex Universal Catalog for metadata discovery, data quality checks, and transformations.
  ✅ Đúng vì: Kết hợp hoàn hảo Storage (raw lake) + BigQuery (lakehouse analytics). Dataplex Universal Catalog tự động scan metadata từ cả hai, hỗ trợ discovery linh hoạt (search/query assets), quality checks (rules engine với scans scheduled), transformations (Dataflows SQL/No-code), và governance end-to-end (zones, policies). Managed 100%, scale cho vast data – best practice 2026.

• [SAI] Use Cloud Storage as the central repository. Use a Cloud Run function to catalog, transform the data, and perform data quality checks.
  ❌ Sai vì: Cloud Run là serverless functions linh hoạt, nhưng phải self-managed (viết code catalog/transform/quality thủ công, không automated governance). Thiếu Universal Catalog native, metadata discovery kém (cần integrate thủ công với Data Catalog cũ), không scale dễ cho vast data đa nguồn. Không đáp ứng "managed data governance solution".

Kết luận 🎯: Chọn Dataplex để xây dựng data lake thông minh, tiết kiệm thời gian và tuân thủ best practices Google Cloud! Nếu cần thiết kế chi tiết hơn, hãy cung cấp thêm yêu cầu. 🚀

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi này thuộc lĩnh vực Google Cloud Dataflow (dựa trên Apache Beam), tập trung vào việc xây dựng streaming data pipeline để xử lý dữ liệu thời gian thực từ Pub/Sub (Google Cloud Pub/Sub).

📊 Tình huống cụ thể:

• Bạn đang phân tích hoạt động click trên website của người dùng (user website click activity).
• Nhiệm vụ: Tính số lượng clicks cho mỗi site visit của một user cụ thể.
• Định nghĩa site visit: Một khoảng thời gian có hoạt động (activity), sau đó theo sau bởi 30 phút không hoạt động (inactivity).

🛠️ Vấn đề cốt lõi: Cần nhóm (group) các sự kiện clicks liên tiếp của cùng một user thành các "phiên" (session), dựa trên khoảng cách thời gian im lặng (gap) là 30 phút. Đây là đặc trưng của sessionization trong streaming analytics, nơi các cửa sổ (windows) phải linh hoạt theo dữ liệu thực tế thay vì cố định. Dataflow/Apache Beam hỗ trợ các loại windows như tumbling, sliding/hopping, và session để xử lý điều này (cập nhật đến Beam 2.58+ và Dataflow runtime 2.58+ năm 2026).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Use session windows with a 30-minute gap duration.

Lý do:

• Session windows là loại cửa sổ động, tự động nhóm các sự kiện của cùng key (user) thành các session nếu khoảng cách giữa các sự kiện liên tiếp ≤ 30 phút (gap duration). Khi gap > 30 phút, nó sẽ kết thúc session hiện tại và bắt đầu session mới – chính xác khớp định nghĩa "site visit" (activity theo sau bởi 30 phút inactivity).
• Điều này lý tưởng cho streaming data không đều đặn như user clicks, giúp tính tổng clicks chính xác per visit mà không bị cắt ngang bởi fixed windows.
• Theo docs Apache Beam mới nhất (2026), session windows hỗ trợ early/late data và watermarking hiệu quả trong Dataflow.

📘 Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên hành vi của windows trong Dataflow/Beam:

• ❌ Use tumbling windows with a 30-minute window.
  Sai vì: Tumbling windows là cửa sổ cố định, không chồng lấp, kích thước 30 phút, bắt đầu từ thời điểm đầu tiên (ví dụ: 0-30min, 30-60min,...). Nó sẽ cắt ngang site visit nếu activity kéo dài qua ranh giới window, dẫn đến clicks bị chia nhỏ không đúng (ví dụ: visit 25-40 phút sẽ split thành 2 windows). Không phù hợp cho session động dựa trên inactivity gap.

• ❌ Use hopping windows with a 30-minute window, and a 1-minute period.
  Sai vì: Hopping (hay sliding) windows chồng lấp với kích thước 30 phút, slide mỗi 1 phút (period). Mỗi event thuộc nhiều windows chồng lấp, gây double-counting clicks và không detect được chính xác 30 phút inactivity (vì focus vào fixed size/overlap thay vì gap giữa events). Kết quả: Tổng clicks per visit bị nhân bản, không chính xác cho sessionization.

• ❌ Use hopping windows with a 30-minute window, and a 30-minute period.
  Sai vì: Hopping với period = window size (30 phút) tương đương tumbling windows (không overlap). Vẫn cố định theo thời gian, không linh hoạt với gap inactivity thực tế của user. Nếu user inactive đúng 30 phút giữa 2 clicks, nó vẫn có thể split visit sai nếu không khớp ranh giới window.

• ✅ Use session windows with a 30-minute gap duration.
  Đúng vì: Như giải thích trên, session windows động dựa trên dữ liệu, merge events nếu gap ≤ 30 phút, split khi > 30 phút. Hoàn hảo cho user site visits, tính tổng clicks chính xác per session. Hỗ trợ combiner (như Sum) để aggregate clicks.

🔗 Tài liệu tham khảo

• 📖 Apache Beam Programming Guide - Windowing: https://beam.apache.org/documentation/programming-guide/#windowing (Session Windows section, cập nhật 2026).
• 📘 Google Cloud Dataflow Docs - Streaming Analytics: https://cloud.google.com/dataflow/docs/guides/streaming-data (Windowing strategies).
• 🛠️ Beam SDK Examples: https://beam.apache.org/get-started/session-windows/ (code mẫu session windows với Pub/Sub).

Hy vọng phân tích này giúp bạn nắm vững khái niệm windowing trong Dataflow! 🚀