Большая часть корпоративных данных находится в большем количестве мест, чем может показать любой слайд стратегии. В крупной компании транзакционные записи могут храниться в локальном источнике данных, маркетинговые данные — в Salesforce, продуктовая аналитика — в Snowflake, журналы событий — в облачном озере данных, а еще в десятке других SaaS-инструментов, каждый из которых содержит часть общей картины. Распространенный совет выбрать одно облачное хранилище и перенести туда всё предполагает уровень единообразия, которого у большинства предприятий нет и в ближайшее время не предвидится.

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

Почему стратегии, основанные на консолидации, буксуют

Полная миграция в хранилище данных выглядит логично на бумаге. На практике она обычно сталкивается с одним и тем же набором проблем.

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

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

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

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

Стратегия, основанная на федерации, а не на миграции

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

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

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

Управление без создания второй копии всего

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

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

Как это выглядит локально

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

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

Как это выглядит на практике

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

С чего начать

Гибридная стратегия работы с данными требует иного набора первоначальных вопросов, чем те, что задаются стандартными парадигмами архитектуры данных. К ним относятся следующие.

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

Стратегия, которая соответствует данным, которые у вас есть на самом деле

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

Узнайте больше о том, как гибридные данные могут сочетаться с локальными данными и данными из lakehouse. Скачайте наше руководство покупателя по Lakehouse.