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

Đáp án

A — Dataform.

Vì sao đúng

Đề nêu ba yêu cầu, và Dataform được thiết kế quanh đúng ba thứ đó: định nghĩa mọi phép biến đổi bằng câu SELECT, quản lý phiên bản, và kiểm thử được.

⚠ Điểm mấu chốt — mỗi bảng là một câu SELECT:

-- definitions/khach_hang_sach.sqlx
config {
  type: "table",
  schema: "staging"
}

SELECT
  customer_id,
  TRIM(LOWER(email)) AS email,
  INITCAP(ten) AS ten
FROM ${ref("khach_hang_tho")}
WHERE customer_id IS NOT NULL

        ↓
    ⚠ ref() khai PHỤ THUỘC
    → Dataform tự dựng ĐỒ THỊ
      và chạy đúng thứ tự

⚠ Kiểm thử ngay trong pipeline — assertions:

config {
  type: "table",
  assertions: {
    uniqueKey: ["customer_id"],
    nonNull: ["customer_id", "email"],
    rowConditions: [
      "tuoi BETWEEN 0 AND 120"
    ]
  }
}

        ↓
    ⚠ Assertion THẤT BẠI → pipeline DỪNG
    → dữ liệu hỏng KHÔNG chảy tiếp
      xuống bảng báo cáo

⚠ Ba thứ Dataform mang lại mà SQL rời rạc không có:

1. PHỤ THUỘC tự động
    → ref() thay cho việc nhớ thứ tự chạy

2. GIT
    → review, lịch sử, quay lui
    → môi trường dev tách khỏi production

3. ASSERTION
    → chất lượng dữ liệu kiểm ngay
      trong luồng, không phải kiểm tay

Xem thêm câu #12915 (lô 133) và #12981 (lô 134): cả hai khoá Cloud Data Fusion, vì ở đó đội KHÔNG lập trình được và cần giao diện kéo thả. Câu này đội giỏi SQL và cần phiên bản + kiểm thử → Dataform. Ba khoá khác nhau vì kỹ năng và yêu cầu của đội khác nhau — không mâu thuẫn.

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

• C (Cloud Data Fusion) — đây là phương án gần nhất vì cũng là công cụ biến đổi ít mã, nhưng nó là giao diện KÉO THẢ, không phải quy trình "SQL-first"; và không có quản lý phiên bản bằng Git theo cách Dataform có.

• B (Dataflow) — đòi viết Apache Beam bằng Java hoặc Python.

• D (Dataproc) — đòi viết Spark.

Ghi nhớ

⚠ Chọn công cụ biến đổi theo kỹ năng của đội — bảng phải thuộc: | Đội | Công cụ | |---|---| | Giỏi SQL, cần phiên bản và kiểm thử | Dataform | | Không lập trình, cần kéo thả | Cloud Data Fusion | | Kỹ sư Python/Java | Dataflow | | Đã có hệ sinh thái Spark | Dataproc | | Chỉ cần chạy một truy vấn theo lịch | scheduled query | | Điều phối nhiều dịch vụ | Cloud Composer |

Từ khoá nhận diện:

"SQL-first, Git, kiểm thử" → Dataform "kéo thả, không cần mã" → Cloud Data Fusion "biến đổi luồng quy mô lớn" → Dataflow "một truy vấn mỗi sáng" → scheduled query "nhiều dịch vụ, phụ thuộc phức tạp" → Cloud Composer

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ó đang chạy không | xem kết quả workflow execution | | Chi phí bao nhiêu | INFORMATION_SCHEMA.JOBS, lọc theo nhãn Dataform |

Và một tính năng nên dùng ngay từ mô hình đầu tiên, chứ không để dành: assertions. Một dòng khai uniqueKey và nonNull biến lỗi dữ liệu từ thứ được phát hiện sau vài tuần bởi một người dùng khó tính, thành thứ làm dừng pipeline ngay trong lần chạy đầu tiên — và đó là khác biệt lớn nhất giữa một chuỗi truy vấn SQL và một pipeline dữ liệu đáng tin.

Đáp án

B — Chuyển sang Nearline sau 90 ngày, rồi chuyển tiếp sang Archive sau 365 ngày.

Vì sao đúng

Đề mô tả ba giai đoạn truy cập khác nhau, nên chính sách vòng đời cũng phải có hai lần chuyển lớp khớp với ba giai đoạn đó.

⚠ Điểm mấu chốt — ánh xạ từng giai đoạn vào một lớp:

0–3 tháng: truy cập HẰNG NGÀY
        ↓
    STANDARD (mặc định, không cần quy tắc)

4–12 tháng: khoảng MỘT LẦN MỖI THÁNG
        ↓
    NEARLINE (khuyến nghị ~1 lần/tháng)
    → quy tắc: age = 90 ngày

> 12 tháng: giữ 7 năm, GẦN NHƯ KHÔNG ĐỌC
        ↓
    ARCHIVE (khuyến nghị <1 lần/năm)
    → quy tắc: age = 365 ngày

⚠ Ràng buộc "giữ 7 năm" loại bỏ mọi phương án có Delete:

Yêu cầu tuân thủ: GIỮ 7 NĂM
        ↓
    ⚠ Bất kỳ quy tắc `Delete` nào
      trước 7 năm đều VI PHẠM
        ↓
    → phương án xoá sau 365 ngày
      bị loại ngay lập tức

⚠ Tệp quy tắc:

{"lifecycle": {"rule": [
  {"action": {"type": "SetStorageClass",
              "storageClass": "NEARLINE"},
   "condition": {"age": 90,
                 "matchesStorageClass": ["STANDARD"]}},
  {"action": {"type": "SetStorageClass",
              "storageClass": "ARCHIVE"},
   "condition": {"age": 365,
                 "matchesStorageClass": ["NEARLINE"]}}
]}}

        ↓
    ⚠ matchesStorageClass giúp quy tắc
      rõ ràng và không chồng chéo

⚠ Vì sao "chuyển thẳng sang Archive sau 90 ngày" là sai:

Archive tính PHÍ TRUY XUẤT CAO NHẤT
        ↓
    Giai đoạn 4–12 tháng vẫn đọc
    MỖI THÁNG MỘT LẦN
        ↓
    → phí truy xuất trong 9 tháng đó
      có thể vượt phần tiết kiệm được
        ↓
    ⚠ Và Archive có thời gian lưu tối thiểu
      365 NGÀY → chuyển sớm là chồng
      thêm rủi ro phí xoá sớm nếu đổi ý

Xem thêm câu #12935 (lô 134): cùng dùng lifecycle nhưng hành động là Delete cho bucket tạm. Và #12918/#12923 (lô 134): chọn lớp theo tần suất. Cùng một quy tắc nền tảng, áp vào các tình huống khác nhau — nhất quán.

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

• A (Coldline sau 90 ngày, XOÁ sau 365 ngày) — đây là phương án gần nhất về cấu trúc hai bước, nhưng nó XOÁ dữ liệu sau một năm — vi phạm trực tiếp yêu cầu giữ 7 năm.

• D (chuyển thẳng sang Archive sau 90 ngày) — bỏ qua giai đoạn giữa; phí truy xuất Archive cho những lần đọc hằng tháng sẽ rất đắt.

• C (giữ tất cả ở Standard) — an toàn nhưng đắt nhất; không tối ưu chi phí như đề yêu cầu.

Ghi nhớ

⚠ Ánh xạ tần suất → lớp lưu trữ — bảng phải thuộc: | Tần suất | Lớp | Tối thiểu | |---|---|---| | Hằng ngày | Standard | không có | | ~1 lần/tháng | Nearline | 30 ngày | | ~1 lần/quý | Coldline | 90 ngày | | <1 lần/năm | Archive | 365 ngày | | Nguyên tắc | chuyển DẦN theo tuổi, đừng nhảy cóc |

Từ khoá nhận diện:

"giữ N năm để tuân thủ" → KHÔNG được có Delete sớm "gần như không đọc" → Archive "mỗi tháng một lần" → Nearline "tự động theo tuổi" → lifecycle rule SetStorageClass "không đoán được mẫu truy cập" → Autoclass

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách hiện tại | gcloud storage buckets describe gs://b --format="value(lifecycle)" | | Đối tượng đang ở lớp nào | gsutil stat gs://b/obj → Storage class | | Chi phí theo lớp | billing export, nhóm theo SKU |

Và một lớp bảo vệ nên thêm vào bên cạnh lifecycle khi có yêu cầu giữ dữ liệu 7 năm: retention policy kèm Bucket Lock. Lifecycle chuyển lớp đúng như thiết kế, nhưng nó không ngăn được một người có quyền xoá nhầm cả thư mục — còn retention policy đã khoá thì kể cả chủ project cũng không xoá được trước hạn.

Đáp án

B — Trong ETL, việc biến đổi diễn ra TRƯỚC khi nạp vào kho; trong ELT, nó diễn ra SAU.

Vì sao đúng

Khác biệt cơ bản nằm đúng ở thứ tự các chữ cái trong tên gọi — và thứ tự đó quyết định nơi phép biến đổi chạy.

⚠ Điểm mấu chốt — đọc chính tên viết tắt:

E T L = Extract → TRANSFORM → Load
        ↓
    Biến đổi Ở NGOÀI kho
    Chỉ dữ liệu ĐÃ SẠCH mới vào kho

E L T = Extract → Load → TRANSFORM
        ↓
    Nạp DỮ LIỆU THÔ vào kho trước
    Biến đổi BÊN TRONG kho bằng SQL

⚠ Hệ quả kéo theo từ khác biệt đó:

ETL
    → kho chỉ có dữ liệu sạch
    → tốn ít dung lượng hơn
    → ⚠ đổi logic phải TRÍCH XUẤT LẠI
      từ hệ thống nguồn
    → cần hạ tầng xử lý riêng

ELT
    → kho có CẢ dữ liệu thô
    → chạy lại được bất cứ lúc nào
    → tận dụng sức mạnh của kho
    → ⚠ dữ liệu nhạy cảm nằm trong kho

⚠ Vì sao ELT thịnh hành cùng với kho hiện đại:

Kho cũ (on-premise, đắt, cứng)
        ↓
    → phải tiết kiệm tài nguyên kho
    → biến đổi ở ngoài = ETL

Kho hiện đại (BigQuery, co giãn, rẻ)
        ↓
    → biến đổi trong kho nhanh và rẻ hơn
    → lưu trữ rẻ, giữ được bản thô
    → ELT thành mặc định

Xem thêm câu #12989 (cùng lô): hỏi ƯU ĐIỂM của ELT → giữ được dữ liệu thô. #12958 (lô 134): nhận diện TÊN của luồng → ELT. #12913 (lô 133): khoá ETL vì phải che PII trước khi nạp. Bốn câu, một hệ thống khái niệm nhất quán.

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

• A (ETL hiện đại, ELT là cũ) — ngược hoàn toàn: ETL là mô hình cũ hơn, ELT phổ biến cùng với kho đám mây.

• C (ETL cho dữ liệu lô, ELT cho luồng) — sai: cả hai đều xử lý được cả lô lẫn luồng; đó không phải điểm phân biệt.

