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

Đáp án

B — Cloud Storage.

Vì sao đúng

Đề liệt kê video độ phân giải cao, bản ghi âm, tệp PDF, tệp nhật ký ứng dụng — tất cả đều là dữ liệu PHI CẤU TRÚC, và Cloud Storage là kho đối tượng của Google Cloud cho đúng loại này.

⚠ Điểm mấu chốt — kho đối tượng cho tệp phi cấu trúc:

Video, âm thanh, PDF, log thô
        ↓
    Không có lược đồ
    Kích thước rất lớn
    Chỉ cần LƯU và LẤY RA
        ↓
    CLOUD STORAGE
        ↓
    - dung lượng KHÔNG GIỚI HẠN
    - đối tượng tới 5 TB mỗi tệp
    - độ bền 11 số 9
    - giá rất rẻ, có nhiều lớp lưu trữ

⚠ Vì sao ba phương án kia đều sai loại:

BIGQUERY
    → kho PHÂN TÍCH cho dữ liệu
      CÓ CẤU TRÚC
    → nhét video vào là sai mục đích
      và cực đắt

CLOUD SQL
    → CSDL GIAO DỊCH
    → lưu BLOB làm phình CSDL,
      sao lưu chậm, giá cao

BIGTABLE
    → NoSQL khoá-giá trị cho
      GHI CỰC LỚN, chuỗi thời gian
    → không phải nơi lưu tệp lớn

⚠ Mẫu chuẩn — tệp ở kho đối tượng, siêu dữ liệu ở CSDL:

CLOUD STORAGE
    gs://media/video/{uuid}.mp4
        ↓
BIGQUERY hoặc CLOUD SQL
    id, tieu_de, thoi_luong, tac_gia,
    uri = 'gs://media/video/{uuid}.mp4'
        ↓
    ⚠ Truy vấn siêu dữ liệu bằng SQL
    ⚠ Lấy tệp bằng đường dẫn
    ⚠ KHÔNG BAO GIỜ nhét tệp vào CSDL

Xem thêm câu #12998 (lô 135): nhận diện dữ liệu phi cấu trúc. Và #13057, #13062 (cùng lô): ánh xạ từng loại dữ liệu vào đúng dịch vụ. Ba câu nhất quán.

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

• D (BigQuery) — đây là phương án dễ nhầm nhất vì nó cũng chứa được lượng dữ liệu khổng lồ, nhưng nó là kho PHÂN TÍCH cho dữ liệu CÓ CẤU TRÚC; lưu video trong đó vừa sai mục đích vừa rất đắt.

• C (Cloud SQL) — CSDL giao dịch; lưu tệp lớn dạng BLOB làm phình CSDL và chậm sao lưu.

• A (Bigtable) — NoSQL cho ghi cực lớn và chuỗi thời gian, giới hạn kích thước ô nhỏ, không phải nơi lưu tệp media.

Ghi nhớ

⚠ Chọn kho theo LOẠI DỮ LIỆU — bảng phải thuộc: | Loại dữ liệu | Kho | |---|---| | Phi cấu trúc: video, ảnh, PDF, log thô | Cloud Storage | | Có cấu trúc, PHÂN TÍCH | BigQuery | | Có cấu trúc, GIAO DỊCH | Cloud SQL / AlloyDB / Spanner | | Bán cấu trúc, ứng dụng di động | Firestore | | NoSQL ghi cực lớn, chuỗi thời gian | Bigtable | | Bộ nhớ đệm | Memorystore |

Từ khoá nhận diện:

"video, âm thanh, PDF, tệp lớn" → Cloud Storage "phân tích hàng tỉ dòng" → BigQuery "giao dịch ứng dụng" → Cloud SQL "IoT, chuỗi thời gian, ghi hàng triệu điểm/giây" → Bigtable "lưu tệp trong CSDL" → luôn là phương án SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket đang tốn bao nhiêu | gcloud storage du -s gs://bucket | | Phân bố theo lớp lưu trữ | billing export, nhóm theo SKU | | Có lifecycle rule chưa | gcloud storage buckets describe → lifecycle |

Và một quy ước nên thống nhất ngay khi lập kho media: cách đặt tên đối tượng. Dùng một cấu trúc có ý nghĩa (loai/nam/thang/{uuid}.ext) thay vì tên tệp gốc do người dùng đặt — tên gốc trùng nhau, chứa ký tự lạ, và không cho biết tệp thuộc về đâu khi bạn cần dọn dẹp hoặc áp lifecycle rule theo tiền tố về sau.

Đáp án

C — Cloud SQL.

Vì sao đúng

Đề mô tả một ứng dụng hoàn toàn thông thường: CSDL quan hệ được quản lý, lưu hồ sơ người dùng, bài viết và bình luận, phạm vi khu vực, đội quen MySQL, và cần backend đáng tin cậy, đa dụng. Cloud SQL là lựa chọn mặc định.

⚠ Điểm mấu chốt — không có ràng buộc nào đòi hỏi hơn:

"nền tảng blog KHU VỰC"
    → KHÔNG cần nhiều Region
    → không cần Spanner

"đội quen MYSQL"
    → Cloud SQL for MySQL, giữ nguyên
      kỹ năng và công cụ

"đa dụng, đáng tin cậy"
    → không nêu nút thắt hiệu năng
    → không cần AlloyDB

"CSDL QUAN HỆ được quản lý"
    → không phải NoSQL
    → không phải Firestore
        ↓
    → Cloud SQL là câu trả lời

