Designing Data-Intensive Applications

Глава 1. Trade-Offs in Data Systems Architecture

Введение

Первая глава книги получилась объёмной как по количеству страниц так и по количеству информации. По сравнению с первым изданием появилось упоминание Single-Node Data Warehouse решений на примере DuckDB, SQLite, но без деталей. Детали будут раскрываться уже в более поздних главах.

Основная мысль первой главы дать читателю понимание, что нет “серебряной пули”, и в каждом решении существуют как свои плюсы так и минусы (trade offs). Посыл авторов благородный, помочь читателю разобраться в море различных технологических решений. Дать фундамент, который будет помогать принимать правильные решения при проектировании архитектуры будущих приложений.

Что изменилось по сравнению с первым изданием? Первое издание книги вышло в 2017 году, с тех пор прошло 9 лет. Мир не стоит на месте, технологии развиваются. По словам авторов, в новом издании они постарались уделить достаточно внимания технологиям вокруг ИИ инфраструктуры, cloud native решениям на базе хранилищ объектов по типу Amazon S3, полностью переписали главу про Batch Processing из-за неактуальности MapReduce в наше время (при проектировании новых архитектур).

Конспект

Приложение считается Data-Intensive, если управление данными это одна из его ключевых задач.

Основные вызовы у таких приложений

— эффективная обработка и хранение большого массива данных
— обеспечение доступности данных в условиях отказа частей системы
— обеспечение согласованности данных (data consistency)

Главные строительные блоки

— Базы данных для хранения информации (например, PostgreSQL, MySQL, Microsoft SQL Server и т.д.)
— Кэш-системы для обеспечения быстрого доступа к данным (например, Redis, memcached)
— Поисковые движки для обеспечения быстрого поиска в большом массиве данных (Elasticsearch, Sphinx)
— Системы для потоковой обработки данных (Apache Flink, Apache Storm)
— Системы для пакетной обработки данных (Apache Hadoop, Apache Spark)

Примеры конкретных инструментов это моё личное дополнение, их множество, здесь приведены лишь наиболее популярные и те, что у меня на слуху. От себя я бы ещё добавил, что рука об руку с обработкой данных идут и различные оркестраторы и workflow-менеджеры по типу Apache Airflow, Oozie, Luigi, NiFi, Prefect, Dagster и т.д.

Типы баз данных

— Транзакционные (OLTP), авторы в книге также называют их операционными
— Аналитические (OLAP)

Транзакционные базы используются там, где данные берут своё начало, а именно базы для бэкенда приложения с которым пользователи взаимодействуют через фронтенд (веб-приложения, мобильные приложения и т.д.). Транзакционным базам присущи точечные запросы на чтение, запись, обновление или удаление. Например, по user_id. Запросы преимущественно формируются на стороне приложение, пользователь напрямую не имеет доступа к базе и не пишет запрос. Примеры: PostgreSQL, MySQL, Oracle DB, Microsoft SQL Server.

Аналитические базы данных используются для работы с данными для принятия решений на стороне бизнеса. Такие базы хранят в себе данные, собранные в том числе из транзакционных баз. Пользователями таких баз в основном являются бизнес и дата аналитики, Data Science специалисты. Зачастую они напрямую посылают запросы к базе, используя SQL. Запросы чаще всего большие и подразумевают обработку огромного набора данных (большие выборки). Примеры: Amazon Redshift, ClickHouse, Apache Druid, Pinot.

Современный подход к организации данных подразумевает четкое разделение между OLTP и OLAP. Но до массового внедрения OLAP транзакционные базы данных использовались и в качестве хранилища аналитических данных. Были придуманы способы моделирования аналитических данных с учётом ограничений реляционной модели, например, Star Schema, Snowflake Schema. В условиях современных OLAP баз данных такие подходы устарели.

Связь между OLTP и OLAP