Enterprise архитектура

Enterprise архитектура включает подмножество архитектур, таких как бизнес-архитектура, техническая, архитектура приложения и архитектура данных.

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

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

Джеффу Безосу приписывают идею «дверей в один и два конца». Дверь в один конец — это решение, которое почти невозможно отменить. Например, Amazon мог бы продать AWS или закрыть его. После такого шага восстановить облачный сервис с той же рыночной позицией было бы практически невозможно. С другой стороны, дверь в два конца — это легко обратимое решение: можно войти, оценить ситуацию и либо продолжить движение вперед, либо вернуться обратно, если результат не устраивает.

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

Архитекторы выявляют проблемы в текущем состоянии (низкое качество данных, ограничения масштабируемости), определяют желаемые будущие состояния (гибкое улучшение качества данных, масштабируемые облачные решения, оптимизированные бизнес-процессы) и реализуют инициативы через выполнение небольших, конкретных шагов.
Важно подчеркнуть, что технические решения должны поддерживать бизнес-цели, а архитектура организации должна балансировать между гибкостью и необходимыми компромиссами для достижения оптимальных результатов.

Архитектура данных

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

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

«Хорошая» архитектура данных

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

Гибкость — основа хорошей архитектуры данных, поскольку благодаря ей мы можем быстро адаптироваться в вечно меняющейся окружающей среде. Хорошая архитектура данных остается адаптивной и легко поддерживаемой. Она развивается в ответ на изменения в бизнесе, а также на появление новых технологий и практик, которые могут открыть ещё большую ценность для бизнеса в будущем.

Плохая архитектура данных отличается сильной связностью, жёсткостью, чрезмерной централизацией или использованием неподходящих инструментов, что затрудняет разработку и управление изменениями.

Принципы хорошей архитектуры данных
Фреймворк AWS Well-Architected состоит из шести ключевых принципов:
— Операционное совершенство
— Безопасность
— Надёжность
— Эффективность производительности
— Оптимизация затрат
— Устойчивость

Пять принципов облачно-нативной архитектуры Google Cloud:
— Проектируйте для автоматизации.
— Грамотно управляйте состоянием.
— Отдавайте предпочтение управляемым сервисам.
— Применяйте многоуровневую защиту.
— Постоянно улучшайте архитектуру

Мы хотели бы дополнить и расширить эти принципы, добавив ключевые принципы архитектуры инженерии данных:
— Осознанный выбор общих компонентов
— Планирование на случай отказов
— Проектируйте с учётом масштабируемости
— Архитектура — это лидерство
— Постоянно улучшайте архитектуру
— Стройте слабо связанные системы
— Принимайте обратимые решения
— Приоритизируйте безопасность
— Используйте принципы FinOps

Принцип 1: Осознанный выбор общих компонентов
Когда архитекторы принимают взвешенные решения и эффективно руководят, общие компоненты становятся основой для совместной работы команд и устранения изолированных процессов. Они способствуют гибкости внутри и между командами, объединяя общие знания и навыки. Общие компоненты могут включать любое широко применимое решение в организации, например:
— Объектное хранилище
— Системы контроля версий
— Инструменты наблюдаемости и мониторинга
— Системы оркестрации
— Движки обработки данных
Облачные платформы являются идеальной средой для внедрения таких компонентов.

Принцип 2: Планирование на случай отказов
Ключевые термины:
1) Доступность — процент времени, в течение которого ИТ-сервис или компонент находится в рабочем состоянии.
2) Надёжность — вероятность того, что система будет соответствовать установленным стандартам и выполнять свои функции в течение заданного интервала времени.
3) RTO (Recovery time objective, «целевое время восстановления») — максимально допустимое время простоя сервиса или системы. Например, один день простоя может быть допустимым для внутренней отчётности, но даже пять минут простоя могут серьёзно повлиять на бизнес интернет-ритейлера.
4) RPO (Recovery Point Objective, «цель точки восстановления») — максимально допустимый объём потерянных данных после сбоя. Время восстановления файлов из резервного хранилища не должно превышать RPO. Например, если RPO составляет 90 минут, то данные, накопленные за последние полтора часа, будут потеряны. Соответственно, снимок (snapshot) должен выполняться не реже одного раза в 90 минут. Резервное копирование может включать не только файлы на дисках, но и настройки приложений, параметры операционной системы сервера, а также состояние процессов в оперативной памяти.

Принцип 3: Проектирование с учётом масштабируемости
Масштабируемость в системах данных включает два ключевых аспекта:

1. Система должна уметь масштабироваться вверх для обработки больших объёмов данных.
2. Система должна масштабироваться вниз, автоматически снижая ресурсы после спада нагрузки для оптимизации затрат.
   Идеальная система должна динамически адаптироваться к нагрузке в автоматическом режиме.

Принцип 4: Архитектура — это лидерство
Архитекторы данных несут ответственность за технологические решения, разработку архитектурных артефактов и распространение решений через лидерство и обучение.
Идеальный архитектор данных:
— Обладает техническими навыками инженера данных, но не занимается ежедневными инженерными задачами.
— Наставляет инженеров, консультируется с организацией при выборе технологий.
— Распространяет знания через обучение и управление процессами.
— Объединяет ресурсы компании для достижения общих целей в технологиях и бизнесе.

