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

Tìm thấy 333 câu.

Câu 71 Data Preparation and Ingestion

A company wants to ingest data from its on-premises Oracle database into BigQuery for analytics. The data engineering team prefers using tools that require minimal coding and provide a visual interface for building pipelines. The tool must be able to connect to the Oracle database, allow for visual transformations, and write the data to BigQuery.

Which Google Cloud service is the best fit?

  1. A BigQuery Data Transfer Service
  2. B Dataflow
  3. C Database Migration Service (DMS)
  4. D Cloud Data Fusion
Xem giải thích

Đáp án

D — Cloud Data Fusion.

Vì sao đúng

Đề nêu bốn yêu cầu: kết nối tới Oracle tại chỗ, giao diện trực quan, ít viết mã nhất có thể, và ghi vào BigQuery. Cloud Data Fusion đáp ứng cả bốn.

⚠ Điểm mấu chốt — kéo thả từ nguồn tới đích:

Cloud Data Fusion Studio
        ↓
    Kéo plugin "Oracle" làm nguồn
        ↓
    Kéo các node biến đổi
    (Wrangler, Joiner, Aggregator...)
        ↓
    Kéo plugin "BigQuery" làm đích
        ↓
    Nối các node lại rồi bấm chạy
        ↓
    ⚠ Không viết một dòng Java hay Python nào

⚠ Kết nối tới Oracle TẠI CHỖ:

Data Fusion chạy trên Google Cloud
        ↓
    Cần đường tới máy chủ Oracle:
      - Cloud VPN hoặc Interconnect
      - hoặc Private Service Connect
        ↓
    Cần JDBC DRIVER của Oracle:
      ⚠ tải lên Data Fusion Hub trước
        (Oracle không cho phân phối lại
         driver, nên phải tự thêm)
        ↓
    Sau đó plugin Oracle hoạt động như
    mọi nguồn khác

⚠ Vì sao ba phương án kia không khớp:

Database Migration Service
    → CHUYỂN CSDL sang Cloud SQL/AlloyDB
    → không phải đích BigQuery,
      không có biến đổi trực quan

Dataflow
    → mạnh và linh hoạt,
      nhưng phải VIẾT MÃ Apache Beam
    → trái yêu cầu "ít viết mã"

BigQuery Data Transfer Service
    → chỉ có trình kết nối cho các nguồn
      SaaS và kho định sẵn
    → KHÔNG có Oracle tại chỗ,
      không có biến đổi trực quan

Xem thêm câu #12915 (lô 133): cũng khoá Cloud Data Fusion vì đội giỏi SQL nhưng không lập trình. Hai câu CÙNG KHOÁ, cùng lý do — hoàn toàn nhất quán. Và #12933/#12939 (cùng lô) là các dịch vụ chuyển TỆP, khác hẳn bài toán ở đây.

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 và hoàn toàn làm được, kể cả có template JDBC-to-BigQuery, nhưng biến đổi tuỳ ý đòi viết Apache Beam bằng Java hoặc Python — trái yêu cầu rõ ràng của đội.

  • C (Database Migration Service) — chuyển CSDL sang Cloud SQL / AlloyDB, không phải sang BigQuery, và không có biến đổi trực quan.

  • A (BigQuery Data Transfer Service) — không có trình kết nối cho Oracle tại chỗ, và không có bước biến đổi.

Ghi nhớ

⚠ Đưa dữ liệu từ CSDL tại chỗ vào Google Cloud — bảng phải thuộc: | Nhu cầu | Dịch vụ | |---|---| | Ít mã, giao diện trực quan, biến đổi | Cloud Data Fusion | | CDC gần thời gian thực vào BigQuery | Datastream | | Chuyển CSDL sang Cloud SQL/AlloyDB | Database Migration Service | | Biến đổi phức tạp, có đội lập trình | Dataflow | | Đã có job Spark | Dataproc | | Nguồn SaaS định sẵn → BigQuery | BigQuery Data Transfer Service |

Từ khoá nhận diện:

"kéo thả, không lập trình, Oracle → BigQuery" → Cloud Data Fusion "đồng bộ thay đổi liên tục vào BigQuery" → Datastream "Oracle → Cloud SQL" → Database Migration Service "Google Ads → BigQuery" → Data Transfer Service "S3 → GCS" → Storage Transfer Service

Datastream — lựa chọn rất đáng cân nhắc Nội dung
Việc CDC — đồng bộ thay đổi gần thời gian thực
Nguồn Oracle, MySQL, PostgreSQL, SQL Server
Đích BigQuery (trực tiếp), Cloud Storage
Ưu điểm không cần viết mã, độ trễ thấp
Khác Data Fusion không có biến đổi trực quan
Đề này cần biến đổi → Data Fusion
Cloud Data Fusion — nhắc lại Nội dung
Nền tảng CDAP mã nguồn mở
Wrangler làm sạch dữ liệu trực quan
Hơn 150 plugin nguồn, đích, biến đổi
Chạy trên Dataproc tạm thời
⚠ Chi phí instance chạy THƯỜNG TRỰC — không rẻ
Ba phiên bản Developer, Basic, Enterprise
Kết nối tới hệ thống tại chỗ Cách
Cloud VPN rẻ, dễ dựng, băng thông vừa
Dedicated / Partner Interconnect băng thông lớn, ổn định
Private Service Connect truy cập riêng tư tới dịch vụ
JDBC driver phải tự tải lên với Oracle
Cần phối hợp đội mạng và đội CSDL — thường là phần lâu nhất
Điều cần cẩn thận khi đọc từ CSDL sản xuất Nội dung
Tải lên hệ thống nguồn đọc theo lô lớn làm chậm ứng dụng
Nên đọc từ replica, hoặc chạy ngoài giờ cao điểm
Đọc gia tăng theo cột dấu thời gian, không quét cả bảng
CDC ít ảnh hưởng nguồn nhất
Quyền tài khoản chỉ đọc, phạm vi hẹp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline chạy có lỗi không | Data Fusion → Pipeline runs | | Số dòng có khớp không | so COUNT(*) hai bên | | Ảnh hưởng tới Oracle thế nào | theo dõi tải trên chính máy chủ nguồn |

Và một điều nên thống nhất với đội quản trị CSDL trước khi chạy pipeline đầu tiên: đọc từ đâu và vào lúc nào. Một job Data Fusion quét toàn bộ bảng lớn trên Oracle sản xuất giữa giờ làm việc có thể làm chậm chính ứng dụng nghiệp vụ — đọc từ replica hoặc chạy ngoài giờ cao điểm là thoả thuận nên có ngay từ đầu, chứ không phải sau sự cố đầu tiên.

Câu 72 Data Management

A data analyst team needs to query a table containing customer PII (Personally Identifiable Information), but they should only be able to see a redacted version of the customer's phone number (e.g., XXX-XXX-1234). A separate, more privileged group of users needs to see the full phone number from the same table. The underlying data must be stored in its original, plaintext format.

Which feature is designed to apply this kind of conditional, query-time redaction?

  1. A Cloud KMS (Key Management Service)
  2. B Dynamic Data Masking
  3. C AEAD (Authenticated Encryption with Associated Data) functions
  4. D CMEK (Customer-Managed Encryption Keys)
Xem giải thích

Đáp án

B — Dynamic Data Masking (che dữ liệu động).

Vì sao đúng

Đề nêu ba ràng buộc, và chỉ dynamic data masking thoả cả ba: dữ liệu gốc lưu NGUYÊN VĂN, nhóm thường thấy bản đã che, nhóm đặc quyền thấy đầy đủ — tất cả quyết định NGAY LÚC TRUY VẤN.

⚠ Điểm mấu chốt — che khi đọc, không đổi dữ liệu đã lưu:

Dữ liệu trên đĩa: 090-123-1234   (nguyên văn)
        ↓
    Nhà phân tích thường truy vấn
        ↓
    → XXX-XXX-1234   (đã che)

    Nhóm đặc quyền truy vấn
        ↓
    → 090-123-1234   (đầy đủ)
        ↓
    ⚠ CÙNG một bảng, CÙNG một câu SQL
    ⚠ Khác nhau ở VAI TRÒ người chạy

⚠ Cách dựng — ba bước:

1. Tạo POLICY TAG trong Dataplex/Data Catalog
   ví dụ "PII / Phone"

2. Gắn tag vào cột phone_number trong lược đồ

3. Tạo DATA POLICY gắn quy tắc che vào tag đó
   và cấp vai trò cho từng nhóm:
     - roles/bigquerydatapolicy.maskedReader
         → thấy bản ĐÃ CHE
     - roles/datacatalog.categoryFineGrainedReader
         → thấy ĐẦY ĐỦ
     - không có vai trò nào → BỊ TỪ CHỐI

