Ngân hàng đề — Microsoft Azure Data Fundamentals

Tìm thấy 328 câu.

Câu 111 Data Warehouse
Which Azure service includes an end-to-end machine learning environment inside the context of a data analytics platform?
  1. A Azure Data Lake Storage Gen2
  2. B Azure Databricks
  3. C Azure SQL Database
  4. D Azure Stream Analytics
Xem giải thích

Đáp án

B — Azure Databricks.

Vì sao đúng

⚠ Databricks gộp phân tích dữ liệu và học máy vào một nền tảng: | Thành phần | Nội dung | |---|---| | ⚠ Notebook cộng tác | ⚠ Python, Scala, SQL, R | | ⚠ Spark phân tán | ⚠ xử lý dữ liệu lớn | | ⚠ MLflow | ⚠ theo dõi thí nghiệm, đăng ký mô hình | | ⚠ Feature Store | ⚠ quản lý đặc trưng dùng chung | | ⚠ AutoML | | | ⚠ Model Serving | ⚠ triển khai mô hình | | ⚠ Delta Lake | ⚠ lớp lưu trữ có giao dịch |

⚠ Từ dữ liệu thô
   ⚠ → biến đổi → huấn luyện
   ⚠ → theo dõi → triển khai → giám sát
        ↓
⚠ TẤT CẢ trong một không gian làm việc

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

  • A (Data Lake Gen2) — ⚠ chỉ là kho LƯU TRỮ, không có môi trường tính toán hay ML.

  • C (Azure SQL Database) — ⚠ CSDL quan hệ; ⚠ có ML Services nhưng không phải môi trường ML đầu-cuối.

  • D (Stream Analytics) — ⚠ xử lý dòng thời gian thực, không phải nền tảng ML.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #19612 trong cùng lô — ⚠ cùng khoá Databricks.

Câu Hỏi gì Khoá
⚠ #19601 (câu này) ⚠ dịch vụ có môi trường ML đầu-cuối ⚠ Databricks
⚠ #19612 ⚠ không gian làm việc cộng tác trên cụm Spark ⚠ Databricks
⚠ Cùng khoá ⚠ hai khía cạnh của cùng một nền tảng
⚠ Cùng với #19558, #19588 ⚠ bốn câu về Databricks và Synapse qua hai lô

⚠ Databricks và Azure Machine Learning — phân biệt: | Tiêu chí | Databricks | Azure ML | |---|---|---| | ⚠ Trọng tâm | ⚠ dữ liệu lớn + ML | ⚠ vòng đời ML | | ⚠ Nền tảng tính toán | ⚠ Spark | ⚠ cluster đa dạng | | ⚠ Giao diện không code | ⚠ hạn chế | ⚠ Designer, AutoML | | ⚠ Xử lý dữ liệu quy mô lớn | ⚠ mạnh nhất | ⚠ yếu hơn | | ⚠ Dùng chung được | ⚠ Databricks huấn luyện, Azure ML quản lý và triển khai |

Từ khoá nhận diện:

"Spark + ML + notebook cộng tác" → ⚠ Databricks "vòng đời mô hình, không cần code" → ⚠ Azure ML "kho lưu trữ" → ⚠ Data Lake "dòng dữ liệu thời gian thực" → ⚠ Stream Analytics

⚠ MLflow — thành phần đáng nhớ Nội dung
⚠ Ghi lại mọi lần chạy thí nghiệm ⚠ tham số, chỉ số, mô hình
⚠ So sánh các lần chạy
⚠ Đăng ký mô hình và quản lý phiên bản
⚠ Giải quyết ⚠ vấn đề kinh điển "mô hình tốt nhất nằm ở notebook nào của ai"
⚠ Delta Lake — nhắc lại Nội dung
⚠ Giao dịch ACID trên tệp data lake
⚠ Time travel: đọc lại phiên bản cũ
⚠ Schema enforcement và evolution
⚠ Vì sao quan trọng ⚠ data lake thuần không bảo đảm nhất quán khi ghi song song

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cần xử lý dữ liệu lớn không | ⚠ quyết định Databricks hay Azure ML | | Có theo dõi được thí nghiệm ML không | | | Cụm có tự tắt khi rảnh không | ⚠ kiểm soát chi phí |

Và vấn đề mà MLflow giải quyết, quen thuộc với mọi đội làm học máy: sáu tháng sau không ai nhớ mô hình đang chạy được huấn luyện bằng dữ liệu nào và tham số gì.

Câu 112 Non-relational DB
Which CosmosDB API format works best with graph data?
  1. A Cassandra API
  2. B Core (SQL) API
  3. C Gemlin API
  4. D Table API
Xem giải thích

Đáp án

C — Gremlin API.

Vì sao đúng

⚠ Gremlin là ngôn ngữ duyệt đồ thị, và đó là API đồ thị của Cosmos DB:

⚠ Dữ liệu đồ thị
   ⚠ ĐỈNH: người, sản phẩm, địa điểm
   ⚠ CẠNH: quan hệ có hướng giữa chúng
        ↓ ⚠ truy vấn Gremlin
⚠ g.V().has('ten','An').out('banBe').out('banBe')
        ↓
