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

Câu 51 Databases

You have a real-time monitoring application that streams data to Bigtable. It is not performing as well as expected. You use a row key that starts with a unique ID of each source system. Each source system sends 500K of data per minute and that is written to one row. There are approximately 200 column families, each having on average 10 columns. What could be the cause of the poor performance?

A 500K is more data than Bigtable can efficiently ingest per row
B 200 column families exceeds the recommended 100 column family limit
C Row keys should not start with a unique ID
D 10 columns per column family is exceeds the recommended 5 columns maximum per column family

Xem giải thích

Đáp án

B — 200 column family vượt quá giới hạn khuyến nghị 100 column family của Bigtable.

Vì sao đúng

⚠ Giới hạn khuyến nghị của Bigtable: | Đại lượng | Khuyến nghị | |---|---| | ⚠ Số column family mỗi bảng | ⚠ KHÔNG quá 100 | | ⚠ Kích thước một ô | ⚠ dưới 100 MB | | ⚠ Kích thước một dòng | ⚠ dưới 100 MB, lý tưởng dưới 10 MB | | ⚠ Độ dài row key | ⚠ dưới 4 KB |

⚠ 200 column family
        ↓
⚠ Gấp đôi khuyến nghị
        ↓
⚠ Bigtable phải quản nhiều nhóm
   lưu trữ hơn cần thiết
        ↓
⚠ Hiệu năng giảm

⚠ Thực tế nên dùng RẤT ÍT column family — ⚠ thường chỉ vài cái.

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

A (500 KB mỗi dòng là quá nhiều cho Bigtable) — ⚠ 500 KB HOÀN TOÀN ổn: ⚠ giới hạn khuyến nghị là 100 MB mỗi dòng.
C (row key không nên bắt đầu bằng ID duy nhất) — ⚠ NGƯỢC LẠI: ⚠ bắt đầu bằng ID hệ thống nguồn là ⚠ thiết kế TỐT — nó rải đều theo nguồn.
D (10 cột mỗi column family vượt mức tối đa 5) — ⚠ KHÔNG có giới hạn 5 cột: ⚠ số column qualifier trong một family gần như không giới hạn.

Ghi nhớ

⚠ Giới hạn Bigtable phải nhớ — bảng: | Giới hạn | Con số | |---|---| | ⚠ Column family mỗi bảng | ⚠ khuyến nghị ≤ 100 | | ⚠ Column qualifier mỗi family | ⚠ gần như không giới hạn | | ⚠ Kích thước ô | ⚠ ≤ 100 MB | | ⚠ Kích thước dòng | ⚠ ≤ 100 MB (lý tưởng ≤ 10 MB) | | ⚠ Row key | ⚠ ≤ 4 KB |

Từ khoá nhận diện:

"quá nhiều column family" → ⚠ giới hạn 100 "ghi dồn một node" → ⚠ row key tuần tự "dòng quá lớn" → ⚠ trên 100 MB "cần index phụ" → ⚠ Bigtable KHÔNG có

⚠ Vì sao nên ít column family	Lý do
⚠ Mỗi family là một nhóm lưu trữ riêng
⚠ Nhiều family = nhiều siêu dữ liệu phải quản
⚠ Chính sách hết hạn đặt theo family	⚠ nhiều family thì nhiều chính sách
⚠ Thiết kế tốt	⚠ vài family, mỗi cái gom các cột hay đọc cùng nhau
⚠ Thay vì nhiều family	⚠ dùng nhiều COLUMN QUALIFIER trong một family

⚠ Chính sách hết hạn (garbage collection)	Chính sách
⚠ Đặt theo COLUMN FAMILY
⚠ Theo số phiên bản tối đa	⚠ giữ N bản gần nhất
⚠ Theo tuổi	⚠ xoá dữ liệu cũ hơn N ngày
⚠ Kết hợp cả hai
⚠ Quan trọng với chuỗi thời gian	⚠ không xoá thì dữ liệu tăng vô hạn

⚠ Chẩn đoán hiệu năng Bigtable	Bước
⚠ 1. Key Visualizer	⚠ có điểm nóng không
⚠ 2. CPU từng node	⚠ lệch nhau nhiều là điểm nóng
⚠ 3. Số column family và kích thước dòng	⚠ đề này
⚠ 4. Client có ở cùng vùng với cụm không
⚠ 5. Số node có đủ không	⚠ nên giữ CPU dưới 70%

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng có bao nhiêu column family | ⚠ trên 100 là phải thiết kế lại | | Chính sách hết hạn đã đặt chưa | | | Client có nằm cùng vùng với cụm không | |

Và cách nghĩ đúng về column family: đó là đơn vị LƯU TRỮ, không phải đơn vị TỔ CHỨC. Muốn phân loại dữ liệu thì dùng tên cột; column family chỉ nên phản ánh những nhóm cột thật sự luôn được đọc cùng nhau.

Câu 52 Data management

You are uploading several hundred files to Google Cloud using gsutil rsynch. The set of files fails to fully upload. You'd rather not reload files that were successfully uploaded. What command would you use to resume the rsynch operation?

A The same command that was used initially. Gsutil rsynch will automatically resume.
B The gsutil rsynch resume command
C The same command that was used initially and the --resume parameter.
D The same command that was used initially and the --upload parameter.

Xem giải thích

Đáp án

A — Chạy lại đúng lệnh ban đầu; gsutil rsync tự động tiếp tục.

Vì sao đúng

⚠ rsync làm việc bằng cách SO SÁNH nguồn và đích:

⚠ Chạy lại lệnh cũ
        ↓
⚠ gsutil liệt kê tệp ở NGUỒN
⚠ gsutil liệt kê tệp ở ĐÍCH
        ↓
⚠ So sánh tên, kích thước, checksum
        ↓
⚠ CHỈ chuyển tệp còn THIẾU hoặc KHÁC
        ↓