⚠ Các quy tắc che có sẵn:

SHA256                → băm, vẫn nối bảng được
ALWAYS_NULL           → luôn trả NULL
DEFAULT_MASKING_VALUE → giá trị mặc định theo kiểu
LAST_FOUR_CHARACTERS  → giữ 4 ký tự cuối   ← đề này
FIRST_FOUR_CHARACTERS → giữ 4 ký tự đầu
EMAIL_MASK            → che phần trước @
DATE_YEAR_MASK        → chỉ giữ năm
CUSTOM (UDF)          → quy tắc tự viết

Xem thêm câu #12965 (lô 134): cùng dùng policy tag, nhưng ở đó yêu cầu là CHẶN HẲN cột lương → khoá là column-level security. Câu này yêu cầu vẫn truy vấn được nhưng thấy bản che → dynamic data masking. Hai khoá khác nhau vì mức độ chặn khác nhau — không mâu thuẫn.

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

  • C (hàm AEAD) — đây là phương án gần nhất về mặt "biến đổi giá trị", nhưng AEAD mã hoá dữ liệu KHI LƯU, nên dữ liệu trên đĩa KHÔNG còn nguyên văn — trái yêu cầu. Nó cũng đòi ứng dụng tự gọi hàm giải mã.

  • A (Cloud KMS) và D (CMEK) — đều là quản lý KHOÁ mã hoá, quyết định ai giữ khoá, không liên quan tới việc hiển thị khác nhau theo vai trò người truy vấn.

Ghi nhớ

⚠ Ba cách bảo vệ cột nhạy cảm — bảng phải thuộc: | Cách | Dữ liệu lưu | Người không đủ quyền thấy gì | |---|---|---| | Column-level security | nguyên văn | BỊ TỪ CHỐI truy vấn | | Dynamic data masking | nguyên văn | giá trị ĐÃ CHE | | AEAD / mã hoá cột | BẢN MÃ | bản mã, cần khoá mới đọc được | | Cả ba | dùng chung POLICY TAG |

Từ khoá nhận diện:

"che một phần, vẫn truy vấn được, dữ liệu gốc nguyên vẹn" → dynamic data masking "chặn hẳn không cho đọc cột" → column-level security "dữ liệu phải được mã hoá trong bảng" → AEAD "ai giữ khoá mã hoá" → CMEK / Cloud KMS "chỉ thấy dòng của mình" → row-level security

Vì sao masking hữu ích hơn ta tưởng Lý do
Truy vấn có sẵn KHÔNG VỠ vẫn chạy, chỉ khác giá trị
Dashboard dùng chung được mỗi người thấy mức chi tiết của mình
SHA256 vẫn JOIN được nối bảng mà không lộ giá trị
Không phải nhân bản dữ liệu một bảng phục vụ nhiều mức quyền
Đổi lại người dùng không biết mình đang xem bản che nếu không được báo
Các vai trò liên quan Vai trò
roles/bigquerydatapolicy.maskedReader thấy bản ĐÃ CHE
roles/datacatalog.categoryFineGrainedReader thấy ĐẦY ĐỦ
Không có vai trò nào bị từ chối truy cập cột
Cấp trên policy tag, không phải trên bảng
Lợi ích một tag, áp cho nhiều cột ở nhiều bảng
AEAD — khi nào mới cần Trường hợp
Dữ liệu phải là bản mã ngay trong bảng quy định rất chặt
Mỗi khách hàng một khoá riêng cách ly tuyệt đối
Xoá khoá = xoá dữ liệu "crypto-shredding"
Hàm AEAD.ENCRYPT, AEAD.DECRYPT_STRING, KEYS.NEW_KEYSET
Đổi lại ứng dụng phức tạp hơn nhiều, mất khả năng lọc và tổng hợp
Phòng thủ nhiều lớp cho PII Lớp
Sensitive Data Protection tìm ra cột nào chứa PII
Policy tag phân loại mức nhạy cảm
Masking hoặc CLS kiểm soát hiển thị
Row-level security giới hạn phạm vi dòng
Data Access audit log ai đã đọc gì
VPC Service Controls chống dữ liệu ra khỏi vành đai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cột nào mang tag gì | bq show --schema --format=prettyjson <bảng> | | Quy tắc che là gì | Dataplex → Data policies | | Người này thấy giá trị nào | chạy thử dưới danh nghĩa tài khoản đó |

Và một điều nên thông báo rõ cho đội phân tích khi bật masking: họ đang xem bản đã che. Nếu không nói, một người thấy XXX-XXX-1234 rất dễ kết luận rằng dữ liệu nguồn bị hỏng — và đi báo một sự cố chất lượng dữ liệu không hề tồn tại.

Câu 73 Data Analysis and Presentation

As a data scientist for an e-commerce company, you are tasked with building a model to predict whether a customer will click on a promotional ad. The training data resides in a table named myproject.marketing_data.ad_engagement, which contains user behavior features and a BOOLEAN column named clicked_ad.

You need to train a logistic regression model to predict the value of clicked_ad, using all other columns in the table as predictive features.

Which query correctly constructs this model?

  1. A

    D)

    CREATE MODEL `myproject.marketing_data.ad_click_model`
AS SELECT * EXCEPT(clicked_ad), clicked_ad AS label
FROM `myproject.marketing_data.ad_engagement`;
  2. B

    B)

    CREATE MODEL `myproject.marketing_data.ad_click_model`
OPTIONS(model_type='LOGISTIC_REG', label_column='clicked_ad')
AS SELECT * EXCEPT(clicked_ad)
FROM `myproject.marketing_data.ad_engagement`;
  3. C

    C)

    CREATE MODEL `myproject.marketing_data.ad_click_model`
OPTIONS(model_type='LOGISTIC_REG', input_label_cols=['clicked_ad'])
AS SELECT * EXCEPT(clicked_ad)
FROM `myproject.marketing_data.ad_engagement`;
  4. D

    A) 

    CREATE MODEL `myproject.marketing_data.ad_click_model`
OPTIONS(model_type='LOGISTIC_REG', input_label_cols=['clicked_ad'])
AS SELECT *
FROM `myproject.marketing_data.ad_engagement`;
Xem giải thích

Đáp án

C — CREATE MODEL ... OPTIONS(model_type='LOGISTIC_REG', input_label_cols=['clicked_ad']) AS SELECT * EXCEPT(clicked_ad) FROM ...

Vì sao đúng

Trong bốn phương án, câu này là phương án duy nhất cùng lúc dùng ĐÚNG loại mô hình và ĐÚNG tên tuỳ chọn khai nhãn — hai điểm mà câu hỏi thật sự kiểm tra.

⚠ Điểm mấu chốt — hai tuỳ chọn bắt buộc:

model_type = 'LOGISTIC_REG'
        ↓
    Nhãn `clicked_ad` là BOOLEAN
    → bài toán PHÂN LOẠI HAI LỚP
    → logistic regression

input_label_cols = ['clicked_ad']
        ↓
    ⚠ Tên tuỳ chọn ĐÚNG của BigQuery ML
    ⚠ Nhận một MẢNG, không phải chuỗi
        ↓
    KHÔNG có tuỳ chọn nào tên `label_column`

⚠ Vì sao hai phương án kia sai chắc chắn:

Phương án B: label_column='clicked_ad'
        ↓
    ⚠ TÊN TUỲ CHỌN KHÔNG TỒN TẠI
    → BigQuery báo lỗi ngay

Phương án A: không có OPTIONS nào cả
        ↓
    ⚠ CREATE MODEL BẮT BUỘC phải có
      OPTIONS(model_type=...)
    → không khai loại mô hình thì không tạo được
    → việc đặt bí danh cột thành `label`
      cũng không thay thế được

⚠ Nhắc lại quy ước đặt tên nhãn của BQML:

Có HAI cách khai nhãn:
    1. input_label_cols = ['ten_cot']
    2. đặt tên cột là `label`
       → BQML tự nhận
        ↓
    Không khai gì và cũng không có cột `label`
    → lỗi

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

Câu này có hai lỗi soạn đề cần biết, nhưng khoá đáp án C vẫn được giữ nguyên:

Lỗi 1 — chữ cái bị xáo. Nội dung các phương án còn giữ nguyên chữ cái của bản gốc (D), B), C), A)), không khớp với nhãn A/B/C/D hiện tại. Khi làm bài, hãy đọc nội dung chứ đừng tin vào chữ cái nằm trong nội dung.

Lỗi 2 — quan trọng hơn — SELECT * EXCEPT(clicked_ad) LOẠI BỎ chính cột nhãn. Trong BigQuery ML, cột nhãn PHẢI CÓ MẶT trong dữ liệu huấn luyện: input_label_cols chỉ nói cho BQML biết cột nào trong tập dữ liệu đó là nhãn. Chạy thật câu C sẽ báo lỗi kiểu "Label column clicked_ad not found in input data".