⚠ Bạn của bạn của An
Khi nào cần đồ thị Ứng dụng
⚠ Mạng xã hội
⚠ Hệ gợi ý theo quan hệ
⚠ Phát hiện gian lận ⚠ vòng tài khoản liên kết
⚠ Đồ thị tri thức
⚠ Quản lý danh tính và quyền

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

  • B (Core SQL API) — ⚠ cho tài liệu JSON.

  • D (Table API) — ⚠ cho khoá-giá trị.

  • A (Cassandra API) — ⚠ cho cột rộng.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề có ⚠ LỖI CHÍNH TẢ trong chính đáp án đúng.

Vấn đề Thực tế
⚠ Đề viết "Gemlin API" ⚠ đúng phải là GREMLIN
⚠ Gremlin là ngôn ngữ của Apache TinkerPop
⚠ Lỗi gõ không ảnh hưởng đáp án
⚠ Giữ nguyên khoá ⚠ C theo bộ đề gốc
⚠ Trong phòng thi ⚠ đừng để lỗi chính tả làm bạn nghi ngờ phương án đúng
⚠ Đối chiếu ⚠ #16274 đợt trước cũng có lỗi gõ trong phương án

⚠ Đây là câu thứ tư về việc chọn API Cosmos DB qua hai lô: | Câu | Hỏi API cho gì | Khoá | |---|---|---| | ⚠ #19539 | ⚠ khoá-giá trị | ⚠ Table API | | ⚠ #19566 | ⚠ tài liệu JSON | ⚠ Core SQL | | ⚠ #19569 | ⚠ cái nào KHÔNG phải API | ⚠ MaxDB | | ⚠ #19602 (câu này) | ⚠ đồ thị | ⚠ Gremlin | | ⚠ Bốn câu | ⚠ cùng một bảng năm API |

⚠ Bảng năm API — chốt lại lần cuối: | API | Mô hình | Tên mới | |---|---|---| | ⚠ Core (SQL) | ⚠ tài liệu | ⚠ for NoSQL | | ⚠ MongoDB | ⚠ tài liệu | ⚠ for MongoDB | | ⚠ Cassandra | ⚠ cột rộng | ⚠ for Apache Cassandra | | ⚠ Gremlin | ⚠ đồ thị | ⚠ for Apache Gremlin | | ⚠ Table | ⚠ khoá-giá trị | ⚠ for Table |

Từ khoá nhận diện:

"đỉnh, cạnh, quan hệ, đường đi" → ⚠ Gremlin "JSON, truy vấn nhiều trường" → ⚠ NoSQL "khoá-giá trị" → ⚠ Table "ghi rất nhiều, chuỗi thời gian" → ⚠ Cassandra

⚠ Khi nào đồ thị thắng CSDL quan hệ Khi nào
⚠ Truy vấn đi qua từ BA TẦNG quan hệ trở lên
⚠ Độ sâu quan hệ không biết trước
⚠ Quan hệ thay đổi thường xuyên
⚠ Dưới ba tầng ⚠ JOIN trong SQL vẫn nhanh và đơn giản hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn quan trọng đi qua mấy tầng quan hệ | | | Có lỗi chính tả nào trong đề làm bạn phân vân không | | | Đây là ứng dụng mới hay đang di chuyển | |

Và một lời khuyên nhỏ cho phòng thi, rút ra từ chính câu này: đừng để một lỗi gõ trong phương án làm bạn loại bỏ đáp án đúng. Ngân hàng đề nào cũng có lỗi chính tả, và chúng phân bố ngẫu nhiên.

Câu 113 Non-relational deployment
Which of the following metrics affect how much a Cosmos DB database costs?
  1. A Based on the tier chosen - Basic, Standard or Premium
  2. B Provisioned throughput and storage only
  3. C Number of executions (queries) and storage only
  4. D Provisioned throughput, number of regions, number of availability zones, consumed storage
Xem giải thích

Đáp án

D — Thông lượng đã cấp phát, số VÙNG, số AVAILABILITY ZONE, và dung lượng đã dùng.

Vì sao đúng

⚠ Chi phí Cosmos DB có nhiều thành phần hơn người ta tưởng: | Thành phần | Nội dung | |---|---| | ⚠ Thông lượng (RU/s) | ⚠ thành phần lớn nhất | | ⚠ Số VÙNG | ⚠ mỗi vùng thêm là NHÂN thêm chi phí RU | | ⚠ Availability zone | ⚠ bật zone redundancy làm tăng giá | | ⚠ Dung lượng lưu trữ | ⚠ tính theo GB đã dùng | | ⚠ Sao lưu bổ sung | ⚠ ngoài hai bản miễn phí |

⚠ 10.000 RU/s ở MỘT vùng
        ↓ ⚠ thêm vùng thứ hai
⚠ Trả cho 10.000 RU/s ở CẢ HAI vùng
        ↓
⚠ Chi phí GẦN GẤP ĐÔI

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

  • B (chỉ thông lượng và lưu trữ) — ⚠ thiếu yếu tố VÙNG và ZONE, ⚠ vốn có thể nhân đôi hoặc nhân ba hoá đơn.

  • C (số lần truy vấn và lưu trữ) — ⚠ chỉ đúng với SERVERLESS, không đúng với provisioned.

  • A (theo bậc Basic/Standard/Premium) — ⚠ Cosmos DB KHÔNG có mô hình bậc như vậy.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ tư về chi phí và RU của Cosmos DB qua hai lô.

Câu Hỏi gì Khoá
⚠ #19520 ⚠ RU/s tối thiểu ⚠ 400
⚠ #19549 ⚠ cấp dư RU thì sao ⚠ vẫn trả tiền
⚠ #19597 ⚠ RU là gì ⚠ tài nguyên đọc 1KB
⚠ #19603 (câu này) ⚠ những gì ảnh hưởng chi phí ⚠ RU, vùng, zone, dung lượng
⚠ Bốn câu ⚠ vẽ trọn mô hình chi phí Cosmos DB

