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

Đáp án

D — Dataproc.

Vì sao đúng

Đề nêu ba điều: đã có sẵn mã Apache Spark, muốn môi trường được quản lý, giảm việc quản lý hạ tầng, và giữ nguyên framework mã nguồn mở quen thuộc. Dataproc là dịch vụ Hadoop/Spark được quản lý của Google Cloud.

⚠ Điểm mấu chốt — "mã Spark ĐÃ CÓ" quyết định câu trả lời:

Đội đã có mã Spark
        ↓
    Chọn Dataflow
        ↓
    ⚠ phải VIẾT LẠI toàn bộ bằng Apache Beam
    → tốn hàng tháng, rủi ro sai lệch

    Chọn Dataproc
        ↓
    → mã Spark chạy gần như NGUYÊN VẸN
    → chỉ đổi đường dẫn dữ liệu
      (HDFS → gs://)
        ↓
    Đây là mẫu "lift and shift" cho
    khối lượng công việc Hadoop/Spark

⚠ Dataproc quản lý những gì thay bạn:

- Dựng cụm trong khoảng 90 GIÂY
- Cài sẵn Spark, Hadoop, Hive, Pig
- Tích hợp sẵn với Cloud Storage,
  BigQuery, Cloud Logging
- Autoscaling
- Vá lỗi qua image version
        ↓
    ⚠ Bạn vẫn CÓ THỂ tuỳ biến sâu
      khi cần

⚠ Ba cách chạy — chọn theo nhu cầu:

DATAPROC SERVERLESS
    → job theo lô, không quản lý cụm
    → hợp nhất với "job hằng ngày"

WORKFLOW TEMPLATE + managed cluster
    → nhiều bước, cụm tự tạo và tự xoá

DATAPROC TRÊN COMPUTE ENGINE
    → cụm thường trực, tương tác,
      tuỳ biến sâu
        ↓
    ⚠ Cả ba đều là "Dataproc"
    → đáp án của đề vẫn đúng

Xem thêm câu #13042 và #13043 (cùng lô): chọn giữa cụm thường trực và Serverless — hai biến thể của chính Dataproc. Ba câu nhất quán. Và #13038 (cùng lô): tiêu chí chọn giữa Dataflow và Data Fusion — một bài toán khác.

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

• A (Dataflow) — đây là phương án gần nhất về mặt "xử lý dữ liệu quy mô lớn không máy chủ", nhưng nó dùng Apache Beam, không phải Spark; đội sẽ phải viết lại toàn bộ mã.

• B (Cloud Data Fusion) — công cụ kéo thả; mã Spark có sẵn không dùng lại được.

• C (BigQuery) — kho dữ liệu SQL; không chạy được job Spark tuỳ ý (có Spark stored procedure, nhưng không phải cách chuyển một khối lượng công việc Spark hiện có).

Ghi nhớ

⚠ Chọn engine theo TÀI SẢN SẴN CÓ — bảng phải thuộc: | Đã có gì | Chọn | |---|---| | Mã Spark / Hadoop / Hive | Dataproc | | Chưa có gì, đội biết Java/Python | Dataflow | | Đội không lập trình | Cloud Data Fusion | | Dữ liệu đã ở BigQuery, đội giỏi SQL | BigQuery + Dataform | | Nguyên tắc | tận dụng thứ đã có trước khi viết lại |

Từ khoá nhận diện:

"đã có mã Spark/Hadoop" → Dataproc "framework mã nguồn mở quen thuộc" → Dataproc "không muốn quản lý cụm" → Dataproc Serverless "viết pipeline mới, cần luồng" → Dataflow "kéo thả" → Cloud Data Fusion

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Job chạy thế nào | gcloud dataproc jobs list --region=<r> | | Cụm có bị bỏ quên không | gcloud dataproc clusters list | | Chi phí bao nhiêu | billing export, lọc SKU Dataproc |

Và một thay đổi tư duy đáng nói rõ với đội khi chuyển Spark lên Dataproc: đừng mang cả HDFS lên theo. Lưu dữ liệu ở Cloud Storage và coi cụm là tài nguyên tạm thời là điều tạo ra phần lớn khoản tiết kiệm — còn dựng lại một cụm Hadoop thường trực trên đám mây thì gần như chỉ là chuyển hoá đơn từ nơi này sang nơi khác.

Đáp án

A — Bộ điều phối phải DỪNG toàn bộ quy trình và gửi CẢNH BÁO.

Vì sao đúng

Khi bước đầu tiên thất bại, mọi bước sau đều dựa trên dữ liệu không tồn tại hoặc đã cũ. Chạy tiếp chỉ tạo ra kết quả sai một cách im lặng — điều tệ hơn nhiều so với một luồng dừng lại.

⚠ Điểm mấu chốt — "thà dừng còn hơn chạy sai":

Bước 1 (Dataproc) THẤT BẠI
        ↓
    Nếu bước 2 vẫn chạy
        ↓
    → nạp vào BigQuery dữ liệu CŨ,
      hoặc KHÔNG CÓ GÌ
        ↓
    ⚠ Báo cáo hôm nay hiển thị số của hôm qua
    ⚠ KHÔNG có lỗi nào báo ra
    ⚠ Có thể nhiều tuần sau mới ai đó phát hiện
        ↓
    → dừng và cảnh báo là hành vi ĐÚNG

⚠ Trong Airflow, đây chính là hành vi MẶC ĐỊNH:

xu_ly >> nap_bigquery >> xoa_cum

        ↓
    trigger_rule mặc định = ALL_SUCCESS
        ↓
    → bước sau chỉ chạy khi bước trước
      THÀNH CÔNG
    → bước 1 hỏng → bước 2 và 3
      chuyển sang trạng thái UPSTREAM_FAILED
        ↓
    + on_failure_callback hoặc email_on_failure
      → gửi cảnh báo

⚠ Nhưng bước DỌN DẸP là ngoại lệ đáng cân nhắc:

Bước 3 xoá cụm Dataproc
        ↓
    ⚠ Nếu cũng bị chặn khi bước 1 hỏng
    → CỤM NẰM KHÔNG VÀ TÍNH TIỀN
        ↓
    Cách xử lý đúng:
      xoa_cum có trigger_rule = ALL_DONE
        ↓
    → "chạy dù các bước trước thành công
      hay thất bại"
    → cụm luôn được dọn
        ↓
    ⚠ Nhưng bước NẠP vẫn phải bị chặn

⚠ Thử lại có giới hạn — không phải vô hạn:

retries = 3
retry_delay = 5 phút
retry_exponential_backoff = True
        ↓
    → chịu được lỗi tạm thời (mạng, quota)
    → hết số lần thì DỪNG và cảnh báo
        ↓
    ⚠ Thử lại VÔ HẠN che giấu lỗi thật
      và đốt tài nguyên

Xem thêm câu #13003 và #12996 (lô 135): cùng về phụ thuộc giữa các bước trong Cloud Composer. Câu này nói về hành vi khi một bước thất bại — mặt còn lại của cùng một cơ chế. Nhất quán.

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

• B (tự thử lại VÔ HẠN cho tới khi thành công) — đây là phương án gần nhất vì thử lại là điều nên làm, nhưng vô hạn là sai: nó che giấu lỗi thật (lược đồ đổi, dữ liệu hỏng), đốt tài nguyên, và không ai được báo.

• D (vẫn chạy job nạp BigQuery với dữ liệu có sẵn) — nạp dữ liệu không đầy đủ vào kho là cách tạo ra báo cáo sai mà không có tín hiệu nào.

• C (xoá cụm ngay lập tức để tiết kiệm) — dọn dẹp là đúng nhưng chưa đủ: thiếu phần dừng luồng và cảnh báo, và xoá cụm ngay có thể mất log hữu ích cho việc chẩn đoán.

Ghi nhớ

⚠ Xử lý thất bại trong bộ điều phối — bảng phải thuộc: | Tình huống | Hành vi đúng | |---|---| | Bước xử lý chính hỏng | DỪNG luồng + CẢNH BÁO | | Lỗi tạm thời (mạng, quota) | thử lại CÓ GIỚI HẠN, có backoff | | Bước DỌN DẸP | chạy dù trước đó hỏng (ALL_DONE) | | Bước không quan trọng | có thể bỏ qua (trigger_rule phù hợp) | | Nguyên tắc | thà DỪNG còn hơn chạy sai im lặng |

Từ khoá nhận diện:

"bước trước hỏng thì làm gì" → dừng + cảnh báo "vẫn chạy tiếp với dữ liệu có sẵn" → luôn là phương án SAI "thử lại vô hạn" → luôn là phương án SAI "dọn dẹp tài nguyên" → trigger_rule = ALL_DONE "đợi N phút rồi chạy bước sau" → không phải phụ thuộc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bước nào hỏng và vì sao | Airflow Graph view và log của task | | Cụm đã được dọn chưa | gcloud dataproc clusters list | | Cảnh báo có tới không | kiểm tra kênh thông báo |

Và một chi tiết thiết kế rất đáng làm đúng ngay từ đầu: bước dọn dẹp phải chạy kể cả khi các bước trước thất bại. Nếu không, một job Dataproc hỏng lúc nửa đêm sẽ để lại một cụm chạy không suốt cuối tuần — và hoá đơn đó thường lớn hơn nhiều so với chính công việc mà nó lẽ ra phải làm.

Đáp án

A — Matplotlib.

Vì sao đúng

Matplotlib là thư viện Python chuẩn để vẽ biểu đồ — và trong bốn phương án, nó là thứ duy nhất thực sự là một thư viện vẽ.

⚠ Điểm mấu chốt — phân biệt THƯ VIỆN với MÔI TRƯỜNG:

MATPLOTLIB
    → THƯ VIỆN Python để VẼ BIỂU ĐỒ   ✓

JUPYTER
    → MÔI TRƯỜNG notebook
    → nơi bạn CHẠY mã, không phải thứ vẽ

COLAB ENTERPRISE
    → DỊCH VỤ notebook được quản lý
    → cũng là môi trường

BIGQUERY
    → KHO DỮ LIỆU
    → nơi lấy dữ liệu ra

⚠ Vẽ biểu đồ cột so sánh doanh số theo vùng:

import matplotlib.pyplot as plt

plt.figure(figsize=(10, 5))
plt.bar(df['vung'], df['doanh_so'])
plt.title('Doanh so theo vung')
plt.xlabel('Vung')
plt.ylabel('Doanh so')
plt.xticks(rotation=45)
plt.tight_layout()
plt.show()

        ↓
    Hoặc gọn hơn qua pandas:
      df.plot.bar(x='vung', y='doanh_so')
    → pandas dùng matplotlib bên dưới

⚠ Hệ sinh thái vẽ biểu đồ của Python:

MATPLOTLIB
    → nền tảng, kiểm soát chi tiết nhất
    → hầu hết thư viện khác dựng trên nó

SEABORN
    → dựng TRÊN matplotlib
    → cú pháp gọn hơn, mặc định đẹp hơn
    → mạnh với biểu đồ thống kê

PLOTLY / BOKEH / ALTAIR
    → biểu đồ TƯƠNG TÁC
    → zoom, hover, lọc

PANDAS .plot()
    → vỏ bọc tiện lợi của matplotlib

Xem thêm câu #13029 và #13031 (lô 135): về môi trường notebook (Colab Enterprise) và lợi ích chạy lại notebook. Câu này về thư viện dùng BÊN TRONG notebook. Ba câu bổ sung nhau — môi trường, cách dùng, và công cụ.

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

• B (Jupyter) — đây là phương án dễ nhầm nhất vì nó gắn liền với công việc này, nhưng Jupyter là MÔI TRƯỜNG notebook — nơi bạn viết và chạy mã, không phải thư viện vẽ.

• C (Colab Enterprise) — dịch vụ notebook được quản lý của Google Cloud; cũng là môi trường.

• D (BigQuery) — kho dữ liệu; nó là nơi bạn lấy dữ liệu, không phải nơi vẽ (dù giao diện có biểu đồ cơ bản).

Ghi nhớ

⚠ Phân biệt bốn tầng trong công việc phân tích — bảng phải thuộc: | Tầng | Ví dụ | |---|---| | Kho dữ liệu | BigQuery | | Môi trường thực thi | Jupyter, Colab Enterprise, Vertex AI Workbench | | Thư viện xử lý | pandas, numpy, scikit-learn | | Thư viện vẽ | matplotlib, seaborn, plotly | | Công cụ BI | Looker Studio, Looker |

Từ khoá nhận diện:

"thư viện Python vẽ biểu đồ" → matplotlib, seaborn, plotly "môi trường notebook" → Jupyter, Colab Enterprise "xử lý dữ liệu dạng bảng trong Python" → pandas "kho dữ liệu" → BigQuery "dashboard cho người dùng nghiệp vụ" → Looker Studio

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Biểu đồ có hiện không | plt.show(), hoặc để ô lệnh trả về figure | | Dữ liệu có đúng không | kiểm df.describe() trước khi vẽ | | Notebook chạy lại được không | Restart & Run All |

Và một thói quen nhỏ giúp tránh kết luận sai từ biểu đồ: nhìn df.describe() trước khi vẽ. Một giá trị ngoại lai duy nhất có thể làm mọi cột khác trong biểu đồ dẹt xuống thành đường thẳng — biểu đồ trông vẫn hợp lệ, chỉ là nó không còn nói lên điều gì về phần dữ liệu mà bạn quan tâm.

Đáp án

C — Dataflow là engine xử lý TRỰC TIẾP hơn, còn Cloud Data Fusion có thêm một lớp trừu tượng làm tăng chi phí phụ trội.

Vì sao đúng

Cả hai đều chuyển được tệp CSV từ Cloud Storage vào CSDL. Khác biệt về hiệu quả nằm ở số tầng mà công việc phải đi qua.

⚠ Điểm mấu chốt — so kiến trúc hai dịch vụ:

DATAFLOW
    Mã Beam của bạn
        ↓
    Dataflow runner
        ↓
    Worker VM
        ↓
    → MỘT tầng duy nhất

CLOUD DATA FUSION
    Pipeline kéo thả
        ↓
    CDAP (nền tảng bên dưới)
        ↓
    Sinh ra job Spark
        ↓
    Chạy trên cụm DATAPROC
        ↓
    → BA tầng, cộng thêm INSTANCE
      Data Fusion chạy THƯỜNG TRỰC

⚠ Chi phí phụ trội cụ thể ở đâu:

1. INSTANCE DATA FUSION
    → chạy 24/7, tính tiền theo giờ
    → kể cả khi không pipeline nào chạy

2. CỤM DATAPROC
    → mỗi lần chạy phải dựng cụm
    → mất vài phút khởi động

3. LỚP CDAP
    → thêm một tầng dịch giữa
      pipeline và Spark
        ↓
    Với tác vụ ĐƠN GIẢN và NGẮN,
    ba khoản này chiếm phần lớn chi phí

⚠ Nhưng đừng kết luận Data Fusion "kém":

Giá trị của Data Fusion nằm ở
    KHÔNG CẦN LẬP TRÌNH
        ↓
    → nhà phân tích tự dựng pipeline
    → không phụ thuộc đội kỹ thuật
    → triển khai rất nhanh với
      nguồn có plugin sẵn
        ↓
    ⚠ Câu hỏi này chỉ so về HIỆU QUẢ
      TÀI NGUYÊN cho một tác vụ đơn giản

Xem thêm câu #13030 (lô 135): khoá Dataflow với cùng lý do — ít chi phí phụ trội cho xử lý thuần tuý. Và #13038 (cùng lô): nêu tiêu chí phân biệt chính là code-first hay low-code. Ba câu hoàn toàn nhất quán.

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

• B (pipeline Dataflow luôn nhanh hơn để phát triển) — đây là phương án gần nhất về mặt "so sánh hai công cụ", nhưng ngược lại: với đội không lập trình, Data Fusion phát triển nhanh hơn nhiều.

• A (chỉ Dataflow xử lý được CSV) — sai; cả hai đều đọc CSV.

• D (Data Fusion không ghi được vào CSDL) — sai; nó có plugin cho nhiều loại CSDL.

Ghi nhớ

⚠ Dataflow ↔ Cloud Data Fusion — bảng phải thuộc: | | Dataflow | Cloud Data Fusion | |---|---|---| | Kiến trúc | engine trực tiếp | CDAP → Spark → Dataproc | | Chi phí nền | KHÔNG có | instance thường trực | | Cách xây | viết mã Beam | kéo thả | | Hiệu quả tài nguyên | cao hơn | thấp hơn với tác vụ nhỏ | | Tốc độ phát triển | chậm hơn (cần kỹ sư) | nhanh hơn (không cần mã) | | Người dùng | kỹ sư | nhà phân tích |

Từ khoá nhận diện:

"hiệu quả tài nguyên, ít phụ trội" → Dataflow "không cần lập trình, triển khai nhanh" → Cloud Data Fusion "code-first hay low-code" → tiêu chí phân biệt chính "chỉ có một công cụ làm được" → thường là phương án SAI "luôn nhanh hơn / luôn đắt hơn" → các mệnh đề tuyệt đối thường sai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí thực tế hai phương án | billing export, so SKU | | Job tốn bao nhiêu tài nguyên | Dataflow Job metrics | | Instance Data Fusion có nhàn rỗi không | thời gian chạy so với thời gian có pipeline |

Và một lựa chọn thứ ba thường bị bỏ qua khi đề bài là "chuyển một tệp CSV": có cần engine nào không? Nếu đích là BigQuery, bq load làm đúng việc đó, miễn phí, và không có hạ tầng nào phải vận hành — engine chỉ thật sự cần khi có phép biến đổi mà SQL không làm được.

Đáp án

B — Mô hình lập trình thống nhất của Apache Beam.

Vì sao đúng

Dataflow là dịch vụ chạy pipeline Apache Beam, và chính mô hình Beam là thứ cho phép cùng một mã nguồn xử lý được cả dữ liệu luồng lẫn dữ liệu theo lô.

⚠ Điểm mấu chốt — Beam trừu tượng hoá sự khác biệt lô/luồng:

Trong Beam, dữ liệu là PCOLLECTION
        ↓
    PCollection HỮU HẠN   → dữ liệu lô
    PCollection VÔ HẠN    → dữ liệu luồng
        ↓
    ⚠ Các PHÉP BIẾN ĐỔI (PTransform)
      KHÔNG PHÂN BIỆT hai loại
        ↓
    → cùng một `ParDo`, `GroupByKey`,
      `Combine` dùng cho cả hai
    → chỉ khác ở NGUỒN ĐỌC

⚠ Cùng logic, hai nguồn:

// LUỒNG
PCollection<String> a = p.apply(
    PubsubIO.readStrings().fromTopic("..."));

// LÔ
PCollection<String> b = p.apply(
    TextIO.read().from("gs://..."));

// CÙNG phép biến đổi cho cả hai
a.apply(ParDo.of(new LamSach()));
b.apply(ParDo.of(new LamSach()));

⚠ Vì sao điều này quan trọng — vấn đề mà nó giải:

Kiến trúc Lambda cổ điển
        ↓
    Một hệ thống cho luồng (tốc độ)
    Một hệ thống cho lô (chính xác)
        ↓
    ⚠ HAI bộ mã, HAI logic
    ⚠ Sửa nghiệp vụ phải sửa cả hai
    ⚠ Quên một lần → HAI CON SỐ KHÁC NHAU
      cho cùng một chỉ số
        ↓
    Beam → MỘT bộ mã duy nhất

⚠ Beam là mã nguồn mở, chạy được nhiều nơi:

Cùng một pipeline Beam chạy trên:
    Dataflow      (Google Cloud)
    Apache Flink
    Apache Spark
    Direct Runner (máy cá nhân, để test)
        ↓
    ⚠ Giảm phụ thuộc vào một nhà cung cấp

Xem thêm câu #13033 (cùng lô): khoá Dataflow cho yêu cầu một pipeline thống nhất cho luồng và lô. Câu này hỏi CÔNG NGHỆ nào cho phép điều đó → Apache Beam. Hai câu bổ sung nhau hoàn hảo.

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

• D (giao diện trực quan, không cần mã để dựng ETL) — đây là phương án gần nhất về mặt "mô tả một công nghệ dữ liệu", nhưng nó mô tả Cloud Data Fusion, không phải Dataflow — và giao diện kéo thả không liên quan gì tới việc thống nhất lô và luồng.

• A (cơ chế chuyển dữ liệu tự động cho BigQuery) — mô tả BigQuery Data Transfer Service.

• C (dịch vụ tốc độ cao chuyển dữ liệu lớn lên Cloud Storage) — mô tả Storage Transfer Service hoặc Transfer Appliance.

Ghi nhớ

⚠ Apache Beam — các khái niệm cốt lõi: | Khái niệm | Nội dung | |---|---| | Pipeline | toàn bộ luồng công việc | | PCollection | tập dữ liệu — HỮU HẠN (lô) hoặc VÔ HẠN (luồng) | | PTransform | phép biến đổi | | ParDo | biến đổi từng phần tử | | GroupByKey, Combine | gom nhóm, tổng hợp | | Window | chia luồng theo thời gian | | Watermark, Trigger | xử lý dữ liệu tới muộn | | Runner | nơi chạy: Dataflow, Flink, Spark |

Từ khoá nhận diện:

"thống nhất lô và luồng" → Apache Beam "kéo thả không cần mã" → Cloud Data Fusion "nạp theo lịch vào BigQuery" → Data Transfer Service "chuyển tệp lên GCS" → Storage Transfer Service "Spark, Hadoop" → Dataproc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline chạy chế độ nào | Dataflow console — Batch hay Streaming | | Logic có dùng chung không | rà soát mã — phép biến đổi có tách riêng không | | Kiểm thử cục bộ | chạy với Direct Runner |

Và một lợi ích thực tế của mô hình Beam mà chỉ thấy rõ khi cần sửa nghiệp vụ: một thay đổi, một chỗ sửa. Với hai hệ thống riêng cho lô và luồng, mỗi lần đổi cách tính là một lần phải nhớ đồng bộ cả hai — và lần quên đầu tiên tạo ra hai con số khác nhau cho cùng một chỉ số, thứ rất tốn thời gian để giải thích và sửa.

Đáp án

B — Bảo đảm bảng được PHÂN VÙNG theo ngày, và KHÔNG cần làm gì thêm.

Vì sao đúng

Đề có hai ràng buộc quyết định: dữ liệu PHẢI truy vấn được NGAY trong BigQuery, và ưu tiên ÍT CÔNG QUẢN TRỊ NHẤT. BigQuery đã có sẵn cơ chế tự giảm giá cho dữ liệu cũ.

⚠ Điểm mấu chốt — long-term storage là TỰ ĐỘNG:

Phân vùng KHÔNG BỊ SỬA ĐỔI trong 90 ngày
        ↓
    BigQuery TỰ chuyển sang
    long-term storage
        ↓
    Giá lưu ≈ 50% active storage
        ↓
    ⚠ KHÔNG cần cấu hình
    ⚠ KHÔNG có thay đổi nào về hiệu năng
    ⚠ Dữ liệu VẪN truy vấn bình thường
        ↓
    → đúng "ít công quản trị nhất"

⚠ Vì sao PHÂN VÙNG là điều kiện then chốt:

Bảng KHÔNG phân vùng
        ↓
    Ghi thêm dữ liệu mới mỗi ngày
        ↓
    → "lần sửa cuối" luôn là HÔM NAY
    → TOÀN BỘ bảng không bao giờ
      đạt 90 ngày
        ↓
    ⚠ KHÔNG BAO GIỜ được giá long-term

Bảng CÓ phân vùng
        ↓
    → tính theo TỪNG PHÂN VÙNG
    → phân vùng cũ tự giảm giá
    → phân vùng hôm nay vẫn giá thường

⚠ ⚠ Điều dễ hiểu lầm nhất — TRUY VẤN không làm mất ưu đãi:

Đồng hồ 90 ngày đếm từ lần SỬA ĐỔI cuối
        ↓
    Sửa đổi = thêm, xoá, cập nhật, nạp

    ⚠ SELECT KHÔNG phải sửa đổi
    ⚠ Xuất dữ liệu KHÔNG phải sửa đổi
        ↓
    → dữ liệu cũ vẫn truy vấn thoải mái
      mà vẫn giữ giá rẻ

Xem thêm câu #13011 (lô 135): khoá xuất sang Cloud Storage Archive vì ở đó dữ liệu KHÔNG BAO GIỜ truy vấn nữa trong 6 năm. Câu này dữ liệu vẫn phải truy vấn được ngay trong BigQuery → để nguyên. Hai khoá khác nhau vì ràng buộc truy vấn khác nhau — hoàn toàn nhất quán. Và #13044 (cùng lô) nêu chính điều kiện tiên quyết: phải phân vùng.

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

• C (đặt partition expiration 90 ngày) — đây là phương án gần nhất và cũng liên quan tới phân vùng, nhưng nó XOÁ dữ liệu cũ hơn 90 ngày — trái yêu cầu "dữ liệu phải còn truy vấn được".

• A (xuất phân vùng cũ sang Cloud Storage Coldline) — dữ liệu rời khỏi BigQuery; muốn truy vấn phải qua external table, chậm hơn và tốn nhiều công quản trị hơn hẳn.

• D (dựng job Dataflow ghi lại phân vùng cũ ở định dạng nén) — rất nhiều công, và BigQuery đã nén sẵn dữ liệu; không mang lại lợi ích gì.

Ghi nhớ

⚠ Giảm chi phí lưu trữ BigQuery — bảng phải thuộc: | Cách | Công quản trị | Dữ liệu còn truy vấn được? | |---|---|---| | Phân vùng + long-term storage | KHÔNG có — tự động | CÓ, bình thường | | Physical storage billing | thấp — đổi ở cấp dataset | CÓ | | Partition expiration | thấp | KHÔNG — bị xoá | | Xuất sang GCS Archive | cao | qua external table, chậm | | Rút ngắn time travel | thấp | có |

Từ khoá nhận diện:

"giảm chi phí, vẫn truy vấn được, ít công nhất" → phân vùng + long-term (tự động) "xoá hẳn sau N tháng" → partition expiration "không bao giờ truy vấn nữa" → xuất sang GCS Archive "quay lại dữ liệu vài ngày trước" → time travel "tính theo dung lượng nén" → physical storage billing

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng có phân vùng chưa | bq show <dataset>.<bảng> → Time Partitioning | | Bao nhiêu ở long-term | INFORMATION_SCHEMA.TABLE_STORAGE → LONG_TERM_LOGICAL_BYTES | | Physical hay logical rẻ hơn | so TOTAL_PHYSICAL_BYTES với TOTAL_LOGICAL_BYTES |

Và một câu trả lời thường đúng hơn người ta nghĩ trong các câu hỏi tối ưu chi phí BigQuery: không cần làm gì thêm. Cơ chế long-term storage đã xử lý đúng tình huống này một cách tự động — và mọi phương án đòi dựng job, xuất dữ liệu hay viết script đều đang thêm công việc để giải một vấn đề đã được giải sẵn.

Đáp án

C — 1: Cloud SQL, 2: Cloud Storage, 3: BigQuery.

Vì sao đúng

Ba yêu cầu trong đề là ba loại khối lượng công việc kinh điển, và mỗi loại có một dịch vụ chuyên trách.

⚠ Điểm mấu chốt — ánh xạ từng yêu cầu:

1) "giao dịch khách hàng, hồ sơ người dùng,
    NHẤT QUÁN CAO"
        ↓
    → CSDL GIAO DỊCH (OLTP)
    → CLOUD SQL

