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

Câu 31 Data Pipelines

You would like to set a maximum number of concurrent jobs in Cloud Dataproc. How would you do that?

A Set computengine:mgi.scheduler.max-concurrent-jobs property when creating a managed instance group for Cloud Dataproc cluster.
B Use Cloud Monitoring to detect the number of jobs running and when the maximum threshold is exceeded, trigger a Cloud Function to terminate the most recently created job.
C
Set dataproc:dataproc.scheduler.max-concurrent-jobs property when creating a cluster.
D
Set dataproc:dataproc.scheduler.max-concurrent-jobs property when adding worker nodes.

Xem giải thích

Đáp án

C — Đặt thuộc tính dataproc:dataproc.scheduler.max-concurrent-jobs khi TẠO cụm.

Vì sao đúng

⚠ Thuộc tính cụm Dataproc đặt lúc tạo cụm:

gcloud dataproc clusters create ten-cum \
  --region=asia-southeast1 \
  --properties=\
dataproc:dataproc.scheduler.max-concurrent-jobs=10

Thành phần	Ý nghĩa
⚠ Tiền tố `dataproc:`	⚠ thuộc tính của chính Dataproc
⚠ `dataproc.scheduler.max-concurrent-jobs`	⚠ giới hạn số job chạy đồng thời
⚠ Đặt lúc TẠO cụm	⚠ qua cờ `--properties`

⚠ Vì sao cần giới hạn: ⚠ quá nhiều job cùng lúc ⚠ tranh nhau tài nguyên, ⚠ tất cả cùng chậm, ⚠ có thể hết bộ nhớ.

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

D (đặt cùng thuộc tính khi THÊM worker node) — ⚠ sai thời điểm: ⚠ đây là thuộc tính cấp CỤM, ⚠ đặt lúc tạo cụm.
A (computengine:mgi.scheduler.max-concurrent-jobs khi tạo managed instance group) — ⚠ thuộc tính bịa: ⚠ và ⚠ Dataproc không được cấu hình qua MIG.
B (dùng Cloud Monitoring phát hiện rồi Cloud Function huỷ job mới nhất) — ⚠ giải pháp chắp vá: ⚠ huỷ job đang chạy là ⚠ mất công việc đã làm; ⚠ khi có tính năng gốc thì đừng tự dựng.

Ghi nhớ

⚠ Tiền tố thuộc tính Dataproc — bảng phải thuộc: | Tiền tố | Áp cho | |---|---| | ⚠ dataproc: | ⚠ chính Dataproc — scheduler, autoscaling | | ⚠ spark: | ⚠ cấu hình Spark | | ⚠ yarn: | ⚠ quản lý tài nguyên YARN | | ⚠ hdfs: | ⚠ HDFS | | ⚠ hive: | ⚠ Hive | | ⚠ Cú pháp | ⚠ --properties=tiềntố:khoá=giá trị |

Từ khoá nhận diện:

"giới hạn job đồng thời" → ⚠ dataproc:dataproc.scheduler.max-concurrent-jobs "chỉnh bộ nhớ executor Spark" → ⚠ spark:spark.executor.memory "cụm tự xoá khi rảnh" → ⚠ --max-idle, là CỜ chứ không phải thuộc tính

⚠ Thuộc tính Dataproc hay gặp	Thuộc tính
⚠ `dataproc.scheduler.max-concurrent-jobs`	⚠ số job đồng thời
⚠ `dataproc.scheduler.max-memory-used`	⚠ ngưỡng bộ nhớ trước khi xếp hàng job mới
⚠ `spark.executor.memory`, `spark.executor.cores`
⚠ `spark.dynamicAllocation.enabled`	⚠ cấp phát executor động
⚠ Đặt lúc nào	⚠ hầu hết là LÚC TẠO cụm — không đổi được sau

⚠ Vì sao giới hạn job đồng thời quan trọng	Lý do
⚠ Job tranh nhau bộ nhớ YARN
⚠ Tất cả cùng chậm thay vì lần lượt xong
⚠ Rủi ro OutOfMemory hàng loạt
⚠ Xếp hàng cho thông lượng TỔNG tốt hơn
⚠ Nguyên tắc chung	⚠ chạy ít việc một lúc thường nhanh hơn chạy tất cả cùng lúc

⚠ Kiến trúc thay thế cho việc chia sẻ cụm	Kiến trúc
⚠ Cụm NGẮN HẠN cho từng job	⚠ cách ly hoàn toàn, không tranh chấp
⚠ Dataproc Serverless	⚠ không quản cụm nào cả
⚠ Cloud Composer điều phối
⚠ Xu hướng	⚠ cụm dùng chung dài hạn ngày càng ít được khuyến nghị

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cụm có bị nhiều job tranh nhau không | ⚠ xem giao diện YARN | | Có nên tách thành cụm ngắn hạn không | | | Thuộc tính có đặt lúc tạo cụm không | ⚠ sau đó không đổi được |

Và cách tránh hẳn cả lớp vấn đề này: mỗi job một cụm riêng, tạo rồi xoá. Khi tính toán rẻ và dữ liệu nằm ở Cloud Storage, việc tranh chấp tài nguyên trên một cụm dùng chung là bài toán tự chuốc lấy.

Câu 32 Data pipelines

A consultant has recommended that you replace an existing messaging system with Cloud Pub/Sub. You are concerned that your existing system has a different delivery guarantee than Cloud Pub/Sub. What kind of message deliver semantics does Cloud Pub/Sub guarantee?

A Deliver at least once
B Deliver at most once
C Deliver at most or deliver at least depending on configuration of the subscription
D Best effort but no guarantee

Xem giải thích

Đáp án

A — Giao ít nhất một lần (deliver at least once).

Vì sao đúng

⚠ Ba kiểu đảm bảo giao tin nhắn: | Kiểu | Nghĩa | Rủi ro | |---|---|---| | ⚠ At most once | ⚠ tối đa một lần | ⚠ có thể MẤT tin nhắn | | ⚠ At least once | ⚠ ít nhất một lần — Pub/Sub | ⚠ có thể TRÙNG | | ⚠ Exactly once | ⚠ đúng một lần | ⚠ khó và tốn kém |

