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 việc thiết kế cấu hình cluster trên Azure Databricks để chạy các quy trình địa phương do người dùng định nghĩa (user-defined local processes). Các yêu cầu chính bao gồm:
✅ Giảm thiểu độ trễ truy vấn (Minimize query latency): Cluster cần phản hồi nhanh chóng với workload.
✅ Tối đa hóa số lượng người dùng có thể chạy truy vấn đồng thời (Maximize the number of users): Hỗ trợ nhiều user cùng lúc mà không bị nghẽn.
✅ Giảm chi phí tổng thể (Reduce overall costs) mà không ảnh hưởng đến hai yêu cầu trên.

Azure Databricks cung cấp các loại cluster như Standard (đa năng, phù hợp workload chung) và High Concurrency (tối ưu cho nhiều user đồng thời với Fair Scheduling). Các tính năng bổ sung như Autoscaling (tự động scale node dựa trên tải) và Auto Termination (tự động tắt cluster khi idle) giúp cân bằng performance và chi phí. Phiên bản mới nhất (tính đến 2026) của Azure Databricks nhấn mạnh High Concurrency kết hợp Autoscaling để xử lý multi-tenant workloads hiệu quả nhất.

✅ Đáp án đúng: High Concurrency with Autoscaling

Lý do lựa chọn:

• High Concurrency được thiết kế chuyên biệt cho môi trường multi-user, sử dụng per-user Fair Scheduling để phân bổ tài nguyên công bằng, hỗ trợ tối đa số lượng user chạy truy vấn đồng thời mà không bị tranh chấp (gang scheduling). Điều này trực tiếp đáp ứng yêu cầu "maximize the number of users".
• Autoscaling tự động điều chỉnh số node (từ min đến max) dựa trên workload thực tế, giúp giảm độ trễ truy vấn bằng cách scale up nhanh chóng khi tải tăng, đồng thời giảm chi phí bằng cách scale down khi idle (không cần tắt hẳn cluster).
• Kết hợp này đảm bảo hiệu suất cao, chi phí thấp mà không thỏa hiệp (theo docs Azure Databricks 2024-2026, High Concurrency + Autoscaling là recommended cho shared interactive workloads).

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

• Standard with Auto Termination ❌
  Sai vì: Standard cluster không tối ưu cho multi-user (dễ bị một user chiếm hết tài nguyên do FIFO scheduling), không đáp ứng "maximize users". Auto Termination tiết kiệm chi phí bằng cách tắt cluster idle sau thời gian nhất định, nhưng làm tăng độ trễ khi restart (có thể mất vài phút), vi phạm "minimize latency". Không phù hợp workload liên tục nhiều user.

• High Concurrency with Autoscaling ✅
  Đúng vì: Như giải thích ở trên, đây là cấu hình lý tưởng: High Concurrency xử lý concurrent users tốt nhất, Autoscaling cân bằng latency và chi phí động (scale từ 2-1000 nodes tùy config).

• High Concurrency with Auto Termination ❌
  Sai vì: High Concurrency tốt cho multi-user, nhưng Auto Termination sẽ tắt cluster khi idle, dẫn đến độ trễ cao khi user quay lại (phải khởi động lại từ đầu). Không đáp ứng "minimize latency" cho workload có thể gián đoạn, dù tiết kiệm chi phí.

• Standard with Autoscaling ❌
  Sai vì: Autoscaling giúp latency và chi phí, nhưng Standard cluster thiếu Fair Scheduling, nên một user lớn có thể làm chậm toàn bộ cluster, không "maximize users". Không hiệu quả bằng High Concurrency cho shared access.

📘 Tài liệu tham khảo

• Azure Databricks Documentation (2026 update): Clusters - High Concurrency & Autoscaling.
• Best Practices Guide: Databricks Runtime 14.x+ nhấn mạnh High Concurrency + Autoscaling cho interactive multi-user queries.
• Cost Optimization: Azure Pricing Calculator xác nhận cấu hình này giảm ~30-50% chi phí so với fixed-size clusters.

🛠️ Khuyến nghị thực tế: Trong Azure Portal, khi tạo cluster, chọn "High Concurrency" > Enable Autoscaling (min 2 workers, max theo workload). Test với Delta Lake để tối ưu thêm!

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

Câu hỏi này thuộc lĩnh vực Azure Data Factory (ADF), tập trung vào việc debug (gỡ lỗi) các hoạt động (activities) trong pipeline ADF. Cụ thể:

• Pipeline ADF chứa hỗn hợp các loại activities: Power Query (dùng trong Data Flows để transform dữ liệu), Notebook (thường từ Databricks hoặc Synapse, chạy code Python/Scala), Copy (sao chép dữ liệu giữa sources/sinks), và Jar (chạy Spark Jar jobs, thường từ Databricks hoặc HDInsight).
• Yêu cầu chọn hai dịch vụ Azure để debug các activities này. Mỗi lựa chọn đúng đáng 1 điểm (multiple correct answers).
• Mục tiêu: Xác định dịch vụ hỗ trợ debug toàn diện cho mix activities trên, bao gồm monitoring logs, interactive debug sessions, và trace lỗi thời gian thực. (Kiến thức cập nhật đến 2026: ADF v2 hỗ trợ debug native cho hầu hết activities, tích hợp sâu với Databricks cho Notebook/Jar theo docs Azure 2024-2026).

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

