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

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

Câu hỏi tập trung vào Azure Data Factory (ADF), một dịch vụ ETL (Extract, Transform, Load) trên Microsoft Azure để quản lý pipeline dữ liệu. Cụ thể:

• Bạn có một pipeline tên pipeline1.
• Yêu cầu: Chạy pipeline này lúc 2 AM hàng ngày (mỗi ngày một lần vào giờ cố định).
• Điều kiện quan trọng: Nếu trigger (kích hoạt) bị dừng (pause/stop), sau khi khởi động lại (restart), lần thực thi tiếp theo vẫn phải diễn ra đúng 2 AM ngày hôm sau, không bị lệch lịch hoặc phụ thuộc vào thời gian dừng.

Mục tiêu là chọn loại trigger phù hợp để đảm bảo lịch chạy cố định, độc lập với trạng thái trước đó. Đây là tính năng cốt lõi của ADF triggers, giúp pipeline chạy theo lịch đáng tin cậy mà không bị "nhảy cóc" khi gặp sự cố tạm thời. 📅

✅ Đáp án đúng: schedule

• Lý do lựa chọn:
  • Schedule trigger là loại trigger chạy theo lịch cố định (dựa trên cron expression hoặc interval), ví dụ: chạy lúc 2:00 AM hàng ngày.
  • Khi trigger bị dừng và khởi động lại, nó không quan tâm đến lịch sử thực thi trước đó, mà chỉ tính lịch từ thời điểm hiện tại trở đi. Do đó, lần chạy tiếp theo vẫn đúng 2 AM ngày hôm sau, bất kể dừng bao lâu.
  • Điều này khớp hoàn hảo với yêu cầu: "next pipeline execution will occur at 2 AM, following a restart".
  • Trong ADF (phiên bản mới nhất 2024-2026), schedule trigger hỗ trợ cấu hình linh hoạt như @hourly(), @daily(02:00) mà không có dependency phức tạp. 🛠️

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên hành vi của trigger trong ADF:

• ✅ schedule
  Đúng vì như giải thích trên: Chạy theo lịch cố định, restart không ảnh hưởng lịch tiếp theo. Hoàn hảo cho yêu cầu hàng ngày lúc 2 AM. 📘

• ❌ tumbling
  Sai vì Tumbling window trigger chạy theo cửa sổ thời gian liên tục (windowed, ví dụ mỗi giờ), hỗ trợ backfill (bù đắp dữ liệu miss) và dependency giữa các window. Nếu dừng, khi restart nó sẽ tiếp tục từ window bị miss hoặc theo trạng thái trước, có thể dẫn đến chạy lệch 2 AM (ví dụ: chạy ngay hoặc bù window cũ). Không đảm bảo "luôn 2 AM sau restart". 🕒

• ❌ storage event
  Sai vì Storage event trigger kích hoạt dựa trên sự kiện (event-based) như khi file mới upload vào Azure Blob Storage (qua Event Grid). Không phải lịch cố định, mà phụ thuộc vào sự kiện thực tế, nên không thể đảm bảo chạy đúng 2 AM hàng ngày. Hoàn toàn không liên quan đến lịch thời gian. ☁️

• ❌ custom event
  Sai vì Custom event trigger cũng là event-based, kích hoạt qua Event Grid custom topic (ví dụ: sự kiện tùy chỉnh từ ứng dụng khác). Không hỗ trợ lịch cố định, chỉ chạy khi có event cụ thể, nên không đáp ứng yêu cầu chạy hàng ngày lúc 2 AM. ⚡

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

• Azure Data Factory Triggers Documentation: Triggers in Azure Data Factory (Microsoft Docs, cập nhật 2024).
• So sánh Schedule vs Tumbling: Create a schedule trigger và Tumbling window trigger.
• Thực hành: Sử dụng ADF Studio để test trigger pause/resume – hành vi schedule luôn giữ lịch độc lập.

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

🧩 Giải thích nội dung câu hỏi
Câu hỏi tập trung vào việc lập lịch thực thi một pipeline trong Azure Data Factory (ADF) sao cho pipeline tự động chạy khi có file mới được tải lên (arrives) vào một container trong Azure Data Lake Storage Gen2 (ADLS Gen2).

• Azure Data Factory (ADF) là dịch vụ ETL/ELT trên cloud của Microsoft, hỗ trợ các trigger để kích hoạt pipeline một cách tự động.
• Azure Data Lake Storage Gen2 (ADLS Gen2) là dịch vụ lưu trữ dữ liệu lớn, hỗ trợ hierarchical namespace và tích hợp sâu với ADF qua các sự kiện (events).
• Yêu cầu chính là trigger phải phát hiện sự kiện file mới (thường là sự kiện "Blob Created" từ Azure Blob Storage Event Grid), không phải dựa trên thời gian cố định.
  (Kiến thức cập nhật đến 2026: ADF hỗ trợ Storage Event Trigger với Event Grid v2, cải tiến độ tin cậy và hỗ trợ ADLS Gen2 đầy đủ - theo docs.microsoft.com/azure/data-factory)

