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

Đáp án

B — Mã hoá khi TRUYỀN (encryption in transit) và mã hoá khi LƯU (encryption at rest).

Vì sao đúng

Chính sách trong đề mô tả hai tình huống: dữ liệu đang được chuyển từ máy người dùng lên bucket, và dữ liệu đang nằm trên đĩa trong trung tâm dữ liệu của Google. Đó là hai trạng thái có tên riêng.

⚠ Điểm mấu chốt — ba trạng thái của dữ liệu:

IN TRANSIT (khi truyền)
        ↓
    Đang đi trên mạng
    → mã hoá bằng TLS
    → MẶC ĐỊNH, tự động

AT REST (khi lưu)
        ↓
    Nằm trên đĩa
    → mã hoá AES-256
    → MẶC ĐỊNH, không tắt được

IN USE (khi đang xử lý)
        ↓
    Đang trong BỘ NHỚ, đang tính toán
    → cần CONFIDENTIAL COMPUTING

⚠ Điều quan trọng nhất — cả hai đều MẶC ĐỊNH BẬT:

Google Cloud mã hoá TỰ ĐỘNG:
    - mọi dữ liệu khi lưu
    - mọi dữ liệu khi truyền qua
      hạ tầng của Google
        ↓
    ⚠ Bạn KHÔNG phải bật gì
    ⚠ Cũng KHÔNG tắt được
        ↓
    → chính sách trong đề được thoả
      NGAY TỪ ĐẦU
        ↓
    Câu hỏi thật sự chỉ còn: AI GIỮ KHOÁ

⚠ Các lớp mã hoá khi truyền:

Người dùng → Google
    → TLS, thường kèm HSTS

Giữa các trung tâm dữ liệu của Google
    → mã hoá tự động

VM → VM trong VPC
    → mã hoá ở tầng hạ tầng

Muốn kiểm soát thêm
    → mTLS, VPN, Interconnect
    → Private Google Access

Xem thêm câu #12927 (lô 133): cùng câu hỏi, cùng khoá — at rest và in transit. Hai câu hoàn toàn nhất quán. Và #13060, #13065 (cùng lô): đi tiếp một bước — ai quản lý khoá.

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

• D (data masking và tokenization) — đây là phương án gần nhất trong nhóm bảo vệ dữ liệu, nhưng cả hai đều là kỹ thuật biến đổi giá trị để che thông tin nhạy cảm, không mô tả trạng thái truyền hay lưu.

• A (firewall và IAM policy) — kiểm soát AI được truy cập, không phải dữ liệu có được mã hoá hay không.

• C (xác thực và uỷ quyền) — cũng về danh tính và quyền, không phải mã hoá.

Ghi nhớ

⚠ Ba trạng thái dữ liệu — bảng phải thuộc: | Trạng thái | Ở đâu | Bảo vệ bằng | |---|---|---| | At rest | trên đĩa | AES-256, MẶC ĐỊNH | | In transit | trên mạng | TLS, MẶC ĐỊNH | | In use | trong bộ nhớ khi xử lý | Confidential Computing | | Hai cái đầu | luôn bật, không tắt được | | Câu hỏi còn lại | ai giữ khoá: GMEK / CMEK / CSEK / EKM |

Từ khoá nhận diện:

"trên đường truyền + trên đĩa" → in transit và at rest "mã hoá cả khi đang xử lý trong RAM" → Confidential VM "ai được truy cập" → IAM — câu hỏi khác "che giá trị nhạy cảm" → masking, tokenization "ai giữ khoá" → GMEK / CMEK / CSEK

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket dùng khoá gì | gcloud storage buckets describe gs://b → defaultKmsKeyName | | Kết nối có dùng TLS không | kiểm tra https:// và HSTS | | Có bucket nào công khai không | Security Command Center |

Và một điều nên nói rõ khi trình bày chính sách này với bộ phận tuân thủ: cả hai yêu cầu đã được đáp ứng ngay từ lúc tạo bucket, không cần dự án nào để triển khai. Công sức nên dồn vào phần thực sự hay gây rò rỉ — quyền truy cập quá rộng và bucket vô tình để công khai — chứ không phải vào việc chứng minh lại một cơ chế vốn luôn bật.

Đáp án

A — Một DATA WAREHOUSE (kho dữ liệu).

Vì sao đúng

Đề mô tả đúng bốn đặc điểm của kho dữ liệu: dữ liệu đã được làm sạch trước, có cấu trúc theo lược đồ rõ ràng, tối ưu cho truy vấn phân tích, và phục vụ báo cáo chính thức của công ty.

⚠ Điểm mấu chốt — data warehouse ↔ data lake:

DATA WAREHOUSE                    ← đề này
    → dữ liệu ĐÃ XỬ LÝ, đã làm sạch
    → LƯỢC ĐỒ rõ ràng, định trước
    → "schema-on-WRITE"
    → tối ưu cho TRUY VẤN PHÂN TÍCH
    → Google Cloud: BIGQUERY

DATA LAKE
    → dữ liệu THÔ, mọi định dạng
    → lược đồ áp KHI ĐỌC
    → "schema-on-READ"
    → linh hoạt, rẻ, nhưng chưa dùng ngay được
    → Google Cloud: CLOUD STORAGE

⚠ Vì sao "nhất quán" đòi hỏi kho dữ liệu:

Báo cáo CHÍNH THỨC của công ty
        ↓
    Mọi người phải ra CÙNG một con số
        ↓
    → cần lược đồ thống nhất
    → cần dữ liệu đã làm sạch, đã loại trùng
    → cần một nguồn sự thật duy nhất
        ↓
    ⚠ Data lake với dữ liệu thô
      không bảo đảm được điều đó

⚠ Kiến trúc hiện đại thường có CẢ HAI:

CLOUD STORAGE (data lake)
    → dữ liệu thô, mọi định dạng
        ↓
    Xử lý và làm sạch
        ↓
BIGQUERY (data warehouse)
    → dữ liệu đã sạch, có cấu trúc
        ↓
    Báo cáo và dashboard
        ↓
    ⚠ "Data lakehouse" = kết hợp cả hai
      → BigLake, Iceberg

Xem thêm câu #13057 (cùng lô): ánh xạ ba loại nhu cầu vào Cloud SQL / Cloud Storage / BigQuery. Và #12940 (lô 134): chọn kho cho dữ liệu có cấu trúc và phi cấu trúc. Ba câu nhất quán.

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

• C (data lake) — đây là phương án gần nhất và cũng lưu dữ liệu quy mô lớn, nhưng nó chứa dữ liệu THÔ, chưa xử lý, chưa có lược đồ chặt — trái yêu cầu "đã làm sạch, có cấu trúc rõ ràng".

• B (CSDL giao dịch) — tối ưu cho giao dịch nhỏ, nhanh (OLTP), không tối ưu cho truy vấn phân tích quét hàng tỉ dòng.

• D (hệ thống lưu trữ đối tượng) — chỉ lưu tệp; không có lược đồ, không truy vấn phân tích trực tiếp hiệu quả.

Ghi nhớ

⚠ Bốn loại hệ thống lưu dữ liệu — bảng phải thuộc: | Loại | Dữ liệu | Ví dụ trên GCP | |---|---|---| | Data warehouse | đã xử lý, có lược đồ, cho PHÂN TÍCH | BigQuery | | Data lake | thô, mọi định dạng, schema-on-read | Cloud Storage | | CSDL giao dịch (OLTP) | có cấu trúc, cho ứng dụng | Cloud SQL, Spanner | | Kho đối tượng | tệp phi cấu trúc | Cloud Storage | | Data lakehouse | kết hợp lake và warehouse | BigLake, Iceberg |

Từ khoá nhận diện:

"đã làm sạch, có lược đồ, cho phân tích" → data warehouse (BigQuery) "dữ liệu thô, mọi định dạng" → data lake (Cloud Storage) "giao dịch, đọc ghi từng dòng" → CSDL giao dịch "ảnh, video, tệp" → kho đối tượng "truy vấn tại chỗ trên data lake, có bảo mật" → BigLake

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Báo cáo đọc tầng nào | rà soát nguồn dữ liệu của dashboard | | Lược đồ có ổn định không | bq show --schema và lịch sử thay đổi | | Số liệu có nhất quán không | đối chiếu hai báo cáo cùng chỉ số |

Và một điều quyết định kho dữ liệu có thật sự mang lại "sự nhất quán" hay không: báo cáo chính thức phải đọc từ tầng đã được kiểm duyệt, không đọc thẳng bảng thô. Khi ai cũng được tự viết truy vấn trên bảng staging, bạn có một kho dữ liệu về mặt kỹ thuật nhưng vẫn có nhiều con số khác nhau cho cùng một chỉ số.

Đáp án

B — Nạp tệp THẲNG vào BigQuery, vì BigQuery hỗ trợ sẵn cấu trúc lồng nhau trong newline-delimited JSON.

Vì sao đúng

BigQuery hiểu trực tiếp JSON lồng nhau: nó ánh xạ đối tượng lồng thành STRUCT và mảng thành ARRAY, giữ nguyên cấu trúc mà không cần bước trung gian nào.

⚠ Điểm mấu chốt — cấu trúc lồng được giữ nguyên:

{"id": 1, "khach": {"ten": "An", "tp": "Ha Noi"},
 "don_hang": [{"ma": "A1", "tien": 250000},
              {"ma": "A2", "tien": 480000}]}

        ↓
    bq load --source_format=NEWLINE_DELIMITED_JSON \
      --autodetect du_an.bang gs://bucket/du-lieu.json
        ↓
    Lược đồ sinh ra:
      id            INTEGER
      khach         RECORD (STRUCT)
        khach.ten     STRING
        khach.tp      STRING
      don_hang      RECORD REPEATED (ARRAY<STRUCT>)
        don_hang.ma    STRING
        don_hang.tien  INTEGER

⚠ Truy vấn dữ liệu lồng — dùng UNNEST:

SELECT
  t.id,
  t.khach.ten,
  d.ma,
  d.tien
FROM `du_an.bang` AS t,
UNNEST(t.don_hang) AS d;

        ↓
    ⚠ UNNEST trải mảng thành DÒNG
    → mỗi đơn hàng một dòng

⚠ Vì sao "làm phẳng thành CSV" là phương án tệ nhất:

Làm phẳng JSON lồng thành CSV
        ↓
    ⚠ MẤT cấu trúc quan hệ cha–con
    ⚠ Hoặc phải LẶP dữ liệu cha
      cho mỗi phần tử mảng
    ⚠ Thêm một bước xử lý phải bảo trì
    ⚠ CSV không có kiểu dữ liệu
        ↓
    → tự tạo ra vấn đề rồi tự giải

Xem thêm câu #12960 (lô 134): nhận dạng định dạng JSON. Câu này về cách NẠP JSON lồng vào BigQuery. Hai câu bổ sung nhau. Và #12959 (lô 134), #13064 (cùng lô) về các cách nạp khác.

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

