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

Đáp án

C — Xuất các phân vùng cũ hơn một năm sang bucket Cloud Storage lớp Archive, và đặt chính sách xoá sau 7 năm trên bucket đó.

Vì sao đúng

Đề nêu hai điều kiện: giữ 7 năm để tuân thủ và sau một năm KHÔNG BAO GIỜ truy vấn nữa, với mục tiêu chi phí thấp nhất có thể. Dữ liệu không bao giờ đọc thì không có lý do gì để nằm trong kho phân tích.

⚠ Điểm mấu chốt — so chi phí lưu trữ giữa hai nơi:

BigQuery long-term storage
        ↓
    ≈ 50% giá active storage
        ↓
    Vẫn ĐẮT HƠN NHIỀU so với

Cloud Storage ARCHIVE
        ↓
    Giá lưu rẻ hơn hẳn
        ↓
    ⚠ Với dữ liệu KHÔNG BAO GIỜ truy vấn,
      phí truy xuất cao của Archive
      KHÔNG thành vấn đề
        ↓
    → Archive là lựa chọn rẻ nhất

⚠ Quy trình thực hiện:

1. Xuất phân vùng cũ
   bq extract --destination_format=PARQUET \
     'du_an.giao_dich$20240101' \
     gs://luu-tru/giao-dich/2024/01/01/*.parquet

2. ĐỐI CHIẾU số dòng trước khi xoá

3. Xoá phân vùng khỏi BigQuery
   DELETE FROM ... WHERE ngay < ...
   hoặc đặt partition expiration

4. Bucket Archive + lifecycle Delete sau 7 năm
   + RETENTION POLICY để không xoá sớm

⚠ Nếu về sau bất ngờ cần truy vấn lại:

Dữ liệu ở Parquet trong GCS
        ↓
    → tạo EXTERNAL TABLE hoặc BIGLAKE TABLE
    → truy vấn ngay bằng SQL
        ↓
    ⚠ Chậm hơn bảng thường, và có
      phí truy xuất của Archive
    → nhưng đây là trường hợp HIẾM

Xem thêm câu #12944 (lô 134): hỏi điều gì XẢY RA nếu để nguyên trong BigQuery → khoá là long-term storage giảm ~50%. Câu này hỏi chiến lược RẺ NHẤT khi biết chắc không truy vấn nữa → chuyển sang Archive. Hai khoá khác nhau vì hai câu hỏi khác nhau — hoàn toàn nhất quán. Và #12992 (cùng lô) là lifecycle nhiều bước cho chính loại dữ liệu này.

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

• B (để trong BigQuery và hưởng long-term storage) — đây là phương án gần nhất và đơn giản nhất, nhưng long-term storage vẫn đắt hơn Archive nhiều lần; với dữ liệu không bao giờ đọc trong 6 năm, chênh lệch tích luỹ rất lớn.

• A (đặt partition expiration 7 năm) — giữ toàn bộ trong BigQuery suốt 7 năm rồi mới xoá; không tối ưu chi phí chút nào.

• D (chụp snapshot bảng mỗi năm) — snapshot vẫn tính phí lưu trữ trong BigQuery và không thay thế được dữ liệu gốc; tốn hơn chứ không rẻ hơn.

Ghi nhớ

⚠ Chi phí lưu trữ — thứ tự từ đắt tới rẻ: | Nơi | Ghi chú | |---|---| | BigQuery active storage | đắt nhất | | BigQuery long-term storage | ≈ 50%, tự động sau 90 ngày không sửa | | GCS Standard | | | GCS Nearline / Coldline | | | GCS Archive | rẻ nhất — nhưng phí truy xuất cao nhất | | Nguyên tắc | dữ liệu KHÔNG truy vấn → ra khỏi kho phân tích |

Từ khoá nhận diện:

"giữ N năm, không bao giờ đọc, rẻ nhất" → xuất sang GCS Archive "vẫn thỉnh thoảng truy vấn" → để trong BigQuery (long-term tự áp dụng) "điều gì xảy ra sau 90 ngày không sửa" → long-term storage "tự động chuyển lớp theo tuổi" → lifecycle rule "cấm xoá trước hạn" → retention policy + Bucket Lock

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu cũ có ai truy vấn không | INFORMATION_SCHEMA.JOBS — tìm truy vấn chạm phân vùng cũ | | Xuất có đủ dòng không | so COUNT(*) với số dòng trong tệp | | Retention đã khoá chưa | gcloud storage buckets describe → retentionPolicy.isLocked |

Và một bước bắt buộc trước khi xoá bất kỳ phân vùng nào khỏi BigQuery: đối chiếu số dòng giữa bảng và tệp đã xuất. Xuất thành công không có nghĩa là đủ — một ký tự đại diện viết sai hay một job xuất bị cắt giữa chừng đều dẫn tới việc mất dữ liệu mà chỉ phát hiện ra nhiều năm sau, đúng vào lúc kiểm toán hỏi tới.

Đáp án

A — Cloud Data Fusion.

Vì sao đúng

Đề nêu bốn điều: nguồn là ứng dụng SaaS, đích là Cloud SQL, cần trình kết nối dựng sẵn và giao diện đồ hoạ, và tránh viết mã. Cloud Data Fusion đáp ứng cả bốn.

⚠ Điểm mấu chốt — kéo thả với plugin dựng sẵn:

Cloud Data Fusion Studio
        ↓
    Kéo plugin nguồn (SaaS / REST / JDBC)
        ↓
    Kéo node biến đổi (Wrangler...)
        ↓
    Kéo plugin đích: Cloud SQL
        ↓
    Nối lại rồi chạy
        ↓
    ⚠ Hơn 150 plugin dựng sẵn
    ⚠ Không viết Java hay Python

