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

Đáp án

A — Đặt tường minh kiểu biến đổi của cột thành "Categorical".

Vì sao đúng

Mã bưu chính (zip code) trông như số nhưng không phải số: 90210 không "lớn hơn" 10001 theo nghĩa nào cả. Nếu để mô hình coi nó là số, mọi phép so sánh và khoảng cách đều vô nghĩa.

⚠ Vấn đề khi coi zip code là số:

Mô hình học được:
    "zip > 50000 thì khả năng mua cao hơn"
        ↓
    ⚠ Hoàn toàn VÔ NGHĨA
    → mã bưu chính là NHÃN,
      chỉ tình cờ viết bằng chữ số
        ↓
    Khoảng cách 90210 − 90211 = 1
    Khoảng cách 90210 − 10001 = 80209
        ↓
    ⚠ Nhưng hai vùng "cách nhau 1"
      chưa chắc giống nhau chút nào

⚠ Khi đặt Categorical thì AutoML làm gì:

Mỗi mã bưu chính = một HẠNG MỤC riêng
        ↓
    Mã hoá one-hot hoặc embedding
        ↓
    ⚠ Không có thứ tự
    ⚠ Không có khoảng cách số học
    ⚠ Mô hình học ĐỘC LẬP cho từng vùng

⚠ Vì sao đừng phó mặc cho suy luận tự động:

AutoML thấy cột toàn chữ số
        ↓
    ⚠ RẤT DỄ đoán là NUMERIC
        ↓
    Và nó KHÔNG BÁO LỖI —
    mô hình vẫn huấn luyện xong,
    chỉ là học sai quan hệ
        ↓
    → Đây là kiểu lỗi IM LẶNG
      nguy hiểm nhất trong ML
        ↓
    Đặt tường minh = kiểm soát được

⚠ Vì sao KHÔNG đổi zip code thành số nguyên:

"90210" → 90210
        ↓
    ⚠ Làm CHÍNH XÁC điều ta muốn tránh
    ⚠ Còn mất luôn số 0 đứng đầu:
      "01234" → 1234
        ↓
    → hai vùng khác nhau bị trộn làm một

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

• B (để AutoML tự suy luận) — phương án gần nhất và là bẫy chính: suy luận tự động thường đúng, nhưng với cột toàn chữ số nó rất dễ đoán thành numeric. Đề nói rõ nhóm muốn CHẮC CHẮN — vậy thì phải khai tường minh.

• C (dùng biến đổi kiểu text) — kiểu text dành cho văn bản tự do, nó sẽ tách từ, dựng embedding ngôn ngữ. Với một mã ngắn cố định thì đó là lãng phí và nhiễu, dù vẫn hơn numeric.

• D (chuyển zip code thành số nguyên trong file nguồn) — làm nặng thêm chính vấn đề, và mất số 0 đứng đầu.

Ghi nhớ

⚠ Các kiểu biến đổi cột trong AutoML Tabular — bảng phải thuộc: | Kiểu | Dùng cho | |---|---| | Numeric | giá trị có thứ tự và khoảng cách thật — tuổi, giá, số lượng | | Categorical | nhãn rời rạc — mã bưu chính, mã tỉnh, ID sản phẩm, loại | | Text | văn bản tự do — mô tả, nhận xét | | Timestamp | ngày giờ — AutoML tự tách năm/tháng/thứ | | Array | danh sách giá trị |

Từ khoá nhận diện:

"trông như số nhưng là mã" → Categorical "cộng trừ nó có ý nghĩa không?" → nếu KHÔNG thì Categorical "câu văn tự do" → Text "ngày tháng" → Timestamp, đừng để dạng chuỗi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểu cột đã đúng chưa | trang cấu hình huấn luyện — soát từng dòng | | Cột nào ảnh hưởng nhiều | feature importance sau khi huấn luyện | | Mô hình có bị rò rỉ nhãn không | độ chính xác đẹp bất thường (>99%) là dấu hiệu đáng ngờ |

Và một câu hỏi đơn giản nên tự đặt cho mọi cột số trước khi huấn luyện: "lấy trung bình cột này có nghĩa gì không?" Trung bình của tuổi có nghĩa, trung bình của giá có nghĩa — nhưng trung bình của mã bưu chính thì không, và đó là dấu hiệu chắc chắn rằng cột ấy phải là hạng mục.

Đáp án

C — ETL (Extract, Transform, Load).

Vì sao đúng

Đề nói rõ một mệnh đề quyết định: dữ liệu phải được biến đổi và làm sạch TRƯỚC KHI nạp vào bảng phân tích cuối cùng. Đó chính là định nghĩa của ETL — chữ T đứng TRƯỚC chữ L.

⚠ Đọc thứ tự chữ cái là ra đáp án:

E  Extract   — rút từ trung tâm dữ liệu tại chỗ
T  Transform — ⚠ LÀM SẠCH, ÁP LUẬT NGHIỆP VỤ
L  Load      — nạp vào BigQuery
        ↓
    ⚠ Chỉ dữ liệu ĐÃ SẠCH mới vào kho

⚠ So với ELT — khác nhau ở chỗ nào:

ETL                        ELT
  Rút                        Rút
   ↓                          ↓
  BIẾN ĐỔI (ngoài kho)       Nạp THÔ vào kho
   ↓                          ↓
  Nạp bản đã sạch            BIẾN ĐỔI bằng SQL
                              trong chính kho
        ↓                          ↓
⚠ Kho chỉ chứa               ⚠ Kho giữ CẢ dữ liệu thô
  dữ liệu đạt chuẩn            → làm lại được khi
                                 luật nghiệp vụ đổi

