Введение

todo

Подходы контроля правильной работы ETL-скрипта. Best Practices Qlik Sense Development

Контроль количества строк при операциях Left Join

//=============================================================
//КОНТРОЛЬ КОЛИЧЕСТВА ПРОВОДОК ДО И ПОСЛЕ JOIN
//=============================================================

Let пЗаписейВфактахДо=NoOfRows('Факты');
TRACE $(пЗаписейВфактахДо);


     //..... Здесь подряд делается несколько различного типа JOIN


Let пЗаписейВфактахПосле=NoOfRows('Факты');
TRACE $(пЗаписейВфактахПосле);
IF $(пЗаписейВфактахПосле)<>$(пЗаписейВфактахДо) THEN

     //------- Генерим ошибку, чтобы остановить выполнени скрипта
     CALL FunctionNotExist111_ThrowError('Принудительная остановка скрипта. Количество строк изменилось.');
 
ENDIF

Контроль полноты данных

Для контроля полноты данных следите за:

  • Количество записей
  • Контрольная сумма по мере
  • Статистические таблицы

Рекомендации по организации ETL-процесса и управлению скриптами

Комментарии в скрипте

1. Наличие в коде больших кусков закомментированного кода – это плохо

Планируйте инфраструктуру Qlik Sense окружения таким образом, чтобы Ваши скрипты либо автоматически бекапировались и фиксировались все вносимые изменения, либо скрипты подключайте через Must_Include, а текстовые файлы контролируйте через Git Tools.

Про разработку скриптов через файлы можно почитать тут:

Следствием такого подхода должно стать отсутствие закомментированного кода в скриптах. Где-то я видел фразу, что большие куски закомментированного кода оставляют разработчики, у которых мало опыта. В чем-то я с этой фразой согласен. Считаю, что нужно в компании вести базу знаний, в которую заносить большие куски кода для обсуждения (это может быть как Mediawiki, так и WordPress – все бесплатно и просто в обслуживании).

За все время работы я практически никогда не смотрел закомментированный код, но очень часто обращаюсь к библиотеке скриптов с ранее созданными техническими решениями. Напрашивается вывод: для эффективной разработки и поддержки нужна библиотека знаний/скриптов, а большие закомментированные куски кода в рабочем ETL не нужны. На стадии разработки допускается комментирование скрипта, а вот в production лучше не выносить эти куски.

А код должен быть максимально удобным для обслуживания. К сожалению к этому приходишь не сразу.

2. Многострочный комментарий /* */ лучше заменять одиночным, т.к. это упрощает отладку

Стремитесь не использовать многострочные комментарии, т.к. при отладке, можно перекрыть одним многострочным комментарием другой многострочный комментарий.

3. Код должен иметь исчерпывающее количество комментариев.

Комментарии должны носить техническое описание, также можно написать обоснование, почему было принято то или иное решение.

Особенно это касается таких вопросов, как расчет себестоимости, аллокации расходов и т.п. Т.к. не всегда принятые решения закрывают все проблемы (логические, технические и т.п.), иногда приходится выбирать меньшее из двух зол, оставляя маленькую щелочку, к которой в дальнейшем нужно прийти и её исправить.

Сначала – проектирование, потом – разработка

Еще есть такая штука, как технический долг (это и неправильно написанный код, “грязный” код, неправильные архитектурные решения, отсутствие четких Бизнес-Процессов разработки, отсутствие документации и т.д.), которые выливаются в конечном итоге в торможении и усложнении процесса развития аналитической системы. В какой-то момент Вам придется сесть и начать все структурировать, систематизировать, чистить промышленное окружения от излишних объектов, чистить код и т.д.

Грязный код, как источник технического долга

🙂

Управление техническим долгом

  • Предотвращаем (Инженерные практики; Критерии готовности DoD; Обмен знаниями)
  • Делаем видимым
    • Технический бэклог
    • Приоритеты (Размер при непогашении; Цена досрочного погашения; Частота “платежей”; Бизнес ценность и стратегическое влияние)
  • Обслуживаем непрерывно (правило бойскаута “Оставь место стоянки чище, чем оно было до твоего прихода”)

