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

Câu 91 Chọn nhiều đáp án Data pipelines

You are currently using Apache Kafka to ingest messages from IoT sensors. A data pipeline based on Apache Flink reads the data from Kafka and processes the data before writing results to long-term storage. If you wanted to migrate to Google Cloud and use managed services instead of Apache Kafka and Apache Flink, what services would you use? (Choose 2)

A Cloud Pub/Sub
B Cloud Dataflow
C
Cloud Firestore
D Cloud Data Fusion
E Cloud Composer

Xem giải thích

Đáp án

A và B — Cloud Pub/Sub và Cloud Dataflow.

Vì sao đúng

⚠ Ánh xạ một-một giữa hai hệ sinh thái: | Đang dùng | Thay bằng | |---|---| | ⚠ Apache Kafka | ⚠ Cloud Pub/Sub | | ⚠ Apache Flink | ⚠ Cloud Dataflow |

⚠ Cảm biến IoT
        ↓ ⚠ Kafka → ⚠ Pub/Sub
⚠ Hàng đợi tin nhắn
        ↓ ⚠ Flink → ⚠ Dataflow
⚠ Xử lý luồng
        ↓
⚠ Lưu trữ dài hạn
   ⚠ (Cloud Storage / BigQuery)

⚠ Cả hai đều là dịch vụ HOÀN TOÀN ĐƯỢC QUẢN — ⚠ không phải vận hành cụm nào.

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

D (Cloud Data Fusion) — ⚠ công cụ ETL kéo thả: ⚠ không thay thế được Flink cho xử lý luồng phức tạp.
E (Cloud Composer) — ⚠ điều phối luồng công việc: ⚠ lập lịch và phụ thuộc, ⚠ không xử lý luồng dữ liệu.
C (Cloud Firestore) — ⚠ CSDL tài liệu: ⚠ không thay thế Kafka lẫn Flink.

Ghi nhớ

⚠ Ánh xạ mã nguồn mở sang Google Cloud — bảng phải thuộc: | Mã nguồn mở | Google Cloud | |---|---| | ⚠ Kafka | ⚠ Pub/Sub | | ⚠ Flink, Spark Streaming, Beam | ⚠ Dataflow | | ⚠ Spark, Hadoop | ⚠ Dataproc | | ⚠ Airflow | ⚠ Cloud Composer | | ⚠ HBase | ⚠ Bigtable | | ⚠ Hive | ⚠ BigQuery | | ⚠ Redis | ⚠ Memorystore | | ⚠ Kubernetes | ⚠ GKE |

Từ khoá nhận diện:

"thay Kafka" → ⚠ Pub/Sub "thay Flink/Spark Streaming" → ⚠ Dataflow "giữ nguyên mã Spark" → ⚠ Dataproc "giữ nguyên mã Kafka" → ⚠ Managed Service for Apache Kafka, hoặc tự chạy trên GKE

⚠ Pub/Sub so với Kafka — khác biệt phải biết	Khác biệt
⚠ Pub/Sub: KHÔNG phải quản broker, partition	⚠ co giãn tự động
⚠ Kafka: kiểm soát chi tiết hơn, có log giữ lâu
⚠ Pub/Sub: thứ tự cần ordering key	⚠ Kafka giữ thứ tự trong partition
⚠ Pub/Sub: giữ tin tới 7 ngày	⚠ Kafka cấu hình được lâu hơn nhiều
⚠ Nếu buộc phải giữ API Kafka	⚠ Google có Managed Service for Apache Kafka

⚠ Dataflow so với Flink	So sánh
⚠ Cả hai dựa trên mô hình dataflow tương tự
⚠ Beam có Flink runner	⚠ mã Beam chạy được trên Flink và ngược chiều một phần
⚠ Dataflow: không quản cụm, tự co giãn
⚠ Flink: kiểm soát chi tiết hơn, chạy ở đâu cũng được
⚠ Di trú	⚠ thường phải viết lại pipeline bằng Beam

⚠ Ước lượng công sức di trú	Công sức
⚠ Kafka → Pub/Sub: đổi client, xử lý khác biệt về thứ tự
⚠ Flink → Beam: viết lại logic pipeline	⚠ phần tốn công nhất
⚠ Chạy song song một thời gian để đối chiếu	⚠ rất nên làm
⚠ Lợi ích	⚠ bỏ hẳn việc vận hành hai cụm phân tán

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hệ thống có phụ thuộc thứ tự tin nhắn không | ⚠ cần ordering key | | Cần giữ tin nhắn bao lâu | ⚠ Pub/Sub tối đa 7 ngày | | Có chạy song song để đối chiếu kết quả không | |

Và lợi ích thật sự của cuộc di trú này không nằm ở tính năng: nó xoá đi hai cụm phân tán phải trực ca. Kafka và Flink đều mạnh, và cả hai đều đòi người hiểu sâu để giữ cho chúng khoẻ mạnh lúc 3 giờ sáng.

Câu 92 Chọn nhiều đáp án Databases

Your BigQuery costs are higher than expected. You want to help data analysts using the BigQuery data warehouse reduce overall costs. Which of the following would you recommend? (choose 2)

A Avoid using SELECT *
B Avoid using partitioned tables
C Avoid using clustered tables
D Use LIMIT only with clustered tables
E Use the bq --estimate-bytes command to estimate the number of bytes read

Xem giải thích

Đáp án

A và D — Tránh dùng SELECT *, và chỉ dùng LIMIT với bảng đã phân cụm (clustered).

Vì sao đúng

⚠ A — vì sao SELECT * đắt:

⚠ BigQuery là kho CỘT
        ↓
⚠ Tính phí theo SỐ BYTE của các CỘT được đọc
        ↓
⚠ SELECT * = ⚠ đọc MỌI cột
        ↓
