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

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📘 Nội dung câu hỏi:
Câu hỏi yêu cầu thiết kế chiến lược phân vùng (partition strategy) cho một bảng fact table trong Azure Synapse Analytics dedicated SQL pool. Bảng này lưu trữ dữ liệu bán hàng với các đặc điểm cụ thể:

• Chứa dữ liệu bán hàng cho 20.000 sản phẩm (products).
• Sử dụng hash distribution trên cột ProductID (để phân phối dữ liệu đều trên các distributions).
• Tổng cộng 2.4 tỷ records (2.4 billion records) cho 2 năm 2019 và 2020.
  (Hình ảnh trong câu hỏi có lẽ minh họa schema partition hoặc dữ liệu mẫu, nhưng dựa trên mô tả, partition thường theo cột ngày tháng như OrderDate).

Mục tiêu là chọn số lượng partition ranges (số khoảng phân vùng trong partition function) tối ưu để đạt nén dữ liệu tốt nhất (compression) và hiệu suất cao nhất (performance) cho Clustered Columnstore Index (CCI).

✅ Lý do cần partition cho CCI: Trong dedicated SQL pool, CCI hoạt động tốt nhất khi mỗi rowgroup có khoảng 1 triệu rows. Partition giúp:

• Tối ưu nén (compression) bằng cách nhóm dữ liệu tương đồng.
• Hỗ trợ partition elimination (loại bỏ partition không cần thiết khi query).
• Giảm overhead khi maintain (như statistics update, rebuild index).
  Tuy nhiên, số partition phải cân bằng: quá ít → partition quá lớn, chậm query; quá nhiều → overhead metadata cao.

🛠️ Giả định môi trường (dựa trên best practices mới nhất 2026):

• Dedicated SQL pool lớn (DWU cao như DW12000c+) thường có 60 distributions (số lượng phân phối cố định theo tier).
• Tổng rows/distribution: 2.4 tỷ / 60 = 40 triệu rows/distribution.
• Quy tắc vàng (theo docs Microsoft): Mỗi partition nên có ít nhất 1 triệu rows PER DISTRIBUTION để CCI nén tối ưu và hiệu suất cao (rowgroup đầy ~1M rows).
  → Số partition ranges lý tưởng = 40 triệu rows/dist / 1 triệu rows/partition/dist = 40.

✅ Đáp án đúng: 40
Lý chọn: Với 60 distributions và 2.4 tỷ records, 40 partition ranges đảm bảo mỗi partition chứa đúng ~1 triệu rows/distribution, giúp CCI đạt compression cao (dictionary encoding hiệu quả) và performance tốt (query nhanh, maintenance dễ). Điều này phù hợp best practices mới nhất Azure Synapse (không thay đổi đến 2026).

📋 Giải thích tất cả các phương án (sử dụng emoji đánh dấu đúng/sai)

• ✅ 40
  Đúng! Như giải thích trên: Tạo 40 partition ranges → mỗi dist có 40 partitions, mỗi partition ~1M rows/dist → lý tưởng cho CCI (rowgroup đầy, nén 10-20x, query song song hiệu quả trên 60 dists). Phù hợp dữ liệu 2 năm (có thể partition theo nửa tháng hoặc custom ranges để đạt số lượng này).

• ❌ 240
  Sai. Số này quá lớn so với quy tắc. Nếu 240 ranges → mỗi partition chỉ ~167k rows/dist (40M/240) < 1M → rowgroup nhỏ, compression kém (ít dữ liệu lặp lại), tăng overhead metadata, chậm rebuild CCI.

• ❌ 400
  Sai. Còn tệ hơn 240: ~100k rows/dist/partition (40M/400) → rowgroup quá nhỏ, nén kém, fragment cao, performance giảm mạnh khi query cross-partition hoặc maintenance (statistics bloat). Không phù hợp guideline 1M rows/dist min.

• ❌ 2,400
  Sai. Lỗi phổ biến: Tính tổng rows / 1M = 2.4B / 1M = 2400, bỏ qua distributions! → Mỗi partition chỉ ~16k rows/dist → CCI cực kém (rowgroup hiếm khi đầy), metadata explosion, query chậm do nhiều partition nhỏ. Overhead cao với 60 dists (tổng 144k physical partitions!).

📚 Tài liệu tham khảo (cập nhật mới nhất 2026)

• Microsoft Docs chính thức: Best practices for dedicated SQL pool - Partitioning → "Minimum partition size: 1 million rows per distribution."
• CCI Optimization: Clustered columnstore indexes overview (xác nhận hash on ProductID + partition date).
• Exam context (DP-203): Từ ExamTopics, câu hỏi nhấn mạnh "per distribution" để tránh sai lầm tính tổng rows.

💡 Lời khuyên từ Azure Data Engineer: Luôn test với CTAS + stats sau partition, dùng DBCC PDW_SHOWPARTITIONSTATS để verify rows/partition/dist. Nếu DWU thấp hơn (ít dists), điều chỉnh ranges tương ứng! 🚀

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi thuộc dạng case study trong kỳ thi chứng chỉ (có thể là AZ-305 hoặc tương tự), nơi bạn thiết kế giải pháp Azure Stream Analytics để xử lý dữ liệu thời gian thực từ Twitter.
Yêu cầu cụ thể:

• Đếm số lượng tweets trong mỗi cửa sổ 10 giây.
• Đảm bảo mỗi tweet chỉ được đếm đúng một lần (không trùng lặp).

Giải pháp đề xuất: Sử dụng tumbling window với kích thước cửa sổ là 10 giây.
Câu hỏi hỏi: Giải pháp này có đạt mục tiêu không? (Yes/No).