• D (ETL cần Python/Java, ELT luôn không cần mã) — sai: ETL có công cụ kéo thả (Data Fusion), còn ELT vẫn cần viết SQL.

Ghi nhớ

⚠ ETL ↔ ELT — bảng phải thuộc: | | ETL | ELT | |---|---|---| | Thứ tự | E → T → L | E → L → T | | Nơi biến đổi | ngoài kho | trong kho | | Dữ liệu thô trong kho | không | có | | Chạy lại logic mới | trích xuất lại từ nguồn | chạy lại từ bảng thô | | Thời đại | cũ hơn | hiện đại, mặc định với kho đám mây | | Hợp khi | PII không được vào kho | hầu hết trường hợp còn lại |

Từ khoá nhận diện:

"biến đổi trước khi nạp" → ETL "nạp thô rồi biến đổi bằng SQL" → ELT "che PII trước khi vào kho" → bắt buộc ETL "giữ bản thô để chạy lại" → ưu điểm ELT "đưa dữ liệu từ kho ra CRM" → Reverse ETL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kho có dữ liệu thô không | xem dataset raw có tồn tại | | Chạy lại có ra cùng kết quả không | kiểm thử tính lặp lại được | | Có PII trong tầng raw không | quét bằng Sensitive Data Protection |

Và một cách nhớ dứt điểm cho phòng thi: đọc chính chữ viết tắt. ETL có chữ T ở giữa nên biến đổi nằm giữa trích xuất và nạp; ELT có chữ T ở cuối nên biến đổi là bước cuối, sau khi dữ liệu đã vào kho. Mọi khác biệt còn lại — dung lượng, khả năng chạy lại, rủi ro tuân thủ — đều là hệ quả của đúng một chi tiết ấy.

Đáp án

B — Dùng loại subscription "Pub/Sub to Cloud Storage".

Vì sao đúng

Đề nêu bốn ràng buộc: lưu trữ dữ liệu ở dạng THÔ, không thay đổi, trực tiếp nhất, không máy chủ, và KHÔNG viết mã. Cloud Storage subscription làm đúng việc đó mà không cần dịch vụ trung gian nào.

⚠ Điểm mấu chốt — Pub/Sub tự ghi thẳng thành tệp:

Thiết bị IoT
        ↓
    Pub/Sub topic
        ↓
    CLOUD STORAGE SUBSCRIPTION
        ↓
    ⚠ Pub/Sub TỰ gom thông điệp
      và ghi thành tệp trong bucket
        ↓
    → KHÔNG có Dataflow
    → KHÔNG có Cloud Function
    → KHÔNG có mã nào phải bảo trì

⚠ Cấu hình:

gcloud pubsub subscriptions create luu-tru \
  --topic=du-lieu-thiet-bi \
  --cloud-storage-bucket=bucket-luu-tru \
  --cloud-storage-file-prefix=iot/ \
  --cloud-storage-max-duration=5m \
  --cloud-storage-max-bytes=100MB
        ↓
    Tệp được đóng khi ĐẾN NGƯỠNG
    thời gian HOẶC dung lượng,
    tuỳ cái nào tới trước
        ↓
    Định dạng: TEXT (mặc định) hoặc AVRO

⚠ Vì sao "dạng thô, không thay đổi" lại quan trọng:

Yêu cầu tuân thủ: lưu NGUYÊN VẸN
        ↓
    ⚠ Mọi bước xử lý ở giữa đều là
      chỗ dữ liệu CÓ THỂ bị đổi
        ↓
    Subscription ghi thẳng
        ↓
    → ít khâu nhất = ít rủi ro nhất
    → cũng là kiến trúc dễ giải trình
      với kiểm toán nhất

⚠ Bốn loại subscription — nhắc lại:

PULL                    → bên nhận tự lấy
PUSH                    → gọi HTTP tới endpoint
BIGQUERY subscription   → ghi thẳng vào bảng
CLOUD STORAGE subscription → ghi thẳng thành tệp  ← đề này
        ↓
    Hai loại cuối: KHÔNG CẦN MÃ, không cần
    dịch vụ tính toán nào

Xem thêm câu #12949 và #12972 (lô 134): cùng chủ đề Pub/Sub nhưng ở đó có hai hệ thống xử lý riêng nên cần hai subscription và dịch vụ tính toán. Câu này chỉ lưu trữ, không xử lý → subscription ghi thẳng. Khoá khác nhau vì có hay không có bước xử lý — nhất quán.

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

• D (Dataflow với nguồn Pub/Sub và đích Cloud Storage) — đây là phương án gần nhất và hoàn toàn chạy được, thậm chí có template dựng sẵn, nhưng nó thêm một dịch vụ phải vận hành và trả tiền cho việc mà Pub/Sub đã làm được một mình. Không phải "trực tiếp nhất, rẻ nhất".

• C (Cloud Function với trigger Pub/Sub) — phải viết mã, phải xử lý gom tệp, và tốn hơn khi khối lượng lớn.

• A (VM chạy script) — không phải serverless, công vận hành cao nhất.

Ghi nhớ

⚠ Bốn loại subscription của Pub/Sub — bảng phải thuộc: | Loại | Đích | Cần mã? | |---|---|---| | Pull | worker tự lấy | có | | Push | endpoint HTTP | có | | BigQuery subscription | bảng BigQuery | KHÔNG | | Cloud Storage subscription | tệp trong bucket | KHÔNG | | Hai loại cuối | luôn cân nhắc TRƯỚC khi dựng Dataflow |

Từ khoá nhận diện:

"lưu thông điệp thô thành tệp, không cần mã" → Cloud Storage subscription "nạp thẳng vào BigQuery, không biến đổi" → BigQuery subscription "cần biến đổi, tổng hợp, cửa sổ" → Dataflow "một đoạn mã nhỏ theo sự kiện" → Cloud Run function "hai hệ thống độc lập cùng nhận" → hai subscription

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tệp có được ghi không | gcloud storage ls gs://bucket/iot/ | | Có thông điệp tồn đọng không | num_undelivered_messages của subscription | | Dữ liệu có nguyên vẹn không | so số thông điệp publish với số dòng trong tệp |

Và một quyết định nên cân nhắc ngay khi tạo subscription, vì sau này khó đổi: chọn định dạng Avro thay vì text. Avro giữ được thuộc tính thông điệp và dấu thời gian publish, đọc bằng BigQuery hiệu quả hơn hẳn, và không tốn thêm gì so với text — trong khi một kho lưu trữ text thuần sẽ khiến mọi phân tích về sau phải bắt đầu bằng một bước phân tích cú pháp.

Đáp án

B — BigQuery Data Editor (roles/bigquery.dataEditor).

Vì sao đúng

Đề tách rất rõ hai nhóm: được TẠO, SỬA, XOÁ BẢNG trong dataset, nhưng KHÔNG được đổi thuộc tính dataset hay cấp quyền cho người khác. Đó chính là ranh giới giữa dataEditor và dataOwner.

⚠ Điểm mấu chốt — ranh giới dataEditor ↔ dataOwner:

roles/bigquery.dataEditor
        ↓
    CÓ:
      tạo, sửa, xoá BẢNG và VIEW
      đọc và ghi DỮ LIỆU
      liệt kê bảng
        ↓
    KHÔNG CÓ:
      đổi thuộc tính DATASET
      setIamPolicy — cấp quyền cho người khác
      xoá chính DATASET

roles/bigquery.dataOwner
        ↓
    = dataEditor
      + quản lý QUYỀN của dataset
      + xoá dataset
        ↓
    ⚠ Đúng hai thứ đề CẤM

⚠ Cấp trên DATASET, không cấp trên project:

bq add-iam-policy-binding \
  --member="user:engineer@congty.com" \
  --role="roles/bigquery.dataEditor" \
  du_an:dataset_cua_doi
        ↓
    ⚠ Cấp ở cấp project → sửa được
      MỌI dataset trong project
        ↓
    Quyền tối thiểu = vai trò hẹp nhất
                    Ở PHẠM VI hẹp nhất

⚠ Đừng quên jobUser nếu họ cần chạy truy vấn:

dataEditor cho quyền TRÊN DỮ LIỆU
        ↓
    Nhưng chạy truy vấn hay nạp dữ liệu
    = tạo JOB
        ↓
    → cần thêm roles/bigquery.jobUser
      trên PROJECT
        ↓
    ⚠ Đề chỉ hỏi vai trò trên DATASET
      nên đáp án là dataEditor

Xem thêm câu #12975 (lô 134): cũng khoá roles/bigquery.dataEditor cho service account ghi dữ liệu. Hai câu CÙNG KHOÁ, cùng lý do — hoàn toàn nhất quán. Và #12957 (lô 134) khoá dataViewer + jobUser cho người chỉ đọc.

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

• C (BigQuery Data Owner) — đây là phương án gần nhất và làm được mọi việc đề cần, nhưng nó thêm quyền đổi thuộc tính dataset và cấp quyền cho người khác — đúng hai điều đề cấm.

• A (BigQuery Admin) — toàn quyền BigQuery trên cả project, rộng hơn hẳn.

• D (BigQuery User) — cho phép chạy job và tạo dataset MỚI, nhưng không cho quyền sửa dữ liệu trong dataset đã có — không đáp ứng yêu cầu.

Ghi nhớ

⚠ Bốn vai trò BigQuery hay bị nhầm — bảng phải thuộc: | Vai trò | Cho phép | |---|---| | bigquery.dataViewer | đọc dữ liệu và siêu dữ liệu | | bigquery.dataEditor | + tạo, sửa, xoá BẢNG; ghi dữ liệu | | bigquery.dataOwner | + quản lý QUYỀN dataset, xoá dataset | | bigquery.user | chạy job + TẠO DATASET mới — không sửa dataset của người khác | | bigquery.jobUser | chỉ chạy job | | bigquery.admin | toàn quyền |

Từ khoá nhận diện:

"tạo và xoá BẢNG, không đụng dataset" → dataEditor "quản lý ai được vào dataset" → dataOwner "chỉ đọc" → dataViewer "chạy truy vấn" → jobUser (kèm quyền dữ liệu) "tự tạo dataset riêng để làm việc" → bigquery.user

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có quyền trên dataset | bq show --format=prettyjson <dataset> → access | | Vai trò gồm quyền nào | gcloud iam roles describe roles/bigquery.dataEditor | | Có quyền thừa không | IAM Recommender |

Và một chi tiết quyết định trong mọi câu hỏi về quyền tối thiểu: phạm vi cấp quan trọng ngang với tên vai trò. dataEditor trên một dataset là mức hợp lý cho một kỹ sư dữ liệu; cùng vai trò ấy cấp ở cấp project lại cho phép họ xoá bảng trong mọi dataset của công ty — và hai tình huống đó trông giống hệt nhau nếu chỉ đọc tên vai trò.

Đáp án

D — Cloud Composer.

Vì sao đúng

Đề mô tả hai dịch vụ KHÁC NHAU phải chạy theo thứ tự, với ràng buộc bước sau chỉ khởi động khi bước trước THÀNH CÔNG. Quản lý phụ thuộc xuyên dịch vụ là việc của bộ điều phối.

