OLTP и OLAP
~ 35 минут
При проектировании ландшафта информационных систем любого предприятия рано или поздно встаёт проблема смешения процессов обработки данных. Операционные бизнес-процессы почти всегда порождают множество небольших транзакций, которые должны обработаться в режиме реального времени, надёжно и непротиворечиво, — такую нагрузку относят к транзакционной, OLTP (англ. Online Transaction Processing).
Ещё бизнес-процессы часто вызывают необходимость дальнейшего анализа их результатов. И эта аналитическая обработка данных носит уже совершенно другой характер — такую нагрузку называют аналитической, OLAP (англ. Online Analytical Processing).
В этом уроке разберём один из важнейших навыков в настройке архитектуры ПО — умение распознавать в ландшафте систем предприятий ситуации смешения транзакционной и аналитической нагрузки.
Типы нагрузки
Глобально есть два вида нагрузки: транзакционная и аналитическая. Они предъявляют разные требования к системам, которые с ними работают. Поэтому, исходя из типа нагрузки на систему, выделяют два типа архитектур:
- OLTP, или Online Transaction Processing. Её используют для приложений или сервисов, которые ориентированы на транзакции в режиме реального времени. Это значит, что им важно гарантировать транзакционную целостность операций по изменению данных в БД.
- OLAP, или Online Analytical Processing. Она предназначена для выполнения сложных аналитических запросов, которые включают агрегирование данных из нескольких источников и выполнение углублённого анализа данных и бизнес-аналитики.
Обратите внимание: «архитектурой» OLTP и OLAP можно назвать только условно. Это скорее набор требований, возможных решений и инструментов, которые позволяют работать с разными типами нагрузки. Сложно описать их с помощью референса реализации или дать гайд для внедрения.
OLTP
Когда приложения должны обрабатывать данные в режиме, приближённом к реальному времени, и требуют надёжной и согласованной работы хранилища для бизнес-данных, реализуется OLTP-архитектура.
OLTP отвечает за выполнение важных задач в бизнес-сценариях. Например, в системах электронной коммерции и системах бронирования авиабилетов — это обработка заказов клиентов, а в банковских системах — финансовых транзакций. То есть операционная деятельность в любом бизнес-домене почти гарантированно использует OLTP.
Характеристики баз данных, реализованных на OLTP-архитектуре
- Быстрая обработка запросов OLTP-системы используются для высокоскоростной обработки запросов. Хотя они в первую очередь ориентированы на транзакционные операции, эти системы эффективно справляются и с задачами, требующими интенсивного чтения. OLTP-архитектура гарантирует, что транзакции выполняются сразу после их получения, практически без задержек. Ключевая метрика, по которой можно оценить OLTP-систему, — это общее число транзакций в единицу времени.
✏️ OLTP-транзакции, как правило, короткие и простые. Они включают в себя вставку, обновление и удаление данных, а также простые запросы и базовые задачи поиска данных.
- Параллелизм Базы данных OLTP спроектированы таким образом, что транзакции одновременно могут быть инициированы несколькими пользователями. Каждая транзакция выполняется независимо от других и в правильном порядке. Два пользователя не могут изменять одни и те же данные в базе данных OLTP одновременно, что имеет решающее значение для сохранения целостности данных.
- Свойства ACID
Чтобы обеспечить целостность, согласованность и надёжность данных, OLTP-транзакции соответствуют свойствам ACID (от англ. atomicity, consistency, isolation, durability):
- Атомарность — транзакции в OLTP-системах обрабатываются как единая, неделимая единица работы. Если какая-либо часть транзакции завершается сбоем, выполняется откат всей транзакции и база данных остаётся в исходном состоянии.
- Согласованность — базы данных OLTP предназначены для поддержания согласованности данных, несмотря на сбои или ошибки. Каждая транзакция изменяет таблицы предопределёнными и предсказуемыми способами, и база данных всегда будет находиться в допустимом состоянии.
- Изоляция — транзакции в системах OLTP изолированы друг от друга. Когда несколько пользователей одновременно читают и записывают данные, эти операции выполняются независимо. Изоляция гарантирует, что изменения, внесённые одной транзакцией, не будут влиять на изменения, внесённые другими.
- Надёжность — когда транзакция успешно выполняется в базе данных OLTP, изменения в данных являются постоянными и сохраняются при любых последующих сбоях или ошибках. Например, при сбоях в работе системы или перебоях в подаче электроэнергии.
4. Свойства BASE
BASE означает базовую доступность (Basically Available), мягкое состояние (Soft state) и согласованность в конечном счёте (Eventually consistent). Этот подход выступает как бы противовесом подходу ACID — в смысле тех гарантий и механизмов, которые они обеспечивают по работе с данными.
💡ACID приоритет отдаётся согласованности в ущерб доступности.
BASE — приоритизируется доступность в ущерб согласованности.
Принципы BASE важно понимать, чтобы сделать выбор между технологиями проектирования системы.
- Базовая доступность — здесь фокус на максимальной доступности базы данных для всех пользователей в любое время. Пользователь не ждёт завершения параллельных транзакций, прежде чем внести свои изменения. Это полезно, когда трафик внезапно возрос и нужно обеспечить работоспособность критически важных бизнес-функций. Другие бизнес-функции при этом продолжают работать, но с задержкой в актуализации данных. Например, в интернет-магазине могут быть критически важными выдача и приём заказов, но функция обновления количества запасов будет работать с небольшой задержкой, при этом пользователи всегда имеют возможность купить товар.
- Мягкое состояние означает, что данные могут находиться в промежуточных или временных состояниях перед тем, как попасть в базу данных, и возможно их неоднократное изменение в соответствии с бизнес-логикой перед финальным сохранением в базе данных. Это свойство тоже учитывает многопользовательский режим работы с данными. Финальное значение для такой записи будет в конечном итоге определено при завершении всех транзакций. Например, если пользователи (редакторы или авторы) одновременно редактируют статью, то внесённые ими изменения могут быть не сразу видны другим. Через некоторое время система учтёт все внесённые изменения и произойдёт обновление статьи, и это действие выполнится не при явной инициации от конкретного пользователя, а в соответствии с логикой работы системы.
- Согласованность в конечном счёте означает, что запись в базе данных достигнет согласованности (consistancy в ACID) не сразу, а после завершения всех одновременных обновлений. Тогда все сервисы, работающие с этой записью, увидят одно и то же значение. Здесь тоже подойдёт пример со статьёй.
Проблема параллельного изменения данных
Поговорим подробнее об одном из ключевых свойств OLTP-системы — изоляции. Для её обеспечения СУБД реализуют так называемые уровни изоляции транзакций, которые призваны решить стандартные проблемы, связанные с параллельным изменением данных:
- Потерянное обновление (lost update). Одновременное изменение строки в таблице базы данных несколькими транзакциями приводит к сохранению последнего изменения, а все предыдущие теряются.
- «Грязное» чтение (dirty read). Одна транзакция может прочитать данные, которые были изменены другой транзакцией, но ещё не подтверждены. Если вторая транзакция откатит изменения, первая окажется в ситуации, когда она работала с данными, которые фактически не существуют или были отменены.
- Неповторяющееся чтение (non-repeatable read). Транзакция дважды читает одни и те же данные, но между этими чтениями другая транзакция изменяет или удаляет их. В результате данные оказываются разными при каждом чтении.
- Фантомное чтение (phantom read). Проблема похожа на non-repeatable read, но в этом случае, когда транзакция повторно выполняет запрос к базе данных по одинаковым критериям (например, критерии фильтрации where или объединения join) и получает разные наборы данных, потому что другая транзакция добавила, изменила или удалила строки, соответствующие критериям запроса. Это приводит к тому, что одни и те же выборки дают разные множества строк: записи «появляются» или «исчезают», как если бы они были фантомами.
Уровни изоляции
Чтобы предсказуемо получать гарантии решения или, наоборот, осознанно допускать указанные проблемы в СУБД, были разработаны уровни изоляции.
Кажется, зачем осознанно оставлять проблемы изоляции? Всё дело в том, что решение этих проблем требует определённых ресурсов и включения дополнительной логики со стороны СУБД. Поэтому в принятии архитектурного решения приходится делать выбор между уровнем изоляции, каждый из которых даёт некоторые гарантии по решению проблем, и уровнем производительности. Также нужно учитывать, какой уровень изоляции допустим для приложения в соответствии с его бизнес-логикой.
Выделяют четыре уровня изоляции транзакций:
- Read uncommitted (чтение незафиксированных данных) — самый низкий уровень изоляции, который решает только проблему lost update, но допускает все остальные (dirty read, non-repeatable read и phantom read).
- Read committed (чтение фиксированных данных) — этот уровень изоляции разрешает работу только с подтверждёнными данными, ограничивая lost update и dirty read.
- Repeatable read (повторяющееся чтение) — на этом уровне изоляции читающая транзакция не учитывает изменения данных, которые были ею ранее прочитаны. Кроме того, никакая транзакция не может изменять данные, пока текущая транзакция не закончит чтение. Обеспечивает гарантии lost update, dirty read, non-repeatable read.
- Serializable (упорядочиваемость) — наивысший уровень изоляции, который решает все указанные проблемы по изоляции данных, но самый ресурсоёмкий по реализации. Побочный эффект этого уровня — замедление всех процессов чтения-записи.
Для OLTP используют разные базы данных. Самые популярные: MySQL, PostgreSQL, Microsoft SQL Server, Oracle, MongoDB.
OLAP
OLAP используют для аналитики. Основной сценарий — запрос данных для анализа и их представление в удобном для этого виде.
OLAP универсальна — компании применяют её для управленческой аналитики практически во всех отраслях, например:
- В здравоохранении анализируют длительность пребывания пациентов в учреждении, число задействованных медработников, диагнозы и демографию. Эти данные помогают улучшать уход и оптимизировать процессы.
- На производстве анализируют прибыльность клиентов и продуктов для планирования и распределения ресурсов, прогнозирования спроса и управления запасами. Ещё OLAP помогает выявлять отклонения и зоны улучшения операций.
- В рекламе изучают поведение клиентов, отток и вовлечённость. Это помогает адаптировать кампании для целевой аудитории и повысить отдачу от маркетинга.
Внедрение OLAP в разные отрасли говорит о её эффективности. Она преобразует необработанные данные в ценные знания — это помогает бизнесу принимать эффективные решения и добиваться успехов.
Архитектурные особенности OLAP
В OLAP есть два основных варианта архитектуры внутреннего хранения данных:
- Колоночное хранение — данные хранятся в колонках, колонки записаны на диск непрерывно.
- Строчное хранение — данные хранятся в строке, строка записывается на диск целиком и непрерывно.
Способ хранения влияет на скорость чтения и фильтрации данных для аналитических запросов. Колоночное хранение позволяет быстрее считывать несколько колонок: загружаются только нужные колонки и их расположение на диске заранее известно. В строчном хранении требуется считывать всю строку — даже если нужны только отдельные колонки.
Популярные базы данных для OLAP — ClickHouse, Apache Kylin и Snowflake.
Сравнение OLTP и OLAP
Совместное использование OLAP и OLTP — не лучшая идея
Многие объединяют OLAP- и OLTP-системы для создания гибридной базы данных. Такая база обеспечивает доступ к данным транзакций в реальном времени и позволяет проводить анализ исторических данных.
Например, операционная система принимает заявки на пополнение запасов на складе и прогнозирует их, чтобы оптимизировать затраты на закупки. Это позволяет закупать товар вовремя и в объёме, соответствующем ожидаемому спросу. Здесь приём заявок — OLTP-нагрузка, а аналитика для прогнозирования заявок — OLAP-нагрузка.
Такое объединение OLTP и OLAP не является архитектурно правильным в долгосрочной перспективе. Представьте, что разрабатываете сервис заявок. Пользователи отправляют заявки на заказы, а вы сохраняете заявки и затем обрабатываете. Допустим, вы пытаетесь вытащить данные из базы по сложному запросу, но этих данных слишком много. Из-за того, что данных много, операции чтения тормозят операции записи.
Вы сталкиваетесь с конфликтом: OLAP подразумевает большие объёмы данных, а OLTP важна скорость реакции и операции в реальном времени. Эти требования противоположны друг другу. Из-за этого архитектуры OLTP и OLAP лучше не использовать совместно.
Архитектура хранилищ данных
✏️ Хранилище данных — специальный тип систем, предназначенный для централизованного хранения, объединения данных и предоставления их пользователям.
Данные часто поступают из нескольких источников: транзакционных систем, файлов журналов и внешних источников. В хранилище они преобразуются и загружаются для дальнейшего анализа.
Существует несколько стандартных архитектур хранилищ данных. Основное требование — современные хранилища должны уметь работать и с «медленным» потоком данных — обычно поставляемых в хранилище в пакетном режиме по расписанию, и с «горячим» потоком данных — поставляемых в хранилище по мере их формирования в системах-источниках.
Архитектура любого хранилища данных состоит из таких блоков:
- Блок поставки данных — как пакетных, так и потоков данных.
- Блок физического хранения данных — инфраструктура, в которой хранятся данные.
- Блок архитектуры данных — методики и инструменты, определяющие структуру и архитектуру хранения данных в хранилище.
- Блок представления данных — то, что даёт возможность доступа к данным хранилища для внешних потребителей. Обычно этот слой называют витринами. Доступ к ним осуществляется как к табличным данным или через API.
Так выглядит общая архитектура хранилища данных (DWH):
Пример
В строительной компании зафиксировали падение выручки от продаж за квартал. Аналитик, чтобы найти причину, изучил ключевые показатели бизнеса, обращаясь к данным хранилища. Результат исследований он оформил в виде BI-отчёта, в котором видна аналитическая зависимость влияющих на падение выручки от продаж показателей.
В своей работе аналитик оперировал только данными хранилища, а не нескольких систем источников. Их можно было исследовать по отдельности, но такие данные было бы невозможно свести в единый результирующий отчёт.
Перечислим наиболее популярные сегодня варианты архитектур хранилищ данных. При этом сделаем фокус на распределённых хранилищах данных, так как традиционные, монолитные, архитектуры фактически выходят из употребления.
Data Warehouse (хранилище данных)
Архитектура таких хранилищ наиболее близка к традиционным хранилищам, data warehouse, или просто хранилище данных, представляет собой единый источник «правды» в компании и служит основным компонентом отчётности и бизнес-аналитики.
Как правило, data warehouse сохраняют исторические данные путём объединения наборов реляционных данных из нескольких источников, включая прикладные, бизнес-данные и транзакционные данные. Данные извлекаются из нескольких источников, преобразуются и очищаются перед загрузкой в систему хранения так, чтобы их можно было считать единым источником правды.
Для data warehouse характерно, что процесс преобразования данных, ETL выполняется до того как данные попадут в хранилище.
К минусам такого типа архитектуры можно отнести способность обрабатывать только хорошо структурирвоанные данные и, соответственно, большие затруднения при работе с неструктурированными данными. А ещё высокую стоимость внедрения и сопровождения.
Data Lake (озёра данных)
✏️ Озеро данных — это централизованное, обладающее высокой гибкостью хранилище, в котором большие объёмы структурированных и неструктурированных данных хранятся в их необработанном, оригинальном и неотформатированном виде.
В отличие от хранилищ данных, в которых хранятся уже «очищенные» реляционные данные, озеро данных хранит данные, используя плоскую архитектуру и объектное хранилище в необработанном виде. Это дает возможность работать с данными в их изначальном виде и извлекать из них больше информации, особенно если они не структурированы или сложны для традиционных систем.
В озёрах данных схема или данные не определяются при захвате данных — вместо этого данные извлекаются, загружаются и преобразуются (ELT) для целей анализа. Озёра данных позволяют выполнять задачи машинного обучения, прогнозирования и многие другие, в которых важна работа с исходными неизменными данными.
Но преимущества определяют и недостатки такой архитектуры.
Минусы этого типа архитектуры:
- Озеро данных может достаточно быстро стать системой хранения данных с высокой степенью неструктурированности данных, в которых сложно навигироваться и к которым сложно применить BI- и ML-инструменты.
- Недостаточный уровень безопасности доступа к чувствительным данным: в неструктурированных данных сложно отследить чувствительные данные и установить контроль доступа к ним.
Data Lakehouse (дом для данных)
Data lakehouse — это новая архитектура хранения больших объёмов данных, которая сочетает в себе лучшие возможности как хранилищ данных, так и озёр данных. Она обеспечивает единое хранилище для всех типов данных: структурированных, полуструктурированных и неструктурированных. И предоставляет лучшие в своём классе возможности машинного обучения, бизнес-аналитики и потоковой передачи.
Data lakehouse обычно создаются как хранилища данных, содержащие все типы данных. Затем данные преобразуются в формат delta lake, который позволяет дать ACID-гарантии как в традиционных хранилищах и при этом сохранить возможности работы с хранилищем как с OLAP.
Метрики баз данных
Метрики в хранилищах данных, как и в любых IT-системах, помогают быстрее, точнее и объективнее оценить качество работы системы. Метрики баз данных можно объединить в несколько групп — вот три основных:
- Метрики объёма по объектам хранения. Контроль размеров хранимой сущности: таблица, группа таблиц, слой хранения.
- Метрики загрузки данных. Контроль выполнения ETL-процессов и обработки потоков, включая контроль основных параметров по CPU и RAM.
- Метрики хранилища. Контроль процессов чтения и записи данных хранилища на диски, выборки данных для определения медленных или самых ресурсоёмких запросов.
Ещё есть метрики качества, но в этом уроке о них не будем говорить подробно.
Метрики в хранилищах данных, как и любые другие метрики в IT-системах, — это средство, с помощью которого мы быстрее, точнее и объективнее можем оценить качество работы любой системы.
Метрики можно объединить в следующие группы:
Метрики объёма по объектам хранения
- Контроль размеров хранимой сущности: таблица, группа таблиц, слой хранения.
Пример
Ритейл-компания хранит данные о продажах.
Для OLAP-модели отслеживается объём данных за каждый месяц по категориям товаров (например, размер таблицы с продажами за октябрь), чтобы понимать, как растёт аналитическая нагрузка.
Для OLTP-модели контролируется общий объём таблицы с транзакциями или её шарды, чтобы вовремя планировать масштабирование базы из-за роста числа онлайн-покупок.
Метрики загрузки данных
- Контроль выполнения ETL-процессов.
- Контроль обработки потоков: включая контроль основных параметров по CPU и RAM.
Пример
В платформе электронной коммерции ежедневно выгружаются данные о заказах из CRM в хранилище для аналитики. Метрики скорости загрузки показывают, что ETL-процесс стал дольше на 20% после запуска акции. Это позволяет выявить узкое место (например, медленный источник данных) и оптимизировать трансформацию, чтобы избежать задержек в аналитике.
Метрики хранилища
- Контроль процессов чтения и записи данных хранилища на диски.
- Контроль процессов выборки данных: цель найти медленные или самые ресурсоёмкие запросы.
Пример
Финансовая компания фиксирует медленные запросы в хранилище данных, анализирующие расчёт доходности по всем клиентам. Для OLTP-модели метрика I/O (чтения/запись) в дисковый массив хранилища выявила, что запросы интенсивно используют диск из-за недостаточной оптимизации индексов. На основании этой метрики запросы оптимизировали, что сократило время обработки отчётов с 10 до 3 минут, улучшив пользовательский опыт аналитиков.
Задание 2
Соотнесите каждое приложение с типом системы, которая подходит для его работы — OLAP или OLTP.
Что почитать про метрики хранилища данных
- Статья о метриках хранилища данных на Хабре.
- Статья на Хабре 2012 года о метриках хранилища данных. Автор предлагает набор метрик, которые помогают оценить эффективность и производительность хранилища.
- Сравнение двух типов систем обработки данных: примеры и рекомендации использования OLAP и OLTP.
- Статья на Хабре о концепции качества данных и его значении для организаций.
Итоги
- Есть два вида нагрузки — транзакционная и аналитическая. Для каждой есть свой тип архитектур — OLTP, или Online Transaction Processing, и OLAP, или Online Analytical Processing.
- OLTP используют для работы с транзакциями в реальном времени. Им важно гарантировать транзакционную целостность операций по изменению данных в базе.
- Для поддержания целостности данных OLTP-архитектуры используют свойства ACID: атомарность, согласованность, изоляцию и надёжность. Важным аспектом являются уровни изоляции транзакций — они нужны, чтобы предсказуемо получать гарантии решения или осознанно допускать указанные проблемы в СУБД.
- OLAP предназначена для выполнения сложных аналитических запросов — агрегирования данных из нескольких источников, выполнения углублённого анализа и бизнес-аналитики.
- В OLAP есть два основных варианта архитектуры внутреннего хранения данных — колоночное и строчное. Колоночное позволяет быстрее считывать несколько колонок. Строчное подходит для операций, где требуется доступ к полным строкам данных.
- Лучше не использовать OLTP и OLAP вместе. OLAP подразумевает большие объёмы данных, а OLTP важна скорость реакции и операции в реальном времени. Эти требования противоположны друг другу — операции чтения могут тормозить операции записи.
- Существует несколько стандартных архитектур хранилищ данных. Они состоят из нескольких блоков: поставки данных, физического хранения данных, архитектуры данных и представления данных. Современные хранилища должны уметь работать и с «медленным» потоком данных, и с «горячим».
- Оценивают эффективность хранилища с помощью метрик. Основные группы метрик: метрики объёма по объектам хранения, метрики загрузки данных, метрики хранилища и метрики качества.