Принцип 5: Постоянно улучшайте архитектуру
Работа архитектора включает три основные задачи:
— Глубокое понимание текущей архитектуры.
— Разработка целевой архитектуры.
— Создание плана перехода с приоритизацией изменений

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

1. Разделение на множество небольших компонентов.
2. Взаимодействие между сервисами через уровни абстракции (например, API или шину сообщений), скрывающие внутренние детали.
3. Изменения в одном компоненте не требуют изменений в других.
4. Отсутствие глобального цикла релизов — каждый компонент обновляется независимо.

Принцип 7: Принятие обратимых решений
В условиях быстрой эволюции технологий и модульной архитектуры всегда выбирайте лучшие решения на текущий момент, но будьте готовы адаптироваться по мере появления новых решений.

Принцип 8: Приоритизация безопасности
Каждый инженер данных должен нести ответственность за безопасность создаваемых и поддерживаемых систем. Два ключевых подхода:
— Модель нулевого доверия (Zero Trust) — проверка и защита на всех уровнях доступа.
— Модель разделённой ответственности — распределение обязанностей между облачным провайдером и пользователями.

Принцип 9: Применение FinOps
FinOps — это подход к финансовому управлению облачными затратами, объединяющий инженеров, финансы и бизнес для принятия решений на основе данных.

Ранее инженеры данных ориентировались на производительность: максимизация скорости обработки на фиксированном количестве ресурсов.
С появлением FinOps важно учитывать и стоимость:
— Какой баланс между AWS Spot Instance при запуске распределённого кластера?
— Какая модель расчёта (pay-per-query vs. reserved capacity) будет выгоднее в долгосрочной перспективе
— Как достичь оптимального соотношения между стоимостью и производительностью при выполнении больших задач?

Основные архитектурные концепции

Домен и сервисы
Домен — это предметная область реального мира, для которой создаётся архитектура. Сервис — это набор функций, предназначенных для выполнения определённой задачи. Один домен может включать несколько сервисов. Например, в домене продаж могут быть три сервиса: заказы, выставление счетов и товары. Каждый из них выполняет определённые задачи, поддерживающие общий процесс продаж.

При определении границ домена сосредоточьтесь на том, что он представляет в реальном мире.

Распределенные системы, масштабируемость, проектирование случаев отказа

Мы как инженеры данных рассматриваем четыре тесно связанных характеристик систем обработки данных:
— Масштабируемость (Scalability) — возможность увеличивать ёмкость системы для повышения производительности и обработки возросшей нагрузки. Например, нам может потребоваться масштабировать систему, чтобы справляться с высоким количеством запросов или обрабатывать огромные объёмы данных.
— Эластичность (Elasticity) — способность масштабируемой системы динамически адаптироваться. Высокоэластичная система может автоматически увеличивать или уменьшать ресурсы в зависимости от текущей нагрузки. Масштабирование вверх критично при росте спроса, а масштабирование вниз помогает снизить затраты в облачной среде. Современные системы иногда могут масштабироваться до нуля, полностью отключаясь при отсутствии нагрузки.
— Доступность (Availability) — процент времени, в течение которого IT-сервис или компонент находится в работоспособном состоянии.
— Надёжность (Reliability) — вероятность того, что система выполнит свои функции в соответствии с заданными стандартами в течение определённого промежутка времени.

Распределённые системы широко используются в различных технологиях обработки данных, которые вы будете использовать в своей архитектуре. Почти каждое облачное хранилище данных или объектное хранилище содержит под капотом механизмы распределения.

Жёсткая vs. Слабая Связанность: Уровни, Монолиты и Микросервисы

На одном конце можно выбрать крайне централизованные зависимости и процессы, где каждая часть домена и сервиса критически зависит от всех остальных доменов и сервисов. Такой подход называется жёсткой (тесной) связанностью (tightly coupled).

На другом конце находятся децентрализованные домены и сервисы, которые не имеют строгих зависимостей друг от друга. Этот подход называется слабой (разряженной) связанностью (loosely coupled). В такой архитектуре независимые команды могут легко разрабатывать системы, но их данные могут оказаться несовместимыми или малополезными для коллег из других команд.

Уровни Архитектуры
При разработке архитектуры важно учитывать её уровни. Архитектура состоит из различных слоёв — данных, приложений, бизнес-логики, представления и необходимо понимать, как их разделять.
Жёсткая связанность между уровнями создаёт уязвимости, поэтому при проектировании следует стремиться к максимальной надёжности и гибкости за счёт правильной организации и разделения слоёв.

Одноуровневая (Single-Tier) Архитектура
В одноуровневой архитектуре база данных и приложение тесно связаны и находятся на одном сервере.

Многоуровневая (Multitier, N-Tier) Архитектура
Многоуровневая архитектура (также известная как n-уровневая) состоит из отдельных слоёв: данных, приложения, бизнес-логики, представления и т. д. Эти слои организованы иерархически, то есть нижние слои не зависят от верхних, но верхние зависят от нижних.

Основная идея такой архитектуры — разделение данных, приложения и пользовательского интерфейса.

Один из самых распространённых видов многоуровневой архитектуры — трёхуровневая (three-tier) архитектура, которая используется в клиент-серверных системах. Она включает три уровня:

1. Уровень данных (Data Tier) — хранение и управление данными.
2. Уровень логики (Application Tier) — обработка данных и выполнение бизнес-логики.
3. Уровень представления (Presentation Tier) — интерфейс пользователя, взаимодействие с системой.

Монолиты и Микросервисы
Монолиты (Monoliths)
Связанность внутри монолитных систем можно рассматривать с двух точек зрения:

1. Техническая связанность (Technical Coupling) — относится к архитектурным уровням (tiers).
2. Доменная связанность (Domain Coupling) — описывает, как домены взаимосвязаны друг с другом.

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

Микросервисы (Microservices)
Микросервисная архитектура состоит из раздельных, децентрализованных и слабо связанных сервисов.
— Каждый сервис выполняет конкретную функцию и не зависит от других сервисов в своём домене.
— Если один сервис временно выходит из строя, это не нарушает работу остальных сервисов.
— Такая архитектура обеспечивает гибкость, масштабируемость и отказоустойчивость по сравнению с монолитными системами.

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

1. Централизация (Centralization)
   — Одна команда отвечает за сбор данных из всех доменов, их согласование и подготовку для потребления всей организацией.
   — Это традиционный подход, используемый в классических хранилищах данных (Data Warehouses).
2. Data Mesh
   — Каждая команда, занимающаяся разработкой ПО, самостоятельно подготавливает свои данные для использования в организации.
   — Подход основан на децентрализации и позволяет лучше масштабировать архитектуру данных

Single vs Multitenant Access
В многоарендной (multitenant) архитектуре важно учитывать два ключевых аспекта: производительность и безопасность.
— Производительность: если несколько крупных арендаторов (tenants) используют облачную систему, сможет ли она обеспечивать стабильную работу для всех? Или возникнет проблема «шумного соседа», когда активное использование одним арендатором ухудшает производительность для других?
— Безопасность: данные различных арендаторов должны быть надёжно изолированы, чтобы исключить утечки или несанкционированный доступ.

Событийно-ориентированная архитектура (Event-Driven Architecture)
Бизнес-процессы редко бывают статичными: постоянно происходят события — например, регистрация нового клиента, оформление заказа или обновление статуса товара.
Событие (event) в этом контексте — это фиксирование изменения состояния чего-либо.
Событийно-ориентированный рабочий процесс (workflow) включает три ключевых этапа:
1. Создание событий (Event Production) — генерация событий системой.
2. Маршрутизация событий (Event Routing) — передача событий в нужные компоненты системы.
3. Потребление событий (Event Consumption) — обработка событий различными сервисами.

Событийно-ориентированная архитектура опирается на событийный workflow и использует его для связи между различными сервисами. Преимущество event-driven архитектуры заключается в том, что она распределяет состояние события между несколькими сервисами.

Brownfield vs. Greenfield проекты
Прежде чем приступить к разработке архитектуры данных, важно определить, начинаете ли вы с нуля или работаете с уже существующей системой.

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

Greenfield проекты
— Начинаются с чистого листа, без ограничений прошлых решений.
— Позволяют выбрать наиболее современные и подходящие технологии.
— Чаще всего проще в реализации, так как отсутствуют технические долги.
— Дают архитекторам и инженерам больше творческой свободы и возможностей для инноваций.

Выбор между brownfield и greenfield подходом зависит от контекста: если модернизация невозможна или слишком затратна, может быть разумнее начать с нуля. Однако brownfield-проекты часто встречаются в крупных компаниях, где полное обновление инфраструктуры сразу невозможно.

Примеры типов архитектур данных

Поскольку архитектура данных — это достаточно абстрактная штука, проще всего ее понимать на конкретных примерах. В этом разделе мы рассмотрим популярные типы архитектур данных.

Data Warehouse (Хранилище данных)
Data Warehouse (DWH) — это центральное хранилище данных, используемое для отчетности и аналитики. Данные в хранилище обычно тщательно структурированы и подготовлены для аналитических задач.

Существует два типа архитектуры хранилищ данных:

1. Организационная архитектура DWH — ориентирована на структуру бизнеса, процессы и потребности различных команд.
2. Техническая архитектура DWH — включает технические аспекты реализации, такие как архитектура MPP (Massively Parallel Processing), схемы хранения данных (звезда, снежинка) и механизмы ETL/ELT.

Организационная архитектура DWH обладает двумя ключевыми характеристиками:

1. Разделение OLAP и OLTP
   — OLAP (онлайн-аналитическая обработка) и OLTP (онлайн-операционная обработка) выполняют разные задачи.
   — Важно отделять аналитическую нагрузку от транзакционных баз данных, чтобы избежать влияния аналитических запросов на производительность бизнес-приложений.
   — DWH создается как отдельная физическая система, куда выгружаются данные, что повышает производительность аналитики и снижает нагрузку на продакшн-системы.
2. Централизованная организация данных:
   — Традиционно хранилище данных получает данные из различных систем через процессы ETL (Extract, Transform, Load).
   — На этапе Extract данные извлекаются из источников (CRM, ERP, базы данных транзакций и др.).
   — После этого они проходят обработку и загружаются в хранилище в структурированном виде, удобном для аналитических запросов.