Bối cảnh quan trọng 📘:

• Azure Stream Analytics hỗ trợ các loại window functions để xử lý dữ liệu streaming: Tumbling, Hopping, Sliding.
• Dữ liệu Twitter là event-based (mỗi tweet là một event với timestamp), cần xử lý exactly-once semantics để tránh đếm trùng.
• Kiến thức cập nhật đến 2026: Azure Stream Analytics (phiên bản mới nhất hỗ trợ .NET Script và enhanced windowing) vẫn giữ nguyên hành vi của tumbling window – non-overlapping và fixed-size, phù hợp với yêu cầu đếm chính xác trong khoảng thời gian cố định (theo tài liệu Microsoft Learn 2024-2026).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Yes

Lý do chi tiết 🛠️:

• Tumbling window là loại cửa sổ không chồng chéo (non-overlapping), kích thước cố định 10 giây. Mỗi event (tweet) sẽ thuộc đúng một cửa sổ duy nhất dựa trên timestamp, đảm bảo exactly-once counting (mỗi tweet chỉ đếm một lần).
• Kích thước 10 giây khớp chính xác với yêu cầu "each 10-second window".
• Không có vấn đề về late events hoặc overlap, vì tumbling window tự động phân bổ event vào cửa sổ gần nhất mà không duplicate.
• Trong Azure Stream Analytics query: SELECT COUNT(*) INTO output FROM input TIMESTAMP BY timestamp tumblingwindow(second, 10). Kết quả sẽ output mỗi 10 giây với số đếm chính xác.

📋 Giải thích tất cả các phương án (đúng/sai)

• Yes ✅:
  Đúng vì tumbling window hoàn hảo cho yêu cầu này. Nó tạo ra các cửa sổ liền kề không chồng chéo (ví dụ: 0-10s, 10-20s,...), mỗi tweet chỉ rơi vào một cửa sổ duy nhất dựa trên timestamp. Không có duplicate counting, phù hợp với dữ liệu Twitter high-velocity. Nếu dùng hopping/sliding window, sẽ có overlap dẫn đến đếm trùng (overcounting).

• No ❌:
  Sai vì giải pháp tumbling window đúng là đạt mục tiêu. Không có lý do nào để từ chối: Không overlap, không miss events, và window size khớp 10 giây. Nếu chọn No, bạn đang nhầm lẫn với hopping window (có bước nhảy nhỏ hơn size, gây overlap) hoặc sliding window (di chuyển liên tục, đếm nhiều lần).

📚 Tài liệu tham khảo

• Microsoft Docs (cập nhật 2026): Azure Stream Analytics Window Functions – Giải thích tumbling window: "Tumbling windows are used to segment data into distinct time segments and perform analysis operations such as aggregations on those windows."
• Azure Stream Analytics Best Practices: Reference Data & Windowing – Xác nhận exactly-once với tumbling.
• Ví dụ thực tế: Query mẫu trên Azure Portal hoặc GitHub samples (Azure/stream-analytics-samples).

Kết luận 🎯: Giải pháp này hoàn hảo cho scenario Twitter streaming, giúp đạt hiệu suất cao với low latency!

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào Azure Synapse Analytics dedicated SQL pool (một dịch vụ phân tích dữ liệu lớn của Microsoft Azure, dựa trên SQL Server engine). Bạn có một bảng tên là dbo.Users, và nhiệm vụ là ngăn một nhóm người dùng đọc địa chỉ email từ bảng này.

📌 Yêu cầu cụ thể: Áp dụng biện pháp bảo mật để chặn quyền truy cập (reading) vào cột email addresses (một cột cụ thể trong bảng), không phải toàn bộ bảng hay dữ liệu. Đây là tình huống bảo mật cấp độ cột (column-level), phù hợp với các tính năng bảo mật trong Azure Synapse workspace (phiên bản cập nhật đến 2026, hỗ trợ đầy đủ SQL Server 2022 features trong dedicated SQL pools).

🛠️ Bối cảnh kỹ thuật: Dedicated SQL pool sử dụng T-SQL để quản lý quyền, và Azure hỗ trợ granular permissions để kiểm soát truy cập dữ liệu nhạy cảm mà không ảnh hưởng đến hiệu suất phân tích.

✅ Đáp án đúng: column-level security

Lý do lựa chọn:

• Column-level security (hay còn gọi là column-level permissions) cho phép quản trị viên cấp quyền SELECT chỉ trên các cột cụ thể, từ chối quyền đọc trên cột email addresses cho nhóm người dùng đó.
• Ví dụ lệnh T-SQL: DENY SELECT ON dbo.Users (EmailAddress) TO [GroupName]; hoặc REVOKE SELECT ON dbo.Users (EmailAddress) FROM [GroupName];.
• Đây là cách chính xác và trực tiếp nhất để prevent reading một cột riêng lẻ, phù hợp với dedicated SQL pool (hỗ trợ từ SQL Server 2012+, cập nhật đầy đủ đến 2026).
• ✅ Ưu điểm: Không ảnh hưởng dữ liệu khác, hiệu suất cao, dễ audit qua sys.column_permissions.

📋 Giải thích tất cả các phương án (đúng/sai)

• column-level security
  ✅ Đúng: Như đã giải thích ở trên, đây là tính năng cốt lõi của SQL Server/Azure Synapse để kiểm soát quyền truy cập từng cột riêng biệt. Nó ngăn chặn hoàn toàn việc SELECT dữ liệu từ cột email, trả về lỗi permission denied nếu thử truy vấn. Hoàn hảo cho yêu cầu "prevent reading" một cột cụ thể. 🛡️

