A Looker LookML Developer works with datasets and LookML and is familiar with SQL and BI tools. LookML Developers are proficient in model management, including troubleshooting existing model errors, implementing data security requirements, creating LookML objects, and maintaining LookML project health. LookML Developers design new LookML dimensions and measures and build Explores for users to answer business questions. LookML developers are skilled at quality management, from implementing version control to assessing code quality to utilizing SQL runner for data validation.

The Google LookMLand Looker business course addresses the following topics:

Section 1: Model management

1.1 Troubleshoot errors in existing data models. For example:

a. Determine error sources

b. Apply procedural concepts to resolve errors

1.2 Apply procedural concepts to implement data security requirements. For example:

a. Implement permissions for users

b. Decide which Looker features to use to implement data security (e.g., access filters, field-level access controls, row-level access controls)

1.3 Analyze data models and business requirements to create LookML objects. For example:

a. Determine which views and tables to use

b. Determine how to join views into Explores

c. Build project-based needs (e.g., data sources, replication, mock reports provided by clients)

1.4 Maintain the health of LookML projects in a given scenario. For example:

a. Ensure existing contents are working (e.g., use Content Validator, audit, search for errors)

b. Resolve errors

Section 2: Customization

2.1 Design new LookML dimensions or measures with given requirements. For example:

a. Translate business requirements (specific metrics) into the appropriate LookML structures (e.g., dimensions, measures, and derived tables)

b. Modify existing project structure to account for new reporting needs

c. Construct SQL statements to use with new dimensions and measures

2.2 Build Explores for users to answer business questions. For example:

a. Analyze business requirements and determine LookML code implementation to meet requirements (e.g., models, views, join structures)

b. Determine which additional features to use to refine data (e.g., sql_always_where, always_filter, only showing certain fields using hidden: fields:, etc.)

Section 3: Optimization

3.1 Apply procedural concepts to optimize queries and reports for performance. For example:

a. Determine which solution to use based on performance implications (e.g., Explores, merged results, derived tables)

b. Apply procedural concepts to evaluate the performance of queries and reports

c. Determine which methodology to use based on the query and reports performance sources (e.g., A/B testing, SQL principles)

3.2 Apply procedural concepts to implement persistent derived tables and caching policies based on requirements. For example:

a. Determine appropriate caching settings based on data warehouse’s update frequency (e.g., hourly, weekly, based on ETL completion)

b. Determine when to use persistent derived tables based on runtime and complexity of Explore queries, and on users’ needs

c. Determine appropriate solutions for improving data availability (e.g., caching query data, persisting tables, combination solutions)

Section 4: Quality

4.1 Implement version control based on given requirements. For example:

a. Determine appropriate setup for Git branches (e.g., shared branches, pull from remote production)

b. Reconcile merge conflicts with other developer branches (e.g., manage multiple users)

c. Validate the pull request process

4.2 Assess code quality. For example:

a. Resolve validation errors and warnings

b. Utilize features to increase usability (e.g., descriptions, labels, group labels)

c. Use appropriate coding for project files (e.g., one view per file)

4.3 Utilize SQL Runner for data validation in a given scenario. For example:

a. Determine why specific queries return results by looking at the generated SQL in SQL Runner

b. Resolve inconsistencies found in the system or analysis (e.g., different results than expected, non-unique primary keys)

c. Optimize SQLs for cost or efficiency based on business requirements