Big Data против классического хранилища данных: кто победит?

Мнения
153360
0
Сергей Цевин, директор центра развития бизнес-приложений департамента аналитических систем, R-Style Softlab
Александр Кондиайн, главный архитектор по хранилищам данных департамента аналитических систем, R-Style Softlab
Александр Медведев, начальник отдела перспективных разработок департамента аналитических систем, R-Style Softlab
Про большие данные написано немало различных статей, в которых восхваляется эта технология, приводятся сравнительные анализы различных продуктов или описываются успешно реализованные проекты на базе Big Data. Авторы нашей статьи размышляют о том, не станет ли Big Data «убийцей» классических хранилищ данных.


В рамках внедрения ИТ-продуктов мы нередко предлагаем своим клиентам сначала построить хранилище данных, и лишь затем внедрять на его основе специализированную функциональность, например управленческую или регуляторную отчетность. При построении хранилища мы используем классическую модель, включающую область детальных данных с третьей нормальной формой, и не менее классическую область витрин данных. При этом мы все чаще слышим от клиентов такие высказывания: «Как это у вас нет Big Data? Ну как же… Это же не круто. Нам нужна Big Data»

Получается, что в сознании обывателя обосновалось мнение, что классическое хранилище данных — это вчерашний день, а вот Big Data, напротив, очень передовая технология. Но так ли это на самом деле? На наш взгляд, нет. Давайте разбираться.  


Когда не обойтись без Big Data? 


Действительно, на сегодняшний день Big Data является достаточно модным явлением. Не все до конца понимают, что же это такое и какие задачи эта технология призвана решить, но хотят ее все поголовно, потому как мода обязывает — «у соседа есть, так чем я хуже».  

Первое, чем следует руководствоваться при выборе между классическим хранилищем и решением Big Data, — это размер бизнеса и генерируемый им объём данных. Например, если в банке всего несколько сотен тысяч клиентов и миллион счетов, то пользы от Big Data он, скорее всего, не получит.
 
Хранилище данных позволяет достаточно эффективно решать большой круг задач, например, связанных с построением отчетности, базирующейся на данных из различных разнородных систем. Все СУБД имеют набор инструментов и механизмов, позволяющих решать задачи на базе хранилища данных максимально быстро и эффективно. В зависимости от вида задачи это может быть использование индексов там, где это оправдано, или, наоборот, отказ от них, использование партиционирования и многопоточности и пр.

Круг задач, решаемых хранилищами, постоянно расширяется, пока не настает момент, когда имеющихся в СУБД механизмов перестает хватать для обеспечения приемлемой производительности. Дальнейшая борьба за эффективность работы обычно сводится к расширению мощностей сервера СУБД и повышению производительности дисковой подсистемы (системы хранения данных). При этом аппаратное масштабирование — достаточно дорогой способ повышения производительности, хотя зачастую — единственный.

В сложившихся условиях может показаться, что системы Big Data, построенные на базе Hadoop, — это и есть тот самый выход! Они дадут долгожданную производительность, относительно недорогое аппаратное масштабирование и дешевое хранение данных. Но так ли это? На наш взгляд, однозначный ответ на этот вопрос дать нельзя.  

 
Ищем преимущества в традиционных хранилищах 


С одной стороны, концепция и методология «больших данных», действительно, содержит ряд интересных подходов, включая полный отказ от такой операции, как UPDATE. Но, с другой стороны, что мешает в классическом хранилище данных использовать точно такой же подход — не выполнять никаких обновлений. Ответ очевиден — ничто не мешает. Кроме того, отказ от UPDATE (а заодно от DELETE и от MERGE) преимущественно вызван техническими ограничениями HDFS — распределённой файловой системы, используемой для хранения информации в решениях на базе Hadoop. Формально на современных версиях Hadoop выполнить эти операторы мы можем, правда, не для всех форматов хранения данных, но при этом получим сильную регрессию производительности. Причем, чем больше обновляемая таблица/партиция, тем больше будет деградация. 

Весомым плюсом решений Big Data является очень хорошая горизонтальная масштабируемость Hadoop. Но и классические хранилища данных, например решения на базе Oracle Exadata, также обеспечивают горизонтальную масштабируемость. Конечно, предел возможностей по масштабируемости у решений на Oracle наступит гораздо раньше, чем у решений на базе Hadoop, но на практике очень часто и этого бывает достаточно.
 
