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

Đáp án

B — Regional.

Vì sao đúng

Đề nêu ba điều: cả nhà phân tích lẫn ứng dụng đều ở europe-west1, và mục tiêu là hiệu năng tốt nhất với chi phí thấp nhất. Khi người dùng tập trung ở một Region, đặt dữ liệu ngay tại đó là lựa chọn tối ưu.

⚠ Điểm mấu chốt — đặt dữ liệu cạnh nơi xử lý:

Bucket ở europe-west1
    + ứng dụng và phân tích cũng ở europe-west1
        ↓
    → độ trễ THẤP NHẤT
    → KHÔNG có phí truyền dữ liệu
      giữa các Region
    → giá lưu trữ RẺ NHẤT
        ↓
    ⚠ Ba lợi ích cùng lúc

⚠ Vì sao multi-region lại KÉM hơn ở đây:

Multi-region EU
        ↓
    ⚠ ĐẮT HƠN về giá lưu
    ⚠ Không cần thiết — người dùng
      chỉ ở một Region
    ⚠ Truy cập từ europe-west1 có thể
      không nhanh hơn regional tại chỗ
        ↓
    → trả tiền cho tính sẵn sàng
      mà đề không yêu cầu

⚠ Quy tắc chọn vị trí bucket:

Người dùng và ứng dụng ở MỘT Region
    → REGIONAL                      ← đề này

Cần chịu lỗi cả một Region
    → DUAL-REGION hoặc MULTI-REGION

Người dùng phân tán NHIỀU CHÂU LỤC
    → MULTI-REGION + CLOUD CDN

Dữ liệu phải ở trong một nước
    → REGION cụ thể + Organization Policy

Xem thêm câu #13119 (cùng lô): khoá Multi-region vì ở đó yêu cầu chịu được mất cả một Region. Hai khoá khác nhau vì yêu cầu khác nhau — hoàn toàn nhất quán. Và #12921 (lô 133): cùng khoá regional cho người dùng ở Úc. #12967 (lô 134): multi-region + CDN cho người dùng đa châu lục.

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

• D (multi-region) — đây là phương án gần nhất về mặt "an toàn hơn", nhưng nó đắt hơn và không cần thiết khi người dùng chỉ ở một Region; đề nhấn mạnh chi phí thấp nhất.

• A (dual-region) — cũng đắt hơn regional, và đề không yêu cầu chịu lỗi Region.

• C (zonal) — Cloud Storage KHÔNG có kiểu vị trí này.

Ghi nhớ

⚠ Chọn vị trí bucket theo phạm vi người dùng — bảng phải thuộc: | Người dùng ở | Chọn | |---|---| | Một Region | REGIONAL — rẻ nhất, nhanh nhất tại chỗ | | Hai Region cụ thể | dual-region | | Một châu lục | multi-region | | Nhiều châu lục | multi-region + Cloud CDN | | Cần chịu lỗi cả Region | dual-region hoặc multi-region | | ⚠ Bẫy | KHÔNG có kiểu "zonal" |

Từ khoá nhận diện:

"người dùng ở một Region, hiệu năng và chi phí" → regional "chịu được mất cả Region" → multi-region "nhiều châu lục" → multi-region + CDN "dữ liệu ở trong nước" → region cụ thể "zonal cho Cloud Storage" → KHÔNG TỒN TẠI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket ở đâu | gcloud storage buckets describe gs://b --format="value(location)" | | Có phí egress giữa Region không | billing export, tìm SKU network | | Độ trễ thực tế | đo từ chính ứng dụng |

Và một khoản chi phí rất hay xuất hiện bất ngờ trong hoá đơn khi vị trí không được đặt nhất quán: phí truyền dữ liệu giữa các Region. Một bucket ở multi-region EU và một job Dataflow ở europe-west1 vẫn chạy bình thường, nhưng mỗi byte đi qua ranh giới đó đều được tính tiền — và với dữ liệu phân tích hằng ngày, khoản đó tích luỹ nhanh hơn nhiều so với phần tiết kiệm được từ bất kỳ tối ưu nào khác.

Đáp án

C — Cloud Workflows.

Vì sao đúng

Đề nêu bốn điều: nối chuỗi vài lời gọi HTTP API bất biến, truyền kết quả từ bước này sang bước kia, tự thử lại, và — quan trọng nhất — KHÔNG phải quản lý hay cấp phát môi trường Apache Airflow. Cloud Workflows khớp cả bốn.

⚠ Điểm mấu chốt — điều phối nhẹ, không có môi trường thường trực:

Cloud Workflows
        ↓
    Khai bằng YAML hoặc JSON
        ↓
    - Gọi HTTP API tuần tự
    - TRUYỀN kết quả giữa các bước
    - THỬ LẠI có backoff
    - Rẽ nhánh, vòng lặp, xử lý lỗi
        ↓
    ⚠ KHÔNG có môi trường thường trực
    ⚠ Trả tiền theo SỐ BƯỚC thực hiện

⚠ Một workflow trông thế nào:

