साप्ताहिक डेटा और AI सारांश — 18 अगस्त 2026

इस सप्ताह Power BI विज़ुअल कैलकुलेशन, Databricks Unity Catalog में Apache Iceberg टेबल और Snowflake के CLASSIFY_TEXT से AI_CLASSIFY बदलाव के साथ तीन…

इस सप्ताह Power BI विज़ुअल कैलकुलेशन, Databricks Unity Catalog में Apache Iceberg टेबल और Snowflake के CLASSIFY_TEXT से AI_CLASSIFY बदलाव के साथ तीन ध्यान देने योग्य टूल शामिल हैं।

Visual Calculations Reach GA — Running Totals Get an ORDERBY Parameter

What changed

  • Visual calculations (DAX written directly on a visual instead of in the model) reached general availability in the July 2026 Power BI release.
  • Visual-calculation-exclusive window functions — RUNNINGSUM, MOVINGAVERAGE, PREVIOUS, and others — now accept an optional ORDERBY parameter, letting you control the sort order the calculation uses independently of how the visual itself is currently sorted.
  • Without ORDERBY, a visual calculation sorts by the visual's default axis order; with it, a running sum can accumulate in, say, descending sales order for a Pareto chart regardless of how the table is displayed on screen.
  • Visual calculations still live only on the visual they're added to — unlike a model measure or a DAX UDF, they aren't reusable across other visuals, which is the tradeoff for the simpler syntax.

Before

// Model measure: Pareto running total, the pre-visual-calculations way
Pareto Running Total =
VAR CurrentProduct = SELECTEDVALUE( Product[Product Name] )
VAR SalesRank =
    RANKX( ALLSELECTED( Product[Product Name] ), [Total Sales], , DESC )
RETURN
    CALCULATE(
        [Total Sales],
        TOPN( SalesRank, ALLSELECTED( Product[Product Name] ), [Total Sales], DESC )
    )

After

// Visual calculation, added directly on the table/chart — not in the model
Pareto Running Total = RUNNINGSUM( [Total Sales], ORDERBY( [Total Sales], DESC ) )

Why it matters

The RANKX + TOPN + ALLSELECTED pattern works, but most analysts have to look it up every time they need it. The visual calculation collapses that to one line, at the cost of not being reusable outside that one visual — for a one-off Pareto chart on a single report page, that's usually the right tradeoff; for logic every measure needs, a DAX UDF (see last week's update) is still the better fit.

Unity Catalog Now Natively Manages Apache Iceberg Tables

What changed

  • Unity Catalog managed tables now support Apache Iceberg directly — CREATE TABLE ... USING iceberg creates a natively managed, UC-governed Iceberg table, not just a Delta table exposing Iceberg-compatible reads.
  • Previously, giving external Iceberg engines access to Databricks data meant creating a Delta table and enabling UniForm (delta.universalFormat.enabledFormats = 'iceberg'), which generates Iceberg metadata alongside Delta but keeps Delta as the primary, writable format.
  • A native Iceberg table skips the dual-format shim entirely — the table is Iceberg, governed by Unity Catalog privileges like any other managed table.
  • Iceberg v3 features (e.g. deletion vectors) are configurable via TBLPROPERTIES, such as 'iceberg.enableDeletionVectors' = 'true'.

Before

-- Delta table with UniForm enabled for Iceberg-compatible external reads
CREATE TABLE analytics.sales.orders (
    order_id BIGINT,
    order_total DECIMAL(10,2)
)
TBLPROPERTIES (
    'delta.columnMapping.mode' = 'id',
    'delta.enableIcebergCompatV2' = 'true',
    'delta.universalFormat.enabledFormats' = 'iceberg'
);
-- Table is still fundamentally Delta; Iceberg readers get a
-- generated, read-oriented metadata layer alongside it.

After

-- Natively managed Iceberg table in Unity Catalog
CREATE TABLE analytics.sales.orders (
    order_id BIGINT,
    order_total DECIMAL(10,2)
)
USING iceberg
TBLPROPERTIES (
    'iceberg.enableDeletionVectors' = 'true'
);
-- No Delta layer underneath — this is Iceberg end to end,
-- governed directly by Unity Catalog.

Why it matters

UniForm was always a compatibility bridge — useful, but a workaround. Teams standardizing on Iceberg (for a multi-engine lakehouse where Snowflake, Trino, or other engines read the same tables) no longer need to maintain a Delta table just to get there; the table can be Iceberg natively while still getting Unity Catalog's governance, lineage, and access control.

CLASSIFY_TEXT Is Being Replaced by AI_CLASSIFY

What changed

  • AI_CLASSIFY is the GA replacement for the legacy SNOWFLAKE.CORTEX.CLASSIFY_TEXT function; Snowflake has stated CLASSIFY_TEXT will be deprecated by the end of 2026.
  • AI_CLASSIFY supports both single-label (default) and multi-label classification via an output_mode option — CLASSIFY_TEXT only ever returned one label.
  • An optional task_description (50 words or fewer) can be passed to give the model context about the classification task, improving accuracy on ambiguous inputs.
  • AI_CLASSIFY is one of several functions renamed under Snowflake's new AI_ prefix convention — AI_EXTRACT replaces the older EXTRACT_ANSWER the same way.
  • Categories still need 2–100 unique, case-sensitive entries in both the old and new function — that constraint didn't change.

Before

SELECT
    feedback_id,
    feedback_text,
    SNOWFLAKE.CORTEX.CLASSIFY_TEXT(
        feedback_text,
        ['Product', 'Customer Service', 'Delivery', 'Price']
    ):label::STRING AS feedback_category
FROM customer.feedback;

After

SELECT
    feedback_id,
    feedback_text,
    AI_CLASSIFY(
        feedback_text,
        ['Product', 'Customer Service', 'Delivery', 'Price'],
        {
            'task_description': 'Classify support feedback by the main topic the customer is raising'
        }
    ):labels[0]::STRING AS feedback_category
FROM customer.feedback;

Why it matters

Beyond just avoiding a deprecated function, AI_CLASSIFY's task_description gives the model context CLASSIFY_TEXT never accepted, which matters most on ambiguous tickets ("the box arrived late and damaged" — Delivery or Product?). And because output_mode can flip to 'multi', the same call can tag a ticket with several relevant categories instead of forcing a single label.

Sources