⚠ Pub/Sub gửi tin nhắn
        ↓
⚠ Chờ subscriber XÁC NHẬN (ack)
        ↓ ⚠ không nhận được ack
   (⚠ mạng chậm, subscriber chậm)
        ↓
⚠ GỬI LẠI
        ↓
⚠ Subscriber có thể nhận HAI LẦN

⚠ Hệ quả bắt buộc phải nhớ: ⚠ mã xử lý phải chịu được tin nhắn lặp (idempotent).

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

B (at most once) — ⚠ ngược lại: ⚠ nghĩa là chấp nhận mất tin nhắn; ⚠ Pub/Sub thà gửi trùng còn hơn để mất.
C (tuỳ cấu hình subscription mà at most hay at least) — ⚠ sai: ⚠ Pub/Sub có tuỳ chọn exactly-once cho pull subscription, ⚠ nhưng không có chế độ "at most once".
D (nỗ lực tối đa, không đảm bảo) — ⚠ Pub/Sub CÓ đảm bảo: ⚠ đây là mô tả của UDP, không phải Pub/Sub.

Ghi nhớ

⚠ Vì sao "at least once" là lựa chọn thực tế — bảng phải thuộc: | Lý do | Nội dung | |---|---| | ⚠ Mạng không đáng tin | ⚠ ack có thể mất trên đường về | | ⚠ Không phân biệt được "chưa xử lý" và "đã xử lý mà mất ack" | | | ⚠ Gửi lại an toàn hơn bỏ qua | ⚠ với hầu hết hệ thống | | ⚠ Cái giá | ⚠ ứng dụng phải tự khử trùng lặp |

Từ khoá nhận diện:

"Pub/Sub đảm bảo gì" → ⚠ at least once "tránh xử lý trùng" → ⚠ idempotent hoặc bật exactly-once "đảm bảo thứ tự" → ⚠ ordering key, KHÔNG mặc định

⚠ Cách làm mã idempotent	Cách
⚠ Dùng `messageId` làm khoá khử trùng
⚠ Ghi có điều kiện: `INSERT ... ON CONFLICT DO NOTHING`
⚠ Thiết kế thao tác "đặt giá trị" thay vì "cộng thêm"	⚠ đặt thì lặp vô hại
⚠ Lưu id đã xử lý trong Redis hoặc Firestore	⚠ có thời hạn
⚠ Nguy hiểm nhất	⚠ thao tác CỘNG DỒN — lặp là sai số liệu

⚠ Exactly-once của Pub/Sub	Đặc điểm
⚠ Chỉ cho PULL subscription
⚠ Trong phạm vi MỘT vùng
⚠ Giảm thông lượng và tăng độ trễ
⚠ Lời khuyên	⚠ vẫn nên viết mã idempotent — rẻ hơn và an toàn hơn

⚠ Nguyên nhân gây gửi lại	Nguyên nhân
⚠ Ack deadline hết trước khi xử lý xong	⚠ phổ biến nhất
⚠ Subscriber chết giữa chừng
⚠ Ack bị mất trên mạng
⚠ Subscriber trả lỗi (nack)
⚠ Cách giảm	⚠ gia hạn ack deadline khi xử lý lâu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mã xử lý có chịu được chạy hai lần không | ⚠ thử gửi lặp thật | | Ack deadline có đủ dài không | | | Có thao tác cộng dồn nào không được bảo vệ không | |

Và lỗi âm thầm nhất của hệ thống nhắn tin: một tin nhắn được xử lý hai lần trong một thao tác cộng dồn. Không có ngoại lệ nào, không có log lỗi nào — chỉ có con số cuối tháng lệch mà không ai giải thích được.

Câu 33 Data Pipelines

A Cloud Dataproc cluster is experiencing a higher than normal workload and you'd like to add several preemptible VMs as worker nodes. What command would you use?

A The number of preemptible nodes in a Cloud Dataproc cluster cannot be changed once the cluster is created.
B gcloud dataproc clusters update with the --preemptible-vms parameter
C gcloud dataproc clusters update with the --num-secondary-workers parameter
D gcloud dataproc clusters update with the --num-workers parameter

Xem giải thích

Đáp án

C — gcloud dataproc clusters update với tham số --num-secondary-workers.

Vì sao đúng

⚠ Trong Dataproc, VM preemptible chính là SECONDARY WORKER: | Loại worker | Đặc điểm | |---|---| | ⚠ Primary worker | ⚠ VM thường, chạy HDFS DataNode, ổn định | | ⚠ Secondary worker | ⚠ preemptible hoặc Spot, CHỈ tính toán |

gcloud dataproc clusters update ten-cum \
  --region=asia-southeast1 \
  --num-secondary-workers=10

⚠ Cụm ĐANG CHẠY thay đổi được số worker — ⚠ không cần tạo lại.

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

D (--num-workers) — ⚠ thêm worker THƯỜNG, không phải preemptible: ⚠ đúng lệnh nhưng ⚠ sai loại worker; ⚠ đắt hơn nhiều.
B (--preemptible-vms) — ⚠ tham số KHÔNG tồn tại.
A (không đổi được số node preemptible sau khi tạo cụm) — ⚠ khẳng định SAI: ⚠ Dataproc cho phép thay đổi cả primary lẫn secondary worker của cụm đang chạy.

Ghi nhớ

⚠ Primary so với Secondary worker — bảng phải thuộc: | Tiêu chí | Primary | Secondary | |---|---|---| | ⚠ Loại VM | ⚠ thường | ⚠ preemptible/Spot (hoặc thường) | | ⚠ Chạy HDFS DataNode | ⚠ CÓ | ⚠ KHÔNG | | ⚠ Bị thu hồi | ⚠ không | ⚠ CÓ THỂ, bất cứ lúc nào | | ⚠ Giá | ⚠ đầy đủ | ⚠ rẻ hơn tới ~80% | | ⚠ Số lượng tối thiểu | ⚠ 2 (hoặc 0 với cụm single-node) | ⚠ 0 |

