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

Đáp án

B — Trong phần payload.

Vì sao đúng

Mỗi sự kiện thay đổi mà Datastream sinh ra được chia thành hai phần rõ ràng: payload chứa DỮ LIỆU của dòng, và phần metadata chứa thông tin về chính sự kiện đó.

⚠ Điểm mấu chốt — cấu trúc một sự kiện Datastream:

{
  "payload": {
    "khach_id": 123,
    "ten": "Nguyen Van An",
    "email": "an@congty.com",
    "cap_nhat_luc": "2026-09-02T10:00:00Z"
  },
  "source_metadata": {
    "table": "khach_hang",
    "schema": "public",
    "change_type": "UPDATE",
    "is_deleted": false,
    "log_position": "...",
    "primary_keys": ["khach_id"]
  },
  "read_timestamp": "...",
  "source_timestamp": "..."
}

        ↓
    ⚠ payload = GIÁ TRỊ MỚI của các cột
    ⚠ source_metadata = thông tin VỀ sự kiện

⚠ Ứng dụng hạ nguồn cần cả hai phần:

payload
    → giá trị mới để ghi vào đích

source_metadata.change_type
    → INSERT / UPDATE / DELETE
    → quyết định làm gì

source_metadata.is_deleted
    → có phải bản ghi bị xoá không

source_metadata.primary_keys
    → biết dùng khoá nào để MERGE

source_timestamp
    → thứ tự sự kiện, xử lý dữ liệu tới muộn

⚠ Mẫu xử lý điển hình — MERGE vào bảng đích:

MERGE `du_an.khach_hang` T
USING (SELECT * FROM su_kien_moi_nhat) S
ON T.khach_id = S.khach_id
WHEN MATCHED AND S.is_deleted THEN DELETE
WHEN MATCHED THEN UPDATE SET ...
WHEN NOT MATCHED THEN INSERT ...

        ↓
    ⚠ Chỉ lấy sự kiện MỚI NHẤT cho mỗi khoá
    → dùng ROW_NUMBER() theo source_timestamp

Xem thêm câu #13059 (lô 136): về CDC — cơ chế mà Datastream dùng để sinh ra chính các sự kiện này. Hai câu bổ sung nhau: một về cơ chế, một về cấu trúc dữ liệu đầu ra.

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

• C (phần metadata) — đây là phương án gần nhất và là một phần thật sự của sự kiện, nhưng nó chứa thông tin VỀ sự kiện (bảng nào, loại thay đổi, vị trí trong nhật ký), không chứa GIÁ TRỊ các cột.

• A (message header) — chứa thông tin vận chuyển của Pub/Sub, không phải dữ liệu dòng.

• D (Dead-Letter Topic) — nơi chứa thông điệp THẤT BẠI, không phải nơi chứa dữ liệu của sự kiện bình thường.

Ghi nhớ

⚠ Cấu trúc sự kiện Datastream — bảng phải thuộc: | Phần | Nội dung | |---|---| | payload | GIÁ TRỊ các cột của dòng | | source_metadata.table / schema | nguồn gốc | | source_metadata.change_type | INSERT / UPDATE / DELETE | | source_metadata.is_deleted | cờ xoá | | source_metadata.primary_keys | khoá để MERGE | | source_timestamp | thời điểm ở NGUỒN — dùng để sắp thứ tự | | read_timestamp | thời điểm Datastream đọc được |

Từ khoá nhận diện:

"giá trị các cột sau khi thay đổi" → payload "loại thay đổi, tên bảng" → source_metadata "thứ tự sự kiện" → source_timestamp "thông điệp thất bại" → dead-letter topic "gộp thay đổi vào bảng đích" → MERGE

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sự kiện trông thế nào | đọc một thông điệp mẫu từ Pub/Sub hoặc tệp trong GCS | | Độ trễ bao nhiêu | chỉ số của Datastream stream | | Bảng đích có khớp nguồn không | so COUNT(*) và vài bản ghi cụ thể |

Và một chi tiết quyết định tính đúng đắn của mọi pipeline CDC: sắp thứ tự theo source_timestamp, không theo thời điểm nhận được. Sự kiện có thể tới lộn xộn, và nếu bạn áp chúng theo thứ tự đến, một lần cập nhật cũ có thể ghi đè lên giá trị mới — sai lệch âm thầm và rất khó truy ngược.

Đáp án

C — Chuẩn hoá định dạng ngày tháng và nối dữ liệu từ nhiều nguồn.

Vì sao đúng

Cả hai việc trong phương án này đều thay đổi hình dạng và nội dung dữ liệu để nó dùng được cho phân tích — đúng định nghĩa của bước Transform.

⚠ Điểm mấu chốt — Transform làm gì cụ thể:

CHUẨN HOÁ ĐỊNH DẠNG
    "02/09/2026", "2026-09-02", "Sep 2 2026"
        ↓ đều thành
    DATE '2026-09-02'
        ↓
    → dữ liệu từ nhiều nguồn so sánh được

NỐI DỮ LIỆU TỪ NHIỀU NGUỒN
    đơn hàng + hồ sơ khách + danh mục sản phẩm
        ↓
    → một bảng phân tích hoàn chỉnh
        ↓
    ⚠ CẢ HAI đều là biến đổi

⚠ Vì sao ba phương án kia thuộc bước KHÁC:

"Nạp dữ liệu cuối vào BigQuery"
    → bước LOAD (chữ L)

"Đặt lịch chạy hằng ngày cho pipeline"
    → ĐIỀU PHỐI (orchestration)
    → Cloud Scheduler, Composer

