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

Câu 81 Data management

You have been tasked with ensuring the successful transfer of 100 TB of data from the AWS S3 object storage system. This is a one time transfer. A complete and reliable transfer of all data is a top priority. How would you recommend loading this data into Cloud Storage?

A gsutil cp
B Cloud Dataflow
C Cloud Storage Transfer Service
D Transfer Appliance

Xem giải thích

Đáp án

C — Cloud Storage Transfer Service.

Vì sao đúng

⚠ Ba yêu cầu của đề: | Yêu cầu | Storage Transfer Service | |---|---| | ⚠ Nguồn là AWS S3 | ⚠ hỗ trợ S3 SẴN, không cần trung gian | | ⚠ 100 TB, chuyển MỘT LẦN | ⚠ chạy được ở quy mô đó | | ⚠ ĐẦY ĐỦ và ĐÁNG TIN CẬY là ưu tiên số một | ⚠ tự kiểm tra checksum, tự thử lại, có báo cáo |

⚠ AWS S3
        ↓ ⚠ Storage Transfer Service
   ⚠ chạy trên hạ tầng Google
   ⚠ song song, tự thử lại
   ⚠ kiểm tra tính toàn vẹn
        ↓
⚠ Cloud Storage

⚠ Không cần máy trung gian nào — ⚠ dịch vụ chạy phía Google.

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

A (gsutil cp) — ⚠ chạy từ MỘT máy, không co giãn: ⚠ 100 TB qua một tiến trình là ⚠ rất chậm; ⚠ đứt giữa chừng phải tự xử lý; ⚠ không có báo cáo toàn vẹn.
D (Transfer Appliance) — ⚠ thiết bị vật lý gửi qua đường bưu điện: ⚠ dùng khi ⚠ băng thông mạng KHÔNG đủ; ⚠ ở đây nguồn là S3 trên đám mây, ⚠ không có ổ đĩa vật lý nào để chép.
B (Cloud Dataflow) — ⚠ dịch vụ XỬ LÝ dữ liệu: ⚠ dùng để biến đổi, ⚠ không phải công cụ chuyển tệp hàng loạt.

Ghi nhớ

⚠ Chọn công cụ chuyển dữ liệu — bảng phải thuộc: | Nguồn và tình huống | Công cụ | |---|---| | ⚠ Từ đám mây khác (S3, Azure), từ URL | ⚠ Storage Transfer Service | | ⚠ Từ tại chỗ qua mạng, có agent | ⚠ Storage Transfer Service for on-premises | | ⚠ Từ tại chỗ, mạng KHÔNG đủ (hàng trăm TB) | ⚠ Transfer Appliance | | ⚠ Vài GB, thao tác nhanh | ⚠ gsutil / gcloud storage | | ⚠ Giữa các bucket Google Cloud | ⚠ Storage Transfer Service hoặc gsutil rsync |

Từ khoá nhận diện:

"từ S3 sang Cloud Storage" → ⚠ Storage Transfer Service "mạng không đủ băng thông" → ⚠ Transfer Appliance "vài trăm tệp nhỏ" → ⚠ gcloud storage cp "cần biến đổi dữ liệu khi chuyển" → ⚠ Dataflow

⚠ Storage Transfer Service — tính năng	Tính năng
⚠ Chuyển theo LỊCH hoặc một lần
⚠ Chỉ chuyển tệp MỚI hoặc ĐÃ ĐỔI	⚠ chạy lại an toàn
⚠ Kiểm tra checksum tự động
⚠ Xoá tệp nguồn sau khi chuyển (tuỳ chọn)
⚠ Lọc theo tiền tố và thời gian sửa đổi
⚠ Báo cáo chi tiết và log lỗi

⚠ Tính thời gian chuyển — công thức	Công thức
⚠ Thời gian ≈ dung lượng ÷ băng thông khả dụng
⚠ 100 TB qua 1 Gbps ≈ 9-10 ngày
⚠ 100 TB qua 10 Gbps ≈ 1 ngày
⚠ Ngưỡng cân nhắc Transfer Appliance	⚠ khi thời gian qua mạng vượt vài tuần
⚠ Với S3	⚠ băng thông giữa hai đám mây thường rất tốt

⚠ Lưu ý chi phí khi chuyển từ S3	Lưu ý
⚠ AWS tính phí TRUYỀN RA (egress)	⚠ thường là khoản lớn nhất
⚠ Google KHÔNG tính phí nhận vào
⚠ Storage Transfer Service miễn phí cho nguồn đám mây
⚠ Nên	⚠ ước tính phí egress của AWS trước khi bắt đầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã ước tính phí egress bên AWS chưa | | | Có báo cáo đối chiếu số tệp và dung lượng không | | | Job có chạy lại được an toàn không | ⚠ chỉ chuyển phần còn thiếu |

Và điều nên làm sau mọi lần chuyển dữ liệu lớn, trước khi xoá nguồn: đối chiếu số tệp và tổng dung lượng ở hai bên. Báo cáo "hoàn tất" của công cụ và một phép đếm độc lập là hai mức tin cậy khác nhau.

Câu 82 Data Pipelines

A user of a Cloud Dataproc cluster needs permission to stop a cluster. They will also need to instantiate workflow templates and other common user tasks. You want to follow Google Cloud recommend best practices for security. What role would you use to grant permission to stop a cluster?

A roles/dataproc.editor
B roles/dataproc.admin
C roles/dataproc.viewer
D
Create a custom role with only permissions to stop the cluster and imitate workflows.

Xem giải thích

Đáp án

A — roles/dataproc.editor.

Vì sao đúng

⚠ Đề cần vai trò cho phép: | Việc | Vai trò tối thiểu | |---|---| | ⚠ DỪNG cụm | ⚠ editor (viewer không đủ) | | ⚠ Khởi tạo workflow template | ⚠ editor | | ⚠ Các việc thường ngày khác | ⚠ editor |

⚠ viewer  → ⚠ chỉ XEM, không dừng được
⚠ editor  → ⚠ dừng, tạo, sửa cụm và
             workflow — ĐỦ và tối thiểu