Từ khoá nhận diện:

"thêm VM preemptible vào Dataproc" → ⚠ --num-secondary-workers "thêm worker thường" → ⚠ --num-workers "job chết vì VM bị thu hồi" → ⚠ quá nhiều secondary, hoặc chưa bật EFM

⚠ Tỉ lệ secondary hợp lý	Tỉ lệ
⚠ Thường không quá 50% tổng số worker
⚠ Quá nhiều thì job hay phải làm lại
⚠ Dữ liệu HDFS chỉ nằm ở primary	⚠ nên primary phải đủ
⚠ Kết hợp tốt nhất	⚠ dữ liệu ở Cloud Storage, primary ít, secondary nhiều

⚠ VM preemptible / Spot — điều phải nhớ	Điều
⚠ Bị thu hồi bất cứ lúc nào, báo trước 30 giây
⚠ Preemptible cũ: tối đa 24 giờ	⚠ Spot VM: KHÔNG giới hạn thời gian
⚠ Rẻ hơn 60–91%
⚠ Hợp với: xử lý theo lô chịu được gián đoạn
⚠ KHÔNG hợp với: CSDL, dịch vụ trạng thái
⚠ Google khuyến nghị	⚠ dùng Spot VM thay cho preemptible

⚠ Bảo vệ job khi worker bị thu hồi	Cách
⚠ Bật Enhanced Flexibility Mode (EFM)	⚠ shuffle không nằm trên secondary
⚠ Giữ đủ primary worker
⚠ Dữ liệu ở Cloud Storage, không ở HDFS
⚠ Job chia nhỏ, có checkpoint

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỉ lệ secondary có quá cao không | | | EFM đã bật chưa | | | Job có hay phải chạy lại vì mất worker không | |

Và cách nghĩ đúng về VM preemptible: chúng không phải VM rẻ hơn, mà là VM có thể biến mất. Kiến trúc phải chịu được điều đó trước, rồi khoản tiết kiệm mới là món quà — chứ không phải ngược lại.

Câu 34 Data Analysis

Analysts are using Cloud Data Studio for analyzing data sets. They would like to improve the performance of the time required to update tables and charts when working with the data. What would you recommend they try to improve performance?

A Use a blended data source
B
Use an extracted data source
C Use an imported data source
D Use a live data source

Xem giải thích

Đáp án

B — Dùng nguồn dữ liệu trích xuất (extracted data source).

Ghi nhớ về chất lượng câu hỏi

⚠ Sản phẩm trong đề đã ĐỔI TÊN.

Thời điểm	Tên
⚠ Đề viết	⚠ Cloud Data Studio (Google Data Studio)
⚠ Hiện nay	⚠ Looker Studio
⚠ Bản trả phí	⚠ Looker Studio Pro

⚠ KHÔNG sửa khoá — ⚠ khái niệm extracted data source vẫn nguyên vẹn trong Looker Studio.

Vì sao đúng

⚠ Ba loại kết nối dữ liệu: | Loại | Cách hoạt động | Hiệu năng | |---|---|---| | ⚠ Live connection | ⚠ truy vấn thẳng nguồn mỗi lần | ⚠ chậm nếu nguồn chậm | | ⚠ Extracted | ⚠ chụp một BẢN TĨNH, lưu trong Looker Studio | ⚠ NHANH — đề này | | ⚠ Blended | ⚠ ghép nhiều nguồn | ⚠ thường CHẬM hơn |

⚠ Extract: lấy dữ liệu MỘT LẦN
        ↓
⚠ Lưu ở bộ nhớ trong của Looker Studio
        ↓
⚠ Biểu đồ đọc từ bản trích xuất
        ↓
⚠ Không phải chờ truy vấn nguồn
        ↓
⚠ Cập nhật biểu đồ NHANH hơn hẳn

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

D (live data source) — ⚠ chính là thứ đang chậm: ⚠ mỗi thao tác đều truy vấn lại nguồn.
A (blended data source) — ⚠ ghép nhiều nguồn, thường CHẬM HƠN: ⚠ không giải quyết vấn đề hiệu năng.
C (imported data source) — ⚠ không phải thuật ngữ của sản phẩm: ⚠ tên đúng là extract.

Ghi nhớ

⚠ Extract data source — đặc điểm phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Là ảnh chụp TĨNH | ⚠ không tự cập nhật theo thời gian thực | | ⚠ Lên lịch làm mới được | ⚠ hằng giờ, hằng ngày… | | ⚠ Có giới hạn dung lượng | ⚠ không hợp với dữ liệu rất lớn | | ⚠ Lọc và chọn cột trước khi trích | ⚠ giảm dung lượng | | ⚠ Đánh đổi | ⚠ NHANH nhưng dữ liệu KHÔNG mới nhất |

Từ khoá nhận diện:

"biểu đồ cập nhật chậm" → ⚠ extracted data source "cần dữ liệu thời gian thực" → ⚠ live connection, chấp nhận chậm hơn "tăng tốc truy vấn BigQuery cho BI" → ⚠ BigQuery BI Engine

⚠ Ba cách tăng tốc dashboard trên BigQuery	Cách
⚠ Extract data source	⚠ ở tầng công cụ BI
⚠ BigQuery BI Engine	⚠ bộ nhớ đệm trong RAM ở tầng BigQuery
⚠ Materialized view / bảng tổng hợp sẵn	⚠ ở tầng dữ liệu
⚠ Nên làm	⚠ tổng hợp sẵn ở tầng dữ liệu là bền vững nhất

⚠ Vì sao dashboard chậm	Nguyên nhân
⚠ Truy vấn quét quá nhiều dữ liệu	⚠ thiếu phân vùng
⚠ Quá nhiều biểu đồ trên một trang	⚠ mỗi cái một truy vấn
⚠ Blend nhiều nguồn
⚠ Tính toán phức tạp trong công cụ BI	⚠ nên đẩy về SQL
⚠ Nguyên tắc	⚠ tính toán ở gần dữ liệu, không ở gần biểu đồ