ETL (Extract, Transform, Load) — традиционный подход, в котором данные:

1. Extract — извлекаются из источников (базы данных, API, файлы).
2. Transform — проходят преобразование (очистка, нормализация, агрегация) в промежуточной системе.
3. Load — загружаются в хранилище данных в уже структурированном виде.

ELT (Extract, Load, Transform) — современный вариант, особенно популярный в облачных хранилищах:

1. Extract — данные извлекаются из источников.
2. Load — загружаются в хранилище в «сыром» виде без предварительной обработки.
3. Transform — обработка и преобразование выполняются внутри хранилища с помощью его вычислительных мощностей (например, BigQuery, Snowflake, Redshift).

Cloud Data Warehouse (CDW)
Облачные хранилища данных (CDW) — это современный вариант традиционных on-premise хранилищ, обладающий рядом преимуществ:
— Горизонтальное масштабирование— ресурсы добавляются динамически.
— Гибкость и доступность — нет необходимости в сложной инфраструктуре.
— Оплата за использование — снижает издержки на поддержку серверов.

Популярные CDW-платформы:
— Amazon Redshift — первый облачный DWH, ориентирован на MPP (massively parallel processing).
— Google BigQuery — полностью управляемое хранилище с serverless-архитектурой.
— Snowflake — облачная DWH-платформа с разделением вычислительных и хранилищных ресурсов.

Data Mart
Data Mart — это тематическое подмножество данных из хранилища, предназначенное для конкретного отдела (маркетинг, финансы, продажи).
Причины использования Data Mart:

1. Упрощенный доступ к данным — аналитики и бизнес-пользователи работают только с нужной информацией.
2. Дополнительная трансформация — данные могут обрабатываться с учетом специфики подразделения.
3. Производительность — уменьшение объема данных снижает нагрузку на запросы.

Data Marts могут строиться двумя основными способами:
— Independently — независимо от основного хранилища, получая данные напрямую из источников.
— Dependent — на основе центрального DWH, получая из него уже очищенные данные.

Связь CDW и Data Marts
Облачные хранилища часто используются как основа для Data Marts, обеспечивая быстрый доступ к агрегированным данным с учетом специфики различных бизнес-единиц.

Data Lake и его эволюция

Data Lake — это централизованное хранилище, в котором могут находиться данные в сыром виде без строгой схемы. Оно поддерживает все виды данных:
— Структурированные (таблицы, реляционные базы).
— Полуструктурированные (JSON, XML, Parquet).
— Неструктурированные (изображения, видео, логи, аудиофайлы)

Плюсы Data Lake:
— Гибкость: не требуется предварительное моделирование схемы.
— Масштабируемость: хранит огромные объемы данных в S3, HDFS
— Поддержка Machine Learning: данные можно использовать для анализа и моделей.

Однако со временем Data Lake стал превращаться в data swamp (болото данных), потому что:
— Данные плохо каталогизировались и терялись.
— Отсутствовала явная схема, что затрудняло анализ.
— Не было ACID-транзакций, сложно было обновлять данные.

Data Lakehouse — гибридное решение. Чтобы исправить недостатки Data Lake, появился Data Lakehouse, предложенный Databricks.

Особенности Data Lakehouse:
— ACID-транзакции (поддержка изменяемых данных, чего не было в классическом Data Lake).
— Схемы и индексация — можно добавлять структурированность, как в DWH.
— Отделение хранения и вычислений — данные хранятся в object storage, а обрабатываются SQL-движками (Spark, Trino).
— Универсальность — подходит и для аналитики, и для Data Science.

Modern Data Stack (MDS) — эволюция аналитической архитектуры
Modern Data Stack (MDS) — это современный подход к построению гибкой, масштабируемой и облачной аналитической платформы, который:
— Упрощает интеграцию данных.
— Использует облачные, plug-and-play сервисы вместо монолитных решений.
— Минимизирует затраты за счет pay-as-you-go.
— Автоматизирует процессы с минимальным кодом (low-code/no-code).

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

Архитектура Lambda
В архитектуре Lambda системы работают независимо друг от друга — пакетная обработка, потоковая обработка и слой обслуживания. Исходная система в идеале является неизменяемой и работает по принципу “только добавление”, отправляя данные в два направления для обработки: потоковую и пакетную.
Потоковая обработка предназначена для предоставления данных с минимальной задержкой, которая обычно реализуется на базе NoSQL-базы данных. В пакетном слое данные обрабатываются и трансформируются в таких системах, как хранилище данных, создавая предвычисленные и агрегированные представления данных.
Слой обслуживания объединяет результаты запросов из двух слоев, предоставляя целостный взгляд на данные.

Архитектура Kappa
В качестве ответа на недостатки архитектуры Lambda Джей Крепс предложил альтернативу — архитектуру Kappa. Ее основная идея заключается в следующем: почему бы не использовать платформу потоковой обработки в качестве основы для всех этапов работы с данными — их получения, хранения и обслуживания?

Такой подход способствует созданию истинно событийной архитектуры. Потоковая и пакетная обработка могут применяться к одним и тем же данным без лишних сложностей: данные обрабатываются в реальном времени, а для пакетной обработки можно просто воспроизвести большие объемы событий из потока.