⚠ Cloud SQL cho blog — cấu hình nên có:

- Cấu hình HA (regional)
  → chịu được hỏng một zone
- Sao lưu tự động + PITR
  → quay lại trước lệnh DELETE nhầm
- Read replica
  → giảm tải đọc khi lượng truy cập tăng
- Private IP + Cloud SQL Auth Proxy
  → không lộ ra Internet
- Deletion protection

⚠ Nguyên tắc chọn CSDL — đi từ đơn giản lên:

Bắt đầu bằng CLOUD SQL
        ↓
    Gặp nút thắt hiệu năng PostgreSQL?
        → ALLOYDB
        ↓
    Cần nhiều Region + nhất quán mạnh?
        → SPANNER
        ↓
    ⚠ Đừng chọn công cụ mạnh nhất
      ngay từ đầu — chi phí và độ phức tạp
      tăng theo cấp số

Xem thêm câu #13066 (cùng lô): khoá AlloyDB vì ở đó ứng dụng đang gặp nút thắt hiệu năng và cần PostgreSQL hiệu năng cao. Và #12914 (lô 133): cũng khoá Cloud SQL cho ứng dụng thông thường. Ba câu, hai khoá, phân biệt bằng YÊU CẦU HIỆU NĂNG — hoàn toàn nhất quán.

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

• B (AlloyDB) — đây là phương án gần nhất về mặt "CSDL quan hệ được quản lý mạnh hơn", nhưng nó tương thích PostgreSQL (đội quen MySQL), đắt hơn, và đề không nêu vấn đề hiệu năng nào cần tới nó.

• D (Spanner) — cho quy mô toàn cầu và nhất quán mạnh đa Region; chi phí tối thiểu cao hơn nhiều và không phải MySQL.

• A (Firestore) — NoSQL dạng tài liệu; đề nói rõ cần CSDL QUAN HỆ.

Ghi nhớ

⚠ Chọn CSDL quan hệ — bảng phải thuộc: | Dịch vụ | Dùng khi | |---|---| | Cloud SQL | MẶC ĐỊNH — MySQL/PostgreSQL/SQL Server, một Region | | AlloyDB | PostgreSQL cần hiệu năng cao hơn | | Spanner | nhiều Region, nhất quán mạnh, mở rộng ngang | | BigQuery | phân tích, không phải giao dịch | | Thứ tự | Cloud SQL → AlloyDB → Spanner |

Từ khoá nhận diện:

"ứng dụng thông thường, một khu vực, quen MySQL" → Cloud SQL "PostgreSQL nhưng cần nhanh hơn nhiều" → AlloyDB "nhiều Region + nhất quán mọi lúc" → Spanner "tài liệu JSON, đồng bộ thời gian thực" → Firestore "phân tích" → BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance có bật HA không | gcloud sql instances describe <ten> → availabilityType | | PITR đã bật chưa | cùng lệnh → pointInTimeRecoveryEnabled | | Số kết nối có gần trần không | chỉ số trong Cloud Monitoring |

Và một cấu hình nên bật trước cả HA khi mới dựng CSDL cho ứng dụng thật: point-in-time recovery. Với một nền tảng blog, sự cố dễ xảy ra nhất không phải hỏng phần cứng mà là một lệnh DELETE chạy nhầm phạm vi — và PITR là thứ duy nhất đưa bạn về đúng giây trước lệnh đó.

Đáp án

C — Tạo một Custom Field.

Vì sao đúng

Đề nêu ba điều: người tạo là nhà phân tích KHÔNG có quyền developer, cần tạo trường mới bằng cách nối hai dimension, và phép tính phải được CSDL thực hiện TRƯỚC khi tổng hợp. Custom Field khớp cả ba.

⚠ Điểm mấu chốt — Custom Field được ĐẨY XUỐNG CSDL:

Custom Field (loại custom dimension)
        ↓
    Looker đưa biểu thức vào SQL sinh ra
        ↓
    SELECT CONCAT(first_name, ' ', last_name)
      AS full_name, ...
    FROM ...
    GROUP BY 1
        ↓
    ⚠ CSDL tính TRƯỚC khi tổng hợp
    → đúng yêu cầu của đề

⚠ Vì sao Table Calculation KHÔNG đúng ở đây:

Table Calculation
        ↓
    Tính TRÊN KẾT QUẢ đã trả về
        ↓
    ⚠ Chạy SAU khi CSDL đã tổng hợp
    → không thể dùng làm chiều để
      GOM NHÓM
        ↓
    Đề nói rõ "TRƯỚC khi tổng hợp"

⚠ Ba nơi tính toán — phân biệt dứt điểm:

LOOKML
    → Developer viết, trong CSDL,
      vĩnh viễn, toàn tổ chức

CUSTOM FIELD                     ← đề này
    → NGƯỜI DÙNG tạo, TRONG CSDL,
      thuộc một Explore/Look

TABLE CALCULATION
    → người dùng tạo, TRÊN KẾT QUẢ,
      sau khi tổng hợp

⚠ Hai loại Custom Field:

CUSTOM DIMENSION
    → tạo CHIỀU mới
    → dùng để cắt lớp, gom nhóm
    → ví dụ: CONCAT(first_name, last_name)

CUSTOM MEASURE
    → tạo CHỈ SỐ tổng hợp mới
    → dựa trên dimension có sẵn
        ↓
    Đề này cần CUSTOM DIMENSION