2) "tệp LỚN, PHI CẤU TRÚC: ảnh, video,
    chi phí thấp"
        ↓
    → KHO ĐỐI TƯỢNG
    → CLOUD STORAGE

3) "quy mô PETABYTE, truy vấn PHÂN TÍCH
    phức tạp trên dữ liệu lịch sử"
        ↓
    → KHO PHÂN TÍCH (OLAP)
    → BIGQUERY

⚠ OLTP ↔ OLAP — phân biệt cốt lõi:

OLTP (Cloud SQL, Spanner)
    → nhiều giao dịch NHỎ, nhanh
    → đọc/ghi vài dòng
    → nhất quán mạnh, có khoá
    → tối ưu cho GHI

OLAP (BigQuery)
    → ít truy vấn, mỗi truy vấn QUÉT RẤT NHIỀU
    → tổng hợp hàng tỉ dòng
    → lưu theo CỘT
    → tối ưu cho ĐỌC PHÂN TÍCH
        ↓
    ⚠ Dùng nhầm chỗ là sai kiến trúc căn bản

⚠ Vì sao không nhét ảnh vào CSDL:

Lưu ảnh dạng BLOB trong Cloud SQL
        ↓
    ⚠ Giá lưu ĐẮT HƠN GCS nhiều lần
    ⚠ Phình CSDL → sao lưu chậm
    ⚠ Không phục vụ trực tiếp cho trình duyệt
    ⚠ Không dùng được CDN
        ↓
    → luôn lưu TỆP trong kho đối tượng,
      CSDL chỉ giữ ĐƯỜNG DẪN

