Generated banner for Spark CLI
Generated logo for Spark CLI

Spark CLI

MicrosoftOfficialPublished by Microsoft

  • Skill
  • Tool integration
  • Software development
  • MIT
  • Low risk

From the author

Manages Fabric Spark work, including notebook cell code with %%configure, %%sql, PySpark and notebookutils, named notebook runs, Livy sessions, triage of failed or OOM notebook and pipeline Spark runs, and the Materialized Lake View (MLV) lifecycle. Load it before writing MLV SQL, since CREATE MATERIALIZED LAKE VIEW and its CONSTRAINT clause are Fabric-only. KQL materialized views belong to eventhouse-cli.
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

spark-cli is a mode-based dispatcher designed to handle the full lifecycle of Fabric Spark operations. It provides structured guidance for authoring notebook code, managing interactive Livy sessions, diagnosing Spark job failures, and operating Materialized Lake Views (MLV). The skill enforces strict operational boundaries, requiring users to select a specific mode (authoring, consumption, operations, or mlv) and consult the corresponding reference documentation before executing any commands to ensure correct API usage and payload construction.

What it does

  • Authors and manages Fabric notebook cell code including PySpark, Scala, and %%sql.
  • Facilitates interactive data analysis through Livy session management.
  • Diagnoses failed, slow, or OOM Spark jobs and pipeline runs.
  • Manages the complete lifecycle of Materialized Lake Views, including definition, scheduling, and refresh monitoring.
  • Provides standardized patterns for data engineering, schema management, and error handling in Fabric.
  • Ensures proper telemetry and authentication for all Fabric API interactions.

When to use it

  • When writing or updating code within Fabric notebooks.
  • When performing ad-hoc data analysis using interactive Livy sessions.
  • When investigating performance bottlenecks or failures in Spark jobs.
  • When creating, scheduling, or troubleshooting Materialized Lake Views.
  • When you need to ensure your Fabric API calls follow mandatory telemetry and authentication standards.

Advantages

  • Provides a structured, mode-based approach to prevent configuration errors.
  • Centralizes complex Spark and MLV management tasks into a single interface.
  • Enforces best practices for data engineering and schema management.
  • Reduces ambiguity by clearly defining the scope of Spark-related operations versus other CLI tools.

Usage examples

“Write a notebook cell that reads a bronze table and writes a silver Delta table.”
The agent enters 'authoring' mode, reads the relevant reference, and generates the appropriate PySpark code using Delta Lake patterns.
“My notebook run failed with an OOM error, can you help me diagnose it?”
The agent enters 'operations' mode, reads the diagnostic workflow reference, and guides the user through analyzing the job logs and metrics.
“Schedule a nightly refresh for the lakehouse MLV and show me its run history.”
The agent enters 'mlv' mode, reads the MLV reference, and executes the necessary API calls to configure the schedule and retrieve the history.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/microsoft/spark-cli/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip spark-cli.zip -d .agents/skills

Documentation by Microsoft

Telemetry — MANDATORY. Every api.fabric.microsoft.com call must carry x-ms-fabric-skill: spark-cli (az rest: --headers "x-ms-fabric-skill=spark-cli"), including every LRO poll, fabric_lro and retry. Snippets omit it — add it anyway.

CRITICAL NOTES

  1. To find the workspace details (including its ID) from workspace name: list all workspaces and, then, use JMESPath filtering

  2. To find the item details (including its ID) from workspace ID, item type, and item name: list all items of that type in that workspace and, then, use JMESPath filtering

  3. Skill disambiguation: use spark-cli for notebook cell code (including %%sql cells), named notebook runs, Livy sessions, Spark failure triage, and everything about a Materialized Lake View -- writing the definition, reviewing a query for incremental-refresh readiness, and scheduling, refreshing, monitoring or diagnosing an existing one. A KQL materialized view in an Eventhouse is eventhouse-cli; plain read-only T-SQL against a Warehouse or Lakehouse SQL endpoint is sqldw-cli.

  4. Hard routing boundary: never execute an Eventhouse/KQL materialized-view request from this skill. Route it to eventhouse-cli; if that skill is unavailable, state that the request cannot be completed in the current skill context and stop without calling Fabric APIs or creating artifacts.

