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

Đáp án

C — bq load my_dataset.my_table my_file.csv

Vì sao đúng

Đề nêu ba điều kiện: tệp CSV nằm trên máy cục bộ, dùng công cụ dòng lệnh, và nạp trực tiếp nhất có thể. bq load nạp thẳng từ máy vào BigQuery, không qua bước trung gian nào.

⚠ Điểm mấu chốt — bq load nhận cả đường dẫn cục bộ:

bq load \
  --source_format=CSV \
  --autodetect \
  --skip_leading_rows=1 \
  my_dataset.my_table \
  my_file.csv
        ↓
    Nguồn là ĐƯỜNG DẪN TRÊN MÁY
    → không cần đưa lên Cloud Storage trước
        ↓
    100 MB nằm trong giới hạn nạp cục bộ

⚠ Khi nào thì phải qua Cloud Storage:

Tệp CỤC BỘ
    → bq load trực tiếp
    → giới hạn kích thước, chậm hơn với file to

Tệp LỚN, hoặc nạp NHIỀU LẦN
    → tải lên Cloud Storage trước
    → bq load ... gs://bucket/file.csv
    → nhanh hơn, song song hơn, có thể dùng
      ký tự đại diện gs://bucket/prefix-*.csv
        ↓
    Đề nói "MỘT LẦN" và "trực tiếp nhất"
    → nạp thẳng

⚠ Các cờ hay dùng của bq load:

--autodetect            tự đoán lược đồ
--skip_leading_rows=1   bỏ dòng tiêu đề
--source_format=CSV|NEWLINE_DELIMITED_JSON|
                PARQUET|AVRO|ORC
--replace               ghi đè bảng
--time_partitioning_field=ngay
--max_bad_records=10

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