Xem thêm câu #12940 (lô 134): cùng bài toán ánh xạ dữ liệu có cấu trúc và phi cấu trúc → BigQuery + Cloud Storage. Hai câu nhất quán.

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

• D (1: Cloud SQL, 2: BigQuery, 3: Cloud Storage) — đây là phương án gần nhất vì vế đầu đúng, nhưng nó đảo hai vế sau: BigQuery không phải nơi lưu ảnh và video, còn Cloud Storage không phải nơi chạy truy vấn phân tích phức tạp.

• A (1: BigQuery cho giao dịch) — BigQuery không phải CSDL giao dịch: không hợp với đọc ghi từng dòng liên tục.

• B (1: Cloud Storage cho giao dịch) — kho đối tượng không phải CSDL.

Ghi nhớ

⚠ Ánh xạ khối lượng công việc → dịch vụ — bảng phải thuộc: | Nhu cầu | Dịch vụ | |---|---| | Giao dịch, nhất quán cao, một Region | Cloud SQL | | Giao dịch, NHIỀU REGION, nhất quán mạnh | Cloud Spanner | | Tệp phi cấu trúc: ảnh, video, sao lưu | Cloud Storage | | Phân tích quy mô petabyte | BigQuery | | NoSQL tài liệu, ứ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:

"giao dịch, hồ sơ người dùng, nhất quán" → Cloud SQL "ảnh, video, tệp lớn, chi phí thấp" → Cloud Storage "petabyte, truy vấn phân tích" → BigQuery "toàn cầu + nhất quán mạnh" → Cloud Spanner "lưu ảnh trong CSDL" → luôn là phương án SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cloud SQL có bị dùng để phân tích không | xem truy vấn chậm trong log | | Ảnh có nằm trong CSDL không | kiểm tra cột BLOB | | Chi phí chia theo dịch vụ | billing export, nhóm theo SKU |

Và một dấu hiệu sai kiến trúc rất dễ nhận ra khi rà soát một hệ thống đang chạy: truy vấn báo cáo chạy thẳng trên CSDL giao dịch. Nó thường bắt đầu bằng một câu "chỉ một báo cáo nhỏ thôi", rồi lớn dần cho tới khi ứng dụng khách hàng chậm đi vào mỗi sáng thứ Hai — và cách chữa luôn là tách sang một kho phân tích riêng.

Đáp án

A — Platform as a Service (PaaS — nền tảng như một dịch vụ).

Vì sao đúng

Đề nêu rõ ranh giới trách nhiệm: đội chỉ muốn viết mã ứng dụng và quản lý dữ liệu, KHÔNG chịu trách nhiệm về hệ điều hành, phần cứng máy chủ hay mạng. Đó chính là định nghĩa của PaaS.