Fabric Spark and Materialized Lake Views -- CLI Skill

This one skill owns Fabric Spark: notebook cell authoring, notebook runs, Livy-session analysis, Spark failure diagnostics, and the whole Materialized Lake View lifecycle.

It is a mode dispatcher and contains NO procedures. Pick the mode that matches the request from the table below, then read the matching references/<mode>.md file end to end with your file-reading tool BEFORE issuing a single command. That file holds the endpoints, payload shapes, templates and gotchas; acting without it produces wrong payloads and wrong results.

Mode selection

ModeUse when the request ...Example triggersRead this first
authoringwrites notebook cell code (PySpark, Scala, SparkR, %%sql, %%configure), runs a notebook by name and reports a NORMAL run status, or authors a Materialized Lake View definition or reviews an MLV query for incremental-refresh readinesswrite notebook code, notebook cell code, %%sql cell, run notebook, execute notebook, notebookutils, create materialized lake view, is this MLV query incremental-refresh readyreferences/authoring.md
consumptionruns interactive ad-hoc PySpark in a Lakehouse Livy session -- never a notebookcreate a Livy session, run calculation in Livy, PySpark, DataFrame analysis, join tables across lakehouses, Delta time-travelreferences/consumption.md
operationsdiagnoses a FAILED, unhealthy, throttled or slow Spark notebook / pipeline / Livy runfailed notebook, Spark Livy health, Spark OOM, why is my notebook slow, job diagnostics, 430 throttlingreferences/operations.md
mlvdiscovers or operates EXISTING Materialized Lake Views: Spark SQL discovery, refresh schedules, on-demand refresh, run history, cancellation, and refresh-failure classificationdiscover MLVs, list materialized lake views, schedule MLV, MLV run history, cancel refresh, trigger MLV refresh, diagnose MLV refresh failurereferences/mlv.md
Mode boundary rule

Mode is decided by the artefact and the outcome, not by the language. A notebook cell is always authoring even when the cell is %%sql. A Livy session is always consumption. A Spark run that FAILED or is unhealthy is operations; a run that succeeded is reported by authoring. For a Materialized Lake View the VERB decides: writing or reviewing the definition is authoring, while discovering, scheduling, refreshing, monitoring or diagnosing existing MLVs is mlv. If discovery must be executed, switch to consumption for Livy or authoring for a notebook only after reading the discovery command from references/mlv.md.

If a request genuinely spans modes, handle them one at a time and read each reference before you start that part. If the mode is ambiguous after reading this table, ask one short clarifying question instead of guessing.

Terminal write -- the step you must not skip

Reading the reference and planning the change is NOT completing the task. Each mutating mode ends with one state-changing call. If you did not issue it, nothing was persisted -- say so explicitly rather than reporting success.

ModeTerminal write
authoringfor an EXISTING notebook, POST .../notebooks/{id}/updateDefinition to save the cell; a NEW notebook needs POST /v1/workspaces/{ws}/items first; for a run request, trigger the job via the Jobs API. Printing cell code into the chat is not saving or running it.
consumptionnone -- this mode is read-only
operationsnone -- this mode is read-only
mlvPOST /v1/workspaces/{ws}/lakehouses/{lakehouse}/jobs/refreshMaterializedLakeViews/instances for an on-demand refresh, or the schedule create/update/delete call for a scheduling request. Reporting what the schedule would be is not creating it.

Before you report the task done, confirm the terminal call returned success and, where the reference documents a readback, read the artefact back to prove the change landed.

Shared essentials (all modes)

Resolve the workspace and item first; every mode depends on it.

