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

Đáp án

D — Cloud Data Fusion.

Vì sao đúng

Đề nêu bốn điều: nhà phân tích nghiệp vụ tự dựng pipeline, không phụ thuộc đội kỹ thuật trung tâm, không phải lập trình viên, và cần phát triển nhanh, trực quan, ít mã. Cloud Data Fusion khớp cả bốn.

⚠ Điểm mấu chốt — trao quyền cho người không lập trình:

Mục tiêu: nhà phân tích TỰ LÀM
        ↓
    Rào cản lớn nhất là VIẾT MÃ
        ↓
    Cloud Data Fusion
      - giao diện kéo thả trong trình duyệt
      - hơn 150 plugin nguồn/đích/biến đổi
      - Wrangler làm sạch trực quan
      - xem trước dữ liệu ở từng bước
        ↓
    → nhà phân tích tự dựng và tự chạy
    → đội kỹ thuật không thành nút cổ chai

⚠ Vì sao ba phương án kia đều KHÔNG "trao quyền" được:

Dataflow   → viết Apache Beam (Java/Python)
Dataproc   → viết Spark
Composer   → viết DAG bằng Python
        ↓
    ⚠ Cả ba đều đòi LẬP TRÌNH
    → nhà phân tích vẫn phải nhờ
      đội kỹ thuật
    → không đạt mục tiêu của đề

⚠ Nhưng "trao quyền" cần đi kèm rào chắn:

Nhà phân tích tự dựng pipeline
        ↓
    ⚠ Cần đặt sẵn:
      - namespace riêng cho từng nhóm
      - service account có quyền HẸP
      - hạn mức tài nguyên
      - quy ước đặt tên và tài liệu
        ↓
    → tự do trong một khuôn khổ,
      không phải tự do tuyệt đối

Xem thêm câu #13012 (cùng lô), #12915 (lô 133), #12981 (lô 134): cả ba cũng khoá Cloud Data Fusion, cùng lý do "không lập trình". Bốn câu CÙNG KHOÁ — nhất quán. Còn #13030 (cùng lô) khoá Dataflow vì tiêu chí ở đó là hiệu năng, không phải kỹ năng đội.

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

• A (Dataflow) — đây là phương án gần nhất về năng lực xử lý, nhưng đòi viết Apache Beam — đúng rào cản mà đề muốn gỡ bỏ.

• B (Dataproc) — đòi viết Spark, còn khó hơn.

• C (Cloud Composer) — là công cụ ĐIỀU PHỐI, không phải công cụ dựng phép biến đổi; và DAG cũng viết bằng Python.

Ghi nhớ

⚠ Công cụ theo kỹ năng của người dùng — bảng phải thuộc: | Người dùng | Công cụ | |---|---| | Nhà phân tích, không lập trình | Cloud Data Fusion | | Nhà phân tích, cần khám phá và làm sạch | Dataprep | | Đội giỏi SQL, cần Git và kiểm thử | Dataform | | Kỹ sư Python/Java | Dataflow | | Đội có Spark | Dataproc | | Điều phối nhiều dịch vụ | Cloud Composer |

Từ khoá nhận diện:

"trao quyền cho nhà phân tích, ít mã, trực quan" → Cloud Data Fusion "khám phá dữ liệu, tìm bất thường" → Dataprep "SQL-first, có kiểm thử" → Dataform "hiệu năng và tiết kiệm tài nguyên" → Dataflow "quản lý thứ tự các bước" → Cloud Composer

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline nào đang chạy | Data Fusion → Pipeline list theo namespace | | Chi phí bao nhiêu | billing export, SKU Data Fusion và Dataproc | | Có pipeline bỏ hoang không | rà soát lần chạy gần nhất |

Và một điều nên chuẩn bị cùng lúc với việc trao công cụ cho nhà phân tích: một danh mục các pipeline đã có. Mô hình tự phục vụ rất dễ dẫn tới ba phiên bản khác nhau của cùng một luồng làm sạch dữ liệu khách hàng — và ba con số hơi khác nhau trong ba báo cáo là cái giá đắt hơn nhiều so với thời gian chờ đội kỹ thuật.

Đáp án

D — Tạo một CONNECTION tới Vertex AI, tạo REMOTE MODEL trỏ tới gemini-pro, rồi dùng hàm ML.GENERATE_TEXT.

Vì sao đúng

Mô hình nền tảng như Gemini không được huấn luyện trong BigQuery — nó chạy ở Vertex AI. BigQuery gọi tới nó qua remote model, và hàm dành cho việc sinh văn bản là ML.GENERATE_TEXT.

⚠ Điểm mấu chốt — ba bước:

1. TẠO CONNECTION tới Vertex AI
   bq mk --connection --location=asia-southeast1 \
     --connection_type=CLOUD_RESOURCE ket-noi-vertex
        ↓
   Cấp cho service account của connection:
     roles/aiplatform.user

2. TẠO REMOTE MODEL
   CREATE OR REPLACE MODEL `du_an.gemini`
   REMOTE WITH CONNECTION
     `du_an.asia-southeast1.ket-noi-vertex`
   OPTIONS (ENDPOINT = 'gemini-pro');

3. GỌI BẰNG SQL
   SELECT ml_generate_text_llm_result AS tom_tat
   FROM ML.GENERATE_TEXT(
     MODEL `du_an.gemini`,
     (SELECT CONCAT('Tóm tắt phản hồi sau: ',
                    noi_dung) AS prompt
      FROM `du_an.phan_hoi_khach_hang`),
     STRUCT(0.2 AS temperature,
            256 AS max_output_tokens,
            TRUE AS flatten_json_output));

⚠ Vì sao "dữ liệu không phải di chuyển" lại quan trọng:

Cách truyền thống
    → xuất dữ liệu ra khỏi BigQuery
    → xử lý ở nơi khác
    → nhập kết quả về
        ↓
    ⚠ thêm bản sao dữ liệu cần bảo vệ
    ⚠ thêm bước, thêm chỗ hỏng