Хотя оригинальная статья об архитектуре Kappa была опубликована в 2014 году, ее широкого распространения пока не наблюдается. Возможно, этому есть несколько причин.
Во-первых, потоковая обработка по-прежнему остается чем-то загадочным для многих компаний: о ней легко говорить, но реализовать на практике сложнее, чем кажется. Во-вторых, архитектура Kappa на деле оказывается сложной и дорогостоящей в использовании.

Архитектура The Internet of Things (IoT)
IoT — это распределенная сеть устройств: компьютеров, датчиков, мобильных устройств, умных гаджетов и любого другого оборудования, подключенного к интернету.
В отличие от данных, вводимых вручную человеком (например, с клавиатуры), данные в IoT генерируются устройствами, которые периодически или непрерывно собирают информацию из окружающей среды и передают ее в целевую систему.

— Устройства — это физическое оборудование, подключенное к интернету, которое отслеживает окружающую среду, собирает данные и передает их в целевую систему.
— Взаимодействие с устройствами — IoT-шлюз выступает в роли узла для подключения устройств и безопасной передачи данных в нужные точки в интернете. Хотя можно подключить устройство напрямую, шлюз позволяет устройствам работать с минимальным энергопотреблением.
— Получение данных (Ingestion) — Процесс начинается с IoT-шлюза, как упомянуто ранее. Далее события и измерения поступают в архитектуру приема событий.
— Хранение — Требования к хранилищу зависят в значительной степени от допустимой задержки в системе IoT.
— Обслуживание (Serving) Способы обработки и представления данных сильно различаются. В пакетных приложениях данные могут анализироваться в облачном хранилище и предоставляться в виде отчетов.

Data Mesh

Data Mesh — это современный подход, предложенный в ответ на разрастающиеся монолитные платформы обработки данных, такие как централизованные озера данных и хранилища, а также на проблему разделения операционных и аналитических данных. Этот подход стремится переосмыслить традиционную централизованную архитектуру, применяя принципы предметно-ориентированного проектирования (Domain-Driven Design), широко используемые в разработке программного обеспечения, к архитектуре данных.

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

Джамак Дегхани выделила четыре ключевых принципа Data Mesh:
— Доменно-ориентированное децентрализованное владение данными и архитектура
— Данные как продукт
— Самообслуживаемая инфраструктура данных как платформа
— Федеративное вычислительное управление

Что такое жизненный цикл работы с данными?

Жизненный цикл работы с данными содержит этапы, где мы трансформируем сырые данные из источников в финальный, готовый к использованию продукт, которым могут воспользоваться такие специалисты как: дата аналитики, data scientistы, ML инженеры. В данной главе сфокусируемся на каждом этапе, раскроем их главные концепции.

Жизненный цикл работы с данными состоит из:
— генерации данных
— загрузки и сбора данных
— трансформации данных
— предоставлении данных конечным потребителям

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

Жизненный цикл работы с данными гибок, и его этапы (хранение, сбор, преобразование) не всегда следуют строгому порядку, а могут пересекаться или происходить в разных последовательностях в зависимости от ситуации.

Фундаментом для всего жизненного цикла работы с данными являются следующие аспекты (нижняя часть диаграммы 1-1): безопасность, управление данными, DataOps, архитектура данных, оркестрация, software engineering.

Дата инженер в процессе жизненного цикла работы с данными должен преследовать следующие цели:
— обеспечить максимальную окупаемость вложенных инвестиций (ROI) при разработке и минимизировать затраты как финансовые, так и связанные с упущенными возможностями
— снизить риски, связанные с безопасностью и качеством данных
— максимизировать ценность и полезность данных необходимых бизнесу

Генерация данных. Системы источники.

Системы источники — это то место где данные изначально появляются. Дата инженер потребляет данные из источников, но при этом не является владельцем и не управляет системой источником. Ему важно понимать как данная система работает и генерирует данные, включая такие параметры как: частоту генерации новых данных, скорость, разнообразие генерируемых данных, может ли потенциально привести к проблемам с производительностью системы в результате аналитических запросов.

Также дата инженеру важно поддерживать связь с владельцами источника данных, чтобы быть в курсе о любых изменениях, которые могут прервать конвейер загрузки данных. Изменения могут быть такого характера: изменение типа данных, например, смена типа колонки в таблице БД, миграция на новую БД.

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

Другим и более современным источником данных является IoT (Internet of things) devices. Каждый девайс, например, смартфон генерирует данные (поведение пользователя в приложении — это новые сгенерированные данные). Данные представляются в виде сообщений, которые направляются в брокеры сообщений (транспорт данных между системами), которые аккумулируют их и передают в другие системы потребители.

Хранение данных

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

Частота доступа к данным
Разные типы данных имеют разные паттерны доступа в зависимости от того, как часто они извлекаются и запрашиваются. Данные классифицируются по «температуре» в зависимости от частоты доступа:
— Горячие данные. Часто запрашиваемые данные (несколько раз в день или даже в секунду), которые должны храниться для быстрого извлечения.
— Теплые данные. Запрашиваются реже, например, еженедельно или ежемесячно.
— Холодные данные. Редко запрашиваемые данные, подходящие для архивного хранения, часто сохраняемые для соблюдения требований законодательства, compliance или для восстановления после аварий.

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