⚠ Tệp đã tải xong được BỎ QUA

⚠ Không cần tham số đặc biệt nào — ⚠ đó chính là bản chất của rsync.

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

C (--resume) và D (--upload) — ⚠ hai tham số này KHÔNG tồn tại trong gsutil rsync.
B (gsutil rsync resume) — ⚠ lệnh con KHÔNG tồn tại.

Ghi nhớ

⚠ gsutil rsync — cờ hay dùng: | Cờ | Việc | |---|---| | ⚠ -r | ⚠ đệ quy vào thư mục con | | ⚠ -d | ⚠ XOÁ ở đích những gì không có ở nguồn — NGUY HIỂM | | ⚠ -n | ⚠ chạy thử (dry run), chỉ in ra sẽ làm gì | | ⚠ -m | ⚠ chạy song song, nhanh hơn nhiều | | ⚠ -c | ⚠ so sánh bằng checksum thay vì kích thước và thời gian |

Từ khoá nhận diện:

"tiếp tục việc tải dở" → ⚠ chạy lại rsync, tự tiếp tục "đồng bộ hai bên giống hệt nhau" → ⚠ rsync -d — cẩn thận, có xoá "chỉ sao chép, không đồng bộ" → ⚠ gsutil cp "chuyển từ đám mây khác, có lịch" → ⚠ Storage Transfer Service

⚠ `cp` so với `rsync`	So sánh
⚠ `cp`: chép mọi thứ, kể cả đã có	⚠ `-n` để không ghi đè
⚠ `rsync`: chỉ chép cái khác biệt
⚠ `rsync -d`: đồng bộ hai chiều nội dung	⚠ xoá được ở đích
⚠ Chuyển lớn dở dang	⚠ rsync là lựa chọn đúng

⚠ Cảnh báo về cờ `-d`	Cảnh báo
⚠ Xoá mọi thứ ở đích không có ở nguồn
⚠ Chỉ sai đường dẫn nguồn là xoá sạch bucket
⚠ LUÔN chạy `-n` trước để xem
⚠ Bảo vệ	⚠ bật object versioning trên bucket quan trọng

⚠ Xu hướng: `gcloud storage` thay `gsutil`	Xu hướng
⚠ `gcloud storage cp`, `gcloud storage rsync`
⚠ Nhanh hơn đáng kể với nhiều tệp nhỏ
⚠ Cú pháp gần giống
⚠ Trong đề thi cũ	⚠ vẫn hay hỏi gsutil

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã chạy -n trước khi dùng -d chưa | | | Có dùng -m để chạy song song không | ⚠ khác biệt lớn về thời gian | | Bucket đích có bật versioning không | |

Và thói quen đáng hình thành với mọi lệnh đồng bộ có khả năng xoá: luôn chạy chế độ thử trước. Một tham số -n mất hai giây và đã cứu rất nhiều bucket.

Câu 53 Data management

Your company has created a new data analytics team. Data analysts will need to read data from and write data to Cloud Storage and query data from BigQuery. Data engineers will also need to create Cloud Storage buckets and set data lifecycle management policies on buckets. You want to follow Google Cloud's recommended best practices. How would you manage access permission for the new team?

A Grant roles to each user individually. Assign data engineers the same roles as data analysts and additional roles needed for their additional responsibilities.
B Create a group for data analysts and a group for data engineers. Add the identities of data analysts to the data analyst group. Add the identities of the data engineers to the data engineer group. Grant roles to the data analyst group to allow access needed by data analysts. Grant roles to the data engineer group needed by the data engineers.
C Create a group for the data analytics team. Grant the group all roles needed by data analysts and data engineers to that group. Add the identities of all team members to the group.
D Grant roles to each user individually. Assign data engineers and data analysts the roles needed by either data analysts or data engineers.

Xem giải thích

Đáp án

B — Tạo một nhóm cho nhà phân tích dữ liệu và một nhóm cho kỹ sư dữ liệu, thêm từng người vào đúng nhóm, rồi cấp vai trò cho từng nhóm.

Vì sao đúng

⚠ Hai nguyên tắc của Google Cloud gặp nhau ở đây: | Nguyên tắc | Cách B thoả | |---|---| | ⚠ Cấp quyền cho NHÓM, không cho cá nhân | ⚠ hai nhóm | | ⚠ Quyền tối thiểu | ⚠ mỗi nhóm chỉ có quyền của vai trò đó |

⚠ Nhóm "nha-phan-tich"
   → ⚠ đọc/ghi Cloud Storage
   → ⚠ truy vấn BigQuery

⚠ Nhóm "ky-su-du-lieu"
   → ⚠ tạo bucket
   → ⚠ đặt lifecycle policy
        ↓
⚠ Người mới vào: chỉ cần thêm
   vào ĐÚNG nhóm

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

C (một nhóm chung cho cả đội, cấp mọi quyền của cả hai vai trò) — ⚠ vi phạm quyền tối thiểu: ⚠ nhà phân tích được quyền tạo bucket và đặt lifecycle dù không cần.
A (cấp vai trò cho từng người) — ⚠ không mở rộng được: ⚠ mỗi người vào hoặc ra là ⚠ phải sửa IAM thủ công; ⚠ dễ bỏ sót.
D (cấp cho từng người, và cho ai cũng quyền của cả hai vai trò) — ⚠ sai cả hai nguyên tắc.

Ghi nhớ

⚠ Thực hành IAM tốt — bảng phải thuộc: | Thực hành | Lý do | |---|---| | ⚠ Cấp cho NHÓM | ⚠ thay đổi nhân sự không phải sửa IAM | | ⚠ Một nhóm cho mỗi VAI TRÒ CÔNG VIỆC | ⚠ quyền tối thiểu | | ⚠ Dùng vai trò predefined | ⚠ tự cập nhật khi có tính năng mới | | ⚠ Custom role khi predefined quá rộng | | | ⚠ Cấp ở cấp tài nguyên hẹp nhất | ⚠ bucket thay vì project |