Remote model
    → BigQuery gọi Vertex AI THAY BẠN
    → dữ liệu ở nguyên trong BigQuery
    → kết quả ghi thẳng vào bảng

⚠ Phân biệt hai loại mô hình trong BigQuery ML:

MÔ HÌNH NỘI SINH (native)
    → CREATE MODEL ... OPTIONS(model_type='...')
    → LOGISTIC_REG, KMEANS, ARIMA_PLUS...
    → BigQuery TỰ huấn luyện
    → dùng ML.PREDICT

REMOTE MODEL                       ← đề này
    → CREATE MODEL ... REMOTE WITH CONNECTION
    → trỏ tới mô hình ở VERTEX AI
    → dùng ML.GENERATE_TEXT,
      ML.GENERATE_EMBEDDING...

Xem thêm câu #12962 (lô 134): dùng ML.PREDICT trên mô hình BQML tự huấn luyện. Câu này gọi mô hình nền tảng của Vertex AI nên dùng hàm khác. Hai khoá khác nhau vì hai loại mô hình khác nhau — hoàn toàn nhất quán.

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

• A (tạo mô hình BQML nội sinh với model_type='GEMINI' rồi dùng ML.PREDICT) — đây là phương án gần nhất và nghe rất hợp lý, nhưng không có model_type='GEMINI': mô hình nền tảng phải khai bằng REMOTE WITH CONNECTION, và hàm sinh văn bản là ML.GENERATE_TEXT.

• C (xuất sang GCS, xử lý bằng notebook, nhập lại) — trái yêu cầu "không di chuyển dữ liệu", và nhiều bước hơn hẳn.

• B (dùng bq đẩy dữ liệu sang Vertex AI rồi cập nhật tay) — thủ công, không mở rộng được, và cũng đưa dữ liệu ra ngoài.

Ghi nhớ

⚠ Hai loại mô hình của BigQuery ML — bảng phải thuộc: | Loại | Khai bằng | Hàm gọi | |---|---|---| | Nội sinh (native) | OPTIONS(model_type=...) | ML.PREDICT, ML.EVALUATE | | Remote (Vertex AI) | REMOTE WITH CONNECTION | ML.GENERATE_TEXT, ML.GENERATE_EMBEDDING | | Nhập từ ngoài | MODEL_TYPE='TENSORFLOW' + MODEL_PATH | ML.PREDICT | | Điều kiện remote | CONNECTION + roles/aiplatform.user |

Từ khoá nhận diện:

"dùng mô hình nền tảng từ SQL, không di chuyển dữ liệu" → remote model + ML.GENERATE_TEXT "tạo vector nhúng" → ML.GENERATE_EMBEDDING "dự đoán bằng mô hình tự huấn luyện" → ML.PREDICT "gọi Natural Language API từ SQL" → ML.UNDERSTAND_TEXT "model_type='GEMINI'" → KHÔNG TỒN TẠI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Connection có quyền chưa | service account của connection cần roles/aiplatform.user | | Kết quả có hợp lý không | đọc tay 50 bản tóm tắt ngẫu nhiên | | Chi phí bao nhiêu | billing export, SKU Vertex AI |

Và một thói quen tiết kiệm rất nhiều tiền khi dùng mô hình nền tảng trên bảng lớn: chỉ sinh kết quả cho bản ghi MỚI và lưu lại. Gọi ML.GENERATE_TEXT trực tiếp trong một view báo cáo nghĩa là mỗi lần ai đó mở dashboard, toàn bộ bảng lại được gửi qua mô hình một lần nữa — và hoá đơn đó tăng theo số người xem chứ không theo lượng dữ liệu.

Đáp án

C — Tác vụ này nhẹ và chạy ngắn, đúng mục đích của hàm không máy chủ, chứ không phải của một engine xử lý dữ liệu quy mô lớn.

Vì sao đúng

Nguyên tắc là chọn công cụ tương xứng với quy mô công việc. Trích một mẩu siêu dữ liệu từ một ảnh rồi gửi thông báo là tác vụ nhỏ, ngắn, theo sự kiện — đúng khuôn mẫu của hàm không máy chủ.

⚠ Điểm mấu chốt — so đặc điểm công việc với đặc điểm công cụ:

CÔNG VIỆC TRONG ĐỀ
    - một tệp mỗi lần
    - chạy vài trăm mili giây
    - theo sự kiện, rời rạc
        ↓
CLOUD RUN FUNCTION
    - khởi động nhanh
    - co về 0 khi rảnh
    - trả tiền theo lần gọi
    - trigger Cloud Storage có sẵn
        ↓
    → khớp hoàn toàn

DATAFLOW
    - dựng cho xử lý SONG SONG khối lượng lớn
    - có chi phí khởi tạo job đáng kể
    - mạnh ở cửa sổ, trạng thái, tổng hợp
        ↓
    → dùng cho việc này là như
      thuê xe tải để chở một phong bì

⚠ Vì sao ba phương án kia đều SAI VỀ SỰ THẬT:

"Dataflow đắt hơn cho MỌI loại tác vụ"
    → SAI: với khối lượng lớn,
      Dataflow rẻ hơn nhiều so với
      gọi hàm hàng triệu lần

"Dataflow không trích được siêu dữ liệu"
    → SAI: nó xử lý được

"CHỈ Cloud Functions mới nhận sự kiện
 từ Cloud Storage"
    → SAI: Eventarc đưa sự kiện GCS tới
      Cloud Run, Workflows, và nhiều đích khác

⚠ Ngưỡng chuyển từ hàm sang Dataflow:

Vẫn dùng HÀM khi:
    - mỗi sự kiện xử lý độc lập
    - thời gian ngắn
    - không cần tổng hợp giữa các bản ghi

Chuyển sang DATAFLOW khi:
    - cần TỔNG HỢP theo cửa sổ
    - cần JOIN nhiều nguồn
    - xử lý hàng triệu bản ghi mỗi giờ
    - cần bảo đảm exactly-once phức tạp