⚠ Vì sao đích là Cloud SQL lại loại bỏ vài phương án:

BigQuery Data Transfer Service
        ↓
    ⚠ Đích LUÔN LÀ BIGQUERY
    → không đưa dữ liệu vào Cloud SQL được
        ↓
    (Không có trong phương án của đề,
     nhưng đây là bẫy hay gặp ở câu tương tự)

Database Migration Service
        ↓
    Đích là Cloud SQL, nhưng NGUỒN
    phải là một CSDL — không phải SaaS

⚠ Phân biệt với các công cụ biến đổi khác:

DATA FUSION  → kéo thả, plugin sẵn,
               KHÔNG cần lập trình   ← đề này
DATAFORM     → SQL-first, Git, kiểm thử
               (nhưng chỉ trong BigQuery)
DATAFLOW     → viết Apache Beam
DATAPROC     → viết Spark
CLOUD RUN    → tự viết ứng dụng

Xem thêm câu #12915 (lô 133) và #12981 (lô 134): cả hai cũng khoá Cloud Data Fusion, cùng lý do "không lập trình, giao diện trực quan". Ba câu CÙNG KHOÁ — nhất quán. Còn #12991 (cùng lô) khoá Dataform vì đội ở đó giỏi SQL và cần quản lý phiên bản.

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

• D (Dataflow) — đây là phương án gần nhất về năng lực và hoàn toàn làm được, nhưng đòi viết pipeline Apache Beam bằng Java hoặc Python — trái yêu cầu tránh viết mã.

• C (Dataproc) — đòi viết job Spark; còn nặng hơn nữa.

• B (Cloud Run) — phải tự viết cả ứng dụng: gọi API SaaS, phân trang, xử lý lỗi, ghi vào Cloud SQL.

Ghi nhớ

⚠ Chọn công cụ theo kỹ năng đội và đích đến — bảng phải thuộc: | Yêu cầu | Công cụ | |---|---| | Không lập trình, kéo thả, nhiều nguồn/đích | Cloud Data Fusion | | Giỏi SQL, biến đổi trong BigQuery, cần Git | Dataform | | Kỹ sư Python/Java, luồng phức tạp | Dataflow | | Đã có Spark | Dataproc | | CSDL → Cloud SQL | Database Migration Service | | SaaS của Google → BigQuery | BigQuery Data Transfer Service |

Từ khoá nhận diện:

"kéo thả, plugin sẵn, nhanh, không viết mã" → Cloud Data Fusion "SQL-first, Git, assertion" → Dataform "biến đổi luồng quy mô lớn" → Dataflow "Google Ads → BigQuery" → Data Transfer Service "MySQL tại chỗ → Cloud SQL" → DMS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline chạy có lỗi không | Data Fusion → Pipeline runs | | Dữ liệu vào Cloud SQL đủ chưa | SELECT COUNT(*) so với nguồn | | Chi phí thực tế | billing export, lọc SKU Data Fusion và Dataproc |

Và một câu hỏi đáng đặt ra trước khi chốt kiến trúc này: dữ liệu khách hàng từ SaaS được dùng để làm gì? Nếu câu trả lời là "phân tích và báo cáo", thì đích tự nhiên là BigQuery chứ không phải Cloud SQL — và khi đó bài toán đơn giản hơn hẳn. Cloud SQL chỉ hợp lý khi dữ liệu đó phục vụ một ứng dụng giao dịch thật sự.

Đáp án

B — Đặt dashboard vào một FOLDER, rồi cấp quyền 'View' trên folder đó cho GROUP "Marketing Analysts".

Vì sao đúng

Trong Looker, quyền nội dung được quản lý qua folder, và cấp cho group thay vì từng người là cách duy nhất mở rộng được.

⚠ Điểm mấu chốt — hai nguyên tắc quản trị:

1. QUYỀN GẮN VÀO FOLDER, không gắn
   vào từng dashboard
        ↓
    → thêm dashboard mới vào folder
      = tự động có đúng quyền
    → không phải nhớ cấp lại

2. CẤP CHO GROUP, không cấp cho cá nhân
        ↓
    → người mới vào đội: thêm vào group
    → người rời đội: bỏ khỏi group
    → không phải rà từng dashboard

⚠ Hai mức quyền trên folder của Looker:

VIEW
    → xem và tương tác với nội dung
      trong folder
    → lọc, drill down, tải kết quả

MANAGE ACCESS, EDIT
    → thêm/sửa/xoá nội dung
    → và cấp quyền cho người khác
        ↓
    ⚠ Đề chỉ cần "đăng nhập và tương tác"
    → VIEW là đủ

⚠ Quyền nội dung ↔ quyền dữ liệu — hai tầng riêng:

FOLDER PERMISSION
    → thấy được dashboard nào

MODEL SET / PERMISSION SET (role)
    → được xem MÔ HÌNH nào,
      làm được những việc gì
        ↓
    ⚠ Có quyền folder mà không có
      quyền model → mở dashboard lên
      thấy lỗi, không thấy dữ liệu
        ↓
    → phải cấp CẢ HAI

Xem thêm câu #12946, #12976 và #12978 (lô 134): cùng về Looker — LookML, yêu cầu doanh nghiệp, nhúng đa khách hàng. Câu này về quản trị quyền nội dung. Bốn câu vẽ nên bức tranh đầy đủ.

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