• A (dùng Data Fusion hoặc Dataflow để dựng lại lược đồ lồng trước khi nạp) — đây là phương án gần nhất và chạy được, nhưng hoàn toàn không cần thiết: BigQuery đã hỗ trợ sẵn, thêm engine chỉ thêm chi phí và độ phức tạp.

• D (làm phẳng thành CSV rồi nạp) — mất cấu trúc, mất kiểu dữ liệu, và thêm một bước phải bảo trì.

• C (viết Cloud Function chèn từng dòng) — cực kỳ chậm và tốn kém với tệp lớn; streaming insert từng dòng đắt hơn nhiều so với nạp theo lô.

Ghi nhớ

⚠ Kiểu dữ liệu lồng của BigQuery — bảng phải thuộc: | Kiểu | Nội dung | |---|---| | STRUCT (RECORD) | nhóm các trường liên quan — đối tượng JSON lồng | | ARRAY (REPEATED) | nhiều giá trị trong một dòng — mảng JSON | | ARRAY<STRUCT> | mảng đối tượng — mẫu phổ biến nhất | | UNNEST | trải mảng thành DÒNG | | Kiểu JSON gốc | giữ nguyên JSON, lược đồ động |

Từ khoá nhận diện:

"NDJSON lồng nhau vào BigQuery" → nạp thẳng, giữ nguyên cấu trúc "truy vấn mảng" → UNNEST "lược đồ hay thay đổi" → kiểu JSON gốc "làm phẳng thành CSV" → thường là phương án SAI "chèn từng dòng bằng hàm" → chậm và đắt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lược đồ có giữ cấu trúc không | bq show --schema --format=prettyjson — tìm RECORD, REPEATED | | Truy vấn mảng có ra đúng không | thử UNNEST trên vài dòng | | Có trường nào bị bỏ sót không | so danh sách khoá trong tệp với lược đồ |

Và một cạm bẫy rất hay gặp khi nạp NDJSON lần đầu: tệp thực ra là một mảng JSON lớn chứ không phải NDJSON. Trình nạp báo lỗi phân tích cú pháp ngay dòng đầu tiên, và thông báo nghe như tệp bị hỏng — trong khi tệp hoàn toàn hợp lệ, chỉ là ở dạng mà BigQuery không nhận.

Đáp án

A — Câu lệnh LOAD DATA.

Vì sao đúng

Đề hỏi rõ: lệnh SQL dùng để nạp tệp từ Cloud Storage vào bảng BigQuery đã có, trong một script tự động. LOAD DATA là câu lệnh SQL được thiết kế cho đúng việc đó.

⚠ Điểm mấu chốt — cú pháp:

LOAD DATA INTO `du_an.bang_hien_co`
FROM FILES (
  format = 'CSV',
  uris = ['gs://bucket/du-lieu-*.csv'],
  skip_leading_rows = 1
);

        ↓
    ⚠ Là một câu SQL → chạy được ở
      MỌI NƠI chạy được SQL:
        - bq query
        - thư viện client
        - SCHEDULED QUERY
        - stored procedure

⚠ Vì sao LOAD DATA hợp với script hơn là bq load:

bq load
    → lệnh CLI, cần cài gcloud SDK

LOAD DATA
    → câu SQL, gọi qua API BigQuery
        ↓
    → dùng được trong stored procedure
    → dùng được trong scheduled query
    → gộp chung với các bước SQL khác
      trong CÙNG một script
        ↓
    ⚠ Cả hai đều đúng về mặt kỹ thuật,
      nhưng đề hỏi "câu lệnh SQL"

⚠ Ba biến thể đáng nhớ:

LOAD DATA INTO      → NỐI THÊM vào bảng
LOAD DATA OVERWRITE → GHI ĐÈ toàn bộ bảng
LOAD DATA INTO ... PARTITIONS(...)
                    → ghi đè MỘT phân vùng
        ↓
    ⚠ Biến thể thứ ba rất hữu ích:
      nạp lại đúng một ngày mà không
      đụng tới các ngày khác

Xem thêm câu #12911 (lô 133): khoá bq load vì đề hỏi công cụ DÒNG LỆNH. Và #12959 (lô 134): khoá luồng giao diện Create Table vì đề hỏi thao tác trên web UI. Ba câu, ba khoá, phân biệt bằng ngữ cảnh sử dụng — hoàn toàn nhất quán.

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

• C (tạo external table) — đây là phương án gần nhất về mặt "làm dữ liệu GCS truy vấn được", nhưng external table KHÔNG nạp dữ liệu vào bảng: nó chỉ trỏ tới tệp, truy vấn chậm hơn và không phải "nạp vào bảng đã có".

• B (gcloud storage cp) — không phải lệnh SQL, và nó chỉ sao chép tệp giữa các nơi, không đưa gì vào BigQuery.

• D (nút 'Create table' trên giao diện) — thao tác thủ công, không dùng được trong script tự động.

Ghi nhớ

⚠ Các cách nạp dữ liệu vào BigQuery — bảng phải thuộc: | Cách | Ngữ cảnh | |---|---| | LOAD DATA (SQL) | script, scheduled query, stored procedure | | bq load (CLI) | script shell, dòng lệnh | | Giao diện Create Table | thao tác một lần | | Thư viện client | trong ứng dụng | | Storage Write API | nạp luồng, thời gian thực | | BigQuery Data Transfer Service | nạp theo LỊCH từ nguồn định sẵn | | External table | truy vấn tại chỗ, KHÔNG nạp |

