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ế giải pháp xử lý dữ liệu streaming với khối lượng dữ liệu biến đổi (variable volumes). Yêu cầu chính là đảm bảo có thể thay đổi số lượng partition sau khi đã tạo (change the partition count after creation). Đây là một nhu cầu phổ biến trong streaming data để scale linh hoạt theo tải.
Dịch nghĩa câu hỏi: "Bạn đang thiết kế giải pháp dữ liệu streaming để ingest dữ liệu với khối lượng biến đổi. Bạn cần đảm bảo có thể thay đổi số lượng partition sau khi tạo. Dịch vụ nào nên sử dụng để ingest dữ liệu?"
🛠️ Ngữ cảnh kỹ thuật: Trong Azure, partition giúp phân phối dữ liệu song song để tăng throughput. Không phải dịch vụ nào cũng hỗ trợ thay đổi partition sau tạo (ví dụ: Event Hubs Standard bị giới hạn fixed partitions).

✅ Đáp án đúng: Azure Event Hubs Dedicated

Lý do lựa chọn:
Azure Event Hubs Dedicated (nay gọi là Event Hubs Clusters với Dedicated tier) là dịch vụ ingest streaming dữ liệu quy mô lớn, hỗ trợ thay đổi số lượng partition động sau khi tạo Event Hub. Bạn có thể scale từ 1-2 partitions lên đến hàng nghìn (tối đa 2,000 partitions/Event Hub) mà không cần tạo mới. Điều này lý tưởng cho dữ liệu biến đổi, với throughput lên đến petabytes/ngày.
📘 Nguồn tham khảo:

• Azure Event Hubs Dedicated documentation (cập nhật 2024-2026).
• Event Hubs scaling best practices.

📋 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 tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai) với lý do chi tiết:

• ✅ [ĐÚNG] Azure Event Hubs Dedicated
  🟢 Đúng vì: Đây là dịch vụ ingest streaming chuyên dụng, hỗ trợ scale partitions sau tạo thông qua clusters dedicated (từ 1 đến 2,000 partitions). Phù hợp ingest variable volumes với auto-scaling và Kafka compatibility. Không có giới hạn fixed như Standard tier.

• ❌ [SAI] Azure Stream Analytics
  🔴 Sai vì: Đây là dịch vụ xử lý (processing) và phân tích streaming, không phải ingest dữ liệu gốc. Nó nhận input từ Event Hubs/Kafka nhưng không quản lý partitions (không tạo/change partitions). Chỉ dùng cho query/transform, không đáp ứng yêu cầu ingest.

• ❌ [SAI] Azure Data Factory
  🔴 Sai vì: Đây là dịch vụ ETL/ELT orchestration cho batch và pipeline data movement. Hỗ trợ streaming qua Data Flows nhưng không phải ingest streaming thuần và không hỗ trợ change partitions sau tạo (không có khái niệm partitions như Event Hubs). Phù hợp copy data hơn là real-time ingest.

• ❌ [SAI] Azure Synapse Analytics
  🔴 Sai vì: Đây là nền tảng analytics tích hợp (warehouse + pipelines + Spark). Có Synapse Pipelines hỗ trợ streaming nhưng không phải dịch vụ ingest chính, và không cho phép change partitions sau tạo ở mức Event Hubs-like. Tập trung analytics/query hơn ingest scale.

🧩 Kết luận: Azure Event Hubs Dedicated là lựa chọn tối ưu cho yêu cầu scale partitions linh hoạt trong streaming ingest. Nếu deploy, khuyến nghị dùng Terraform/ARM để quản lý clusters! 🚀

🧩 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ế chiến lược phân vùng (partitioning strategy) cho một bảng inventory updates trong Azure Synapse Analytics dedicated SQL pool (nay là Synapse SQL dedicated pool). Bảng này sử dụng clustered columnstore index (CCI) và bao gồm các cột chính từ hình ảnh: EventDate, EventTypeID, WarehouseID, ProductCategoryTypeID.

📊 Thông tin từ hình ảnh (bảng dữ liệu):

• EventDate: Một triệu records được thêm vào bảng mỗi ngày (One million records are added to the table each day). → Dữ liệu tăng trưởng theo thời gian, phù hợp phân tích lịch sử.
• EventTypeID: Bảng chứa 10 triệu records cho mỗi event type (The table contains 10 million records for each event type). → Cardinality trung bình, skew thấp.
• WarehouseID: Bảng chứa 100 triệu records cho mỗi warehouse (The table contains 100 million records for each warehouse). → Mỗi warehouse có lượng dữ liệu lớn nhất, cho thấy ít warehouse nhưng data per warehouse rất cao (skew cao theo warehouse).
• ProductCategoryTypeID: Bảng chứa 25 triệu records cho mỗi product category type (The table contains 25 million records for each product category type). → Cardinality cao hơn EventTypeID.

🔍 Mô hình sử dụng (usage patterns):

• Các nhà phân tích thường xuyên phân tích giao dịch theo warehouse (most commonly analyze transactions for a warehouse).
• Các truy vấn tóm tắt (summarize) theo product category type, date, và/hoặc inventory event type.

🎯 Mục tiêu: Đề xuất cột để phân vùng bảng nhằm giảm thiểu thời gian truy vấn (minimize query times). Trong Synapse SQL dedicated pool với CCI, partitioning giúp:

• Partition elimination: Chỉ scan partitions liên quan khi filter.
• Phân phối dữ liệu đều qua distributions (hash distribution).
• Quản lý data lifecycle (archive old partitions).
• Best practice: Chọn cột thường dùng trong WHERE clause với equality filters, có skew thấp (số records per value tương đương), và cardinality trung bình (không quá thấp gây imbalance).

✅ Đáp án đúng: WarehouseID

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

• Phù hợp nhất với usage patterns: Analysts most commonly query theo warehouse → Partition by WarehouseID cho phép partition elimination hiệu quả, chỉ scan ~100M records/warehouse thay vì toàn bộ bảng (có thể hàng tỷ rows). Điều này giảm I/O và thời gian query đáng kể.
• Skew và cardinality lý tưởng: Mỗi warehouse có 100M records → Ít warehouse (ví dụ: 10 warehouses → total ~1B rows), partitions lớn nhưng cân bằng, tránh hotspot trên distributions.
• Tối ưu CCI: CCI hiệu suất cao với large segments; partitioning giúp segment elimination nhanh khi filter warehouse.
• Không phụ thuộc date (dù 1M/day tốt cho sliding window), vì warehouse là filter phổ biến nhất.

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

• EventTypeID ❌
  Sai vì: Mỗi event type chỉ 10M records → Partitions quá nhỏ (nhiều types → hàng trăm partitions), gây overhead quản lý và metadata. Queries summarize by event type có thể scan nhiều partitions, không giảm thời gian query hiệu quả. Skew thấp nhưng không phải filter phổ biến nhất (warehouse mới là chính).

• ProductCategoryTypeID ❌
  Sai vì: 25M records/category → Cardinality cao (nhiều categories), partitions trung bình nhưng queries summarize by category vẫn cần scan nhiều partitions. Không khớp "most commonly" filter (warehouse quan trọng hơn), dẫn đến ít elimination, query chậm hơn.

• EventDate ❌
  Sai vì: Tuy 1M records/day lý tưởng cho date partitioning (sliding window, archive old data), nhưng queries không chủ yếu filter theo date mà theo warehouse. Partition theo date (daily/monthly) sẽ scan toàn bộ partitions của warehouse qua nhiều ngày, không tối ưu. Skew theo date cao dần (dữ liệu tích lũy).

• WarehouseID ✅
  Đúng vì: Như giải thích trên, khớp chính xác usage (warehouse filter phổ biến nhất), partitions lớn/cân bằng (100M/warehouse), tối ưu elimination cho hầu hết queries. Kết hợp summarize by date/category/type vẫn nhanh nhờ CCI compression.

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

• Azure Synapse Analytics docs: Best practices for dedicated SQL pool - Partitioning → Nhấn mạnh partition trên cột filter thường xuyên với even distribution.
• Synapse SQL Pool partitioning guide (2024+): Hash distributed tables & partitioning → Ưu tiên low-skew columns cho query perf.
• CCI optimization: Columnstore indexes overview → Segment/partition elimination cho large tables.

💡 Lời khuyên thiết kế: Kết hợp hash distribution trên WarehouseID + partition trên cột này để scale tối đa. Test với CTAS để rebuild table!

🧩 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 Synapse Analytics và Azure Data Lake Storage Gen2 (ADLS Gen2), tập trung vào việc thiết lập quyền truy cập an toàn cho SQL pool (trong Azure Synapse workspace) để tải dữ liệu từ data lake.

• Bối cảnh chính:

  • Bạn có một tài khoản ADLS Gen2 enterprise-wide, chỉ có thể truy cập qua Azure Virtual Network (VNET1) – nghĩa là data lake được bảo vệ bằng private endpoint hoặc network rules, không cho phép truy cập public.
  • Bạn đang xây dựng SQL pool trong Azure Synapse để sử dụng dữ liệu từ data lake.
  • Nhóm Sales (Azure AD group) đã được gán quyền truy cập file qua POSIX controls (ACLs trên ADLS Gen2 hỗ trợ AAD groups).
  • Yêu cầu: Tải dữ liệu sales vào SQL pool mỗi giờ (hourly load), cần đảm bảo SQL pool có thể đọc dữ liệu từ data lake một cách tự động và an toàn.

• Vấn đề cốt lõi: SQL pool cần authenticate với ADLS Gen2 mà không dùng SAS (vì SAS không phù hợp cho private access và managed identity tốt hơn). Vì data lake chỉ accessible qua VNET, phải dùng Managed Identity (MI) của Synapse để impersonate quyền của Sales group qua POSIX ACLs. Cần 3 hành động (multi-select question).

• Mục tiêu: Đảm bảo SQL pool (service principal-like qua MI) có quyền đọc dữ liệu sales, phù hợp cho workload hourly mà không cần credential thủ công.

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

• Azure Synapse SQL pool data loading with managed identity
• ADLS Gen2 POSIX ACLs with AAD groups
• Synapse managed identity for private endpoints

✅ Đáp án đúng (3 hành động cần thực hiện)

Để SQL pool truy cập data lake qua VNET và POSIX ACLs của Sales group, cần sử dụng Managed Identity của Synapse workspace/SQL pool. Các bước đúng là:

1. Create a managed identity.
   🛠️ Lý do: Tạo MI (system-assigned hoặc user-assigned) cho Synapse workspace/SQL pool để đại diện cho service khi authenticate với ADLS Gen2. MI là cách an toàn nhất cho workload tự động (hourly), hỗ trợ private VNET access mà không cần SAS hoặc user credentials.

