Author Archives: Allen Rodriguez

A DAX measure is not a stored answer. It is an expression evaluated under a set of filters that changes with the report cell, slicer, visual axis, relationship path, and filters introduced by the formula itself. That set is filter context. Many DAX problems that look like syntax problems are actually context problems: the formula […]

Power Query transformations are displayed as a tidy list of steps, but the engine does not necessarily execute them one by one on the local machine. When a connector and transformation support it, Power Query can translate work into the source system’s native query language and let the source perform filtering, projection, aggregation, or joins. […]

A Power BI model can look clean in Model view and still be difficult to operate. The real test comes when business logic changes, a new fact source arrives, measures become more complex, and report authors start combining fields in ways the original developer did not anticipate. Star-schema design earns its value because it makes […]

CI/CD in Microsoft Fabric is easy to reduce to two features: connect a workspace to Git and use deployment pipelines to move items between environments. That description is accurate but incomplete. Production safety depends on the boundary between source-controlled definitions, workspace state, environment-specific configuration, data, credentials, and the operational checks that happen after deployment. A […]

Microsoft Fabric makes the lakehouse-versus-warehouse decision look deceptively small because both choices live in OneLake and both can participate in the same analytics estate. The operational difference appears later: in the development language a team prefers, the kinds of data it must accept, the transaction semantics it expects, and the way downstream users change the […]

Data quality and observability are often treated as separate disciplines. Quality teams define rules about completeness, validity, and consistency, while platform teams monitor runs, capacity, and errors. In production those signals belong together. A pipeline can be technically healthy while publishing incorrect data, and a quality rule can fail because the platform never delivered the […]

Performance tuning in a lakehouse is easy to turn into a list of commands: compact files, use V-Order, change partitions, cache data, scale compute. Those actions can help, but only when they address the real bottleneck. A write-heavy ingestion table and a read-heavy Direct Lake table can need opposite choices. Performance work in the DP-700 […]

A pipeline can show “Succeeded” while the business outcome is wrong. A Spark job can run for twice its normal duration and still finish without an error. Monitoring therefore has to answer more than whether an activity completed. It should show whether the expected data moved, whether the workload behaved normally, and where evidence points […]

Deployment pipelines are often introduced as a way to move Fabric content from development to test to production. The real value is not the movement. It is the chance to make change predictable: compare what will move, control who can promote it, separate environment-specific configuration, and create evidence about what reached production. Deployment pipelines matter […]

A Fabric user can be able to open an item and still be unable to read its underlying data. Another user can be able to read a table through one engine while lacking permission to modify the workspace that contains it. Those outcomes are not contradictions. They reflect the fact that Microsoft Fabric separates control […]

Real-time systems are often presented as arrows moving events from a source to a destination. The difficult work sits inside the arrows: ordering, filtering, schema change, time windows, backpressure, duplicate events, and decisions about what should happen when a destination cannot keep up. Fabric Eventstreams lowers the amount of code required to route and transform […]

Incremental ingestion is often introduced as an efficiency technique: move only new or changed data instead of reading the entire source every time. The harder engineering problem is state. A system has to remember what it already processed, recognize what changed, handle retries, and recover when the source does not behave as expected. Incremental state […]

Delta tables make schema change look deceptively manageable. A new column can be merged, a compatible type can be widened, and some changes can be expressed without rewriting every file. But the table is only one participant. Notebooks, SQL endpoints, semantic models, pipelines, tests, and external consumers can all depend on the old shape. Schema […]

One Lake shortcuts are easy to describe as “data without copying,” but that phrase can encourage the wrong architecture. A shortcut does not remove ownership, security, latency, or change management. It replaces a copy boundary with a live dependency. That can be exactly what a data platform needs, but only when the team understands who […]

Dataflow Gen2 looks simple when it is viewed only as a visual Power Query surface: connect to a source, apply transformations, and write the result somewhere useful. The engineering question is harder. A production team needs to know where the transformation actually runs, which state belongs to the dataflow, which state belongs to the destination, […]