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

Đáp án

B — subscription/num_undelivered_messages.

Vì sao đúng

⚠ Đề hỏi: làm sao biết ứng dụng đọc từ pull subscription ⚠ không theo kịp lượng tin nhắn được đưa vào.

⚠ Publisher đẩy tin nhắn vào topic
        ↓
⚠ Subscription giữ tin chưa được xử lý
        ↓
⚠ Subscriber đọc và xác nhận (ack)
        ↓
⚠ Đọc CHẬM hơn đẩy vào
   → ⚠ num_undelivered_messages TĂNG DẦN

⚠ Hai chỉ số cốt lõi cho tồn đọng Pub/Sub: | Chỉ số | Ý nghĩa | |---|---| | ⚠ subscription/num_undelivered_messages | ⚠ SỐ LƯỢNG tin chưa xử lý — đề này | | ⚠ subscription/oldest_unacked_message_age | ⚠ TUỔI của tin cũ nhất chưa xử lý | | ⚠ Nên theo dõi cả hai | ⚠ số lượng cho quy mô, tuổi cho độ trễ |

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

• D (topic/num_undelivered_messages) — ⚠ sai cấp tài nguyên: ⚠ tồn đọng thuộc về SUBSCRIPTION, không phải topic; ⚠ một topic có nhiều subscription, ⚠ mỗi cái tồn đọng khác nhau.

• A (topic/excess_ingestion_volume) và C (subscription/excess_ingestion_volume) — ⚠ hai chỉ số này KHÔNG tồn tại trong Pub/Sub.

Ghi nhớ

⚠ Cấp tài nguyên của chỉ số Pub/Sub — bảng phải thuộc: | Cấp | Chỉ số | |---|---| | ⚠ Topic | ⚠ send_message_operation_count, send_request_count | | ⚠ Subscription | ⚠ num_undelivered_messages, oldest_unacked_message_age, pull_request_count | | ⚠ Quy tắc | ⚠ mọi thứ liên quan tới TIÊU THỤ đều ở cấp subscription |

Từ khoá nhận diện:

"consumer không theo kịp" → ⚠ subscription/num_undelivered_messages "tin nhắn bị chậm bao lâu" → ⚠ subscription/oldest_unacked_message_age "tin nhắn bị xử lý lỗi nhiều lần" → ⚠ dead-letter topic

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cảnh báo trên tuổi tin cũ nhất chưa | | | Ack deadline có đủ cho thời gian xử lý thật không | | | Đã cấu hình dead-letter topic chưa | ⚠ tránh tin lỗi lặp mãi |

Và nguyên nhân phổ biến nhất của tồn đọng Pub/Sub mà nhìn biểu đồ không thấy ngay: ack deadline ngắn hơn thời gian xử lý thật. Tin nhắn được giao đi giao lại, subscriber làm việc liên tục, mà hàng chờ thì không bao giờ vơi.

Đáp án

A — Thực hiện đánh giá chất lượng dữ liệu trên dữ liệu nguồn SAU KHI trích xuất khỏi hệ thống nguồn: kiểm tra khoảng giá trị của từng thuộc tính, phân bố giá trị, đếm số giá trị không hợp lệ và bị thiếu, cùng các kiểm tra khác.

Vì sao đúng

⚠ Đề hỏi chính xác: làm sao hiểu được QUY MÔ của vấn đề ⚠ TRƯỚC KHI bắt đầu viết mã ETL.

⚠ Trích xuất dữ liệu ra
        ↓
⚠ ĐO chất lượng thật sự
   ⚠ khoảng giá trị
   ⚠ phân bố
   ⚠ số giá trị thiếu, không hợp lệ
        ↓
⚠ BIẾT phải xử lý những gì
        ↓
⚠ Mới viết ETL cho đúng

⚠ Vì sao phải làm SAU khi trích xuất: ⚠ chỉ khi dữ liệu đã ra khỏi hệ thống nguồn thì ⚠ mới đo được cái sẽ thật sự đi vào kho.

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

• D (nạp vào kho rồi ghi log những bản ghi không đạt) — ⚠ ngược yêu cầu của đề: ⚠ đề nói rõ KHÔNG muốn đưa dữ liệu sai vào kho; ⚠ và ⚠ phải viết ETL xong mới biết vấn đề.

