Ngân hàng đề — Google Cloud Associate Data Practitioner

Đáp án

C — Cloud Logging (Logs Explorer) cho job Dataflow.

Vì sao đúng

Lỗi lệch lược đồ xảy ra bên trong pipeline Dataflow khi nó cố ghi vào BigQuery. Mọi thông báo lỗi và stack trace của worker đều đổ về Cloud Logging.

⚠ Điểm mấu chốt — lỗi phát sinh ở đâu thì log ở đó:

Pub/Sub → DATAFLOW → BigQuery
                ↑
        lỗi lệch lược đồ xảy ra ở đây
        (khi worker cố ghi vào BigQuery)
                ↓
    → log của WORKER đổ về CLOUD LOGGING
        ↓
    Lọc trong Logs Explorer:
      resource.type="dataflow_step"
      resource.labels.job_id="<job id>"
      severity>=ERROR

⚠ Vì sao ba nơi kia không phải nơi tìm chi tiết:

BIGQUERY JOB HISTORY
    → Dataflow ghi bằng STREAMING /
      Storage Write API
    → thường KHÔNG tạo "job" hiện ở đây
    → và không có stack trace của worker

PUB/SUB METRICS PANEL
    → cho biết CÓ tồn đọng hay không
    → nhưng KHÔNG cho biết VÌ SAO

DEAD-LETTER TOPIC
    → chứa THÔNG ĐIỆP thất bại
    → hữu ích, nhưng là NƠI CHỨA DỮ LIỆU
      hỏng, không phải nơi có log chi tiết
    → và chỉ tồn tại NẾU đã cấu hình

⚠ Quy trình chẩn đoán đúng thứ tự:

1. Dataflow console → Job graph
     → bước nào đang lỗi
2. Logs Explorer, severity>=ERROR
     → SẮP XẾP TĂNG DẦN
     → tìm lỗi ĐẦU TIÊN
3. Đọc stack trace
     → thường nêu rõ tên trường lệch
4. So lược đồ bảng với payload
     bq show --schema
5. Sửa: đổi lược đồ, hoặc thêm bước
   ánh xạ, hoặc đẩy bản ghi hỏng
   sang dead-letter

Xem thêm câu #12920 (lô 133): cùng câu hỏi về nơi tìm log lỗi của Dataflow, cùng khoá Cloud Logging. Hai câu hoàn toàn nhất quán. Và #12930 (lô 133): giao diện Dataflow để xem đồ thị và chỉ số, không phải log.

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

• B (dead-letter topic) — đây là phương án gần nhất và rất nên có, nhưng nó chứa các THÔNG ĐIỆP thất bại, không phải log chi tiết có stack trace; và nó chỉ tồn tại nếu pipeline đã được cấu hình dead-letter.

• A (BigQuery job history) — ghi bằng Storage Write API thường không tạo job hiện ở đây, và không có log của worker.

• D (bảng chỉ số của Pub/Sub topic) — cho biết backlog và tốc độ, không cho biết nguyên nhân lỗi.

Ghi nhớ

⚠ Bốn nơi xem thông tin về pipeline — bảng phải thuộc: | Nơi | Cho gì | |---|---| | Cloud Logging (Logs Explorer) | LOG, thông báo lỗi, STACK TRACE | | Dataflow Job graph | cấu trúc, throughput từng bước | | Dataflow Job metrics | freshness, latency, số worker | | Cloud Monitoring | dashboard tổng hợp, CẢNH BÁO | | Dead-letter | BẢN GHI hỏng để phân tích |

Từ khoá nhận diện:

"stack trace, thông báo lỗi chi tiết" → Cloud Logging "bước nào chậm" → Dataflow Job graph "pipeline có theo kịp không" → data freshness "bản ghi nào bị hỏng" → dead-letter "backlog Pub/Sub" → Monitoring metrics

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lỗi đầu tiên là gì | Logs Explorer, sắp xếp tăng dần, severity>=ERROR | | Lược đồ bảng thế nào | bq show --schema --format=prettyjson | | Payload thực tế ra sao | xem một thông điệp trong dead-letter hoặc log |

Và một cảnh báo nên có sẵn cho mọi pipeline luồng, vì tình huống trong đề rất hay xảy ra: data freshness vượt ngưỡng. Job vẫn ở trạng thái "Running", không có gì đỏ trên giao diện, nhưng dữ liệu đã ngừng tới BigQuery từ nhiều giờ trước — và nếu chỉ theo dõi trạng thái job, bạn sẽ chỉ biết khi có người hỏi vì sao báo cáo đứng yên.

Đáp án

C — Tổng dung lượng dữ liệu và băng thông mạng khả dụng.

Vì sao đúng

Quyết định giữa chuyển trực tuyến và chuyển ngoại tuyến là một phép tính số học đơn giản: bao nhiêu dữ liệu, chia cho tốc độ đường truyền, ra bao nhiêu thời gian.

⚠ Điểm mấu chốt — làm phép tính trước, quyết định sau:

Thời gian ≈ Dung lượng / Băng thông
        ↓
    1 Gbps dùng hết công suất
      ≈ 10 TB mỗi ngày
    100 Mbps
      ≈ 1 TB mỗi ngày
        ↓
    ⚠ Thực tế chỉ đạt 50–70%
      con số lý thuyết
        ↓
    Quá VÀI TUẦN → chuyển sang
    thiết bị vật lý

⚠ Ví dụ cụ thể:

10 TB qua đường 1 Gbps
    → khoảng 1–2 ngày
    → TRỰC TUYẾN (Storage Transfer Service)

500 TB qua đường 100 Mbps
    → khoảng 500 ngày
    → NGOẠI TUYẾN (Transfer Appliance)