Từ khoá nhận diện:

"câu lệnh SQL để nạp" → LOAD DATA "dòng lệnh" → bq load "giao diện web" → Create Table "nạp theo lịch, không cần mã" → Data Transfer Service "truy vấn mà không nạp" → external table / BigLake

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng đã có dữ liệu mới chưa | SELECT COUNT(*) trước và sau | | Job nạp có lỗi gì | bq show -j <job_id> | | Kiểu cột có đúng không | bq show --schema --format=prettyjson |

Và một biến thể của LOAD DATA rất đáng dùng cho pipeline hằng đêm: LOAD DATA OVERWRITE ... PARTITIONS(...). Nó ghi đè đúng phân vùng của ngày đang xử lý, nên chạy lại một ngày bị lỗi là an toàn tuyệt đối — không sinh dữ liệu trùng và không đụng tới các ngày khác.

Đáp án

B — CSEK (Customer-Supplied Encryption Keys — khoá do khách hàng tự cung cấp).

Vì sao đúng

Yêu cầu tuyệt đối trong đề là: khoá phải được tạo, lưu và quản lý HOÀN TOÀN trong HSM tại chỗ của công ty, NGOÀI hạ tầng Google Cloud. Trong bốn phương án, chỉ CSEK giữ khoá ở ngoài.

⚠ Điểm mấu chốt — khoá không bao giờ được Google lưu:

CSEK
        ↓
    Bạn tạo khoá trong HSM của mình
        ↓
    Gửi khoá KÈM THEO MỖI YÊU CẦU
    (trong header của lời gọi API)
        ↓
    Google dùng khoá đó để mã hoá/giải mã
        ↓
    ⚠ Google KHÔNG LƯU khoá
    ⚠ Chỉ giữ một mã băm để xác minh
        ↓
    → khoá luôn ở trong hạ tầng của bạn

⚠ Vì sao CMEK KHÔNG đủ ở đây:

CMEK
        ↓
    Khoá do BẠN quản lý — nhưng
    NẰM TRONG CLOUD KMS
        ↓
    ⚠ Cloud KMS là hạ tầng của GOOGLE
        ↓
    → vi phạm yêu cầu "hoàn toàn ngoài
      hạ tầng Google Cloud"
        ↓
    (Cloud EKM giữ khoá ở hệ thống ngoài,
     nhưng không có trong phương án)

⚠ Cái giá rất lớn của CSEK:

- Phải gửi khoá TRONG MỖI yêu cầu API
- MẤT KHOÁ = MẤT DỮ LIỆU VĨNH VIỄN,
  Google không khôi phục được
- Chỉ MỘT SỐ dịch vụ hỗ trợ
  (Cloud Storage, Compute Engine)
  → BigQuery KHÔNG hỗ trợ CSEK
- Ứng dụng phức tạp hơn nhiều
- Không dùng được nhiều tính năng
  tích hợp sẵn

Xem thêm câu #13060 (cùng lô): khoá CMEK vì ở đó yêu cầu là quản lý khoá trong Cloud KMS và trong suốt với người dùng. #12984 (lô 135): khoá GMEK vì không muốn cấu hình gì. Ba câu, ba mức kiểm soát — hoàn toàn nhất quán.

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

• A (CMEK) — đây là phương án gần nhất và cho mức kiểm soát cao, nhưng khoá nằm trong Cloud KMS, tức là trong hạ tầng Google — vi phạm yêu cầu "hoàn toàn bên ngoài".

• C (mã hoá mặc định) — Google quản lý toàn bộ khoá; ngược hẳn yêu cầu.

• D (quyền IAM) — kiểm soát ai được truy cập, hoàn toàn không liên quan tới việc quản lý khoá mã hoá.

Ghi nhớ

⚠ Bốn mức quản lý khoá — bảng phải thuộc: | Mức | Khoá nằm ở đâu | Google có lưu khoá không | |---|---|---| | GMEK | hệ thống của Google | có | | CMEK | Cloud KMS (của Google) | có, nhưng bạn kiểm soát | | Cloud EKM | hệ thống đối tác NGOÀI GCP | không | | CSEK | HSM/hệ thống của bạn | KHÔNG — gửi theo từng yêu cầu | | Mức kiểm soát tăng dần | GMEK → CMEK → EKM → CSEK |

Từ khoá nhận diện:

"khoá hoàn toàn ngoài Google Cloud, tự cung cấp" → CSEK "khoá ở hệ thống ngoài nhưng vẫn trong suốt" → Cloud EKM "tự quản khoá bằng Cloud KMS" → CMEK "không cấu hình gì" → GMEK "phải gọi hàm giải mã trong SQL" → AEAD

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đối tượng dùng khoá nào | gsutil stat gs://b/obj → dòng về CSEK/KMS | | Dịch vụ có hỗ trợ CSEK không | kiểm tra tài liệu từng dịch vụ | | Có kế hoạch khôi phục khoá chưa | quy trình sao lưu khoá trong HSM |

Và một điều nên đặt lên bàn cân trước khi chọn CSEK để đáp ứng quy định: Cloud EKM thường thoả cùng yêu cầu mà rẻ hơn nhiều về vận hành. Nó giữ khoá ở hệ thống ngoài Google, nhưng vẫn trong suốt với ứng dụng và hỗ trợ nhiều dịch vụ hơn — trong khi CSEK buộc mọi lời gọi API phải mang theo khoá và loại bỏ phần lớn tính năng tích hợp sẵn.