2. Add the managed identity to the Sales group.
   🛠️ Lý do: MI được add vào Azure AD group "Sales" để kế thừa POSIX ACLs trên file/folder data lake. ADLS Gen2 hỗ trợ AAD groups cho ACLs, cho phép MI đọc dữ liệu sales như một "thành viên" group.

3. Use the managed identity as the credentials for the data load process.
   🛠️ Lý do: Trong T-SQL (COPY INTO hoặc PolyBase), chỉ định MI làm credential cho data load từ ABFSS path. Điều này enable hourly load tự động, tích hợp với VNET private endpoint.

📋 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, giữ nguyên văn bản gốc tiếng Anh. Tôi đánh dấu ✅ (đúng, là phần giải pháp) hoặc ❌ (sai, không giải quyết vấn đề).

• Create a managed identity.
  ✅ Đúng: Đây là bước đầu tiên bắt buộc. MI cho phép Synapse service authenticate với ADLS Gen2 mà không cần password/SAS, phù hợp cho VNET-restricted access và POSIX ACLs. Không có MI thì không thể impersonate Sales group.

• Add the managed identity to the Sales group.
  ✅ Đúng: MI phải là "thành viên" của Azure AD group Sales để kế thừa quyền POSIX ACLs trên data lake files. Đây là cách chuẩn để service account (MI) truy cập dữ liệu group-owned.

• Use the managed identity as the credentials for the data load process.
  ✅ Đúng: Sử dụng IDENTITY = 'Managed Identity' trong COPY command để load data hourly. Hỗ trợ private endpoint qua VNET1, an toàn và tự động.

• Add your Azure Active Directory (Azure AD) account to the Sales group.
  ❌ Sai: Tài khoản cá nhân (your AAD account) không dùng cho service workload như SQL pool hourly load. Nó chỉ phù hợp cho interactive access (như Synapse Studio), không scale cho automation và không liên quan đến VNET/service auth.

• Create a shared access signature (SAS).
  ❌ Sai: SAS là token thời hạn cho public/anonymous access, không phù hợp với VNET-restricted data lake (private only). SAS không tích hợp POSIX ACLs/AAD groups, kém an toàn cho enterprise/hourly loads, và Microsoft recommend MI thay thế.

• Use the shared access signature (SAS) as the credentials for the data load process.
  ❌ Sai: SAS không hỗ trợ managed service auth qua VNET/private endpoint. Nó yêu cầu public exposure hoặc key rotation thủ công, không phù hợp hourly automation và vi phạm best practice security (dùng MI thay thế).

🛠️ Tóm tắt: Kết hợp 3 bước ✅ tạo MI → add vào group → dùng làm credential sẽ enable SQL pool load data sales an toàn qua VNET1! 🚀

🧩 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 phân tích thống kê (statistical analysis) sử dụng các hàm Python tùy chỉnh độc quyền (custom proprietary Python functions) trên dữ liệu gần thời gian thực (near real-time data) từ Azure Event Hubs. Mục tiêu chính là giảm thiểu độ trễ (minimize latency).

🛠️ Yêu cầu cốt lõi:

• Dữ liệu đầu vào: Stream từ Azure Event Hubs (dữ liệu streaming cao throughput).
• Xử lý: Phân tích thống kê với Python custom functions (không dùng ngôn ngữ khác như SQL thuần).
• Ưu tiên: Low latency – nghĩa là xử lý nhanh chóng, gần real-time, tránh batch processing chậm.
• Đây là tình huống streaming analytics với lập trình linh hoạt (Python), phù hợp cho data engineering/ML workloads.

📘 Kiến thức cập nhật (đến 2026): Theo tài liệu Microsoft Azure mới nhất (Azure Databricks Runtime 15.x+ và Spark 3.5+), Azure Databricks là lựa chọn tối ưu cho streaming từ Event Hubs nhờ Spark Structured Streaming tích hợp trực tiếp với Python APIs, hỗ trợ custom UDFs (User-Defined Functions) và Delta Live Tables cho low-latency processing.

Nguồn tham khảo:

• Azure Databricks documentation - Event Hubs integration
• Spark Structured Streaming guide
• Azure Event Hubs with Databricks

✅ Đáp án đúng: Azure Databricks

Lý do lựa chọn 🏆:
Azure Databricks là nền tảng dựa trên Apache Spark, hỗ trợ Spark Structured Streaming để xử lý near real-time từ Azure Event Hubs với độ trễ thấp (micro-batch hoặc continuous processing). Nó cho phép viết custom Python functions dễ dàng qua notebooks hoặc jobs, bao gồm statistical analysis (ví dụ: pandas, NumPy, SciPy integrations). Tối ưu hóa latency nhờ auto-scaling clusters và Photon engine (tăng tốc 10-20x cho Python workloads). Phù hợp hoàn hảo cho proprietary code mà không cần compile.

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

• Azure Synapse Analytics ❌
  Phân tích sai: Synapse tốt cho big data analytics (Spark pools + SQL), hỗ trợ Python notebooks, nhưng không tối ưu cho near real-time streaming từ Event Hubs (chủ yếu batch-oriented hoặc Spark jobs chậm hơn). Custom Python functions có thể dùng nhưng latency cao hơn do overhead của Synapse workspace. Không phải lựa chọn minimize latency cho streaming stats. (Cập nhật 2026: Synapse Link hỗ trợ CDC nhưng vẫn không bằng Databricks streaming).