100 TB qua đường 10 Gbps
    → khoảng 1–2 ngày
    → TRỰC TUYẾN vẫn hợp lý
        ↓
    ⚠ Cùng một dung lượng, kết luận
      KHÁC NHAU tuỳ băng thông
    → phải xét CẢ HAI yếu tố

⚠ Vì sao ba phương án kia không phải yếu tố quyết định:

"Số lượng tệp và lớp lưu trữ đích"
    → ảnh hưởng hiệu năng và chi phí
    → nhưng KHÔNG quyết định
      trực tuyến hay ngoại tuyến

"Định dạng dữ liệu và kỹ năng đội"
    → không liên quan tới phương thức chuyển

"Yêu cầu bảo mật và ngân sách"
    → CẢ HAI phương thức đều mã hoá
    → ngân sách là ràng buộc phụ,
      không phải yếu tố kỹ thuật quyết định

Xem thêm câu #13089 (cùng lô): áp dụng chính phép tính này — 100 TB, đường truyền chậm, mất hơn một năm → Transfer Appliance. Và #12933/#12939 (lô 134), #13074 (lô 136): cùng bộ tiêu chí cho các quy mô khác nhau. Năm câu, một quy tắc duy nhất — hoàn toàn nhất quán.

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

• D (yêu cầu bảo mật và ngân sách) — đây là phương án gần nhất về mặt "yếu tố thực tế của dự án", nhưng cả hai phương thức đều mã hoá dữ liệu, và ngân sách chỉ là ràng buộc phụ — không quyết định tính khả thi kỹ thuật.

• A (số lượng tệp và lớp lưu trữ đích) — ảnh hưởng hiệu năng và chi phí, không quyết định phương thức.

• B (định dạng dữ liệu và kỹ năng đội) — không liên quan tới việc chọn kênh chuyển.

Ghi nhớ

⚠ Chọn công cụ chuyển dữ liệu — bảng phải thuộc: | Tình huống | Công cụ | |---|---| | Vài GB, một lần, trong script | gcloud storage cp | | TB, băng thông ĐỦ, có lịch | Storage Transfer Service | | Nguồn tại chỗ, băng thông đủ | STS + agent pool | | Hàng trăm TB, băng thông KHÔNG đủ | Transfer Appliance | | Cần đường truyền riêng lâu dài | Cloud Interconnect |

Từ khoá nhận diện:

"dung lượng và băng thông" → tiêu chí quyết định "mất nhiều tháng nếu truyền mạng" → Transfer Appliance "vài TB, mạng ổn" → Storage Transfer Service "vài GB, một lần" → gcloud storage "cần băng thông lớn lâu dài" → Interconnect

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Băng thông thật là bao nhiêu | đo thử với một tệp lớn, đừng tin con số hợp đồng | | Truyền trực tuyến mất bao lâu | tính theo băng thông đo được | | Dữ liệu đã tới đủ chưa | so số tệp và checksum |

Và một sai lầm rất hay gặp khi lập kế hoạch: dùng con số băng thông trong hợp đồng thay vì băng thông đo được. Đường truyền 1 Gbps chia sẻ với toàn bộ văn phòng có thể chỉ còn 200 Mbps khả dụng cho việc chuyển dữ liệu — và sự chênh lệch đó đủ để biến một kế hoạch hai tuần thành ba tháng.

Đáp án

D — Phân cụm (clustering) bảng theo cột product_sku.

Vì sao đúng

Đề nêu ba dấu hiệu chỉ thẳng vào phân cụm: truy vấn lọc và tổng hợp theo product_sku, cột này có độ phân biệt rất cao (high cardinality), và bảng KHÔNG phân vùng theo ngày.

⚠ Điểm mấu chốt — phân cụm SẮP XẾP dữ liệu cùng khoá cạnh nhau:

CLUSTER BY product_sku
        ↓
    BigQuery sắp xếp dữ liệu vật lý
    theo product_sku
        ↓
    Các dòng cùng SKU nằm CẠNH NHAU
    trong cùng khối
        ↓
    WHERE product_sku = 'ABC-123'
        ↓
    → BigQuery BỎ QUA các khối
      không chứa SKU đó
    → quét ít hơn, nhanh hơn, rẻ hơn

⚠ Vì sao "độ phân biệt cao" lại là dấu hiệu của phân cụm:

Cột có RẤT NHIỀU giá trị khác nhau
    (product_sku, user_id, order_id)
        ↓
    → phân vùng KHÔNG dùng được
      (tối đa 4.000 phân vùng)
        ↓
    → phân cụm là công cụ đúng
        ↓
    Ngược lại, cột ít giá trị
    (giới tính, trạng thái)
        ↓
    ⚠ phân cụm gần như VÔ ÍCH

⚠ Tạo lại bảng có phân cụm:

CREATE TABLE `du_an.san_pham_moi`
CLUSTER BY product_sku
AS SELECT * FROM `du_an.san_pham`;

        ↓
    ⚠ Không đổi bảng đang có tại chỗ được
    → tạo bảng mới rồi chuyển sang
        ↓
    Nếu có cột ngày, nên thêm:
      PARTITION BY DATE(ngay)
      CLUSTER BY product_sku

Xem thêm câu #13005 (lô 135): cũng khoá phân cụm, nhưng ở đó bảng đã phân vùng theo ngày và nút thắt là JOIN theo store_id. Và #12979 (lô 134): khoá phân vùng vì truy vấn lọc theo NGÀY. Ba câu, hai khoá, phân biệt bằng CỘT ĐƯỢC LỌC — hoàn toàn nhất quán.

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