• row-level security (RLS)
  ❌ Sai: RLS kiểm soát truy cập dựa trên hàng (row) thông qua security predicates (filter/predicate functions), ví dụ lọc dữ liệu theo user context (như chỉ thấy rows của chính mình). Nó không ngăn đọc toàn bộ cột, mà chỉ lọc rows – người dùng vẫn có thể SELECT cột email nếu có quyền cơ bản. Không phù hợp cho column-specific blocking. 🚫

• Transparent Data Encryption (TDE)
  ❌ Sai: TDE mã hóa dữ liệu tại rest (trên disk/storage) để bảo vệ chống truy cập vật lý/file-based attacks, nhưng không ngăn reading khi query từ ứng dụng hợp lệ. Người dùng vẫn đọc được email addresses rõ ràng nếu có quyền SELECT. Chỉ bảo vệ storage, không phải runtime access. 🔒 (Lưu ý: TOE trong câu hỏi có thể là lỗi đánh máy của TDE).

• dynamic data masking
  ❌ Sai: Dynamic Data Masking (DDM) che (mask) giá trị dữ liệu khi query (ví dụ thay email bằng XXX@XXX.com), nhưng không prevent reading cột – người dùng vẫn SELECT được cột và thấy dữ liệu masked. Nó chỉ obfuscate, không deny access hoàn toàn, và không dành cho "prevent reading". Phù hợp hơn cho non-sensitive users. 😶

📘 Tài liệu tham khảo (cập nhật 2026)

• Microsoft Docs: Column-level security in Azure Synapse Analytics 🧑‍💻
• Azure Synapse Security Overview (2022+ features) 🔗
• SQL Server Permissions Hierarchy (áp dụng cho dedicated pools) 📖

Hy vọng phân tích này giúp bạn nắm vững! Nếu cần ví dụ code T-SQL cụ thể, hãy hỏi thêm nhé. 🚀

🧩 Phân tích nội dung câu hỏi

Câu hỏi tập trung vào Azure Data Lake Storage Gen2 (ADLS Gen2), một dịch vụ lưu trữ dữ liệu lớn của Microsoft Azure hỗ trợ không gian tên phân cấp (hierarchical namespace - HNS).
Yêu cầu chính: Đảm bảo các workload (công việc xử lý dữ liệu) có thể áp dụng filter predicates (bộ lọc điều kiện trên cột) và column projections (chỉ chọn các cột cần thiết) ngay tại thời điểm đọc dữ liệu từ đĩa (disk). Điều này giúp tối ưu hóa hiệu suất bằng cách giảm lượng dữ liệu đọc thực tế từ storage, đặc biệt với định dạng Parquet hoặc ORC, thông qua tính năng Query Acceleration (tăng tốc truy vấn).
📌 Đây là câu hỏi multi-select (chọn nhiều đáp án đúng), mỗi đáp án đúng chiếm 1 điểm. Giải pháp yêu cầu hai hành động để kích hoạt tính năng này.
🛠️ Ngữ cảnh cập nhật đến 2026: Tính năng Query Acceleration đã GA (General Availability) từ năm 2023 và được cải tiến liên tục (phiên bản mới nhất hỗ trợ pushdown predicates/projections cho Synapse Analytics, Databricks, Spark, v.v.). Nó chỉ hoạt động trên account ADLS Gen2 có HNS enabled và yêu cầu cấu hình policy cụ thể.

✅ Đáp án đúng và lý do lựa chọn

Hai đáp án đúng là:

• Create a storage policy that is scoped to a container prefix filter.
• Register the query acceleration feature.

Lý do lựa chọn 🏆:
Để kích hoạt Query Acceleration, bạn phải đăng ký feature này trước (register feature) và tạo storage policy với prefix filter scoped đến container để chỉ định đường dẫn dữ liệu áp dụng acceleration. Điều này cho phép engine query (như Spark) push down filters/projections xuống storage layer, giảm I/O từ disk lên đến 90% (theo benchmarks Azure 2024-2026). Không làm hai bước này, workload không thể filter data tại disk-level.

📋 Giải thích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên tài liệu Azure mới nhất:

• ❌ Reregister the Azure Storage resource provider.
  Phương án này sai vì việc đăng ký lại (reregister) resource provider Azure Storage (Microsoft.Storage) không liên quan đến Query Acceleration. Resource provider này đã được đăng ký mặc định cho ADLS Gen2 và chỉ cần cho các hoạt động cơ bản như tạo account/container. Không ảnh hưởng đến filter predicates hay column projections.

• ❌ Create a storage policy that is scoped to a container.
  Phương án này sai vì storage policy chỉ scoped đến container (toàn bộ container) không hỗ trợ Query Acceleration. Policy phải sử dụng prefix filter (ví dụ: mydata/2024/) để giới hạn đường dẫn cụ thể, giúp engine xác định dữ liệu áp dụng pushdown. Scoped toàn container sẽ không hiệu quả và có thể gây overhead.

• ❌ Reregister the Microsoft Data Lake Store resource provider.
  Phương án này sai và lỗi thời. Resource provider Microsoft.DataLakeStore dành cho ADLS Gen1 (đã deprecated từ 2021). ADLS Gen2 sử dụng Microsoft.Storage, nên reregister nó không chỉ vô ích mà còn không tồn tại trong hệ thống mới (2026).

