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

Đáp án

C — Colab Enterprise.

Vì sao đúng

Đề nêu năm yêu cầu, và chỉ một môi trường notebook đáp ứng được cả năm: mã SQL và Python, biểu đồ tuỳ chỉnh bằng Matplotlib, văn bản diễn giải, gói trong MỘT tài liệu duy nhất, và chạy lại được với dữ liệu mới.

⚠ Điểm mấu chốt — notebook gộp bốn thứ vào một tệp:

Một notebook chứa:
    ô MARKDOWN     → văn bản diễn giải
    ô SQL          → %%bigquery
    ô PYTHON       → pandas, scikit-learn
    ô ĐẦU RA       → biểu đồ Matplotlib
        ↓
    ⚠ Tất cả trong MỘT tệp .ipynb
    ⚠ Chạy lại toàn bộ → dữ liệu mới,
      biểu đồ mới, kết luận cập nhật
        ↓
    Đây chính là "phân tích LẶP LẠI ĐƯỢC
    và CÓ TÀI LIỆU"

⚠ Ví dụ cấu trúc một notebook báo cáo:

# Ô 1 — Markdown: mục tiêu và giả định

# Ô 2 — SQL
%%bigquery df_churn
SELECT khach_id, so_thang_su_dung, da_roi_bo
FROM `du_an.khach_hang`
WHERE ngay >= DATE_SUB(CURRENT_DATE(), INTERVAL 12 MONTH)

# Ô 3 — Python
import matplotlib.pyplot as plt
df_churn.groupby('so_thang_su_dung')['da_roi_bo'] \
        .mean().plot.bar()
plt.title('Ti le roi bo theo tham nien')

# Ô 4 — Markdown: nhận định và khuyến nghị

⚠ Vì sao Colab Enterprise chứ không phải Jupyter tự cài:

Colab Enterprise
    → Jupyter ĐƯỢC QUẢN LÝ trong Vertex AI
    → chạy dưới SERVICE ACCOUNT
      (không cần khoá JSON)
    → kết nối BigQuery bằng một dòng
    → cộng tác như Google Docs
    → kiểm soát bằng IAM và VPC-SC
        ↓
    → không phải vá máy chủ, không phải
      tự lo bảo mật

Xem thêm câu #13029 (lô 135): cùng khoá Colab Enterprise cho môi trường notebook được quản lý. #13031 (lô 135): lợi ích chạy lại notebook cho báo cáo định kỳ. #13053 (lô 136): Matplotlib là thư viện vẽ. Bốn câu nhất quán, mô tả cùng một quy trình làm việc.

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

• D (BigQuery Studio) — đây là phương án gần nhất và thật sự có hỗ trợ notebook, nhưng nó thiên về môi trường SQL và khám phá dữ liệu trong BigQuery; với báo cáo cần Python, Matplotlib và văn bản diễn giải dài, Colab Enterprise là môi trường notebook đầy đủ hơn.

• A (Looker Studio) — công cụ dashboard trực quan, không chạy được Python hay hiển thị mã.

• B (Google Sheets) — bảng tính; không phải môi trường lập trình.

Ghi nhớ

⚠ Chọn công cụ theo kiểu sản phẩm cần tạo — bảng phải thuộc: | Sản phẩm | Công cụ | |---|---| | Báo cáo có mã + biểu đồ + diễn giải, chạy lại được | Colab Enterprise / Vertex AI Notebooks | | Dashboard tương tác cho người dùng nghiệp vụ | Looker Studio | | Chỉ số thống nhất toàn công ty | Looker | | Khám phá bằng SQL | BigQuery Studio | | Phân tích trong bảng tính | Connected Sheets |

Từ khoá nhận diện:

"mã + biểu đồ + văn bản trong một tài liệu" → notebook "chạy lại với dữ liệu mới" → notebook "dashboard tương tác không cần mã" → Looker Studio "khám phá bằng SQL" → BigQuery Studio "Matplotlib, pandas" → môi trường Python

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Notebook chạy lại được không | Restart & Run All | | Có ngày hard-code không | tìm chuỗi ngày trong mã | | Runtime có tự tắt không | cấu hình idle shutdown |

Và một phép thử đơn giản quyết định báo cáo có thật sự "chạy lại được" hay không: Restart & Run All trên máy của người khác. Rất nhiều notebook chỉ chạy đúng trong môi trường của tác giả — thiếu một thư viện, dựa vào một biến còn sót, hoặc trỏ vào một bảng tạm đã bị xoá — và đó là lúc "tài liệu lặp lại được" trở thành một tệp không ai mở lại được.

Đáp án

C — Lệnh gcloud storage cp.

Vì sao đúng

Đề nêu ba điều: 5 MB, một lần duy nhất, làm thủ công, và KHÔNG cần lịch chạy hay tính năng di chuyển phức tạp. Công cụ dòng lệnh là mức vừa đủ.

⚠ Điểm mấu chốt — một dòng lệnh cho một việc nhỏ:

gcloud storage cp cau-hinh.yaml \
  gs://bucket/cau-hinh/
        ↓
    ⚠ 5 MB → xong trong vài giây
    ⚠ Không dựng gì, không cấu hình gì
    ⚠ Không có dịch vụ nào phải quản lý

⚠ Bảng quy mô — chọn công cụ theo con số:

Vài MB – vài GB, một lần
    → gcloud storage cp