main:
  steps:
    - buoc1:
        call: http.post
        args:
          url: https://api-a.example.com/xu-ly
          auth: {type: OIDC}
        result: ket_qua_a
    - buoc2:
        call: http.post
        args:
          url: https://api-b.example.com/tiep
          body:
            du_lieu: ${ket_qua_a.body.id}
        result: ket_qua_b
    - tra_ve:
        return: ${ket_qua_b.body}

        ↓
    ⚠ `${ket_qua_a.body.id}` chính là
      TRUYỀN KẾT QUẢ giữa các bước

⚠ Vì sao Cloud Composer bị loại:

Cloud Composer = Apache Airflow được quản lý
        ↓
    ⚠ Vẫn phải TẠO và DUY TRÌ một
      MÔI TRƯỜNG thường trực
    ⚠ Chi phí nền đáng kể
        ↓
    Đề nói rõ: "KHÔNG cần quản lý
    hay cấp phát môi trường Airflow"
        ↓
    → loại bỏ tường minh

Xem thêm câu #13015 (lô 135), #12996 và #13003 (lô 135): khoá Cloud Composer vì ở đó luồng phức tạp, nhiều dịch vụ, cần backfill và DAG đầy đủ. Câu này là chuỗi vài lời gọi API nhẹ và loại trừ Airflow tường minh → Workflows. Bốn câu, hai khoá, phân biệt bằng ĐỘ PHỨC TẠP và ràng buộc trong đề — hoàn toàn nhất quán.

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

• B (Cloud Composer) — đây là phương án gần nhất và hoàn toàn làm được, nhưng đề loại trừ tường minh việc phải quản lý môi trường Airflow.

• D (Cloud Functions) — chạy một đoạn mã; nối chuỗi nhiều bước bằng hàm là tự viết lại logic điều phối (thử lại, truyền trạng thái, xử lý lỗi).

• A (Eventarc) — định tuyến SỰ KIỆN tới một đích, không phải bộ điều phối nhiều bước.

Ghi nhớ

⚠ Thang công cụ điều phối — từ nhẹ tới nặng: | Công cụ | Đặc điểm | |---|---| | Cloud Scheduler | một lời gọi theo giờ | | Eventarc | định tuyến một sự kiện tới một đích | | Cloud Workflows | chuỗi vài bước, YAML, KHÔNG có môi trường thường trực | | Cloud Composer | DAG đầy đủ, backfill, môi trường thường trực | | Dataform | chuỗi bước SQL trong BigQuery | | Dataproc Workflow Template | nhiều job trong Dataproc |

Từ khoá nhận diện:

"chuỗi API, truyền kết quả, không muốn Airflow" → Cloud Workflows "DAG phức tạp, nhiều dịch vụ, backfill" → Cloud Composer "một lời gọi theo giờ" → Cloud Scheduler "phản ứng theo sự kiện" → Eventarc "chỉ toàn SQL" → Dataform

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Workflow chạy tới bước nào | console → Workflows → Executions | | Biến truyền giữa các bước có đúng không | xem chi tiết từng bước trong execution | | Có bị thử lại nhiều lần không | log của execution |

Và một lý do rất thực tế khiến Workflows thường là lựa chọn đúng cho luồng nhỏ: nó không có gì để bỏ quên. Không có môi trường nào chạy 24/7, không có phiên bản Airflow phải nâng cấp, không có worker phải giám sát — chỉ có một tệp YAML và hoá đơn tính theo số bước thật sự chạy.

Đáp án

B — Một BigQuery subscription được quản lý của Pub/Sub, cấu hình kèm dead-letter topic và bật tiến hoá lược đồ.

Vì sao đúng

Đề nêu bốn yêu cầu, và cách này đáp ứng cả bốn mà không cần viết mã: ghi thẳng vào BigQuery, giảm tối đa công vận hành, tự thêm cột mới khi lược đồ đổi, và định tuyến thông điệp lỗi sang topic riêng.

⚠ Điểm mấu chốt — Pub/Sub tự ghi, không cần dịch vụ trung gian:

Pub/Sub topic
        ↓
    BIGQUERY SUBSCRIPTION
        ↓
    Pub/Sub TỰ ghi vào bảng
    bằng Storage Write API
        ↓
    ⚠ KHÔNG có Dataflow
    ⚠ KHÔNG có Cloud Function
    ⚠ KHÔNG có mã nào phải bảo trì

⚠ Hai tuỳ chọn giải quyết hai yêu cầu còn lại:

1. TIẾN HOÁ LƯỢC ĐỒ
   --use-topic-schema
   → dùng lược đồ của topic
   → cột mới trong lược đồ được thêm
     vào bảng
   (kèm --drop-unknown-fields nếu cần
    bỏ qua trường lạ thay vì lỗi)

2. DEAD-LETTER TOPIC
   --dead-letter-topic=projects/.../topics/dlt
   --max-delivery-attempts=5
   → thông điệp thất bại chuyển sang DLT
   → phân tích được nguyên nhân

⚠ Vì sao dead-letter là BẮT BUỘC với subscription được quản lý:

Không có worker nào của bạn chạy
        ↓
    → KHÔNG có log ứng dụng để đọc
        ↓
    Thông điệp ghi thất bại
        ↓
    → nằm im trong subscription
    → backlog tăng, không có lỗi nào hiện ra
        ↓
    ⚠ DLT là cách DUY NHẤT bắt được
      thông điệp hỏng

