В любой современной организации данные давно стали частью операционных, технологических и управленческих процессов. Разница лишь в масштабе и сложности: одним компаниям достаточно нескольких относительно компактных баз, другим приходится работать с десятками систем, которые внедрялись в разное время, под разные задачи и в составе разных решений.
Проблема начинается, когда данных становится так много, что прежняя архитектура перестает выдерживать изменения: появляются новые источники, ускоряются бизнес-процессы, растет стоимость хранения и обработки, а каждое изменение в модели данных требует пересмотра уже принятых решений. Как быть, когда архитектурные подходы организации данных, такие как DWH, Data Fabric, Data Lake, Снежинка, Data Vault, Anchor Modeling и другие, перестают отвечать требованиям и почему под давлением динамично меняющихся обстоятельств стройные концепции постоянно нарушаются?
Сегодня мы разберем, почему выбор стратегии работы с большими данными стал архитектурной задачей, как менялись подходы к построению платформ данных, что такое гравитация данных и какие требования стоит предъявлять к современным решениям.
Когда данные становятся большими
Привет, Хабр! Меня зовут Владимир Пугачев, я главный архитектор больших данных в Cloud X. О самом термине, и о том, когда данные следует считать «большими», идет много споров — в том числе и научных. Но у нас нет времени дожидаться консенсуса сообщества. В проектах, с которыми мы работаем, хорошо видно: категории данных, которые еще недавно считались обычными, сегодня требуют подходов уровня Big Data. Поэтому на практике мы смотрим на сочетание трех факторов: размер, скорость и разнообразие.
Первый фактор — объем. Данные накапливаются быстрее, чем компании успевают пересматривать архитектуру хранения и обработки. Чем больше исторических, транзакционных, технических и пользовательских данных оказывается в контуре, тем заметнее становятся ограничения старых решений.
Второй фактор — скорость. Данные поступают непрерывно, а ожидания бизнеса по времени реакции сокращаются. Если ETL-процессы начинают конкурировать за окна обработки, отчеты задерживаются, а сервисы деградируют под нагрузкой, значит проблема уже вышла за рамки простой оптимизации запросов.
Третий фактор — разнообразие. Наряду со структурированными реляционными данными компании работают с событиями, логами, медиа, полуструктурированными документами и потоками телеметрии. Чем шире спектр форматов и сценариев использования, тем сложнее удерживать данные в одной архитектурной модели.
Практический вывод простой: большие данные — это не только вопрос размера. Это ситуация, в которой прежние способы хранения, интеграции и обработки перестают давать предсказуемый результат по срокам, стоимости и качеству.
Как менялись архитектурные подходы
Чтобы выбрать стратегию, полезно посмотреть на эволюцию платформ данных: каждый следующий подход возникал как ответ на ограничения предыдущего.
Операционное хранилище данных (ODS) решало задачу согласованного оперативного представления данных для текущих бизнес-процессов. Оно могло выступать буфером перед долгосрочным хранилищем, но плохо подходило для сложной аналитики и при постоянном опросе источников создавало дополнительную нагрузку на операционные системы.
DWH стало следующим шагом: единое хранилище структурированных данных из разрозненных систем, ориентированное на отчетность, бизнес-аналитику и управленческие решения. Но у классического DWH есть понятные ограничения: высокая стоимость проектирования, длительный цикл изменений, зависимость от качества модели и задержка обновления данных.
Для интерактивного анализа долго использовались OLAP-кубы. Они удобны, когда бизнесу нужны срезы, агрегации и детализация по иерархиям. Однако по мере роста объемов и числа сценариев кубы становятся тяжелыми в подготовке и поддержке: скорость обновления падает, а новые вопросы бизнеса требуют все большего объема предварительного моделирования.
Крупные компании в свое время начали массово внедрять хранилища с архитектурой Data Lake. Основная идея состояла в том, чтобы распределить данные по множеству средних по мощности узлов и хранить структурированные и неструктурированные данные в одном месте — с надеждой на то, что фреймворки распределенных вычислений, такие как Apache Spark, закроют основные потребности. Но стратегия близости вычислений к данным со временем начала давать сбой. Узлы приходилось использовать все более дорогие и мощные, а хранение, например, реляционных данных в, по сути, файловой системе давало ощутимый «оверхед». В интернете постепенно начали появляться статьи на тему «жив ли еще Hadoop».
В настоящее время основными архитектурами платформ данных признаны Data Lakehouse и завоевывающий популярность Data Streamhouse. Одна из главных парадигм новых архитектур – не объединять в одном технологическом решении весь функционал, а использовать взаимосвязанные решения, наиболее предназначенные для конкретных направлений.
Иными словами, задача современных архитектур не в том, чтобы снова собрать весь функционал в одной точке, а в том, чтобы разделить роли компонентов: потоковая обработка, горячее хранение, аналитическое хранилище, долгосрочный архив и витрины данных должны работать согласованно, но не обязательно в одном монолите. Такой подход позволяет бороться с проблемой гравитации данных.
Что такое гравитация данных
Гравитация данных — один из ключевых факторов, который приходится учитывать архитекторам. Чем больше данных сосредоточено в одном месте, тем сильнее к этому месту начинают “притягиваться” сервисы, процессы и команды. Так проще снижать задержки, повышать пропускную способность и не гонять большие массивы по сети.
На раннем этапе это выглядит рационально. Но со временем система становится все менее подвижной. «Сила притяжения» становиться настолько велика, что когда возникает вопрос переработки архитектуры решений из-за практической невозможности горизонтального и вертикального масштабирования, то, например, для выделения одного микросервиса требуются колоссальные затраты ресурсов. Данные начинают определять архитектуру сильнее, чем бизнес-требования.
Чтобы контролировать гравитацию данных, надо отказаться от заманчивой идеи централизованного хранилища, которое является репликой всех данных компании. Вместо этого нужны распределение данных по уровням, понятные правила владения, архивирование, удаление неиспользуемых наборов, управление метаданными и осознанный выбор места, где выполняются вычисления.
Каким должно быть решение для больших данных
Требования к платформе больших данных важно формулировать как проверяемые инженерные критерии. Ниже — пять критериев, которые чаще всего оказываются критичными на промышленных проектах.
1. Enterprise-ready. Решение должно быть готово к эксплуатации в крупном контуре: с понятной отказоустойчивостью, мониторингом, обновлениями, управлением доступом, SLA и поддержкой. Возможность “поднять кластер в несколько кликов” имеет ценность только тогда, когда за ней стоит понятный порядок промышленной эксплуатации.
2. Кастомизация. В enterprise-среде редко бывает достаточно продукта “как есть”. Нужны адаптация под требования безопасности, интеграция с существующими системами, учет ограничений по инфраструктуре и возможность менять конфигурацию под реальные рабочие нагрузки.
3. Геораспределенность. Для компаний с распределенной инфраструктурой важно не только хранить данные в разных локациях, но и управлять согласованностью, задержками, доступностью и правилами размещения данных. Здесь особенно заметны компромиссы между производительностью, стоимостью и требованиями к надежности.
4. Центр компетенций. Платформа больших данных — это не только набор сервисов. Заказчикам часто нужен доступ к экспертам, которые понимают внутреннюю архитектуру решения, могут помочь с проектированием, миграцией, оптимизацией запросов и разбором инцидентов.
5. Пилотирование. Переход на новую архитектуру редко стоит начинать с полномасштабной миграции. Пилот помогает проверить рабочие нагрузки, оценить стоимость владения, выявить ограничения и понять, какие компоненты действительно нужны.
Пример реализации: Cloud X Data Lakehouse
В Cloud X мы используем эти критерии как практическую рамку при проектировании решений для промышленных заказчиков. Один из результатов такого подхода — облачное индустриальное решение в архитектуре Data Lakehouse.
В его основе три продукта: Cloud X GreenPlum, Cloud X ClickHouse и Cloud X Data Lake. Архитектура гибридная: часть компонентов может находиться на объекте автоматизации, а хранение и обработка данных выносятся в облачный контур. Такой вариант позволяет учитывать требования к локальности данных, производительности и управлению инфраструктурой.
Задача решения — собрать управляемый контур для хранения, обработки и аналитики больших данных.
Cloud X GreenPlum и Cloud X Data Lake основаны на собственных дистрибутивах, входящих в реестр отечественного ПО.
Вместо заключения
Стратегия работы с большими данными не сводится к выбору между DWH, Data Lake или Lakehouse. В реальности это выбор баланса: где хранить данные, где выполнять вычисления, как управлять качеством, какие наборы данных действительно нужны бизнесу и как не допустить, чтобы архитектура стала неподвижной под собственной тяжестью.
ссылка на оригинал статьи https://habr.com/ru/articles/1057402/