+7 499 350 77 10
+7 499 322 88 70
Дарья Колесова

Как выбрать СУБД для работы с большими данными?

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

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

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

В этой статье мы будем опираться только на Open Source инструменты, актуальные и востребованные сейчас на рынке (особенно в условиях импортозамещения).

Итак, давайте рассмотрим несколько типовых задач, с которыми может столкнуться аналитик данных.
Практические задачи
Задача 1
Годовой отчёт
Суть задачи: собрать годовой отчёт, который должен обновляться каждый день и содержать сложные показатели, на основе которых руководители могут принимать решения о работе компании и её процессах (метрики retention, LTV и др). Отчёт нужно также вывести на BI-дашборд.

Такие дашборды подключаются к обновляемым источникам данных и представляют собой набор графиков, диаграмм и таблиц со сводными результатами какой-либо деятельности. Как пример, дашборды используется для отслеживания доходов и расходов, мониторинга процессов, демонстрации ключевых показателей бизнеса. Наиболее известные инструменты для создания дашбордов это Power BI от Microsoft, Tableau, Qlik.
Анализируя постановку задачи, можно выделить такие критерии выбора СУБД:

  • Нужно обрабатывать ОЧЕНЬ много данных (не тысячи и миллионы, а миллиарды записей)
  • Сложная логика расчётов метрик
  • Необходимо частое обновление — минимум раз в день
  • Нужно обеспечить минимальное время сбора отчёта (минуты, а не часы)
Для решения таких задач я хочу порекомендовать open-source СУБД Greenplum.

Во-первых, GreenPlum — мощная СУБД, а для работы с хранящимися в ней данными используется SQL. Для задач нашего кейса (сложная логика расчётов) удобно использовать SQL, ведь этот язык специально предназначен для работы со сложными запросами из БД.

Во-вторых, GreenPlum — MPP (Massively Parallel Processing) СУБД. Это значит, что данные в БД физически хранятся на разных серверах. Это позволяет оптимально распределить нагрузку при выполнении запроса и значительно сократить время сборки отчёта.
Задача 2
Мониторинг и онлайн-аналитика

Суть задачи: реализовать для маркетинга инструмент онлайн-мониторинга, который позволил бы с задержкой не более 10 секунд отслеживать количество пользователей, приходящих с различных каналов (социальные сети, рассылка, промо-акции и так далее).

Из условий задачи выделяем такие критерии:

  • Большое количество данных
  • Умеренная сложность логики, нет сложных метрик и расчётов
  • Требуется обеспечить минимальное время сбора и частое обновление (анализ данных в реальном времени)

Для такой задачи отлично подойдёт, например, инструмент ClickHouse. Важная особенность заключается в том, что ClickHouse — это колоночная СУБД.
К тому же при решении задач онлайн-аналитики больших данных ClickHouse позволяет осуществлять выборку данных массивами. Это называется vectorized query execution или векторизованное выполнение запросов. Любые операции выполняются не на индивидуальных значениях, а на массивах данных. Такой подход значительно ускоряет время выполнения запросов.

Но нужно помнить, что из-за подобного подхода растёт скорость, но падает точность. Возможны погрешности в вычислениях, поэтому ClickHouse не подходит для решения задач, в которых важна доскональная точность (например, в банковских транзакциях). При решении ряда задач анализа больших данных, в которых не требуется высокая точность, попадание в выборку одного-двух лишних значений не повлияет на результаты, и ClickHouse смело можно использовать для анализа данных.
Задача 3
Связь данных нескольких сервисов
Давайте представим, что в нашей компании микросервисная архитектура. Каждый сервис функционирует изолированно и имеет собственную базу данных, в которой хранит только необходимые ему данные.

Бывают ситуации, когда требуется связать данные из разных сервисов: например, если мы хотим выдавать некоторым пользователям промокод на скидку. При этом условие отбора таких пользователей включает несколько критериев. Например, пользователь должен сделать не менее двух заказов и быть зарегистрирован не ранее, чем две недели назад. Предположим, что данные о количестве заказов и дате регистрации хранятся в БД разных сервисов и нам необходимо собрать данные из двух сервисов, обработать и отдать потребителю данных.
Почему бы нам не использовать инструменты, рассмотренные ранее? Например, GreenPlum или ClickHouse?

Когда речь идёт о взаимодействии приложения с пользователем, задержка даже в 10 секунд становится критичной. Каждый пользователь хочет взаимодействовать с тем продуктом, который предоставляет мгновенный отклик. И здесь в дело вступает такое понятие как real-time.

Выделяем из условия задачи следующие критерии выбора нашего будущего инструмента:

  • Много данных о пользователях
  • Связь нескольких источников данных
  • Real-time доставка данных (быстродействие как на запись, так и на чтение)