• A (cấp 'Manage Access' cho từng người dùng) — đây là phương án gần nhất về mặt "cấp quyền", nhưng nó sai ở hai điểm: cấp cho từng cá nhân (không mở rộng được) và cấp quá nhiều quyền (Manage Access cho phép họ cấp quyền cho người khác).

• C (gửi URL qua email) — URL không phải cơ chế phân quyền; không có quyền thì mở link vẫn bị từ chối.

• D (gửi PDF theo lịch) — cho ảnh chụp tĩnh, không cho phép tương tác như đề yêu cầu.

Ghi nhớ

⚠ Quản trị quyền trong Looker — bảng phải thuộc: | Thành phần | Việc | |---|---| | Folder + folder permission | ai THẤY nội dung nào | | Group | đơn vị cấp quyền — không cấp cho cá nhân | | Role = permission set + model set | làm được gì, trên mô hình nào | | User attribute | giá trị theo từng người — dùng cho lọc dòng | | access_filter trong LookML | lọc DÒNG theo user attribute | | Nguyên tắc | quyền nội dung và quyền dữ liệu là HAI tầng |

Từ khoá nhận diện:

"cho cả nhóm xem dashboard" → folder + group + View "mỗi người chỉ thấy dữ liệu của mình" → user attribute + access_filter "được sửa dashboard" → quyền Edit trên folder "gửi URL cho nhau" → không phải phân quyền "nhúng cho người ngoài" → signed embed

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Group có quyền trên folder chưa | menu Manage Access của folder | | Người dùng thuộc group nào | Admin → Users | | Họ thấy gì thật sự | impersonate (sudo) vào tài khoản đó |

Và một nguyên nhân rất hay gặp khi ai đó báo "tôi mở dashboard lên mà không thấy dữ liệu": có quyền folder nhưng thiếu quyền model. Hai tầng quyền này độc lập với nhau, và cấp đúng một tầng cho ra đúng triệu chứng ấy — dashboard hiện ra bình thường, chỉ có mọi ô đều báo lỗi.

Đáp án

B — Người dùng thiếu roles/bigquery.jobUser, vai trò cần để CHẠY job truy vấn.

Vì sao đúng

Triệu chứng mô tả trong đề là dấu hiệu kinh điển: thấy được tên bảng và lược đồ (nhờ quyền dữ liệu) nhưng không chạy được SELECT (thiếu quyền job).

⚠ Điểm mấu chốt — BigQuery tách quyền DỮ LIỆU khỏi quyền JOB:

roles/bigquery.dataViewer
        ↓
    Đọc dữ liệu và siêu dữ liệu
    → THẤY bảng, THẤY lược đồ
        ↓
    ⚠ Nhưng KHÔNG tạo được JOB

roles/bigquery.jobUser
        ↓
    Tạo và chạy job trong project
        ↓
    ⚠ PHẢI CÓ CẢ HAI mới chạy được SELECT

⚠ Vì sao triệu chứng lại đúng như vậy:

Xem danh sách bảng và lược đồ
        ↓
    → chỉ là lời gọi API ĐỌC SIÊU DỮ LIỆU
    → không tạo job
    → dataViewer là đủ

Chạy SELECT
        ↓
    → BigQuery tạo một QUERY JOB
    → cần quyền tạo job TRONG PROJECT
        ↓
    ⚠ Thông báo lỗi thường nhắc tới
      "job", không nhắc tới bảng
    → rất dễ đi tìm sai chỗ

⚠ Sửa:

gcloud projects add-iam-policy-binding DU-AN \
  --member="user:analyst@congty.com" \
  --role="roles/bigquery.jobUser"
        ↓
    ⚠ Cấp trên PROJECT — nơi job chạy
      và nơi tính tiền truy vấn

⚠ Vì sao BigQuery thiết kế như vậy:

DỮ LIỆU ở project A
CHẠY JOB ở project B
        ↓
    → chi phí truy vấn tính cho project B
        ↓
    → dataset dùng chung, mỗi đội tự trả
      tiền truy vấn của mình
        ↓
    Đây là tính năng, không phải phiền toái

Xem thêm câu #12957 (lô 134): hỏi cần CẤP hai vai trò nào cho nhà phân tích chỉ đọc → dataViewer + jobUser. Câu này hỏi VÌ SAO bị lỗi khi thiếu jobUser. Hai câu bổ sung nhau hoàn hảo — nhất quán.

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

• C (cần dataOwner để chạy truy vấn) — đây là phương án dễ chọn nhầm vì nghe như "cần quyền cao hơn", nhưng dataOwner vẫn KHÔNG cho quyền tạo job; thêm nó vào cũng không sửa được lỗi, mà lại cấp thừa quyền quản lý dataset.

• A (được cấp quá nhiều quyền gây xung đột) — IAM không hoạt động như vậy: các vai trò cộng dồn, không xung đột (chỉ có Deny policy mới chặn).

• D (dữ liệu mã hoá, thiếu khoá giải mã) — nếu là vấn đề CMEK thì lỗi sẽ nói về khoá, và người dùng cũng không xem được lược đồ bình thường như mô tả.

Ghi nhớ

⚠ Hai trục quyền của BigQuery — bảng phải thuộc: | Trục | Vai trò | Cấp ở đâu | |---|---|---| | Quyền DỮ LIỆU | dataViewer / dataEditor / dataOwner | dataset hoặc bảng | | Quyền JOB | jobUser / user | PROJECT | | Chạy SELECT | cần CẢ HAI | | | Chỉ xem lược đồ | dataViewer hoặc metadataViewer là đủ | | Bẫy | thông báo lỗi nói về "job", không nói về bảng |

