МИНИСТЕРСТВО ВЫСШЕГО ОБРАЗОВАНИЯ, НАУКИ И
ИННОВАЦИЙ РЕСПУБЛИКИ УЗБЕКИСТАН ТАШКЕНТСКИЙ
УНИВЕРСИТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ ИМЕНИ
МУХАММАДА АЛЬ-ХОРАЗМИЙ
Cамостоятельная
Работа
по предмету База данных на тему:
« Архитектура систем баз данных. »
Группа: 065-23
Выполнил(a): Нуритдинова Севара
Проверил(a): Мухторова Г.Х.
Ташкент 2025г.
План:
1. Введение
2.Основная часть:
2.1. Что такое архитектура данных и как её построить
2.2. Архитектура СУБД
2.3. Погружение в различные подходы к построению хранилищ
данных
3.Заключение
4.Список использованной литературы
Введение
Архитектура данных — это описание того, как в компании организована
работа с данными. Функция архитектуры — систематизировать эту работу:
создать базу данных, настроить процесс их сбора, определить условия хранения
и правила обработки. Архитектура данных — это перечень документов, в нём
собраны правила, методики, термины, ПО и даже список сотрудников, которые
будут работать с базой данных.
Допустим, в компании решили запустить маркетплейс. Чтобы проект
работал без сбоев, придётся собирать, хранить и обрабатывать большое
количество данных: информацию о товарах, поставщиках, покупателях, заказах,
доставках. Без архитектуры это будет сложно делать.
Архитектуру проектируют инженеры данных. Для этого специалист
должен знать специфику работы компании, какие данные будут собирать и для
каких целей они нужны. В зависимости от задачи инженер проектирует
архитектуру баз данных: что, как, где и по каким правилам будет храниться и
обрабатываться. Инженер редко получает готовое ТЗ и в основном
самостоятельно собирает информацию, общаясь с заказчиком и коллегами.
2.Основная часть:
2.1. Что такое архитектура данных и как её построить
Архитектура данных состоит из модели, стратегии, правил и стандартов.
В модели описывают, как данные взаимодействуют между собой и с другими
сферами, например бизнес и техническая часть, то есть сотрудники компании и
серверы.
Эту модель архитектуры баз данных ещё называют лямбда-архитектурой. Она
подходит для хранения и обработки в реальном времени больших данных,
которые поступают быстрыми потоками, например данные со стриминговых
платформ
Стратегия — это то, для чего создают архитектуру данных. Например, в
компании собирают данные, чтобы улучшить качество клиентского сервиса или
работу рекомендательных систем.
Архитектура данных рассчитывается на основе сферы деятельности.
Архитектура для компании по разработке игр будет отличаться от архитектуры
для интернет-магазина, а архитектура для интернет-магазина — от архитектуры
для маркетплейса.
У бизнеса могут быть разные задачи, поэтому инженер данных
проектирует архитектуру на основе диалога с заказчиком.
Правила и стандарты — это набор принципов работы с архитектурой
данных, их ещё называют политикой. Эти принципы зависят от того, какой тип
базы данных выбран для хранения — простейший, реляционный, NoSQL или
комбинированный.
Нельзя сформировать архитектуру баз данных по готовому шаблону или
скопировать у ближайшего конкурента. У каждого заказчика свой подход к
работе и особенности, поэтому инженеру данных важно их выяснить до начала
проектирования,
чтобы
потом
не
переделывать
всю
архитектуру.
Инженеру данных могут заказать архитектуру для хранения результатов
медицинского исследования или для архивации документов. Студенты курса
«Инженер данных с нуля» учатся проектировать разные типы архитектур
данных на задачах реальных бизнесов. Во время обучения вместе с опытной
командой они реализуют несколько проектов для разных сфер бизнеса.
В архитектуре баз данных описывают, как организовать потоки данных, и
определяют подходящий тип базы и СУБД. Например, для интернет-магазина
больше подойдёт реляционная база данных, а производителю товаров —
документоориентированная
БД
для
хранения
неструктурированной
информации типа описания товаров или инструкций по эксплуатации.
На этапе проектирования нужно выбрать методы и способы очистки данных и
определить форму нормализации. Например, какие записи следует удалять из
базы и как это делать — с помощью встроенных в хранилище инструментов,
специально написанных скриптов или вручную.
Чаще всего представители бизнеса, которые будут пользоваться данными,
не владеют SQL или Python. Чтобы им не пришлось учиться писать запросы,
нужно продумать графический интерфейс или дашборды, на которых будут
визуализироваться нужные данные.
Чтобы ответить на эти вопросы, инженер данных общается с заказчиком
архитектуры, аналитиками данных и бизнес-аналитиками, специалистами по
Data Science.
2. Создание архитектуры данных
При проектировании архитектуру данных описывают на трёх уровнях:
● внешний,
● концептуальный,
● внутренний.
Внешний уровень архитектуры данных ещё называют бизнес-уровнем. На
нём продумывают, как архитектура будет помогать бизнесу работать с
данными: как сотрудники заказчика будут видеть базу, ориентироваться в
данных и принимать на их основе решения. Для разных отделов могут быть
созданы разные графические интерфейсы, сценарии и методики. Допустим,
отдел логистики отслеживает сроки доставки, количество товаров на складе,
загруженность дорог в разное время в разных районах города, а отделу
маркетинга нужны данные о трафике на сайт, количестве заявок и стоимости
рекламных кампаний.
На этом уровне описывают модель базы данных, методики для анализа и
прогнозирования, выбор которых зависит от бизнес-задач.
Наличие специалистов в компании — тоже одна из бизнес-составляющих,
которую учитывают при проектировании архитектуры данных. Например,
чтобы работать с данными, компании нужно нанять аналитика.
На концептуальном уровне описывают структуру базы данных: какие данные
в ней хранят, их атрибуты и сущности, как данные обрабатывают и как они
связаны между собой. Концептуальный уровень — это то, как видит базу
данных её администратор.
На этом уровне также описывают:
● методики работы с архитектурой, например инструкции, схемы или перечень
навыков, которым нужно обучить сотрудников компании;
● правила безопасности, например, кто из сотрудников получит доступ
редактировать данные.
На техническом, или внутреннем, уровне описывают, какой объём у данных,
как и где их будут хранить и что для этого нужно. Допустим, какой сервер и
ПО компания должна закупить для организации хранения.
Архитектуру описывают для трёх групп пользователей: представителей бизнеса,
которые будут использовать данные, администраторов, которые будут
управлять базой, и технических специалистов, которые будут следить за
серверами и ПО
Развитие архитектуры данных
Данные множатся в геометрической прогрессии — десять лет назад их было в
миллионы раз меньше. На основе данных делают прогнозы и зарабатывают
деньги. Это значит, что нужны новые инструменты для работы с ними, потому
что никто не хочет терять такой ценный ресурс.
Раньше для хранения данных нужен был физический сервер, сейчас компании
могут купить место в облачном хранилище для любого объёма данных
Вариаций
архитектур
данных
много,
они
постоянно
развиваются
и
подстраиваются под современные требования. В рамках отдельной компании
архитектура данных тоже может развиваться вместе с бизнесом. Допустим,
компания открыла интернет-магазин. В магазине 15 позиций товаров, а у
компании два поставщика. Постепенно бизнес растёт, и в интернет-магазине
уже тысяча позиций, а компания работает с сотней поставщиков. Предыдущая
архитектура уже не справляется с увеличенным потоком данных, поэтому её
нужно менять.
2.2. Архитектура СУБД
Зачем нужны базы данных? Данные, с которыми работают программы, не
существуют сами по себе: их нужно как-то хранить, уметь добавлять, извлекать,
читать, обновлять и удалять. Все эти действия было бы сложно проводить, если
базы данных не имели бы конкретной продуманной структуры. В этом уроке мы
изучим подробнее архитектуру баз данных, чтобы лучше представлять себе то,
с чем предстоит работать далее в курсе.
Сложность СУБД
Программы Postgresql, Mysql, Oracle, SQL Server являются СУБД — Системой
Управления Базами Данных. СУБД не то же самое, что и база данных
(БД). БД — это хранилище данных, у которых определенная внутренняя
структура. Но кто-то должен ее обслуживать: создать, обновлять, записывать в
нее данные, выбирать их. Именно этим и занимается СУБД — специальная
программа, которую необходимо установить на ту машину, где планируется
размещать базу данных.
Когда компьютеры только появились, задачу хранения данных каждый решал
по-своему. Самый простой способ хранить данные — положить их в файл. Но
тогда неизбежно встанут вопросы:

Как потом найти эти данные?

А если разные данные имеют разную структуру и разный размер?

А
что,
если
данные
понадобятся
нескольким
пользователям
одновременно?

А что, если во время обновления произойдет сбой?

А если данных станет настолько много, что они не поместятся в один
файл?
Именно из-за этих вопросов появилась разработка систем хранения — очень
сложная и затратная история. Инженеры довольно быстро поняли, что базами
данных должна заниматься специализированная программа, функционирующая
независимо от софта, который они разрабатывают.
СУБД — невероятно сложные программы, к которым предъявляются
практически максимальные требования по надежности, скорости работы и
эффективности. Неспроста считается, что если СУБД меньше 10 лет, то это
слишком молодой продукт для использования в серьезных приложениях.
Как устроены СУБД
СУБД реализуется как клиент-серверное приложение:

Сервером выступает сама СУБД — она управляет файлами баз данных,
принимает запросы от клиентов и выполняет их команды

Клиентом считается любое приложение, желающее взаимодействовать с
базой данных.
Клиентские приложения могут быть разнообразны по форме:

Текстовая утилита

Графическое приложение

Веб-сервер, использующий базу данных для отображения веб-страниц

Специализированный инструмент для обслуживания баз данных
Сервер в такой архитектуре спроектирован так, что он может работать с
большим количеством одновременных подключений от разных клиентов.
Подобная схема имеет большое значение в реальной жизни. Как правило, база
данных используется большим количеством пользователей одновременно.
Иногда сервер и клиент располагаются на одной машине. Это удобно во время
разработки:
Утилита psql с точки зрения СУБД является клиентом. Если СУБД не запущена,
то консоль не сможет запуститься:
psql
psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such file
or directory
Is the server running locally and accepting connections on that socket?
По умолчанию соединение происходит с той машиной, на которой запускается
REPL. Это поведение можно изменить, если задать соответствующие
параметры. Но пока этот вопрос мы не будем рассматривать подробно.
2.3. Погружение в различные подходы к построению хранилищ
данных
В эпоху цифровизации бизнеса, когда каждый клик и каждая транзакция
превращаются в данные, важность их архитектуры становится ключевой для
успеха компании. Современные архитектуры данных — это не просто
хранилища, это сложные системы, обеспечивающие быстрый доступ,
безопасность и возможность анализа огромных объемов информации.
Архитектура данных — это скелет любой информационной системы. Она
определяет, как данные собираются, хранятся, обрабатываются и передаются.
История архитектур данных начинается с простых файловых систем и доходит
до современных облачных и распределенных решений. Этот эволюционный
путь привел к появлению различных подходов к архитектуре хранилищ данных,
каждый из которых обладает своими уникальными особенностями и
преимуществами. Наиболее знаковыми в этом контексте являются классические
подходы, разработанные Уильямом Инмоном и Ральфом Кимбаллом.
Классические
типы:
Инмона
и
КимбаллаАрхитектура
Инмона
(3NF)
ориентирована на создание единого, интегрированного хранилища данных, в то
время как архитектура Кимбалла (звезда, dimensional modelling) фокусируется
на построении многомерных моделей для аналитики. Кроме того, важное место
занимает так называемый Modern stack, или архитектура больших данных,
предлагающая гибкие и масштабируемые решения.
модель Кимбалла для хранения данных
Хранилища данных могут включать несколько слоев, обычно до трех (staging
area, operational data store, детальный слой, презентационный слой), хотя в
некоторых случаях их может быть больше.
Например, могут присутствовать следующие слои: stg lake, lake, stg ods, ods,
stg dds, dds, stg cdm, cdm, а также специализированный слой для машинного
обучения. Это предоставляет широкие возможности для организации и
анализа данных в различных сценариях использования.
Примеры трехуровневой архитектуры данных
Лямбда и Каппа архитектуры
В контексте современных архитектур данных, Лямбда и Каппа архитектуры
выделяются своей спецификой. Они представляют собой подходы к построению
ETL (Extract, Transform, Load) pipelines, что является ключевым элементом в
обработке данных.
Лямбда-архитектура: Адаптация к динамике рынка
Лямбда-архитектура представляет собой service-based подход, способный
быстро адаптироваться к изменениям рынка и обеспечивать релевантность
предложений. Эта архитектура становится особенно актуальной, когда речь идет
о таких задачах, как рассылка персонализированных предложений о скидках, где
необходимо учитывать как исторические данные клиентов, так и их текущее
местоположение.
Компоненты Лямбда-архитектуры:
1. Пакетный уровень (Batch Layer) - "холодный путь": Здесь данные
хранятся в исходном виде и обрабатываются с задержкой. Этот уровень
содержит
"сырые"
данные,
включая
нормативно-справочную
информацию, изменяющуюся редко. Используя методы машинного
обучения, на пакетном уровне проводится анализ исторических данных
для сегментации клиентов и создания прогнозных моделей.
2. Скоростной уровень (Speed Layer) - "горячий путь": Этот уровень
обеспечивает анализ данных в реальном времени с минимальной
задержкой. Он использует фреймворки потоковой обработки данных,
такие как Apache Spark, Storm или Flink, для обработки информации с
коротким жизненным циклом. В этом слое делаются некоторые
компромиссы в точности в пользу скорости.
3. Сервисный уровень (Serving Layer): Сервисный уровень предоставляет
интерфейс для объединения данных из пакетного и скоростного уровней.
Он позволяет пользователям получить доступ к консолидированным,
актуализированным данным для аналитических целей.
Лямбда-архитектура представляет собой гибкий подход, позволяющий быстро
адаптироваться к изменениям и обеспечивать релевантность предложений, что
критично в условиях динамичного рыночного окружения.
Применение λ-архитектуры в практике Big Data
Лямбда-архитектура обеспечивает обработку больших объемов данных с
минимальной
задержкой,
выделяясь
своей
отказоустойчивостью
и
возможностью масштабирования. Это достигается за счет сочетания пакетной
обработки и скоростного анализа, позволяя интегрировать новые данные,
сохраняя при этом целостность и доступность исторической информации. Такие
качества делают лямбда-архитектуру востребованной в реальных Big Data
проектах, что подтверждается ее использованием ведущими компаниями,
такими как Twitter, Netflix и Yahoo.
Каппа-архитектура в Big Data: Упрощение и Эффективность
Каппа-архитектура представляет собой стройную модель обработки данных, где
все данные рассматриваются как последовательный поток событий. Эти
события систематически упорядочиваются в надежном журнале событий, где
каждое новое событие обновляет текущее состояние. В отличие от лямбдаархитектуры, Каппа исключает пакетный уровень обработки, сосредотачиваясь
на потоковой обработке в реальном времени и сохранении данных в виде
непрерывно обновляемого представления.
Каппа-архитектура упрощает проектирование систем Big Data, удаляя
необходимость в пакетной обработке и полагаясь на неизменяемый журнал
событий, который служит основой для всех операций. Этот подход позволяет
системам потоковых вычислений обрабатывать данные непосредственно из
журнала, при необходимости дополняя их информацией из вспомогательных
хранилищ.
Технологии, используемые в Каппа-архитектуре, включают:

Системы постоянного логирования событий, такие как Apache Kafka и
Amazon Kinesis.

Фреймворки для потоковых вычислений, включая Apache Spark и Flink.

Разнообразные базы данных на сервисном уровне, от резидентных до
специализированных решений для полнотекстового поиска.
Применение K-архитектуры и роль Apache Kafka
K-архитектура находит свое применение в сценариях, где:

Необходимо управление очередью событий и запросов в распределенной
файловой системе.

Порядок событий не фиксирован, и потоковые фреймворки могут
взаимодействовать с данными в любой момент.

Высокая доступность и устойчивость критичны, так как обработка данных
происходит на каждом узле системы.
Apache Kafka, как мощный брокер сообщений, поддерживает эти требования,
предоставляя быструю, надежную и масштабируемую платформу для сбора и
агрегации данных. Это делает Каппа-архитектуру на базе Kafka идеальной для
проектов, подобных LinkedIn, где необходимо обрабатывать и хранить большие
объемы данных для обслуживания множественных идентичных запросов.
Выводы
В этом уроке мы изучили архитектуру баз данных. Теперь мы лучше
представляем, с чем нам предстоит работать далее в курсе. Также мы узнали, что
БД и СУБД — это разные вещи. В первом случае речь идет о хранилище данных,
у которых определенная внутренняя структура. Но чтобы обслуживать ее,
применяют систему управления базами данных, которой и является СУБД. Она
реализуется как клиент-серверное приложение.
Список использованной литературы
1. Хомопепко А. Д., Цыганков В. М., Мальцев М. Г.
Базы данных: Учебник для высших учебных заведений / Под ред. А. Д.
Хомопепко. —6-еизд., доп. - СПб.:КОРОНА-Век,2009.
2. Шумский, А.А. Системный анализ в защите информации / А.А. Шумский. Москва, 2005.
3. Шустова Л.И. Тараканов О.В. Базы данных. Учебник/Инфра-М-электронное
издание
4. Доминик Microsoft ASP .NET. Обеспечение безопасности / Доминик Байер. М.: Питер, Русская Редакция, 2008.