Для решения такого рода задач хочу предложить инструмент Cassandra. Это NoSQL СУБД. Почему для нас это важно? Требовательность SQL к структуре и соответствию типам значительно замедляет время записи данных по сравнению с noSQL. В нашей же задаче важно не только быстро получать данные, но и быстро их записывать.

Cassandra — колоночная СУБД. Как и в случае с ClickHouse, это здорово ускоряет чтение данных.
Задача 4
Система рекомендаций

Суть задачи: одна из популярнейших задач в Big Data — реализация рекомендательной системы, позволяющей подбирать релевантные для конкретного пользователя товары, услуги, фильмы, новости и так далее.

Основные критерии для этой задачи:

  • Высокое качество рекомендаций
  • Сложная логика расчётов
  • Частое обновление (минимум раз в день)
  • Быстродействие формирования подборки (не обязательно мгновенно, но в течение нескольких минут)

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


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

Воркшоп Дарьи Колесовой из Яндекса


«NO SQL. Современные технологии хранения и

анализа данных в микросервисной архитектуре»

8 часов в выходные 9-10 марта 2024

Воркшоп будет полезен системным аналитикам, проектировщикам и разработчикам, которые хотят познакомиться с микросервисной архитектурой, разными СУБД и языками запросов к ним: PostgreSQL, Redis, Neo4j и MongoDB
Забронировать место
Ваш промокод: GO2NOSQL даст скидку 20%
Как оценить надёжность инструмента
Сейчас поговорим о том, на какие «маячки» смотреть при выборе инструмента и как оценить его надежность (особенно Open Source-технологий).

Вернёмся к задаче № 2 (мониторинг и онлайн аналитика) и представим, что на просторах сети мы нашли инструмент Apache Kudu. Разработчик заявляет, что Kudu позволят «проводить быструю аналитику на быстро изменяющихся данных». Звучит как-то, что нам и нужно. Но давайте посмотрим на инструмент чуть глубже.

Большинство Open Source проектов хранят свой код на GitHub. Поэтому GitHub — первое место, куда я иду, когда хочу убедиться, что «пациент жив».

Вот как выглядит страница проекта Apache Kudu:

Страница проекта Apache Kudu
Итак, на что я обращаю внимание.

1. Дата последнего коммита. Если последний коммит был сделан давно, обратите на это внимание, возможно инструмент никто не поддерживает. Если видим, что последний коммит был сделан, например, всего 2 часа назад, то это хороший знак!

2. Даты обновления в конкретных папках проекта. В крупных проектах куски кода разбиты по разным папкам. Так мы можем оценить, а что именно в проекте обновляет разработчик. Если большая часть папок была обновлена давно, на это также стоит обратить внимание. Видим, что некоторые папки были обновлены недавно, 2 и 6 часов назад. Но при этом, остальные были обновлены несколько месяцев назад. Здесь закрадывается подозрение, что проект развивается не очень активно. Все же дадим шанс этому инструменту и проверим ещё несколько моментов.
3. Наличие у проекта лицензии. У Kudu есть лицензия Apache 2.0, значит разработчик предполагает, что этот код будет использоваться в других проектах и обеспокоился тем, чтобы проект находился в правовом поле.

4. Дата последнего релиза и их количество. У Apache Kudu последний релиз был 19 апреля (скриншот страницы был сделан 14 июля), то есть достаточно давно для Open Source проекта.

Теперь нам нужно посмотреть, а что, собственно, было включено в релизы проекта? Поэтому следующее, что я делаю — это захожу на сайт Apache Kudu на страницу с релизами.

Cтраница с релизами на сайте Apache Kudu

Видим, что тот самый последний релиз 1.16.00 связан с документацией, а предыдущие релизы были год назад. И конечно, это говорит о том, что инструмент не поддерживается и не развивается разработчиком.

Такие инструменты я не рекомендую использовать и вот почему:

  • Поддержка долго обрабатывает запрос или не обрабатывает вообще
  • Баги не устраняются
  • По сравнению с аналогами функциональность скорее всего будет хуже, так как рынок не стоит на месте, а этот инструмент совсем не развивается
  • Мало совместимых инструментов
Заключение
На рынке большое количество различных инструментов для решения задач, связанных с большими объёмами данных, а также их хранением, выборкой, обработкой. На первый взгляд в этом многообразии легко потеряться. Чтобы выбрать подходящий инструмент, нужно рассмотреть детально стоящую перед вами задачу и выделить основные критерии, под которые должен подходить инструмент. Также, как вы можете видеть из статьи, нужно не забыть удостовериться, что он хорошо поддерживается и активно развивается.
Автор
Дарья Колесова
Big Data RnD разработчик, BI-engineer, data-аналитик, технический лид
  • Более 5 лет опыта в Big Data разработке
  • Более 3 лет опыта в роли тренера

Почта для связи: dusikjuk@yandex.ru