• B (bật long-term storage) — đây là phương án dễ nhầm vì cũng liên quan tới bảng lớn, nhưng nó là cơ chế TỰ ĐỘNG giảm GIÁ LƯU TRỮ, hoàn toàn không ảnh hưởng hiệu năng truy vấn.

• A (tạo authorized view) — cơ chế bảo mật và chia sẻ, không tối ưu hiệu năng.

• C (đặt table expiration) — xoá bảng vào một thời điểm, không liên quan gì.

Ghi nhớ

⚠ Phân vùng ↔ phân cụm — bảng phải thuộc: | | Partitioning | Clustering | |---|---|---| | Cơ chế | chia bảng thành phần vật lý | sắp xếp trong phân vùng | | Số cột | MỘT | tối đa 4, CÓ THỨ TỰ | | Kiểu cột | DATE, TIMESTAMP, DATETIME, INT64 | hầu hết kiểu | | Độ phân biệt | THẤP (ngày, tháng) | CAO (id, sku) | | Giảm chi phí | đoán trước được | không đoán trước được | | Giới hạn | 4.000 phân vùng | không | | Nên dùng | CẢ HAI khi có thể |

Từ khoá nhận diện:

"lọc theo cột nhiều giá trị (id, sku)" → phân cụm "lọc theo NGÀY" → phân vùng "đã phân vùng rồi, join chậm" → thêm phân cụm theo cột join "giảm giá lưu trữ" → long-term storage (tự động) "mua thêm slot" → giải pháp cuối cùng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng có phân cụm chưa | bq show <dataset>.<bảng> → Clustered By | | Truy vấn có rẻ hơn không | so total_bytes_billed trước và sau | | Cột có đủ độ phân biệt không | SELECT COUNT(DISTINCT product_sku) |

Và một phép kiểm tra nên làm trước khi chọn cột phân cụm: đếm số giá trị phân biệt của cột đó. Một cột chỉ có năm giá trị sẽ khiến mỗi khối dữ liệu vẫn chứa cả năm — và phân cụm khi ấy không bỏ qua được gì, dù bảng vẫn được sắp xếp lại tốn công.

Đáp án

A — Bigtable.

Vì sao đúng

Đề nêu năm đặc điểm, và Bigtable khớp cả năm: chuỗi thời gian từ hàng triệu cảm biến, thông lượng GHI rất cao, đọc độ trễ thấp, phục vụ cả giám sát vận hành lẫn phân tích quy mô lớn, và mô hình wide-column linh hoạt.

⚠ Điểm mấu chốt — Bigtable sinh ra cho đúng dạng tải này:

Bigtable
        ↓
    - NoSQL WIDE-COLUMN
    - GHI hàng triệu điểm/giây
    - ĐỌC độ trễ MỘT CHỮ SỐ MILI GIÂY
    - mở rộng NGANG bằng cách thêm node
    - dữ liệu sắp xếp theo ROW KEY
        ↓
    → chuỗi thời gian IoT là
      trường hợp sử dụng KINH ĐIỂN

⚠ ⚠ Thiết kế ROW KEY — thứ quyết định thành bại:

Bigtable sắp xếp dữ liệu theo ROW KEY
        ↓
    ⚠ Row key TĂNG DẦN ĐỀU (như timestamp)
      → mọi ghi dồn vào MỘT node
      → HOTSPOT, thông lượng sụp đổ
        ↓
    Cách đúng cho IoT:
      <sensor_id>#<timestamp đảo ngược>
        ↓
    → ghi phân tán đều theo cảm biến
    → đọc chuỗi thời gian của một cảm biến
      vẫn rất nhanh (dữ liệu liền nhau)

⚠ Vì sao BigQuery không phải câu trả lời ở đây:

BigQuery
        ↓
    Kho PHÂN TÍCH, tối ưu cho
    QUÉT LỚN và tổng hợp
        ↓
    ⚠ KHÔNG hợp với đọc/ghi
      TỪNG BẢN GHI độ trễ mili giây
    ⚠ Đề yêu cầu "giám sát vận hành
      độ trễ thấp"
        ↓
    Mẫu thường dùng:
      Bigtable cho vận hành
      + xuất sang BigQuery cho phân tích sâu

Xem thêm câu #13057, #13071 và #13076 (lô 136): ánh xạ các loại dữ liệu vào Cloud SQL, Cloud Storage, BigQuery, Firestore. Câu này bổ sung Bigtable cho tải NoSQL quy mô lớn. Bốn câu vẽ nên bảng chọn kho đầy đủ — nhất quán.

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

• D (BigQuery) — đây là phương án gần nhất vì cũng xử lý được khối lượng khổng lồ, nhưng nó là kho PHÂN TÍCH: không phục vụ đọc/ghi từng bản ghi độ trễ mili giây cho giám sát vận hành.

• C (Cloud SQL) — CSDL quan hệ một node, không kham nổi hàng triệu lượt ghi mỗi giây.

• B (AlloyDB) — mạnh hơn Cloud SQL nhưng vẫn là PostgreSQL quan hệ, không phải wide-column, và không mở rộng ngang tới quy mô này.

Ghi nhớ

⚠ Chọn kho theo dạng tải — bảng phải thuộc: | Dạng tải | Dịch vụ | |---|---| | Chuỗi thời gian, ghi cực lớn, wide-column | Bigtable | | Giao dịch quan hệ | Cloud SQL / AlloyDB / Spanner | | Tài liệu, thời gian thực, di động | Firestore | | Phân tích quy mô petabyte | BigQuery | | Tệp phi cấu trúc | Cloud Storage | | Bộ nhớ đệm | Memorystore |

Từ khoá nhận diện:

"IoT, chuỗi thời gian, hàng triệu ghi/giây" → Bigtable "đọc độ trễ mili giây từng bản ghi" → Bigtable "phân tích, tổng hợp hàng tỉ dòng" → BigQuery "giao dịch, nhất quán" → Cloud SQL "đồng bộ thời gian thực tới máy khách" → Firestore

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có hotspot không | Key Visualizer trong console | | CPU node có quá tải không | chỉ số CPU utilization — nên dưới 70% | | Row key thiết kế thế nào | rà soát mã ghi dữ liệu |

Và một quyết định gần như không thể sửa về sau với Bigtable: thiết kế row key. Không có chỉ mục phụ, nên mọi mẫu truy vấn đều phụ thuộc vào row key — và đổi row key nghĩa là ghi lại toàn bộ dữ liệu. Hãy liệt kê mọi cách bạn sẽ truy vấn dữ liệu trước khi ghi bản ghi đầu tiên.

Đáp án

A — ETL, để dữ liệu được làm sạch và khử độc trong một engine xử lý RIÊNG TRƯỚC KHI vào kho.

Vì sao đúng

Đề nêu hai yêu cầu bảo mật tuyệt đối: PII phải được che, và đầu vào độc hại phải được khử độc — cả hai TRƯỚC KHI dữ liệu vào kho. Thứ tự đó buộc phải là ETL.

⚠ Điểm mấu chốt — dữ liệu KHÔNG ĐƯỢC TIN CẬY thì không cho vào kho:

Dữ liệu từ ứng dụng web CÔNG KHAI
        ↓
    ⚠ Người dùng bất kỳ có thể gửi lên
    ⚠ Có thể chứa PII
    ⚠ Có thể chứa nội dung độc hại
        ↓
    ETL: xử lý ở ENGINE RIÊNG trước
        ↓
    → chỉ dữ liệu ĐÃ SẠCH vào BigQuery
    → PII KHÔNG BAO GIỜ chạm tới kho

⚠ Vì sao ELT không dùng được ở đây:

ELT: nạp thô vào kho trước
        ↓
    ⚠ PII ĐÃ NẰM trong BigQuery
    → lọt vào time travel, snapshot, bản sao
    → ai truy vấn trong khoảng đó đều thấy
        ↓
    ⚠ Nội dung độc hại cũng vào kho
    → có thể ảnh hưởng hệ thống hạ nguồn
      đọc từ kho
        ↓
    → vi phạm chính sách của đề

⚠ Kiến trúc cụ thể:

Ứng dụng web → Pub/Sub hoặc Cloud Storage
        ↓
    DATAFLOW
      - gọi Sensitive Data Protection
        để phát hiện và che PII
      - kiểm tra tính hợp lệ, khử độc
      - bản ghi hỏng → DEAD-LETTER
        ↓
    BIGQUERY — chỉ dữ liệu đã sạch

Xem thêm câu #13032 (lô 136): cùng khoá ETL vì phải làm sạch trước khi dữ liệu sẵn sàng phân tích. Và #12913 (lô 133): cùng khoá ETL vì phải che PII trước khi nạp. Ba câu nhất quán. Còn #13049 (lô 136) khoá ELT vì ở đó không có ràng buộc PII.

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

• D (ELT — nạp thô nhanh rồi biến đổi sau bằng SQL) — đây là phương án gần nhất và là mặc định trong nhiều tình huống khác, nhưng nó đưa dữ liệu thô chứa PII vào kho trước — vi phạm trực tiếp chính sách.

• C (nạp thẳng, tin vào bảo mật nội tại của BigQuery) — BigQuery không tự khử độc hay che PII; bảo mật của nó là kiểm soát truy cập, không phải làm sạch nội dung.

• B (pipeline luồng qua Pub/Sub, coi là an toàn tự nhiên) — Pub/Sub chỉ vận chuyển thông điệp; nó không kiểm tra hay làm sạch nội dung.

Ghi nhớ

⚠ ETL ↔ ELT — khi nào bắt buộc ETL: | Tình huống | Mô hình | |---|---| | PII không được phép vào kho | ETL | | Dữ liệu từ nguồn KHÔNG TIN CẬY | ETL | | Quy định ngành bắt làm sạch trước | ETL | | Kho mạnh, muốn giữ dữ liệu thô | ELT | | Nguồn nội bộ đáng tin | ELT | | Mặc định hiện nay | ELT, trừ khi có ràng buộc như trên |

Từ khoá nhận diện:

"dữ liệu không tin cậy, che PII trước khi vào kho" → ETL "nạp thô rồi biến đổi bằng SQL" → ELT "kho tự bảo vệ" → luôn là phương án SAI "Pub/Sub an toàn tự nhiên" → SAI — nó chỉ vận chuyển "che theo vai trò khi đọc" → dynamic masking — bài toán khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kho còn PII không | quét bằng Sensitive Data Protection | | Bản ghi hỏng đi đâu | kiểm tra bảng dead-letter | | Pipeline có bỏ sót trường mới không | quét lại định kỳ khi nguồn đổi lược đồ |

Và một điều đáng làm ngay cả khi đã chọn ETL: vẫn giữ dữ liệu thô, nhưng ở một bucket riêng với quyền rất hẹp. ETL bảo vệ kho, nhưng nếu logic che có lỗi và bạn không còn nguồn để chạy lại, việc sửa sẽ phải bắt đầu bằng việc chờ dữ liệu mới phát sinh — điều không ai muốn khi phát hiện lỗi vào tuần thứ ba.

Đáp án

D — Một DATA LAKE, sử dụng cách tiếp cận "schema-on-read".

Vì sao đúng