⚠ Bảng 100 cột mà chỉ cần 3 cột
   → ⚠ trả tiền gấp nhiều lần

⚠ D — vì sao LIMIT KHÔNG giảm chi phí (trừ bảng phân cụm):

⚠ SELECT * FROM bang LIMIT 10
        ↓
⚠ BigQuery vẫn QUÉT TOÀN BỘ bảng
   rồi mới cắt lấy 10 dòng
        ↓
⚠ Chi phí KHÔNG giảm
        ↓
⚠ NGOẠI LỆ: bảng đã PHÂN CỤM
   ⚠ có thể bỏ qua khối dữ liệu không cần

⚠ Đây là hiểu lầm phổ biến nhất về chi phí BigQuery.

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

B (tránh dùng bảng phân vùng) — ⚠ NGƯỢC HOÀN TOÀN: ⚠ phân vùng là ⚠ cách giảm chi phí hiệu quả nhất.
C (tránh dùng bảng phân cụm) — ⚠ cũng ngược lại: ⚠ phân cụm giúp giảm dữ liệu quét.
E (bq --estimate-bytes) — ⚠ cờ này KHÔNG tồn tại: ⚠ cách đúng là ⚠ bq query --dry_run.

Ghi nhớ

⚠ Giảm chi phí BigQuery — bảng phải thuộc: | Cách | Hiệu quả | |---|---| | ⚠ PHÂN VÙNG theo ngày | ⚠ cao nhất — chỉ quét phân vùng cần | | ⚠ PHÂN CỤM theo cột hay lọc | ⚠ cao | | ⚠ Chọn đúng cột, bỏ SELECT * | ⚠ cao | | ⚠ Materialized view cho truy vấn lặp | | | ⚠ Đặt hạn mức chi tiêu | ⚠ chặn hoá đơn bất ngờ | | ⚠ --dry_run xem trước | ⚠ MIỄN PHÍ |

Từ khoá nhận diện:

"giảm chi phí truy vấn" → ⚠ **phân vùng, phân cụm, bỏ SELECT *** "LIMIT có giảm chi phí không" → ⚠ KHÔNG, trừ bảng phân cụm "xem trước sẽ quét bao nhiêu" → ⚠ bq query --dry_run "chi phí ổn định" → ⚠ mua slot

⚠ Phân vùng so với phân cụm	Phân biệt
⚠ Phân vùng: chia bảng theo NGÀY, số nguyên, hoặc thời gian nạp	⚠ tối đa 4.000 phân vùng
⚠ Phân cụm: SẮP XẾP dữ liệu trong phân vùng theo tối đa 4 cột
⚠ Phân vùng: biết TRƯỚC sẽ quét bao nhiêu
⚠ Phân cụm: chi phí chỉ biết SAU khi chạy
⚠ Nên dùng	⚠ CẢ HAI cùng nhau
⚠ Ép dùng phân vùng	⚠ `require_partition_filter = true`

⚠ Những gì KHÔNG giảm chi phí	Không giảm
⚠ `LIMIT`	⚠ trừ bảng phân cụm
⚠ `ORDER BY`
⚠ Xem trước bảng trong giao diện	⚠ cái này MIỄN PHÍ, không tính là truy vấn
⚠ Chỉ có	⚠ giảm số CỘT và số PHÂN VÙNG được đọc mới giảm chi phí

⚠ Công cụ kiểm soát chi phí	Công cụ
⚠ `--dry_run`	⚠ ước tính trước, miễn phí
⚠ Custom quota theo project hoặc người dùng	⚠ chặn cứng
⚠ Cảnh báo ngân sách
⚠ Bảng thống kê INFORMATION_SCHEMA.JOBS	⚠ xem ai chạy truy vấn tốn nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng lớn đã phân vùng chưa | ⚠ việc đầu tiên phải làm | | Có bắt buộc bộ lọc phân vùng chưa | | | Ai đang chạy truy vấn tốn nhất | ⚠ INFORMATION_SCHEMA.JOBS |

Và hiểu lầm tốn tiền nhất mà gần như ai mới dùng BigQuery cũng mắc: LIMIT 10 không làm truy vấn rẻ đi. Một câu SELECT * FROM bang_10TB LIMIT 10 vẫn tính tiền cho đủ 10 TB.

Câu 93 Data Pipelines

Messages are unexpectedly accumulating in service using Cloud Pub/Sub. A developer unfamiliar with Cloud Pub/Sub has asked for our help in diagnosing the problem. What would you point out with respect to how messages are removed from Cloud Pub/Sub topics?

A Once at least one subscriber for each topic has acknowledged the message it will be deleted from storage.
B Once at least one subscriber for each bucket has acknowledged the message it will be deleted from storage.
C Once at least one subscriber for any subscription has acknowledged the message it will be deleted from storage.
D Once at least one subscriber for each subscription has acknowledged the message it will be deleted from storage.

Xem giải thích

Đáp án

D — Tin nhắn chỉ bị xoá khỏi kho lưu khi ÍT NHẤT MỘT subscriber của MỖI subscription đã xác nhận (ack).

Vì sao đúng

⚠ Quan hệ giữa topic, subscription và subscriber:

⚠ TOPIC
   ├── ⚠ Subscription A
   │      ├── subscriber A1
   │      └── subscriber A2
   └── ⚠ Subscription B
          └── subscriber B1
        ↓
⚠ Mỗi SUBSCRIPTION nhận MỘT BẢN SAO
   của mọi tin nhắn
        ↓
⚠ Trong một subscription, các subscriber
   CHIA NHAU tin nhắn
        ↓
⚠ Tin bị xoá khi MỌI subscription
   đều đã ack

⚠ Đây chính là lý do tin nhắn tồn đọng: ⚠ chỉ cần MỘT subscription không xử lý là ⚠ tin nhắn còn nằm đó.

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

