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

Đáp án

B — Spanner.

Vì sao đúng

Đề gói gọn ba yêu cầu, và chỉ Spanner có đủ cả ba:

⚠ Ba yêu cầu và lời đáp của Spanner:

1. MỘT CSDL duy nhất phục vụ nhiều châu lục
     → Spanner có cấu hình ĐA VÙNG và ĐA LỤC ĐỊA

2. MỞ RỘNG NGANG toàn cầu
     → thêm node là thêm năng lực,
       dữ liệu tự chia split và cân bằng

3. NHẤT QUÁN GIAO DỊCH MẠNH TOÀN CẦU
     → ⚠ đây là chỗ mọi CSDL khác gãy
     → Spanner có TrueTime

⚠ TrueTime — thứ khiến Spanner khác biệt:

Đồng hồ nguyên tử + máy thu GPS
    ở mọi trung tâm dữ liệu Google
        ↓
    TrueTime trả về một KHOẢNG
    thay vì một điểm thời gian
        ↓
    Spanner chờ hết khoảng bất định
    trước khi commit
        ↓
    ⚠ Mọi giao dịch có thứ tự TOÀN CỤC
      thống nhất, dù ở châu lục nào
        ↓
    → nhất quán ngoại (external consistency),
      mức mạnh nhất có thể có

⚠ Vì sao chuyện này sống còn với thanh toán:

Chuyển tiền: trừ tài khoản ở Singapore
             cộng tài khoản ở London
        ↓
    Nếu chỉ NHẤT QUÁN CUỐI CÙNG
        ↓
    ⚠ Có khoảnh khắc tiền bị trừ
      mà chưa được cộng
    ⚠ Hoặc đọc thấy số dư cũ
      → cho rút hai lần
        ↓
    Spanner: giao dịch ACID xuyên vùng
        ↓
    → không bao giờ có trạng thái nửa vời

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

• A (Bigtable) — NoSQL rất nhanh, mở rộng ngang tuyệt vời, nhưng chỉ có giao dịch trong PHẠM VI MỘT DÒNG. Không có giao dịch nhiều dòng, không có SQL đầy đủ, và bản sao đa vùng là nhất quán cuối cùng. Không dùng được cho sổ cái tài chính.

• C (BigQuery) — kho dữ liệu phân tích (OLAP), sinh ra để quét hàng tỉ dòng, không phải để xử lý giao dịch (OLTP). Ghi từng giao dịch nhỏ với độ trễ mili-giây là sai công cụ.

• D (Cloud SQL) — MySQL/PostgreSQL có quản lý, ACID đầy đủ, nhưng chỉ mở rộng DỌC (máy to hơn) và bản sao đọc chỉ nhất quán cuối cùng. Không có ghi đa vùng — đúng thứ đề đòi.

Ghi nhớ

⚠ Chọn CSDL trên Google Cloud — bảng phải thuộc: | Nhu cầu | Chọn | |---|---| | OLTP toàn cầu + ACID + mở rộng ngang | Spanner | | OLTP quan hệ một vùng | Cloud SQL | | NoSQL khoá–giá trị, thông lượng cực lớn, độ trễ mili-giây | Bigtable | | NoSQL tài liệu, đồng bộ realtime cho di động | Firestore | | Phân tích, kho dữ liệu | BigQuery | | Bộ nhớ đệm | Memorystore |

Từ khoá nhận diện:

"toàn cầu + nhất quán mạnh + SQL" → Spanner "chuỗi thời gian, IoT, hàng petabyte, ghi rất nhiều" → Bigtable "nâng và chuyển MySQL/PostgreSQL sẵn có" → Cloud SQL "ứng dụng di động, đồng bộ ngoại tuyến" → Firestore "chạy báo cáo trên hàng tỉ dòng" → BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | CPU có quá tải không | giữ dưới 65% cho đa vùng | | Có hotspot không | Key Visualizer — nhìn bản đồ nhiệt khoá | | Truy vấn nào chậm | Query Insights trong console |

Và một điều rất dễ bị bỏ qua khi thiết kế trên Spanner: khoá chính quyết định hiệu năng nhiều hơn cả số node. Một khoá tăng dần theo thời gian sẽ dồn mọi lượt ghi vào cùng một split, và khi đó thêm node cũng gần như không giúp gì — đó là lỗi thiết kế phổ biến nhất mà người mới dùng Spanner mắc phải.

Đáp án

A — Vào Model Registry, xác nhận chỉ số của v1 tốt hơn, rồi triển khai v1 lên endpoint sản xuất thay cho v2.

Vì sao đúng

Đây chính là lý do Vertex AI Model Registry tồn tại: giữ mọi phiên bản mô hình cùng chỉ số đánh giá của chúng, để quay lui là một thao tác triển khai lại chứ không phải huấn luyện lại.

⚠ Quy trình quay lui đúng — ba bước:

1. Mở Model Registry
     → thấy v1 và v2 cùng nằm dưới
       một MODEL, khác VERSION
        ↓
2. Xem chỉ số đánh giá của v1
     → ⚠ XÁC NHẬN bằng số liệu,
       không quay lui theo cảm tính
        ↓
3. Triển khai v1 lên endpoint
     → endpoint giữ nguyên,
       chỉ đổi mô hình đứng sau
        ↓
    ⚠ URL endpoint KHÔNG đổi
    ⚠ Ứng dụng gọi không phải sửa gì
    ⚠ v2 vẫn còn trong registry để mổ xẻ