Vài TB, có lịch, cần thử lại tự động
    → Storage Transfer Service

Hàng trăm TB, băng thông không đủ
    → Transfer Appliance
        ↓
    ⚠ Dùng công cụ nặng cho việc nhẹ
      là mất thời gian, không phải
      cẩn thận

⚠ Vài cờ hữu ích:

gcloud storage cp -r ./thu-muc gs://bucket/
    → chép cả thư mục

gcloud storage rsync -r ./thu-muc gs://bucket/
    → đồng bộ, chỉ chép phần khác

gcloud storage cp gs://bucket/tep .
    → tải xuống

gcloud storage ls -l gs://bucket/
    → kiểm tra sau khi chép

Xem thêm câu #13074 (lô 136): cùng tình huống, cùng khoá gcloud storage cho 0,9 GB một lần. Hai câu hoàn toàn nhất quán. Và #13082, #13089 (cùng lô): cùng bộ tiêu chí cho quy mô lớn hơ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à là dịch vụ chuyển dữ liệu được quản lý, nhưng nó sinh ra cho khối lượng lớn, chạy theo lịch, cần thử lại và báo cáo. Với một tệp 5 MB, dựng một job là nhiều bước hơn hẳn giá trị mang lại.

• D (Transfer Appliance) — thiết bị vật lý cho hàng trăm TB; gửi ổ cứng cho 5 MB là vô lý.

• B (Cloud Storage FUSE) — gắn bucket như hệ thống tệp cho ứ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 — bảng phải thuộc: | Khối lượng và tần suất | Công cụ | |---|---| | MB tới vài GB, một lần | gcloud storage cp / rsync | | TB, theo lịch, được quản lý | Storage Transfer Service | | Nguồn tại chỗ, băng thông đủ | STS + agent pool | | Hàng trăm TB, băng thông kém | Transfer Appliance | | Ứng dụng đọc bucket như thư mục | Cloud Storage FUSE |

Từ khoá nhận diện:

"một tệp nhỏ, một lần, thủ công" → gcloud storage cp "theo lịch, khối lượng lớn" → Storage Transfer Service "mất nhiều tháng nếu truyền mạng" → Transfer Appliance "gắn bucket như thư mục" → Cloud Storage FUSE "đồng bộ hai bên" → rsync

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tệp đã lên chưa | gcloud storage ls -l gs://bucket/cau-hinh/ | | Kích thước có khớp không | so với ls -l cục bộ | | Ai đọc được tệp đó | gcloud storage buckets get-iam-policy |

Và một nguyên tắc đáng nhớ cho mọi câu hỏi dạng "chọn công cụ": đọc con số khối lượng trước tiên. Vài MB thì một lệnh CLI là đúng mức; vài TB mới cần dịch vụ được quản lý — và chọn công cụ nặng hơn mức cần thiết không phải là cẩn thận, mà là làm chậm chính mình.

Đáp án

B — Spanner.

Vì sao đúng

Đề nêu ba yêu cầu đi cùng nhau, và chỉ Spanner đáp ứng được cả ba: người dùng toàn cầu ngay từ đầu, mở rộng NGANG qua nhiều châu lục, và nhất quán giao dịch MẠNH cho các giao dịch tài chính.

⚠ Điểm mấu chốt — Spanner là CSDL duy nhất có cả ba:

CSDL QUAN HỆ có giao dịch
    +
MỞ RỘNG NGANG không giới hạn
    +
NHẤT QUÁN MẠNH ở phạm vi TOÀN CẦU
        ↓
    ⚠ Ba thứ này thường loại trừ nhau
      trong lý thuyết CSDL phân tán
        ↓
    Spanner đạt được nhờ TRUETIME

⚠ TrueTime — cơ chế đằng sau:

Google đặt ĐỒNG HỒ NGUYÊN TỬ và GPS
trong các trung tâm dữ liệu
        ↓
    → biết chính xác thời gian với
      sai số rất nhỏ, có giới hạn
        ↓
    → sắp xếp được thứ tự giao dịch
      một cách TOÀN CỤC
        ↓
    → nhất quán mạnh mà vẫn
      mở rộng ngang được

⚠ Vì sao "giao dịch tài chính" là từ khoá quyết định:

Thanh toán quảng cáo, đăng ký thuê bao
        ↓
    ⚠ KHÔNG chấp nhận nhất quán cuối cùng
    ⚠ Không được trừ tiền hai lần
    ⚠ Không được đọc số dư cũ
        ↓
    → cần GIAO DỊCH ACID
    → và nhất quán MẠNH kể cả
      khi người dùng ở châu lục khác

Xem thêm câu #12563 (lô 133): cùng khoá Spanner cho yêu cầu nhiều Region + nhất quán mọi lúc. Và #13072 (lô 136): khoá Cloud SQL cho ứng dụng một khu vực, thông thường. #13076 (lô 136): khoá Firestore cho thời gian thực, lược đồ linh hoạt. Bốn câu, ba khoá, phân biệt bằng PHẠM VI và MÔ HÌNH — hoàn toàn nhất quán.

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

• A (Firestore) — đây là phương án gần nhất về mặt "toàn cầu và mở rộng ngang", và Firestore có chế độ multi-region, nhưng nó là NoSQL tài liệu: không có giao dịch quan hệ đầy đủ ở quy mô mà giao dịch tài chính phức tạp đòi hỏi.