C (một subscriber của BẤT KỲ subscription nào ack là xoá) — ⚠ bẫy gần nhất và sai nguy hiểm: ⚠ nếu đúng vậy thì ⚠ các subscription khác sẽ MẤT tin nhắn.
A (một subscriber của mỗi TOPIC ack) — ⚠ subscriber gắn với SUBSCRIPTION, không gắn với topic.
B (một subscriber của mỗi BUCKET) — ⚠ "bucket" không phải khái niệm của Pub/Sub.

Ghi nhớ

⚠ Mô hình Pub/Sub — bảng phải thuộc: | Khái niệm | Vai trò | |---|---| | ⚠ Topic | ⚠ nơi publisher gửi tin | | ⚠ Subscription | ⚠ một LUỒNG NHẬN độc lập, có bản sao riêng | | ⚠ Subscriber | ⚠ tiến trình đọc từ subscription | | ⚠ Nhiều subscription | ⚠ fan-out: mỗi hệ thống hạ nguồn một subscription | | ⚠ Nhiều subscriber trong một subscription | ⚠ chia tải, mỗi tin chỉ một subscriber nhận |

Từ khoá nhận diện:

"tin nhắn không bị xoá" → ⚠ có subscription nào chưa ack "nhiều hệ thống cùng nhận mọi tin" → ⚠ nhiều SUBSCRIPTION "chia tải xử lý" → ⚠ nhiều SUBSCRIBER trong một subscription

⚠ Nguyên nhân tin nhắn tồn đọng	Nguyên nhân
⚠ Có subscription MỒ CÔI không ai đọc	⚠ nguyên nhân số một, hay bị quên
⚠ Subscriber xử lý chậm hơn tốc độ gửi
⚠ Ack deadline quá ngắn → giao lại vô hạn
⚠ Subscriber trả lỗi liên tục	⚠ cần dead-letter topic
⚠ Chẩn đoán	⚠ `num_undelivered_messages` theo TỪNG subscription

⚠ Subscription mồ côi — mối nguy thầm lặng	Mối nguy
⚠ Tạo ra để thử rồi quên xoá
⚠ Tin nhắn dồn tới hạn 7 ngày
⚠ Tốn phí lưu trữ tin nhắn
⚠ Không có cảnh báo nếu không ai đặt
⚠ Nên làm	⚠ rà soát subscription định kỳ, đặt hạn hết hiệu lực (expiration policy)

⚠ Vòng đời một tin nhắn	Vòng đời
⚠ Publisher gửi vào topic
⚠ Pub/Sub tạo bản sao cho MỖI subscription
⚠ Giao cho subscriber, chờ ack
⚠ Không ack trong deadline → giao lại
⚠ Mọi subscription ack → XOÁ
⚠ Quá thời hạn lưu → xoá dù chưa ack	⚠ mặc định 7 ngày

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Topic có subscription nào không ai đọc không | ⚠ kiểm tra đầu tiên khi tồn đọng | | Tồn đọng nằm ở subscription nào | | | Đã đặt expiration policy cho subscription chưa | |

Và nguyên nhân số một của hiện tượng tin nhắn dồn ứ mà không ai giải thích được: một subscription được tạo ra để thử nghiệm rồi bị quên lãng. Nó âm thầm giữ lại mọi bản sao tin nhắn cho tới khi hết hạn bảy ngày.

Câu 94 Data Pipelines

A team of data scientists is becoming increasingly dependent on jobs running in a Cloud Dataproc cluster. They would like to increase the number of master nodes from 1 to 2 to improve availability. What command would they use?

A gcloud dataproc master-nodes
B gcloud dataproc nodes add-master
C gcloud dataproc create master-nodes
D The number of master nodes cannot be changed once a cluster is created.

Xem giải thích

Đáp án

D — Số lượng master node không thể thay đổi sau khi cụm đã được tạo.

Vì sao đúng

⚠ Dataproc có hai chế độ, quyết định LÚC TẠO CỤM: | Chế độ | Master node | |---|---| | ⚠ Standard | ⚠ 1 master | | ⚠ High Availability | ⚠ 3 master | | ⚠ Lưu ý | ⚠ KHÔNG có tuỳ chọn 2 master |

⚠ Muốn đổi từ 1 sang 3 master
        ↓
⚠ Phải TẠO CỤM MỚI với --num-masters=3
        ↓
⚠ Chuyển job sang cụm mới
        ↓
⚠ Xoá cụm cũ

⚠ Đề hỏi tăng lên 2 master — ⚠ vừa không đổi được, ⚠ vừa 2 không phải con số hợp lệ.

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

A, B, C — ⚠ cả ba lệnh đều KHÔNG TỒN TẠI: ⚠ gcloud dataproc master-nodes, ⚠ gcloud dataproc nodes add-master, ⚠ gcloud dataproc create master-nodes đều là tên bịa.

Ghi nhớ

⚠ Đổi được và không đổi được trong Dataproc — bảng phải thuộc: | Thuộc tính | Đổi sau khi tạo | |---|---| | ⚠ Số WORKER (primary và secondary) | ⚠ ĐƯỢC — clusters update | | ⚠ Autoscaling policy | ⚠ ĐƯỢC | | ⚠ Số MASTER | ⚠ KHÔNG | | ⚠ Loại máy | ⚠ KHÔNG | | ⚠ Vùng và zone | ⚠ KHÔNG | | ⚠ Phiên bản image | ⚠ KHÔNG | | ⚠ Thuộc tính cụm (--properties) | ⚠ KHÔNG |

Từ khoá nhận diện:

"tăng số master" → ⚠ phải tạo cụm mới với --num-masters=3 "tăng số worker" → ⚠ clusters update --num-workers "cụm HA" → ⚠ 3 master, khai lúc tạo

