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

Đáp án

A — Pub/Sub và Dataflow.

Vì sao đúng

Đề có bốn ràng buộc: luồng sự kiện IoT liên tục, khối lượng lớn, xử lý thời gian thực, tổng hợp theo CỬA SỔ, và hoàn toàn không máy chủ. Cặp Pub/Sub + Dataflow là kiến trúc chuẩn cho đúng bài toán này.

⚠ Điểm mấu chốt — mỗi dịch vụ một vai trò:

Thiết bị IoT
        ↓
    PUB/SUB
        → thu nhận, làm BỘ ĐỆM
        → chịu được đỉnh tải
        → tách rời thiết bị khỏi xử lý
        ↓
    DATAFLOW (Apache Beam)
        → xử lý luồng
        → TỔNG HỢP THEO CỬA SỔ
        → xử lý dữ liệu tới muộn
        ↓
    BIGQUERY
        → lưu kết quả để phân tích

⚠ Cửa sổ — thứ chỉ Dataflow làm tốt trong bốn phương án:

FIXED WINDOW (cửa sổ cố định)
    → mỗi 5 phút một cửa sổ, không chồng lấn

SLIDING WINDOW (cửa sổ trượt)
    → 10 phút, trượt mỗi 1 phút → chồng lấn

SESSION WINDOW (cửa sổ phiên)
    → gom theo khoảng lặng giữa các sự kiện
        ↓
    Đây là mô hình của Apache Beam,
    Dataflow triển khai đầy đủ

⚠ Thời điểm sự kiện ↔ thời điểm xử lý — điều quyết định độ đúng:

Cảm biến IoT gửi lúc 10:00
        ↓
    Mạng chập chờn, tới hệ thống lúc 10:07
        ↓
    ⚠ Tính vào cửa sổ NÀO?

Beam dùng EVENT TIME
    → tính theo lúc SỰ KIỆN XẢY RA
        ↓
    + WATERMARK: ước lượng "đã nhận đủ chưa"
    + ALLOWED LATENESS: chấp nhận trễ bao lâu
    + TRIGGER: khi nào phát kết quả
        ↓
    → kết quả ĐÚNG dù dữ liệu tới lộn xộn

Xem thêm câu #12949 (cùng lô): nói riêng về vai trò bộ đệm của Pub/Sub. Và #12930 (lô 133): theo dõi chính pipeline Dataflow luồng này. Ba câu mô tả ba phần của cùng một kiến trúc.

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

• B (Eventarc và Cloud Run) — đây là phương án gần nhất vì cũng không máy chủ và xử lý theo sự kiện, nhưng Cloud Run xử lý TỪNG request độc lập; nó không có mô hình cửa sổ, watermark hay trạng thái luồng. Tự dựng lại những thứ đó là công việc rất lớn.

• D (Cloud Storage và Dataproc) — đây là mô hình xử lý theo LÔ, không phải thời gian thực; Dataproc cũng không phải serverless (trừ Serverless for Spark, nhưng vẫn thiên về lô).

• C (Cloud SQL và Cloud Functions) — Cloud SQL không kham nổi luồng ghi lớn liên tục, và cũng không có cơ chế tổng hợp theo cửa sổ.

Ghi nhớ

⚠ Kiến trúc luồng chuẩn trên Google Cloud — bảng phải thuộc: | Vai trò | Dịch vụ | |---|---| | Thu nhận và làm bộ đệm | Pub/Sub | | Xử lý luồng, tổng hợp cửa sổ | Dataflow | | Lưu kết quả phân tích | BigQuery | | Lưu dữ liệu thô | Cloud Storage | | Trực quan hoá | Looker Studio | | Đặc thù IoT | thiết bị dùng MQTT → Pub/Sub qua cầu nối |

Từ khoá nhận diện:

"luồng thời gian thực + cửa sổ + serverless" → Pub/Sub + Dataflow "xử lý theo lô trên tệp" → Dataproc hoặc Dataflow batch "một sự kiện, một hàm nhỏ" → Cloud Run function "nạp thẳng vào BigQuery không cần xử lý" → BigQuery subscription của Pub/Sub "đã có sẵn job Spark" → Dataproc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline có theo kịp không | Data freshness trong Job metrics | | Pub/Sub có tồn đọng không | num_undelivered_messages | | Dữ liệu trễ có bị bỏ không | đếm bản ghi bị loại vì quá allowed lateness |

Và một quyết định thiết kế đáng cân nhắc kỹ với dữ liệu IoT: allowed lateness đặt bao lâu. Cảm biến ở vùng sóng yếu có thể gửi dữ liệu trễ hàng giờ; đặt quá ngắn thì mất dữ liệu, đặt quá dài thì pipeline phải giữ trạng thái của mọi cửa sổ mở trong suốt khoảng đó — và chi phí bộ nhớ của lựa chọn đó thường chỉ lộ ra khi hệ thống đã chạy được vài tuần.

Đáp án

C — Storage Object Admin (roles/storage.objectAdmin).

Vì sao đúng

Yêu cầu tách rất rõ hai nhóm quyền: toàn quyền trên ĐỐI TƯỢNG (tải lên, tải xuống, liệt kê, xoá), nhưng KHÔNG được xoá bucket hay đổi IAM của bucket. Đó chính là ranh giới của objectAdmin.

⚠ Điểm mấu chốt — ranh giới giữa "đối tượng" và "bucket":

