Ngân hàng đề — Google Cloud Digital Leader

Đáp án

D — Việc thứ nhất là phân tích dữ liệu; việc thứ hai là học máy.

Vì sao đúng

Ranh giới giữa hai lĩnh vực này nằm ở hướng thời gian: nhìn về quá khứ hay dự đoán tương lai.

⚠ Hai việc, hai bản chất:

VIỆC 1: "sản phẩm nào bán chạy
         nhất QUÝ TRƯỚC"
        ↓
    Dữ liệu ĐÃ CÓ SẴN
    Chỉ cần tổng hợp và trình bày
        ↓
    ⚠ PHÂN TÍCH DỮ LIỆU
      (mô tả — descriptive)

VIỆC 2: "sản phẩm nào KHẢ NĂNG
         bán chạy QUÝ TỚI"
        ↓
    Câu trả lời CHƯA TỒN TẠI
    Phải học quy luật từ quá khứ
    rồi suy ra tương lai
        ↓
    ⚠ HỌC MÁY
      (dự đoán — predictive)

⚠ Bốn cấp độ phân tích — thang cần thuộc:

1. DESCRIPTIVE   "Chuyện gì ĐÃ xảy ra?"
     → BI dashboard, báo cáo
     → ⚠ việc thứ nhất ở đây

2. DIAGNOSTIC    "Vì sao nó xảy ra?"
     → khoan sâu, phân tích nguyên nhân

3. PREDICTIVE    "Chuyện gì SẼ xảy ra?"
     → ⚠ HỌC MÁY — việc thứ hai

4. PRESCRIPTIVE  "Nên LÀM GÌ?"
     → tối ưu hoá, hệ khuyến nghị
        ↓
    ⚠ Giá trị tăng dần từ 1 lên 4
    ⚠ Độ khó cũng tăng theo

⚠ Vì sao phương án C ("cả hai đều là phân tích dữ liệu") sai:

Cả hai đều DÙNG dữ liệu — đúng
        ↓
    ⚠ Nhưng việc thứ hai tạo ra
      thông tin CHƯA HỀ CÓ trong dữ liệu
        ↓
    Không có bảng nào chứa
    "doanh số quý tới"
        ↓
    → phải HỌC một mô hình
      để sinh ra con số đó
        ↓
    → đó là học máy, không phải
      truy vấn dữ liệu

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

• C (cả hai đều là phân tích dữ liệu) — phương án gần nhất, vì cả hai đều làm việc với dữ liệu. Nhưng dự đoán tương lai đòi một mô hình học từ dữ liệu, không phải một truy vấn tổng hợp.

• A (thứ nhất là ML, thứ hai là phân tích) — đảo ngược hoàn toàn.

• B (cả hai đều là trí tuệ nhân tạo) — dashboard lịch sử là truy vấn và tổng hợp, không có yếu tố học nào. Học máy là một nhánh của AI; báo cáo BI thì không.

Ghi nhớ

⚠ Bốn cấp phân tích — bảng phải thuộc: | Cấp | Câu hỏi | Công cụ | |---|---|---| | Descriptive | "Đã xảy ra gì?" | Looker, dashboard BI | | Diagnostic | "Vì sao?" | khoan sâu, phân đoạn | | Predictive | "Sẽ xảy ra gì?" | BigQuery ML, Vertex AI | | Prescriptive | "Nên làm gì?" | tối ưu hoá, khuyến nghị |

Từ khoá nhận diện:

"quý trước, năm ngoái, đã bán bao nhiêu" → phân tích dữ liệu "dự đoán, khả năng, quý tới, sắp rời bỏ" → học máy "nên làm gì để tối ưu" → prescriptive "tại sao chỉ số giảm" → diagnostic

Ba việc kiểm chứng: | Việc | Câu hỏi | |---|---| | Câu trả lời đã nằm trong dữ liệu chưa | có → phân tích; chưa → học máy | | Có đủ dữ liệu lịch sử không | dự báo mùa vụ cần ít nhất 2–3 chu kỳ | | Dự báo có tốt hơn cách đoán đơn giản không | ⚠ nếu không thì mô hình không đáng triển khai |

Và một phép thử rất gọn để phân biệt hai lĩnh vực này trong mọi câu hỏi: hỏi xem câu trả lời đã tồn tại trong dữ liệu hay chưa. Nếu chỉ cần một câu SQL là lấy ra được, đó là phân tích dữ liệu; nếu phải suy ra một điều chưa ai ghi lại, đó là học máy.

Đáp án

C — Quy tắc ngưỡng ngân sách của Cloud Billing (budget threshold rules).

Vì sao đúng

Đề đòi thông báo CHỦ ĐỘNG ở những mốc phần trăm cụ thể — đó chính xác là chức năng của ngân sách và ngưỡng cảnh báo trong Cloud Billing.

⚠ Cấu hình đúng thứ đề mô tả:

Budget: 10.000 USD / tháng
Phạm vi: đúng project đó
        ↓
    Ngưỡng cảnh báo:
      50%  → gửi email
      90%  → gửi email
      100% → gửi email
        ↓
    ⚠ Đặt được bao nhiêu ngưỡng tuỳ ý
    ⚠ Cảnh báo theo chi phí THỰC TẾ
      hoặc chi phí DỰ BÁO