Xem thêm câu #12912 (lô 133): cùng tình huống "tệp lên bucket thì chạy đoạn mã nhỏ" → cũng khoá Cloud Run function. Hai câu nhất quán. Còn #12951, #13024 khoá Dataflow vì ở đó cần tổng hợp theo cửa sổ trên luồng lớn.

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

• A (Dataflow đắt hơn cho mọi loại tác vụ) — đây là phương án gần nhất về kết luận nhưng sai về lý do: Dataflow rẻ hơn ở khối lượng lớn. Cái sai của nó ở đây là không tương xứng, không phải "luôn đắt".

• D (chỉ Cloud Functions mới nhận được sự kiện Cloud Storage) — sai: Eventarc định tuyến sự kiện GCS tới nhiều đích.

• B (Dataflow không trích được siêu dữ liệu) — sai; nó hoàn toàn làm được.

Ghi nhớ

⚠ Chọn công cụ theo quy mô tác vụ — bảng phải thuộc: | Đặc điểm công việc | Công cụ | |---|---| | Nhẹ, ngắn, theo sự kiện, độc lập | Cloud Run function | | Container, chạy lâu hơn, HTTP | Cloud Run | | Chạy tới khi xong, theo lô | Cloud Run job | | Khối lượng lớn, cửa sổ, tổng hợp | Dataflow | | Đã có Spark | Dataproc | | Nguyên tắc | công cụ tương xứng với quy mô |

Từ khoá nhận diện:

"một tệp, một hành động nhỏ" → Cloud Run function "tổng hợp theo cửa sổ, luồng lớn" → Dataflow "xử lý hàng loạt tệp mỗi đêm" → Dataflow batch hoặc Cloud Run job "sự kiện GCS tới nhiều loại đích" → Eventarc "Dataflow luôn đắt" → SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàm chạy bao lâu mỗi lần | log của hàm, trường execution time | | Có bị gọi lặp không | đếm số lần gọi trên cùng một tệp | | Chi phí bao nhiêu | billing export, so với ước tính Dataflow |

Và một nguyên tắc kiến trúc đáng giữ ngoài phạm vi câu hỏi này: chọn công cụ nhỏ nhất còn đủ dùng. Một engine mạnh dùng cho việc nhỏ không chỉ tốn tiền, nó còn mang theo cả độ phức tạp vận hành — và mỗi thành phần thừa trong hệ thống là thêm một thứ có thể hỏng vào lúc bạn không mong đợi.

Đáp án

C — Pub/Sub, Dataflow và BigQuery.

Vì sao đúng

Đề mô tả đúng bốn chặng của một nền tảng phân tích thời gian thực: thu nhận, biến đổi và làm giàu ngay khi dữ liệu chảy qua, nạp vào kho, và phân tích bằng SQL — tất cả không máy chủ.

⚠ Điểm mấu chốt — mỗi dịch vụ một chặng:

Website phát sự kiện clickstream
        ↓
    PUB/SUB
      → thu nhận, làm bộ đệm
      → chịu được đỉnh tải giờ cao điểm
        ↓
    DATAFLOW (streaming)
      → LÀM GIÀU: nối sự kiện với
        hồ sơ người dùng
      → làm sạch, chuẩn hoá
        ↓
    BIGQUERY
      → lưu và phân tích bằng SQL ngay
        ↓
    ⚠ Cả ba đều KHÔNG MÁY CHỦ

⚠ "Làm giàu bằng hồ sơ người dùng" — Dataflow làm thế nào:

SIDE INPUT
    → nạp bảng hồ sơ người dùng
      làm tập dữ liệu phụ
    → mỗi sự kiện tra cứu trong đó
        ↓
    Hợp khi bảng hồ sơ NHỎ và ít đổi

Hoặc TRA CỨU NGOÀI
    → gọi Bigtable / Memorystore
      cho mỗi sự kiện
        ↓
    Hợp khi hồ sơ LỚN hoặc đổi liên tục
        ↓
    ⚠ Nhớ dùng bộ nhớ đệm trong worker
      để không gọi lại cho mỗi bản ghi

⚠ Vì sao ba phương án kia không phải kiến trúc luồng:

Cloud Storage + Dataproc + Cloud SQL
    → mô hình THEO LÔ, không thời gian thực
    → Dataproc không phải serverless

Composer + Data Fusion + BigQuery
    → điều phối và ETL THEO LÔ
    → Data Fusion không dành cho luồng
      độ trễ thấp

Cloud Functions + Cloud Run + Spanner
    → không có bộ đệm thu nhận
    → Spanner là CSDL giao dịch,
      không phải kho phân tích

Xem thêm câu #12951 (lô 134): cùng kiến trúc, cùng khoá Pub/Sub + Dataflow, ở đó là dữ liệu IoT với tổng hợp theo cửa sổ. Hai câu hoàn toàn nhất quán. Và #12994, #12999 (cùng lô) là hai biến thể: không biến đổi thì dùng subscription ghi thẳng, có che PII thì cần Dataflow.

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

• A (Cloud Composer, Cloud Data Fusion, BigQuery) — đây là phương án gần nhất vì kết thúc ở BigQuery, nhưng Composer và Data Fusion đều thiên về xử lý THEO LÔ và có chi phí nền thường trực — không phải kiến trúc luồng không máy chủ.

• B (Cloud Storage, Dataproc, Cloud SQL) — theo lô, Dataproc không phải serverless, và Cloud SQL không phải kho phân tích.

• D (Cloud Functions, Cloud Run, Cloud Spanner) — thiếu bộ đệm thu nhận, và Spanner là CSDL giao dịch.

Ghi nhớ

⚠ Kiến trúc luồng chuẩn — bảng phải thuộc: | Chặng | Dịch vụ | |---|---| | Thu nhận, bộ đệm | Pub/Sub | | Biến đổi luồng, làm giàu, cửa sổ | Dataflow | | Kho phân tích | BigQuery | | Lưu dữ liệu thô | Cloud Storage | | Trực quan hoá | Looker Studio | | Tra cứu độ trễ cực thấp | Bigtable, Memorystore |