Xem thêm câu #13070 (cùng lô): khoá LookML vì cần chỉ số vĩnh viễn, được quản trị toàn tổ chức. Và #13079 (cùng lô): khoá Table Calculation vì tính trên kết quả đã trả về. Ba câu, ba khoá, phân biệt bằng AI TẠO và TÍNH Ở ĐÂU — hoàn toàn nhất quán.

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

• B (Table Calculation) — đây là phương án gần nhất vì cũng do người dùng tạo, nhưng nó tính SAU khi CSDL đã tổng hợp — trái yêu cầu "trước khi tổng hợp", và không dùng làm chiều gom nhóm được.

• A (sửa LookML) — nhà phân tích KHÔNG có quyền developer; và với một trường tạm thời cho một báo cáo, sửa LookML là quá nặng.

• D (dùng authorized view trong BigQuery) — là cơ chế bảo mật, không phải cách tạo trường tính toán; và cũng cần quyền mà nhà phân tích không có.

Ghi nhớ

⚠ Ba nơi tính toán trong Looker — bảng phải thuộc: | Nơi | Ai tạo | Tính ở đâu | Dùng làm chiều gom nhóm? | |---|---|---|---| | LookML | Developer | CSDL | CÓ | | Custom Field | người dùng | CSDL | CÓ | | Table Calculation | người dùng | kết quả đã trả về | KHÔNG |

Từ khoá nhận diện:

"người dùng tạo, tính trong CSDL, trước khi tổng hợp" → Custom Field "tính trên kết quả, ví dụ % của tổng" → Table Calculation "chỉ số chính thức toàn công ty" → LookML "không có quyền developer" → loại bỏ phương án LookML "nối hai chiều thành một" → custom dimension

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trường được tính ở đâu | xem SQL sinh ra trong tab SQL | | Kết quả có đúng không | so với truy vấn viết tay | | Có bị giới hạn dòng không | kiểm tra row limit của Look |

Và một cách kiểm tra nhanh mỗi khi phân vân giữa Custom Field và Table Calculation: mở tab SQL trong Explore. Nếu biểu thức xuất hiện trong câu SQL gửi xuống CSDL, đó là Custom Field và bạn dùng nó làm chiều gom nhóm được; nếu không thấy, phép tính đang chạy trên kết quả và sẽ sai khi số dòng bị giới hạn.

Đáp án

C — Công cụ dòng lệnh gcloud storage.

Vì sao đúng

Đề nêu bốn điều: 0,9 GB, một lần duy nhất, từ máy trạm cá nhân, trong một script tự động hoá tuỳ chỉnh, và KHÔNG cần tính năng phức tạp như lịch chạy hay quản lý băng thông. Công cụ dòng lệnh là mức vừa đủ.

⚠ Điểm mấu chốt — khối lượng nhỏ, một lần, trong script:

gcloud storage cp -r ./thu-muc-log \
  gs://bucket/log/
        ↓
    ⚠ Một dòng lệnh
    ⚠ Chạy được ngay trong script
    ⚠ Không dựng gì, không cấu hình gì
        ↓
    0,9 GB qua đường truyền văn phòng
    → vài phút là xong

⚠ Vì sao Storage Transfer Service là quá tay ở đây:

Storage Transfer Service
        ↓
    Sinh ra cho:
      - khối lượng LỚN (TB trở lên)
      - chạy THEO LỊCH, lặp lại
      - cần thử lại tự động, báo cáo
      - nguồn TẠI CHỖ cần AGENT
        ↓
    ⚠ Với 0,9 GB một lần trong script,
      dựng agent pool và job là
      nhiều bước hơn hẳn giá trị mang lại

⚠ gcloud storage — vài cờ đáng biết:

-r                → đệ quy cả thư mục
-m (với gsutil)   → song song; gcloud storage
                    tự song song
--gzip-in-flight  → nén khi truyền
rsync             → đồng bộ, chỉ chép phần khác
        ↓
    ⚠ gcloud storage NHANH HƠN gsutil
      đáng kể — nên dùng cho việc mới

Xem thêm câu #12933 (lô 134): khoá Storage Transfer Service vì 10 TB từ S3, cần dịch vụ được quản lý. #12939 (lô 134): khoá Transfer Appliance vì 500 TB, băng thông không đủ. #13010 (lô 135): STS với agent pool vì nguồn tại chỗ và ràng buộc vùng. Bốn câu, bốn khoá, phân biệt bằng KHỐI LƯỢNG và YÊU CẦU — hoàn toàn nhất quán.

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

• A (Storage Transfer Service) — đây là phương án gần nhất và hoàn toàn làm được, nhưng nó là dịch vụ cho khối lượng lớn, chạy theo lịch, cần agent với nguồn tại chỗ — quá nhiều bước cho một lần chép 0,9 GB.

• B (Transfer Appliance) — thiết bị vật lý cho hàng trăm TB; gửi ổ cứng qua bưu điện cho 0,9 GB là vô lý.

• D (Cloud Storage FUSE) — gắn bucket như một hệ thống tệp để ứng dụng đọc ghi liên tục; không phải công cụ chép một lần.

Ghi nhớ

⚠ Chọn công cụ theo KHỐI LƯỢNG và TẦN SUẤT — bảng phải thuộc: | Tình huống | Công cụ | |---|---| | Vài GB, một lần, trong script | gcloud storage cp / rsync | | TB, từ đám mây khác hoặc tại chỗ, có lịch | Storage Transfer Service | | Hàng trăm TB, băng thông không đủ | Transfer Appliance | | Ứng dụng cần đọc bucket như thư mục | Cloud Storage FUSE | | Nạp vào BigQuery | bq load / LOAD DATA |