⚠ Sản phẩm BI của Google — phân biệt	Sản phẩm
⚠ Looker Studio	⚠ miễn phí, dashboard tự phục vụ — tên cũ Data Studio
⚠ Looker	⚠ nền tảng BI doanh nghiệp, có lớp mô hình LookML
⚠ Connected Sheets	⚠ truy vấn BigQuery từ Google Sheets
⚠ BI Engine	⚠ tăng tốc, không phải công cụ trực quan hoá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu cần mới tới mức nào | ⚠ quyết định extract hay live | | Truy vấn nguồn quét bao nhiêu dữ liệu | | | Có thể tổng hợp sẵn ở tầng dữ liệu không | |

Và câu hỏi nên đặt trước khi tối ưu bất kỳ dashboard nào: người xem thật sự cần dữ liệu mới đến mức nào?. Rất nhiều báo cáo được xây theo thời gian thực trong khi người đọc chỉ mở nó mỗi sáng một lần.

Câu 35 Data management

Epidemiology and infectious disease researchers are collecting data on the genomic sequences of several pathogens. The data is stored in a bioinformatics-specific format called FASTQ and are tens of gigabytes in size. They will eventually store several terabytes of FASTQ data. The data will be processed by Cloud Dataflow and results will be written to BigQuery. What is a good option for storing FASTQ data?

A Cloud Storage
B Bigtable
C Cloud Firestore
D BigQuery

Xem giải thích

Đáp án

A — Cloud Storage.

Vì sao đúng

⚠ Đặc điểm dữ liệu trong đề: | Đặc điểm | Suy ra | |---|---| | ⚠ Định dạng chuyên ngành FASTQ | ⚠ tệp thô, không phải dữ liệu bảng | | ⚠ Mỗi tệp hàng chục GB | ⚠ tệp lớn — kho đối tượng | | ⚠ Tổng vài terabyte | ⚠ cần rẻ và co giãn | | ⚠ Dataflow xử lý, kết quả vào BigQuery | ⚠ Cloud Storage là nguồn chuẩn cho Dataflow |

⚠ Tệp FASTQ → ⚠ Cloud Storage
        ↓ ⚠ Dataflow đọc
⚠ Xử lý, phân tích
        ↓
⚠ Kết quả có cấu trúc → ⚠ BigQuery

⚠ Mẫu kiến trúc kinh điển: ⚠ dữ liệu thô ở kho đối tượng, kết quả có cấu trúc ở kho phân tích.

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

D (BigQuery) — ⚠ BigQuery cho dữ liệu CÓ CẤU TRÚC dạng bảng: ⚠ FASTQ là định dạng văn bản chuyên ngành; ⚠ nạp thẳng vào là ⚠ đắt và không truy vấn được gì hữu ích; ⚠ nhưng BigQuery là nơi ghi KẾT QUẢ như đề nói.
B (Bigtable) — ⚠ cho truy vấn bằng khoá độ trễ thấp: ⚠ tệp hàng chục GB ⚠ vượt quá giới hạn kích thước ô của Bigtable.
C (Cloud Firestore) — ⚠ CSDL tài liệu, giới hạn ~1 MB mỗi tài liệu: ⚠ hoàn toàn không phù hợp.

Ghi nhớ

⚠ Chọn nơi lưu theo hình dạng dữ liệu — bảng phải thuộc: | Hình dạng | Nơi lưu | |---|---| | ⚠ Tệp lớn, định dạng bất kỳ | ⚠ Cloud Storage | | ⚠ Bảng, phân tích SQL | ⚠ BigQuery | | ⚠ Khoá-giá trị, độ trễ thấp, khối lượng lớn | ⚠ Bigtable | | ⚠ Tài liệu cho ứng dụng | ⚠ Firestore | | ⚠ Quan hệ giao dịch | ⚠ Cloud SQL / Spanner |

Từ khoá nhận diện:

"tệp lớn, định dạng chuyên ngành" → ⚠ Cloud Storage "kết quả phân tích có cấu trúc" → ⚠ BigQuery "Dataflow đọc từ đâu" → ⚠ thường là Cloud Storage hoặc Pub/Sub

⚠ Giới hạn kích thước phải nhớ	Giới hạn
⚠ Cloud Storage: 5 TB mỗi object	⚠ thoải mái cho FASTQ
⚠ Bigtable: khuyến nghị dưới 10 MB mỗi ô
⚠ Firestore: 1 MB mỗi tài liệu
⚠ Pub/Sub: 10 MB mỗi tin nhắn
⚠ Tệp lớn qua Pub/Sub	⚠ gửi ĐƯỜNG DẪN, không gửi nội dung

⚠ Kiến trúc data lake trên Google Cloud	Kiến trúc
⚠ Cloud Storage làm lớp lưu trữ thô
⚠ Dataflow hoặc Dataproc xử lý
⚠ BigQuery làm lớp phân tích
⚠ Dataplex quản trị toàn bộ
⚠ Nguyên tắc	⚠ giữ dữ liệu THÔ nguyên vẹn, xử lý lại được khi đổi yêu cầu

⚠ Tối ưu chi phí cho dữ liệu khoa học	Tối ưu
⚠ Nén tệp trước khi lưu	⚠ FASTQ nén rất tốt
⚠ Lifecycle chuyển sang Coldline/Archive	⚠ dữ liệu cũ ít dùng
⚠ Chia tệp để Dataflow đọc song song
⚠ Chọn vùng gần nơi tính toán	⚠ tránh phí truyền liên vùng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu thô có được giữ nguyên vẹn không | | | Tệp có chia nhỏ để đọc song song được không | | | Lifecycle đã đặt cho dữ liệu cũ chưa | |

Và nguyên tắc nền của mọi data lake: giữ dữ liệu thô mãi mãi, dữ liệu đã xử lý thì dựng lại được. Yêu cầu phân tích sẽ đổi; nếu bạn đã vứt bản gốc đi thì không có cách nào quay lại.

Câu 36 Databases