Đáp án

A — AlloyDB.

Vì sao đúng

Đề nêu bốn điều: đang dùng PostgreSQL, gặp nút thắt hiệu năng, cần tương thích PostgreSQL 100%, và cần hiệu năng, sẵn sàng, khả năng mở rộng cao hơn hẳn cho khối lượng công việc OLTP đòi hỏi. AlloyDB được thiết kế cho đúng khoảng trống đó.

⚠ Điểm mấu chốt — AlloyDB nằm giữa Cloud SQL và Spanner:

CLOUD SQL for PostgreSQL
    → PostgreSQL tiêu chuẩn được quản lý
    → mặc định tốt cho hầu hết ứng dụng
    → mở rộng theo chiều DỌC

ALLOYDB                          ← đề này
    → 100% tương thích PostgreSQL
    → hiệu năng giao dịch cao hơn nhiều
    → phân tích nhanh hơn RẤT nhiều
      nhờ COLUMNAR ENGINE
    → mở rộng đọc bằng nhiều read pool

SPANNER
    → KHÔNG phải PostgreSQL thuần
      (có giao diện tương thích)
    → nhiều Region, nhất quán mạnh toàn cầu

⚠ Điều làm AlloyDB nhanh hơn:

- Tách lưu trữ khỏi tính toán
  → lớp lưu trữ thông minh, phân tán
- COLUMNAR ENGINE trong bộ nhớ
  → truy vấn phân tích nhanh hơn
    nhiều lần so với PostgreSQL thường
- Tự động phân tầng bộ nhớ đệm
- Read pool mở rộng ngang cho ĐỌC
- Bảo trì không gián đoạn

⚠ Vì sao "tương thích 100%" lại quan trọng:

Ứng dụng PostgreSQL hiện có
        ↓
    Chuyển sang AlloyDB
        ↓
    → giữ nguyên SQL, extension,
      driver, công cụ
    → thường chỉ đổi CHUỖI KẾT NỐI
        ↓
    ⚠ Chuyển sang một CSDL khác hẳn
      sẽ phải viết lại truy vấn và
      kiểm thử lại toàn bộ

Xem thêm câu #12914 (lô 133) và #13072 (cùng lô): khoá Cloud SQL vì ở đó là ứng dụng thông thường, không nêu vấn đề hiệu năng. Và #12563 (lô 133): khoá Spanner vì cần nhiều Region, nhất quán mọi lúc. Bốn câu, ba khoá, phân biệt bằng YÊU CẦU cụ thể — hoàn toàn nhất quán.

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

• D (Cloud SQL for PostgreSQL) — đây là phương án gần nhất và cũng là PostgreSQL được quản lý, nhưng công ty đang gặp nút thắt hiệu năng; chuyển sang cùng một mức dịch vụ không giải quyết được vấn đề.

• C (Spanner) — cho quy mô toàn cầu và nhất quán mạnh, nhưng không phải PostgreSQL thuần: cần chỉnh lược đồ và truy vấn, và chi phí tối thiểu cao hơn nhiều.

• B (Firestore) — NoSQL dạng tài liệu, mô hình dữ liệu khác hẳn; không phải CSDL quan hệ.

Ghi nhớ

⚠ Bốn CSDL quan hệ của Google Cloud — 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, vẫn một Region | | 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ự cân nhắc | Cloud SQL → AlloyDB → Spanner khi quy mô tăng |

Từ khoá nhận diện:

"PostgreSQL nhưng cần hiệu năng cao hơn" → AlloyDB "MySQL/PostgreSQL thông thường" → Cloud SQL "nhiều Region + nhất quán mọi lúc" → Spanner "NoSQL tài liệu, thời gian thực" → Firestore "phân tích hàng tỉ dòng" → BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nút thắt thật sự ở đâu | pg_stat_statements, chỉ số CPU và I/O | | Columnar engine có được dùng không | xem query plan | | Chi phí so với Cloud SQL | Pricing Calculator với cấu hình thật |

Và một bước nên làm trước khi chuyển sang AlloyDB vì lý do hiệu năng: xác định nút thắt thật sự nằm ở đâu. Rất nhiều "vấn đề hiệu năng PostgreSQL" thực ra là thiếu chỉ mục, truy vấn N+1, hoặc kết nối không dùng pool — và những thứ đó sẽ theo bạn sang bất kỳ CSDL mới nào, dù nó nhanh tới đâu.

Đáp án

D — Chuyển dữ liệu thô thành trạng thái CÓ CẤU TRÚC, NHẤT QUÁN và HỮU DỤNG, đáp ứng yêu cầu phân tích.

Vì sao đúng

Đây là định nghĩa của bước "Transform" trong cả ETL lẫn ELT: nó biến dữ liệu ở dạng nguồn thành dạng dùng được cho phân tích.

⚠ Điểm mấu chốt — biến đổi làm gì cụ thể:

CHUẨN HOÁ
    "US", "USA", "United States" → "US"

LÀM SẠCH
    bỏ khoảng trắng thừa, sửa lỗi định dạng

ÉP KIỂU
    chuỗi "2026-09-02" → DATE

LOẠI TRÙNG
    giữ bản ghi mới nhất cho mỗi khoá

LÀM GIÀU
    nối với dữ liệu từ nguồn khác

TỔNG HỢP
    gộp theo ngày, theo vùng

ĐỊNH HÌNH LẠI
    phi chuẩn hoá cho truy vấn nhanh