⚠ Chế độ HA của Dataproc	Đặc điểm
⚠ 3 master node	⚠ không phải 2 — cần số LẺ để bầu chọn
⚠ YARN ResourceManager và HDFS NameNode có dự phòng
⚠ Dùng ZooKeeper để bầu master hoạt động
⚠ Vì sao số lẻ	⚠ thuật toán đồng thuận cần đa số quá bán
⚠ 2 master	⚠ không quyết định được ai đúng khi mất liên lạc

⚠ Cách tránh vấn đề này hoàn toàn	Cách
⚠ Dùng cụm NGẮN HẠN cho từng job	⚠ cụm chết thì tạo lại, không cần HA
⚠ Dữ liệu ở Cloud Storage, không ở HDFS
⚠ Dataproc Serverless	⚠ không có cụm để lo
⚠ HA chỉ cần khi	⚠ cụm dài hạn phục vụ nhiều người dùng liên tục

⚠ Vì sao nhiều thuộc tính không đổi được	Lý do
⚠ Nhiều cấu hình được ghi vào VM lúc khởi tạo
⚠ HDFS và YARN cần cấu hình nhất quán trên toàn cụm
⚠ Hệ quả thực tế	⚠ phải tính kỹ TRƯỚC khi tạo cụm dài hạn
⚠ Hoặc	⚠ dùng cụm ngắn hạn để mọi quyết định đều đảo ngược được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cụm có thật sự cần chạy dài hạn không | | | Nếu cụm chết thì mất gì | ⚠ nếu không mất gì thì không cần HA | | Đã cân nhắc Dataproc Serverless chưa | |

Và cách nghĩ giúp tránh gần như mọi giới hạn "không đổi được" của Dataproc: đừng coi cụm là thứ phải sống lâu. Một cụm được tạo mới cho mỗi job thì mọi quyết định cấu hình đều sửa được ở lần chạy sau.

Câu 95 Machine learning

A project sponsor wants to develop a machine learning model to classify potentially fraudulent transactions. They want to rank models based on a combination of precision and recall. What evaluation metric would you recommend?

A F-score
B Root mean squared error
C Feature crosses
D Mean squared error

Xem giải thích

Đáp án

A — F-score (F1 score).

Vì sao đúng

⚠ F-score là trung bình ĐIỀU HOÀ của precision và recall:

⚠ F1 = 2 × (precision × recall)
        ÷ (precision + recall)
        ↓
⚠ Chỉ CAO khi CẢ HAI đều cao
        ↓
⚠ Một trong hai thấp → ⚠ F1 thấp

Vì sao dùng trung bình điều hoà	Lý do
⚠ Trung bình cộng che giấu sự mất cân bằng	⚠ precision 1,0 và recall 0,0 → trung bình cộng 0,5
⚠ Trung bình điều hoà thì bằng 0	⚠ phản ánh đúng là mô hình vô dụng

⚠ Đề nói rõ "kết hợp precision và recall" → ⚠ F-score.

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

B (RMSE) và D (MSE) — ⚠ chỉ số cho bài toán HỒI QUY: ⚠ đo sai lệch giữa số dự đoán và số thực; ⚠ đề này là PHÂN LOẠI.
C (feature crosses) — ⚠ kỹ thuật đặc trưng, không phải chỉ số đánh giá.

Ghi nhớ

⚠ Chỉ số theo loại bài toán — bảng phải thuộc: | Loại | Chỉ số | |---|---| | ⚠ Phân loại | ⚠ precision, recall, F1, AUC-ROC, AUC-PR | | ⚠ Hồi quy | ⚠ MAE, MSE, RMSE, R² | | ⚠ Chuỗi thời gian | ⚠ MAPE, RMSE | | ⚠ Phân cụm | ⚠ silhouette score, Davies-Bouldin | | ⚠ Gợi ý | ⚠ precision@k, NDCG |

Từ khoá nhận diện:

"kết hợp precision và recall" → ⚠ F-score "sai số dự đoán số" → ⚠ RMSE, MAE "dữ liệu rất mất cân bằng" → ⚠ AUC-PR tốt hơn AUC-ROC "bỏ sót rất đắt" → ⚠ ưu tiên recall

⚠ F-beta — khi hai chỉ số không ngang nhau	Biến thể
⚠ F1	⚠ precision và recall NGANG nhau
⚠ F2	⚠ coi trọng RECALL gấp đôi
⚠ F0.5	⚠ coi trọng PRECISION gấp đôi
⚠ Với phát hiện gian lận	⚠ thường ưu tiên recall — bỏ sót giao dịch gian lận rất đắt
⚠ Nhưng	⚠ precision thấp làm phiền quá nhiều khách hàng vô tội

⚠ Bài toán phát hiện gian lận — đặc thù	Đặc thù
⚠ Dữ liệu RẤT mất cân bằng	⚠ có khi dưới 1% là gian lận
⚠ Accuracy vô dụng	⚠ đoán "không gian lận" luôn đạt 99%
⚠ Chi phí hai loại lỗi rất khác nhau
⚠ Nên dùng	⚠ AUC-PR và F-beta phù hợp với chi phí nghiệp vụ
⚠ Kỹ thuật xử lý	⚠ lấy mẫu lại, gán trọng số lớp, SMOTE

⚠ Ma trận nhầm lẫn — nền tảng của mọi chỉ số	Ô
⚠ TP	⚠ dự đoán dương, thực tế dương — bắt đúng gian lận
⚠ FP	⚠ báo nhầm giao dịch sạch — làm phiền khách
⚠ FN	⚠ bỏ sót gian lận — mất tiền
⚠ TN	⚠ đúng là giao dịch sạch
⚠ Quyết định nghiệp vụ	⚠ so sánh CHI PHÍ của FP và FN

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí một FP so với một FN là bao nhiêu | ⚠ quyết định chọn F-beta nào | | Dữ liệu mất cân bằng cỡ nào | | | Có đang dùng accuracy làm chỉ số chính không | ⚠ dấu hiệu cảnh báo |