"Trích xuất dữ liệu thô từ CSDL nguồn"
    → bước EXTRACT (chữ E)
        ↓
    ⚠ Ba việc này đều CẦN THIẾT,
      nhưng KHÔNG phải Transform

⚠ Danh sách các phép biến đổi thường gặp:

CHUẨN HOÁ    → định dạng ngày, mã quốc gia
LÀM SẠCH     → bỏ khoảng trắng, sửa lỗi
ÉP KIỂU      → chuỗi → số, chuỗi → ngày
LOẠI TRÙNG   → giữ bản ghi đúng
LÀM GIÀU     → nối với nguồn khác
TỔNG HỢP     → gộp theo nhóm
ĐỊNH HÌNH    → phi chuẩn hoá, nested/repeated
ẨN DANH HOÁ  → che PII

Xem thêm câu #13067 (lô 136): hỏi MỤC TIÊU của bước Transform → biến dữ liệu thô thành dạng dùng được. Câu này hỏi HOẠT ĐỘNG cụ thể. Hai câu bổ sung nhau — hoàn toàn nhất quán. Và #12953 (lô 134): nhận diện chuẩn hoá mã quốc gia là biến đổi.

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

• A (nạp dữ liệu cuối vào BigQuery) — đây là phương án gần nhất vì cũng là một bước của pipeline, nhưng đó là LOAD, không phải Transform.

• D (trích xuất dữ liệu thô từ CSDL nguồn) — là bước EXTRACT.

• B (đặt lịch chạy hằng ngày) — thuộc về ĐIỀU PHỐI, một phạm trù khác hẳn.

Ghi nhớ

⚠ Các bước của pipeline và việc của chúng — bảng phải thuộc: | Bước | Việc | |---|---| | Extract | lấy dữ liệu ra khỏi nguồn | | Transform | chuẩn hoá, làm sạch, join, tổng hợp | | Load | đưa dữ liệu vào đích | | Assess quality | PHÁT HIỆN vấn đề — không sửa | | Orchestrate | quản lý thứ tự, lịch chạy, phụ thuộc | | Govern | quyền, phân loại, dòng dõi |

Từ khoá nhận diện:

"chuẩn hoá, join, tổng hợp, ép kiểu" → Transform "lấy ra / đưa vào" → Extract / Load "đặt lịch, quản lý phụ thuộc" → điều phối "kiểm tra rỗng, đúng định dạng" → đánh giá chất lượng "ai được truy cập" → quản trị

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Biến đổi có mất dòng không | so COUNT(*) trước và sau | | Ngày tháng có bị hiểu sai không | kiểm tra vài bản ghi ở phần biên tháng | | Kết quả có lặp lại được không | chạy lại và so |

Và một hàm rất đáng dùng khi chuẩn hoá ngày tháng từ nguồn không tin cậy: SAFE.PARSE_DATE. Nó trả về NULL thay vì làm hỏng cả truy vấn khi gặp một giá trị sai định dạng — và một cột NULL đếm được là tín hiệu rõ ràng hơn nhiều so với một job thất bại không rõ nguyên nhân.

Đáp án

A — Cloud Monitoring.

Vì sao đúng

Đề nêu hai nhu cầu: dựng dashboard theo dõi CHỈ SỐ (CPU, system lag) và cấu hình CẢNH BÁO tự động khi job thất bại. Cả hai đều là việc của Cloud Monitoring.

⚠ Điểm mấu chốt — bốn trụ cột quan sát, mỗi cái một loại dữ liệu:

CLOUD MONITORING                  ← đề này
    → CHỈ SỐ (metrics)
    → DASHBOARD
    → ALERTING POLICY
    → trả lời: "hệ thống có khoẻ không"

CLOUD LOGGING
    → LOG, thông báo lỗi, stack trace
    → trả lời: "chuyện gì đã xảy ra"

CLOUD TRACE
    → dấu vết một request qua các dịch vụ

CLOUD PROFILER
    → hàm nào tốn CPU và bộ nhớ

⚠ Các chỉ số Dataflow đáng đưa lên dashboard:

job/system_lag           → độ trễ hệ thống
job/data_watermark_age   → DATA FRESHNESS
job/current_num_vcpus    → số worker
CPU utilization          → worker có bận không
job/element_count        → thông lượng theo bước
job/user_counter         → chỉ số tuỳ chỉnh của bạn

⚠ Cảnh báo khi job thất bại — dùng log-based metric:

1. Trong Cloud Logging, tạo bộ lọc bắt
   sự kiện job chuyển sang FAILED
        ↓
2. Tạo LOG-BASED METRIC từ bộ lọc đó
        ↓
3. Trong Cloud Monitoring, tạo
   ALERTING POLICY trên chỉ số ấy
        ↓
4. Gắn kênh thông báo:
   email, Slack, PagerDuty, Pub/Sub
        ↓
    ⚠ Logging và Monitoring làm việc
      CÙNG NHAU — nhưng công cụ
      TẠO CẢNH BÁO là Monitoring

Xem thêm câu #12920 (lô 133) và #13081 (lô 136): cùng về Dataflow nhưng hỏi nơi tìm LOG và stack trace → khoá là Cloud Logging. Câu này hỏi dashboard chỉ số và cảnh báo → Cloud Monitoring. Ba câu khoá khác nhau vì hỏi hai loại dữ liệu khác nhau — hoàn toàn nhất quán.

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

• C (Cloud Logging) — đây là phương án gần nhất và cung cấp dữ liệu cho log-based metric, nhưng bản thân nó dành cho log dạng chữ; dashboard chỉ số và alerting policy nằm ở Cloud Monitoring.

