EduDataSci – Educating the world about data and leadership – Data Strategy from a one time K-12 data architect

The GPU Is Not the Product: What Query Acceleration Changes in Microsoft Fabric

The moment a warehouse most needs predictable performance is usually the moment everyone asks it a question at once.

Market volatility drives simultaneous risk, liquidity and exposure queries. A card-processing incident sends analysts, applications and investigators into the same transaction history. Month-end reporting puts Finance, Operations and executives on the same governed data while automated services continue doing their own work in the background.

Microsoft Fabric’s new query acceleration preview addresses that pressure in an unusual way. The T-SQL does not change. The tables do not move. Fabric identifies eligible scans, joins and aggregations and sends them to a GPU working beside the CPU inside the warehouse execution plan.

That does not make every query seven times faster or add general-purpose GPU compute to Fabric notebooks. It makes specialized compute an internal property of the governed data product, below the interface its consumers already use.

Blog News: New Reference Pages, Practical Projects, and Blaise

Explore the new Fabric architecture reference, GitHub guides, Teacher Workbench and Lovable Deployment pages—and meet Blaise in The Anti-Squirrel Resistance.

There is a point at which a useful blog needs a better front door than its most recent post.

An article can explain an idea, take a position, and work through an example. A few weeks later, however, the reader who wants to use that idea may need something different: a current reference, the right download, a guide to contributing, or a clear place to begin. Those resources should not require remembering which Tuesday an article appeared.

I have been adding that kind of structure to EduDataSci. The new pages bring together a Microsoft Fabric architecture reference, practical projects and downloads, and a set of GitHub guides that start with the questions people actually ask. They are intended to make the site more useful after the reading is finished.

There is also a new Sunday contributor. His priorities are companionship, duck sticks, and exposing what he considers a deeply neglected squirrel problem. Blaise has acquired a section of his own, and he is taking the responsibility seriously.

Making AI Capabilities Available to Every Worker

A procurement analyst develops an AI-assisted way to prepare a supplier renewal review. It finds the current agreement, reconciles spending, checks the renewal date, and assembles a briefing. Getting it right has involved experiments, corrections, and decisions about which sources to trust. A colleague wants to use it. If the handover consists of a long prompt, several attachments, and instructions for moving results between applications, much of that development work remains locked inside the analyst’s personal routine.

I think sharing tested capabilities is the best way to make corporate AI investment useful across the workforce. A successful experiment should become something colleagues can use and improve without reconstructing its creator’s process. Skills, plugins, connected tools, and shared agents give us several ways to achieve that. Cowork-style environments provide the place where those capabilities can come together around an employee’s task. I see this becoming the normal way people work with enterprise software, across business functions and levels of technical expertise.

The distinction matters because distributing access to a model leaves a considerable amount of work unfinished. People still need the right information, a workable method, and some means of producing a result. Training everyone to become better at prompting helps, but requiring every employee to rediscover an effective workflow is an expensive approach to organizational learning.

Dear World: You Are Not Taking the Squirrels Seriously

I’m Blaise Lonestar. The squirrels are getting away with something, Mondays need reconsidering, and I would like to come with you.

Dear world,

My name is Blaise Lonestar. I am a white golden retriever, which means I am golden in the important ways and white on your trousers. If we have not met, I would very much like to correct that. You may scratch behind my ears while we discuss the situation.

I live with Jason. I love him with my entire body, particularly the tail, which begins to wiggle when he comes home. He is a good human in many respects. He understands duck sticks, can operate doors, and knows several excellent places to walk. Unfortunately, he also believes that we should sometimes do separate things.

This is one of several matters on which the world needs my perspective. The squirrels are another.

Four Correct Records. No Common Answer

At 10:02, a trader can point to an execution and say the trade exists. Risk can point to an amended position and say the exposure has changed. Operations can point to an unmatched allocation and say the trade is not ready to settle. Finance can point to yesterday’s booking and say nothing new has reached the official ledger.

Nobody is necessarily wrong. That is the problem.

Each application is answering a different question, at a different point in the lifecycle, using a different clock. The trader’s blotter records what was filled. The risk platform measures the exposure it currently understands. The operations platform tracks whether the allocation has matched. The ledger reports what passed a controlled posting boundary by the previous close.

Ask the firm what happened, however, and it may not have an answer. It has four extracts, several timestamps, a reconciliation queue and, eventually, a meeting.

This is not simply bad data quality. It is the predictable result of an architecture that makes applications authoritative for isolated stages and asks reconciliation to assemble enterprise meaning afterward. The alternative is not another master table. It is a governed live lifecycle: persistent identities connect related business objects, semantic events preserve what changed, bitemporal state distinguishes economic effect from firm-recorded time, and materialized views give each function the answer it needs.

The target is not one application—or one physical database—containing all truth. It is a logically governed history from which authorized functions can produce timely, explainable views.

The Landing Lakehouse: The Fabric Pattern Between Arrival and Use

A source begins mirroring into Microsoft Fabric on Friday. By Monday, the tables are visible in OneLake. Production engineers can build from them. Developers can query them. Testers can point validation jobs at them. Analysts can begin exploring.

The delivery looks successful because the data arrived quickly. The architecture may already be in trouble.

The first reachable version of data is rarely the version every user and environment should consume. Production needs fidelity and controlled change. Development needs realistic relationships without unnecessary exposure. Test needs stable inputs that do not shift underneath automated validation. The source team needs to retain authority over what lands and what may be published. Governance needs a defensible answer to a deceptively simple question: which version of this data is visible to whom?