✅ Đáp án đúng: storage event
Lý do lựa chọn: Storage Event Trigger là loại trigger lý tưởng để kích hoạt pipeline dựa trên sự kiện thời gian thực từ ADLS Gen2 (qua Azure Event Grid). Khi file mới được tạo (upload), Event Grid sẽ gửi sự kiện "Microsoft.Storage.BlobCreated", và trigger sẽ tự động chạy pipeline. Điều này đảm bảo xử lý dữ liệu ngay lập tức, không delay theo lịch, phù hợp với kịch bản "when a new file arrives". Hỗ trợ container cụ thể, path filter, và tích hợp native với ADLS Gen2.
📘 Tài liệu tham khảo: Tạo Storage Event Trigger trong ADF (Microsoft Docs, cập nhật 2025).

🛠️ Phân tích tất cả các phương án (Giữ nguyên văn bản gốc):

• on-demand ❌ Sai vì: Đây là chế độ chạy pipeline thủ công theo yêu cầu người dùng, không tự động phát hiện file mới. Không phù hợp với yêu cầu "schedule... when a new file arrives" vì thiếu cơ chế lắng nghe sự kiện. Chỉ dùng cho test/debug.
• tumbling window ❌ Sai vì: Trigger này dựa trên cửa sổ thời gian cố định (fixed intervals, ví dụ mỗi 5 phút), xử lý dữ liệu theo batch theo thời gian (hỗ trợ backfill/watermark). Không phản ứng với sự kiện file cụ thể, có thể miss file hoặc delay xử lý.
• schedule ❌ Sai vì: Trigger chạy theo lịch trình thời gian định kỳ (cron-like, ví dụ hàng giờ), không liên kết với sự kiện file mới. Sẽ kiểm tra file theo lịch, dẫn đến xử lý muộn hoặc dư thừa nếu file đến ngoài lịch.
• storage event ✅ Đúng như đã giải thích ở trên – Phù hợp hoàn hảo cho event-driven architecture với ADLS Gen2.

🧩 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 quản lý hiệu suất (performance) của một enterprise data warehouse trong Azure Synapse Analytics (cụ thể là Dedicated SQL Pool, trước đây gọi là SQL Data Warehouse).

• Tình huống vấn đề: Người dùng gặp tình trạng query thường được sử dụng (commonly used queries) chạy chậm, nhưng query ít sử dụng (infrequently used queries) không có thay đổi về hiệu suất. Điều này gợi ý vấn đề không nằm ở tài nguyên tổng thể (như compute hoặc IO chung), mà liên quan đến cơ chế cache – nơi dữ liệu "nóng" (hot data từ query thường dùng) nên được lưu trữ tạm thời để truy xuất nhanh, thay vì đọc từ storage chậm chạp mỗi lần.

• Yêu cầu: Giám sát resource utilization metrics để xác định nguyên nhân. Azure Synapse cung cấp các metric qua Azure Monitor, giúp theo dõi CPU, IO, cache, tempdb, v.v. Vấn đề chỉ ảnh hưởng query thường dùng → cần metric liên quan đến cache efficiency cho dữ liệu truy cập lặp lại.

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

• Azure Synapse Analytics Monitoring Metrics (cập nhật 2024-2026).
• Synapse Dedicated SQL Pool Performance Tuning – Nhấn mạnh Cache Hit % cho hot queries.

✅ Đáp án đúng: Cache hit percentage

Lý do lựa chọn:

• Cache hit percentage đo lường tỷ lệ dữ liệu được lấy từ ResultSet Cache (bộ đệm kết quả query trong Synapse) thay vì đọc từ storage (Columnstore index).
• Với query thường dùng, nếu cache hit thấp (ví dụ <80-90%), query phải thực hiện full scan từ disk → gây chậm đáng kể. Query ít dùng không bị ảnh hưởng vì chúng ít cache và không lặp lại.
• 🛠️ Giải pháp thực tế: Giám sát metric này qua Azure Monitor hoặc Query Store. Nếu thấp, áp dụng Automatic Statistics, Materialized Views, hoặc scale-up DWU để tăng cache size. Phiên bản mới nhất (2026) vẫn ưu tiên metric này cho workload lặp lại.

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

• ❌ [SAI] DWU limit
  Metric này theo dõi giới hạn Data Warehouse Units (DWU) – mức compute tổng thể đã được provision. Nó không liên quan trực tiếp đến query cụ thể, mà chỉ báo hiệu nếu toàn bộ pool bị throttle (ví dụ 100% DWU sử dụng). Vấn đề chỉ ảnh hưởng query thường dùng, không phải toàn hệ thống → loại trừ.

• ✅ [ĐÚNG] Cache hit percentage
  (Như đã giải thích ở trên) Đây là metric chính xác nhất cho tình huống hot queries chậm do cache miss, giúp pinpoint vấn đề cache không hiệu quả mà không ảnh hưởng query lạnh.