Xem thêm câu #13090 (cùng lô): chính tình huống backlog tăng mà không có log → phải bật DLT. Và #13105 (cùng lô): nêu tiêu chí phân biệt giữa subscription được quản lý và subscriber tự viết. Ba câu tạo thành một bộ hoàn chỉnh về Pub/Sub → BigQuery.

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

• D (pipeline Dataflow tự viết dùng Storage Write API) — đây là phương án gần nhất về mặt kỹ thuật và rất linh hoạt, nhưng nó đòi viết và vận hành một pipeline — trái yêu cầu "giảm tối đa mã tuỳ chỉnh và công vận hành".

• C (Cloud Function được kích hoạt bởi Pub/Sub) — cũng phải viết mã, và kém hiệu quả ở thông lượng cao.

• A (external table trỏ vào tệp trong Cloud Storage) — không phải cơ chế nạp luồng; dữ liệu vẫn phải được ghi ra tệp trước bằng cách nào đó.

Ghi nhớ

⚠ Bốn cách đưa Pub/Sub vào BigQuery — bảng phải thuộc: | Cách | Cần mã? | Biến đổi được? | |---|---|---| | BigQuery subscription | KHÔNG | không | | Dataflow | có | có — đầy đủ | | Cloud Run function | có | có, hạn chế | | Cloud Storage subscription → nạp sau | không | không | | Chọn subscription khi | chỉ nạp thô, không biến đổi |

Từ khoá nhận diện:

"nạp thẳng, ít mã, ít vận hành" → BigQuery subscription "cần biến đổi, che PII, tổng hợp cửa sổ" → Dataflow "lưu thô thành tệp" → Cloud Storage subscription "thông điệp lỗi để phân tích" → dead-letter topic "cột mới xuất hiện" → tiến hoá lược đồ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Subscription cấu hình thế nào | gcloud pubsub subscriptions describe <sub> | | Có thông điệp hỏng không | subscription trên DLT | | Dữ liệu tới bảng chưa | SELECT MAX(<thời điểm>) |

Và một cấu hình nên coi là bắt buộc với mọi subscription được quản lý: dead-letter topic. Đây là kiến trúc không có worker nào của bạn chạy, nên nếu không có DLT, một thông điệp sai lược đồ sẽ chỉ biểu hiện thành một con số backlog tăng dần — không log, không lỗi, không manh mối nào về nguyên nhân.

Đáp án

C — 1) Một DEPENDENCY (dùng hàm ref), và 2) một ASSERTION.

Vì sao đúng

Dataform có hai cơ chế riêng biệt cho hai nhu cầu này: ref() khai phụ thuộc để quyết định thứ tự dựng bảng, và assertions kiểm tra chất lượng dữ liệu.

⚠ Điểm mấu chốt — ref() vừa dựng SQL vừa khai phụ thuộc:

-- definitions/fct_daily_sales.sqlx
config {
  type: "table",
  assertions: {
    rowConditions: [
      "total_revenue >= 0"
    ]
  }
}

SELECT
  o.ngay,
  c.khu_vuc,
  SUM(o.tong_tien) AS total_revenue
FROM ${ref("stg_orders")} AS o
JOIN ${ref("dim_customers")} AS c
  ON c.khach_id = o.khach_id
GROUP BY 1, 2

        ↓
    ⚠ ref() làm HAI việc cùng lúc:
      1. thay bằng tên bảng đầy đủ trong SQL
      2. khai PHỤ THUỘC → Dataform dựng
         stg_orders và dim_customers TRƯỚC

⚠ Assertions — ba kiểu khai sẵn:

uniqueKey: ["order_id"]
    → không có khoá trùng

nonNull: ["order_id", "ngay"]
    → không có giá trị NULL

rowConditions: ["total_revenue >= 0"]
    → điều kiện tuỳ ý trên từng dòng
        ↓
    ⚠ Assertion THẤT BẠI → pipeline DỪNG
    → dữ liệu hỏng KHÔNG chảy tiếp

⚠ Vì sao ref() tốt hơn viết tên bảng cứng:

Viết cứng `du_an.stg_orders`
        ↓
    ⚠ Dataform KHÔNG BIẾT có phụ thuộc
    → có thể dựng fct_daily_sales TRƯỚC
      khi stg_orders sẵn sàng
    ⚠ Đổi môi trường (dev/prod) phải sửa mã
        ↓
    Dùng ${ref("stg_orders")}
        ↓
    → thứ tự tự đúng
    → tên bảng tự đổi theo môi trường

Xem thêm câu #13126 (cùng lô): mô tả điều gì xảy ra KHI assertion thất bại. Và #12991 (lô 135): khoá Dataform cho đội SQL-first cần Git và kiểm thử. Ba câu tạo thành một bộ về Dataform.

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

• A (1: assertion, 2: dependency) — đây là phương án gần nhất vì dùng đúng hai thuật ngữ, nhưng gán ngược: phụ thuộc lo thứ tự, assertion lo chất lượng.

• B (policy tag và BigLake table) — cả hai đều là cơ chế BẢO MẬT và quản trị, không liên quan tới thứ tự dựng bảng hay kiểm tra chất lượng.

• D (scheduled query và custom field) — scheduled query là cách chạy SQL theo lịch (không quản lý phụ thuộc), custom field là tính năng của Looker.

Ghi nhớ