⚠ Điểm mấu chốt — DAG diễn đạt đúng ràng buộc trong đề:

with DAG('tong_hop_va_ml', schedule='0 3 * * *') as dag:
    tong_hop = BigQueryInsertJobOperator(
        task_id='chay_stored_procedure',
        configuration={'query': {
            'query': 'CALL du_an.tong_hop_ngay();',
            'useLegacySql': False}})

    ml = DataprocSubmitJobOperator(
        task_id='spark_ml',
        job={...})

    tong_hop >> ml

        ↓
    ⚠ Dấu >> = "chỉ chạy ml khi tong_hop XONG
      và THÀNH CÔNG"
    → thất bại thì ml KHÔNG chạy
    → và Composer tự thử lại theo cấu hình

⚠ Vì sao Cloud Scheduler không đủ:

Cloud Scheduler
        ↓
    Chỉ kích hoạt MỘT đích theo giờ
        ↓
    Muốn hai bước → đặt hai job:
      03:00 chạy stored procedure
      03:30 chạy Dataproc
        ↓
    ⚠ Nếu bước 1 mất 45 phút thì sao?
    ⚠ Nếu bước 1 THẤT BẠI thì sao?
      → bước 2 vẫn chạy trên dữ liệu cũ
        ↓
    → "đợi 30 phút" KHÔNG PHẢI phụ thuộc

⚠ Composer có sẵn operator cho cả hai dịch vụ:

BigQueryInsertJobOperator      → chạy truy vấn, gọi procedure
BigQueryCheckOperator          → kiểm tra kết quả
DataprocSubmitJobOperator      → nộp job Spark
DataprocCreateClusterOperator  → tạo cụm tạm
DataprocDeleteClusterOperator  → xoá cụm sau khi xong
        ↓
    ⚠ Không phải viết mã gọi API

Xem thêm câu #12948 (lô 134): cùng khoá Cloud Composer, cùng lý do phụ thuộc nhiều bước. Và #12970 (lô 134) hỏi loại công cụ → orchestration. Ba câu nhất quán. Còn #12934 (lô 134) khoá Cloud Scheduler vì ở đó chỉ có một lời gọi duy nhất.

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

• B (Cloud Workflows) — đây là phương án gần nhất và thật sự làm được luồng tuần tự này, nhẹ và rẻ hơn Composer. Nhưng câu hỏi nhấn mạnh "quản lý phụ thuộc xuyên dịch vụ" trong một quy trình điều phối, và Composer là dịch vụ được thiết kế cho việc đó — với DAG, backfill, thử lại theo tác vụ và giao diện theo dõi đầy đủ.

• C (Cloud Scheduler) — chỉ kích hoạt theo giờ, không biết bước trước có thành công hay không.

• A (Eventarc) — định tuyến sự kiện tới đích; không phải bộ điều phối có DAG.

Ghi nhớ

⚠ Chọn công cụ theo độ phức tạp của luồng — bảng phải thuộc: | Nhu cầu | Công cụ | |---|---| | Một lời gọi theo giờ | Cloud Scheduler | | Chuỗi vài bước, ít phụ thuộc | Cloud Workflows | | DAG phức tạp, nhiều dịch vụ, backfill | Cloud Composer | | Phản ứng theo sự kiện | Eventarc + Cloud Run | | Chỉ toàn SQL trong BigQuery | Dataform | | Chỉ trong Dataproc | Dataproc Workflow Template |

Từ khoá nhận diện:

"bước sau chạy khi bước trước THÀNH CÔNG" → điều phối, Composer "đợi N phút rồi chạy bước hai" → KHÔNG phải phụ thuộc — là bẫy "một endpoint đúng giờ" → Cloud Scheduler "vài lời gọi API nối nhau, muốn rẻ" → Workflows "sự kiện từ dịch vụ GCP" → Eventarc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bước nào hỏng | Airflow Graph view — ô đỏ | | Vì sao hỏng | log của task, và log của dịch vụ tương ứng | | Luồng có chậm dần không | Gantt view |

Và một cái bẫy đáng nhớ khi ai đó đề xuất "cứ đặt hai job cách nhau 30 phút cho đơn giản": đó không phải là phụ thuộc, đó là hy vọng. Ngày mà bảng nguồn lớn gấp đôi và stored procedure chạy 45 phút, job Spark vẫn khởi động đúng giờ và xử lý dữ liệu của hôm qua — không có lỗi nào, chỉ có một báo cáo sai mà phải mất vài ngày mới có người nhận ra.

Đáp án

A — Dataproc Serverless cho ÍT quyền kiểm soát chi tiết cấu hình cụm hơn, đổi lại là sự ĐƠN GIẢN trong vận hành.

Vì sao đúng

Đây đúng là đánh đổi trung tâm của mọi dịch vụ không máy chủ: bạn giao quyền điều khiển hạ tầng cho nhà cung cấp, và nhận lại việc không phải vận hành nó.

⚠ Điểm mấu chốt — so hai cách chạy Spark:

DATAPROC TRÊN COMPUTE ENGINE
        ↓
    Bạn quyết định:
      loại máy, số worker, đĩa,
      phiên bản Spark và thư viện,
      initialization action,
      autoscaling policy, network
        ↓
    → kiểm soát tối đa
    → nhưng PHẢI vận hành cụm

DATAPROC SERVERLESS        ← đề này
        ↓
    Bạn chỉ nộp job
        ↓
    Google lo tài nguyên, co giãn,
    vá lỗi, dọn dẹp
        ↓
    → đơn giản tối đa
    → nhưng ÍT tuỳ chỉnh hơn