Từ khoá nhận diện:

"thấy bảng nhưng không chạy được truy vấn" → thiếu jobUser "không thấy bảng nào cả" → thiếu quyền DỮ LIỆU "chạy được nhưng không thấy cột X" → column-level security "thấy ít dòng hơn người khác" → row-level security "lỗi nhắc tới khoá KMS" → thiếu quyền trên khoá CMEK

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người này có jobUser không | gcloud projects get-iam-policy <id>, lọc theo email | | Quyền trên dataset thế nào | bq show --format=prettyjson <dataset> | | Vì sao bị từ chối | Policy Troubleshooter |

Và một mẹo đọc thông báo lỗi của BigQuery giúp tiết kiệm rất nhiều thời gian: để ý lỗi nhắc tới "job" hay nhắc tới "table". Lỗi về job nghĩa là thiếu quyền chạy ở cấp project; lỗi về bảng nghĩa là thiếu quyền dữ liệu — và hai thứ đó nằm ở hai chỗ hoàn toàn khác nhau trong cấu hình IAM.

Đáp án

D — Khi luồng công việc phải phối hợp các tác vụ trên NHIỀU dịch vụ Google Cloud khác nhau như Dataproc, BigQuery và Cloud Storage.

Vì sao đúng

Đây chính là ranh giới giữa hai công cụ: Dataproc Workflow Template chỉ điều phối được BÊN TRONG Dataproc, còn Cloud Composer điều phối xuyên mọi dịch vụ.

⚠ Điểm mấu chốt — phạm vi quyết định lựa chọn:

DATAPROC WORKFLOW TEMPLATE
        ↓
    Phạm vi: CHỈ các job Dataproc
      (Spark, Hive, Pig, PySpark...)
        ↓
    Có: thứ tự bước, tham số,
        tự tạo và xoá cụm
    KHÔNG: gọi BigQuery, gửi thông báo,
        chạy Cloud Function

CLOUD COMPOSER
        ↓
    Phạm vi: MỌI dịch vụ
        ↓
    Hàng trăm operator dựng sẵn
    → Dataproc, BigQuery, GCS, Pub/Sub,
      Cloud Run, và cả hệ thống ngoài GCP

⚠ Câu hỏi phân biệt trong một dòng:

"Luồng có bước nào NGOÀI Dataproc không?"
        ↓
    KHÔNG → Dataproc Workflow Template
             (đơn giản hơn, rẻ hơn,
              không có môi trường thường trực)
        ↓
    CÓ   → Cloud Composer

⚠ Vì sao ba phương án kia đều mô tả tình huống NGƯỢC LẠI:

"Toàn bộ chuỗi job chạy trên MỘT cụm Dataproc"
    → chính là lúc dùng Workflow Template

"Giảm thời gian và độ phức tạp thiết lập
 cho một job đơn giản, lặp lại"
    → Composer có môi trường thường trực,
      thiết lập nặng hơn nhiều

"Chuỗi tuyến tính đơn giản các job Spark và Hive"
    → đúng phạm vi của Workflow Template

Xem thêm câu #12954 (lô 134): khoá Dataproc Workflow Template vì luồng chỉ trong Dataproc. Và #12996, #13003 (cùng lô): khoá Cloud Composer vì có nhiều dịch vụ hoặc nhiều bước phụ thuộc. Bốn câu, một quy tắc phân biệt duy nhất — hoàn toàn nhất quán.

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

• A (toàn bộ chuỗi chạy trên một cụm Dataproc) — đây là phương án gần nhất nhưng mô tả đúng lúc nên chọn Workflow Template, không phải Composer.

• B (giảm thời gian và độ phức tạp thiết lập cho job đơn giản) — ngược: Composer đòi dựng một môi trường thường trực, phức tạp và tốn kém hơn hẳn.

• C (chuỗi tuyến tính đơn giản các job Spark và Hive) — cũng nằm gọn trong phạm vi Dataproc → Workflow Template.

Ghi nhớ

⚠ Workflow Template ↔ Cloud Composer — bảng phải thuộc: | | Dataproc Workflow Template | Cloud Composer | |---|---|---| | Phạm vi | chỉ Dataproc | mọi dịch vụ | | Chi phí nền | KHÔNG có | môi trường thường trực | | Độ phức tạp thiết lập | thấp | cao | | Quản lý cụm | tự tạo và xoá | qua operator | | Backfill, XCom, sensor | không | có | | Chọn khi | luồng gọn trong Dataproc | luồng xuyên dịch vụ |

Từ khoá nhận diện:

"nhiều dịch vụ khác nhau" → Cloud Composer "chỉ toàn job Spark trên một cụm" → Workflow Template "muốn đơn giản và rẻ" → Workflow Template hoặc Workflows "một job theo lịch" → Cloud Scheduler "chỉ toàn SQL trong BigQuery" → Dataform

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luồng có bước ngoài Dataproc không | liệt kê từng bước và dịch vụ tương ứng | | Chi phí môi trường Composer | billing export, lọc SKU Composer | | Template chạy tới đâu | gcloud dataproc operations list |

Và một cách kiểm tra nhanh trước khi quyết định dựng một môi trường Cloud Composer: liệt kê các bước của luồng và ghi tên dịch vụ bên cạnh mỗi bước. Nếu cột dịch vụ chỉ có mỗi chữ "Dataproc", bạn đang chuẩn bị trả chi phí thường trực cho một thứ mà Workflow Template làm được miễn phí.

Đáp án