⚠ admin   → ⚠ thêm quyền quản IAM — THỪA

⚠ Nguyên tắc quyền tối thiểu: ⚠ chọn vai trò nhỏ nhất mà vẫn đủ.

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

B (roles/dataproc.admin) — ⚠ thừa quyền: ⚠ admin thêm khả năng quản phân quyền IAM của Dataproc; ⚠ người dùng thường không cần.
C (roles/dataproc.viewer) — ⚠ thiếu quyền: ⚠ chỉ xem được, ⚠ không dừng được cụm.
D (tạo custom role chỉ có quyền dừng cụm và chạy workflow) — ⚠ thừa công sức và ngược khuyến nghị: ⚠ Google khuyến nghị ưu tiên vai trò predefined; ⚠ custom role phải tự bảo trì khi dịch vụ thêm tính năng; ⚠ và ⚠ đề nói người dùng còn cần các việc thường ngày khác.

Ghi nhớ

⚠ Thứ tự chọn vai trò IAM — bảng phải thuộc: | Thứ tự | Cách | |---|---| | ⚠ 1. Vai trò PREDEFINED phù hợp nhất | ⚠ ưu tiên đầu tiên | | ⚠ 2. Custom role | ⚠ chỉ khi predefined RÕ RÀNG quá rộng | | ⚠ 3. Basic role (Owner/Editor/Viewer) | ⚠ TRÁNH ở production |

Từ khoá nhận diện:

"vai trò tối thiểu cho việc X" → ⚠ tìm predefined vừa đủ "predefined thừa quyền RÕ RỆT" → ⚠ custom role "cho tiện thì cấp Owner" → ⚠ LUÔN SAI

⚠ Vai trò Dataproc — bộ đầy đủ	Vai trò
⚠ `dataproc.viewer`	⚠ xem cụm và job
⚠ `dataproc.editor`	⚠ tạo, sửa, dừng cụm; gửi job; workflow template
⚠ `dataproc.admin`	⚠ editor + quản IAM của Dataproc
⚠ `dataproc.worker`	⚠ cho SERVICE ACCOUNT của VM trong cụm
⚠ Lưu ý	⚠ `dataproc.worker` là cho máy, không phải cho người

⚠ Vì sao đừng vội tạo custom role	Lý do
⚠ Không tự cập nhật khi Google thêm quyền mới
⚠ Tính năng mới có thể im lặng không dùng được
⚠ Nhiều custom role thì khó rà soát
⚠ Phải bảo trì mãi mãi
⚠ Chỉ tạo khi	⚠ predefined gần nhất vẫn rộng quá mức chấp nhận được

⚠ Custom role — nếu buộc phải tạo	Lời khuyên
⚠ Tạo ở cấp TỔ CHỨC để dùng chung
⚠ Đặt tên và mô tả rõ ràng
⚠ Bắt đầu từ predefined rồi bớt đi
⚠ Ghi lại lý do tạo
⚠ Rà soát khi dịch vụ có bản cập nhật lớn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có vai trò predefined nào vừa đủ không | ⚠ kiểm tra trước khi tạo custom | | Người dùng có thật sự cần quản IAM không | ⚠ nếu không thì đừng cấp admin | | IAM Recommender gợi ý gì | |

Và cân nhắc thực dụng khi chọn vai trò: custom role chính xác hơn nhưng tốn công bảo trì mãi mãi. Với phần lớn trường hợp, một vai trò predefined hơi rộng một chút mà được Google cập nhật vẫn là lựa chọn tốt hơn.

Câu 83 Data pipelines

You are using Cloud Dataflow to process data that is represented as key value pairs. What Apache Beam construct will you likely use in your workflow?

A Database connection
B
PCollections
C User-defined function (UDF)
D Watermark

Xem giải thích

Đáp án

B — PCollection.

Vì sao đúng

⚠ PCollection là cấu trúc dữ liệu NỀN TẢNG của Apache Beam:

⚠ Mọi dữ liệu trong pipeline Beam
   đều nằm trong một PCollection
        ↓
⚠ PTransform biến đổi
   PCollection này → PCollection khác
        ↓
⚠ Cặp khoá-giá trị được biểu diễn là
   ⚠ PCollection<KV<K, V>>

Đặc điểm PCollection	Nội dung
⚠ Phân tán	⚠ chia trên nhiều worker
⚠ BẤT BIẾN	⚠ transform tạo collection MỚI
⚠ Bounded hoặc unbounded	⚠ batch hoặc streaming
⚠ Có coder	⚠ biết cách serialize dữ liệu

⚠ Với dữ liệu khoá-giá trị, ⚠ dùng được GroupByKey, CoGroupByKey, Combine.perKey.

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

D (watermark) — ⚠ khái niệm về TIẾN ĐỘ THỜI GIAN: ⚠ không phải cấu trúc chứa dữ liệu.
C (user-defined function) — ⚠ thuật ngữ của SQL/BigQuery: ⚠ Beam gọi là DoFn.
A (database connection) — ⚠ không phải khái niệm Beam: ⚠ Beam đọc ghi qua IO connector.

Ghi nhớ

⚠ Khái niệm cốt lõi Apache Beam — bảng phải thuộc: | Khái niệm | Vai trò | |---|---| | ⚠ Pipeline | ⚠ toàn bộ luồng xử lý | | ⚠ PCollection | ⚠ tập dữ liệu phân tán, bất biến | | ⚠ PTransform | ⚠ phép biến đổi | | ⚠ ParDo / DoFn | ⚠ xử lý từng phần tử | | ⚠ IO connector | ⚠ đọc nguồn, ghi đích | | ⚠ Runner | ⚠ nơi thực thi — Dataflow, Spark, Flink |

Từ khoá nhận diện:

"tập dữ liệu trong Beam" → ⚠ PCollection "xử lý từng phần tử" → ⚠ ParDo với DoFn "gom theo khoá" → ⚠ GroupByKey "join hai tập theo khoá" → ⚠ CoGroupByKey