Từ khoá nhận diện:

"nhiều người cùng vai trò" → ⚠ Google Group "vai trò có sẵn thừa quyền" → ⚠ custom role "quyền tạm thời, có hạn" → ⚠ IAM Conditions "cấp Owner cho tiện" → ⚠ LUÔN SAI

⚠ Vai trò Cloud Storage hay dùng	Vai trò
⚠ `storage.objectViewer`	⚠ chỉ đọc object
⚠ `storage.objectCreator`	⚠ chỉ ghi, không đọc, không xoá
⚠ `storage.objectUser`	⚠ đọc và ghi object
⚠ `storage.admin`	⚠ quản bucket, lifecycle — cho kỹ sư dữ liệu
⚠ Nhà phân tích	⚠ objectUser là đủ, không cần admin

⚠ Vai trò BigQuery hay dùng	Vai trò
⚠ `bigquery.dataViewer`	⚠ đọc dữ liệu
⚠ `bigquery.dataEditor`	⚠ đọc và ghi dữ liệu
⚠ `bigquery.jobUser`	⚠ CHẠY truy vấn — hay bị quên!
⚠ `bigquery.user`	⚠ chạy truy vấn + tạo dataset
⚠ Bẫy kinh điển	⚠ có dataViewer mà thiếu jobUser thì KHÔNG chạy được truy vấn

⚠ Vì sao nhóm quan trọng hơn người ta nghĩ	Lý do
⚠ Người nghỉ việc chỉ cần gỡ khỏi nhóm
⚠ Kiểm toán nhìn nhóm là hiểu ngay ai làm gì
⚠ Nhóm đồng bộ được từ Active Directory	⚠ qua GCDS
⚠ Chính sách IAM ngắn và đọc được
⚠ Không dùng nhóm	⚠ chính sách IAM dài hàng trăm dòng, không ai hiểu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách IAM có bao nhiêu binding cho cá nhân | ⚠ càng ít càng tốt | | Nhóm có đồng bộ từ hệ thống nhân sự không | | | Có ai thừa quyền không | ⚠ IAM Recommender |

Và thước đo đơn giản cho sức khoẻ của một chính sách IAM: đọc nó có hiểu được ai làm gì không. Nếu chính sách toàn địa chỉ email cá nhân thay vì tên nhóm, thì không ai còn kiểm soát được nó nữa.

Câu 54 Data management

A BigQuery data warehouse needs to access some data in Cloud Storage using external tables. Which of the following is not a supported file format for external tables based on files in Cloud Storage?

A Avro
B
ORC
C Firestore export files
D Excel xlsx format

Xem giải thích

Đáp án

D — Định dạng Excel xlsx.

Vì sao đúng

⚠ Đề hỏi định dạng nào KHÔNG được hỗ trợ cho external table dựa trên tệp ở Cloud Storage.

⚠ Định dạng ĐƯỢC hỗ trợ: | Định dạng | Hỗ trợ | |---|---| | ⚠ Avro | ⚠ CÓ | | ⚠ ORC | ⚠ CÓ | | ⚠ Parquet | ⚠ CÓ | | ⚠ CSV | ⚠ CÓ | | ⚠ JSON (newline-delimited) | ⚠ CÓ | | ⚠ Firestore / Datastore export | ⚠ CÓ | | ⚠ Excel xlsx | ⚠ KHÔNG |

⚠ Vì sao xlsx không được hỗ trợ: ⚠ đó là định dạng nhị phân độc quyền với nhiều sheet, công thức, định dạng ô — ⚠ không phải định dạng dữ liệu dạng cột hay dòng thuần.

⚠ Muốn nạp Excel: ⚠ xuất sang CSV trước, ⚠ hoặc dùng Connected Sheets với Google Sheets.

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

A (Avro), B (ORC), C (tệp export của Firestore) — ⚠ cả ba ĐỀU được hỗ trợ: ⚠ đề hỏi cái KHÔNG được hỗ trợ.

Ghi nhớ

⚠ External table trong BigQuery — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Dữ liệu nằm NGOÀI BigQuery | ⚠ Cloud Storage, Sheets, Bigtable, Cloud SQL | | ⚠ Truy vấn được bằng SQL | | | ⚠ Không tốn phí lưu trữ BigQuery | | | ⚠ CHẬM HƠN bảng gốc | ⚠ không có tối ưu lưu trữ nội bộ | | ⚠ Không cache kết quả truy vấn | | | ⚠ Khi nào dùng | ⚠ dữ liệu tạm, khám phá, hoặc dữ liệu đổi liên tục ở nơi khác |

Từ khoá nhận diện:

"truy vấn dữ liệu ở Cloud Storage bằng SQL" → ⚠ external table hoặc BigLake "Excel" → ⚠ phải chuyển sang CSV, hoặc dùng Sheets "hiệu năng tốt nhất" → ⚠ nạp hẳn vào BigQuery

⚠ External table so với nạp hẳn vào BigQuery	So sánh
⚠ External: không tốn phí lưu, không phải chép
⚠ External: chậm hơn, không phân vùng/phân cụm được như bảng gốc
⚠ Nạp hẳn: nhanh, có cache, tối ưu được
⚠ Nạp hẳn: tốn phí lưu trữ
⚠ Quy tắc	⚠ truy vấn thường xuyên thì NẠP HẲN

⚠ BigLake — bước tiến của external table	Đặc điểm
⚠ Kiểm soát truy cập cấp CỘT và DÒNG trên dữ liệu ở Cloud Storage
⚠ Người dùng không cần quyền trực tiếp trên bucket	⚠ ưu điểm bảo mật lớn
⚠ Bộ nhớ đệm siêu dữ liệu để tăng tốc
⚠ Thay thế dần	⚠ external table thông thường trong ca dùng doanh nghiệp