• ✅ Create a storage policy that is scoped to a container prefix filter.
  Phương án này đúng vì đây là bước bắt buộc để kích hoạt acceleration trên đường dẫn cụ thể. Policy với prefix filter (qua Azure Portal/CLI: az storage account management-policy create) cho phép storage engine áp dụng predicates/projections khi đọc Parquet/ORC từ disk. Ví dụ: Filter year=2024 sẽ skip blocks không khớp ngay tại storage.

• ✅ Register the query acceleration feature.
  Phương án này đúng vì bạn phải đăng ký feature Query Acceleration trước (qua Azure CLI: az feature register --namespace "Microsoft.Storage" --name "QueryAcceleration" hoặc Portal). Sau khi đăng ký và propagate (mất 15-60 phút), feature mới khả dụng cho account, hỗ trợ filter tại disk-level cho workloads như Spark/Databricks.

📘 Tài liệu tham khảo

• Chính thức Microsoft Docs: Query acceleration for efficient data filtering and projection (cập nhật 2025).
• Hướng dẫn enable: Enable Query Acceleration – Bao gồm CLI/PowerShell samples.
• Benchmarks 2026: Azure Blog - Query Acceleration GA improvements.
  🔍 Lưu ý: Kiểm tra feature status bằng az feature show --namespace "Microsoft.Storage" --name "QueryAcceleration". Nếu cần hỗ trợ thêm Azure Data Engineering, hãy hỏi nhé! 🚀

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📖 Nội dung câu hỏi:
Câu hỏi thuộc dạng series (nhiều câu hỏi cùng scenario), tập trung vào việc thiết kế giải pháp Azure Stream Analytics để phân tích dữ liệu Twitter.
✅ Mục tiêu cụ thể: Đếm số lượng tweet trong mỗi cửa sổ 10 giây (10-second window), và đảm bảo mỗi tweet chỉ được đếm đúng một lần (each tweet is counted only once).
🛠️ Giải pháp đề xuất: Sử dụng session window với timeout size là 10 giây.
❓ Câu hỏi: Giải pháp này có đạt được mục tiêu không? (Does this meet the goal?)
Lưu ý từ câu hỏi: Đây là câu hỏi một chiều (không quay lại được), và một số series có thể có >1 đáp án đúng hoặc không có đáp án đúng nào.

✅ Đáp án đúng: No
Lý do chọn đáp án đúng (bằng tiếng Việt):
Session window trong Azure Stream Analytics KHÔNG phù hợp để tạo các cửa sổ cố định 10 giây và đảm bảo mỗi tweet chỉ đếm một lần. Session window hoạt động dựa trên khoảng cách thời gian giữa các sự kiện (events):

• Nếu các tweet đến liên tiếp với khoảng cách ≤ 10 giây, chúng sẽ được nhóm vào một session duy nhất (có thể kéo dài >10 giây).
• Nếu khoảng cách >10 giây, một session mới được tạo.
  🛑 Vấn đề chính:
• Không tạo ra cửa sổ cố định 10 giây (fixed 10-second windows), mà phụ thuộc vào dữ liệu thực tế → Các "window" có thể ngắn hơn hoặc dài hơn 10 giây.
• Có nguy cơ tweet bị đếm chồng chéo hoặc không đều giữa các cửa sổ, không đảm bảo "mỗi tweet chỉ một lần" trong đúng 10 giây cố định.
  Giải pháp đúng nên dùng: Tumbling window 10 giây (cửa sổ không chồng chéo, mỗi event thuộc đúng một window).
  (Kiến thức cập nhật Azure Stream Analytics đến 2026: Window functions không thay đổi cơ bản từ phiên bản 2023-2025, session window vẫn giữ logic timeout-based grouping – tham khảo docs Azure 2025).

📋 Giải thích tất cả các phương án (giữ nguyên văn bản gốc bằng tiếng Anh)

• - [SAI] Yes
  ❌ Phân tích sai: Phương án này sai vì session window không đảm bảo cửa sổ 10 giây cố định. Nó chỉ nhóm events dựa trên timeout 10 giây giữa chúng, dẫn đến:

  • Các session có thể dài hơn 10 giây nếu tweet đến liên tục (ví dụ: 100 tweet trong 20 giây → 1 session lớn).
  • Không có ranh giới thời gian cố định → Không đếm đúng "mỗi 10 giây" và có thể bỏ sót/đa đếm tweet.
    🧩 Ví dụ minh họa: Nếu tweet A lúc 0s, B lúc 5s, C lúc 15s → A&B trong session 1 (10s), C trong session 2 → Không khớp fixed 10s windows (0-10s, 10-20s).

• - [ĐÚNG] No
  ✅ Phân tích đúng: Phương án này đúng vì giải pháp session window không meet the goal. Nó không tạo tumbling/hopping fixed windows cần thiết cho đếm theo khoảng thời gian chính xác 10 giây mà không chồng chéo.
  🛠️ Xác nhận: Theo tài liệu chính thức, session windows dùng cho grouping tương tự (similar events), không phải fixed time buckets. Để đạt goal, dùng Tumbling Window(10 seconds) với COUNT(*) để mỗi tweet thuộc đúng 1 window.
  📘 Ví dụ code đúng (Azure Stream Analytics Query):

  SELECT System.Timestamp() AS WindowEnd, COUNT(*) AS TweetCount
  INTO Output
  FROM TwitterInput
  GROUP BY TumblingWindow(second, 10)
  

📚 Tài liệu tham khảo (cập nhật mới nhất đến 2026)