⚠ Phép biến đổi cho dữ liệu khoá-giá trị	Phép
⚠ `GroupByKey`	⚠ gom mọi giá trị cùng khoá
⚠ `CoGroupByKey`	⚠ join nhiều PCollection theo khoá
⚠ `Combine.perKey`	⚠ tổng hợp theo khoá — HIỆU QUẢ hơn GroupByKey
⚠ `Keys` / `Values`	⚠ lấy riêng khoá hoặc giá trị
⚠ Mẹo hiệu năng	⚠ Combine gộp sớm ở từng worker, giảm dữ liệu shuffle

⚠ Vì sao PCollection bất biến	Lý do
⚠ Cho phép tính lại phần bị mất khi worker chết
⚠ Cho phép nhiều transform đọc cùng một collection
⚠ Đơn giản hoá xử lý song song
⚠ Hệ quả	⚠ mỗi transform sinh collection MỚI, không sửa cái cũ

⚠ Bounded so với Unbounded PCollection	Phân biệt
⚠ Bounded	⚠ hữu hạn — tệp, bảng — chế độ batch
⚠ Unbounded	⚠ vô hạn — Pub/Sub — chế độ streaming
⚠ Unbounded BẮT BUỘC có windowing	⚠ để tổng hợp được
⚠ Ưu điểm Beam	⚠ cùng một mã cho cả hai chế độ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có dùng Combine thay cho GroupByKey được không | ⚠ giảm shuffle đáng kể | | Dữ liệu có lệch theo khoá không | ⚠ một khoá chiếm phần lớn | | Streaming đã khai windowing chưa | |

Và bẫy hiệu năng phổ biến nhất trong Beam: dùng GroupByKey khi chỉ cần tổng hợp. Combine.perKey gộp ngay tại từng worker trước khi shuffle, và khác biệt về khối lượng dữ liệu di chuyển thường rất lớn.

Câu 84 Data Pipelines

When using Cloud Data Fusion you receive an error that a Dataproc operation failed and the user is not authorized to act as a service account. What would you do to correct this problem?

A Create a Cloud Dataproc cluster before starting Cloud Data Fusion.
B Grant the Service Account User role to Cloud Data Fusion.
C Grant the Service Account User role to Cloud Dataproc.
D Ensure both Cloud Data Fusion and Cloud Dataproc are running in the same zone.

Xem giải thích

Đáp án

B — Cấp vai trò Service Account User cho Cloud Data Fusion.

Vì sao đúng

⚠ Đọc thông báo lỗi là ra đáp án: ⚠ "user is not authorized to act as a service account".

⚠ Cloud Data Fusion cần TẠO cụm Dataproc
        ↓
⚠ Cụm đó chạy DƯỚI DANH NGHĨA
   một service account
        ↓
⚠ Muốn "hành động thay" service account
   ⚠ phải có vai trò
   ⚠ roles/iam.serviceAccountUser
        ↓
⚠ Thiếu vai trò đó → ⚠ đúng lỗi trong đề

⚠ Cấp cho AI: ⚠ cho Cloud Data Fusion (bên khởi tạo), ⚠ không phải cho Dataproc.

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

C (cấp Service Account User cho Cloud Dataproc) — ⚠ sai chiều: ⚠ Dataproc là bên ĐƯỢC TẠO RA; ⚠ bên cần quyền là bên KHỞI TẠO.
A (tạo cụm Dataproc trước khi khởi động Data Fusion) — ⚠ không giải quyết lỗi quyền: ⚠ và ⚠ Data Fusion thiết kế để tự tạo cụm ngắn hạn.
D (đảm bảo cả hai chạy cùng zone) — ⚠ lỗi vị trí sẽ có thông báo khác hẳn: ⚠ đây là lỗi uỷ quyền, không phải mạng.

Ghi nhớ

⚠ roles/iam.serviceAccountUser — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Cho phép | ⚠ "hành động thay" một service account | | ⚠ Cần khi | ⚠ tạo tài nguyên CHẠY DƯỚI service account đó | | ⚠ Ví dụ | ⚠ tạo VM, cụm Dataproc, job Dataflow, Cloud Function | | ⚠ Cấp cho | ⚠ người dùng hoặc service account KHỞI TẠO | | ⚠ Rất nhạy cảm | ⚠ ai có quyền này kế thừa được quyền của SA đó |

Từ khoá nhận diện:

"not authorized to act as a service account" → ⚠ thiếu iam.serviceAccountUser "cannot impersonate" → ⚠ thiếu iam.serviceAccountTokenCreator "permission denied on resource" → ⚠ thiếu vai trò trên chính tài nguyên

⚠ Hai vai trò dễ lẫn	Phân biệt
⚠ `serviceAccountUser`	⚠ GẮN service account vào tài nguyên khi tạo
⚠ `serviceAccountTokenCreator`	⚠ LẤY token, mạo danh service account trực tiếp
⚠ Cả hai đều mạnh	⚠ cấp cho ai có nghĩa cho họ mượn quyền của SA

⚠ Cloud Data Fusion — kiến trúc	Kiến trúc
⚠ Giao diện ETL kéo thả
⚠ Pipeline được BIÊN DỊCH thành job Spark
⚠ Chạy trên cụm Dataproc NGẮN HẠN tự tạo
⚠ Service account của Data Fusion tạo cụm đó
⚠ Vì vậy	⚠ cần quyền serviceAccountUser trên SA mà cụm sẽ dùng

⚠ Chẩn đoán lỗi quyền trên Google Cloud	Bước
⚠ 1. ĐỌC KỸ thông báo — nó thường nói rõ quyền thiếu
⚠ 2. Xác định danh tính nào đang thực hiện	⚠ người hay service account
⚠ 3. Xác định tài nguyên đích
⚠ 4. Dùng Policy Troubleshooter
⚠ 5. Kiểm tra Organization Policy	⚠ có thể chặn dù IAM đủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Service account nào thực hiện thao tác | | | Nó có serviceAccountUser trên SA đích không | | | Có Organization Policy nào chặn không | |