Từ khoá nhận diện:

"vài GB, một lần, script tuỳ chỉnh" → gcloud storage "TB, theo lịch, được quản lý" → Storage Transfer Service "băng thông không đủ, hàng trăm TB" → Transfer Appliance "gắn bucket như thư mục" → Cloud Storage FUSE "đồng bộ hai bên" → rsync hoặc STS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã chép đủ chưa | gcloud storage ls -r gs://bucket/log/ \| wc -l | | Dung lượng có khớp không | gcloud storage du -s so với du -sh cục bộ | | Có tệp nào lỗi không | mã thoát và thông báo của lệnh |

Và một nguyên tắc đáng nhớ cho mọi câu hỏi dạng "chọn công cụ chuyển dữ liệu": đọc con số khối lượng trước tiên. Vài GB thì một lệnh CLI là đúng mức; vài TB thì cần dịch vụ được quản lý; vài trăm TB với đường truyền yếu thì mới tới thiết bị vật lý — và chọn sai mức luôn có nghĩa là làm quá nhiều hoặc quá ít.

Đáp án

D — Infrastructure as a Service (IaaS — hạ tầng như một dịch vụ).

Vì sao đúng

Đề nêu hai vế rất rõ: đội muốn TOÀN QUYỀN kiểm soát hệ điều hành (chọn bản phân phối Linux, phiên bản kernel) và mọi phần mềm cài đặt, đồng thời giao phần cứng và mạng cho nhà cung cấp. Đó chính là ranh giới của IaaS.

⚠ Điểm mấu chốt — ai quản lý tới đâu:

IaaS                              ← đề này
    Nhà cung cấp: phần cứng, ảo hoá,
                  mạng vật lý, điện, làm mát
    BẠN: HỆ ĐIỀU HÀNH, runtime,
         phần mềm, ứng dụng, dữ liệu
        ↓
    → Compute Engine

PaaS
    Nhà cung cấp: + hệ điều hành, runtime,
                   mở rộng, vá lỗi
    BẠN: chỉ ứng dụng và dữ liệu
        ↓
    → App Engine, Cloud Run

SaaS
    Nhà cung cấp: TẤT CẢ

⚠ "Chọn bản phân phối Linux và phiên bản kernel" là dấu hiệu quyết định:

Kiểm soát tới mức KERNEL
        ↓
    ⚠ PaaS KHÔNG cho điều này
    → nhà cung cấp quyết định
      hệ điều hành và runtime
        ↓
    → chỉ IaaS mới cho phép

⚠ Cái giá của quyền kiểm soát:

Với IaaS bạn PHẢI tự lo:
    - vá lỗi hệ điều hành
    - cấu hình tường lửa và bảo mật
    - cài và cập nhật phần mềm
    - giám sát, sao lưu
    - tự co giãn (MIG, autoscaling)
        ↓
    ⚠ Đây là đánh đổi có ý thức,
      không phải "tiện thì chọn"

⚠ "Lift and shift" — mẫu chuyển đổi của đề này:

Máy chủ ứng dụng tại trung tâm dữ liệu
        ↓
    Migrate to Virtual Machines
        ↓
    VM trên Compute Engine
        ↓
    → chuyển nhanh, ít rủi ro
    → nhưng KHÔNG tận dụng được
      lợi thế của đám mây ngay
        ↓
    Bước tiếp theo thường là
    "improve and move" → container, PaaS

Xem thêm câu #13058 (cùng lô): khoá PaaS vì ở đó đội KHÔNG muốn quản lý hệ điều hành. Hai câu là hai mặt của cùng một trục — hoàn toàn nhất quán.

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

• A (PaaS) — đây là phương án gần nhất và cũng giao hạ tầng cho nhà cung cấp, nhưng với PaaS bạn KHÔNG chọn được bản phân phối Linux hay phiên bản kernel — nhà cung cấp quản lý tầng đó.

• B (FaaS) — mức trừu tượng cao nhất: bạn chỉ viết hàm, không kiểm soát gì về môi trường.

• C (SaaS) — phần mềm dùng sẵn; không chạy được ứng dụng riêng của công ty.

Ghi nhớ

⚠ Bốn mô hình dịch vụ — bảng phải thuộc: | Mô hình | Bạn quản lý | Ví dụ trên GCP | |---|---|---| | IaaS | hệ điều hành, runtime, ứng dụng, dữ liệu | Compute Engine | | PaaS | ứng dụng và dữ liệu | App Engine, Cloud Run | | FaaS | chỉ hàm | Cloud Run functions | | SaaS | chỉ dữ liệu và cấu hình | Google Workspace | | Mẹo nhớ | càng lên cao, kiểm soát càng ít, việc càng nhẹ |

Từ khoá nhận diện:

"chọn hệ điều hành, kernel, phần mềm hệ thống" → IaaS "chỉ viết mã, không quản hệ điều hành" → PaaS "chỉ một hàm theo sự kiện" → FaaS "dùng phần mềm có sẵn" → SaaS "lift and shift máy chủ" → IaaS / Compute Engine

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VM đang chạy hệ điều hành nào | gcloud compute instances describe <vm> → licenses | | Bản vá có được cập nhật không | VM Manager → OS patch management | | Có thể chuyển sang container không | rà soát phụ thuộc mức hệ điều hành |