⚠ Điểm mấu chốt — ba mô hình chia trách nhiệm khác nhau:

IaaS — Infrastructure as a Service
    Nhà cung cấp: phần cứng, ảo hoá, mạng
    BẠN: hệ điều hành, runtime, ứng dụng,
         dữ liệu, vá lỗi
        ↓
    Ví dụ: Compute Engine

PaaS — Platform as a Service       ← đề này
    Nhà cung cấp: + hệ điều hành, runtime,
                   mở rộng, vá lỗi
    BẠN: ỨNG DỤNG và DỮ LIỆU
        ↓
    Ví dụ: App Engine, Cloud Run

SaaS — Software as a Service
    Nhà cung cấp: TẤT CẢ
    BẠN: chỉ dùng phần mềm
        ↓
    Ví dụ: Google Workspace, Looker Studio

⚠ Mẹo nhớ — "bạn quản lý tới đâu":

IaaS  → bạn quản lý từ HỆ ĐIỀU HÀNH trở lên
PaaS  → bạn quản lý từ ỨNG DỤNG trở lên
SaaS  → bạn không quản lý gì cả
        ↓
    ⚠ Đề nói "chỉ viết mã và quản lý dữ liệu"
    → đúng ranh giới của PaaS

⚠ PaaS trên Google Cloud:

APP ENGINE
    → PaaS cổ điển nhất
    → Standard: ngôn ngữ định sẵn, co về 0
    → Flexible: container, linh hoạt hơn

CLOUD RUN
    → PaaS hiện đại, dựa trên CONTAINER
    → co về 0, trả theo request
    → bất kỳ ngôn ngữ nào

CLOUD RUN FUNCTIONS
    → FaaS — mức trừu tượng cao hơn nữa

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

• B (IaaS) — đây là phương án gần nhất trong ba mô hình chuẩn, nhưng với IaaS bạn VẪN phải quản lý hệ điều hành: vá lỗi, cấu hình, giám sát — đúng thứ đề nói không muốn.

• C (SaaS) — là phần mềm dùng sẵn; đội không viết được ứng dụng riêng trên đó.

• D (Data Center as a Service) — không phải mô hình chuẩn trong bộ ba IaaS/PaaS/SaaS.

Ghi nhớ

⚠ Ba mô hình dịch vụ đám mây — 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 | | SaaS | chỉ dữ liệu và cấu hình | Google Workspace, Looker Studio | | FaaS | chỉ hàm | Cloud Run functions | | Mẹo nhớ | càng lên cao, bạn quản lý càng ít |

Từ khoá nhận diện:

"chỉ viết mã, không quản hệ điều hành" → PaaS "cần kiểm soát hệ điều hành, cài phần mềm riêng" → IaaS "dùng phần mềm có sẵn" → SaaS "chỉ một hàm theo sự kiện" → FaaS "container được quản lý" → Cloud Run — PaaS/CaaS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai chịu trách nhiệm vá lỗi | đọc tài liệu trách nhiệm chung của dịch vụ | | Ứng dụng có bị khoá nền tảng không | đóng gói bằng container để giảm rủi ro | | Chi phí thực tế | Pricing Calculator với lưu lượng dự kiến |