Đề nêu ba đặc điểm: dữ liệu THÔ đa dạng (văn bản phi cấu trúc, log bán cấu trúc, ảnh), cần hệ thống LINH HOẠT, và chỉ áp lược đồ KHI SẴN SÀNG phân tích. Đó chính là định nghĩa của data lake với schema-on-read.

⚠ Điểm mấu chốt — schema-on-read ↔ schema-on-write:

SCHEMA-ON-WRITE (data warehouse)
        ↓
    Phải định LƯỢC ĐỒ TRƯỚC khi ghi
        ↓
    → dữ liệu không khớp thì BỊ TỪ CHỐI
    → nhất quán, truy vấn nhanh
    → ⚠ kém linh hoạt khi nguồn đổi

SCHEMA-ON-READ (data lake)        ← đề này
        ↓
    Ghi dữ liệu Ở DẠNG GỐC
        ↓
    Áp lược đồ KHI ĐỌC
        ↓
    → nhận được MỌI loại dữ liệu
    → ⚠ chất lượng không được bảo đảm

⚠ Data lake trên Google Cloud:

CLOUD STORAGE
    → lưu mọi thứ ở dạng gốc
        ↓
    + BigLake table       → truy vấn tại chỗ có bảo mật
    + Dataplex            → quản trị, phát hiện, chất lượng
    + Dataproc / Dataflow → xử lý
    + Object table        → truy vấn tệp phi cấu trúc
        ↓
    ⚠ Cloud Storage là NỀN của data lake

⚠ ⚠ Rủi ro lớn nhất — "data swamp" (đầm lầy dữ liệu):

Đổ mọi thứ vào lake, không quản trị
        ↓
    ⚠ Không ai biết dữ liệu nào là gì
    ⚠ Không ai biết dữ liệu nào còn đúng
    ⚠ Không ai biết ai được đọc cái gì
        ↓
    → lake thành nơi chứa rác đắt tiền
        ↓
    Phòng ngừa:
      - Dataplex làm danh mục
      - quy ước đặt tên và phân vùng thư mục
      - CHỦ SỞ HỮU rõ ràng cho từng vùng
      - chính sách vòng đời

Xem thêm câu #13062 (lô 136): khoá data warehouse với schema-on-write vì ở đó dữ liệu đã làm sạch, có lược đồ, cho báo cáo chính thức. Hai câu mô tả hai hệ thống khác nhau — hoàn toàn nhất quán.

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

• A (data lake với schema-on-write) — đây là phương án gần nhất vì chọn đúng hệ thống, nhưng gán sai cách tiếp cận: data lake dùng schema-on-READ.

• C (data warehouse với schema-on-write) — mô tả đúng cặp, nhưng sai hệ thống cho tình huống này: kho dữ liệu không nhận dữ liệu thô đa dạng như đề mô tả.

• B (data warehouse với schema-on-read) — sai cả hai vế.

Ghi nhớ

⚠ Data lake ↔ data warehouse — bảng phải thuộc: | | Data lake | Data warehouse | |---|---|---| | Dữ liệu | THÔ, mọi định dạng | đã xử lý, có cấu trúc | | Lược đồ | schema-on-READ | schema-on-WRITE | | Người dùng | nhà khoa học dữ liệu, kỹ sư | nhà phân tích nghiệp vụ | | Chi phí lưu | rất rẻ | cao hơn | | Trên GCP | Cloud Storage | BigQuery | | Rủi ro | data swamp | kém linh hoạt |

Từ khoá nhận diện:

"dữ liệu thô đa dạng, áp lược đồ khi đọc" → data lake, schema-on-read "đã làm sạch, lược đồ rõ, cho báo cáo" → data warehouse, schema-on-write "kết hợp cả hai" → data lakehouse — BigLake, Iceberg "truy vấn lake bằng SQL có bảo mật" → BigLake table "quản trị lake" → Dataplex

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lake có được lập danh mục không | Dataplex → Search | | Có tệp nào không ai biết là gì | rà soát siêu dữ liệu thiếu mô tả | | Chi phí lưu bao nhiêu | gcloud storage du -s và billing export |

Và một điều quyết định data lake có giá trị hay trở thành đầm lầy: mỗi vùng dữ liệu phải có một người chịu trách nhiệm rõ ràng. Công nghệ lưu trữ thì rẻ và không giới hạn, nhưng câu trả lời cho "dữ liệu này là gì và hỏi ai khi nó sai" thì phải có người viết ra — và đó là phần duy nhất không có công cụ nào làm thay được.

Đáp án

C — Cấu hình job nạp cho phép THÊM TRƯỜNG MỚI vào lược đồ.

Vì sao đúng

BigQuery có sẵn tuỳ chọn cập nhật lược đồ khi nạp: ALLOW_FIELD_ADDITION cho phép job tự thêm cột mới vào bảng đích thay vì thất bại.

⚠ Điểm mấu chốt — hai tuỳ chọn cập nhật lược đồ:

ALLOW_FIELD_ADDITION
        ↓
    Nguồn có TRƯỜNG MỚI
        ↓
    → BigQuery TỰ THÊM cột vào bảng
    → cột đó NULL cho dữ liệu cũ
        ↓
    ⚠ Đúng tình huống trong đề

ALLOW_FIELD_RELAXATION
        ↓
    Trường từ REQUIRED thành NULLABLE
        ↓
    → cho phép nới lỏng ràng buộc

⚠ Cấu hình:

# Dòng lệnh
bq load \
  --source_format=NEWLINE_DELIMITED_JSON \
  --schema_update_option=ALLOW_FIELD_ADDITION \
  du_an.bang gs://bucket/du-lieu.json