• Azure Data Factory Debug Activities (cập nhật 2025).
• Integrate Azure Databricks with ADF (phiên bản mới nhất 2026 preview).

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

Hai đáp án đúng là: Azure Data Factory và Azure Databricks.
🛠️ Lý do:

• Azure Data Factory cung cấp Debug mode native cho pipeline, hỗ trợ debug trực tiếp Copy, Power Query (Data Flows), và activities từ linked services như Notebook/Jar. Bạn có thể chạy interactive slices, xem input/output, logs chi tiết mà không deploy full pipeline.
• Azure Databricks dùng để debug sâu Notebook và Jar activities (chạy trên Databricks cluster linked với ADF). Hỗ trợ notebook interactive runs, Spark UI, và cluster logs để trace lỗi Spark jobs.
• Kết hợp hai dịch vụ này debug toàn bộ mix activities hiệu quả nhất, theo best practices Azure (không cần Synapse/HDInsight vì chúng không native hỗ trợ tất cả).

📋 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, giữ nguyên văn bản gốc tiếng Anh. Phần giải thích sử dụng emoji để nổi bật:

• Azure Machine Learning
  ❌ Sai: Dịch vụ này chuyên ML workflows (train/deploy models), không hỗ trợ debug ADF activities như Copy/Power Query/Notebook/Jar. Không integrate trực tiếp với ADF pipelines cho debug (chỉ dùng cho ML-specific tasks).

• Azure Data Factory
  ✅ Đúng: Là dịch vụ core cho pipeline orchestration. Cung cấp Activity Runs tab, Debug button, và Input/Output previews để gỡ lỗi tất cả activities (Copy native, Power Query qua Data Flow debug, Notebook/Jar qua linked service monitoring). Hỗ trợ live logs và retry logic theo docs 2026.

• Azure Synapse Analytics
  ❌ Sai: Synapse có pipelines tương tự ADF (Studio), hỗ trợ Notebook/Power Query, nhưng không phải lựa chọn chính cho ADF pipelines thuần. Debug Synapse-specific (Spark pools), không seamless với ADF mix activities (phải migrate mới dùng).

• Azure HDInsight
  ❌ Sai: Dịch vụ Hadoop/Spark managed clusters, hỗ trợ Jar jobs, nhưng deprecated dần từ 2024 (Azure khuyến nghị Databricks thay thế). Không integrate tốt với ADF cho Notebook/Power Query/Copy debug, thiếu interactive notebook UI hiện đại.

• Azure Databricks
  ✅ Đúng: Lakehouse platform lý tưởng cho debug Notebook (interactive runs, %run cells) và Jar (Spark Submit với UI). ADF gọi Databricks activities qua linked service, và debug qua Databricks workspace (Cluster Events, Spark UI). Bổ sung hoàn hảo cho ADF theo integration guides 2026.

🧩 Kết luận: Sử dụng ADF cho debug tổng quát + Databricks cho Spark-heavy activities là giải pháp tối ưu, giúp tiết kiệm thời gian và chi phí! Nếu cần demo, có thể test trên Azure portal.

🧩 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 (cụ thể là dedicated SQL pool tên pool1). Yêu cầu là thực hiện kiểm toán hàng tháng (monthly audit) các câu lệnh SQL ảnh hưởng đến dữ liệu nhạy cảm (sensitive data), đồng thời giảm thiểu nỗ lực quản trị (minimize administrative effort).

📘 Ngữ cảnh chính:

• Dedicated SQL pool trong Synapse là môi trường SQL serverless/dedicated để xử lý dữ liệu lớn.
• "Audit SQL statements that affect sensitive data" nghĩa là theo dõi/log các truy vấn SQL đọc/ghi/sửa dữ liệu được đánh dấu nhạy cảm (như thông tin cá nhân, tài chính).
• Giải pháp phải tự động hóa cao, không yêu cầu can thiệp thủ công hàng tháng để giảm công sức admin.

Mục tiêu là chọn tính năng Azure tích hợp sẵn hỗ trợ audit tự động dựa trên phân loại dữ liệu nhạy cảm. (Kiến thức cập nhật đến 2026: Azure Synapse hỗ trợ Microsoft Purview integration cho sensitivity labels với auditing nâng cao qua Azure SQL Auditing và Purview Data Governance).

✅ Đáp án đúng: sensitivity labels

Lý do chọn:

• Sensitivity labels (từ Microsoft Information Protection và Purview) cho phép phân loại tự động dữ liệu nhạy cảm (như PII - Personally Identifiable Information) trên các cột SQL trong dedicated SQL pool.
• Khi áp dụng, hệ thống tự động audit/log các SQL statements truy cập dữ liệu labeled (qua Azure SQL Auditing hoặc Synapse logs tích hợp Purview).
• Minimize administrative effort: Chỉ cần setup labels một lần (scan tự động), sau đó audit reports được generate hàng tháng qua Purview dashboard hoặc Log Analytics không cần script thủ công. Hỗ trợ export CSV/Power BI cho kiểm toán định kỳ.
• 🛠️ Ưu điểm nổi bật: Tích hợp native với Synapse workspace, không downtime, scale tự động.