• ❌ [SAI] Local tempdb percentage
  Metric đo phần trăm sử dụng tempdb local (không gian tạm cho sort/hash operations). Nó hữu ích cho query phức tạp với spill-to-disk, nhưng không giải thích tại sao chỉ query thường dùng chậm (tempdb thường ảnh hưởng query lớn bất kể tần suất) → không phù hợp.

• ❌ [SAI] Data IO percentage
  Metric theo dõi tỷ lệ IO dữ liệu từ storage (Active Queries IO %). Nó chỉ báo hiệu bottleneck IO tổng quát, nhưng query ít dùng không chậm → vấn đề không phải IO chung, mà là cache cụ thể cho query lặp lại.

🧩 Tóm tắt insight: Tập trung Cache hit giúp tối ưu nhanh chóng bằng cách scale cache hoặc refactor workload. Sử dụng Azure Portal > Monitoring > Metrics để visualize! 🚀

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

Câu hỏi này thuộc chủ đề Azure Synapse Analytics Pipelines, tập trung vào việc xây dựng một pipeline để sao chép dữ liệu từ các bảng cụ thể trong Azure SQL Database (DB1) sang các file trong Azure Storage Account (storage1).

• Tình huống: File File1.txt trong storage1 chứa danh sách tên các bảng được chọn từ DB1 (ví dụ: "TableA", "TableB",...).
• Yêu cầu chính:
  • Sử dụng Copy activity trong pipeline, được parameterized (tham số hóa) để lấy dữ liệu từ File1.txt làm nguồn xác định source (bảng nguồn) và destination (file đích).
  • Các hoạt động sao chép phải chạy song song (parallel) càng nhiều càng tốt để tối ưu hiệu suất.
• Câu hỏi yêu cầu chọn 2 pipeline activities cần thêm vào pipeline để đạt yêu cầu (multi-select, mỗi lựa chọn đúng 1 điểm).
• Phiên bản cập nhật: Dựa trên tài liệu Azure Synapse Analytics mới nhất (tính đến 2026), Copy activity hỗ trợ parameterization động qua expressions/expressions từ các activity trước, và ForEach hỗ trợ parallel execution với tùy chọn "Is Sequential: false" (mặc định parallel cho batches nhỏ).

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

• Azure Synapse Pipelines - Lookup Activity
• Azure Synapse Pipelines - ForEach Activity
• Copy Activity Parameterization

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

Hai activities đúng là Lookup và ForEach.

🛠️ Lý do:

• Lookup: Đọc nội dung file File1.txt (danh sách tên bảng) dưới dạng JSON/array, trả về output dạng mảng để parameterize cho Copy activity (source table name và destination file name).
• ForEach: Lặp qua từng tên bảng từ output của Lookup, thực thi Copy activity bên trong với tham số động (ví dụ: @item().tableName). Bật parallel execution (Sequential: false) để các copy chạy song song, đáp ứng yêu cầu "parallel as often as possible".
• Luồng pipeline điển hình: Lookup → ForEach (chứa Copy activity parameterized).

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh:

• ❌ Get Metadata
  Phương án này SAI vì Get Metadata chỉ lấy metadata (như kích thước file, số lượng dòng, thời gian sửa đổi) của dataset/file, không đọc nội dung (danh sách tên bảng) từ File1.txt. Không dùng để parameterize source/destination cho Copy activity. (Thay vào đó, dùng cho validation hoặc dynamic dataset schema).

• ✅ Lookup
  Phương án này ĐÚNG vì Lookup đọc toàn bộ nội dung file File1.txt (text/JSON), trả về output dạng array/object có thể dùng trực tiếp trong expressions của Copy activity (ví dụ: @activity('Lookup').output.value). Hoàn hảo để lấy danh sách bảng động và parameterize source table.

• ✅ ForEach
  Phương án này ĐÚNG vì ForEach lặp qua mảng output từ Lookup (từng tên bảng), chứa Copy activity bên trong với tham số động (@item()). Hỗ trợ parallel execution (tùy chọn "Sequential: Off" và "Batch Count" để chia batches chạy song song), đảm bảo copy nhiều bảng cùng lúc.

• ❌ If Condition
  Phương án này SAI vì If Condition chỉ kiểm tra điều kiện logic (if/else) dựa trên output trước, không hỗ trợ lặp hoặc parallel copy. Không liên quan đến việc đọc file danh sách hoặc parameterize multiple copies. (Dùng cho branching logic, không phải iteration).

🧩 Tóm tắt luồng khuyến nghị: Lookup (đọc File1.txt) → ForEach (parallel Copy cho từng bảng). Điều này tận dụng tối đa tính năng Synapse 2026 với dynamic schema và parallel processing! 🚀

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

Câu hỏi tập trung vào Azure Synapse Analytics, một dịch vụ phân tích dữ liệu tích hợp của Microsoft Azure. Cụ thể:

• Bạn có một workspace Azure Synapse chứa Apache Spark pool tên là SparkPool1.
• Trong SparkPool1, có một Delta Lake table tên là SparkTable1 (Delta Lake là định dạng lưu trữ mở, hỗ trợ ACID transactions, được sử dụng phổ biến trong Spark để quản lý dữ liệu lớn).
• Yêu cầu: Đề xuất giải pháp cho phép chạy Transact-SQL (T-SQL) queries trực tiếp trên dữ liệu của SparkTable1, đồng thời hỗ trợ partition elimination (tối ưu hóa truy vấn bằng cách chỉ scan các partition liên quan, giảm thời gian và chi phí xử lý).

Mục tiêu là kết nối dữ liệu từ Spark (Delta Lake) sang SQL engine mà không cần di chuyển dữ liệu vật lý, tận dụng tính năng partition để query hiệu quả. 📘 Lưu ý: Serverless SQL pool trong Synapse hỗ trợ query trực tiếp trên Delta Lake qua external tables/views, trong khi Dedicated SQL pool yêu cầu dữ liệu native (như Parquet hoặc copy data).

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

Đáp án đúng: a partitioned view in a serverless SQL pool
🛠️ Lý do:

• Serverless SQL pool trong Azure Synapse cho phép tạo external table hoặc view trên Delta Lake tables từ Spark pool mà không cần copy dữ liệu (query-on-storage).
• Khi Delta table được partitioned (ví dụ: theo ngày/tháng), bạn có thể tạo partitioned view để T-SQL queries tận dụng partition elimination tự động (chỉ đọc partition cần thiết, cải thiện performance lên đến hàng chục lần).
• Tính năng này được hỗ trợ đầy đủ từ phiên bản Synapse 2023+, cập nhật đến 2026 với cải tiến Delta Lake integration (hỗ trợ schema evolution và time travel). Dedicated pools không hỗ trợ trực tiếp Delta mà không qua ETL.
  ✅ Kết quả: Giải pháp này đáp ứng 100% yêu cầu: T-SQL queries + partition elimination trên dữ liệu gốc.

📋 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 bằng 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 Synapse mới nhất (2026).

• ❌ [SAI] a partitioned table in a dedicated SQL pool
  Lý do sai: Dedicated SQL pool (trước đây gọi Synapse Dedicated) chỉ hỗ trợ dữ liệu native như heap/clustered columnstore tables, không query trực tiếp Delta Lake từ Spark. Bạn phải dùng CETAS (CREATE EXTERNAL TABLE AS SELECT) hoặc PolyBase để export dữ liệu sang Dedicated, mất thời gian và không giữ nguyên partition gốc từ Delta. Không hỗ trợ partition elimination tự động trên Delta.

• ❌ [SAI] a partitioned view in a dedicated SQL pool
  Lý do sai: Tương tự trên, Dedicated SQL pool không thể reference trực tiếp Delta Lake table qua view. View chỉ hoạt động trên dữ liệu nội bộ (internal tables). Nếu cố gắng, bạn cần ETL dữ liệu trước, dẫn đến duplicate storage và mất tính partition elimination từ Delta gốc.

• ❌ [SAI] a partitioned index in a dedicated SQL pool
  Lý do sai: Partitioned index (như clustered columnstore index partitioned) chỉ áp dụng cho internal tables trong Dedicated SQL pool. Không thể index trực tiếp trên external Delta table từ Spark. Index này yêu cầu dữ liệu đã load vào Dedicated, không hỗ trợ query-on-storage và partition elimination từ Delta.

• ✅ [ĐÚNG] a partitioned view in a serverless SQL pool
  Lý do đúng: Serverless SQL pool hỗ trợ external tables/views trên Delta Lake (ABFSS path từ Spark pool). Tạo partitioned view (sử dụng CREATE VIEW với partition function) để T-SQL queries tự động eliminate partitions dựa trên WHERE clause (ví dụ: WHERE date = '2024-01-01' chỉ scan partition date). Hiệu quả cao, serverless scale theo query. ✅ Hoàn hảo cho use case!

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

• Azure Synapse Analytics - Query Delta Lake tables using serverless SQL pool (hỗ trợ partition pruning từ 2023+).
• Partition elimination in Synapse Serverless (xác nhận T-SQL partition elimination trên Delta).
• Delta Lake integration in Synapse Spark & SQL (cross-engine querying).
• AWS không liên quan trực tiếp (có thể nhầm với chủ đề), nhưng tương đương là Amazon Athena với Delta trên S3 hỗ trợ partition pruning.

🧠 Kết luận: Giải pháp khuyến nghị ưu tiên serverless để tiết kiệm chi phí và linh hoạt! Nếu cần code mẫu, hãy hỏi thêm. 🚀

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

Câu hỏi tập trung vào tích hợp giữa Azure Data Factory (ADF) và Microsoft Purview 📘. Cụ thể:

• Bạn có một ADF đã kết nối với tài khoản Microsoft Purview, và ADF này đã được đăng ký (registered) trong Purview.
• Sau khi cập nhật một pipeline trong ADF, bạn cần đảm bảo rằng lineage mới (dòng dõi dữ liệu) được cập nhật và hiển thị trong Purview.
• Lineage ở đây đề cập đến thông tin theo dõi luồng dữ liệu từ nguồn đến đích, giúp Purview vẽ sơ đồ dữ liệu tự động dựa trên metadata runtime 🛤️.
• Yêu cầu chính: Hành động đầu tiên (first) cần làm để lineage cập nhật có sẵn trong Purview.

Dựa trên kiến thức cập nhật mới nhất từ Microsoft (phiên bản Azure Data Factory và Purview đến năm 2026), Purview tự động thu thập lineage từ ADF qua scan runtime khi pipeline được thực thi. Không có thay đổi lớn trong cơ chế này từ các bản cập nhật gần đây (Purview Unified Catalog 2024-2025).

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

Đáp án đúng: Execute the pipeline.
🧠 Lý do: Khi bạn cập nhật pipeline trong ADF, Purview chỉ thu thập và cập nhật lineage sau khi pipeline được thực thi (execute) tại runtime. Việc chạy pipeline kích hoạt ADF-Purview integration scanner, quét metadata hoạt động thực tế (như source, sink, transformation) và đẩy lineage mới lên Purview. Đây là bước đầu tiên và bắt buộc để lineage được refresh. Không chạy pipeline thì Purview không có dữ liệu mới để cập nhật!
(Nguồn: Microsoft Docs - Integrate Azure Data Factory with Microsoft Purview - Cập nhật 2025).

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên quy trình tích hợp ADF-Purview 🛠️:

• Disconnect the Microsoft Purview account from the data factory.
  ❌ Sai: Việc ngắt kết nối Purview khỏi ADF sẽ làm mất hoàn toàn tích hợp, dừng mọi scan lineage hiện tại và tương lai. Điều này trái ngược với mục tiêu cập nhật lineage mới. Thay vào đó, kết nối phải được duy trì để Purview tiếp tục nhận dữ liệu.

• Execute the pipeline.
  ✅ Đúng: Như đã giải thích ở trên, đây là bước đầu tiên cần thiết. Pipeline chạy sẽ trigger Purview scanner, thu thập lineage runtime và cập nhật ngay lập tức trong Purview portal (thường trong vài phút). Không có bước nào trước đó bắt buộc hơn!

• Execute an Azure DevOps build pipeline.
  ❌ Sai: Azure DevOps dùng cho CI/CD pipeline deployment (build và release ADF artifacts), không liên quan trực tiếp đến việc cập nhật lineage runtime trong Purview. Build chỉ deploy code, không kích hoạt execution để scan dữ liệu thực tế.

• Locate the related asset in the Microsoft Purview portal.
  ❌ Sai: Việc tìm kiếm asset trong Purview portal chỉ giúp xem lineage hiện tại, không trigger bất kỳ cập nhật nào. Lineage cũ vẫn hiển thị nếu chưa chạy pipeline mới. Đây là bước sau khi execute, không phải first step.

📚 Tài liệu tham khảo thêm

• Azure Data Factory - Microsoft Purview integration overview (Cập nhật 2026 preview).
• Purview Lineage for ADF - Chi tiết về runtime scanning.
• Video demo: Microsoft Build 2025 - ADF & Purview Lineage.

Hy vọng phân tích này giúp bạn nắm vững! Nếu cần demo thực tế trên Azure portal, hãy cho tôi biết nhé 🚀.

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

Câu hỏi tập trung vào việc thiết kế bảng sales transactions trong Azure Synapse Analytics dedicated SQL pool (trước đây gọi là Azure SQL Data Warehouse). Bảng này dự kiến chứa khoảng 60 triệu rows mỗi tháng, được partition theo tháng (tức mỗi partition đại diện cho một tháng dữ liệu). Bảng sử dụng clustered columnstore index (CCI) để tối ưu hóa nén và hiệu suất query, kết hợp với round-robin distribution để phân phối dữ liệu đều qua các distributions (đơn vị phân tán dữ liệu song song trong Synapse).

📌 Câu hỏi cốt lõi: Ước lượng số rows cho mỗi sự kết hợp giữa distribution và partition (tức rows trong một distribution cụ thể của một partition cụ thể).

• Partition theo tháng → Mỗi partition chứa ~60 triệu rows (dữ liệu 1 tháng).
• Round-robin distribution → Dữ liệu được phân bổ ngẫu nhiên và đều qua 60 distributions (số lượng tiêu chuẩn cho hầu hết dedicated SQL pools từ DW300c trở lên, theo tài liệu Azure Synapse cập nhật đến 2026).
• Do đó, cần tính 60M rows / 60 distributions = 1M rows mỗi distribution-partition combo.
  🛠️ Lý do quan trọng: Clustered columnstore index hoạt động tối ưu khi mỗi rowgroup chứa khoảng 1 triệu rows, giúp nén dữ liệu hiệu quả (compression ratio cao) và query nhanh hơn.

✅ Đáp án đúng: "1 million"