⚠ Các thành phần của Dataform — bảng phải thuộc: | Thành phần | Việc | |---|---| | ref("bang") | khai PHỤ THUỘC và thay tên bảng | | assertions | kiểm thử CHẤT LƯỢNG dữ liệu | | config.type | table, view, incremental, operations | | declaration | khai bảng NGUỒN bên ngoài | | dependencies | khai phụ thuộc không qua ref | | .sqlx | tệp định nghĩa: config + một câu SELECT |

Từ khoá nhận diện:

"bảng này phải dựng trước bảng kia" → ref() — dependency "kiểm tra dữ liệu không âm, không trùng" → assertion "chạy SQL theo lịch" → scheduled query — không quản phụ thuộc "phân loại cột nhạy cảm" → policy tag "trường tính toán trong Looker" → custom field

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đồ thị phụ thuộc thế nào | compile trong giao diện Dataform | | Assertion có chạy không | kết quả workflow execution | | Bảng nào thiếu assertion | rà soát các tệp .sqlx |

Và một thói quen đáng thiết lập ngay từ mô hình đầu tiên: mọi bảng đều phải có ít nhất uniqueKey và nonNull. Hai dòng khai báo đó bắt được phần lớn lỗi dữ liệu thực tế — trùng khoá do nạp lại, và trường bắt buộc bị thiếu khi nguồn đổi — và chúng bắt được trước khi báo cáo hiển thị con số sai.

Đáp án

D — Eventarc.

Vì sao đúng

Đề nêu hai điều: cần trigger đăng ký một Pub/Sub topic và gọi Cloud Function, và công ty có chính sách dùng MỘT dịch vụ ĐỊNH TUYẾN SỰ KIỆN TẬP TRUNG cho mọi tích hợp kiểu này. Eventarc chính là dịch vụ đó.

⚠ Điểm mấu chốt — "định tuyến sự kiện tập trung" là từ khoá:

Eventarc
        ↓
    Lớp ĐỊNH TUYẾN SỰ KIỆN thống nhất
    của Google Cloud
        ↓
    - hơn 130 nguồn sự kiện
    - chuẩn CloudEvents
    - đích: Cloud Run, Cloud Run functions,
      Workflows, GKE
        ↓
    ⚠ Chính sách công ty đòi
      "một dịch vụ tập trung"
    → Eventarc đúng vai trò đó

⚠ Tạo trigger cho nguồn Pub/Sub:

gcloud eventarc triggers create trigger-pubsub \
  --destination-run-service=ham-xu-ly \
  --destination-run-region=asia-southeast1 \
  --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished" \
  --transport-topic=projects/DU-AN/topics/su-kien \
  --service-account=sa@du-an.iam.gserviceaccount.com

⚠ Vì sao "định tuyến tập trung" lại đáng giá:

Không có lớp tập trung
        ↓
    Mỗi tích hợp một kiểu:
      - hàm này dùng trigger Pub/Sub trực tiếp
      - hàm kia dùng trigger GCS
      - hàm khác tự viết subscriber
        ↓
    ⚠ Không có chỗ nào nhìn thấy
      TOÀN BỘ luồng sự kiện
    ⚠ Khó kiểm toán, khó chuẩn hoá
        ↓
    Eventarc
        ↓
    → một nơi khai và xem mọi trigger
    → cùng chuẩn CloudEvents
    → cùng cách xác thực

Xem thêm câu #13120 (cùng lô): cùng khoá Eventarc, nhưng nguồn là Cloud Storage và đích là Cloud Run service. Hai câu hoàn toàn nhất quán — Eventarc là cơ chế chung cho mọi nguồn và đích.

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

• C (Cloud Composer) — đây là phương án gần nhất trong nhóm "tự động hoá", nhưng nó là bộ ĐIỀU PHỐI luồng nhiều bước, không phải cơ chế định tuyến sự kiện; và nó đòi một môi trường thường trực.

• A (Cloud Scheduler) — kích hoạt theo LỊCH, không phản ứng theo sự kiện.

• B (Cloud Logging) — lưu và tra cứu log; nó có thể sinh ra sự kiện audit log, nhưng không phải dịch vụ định tuyến.

Ghi nhớ

⚠ Bốn cơ chế kích hoạt — bảng phải thuộc: | Kích hoạt theo | Công cụ | |---|---| | SỰ KIỆN của dịch vụ GCP | Eventarc | | LỊCH (cron) | Cloud Scheduler | | Thông điệp hàng đợi | Pub/Sub (trigger trực tiếp) | | Tác vụ có kiểm soát tốc độ | Cloud Tasks | | Luồng nhiều bước | Cloud Composer / Workflows |

Từ khoá nhận diện:

"định tuyến sự kiện tập trung" → Eventarc "khi tệp được tải lên" → Eventarc (nguồn GCS) "đúng giờ mỗi ngày" → Cloud Scheduler "nhiều bước có phụ thuộc" → Composer / Workflows "lưu và tra cứu log" → Cloud Logging

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có những trigger nào | gcloud eventarc triggers list | | Sự kiện có tới không | log của dịch vụ đích | | Vì sao không tới | kiểm tra roles/run.invoker |