C — BigQuery Data Transfer Service.

Vì sao đúng

Đề nêu bốn điều: nguồn là Google Ads, đích là BigQuery, nạp tự động mỗi ngày, không viết mã. Data Transfer Service có trình kết nối dựng sẵn cho đúng nguồn này.

⚠ Điểm mấu chốt — trình kết nối dựng sẵn, cấu hình bằng vài cú bấm:

BigQuery → Data transfers → Create transfer
        ↓
    Source: Google Ads
    Nhập Customer ID, cấp quyền
    Đặt lịch: hằng ngày
    Chọn dataset đích
        ↓
    → BigQuery TỰ tạo bảng theo lược đồ
      chuẩn của Google Ads
    → tự nạp mỗi ngày
        ↓
    ⚠ Không một dòng mã nào

⚠ Đặc thù của dữ liệu quảng cáo mà DTS xử lý sẵn:

Google Ads ĐIỀU CHỈNH SỐ LIỆU HỒI TỐ
    (chuyển đổi ghi nhận muộn)
        ↓
    → số của ngày hôm qua có thể đổi
      trong vài ngày tới
        ↓
    DTS có REFRESH WINDOW
    → tự nạp lại N ngày gần nhất
        ↓
    ⚠ Tự viết pipeline thì phải tự lo
      chuyện này — và rất dễ bỏ sót

⚠ Vì sao ba phương án kia đều "quá tay" hoặc sai đích:

Cloud Data Fusion
    → làm được, nhưng phải TỰ DỰNG pipeline,
      tự lo OAuth, phân trang, lược đồ đổi
    → cộng chi phí instance thường trực

Dataflow
    → phải VIẾT MÃ Apache Beam

Storage Transfer Service
    → chuyển TỆP giữa các kho đối tượng
    → không liên quan Google Ads hay BigQuery

Xem thêm câu #12924 (lô 134): cùng một tình huống, cùng khoá BigQuery Data Transfer Service. Hai câu hoàn toàn nhất quán. Và #13012 (cùng lô) khoá Data Fusion vì ở đó đích là Cloud SQL và nguồn không có trình kết nối DTS.

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

• A (Cloud Data Fusion) — đây là phương án gần nhất vì cũng không cần lập trình, nhưng bạn vẫn phải tự dựng pipeline, tự xử lý xác thực, phân trang và thay đổi lược đồ, cộng thêm chi phí instance thường trực.

• B (Dataflow) — đòi viết mã Apache Beam.

• D (Storage Transfer Service) — chuyển tệp giữa các kho đối tượng, không nạp vào BigQuery.

Ghi nhớ

⚠ Bốn dịch vụ "transfer" — bảng phải thuộc: | Dịch vụ | Nguồn → Đích | |---|---| | BigQuery Data Transfer Service | SaaS, kho khác → BIGQUERY | | Storage Transfer Service | S3, Azure, HTTP, on-prem → CLOUD STORAGE | | Database Migration Service | CSDL → Cloud SQL / AlloyDB | | Datastream | CSDL → BigQuery, GCS (CDC) | | Transfer Appliance | thiết bị vật lý, khối lượng rất lớn |

Từ khoá nhận diện:

"Google Ads / YouTube / Campaign Manager → BigQuery" → DTS "S3 → GCS" → Storage Transfer Service "MySQL → Cloud SQL" → DMS "cần biến đổi trên đường nạp" → Data Fusion / Dataflow "nguồn không có trình kết nối sẵn" → Data Fusion / Dataflow

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Transfer chạy thành công không | BigQuery → Data transfers → Run history | | Dữ liệu mới nhất tới đâu | SELECT MAX(<cột ngày>) trên bảng đích | | Chạy dưới danh nghĩa ai | xem cấu hình transfer |

Và một cấu hình nên đổi ngay sau khi transfer chạy ổn định: chuyển sang chạy dưới service account thay vì tài khoản cá nhân. Transfer tạo bằng tài khoản của một người sẽ dừng khi người đó rời công ty — và vì nó hỏng lặng lẽ, thường phải tới lúc có người hỏi "sao số liệu vẫn là của tuần trước" thì mới ai đó phát hiện ra.

Đáp án

B — Dataprep.

Vì sao đúng

Đề nêu bốn đặc điểm: nhà phân tích nghiệp vụ, không phải lập trình viên, cần KHÁM PHÁ TRỰC QUAN dữ liệu, tìm và sửa bất thường như giá trị sai định dạng và ngoại lai, trước khi nạp vào BigQuery. Dataprep sinh ra cho đúng công việc này.

⚠ Điểm mấu chốt — Dataprep tự PHÁT HIỆN vấn đề và GỢI Ý cách sửa:

Tải mẫu dữ liệu lên
        ↓
    Dataprep TỰ VẼ biểu đồ phân phối
    cho TỪNG cột
        ↓
    → tự đánh dấu:
        giá trị THIẾU
        giá trị SAI ĐỊNH DẠNG (màu đỏ)
        giá trị NGOẠI LAI
        kiểu dữ liệu suy đoán
        ↓
    Bấm vào phần bất thường
        ↓
    ⚠ Dataprep GỢI Ý các phép biến đổi
    → chọn một cái, xem trước kết quả ngay

⚠ Điều khiến Dataprep khác hẳn các công cụ ETL khác:

DATA FUSION / DATAFLOW
        ↓
    Bạn phải BIẾT TRƯỚC dữ liệu hỏng ở đâu
    rồi mới dựng bước xử lý