⚠ Nộp job serverless — ngắn tới mức nào:

gcloud dataproc batches submit spark \
  --region=asia-southeast1 \
  --jar=gs://bucket/job.jar \
  -- arg1 arg2
        ↓
    ⚠ Không có tên cụm
    ⚠ Không có số worker
    ⚠ Không có gì để tắt sau khi xong

⚠ Vì sao ba phương án kia sai rõ ràng:

"Không hỗ trợ Python"
    → SAI: PySpark chạy tốt

"Phải tự co giãn hạ tầng"
    → SAI: nó TỰ co giãn — đó là
      điểm bán hàng chính

"Đắt hơn với job ngắn"
    → SAI: NGƯỢC LẠI.
      Job ngắn là nơi serverless RẺ NHẤT
      vì không phải trả cho thời gian
      dựng và nhàn rỗi của cụm

Xem thêm câu #12954 (lô 134): về Dataproc Workflow Template với managed cluster — cũng nhằm tránh cụm bị bỏ quên. Serverless đi xa hơn một bước: không có cụm nào cả.

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

• D (đắt hơn với job ngắn) — đây là phương án dễ nhầm nhất vì nghe hợp lý, nhưng ngược với thực tế: với job chạy rời rạc và ngắn, serverless thường rẻ hơn vì không phải trả cho thời gian khởi tạo và nhàn rỗi của cụm.

• B (không hỗ trợ Python) — sai; PySpark được hỗ trợ đầy đủ.

• C (phải tự co giãn hạ tầng) — sai; tự co giãn chính là điều serverless mang lại.

Ghi nhớ

⚠ Dataproc Serverless ↔ Dataproc trên Compute Engine — bảng phải thuộc: | | Serverless | Trên Compute Engine | |---|---|---| | Quản lý cụm | KHÔNG có cụm | bạn quản lý | | Kiểm soát cấu hình | hạn chế | chi tiết | | Co giãn | tự động | autoscaling policy | | Khởi động | nhanh, tính bằng phút | tạo cụm mất vài phút | | Chi phí job ngắn, rời rạc | rẻ hơn | đắt hơn | | Chi phí job liên tục, dày đặc | có thể đắt hơn | cụm thường trực rẻ hơn |

Từ khoá nhận diện:

"chạy Spark không muốn quản cụm" → Dataproc Serverless "cần cấu hình cụm rất đặc thù" → Dataproc trên Compute Engine "job Spark dùng lại có tham số" → Workflow Template "đã có Hadoop, HBase, Hive tại chỗ" → Dataproc cụm "không muốn dùng Spark chút nào" → Dataflow hoặc BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Job chạy ra sao | gcloud dataproc batches describe <id> --region=<r> | | Tốn bao nhiêu tài nguyên | chỉ số của batch trong Monitoring | | Có cụm nào bị bỏ quên không | gcloud dataproc clusters list |

Và một khoản chi phí nên rà soát ngay trong tuần này nếu tổ chức đang dùng Dataproc: danh sách cụm đang chạy. Một cụm dựng để thử nghiệm rồi quên tắt tiêu tiền đều đặn hai mươi bốn giờ mỗi ngày mà không sản xuất ra gì — và đó chính là loại chi phí mà Dataproc Serverless loại bỏ hoàn toàn về mặt cấu trúc, chứ không phải bằng kỷ luật.

Đáp án

C — Dữ liệu PHI CẤU TRÚC (unstructured data).

Vì sao đúng

Bài đăng mạng xã hội, đánh giá sản phẩm và bình luận video đều là văn bản tự do do con người viết — không có lược đồ, không có trường cố định, không có kiểu dữ liệu.

⚠ Điểm mấu chốt — ba loại dữ liệu:

CÓ CẤU TRÚC (structured)
    → bảng, lược đồ cố định
    → CSDL quan hệ, CSV
    → id, tên, giá, ngày

BÁN CẤU TRÚC (semi-structured)
    → CÓ thẻ đánh dấu nhưng lược đồ LINH HOẠT
    → JSON, XML, Avro, Parquet
    → mỗi bản ghi có thể có trường khác nhau

PHI CẤU TRÚC (unstructured)     ← đề này
    → KHÔNG có mô hình dữ liệu nội tại
    → văn bản tự do, ảnh, âm thanh, video

⚠ Cái bẫy quen thuộc — "nằm trong bảng" không có nghĩa là "có cấu trúc":

Bình luận lưu trong cột `noi_dung`
của một bảng BigQuery
        ↓
    ⚠ CỘT thì có cấu trúc
    ⚠ NỘI DUNG bên trong vẫn là
      VĂN BẢN PHI CẤU TRÚC
        ↓
    → phân tích cảm xúc phải xử lý
      chính phần văn bản đó

⚠ Phân tích cảm xúc trên Google Cloud:

Natural Language API
    → analyzeSentiment, analyzeEntities
    → mô hình dựng sẵn, gọi là dùng

BigQuery ML + mô hình Vertex AI
    → ML.GENERATE_TEXT, ML.UNDERSTAND_TEXT
    → chạy NGAY TRONG SQL trên bảng bình luận

Vertex AI
    → tinh chỉnh mô hình cho lĩnh vực riêng

Speech-to-Text / Video Intelligence
    → cho bình luận dạng âm thanh, video

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

Phương án A và D của câu này TRÙNG NHAU NGUYÊN VĂN — cả hai đều là "Semi-structured data". Đây là lỗi biên tập của bộ đề nguồn; nhiều khả năng một trong hai vốn phải là một loại khác (ví dụ "Time-series data" hoặc "Structured data").