Và một lợi ích của việc chuẩn hoá qua Eventarc mà chỉ thấy rõ khi hệ thống đã lớn: một chỗ duy nhất để trả lời câu hỏi "sự kiện này chảy đi đâu". Với hàng chục tích hợp mỗi cái một kiểu, việc lần ra ai đang lắng nghe topic nào là một dự án khảo cổ — còn với Eventarc, đó là một lệnh triggers list.

Đáp án

B — Lần chạy sẽ THẤT BẠI ở bước stg_orders, và Dataform sẽ CHẶN việc thực thi bảng fct_orders phía sau.

Vì sao đúng

Assertion trong Dataform là cổng chất lượng: khi nó thất bại, pipeline dừng lại tại đó và các bảng phụ thuộc không được dựng — để dữ liệu hỏng không lan xuống.

⚠ Điểm mấu chốt — assertion chặn luồng phía sau:

stg_orders được dựng
        ↓
    Assertion uniqueKey: ["order_id"] chạy
        ↓
    Phát hiện order_id trùng
        ↓
    ⚠ ASSERTION THẤT BẠI
        ↓
    → bước stg_orders báo FAILED
    → fct_orders (phụ thuộc qua ref)
      KHÔNG được thực thi
        ↓
    ⚠ Bảng fct_orders giữ nguyên
      dữ liệu của lần chạy TRƯỚC

⚠ Vì sao "chặn" là hành vi ĐÚNG:

Nếu vẫn chạy tiếp
        ↓
    → dữ liệu TRÙNG chảy vào fct_orders
    → doanh thu bị TÍNH HAI LẦN
    → báo cáo sai mà KHÔNG có tín hiệu nào
        ↓
    ⚠ Bảng báo cáo hiển thị số cũ
      còn TỐT HƠN hiển thị số sai
        ↓
    Nguyên tắc: THÀ DỪNG CÒN HƠN CHẠY SAI

⚠ Quy trình xử lý khi assertion thất bại:

1. Xem bảng KẾT QUẢ ASSERTION
     → Dataform lưu các DÒNG VI PHẠM
2. Tìm nguyên nhân ở nguồn
     → nạp lại hai lần? nguồn có trùng thật?
3. Sửa:
     - thêm bước loại trùng trong stg_orders
     - hoặc sửa quy trình nạp
4. Chạy lại pipeline
        ↓
    ⚠ Assertion cũng là công cụ CHẨN ĐOÁN,
      không chỉ là cổng chặn

Xem thêm câu #13124 (cùng lô): khai ref() và assertions. Câu này mô tả điều gì xảy ra khi assertion thất bại. Hai câu bổ sung nhau hoàn hảo. Và #13052 (lô 136): cùng nguyên tắc dừng và cảnh báo khi một bước hỏng.

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

• C (gửi thông báo nhưng vẫn chạy hết mọi bước) — đây là phương án gần nhất vì thông báo là điều nên có, nhưng Dataform KHÔNG chạy tiếp các bảng phụ thuộc; nếu chạy tiếp thì assertion mất hết ý nghĩa.

• A (bỏ qua assertion và nạp dữ liệu xấu) — ngược hoàn toàn với mục đích của assertion.

• D (bỏ qua stg_orders nhưng vẫn dựng fct_orders bằng dữ liệu cũ) — không phải hành vi của Dataform; bảng phụ thuộc bị chặn, không phải được dựng bằng dữ liệu cũ.

Ghi nhớ

⚠ Hành vi của Dataform khi assertion thất bại — bảng phải thuộc: | Điều xảy ra | Nội dung | |---|---| | Bước đó báo FAILED | | | Các bảng PHỤ THUỘC bị CHẶN | không thực thi | | Bảng phía sau giữ dữ liệu lần chạy TRƯỚC | | | Dòng vi phạm được lưu lại | bảng kết quả assertion | | Cảnh báo | nếu đã cấu hình thông báo | | Nguyên tắc | thà dừng còn hơn chạy sai |

Từ khoá nhận diện:

"assertion thất bại" → dừng bước đó và chặn bước sau "vẫn chạy tiếp" → luôn là phương án SAI "bỏ qua và nạp dữ liệu xấu" → sai mục đích của assertion "chỉ gửi thông báo" → chưa đủ "dữ liệu hỏng lan xuống" → chính điều assertion ngăn chặn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Assertion thất bại ở dòng nào | bảng kết quả assertion trong Dataform | | Bảng phía sau có bị chặn không | xem trạng thái trong workflow execution | | Nguồn có trùng thật không | GROUP BY order_id HAVING COUNT(*) > 1 |

Và một giá trị của assertion mà người ta thường chỉ nhận ra sau lần thất bại đầu tiên: nó không chỉ chặn, nó còn chỉ ra chính xác những dòng nào sai. Thay vì một báo cáo lệch số mà không ai biết bắt đầu tìm từ đâu, bạn có ngay danh sách order_id bị trùng — và đó thường là toàn bộ manh mối cần thiết để lần ra nguyên nhân ở hệ thống nguồn.

Đáp án

B — 1-B, 2-A, 3-C: Phi cấu trúc → Cloud Storage; Có cấu trúc quy mô petabyte → BigQuery; Bán cấu trúc chuỗi thời gian IoT → Bigtable.

Vì sao đúng

Ba loại dữ liệu trong đề là ba đại diện kinh điển, và mỗi loại có một dịch vụ chuyên trách.

⚠ Điểm mấu chốt — ánh xạ từng loại:

1) PHI CẤU TRÚC
   "tệp media thô: ảnh, video, cho data lake"
        ↓
    → CLOUD STORAGE (B)
    → kho đối tượng, rẻ, không giới hạn

2) CÓ CẤU TRÚC
   "petabyte giao dịch bán hàng lịch sử,
    lược đồ cố định, phân tích toàn công ty"
        ↓
    → BIGQUERY (A)
    → kho phân tích, lưu theo cột

3) BÁN CẤU TRÚC
   "chuỗi thời gian IoT, thông lượng cao,
    độ trễ thấp, truy vấn theo ROW KEY"
        ↓
    → BIGTABLE (C)
    → NoSQL wide-column

⚠ Từ khoá quyết định của mỗi vế:

"media files, data lake"
    → kho ĐỐI TƯỢNG, không phải CSDL

"petabyte, lược đồ cố định, PHÂN TÍCH"
    → kho PHÂN TÍCH, không phải giao dịch

"ROW KEY, thông lượng cao, độ trễ thấp"
    → ⚠ "row key" là dấu hiệu RẤT RÕ
      của Bigtable

⚠ Vì sao Bigtable chứ không phải BigQuery cho IoT:

BigQuery
    → tối ưu cho QUÉT LỚN và tổng hợp
    → ⚠ không hợp đọc/ghi TỪNG bản ghi
      độ trễ mili giây

Bigtable
    → đọc/ghi theo ROW KEY rất nhanh
    → ghi hàng triệu điểm/giây
        ↓
    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 (lô 136): ánh xạ giao dịch / tệp / phân tích vào Cloud SQL, Cloud Storage, BigQuery. #13071 (lô 136): Cloud Storage cho media. #13084 (cùng lô): Bigtable cho IoT. Bốn câu tạo thành bảng chọn kho đầy đủ — hoàn toàn nhất quán.

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

• A (1-B, 2-C, 3-A) — đây là phương án gần nhất vì vế đầu đúng (Cloud Storage cho media), nhưng nó đảo BigQuery và Bigtable ở hai vế sau.

• C (1-A, 2-B, 3-C) — đưa media vào BigQuery và dữ liệu phân tích vào Cloud Storage — sai cả hai vế đầu.

• D (1-C, 2-A, 3-B) — đưa media vào Bigtable và IoT vào Cloud Storage — sai vế đầu và vế cuối.

Ghi nhớ

⚠ Bảng chọn kho theo LOẠI DỮ LIỆU — bảng phải thuộc: | Loại dữ liệu | Dịch vụ | |---|---| | Phi cấu trúc: ảnh, video, PDF, log thô | Cloud Storage | | Có cấu trúc, PHÂN TÍCH quy mô lớn | BigQuery | | Có cấu trúc, GIAO DỊCH | Cloud SQL / AlloyDB / Spanner | | Bán cấu trúc, chuỗi thời gian, ghi lớn | Bigtable | | Tài liệu, thời gian thực, di động | Firestore | | Bộ nhớ đệm | Memorystore |

Từ khoá nhận diện:

"ảnh, video, media, data lake" → Cloud Storage "petabyte, phân tích, lược đồ cố định" → BigQuery "row key, IoT, chuỗi thời gian, thông lượng cao" → Bigtable "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 | |---|---| | Bigtable có hotspot không | Key Visualizer | | BigQuery có bị dùng cho tra cứu điểm không | xem truy vấn WHERE id = ... chạy liên tục | | Chi phí chia theo dịch vụ | billing export, nhóm theo SKU |

Và một mẹo làm bài rất hiệu quả với các câu hỏi ghép cặp kiểu này: tìm vế DỄ NHẤT trước rồi loại trừ. "Media files, data lake" gần như chắc chắn là Cloud Storage — chỉ riêng điều đó đã loại được hai trong bốn phương án, và câu hỏi thu lại thành một lựa chọn giữa hai khả năng.

Đáp án

B — Project → Model → Explore → View → Measure.

Vì sao đúng

Đây là thứ tự phân cấp thật sự của LookML, từ vùng chứa rộng nhất tới phần tử cụ thể nhất — và cũng là đường đi khi bạn tìm chỗ để thêm một measure.

⚠ Điểm mấu chốt — năm cấp từ ngoài vào trong:

PROJECT
    → toàn bộ kho mã LookML (một repo Git)
        ↓
    MODEL (.model.lkml)
        → khai CONNECTION tới CSDL
        → gom các EXPLORE
        ↓
        EXPLORE
            → điểm vào cho người dùng
            → khai JOIN giữa các view
            ↓
            VIEW (.view.lkml)
                → ánh xạ MỘT BẢNG
                ↓
                DIMENSION / MEASURE
                    → trường cụ thể

⚠ Vì sao measure nằm trong VIEW, không nằm trong explore:

measure: average_order_value {
  type: average
  sql: ${TABLE}.amount ;;
}
        ↓
    ⚠ Trường thuộc về BẢNG nào thì khai
      trong VIEW của bảng đó
        ↓
    Explore chỉ TẬP HỢP các view lại
    và khai cách chúng nối với nhau
        ↓
    → muốn thêm measure về đơn hàng
      → mở orders.view.lkml

⚠ Điều gây nhầm — explore VIẾT trong tệp model:

Tệp cua_hang.model.lkml chứa:
    connection: "bigquery_..."
    include: "/views/*.view.lkml"

    explore: orders {
      join: users { ... }
    }
        ↓
    ⚠ Explore VIẾT bên trong tệp model
    ⚠ Nhưng về PHÂN CẤP, explore
      nằm DƯỚI model và TRÊN view
        ↓
    → đây là nguồn nhầm lẫn phổ biến nhất

Xem thêm câu #13026 (lô 135): hỏi VAI TRÒ của ba thành phần model, view, explore. Câu này hỏi THỨ TỰ PHÂN CẤP. Hai câu bổ sung nhau hoàn hảo — cùng một kiến thức nhìn từ hai góc.

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

• C (Project → Model → View → Explore → Measure) — đây là phương án gần nhất và ba cấp đầu đúng, nhưng nó đảo View và Explore: explore tập hợp các view, nên nằm trên view.

• A (Project → Explore → Model → View → Measure) — đảo Model và Explore: model là vùng chứa của explore.

• D (Explore → View → Measure → Model → Project) — đảo ngược hoàn toàn.

Ghi nhớ

⚠ Phân cấp LookML — bảng phải thuộc: | Cấp | Thành phần | Vai trò | |---|---|---| | 1 | Project | toàn bộ kho mã LookML | | 2 | Model | connection + tập các explore | | 3 | Explore | điểm vào, khai JOIN | | 4 | View | ánh xạ MỘT bảng | | 5 | Dimension / Measure | trường cụ thể | | Bẫy | explore VIẾT trong tệp model nhưng nằm DƯỚI model về phân cấp |

Từ khoá nhận diện:

"thêm một measure" → mở VIEW của bảng đó "khai JOIN" → explore "kết nối CSDL" → model "toàn bộ kho mã" → project "điểm vào cho người dùng" → explore

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Measure nằm ở tệp nào | tìm tên trường trong kho LookML | | Explore dùng những view nào | đọc tệp model | | SQL sinh ra thế nào | tab SQL trong Explore |

Và một chi tiết trong cấu trúc LookML mà người mới rất hay bỏ qua, nhưng lại gây sai số liệu nhiều nhất: khai primary_key: yes trong mỗi view. Không có nó, Looker không dùng được cơ chế symmetric aggregates, và mọi measure trên bảng bị join one-to-many sẽ bị cộng lặp — truy vấn vẫn chạy, biểu đồ vẫn đẹp, chỉ có con số là sai.

Đáp án

B — Vào mục "Dashboards", tạo một dashboard mới, rồi thêm các tile từ những Look đã lưu.

Vì sao đúng

Trong Looker, Look là một truy vấn đã lưu kèm cách hiển thị; dashboard là nơi gom nhiều Look thành một trang để chia sẻ. Quy trình đúng là tạo dashboard rồi thêm tile.

⚠ Điểm mấu chốt — Look và dashboard là hai khái niệm khác nhau:

LOOK
    → MỘT truy vấn đã lưu + một biểu đồ
    → xem riêng lẻ được
    → có thể dùng lại ở nhiều dashboard

DASHBOARD
    → TẬP HỢP nhiều TILE
    → mỗi tile là một biểu đồ
    → có BỘ LỌC dùng chung
    → chia sẻ như một trang duy nhất

⚠ Hai cách thêm tile vào dashboard:

CÁCH 1 — từ Look đã lưu
    Dashboard → Add tile → From a Look
        ↓
    ⚠ Tile LIÊN KẾT tới Look
    → sửa Look thì tile đổi theo

CÁCH 2 — tạo tile mới ngay trên dashboard
    Dashboard → Add tile → New tile
        ↓
    → truy vấn thuộc về dashboard,
      không phải Look riêng
        ↓
    Đề nói "đã lưu các Look" → cách 1

⚠ Sau khi có dashboard — các bước tiếp:

- Thêm DASHBOARD FILTER
  → cho người xem tự lọc
- Sắp xếp bố cục các tile
- Đặt dashboard vào FOLDER
- Cấp quyền View cho GROUP
- Đặt scheduled delivery nếu cần
        ↓
    ⚠ Quyền cấp ở FOLDER, không ở
      từng dashboard

Xem thêm câu #13112 (cùng lô): thêm dashboard filter để người dùng tự lọc. Và #13013 (lô 135): cấp quyền qua folder + group. Ba câu mô tả ba bước liên tiếp của cùng một quy trình.

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

• D (tạo tệp view mới trong LookML) — đây là phương án gần nhất trong các thao tác Looker, nhưng đó là việc của developer ở tầng MÔ HÌNH; dựng dashboard là thao tác ở tầng nội dung, không cần đụng LookML.

• C (dùng SQL Runner để viết truy vấn gộp các Look) — SQL Runner dùng để chạy SQL thô trực tiếp lên CSDL; nó không gộp Look thành dashboard.

• A (thêm project mới vào model) — thao tác ở tầng dự án LookML, hoàn toàn không liên quan.

Ghi nhớ

⚠ Các khái niệm nội dung trong Looker — bảng phải thuộc: | Khái niệm | Nội dung | |---|---| | Explore | giao diện KHÁM PHÁ dữ liệu | | Look | MỘT truy vấn đã lưu + biểu đồ | | Dashboard | TẬP HỢP tile, có bộ lọc chung | | Tile | một ô trên dashboard | | Folder | nơi chứa nội dung và CẤP QUYỀN | | Board | trang tổng hợp liên kết tới nội dung |