# Bằng SQL
LOAD DATA INTO `du_an.bang`
FROM FILES (...)
WITH CONNECTION ...
-- hoặc dùng API với schemaUpdateOptions

        ↓
    ⚠ Có thể khai CẢ HAI tuỳ chọn cùng lúc
    → chịu được cả thêm trường lẫn nới ràng buộc

⚠ Giới hạn — những gì tuỳ chọn này KHÔNG cứu được:

ĐỔI KIỂU DỮ LIỆU
    STRING → INTEGER
        ↓
    ⚠ VẪN THẤT BẠI

XOÁ TRƯỜNG ở nguồn
    → cột cũ vẫn còn, nhận NULL — không lỗi

ĐỔI TÊN TRƯỜNG
    → coi như xoá cột cũ + thêm cột mới
    → dữ liệu cũ nằm ở cột cũ
        ↓
    ⚠ Chỉ THÊM TRƯỜNG và NỚI RÀNG BUỘC
      được xử lý tự động

Xem thêm câu #13063 (lô 136): về nạp NDJSON lồng nhau vào BigQuery. Câu này về xử lý lược đồ thay đổi theo thời gian. Hai câu bổ sung nhau. Và #13081 (lô 136): chẩn đoán lỗi lệch lược đồ trong pipeline Dataflow.

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

• D (sửa lược đồ bảng thủ công trước mỗi lần chạy) — đây là phương án gần nhất và giải quyết được vấn đề, nhưng nó thủ công, dễ quên, và trái yêu cầu "tự động xử lý trong tương lai".

• B (xoá cột mới khỏi tệp nguồn trước khi nạp) — vứt bỏ dữ liệu mà nguồn cố ý gửi; thêm một bước xử lý phải bảo trì.

• A (tạo bảng mới cho mỗi ngày) — phân mảnh dữ liệu, khiến truy vấn phải gộp hàng trăm bảng; đây là phản mẫu.

Ghi nhớ

⚠ Xử lý lược đồ thay đổi trong BigQuery — bảng phải thuộc: | Thay đổi | Cách xử lý | |---|---| | Thêm trường mới | ALLOW_FIELD_ADDITION | | REQUIRED → NULLABLE | ALLOW_FIELD_RELAXATION | | Xoá trường ở nguồn | cột cũ nhận NULL — không lỗi | | ĐỔI KIỂU dữ liệu | VẪN LỖI — phải xử lý thủ công | | Đổi tên trường | như xoá + thêm — cần ánh xạ | | Lược đồ rất động | dùng kiểu JSON gốc |

Từ khoá nhận diện:

"nguồn thêm cột mới, job thất bại" → ALLOW_FIELD_ADDITION "REQUIRED thành NULLABLE" → ALLOW_FIELD_RELAXATION "lược đồ thay đổi liên tục, khó đoán" → kiểu JSON gốc "tạo bảng mới mỗi ngày" → phản mẫu "sửa lược đồ thủ công" → không tự động

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lược đồ hiện tại có gì | bq show --schema --format=prettyjson | | Cột mới đã được thêm chưa | so trước và sau lần nạp | | Job có lỗi gì | bq show -j <job_id> |

Và một điều nên thoả thuận với đội quản lý hệ thống nguồn, vì nó giải quyết vấn đề tận gốc: một hợp đồng lược đồ và cơ chế báo trước khi thay đổi. ALLOW_FIELD_ADDITION xử lý êm việc thêm cột, nhưng nó không cứu được việc đổi kiểu dữ liệu — và biết trước một tuần vẫn tốt hơn nhiều so với phát hiện lúc pipeline đã dừng.

Đáp án

B — Dùng Spot VM (preemptible VM) cho các node worker và bật autoscaling cho cụm.

Vì sao đúng

Đề nêu hai điều kiện quyết định: job chịu được việc mất vài node mà không hỏng, và mục tiêu là giảm chi phí vận hành tối đa. Đó chính là điều kiện lý tưởng để dùng Spot VM.

⚠ Điểm mấu chốt — Spot VM rẻ hơn rất nhiều nhưng có thể bị thu hồi:

SPOT VM
        ↓
    Giá rẻ hơn VM thường RẤT NHIỀU
        ↓
    ⚠ Google có thể THU HỒI bất cứ lúc nào
      (báo trước 30 giây)
        ↓
    Job CHỊU ĐƯỢC mất node
        ↓
    → đúng điều kiện để dùng
    → tiết kiệm lớn mà không ảnh hưởng

⚠ Trong Dataproc — dùng SECONDARY WORKER:

gcloud dataproc clusters create cum \
  --num-workers=2 \
  --num-secondary-workers=8 \
  --secondary-worker-type=spot
        ↓
    PRIMARY WORKER (thường)
      → chạy HDFS DataNode
      → giữ ổn định cho cụm

    SECONDARY WORKER (Spot)
      → CHỈ tính toán, không lưu dữ liệu
      → mất đi không sao
        ↓
    ⚠ Đây là lý do phải giữ vài
      primary worker thường

⚠ Autoscaling — nửa còn lại của câu trả lời:

Autoscaling policy
        ↓
    Thêm worker khi có job đang chờ
    Bớt worker khi rảnh
        ↓
    → không trả tiền cho công suất
      không dùng tới
        ↓
    Kết hợp với Spot:
      phần co giãn dùng Spot
      → rẻ nhất có thể

⚠ Và điều kiện nền: dữ liệu KHÔNG nằm trên cụm:

Lưu dữ liệu ở CLOUD STORAGE
        ↓
    → mất node không mất dữ liệu
    → cụm xoá đi vẫn còn nguyên
        ↓
    ⚠ Nếu lưu trên HDFS của cụm
      → mất node có thể MẤT DỮ LIỆU
      → không dùng Spot được