⚠ Nạp dữ liệu vào BigQuery — định dạng và tốc độ	Định dạng
⚠ Avro nén	⚠ nhanh nhất, đọc song song được
⚠ Parquet, ORC	⚠ tốt
⚠ CSV/JSON không nén	⚠ đọc song song được
⚠ CSV/JSON nén gzip	⚠ CHẬM NHẤT — không chia nhỏ được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | External table có bị truy vấn quá thường xuyên không | ⚠ thì nên nạp hẳn | | Người dùng có cần quyền trực tiếp trên bucket không | ⚠ BigLake tránh được | | Định dạng có cho phép đọc song song không | |

Và bẫy chi phí ẩn của external table: mỗi truy vấn đều đọc lại toàn bộ tệp. Không có phân vùng, không có cache — một bảng ngoài bị truy vấn hằng giờ sẽ đắt hơn nhiều so với việc chỉ nạp nó vào một lần.

Câu 55 Data Analysis

A data scientist is just learning to use Google Cloud for analytics. They would like to perform data quality checks and exploratory analysis on data sets stored in Cloud Storage. What Google Cloud service would you recommend they use?

A Cloud Dataflow
B Cloud Dataprep
C Cloud Dataproc
D Vertex AI

Xem giải thích

Đáp án

B — Cloud Dataprep.

Vì sao đúng

⚠ Đặc điểm người dùng trong đề: ⚠ nhà khoa học dữ liệu MỚI dùng Google Cloud, ⚠ cần ⚠ kiểm tra chất lượng và khám phá dữ liệu.

⚠ Dataprep
        ↓
⚠ Giao diện TRỰC QUAN, không cần viết mã
        ↓
⚠ Tự động hiện thống kê từng cột
   ⚠ phân bố, giá trị thiếu, giá trị lạ
        ↓
⚠ Gợi ý phép làm sạch
        ↓
⚠ Chạy nền bằng Dataflow

Đặc điểm	Vì sao hợp
⚠ Không cần lập trình	⚠ người mới dùng được ngay
⚠ Hồ sơ dữ liệu tự động	⚠ đúng nhu cầu kiểm tra chất lượng
⚠ Đọc thẳng từ Cloud Storage

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

A (Cloud Dataflow) — ⚠ phải viết mã Apache Beam: ⚠ mạnh cho đường ống sản xuất, ⚠ không phải công cụ khám phá.
C (Cloud Dataproc) — ⚠ cụm Spark/Hadoop: ⚠ phải biết Spark và quản cụm.
D (Vertex AI) — ⚠ nền tảng học máy: ⚠ có notebook để khám phá, ⚠ nhưng ⚠ không chuyên về hồ sơ chất lượng dữ liệu như Dataprep.

Ghi nhớ

⚠ Công cụ xử lý dữ liệu Google Cloud — bảng phải thuộc: | Công cụ | Dành cho | Cần biết gì | |---|---|---| | ⚠ Dataprep | ⚠ khám phá, làm sạch trực quan | ⚠ không cần mã | | ⚠ Data Fusion | ⚠ ETL kéo thả | ⚠ không cần mã | | ⚠ Dataflow | ⚠ đường ống sản xuất | ⚠ Apache Beam | | ⚠ Dataproc | ⚠ Spark/Hadoop | ⚠ Spark | | ⚠ BigQuery | ⚠ phân tích | ⚠ SQL |

Từ khoá nhận diện:

"khám phá và làm sạch, không biết lập trình" → ⚠ Dataprep "xây ETL bằng giao diện" → ⚠ Data Fusion "đường ống streaming sản xuất" → ⚠ Dataflow "đã có mã Spark" → ⚠ Dataproc

⚠ Dataprep làm được gì	Việc
⚠ Hồ sơ dữ liệu tự động	⚠ phân bố, kiểu, giá trị thiếu
⚠ Gợi ý phép biến đổi	⚠ dựa trên nội dung dữ liệu
⚠ Xem trước kết quả ngay
⚠ Xuất "recipe" thành job Dataflow	⚠ chạy lặp lại được
⚠ Lưu ý	⚠ Dataprep do Alteryx (Trifacta) cung cấp, không phải sản phẩm gốc Google

⚠ Kiểm tra chất lượng dữ liệu — nhìn gì	Nhìn gì
⚠ Tỉ lệ giá trị thiếu mỗi cột
⚠ Phân bố và giá trị ngoại lai
⚠ Số giá trị phân biệt	⚠ cột chỉ có một giá trị là vô dụng
⚠ Định dạng không nhất quán	⚠ ngày tháng viết nhiều kiểu
⚠ Bản ghi trùng lặp

⚠ Từ khám phá tới sản xuất	Lộ trình
⚠ Dataprep để hiểu dữ liệu và thử phép biến đổi
⚠ Xuất thành job Dataflow
⚠ Cloud Composer điều phối theo lịch
⚠ Ưu điểm	⚠ không phải viết lại từ đầu khi lên sản xuất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã xem hồ sơ dữ liệu trước khi viết ETL chưa | | | Có cột nào toàn giá trị thiếu không | | | Định dạng ngày tháng có nhất quán không | ⚠ nguồn lỗi phổ biến nhất |

Và bước mà mọi dự án dữ liệu nên bắt đầu nhưng hay bỏ qua: nhìn vào dữ liệu thật trước khi viết dòng mã đầu tiên. Nửa giờ xem hồ sơ dữ liệu thường tiết kiệm được cả tuần gỡ lỗi về sau.

Câu 56 Data pipelines

A team of data analysts want to run a series of jobs on large data sets. There is a complicated set of dependencies between the jobs. They want to use a managed service if possible. Which of the following would you recommend they try?

A Write Airflow directed acyclic graphs in Python and execute them with Cloud Composer.
B
Write Airflow directed acyclic graphs in SQL and execute them with Cloud Composer.
C
Write Airflow directed acyclic graphs in SQL and execute them with Cloud Workflows.
D
Write Airflow directed acyclic graphs in Python and execute them with Cloud Workflows.

