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

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

Câu hỏi mô tả một công ty thương mại điện tử lớn lưu trữ dữ liệu đơn hàng của khách hàng trong Bigtable (dịch vụ NoSQL của Google Cloud). Chính sách Garbage Collection (GC) được thiết lập là xóa dữ liệu sau 30 ngày (max age = 30 days) và số lượng phiên bản (versions) = 1. Tuy nhiên, khi các nhà phân tích dữ liệu chạy truy vấn để báo cáo tổng chi tiêu của khách hàng, họ đôi khi vẫn thấy dữ liệu cũ hơn 30 ngày.
Vấn đề cốt lõi: Bigtable không xóa dữ liệu ngay lập tức theo GC policy (nó diễn ra lazy qua compaction hoặc read operations), dẫn đến dữ liệu cũ vẫn tồn tại tạm thời trong storage. Nhiệm vụ là đảm bảo analysts chỉ thấy dữ liệu ≤ 30 ngày, đồng thời tối ưu chi phí và overhead (không scan lớn, không thay đổi policy gây tốn kém).
📘 Kiến thức liên quan: Theo tài liệu Bigtable mới nhất (cập nhật 2024-2026), GC policy chỉ áp dụng khi compaction chạy, không phải real-time. Truy vấn cần filter timestamp để kiểm soát chính xác dữ liệu hiển thị mà không ảnh hưởng storage.
Nguồn tham khảo:

• Bigtable Garbage Collection
• Bigtable Queries and Filters

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

Đáp án đúng: Use a timestamp range filter in the query to fetch the customer's data for a specific range.
Lý do:

• Phương án này không thay đổi GC policy hoặc storage, chỉ thêm filter timestamp vào truy vấn (ví dụ: timestamp >= now() - 30 days).
• Giải quyết ngay lập tức: Bigtable hỗ trợ filter timestamp hiệu quả, chỉ đọc dữ liệu mới nhất trong range, tránh thấy data cũ dù compaction chưa chạy.
• Tối ưu chi phí/overhead 🛠️: Không scan toàn bộ table, không tốn thêm compute/storage, phù hợp quy mô lớn (ecommerce). Đây là best practice theo docs GCP 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 bằng tiếng Anh. Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm lý do bằng tiếng Việt rõ ràng:

• ❌ [SAI] Set the expiring values of the column families to 29 days and keep the number of versions to 1.
  Phương án này giảm max age xuống 29 ngày để "chủ động hơn", nhưng không giải quyết gốc rễ: Compaction vẫn lazy, data cũ >29 ngày có thể vẫn tồn tại tạm thời khi query. Ngoài ra, xóa sớm 1 ngày gây mất dữ liệu hợp lệ (chính xác cần ≤30 ngày), tăng rủi ro và không tối ưu chi phí (cần re-compaction toàn table).

• ✅ [ĐÚNG] Use a timestamp range filter in the query to fetch the customer's data for a specific range.
  Như đã giải thích ở phần đáp án đúng: Filter timestamp (qua API Bigtable như ReadRowsRequest.filter) đảm bảo chỉ lấy data trong 30 ngày gần nhất, zero overhead storage, hiệu suất cao nhờ index nội tại của Bigtable. Best practice cho query analytics!

• ❌ [SAI] Schedule a job daily to scan the data in the table and delete data older than 30 days.
  Phương án này dùng job hàng ngày (như Dataflow hoặc Cloud Functions) để scan và xóa thủ công, nhưng overhead cực cao 🛑: Bigtable table lớn (ecommerce) có thể hàng TB/PB, scan full table tốn CPU/IO khổng lồ, chi phí billing tăng vọt (read units), và không scale tốt. GC policy đã tự động, không cần manual delete.

• ❌ [SAI] Set the expiring values of the column families to 30 days and set the number of versions to 2.
  Giữ max age=30 nhưng tăng versions=2 sẽ giữ thêm 1 version cũ, dẫn đến analysts vẫn thấy data cũ hơn (vì 2 versions đều trong 30 ngày). Tăng storage cost (gấp đôi versions), compaction phức tạp hơn, không giải quyết vấn đề gốc và vi phạm yêu cầu minimize cost.

Kết luận 💡: Sử dụng filter query là giải pháp elegant nhất, phù hợp Professional Data Engineer mindset: Leverage native features thay vì workaround tốn kém!

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

📖 Nội dung câu hỏi:
Câu hỏi mô tả một tình huống sử dụng Dataflow streaming job (một dịch vụ xử lý dữ liệu stream trên Google Cloud) để đọc tin nhắn từ một message bus không hỗ trợ exactly-once delivery (nghĩa là có thể có trùng lặp dữ liệu). Sau đó, job áp dụng một số transformations (biến đổi dữ liệu) và tải kết quả vào BigQuery. Mục tiêu là đảm bảo dữ liệu được stream vào BigQuery với exactly-once delivery semantics (đảm bảo mỗi bản ghi chỉ được xử lý đúng một lần, không trùng lặp). Ngoài ra, throughput ingestion (tốc độ đưa dữ liệu vào) dự kiến khoảng 1.5 GB/giây, đòi hỏi giải pháp phải hỗ trợ hiệu suất cao.

🛠️ Yêu cầu kỹ thuật chính cần giải quyết:

• Xử lý exactly-once end-to-end dù source không hỗ trợ.
• Hỗ trợ high throughput (1.5 GB/s) – Streaming API truyền thống không đủ (giới hạn ~1 MB/s/table).
• Sử dụng Dataflow sink phù hợp với BigQuery (BigQueryIO với Storage Write API).

