Архитектуры данных эпохи цифровой революции

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

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

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

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

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

— Многие крупные организации уже вложили большие средства в прежние архитектуры данных. Не приведет ли промедление с их обновлением к проблемам в бизнесе?

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

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

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

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

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

— Что нужно предпринять организациям, чтобы их архитектуры данных соответствовали потребностям их бизнеса и не превращались в закрытый от посторонних глаз «черный ящик» и в «черную дыру» для инвестиций?

Это одна из основных проблем управления данными. Были времена, когда организациям нравились технологии одного известного вендора реляционных СУБД, и очень многие опирались именно на них. Потом началось всеобщее увлечение идеями, которые реализовал другой вендор, и все дружно осваивали его технологии и создавали на их основе хранилища данных. С наступлением «золотой лихорадки» вокруг больших данных многие бросились внедрять Hadoop и озера данных.

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

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

— В каких случаях разумно использовать архитектуру Data Mesh? Насколько сложно ее реализовать и какие выгоды можно в этом случае получить?

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

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

— Когда полезно применять архитектуру логических графов знаний (Logical Knowledge Graph)? Какое окружение — технологическое, процессное, организационное — требуется, чтобы эта архитектура работала эффективно?

На мой взгляд, эта архитектура, по сути, является очередным шагом эволюции управления основными данными (Master Data Management, MDM). Граф знаний — это «золотая» запись с базовой информацией о некоей сущности (клиенте, автомобиле, объекте недвижимости и пр.), соединенной с другими подобными записями посредством семантических связей. Такая взаимосвязанность открывает широкие возможности для проведения глубокого анализа и глубокой предиктивной аналитики. Это достаточно молодая, стремительно развивающаяся область. Тем не менее, уже есть интересные успешные примеры того, какие фантастические результаты можно получить, объединив данные из различных доменов с помощью семантических графов. Это несколько другой подход по сравнению с теми, что мы видели раньше, он основан на других идеях, видении и инструментарии. Реализовать его достаточно быстро и с относительно невысокими затратами можно, используя платформу виртуализации данных — она позволит очень гибко менять представление данных из различных источников и доменов.

— Каковы, на Ваш взгляд, дальнейшие перспективы развития архитектур больших данных?

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

Источник