Và mẹo tiết kiệm thời gian nhất khi gặp lỗi quyền trên Google Cloud: đọc nguyên văn thông báo lỗi. Cụm từ "act as a service account" chỉ thẳng vào một vai trò duy nhất, và đoán mò luôn chậm hơn đọc.

Câu 85 Data analysis

A team of researchers is running a high performance distributed computing platform on premises but wants to migrate to Google Cloud. The platform uses virtual machines. The researchers want to be able to scale up the number of virtual machines in the cluster based on CPU load. What would you recommend they use?

A Kubernetes cluster
B Managed instance groups
C Unmanaged instance groups
D Cloud Run

Xem giải thích

Đáp án

B — Managed instance group (nhóm instance được quản).

Vì sao đúng

⚠ Ba dữ kiện của đề: | Dữ kiện | Suy ra | |---|---| | ⚠ Nền tảng dùng MÁY ẢO | ⚠ không phải container | | ⚠ Muốn tăng số VM theo tải CPU | ⚠ autoscaling của MIG | | ⚠ Di trú từ tại chỗ | ⚠ giữ nguyên mô hình VM, ít thay đổi |

⚠ Managed Instance Group
        ↓
⚠ Instance template định nghĩa VM mẫu
        ↓
⚠ Autoscaler theo dõi CPU
        ↓
⚠ CPU trung bình vượt ngưỡng
   → ⚠ TẠO THÊM VM
⚠ CPU thấp
   → ⚠ GỠ BỚT VM

⚠ Cộng thêm: ⚠ MIG tự khôi phục VM hỏng (autohealing) và ⚠ cập nhật cuốn chiếu.

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

A (cụm Kubernetes) — ⚠ đòi đóng gói lại thành CONTAINER: ⚠ thay đổi lớn về kiến trúc và kỹ năng; ⚠ đề nói nền tảng đang dùng máy ảo.
C (unmanaged instance group) — ⚠ KHÔNG có autoscaling, KHÔNG có autohealing: ⚠ chỉ là một danh sách VM gom lại.
D (Cloud Run) — ⚠ dành cho container không trạng thái: ⚠ không hợp với nền tảng tính toán phân tán chạy trên VM.

Ghi nhớ

⚠ Managed so với Unmanaged instance group — bảng phải thuộc: | Tính năng | ⚠ Managed | ⚠ Unmanaged | |---|---|---| | ⚠ Autoscaling | ⚠ CÓ | ⚠ KHÔNG | | ⚠ Autohealing | ⚠ CÓ | ⚠ KHÔNG | | ⚠ Cập nhật cuốn chiếu | ⚠ CÓ | ⚠ KHÔNG | | ⚠ VM đồng nhất từ template | ⚠ CÓ | ⚠ VM khác nhau tuỳ ý | | ⚠ Unmanaged dùng khi | ⚠ VM đã có sẵn, cấu hình khác nhau — hiếm khi nên dùng |

Từ khoá nhận diện:

"co giãn số VM theo tải" → ⚠ MIG + autoscaler "container, microservice" → ⚠ GKE hoặc Cloud Run "tính toán hiệu năng cao có bộ lập lịch" → ⚠ Batch, hoặc Slurm trên Compute Engine "VM tự thay khi hỏng" → ⚠ MIG autohealing

⚠ Autoscaler MIG — tín hiệu co giãn	Tín hiệu
⚠ Mức sử dụng CPU	⚠ phổ biến nhất — đề này
⚠ Dung lượng phục vụ của Load Balancer
⚠ Chỉ số Cloud Monitoring tuỳ chỉnh	⚠ độ dài hàng đợi chẳng hạn
⚠ Lịch (schedule-based)	⚠ biết trước giờ cao điểm
⚠ Tham số quan trọng	⚠ cooldown period — chờ VM khởi động xong mới đo lại

⚠ Lưu ý khi co giãn theo CPU	Lưu ý
⚠ Cooldown quá ngắn	⚠ tạo VM liên tục rồi lại xoá — dao động
⚠ Đặt `maxNumReplicas` để chặn chi phí
⚠ VM khởi động chậm thì co giãn phản ứng chậm	⚠ dùng ảnh nền đã cài sẵn
⚠ Với tính toán khoa học	⚠ cân nhắc Spot VM cho phần lớn worker

⚠ Lựa chọn khác cho tính toán hiệu năng cao	Lựa chọn
⚠ Google Cloud Batch	⚠ dịch vụ chạy job theo lô, được quản
⚠ Cluster Toolkit (HPC Toolkit)	⚠ dựng cụm HPC với Slurm
⚠ Dataproc	⚠ nếu là Spark/Hadoop
⚠ Đề này	⚠ MIG là câu trả lời sát yêu cầu nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VM mất bao lâu để khởi động xong | ⚠ quyết định độ trễ co giãn | | maxNumReplicas đã đặt chưa | ⚠ chặn hoá đơn bất ngờ | | Có dùng Spot VM cho worker được không | |

Và tham số hay bị bỏ quên khi bật autoscaling: giới hạn số lượng tối đa. Một vòng lặp lỗi làm CPU tăng vọt có thể sinh ra hàng trăm VM trong một đêm, và hoá đơn sẽ nói cho bạn biết vào cuối tháng.

Câu 86 Data pipelines

A manufacturer of delivery drones has equipped drones with multiple sensors that send performance and environment data to the analytics pipeline. Temperature received over the past hour is analyzed and if any temperature reading is more than 2 standard deviations away from the mean for the past hour, an alert is triggered. You would like to build the analysis pipeline using a managed service. What Google Cloud service would you recommend?

A Cloud Dataflow
B Cloud Dataproc
C Cloud Data Fusion
D Cloud Firestore

Xem giải thích

Đáp án

A — Cloud Dataflow.

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

⚠ Câu này dùng CÙNG kịch bản với #16200 ở lô trước, chỉ đổi câu hỏi.

