#DataOps. Конвейер обработки данных

Пару дней назад PC Week/RE опубликовал перевод статьи Джорджа Анадиотиса Как работает DataOps — эквивалент DevOps в мире данных. В ней, как и во многих статья о постепенно обретающем популярность термине dataops, какие-то идеи понятны и очевидны, а какие-то только лишь слегка оконтурены, настолько абстрактны и общи, что и обсуждать их нет никакого смысла. Впрочем, даже статья про dataops в Википедии перечисляет целых двадцать принципов, характеризующих этот термин, что скорее свидетельствует об отсутствии единого его понимания. Думаю, что в ближайшем будущем нам не избежать споров о том, что же такое DataOps, но через некоторое время новая концепция сбора и обработки данных в организациях оформится и со временем потеснит столь привычную многим метафору корпоративного хранилища данных.

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

Но сначала напомню, что ключевые принципы оригинальной концепции DevOps собраны в так называемых The Three Ways (см. например The Three Ways: The Principles Underpinning DevOps by Gene Kim)

Первый путь, иногда называемый Flow, акцентирует наше внимание на потоке создания ценности (реализуемом тем самым автоматизированным конвейером доставки) и необходимости думать не об отдельных этапах, а производительности цепочки в целом. У многих он ассоциируется с CI/CD – непрерывной интеграцией и поставкой.

Второй путь подчеркивает важность наличия замкнутой петли обратной связи.

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

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

Прежде всего нам нужно ввести ограничение на источники данных с которыми мы будем работать. Далее везде мы будем предполагать, что данные организованы в соответствии с паттерном Event Sourcing.

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

Второй момент. Мы рассматриваем источники данных как сторонние подключаемые службы. Backing Services говоря языком The Twelve-Factor App Т.е. источники и потребители данных свободно подключаются к сценарию обработки. Практически, как резервуары с водой к корпоративному кулеру или кофе-машине. Какие-то емкости опустошаются в ходе работы сценария, какие-то наполняются данными. Сценарию обработки, в принципе, безразлично какой резервуар к нему подключат, главное соответствие интерфейсам. Мы можем запускать один и тот же сценарий как на небольших тестовых выборках данных из ста записей, так и на массивах с миллиардами записей. Впрочем, в этом случае нам может оказаться полезным разделить такой массив на несколько частей и для каждой запустить отдельный экземпляр сценария обработки (практически map-reduce).

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

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

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

Реклама

One Comment

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s