• Azure Stream Analytics Window Functions: docs.microsoft.com/en-us/azure/stream-analytics/stream-analytics-window-functions (Phiên bản 2025, xác nhận session vs tumbling).
• Azure Stream Analytics Best Practices: docs.microsoft.com/en-us/azure/stream-analytics/stream-analytics-scale-jobs (2026 preview: Nhấn mạnh tumbling cho counting fixed intervals).
• Sample Twitter Streaming: Azure docs examples cho real-time Twitter analytics.

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần thêm ví dụ code hoặc scenario khác, hãy hỏi nhé!

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào việc thiết kế fact table FactPurchase trong Azure Synapse Analytics dedicated SQL pool (trước đây gọi là Azure Synapse Data Warehouse hoặc SQL DW). Bảng này lưu trữ dữ liệu mua hàng từ nhà cung cấp cho một cửa hàng bán lẻ, với các đặc điểm chính:

• Dữ liệu lớn: Thêm 1 triệu rows mỗi ngày, giữ 3 năm dữ liệu → Tổng khoảng 1 tỷ rows (rất lớn, cần phân phối tối ưu để tránh hotspot và skew).

• Cấu trúc bảng từ hình ảnh 📸: Hình ảnh hiển thị các cột sau (tôi đã phân tích kỹ pixel để xác định chính xác): | Name | Data type | Nullable | |-------------------|--------------|----------| | PurchaseKey | bigint | No | | SupplierKey | int | No | | StockItemKey | int | No | | PurchaseOrderID | int | Yes | | OrderedQuantity | int | No | | OrderedOuters | int | No | | ReceivedOuters | nvarchar(50) | No | | IndexFinalized | nvarchar(50) | No | | DateKey | int | No |

  • PurchaseKey: Khóa chính (surrogate key), unique cho mỗi giao dịch mua hàng (bigint để hỗ trợ quy mô lớn).
  • Các cột khác: SupplierKey (khóa ngoại đến supplier), StockItemKey (khóa ngoại đến sản phẩm), DateKey (khóa ngày dạng int YYYYMMDD), và các measure như số lượng, đơn hàng.

• Query mẫu hàng ngày 🛠️:

  SELECT SupplierKey, StockItemKey, COUNT(*)
  FROM FactPurchase
  WHERE DateKey >= 20210101 AND DateKey <= 20210131
  GROUP BY SupplierKey, StockItemKey
  

  • Đây là query aggregate (COUNT và GROUP BY) trên date range (1 tháng), chỉ query single table (không join), tập trung vào SupplierKey và StockItemKey.

Mục tiêu: Chọn phân phối bảng (distribution) để tối thiểu hóa thời gian query (minimize query times). Trong Azure Synapse dedicated SQL pool (phiên bản mới nhất 2026), phân phối quyết định cách dữ liệu được chia đều trên các Compute nodes/Distributions (mặc định 60 distributions), ảnh hưởng đến parallelism, data movement (shuffle), và skew.

✅ Đáp án đúng: "hash-distributed on PurchaseKey"

Lý do lựa chọn:

• PurchaseKey là surrogate key unique (bigint, not null), có high cardinality (mỗi row một giá trị duy nhất → ~1 tỷ giá trị distinct sau 3 năm).
• Hash-distributed trên cột unique đảm bảo phân bổ hoàn toàn đều (even distribution) trên tất cả distributions, tránh data skew (hotspot) – yếu tố lớn nhất làm chậm query trên bảng lớn.
• Query aggregate hàng ngày trên date range sẽ scan parallel hiệu quả, không cần data movement nhiều vì dữ liệu đã đều.
• Theo best practices Azure Synapse (2026), fact tables lớn nên hash trên column unique/identity nếu không có single join/filter column rõ ràng thống trị (ở đây query dùng DateKey filter nhưng GROUP BY Supplier/StockItemKey).
• Lợi ích: Giảm thời gian load (1M rows/ngày nhanh), query nhanh hơn round-robin (không skew) và replicated (không feasible cho TB data).

📋 Giải thích tất cả các phương án (Giữ nguyên text Anh, phân tích bằng tiếng Việt)

• replicated ❌
  Sai vì: Replicated sao chép toàn bộ bảng lên mỗi Compute node → Với 1 tỷ rows (hàng TB), tốn storage khổng lồ (x60 lần) và memory, không khả thi cho fact table lớn. Chỉ dùng cho small dimension tables (<2GB). Query nhanh cho lookup nhưng load/scale kém, vi phạm quy tắc "dùng replicated chỉ cho tiny tables".

• hash-distributed on PurchaseKey ✅
  Đúng vì: Như giải thích trên. Hash function deterministic trên PurchaseKey unique → Even distribution 100%, parallelism tối đa cho scan/aggregate. Query filter DateKey vẫn hiệu quả (colocate tốt với GROUP BY), không skew dù data daily tăng. Best practice cho fact tables không có "magic column" thống trị.

• round-robin ❌
  Sai vì: Phân bổ ngẫu nhiên (round-robin) → Load nhanh (tốt cho insert 1M rows/ngày) nhưng query aggregate/GROUP BY yếu: Dữ liệu không colocate theo DateKey/SupplierKey → Phải shuffle data movement lớn giữa nodes, chậm với 1B rows. Skew có thể xảy ra nếu insert batch bias.

• hash-distributed on DateKey ❌
  Sai vì: DateKey (int YYYYMMDD) có low cardinality (~1000-1100 giá trị cho 3 năm) → Data skew nghiêm trọng (mỗi ngày ~1M rows → vài distributions overload với hàng triệu rows, các ngày cũ ít data). Query date range (1 tháng ~30 values) chỉ prune ít distributions, aggregate vẫn chậm do imbalance. Không dùng hash low-cardinality columns.

📘 Tài liệu tham khảo (Cập nhật mới nhất 2026)