Câu	Hỏi gì
⚠ #16200 (lô 157)	⚠ loại CỬA SỔ nào → sliding window
⚠ #16271 (câu này)	⚠ DỊCH VỤ nào → Dataflow
⚠ Bộ đề hay làm vậy	⚠ một kịch bản, hỏi nhiều khía cạnh
⚠ Nhớ cả cụm	⚠ Pub/Sub → Dataflow (sliding window) → cảnh báo

Vì sao đúng

⚠ Ghép yêu cầu với năng lực Dataflow: | Yêu cầu | Dataflow | |---|---| | ⚠ Xử lý LUỒNG thời gian thực | ⚠ hỗ trợ streaming gốc | | ⚠ Cửa sổ trượt một giờ | ⚠ windowing của Apache Beam | | ⚠ Tính trung bình và độ lệch chuẩn | ⚠ phép tổng hợp trong cửa sổ | | ⚠ DỊCH VỤ ĐƯỢC QUẢN | ⚠ không phải dựng cụm nào |

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

B (Cloud Dataproc) — ⚠ được quản nhưng vẫn phải QUẢN CỤM: ⚠ chọn máy, số node, autoscaling; ⚠ Spark Streaming làm được nhưng ⚠ nặng nề hơn cho bài toán này.
C (Cloud Data Fusion) — ⚠ công cụ ETL trực quan: ⚠ thiên về batch và tích hợp dữ liệu, ⚠ không phải phân tích luồng có cửa sổ thống kê.
D (Cloud Firestore) — ⚠ CSDL, không phải công cụ xử lý.

Ghi nhớ

⚠ Chọn dịch vụ xử lý — bảng phải thuộc: | Nhu cầu | Dịch vụ | |---|---| | ⚠ Streaming, cửa sổ, tổng hợp thời gian thực | ⚠ Dataflow | | ⚠ Đã có mã Spark/Hadoop | ⚠ Dataproc | | ⚠ ETL kéo thả, không viết mã | ⚠ Data Fusion | | ⚠ Điều phối nhiều bước | ⚠ Cloud Composer | | ⚠ Xử lý sự kiện đơn giản | ⚠ Cloud Functions |

Từ khoá nhận diện:

"phân tích luồng, được quản, có cửa sổ" → ⚠ Dataflow "cửa sổ trượt một giờ" → ⚠ sliding window trong Beam "cảnh báo khi vượt ngưỡng thống kê" → ⚠ tính trong cửa sổ rồi đẩy sang Pub/Sub hoặc Monitoring

⚠ Kiến trúc đầy đủ cho bài toán này	Kiến trúc
⚠ Cảm biến → Pub/Sub	⚠ thu nhận, đệm
⚠ Pub/Sub → Dataflow	⚠ sliding window 1 giờ, trượt mỗi phút
⚠ Dataflow tính trung bình và độ lệch chuẩn
⚠ Vượt 2 độ lệch chuẩn → phát cảnh báo	⚠ Pub/Sub topic cảnh báo
⚠ Song song ghi BigQuery	⚠ phân tích lịch sử

⚠ Vì sao Dataflow hơn Dataproc cho streaming	Lý do
⚠ Không quản cụm, tự co giãn theo tồn đọng
⚠ Xử lý watermark và dữ liệu tới muộn sẵn có
⚠ Cùng mã cho batch và streaming
⚠ Trả tiền theo tài nguyên thực dùng
⚠ Dataproc hơn khi	⚠ đã có sẵn mã Spark, muốn giữ nguyên

⚠ Phát hiện bất thường — các mức độ	Mức độ
⚠ Ngưỡng cố định	⚠ đơn giản nhất
⚠ Độ lệch chuẩn theo cửa sổ trượt	⚠ đề này — thích nghi theo thời gian
⚠ Mô hình học máy	⚠ BigQuery ML, Vertex AI
⚠ Ưu điểm của cách trong đề	⚠ tự điều chỉnh theo điều kiện thực tế, không cần huấn luyện

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bước trượt của cửa sổ có quá nhỏ không | ⚠ tốn tài nguyên | | Dữ liệu cảm biến tới muộn bao lâu | ⚠ đặt allowed lateness | | Cảnh báo có bị nhiễu quá nhiều không | ⚠ điều chỉnh ngưỡng độ lệch |

Và điều quyết định một hệ thống cảnh báo có được dùng lâu dài hay không: tỉ lệ báo động giả. Một hệ thống kêu quá nhiều sẽ bị tắt tiếng, và khi đó nó tệ hơn cả việc không có gì.

Câu 87 Machine Learning

A retailer has been using Kubernetes to deploy new applications built on microservices architectures. They now want to start building machine learning pipelines while leveraging their expertise in Kubernetes. What service would you recommend for running machine learning workflows on Kubernetes?

A Vertex AI
B AutoML Tables
C Kubeflow
D Cloud Composer

Xem giải thích

Đáp án

C — Kubeflow.

Vì sao đúng

⚠ Đề nhấn "tận dụng chuyên môn Kubernetes sẵn có":

⚠ Đội đã giỏi Kubernetes
        ↓
⚠ Kubeflow = ⚠ nền tảng ML
   CHẠY TRÊN Kubernetes
        ↓
⚠ Dùng lại kỹ năng, công cụ,
   quy trình vận hành đã có
        ↓
⚠ Không phải học nền tảng mới

Kubeflow gồm gì	Thành phần
⚠ Kubeflow Pipelines	⚠ quy trình ML dạng DAG
⚠ Notebook servers
⚠ Training operator	⚠ huấn luyện phân tán
⚠ KServe	⚠ phục vụ mô hình
⚠ Katib	⚠ dò siêu tham số

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