Câu chạy được trên thực tế là phương án D (... input_label_cols=['clicked_ad'] AS SELECT * FROM ...) — giữ nguyên cột nhãn trong SELECT *.

KHÔNG sửa khoá vì đây là bộ đề nguồn; nhưng khi làm việc thật, hãy nhớ: input_label_cols KHÔNG đi kèm EXCEPT cột nhãn.

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

  • D (input_label_cols + SELECT *) — đây là phương án gần nhất và về mặt kỹ thuật là câu chạy đúng (xem ghi chú chất lượng ở trên); trong phạm vi bộ đề, nó bị coi là sai vì được cho là "đưa cả cột nhãn vào làm đặc trưng".

  • B (label_column='clicked_ad') — tên tuỳ chọn không tồn tại trong BigQuery ML.

  • A (không có OPTIONS) — thiếu model_type, câu lệnh không hợp lệ.

Ghi nhớ

⚠ Cú pháp CREATE MODEL — bảng phải thuộc: | Thành phần | Nội dung | |---|---| | CREATE OR REPLACE MODEL <dataset>.<ten> | tạo hoặc thay thế | | OPTIONS(model_type = '...') | BẮT BUỘC | | input_label_cols = ['ten_cot'] | khai cột nhãn — nhận MẢNG | | AS SELECT ... | dữ liệu huấn luyện, PHẢI CHỨA cột nhãn | | Quy ước thay thế | đặt tên cột là label thì không cần khai | | label_column | KHÔNG TỒN TẠI |

Từ khoá nhận diện:

"nhãn BOOLEAN, dự đoán có/không" → LOGISTIC_REG "dự đoán giá trị số" → LINEAR_REG "khai cột nhãn" → input_label_cols=['x'] "label_column" → SAI, không tồn tại "EXCEPT cột nhãn khi huấn luyện" → SAI trong thực tế

Các tuỳ chọn OPTIONS hay dùng Tuỳ chọn
model_type bắt buộc
input_label_cols cột nhãn
auto_class_weights = TRUE cân bằng lớp — rất quan trọng với dữ liệu lệch
data_split_method AUTO_SPLIT, RANDOM, SEQ, NO_SPLIT
data_split_eval_fraction tỉ lệ tập kiểm định
l1_reg / l2_reg điều chuẩn
max_iterations số vòng lặp
enable_global_explain = TRUE bật giải thích mô hình
TRANSFORM — tính năng rất đáng dùng Nội dung
Việc khai tiền xử lý NGAY TRONG mô hình
Ví dụ TRANSFORM(ML.STANDARD_SCALER(gia) AS gia, ...)
Lợi ích ML.PREDICT tự áp lại đúng phép biến đổi
Tránh được lệch giữa lúc huấn luyện và lúc dự đoán
Đây là một trong những nguồn lỗi phổ biến nhất của ML
Với bài toán dự đoán click quảng cáo Nội dung
Dữ liệu rất mất cân bằng tỉ lệ click thường vài phần trăm
Vì vậy auto_class_weights = TRUE
Đừng nhìn accuracy nhìn AUC, precision, recall
Rò rỉ dữ liệu loại các cột chỉ có sau khi đã click
Đánh giá ML.EVALUATE, ML.ROC_CURVE
Vòng đời một mô hình BQML Bước
1 CREATE MODEL — huấn luyện
2 ML.EVALUATE — đo chất lượng
3 ML.FEATURE_IMPORTANCE — hiểu mô hình
4 ML.PREDICT — dự đoán
5 Huấn luyện lại định kỳ — chống trôi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình huấn luyện trên cột nào | SELECT * FROM ML.FEATURE_INFO(MODEL ...) | | Mô hình tốt tới đâu | ML.EVALUATE — xem AUC | | Quá trình huấn luyện | ML.TRAINING_INFO — loss có hội tụ không |

Và một tuỳ chọn gần như luôn nên bật với bài toán dự đoán click: auto_class_weights = TRUE. Khi chỉ 2% lượt hiển thị dẫn tới click, mô hình không cân bằng lớp sẽ học được cách "không ai click bao giờ" và đạt 98% độ chính xác — một con số đẹp cho một mô hình hoàn toàn vô dụng.

Câu 74 Data Management

A retail company is migrating its data warehouse to Google Cloud. They plan to store historical sales data in a Cloud Storage bucket. The company's security policy mandates that all data must be encrypted at rest. The IT team is small and wants to minimize operational overhead, so they need a solution where Google manages the entire encryption key lifecycle (generation, rotation, storage, and destruction) automatically, with no configuration required from their side.

Which encryption method satisfies these requirements?

  1. A

    Google-managed encryption keys (GMEK)
  2. B

    Encryption in transit
  3. C

    Customer-managed encryption keys (CMEK)
  4. D

    Customer-supplied encryption keys (CSEK)
Xem giải thích

Đáp án

A — Google-managed encryption keys (GMEK — khoá do Google quản lý).

Vì sao đúng

Đề nêu bốn điều: mã hoá khi lưu, Google lo TOÀN BỘ vòng đời khoá, giảm tối đa công vận hành, và không cần cấu hình gì. Đó chính xác là mã hoá mặc định của Google Cloud.

⚠ Điểm mấu chốt — GMEK là mặc định, có sẵn, không phải bật:

Tạo bucket Cloud Storage
        ↓
    ⚠ Dữ liệu ĐÃ ĐƯỢC MÃ HOÁ AES-256
      ngay từ đối tượng đầu tiên
        ↓
    Google lo:
      - sinh khoá
      - XOAY khoá tự động
      - lưu khoá an toàn
      - huỷ khoá khi cần
        ↓
    ⚠ Không có nút nào để bật
    ⚠ Cũng không có nút nào để tắt

⚠ Ba mức quản lý khoá — chọn theo mức kiểm soát CẦN có:

GMEK                              ← đề này
    → Google lo hết
    → 0 công vận hành
    → 0 kiểm soát

CMEK (Cloud KMS)
    → bạn tạo khoá, đặt lịch xoay,
      thu hồi được
    → có công vận hành
    → cho yêu cầu TUÂN THỦ

CSEK
    → bạn gửi khoá theo từng yêu cầu
    → Google KHÔNG lưu khoá
    → công vận hành lớn nhất

⚠ Chính sách "phải mã hoá khi lưu" đã được đáp ứng sẵn:

Yêu cầu: "mọi dữ liệu phải mã hoá khi lưu"
        ↓
    ⚠ Google Cloud LUÔN làm điều này
        ↓
    → chính sách được thoả mà KHÔNG
      cần làm gì thêm
        ↓
    Câu hỏi thật sự chỉ còn:
      có cần TỰ QUẢN khoá không?
        ↓
    Đề nói "đội IT nhỏ, giảm công vận hành,
    không cần cấu hình" → KHÔNG

Xem thêm câu #12931 (lô 133): cùng chủ đề khoá mã hoá nhưng ở đó chính sách bắt toàn quyền kiểm soát việc xoay và quản lý khoá → khoá là CMEK với Cloud KMS. Hai khoá khác nhau vì yêu cầu kiểm soát khác nhau — hoàn toàn nhất quán.

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

  • C (CMEK) — đây là phương án gần nhất và cho kiểm soát tốt hơn, nhưng nó đòi tạo key ring, tạo khoá, cấp quyền cho service agent, đặt lịch xoay, và chịu rủi ro mất khoá — trái hẳn yêu cầu "giảm tối đa công vận hành, không cấu hình gì".

  • D (CSEK) — công vận hành lớn nhất: tự quản khoá bên ngoài, gửi kèm mỗi yêu cầu; mất khoá là mất dữ liệu.

  • B (mã hoá khi truyền) — bảo vệ dữ liệu trên đường đi, không phải khi lưu. Cũng đã bật mặc định.

Ghi nhớ

⚠ Ba (bốn) mức quản lý khoá — bảng phải thuộc: | Mức | Ai tạo khoá | Công vận hành | Kiểm soát | |---|---|---|---| | GMEK | Google | KHÔNG CÓ | không | | CMEK | bạn, trong Cloud KMS | trung bình | xoay, thu hồi, vô hiệu hoá | | CSEK | bạn, bên ngoài | cao | cao nhất, ít dịch vụ hỗ trợ | | EKM | hệ thống ngoài GCP | cao | cho tuân thủ rất nghiêm ngặt |

Từ khoá nhận diện:

"không cần cấu hình, Google lo hết" → GMEK "phải tự quản việc xoay khoá" → CMEK + Cloud KMS "Google không được giữ khoá" → CSEK hoặc Cloud EKM "bảo vệ trên đường truyền" → TLS — câu hỏi khác "mã hoá khi ĐANG XỬ LÝ" → Confidential Computing

GMEK hoạt động thế nào bên trong Nội dung
Dữ liệu chia thành khối, mỗi khối một DEK
DEK được mã hoá bằng KEK khoá mã hoá khoá
KEK lưu trong hệ thống KMS nội bộ của Google
Thuật toán AES-256
Xoay khoá Google làm tự động
Chứng nhận ISO, SOC, FedRAMP... — dùng được cho hầu hết yêu cầu tuân thủ
Khi nào GMEK là KHÔNG đủ Trường hợp
Quy định bắt tự quản khoá tài chính, y tế ở một số nước
Cần "công tắc ngắt" vô hiệu hoá khoá = khoá dữ liệu
Cần audit ai dùng khoá lúc nào Cloud KMS có audit log riêng
Cần khoá nằm ngoài Google → Cloud EKM
Nếu không có yêu cầu nào GMEK là lựa chọn đúng và rẻ nhất
Cái giá của CMEK mà đội nhỏ nên biết Cái giá
Phải cấp quyền cho service agent của từng dịch vụ thiếu là job hỏng
Khoá phải cùng Region với dữ liệu
Xoá khoá = MẤT DỮ LIỆU VĨNH VIỄN
Chi phí Cloud KMS theo khoá và theo thao tác
Thêm một hệ thống phải vận hành
Với đội IT nhỏ rủi ro tự gây sự cố cao hơn lợi ích
Bảo vệ dữ liệu — lớp nào quan trọng hơn mã hoá Lớp
IAM đúng và hẹp nguyên nhân rò rỉ phổ biến nhất
Uniform bucket-level access tắt ACL đối tượng
Public Access Prevention chặn bucket công khai
VPC Service Controls vành đai
Audit log phát hiện bất thường
Thực tế dữ liệu bị lộ vì QUYỀN SAI, hiếm khi vì thiếu mã hoá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket dùng khoá gì | gcloud storage buckets describe gs://b → defaultKmsKeyName rỗng = GMEK | | Đối tượng cụ thể | gsutil stat gs://b/obj → dòng KMS key | | Có bucket nào công khai không | Security Command Center |

Và một điều nên nhấn mạnh khi trình bày với bộ phận tuân thủ: chính sách "mã hoá khi lưu" đã được thoả ngay từ lúc tạo bucket, không cần dự án nào để triển khai. Công sức nên dồn vào phần thực sự hay gây rò rỉ — quyền truy cập quá rộng và bucket vô tình để công khai — chứ không phải vào việc dựng một hệ thống quản lý khoá mà đội chưa đủ người để vận hành an toàn.

Câu 75 Data Preparation and Ingestion

A medical device generates sensitive health data that, according to data privacy regulations, must be de-identified on-site before any part of the data is transmitted to the cloud. A summary of the de-identified data then needs to be uploaded to Cloud Storage.

Which solution architecture meets this strict requirement?

  1. A Deploy an application on Google Distributed Cloud Edge to process and de-identify the data locally before uploading results.
  2. B Install Pub/Sub Lite on-site to stream the data to the cloud.
  3. C Stream the raw data to a Dataflow job that uses the Cloud Healthcare API for de-identification.
  4. D Use Storage Transfer Service to move the raw data to a temporary Cloud Storage bucket for processing.
Xem giải thích

Đáp án

A — Triển khai ứng dụng trên Google Distributed Cloud Edge để xử lý và khử định danh dữ liệu NGAY TẠI CHỖ trước khi tải kết quả lên.

Vì sao đúng

Ràng buộc tuyệt đối của đề là: dữ liệu phải được khử định danh TẠI CHỖ TRƯỚC KHI bất kỳ phần nào được truyền lên đám mây. Điều đó buộc việc xử lý phải xảy ra ở nơi thiết bị đang đứng.

⚠ Điểm mấu chốt — ràng buộc loại bỏ mọi kiến trúc "gửi lên rồi xử lý":

"Khử định danh TẠI CHỖ,
 TRƯỚC KHI truyền bất kỳ phần nào"
        ↓
    ⚠ Mọi phương án gửi dữ liệu THÔ
      lên đám mây rồi mới xử lý
      → VI PHẠM ngay ở bước truyền
        ↓
    → phải có NĂNG LỰC TÍNH TOÁN
      tại chính cơ sở đó
        ↓
    Google Distributed Cloud Edge
    = hạ tầng Google chạy TRONG
      trung tâm dữ liệu của khách hàng

⚠ Google Distributed Cloud — ý tưởng cốt lõi:

Phần cứng và phần mềm của Google
    đặt TẠI CƠ SỞ của khách hàng
        ↓
    - chạy container, VM, dịch vụ dữ liệu
    - quản lý bằng công cụ quen thuộc
      của Google Cloud
    - có phiên bản NGẮT KẾT NỐI hoàn toàn
      (air-gapped) cho yêu cầu ngặt nghèo nhất
        ↓
    → dữ liệu nhạy cảm KHÔNG BAO GIỜ
      rời khỏi cơ sở ở dạng thô

⚠ Luồng đúng theo yêu cầu:

Thiết bị y tế sinh dữ liệu
        ↓
    Ứng dụng trên GDC Edge (TẠI CHỖ)
      - khử định danh
      - tổng hợp thành bản tóm tắt
        ↓
    ⚠ Đến đây dữ liệu KHÔNG CÒN
      định danh được nữa
        ↓
    Tải bản tóm tắt lên Cloud Storage
        ↓
    Phân tích trên đám mây bình thường

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

  • C (truyền dữ liệu thô tới Dataflow rồi khử định danh bằng Cloud Healthcare API) — đây là phương án gần nhất và là kiến trúc rất đúng đắn trong hoàn cảnh bình thường, nhưng nó truyền DỮ LIỆU THÔ lên đám mây trước — vi phạm trực tiếp điều đề cấm.

  • D (Storage Transfer Service đưa dữ liệu thô lên bucket tạm để xử lý) — cũng đưa dữ liệu thô lên đám mây; "bucket tạm" không thay đổi bản chất.

  • B (cài Pub/Sub Lite tại chỗ để truyền dữ liệu lên) — Pub/Sub Lite là dịch vụ đám mây, không cài tại chỗ được, và ngay cả nếu được thì nó cũng chỉ truyền dữ liệu thô đi.

Ghi nhớ

⚠ Xử lý dữ liệu ở đâu — bảng phải thuộc: | Ràng buộc | Kiến trúc | |---|---| | Dữ liệu KHÔNG được rời cơ sở ở dạng thô | Google Distributed Cloud (Edge / air-gapped) | | Dữ liệu phải ở trong một quốc gia | region cụ thể + Organization Policy | | Xử lý gần thiết bị để giảm độ trễ | edge computing, GDC Edge | | Không có ràng buộc vị trí | xử lý trên đám mây — đơn giản nhất | | Cần khử định danh trên đám mây | Sensitive Data Protection, Cloud Healthcare API |

Từ khoá nhận diện:

"khử định danh TẠI CHỖ trước khi truyền" → Google Distributed Cloud Edge "môi trường ngắt kết nối hoàn toàn" → GDC air-gapped "khử định danh dữ liệu y tế trên đám mây" → Cloud Healthcare API de-identification "tìm và che PII nói chung" → Sensitive Data Protection "dữ liệu phải ở trong nước" → chọn region + resourceLocations

Các dạng Google Distributed Cloud Dạng
GDC Edge phần cứng đặt tại cơ sở khách hàng, kết nối với Google Cloud
GDC air-gapped hoàn toàn ngắt kết nối — cho quốc phòng, chính phủ
GDC hosted vận hành bởi đối tác trong nước
Điểm chung API và công cụ quen thuộc của Google Cloud
Dùng khi dữ liệu không được rời khỏi một ranh giới vật lý
Khử định danh dữ liệu y tế — các kỹ thuật Kỹ thuật
Redaction xoá hẳn trường định danh
Masking thay bằng ký tự che
Tokenization thay bằng token có thể ánh xạ ngược
Date shifting dịch chuyển ngày theo một độ lệch cố định cho mỗi bệnh nhân
Generalization tuổi 37 → nhóm 30–39
k-anonymity, l-diversity chống suy luận ngược từ dữ liệu tổng hợp
Vì sao "tổng hợp" chưa chắc là an toàn Nội dung
Nhóm quá nhỏ một bản ghi trong nhóm = lộ chính người đó
Kết hợp nhiều chiều tuổi + mã bưu chính + giới tính đủ để định danh
Dữ liệu ngoại lai giá trị cực đoan dễ nhận ra
Cách phòng ngưỡng số lượng tối thiểu, k-anonymity
Công cụ Sensitive Data Protection có tính k-anonymity, l-diversity
Cloud Healthcare API — cho dữ liệu y tế trên đám mây Nội dung
Hỗ trợ FHIR, HL7v2, DICOM
De-identification API khử định danh có cấu hình chi tiết
Date shifting nhất quán theo bệnh nhân giữ được quan hệ thời gian
Dùng khi dữ liệu ĐƯỢC PHÉP lên đám mây
Đề này không được phép → phải xử lý tại chỗ trước

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu rời cơ sở đã sạch chưa | quét bằng Sensitive Data Protection trên bản tải lên | | Có kênh nào gửi dữ liệu thô không | rà soát toàn bộ luồng mạng ra ngoài | | Có suy luận ngược được không | kiểm tra kích thước nhóm nhỏ nhất |