roles/storage.objectAdmin
        ↓
    CÓ:
      storage.objects.create  (tải lên)
      storage.objects.get     (tải xuống)
      storage.objects.list    (liệt kê)
      storage.objects.delete  (xoá)
      storage.objects.update
        ↓
    KHÔNG CÓ:
      storage.buckets.delete   ← không xoá bucket
      storage.buckets.setIamPolicy ← không đổi quyền
      storage.buckets.update
        ↓
    ⚠ Khớp CHÍNH XÁC yêu cầu của đề

⚠ Cấp ở đúng phạm vi — cũng là một phần của quyền tối thiểu:

gcloud storage buckets add-iam-policy-binding \
  gs://ten-bucket \
  --member="user:dev@congty.com" \
  --role="roles/storage.objectAdmin"
        ↓
    ⚠ Cấp TRÊN BUCKET, không phải trên PROJECT
        ↓
    Cấp ở cấp project → người đó có quyền
    trên MỌI bucket, kể cả những cái
    họ không nên chạm tới

⚠ Vì sao Storage Admin là quá rộng:

roles/storage.admin
        ↓
    = objectAdmin
      + TOÀN QUYỀN TRÊN BUCKET
        ↓
    → xoá được cả bucket
    → đổi được IAM policy
    → có thể tự cấp thêm quyền cho mình
        ↓
    ⚠ Vi phạm trực tiếp hai điều
      mà đề cấm

Xem thêm câu #12956 và #12957 (cùng lô): cùng chủ đề chọn vai trò tối thiểu, nhưng cho xem toàn project và cho chạy truy vấn BigQuery. Ba câu, ba vai trò khác nhau, cùng một nguyên tắc.

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

• B (Storage Admin) — đây là phương án gần nhất và làm được mọi việc đề cần, nhưng nó thêm cả quyền xoá bucket và đổi IAM — đúng hai thứ đề cấm.

• A (Project Editor) — quá rộng một cách nguy hiểm: quyền sửa gần như mọi tài nguyên trong toàn bộ project.

• D (Storage Legacy Bucket Owner) — vai trò kế thừa từ hệ ACL cũ, cho quyền trên chính bucket (kể cả sửa metadata bucket), và không nên dùng cho phân quyền mới.

Ghi nhớ

⚠ Các vai trò Cloud Storage — bảng phải thuộc: | Vai trò | Cho phép | |---|---| | roles/storage.objectViewer | đọc và liệt kê đối tượng | | roles/storage.objectCreator | tạo mới — KHÔNG đọc, KHÔNG ghi đè | | roles/storage.objectUser | đọc, tạo, sửa, xoá đối tượng | | roles/storage.objectAdmin | toàn quyền ĐỐI TƯỢNG, không đụng bucket | | roles/storage.admin | cả bucket lẫn đối tượng | | roles/storage.legacy* | hệ ACL cũ — tránh dùng |

Từ khoá nhận diện:

"toàn quyền tệp, không đụng bucket" → storage.objectAdmin "chỉ tải lên, không đọc lại được" → storage.objectCreator — hay dùng cho nhật ký "chỉ đọc" → storage.objectViewer "tạo và xoá bucket" → storage.admin "Project Editor cho nhanh" → luôn là phương án SAI trong câu hỏi quyền tối thiểu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có quyền gì trên bucket | gcloud storage buckets get-iam-policy gs://b | | Vai trò gồm permission nào | gcloud iam roles describe roles/storage.objectAdmin | | Có quyền thừa không | IAM Recommender |

Và một chi tiết dễ bỏ qua khi cấp objectAdmin: cấp nó trên chính bucket, đừng cấp ở cấp project. Cùng một vai trò nhưng khác phạm vi là khác biệt giữa "một lập trình viên toàn quyền trên bucket của họ" và "một lập trình viên xoá được mọi tệp trong mọi bucket của công ty" — và cả hai trường hợp đều hiện lên như nhau trong danh sách vai trò nếu không nhìn kỹ phạm vi.

Đáp án

C — Data transformation (biến đổi dữ liệu).

Vì sao đúng

Việc trong đề là thay đổi giá trị dữ liệu: đưa "US", "USA", "United States", "us" về cùng một dạng chuẩn "US". Thay đổi dữ liệu để nó dùng được chính là biến đổi.

⚠ Điểm mấu chốt — đánh giá ↔ biến đổi, ranh giới rất rõ:

ĐÁNH GIÁ CHẤT LƯỢNG (assess)
        ↓
    "Cột country_code có 4 biến thể
     khác nhau cho cùng một nước"
        ↓
    → PHÁT HIỆN vấn đề, KHÔNG sửa

BIẾN ĐỔI (transform)          ← đề này
        ↓
    "Chạy script đưa tất cả về 'US'"
        ↓
    → THAY ĐỔI dữ liệu để sửa vấn đề

⚠ Chuẩn hoá bằng SQL:

SELECT
  CASE UPPER(TRIM(country_code))
    WHEN 'US' THEN 'US'
    WHEN 'USA' THEN 'US'
    WHEN 'UNITED STATES' THEN 'US'
    WHEN 'U.S.A.' THEN 'US'
    ELSE UPPER(TRIM(country_code))
  END AS country_code_chuan
FROM `du_an.khach_hang`;

⚠ Cách làm bền hơn — bảng ánh xạ:

Thay vì CASE dài vô tận trong truy vấn
        ↓
    Tạo BẢNG ÁNH XẠ:
      gia_tri_tho | gia_tri_chuan
      'USA'       | 'US'
      'us'        | 'US'
      'Viet Nam'  | 'VN'
        ↓
    LEFT JOIN vào bảng đó
        ↓
    → thêm biến thể mới chỉ cần THÊM DÒNG,
      không phải sửa mã
    → giá trị KHÔNG khớp lộ ra ngay
      (thành NULL) → biết mà bổ sung

Xem thêm câu #12943 (cùng lô): cùng nói về khâu chuẩn bị dữ liệu, nhưng ở đó là KIỂM TRA xem dữ liệu có hợp lệ không → khoá là đánh giá chất lượng dữ liệu. Câu này là SỬA dữ liệu → biến đổi. Hai bước liên tiếp, hai khoá khác nhau, không mâu thuẫn.

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

• A (đánh giá chất lượng dữ liệu) — đây là phương án gần nhất và là bước NGAY TRƯỚC: nó phát hiện ra rằng cột có nhiều biến thể, nhưng không sửa. Đề mô tả hành động sửa.

• D (nạp dữ liệu) — đưa dữ liệu vào hệ thống, xảy ra trước cả hai bước trên.

• B (lưu trữ dài hạn) — chuyển dữ liệu cũ sang nơi lưu rẻ, không liên quan.

Ghi nhớ

⚠ Các bước chuẩn bị dữ liệu — bảng phải thuộc: | Bước | Việc | |---|---| | Ingestion | đưa dữ liệu vào | | Assessing quality | PHÁT HIỆN vấn đề — không sửa | | Transformation | SỬA và định hình lại dữ liệu | | Loading | nạp vào kho đích | | Archiving | chuyển dữ liệu cũ sang lưu trữ rẻ |

Từ khoá nhận diện:

"chuẩn hoá, làm sạch, đổi kiểu, gộp" → biến đổi "kiểm tra rỗng, đúng định dạng, đúng khoảng" → đánh giá chất lượng "đưa dữ liệu vào hệ thống" → nạp "chuyển dữ liệu cũ sang lớp rẻ" → lưu trữ dài hạn "điều phối thứ tự các bước" → orchestration

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn bao nhiêu biến thể | SELECT country_code, COUNT(*) GROUP BY 1 ORDER BY 2 DESC | | Có giá trị nào không ánh xạ được | LEFT JOIN bảng ánh xạ, tìm NULL | | Biến đổi có làm mất dòng không | so COUNT(*) trước và sau |

Và một điều nên chuẩn bị sẵn ngay khi viết bước chuẩn hoá đầu tiên: chỗ để chứa những giá trị không ánh xạ được. Dữ liệu thật luôn sinh ra biến thể mới — "U.S.", "United States of America", một khoảng trắng thừa — và một bảng liệt kê những giá trị chưa khớp là cách duy nhất để bạn biết mà bổ sung, thay vì để chúng lặng lẽ rơi vào nhóm "khác".

Đáp án

D — Dataproc Workflow Templates.

Vì sao đúng

Đề cần một định nghĩa job DÙNG LẠI ĐƯỢC và THAM SỐ HOÁ ĐƯỢC, để ai trong đội cũng chạy được với đường dẫn vào/ra khác nhau mà không phải nhớ đống đối số dòng lệnh. Workflow Template là tính năng của Dataproc cho đúng việc đó.

⚠ Điểm mấu chốt — template là bản khai job có tham số:

gcloud dataproc workflow-templates create xu-ly-ban-hang \
  --region=asia-southeast1

gcloud dataproc workflow-templates add-job spark \
  --workflow-template=xu-ly-ban-hang \
  --step-id=buoc-chinh \
  --class=com.congty.XuLy \
  --jars=gs://bucket/job.jar \
  -- --input=PLACEHOLDER --output=PLACEHOLDER

gcloud dataproc workflow-templates set-managed-cluster \
  --workflow-template=xu-ly-ban-hang \
  --cluster-name=cum-tam --num-workers=4

        ↓
    Chạy với tham số khác nhau:
      gcloud dataproc workflow-templates instantiate \
        xu-ly-ban-hang \
        --parameters="INPUT=gs://a,OUTPUT=gs://b"

⚠ Điều quan trọng nhất — CỤM ĐƯỢC QUẢN LÝ:

set-managed-cluster
        ↓
    Khi chạy template:
      1. Dataproc TỰ TẠO cụm
      2. Chạy các job theo thứ tự
      3. TỰ XOÁ cụm khi xong
        ↓
    ⚠ Không có cụm nào nằm không mà tính tiền
    ⚠ Không ai quên tắt cụm
        ↓
    → đây là mẫu tiết kiệm nhất
      cho job Spark chạy định kỳ

⚠ Template cũng khai được PHỤ THUỘC giữa các bước:

add-job ... --step-id=buoc-a
add-job ... --step-id=buoc-b --start-after=buoc-a
        ↓
    → một DAG nhỏ NGAY TRONG Dataproc
        ↓
    Khác Composer ở chỗ:
      phạm vi chỉ trong Dataproc,
      không điều phối dịch vụ khác

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

• A (Cloud Composer) — đây là phương án gần nhất và hoàn toàn chạy được, nhưng đề hỏi rõ "tính năng nào CỦA DATAPROC". Composer là dịch vụ riêng, có chi phí môi trường thường trực, và là quá tay cho việc chuẩn hoá một job.