⚠ Yếu tố nhân chi phí — cần cảnh giác: | Yếu tố | Ảnh hưởng | |---|---| | ⚠ Mỗi vùng thêm | ⚠ NHÂN chi phí RU | | ⚠ Ghi đa vùng | ⚠ đắt hơn nữa | | ⚠ Zone redundancy | ⚠ tăng giá RU | | ⚠ Nhất quán mạnh | ⚠ tốn RU hơn khi đọc | | ⚠ Sai lầm | ⚠ bật nhiều vùng cho môi trường dev |

Từ khoá nhận diện:

"thông lượng, vùng, zone, dung lượng" → ⚠ chi phí Cosmos DB "trả theo lượt dùng" → ⚠ serverless "bậc Basic/Standard/Premium" → ⚠ Redis, không phải Cosmos

⚠ Cách giảm chi phí Cosmos DB Cách
⚠ Bỏ vùng không cần thiết ⚠ hiệu quả tức thì
⚠ Dùng serverless cho dev/test
⚠ Autoscale cho tải thất thường
⚠ Loại chỉ mục cho trường không lọc theo
⚠ Đặt TTL cho dữ liệu tạm
⚠ Xem lại partition key ⚠ giảm truy vấn chéo phân vùng
⚠ Reserved capacity ⚠ cam kết 1-3 năm, giảm đáng kể
⚠ Sao lưu — phần chi phí hay bị quên Nội dung
⚠ Hai bản sao lưu miễn phí
⚠ Bản thứ ba trở đi tính tiền
⚠ Continuous backup (point-in-time) tính tiền riêng
⚠ Cân nhắc ⚠ theo yêu cầu khôi phục thật sự

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang bật bao nhiêu vùng và có cần hết không | | | Môi trường dev có dùng serverless không | | | Có cân nhắc reserved capacity chưa | ⚠ nếu tải ổn định |

Và yếu tố làm hoá đơn Cosmos DB tăng vọt mà nhiều người không lường trước: mỗi vùng thêm vào là nhân chi phí thông lượng lên. Bật thêm hai vùng cho "an toàn" nghĩa là trả gấp ba lần.

Câu 114 Connectivity
Your company has a Azure SQL Database, and each user of that database has their own username and password unique to that database server, known as SQL Server Authentication. Your security team wants to eliminate this, and use the same username and password that users use in the corporate network. What type of security can you enable to allow this single sign-on model?
  1. A Azure AD Authentication
  2. B Access Control Lists
  3. C Social Media authentication (e.g. Facebook, LinkedIn, Microsoft, etc)
  4. D IP-based Firewall
Xem giải thích

Đáp án

A — Xác thực bằng Azure AD (Entra ID Authentication).

Vì sao đúng

⚠ Đề mô tả đúng bài toán mà Entra ID authentication giải quyết:

⚠ SQL Authentication
   ⚠ mỗi người một tài khoản RIÊNG trong CSDL
   ⚠ mật khẩu riêng, quản lý riêng
        ↓ ⚠ chuyển sang
⚠ Entra ID Authentication
   ⚠ dùng CHÍNH tài khoản công ty
        ↓
⚠ Một danh tính cho mọi hệ thống
Lợi ích Nội dung
⚠ Một tài khoản cho mọi dịch vụ
⚠ Áp dụng được MFA
⚠ Chính sách mật khẩu tập trung
⚠ Nghỉ việc là cắt được mọi quyền
⚠ Cấp quyền theo NHÓM ⚠ không phải từng người
⚠ Nhật ký đăng nhập tập trung

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

  • D (tường lửa theo IP) — ⚠ kiểm soát MẠNG, không phải danh tính.

  • B (danh sách kiểm soát truy cập) — ⚠ là PHÂN QUYỀN, bước sau xác thực.

  • C (đăng nhập qua mạng xã hội) — ⚠ dành cho ứng dụng khách hàng (B2C), ⚠ không dùng cho tài khoản nội bộ doanh nghiệp.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp với #19600 trong cùng lô.

Câu Dịch vụ Khoá
⚠ #19600 ⚠ Cosmos DB ⚠ Entra ID authentication
⚠ #19604 (câu này) ⚠ Azure SQL Database ⚠ Entra ID authentication
⚠ Cùng khoá ⚠ cùng một giải pháp cho hai dịch vụ
⚠ Bài học ⚠ thay xác thực cục bộ bằng danh tính tập trung là mẫu chung của Azure

⚠ Hai kiểu xác thực của Azure SQL: | Kiểu | Đặc điểm | |---|---| | ⚠ SQL Authentication | ⚠ tài khoản trong CSDL, mật khẩu riêng | | ⚠ Entra ID Authentication | ⚠ danh tính tập trung, KHUYẾN NGHỊ | | ⚠ Có thể | ⚠ bật cả hai, hoặc CHỈ Entra ID | | ⚠ Chỉ Entra ID | ⚠ cấu hình "Microsoft Entra-only authentication" |

Từ khoá nhận diện:

"tài khoản công ty, một mật khẩu" → ⚠ Entra ID authentication "tài khoản riêng trong CSDL" → ⚠ SQL authentication "ứng dụng không cần mật khẩu" → ⚠ managed identity "khách hàng đăng nhập bằng Facebook" → ⚠ Entra External ID / B2C