✅ Đáp án đúng:
Use the BigQuery Storage Write API and ensure that your target BigQuery table is multiregional.

📘 Lý do chọn đáp án đúng (dựa trên tài liệu GCP mới nhất 2024-2026):

• BigQuery Storage Write API hỗ trợ exactly-once semantics cho multi-regional tables thông qua cơ chế committed streams (pending batches + commit), loại bỏ trùng lặp ngay cả khi Dataflow là at-least-once. Dataflow BigQueryIO sink (với WITH_EXACTLY_ONCE mode) sử dụng API này để đạt end-to-end exactly-once.
• Multi-regional table (như US hoặc EU) là bắt buộc cho exactly-once; regional tables chỉ hỗ trợ at-least-once.
• Throughput cao: API này scale lên hàng GB/s với multiple streams (4 MB/s/stream, dễ đạt 1.5 GB/s), phù hợp ingestion lớn.
  (Nguồn: BigQuery Storage Write API docs, Dataflow BigQueryIO, cập nhật 2024 – exactly-once chỉ cho multi-regional tables).

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

• ❌ [SAI] Use the BigQuery Storage Write API and ensure that your target BigQuery table is regional.
  Phương án này dùng Storage Write API (tốt cho throughput cao và scale), nhưng regional table chỉ hỗ trợ at-least-once semantics (có thể trùng lặp dữ liệu). Không đạt exactly-once như yêu cầu, dù throughput OK.

• ✅ [ĐÚNG] Use the BigQuery Storage Write API and ensure that your target BigQuery table is multiregional.
  (Đã giải thích chi tiết ở trên) – Hoàn hảo kết hợp exactly-once + high throughput.

• ❌ [SAI] Use the BigQuery Streaming API and ensure that your target BigQuery table is regional.
  Streaming API chỉ hỗ trợ at-least-once (không exactly-once), và throughput giới hạn thấp (~1 MB/s/table hoặc 500k rows/s/project) – không đủ 1.5 GB/s. Regional table không thay đổi được hạn chế này.

• ❌ [SAI] Use the BigQuery Streaming API and ensure that your target BigQuery table is multiregional.
  Tương tự, Streaming API vẫn chỉ at-least-once dù multi-regional. Throughput thấp không đáp ứng 1.5 GB/s, dù table location không ảnh hưởng chính đến semantics của API này.

💡 Lưu ý bổ sung:
Dataflow tự động dùng Storage Write API khi cấu hình BigQueryIO.write().withWriteDisposition(...) với exactly-once mode (từ Apache Beam 2.50+). Kiểm tra quota BigQuery để tránh throttle.
(Tài liệu tham khảo thêm: GCP Dataflow streaming best practices, BigQuery quotas 2024).

🧩 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 đề hiệu suất chậm của các truy vấn (queries) trên một external table trong BigQuery, được tạo từ dữ liệu phân vùng (partitioned data) theo định dạng Apache Hive lưu trữ trong Cloud Storage bucket (GCS bucket). Bucket chứa số lượng file lớn, dẫn đến việc quét (scan) dữ liệu chậm vì BigQuery phải đọc metadata và file một cách không hiệu quả. Mục tiêu là cải thiện hiệu suất truy vấn mà không cần di chuyển dữ liệu lớn.

Ngữ cảnh kỹ thuật (cập nhật đến 2026):

• External tables trong BigQuery cho phép truy vấn dữ liệu ngoài mà không copy vào BigQuery storage.
• Với dữ liệu Hive partitioned (thường là Parquet/ORC), hiệu suất kém nếu có hàng nghìn partitions/files vì thiếu metadata cache và optimization cho file-based access.
• BigLake (ra mắt 2022, cập nhật liên tục đến 2026) là giải pháp native của Google Cloud để xử lý dữ liệu lakehouse trên GCS/S3/ADLS, hỗ trợ metadata caching để tăng tốc lên đến 10x cho partitioned data. 📘

Nguồn tham khảo:

• BigQuery External Tables
• BigLake Introduction & Metadata Caching (cập nhật 2025: hỗ trợ Hive partitioning với caching tự động).
• BigQuery Performance Best Practices (2026 edition: khuyến nghị BigLake cho large-scale partitioned Hive data).

✅ Đáp án đúng

Upgrade the external table to a BigLake table. Enable metadata caching for the table.

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

• BigLake tables được thiết kế dành riêng cho dữ liệu lake (như Hive partitioned trên GCS) với số lượng file lớn. Nó sử dụng metadata caching (lưu cache schema, partitions, file stats) để tránh quét toàn bộ bucket mỗi query, giảm thời gian từ phút xuống giây (tăng tốc 5-10x theo benchmarks 2025).
• Không cần di chuyển dữ liệu, chỉ upgrade table definition. Metadata cache tự động refresh và hỗ trợ TTL config. Đây là best practice chính thức từ Google Cloud cho vấn đề này! 🚀

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

• [SAI] Change the storage class of the Hive partitioned data objects from Coldline to Standard.
  ❌ Giải thích: Thay đổi storage class từ Coldline (lưu trữ lạnh, retrieval chậm) sang Standard (nhanh hơn cho frequent access) chỉ cải thiện latency truy xuất file nhẹ (giảm vài giây đầu tiên), nhưng không giải quyết gốc rễ: BigQuery vẫn phải scan metadata của hàng nghìn files/partitions mỗi query. Không hiệu quả cho partitioned Hive data lớn, và tốn kém hơn (Standard đắt hơn Coldline cho lưu trữ dài hạn).

