eventhouse
74 TopicsEventhouse Capacity Planner minimum CU not reflected in UI/API
Hi all, We've set a minimum of 32 CU on our Eventhouse via Capacity Planner (autoscale alone isn't sufficient - we need guaranteed baseline capacity to protect a large bulk-ingestion workload from destination-side OutOfMemory during a migration). We've been told the 32 CU setting has been applied on the backend, but the Fabric UI and REST API (.show cluster / .show diagnostics) still report capacity/behavior consistent with a much lower tier. Can anyone confirm: Whether the a custom minimum CU value is actually enforced server-side even though the UI/API don't show it, and When UI/API reporting is expected to catch up to reflect the configured minimum? Any insight or similar experience would be appreciated.82Views0likes3CommentsAnomaly Detector is disabled
Hello, I have a big Table in which we have our TimeSeries data from various devices. Since not every device sends the same data we have a big schema of numeric columns that are not filled for every deviceId. Is that the reason why there is no Anomaly Detector in my EventHouse? In the schema I can see that columns for the data are int or real. Some columns are string, but that shoudn't be the reason, right? Has anyone faced the same issue?10Views0likes1CommentHandling Multiple Schemas in Eventstream for Azure Event Hub and Azure IOT Hub data sources
One of the challenges with streaming data is that data comes in a variety of schemas, which can be dynamic and are not always predictable. As applications and data structures change, schema values can sometimes be wildly different across devices or event inputs. Recently a customer reached out with several questions on this common problem. With the capabilities in Fabric Real Time Intelligence we can flexibly ingest this data. Enough of the background let’s get to the problem!Fabric Business Events: what delivery guarantees and replay pattern should we design for?
Hi all, I am testing the newer Business Events capability in Fabric Real-Time Intelligence and trying to understand what reliability assumptions should be made for a production design. The pattern I am looking at is roughly: Eventstream → Business Event → Activator → downstream action / User Data Function with Eventhouse enabled so the published business events are also retained for historical analysis. The current documentation explains the publisher/consumer model and shows how Eventstream can publish a governed business event that Activator then consumes. What I have not been able to find clearly documented is the delivery contract between the published business event and its consumers. A few things I am trying to clarify: If an Activator consumer or downstream action is temporarily unavailable, does Fabric retry delivery of the business event? Should consumers assume at-least-once delivery and therefore be designed to handle duplicate events, or is a different delivery model used? Is event ordering guaranteed in any scope, for example for events from the same Eventstream publisher? Since published business events can also be retained automatically in Eventhouse, is that retained history intended to support replay/reprocessing after a consumer outage, or is it primarily an analytical record and replay would need to be implemented separately? Are there documented retry or delivery-retention windows that should be considered when designing an operational workflow? I am mainly trying to understand what a resilient production pattern should look like when the business event triggers something with side effects, where processing the same event twice or silently missing an event would matter. Would you generally make the downstream consumer idempotent and treat Eventhouse as an audit/recovery store, or is there a more Fabric-native pattern for this? Interested to hear how others are approaching this with Business Events and Activator.50Views0likes2Comments25 November 2024 – Meetup Dutch Fabric User Group & Power BI Gebruikersgroep
We are pleased to announce details of our very special extended in-person user group meetup on November 25th. Which we are doing together with the Power BI Gebruikersgroep. It will be hosted by our friends KPMG in their office at Amstelveen. Together we have an incredible lineup in store, starting with Oskari Heikkinen will talk about "Best practices for Fabric Eventhouse". Afterwards, Marnix Jansen will talk about "The Science of Effective Business Reporting: Using IBCS Standards to Drive Action". To finish the evening, Benni De Jagere and Kasper de Jonge from Microsoft will do an Ignite 2024 recap. You can register to attend by following the link below. 25 November 2024 – Meetup Dutch Fabric User Group – Dutch Fabric User group Don't miss out on this opportunity to gain valuable insights in these amazing sessions.144Views0likes0CommentsZürich - 69th Fabric User Group [IN-PERSON]
Dear Data Wizards, We are looking forward to inviting all of you to our next meetup. This time in in-person mode. If you wish to participate, please reach out to me personally to register. Thanks! Topics What's New - Kristian E2E Scenario - from REST API to KQL Magic to Insights - Meinrad & Kristian The session will be recorded and made available on YouTube --> https://aka.ms/FabricUGYouTube E2E Scenario - from REST API to KQL Magic to Insights In this session, we’ll dive into the fascinating world of metadata-driven pipelines and KQL within Microsoft Fabric. Starting with REST APIs, we’ll explore how to extract stock data, including daily prices, and seamlessly store it in a Lakehouse. But that’s just the beginning! Real-time analytics will transform this data, making it readily available for Power BI reporting. Join us as we demystify the process, share best practices, and empower you to create robust end-to-end solutions. Good to know We want this group to be a safe environment that encourages open discussion, exchange of ideas and problems you may face. Therefore, we kindly ask that no members will leverage the information for unsolicited acquisitions of new customers or projects. This group builds on trust, and without it we cannot learn from each other and excel on this topic. Want to be a presenter? We are always looking for new speaker. If you are interested and would like to show something to the Power BI Meetup Group please feel free to contact us!2.3KViews0likes0CommentsBest practice for handling schema evolution in Fabric Eventstream before data reaches Eventhouse?
I have an Eventstream receiving operational events where the schema may evolve over time. For example, the producer initially sends: DeviceId, Timestamp, Temperature, Status but later adds fields such as: Location, FirmwareVersion, ErrorCode I want the pipeline to continue ingesting events without breaking downstream KQL tables, update policies, materialized views, or Real-Time Dashboards. I am trying to understand where schema evolution should ideally be handled in a production Fabric RTI architecture. Would you: enforce the contract upstream using Schema Registry normalize changing fields inside Eventstream before Eventhouse ingestion land the raw payload first and handle schema evolution inside Eventhouse/KQL maintain separate versioned event schemas/tables How are people handling this in production when producers can add fields without notice? I am particularly interested in avoiding a design where every small upstream schema change forces updates across Eventstream, KQL tables, update policies, and downstream dashboards.Solved94Views0likes2CommentsBest practice for deciding between Eventstream transformations and Eventhouse update policies
Hi Fabric Community, I am exploring a Real-Time Intelligence architecture and would appreciate some guidance on where transformation logic should ideally be placed. The proposed flow is: Azure Event Hubs → Fabric Eventstream → Eventhouse → Real-Time Dashboard / Power BI Fabric Eventstream supports filtering, field management, aggregation and other processing before events are written to the destination. An Eventhouse can also ingest the raw events first and transform them into curated tables through KQL update policies. I am trying to understand the recommended boundary between these two layers. For example, assume the incoming event contains: Device or customer identifier Event timestamp Event type Location Numeric readings Additional JSON properties The required processing includes: Removing events that fail basic validation Renaming and standardizing fields Converting timestamps and data types Flattening selected JSON properties Enriching the event with reference data Creating five-minute aggregates Preserving the original event for auditing and future reprocessing My current thinking is: Use Eventstream for lightweight filtering, routing and simple schema normalization. Land the original event in a Bronze table whenever replay or auditing is required. Use Eventhouse update policies or KQL for enrichment, reusable business logic and curated Silver tables. Use materialized views for frequently queried aggregations rather than calculating them repeatedly in dashboards. However, I am unsure where Microsoft recommends drawing the line. A few questions: Are there transformation types that should generally remain in Eventstream rather than Eventhouse? Is it considered good practice to send both the raw stream and a transformed derived stream into separate Eventhouse tables? When using Eventstream’s Event processing before ingestion mode, what are the trade-offs compared with direct ingestion followed by an Eventhouse update policy? How do teams handle changes to transformation logic when historical events need to be reprocessed? For reference-data enrichment, would you normally perform the lookup in Eventstream or after ingestion with KQL? Are five-minute or hourly aggregations better implemented in Eventstream, through an update policy, or with an Eventhouse materialized view? Microsoft’s Eventstream destination guidance documents both direct ingestion and event processing before ingestion, while the KQL update-policy documentation provides another way to transform ingested data. I would be interested to hear how others divide responsibility between Eventstream and Eventhouse in production, particularly where auditability, reprocessing and maintainability are important. Thanks in advance!Solved96Views0likes2CommentsFabric Eventhouse: Capacity policy for .ingest inline is hard-capped at 1 concurrent operation
Problem When using the KQL Activity in Fabric Data Pipelines to execute .ingest inline commands against an Eventhouse KQL database, the effective ingestion capacity is always 1 concurrent operation — regardless of the Fabric capacity SKU (tested on F2 and F8) and regardless of the cluster capacity policy setting. Running .alter-merge cluster policy capacity with ClusterMaximumConcurrentOperations: 16 succeeds without error, but .show capacity still reports an effective ingestion capacity of 1. Any pipeline pattern that executes .ingest inline within a parallel ForEach immediately hits 429 TooManyRequests / ControlCommandThrottledException errors. Highlighting that the capacity is 1. This makes the KQL Activity (KustoQueryLanguage type) unusable for parallel ingestion scenarios — which is an important use case in data pipelines (logging, event emission, watermark updates during parallel table processing). Question / Request Do you recognize this issue? if so I have the below request: Increase the effective ingestion capacity for Fabric Eventhouse to match what the capacity policy allows (respect ClusterMaximumConcurrentOperations)Solved467Views0likes11Comments