Clustering stores rows with similar values close together inside a table's files, so queries that filter on those columns can skip most of the data. Platforms implement it differently: Databricks offers liquid clustering, and Snowflake offers clustering keys on top of its automatic micro-partitions.
For example, an events table with billions of rows is mostly queried by customer and by day. If its files mix all customers together, a query for one customer has to read most of them. With clustering on the customer column, rows for the same customer are written close together, each file's metadata records the range of customer values it holds, and the engine skips every file whose range cannot include the customer in the query. The same data skipping makes date filters cheap when the table is clustered by date.
On Databricks, liquid clustering is declared with CLUSTER BY on a Delta table, and its keys can be changed later without rewriting the existing data at once; Databricks recommends it over older techniques such as Z-ordering. On Snowflake, every table is stored in micro-partitions with value ranges, and a clustering key tells the service how to keep a large table ordered as data arrives, at a compute cost. In both cases, clustering helps large tables queried by a few predictable columns and does little for small ones.
Good clustering columns are ones that queries filter on and that have many distinct values; a column with only a few values is usually better as a partition or not used at all. Because clustering only changes how data is stored, a test result does not depend on it, which is why it can be tuned per platform after a pipeline is correct. See also lakehouse.
Unlike partitioning, clustering does not split the table into separate parts. Where it fits, these settings are platform-specific and belong in the platform's template, not in a general rule. See Databricks and Snowflake. It is a tuning choice rather than a modeling one, so it can be changed later without changing what the data means.