⚠ Vì sao endpoint tách rời khỏi mô hình:

        ENDPOINT (địa chỉ ổn định)
              │
      ┌───────┴───────┐
     v1              v2
   80% traffic    20% traffic
        ↓
    ⚠ Một endpoint có thể phục vụ
      NHIỀU mô hình cùng lúc
    ⚠ Chia lưu lượng theo phần trăm
      → canary, A/B, quay lui dần
        ↓
    Quay lui = đưa v1 về 100%

⚠ Vì sao KHÔNG xoá v2:

Xoá v2
    → mất mô hình để điều tra
    → mất chỉ số so sánh
    → ⚠ endpoint KHÔNG tự quay về v1
      → mất luôn dịch vụ
        ↓
    Đúng: HẠ v2 khỏi endpoint,
          GIỮ nó trong registry

Xem thêm #13134 và #13138 (cùng lô này) — cùng chủ đề quay lui và triển khai mô hình, khoá đáp án nhất quán với câu này: luôn triển khai lại phiên bản cũ từ Model Registry.

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

• C (xoá v2, endpoint tự quay về v1) — đây là phương án gần nhất và cũng là bẫy nguy hiểm nhất: endpoint KHÔNG tự động quay lui. Xoá mô hình đang được triển khai sẽ làm hỏng endpoint, và bạn còn mất luôn v2 để phân tích nguyên nhân.

• B (huấn luyện lại v2 ngay trên endpoint sản xuất) — endpoint chỉ phục vụ suy luận, không huấn luyện được. Và huấn luyện lại mất hàng giờ trong khi người dùng đang chịu mô hình kém.

• D (tạo mô hình BigQuery ML mới rồi triển khai ngay) — đưa một mô hình chưa hề được đánh giá vào sản xuất giữa lúc đang sự cố. Vi phạm mọi nguyên tắc MLOps.

Ghi nhớ

⚠ Vertex AI Model Registry — bảng phải thuộc: | Khái niệm | Nội dung | |---|---| | Model | thùng chứa logic cho nhiều phiên bản | | Version | v1, v2, v3… mỗi lần huấn luyện lại | | Alias | nhãn di động: default, production, champion | | Endpoint | địa chỉ phục vụ, TÁCH RỜI khỏi mô hình | | Traffic split | chia % lưu lượng giữa các phiên bản | | ⚠ Ghi nhớ | quay lui = triển khai lại, KHÔNG phải xoá |

Từ khoá nhận diện:

"quay lui về phiên bản trước" → triển khai lại từ Model Registry "thử phiên bản mới trên ít người dùng" → traffic split / canary "độ chính xác tụt dần theo thời gian" → Vertex AI Model Monitoring "cần biết mô hình huấn luyện từ dữ liệu nào" → lineage / metadata

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Endpoint đang chạy phiên bản nào | gcloud ai endpoints describe | | Lưu lượng chia thế nào | trafficSplit trong cùng lệnh trên | | Chất lượng đã hồi chưa | Model Monitoring và chỉ số nghiệp vụ |

Và một thói quen đáng có sau mỗi lần quay lui: giữ nguyên v2 trong registry và ghi lại lý do. Mô hình kém đi thường không phải lỗi của mô hình mà là lỗi của dữ liệu vào — nếu xoá nó đi, lần sau bạn sẽ huấn luyện lại đúng con đường đã sai mà không biết mình đang lặp lại.

Đáp án

B — Pipeline Dataflow tuỳ biến dùng BigQuery Storage Write API.

Vì sao đúng

Đề nêu ba yêu cầu cùng lúc — và chỉ Storage Write API qua Dataflow đáp ứng đủ:

⚠ Ba yêu cầu, ba lời đáp:

1. THÔNG LƯỢNG CAO NHẤT
     → Storage Write API là API ghi
       thế hệ mới, gRPC, luồng liên tục
     → nhanh hơn hẳn legacy streaming insert

2. GIAO ĐÚNG-MỘT-LẦN (exactly-once)
     → Storage Write API có
       stream offset + commit
     → Dataflow phối hợp để không
       trùng, không mất

3. THỨ TỰ NGHIÊM NGẶT
     → Pub/Sub ordering key giữ thứ tự
     → ⚠ Dataflow có thể ghi theo
       stream committed giữ nguyên
       thứ tự trong từng khoá

⚠ Vì sao subscription "Write to BigQuery" có sẵn không đủ:

Managed BigQuery subscription
    ưu: KHÔNG cần viết mã, rẻ nhất
        ↓
    ⚠ nhưng KHÔNG bảo đảm thứ tự
      nghiêm ngặt xuyên suốt
    ⚠ và KHÔNG biến đổi được dữ liệu
        ↓
    → hợp khi yêu cầu là ÍT VẬN HÀNH
    → không hợp khi yêu cầu là
      THỨ TỰ + THÔNG LƯỢNG TỐI ĐA

⚠ Đối chiếu quan trọng — #13090 (lô 137) hỏi gần giống nhưng khoá managed subscription + dead-letter topic, vì ở đó yêu cầu là ít vận hành nhất, đơn giản nhất. Ở câu này yêu cầu là thứ tự nghiêm ngặt và thông lượng cao nhất, nên khoá là Dataflow + Storage Write API. Hai câu KHÔNG mâu thuẫn — chúng khác nhau ở tiêu chí tối ưu.

Cách đọc đề để không nhầm: tìm cụm chỉ tiêu chí — "ít mã nhất / ít vận hành nhất" → managed subscription; "thông lượng cao nhất / exactly-once / thứ tự / cần biến đổi" → Dataflow.

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

• A (managed subscription + dead-letter topic) — phương án gần nhất, và đúng cho một đề khác: khi tiêu chí là đơn giản và ít vận hành. Dead-letter topic xử lý thông điệp hỏng, không liên quan gì tới thứ tự hay thông lượng.

