Prepare and test your skills
Prepare and test your skills
LookML (opens in a new tab) parameters are named settings that shape how business users see and query database tables in Looker. A view defines one table and the fields users can select from it, while an Explore (opens in a new tab) defines the starting point for a query and how views join together. Dimension and measure parameters inside views define the selectable fields, so adjusting these parameters controls what appears in the field picker and how results are grouped and calculated.
A dimension defines a groupable field that describes an attribute or row-level value and can be used to filter a query. Dimensions in Looker always appear in the GROUP BY clause of the SQL that Looker generates, which means they define how rows are grouped. Common dimensions correspond to a column in the underlying table, such as product name, product color, order status, user ID, or created date, and a dimension can also be a derived value computed from other fields in the same row.
Dimensions are declared inside a view file with the syntax dimension: field_name followed by settings in curly braces. The core settings are type, such as string, number, or time, and sql, which defines the SQL expression for the field. Base dimensions that read directly from a table column use sql: ${TABLE}.column_name ;;, where ${TABLE} refers to the view's table, so a table or schema change only needs an update in one place.
A measure calculates an aggregation over many rows with a SQL aggregate function, and any field computed from other measures is also a measure. Measures use types such as count, sum, avg, min, max, count_distinct, and percent_of_previous, and they appear in the SELECT clause as aggregated calculations. When users filter on a measure, that filter applies to grouped values in the HAVING clause, while dimension filters apply in the WHERE clause.
Measures are declared inside a view file with the syntax measure: field_name followed by type and sql settings. The sql setting often references an existing dimension with ${field_name}, such as sql: ${amount} ;; with type: sum to create SUM(orders.amount). Using ${field_name} instead of repeating ${TABLE}.column_name keeps one definition of the column, so a column rename only requires one update in the base dimension.
| Field | What it represents | How Looker uses it in SQL |
|---|---|---|
| Dimension | Row-level attribute for grouping and filtering, such as status or created date | Placed in SELECT and GROUP BY; filters go in WHERE |
| Measure | Aggregated calculation, such as total sale price or total items sold | Placed in SELECT as COUNT, SUM, or AVG; filters on grouped results go in HAVING |
A dimension group is a shortcut that creates multiple time-based dimensions from one date or time column at once. A single dimension_group: created definition with type: time and a list of timeframes such as date, week, month, quarter, and year exposes Created Date, Created Week, and Created Month as separate selectable fields.
An Explore provides the starting point for a query that users can run, and it serves as the FROM in SQL terms. Explores are listed in the Explore menu below the name of the model they belong to, and users build queries by selecting that Explore's dimensions and measures in the field picker. Not every view should be an Explore, because lookup views such as a States table are only useful when joined to a business entity like Orders.
Explores are declared by convention in a model file with the explore parameter, which also sets the database connection and included view files for the model. The declaration explore: orders makes Orders queryable, and nested join blocks define how other views attach to it. Each join names a view and defines its join condition with sql_on, such as sql_on: ${orders.customer_id} = ${customers.id} ;;, so Looker can automatically generate the correct LEFT JOIN logic when a query selects fields from multiple views.
Exam tip: A dimension filter limits rows before grouping, while a measure filter limits grouped results — dimensions feed WHERE and GROUP BY, measures feed aggregate calculations and HAVING.
LookML (opens in a new tab) parameters are settings in a LookML project that define the data model and control how Looker (opens in a new tab) generates SQL. Every LookML parameter alters the structure, content, or behavior of the query that Looker sends to the database. A change to a dimension, measure, or filter parameter therefore changes what fields business users see in an Explore and what rows and calculations appear in reports and dashboards.
A dimension is a groupable field that represents an attribute, fact, or value from a single row. Common dimensions include dates, names, and IDs, and they often correspond directly to columns in the underlying database table. Dimensions are defined inside a view file and appear in the field picker in an Explore, where users can select them and use them to filter a query.
In generated SQL, Looker places dimensions in the SELECT clause and in the GROUP BY clause. A dimension group is a special dimension parameter that creates multiple time-related dimensions at once from one date or time column, such as date, week, and month from a created_at column. The allow_fill parameter controls dimension fill, which fills in missing dates or values so charts do not misleadingly connect an incomplete set of points.
A measure is a field that aggregates many rows using a SQL aggregate function. Measures use functions such as:
COUNTSUMAVGMINMAXAny field calculated from other measure values is also a measure. For example, measures for a Sales view might include total items sold as a count, total sale price as a sum, and average sale price as an average.
In generated SQL, Looker places measures in the SELECT clause and filters on grouped measure values in the HAVING clause. The declared type of a measure, such as count, sum, count_distinct, or percent_of_previous, determines which aggregate Looker generates and what values users should expect.
A filter is a LookML field or expression that limits which rows are included before or after aggregation. Dimension filter expressions populate the SQL WHERE clause, while measure filter expressions populate the SQL HAVING clause. Filter expressions can be added by a user in an Explore to shape an ad hoc query, or they can be declared directly in LookML to apply to all queries from that field or Explore.
LookML also supports filter-only fields that filter Explores, Looks, and dashboards but cannot be added to a result set. The parameter field creates this kind of filter-only field for collecting user input, and the filter field supports advanced uses such as templated filters. Filter-only fields are useful when the goal is to let users narrow results without showing the filter value itself as a column.
LookML parameter syntax declares objects such as views, dimensions, measures, and dimension groups with a name and a block of settings. A view block contains its fields, and each field block sets its type and its sql expression that tells Looker how to calculate the field. For example, an orders view can declare an id dimension, a created dimension group with timeframes: [date, week], a count measure of type: count, and a total_amount measure of type: sum.
LookML uses substitution operators to connect fields to tables and to each other without repeating full column names. The syntax ${TABLE}.field_name points to a column in the underlying database table for base dimensions, so a table or schema change can be updated once in sql_table_name. The syntax ${field_name} points to an already defined LookML dimension or measure, so a column change only needs to be updated in one base field and then flows automatically to every measure that references it.
| Field kind | What it describes | Main SQL effect |
|---|---|---|
| Dimension | Row-level attribute such as product name, color, or created date | Adds a column to SELECT and GROUP BY, filters in WHERE |
| Measure | Aggregation such as count, sum, or average | Adds an aggregate to SELECT, filters in HAVING |
| Filter | Limit on rows or grouped values, including filter-only input | Adds conditions to WHERE or HAVING without always adding a column |
The flow from LookML to SQL builds every query from a fixed set of components drawn from the LookML project. The model selects the target database, the explore supplies the SQL FROM, the chosen dimensions and measures supply the SELECT, filters supply WHERE and HAVING, and the sort choice supplies ORDER BY. Joins between views are encoded in the model, so Looker adds a LEFT JOIN only when the selected fields require that view.
A left-to-right process flow showing how model, explore, fields, and filters map to FROM, SELECT, WHERE, GROUP BY, HAVING and ORDER BY in generated SQL.
Because of this flow from LookML to SQL, a small parameter edit changes both the query and the user experience. Renaming a label or description changes what appears in the field picker, changing a type or sql expression changes the calculation and formatting in the results, and adding a filter changes which rows are returned. Users can inspect the result in an Explore by opening the SQL tab in the Data panel to see the exact SELECT, JOIN, WHERE, GROUP BY, and HAVING clauses that Looker sent to the database.
Exam tip: Dimension filters limit individual rows in WHERE and dimensions group rows in GROUP BY, while measure filters limit grouped results in HAVING.
Optimize Field Presentation and Organization means using LookML parameters on dimensions and measures to control how fields look in tables and visualizations and how fields are organized in the field picker. Presentation parameters do not change the underlying data, they change the name users see, the guidance users get, and the format of the displayed value. In Looker, value_format and value_format_name control numeric display, while label, description, and grouping controls make the field list clearer for business users.
value_format (opens in a new tab) is the LookML parameter that formats the output of a type: number field using Excel-style options. A developer adds the format string to a dimension or measure, and Looker renders the stored value in that format in data tables and visualizations. For example, a measure total_order_amount with value_format: "$#,##0.00" renders a value such as 1234 as $1,234.00.
value_format_name is the related parameter that applies a built-in or custom named_value_format instead of writing the Excel-style string directly. A developer sets value_format_name: usd on a type: sum measure, and Looker applies the formatting defined by that named format. The choice depends on reuse: use value_format for a one-time format on one field, and use value_format_name when the same named format should be shared across fields.
| Format option | How the format is defined | Example use |
|---|---|---|
| value_format | Excel-style format string written in the field | value_format: "$#,##0.00" on total_order_amount |
| value_format_name | Name of a built-in or custom named_value_format | value_format_name: usd on total_order_amount |
Exam tip: value_format and value_format_name have no effect on fields that are not type: number.
A label is the presentation parameter that controls the friendly name users see for a field in Explores, visualizations, and deliveries. By default Looker builds a field name from the view and field name, but a custom label replaces that text with business language. Custom labels for each column can also be set in table chart visualization options, and the Show Full Field Name option controls whether the view name appears with the field name.
Labels flow from the model to the output destination. When Apply visualization options (opens in a new tab) is selected for a data delivery, the delivery appears similar to a table chart and includes the configured custom labels. When Apply visualization options is unselected, Looker sends the data as it appears in the Data section of the Look or dashboard tile. The JSON — Detail, Inline format always uses raw field names, not the field label, while JSON — Label uses the field label even when Apply visualization options is unselected.
Field descriptions and field groups help end-users choose the correct dimension or measure in the field picker. A description adds an annotation to an individual field that explains what the field means or when to use it. A group label places related fields under a shared group heading, so fields from the same business area stay together instead of appearing as one long list.
Descriptions and groups work together with labels and value formatting. The label gives the field a readable name, the description gives contextual guidance behind that name, the group gives the field a place in the picker, and value_format ensures the values look correct after the user selects the field. Together these parameters keep the model organized for developers and readable for business users.
SELECT and GROUP BY with filters in WHERE, while measures appear as aggregates in SELECT with filters in HAVING.FROM, and Looker adds a LEFT JOIN defined by sql_on only when selected fields require the joined view.${TABLE}.column_name points to a database column and ${field_name} reuses a defined LookML field so column changes require one update.value_format and value_format_name only affect type: number fields, with value_format for one-time formats and value_format_name for shared named formats.A LookML dimension is a row-level attribute for grouping and filtering that Looker places in the SELECT and GROUP BY clauses with filters in the WHERE clause, while a LookML measure is an aggregated calculation that Looker places in the SELECT clause as an aggregate such as COUNT, SUM or AVG with filters on grouped values in the HAVING clause. Any field calculated from other measure values is also a measure.
Use value_format for a one-time Excel-style format on one type number field and use value_format_name when the same built-in or custom named format should be shared across fields. Both parameters only affect type number fields and control how values render in data tables and visualizations.
A LookML dimension group is a shortcut that creates multiple time-based dimensions from one date or time column at once. A single definition with type time and a list of timeframes such as date, week, month, quarter and year exposes separate selectable fields such as Created Date, Created Week and Created Month.
A LookML Explore provides the starting point for a query that users can run and serves as the FROM in SQL terms, with Explores listed in the Explore menu below the name of the model they belong to. Each join names a view and defines its join condition with sql_on so Looker can automatically generate the correct LEFT JOIN logic only when the selected fields require the joined view.
A Looker developer is updating an e-commerce view file (order_items.view) to improve data discovery and report readability for business users. The team has outlined the following four requirements:
shipping_city, shipping_state, and shipping_zip) together inside a single collapsible drop-down folder within the view in the field picker.total_revenue measure so users see an explanatory definition when hovering over its information icon in the field picker.total_revenue measure in data tables and visualizations to appear as currency (for example, $1,250.00).usr_id to Customer ID without altering how the field is referenced in LookML models.Which group of LookML parameters should the developer apply to satisfy all four requirements?
Last updated