• C (nạp mọi dữ liệu nguồn vào data lake rồi mới vào kho) — ⚠ chỉ dời chỗ chứa: ⚠ không đo gì cả, ⚠ vẫn không biết quy mô vấn đề.

• B (để quản trị viên hệ thống nguồn tự xác nhận chất lượng trước khi xuất) — ⚠ dựa vào lời hứa thay vì phép đo: ⚠ đề nói họ nghi ngờ kiểm soát chất lượng ở nguồn kém; ⚠ hỏi chính người có vấn đề là không đáng tin.

Ghi nhớ

⚠ Sáu chiều của chất lượng dữ liệu — bảng phải thuộc: | Chiều | Câu hỏi | |---|---| | ⚠ Đầy đủ (completeness) | ⚠ bao nhiêu giá trị bị thiếu | | ⚠ Hợp lệ (validity) | ⚠ có đúng định dạng, đúng khoảng không | | ⚠ Chính xác (accuracy) | ⚠ có khớp thực tế không | | ⚠ Nhất quán (consistency) | ⚠ các hệ thống có nói cùng một điều không | | ⚠ Duy nhất (uniqueness) | ⚠ có bản ghi trùng không | | ⚠ Kịp thời (timeliness) | ⚠ dữ liệu mới tới mức nào |

Từ khoá nhận diện:

"hiểu quy mô vấn đề trước khi viết ETL" → ⚠ đánh giá chất lượng dữ liệu (data profiling) "phát hiện dữ liệu nhạy cảm" → ⚠ DLP data profiling "theo dõi nguồn gốc dữ liệu" → ⚠ Data Catalog / Dataplex lineage

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Biết tỉ lệ bản ghi hỏng của từng nguồn không | | | Bản ghi bị loại đi đâu | ⚠ có ai xem lại không | | Có phát hiện được khi chất lượng nguồn xấu đi không | |

Và lý do bước đánh giá này hay bị bỏ qua: nó không tạo ra thứ gì chạy được. Nhưng viết ETL mà không biết dữ liệu thật trông thế nào là viết cho một giả định, và giả định đó gần như luôn sai.

Đáp án

A — Tạo một sole-tenant node group và chỉ định node group đó khi tạo cụm Dataproc.

Vì sao đúng

⚠ Yêu cầu pháp lý của đề: ⚠ không được chạy phân tích PII trên máy chủ vật lý DÙNG CHUNG với khách hàng khác.

⚠ Mặc định: VM của bạn chạy trên
   máy chủ vật lý CHUNG với khách khác
   (⚠ được cách ly bằng ảo hoá)
        ↓ ⚠ Sole-tenant node
⚠ CẢ máy chủ vật lý DÀNH RIÊNG
   cho project của bạn
        ↓
⚠ Không có VM của khách khác
   trên cùng phần cứng

⚠ Dataproc HỖ TRỢ sole-tenant node — ⚠ khai node group khi tạo cụm.

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

• B (Dataproc không cấu hình được sole tenant, phải tự chạy Spark trên MIG) — ⚠ khẳng định SAI: ⚠ Dataproc có hỗ trợ sole-tenant node; ⚠ tự dựng Spark là ⚠ vứt bỏ toàn bộ giá trị của dịch vụ được quản.

• C (tắt autoscaling để tránh thêm VM không phải sole tenant) — ⚠ hiểu sai cơ chế: ⚠ nếu cụm đã dùng node group thì ⚠ VM mở rộng thêm cũng nằm trên node đó; ⚠ tắt autoscaling không liên quan gì tới thuê bao riêng.

• D (tạo unmanaged instance group và chỉ định khi tạo cụm) — ⚠ không phải cơ chế của Dataproc: ⚠ và ⚠ instance group không đảm bảo phần cứng riêng.

Ghi nhớ

⚠ Sole-tenant node — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Là gì | ⚠ máy chủ vật lý dành RIÊNG cho một project | | ⚠ Giải quyết gì | ⚠ yêu cầu tuân thủ về cách ly vật lý, giấy phép theo lõi | | ⚠ Chi phí | ⚠ trả tiền cho CẢ node, dù dùng hết hay không | | ⚠ Dịch vụ hỗ trợ | ⚠ Compute Engine, GKE, Dataproc | | ⚠ Cấu hình được | ⚠ affinity label để chọn workload nào lên node nào |