Và câu hỏi nên đặt trước khi chọn chỉ số đánh giá: sai lầm nào tốn kém hơn — báo nhầm hay bỏ sót?. Câu trả lời đến từ nghiệp vụ, không đến từ khoa học dữ liệu, và nó quyết định toàn bộ cách mô hình được điều chỉnh.

Câu 96 Data Pipelines

As the developer of a new Cloud Dataflow pipeline, you'd like to limit the processing resources used when testing a new pipeline. What parameter would you specify when executing your new Cloud Dataflow job?

A --maxNumWorkers
B --jobWorkers
C --maxVMs
D --maxContainers

Xem giải thích

Đáp án

A — --maxNumWorkers.

Vì sao đúng

⚠ Dataflow tự co giãn số worker theo tải — ⚠ khi thử nghiệm thì đó là rủi ro chi phí.

⚠ Không đặt giới hạn
        ↓
⚠ Pipeline thử nghiệm có lỗi
   ⚠ tạo ra khối lượng công việc lớn
        ↓
⚠ Dataflow tự thêm worker
        ↓
⚠ Hoá đơn bất ngờ

⚠ Đặt --maxNumWorkers=3
        ↓
⚠ Trần cứng, chi phí dự đoán được

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

B (--jobWorkers), C (--maxVMs), D (--maxContainers) — ⚠ cả ba tham số đều KHÔNG TỒN TẠI trong Dataflow.

Ghi nhớ

⚠ Tham số Dataflow hay dùng — bảng phải thuộc: | Tham số | Việc | |---|---| | ⚠ --maxNumWorkers | ⚠ trần số worker — đề này | | ⚠ --numWorkers | ⚠ số worker ban đầu | | ⚠ --workerMachineType | ⚠ loại máy | | ⚠ --autoscalingAlgorithm | ⚠ THROUGHPUT_BASED hoặc NONE | | ⚠ --region | ⚠ vùng chạy job | | ⚠ --tempLocation | ⚠ thư mục tạm trên Cloud Storage | | ⚠ --streaming | ⚠ chế độ luồng |

Từ khoá nhận diện:

"giới hạn tài nguyên khi thử" → ⚠ --maxNumWorkers "tắt hẳn autoscaling" → ⚠ --autoscalingAlgorithm=NONE "giảm chi phí job batch không gấp" → ⚠ FlexRS "chọn máy nhỏ hơn" → ⚠ --workerMachineType

⚠ Thực hành khi phát triển pipeline	Thực hành
⚠ Thử với DirectRunner trên máy cá nhân trước	⚠ miễn phí
⚠ Dùng tập dữ liệu NHỎ khi thử
⚠ Đặt `--maxNumWorkers` thấp
⚠ Chạy trong project riêng cho môi trường phát triển
⚠ Đặt cảnh báo ngân sách

⚠ Vì sao autoscaling nguy hiểm khi thử nghiệm	Lý do
⚠ Vòng lặp vô hạn tạo tồn đọng giả	⚠ Dataflow thấy tồn đọng thì thêm worker
⚠ Job streaming chạy MÃI cho tới khi bị huỷ
⚠ Quên huỷ job cuối tuần là hoá đơn lớn
⚠ Nên	⚠ luôn kiểm tra danh sách job đang chạy trước khi nghỉ

⚠ Cách ước tính chi phí Dataflow	Cách
⚠ Chi phí ≈ số worker × thời gian × giá máy
⚠ Cộng phí Streaming Engine hoặc Shuffle nếu bật
⚠ Xem Job Metrics để biết vCPU-giờ thực dùng
⚠ Với batch	⚠ FlexRS giảm đáng kể nếu chờ được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có job streaming nào bị quên không huỷ không | | | maxNumWorkers đã đặt cho môi trường thử chưa | | | Cảnh báo ngân sách đã bật chưa | |

Và thói quen nên có với mọi dịch vụ tự co giãn: đặt trần trước khi chạy lần đầu. Tính năng tự co giãn được thiết kế để phục vụ tải thật, và nó không phân biệt được tải thật với một vòng lặp lỗi.

Câu 97 Resource Hierarchy

A group of data engineers will be working on several initiatives. Each initiative will have their own VMs, storage buckets, and sets of Cloud Functions. The initiatives will all be governed by the same set of constraints that are required to stay in compliance with regulations. How would you recommend the data engineers organize their Google Cloud resources?

A Use a project for each initiative and place those projects in a folder. Attach policies to the folder to enforce constraints.
B Use a folder for each initiative and place those folders in a project. Attach policies to the project to enforce constraints.
C Use a project for each initiative and place those projects in an organization. Attach policies to the organization to enforce constraints.
D Use an organization for each initiative and place those folders in a project. Attach policies to the organization to enforce constraints.

Xem giải thích

Đáp án

A — Dùng một project cho mỗi sáng kiến, đặt các project đó trong một folder, và gắn chính sách vào folder để cưỡng chế ràng buộc.

Vì sao đúng

⚠ Cây phân cấp tài nguyên của Google Cloud:

⚠ Organization (tổ chức)
        ↓
⚠ Folder (thư mục, lồng nhau được)
        ↓
⚠ Project (dự án)
        ↓
⚠ Tài nguyên (VM, bucket, function)

⚠ Vì sao cấu trúc trong phương án A đúng: | Yếu tố | Lý do | |---|---| | ⚠ Mỗi sáng kiến MỘT project | ⚠ cách ly tài nguyên, hạn mức, hoá đơn | | ⚠ Gom vào MỘT folder | ⚠ các sáng kiến chung một bộ ràng buộc | | ⚠ Gắn chính sách ở FOLDER | ⚠ kế thừa xuống mọi project, kể cả project TẠO SAU |