Xem thêm câu #13042 và #13043 (lô 136): chọn giữa cụm thường trực và Dataproc Serverless. Và #12997 (lô 135): đánh đổi giữa hai phương án. Ba câu về vận hành Dataproc, câu này về TỐI ƯU CHI PHÍ — nhất quán.

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

• C (tắt autoscaling để chi phí cố định và dự đoán được) — đây là phương án gần nhất về mặt "quản lý chi phí", nhưng cố định KHÔNG có nghĩa là THẤP: cụm giữ nguyên kích thước sẽ trả tiền cho cả công suất không dùng.

• D (lưu dữ liệu trên HDFS của node chính) — đi ngược thực hành chuẩn: buộc cụm phải sống mãi, và không dùng được Spot VM.

• A (dùng loại máy lớn nhất cho mọi node) — tăng chi phí, không giảm.

Ghi nhớ

⚠ Tiết kiệm chi phí Dataproc — bảng phải thuộc: | Cách | Hiệu quả | |---|---| | Spot VM cho secondary worker | giảm mạnh nhất | | Autoscaling policy | không trả cho công suất thừa | | Cụm TẠM (ephemeral) | tạo – chạy – xoá | | Dataproc Serverless | không có cụm nào cả | | --max-idle | tự tắt khi rảnh | | Lưu dữ liệu ở GCS | điều kiện nền cho mọi cách trên | | Sai lầm lớn nhất | cụm thường trực bị bỏ quên |

Từ khoá nhận diện:

"job chịu được mất node, giảm chi phí" → Spot VM + autoscaling "không muốn quản lý cụm" → Dataproc Serverless "cụm thường trực cho truy vấn tương tác" → Dataproc trên Compute Engine "lưu trên HDFS" → phản mẫu trên đám mây "máy to nhất cho nhanh" → thường là phương án SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cụm dùng Spot chưa | gcloud dataproc clusters describe <ten> → secondaryWorkerConfig | | Job có bị hỏng vì mất node không | log của job, tỉ lệ task phải chạy lại | | Tiết kiệm được bao nhiêu | billing export, so trước và sau |

Và một cấu hình nên đặt cùng lúc với autoscaling: gracefulDecommissionTimeout. Không có nó, việc thu nhỏ cụm sẽ gỡ node ngay giữa lúc task đang chạy, buộc Spark tính lại phần đó — và khoản tiết kiệm từ việc bớt node có thể bị ăn hết bởi thời gian chạy lại.

Đáp án

A — Transfer Appliance.

Vì sao đúng

Đề đã làm sẵn phép tính: 100 TB, đường truyền chậm và không ổn định, và chuyển trực tuyến mất hơn một năm. Khi con số đó vượt xa mọi thời hạn hợp lý, giải pháp là chuyển bằng đường vật lý.

⚠ Điểm mấu chốt — khi mạng là nút thắt, đừng dùng mạng:

100 TB, chuyển trực tuyến hơn MỘT NĂM
        ↓
    ⚠ Không kế hoạch nào chấp nhận được
    ⚠ Đường truyền "không ổn định" còn
      khiến việc chuyển liên tục bị đứt
        ↓
    Transfer Appliance
        ↓
    → sao dữ liệu vào thiết bị qua
      MẠNG NỘI BỘ (rất nhanh)
    → gửi thiết bị tới Google
    → Google nạp vào Cloud Storage
        ↓
    Tổng thời gian: tính bằng TUẦN

⚠ Quy trình sáu bước:

1. Đặt thiết bị qua console
2. Google gửi thiết bị tới cơ sở
3. Cắm vào mạng nội bộ, sao dữ liệu vào
     → tốc độ LAN, không phải Internet
4. Gửi thiết bị trả lại Google
5. Google nạp dữ liệu vào Cloud Storage
6. Thiết bị được XOÁ AN TOÀN
        ↓
    ⚠ Dữ liệu MÃ HOÁ suốt hành trình
    ⚠ Chỉ bạn giữ khoá giải mã

⚠ Chọn dung lượng thiết bị:

Transfer Appliance TA40   → khoảng 40 TB
Transfer Appliance TA300  → khoảng 300 TB
        ↓
    100 TB → MỘT thiết bị TA300
             hoặc BA thiết bị TA40
        ↓
    ⚠ Đặt dư một chút — dữ liệu
      thường lớn hơn ước tính

Xem thêm câu #13082 (cùng lô): nêu chính hai tiêu chí quyết định — dung lượng và băng thông. Câu này là ứng dụng trực tiếp. Và #12939 (lô 134): cùng khoá Transfer Appliance cho 500 TB. Ba câu hoàn toàn nhất quán.

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

• D (Storage Transfer Service) — đây là phương án gần nhất và là dịch vụ chuyển dữ liệu được quản lý tốt nhất, nhưng nó vẫn truyền qua đường mạng — chính là nút thắt mà đề mô tả.

• B (gcloud storage) — cũng qua mạng, lại chạy trên máy bạn, không chịu được đường truyền không ổn định.

• C (Cloud Storage FUSE) — gắn bucket như hệ thống tệp để ứng dụng đọc ghi; không phải công cụ di chuyển dữ liệu lớn.

Ghi nhớ

⚠ Chọn cách chuyển theo DUNG LƯỢNG và BĂNG THÔNG — bảng phải thuộc: | Tình huống | Công cụ | |---|---| | Vài GB, một lần | gcloud storage cp | | TB, băng thông đủ | Storage Transfer Service | | Nguồn tại chỗ, băng thông đủ | STS + agent pool | | Hàng trăm TB, băng thông KHÔNG đủ | Transfer Appliance | | Cần băng thông lớn LÂU DÀI | Cloud Interconnect |