⚠ Cấp quyền theo NHÓM — thực hành quan trọng Nội dung
⚠ Tạo nhóm Entra ID cho từng vai trò nghiệp vụ
⚠ Cấp quyền CSDL cho NHÓM
⚠ Thêm bớt người trong nhóm là xong
⚠ Nếu cấp cho từng người ⚠ mỗi lần thay đổi nhân sự là một lần sửa CSDL
⚠ Ứng dụng thì dùng gì Dùng gì
⚠ Managed identity ⚠ không có mật khẩu để lộ
⚠ App Service, Function, VM đều có
⚠ Cấp quyền cho managed identity như một người dùng
⚠ Đây là ⚠ cách tốt nhất hiện nay cho kết nối ứng dụng tới CSDL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn tài khoản SQL Authentication nào không | | | Quyền cấp cho người hay cho nhóm | | | Ứng dụng đã dùng managed identity chưa | |

Và thay đổi có tác động lớn nhất tới việc quản lý truy cập cơ sở dữ liệu, thường bị hoãn vì ngại: cấp quyền cho nhóm thay vì cho từng người. Sau đó mọi thay đổi nhân sự đều xử lý được ở một chỗ duy nhất.

Câu 115 Relational data security
What feature of SQL Database (based on the SQL Server engine) allows you to prevent sensitive fields (such as social security number, phone number, credit card number) from being displayed in a report by partly hiding the value to provide increased data privacy?
  1. A Row-level security
  2. B Dynamic Data Masking
  3. C Always On Encryption
  4. D Azure Data Encryption
Xem giải thích

Đáp án

B — Dynamic Data Masking.

Vì sao đúng

⚠ Đề mô tả chính xác: che MỘT PHẦN giá trị khi hiển thị:

⚠ Dữ liệu thật: 0901234567
        ↓ ⚠ Dynamic Data Masking
⚠ Người dùng thường thấy: XXXXXX4567
        ↓
⚠ Dữ liệu trên đĩa KHÔNG đổi
⚠ Chỉ che ở kết quả trả về
Kiểu mặt nạ Kết quả
⚠ Default ⚠ che toàn bộ theo kiểu dữ liệu
⚠ Credit card ⚠ hiện 4 số cuối
⚠ Email ⚠ aXX@XXXX.com
⚠ Random ⚠ số ngẫu nhiên trong khoảng
⚠ Custom string ⚠ giữ N ký tự đầu và cuối

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

  • C (Always Encrypted) — ⚠ mã hoá ở client: ⚠ dữ liệu trong CSDL là ⚠ chuỗi mã hoá, không phải giá trị bị che một phần.

  • A (Row-level security) — ⚠ ẩn cả DÒNG, không che cột.

  • D (Azure Data Encryption) — ⚠ thường ám chỉ TDE, mã hoá khi lưu, trong suốt với truy vấn.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ ba về nhóm cơ chế bảo vệ dữ liệu SQL qua hai lô.

Câu Mô tả trong đề Khoá
⚠ #19492 ⚠ kết quả hiện XXX-XXX-8866 ⚠ Dynamic Data Masking
⚠ #19494 ⚠ chỉ giải mã ở client ⚠ Always Encrypted
⚠ #19605 (câu này) ⚠ che một phần trường nhạy cảm trong báo cáo ⚠ Dynamic Data Masking
⚠ Ba câu ⚠ cùng bộ phương án, khoá theo mô tả
⚠ Điểm phân định ⚠ dữ liệu trong CSDL là BẢN RÕ (masking) hay BẢN MÃ (Always Encrypted)

⚠ Bốn cơ chế — bảng chốt: | Cơ chế | Che gì | Ai không đọc được | |---|---|---| | ⚠ TDE | ⚠ tệp trên đĩa | ⚠ người lấy được file | | ⚠ Always Encrypted | ⚠ giá trị cột | ⚠ kể cả DBA | | ⚠ Data Masking | ⚠ một phần giá trị khi hiển thị | ⚠ người dùng thường | | ⚠ RLS | ⚠ cả dòng | ⚠ người không thuộc phạm vi |

Từ khoá nhận diện:

"che một phần, XXX" → ⚠ Data Masking "DBA cũng không đọc được" → ⚠ Always Encrypted "chỉ thấy dòng của mình" → ⚠ RLS "mã hoá file" → ⚠ TDE

⚠ Nhắc lại giới hạn của masking Giới hạn
⚠ KHÔNG phải cơ chế bảo mật mạnh
⚠ Người có quyền truy vấn có thể SUY RA giá trị thật
⚠ Dùng WHERE để dò từng ký tự
⚠ Đúng mục đích ⚠ giảm lộ vô ý cho người dùng nội bộ
⚠ Kết hợp ⚠ với phân quyền cột và RLS
⚠ Ai được xem dữ liệu thật Ai
⚠ Thành viên có quyền UNMASK
⚠ Chủ sở hữu database
⚠ Cấu hình ⚠ GRANT UNMASK cho vai trò cần thiết
⚠ Nên ⚠ cấp UNMASK càng ít càng tốt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đang có quyền UNMASK | | | Người dùng có thể suy ra giá trị bằng WHERE không | | | Có cần bảo vệ mạnh hơn không | ⚠ thì phải Always Encrypted |

Và điều cần nói rõ với bên nghiệp vụ khi triển khai che dữ liệu động, để tránh cảm giác an toàn sai lệch: nó ngăn người ta VÔ TÌNH nhìn thấy, không ngăn người ta CỐ Ý tìm ra.