• C (script định kỳ chạy LOAD DATA theo lô nhỏ) — đây là xử lý theo lô, không phải luồng. Độ trễ tính bằng phút, và LOAD DATA có hạn ngạch số lần nạp mỗi bảng mỗi ngày.

• D (bảng ngoài trỏ vào file trên Cloud Storage) — dữ liệu không thực sự được nạp vào BigQuery; truy vấn chậm hơn, không có phân vùng và cụm hiệu quả, và không có bảo đảm exactly-once nào.

Ghi nhớ

⚠ Bốn cách đưa dữ liệu vào BigQuery — bảng phải thuộc: | Cách | Dùng khi | |---|---| | Managed Pub/Sub → BigQuery subscription | đơn giản nhất, không viết mã, không biến đổi | | Dataflow + Storage Write API | cần BIẾN ĐỔI, exactly-once, thông lượng cao | | LOAD DATA / batch load | theo lô, MIỄN PHÍ, có hạn ngạch số lần | | Bảng ngoài / BigLake | truy vấn tại chỗ, không sao chép | | Datastream | thay đổi từ CSDL quan hệ (CDC) |

Từ khoá nhận diện:

"ít vận hành nhất, không viết mã" → managed subscription "exactly-once + thứ tự + thông lượng cao" → Dataflow + Storage Write API "cần làm giàu / gộp cửa sổ trước khi ghi" → Dataflow "nạp mỗi đêm, tiết kiệm" → batch load, miễn phí

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bị dồn ứ không | metric num_undelivered_messages | | Pipeline có theo kịp không | System lag và Data freshness của Dataflow | | Có bản ghi trùng không | COUNT(*) so với COUNT(DISTINCT event_id) |

Và một lời nhắc khi làm bài với những câu hỏi nạp dữ liệu gần giống nhau: đọc câu cuối của đề trước khi nhìn phương án. Cùng một kiến trúc Pub/Sub → BigQuery có ít nhất ba đáp án đúng khác nhau, và thứ quyết định luôn là cụm từ nêu tiêu chí — đơn giản nhất, rẻ nhất, hay thông lượng và chính xác nhất.

Đáp án

B — Cloud Monitoring, với chỉ số subscription/num_undelivered_messages.

Vì sao đúng

"Dồn ứ thông điệp chưa giao được" trong Pub/Sub có đúng một chỉ số đo trực tiếp, và Cloud Monitoring là nơi đặt cảnh báo trên chỉ số đó.

⚠ Chỉ số nói đúng điều đề hỏi:

subscription/num_undelivered_messages
        ↓
    = số thông điệp ĐÃ ĐẾN subscription
      nhưng CHƯA được subscriber
      xác nhận (ack)
        ↓
    Số này TĂNG DẦN nghĩa là:
      - subscriber chết, hoặc
      - subscriber chậm hơn publisher
        ↓
    ⚠ Đây chính là định nghĩa "backlog"

⚠ Đường đi tới PagerDuty:

Pub/Sub tự phát metric
        ↓
Cloud Monitoring — Alerting policy
  điều kiện: num_undelivered_messages
             > 10.000 trong 5 phút
        ↓
Notification channel
        ↓
   ┌────────┴────────┐
PagerDuty        Webhook/Email/Slack
        ↓
    ⚠ PagerDuty là kênh thông báo
      có sẵn — chỉ cần dán
      integration key

⚠ Vì sao ba cách kia sai về bản chất:

CLOUD SCHEDULER + script hỏi định kỳ
    → tự dựng lại thứ Monitoring đã có
    → ⚠ script chết thì mất luôn cảnh báo
    → chính là "ai canh người canh gác"

DEAD-LETTER TOPIC
    → nơi CHỨA thông điệp thất bại
    → ⚠ KHÔNG phát cảnh báo được
    → và nó bắt lỗi TỪNG thông điệp,
      không phải tình trạng dồn ứ

LOG-BASED METRIC trên lỗi giao
    → chỉ thấy khi có DÒNG LOG lỗi
    → ⚠ subscriber CHẾT HẲN thì
      không sinh log nào cả
    → backlog phình mà log im lặng

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

• D (Cloud Logging, log-based metric trên lỗi giao) — phương án gần nhất và là bẫy tinh vi: nó chỉ bắt được lỗi có ghi log. Trường hợp nguy hiểm nhất — subscriber ngừng hẳn, không kéo thông điệp nào — không sinh dòng log nào, nên cảnh báo im lặng đúng lúc cần nhất.

• A (Cloud Scheduler chạy script hỏi trạng thái) — dựng lại bằng tay thứ Monitoring đã làm sẵn, thêm một điểm hỏng, và không có cảnh báo khi chính script chết.

• C (dead-letter topic để kích hoạt cảnh báo) — dead-letter topic là nơi chứa thông điệp giao thất bại quá số lần, không phải cơ chế cảnh báo. Muốn biết nó có gì thì… lại phải đặt cảnh báo Cloud Monitoring trên nó.

Ghi nhớ

⚠ Các chỉ số Pub/Sub phải thuộc: | Chỉ số | Ý nghĩa | |---|---| | subscription/num_undelivered_messages | số thông điệp tồn đọng — quan trọng nhất | | subscription/oldest_unacked_message_age | tuổi thông điệp cũ nhất chưa ack — cảnh báo cùng cặp | | topic/send_request_count | tốc độ publish | | subscription/pull_ack_message_count | tốc độ tiêu thụ | | subscription/dead_letter_message_count | số thông điệp rơi vào dead-letter | | ⚠ Thực hành | cảnh báo trên CẢ hai chỉ số đầu |

