Hack Your Way to LookML Mastery By Following These Tips

is one of my favorite BI tools. Ever since it was acquired by Google in 2019, it has become a part of the Google Cloud Platform (GCP) and its functionalities have become more and more practical. In this article, I’m going to share my tips to sharpen your skills. Looker LookML code 1. Only build the absolute necessary dimensions and measures Looker is a self-serve tool, though it’s the LookML developer’s job to identify which metric (dimension and measures) is important to their colleagues — especially if the data (table from a data source) is big. Always ask yourself if “this dimension (or measure) is necessary?”, “Does this appear somewhere else?” Two key benefits of selecting dimensions wisely: I get many confusing feedback from internal users when fields appear multiple times in the same explore (meaning, same view). Saves time: People have different ways to get the same results. And using the same dimension in different views costs much more. Saves cost: For example, I have 2 tables and . is to describe all user’s information at the latest time (today) while is to describe all user’s information on the daily level (exp: same user A spent 20USD on Monday, 30USD on Tuesday, 40 USD on Wednesday). snapshot_user user_daily Snapshot_user user_daily However, both views have the user’s name and the user’s DOB (Date of birth). There is a different query would happen (Assuming PII is not a factor in my example): SELECT user_name, user_dob FROM snapshot_user While someone can have the same result with a higher cost of the query SELECT user.user_name, user_daily.user_dob FROM snapshot_user AS user LEFT JOIN user_daily USING (user_id) 2. Structure your View and Models After years of writing LookML code, one tip I always suggest to my team is when we build a big view (let’s say greater than 50 dimensions and measures), it’s good to structure your view from the beginning. Example: Applicant view’s structure When other developers read your code, it is easier to review what is inside the big view. On the other hand, it is also easier for developers to search for specific dimensions or measures in the key part. Assuming I only want to check , then it will only show twice in the view (1) at the beginning of the view — View structure and (2) at the beginning of your code. 03. Applicant Risk Assessment 3. Follow LookML standards and always have descriptions! Same reason as the previous tips, consistency and standard are very important practices after tidying your view structure. Personally, I have two strong recommendations for all LookML developers: Always have descriptions for every single dimension and measure of your build. It is essential to understand your data, its definition and use case of the metric. Even if it is an obvious name like “applicant_id”, sometimes, the id is returned by different providers and can impact results. Follow the standard guideline from Looker. Looker contains many great pieces of training around , and in field definitions. I believe it is very useful for self-practices. , organizing Model files naming aggregates ordering parameters 4. Peer Code Review Process To achieve the three practices above, I would recommend the team always have a good . Developers sometimes could miss things. The analytics engineer team should always have a good , either taking reference from or from . code review process guideline checklist Looker guidelines experiences Some must-have checklists I would recommend: Purpose of dimension/measures Check LookML validation How is done — check the join. If sometimes, your SQL is too complicated to define a dimension while the metric can be used multiple times, we should bring it to (the link would suggest the best DBT practice) SQL DBT Description and style Above is my personal practice daily to build a good LookML code. Let me know your tips too Also published . here