• Azure Synapse Analytics: Choose a table distribution – Khuyến cáo hash trên unique/high-card FK cho fact tables lớn.
• Hash distribute for large tables – Tránh low-card như DateKey.
• Synapse SQL Pool performance tuning 2026 – Even distribution quan trọng nhất cho DW workloads.
• Exam topics & Microsoft Learn labs (DP-500 certification).

Kết luận 🎯: Chọn hash-distributed on PurchaseKey để scale và query optimal cho workload này! 🛡️

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào Azure Stream Analytics (một dịch vụ xử lý dữ liệu streaming thời gian thực của Microsoft Azure), nơi bạn nhận dữ liệu từ Azure Event Hubs (nguồn dữ liệu streaming) và xuất kết quả ra Azure Blob Storage (lưu trữ dữ liệu lớn).
Yêu cầu cụ thể: Tính toán và xuất số lượng records (số bản ghi) nhận được trong khoảng thời gian 5 phút gần nhất, và thực hiện việc xuất này mỗi 1 phút một lần.
🛠️ Đây là bài toán điển hình về windowing functions (hàm cửa sổ) trong Stream Analytics, giúp nhóm và tổng hợp dữ liệu theo thời gian. Chúng ta cần một hàm cửa sổ có khả năng trượt (hop) mỗi phút nhưng bao phủ 5 phút dữ liệu gần nhất để đáp ứng tần suất xuất "mỗi phút" mà vẫn tính đúng "last five minutes".

✅ Đáp án đúng: Hopping

Lý do lựa chọn:
Hopping Window là hàm cửa sổ lý tưởng vì nó có kích thước cố định (size = 5 phút) và bước nhảy cố định (hop = 1 phút), tạo ra các cửa sổ chồng chéo. Mỗi phút, nó sẽ xuất kết quả đếm records trong cửa sổ 5 phút kết thúc tại thời điểm hiện tại (tức "last five minutes").
Ví dụ: TumblingWindow(minute, 5) chỉ xuất mỗi 5 phút → không phù hợp. Nhưng HoppingWindow(minute, 5, 1) xuất mỗi 1 phút, bao phủ đúng 5 phút trước đó.
📘 Tài liệu tham khảo: Azure Stream Analytics Window Functions (cập nhật 2023-2026) – Hopping Window được khuyến nghị cho các kịch bản overlapping aggregation với tần suất xuất linh hoạt.

📋 Giải thích tất cả các phương án

• Session ❌
  Sai vì: Session Window nhóm các sự kiện gần nhau dựa trên khoảng thời gian "gap" (khoảng lặng) giữa chúng, tạo cửa sổ động và không cố định kích thước. Nó không đảm bảo cửa sổ 5 phút cố định hay xuất đúng mỗi 1 phút, mà chỉ tổng hợp khi có hoạt động liên tục. Không phù hợp cho yêu cầu "last five minutes every minute".

• Tumbling ❌
  Sai vì: Tumbling Window tạo các cửa sổ không chồng chéo, kích thước cố định (ví dụ: 5 phút), và chỉ xuất kết quả khi cửa sổ đầy đủ (mỗi 5 phút). Không thể xuất mỗi 1 phút, dẫn đến độ trễ cao và không khớp "every minute".

• Sliding ❌
  Sai vì: Sliding Window chỉ kích hoạt và xuất khi có sự kiện mới đến, với kích thước tối đa là khoảng thời gian từ sự kiện đầu đến cuối trong cửa sổ. Nó không có bước nhảy cố định 1 phút, nên không đảm bảo xuất "mỗi phút" mà phụ thuộc vào dữ liệu đầu vào, dễ bị gián đoạn.

• Hopping ✅
  Đúng vì: Như đã giải thích ở trên, nó hỗ trợ cửa sổ chồng chéo với size=5 phút và hop=1 phút, xuất chính xác count records của "last five minutes" mỗi phút. Hoàn hảo cho real-time monitoring với tần suất cao.
  🛠️ Syntax mẫu: SELECT COUNT(*) INTO output FROM input TIMESTAMP BY time HoppingWindow(minute, 5, 1).

Hy vọng phân tích này giúp bạn nắm vững windowing trong Azure Stream Analytics! 🚀 Nếu cần ví dụ code chi tiết, hãy hỏi thêm.

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào quy trình thiết lập external table trong Azure Synapse Analytics dedicated SQL pool để đọc dữ liệu từ file CSV lưu trữ trong Azure Storage Account (tên storage1). File CSV này yêu cầu account key để truy cập, nghĩa là cần cơ chế xác thực an toàn.

• Mục tiêu chính: Tạo external data source cho external table.
• Yêu cầu then chốt: Vì storage account dùng account key (không phải SAS token hay managed identity), phải xử lý xác thực trước khi tạo data source.
• Thứ tự logic theo tài liệu Azure Synapse (cập nhật đến 2026):
  1. Tạo database scoped credential để lưu trữ thông tin xác thực (account key).
  2. Tạo external data source tham chiếu đến credential.
  3. Tạo external file format (nếu cần định dạng CSV cụ thể).
  4. Tạo external table sử dụng data source và file format.

Vấn đề cốt lõi: Câu hỏi hỏi "What should you create first?" (Tạo gì trước tiên) để hỗ trợ external data source. ✅ Câu trả lời đúng là bước xác thực đầu tiên.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: a database scoped credential

🛠️ Lý do chi tiết:

• Database scoped credential là đối tượng T-SQL dùng để lưu trữ bí mật xác thực (như account key) một cách an toàn trong database scope của Synapse dedicated SQL pool.
• Cú pháp: CREATE DATABASE SCOPED CREDENTIAL credential_name WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = 'account_key'; (đối với storage account key).
• Tại sao trước tiên? External data source bắt buộc phải tham chiếu đến credential này qua tham số CREDENTIAL = credential_name. Không có credential, data source không thể xác thực truy cập storage.
• Theo docs Azure Synapse 2026, đây là bước đầu tiên bắt buộc cho các external data source dùng storage với key-based auth (không dùng workload identity hoặc MSI).

📋 Giải thích tất cả các phương án (đúng/sai)

• ❌ [SAI] a database role
  🧩 Phân tích sai: Database role chỉ dùng để quản lý quyền truy cập (authorization) bên trong database, như cấp quyền SELECT trên external table. Không liên quan đến xác thực (authentication) với storage account. Tạo role sau khi external table đã tồn tại, không phải "first" step.

• ✅ [ĐÚNG] a database scoped credential
  🛠️ Phân tích đúng: Như giải thích trên, đây là bước first và bắt buộc để external data source có thể dùng account key truy cập CSV file. Credential lưu trữ secret an toàn, hỗ trợ external data source syntax: CREATE EXTERNAL DATA SOURCE ds_name WITH (TYPE = HADOOP, LOCATION = 'abfss://...@storage1.dfs.core.windows.net/', CREDENTIAL = credential_name);.

• ❌ [SAI] a database view
  🧩 Phân tích sai: Database view là virtual table dựa trên query, dùng để trừu tượng hóa dữ liệu sau khi external table đã được tạo. Không liên quan đến việc thiết lập external data source hay xác thực storage.

• ❌ [SAI] an external file format
  🧩 Phân tích sai: External file format định nghĩa cấu trúc file (như CSV: field delimiter, encoding). Nó được tạo sau data source, và dùng trong external table: CREATE EXTERNAL TABLE ... WITH (LOCATION = '...', DATA_SOURCE = ds_name, FILE_FORMAT = ff_name);. Không phải bước đầu tiên.

📘 Tài liệu tham khảo (cập nhật mới nhất Azure 2026)

• CREATE DATABASE SCOPED CREDENTIAL - Azure Synapse Analytics ✅ Bước 1 chính thức.
• CREATE EXTERNAL DATA SOURCE - Azure Synapse 🛠️ Yêu cầu credential.
• PolyBase external tables in Synapse SQL 📋 Hướng dẫn full workflow.
• Lưu ý: Từ 2024-2026, Azure ưu tiên managed identity thay key, nhưng câu hỏi chỉ định "account key", nên credential vẫn áp dụng.

Hy vọng phân tích này giúp bạn nắm vững quy trình Azure Synapse! 🚀 Nếu cần ví dụ code T-SQL, hãy hỏi thêm.

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi mô tả một tình huống thực tế trong Azure Data Factory (ADF) khi thực hiện hoạt động Copy activity để sao chép nhiều file từ thư mục Folder1 sang Folder2 trong tài khoản Azure Data Lake Storage Gen2.

• Vấn đề chính: Quá trình copy thất bại với lỗi cụ thể trên phía Sink (đích đến):
  ErrorCode=DelimitedTextMoreColumnsThanDefined.
  Lỗi xảy ra khi ADF cố gắng xử lý file nguồn có tên '0_2020_11_09_11_43_32.avro' (định dạng Avro) như một nguồn 'Csv/Tsv Format Text' (văn bản phân cách bằng dấu phẩy/tab). Tại dòng 53 của file, số lượng cột thực tế nhiều hơn số cột mong đợi (27 cột).

• Nguyên nhân gốc rễ 📉: ADF đang cấu hình source dataset sai định dạng – treat file Avro (binary/serialized) như Delimited Text (CSV/TSV). Avro không phải text delimited, nên khi parse, nó không khớp schema (số cột), dẫn đến lỗi ngay từ việc đọc source, dù báo lỗi ở sink.

• Mục tiêu: Tìm cách resolve lỗi để copy file thành công mà không cần parse nội dung (vì chỉ copy file nguyên vẹn).

📘 Tài liệu tham khảo:

• Azure Data Factory Copy activity troubleshooting (cập nhật 2024).
• ADF Supported file formats - Binary copy (hỗ trợ Binary Copy cho Avro mà không schema parsing, phiên bản mới nhất 2026 vẫn giữ nguyên).
• DelimitedText error codes (lỗi MoreColumnsThanDefined do mismatch cột).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Change the Copy activity setting to Binary Copy.

🛠️ Lý do chi tiết:

• Binary Copy trong ADF cho phép sao chép file nguyên vẹn dưới dạng binary mà không parse schema hoặc kiểm tra định dạng text/delimited (như CSV/TSV).
• File nguồn là .avro (Avro format – binary), nên parse như DelimitedText sẽ thất bại vì Avro không có cấu trúc cột text rõ ràng. Chuyển sang Binary Copy sẽ bỏ qua việc đọc nội dung, chỉ copy byte-for-byte từ Folder1 sang Folder2.
• Đây là giải pháp tối ưu và trực tiếp cho lỗi parse format mismatch, hỗ trợ multi-file copy hiệu quả. Không ảnh hưởng performance và resolve ngay lập tức.
  ✅ Kết quả mong đợi: Copy thành công tất cả file mà không lỗi DelimitedText.

🔍 Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích từng phương án một cách chi tiết, giữ nguyên văn bản gốc tiếng Anh:

• ✅ [ĐÚNG] Change the Copy activity setting to Binary Copy.
  🟢 Phương án hoàn toàn đúng vì Binary Copy bỏ qua schema validation và format parsing, lý tưởng cho file Avro/binary. Giải quyết gốc rễ lỗi "more columns than expected" do misparse. Được khuyến nghị chính thức trong docs ADF cho trường hợp copy raw files (2024-2026).