A data engineer needs to load data stored in Avro files in Cloud Storage into Bigtable. They would like to have a reliable, easily monitored process for copying the data. What would you recommend they use to copy the data?

A Storage Transfer Service
B gsutil
C Cloud Dataflow, starting with a Cloud Storage Avro to Bigtable template.
D Custom Python 3 program

Xem giải thích

Đáp án

C — Dùng Cloud Dataflow, bắt đầu từ template "Cloud Storage Avro to Bigtable".

Vì sao đúng

⚠ Đề yêu cầu quy trình ĐÁNG TIN CẬY và DỄ GIÁM SÁT: | Yêu cầu | Dataflow template | |---|---| | ⚠ Đáng tin cậy | ⚠ tự thử lại, xử lý lỗi, chạy song song | | ⚠ Dễ giám sát | ⚠ giao diện Job Metrics, log tích hợp, cảnh báo | | ⚠ Ít công sức | ⚠ template có SẴN cho đúng cặp Avro → Bigtable |

⚠ Tệp Avro ở Cloud Storage
        ↓ ⚠ Dataflow template
   ⚠ đọc song song, tự co giãn
        ↓
⚠ Ghi vào Bigtable
        ↓
⚠ Theo dõi tiến độ, số bản ghi,
   lỗi ngay trên giao diện

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

D (chương trình Python 3 tự viết) — ⚠ phải tự làm mọi thứ: ⚠ tự chia việc, tự thử lại, tự giám sát, tự xử lý lỗi giữa chừng; ⚠ và ⚠ một tiến trình đơn thì rất chậm.
B (gsutil) — ⚠ gsutil chỉ SAO CHÉP TỆP: ⚠ nó không nạp dữ liệu vào Bigtable, ⚠ không hiểu định dạng Avro.
A (Storage Transfer Service) — ⚠ chuyển tệp GIỮA các kho lưu trữ: ⚠ từ S3, từ URL, giữa các bucket; ⚠ không ghi vào Bigtable.

Ghi nhớ

⚠ Dataflow template dựng sẵn hay gặp — bảng phải thuộc: | Template | Việc | |---|---| | ⚠ Cloud Storage Avro → Bigtable | ⚠ đề này | | ⚠ Pub/Sub → BigQuery | ⚠ phổ biến nhất cho streaming | | ⚠ Cloud Storage Text → BigQuery | | | ⚠ BigQuery → Cloud Storage | | | ⚠ Datastore/Firestore → Cloud Storage | | | ⚠ Lợi ích | ⚠ không cần viết mã Beam nào |

Từ khoá nhận diện:

"nạp dữ liệu có định dạng vào CSDL, cần đáng tin cậy" → ⚠ Dataflow template "chỉ sao chép tệp giữa các bucket" → ⚠ gsutil hoặc Storage Transfer Service "chuyển từ AWS S3 sang Cloud Storage" → ⚠ Storage Transfer Service "cần biến đổi phức tạp" → ⚠ Dataflow tự viết bằng Beam

⚠ Vì sao đừng tự viết script nạp dữ liệu	Lý do
⚠ Chạy được nửa chừng rồi chết thì sao
⚠ Có ghi trùng khi chạy lại không
⚠ Ai biết nó đang chạy tới đâu
⚠ Một tiến trình không song song hoá được
⚠ Dataflow lo sẵn	⚠ cả bốn vấn đề trên

⚠ Ba cách chạy Dataflow	Cách
⚠ Template dựng sẵn của Google	⚠ nhanh nhất, không cần mã
⚠ Flex template tự tạo	⚠ đóng gói pipeline của mình thành template
⚠ Chạy trực tiếp từ mã Beam	⚠ linh hoạt nhất
⚠ Chọn	⚠ có template sẵn thì luôn thử template trước

⚠ Nạp dữ liệu vào Bigtable — lưu ý	Lưu ý
⚠ Row key quyết định tất cả	⚠ nạp sai khoá là phải làm lại từ đầu
⚠ Ghi tuần tự gây điểm nóng	⚠ kể cả lúc nạp lần đầu
⚠ Cân nhắc tăng node tạm thời khi nạp	⚠ rồi giảm lại
⚠ Nạp là idempotent nếu cùng row key	⚠ ghi đè, không nhân đôi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có template sẵn cho cặp nguồn–đích này không | ⚠ kiểm tra trước khi viết mã | | Row key đã thiết kế xong chưa | | | Job có bị nghẽn ở bước nào không | ⚠ xem Job Metrics |

Và câu hỏi nên hỏi trước mỗi lần định viết script chuyển dữ liệu: đã có template cho việc này chưa?. Phần lớn các cặp nguồn–đích phổ biến đều đã có, và một template được Google bảo trì luôn đáng tin hơn script chạy trên máy của ai đó.

Câu 37 Data Analysis

You are migrating a data warehouse from on-premises to Google Cloud. Users of the data warehouse are concerned that they will not have access to highly performant, in memory analysis. What service would you suggest to have comparable features and performance in Google Cloud?

A Bigtable with BI Engine
B BigQuery with Cloud Memorystore using Redis
C BigQuery Cloud Memorystore with memcached
D BigQuery BI Engine

Xem giải thích

Đáp án

D — BigQuery BI Engine.

Vì sao đúng

⚠ Đề nêu: người dùng lo mất khả năng phân tích trong BỘ NHỚ (in-memory) hiệu năng cao.

⚠ BI Engine
        ↓
⚠ Lớp phân tích TRONG BỘ NHỚ
   tích hợp SẴN trong BigQuery
        ↓
⚠ Tự động lưu đệm dữ liệu
   hay dùng vào RAM
        ↓
⚠ Truy vấn dashboard trả về
   trong dưới một giây

Đặc điểm	Nội dung
⚠ Không cần đổi truy vấn	⚠ SQL giữ nguyên
⚠ Không cần quản hạ tầng	⚠ chỉ đặt dung lượng RAM
⚠ Tự chọn dữ liệu nào nên nằm trong RAM

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

