Оркестрация данных: от фрагментации данных к совместной работе

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

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

Состояние оркестровки данных

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

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

- Множество направлений, заинтересованных сторон и вариантов использования продуктов данных.

- Разнородные инструменты и процессы, связанные с созданием конечного продукта.

В типичном стеке данных есть несколько компонентов, которые помогают организовать эти распространенные сценарии.

Компоненты

Преобладающая в отрасли схема обработки данных известна как «извлечение, загрузка и преобразование» или ELT. Данные (E) извлекаются из вышестоящих источников, (L) загружаются непосредственно в хранилище данных и только затем (T) преобразуются в различные представления, специфичные для предметной области. Существуют варианты, например ETL , который выполняет преобразования перед загрузкой в хранилище. Все подходы объединяет три возможности высокого уровня: усвоение, преобразование и обслуживание. Оркестрация необходима для координации между этими тремя этапами, а также внутри каждого из них.

Проглатывание

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

Трансформация

Типичные примеры преобразований включают распаковку и очистку данных от их исходной структуры, а также их разделение или объединение в модель, более тесно связанную с бизнес-сферой. SQL и Python — наиболее распространенные способы выражения этих преобразований, и современные хранилища данных обеспечивают для них отличную поддержку. Роль оркестрации на этом этапе заключается в определении последовательности преобразований для эффективного создания моделей, используемых заинтересованными сторонами.

Обслуживание

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

Рисунок 1. Типичный поток данных из источников через хранилище данных в приложения конечного пользователя.

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

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

Инструменты

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

По мере усложнения процессов становится ценным сделать явные зависимости между ними. Это то, что обеспечивают механизмы рабочих процессов , такие как Apache Airflow. Airflow и подобные системы также часто называют «оркестраторами», но, как мы увидим, они не являются единственным подходом к оркестровке. Механизмы рабочих процессов позволяют инженерам данных указывать явный порядок выполнения задач. Они поддерживают выполнение запланированных задач так же, как cron а также может отслеживать внешние события, которые должны вызвать запуск. Помимо повышения надежности конвейеров, общий обзор зависимостей, которые они предлагают, может улучшить видимость и обеспечить больший контроль над управлением.

Иногда само понятие «задача» может быть ограничивающим. Задачи по своей сути будут работать с пакетами данных, но мир потоковой передачи зависит от единиц данных, которые передаются непрерывно. Многие современные платформы потоковой передачи построены на основе модели потока данных , Apache Flink популярным примером является. Этот подход отказывается от последовательности независимых задач в пользу создания более детальных вычислений, которые могут работать с фрагментами любого размера.

От оркестровки к композиции

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

Компонуемые системы данных

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

Открытые стандарты

Открытые стандарты форматов данных находятся в центре движения компонуемых данных. Apache Parquet стал де-факто форматом файлов для столбчатых данных, а Apache Arrow — его аналогом в памяти. Стандартизация этих форматов важна, поскольку она сокращает или даже устраняет дорогостоящие этапы копирования, преобразования и передачи, которые мешают многим конвейерам данных. Интеграция с системами, которые изначально поддерживают эти форматы, обеспечивает «совместное использование данных» без всякого связующего кода. Например, процесс приема может записывать файлы Parquet в объектное хранилище, а затем просто передавать путь к этим файлам. Нижестоящие службы смогут получить доступ к этим файлам без необходимости создания собственных внутренних копий. Если рабочей нагрузке необходимо обмениваться данными с локальным процессом или удаленным сервером, она может использовать Arrow IPC или Arrow Flight с практически нулевыми издержками.

Стандартизация происходит на всех уровнях стека. Apache Iceberg и другие форматы открытых таблиц развивают успех Parquet, определяя макет для организации файлов, чтобы их можно было интерпретировать как таблицы. Это добавляет тонкую, но важную семантику к доступу к файлам, которая может превратить коллекцию файлов в принципиальное хранилище данных. В сочетании с каталогом, таким как недавно запущенный Apache Polaris , организации получают средства управления для создания авторитетного источника правды, одновременно получая выгоду от совместного использования с нулевым копированием, которое обеспечивают базовые форматы. Силу этого сочетания невозможно переоценить. Когда источник достоверной информации в бизнесе полностью совместим с остальной частью экосистемы, значительной степени оркестрации можно добиться, просто обмениваясь данными, а не создавая громоздкие процессы подключения.

Рисунок 2. Система данных, состоящая из открытых стандартов

После того как данные записаны в объектное хранилище в виде Parquet, их можно использовать совместно без каких-либо преобразований.

Деконструированный стек

Системам данных всегда приходилось делать предположения о форматах файлов, памяти и таблиц, но в большинстве случаев они были скрыты глубоко в их реализациях. Узкий API для взаимодействия с хранилищем данных или поставщиком услуг данных обеспечивает чистый дизайн продукта, но не расширяет возможности выбора, доступные конечным пользователям. Рассмотрим рисунки 1 и 2, на которых изображены системы данных, предназначенные для поддержки аналогичных бизнес-возможностей.

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

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

Заключение

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