• B (Cloud Functions) — chạy một đoạn mã ngắn, không phải cơ chế định nghĩa job Spark.

• C (startup script tuỳ chỉnh) — chạy lúc VM khởi động; không tham số hoá job, không quản lý vòng đời cụm.

Ghi nhớ

⚠ Dataproc — các khái niệm cần thuộc: | Khái niệm | Nội dung | |---|---| | Workflow Template | định nghĩa job DÙNG LẠI, có THAM SỐ, có phụ thuộc | | Managed cluster | tự tạo và TỰ XOÁ cụm cho mỗi lần chạy | | Cluster selector | dùng cụm đang có, chọn theo nhãn | | Initialization action | script chạy khi tạo cụm | | Autoscaling policy | co giãn số worker | | Dataproc Serverless | chạy Spark KHÔNG cần cụm nào |

Từ khoá nhận diện:

"job Spark dùng lại, có tham số" → Workflow Template "chạy Spark không cần quản lý cụm" → Dataproc Serverless for Spark "điều phối NHIỀU dịch vụ khác nhau" → Cloud Composer "cụm luôn sẵn sàng cho nhiều người dùng" → cụm thường trực + autoscaling "cài thư viện lúc tạo cụm" → initialization action

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Template khai gì | gcloud dataproc workflow-templates describe <ten> --region=<r> | | Lần chạy gần nhất ra sao | gcloud dataproc operations list | | Cụm có bị bỏ quên không | gcloud dataproc clusters list — kiểm tra định kỳ |

Và một khoản chi phí rất hay bị bỏ quên với Dataproc: cụm thường trực không ai dùng. Workflow Template với managed cluster loại bỏ hoàn toàn rủi ro đó — cụm sinh ra khi cần và biến mất khi xong, nên không có cách nào để quên tắt nó.

Đáp án

C — Cấu hình một cross-region read replica (bản sao đọc ở Region khác).

Vì sao đúng

Yêu cầu là chịu được sự cố của CẢ MỘT REGION. Muốn vậy, dữ liệu phải có bản sao ở một Region khác, và Cloud SQL có sẵn tính năng đó.

⚠ Điểm mấu chốt — mỗi cơ chế chống một loại sự cố:

Cấu hình HA (regional)
        ↓
    Máy dự phòng ở ZONE KHÁC,
    CÙNG Region
        ↓
    ⚠ Cả Region chết → KHÔNG cứu được

CROSS-REGION READ REPLICA      ← đề này
        ↓
    Bản sao ở REGION KHÁC HẲN
        ↓
    Region chính chết
        ↓
    → THĂNG CẤP replica thành máy chính độc lập
    → dịch vụ hoạt động trở lại

⚠ Quy trình khi Region chính gặp sự cố:

gcloud sql instances promote-replica ten-replica
        ↓
    Replica trở thành instance ĐỘC LẬP,
    ghi được
        ↓
    Trỏ ứng dụng sang instance mới
        ↓
    ⚠ Đây là thao tác MỘT CHIỀU
      — không quay lại làm replica được
    ⚠ Nhân bản là BẤT ĐỒNG BỘ
      → có thể MẤT vài giao dịch cuối

⚠ Hai con số phải thống nhất với bên nghiệp vụ:

RPO (Recovery Point Objective)
    → chấp nhận MẤT bao nhiêu dữ liệu
    → với replica bất đồng bộ: vài giây

RTO (Recovery Time Objective)
    → chấp nhận NGỪNG bao lâu
    → thăng cấp replica: vài phút
        ↓
    Cần RPO = 0 và đa Region
      → phải dùng CLOUD SPANNER,
        không phải Cloud SQL

Xem thêm câu #12932 (cùng lô): cũng về bảo vệ dữ liệu của Cloud SQL, nhưng ở đó là khôi phục về một thời điểm → khoá là sao lưu tự động + PITR. Hai khoá khác nhau vì chống hai loại rủi ro khác nhau: PITR chống lỗi con người, replica đa Region chống sự cố hạ tầng. Một hệ thống nghiêm túc cần cả hai.

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

• B (bật sao lưu tự động) — đây là phương án gần nhất và bắt buộc phải có, nhưng khôi phục từ sao lưu mất hàng giờ, và bản sao lưu mặc định nằm cùng khu vực. Nó không phải cơ chế chịu lỗi Region.

• D (xuất CSDL sang Cloud Storage hằng ngày) — thủ công, chậm, mất tới một ngày dữ liệu, và cũng cần chọn bucket đa vùng mới thật sự an toàn.

• A (tăng vCPU và RAM) — cải thiện hiệu năng, không liên quan gì tới tính sẵn sàng.

Ghi nhớ

⚠ Bốn cơ chế của Cloud SQL và loại sự cố chúng chống — bảng phải thuộc: | Cơ chế | Chống | |---|---| | Sao lưu tự động + PITR | lỗi con người, dữ liệu hỏng | | Cấu hình HA (regional) | hỏng một ZONE | | Read replica cùng Region | quá tải đọc | | Cross-region read replica | sự cố CẢ REGION | | Nhớ | bốn cơ chế, bốn mục đích — không thay thế nhau |

Từ khoá nhận diện:

"chịu được mất cả Region" → cross-region read replica "chịu được mất một zone" → cấu hình HA regional "xoá nhầm dữ liệu" → PITR "giảm tải đọc" → read replica "RPO = 0 trên nhiều Region" → Cloud Spanner, không phải Cloud SQL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có replica ở Region nào | gcloud sql instances list — xem cột Region | | Độ trễ nhân bản bao nhiêu | chỉ số replication_lag trong Monitoring | | Sao lưu để ở đâu | gcloud sql instances describe → backupConfiguration.location |

Và điều quyết định một kế hoạch khôi phục thảm hoạ có giá trị hay không: đã từng diễn tập chưa. Một cross-region replica cấu hình đúng nhưng chưa ai từng thăng cấp thử sẽ để lộ đủ thứ bất ngờ vào đúng lúc tệ nhất — chuỗi kết nối hard-code trong ảnh container, quyền IAM thiếu, hay đơn giản là không ai nhớ tên lệnh.

Đáp án

B — Viewer.

Vì sao đúng

Yêu cầu là NHÌN THẤY mọi tài nguyên trong project — dataset BigQuery, bucket Cloud Storage — nhưng không được sửa, xoá hay tạo gì. Đó chính là vai trò cơ bản Viewer.

⚠ Điểm mấu chốt — ba vai trò cơ bản (basic role):

VIEWER   → đọc MỌI tài nguyên       ← đề này
           không thay đổi được gì

EDITOR   → Viewer + SỬA, TẠO, XOÁ
           hầu hết tài nguyên

OWNER    → Editor + quản lý IAM,
           quản lý thanh toán

⚠ Vì sao Browser lại KHÔNG đủ:

roles/browser
        ↓
    Chỉ cho phép DUYỆT CÂY TÀI NGUYÊN:
      thấy project, folder, organization
      trong cấu trúc phân cấp
        ↓
    ⚠ KHÔNG cho xem NỘI DUNG:
      không thấy dataset BigQuery,
      không thấy bucket Cloud Storage
        ↓
    → dùng cho công cụ cần biết cây tổ chức,
      không dùng cho người cần xem tài nguyên

⚠ Cấp Viewer:

gcloud projects add-iam-policy-binding DU-AN \
  --member="user:pm@congty.com" \
  --role="roles/viewer"

⚠ Và một cảnh báo quan trọng về Viewer:

⚠ Viewer cho phép ĐỌC DỮ LIỆU, không chỉ
  xem danh sách tài nguyên
        ↓
    → đọc được NỘI DUNG bảng BigQuery
    → đọc được NỘI DUNG tệp trong bucket
        ↓
    Nếu chỉ cần "thấy có những gì"
    mà KHÔNG được đọc dữ liệu
        ↓
    → dùng roles/browser + các vai trò
      metadata hẹp, chứ không dùng Viewer

Xem thêm câu #12957 (cùng lô): cũng về quyền tối thiểu nhưng cho chạy truy vấn BigQuery → khoá là BigQuery Data Viewer + Job User. Và #12952 (cùng lô) cho quản lý tệp trong bucket → Storage Object Admin. Ba câu, ba mức phạm vi.

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

• A (Browser) — đây là phương án gần nhất và đúng là vai trò rất hẹp, nhưng nó chỉ cho duyệt cấu trúc phân cấp (project, folder), không cho xem dataset hay bucket như đề yêu cầu.

• C (Editor) — cho phép sửa, tạo, xoá — vi phạm trực tiếp yêu cầu.

• D (Owner) — rộng nhất, kể cả quản lý IAM và thanh toán.

Ghi nhớ

⚠ Ba vai trò cơ bản — bảng phải thuộc: | Vai trò | Cho phép | |---|---| | roles/viewer | ĐỌC mọi tài nguyên, không thay đổi gì | | roles/editor | Viewer + tạo, sửa, xoá | | roles/owner | Editor + quản lý IAM và thanh toán | | roles/browser | chỉ duyệt CÂY tài nguyên — không phải basic role | | Khuyến nghị của Google | hạn chế basic role, ưu tiên vai trò ĐỊNH SẴN theo dịch vụ |

Từ khoá nhận diện:

"xem mọi thứ, không sửa gì" → roles/viewer "chỉ thấy cây project/folder" → roles/browser "xem nhưng KHÔNG được đọc dữ liệu" → vai trò metadata của từng dịch vụ "quản lý quyền của người khác" → roles/resourcemanager.projectIamAdmin "cấp Editor cho nhanh" → luôn sai trong câu hỏi quyền tối thiểu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có vai trò gì | gcloud projects get-iam-policy <id> | | Vai trò gồm những quyền nào | gcloud iam roles describe roles/viewer | | Có quyền thừa không | IAM Recommender |

Và một câu nên hỏi trước khi cấp roles/viewer cho người quản lý dự án: họ có thật sự cần ĐỌC dữ liệu, hay chỉ cần biết có những gì và tốn bao nhiêu? Rất thường xuyên, câu trả lời là vế sau — và khi đó roles/browser cộng với quyền xem chi phí vừa đủ dùng, vừa không đặt toàn bộ dữ liệu khách hàng vào tầm tay một người không cần tới nó.

Đáp án

A — BigQuery Data Viewer và BigQuery Job User.

Vì sao đúng

Chạy được một câu SELECT trong BigQuery cần HAI quyền tách rời: quyền ĐỌC DỮ LIỆU, và quyền CHẠY JOB. Thiếu một trong hai là không làm việc được.