⚠ Cảnh báo theo dự báo — điểm mạnh dễ bị bỏ qua:

Chi phí THỰC TẾ đạt 90%
    → biết khi đã gần hết tiền

Chi phí DỰ BÁO đạt 100%
    → ⚠ báo ngay từ giữa tháng
      rằng ĐÀ TIÊU sẽ vượt ngân sách
        ↓
    → đúng tinh thần "hành động
      TRƯỚC khi vượt" của đề

⚠ Ngân sách KHÔNG tự chặn chi tiêu:

Đạt 100% ngân sách
        ↓
    ⚠ Dịch vụ VẪN CHẠY BÌNH THƯỜNG
    ⚠ Tiền VẪN tiếp tục phát sinh
        ↓
    Ngân sách chỉ là CẢNH BÁO
        ↓
    Muốn thật sự chặn thì phải:
      cảnh báo → Pub/Sub → Cloud Function
      → tắt tài nguyên hoặc gỡ liên kết
        tài khoản thanh toán
        ↓
    ⚠ Rất rủi ro — không dùng cho
      hệ thống sản xuất

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

• A (Cloud Billing Reports) — phương án gần nhất: báo cáo cho bạn xem và phân tích chi phí rất tốt. Nhưng nó bị động — phải có người mở ra xem. Đề đòi "được thông báo chủ động".

• D (chính sách hạn ngạch tài nguyên) — hạn ngạch giới hạn số lượng tài nguyên dùng được (số CPU, số IP), không phải số tiền. Có ảnh hưởng gián tiếp tới chi phí nhưng không cảnh báo theo phần trăm ngân sách.

• B (phân cấp tài nguyên) — cách tổ chức tổ chức → thư mục → project. Nó giúp nhóm chi phí và cấp quyền, nhưng bản thân không gửi cảnh báo nào.

Ghi nhớ

⚠ Công cụ quản lý chi phí trên Google Cloud — bảng phải thuộc: | Công cụ | Việc | |---|---| | Budgets & alerts | cảnh báo CHỦ ĐỘNG theo ngưỡng % | | Billing reports | xem và phân tích chi phí — bị động | | Billing export sang BigQuery | phân tích sâu bằng SQL | | Cost breakdown / Pricing calculator | ước tính trước | | Quotas | giới hạn SỐ LƯỢNG tài nguyên | | Recommender | gợi ý cắt giảm — máy nằm không, đĩa mồ côi | | Labels | gắn nhãn để quy chi phí về đội/môi trường |

Từ khoá nhận diện:

"báo cho tôi khi đạt X%" → budget alert "xem tháng trước tiêu vào đâu" → billing report "phân tích chi phí theo nhãn, theo ngày" → billing export + BigQuery "chặn không cho tạo quá N máy" → quota "giảm giá nếu cam kết dài hạn" → CUD (committed use discount)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cảnh báo có tới đúng người không | thử hạ ngưỡng xuống rất thấp | | Tiền đi đâu nhiều nhất | billing report, nhóm theo dịch vụ và SKU | | Có tài nguyên nằm không nào | Recommender — Idle resources |

Và một thói quen nên áp cho mọi project mới ngay từ ngày đầu: tạo ngân sách kèm nhãn trước khi tạo tài nguyên. Chi phí đám mây hiếm khi tăng vọt vì một quyết định lớn — nó thường bò lên từ những thứ nhỏ mà không ai gán được cho đội nào, và nhãn là thứ duy nhất giúp trả lời câu hỏi "cái này của ai" sau ba tháng.

Đáp án

A — Microservices (kiến trúc vi dịch vụ).

Vì sao đúng

Đề mô tả đúng quá trình tách một khối nguyên (monolith) thành nhiều thành phần nhỏ, triển khai độc lập — đó là định nghĩa của microservices.

⚠ Vấn đề của khối nguyên trong đề:

Một lỗi nhỏ ở tính năng GỢI Ý
        ↓
    ⚠ Phải kiểm thử LẠI TOÀN BỘ
    ⚠ Phải triển khai LẠI TOÀN BỘ
    ⚠ Rủi ro làm hỏng cả thanh toán,
      tìm kiếm, hồ sơ người dùng
        ↓
    → chậm và nguy hiểm

⚠ Sau khi tách thành microservices:

   ┌──────────┬──────────┬──────────┐
Thanh toán  Tìm kiếm  Hồ sơ    Gợi ý
   │          │          │        │
  CSDL      CSDL      CSDL     CSDL
  riêng     riêng     riêng    riêng
        ↓
    Sửa lỗi ở "Gợi ý"
        ↓
    ⚠ Chỉ kiểm thử và triển khai
      DỊCH VỤ ĐÓ
    ⚠ Ba dịch vụ kia không đụng tới
        ↓
    → nhanh hơn, rủi ro nhỏ hơn

⚠ Vì sao ba phương án kia là khái niệm khác:

LIFT AND SHIFT
    → chuyển ứng dụng lên đám mây
      GIỮ NGUYÊN kiến trúc
    → ⚠ khối nguyên vẫn là khối nguyên

SERVERLESS
    → mô hình VẬN HÀNH: không quản máy chủ
    → ⚠ là cách CHẠY, không phải cách
      CHIA ứng dụng
    → microservice có thể chạy serverless