Выбор системы хранения
Какой тип хранения данных вам следует использовать? Это зависит от ваших требований по их использованию, объема данных, частоты их поступления, формата и размера обрабатываемых данных — по сути, от ключевых факторов, перечисленных выше. Нет универсальной рекомендации по хранению, подходящей для всех. У каждой технологии хранения есть свои плюсы и минусы.

Загрузка, сбор данных

После того как удалось разобраться с источником данных и хранением данных, следующий шаг — это забор данных из системы. Источники данных и процессы их забора часто являются узкими горлышками в жизненном цикле работы с данными. Источники данных обычно находятся вне вашего контроля и могут стать недоступными или начать предоставлять некачественные данные. Сервисы, что загружают данные, также могут неожиданно выходить из строя, что вызывает проблемы с конвейером данных. Ненадежные источники и системы загрузки данных создают цепную реакцию проблем по всему жизненному циклу работы с данными.

Пакетная обработка против потоковой обработки
Данные постоянно генерируются и обновляются на источнике в реальном времени. Пакетная обработка больших объемов данных, например, ежедневная загрузка, часто применяется в устаревших системах. Загрузка данных через пакетную обработку задается в заранее установленные временные интервалы или в тот момент когда накапливаемые данные достигнут установленных порогов по объему. Из-за ограничений старых систем пакетная загрузка долгое время была стандартным способом обработки данных. Тем не менее, пакетная обработка по-прежнему остается очень популярным методом загрузки данных для аналитики и машинного обучения. В свою очередь, потоковая загрузка позволяет передавать данные конечным потребителям в режиме реального времени или близком к реальному с минимальной задержкой (например, менее одной секунды). Современные платформы потоковой обработки данных и разделение процесса хранения и вычисления во многих современных системах способствуют доступности и росту популярности обработки данных в реальном времени. Выбор между пакетной и потоковой обработкой зависит от конкретных задач и ожиданиями по времени готовности данных для обработки в системах потребителях.

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

Модель Push и Pull данных
В моделе push источник отправляет данные непосредственно в целевую систему, будь то база данных, объектное хранилище или файловая система. В модели pull данные извлекаются из источника.

Рассмотрим, к примеру, процесс извлечения, преобразования и загрузки данных (ETL), который часто используется в пакетных потоках загрузки данных. Часть процесса ETL, отвечающая за извлечение (E), подчеркивает, что мы имеем дело с моделью Pull данных. ETL система выполняет запрос к текущей таблице-источнику по определенному расписанию.

В другом примере рассмотрим непрерывный процесс изменения данных (CDC), который достигается несколькими способами. Один из распространенных методов, когда обращаемся к каждой измененной строке в БД. Эта строка отправляется в очередь, откуда система по загрузке данных ее забирает. Другой распространенный метод CDC использует транзакционные логи, которые фиксируют каждый commit в БД. База данных записывает каждый commit в логи, а система по загрузке данных читает эти логи, не взаимодействуя с БД напрямую. Это создает минимальную или даже нулевую дополнительную нагрузку на БД. Некоторые версии пакетного CDC используют модель pull данных. Например, в случае CDC на основе временных меток система по загрузке данных делает запрос к БД и извлекает строки, которые изменились с момента последнего обновления.

Трансформация данных

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

При преобразовании данных следует учитывать следующие вещи:
— Каковы затраты и выгода преобразования данных? Какую бизнес ценность она несет?
— Является ли трансформация простой, понятной и изолированной от остальных операций с данными?
— Какую бизнес логику имплементирует преобразование данных?

Преобразование данных может выполняться как в пакетном режиме, так и в потоковой обработке. Хотя пакетные преобразования остаются преобладающими, растущая популярность потоковой обработки и увеличение объема потоковых данных ведут к тому, что потоковые преобразования могут со временем вытеснить пакетные в некоторых областях.

Преобразование данных часто интегрируется с другими фазами жизненного цикла работы с данными. Оно может выполняться уже на стороне системы источника или «налету» во время загрузки данных. Пример: система может обогатить запись дополнительными системными полями в процессе загрузки.

Бизнес-логика — это основная движущая сила преобразования данных. Пример: продажа товара может быть выражена как бизнес-логика, которая переводится в конкретные и многократно переиспользуемые элементы. Моделирование данных важно для понимания и отражения бизнес-процессов, и важно обеспечивать стандартный подход к реализации бизнес-логики в процессе преобразования.

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

Предоставление данных конечным потребителям

Предоставление данных — это самая интересная часть жизненного цикла работы с данными. Именно здесь и происходит волшебство. Именно здесь инже­неры машинного обучения могут применить самые передовые подходы. Рассмотрим некоторые из популярных видов использования данных: аналитику, машинное обу­чение и обратный ETL.

Аналитика
Существует два типа аналитики:

1. Операционная
2. Бизнес аналитика

Бизнес аналитика (BI)
Данный тип аналитики описывает состояние бизнеса компании в прошлом или в настоящем. Бизнес аналитика требует обработки сырых данных используя бизнес логику. Как мы ранее говорили процесс обработки данных по бизнес правилам происходит на этапе трансформации данных, но помимо этого все большую популярность набирает подход применение бизнес правил при чтении данных. Данные в таком случае хранятся практически в сыром виде с минимальной постобработкой по бизнес логике. BI системы, которые читают данные из хранилищ данных, хранят репозиторий знаний о бизнес логике. При запросе данных из хранилища применяется бизнес логика для составления отчетов, дашбордов.

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