Và một phép kiểm tra nên chạy định kỳ ngay cả khi kiến trúc đã đúng: quét chính dữ liệu đã tải lên đám mây để tìm PII còn sót. Logic khử định danh viết đúng lúc đầu vẫn có thể bỏ lọt định danh nằm trong trường văn bản tự do — và một lần quét tự động hằng tuần là cách rẻ nhất để phát hiện điều đó trước khi kiểm toán viên phát hiện.

Câu 76 Data Pipeline Orchestration
The process of moving a database from on-premises to the cloud while keeping the source database fully operational and synchronizing changes in real-time is known as what type of migration?
  1. A ETL Migration
  2. B Offline Migration
  3. C Batch Migration
  4. D Online Migration
Xem giải thích

Đáp án

D — Online Migration (di chuyển trực tuyến).

Vì sao đúng

Đề mô tả đúng hai đặc điểm của di chuyển trực tuyến: CSDL nguồn vẫn hoạt động bình thường trong suốt quá trình, và thay đổi được đồng bộ theo thời gian thực.

⚠ Điểm mấu chốt — trực tuyến ↔ ngoại tuyến:

OFFLINE MIGRATION (ngoại tuyến)
        ↓
    1. DỪNG ứng dụng
    2. Sao lưu, chuyển, khôi phục
    3. Bật lại ứng dụng
        ↓
    ⚠ THỜI GIAN NGỪNG = toàn bộ
      thời gian chuyển dữ liệu
    → có thể hàng giờ tới hàng ngày

ONLINE MIGRATION (trực tuyến)   ← đề này
        ↓
    1. Sao chép ban đầu (nguồn vẫn chạy)
    2. CDC — bắt và phát lại thay đổi
       liên tục
    3. Khi độ trễ gần bằng 0 → CẮT CHUYỂN
        ↓
    ⚠ Thời gian ngừng chỉ là VÀI PHÚT
      của bước cắt chuyển

⚠ CDC — cơ chế làm nên di chuyển trực tuyến:

Change Data Capture
        ↓
    Đọc NHẬT KÝ GIAO DỊCH của CSDL nguồn
      MySQL   → binlog
      PostgreSQL → WAL / logical replication
      Oracle  → redo log
        ↓
    Phát lại các thay đổi lên đích
        ↓
    ⚠ KHÔNG cần truy vấn bảng nguồn liên tục
    → ít ảnh hưởng tới hiệu năng ứng dụng

⚠ Ba giai đoạn của một lần di chuyển trực tuyến:

1. FULL DUMP — sao chép toàn bộ dữ liệu hiện có
        ↓
2. CDC — bắt kịp và bám theo thay đổi
        ↓
    Theo dõi REPLICATION LAG
        ↓
3. CUTOVER — khi lag gần 0:
     - dừng ghi ở nguồn (vài phút)
     - đợi lag về 0
     - trỏ ứng dụng sang đích
     - thăng cấp đích thành máy chính

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

  • B (Offline Migration) — đây là phương án đối lập trực tiếp: phải dừng CSDL nguồn trong suốt quá trình.

  • C (Batch Migration) — chuyển theo lô định kỳ, không đồng bộ thời gian thực và thường có thời gian ngừng.

  • A (ETL Migration) — không phải thuật ngữ chuẩn cho việc này; ETL là quy trình biến đổi dữ liệu cho phân tích, không phải kiểu di chuyển CSDL.

Ghi nhớ

⚠ Hai kiểu di chuyển — bảng phải thuộc: | | Online | Offline | |---|---|---| | Nguồn trong lúc chuyển | vẫn HOẠT ĐỘNG | PHẢI DỪNG | | Đồng bộ thay đổi | CDC thời gian thực | không | | Thời gian ngừng | vài phút (cắt chuyển) | toàn bộ thời gian chuyển | | Độ phức tạp | cao hơn | thấp | | Dùng khi | hệ thống quan trọng, không được ngừng lâu | dữ liệu nhỏ, chấp nhận ngừng |

Từ khoá nhận diện:

"nguồn vẫn chạy, đồng bộ thời gian thực" → online migration "dừng ứng dụng rồi chuyển" → offline migration "bắt thay đổi từ nhật ký giao dịch" → CDC "chuyển CSDL sang Cloud SQL" → Database Migration Service "đồng bộ CSDL vào BigQuery" → Datastream

Công cụ di chuyển trực tuyến trên GCP Công cụ
Database Migration Service CSDL → Cloud SQL / AlloyDB, có CDC, miễn phí
Datastream CDC → BigQuery, Cloud Storage
Nhân bản gốc của CSDL binlog replication tự dựng
Storage Transfer Service cho tệp, không phải CSDL
Transfer Appliance khối lượng rất lớn, ngoại tuyến
Chuẩn bị trước khi di chuyển trực tuyến Việc
Bật nhật ký giao dịch ở nguồn binlog ROW, hoặc wal_level=logical
Tài khoản có quyền đọc nhật ký
Đường mạng riêng VPN, Interconnect, hoặc Private Service Connect
Kiểm tra tính tương thích phiên bản, engine bảng, tính năng không hỗ trợ
Mọi bảng phải có KHOÁ CHÍNH bảng không khoá chính là vấn đề lớn với CDC
Kế hoạch cắt chuyển (cutover) Bước
1 Theo dõi replication lag tới khi gần 0
2 Đặt ứng dụng ở chế độ chỉ đọc hoặc dừng ghi
3 Đợi lag về 0
4 Đối chiếu số dòng và checksum
5 Thăng cấp đích, trỏ ứng dụng sang
6 Giữ nguồn thêm một thời gian để quay lui nếu cần
Đừng quên phần "quay lui" Nội dung
Giữ CSDL nguồn ít nhất vài ngày đừng xoá vội
Kịch bản quay lui viết sẵn ai làm gì
Đo hiệu năng trên đích trước tránh bất ngờ về tốc độ
Kiểm thử ứng dụng đầy đủ chuỗi kết nối, driver, charset
Sai lầm cắt chuyển vào tối thứ Sáu mà không có đường lùi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ nhân bản bao nhiêu | DMS console, hoặc chỉ số của Datastream | | Dữ liệu đã khớp chưa | so COUNT(*) từng bảng và checksum | | Nguồn có bị ảnh hưởng hiệu năng không | theo dõi tải trên CSDL nguồn |

Và một điều kiện kỹ thuật rất hay chặn đứng kế hoạch di chuyển trực tuyến ở phút chót: bảng không có khoá chính. CDC cần khoá để xác định dòng nào vừa thay đổi, nên những bảng thiếu khoá chính hoặc thiếu chỉ mục duy nhất thường phải xử lý riêng — kiểm tra điều này ngay từ giai đoạn khảo sát, chứ không phải khi công cụ báo lỗi.

Câu 77 Data Management

A team is deciding between Cloud Data Fusion and Database Migration Service (DMS) for a data-moving task.

When should the team choose DMS?

  1. A When the goal is to replicate an entire operational MySQL database to Cloud SQL as a fully functional, transactional system.
  2. B When the goal is to extract data from a database, transform its structure, and load it into BigQuery for analysis.
  3. C When the project requires a visual, code-free interface to build a complex data transformation workflow.
  4. D When data needs to be loaded into BigQuery from a SaaS application like Google Ads.
Xem giải thích

Đáp án

A — Khi mục tiêu là NHÂN BẢN toàn bộ CSDL MySQL đang vận hành sang Cloud SQL thành một hệ thống GIAO DỊCH hoạt động đầy đủ.

Vì sao đúng

Database Migration Service sinh ra cho đúng một việc: chuyển một CSDL vận hành sang dịch vụ CSDL được quản lý của Google Cloud, giữ nguyên cấu trúc và tính giao dịch.