VIRTUALIZATION
    → nhiều máy ảo trên một máy vật lý
    → ⚠ công nghệ hạ tầng,
      không phải kiến trúc phần mềm

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

• C (điện toán serverless) — phương án gần nhất về mặt "hiện đại hoá", và microservices thường chạy trên nền serverless. Nhưng serverless nói về ai quản máy chủ, còn câu hỏi là về cách chia ứng dụng thành các phần. Hai trục khác nhau.

• B (lift and shift) — chiến lược di cư giữ nguyên kiến trúc. Ngược hẳn với việc tái cấu trúc mà đề mô tả.

• D (ảo hoá) — công nghệ nền để chạy nhiều máy ảo trên một máy chủ vật lý. Không liên quan tới cách tổ chức mã nguồn.

Ghi nhớ

⚠ Monolith và microservices — bảng phải thuộc: | | Monolith | Microservices | |---|---|---| | Triển khai | cả khối một lần | từng dịch vụ độc lập | | Mở rộng | phải nhân cả khối | chỉ nhân phần cần | | Lỗi | có thể sập cả hệ thống | cô lập trong một dịch vụ | | Công nghệ | thống nhất một stack | mỗi dịch vụ chọn stack riêng | | ⚠ Độ phức tạp | thấp | CAO — mạng, giám sát, dữ liệu phân tán | | Hợp với | đội nhỏ, sản phẩm mới | đội lớn, hệ thống trưởng thành |

Từ khoá nhận diện:

"tách thành các phần triển khai độc lập" → microservices "chuyển lên đám mây giữ nguyên" → lift and shift / rehost "không quản máy chủ, co về 0" → serverless "đóng gói ứng dụng cùng thư viện" → container

Ba việc kiểm chứng: | Việc | Câu hỏi | |---|---| | Có triển khai độc lập được thật không | sửa một dịch vụ có phải đụng dịch vụ khác không | | Có theo dõi được xuyên dịch vụ không | Cloud Trace đã bật chưa | | Đội có đủ trưởng thành không | CI/CD, giám sát, trực sự cố |

Và một lời khuyên được nhắc đi nhắc lại trong ngành mà đề thi ít khi nói ra: đừng bắt đầu một sản phẩm mới bằng microservices. Ranh giới giữa các dịch vụ chỉ trở nên rõ ràng sau khi bạn đã hiểu nghiệp vụ — chia quá sớm thì bạn phải trả toàn bộ chi phí phức tạp để đổi lấy những đường biên đặt sai chỗ.

Đáp án

A — Giúp thiết lập một "gốc tin cậy" ở tầng phần cứng để xác minh máy chủ không bị can thiệp.

Vì sao đúng

Chip bảo mật Titan do Google tự thiết kế tồn tại để trả lời một câu hỏi rất cụ thể: làm sao biết chắc phần mềm đang chạy trên máy chủ đúng là phần mềm Google viết ra, chưa bị ai đổi?

⚠ Chuỗi khởi động được xác minh (verified boot):

TITAN (chip, gốc tin cậy)
  ⚠ khoá gốc nằm TRONG SILICON,
    không đọc ra được
        ↓ kiểm chữ ký
    FIRMWARE
        ↓ kiểm chữ ký
    BOOTLOADER
        ↓ kiểm chữ ký
    KERNEL
        ↓ kiểm chữ ký
    HỆ ĐIỀU HÀNH
        ↓
    ⚠ Một mắt xích SAI CHỮ KÝ
      → máy KHÔNG khởi động

⚠ Vì sao phải bắt đầu từ phần cứng:

Phần mềm chống phần mềm
    → ⚠ kẻ tấn công chiếm được tầng
      THẤP HƠN thì mọi lớp trên
      đều bị lừa
        ↓
    Rootkit trong firmware
    có thể nói dối hệ điều hành
        ↓
    Phải có một điểm neo
    KHÔNG THỂ đổi bằng phần mềm
        ↓
    ⚠ Đó chính là "gốc tin cậy
      phần cứng"

⚠ Vì sao ba phương án kia không phải lợi ích bảo mật:

"Giảm nhân sự quản lý hoá đơn"
    → chuyện tài chính, không liên quan

"Giảm giá VM nhờ phần cứng rẻ"
    → ⚠ NGƯỢC LẠI: chip tự thiết kế
      là đầu tư ĐẮT, không phải
      phần cứng phổ thông

"Cho khách chọn nhà cung cấp phần cứng"
    → ⚠ NGƯỢC LẠI: Google TỰ thiết kế
      chính vì muốn kiểm soát
      toàn bộ chuỗi cung ứng

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

• C (giảm giá VM nhờ dùng phần cứng phổ thông giá rẻ) — phương án gần nhất về mặt "nghe hợp lý", nhưng sai chiều: Google tự thiết kế máy chủ và chip để kiểm soát bảo mật, không phải để mua đồ rẻ.

• B (giảm nhân sự quản lý thanh toán) — hoàn toàn không liên quan tới bảo mật phần cứng.

• D (khách được chọn nhà cung cấp phần cứng) — trái ngược thực tế: khách hàng không chọn phần cứng trong đám mây công cộng, và đó chính là điều cho phép Google chuẩn hoá bảo mật.