⚠ Vì sao không gắn ở cấp tổ chức: ⚠ ràng buộc chỉ áp cho nhóm sáng kiến này, ⚠ không phải toàn công ty.

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

C (project trong tổ chức, gắn chính sách ở TỔ CHỨC) — ⚠ áp cho TOÀN BỘ công ty: ⚠ quá rộng; ⚠ các bộ phận khác không chịu cùng ràng buộc tuân thủ này.
B (folder cho mỗi sáng kiến, đặt folder TRONG project) — ⚠ SAI cấu trúc: ⚠ folder không nằm trong project; ⚠ ngược lại mới đúng.
D (một tổ chức cho mỗi sáng kiến) — ⚠ hiểu sai hoàn toàn: ⚠ tổ chức gắn với một tên miền công ty, ⚠ không tạo tuỳ ý cho từng sáng kiến.

Ghi nhớ

⚠ Cây phân cấp — quy tắc phải thuộc: | Cấp | Đặc điểm | |---|---| | ⚠ Organization | ⚠ gốc, MỘT cho mỗi tên miền | | ⚠ Folder | ⚠ nhóm project, LỒNG được tối đa 10 cấp | | ⚠ Project | ⚠ ranh giới của tài nguyên, hạn mức, hoá đơn, IAM | | ⚠ Resource | ⚠ VM, bucket, dataset | | ⚠ Chính sách và IAM | ⚠ KẾ THỪA từ trên xuống |

Từ khoá nhận diện:

"nhiều nhóm chung một bộ ràng buộc" → ⚠ folder + chính sách ở folder "áp cho toàn công ty" → ⚠ cấp tổ chức "cách ly tài nguyên và chi phí" → ⚠ project riêng

⚠ Vì sao dùng nhiều project	Lý do
⚠ Cách ly hạn mức (quota)	⚠ một sáng kiến hết quota không ảnh hưởng cái khác
⚠ Cách ly hoá đơn	⚠ biết sáng kiến nào tốn bao nhiêu
⚠ Cách ly IAM	⚠ quyền không tràn sang nhau
⚠ Xoá project là xoá sạch mọi thứ	⚠ dọn dẹp gọn gàng
⚠ Giảm bán kính ảnh hưởng khi có sự cố

⚠ Cấu trúc folder thường gặp	Cấu trúc
⚠ Theo môi trường	⚠ prod / staging / dev
⚠ Theo đơn vị kinh doanh
⚠ Theo mức tuân thủ	⚠ đề này — cùng bộ ràng buộc
⚠ Kết hợp nhiều cấp	⚠ bộ phận → môi trường
⚠ Nguyên tắc	⚠ cấu trúc phải phản ánh cách CẤP QUYỀN, không phải sơ đồ tổ chức

⚠ Cái gì kế thừa, cái gì không	Kế thừa
⚠ IAM binding	⚠ kế thừa xuống — CỘNG DỒN
⚠ Organization Policy	⚠ kế thừa, có thể ghi đè nếu cho phép
⚠ Tài khoản thanh toán	⚠ gắn theo project
⚠ Quan trọng	⚠ quyền cấp ở folder áp cho MỌI project bên dưới, kể cả project mới

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Project mới có tự động chịu ràng buộc không | ⚠ nếu chính sách ở folder thì có | | Có project nào nằm ngoài folder không | ⚠ sẽ không chịu ràng buộc | | Cấu trúc folder có phản ánh cách phân quyền không | |

Và lợi ích lớn nhất của việc gắn chính sách ở folder thay vì từng project: project tạo ra ngày mai cũng tự động tuân thủ. Không cần ai nhớ, không cần thêm bước nào trong quy trình.

Câu 98 Databases

A Web hosting company has been using a custom built data store modeled on the sparse multidimensional array data structure. The CIO no longer wants to pay to develop and maintain a custom data store. Instead, the CIO wants a managed database service if possible and if not, they want to use a well supported open source database that is also based on sparse multidimensional array data structure. The Web hosting company is already using Google Cloud Compute Engine, Cloud Storage, and Kubernetes Engine. What would you recommend to the company?

A Cassandra
B Cloud Bigtable
C BigQuery
D Cloud Spanner

Xem giải thích

Đáp án

B — Cloud Bigtable.

Vì sao đúng

⚠ "Mảng đa chiều thưa" (sparse multidimensional array) là mô tả CHÍNH THỨC của Bigtable: | Chiều | Nội dung | |---|---| | ⚠ Chiều 1 | ⚠ row key | | ⚠ Chiều 2 | ⚠ column family | | ⚠ Chiều 3 | ⚠ column qualifier | | ⚠ Chiều 4 | ⚠ dấu thời gian (timestamp) | | ⚠ "Thưa" nghĩa là | ⚠ ô không có giá trị thì KHÔNG tốn chỗ |

⚠ Đề ưu tiên: dịch vụ ĐƯỢC QUẢN nếu có
        ↓
⚠ Bigtable = ⚠ được quản + đúng mô hình
        ↓
⚠ Không cần tới phương án mã nguồn mở

⚠ Bigtable là bài báo gốc đã sinh ra HBase và ảnh hưởng tới Cassandra.

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

A (Cassandra) — ⚠ đúng mô hình dữ liệu nhưng KHÔNG được quản: ⚠ đề nói rõ ⚠ ưu tiên dịch vụ được quản, mã nguồn mở chỉ là phương án dự phòng.
C (BigQuery) — ⚠ kho phân tích dạng cột, không phải mảng đa chiều thưa.
D (Cloud Spanner) — ⚠ CSDL QUAN HỆ: ⚠ mô hình hoàn toàn khác.

Ghi nhớ

