Первую пару разделить достаточно просто: архитектор проектирует то, чем потом пользуется инженер. То есть архитектор создает систему правил, политик, стандартов и моделей сбора, использования и хранения информации. А следом за ним вступает в работу инженер, внедряя и обслуживая конвейер данных согласно плану.
Со второй парой чуть сложнее, так как их сферы ответственности пересекаются, а еще Data Scientist часто тоже называют аналитиком, как и Data analyst. Тем не менее они отличаются.
Аналитик (Data analyst) чаще всего не строит прогнозы: он ищет закономерности и тенденции в данных, делает выводы и передает полученные результаты другим сотрудникам. Для этого он визуализирует информацию, то есть использует графики и диаграммы.
Выводы аналитика помогают находить закономерности, на основе которых другие отделы – продажи, финансы, маркетинг и так далее – принимают правильные решения.
Специалист по данным (Data Scientist), в свою очередь, подробнее изучает и расписывает результаты аналитиков. Он не просто ищет взаимосвязи, а пытается понять причины тех или иных явлений, определить факторы, влияющие на изменение данных. Кроме того, он может моделировать задачи и затем создавать прогнозы. Его суперсила – умение вычленять из информации сокрытое, находить неизвестные ранее закономерности.
Организации часто нанимают сначала аналитика, а после уже – специалиста по данным, чтобы он сконцентрировался на самых трудоемких задачах.
Теперь у нас в аналитическом отделе четыре специальности, четыре сферы ответственности: их легко запомнить, если провести аналогию с процессом строительства.
Архитекторы данных – это те же самые архитекторы, что проектируют здание и все его системы.
Инженеры данных – строители. Они претворяют в жизнь план архитектора.
Аналитики – это арендаторы помещений: используют построенное, чтобы удовлетворять потребности других отделов.
А специалисты по данным – это те люди, которые понимают, как все работает на детальном уровне. Это дает им возможность контролировать работу объекта: они делают замеры, снимают показания счетчиков и следят за порядком.
Разумеется, это не финальная версия аналитического отдела. По мере того как усложняются задачи и разрастаются отдельные этапы жизненного цикла информации, создаются новые рабочие места и появляются новые специальности: собственные разработчики, администраторы баз данных, проджект-менеджеры и другие. Мы вернемся к ним в пятой части книги, когда вы уже хорошо разберетесь с основными инструментами и задачами, которые в целом должен решать аналитический отдел. И тогда уже поговорим подробнее о необходимых компетенциях каждого специалиста, а также более предметно разберем их должностные обязанности.
А сейчас переходим к следующей большой теме: как организовать хранение данных.
Часть 2Как хранить и организовывать данные
Глава 6Методы организации данных
Впрошлой части мы обсудили структуру аналитического отдела в идеальном мире, но также я акцентировал внимание на том, что архитектор данных в компании появляется не сразу. Тем не менее работу с ними необходимо начать именно с архитектуры, то есть со способов хранения и организации данных. Почему так? Даже если в вашей компании еще нет никакого аналитического отдела, в любом случае данные уже неизбежно накапливаются. И нужно начинать наводить в них порядок. Этим мы и займемся.
Вам может показаться, будто руководителю незачем вникать в эти тонкости. Нанял себе аналитика и живи спокойно. Но, согласитесь, понимая, что и как устроено внутри компании, любой управленец получает неоспоримое преимущество. А потому важно и нужно последовательно изучить каждую главу, чтобы сложилось правильное представление о новом направлении работы любого успешного бизнеса. Вашего бизнеса.
Итак, можно выделить три главных метода организации любых данных: базы, хранилища и озера данных.
База данных (БД, или DB – database) – это большой объем информации, структурированной по определенным правилам и хранящейся в едином виде в одном месте. Благодаря этому с информацией можно работать: собирать, сравнивать, выводить на графики, делать запросы. Это похоже на склад, где не просто полки с разными предметами, а целая система хранения. Вы знаете, в каком блоке стоят холодильники, а в каком – микроволновки. Все структурировано и понятно. И когда вам необходимо найти стиральную машину, то вы сразу идете в отсек, где они хранятся, а не бессистемно ищете по всему ангару. Так же устроены и базы данных. Чтобы получить информацию по сотруднику или нужному товару, нет необходимости перелопачивать кучу документов. Все хранится, учтено и упорядочено в соответствующих базах данных.
Хранилище данных (Data Warehouse) – это более сложная система: в ней собирается и хранится структурированная информация из различных источников, в первую очередь из баз данных внутри компании. Эти записи используются для аналитики и принятия управленческих решений, а также решения других задач бизнеса. И если базы данных мы сравнивали со складом, то здесь можно говорить о логистическом парке, когда множество складов базируются на одной территории.
Озеро данных (Data Lake) – это хранилище, в котором одновременно может находиться огромный объем самой разной информации: полностью структурированной, частично структурированной или даже совсем не структурированной. Здесь нет никаких ограничений по размеру или объему единицы информации, данные хранятся в естественном формате. Озера можно представить в виде дедушкиного гаража. В нем стоят полки с коробками гвоздей, гаек и других рассортированных инструментов, но также найдется место для шин, запасов бензина, моторной лодки и старого мотоцикла. Озера нужны для того, чтобы аккумулировать разрозненные данные, а потом использовать их для анализа.
Нельзя сказать, что какой-то из этих методов «правильный», «идеальный», «лучший» или «худший». Каждый из них выполняет свои конкретные функции, и мы можем выбрать любой, наиболее подходящий для наших бизнес-задач.
Да, мы всегда начинаем с определения задачи. Ни у одной организации нет цели «построить хранилище или озеро». Нет, к специалистам обращаются и начинают работать с данными, чтобы увеличить прибыль или расширить компанию.
Любая задача в аналитике должна работать в первую очередь на цели бизнеса.
Поэтому при разработке архитектуры четко проясняем задачи:
1. Какие данные будут храниться? С какой целью?
2. Как часто к ним будут обращаться?
3. Какой объем информации предстоит обрабатывать?
4. Как данные будут использоваться?
Учтите также ваш текущий технологический стек, то есть те инструменты, которые уже используются в вашей компании.
1. Откуда сейчас стекаются данные и как с ними работают сотрудники?
2. В каком виде хранятся данные?
3. Какие программы, системы, инструменты уже используются в работе? Или, может быть, оплачены, но пока не используются?
Если вы уже используете какие-то сервисы, лучше всего искать решение, совместимое с ними. Например, в 2016 году я присоединился к компании, которая занималась мобильной рекламой. Программисты организации настроили сбор информации. Фиксировались все возможные события в системе: какие действия совершали пользователи, в какой момент и какие возникали ошибки и так далее. Эти данные представляли собой сырые массивы данных и никак не обрабатывались. Сотрудники пытались разобраться, насколько успешны рекламные кампании, однако работа шла медленно и неэффективно: записей много, но использовать их тяжело.
Рис. 5. Скриншот из Kibana – ПО, которое компания использовала для визуализации своих данных
Передо мной стояла задача повысить эффективность и скорость работы с данными. Оказалось, что у компании уже была лицензия на систему управления базами данных HP Vertica. Я предложил руководству создать реляционное хранилище (рассмотрим, что это такое, чуть позже) на ее основе.
Директор принял мое предложение и дал зеленый свет. Дальше – больше. Я провел интервью с сотрудниками и спроектировал хранилище данных. В итоге на его основе удалось построить отчетность и серьезно изменить подход к работе с данными. Одно из преобразований было почти революционным: компания одной из первых начала внедрять Сlickhouse (о нем подробнее мы поговорим чуть позже, когда дойдем до колоночных баз данных). Тогда технология была еще сырой, тем не менее изменения помогли начать по-настоящему оценивать эффективность рекламных кампаний. Грамотная работа аналитика под руководством директора, понимающего задачи компании, принесла свои плоды, позволив существенно сократить затраты на хранение и использование собственных данных.
Теперь давайте познакомимся с базами данных, хранилищами и озерами поближе, чтобы вам было легче разобраться, что из них максимально эффективно будет реализовывать задачи вашего бизнеса.
Глава 7Базы данных (БД)
База данных – это совокупность информации, организованной по определенным правилам.
Эти правила помогают быстро находить нужные данные как для аналитики, так и для текущих транзакций, а также добавлять новые записи, редактировать существующие и удалять ненужные.
База данных – фундаментальный инструмент для хранения и управления большим объемом информации; она обеспечивает надежность, эффективность и безопасность в работе с ней.
К примеру, базы данных хороши для учета и анализа информации об успехах бизнеса, для хранения записей о предприятии и сотрудниках.
Базы данных бывают разных видов.
Традиционных моделей данных три: иерархическая, сетевая и реляционная.
Первые две сейчас редко используются в чистом виде, поэтому рассмотрим их кратко, для базового понимания разницы между ними.
В основе иерархических баз данных, как следует из названия, лежит иерархия, то есть одни объекты подчиняются другим. Вам знакома эта модель: при хранении документов на компьютере под управлением Windows в общей папке «Диск С» есть папка «Фото», в ней – папка «2024», в ней – папка «Море», и там уже отдельные файлы, соответствующие теме.
При таком способе организации найти и извлечь нужную информацию довольно легко – сразу понятно, где какие данные находятся, к чему относятся и как до них добраться. Но для большинства задач такая модель быстро становится чересчур громоздкой. Что, если вы захотите собрать в папку «Море» фото за все годы, но при этом также иметь возможность посмотреть снимки из отпуска только за 2024? Один и тот же документ не может лежать сразу в двух местах. Значит, придется дублировать: исходную папку оставить на месте, а в «Фото» добавить новую папку «Море-2024» и скопировать туда отпускные фото с 2024-го года. Несколько таких операций – и вы совершенно запутаетесь, где и что у вас хранится.
Поэтому иерархические базы данных используются очень ограниченно – там, где важно сохранить отношения подчинения. Например, структура предприятия, где видна иерархия сотрудников, кто кому подчиняется и в каком отделе работает. Информация на каждого сотрудника формируется в индивидуальном файле, который лежит в папке отдела, а она, в свою очередь, находится в папке департамента, к которому относится отдел.
Сетевые (или графовые) базы данных чуть удобнее и уходят от ограничений иерархических за счет того, что между таблицами и записями может быть сразу несколько связей. Все они запоминаются и хранятся в специальных индексных файлах, и их можно быстро и просто найти. Пример такой базы данных – каталог фильмов: можно посмотреть всех актеров, снявшихся в ленте, и перейти на страницу каждого, чтобы узнать, в каких фильмах еще он играл. Здесь уже не нужно создавать новую страницу актера под каждый фильм, достаточно в отдельном файле прописать указатели, что с чем связано.
Эта модель хороша своей оперативностью и эффективностью затрат памяти, так как не нужно создавать дубликаты информации, как в случае с папками «Море» и «Море-2024». Недостатки – сложность и жесткость структуры. Вносить изменения в такую базу будет очень непросто. Кроме того, структура сетевых баз данных удобна для понимания машинами, но пользователям сложнее их считывать, поскольку не так явно видны связи между элементами, а потому нужно отдельно задумываться о понятной визуализации.
Рис. 6. Сетевая база данных
На практике из трех традиционных моделей чаще всего используются реляционные базы данных. На них мы остановимся поподробнее, поскольку именно с ними чаще всего придется сталкиваться вам, вашему аналитику или аналитическому отделу.
Реляционные базы данных
В реляционной базе данные структурированы в виде таблиц, содержащих строки и столбцы с заданными взаимосвязями.
Эта модель опирается на реляционную алгебру, замкнутую систему обращений к данным и действий с ними, и использует SQL – структурированный язык запросов, который применяется для получения, создания и изменения информации в базах данных табличного типа.
Рис. 7. Microsoft Exсel устроен по принципу реляционной базы данных
Вообще, стоит отметить, что большая часть работы аналитиков напрямую связана с языком SQL. В последние годы, в связи с широким распространением облачных баз данных, SQL стал снова популярен. Сейчас он повсеместно используется аналитиками и инженерами данных в современных решениях типа dbt (data build tool) – инструмента для трансформации данных на основе SQL-запросов.
Термин «реляционный» происходит от английского relations – «отношения», так называют связи данных в таблицах. Структура отдельных таблиц может отличаться, но внутри каждой должны быть уникальные столбцы и колонки. Скорее всего, вы уже сталкивались с реляционной базой данный, поскольку Microsoft Exсel устроен по ее принципу. Одна из наиболее распространенных систем управления такими базами – MySQL — часто используется для большинства веб-приложений и сайтов. Вторая по популярности – PostgreSQL. К этому типу также относятся Microsoft SQL Server (MS SQL).
Преимущества реляционной модели данных:
• Понятная процедура обработки: вашему аналитику не нужно продумывать маршрут запроса и получения информации. Обращение к базе, операции над данными, конечный результат имеют вид, интуитивно понятный и привычный для нас. Но также в таблице, как правило, четко передается физическая сущность ее элементов.
• Простая организация хранения данных: программы быстрее обрабатывают информацию, упрощая работу аналитиков.
На этой модели основано большинство продуктов для систематизации информации – от «Google Таблиц» до динамических систем анализа: к примеру, поведения пользователей на сайте. По сути, все события в бизнесе можно описать через реляционную модель: все операции (заказы и историю их обработки, закупку и прием товаров) в интернет-магазине, сделки на бирже, рекламу (рекламные кампании, сколько людей пришло с каждого канала, сколько это стоило, сколько человек увидели объявление, сколько кликнули по ссылке), продажи (сколько заявок пришло, сколько обработали, какая конверсия, какие результаты у каждого менеджера) и так далее.
Приведу пример. Я помогал крупной сети супермаркетов создать базу данных для работы отдела маркетинга. Изначально они использовали для хранения данных MS Excel и тратили несколько суток на поиск нужной информации и создание отчетов. Ведь сами по себе таблицы Excel не предназначены для хранения большого объема информации, вы должны заполнять их вручную, при этом невозможно эффективно связать несколько таблиц между собой. А потому первым делом я предложил руководителю создать базу данных с записями о заказах (чеках).
Мы использовали Microsoft SQL Server: транзакционнные данные из системы SAP (система планирования ресурсов корпораций, аналог 1С) загружались в SQL-сервер и затем использовались для анализа. База данных объемом несколько гигабайт находилась на выделенном компьютере. Хотя сегодня такой объем может показаться ничтожно малым для непрерывной записи, но в то время этого было достаточно. В базе содержались таблицы «Заказы» с ключами «Дата», «ID чека», «Товар», «Категория», «Идентификатор магазина» и другие.
Допустим, маркетологам нужно было проанализировать, насколько успешно работают их рекламные кампании и как на результаты влияет карта постоянного покупателя. Если один и тот же клиент часто совершал покупки и использовал клиентскую карту, в базу записывался его идентификатор. Таким образом, мы могли быстро, буквально с помощью одного запроса увидеть процент покупок с картой и без нее. Кроме того, единая база данных позволила нам легко провести кластеризацию покупателей, то есть разделить их на группы, и перейти к более глубокой аналитике.
Другой пример из розничной торговли. Администрация гипермаркета хочет изучить поведение покупателей: какие товары остаются на полках дольше, какие товары покупаются быстрее. Для этой задачи требуются следующие данные:
• Информация о покупках. Название товара, категория, цена.
• Идентификатор покупки. Можно ограничиться номером чека, а можно присвоить уникальные идентификаторы постоянным клиентам, например через номер бонусной карты, как в примере выше.
• Время покупки. Это поле важно как для маркетинга (чтобы определить, когда товары должны быть размещены на полках), так и для администратора магазина. Когда пик спроса на товары наибольший, нужно обеспечить работу максимального количества касс.
Добавляем эти поля в таблицы, настраиваем экспорт данных из системы – готово, можно строить аналитическую отчетность. И так можно разложить практически любую задачу: понять, что вы хотите найти и какие данные вам для этого понадобятся, а затем добавить в базу соответствующие поля, чтобы начать собирать статистику.
Если вы хотите, чтобы реляционная база работала корректно, она должна быть целостной, а данные в ней – нормализованными и структурированными. И последнее условие – информация должна обрабатываться с помощью вычислительных систем.
Целостность следует понимать двояко. С одной стороны, информация должна быть полной и достаточной, поскольку с ее помощью необходимо выстраивать взаимосвязи между элементами базы. С другой стороны, под целостностью подразумевается соответствие информации конкретным условиям и формату ввода.
Как говорилось выше, базы данных предназначены для машинной обработки. То есть информация обрабатывается или человеком с помощью компьютера, или программой без участия человека.
А значит, информацию нужно подготовить, чтобы программа с ней справилась: привести в форму, удобную для ввода, понятную для анализа и пригодную для поиска. Это и называется нормализацией.
Начинающие аналитики, а порой даже профессионалы, тратят едва ли не половину рабочего времени на приведение данных к стандартному виду. Рассмотрим на примере.
Представьте гипермаркет. В нем продается 40 тысяч товаров. И ежедневно клиенты совершают миллион покупок.
Какая проблема может возникнуть с информацией? Например, сегодня один менеджер ввел адресные данные клиента для доставки. А завтра второй продублировал тот же адрес, но изменил в нем один символ. Допустим, зафиксировал название улицы с маленькой буквы. Теперь в базе хранятся разные названия одного и того же адреса доставки.
Если вы захотите построить отчет по продажам с разбивкой по адресам доставки, то неизбежно столкнетесь с головной болью: как всю эту информацию свести воедино? Аналитику придется тратить кучу времени на очистку и нормализацию данных, убирать лишние пробелы, запятые, править регистр некоторых букв, удалять лишние слова, пытаясь привести все к единому виду. И только после этого приступать к анализу. То есть заниматься не столько самой отчетностью, сколько подготовкой записей к ней.
Конечно, так быть не должно. Ведь это отнимает лишнее время. Именно поэтому должны быть четкие и единые правила заполнения баз данных.
Та же проблема может возникать со стороны пользователей. Например, у нас была задача по нормализации клиентской базы в компании «Юлмарт». Они не сразу настроили ограничения для полей на странице регистрации, и 10 миллионов клиентов ввели свой адрес как попало. Кто-то указал страну. Некоторые – только город. Другие – улицу. А были и те, кто вообще ничего не написал. Только на очистку данных мы потратили не один месяц.
Из этих примеров можно сделать два вывода. Во-первых, если вам кажется, что аналитик работает неэффективно, возможно, это не его вина: проверьте, не тратит ли он большую часть рабочего времени на черновую работу. А во-вторых, о нормализации данных стоит задуматься как можно раньше, чтобы потом не тратить время и деньги на лишнюю работу. На этапе формирования системы хранения данных разработайте глоссарий и регламенты ввода информации для сотрудников, и это поможет вам избежать проблем в дальнейшем.
Базы данных NoSQL
NoSQL базы данных были придуманы больше двадцати лет назад, но активно и охотно пользоваться ими стали не так давно. NoSQL расшифровывается как Not only SQL, то есть «не только SQL». Это понятие включает в себя разные продукты, которые могут поддерживать или не поддерживать SQL-запросы. Главное, что их объединяет, – попытка уйти от ограничений реляционных баз данных, в первую очередь от их статической, плохо масштабируемой структуры.
Дело в том, что структура реляционной базы данных – одновременно ее сила и слабость. Заранее определенные поля и связи позволяют сохранять информацию целостной и согласованной. Вы не можете ввести что попало куда попало, а значит, «мусора» в системе будет меньше. Она способна выполнять даже сложные запросы, потому что в ней все разложено по полочкам: информацию легко фильтровать, сортировать, объединять и так далее.
Но бывают и комплексные задачи. И вот тут у реляционной базы данных начинаются проблемы. Она просто не справится, если нам нужно хранить неструктурированную информацию, которая не влезает на «полочки». Например, изображения, видео, данные датчиков сложно вписать в классическую реляционную модель, это требует несоизмеримо больших затрат и ограничивает возможности выполнения запросов.
Здесь-то и приходят на помощь NoSQL базы данных: в них записи хранятся в отдельных документах, парах «ключ – значение», графовых базах данных или базах с широкими столбцами.
• Пара «ключ – значение». Самый простой вид баз данных. Его используют для хранения изображений и видео, а также как кеш, то есть буфер для временного хранения объектов в рекламных и игровых приложениях. Пример работы таких баз данных – сайты популярных компаний, когда при загрузке вы видите начало статьи, а затем кнопку «Еще» или «Подробнее». Именно технология «ключ – значение» позволяет молниеносно подгружать большой текст, когда вы нажимаете на эти кнопки. Этот вид баз данных также подходит для организации пользовательских аккаунтов, каталогов, систем управления контентом, в которых файлы могут меняться с течением времени. Примеры таких баз: Oracle, Berkeley, Redis, Amazon DynamoDB, CouchDB, eXist, MongoDB.
• Колоночная база. Уже знакомая нам таблица, только данные в ней сгруппированы не в строки, а в колонки. Возьмем мобильную рекламную сеть. Обрабатывать большое количество данных ей помогают именно колоночные базы данных. Примеры самых популярных: Vertica, Clickhouse, BigQuery, Cassandra, Apache HBase, Hypertable.
• Графовое хранилище. Их используют для организации дорожных карт, маршрутов транспорта, социальных сетей. Когда вы смотрите рекомендации в онлайн-кинотеатрах, способы добраться из точки А в точку Б, используя несколько видов транспорта, в «Яндекс Картах», или переходите со своей страницы во «Вконтакте» на страницу друга – все это организовано с помощью графовых хранилищ. Примеры: Amazon Neptune, InfoGrid, Orient, Blazegraph, Titan.
Рис. 8. Архитектура SQL и NoSQL
Архитектура NoSQL динамична, может меняться и легко приспосабливаться к переменам в структуре, в отличие от реляционных баз данных. Внутри NoSQL может храниться как структурированная, так и неструктурированная информация. Из-за этого добавлять новые записи гораздо проще, а значит, такие системы хорошо масштабируются для обработки больших объемов записей без потерь производительности. Они лучше справляются с потоковой обработкой данных и аналитическими запросами.
Многие NoSQL базы данных также предоставляют встроенную поддержку распределенности данных и отказоустойчивости. Распределенность данных означает, что они хранятся не на одном сервере, а на нескольких, позволяя подключить к работе дополнительные мощности, быстрее и эффективнее обрабатывать большие объемы информации. А отказоустойчивость – не что иное, как защита от сбоя и поломок. Если выйдет из строя один сервер, то в распределенной системе есть еще несколько, которые возьмут нагрузку на себя. Значит, данные не будут утеряны, а работа не встанет намертво.
Но у NoSQL баз данных есть ряд серьезных ограничений:
• Так как мы отказались от строгой структуры, появился риск того, что данные в какой-то момент потеряют целостность и станут несогласованными, то есть начнут противоречить друг другу.
• NoSQL базы могут быть ограничены в выполнении сложных запросов. К примеру, нам нужно посчитать уникальное количество пользователей, совершивших клик по баннеру на нашем сайте. У баз NoSQL могут возникнуть проблемы с решением такой задачи, а это, в свою очередь, затрудняет аналитику и составление отчетов.
• Гибкость NoSQL баз выступает как плюсом, так и минусом, потому что нет единого стандарта для всех баз данных и они могут быть несовместимы между собой.
• Если вам понадобится обновить схему данных, это может занять много времени.
В таблице (рис. 9) вы видите сравнительные характеристики реляционных баз данных и NoSQL:
Рис. 9. Сравнительные характеристики реляционных баз данных и NoSQL
Колоночные базы данных
Подробно мы остановимся на колоночных базах данных. Сегодня именно они используются там, где реляционные неэффективны. Внешне колоночные и реляционные базы данных как будто даже похожи – и те и другие имеют вид таблицы. Только в колоночных базах данные формируются по колонкам, а не по строкам. Каждая колонка – это узкая таблица, состоящая из одного поля.
На рисунке (рис. 10) пример колоночной базы данных. Значения одного поля в колоночной базе данных хранятся на диске последовательно: A1-A2-A3-А4, затем B1-B2-B3-В4, потом C1-C2-C3-С4.
Рис. 10. Пример колоночной БД
Благодаря такому строению при аналитических операциях с колоночной базой данных скорость обработки информации повышается. Реляционные базы с увеличением нагрузки замедляются или требуют больше вычислительных мощностей, потому что во время создания отчетов им приходится анализировать лишнюю информацию. И чем больше записей (строк), тем заметнее проблема.
Разберем на примере. Нам нужно просуммировать выручку за определенный период, посчитать количество пользователей и количество купленных товаров. Если представить табличную базу данных, то нас будут интересовать в первую очередь три колонки: сумма, количество товаров и число пользователей. Правда, в ней есть еще сотня других колонок: время покупки, география, супермаркет и многое другое.
Если у нас реляционная база данных, то записи хранятся построчно – значит, серверу придется считывать каждую строку целиком, вместе с кучей ненужных данных. Попробуйте скользить глазами по каждой строке по очереди, обязательно от начала до конца, и только потом переходите на следующую. Запомните, сколько времени это у вас заняло.
А теперь представим, что эта же база данных хранится в колоночном формате. Это значит, что мы можем сразу выделить только нужные нам колонки и посчитать информацию из них. Проделайте то же упражнение: найдите глазами выручку, количество пользователей и товаров и пробегитесь по этим трем столбцам сверху вниз. Получилось быстрее, чем в прошлом варианте, правда? А теперь представьте, что таких строк у вас тысячи, сотни тысяч, миллионы. Как вы понимаете, производительность у двух этих методов будет сильно отличаться.
Кроме того, у колоночных баз есть возможность сжатия данных, которые необходимо считывать с диска. Например, если часть записей связана с датой, то записи в файле можно организовать в виде [количество повторов, дата]. Такая запись уменьшает размер базы на несколько порядков. Таким образом, колоночные базы данных требуют в 7 раз меньше памяти.
Пример колоночной базы данных – ClickHouse, которая изначально создавалась для решения задач «Яндекс. Метрики». Ее исходный код доступен для просмотра, изучения, изменения и доработки. Эта база данных позволяет строить произвольные отчеты и выполнять аналитические запросы в режиме реального времени, обрабатывать быстро и точно огромные объемы информации, считать метрики и своевременно формировать аналитические отчеты. Именно поэтому одним из главных преимуществ колоночных баз данных считается скорость. Она превышает самые смелые ожидания – работает в 10–100 раз быстрее реляционных БД.
Еще одно преимущество – расширяемость. Колоночная БД может использовать множество внешних подключений, например интегрироваться с S3 bucket, Apache Kafka или другими.
Следует также отметить и недостатки колоночных систем управления базами данных: медленная запись и неприспособленность для транзакционной работы. Мы можем вставить новую запись в строчную реляционную базу данных с помощью одной операции. Тогда как для записи в столбцовую базу требуется больше вычислительных ресурсов, потому что придется записывать все поля в соответствующие столбцы по одному.
И для закрепления приведу пример из практики.
Однажды ко мне обратились разработчики приложения по организации правильного питания и интервального голодания. Компания хотела стабильно получать маркетинговую информацию и быстро ее анализировать. До этого системно решить задачу не получалось.
Начали разбираться. Оказалось, что для решения вопроса заказчика нужно получать, хранить и обрабатывать несколько типов данных:
• информацию о действиях пользователя в приложении: например, об установке, нажатии кнопок и так далее;
• данные из рекламных кабинетов о продвижении в соцсетях;
• информацию из сторонней системы (данные из виртуальных магазинов, где покупается приложение).
Что у компании уже было?База данных, которая пополнялась в режиме реального времени. Аналитика в фирме не велась, но разработчики понимали, как должно выглядеть хранилище данных, а это уже залог успеха.
Что мы сделали?Осознав, что важна любая информация о работе компании, мы решили собирать ее в неструктурированном виде в одном месте. Для этого выбрали озеро данных, о котором подробнее поговорим чуть позднее. Мы хотели добиться, чтобы ко всей имеющейся информации в режиме реального времени добавлялась новая и все вместе регулярно отправлялось на определенный адрес в интернете. Там с помощью специальных программ и скриптов она преображалась, структурируясь, в колоночную базу данных. Мы фиксировали:
• события, которые происходят в приложении (клики, переходы по разделам, покупки и переписки пользователей);
• события, которые отвечают за выручку (фиксируется каждая покупка);
• данные о рекламных расходах.
Преобразование данных из неструктурированного вида в четкую колоночную базу позволило компании легко и быстро писать запросы, получать информацию об эффективности рекламных кампаний, выручке и активности пользователей. Цель была успешно достигнута!
Подводя итог, замечу, что у каждой базы данных есть свои минусы и плюсы.
А потому, чтобы использовать все преимущества реляционных и нереляционных баз и минимизировать их недостатки, сегодня специалисты используют в работе так называемые гибридные базы данных.
Гибридные базы данных
Часто лучшим решением становится именно сочетание реляционной и NoSQL баз данных. Такой вариант называется гибридной базой данных (рис. 11).
Гибридные базы данных активно развивались в течение последних десятилетий. В 2013 году компания Gartner ввела термин «гибридная транзакционная/аналитическая обработка» или HTAP. Основное преимущество архитектуры HTAP – одновременное выполнение транзакционных и аналитических процессов, что дает больше возможностей для сбора и обработки данных.
Рис. 11. Гибридная БД
На сегодняшний день эти базы редко встречаются в деятельности компаний, поскольку для компаний переход с налаженной схемы работы на новый формат выходит слишком энергозатратным и дорогостоящим, даже если этот переход сулит выгоду в дальнейшем. Тем более при таких масштабных переменах работа предприятия на время приостанавливается, а на это готов пойти не каждый руководитель. Именно поэтому гибридные базы данных так и не нашли широкого распространения. Однако это интересный тренд, который сочетает плюсы обеих систем.
Надежность. Гибридные базы зачастую используют для хранения информации как открытое, так и частное облачное хранилище. Новые гибридные базы данных позволяют создавать гибридные облака, в которых можно хранить записи и запускать приложения в нескольких средах. Это сокращает время простоя и обеспечивает устойчивую работу бизнеса. Например, если частная структура обновляется, на некоторое время перекрывая доступ к вашему личному облаку, можно перенести рабочие нагрузки в публичные (открытые) облачные среды.
Высокий уровень доступности. За счет того, что NoSQL вместо таблиц использует гибкие модели хранения данных – документы, графы, пары «ключ – значение», – мы получаем более легкий доступ к данным. К примеру, вводя комментарий к записи в социальных сетях, вы моментально видите, как он подгружается и отображается на странице.
Масштабируемость. За счет использования реляционных таблиц нет нужды хранить в оперативной памяти всю базу данных.
Гибкость. Гибридные базы могут работать с большим объемом совершенно разных данных: файлов, баз с информацией, транзакций. Могут практически моментально анализировать данные и на основе этого помогать принимать решения. Этот процесс называется гибридной транзакционной и аналитической обработкой (Hybrid Transaction-analytical Processind – HTAP). Благодаря этому базы подходят для сервисов и приложений, работающих в режиме реального времени.
Стабильность работы. Гибридные базы данных могут обеспечить бесперебойную онлайн-работу с клиентами. Для этого как раз используется HTAP. Сейчас это самая экономически выгодная стратегия, позволяющая достичь максимальной производительности и скорости работы.
Но не все так просто. Чтобы получить результат от сложных гибридных баз данных, компаниям нужно серьезно подойти к вопросу их разработки и внедрения. Важно, чтобы возможностей и мощностей серверов было достаточно для согласованной работы и быстрого доступа к данным.
На практике гибридные базы данных обычно используют в двух вариантах.
База данных документов
С одной стороны, реляционной системе не хватает гибкости: каждый раз, когда вводится новая информация, обновляется вся база и на обработку тратятся дополнительные ресурсы и время. Но если в систему добавить документы NoSQL, то сотрудники компании смогут по мере необходимости легко создавать и вносить новые данные. Все записи при этом будут храниться в виде отдельных документов, защищенных от любых изменений в будущем.
Пример такого решения – Couchbase или MongoDB. Они предлагают поддержку JSON-массивов внутри значений таблицы данных. Допустим, у нас хранится запись о пользователях социальной сети и с помощью NoSQL мы можем подгрузить такую информацию: пользователь наводит курсор на имя человека на его личной странице, и сразу же отображается окошко с количеством друзей, местом обучения или проживания и другими данными. При этом рабочий процесс становится проще, но данными сложнее управлять по сравнению с обычной таблицей.
База данных In-Memory и графовая база данных
Как онлайн-магазины могут рекомендовать продукт, который потенциально может вас заинтересовать? С помощью анализа ваших предыдущих покупок, поисковых запросов и просмотров тех или иных товаров.
И, опять же, лучше всего в этом разобрались социальные сети. Они пристально «наблюдают» за нашими интересами, на основании которых рекламодатели таргетируют рекламу. Но если использовать для этого реляционную базу данных, возникнет проблема: для получения результатов нужно запрашивать и объединять сразу несколько таблиц. А это невозможно сделать быстро.
Одно из решений – перед добавлением данных в реляционную базу загрузить эти же массивы информации в оперативную память. Что это значит? Обычно база данных считывает информацию с физического носителя – жесткого диска, но можно также хранить данные в оперативной памяти. Таким образом, база данных будет считывать сведения гораздо быстрее. Она будет кешировать все предварительные расчеты, нужные для выполнения запросов, в оперативной памяти, а не обращаться раз за разом к диску.
Более выгодный вариант – создание графовых баз, в которых будут отслеживаться все ваши предпочтения, ваши друзья и их интересы. Графовые базы данных ищут и по сущностям, и по связям между ними. За счет этого они оптимизированы для быстрого поиска и выполнения запросов. Примеры таких баз in-memory – Memcached и Redis.
Подводя итог, можно сказать, что все вышеперечисленные базы данных – реляционные, NoSQL, гибридные – эффективны и полезны в зависимости от конкретных целей и проектов. Просто к их выбору и созданию нужно подходить осознанно и с пониманием, учитывая все факторы, задачи и ожидания.