Từ khoá nhận diện:

"mất nhiều tháng/năm nếu truyền mạng" → Transfer Appliance "TB, mạng ổn, cần quản lý" → Storage Transfer Service "vài GB trong script" → gcloud storage "gắn bucket như thư mục" → Cloud Storage FUSE "chuyển liên tục lâu dài" → Interconnect

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Băng thông thật là bao nhiêu | đo thử, đừng tin con số hợp đồng | | Thiết bị có sẵn ở nước bạn không | kiểm tra tài liệu Google Cloud | | Dữ liệu đã tới đủ chưa | so số tệp và checksum |

Và một bước rất đáng làm trước khi đặt thiết bị: kiểm kê xem 100 TB đó có thật sự cần chuyển hết không. Kho lưu trữ lâu năm thường chứa bản sao trùng lặp, tệp tạm và dữ liệu đã hết giá trị — và giảm được 30% khối lượng đôi khi đổi được từ ba thiết bị xuống còn một.

Đáp án

B — Một Dead-Letter Topic (DLT) cho subscription.

Vì sao đúng

Với BigQuery subscription được quản lý, việc ghi dữ liệu do chính Pub/Sub thực hiện — không có worker nào của bạn chạy, nên không có log ứng dụng nào để đọc. Dead-letter topic là nơi duy nhất bắt được các thông điệp thất bại.

⚠ Điểm mấu chốt — không có mã của bạn thì không có log của bạn:

BigQuery subscription (được quản lý)
        ↓
    Pub/Sub TỰ ghi thẳng vào bảng
        ↓
    ⚠ KHÔNG có Dataflow job
    ⚠ KHÔNG có Cloud Function
    ⚠ KHÔNG có worker nào của bạn
        ↓
    → KHÔNG có log ứng dụng trong
      Cloud Logging để đọc
        ↓
    Thông điệp ghi thất bại
        ↓
    → Pub/Sub thử lại
    → hết số lần → NẰM LẠI trong subscription
    → backlog TĂNG mà không có lỗi nào hiện ra

⚠ Dead-letter topic giải quyết đúng chỗ đó:

gcloud pubsub subscriptions update sub-bigquery \
  --dead-letter-topic=projects/DU-AN/topics/dlt \
  --max-delivery-attempts=5
        ↓
    Thông điệp thất bại 5 lần
        ↓
    → chuyển sang DLT
        ↓
    ⚠ Bạn ĐỌC ĐƯỢC nội dung thông điệp
    ⚠ Kèm THUỘC TÍNH ghi lý do thất bại
        ↓
    → chẩn đoán được nguyên nhân gốc

⚠ Nguyên nhân thường gặp của lỗi ghi BigQuery subscription:

- Lược đồ thông điệp KHÔNG KHỚP bảng
- Trường bắt buộc bị thiếu
- Kiểu dữ liệu sai
- Bảng đích không tồn tại hoặc bị đổi
- Service agent của Pub/Sub thiếu quyền
  roles/bigquery.dataEditor

⚠ Xem thêm câu #13081 (lô 136): cũng là "Pub/Sub → BigQuery ngừng chảy", nhưng ở đó là pipeline DATAFLOW tự viết → có worker, có log → khoá là Cloud Logging. Câu này là subscription ĐƯỢC QUẢN LÝ → không có worker nào → phải bật DLT. Hai khoá khác nhau vì KIẾN TRÚC khác nhau — hoàn toàn nhất quán, và đây chính là điểm phân biệt cần nhớ.

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

• C (tạo alerting policy trong Cloud Monitoring) — đây là phương án gần nhất và rất nên có, nhưng cảnh báo chỉ BÁO CÓ VẤN ĐỀ; nó không bắt được thông điệp lỗi để phân tích nguyên nhân.

• A (viết subscriber riêng bằng Cloud Function) — thay đổi cả kiến trúc để lấy log; DLT giải quyết trực tiếp mà không phải bỏ subscription được quản lý.

• D (bật log mức debug cho topic) — không có tuỳ chọn như vậy; và vấn đề nằm ở subscription, không phải topic.

Ghi nhớ

⚠ Chẩn đoán "dữ liệu ngừng tới BigQuery" — theo KIẾN TRÚC: | Kiến trúc | Nơi tìm nguyên nhân | |---|---| | Dataflow tự viết | Cloud Logging — log worker, stack trace | | Cloud Function subscriber | Cloud Logging — log của hàm | | BigQuery subscription (quản lý) | DEAD-LETTER TOPIC | | Cloud Storage subscription | dead-letter topic | | Chung | Monitoring cho backlog và cảnh báo |

Từ khoá nhận diện:

"subscription được quản lý, không thấy log" → dead-letter topic "pipeline Dataflow, cần stack trace" → Cloud Logging "backlog tăng" → num_undelivered_messages trong Monitoring "thông điệp hỏng để phân tích" → DLT "cảnh báo khi có vấn đề" → alerting policy — báo, không chẩn đoán

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Subscription có DLT chưa | gcloud pubsub subscriptions describe <sub> → deadLetterPolicy | | Có thông điệp hỏng không | subscription trên DLT | | Backlog bao nhiêu | Monitoring → num_undelivered_messages |

Và một cấu hình nên đặt ngay khi tạo bất kỳ subscription nào được quản lý: dead-letter topic. Không có nó, thông điệp thất bại sẽ nằm im trong subscription cho tới khi hết thời gian giữ rồi biến mất — và bạn sẽ có một backlog tăng đều mà không một dòng log nào giải thích tại sao.