⚠ Mô hình dữ liệu Bigtable — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Thưa (sparse) | ⚠ cột trống KHÔNG tốn dung lượng | | ⚠ Đa chiều | ⚠ row × family × qualifier × timestamp | | ⚠ Sắp xếp theo row key | ⚠ thứ tự từ điển | | ⚠ Nhiều phiên bản mỗi ô | ⚠ theo dấu thời gian | | ⚠ Column qualifier tạo động | ⚠ không cần khai trước |

Từ khoá nhận diện:

"mảng đa chiều thưa" → ⚠ Bigtable (hoặc HBase, Cassandra) "tương thích HBase API" → ⚠ Bigtable "cột rộng (wide column)" → ⚠ Bigtable, Cassandra "muốn được quản" → ⚠ luôn ưu tiên dịch vụ Google Cloud

⚠ Vì sao "thưa" quan trọng	Lý do
⚠ Mỗi dòng có thể có tập cột KHÁC NHAU
⚠ Dòng có 3 cột và dòng có 1.000 cột nằm chung bảng
⚠ Không lãng phí chỗ cho ô trống	⚠ khác CSDL quan hệ
⚠ Ca dùng	⚠ dữ liệu có cấu trúc rất thay đổi giữa các bản ghi

⚠ Bigtable so với Cassandra	So sánh
⚠ Bigtable: được quản hoàn toàn	⚠ không vận hành node nào
⚠ Cassandra: tự vận hành, chạy ở đâu cũng được
⚠ Bigtable: co giãn bằng cách đổi số node
⚠ Cassandra: kiểm soát chi tiết mức nhất quán
⚠ Nếu buộc phải dùng Cassandra	⚠ chạy trên GKE, hoặc dùng dịch vụ bên thứ ba

⚠ Nhiều phiên bản mỗi ô — ứng dụng	Ứng dụng
⚠ Lưu lịch sử thay đổi của một giá trị
⚠ Chuỗi thời gian: mỗi phiên bản là một mốc
⚠ Chính sách hết hạn theo số phiên bản hoặc tuổi
⚠ Cẩn thận	⚠ không đặt chính sách thì dữ liệu tăng vô hạn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách hết hạn đã đặt chưa | | | Có thật sự cần nhiều phiên bản mỗi ô không | | | Mọi truy vấn có đi qua row key được không | |

Và điều thú vị về dòng dõi của các cơ sở dữ liệu này: bài báo Bigtable của Google năm 2006 đã sinh ra HBase, và ảnh hưởng tới Cassandra. Chọn Bigtable là quay về bản gốc, chỉ khác là không phải tự vận hành nó.

Câu 99 Data management

A financial services company is required to keep audit records for at least seven years. The data is unlikely to be accessed but must be kept anyway. The company has been storing this data in an on-premises file system but the CIO wants to a lower cost solution. The company is migrating several workloads to Google Cloud and is considering a Google Cloud-based solution. What would you recommend?

A Cloud Storage Archive class storage
B Cloud Storage Coldline storage
C Cloud Storage Multi-Region storage
D Cloud Storage Dual-Region storage

Xem giải thích

Đáp án

A — Cloud Storage lớp Archive.

Vì sao đúng

⚠ Ghép yêu cầu với đặc điểm lớp: | Yêu cầu | Archive | |---|---| | ⚠ Giữ tối thiểu BẢY NĂM | ⚠ thời gian lưu tối thiểu 365 ngày — không thành vấn đề | | ⚠ HẦU NHƯ không truy cập | ⚠ đúng thiết kế: dưới 1 lần/năm | | ⚠ Chi phí THẤP NHẤT | ⚠ lớp rẻ nhất của Cloud Storage | | ⚠ Nhưng vẫn phải giữ | ⚠ độ bền 11 số 9 như mọi lớp |

⚠ Bản ghi kiểm toán 7 năm
   ⚠ gần như không ai đọc
        ↓
⚠ Archive class
        ↓
⚠ Chi phí lưu trữ thấp nhất
⚠ Truy cập vẫn TỨC THÌ khi cần
   ⚠ (không phải chờ như băng từ)

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

B (Coldline) — ⚠ thiết kế cho ~1 lần mỗi QUÝ: ⚠ đắt hơn Archive; ⚠ đề nói hầu như không truy cập.
C (Multi-Region) và D (Dual-Region) — ⚠ là cấu hình VỊ TRÍ, không phải lớp lưu trữ: ⚠ và ⚠ đắt hơn cho nhu cầu này.

Ghi nhớ

⚠ Archive class — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Thời gian lưu tối thiểu | ⚠ 365 ngày | | ⚠ Phí lưu trữ | ⚠ thấp nhất | | ⚠ Phí lấy dữ liệu | ⚠ cao nhất | | ⚠ Độ trễ truy cập | ⚠ TỨC THÌ — mili giây | | ⚠ Độ bền | ⚠ 11 số 9, như mọi lớp | | ⚠ Hiểu lầm phổ biến | ⚠ tưởng phải "rã đông" như băng từ — KHÔNG |

Từ khoá nhận diện:

"giữ nhiều năm, hầu như không đọc" → ⚠ Archive "đọc hằng quý" → ⚠ Coldline "đọc hằng tháng" → ⚠ Nearline "không ai được xoá trước hạn" → ⚠ Bucket Lock + retention policy

⚠ Với bản ghi kiểm toán, cần thêm gì	Thêm
⚠ Retention policy 7 năm
⚠ Retention policy LOCK	⚠ không ai gỡ được, kể cả admin
⚠ Lifecycle xoá sau 7 năm	⚠ giữ quá hạn cũng có rủi ro pháp lý
⚠ Bucket riêng, quyền rất hẹp
⚠ Audit log cho chính bucket đó