Từ khoá nhận diện:

"dồn ứ, backlog, chưa xử lý kịp" → num_undelivered_messages "dữ liệu bị cũ, trễ quá lâu" → oldest_unacked_message_age "thông điệp hỏng lặp mãi" → dead-letter topic "cảnh báo ra PagerDuty/Slack" → Cloud Monitoring notification channel

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Backlog hiện bao nhiêu | Metrics Explorer, chỉ số trên | | Cảnh báo có bắn không | tạm hạ ngưỡng để thử | | PagerDuty có nhận không | nút "Send test notification" |

Và một điều nên làm ngay khi tạo bất kỳ subscription quan trọng nào: đặt cảnh báo cùng lúc với việc tạo subscription, đừng để tới lúc gặp sự cố đầu tiên mới nhớ ra. Backlog là loại lỗi âm thầm — hệ thống trông vẫn "chạy", chỉ có dữ liệu là ngày một cũ đi.

Đáp án

D — Cloud Workflows.

Vì sao đúng

Đề nêu đúng bốn đặc điểm của Cloud Workflows: serverless, DAG khai báo bằng YAML/JSON, gọi REST API là việc gốc, và thử lại tự động khi lỗi tạm thời.

⚠ Một workflow ba bước trông như thế này:

main:
  steps:
    - buoc1:
        call: http.get
        args:
          url: https://api-a.example.com/data
        result: kq1
    - buoc2:
        call: http.post
        args:
          url: https://api-b.example.com/xu-ly
          body:
            input: ${kq1.body.id}
        result: kq2
    - buoc3:
        call: http.post
        args:
          url: https://api-c.example.com/luu
          body: ${kq2.body}

        ↓
    ⚠ Dữ liệu chuyền qua biến ${...}
    ⚠ Không có máy chủ nào phải quản
    ⚠ Trả tiền theo SỐ BƯỚC chạy

⚠ Thử lại tự động — đúng thứ đề đòi:

- goi_api:
    try:
      call: http.get
      args: {url: "..."}
    retry:
      predicate: ${http.default_retry_predicate}
      max_retries: 5
      backoff:
        initial_delay: 1
        max_delay: 60
        multiplier: 2

        ↓
    ⚠ Có sẵn predicate cho lỗi TẠM THỜI
      (429, 502, 503, 504, timeout)
    ⚠ Lùi theo cấp số nhân — không cần tự viết

⚠ Vì sao Cloud Composer là quá nặng ở đây:

CLOUD COMPOSER (Airflow có quản lý)
    → mạnh, nhiều operator, có UI DAG
        ↓
    ⚠ nhưng chạy trên CỤM GKE THƯỜNG TRỰC
    ⚠ tốn hàng trăm đô mỗi tháng
      DÙ KHÔNG CHẠY GÌ
        ↓
    Đề nói "NHẸ NHÀNG NHẤT"
        ↓
    → Workflows: trả tiền theo bước,
      không chạy thì gần như 0 đồng

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

• A (Cloud Composer) — đây là phương án gần nhất về mặt "điều phối DAG", nhưng nó không nhẹ: môi trường Airflow chạy thường trực, tốn tiền cả khi rảnh, và cần hiểu Airflow. Composer đáng dùng khi có hàng chục pipeline dữ liệu phức tạp, không phải cho ba lời gọi REST nối tiếp.

• B (Cloud Functions) — có thể viết mã để gọi ba API, nhưng khi đó bạn tự cài đặt điều phối, thử lại và truyền trạng thái. Và hàm có giới hạn thời gian chạy. Đề đòi "điều phối", không đòi "viết một hàm làm mọi thứ".

• C (Cloud Scheduler) — chỉ là cron trên đám mây: kích hoạt một đích theo lịch. Nó không có khái niệm bước, nhánh, hay truyền dữ liệu. Thường được dùng để khởi động một workflow chứ không thay thế nó.

Ghi nhớ

⚠ Bốn công cụ điều phối trên Google Cloud — bảng phải thuộc: | Công cụ | Dùng khi | |---|---| | Cloud Workflows | chuỗi lời gọi API, serverless, nhẹ, trả theo bước | | Cloud Composer | pipeline dữ liệu phức tạp, hệ sinh thái Airflow, có UI | | Cloud Scheduler | chỉ kích hoạt theo lịch — cron | | Cloud Tasks | hàng đợi tác vụ bất đồng bộ, kiểm soát tốc độ | | Eventarc | định tuyến sự kiện tới đích |

Từ khoá nhận diện:

"nhẹ nhất, gọi REST API, serverless" → Cloud Workflows "DAG dữ liệu phức tạp, Airflow, nhiều operator" → Cloud Composer "chạy lúc 2 giờ sáng hằng ngày" → Cloud Scheduler "phản ứng khi file được tải lên" → Eventarc "hàng đợi, giới hạn tốc độ gửi" → Cloud Tasks

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Workflow chạy tới bước nào | tab Executions — xem từng bước | | Bước nào lỗi | log thực thi kèm mã trạng thái | | Tốn bao nhiêu | đếm số bước — giá theo bước, có hạn mức miễn phí |

Và một mẹo thiết kế đáng nhớ với Workflows: đừng chuyền dữ liệu lớn qua biến giữa các bước. Giới hạn 512 KB đến rất nhanh khi một API trả về JSON dài; cách đúng là ghi kết quả xuống Cloud Storage hoặc BigQuery rồi chuyền đường dẫn, để workflow chỉ làm đúng việc điều phối.