Nguồn tham khảo:

• Microsoft Docs: Sensitivity labels in Azure Synapse (cập nhật 2025).
• Purview Auditing for sensitive data (phiên bản mới nhất 2026 với AI auto-labeling).

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

• workload management ❌
  Sai vì: Đây là tính năng quản lý workload/query prioritization trong Synapse (như resource classes, concurrency limits). Nó chỉ kiểm soát performance/ưu tiên truy vấn, không audit SQL statements hay liên quan sensitive data. Sử dụng nó yêu cầu config thủ công liên tục, tăng effort thay vì giảm.

• sensitivity labels ✅
  Đúng vì: Như giải thích trên, tự động classify và audit SQL activities trên sensitive data với minimal setup. Hoàn hảo cho monthly reports qua Purview.

• dynamic data masking ❌
  Sai vì: DDM chỉ ẩn/mask dữ liệu thời gian thực cho user không authorized (ví dụ: thay số CC bằng ****). Nó không log/audit SQL statements, chỉ bảo vệ view dữ liệu, không phù hợp cho kiểm toán truy vấn ảnh hưởng sensitive data.

• Microsoft Defender for SQL ❌
  Sai vì: Đây là công cụ threat detection (alert unusual activities như SQL injection). Nó cung cấp alerts real-time nhưng không tự động audit monthly SQL statements cụ thể trên sensitive data. Yêu cầu config policies phức tạp và review manual, không minimize effort cho audit định kỳ.

🧩 Tóm tắt so sánh nhanh: | Tính năng | Audit SQL sensitive? | Minimize effort? | |-----------|----------------------|------------------| | ✅ sensitivity labels | Có (tự động log) | Cao | | ❌ Các cái khác | Không | Thấp |

Lời khuyên thực hành 💡: Kết hợp sensitivity labels với Azure Monitor/Log Analytics để dashboard monthly audit tự động. Test trên dev pool trước khi apply production!

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

Câu hỏi mô tả một công ty mua các thiết bị IoT để giám sát máy móc sản xuất. Họ sử dụng Azure IoT Hub để giao tiếp với các thiết bị IoT này. Yêu cầu chính là phải giám sát các thiết bị theo thời gian thực (real-time monitoring). Bạn cần thiết kế giải pháp phù hợp để đáp ứng nhu cầu này.

• Bối cảnh chính: Azure IoT Hub là dịch vụ trung tâm quản lý giao tiếp hai chiều giữa IoT devices và cloud, hỗ trợ telemetry data streaming. Để giám sát real-time, giải pháp cần xử lý dữ liệu stream ngay tại edge (thiết bị) hoặc cloud với độ trễ thấp, tránh phụ thuộc vào phân tích OLAP chậm.
• Thách thức: Dữ liệu từ IoT devices đến liên tục, cần xử lý nhanh chóng để phát hiện sự cố máy móc kịp thời, không dùng công cụ phân tích batch hoặc static.
• Mục tiêu thiết kế: Chọn công cụ hỗ trợ stream processing tại edge cho IoT, tích hợp tốt với IoT Hub, phát triển qua Visual Studio để deploy application lên devices.

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

• Azure IoT Hub documentation (cập nhật 2024-2026).
• Azure Stream Analytics on Edge (phiên bản mới nhất hỗ trợ .NET SDK và Visual Studio integration).

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

Đáp án đúng: Azure Stream Analytics Edge application using Microsoft Visual Studio

Lý do 🛠️:

• Azure Stream Analytics Edge cho phép xử lý dữ liệu stream real-time ngay trên thiết bị IoT edge (như gateway hoặc device), giảm độ trễ và phụ thuộc cloud. Nó tích hợp trực tiếp với Azure IoT Hub để nhận telemetry data, chạy các query SQL-like để phân tích, lọc, aggregate real-time (ví dụ: phát hiện anomaly trên máy móc).
• Sử dụng Microsoft Visual Studio để phát triển và deploy ứng dụng Edge như một module (ASA Edge module), hỗ trợ .NET runtime, dễ dàng build, test và push lên devices qua IoT Edge runtime.
• Phù hợp nhất cho real-time monitoring IoT, theo best practices Azure IoT solution architecture (cập nhật 2026 với hỗ trợ AI/ML edge processing).

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

• Azure Analysis Services using Azure Portal
  ❌ Sai vì Azure Analysis Services ( AAS ) là dịch vụ OLAP tabular model cho phân tích dữ liệu lớn (data warehouse), không hỗ trợ stream processing real-time. Nó dùng Portal để quản lý model static, không tích hợp trực tiếp IoT Hub hay edge devices, chỉ phù hợp batch analytics sau khi dữ liệu đã lưu trữ (như trong Synapse hoặc Power BI).

• Azure Stream Analytics Edge application using Microsoft Visual Studio
  ✅ Đúng như đã giải thích ở trên. Đây là giải pháp edge computing real-time tối ưu cho IoT monitoring, deploy qua Visual Studio với hỗ trợ full lifecycle (develop, debug, deploy).