• C (AlloyDB) — PostgreSQL hiệu năng cao nhưng phạm vi MỘT REGION; không mở rộng ngang qua nhiều châu lục.

• D (Cloud SQL) — mở rộng theo chiều DỌC, nhân bản đa Region là BẤT ĐỒNG BỘ → không có nhất quán mạnh toàn cầu.

Ghi nhớ

⚠ Bốn CSDL và phạm vi của chúng — bảng phải thuộc: | Dịch vụ | Phạm vi | Nhất quán | |---|---|---| | Cloud SQL | một Region | mạnh trong Region; replica đa Region BẤT ĐỒNG BỘ | | AlloyDB | một Region | mạnh, hiệu năng cao | | Spanner | NHIỀU REGION, toàn cầu | MẠNH ở phạm vi toàn cầu | | Firestore | multi-region | mạnh cho tài liệu, không phải quan hệ | | Mở rộng | chỉ Spanner mở rộng NGANG cho ghi |

Từ khoá nhận diện:

"toàn cầu + nhất quán mạnh + giao dịch" → Spanner "một Region, ứng dụng thông thường" → Cloud SQL "PostgreSQL cần nhanh hơn" → AlloyDB "thời gian thực, di động, tài liệu" → Firestore "phân tích" → BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance cấu hình thế nào | gcloud spanner instances describe <ten> → config | | Có hotspot không | Key Visualizer | | CPU có đủ không | chỉ số cpu/utilization — nên dưới 65% với multi-region |

Và một điều đáng cân nhắc kỹ ngay cả khi Spanner là câu trả lời đúng về kỹ thuật: chi phí tối thiểu của nó cao hơn Cloud SQL rất nhiều. Với một ứng dụng mới chưa có người dùng, bắt đầu bằng Cloud SQL rồi chuyển sang Spanner khi thật sự đạt quy mô toàn cầu thường là quyết định kinh tế hơn — miễn là lược đồ được thiết kế sao cho việc chuyển đổi về sau không phải viết lại từ đầu.

Đáp án

A — Một external table trỏ tới vị trí trong Cloud Storage.

Vì sao đúng

Đề nêu ba điều: vài truy vấn khám phá tức thời, trên tệp log thô trong Cloud Storage, và KHÔNG dựng pipeline nạp, KHÔNG di chuyển dữ liệu. External table là cơ chế "truy vấn tại chỗ" đơn giản nhất.

⚠ Điểm mấu chốt — tạo một lần, truy vấn ngay:

CREATE EXTERNAL TABLE `du_an.log_tho`
OPTIONS (
  format = 'CSV',
  uris = ['gs://bucket/logs/*.csv'],
  skip_leading_rows = 1
);

SELECT * FROM `du_an.log_tho` LIMIT 100;

        ↓
    ⚠ KHÔNG nạp dữ liệu
    ⚠ KHÔNG sao chép gì
    ⚠ BigQuery đọc thẳng tệp khi truy vấn
        ↓
    → dựng xong trong một phút

⚠ Đánh đổi — nhanh để dựng, chậm để chạy:

EXTERNAL TABLE
    Ưu:  dựng tức thì, không di chuyển dữ liệu
         không tốn thêm dung lượng
    Nhược: ⚠ CHẬM HƠN bảng thường nhiều
           ⚠ không có phân vùng, phân cụm
           ⚠ không có thống kê để tối ưu
           ⚠ không cache kết quả
        ↓
    → hợp với KHÁM PHÁ, không hợp
      với truy vấn lặp lại hằng ngày

⚠ Khi nào chuyển sang cách khác:

Chỉ khám phá vài lần
    → EXTERNAL TABLE          ← đề này

Cần bảo mật cấp dòng/cột trên data lake
    → BIGLAKE TABLE

Truy vấn thường xuyên, cần hiệu năng
    → NẠP vào bảng quản lý
        ↓
    ⚠ Ba mức, chọn theo tần suất và
      yêu cầu quản trị

Xem thêm câu #13069 (lô 136): khoá BigLake table vì ở đó cần row-level và column-level security trên data lake. Câu này chỉ cần khám phá nhanh → external table là đủ. Hai khoá khác nhau vì yêu cầu quản trị khác nhau — hoàn toàn nhất quán.

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

• D (bảng quản lý của BigQuery) — đây là phương án gần nhất và cho hiệu năng tốt nhất, nhưng nó đòi NẠP dữ liệu vào BigQuery — trái yêu cầu "không di chuyển dữ liệu, không dựng pipeline".

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

• C (pipeline luồng Dataflow) — quá tay: dựng cả một pipeline cho vài truy vấn khám phá.

Ghi nhớ

⚠ Ba cách để BigQuery đọc dữ liệu trong GCS — bảng phải thuộc: | Cách | Hiệu năng | Bảo mật chi tiết | Dùng khi | |---|---|---|---| | External table | chậm nhất | KHÔNG có | khám phá tuỳ hứng | | BigLake table | trung bình (có cache) | ĐẦY ĐỦ | data lake có quản trị | | Nạp vào bảng quản lý | nhanh nhất | đầy đủ | truy vấn thường xuyên |

Từ khoá nhận diện:

"truy vấn tại chỗ, khám phá nhanh" → external table "data lake + row/column-level security" → BigLake "truy vấn thường xuyên, cần hiệu năng" → nạp vào bảng "nạp theo lịch" → Data Transfer Service "tệp phi cấu trúc: ảnh, video" → object table

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lược đồ đoán được thế nào | bq show --schema --format=prettyjson | | Truy vấn quét bao nhiêu | --dry_run — với external table, ước tính kém chính xác | | Có bao nhiêu tệp | gcloud storage ls gs://bucket/logs/ \| wc -l |

Và một dấu hiệu cho biết đã đến lúc rời khỏi external table: cùng một truy vấn được chạy nhiều lần mỗi ngày. External table sinh ra cho việc nhìn qua dữ liệu lần đầu; khi nó trở thành nguồn của một báo cáo định kỳ, chi phí và độ chậm sẽ vượt xa công sức của một lần nạp vào bảng quản lý.

Đáp án

B — CSV vốn là định dạng PHẲNG và không thể nạp trực tiếp vào BigQuery để tạo ra lược đồ lồng nhau.

Vì sao đúng

CSV không có khái niệm cấu trúc lồng: mỗi dòng là một danh sách giá trị ngăn cách bằng dấu phẩy, không có cách nào diễn đạt một đối tượng con hay một mảng.

⚠ Điểm mấu chốt — giới hạn nằm ở CHÍNH ĐỊNH DẠNG:

CSV
    khach_id,ten,thanh_pho,tuoi
    1,An,Ha Noi,30
        ↓
    ⚠ Không có cú pháp nào để nói
      "ten và thanh_pho thuộc về
       một record tên là khach"
        ↓
    → nạp CSV LUÔN cho ra bảng PHẲNG
    → không cấu hình nào đổi được điều đó

⚠ Ba định dạng hỗ trợ lồng nhau:

JSON (NDJSON)
    {"id":1,"khach":{"ten":"An","tp":"Ha Noi"}}
        ↓
    → BigQuery tạo STRUCT tự động

AVRO
    → lược đồ nhúng, hỗ trợ record lồng

PARQUET / ORC
    → hỗ trợ cấu trúc lồng đầy đủ
        ↓
    ⚠ Ba định dạng này giữ được
      cấu trúc; CSV thì không

⚠ Nếu buộc phải bắt đầu từ CSV — hai cách:

CÁCH 1 — nạp phẳng rồi dựng lại bằng SQL
CREATE TABLE `du_an.bang_long` AS
SELECT
  khach_id,
  STRUCT(ten, thanh_pho, tuoi) AS khach
FROM `du_an.bang_phang`;
        ↓
    → dùng STRUCT() và ARRAY_AGG()

CÁCH 2 — chuyển CSV sang JSON/Avro trước
    → bằng Dataflow, Data Fusion, hoặc script
    → rồi nạp

Xem thêm câu #13063 (lô 136): khoá nạp NDJSON THẲNG vào BigQuery vì định dạng đó hỗ trợ sẵn cấu trúc lồng. Câu này giải thích vì sao CSV KHÔNG làm được. Hai câu là hai mặt của cùng một kiến thức — hoàn toàn nhất quán.

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

• C (quên dùng cờ --autodetect) — đây là phương án gần nhất vì --autodetect thật sự ảnh hưởng tới lược đồ, nhưng nó chỉ đoán KIỂU DỮ LIỆU của các cột phẳng; nó không thể tạo ra cấu trúc lồng từ CSV.

• A (phải dùng BigQuery Data Transfer Service) — DTS không thay đổi được giới hạn của định dạng CSV.

• D (phải chuyển sang XML) — BigQuery KHÔNG hỗ trợ nạp XML; và đây không phải cách giải quyết.

Ghi nhớ

⚠ Định dạng và khả năng lồng nhau — bảng phải thuộc: | Định dạng | Hỗ trợ lồng nhau | Ghi chú | |---|---|---| | CSV | KHÔNG | phẳng hoàn toàn | | JSON (NDJSON) | CÓ | STRUCT và ARRAY | | Avro | CÓ | lược đồ nhúng | | Parquet / ORC | CÓ | theo cột, nén tốt | | XML | — | BigQuery không nạp trực tiếp |

Từ khoá nhận diện:

"CSV cho ra bảng phẳng" → giới hạn của định dạng "muốn lược đồ lồng" → JSON, Avro, Parquet "đã có CSV, muốn lồng" → nạp phẳng rồi STRUCT() "--autodetect" → chỉ đoán KIỂU, không tạo cấu trúc "XML" → BigQuery không hỗ trợ nạp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lược đồ có lồng không | bq show --schema --format=prettyjson — tìm RECORD, REPEATED | | Định dạng nguồn là gì | kiểm tra tệp thật, không tin phần mở rộng | | Có cần lồng không | xem cách truy vấn thực tế |

Và một câu hỏi nên đặt ra trước khi bỏ công dựng cấu trúc lồng: truy vấn thực tế có được lợi từ nó không? Cấu trúc lồng giúp tránh JOIN và rất hiệu quả khi dữ liệu cha–con luôn được đọc cùng nhau — nhưng nếu các báo cáo chủ yếu tổng hợp trên phần cha, một bảng phẳng đơn giản vừa dễ viết vừa dễ hiểu hơn cho cả đội.

Đáp án

D — Xử lý đơn hàng trực tuyến của khách là tác vụ OLTP; phân tích xu hướng doanh số theo quý là tác vụ OLAP.

Vì sao đúng