Операционная аналитика
Операционная аналитика сфокусирована на деталях состоянии бизнеса в текущее время.
В операционной аналитике данные потребляются в реальном времени напрямую из системы источника данных или из системы потоковой обработки данных. Ценность информации, полученной от операционной аналитики, отличается от традиционной бизнес аналитики тем что операционная аналитика сфокусирована на текущем состоянии бизнеса и нет задачи в поиске трендов в исторических данных.

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

Дата инженеры часто пересекаются в обязанностях с ML-инженерами и аналитиками. Они поддерживают кластеры Spark для аналитики и ML, системы оркестрации и каталоги данных. Определение зон ответственности между инженерией данных и ML — ключевое организационное решение.

Хранилища признаков (feature stores) помогают уменьшить нагрузку на ML-инженеров, сохраняя историю и версии признаков и обеспечивая совместное их использование между командами. Инженеры данных играют важную роль в поддержке хранилищ признаков.

Инженеры данных должны понимать основы ML, связанные с ними требования к обработке данных и задачи аналитических команд. Это помогает наладить коммуникацию, сотрудничество и создавать инструменты, которые объединяют усилия команд. Перед внедрением ML важно оценить качество данных, их доступность и соответствие реальности.

Обратный ETL

Обратный ETL — это процесс, при котором обработанные данные из хранилища данных возвращаются в исходные системы, такие как CRM или SaaS-платформы. Хотя раньше эта практика считалась нежелательной, сегодня она признаётся полезной и часто необходимой для бизнеса.
Примеры использования обратного ETL:
— Реклама и маркетинг: Аналитики рассчитывают ставки в Excel на основе данных из хранилища, а затем вручную загружают эти данные в Google Ads.
— CRM и платформы управления клиентами: Компании передают метрики и аналитические данные обратно в CRM для улучшения взаимодействия с клиентами.
— Модели и аналитика: Данные аналитики или результаты моделей машинного обучения возвращаются в системы источники для дальнейшего использования.

Основные практики, протекающие через весь жизненный цикл работы с данными

Безопасность

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

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

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

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

Управление данными

Управление данными — это обеспечение качества, целостности, безопасности и удобства использования данных, собранных организацией, благодаря этому извлекается максимальная ценность из данных для бизнеса. Управление данными помогает компаниям избегать проблем с недоверием к ним и упрощает процесс принятия решений. Для эффективного управления данными необходимы люди, процессы и технологии.
Если управление данными организовано плохо, это может привести к таким ситуациям:
— Аналитик получает запрос на отчет, но не знает, какие данные использовать.
— Он тратит часы на поиск нужных таблиц, делая предположения.
— Итоговый отчет получается неполным и сомнительным.
— Это вызывает недоверие к данным в целом и осложняет бизнес-планирование

Управление данных подразделяется на следующие категории:
— Обнаружение данных (Discoverability): Возможность находить нужные данные
— Безопасность (Security): Защита данных от несанкционированного доступа.
— Ответственность (Accountability): Определение, кто отвечает за данные.

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

Метаданные — это данные о данных, которые являются основой для всего жизненного цикла работы с данными. Используя метаданные дата инженеры проектируют потоки данных, управляют данными через весь жизненный цикл работы с данными, и убеждаются что данные использованы правильно.
Основные категории метаданных:
— Бизнес метаданные. Позволяет понять как данные используются в бизнес контексте, включая бизнес правила, определения
— Технические метаданные. Описывают создание и использование данных в процессе инженерии данных. Включают модель данных, происхождение и схему данных.
— Операционные метаданные. Относится к операционным системам, включают статистику работы заданий, логи, отслеживание ошибок, мониторинг успешного или неуспешного выполнения заданий
— Справочная информация. Редко меняющиеся данные, которые используются для классификации других данных, например, единицы измерения, налоговые ставки, коды валют, стран и т. д. Благодаря справочным данным все источники данных в организации буду классифицировать одинаковым образом, что повышает согласованность и их качество

Мастер данные — это данные о ключевых бизнес сущностях организации, таких как сотрудники, клиенты, продукты и т. д. Управление мастер-данными (MDM) — это практики создания последовательных определений сущностей, известных как «золотые записи», поддерживающиеся технологическими инструментами, приводящие данные из разных источников, форматов к единому стандарту или структуре по всей организации. Это необходимо для обеспечения согласованности, точности и совместимости данных. Данный процесс может прямо входить в сферу ответственности дата инженеров, но часто является задачей отдельной специализированной команды. В качестве примера команда MDM может определить стандартный формат адресов клиентов, а затем работать с инженерами для создания API, который будет возвращать согласованные адреса, систем, использующие данные об адресах для сопоставления записей клиентов между подразделениями компании.