Câu 116 Analytics Workload
Which of the following types of data is an example of a transactional workload?
  1. A A database that feeds into PowerBI to provide rich and interactive reports.
  2. B A database that feeds into machine learning to build and train models.
  3. C A database that feeds into Azure Analysis Services for complex and processing intensive analytics.
  4. D A database that contains the day-to-day operations of an organization.
Xem giải thích

Đáp án

D — Một cơ sở dữ liệu chứa các hoạt động HẰNG NGÀY của tổ chức.

Vì sao đúng

⚠ Workload giao dịch là nơi ghi nhận nghiệp vụ đang diễn ra: | Ví dụ | Nội dung | |---|---| | ⚠ Đơn hàng, thanh toán | | | ⚠ Nhập xuất kho | | | ⚠ Đăng ký, đặt lịch | | | ⚠ Chấm công, tính lương | |

⚠ Sự kiện xảy ra
        ↓ ⚠ NGAY LẬP TỨC
⚠ Ghi vào CSDL
        ↓
⚠ Nhiều thao tác NGẮN, cần ACID

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

  • A (CSDL nạp vào Power BI để làm báo cáo) — ⚠ là workload PHÂN TÍCH.

  • C (nạp vào Analysis Services để phân tích nặng) — ⚠ cũng là PHÂN TÍCH.

  • B (nạp vào học máy để huấn luyện mô hình) — ⚠ là workload phân tích và khoa học dữ liệu.

⚠ Ba phương án sai đều mô tả nơi dữ liệu ĐI TỚI để phân tích — ⚠ dấu hiệu nhận ra ngay.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ cùng chùm với #19534, #19557, #19607, #19610.

Câu Hỏi gì Khoá
⚠ #19534 ⚠ truy vấn sâu chạy hàng giờ ⚠ OLAP
⚠ #19557 ⚠ ghi dòng ngay khi bán hàng ⚠ transactional
⚠ #19606 (câu này) ⚠ ví dụ nào là workload giao dịch ⚠ hoạt động hằng ngày
⚠ Cùng trục ⚠ giao dịch và phân tích
⚠ Mẹo ⚠ hỏi dữ liệu ĐƯỢC TẠO RA ở đây hay ĐƯỢC ĐỌC ĐI phân tích

⚠ OLTP và OLAP — bảng nhận diện nhanh: | Dấu hiệu trong đề | Loại | |---|---| | ⚠ "hoạt động hằng ngày", "ghi nhận" | ⚠ OLTP | | ⚠ "báo cáo", "phân tích", "nạp vào Power BI" | ⚠ OLAP | | ⚠ "huấn luyện mô hình" | ⚠ phân tích | | ⚠ "đơn hàng, thanh toán" | ⚠ OLTP |

Từ khoá nhận diện:

"vận hành hằng ngày" → ⚠ transactional "nạp vào công cụ báo cáo" → ⚠ analytical "cần ACID" → ⚠ transactional "đọc nhiều, ghi ít" → ⚠ analytical

⚠ Dữ liệu chảy từ OLTP sang OLAP Luồng
⚠ CSDL giao dịch là NGUỒN
⚠ ETL/ELT chuyển sang kho phân tích
⚠ Kho phân tích nạp vào Power BI
⚠ Nghĩa là ⚠ cùng một dữ liệu, hai vai trò khác nhau
⚠ Vì sao không phân tích thẳng trên CSDL giao dịch Lý do
⚠ Truy vấn nặng làm chậm việc bán hàng
⚠ Cấu trúc chuẩn hoá khó viết báo cáo
⚠ Không có dữ liệu lịch sử dài
⚠ Ngoại lệ ⚠ bản sao CHỈ ĐỌC hoặc Synapse Link cho phân tích nhẹ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu được TẠO RA hay được ĐỌC ĐI | ⚠ câu hỏi phân định | | Có báo cáo nặng nào chạy trên CSDL giao dịch không | | | Có cần dữ liệu lịch sử dài không | |

Và câu hỏi phân biệt hai loại workload nhanh nhất, dùng được cho cả chùm câu hỏi này: dữ liệu được SINH RA ở đây, hay được ĐỌC TỪ đây để đi phân tích?

Câu 117 Analytics Workload
Which of the following scenarios would be a poor environment for an analytical database?
  1. A Data that is stored on a system specifically designed for analytics and is not used for any other purpose
  2. B Data that has been pre-proceessed into Cubes
  3. C Data that is constantly changing
  4. D Data that has been de-normalized from it's original source
Xem giải thích

Đáp án

C — Dữ liệu THAY ĐỔI LIÊN TỤC.

Vì sao đúng

⚠ CSDL phân tích được thiết kế cho dữ liệu ỔN ĐỊNH: | Đặc điểm CSDL phân tích | Nội dung | |---|---| | ⚠ Nạp theo lô, đọc nhiều lần | | | ⚠ Phi chuẩn hoá, dữ liệu lặp | ⚠ cập nhật rất tốn | | ⚠ Lưu theo cột, nén cao | ⚠ sửa một dòng phải giải nén cả khối | | ⚠ Chỉ mục và tổng hợp dựng sẵn | ⚠ phải dựng lại khi dữ liệu đổi |

⚠ Dữ liệu đổi liên tục
        ↓
⚠ Phải cập nhật bảng fact, dimension,
   ⚠ chỉ mục, cube, bản tổng hợp
        ↓