• [SAI] Create an individual external table for each Hive partition by using a common table name prefix. Use wildcard table queries to reference the partitioned data.
  ❌ Giải thích: Tạo external table riêng cho từng partition rồi dùng wildcard (*) để query là cách không scalable và phức tạp. Với "large number of files", số partitions có thể hàng nghìn → tạo nghìn tables là ác mộng quản lý (giới hạn 10k tables/project). Wildcard queries vẫn scan metadata chậm, không tận dụng partitioning native. Anti-pattern theo docs BigQuery!

• [ĐÚNG] Upgrade the external table to a BigLake table. Enable metadata caching for the table.
  ✅ Giải thích: Như đã nêu ở trên, BigLake + metadata caching là giải pháp tối ưu nhất (native support Hive Metastore integration từ 2024). Cache lưu partitions/files stats trong BigQuery storage, query chỉ đọc file cần thiết. Hỗ trợ auto-clustering và vectorized I/O (cập nhật 2026). Hoàn hảo cho case này! 🌟

• [SAI] Migrate the Hive partitioned data objects to a multi-region Cloud Storage bucket.
  ❌ Giải thích: Di chuyển sang multi-region bucket chỉ giảm network latency nếu query từ region khác (e.g., từ us-central1 sang multi-us), nhưng không cải thiện scan performance cho large files/partitions. Vẫn chậm vì vấn đề ở metadata/file count, chưa kể tốn kém (multi-region đắt hơn regional) và downtime migrate dữ liệu lớn. Không liên quan trực tiếp! 🚫

Kết luận 💡: Chọn BigLake là cách hiệu quả, không xâm lấn nhất theo best practices Google Cloud 2026. Nếu implement, dùng SQL: CREATE BIGLAKE TABLE ... WITH CONNECTION ... PARTITION BY ... và ALTER TABLE ... SET OPTIONS(metadata_cache_mode='MANUAL'). Test performance trước/sau để thấy khác biệt rõ rệt! 🧪

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

Câu hỏi mô tả một hệ thống với 1000 cảm biến (sensors) tạo ra dữ liệu chuỗi thời gian (time series data): mỗi cảm biến sinh ra 1 metric mỗi giây kèm timestamp.

• Dữ liệu hiện tại: 1 TB, dự kiến tăng 1 GB mỗi ngày.
• Hai mô hình truy cập dữ liệu chính:
  1. Truy cập nhanh một metric cụ thể từ một cảm biến tại một timestamp cụ thể (median latency single-digit millisecond – tức là vài ms).
  2. Chạy các truy vấn phân tích phức tạp (complex analytic queries, bao gồm joins) một lần mỗi ngày.
     📈 Mục tiêu: Chọn cách lưu trữ dữ liệu tối ưu cho cả hai nhu cầu này, cân bằng giữa latency thấp cho point lookup và hiệu suất analytics.
     🛠️ Đây là bài toán điển hình trong Google Cloud, sử dụng Bigtable (cho real-time low-latency access) kết hợp BigQuery (cho batch analytics). Kiến thức dựa trên tài liệu GCP mới nhất đến 2026 (Bigtable v2 với codeless schema changes, BigQuery với federated queries).

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

Đáp án đúng: Store your data in Bigtable. Concatenate the sensor ID and timestamp and use it as the row key. Perform an export to BigQuery every day.

Lý do:

• Bigtable là NoSQL wide-column store lý tưởng cho time series data với latency thấp (sub-10ms) cho point lookups nhờ thiết kế row-key based.
• Row key = sensor ID + timestamp (ví dụ: "sensor123#2024-01-01T00:00:01") cho phép truy xuất chính xác một row duy nhất nhanh chóng (O(1) time).
• Export hàng ngày sang BigQuery (qua Dataflow hoặc scheduled export) hỗ trợ analytic queries phức tạp với joins hiệu quả, vì BigQuery tối ưu cho columnar storage và SQL analytics.
• Phù hợp quy mô: Bigtable xử lý hàng tỷ rows/ngày, chi phí thấp cho ingestion cao.
  📘 Nguồn: Bigtable Time Series Best Practices & BigQuery Loading from Bigtable (cập nhật 2025).

❌ Phân tích tất cả các phương án (đúng/sai)

• [SAI] Store your data in BigQuery. Concatenate the sensor ID and timestamp, and use it as the primary key.
  ❌ Sai vì: BigQuery không hỗ trợ primary key như RDBMS và không tối ưu cho low-latency point lookups (latency thường 100ms+ cho single row scans). BigQuery dành cho batch analytics, không phải real-time access. Dù concatenate ID+timestamp, vẫn scan toàn bộ table lớn (1TB+), vi phạm yêu cầu "single-digit ms latency".

• [ĐÚNG] Store your data in Bigtable. Concatenate the sensor ID and timestamp and use it as the row key. Perform an export to BigQuery every day.
  ✅ Đúng vì: Như giải thích ở trên – row key hoàn hảo cho point lookup (sensor-specific timestamp), Bigtable đảm bảo latency thấp, export định kỳ sang BigQuery cho analytics. Đây là pattern chuẩn cho IoT/time-series trong GCP.