Ответственность за данные
Ответственность за данные — это назначение контактного лица для управления конкретной порции данных. Контактные лица обеспечивают согласованность, качество, доступ, корректное и понятное описание, защиту от несанкционированного доступа, соответствие регуляторным требования данных, координацию по управлению данными с другими заинтересованными лицами. Объектами, за которыми закреплены ответственные, могут быть как отдельные таблицы, потоки данных, так и конкретные поля в таблицах. Не всегда дата инженеры являются ответственными за данными, ими могут быть и software engineers, и product owners, и другие роли.

Качество данных
Качество данных — это целостный, непрерывный процесс, требующий сочетания человеческих и технологических усилий, постоянного мониторинга, проверки, обратной связи с пользователями и четких определений данных, чтобы гарантировать, что данные точны, полны, согласованы и надежны
Качество данных определяется тремя ключевыми аспектами:
— Точность: Данные должны быть правильными, без дубликатов и с точными числовыми значениями
— Полнота: Записи должны быть полными, и все необходимые поля должны содержать допустимые значения
— Согласованность: Данные должны быть согласованы в разных системах

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

Происхождение данных (Data Lineage)
По мере того как данные проходят через жизненный цикл работы с данными, они изменяются через преобразования и комбинации с другими данными. Бывает сложно понять, как был получен определенный набор данных. Инструменты происхождения данных помогают инженерам понять предыдущие шаги трансформации, а также их источники. Важно отслеживать происхождение и изменения данных, их зависимости с течением времени, потому что это помогает отслеживать ошибки, решать инциденты, находить ответственных за данные и отлаживать данные при разработке систем, которые их обрабатывают.

DataOps

DataOps — это совокупность практик, культурных норм и архитектурных паттернов.
DataOps имеет три основные технические составляющие: автоматизация, мониторинг и наблюдаемость, а также реагирование на инциденты.

Автоматизация в DataOps имеет схожий воркфлоу что и у DevOps, состоящий из управления изменениями (управление окружением, кодом и версиями данных), непрерывной интеграции и развертывания (CI/CD) и конфигурации приложения через код. Как и в DevOps, практики DataOps следят за надежностью технологий и систем (потоки данных, оркестрация и т. д.), но еще и проверкой качества данных, перекосом данных и целостностью метаданных.
Мониторинг и наблюдаемость критически важны для своевременного выявления любых проблем на протяжении всего жизненного цикла работы с данными. Мониторинг, логирование, нотификация — все это играет важную роль. Рекомендуется внедрять SPC (Statistical Process Control), чтобы понимать, являются ли отслеживаемые события отклонениями от нормы.
Реагирование на инциденты — это симбиоз использования возможностей автоматизации и мониторинга для быстрого выявления причин инцидента и устранения его последствий. Можно выделить следующие аспекты:
— Реагирование на инциденты — это не только про технологии и инструменты, но и открытая, лишенная обвинений коммуникация как среди дата инженеров, так и на уровне всей организации
— дата инженеры должны быть подготовленными к возникновению аварий и оперативно действовать для быстрого восстановления работы системы
— дата инженеры должны проактивно находить проблемы до того, как о них сообщит бизнес

Архитектура данных

Архитектура данных отражает текущее и будущее состояние дата систем, удовлетворяющих долгосрочные потребности и стратегию организации в области данных. Поскольку требования организации к данным, вероятно, будут быстро изменяться, а новые инструменты и практики появляются почти ежедневно, дата инженерам стоит разбираться в проектировании хороших архитектур данных.

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

Оркестрация

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

Software Engineering

Software Engineering всегда был ключевым навыком для дата инженеров. В ранние годы инженерии данных (2000—2010) инженеры работали с низкоуровневыми фреймворками и писали задачи MapReduce на C, C++ и Java. В разгар эпохи больших данных (середина 2010-х годов) инженеры начали использовать фреймворки, которые абстрагировались от низкоуровневых деталей. Использование абстракций продолжается и сегодня, поскольку облачные хранилища данных поддерживают мощные преобразования данных, используя SQL, Spark. Несмотря на это, software engineering по-прежнему остается критически важным аспектом для дата инженеров.

Разработка open-source фреймворков
Многие дата инженеры активно вносят вклад в разработку open-source фреймворков для решения конкретных задач в жизненном цикле обработки данных, а затем продолжают дорабатывать их код, улучшая инструменты под свои задачи и внося вклад в сообщество. Хорошими примерами таких фреймворков являются фреймворки экосистемы Hadoop и оркестратор Apache Airflow. Прежде чем дата инженеры начнут разрабатывать новые внутренние инструменты, им стоит изучить существующие решения. Есть большая вероятность, что уже существует open-source проекты, решающий их проблему, и лучше присоединиться к его развитию, чем изобретать велосипед заново.

На практике, независимо от того, какие высокоуровневые инструменты используют дата инженеры, они неизбежно сталкиваются с необычными случаями в течение жизненного цикла обработки данных, которые требуют выхода за рамки возможностей выбранных инструментов. При работе с фреймворками, такими как Fivetran, Airbyte или Matillion, дата инженеры могут столкнуться с источниками данных, для которых нет готовых коннекторов, и тогда им придется разрабатывать их самостоятельно. Для этого важно владеть навыками программирования, чтобы разбираться в API, извлекать и преобразовывать данные, обрабатывать исключения и решать другие задачи, выходящие за рамки стандартного функционала инструментов.