Và một câu hỏi đáng đặt ra ngay sau khi hoàn tất "lift and shift": có thật sự cần quyền kiểm soát tới kernel nữa không? Rất nhiều ứng dụng được chuyển lên IaaS vì đó là cách nhanh nhất, rồi ở lại đó nhiều năm — trong khi phần lớn chúng chạy tốt trên Cloud Run và có thể tiết kiệm cả chi phí lẫn công vá lỗi hằng tháng.

Đáp án

A — Firestore.

Vì sao đúng

Đề nêu bốn điều: ứng dụng chat thời gian thực cho web và di động, CSDL không máy chủ, được quản lý, cấu trúc dữ liệu LINH HOẠT, và — quan trọng nhất — tự động ĐẨY cập nhật tới các máy khách đang kết nối. Chỉ Firestore có tính năng cuối.

⚠ Điểm mấu chốt — real-time listener là thứ không CSDL nào khác có:

Firestore
        ↓
    Máy khách ĐĂNG KÝ LẮNG NGHE
    một truy vấn hoặc tài liệu
        ↓
    Có tin nhắn mới được ghi
        ↓
    ⚠ Firestore TỰ ĐẨY thay đổi
      tới MỌI máy khách đang lắng nghe
        ↓
    → không phải polling
    → không phải tự dựng WebSocket
        ↓
    Đúng yêu cầu "tự động đẩy cập nhật"

⚠ Bốn đặc điểm khớp với ứng dụng chat:

1. REAL-TIME LISTENER
    → tin nhắn xuất hiện ngay

2. LƯỢC ĐỒ LINH HOẠT (tài liệu)
    → tin nhắn có thể có ảnh, file,
      emoji, trả lời — cấu trúc khác nhau

3. SDK CHO DI ĐỘNG VÀ WEB
    → Android, iOS, Web, Flutter
    → có CHẾ ĐỘ NGOẠI TUYẾN

4. KHÔNG MÁY CHỦ, TỰ CO GIÃN
    → không quản lý gì

⚠ Chế độ ngoại tuyến — điểm cộng lớn cho ứng dụng chat:

Máy khách mất mạng
        ↓
    SDK Firestore vẫn cho ĐỌC từ
    bộ nhớ đệm cục bộ
    và GHI vào hàng đợi
        ↓
    Có mạng lại
        ↓
    → tự đồng bộ lên máy chủ
        ↓
    ⚠ Người dùng gần như không thấy gián đoạn

Xem thêm câu #13072 (cùng lô): khoá Cloud SQL cho ứng dụng blog quan hệ, thông thường. Và #12563 (lô 133): khoá Spanner cho nhiều Region, nhất quán mạnh. Ba câu, ba khoá, phân biệt bằng MÔ HÌNH DỮ LIỆU và YÊU CẦU — hoàn toàn nhất quán.

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

• D (Spanner) — đây là phương án gần nhất về mặt "CSDL được quản lý, mở rộng tốt", nhưng nó là CSDL QUAN HỆ với lược đồ cố định, không có real-time listener, không có SDK di động với chế độ ngoại tuyến, và chi phí tối thiểu cao hơn nhiều.

• C (Cloud SQL) và B (AlloyDB) — đều là CSDL quan hệ lược đồ cố định, không đẩy cập nhật thời gian thực, và ứng dụng phải tự dựng cơ chế WebSocket.

Ghi nhớ

⚠ Chọn CSDL theo mô hình và yêu cầu — bảng phải thuộc: | Nhu cầu | Dịch vụ | |---|---| | Thời gian thực, di động, lược đồ linh hoạt | Firestore | | Quan hệ, thông thường, một Region | Cloud SQL | | PostgreSQL hiệu năng cao | AlloyDB | | Quan hệ, nhiều Region, nhất quán mạnh | Spanner | | NoSQL ghi cực lớn, chuỗi thời gian | Bigtable | | Phân tích | BigQuery |

Từ khoá nhận diện:

"chat, thông báo, đồng bộ thời gian thực" → Firestore "ứng dụng di động có chế độ ngoại tuyến" → Firestore "giao dịch quan hệ thông thường" → Cloud SQL "toàn cầu + nhất quán mạnh" → Spanner "hàng triệu điểm dữ liệu mỗi giây" → Bigtable

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Security Rules có chặt không | Firestore emulator và bộ kiểm thử rules | | Chi phí đọc bao nhiêu | Firestore usage dashboard | | Chỉ mục có đủ không | lỗi truy vấn thường kèm sẵn link tạo chỉ mục |

Và một khoản chi phí rất dễ vượt dự toán với ứng dụng chat trên Firestore: listener đặt trên một collection quá rộng. Mỗi tài liệu thay đổi trong phạm vi lắng nghe đều tính là một lượt đọc cho từng máy khách — nên hãy lắng nghe đúng phòng chat đang mở, kèm giới hạn số tin nhắn, thay vì lắng nghe toàn bộ lịch sử.

Đáp án

D — Từ 30 phút tới 7 ngày.

Vì sao đúng

Với BigLake table, max_staleness khai mức "cũ" tối đa mà bạn chấp nhận cho bộ nhớ đệm siêu dữ liệu, và BigQuery cho phép đặt trong khoảng 30 phút tới 7 ngày.

⚠ Điểm mấu chốt — đánh đổi giữa TỐC ĐỘ và ĐỘ TƯƠI:

max_staleness NHỎ (gần 30 phút)
        ↓
    → dữ liệu mới xuất hiện nhanh
    → nhưng cache làm mới thường xuyên
      → tốn hơn, ít lợi ích hơn

max_staleness LỚN (gần 7 ngày)
        ↓
    → truy vấn rất nhanh
    → nhưng tệp mới có thể chưa thấy
      trong nhiều ngày
        ↓
    ⚠ Chọn theo TẦN SUẤT dữ liệu mới về

⚠ Cấu hình:

CREATE EXTERNAL TABLE `du_an.lake.su_kien`
WITH CONNECTION `du_an.asia-southeast1.ket-noi`
OPTIONS (
  format = 'PARQUET',
  uris = ['gs://lake/su-kien/*.parquet'],
  max_staleness = INTERVAL 1 HOUR,
  metadata_cache_mode = 'AUTOMATIC'
);

        ↓
    AUTOMATIC → BigQuery tự làm mới
    MANUAL    → bạn gọi
                BQ.REFRESH_EXTERNAL_METADATA_CACHE

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

Data lake có HÀNG TRIỆU tệp
        ↓
    Không có cache
        ↓
    → mỗi truy vấn phải LIỆT KÊ tệp
      và đọc thống kê
    → phần lớn thời gian truy vấn
      dành cho việc này
        ↓
    Có cache
        ↓
    → danh sách tệp và thống kê đã sẵn
    → truy vấn nhanh hơn NHIỀU LẦN

Xem thêm câu #13069 (cùng lô): về BigLake table và các tính năng bảo mật của nó. Câu này đi sâu vào cấu hình hiệu năng. Hai câu bổ sung nhau. Và #12980 (lô 134) cũng về BigLake.

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

• B (từ 1 phút tới 24 giờ) — đây là phương án gần nhất và nghe rất hợp lý, nhưng cận dưới thực tế là 30 phút và cận trên là 7 ngày, không phải 24 giờ.

• A (không cấu hình được, cố định 1 giờ) — sai: max_staleness là tuỳ chọn khai được.

• C (từ 1 ngày tới 30 ngày) — sai cả hai đầu.

Ghi nhớ

⚠ Metadata cache của BigLake — bảng phải thuộc: | Tham số | Nội dung | |---|---| | max_staleness | 30 PHÚT tới 7 NGÀY | | metadata_cache_mode = 'AUTOMATIC' | BigQuery tự làm mới | | metadata_cache_mode = 'MANUAL' | bạn tự gọi làm mới | | Làm mới thủ công | BQ.REFRESH_EXTERNAL_METADATA_CACHE | | Áp dụng cho | BigLake table, và object table | | Lợi ích | tăng tốc truy vấn trên data lake nhiều tệp |

Từ khoá nhận diện:

"cache siêu dữ liệu BigLake" → 30 phút – 7 ngày "tự làm mới" → AUTOMATIC "làm mới ngay sau khi nạp tệp" → MANUAL + gọi thủ tục "truy vấn data lake chậm" → bật metadata caching "external table thường" → không có metadata cache

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cache cấu hình thế nào | bq show --format=prettyjson <bảng> → maxStaleness | | Truy vấn có nhanh hơn không | so thời gian trước và sau khi bật cache | | Dữ liệu có bị cũ không | so MAX(<cột thời gian>) với tệp mới nhất trong bucket |

Và một mẫu rất đáng áp dụng với pipeline theo lô: đặt metadata_cache_mode = 'MANUAL' rồi gọi làm mới ngay sau bước nạp tệp. Cách đó cho bạn cả tốc độ của cache lẫn sự chắc chắn rằng báo cáo chạy ngay sau pipeline sẽ thấy đúng dữ liệu vừa được ghi.

Đáp án

C — Cloud Data Loss Prevention (DLP), nay là Sensitive Data Protection.

Vì sao đúng

Đề nêu bốn điều: quét tự động hàng trăm bucket và bảng BigQuery, tìm PII như email và số điện thoại, phân loại, và sinh báo cáo kết quả. Đó chính là công việc của Sensitive Data Protection.

⚠ Điểm mấu chốt — phát hiện tự động bằng bộ nhận dạng dựng sẵn:

Sensitive Data Protection
        ↓
    Hơn 150 INFOTYPE dựng sẵn:
      EMAIL_ADDRESS
      PHONE_NUMBER
      CREDIT_CARD_NUMBER
      PERSON_NAME
      IP_ADDRESS
      VIETNAM_NATIONAL_ID_NUMBER
      ... và nhiều loại theo quốc gia
        ↓
    Quét CLOUD STORAGE, BIGQUERY, DATASTORE
        ↓
    → báo cáo: cột nào, tệp nào,
      loại PII gì, mức tin cậy bao nhiêu

⚠ Hai chế độ quét:

DISCOVERY (khám phá)
    → quét LIÊN TỤC toàn tổ chức
    → tự lập hồ sơ dữ liệu
    → cảnh báo khi phát hiện PII mới
        ↓
    Hợp với "kiểm toán toàn project"

INSPECTION JOB
    → quét MỘT nguồn cụ thể theo yêu cầu
    → kết quả ghi ra BigQuery hoặc Pub/Sub

⚠ Kết quả dùng để làm gì tiếp:

Báo cáo phát hiện PII
        ↓
    → biết cột nào cần GẮN POLICY TAG
    → biết bucket nào cần siết quyền
    → biết dữ liệu nào cần che hoặc mã hoá
        ↓
    ⚠ Phát hiện là BƯỚC ĐẦU;
      hành động là bước sau

