Как мы сократили время выполнения в Alteryx с 6 часов до 9 минут с помощью dbt и Snowflake

Alteryx — это платформа визуальной трансформации данных с удобным интерфейсом и инструментами перетаскивания. Тем не менее, Alteryx может испытывать трудности с увеличением сложности в рамках конвейера данных организации и может стать неоптимальным инструментом, когда компании начинают работать с большими и сложными преобразованиями данных. В таких случаях переход на dbt может быть естественным шагом, поскольку dbt предназначен для управления сложными конвейерами преобразования данных более масштабируемым, эффективным и явным образом. Также этот переход включал миграцию с локального SQL Server на облачные вычисления Snowflake. В этой статье мы описываем различия между Alteryx и dbt и как мы сократили время выполнения клиента в Alteryx с 6 часов до 9 минут с помощью dbt и Snowflake в Indicium Tech.

Введение

Преобразование данных в соответствии с бизнес-правилами может быть сложной задачей, особенно с увеличением объема данных, собираемых компаниями. Чтобы уменьшить такую сложность, решения для преобразования данных, разработанные как инструменты перетаскивания, могут рассматриваться как более интуитивные, поскольку аналитики могут визуализировать шаги, предпринимаемые для преобразования данных. Примером популярного инструмента преобразования с перетаскиванием является Alteryx, который позволяет бизнес-аналитикам преобразовывать данные, перетаскивая операторы на холсте. Графический интерфейс Alteryx Designer представлен на Рисунке 1.

Рисунок 1 — Интерфейс рабочего процесса Alteryx Designer

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

Эта статья описывает наш опыт миграции рабочего процесса данных крупного клиента из Alteryx в dbt в течение трех месяцев. После рефакторинга моделей время выполнения модели было сокращено с 6 часов до 9 минут в dbt, с более четкой родословной моделей и лучшей документацией и контролем версий.

Для этого мы:

• Определили, какие модели будут приоритетными вместе с командой клиента,
• Определили, какой подход будет использоваться для рефакторинга рабочих процессов Alteryx в модели dbt,
• Провели аудит рефакторированных моделей, чтобы убедиться, что они соответствуют выходным данным из оригинального рабочего процесса Alteryx, и
• Заменили источники данных клиентов на рефакторированные модели dbt.

Мы надеемся, что наш опыт будет полезен аналитическим инженерам, которые ищут высокоуровневую структуру, чтобы помочь в переходе от рабочих процессов Alteryx к dbt, и что это поможет им увидеть общую картину в рефакторинге моделей.

Для кого не предназначен этот пост?

Хотя мы считаем, что dbt является лучшим инструментом преобразования, чем Alteryx для большинства случаев использования, мы признаем, что миграция из Alteryx в dbt не подходит для всех. Alteryx разработан для аналитиков данных, но его возможности хорошо подходят для бизнес-пользователей, включая маркетинг, продажи, бухгалтерию и HR. Alteryx может быть достаточно хорошим инструментом, когда:

• У вас небольшое количество преобразований
• Преобразования относительно просты
• Преобразования не нужно выполнять часто
• Вы хотите, чтобы этот процесс управлялся нетехническими пользователями

Сосредоточившись больше на видимости конвейера данных и более дружественном пользовательском интерфейсе, Alteryx превосходит при работе с меньшими, более понятными потоками данных, где аналитический инженер (AE) может действительно визуализировать, как данные преобразуются от источника до каждого выхода.

Когда дело доходит до обработки сложных структур данных, dbt имеет несколько функций, которые делают его превосходящим Alteryx. Как мы увидим далее с более подробной информацией, в контексте перехода стека данных, когда длинные и сложные потоки данных являются обычным явлением, dbt часто быстрее, чем Alteryx. Это происходит по нескольким причинам (Таблица 2):

Аспект	dbt	Alteryx
Опыт разработки	Интерфейс командной строки и IDE	Графический пользовательский интерфейс
Цель	Разработан для преобразования и моделирования данных	Возможности манипуляции и анализа данных
Оптимизация	Использует возможности оптимизации запросов	Не использует повторно тот же источник, который уже был выполнен моделью, и запускает его снова
Логика выполнения	Обрабатывает только измененные данные для больших наборов данных (инкрементальный запуск)	Обрабатывает все данные каждый раз, когда он запускается

Таблица 2 — Высокоуровневое сравнение между dbt и Alteryx

Пошаговое руководство по переносу рабочих процессов Alteryx в модели dbt

Описание случая