Xem giải thích

Đáp án

A — Viết Airflow DAG bằng Python và chạy bằng Cloud Composer.

Vì sao đúng

⚠ Hai điểm phải khớp cùng lúc: | Điểm | Đúng là | |---|---| | ⚠ Ngôn ngữ viết DAG | ⚠ PYTHON — Airflow DAG luôn là mã Python | | ⚠ Dịch vụ chạy | ⚠ Cloud Composer — Airflow được quản |

⚠ Nhiều job, phụ thuộc phức tạp
        ↓
⚠ DAG (đồ thị có hướng không chu trình)
   ⚠ mô tả job nào chạy sau job nào
        ↓
⚠ Viết bằng Python
        ↓
⚠ Cloud Composer chạy và điều phối

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

B (DAG bằng SQL, chạy bằng Composer) — ⚠ sai ngôn ngữ: ⚠ Airflow DAG không viết bằng SQL (dù task bên trong có thể chạy SQL).
D (DAG bằng Python, chạy bằng Cloud Workflows) — ⚠ sai dịch vụ: ⚠ Cloud Workflows dùng YAML/JSON, ⚠ không chạy Airflow DAG.
C (DAG bằng SQL, chạy bằng Cloud Workflows) — ⚠ sai cả hai vế.

Ghi nhớ

⚠ Cloud Composer so với Cloud Workflows — bảng phải thuộc: | Tiêu chí | ⚠ Cloud Composer | ⚠ Cloud Workflows | |---|---|---| | ⚠ Nền tảng | ⚠ Apache Airflow | ⚠ dịch vụ riêng của Google | | ⚠ Định nghĩa bằng | ⚠ PYTHON | ⚠ YAML hoặc JSON | | ⚠ Dành cho | ⚠ đường ống DỮ LIỆU phức tạp | ⚠ điều phối API, việc nhẹ | | ⚠ Chi phí | ⚠ trả cho môi trường chạy liên tục | ⚠ trả theo BƯỚC thực thi | | ⚠ Trạng thái | ⚠ có lịch sử chạy, backfill | ⚠ đơn giản hơn |

Từ khoá nhận diện:

"nhiều job, phụ thuộc phức tạp, đường ống dữ liệu" → ⚠ Cloud Composer "gọi vài API theo thứ tự, nhẹ" → ⚠ Cloud Workflows "chạy một việc theo lịch" → ⚠ Cloud Scheduler "phản ứng với sự kiện" → ⚠ Eventarc + Cloud Functions

⚠ Khái niệm Airflow phải biết	Khái niệm
⚠ DAG	⚠ đồ thị có hướng không chu trình — toàn bộ luồng công việc
⚠ Task	⚠ một bước
⚠ Operator	⚠ loại việc: BigQueryOperator, DataflowOperator…
⚠ Sensor	⚠ chờ một điều kiện xảy ra
⚠ XCom	⚠ truyền dữ liệu nhỏ giữa các task
⚠ Backfill	⚠ chạy lại cho khoảng thời gian trong quá khứ

⚠ Vì sao Composer hợp với đường ống dữ liệu	Lý do
⚠ Có operator sẵn cho hầu hết dịch vụ Google Cloud
⚠ Thử lại, cảnh báo, SLA có sẵn
⚠ Backfill khi cần chạy lại quá khứ
⚠ Giao diện xem trạng thái từng task
⚠ Nhược điểm	⚠ môi trường chạy liên tục nên có chi phí nền

⚠ Khi nào KHÔNG cần Composer	Khi nào
⚠ Chỉ một job chạy theo lịch	⚠ Cloud Scheduler đủ
⚠ Chỉ phản ứng với sự kiện đơn giản	⚠ Cloud Functions
⚠ Điều phối vài lời gọi API	⚠ Cloud Workflows rẻ hơn nhiều
⚠ Composer đáng dùng khi	⚠ có hàng chục task với phụ thuộc thật sự

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Số job và mức độ phụ thuộc có đủ để cần Composer không | | | Task lỗi thì có cảnh báo tới ai không | | | Có cần backfill quá khứ không | ⚠ đặc trưng riêng của Airflow |

Và tiêu chí đơn giản để chọn giữa hai công cụ: Composer khi bạn cần biết chuyện gì đã chạy hôm qua và chạy lại được nó; Workflows khi bạn chỉ cần gọi vài thứ theo thứ tự.

Câu 57 Databases

A data analyst currently has the bigquery.dataViewer role and can successfully query a materialized view. They also want to be able to refresh the materialized view. You want to use a predefined role but not grant them any more permissions than needed to refresh the materialized view. What predefined role would you grant to the user?

A bigquery.dataOwner
B bigquery.admin
C bigquery.dataEditor
D bigquery.mvUpdater

Xem giải thích

Đáp án

C — bigquery.dataEditor.

Vì sao đúng

⚠ Làm mới materialized view là thao tác GHI DỮ LIỆU:

⚠ dataViewer → ⚠ chỉ ĐỌC
        ↓ ⚠ không làm mới được
⚠ dataEditor → ⚠ đọc + GHI
        ↓
⚠ Làm mới materialized view được

⚠ Vì sao dataEditor là lựa chọn tối thiểu: ⚠ hai phương án còn lại (dataOwner, admin) ⚠ rộng quyền hơn nhiều.

Vai trò	Quyền
⚠ `dataViewer`	⚠ đọc dữ liệu và siêu dữ liệu
⚠ `dataEditor`	⚠ thêm đọc + GHI, tạo/sửa/xoá bảng — ĐỦ và tối thiểu
⚠ `dataOwner`	⚠ thêm quyền quản IAM của dataset
⚠ `admin`	⚠ toàn quyền BigQuery của project

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