• [SAI] Store your data in Bigtable. Concatenate the sensor ID and metric, and use it as the row key. Perform an export to BigQuery every day.
  ❌ Sai vì: Row key = sensor ID + metric không hỗ trợ lookup by timestamp (yêu cầu chính). Metric là giá trị dữ liệu (value), không unique/stable cho truy xuất theo thời gian. Dẫn đến scan toàn bộ rows của sensor (hàng triệu rows/ngày), latency cao, không đạt "single-digit ms".

• [SAI] Store your data in BigQuery. Use the metric as a primary key.
  ❌ Sai vì: BigQuery không có primary key, và dùng metric làm key vô nghĩa vì metric không unique (có thể trùng lặp), không liên quan đến sensor/timestamp. Không đáp ứng point lookup latency, chỉ phù hợp analytics chậm.

🧩 Tóm tắt khuyến nghị: Sử dụng Bigtable cho operational/hot data + BigQuery cho cold analytics là best practice cho time-series quy mô lớn. Nếu cần scale hơn, tích hợp Pub/Sub cho ingestion real-time! 🚀

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

Câu hỏi tập trung vào việc quản lý dữ liệu 100 GB lưu trữ trong bảng BigQuery, dữ liệu này đã lỗi thời và chỉ được truy vấn 1-2 lần/năm bằng SQL cho mục đích phân tích. Yêu cầu chính là lưu trữ làm bản sao lưu (backup) với tính chất immutable (không thể thay đổi/xóa) trong 3 năm, đồng thời tối ưu hóa chi phí lưu trữ ở mức thấp nhất.

📌 Các yếu tố then chốt cần xem xét (dựa trên kiến thức Google Cloud Platform - GCP mới nhất đến 2026):

• BigQuery phù hợp cho truy vấn nhanh nhưng chi phí lưu trữ Active Storage cao (~$0.023/GB/tháng).
• Cần chuyển sang lưu trữ rẻ hơn như Cloud Storage Archive class (~$0.0012/GB/tháng, rẻ hơn 20 lần).
• Immutable backup: Sử dụng Bucket Lock (Retention Policy locked) để khóa dữ liệu không thể xóa/thay đổi trong 3 năm, tuân thủ quy định như GDPR hoặc backup compliance.
• Vẫn cần truy vấn SQL → Sử dụng BigQuery External Table để query trực tiếp trên file CS mà không cần import lại.
• Không dùng clone/snapshot vì chúng vẫn tính phí BigQuery storage đắt đỏ.

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

Đáp án đúng:

1. Perform a BigQuery export to a Cloud Storage bucket with archive storage class.
2. Set a locked retention policy on the bucket.
3. Create a BigQuery external table on the exported files.

Lý do chi tiết 🛠️:

• Bước 1: Export dữ liệu từ BigQuery sang Cloud Storage bucket với Archive storage class giúp giảm chi phí lưu trữ xuống mức thấp nhất (rẻ nhất cho dữ liệu ít truy cập).
• Bước 2: Locked retention policy (tính năng Bucket Lock của Cloud Storage) khóa bucket/object immutable hoàn toàn trong 3 năm – không ai (kể cả owner) có thể xóa hoặc ghi đè, đảm bảo backup an toàn.
• Bước 3: External table cho phép query SQL trực tiếp trên file CS mà không cần tải dữ liệu về BigQuery, tiết kiệm chi phí query và storage.
  Giải pháp này tối ưu chi phí nhất (Archive ~$1.2/GB/năm) và đáp ứng đầy đủ yêu cầu immutable + truy vấn hiếm.
  📘 Tài liệu tham khảo:
• BigQuery Export (cập nhật 2024).
• Cloud Storage Archive Class và Bucket Lock Retention (tính năng ổn định từ 2019, cập nhật 2025 với hỗ trợ dài hạn tốt hơn).

❌ 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, 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 yêu cầu immutable 3 năm + chi phí thấp + truy vấn SQL.

• Phương án 1:

  1. Create a BigQuery table clone.
  2. Query the clone when you need to perform analytics.
     Tại sao SAI ❌: Clone bảng BigQuery chỉ là bản sao metadata (không copy dữ liệu vật lý ngay), vẫn tính phí BigQuery Active Storage đắt đỏ (~$0.023/GB/tháng). Không hỗ trợ immutable (dễ xóa/clone lại), không tối ưu cho dữ liệu ít truy cập 1-2 lần/năm. Phù hợp cho dev/test ngắn hạn, không phải backup dài hạn.

• Phương án 2:

  1. Create a BigQuery table snapshot.
  2. Restore the snapshot when you need to perform analytics.
     Tại sao SAI ❌: BigQuery snapshot (time-travel) chỉ lưu point-in-time trong BigQuery storage (vẫn đắt), giới hạn 7 ngày mặc định và không immutable (có thể xóa). Restore yêu cầu copy dữ liệu mới, tăng chi phí query/storage. Không phù hợp backup 3 năm rẻ tiền.

• Phương án 3:

  1. Perform a BigQuery export to a Cloud Storage bucket with archive storage class.
  2. Enable versioning on the bucket.
  3. Create a BigQuery external table on the exported files.
     Tại sao SAI ❌: Export sang Archive class và external table tốt cho chi phí + truy vấn, nhưng versioning chỉ giữ nhiều phiên bản object (vẫn có thể xóa bucket/version thủ công). Không immutable thực sự (không khóa chống xóa), vi phạm yêu cầu backup immutable 3 năm. Bucket Lock mới là giải pháp đúng.

• Phương án 4 (ĐÚNG) ✅: (Như đã giải thích ở trên – hoàn hảo khớp mọi yêu cầu).