DATAPREP                        ← đề này
        ↓
    Công cụ CHỦ ĐỘNG CHỈ RA
    dữ liệu bất thường
        ↓
    → đúng cho giai đoạn KHÁM PHÁ,
      khi chưa biết dữ liệu có gì

⚠ Kết quả cuối cùng vẫn là một pipeline chạy được:

"Recipe" (công thức) = chuỗi các bước biến đổi
        ↓
    Chạy job
        ↓
    → thực thi trên DATAFLOW
    → ghi kết quả vào BigQuery hoặc GCS
        ↓
    ⚠ Có quy mô của Dataflow
      mà không phải viết Beam
        ↓
    Lên lịch chạy lại được

Xem thêm câu #13012 (cùng lô), #12915 (lô 133), #12981 (lô 134): cả ba khoá Cloud Data Fusion — cho việc dựng PIPELINE ETL bằng kéo thả. Và #12991 (cùng lô) khoá Dataform cho đội giỏi SQL cần Git. Câu này là KHÁM PHÁ và LÀM SẠCH trực quan → Dataprep. Bốn khoá khác nhau theo bốn nhu cầu khác nhau — nhất quán.

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

• D (BigQuery) — đây là phương án gần nhất vì nhà phân tích giỏi SQL và BigQuery làm sạch dữ liệu được, nhưng đề nhấn mạnh "khám phá TRỰC QUAN" và "trước khi nạp vào BigQuery" — BigQuery không có giao diện phát hiện bất thường theo cách đó.

• A (Dataflow) — đòi viết mã Apache Beam.

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

Ghi nhớ

⚠ Bốn công cụ dữ liệu không cần lập trình — phân biệt dứt điểm: | Công cụ | Dùng cho | |---|---| | Dataprep | KHÁM PHÁ và LÀM SẠCH trực quan — chưa biết dữ liệu có gì | | Cloud Data Fusion | DỰNG PIPELINE ETL kéo thả — đã biết cần làm gì | | Dataform | chuỗi biến đổi SQL có Git và kiểm thử | | Connected Sheets | phân tích BigQuery trong bảng tính | | Ghi nhớ | Dataprep khám phá, Data Fusion sản xuất |

Từ khoá nhận diện:

"khám phá trực quan, tìm bất thường, ngoại lai" → Dataprep "dựng pipeline kéo thả, nhiều nguồn/đích" → Cloud Data Fusion "biến đổi bằng SQL, cần kiểm thử" → Dataform "viết Beam" → Dataflow "phân tích trong Google Sheets" → Connected Sheets

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn bao nhiêu giá trị bất thường | biểu đồ chất lượng cột trong Dataprep | | Job có chạy hết dữ liệu không | so số dòng vào và ra | | Chi phí bao nhiêu | billing export — job chạy trên Dataflow |

Và một điều nên nói rõ về vai trò của Dataprep trong bức tranh dài hạn: nó mạnh nhất ở giai đoạn KHÁM PHÁ. Khi bạn đã hiểu dữ liệu và các quy tắc làm sạch đã ổn định, chuyển chúng sang một pipeline có kiểm thử và quản lý phiên bản — Dataform hoặc Data Fusion — sẽ bền hơn nhiều so với một recipe mà chỉ một người biết cách sửa.

Đáp án

A — Vi phạm Nguyên tắc Quyền Tối thiểu (Principle of Least Privilege), vì cấp quyền vượt xa nhu cầu chỉ để truy vấn dữ liệu.

Vì sao đúng

roles/bigquery.admin cho toàn quyền trên toàn bộ BigQuery của project, trong khi nhu cầu thực tế của nhà phân tích chỉ là đọc dữ liệu và chạy truy vấn.

⚠ Điểm mấu chốt — khoảng cách giữa nhu cầu và quyền được cấp:

NHU CẦU THẬT
    → đọc dữ liệu
    → chạy SELECT
        ↓
    = dataViewer + jobUser

ĐƯỢC CẤP: bigquery.admin
    → xoá bảng, xoá dataset
    → sửa dữ liệu
    → cấp quyền cho người khác
    → quản lý reservation và slot
    → đổi cấu hình mã hoá
        ↓
    ⚠ Không ai trong số này là
      "chạy báo cáo"

⚠ Ba loại rủi ro cụ thể, không phải lý thuyết:

1. TAI NẠN
    → một lệnh DROP TABLE gõ nhầm
      trong cửa sổ sai
    → bảng sản xuất biến mất

2. TÀI KHOẢN BỊ CHIẾM
    → kẻ tấn công có TOÀN QUYỀN BigQuery
    → đọc mọi thứ, xoá mọi thứ

3. LEO THANG QUYỀN
    → admin CẤP ĐƯỢC QUYỀN cho người khác
    → một tài khoản bị chiếm thành nhiều

⚠ Và một hệ quả về vận hành ít người nghĩ tới:

Cấp admin để "khỏi gặp lỗi quyền"
        ↓
    → KHÔNG BAO GIỜ biết được
      họ THẬT SỰ cần quyền gì
        ↓
    → không bao giờ siết lại được
    → không trả lời được câu hỏi
      của kiểm toán: "ai làm được gì?"

Xem thêm câu #12952, #12956, #12957, #12975 (lô 134) và #12995, #13007, #13014 (lô 135): cả bảy câu đều là ứng dụng của cùng một nguyên tắc vào các dịch vụ khác nhau. Câu này phát biểu chính nguyên tắc ấy.

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