Đáp án

C — Bảng BigLake ở Project A, chia sẻ sang Project B và quản trị bằng policy tag.

Vì sao đúng

Đề đòi ba thứ cùng lúc, và BigLake + policy tag là tổ hợp duy nhất làm đủ:

⚠ Ba yêu cầu, ba lời đáp:

1. TRUY VẤN TẠI CHỖ, KHÔNG SAO CHÉP
     → BigLake đọc thẳng file Parquet
       trên Cloud Storage

2. XUYÊN DỰ ÁN
     → nhà phân tích ở Project B
       KHÔNG cần quyền vào bucket
     → ⚠ BigLake dùng CONNECTION
       có service account riêng

3. CHE CỘT PII
     → policy tag gắn lên cột `email`
     → Data Catalog quản lý phân cấp thẻ

⚠ Điểm mấu chốt — uỷ quyền qua connection:

Nhà phân tích (Project B)
        ↓ truy vấn bảng BigLake
BigQuery
        ↓ dùng SERVICE ACCOUNT
          của BigLake connection
Cloud Storage (Project A)
        ↓
    ⚠ Chỉ service account đó
      có quyền đọc bucket
    ⚠ Nhà phân tích KHÔNG hề
      có quyền vào Cloud Storage
        ↓
    → không thể lách qua BigQuery
      để tải thẳng file về

⚠ Policy tag hoạt động ra sao:

Cột `email`  ←gắn→  policy tag "PII/Email"
        ↓
    Ai có vai `Fine-Grained Reader`
    trên thẻ đó → thấy giá trị thật
        ↓
    Ai KHÔNG có → ⚠ bị TỪ CHỐI truy cập cột
      hoặc thấy giá trị đã CHE
      (nếu bật data masking)
        ↓
    ⚠ Áp ở tầng BigQuery,
      không phải ở tầng ứng dụng
      → mọi công cụ đều bị chặn như nhau

Xem thêm #13132 (cùng lô này) — về Data Catalog và policy tag; câu này là ứng dụng của cùng cơ chế cho tình huống xuyên dự án.

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

• B (bảng ngoài thường + authorized view) — phương án gần nhất. Authorized view có cho phép chia sẻ mà không cấp quyền bảng gốc, nhưng bảng ngoài THƯỜNG không có lớp uỷ quyền của BigLake: người truy vấn vẫn phải có quyền đọc bucket Cloud Storage, đúng thứ chính sách cấm. Và authorized view che theo cột bằng cách viết lại SQL, không phải quản trị tập trung bằng thẻ.

• A (Storage Transfer Service sao chép hằng ngày) — vi phạm ngay yêu cầu "tại chỗ, không sao chép", tạo thêm một bản dữ liệu nhạy cảm phải bảo vệ, và dữ liệu luôn cũ một ngày.

• D (cấp IAM thẳng vào bucket) — cấp quyền vào bucket là cấp toàn bộ file, không có cách nào che một cột trong file Parquet ở tầng Cloud Storage. Ngược hoàn toàn với chính sách.

Ghi nhớ

⚠ Ba loại bảng trong BigQuery — bảng phải thuộc: | Loại | Đặc điểm | |---|---| | Bảng gốc (native) | dữ liệu nằm trong BigQuery, nhanh nhất | | Bảng ngoài (external) | đọc file ngoài, người dùng CẦN quyền vào kho | | BigLake | đọc file ngoài + UỶ QUYỀN qua connection + bảo mật mức cột/dòng |

Từ khoá nhận diện:

"tại chỗ + phân quyền mịn + không cho vào bucket" → BigLake "che cột nhạy cảm tập trung" → policy tag (Data Catalog / Dataplex) "lọc theo dòng cho từng nhóm" → row-level security "chia sẻ dữ liệu cho tổ chức khác" → Analytics Hub "tìm và phân loại PII tự động" → Sensitive Data Protection

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng B có bị chặn cột không | đăng nhập bằng chính tài khoản đó rồi SELECT email | | Connection dùng service account nào | bq show --connection | | Ai đã đọc dữ liệu nhạy cảm | Cloud Audit Logs — Data Access |

Và một điều luôn đáng làm sau khi dựng xong lớp bảo vệ này: tự mình thử với đúng tài khoản của người dùng cuối. Cấu hình policy tag rất dễ trông có vẻ đúng trên giao diện trong khi người quản trị — vốn có sẵn mọi quyền — không bao giờ chạm phải rào chắn mà mình vừa dựng.

Đáp án

B — Bigtable.

Vì sao đúng

Đề liệt kê bốn đặc điểm, và cả bốn đều là mô tả sách giáo khoa của Bigtable:

⚠ Bốn đặc điểm ↔ Bigtable:

1. HÀNG TRIỆU LƯỢT GHI MỖI GIÂY
     → Bigtable mở rộng ngang tuyến tính
     → thêm node = thêm thông lượng

2. ĐỌC DƯỚI 10 MILI-GIÂY (p99)
     → thiết kế đúng khoá dòng
       → đọc một dòng gần như tức thời

3. MÔ HÌNH WIDE-COLUMN, BÁN CẤU TRÚC
     → ⚠ đây là ĐỊNH NGHĨA của Bigtable
     → mỗi dòng có thể có tập cột khác nhau

4. DỮ LIỆU SỰ KIỆN QUY MÔ LỚN
     → quảng cáo, IoT, tài chính, chuỗi thời gian
     → đúng nhóm ca sử dụng chuẩn

⚠ Vì sao đấu giá thời gian thực (RTB) chọn Bigtable:

Yêu cầu đấu giá tới
        ↓
    ⚠ Phải trả lời trong ~100ms TỔNG
      → phần tra hồ sơ người dùng
        chỉ được vài mili-giây
        ↓
Bigtable: đọc theo row key
        ↓
    row key = user_id
        ↓
    ⚠ Một lượt tìm, không join,
      không quét
        ↓
    → dưới 10ms, ở quy mô hàng tỉ dòng

⚠ Khoá dòng quyết định tất cả:

     SAI                     ĐÚNG
timestamp_userid      userid_reversed#timestamp
        ↓                       ↓
mọi lượt ghi dồn         ghi trải đều
vào CUỐI bảng            khắp các node
        ↓                       ↓
⚠ HOTSPOT               ⚠ mở rộng thật sự
thêm node vô ích

⚠ Đối chiếu #13141 (cùng lô này) — đề đó cũng nói "mở rộng ngang toàn cầu" nhưng khoá Spanner, vì nó đòi giao dịch ACID nhất quán mạnh cho hệ thanh toán. Câu này không đòi giao dịch nhiều dòng, mà đòi thông lượng và độ trễ. Hai khoá khác nhau là đúng — chúng khác ở yêu cầu giao dịch.

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

• C (Spanner) — cũng mở rộng ngang, nhưng sinh ra cho giao dịch quan hệ ACID toàn cầu. Ghi hàng triệu sự kiện mỗi giây bằng Spanner đắt hơn nhiều lần và không tận dụng gì ưu điểm của nó. Đề không nhắc tới giao dịch.

• A (BigQuery) — kho phân tích. Rất hợp để phân tích dữ liệu quảng cáo sau này, nhưng độ trễ truy vấn tính bằng giây, không phải mili-giây, và không chịu nổi tốc độ ghi từng bản ghi như vậy.

• D (Firestore) — NoSQL kiểu tài liệu, mạnh về đồng bộ thời gian thực cho ứng dụng di động và web. Không phải wide-column, và không đạt quy mô hàng triệu ghi mỗi giây như đề nêu.

Ghi nhớ

⚠ Bigtable — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Mô hình | NoSQL wide-column, thưa | | Khoá | DUY NHẤT một row key — không có khoá phụ | | Độ trễ | một chữ số mili-giây | | Quy mô | hàng petabyte, hàng triệu ghi/giây | | Giao dịch | CHỈ trong một dòng | | Giao diện | HBase API, gRPC | | Không có | SQL đầy đủ, join, khoá phụ |

Từ khoá nhận diện:

"chuỗi thời gian, IoT, quảng cáo, độ trễ mili-giây, wide-column" → Bigtable "giao dịch toàn cầu, ACID, SQL" → Spanner "ứng dụng di động, đồng bộ ngoại tuyến, tài liệu" → Firestore "báo cáo, phân tích, quét hàng tỉ dòng" → BigQuery "MySQL/PostgreSQL có sẵn" → Cloud SQL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có hotspot không | Key Visualizer — nhìn vệt sáng dọc | | CPU có quá tải không | giữ dưới 70% | | Độ trễ p99 bao nhiêu | metric server/latencies trong Cloud Monitoring |

Và một kiến trúc rất hay gặp mà đề thi thích hỏi: Bigtable phục vụ đọc nóng, BigQuery phục vụ phân tích nguội. Hai hệ thống này không cạnh tranh nhau — dữ liệu sự kiện thường được ghi vào cả hai, và chọn sai chỗ để đặt câu hỏi mới là lỗi kiến trúc, chứ không phải chọn sai cơ sở dữ liệu.

Đáp án

D — Trong một ParDo tuỳ biến áp lên PCollection.

Vì sao đúng

Trong mô hình Apache Beam mà Dataflow chạy, mọi logic biến đổi dữ liệu đều nằm ở tầng transform, và ParDo là transform tổng quát nhất để xử lý từng phần tử.

⚠ Ba tầng của một pipeline Beam:

    SOURCE (đọc)
        ↓  PCollection<dữ liệu thô>
    TRANSFORM  ← ⚠ LOGIC NGHIỆP VỤ Ở ĐÂY
        ↓  PCollection<dữ liệu đã đổi>
    SINK (ghi)

    Source: chỉ ĐỌC và giải mã
    Sink:   chỉ GHI ra đích
    ⚠ Cả hai KHÔNG phải chỗ đặt
      logic nghiệp vụ

⚠ ParDo cho bài toán đổi độ C sang độ F:

class DoiSangF(beam.DoFn):
    def process(self, phan_tu):
        c = phan_tu['temperature_celsius']
        phan_tu['temperature_fahrenheit'] = c * 9 / 5 + 32
        yield phan_tu

(p
 | 'Doc'    >> beam.io.ReadFromPubSub(topic=TOPIC)
 | 'Parse'  >> beam.Map(json.loads)
 | 'DoiF'   >> beam.ParDo(DoiSangF())
 | 'Ghi'    >> beam.io.WriteToBigQuery(BANG))

        ↓
    ⚠ Chạy SONG SONG trên mọi worker
    ⚠ Tự mở rộng theo lượng dữ liệu
    ⚠ Cùng một mã dùng được cho
      cả luồng lẫn lô

⚠ Vì sao KHÔNG dùng Cloud Function sau khi xử lý xong:

Dataflow → BigQuery → Cloud Function sửa lại
        ↓
    ⚠ Dữ liệu SAI đã nằm trong kho
      trong khoảng thời gian trung gian
    ⚠ Thêm một hệ thống phải vận hành
    ⚠ Không mở rộng bằng Dataflow
    ⚠ Mất tính exactly-once
        ↓
    → Biến đổi phải ở TRONG pipeline

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