⚠ Vì sao ba phương án kia mô tả bước KHÁC:

"di chuyển dữ liệu thô nhanh nhất có thể"
    → mô tả bước EXTRACT và LOAD

"kiểm soát ai được truy cập dữ liệu"
    → mô tả QUẢN TRỊ và BẢO MẬT
    → IAM, policy tag, row-level security

"lưu dữ liệu ở dạng gốc trong data lake"
    → mô tả tầng RAW của data lake
    → chính là thứ chưa được biến đổi

⚠ Transform ở đâu — khác nhau giữa ETL và ELT:

ETL: Transform TRƯỚC khi nạp
    → chạy trên Dataflow, Data Fusion
    → chỉ dữ liệu sạch vào kho

ELT: Transform SAU khi nạp
    → chạy bằng SQL trong BigQuery
    → giữ được dữ liệu thô
        ↓
    ⚠ MỤC TIÊU của bước Transform
      là GIỐNG NHAU trong cả hai

Xem thêm câu #12953 (lô 134): nhận diện việc chuẩn hoá mã quốc gia là biến đổi dữ liệu. Và #12943 (lô 134): phân biệt với đánh giá chất lượng — bước phát hiện vấn đề chứ không sửa. Ba câu nhất quán.

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

• A (di chuyển dữ liệu thô từ nguồn tới đích nhanh nhất) — đây là phương án gần nhất về mặt "cũng là một bước của pipeline", nhưng nó mô tả Extract và Load, không phải Transform.

• C (lưu dữ liệu ở dạng gốc trong data lake) — mô tả tầng RAW, tức là dữ liệu chưa được biến đổi.

• B (kiểm soát ai được truy cập dữ liệu đã xử lý) — mô tả quản trị và bảo mật, một khía cạnh hoàn toàn khác.

Ghi nhớ

⚠ Các bước của pipeline dữ liệu — bảng phải thuộc: | Bước | Mục tiêu | |---|---| | Extract | lấy dữ liệu ra khỏi nguồn | | Load | đưa dữ liệu vào đích | | Transform | biến dữ liệu thô thành dạng DÙNG ĐƯỢC | | Assess quality | PHÁT HIỆN vấn đề — không sửa | | Orchestrate | quản lý thứ tự và phụ thuộc | | Govern | quyền, phân loại, dòng dõi |

Từ khoá nhận diện:

"biến dữ liệu thô thành dạng dùng được" → Transform "lấy ra / đưa vào" → Extract / Load "kiểm tra rỗng, đúng định dạng" → đánh giá chất lượng "ai được truy cập" → quản trị, IAM "lưu nguyên dạng gốc" → tầng raw của data lake

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 | | Kết quả có lặp lại được không | chạy lại và so kết quả | | Còn giá trị bất thường không | thống kê phân phối từng cột |

Và một phép kiểm chứng nên gắn vào mọi bước biến đổi ngay từ khi viết: so số dòng trước và sau. Một phép JOIN nhân bản dòng hay một điều kiện lọc quá rộng đều cho ra bảng trông hoàn toàn bình thường — và số dòng là tín hiệu rẻ nhất, nhanh nhất để phát hiện cả hai.

Đáp án

A — Analytics Hub (cơ chế chia sẻ của BigQuery).

Vì sao đúng

Đề nêu bốn yêu cầu: nền tảng TẬP TRUNG, các phòng ban KHÁM PHÁ và ĐĂNG KÝ dataset, chỉ đọc để phân tích, và KHÔNG sao chép hay di chuyển dữ liệu khỏi project của đội phân tích. Analytics Hub được thiết kế cho đúng bộ yêu cầu này.

⚠ Điểm mấu chốt — chia sẻ bằng CON TRỎ, không phải bản sao:

Đội phân tích tạo LISTING trong EXCHANGE
        ↓
    Phòng ban khác ĐĂNG KÝ
        ↓
    Nhận LINKED DATASET trong project họ
        ↓
    ⚠ Linked dataset chỉ là CON TRỎ
    → dữ liệu vẫn nằm ở MỘT chỗ duy nhất
    → cập nhật ở nguồn là thấy ngay
    → THU HỒI được bất cứ lúc nào

⚠ Ba khái niệm của Analytics Hub:

EXCHANGE (sàn trao đổi)
    → nơi chứa các listing
    → riêng cho tổ chức, hoặc công khai

LISTING (mục chia sẻ)
    → một dataset được công bố
    → kèm mô tả, tài liệu, điều kiện dùng

SUBSCRIPTION (đăng ký)
    → bên nhận đăng ký
    → sinh ra LINKED DATASET

⚠ Ai trả tiền cho gì — điểm rất hợp lý:

ĐỘI PHÂN TÍCH (bên chia sẻ)
    → trả phí LƯU TRỮ dữ liệu

PHÒNG BAN (bên đăng ký)
    → trả phí TRUY VẤN của chính họ
        ↓
    ⚠ Chia sẻ KHÔNG làm tăng chi phí
      truy vấn của bên cung cấp
    → mô hình rất phù hợp cho
      chia sẻ nội bộ giữa các phòng ban

Xem thêm câu #12945 (lô 134): cùng tình huống chia sẻ dataset không sao chép, cùng khoá Analytics Hub. Hai câu hoàn toàn nhất quán.

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

• D (IAM) — đây là phương án gần nhất và về kỹ thuật thì cấp quyền đọc dataset cho phòng ban khác là làm được, nhưng IAM không có danh mục để khám phá, không có cơ chế ĐĂNG KÝ, không theo dõi được mức sử dụng. Analytics Hub dùng IAM bên dưới và bổ sung lớp quản trị đó.

