Scribd
Upload
23 views8 pages

Looker Side Optimization Techniques

Uploaded by

srikant.k
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
23 views8 pages

Looker Side Optimization Techniques

Uploaded by

srikant.k
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 8

Looker Side Optimization techniques

1. Persist :

This is one of the optimization techniques where there is huge data or complex
calculations and filters, if data refreshes in a day or 2. This can be helpful.

I tried giving this in explore level and first time it loads with some time but
whenever users come to this dashboard, it won't wait to load but render in
seconds.

First time load


Loaded completely:

If user reload:

Here otif details not rendered yet. Still loading


After enabling persist:
now am refreshing same dashboard,

This won’t hit DB again to fetch. But the issue here is first time load will take some
time to load and if data is updated frequently this won’t work.

2. Removing Joins
 Remove Redundant Joins: Ensure only necessary joins are included based on
the parameter conditions.
 Simplify SQL Conditions: Consolidate SQL conditions and use simpler logic
where possible.
 Use PDTs for Complex Joins: If certain joins are always needed and
computationally heavy, consider using PDTs.
On one view there are 7 Joins made in model level. As the data is huge its taking
time to load.

3. Extends replacement.
As global data is used Extends feature where another view is getting extended. i.e
all dimensions and measures also get combined with global data and huge
columns will be formed.

I tried to restrict not to use extends but tried to get from another view whatever
required. But, didn’t helped much.

If you see above screen, I have commented and tried to create dimensions getting
called vis its view name. But, didn’t worked as expected for the performance
improvement.
4. Case vs If conditional statements:

Wherever required, I tried to change from if to case conditional statements. Few


got liquid syntax error, and few didn’t effectively worked

5. Potential reasons for slow rendering: (found while surfing)

Large Datasets: The views seem to be querying a large table (dbo.@{switch})


based on various filter conditions. If this table contains a massive amount of data,
aggregating and filtering it for each visualization can be time-consuming.

Complex Calculations: The views include several calculated measures


(numerator_a, denominator_a, etc.) that involve conditional logic and potentially
nested aggregations. These calculations can add to the query processing time.

Time Dimension Logic: The way the fiscal_yr_mo dimension is determined based
on the plant_region and other parameters might lead to complex queries,
especially if there are many regions or parameter values.

View Dependencies: If the global_data view depends on other views that also
have complex logic or large datasets, it can lead to cascading slowness.

Tried below Optimization Techniques as well:

Optimize Calculations: Simplify the calculations in the views if possible. Break


down complex calculations into smaller, more manageable steps.

Explore Filters: Pre-filter the data based on user selections before performing
complex calculations. This can reduce the amount of data processed. This won't
work as we have filters separately in filter panel. Can’t fix static filters.
Indexes: Ensure proper indexes are created on the database columns used in the
LookML filters and aggregations. – This I haven’t tried as we need to fix with DB
person as well

Caching: Looker offers options for caching query results. Explore caching
strategies to improve performance for frequently accessed views.

You might also like