Hai ví dụ trong đề là hai đại diện kinh điển của hai loại khối lượng công việc hoàn toàn khác nhau.

⚠ Điểm mấu chốt — phân biệt bằng ĐẶC ĐIỂM TRUY VẤN:

OLTP — Online Transaction Processing
        ↓
    "Xử lý một đơn hàng"
        ↓
    - RẤT NHIỀU giao dịch NHỎ
    - đọc/ghi VÀI DÒNG
    - độ trễ mili giây
    - nhất quán mạnh, có khoá
    - tối ưu cho GHI
        ↓
    → Cloud SQL, Spanner, AlloyDB

OLAP — Online Analytical Processing
        ↓
    "Phân tích xu hướng doanh số quý"
        ↓
    - ÍT truy vấn, mỗi truy vấn QUÉT RẤT NHIỀU
    - tổng hợp hàng triệu tới hàng tỉ dòng
    - lưu theo CỘT
    - tối ưu cho ĐỌC PHÂN TÍCH
        ↓
    → BigQuery

⚠ Vì sao phải tách hai loại này ra hai hệ thống:

Chạy truy vấn phân tích trên CSDL giao dịch
        ↓
    ⚠ Quét bảng lớn → dùng hết CPU và I/O
    ⚠ Tranh chấp khoá với ứng dụng
    ⚠ Khách hàng thấy ứng dụng chậm đi
        ↓
    → tách sang kho phân tích riêng
    → nối bằng Datastream hoặc federated query

⚠ Bảng so sánh nhanh:

                OLTP            OLAP
Số truy vấn     rất nhiều       ít
Dữ liệu/truy vấn vài dòng       hàng triệu dòng
Lưu trữ         theo DÒNG       theo CỘT
Mô hình         chuẩn hoá       phi chuẩn hoá
Tối ưu cho      GHI             ĐỌC
Ví dụ           đặt hàng        báo cáo quý

Xem thêm câu #13057 (lô 136): ánh xạ giao dịch → Cloud SQL, phân tích → BigQuery. Và #13062 (lô 136): data warehouse cho phân tích. Ba câu nhất quán, cùng một nguyên tắc tách OLTP khỏi OLAP.

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

• A (đảo ngược hai vế) — đây là phương án gần nhất vì dùng đúng hai thuật ngữ, nhưng gán nhầm: xử lý đơn hàng là OLTP, phân tích xu hướng là OLAP.

• B (cả hai đều là OLTP) và C (cả hai đều là OLAP) — gộp hai loại khác hẳn nhau vào một; sai về bản chất.

Ghi nhớ

⚠ OLTP ↔ OLAP — bảng phải thuộc: | | OLTP | OLAP | |---|---|---| | Mục đích | vận hành nghiệp vụ | phân tích, ra quyết định | | Truy vấn | nhiều, nhỏ, nhanh | ít, lớn, quét nhiều | | Lưu trữ | theo DÒNG | theo CỘT | | Mô hình dữ liệu | chuẩn hoá | phi chuẩn hoá, star schema | | Tối ưu cho | GHI | ĐỌC | | Trên GCP | Cloud SQL, Spanner, AlloyDB | BigQuery |

Từ khoá nhận diện:

"đặt hàng, thanh toán, cập nhật hồ sơ" → OLTP "báo cáo, xu hướng, tổng hợp theo quý" → OLAP "vài dòng, độ trễ mili giây" → OLTP "quét hàng tỉ dòng" → OLAP "chạy báo cáo trên CSDL sản xuất" → dấu hiệu sai kiến trúc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | CSDL giao dịch có bị dùng để phân tích không | xem truy vấn chậm trong log | | BigQuery có bị dùng cho tra cứu điểm không | xem truy vấn WHERE id = ... chạy liên tục | | Độ trễ đồng bộ giữa hai hệ thống | chỉ số của Datastream |

Và một câu hỏi rất hữu ích khi rà soát kiến trúc dữ liệu của một hệ thống đang chạy: báo cáo lấy dữ liệu từ đâu? Nếu câu trả lời là "từ CSDL của ứng dụng", bạn vừa tìm ra nguyên nhân của phần lớn những lần hệ thống chậm bất thường — và cách chữa là tách sang kho phân tích, không phải mua thêm CPU.

Đáp án

B — Truy vấn dữ liệu trong BigQuery Studio và trực quan hoá bằng Looker Studio.

Vì sao đúng

Đề nêu bốn yêu cầu: công cụ tự phục vụ cho lãnh đạo, dashboard TRỰC TIẾP và TƯƠNG TÁC, có bộ lọc để đi sâu theo vùng và danh mục, và KHÔNG viết mã. Cặp BigQuery + Looker Studio là quy trình chuẩn.

⚠ Điểm mấu chốt — mỗi công cụ một vai trò:

BIGQUERY (Studio)
    → nơi DỮ LIỆU nằm
    → nơi viết truy vấn, dựng bảng tổng hợp
        ↓
LOOKER STUDIO
    → nơi TRỰC QUAN HOÁ
    → kéo thả tạo biểu đồ
    → bộ lọc, drill-down, chia sẻ
        ↓
    ⚠ Lãnh đạo chỉ chạm vào Looker Studio
    ⚠ Không cần biết SQL

⚠ Bộ lọc và drill-down trong Looker Studio:

Filter control
    → hộp chọn vùng, danh mục sản phẩm
    → áp cho toàn trang hoặc từng biểu đồ