⚠ Tính chi phí 7 năm — cần lưu ý	Lưu ý
⚠ Phí lưu trữ nhân với 84 tháng
⚠ Cộng phí lấy dữ liệu nếu có kiểm toán
⚠ Cộng phí thao tác (số object)	⚠ nhiều tệp nhỏ thì phí thao tác đáng kể
⚠ Mẹo	⚠ gộp tệp nhỏ thành gói lớn trước khi lưu trữ

⚠ So sánh với lưu trữ tại chỗ	So sánh
⚠ Tại chỗ: chi phí phần cứng, điện, nhân sự, thay ổ đĩa
⚠ Đám mây: một dòng trên hoá đơn
⚠ Tại chỗ: phải tự kiểm chứng dữ liệu còn đọc được
⚠ Archive: Google lo độ bền
⚠ Rủi ro cần tính	⚠ phí lấy toàn bộ dữ liệu ra nếu muốn rời đi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Retention policy đã lock chưa | | | Có nhiều tệp nhỏ không | ⚠ nên gộp lại | | Đã tính phí lấy dữ liệu cho một đợt kiểm toán chưa | |

Và điều đáng nhớ nhất về lớp Archive của Cloud Storage: rẻ nhất nhưng vẫn truy cập tức thì. Khác với băng từ hay các dịch vụ lưu trữ lạnh cần vài giờ để rã đông, dữ liệu ở đây luôn sẵn sàng ngay — chỉ là bạn trả tiền cho mỗi lần chạm vào.

Câu 100 Data management

You are creating a set of Cloud Storage buckets for storing data that will be accessed by several different teams in your organization. The teams have different access requirements. You want to follow Google Cloud's recommended best practices. How would you implement access controls to objects and buckets?

A Uniform bucket level access
B Fine-grained access controls
C Signed URLs
D Signed policy documents

Xem giải thích

Đáp án

A — Uniform bucket-level access (quyền truy cập thống nhất ở mức bucket).

Vì sao đúng

⚠ Google khuyến nghị dùng uniform bucket-level access: | Đặc điểm | Nội dung | |---|---| | ⚠ CHỈ dùng IAM | ⚠ tắt hẳn ACL trên từng object | | ⚠ Một nơi kiểm soát duy nhất | ⚠ dễ rà soát, dễ kiểm toán | | ⚠ Kế thừa từ project và folder | | | ⚠ Dùng được IAM Conditions | ⚠ điều kiện theo tiền tố object |

⚠ Nhiều đội, yêu cầu truy cập khác nhau
        ↓
⚠ Uniform access + BUCKET RIÊNG cho mỗi đội
        ↓
⚠ Cấp vai trò IAM khác nhau cho từng bucket
        ↓
⚠ Kiểm soát rõ ràng, kiểm toán được

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

B (fine-grained access control) — ⚠ cho phép ACL trên TỪNG object: ⚠ Google ⚠ khuyến nghị TRÁNH; ⚠ hai hệ thống quyền song song (IAM + ACL) ⚠ rất khó rà soát; ⚠ rất nhiều vụ rò rỉ dữ liệu đến từ ACL cấu hình sai.
C (signed URL) — ⚠ cấp quyền TẠM THỜI cho người KHÔNG có tài khoản: ⚠ giải bài toán khác.
D (signed policy document) — ⚠ kiểm soát điều kiện TẢI LÊN từ form web: ⚠ cũng là bài toán khác.

Ghi nhớ

⚠ Hai chế độ quyền của Cloud Storage — bảng phải thuộc: | Chế độ | Nội dung | |---|---| | ⚠ Uniform bucket-level | ⚠ CHỈ IAM — Google KHUYẾN NGHỊ | | ⚠ Fine-grained | ⚠ IAM + ACL trên từng object — tránh | | ⚠ Chuyển sang uniform | ⚠ được, nhưng sau 90 ngày thì KHÔNG quay lại được | | ⚠ Cưỡng chế toàn tổ chức | ⚠ storage.uniformBucketLevelAccess |

Từ khoá nhận diện:

"nhiều đội, quyền khác nhau, thực hành tốt" → ⚠ uniform access + bucket riêng "cho người ngoài tải một file trong 1 giờ" → ⚠ signed URL "cho người dùng tải file lên trực tiếp" → ⚠ signed policy document "quyền theo tiền tố thư mục" → ⚠ IAM Conditions

⚠ Vì sao ACL nguy hiểm	Lý do
⚠ Đặt được trên TỪNG object — hàng triệu chỗ để sai
⚠ Có `allUsers` = CÔNG KHAI toàn Internet
⚠ Không thấy được trong tổng quan IAM
⚠ Rất khó trả lời "ai đọc được file này"
⚠ Nhiều vụ rò rỉ nổi tiếng	⚠ đến từ đúng một ACL đặt nhầm

⚠ Signed URL — khi nào thật sự cần	Khi nào
⚠ Người dùng KHÔNG có tài khoản Google
⚠ Cho tải một file cụ thể trong thời gian giới hạn
⚠ Ứng dụng ký URL bằng service account
⚠ Lưu ý bảo mật	⚠ ai có URL là truy cập được — đặt hạn NGẮN

⚠ Thiết kế bucket cho nhiều đội	Thiết kế
⚠ MỖI ĐỘI một bucket riêng	⚠ đơn giản và rõ ràng nhất
⚠ Cấp vai trò IAM ở mức bucket
⚠ Dùng Google Group thay vì từng người
⚠ Nếu buộc dùng chung bucket	⚠ IAM Conditions theo tiền tố object

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bucket nào còn dùng ACL không | | | Có object nào cấp cho allUsers không | ⚠ kiểm tra ngay | | Đã bật chính sách tổ chức bắt buộc uniform chưa | |

Và một trong những nguyên nhân rò rỉ dữ liệu phổ biến nhất trên đám mây: một ACL cấp quyền cho allUsers trên một object mà không ai nhớ. Uniform bucket-level access xoá bỏ hẳn khả năng đó.

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

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