Từ khoá nhận diện:

"clickstream, thời gian thực, serverless, SQL ngay" → Pub/Sub + Dataflow + BigQuery "không cần biến đổi" → Pub/Sub BigQuery subscription "xử lý theo lô mỗi đêm" → Cloud Storage + Dataflow/Dataproc "điều phối nhiều bước" → Cloud Composer — vai trò khác "CSDL giao dịch toàn cầu" → Spanner — không phải kho phân tích

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline có theo kịp không | Data freshness trong Job metrics | | Pub/Sub có tồn đọng không | num_undelivered_messages | | Dữ liệu có tới BigQuery không | SELECT MAX(<thời điểm>) trên bảng đích |

Và một lựa chọn đáng cân nhắc nếu bảng hồ sơ người dùng không quá lớn: làm giàu bằng phép JOIN trong BigQuery thay vì trong Dataflow. Nạp sự kiện thô vào kho rồi nối với bảng hồ sơ bằng SQL đơn giản hơn nhiều về vận hành — cái giá là độ trễ tính bằng phút thay vì giây, và với phần lớn báo cáo phân tích thì đó là cái giá rất dễ chấp nhận.

Đáp án

B — Tự động hoá một luồng công việc nhiều bước bằng cách quản lý THỨ TỰ và PHỤ THUỘC giữa các tác vụ.

Vì sao đúng

Đây chính là định nghĩa của điều phối (orchestration): nó không tự xử lý dữ liệu, mà quyết định việc nào chạy, khi nào, theo thứ tự nào, và làm gì khi hỏng.

⚠ Điểm mấu chốt — điều phối là "nhạc trưởng", không phải "nhạc công":

CÔNG CỤ XỬ LÝ (nhạc công)
    → Dataflow, Dataproc, BigQuery
    → LÀM việc: biến đổi dữ liệu

CÔNG CỤ ĐIỀU PHỐI (nhạc trưởng)
    → Cloud Composer, Workflows
    → CHỈ HUY: ai chạy trước, ai chạy sau,
      hỏng thì thử lại hay dừng
        ↓
    ⚠ Nhạc trưởng KHÔNG chơi nhạc cụ nào

⚠ Bốn việc cụ thể của một bộ điều phối:

1. THỨ TỰ và PHỤ THUỘC
    → B chỉ chạy khi A THÀNH CÔNG

2. THỬ LẠI và xử lý lỗi
    → theo từng tác vụ, có backoff

3. LỊCH và KÍCH HOẠT
    → theo giờ, hoặc theo sự kiện

4. THEO DÕI và CẢNH BÁO
    → một chỗ xem trạng thái cả luồng

⚠ Vì sao ba phương án kia mô tả các phạm trù KHÁC:

"môi trường không máy chủ để chạy job"
    → mô tả Cloud Run, Dataflow
    → đó là XỬ LÝ

"lưu dữ liệu đã xử lý để phân tích"
    → mô tả BigQuery, Cloud Storage
    → đó là LƯU TRỮ

"trực quan hoá kết quả trên dashboard"
    → mô tả Looker, Looker Studio
    → đó là BI

Xem thêm câu #12970 (lô 134): cùng câu hỏi về phạm trù công cụ, cùng khoá orchestration. Hai câu hoàn toàn nhất quán. Và #12948, #12996, #13003, #13015 là các câu hỏi cụ thể về chọn bộ điều phối nào.

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

• A (cung cấp môi trường không máy chủ để chạy các job xử lý riêng lẻ) — đây là phương án gần nhất vì bộ điều phối cũng "chạy job", nhưng nó không cung cấp môi trường tính toán: nó ra lệnh cho các dịch vụ khác chạy.

• C (lưu dữ liệu đã xử lý) — đó là vai trò của kho dữ liệu.

• D (trực quan hoá kết quả) — đó là vai trò của công cụ BI.

Ghi nhớ

⚠ Bốn phạm trù trong một pipeline dữ liệu — bảng phải thuộc: | Phạm trù | Việc | Ví dụ | |---|---|---| | Lưu trữ | chứa dữ liệu | Cloud Storage, BigQuery | | Xử lý | biến đổi dữ liệu | Dataflow, Dataproc, Data Fusion | | Điều phối | quản lý THỨ TỰ và PHỤ THUỘC | Cloud Composer, Workflows | | BI | hiển thị cho người dùng | Looker, Looker Studio | | Một pipeline hoàn chỉnh | thường có cả bốn |

Từ khoá nhận diện:

"quản lý thứ tự và phụ thuộc" → điều phối "biến đổi, tính toán" → xử lý "nơi chứa" → lưu trữ "biểu đồ, báo cáo" → BI "chạy đúng giờ, một việc" → lập lịch — nhẹ hơn điều phối

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bước nào hỏng | giao diện của bộ điều phối | | Luồng có chậm dần không | so thời lượng theo ngày | | Có bước nào chạy chồng không | kiểm tra khoá chống chạy song song |

Và một ranh giới đáng giữ nghiêm trong mọi kiến trúc dữ liệu: bộ điều phối ra lệnh, engine làm việc. Khi một tác vụ Airflow bắt đầu tự đọc và biến đổi hàng triệu dòng, ranh giới ấy đã bị vượt — và hệ quả thường thấy là môi trường điều phối trở thành nút thắt cho mọi pipeline khác trong tổ chức.

Đáp án

D — Model: khai KẾT NỐI CSDL và tập các Explore; View: đại diện MỘT BẢNG, nơi định nghĩa dimension và measure; Explore: khai QUAN HỆ JOIN giữa các view, tạo ra thực thể mà người dùng truy vấn.

Vì sao đúng

Ba thành phần cốt lõi của LookML có vai trò rất rõ ràng, và chỉ phương án này mô tả đúng cả ba.

⚠ Điểm mấu chốt — ba tầng, từ dưới lên:

VIEW  (tầng dưới cùng)
    → ánh xạ tới MỘT BẢNG trong CSDL
    → nơi khai DIMENSION và MEASURE
      dimension: thuộc tính để cắt lớp
      measure:   chỉ số tổng hợp
        ↓
EXPLORE  (tầng giữa)
    → chọn một view làm gốc
    → khai JOIN sang các view khác
    → là ĐIỂM VÀO cho người dùng
      trong giao diện Looker
        ↓
MODEL  (tầng trên cùng)
    → khai KẾT NỐI tới CSDL
    → gom các Explore nào được dùng

⚠ Ví dụ với users, orders, products trong đề:

# view: orders.view.lkml
view: orders {
  sql_table_name: cua_hang.orders ;;
  dimension: id { primary_key: yes }
  dimension_group: created { type: time }
  measure: tong_doanh_thu {
    type: sum
    sql: ${TABLE}.amount ;;
  }
}

# model: cua_hang.model.lkml
connection: "bigquery_cua_hang"
include: "/views/*.view.lkml"

explore: orders {
  join: users {
    sql_on: ${orders.user_id} = ${users.id} ;;
    relationship: many_to_one
  }
  join: products {
    sql_on: ${orders.product_id} = ${products.id} ;;
    relationship: many_to_one
  }
}

⚠ Vì sao các phương án khác lẫn lộn vai trò:

Nhầm phổ biến 1
    "Model khai JOIN"
        ↓
    ⚠ SAI — JOIN khai trong EXPLORE
      (explore thì viết BÊN TRONG tệp model,
       nên rất dễ nhầm)

Nhầm phổ biến 2
    "View khai JOIN, Explore là bảng"
        ↓
    ⚠ ĐẢO NGƯỢC hoàn toàn

Nhầm phổ biến 3
    "Model là dashboard, View là ô biểu đồ"
        ↓
    ⚠ Nhầm sang khái niệm giao diện,
      không phải LookML

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

Nội dung các phương án còn giữ nguyên chữ cái của bản gốc (D), C), B), A)), không khớp với nhãn A/B/C/D hiện tại — bộ đề đã xáo thứ tự nhưng không xoá chữ cái cũ trong nội dung.

Điều này KHÔNG làm thay đổi khoá đáp án: phương án được chọn là nhãn D, và nội dung của nó (mang chữ cái gốc "A)") hoàn toàn chính xác. Khi làm bài, hãy đọc nội dung và bỏ qua chữ cái nằm bên trong nội dung.

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

• A (Model khai join; Explore khai kết nối) — đây là phương án gần nhất vì mô tả View hoàn toàn đúng, nhưng nó đảo vai trò của Model và Explore: join khai trong Explore, còn kết nối khai trong Model.

• C (View khai join, Explore là bảng) — đảo ngược View và Explore.

• B (Model là dashboard, View là ô biểu đồ) — nhầm sang khái niệm giao diện; LookML là lớp mô hình, không phải lớp hiển thị.

Ghi nhớ

⚠ Ba thành phần LookML — bảng phải thuộc: | Thành phần | Vai trò | |---|---| | view | ánh xạ MỘT BẢNG; khai dimension và measure | | explore | khai JOIN giữa các view; ĐIỂM VÀO cho người dùng | | model | khai CONNECTION và tập các explore | | Bẫy | explore viết BÊN TRONG tệp model → dễ nhầm là model khai join |

Từ khoá nhận diện:

"kết nối CSDL" → model "bảng, dimension, measure" → view "join, điểm vào truy vấn" → explore "dashboard, biểu đồ" → giao diện Looker, không phải LookML "lọc dòng theo người dùng" → access_filter trong explore

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Explore sinh SQL gì | tab SQL trong giao diện Explore | | Join có nhân bản dòng không | so số dòng với truy vấn trực tiếp | | Chỉ số định nghĩa ở đâu | tìm measure trong kho LookML |

Và một lỗi rất hay gặp với người mới viết LookML, đáng nhớ hơn cả việc phân biệt ba thành phần: khai sai relationship trong join. Truy vấn vẫn chạy, biểu đồ vẫn vẽ, chỉ có điều doanh thu bị cộng lặp theo số dòng bên kia — và đó là loại sai lệch chỉ lộ ra khi ai đó tình cờ đối chiếu với báo cáo của phòng kế toán.

Đáp án

A — Bảo vệ CSDL sản xuất tại chỗ khỏi ảnh hưởng hiệu năng của các truy vấn phân tích.

Vì sao đúng

Mẫu "nhân bản rồi nạp" tách hẳn hệ thống vận hành khỏi hoạt động phân tích: mọi truy vấn nặng chạy trên bản sao trên đám mây, không chạm tới CSDL đang phục vụ khách hàng.

⚠ Điểm mấu chốt — so hai kiến trúc:

ETL TRỰC TIẾP từ CSDL tại chỗ
        ↓
    Pipeline ĐỌC THẲNG CSDL sản xuất
        ↓
    ⚠ Truy vấn quét bảng lớn
    ⚠ Tranh chấp khoá và tài nguyên
    ⚠ Ứng dụng khách hàng CHẬM ĐI
    ⚠ Đội DBA phản đối, và họ đúng

DMS + BQDTS (nhân bản rồi nạp)
        ↓
    DMS đọc NHẬT KÝ GIAO DỊCH
      → tải rất nhẹ lên nguồn
        ↓
    Cloud SQL — bản sao đầy đủ
        ↓
    Mọi thao tác phân tích chạy TỪ ĐÂY
        ↓
    → CSDL sản xuất KHÔNG bị ảnh hưởng

⚠ Vì sao đọc nhật ký lại nhẹ hơn hẳn truy vấn:

ETL truy vấn: SELECT * FROM don_hang
              WHERE ngay > ...
        ↓
    → quét bảng, dùng CPU và I/O của nguồn
    → có thể giữ khoá

CDC đọc binlog/WAL
        ↓
    → đọc TUẦN TỰ một tệp nhật ký
      mà CSDL vốn đã ghi ra
    → gần như không tạo tải truy vấn