A (Vertex AI) — ⚠ nền tảng ML rất tốt nhưng KHÔNG chạy trên Kubernetes của khách: ⚠ đề yêu cầu tận dụng chuyên môn Kubernetes; ⚠ (lưu ý: Vertex AI Pipelines chạy được pipeline định nghĩa bằng KFP SDK).
B (AutoML Tables) — ⚠ chỉ huấn luyện tự động trên dữ liệu bảng: ⚠ không phải nền tảng quy trình ML.
D (Cloud Composer) — ⚠ điều phối luồng công việc CHUNG bằng Airflow: ⚠ không chuyên cho ML; ⚠ thiếu các thành phần như phục vụ mô hình, dò siêu tham số.

Ghi nhớ

⚠ Nền tảng MLOps — bảng phải thuộc: | Nền tảng | Đặc điểm | |---|---| | ⚠ Kubeflow | ⚠ mã nguồn mở, chạy trên Kubernetes — đề này | | ⚠ Vertex AI Pipelines | ⚠ được quản, không cần quản cụm | | ⚠ Cloud Composer | ⚠ điều phối chung, không chuyên ML | | ⚠ TFX | ⚠ thư viện pipeline cho TensorFlow | | ⚠ Lưu ý quan trọng | ⚠ Vertex AI Pipelines CHẠY ĐƯỢC pipeline viết bằng Kubeflow Pipelines SDK |

Từ khoá nhận diện:

"ML trên Kubernetes, tận dụng chuyên môn K8s" → ⚠ Kubeflow "không muốn quản hạ tầng" → ⚠ Vertex AI "điều phối job dữ liệu chung" → ⚠ Cloud Composer "pipeline TensorFlow chuẩn hoá" → ⚠ TFX

⚠ Các bước của một quy trình MLOps	Bước
⚠ Nạp và kiểm chứng dữ liệu
⚠ Kỹ thuật đặc trưng
⚠ Huấn luyện và dò siêu tham số
⚠ Đánh giá và kiểm chứng mô hình
⚠ Triển khai và phục vụ
⚠ Theo dõi trôi dữ liệu, huấn luyện lại
⚠ Kubeflow phủ	⚠ toàn bộ các bước trên

⚠ Đánh đổi Kubeflow so với Vertex AI	Đánh đổi
⚠ Kubeflow: toàn quyền, chạy được ở mọi nơi có K8s	⚠ kể cả tại chỗ, đám mây khác
⚠ Kubeflow: PHẢI tự vận hành, tự nâng cấp
⚠ Vertex AI: được quản, ít việc vận hành
⚠ Vertex AI: gắn với Google Cloud
⚠ Nếu đội đã giỏi K8s	⚠ chi phí vận hành Kubeflow thấp hơn nhiều so với đội không biết

⚠ Vì sao MLOps quan trọng	Lý do
⚠ Mô hình xuống cấp theo thời gian	⚠ trôi dữ liệu
⚠ Cần huấn luyện lại đều đặn
⚠ Cần dựng lại được kết quả	⚠ cùng dữ liệu, cùng mã, cùng mô hình
⚠ Cần quay lui khi mô hình mới tệ hơn
⚠ Thực tế	⚠ phần lớn công sức của dự án ML nằm SAU khi mô hình đã xong

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội có sẵn sàng vận hành thêm một nền tảng không | | | Có cần chạy ở nhiều môi trường không | ⚠ Kubeflow có lợi thế | | Đã có quy trình huấn luyện lại tự động chưa | |

Và sự thật ít được nói tới về dự án học máy: huấn luyện được mô hình tốt là phần dễ. Phần khó là giữ cho nó còn tốt sau sáu tháng, và đó chính là lý do MLOps tồn tại.

Câu 88 Databases

A manufacturer of delivery drones has been using a PostgreSQL database running in Compute Engine to store data. The company is growing and the database is not able to keep up with the ingestion of telemetry data from the drones. The CTO would like to use a managed database service that will provide low latency writes and scale to petabytes of data. The top priority is scalability and the CTO is willing to invest development time in changing the application if needed. What managed Google Cloud database service would you recommend?

A Cloud SQL using PostgreSQL
B Cloud Spanner
C Cloud Bigtable
D BigQuery

Xem giải thích

Đáp án

C — Cloud Bigtable.

Vì sao đúng

⚠ Ba yêu cầu, cả ba đều chỉ về Bigtable: | Yêu cầu | Bigtable | |---|---| | ⚠ Ghi độ trễ thấp | ⚠ dưới 10 mili giây | | ⚠ Co giãn tới PETABYTE | ⚠ đúng quy mô thiết kế | | ⚠ Sẵn sàng SỬA ứng dụng | ⚠ gỡ bỏ ràng buộc phải giữ SQL |

⚠ Dữ liệu telemetry từ drone = ⚠ chuỗi thời gian khối lượng lớn — ⚠ ca dùng kinh điển của Bigtable.

⚠ PostgreSQL trên Compute Engine
   ⚠ không theo kịp tốc độ ghi
        ↓ ⚠ vì sao
   ⚠ CSDL quan hệ co giãn theo CHIỀU DỌC
   ⚠ mỗi lần ghi phải giữ ACID, index, khoá
        ↓ ⚠ Bigtable
   ⚠ co giãn NGANG: thêm node = thêm thông lượng

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

B (Cloud Spanner) — ⚠ co giãn tốt nhưng ĐẮT hơn nhiều: ⚠ giữ nhất quán mạnh toàn cầu là ⚠ chi phí không cần thiết cho dữ liệu telemetry.
A (Cloud SQL PostgreSQL) — ⚠ cùng giới hạn với hệ thống hiện tại: ⚠ vẫn co giãn theo chiều dọc; ⚠ chỉ dời vấn đề đi chỗ khác.
D (BigQuery) — ⚠ kho PHÂN TÍCH, không phải CSDL ghi độ trễ thấp: ⚠ nhưng ⚠ là đích tốt để phân tích lịch sử sau khi qua Bigtable.

Ghi nhớ