Lý do chọn:
Với 60 triệu rows/tháng và partition theo tháng, mỗi partition chứa 60M rows. Dedicated SQL pool sử dụng round-robin distribution phân bổ đều qua 60 distributions (tiêu chuẩn Gen2 pools). Vậy, số rows mỗi distribution-partition là 60M / 60 = 1 triệu rows.
✅ Điều này khớp với best practice của Microsoft: rowgroup size lý tưởng ~1M rows cho CCI để tối ưu hiệu suất (theo tài liệu Azure Synapse 2026).

📘 Nguồn tham khảo:

• Azure Synapse Analytics - Distributions (xác nhận 60 distributions cho hầu hết pools).
• Design guidance for dedicated SQL pool (rowgroup ~1M rows).
• Cập nhật 2026: Không thay đổi số distributions cơ bản cho Gen2 pools.

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

• "1 million" ✅ Đúng: Như phân tích trên, 60M rows/partition chia đều cho 60 distributions → chính xác 1M rows/combo. Phù hợp với kiến trúc Synapse và CCI optimization.

• "5 million" ❌ Sai: Có thể nhầm lẫn với số distributions thấp hơn (ví dụ 12 distributions → 60M/12=5M), nhưng Synapse tiêu chuẩn dùng 60 distributions (không phải 12). Không khớp tài liệu.

• "20 million" ❌ Sai: Giả sử chỉ 3 distributions (60M/3=20M), nhưng không có cấu hình nào như vậy trong Synapse dedicated SQL pools. Quá lớn so với rowgroup lý tưởng của CCI.

• "60 million" ❌ Sai: Đây là tổng rows của toàn bộ partition (1 tháng), bỏ qua việc phân phối qua 60 distributions. Không tính đến cơ chế distribution.

🧩 Tóm tắt: Câu hỏi kiểm tra hiểu biết về distribution strategy và partitioning trong Synapse, nhấn mạnh quy tắc 60 distributions cho round-robin để đạt hiệu suất cao nhất!

🧩 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 workspace, cụ thể là việc triển khai một lake database (cơ sở dữ liệu hồ dữ liệu) bằng cách sử dụng database template (mẫu cơ sở dữ liệu) trong Azure Synapse.

• Lake database là một tính năng mới trong Azure Synapse (từ năm 2023 trở đi, cập nhật đến 2026 vẫn giữ nguyên), cho phép định nghĩa schema cho dữ liệu trong Azure Data Lake Storage Gen2 một cách declarative (khai báo), hỗ trợ truy vấn bằng T-SQL mà không cần di chuyển dữ liệu.
• Database template là các mẫu sẵn có (như AdventureWorks hoặc mẫu tùy chỉnh) giúp triển khai nhanh lake database, bao gồm các yếu tố cốt lõi để định nghĩa cấu trúc dữ liệu.
• Câu hỏi yêu cầu chọn hai yếu tố (each correct answer presents part of the solution) được bao gồm trong template, mỗi lựa chọn đúng đáng 1 điểm. Đây là dạng multiple-choice với multiple correct answers (chọn nhiều đáp án đúng).

Mục tiêu là hiểu những gì template tự động tạo ra khi deploy lake database, dựa trên tài liệu chính thức Microsoft (cập nhật mới nhất 2024-2026).

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

• Microsoft Docs: Create a lakehouse database from a template
• Azure Synapse Lake Database Overview (xác nhận elements trong template).

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

Hai đáp án đúng là relationships và table definitions.

🛠️ Lý do:

• Khi deploy lake database từ template, Azure Synapse tự động tạo các table definitions (định nghĩa bảng: schema, columns, data types) và relationships (mối quan hệ giữa các bảng, như foreign keys) để đảm bảo tính toàn vẹn dữ liệu và hỗ trợ truy vấn JOIN hiệu quả.
• Đây là các yếu tố cốt lõi của lake database schema, giúp template trở thành "blueprint" hoàn chỉnh cho dữ liệu có cấu trúc. Không cần cấu hình thủ công, phù hợp với mục tiêu triển khai nhanh.

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết:

• ✅ relationships
  Đúng. Template bao gồm các mối quan hệ giữa các bảng (như primary key - foreign key), giúp lake database hỗ trợ referential integrity và truy vấn phức tạp. Điều này được tự động deploy từ mẫu, theo docs Microsoft.

• ❌ data formats
  Sai. Data formats (định dạng dữ liệu như Parquet, Delta, CSV) không được include trong template. Chúng được quản lý riêng qua external tables hoặc file properties trong Data Lake, không phải phần của schema template.

• ❌ linked services
  Sai. Linked services là khái niệm của Azure Synapse Pipelines/Integration Runtime để kết nối nguồn dữ liệu bên ngoài (như ADLS, SQL DB). Template lake database không tạo linked services; chúng phải config riêng trong workspace.

• ❌ table permissions
  Sai. Table permissions (quyền truy cập bảng) thuộc về Azure RBAC hoặc SQL roles, được thiết lập sau khi deploy qua Synapse Studio hoặc SQL commands. Template chỉ tập trung vào schema, không include security permissions.