B (BigQuery + Memorystore Redis) và C (BigQuery + Memorystore Memcached) — ⚠ Memorystore là bộ nhớ đệm cho ỨNG DỤNG: ⚠ nó không tăng tốc truy vấn BigQuery; ⚠ bạn phải tự viết mã lưu và đọc đệm.
A (Bigtable với BI Engine) — ⚠ BI Engine chỉ hoạt động với BigQuery: ⚠ không dùng cho Bigtable.

Ghi nhớ

⚠ Các lớp tăng tốc trong BigQuery — bảng phải thuộc: | Cách | Nội dung | |---|---| | ⚠ BI Engine | ⚠ phân tích trong RAM, cho dashboard — đề này | | ⚠ Materialized view | ⚠ kết quả tổng hợp tính sẵn | | ⚠ Phân vùng (partition) | ⚠ giảm dữ liệu quét | | ⚠ Phân cụm (cluster) | ⚠ sắp xếp theo cột hay lọc | | ⚠ Cache kết quả truy vấn | ⚠ MIỄN PHÍ, tự động, giữ 24 giờ |

Từ khoá nhận diện:

"phân tích trong bộ nhớ, dashboard nhanh" → ⚠ BI Engine "bộ nhớ đệm cho ứng dụng" → ⚠ Memorystore "giảm dữ liệu quét" → ⚠ phân vùng và phân cụm "truy vấn giống hệt lần trước" → ⚠ cache kết quả, miễn phí

⚠ BI Engine — chi tiết phải nhớ	Chi tiết
⚠ Đặt dung lượng RAM theo project và vùng
⚠ Tự chọn bảng và cột nào cần đệm	⚠ dựa trên mẫu truy vấn
⚠ Tích hợp trong suốt	⚠ không sửa truy vấn
⚠ Hợp nhất với Looker Studio, Looker, Sheets
⚠ Giới hạn	⚠ không phải truy vấn nào cũng được tăng tốc

⚠ Cache kết quả truy vấn — miễn phí và hay bị quên	Đặc điểm
⚠ Truy vấn Y HỆT trên bảng KHÔNG đổi	⚠ trả kết quả cũ, KHÔNG tính phí
⚠ Giữ 24 giờ
⚠ Hỏng cache khi bảng thay đổi
⚠ Mẹo	⚠ dùng truy vấn tham số hoá ổn định để tận dụng cache

⚠ Thứ tự nên thử khi tối ưu BigQuery	Thứ tự
⚠ 1. Phân vùng và phân cụm bảng	⚠ hiệu quả nhất, rẻ nhất
*⚠ 2. Bỏ `SELECT `**
⚠ 3. Materialized view cho truy vấn lặp
⚠ 4. BI Engine cho dashboard
⚠ 5. Mua slot nếu khối lượng ổn định

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng đã phân vùng chưa | ⚠ làm trước khi nghĩ tới BI Engine | | Dung lượng BI Engine đặt bao nhiêu | | | Truy vấn có thật sự được tăng tốc không | ⚠ xem chi tiết trong execution details |

Và sai lầm hay gặp khi tối ưu hiệu năng phân tích: mua thêm bộ nhớ trước khi sửa cách quét dữ liệu. Một bảng chưa phân vùng sẽ ngốn hết mọi khoản RAM bạn ném vào nó, và vẫn chậm.

Câu 38 Databases

An IoT service uses Bigtable to store timeseries data. You have noticed that write operations tend to happen on one node at a time rather than being evenly distributed across nodes. What could be the cause of this problem?

A
Using the wrong type of GCP load balancer in front of Bigtable
B Using too many columns in your data model
C Misconfiguring replication
D
Using a row key that causes data that arrives close in time to be written to a single node, rather than evenly distributed.

Xem giải thích

Đáp án

D — Dùng row key khiến dữ liệu tới gần nhau về thời gian bị ghi vào MỘT node thay vì rải đều.

Ghi nhớ về chất lượng câu hỏi

⚠ Câu này GẦN TRÙNG với #16197 trong cùng lô.

Câu	Góc hỏi
⚠ #16197	⚠ đã dùng UUID mà vẫn nóng — vì UUID có thứ tự
⚠ #16223 (câu này)	⚠ vì sao ghi dồn vào một node
⚠ Cùng nguyên nhân	⚠ row key khiến dữ liệu gần nhau về thời gian nằm gần nhau về khoá
⚠ Khoá nhất quán	⚠ cả hai đều trỏ về thiết kế row key

Vì sao đúng

⚠ Cách Bigtable chia việc:

⚠ Bảng chia thành TABLET theo
   KHOẢNG row key
        ↓
⚠ Mỗi tablet do MỘT node phục vụ
        ↓
⚠ Row key bắt đầu bằng dấu thời gian
        ↓
⚠ Mọi ghi mới có khoá LIỀN KỀ
        ↓
⚠ Cùng rơi vào tablet CUỐI
        ↓
⚠ MỘT node gánh hết, các node khác rảnh

⚠ Đây là lỗi thiết kế kinh điển với dữ liệu chuỗi thời gian.

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

B (dùng quá nhiều cột) — ⚠ ảnh hưởng dung lượng và hiệu năng đọc: ⚠ không gây phân bố ghi lệch.
C (cấu hình nhân bản sai) — ⚠ nhân bản là giữa các CỤM: ⚠ không quyết định phân bố trong một cụm.
A (dùng sai loại load balancer trước Bigtable) — ⚠ KHÔNG có load balancer trước Bigtable: ⚠ client thư viện tự định tuyến tới đúng node.

Ghi nhớ

⚠ Thiết kế row key cho chuỗi thời gian — bảng phải thuộc: | Cách | Đánh giá | |---|---| | ⚠ timestamp#thietbi | ⚠ SAI — điểm nóng nặng | | ⚠ thietbi#timestamp | ⚠ TỐT — rải theo thiết bị, quét được theo thiết bị | | ⚠ hash(thietbi)#thietbi#timestamp | ⚠ rải đều hơn nữa | | ⚠ thietbi#(MAX-timestamp) | ⚠ bản ghi MỚI NHẤT lên đầu |

