Exam DP-700 topic 1 question 2 discussion

KQL is avaialble in eventhouse only https://learn.microsoft.com/en-us/fabric/fundamentals/decision-guide-data-store

Eventhouse: Read operations: KQL, Spark and T-SQL Write operations: KQL, Spark https://learn.microsoft.com/en-us/fabric/get-started/decision-guide-data-store

Lakehouse read operations available are only T-SQL and Spark. However, Eventhouse read operations permitted are T-SQL,Spark and also KQL as it is required in the question.

a Lakehouse is the correct answer

Here’s why a lakehouse fits perfectly for your scenario: It supports semi-structured data, such as JSON or Parquet. It can be accessed using T-SQL, KQL, and Apache Spark—offering maximum flexibility across personas. You mentioned data is only written using Spark, and lakehouses are optimized for Spark-based ingestion and processing. It stores data in Delta Lake format in OneLake, making it ACID-compliant and performant across engines. Source: Perplexity.ai and Microsoft Copilot (both says Lakehouse) Quite surprised to understand the gap from microsoft learn and copilot https://learn.microsoft.com/en-us/fabric/fundamentals/decision-guide-data-store

Although data is only in Unstructured format and only Apache Spark is used to write, which is fulfilled by both a Lakehouse and Eventhouse. However, provided that there is no mention of streaming data, I would prefer to use Lakehouse as a data storage. Eventhouse is primarily designed for Streaming data and KQL analytics. Writing data using Apache Spark is not the ideal usecase for Eventhouse. On the other hand, Lakehouse can store unstructured data, supports native write access via Apache Spark, can read using T-SQL (using SQL endpoint) and KQL (using shortcuts to Kusto). In real world scenario, Lakehouse is the ideal choice in such a case.

Obviously, the answer is B - T-SQL, KQL and Spark can be used on Eventhouse - T-SQL & Spark can be used on Lakehouse

A. a lakehouse is correct as the constraint is "only written by using Spark"

A. a lakehouse Designed to handle structured, semi-structured, and unstructured data. Stored in Delta Lake format, making it accessible from: Spark (native) T-SQL via the SQL analytics endpoint KQL via OneLake integration Supports multi-engine access. Ideal for big data + analytics scenarios, especially with semi-structured data like JSON, Parquet, etc. Spark is commonly used to write to lakehouses.

The correct is A

A is the correct answer

Eventhouse is the right answer because KQL is avaialble in eventhouse only https://learn.microsoft.com/en-us/fabric/fundamentals/decision-guide-data-store

I select A. Request dont talk about stream data

event house meant for time series data

You need a storage solution that supports: Semi-structured data Read access via T-SQL, KQL, and Apache Spark Write access via Spark A lakehouse in Microsoft Fabric is designed exactly for this: Supports semi-structured and structured data (e.g., JSON, Parquet, CSV). Can be queried using: T-SQL (via SQL analytics endpoint) KQL (via Kusto query endpoint) Apache Spark (via notebooks or jobs) Optimized for big data processing and analytics. Allows Spark-based writes and multi-engine reads.

❌ Why Option B (an Eventhouse) is NOT Correct 🔹 What is an Eventhouse in Microsoft Fabric? An Eventhouse is designed for large-scale, time-series, and event data, such as: Logs Telemetry IoT device data It is optimized for append-only workloads. Queries are executed using KQL (Kusto Query Language). It is NOT built to be written using Apache Spark. It does not natively support T-SQL or Spark-based analytics.

Explanation by chatGPT: A Lakehouse in Microsoft Fabric is designed to store semi-structured data and supports multiple query languages including T-SQL, KQL, and Apache Spark. The question specifies that the data will be written only by Spark, and needs to be read by T-SQL, KQL, and Spark, which fits perfectly with the Lakehouse architecture. Eventhouse is designed mainly for event streaming and ingestion. Datamart is typically used for relational, structured data with a semantic model and T-SQL querying but does not natively support Spark or KQL. Warehouse is optimized for structured, relational data and T-SQL querying but does not support KQL or Spark.