⚠ Điểm mấu chốt — vì sao phải có đủ hai:

roles/bigquery.dataViewer
        ↓
    Đọc dữ liệu và siêu dữ liệu của
    bảng, view, dataset
        ↓
    ⚠ Nhưng KHÔNG chạy được truy vấn nào

roles/bigquery.jobUser
        ↓
    Tạo và chạy JOB (truy vấn, nạp, xuất)
    trong project
        ↓
    ⚠ Nhưng KHÔNG đọc được bảng nào
        ↓
    → PHẢI CÓ CẢ HAI

⚠ Vì sao BigQuery tách hai thứ này:

Trong BigQuery:
    DỮ LIỆU nằm ở một project
    CHI PHÍ TRUY VẤN tính cho project
      CHẠY JOB
        ↓
    → hai thứ có thể ở HAI PROJECT KHÁC NHAU
        ↓
    dataViewer  → cấp trên DATASET (nơi có dữ liệu)
    jobUser     → cấp trên PROJECT (nơi trả tiền)
        ↓
    ⚠ Đây là mô hình rất mạnh:
      dữ liệu tập trung, chi phí phân bổ
      về từng đội

⚠ Cấp đúng phạm vi:

# quyền đọc, trên chính DATASET
bq add-iam-policy-binding \
  --member="user:analyst@congty.com" \
  --role="roles/bigquery.dataViewer" \
  du_an:bao_cao

# quyền chạy job, trên PROJECT
gcloud projects add-iam-policy-binding DU-AN \
  --member="user:analyst@congty.com" \
  --role="roles/bigquery.jobUser"

Xem thêm câu #12956 và #12952 (cùng lô): cùng nguyên tắc quyền tối thiểu, cho xem toàn project và cho quản lý tệp trong bucket. Ba câu nhất quán.

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

• B (Data Editor + Job User) — đây là phương án gần nhất và chạy được truy vấn, nhưng dataEditor cho phép SỬA và XOÁ dữ liệu, tạo và xoá bảng — đúng điều đề cấm.

• C (BigQuery Admin + Project Viewer) — bigquery.admin là toàn quyền BigQuery, rộng hơn hẳn mức cần.

• D (BigQuery Data Owner) — toàn quyền trên dataset kể cả xoá; hơn nữa một mình nó cũng không đủ vì thiếu quyền chạy job.

Ghi nhớ

⚠ Các vai trò BigQuery — bảng phải thuộc: | Vai trò | Cho phép | |---|---| | roles/bigquery.dataViewer | ĐỌC dữ liệu và siêu dữ liệu | | roles/bigquery.dataEditor | đọc + ghi, tạo, xoá bảng | | roles/bigquery.dataOwner | + quản lý quyền của dataset | | roles/bigquery.jobUser | CHẠY job — không đọc được dữ liệu | | roles/bigquery.user | jobUser + tạo dataset + đọc siêu dữ liệu | | roles/bigquery.metadataViewer | thấy có bảng gì, KHÔNG đọc nội dung | | roles/bigquery.admin | toàn quyền |

Từ khoá nhận diện:

"chỉ chạy SELECT, không sửa gì" → dataViewer + jobUser "cần tạo bảng riêng của mình" → roles/bigquery.user trên project "thấy tên bảng nhưng không đọc dữ liệu" → metadataViewer "nạp và xoá dữ liệu" → dataEditor "một vai trò là đủ" → thường SAI với BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có quyền trên dataset | bq show --format=prettyjson <dataset> → access | | Ai chạy được job | gcloud projects get-iam-policy <id>, tìm jobUser | | Vì sao bị từ chối | Policy Troubleshooter |

Và một lỗi cấu hình rất hay gặp khi phân quyền BigQuery lần đầu: cấp đủ quyền đọc nhưng quên jobUser. Người dùng nhìn thấy bảng trong giao diện, mở được lược đồ, nhưng mỗi lần bấm chạy truy vấn lại nhận lỗi quyền — và thông báo lỗi nói về "job", chứ không nói về bảng, nên rất dễ dẫn người ta đi tìm sai chỗ.

Đáp án

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

Vì sao đúng

Đề mô tả rõ thứ tự: trích xuất dữ liệu thô → nạp THẲNG vào bảng staging trong BigQuery → rồi mới chạy loạt script SQL để làm sạch và tổng hợp. Biến đổi xảy ra SAU khi nạp, ngay bên trong kho.

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

ELT = Extract → LOAD → Transform     ← đề này
        ↓
    Nạp DỮ LIỆU THÔ vào kho trước
        ↓
    Biến đổi bằng SQL NGAY TRONG BigQuery
        ↓
    raw → staging → curated

ETL = Extract → TRANSFORM → Load
        ↓
    Biến đổi Ở NGOÀI kho, rồi mới nạp
    kết quả đã sạch

⚠ Vì sao ELT trở thành mặc định với BigQuery:

Kho hiện đại rất mạnh và co giãn
        ↓
    BigQuery biến đổi hàng tỉ dòng
    nhanh hơn hầu hết công cụ ngoài
        ↓
    + Giữ được DỮ LIỆU THÔ
        ↓
    → đổi logic biến đổi → CHẠY LẠI từ thô
    → không phải trích xuất lại từ nguồn
    → triển khai nhanh hơn, ít hạ tầng hơn