⚠ Điểm mấu chốt — DMS và Data Fusion khác nhau ở MỤC ĐÍCH:

DATABASE MIGRATION SERVICE
        ↓
    Nguồn: MySQL, PostgreSQL, Oracle,
           SQL Server
    Đích:  Cloud SQL, AlloyDB
        ↓
    Mục tiêu: BẢN SAO TRUNG THÀNH
      → giữ nguyên lược đồ
      → giữ nguyên tính giao dịch
      → CSDL đích thay thế được CSDL nguồn
        ↓
    ⚠ KHÔNG biến đổi dữ liệu

CLOUD DATA FUSION
        ↓
    Nguồn: đủ loại
    Đích:  BigQuery, GCS, và nhiều nơi
        ↓
    Mục tiêu: XÂY PIPELINE PHÂN TÍCH
      → biến đổi, làm sạch, tổng hợp
      → giao diện kéo thả

⚠ Câu hỏi phân biệt đơn giản nhất:

"Đích đến có phải là một CSDL
 GIAO DỊCH thay thế cho cái cũ không?"
        ↓
    CÓ  → Database Migration Service
    KHÔNG (đích là kho phân tích)
        → Data Fusion, Datastream,
          hoặc Dataflow

⚠ Ưu điểm của DMS trong tình huống này:

- MIỄN PHÍ với chuyển đồng nhất
  (MySQL → Cloud SQL for MySQL)
- Có CDC → thời gian ngừng rất ngắn
- Tự kiểm tra tính tương thích trước
- Tự tạo instance đích
- Theo dõi replication lag trong console
- Thăng cấp đích bằng một thao tác

Xem thêm câu #12981 (lô 134): cùng so sánh các công cụ chuyển dữ liệu, nhưng ở đó đích là BigQuery và yêu cầu biến đổi trực quan không lập trình → khoá là Cloud Data Fusion. Hai khoá khác nhau vì đích và mục đích khác nhau — hai câu bổ sung cho nhau.

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

  • B (trích xuất, biến đổi cấu trúc, nạp vào BigQuery để phân tích) — đây là phương án gần nhất và mô tả đúng việc của Data Fusion hoặc Datastream, không phải DMS. DMS không đưa dữ liệu vào BigQuery và không biến đổi cấu trúc.

  • C (giao diện trực quan, không cần mã, luồng biến đổi phức tạp) — mô tả Cloud Data Fusion.

  • D (nạp vào BigQuery từ SaaS như Google Ads) — mô tả BigQuery Data Transfer Service.

Ghi nhớ

⚠ Bốn dịch vụ chuyển dữ liệu — bảng phải thuộc: | Dịch vụ | Nguồn → Đích | Mục đích | |---|---|---| | Database Migration Service | CSDL → Cloud SQL / AlloyDB | bản sao GIAO DỊCH trung thành | | Datastream | CSDL → BigQuery, GCS | CDC cho PHÂN TÍCH | | Cloud Data Fusion | nhiều nguồn → nhiều đích | ETL trực quan, có biến đổi | | BigQuery Data Transfer Service | SaaS, kho → BigQuery | nạp theo lịch | | Storage Transfer Service | kho đối tượng → GCS | chuyển TỆP |

Từ khoá nhận diện:

"MySQL → Cloud SQL, giữ nguyên giao dịch" → DMS "CSDL → BigQuery, gần thời gian thực" → Datastream "kéo thả, biến đổi, → BigQuery" → Cloud Data Fusion "Google Ads → BigQuery" → Data Transfer Service "S3 → GCS" → Storage Transfer Service

DMS — điều cần nhớ Nội dung
Chuyển đồng nhất (MySQL→MySQL) MIỄN PHÍ
Chuyển không đồng nhất (Oracle→PostgreSQL) có phí, phức tạp hơn
CDC thời gian ngừng rất ngắn
Kiểm tra trước báo trước các vấn đề tương thích
Kết nối VPN, Interconnect, hoặc IP allowlist
Thăng cấp đích một thao tác trong console
Điều kiện phía nguồn với MySQL Điều kiện
log_bin = ON bật nhật ký nhị phân
binlog_format = ROW bắt buộc cho CDC
binlog_row_image = FULL
Tài khoản có REPLICATION SLAVE
Mọi bảng có khoá chính rất quan trọng
Giữ binlog đủ lâu tránh mất thay đổi khi chậm
Datastream — khi đích là BigQuery Nội dung
Việc CDC từ CSDL vào BigQuery gần thời gian thực
Nguồn Oracle, MySQL, PostgreSQL, SQL Server
Ghi thẳng vào BigQuery không cần Dataflow
Dùng khi muốn phân tích trên dữ liệu vận hành mà không đụng CSDL gốc
Khác DMS đích là kho phân tích, không phải CSDL thay thế
Mẫu kiến trúc hay gặp trong thực tế Mẫu
DMS đưa CSDL lên Cloud SQL hệ thống vận hành
Datastream đồng bộ Cloud SQL → BigQuery phân tích
Dataform biến đổi trong BigQuery mô hình dữ liệu
Looker Studio hiển thị báo cáo
Kết quả tách bạch OLTP và OLAP mà vẫn gần thời gian thực

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Job DMS đang ở giai đoạn nào | console → Database Migration → Migration jobs | | Độ trễ nhân bản | cùng màn hình, chỉ số replication delay | | Dữ liệu đã khớp chưa | so COUNT(*) và checksum từng bảng |

Và một cách phân biệt nhanh nếu gặp câu hỏi tương tự trong phòng thi: nhìn vào ĐÍCH. Đích là Cloud SQL hay AlloyDB thì gần như chắc chắn là Database Migration Service; đích là BigQuery hoặc Cloud Storage thì phải là Datastream, Data Fusion hoặc Dataflow — và câu hỏi chỉ còn là "có cần biến đổi không, và đội có viết mã được không".

Câu 78 Data Analysis and Presentation

A team is analyzing a large website_clicks table in BigQuery. They want to find the top 5 most visited pages for each day in the last month. The table contains the columns visit_date, page_path, and session_id.

Which two SQL features are essential for writing this query efficiently?

  1. A Window Functions (like RANK or ROW_NUMBER) and PARTITION BY
  2. B JOIN and UNION
  3. C GROUP BY and HAVING
  4. D Federated Queries and LIMIT
Xem giải thích

Đáp án

A — Hàm cửa sổ (như RANK hoặc ROW_NUMBER) kết hợp với PARTITION BY.

Vì sao đúng

Yêu cầu là top 5 trang được xem nhiều nhất CHO MỖI NGÀY. Cụm "top N trong từng nhóm" là dấu hiệu kinh điển của hàm cửa sổ có PARTITION BY.

⚠ Điểm mấu chốt — truy vấn đầy đủ:

WITH luot_xem AS (
  SELECT visit_date, page_path,
         COUNT(*) AS so_luot
  FROM `du_an.website_clicks`
  WHERE visit_date >= DATE_SUB(CURRENT_DATE(),
                               INTERVAL 30 DAY)
  GROUP BY visit_date, page_path
)
SELECT visit_date, page_path, so_luot
FROM luot_xem
QUALIFY ROW_NUMBER() OVER (
  PARTITION BY visit_date
  ORDER BY so_luot DESC
) <= 5;

        ↓
    GROUP BY  → đếm lượt mỗi trang mỗi ngày
    PARTITION BY visit_date
              → xếp hạng RIÊNG trong TỪNG NGÀY
    <= 5      → lấy top 5

⚠ Vì sao chỉ GROUP BY + HAVING là KHÔNG đủ:

GROUP BY visit_date, page_path
        ↓
    → đếm được lượt xem mỗi trang mỗi ngày
    → ✓ bước này CẦN THIẾT

HAVING ...
        ↓
    ⚠ lọc theo GIÁ TRỊ TỔNG HỢP
      (ví dụ "trên 1000 lượt")
    ⚠ KHÔNG diễn đạt được
      "5 dòng CAO NHẤT trong mỗi nhóm"
        ↓
    → cần XẾP HẠNG, mà xếp hạng
      trong từng nhóm là việc của
      HÀM CỬA SỔ

⚠ PARTITION BY — thứ làm nên "trong mỗi ngày":

KHÔNG có PARTITION BY
        ↓
    ROW_NUMBER() OVER (ORDER BY so_luot DESC)
        ↓
    → top 5 của CẢ THÁNG
    → có thể toàn của một ngày duy nhất

CÓ PARTITION BY visit_date
        ↓
    → mỗi ngày có riêng hạng 1..5
    → 30 ngày × 5 = 150 dòng