• A (gcloud storage cp my_file.csv gs://my-bucket) — đây là phương án gần nhất và là bước đầu của cách đi vòng, nhưng nó chỉ tải tệp lên Cloud Storage, chưa hề nạp gì vào BigQuery. Vẫn cần thêm một lệnh bq load nữa — nên không phải "trực tiếp nhất".

• B (bq query 'SELECT * FROM my_file.csv') — BigQuery không truy vấn được tệp trên máy cục bộ. Muốn truy vấn tệp tại chỗ thì phải là bảng ngoài (external table) trỏ vào Cloud Storage.

• D (gcloud dataflow jobs run my_job) — Dataflow là quá nặng cho một lần nạp 100 MB, và lệnh này cần một template có sẵn.

Ghi nhớ

⚠ Các cách đưa dữ liệu vào BigQuery — bảng phải thuộc: | Cách | Dùng khi | |---|---| | bq load từ tệp cục bộ | nạp một lần, tệp nhỏ | | bq load từ gs:// | tệp lớn, nạp lặp lại, nhiều tệp | | BigQuery Data Transfer Service | nạp theo lịch từ nguồn có sẵn | | Storage Write API | nạp luồng, thời gian thực | | Dataflow | cần biến đổi phức tạp | | External table | truy vấn tại chỗ, không nạp |

Từ khoá nhận diện:

"nạp tệp cục bộ, một lần, dòng lệnh" → bq load "nạp theo lịch từ Google Ads, S3..." → Data Transfer Service "dữ liệu luồng thời gian thực" → Storage Write API hoặc Dataflow "truy vấn tệp mà không nạp" → external table "biến đổi phức tạp trên đường nạp" → Dataflow

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng đã có dữ liệu chưa | bq show my_dataset.my_table → Num Rows | | Lược đồ đúng chưa | bq show --schema --format=prettyjson | | Job nạp có lỗi gì | bq show -j <job_id> |

Và một thói quen đáng có với mọi lần nạp CSV: đừng tin --autodetect với dữ liệu định danh. Mã khách hàng, mã bưu chính, số điện thoại — những cột trông như số nhưng thực chất là chuỗi — rất hay bị đoán thành INTEGER, và số 0 ở đầu biến mất lặng lẽ. Khai lược đồ tường minh mất thêm vài phút, nhưng nó tránh được một lớp lỗi dữ liệu mà về sau rất khó truy ngược.

Đáp án

B — Cloud Storage và một Cloud Run function.

Vì sao đúng

Đề mô tả đúng khuôn mẫu sự kiện → hàm nhỏ: tệp .txt được tải lên thì chạy một đoạn mã ngắn đọc nội dung và ghi vào Cloud Logging. Đây là bài toán mẫu của hàm không máy chủ.

⚠ Điểm mấu chốt — luồng sự kiện:

Tải file .txt lên bucket
        ↓
    Cloud Storage phát sự kiện
    google.cloud.storage.object.v1.finalized
        ↓
    Eventarc chuyển tới
        ↓
    Cloud Run function
        ↓
    Đọc nội dung, ghi ra Cloud Logging
        ↓
    ⚠ Không có máy chủ nào phải nuôi
    ⚠ Không có request thì KHÔNG TÍNH TIỀN

⚠ Triển khai:

gcloud functions deploy xu-ly-txt \
  --gen2 --runtime=python312 \
  --region=asia-southeast1 \
  --trigger-event-filters="type=google.cloud.storage.object.v1.finalized" \
  --trigger-event-filters="bucket=ten-bucket" \
  --entry-point=xu_ly
        ↓
    Trong hàm: lọc theo đuôi .txt
    (bộ lọc trigger không lọc theo đuôi tệp)

⚠ Vì sao ba phương án kia đều "quá tay":

VM luôn chạy
    → trả tiền 24/7 cho việc thỉnh thoảng mới xảy ra
    → phải tự vá, tự giám sát

Cloud Composer
    → điều phối luồng công việc PHỨC TẠP
    → chi phí nền RẤT LỚN cho một tác vụ nhỏ

BigQuery
    → kho dữ liệu phân tích
    → không phải nơi chạy mã theo sự kiện

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

• C (Cloud Composer) — đây là phương án gần nhất về mặt "tự động hoá", nhưng Composer là Airflow được quản lý, dành cho điều phối luồng công việc nhiều bước có phụ thuộc. Nó chạy một môi trường thường trực, chi phí nền lớn hơn nhiều lần công việc này.

• A (VM thường trực) — ngược hẳn yêu cầu "không máy chủ": trả tiền liên tục, phải tự vận hành.

• D (BigQuery) — là kho phân tích, không phải nơi chạy mã phản ứng theo sự kiện.

Ghi nhớ

⚠ Chọn công cụ tự động hoá theo độ phức tạp — bảng phải thuộc: | Nhu cầu | Công cụ | |---|---| | Một đoạn mã nhỏ phản ứng theo sự kiện | Cloud Run function | | Dịch vụ container, xử lý dài hơn | Cloud Run | | Nhiều bước có phụ thuộc, cần điều phối | Cloud Composer (Airflow) | | Luồng nhẹ, ít bước, không cần Airflow | Workflows | | Chạy theo lịch đơn giản | Cloud Scheduler | | Xử lý dữ liệu quy mô lớn | Dataflow |

Từ khoá nhận diện:

"file lên bucket thì chạy đoạn mã nhỏ" → Cloud Run function "nhiều bước, phụ thuộc lẫn nhau, DAG" → Cloud Composer "điều phối nhẹ, gọi vài API" → Workflows "chạy đúng giờ mỗi ngày" → Cloud Scheduler "biến đổi dữ liệu luồng lớn" → Dataflow

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàm có được gọi không | Logs Explorer, lọc theo tên hàm | | Trigger cấu hình đúng chưa | gcloud functions describe <ten> --gen2 | | Có bị gọi lặp không | đếm số lần gọi trên một tệp trong log |

Và một cái bẫy khiến hoá đơn tăng vọt trong im lặng: hàm ghi kết quả trở lại chính bucket đã kích hoạt nó. Mỗi lần ghi lại phát ra một sự kiện finalized mới, gọi lại chính hàm đó, và vòng lặp chạy cho tới khi ai đó nhận ra. Luôn ghi kết quả sang bucket khác, hoặc kiểm tra tiền tố ngay ở dòng đầu của hàm.

Đáp án

D — ETL (Extract, Transform, Load — trích xuất, biến đổi, nạp).

Vì sao đúng

Chính sách trong đề nói rõ: PII phải được che TRƯỚC KHI nạp vào BigQuery. Thứ tự "biến đổi trước, nạp sau" chính là định nghĩa của ETL.

⚠ Điểm mấu chốt — thứ tự các chữ cái chính là câu trả lời:

ETL = Extract → Transform → LOAD
        ↓
    Trích xuất từ CSDL tại chỗ
        ↓
    CHE PII (transform)         ← xảy ra TRƯỚC
        ↓
    Nạp vào BigQuery
        ↓
    ⚠ Dữ liệu nhạy cảm CHƯA BAO GIỜ
      chạm tới kho đích

ELT = Extract → LOAD → Transform
        ↓
    Nạp dữ liệu THÔ vào kho trước
        ↓
    ⚠ PII đã nằm trong BigQuery rồi
    → VI PHẠM chính sách trong đề

⚠ Vì sao ELT phổ biến hơn nhưng vẫn không dùng được ở đây:

ELT hợp thời vì kho hiện đại rất mạnh
        ↓
    BigQuery biến đổi nhanh và rẻ
    Giữ được dữ liệu thô để làm lại
        ↓
    NHƯNG:
    ELT đòi hỏi dữ liệu THÔ được phép
    nằm trong kho
        ↓
    ⚠ Đề nói PII KHÔNG ĐƯỢC vào kho
    → bắt buộc ETL

⚠ Công cụ thực hiện ETL trên Google Cloud:

Dataflow          → biến đổi luồng và theo lô
Cloud Data Fusion → giao diện kéo thả, không cần lập trình
Dataproc          → Spark/Hadoop
Datastream + Dataflow → CDC từ CSDL tại chỗ
Cloud DLP (Sensitive Data Protection)
                  → PHÁT HIỆN và CHE PII

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

• A (ELT) — đây là phương án gần nhất và là kiểu kiến trúc rất phổ biến với BigQuery, nhưng nó nạp dữ liệu THÔ vào kho trước rồi mới biến đổi — nghĩa là PII đã vào BigQuery, vi phạm chính sách.

• B (Data Virtualization) — truy vấn dữ liệu tại nguồn mà không di chuyển nó; đề rõ ràng có bước nạp vào BigQuery.

• C (Reverse ETL) — đưa dữ liệu TỪ kho NGƯỢC RA các hệ thống nghiệp vụ (CRM, công cụ marketing). Hướng ngược với đề.

Ghi nhớ

⚠ Bốn kiểu luồng dữ liệu — bảng phải thuộc: | Kiểu | Thứ tự | Dùng khi | |---|---|---| | ETL | trích xuất → BIẾN ĐỔI → nạp | phải làm sạch/che PII trước khi vào kho | | ELT | trích xuất → nạp → biến đổi | kho mạnh, muốn giữ dữ liệu thô | | Reverse ETL | kho → hệ thống nghiệp vụ | đẩy phân khúc khách hàng sang CRM | | Data Virtualization | truy vấn tại nguồn | không muốn sao chép dữ liệu |

Từ khoá nhận diện:

"che/làm sạch TRƯỚC KHI nạp" → ETL "nạp thô rồi biến đổi trong kho" → ELT "đưa dữ liệu từ kho ra CRM" → Reverse ETL "không di chuyển dữ liệu" → data virtualization, hoặc BigQuery external table / BigLake "phát hiện PII tự động" → Sensitive Data Protection (Cloud DLP)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kho có còn PII không | quét bằng Sensitive Data Protection | | Bước che có chạy không | log của Dataflow / Data Fusion | | Ai xem được cột nhạy cảm | policy tag và IAM của BigQuery |

Và một điều nên cân nhắc khi thiết kế theo ETL vì lý do tuân thủ: hãy giữ lại dữ liệu thô ở một nơi có kiểm soát chặt — một bucket riêng, mã hoá bằng khoá của bạn, quyền truy cập rất hẹp. ETL bảo vệ kho, nhưng nếu logic che bị lỗi và bạn không còn nguồn để chạy lại, việc sửa sẽ phải bắt đầu bằng một lần trích xuất mới từ hệ thống tại chỗ.

Đáp án

C — Cloud SQL for MySQL.

Vì sao đúng

Đề hỏi "tương đương trực tiếp nhất của một CSDL MySQL tại chỗ", kèm ba ràng buộc: giao dịch, độ trễ thấp, được quản lý hoàn toàn. Cloud SQL for MySQL đúng nghĩa là MySQL do Google vận hành.

⚠ Điểm mấu chốt — cùng một động cơ, khác người vận hành:

MySQL tại chỗ
        ↓
    Bạn lo: máy chủ, hệ điều hành, vá lỗi,
             sao lưu, nhân bản, chuyển đổi dự phòng

Cloud SQL for MySQL
        ↓
    CHÍNH LÀ MySQL — cùng giao thức,
    cùng SQL, cùng trình điều khiển
        ↓
    Google lo: hạ tầng, vá lỗi, sao lưu,
                HA, nhân bản
        ↓
    → ứng dụng thường CHỈ CẦN ĐỔI CHUỖI KẾT NỐI

⚠ Vì sao đây là kiểu chuyển đổi ít rủi ro nhất:

"Lift and shift" ở tầng dữ liệu
        ↓
    Không đổi mô hình dữ liệu
    Không viết lại truy vấn
    Không đổi thư viện kết nối
        ↓
    → dùng Database Migration Service
      chuyển với thời gian ngừng rất ngắn

⚠ Vì sao KHÔNG chọn Spanner ở câu này:

Spanner cũng có giao dịch và nhất quán mạnh
        ↓
    Nhưng nó KHÔNG phải MySQL:
      - động cơ riêng của Google
      - phải chỉnh lược đồ và truy vấn
      - chi phí tối thiểu cao hơn nhiều
        ↓
    Đề hỏi "TƯƠNG ĐƯƠNG TRỰC TIẾP"
    và "giảm công vận hành"
        ↓
    → Cloud SQL

Xem thêm câu #12563 (cùng lô): ở đó khoá là Cloud Spanner vì đề yêu cầu người dùng ở NHIỀU REGION và nhất quán mọi lúc. Câu này không có ràng buộc đa Region, lại nhấn mạnh "tương đương trực tiếp của MySQL". Hai khoá khác nhau vì ràng buộc khác nhau, không mâu thuẫn.

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

• D (Cloud Spanner) — đây là phương án gần nhất và thoả được yêu cầu giao dịch, nhưng nó không phải MySQL: phải chỉnh lược đồ, chỉnh truy vấn, và chi phí tối thiểu cao hơn nhiều. Chỉ chọn khi cần quy mô toàn cầu.

• A (BigQuery) — kho dữ liệu PHÂN TÍCH, không phục vụ giao dịch độ trễ thấp.

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

Ghi nhớ

⚠ Chọn CSDL trên Google Cloud — bảng phải thuộc: | Nhu cầu | Dịch vụ | |---|---| | MySQL / PostgreSQL / SQL Server tại chỗ chuyển lên | Cloud SQL | | PostgreSQL hiệu năng cao, một Region | AlloyDB | | Quan hệ, NHIỀU REGION, nhất quán mạnh | Cloud Spanner | | NoSQL tài liệu, ứng dụng di động, thời gian thực | Firestore | | NoSQL khoá-giá trị, ghi cực lớn, chuỗi thời gian | Bigtable | | Phân tích, kho dữ liệu | BigQuery | | Bộ nhớ đệm | Memorystore (Redis, Valkey) |

Từ khoá nhận diện:

"tương đương trực tiếp của MySQL tại chỗ" → Cloud SQL for MySQL "nhiều Region + nhất quán mọi lúc" → Cloud Spanner "phân tích hàng tỉ dòng" → BigQuery "ứng dụng di động, đồng bộ thời gian thực" → Firestore "IoT, chuỗi thời gian, ghi hàng triệu điểm/giây" → Bigtable

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance có bật HA không | gcloud sql instances describe <ten> → availabilityType: REGIONAL | | Có replica nào | cùng lệnh trên → replicaNames | | Sao lưu và PITR | → backupConfiguration.pointInTimeRecoveryEnabled |

Và một cấu hình rất nên bật ngay từ đầu với CSDL sản xuất: point-in-time recovery. Sao lưu hằng ngày chỉ đưa bạn về mốc gần nhất, còn PITR cho phép quay về đúng thời điểm trước một lệnh DELETE chạy nhầm — và loại sự cố đó xảy ra thường xuyên hơn sự cố phần cứng rất nhiều.

Đáp án

B — Cloud Data Fusion.

Vì sao đúng

Đề nêu ba đặc điểm của đội: giỏi SQL, không thạo Java hay Python, và cần giao diện đồ hoạ không phải viết mã để dựng, xem và chạy luồng ETL. Cloud Data Fusion sinh ra đúng cho nhóm người này.

⚠ Điểm mấu chốt — kéo thả thay vì viết mã:

Cloud Data Fusion
        ↓
    Giao diện WEB kéo thả
        ↓
    Kéo các "node":
      Nguồn → Wrangler → Biến đổi → Đích
        ↓
    Xem trực quan toàn bộ luồng
    Xem trước dữ liệu ở từng bước
        ↓
    ⚠ KHÔNG cần viết Java hay Python

⚠ Wrangler — thứ khiến người giỏi SQL thấy quen:

Nạp mẫu dữ liệu lên
        ↓
    Bấm vào cột để:
      tách, gộp, đổi kiểu,
      lọc, chuẩn hoá, che dữ liệu
        ↓
    Mỗi thao tác thành một BƯỚC trong công thức
        ↓
    → giống thao tác trên bảng tính
    → nhưng chạy được ở quy mô lớn

⚠ Bên dưới vẫn là hạ tầng thật:

Data Fusion (giao diện, dựa trên CDAP)
        ↓
    Sinh ra pipeline
        ↓
    Chạy trên DATAPROC (Spark) tạm thời
        ↓
    → đội không cần biết Spark
    → nhưng vẫn có quy mô của Spark
        ↓
    ⚠ Có chi phí instance thường trực
      của chính Data Fusion

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

• D (Dataflow) — đây là phương án gần nhất về mục đích (đều là ETL), nhưng Dataflow đòi viết pipeline bằng Apache Beam trong Java hoặc Python — đúng thứ đội này không làm được. (Có template dựng sẵn, nhưng không phải môi trường dựng luồng bằng giao diện.)

• A (Dataproc) — Spark/Hadoop được quản lý, vẫn phải viết mã Spark.

• C (Cloud Composer) — điều phối các bước, không phải công cụ dựng phép biến đổi bằng giao diện.

Ghi nhớ

⚠ Bốn công cụ xử lý dữ liệu — bảng phải thuộc: | Công cụ | Bản chất | Đòi hỏi kỹ năng | |---|---|---| | Cloud Data Fusion | kéo thả, không cần mã | giao diện đồ hoạ | | Dataflow | Apache Beam, lô và luồng | Java / Python | | Dataproc | Spark, Hadoop được quản lý | Spark / Hadoop | | Cloud Composer | Airflow — ĐIỀU PHỐI | Python (DAG) | | Dataform | biến đổi bằng SQL trong BigQuery | SQL |

Từ khoá nhận diện:

"không cần lập trình, giao diện kéo thả" → Cloud Data Fusion "biến đổi luồng thời gian thực quy mô lớn" → Dataflow "đã có sẵn job Spark/Hadoop" → Dataproc "điều phối nhiều bước phụ thuộc" → Cloud Composer "chỉ dùng SQL, biến đổi trong BigQuery" → Dataform

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline chạy có lỗi không | giao diện Data Fusion → Pipeline runs | | Cụm Dataproc bên dưới thế nào | xem Compute profile của pipeline | | Chi phí thực tế | billing export, lọc SKU Data Fusion và Dataproc |

Và một điều nên nói rõ với đội trước khi chốt Data Fusion: instance của nó tính tiền theo giờ chạy, kể cả khi không có pipeline nào hoạt động. Với đội chỉ chạy vài luồng mỗi ngày, khoản này có thể lớn hơn cả chi phí xử lý dữ liệu — nên hãy tắt instance ở môi trường phát triển, và nếu đội thật sự thoải mái với SQL, Dataform đáng được đặt lên bàn cân.

Đáp án

B — SELECT * FROM product_sales_2024 LIMIT 10;

Vì sao đúng

Trong bốn phương án, đây là câu duy nhất trả về đúng thứ cần: mười dòng đầu, đủ mọi cột, để xem cấu trúc bảng và nội dung mẫu.

⚠ Điểm mấu chốt — so sánh bốn truy vấn:

B: SELECT * ... LIMIT 10
    → 10 dòng, đủ cột
    → đúng yêu cầu

D: SELECT * (không LIMIT)
    → trả về TOÀN BỘ bảng rất lớn
    → kết quả khổng lồ, chờ lâu

C: SELECT COUNT(*)
    → chỉ ra MỘT SỐ
    → không thấy cột nào, không thấy dữ liệu

A: SELECT * WHERE date < CURRENT_DATE()
    → vẫn có thể trả hàng triệu dòng
    → thêm điều kiện không cần thiết

⚠ ⚠ Nhưng phải biết: LIMIT KHÔNG làm giảm chi phí quét:

BigQuery tính tiền theo
    SỐ BYTE ĐƯỢC QUÉT
        ↓
    SELECT * ... LIMIT 10
        ↓
    ⚠ Vẫn quét TOÀN BỘ các cột được chọn
    ⚠ LIMIT chỉ cắt bớt KẾT QUẢ TRẢ VỀ
        ↓
    → với bảng rất lớn, câu này vẫn tốn tiền

⚠ Ba cách xem mẫu dữ liệu MIỄN PHÍ hoàn toàn:

1. TABLE PREVIEW trong console
    → tab "Preview" — KHÔNG quét, KHÔNG tính tiền

2. bq head
    bq head -n 10 my_dataset.product_sales_2024
    → dùng API tabledata.list, MIỄN PHÍ

3. Xem lược đồ
    bq show --schema my_dataset.product_sales_2024
    → chỉ đọc metadata, MIỄN PHÍ

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

• A (SELECT * ... WHERE date < CURRENT_DATE()) — đây là phương án gần nhất vì có lọc, nhưng điều kiện này không giới hạn số dòng — với bảng bán hàng cả năm, gần như toàn bộ dữ liệu đều thoả.

• D (SELECT * không LIMIT) — trả về toàn bộ bảng rất lớn: chậm, kết quả không xem nổi.

• C (SELECT COUNT(*)) — chỉ cho số dòng, không thấy cột nào, không đáp ứng yêu cầu xem cấu trúc và nội dung.

Ghi nhớ về chất lượng câu hỏi

Câu này đúng ở mức so sánh bốn phương án được cho, nhưng cần biết một điều quan trọng ngoài phạm vi đó: LIMIT KHÔNG giảm chi phí truy vấn của BigQuery. Chi phí tính theo số byte quét, và SELECT * buộc BigQuery đọc mọi cột.

Trong công việc thật, cách đúng để "xem nhanh dữ liệu mà không tốn tiền" là tab Preview của console hoặc bq head — cả hai đều miễn phí. Khoá B vẫn là đáp án đúng của câu này, chỉ là đừng mang thói quen "cứ LIMIT là rẻ" ra khỏi phòng thi.

Ghi nhớ

⚠ Xem nhanh dữ liệu BigQuery — bảng phải thuộc: | Cách | Chi phí | |---|---| | Tab Preview trong console | MIỄN PHÍ — không quét | | bq head -n 10 <bảng> | MIỄN PHÍ | | bq show --schema <bảng> | MIỄN PHÍ | | SELECT * ... LIMIT 10 | TÍNH TIỀN theo byte quét | | TABLESAMPLE SYSTEM (1 PERCENT) | quét ít hơn, có tính tiền |

Từ khoá nhận diện:

"xem mẫu dữ liệu" → Preview hoặc bq head (miễn phí) "xem cấu trúc bảng" → bq show --schema, hoặc INFORMATION_SCHEMA.COLUMNS "giảm chi phí truy vấn" → chọn ít cột + lọc theo cột PHÂN VÙNG "LIMIT giảm chi phí" → SAI "ước lượng chi phí trước" → --dry_run

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn sẽ quét bao nhiêu | bq query --dry_run, hoặc chỉ báo trong console | | Bảng có phân vùng không | bq show → Time Partitioning | | Ai đang tốn nhiều nhất | INFORMATION_SCHEMA.JOBS |

Và một cài đặt nên bật cho mọi người mới vào dự án: maximum_bytes_billed. Một câu SELECT * gõ vội trên bảng vài trăm TiB có thể sinh hoá đơn đáng nhớ trong vài giây, và trần này biến sự cố đó thành một thông báo lỗi vô hại.

Đáp án

A — Dùng tính năng "Scheduled queries" (truy vấn theo lịch) ngay trong giao diện BigQuery.

Vì sao đúng

Đề nêu rõ hai ràng buộc: thiết lập tối thiểu và không viết mã. Yêu cầu chỉ là một câu SQL chạy mỗi sáng 8 giờ — đúng phạm vi của scheduled query.

⚠ Điểm mấu chốt — tất cả nằm trong BigQuery:

Trong giao diện BigQuery:
    Viết truy vấn
        ↓
    Bấm "Schedule"
        ↓
    Đặt: lặp lại hằng ngày, 08:00,
         múi giờ, bảng đích, chế độ ghi
        ↓
    ⚠ KHÔNG cần hàm, không cần Airflow,
      không cần máy chủ, không cần mã

⚠ Bên dưới là BigQuery Data Transfer Service:

Scheduled query
        ↓
    Chạy trên nền BigQuery Data Transfer Service
        ↓
    → có LỊCH SỬ CHẠY và log
    → có thử lại
    → có thông báo qua Pub/Sub khi hỏng
        ↓
    Bản thân dịch vụ MIỄN PHÍ
    → chỉ trả tiền cho chính truy vấn

⚠ Ba lựa chọn cấu hình quan trọng:

Chế độ ghi bảng đích:
    WRITE_TRUNCATE  → ghi đè — báo cáo "ảnh chụp"
    WRITE_APPEND    → nối thêm — dữ liệu lịch sử

Múi giờ:
    ⚠ mặc định UTC — 8 giờ sáng giờ nào?

Tham số thời gian chạy:
    @run_date, @run_time
    → dùng để lấy "dữ liệu ngày hôm qua"

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

• B (Cloud Function + Cloud Scheduler) — đây là phương án gần nhất và hoàn toàn chạy được, nhưng cần viết mã, triển khai hàm, cấu hình quyền và một job lịch riêng — nhiều bước hơn hẳn cho cùng một kết quả.

• C (Cloud Composer) — Airflow được quản lý, phải viết DAG bằng Python và duy trì một môi trường thường trực tốn kém. Quá nặng cho một truy vấn.

• D (script trên VM + cron) — công vận hành cao nhất: máy phải luôn chạy, phải vá lỗi, phải tự lo giám sát và thử lại.

Ghi nhớ

⚠ Chạy SQL theo lịch — chọn công cụ theo độ phức tạp: | Nhu cầu | Công cụ | |---|---| | Một truy vấn, lịch cố định | BigQuery scheduled query | | Vài bước SQL có phụ thuộc | Dataform | | Nhiều hệ thống, phụ thuộc phức tạp | Cloud Composer | | Kích hoạt mã tuỳ ý theo giờ | Cloud Scheduler + Cloud Run | | Nạp định kỳ từ nguồn ngoài | Data Transfer Service |

Từ khoá nhận diện:

"một truy vấn, mỗi sáng, không viết mã" → scheduled query "DAG, phụ thuộc, nhiều hệ thống" → Cloud Composer "chuỗi phép biến đổi SQL có kiểm thử" → Dataform "gọi API theo giờ" → Cloud Scheduler "nạp từ Google Ads, YouTube, S3 theo lịch" → Data Transfer Service

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Job đã chạy chưa | BigQuery → Scheduled queries → Run history | | Chạy dưới danh nghĩa ai | xem cấu hình của scheduled query | | Bảng đích có dữ liệu mới không | SELECT MAX(<cột ngày>) FROM <bảng đích> |

Và một chi tiết rất hay gây sự cố sau vài tháng: scheduled query mặc định chạy dưới danh nghĩa người tạo ra nó. Khi người đó đổi vai trò hoặc rời công ty, báo cáo dừng chạy mà không ai được báo — và thường phải tới lúc có người hỏi "sao số liệu vẫn là của tuần trước" thì mới phát hiện ra. Chuyển sang service account ngay từ đầu là cách tránh gọn nhất.

Đáp án

C — Standard.

Vì sao đúng

Đề nói log được sinh liên tục và phải phân tích NGAY khi tạo ra, với ưu tiên hàng đầu là hiệu năng và truy cập nhanh. Đó chính là mô tả của dữ liệu nóng — lớp Standard.

⚠ Điểm mấu chốt — chọn lớp theo TẦN SUẤT TRUY CẬP:

Truy cập THƯỜNG XUYÊN, liên tục
    → STANDARD                    ← đề này

Khoảng 1 lần/tháng
    → NEARLINE

Khoảng 1 lần/quý
    → COLDLINE

Dưới 1 lần/năm
    → ARCHIVE

⚠ Vì sao ba lớp lạnh đều sai ở đây — hai lý do:

LÝ DO 1 — PHÍ TRUY XUẤT
    Lớp lạnh tính tiền MỖI LẦN ĐỌC
        ↓
    Dashboard đọc liên tục
        ↓
    → phí truy xuất VƯỢT XA
      phần tiết kiệm được khi lưu

LÝ DO 2 — THỜI GIAN LƯU TỐI THIỂU
    Nearline 30 ngày, Coldline 90, Archive 365
        ↓
    Log mới ghi mà xoá hoặc đổi lớp sớm
        ↓
    → bị tính PHÍ XOÁ SỚM

⚠ Một điều thường bị hiểu lầm:

Cả bốn lớp đều có:
    - CÙNG độ bền (11 số 9)
    - CÙNG độ trễ truy cập (mili giây)
        ↓
    ⚠ Lớp lạnh KHÔNG chậm hơn khi đọc
    → khác biệt nằm ở GIÁ, không ở TỐC ĐỘ
        ↓
    Nhưng với dữ liệu đọc liên tục,
    giá mới là thứ quyết định

Xem thêm câu #12923 (cùng lô): cùng chủ đề lớp lưu trữ nhưng đề nói dữ liệu cũ truy cập vài lần MỖI THÁNG → khoá là Nearline. Và #12588 (cùng lô) đổi sang Coldline cho dữ liệu lạnh hơn nữa. Ba khoá khác nhau vì tần suất truy cập khác nhau — hoàn toàn nhất quán.

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

• D (Nearline) — đây là phương án gần nhất trong nhóm lạnh, nhưng nó dành cho dữ liệu truy cập khoảng một lần mỗi tháng, có phí truy xuất và tối thiểu 30 ngày. Log đọc liên tục sẽ đắt hơn hẳn Standard.

• B (Coldline) — cho dữ liệu khoảng một lần mỗi quý; phí truy xuất cao hơn nữa.

• A (Archive) — cho dữ liệu dưới một lần mỗi năm; đắt nhất khi đọc, tối thiểu 365 ngày.

Ghi nhớ

⚠ Bốn lớp lưu trữ — bảng phải thuộc: | Lớp | Tần suất truy cập | Tối thiểu | Phí truy xuất | |---|---|---|---| | Standard | liên tục, thường xuyên | không có | không có | | Nearline | ~1 lần/tháng | 30 ngày | có | | Coldline | ~1 lần/quý | 90 ngày | cao hơn | | Archive | <1 lần/năm | 365 ngày | cao nhất | | Điểm chung | cùng độ bền, cùng độ trễ mili giây |

Từ khoá nhận diện:

"phân tích ngay, hiệu năng ưu tiên" → Standard "vài lần mỗi tháng" → Nearline "vài lần mỗi quý" → Coldline "lưu trữ tuân thủ, hầu như không đọc" → Archive "không đoán được mẫu truy cập" → Autoclass

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket đang ở lớp nào | gcloud storage buckets describe gs://b | | Dữ liệu thật sự được đọc bao nhiêu | Monitoring, chỉ số request của bucket | | Chi phí chia theo lớp | billing export, nhóm theo SKU |

Và một điều cần tính trước khi chuyển log sang lớp lạnh cho "tiết kiệm": hãy đo số lần đọc thật trước đã. Với dữ liệu mà dashboard quét đều đặn, phí truy xuất của Nearline hay Coldline có thể vượt xa phần tiết kiệm được ở giá lưu — và bạn sẽ trả nhiều hơn để đổi lấy cảm giác đang tối ưu.

Đáp án

D — BigQuery ML (BQML).

Vì sao đúng

Đề nói rõ: dữ liệu đã nằm trong BigQuery, và đội muốn dựng, huấn luyện và đánh giá mô hình CHỈ BẰNG SQL, ngay trong BigQuery. Đó là toàn bộ lý do BigQuery ML tồn tại.

⚠ Điểm mấu chốt — huấn luyện bằng một câu SQL:

CREATE OR REPLACE MODEL `du_an.du_doan_vo_no`
OPTIONS(
  model_type = 'LOGISTIC_REG',
  input_label_cols = ['vo_no']
) AS
SELECT thu_nhap, so_du, so_lan_tre_han, vo_no
FROM `du_an.giao_dich_khach_hang`;

        ↓
    ⚠ Dữ liệu KHÔNG rời khỏi BigQuery
    ⚠ Không cần Python, không cần hạ tầng

⚠ Đánh giá và dự đoán cũng bằng SQL:

-- đánh giá
SELECT * FROM ML.EVALUATE(MODEL `du_an.du_doan_vo_no`);

-- dự đoán
SELECT * FROM ML.PREDICT(
  MODEL `du_an.du_doan_vo_no`,
  (SELECT * FROM `du_an.khach_hang_moi`));

-- giải thích
SELECT * FROM ML.EXPLAIN_PREDICT(...);

⚠ Vì sao "dữ liệu không phải di chuyển" lại quan trọng:

Cách truyền thống:
    Xuất dữ liệu khỏi kho
        ↓
    Đưa vào môi trường huấn luyện
        ↓
    ⚠ Với dữ liệu tài chính: thêm một
      bản sao dữ liệu nhạy cảm cần bảo vệ
      + thời gian + quyền truy cập

BQML:
    Mô hình chạy TẠI CHỖ trong BigQuery
        ↓
    → ít rủi ro tuân thủ hơn hẳn

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

• C (AutoML Tables) — đây là phương án gần nhất vì cũng huấn luyện mô hình trên dữ liệu bảng ít cần viết mã, nhưng nó là giao diện của Vertex AI, không phải "chỉ dùng SQL trong BigQuery". (Chức năng này nay đã gộp vào Vertex AI, và BQML cũng gọi được AutoML qua model_type='AUTOML_CLASSIFIER'.)

• A (Vertex AI Pipelines) — điều phối luồng công việc học máy, cần viết mã Python và định nghĩa pipeline.

• B (Looker) — nền tảng trực quan hoá và BI, không huấn luyện mô hình.

Ghi nhớ

⚠ Chọn công cụ học máy trên Google Cloud — bảng phải thuộc: | Nhu cầu | Công cụ | |---|---| | Dữ liệu đã ở BigQuery, chỉ dùng SQL | BigQuery ML | | Toàn bộ vòng đời ML, viết mã Python | Vertex AI | | Điều phối các bước huấn luyện | Vertex AI Pipelines | | Mô hình dựng sẵn: ảnh, ngôn ngữ, giọng nói | API của Vertex AI | | Trực quan hoá, BI | Looker, Looker Studio |

Từ khoá nhận diện:

"chỉ dùng SQL, ngay trong BigQuery" → BigQuery ML "đội giỏi Python, cần kiểm soát chi tiết" → Vertex AI "nhận dạng ảnh, dịch, chuyển giọng nói" → API dựng sẵn "điều phối nhiều bước ML" → Vertex AI Pipelines "báo cáo, biểu đồ" → Looker Studio

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình tốt tới đâu | ML.EVALUATE — xem AUC, precision, recall | | Đặc trưng nào quan trọng | ML.FEATURE_IMPORTANCE | | Mô hình đang dùng dữ liệu nào | ML.TRAINING_INFO và định nghĩa mô hình |

Và một cạm bẫy rất dễ rơi vào với bài toán vỡ nợ: dữ liệu mất cân bằng nặng. Nếu chỉ 2% khách hàng vỡ nợ, một mô hình dự đoán "không ai vỡ nợ" đã đạt 98% độ chính xác mà hoàn toàn vô dụng. Hãy đọc AUC, precision và recall trong ML.EVALUATE thay vì nhìn con số accuracy — đó là khác biệt giữa một mô hình dùng được và một con số đẹp.

Đáp án

B — Cloud Logging.

Vì sao đúng

Đề cần thông báo lỗi và stack trace do worker của Dataflow sinh ra. Đó là log, và mọi log của Google Cloud đều đổ về Cloud Logging.

⚠ Điểm mấu chốt — bốn công cụ quan sát, mỗi cái một loại dữ liệu:

CLOUD LOGGING
    → LOG: dòng chữ, thông báo lỗi,
      STACK TRACE                     ← đề này

CLOUD MONITORING
    → CHỈ SỐ: CPU, độ trễ, thông lượng

CLOUD TRACE
    → DẤU VẾT: một request đi qua các
      dịch vụ mất bao lâu ở đâu

CLOUD PROFILER
    → HỒ SƠ HIỆU NĂNG: hàm nào tốn CPU,
      tốn bộ nhớ

⚠ Tìm log của Dataflow ở đâu:

Giao diện Dataflow → chọn job → tab "Logs"
        ↓
    Có hai nhóm:
      JOB LOGS    → thông điệp của dịch vụ
      WORKER LOGS → mã của bạn, STACK TRACE

Trong Logs Explorer:
  resource.type="dataflow_step"
  resource.labels.job_id="<job id>"
  severity>=ERROR

⚠ Quy trình gỡ lỗi một job Dataflow hỏng:

1. Đọc thông báo lỗi ở tab Job Logs
2. Lọc severity>=ERROR trong Worker Logs
       → tìm stack trace đầu tiên
3. Xem "Job graph" — bước nào dừng
4. Xem chỉ số worker trong Monitoring
       → có phải hết bộ nhớ không
5. Nếu chậm chứ không lỗi → Profiler

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

• A (Cloud Profiler) — đây là phương án dễ nhầm nhất khi nghĩ tới "công cụ chẩn đoán", nhưng nó cho biết hàm nào tốn CPU và bộ nhớ, không phải nơi đọc thông báo lỗi.

• C (Cloud Trace) — theo dõi độ trễ của một request qua nhiều dịch vụ, dùng để tìm nút thắt, không phải để đọc stack trace của job thất bại.

• D (Cloud Debugger) — cho phép đặt điểm chụp trạng thái trên ứng dụng đang chạy, không phải nơi lưu log. Ngoài ra xem phần ghi chú bên dưới.

Ghi nhớ về chất lượng câu hỏi

Cloud Debugger (phương án D) là dịch vụ ĐÃ NGỪNG HOẠT ĐỘNG — Google tắt vào 31/05/2023, thay bằng Cloud Debugger trong Snapshot Debugger nguồn mở và các công cụ khác của Cloud Observability.

Điều này KHÔNG làm thay đổi khoá đáp án: D vốn đã là phương án sai, và B (Cloud Logging) vẫn đúng. Chỉ cần biết rằng nếu gặp Cloud Debugger như một đáp án đúng trong đề nào đó, đó là dấu hiệu câu hỏi đã cũ so với dịch vụ thực tế.

Ghi nhớ

⚠ Bốn trụ cột quan sát của Google Cloud — bảng phải thuộc: | Công cụ | Dữ liệu | Trả lời câu hỏi | |---|---|---| | Cloud Logging | log, stack trace | chuyện gì đã xảy ra, lỗi gì | | Cloud Monitoring | chỉ số, cảnh báo | hệ thống khoẻ không | | Cloud Trace | dấu vết phân tán | thời gian đi đâu mất | | Cloud Profiler | hồ sơ CPU/bộ nhớ | hàm nào tốn tài nguyên | | Error Reporting | gom nhóm lỗi | lỗi nào xảy ra nhiều nhất |

Từ khoá nhận diện:

"stack trace, thông báo lỗi" → Cloud Logging "CPU, bộ nhớ, cảnh báo" → Cloud Monitoring "request chậm ở bước nào" → Cloud Trace "hàm nào ngốn CPU" → Cloud Profiler "gom các lỗi giống nhau lại" → Error Reporting

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lỗi đầu tiên là gì | Logs Explorer, sắp xếp tăng dần, severity>=ERROR | | Bước nào dừng | Job graph trong giao diện Dataflow | | Worker có hết bộ nhớ không | chỉ số worker trong Monitoring |

Và một thói quen giúp gỡ lỗi Dataflow nhanh hơn hẳn: tìm dòng lỗi ĐẦU TIÊN, không phải dòng cuối. Một bước hỏng thường kéo theo hàng loạt lỗi phái sinh ở các bước sau, và phần cuối của log gần như luôn là hậu quả chứ không phải nguyên nhân.