Мы решили порассуждать, так ли уж «плохи» классические хранилища данных (за исключением того, что возможности по масштабированию у них слабее), и открыли немало интересных фактов, которыми хотим поделиться. Любая компьютерная система в процессе своего жизненного цикла имеет тенденцию к захламлению. Простой пример: установленная у рядового пользователя ОС Windows спустя несколько лет превратится во множество программ, которые не используются; десятки непонятных процессов в автозагрузке, замедляющих и без того не очень быстрый процесс запуска операционной системы и отъедающих оперативную память; сильно фрагментированный диск; неиспользуемые расширения браузера и много другого «мусора». Аналогичная ситуация складывается и с хранилищами данных: через несколько лет накапливается существенный объем неоптимальных запросов, «наросты» структур, таблицы логов и «запасных» данных, которые замедляют использование первоначально хорошо работавшего проекта. 
Зачастую обслуживание хранилища ограничивается простейшим контролем за наличием доступного дискового пространства. Естественно, такой комплекс мер постепенно приводит к деградации производительности, так как любое хранилище растет, и порой с весьма значительной скоростью. Рост объемов хранилища требует расширения системы хранения данных, а это недешевое удовольствие. Поэтому, когда на слуху появляется Big Data, которая может быть масштабирована простыми серверами с обычными дисками, возникает то самое ощущение: дескать, классическое хранилище — старое, медленное и немодное, а вот если построить его на Big Data, то вот такое хранилище точно «полетит» — будьте уверены!
  
Вполне возможно, что и «полетит» на первых порах, но вопрос в том, как долго оно будет именно «летать», прежде чем начнет требовать аппаратного расширения.
Также надо понимать, что при построении решений класса Big Data всё равно понадобится большое количество аппаратного и программного обеспечения. Скорее всего, потребуются новые высококвалифицированные сотрудники, чтобы обслуживать этот программно-аппаратный комплекс. Так что не известно, что буде дешевле — апгрейд аппаратной составляющей классического хранилища или построение платформы Big Data.  

В то же время, если правильно реорганизовать данные в «старом» хранилище (в случае, когда характеристики данных с момента внедрения претерпели существенные изменения) и освободить быстрые диски за счет переноса на другие носители более ранних данных, обращение к которым происходит редко или от случая к случаю, то содержание текущего хранилища будет вполне бюджетным. А если провести ряд работ по оптимизации используемых запросов (например, в связи с тем, что количество пользователей увеличилось), то необходимость в замене хранилища отпадет сама собой. В конце концов, можно и мощность используемого железа увеличить.  

Следуя этой логике, получается, что Big Data вовсе не нужна? Ответ опять-же отрицательный. Все зависит от задач, которые призвано решать хранилище данных. Для каждой задачи нужно использовать свой, наиболее подходящий инструмент. Если речь идет о загрузке и обработке большого объема различной неструктурированной информации (данные об активности посетителей сайта, анализ геолокации клиентов и другие задачи, которые сложно описать единой моделью данных), то та же Big Data — самый подходящий для этих задач инструмент. Также удобно использовать Big Data для систем машинного обучения (Machine Learning) и прогнозирования. Но в итоге вся эта переработанная информация чаще всего попадает в некое классическое хранилище, которое более приспособлено для визуализации данных бизнес-заказчику.

 
Гибридные решения  


Сегодня большую популярность набирают гибридные решения. Строится Data Lake на базе Hadoop, где собираются данные со всех источников. Фактически Data Lake выполняет роль stage-области классического хранилища. В нём происходит обработка данных, вычленение значимой информации из неструктурированных источников. Затем данные загружаются в детальный слой классического хранилища на базе традиционных СУБД, а витрины формируются в специальной аналитической СУБД, например HP Vertica. Такой подход позволяет хранить разные слои данных отдельно и разделить нагрузку ETL и отчётов по разным физическим средам. 

 
Вывод  

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

 
Помните, с появлением телевидения возникло мнение, что театр обречен? Время показало, что это не так. Более того, теперь, в эпоху YouTube и стримминговых сервисов, еще не ясно, выживет ли телевидение…


Все статьи

Комментарии



Подписка на рассылку
Сортировать
Теги:
Все теги
Выберите интересующий Вас продукт компании
Любой продукт
Сортировать по году:
2017 2018 2019