• C (nên tạo vai trò tuỳ chỉnh vì vai trò định sẵn không được khuyến nghị cho nhóm) — đây là phương án gần nhất về mặt "nên làm khác", nhưng ngược với khuyến nghị của Google: hãy ưu tiên vai trò ĐỊNH SẴN, chỉ tạo vai trò tuỳ chỉnh khi không có cái nào đủ hẹp.

• B (vai trò Admin làm mỗi truy vấn đắt hơn) — sai: chi phí truy vấn tính theo byte quét, không phụ thuộc vai trò.

• D (Admin không cho chạy truy vấn, chỉ quản lý dataset) — sai: bigquery.admin bao gồm cả quyền chạy truy vấn.

Ghi nhớ

⚠ Nguyên tắc quyền tối thiểu — bốn câu hỏi phải trả lời: | Câu hỏi | Nội dung | |---|---| | AI | người dùng, GROUP, hay service account | | LÀM GÌ | vai trò hẹp nhất còn đủ dùng | | TRÊN GÌ | phạm vi: tài nguyên → project → folder → org | | BAO LÂU | cân nhắc IAM condition có hạn | | Thực hành | cấp cho GROUP, rà soát bằng Recommender |

Từ khoá nhận diện:

"cấp Admin cho khỏi gặp lỗi" → vi phạm quyền tối thiểu "chỉ chạy SELECT" → dataViewer + jobUser "vai trò tuỳ chỉnh tốt hơn định sẵn" → SAI — định sẵn được ưu tiên "cấp cho từng người" → nên cấp cho GROUP "quyền tạm thời" → IAM condition có hạn thời gian

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đang có vai trò rộng | gcloud projects get-iam-policy <id>, tìm admin, editor, owner | | Quyền nào thật sự được dùng | IAM Recommender và audit log | | Vai trò gồm những gì | gcloud iam roles describe roles/bigquery.admin |

Và một cách tiếp cận thực dụng khi đội phàn nàn về lỗi quyền: coi mỗi lỗi quyền là một thông tin hữu ích, không phải một phiền toái. Nó cho biết chính xác ai cần quyền gì — và cấp đúng thứ đó mất vài phút, trong khi cấp admin cho nhanh sẽ khiến bạn vĩnh viễn không biết câu trả lời ấy.

Đáp án

A — Tạo và duy trì một BẢN SAO của CSDL tại chỗ trong Cloud SQL, được cập nhật liên tục với độ trễ thấp.

Vì sao đúng

Trong mẫu kiến trúc chuẩn để đưa dữ liệu từ CSDL tại chỗ vào BigQuery, DMS đảm nhận nửa đầu: nhân bản CSDL nguồn sang Cloud SQL, giữ nó luôn cập nhật.

⚠ Điểm mấu chốt — mẫu hai chặng:

CSDL TẠI CHỖ
        ↓
    DMS (nhân bản CDC liên tục)
        ↓
    CLOUD SQL — bản sao độ trễ thấp
        ↓
    Datastream, Dataflow, hoặc federated query
        ↓
    BIGQUERY — phân tích
        ↓
    ⚠ DMS chỉ lo CHẶNG ĐẦU
    ⚠ Nó KHÔNG đưa dữ liệu vào BigQuery

⚠ Vì sao lại phải đi qua Cloud SQL:

1. TÁCH TẢI khỏi hệ thống sản xuất
    → truy vấn phân tích không chạm
      CSDL đang phục vụ khách hàng

2. Cloud SQL nằm TRONG Google Cloud
    → các dịch vụ khác kết nối dễ hơn nhiều
      so với qua VPN tới on-prem

3. Có một BẢN SAO vận hành đầy đủ
    → dùng được cho cả mục đích khác
      (dự phòng, môi trường thử)

⚠ Chặng thứ hai — từ Cloud SQL sang BigQuery:

DATASTREAM
    → CDC từ Cloud SQL vào BigQuery
    → gần thời gian thực, không cần mã

FEDERATED QUERY
    → BigQuery truy vấn THẲNG Cloud SQL
    → EXTERNAL_QUERY(...)
    → hợp với bảng nhỏ, truy vấn thưa

DATAFLOW hoặc scheduled query
    → nạp theo lô nếu chấp nhận độ trễ

Xem thêm câu #12987 và #13002 (cùng lô): cùng về DMS — so sánh với Data Fusion và di chuyển PostgreSQL 5 TB. Ba câu nhất quán: DMS luôn có đích là Cloud SQL hoặc AlloyDB, không bao giờ là BigQuery.

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

• D (lên lịch nạp gia tăng hằng ngày từ Cloud SQL vào BigQuery) — đây là phương án gần nhất và mô tả đúng CHẶNG THỨ HAI, nhưng đó là việc của Datastream, Dataflow hoặc scheduled query, không phải của DMS.

• B (kết nối thẳng tới CSDL tại chỗ và chạy truy vấn phân tích cho BigQuery) — DMS không phải công cụ truy vấn; và chạy truy vấn phân tích thẳng trên CSDL sản xuất là điều mẫu kiến trúc này muốn tránh.

• C (biến đổi và làm giàu dữ liệu phức tạp trước khi nạp vào kho) — DMS không biến đổi gì cả; đó là việc của Dataflow hoặc Data Fusion.

Ghi nhớ

⚠ Mẫu đưa CSDL tại chỗ vào BigQuery — bảng phải thuộc: | Chặng | Công cụ | |---|---| | On-prem → Cloud SQL | Database Migration Service | | Cloud SQL → BigQuery (CDC) | Datastream | | Cloud SQL → BigQuery (truy vấn trực tiếp) | federated query EXTERNAL_QUERY | | Cần biến đổi phức tạp | Dataflow, Data Fusion | | On-prem → BigQuery trực tiếp | Datastream cũng làm được |