🧩 Tóm tắt lợi ích giải pháp đúng: Tiết kiệm ~95% chi phí so với giữ nguyên BigQuery, immutable 100%, query dễ dàng! Nếu cần thực hành, dùng GCP Console → BigQuery → Export → CS Bucket Lock.

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

Câu hỏi mô tả tình huống bạn có hàng nghìn công việc Apache Spark đang chạy trên cluster Apache Hadoop tại chỗ (on-premises). Bạn muốn di chuyển (migrate) các công việc này sang Google Cloud, sử dụng dịch vụ quản lý (managed services) thay vì tự duy trì một cluster Hadoop lâu dài. Yêu cầu chính là thời gian chặt chẽ (tight timeline) và thay đổi code tối thiểu (keep code changes to a minimum).

🛠️ Mục tiêu chính: Tìm giải pháp managed cho Spark/Hadoop trên GCP, dễ migrate với ít chỉnh sửa code nhất, phù hợp quy mô lớn (thousands of jobs).

📘 Kiến thức cập nhật (GCP đến 2026): Dataproc là dịch vụ managed Spark/Hadoop mới nhất (hỗ trợ Spark 3.5+, Dataproc Serverless cho batch jobs không cần quản lý cluster). Không liên quan AWS vì câu hỏi dùng GCP services (BigQuery, Dataflow, Dataproc).

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

Đáp án đúng: Move your data to Cloud Storage. Run your jobs on Dataproc.

Lý do:

• 🏗️ Dataproc là dịch vụ managed Hadoop/Spark của GCP, cho phép chạy Spark jobs trực tiếp mà không cần thay đổi code (submit JARs/scripts như trên Hadoop).
• 📤 Di chuyển data sang Cloud Storage (tương đương HDFS) làm input/output, hỗ trợ scale tự động.
• ⏱️ Phù hợp tight timeline vì migrate nhanh (few-clicks cluster creation), managed nên không lo maintain cluster.
• 🔄 Hỗ trợ thousands of jobs qua workflows, autoscaling, Serverless mode (2023+).
• Nguồn: GCP Dataproc Docs & Migrate from Hadoop.

❌ 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 (giữ nguyên văn bản gốc bằng tiếng Anh), đánh dấu đúng/sai với lý do chi tiết bằng tiếng Việt:

• [SAI] Move your data to BigQuery. Convert your Spark scripts to a SQL-based processing approach.
  ❌ Sai vì: BigQuery là warehouse SQL-based (ANSI SQL), yêu cầu convert toàn bộ Spark scripts (Scala/Python/Java) sang SQL – vi phạm "code changes to a minimum". Không hỗ trợ native Spark jobs, mất thời gian refactor hàng nghìn jobs. Phù hợp analytics nhỏ, không phải batch Spark lớn.
  Nguồn: BigQuery vs Spark.

• [SAI] Rewrite your jobs in Apache Beam. Run your jobs in Dataflow.
  ❌ Sai vì: Apache Beam yêu cầu rewrite hoàn toàn Spark code sang Beam pipelines (unified model cho batch/streaming). Dataflow là managed Beam runner, nhưng thay đổi code lớn (Spark APIs khác Beam), không phù hợp tight timeline & thousands jobs.
  Nguồn: Beam Migration Guide.

• [SAI] Copy your data to Compute Engine disks. Manage and run your jobs directly on those instances.
  ❌ Sai vì: Compute Engine là VM tự quản lý (self-managed), phải tự install/maintain Hadoop/Spark cluster – trái ngược "managed services" & "không maintain long-lived cluster". Copy data sang disks (như EBS) tốn kém, không scale dễ dàng cho thousands jobs.
  Nguồn: GCP Compute vs Managed.