Điều này KHÔNG làm thay đổi khoá đáp án: hai phương án trùng nhau đều sai, và C (phi cấu trúc) vẫn là câu trả lời đúng duy nhất. Gặp dạng này trong bài thi thật thì cứ chọn phương án đúng và bỏ qua sự trùng lặp — nó là lỗi soạn đề, không phải cái bẫy.

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

• A và D (bán cấu trúc) — đây là hai phương án gần nhất, và văn bản có thể được BỌC trong JSON khi thu thập; nhưng khi đó JSON chỉ là lớp vỏ vận chuyển, còn nội dung bình luận bên trong vẫn phi cấu trúc. Thứ đội marketing phân tích là nội dung, không phải lớp vỏ.

• B (có cấu trúc) — dữ liệu có cấu trúc có lược đồ cố định và kiểu rõ ràng; văn bản tự do không có.

Ghi nhớ

⚠ Ba loại dữ liệu — bảng phải thuộc: | Loại | Ví dụ | Lưu ở đâu trên GCP | |---|---|---| | Có cấu trúc | bảng quan hệ, CSV | BigQuery, Cloud SQL, Spanner | | Bán cấu trúc | JSON, XML, Avro, Parquet | BigQuery (JSON/STRUCT), Firestore, GCS | | Phi cấu trúc | văn bản, ảnh, âm thanh, video | Cloud Storage (+ object table) |

Từ khoá nhận diện:

"bài đăng, bình luận, đánh giá, ảnh, video" → phi cấu trúc "JSON, XML, log có thẻ" → bán cấu trúc "bảng có lược đồ cố định" → có cấu trúc "phân tích cảm xúc" → Natural Language API hoặc BigQuery ML "tệp trong GCS, muốn truy vấn bằng SQL" → object table / BigLake

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình gán cảm xúc có đúng không | đọc tay 100 mẫu ngẫu nhiên và so | | Có PII trong văn bản không | Sensitive Data Protection | | Chi phí gọi mô hình | billing export, lọc SKU Vertex AI |

Và một bước không nên bỏ qua trước khi báo cáo điểm cảm xúc cho ban lãnh đạo: đọc tay một mẫu ngẫu nhiên và so với nhãn mà mô hình gán. Mỉa mai, tiếng lóng và cách viết tắt của người Việt là những thứ mô hình đa ngôn ngữ hay đọc sai nhất — và một biểu đồ cảm xúc dựa trên nhãn sai sẽ dẫn tới những quyết định marketing rất tự tin theo hướng ngược lại.

Đáp án

C — Dataflow.

Vì sao đúng

Đề cần biến đổi dữ liệu LUỒNG giữa Pub/Sub và BigQuery: che PII trong trường user_email theo thời gian thực, với kiến trúc không máy chủ. Dataflow là dịch vụ xử lý luồng của Google Cloud cho đúng vị trí đó.

⚠ Điểm mấu chốt — Dataflow nằm ĐÚNG giữa hai đầu:

Ứng dụng
        ↓
    Pub/Sub topic
        ↓
    DATAFLOW (streaming)
      - đọc thông điệp
      - CHE PII trong user_email
      - ghi vào BigQuery
        ↓
    BigQuery — phân tích ngay
        ↓
    ⚠ Không máy chủ, tự co giãn
    ⚠ Xử lý từng thông điệp khi nó tới

⚠ Phép che trong pipeline:

class ChePII(beam.DoFn):
    def process(self, ban_ghi):
        email = ban_ghi.get('user_email', '')
        ban_ghi['user_email'] = hashlib.sha256(
            email.encode()).hexdigest()
        yield ban_ghi

        ↓
    Hoặc gọi Sensitive Data Protection API
    để phát hiện và che nhiều loại PII
        ↓
    ⚠ Băm giữ được khả năng NỐI BẢNG
      mà không lộ email gốc

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

Pub/Sub BigQuery subscription
        ↓
    Ghi THẲNG vào bảng, KHÔNG BIẾN ĐỔI
        ↓
    ⚠ Email THÔ sẽ vào BigQuery
    → vi phạm yêu cầu che PII
        ↓
    Cần biến đổi → phải có bước tính toán
    → Dataflow

Xem thêm câu #12994 (cùng lô): cùng đi từ Pub/Sub nhưng ở đó yêu cầu là lưu nguyên vẹn, KHÔNG biến đổi → khoá là Cloud Storage subscription. Hai khoá khác nhau vì có hay không có bước biến đổi — hoàn toàn nhất quán. Và #12951 (lô 134) cũng là Pub/Sub + Dataflow vì cần tổng hợp theo cửa sổ.

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

• D (Cloud Functions) — đây là phương án gần nhất và về nguyên tắc chạy được, nhưng nó xử lý từng thông điệp độc lập, không có mô hình luồng, không có cửa sổ, không có xử lý dữ liệu trễ, và kém hiệu quả về chi phí ở thông lượng cao.

• B (Cloud Data Fusion) — công cụ ETL trực quan, mạnh về xử lý theo lô; không phải lựa chọn cho luồng thời gian thực có độ trễ thấp.

• A (scheduled query của BigQuery) — chạy theo lịch trên dữ liệu ĐÃ NẰM TRONG BigQuery, nên email thô đã vào kho rồi — quá muộn.

Ghi nhớ

⚠ Đi từ Pub/Sub tới BigQuery — chọn theo nhu cầu biến đổi: | Nhu cầu | Cách | |---|---| | KHÔNG biến đổi gì | Pub/Sub BigQuery subscription — không cần mã | | Chỉ lưu tệp thô | Pub/Sub Cloud Storage subscription | | Có biến đổi, che PII, tổng hợp cửa sổ | Dataflow | | Logic nhỏ, thông lượng thấp | Cloud Run function | | Xử lý sau, theo lô | scheduled query |