Từ khoá nhận diện:

"gom các Look thành một trang" → dashboard "một truy vấn đã lưu" → Look "cho người dùng tự lọc" → dashboard filter "cấp quyền cho nhóm" → folder permission "sửa mô hình dữ liệu" → LookML — tầng khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tile lấy dữ liệu từ đâu | mở tile → Explore from here | | Dashboard tốn bao nhiêu | INFORMATION_SCHEMA.JOBS phía BigQuery | | Ai xem được | quyền của FOLDER chứa dashboard |

Và một quyết định nên cân nhắc khi thêm tile: dùng Look có sẵn hay tạo tile mới. Tile liên kết tới Look giúp sửa một chỗ và mọi nơi cập nhật, nhưng cũng có nghĩa là một thay đổi nhỏ trong Look sẽ ảnh hưởng tới mọi dashboard đang dùng nó — nên với biểu đồ chỉ phục vụ một dashboard, tạo tile mới thường an toàn hơn.

Đáp án

D — Cross-region read replica (bản sao đọc ở Region khác).

Vì sao đúng

Yêu cầu là khôi phục hoạt động ở một Region ĐỊA LÝ KHÁC khi us-central1 hỏng hoàn toàn. Chỉ bản sao nằm ở Region khác mới đáp ứng được.

⚠ Điểm mấu chốt — mỗi cơ chế chống một loại sự cố:

CẤU HÌNH HA (regional)
        ↓
    Máy dự phòng ở ZONE KHÁC,
    CÙNG Region us-central1
        ↓
    ⚠ Cả Region chết → KHÔNG cứu được

CROSS-REGION READ REPLICA        ← đề này
        ↓
    Bản sao ở us-east1
        ↓
    us-central1 chết
        ↓
    → THĂNG CẤP replica thành
      instance độc lập, ghi được
    → trỏ ứng dụng sang

⚠ Quy trình khi Region chính gặp sự cố:

gcloud sql instances promote-replica ten-replica
        ↓
    Replica trở thành instance ĐỘC LẬP
        ↓
    ⚠ Thao tác MỘT CHIỀU — không quay lại
      làm replica được
    ⚠ Nhân bản là BẤT ĐỒNG BỘ
      → có thể MẤT vài giao dịch cuối
        ↓
    Sau đó: bật HA, bật sao lưu,
    tạo replica mới cho instance mới

⚠ Hai con số phải thống nhất với bên nghiệp vụ:

RPO — chấp nhận MẤT bao nhiêu dữ liệu
    → với replica bất đồng bộ: vài giây

RTO — chấp nhận NGỪNG bao lâu
    → thăng cấp replica: vài phút
        ↓
    Cần RPO = 0 trên nhiều Region
      → phải dùng CLOUD SPANNER,
        không phải Cloud SQL

Xem thêm câu #12955 (lô 134): cùng tình huống, cùng khoá cross-region read replica. Hai câu hoàn toàn nhất quán. Và #12932 (lô 134): khoá PITR vì ở đó chống lỗi con người, không phải sự cố Region.

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

• A (cấu hình HA) — đây là phương án gần nhất và bắt buộc phải có cho hệ thống quan trọng, nhưng nó đặt máy dự phòng ở ZONE khác trong CÙNG Region; mất cả us-central1 là mất cả hai.

• B (sao lưu tự động) — bắt buộc phải có, nhưng khôi phục từ sao lưu mất hàng giờ, và bản sao lưu mặc định nằm cùng khu vực.

• C (point-in-time recovery) — chống lỗi con người (xoá nhầm), không phải cơ chế chịu lỗi Region.

Ghi nhớ

⚠ Bốn cơ chế của Cloud SQL và loại sự cố chúng chống — bảng phải thuộc: | Cơ chế | Chống | |---|---| | Sao lưu tự động + PITR | lỗi con người, dữ liệu hỏng | | Cấu hình HA (regional) | hỏng một ZONE | | Read replica cùng Region | quá tải đọc | | Cross-region read replica | sự cố CẢ REGION | | Nhớ | bốn cơ chế, bốn mục đích — không thay thế nhau |

Từ khoá nhận diện:

"khôi phục ở Region địa lý khác" → cross-region read replica "chịu được hỏng một zone" → cấu hình HA regional "xoá nhầm dữ liệu" → PITR "giảm tải đọc" → read replica "RPO = 0 đa Region" → Cloud Spanner

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có replica ở Region nào | gcloud sql instances list — xem cột Region | | Độ trễ nhân bản | chỉ số replication_lag trong Monitoring | | Sao lưu để ở đâu | describe → backupConfiguration.location |

Và điều quyết định một kế hoạch khôi phục thảm hoạ có giá trị hay không: đã từng diễn tập thăng cấp replica chưa. Cấu hình đúng trong describe không bảo đảm quy trình chạy trơn tru dưới áp lực — chuỗi kết nối hard-code trong ảnh container, quyền IAM thiếu, hay đơn giản là không ai nhớ tên lệnh, đều chỉ lộ ra khi bạn thật sự thử.