⚠ Lợi ích kèm theo — không chỉ là hiệu năng:

- Bản sao trên đám mây dùng được cho
  môi trường thử nghiệm
- Là một bước trong kế hoạch di chuyển
  lên đám mây
- Tách bạch quyền: đội phân tích
  không cần quyền trên CSDL sản xuất
- Độ trễ thấp, gần thời gian thực

Xem thêm câu #13019 (cùng lô): hỏi vai trò của DMS trong chính mẫu này → tạo bản sao trong Cloud SQL. Câu này hỏi LỢI ÍCH LỚN NHẤT của mẫu. Hai câu bổ sung nhau — nhất quán.

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

• C (hiệu năng tốt hơn cho biến đổi phức tạp trên đường truyền) — đây là phương án gần nhất về mặt "ưu điểm kỹ thuật", nhưng ngược lại: mẫu này KHÔNG biến đổi trên đường; nó nhân bản nguyên vẹn rồi biến đổi sau. ETL trực tiếp mới là nơi biến đổi trên đường.

• B (quản lý ít dịch vụ hơn) — ngược: mẫu này dùng nhiều dịch vụ hơn (DMS + Cloud SQL + BQDTS/Datastream).

• D (là mô hình duy nhất hỗ trợ nạp luồng thời gian thực) — sai: Dataflow và Datastream cũng làm được, và mẫu này không phải "duy nhất".

Ghi nhớ

⚠ Hai mẫu đưa dữ liệu vận hành vào kho — bảng phải thuộc: | | ETL trực tiếp | Nhân bản rồi nạp | |---|---|---| | Tải lên nguồn | CAO — truy vấn quét bảng | THẤP — đọc nhật ký | | Số dịch vụ | ít hơn | nhiều hơn | | Bản sao vận hành | không có | có, dùng được cho việc khác | | Biến đổi | trên đường truyền | sau khi vào kho | | Độ phức tạp | thấp hơn | cao hơn | | Dùng khi | nguồn nhỏ, tải nhẹ | nguồn là hệ thống sản xuất quan trọng |

Từ khoá nhận diện:

"bảo vệ CSDL sản xuất khỏi truy vấn phân tích" → nhân bản rồi nạp "đọc nhật ký giao dịch" → CDC — tải nhẹ "biến đổi trên đường" → ETL trực tiếp "đơn giản, ít dịch vụ" → ETL trực tiếp "cần cả bản sao vận hành" → nhân bản rồi nạp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nguồn có bị ảnh hưởng không | theo dõi CPU và I/O trên máy chủ nguồn trước và sau | | Bản sao có bám kịp không | replication lag trong DMS console | | Dữ liệu ở BigQuery có mới không | SELECT MAX(<cột thời gian>) |

Và một lợi ích thường quyết định lựa chọn này trong thực tế, ngoài lý do kỹ thuật: đội quản trị CSDL đồng ý. Một pipeline đọc thẳng vào hệ thống sản xuất luôn là chủ đề tranh cãi kéo dài, còn một cơ chế nhân bản qua nhật ký giao dịch là thứ họ đã quen và tin tưởng — và điều đó thường rút ngắn dự án hơn bất kỳ tối ưu kỹ thuật nào.

Đáp án

C — Data Catalog (nay là Dataplex Universal Catalog).

Vì sao đúng

Đề nêu bốn yêu cầu: tự động phát hiện và lập danh mục dữ liệu ở BigQuery lẫn Cloud Storage, được quản lý hoàn toàn, cho phép tìm kiếm bằng thuật ngữ nghiệp vụ, và xem siêu dữ liệu kỹ thuật. Đó là toàn bộ mô tả của một data catalog.

⚠ Điểm mấu chốt — tự động lập danh mục, không phải nhập tay:

Dataplex Universal Catalog
        ↓
    TỰ ĐỘNG quét và lập danh mục:
      - dataset, bảng, view của BigQuery
      - tệp trong Cloud Storage
      - Pub/Sub topic, Spanner, Bigtable...
        ↓
    Thu thập SIÊU DỮ LIỆU KỸ THUẬT:
      lược đồ, kiểu cột, kích thước,
      thời điểm cập nhật
        ↓
    Cho phép gắn thêm SIÊU DỮ LIỆU NGHIỆP VỤ:
      mô tả, chủ sở hữu, thuật ngữ, tag
        ↓
    → tìm kiếm bằng NGÔN NGỮ NGHIỆP VỤ

⚠ Vì sao "tìm bằng thuật ngữ nghiệp vụ" lại quan trọng:

Nhà phân tích cần "doanh thu thuần"
        ↓
    ⚠ Không biết bảng tên là gì
    ⚠ Không biết nằm ở project nào
        ↓
    Không có catalog
        ↓
    → đi hỏi từng người
    → hoặc tự dựng lại bảng đã có
        ↓
    Có catalog
        ↓
    → gõ "doanh thu thuần" vào ô tìm kiếm
    → thấy bảng, chủ sở hữu, mô tả, lược đồ

⚠ Catalog không chỉ để tìm — nó là nền của quản trị:

Dataplex Universal Catalog còn là nơi:
    - định nghĩa TAXONOMY và POLICY TAG
      → dùng cho column-level security
    - quản lý DATA POLICY
      → dùng cho dynamic data masking
    - khai quy tắc CHẤT LƯỢNG DỮ LIỆU
    - theo dõi DÒNG DÕI (lineage)
      → dữ liệu này đến từ đâu
        ↓
    ⚠ Đây chính là lý do nó gắn với
      các câu hỏi về policy tag

Xem thêm câu #12965 (lô 134): dùng policy tag để chặn cột lương — policy tag được định nghĩa trong chính Dataplex Catalog. Và #12980 (lô 134): BigLake + policy tag cho data lake. Ba câu nhất quán — catalog là nền tảng chung.

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