Hy vọng phân tích này giúp bạn nắm vững! Nếu cần demo thực tế trên Azure Synapse, hãy cho tôi biết nhé 🚀.

🧩 Giải thích nội dung câu hỏi

Câu hỏi yêu cầu triển khai một star schema trong Azure Synapse Analytics dedicated SQL pool, cụ thể là tạo bảng DimProduct làm Type 3 Slowly Changing Dimension (SCD).

• Star schema là mô hình dữ liệu kho dữ liệu phổ biến với bảng fact ở trung tâm và các bảng dimension xung quanh. Bảng dimension như DimProduct lưu trữ thông tin mô tả (ví dụ: sản phẩm).
• Type 3 SCD là loại xử lý thay đổi chậm trong dimension:
  • Giữ nguyên các khóa chính (ProductKey, ProductSourceID).
  • Lưu giá trị hiện tại (ProductName, ProductDescription, Color) và giá trị trước đó (original/previous) trong cùng một hàng, bằng cách thêm các cột riêng biệt cho giá trị cũ. Không tạo hàng mới như Type 2.
• Bảng đã định nghĩa sẵn với phân phối REPLICATE (phù hợp cho dimension nhỏ) và CLUSTERED COLUMNSTORE INDEX (tối ưu nén và query).
• Nhiệm vụ: Thêm 3 cột để hỗ trợ Type 3 SCD, đáp án là câu hỏi multiple correct answers (mỗi lựa chọn đúng 1 điểm).

Dựa trên tài liệu Microsoft Azure Synapse Analytics (cập nhật 2024-2026), Type 3 SCD thường dùng cột "Original" hoặc "Previous" để lưu giá trị lịch sử bên cạnh cột hiện tại. 📘 Nguồn tham khảo: Microsoft Docs - Slowly changing dimensions, Azure Synapse SCD Implementation Guide.

✅ Đáp án đúng (3 lựa chọn)

Các cột cần thêm là:
• [OriginalProductDescription] NVARCHAR(2000) NOT NULL
• [OriginalColor] NVARCHAR(50) NOT NULL
• [OriginalProductName] NVARCHAR(100) NULL

Lý do lựa chọn: Trong Type 3 SCD, cần thêm cột lưu giá trị gốc/ban đầu (Original) cho các trường có thể thay đổi (ProductName, ProductDescription, Color), song song với cột hiện tại. Điều này cho phép theo dõi 1 cấp lịch sử (giá trị cũ và mới) trong cùng hàng. Kiểu dữ liệu khớp chính xác (NVARCHAR với độ dài tương ứng), và OriginalProductName cho phép NULL vì giá trị gốc có thể chưa tồn tại ở lần đầu insert. 🛠️ Hoàn thiện table như vậy hỗ trợ query so sánh thay đổi dễ dàng mà không cần join phức tạp.

📋 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 bằng tiếng Anh:

• ❌ [SAI] [EffectiveStartDate] [datetime] NOT NULL
  Phương án này không đúng vì EffectiveStartDate dùng cho Type 2 SCD (thêm hàng mới với khoảng thời gian hiệu lực). Type 3 không cần theo dõi ngày bắt đầu/kết thúc, mà chỉ lưu giá trị hiện tại + trước đó trong cùng hàng. Thêm cột này sẽ làm table dư thừa và không phù hợp yêu cầu.

• ❌ [SAI] [EffectiveEndDate] [datetime] NOT NULL
  Phương án này không đúng tương tự, EffectiveEndDate cũng dành cho Type 2 SCD để đánh dấu kết thúc hiệu lực của hàng cũ. Type 3 SCD không sử dụng cơ chế này, tránh tạo nhiều phiên bản hàng. Sử dụng sẽ vi phạm nguyên tắc "in-place" thay đổi của Type 3.

• ✅ [ĐÚNG] [OriginalProductDescription] NVARCHAR(2000) NOT NULL
  Phương án này đúng vì lưu giá trị gốc của ProductDescription (cột có thể thay đổi). Kiểu dữ liệu khớp, NOT NULL đảm bảo tính toàn vẹn. Hoàn hảo cho Type 3 SCD để so sánh mô tả cũ/mới.

• ❌ [SAI] [IsCurrentRow] [bit] NOT NULL
  Phương án này không đúng vì IsCurrentRow dùng cho Type 2 SCD để flag hàng hiện tại (1=active, 0=historical). Type 3 chỉ có một hàng duy nhất per key, không cần flag vì không có nhiều phiên bản. Thêm sẽ không cần thiết và phức tạp hóa.

• ✅ [ĐÚNG] [OriginalColor] NVARCHAR(50) NOT NULL
  Phương án này đúng vì lưu giá trị gốc của Color (cột thay đổi). Kiểu dữ liệu chính xác, hỗ trợ Type 3 bằng cách giữ lịch sử màu sắc cũ bên cạnh giá trị mới.