Từ khoá nhận diện:

"nhân bản CSDL sang Cloud SQL" → DMS "CDC vào BigQuery" → Datastream "BigQuery truy vấn thẳng Cloud SQL" → federated query "biến đổi trên đường nạp" → Dataflow / Data Fusion "DMS đưa dữ liệu vào BigQuery" → SAI — đích của DMS là Cloud SQL/AlloyDB

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

Và một câu hỏi nên đặt ra khi thiết kế kiến trúc này: có thật sự cần chặng Cloud SQL ở giữa không? Datastream nối thẳng từ CSDL tại chỗ vào BigQuery được, nên nếu mục tiêu duy nhất là phân tích, bỏ chặng giữa sẽ đơn giản và rẻ hơn. Chặng Cloud SQL chỉ đáng giá khi bạn cũng cần một bản sao vận hành đầy đủ trên đám mây.

Đáp án

A — Cloud Data Fusion hoặc Dataflow.

Vì sao đúng

Đề mô tả một tác vụ ETL thực sự phức tạp: làm sạch nhiều, làm giàu bằng cách nối với ba tập dữ liệu khác, và tái cấu trúc lược đồ trước khi nạp. Chỉ hai công cụ biến đổi đa năng làm được cả ba việc đó.

⚠ Điểm mấu chốt — ba yêu cầu đều là BIẾN ĐỔI:

"làm sạch đáng kể"      → biến đổi
"nối với BA tập khác"   → biến đổi (join)
"tái cấu trúc lược đồ"  → biến đổi
        ↓
    ⚠ Cần một ENGINE BIẾN ĐỔI đầy đủ
        ↓
    Cloud Data Fusion → kéo thả
    Dataflow          → viết Apache Beam
        ↓
    Cả hai đều làm được

⚠ Vì sao ba phương án kia đều KHÔNG biến đổi được:

Storage Transfer Service
    → chuyển TỆP giữa các kho đối tượng
    → KHÔNG biến đổi gì

Database Migration Service
    → nhân bản CSDL sang Cloud SQL
    → KHÔNG biến đổi, và đích SAI

BigQuery Data Transfer Service
    → nạp từ nguồn định sẵn vào BigQuery
    → KHÔNG có bước biến đổi tuỳ ý
        ↓
    ⚠ Ba dịch vụ này chỉ DI CHUYỂN,
      không BIẾN ĐỔI

⚠ Chọn giữa hai phương án đúng như thế nào:

CLOUD DATA FUSION
    → đội KHÔNG lập trình
    → cần nhìn thấy luồng bằng hình
    → chấp nhận chi phí instance thường trực

DATAFLOW
    → đội có kỹ sư Java/Python
    → cần hiệu năng và tiết kiệm tài nguyên
    → cần cả xử lý LUỒNG

Xem thêm câu #13021 (cùng lô): khoá chỉ Data Fusion vì đề nhấn mạnh nhà phân tích KHÔNG lập trình. Và #13030 (cùng lô): khoá chỉ Dataflow vì ưu tiên hiệu năng và ít tài nguyên. 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

• C (Database Migration Service) — đây là phương án gần nhất vì nguồn cũng là CSDL tại chỗ, nhưng DMS nhân bản NGUYÊN VẸN sang Cloud SQL, không biến đổi và không có đích BigQuery.

• D (BigQuery Data Transfer Service) — có đích đúng là BigQuery, nhưng không có bước biến đổi tuỳ ý và không hỗ trợ CSDL tại chỗ.

• B (Storage Transfer Service) — chuyển tệp, hoàn toàn không liên quan.

Ghi nhớ

⚠ DI CHUYỂN ↔ BIẾN ĐỔI — bảng phải thuộc: | Nhóm | Dịch vụ | Biến đổi được? | |---|---|---| | Chỉ DI CHUYỂN | Storage Transfer Service | KHÔNG | | Chỉ DI CHUYỂN | Database Migration Service | KHÔNG | | Chỉ DI CHUYỂN | BigQuery Data Transfer Service | KHÔNG | | Chỉ DI CHUYỂN (CDC) | Datastream | KHÔNG (có ánh xạ kiểu cơ bản) | | BIẾN ĐỔI | Dataflow, Cloud Data Fusion, Dataproc | CÓ | | BIẾN ĐỔI bằng SQL | Dataform, BigQuery | CÓ |

Từ khoá nhận diện:

"làm sạch, join nhiều nguồn, đổi lược đồ" → Dataflow hoặc Data Fusion "chỉ chuyển nguyên vẹn" → các dịch vụ transfer "nạp thô rồi biến đổi bằng SQL" → ELT với Dataform "nguồn SaaS định sẵn" → BigQuery Data Transfer Service "CSDL → Cloud SQL" → DMS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline có chạy đủ dữ liệu không | so số dòng nguồn và đích | | Phép join có nhân bản dòng không | so COUNT(*) trước và sau | | Nguồn có bị ảnh hưởng không | theo dõi tải trên CSDL tại chỗ |

Và một hướng đáng đặt lên bàn cân trước khi chọn giữa hai phương án trong đáp án: có thể nạp thô vào BigQuery rồi làm sạch bằng SQL không? Với việc "join với ba tập dữ liệu khác", nếu cả ba tập ấy cũng nằm trong BigQuery thì phép join bằng SQL vừa đơn giản hơn, vừa rẻ hơn, và vừa giữ được dữ liệu thô để chạy lại khi logic thay đổi.