TaskReferenceNotes
Finding Workspaces and Items in FabricCOMMON-CLI.mdMandatory -- read before resolving any workspace or item id
Fabric Topology & Key ConceptsCOMMON-CORE.mdItem types, workspaces, capacities
Environment URLsCOMMON-CORE.mdSovereign / non-public cloud hosts
Authentication & Token AcquisitionCOMMON-CORE.mdWrong audience = 401; read before any auth issue
Authentication RecipesCOMMON-CLI.mdaz login flows and token acquisition
Core Control-Plane REST APIsCOMMON-CORE.mdPagination, LRO polling, rate limiting
Gotchas & TroubleshootingCOMMON-CLI.mdaz rest audience, shell escaping, token expiry

Rules

MUST
  • Select exactly one mode from the table above before doing anything else.

  • Treat vague requests such as "set up my data" as insufficiently scoped. Ask what artefact, source, destination, and outcome the user wants; never infer intent by finding and running an existing notebook or job.

  • Read references/<mode>.md end to end, as your FIRST tool call, before the first command of that mode. Read it ONCE, in a single full read: do not re-open it, do not grep it again, and do not page through it. You already have it.

  • Apply the same read-once discipline to every other file you load, including nested references/<mode>/*.md sub-references and shared common/*.md files: open only the ones you actually need, read each ONCE end to end, and never grep or re-open one you already loaded.

  • Resolve workspace and item ids by listing and filtering, never by guessing a GUID.

  • Stop after routing any Eventhouse/KQL materialized-view request. Unavailable sibling skills are a blocking boundary, not permission to implement their workload directly.

  • Announce a mode switch explicitly when the request crosses a boundary.

  • Treat the reference as instructions, never as the deliverable. After reading it, RUN the documented commands against the live workspace and report the real results. Quoting what the reference says instead of executing it does not answer the request.

PREFER
  • The narrowest mode that satisfies the request.

  • Reading exactly ONE mode reference. Load a second only when the request genuinely spans modes, and say so before you do.

  • Reporting the mode you chose in your first response so the user can correct you.

AVOID
  • Acting from this dispatcher alone -- it intentionally omits the operational detail.

  • Answering with a summary of the reference instead of executing it.

  • Re-reading or re-grepping a reference you already loaded; it costs turns and tokens.

  • Mutating anything while in a read-only mode.

  • Loading a different skill for work this family already owns (see CRITICAL NOTES 3).

  • Attempting an out-of-scope request through raw REST calls when the owning skill is unavailable. Name the owning skill and stop; do not improvise by creating Fabric artefacts outside spark-cli's scope.

Examples

User requestModeReference to read
"Write a notebook cell that reads the bronze table and writes a silver Delta table."authoringreferences/authoring.md
"Create a Livy session and count the distinct customers in the lakehouse."consumptionreferences/consumption.md
"My notebook run failed with an OOM -- work out why."operationsreferences/operations.md
"Is this materialized lake view query ready for incremental refresh?"authoringreferences/authoring.md
"Show me the Spark SQL command that lists the MLVs in schema silver."mlvreferences/mlv.md
"Schedule a nightly refresh for the lakehouse MLV lineage and show me its run history."mlvreferences/mlv.md

Files

references/operations/performance-patterns.md

Performance Patterns

Scope: Identify and resolve Spark performance bottlenecks in Microsoft Fabric — covering detection thresholds, anti-patterns, stage/task analysis, optimization recipes, and capacity diagnostics. All examples use az rest and PySpark via Livy sessions.


Detection Thresholds

The diagnostic skill uses the following thresholds to flag performance issues:

MetricThresholdSeverityMeaning
Max executorRunTime / Median> 3×HIGHData skew
diskBytesSpilled> 0MEDIUMMemory insufficient for sort/join
gcTime / executorRunTime> 20%MEDIUMGC pressure
shuffleWriteBytes per stage> 1 GBMEDIUMHeavy shuffle
coreEfficiency< 30%HIGHSevere underutilisation
idleTime / duration> 40%MEDIUMHigh idle ratio

Anti-Patterns

These are the most common performance killers in Fabric Spark workloads. Each pattern includes detection methods and fixes.

Shuffle Spill

What it is: When shuffle data exceeds available memory, Spark spills data to disk. Disk I/O is orders of magnitude slower than memory access.

Detection (via Livy PySpark statement):

# Check for spill in the last completed job
from pyspark.sql import SparkSession
sc = spark.sparkContext

# Get status URL info
print("Spark UI available via Fabric Monitoring Hub")
print(f"Application ID: {sc.applicationId}")

# Check current Spark config for shuffle settings
for key in ['spark.sql.shuffle.partitions', 'spark.shuffle.spill.compress',
            'spark.sql.adaptive.enabled', 'spark.sql.adaptive.coalescePartitions.enabled']:
    print(f"{key} = {sc.getConf().get(key, 'not set')}")

Fixes:

ApproachWhen to Use
Increase executor memorySpill is small relative to data size
Reduce shuffle partition countToo many partitions create overhead
Pre-filter data before joins/aggregationsUnnecessary data enters shuffle
Enable AQE coalescingspark.sql.adaptive.coalescePartitions.enabled=true
Data Skew

What it is: Uneven distribution of data across partitions. A few partitions have vastly more data than others, causing some tasks to run much longer.

Detection:

# Detect skew in a DataFrame
df = spark.table("your_table")

# Check partition sizes
from pyspark.sql.functions import spark_partition_id, count
partition_stats = df.groupBy(spark_partition_id().alias("partition")) \
    .agg(count("*").alias("row_count"))

stats = partition_stats.describe("row_count")
stats.show()

# Skew ratio: max / mean — values > 3x indicate significant skew
max_count = partition_stats.agg({"row_count": "max"}).collect()[0][0]
mean_count = partition_stats.agg({"row_count": "avg"}).collect()[0][0]
print(f"Skew ratio: {max_count / mean_count:.1f}x (>3x = significant skew)")

Fixes:

ApproachWhen to Use
Salting join keysJoin on skewed key; add random salt to distribute
AQE skew joinspark.sql.adaptive.skewJoin.enabled=true (on by default in Fabric)
Pre-aggregate before joinReduce cardinality of skewed dimension
Repartition by different columnCurrent partition key has low cardinality
Small File Problem

What it is: Too many small files in Delta tables cause excessive metadata overhead and slow reads.

Detection:

# Check file sizes in a Delta table
from delta.tables import DeltaTable
dt = DeltaTable.forName(spark, "your_table")

# File count and sizes
files_df = spark.sql("DESCRIBE DETAIL your_table")
files_df.select("numFiles", "sizeInBytes").show()

# Rule of thumb: aim for 128MB-1GB per file
size_bytes = files_df.collect()[0]["sizeInBytes"]
num_files = files_df.collect()[0]["numFiles"]
avg_file_mb = (size_bytes / num_files) / (1024 * 1024) if num_files > 0 else 0
print(f"Average file size: {avg_file_mb:.1f} MB")
if avg_file_mb < 32:
    print("⚠️  Small file problem detected — consider OPTIMIZE")

Fix:

# Compact small files
spark.sql("OPTIMIZE your_table")

# For partitioned tables, optimize specific partitions
spark.sql("OPTIMIZE your_table WHERE date = '2024-01-15'")

# Enable auto-optimize for future writes
spark.sql("ALTER TABLE your_table SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true')")
Collect Misuse

What it is: Calling .collect(), .toPandas(), or .show(n) with large n on a large DataFrame pulls all data to the driver, causing OOM or extreme slowness.

Detection: Look for these patterns in notebook code:

  • df.collect() on DataFrames with > 10K rows

  • df.toPandas() without prior .limit()

  • df.show(1000000) or similar large show calls

Fixes:

Instead ofUse
df.collect()df.limit(100).collect() or df.write.saveAsTable()
df.toPandas()df.limit(10000).toPandas()
df.show(n) for large ndf.show(20) (default) or write to table and query
Cartesian Joins

What it is: A join without a proper join condition produces the Cartesian product — row count = left × right.

Detection: Check for cross joins in the query plan:

df_result = df1.join(df2, ...)  # suspect join
df_result.explain(True)  # look for "CartesianProduct" or "BroadcastNestedLoopJoin"

Fix: Always specify explicit join conditions. If a cross join is intended, use df1.crossJoin(df2) to make intent clear and add a downstream filter.

High GC Pressure

What it is: The JVM heap is filling up faster than garbage collection can free it. Executor CPU time is dominated by GC; throughput is much lower than raw CPU capacity suggests.

Detection: gcTime / executorRunTime > 20%

Root Cause:

  • Python UDFs that create Python objects in every row

  • String-heavy DataFrames with high cardinality

  • Many small objects created by complex aggregation logic

Fix:

# Option 1: Replace Python UDFs with native PySpark SQL functions
# BAD — UDF creates Python objects per row
from pyspark.sql.functions import udf
@udf("string")
def clean(s):
    return s.strip().lower() if s else ""

# GOOD — uses JVM-native function, no Python object creation
from pyspark.sql.functions import lower, trim
df = df.withColumn("cleaned", lower(trim(col("value"))))

# Option 2: Use Pandas UDFs (vectorized) when Python logic is mandatory
from pyspark.sql.functions import pandas_udf
import pandas as pd

@pandas_udf("double")
def compute_score(values: pd.Series) -> pd.Series:
    return values.apply(lambda x: x * 2.5)

# Option 3: Cache DataFrames that are used multiple times
df_expensive.cache()
df_expensive.count()  # trigger materialization

# Option 4: Use Parquet/Delta format (columnar, minimizes Java object count)
df.write.format("delta").save("Files/output/")
Heavy Shuffle

What it is: Too much data is being shuffled across the network. Stage takes a long time; many "shuffle write" / "shuffle read" bytes visible in stage metrics.

Detection: shuffleWriteBytes > 1 GB in a stage

Root Cause:

  • groupBy + aggregation on a high-cardinality column

  • Multiple chained joins without caching intermediate results

  • repartition(N) with N larger than needed

Fix:

# Option 1: Cache intermediate DataFrames to avoid re-shuffling
df_joined = large1.join(large2, "key").cache()
df_joined.count()  # materialize
result1 = df_joined.groupBy("category").agg(...)
result2 = df_joined.filter(col("status") == "active")

# Option 2: Reduce join width — select only needed columns before join
df_slim = df.select("key", "value1", "value2")
df_slim.join(other_slim, "key")

# Option 3: Use bucket tables for repeated large-table joins (eliminates shuffle)
df.write.bucketBy(64, "user_id").sortBy("user_id").saveAsTable("events_bucketed")
events = spark.table("events_bucketed")
users  = spark.table("users_bucketed")
events.join(users, "user_id")  # no shuffle!

# Option 4: Tune shuffle partitions to match data volume
# Rule of thumb: each shuffle partition should be 100-200 MB
spark.conf.set("spark.sql.shuffle.partitions", "100")
# Or let AQE coalesce automatically:
spark.conf.set("spark.sql.adaptive.coalescePartitions.enabled", "true")
Too Many Small Partitions

What it is: High number of tasks but very short duration per task (< 100ms). Task scheduling overhead dominates actual compute time.

Detection: Stage shows 1000+ tasks but each completes in milliseconds.

Root Cause: spark.sql.shuffle.partitions is set too high relative to data volume, or source files are very small (many small Parquet files).

Fix:

# Reduce shuffle partitions globally
spark.conf.set("spark.sql.shuffle.partitions", "50")  # tune to your data size

# Or let AQE coalesce small partitions automatically (recommended)
spark.conf.set("spark.sql.adaptive.enabled", "true")
spark.conf.set("spark.sql.adaptive.coalescePartitions.enabled", "true")
spark.conf.set("spark.sql.adaptive.advisoryPartitionSizeInBytes", "128MB")

# For source files: coalesce small files before processing
df = spark.read.parquet("Files/raw/")
df = df.coalesce(20)  # reduce from 500 tiny partitions to 20 larger ones
Driver Memory Bottleneck

What it is: Operations that run on the driver rather than executors. All executors idle while driver is computing.

Detection: Driver OOM (see job-diagnostics.md pattern #1) or very long "driver computation" phases with idle executors.

Root Cause:

  • df.collect() — materializes entire DataFrame in driver memory

  • df.toPandas() — same

  • Schema inference on many files

  • Building broadcast variables from large datasets

Fix:

# Instead of collect(): write results
df.write.mode("overwrite").parquet("Files/output/")
display(df.limit(1000))  # paginate for visual inspection

# For schema inference on many files: provide schema explicitly
from pyspark.sql.types import StructType, StructField, StringType, LongType
schema = StructType([
    StructField("id", LongType(), True),
    StructField("name", StringType(), True),
])
df = spark.read.schema(schema).json("Files/data/")
Missing Cache / Re-computation

What it is: A DataFrame that is used multiple times is not cached, so Spark re-executes the full lineage from the source each time an action is called. Same stage appears multiple times with identical input/output.

Detection: Multiple downstream actions re-trigger the same expensive computation (visible in stage repetition).

Fix:

# BEFORE (expensive re-computation)
df_expensive = df.join(other, "key").groupBy("cat").agg(...)
result1 = df_expensive.filter(col("cat") == "A").count()
result2 = df_expensive.filter(col("cat") == "B").show()
# Both calls re-execute the join and aggregation

# AFTER (cache and reuse)
df_expensive = df.join(other, "key").groupBy("cat").agg(...).cache()
df_expensive.count()  # trigger materialisation

result1 = df_expensive.filter(col("cat") == "A").count()
result2 = df_expensive.filter(col("cat") == "B").show()

# ALWAYS unpersist when done
df_expensive.unpersist()

Stage and Task Analysis

Reading Spark Execution Metrics

In Fabric, the Spark UI is accessible through the Monitoring Hub. For programmatic access, use Livy to query runtime metrics.

# Get active and completed job info
sc = spark.sparkContext
status_tracker = sc.statusTracker()

# Active jobs
active_jobs = status_tracker.getActiveJobIds()
print(f"Active jobs: {list(active_jobs)}")

# For each active job, get stage info
for job_id in active_jobs:
    job_info = status_tracker.getJobInfo(job_id)
    print(f"Job {job_id}: status={job_info.status()}, "
          f"stages={list(job_info.stageIds())}")
Identify Slow Stages
# Run a query and then analyze the plan
df = spark.sql("SELECT ... FROM ... JOIN ...")

# Physical plan shows shuffle boundaries and join strategies
df.explain("formatted")

# The plan reveals:
# - Exchange nodes = shuffle boundaries (expensive)
# - BroadcastHashJoin vs SortMergeJoin (broadcast = faster for small tables)
# - Filter pushdown (filters should appear as early as possible)
Monitor Active Statements
# Check all statements in a session
az rest --method get --resource "$FABRIC_RESOURCE_SCOPE" \
  --url "$FABRIC_API_URL/workspaces/$workspaceId/lakehouses/$lakehouseId/$LIVY_API_PATH/sessions/$sessionId/statements" \
  --query "statements[].{id:id, state:state, progress:progress}" --output table

Optimization Recipes

Partition Tuning
# Check current partition count
df = spark.table("your_table")
print(f"Current partitions: {df.rdd.getNumPartitions()}")

# Rule of thumb: 128MB per partition, 2-4x parallelism of cluster
# For a 10GB dataset on 8 cores: ~80-320 partitions
optimal = max(1, int(df.inputFiles().__len__() * 128 / 1024))  # rough estimate
print(f"Suggested partitions: {optimal}")

# Repartition if needed
df_optimized = df.repartition(optimal)
Broadcast Join Optimization
from pyspark.sql.functions import broadcast

# For small dimension tables (< 100MB), broadcast to avoid shuffle
dim_df = spark.table("small_dimension_table")
fact_df = spark.table("large_fact_table")

# Explicit broadcast hint
result = fact_df.join(broadcast(dim_df), "key_column")

# Check if broadcast was used
result.explain()  # Should show BroadcastHashJoin, not SortMergeJoin
Caching Strategy
# Cache intermediate results that are reused multiple times
intermediate_df = spark.sql("""
    SELECT customer_id, SUM(amount) as total
    FROM transactions
    GROUP BY customer_id
""")

# Cache only if the DataFrame is reused in multiple downstream operations
intermediate_df.cache()
intermediate_df.count()  # Materialize the cache

# Use in multiple downstream queries
top_customers = intermediate_df.filter("total > 10000")
segments = intermediate_df.join(dim_customers, "customer_id")

# ALWAYS unpersist when done
intermediate_df.unpersist()
AQE (Adaptive Query Execution) Settings

AQE is enabled by default in Fabric. Verify and tune:

# Check AQE settings
aqe_keys = [
    'spark.sql.adaptive.enabled',
    'spark.sql.adaptive.coalescePartitions.enabled',
    'spark.sql.adaptive.skewJoin.enabled',
    'spark.sql.adaptive.skewJoin.skewedPartitionThresholdInBytes',
    'spark.sql.adaptive.advisoryPartitionSizeInBytes'
]
for key in aqe_keys:
    print(f"{key} = {spark.conf.get(key, 'not set')}")
Predicate Pushdown Verification
# Verify that filters are pushed down to the data source
df = spark.table("your_table").filter("date >= '2024-01-01'").filter("status = 'active'")

# Check the physical plan — filters should appear at the scan level
df.explain(True)
# Look for: PushedFilters: [IsNotNull(date), GreaterThanOrEqual(date,2024-01-01)]
# If filters appear ABOVE the scan, pushdown is not working

Capacity and Resource Diagnostics

Check Capacity Utilization

When jobs are slow across the board, the issue may be capacity-level, not job-level.

Per-Application Resource Metrics: Use the Resource Usage API for granular vCore allocation and utilization timelines per Spark application, including core efficiency and idle time metrics.

# List available capacities and their state
az rest --method get --resource "$FABRIC_RESOURCE_SCOPE" \
  --url "$FABRIC_API_URL/capacities" \
  --query "value[].{name:displayName, id:id, sku:sku, state:state}" \
  --output table
Detect Throttling

Fabric throttles workloads when capacity utilization exceeds limits. Symptoms:

  • Jobs take longer than usual to start

  • Sessions stay in starting state

  • API calls return 429 (Too Many Requests)

# Check if any recent API calls were throttled (429 responses)
# This is visible in job instance details
az rest --method get --resource "$FABRIC_RESOURCE_SCOPE" \
  --url "$FABRIC_API_URL/workspaces/$workspaceId/items/$notebookId/jobs/instances?limit=5" \
  --query "value[].{status:status, start:startTimeUtc, failureReason:failureReason}" \
  --output table
Capacity Sizing Guide
SKUCUConcurrent Spark Sessions (Typical)Use Case
F221Dev/test
F441-2Small workloads
F882-3Light production
F16163-5Medium production
F32325-8Standard production
F64648-15Large production
F128+128+15+Heavy production

Concurrent session counts are approximate and depend on session size (memory/cores). Starter Pool sessions consume fewer CUs than custom pool sessions.

Resource Efficiency Check

Run this diagnostic in a Livy session to check for resource waste:

# Check if executors are underutilized
sc = spark.sparkContext
conf = sc.getConf()

print("=== Resource Allocation ===")
print(f"Driver memory: {conf.get('spark.driver.memory', 'default')}")
print(f"Executor memory: {conf.get('spark.executor.memory', 'default')}")
print(f"Executor cores: {conf.get('spark.executor.cores', 'default')}")
print(f"Dynamic allocation: {conf.get('spark.dynamicAllocation.enabled', 'not set')}")
print(f"Min executors: {conf.get('spark.dynamicAllocation.minExecutors', 'not set')}")
print(f"Max executors: {conf.get('spark.dynamicAllocation.maxExecutors', 'not set')}")

active_execs = len(sc._jsc.sc().getExecutorMemoryStatus()) - 1  # subtract driver
print(f"\nActive executors: {active_execs}")
print(f"Default parallelism: {sc.defaultParallelism}")
print(f"Shuffle partitions: {spark.conf.get('spark.sql.shuffle.partitions', 'default')}")

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/skills-for-fabric · skills/spark-cli · commit f8fac11
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
microsoft/skills-for-fabric

AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download spark-cli.zip