Từ khoá nhận diện:

"không dùng chung phần cứng vật lý" → ⚠ sole-tenant node "giấy phép phần mềm tính theo lõi vật lý" → ⚠ sole-tenant node (bring your own license) "dữ liệu không được rời khỏi ranh giới" → ⚠ VPC Service Controls "khoá phải nằm ngoài Google" → ⚠ Cloud EKM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quy định thật sự yêu cầu cách ly gì | ⚠ vật lý hay logic | | Chi phí sole-tenant so với lợi ích | | | Có thể che PII trước khi phân tích không | ⚠ rẻ hơn nhiều so với cách ly phần cứng |

Và câu hỏi đáng đặt trước khi mua cách ly phần cứng: dữ liệu này có nhất thiết phải mang theo PII vào bước phân tích không?. Nếu che được từ đầu thì phần lớn yêu cầu tuân thủ nặng nề phía sau sẽ tự biến mất.

Đáp án

B — Entity (thực thể).

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

⚠ Thuật ngữ trong đề và trong khoá thuộc HAI chế độ khác nhau của cùng một sản phẩm.

⚠ Đề viết "Cloud Firestore document data model" nhưng ⚠ khoá dùng thuật ngữ của Datastore mode.

⚠ KHÔNG sửa khoá — ⚠ trong bốn phương án, ⚠ Entity vẫn là thứ duy nhất tương ứng với một DÒNG; ⚠ "Document" không được đưa ra.

⚠ Cách nhớ an toàn: ⚠ Document (Native) = Entity (Datastore mode) = một DÒNG.

Vì sao đúng

⚠ Ánh xạ khái niệm sang CSDL quan hệ: | Firestore/Datastore | Quan hệ | |---|---| | ⚠ Kind / Collection | ⚠ BẢNG | | ⚠ Entity / Document | ⚠ DÒNG — đề này | | ⚠ Property / Field | ⚠ CỘT | | ⚠ Key | ⚠ KHOÁ CHÍNH |

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

• D (Kinds) — ⚠ tương ứng với BẢNG, không phải dòng: ⚠ Kind là loại của thực thể.

• A (Index) — ⚠ chỉ mục để truy vấn nhanh: ⚠ có ở cả hai mô hình, ⚠ không phải đơn vị dữ liệu.

• C (Interleaved row) — ⚠ khái niệm của Cloud SPANNER, ⚠ không phải Firestore: ⚠ dùng để đặt bảng con nằm xen kẽ vật lý với bảng cha.

Ghi nhớ

⚠ Firestore hai chế độ — bảng phải thuộc: | Chế độ | Đặc điểm | |---|---| | ⚠ Native mode | ⚠ Collection/Document, đồng bộ thời gian thực, SDK di động | | ⚠ Datastore mode | ⚠ Kind/Entity, tương thích ngược với Datastore cũ | | ⚠ Phải chọn khi tạo | ⚠ KHÔNG đổi được về sau | | ⚠ Dự án mới | ⚠ Google khuyến nghị Native mode |

Từ khoá nhận diện:

"đồng bộ thời gian thực, ứng dụng di động" → ⚠ Firestore Native mode "tương thích với ứng dụng Datastore cũ" → ⚠ Datastore mode "interleaved table" → ⚠ Cloud Spanner "cột rộng, hàng nghìn cột, chuỗi thời gian" → ⚠ Bigtable

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang dùng chế độ nào | ⚠ quyết định thuật ngữ và API | | Truy vấn có index tổng hợp cần thiết chưa | | | Quy tắc bảo mật có chặt không | ⚠ mặc định của môi trường thử là mở toang |

Và cái bẫy hay gặp nhất với Firestore: quy tắc bảo mật để ở chế độ thử nghiệm rồi quên đổi. Chế độ đó cho phép mọi người đọc và ghi toàn bộ cơ sở dữ liệu, và nó hết hạn im lặng sau 30 ngày.

Đáp án

B và D — Tổng dung lượng dữ liệu lưu trong materialized view, và tần suất làm mới materialized view.

Vì sao đúng

⚠ Materialized view khác view thường ở chỗ nó LƯU THẬT dữ liệu:

⚠ View thường
   → ⚠ chỉ là câu truy vấn được đặt tên
   → ⚠ KHÔNG tốn dung lượng

⚠ Materialized view
   → ⚠ LƯU kết quả đã tính sẵn
   → ⚠ tốn phí LƯU TRỮ (B)
   → ⚠ tự LÀM MỚI khi bảng gốc đổi
   → ⚠ mỗi lần làm mới là một lần
     XỬ LÝ, tốn phí (D)

⚠ Bảng gốc thay đổi càng thường xuyên → làm mới càng nhiều → chi phí càng cao.

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

• A (kiểu dữ liệu dùng trong materialized view) — ⚠ ảnh hưởng gián tiếp và rất nhỏ: ⚠ kiểu dữ liệu quyết định số byte mỗi giá trị, ⚠ nhưng đó đã được tính vào tổng dung lượng ở phương án B.

• C (số người dùng có quyền đọc view) — ⚠ BigQuery KHÔNG tính phí theo số người dùng: ⚠ tính theo dữ liệu quét khi truy vấn và dung lượng lưu.

Ghi nhớ

⚠ Mô hình chi phí BigQuery — bảng phải thuộc: | Loại phí | Tính theo | |---|---| | ⚠ Lưu trữ active | ⚠ GB/tháng, bảng có sửa trong 90 ngày | | ⚠ Lưu trữ long-term | ⚠ rẻ hơn ~50%, không sửa 90 ngày — TỰ ĐỘNG | | ⚠ Truy vấn on-demand | ⚠ theo TB DỮ LIỆU QUÉT | | ⚠ Truy vấn capacity (slot) | ⚠ theo slot đã đặt trước | | ⚠ Streaming insert | ⚠ theo số byte nạp vào | | ⚠ KHÔNG tính theo | ⚠ số người dùng, số truy vấn |

Từ khoá nhận diện:

"chi phí materialized view" → ⚠ dung lượng lưu + tần suất làm mới "giảm dữ liệu quét" → ⚠ phân vùng (partition) và phân cụm (cluster) "chi phí ổn định, dự đoán được" → ⚠ mua slot (capacity pricing)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng gốc thay đổi bao nhiêu lần mỗi ngày | ⚠ quyết định phí làm mới | | Materialized view có thật sự được dùng không | ⚠ xem thống kê truy vấn | | Bảng đã phân vùng chưa | ⚠ hiệu quả hơn materialized view trong nhiều trường hợp |

Và nghịch lý của materialized view: nó tiết kiệm nhất khi dữ liệu ít thay đổi, mà dữ liệu ít thay đổi thì thường cũng không cần tối ưu gấp. Trước khi tạo một cái, hãy đo xem truy vấn đó thật sự chạy bao nhiêu lần.

Đáp án

B — Tạo một vai trò tuỳ chỉnh (custom role) chỉ chứa đúng những quyền cần thiết. Đây là nguyên tắc quyền tối thiểu.

Vì sao đúng

⚠ Tình huống của đề:

⚠ Người bảo trì cần quyền từ BA vai trò
⚠ Nhưng ba vai trò đó chứa NHIỀU quyền
   họ KHÔNG cần
        ↓
⚠ Gán cả ba = ⚠ cấp thừa quyền
        ↓
⚠ Vai trò TUỲ CHỈNH:
   ⚠ lấy đúng những quyền cần
   ⚠ bỏ phần thừa

⚠ Đây chính là lúc vai trò tuỳ chỉnh được sinh ra để dùng — ⚠ khi vai trò định sẵn quá rộng.

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

• C (gán cả ba vai trò có sẵn để đỡ phải quản lý) — ⚠ đánh đổi sai hướng: ⚠ tiện cho quản trị viên nhưng ⚠ vi phạm quyền tối thiểu; ⚠ đề nói rõ ba vai trò đó có quyền thừa.

• A (gán vai trò Owner cho gọn) — ⚠ tệ nhất trong bốn phương án: ⚠ Owner có toàn quyền, ⚠ kể cả xoá project và đổi thanh toán.

• D (tạo "custom group" chứa mọi quyền của ba vai trò, theo nguyên tắc quyền TỐI ĐA) — ⚠ hai lỗi: ⚠ không có khái niệm "nguyên tắc quyền tối đa" (đó là chữ bịa); ⚠ và ⚠ group là để gom NGƯỜI, không phải để gom quyền.

