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)
• Способ построения (планируете ли построить архитектуру с помощью микросервисов)
• Существующий развернутый стек
• Опыт команды по использованию тех или иных технологий
Особняком в этом списке стоят форматы и типы собираемых данных. Разнообразие больших данных требует, чтобы конвейеры больших данных могли распознавать и обрабатывать данные во многих различных форматах - структурированных, неструктурированных и частично структурированных, и обычно именно формат данных во многом определяет рабочий процесс и компоненты для промежуточного и окончательного хранения данных.

Шаблоны Data Pipeline

Чем дольше работаешь в сфере визуализации данных, тем больше понимаешь, что сама визуализация – это примерно 10-15% рабочего времени; всё остальное время тратится на подготовку данных. Данные, создаваемые приложениями, устройствами или людьми, должны быть обработаны, прежде чем они будут использованы. Не всегда обработка включает в себя преобразование данных, однако практически всегда содержит шаги, связанные с качеством данных. Для того, чтобы как-то узаконить артефакты, возникающие в процессе обработки данных из места их производство в место использования, используют термин Data pipeline (Конвейер данных). По определению конвейер данных представляет собой поток данных между двумя или более системами. Это набор инструкций, которые определяют, как и когда перемещать данные между этими системами. Конвейер данных может быть таким же простым, как перемещение данных из точки A(Data producer) в точку B (Data Consumer), и столь же сложным, как сбор данных из нескольких источников, их преобразование и хранение в нескольких местах назначения.
Чтобы понять, как работает конвейер данных , представьте себе любой конвейер, который получает что-то от источника и передает его в пункт назначения. Что происходит с данными по пути, зависит от бизнес-сценария использования и самого пункта назначения.
Data producer: Источники данных могут включать реляционные базы данных и данные из приложений SaaS. Большинство конвейеров получают необработанные данные из нескольких источников с помощью механизма push, вызова API, механизма репликации, который извлекает данные с регулярными интервалами. Кроме того, данные могут быть синхронизированы в реальном времени или через запланированные интервалы.
Место использования (Data Consumer): местом назначения может быть хранилище данных, озеро данных или витрина данных, либо это может быть приложение для BI-аналитики.
Шаблоны Data pipelines:
1. Копилка Amazon Redshift
https://www.intermix.io/blog/14-data-pipelines-amazon-redshift/
2. Обзор видов архитектуры Azure на все случаи жизни:
https://docs.microsoft.com/ru-ru/azure/architecture/browse/
3. Примеры реализации Data pipelines на Azure (с кодом): https://github.com/Azure-Samples/modern-data-warehouse-dataops
4. Data pipelines под SnowFlake:
https://www.snowflake.com/blog/designing-big-data-stream-ingestion-architectures-using-snowflake-part-1/
https://docs.snowflake.com/en/user-guide/data-pipelines-examples.html

Про управление требованиями.

В ходе работы все мы неоднократно сталкивались с неуправляемыми, конфликтующими, избыточными, да и просто ущербными требованиями. Вопрос отягощается ещё и тем, что единый стандарт формулирования требований или отсутствует, или игнорируется со стороны стейкхолдеров.
Что делать? Вот 5 простых шагов, как стать граммар-наци для своих требований:
1) Чуть-чуть пострадать над ISO/IEC 29148 (https://www.iso.org/standard/45171.html) и сформулировать, что именно считается требованием в рамках вашего проекта, что является ограничивающими факторами, а что можно опустить.
2) Придумать себе классификацию требований. Тот же стандарт разделяет ваши требования на Stakeholder’s/System/Software. Смело отходите от стандарта, если это к вам не применимо, и разрабатываете вы не ПО, а новый сорт земляники.
3) Просмотрите свои требования внимательно на предмет того, способен ли их воспринять 14-летний школьник со средним уровнем интеллекта. Если нет, то можно закопаться в стандарт написания требований INCOSE Guide for Writing Requirements. В последней версии 108 листов, но есть видеоверсия: https://www.youtube.com/watch?v=UhYv2-x1CoQ
Если всё же соберетесь его читать, можно смело начинать со 102 страницы, где уже приведены конкретные паттерны написания требований с учетом необходимого уровня абстракции.
4) Провести анализ своих требований. Хорошо сформулированное требование имеет следующие характеристики:
уникальное: оно удовлетворяет только одному основному требованию;
актуальное: оно актуально в текущий момент, соответствует потребностям бизнеса и не противоречит дальнейшей роудмэпу развития продукта;
согласованное: не противоречит другим требованиям и соответствует их уровню декомпозиции;
понятное: требование сформулировано понятно и недвусмысленно;
поддающееся проверке: выполнение требования может быть проверено оптимальным способом, не зависящим от экспертной оценки;
приоритетное: его важность можно оценить относительно других требований;
5) Выбрать себе фреймворк для работы с жизненным циклом требований. Он традиционно вшит в ПО по управлению требованиями через статусы требований и связные задачи и помогает сделать грамотную трассировку требований (как это работает: https://www.inflectra.com/ideas/topic/requirements-traceability.aspx). Однако, если проект ведется в Excel, а не в одном из «20+ лучших тулзов для управления требованиями», можно взять на вооружение The Praxis Framework (https://www.praxisframework.org/en/knowledge/requirements-management) и применить его для своего проекта.

Requirements management - Praxis Framework Requirements management establishes stakeholders' wants and needs, and then reviews these to create a set of baseline requirements.

Инструмент квадранта для фиксации требований к дашборду

Есть три фактора успеха для построения эффективного оперативного дашборда:
-глубокое погружение в бизнес-контекст и потребности ЦА;
-грамотное сопоставление требований пользователя и возможностей BI-инструмента;
-смелость.
Глубокое погружение в контекст.
Последствия:
· Слишком много идей;
· Нет понимания, что нужно «прямо сейчас», а что потребуется впоследствии, так как заказчик хочет всё и сразу/

Для задачки по построению аналитики по дефектам оборудования, которые выявляют обходчики промышленного оборудования (причем, на самом промышленном предприятии они могут быть в любой должности - операторы, ремонтники, инженеры), нам требовался какой-то инструмент для приоритизации работы над метриками. Для удобства такой приоритизации можно использовать классический квадрант с двумя осями: используемость в ритуалах пользователей и скорость реализации.
Используемость в ритуалах пользователей – критерий, который характеризует важность метрики с практической точки зрения. Конечно, можно определить важность метрик для пользователей с помощью опроса (например, попросив пользователей расставить приоритеты), но этот способ хорош тогда, когда в целом у пользователей нет ни регулярной отчетности, ни бизнес-процесса.
В нашем кейсе процесс выявления дефектов уже существовал, поэтому наиболее честной мерой для оценки важности метрик являлись пользовательские ритуалы: к ним уже так или иначе готовились вручную справки, которые содержали те или иные данные.
Вторым критерием для квадранта была выбрана скорость реализации метрик на дашборде: чем быстрее они могли быть построены, тем лучше. Всё дело в том, что до момента внедрения оперативного дашборда как таковой отчетности с визуализацией у пользователей не существовало (только таблицы), поэтому одним из факторов успешной приживаемости дашбордов была скорость. Чем быстрее пользователи получат дашборд для того, чтобы его «обтыкать» со всех сторон, тем быстрее они смирятся с новым форматом работы, что обеспечит в дальнейшем приживаемость дашбордов как продукта.
Можно ли просто дать таким консервативным пользователям табличку, и оставить их в покое со всякими дашбордами? Можно, но это не наша история. Наша история – про цифровое будущее)