Xem thêm câu #12971 (lô 134): cùng họ hàm cửa sổ, ở đó là chọn DENSE_RANK() vì yêu cầu hạng liên tục khi đồng hạng. Câu này hỏi hai tính năng cần dùng → hàm cửa sổ + PARTITION BY. Hai câu nhất quán.

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

  • C (GROUP BY và HAVING) — đây là phương án gần nhất và GROUP BY thực sự cần cho bước đếm, nhưng HAVING không xếp hạng được; nó chỉ lọc theo giá trị tổng hợp, không lấy được "5 cao nhất mỗi nhóm".

  • B (JOIN và UNION) — dùng để ghép bảng; ở đây chỉ có một bảng.

  • D (federated query và LIMIT) — federated query dùng cho nguồn dữ liệu ngoài; LIMIT cắt tổng thể, không cắt theo từng nhóm.

Ghi nhớ

⚠ Top-N theo nhóm — bảng phải thuộc: | Bước | Công cụ | |---|---| | Đếm/tổng hợp theo nhóm | GROUP BY | | Xếp hạng TRONG từng nhóm | hàm cửa sổ + PARTITION BY | | Lọc theo hạng | QUALIFY, hoặc bọc subquery + WHERE | | Cách gọn của BigQuery | ARRAY_AGG(... ORDER BY ... LIMIT n) | | Sai lầm | dùng LIMIT — cắt tổng thể, không theo nhóm |

Từ khoá nhận diện:

"top N TRONG MỖI nhóm" → hàm cửa sổ + PARTITION BY "tổng theo nhóm" → GROUP BY "chỉ lấy nhóm có tổng > X" → HAVING "so với dòng trước" → LAG / LEAD "cộng dồn theo thời gian" → SUM() OVER (ORDER BY ...)

Ba hàm xếp hạng — nhắc lại Hàm
ROW_NUMBER() luôn khác nhau — đúng N dòng
RANK() đồng hạng, có khoảng trống
DENSE_RANK() đồng hạng, không khoảng trống
Chọn ROW_NUMBER khi cần đúng 5 dòng
Chọn DENSE_RANK khi muốn lấy hết những trang đồng hạng 5
QUALIFY — cú pháp rất tiện của BigQuery Nội dung
Việc lọc trực tiếp trên hàm cửa sổ
Không có QUALIFY phải bọc trong subquery hoặc CTE
Vì sao WHERE chạy TRƯỚC SELECT, chưa có kết quả hàm cửa sổ
Cú pháp QUALIFY ROW_NUMBER() OVER (...) <= 5
Vị trí sau HAVING, trước ORDER BY
Cách viết thay thế bằng ARRAY_AGG Nội dung
Cú pháp ARRAY_AGG(STRUCT(page_path, so_luot) ORDER BY so_luot DESC LIMIT 5)
Ưu điểm rất hiệu quả — BigQuery tối ưu tốt
Kết quả một MẢNG top 5 cho mỗi ngày
Trải ra UNNEST nếu cần dạng bảng
Dùng khi top-N nhỏ và muốn giữ dạng lồng
Tối ưu truy vấn này trên bảng lớn Cách
Lọc theo cột PHÂN VÙNG trước WHERE visit_date >= ...
Chỉ chọn cột cần visit_date, page_path
Gộp trước, xếp hạng sau giảm dữ liệu phải sắp xếp rất nhiều
Phân cụm theo page_path nếu hay lọc theo trang
Kiểm tra --dry_run và Execution details

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết quả có đúng số dòng | 30 ngày × 5 = 150 (trừ ngày ít trang) | | Có bị lẫn giữa các ngày không | kiểm tra PARTITION BY visit_date | | Đồng hạng xử lý thế nào | so ROW_NUMBER và DENSE_RANK trên cùng dữ liệu |

Và một quyết định nhỏ nhưng nên nói rõ với người đặt yêu cầu: khi hai trang có cùng số lượt ở vị trí thứ 5, báo cáo lấy một hay lấy cả hai? ROW_NUMBER cho đúng 5 dòng nhưng chọn tuỳ ý một trong hai; DENSE_RANK giữ cả hai và cho ra 6 dòng. Cả hai đều đúng — chỉ cần thống nhất trước để không phải giải thích sau.

Câu 79 Data Analysis and Presentation

A company adopts an ELT (Extract, Load, Transform) pattern, loading raw JSON (JavaScript Object Notation) data from its event bus directly into a staging table in BigQuery.

What is a key advantage of this approach compared to a traditional ETL (Extract, Transform, Load) pipeline?

  1. A It allows for the preservation of the raw, unaltered source data within the data warehouse for future reprocessing or auditing.
  2. B It reduces the overall storage cost because raw data is smaller than transformed data.
  3. C It is the only method capable of handling real-time, streaming data workloads.
  4. D It ensures that only perfectly structured and validated data ever enters the data warehouse.
Xem giải thích

Đáp án

A — Cho phép GIỮ LẠI dữ liệu nguồn THÔ, nguyên vẹn, ngay trong kho dữ liệu, phục vụ việc xử lý lại hoặc kiểm toán về sau.

Vì sao đúng

Đây là ưu điểm cốt lõi và thật sự của ELT: nạp dữ liệu thô vào kho trước nghĩa là bản gốc luôn còn đó, và mọi phép biến đổi đều có thể làm lại từ đầu mà không cần đụng tới hệ thống nguồn.

⚠ Điểm mấu chốt — giữ dữ liệu thô mở ra ba khả năng:

1. LOGIC BIẾN ĐỔI THAY ĐỔI
    → chạy lại từ bảng thô
    → không phải trích xuất lại từ nguồn

2. PHÁT HIỆN LỖI BIẾN ĐỔI
    → đối chiếu kết quả với dữ liệu thô
    → tìm ra sai ở bước nào

3. CÂU HỎI MỚI XUẤT HIỆN
    → trường mà bản tổng hợp đã bỏ đi
      vẫn còn trong bảng thô
        ↓
    ⚠ Với ETL, cả ba đều đòi
      TRÍCH XUẤT LẠI TỪ NGUỒN

⚠ Vì sao điều này đặc biệt đúng với JSON:

Dữ liệu sự kiện dạng JSON
        ↓
    Lược đồ HAY THAY ĐỔI theo thời gian
        ↓
    ETL: phải quyết định TRƯỚC
         lấy trường nào
         → trường mới thêm sẽ bị bỏ mất
        ↓
    ELT: nạp NGUYÊN VẸN vào kiểu JSON
         hoặc STRUCT
         → trường mới vẫn nằm đó
         → khai thác được bất cứ lúc nào

⚠ Cấu trúc ba tầng đi kèm ELT:

RAW      → y hệt nguồn, không sửa gì
             = "bản ghi gốc" cho kiểm toán
STAGING  → làm sạch, ép kiểu, loại trùng
CURATED  → mô hình nghiệp vụ, bảng báo cáo
        ↓
    Mỗi tầng dựng lại được từ tầng trước

Xem thêm câu #12958 (lô 134): cùng chủ đề, ở đó hỏi TÊN GỌI của luồng → khoá ELT. Và #12913 (lô 133): khoá ETL vì phải che PII trước khi vào kho. Ba câu nhất quán: ELT là mặc định; ETL khi có ràng buộc tuân thủ.

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

  • D (bảo đảm chỉ dữ liệu đã được kiểm chứng mới vào kho) — đây là phương án gần nhất về ngữ nghĩa, nhưng nó mô tả ưu điểm của ETL, không phải ELT. ELT làm điều ngược lại: nạp cả dữ liệu thô, kể cả phần chưa sạch.

  • B (giảm chi phí lưu trữ vì dữ liệu thô nhỏ hơn dữ liệu đã biến đổi) — sai về thực tế: ELT thường TỐN THÊM dung lượng vì giữ cả bản thô lẫn bản đã xử lý.

  • C (là cách duy nhất xử lý được dữ liệu luồng thời gian thực) — sai: cả ETL lẫn ELT đều xử lý được dữ liệu luồng; đó không phải điểm phân biệt.

Ghi nhớ

⚠ ETL ↔ ELT — bảng phải thuộc: | | ETL | ELT | |---|---|---| | Thứ tự | biến đổi TRƯỚC khi nạp | nạp trước, biến đổi sau | | Dữ liệu thô trong kho | KHÔNG | CÓ | | Chạy lại logic mới | phải lấy lại từ nguồn | chạy lại từ bảng thô | | Chi phí lưu | thấp hơn | cao hơn | | Hợp với | PII không được vào kho | hầu hết trường hợp | | Nơi biến đổi | công cụ ngoài | trong kho (BigQuery SQL) |

Từ khoá nhận diện:

"giữ dữ liệu thô để xử lý lại" → ưu điểm của ELT "chỉ dữ liệu sạch mới vào kho" → ưu điểm của ETL "che PII trước khi nạp" → bắt buộc ETL "kho mạnh, biến đổi bằng SQL" → ELT "ELT tiết kiệm dung lượng" → SAI