Ghi nhớ

⚠ Ba loại vai trò IAM — bảng phải thuộc: | Loại | Đặc điểm | |---|---| | ⚠ Basic (Owner, Editor, Viewer) | ⚠ quá rộng, TRÁNH dùng ở production | | ⚠ Predefined | ⚠ Google định nghĩa theo từng dịch vụ, tự cập nhật | | ⚠ Custom | ⚠ tự chọn từng quyền — dùng khi predefined quá rộng | | ⚠ Thứ tự ưu tiên | ⚠ predefined trước, custom khi cần thiết |

Từ khoá nhận diện:

"vai trò có sẵn chứa quyền thừa" → ⚠ vai trò tuỳ chỉnh "đỡ phải quản lý nên gán Owner" → ⚠ LUÔN SAI "gom nhiều người có cùng quyền" → ⚠ Google Group "cấp quyền tạm thời, có thời hạn" → ⚠ IAM Conditions

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ai đang giữ vai trò Owner không cần thiết không | | | IAM Recommender đang gợi ý gỡ những gì | | | Vai trò tuỳ chỉnh có được rà lại khi dịch vụ cập nhật không | |

Và hiện tượng xảy ra ở mọi tổ chức nếu không ai chủ động ngăn: quyền chỉ đi lên, không bao giờ đi xuống. Mỗi lần ai đó bị chặn, người ta cấp thêm quyền — và không ai quay lại gỡ nó ra.

Đáp án

A — gcloud dataflow sql query.

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

⚠ Dataflow SQL đã bị Google NGỪNG cung cấp.

⚠ KHÔNG sửa khoá đáp án — ⚠ theo quy ước, ⚠ câu nhắc dịch vụ đã ngừng chỉ được ghi chú, ⚠ kể cả khi dịch vụ đó nằm trong chính đáp án đúng.

⚠ Vẫn học được gì từ câu này: ⚠ quy tắc đặt tên lệnh của gcloud và bq.

Vì sao đúng (theo bối cảnh đề)

⚠ Cấu trúc lệnh của Google Cloud CLI:

gcloud <dịch vụ> <nhóm> <lệnh>
   ↓
gcloud dataflow sql query
   ⚠ dịch vụ: dataflow
   ⚠ nhóm:    sql
   ⚠ lệnh:    query

⚠ Chạy trên Dataflow → ⚠ dùng gcloud, ⚠ dịch vụ là dataflow.

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

• B (bq dataflow sql query) — ⚠ bq là CLI RIÊNG của BigQuery: ⚠ nó không điều khiển Dataflow.

• C (gcloud bigquery sql query) — ⚠ gcloud không có nhóm lệnh bigquery kiểu này: ⚠ và ⚠ đề yêu cầu chạy trên Dataflow.

• D (bq bigquery sql query) — ⚠ thừa và sai: ⚠ bq đã là BigQuery rồi, ⚠ lệnh truy vấn là bq query.

Ghi nhớ

⚠ Các CLI của Google Cloud — bảng phải thuộc: | CLI | Dùng cho | |---|---| | ⚠ gcloud | ⚠ phần lớn dịch vụ: compute, dataflow, iam, run… | | ⚠ bq | ⚠ RIÊNG BigQuery | | ⚠ gsutil / gcloud storage | ⚠ Cloud Storage | | ⚠ kubectl | ⚠ Kubernetes/GKE | | ⚠ Xu hướng | ⚠ gcloud storage đang thay dần gsutil |

Từ khoá nhận diện:

"chạy job trên Dataflow" → ⚠ gcloud dataflow ... "truy vấn BigQuery từ dòng lệnh" → ⚠ bq query "tải tệp lên bucket" → ⚠ gcloud storage cp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lệnh trong tài liệu có còn tồn tại không | ⚠ gcloud <dịch vụ> --help | | Dịch vụ đang dùng có bị đánh dấu deprecated không | | | Có đường thay thế nào Google khuyến nghị không | |

Và điều cần giữ khi ôn thi bằng ngân hàng đề cũ: nhớ đáp án để qua kỳ thi, nhớ thực tế để làm việc. Hai thứ đó không phải lúc nào cũng trùng nhau, và biết chỗ chúng lệch nhau chính là dấu hiệu bạn hiểu thật.