Xem thêm câu #13080 (cùng lô): dùng Dataflow template tích hợp DLP để PHÁT HIỆN VÀ CHE ngay trên đường nạp. Hai câu bổ sung nhau: câu này là kiểm toán tĩnh, câu kia là bảo vệ động. Và #12965 (lô 134): dùng policy tag để chặn cột — hành động sau khi đã phát hiện.

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

• A (Data Catalog / Dataplex) — đây là phương án gần nhất vì cũng lập danh mục dữ liệu toàn tổ chức, nhưng nó không tự quét NỘI DUNG để tìm PII; nó quản lý siêu dữ liệu và policy tag. (Hai dịch vụ làm việc cùng nhau: DLP phát hiện, Catalog gắn tag.)

• B (IAM) — kiểm soát AI được truy cập, không phát hiện dữ liệu nhạy cảm nằm ở đâu.

• D (Cloud KMS) — quản lý khoá mã hoá, không quét nội dung.

Ghi nhớ

⚠ Vòng đời bảo vệ dữ liệu nhạy cảm — bảng phải thuộc: | Bước | Công cụ | |---|---| | PHÁT HIỆN PII ở đâu | Sensitive Data Protection (DLP) | | PHÂN LOẠI mức nhạy cảm | policy tag trong Dataplex Catalog | | CHẶN hoặc CHE | column-level security, dynamic masking | | LỌC DÒNG | row-level security | | MÃ HOÁ trong cột | AEAD | | THEO DÕI truy cập | Data Access audit log |

Từ khoá nhận diện:

"quét tự động tìm PII, phân loại, báo cáo" → Sensitive Data Protection "tìm dữ liệu bằng thuật ngữ nghiệp vụ" → Dataplex Catalog "che PII trên đường nạp" → Dataflow + DLP template "chặn cột nhạy cảm" → policy tag "ai được truy cập" → IAM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quét tìm được gì | kết quả inspection job trong BigQuery | | Cột nào đã gắn tag | bq show --schema --format=prettyjson | | Có nguồn nào chưa quét | cấu hình phạm vi của Discovery |

Và một phát hiện gần như luôn xuất hiện trong lần quét đầu tiên: PII nằm trong các trường văn bản tự do. Số điện thoại trong ô ghi chú, email trong mô tả sản phẩm, tên người trong nội dung phản hồi — đó là những chỗ mà không ai nghĩ tới khi liệt kê "cột nhạy cảm" bằng tay, và cũng là lý do việc quét tự động đáng làm.

Đáp án

D — Một Table Calculation.

Vì sao đúng

Đề nêu điều kiện quyết định: phép tính phải được thực hiện CHỈ TRÊN DỮ LIỆU ĐÃ TRẢ VỀ từ CSDL. Đó chính là định nghĩa của Table Calculation trong Looker.

⚠ Điểm mấu chốt — tính SAU khi CSDL đã trả kết quả:

Looker chạy truy vấn
        ↓
    CSDL trả về: quốc gia + tổng doanh số
        ↓
    TABLE CALCULATION chạy TRÊN kết quả đó
        ↓
    percent_of_total(${doanh_so})
        ↓
    → thêm cột phần trăm
        ↓
    ⚠ KHÔNG có truy vấn thứ hai
    ⚠ KHÔNG đẩy gì xuống CSDL

⚠ Các hàm Table Calculation hay dùng:

percent_of_total(${x})   → phần trăm của tổng
running_total(${x})      → cộng dồn
rank(${x}, ${x})         → xếp hạng
offset(${x}, 1)          → giá trị dòng sau
offset(${x}, -1)         → giá trị dòng trước
${x} / offset(${x}, -1) - 1
                         → tăng trưởng so với kỳ trước
row(), pivot_index()     → vị trí

⚠ ⚠ Cái bẫy lớn nhất — row limit:

Table Calculation tính trên
SỐ DÒNG ĐÃ TRẢ VỀ
        ↓
    Look có row limit = 500
    nhưng thực tế có 2000 quốc gia
        ↓
    ⚠ percent_of_total tính trên tổng
      của 500 dòng, KHÔNG PHẢI tổng thật
        ↓
    → mọi phần trăm đều SAI
        ↓
    Khắc phục:
      - tăng row limit
      - hoặc dùng LOOKML MEASURE
        (tính ở CSDL)

Xem thêm câu #13070 (cùng lô): khoá LookML cho chỉ số chính thức, toàn tổ chức. Và #13073 (cùng lô): khoá Custom Field cho phép tính đẩy xuống CSDL trước khi tổng hợp. Ba câu, ba khoá, phân biệt bằng TÍNH Ở ĐÂU — hoàn toàn nhất quán.

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

• B (Custom Field) — đây là phương án gần nhất vì cũng do người dùng tạo, nhưng Custom Field được ĐẨY XUỐNG CSDL — trái yêu cầu "chỉ tính trên dữ liệu đã trả về".

• A (LookML measure) — cũng tính trong CSDL, và cần quyền developer; quá nặng cho một cột phần trăm trong một báo cáo.

• C (Dynamic Data Masking) — là tính năng bảo mật của BigQuery, hoàn toàn không liên quan tới việc tính toán.

Ghi nhớ

