Filters
The Filters tab allows you to define data perspectives on the connected data sources of a Custom Model. While the Data Sources tab determines which data sources are connected, the Filters tab determines which part of each data source is exposed to this model and its users.
This is the second layer of filtering in Lakehousecat's two-layer architecture:
| Layer | Where | What it controls |
|---|---|---|
| Layer 1 – Data Source Filters | Data Source editor | Which data is physically loaded into ClickHouse |
| Layer 2 – Custom Model Filters | Custom Model Filters tab | Which subset of the loaded data this model exposes as a logical view |
Custom Model filters are implemented as ClickHouse VIEWs. They do not copy or reload data — they create a logical slice of the already-loaded data at query time. This means you can create multiple Custom Models with different filters over the same data source without any additional storage cost or reload.
Why Use Custom Model Filters
Use filters on a Custom Model to:
- Create role-based perspectives — one data source can be the foundation for multiple models, each scoped to a different audience (e.g., Sales Team, Finance Team, Executive View)
- Restrict sensitive data — hide tables or columns that should not be visible to a given group of users
- Apply row-level data restrictions — limit query results to a specific tenant, region, status, or time window
Custom Model filters define what data users can access when they query this model. Sharing a model = granting access to all data it exposes. Configure filters carefully before sharing.
Selecting a Data Source to Filter
The Filters tab shows a dropdown of all data sources connected to this Custom Model. Select a data source to configure its filters. A dot indicator (●) appears next to data sources that already have filters configured.
If no data sources appear, go to the Data Sources tab first and connect at least one data source.
Filter Sections
Custom Model filters operate on the semantic views of the connected data source (not the raw database tables). After picking a data source, the tab loads its generated semantic views, grouped by view type:
- entity — dimension views (e.g.
entity_customer,entity_store). - metrics / joined_metrics — measure/fact views. When a timeline data source is linked,
the metrics views are exposed as
joined_metrics_*; both are listed and filterable.
Star views are not listed here: they are generated outputs of the model build, derived from the entity and metrics views you select. You shape the star views indirectly by choosing which input views and columns flow into the model.
View Type Filter
Include or exclude whole view types (entity / metrics / joined_metrics). Selecting a type in Include mirrors only views of that type into the model; Exclude drops that type.
View Selection
Choose which individual views are mirrored into the model. Check views under Include Views (whitelist) or Exclude Views (blacklist).
Column Selections
Per-view column filtering. Pick a view, then choose which columns to include (whitelist) or exclude (blacklist). This is how you hide a specific dimension or measure column — excluded columns disappear from the views (and therefore from the generated star views) on the next Update Semantic Model.
Column Row-Level Filters
Add row-level restrictions equivalent to a WHERE clause. Each filter targets a specific view,
column, comparison operator, and value.
Examples:
tenant_id EQUALS acme— restricts all queries to data belonging to a specific tenantregion EQUALS EMEA— scopes the model to European data onlystatus EQUALS active— excludes archived or inactive records
Saving and Clearing Filters
- Save — applies the current filter configuration for the selected data source.
- Clear Filters — removes all filters for the selected data source, making the full dataset visible again.
Each data source is saved independently. You can configure different filters for each connected data source.
Effect on the Semantic Layer
Custom Model filters take effect at query time — they do not require re-running semantic extraction at the data source level. However, after saving or changing filters, run Update Semantic Model from the Operations tab to regenerate the semantic layer to reflect the new data perspective.
Column filters and existing charts. Whether a column excluded by a filter actually disappears after Update Semantic Model depends on whether the model already has charts or dashboards attached:
- No charts attached yet (development phase) — the semantic layer rebuilds freely. Excluded columns are dropped as expected.
- Charts or dashboards already attached — a do-no-harm safeguard keeps the existing semantic structure unchanged instead of dropping the column, so live charts do not silently break. In this case, apply the filter change on a cloned copy of the model instead — the clone has no charts attached, so the rebuild applies the drop, and you can then move users to the updated clone.
This is independent of the Locked toggle: a locked model skips semantic rebuilds entirely, while an unlocked-but-shared model is still protected as soon as it has dependents.
Best Practices
- Define filters before running Create Semantic Model so the semantic layer reflects the filtered view from the start.
- Use Column Row-Level Filters for multi-tenant scenarios — one data source, many models, each scoped to its tenant.
- Lock the model after finalizing filters in a production environment to prevent accidental changes.
- Validate the model by testing queries as an end user before sharing.