• Azure Analysis Services using Azure PowerShell
  ❌ Sai vì AAS vẫn là công cụ phân tích multidimensional/tabular chậm, dùng PowerShell chỉ để automate provisioning/management server, không xử lý IoT stream data real-time. Không liên quan đến edge hoặc IoT Hub communication.

• Azure Analysis Services using Microsoft Visual Studio
  ❌ Sai vì dù Visual Studio hỗ trợ phát triển AAS models (qua SSDT extension), AAS vẫn chỉ là analytics engine không real-time, tập trung vào cube/query lớn từ data sources stored, không phải stream từ IoT devices. Không đáp ứng yêu cầu giám sát liên tục.

🧠 Kết luận: Giải pháp tập trung vào edge stream analytics là xu hướng mới nhất Azure IoT (2024-2026), giúp tối ưu chi phí và performance cho manufacturing monitoring!

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

Câu hỏi tập trung vào việc lựa chọn loại file phù hợp để lưu trữ dữ liệu trong Azure Blob Storage (tài khoản storage1), sao cho dữ liệu có thể được đọc bởi Azure Synapse Analytics dedicated SQL pool (Pool1). Các yêu cầu cụ thể bao gồm:

• Cho phép Pool1 bỏ qua (skip) các cột và hàng không cần thiết trong truy vấn (column pruning và row group skipping, thường nhờ định dạng columnar từ hình ảnh minh họa trong câu hỏi).
• Tự động tạo thống kê cột (column statistics) để tối ưu hóa hiệu suất truy vấn.
• Giảm thiểu kích thước file (minimize file size) nhờ nén dữ liệu hiệu quả.

🛠️ Bối cảnh kỹ thuật: Trong Azure Synapse Analytics (phiên bản mới nhất 2024-2026), dedicated SQL pool sử dụng PolyBase hoặc COPY INTO để đọc dữ liệu từ Blob Storage qua External Tables. Định dạng file phải hỗ trợ các tính năng tối ưu hóa truy vấn như predicate pushdown, columnar storage, và tự động thu thập stats (qua hệ thống như CE - Columnstore Engine).

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

• Azure Synapse Analytics - Dedicated SQL pool best practices (cập nhật 2025).
• External tables in Synapse SQL (khuyến nghị Parquet cho compression và pruning).
• COPY INTO syntax và file formats (hỗ trợ Parquet từ 2021, tối ưu hóa liên tục đến 2026).

✅ Đáp án đúng: Parquet

Lý do lựa chọn: Parquet là định dạng columnar (lưu trữ theo cột), lý tưởng cho Azure Synapse dedicated SQL pool. Nó đáp ứng đầy đủ 3 yêu cầu:

• Skip columns/rows: Hỗ trợ column pruning (bỏ qua cột không dùng) và row group skipping (bỏ qua hàng dựa trên min/max stats trong metadata).
• Tự động tạo column statistics: Synapse tự động thu thập stats từ metadata Parquet khi query.
• Minimize file size: Nén columnar hiệu quả (Snappy/GZIP), giảm kích thước lên đến 75-90% so với row-based formats.
  🧩 Đây là best practice chính thức từ Microsoft cho large-scale analytics workloads.

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

• JSON ❌ Sai: JSON là định dạng row-based, text-heavy, không hỗ trợ columnar pruning hay row skipping hiệu quả. Không tự động tạo column stats đầy đủ, và kích thước file lớn do không nén tốt (chỉ hỗ trợ cơ bản qua PolyBase, kém hiệu suất cao).
• Parquet ✅ Đúng: Như giải thích trên, hoàn hảo cho tất cả yêu cầu nhờ columnar storage, metadata phong phú, và compression tích hợp. Synapse ưu tiên Parquet cho dedicated pools từ 2021 đến nay (2026).
• Avro ❌ Sai: Avro là row-based (dù có schema), không hỗ trợ columnar pruning/row skipping tốt. Stats không tự động đầy đủ, và compression kém hơn Parquet (dùng Snappy nhưng row-oriented). Không phải lựa chọn tối ưu cho Synapse SQL pools.
• CSV ❌ Sai: CSV là text row-based đơn giản, không có metadata cho pruning/skipping, không tự động stats, và kích thước file lớn nhất (không nén columnar). Chỉ phù hợp dữ liệu nhỏ, không khuyến nghị cho analytics lớn trong Synapse.

🛠️ Lời khuyên thực tế: Khi implement, sử dụng CETAS (CREATE EXTERNAL TABLE AS SELECT) với Parquet để export từ Pool1 sang storage1, đảm bảo partition theo ngày/cột để tối ưu hơn nữa!

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

Câu hỏi tập trung vào Azure Databricks, một nền tảng phân tích dữ liệu lớn trên Microsoft Azure, nơi bạn có thể tạo notebooks hỗ trợ nhiều ngôn ngữ lập trình như R (ngôn ngữ chính), Scala và SQL. 🛠️ Cụ thể, câu hỏi hỏi về cách chuyển đổi ngôn ngữ giữa các cell trong notebook khi tạo notebook mới. Trong Databricks, mỗi cell có thể chạy một ngôn ngữ khác nhau, và bạn cần sử dụng magic command (lệnh đặc biệt) ở đầu cell để chỉ định ngôn ngữ. Điều này giúp linh hoạt chuyển đổi mà không cần tạo notebook riêng biệt cho từng ngôn ngữ. 📘 Kiến thức dựa trên phiên bản Databricks Runtime mới nhất (hỗ trợ đến 2026, không thay đổi cơ bản từ Unity Catalog và Lakehouse Federation).