⚠ Chi phí cập nhật vượt xa lợi ích

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

  • A (dữ liệu nằm trên hệ thống dành riêng cho phân tích) — ⚠ là điều kiện LÝ TƯỞNG.

  • B (dữ liệu đã tiền xử lý thành cube) — ⚠ cũng lý tưởng: ⚠ tổng hợp sẵn để đọc nhanh.

  • D (dữ liệu đã phi chuẩn hoá từ nguồn gốc) — ⚠ đúng khuôn mẫu của kho dữ liệu.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là câu hỏi NGƯỢC trong chùm OLTP/OLAP.

Câu Hỏi gì Khoá
⚠ #19534 ⚠ bài toán nào hợp OLAP ⚠ truy vấn sâu chạy lâu
⚠ #19606 ⚠ ví dụ nào là giao dịch ⚠ hoạt động hằng ngày
⚠ #19607 (câu này) ⚠ môi trường nào KÉM cho phân tích ⚠ dữ liệu đổi liên tục
⚠ Ba câu ⚠ cùng trục, một câu hỏi ngược
⚠ Mẹo ⚠ câu hỏi ngược: tìm đặc điểm của OLTP đặt vào bối cảnh OLAP

⚠ Vì sao dữ liệu đổi liên tục không hợp kho phân tích: | Lý do | Nội dung | |---|---| | ⚠ Dữ liệu lặp ở nhiều nơi | ⚠ sửa một chỗ phải sửa nhiều chỗ | | ⚠ Bảng tổng hợp phải tính lại | | | ⚠ Nén theo cột không hợp với sửa lẻ | | | ⚠ Báo cáo có thể thấy số khác nhau giữa hai lần chạy | | | ⚠ Kho phân tích thích | ⚠ nạp một lần, đọc nhiều lần |

Từ khoá nhận diện:

"dữ liệu đổi liên tục" → ⚠ thuộc về OLTP "tiền xử lý, cube, phi chuẩn hoá" → ⚠ OLAP "hệ thống riêng cho phân tích" → ⚠ OLAP "cần cập nhật nhiều" → ⚠ KHÔNG hợp kho dữ liệu

⚠ Nếu vẫn cần phân tích dữ liệu đang đổi Cách
⚠ Bản sao CHỈ ĐỌC của CSDL giao dịch
⚠ Synapse Link / HTAP ⚠ phân tích gần thời gian thực
⚠ Change Data Capture nạp tăng dần
⚠ Xử lý dòng cho chỉ số tức thời
⚠ Đừng ⚠ cố biến kho dữ liệu thành hệ thống cập nhật liên tục
⚠ Slowly Changing Dimension — cách kho dữ liệu đối phó Cách
⚠ Type 2: thêm dòng mới thay vì sửa
⚠ Giữ được lịch sử, tránh cập nhật tại chỗ
⚠ Đây là ⚠ giải pháp cho thay đổi CHẬM, không phải thay đổi liên tục

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu thay đổi với tần suất nào | | | Có cần phân tích thời gian thực không | ⚠ thì dùng HTAP hoặc stream | | Bảng tổng hợp mất bao lâu để dựng lại | |

Và điều một kho dữ liệu được thiết kế để làm rất tốt và một việc nó làm rất tệ: nó tối ưu cho việc đọc đi đọc lại dữ liệu ổn định, không phải cho việc theo kịp dữ liệu đang thay đổi từng giây.

Câu 118 Core data workloads
Which of the following data processing techniques would be best used for handling a file containing millions of rows of data?
  1. A Batch processing
  2. B Stream processing
Xem giải thích

Đáp án

A — Xử lý theo LÔ (batch processing).

Vì sao đúng

⚠ Một TỆP chứa hàng triệu dòng là dữ liệu HỮU HẠN, có ranh giới:

⚠ Tệp có điểm ĐẦU và điểm CUỐI
        ↓
⚠ Xử lý cả tệp như một khối
        ↓
⚠ Tận dụng song song hoá
⚠ Biết được tiến độ và thời điểm hoàn thành
Batch phù hợp vì Nội dung
⚠ Dữ liệu đã có sẵn đầy đủ
⚠ Không có yêu cầu độ trễ
⚠ Xử lý cả khối hiệu quả hơn từng dòng
⚠ Chia nhỏ chạy song song được

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

  • B (stream processing) — ⚠ cho dữ liệu VÔ HẠN đang chảy: ⚠ cảm biến, log thời gian thực; ⚠ một tệp tĩnh không phải dòng dữ liệu.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ tư về batch và stream qua hai lô.

Câu Mô tả Khoá
⚠ #19516 ⚠ dữ liệu về một lần mỗi ngày ⚠ batch
⚠ #19537 ⚠ vài giây một lần, nhạy thời gian ⚠ real-time
⚠ #19598 ⚠ lớn, phức tạp, xử lý lâu ⚠ batch
⚠ #19608 (câu này) ⚠ tệp hàng triệu dòng ⚠ batch
⚠ Bốn câu ⚠ ba câu batch, một câu stream
⚠ Nhận diện ⚠ TỆP là dấu hiệu của batch; DÒNG CHẢY là dấu hiệu của stream

⚠ Ranh giới dữ liệu — cách phân biệt căn bản: | Loại | Đặc điểm | |---|---| | ⚠ Bounded (hữu hạn) | ⚠ có đầu có cuối → batch | | ⚠ Unbounded (vô hạn) | ⚠ chảy mãi → stream | | ⚠ Tệp | ⚠ luôn là bounded | | ⚠ Event Hub, IoT Hub | ⚠ luôn là unbounded |