Этот блог-пост описывает консалтинговый проект для крупного клиента в Indicium Tech®, который останется анонимным. Клиент — это глобальная технологическая компания, специализирующаяся на предоставлении решений для управления корпоративным контентом и автоматизации. Несколько программных продуктов для аналитики данных были внедрены организацией для хранения и анализа данных. Поскольку этап преобразования данных не сосредоточен в одном программном обеспечении, анализ и преобразование данных со временем стали все более сложными и дорогими. Особенно потому, что компания приобрела множество инструментов для преобразования данных (таких как Alteryx, Tableau Prep, Power BI и хранимые процедуры SQL Server), которые использовались в разных командах. Это затрудняло наличие единого источника правды и централизованной платформы преобразования данных.

Когда клиент нанял Indicium, у них было десятки рабочих процессов Alteryx, построенных и выполняемых ежедневно исключительно для маркетинговой команды, которая была в центре внимания проекта. Для маркетинговой команды рабочие процессы Alteryx должны были выполняться в правильном порядке, так как они были взаимозависимы, что означает, что один рабочий процесс Alteryx использовал результат предыдущего, и так далее. Основные рабочие процессы Alteryx, выполняемые ежедневно маркетинговой командой, занимали около 6 часов. Еще один важный аспект, который нужно было учитывать, заключался в том, что если модель не завершила выполнение, когда следующая модель начала выполняться, данные были бы неполными, требуя повторного запуска рабочего процесса. Выполнение всех моделей обычно планировалось на ночь и раннее утро, чтобы данные были актуальными на следующий день. Но если накануне вечером произошла ошибка, данные были бы неверными или устаревшими. Рисунок 3 иллюстрирует планировщик.

Рисунок 3 — Пример рабочего процесса планировщика Alteryx

Происхождение данных было аспектом, который добавлял много дополнительной работы, потому что было трудно определить, какие модели зависели от других при таком количестве построенных рабочих процессов Alteryx. Когда количество рабочих процессов увеличивалось, требовалось много времени, чтобы создать представление этой родословной в другом программном обеспечении. Таким образом, если имя столбца изменялось в модели из-за изменения в источнике модели, аналитики по маркетингу должны были бы сопоставить, какие модели ниже по потоку были затронуты таким изменением, чтобы внести необходимые корректировки. Поскольку родословная модели была сопоставлена вручную, было сложно поддерживать ее в актуальном состоянии.

Одной из наших основных задач было рефакторинг рабочих процессов Alteryx, которые маркетинговая команда использовала каждый день. Как вы уже могли догадаться, этот рефакторинг был выполнен путем создания моделей в dbt. Конструкция и описание того, как был выполнен этот рефакторинг, представлены далее.

Как мы рефакторили (пошаговое руководство на основе нашего опыта)

Ниже мы предоставляем высокоуровневую структуру с шагами, которые мы следовали для рефакторинга рабочих процессов Alteryx в dbt:

Рисунок 4 — Шаги, выполненные для рефакторинга моделей Alteryx в dbt

Шаг 1: Начните с рефакторинга меньших рабочих процессов Alteryx, а затем переходите к более сложным

Понимание того, с чего начать процесс рефакторинга, очень важно, так как это напрямую влияет на восприятие клиентом ценности доставки. Для некоторых клиентов может быть лучше начать с небольших моделей, чтобы понять лучший подход к рефакторингу моделей. Начало с более коротких и менее сложных рабочих процессов Alteryx может быть способом создания доказательства концепции и получения небольших/быстрых побед. Также этот подход может быть использован для предоставления доказательств превосходной производительности dbt для скептически настроенных клиентов.

С другой стороны, некоторые клиенты могут предпочесть начать с самых важных или наиболее используемых моделей, чтобы основные отчеты бизнес-аналитики работали на dbt как можно скорее. Хотя этот подход позволяет достичь большей ценности, вероятно, потребуется больше времени для рефакторинга этих рабочих процессов из-за их сложности преобразований и шагов, вовлеченных в рабочий процесс.

Мы приняли смешанный подход, начав с одного или двух более простых рабочих процессов, чтобы получить опыт и уверенность в процессе рефакторинга, а затем перейдя к рефакторингу самых важных рабочих процессов клиента. Этот подход обеспечивает отличный баланс между временем и доставкой ценности.

Шаг 2: Определите исходные модели и рефакторите Alteryx слева направо

Первый шаг — это проверить все источники данных и создать одно общее выражение таблицы (CTE) для каждого источника, упомянутого в конкретном рабочем процессе Alteryx, который рефакторится, чтобы его было легко повторно использовать в модели.

Важно нажать на каждый источник данных (зеленые значки книг на самой левой стороне Рисунка 5) и проверить, были ли выполнены какие-либо преобразования внутри этого запроса источника данных. Очень часто значок источника содержит более одного источника данных или фильтра, поэтому этот шаг важен. Следующий шаг — следовать за рабочим процессом и транскрибировать преобразования в SQL-запросы в моделях dbt, чтобы воспроизвести те же преобразования данных, что и в рабочем процессе Alteryx.

