Модернизация корпоративных данных: Hadoop, Netezza и смена платформенной стратегии

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

В среде данных любого крупнейшего банка вы найдёте исторические наслоения. Мейнфрейм. Хранилище Oracle, приобретённое в 2000-х. Комплекс Netezza, купленный ради регуляторной отчётности. Кластер Hadoop, развёрнутый аналитиками. Задачи SAS. Tableau. SQL Server. Растущее присутствие Azure или AWS. Каждый слой был правильным ответом на чью-то задачу в день приобретения.

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

Hadoop как стратегическая зона приёма данных

Hadoop стал стратегической ставкой для новых задач и неструктурированных данных. Схема при чтении позволяла принимать исходные данные без предварительного согласования целевой схемы; HDFS и Hive metastore обеспечили единое физическое место для междоменных соединений; открытая экосистема (Spark, Hive, Impala, аналитические блокноты) дала отдельным командам аналитиков нужную гибкость без развёртывания специализированной инфраструктуры.

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

Netezza как рабочая лошадка для тактических задач

Netezza не нуждалась в замене. Нужно было перестать нагружать её задачами, для которых она не предназначена. Этот комплекс по-прежнему отлично выполняет свои задачи: структурированные SQL-операции над множествами с предсказуемой формой запросов к таблицам фактов терабайтного масштаба. Регуляторные витрины, финансовая отчётность, агрегация рисков — всё это подходило Netezza и осталось на ней.

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

Дерево решений для выбора платформы

Для согласования платформ под новые инициативы нужно воспроизводимое дерево решений, а не совещание. Мы использовали такое:

• Это регуляторная отчётность по моделируемой витрине? → Существующий стек хранилищ (Netezza или Oracle).
• Задача принимает исходные события с гибкой схемой? → Зона приёма данных Hadoop.
• Это транзакционная задача? → Операционная база данных, а не аналитические хранилища.
• Это исследовательский анализ в блокнотах? → Hadoop с доступом только для чтения к моделируемым витринам через федерацию.
• Набор данных новый, а потребитель изначально облачный? → Облачная платформа данных с продуманным односторонним потоком обратно в локальную среду.

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

Управление без бюрократии

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

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

Что это означает для вашей стратегии данных

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

Пересматриваете свою среду данных?

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