⚠ Ngưỡng chọn CSDL theo quy mô — bảng phải thuộc: | Quy mô và nhu cầu | Dịch vụ | |---|---| | ⚠ Dưới vài TB, quan hệ | ⚠ Cloud SQL | | ⚠ Quan hệ + toàn cầu + nhất quán mạnh | ⚠ Spanner | | ⚠ Trên 1 TB, ghi/đọc độ trễ thấp, khối lượng lớn | ⚠ Bigtable — đề này | | ⚠ Tài liệu, ứng dụng web/di động | ⚠ Firestore | | ⚠ Phân tích | ⚠ BigQuery |

Từ khoá nhận diện:

"telemetry, IoT, chuỗi thời gian, petabyte" → ⚠ Bigtable "cần SQL và giao dịch toàn cầu" → ⚠ Spanner "phân tích lịch sử" → ⚠ BigQuery "sẵn sàng sửa ứng dụng" → ⚠ mở đường cho lựa chọn NoSQL

⚠ Vì sao CSDL quan hệ khó chịu tải ghi IoT	Lý do
⚠ Mỗi lần ghi cập nhật nhiều index
⚠ Đảm bảo ACID tốn chi phí đồng bộ
⚠ Chỉ một node nhận ghi
⚠ Bảng lớn làm index phình to
⚠ Bigtable ngược lại	⚠ ghi tuần tự vào bộ nhớ rồi flush — rất nhanh

⚠ Chi phí sửa ứng dụng khi chuyển sang Bigtable	Chi phí
⚠ Thiết kế lại ROW KEY theo mẫu truy vấn	⚠ việc quan trọng nhất
⚠ Bỏ JOIN — phi chuẩn hoá dữ liệu
⚠ Không có giao dịch nhiều dòng
⚠ Không có index phụ
⚠ Đề đã nói rõ	⚠ CTO chấp nhận đầu tư thời gian phát triển

⚠ Kiến trúc telemetry hoàn chỉnh	Kiến trúc
⚠ Drone → Pub/Sub
⚠ Pub/Sub → Dataflow
⚠ Dataflow → Bigtable	⚠ truy vấn gần thời gian thực
⚠ Dataflow → BigQuery	⚠ phân tích lịch sử
⚠ Chính sách hết hạn trên Bigtable	⚠ xoá dữ liệu cũ tự động

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mọi truy vấn có đi qua row key được không | ⚠ nếu không thì Bigtable sai lựa chọn | | Dữ liệu có vượt 1 TB không | ⚠ dưới đó Bigtable hơi đắt | | Đã đặt chính sách hết hạn chưa | ⚠ dữ liệu IoT tăng vô hạn |

Và câu hỏi kiểm tra quyết định trước khi cam kết dùng Bigtable: liệt kê mọi câu hỏi hệ thống cần trả lời, rồi xem có trả lời được bằng row key không. Nếu có một câu không, hãy dừng lại và thiết kế lại khoá.

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

A Cloud Spanner database is experiencing hot-spotting. You suggest changing the primary keys of tables in the database. What methods would you consider when defining new keys? (Choose 2).

A Hash value of existing primary key
B Auto-incrementing values
C Big-reversed sequential values
D Timestamps
E Start primary key with low cardinality attribute

Xem giải thích

Đáp án

A và C — Băm giá trị khoá chính hiện tại, và dùng giá trị tuần tự ĐẢO BIT.

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

⚠ Phương án C gõ sai chính tả.

Đề viết	Đúng phải là
⚠ "Big-reversed sequential values"	⚠ "BIT-reversed sequential values"
⚠ Nghĩa	⚠ đảo thứ tự BIT của số tuần tự

⚠ Không ảnh hưởng đáp án — ⚠ nhưng nên biết thuật ngữ đúng để tra cứu.

Vì sao đúng

⚠ Spanner chia dữ liệu theo KHOẢNG khoá chính — ⚠ giống Bigtable.

⚠ Khoá tuần tự: 1001, 1002, 1003…
        ↓
⚠ Mọi ghi mới vào CÙNG một split
        ↓
⚠ ĐIỂM NÓNG

⚠ Cách chữa A: BĂM khoá
   ⚠ hash(1001) = 8f3a…
   ⚠ hash(1002) = 2b7c…
        ↓ ⚠ rải đều

⚠ Cách chữa C: ĐẢO BIT
   ⚠ 1001 → đảo bit → số rất khác
   ⚠ 1002 → đảo bit → số rất khác
        ↓ ⚠ rải đều mà vẫn duy nhất

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

B (giá trị tự tăng) và D (dấu thời gian) — ⚠ CHÍNH LÀ nguyên nhân gây điểm nóng: ⚠ cả hai đều tuần tự.
E (bắt đầu khoá bằng thuộc tính có ĐỘ PHÂN BIỆT THẤP) — ⚠ làm điểm nóng TỆ HƠN: ⚠ ít giá trị phân biệt nghĩa là ⚠ nhiều dòng dồn vào cùng dải khoá; ⚠ phải làm ngược lại — dùng thuộc tính có độ phân biệt CAO.

Ghi nhớ

⚠ Thiết kế khoá chính Spanner — bảng phải thuộc: | Cách | Đánh giá | |---|---| | ⚠ UUID phiên bản 4 | ⚠ TỐT — ngẫu nhiên | | ⚠ Băm khoá tự nhiên | ⚠ TỐT | | ⚠ Đảo bit số tuần tự | ⚠ TỐT — giữ được tính duy nhất | | ⚠ Đổi thứ tự: cột phân biệt cao lên trước | ⚠ TỐT | | ⚠ Số tự tăng | ⚠ XẤU | | ⚠ Dấu thời gian ở đầu | ⚠ XẤU |

Từ khoá nhận diện:

"điểm nóng Spanner" → ⚠ khoá chính tuần tự "điểm nóng Bigtable" → ⚠ row key tuần tự — CÙNG nguyên lý "UUID vẫn nóng" → ⚠ dùng UUID có thứ tự (v1/v7)

⚠ Đảo bit hoạt động thế nào	Cơ chế
⚠ Số tuần tự khác nhau ở bit THẤP	⚠ 1000, 1001, 1002…
⚠ Đảo bit đưa bit thấp lên ĐẦU
⚠ Kết quả: các số liền nhau thành rất xa nhau
⚠ Vẫn DUY NHẤT và đảo ngược được	⚠ ưu điểm so với băm
⚠ Đánh đổi	⚠ mất khả năng quét theo khoảng thứ tự gốc