Và một nguyên tắc đáng giữ khi chọn giữa các mức trừu tượng: chọn mức cao nhất còn đáp ứng được yêu cầu. Mỗi bậc đi xuống — từ Cloud Run về GKE, từ GKE về Compute Engine — đổi lấy thêm quyền kiểm soát bằng thêm việc phải làm mỗi tuần, và cái giá đó thường lớn hơn nhiều so với vẻ ngoài của nó.

Đáp án

D — Change Data Capture (CDC — bắt thay đổi dữ liệu).

Vì sao đúng

CDC là cơ chế đọc nhật ký giao dịch của CSDL nguồn và phát lại các thay đổi lên đích một cách liên tục — chính là thứ cho phép di chuyển với thời gian ngừng gần như bằng không.

⚠ Điểm mấu chốt — CDC đọc NHẬT KÝ, không truy vấn bảng:

Mọi CSDL đều ghi NHẬT KÝ GIAO DỊCH
    MySQL      → binlog
    PostgreSQL → WAL
    Oracle     → redo log
    SQL Server → transaction log
        ↓
    CDC ĐỌC TUẦN TỰ nhật ký đó
        ↓
    → biết chính xác dòng nào vừa
      thêm/sửa/xoá, theo đúng thứ tự
        ↓
    ⚠ Gần như KHÔNG tạo tải truy vấn
      lên CSDL nguồn

⚠ Ba giai đoạn của di chuyển gần như không ngừng:

1. FULL DUMP
    → sao chép toàn bộ dữ liệu hiện có
    → nguồn VẪN PHỤC VỤ bình thường

2. CDC
    → bắt kịp và bám theo mọi thay đổi
    → theo dõi REPLICATION LAG
        ↓
    ⚠ Đây là giai đoạn CDC làm việc

3. CUTOVER — khi lag ≈ 0
    → dừng ghi vài phút
    → đợi lag về 0
    → thăng cấp đích
        ↓
    Thời gian ngừng: VÀI PHÚT

⚠ Vì sao CDC nhẹ hơn hẳn cách truy vấn:

Cách truy vấn định kỳ
    SELECT * FROM don_hang
    WHERE cap_nhat > '<lần trước>'
        ↓
    ⚠ quét bảng, dùng CPU và I/O của nguồn
    ⚠ bỏ sót bản ghi bị XOÁ
    ⚠ cần cột dấu thời gian đáng tin

CDC
        ↓
    → đọc tệp nhật ký tuần tự
    → BẮT ĐƯỢC CẢ THAO TÁC XOÁ
    → không cần cột dấu thời gian

Xem thêm câu #12986 (lô 135): về khái niệm online migration — CDC chính là cơ chế làm nên nó. Và #13002, #13040 (cùng lô và lô 135): chọn DMS cho chính bài toán này. Bốn câu mô tả cùng một chủ đề từ bốn góc — hoàn toàn nhất quán.

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

• C (tự động chuyển đổi lược đồ cho kho dữ liệu) — đây là phương án gần nhất về mặt "một tính năng của DMS", và DMS có chuyển đổi lược đồ trong di chuyển không đồng nhất, nhưng đó không phải thứ tạo ra khả năng đồng bộ liên tục.

• A (trình dựng pipeline trực quan không cần mã) — mô tả Cloud Data Fusion, không phải DMS.

• B (tích hợp với BigQuery cho phân tích thời gian thực) — mô tả Datastream; đích của DMS là Cloud SQL / AlloyDB.

Ghi nhớ

⚠ CDC — điều cần thuộc: | Điểm | Nội dung | |---|---| | Cơ chế | đọc NHẬT KÝ GIAO DỊCH của CSDL | | Tải lên nguồn | rất nhẹ — không truy vấn bảng | | Bắt được thao tác XOÁ | khác hẳn cách truy vấn theo dấu thời gian | | Giữ đúng thứ tự | theo nhật ký | | Cho phép | di chuyển gần như không ngừng | | Dịch vụ dùng CDC | DMS, Datastream |

Từ khoá nhận diện:

"đồng bộ liên tục, thời gian ngừng gần bằng 0" → CDC "CSDL → Cloud SQL" → DMS (dùng CDC) "CSDL → BigQuery gần thời gian thực" → Datastream (dùng CDC) "kéo thả không cần mã" → Cloud Data Fusion "chuyển đổi lược đồ" → một tính năng phụ, không phải cơ chế đồng bộ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lag hiện tại bao nhiêu | DMS console → replication delay | | Nguồn đã bật nhật ký chưa | kiểm tra cấu hình CSDL nguồn | | Dữ liệu đã khớp chưa | so COUNT(*) và checksum từng bảng |

Và một quy tắc nên thoả thuận với đội phát triển trước khi bắt đầu giai đoạn CDC: đóng băng mọi thay đổi lược đồ cho tới khi cắt chuyển xong. Một lệnh ALTER TABLE chạy giữa chừng có thể làm luồng nhân bản dừng lại hoặc áp sai dữ liệu — và phát hiện điều đó vào đêm cắt chuyển là tình huống không ai muốn gặp.

Đáp án

C — CMEK (Customer-Managed Encryption Keys — khoá mã hoá do khách hàng quản lý).

Vì sao đúng

Đề nêu hai điều: khoá mã hoá do đội bảo mật của công ty quản lý trong Cloud KMS, và người dùng có quyền truy vấn thì thấy dữ liệu đã giải mã, KHÔNG phải viết hàm SQL đặc biệt. Chỉ CMEK thoả cả hai.

⚠ Điểm mấu chốt — CMEK mã hoá ĐĨA, hoàn toàn TRONG SUỐT:

CMEK
        ↓
    Thay khoá mặc định của Google
    bằng khoá của BẠN trong Cloud KMS
        ↓
    BigQuery tự giải mã khi đọc
        ↓
    ⚠ Người dùng truy vấn BÌNH THƯỜNG
    ⚠ KHÔNG gọi hàm nào
    ⚠ KHÔNG biết có CMEK hay không
        ↓
    → đúng yêu cầu "thấy dữ liệu giải mã,
      không cần SQL đặc biệt"

⚠ Cấu hình:

# 1. Tạo key ring và key trong Cloud KMS
gcloud kms keyrings create vong-khoa \
  --location=asia-southeast1
gcloud kms keys create khoa-bq \
  --keyring=vong-khoa --location=asia-southeast1 \
  --purpose=encryption --rotation-period=90d

# 2. Cấp quyền cho SERVICE AGENT của BigQuery
#    roles/cloudkms.cryptoKeyEncrypterDecrypter

# 3. Đặt khoá mặc định cho dataset
bq update --destination_kms_key=... du_an:dataset

⚠ Sức mạnh thật sự của CMEK — công tắc ngắt:

Vô hiệu hoá hoặc huỷ khoá trong KMS
        ↓
    ⚠ Dữ liệu KHÔNG GIẢI MÃ ĐƯỢC NỮA
        ↓
    → đây là "công tắc ngắt" cho dữ liệu
    → chính là thứ mà yêu cầu tuân thủ
      thường muốn có
        ↓
    ⚠ Cũng là rủi ro: mất khoá = mất dữ liệu

Xem thêm câu #13065 (cùng lô): khoá CSEK vì ở đó khoá phải nằm HOÀN TOÀN NGOÀI Google Cloud. #13037 (cùng lô): khoá AEAD vì dữ liệu phải là bản mã trong bảng và phải gọi hàm. #12984 (lô 135): khoá GMEK vì không muốn cấu hình gì. Bốn câu, bốn mức kiểm soát khoá — hoàn toàn nhất quán.

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

• B (hàm AEAD) — đây là phương án gần nhất về mức bảo vệ, nhưng nó đòi gọi hàm giải mã tường minh trong SQL — đúng thứ đề nói không được có. Và nó mã hoá một cột, không phải cả dataset.

• A (Dynamic Data Masking) — CHE giá trị với người không đủ quyền; đề muốn người có quyền thấy dữ liệu bình thường và vấn đề là quản lý KHOÁ, không phải che.

• D (Authorized View) — kiểm soát ai thấy kết quả gì, không liên quan tới khoá mã hoá.

Ghi nhớ

⚠ Bốn mức quản lý khoá — bảng phải thuộc: | Mức | Ai tạo và giữ khoá | Người dùng cần làm gì | |---|---|---| | GMEK | Google | không gì — mặc định | | CMEK | BẠN, trong Cloud KMS | không gì — trong suốt | | CSEK | BẠN, bên ngoài GCP | gửi khoá theo từng yêu cầu | | Cloud EKM | hệ thống ngoài Google Cloud | trong suốt, khoá ở ngoài | | AEAD | bạn, keyset trong SQL | PHẢI gọi hàm giải mã |

Từ khoá nhận diện:

"tự quản khoá bằng Cloud KMS, trong suốt với người dùng" → CMEK "khoá phải nằm ngoài Google Cloud" → CSEK hoặc Cloud EKM "phải gọi hàm giải mã" → AEAD "không cần cấu hình gì" → GMEK "che giá trị theo vai trò" → dynamic data masking

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dataset dùng khoá nào | bq show --format=prettyjson <dataset> → defaultEncryptionConfiguration | | Khoá xoay bao lâu một lần | gcloud kms keys describe → rotationPeriod | | Ai truy cập được khoá | gcloud kms keys get-iam-policy |

Và một nguyên tắc tổ chức phải đi kèm CMEK để nó thật sự có giá trị: tách bạch người quản khoá khỏi người quản dữ liệu. Sức mạnh của CMEK nằm ở chỗ vô hiệu hoá khoá là khoá luôn dữ liệu — nhưng nếu cùng một người vừa quản khoá vừa quản dataset, cơ chế ấy không thêm lớp bảo vệ nào, mà chỉ thêm một cách để mất dữ liệu do nhầm lẫn.