Đáp án

D — Dùng thêm dữ liệu huấn luyện (more training instances).

Vì sao đúng

⚠ Chìa khoá: CẢ HAI chỉ số đều thấp.

⚠ Cả precision và recall thấp
        ↓
⚠ Không phải chuyện cân bằng ngưỡng
        ↓
⚠ Mô hình chưa học được quy luật
        ↓
⚠ Thêm DỮ LIỆU là cách trực tiếp nhất

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

• A (L1 regularization) và B (L2 regularization) — ⚠ chữa QUÁ KHỚP (overfitting): ⚠ chúng làm mô hình đơn giản hơn; ⚠ mô hình đang học kém mà lại ép đơn giản hơn nữa thì ⚠ càng tệ.

• C (dropout) — ⚠ cũng là kỹ thuật chống quá khớp: ⚠ tắt ngẫu nhiên một phần nơ-ron khi huấn luyện; ⚠ cùng vấn đề với A và B.

Ghi nhớ

⚠ Precision và recall — công thức phải thuộc: | Chỉ số | Công thức | Trả lời câu hỏi | |---|---|---| | ⚠ Precision | ⚠ TP / (TP + FP) | ⚠ những cái ta báo dương, bao nhiêu đúng | | ⚠ Recall | ⚠ TP / (TP + FN) | ⚠ những cái thật sự dương, ta bắt được bao nhiêu | | ⚠ F1 | ⚠ trung bình điều hoà của hai cái | ⚠ cân bằng cả hai |

Từ khoá nhận diện:

"cả precision và recall đều thấp" → ⚠ thiếu dữ liệu / thiếu đặc trưng — chưa khớp (underfitting) "tốt trên tập huấn luyện, tệ trên tập kiểm tra" → ⚠ quá khớp → regularization, dropout "tệ trên CẢ HAI tập" → ⚠ chưa khớp → thêm dữ liệu, mô hình phức tạp hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số trên tập train so với tập test thế nào | ⚠ phân biệt chưa khớp và quá khớp | | Dữ liệu có mất cân bằng lớp không | | | Có bao nhiêu mẫu cho lớp thiểu số | ⚠ thường là nút thắt thật |

Và bước chẩn đoán đầu tiên cho mọi mô hình chạy kém: so sánh chỉ số trên tập huấn luyện với tập kiểm tra. Hai con số đó quyết định bạn cần thêm dữ liệu hay cần bớt độ phức tạp — làm ngược là mất hàng tuần.

Đáp án

D — Cloud CDN.

Vì sao đúng

⚠ Đề nêu: người dùng khắp thế giới phải có trải nghiệm như nhau khi xem video các trận đã phát.

⚠ Video ĐÃ PHÁT = nội dung TĨNH,
   không đổi
        ↓
⚠ Cloud CDN lưu bản sao ở
   BIÊN MẠNG gần người dùng
        ↓
⚠ Người ở Ấn Độ, Anh, Úc
   đều lấy từ điểm gần mình
        ↓
⚠ Độ trễ thấp và ĐỒNG ĐỀU

⚠ Từ khoá quyết định: ⚠ "regardless of where they are located" — ⚠ đó là bài toán của CDN, ⚠ không phải bài toán lưu trữ.

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

• A (Cloud Storage multi-region) — ⚠ bẫy gần nhất: ⚠ multi-region cải thiện độ bền và độ sẵn sàng, ⚠ nhưng ⚠ không đưa nội dung tới gần người dùng cuối như CDN; ⚠ thường dùng CÙNG với CDN làm nguồn gốc.

• C (Cloud Storage lớp Nearline) — ⚠ sai hẳn mục đích: ⚠ Nearline cho dữ liệu ít truy cập; ⚠ có phí lấy dữ liệu, ⚠ dùng cho video xem thường xuyên là ⚠ đắt và chậm.

• B (Cloud Firestore) — ⚠ CSDL tài liệu: ⚠ không phải nơi phân phối video.

Ghi nhớ