A (dataOwner) — ⚠ thừa quyền: ⚠ thêm khả năng đổi phân quyền của dataset.
B (admin) — ⚠ thừa quyền RẤT nhiều: ⚠ toàn quyền trên mọi dataset và job.
D (bigquery.mvUpdater) — ⚠ vai trò KHÔNG TỒN TẠI: ⚠ tên bịa.

Ghi nhớ

⚠ Vai trò BigQuery predefined — bảng phải thuộc: | Vai trò | Cho phép | |---|---| | ⚠ bigquery.dataViewer | ⚠ đọc dữ liệu | | ⚠ bigquery.dataEditor | ⚠ đọc + ghi + tạo/xoá bảng | | ⚠ bigquery.dataOwner | ⚠ thêm quản IAM của dataset | | ⚠ bigquery.jobUser | ⚠ CHẠY truy vấn và job | | ⚠ bigquery.user | ⚠ jobUser + tạo dataset | | ⚠ bigquery.admin | ⚠ toàn quyền |

Từ khoá nhận diện:

"chỉ đọc dữ liệu" → ⚠ dataViewer "ghi dữ liệu, làm mới view" → ⚠ dataEditor "chạy truy vấn" → ⚠ jobUser — bổ sung cho dataViewer "quản quyền của dataset" → ⚠ dataOwner

⚠ Bẫy kinh điển: dataViewer mà không chạy được truy vấn	Bẫy
⚠ `dataViewer` cho quyền ĐỌC BẢNG
⚠ Nhưng chạy truy vấn là tạo một JOB
⚠ Tạo job cần `bigquery.jobUser`
⚠ Kết quả	⚠ có dataViewer mà vẫn báo lỗi quyền khi bấm Run
⚠ Cấp đúng	⚠ dataViewer (trên dataset) + jobUser (trên project)

⚠ Hai cấp cấp quyền trong BigQuery	Cấp
⚠ Cấp PROJECT	⚠ jobUser, user, admin
⚠ Cấp DATASET	⚠ dataViewer, dataEditor, dataOwner
⚠ Cấp BẢNG hoặc VIEW	⚠ cũng cấp được, hẹp nhất
⚠ Cấp CỘT	⚠ policy tag
⚠ Cấp DÒNG	⚠ row-level security

⚠ Materialized view — quyền và chi phí	Chi tiết
⚠ Tự động làm mới theo mặc định	⚠ không cần ai bấm
⚠ Làm mới thủ công cần quyền ghi	⚠ đề này
⚠ Chi phí: dung lượng lưu + mỗi lần làm mới
⚠ Đặt `max_staleness` để giảm tần suất làm mới

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng có jobUser chưa | ⚠ lỗi phổ biến nhất khi cấp quyền BigQuery | | Quyền cấp ở cấp dataset hay project | | | Có ai đang giữ bigquery.admin không cần thiết không | |

Và lỗi cấp quyền BigQuery mà gần như ai cũng gặp một lần: cấp dataViewer rồi ngạc nhiên vì người dùng vẫn không chạy được truy vấn. Đọc bảng và chạy job là hai quyền tách rời, và không có gì gợi ý điều đó trong tên vai trò.

Câu 58 Databases

A financial services company is using a single Bigtable cluster to store data about equity prices. There is a large volume of write operations during the trading day. There are also analytic batch jobs that run through the day. You have been hired to help optimize the performance of Bigtable. What would you recommend they do?

A Isolate the write and batch workloads by adding a second cluster to the Bigtable instance and create two app profiles, one for write traffic and one for batch jobs.
B Continue to write data to Bigtable but create a Cloud Dataflow job to copy data to a Cloud Spanner data warehouse for batch operations.
C Continue to write data to Bigtable but create a Cloud Dataflow job to copy data to a Cloud Firestore data warehouse for batch operations.
D Isolate the write and batch workloads by adding a second set of tables to the Bigtable instance and write the data needed by batch jobs to the second set of tables.

Xem giải thích

Đáp án

A — Tách tải ghi và tải batch bằng cách thêm cụm thứ hai vào instance Bigtable, rồi tạo hai app profile: một cho lưu lượng ghi, một cho job batch.

Vì sao đúng

⚠ Vấn đề: ghi thời gian thực và job phân tích tranh nhau tài nguyên của cùng một cụm.

⚠ Một cụm duy nhất
   ⚠ ghi giá cổ phiếu liên tục
   ⚠ + job batch quét khối lượng lớn
        ↓
⚠ Batch làm chậm ghi, ghi làm chậm batch
        ↓ ⚠ Thêm cụm thứ hai
⚠ Cụm A: chỉ nhận ghi
⚠ Cụm B: chỉ chạy batch
   ⚠ (nhân bản tự động giữa hai cụm)
        ↓
⚠ App profile định tuyến từng loại
   lưu lượng tới đúng cụm

⚠ Đây là mẫu "cách ly tải" (workload isolation) chính thức của Bigtable.

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

D (thêm bộ bảng thứ hai trong cùng instance) — ⚠ vẫn chung một cụm: ⚠ bảng khác nhau ⚠ vẫn dùng chung CPU và đĩa của cùng node; ⚠ không tách được tải.
B (chép sang Cloud Spanner cho batch) — ⚠ Spanner không phải kho phân tích: ⚠ đắt và sai mục đích; ⚠ nếu muốn chép đi thì đích đúng là BigQuery.
C (chép sang Cloud Firestore cho batch) — ⚠ Firestore là CSDL tài liệu cho ứng dụng: ⚠ càng không hợp cho batch phân tích.

Ghi nhớ

