Highlightdbt Labs

dbt entities are typed join keys that link semantic models

dbt docs define entities as business concepts used as join keys—primary, unique, foreign, or natural—in the Semantic Layer.

Entities represent real-world concepts such as customers or transactions and act as join keys across semantic models in dbt’s Semantic Layer (v1.12+). Required parameters are name and type; types are primary, unique, foreign, and natural. Names must be unique within a model and may use expr; entities can also be used as dimensions.

Based on: Entities | dbt Developer Hub · dbt Labs

Highlightdbt Labs

dbt measures are column aggregations, now migrating to simple metrics

dbt documentation for measures as aggregations on model columns, with deprecation toward type: simple metrics.

Measures aggregate columns and can stand alone or feed complex metrics. Parameters include name, agg (sum, max, min, average, median, count_distinct, percentile, sum_boolean), expr, non_additive_dimension, and related fields. The new spec deprecates measures in favor of simple metrics under metrics.

Based on: Measures | dbt Developer Hub · dbt Labs

Highlightdbt Labs

MetricFlow centralizes metric specs and SQL construction in dbt

dbt intro to defining metrics with MetricFlow as the Semantic Layer component that builds SQL and enforces consistency.

MetricFlow in dbt centrally defines metrics and builds SQL from semantic models and metric specs. It aims to cut duplicative coding, support governance of company metrics, and keep consumer results consistent; defined metrics can be queried in development and, on higher plans, in downstream tools.

Based on: Build your metrics | dbt Developer Hub · dbt Labs

Highlightdbt Labs

dbt semantic models are MetricFlow graph nodes tied to DAG models

dbt docs explain semantic models as YAML-configured nodes and entities that MetricFlow uses for the Semantic Layer.

In dbt v1.12+, semantic models are the foundation for MetricFlow’s Semantic Layer: nodes linked by entities in a semantic graph, annotated on dbt models for metric use. Each DAG model maps to one semantic_model YAML block (or Apache Ossie docs); components include name, time dimension, and entities.

Based on: Semantic models | dbt Developer Hub · dbt Labs

HighlightConfluent

Confluent Schema Registry centralizes Kafka schema validate-and-evolve rules

Confluent documentation overview of Schema Registry for managing, validating, and evolving schemas on Kafka topics.

Schema Registry is a centralized store for topic message schemas and for serialize/deserialize over the network. Producers and consumers use it for consistency and compatibility as schemas change; Confluent frames it as a data-governance component covering quality, standards, lineage visibility, audit, and collaboration, on Cloud and Platform.

Based on: Schema Registry for Confluent Platform | Confluent Documentation · Confluent

HighlightGoogle Cloud

LookML puts join structure and query content in one reusable semantic model

Google Cloud docs introduce LookML as Looker’s modeling language for dimensions, aggregates, joins, and SQL generation.

LookML (Looker Modeling Language) is a dependency-style language for building semantic data models over SQL databases. Models and views define joins and calculations once; Looker generates dialect-independent SQL so analysts avoid repeating expressions and business users query without writing SQL.

Based on: Introduction to LookML | Looker | Google Cloud Documentation · Google Cloud

HighlightSnowflake

Cortex Analyst: managed text-to-SQL over Snowflake structure via REST

Snowflake docs on Cortex Analyst—an LLM feature for natural-language questions on structured data, exposed as a REST API.

Cortex Analyst is a fully managed Snowflake Cortex feature that answers business questions on structured Snowflake data in natural language without users writing SQL. It ships as a REST API for embedding in apps and aims to produce accurate text-to-SQL without teams building custom RAG stacks or managing GPUs. Snowflake recommends transitioning to Cortex Agents, which includes Analyst capabilities.

Based on: Cortex Analyst | Snowflake Documentation · Snowflake

Highlightmartinfowler.com

Data mesh: domain-owned data products instead of a central lake monolith

Zhamak Dehghani’s 2019 essay on moving from monolithic data lakes to a distributed data mesh.

Dehghani argues enterprise data lakes often fail at scale through centralization, coupled pipelines, and siloed ownership. The proposed shift treats domains as first-class, applies platform thinking for self-serve infrastructure, and treats data as a product with discoverability, addressability, trust, self-describing semantics, interoperability, and secure access.

Based on: How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh · martinfowler.com

Highlightdbt Labs

Centralize metrics in dbt so every BI tool reads the same definitions

Overview of the dbt Semantic Layer: MetricFlow-backed metrics defined once in the modeling layer for consistent downstream use.

The dbt Semantic Layer, powered by MetricFlow, lets teams define metrics on existing models, handle joins, and expose those definitions to downstream tools. Moving metrics out of BI into the modeling layer keeps business units on the same definitions; a change in dbt refreshes everywhere the metric is invoked. Access permissions control who can use it; Starter or Enterprise-tier accounts are required.

Based on: dbt Semantic Layer | dbt Developer Hub · dbt Labs

Highlightdbt Labs

dbt model contracts: build-time guarantees on column shape before consumers break

dbt Labs docs on model contracts—upfront shape guarantees verified at build, plus governance caveats and support limits.

A dbt model contract is a set of upfront guarantees on the shape of a model’s dataset. At build time dbt checks that the transformation matches the contract or fails. Governance features add trust but can harden rollbacks if adopted too early, and contracts apply only to supported SQL materializations—not Python models, ephemeral models, or several other resource types.

Based on: Model contracts | dbt Developer Hub · dbt Labs

Highlightdbt Labs

MetricFlow: YAML metrics and a semantic graph that generate the SQL

dbt Labs guide introducing MetricFlow as the engine behind the Semantic Layer for defining and querying metrics.

MetricFlow powers dbt’s Semantic Layer with opinionated abstractions for defining and managing metric logic. It builds SQL from YAML (and, from dbt v1.12, Ossie documents), linking semantic models and metrics in a semantic graph. It works with listed warehouses and dbt 1.6+, under Apache 2.0.

Based on: About MetricFlow | dbt Developer Hub · dbt Labs

Highlightmartin.kleppmann.com

Why Thrift, Protobuf, and Avro must survive schema change, not only serialize bytes

Martin Kleppmann on how teams reach schema-based binary formats and why schema evolution is the overlooked requirement.

Kleppmann traces a common path from language-native serialization to JSON to custom binary formats, then to Thrift, Protocol Buffers, or Avro for schema-driven, cross-language encoding. He argues that comparisons often skip what happens when the schema changes. All three formats support evolution so producers and consumers on different versions can still interoperate.

Based on: Schema evolution in Avro, Protocol Buffers and Thrift Martin Kleppmann's blog · martin.kleppmann.com