✅ Đáp án đúng: %<language>

Lý do lựa chọn:
Trong Azure Databricks notebooks, magic command %<language> là cách chuẩn và chính thức để chuyển đổi ngôn ngữ giữa các cell. Ví dụ: %r cho R, %scala cho Scala, %sql cho SQL. Lệnh này được đặt ở dòng đầu tiên của cell và áp dụng cho toàn bộ cell đó. Điều này tuân thủ tài liệu chính thức của Databricks, giúp notebook hỗ trợ đa ngôn ngữ một cách mượt mà mà không cần cấu hình phức tạp. ✅ Hoàn hảo cho kịch bản câu hỏi!

🔍 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 nội dung gốc bằng tiếng Anh, kèm giải thích chi tiết bằng tiếng Việt tại sao đúng/sai dựa trên tính năng Databricks:

• %<language> ✅ Đúng hoàn toàn!
  Đây là magic command chuẩn của Databricks (và Apache Spark notebooks). Ví dụ: %r chuyển sang R, %sql chạy SQL query trực tiếp. Không có thay đổi nào đến năm 2026 – đây là tính năng cốt lõi từ phiên bản đầu tiên. Sử dụng sai vị trí (không ở đầu cell) sẽ báo lỗi syntax.

• @<Language > ❌ Sai!
  Ký hiệu @ không được hỗ trợ trong Databricks để chuyển ngôn ngữ. Nó có thể bị nhầm với decorator trong Python (như @app.route trong Flask) hoặc annotation trong một số ngôn ngữ khác, nhưng không liên quan đến notebooks. Sử dụng sẽ gây lỗi "invalid syntax" ngay lập tức.