Ghi nhớ

⚠ Các lớp bảo mật của Google Cloud — bảng phải thuộc: | Lớp | Biện pháp | |---|---| | Vật lý | trung tâm dữ liệu nhiều lớp kiểm soát, sinh trắc học | | Phần cứng | ⚠ chip Titan, máy chủ tự thiết kế, verified boot | | Hạ tầng / lưu trữ | mã hoá mặc định khi lưu | | Mạng | mã hoá khi truyền, Cloud Armor, VPC | | Danh tính | IAM, khoá bảo mật Titan, 2SV | | Vận hành | kiểm toán, phát hiện xâm nhập, đội bảo mật riêng |

Từ khoá nhận diện:

"gốc tin cậy, verified boot, chip Titan" → bảo mật tầng phần cứng "bảo vệ dữ liệu ĐANG xử lý trong CPU" → Confidential Computing "mã hoá khi lưu và khi truyền" → mặc định, không cần bật "khoá do khách quản lý" → CMEK / Cloud KMS

Ba việc kiểm chứng cho một tổ chức: | Việc | Cách | |---|---| | Cấu hình của mình có lỗ hổng không | Security Command Center | | Ai có quyền quá rộng | IAM Recommender — gợi ý thu hẹp quyền | | Có ai truy cập bất thường không | Cloud Audit Logs |

Và một điều đáng ghi nhớ khi đọc mọi câu hỏi về bảo mật đám mây: phần Google lo rất tốt thường không phải phần khiến các tổ chức bị xâm nhập. Các sự cố thực tế hầu như luôn bắt nguồn từ nửa còn lại của mô hình trách nhiệm chung — một bucket để công khai, một tài khoản dịch vụ có quyền quá rộng, một khoá bị đưa lên kho mã nguồn.

Đáp án

B — Confidential Computing (điện toán bảo mật).

Vì sao đúng

Dữ liệu tồn tại ở ba trạng thái, và Confidential Computing là lời đáp cho trạng thái thứ ba — trạng thái khó bảo vệ nhất.

⚠ Ba trạng thái của dữ liệu:

1. KHI LƯU (at rest)      — trên đĩa
     → mã hoá mặc định ✔

2. KHI TRUYỀN (in transit) — qua mạng
     → TLS, mã hoá giữa các
       trung tâm dữ liệu ✔

3. ⚠ KHI XỬ LÝ (in use)   — trong RAM và CPU
     → ⚠ TRUYỀN THỐNG là ĐỂ TRẦN
     → đây là CONFIDENTIAL COMPUTING

⚠ Vì sao trạng thái thứ ba từng là lỗ hổng:

Muốn tính toán trên dữ liệu
        ↓
    Phải GIẢI MÃ nó ra RAM
        ↓
    ⚠ Ai đọc được bộ nhớ máy chủ
      thì đọc được dữ liệu THÔ
    ⚠ Kể cả quản trị viên hạ tầng
    ⚠ Kể cả một hypervisor bị chiếm
        ↓
    Confidential Computing:
    ⚠ mã hoá LUÔN CẢ BỘ NHỚ

⚠ Confidential VM hoạt động thế nào:

CPU (AMD SEV / Intel TDX) có
khoá mã hoá bộ nhớ riêng cho từng VM
        ↓
    ⚠ Khoá do PHẦN CỨNG sinh và giữ
    ⚠ Hypervisor KHÔNG đọc được
    ⚠ Google KHÔNG đọc được
        ↓
    Dữ liệu chỉ ở dạng rõ
    BÊN TRONG ranh giới CPU
        ↓
    Bật bằng MỘT hộp kiểm khi tạo VM
        ↓
    ⚠ Không cần sửa ứng dụng

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

• C (chủ quyền dữ liệu — data sovereignty) — phương án gần nhất về mặt "nghe như bảo vệ dữ liệu", nhưng nó nói về dữ liệu nằm ở LÃNH THỔ nào và chịu luật nước nào, không nói gì tới việc bảo vệ trong lúc xử lý.

• A (kiểm toán — auditing) — ghi lại ai đã làm gì, để điều tra sau. Không mã hoá gì cả.

• D (xác thực hai bước — 2SV) — bảo vệ việc đăng nhập của người dùng. Quan trọng, nhưng ở tầng danh tính, không phải tầng xử lý dữ liệu.

Ghi nhớ

⚠ Ba trạng thái dữ liệu và cách bảo vệ — bảng phải thuộc: | Trạng thái | Bảo vệ bằng | |---|---| | Khi lưu (at rest) | mã hoá đĩa — MẶC ĐỊNH trên Google Cloud | | Khi truyền (in transit) | TLS và mã hoá giữa các trung tâm dữ liệu | | ⚠ Khi xử lý (in use) | CONFIDENTIAL COMPUTING |

Từ khoá nhận diện:

"bảo vệ trong lúc CPU đang xử lý" → Confidential Computing "dữ liệu phải nằm trong lãnh thổ nước X" → data sovereignty / data residency "ai đã truy cập cái gì" → audit logs "chống chiếm tài khoản" → 2SV, khoá bảo mật Titan

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VM có đang ở chế độ confidential không | gcloud compute instances describe → confidentialInstanceConfig | | Chi phí tăng bao nhiêu | so SKU trong billing report | | Ứng dụng có chạy bình thường không | ⚠ thử tải trước khi chuyển sản xuất |