Từ khoá nhận diện:

"ghi dồn vào một node" → ⚠ row key tuần tự "muốn lấy bản ghi mới nhất nhanh" → ⚠ dấu thời gian đảo ngược "nhìn thấy điểm nóng" → ⚠ Key Visualizer

⚠ Vì sao chuỗi thời gian dễ sai nhất	Lý do
⚠ Bản năng đầu tiên là đặt thời gian lên trước	⚠ vì muốn quét theo thời gian
⚠ Nhưng mọi ghi mới đều ở cuối bảng
⚠ Lúc thử với ít dữ liệu thì không thấy vấn đề
⚠ Chỉ lộ ra khi lên quy mô thật
⚠ Cách đúng	⚠ đặt trường có ĐỘ PHÂN TÁN CAO lên trước

⚠ Dấu hiệu điểm nóng	Dấu hiệu
⚠ CPU một node rất cao, các node khác thấp
⚠ Thêm node không cải thiện thông lượng	⚠ triệu chứng rõ nhất
⚠ Độ trễ ghi tăng dần theo thời gian
⚠ Key Visualizer có vệt sáng dọc

⚠ Nếu đã lỡ thiết kế sai row key	Cách chữa
⚠ KHÔNG đổi row key tại chỗ được
⚠ Phải tạo bảng mới và chép lại	⚠ Dataflow
⚠ Chi phí lớn khi dữ liệu đã nhiều
⚠ Bài học	⚠ thiết kế row key là quyết định gần như không đảo ngược

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thêm node có tăng thông lượng không | ⚠ không tăng là có điểm nóng | | Key Visualizer cho thấy gì | | | Trường đầu tiên của row key có độ phân tán cao không | |

Và điều khiến lỗi này đắt hơn mọi lỗi khác trong Bigtable: nó không sửa được tại chỗ. Một row key sai chỉ có thể chữa bằng cách chép lại toàn bộ bảng, và bảng thì mỗi ngày một lớn.

Câu 39 Machine learning

You are developing a deep learning model and have training data with a large number of features. You are not sure which features are important. You'd like to use a regularization technique that will drive the parameter for the least important features toward zero. What regularization technique would you use?

A Dropout
B Backpropagation
C L2 or Ridge Regression
D L1 or Lasso Regression

Xem giải thích

Đáp án

D — L1, còn gọi là Lasso Regression.

Vì sao đúng

⚠ Khác biệt cốt lõi giữa L1 và L2: | Kỹ thuật | Phạt theo | Kết quả | |---|---|---| | ⚠ L1 (Lasso) | ⚠ GIÁ TRỊ TUYỆT ĐỐI của trọng số | ⚠ đẩy trọng số về ĐÚNG 0 | | ⚠ L2 (Ridge) | ⚠ BÌNH PHƯƠNG trọng số | ⚠ thu nhỏ nhưng KHÔNG về 0 |

⚠ Đề cần: đẩy tham số của đặc trưng
   KÉM QUAN TRỌNG NHẤT về 0
        ↓
⚠ Trọng số = 0 nghĩa là
   ⚠ đặc trưng đó bị LOẠI hẳn
        ↓
⚠ Chỉ L1 làm được điều này
        ↓
⚠ L1 = CHỌN ĐẶC TRƯNG tự động

⚠ Đúng nhu cầu của đề: ⚠ "không chắc đặc trưng nào quan trọng".

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

C (L2 / Ridge) — ⚠ bẫy gần nhất: ⚠ L2 thu nhỏ mọi trọng số ⚠ nhưng ⚠ không bao giờ đưa về đúng 0; ⚠ đặc trưng vô ích vẫn còn trong mô hình.
A (dropout) — ⚠ kỹ thuật chống quá khớp cho mạng nơ-ron: ⚠ tắt ngẫu nhiên nơ-ron khi huấn luyện; ⚠ không chọn đặc trưng.
B (backpropagation) — ⚠ KHÔNG phải regularization: ⚠ đó là thuật toán huấn luyện — cách tính đạo hàm để cập nhật trọng số.

Ghi nhớ

⚠ L1 so với L2 — bảng phải thuộc: | Tiêu chí | ⚠ L1 (Lasso) | ⚠ L2 (Ridge) | |---|---|---| | ⚠ Hàm phạt | ⚠ tổng |w| | ⚠ tổng w² | | ⚠ Trọng số về 0 | ⚠ CÓ | ⚠ KHÔNG | | ⚠ Chọn đặc trưng | ⚠ CÓ — tự động | ⚠ không | | ⚠ Mô hình thưa (sparse) | ⚠ CÓ | ⚠ không | | ⚠ Với đặc trưng tương quan cao | ⚠ chọn một, bỏ cái kia | ⚠ chia đều trọng số |

Từ khoá nhận diện:

"đẩy tham số về 0, chọn đặc trưng" → ⚠ L1 / Lasso "thu nhỏ trọng số, giữ mọi đặc trưng" → ⚠ L2 / Ridge "kết hợp cả hai" → ⚠ Elastic Net "chống quá khớp cho mạng nơ-ron" → ⚠ dropout, dừng sớm

⚠ Vì sao L1 đưa được về đúng 0	Lý do
⚠ Đạo hàm của \|w\| là hằng số	⚠ lực đẩy về 0 không giảm khi w nhỏ
⚠ Đạo hàm của w² tỉ lệ với w	⚠ w càng nhỏ lực càng yếu — không bao giờ tới 0
⚠ Hình học	⚠ vùng ràng buộc của L1 có GÓC NHỌN nằm trên trục toạ độ

⚠ Regularization — mục đích chung	Mục đích
⚠ Chống QUÁ KHỚP
⚠ Phạt mô hình quá phức tạp
⚠ Cải thiện khả năng tổng quát hoá
⚠ Tham số lambda	⚠ quá lớn → chưa khớp; quá nhỏ → không có tác dụng
⚠ Lưu ý	⚠ phải CHUẨN HOÁ đặc trưng trước khi dùng regularization