• B (BigQuery) — kho phân tích; có thể lưu log xuất ra, nhưng không phải công cụ giám sát và cảnh báo.

• D (Data Catalog / Dataplex) — lập danh mục dữ liệu, hoàn toàn không liên quan tới giám sát vận hành.

Ghi nhớ

⚠ Bốn trụ cột quan sát — bảng phải thuộc: | Công cụ | Dữ liệu | Trả lời câu hỏi | |---|---|---| | Cloud Monitoring | chỉ số, dashboard, CẢNH BÁO | hệ thống có khoẻ không | | Cloud Logging | log, stack trace | chuyện gì đã xảy ra | | Cloud Trace | dấu vết phân tán | thời gian đi đâu mất | | Cloud Profiler | hồ sơ CPU/bộ nhớ | hàm nào tốn tài nguyên | | Error Reporting | gom nhóm lỗi | lỗi nào xảy ra nhiều nhất |

Từ khoá nhận diện:

"dashboard chỉ số, cảnh báo" → Cloud Monitoring "stack trace, thông báo lỗi" → Cloud Logging "request chậm ở bước nào" → Cloud Trace "hàm nào ngốn CPU" → Cloud Profiler "gom các lỗi giống nhau" → Error Reporting

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số có sẵn không | Metrics Explorer, tìm dataflow.googleapis.com | | Cảnh báo có gửi được không | thử gửi test tới kênh thông báo | | Ngưỡng có hợp lý không | so với dữ liệu lịch sử vài tuần |

Và một phần của alerting policy rất đáng viết cẩn thận dù dễ bị bỏ qua: ô Documentation. Người nhận cảnh báo lúc hai giờ sáng cần biết ngay chỉ số này nghĩa là gì, ảnh hưởng tới đâu, và bước đầu tiên nên làm — và một dòng hướng dẫn viết sẵn khi đầu óc còn tỉnh táo có giá trị hơn nhiều so với việc phải tự suy luận lúc đó.

Đáp án

B — Storage Transfer Service.

Vì sao đúng

Đề nêu bốn yêu cầu, và chỉ Storage Transfer Service có đủ cả bốn: 50 TB từ NFS tại chỗ, chạy liên tục trong nhiều tuần, GIỚI HẠN BĂNG THÔNG trong giờ cao điểm, và nhật ký cùng báo cáo chi tiết.

⚠ Điểm mấu chốt — ba tính năng chỉ STS có:

1. GIỚI HẠN BĂNG THÔNG
    → agent pool đặt được bandwidth limit
    → không làm nghẽn mạng văn phòng

2. CHẠY LIÊN TỤC, TỰ THỬ LẠI
    → đứt mạng thì tiếp tục, không bắt đầu lại
    → chạy nhiều tuần không cần trông

3. NHẬT KÝ VÀ BÁO CÁO
    → biết tệp nào đã chuyển, tệp nào lỗi
    → xuất được sang Cloud Logging

⚠ Nguồn là NFS tại chỗ → cần AGENT:

Storage Transfer Service với nguồn tại chỗ
        ↓
    Chạy AGENT (container Docker)
    trên máy chủ trong mạng nội bộ
        ↓
    Agent thuộc một AGENT POOL
        ↓
    ⚠ Agent pool là nơi đặt
      GIỚI HẠN BĂNG THÔNG
        ↓
    Nhiều agent → tăng thông lượng,
    chịu lỗi tốt hơn

⚠ Vì sao 50 TB không cần Transfer Appliance:

50 TB, kế hoạch VÀI TUẦN
        ↓
    Nếu có 100 Mbps dành cho việc này
      → ~1 TB/ngày → 50 ngày
    Nếu có 500 Mbps
      → ~5 TB/ngày → 10 ngày
        ↓
    ⚠ Đề nói "trong vài tuần" —
      hoàn toàn khả thi qua mạng
    ⚠ Và đề yêu cầu GIỚI HẠN BĂNG THÔNG,
      tức là mạng vẫn dùng được

Xem thêm câu #13082 (cùng lô): nêu tiêu chí dung lượng và băng thông. #13089 (cùng lô): khoá Transfer Appliance vì mất hơn một năm. #13010 (lô 135): cùng khoá STS với agent pool. Bốn câu, một quy tắc — hoàn toàn nhất quán.

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

• D (Transfer Appliance) — đây là phương án gần nhất về mặt "khối lượng lớn", nhưng đề nói rõ kế hoạch là vài tuần và cần giới hạn băng thông — nghĩa là mạng vẫn dùng được. Thiết bị vật lý cũng không có nhật ký tiến độ liên tục như đề yêu cầu.

• A (gcloud storage) — không có giới hạn băng thông tích hợp, không tự thử lại khi đứt, và không có báo cáo.

• C (Cloud Storage FUSE) — gắn bucket như hệ thống tệp, không phải công cụ di chuyển dữ liệu quy mô lớn.

Ghi nhớ

⚠ Storage Transfer Service — tính năng cần thuộc: | Tính năng | Nội dung | |---|---| | Nguồn | S3, Azure Blob, HTTP, GCS khác, hệ thống tệp TẠI CHỖ | | Agent pool | cần cho nguồn tại chỗ, có REGION | | Giới hạn băng thông | đặt ở agent pool | | Chạy theo lịch hoặc liên tục | | | Tự thử lại | không cần trông | | Kiểm tra toàn vẹn | so checksum | | Nhật ký và báo cáo | xuất được sang Cloud Logging | | Thông báo | qua Pub/Sub |

Từ khoá nhận diện:

"giới hạn băng thông, chạy liên tục, có báo cáo" → Storage Transfer Service "nguồn tại chỗ" → STS + agent pool "mất nhiều tháng nếu truyền mạng" → Transfer Appliance "vài GB một lần" → gcloud storage "gắn bucket như thư mục" → Cloud Storage FUSE

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Job chạy tới đâu | console → Storage Transfer → job → Runs | | Băng thông có bị vượt không | theo dõi trên thiết bị mạng của bạn | | Dữ liệu đã đủ chưa | so số tệp và tổng dung lượng |

Và một tính năng của Storage Transfer Service thường quyết định việc dự án có được phê duyệt hay không: giới hạn băng thông. Đội mạng gần như luôn phản đối một luồng chuyển dữ liệu kéo dài nhiều tuần, và khả năng cam kết "không quá 20% băng thông trong giờ làm việc" là điều biến cuộc tranh luận đó thành một cấu hình đơn giản.

Đáp án

C — Việc bên nhận là một dịch vụ TỰ VIẾT (như Dataflow) hay là loại subscription 'Write to BigQuery' ĐƯỢC QUẢN LÝ.

Vì sao đúng

Nơi tìm nguyên nhân lỗi phụ thuộc vào có mã của bạn đang chạy hay không — vì chỉ mã của bạn mới sinh ra log ứng dụng.

⚠ Điểm mấu chốt — có worker thì có log, không có worker thì không:

SUBSCRIBER TỰ VIẾT (Dataflow, Cloud Run,
Cloud Function)
        ↓
    → có WORKER chạy mã của bạn
    → mã ném ngoại lệ, ghi log
        ↓
    ⚠ CLOUD LOGGING có stack trace
      và thông báo lỗi chi tiết

SUBSCRIPTION ĐƯỢC QUẢN LÝ
(BigQuery / Cloud Storage subscription)
        ↓
    → Pub/Sub tự ghi, KHÔNG có worker
      nào của bạn
        ↓
    ⚠ KHÔNG có log ứng dụng để đọc
    ⚠ Backlog tăng mà không có lỗi nào
        ↓
    → phải bật DEAD-LETTER TOPIC
      mới bắt được thông điệp hỏng

⚠ Bảng quyết định:

Bên nhận là gì?
        ↓
    Dataflow / Cloud Run / Cloud Function
        → CLOUD LOGGING
        → lọc theo resource và job_id

    BigQuery subscription
    Cloud Storage subscription
        → DEAD-LETTER TOPIC
        → đọc thông điệp và thuộc tính
          ghi lý do thất bại

⚠ Nhưng dead-letter hữu ích cho CẢ HAI:

Ngay cả với Dataflow tự viết
        ↓
    Vẫn nên có dead-letter
        ↓
    → Cloud Logging cho biết LÝ DO
    → dead-letter giữ CHÍNH BẢN GHI hỏng
        ↓
    ⚠ Hai thứ bổ sung nhau:
      log để chẩn đoán,
      dead-letter để phân tích và nạp lại

⚠ Đây là câu CHỐT cho một cặp đã gặp: #13081 (lô 136) khoá Cloud Logging vì đó là pipeline Dataflow tự viết; #13090 (cùng lô) khoá Dead-Letter Topic vì đó là BigQuery subscription được quản lý. Câu này nêu chính tiêu chí phân biệt giữa hai trường hợp ấy. Ba câu tạo thành một bộ hoàn chỉnh, hoàn toàn nhất quán.

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

• B (dữ liệu là JSON hay Avro) — đây là phương án gần nhất về mặt "liên quan tới lỗi lược đồ", nhưng định dạng ảnh hưởng NỘI DUNG lỗi, không quyết định NƠI tìm log.

• A (Region của topic) — không liên quan tới nơi ghi log.

• D (số lượng thông điệp) — ảnh hưởng backlog và hiệu năng, không đổi nơi tìm nguyên nhân.

Ghi nhớ

⚠ Chẩn đoán Pub/Sub → BigQuery theo KIẾN TRÚC — bảng phải thuộc: | Kiến trúc | Nơi tìm nguyên nhân | |---|---| | Dataflow tự viết | Cloud Logging — stack trace | | Cloud Run / Cloud Function subscriber | Cloud Logging — log của dịch vụ | | BigQuery subscription (quản lý) | DEAD-LETTER TOPIC | | Cloud Storage subscription | dead-letter topic | | Mọi kiến trúc | Monitoring cho backlog và cảnh báo |

Từ khoá nhận diện:

"subscription được quản lý, không thấy log" → dead-letter topic "pipeline tự viết, cần stack trace" → Cloud Logging "backlog tăng" → num_undelivered_messages "dashboard và cảnh báo" → Cloud Monitoring "bản ghi hỏng để phân tích" → dead-letter

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Subscription thuộc loại nào | gcloud pubsub subscriptions describe <sub> | | Có DLT chưa | cùng lệnh → deadLetterPolicy | | Có log của worker không | Logs Explorer, lọc theo dịch vụ tương ứng |

Và một câu hỏi nên đặt ra đầu tiên mỗi khi gỡ lỗi một luồng Pub/Sub: ai đang thực sự ghi dữ liệu — mã của tôi hay chính Pub/Sub? Câu trả lời quyết định bạn nên mở Logs Explorer hay đi tìm dead-letter topic, và đặt sai câu hỏi đó có thể khiến bạn mất hàng giờ tìm những dòng log không bao giờ tồn tại.

Đáp án

B — Dùng một công cụ biến đổi như Cloud Data Fusion hoặc Dataflow để phân tích dữ liệu phẳng và DỰNG cấu trúc lồng TRƯỚC KHI nạp.

Vì sao đúng