A Landing Lakehouse provides that answer.

The pattern uses a dedicated Lakehouse as the controlled boundary between direct arrival and governed use. Mirrored data, external shortcuts, and source-owned Fabric data can land once. The Landing Lakehouse then exposes distinct schemas for production, anonymized development, representative subsets, Known Copies, and curated validation. Each output is a separate surface with its own purpose, access model, refresh behavior, and owner.

The point is not to add another layer for its own sake. The point is to keep the convenience of Fabric from collapsing several different contracts into one raw surface.

Microsoft Fabric Databases and AI Move Closer to Everyday Operations

A dashboard can tell a business exactly what is wrong while leaving most of the work of fixing it untouched. A collections manager sees overdue balances, then opens email to investigate a dispute, finds the relevant contract, and asks someone else to update the account. The analytical system has produced a useful answer. The operational process still depends on people carrying that answer between systems.

Microsoft’s Fabric, database, and AI announcements since the beginning of September are increasingly aimed at that gap. Fabric is acquiring more of the capabilities needed to describe a business, recognize a change, and support the work that follows. SQL databases are becoming more capable AI application backends. Foundry is adding the execution services that let agents participate in recurring processes. The Barcelona FabCon and SQLCon releases make this direction particularly visible, with the early October Decision-1 announcement adding a specialized model for the smaller judgments inside those processes.

I see this as a substantial expansion of Fabric’s purpose. Microsoft is positioning it as a shared foundation for running data-intensive business operations, extending well beyond reporting and analytical storage. The strongest part of the strategy is its use of assets organizations already own: operational databases, Power BI measures, business relationships, and established permissions. That gives the recent announcements a coherence that is easy to miss when they are read as separate feature lists.

Stop Settlement Fails Before They Start

At 9:42 a.m., an institutional equity trade executes normally. There is no break and no exception to repair.

By 2:00 p.m., the picture has changed. The client’s allocation is later than usual. The standing settlement instruction (SSI) on one record does not agree with the custodian’s current instruction. Securities expected from another account have not arrived. A routine counterparty acknowledgment is still missing.

None of those facts proves that the trade will fail. Together, they say that the trade is becoming harder to settle.

The traditional operating model waits for a definite exception, places it in a queue and asks an operations analyst to reconstruct what happened. A prevention model starts earlier. It watches the trade’s full lifecycle, recognizes a risky pattern, applies the firm’s control rules and intervenes while useful choices remain.

This is not a proposal for a better exception queue. It is a different job for operations: prevent avoidable failures, resolve safe and bounded issues automatically, bring judgment-heavy cases to the right expert, and remove recurring defects from the upstream process.

Definitions Move. Data Stays: The Updated EduDataSci CI/CD Framework for Microsoft Fabric

A Fabric deployment can succeed while the target lakehouse is empty, the wrong Variable Library value set is active, a shortcut still points to Development, and the lakehouse depends on the identity of someone who has left the company.

The API did not lie. The architecture asked it the wrong question.

When I wrote about the ideal Fabric CI/CD approach, the division of labor was clear. Git controls change. Workspaces isolate execution. Deployment Pipelines promote approved content. External CI/CD adds tests and approvals. When native promotion cannot finish the job, fabric-cicd moves item definitions and an idempotent configuration notebook brings the lakehouse into the required state.

That architecture needs an update, not a replacement. Microsoft now frames Git integration, Deployment Pipelines, REST APIs, Variable Libraries, Fabric CLI, Terraform, and fabric-cicd as one Fabric CI/CD platform. Fabric can transport and bind more of the portable definition while exposing better APIs for target-local state.

In this framework, the code plane moves portable definitions and the data plane converges mutable target state. A release is complete only when both have happened—and the release can prove it.

When Software Becomes Disposable: Why the Next Data Mesh Needs Action-Oriented Data Products

Something important changes when intent becomes the front door to software. If a banker, underwriter, advisor, claims lead, or merchant-risk analyst can ask for a task-specific application and receive it in minutes, then bespoke software stops being rare. It becomes cheap. The expensive thing is no longer the application layer. The expensive thing is the interface to truth: the boundary where customer data, authorization, business policy, and systems of record meet.

That shift deserves a different architectural response. I like to frame a data product as reusable, trustworthy, contract-driven, loosely coupled asset with clear ownership, explicit promises about freshness and meaning, and a versioned surface consumers can rely on. The data mesh tradition adds domain ownership, self-serve platform capability, and federated computational governance. My ingest-transform-surface model sharpens the picture further: inputs are explicit, transformation is deliberate, and the published surface is the contract. All of that is right. It just is not enough once agents and intent-driven tools begin to mediate real work.

Domain APIs need to become the front door for fit-for-purpose apps, and the mesh becomes the process glue that turns operational data into analyzable insight and analytical insight into operational action. My argument is that we should now make that shift explicit. The next mesh should be built from Action-Oriented Data Products: domain-owned data products whose interfaces declare not only what can be read and analyzed, but what can be done, by whom, for what purpose, with which guardrails, and against which authoritative source.

This is not a new name for old API management. It is a claim about the next architectural quantum. Data mesh already argued that the data product is the quantum of the analytical estate. In an intent-mediated world, that quantum must become action-oriented. The mesh stays. The node changes. To make that case, I want to do three things: show why current data products stop short, explain the historical parallels to object orientation, microservices, and data mesh, and define the architecture that lets agents discover and manipulate data safely.