Взломайте свой путь к мастерству LookML, следуя этим советам

Looker — один из моих любимых инструментов бизнес-аналитики. С тех пор, как он был приобретен Google в 2019 году, он стал частью облачной платформы Google (GCP), и его функциональные возможности становятся все более и более практичными. В этой статье я поделюсь своими советами по улучшению вашего кода LookML. навыки.

1. Создавайте только абсолютно необходимые измерения и меры

Looker — это инструмент самообслуживания, хотя задача разработчика LookML — определить, какие показатели (параметры и меры) важны для их коллег, особенно если данные (таблица из источника данных) велики.

Всегда спрашивайте себя: «Это измерение (или показатель) необходимо?», «Появляется ли оно где-то еще?»

Два ключевых преимущества разумного выбора параметров:

• Экономит время. Я получаю множество запутанных отзывов от внутренних пользователей, когда поля появляются несколько раз в одном исследовании (то есть в одном и том же представлении).
• Экономия затрат. У людей есть разные способы добиться одинаковых результатов. А использование одного и того же параметра в разных представлениях стоит гораздо дороже.

Например, у меня есть 2 таблицы snapshot_user и user_daily. Snapshot_user описывает всю информацию о пользователе в последнее время (сегодня), а user_daily описывает всю информацию о пользователе на дневном уровне (пример: тот же пользователь A потратил 20 долларов США в понедельник , 30 долларов США во вторник, 40 долларов США в среду).

Однако в обоих представлениях есть имя пользователя и его DOB (дата рождения). Произойдет другой запрос (предположим, что PII не является фактором в моем примере):

ВЫБРАТЬ user_name, user_dob FROM snapshot_user

В то время как кто-то может получить тот же результат с более высокой стоимостью запроса

ВЫБЕРИТЕ user.user_name, user_daily.user_dob

ОТ пользователя snapshot_user КАК пользователь

ВЛЕВО ПРИСОЕДИНЯЙТЕСЬ к user_daily, ИСПОЛЬЗУЯ (user_id)

2. Структурируйте представление и модели

После нескольких лет написания кода LookML я всегда советую своей команде один совет: когда мы создаем большое представление (скажем, более 50 измерений и мер), хорошо структурировать свое представление с самого начала.

Пример: структура представления заявителя

• Когда другие разработчики читают ваш код, становится легче просмотреть, что находится внутри общего представления.
• С другой стороны, разработчикам также проще искать определенные параметры или меры в ключевой части. Предположим, я хочу проверить только 03. Applicant Risk Assessment, то она будет отображаться только дважды в представлении (1) в начале представления — Структура представления и (2) в начале вашего кода.

3. Соблюдайте стандарты LookML и всегда используйте описания!

По той же причине, что и в предыдущих советах, согласованность и стандартность являются очень важными практиками после приведения в порядок структуры вашего представления. Лично у меня есть две настоятельные рекомендации для всех разработчиков LookML:

* Всегда имейте описания для каждого измерения и меры вашей сборки. Важно понимать ваши данные, их определение и вариант использования метрики. Даже если это очевидное имя, такое как «applicant_id», иногда идентификатор возвращается разными поставщиками и может повлиять на результаты.

* Следуйте стандартным рекомендациям Looker. Looker содержит много полезных обучающих материалов по организации файлов моделей,< /strong> именование агрегатов и параметры заказа в определениях полей. Я считаю, что это очень полезно для самостоятельной практики.

4. Процесс экспертной проверки кода

Для достижения трех описанных выше рекомендаций я бы порекомендовал команде всегда иметь хороший процесс проверки кода. Разработчики иногда могли что-то упустить. У команды инженеров-аналитиков всегда должен быть хороший контрольный список рекомендаций, основанный либо на рекомендациях Looker< /a> или из опыта.

Некоторые обязательные контрольные списки, которые я бы порекомендовал:

* Цель измерения/меры * Проверьте проверку LookML. * Как выполняется SQL — проверьте присоединение. Если иногда ваш SQL слишком сложен для определения измерения, а метрика может использоваться несколько раз, мы должны перенести ее на DBT (ссылка предлагает наилучшую практику DBT) * Описание и стиль

Выше приведена моя личная ежедневная практика создания хорошего кода LookML. Дайте мне тоже знать ваши советы

:::информация Также опубликовано здесь.

:::