⚠ Vì sao ETL vẫn hợp lý ở đây:

Yêu cầu của đề:
  "ensure data quality"
  "enforce business rules"
  "BEFORE it is loaded"
        ↓
    ⚠ Bên nghiệp vụ muốn kho
      KHÔNG BAO GIỜ chứa dữ liệu bẩn
        ↓
    → biến đổi phải ở TRƯỚC bước nạp
    → công cụ: Dataflow, Data Fusion,
      hoặc Dataproc

⚠ Đối chiếu ba câu dễ lẫn:

• Câu này (#13152) khoá ETL — vì đề nhấn "trước khi nạp".
• #13110 (lô 137) khoá ETLT — vì đề đó mô tả hai lần biến đổi: làm sạch/che dữ liệu nhạy cảm trước khi nạp, rồi mới mô hình hoá bằng SQL trong kho.
• #12993 (lô 135) có ETLT là phương án SAI — vì đề đó chỉ có một lần biến đổi, sau khi nạp.

Ba câu KHÔNG mâu thuẫn. Quy tắc đọc đề: đếm xem có mấy lần biến đổi và chúng nằm trước hay sau bước nạp.

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

• B (ELT) — phương án gần nhất và là kiểu hiện đại được ưa chuộng trên BigQuery. Nhưng ELT nạp dữ liệu thô trước rồi mới biến đổi bằng SQL — trái hẳn yêu cầu "làm sạch trước khi nạp" của đề.

• D (ETLT) — có hai lần biến đổi. Đề chỉ mô tả một lần, ở trước bước nạp.

• A (Data Replication) — sao chép dữ liệu y nguyên sang nơi khác, không có bước biến đổi nào. Đó là chuyện của Datastream hay công cụ CDC.

Ghi nhớ

⚠ Bốn mô hình dịch chuyển dữ liệu — bảng phải thuộc: | Mô hình | Đặc điểm | |---|---| | ETL | biến đổi TRƯỚC khi nạp — kho chỉ chứa dữ liệu sạch | | ELT | nạp thô rồi biến đổi bằng SQL trong kho — hiện đại, linh hoạt | | ETLT | làm sạch/che nhẹ trước, mô hình hoá sau — thường vì tuân thủ | | Replication / CDC | sao chép nguyên trạng, không biến đổi |

Từ khoá nhận diện:

"làm sạch TRƯỚC khi nạp" → ETL "nạp thô rồi biến đổi bằng SQL" → ELT "che PII trước khi nạp, mô hình hoá sau" → ETLT "giữ bản sao đồng bộ liên tục" → replication / CDC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu vào kho có sạch không | Dataplex data quality hoặc Dataform assertion | | Có mất bản ghi khi biến đổi không | so số dòng vào và ra | | Làm lại được không nếu luật đổi | có còn giữ bản thô không |

Và một lời khuyên thực tế vượt ra ngoài phòng thi: kể cả khi chọn ETL, vẫn nên lưu một bản sao dữ liệu thô ở Cloud Storage. Luật nghiệp vụ sẽ đổi, và ngày đó bạn sẽ cần chạy lại toàn bộ lịch sử — nếu chỉ còn dữ liệu đã biến đổi thì không có đường lùi.

Đáp án

C — Dùng Storage Transfer Service: cài transfer agent tại chỗ, tạo transfer job trên console và đặt "Bandwidth limit" 60 Mbps.

Vì sao đúng

Đề đặt bốn ràng buộc, và chỉ Storage Transfer Service (STS) thoả cả bốn:

⚠ Bốn ràng buộc, một lời đáp:

1. TRỰC TUYẾN (online)     → STS chạy qua Internet
2. CÓ QUẢN LÝ (managed)    → Google lo lịch, thử lại,
                             kiểm tra toàn vẹn
3. TỪ FILE SERVER TẠI CHỖ  → transfer agent chạy trong
                             mạng nội bộ, đọc hệ thống file
4. ⚠ GIỚI HẠN 60 Mbps      → tuỳ chọn "Bandwidth limit"
                             ngay trong cấu hình job

⚠ Kiến trúc STS cho nguồn tại chỗ:

File server nội bộ
        ↓ đọc
Transfer agent (chạy trong Docker)
   nhiều agent = một agent pool
        ↓ ⚠ chỉ kết nối RA NGOÀI
          → không cần mở cổng vào
        ↓ HTTPS
Storage Transfer Service (Google quản lý)
        ↓
Cloud Storage bucket
        ↓
    ⚠ Băng thông giới hạn ở
      MỨC AGENT POOL
    ⚠ Điều phối, thử lại, checksum
      đều do Google lo

⚠ Tính thời gian — vì sao vẫn nên chọn online:

10 TB ở 60 Mbps
   = 10 × 8.000.000 Mb ÷ 60 Mb/s
   ≈ 1.333.000 giây
   ≈ 15,4 ngày
        ↓
    ⚠ Lâu, nhưng CHẤP NHẬN ĐƯỢC
    ⚠ Và đề đã CHỈ ĐỊNH "online"
        ↓
    (Ngưỡng thường dùng: dưới ~10 TB
     hoặc dưới ~1 tuần thì chọn online;
     lớn hơn nhiều thì Transfer Appliance)

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

• A (Transfer Appliance) — thiết bị vật lý cho chuyển ngoại tuyến. Đây là lựa chọn tốt cho hàng trăm TB, nhưng đề yêu cầu rõ "online", và với 10 TB thì chờ gửi thiết bị đi về còn lâu hơn.

• B (gcloud storage cp + tc/trickle) — phương án gần nhất về mặt kết quả, nhưng không phải dịch vụ có quản lý: bạn tự viết script, tự lo thử lại, tự lo kiểm tra toàn vẹn, và giới hạn băng thông ở tầng hệ điều hành là thủ công, dễ sai. Đề đòi "a managed Google Cloud service".

• D (Cloud Data Fusion) — công cụ ETL, không phải công cụ di chuyển dữ liệu số lượng lớn. Chạy cụm Dataproc chỉ để sao chép file là đắt và phức tạp vô ích, và không có nút giới hạn băng thông như STS.

Ghi nhớ

⚠ Bốn cách đưa dữ liệu lên Google Cloud — bảng phải thuộc: | Cách | Dùng khi | |---|---| | gcloud storage cp | vài GB, một lần, thủ công | | Storage Transfer Service | có quản lý, theo lịch, TỪ tại chỗ / S3 / Azure / URL | | Transfer Appliance | hàng trăm TB, đường truyền yếu — OFFLINE | | Cloud Interconnect / VPN | cần đường riêng lâu dài, băng thông lớn |

Từ khoá nhận diện:

"có quản lý + theo lịch + giới hạn băng thông" → Storage Transfer Service "hàng trăm TB, gửi thiết bị" → Transfer Appliance "từ S3 hoặc Azure Blob sang GCS" → Storage Transfer Service "đường truyền riêng, lâu dài" → Interconnect

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có đúng không vượt 60 Mbps | theo dõi trên router/firewall, không chỉ tin cấu hình | | Đã chép được bao nhiêu | trang chi tiết job — số byte, số file, số lỗi | | Có thiếu file nào không | so số lượng file hai đầu sau khi xong |

Và một chi tiết vận hành rất đáng nhớ: giới hạn băng thông của STS đổi được ngay khi job đang chạy. Cách làm thông minh trong thực tế là hạ xuống thấp trong giờ hành chính và nâng lên vào ban đêm — vẫn tôn trọng yêu cầu của bộ phận IT mà rút ngắn được đáng kể tổng thời gian chuyển.

Đáp án

A — Cấu hình High Availability (HA).

Vì sao đúng

Chỉ cấu hình HA của Cloud SQL mới cho chuyển đổi dự phòng TỰ ĐỘNG khi mất một zone, và đó đúng là yêu cầu của đề.

⚠ HA hoạt động ra sao:

        Region us-central1
   ┌──────────────┬──────────────┐
   zone A          zone B
   PRIMARY  ═══→  STANDBY
   (đang phục vụ)  (bản sao ĐỒNG BỘ,
                    KHÔNG phục vụ đọc)
        ↓
    Ghi được xác nhận chỉ khi
    ĐÃ ghi ở CẢ HAI zone
        ↓
    ⚠ Zone A chết
        ↓
    Cloud SQL tự phát hiện
        ↓
    STANDBY thành PRIMARY
        ↓
    ⚠ Cùng ĐỊA CHỈ IP, cùng tên
    ⚠ Ứng dụng chỉ cần KẾT NỐI LẠI
    ⚠ Thường xong trong ~60 giây

⚠ Ba khái niệm rất hay bị nhầm lẫn:

HA (bản sao dự phòng)
    → chống MẤT ZONE
    → ⚠ TỰ ĐỘNG chuyển
    → standby KHÔNG đọc được

READ REPLICA
    → chống QUÁ TẢI ĐỌC / mất REGION
    → ⚠ chuyển đổi phải THỦ CÔNG
    → sao chép BẤT ĐỒNG BỘ → có thể mất dữ liệu

BACKUP / PITR
    → chống XOÁ NHẦM, HỎNG DỮ LIỆU
    → ⚠ phải KHÔI PHỤC — mất hàng chục phút
    → không phải cơ chế sẵn sàng cao

⚠ Vì sao ba phương án kia không đáp ứng "tự động":

Cross-region read replica
    → phải BẤM promote bằng tay
    → có thể mất giao dịch cuối
    (nhưng là lựa chọn ĐÚNG cho
     thảm hoạ cả REGION)

Point-in-time recovery
    → tạo instance MỚI từ thời điểm cũ
    → mất nhiều phút tới hàng giờ

Automated backups
    → điều kiện CẦN cho PITR và HA
    → nhưng bản thân không tự chuyển

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

• B (bản sao đọc xuyên vùng) — phương án gần nhất, và đúng cho một đề khác: khi câu hỏi là mất cả một region. Ở đây đề nói zonal failure và tự động, mà promote replica là thao tác thủ công.

• C (Point-in-time recovery) — dùng để quay về một mốc thời gian sau khi dữ liệu bị hỏng hoặc xoá nhầm. Không phải cơ chế sẵn sàng cao.

• D (Sao lưu tự động) — cần thiết và là điều kiện tiên quyết để bật HA lẫn PITR, nhưng bản thân sao lưu không chuyển đổi gì cả.

Ghi nhớ

⚠ Bốn cơ chế bảo vệ của Cloud SQL — bảng phải thuộc: | Cơ chế | Chống được | Tự động? | |---|---|---| | HA (regional) | mất ZONE | CÓ, ~60 giây | | Read replica cùng vùng | quá tải đọc | không | | Cross-region replica | mất REGION | KHÔNG — promote thủ công | | Backup + PITR | xoá nhầm, hỏng dữ liệu | không |

Từ khoá nhận diện:

"mất zone + tự động + ít gián đoạn" → HA configuration "mất cả region" → cross-region replica (chấp nhận promote tay) "lỡ tay DELETE không có WHERE" → PITR "giảm tải cho instance chính" → read replica

Ba việc kiểm chứng: | Việc | Cách | |---|---| | HA đã bật chưa | gcloud sql instances describe → availabilityType: REGIONAL | | Chuyển đổi mất bao lâu thật | nút "Trigger failover" ở môi trường thử | | Ứng dụng có tự hồi không | quan sát log ứng dụng trong lúc diễn tập |

Và một điều rất dễ hiểu lầm mà đề thi hay nhắm vào: HA không phải là bản sao lưu. Standby phản chiếu mọi thứ primary làm, kể cả một câu DROP TABLE gõ nhầm — thứ duy nhất cứu được bạn khỏi lỗi ấy là backup và point-in-time recovery.

Đáp án

B — Cloud Key Management Service (Cloud KMS).

Vì sao đúng

CMEK có nghĩa là khoá do khách hàng quản lý, và Cloud KMS là dịch vụ tạo, lưu và quản lý khoá mã hoá trên Google Cloud.

⚠ CMEK hoạt động thế nào với Cloud Storage:

Tạo key ring và key trong Cloud KMS
        ↓
Cấp cho SERVICE AGENT của Cloud Storage
vai `cloudkms.cryptoKeyEncrypterDecrypter`
        ↓
Đặt khoá đó làm khoá mặc định của bucket
        ↓
    Ghi đối tượng
        ↓
    ⚠ Cloud Storage sinh khoá dữ liệu (DEK)
    ⚠ DEK được BỌC bằng khoá KMS (KEK)
    ⚠ ⚠ KHOÁ GỐC KHÔNG BAO GIỜ
      RỜI KHỎI Cloud KMS
        ↓
    Đọc đối tượng → KMS mở khoá DEK

⚠ Ba mức mã hoá — phải phân biệt:

GOOGLE-MANAGED (mặc định)
    → luôn bật, không phải làm gì
    → Google giữ khoá

CMEK
    → ⚠ KHOÁ TRONG CLOUD KMS,
      BẠN quản lý vòng đời
    → xoay khoá, tắt khoá, huỷ khoá
    → ⚠ TẮT KHOÁ = dữ liệu KHÔNG ĐỌC ĐƯỢC

CSEK
    → bạn tự giữ khoá NGOÀI Google
    → gửi kèm trong mỗi request
    → mất khoá là mất dữ liệu vĩnh viễn

⚠ Cloud HSM không phải dịch vụ riêng:

Cloud KMS có BA MỨC BẢO VỆ:
    SOFTWARE  → khoá trong phần mềm
    HSM       → ⚠ khoá trong thiết bị
                 FIPS 140-2 Level 3
    EXTERNAL  → khoá ở nhà cung cấp bên ngoài
        ↓
    ⚠ Cloud HSM là MỘT LỰA CHỌN
      BÊN TRONG Cloud KMS,
      không phải dịch vụ song song
        ↓
    → Câu trả lời cho "dịch vụ nào"
      vẫn là Cloud KMS

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

• C (Cloud HSM) — phương án gần nhất và là bẫy chính: Cloud HSM thật sự lưu khoá, nhưng nó là mức bảo vệ HSM bên trong Cloud KMS, không phải một dịch vụ độc lập. Bạn vẫn tạo và quản lý khoá qua giao diện Cloud KMS.

• A (IAM) — quản lý ai được làm gì, kể cả ai được dùng khoá. Nhưng nó không tạo và không lưu khoá mã hoá.

• D (Secret Manager) — lưu bí mật của ứng dụng: mật khẩu, chuỗi kết nối, API key. Không phải khoá mã hoá dùng cho CMEK — hai loại "bí mật" khác nhau hoàn toàn.

Ghi nhớ

⚠ Bốn dịch vụ bảo mật hay bị lẫn — bảng phải thuộc: | Dịch vụ | Lưu gì | |---|---| | Cloud KMS | KHOÁ MÃ HOÁ — dùng cho CMEK | | Secret Manager | mật khẩu, API key, chuỗi kết nối | | IAM | quyền — ai làm được gì | | Certificate Manager | chứng chỉ TLS | | Sensitive Data Protection | phát hiện và che PII |

Từ khoá nhận diện:

"CMEK, khoá mã hoá, xoay khoá" → Cloud KMS "mật khẩu CSDL trong ứng dụng" → Secret Manager "FIPS 140-2 Level 3, thiết bị phần cứng" → mức bảo vệ HSM TRONG Cloud KMS "tự giữ khoá ngoài Google" → CSEK hoặc EKM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket đang dùng khoá nào | gcloud storage buckets describe → defaultKmsKeyName | | Ai đã dùng khoá | Cloud Audit Logs của Cloud KMS | | Khoá xoay đúng chu kỳ chưa | gcloud kms keys describe → rotationPeriod |

Và một điều nên xác lập ngay khi bật CMEK lần đầu: ai có quyền tắt hoặc huỷ khoá. Quyền đó mạnh ngang quyền xoá toàn bộ dữ liệu — chỉ khác là nó xảy ra tức thì và không có thùng rác để lục lại.

Đáp án

A — Project chứa dataset; dataset chứa bảng, view, model và routine; tham chiếu bảng bằng project.dataset.table.

Vì sao đúng

Đây là mô tả đúng phân cấp tài nguyên của BigQuery, và cũng là cách viết tên đủ điều kiện mà mọi truy vấn dùng.

⚠ Phân cấp — ba tầng:

ORGANIZATION
   └── FOLDER
        └── PROJECT           ← ranh giới TÍNH TIỀN và IAM
             └── DATASET      ← ⚠ ranh giới VỊ TRÍ ĐỊA LÝ
                  ├── TABLE
                  ├── VIEW / MATERIALIZED VIEW
                  ├── MODEL (BigQuery ML)
                  ├── ROUTINE (hàm, thủ tục)
                  └── EXTERNAL TABLE

⚠ Cách viết tên trong truy vấn:

-- đủ điều kiện, luôn đúng
SELECT * FROM `du-an-abc.ban_hang.don_hang`;

-- bỏ project nếu truy vấn chạy trong chính project đó
SELECT * FROM ban_hang.don_hang;

-- ⚠ dấu backtick BẮT BUỘC khi tên
--   có dấu gạch ngang
SELECT * FROM `du-an-abc.ban_hang.don_hang`;

        ↓
    ⚠ KHÔNG có kiểu project.table
      — dataset là BẮT BUỘC

⚠ Vì sao dataset lại quan trọng đến vậy:

DATASET quyết định:
    1. ⚠ VỊ TRÍ ĐỊA LÝ (US, EU, asia-southeast1)
         → không đổi được sau khi tạo
         → ⚠ KHÔNG join được bảng khác vùng
    2. Ranh giới cấp quyền tiện nhất
    3. Thời gian sống mặc định của bảng
    4. Khoá CMEK mặc định
        ↓
    ⚠ Nghĩ kỹ về vị trí TRƯỚC khi tạo dataset

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

• B (dataset là tuỳ chọn, tạo bảng thẳng trong project) — phương án gần nhất và sai ở một điểm dứt khoát: bảng BẮT BUỘC phải nằm trong một dataset. Không tồn tại dạng project.table.

• C (dataset chứa project) — đảo ngược phân cấp. Project là cấp cao hơn.

• D (bảng và view là tài nguyên cấp cao nhất) — sai hoàn toàn; và dataset.table chỉ là dạng rút gọn khi đã ở trong project đó, không phải cách tham chiếu duy nhất.

Ghi nhớ

⚠ Phân cấp BigQuery — bảng phải thuộc: | Cấp | Vai trò | |---|---| | Project | ranh giới TÍNH TIỀN, hạn ngạch, IAM | | Dataset | ranh giới VỊ TRÍ, đơn vị cấp quyền tự nhiên | | Table / View / Model / Routine | đối tượng thật | | Tham chiếu | project.dataset.table |

Từ khoá nhận diện:

"bảng nằm ở đâu" → trong dataset, luôn luôn "đổi vùng của dataset" → KHÔNG được — phải tạo mới và sao chép "join hai bảng khác vùng" → KHÔNG được — phải chuyển về cùng vùng "cấp quyền cho cả nhóm bảng" → cấp ở mức dataset

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dataset ở vùng nào | bq show --format=prettyjson <dataset> → location | | Có những gì trong dataset | bq ls <project>:<dataset> | | Ai có quyền gì | tab Sharing của dataset, hoặc bq show --format=json |

Và một quyết định nên cân nhắc thật kỹ ngay từ ngày đầu dựng kho: vị trí của dataset. Nó không đổi được, nó quyết định bảng nào join được với bảng nào, và sửa lại khi kho đã có hàng trăm bảng là một dự án di chuyển dữ liệu chứ không còn là một thao tác cấu hình.

Đáp án

B — Cloud Composer (Apache Airflow có quản lý), dùng DataflowTemplateOperator và các operator BigQuery để mô hình hoá DAG với phụ thuộc và thử lại.

Vì sao đúng

Đề dùng đúng những từ khoá của thế giới Airflow: "DAG viết bằng Python", "retries", "dependencies", và một chuỗi ba bước dữ liệu chạy hằng đêm.

⚠ Bốn yêu cầu ↔ Cloud Composer:

1. DAG BẰNG PYTHON
     → ⚠ Airflow định nghĩa DAG
       bằng chính mã Python

2. THỬ LẠI + PHỤ THUỘC
     → retries, retry_delay ở mức task
     → toán tử >> để khai phụ thuộc

3. GỌI DATAFLOW TEMPLATE
     → ⚠ DataflowTemplateOperator
       có SẴN, không phải tự viết

4. CHẠY SQL BIGQUERY
     → BigQueryInsertJobOperator có sẵn

⚠ DAG trông như thế này:

with DAG('pipeline_dem',
         schedule='0 2 * * *',
         default_args={'retries': 3,
                       'retry_delay': timedelta(minutes=5)}) as dag:

    nap = DataflowTemplateOperator(
        task_id='nap_tu_gcs',
        template='gs://.../template')

    bien_doi = BigQueryInsertJobOperator(
        task_id='bien_doi',
        configuration={'query': {'query': SQL}})

    lam_moi = SimpleHttpOperator(task_id='lam_moi_dashboard', ...)

    nap >> bien_doi >> lam_moi

        ↓
    ⚠ Một dòng cuối khai đủ phụ thuộc
    ⚠ Bước sau chỉ chạy khi bước trước THÀNH CÔNG
    ⚠ Giao diện Airflow: xem DAG, log,
      chạy lại đúng một task hỏng

⚠ Đối chiếu #13145 (cùng lô này) — đề đó khoá Cloud Workflows vì yêu cầu là "nhẹ nhàng nhất" cho ba lời gọi REST API. Câu này khoá Cloud Composer vì đề đòi DAG Python kiểu Airflow, có operator dựng sẵn cho Dataflow và BigQuery. Hai câu KHÔNG mâu thuẫn — chúng hỏi hai tình huống khác nhau.

Cách phân biệt khi làm bài: thấy chữ "Airflow", "DAG", "operator", "Python" → Composer. Thấy "nhẹ nhất", "serverless", "gọi REST API", "trả tiền theo bước" → Workflows.

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

• A (Cloud Workflows) — phương án gần nhất, và đúng cho tình huống nhẹ hơn. Nhưng đề nói thẳng là muốn DAG Python và operator Airflow; chính lời văn của phương án A cũng thừa nhận "không có DAG và operator Airflow".

• C (scheduled query của BigQuery) — chỉ lập lịch được bước SQL. Nó không khởi chạy được Dataflow, không điều phối phụ thuộc giữa các bước.

• D (nhiều job Cloud Scheduler riêng lẻ) — mỗi job chạy độc lập theo giờ, không hề biết bước trước đã xong hay chưa. Đây là kiểu "điều phối bằng cách đoán thời gian" — bước trước chậm một chút là cả chuỗi sai.

Ghi nhớ

⚠ Composer hay Workflows — bảng quyết định: | Tiêu chí | Composer | Workflows | |---|---|---| | Định nghĩa | Python (Airflow) | YAML/JSON | | Chi phí | cụm chạy THƯỜNG TRỰC, tốn cả khi rảnh | theo BƯỚC, gần 0 khi rảnh | | Hệ sinh thái | hàng trăm operator dựng sẵn | connector Google Cloud + HTTP | | Giao diện | UI Airflow đầy đủ | xem thực thi trong console | | Hợp với | pipeline dữ liệu phức tạp, nhiều phụ thuộc | chuỗi lời gọi API nhẹ |

Từ khoá nhận diện:

"DAG, Airflow, operator, Python" → Cloud Composer "nhẹ nhất, serverless, gọi REST" → Cloud Workflows "chỉ chạy một câu SQL theo lịch" → scheduled query "chỉ cần cron kích hoạt một đích" → Cloud Scheduler

Ba việc kiểm chứng: | Việc | Cách | |---|---| | DAG chạy tới đâu | Graph view trong UI Airflow | | Task nào hỏng | xem log task, chạy lại đúng task đó | | Có chạy bù ngoài ý muốn không | ⚠ kiểm catchup và start_date |

Và một cái bẫy khiến rất nhiều người mất một buổi sáng khi bật DAG đầu tiên: catchup mặc định là bật. Một DAG có start_date từ đầu năm sẽ lập tức xếp hàng chạy bù hàng trăm lần thực thi ngay khi được kích hoạt — hãy đặt catchup=False trừ khi bạn thật sự muốn chạy lại quá khứ.

Đáp án

B — TRIM(review_text)

Vì sao đúng

TRIM là hàm chuẩn của GoogleSQL (ngôn ngữ SQL của BigQuery) để cắt khoảng trắng ở đầu và cuối chuỗi.

⚠ Ba hàm cùng họ:

SELECT
  TRIM('  xin chào  ')   AS ca_hai_dau,  -- 'xin chào'
  LTRIM('  xin chào  ')  AS ben_trai,    -- 'xin chào  '
  RTRIM('  xin chào  ')  AS ben_phai;    -- '  xin chào'

        ↓
    TRIM   → cắt CẢ HAI đầu  ← đề này
    LTRIM  → chỉ bên TRÁI
    RTRIM  → chỉ bên PHẢI

⚠ TRIM còn cắt được ký tự khác khoảng trắng:

SELECT TRIM('***khuyến mãi***', '*');
-- → 'khuyến mãi'

SELECT TRIM('$1.234,00', '$,');
-- → '1.234.00' — cắt mọi ký tự có trong tập

        ↓
    ⚠ Tham số thứ hai là TẬP KÝ TỰ,
      không phải một chuỗi con

⚠ Vì sao ba tên kia không tồn tại trong GoogleSQL:

STRIP()   → ⚠ đó là PYTHON (.strip()),
             KHÔNG có trong BigQuery

CLEAN()   → không tồn tại

FORMAT()  → CÓ tồn tại nhưng để
             ĐỊNH DẠNG chuỗi,
             không cắt khoảng trắng
             FORMAT('%s có %d đơn', ten, n)

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

• A (FORMAT) — phương án gần nhất vì hàm này có thật, nhưng việc của nó là dựng chuỗi theo mẫu (giống printf), hoàn toàn không liên quan tới cắt khoảng trắng.

• C (STRIP) — tên hàm của Python, không có trong GoogleSQL. Chạy sẽ báo Function not found.

• D (CLEAN) — không tồn tại trong BigQuery.

Ghi nhớ

⚠ Hàm chuỗi hay dùng trong BigQuery — bảng phải thuộc: | Hàm | Việc | |---|---| | TRIM / LTRIM / RTRIM | cắt khoảng trắng hoặc ký tự ở rìa | | UPPER / LOWER | đổi hoa thường | | CONCAT hoặc \|\| | nối chuỗi | | SUBSTR | cắt đoạn con | | SPLIT | tách thành mảng | | REPLACE | thay chuỗi con | | REGEXP_REPLACE | thay theo biểu thức chính quy | | LENGTH | độ dài ký tự | | NORMALIZE | chuẩn hoá Unicode — rất quan trọng với tiếng Việt |

Từ khoá nhận diện:

"khoảng trắng thừa ở đầu/cuối" → TRIM "khoảng trắng thừa Ở GIỮA" → REGEXP_REPLACE(x, r'\\s+', ' ') "so sánh không phân biệt hoa thường" → LOWER cả hai vế "tách chuỗi thành nhiều dòng" → SPLIT + UNNEST

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn bao nhiêu dòng dính khoảng trắng | COUNTIF(x != TRIM(x)) | | Có chuỗi rỗng ẩn không | COUNTIF(TRIM(x) = '') | | Có bao nhiêu giá trị phân biệt sau khi sạch | so COUNT(DISTINCT x) với COUNT(DISTINCT TRIM(LOWER(x))) |

Và một phép kiểm tra rất đáng chạy trên mọi cột văn bản mới nhận về: đếm số giá trị phân biệt trước và sau khi chuẩn hoá. Chênh lệch lớn giữa hai con số là bằng chứng trực tiếp rằng dữ liệu đang bị phân mảnh vì khoảng trắng và hoa thường — và mọi báo cáo nhóm theo cột đó đều đang đếm sai.

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào việc xây dựng mô hình Machine Learning trong BigQuery ML (một dịch vụ của Google Cloud Platform - GCP) để dự đoán customer churn (khách hàng rời bỏ) dựa trên dữ liệu lịch sử mua sắm lưu trữ trong bảng customer_data. Dữ liệu bao gồm thông tin nhân khẩu học, lịch sử mua hàng và cột churned làm nhãn mục tiêu (target label - 1 nếu churn, 0 nếu không).

📌 Yêu cầu chính: Tạo và huấn luyện mô hình logistic regression (model_type='logistic_reg') bằng câu lệnh CREATE OR REPLACE MODEL. Câu lệnh phải:

• Chỉ định tên model: churn_prediction_model.
• Sử dụng bảng customer_data.
• Tách biệt features (các đặc trưng đầu vào như demographics, purchase history) và label (churned).
• Tuân thủ quy tắc BigQuery ML: Đối với phân loại nhị phân (binary classification) như logistic regression, query phải cung cấp tất cả features (không bao gồm label) và label riêng biệt (alias là label).

🛠️ Lưu ý kỹ thuật từ BigQuery ML (cập nhật đến 2026):

• Syntax chuẩn: CREATE OR REPLACE MODEL model_name OPTIONS(model_type='logistic_reg') AS SELECT features..., label AS label FROM table;.
• Không được include label vào features (tránh data leakage).
• Bắt buộc có cột label được alias rõ ràng.
• Tài liệu chính thức: BigQuery ML Documentation - CREATE MODEL và Logistic Regression in BigQuery ML.

✅ Đáp án đúng

Đáp án đúng là lựa chọn thứ 2:

<code><pre>CREATE OR REPLACE MODEL churn_prediction_model
OPTIONS (model_type='logistic_reg') AS
SELECT * EXCEPT(churned),
        churned AS label
FROM customer_data;</pre></code>

Lý do lựa chọn:

• 🟢 Query này hoàn hảo vì sử dụng * EXCEPT(churned) để chọn tất cả features (loại trừ cột churned), sau đó thêm churned AS label làm nhãn mục tiêu riêng biệt.
• Đảm bảo không data leakage (label không lẫn vào features), phù hợp cho logistic regression binary classification.
• BigQuery ML sẽ tự động huấn luyện model với input chuẩn, dự đoán churn risk chính xác. ✅

📋 Giải thích chi tiết tất cả các phương án

• Phương án 1 (Sai ❌):

  <code><pre>CREATE OR REPLACE MODEL churn_prediction_model
  OPTIONS (model_type='logistic_reg') AS
  SELECT *
  FROM customer_data;</pre></code>
  

  Giải thích sai: Query chọn * (tất cả cột), nên cột churned bị lẫn vào features, gây data leakage nghiêm trọng. BigQuery ML sẽ báo lỗi hoặc model kém chất lượng vì label không được tách biệt và alias là label. Không tuân thủ quy tắc bắt buộc của BQML. ❌

• Phương án 2 (Đúng ✅): (Như đã giải thích ở trên - hoàn chỉnh và chuẩn xác). 🟢

• Phương án 3 (Sai ❌):

  <code><pre>CREATE OR REPLACE MODEL churn_prediction_model OPTIONS(model_type='logistic_reg') AS 
  SELECT * EXCEPT (churned) 
  FROM customer_data;</pre></code>
  

  Giải thích sai: Query chỉ chọn * EXCEPT(churned) (features đầy đủ), nhưng thiếu hoàn toàn cột label (churned AS label). BigQuery ML yêu cầu bắt buộc có cột label cho supervised learning như logistic regression, nên sẽ báo lỗi "No label column". ❌

• Phương án 4 (Sai ❌):

  <code><pre>CREATE OR REPLACE MODEL churn_prediction_model
  OPTIONS (model_type='logistic_reg') AS
  SELECT churned as label
  FROM customer_data;</pre></code>
  

  Giải thích sai: Query chỉ chọn churned as label (có label đúng), nhưng thiếu tất cả features (demographics, purchase history). Model không có input để học, BigQuery ML sẽ báo lỗi thiếu features hoặc model vô nghĩa (không dự đoán được churn dựa trên dữ liệu). ❌

📘 Tài liệu tham khảo bổ sung

• Google Cloud BigQuery ML Syntax (cập nhật 2024-2026).
• Tutorial: Predict Customer Churn with BigQuery ML.
• Best practices: Sử dụng ML.TRAINING_RUN để monitor training sau khi create model.

Hy vọng phân tích này giúp bạn nắm vững BigQuery ML! 🚀 Nếu cần ví dụ thực hành, hãy hỏi thêm.

🧩 Phân tích nội dung câu hỏi

Câu hỏi yêu cầu sử dụng SQL để tính trung bình di động hàng tuần (weekly moving average) của tổng doanh số bán hàng (total_sales) theo từng cửa hàng (store_id), dựa trên dữ liệu hàng ngày từ bảng store_sales_daily. Mục tiêu là xác định xu hướng doanh số cho từng cửa hàng riêng lẻ.

• Yêu cầu chính:
  • Phân vùng (PARTITION) theo store_id để tính riêng cho từng cửa hàng. ✅
  • Sắp xếp (ORDER BY) theo date để đảm bảo tính theo thứ tự thời gian. ✅
  • Sử dụng cửa sổ trượt (window frame) với 6 hàng trước đó + hàng hiện tại (tổng 7 hàng, tương đương 1 tuần nếu dữ liệu hàng ngày). 🛠️

Điều này sử dụng hàm cửa sổ AVG() OVER() trong SQL (hỗ trợ đầy đủ trên Amazon Redshift, Athena, và các dịch vụ AWS khác đến phiên bản 2026). 📘

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng là phương án thứ 3 (đã đánh dấu [ĐÚNG]):

SELECT 
    store_id, 
    date, 
    total_sales, 
    AVG(total_sales) 
    OVER (
        PARTITION BY store_id
        ORDER BY date 
        ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
    ) as rolling_avg
FROM store_sales_daily

Lý do:

• PARTITION BY store_id: Đúng vì tính trung bình riêng cho từng cửa hàng, tránh lẫn dữ liệu giữa các store. 🏪
• ORDER BY date: Đúng vì di động theo thời gian (daily data), đảm bảo cửa sổ trượt theo thứ tự ngày. 📅
• ROWS BETWEEN 6 PRECEDING AND CURRENT ROW: Chính xác cho 7 hàng gần nhất (6 ngày trước + hiện tại), phù hợp weekly moving average trên dữ liệu discrete rows. ROWS đếm physical rows, lý tưởng cho daily distinct dates. 🚀
• Kết quả: Mỗi hàng sẽ có rolling_avg là trung bình 7 ngày gần nhất của store đó, giúp phát hiện xu hướng.

🛠️ Giải thích chi tiết từng phương án

Dưới đây là phân tích tất cả 4 phương án, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên SQL window functions (AWS Redshift v2.0+ và Athena 2026). ❌ cho sai, ✅ cho đúng.

• Phương án 1 [SAI] ❌

  SELECT store_id, date, total_sales, 
         AVG(total_sales) OVER (
             PARTITION BY store_id
             ORDER BY total_sales
             RANGE BETWEEN 6 PRECEDING AND CURRENT ROW
         ) AS rolling_avg
  FROM store_sales_daily;
  

  Lý do sai:

  • ORDER BY total_sales thay vì date → Cửa sổ trượt theo giá trị doanh số (không theo thời gian), dẫn đến thứ tự ngẫu nhiên, không phản ánh xu hướng hàng tuần. Sai hoàn toàn! 😵
  • RANGE thay vì ROWS: RANGE dựa trên giá trị (peer rows có cùng total_sales), có thể bao gồm nhiều hơn 7 ngày nếu sales trùng lặp. Không phù hợp cho moving average thời gian.

• Phương án 2 [SAI] ❌

  SELECT store_id, date, total_sales, 
         AVG(total_sales) 
         OVER ( 
             PARTITION BY date 
             ORDER BY store_id 
             ROWS BETWEEN 6 PRECEDING AND CURRENT ROW 
         ) as rolling_avg
  FROM store_sales_daily
  

  Lý do sai:

  • PARTITION BY date → Nhóm theo ngày thay vì store_id, tính trung bình tất cả stores cùng ngày, không phân tích xu hướng theo từng cửa hàng. Sai mục tiêu! 🏪❌
  • ORDER BY store_id → Sắp xếp theo ID cửa hàng, không theo thời gian, cửa sổ trượt vô nghĩa cho weekly trend.

• Phương án 3 [ĐÚNG] ✅

  SELECT 
      store_id, 
      date, 
      total_sales, 
      AVG(total_sales) 
      OVER (
          PARTITION BY store_id
          ORDER BY date 
          ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
      ) as rolling_avg
  FROM store_sales_daily
  

  Lý do đúng: Như đã giải thích ở phần trên. Hoàn hảo cho yêu cầu! 🌟 (ROWS chính xác vì đếm exact 7 rows theo date order).

• Phương án 4 [SAI] ❌

  SELECT 
      store_id, 
      date, 
      total_sales, 
      AVG(total_sales) 
  OVER (
      PARTITION BY total_sales
      ORDER BY date 
      RANGE BETWEEN 6 PRECEDING AND CURRENT ROW
  ) AS rolling_avg
  FROM store_sales_daily
  

  Lý do sai:

  • PARTITION BY total_sales → Nhóm theo giá trị doanh số, không theo store_id → Kết quả lẫn lộn giữa các cửa hàng có sales giống nhau, không xác định xu hướng per store. Hoàn toàn sai! 💥
  • RANGE: Có thể mở rộng ngoài 7 ngày nếu nhiều rows có total_sales giống nhau trong range.

📘 Tài liệu tham khảo (AWS cập nhật 2026)

• Amazon Redshift SQL Reference - Window Functions: https://docs.aws.amazon.com/redshift/latest/dg/r_WF_window_clause.html (ROWS vs RANGE chi tiết).
• Athena Documentation - OVER Clause: https://docs.aws.amazon.com/athena/latest/ug/window-functions.html (Hỗ trợ identical từ v3+).
• AWS Big Data Blog - Moving Averages: https://aws.amazon.com/blogs/big-data/analyze-time-series-data-with-amazon-redshift/ (Ví dụ thực tế weekly rolling avg).

Phân tích này dựa trên best practices AWS SQL đến 2026. Nếu cần query test, hãy cung cấp sample data! 🧪