CSV không thể diễn đạt cấu trúc lồng, nên muốn có bảng lồng nhau, bắt buộc phải có một bước biến đổi ở giữa để dựng cấu trúc đó.

⚠ Điểm mấu chốt — cần một bước dựng cấu trúc:

CSV phẳng trong Cloud Storage
        ↓
    ⚠ Nạp thẳng → LUÔN cho bảng PHẲNG
        ↓
    BƯỚC BIẾN ĐỔI (bắt buộc)
      - Dataflow: dựng đối tượng lồng trong mã
      - Data Fusion: dùng node biến đổi
      - hoặc nạp phẳng rồi dùng SQL
        ↓
    BigQuery với lược đồ LỒNG

⚠ Ba cách thực hiện bước biến đổi:

CÁCH 1 — Dataflow
    Đọc CSV → gom theo khoá cha
    → dựng TableRow lồng → ghi BigQuery

CÁCH 2 — Cloud Data Fusion
    Plugin đọc CSV → node Group By / Joiner
    → sink BigQuery với lược đồ lồng

CÁCH 3 — nạp phẳng rồi dựng bằng SQL
    CREATE TABLE ... AS
    SELECT khach_id,
      ARRAY_AGG(STRUCT(ma_don, tien)) AS don_hang
    FROM bang_phang
    GROUP BY khach_id;
        ↓
    ⚠ Cách 3 thường ĐƠN GIẢN NHẤT
      nếu dữ liệu đã vào được BigQuery

⚠ Vì sao bq load với lược đồ lồng khai tay vẫn không đủ:

Khai lược đồ lồng trong tệp JSON
rồi nạp CSV
        ↓
    ⚠ VẪN THẤT BẠI
    → CSV không có cấu trúc để ánh xạ vào
      các trường lồng
        ↓
    → giới hạn nằm ở ĐỊNH DẠNG NGUỒN,
      không phải ở cách khai lược đồ

Xem thêm câu #13095 (cùng lô): giải thích VÌ SAO CSV không tạo được lược đồ lồng — vì nó vốn phẳng. Câu này nêu PHẢI LÀM GÌ để vẫn đạt được mục tiêu. Hai câu bổ sung nhau hoàn hảo. Và #13063 (lô 136): với NDJSON thì nạp thẳng được.

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

• D (dùng bq load với lược đồ lồng khai tay) — đây là phương án gần nhất và nghe rất hợp lý, nhưng khai lược đồ không tạo ra cấu trúc từ dữ liệu phẳng: CSV không có cách nào chỉ ra trường nào thuộc record nào.

• A (đổi tên tệp từ .csv thành .json) — đổi tên không đổi nội dung; BigQuery sẽ báo lỗi phân tích cú pháp.

• C (nén bằng GZIP trước khi nạp) — ảnh hưởng kích thước và tốc độ, không liên quan tới cấu trúc.

Ghi nhớ

⚠ Muốn lược đồ lồng — bảng phải thuộc: | Nguồn | Cách làm | |---|---| | JSON (NDJSON), Avro, Parquet | nạp THẲNG — giữ nguyên cấu trúc | | CSV | BẮT BUỘC có bước biến đổi | | Công cụ biến đổi | Dataflow, Data Fusion, hoặc SQL trong BigQuery | | Cách gọn nhất | nạp phẳng rồi ARRAY_AGG(STRUCT(...)) | | Không làm được bằng | khai lược đồ, đổi tên tệp, nén |

Từ khoá nhận diện:

"CSV nhưng muốn lược đồ lồng" → bắt buộc có bước biến đổi "NDJSON lồng nhau" → nạp thẳng được "gom nhiều dòng thành mảng" → ARRAY_AGG(STRUCT(...)) "trải mảng thành dòng" → UNNEST "khai lược đồ là đủ" → SAI với CSV

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lược đồ có lồng không | bq show --schema --format=prettyjson — tìm RECORD, REPEATED | | Số bản ghi cha có đúng không | so với COUNT(DISTINCT khoa_cha) của bảng phẳng | | Truy vấn có nhanh hơn không | so total_bytes_billed trước và sau |

Và một cách tiếp cận thường đơn giản hơn nhiều so với việc dựng pipeline biến đổi riêng: nạp CSV vào một bảng staging phẳng, rồi dùng ARRAY_AGG(STRUCT(...)) để tạo bảng lồng. Nạp theo lô vào BigQuery là miễn phí, câu SQL chỉ vài dòng, và bạn không phải vận hành thêm một engine nào cả.

Đáp án

A — BigQuery TÁCH BIỆT lưu trữ và tính toán, cho phép mỗi bên co giãn độc lập và tự động mà không cần người dùng can thiệp.

Vì sao đúng

Đây là nguyên lý kiến trúc nền tảng khiến BigQuery được gọi là kho dữ liệu không máy chủ: bạn không khai báo, không cấp phát, không quản lý bất kỳ máy chủ nào.

⚠ Điểm mấu chốt — hai tầng độc lập:

TẦNG LƯU TRỮ (Colossus)
    → dữ liệu lưu theo CỘT, nén, nhân bản
    → trả tiền theo DUNG LƯỢNG
        ↓
    ⚠ TÁCH RỜI khỏi
        ↓
TẦNG TÍNH TOÁN (Dremel + slot)
    → hàng nghìn worker chạy truy vấn
    → trả tiền theo BYTE QUÉT hoặc SLOT
        ↓
    Nối bằng JUPITER — mạng petabit của Google
        ↓
    ⚠ Thêm dữ liệu KHÔNG cần thêm máy
    ⚠ Truy vấn nặng KHÔNG cần mở rộng lưu trữ

⚠ So với kho dữ liệu truyền thống:

KHO TRUYỀN THỐNG
    → cụm máy chủ cố định
    → lưu trữ và tính toán GẮN CHẶT
        ↓
    ⚠ Hết dung lượng → phải thêm node
    ⚠ Truy vấn chậm → phải thêm node
    ⚠ Node nhàn rỗi vẫn tính tiền
    ⚠ Phải dự báo công suất trước

BIGQUERY
    → thêm dữ liệu: chỉ trả phí lưu
    → truy vấn nặng: Google tự cấp slot
    → không truy vấn: không trả phí tính toán

⚠ Vì sao "không máy chủ" không có nghĩa là "luôn nhanh":

Truy vấn quét 100 TB
        ↓
    → vẫn mất thời gian và tiền
    → BigQuery không phá vỡ vật lý
        ↓
    ⚠ "Serverless" nghĩa là KHÔNG PHẢI
      QUẢN LÝ HẠ TẦNG
    → không có nghĩa là mọi truy vấn
      chạy dưới một giây

Xem thêm câu #13062 (lô 136): về data warehouse và vì sao BigQuery phù hợp. Câu này giải thích nguyên lý kiến trúc bên dưới. Hai câu bổ sung nhau.

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

• D (phải cấp phát và quản lý cụm cố định) — đây là phương án mô tả kho dữ liệu TRUYỀN THỐNG, chính là điều BigQuery loại bỏ. (Mô hình reservation có mua slot, nhưng đó là cách tính tiền, không phải cụm bạn phải vận hành.)

• C (bảo đảm mọi truy vấn xong dưới một giây) — không có bảo đảm nào như vậy; truy vấn quét nhiều dữ liệu vẫn mất thời gian.

• B (chỉ truy cập được qua CLI) — sai: có giao diện web, API, thư viện client, và nhiều công cụ BI.

Ghi nhớ

⚠ Kiến trúc BigQuery — bảng phải thuộc: | Thành phần | Vai trò | |---|---| | Colossus | hệ thống lưu trữ phân tán — dữ liệu theo cột | | Dremel | engine thực thi truy vấn | | Jupiter | mạng petabit nối lưu trữ và tính toán | | Borg | điều phối tài nguyên | | Slot | đơn vị năng lực tính toán | | Nguyên lý | TÁCH BIỆT lưu trữ và tính toán |

Từ khoá nhận diện:

"tách lưu trữ và tính toán, co giãn độc lập" → nguyên lý serverless của BigQuery "không quản lý hạ tầng" → serverless "bảo đảm dưới một giây" → không có bảo đảm như vậy "cụm cố định" → mô hình truyền thống "trả tiền theo byte quét" → on-demand pricing

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn quét bao nhiêu | --dry_run | | Slot có bị thiếu không | INFORMATION_SCHEMA.JOBS → total_slot_ms | | Chi phí chia theo ai | INFORMATION_SCHEMA.JOBS nhóm theo user |

Và một hiểu lầm rất phổ biến về "serverless" đáng làm rõ với đội mới dùng BigQuery: nó bỏ việc vận hành, không bỏ việc thiết kế. Không ai phải cấp phát máy chủ nữa, nhưng một bảng không phân vùng và một thói quen SELECT * vẫn tạo ra hoá đơn lớn hơn nhiều lần so với cùng dữ liệu đó được thiết kế đúng.

Đáp án

B — Thiết kế và xây dựng pipeline ETL vững chắc để đưa dữ liệu từ hệ thống nguồn vào kho dữ liệu.

Vì sao đúng

Đây là mô tả cốt lõi của kỹ sư dữ liệu (data engineer): người xây và vận hành hạ tầng đưa dữ liệu tới nơi cần đến, để những người khác dùng được.

⚠ Điểm mấu chốt — bốn vai trò trong một đội dữ liệu:

DATA ENGINEER                     ← đề này
    → xây pipeline, hạ tầng dữ liệu
    → bảo đảm dữ liệu ĐÚNG, ĐỦ, ĐÚNG GIỜ
    → công cụ: Dataflow, Composer, SQL

DATA ANALYST
    → phân tích, tìm hiểu ý nghĩa
    → dựng dashboard cho nghiệp vụ
    → công cụ: SQL, Looker Studio

DATA SCIENTIST
    → mô hình dự đoán, thống kê
    → công cụ: Python, BigQuery ML, Vertex AI

ANALYTICS ENGINEER
    → giữa engineer và analyst
    → mô hình hoá dữ liệu bằng SQL
    → công cụ: Dataform, dbt

⚠ Kỹ sư dữ liệu làm gì cụ thể mỗi ngày:

- Dựng và bảo trì pipeline nạp dữ liệu
- Thiết kế lược đồ và mô hình dữ liệu
- Bảo đảm CHẤT LƯỢNG và ĐỘ TIN CẬY
- Tối ưu chi phí và hiệu năng
- Điều phối luồng công việc
- Giám sát và xử lý sự cố pipeline
- Quản trị: quyền, phân loại, dòng dõi

⚠ Ba phương án kia thuộc về ai:

"Dùng phương pháp thống kê để diễn giải
 dữ liệu và đưa ra nhận định nghiệp vụ"
    → DATA ANALYST

"Dựng dashboard tương tác cho lãnh đạo"
    → DATA ANALYST (hoặc BI developer)

"Phát triển mô hình học máy dự đoán
 hành vi khách hàng"
    → DATA SCIENTIST

Xem thêm câu #13097 (cùng lô): dashboard cho lãnh đạo — công việc của analyst. Và #13091 (cùng lô): báo cáo phân tích có mã — thiên về data scientist. Ba câu vẽ nên bức tranh phân vai của một đội dữ liệu.

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