⚠ Nhân bản và app profile của Bigtable — bảng phải thuộc: | Khái niệm | Nội dung | |---|---| | ⚠ Instance | ⚠ chứa một hoặc nhiều CỤM | | ⚠ Cụm (cluster) | ⚠ tập node ở một zone | | ⚠ Nhân bản | ⚠ TỰ ĐỘNG giữa các cụm, nhất quán CUỐI CÙNG | | ⚠ App profile | ⚠ quy tắc định tuyến lưu lượng tới cụm nào | | ⚠ Single-cluster routing | ⚠ gửi tới đúng một cụm — cách ly tải | | ⚠ Multi-cluster routing | ⚠ tự chuyển sang cụm khác khi có sự cố — độ sẵn sàng |

Từ khoá nhận diện:

"tải ghi và tải phân tích tranh nhau" → ⚠ thêm cụm + app profile riêng "cần độ sẵn sàng cao" → ⚠ multi-cluster routing "cần phân tích SQL trên dữ liệu Bigtable" → ⚠ xuất sang BigQuery hoặc external table

⚠ Hai kiểu định tuyến app profile	Kiểu
⚠ Single-cluster	⚠ nhất quán ĐỌC-SAU-GHI trong cụm đó, cách ly tải
⚠ Multi-cluster	⚠ tự chuyển cụm khi hỏng, nhưng có thể đọc dữ liệu cũ
⚠ Đề này	⚠ single-cluster cho từng loại tải
⚠ Lưu ý	⚠ nhân bản là nhất quán CUỐI CÙNG — batch có thể thấy dữ liệu trễ vài giây

⚠ Vì sao tách tải quan trọng	Lý do
⚠ Batch quét lớn làm đầy cache của node
⚠ Độ trễ ghi tăng vọt lúc batch chạy
⚠ Khó điều chỉnh số node cho hai loại tải khác nhau
⚠ Sau khi tách	⚠ mỗi cụm co giãn độc lập theo tải riêng

⚠ Chi phí của việc thêm cụm	Chi phí
⚠ Trả tiền cho node của CẢ HAI cụm
⚠ Tốn thêm dung lượng lưu trữ (dữ liệu nhân bản)
⚠ Có phí truyền dữ liệu giữa các vùng nếu khác vùng
⚠ Đổi lại	⚠ hiệu năng ổn định và có thêm dự phòng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ ghi có tăng lúc batch chạy không | | | App profile đã tách chưa | ⚠ mặc định là một profile dùng chung | | Batch có chịu được dữ liệu trễ vài giây không | |

Và điều làm mẫu này mạnh hơn vẻ ngoài: cụm thứ hai vừa cách ly tải vừa là bản dự phòng. Bạn trả tiền cho hiệu năng và nhận thêm khả năng chịu lỗi mà không phải thiết kế gì thêm.

Câu 59 Machine Learning

A team of data analysts are proficient in using SQL but not programming in Java, Python, or other programming languages. They want to experiment with building machine learning models trained on relational data. They have approximately 1 TB of data to work with. What would you recommend they use?

A Bigtable
B Cloud TPUs
C BigQuery ML
D Cloud Fusion

Xem giải thích

Đáp án

C — BigQuery ML.

Vì sao đúng

⚠ Ba dữ kiện của đề, cả ba đều chỉ về BigQuery ML: | Dữ kiện | BigQuery ML | |---|---| | ⚠ Thành thạo SQL, KHÔNG biết Java/Python | ⚠ huấn luyện mô hình bằng SQL thuần | | ⚠ Dữ liệu QUAN HỆ | ⚠ BigQuery là kho quan hệ | | ⚠ Khoảng 1 TB | ⚠ BigQuery xử lý thoải mái |

CREATE MODEL `duan.mohinh_du_bao`
OPTIONS(model_type='linear_reg') AS
SELECT dac_trung_1, dac_trung_2, nhan
FROM `duan.du_lieu_huan_luyen`;

⚠ Không phải xuất dữ liệu đi đâu cả — ⚠ mô hình huấn luyện ngay tại chỗ dữ liệu đang nằm.

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

B (Cloud TPU) — ⚠ là PHẦN CỨNG tăng tốc: ⚠ vẫn phải viết mã TensorFlow bằng Python.
A (Bigtable) — ⚠ CSDL NoSQL, không có khả năng học máy.
D (Cloud Data Fusion) — ⚠ công cụ ETL kéo thả: ⚠ để chuẩn bị dữ liệu, ⚠ không huấn luyện mô hình.

Ghi nhớ

⚠ Chọn công cụ ML theo kỹ năng đội — bảng phải thuộc: | Đội biết gì | Công cụ | |---|---| | ⚠ Chỉ SQL | ⚠ BigQuery ML | | ⚠ Không biết gì về ML, muốn nhanh | ⚠ AutoML | | ⚠ Python + framework ML | ⚠ Vertex AI custom training | | ⚠ Chỉ cần gọi API | ⚠ Vision, Natural Language, Speech API |

Từ khoá nhận diện:

"biết SQL, dữ liệu ở BigQuery" → ⚠ BigQuery ML "tự tinh chỉnh siêu tham số" → ⚠ Vertex AI custom training "không có chuyên gia ML" → ⚠ AutoML

⚠ Loại mô hình BigQuery ML hỗ trợ	Loại
⚠ `linear_reg`	⚠ hồi quy — dự đoán số
⚠ `logistic_reg`	⚠ phân loại
⚠ `kmeans`	⚠ phân cụm
⚠ `arima_plus`	⚠ dự báo chuỗi thời gian
⚠ `matrix_factorization`	⚠ hệ gợi ý
⚠ `boosted_tree`, `dnn`, `automl`
⚠ Nhập mô hình TensorFlow	⚠ dùng mô hình huấn luyện bên ngoài

⚠ Ưu điểm lớn nhất của BigQuery ML	Ưu điểm
⚠ Dữ liệu KHÔNG rời khỏi BigQuery	⚠ không phải xuất, không phải lo bảo mật khi di chuyển
⚠ Không cần dựng hạ tầng
⚠ Dự đoán bằng `ML.PREDICT` — cũng là SQL
⚠ Đánh giá bằng `ML.EVALUATE`
⚠ Rào cản thấp	⚠ nhà phân tích tự làm được, không cần chờ đội ML

