Трансформация и оркестрация данных
Как мы уже говорили, подходы к обработке информации постоянно совершенствуются. В последнее время процедуры извлечения и загрузки отделяют от первичной трансформации. Одним из самых удобных способов, обеспечивающих этот процесс, выступает инструмент для трансформации данных dbt (data build tool). Это наш кухонный комбайн, сочетающий в себе одном многие процессы и позволяющий нам готовить пасту с креветками быстрее и проще. Остановимся на dbt подробнее.
Трансформация данных и dbt
Трансформация – одна из основ работы с данными. От ее качества во многом зависит результат анализа и актуальность управленческих решений.
На практике специалисты и команды DataOps, работающие с данными, часто сталкиваются с беспорядочными наборами информации. В таком способе хранения есть свои преимущества, однако такие данные сложно анализировать и визуализировать.
Кроме того, в бесструктурных наборах данных могут присутствовать:
• несколько элементов в одном и том же поле,
• неполные данные,
• записи в разных форматах,
• текстовые значения в столбцах с цифрами,
• другие ошибки.
Рис. 22. Данные без трансформации напоминают гору неразобранных бумаг – работать с ними так же сложно
Процесс, во время которого информация приводится в пригодный для анализа формат и корректируется, называют очисткой данных. По сути, это первый этап перед трансформацией. Именно на нем происходит нормализация и стандартизация данных. Иногда очистка требует намного больше усилий и времени, чем анализ и визуализация.
Трансформация нужна не сама по себе. Она не только исправляет ошибки, но и позволяет объединять данные, строить из них промежуточную витрину или создавать агрегирующую таблицу. И тем самым сокращает размерность информации (то есть уменьшает количество данных, которые аналитик будет использовать в работе).
Как правило, именно с такими агрегатами и работают аналитики. На основе витрин они пишут запросы, необходимые для составления отчетов.
Трансформация данных вручную – для бизнеса процесс долгий, а для сотрудника сродни каторге. Именно поэтому специалистам понадобились инструменты, облегчающие эту работу.
Рис. 23. Стандартизация – это приведение данных из разных источников к единому согласованному формату
Dbt – не единственный инструмент. Есть и другие решения. Но на практике их сложно применить для обработки потока данных, а потому они используются при «точечных» задачах. Из популярных можно назвать:
• «Умная очистка» или Smart CleanUp в «Google Таблицах». Она дает возможность увидеть ошибки в данных. Но исправлять нужно вручную.
• Tabula. Это кроссплатформенная утилита, она служит для извлечения данных из PDF-файлов и хранения их в формате CSV.
• OpenRefine. Помогает исправлять опечатки и ошибки форматирования и стандартизировать данные.
Как правило, эти и множество других задач можно решить с помощью SQL-запросов внутри созданной базы данных. Именно здесь приходит на помощь dbt. Он существует в двух версиях:
• основная – работает с интерфейсом командной строки (open source software),
• версия с графическим интерфейсом (GUI).
Что позволяет сделать dbt:
• структурировать запросы для трансформации данных и управлять ими,
• в версии с графическим интерфейсом создавать онлайн-документацию для фрагментов кода,
• преобразовывать код в определенном формате в правильный SQL-запрос к хранилищу данных и правильно его исполнять.
Это и есть главная задача dbt.
Рис. 24. Пример dbt-модели
Теперь немного поговорим о технологии работы инструмента. Dbt – еще своего рода надстройка над SQL-файлами. Он поддерживает синтаксисы SQL и YAML. В переводе с английского YAML означает «еще один язык разметки». То есть на практике это способ обращения к хранилищам данных, предназначенный для организации больших потоков информации и ее хранения в понятном человеку виде. Функционально YAML – конкурент XML и отличается от него минимализмом и удобством применения.
Рис. 25. Пример файла с шаблоном YAML-разметки
На рисунках 24–26 вы можете видеть, как прописываются запросы и порядок выполнения действий над данными. Dbt при первом запуске автоматически создает файл с шаблоном YAML-разметки.
Давайте внимательнее рассмотрим особенности dbt.
Разработала и запустила dbt в коммерческую эксплуатацию команда Fishtown Analytics. Их специалисты решали примерно такие же задачи, как и моя компания LEFT JOIN на аутсорсе:
• создавали хранилища и потоки данных,
• выстраивали их аналитику в организациях.
Fishtown Analytics довольно быстро столкнулась с необходимостью повторения однотипных действий, а потому решила создать инструмент для работы с данными, способный упростить жизнь инженерам и аналитикам.
Рис. 26. Пример работы с dbt через bash
Специалисты компании придумали новый подход трансформации данных внутри хранилища. Теперь основные его сущности и операции описываются в отдельных YAML-файлах, хотя сама концепция довольно непривычна для инженера данных, привыкшего работать с SQL-запросами. Для того чтобы как следует погрузиться в идею dbt, я советую любому специалисту по инжинирингу пройти бесплатный вводный курс (dbt-101) и изучить все настройки.
Одна из самых крутых опций dbt – макросы на языке Jinja (Python-библиотека), позволяющие легче писать однотипный код. В dbt также доступны расширения (packages), которые можно писать самостоятельно или пользоваться готовыми от сторонних производителей.
Разница между макросами и расширениями в том, что первые – это документированные фрагменты кода. По аналогии с другими языками программирования макросы выступают кодом отдельных функций. Таким образом, Python-программисту, знакомому с функциональным направлением, легко реализовать удобный для него подход внутри dbt. Большинство расширений и макросов создают сами участники сообщества dbt.
В свою очередь, расширения позволяют:
• корректно подключаться к хранилищам;
• разместить повторно (часто) используемые фрагменты кода один раз (принцип DRY);
• создавать максимально точные запросы.
Рассмотрим подробнее упомянутый выше принцип DRY. В переводе с английского аббревиатура DRY означает «не повторяйся» (don’t repeat yourself). Сам принцип пришел из программирования и сводится к исключению повторов кода. Если какой-то элемент используется чаще одного раза, он выносится в отдельный файл-библиотеку или расширение. DRY позволяет освободить ресурсы для разных вариантов обработки данных.
Одни из важных функций dbt – контроль версий и откат изменений. Эти понятия пришли в работу с данными также из программирования.
Под версией разработчики понимают блок кода, написанный в определенный момент времени.
Команда разработчиков программного обеспечения:
• создает прототип (или альфа-версию) продукта;
• изучает его работу;
• исправляет основные ошибки;
• создает черновик или бета-версию, очередной коммит (способ сохранения изменений в коде);
• тестирует его, исправляет ошибки и предоставляет готовый продукт.
Отличным инструментом внутри dbt выступает Git – распределенная система управления версиями при разработке программного обеспечения. В работе с данными она используется для схожих задач:
• каталогизирует агрегаты данных;
• ускоряет резервное копирование;
• облегчает обращение к разным наборам данных и легко восстанавливается в случае сбоя.
Dbt позволяет подключить Git и работать с данными примерно таким же образом.
Суть подхода в том, чтобы «отложить в сторону» код на SQL, создавая определенные витрины. Затем другой разработчик может подхватить наработанное и продолжить трудиться над задачей в другой «ветке», а после объединить код и присоединиться к «основной ветке», реализовав задуманное командой.
Безусловно, не только управление версиями кода – полезная возможность dbt. Инструмент также помогает в работе над определением структур данных. Например, можно запланировать регулярное удаление и создать материализованное представление, которое будет пополняться нужными данными за прошедший период.
• Удобно реализована работа и с тестированием данных. Dbt помогает проверять уникальные и пустые значения, взаимосвязи в таблицах.
• Dbt поддерживает инкрементные модели тестирования, а не пересоздает таблицы данных. Кроме того, он может тестировать и источники информации, и уже готовые витрины.
• Dbt также позволяет создавать пользовательские тесты или применять готовые, которые можно брать из репозитория на сайте hub.getdbt.com.
Немного запутанно, правда? Смотрите, как все это работает на практике.
Наша команда настраивала аналитическую отчетность для владельцев американского мобильного приложения по уходу за собой. Основатели компании пользовались платежными агрегаторами Stripe и Braintree. Маркетологи поставили перед нами следующую задачу: им было необходимо считать действия каждого пользователя в приложении.
Чтобы это сделать, потребовалось объединить данные из платежных агрегаторов. А информацию они отдают по-разному:
• один указывает время оплаты с точностью до секунд, другой – до минут,
• один передает таблицу из 15 полей, другой – из 12,
• в таблицах отличаются идентификатор пользователя и другая информация.
Нам нужна была одна таблица с колонками в едином формате и объединенными данными. Именно так должна выглядеть отчетность. Что мы сделали?
Внедрили клиентам dbt, построив процессы обработки данных с использованием SQL.
Прописали алгоритм взаимосвязи и правила объединения данных.
Создали промежуточную витрину, содержащую агрегированную информацию.
В конце объединили внутренние и финансовые данные компании. Теперь появилась возможность писать запросы к этому агрегату и строить отчеты. Задача была решена.
Но давайте пойдем дальше. Это же приложение из приведенного выше примера накапливает данные непрерывно. С нашей помощью его владельцы получают актуальные отчеты.
А как быть, если данных поступает больше?
В этом случае настройка регулярности сбора и мониторинг – уже необходимость. И она реализуется путем так называемой оркестрации данных.
Оркестрация данных
Мы подошли к самому интересному. Оркестрация данных – это процесс координации и управления одновременно несколькими потоками информации.
Зачем она нужна? В современном мире структура данных со временем становится все сложнее. Постоянный рост количества систем хранения и управления информацией добавляет трудностей. И нужно уметь не только поверхностно разбираться в этих вопросах, но и настраивать различные программные инструменты, исходя из своих потребностей.
Давайте подумаем, какие требования можно предъявить в вашей компании к входящим данным?
• Данные не должны дублировать друг друга, чтобы не занимать лишнее место в хранилищах.
• Они должны быть исчерпывающими.
• Их должно быть легко найти, извлечь и использовать по назначению.
Современные инструменты сбора данных выстраивают их в потоки и задают некоторую очередность загрузки в хранилища. Оркестрация предполагает автоматический процесс размещения данных и управления пайплайнами.
Теперь обратимся к теории. Когда вы планируете трансформацию данных и работу с ними, то часто вынуждены использовать графы, где отдельные операции и взаимосвязи представлены определенным образом. В чем их особенность?
Обычно граф выглядит как неправильный многоугольник с вершинами (узлами) и линиями (ребрами). Вершины отображают отдельные операции: извлечь данные А, переместить в таблицу B – эти действия выполняются с помощью инструментов. Ребра отображают взаимосвязи между операциями.
Чаще всего используется прямой ациклический граф – DAG (Directed Acyclic Graph). Это модель, структурирующая информацию в некий порядок выполнения операций: извлечь А и В, объединить в С, убрать ошибки.
DAG – это практически готовая инструкция по исполнению скриптов (может планироваться по расписанию) под управлением того же Airflow.
Как это выглядит на практике?
Обычно в компании множество Python-скриптов, каждый управляет отдельной процедурой. Для того чтобы наладить исполнение одного и того же скрипта, они планируются через cron – внутреннюю библиотеку операционной системы. В базовой версии это рабочий вариант, позволяющий тестировать подходы по сбору данных.
Однако поддерживать выполнение десятков связанных между собой скриптов и управлять им сложно. Еще труднее понимать, насколько эффективно обрабатываются данные и чем завершились определенные работы: успехом или неудачей.
Но эту же задачу можно решить проще: подключить специально предназначенные для оркестрации инструменты: например, Airflow или Dagster. В них есть возможность спланировать Python-скрипты, находящиеся внутри DAG’ов. Это позволяет контролировать успешность выполнения операций и распределять их во времени.
Таким образом, мы упрощаем управление запусков скриптов и видим его подробные результаты.
Подобный подход гарантирует, что мы получим витрину данных, с которой может работать аналитик.
Или же выявим причины, почему создать витрину не удалось.
Например, у компании из Эстонии, занимающейся беттингом (ставками на спорт) данные преобразуются и складываются в ClickHouse. А все основные процедуры автоматизированы и переданы под управление Airflow.
Рис. 27. Пример DAG из Airflow
Да, зачастую объем необходимых к выполнению скриптов может быть настолько громоздким.
Как вы можете видеть, объемы работы с данными таковы, что для них необходим отдельный специалист, а иногда и не один. И именно об этом мы поговорим в следующей части – в чем разница в обязанностях разных аналитиков, чем отличаются их задачи и как они готовят отчетность.