• C (Data Catalog / Dataplex) — giúp TÌM KIẾM và mô tả dữ liệu, nhưng không cấp quyền truy cập hay tạo linked dataset.

• B (BigQuery Data Transfer Service) — SAO CHÉP dữ liệu theo lịch — đúng thứ đề muốn tránh.

Ghi nhớ

⚠ Các cách chia sẻ dữ liệu BigQuery — bảng phải thuộc: | Cách | Dùng khi | |---|---| | Analytics Hub | chia sẻ có QUẢN TRỊ, không sao chép, theo dõi được | | IAM trên dataset | chia sẻ đơn giản trong nội bộ | | Authorized view | chỉ lộ MỘT PHẦN dữ liệu | | Dataset copy (BQDTS) | khi bên nhận cần bản sao riêng | | bq extract sang GCS | bên nhận không dùng BigQuery | | Row/column-level security | giới hạn theo dòng và cột |

Từ khoá nhận diện:

"chia sẻ không sao chép, có đăng ký và theo dõi" → Analytics Hub "tìm kiếm dữ liệu bằng thuật ngữ nghiệp vụ" → Dataplex Catalog "chỉ cho xem vài cột" → authorized view / policy tag "bên nhận cần bản sao riêng" → dataset copy "sao chép theo lịch" → Data Transfer Service — trái yêu cầu ở đây

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đang đăng ký | console → Analytics Hub → listing → Subscriptions | | Họ truy vấn bao nhiêu | số liệu của Hub, và INFORMATION_SCHEMA.JOBS | | Listing có lộ cột nhạy cảm không | kiểm tra policy tag và định nghĩa view |

Và một chi tiết khiến Analytics Hub khác biệt hẳn so với việc cấp quyền IAM trực tiếp: bạn biết ai đang dùng dữ liệu của mình. Với IAM, một dataset chia sẻ cho năm phòng ban là năm dòng trong chính sách và không có gì hơn; với Analytics Hub, bạn thấy ai đăng ký, ai truy vấn bao nhiêu — và đó là thông tin cần để quyết định có nên tiếp tục duy trì dataset đó hay không.

Đáp án

B — BigLake table.

Vì sao đúng

Đề nêu ba yêu cầu: truy vấn dữ liệu TẠI CHỖ trong Cloud Storage, cần row-level VÀ column-level security, và cưỡng chế qua IAM của BigQuery, KHÔNG phải quản lý quyền riêng trên tệp gốc. BigLake là loại bảng duy nhất làm được cả ba.

⚠ Điểm mấu chốt — BigLake tách quyền dữ liệu khỏi quyền tệp:

EXTERNAL TABLE thường
        ↓
    Người dùng phải có quyền TRÊN BUCKET
        ↓
    ⚠ tức là họ đọc thẳng tệp được
    ⚠ KHÔNG hỗ trợ row/column-level security
        ↓
    → phải quản lý quyền ở HAI nơi

BIGLAKE TABLE                    ← đề này
        ↓
    Truy cập qua CONNECTION có
    service account riêng
        ↓
    ⚠ Người dùng KHÔNG cần quyền trên bucket
    ⚠ CÓ row-level security
    ⚠ CÓ column-level security (policy tag)
    ⚠ CÓ dynamic data masking
        ↓
    → BigQuery thành CỬA DUY NHẤT vào data lake

⚠ Cách dựng:

-- 1. Tạo connection; cấp cho service account của nó
--    roles/storage.objectViewer trên bucket

-- 2. Tạo BigLake table
CREATE EXTERNAL TABLE `du_an.lake.giao_dich`
WITH CONNECTION `du_an.asia-southeast1.ket-noi-gcs`
OPTIONS (
  format = 'PARQUET',
  uris = ['gs://data-lake/giao-dich/*.parquet'],
  max_staleness = INTERVAL 1 HOUR,
  metadata_cache_mode = 'AUTOMATIC'
);

-- 3. Gắn policy tag vào cột nhạy cảm
-- 4. Tạo row access policy nếu cần lọc dòng

⚠ Lợi ích về hiệu năng — metadata caching:

Data lake có hàng triệu tệp
        ↓
    External table thường phải LIỆT KÊ
    tệp mỗi lần truy vấn
        ↓
    ⚠ rất chậm

BigLake với metadata cache
        ↓
    → cache danh sách tệp và thống kê
    → truy vấn nhanh hơn NHIỀU LẦN

Xem thêm câu #12980 (lô 134): cùng tình huống data lake cần quản trị và che cột, cùng khoá BigLake + policy tag. Hai câu hoàn toàn nhất quán. Và #13077 (cùng lô) về cấu hình metadata cache của chính BigLake.

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

• D (external table thường) — đây là phương án gần nhất vì cũng truy vấn tại chỗ, nhưng nó KHÔNG hỗ trợ row-level và column-level security, và đòi người dùng có quyền trên bucket — đúng hai điều đề loại bỏ.

• A (bảng quản lý của BigQuery) — đòi NẠP dữ liệu vào BigQuery, trái yêu cầu "truy vấn tại chỗ".

• C (BigQuery Data Transfer Service) — sao chép dữ liệu theo lịch, không phải cơ chế truy vấn tại chỗ.

Ghi nhớ