Và một cách hiểu gọn về Confidential Computing giúp nhớ lâu: nó đóng nốt mắt xích cuối cùng. Ngành bảo mật đã lo rất kỹ cho dữ liệu lúc nằm yên và lúc di chuyển, nhưng suốt nhiều năm dữ liệu vẫn phải cởi bỏ lớp mã hoá mỗi lần cần được tính toán — và đó chính là khoảnh khắc mà công nghệ này bảo vệ.

Đáp án

A — Dùng Cloud Translation API.

Vì sao đúng

Đề nêu ba điều kiện, và cả ba đều đẩy về phía API dựng sẵn:

⚠ Ba điều kiện ↔ Translation API:

1. "KHÔNG có chuyên gia học máy"
     → không thể huấn luyện mô hình

2. "CÔNG SỨC PHÁT TRIỂN TỐI THIỂU"
     → chỉ cần gọi một API

3. Dịch nhận xét khách sạn
     → ⚠ đây là NGÔN NGỮ ĐỜI THƯỜNG,
       không có thuật ngữ chuyên ngành
     → mô hình chung của Google
       đã rất tốt

⚠ Toàn bộ việc phải làm chỉ là:

from google.cloud import translate_v2 as translate

client = translate.Client()
kq = client.translate(
    "The hotel staff was incredibly friendly.",
    target_language="vi")
print(kq["translatedText"])
# → "Nhân viên khách sạn cực kỳ thân thiện."

        ↓
    ⚠ KHÔNG có dữ liệu huấn luyện
    ⚠ KHÔNG có mô hình phải nuôi
    ⚠ KHÔNG có endpoint phải trả tiền
      thường trực
    ⚠ Hỗ trợ hơn 100 ngôn ngữ,
      TỰ NHẬN DIỆN ngôn ngữ nguồn

⚠ Khi nào mới cần AutoML Translation:

Có THUẬT NGỮ RIÊNG mà mô hình
chung dịch sai
    ví dụ: tên sản phẩm, từ ngành hẹp
        ↓
    Có sẵn kho SONG NGỮ
    đã dịch chuẩn (hàng nghìn cặp câu)
        ↓
    → mới nên tinh chỉnh
        ↓
    ⚠ Nhận xét khách sạn KHÔNG
      thuộc trường hợp này

Nhất quán với #13251 (cùng lô này) — câu đó cũng khoá API dựng sẵn cho một bài toán ngôn ngữ phổ quát. Nguyên tắc chung: việc phổ biến thì dùng API sẵn, đừng tự huấn luyện.

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

• B (AutoML Translation) — phương án gần nhất và là bẫy chính: nó có thật và cũng không cần viết mã ML. Nhưng nó cần một kho dữ liệu song ngữ để tinh chỉnh, tốn thời gian và tiền, để đổi lấy lợi ích gần như bằng không cho ngôn ngữ đời thường.

• D (mô hình tuỳ biến trên Vertex AI) — cần chuyên gia ML mà đề nói rõ là công ty không có, và tốn hàng tháng.

• C (BigQuery ML) — dùng để huấn luyện mô hình trên dữ liệu bảng biểu bằng SQL. Không phải công cụ dịch máy.

Ghi nhớ

⚠ Ba mức giải pháp AI — bảng phải thuộc: | Mức | Khi nào | |---|---| | API dựng sẵn | việc phổ quát, không có chuyên gia, cần nhanh | | AutoML | có dữ liệu riêng, thuật ngữ riêng, không viết mã | | Mô hình tuỳ biến | lợi thế cạnh tranh cốt lõi, cần kiểm soát kiến trúc |

Từ khoá nhận diện:

"không có chuyên gia ML + công sức tối thiểu" → API dựng sẵn "thuật ngữ riêng mô hình chung dịch sai" → AutoML Translation "dữ liệu bảng biểu, biết SQL" → BigQuery ML "kiến trúc riêng, khác biệt cạnh tranh" → Vertex AI custom

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chất lượng dịch có ổn không | lấy 50 nhận xét, nhờ người bản ngữ đọc | | Có tên riêng bị dịch sai không | → thêm glossary | | Tốn bao nhiêu | đếm ký tự × đơn giá, nhớ trừ phần đã đệm |

Và một điều nên làm ngay khi đưa tính năng này lên trang web: đệm lại bản dịch. Một nhận xét khách sạn được hàng nghìn người đọc nhưng chỉ cần dịch đúng một lần — bỏ qua bước đệm là cách nhanh nhất biến một tính năng rẻ tiền thành một khoản chi phí đều đặn không cần thiết.

Đáp án

C — Pub/Sub.

Vì sao đúng

Cụm từ "cửa trước" (the front door) trong đề là cách Google thường dùng để mô tả vai trò của Pub/Sub trong kiến trúc dữ liệu luồng.

⚠ Kiến trúc luồng chuẩn trên Google Cloud:

Hàng nghìn xe gửi vị trí
        ↓
    ⚠ PUB/SUB   ← "cửa trước"
      nhận vào, đệm lại, tách rời
        ↓
    DATAFLOW
      xử lý theo cửa sổ thời gian,
      tính cung–cầu theo khu vực
        ↓
   ┌────────┴────────┐
