Press "Enter" to skip to content

Category: Microsoft Fabric

Semantic Link Labs UI Updates

Chris Webb takes a look:

There’s so much going on in the Fabric community that it can be hard to keep up with it all. Semantic Link Labs is a great example: in the six months or so since I last had a proper look at it my colleague Michael Kovalsky has done a whole load of cool things and it wasn’t until I had a chat with him recently that I realised how much had changed. Most importantly, for someone old-fashioned like me who still likes tools with a UI, a lot of new functionality has been added which has a UI and is usable with minimal coding.

Click through to see what’s available.

Comments closed

Validating Selective Deployments in Microsoft Fabric

Matt Collins shares some advice:

Selective deployments with the fabric-cicd python library are highly useful for shipping just the items that actually changed in your CI/CD process. Unfortunately, by default, it also tells you that a deployment succeeded when nothing was deployed at all.

This blog showcases an example where we selectively deployed Fabric items to upper environments, not realising that the dev ops pipeline reported as “successful” but did not contain our intended changes. We will then dig into some quality checks that highlighted a bigger error in the way Microsoft Fabric handles item naming in a repository.

You’ll learn how to help safeguard from human error in selective Fabric deployments, as well as create useful build validations in Azure DevOps that help to keep your repository resource names clean and fit-for-purpose. All this is achieved through two simple CI/CD pipelines.

Read on to learn more.

Comments closed

Surrogate Keys in Fabric Data Warehouse

Louis Davidson does some more digging:

Creating the simplest of tables, the first thing I start thinking about is making sure that the data is going to be protected from the user. Users (including myself on my own projects when I have my user hat on) don’t notice when they start inserting poor quality data sometimes. Oops, I hit F5 twice, I wonder if that will affect my data? Without proper constraints, it probably will.

In this second entry, I want to cover a few things about handling surrogate values that will help you avoid some of the (in retrospect) kind of dumb expectations that I had. Fabric Data Warehouse T-SQL feels so much like SQL Server Relational T-SQL that some stuff like choosing a surrogate key makes me think I am missing something.

One of the things Louis mentions is how the values get inserted and how it looks like they’re in different ranges. This makes sense, as each distributed node likely has its own range of identity values, similar to the way merge replication would work with identity keys to prevent overlap.

Comments closed

Configuring OneLake Security for a Microsoft Fabric Lakehouse

Gilbert Quevauvilliers locks things down:

In this blog post, I will show you how to configure OneLake security for a Microsoft Fabric Lakehouse. We will remove the default broad-access role, grant the required Lakehouse access, configure object-, row-, and column-level security, and test the results. The goal is to create a secure-by-default setup in which users can access only the data they need.

Click through for the guide.

Comments closed

Accessing Fabric Semantic Model Data in Excel

Teo Lachev comes full-circle:

Ask a business user where they want to work with the data, and Excel would probably top the list. Regardless of how hard we try to lure users away from it, Excel remains the endpoint of self-service BI for many organizations. I have clients who have built custom apps or purchased Excel add-ins simply to get data into Excel—or manipulate it once it gets there.

So rather than fighting Excel, let’s look at the options Microsoft provides for bringing governed Power BI data into it. In particular, I’m interested in getting data from Fabric semantic models into Excel.

Click through for five options, including their pros and cons.

Comments closed

Deploying Fabric Resources via ADO

Jon Lunn continues a series on source control and branching with Microsoft Fabric:

There are a few things you need to check first:

  1. Does the account your going to use to authenticate to (In this case a Service Principal) been added to the workspace with contributor level access?
  2. Has the DevOps Library been updated with the values for the Service Principal and workspace id you are deploying to?
  3. Has any DevOps Environment that is production been gated to to allow deployments only after approval?
  4. Got the list of items to deploy?

You have done all those, then alright! Lets push that button! Flick that switch! Saddle that horse!

Be right back; acquiring horse.

Comments closed

Tips on When to Use Microsoft Fabric Shortcuts

James Serra offers up some guidance:

Imagine separate Sales, Finance, Shared Data, and Executive Analytics workspaces. Sales owns sales transactions, Finance owns budgets, and Shared Data owns common tables such as Customer, Product, and Date. Executive Analytics needs selected data from all three, but it does not want to copy everything into another lakehouse and maintain another set of pipelines. Instead, it creates shortcuts to the authoritative tables and presents them together in its own lakehouse.

This is where the beauty of Fabric OneLake shortcuts becomes obvious. To a report developer or analyst, the Executive Analytics lakehouse can look like one complete collection of tables. That person might not even know which tables are physically stored there and which are shortcuts—and usually should not need to know. Fabric resolves those paths behind the scenes, which is one reason I call Fabric “the great data unifier”: it can present one logical data estate without forcing all the data into one physical location.

Click through to learn more about what shortcuts are, how they work, and when you should (or should not) use them.

Comments closed

Handling Backpressure in Fabric Real-Time Intelligence

Greg Low talks about backpressure:

In any real-time data system, there’s a point where the incoming event rate can exceed what the system can process. This condition is known as backpressure.

Backpressure can occur for a few reasons — a sudden spike in data volume, slow or overloaded consumers, or limited throughput in one part of the pipeline. If it’s not handled properly, it can cascade through the system, eventually causing delays or even a complete stall in event processing.

There are several strategies to handle backpressure effectively.

Click through for those mechanisms. The pedant in me who hates how “real-time” has replaced “online” in terms of systems terminology—not Greg’s fault in the least—would point out that if you truly have a real-time system, you can’t afford to have backpressure because any sort of delay would be inimical to it being real-time.

Comments closed

Datatypes and Constraints in Microsoft Fabric Data Warehouses

Louis Davidson starts digging in:

There are three major “engines” in Fabric that I have seen that use T-SQL. There is the SQL Azure Fabric engine, the Lakehouse, and the Data Warehouse. Having this capability to manipulate data is wonderful, but there are some things you need to understand before you start writing code (unless you want to learn them the hard way like I have. I also will not profess to have found all of these differences. Changing my mindset when using these engines was the subject of this editorial

Read on for some inconsistency.

Comments closed