⚠ Bốn loại bảng của BigQuery — bảng phải thuộc: | Loại | Dữ liệu ở đâu | Bảo mật chi tiết | |---|---|---| | Managed table | trong BigQuery | đầy đủ | | BigLake table | trong GCS/S3/Azure | ĐẦY ĐỦ | | External table thường | trong GCS | KHÔNG có | | Object table | tệp phi cấu trúc trong GCS | có, qua connection | | Hiệu năng | managed > BigLake > external |

Từ khoá nhận diện:

"data lake + row/column-level security + IAM của BigQuery" → BigLake "truy vấn tại chỗ, không cần bảo mật chi tiết" → external table "hiệu năng tốt nhất" → nạp vào bảng quản lý "ảnh, video trong GCS" → object table "cần quyền trên bucket" → dấu hiệu của external table thường

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng có phải BigLake không | bq show --format=prettyjson → có connectionId | | Cột nào mang policy tag | bq show --schema --format=prettyjson | | Người dùng có đọc được bucket không | không nên — kiểm tra IAM của bucket |

Và một bước cần làm để BigLake thật sự phát huy tác dụng: gỡ quyền trực tiếp trên bucket của người dùng cuối. Nếu họ vẫn có storage.objectViewer trên bucket gốc, mọi chính sách row-level và column-level đều bị bỏ qua chỉ bằng cách đọc thẳng tệp — và bảng BigLake khi đó chỉ là một lớp trang trí.

Đáp án

D — Nhờ một Looker Developer thêm trường đó vào LookML của dự án.

Vì sao đúng

Đề nêu ba yêu cầu: chỉ số phải VĨNH VIỄN, ĐƯỢC QUẢN TRỊ, và mọi người dùng đều dùng ĐÚNG một logic. Chỉ LookML — lớp mô hình tập trung — cho cả ba.

⚠ Điểm mấu chốt — ba nơi định nghĩa phép tính trong Looker:

LOOKML MEASURE                    ← đề này
    → do DEVELOPER viết
    → lưu trong GIT, có review
    → dùng cho TOÀN BỘ tổ chức
    → VĨNH VIỄN và ĐƯỢC QUẢN TRỊ

CUSTOM FIELD
    → do NGƯỜI DÙNG tạo trong Explore
    → tính TRONG CSDL (đẩy vào SQL)
    → tạm thời, thuộc về một Look

TABLE CALCULATION
    → do NGƯỜI DÙNG tạo
    → tính TRÊN KẾT QUẢ đã trả về
    → không đẩy xuống CSDL

⚠ Định nghĩa trong LookML:

measure: customer_lifetime_value {
  type: number
  sql: SUM(${orders.amount}) /
       NULLIF(COUNT(DISTINCT ${users.id}), 0) ;;
  value_format_name: usd
  description: "CLV = tổng doanh thu / số khách duy nhất"
}

        ↓
    ⚠ Mọi dashboard, mọi Look, mọi người
      đều lấy TỪ ĐÂY
    → không còn hai con số CLV khác nhau

⚠ Vì sao đây là "được quản trị":

LookML lưu trong GIT
        ↓
    - Đổi định nghĩa phải qua PULL REQUEST
    - Có người review
    - Có lịch sử thay đổi
    - Quay lui được
    - Có môi trường dev tách production
        ↓
    ⚠ Custom Field và Table Calculation
      KHÔNG có gì trong số này

Xem thêm câu #13073 và #13079 (cùng lô): khoá lần lượt là Custom Field và Table Calculation — hai nơi còn lại. 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à #12946, #12976 (lô 134) về vai trò của LookML trong quản trị.

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

• B (Custom Field chia sẻ cho mọi người) — đây là phương án gần nhất và cũng chia sẻ được, nhưng Custom Field thuộc về một Explore/Look cụ thể, không được quản lý phiên bản, và ai cũng sửa được — không đáp ứng "vĩnh viễn và được quản trị".

• C (Table Calculation lưu vào dashboard) — chỉ tính trên kết quả của một truy vấn, gắn với một dashboard, không tái sử dụng được ở nơi khác.

• A (tính sẵn trong BigQuery và tạo bảng mới) — có thể chạy được, nhưng chỉ số không xuất hiện như một trường Looker dùng chung; và mỗi lần đổi logic lại phải dựng lại bảng.

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 | Phạm vi | |---|---|---|---| | LookML measure/dimension | Developer | trong CSDL | toàn tổ chức, có Git | | Custom Field | người dùng | trong CSDL | một Explore/Look | | Table Calculation | người dùng | trên KẾT QUẢ đã trả về | một Look/dashboard |

Từ khoá nhận diện:

"chỉ số chính thức, dùng chung, được quản trị" → LookML "người dùng tự tạo trường, tính trong CSDL" → Custom Field "tính trên kết quả đã có, ví dụ phần trăm tổng" → Table Calculation "cần quản lý phiên bản và review" → LookML "nhanh, tạm thời, cho một báo cáo" → Custom Field hoặc Table Calculation

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số định nghĩa ở đâu | tìm measure trong kho LookML | | Ai đổi gần đây | lịch sử Git của dự án | | Có ai dùng Custom Field trùng lặp không | rà soát các Look có custom field |

Và một quy trình đáng thiết lập khi tổ chức đã có LookML: Custom Field là nơi THỬ NGHIỆM, LookML là nơi CHỐT. Nhà phân tích tự do thử công thức mới trong Explore, nhưng khi một chỉ số trở thành số liệu chính thức, nó phải đi qua pull request — và đó chính là ranh giới giữa linh hoạt và nhất quán.