• C (trong source connector đọc từ Pub/Sub) — phương án gần nhất về mặt "làm sớm", nhưng source connector là mã có sẵn của Beam, việc của nó là đọc và giải mã, không phải chỗ nhét logic nghiệp vụ. Sửa nó là làm mã khó đọc và khó kiểm thử.

• B (trong sink connector ghi vào BigQuery) — cùng lý do: sink chỉ ghi. Đặt logic ở đó thì không thể tái dùng khi thêm một đích thứ hai.

• A (Cloud Function sửa dữ liệu sau khi xử lý) — kiến trúc sai: dữ liệu chưa đúng đã được ghi ra, rồi sửa sau. Thêm độ trễ, thêm chi phí, thêm chỗ hỏng.

Ghi nhớ

⚠ Các transform cốt lõi của Beam — bảng phải thuộc: | Transform | Việc | |---|---| | ParDo | xử lý từng phần tử — TỔNG QUÁT nhất, ra 0..n kết quả | | Map | 1 vào → 1 ra, dạng rút gọn của ParDo | | FlatMap | 1 vào → nhiều ra | | Filter | giữ phần tử thoả điều kiện | | GroupByKey | gom theo khoá | | Combine | tổng hợp (sum, mean, count) | | CoGroupByKey | join nhiều PCollection | | Window | chia luồng theo cửa sổ thời gian |

Từ khoá nhận diện:

"biến đổi từng bản ghi" → ParDo / Map "một bản ghi tách thành nhiều" → FlatMap "tổng hợp theo khoá" → GroupByKey + Combine "gộp hai luồng" → CoGroupByKey hoặc side input "bản ghi hỏng đừng làm gãy pipeline" → dead-letter qua output có thẻ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bước nào chậm | đồ thị pipeline trong console, xem wall time từng bước | | Có bản ghi hỏng không | đếm dòng ở bảng dead-letter | | Dữ liệu có tươi không | Data freshness và System lag |

Và một nguyên tắc kiến trúc đáng mang theo ra ngoài phòng thi: dữ liệu nên đúng trước khi được ghi xuống, không phải sau đó. Mọi phương án kiểu "ghi ra rồi sửa lại" đều tạo ra một khoảng thời gian mà kho dữ liệu chứa giá trị sai — và trong khoảng đó, ai đó đã kịp chạy báo cáo.

Đáp án

C — Vertex AI AutoML.

Vì sao đúng

Đề nêu rõ ràng: người dùng là chuyên viên nghiệp vụ, KHÔNG viết được Python hay SQL, và cần giao diện web đơn giản để tải dữ liệu lên và huấn luyện. Đó chính xác là đối tượng AutoML nhắm tới.

⚠ Quy trình AutoML — không một dòng mã:

1. Tạo Dataset trong console
     → chọn kiểu: Text classification
2. Tải file lên (CSV / JSONL)
     → hoặc trỏ vào Cloud Storage
3. Gán nhãn hoặc dùng nhãn có sẵn
4. Bấm "Train new model"
     → chọn ngân sách giờ huấn luyện
5. AutoML tự:
     - chọn kiến trúc mô hình
     - tinh chỉnh siêu tham số
     - chia tập train/valid/test
6. Xem trang đánh giá:
     precision, recall, ma trận nhầm lẫn
7. Bấm "Deploy" → có endpoint
        ↓
    ⚠ Toàn bộ bằng CHUỘT

⚠ Vì sao ba phương án kia đòi lập trình:

VERTEX AI WORKBENCH
    → notebook Jupyter
    → ⚠ phải viết PYTHON

BIGQUERY ML
    → ⚠ phải viết SQL:
      CREATE MODEL ... OPTIONS(...)
    → dù đơn giản hơn Python,
      vẫn là VIẾT MÃ

DATAFLOW
    → ⚠ phải viết Apache Beam
    → và nó KHÔNG huấn luyện mô hình

⚠ Đọc kỹ đề — hai chi tiết loại trừ:

"business analysts"
"no experience writing code in Python OR SQL"
        ↓
    ⚠ Chữ "OR SQL" cố tình
      loại BigQuery ML
        ↓
"simple, WEB-BASED GRAPHICAL interface"
        ↓
    ⚠ Chỉ AutoML có

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

• D (BigQuery ML) — phương án gần nhất và là bẫy chính. BigQuery ML thật sự đơn giản và rất hợp với nhà phân tích… biết SQL. Nhưng đề nói thẳng là nhóm này không biết SQL, nên nó bị loại bởi chính câu chữ của đề.

• A (Vertex AI Workbench) — môi trường notebook, dành cho nhà khoa học dữ liệu viết Python. Linh hoạt nhất nhưng đòi kỹ năng lập trình.

• B (Dataflow) — công cụ xử lý dữ liệu, không phải công cụ huấn luyện mô hình. Sai hẳn hạng mục.

Ghi nhớ

⚠ Chọn công cụ ML theo kỹ năng người dùng — bảng phải thuộc: | Người dùng | Công cụ | |---|---| | Không viết mã | Vertex AI AutoML | | Biết SQL, dữ liệu đã ở BigQuery | BigQuery ML | | Biết Python, cần kiểm soát đầy đủ | Vertex AI custom training / Workbench | | Chỉ cần dùng mô hình có sẵn | API dựng sẵn (Vision, NLP, Translation) | | Cần mô hình sinh | Vertex AI Model Garden / Gemini |

Từ khoá nhận diện:

"không biết lập trình, giao diện đồ hoạ" → AutoML "nhà phân tích biết SQL" → BigQuery ML "cần tuỳ biến kiến trúc, viết Python" → custom training "nhận dạng vật thể ảnh thông thường, không cần huấn luyện" → Vision API "phân loại email chuyên ngành riêng" → AutoML text

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình tốt tới đâu | trang Evaluate — precision, recall theo từng nhãn | | Nhãn nào yếu | ma trận nhầm lẫn — thu thập thêm dữ liệu cho nhãn đó | | Tốn bao nhiêu | giờ node huấn luyện + giờ endpoint đang triển khai |

Và một lời nhắc thực tế về chi phí mà nhiều người quên: endpoint đã triển khai vẫn tính tiền kể cả khi không ai gọi. Sau khi thử nghiệm xong, nếu chưa dùng thật thì hãy hạ mô hình khỏi endpoint — mô hình vẫn nằm nguyên trong Model Registry và triển khai lại bất cứ lúc nào.

Đáp án

D — Trước hết dùng Cloud Monitoring để tạo cảnh báo và xem biểu đồ; sau đó dùng Cloud Logging để đọc log lỗi chi tiết.

Vì sao đúng

Hai dịch vụ này chia việc rất rõ ràng, và đề mô tả đúng trình tự chuẩn của một cuộc điều tra sự cố.

⚠ Ranh giới giữa hai dịch vụ:

CLOUD MONITORING
    → làm việc với SỐ theo thời gian
    → metric, biểu đồ, dashboard, SLO
    → ⚠ trả lời câu hỏi "CÓ CHUYỆN GÌ
      ĐANG XẢY RA KHÔNG?"

CLOUD LOGGING
    → làm việc với SỰ KIỆN dạng văn bản
    → log có cấu trúc, tra cứu, lọc
    → ⚠ trả lời câu hỏi "VÌ SAO
      NÓ XẢY RA?"

⚠ Dòng chảy một cuộc điều tra:

num_undelivered_messages tăng 15 phút
        ↓
Cloud Monitoring bắn cảnh báo   ← PHÁT HIỆN
        ↓
Nhìn dashboard: tăng từ lúc nào,
tăng đột ngột hay dần dần?      ← KHOANH VÙNG
        ↓
Chuyển sang Cloud Logging       ← ⚠ CHẨN ĐOÁN
    lọc theo subscription và mức ERROR
        ↓
Thấy: "Deadline exceeded" /
      "permission denied" /
      ngoại lệ trong subscriber
        ↓
    → biết NGUYÊN NHÂN

⚠ Vì sao không thể đảo ngược thứ tự:

LOGGING KHÔNG PHẢI CHỖ ĐẶT CẢNH BÁO GỐC
    → nó không có metric có sẵn
      như num_undelivered_messages
    → ⚠ subscriber chết hẳn thì
      KHÔNG sinh log nào,
      cảnh báo dựa vào log sẽ IM LẶNG

MONITORING KHÔNG PHẢI CHỖ ĐỌC LỖI
    → nó chỉ có SỐ, không có
      thông báo ngoại lệ
    → ⚠ biết backlog = 50.000
      nhưng không biết vì sao

Bổ sung cho câu #13144 (cùng lô này): câu đó hỏi đặt cảnh báo ở đâu (Cloud Monitoring, chỉ số num_undelivered_messages); câu này hỏi điều tra tiếp ở đâu (Cloud Logging). Hai câu nhất quán và ghép thành một quy trình đầy đủ.

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

• A (Cloud Monitoring cho cả hai việc) — phương án gần nhất, và đúng một nửa: Monitoring đúng cho cảnh báo, nhưng nó chỉ chứa chuỗi số, không chứa thông báo lỗi. Muốn thấy dòng lỗi phải sang Logging.

• B (Cloud Logging cho cả hai) — đảo ngược vai trò. Logging không có metric hệ thống dựng sẵn, và cảnh báo dựa trên log mù đúng lúc subscriber chết hẳn.

• C (Logging tạo cảnh báo, Monitoring tìm lỗi) — hoán đổi hoàn toàn hai vai. Sai ở cả hai vế.

Ghi nhớ

⚠ Bộ Cloud Operations — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Cloud Monitoring | metric, dashboard, cảnh báo, uptime check, SLO | | Cloud Logging | thu thập, lưu, TRA CỨU log | | Cloud Trace | theo dấu độ trễ qua nhiều dịch vụ | | Cloud Profiler | CPU và bộ nhớ trong ứng dụng | | Error Reporting | gom lỗi giống nhau thành nhóm |

Từ khoá nhận diện:

"cảnh báo khi vượt ngưỡng" → Cloud Monitoring "tìm thông báo lỗi cụ thể" → Cloud Logging "request chậm ở đâu trong chuỗi dịch vụ" → Cloud Trace "hàm nào ngốn CPU" → Cloud Profiler "ai đã xoá tài nguyên đó" → Cloud Audit Logs

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Backlog bắt đầu từ lúc nào | Metrics Explorer, kéo khung thời gian rộng ra | | Lỗi gì | Logs Explorer, cùng khung giờ, severity>=ERROR | | Đã hết chưa | xem metric quay về đường nền — đừng chỉ tin việc đã sửa |

Và một thói quen giúp rút ngắn mọi cuộc điều tra sau này: ghi runbook ngay vào phần mô tả của chính sách cảnh báo. Người trực lúc 3 giờ sáng không nên phải tự nhớ ra rằng bước tiếp theo là mở Logs Explorer với bộ lọc nào — câu đó nên nằm sẵn trong thông báo mà họ vừa nhận.