Плюсы и минусы различных DWH как источников данных для BI
Ожидается, что к 2028 году объем рынка облачного хранения данных достигнет 7,69 млрд долларов. При этом, глобальный рынок облачных хранилищ данных в 2026 году должен достигнуть 10,42 млрд долларов — это почти в 3 раза больше, чем аналогичный показатель 2021 года.
Корпоративное хранилище данных долгое время является наиболее популярным источником данных для бизнес-аналитики, и вряд ли в ближайшее время картина радикально изменится. Но наряду с ним выступают и гибридные системы Hybrid Transaction / Analytical Processing, которые совмещают аналитику данных транзакционных (учетных) систем и систем анализа данных. Также очень популярно использование озер данных, напрямую связанных со слоем BI, активно развиваются технологии облачного хранилища данных.
В этой статье мы кратко рассмотрим несколько вариантов организации аналитических хранилищ. Итак, поехали!
Единый источник истины
Доверие к данным - основное и главное требование, предъявляемое к аналитическим системам. Аналитика не даст ожидаемых результатов, если в цифрах, которые она показывает, есть сомнения. Кроме того, нужно учитывать, что объем данных в аналитическом хранилище будет со временем расти, и, в отличие от учетных (транзакционных систем), КХД не рассчитаны на то, что из них будет что-то удаляться.
Часто заказчики хотят себе единое корпоративное хранилище, чтобы руководители могли получать только “правду и ничего, кроме правды”. Быть единым источником истины - частая задача корпоративных хранилищ. Знания и информация обо всех бизнес-процессах и объектах бизнеса должна собираться и храниться в одном месте. Все предприятия должны быть описаны в одном месте и один раз. Централизованное хранилище объединяет в себе информацию всех частей предприятия.
Корпоративное реляционное хранилище данных
Централизованное реляционное хранилище - это хранилище, которое объединяет знания и информацию обо всех бизнес-процессах и объектах бизнеса в виде табличных структур, связанных между собой. Данные в хранилище должны поступать в предварительно подготовленном структурированном виде, пригодном для их размещения внутри таблиц. Нормализацию данных в хранилище полностью определяет подход к организации аналитического хранилища. С одной стороны, нормализованная структура, применяемая в транзакционных хранилищах, не обеспечивает должной производительности. С другой стороны, денормализация, которая обеспечивает более дешевый и быстрый анализ, ведет к избыточности данных и увеличении времени их обновления. Существует множество типовых и гибридных методологий по организации хранения данных в аналитических системах. В реляционном хранилище можно выделить следующие плюсы и минусы:
Плюсы:
Высокая степень качества входящих данных. Данные, которые будут попадать в хранилище, уже имеют табличную структуру, что значительно упрощает дальнейшие манипуляции с ними. А за их подготовку отвечают поставщики данных - владельцы систем-источников.
Ядро хранилища может выступать единым “источником истины” для анализа. На основе определенных объемов данных можно построить витрины, которые будут надежным источником информации.
Возможность анализировать данные за большой период. Такая возможность достигается за счет хранения исторических данных в единой структуре.
Высокая масштабируемость и поддержка больших объемов данных (хранение, обработка и быстрая доставка).
Контролируемый доступ к единому хранилищу.
Минусы:
- Неизбежный, постепенный рост затрат на администрирование и поддержку структуры хранилища.
- Увеличение объема данных ведет к росту сомнений в их достоверности. С ростом объемов данных и числа их потребителей увеличиваются противоречия об “истинности” этих данных, так как договорится о терминах и методологии становится все сложнее.
- Дороговизна внесения изменений. Риск сломать существующие ETL-процессы: переиспользование витрин в качестве источников для последующего анализа приводит к чрезвычайной сложности структуры хранения.
Облачное хранилище данных (Cloud Data Warehouse)
В этом случае хранилища разворачиваются в облачной инфраструктуре, обеспечивая гибкое масштабирование за счет увеличения количества или качества серверов и высокую доступность без необходимости создания и управления физической инфраструктурой.
Плюсы:
Не требует затрат на аппаратное обеспечение и инфраструктуру.
Высокая доступность и надежность данных, удаленное администрирование и обслуживание. В том числе облачная инфраструктура позволяет быстро расширять парк компонентов аналитического хранилища. Например, организовать гибридные структуры (озеро данных/ DW-хранилище) в облаке сильно проще.
Быстрое внедрение и интеграция с облачными инструментами для обработки данных, управления доступом, DevOps и другими сервисами.
Минусы:
- Зависимость от провайдера облачных услуг.
- Возможные проблемы с безопасностью данных в связи с передачей информации через интернет.
Операционное хранилище данных (Operational Data Store, ODS)
Такое хранилище по сути представляет собой слой DW-хранилища, который в свою очередь можно использовать как независимый источник. Главной чертой ODS-хранилища является его высокая скорость обновления анализируемых данных, что в части случаев позволяет решать операционные аналитические задачи на высокоактуальных данных без нагрузки транзакционных систем.
Плюсы:
Данные в ODS-слое актуальны, что позволяет производить анализ, не нагружая при том транзакционную систему “дорогими”, с точки зрения реляционных баз, аналитическими запросами.
Является источником данных для операционных витрин - аналитических систем, которые требуют высокой степени актуальности данных, например, ситуационных центров, куда собирается текущая информация из множества систем компании.
Минусы:
Не предназначена для долгосрочного хранения данных и сложной аналитики, т.к. ODS часто перезаписывает или обновляет старые данные новыми.
Отсутствуют возможности анализа исторических данных.
Озера данных
При работе с большими данными сложно привести все их типы в пригодный для хранилища вид. Такая работа потребует сложных ETL-процессов, которые при работе с большим объемом данных будут выполняться слишком долго. Поэтому концепция озера данных придерживается подхода ELT. Данные записываются в “озеро” в том виде, в котором они поступают из первичных источников с минимальными затратами на их подготовку. Это значительно упрощает вопрос хранения произвольных данных. Предполагается, что при работе с ними дата-инженеры будут так разбирать структурировать данные, чтобы ответить на конкретные вопросы бизнеса. В общем случае озеро данных позволяет дата-аналитикам обрабатывать неструктурированные данные и загружать результаты в BI-слой.
Плюсы:
- Дешевое хранение большого объема данных
- Данные не очищаются предварительно, соответственно, они меньше подвержены трансформации, что предоставляет практически неограниченные возможности в их анализе по произвольным критериям.
Недостатки:
Из-за отсутствия структурированности можно по-разному интерпретировать информацию из данных, что в итоге приводит к расхождениям одних и тех же понятий и значений одних и тех же бизнес-показателей.
Бессистемный сбор “всего, что есть” может привести к усугублению фактора энтропии в озере данных. В итоге компания не понимает, какие данные анализируются, и “озеро” превращается в “болото” данных, что ведет к еще большему снижению доверия к информации.
На что нужно обращать внимание при выборе модели корпоративного хранилища
Выбор DWH может повлиять на эффективность бизнес-аналитики и управления данными. Здесь нужно учесть множество факторов, так как каждое хранилище имеет собственные характеристики и возможности, решающие конкретные виды задач. Например:
Объём и рост данных
Масштабируемость — ключевой аспект для выбора хранилища. Если данные компании быстро растут, то DWH должно справляться с увеличением объёмов без значительного снижения производительности. Например, облачные хранилища могут легко масштабироваться, тогда как локальным DW для этого могут потребоваться значительные инвестиции в оборудование.
Производительность и скорость обработки данных
Для BI критически важны быстрые результаты. Выбор DWH должен учитывать, какие данные и насколько быстро система должна представлять, кто является получателем данных, насколько данные должны быть актуальны и как часто обновляться.
Скорость внедрения
Быстрое развертывание DWH очень важно для организаций, которые нуждаются в оперативном анализе данных — розничным сетям, банкам, стриминговым сервисам и т.д. Например, облачные DWH обычно внедряются быстрее, чем традиционные локальные хранилища, для которых требуется развертывание физической инфраструктуры. Но вопрос скорости неразрывно связан и со структурой организации сбора. Например, выбрав реляционное DW-хранилище, организация нормализованного ядра займет значительно больше времени, чем организация тематических витрин. Но в перспективе ситуация с сопровождением хранилища при его росте может в корне измениться.
Стоимость
Компании должны оценивать не только текущие затраты, но и прогнозировать долгосрочные расходы. Например, внедрение и поддержка локального DW может потребовать значительных инвестиций в инфраструктуру компании и IT-персонал. С другой стороны, облачные решения оплачиваются по мере использования — это может снизить начальные затраты, но при активном росте данных компании, цена за облачный DWH может резко измениться.
Гибкость и адаптивность
Бизнес-стратегии и цели могут меняться — это требует от DWH гибкости в поддержке новых запросов, источников данных и моделей аналитики. Все это помогает сократить время адаптации и снизить затраты на изменения.
Поддержка ETL/ELT-процессов
ETL/ELT-процессы — важная часть управления данными, которая позволяет быстро и корректно загружать и трансформировать информацию. Поэтому DWH должны либо поддерживать интеграцию с ETL-инструментами, либо обладать встроенными механизмами для их реализации.
Заключение
Хранилища данных играют ключевую роль в бизнес-аналитике. Они помогают масштабировать бизнес, проводить исторический и многоуровневый анализ данных, а также контролировать безопасность информации.
При этом выбор подходящего DWH зависит от целей и возможностей бизнеса. Корпоративное хранилище следует рассматривать как самостоятельный продукт в ИТ-инфраструктуре компании. Соответственно, при определении объема вложений необходимо понимать выгоды, получаемые от продукта и риски, которые могут произойти.
Что касается технологий и компонентной архитектуры, здесь также необходимо формировать потребность от бизнеса. Вряд ли нужно проектировать сложное многоуровневое КХД, если бизнес органичен во времени и средствах. В таком случае можно обойтись тематическими витринами данных в облачном хранилище.
В то же время этот подход не подойдет крупной филиальной структуре, которая будет использовать хранилище на протяжении многих лет без его кардинальной перестройки. Подобной компании уже на старте работ необходимо рассматривать гибридные схемы хранилища, которые предполагают использование озер данных и реляционных хранилищ. Также такой подход требует обеспечивать достаточное документирование ETL-процессов и формирование единого словаря терминов и определений, который будет сопровождать хранилище.