Data Generation

Матрица подбора инструментов Data pipelines

Data pipelines (конвейер данных) зачастую рассматриваются организациями не просто как способ поставки данных (процесс), но и как некий программный актив, характеристики которого обеспечивают data-driven подход к принятию решений.
Характеристиками актива (продуктовыми метриками) в таком подходе традиционно выступают:
-Скорость или пропускная способность - это то, сколько данных конвейер может обработать за установленный промежуток времени.
-Надежность конвейера данных - необходимость, чтобы отдельные системы в конвейере данных были отказоустойчивыми. Надежный конвейер данных со встроенными механизмами аудита, регистрации и проверки помогает обеспечить качество данных.
-Задержка - это время, необходимое для прохождения отдельной единицы данных по конвейеру. Задержка больше связана со временем отклика, чем с объемом или пропускной способностью. Поддержание низкой задержки может быть дорогостоящим с точки зрения как цены, так и ресурсов обработки.
Однако, если говорить о фундаментальном компонентном подходе, в котором Data pipeline рассматривается не как сервис или платформа, а именно как совокупная программная цепочка, то для его поддержки организациям зачастую требуется следующий компонентный набор:
-Среда разработки и развертывания
-Графическая оболочка для среды разработки для управления потоком данных (в частности, для контроля преобразования данных)
-Среда тестирования
-Инструменты контроля версионности
-Мониторинговые инструменты для контроля и устранения неполадок

Выбор конкретных инструментов (технологический стек) и их конфигурация зависят как от самой задачи, так и от многих иных параметров, не связанных напрямую с данными. Передовые практики оркестрации и автоматизации Data pipeline базирутся на следующих подходах:
-Непрерывная оценка структуры источников данных (метаданных) для оперативного управления изменениями (автоматическое обнаружение изменения схемы в источнике данных).
-Автоматическая генерация кода для модификации приемника данных;
-Обеспечение разнообразия коннекторов, которые могут принимать данные из самых разных файлов, баз данных, потоков событий, облачных сервисов и приложений.
-Поддержка разнообразных подходов к извлечению / загрузки / преобразованию (ELT) для интеграции и преобразования данных.
-Управление нормализацией данных для автоматизации создания конвейеров данных и создания готовых для анализа активов данных.
-Возможность использования гибридных облачных вычислений для поддержки масштабной интеграции.
-Поддержка репликации и автоматического восстановления после сбоя.
У-довлетворение требованиям защиты данных и обеспечение сквозного шифрования для предотвращения несанкционированного использования.
Но и сами эти инструменты, в свою очередь, влияют на систему ритуалов, складывающихся вокруг поставки данных, и определяют, как в конечном итоге выглядят процессы разработки, обслуживания и управления конвейерами данных.

Между ТЗ и Дашбордом: артефакт преобразования данных

