Data Generation

Шаблоны 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

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

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

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