⚠ Ba nơi tính toán trong Looker — bảng tổng kết: | Nơi | Ai tạo | Tính ở đâu | Ví dụ điển hình | |---|---|---|---| | LookML | Developer | CSDL | chỉ số chính thức: ARR, CLV | | Custom Field | người dùng | CSDL | nối hai cột thành full_name | | Table Calculation | người dùng | KẾT QUẢ đã trả về | % của tổng, cộng dồn, xếp hạng |

Từ khoá nhận diện:

"tính trên dữ liệu đã trả về" → Table Calculation "% của tổng, cộng dồn, so với dòng trước" → Table Calculation "tính trong CSDL, trước khi tổng hợp" → Custom Field "chỉ số chính thức, được quản trị" → LookML "che dữ liệu nhạy cảm" → masking — chuyện khác hẳn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phép tính chạy ở đâu | tab SQL — nếu không thấy trong SQL thì là Table Calculation | | Row limit là bao nhiêu | thiết lập của Look | | Tổng có đúng không | so với truy vấn tổng hợp riêng |

Và một phép kiểm tra bắt buộc mỗi khi dùng percent_of_total: so tổng trong báo cáo với tổng thật của toàn bộ dữ liệu. Nếu Look bị giới hạn số dòng, phần trăm sẽ được tính trên một mẫu chứ không phải toàn bộ — và đó là loại sai lệch cho ra những con số trông hoàn toàn hợp lý nhưng cộng lại vẫn đúng 100%, nên rất khó phát hiện.

Đáp án

B — Dùng một Dataflow template tích hợp với Cloud DLP để kiểm tra và khử định danh dữ liệu TRƯỚC KHI ghi vào BigQuery.

Vì sao đúng

Đề nêu bốn điều: tự động phát hiện và che PII, trên đường nạp từ Cloud Storage vào BigQuery, ít mã tuỳ chỉnh nhất, và tự co giãn. Template dựng sẵn kết hợp Dataflow với DLP đáp ứng cả bốn.

⚠ Điểm mấu chốt — Google đã có sẵn template cho đúng việc này:

Template "Data Masking/Tokenization
from Cloud Storage to BigQuery
using Cloud DLP"
        ↓
    Đọc CSV từ Cloud Storage
        ↓
    Gọi DLP API để KIỂM TRA và
    KHỬ ĐỊNH DANH theo template đã khai
        ↓
    Ghi kết quả đã che vào BigQuery
        ↓
    ⚠ Chạy bằng cấu hình, KHÔNG viết mã
    ⚠ Dataflow tự co giãn

⚠ Vì sao phải che TRƯỚC KHI ghi vào BigQuery:

Nếu nạp thô rồi che sau
        ↓
    ⚠ PII ĐÃ NẰM trong kho một khoảng thời gian
    ⚠ Có thể lọt vào bản sao, snapshot,
      time travel
    ⚠ Ai truy vấn trong khoảng đó đều thấy
        ↓
    Che trên đường nạp
        ↓
    → PII KHÔNG BAO GIỜ chạm tới kho
    → dễ giải trình với kiểm toán hơn nhiều

⚠ Cấu hình DLP template — quyết định cách che:

DE-IDENTIFY TEMPLATE khai:
    - infoType nào cần tìm
      (EMAIL_ADDRESS, CREDIT_CARD_NUMBER)
    - hành động: redact / mask /
      tokenize (FPE) / hash
    - ngưỡng tin cậy
        ↓
    ⚠ Template lưu riêng, TÁI SỬ DỤNG
      cho nhiều pipeline

Xem thêm câu #13078 (cùng lô): dùng DLP để QUÉT PHÁT HIỆN PII trong kho hiện có. Câu này dùng DLP để CHE TRÊN ĐƯỜNG NẠP. Hai câu bổ sung nhau: kiểm toán tĩnh và bảo vệ động. Và #12999 (lô 135): cũng dùng Dataflow che PII giữa Pub/Sub và BigQuery.

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

• A (mã hoá tệp CSV bằng Cloud KMS trước khi tải lên) — đây là phương án gần nhất về mặt "bảo vệ dữ liệu", nhưng nó bảo vệ CẢ TỆP; khi giải mã để nạp, PII vẫn nguyên vẹn đi vào BigQuery. Không phát hiện và không che gì.

• C (bật VPC Service Controls) — dựng vành đai chống dữ liệu ra ngoài, nhưng PII vẫn nằm trong BigQuery với đầy đủ giá trị.

• D (cấp BigQuery Data Editor cho service account nạp dữ liệu) — chỉ là cấp quyền để nạp; không liên quan gì tới việc che PII.

Ghi nhớ

⚠ Bảo vệ PII theo vị trí trong luồng — bảng phải thuộc: | Vị trí | Công cụ | |---|---| | Trên đường nạp (trước khi vào kho) | Dataflow + DLP template | | Đã ở trong kho — phát hiện | DLP inspection / discovery | | Đã ở trong kho — che khi đọc | dynamic data masking | | Đã ở trong kho — chặn cột | column-level security | | Trong bảng, dạng bản mã | AEAD | | Chống rò rỉ ra ngoài | VPC Service Controls |

Từ khoá nhận diện:

"che PII trên đường nạp, ít mã" → Dataflow template + DLP "quét tìm PII trong kho" → DLP inspection "che theo vai trò người xem" → dynamic data masking "chặn hẳn cột" → column-level security "mã hoá tệp" → không giải quyết bài toán PII trong dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng đích còn PII không | quét bằng Sensitive Data Protection | | Pipeline có lỗi không | log của job Dataflow | | Chi phí DLP bao nhiêu | billing export, lọc SKU DLP |

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