• Azure Databricks ✅
  Phân tích đúng: Như đã giải thích ở trên, đây là lựa chọn lý tưởng với Event Hubs connector native, Python-first (Databricks Runtime hỗ trợ MLflow cho stats models), và low-latency streaming (continuous mode dưới 100ms). Hỗ trợ full custom proprietary functions mà không giới hạn.

• Azure Stream Analytics ❌
  Phân tích sai: Dành cho streaming SQL queries với low latency (sub-second), tích hợp Event Hubs, nhưng không hỗ trợ custom proprietary Python functions (chỉ JavaScript UDFs hạn chế hoặc ML modules predefined). Không phù hợp cho statistical analysis phức tạp cần Python libraries độc quyền.

• Azure SQL Database ❌
  Phân tích sai: Đây là relational database cho OLTP/OLAP, không xử lý streaming near real-time từ Event Hubs (cần ETL riêng). Không hỗ trợ Python functions native (chỉ T-SQL), latency cao cho analysis lớn, không minimize được cho custom stats trên streams. (Cập nhật: Hyperscale hỗ trợ nhưng vẫn không streaming-focused).

🧩 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ế bảng dimension ngày tháng (date dimension table) trong Azure Synapse Analytics dedicated SQL pool (trước đây gọi là SQL Data Warehouse). Bảng này sẽ được sử dụng chung bởi tất cả các bảng fact trong data warehouse. Mục tiêu chính là khuyến nghị loại phân phối (distribution type) giúp tối thiểu hóa việc di chuyển dữ liệu (data movement) trong quá trình thực hiện các truy vấn (queries), đặc biệt là các phép JOIN giữa fact tables lớn và dimension table nhỏ.

📘 Bối cảnh kiến thức: Trong dedicated SQL pool của Azure Synapse, dữ liệu được phân phối (distributed) trên nhiều compute nodes để xử lý song song. Việc chọn distribution type sai có thể dẫn đến data skew hoặc data movement lớn (redistribution) khi JOIN, làm chậm query. Dimension tables như date thường nhỏ và được truy vấn thường xuyên, nên cần strategy tối ưu cho lookup/join.

✅ Đáp án đúng: REPLICATE

Lý do lựa chọn:
REPLICATE là lựa chọn tối ưu nhất cho date dimension table nhỏ, được dùng bởi nhiều fact tables. Nó sao chép toàn bộ bảng lên mọi compute node, giúp tất cả JOIN xảy ra local (không cần di chuyển dữ liệu giữa nodes). Điều này giảm đáng kể data movement, tăng tốc query và tránh broadcast/repartition. Theo best practice của Microsoft (cập nhật đến 2024-2026), REPLICATE lý tưởng cho dimension tables < 2GB, đặc biệt date dimension chỉ vài nghìn rows. 🛠️ Kết quả: Query performance cao, chi phí compute thấp.

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

• HASH ❌
  Sai vì: HASH phân phối dữ liệu dựa trên hash của một cột (ví dụ date key). Với date dimension nhỏ, nó có thể gây data skew nếu distribution column có ít giá trị unique (date chỉ ~10 năm ~3650 rows), dẫn đến data movement lớn khi JOIN với fact tables (phải co-locate hoặc redistribute). Không phù hợp cho bảng nhỏ dùng chung, dễ làm chậm query toàn cục.

• REPLICATE ✅
  Đúng vì: Như đã giải thích ở trên, REPLICATE loại bỏ hoàn toàn data movement bằng cách replicate bảng lên tất cả nodes. Hoàn hảo cho small dimension tables như date, được join thường xuyên với fact tables lớn. Microsoft khuyến nghị: "Use REPLICATE for small tables... to eliminate data movement" (không thay đổi đến 2026). Ưu điểm: Join local, scalable, storage overhead thấp với bảng nhỏ.

• ROUND_ROBIN ❌
  Sai vì: ROUND_ROBIN phân phối ngẫu nhiên đều các rows lên nodes, nhanh cho data loading nhưng tệ nhất cho JOIN. Khi query JOIN với fact tables, phải di chuyển dữ liệu lớn (redistribute) giữa nodes để co-locate, gây bottleneck và chậm query. Không khuyến nghị cho dimension tables cần lookup nhanh.

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

• Azure Synapse Analytics: Table Distribution Options – Hướng dẫn chính thức về HASH/REPLICATE/ROUND_ROBIN.
• Best Practices for Designing Tables – Khuyến nghị REPLICATE cho small dimensions.
• Synapse Dedicated SQL Pool Performance Tuning – Xác nhận minimize data movement với REPLICATE (phiên bản 2024+, không thay đổi lớn đến 2026).

🧩 Tóm tắt: REPLICATE là "ngôi sao" cho date dimension trong Synapse! 🚀

🧩 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ế star schema (mô hình sao) cho một tập dữ liệu chứa hồ sơ đơn hàng trực tuyến. Mỗi hồ sơ bao gồm ngày đặt hàng (order date), ngày giao hàng dự kiến (order due date) và ngày vận chuyển (order ship date).
Mục tiêu chính là tối ưu hóa thời gian truy vấn nhanh nhất khi:

• Truy vấn khoảng ngày tùy ý (arbitrary date ranges).
• Tổng hợp dữ liệu theo thuộc tính lịch dương lịch tài chính (fiscal calendar attributes), ví dụ như quý tài chính, tháng tài chính, ngày lễ, v.v.

Đây là câu hỏi trắc nghiệm đa lựa chọn (chọn hai hành động đúng), thường gặp trong các kỳ thi AWS liên quan đến data warehousing như Amazon Redshift (phiên bản mới nhất đến 2026 hỗ trợ columnar storage và distribution keys tối ưu cho star schema). Star schema bao gồm fact table (bảng sự kiện chứa số liệu) và dimension tables (bảng chiều, như date dimension).
Lý do cần tối ưu: Truy vấn ngày/tháng thường chiếm 80% workload trong data warehouse, nên cần key integer để join/sort nhanh, tránh hàm SQL phức tạp gây chậm.

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

• AWS Redshift Best Practices: Designing Star Schema (cập nhật 2025).
• AWS Well-Architected Framework - Data Analytics Lens: Star Schema Optimization (2026 edition).

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

Hai hành động đúng là:
🟢 Create a date dimension table that has an integer key in the format of YYYYMMDD.
🟢 In the fact table, use integer columns for the date fields.

Lý do lựa chọn:

• Trong Amazon Redshift (và các data warehouse columnar như phiên bản RA3 với AQUA caching 2025-2026), sử dụng integer key dạng YYYYMMDD (ví dụ: 20231225) cho date dimension giúp join siêu nhanh (O(1) so sánh integer), range scan hiệu quả (arbitrary date ranges như BETWEEN 20230101 AND 20231231), và tích hợp fiscal attributes (như fiscal quarter) mà không cần tính toán runtime.
• Fact table dùng integer columns thay vì DateTime để foreign key join trực tiếp với dim_date, giảm storage 50-70%, tăng query speed 10x so với DateTime (do sortkey/distkey trên integer nhanh hơn).
  Kết hợp hai hành động này tạo conformed date dimension chuẩn Kimball methodology, tối ưu cho MPP query engine của Redshift.

🛠️ 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 một, giữ nguyên văn bản gốc tiếng Anh. Phần giải thích đúng/sai dựa trên best practices AWS Redshift 2026 (columnar compression, ZSTD encoding cho integer dates).

