Системы хранения и обработки больших данных

Архитектурные подходы к построению хранилища данных

Что такое хранилище данных и для чего оно нужно

Хранилище данных – это набор технологий, который обеспечивает сбор и централизованное хранение информации в масштабах компании.

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

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

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

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

Как построить хранилище данных

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

Хранилища данных первого поколения. Традиционный подход

Традиционная архитектура хранилищ данных использовалась практически во всех крупных компаниях на заре их появления — в конце 80-х годов. У истоков стояли пионеры проектирования хранилищ данных — Ральф Кимбалл и Билл Инмон.

Традиционный подход подразумевает извлечение данных из систем-источников специальными ETL (extract-transform-load)-инструментами, их преобразование и загрузку в централизованное хранилище.

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

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

Недостатки традиционного подхода к построению хранилищ данных:

• отсутствие горизонтального масштабирования. В качестве технологии хранения использовалась СУБД на базе SMP-архитектуры (Symmetric MultiProcessing), и масштабирование платформы предполагало замену практически всей инфраструктуры;
• долгая обработка. Данные должны не просто загружаться в хранилище, но и трансформироваться в удобный для аналитических систем вид, обогащаясь при этом дополнительной информацией. С момента возникновения данных во front-end системе до момента возможности их использования в бизнес-анализе проходило продолжительное время (до 24 часов);
• высокая стоимость инфраструктуры для обеспечения отказоустойчивости. Аппаратная отказоустойчивость в SMP-архитектуре реализуется по модели взаимодействия вычислительных комплексов «master/slave» («ведущий/ведомый»), что подразумевает наличие сервера, который дублирует основной. Также для обеспечения отказоустойчивости должна использоваться дорогая система хранения данных типа NAS (Network Attached Storage) или SAN (Storage Area Network) с дублированием для обоих серверов в модели взаимодействия «master/slave».

Хранилища данных второго поколения

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

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

Появление Apache Hadoop привело к возникновению термина Data Lake (озеро данных). Его автором стал Джеймс Диксон. Идея Data Lake заключалась в том, чтобы интегрировать Hadoop-решение в уже существующую legacy-архитектуру компании с целью ускорить обработку большого объема информации и решить проблему хранения данных. Legacy-архитектура — это архитектура с унаследованными системами, методами и технологиями, которые пока не выведены из эксплуатации, не могут быть перепроектированы по разным причинам и используются до сих пор. Технологическое решение Apache Hadoop позволяет выстраивать архитектуру хранилища без сложных процессов перепроектирования систем, которые по сути являются накопившимся техническим долгом компании.

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

Преимущества проектирования EDWH с использованием Hadoop:

• распределенная обработка данных и соответственно возможность горизонтального масштабирования кластера Hadoop посредством добавления новых недорогих узлов оборудования массового класса;
• снижение общей нагрузки на дорогостоящие front-end системы и хранилище данных;
• относительно невысокая стоимость за счет открытого исходного кода Hadoop и разработки его для повсеместно используемого оборудования.

Недостатки:

• отсутствие четкого дизайна, что приводит к общей сложности экосистемы Hadoop: при появлении Data Lake в компании обычно начинается лавинообразная загрузка всех имеющихся данных, в результате теряется смысл данных, пропадают связи между ними, а, учитывая, что со временем бизнес-процессы эволюционируют и вслед за этим изменяются структуры хранения данных в системах-источниках, нарушение структурированности данных превращает Data Lake в Data Swamp (болото данных);
• проблема конкурентного доступа к данным существует в большинстве продуктов на платформе Hadoop. Когда одна сессия читает таблицу, а другая — пытается записать в нее данные, то либо падает запрос, либо блокируется таблица. Речь про таблицы идет в контексте тех фреймворков Hadoop, которые имитируют работу СУБД. Поддержка требований ACID (Atomicity, Consistency, Isolation, Durability) к СУБД реализована только в старших версиях Apache Hive (реляционная СУБД в рамках платформы Hadoop) и является очень лимитированной;
• при операциях обновления данные в исходном файле не изменяются, а создается некоторый новый файл, дельта-файл, в котором отмечается, какие строки были изменены и как. Такая реализация возможностей ACID делает Apache Hive неустойчивой к высоким нагрузкам при изменении данных, т.е. возникает проблема с производительностью, а это значит, что сами требования ACID поддерживаются лишь номинально;
• длительная обработка. С момента возникновения данных во front-end системе до момента возможности их использования для в хранилище данных проходит значительное время;
• проблема с аварийным восстановлением. В Hadoop эта проблема не до конца решена, несмотря на наличие инструмента отказоустойчивости.