Từ khoá nhận diện:

"tệp, file, khối dữ liệu" → ⚠ batch "dòng, luồng, liên tục" → ⚠ stream "hàng triệu dòng có sẵn" → ⚠ batch "cảm biến gửi mỗi giây" → ⚠ stream

⚠ Xử lý tệp hàng triệu dòng — thực hành Thực hành
⚠ Chia tệp thành phần để chạy song song
⚠ Dùng định dạng cột như Parquet nếu có thể
⚠ Ghi kết quả theo phân vùng
⚠ Có điểm kiểm tra để chạy tiếp khi lỗi
⚠ Công cụ ⚠ Spark, Data Factory, Azure Batch
⚠ Ranh giới mờ: micro-batch Nội dung
⚠ Spark Structured Streaming xử lý dòng bằng các lô RẤT NHỎ
⚠ Độ trễ vài giây tới vài phút
⚠ Nằm giữa ⚠ batch thuần và stream thuần
⚠ Thực dụng ⚠ đủ nhanh cho nhiều nhu cầu "gần thời gian thực"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu có ranh giới không | ⚠ câu hỏi phân định | | Có yêu cầu về độ trễ không | | | Có chia nhỏ chạy song song được không | |

Và cách phân biệt hai mô hình xử lý chắc chắn nhất, gọn hơn mọi định nghĩa: dữ liệu của bạn có điểm KẾT THÚC không? Có thì là lô, không thì là dòng.

Câu 119 Chọn nhiều đáp án Core data workloads
Which of the following is an advantage of batch processing of data? Choose two.
  1. A Processing data altogether is sometimes more efficient than processing data one at a time
  2. B You can choose a time when computers are idle, such as overnight
  3. C One single bad row of data doesn't affect the whole job
  4. D Data gets processed immediately
Xem giải thích

Đáp án

A và B — Xử lý cả khối đôi khi hiệu quả hơn xử lý từng cái một; và bạn chọn được thời điểm máy móc rảnh rỗi, chẳng hạn ban đêm.

Vì sao đúng

⚠ Hai ưu điểm này là lý do xử lý theo lô vẫn tồn tại: | Ưu điểm | Nội dung | |---|---| | ⚠ Hiệu quả theo khối | ⚠ chi phí khởi động chia đều cho nhiều bản ghi | | ⚠ Chọn được giờ chạy | ⚠ tận dụng tài nguyên rảnh, tránh giờ cao điểm | | ⚠ Rẻ hơn | ⚠ không phải chạy liên tục | | ⚠ Dễ chạy lại | |

⚠ Xử lý 1 triệu dòng từng dòng một
   ⚠ = 1 triệu lần mở kết nối, ghi log, commit
⚠ Xử lý theo lô 10.000 dòng
   ⚠ = 100 lần
        ↓
⚠ Nhanh hơn nhiều lần

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

  • D (dữ liệu được xử lý ngay lập tức) — ⚠ NGƯỢC hoàn toàn: ⚠ đó là ưu điểm của xử lý DÒNG.

  • C (một dòng dữ liệu xấu không ảnh hưởng cả công việc) — ⚠ NGƯỢC: ⚠ đây chính là ⚠ NHƯỢC ĐIỂM của xử lý theo lô — ⚠ một dòng hỏng có thể làm ⚠ cả lô thất bại.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án C là ⚠ nhược điểm được viết như ưu điểm — ⚠ dạng nhiễu đáng chú ý.

Điểm Nội dung
⚠ Trong xử lý theo LÔ ⚠ một dòng lỗi có thể làm hỏng cả lô
⚠ Trong xử lý DÒNG ⚠ mỗi bản ghi độc lập, lỗi một cái không ảnh hưởng cái khác
⚠ Vì vậy ⚠ C mô tả ưu điểm của STREAM, không phải batch
⚠ Mẹo ⚠ cảnh giác với phương án nói ngược đặc điểm đã biết

⚠ Ưu và nhược của xử lý theo lô: | Ưu | Nhược | |---|---| | ⚠ Hiệu quả theo khối | ⚠ độ trễ cao | | ⚠ Chọn được giờ chạy | ⚠ một dòng lỗi ảnh hưởng cả lô | | ⚠ Rẻ hơn | ⚠ phát hiện lỗi muộn | | ⚠ Dễ chạy lại toàn bộ | ⚠ kết quả không tức thời |

Từ khoá nhận diện:

"hiệu quả theo khối, chạy ban đêm" → ⚠ ưu điểm batch "kết quả ngay lập tức" → ⚠ ưu điểm stream "lỗi một bản ghi không ảnh hưởng cái khác" → ⚠ ưu điểm stream "chi phí thấp hơn" → ⚠ thường là batch

⚠ Xử lý dòng lỗi trong lô Cách
⚠ Tách dòng lỗi ra "bảng cách ly" ⚠ error rows / dead letter
⚠ Tiếp tục xử lý phần còn lại
⚠ Báo cáo số dòng lỗi sau khi chạy xong
⚠ Cấu hình được ⚠ Data Factory có fault tolerance cho Copy activity
⚠ Không làm việc này ⚠ một dòng hỏng làm hỏng cả đêm chạy
⚠ Chọn giờ chạy — lợi ích thực tế Lợi ích
⚠ Không tranh tài nguyên với hệ thống giao dịch
⚠ Máy ảo low-priority rẻ hơn
⚠ Cửa sổ bảo trì không ảnh hưởng người dùng
⚠ Lưu ý ⚠ múi giờ — "ban đêm" ở đâu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cơ chế cách ly dòng lỗi chưa | ⚠ tránh hỏng cả lô | | Giờ chạy có tránh giờ cao điểm không | | | Chạy lại có an toàn không | |