⚠ Hạn chế của BigQuery ML	Hạn chế
⚠ Ít kiểm soát chi tiết quá trình huấn luyện
⚠ Không hợp với mô hình rất phức tạp	⚠ thị giác, ngôn ngữ lớn
⚠ Chi phí huấn luyện tính theo dữ liệu xử lý
⚠ Khi cần hơn	⚠ chuyển sang Vertex AI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu đã ở BigQuery chưa | ⚠ nếu chưa thì phải cân nhắc chi phí nạp | | Bài toán có thuộc loại BigQuery ML hỗ trợ không | | | Đã đánh giá mô hình trên tập kiểm tra riêng chưa | |

Và giá trị lớn nhất mà BigQuery ML mang lại cho một tổ chức: nó rút ngắn khoảng cách giữa người hiểu dữ liệu và người xây mô hình. Rất thường xuyên, hai người đó nên là một.

Câu 60 Databases

As a database administrator, you are finding that a Cloud SQL database using PostgreSQL is not meeting read operation SLAs. You want to improve performance with minimal changes to database applications. What would you try first to improve read performance?

A
Create a read replica.
B
Use Cloud Memorystore to cache data to be read.
C Use change data capture to keep a second database in a different region in synch with the primary database while having read operations sent to the secondary database.
D Use PostgreSQL's explain plan feature to analyze queries and rewrite them to improve performance.

Xem giải thích

Đáp án

A — Tạo read replica (bản sao chỉ đọc).

Vì sao đúng

⚠ Đề nhấn "thay đổi ứng dụng ÍT NHẤT": | Cách | Mức thay đổi | |---|---| | ⚠ Read replica | ⚠ chỉ đổi chuỗi kết nối cho truy vấn đọc | | ⚠ Memorystore | ⚠ phải viết lại logic đọc, quản lý cache | | ⚠ Viết lại truy vấn | ⚠ sửa nhiều mã, tốn thời gian phân tích |

⚠ Cloud SQL primary
   ⚠ nhận GHI
        ↓ ⚠ nhân bản
⚠ Read replica
   ⚠ nhận ĐỌC
        ↓
⚠ Tải đọc rời khỏi primary
   → ⚠ cả hai đều nhanh hơn

⚠ Tạo replica chỉ bằng vài thao tác, ⚠ Cloud SQL lo toàn bộ việc nhân bản.

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

D (dùng explain plan để phân tích và viết lại truy vấn) — ⚠ thường là việc ĐÚNG về lâu dài ⚠ nhưng ⚠ tốn nhiều công sửa ứng dụng; ⚠ đề yêu cầu thử ĐẦU TIÊN với ít thay đổi nhất.
B (dùng Memorystore làm cache) — ⚠ hiệu quả nhưng đòi viết lại mã: ⚠ phải quyết định cache cái gì, ⚠ khi nào làm mới, ⚠ xử lý cache cũ.
C (dùng change data capture đồng bộ CSDL thứ hai ở vùng khác) — ⚠ tự dựng lại chính tính năng read replica: ⚠ phức tạp hơn nhiều mà không hơn gì.

Ghi nhớ

⚠ Read replica của Cloud SQL — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ CHỈ đọc | ⚠ không ghi được vào replica | | ⚠ Nhất quán CUỐI CÙNG | ⚠ có độ trễ nhân bản (replica lag) | | ⚠ Đặt được ở vùng khác | ⚠ cross-region replica | | ⚠ Nhiều replica cùng lúc | | | ⚠ Nâng cấp thành primary được | ⚠ dùng cho khôi phục thảm hoạ | | ⚠ KHÔNG phải HA | ⚠ HA dùng cấu hình regional với standby tự chuyển |

Từ khoá nhận diện:

"đọc chậm, ít thay đổi nhất" → ⚠ read replica "cần đọc dữ liệu MỚI NHẤT tuyệt đối" → ⚠ phải đọc từ primary "tự động chuyển khi primary hỏng" → ⚠ cấu hình HA, không phải read replica "cache dữ liệu nóng" → ⚠ Memorystore

⚠ Read replica so với HA — hay bị lẫn	Phân biệt
⚠ Read replica: MỞ RỘNG khả năng đọc	⚠ không tự chuyển khi hỏng
⚠ HA (regional): DỰ PHÒNG, tự chuyển	⚠ standby KHÔNG phục vụ đọc
⚠ Cần cả hai	⚠ thì bật cả hai — chúng độc lập

⚠ Bẫy của read replica	Bẫy
⚠ Replica lag	⚠ đọc có thể thấy dữ liệu cũ vài giây
⚠ Ứng dụng ghi rồi đọc ngay có thể không thấy	⚠ read-after-write
⚠ Truy vấn nặng trên replica làm lag tăng
⚠ Cách xử lý	⚠ thao tác cần nhất quán tuyệt đối thì đọc từ primary

⚠ Thứ tự tối ưu hiệu năng CSDL	Thứ tự
⚠ 1. Thêm INDEX đúng	⚠ thường hiệu quả nhất, rẻ nhất
⚠ 2. Read replica cho tải đọc
⚠ 3. Cache tầng ứng dụng
⚠ 4. Viết lại truy vấn xấu
⚠ 5. Nâng cấp máy	⚠ đắt nhất, hiệu quả tạm thời

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn chậm có thiếu index không | ⚠ kiểm tra trước tiên | | Replica lag là bao nhiêu | | | Ứng dụng có chỗ nào ghi rồi đọc ngay không | |

Và điều nên kiểm tra trước cả read replica: truy vấn chậm có thiếu index không. Một index đúng chỗ thường cải thiện nhiều hơn cả một máy chủ mới, và không tốn thêm đồng nào mỗi thá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ớ