BIGQUERY        Bigtable / API
(phân tích)     (điều chỉnh giá
                 thời gian thực)
        ↓
    LOOKER (bảng điều khiển)

⚠ Vì sao phải có một lớp đệm ở giữa:

Nếu xe ghi THẲNG vào hệ xử lý
        ↓
    ⚠ Hệ xử lý chậm hoặc chết
      → MẤT DỮ LIỆU
    ⚠ Lượng xe tăng đột biến
      → hệ xử lý gục
    ⚠ Mỗi người gửi phải biết
      địa chỉ người nhận
        ↓
    Pub/Sub ở giữa:
    ⚠ TÁCH RỜI người gửi và người nhận
    ⚠ ĐỆM khi hạ nguồn chậm
    ⚠ Tự mở rộng, không cần cấu hình
    ⚠ Giữ thông điệp tới 7 ngày

⚠ Vì sao ba phương án kia không phải "cửa trước":

BIGQUERY
    → ĐÍCH ĐẾN để phân tích
    → không phải nơi nhận luồng thô
      từ hàng nghìn thiết bị

CLOUD STORAGE
    → lưu TỆP
    → ⚠ hợp với theo lô, không hợp
      với sự kiện nhỏ liên tục

LOOKER
    → công cụ TRỰC QUAN HOÁ
    → nằm ở CUỐI đường ống

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

• A (BigQuery) — phương án gần nhất vì BigQuery có nhận được dữ liệu luồng. Nhưng nó là đích đến để phân tích, không phải lớp nhận và đệm; nó không tách rời người gửi khỏi người nhận, và không đệm giúp bạn khi hạ nguồn gặp sự cố.

• B (Cloud Storage) — lưu tệp, phù hợp với xử lý theo lô. Ghi hàng nghìn sự kiện nhỏ mỗi giây thành từng đối tượng là cách dùng sai.

• D (Looker) — nền tảng BI để trực quan hoá, đứng ở cuối chuỗi.

Ghi nhớ

⚠ Vòng đời dữ liệu trên Google Cloud — bảng phải thuộc: | Giai đoạn | Sản phẩm | |---|---| | Nhận (ingest) | Pub/Sub (luồng), Storage Transfer / Datastream (lô) | | Lưu | Cloud Storage, BigQuery, Bigtable, Spanner | | Xử lý | Dataflow, Dataproc, Dataform | | Phân tích | BigQuery | | Trực quan hoá | Looker, Looker Studio | | Học máy | Vertex AI, BigQuery ML |

Từ khoá nhận diện:

"cửa trước, nhận luồng, nhiều nguồn cùng lúc" → Pub/Sub "xử lý luồng, cửa sổ thời gian" → Dataflow "phân tích, kho dữ liệu" → BigQuery "bảng điều khiển" → Looker "đưa CSDL quan hệ lên theo thời gian thực" → Datastream

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bị dồn ứ không | metric num_undelivered_messages | | Dữ liệu có bị cũ không | oldest_unacked_message_age | | Có mất thông điệp không | ⚠ kiểm hạn giữ — mặc định 7 ngày |

Và một lợi ích của Pub/Sub thường chỉ được đánh giá đúng khi hệ thống lớn lên: thêm một hệ thống tiêu thụ mới không cần đụng gì tới bên gửi. Hôm nay chỉ có bộ tính giá đọc dữ liệu vị trí; ngày mai đội chống gian lận muốn cùng dữ liệu đó — chỉ cần tạo thêm một subscription, và những chiếc xe ngoài đường không hề biết có gì thay đổi.

Đáp án

A — Looker.

Vì sao đúng

Đề nêu ba yêu cầu, và cả ba đều là mô tả của một nền tảng BI tự phục vụ:

⚠ Ba yêu cầu ↔ Looker:

1. TỰ DỰNG dashboard và báo cáo
     → Looker cho người dùng nghiệp vụ
       tự tạo Look và dashboard

2. KHÔNG cần biết SQL
     → ⚠ LookML dịch thao tác kéo thả
       thành SQL tự động

3. KHÔNG phải nhờ đội dữ liệu
     → đội dữ liệu chỉ dựng MÔ HÌNH
       một lần, sau đó người dùng
       tự khai thác

⚠ LookML — chìa khoá của mô hình này:

Đội dữ liệu viết LookML MỘT LẦN:
    - bảng nào nối với bảng nào
    - "doanh thu" định nghĩa thế nào
    - chỉ số nào tính ra sao
        ↓
    ⚠ Định nghĩa TẬP TRUNG,
      ai cũng dùng chung
        ↓
Người dùng nghiệp vụ trong Explore:
    kéo thả chiều và chỉ số
        ↓
    Looker sinh SQL và chạy trên BigQuery
        ↓
    ⚠ Không ai gõ SQL
    ⚠ ⚠ Mọi người ra CÙNG một con số

⚠ Vì sao "một nguồn sự thật" mới là giá trị lớn nhất:

Không có mô hình chung
        ↓
    Đội marketing tính doanh thu
    theo cách A → 10 tỉ
    Đội bán hàng tính theo cách B → 11 tỉ
        ↓
    ⚠ Họp hành mất thời gian
      tranh cãi con số nào đúng
        ↓