Drill down
    → khai cấp phân cấp: vùng → tỉnh → cửa hàng
    → người xem bấm để đi sâu

Date range control
    → chọn khoảng thời gian
        ↓
    ⚠ Tất cả cấu hình bằng giao diện,
      không viết mã

⚠ Điều phải chú ý về CHI PHÍ:

Mỗi lần làm mới biểu đồ
    = một TRUY VẤN BigQuery
        ↓
    Dashboard 10 biểu đồ × nhiều người xem
    × nhiều lần mỗi ngày
        ↓
    ⚠ Hoá đơn có thể lớn
        ↓
    Cách giảm:
      - BẬT CACHE của Looker Studio
      - dựng BẢNG TỔNG HỢP nhỏ để đọc
      - BI Engine
      - đặt maximum_bytes_billed

Xem thêm câu #12947 (lô 134): cùng khoá Looker Studio cho dashboard miễn phí, kéo thả. Và #13045 (lô 136): phân biệt xem trực tiếp với gửi báo cáo theo lịch trong Looker. Ba câu nhất quán.

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

• C (xuất dữ liệu BigQuery sang Google Sheets để vẽ biểu đồ) — đây là phương án gần nhất vì cũng cho ra biểu đồ, nhưng nó tạo bản sao tĩnh, không tự cập nhật, và giới hạn số ô của Sheets. (Connected Sheets thì khác — nhưng vẫn không phải dashboard tương tác cho lãnh đạo.)

• D (viết script Python trong Colab tạo báo cáo HTML tĩnh) — cần viết mã và cho ra báo cáo TĨNH, không tương tác.

• A (Cloud Function gửi email tóm tắt hằng ngày) — không phải dashboard, không tương tác, không lọc được.

Ghi nhớ

⚠ Chọn công cụ theo người dùng và nhu cầu — bảng phải thuộc: | Người dùng và nhu cầu | Công cụ | |---|---| | Lãnh đạo, dashboard tương tác, miễn phí | Looker Studio | | Doanh nghiệp, chỉ số thống nhất, quản trị | Looker | | Nhà phân tích, khám phá bằng SQL | BigQuery Studio | | Nhà khoa học dữ liệu, Python | Colab Enterprise | | Người quen bảng tính | Connected Sheets |

Từ khoá nhận diện:

"dashboard tương tác, không cần mã, miễn phí" → Looker Studio "chỉ số thống nhất toàn công ty, LookML" → Looker "khám phá bằng SQL" → BigQuery Studio "báo cáo có mã và diễn giải" → notebook "gửi email tóm tắt" → không phải dashboard

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dashboard tốn bao nhiêu | INFORMATION_SCHEMA.JOBS, lọc theo nhãn Looker Studio | | Cache có hoạt động không | làm mới nhiều lần, xem số job phát sinh | | Ai xem được báo cáo | menu chia sẻ của chính báo cáo |

Và một bước nên làm trước khi mở dashboard cho ban lãnh đạo: dựng một bảng tổng hợp nhỏ để báo cáo đọc, thay vì trỏ thẳng vào bảng giao dịch nhiều terabyte. Mỗi bộ lọc mà lãnh đạo bấm sẽ sinh một truy vấn mới — và với một bảng tổng hợp vài trăm nghìn dòng, chi phí đó gần như bằng không thay vì tăng theo mỗi lượt xem.

Đáp án

B — Đặt partition expiration 1095 ngày cho bảng.

Vì sao đúng

Yêu cầu là xoá dữ liệu đúng 3 năm sau khi phát sinh, tự động, không cần can thiệp thủ công. BigQuery có sẵn cơ chế xoá phân vùng theo tuổi.

⚠ Điểm mấu chốt — một dòng cấu hình, chạy mãi:

ALTER TABLE `du_an.user_activity`
SET OPTIONS (
  partition_expiration_days = 1095
);

        ↓
    BigQuery TỰ XOÁ mọi phân vùng
    quá 1095 ngày
        ↓
    ⚠ Không có job nào phải chạy
    ⚠ Không có mã nào phải bảo trì
    ⚠ Không có gì để quên

⚠ Vì sao xoá theo PHÂN VÙNG rẻ hơn DELETE:

DELETE FROM ... WHERE ngay < ...
        ↓
    → là thao tác DML
    → phải QUÉT dữ liệu để tìm dòng cần xoá
    → TỐN TIỀN theo byte quét
    → chậm với bảng lớn

XOÁ PHÂN VÙNG
        ↓
    → bỏ đi cả một khối siêu dữ liệu
    → gần như tức thì
    → MIỄN PHÍ

⚠ Điều kiện tiên quyết — bảng phải PHÂN VÙNG:

Không phân vùng
        ↓
    ⚠ KHÔNG có partition expiration
    → buộc phải DELETE thủ công
        ↓
    Vì vậy bảng log nên:
      PARTITION BY DATE(thoi_diem)
      OPTIONS(partition_expiration_days = 1095)
        ↓
    ⚠ Khai ngay khi TẠO bảng

Xem thêm câu #13039 (lô 136): cùng tình huống xoá tự động, cùng khoá partition expiration (48 tháng). Và #13044 (lô 136): nêu chính điều kiện tiên quyết là phân vùng. Ba câu hoàn toàn nhất quán.

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