• A (Cloud Asset Inventory) — đây là phương án gần nhất vì cũng "kiểm kê", nhưng nó lập danh mục TÀI NGUYÊN HẠ TẦNG (VM, bucket, quy tắc firewall, chính sách IAM) phục vụ quản trị và bảo mật; nó không lập danh mục NỘI DUNG DỮ LIỆU hay cho tìm kiếm bằng thuật ngữ nghiệp vụ.

• B (BigQuery) — là kho dữ liệu; nó có INFORMATION_SCHEMA nhưng không bao quát Cloud Storage và không có tìm kiếm nghiệp vụ.

• D (Cloud Storage) — chỉ là kho đối tượng.

Ghi nhớ

⚠ Ba công cụ "kiểm kê" hay bị nhầm — bảng phải thuộc: | Công cụ | Lập danh mục gì | |---|---| | Dataplex Universal Catalog | DỮ LIỆU: bảng, tệp, lược đồ, thuật ngữ nghiệp vụ | | Cloud Asset Inventory | TÀI NGUYÊN HẠ TẦNG: VM, bucket, IAM, firewall | | INFORMATION_SCHEMA | siêu dữ liệu của riêng BigQuery | | Security Command Center | rủi ro và lỗ hổng bảo mật | | Phân biệt | Catalog cho người dùng DỮ LIỆU; Asset Inventory cho người quản trị HẠ TẦNG |

Từ khoá nhận diện:

"tìm dữ liệu bằng thuật ngữ nghiệp vụ" → Dataplex Universal Catalog "kiểm kê VM, bucket, chính sách IAM" → Cloud Asset Inventory "lược đồ bảng BigQuery bằng SQL" → INFORMATION_SCHEMA "policy tag, phân loại nhạy cảm" → Dataplex Catalog "dữ liệu này đến từ đâu" → Data Lineage trong Dataplex

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Catalog đã quét được gì | tìm kiếm thử trong Dataplex → Search | | Bảng nào chưa có mô tả | lọc theo tài sản thiếu siêu dữ liệu | | Cột nhạy cảm đã gắn tag chưa | xem taxonomy và policy tag |

Và một sự thật quyết định catalog có giá trị hay không: phần đắt nhất không phải công nghệ, mà là mô tả do con người viết. Dataplex tự quét được lược đồ trong vài phút, nhưng câu trả lời cho "bảng này dùng để làm gì và hỏi ai khi số liệu sai" thì phải có người điền — và một catalog đầy bảng không mô tả chỉ là một danh sách tên bảng dài hơn.

Đáp án

C — Colab Enterprise.

Vì sao đúng

Đề nêu ba yêu cầu: dịch vụ được quản lý để giảm công vận hành, tích hợp an toàn với dữ liệu BigQuery sẵn có, và dựa trên công nghệ Jupyter Notebook quen thuộc. Colab Enterprise khớp cả ba.

⚠ Điểm mấu chốt — Jupyter được quản lý, tích hợp sẵn với GCP:

Colab Enterprise (trong Vertex AI)
        ↓
    - Giao diện Colab quen thuộc
    - KHÔNG phải quản lý máy chủ
    - Chạy dưới SERVICE ACCOUNT
      → không cần khoá JSON
    - Kết nối BigQuery bằng một dòng
    - Cộng tác như Google Docs
    - Kiểm soát bằng IAM và VPC-SC

⚠ Đọc BigQuery trong notebook:

%%bigquery df
SELECT ngay, SUM(doanh_thu) AS tong
FROM `du_an.ban_hang`
WHERE ngay >= '2026-01-01'
GROUP BY ngay

        ↓
    Hoặc:
      from google.cloud import bigquery
      client = bigquery.Client()
      df = client.query(sql).to_dataframe()
        ↓
    ⚠ Xác thực TỰ ĐỘNG qua service account

⚠ Vì sao tự cài Jupyter trên Compute Engine lại kém:

VM tự cài Jupyter
        ↓
    ⚠ Bạn phải lo:
      - vá hệ điều hành và thư viện
      - cấu hình HTTPS và xác thực
      - sao lưu notebook
      - tắt máy khi không dùng
      - quản lý khoá truy cập BigQuery
        ↓
    → trái hẳn yêu cầu "giảm công vận hành"
    → và là một bề mặt tấn công tự tạo

Xem thêm câu #12922 (lô 134): cùng tình huống, cùng khoá Vertex AI Notebooks / Colab Enterprise. Hai câu hoàn toàn nhất quán. Và #13031 (cùng lô) nói về lợi ích chạy lại notebook cho báo cáo định kỳ.

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

• A (Compute Engine tự cài Jupyter) — đây là phương án gần nhất về mặt "cũng có Jupyter", nhưng không phải dịch vụ được quản lý: mọi việc vá lỗi, bảo mật, sao lưu đều thuộc về bạn.

• B (Dataproc) — có notebook qua Jupyter component, nhưng nó là nền tảng Spark/Hadoop, nặng hơn nhiều nhu cầu, và phải quản lý cụm.

• D (Looker Studio) — công cụ trực quan hoá, không chạy được Python.

Ghi nhớ

⚠ Hai lựa chọn notebook của Vertex AI — bảng phải thuộc: | | Colab Enterprise | Vertex AI Workbench | |---|---|---| | Quản lý máy | KHÔNG cần | instance riêng, cấu hình sâu | | Khởi động | nhanh | chậm hơn | | Cộng tác | như Google Docs | theo instance | | Tuỳ chỉnh môi trường | hạn chế hơn | cài được thư viện hệ thống | | Chọn khi | khám phá, cộng tác, ít vận hành | môi trường ổn định lâu dài | | Điểm chung | service account, tích hợp BigQuery, IAM |

Từ khoá nhận diện:

"Jupyter được quản lý, tích hợp BigQuery" → Colab Enterprise "cần cài thư viện hệ thống, đĩa lớn" → Vertex AI Workbench "phân tích bằng SQL" → BigQuery UI "dashboard" → Looker Studio "tự cài Jupyter trên VM" → trái yêu cầu dịch vụ được quản lý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Notebook chạy dưới danh nghĩa ai | !gcloud auth list trong một ô lệnh | | Truy vấn tốn bao nhiêu | BigQuery → Job history | | Runtime nào đang chạy | Vertex AI → Colab Enterprise → Runtimes |