• ✅ [ĐÚNG] [OriginalProductName] NVARCHAR(100) NULL
  Phương án này đúng vì lưu giá trị gốc của ProductName. Cho phép NULL (phù hợp lần insert đầu tiên chưa có "original"), khớp quy tắc Type 3 SCD linh hoạt. Độ dài NVARCHAR(100) tương ứng cột hiện tại.

Tóm lại, chỉ 3 cột "Original" mới phù hợp, giúp table hỗ trợ Type 3 SCD hiệu quả trong Azure Synapse! 🚀

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

Câu hỏi tập trung vào Azure Synapse Analytics serverless SQL pool (một dịch vụ phân tích dữ liệu không máy chủ của Microsoft Azure). Cụ thể, nó mô tả việc thực thi lệnh CREATE EXTERNAL TABLE ... AS SELECT (hay còn gọi là CTAS cho external table) để tạo một bảng ngoài (external table) tên là Orders.

• Cấu trúc lệnh chính:
  • LOCATION = 'orders/': Chỉ định vị trí lưu trữ dữ liệu trong data lake (thường là Azure Data Lake Storage Gen2).
  • DATA_SOURCE = sales: Tham chiếu đến một external data source đã được định nghĩa trước (chứa đường dẫn đến data lake).
  • FILE_FORMAT = SalesOrders: Sử dụng định dạng file đã định nghĩa (có thể là Parquet, CSV, v.v.).
  • Phần AS SELECT từ OPENROWSET: Đọc dữ liệu từ các file CSV trong thư mục 'sales_orders/*.csv' (sử dụng PARSER_VERSION = '2.0' để parse CSV hiện đại, bỏ qua header row), lọc WHERE OrderType = 'Customer Order', và materialize (ghi vật lý) kết quả vào vị trí LOCATION.

Mục tiêu câu hỏi: Xác định nơi lưu trữ các hàng dữ liệu được trả về từ query (tức là dữ liệu sau khi SELECT và lọc). Đây KHÔNG phải là nơi lưu metadata của external table (luôn ở SQL catalog), mà là nơi dữ liệu thực tế được ghi vật lý sau khi thực thi CTAS.

📘 Lưu ý kiến thức cập nhật (đến 2026): Trong Azure Synapse Analytics (phiên bản mới nhất 2024-2026), serverless SQL pool hỗ trợ CTAS cho external table để ghi dữ liệu vào data lake dưới dạng file phân tán (theo FILE_FORMAT), tối ưu cho query lớn. Không có thay đổi cơ bản so với docs chính thức.

Nguồn tham khảo:

• CREATE EXTERNAL TABLE (Transact-SQL) - Azure Synapse Analytics
• OPENROWSET trong serverless SQL pool

✅ Đáp án đúng: in a file in a data lake

Lý do lựa chọn:

• Lệnh CREATE EXTERNAL TABLE AS SELECT trong serverless SQL pool sẽ materialize dữ liệu từ SELECT (sau khi lọc WHERE) và ghi trực tiếp vào data lake tại thư mục LOCATION = 'orders/' (dựa trên DATA_SOURCE = sales).
• Dữ liệu được lưu dưới dạng file vật lý (ví dụ: Parquet hoặc CSV theo FILE_FORMAT = SalesOrders), phân tán để hỗ trợ query nhanh. External table chỉ lưu metadata (schema) trong SQL catalog, còn dữ liệu thực tế nằm ở data lake.
• 🛠️ Quá trình: OPENROWSET đọc file nguồn → SELECT lọc → CTAS ghi file mới vào data lake. Điều này giúp tạo "managed external table" mà không cần di chuyển dữ liệu vào SQL database.

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

• in a file in a data lake ✅
  Đúng vì như phân tích trên: CTAS ghi dữ liệu vật lý vào data lake tại LOCATION chỉ định. Đây là tính năng cốt lõi của external table trong Synapse serverless để xử lý dữ liệu lớn mà không tốn chi phí lưu trữ SQL.

• in a relational database ❌
  Sai vì serverless SQL pool không lưu dữ liệu vào relational database (như Azure SQL Database hoặc dedicated SQL pool). External table chỉ query dữ liệu từ data lake mà không import vào SQL storage. Nếu dùng dedicated pool hoặc CREATE TABLE thông thường thì mới lưu vào DB.

• in a global temporary table ❌
  Sai vì global temporary table (##temp) chỉ tồn tại tạm thời trong SQL catalog (không phải data lake), và bị xóa khi tất cả session kết thúc. CTAS external table tạo bảng bền vững với dữ liệu vật lý ở data lake, không phải temp.

• in a session temporary table ❌
  Sai vì session temporary table (#temp) chỉ tồn tại trong session hiện tại và xóa khi session đóng. Không liên quan đến CTAS external table, vốn tạo cấu trúc bền vững và ghi dữ liệu vĩnh viễn vào data lake.

🛠️ Tóm tắt lợi ích: Cách này giúp Azure Data Engineer xử lý dữ liệu lakehouse hiệu quả, kết hợp SQL querying với lưu trữ rẻ tiền ở data lake! Nếu cần thực hành, hãy test trên Azure Synapse workspace.