• C (dựng dashboard tương tác cho lãnh đạo) — đây là phương án gần nhất vì cũng thuộc lĩnh vực dữ liệu, nhưng đó là công việc của data analyst: diễn giải và trình bày, không phải xây hạ tầng.

• A (dùng thống kê để diễn giải và đưa ra nhận định) — công việc của data analyst.

• D (phát triển mô hình học máy) — công việc của data scientist.

Ghi nhớ

⚠ Bốn vai trò trong đội dữ liệu — bảng phải thuộc: | Vai trò | Công việc chính | Công cụ tiêu biểu | |---|---|---| | Data engineer | xây PIPELINE và hạ tầng dữ liệu | Dataflow, Composer, Dataform | | Data analyst | phân tích, dashboard, nhận định | SQL, Looker Studio | | Data scientist | mô hình dự đoán, thống kê | Python, BigQuery ML, Vertex AI | | Analytics engineer | mô hình hoá dữ liệu bằng SQL | Dataform, dbt | | Data steward | quản trị, chất lượng, phân loại | Dataplex |

Từ khoá nhận diện:

"xây pipeline, ETL, hạ tầng" → data engineer "dashboard, nhận định nghiệp vụ" → data analyst "mô hình dự đoán, học máy" → data scientist "mô hình hoá bằng SQL, dbt/Dataform" → analytics engineer "quản trị và chất lượng dữ liệu" → data steward / governance

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline có chạy đúng giờ không | lịch sử chạy trong Composer/Dataform | | Dữ liệu có đủ và đúng không | assertion và kiểm tra chất lượng | | Chi phí có hợp lý không | INFORMATION_SCHEMA.JOBS và billing export |

Và một điều đáng nói về vai trò của kỹ sư dữ liệu mà bản mô tả công việc thường bỏ sót: phần lớn thời gian không dành cho việc xây pipeline mới, mà cho việc giữ những pipeline cũ chạy đúng. Nguồn đổi lược đồ, dữ liệu tới muộn, chi phí tăng bất thường — đó mới là công việc thực tế, và nó quyết định đội phân tích có tin vào số liệu hay không.

Đáp án

B — Dùng Dataplex Universal Catalog để đăng ký các nguồn và áp quản trị, dòng dõi, lập hồ sơ và kiểm tra chất lượng dữ liệu trên cả BigQuery lẫn Cloud Storage.

Vì sao đúng

Đề liệt kê năm nhu cầu, và Dataplex Universal Catalog là dịch vụ duy nhất gộp cả năm: phát hiện tài sản, theo dõi dòng dõi, lập hồ sơ dữ liệu, kiểm tra chất lượng tự động, và quản lý từ điển thuật ngữ nghiệp vụ — tất cả KHÔNG di chuyển dữ liệu.

⚠ Điểm mấu chốt — một lớp quản trị cho nhiều kho, nhiều project, nhiều Region:

Dataplex Universal Catalog
        ↓
    Đăng ký nguồn:
      - dataset BigQuery ở nhiều project
      - bucket Cloud Storage ở nhiều Region
        ↓
    ⚠ DỮ LIỆU KHÔNG DI CHUYỂN
    → chỉ siêu dữ liệu được thu thập
        ↓
    Áp lên đó:
      - danh mục và tìm kiếm
      - data lineage
      - data profiling
      - data quality rules
      - business glossary
      - policy tag

⚠ Năm nhu cầu ánh xạ vào năm tính năng:

"phát hiện tài sản"
    → tự động quét và lập danh mục

"theo dõi dòng dõi"
    → DATA LINEAGE — dữ liệu đến từ đâu

"lập hồ sơ dữ liệu"
    → DATA PROFILING — thống kê phân phối cột

"kiểm tra chất lượng tự động"
    → DATA QUALITY — quy tắc, chấm điểm, lịch chạy

"từ điển thuật ngữ nghiệp vụ"
    → BUSINESS GLOSSARY

⚠ Cấu trúc logic của Dataplex:

LAKE
    → ranh giới logic, ví dụ theo phòng ban
        ↓
    ZONE
      - RAW zone: dữ liệu thô
      - CURATED zone: dữ liệu đã xử lý
        ↓
      ASSET
        → trỏ tới bucket hoặc dataset THẬT
        ↓
    ⚠ Tổ chức LOGIC chồng lên
      dữ liệu VẬT LÝ đang nằm rải rác

Xem thêm câu #13028 (lô 135): cùng khoá Data Catalog / Dataplex Universal Catalog cho nhu cầu phát hiện và quản lý siêu dữ liệu. Hai câu hoàn toàn nhất quán. Và #12965/#12980 (lô 134): policy tag — một tính năng của chính Dataplex.

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

• D (Cloud Asset Inventory) — đây là phương án gần nhất vì cũng "kiểm kê toàn tổ chức", nhưng nó lập danh mục TÀI NGUYÊN HẠ TẦNG (VM, bucket, chính sách IAM) cho mục đích quản trị và bảo mật; nó không lập hồ sơ dữ liệu, không theo dõi dòng dõi, không có từ điển nghiệp vụ.

• C (Dataflow gom dữ liệu về một dataset) — DI CHUYỂN dữ liệu — đúng thứ đề nói phải tránh; và nó không phải công cụ quản trị.

• A (Looker) — nền tảng BI và mô hình ngữ nghĩa cho báo cáo; không quản trị dữ liệu trên Cloud Storage và không có các tính năng đề nêu.

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ữ, chất lượng, dòng dõi | | 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 quản trị HẠ TẦNG |

Từ khoá nhận diện:

"phát hiện, dòng dõi, chất lượng, từ điển nghiệp vụ" → Dataplex Universal Catalog "kiểm kê VM, IAM, firewall" → Cloud Asset Inventory "policy tag, phân loại nhạy cảm" → Dataplex Catalog "quét tìm PII" → Sensitive Data Protection "gom dữ liệu về một chỗ" → trái yêu cầu "không di chuyển"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Catalog đã quét được gì | Dataplex → Search | | Bảng nào chưa có mô tả | lọc tài sản thiếu siêu dữ liệu | | Điểm chất lượng dữ liệu | Dataplex → Data quality scans |

Và một sự thật quyết định giá trị của mọi dự án quản trị dữ liệu: phần đắt nhất không phải công nghệ, mà là những mô tả do con người viết. Dataplex tự quét lược đồ trong vài phút và tự dựng dòng dõi, 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 danh mục đầy bảng không mô tả chỉ là một danh sách tên bảng dài hơn.

Đáp án

B — ETLT (Extract, Transform, Load, Transform).

Vì sao đúng

Đề mô tả biến đổi ở CẢ HAI phía: làm sạch và kiểm tra lược đồ TRƯỚC khi nạp, rồi lại tổng hợp SAU khi nạp để dựng bảng báo cáo. Đó là mô hình lai.

⚠ Điểm mấu chốt — đọc kỹ thứ tự trong đề:

E — Trích xuất dữ liệu thô
        ↓
T (thứ nhất) — làm sạch, KIỂM TRA LƯỢC ĐỒ
        ↓        (ở ngoài kho)
L — Nạp vào BigQuery
        ↓
T (thứ hai) — tổng hợp thành bảng báo cáo
             (bằng SQL, trong kho)
        ↓
    ⚠ CÓ HAI chữ T → ETLT

⚠ Vì sao mô hình lai này rất phổ biến trong thực tế:

Biến đổi TRƯỚC khi nạp (T1)
    → chỉ những gì BẮT BUỘC:
        - che PII
        - khử độc dữ liệu không tin cậy
        - kiểm tra lược đồ, loại bản ghi hỏng
        ↓
Biến đổi SAU khi nạp (T2)
    → phần còn lại, bằng SQL:
        - tổng hợp, join, mô hình hoá
        - dựng bảng báo cáo
        ↓
    ⚠ Vừa đáp ứng ràng buộc bảo mật,
      vừa giữ được sự linh hoạt của ELT

⚠ So ba mô hình:

ETL   → biến đổi CHỈ trước khi nạp
ELT   → biến đổi CHỈ sau khi nạp
ETLT  → biến đổi ở CẢ HAI phía    ← đề này
        ↓
    T1 thường NHẸ: bảo mật, chất lượng
    T2 thường NẶNG: mô hình hoá nghiệp vụ

⚠ Xem thêm câu #12993 (lô 135): ở đó ETLT là phương án SAI, vì câu hỏi là "khác biệt CƠ BẢN giữa ETL và ELT" — ETLT không trả lời câu hỏi ấy. Câu này MÔ TẢ một luồng cụ thể có hai lần biến đổi nên ETLT là đúng. Hai câu không mâu thuẫn: cùng một khái niệm, hai vai trò khác nhau trong hai câu hỏi khác nhau. Và #13085 (cùng lô) khoá ETL vì ở đó chỉ nêu biến đổi TRƯỚC khi nạp.

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

• C (ETL) — đây là phương án gần nhất vì vế đầu đúng (có biến đổi trước khi nạp), nhưng nó bỏ qua lần biến đổi THỨ HAI sau khi nạp mà đề mô tả rõ.

• D (ELT) — cũng chỉ đúng một nửa: bỏ qua bước làm sạch và kiểm tra lược đồ trước khi nạp.

• A (Reverse ETL) — đưa dữ liệu TỪ kho NGƯỢC RA các hệ thống nghiệp vụ; hướng hoàn toàn khác.

Ghi nhớ

⚠ Bốn mô hình luồng dữ liệu — bảng phải thuộc: | Mô hình | Thứ tự | Đặc điểm | |---|---|---| | ETL | E → T → L | biến đổi chỉ trước khi nạp | | ELT | E → L → T | biến đổi chỉ sau khi nạp | | ETLT | E → T → L → T | biến đổi ở CẢ HAI phía | | Reverse ETL | kho → hệ thống nghiệp vụ | hướng ngược | | Nhận diện | đếm số lần biến đổi và vị trí của chúng |

Từ khoá nhận diện:

"làm sạch trước khi nạp RỒI tổng hợp sau khi nạp" → ETLT "chỉ biến đổi trước khi nạp" → ETL "nạp thô rồi biến đổi bằng SQL" → ELT "kho → CRM" → Reverse ETL "khác biệt cơ bản giữa ETL và ELT" → câu hỏi khác, trả lời bằng thứ tự T

Ba việc kiểm chứng: | Việc | Cách | |---|---| | T1 có che hết PII không | quét bảng staging bằng DLP | | T2 có chạy lại được không | chạy lại và so kết quả | | Bản ghi hỏng đi đâu | kiểm tra dead-letter của bước T1 |

Và một nguyên tắc thiết kế giúp mô hình ETLT không phình to: T1 chỉ làm những gì bắt buộc phải làm trước khi nạp. Mỗi phép biến đổi đặt vào T1 là một thứ bạn không thể sửa lại mà không trích xuất lại từ nguồn — nên hãy để bảo mật và chất lượng ở đó, còn mọi logic nghiệp vụ thì đẩy sang T2, nơi bạn chạy lại được bất cứ lúc nào.