❌ Create a date dimension table that has a DateTime key.
Sai: DateTime key (như TIMESTAMP) gây chậm join và range query vì so sánh phức tạp hơn integer (CPU overhead cao trong Redshift's sortmerge join). Không phù hợp fiscal aggregation (phải cast/extract mỗi lần), tăng latency 5-20x so với YYYYMMDD integer.

❌ Use built-in SQL functions to extract date attributes.
Sai: Các hàm như DATE_TRUNC, EXTRACT (YEAR/MONTH) trong Redshift phải tính toán mỗi lần query (runtime cost cao, đặc biệt với billions rows), không cache tốt, làm chậm arbitrary ranges và fiscal attrs (ví dụ: fiscal_month cần custom logic). Không scale cho high-concurrency workloads.

✅ Create a date dimension table that has an integer key in the format of YYYYMMDD.
Đúng: Integer YYYYMMDD là best practice cho dim_date (surrogate key), hỗ trợ fast range scans (BETWEEN integers), pre-computed fiscal attrs (như fiscal_quarter column), và even distribution trong Redshift distkeys. Giảm I/O 90% so với DateTime.

✅ In the fact table, use integer columns for the date fields.
Đúng: Thay DateTime bằng integer (FK to dim_date) giúp compact storage (4 bytes vs 8 bytes), faster joins (integer hash nhanh), và sortkey hiệu quả trên multiple date columns (multi-sortkey Redshift 2025). Tối ưu aggregation by date hierarchies.

❌ Use DateTime columns for the date fields.
Sai: DateTime columns trong fact table (như TIMESTAMP) gây bloat storage, chậm zone map pruning cho ranges, và khó aggregate fiscal (cần functions như DATE_PART). Redshift recommend integer surrogate keys để tránh (theo docs 2026).

Kết luận 💡: Thiết kế này đảm bảo sub-second queries cho date-heavy workloads trên Redshift! Nếu implement, dùng SORTKEY trên date integers và DISTKEY trên dim_date key.

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

Câu hỏi xoay quanh việc quản lý external table trong Azure Synapse Analytics sử dụng PolyBase. Cụ thể:

• Bạn đã tạo một external table tên [Ext].[Items] để query dữ liệu từ các file Parquet lưu trữ trên Azure Data Lake Storage Gen2 (ADLS Gen2) mà không import dữ liệu vào data warehouse.
• External table hiện chỉ có 3 cột, nhưng file Parquet thực tế có 4 cột, bao gồm cột mới là ItemID.
• Nhiệm vụ: Chọn lệnh SQL phù hợp để thêm cột ItemID vào external table mà không cần import dữ liệu.

📘 Lưu ý quan trọng: External table trong Synapse Analytics chỉ là metadata trỏ đến dữ liệu bên ngoài (Parquet files). Schema của table phải khớp chính xác với cấu trúc file Parquet để query thành công. Không hỗ trợ thay đổi schema động qua ALTER (như regular table). Giải pháp yêu cầu tái tạo table với schema đầy đủ. Kiến thức dựa trên tài liệu Azure Synapse cập nhật mới nhất (2024-2026): External tables không hỗ trợ ALTER COLUMN cho PolyBase/Parquet.
Nguồn tham khảo:

• CREATE EXTERNAL TABLE - Azure Synapse Analytics
• PolyBase in Synapse

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

Đáp án đúng:

DROP EXTERNAL TABLE [Ext].[Items]

CREATE EXTERNAL TABLE [Ext].[Items]

(
[ItemID] [int] NULL,
[ItemName] nvarchar(50) NULL,
[ItemType] nvarchar(20) NULL,
[ItemDescription] nvarchar(250)
)
WITH
(
LOCATION='/Items/',
DATA_SOURCE = AzureDataLakeStore,
FILE_FORMAT = PARQUET,
REJECT_TYPE = VALUE,
REJECT_VALUE = 0
);

Lý do:
🛠️ Lệnh này DROP external table cũ (xóa metadata) rồi CREATE lại với schema đầy đủ 4 cột, khớp chính xác cấu trúc file Parquet (bao gồm ItemID). Điều này đảm bảo PolyBase query được toàn bộ dữ liệu mà không cần import. Đây là cách chuẩn theo docs Synapse: Phải recreate table khi schema data source thay đổi. Không ảnh hưởng dữ liệu gốc trên ADLS Gen2. ✅ Hoàn hảo!

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

• Phương án 1 (SAI):
  

  ALTER EXTERNAL TABLE [Ext].[Items]
  
  ADD [ItemID] int;

  
  ❌ Sai vì: Azure Synapse không hỗ trợ ALTER EXTERNAL TABLE để thêm cột. External table chỉ là view metadata, schema phải khớp file lúc CREATE. Lệnh này sẽ báo lỗi syntax. (Regular table mới hỗ trợ ALTER ADD COLUMN).

• Phương án 2 (SAI):
  

  DROP EXTERNAL FILE FORMAT parquetfile1;
  
  CREATE EXTERNAL FILE FORMAT parquetfile1
  
  WITH (
  
  FORMAT_TYPE = PARQUET,
  
  DATA_COMPRESSION = 'org.apache.hadoop.io.compress.SnappyCodec'
  
  );

  
  ❌ Sai vì: Lệnh chỉ tái tạo EXTERNAL FILE FORMAT (định nghĩa format Parquet + compression Snappy), không liên quan đến schema cột của table. File format đã đúng (PARQUET), vấn đề là thiếu cột ItemID trong table definition. Thay đổi này không thêm cột vào [Ext].[Items].

• Phương án 3 (ĐÚNG): ✅ (Đã giải thích ở trên). Hoàn toàn khớp yêu cầu!

• Phương án 4 (SAI):
  

  ALTER TABLE [Ext].[Items]
  
  ADD [ItemID] int;

  
  ❌ Sai vì: External table không hỗ trợ ALTER TABLE ADD COLUMN như internal table. Synapse phân biệt rõ: External table dùng PolyBase phải recreate toàn bộ. Lệnh này gây lỗi "Invalid object name" hoặc syntax error vì external table không phải managed table.

🧩 Tóm tắt: Để xử lý schema mismatch ở external table PolyBase, luôn DROP + CREATE lại với schema đầy đủ. Tránh ALTER! Nếu file Parquet thay đổi thường xuyên, cân nhắc serverless SQL pool trong Synapse cho linh hoạt hơn (cập nhật 2024+).

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

Câu hỏi yêu cầu triển khai Type 3 Slowly Changing Dimension (SCD Type 3) cho dữ liệu product category (danh mục sản phẩm) trong Azure Synapse Analytics dedicated SQL pool.

• SCD Type 3 là một kỹ thuật quản lý thay đổi dữ liệu chậm trong kho dữ liệu (Data Warehouse), nơi lưu trữ lịch sử hạn chế bằng cách thêm các cột mới để ghi nhận giá trị hiện tại và giá trị trước đó (không xóa/sửa dữ liệu cũ, mà "nén" lịch sử vào cột phụ). Không sử dụng effective dates như Type 2.
• Bảng [DBO].[DimProduct] đã tồn tại với các cột cơ bản: ProductKey (surrogate key), ProductSourceID (business key), ProductName, Color, SellStartDate/EndDate, RowInserted/UpdatedDateTime, ETLAuditID.
• Nhiệm vụ: Thêm đúng 2 cột vào bảng này để hỗ trợ SCD Type 3 cho product category data (dữ liệu danh mục sản phẩm, chưa có cột nào liên quan).
• Đây là câu hỏi multi-select (mỗi lựa chọn đúng worth 1 point), dựa trên best practice của Azure Synapse Analytics và SQL Server (phiên bản cập nhật đến 2026, hỗ trợ SCD qua T-SQL và pipelines trong Synapse).

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

• Microsoft Docs: Slowly changing dimensions (Azure Synapse SCD Type 3).
• SQL Server SCD guidance: SCD Type 3 implementation (áp dụng tương tự cho Synapse dedicated pool).

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

Hai cột đúng cần thêm là:

• [CurrentProductCategory] [nvarchar] (100) NOT NULL
• [OriginalProductCategory] [nvarchar] (100) NOT NULL

Lý do 🛠️:

• SCD Type 3 yêu cầu hai cột riêng biệt để lưu giá trị danh mục sản phẩm hiện tại (Current) và giá trị gốc/ban đầu (Original/Previous). Khi category thay đổi, cập nhật cột Current bằng giá trị mới và shift giá trị cũ từ Current sang Original. Điều này giữ lịch sử ngắn gọn (chỉ 2 trạng thái gần nhất) mà không cần Type 2 (với effective dates và multiple rows). Bảng hiện tại thiếu cột category, nên thêm đúng hai cột này là giải pháp chuẩn cho product category data trong Azure Synapse dedicated SQL pool.

📋 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:

• ❌ [SAI] [EffectiveStartDate] [datetime] NOT NULL
  Phương án này sai vì thuộc về SCD Type 2 (sử dụng effective dates để đánh dấu khoảng thời gian hợp lệ của row). SCD Type 3 không dùng effective dates (như Start/End), mà chỉ cần cột current/previous. Thêm cột này sẽ làm phức tạp hóa không cần thiết cho Type 3.

• ✅ [ĐÚNG] [CurrentProductCategory] [nvarchar] (100) NOT NULL
  Phương án này đúng vì là cột lưu giá trị danh mục sản phẩm hiện tại (current value). Khi category thay đổi, giá trị mới được ghi vào đây, trong khi giá trị cũ shift sang cột Original. Phù hợp chuẩn SCD Type 3 trong Synapse (NOT NULL để đảm bảo tính toàn vẹn dữ liệu).

• ❌ [SAI] [EffectiveEndDate] [datetime] NULL
  Phương án này sai tương tự EffectiveStartDate, dành cho SCD Type 2 (đánh dấu ngày kết thúc hiệu lực của row cũ). Type 3 không track full history qua dates, mà chỉ giữ 2 giá trị gần nhất, nên không cần cột này.

• ❌ [SAI] [ProductCategory] [nvarchar] (100) NOT NULL
  Phương án này sai vì chỉ là một cột đơn lẻ (không hỗ trợ lịch sử). SCD Type 3 cần hai cột (current + original) để track thay đổi; cột này giống SCD Type 1 (overwrite), không giữ previous value.

• ✅ [ĐÚNG] [OriginalProductCategory] [nvarchar] (100) NOT NULL
  Phương án này đúng vì lưu giá trị danh mục sản phẩm gốc/trước đó (previous/original value). Khi update, copy Current cũ vào đây và ghi new value vào Current. Hoàn thiện cặp cột chuẩn cho SCD Type 3 trong Azure Synapse.

Kết luận 🎯: Chỉ thêm hai cột ✅ là đủ để implement SCD Type 3 hiệu quả, tận dụng IDENTITY key và audit columns có sẵn trong bảng!

🧩 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ế mô hình bảo mật cho một Azure Synapse Analytics dedicated SQL pool (bộ xử lý SQL chuyên dụng), hỗ trợ nhiều công ty (multi-tenant). Mục tiêu là đảm bảo người dùng từ mỗi công ty chỉ xem được dữ liệu của chính công ty mình, tức là áp dụng row-level security (RLS - bảo mật cấp hàng).

📌 Yêu cầu cụ thể: Chọn hai đối tượng (objects) cần bao gồm trong giải pháp. Mỗi lựa chọn đúng chiếm 1 điểm. Đây là câu hỏi kiểu multiple correct answers (chọn nhiều đáp án đúng), thường gặp trong các kỳ thi chứng chỉ Azure như DP-203 (Data Engineering on Microsoft Azure).

🛠️ Bối cảnh kỹ thuật: Azure Synapse dedicated SQL pool dựa trên SQL Server engine, hỗ trợ RLS để lọc dữ liệu dựa trên điều kiện (ví dụ: cột CompanyID). Giải pháp phải sử dụng các tính năng SQL native, không phải Azure-wide RBAC.

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

Hai đáp án đúng là: "a security policy" và "a predicate function".

Lý do chọn:
Để triển khai RLS trong Azure Synapse dedicated SQL pool, cần kết hợp security policy (chính sách bảo mật) và predicate function (hàm điều kiện). Security policy sẽ áp dụng predicate function lên các bảng cụ thể, lọc hàng dữ liệu dựa trên ngữ cảnh người dùng (ví dụ: kiểm tra CompanyID == USER's Company). Đây là cách chuẩn theo tài liệu Microsoft mới nhất (cập nhật 2024-2026), hỗ trợ multi-tenant mà không cần view phức tạp.

Ví dụ triển khai cơ bản:

• Tạo predicate function: CREATE FUNCTION fn_SecurityPredicate(CompanyID AS INT) RETURNS TABLE...
• Tạo security policy: CREATE SECURITY POLICY FilterPolicy...

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

• Row-level security (RLS) - Azure Synapse Analytics | Microsoft Learn (phiên bản mới nhất 2024).
• CREATE SECURITY POLICY (Transact-SQL) - SQL Server.

📋 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 nội dung gốc tiếng Anh. Mỗi phương án được đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm lý do cụ thể:

• a security policy
  ✅ Đúng. Đây là đối tượng cốt lõi để kích hoạt RLS trên bảng. Security policy liên kết với predicate function, tự động lọc dữ liệu khi query (SELECT/INSERT/UPDATE/DELETE). Không có nó, RLS không hoạt động. Phù hợp hoàn hảo cho multi-tenant.

• a custom role-based access control (RBAC) role
  ❌ Sai. Custom RBAC role là tính năng Azure resource-level (IAM ở subscription/resource group), kiểm soát quyền truy cập workspace hoặc pool, không lọc dữ liệu cấp hàng. Nó chỉ cấp/y tế quyền đọc/ghi pool, không phân biệt dữ liệu công ty.

• a predicate function
  ✅ Đúng. Đây là hàm scalar hoặc table-valued định nghĩa logic lọc (predicate), ví dụ: CompanyID = dbo.fn_CurrentCompany(). Phải kết hợp với security policy để áp dụng. Thiếu nó, không có điều kiện lọc dữ liệu.

• a column encryption key
  ❌ Sai. Column encryption key dùng cho Always Encrypted (mã hóa cột dữ liệu tại client-side), bảo vệ nội dung cột khỏi admin/DBA, không lọc hàng theo công ty. Không liên quan đến RLS multi-tenant.

• asymmetric keys
  ❌ Sai. Asymmetric keys dùng cho mã hóa, ký số, hoặc TDE (Transparent Data Encryption), bảo mật dữ liệu tại rest hoặc transmission. Không hỗ trợ lọc dữ liệu cấp hàng cho multi-tenant.

🧠 Lưu ý bổ sung: Giải pháp này hiệu suất cao trong Synapse (hỗ trợ filtered indexes từ 2023+), tránh performance overhead so với view. Nếu dùng serverless pool, RLS cũng tương tự nhưng cần kiểm tra compatibility level.

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

Câu hỏi thuộc chủ đề Azure Synapse Analytics (cụ thể là Dedicated SQL pool, trước đây gọi là SQL Data Warehouse). Tình huống: Bạn có một SQL pool trong Azure Synapse, và người dùng báo cáo rằng các truy vấn (queries) chạy chậm hơn mong đợi. Sau khi kiểm tra, vấn đề liên quan đến queried columnstore segments (các phân đoạn dữ liệu dạng columnstore bị truy vấn). Bạn cần thêm monitoring vào underlying storage (lưu trữ cơ sở) để chẩn đoán vấn đề. Câu hỏi yêu cầu chọn hai metrics cần monitor, mỗi lựa chọn đúng chiếm 1 điểm.

Mục tiêu chính: Tập trung vào việc theo dõi hiệu suất lưu trữ liên quan đến columnstore indexes, nơi dữ liệu được lưu dưới dạng segments và sử dụng cache để tối ưu truy vấn. Vấn đề chậm có thể do cache không hiệu quả (hit rate thấp hoặc cache đầy), dẫn đến đọc trực tiếp từ storage chậm hơn. 📈

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

Hai metrics đúng là: Cache used percentage và Cache hit percentage.
🛠️ Lý do: Trong Azure Synapse Dedicated SQL pool, columnstore segments được cache vào ResultSet Cache và Columnstore Segment Cache để tăng tốc truy vấn.

• Cache used percentage giúp phát hiện cache bị đầy (utilization cao), buộc phải đọc từ storage chậm.
• Cache hit percentage đo tỷ lệ truy vấn lấy dữ liệu từ cache (thay vì disk), nếu thấp thì segments không được cache tốt, gây chậm.
  Những metrics này trực tiếp liên quan đến underlying storage cho columnstore segments, giúp diagnose chính xác. Theo tài liệu Azure mới nhất (2024-2026), đây là các metric chuẩn trong Azure Monitor cho Synapse SQL pools. 📘

🧩 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:

• ❌ Snapshot Storage Size
  Phương án này SAI vì nó đo kích thước lưu trữ của các snapshot (bản sao lưu tạm thời) trong SQL pool, chủ yếu dùng để theo dõi chi phí storage cho point-in-time recovery. Không liên quan trực tiếp đến hiệu suất columnstore segments hoặc cache hit khi truy vấn, vì snapshot không ảnh hưởng đến tốc độ đọc dữ liệu đang query. 🗑️

• ✅ Cache used percentage
  Phương án này ĐÚNG vì nó hiển thị tỷ lệ phần trăm cache đang được sử dụng (trong tổng cache quota của pool). Nếu cao (>80-90%), cache đầy dẫn đến evict segments cũ, buộc đọc từ underlying storage (như Azure Storage) chậm hơn. Giúp diagnose khi vấn đề là cache không đủ cho columnstore data. 🔄

• ❌ DWU Limit
  Phương án này SAI vì DWU (Data Warehouse Units) là metric về compute capacity (tổng tài nguyên tính toán của pool, như Gen2 DWU). Nó liên quan đến scaling compute, không phải underlying storage hay columnstore segments cụ thể. Vấn đề ở đây là storage/cache, không phải limit compute. ⚠️

• ✅ Cache hit percentage
  Phương án này ĐÚNG vì nó đo tỷ lệ % truy vấn lấy dữ liệu từ cache thay vì disk storage. Với columnstore segments, hit rate thấp (<70-80%) cho thấy segments không được cache hiệu quả, dẫn đến I/O chậm từ storage. Đây là metric cốt lõi để chẩn đoán query chậm liên quan segments. 🎯

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

• Azure Docs chính thức: Monitor cache utilization in Synapse SQL pool – Chi tiết về Cache Hit % và Used % cho columnstore.
• Azure Monitor Metrics: Synapse Analytics Metrics Reference – Liệt kê đầy đủ metrics, xác nhận hai metric trên cho storage diagnostics (Gen2 pools, phiên bản 2024+).
• Best Practices: Troubleshoot query performance in Synapse – Khuyến nghị monitor cache cho columnstore issues.

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