Vì sao ELT trở thành mặc định Lý do
Kho hiện đại rất mạnh BigQuery biến đổi nhanh và rẻ
Lưu trữ rẻ giữ bản thô không tốn nhiều
Triển khai nhanh hơn ít hạ tầng trung gian
Linh hoạt đổi logic không cần đụng nguồn
Công cụ hỗ trợ tốt Dataform, dbt
Cái giá của ELT — nên biết trước Cái giá
Dữ liệu thô trong kho cần chính sách quyền chặt hơn
Chi phí lưu tăng giữ nhiều tầng
Kho có thể thành "đầm lầy dữ liệu" nếu không quản trị
Chi phí truy vấn biến đổi chạy trên kho tính tiền
Khắc phục vòng đời rõ ràng cho tầng raw, phân vùng, quyền hẹp
Xử lý JSON trong BigQuery Cách
Kiểu JSON gốc giữ nguyên, lược đồ động
STRUCT và ARRAY khai tường minh, truy vấn hiệu quả hơn
Hàm JSON_VALUE, JSON_QUERY, JSON_EXTRACT
UNNEST trải mảng thành dòng
Mẫu thường dùng raw giữ JSON, staging trải thành cột
Quản trị tầng raw Việc
Phân vùng theo ngày nạp dễ xoá, dễ chạy lại
Chính sách giữ bao lâu ví dụ 13 tháng rồi sang Archive
Quyền rất hẹp thô có thể chứa PII
Không cho báo cáo đọc trực tiếp chỉ đọc tầng curated
Ghi chú nguồn gốc tệp nào, lúc nào, phiên bản nào

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng thô có nguyên vẹn không | so số dòng với nguồn | | Chạy lại có ra cùng kết quả không | kiểm thử tính lặp lại được | | Tầng raw tốn bao nhiêu | INFORMATION_SCHEMA.TABLE_STORAGE |

Và một điều nên chốt ngay khi chọn ELT, trước khi tầng raw kịp phình to: giữ dữ liệu thô bao lâu và ai được đọc nó. Không có câu trả lời cho hai câu hỏi đó, tầng raw sẽ vừa tăng chi phí đều đặn vừa trở thành nơi tập trung dữ liệu nhạy cảm mà không ai nhớ đã cấp quyền cho những ai.

Câu 80 Data Preparation and Ingestion

You are running a Dataflow pipeline that reads data from Cloud Storage, transforms it, and writes it to BigQuery. The pipeline is running much slower than expected. When you inspect the job in the Dataflow monitoring UI, you see that the bottleneck is the final "Write to BigQuery" step.

What is a common optimization to improve the write performance of a Dataflow pipeline to BigQuery?

  1. A Increase the number of vCPUs on the Dataflow workers.
  2. B

    Use the Storage Write API
  3. C Set a lower num_workers value to reduce write contention.
  4. D Change the BigQuery table's storage from physical to logical.
Xem giải thích

Đáp án

B — Dùng Storage Write API.

Vì sao đúng

Nút thắt nằm ở bước GHI vào BigQuery, và Storage Write API là giao diện ghi thế hệ mới của BigQuery — nhanh hơn, rẻ hơn và đáng tin cậy hơn các cách ghi cũ.

⚠ Điểm mấu chốt — ba cách ghi vào BigQuery từ Dataflow:

LOAD JOB (theo lô)
    → gom thành tệp rồi nạp
    → có ĐỘ TRỄ, có hạn mức số job
    → miễn phí nhưng chậm

STREAMING INSERT (tabledata.insertAll — API CŨ)
    → ghi từng dòng
    → độ trễ thấp nhưng ĐẮT
    → giới hạn hạn mức, chỉ at-least-once

STORAGE WRITE API                  ← khuyến nghị
    → giao thức gRPC hiệu năng cao
    → thông lượng CAO HƠN, giá RẺ HƠN
    → hỗ trợ EXACTLY-ONCE
    → dùng chung cho cả LÔ và LUỒNG

⚠ Bật trong Dataflow:

BigQueryIO.writeTableRows()
  .withMethod(BigQueryIO.Write.Method.STORAGE_WRITE_API)
  .withTriggeringFrequency(Duration.standardSeconds(30))
  .withNumStorageWriteApiStreams(10)

        ↓
    ⚠ Với pipeline luồng, đây thường là
      thay đổi một dòng cho hiệu quả rất lớn

⚠ Vì sao tăng vCPU thường KHÔNG giải quyết được:

Nút thắt ở bước GHI
        ↓
    → worker đang CHỜ BigQuery nhận dữ liệu,
      không phải thiếu CPU
        ↓
    ⚠ Thêm vCPU → worker chờ nhanh hơn?
    → không, chỉ tốn tiền hơn
        ↓
    Nguyên tắc gỡ nút thắt:
      SỬA ĐÚNG bước đang nghẽn,
      đừng ném thêm tài nguyên vào cả job

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

  • A (tăng vCPU của worker) — đây là phản xạ thường gặp nhất, nhưng nút thắt là thông lượng ghi, không phải năng lực tính toán; thêm CPU chỉ làm tăng chi phí.

  • C (giảm num_workers để bớt tranh chấp ghi) — làm chậm hơn nữa; BigQuery được thiết kế để nhận ghi song song.

  • D (đổi bảng từ physical sang logical storage billing) — chỉ là cách TÍNH TIỀN lưu trữ, không ảnh hưởng gì tới hiệu năng ghi.

Ghi nhớ

⚠ Các cách ghi vào BigQuery — bảng phải thuộc: | Cách | Độ trễ | Chi phí | Ghi chú | |---|---|---|---| | Load job | cao (theo lô) | miễn phí | hạn mức số job/ngày | | Streaming insert (cũ) | thấp | đắt | at-least-once | | Storage Write API | thấp | rẻ hơn streaming | exactly-once, dùng cho cả lô lẫn luồng | | Khuyến nghị hiện nay | Storage Write API cho hầu hết trường hợp |

Từ khoá nhận diện:

"ghi vào BigQuery chậm" → Storage Write API "nạp tệp lớn theo lô, miễn phí" → load job "pipeline chậm vì CPU" → mới xét tới loại máy worker "hot key, dữ liệu lệch" → sửa khoá, không phải thêm worker "trạng thái luồng lớn" → Streaming Engine

Quy trình gỡ nút thắt pipeline Dataflow Bước
1 Job graph — xác định BƯỚC nào nghẽn
2 Xem throughput vào/ra của bước đó
3 Xem CPU utilization của worker
4 CPU thấp mà vẫn chậm → nghẽn ở I/O hoặc đích
5 CPU cao → tăng worker hoặc đổi loại máy
6 Một worker chậm hẳn → dữ liệu lệch (hot key)
Tối ưu khác cho Dataflow Cách
Streaming Engine tách trạng thái khỏi worker
Dataflow Prime tự điều chỉnh tài nguyên theo bước
Fusion Beam tự gộp các bước — có thể cần Reshuffle để tách
Combiner gộp sớm để giảm dữ liệu phải trộn
Side input nhỏ tránh join lớn không cần thiết
Storage Write API — điều cần nhớ Nội dung
Giao thức gRPC, hai chiều
Ngữ nghĩa exactly-once trong stream
Chế độ committed (thấy ngay), pending (commit theo lô)
Giá rẻ hơn streaming insert đáng kể, có mức miễn phí
Hỗ trợ Dataflow, thư viện client, và Pub/Sub BigQuery subscription
Thay thế API insertAll cũ
Khi ghi vào BigQuery vẫn chậm dù đã dùng Write API Kiểm
Số stream ghi song song withNumStorageWriteApiStreams
Lược đồ không khớp mỗi dòng lỗi làm chậm và sinh retry
Bảng có quá nhiều phân vùng bị ghi cùng lúc
Hạn mức của project kiểm tra quota
Dead-letter tách dòng hỏng ra thay vì để chúng làm nghẽn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bước nào là nút thắt | Dataflow Job graph, xem throughput từng bước | | Worker có bận không | CPU utilization trong Job metrics | | Ghi có bị lỗi dòng không | log của bước ghi và bảng dead-letter |

Và một nguyên tắc đáng nhớ mỗi khi một pipeline chạy chậm: đọc biểu đồ trước khi thêm tài nguyên. Nếu CPU của worker chỉ ở mức thấp mà job vẫn ì ạch, vấn đề gần như chắc chắn nằm ở đầu vào hoặc đầu ra chứ không ở năng lực tính toán — và tăng số worker trong tình huống đó chỉ tạo ra thêm những worker cùng ngồi chờ.