• D (scheduled query chạy DELETE hằng ngày) — đây là phương án gần nhất và cũng tự động, nhưng nó tốn tiền theo byte quét mỗi ngày, chậm hơn, và thêm một thứ phải theo dõi khi hỏng.

• C (Cloud Function xoá dòng cũ) — phải viết mã, phải xử lý lỗi và phân trang; nhiều công hơn hẳn.

• A (pipeline Dataflow ghi lại bảng) — cực kỳ tốn kém cho một việc mà một dòng cấu hình làm được.

Ghi nhớ

⚠ Vòng đời dữ liệu trong BigQuery — bảng phải thuộc: | Cơ chế | Việc | |---|---| | partition_expiration_days | tự XOÁ phân vùng quá tuổi | | expiration_timestamp của bảng | xoá cả BẢNG vào thời điểm định trước | | default_partition_expiration_days của dataset | áp cho bảng mới | | Long-term storage | tự giảm ~50% GIÁ, không xoá | | bq extract + xoá | giữ bản sao ở GCS | | Time travel | khôi phục trong 7 ngày |

Từ khoá nhận diện:

"xoá tự động sau N ngày" → partition expiration "giữ N năm để tuân thủ" → GCS Archive + retention policy "giảm chi phí dữ liệu cũ, vẫn truy vấn được" → long-term storage (tự động) "DELETE hằng ngày" → tốn kém, không phải cách tốt nhất "Dataflow ghi lại bảng" → quá tay

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách đã đặt chưa | bq show --format=prettyjson <bảng> → partitionExpirationMs | | Dữ liệu cũ nhất còn lại | SELECT MIN(thoi_diem) FROM ... | | Có bảng nào giữ dữ liệu cũ không | rà soát bảng tổng hợp và bản sao |

Và một chỗ rất hay bị bỏ sót khi thực thi yêu cầu pháp lý về xoá dữ liệu: các bảng phái sinh. Bảng gốc được dọn đúng hạn, nhưng bảng tổng hợp, bảng staging và bản sao tạo ra từ nó vẫn giữ nguyên dữ liệu cũ — nên hãy lập bản đồ toàn bộ đường đi của dữ liệu trước khi báo cáo rằng chính sách đã được thực thi.

Đáp án

D — Cloud Data Fusion.

Vì sao đúng

Đề nêu rõ thách thức chính là độ phức tạp của việc KẾT NỐI tới các hệ thống rất khác nhau (Oracle tại chỗ, Salesforce, SAP), và đội muốn trình kết nối DỰNG SẴN, ĐÃ CHỨNG NHẬN để rút ngắn thời gian tích hợp.

⚠ Điểm mấu chốt — giá trị nằm ở PLUGIN dựng sẵn:

Cloud Data Fusion
        ↓
    Hơn 150 PLUGIN dựng sẵn, gồm:
      - JDBC (Oracle, SQL Server, MySQL...)
      - Salesforce
      - SAP (bộ plugin chứng nhận riêng)
      - ServiceNow, Workday, Marketo
      - Kafka, S3, Azure Blob
        ↓
    ⚠ Không phải tự viết mã gọi API
    ⚠ Không phải tự lo OAuth, phân trang,
      giới hạn tần suất, ánh xạ kiểu

⚠ Vì sao SAP và Salesforce là từ khoá quyết định:

SAP và Salesforce
        ↓
    API rất phức tạp, có đặc thù riêng
        ↓
    Tự viết pipeline
      → hàng tuần tới hàng tháng
      → và phải bảo trì khi API đổi

    Plugin chứng nhận
      → cấu hình vài trường là chạy
        ↓
    ⚠ Đây chính là "rút ngắn quá trình
      tích hợp" mà đề nói tới

⚠ Vì sao Dataflow không phải câu trả lời ở đây:

Dataflow
        ↓
    Rất mạnh, nhưng phải VIẾT MÃ Beam
        ↓
    ⚠ Kết nối tới SAP, Salesforce
      → phải tự viết I/O connector
      → hoặc dùng thư viện bên thứ ba
        ↓
    → không giải quyết được
      "thách thức chính" của đề

Xem thêm câu #13012 và #13021 (lô 135), #13020 (lô 135): cùng khoá Cloud Data Fusion, cùng lý do plugin dựng sẵn và không cần lập trình. Bốn câu hoàn toàn nhất quán. Và #13038 (lô 136): nêu tiêu chí phân biệt với Dataflow.

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

• B (Dataflow) — đây là phương án gần nhất về năng lực xử lý, nhưng nó đòi viết mã Beam và không có trình kết nối chứng nhận cho SAP hay Salesforce — đúng thách thức mà đề nêu.

• C (Cloud Functions) — chạy đoạn mã ngắn; tích hợp ba hệ thống doanh nghiệp bằng hàm là tự viết lại toàn bộ.

• A (BigQuery) — là kho dữ liệu ĐÍCH, không phải công cụ kết nối và tích hợp.

Ghi nhớ

⚠ Chọn công cụ theo THÁCH THỨC CHÍNH — bảng phải thuộc: | Thách thức chính | Công cụ | |---|---| | Kết nối tới nhiều hệ thống lạ | Cloud Data Fusion (plugin sẵn) | | Logic biến đổi phức tạp, có kỹ sư | Dataflow | | Đã có mã Spark | Dataproc | | Chỉ biến đổi SQL trong BigQuery | Dataform | | Nguồn SaaS của Google → BigQuery | BigQuery Data Transfer Service | | CSDL → Cloud SQL | Database Migration Service |