Và cấu hình cần có cho mọi quy trình xử lý theo lô nghiêm túc, thường chỉ được thêm sau lần đầu hỏng: cách ly dòng lỗi và tiếp tục chạy. Một bản ghi sai định dạng không đáng làm hỏng cả một đêm xử lý.

Câu 120 Analytics Workload
Which of the following database features would be best for an analytics workload and not a transactional workload?
  1. A Semi-structured data, stored in JSON documents
  2. B Unstructured data, stored as binary files in a Blob storage account
  3. C A fully-normalized table structure, requiring a lot of JOINs to extract reports
  4. D Optimized for reading data and not optimized (or even able) to update data
Xem giải thích

Đáp án

D — Tối ưu cho việc ĐỌC dữ liệu và KHÔNG tối ưu (thậm chí không thể) cập nhật dữ liệu.

Vì sao đúng

⚠ Đó là đặc trưng cốt lõi của hệ thống phân tích: | Đặc điểm | Nội dung | |---|---| | ⚠ Đọc rất nhiều, ghi theo lô | | | ⚠ Lưu theo CỘT, nén cao | ⚠ tối ưu quét, kém khi sửa | | ⚠ Phi chuẩn hoá | ⚠ dữ liệu lặp, sửa rất tốn | | ⚠ Bảng tổng hợp dựng sẵn | | | ⚠ Một số kho chỉ hỗ trợ APPEND | |

⚠ Kho phân tích
   ⚠ nạp theo lô → đọc hàng nghìn lần
        ↓
⚠ Việc cập nhật lẻ tẻ gần như không xảy ra
        ↓
⚠ Thiết kế bỏ hẳn tối ưu cho cập nhật

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

  • C (cấu trúc bảng chuẩn hoá hoàn toàn, cần nhiều JOIN) — ⚠ là đặc trưng của OLTP; ⚠ kho phân tích cố ý ⚠ phi chuẩn hoá để giảm JOIN.

  • A (JSON bán cấu trúc) và B (tệp nhị phân trong blob) — ⚠ nói về LOẠI dữ liệu, ⚠ không phải đặc trưng phân biệt hai loại workload.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ tư trong chùm OLTP/OLAP của lô này.

Câu Hỏi gì Khoá
⚠ #19589 ⚠ data warehouse workload là gì ⚠ toàn bộ quy trình
⚠ #19606 ⚠ ví dụ workload giao dịch ⚠ hoạt động hằng ngày
⚠ #19607 ⚠ môi trường kém cho phân tích ⚠ dữ liệu đổi liên tục
⚠ #19610 (câu này) ⚠ tính năng hợp phân tích, không hợp giao dịch ⚠ tối ưu đọc, không cập nhật
⚠ Bốn câu ⚠ cùng một trục kiến thức trong một lô

⚠ OLTP và OLAP — bảng đối chiếu cuối cùng: | Tiêu chí | OLTP | OLAP | |---|---|---| | ⚠ Tối ưu cho | ⚠ GHI và cập nhật | ⚠ ĐỌC và tổng hợp | | ⚠ Chuẩn hoá | ⚠ cao | ⚠ thấp | | ⚠ Lưu trữ | ⚠ theo dòng | ⚠ theo cột | | ⚠ Dữ liệu | ⚠ hiện tại | ⚠ lịch sử dài | | ⚠ Truy vấn | ⚠ nhiều, ngắn | ⚠ ít, nặng | | ⚠ Người dùng | ⚠ ứng dụng, nhân viên | ⚠ nhà phân tích, lãnh đạo |

Từ khoá nhận diện:

"tối ưu đọc, không cập nhật" → ⚠ phân tích "chuẩn hoá cao, nhiều JOIN" → ⚠ giao dịch "lưu theo cột" → ⚠ phân tích "ACID, giao dịch ngắn" → ⚠ giao dịch

⚠ Vì sao lưu theo cột hợp với đọc Lý do
⚠ Truy vấn phân tích chỉ dùng vài cột trong hàng chục cột
⚠ Lưu theo cột chỉ đọc đúng cột cần
⚠ Giá trị cùng cột giống nhau nên nén rất tốt
⚠ Nhược ⚠ sửa một dòng phải chạm vào mọi cột
⚠ Delta Lake làm mờ ranh giới Nội dung
⚠ Cho phép UPDATE và DELETE trên data lake
⚠ Nhờ ghi lại phiên bản thay vì sửa tại chỗ
⚠ Nhưng ⚠ vẫn không phù hợp cho cập nhật lẻ tẻ tần suất cao

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hệ thống này đọc nhiều hay ghi nhiều | | | Có cần cập nhật lẻ tẻ thường xuyên không | | | Cấu trúc chuẩn hoá hay phi chuẩn hoá | |

Và điểm khiến hai loại hệ thống không thể gộp làm một dù nghe như trùng lặp: tối ưu cho ghi và tối ưu cho đọc kéo thiết kế về hai hướng đối nghịch nhau. Chọn cả hai nghĩa là không tối ưu cho cái nào.