⚠ Đưa nội dung tới gần người dùng — bảng phải thuộc: | Nhu cầu | Dịch vụ | |---|---| | ⚠ Nội dung TĨNH tới toàn cầu | ⚠ Cloud CDN — đề này | | ⚠ Kho chứa nội dung gốc | ⚠ Cloud Storage | | ⚠ Định tuyến người dùng tới vùng gần nhất | ⚠ Global HTTP(S) Load Balancer | | ⚠ Livestream | ⚠ CDN + giao thức phát trực tiếp, khác bài toán này |

Từ khoá nhận diện:

"trải nghiệm như nhau bất kể ở đâu" → ⚠ Cloud CDN "độ bền dữ liệu qua nhiều vùng" → ⚠ Cloud Storage multi-region "dữ liệu ít khi đọc, lưu lâu" → ⚠ Nearline / Coldline / Archive

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỉ lệ cache hit là bao nhiêu | ⚠ thấp là cấu hình header sai | | Có nội dung riêng tư nào bị cache không | | | Nội dung cập nhật thì người dùng thấy sau bao lâu | |

Và chỉ số nói lên nhiều nhất về một triển khai CDN: tỉ lệ cache hit. Nếu nó thấp, bạn đang trả tiền cho một lớp trung gian mà vẫn phục vụ mọi request từ nguồn gốc.

Đáp án

B — Mô hình tài liệu (document model).

Vì sao đúng

⚠ Vấn đề của đề: lược đồ phải đổi liên tục để hỗ trợ tính năng và loại vật phẩm mới.

⚠ CSDL chuẩn hoá (quan hệ)
   → ⚠ mỗi loại vật phẩm mới
     = ⚠ thêm bảng, thêm cột
   → ⚠ ALTER TABLE trên bảng lớn
   → ⚠ khó bảo trì
        ↓
⚠ Mô hình TÀI LIỆU
   → ⚠ mỗi vật phẩm là một tài liệu
   → ⚠ trường khác nhau tuỳ loại
   → ⚠ KHÔNG cần đổi lược đồ

⚠ Trên Google Cloud: ⚠ Firestore là CSDL tài liệu.

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

• A (star schema) và D (snowflake schema) — ⚠ đều là lược đồ của KHO DỮ LIỆU phân tích: ⚠ thiết kế cho truy vấn tổng hợp, ⚠ vẫn là lược đồ cứng, ⚠ không giải quyết vấn đề thay đổi cấu trúc.

• C (network model) — ⚠ mô hình CSDL từ thập niên 1970: ⚠ hầu như không còn dùng, ⚠ và ⚠ vẫn cần định nghĩa cấu trúc trước.

Ghi nhớ

⚠ Các mô hình dữ liệu — bảng phải thuộc: | Mô hình | Dùng khi | |---|---| | ⚠ Quan hệ chuẩn hoá | ⚠ giao dịch, tính toàn vẹn cao, lược đồ ổn định | | ⚠ Tài liệu (document) | ⚠ cấu trúc linh hoạt, thay đổi thường xuyên — đề này | | ⚠ Star schema | ⚠ kho dữ liệu: một bảng fact + nhiều bảng dimension | | ⚠ Snowflake schema | ⚠ star nhưng dimension được chuẩn hoá thêm | | ⚠ Cột rộng (wide-column) | ⚠ Bigtable — khối lượng cực lớn, độ trễ thấp |

Từ khoá nhận diện:

"lược đồ đổi liên tục" → ⚠ mô hình tài liệu, Firestore "phân tích, báo cáo, tổng hợp" → ⚠ star schema, BigQuery "hàng triệu ghi mỗi giây, chuỗi thời gian" → ⚠ Bigtable "giao dịch quan hệ toàn cầu" → ⚠ Spanner

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lược đồ thật sự đổi bao nhiêu lần một quý | ⚠ quyết định có đáng bỏ mô hình quan hệ không | | Có cần JOIN nhiều không | ⚠ nếu có thì tài liệu là lựa chọn khó | | Ai kiểm tra tính hợp lệ của dữ liệu | ⚠ không có lược đồ thì ứng dụng phải lo |

Và cái giá thật của mô hình linh hoạt: lược đồ không biến mất, nó chỉ chuyển từ cơ sở dữ liệu vào mã nguồn. Ở đó không ai bắt buộc nó phải nhất quán, và không ai được cảnh báo khi nó bị vi phạm.