Và một cài đặt nên bật ngay khi tạo runtime đầu tiên: tự động tắt khi không hoạt động. Một môi trường notebook có GPU để quên qua kỳ nghỉ tốn hơn cả chi phí lưu trữ của toàn bộ dữ liệu mà nó đang phân tích — và đây là khoản lãng phí phổ biến nhất khi một đội khoa học dữ liệu mới chuyển lên đám mây.

Đáp án

A — Dataflow, vì đây là engine được tối ưu cao với ít chi phí phụ trội cho tác vụ xử lý dữ liệu thuần tuý.

Vì sao đúng

Đề đặt ưu tiên CAO NHẤT là giảm tiêu thụ tài nguyên và đạt hiệu năng xử lý tốt nhất, với logic biến đổi đơn giản (lọc dòng và ép kiểu) trên hàng terabyte mỗi ngày.

⚠ Điểm mấu chốt — Dataflow là engine xử lý thuần, không có lớp phụ trội:

DATAFLOW
        ↓
    - Không máy chủ, tự co giãn
    - Trả tiền theo TÀI NGUYÊN JOB DÙNG THẬT
    - KHÔNG có chi phí nền thường trực
    - Tối ưu sâu cho lọc và ánh xạ
      (Beam tự gộp các bước — "fusion")
        ↓
    → với logic đơn giản trên khối lượng lớn,
      đây là phương án hiệu quả nhất

⚠ Vì sao Data Fusion kém hiệu quả hơn ở đây:

Cloud Data Fusion
        ↓
    Là LỚP GIAO DIỆN trên CDAP
        ↓
    Sinh ra pipeline chạy trên DATAPROC
        ↓
    ⚠ Có chi phí instance THƯỜNG TRỰC
    ⚠ Thêm một tầng trừu tượng nữa
        ↓
    → giá trị của nó là KHÔNG CẦN LẬP TRÌNH
    → nhưng đề này KHÔNG nêu ràng buộc đó,
      mà nêu ưu tiên HIỆU NĂNG

⚠ Vì sao Dataproc không phải lựa chọn hiệu quả nhất:

Dataproc
        ↓
    Cho KIỂM SOÁT cụm chi tiết nhất
        ↓
    ⚠ Nhưng phải quản lý cụm
    ⚠ Cụm nhàn rỗi vẫn tính tiền
        ↓
    → hợp khi ĐÃ CÓ job Spark
    → không hợp khi mục tiêu là
      "ít tài nguyên nhất"

⚠ Với logic đơn giản, tối ưu Dataflow rất đáng làm:

- Đọc trực tiếp Parquet/Avro thay vì CSV
- FlexRS cho job theo lô chịu được trễ
  → dùng Spot VM, rẻ hơn đáng kể
- Dataflow Prime → tự điều chỉnh tài nguyên
- Storage Write API → ghi BigQuery hiệu quả
- Đặt --maxNumWorkers hợp lý

Xem thêm câu #13020 (cùng lô): khoá "Data Fusion HOẶC Dataflow" vì đề ở đó chỉ nhấn ETL phức tạp, không nêu tiêu chí phân biệt. Và #13021 (cùng lô): khoá Data Fusion vì nhấn đội không lập trình. Ba câu, ba khoá, phân biệt bằng TIÊU CHÍ được nhấn mạnh — hoàn toàn nhất quán.

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

• D (Cloud Data Fusion vì giao diện trực quan) — đây là phương án gần nhất và lý do nêu ra là đúng về Data Fusion, nhưng "giao diện đơn giản hoá việc dựng pipeline" không phải tiêu chí của đề; đề ưu tiên hiệu năng và tiết kiệm tài nguyên.

• C (Dataproc vì kiểm soát cụm tốt nhất) — kiểm soát chi tiết không phải mục tiêu, và quản lý cụm làm tăng tiêu thụ tài nguyên.

• B (Cloud Run vì nhẹ nhất) — Cloud Run không phải engine xử lý dữ liệu song song; xử lý terabyte mỗi ngày bằng nó là tự dựng lại Dataflow bằng tay.

Ghi nhớ

⚠ Chọn engine theo TIÊU CHÍ được nhấn mạnh — bảng phải thuộc: | Tiêu chí trong đề | Chọn | |---|---| | Hiệu năng, ít tài nguyên, khối lượng lớn | Dataflow | | Đội không lập trình, trực quan | Cloud Data Fusion | | Đã có job Spark/Hadoop | Dataproc | | Chỉ SQL, dữ liệu đã ở BigQuery | Dataform / BigQuery | | Tác vụ nhỏ theo sự kiện | Cloud Run function | | Nguyên tắc | đọc kỹ TIÊU CHÍ, không chỉ mô tả công việc |

Từ khoá nhận diện:

"hiệu năng tốt nhất, ít tài nguyên nhất" → Dataflow "không lập trình, kéo thả" → Cloud Data Fusion "kiểm soát cụm, đã có Spark" → Dataproc "một tệp, một hành động nhỏ" → Cloud Run function "chỉ lọc và ép kiểu" → cũng cân nhắc nạp thẳng + SQL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Job tốn bao nhiêu tài nguyên | Job metrics → vCPU và bộ nhớ theo thời gian | | Bước nào là nút thắt | Job graph, xem throughput từng bước | | Chi phí thực tế | billing export, so với phương án khác |

Và một câu hỏi đáng đặt ra trước khi dựng bất kỳ pipeline nào cho logic đơn giản như "lọc dòng và ép kiểu": có cần một engine xử lý riêng không? Nạp thẳng tệp vào BigQuery là miễn phí, và một câu SQL làm được cả hai việc đó — nếu tỉ lệ dòng bị loại không quá lớn, cách ấy vừa nhanh hơn vừa không có hạ tầng nào phải vận hành.