⚠ Các cách chọn đặc trưng khác	Cách
⚠ L1 regularization	⚠ tự động trong lúc huấn luyện
⚠ Feature importance từ cây quyết định
⚠ Phân tích tương quan	⚠ loại đặc trưng trùng lặp
⚠ SHAP values	⚠ giải thích đóng góp từng đặc trưng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đặc trưng đã được chuẩn hoá chưa | ⚠ không thì regularization phạt lệch | | Bao nhiêu trọng số bị đưa về 0 | ⚠ cho biết bao nhiêu đặc trưng thật sự có ích | | Lambda đã dò bằng cross-validation chưa | |

Và giá trị thực dụng nhất của L1 ngoài việc chống quá khớp: nó nói cho bạn biết đặc trưng nào không đáng thu thập. Một trọng số bằng 0 là lời khuyên bỏ hẳn cột dữ liệu đó khỏi đường ống.

Câu 40 Databases

A team of data scientists has been using an on-premises cluster running Hadoop and HBase. They want to migrate to a managed service in Google Cloud. They also want to minimize changes to programs that make extensive use of the HBase API. What GCP service would you recommend?

A Cloud Spanner
B Bigtable
C BigQuery
D Cloud Dataflow

Xem giải thích

Đáp án

B — Bigtable.

Ghi nhớ về chất lượng câu hỏi

⚠ Câu này GẦN TRÙNG với #16199 trong cùng lô.

Câu	Bối cảnh
⚠ #16199	⚠ IoT drone, từng dùng HBase, cần ghi lớn độ trễ thấp
⚠ #16225 (câu này)	⚠ cụm Hadoop + HBase, muốn ít sửa mã dùng HBase API
⚠ Cùng khoá	⚠ Bigtable
⚠ Nhớ một điều	⚠ HBase API ⇒ Bigtable, không cần nghĩ thêm

Vì sao đúng

⚠ Yêu cầu quyết định của đề: ⚠ giảm tối đa thay đổi trong chương trình dùng nhiều HBase API.

⚠ Bigtable hỗ trợ HBase API
        ↓
⚠ Thư viện client HBase cho Java
   dùng được với Bigtable
        ↓
⚠ Đổi cấu hình kết nối là chính
        ↓
⚠ Mã nghiệp vụ gần như GIỮ NGUYÊN

⚠ Không có dịch vụ nào khác trên Google Cloud tương thích HBase API.

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

C (BigQuery) — ⚠ kho phân tích, dùng SQL: ⚠ phải viết lại toàn bộ mã HBase.
A (Cloud Spanner) — ⚠ CSDL quan hệ, dùng SQL: ⚠ mô hình dữ liệu khác hẳn, ⚠ và ⚠ đắt hơn nhiều.
D (Cloud Dataflow) — ⚠ dịch vụ XỬ LÝ dữ liệu, không phải CSDL: ⚠ không lưu trữ gì lâu dài.

Ghi nhớ

⚠ Tương thích API khi di trú — bảng phải thuộc: | Nguồn | Đích | Mức tương thích | |---|---|---| | ⚠ HBase | ⚠ Bigtable | ⚠ CÙNG API — chỉ đổi cấu hình | | ⚠ MySQL/PostgreSQL | ⚠ Cloud SQL | ⚠ cùng giao thức | | ⚠ Redis | ⚠ Memorystore | ⚠ cùng giao thức | | ⚠ Kafka | ⚠ Pub/Sub | ⚠ KHÁC API — phải viết lại | | ⚠ Hive | ⚠ BigQuery | ⚠ SQL gần giống nhưng có khác biệt |

Từ khoá nhận diện:

"giữ nguyên mã HBase" → ⚠ Bigtable "giữ nguyên cụm Hadoop/Spark" → ⚠ Dataproc "giữ nguyên mã Kafka" → ⚠ tự chạy Kafka trên GKE, hoặc viết lại sang Pub/Sub

⚠ Hai lựa chọn khi di trú Hadoop	Lựa chọn
⚠ Nâng và chuyển (lift and shift)	⚠ Dataproc — giữ nguyên Hadoop, HBase, Spark
⚠ Hiện đại hoá	⚠ BigQuery, Dataflow, Bigtable — thay từng mảnh
⚠ Chiến lược thường dùng	⚠ chuyển sang Dataproc trước cho nhanh, rồi hiện đại hoá dần
⚠ Đề này	⚠ Bigtable cho tầng CSDL, có thể kèm Dataproc cho tầng tính toán

⚠ Khác biệt cần biết khi từ HBase sang Bigtable	Khác biệt
⚠ Không có coprocessor	⚠ mã chạy phía máy chủ phải chuyển ra ngoài
⚠ Không có giao dịch trên nhiều dòng	⚠ HBase cũng hạn chế tương tự
⚠ Bigtable tự quản chia tablet	⚠ không cần tự split region
⚠ Không có namespace như HBase
⚠ Nên kiểm	⚠ mã có dùng tính năng HBase nào không có trên Bigtable không

⚠ Vì sao chuyển sang dịch vụ được quản	Lý do
⚠ Không phải vá, nâng cấp, cân bằng cụm
⚠ Co giãn bằng cách đổi số node
⚠ Nhân bản đa vùng có sẵn
⚠ SLA và hỗ trợ
⚠ Đánh đổi	⚠ ít tuỳ biến sâu hơn cụm tự quản

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mã có dùng coprocessor không | ⚠ phải viết lại phần đó | | Thiết kế row key hiện tại có gây điểm nóng không | ⚠ cơ hội sửa lúc di trú | | Dữ liệu có trên 1 TB không | ⚠ dưới đó Bigtable hơi đắt |

Và cơ hội mà mọi cuộc di trú CSDL nên tận dụng: thiết kế lại row key. Đó là lần duy nhất bạn được chép lại toàn bộ dữ liệu mà không ai coi là một sự cố.

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

Đá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

Ghi nhớ về chất lượng câu hỏi

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

Ghi nhớ về chất lượng câu hỏi

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

Ghi nhớ về chất lượng câu hỏi

Vì sao đúng

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

Ghi nhớ