Có LookML
        ↓
    → một định nghĩa duy nhất,
      sửa một chỗ là mọi báo cáo đổi theo

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

• B (Dataflow) — công cụ xử lý dữ liệu, cần viết Apache Beam. Đứng ở giữa đường ống, không phải nơi người dùng nghiệp vụ nhìn vào.

• C (Cloud Composer) — công cụ điều phối pipeline cho kỹ sư dữ liệu. Không có gì để người dùng nghiệp vụ khai thác.

• D (Pub/Sub) — dịch vụ nhận và chuyển thông điệp, nằm ở đầu vào của đường ống.

Ghi nhớ

⚠ Hai công cụ BI của Google — bảng phải thuộc: | | Looker | Looker Studio | |---|---|---| | Mô hình dữ liệu | LookML — định nghĩa tập trung | kết nối trực tiếp, mỗi báo cáo tự lo | | Quản trị | mạnh — một nguồn sự thật | nhẹ | | Chi phí | có phí, theo nền tảng và người dùng | có bản MIỄN PHÍ | | Hợp với | doanh nghiệp, nhiều đội dùng chung | báo cáo nhanh, nhóm nhỏ | | Nhúng | mạnh — nhúng vào sản phẩm | có |

Từ khoá nhận diện:

"BI tự phục vụ, không cần SQL, quản trị chỉ số tập trung" → Looker "dashboard nhanh, miễn phí" → Looker Studio "phân tích BigQuery trong bảng tính" → Connected Sheets "notebook phân tích" → BigQuery Studio / Colab Enterprise

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng có tự làm được không | quan sát một người mới trong 30 phút đầu | | Chi phí truy vấn bao nhiêu | BigQuery job history, lọc theo Looker | | Có nội dung nào hỏng không | Content Validator |

Và một điều quyết định thành bại của mọi triển khai Looker, dù đề thi không hỏi: chất lượng của mô hình LookML. Công cụ chỉ tốt bằng mô hình phía sau nó — một mô hình đặt tên khó hiểu và thiếu mô tả sẽ khiến người dùng nghiệp vụ quay lại đúng thói quen cũ là gửi yêu cầu cho đội dữ liệu.

Đáp án

A — Bền vững (Sustainability).

Vì sao đúng

Đề nêu hai điều rất cụ thể: năng lượng tái tạo và công cụ đo, báo cáo phát thải carbon. Cả hai đều thuộc trụ cột bền vững trong bộ lợi ích chuyển đổi mà Google Cloud nêu ra.

⚠ Hai yêu cầu ↔ cam kết của Google:

1. "KHỚP 100% điện tiêu thụ với
    năng lượng tái tạo"
     → ⚠ Google đạt điều này
       từ năm 2017
     → mục tiêu tiếp theo: chạy bằng
       năng lượng SẠCH 24/7 vào 2030

2. "CÔNG CỤ ĐO VÀ BÁO CÁO PHÁT THẢI"
     → ⚠ Carbon Footprint —
       báo cáo phát thải theo project,
       theo dịch vụ, theo vùng
     → xuất được sang BigQuery

⚠ Vì sao chạy trên đám mây thường ít phát thải hơn:

TRUNG TÂM DỮ LIỆU RIÊNG
    → tỉ lệ sử dụng máy thường rất thấp
    → hiệu suất làm mát kém
    → điện lấy từ lưới địa phương
        ↓
GOOGLE CLOUD
    → ⚠ PUE ~1,1 — hiệu quả hàng đầu
    → máy dùng chung, tỉ lệ sử dụng cao
    → ⚠ mua năng lượng tái tạo quy mô lớn
        ↓
    → cùng khối lượng công việc,
      phát thải thấp hơn nhiều

⚠ Khách hàng còn tự giảm thêm được:

CHỌN VÙNG CÓ ĐIỆN SẠCH HƠN
    → ⚠ console hiện huy hiệu lá cây
      cho vùng phát thải thấp
        ↓
DÙNG ACTIVE ASSIST
    → tắt tài nguyên nằm không
        ↓
CHỌN DỊCH VỤ SERVERLESS
    → co về 0 khi rảnh
        ↓
    ⚠ Ít tài nguyên lãng phí
      = ít tiền VÀ ít carbon

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

• C (Intelligence — thông minh) — nói về việc dùng dữ liệu và AI để ra quyết định tốt hơn. Không liên quan tới phát thải.

• B (Collaboration — cộng tác) — nói về Google Workspace và cách các đội làm việc cùng nhau.

• D (Freedom — tự do) — nói về mã nguồn mở, đa đám mây, tránh bị khoá chân vào một nhà cung cấp.

Ghi nhớ

⚠ Các trụ cột chuyển đổi số mà Google Cloud nêu — bảng nên thuộc: | Trụ cột | Nội dung | |---|---| | Sustainability | năng lượng tái tạo, báo cáo carbon | | Intelligence | dữ liệu và AI để ra quyết định | | Collaboration | Workspace, làm việc cùng nhau | | Freedom | mã nguồn mở, đa đám mây, không bị khoá chân | | Trust / Security | bảo mật nhiều lớp, mã hoá mặc định |

Từ khoá nhận diện:

"carbon, năng lượng tái tạo, môi trường" → Sustainability "mã nguồn mở, đa đám mây, không khoá chân" → Freedom "dữ liệu, AI, quyết định tốt hơn" → Intelligence "làm việc nhóm, họp, tài liệu chung" → Collaboration

Ba việc kiểm chứng cho một tổ chức: | Việc | Cách | |---|---| | Đang phát thải bao nhiêu | báo cáo Carbon Footprint | | Vùng đang dùng có sạch không | xem huy hiệu lá cây trong Region Picker | | Có bao nhiêu tài nguyên lãng phí | Recommender — Idle resources |

Và một điều đáng nhớ nếu bạn được giao nhiệm vụ giảm phát thải cho hệ thống đám mây: hãy bắt đầu bằng việc dọn tài nguyên nằm không. Nó không cần đổi kiến trúc, không cần đàm phán với ai, và cho kết quả trên cả hai bảng báo cáo cùng lúc — bảng chi phí và bảng phát thải.

Đáp án

D — 1. Database (cơ sở dữ liệu), 2. Data Warehouse (kho dữ liệu), 3. Data Lake (hồ dữ liệu).

Vì sao đúng

Ba nhu cầu trong đề tương ứng chính xác với ba khái niệm lưu trữ dữ liệu kinh điển.

⚠ Ghép từng nhu cầu:

NHU CẦU 1 — đơn hàng và giao dịch
             ĐANG DIỄN RA của web bán hàng
    → đọc ghi liên tục, độ trễ thấp,
      cần giao dịch
    → ⚠ đây là OLTP
    → DATABASE (Cloud SQL / Spanner)

NHU CẦU 2 — doanh số MƯỜI NĂM QUA
             để phân tích và báo cáo xu hướng
    → dữ liệu ĐÃ CÓ CẤU TRÚC,
      truy vấn tổng hợp lớn
    → ⚠ đây là OLAP
    → DATA WAREHOUSE (BigQuery)

NHU CẦU 3 — hàng petabyte weblog THÔ,
             GIỮ NGUYÊN ĐỊNH DẠNG GỐC,
             cho thí nghiệm CHƯA XÁC ĐỊNH
    → ⚠ ba cụm từ này là dấu hiệu
      kinh điển của HỒ DỮ LIỆU
    → DATA LAKE (Cloud Storage)

⚠ Ba cụm từ khoá không thể nhầm:

"raw"        (thô)
"original format" (định dạng gốc)
"undefined future experiments"
   (thí nghiệm chưa xác định)
        ↓
    ⚠ Kho dữ liệu đòi bạn quyết định
      SCHEMA TRƯỚC khi nạp
    ⚠ Hồ dữ liệu cho phép nạp trước,
      quyết định sau
        ↓
    → schema-on-write  = warehouse
    → schema-on-read   = lake

⚠ Ba khái niệm trên một trục:

DATABASE          WAREHOUSE         LAKE
đang diễn ra      lịch sử           thô
có cấu trúc       có cấu trúc       mọi định dạng
OLTP              OLAP              chưa xác định
GB–TB             TB–PB             PB+
Cloud SQL,        BigQuery          Cloud Storage
Spanner

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

• B (warehouse / database / lake) — phương án gần nhất: đúng ở vị trí thứ ba nhưng hoán đổi hai vị trí đầu. Giao dịch đang diễn ra không thuộc về kho dữ liệu, và dữ liệu lịch sử mười năm để phân tích không thuộc về CSDL giao dịch.

• A và C — đều xếp sai thứ tự ở nhiều vị trí.

Ghi nhớ

⚠ Ba khái niệm lưu trữ — bảng phải thuộc: | | Database | Data Warehouse | Data Lake | |---|---|---|---| | Dữ liệu | đang diễn ra | lịch sử, đã làm sạch | thô, mọi định dạng | | Cấu trúc | có cấu trúc | có cấu trúc | có, bán và phi cấu trúc | | Schema | schema-on-write | schema-on-write | ⚠ schema-on-read | | Tải | OLTP | OLAP | khám phá, ML | | Sản phẩm | Cloud SQL, Spanner, Firestore | BigQuery | Cloud Storage | | Người dùng | ứng dụng | nhà phân tích | nhà khoa học dữ liệu |

Từ khoá nhận diện:

"giao dịch, đơn hàng đang xử lý" → database "lịch sử, báo cáo, xu hướng" → data warehouse "thô, định dạng gốc, chưa biết dùng làm gì" → data lake "kết hợp cả hai" → lakehouse (BigLake, Dataplex)

Ba việc kiểm chứng khi chọn: | Việc | Câu hỏi | |---|---| | Có cần giao dịch không | có → database | | Đã biết sẽ truy vấn thế nào chưa | rồi → warehouse | | Có muốn giữ nguyên định dạng gốc không | có → lake |

Và một nguyên tắc thực tế đáng nhớ về hồ dữ liệu: hãy ghi metadata ngay lúc nạp, đừng để sau. Chi phí ghi lại nguồn gốc và ý nghĩa của một tập dữ liệu lúc bạn còn nhớ là vài phút; chi phí truy ngược lại điều đó sau hai năm, khi người nạp nó đã đổi việc, thường là bỏ luôn tập dữ liệu ấy.