Хранилища данных третьего поколения

Основным драйвером развития нового подхода послужило появление систем класса MPP (Massive Parallel Processing, множество компьютеров работают параллельно каждый со своей памятью), а также возможность использования потоковой передачи данных (streaming) для обеспечения доступности в режиме реального времени.

Совмещение этих двух технологических подходов дало возможность переносить данные из систем-источников в мощное хорошо масштабируемое технологическое решение класса MPP в режиме реального времени. На такой архитектуре появились большие промышленные СУБД типа GreenPlum, Vertica, Teradata, которые внедряются во множестве крупных компаний.

В хранилищах этого поколения с целью обеспечения данными реального времени осуществляется переход от ETL-процессов (extract-transform-load) к ELT-процессам (extract-load-transform): сначала данные извлекаются и загружаются в отдельный слой хранилища, и лишь после этого происходит их преобразование. Такой подход дает возможность получить копию исходных данных системы-источника и дальше производить над ними манипуляции, не нагружая систему. Такая концепция подразумевает наличие в хранилище нескольких слоев данных.

• Raw Data — сырые данные, хранящиеся в структурах, максимально близких к структурам системы-источника;
• ODS (Operational Data Store) — детальные данные, хранящиеся в структурах единой модели данных хранилища;
• Data Marts — витрины и отчеты.

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

Чтобы максимально сократить отставание данных в хранилище на стороне системы-источника необходимо применять технологию класса CDC (Change Data Capture, сбор измененных данных), которая воспроизводит изменения систем-источников на удаленном решении, в том числе — на MPP-платформе.

Преимущества подхода:

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

Как встроить хранилище данных в общий IT-ландшафт компании? Методология Data Mesh

В архитектурных моделях, которые мы применяем в хранилищах данных, существует ряд проблем:

1) плохая масштабируемость в связи с большим количеством источников и большими объемами данных — чем больше данных становится доступными в источниках, тем меньше способность хранилища собирать, согласовывать и контролировать их, при этом по-прежнему следует отделять данные из информационных систем, обслуживающих операционные потребности бизнеса, от данных, используемых в аналитических целях;

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

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

Data Mesh объединяет парадигму хранилищ данных третьего поколения в концепцию создания нескольких слоев данных и применения продуктового мышления в отношении самих данных.

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

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

Нагрузка на оперативные системы

Нагрузку, которую испытывает на себе почти любая оперативная система, можно условно поделить на четыре блока:

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

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

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

Интеграционная нагрузка на оперативные системы

Между информационными системами существует два способа обмена данными: точка-точка и публикация-подписка.

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

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

Интеграция систем по методам «точка-точка» и «публикация/подписка» внутри могут быть устроены похоже. Например, при обмене данными в режиме реального времени. В этом случае, при появлении изменившихся данных, система инициирует получение этих данных получателем, то есть работает по принципу «push». Альтернатива — принцип «pull», когда инициатором получения данных становится система-получатель. В обоих случаях источник и потребитель взаимодействуют без промежуточного звена.

Интеграция систем по методу «точка-точка» привлекает простотой. Однако у этого способа есть серьезный недостаток: потенциально высокая, плохо прогнозируемая наведенная нагрузка от сторонних систем, которая будет только расти с ростом потребности в данных системы-источника.

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

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

Единое интеграционное пространство обеспечивает данными множество систем-потребителей, в том числе и слой Raw Data хранилища, при этом нагрузка на систему-источник будет минимальна.

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

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

Преимущества подхода единого интеграционного пространства:

• экономия ресурса на реализацию сложной паутины межсистемной интеграции, потому что вся информация из систем-источников загружается централизованно;
• стандартизированность. Процессы доступа к данным со стороны систем-потребителей не зависят от технологической платформы системы-источника. С точки зрения системы-источника интеграция реализуется по методу «публикация-подписка», которая гарантирует отсутствие наведенной нагрузки от множества систем-потребителей. С точки зрения систем-потребителей, интеграция может быть реализована как по методу «публикация-подписка», так и по простейшему методу «точка-точка» со слоем Raw Data хранилища, где доступна максимально возможная глубина данных без риска критического влияния на оперативные системы компании;
• проверка на чистоту данных. Все порции, которые загружаются через брокера сообщений в слой Raw Data, проходят в отдельном слое сервисных операций проверку на консистентность с использованием специализированных средств мониторинг и оповещения систем-источников в случае возникновения проблем;
• объединение сотрудников, так как при создании единого интеграционного пространства появляются точки взаимодействия продуктовых команд из разных предметных областей компании.

Вывод

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

Заключение

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