⚠ Cấu trúc ba tầng điển hình:

RAW (thô)
    → y hệt nguồn, không sửa gì
    → là "bản ghi gốc"

STAGING (trung gian)
    → làm sạch, chuẩn hoá kiểu,
      loại trùng

CURATED / MART (đã sẵn sàng)
    → mô hình cho nghiệp vụ,
      bảng tổng hợp cho báo cáo
        ↓
    Dataform hoặc dbt quản lý
    các bước SQL này

Xem thêm câu #12913 (lô 133): cùng dạng câu hỏi nhưng ở đó chính sách bắt che PII TRƯỚC khi vào kho → khoá là ETL. Hai khoá khác nhau vì ràng buộc khác nhau, không mâu thuẫn. Quy tắc: dữ liệu nhạy cảm không được vào kho → ETL; còn lại → ELT.

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

• A (ETL) — đây là phương án đối lập trực tiếp: nó biến đổi TRƯỚC khi nạp, còn đề nói rõ dữ liệu thô được nạp thẳng rồi mới xử lý.

• B (ETLT) — không phải thuật ngữ chuẩn được dùng để mô tả luồng này; đề khớp chính xác với ELT.

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

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 | | Nơi biến đổi | công cụ ngoài (Dataflow, Data Fusion) | trong kho (BigQuery SQL) | | Dữ liệu thô | KHÔNG vào kho | có trong kho | | Chạy lại logic mới | phải trích xuất lại từ nguồn | chạy lại từ dữ liệu thô | | Hợp với | tuân thủ, PII không được vào kho | hầu hết trường hợp còn lại | | Chi phí lưu | thấp hơn | cao hơn (giữ cả thô) |

Từ khoá nhận diện:

"nạp thô rồi biến đổi bằng SQL trong kho" → ELT "làm sạch/che PII trước khi nạp" → ETL "đẩy dữ liệu từ kho ra CRM" → Reverse ETL "truy vấn tại nguồn, không di chuyển" → data virtualization / external table "quản lý các bước SQL có kiểm thử" → Dataform

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng thô có còn nguyên vẹn không | so số dòng với nguồn | | Các bước biến đổi có chạy đúng thứ tự | đồ thị phụ thuộc của Dataform, hoặc lịch sử scheduled query | | Kết quả cuối có khớp không | assertion hoặc truy vấn đối chiếu |

Và một điều nên thống nhất từ đầu khi chọn ELT: quy tắc giữ dữ liệu thô bao lâu. Giữ mãi thì chi phí lưu tăng dần và dữ liệu cũ chẳng ai dùng; xoá sớm thì mất khả năng chạy lại. Một chính sách rõ ràng — ví dụ giữ thô 13 tháng rồi chuyển sang Cloud Storage Archive — trả lời được cả hai lo ngại mà không cần tranh luận lại mỗi quý.

Đáp án

B — Trong giao diện BigQuery, chọn dataset đích, bấm 'Create Table', rồi chọn nguồn là 'Google Cloud Storage'.

Vì sao đúng

BigQuery có sẵn luồng tạo bảng từ tệp trong Cloud Storage ngay trong giao diện web, và đó là cách làm chuẩn.

⚠ Điểm mấu chốt — luồng thao tác đầy đủ:

BigQuery UI → chọn DATASET đích
        ↓
    Bấm "Create Table"
        ↓
    Create table from: Google Cloud Storage
    Select file: gs://bucket/du-lieu.csv
    File format: CSV
        ↓
    Destination: tên bảng mới
        ↓
    Schema: Auto detect, hoặc khai tay
        ↓
    Advanced options:
      Header rows to skip: 1
      Field delimiter
      Allow jagged rows
      Number of errors allowed
        ↓
    Bấm "Create table"

⚠ Vì sao KHÔNG có nút "Export to BigQuery" trong Cloud Storage:

Cloud Storage là KHO ĐỐI TƯỢNG
        ↓
    Nó không biết gì về BigQuery
        ↓
    ⚠ Luồng luôn bắt đầu TỪ PHÍA BIGQUERY
      (hoặc từ lệnh bq load)
        ↓
    → đây là bẫy hay gặp trong đề

⚠ LOAD DATA có tồn tại, nhưng không phải luồng của câu hỏi:

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

        ↓
    ⚠ Câu lệnh này CÓ THẬT trong BigQuery
    → nhưng đề hỏi luồng qua GIAO DIỆN,
      và phương án A không mô tả đúng cách dùng

Xem thêm câu #12911 (lô 133): cùng việc nạp CSV nhưng bằng dòng lệnh → khoá là bq load. Hai câu là hai cách làm cùng một việc, khoá nhất quán.

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

• A (viết truy vấn SQL dùng LOAD DATA) — đây là phương án gần nhất vì LOAD DATA thật sự tồn tại trong BigQuery, nhưng đề hỏi luồng tạo bảng qua giao diện, và phương án B mô tả đúng các bước chuẩn.

• D (trong giao diện Cloud Storage bấm 'Export to BigQuery') — không có chức năng này; Cloud Storage không khởi tạo được việc nạp vào BigQuery.

• C (cấp quyền cho service account trong IAM) — quyền là điều kiện cần, nhưng bản thân nó không nạp dữ liệu.

Ghi nhớ

