Что такое архитектура данных и как её построить

Архитектура данных — это описание того, как в компании организована работа с данными. Функция архитектуры — систематизировать эту работу: создать базу данных, настроить процесс их сбора, определить условия хранения и правила обработки. Архитектура данных — это перечень документов, в нём собраны правила, методики, термины, ПО и даже список сотрудников, которые будут работать с базой данных.

Допустим, в компании решили запустить маркетплейс. Чтобы проект работал без сбоев, придётся собирать, хранить и обрабатывать большое количество данных: информацию о товарах, поставщиках, покупателях, заказах, доставках. Без архитектуры это будет сложно делать.

Архитектуру проектируют инженеры данных. Для этого специалист должен знать специфику работы компании, какие данные будут собирать и для каких целей они нужны. В зависимости от задачи инженер проектирует архитектуру баз данных: что, как, где и по каким правилам будет храниться и обрабатываться. Инженер редко получает готовое ТЗ и в основном самостоятельно собирает информацию, общаясь с заказчиком и коллегами.

Стратегия — это то, для чего создают архитектуру данных. Например, в компании собирают данные, чтобы улучшить качество клиентского сервиса или работу рекомендательных систем.

Архитектура данных рассчитывается на основе сферы деятельности. Архитектура для компании по разработке игр будет отличаться от архитектуры для интернет-магазина, а архитектура для интернет-магазина — от архитектуры для маркетплейса.

У бизнеса могут быть разные задачи, поэтому инженер данных проектирует архитектуру на основе диалога с заказчиком.

Правила и стандарты — это набор принципов работы с архитектурой данных, их ещё называют политикой. Эти принципы зависят от того, какой тип базы данных выбран для хранения — простейший, реляционный, NoSQL или комбинированный.

Нельзя сформировать архитектуру баз данных по готовому шаблону или скопировать у ближайшего конкурента. У каждого заказчика свой подход к работе и особенности, поэтому инженеру данных важно их выяснить до начала проектирования, чтобы потом не переделывать всю архитектуру.

Инженеру данных могут заказать архитектуру для хранения результатов медицинского исследования или для архивации документов. Студенты курса «Инженер данных с нуля» учатся проектировать разные типы архитектур данных на задачах реальных бизнесов. Во время обучения вместе с опытной командой они реализуют несколько проектов для разных сфер бизнеса.

Чтобы начать работу над архитектурой данных, инженеру данных нужно ответить на три вопроса:

— Как данные будут храниться?
В архитектуре баз данных описывают, как организовать потоки данных, и определяют подходящий тип базы и СУБД. Например, для интернет-магазина больше подойдёт реляционная база данных, а производителю товаров — документоориентированная БД для хранения неструктурированной информации типа описания товаров или инструкций по эксплуатации.

— Как данные будут упорядочиваться?
На этапе проектирования нужно выбрать методы и способы очистки данных и определить форму нормализации. Например, какие записи следует удалять из базы и как это делать — с помощью встроенных в хранилище инструментов, специально написанных скриптов или вручную.

— Как данные будут использоваться?
Чаще всего представители бизнеса, которые будут пользоваться данными, не владеют SQL или Python. Чтобы им не пришлось учиться писать запросы, нужно продумать графический интерфейс или дашборды, на которых будут визуализироваться нужные данные.

Чтобы ответить на эти вопросы, инженер данных общается с заказчиком архитектуры, аналитиками данных и бизнес-аналитиками, специалистами по Data Science.

При проектировании архитектуру данных описывают на трёх уровнях:
● внешний,
● концептуальный,
● внутренний.

Внешний уровень архитектуры данных ещё называют бизнес-уровнем. На нём продумывают, как архитектура будет помогать бизнесу работать с данными: как сотрудники заказчика будут видеть базу, ориентироваться в данных и принимать на их основе решения. Для разных отделов могут быть созданы разные графические интерфейсы, сценарии и методики. Допустим, отдел логистики отслеживает сроки доставки, количество товаров на складе, загруженность дорог в разное время в разных районах города, а отделу маркетинга нужны данные о трафике на сайт, количестве заявок и стоимости рекламных кампаний.

На этом уровне описывают модель базы данных, методики для анализа и прогнозирования, выбор которых зависит от бизнес-задач.

Наличие специалистов в компании — тоже одна из бизнес-составляющих, которую учитывают при проектировании архитектуры данных. Например, чтобы работать с данными, компании нужно нанять аналитика.

На концептуальном уровне описывают структуру базы данных: какие данные в ней хранят, их атрибуты и сущности, как данные обрабатывают и как они связаны между собой. Концептуальный уровень — это то, как видит базу данных её администратор.

На этом уровне также описывают:
● методики работы с архитектурой, например инструкции, схемы или перечень навыков, которым нужно обучить сотрудников компании;
● правила безопасности, например, кто из сотрудников получит доступ редактировать данные.

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