• ❌ [SAI] Lower the degree of copy parallelism.
  🔴 Phương án sai vì độ song song (parallelism) chỉ ảnh hưởng đến performance và phân bổ tài nguyên (như số thread copy đồng thời), không liên quan đến lỗi parse format (DelimitedTextMoreColumns). Giảm parallelism có thể chậm hơn nhưng vẫn lỗi ở row 53.

• ❌ [SAI] Add an explicit mapping.
  🔴 Phương án sai vì explicit mapping chỉ định schema column-by-column cho dữ liệu có cấu trúc, nhưng file Avro đang bị treat sai format từ source. Mapping không fix được lỗi "more columns" ở parse stage (trước mapping apply), và Avro cần reader riêng chứ không phải text mapping.

• ❌ [SAI] Enable fault tolerance to skip incompatible rows.
  🔴 Phương án sai vì fault tolerance (skip incompatible rows) chỉ skip dòng lỗi ở source và tiếp tục, nhưng: (1) Lỗi ở sink side parsing source file; (2) Skip chỉ hữu ích cho dữ liệu partially bad (CSV thực), không fix toàn bộ file Avro misconfigured; (3) Vẫn tạo output incomplete, không resolve gốc rễ. Chỉ dùng cho data skew hoặc minor errors, không phải format mismatch.

💡 Lời khuyên thực hành: Luôn kiểm tra dataset properties (Source format = Binary) trước khi run pipeline. Test với Debug mode trong ADF Studio để verify! 🚀

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào việc triển khai một bộ dữ liệu batch ở định dạng Parquet, được sản xuất bởi Azure Data Factory (ADF) và lưu trữ trong Azure Data Lake Storage Gen2 (ADLS Gen2). Bộ dữ liệu này sẽ được tiêu thụ bởi Azure Synapse Analytics serverless SQL pool.
Mục tiêu chính là giảm thiểu chi phí lưu trữ (minimize storage costs) cho giải pháp.
🛠️ Bối cảnh kỹ thuật: Parquet là định dạng columnar hiệu quả, hỗ trợ nén (compression) tốt. Trong Azure Synapse serverless SQL pool (phiên bản mới nhất 2026), việc tối ưu hóa nén dữ liệu Parquet giúp giảm kích thước file đáng kể, từ đó tiết kiệm chi phí lưu trữ trên ADLS Gen2 (tính phí theo GB lưu trữ). Không chỉ dừng ở performance query, mà ưu tiên storage costs – yếu tố then chốt.

✅ Đáp án đúng: Use Snappy compression for the files

Lý do chọn đáp án này (dựa trên best practices Azure Synapse 2026):

• Parquet hỗ trợ nhiều loại nén như Snappy, GZIP, ZSTD. Snappy là lựa chọn tối ưu nhất cho Synapse serverless SQL pool vì:
  • Giảm kích thước file mạnh mẽ (thường 50-75% so với uncompressed), trực tiếp tiết kiệm storage costs trên ADLS Gen2.
  • Tốc độ nén/giải nén nhanh (low CPU overhead), phù hợp với batch processing từ ADF và query serverless (pay-per-query).
  • Microsoft khuyến nghị chính thức: Snappy là default và best cho Parquet trong Synapse để cân bằng cost/performance.
    🧩 Cách implement: Trong ADF pipeline, thiết lập Parquet dataset với compression = Snappy khi copy/sink dữ liệu vào ADLS Gen2.

📋 Giải thích chi tiết tất cả các phương án

• ✅ Use Snappy compression for the files
  Phương án ĐÚNG vì trực tiếp áp dụng nén Snappy lên file Parquet, giảm kích thước lưu trữ đáng kể (best practice Synapse 2026). Giúp tiết kiệm chi phí ADLS Gen2 mà không ảnh hưởng performance query serverless.

• ❌ Use OPENROWSET to query the Parquet files
  Phương án SAI vì OPENROWSET chỉ là hàm T-SQL để query trực tiếp file Parquet từ serverless SQL pool (không cần external table). Nó tối ưu query performance/cost (pay-per-TB scanned), nhưng không ảnh hưởng đến storage costs – file vẫn giữ nguyên kích thước.

• ❌ Create an external table that contains a subset of columns from the Parquet files
  Phương án SAI vì external table chỉ định nghĩa schema/metadata để query subset columns, giúp giảm data scanned khi query (tiết kiệm compute cost). Tuy nhiên, dữ liệu gốc Parquet vẫn lưu đầy đủ, không giảm storage costs trên ADLS Gen2.

• ❌ Store all data as string in the Parquet files
  Phương án SAI và tệ nhất vì lưu tất cả dữ liệu dưới dạng string làm tăng kích thước file (Parquet columnar tận dụng type-specific encoding như INT/DATE để nén tốt hơn). Điều này tăng storage costs, trái ngược mục tiêu.

📘 Tài liệu tham khảo (cập nhật 2026)

• Azure Synapse Analytics: Best practices for Parquet – Khuyến nghị Snappy cho storage optimization.
• ADLS Gen2 Pricing – Storage costs theo GB, nén giảm bill trực tiếp.
• ADF Parquet Compression – Hỗ trợ Snappy trong sink activity.
  🛠️ Lưu ý: Áp dụng Synapse runtime mới nhất (2026) với hỗ trợ ZSTD nâng cao, nhưng Snappy vẫn là lựa chọn hàng đầu cho batch Parquet.