⚠ Băm so với đảo bit	So sánh
⚠ Băm: rải rất đều, nhưng không đảo ngược được
⚠ Đảo bit: rải đều, VẪN suy ra được giá trị gốc
⚠ Cả hai: mất thứ tự tự nhiên
⚠ Nếu cần cả hai	⚠ thêm cột riêng lưu giá trị gốc và đánh index

⚠ Cách khác giảm điểm nóng	Cách
⚠ Đảo thứ tự cột trong khoá chính	⚠ cột phân biệt cao lên trước
⚠ Thêm tiền tố phân mảnh (shard)	⚠ `shard_id` = hash % N
⚠ Interleave bảng con vào bảng cha	⚠ giảm truy cập chéo split
⚠ Công cụ chẩn đoán	⚠ Key Visualizer của Spanner

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khoá chính có tuần tự không | | | Key Visualizer cho thấy gì | | | Có cần quét theo khoảng không | ⚠ quyết định được phép băm hay không |

Và điểm chung đáng nhớ giữa Spanner và Bigtable: cả hai đều chia dữ liệu theo khoảng khoá, nên cả hai đều ghét khoá tuần tự. Học một lần, áp dụng được cho cả hai.

Câu 90 Databases

You have a latency-sensitive application that uses Bigtable. You want to follow Google Cloud recommended best practices. What would you do?

A
Use a service account for all read operations
B Keep storage utilization per node below 60%
C Use HDD storage instead of SSD storage
D Use a global load balancer in front of Bigtable

Xem giải thích

Đáp án

B — Giữ mức sử dụng lưu trữ mỗi node dưới 60%.

Vì sao đúng

⚠ Khuyến nghị của Google cho Bigtable nhạy độ trễ: | Ngưỡng | Ý nghĩa | |---|---| | ⚠ Lưu trữ mỗi node dưới 60% | ⚠ cho ứng dụng nhạy ĐỘ TRỄ | | ⚠ Lưu trữ mỗi node dưới 70% | ⚠ ngưỡng chung | | ⚠ CPU dưới 70% | ⚠ ngưỡng chung |

⚠ Node đầy dữ liệu
        ↓
⚠ Ít chỗ cho bộ nhớ đệm
⚠ Nén và dọn dẹp tốn tài nguyên hơn
⚠ Chia tablet lại thường xuyên hơn
        ↓
⚠ ĐỘ TRỄ TĂNG và dao động

⚠ Để dư dung lượng nghĩa là mua độ trễ ổn định bằng tiền node.

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

C (dùng HDD thay SSD) — ⚠ NGƯỢC với nhu cầu: ⚠ ứng dụng nhạy độ trễ ⚠ phải dùng SSD; ⚠ HDD chỉ hợp cho khối lượng lớn ít truy cập.
D (đặt global load balancer trước Bigtable) — ⚠ KHÔNG áp dụng được: ⚠ client thư viện Bigtable tự định tuyến tới đúng node.
A (dùng service account cho mọi thao tác đọc) — ⚠ là chuyện XÁC THỰC, không liên quan độ trễ.

Ghi nhớ

⚠ Ngưỡng vận hành Bigtable — bảng phải thuộc: | Chỉ số | Ngưỡng | |---|---| | ⚠ CPU trung bình cụm | ⚠ dưới 70% | | ⚠ CPU node nóng nhất | ⚠ dưới 90% | | ⚠ Lưu trữ mỗi node | ⚠ dưới 70% (dưới 60% nếu nhạy độ trễ) | | ⚠ SSD tối đa mỗi node | ⚠ khoảng 5 TB | | ⚠ HDD tối đa mỗi node | ⚠ khoảng 16 TB |

Từ khoá nhận diện:

"nhạy độ trễ" → ⚠ SSD + để dư dung lượng + client cùng vùng "khối lượng lớn, ít đọc, tiết kiệm" → ⚠ HDD "độ trễ dao động" → ⚠ kiểm tra điểm nóng và mức dùng lưu trữ

⚠ SSD so với HDD trong Bigtable	So sánh
⚠ SSD: độ trễ thấp và ỔN ĐỊNH	⚠ mặc định nên chọn
⚠ HDD: rẻ hơn, độ trễ cao hơn nhiều
⚠ HDD hợp với: quét lớn, ít truy cập ngẫu nhiên
⚠ KHÔNG đổi được sau khi tạo instance	⚠ phải tạo mới và chép dữ liệu

⚠ Các yếu tố khác ảnh hưởng độ trễ Bigtable	Yếu tố
⚠ Điểm nóng row key	⚠ nguyên nhân số một
⚠ Client ở KHÁC vùng với cụm	⚠ thêm hàng chục mili giây
⚠ Dòng quá lớn
⚠ Quá nhiều column family
⚠ Số node không đủ
⚠ Quét khoảng lớn cạnh tranh với đọc điểm	⚠ tách bằng app profile

⚠ Vì sao "để dư" là thực hành tốt chung	Lý do
⚠ Hệ thống chạy sát ngưỡng thì độ trễ tăng phi tuyến
⚠ Cần dư để chịu đỉnh tải bất ngờ
⚠ Cần dư cho việc dọn dẹp nội bộ
⚠ Áp dụng cho	⚠ CPU, đĩa, bộ nhớ, kết nối — mọi tài nguyên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mức dùng lưu trữ mỗi node là bao nhiêu | | | Client có cùng vùng với cụm không | | | Có dùng HDD cho ứng dụng nhạy độ trễ không | ⚠ sai lầm không sửa được tại chỗ |

Và quyết định gần như không đảo ngược được khi tạo instance Bigtable: chọn SSD hay HDD. Đổi ý sau đó có nghĩa là tạo instance mới và chép lại toàn bộ dữ liệu.

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

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

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ớ