Từ khoá nhận diện:

"che PII trước khi vào kho, thời gian thực" → Dataflow "nạp thẳng không biến đổi" → BigQuery subscription "tổng hợp theo cửa sổ" → Dataflow "chạy sau khi dữ liệu đã vào" → scheduled query — quá muộn cho PII "che theo vai trò người xem" → dynamic data masking — bài toán khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng đích còn email thô không | quét bằng Sensitive Data Protection | | Pipeline có theo kịp không | Data freshness trong Job metrics | | Có bản ghi nào lọt qua chưa che không | truy vấn tìm mẫu @ trong cột đã băm |

Và một phép kiểm tra nên chạy định kỳ chứ không chỉ một lần khi triển khai: quét bảng đích tìm PII còn sót. Logic che viết đúng cho lược đồ hôm nay vẫn có thể bỏ lọt một trường mới được thêm vào thông điệp tuần sau — và một lần quét tự động hằng tuần phát hiện điều đó rẻ hơn rất nhiều so với việc để kiểm toán viên tìm thấy trước.

Đáp án

C — Cloud Scheduler, dùng để kích hoạt việc nộp job Dataproc.

Vì sao đúng

Đề chỉ có MỘT job, chạy theo lịch CỐ ĐỊNH mỗi giờ, và yêu cầu bộ điều phối được quản lý hoàn toàn. Không có phụ thuộc nào giữa các bước, nên Cloud Scheduler là mức vừa đủ.

⚠ Điểm mấu chốt — không có phụ thuộc thì không cần DAG:

Yêu cầu: chạy MỘT job PySpark mỗi giờ
        ↓
    Không có bước A phải xong trước bước B
    Không có rẽ nhánh
    Không cần backfill phức tạp
        ↓
    → Cloud Scheduler là đủ
    → Composer là quá tay và tốn kém

⚠ Hai cách để Scheduler nộp job Dataproc:

CÁCH 1 — gọi thẳng Dataproc REST API
gcloud scheduler jobs create http chay-spark \
  --schedule="0 * * * *" \
  --uri="https://dataproc.googleapis.com/v1/projects/\
DU_AN/regions/asia-southeast1/jobs:submit" \
  --http-method=POST \
  --oauth-service-account-email=sa@du-an.iam.gserviceaccount.com \
  --message-body-from-file=job.json

CÁCH 2 — kích hoạt Workflow Template
  → Scheduler gọi workflowTemplates:instantiate
  → template TỰ TẠO cụm, chạy, rồi XOÁ cụm

⚠ Xác thực — điểm dễ sai nhất:

Gọi API của Google (Dataproc)
        ↓
    → dùng --oauth-service-account-email
      (OAuth token)

Gọi Cloud Run / Cloud Functions
        ↓
    → dùng --oidc-service-account-email
      (OIDC token)
        ↓
    ⚠ Service account cần
      roles/dataproc.editor

Xem thêm câu #12996 và #13003 (cùng lô): cả hai khoá Cloud Composer vì có phụ thuộc giữa nhiều bước. Câu này chỉ có một job duy nhất theo lịch → Cloud Scheduler. Ba khoá khác nhau theo số bước và phụ thuộc — hoàn toàn nhất quán.

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

• D (Cloud Function với trigger theo thời gian) — đây là phương án gần nhất và chạy được, nhưng Cloud Functions không có trigger thời gian riêng: nó vẫn phải nhờ Cloud Scheduler kích hoạt. Thêm một lớp trung gian mà không thêm giá trị gì.

• A (cron trên node master của Dataproc) — không phải dịch vụ được quản lý; cụm khởi động lại hay bị xoá là lịch biến mất.

• B (Cloud Tasks) — hàng đợi tác vụ có kiểm soát tốc độ, dùng để lên lịch từng tác vụ riêng lẻ, không phải cơ chế lặp theo cron.

Ghi nhớ

⚠ Chọn công cụ theo số bước và phụ thuộc — bảng phải thuộc: | Tình huống | Công cụ | |---|---| | MỘT job, lịch cố định | Cloud Scheduler | | Vài bước nối nhau, luồng nhẹ | Cloud Workflows | | Nhiều bước có phụ thuộc, nhiều dịch vụ | Cloud Composer | | Nhiều bước CHỈ trong Dataproc | Dataproc Workflow Template | | Kích hoạt theo SỰ KIỆN | Eventarc / Cloud Run function |

Từ khoá nhận diện:

"một job mỗi giờ" → Cloud Scheduler "bước sau chờ bước trước" → Cloud Composer "nhiều bước Spark có tham số" → Dataproc Workflow Template "khi tệp được tải lên" → trigger sự kiện "cron trên VM" → không phải dịch vụ được quản lý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Job lịch cấu hình đúng chưa | gcloud scheduler jobs describe <ten> --location=<r> | | Job Dataproc có được nộp không | gcloud dataproc jobs list --region=<r> | | Chạy thử ngay | gcloud scheduler jobs run <ten> --location=<r> |

Và một câu hỏi đáng đặt ra khi job đã chạy ổn định vài tuần: cụm Dataproc có cần tồn tại giữa các lần chạy không? Một job mỗi giờ, mỗi lần vài phút, nghĩa là cụm nhàn rỗi hơn 90% thời gian — chuyển sang Workflow Template với cụm tạm hoặc Dataproc Serverless thường cắt được phần lớn hoá đơn mà không đổi gì trong chính job.