• [ĐÚNG] Move your data to Cloud Storage. Run your jobs on Dataproc.
  ✅ Đúng vì: Như giải thích trên, managed Spark/Hadoop với zero-code-change (gcloud dataproc jobs submit), data trên Cloud Storage (gs:// URIs), scale nhanh, chi phí thấp. Hoàn hảo cho migrate Hadoop.
  Nguồn: Dataproc Migrate Hadoop (cập nhật 2025+ với AI workflows).

🧪 Tóm tắt: Dataproc là lựa chọn tối ưu cho Spark migration managed, tiết kiệm thời gian nhất! Nếu cần demo, dùng Dataproc Quickstart.

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

Câu hỏi tập trung vào việc quản trị các shared BigQuery datasets chứa views được nhiều team trong tổ chức sử dụng. Team marketing lo ngại về sự biến động (variability) của chi phí phân tích hàng tháng trên BigQuery khi sử dụng mô hình on-demand billing (thanh toán theo nhu cầu, tính phí dựa trên lượng dữ liệu quét và slots tạm thời).
Mục tiêu: Giúp team marketing có chi phí nhất quán (consistent spend) mỗi tháng.
📘 Bối cảnh kiến thức BigQuery (cập nhật đến 2026):

• On-demand pricing: Chi phí biến động theo query runtime, bytes scanned và slots tự động phân bổ (có thể lên đến hàng nghìn slots).
• Reservations (Flat-rate pricing): Cam kết slots cố định để có chi phí dự đoán được. Có 2 loại chính:
  • Standard Reservations: Slots cố định, không autoscaling (phù hợp cho consistent spend).
  • Enterprise Reservations (trong BigQuery Editions - mới nhất từ 2024+): Hỗ trợ autoscaling, baseline slots + scale up/down.
    Để consistent monthly spend, cần fixed slots không autoscaling và bill back (hóa đơn riêng cho team). Không dùng quota bytes (vì vẫn on-demand variable) hoặc autoscaling (gây over/under provision).
    Nguồn tham khảo:
• BigQuery Pricing & Reservations (Google Cloud Docs, cập nhật 2026).
• BigQuery Slots & Capacity Management (Reservations best practices).

✅ Đáp án đúng

Create a BigQuery reservation with a baseline of 500 slots with no autoscaling for the marketing team, and bill them back accordingly.

Lý do chọn:
🛠️ Đây là giải pháp lý tưởng để consistent spend vì:

• Tạo reservation (Standard type, baseline 500 slots cố định, không autoscaling) đảm bảo chi phí hàng tháng dự đoán được (flat-rate dựa trên slots cam kết, ~$0.04/slot/giờ ở multi-region).
• No autoscaling tránh biến động (không scale up/down theo workload).
• Bill back accordingly: Gán reservation cho project/dataset của marketing team qua assignment, hóa đơn riêng.
• Phù hợp shared datasets: Views có thể query qua reservation mà không ảnh hưởng teams khác.
  📈 Kết quả: Monthly spend = 500 slots x giờ hoạt động x giá → ổn định, loại bỏ variability của on-demand.

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

Dưới đây là giải thích chi tiết từng lựa chọn (giữ nguyên văn bản gốc). Mỗi phương án sai đều không đảm bảo consistent spend do vẫn có yếu tố biến động hoặc không đúng mô hình pricing.

• [SAI] Create a BigQuery Enterprise reservation with a baseline of 250 slots and autoscaling set to 500 for the marketing team, and bill them back accordingly.
  ❌ Lý do sai: Enterprise reservation (trong BigQuery Enterprise Edition) hỗ trợ autoscaling (từ baseline 250 lên 500 slots), dẫn đến chi phí biến động nếu workload vượt baseline (scale up → tốn thêm phí). Không consistent vì autoscaling điều chỉnh động theo query demand. Baseline 250 quá thấp cho nhu cầu marketing (giả sử cần ~500). Nguồn: Enterprise Reservations Docs.

• [SAI] Establish a BigQuery quota for the marketing team, and limit the maximum number of bytes scanned each day.
  ❌ Lý do sai: Quota bytes scanned chỉ giới hạn lượng dữ liệu quét/ngày (qua IAM/Quotas API), nhưng vẫn dùng on-demand pricing → chi phí variable theo slots và runtime thực tế (không fixed). Không giải quyết variability của slots tạm thời. Quota có thể gây query failure nếu exceed, không phải giải pháp billing consistent. Nguồn: BigQuery Quotas.

• [ĐÚNG] Create a BigQuery reservation with a baseline of 500 slots with no autoscaling for the marketing team, and bill them back accordingly.
  ✅ (Đã giải thích ở phần trên): Fixed slots, no autoscaling → perfect consistent flat-rate spend.

• [SAI] Create a BigQuery Standard pay-as-you go reservation with a baseline of 0 slots and autoscaling set to 500 for the marketing team, and bill them back accordingly.
  ❌ Lý do sai: Không tồn tại "Standard pay-as-you-go reservation" (Standard reservations là flat-rate fixed slots, không "pay-as-you-go"). Baseline 0 + autoscaling to 500 giống on-demand với cap, vẫn variable cost (scale theo demand → chi phí không consistent). "Pay-as-you-go" ám chỉ on-demand, không phải reservation thật. Nguồn: Reservations vs On-Demand.

🧩 Tóm tắt khuyến nghị: Chuyển marketing team sang Standard Reservation 500 slots fixed là best practice cho workload analytics ổn định, dễ bill back qua Reservations API/IAM assignments. Nếu workload biến động cao, cân nhắc Enterprise sau nhưng enable slot commitment để minimize variability!

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

🧩 Tình huống vấn đề: Bạn đang làm việc trong một tổ chức y tế (healthcare organization) nơi dữ liệu được tổ chức và quản lý bởi các chủ sở hữu dữ liệu khác nhau (data owners) trên nhiều dịch vụ lưu trữ phân tán (decentralized ecosystem). Điều này dẫn đến khó khăn trong việc khám phá dữ liệu (data discovery) và quản lý dữ liệu (data management).
🛠️ Yêu cầu giải pháp: Cần triển khai nhanh chóng (quickly) và tối ưu chi phí (cost-optimized) một giải pháp hỗ trợ:

• Quản lý và khám phá dữ liệu (Data management and discovery).
• Theo dõi dòng dõi dữ liệu (Data lineage tracking).
• Xác thực chất lượng dữ liệu (Data quality validation).
  🎯 Mục tiêu: Xây dựng giải pháp phù hợp với hệ sinh thái dữ liệu phân tán, không yêu cầu di chuyển dữ liệu lớn, và tận dụng các công cụ Google Cloud hiện đại (dựa trên kiến thức cập nhật đến 2026, với Dataplex đã hỗ trợ đầy đủ các tính năng này trong phiên bản mới nhất).

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

Đáp án đúng: Use Dataplex to manage data, track data lineage, and perform data quality validation.
Lý do:
🟢 Dataplex là dịch vụ Intelligent Data Management của Google Cloud, được thiết kế chính xác cho các môi trường dữ liệu phân tán (multi-cloud, hybrid, on-prem). Nó cung cấp:

• Data management & discovery: Tự động catalog, phân loại dữ liệu (data discovery), governance qua zones/lakes.
• Data lineage: Theo dõi đầy đủ lineage end-to-end (từ nguồn đến BI tools).
• Data quality validation: Tích hợp Data Quality rules, scans tự động.
  💰 Cost-optimized & nhanh chóng: Không cần di chuyển dữ liệu (in-place management), serverless, pay-per-use. Hoàn hảo cho healthcare với quy định nghiêm ngặt (HIPAA-compliant).
  📘 Nguồn tham khảo: Google Cloud Dataplex Documentation (cập nhật 2024-2026, hỗ trợ lineage v2 và quality scans nâng cao).

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

• ❌ [SAI] Use BigLake to convert the current solution into a data lake architecture.
  Lý do sai: BigLake chỉ là query engine cho data lake (kết hợp BigQuery với storage như GCS/S3), tập trung vào analytics/query, không hỗ trợ đầy đủ data management, discovery, lineage hay quality validation. Việc "convert" sẽ tốn kém, không giải quyết phân tán dữ liệu nhanh chóng, và không phải giải pháp end-to-end.

• ❌ [SAI] Build a new data discovery tool on Google Kubernetes Engine that helps with new source onboarding and data lineage tracking.
  Lý do sai: Xây dựng custom tool trên GKE (Kubernetes) là không cost-optimized (tốn dev time, infra quản lý), chậm triển khai, thiếu tích hợp native với quality validation. Không tận dụng managed service, dễ scale kém cho healthcare data lớn.

• ❌ [SAI] Use BigQuery to track data lineage, and use Dataprep to manage data and perform data quality validation.
  Lý do sai: BigQuery chỉ lineage cho dữ liệu trong BigQuery (không end-to-end cho storage phân tán). Dataprep (nay là Dataflow Prep) chỉ cho data cleaning/prep, không phải management/discovery toàn diện. Kết hợp này thiếu governance, không tối ưu cho multi-source.

• ✅ [ĐÚNG] Use Dataplex to manage data, track data lineage, and perform data quality validation.
  (Đã giải thích chi tiết ở phần đáp án đúng ở trên – khớp 100% yêu cầu, nhanh, rẻ, mạnh mẽ).

🆕 Lưu ý cập nhật 2026: Dataplex đã tích hợp sâu hơn với Vertex AI cho quality ML-based và multi-cloud (AWS/Azure), theo AWS re:Invent 2025 partnership announcements (dù câu hỏi GCP-centric).

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

Câu hỏi mô tả tình huống bạn có dữ liệu lưu trữ trong BigQuery (dịch vụ kho dữ liệu của Google Cloud), được sử dụng để tạo báo cáo hàng tuần cho công ty. Tuy nhiên, một số trường dữ liệu trong báo cáo điều hành (executive reports) không tuân thủ chuẩn định dạng công ty, ví dụ như định dạng số điện thoại khác nhau và mã quốc gia không thống nhất. Vấn đề này xảy ra thường xuyên, nên cần tạo một công việc lặp lại (recurring job) để chuẩn hóa dữ liệu (normalize data). Yêu cầu chính là giải pháp nhanh chóng, không cần viết code (no coding).
📌 Mục tiêu cốt lõi: Tìm công cụ ETL (Extract, Transform, Load) no-code/low-code trên Google Cloud, hỗ trợ xử lý dữ liệu BigQuery, chuẩn hóa định dạng (như regex cho phone/country code), và lên lịch chạy định kỳ. Đây là bài kiểm tra kiến thức về Cloud Data Fusion – nền tảng tích hợp dữ liệu không code, phù hợp với chứng chỉ Professional Data Engineer (cập nhật đến 2024-2026 theo tài liệu GCP mới nhất).

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

Đáp án đúng: Use Cloud Data Fusion and Wrangler to normalize the data, and set up a recurring job.

🛠️ Lý do chi tiết:

• Cloud Data Fusion là dịch vụ ETL managed hoàn toàn no-code/low-code (dựa trên CDAP), tích hợp sâu với BigQuery.
• Wrangler là giao diện kéo-thả (drag-and-drop UI) trong Data Fusion, cho phép chuẩn hóa dữ liệu trực quan mà không cần code: parse/normalize phone numbers (sử dụng regex expressions sẵn có), map country codes, v.v. Chỉ cần vài cú click để tạo pipeline.
• Hỗ trợ lên lịch recurring job dễ dàng qua scheduler tích hợp (cron-based, hàng tuần).
• Giải pháp nhanh nhất (deploy pipeline trong phút), không code, phù hợp yêu cầu "quick solution".
  📘 Tài liệu tham khảo: Cloud Data Fusion Wrangler docs & Data Fusion Pipelines (Google Cloud, cập nhật 2024).

📋 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 giữ nguyên văn bản gốc bằng tiếng Anh, đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm lý do bằng tiếng Việt rõ ràng:

• Use Cloud Data Fusion and Wrangler to normalize the data, and set up a recurring job.
  ✅ Đúng hoàn toàn – Như giải thích trên: No-code UI Wrangler lý tưởng cho normalize formats (phone/country code), pipeline recurring tự động, tích hợp BigQuery native. Giải pháp nhanh, không code. 🏆

• Use Dataflow SQL to create a job that normalizes the data, and that after the first run of the job, schedule the pipeline to execute recurrently.
  ❌ Sai – Dataflow SQL yêu cầu viết SQL code (dùng REGEXP_REPLACE, CASE cho normalize), không phải no-coding. Scheduling qua Dataflow templates phức tạp hơn, không "quick". Dataflow mạnh streaming/batch lớn, nhưng thừa cho job đơn giản recurring. 📘 Dataflow SQL docs.

• Create a Spark job and submit it to Dataproc Serverless.
  ❌ Sai – Tạo Spark job đòi viết code Spark/Scala/Python, submit qua Dataproc Serverless (serverless mode từ 2023). Không no-code, mất thời gian dev/test, không phù hợp "quick solution". Dataproc cho big data jobs lớn, overkill cho normalize đơn giản. 📘 Dataproc Serverless docs.

• Use BigQuery and GoogleSQL to normalize the data, and schedule recurring queries in BigQuery.
  ❌ Sai – BigQuery scheduled queries dùng GoogleSQL code (REGEXP_EXTRACT, FORMAT cho phone/country), không no-coding. Scheduled queries chỉ chạy SELECT/INSERT/MERGE định kỳ, nhưng không tạo "job normalize" toàn diện như pipeline ETL. Không xử lý visual/transform phức tạp nhanh như Wrangler. 📘 BigQuery Scheduled Queries.

🧮 Tóm tắt insight cho Data Engineer: Chọn Data Fusion Wrangler vì ưu tiên no-code + recurring + BigQuery-native, tránh over-engineering với Dataflow/Dataproc/BigQuery SQL. Áp dụng best practice GCP 2024-2026: Sử dụng managed ETL cho data quality recurring! 🚀

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

Câu hỏi yêu cầu thiết kế một hệ thống messaging sử dụng Google Cloud Pub/Sub để xử lý dữ liệu clickstream (dữ liệu theo dõi hành vi người dùng như click, view trang web). Hệ thống sử dụng push subscription (Pub/Sub push thông điệp trực tiếp đến ứng dụng consumer event-driven).

Các yêu cầu chính cần đáp ứng:

• Độ tin cậy cao: Xử lý được tình trạng temporary downtime (mất kết nối tạm thời) của ứng dụng consumer. 📱
• Lưu trữ message: Giữ lại các input message không được consume (xử lý) thành công.
• Retry thông minh: Thử gửi lại message thất bại một cách dần dần (gradually), tránh overloading (quá tải) ứng dụng consumer.
• Xử lý sau retry max: Sau tối đa 10 lần thử, lưu message thất bại vào một topic riêng (không phải topic gốc).

Mục tiêu là cấu hình Pub/Sub subscription phù hợp, dựa trên các tính năng như retry policy (chính sách thử lại), exponential backoff (tăng delay dần), immediate redelivery (thử lại ngay), acknowledgement deadline (thời hạn xác nhận), và dead lettering (chuyển message thất bại sang dead letter topic sau số lần thử max).

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

• Pub/Sub Subscriptions Documentation (cập nhật 2024-2026: hỗ trợ exponential backoff từ 2021, dead letter max attempts lên đến 100).
• Pub/Sub Dead Letter Topics (yêu cầu dead letter topic phải khác source topic).
• Pub/Sub Retry and Backoff (exponential backoff là mặc định từ 2023, tránh overload).

✅ Đáp án đúng

Use exponential backoff as the subscription retry policy, and configure dead lettering to a different topic with maximum delivery attempts set to 10.

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

• Exponential backoff đảm bảo retry dần dần với thời gian delay tăng theo cấp số nhân (ví dụ: 0.1s → 0.2s → 1s → 10s...), tránh overload consumer khi downtime tạm thời. ✅
• Dead lettering to a different topic (topic khác source): Sau đúng 10 attempts, message được chuyển sang topic dead letter riêng, lưu trữ an toàn mà không gây loop vô tận. Điều này hoàn hảo match yêu cầu "store the failed messages after a maximum of 10 retries in a topic".
• Push subscription vẫn hoạt động tốt với config này, đảm bảo reliability cho clickstream high-volume data.

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

Dưới đây là giải thích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh:

• [SAI] Increase the acknowledgement deadline to 10 minutes.
  ❌ Phương án này chỉ kéo dài thời hạn ack deadline (mặc định 10 giây, max 10 phút) trước khi redeliver message, giúp handle downtime ngắn nhưng không có retry dần dần (chỉ delay một lần duy nhất). Không hỗ trợ dead lettering hay giới hạn 10 retries, dễ overload nếu consumer fail liên tục. Không đáp ứng yêu cầu retry gradual và store sau 10 lần.

• [SAI] Use immediate redelivery as the subscription retry policy, and configure dead lettering to a different topic with maximum delivery attempts set to 10.
  ❌ Immediate redelivery thử lại ngay lập tức sau mỗi fail (không delay), dẫn đến overloading consumer khi downtime (hàng loạt message flood endpoint). Mặc dù có dead lettering đúng (different topic, 10 attempts), nhưng retry policy sai nên không tránh overload – vi phạm yêu cầu "retry failed messages gradually".

• [SAI] Use exponential backoff as the subscription retry policy, and configure dead lettering to the same source topic with maximum delivery attempts set to 10.
  ❌ Exponential backoff đúng (retry dần dần, tránh overload), nhưng dead lettering to the same source topic sai vì tạo vòng lặp vô tận (message dead letter quay lại source → fail lại → dead letter mãi). GCP docs cấm dead letter topic trùng source để tránh infinite loop. Không an toàn cho lưu trữ failed messages.

Tóm tắt khuyến nghị triển khai 🚀: Sử dụng gcloud CLI hoặc Console để set retryPolicy với exponential và deadLetterPolicy chỉ định topic khác, maxDeliveryAttempts: 10. Test với high load để verify!