Từ khoá nhận diện:

"nhiều nguồn khác nhau, cần trình kết nối sẵn" → Cloud Data Fusion "SAP, Salesforce, ServiceNow" → plugin chứng nhận của Data Fusion "logic tuỳ biến phức tạp" → Dataflow "Google Ads → BigQuery" → Data Transfer Service "Oracle → Cloud SQL" → DMS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nguồn có plugin sẵn không | Data Fusion Hub | | Pipeline chạy có lỗi không | Pipeline runs trong giao diện | | Nguồn có bị ảnh hưởng không | theo dõi tải trên Oracle và giới hạn API của SaaS |

Và một khoản công sức thường bị đánh giá thấp khi tích hợp SAP hay Salesforce: phần cấu hình ở PHÍA HỆ THỐNG NGUỒN. Plugin của Data Fusion lo phần kết nối, nhưng bạn vẫn cần quyền phù hợp, đôi khi cần cài thành phần phụ trên SAP, và cần đội quản trị hệ thống đó phối hợp — hãy đưa việc đó vào kế hoạch từ đầu thay vì coi là chi tiết kỹ thuật nhỏ.

Đáp án

A — Tạo một Signed URL cho đối tượng đó.

Vì sao đúng

Đề nêu bốn điều: quyền TẠM THỜI, có giới hạn thời gian, chỉ đọc, cho một đối tượng cụ thể, KHÔNG đổi chính sách IAM, và người nhận tải trực tiếp từ trình duyệt. Signed URL làm đúng cả năm.

⚠ Điểm mấu chốt — URL mang sẵn chữ ký và hạn dùng:

gcloud storage sign-url gs://bucket/tep.pdf \
  --duration=1h \
  --private-key-file=key.json
        ↓
    Sinh ra một URL dài chứa:
      - đường dẫn đối tượng
      - thời điểm HẾT HẠN
      - CHỮ KÝ mã hoá
        ↓
    ⚠ Ai có URL đều tải được
    ⚠ Hết hạn thì URL vô hiệu
    ⚠ KHÔNG đụng tới IAM
    ⚠ Người nhận KHÔNG cần tài khoản Google

⚠ Vì sao cấp IAM role là không phù hợp ở đây:

Cấp roles/storage.objectViewer
        ↓
    ⚠ Khách hàng phải CÓ TÀI KHOẢN GOOGLE
    ⚠ Quyền TỒN TẠI VĨNH VIỄN tới khi thu hồi
    ⚠ Phải nhớ gỡ quyền sau đó
    ⚠ Áp cho cả bucket hoặc phải cấu hình riêng
        ↓
    → trái yêu cầu "tạm thời, không đổi IAM"

⚠ Vì sao "công khai đối tượng" là sai nghiêm trọng:

Đặt allUsers:objectViewer
        ↓
    ⚠ AI TRÊN INTERNET cũng tải được
    ⚠ Có thể bị lập chỉ mục bởi công cụ tìm kiếm
    ⚠ Không có hạn dùng
    ⚠ Không biết ai đã tải
        ↓
    → lỗ hổng bảo mật, không phải giải pháp

Xem thêm câu #12937 (lô 134): về uniform bucket-level access. Signed URL hoạt động bình thường với uniform access, vì nó không phải ACL — đây là lý do nó là cách chia sẻ đúng đắn khi đã tắt ACL từng đối tượng.

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

• B (cấp Storage Object Viewer cho tài khoản khách hàng) — đây là phương án gần nhất và đúng về mặt quyền đọc, nhưng nó đổi chính sách IAM (trái yêu cầu), không tự hết hạn, và đòi khách hàng có tài khoản Google.

• C (đặt đối tượng thành công khai) — lỗ hổng bảo mật: ai cũng truy cập được, vô thời hạn.

• D (chuyển đối tượng sang bucket công khai) — cũng công khai, và còn phải di chuyển dữ liệu.

Ghi nhớ

⚠ Các cách chia sẻ đối tượng trong Cloud Storage — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Signed URL | tạm thời, có hạn, KHÔNG cần tài khoản Google | | Signed policy document | cho phép TẢI LÊN có kiểm soát | | IAM role | lâu dài, cần tài khoản Google | | IAM condition | quyền có điều kiện thời gian hoặc tiền tố | | allUsers | CÔNG KHAI — rất cẩn thận | | Cloud CDN + signed cookie | nhiều đối tượng, một phiên |

Từ khoá nhận diện:

"tạm thời, có hạn, không đổi IAM" → Signed URL "cho phép tải LÊN" → signed policy document "nhiều tệp trong một phiên" → signed cookie "lâu dài, người trong tổ chức" → IAM role "công khai cho tiện" → luôn là phương án SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | URL còn hạn không | tham số X-Goog-Expires trong URL | | Ai đã tải tệp | Data Access audit log của bucket | | Bucket có công khai không | get-iam-policy, tìm allUsers |

Và một tham số nên đặt cẩn thận hơn người ta thường làm: thời hạn của Signed URL. Vì không thu hồi được trước khi hết hạn, một URL bảy ngày cho một tệp nhạy cảm nghĩa là bảy ngày bạn không kiểm soát được ai đang giữ nó — hãy đặt đủ dùng cho lần tải đó, thường là vài giờ, chứ không phải mức tối đa.