Qlik Best Practice – Scripting In Qlik Sense

  • Комментарии к коду должны проставляться в разделах скрипта там, где производится преобразование данных, чтобы понять, почему код был написан именно таким образом. Это не означает, что Вам нужно писать комментарий для каждой строки кода. Старайтесь кратко и конкретно описывать суть кода и шагов трансформации данных.
  • Всегда, всегда и еще раз – ВСЕГДА оборачивайте ключевые поля функцией text() при выгрузке из базы данных. Много раз сталкивался на практике, когда выгружается ключ и часть ключа декодируется как число (часть ключа изменяется и перестает соответствовать первоисточнику). Даже если Вы выгружаете GUID ключи из 1С 8.3, то все равно оборачивайте эти ключи в text().
  • Скрипт разбивается на разделы. В каждом разделе производятся преобразования для 1 таблицы или 1 файла QVD. Размещать весь скрипт в 1 разделе не рекомендуется.
  • В разделе Main размещайте только переменный для конфигурации приложения, глобальные переменные. Не размещайте скрипт загрузки/трансформации в этом разделе.
  • В приложении для ETL установите параметр CreateSearchIndex в 0 в разделе Main. Это позволит избежать создание поискового индекса, что положительно скажется на времени перезагрузки. Поисковые индексы не требуются, если приложение не используется для анализа данных.
  • Для работы с датой создавайте отдельную таблицу – Календарь, в которой находятся разные атрибуты для работы с периодами (например, дата, недели, кварталы, месяца, года и т.п.). Календарь связывается с таблицей фактов через ключевое поле Дата (обычно это дата, но можно и другие поля сделать). Этот подход позволит пользователям фильтровать данные по любым интересующим их периодам. Также можно создать отдельные флаги для фильтрации часто используемых диапазонов дат, например, «Скользящие 12 месяцев», «Текущий год», «Предыдущий год», «Скользящие 4 недели» и т.д.
  • Избегайте WHERE условий при загрузке данных из QVD-файлов. WHERE условия сбивают оптимизированную загрузку (сюда не входит WHERE NOT EXISTS). Там, где это возможно и целесообразно, следует создавать отдельное ограниченное QVD с ограниченным набором данных или использовать другие методы фильтрации, такие как left/inner join с другой таблицей или использование WHERE EXISTS (через отдельное поле-фильтр, которое можно заполнить через LOAD * INLINE).
  • Для работы в команде рекомендуется разработать и согласовать стандарт по написанию кода: добавление комментариев, отступы, соглашения по наименованию переменных, таблиц, меппингов, функций, глобальных переменных, использование апострофов, квадратных скобок для полей и таблиц с пробелами в названии, разработайте шаблон скрипта загрузки, использование регистра Camel Case и т.д.
  • Используйте только синтаксис сценария Qlik и избегайте сторонних библиотек / операторов include, если они не обеспечивают значительного улучшения производительности приложения или времени разработки. Внешний код может вызвать эффект «черного ящика», когда разработчики не имеют четкого понимания того, что делает внешний код. Точно так же поддержание сценария вне Qlik может стать головной болью (скрипт во всех приложениях должен быть унифицирован, если где-то вставить include, то поиск по скрипту не даст результатов и разработчик может долго бродить по кругу в поисках нужного места).
  • При использовании запросов SQL рассмотрите возможность использования (WITH NOLOCK), это предотвращает ожидание запроса для при блокировке записей. Неиспользование (WITH NO LOCK) может привести к тому, что перезагрузка займет значительно больше времени или, возможно, истечет время ожидания и работа скрипта завершится с ошибкой.
  • Скрыть поля, которые не применимы для анализа, например составные поля (ключи), которые используются только для модели данных. Скрытие полей реализуется с помощью hidePrefix/hideSuffix.
  • Точно так же следует исключить поля, которые не используются для фильтрации в интеллектуальном поиске. Для этого используется оператор EXCLUDE. Преимущество исключения ненужных полей заключается в том, что оно уменьшает количество полей для поиска и исключает неприемлемые результаты из поиска. Таким образом, обеспечивая более быстрый поиск.
  • Системные переменные в разных приложениях Extract, Transform и App должны быть настроены одинаково (про переменные в разделе Main).
  • Единый принцип написания названий полей и переменных.
  • Единый принцип написания названий полей и переменных.
  • Используйте TRACE перед значительными участками кода, в том числе вначале каждого раздела скрипта – поможет в локализации проблем.
  • Удаляем лишний, не используемый код.
  • Очищаем переменные, которые нам не нужны в самом приложении LET Переменная = NULL().
  • Используйте комментарии к полям, комментарии к таблицам (формируется через commetn fields, comment tables using map_tables).
  • Используйте теги к полям ($dimension, $measure, $hidden).
5 1 голос
Рейтинг статьи

Подписаться
Уведомление о
guest
0 комментариев
Встроенная Обратная Связь
Просмотр всех комментариев
0
Оставьте, пожалуйста, комментарий!x