Где-то между формулированием и анализом ТЗ на построение отчетности, построением Data Pipelines и отрисовкой диаграмм в BI-инструменте затесалась обработка данных. Описание обработки данных позволяет быстро отвечать на вопросы пользователей, самый популярный из которых – «Данные на источнике и в дашборде отличаются, почему?»
Одним из полезных артефактов является граф потока данных, который описывает, как потоки данных перемещаются между операциями с учетом инструментов преобразований. Его используют в потоковом программировании, однако, при должной кастомизации, он удобен и для описания дискретного преобразования данных (batch-процессинг).
В упрощенном виде этот граф состоит из четырёх частей:
• Описание преобразований на источнике (Data lineage)
• Описание операций преобразования в ходе batch-процесса
• Преобразования внутри хранилища ( Data Consumer)
• Query-запросы на уровне BI-инструмента
В отличие от архитектуры Data Pipelines, граф описывает именно шаги физического преобразования данных. Единицей графа (основной функциональной единицей) является оператор. Они получают данные из входов, выполняют над ними вычисления и выдают данные на выходы для дальнейшей обработки.
Операторы без портов ввода называются источниками данных (data source). При этом, в зависимости от степени укрупнения графа, в качестве data source могут выступать как в целом веб-ресурсы, приложения/системы, файлы, так и отдельные таблицы внутри них. В случае, если в графе раскрываются преобразования данных внутри источника, подход трансформируется в Data lineage, содержащий преобразования данных от самых нижних слоёв (системных таблиц) до пользовательских артефактов, и при этом указывается, с какого именно слоя забираются данные для batch-процесса.
Операции преобразования (transformation operation) – это однопроходные операции, которые описывают каждое преобразование. При этом конкретное вычисление может быть применено с помощью одной функции, то есть одного шага, ко всему столбцу или серии столбцов, давая несколько результатов от одного действия. В зависимости от чувствительности конечных данных для пользователя подбирают степень укрупнения такого описания (описывают в целом шаг вычислений, или же формулой преобразований для каждого конкретного столбца).
Преобразования внутри хранилища традиционно содержат описания трансформаций между слоями. Концепция описания здесь сильно зависит от наличия операций Data Quality, очистки и обогащения, а также проверок на бизнес-зависимости и корректировок с учетом результатов этих бизнес-проверок. Примером бизнес-зависимости могут быть данные, которые должны быть перекрестно проверены из одного источника по сравнению с другим для поддержания точности перед консолидацией.
Описанием преобразований на уровне BI-инструмента можно пренебречь, если дашборд строится на готовом датасете и содержит только меры, агрегирование и фильтрацию. Но, если Data Prep (консолидация, join, сложные query-запросы, транспонирование и пр.) происходит на уровне BI, описание последовательных шагов преобразований в графе снимает большую часть вопросов, связанных с расхождением данных.

Подход к проектированию Data pipeline (конвейеров данных)

Времена, когда «выгрузил в CSV, залил в BI» считалось вполне пригодной архитектурой, давно прошли. Архитекторам и разработчикам пришлось адаптироваться к «большим данным», как с точки зрения их анализа, так и с точки зрения их доставки от точки производства до места непосредственного использования.
Как и многие компоненты архитектуры данных, Data Pipelines эволюционировали для поддержки больших данных. Ключевую роль в развитии архитектуры конвейеров данных играют, с одной стороны, требования по скорости обработки и преобразования самих данных (условно, можно назвать это time-to-market), и, с другой стороны, развитие предсказательной и предписывающей аналитики, которая предполагает работу с данными в режиме реального времени.
При этом объем больших данных требует, чтобы конвейеры данных были масштабируемыми, поскольку объем может изменяться с течением времени. На практике, вероятно, будет много событий больших данных, которые происходят одновременно или очень близко друг к другу, поэтому конвейер больших данных должен иметь возможность масштабирования для одновременной обработки значительных объемов.
Архитектура конвейера данных требует предварительной проработки ряда вопросов, связанных с процессами, которые будут происходить с данными, и которые, в конечном итоге, определяют тип этой архитектуры .(традиционная (batch process), потоковая или гибридная (архитектура Lambda).
Типовой чек-лист по Data processing:
• Тип аналитической задачи:
o традиционная аналитика (анализ исторических данных);
o предписывающая/предиктивная аналитика;
o аналитика в реальном времени;
o гибридная задача (предполагается и пакетная, и потоковая обработка)
• Ожидаемая скорость передачи данных
• Направление потока данных (только прямой от Data producer к Data consumer, или предполагается и обратная связь)
• Виды обработки данных, применяемые в ходе Data processing
• Тип Data producer (локальный, облачный)
• Требования по нагрузке на Data producer при заборе данных
• Стратегия извлечения данных (push/pull)
• Способ построения (планируете ли построить архитектуру с помощью микросервисов)
• Существующий развернутый стек
• Опыт команды по использованию тех или иных технологий
Особняком в этом списке стоят форматы и типы собираемых данных. Разнообразие больших данных требует, чтобы конвейеры больших данных могли распознавать и обрабатывать данные во многих различных форматах - структурированных, неструктурированных и частично структурированных, и обычно именно формат данных во многом определяет рабочий процесс и компоненты для промежуточного и окончательного хранения данных.