⚠ Bốn cách nạp dữ liệu từ GCS vào BigQuery — bảng phải thuộc: | Cách | Dùng khi | |---|---| | Giao diện: Create Table → Google Cloud Storage | thao tác một lần, trực quan | | bq load (dòng lệnh) | script, tự động hoá | | LOAD DATA (SQL) | nạp trong một truy vấn, dễ đưa vào scheduled query | | External table | truy vấn TẠI CHỖ, không nạp | | Data Transfer Service | nạp theo LỊCH từ GCS |

Từ khoá nhận diện:

"qua giao diện web" → Create Table → Google Cloud Storage "dòng lệnh" → bq load "nạp lặp lại theo lịch" → Data Transfer Service "không muốn nạp, chỉ truy vấn" → external table / BigLake "Export to BigQuery trong GCS" → KHÔNG TỒN TẠI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng đã có dữ liệu chưa | bq show <dataset>.<bảng> → Num Rows | | Kiểu cột có đúng không | bq show --schema --format=prettyjson | | Có dòng nào bị bỏ không | bq show -j <job_id> → số bản ghi lỗi |

Và một tuỳ chọn nên cân nhắc kỹ mỗi lần nạp CSV: "Number of errors allowed". Đặt lớn cho job chạy trót lọt nhưng âm thầm bỏ đi hàng nghìn dòng; đặt bằng 0 thì một dòng hỏng làm hỏng cả lần nạp. Cách cân bằng thường tốt nhất là đặt bằng 0 và sửa dữ liệu nguồn — vì một bảng thiếu dữ liệu mà không ai biết còn nguy hiểm hơn một lần nạp thất bại.

Đáp án

B — JSON.

Vì sao đúng

Đề mô tả ba đặc điểm nhận dạng của JSON: cặp khoá–giá trị, giá trị có thể là chuỗi, số, hoặc ĐỐI TƯỢNG LỒNG NHAU, và cả tệp bọc trong dấu ngoặc nhọn {}.

⚠ Điểm mấu chốt — hình dạng của JSON:

{
  "khach_hang_id": 12345,
  "ten": "Nguyen Van An",
  "dia_chi": {
    "thanh_pho": "Ha Noi",
    "quoc_gia": "VN"
  },
  "don_hang": [
    {"id": "A1", "tong": 250000},
    {"id": "A2", "tong": 480000}
  ]
}

        ↓
    ⚠ Ngoặc NHỌN {} → đối tượng
    ⚠ Ngoặc VUÔNG [] → mảng
    ⚠ Lồng nhau tuỳ ý → đây là điểm
      CSV không làm được

⚠ JSON ↔ Avro ↔ Parquet ↔ CSV — nhận dạng nhanh:

JSON     → VĂN BẢN đọc được, {} và [],
           lồng nhau
Avro     → NHỊ PHÂN, theo DÒNG,
           lược đồ nhúng dạng JSON
Parquet  → NHỊ PHÂN, theo CỘT
CSV      → VĂN BẢN, phẳng, ngăn cách
           bằng dấu phẩy
        ↓
    Chỉ JSON và CSV mở được bằng
    trình soạn thảo văn bản

⚠ Với BigQuery — phải là NDJSON, không phải JSON thường:

BigQuery nạp JSON theo dạng
    NEWLINE DELIMITED JSON (NDJSON)
        ↓
    MỖI DÒNG là MỘT đối tượng JSON hoàn chỉnh:
      {"id":1,"ten":"An"}
      {"id":2,"ten":"Binh"}
        ↓
    ⚠ KHÔNG phải một mảng lớn bọc cả tệp
    → dạng mảng phải chuyển đổi trước

Xem thêm câu #12950 (cùng lô): cùng bộ bốn phương án nhưng mô tả nhị phân, theo dòng, lược đồ nhúng, tiến hoá lược đồ → khoá là Avro. Hai câu, hai khoá, phân biệt bằng chính các đặc điểm được mô tả.

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

• A (Apache Avro) — đây là phương án gần nhất vì Avro cũng lưu lược đồ dưới dạng JSON, nhưng bản thân dữ liệu Avro là NHỊ PHÂN, không mở ra thấy {} được.

• C (Apache Parquet) — nhị phân, theo cột, hoàn toàn không đọc được bằng mắt.

• D (CSV) — phẳng, không lồng nhau, ngăn cách bằng dấu phẩy và xuống dòng.

Ghi nhớ

⚠ Nhận dạng bốn định dạng — bảng phải thuộc: | Định dạng | Dấu hiệu | |---|---| | JSON | văn bản, {} và [], LỒNG NHAU được | | Avro | nhị phân, theo DÒNG, lược đồ nhúng | | Parquet | nhị phân, theo CỘT | | CSV | văn bản, PHẲNG, ngăn cách bằng dấu phẩy | | Đọc bằng mắt được | chỉ JSON và CSV |

Từ khoá nhận diện:

"khoá–giá trị, lồng nhau, {}" → JSON "nhị phân, theo dòng, tiến hoá lược đồ" → Avro "theo cột, nén tốt, phân tích" → Parquet "bảng phẳng đơn giản" → CSV "JSON cho BigQuery" → phải là NDJSON

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tệp có đúng NDJSON không | head -3 tep.json — mỗi dòng phải là một {...} | | JSON có hợp lệ không | jq . tep.json > /dev/null | | BigQuery hiểu lược đồ thế nào | bq show --schema sau khi nạp |

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