• \<language > ❌ Sai!
  Ký hiệu \[ (với dấu backslash escape) giống như markdown syntax cho code block (ví dụ: \[code\] trong LaTeX hoặc display math), nhưng Databricks không dùng để switch ngôn ngữ. Nó chỉ render text, không execute code, dẫn đến cell không chạy và báo lỗi parsing.

• \(<language >) ❌ Sai!
  Ký hiệu \\( tương tự LaTeX inline math (như \(x^2\)), thường dùng trong markdown để hiển thị công thức toán. Trong Databricks, nó chỉ format text, không switch ngôn ngữ hay execute code – cell sẽ bị coi là markdown thuần túy, không chạy R/Scala/SQL.

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

• Databricks Documentation: Notebook languages and magic commands – Xác nhận %<language> là cách chính thức.
• Azure Databricks Guide: Multi-language notebooks – Tích hợp Azure cụ thể.
• Databricks Runtime 15.x+ (2026): Không thay đổi magic commands, hỗ trợ R 4.3+, Scala 2.12/2.13. 🔗 Kiểm tra tại docs.databricks.com cho phiên bản live.

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

🧩 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/ELT mạnh mẽ của Microsoft Azure, dùng để xây dựng pipeline xử lý dữ liệu. Cụ thể:

• Bạn có một pipeline incremental load (tải dữ liệu tăng dần) từ nguồn dữ liệu vào Azure Data Lake Storage Gen2 (ADLS Gen2).
• Dữ liệu cần tải được xác định bởi cột LastUpdatedDate trong bảng nguồn (để chỉ lấy dữ liệu mới/cập nhật).
• Pipeline được lên kế hoạch chạy mỗi 4 giờ.
• Yêu cầu chính:
  • ✅ Tự động retry (thử lại) khi pipeline thất bại do concurrency (đồng thời nhiều job) hoặc throttling limits (giới hạn tốc độ từ dịch vụ).
  • ✅ Hỗ trợ backfilling (tải lại dữ liệu lịch sử đã tồn tại trong bảng, ví dụ để sửa lỗi hoặc bổ sung dữ liệu cũ).

Câu hỏi yêu cầu chọn loại trigger (kích hoạt) phù hợp nhất trong ADF để đáp ứng cả hai yêu cầu trên. Trigger là cơ chế tự động chạy pipeline theo lịch hoặc sự kiện. (Lưu ý: Kiến thức dựa trên phiên bản ADF mới nhất đến 2026, với hỗ trợ tumbling window trigger được cải tiến cho retry và backfill – theo tài liệu Azure cập nhật).

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

• Azure Data Factory Triggers (phiên bản 2024-2026).
• Tumbling Window Trigger best practices.

✅ Đáp án đúng: tumbling window

Lý do lựa chọn 🛠️:

• Tumbling Window Trigger là loại trigger theo cửa sổ thời gian cố định (ví dụ: mỗi 4 giờ), hoàn hảo cho lịch chạy định kỳ như yêu cầu.
• Tự động retry: Hỗ trợ retry policy tích hợp cho lỗi concurrency/throttling (như Data Flow hoặc Integration Runtime overload), với tùy chọn retry sau delay và max retry count. Điều này được thiết kế đặc biệt cho các pipeline tải dữ liệu lớn.
• Hỗ trợ backfill: Cho phép rerun pipeline cho các window thời gian lịch sử (backfill dữ liệu cũ dựa trên LastUpdatedDate), rất phù hợp cho incremental load cần sửa chữa dữ liệu quá khứ.
• Không trigger nào khác đáp ứng đồng thời cả hai yêu cầu này một cách tự động và hiệu quả.

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

• event ❌
  Sai vì: Event-based trigger chỉ kích hoạt khi có sự kiện cụ thể (như file mới upload vào storage hoặc message từ Event Grid/Service Bus). Không hỗ trợ lịch chạy định kỳ mỗi 4 giờ, không có cơ chế retry tự động cho concurrency/throttling, và backfill không khả dụng vì phụ thuộc sự kiện thời gian thực chứ không phải window lịch sử.

• on-demand ❌
  Sai vì: Đây là chế độ chạy thủ công (manual trigger) qua portal/CLI/API. Không tự động chạy theo lịch 4 giờ, không retry tự động (phải chạy lại tay), và backfill chỉ làm thủ công từng lần – không phù hợp cho quy trình tự động hóa.

• schedule ❌
  Sai vì: Schedule trigger chạy theo lịch cron (ví dụ mỗi 4 giờ), hỗ trợ incremental load cơ bản. Tuy nhiên, không hỗ trợ retry tự động cho concurrency/throttling (chỉ retry đơn giản nếu fail hoàn toàn, không xử lý throttling tốt), và không hỗ trợ backfill native (phải dùng workaround như parameter thủ công, kém hiệu quả so với tumbling window).

• tumbling window ✅
  Đúng vì: Như đã giải thích ở phần đáp án. Đây là lựa chọn tối ưu với cửa sổ thời gian không chồng chéo (non-overlapping windows), hỗ trợ dependency giữa các window, retry mạnh mẽ, và backfill dễ dàng qua UI/ARM template. Hoàn hảo cho pipeline incremental với LastUpdatedDate! 🚀

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

Câu hỏi yêu cầu thiết kế một giải pháp sử dụng Azure Data Factory (ADF) để sao chép hàng ngày các file Parquet từ Azure Blob Storage sang Azure Data Lake Storage Gen2 (ADLS Gen2).
Dữ liệu được load theo cấu trúc thư mục: {Year}/{Month}/{Day}/ (ví dụ: 2024/10/05/).
Mục tiêu chính: Tối ưu hóa (minimize) lượng dữ liệu chuyển giữa hai tài khoản lưu trữ (giảm chi phí và thời gian transfer, đặc biệt nếu hai account ở region khác nhau).
Đây là câu hỏi multiple correct answers (chọn 2 cấu hình đúng), mỗi đáp án đúng chiếm 1 điểm.
Giải pháp cần hỗ trợ incremental load (chỉ copy dữ liệu mới/thay đổi hàng ngày), tránh copy toàn bộ dữ liệu mỗi ngày để giảm transfer data.
📘 Nguồn tham khảo: Tài liệu chính thức Microsoft Azure Data Factory (cập nhật 2024-2026): Copy activity - Azure Data Factory, Incremental copy from Azure Blob Storage, ADLS Gen2 connector.

✅ Đáp án đúng (chọn 2 phương án sau)

Hai cấu hình cần thiết để minimize data transfer bằng cách thực hiện incremental copy chỉ với dữ liệu mới theo ngày:

1. Filter by the last modified date of the source files
2. Specify a file naming pattern for the destination

Lý do lựa chọn:

• Kết hợp hai cấu hình này giúp ADF chỉ scan và copy file mới hoặc modified từ source (Blob Storage) dựa trên last modified date (lọc theo ngày hôm trước), sau đó đặt tên file và thư mục đích theo pattern phù hợp {Year}/{Month}/{Day}/ tại destination (ADLS Gen2).
• Điều này tránh copy toàn bộ dữ liệu cũ, giảm đáng kể lượng transfer (chỉ delta data hàng ngày ~ vài GB thay vì TB).
• 🛠️ Cách triển khai trong ADF: Sử dụng Copy Activity với Source dataset filter modifiedDateTime >= @utcnow('yyyy-MM-dd') (hoặc slice theo ngày), và Sink dataset với fileName pattern như @{formatDateTime(utcnow(), 'yyyy/MM/dd')}/file.parquet.

📋 Giải thích chi tiết 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 tiếng Anh. Phần giải thích hoàn toàn bằng tiếng Việt với lý do đúng/sai dựa trên best practices ADF (phiên bản mới nhất 2024+ với hỗ trợ dynamic partitioning và binary copy cho Parquet).

• ✅ Specify a file naming pattern for the destination.
  Đúng: Cấu hình này cho phép ADF tự động tạo tên file và thư mục theo pattern động (ví dụ: @{formatDateTime(pipeline().TriggerTime, 'yyyy/MM/dd')}/data.parquet), khớp với cấu trúc {Year}/{Month}/{Day}/. Kết hợp với filter source, nó đảm bảo chỉ copy delta data vào đúng partition mới, tránh duplicate và minimize transfer bằng cách không cần overwrite toàn bộ. 🧩 Hoàn hảo cho daily partition load.

• ❌ Delete the files in the destination before loading the data.
  Sai: Việc xóa toàn bộ file ở destination trước khi load sẽ buộc ADF phải copy lại toàn bộ dữ liệu mỗi ngày (full reload), tăng lượng transfer lên gấp nhiều lần thay vì chỉ delta. Không phù hợp với mục tiêu minimize, và có thể gây mất dữ liệu lịch sử nếu không backup. 🚫 Chỉ dùng cho trường hợp truncate/load full.

• ✅ Filter by the last modified date of the source files.
  Đúng: ADF hỗ trợ filter LastModified trên source dataset (Blob Storage) như modifiedDateTime > @pipeline().parameters.lastCopyDate. Điều này chỉ lấy file thay đổi từ lần load trước (hàng ngày), giảm scan/copy từ TB xuống chỉ dữ liệu mới (~daily delta). Kết hợp naming pattern để lưu đúng folder ngày. 🛠️ Best practice cho incremental copy Parquet.

• ❌ Delete the source files after they are copied.
  Sai: Xóa source file sau copy không liên quan đến minimize transfer giữa hai accounts (chỉ ảnh hưởng sau khi copy xong). Hơn nữa, source Blob có thể cần giữ nguyên cho business (archive/raw zone), và xóa có rủi ro mất dữ liệu. ADF không khuyến khích auto-delete source trừ khi explicit pipeline. 🚫 Không giúp giảm data transfer.

🏆 Kết luận & Lời khuyên triển khai

Hai đáp án đúng tạo pipeline hiệu quả cao: Filter source → Copy delta → Dynamic naming destination.
💡 Tip nâng cao (2024+): Sử dụng Pipeline parameter cho lastModifiedCutoff và Tumbling Window trigger daily; enable Preserve hierarchy trong Copy Activity để giữ metadata Parquet. Test với Debug mode ADF để verify transfer bytes.
📘 Tài liệu bổ sung: Partitioning in ADF, Cost optimization for Data Movement.

🧩 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, một dịch vụ phân tích dữ liệu tích hợp của Microsoft Azure. Tình huống: Bạn có một subscription Azure chứa Azure Synapse Analytics workspace và một người dùng tên User1. Nhiệm vụ là đảm bảo User1 có thể review (xem xét, duyệt qua) các Azure Synapse Analytics database templates từ gallery (kho mẫu cơ sở dữ liệu có sẵn trong Synapse Studio). Giải pháp phải tuân thủ nguyên tắc least privilege (quyền hạn tối thiểu, chỉ cấp quyền cần thiết nhất để tránh rủi ro bảo mật).

📌 Mục tiêu chính: User1 chỉ cần xem templates từ gallery (không cần chỉnh sửa, tạo mới hay quản lý workspace). Đây là quyền đọc (read-only) cơ bản trong Synapse workspace, không liên quan đến storage hay quyền cao cấp.

🛠️ Ngữ cảnh kỹ thuật:

• Azure Synapse Analytics sử dụng Role-Based Access Control (RBAC) với các role tích hợp sẵn như Synapse User, Synapse Contributor, Synapse Administrator.
• Gallery templates là các mẫu database (như Spark pools, pipelines) có sẵn trong Synapse Studio, yêu cầu quyền truy cập workspace để view.
• Least privilege ưu tiên role thấp nhất đáp ứng yêu cầu (theo nguyên tắc Zero Trust của Azure).

✅ Đáp án đúng: Synapse User

Lý do lựa chọn:

• Role Synapse User cấp quyền xem và sử dụng các artifact cơ bản trong workspace, bao gồm review database templates từ gallery mà không cho phép chỉnh sửa, tạo mới hay quản lý.
• Đây chính là least privilege vì nó chỉ cho phép read và execute (xem và chạy), phù hợp hoàn hảo với yêu cầu "review" (không cần quyền cao hơn).
• Theo tài liệu Azure mới nhất (cập nhật đến 2024-2026, không thay đổi cơ bản), Synapse User đủ để truy cập Synapse Studio và gallery mà không cần quyền contributor hay admin.

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

• ❌ Storage Blob Data Contributor:
  Phương án này sai vì role này thuộc Azure Storage RBAC, chỉ cho phép đóng góp dữ liệu vào Blob storage (upload/download blobs). Không liên quan đến Synapse Analytics workspace hay gallery templates. User1 sẽ không thể truy cập Synapse Studio nếu chỉ có role này. (Least privilege không áp dụng vì không đáp ứng yêu cầu).

• ❌ Synapse Administrator:
  Phương án này sai vì role Synapse Administrator cấp quyền quản lý đầy đủ workspace (tạo, xóa, quản lý tất cả artifact, users, security). Vi phạm least privilege nghiêm trọng vì User1 chỉ cần review templates, không cần quyền admin cao cấp như vậy. Sử dụng role này tăng rủi ro bảo mật không cần thiết.

• ❌ Synapse Contributor:
  Phương án này sai vì role Synapse Contributor cho phép tạo, chỉnh sửa và đóng góp artifact (như pipelines, notebooks, templates). Mặc dù có thể review gallery, nhưng nó cấp quyền write/modify thừa thãi, vi phạm least privilege. Chỉ dùng khi cần phát triển/contribute thực sự.

• ✅ Synapse User:
  Phương án này đúng vì role Synapse User cung cấp quyền truy cập read-only và execute vào workspace, bao gồm xem database templates từ gallery trong Synapse Studio. Hoàn toàn tuân thủ least privilege, không cấp quyền thừa. User1 có thể mở gallery, review templates mà không ảnh hưởng đến các phần khác.

🔗 Tài liệu tham khảo (Azure docs mới nhất đến 2026)

• Azure Synapse Analytics RBAC Overview – Chi tiết các role Synapse.
• Synapse Studio roles and permissions – Xác nhận Synapse User cho gallery access.
• Least privilege principle in Azure – Hướng dẫn áp dụng.

🧠 Lưu ý: Các role này áp dụng ở mức workspace scope. Để assign, dùng Azure Portal > Synapse workspace > Access control (IAM) > Add role assignment. Không có thay đổi lớn trong phiên bản 2024-2026!

🧩 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 xây dựng một giải pháp Structured Streaming trong Azure Databricks (dựa trên Apache Spark Structured Streaming). Cụ thể:

• Bạn đang lập kế hoạch xây dựng một ứng dụng streaming có cấu trúc để đếm số lượng events mới (new events) trong các khoảng thời gian 5 phút (five-minute intervals).
• Yêu cầu chỉ báo cáo (report) những events đến trong khoảng thời gian đó (only events that arrive during the interval), không bao gồm dữ liệu cũ hoặc tổng hợp toàn bộ.
• Kết quả output sẽ được gửi đến một Delta Lake table (bảng hỗ trợ ACID transactions, phù hợp cho streaming writes).

📌 Vấn đề cốt lõi: Trong Structured Streaming, output mode quyết định cách dữ liệu được ghi ra sink (ở đây là Delta Lake) sau mỗi trigger (mặc định hoặc tùy chỉnh 5 phút). Chúng ta cần mode chỉ ghi dữ liệu mới hoàn toàn từ interval hiện tại, không ghi lại toàn bộ state hoặc chỉ updates.

🛠️ Kiến thức nền tảng (cập nhật đến Spark 3.5+ / Databricks Runtime 14.3 LTS năm 2025-2026): Structured Streaming hỗ trợ 3 output mode chính cho các query aggregation trên streaming data: append, complete, và update. Append là lựa chọn lý tưởng cho late-arriving data và chỉ output rows mới.

✅ Đáp án đúng: append

Lý do lựa chọn:

• Append mode chỉ ghi ra những rows mới được tính toán từ dữ liệu đến trong trigger interval hiện tại (ở đây là 5 phút). Nó hoàn hảo cho yêu cầu "count new events" và "report only events that arrive during the interval", vì không rewrite dữ liệu cũ.
• Với Delta Lake, append hỗ trợ incremental writes hiệu quả, tránh full recompute, phù hợp cho streaming production.
• Ví dụ code Spark: df.writeStream.outputMode("append").trigger(processingTime='5 minutes').table("delta_table").
• ✅ Phù hợp 100% với yêu cầu: Không cần state toàn bộ, chỉ thêm counts mới mỗi 5 phút.

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

• ❌ update
  Phương án này SAI vì update mode chỉ output những rows bị thay đổi hoặc mới (updated/changed rows) dựa trên key (như window/groupBy). Với aggregation như count theo 5 phút, nó sẽ ghi chỉ delta changes (tăng/giảm counts), nhưng KHÔNG output full new events nếu không có change so với state trước. Yêu cầu là "report only events that arrive during the interval" → update có thể miss full snapshot mới hoặc gây duplicate nếu late data. Không lý tưởng cho pure "new events count" append-only.

• ❌ complete
  Phương án này SAI vì complete mode yêu cầu ghi lại TOÀN BỘ kết quả aggregation (full state) mỗi trigger (5 phút), bao gồm tất cả intervals từ đầu query. Điều này không hiệu quả cho streaming dài hạn (overhead lớn với Delta Lake), và vi phạm yêu cầu "only events during the interval" vì output thừa dữ liệu cũ. Chỉ dùng cho global aggregations nhỏ (như total count), không phải windowed counts.

• ✅ append
  Phương án này ĐÚNG vì append mode chỉ thêm rows mới hoàn toàn từ dữ liệu xử lý trong interval hiện tại (5 phút), không chạm vào dữ liệu cũ. Hoàn toàn khớp "count new events" và "report only events that arrive during the interval". Delta Lake hỗ trợ append với watermarking để xử lý late data, đảm bảo exactly-once semantics (Spark 3.5+).

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

• Apache Spark Structured Streaming Guide (Spark 3.5.0+): spark.apache.org/docs/latest/structured-streaming-programming-guide.html#output-modes – Chi tiết append cho event-time windows.
• Azure Databricks Docs (Runtime 15.0+ / 2026): docs.databricks.com/en/structured-streaming/output-modes.html – Xác nhận append cho Delta sinks với tumbling windows.
• Delta Lake Guide: delta.io/blog/2024-02-08-delta-streaming-support – Hỗ trợ append streaming writes từ Spark 3.4+.

🧩 Kết luận: Append là mode tối ưu cho use case này, giúp scalable và cost-effective trong Azure Databricks! Nếu cần code sample, hãy hỏi thêm nhé! 🚀