Рисунок 5 — Рабочий процесс Alteryx

На этом этапе мы определили, какие операторы использовались в источнике данных (например, объединение данных, упорядочивание столбцов, группировка и т.д.). Обычно операторы Alteryx довольно понятны, и вся необходимая информация для понимания отображается на левой стороне меню. Мы также проверили документацию, чтобы понять, как каждый оператор Alteryx работает за кулисами.

Мы следовали руководству dbt Labs о том, как рефакторить устаревшие SQL-запросы в dbt и некоторые лучшие практики. После того как мы завершили рефакторинг всех рабочих процессов Alteryx, мы проверили, совпадает ли выход Alteryx с выходом рефакторированной модели, построенной на dbt.

Шаг 3: Используйте пакет audit_helper для аудита рефакторированных моделей данных

Аудит больших моделей, иногда с десятками столбцов и миллионами строк, может быть действительно сложной задачей для выполнения вручную. Невозможно вручную проверить столбцы один за другим, объединяя таблицы по их первичному ключу и измеряя совместимость через самодельный SQL. К счастью, существует несколько пакетов dbt, созданных исключительно для автоматизации этого процесса!

В этом проекте мы использовали пакет audit_helper, потому что он предоставляет более надежные макросы аудита и предлагает больше возможностей автоматизации для нашего случая использования. Для этого нам нужно было иметь как выходную таблицу устаревшего рабочего процесса Alteryx, так и рефакторированную модель dbt, материализованную в хранилище данных проекта. Затем мы использовали макросы, доступные в audit_helper, чтобы сравнить результаты запросов, типы данных, значения столбцов, количество строк и многое другое, что доступно в пакете. Для подробного объяснения и руководства по использованию пакета audit_helper, ознакомьтесь с этой статьей в блоге. Рисунок 6 графически иллюстрирует логику валидации, стоящую за audit_helper.

Рисунок 6 - Логика валидации данных audit_helper

Шаг 4: Дублируйте отчеты и подключите их к рефакторированным моделям dbt

С рефакторированными и проверенными моделями пришло время подключить их к инструменту BI-отчетов. Хотя некоторые будут достаточно смелыми, чтобы подключить рефакторированную модель непосредственно к оригинальному BI-отчету, мы рекомендуем дублировать BI-отчет и подключить эту копию к новой рефакторированной модели dbt.

Этот подход позволяет сравнивать два отчета бок о бок и проверять, как данные ведут себя в созданных визуализациях. Также это может служить шагом для двойной проверки того, что значения совпадают в рефакторированных и устаревших таблицах. Поэтому иногда может потребоваться вернуться к шагу преобразования и изменить типы столбцов или изменить бизнес-правило, например.

Преимущества процесса рефакторинга

Успешное преобразование всего набора рабочих процессов данных из движка Alteryx в dbt, безусловно, не является тривиальной задачей, но внедрение этой структуры, как результат процесса обучения методом проб и ошибок команды, позволило нам ускорить этот процесс, в то время как его фокус на аудите данных позволил обеспечить видимое и автоматизированное обеспечение качества данных.

Преобразование оказалось очень ценным для клиента благодаря трем основным аспектам нового стека данных на основе dbt, которые были замечены обеими командами:

• Невероятно сокращенное время выполнения: Возможно, самый впечатляющий результат, общее время выполнения рабочего процесса данных маркетинговой команды было сокращено с более чем 6 часов до всего 9 минут. Это представляет собой сокращение времени выполнения более чем в 40 раз. Большая часть этого происходит из-за перехода с локальных вычислений SQL Server на облачные вычисления Snowflake, гибкой компиляции SQL и предложений материализации dbt, а также последовательного выполнения на основе родословной (см. Рисунок 7).
• Улучшенная видимость рабочего процесса: Поддержка dbt для документации и тестирования, в сочетании с dbt Cloud, позволяет получить отличную видимость выполнения родословной рабочего процесса, ускоряя идентификацию ошибок и несоответствий данных и их устранение. Не раз наша команда смогла раньше идентифицировать влияние изменения логики одного столбца на модели ниже по потоку, чем эти модели Alteryx.
• Упрощение рабочего процесса: Модульный подход dbt к моделированию данных, помимо ускорения общего времени выполнения рабочего процесса данных, упростил создание новых таблиц на основе уже существующих модулей и улучшил читаемость кода.

Рисунок 7 — Сравнение времени выполнения, в минутах

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

Ссылки

Миграция из хранимых процедур в dbt

Audit_helper в dbt: Поднятие аудита данных на более высокий уровень

Рефакторинг устаревшего SQL в dbt