Путь в backend. Знакомимся с профессией архитектор данных
Мы поговорили с Александром Шульгиным об его опыте в IT и профессии архитектора баз данных. Из интервью вы узнаете о backend-разработке, работе с PostgreSQL и MySQL, инструментами вроде DBeaver, pgAdmin, Draw.io и ERwin, а также навыках SQL, Git и переходах в DevOps/SRE.
Расскажите о своём профессиональном пути и о том, как вы пришли в профессию архитектора баз данных.
Мой путь в IT начался с практической необходимости ещё на первом курсе по направлению «Разработка и сопровождение программных продуктов». Первым серьёзным вызовом стала курсовая работа, которая по сути была полноценным проектом. В то время не было такого доступа к готовым решениям и ИИ, как сейчас, поэтому всё приходилось изучать самостоятельно: читать литературу, сидеть на форумах, методом проб и ошибок проходить все этапы разработки. Этот опыт «выживания» и глубокая личная вовлечённость в создание продукта с нуля заложили основу моего понимания.
Осознанный интерес к данным появился на втором курсе — мне невероятно нравился предмет по работе с СУБД. Мне импонировала его скрупулёзность, целостность и логичность, хотя многим одногруппникам он казался монотонным. Позже, работая в командах над ПО и сайтами, я наблюдал, как качество данных и продуманность их структуры влияют на всё приложение. Но по-настоящему всё сложилось в голове, когда я взялся за свой проект сервис бронирования проживания для Вузов России. Там пришлось быть и разработчиком, и аналитиком, и, что ключевое, архитектором. Именно тогда я осознанно погрузился в проектирование сложной, но эффективной схемы БД, где каждое отношение и индекс были на своём месте для скорости и целостности. Этот опыт и стал точкой перехода от разработки к специализации на архитектуре данных.
Как вы обычно объясняете, кто такой архитектор баз данных, человеку без технического образования?
Архитектора баз данных проще всего представить как главного проектировщика хранилища данных в компании. Если проводить аналогию с библиотекой, то пока backend-разработчики строят само здание и настраивают процессы выдачи книг, архитектор думает о фундаментальных вещах: как расставить все стеллажи и каталоги, чтобы любую книгу можно было найти за секунду; как организовать работу, чтобы несколько человек одновременно могли вносить новые книги без путаницы; и как защитить ценную информацию от посторонних. Ключевая задача спроектировать систему хранения данных так, чтобы она работала быстро, без сбоев и была готова к росту, даже если информации станет в десятки раз больше. По сути, он создаёт структурированный и надёжный фундамент, на котором уже строятся все цифровые сервисы.
В каких задачах и ситуациях роль архитектора баз данных становится особенно важной?
Критически важна роль на старте любого нового продукта или при его кардинальном изменении. Как в моём проекте сервиса бронирования: неправильно выбранная структура данных на старте привела бы к невозможности масштабирования, потере скорости при росте пользователей и кошмару с целостностью информации (например, двойному бронированию). Также архитектор незаменим при оптимизации «унаследованных» систем, которые начинают «тормозить» и ломаться под нагрузкой, ведь часто проблема не в коде, а в фундаменте, в том, как организованы и запрашиваются данные.
Чем работа архитектора баз данных отличается от работы backend-разработчика или аналитика данных?
Это три разных специалиста, которые работают с данными на разных этапах. Backend-разработчик - это тот, кто создаёт сервисы, например, кнопку «Сохранить заказ». Он использует базу данных как готовый инструмент, чтобы положить туда информацию. Аналитик данных, наоборот, забирает информацию из этого хранилища: он анализирует, сколько заказов сделали и что популярно, и строит по этому отчёты. А архитектор баз данных - это проектировщик самого хранилища. Он решает, как эта база будет устроена внутри: как разложить данные, чтобы и «сохранить», и «проанализировать» можно было мгновенно, чтобы ничего не потерялось и система выдержала рост. То есть он создаёт надёжный фундамент, на котором уже работают и разработчик, и аналитик.
С какими типами баз данных вы работаете чаще всего и почему?
Мой основной опыт сосредоточен на реляционных базах данных, таких как PostgreSQL и MySQL. Они были и остаются рабочими лошадками для большинства бизнес-приложений, особенно там, где критически важна гарантированная целостность данных, транзакции (как в финансовых операциях или том же бронировании) и сложные связи между сущностями. С ними я работал и в команде, и в своих проектах. Да и как уже говорил, сам стек был выбран еще во время студенчества. При этом я стараюсь не останавливаться на достигнутом уровне. Как только чувствую, что освоил текущий инструмент достаточно глубоко, планомерно начинаю изучать что-то новое, ведь технологии не стоят на месте. Даже если в основной практике часто используются проверенные, «шаблонные» решения, понимание других подходов, расширяет кругозор и помогает подбирать оптимальный инструмент для каждой конкретной задачи.
Какие базовые знания необходимы человеку, который только задумывается о начале обучения этой профессии?
Для старта в профессии архитектора баз данных я бы посоветовал заложить чёткий фундамент: понять основы реляционной модели (таблицы, связи, ключи), освоить базовый SQL для выборки и соединения данных, научиться абстрактно мыслить, чтобы видеть сущности и их взаимосвязи в реальном мире. Не менее важно любопытство и привычка внимательно читать документацию, чтобы осознанно выбирать одну структуру хранения данных вместо другой. Наблюдая за обучением студентов, я часто замечаю, как им мешает излишняя торопливость и желание действовать быстро, не обдумывая шаги. В нашей работе это недопустимо, ведь ошибки, допущенные на этапе проектирования, болезненно проявляются на финише, при сдаче проекта, и заставляют переделывать всё с нуля. Поэтому я бы добавил сюда ещё два качества: скрупулёзность и методичность. В своё время мне тоже пришлось не раз начинать сначала, чтобы через ошибки прийти к пониманию, что аккуратность и продуманность на старте экономят огромное количество сил и времени в конце.
Насколько важно знание SQL на старте и на каком уровне его достаточно для начинающего?
SQL не просто язык, это способ мышления о данных. На старте это самый важный навык. Достаточный уровень для начала это уверенное владение основными операциями изменения данных, такими как выборка, вставка, обновление и удаление, с умением соединять таблицы разной сложности, понимание агрегации и простых подзапросов. Не нужно сразу лезть в оконные функции или сложную оптимизацию. И самое главное это не бояться брать простые проекты, чтобы набивать шишки и получать опыт уже в студенчестве на тестовых задачах.
Какие математические или логические навыки действительно нужны архитектору баз данных в повседневной работе?
Глубокая высшая математика требуется в этой работе нечасто. Самое важное здесь это развитое логическое и структурное мышление. Один мой школьный учитель часто говорил, что ключ к успеху в сложных задачах лежит не в запоминании формул, а в умении подвергать сомнению и анализировать каждый шаг, то есть в критическом мышлении, и в чётком планировании действий, то есть в алгоритмизации. Эти слова стали для меня руководством. На практике это означает умение разбивать сложную бизнес задачу, например такую как система бронирования столика со всеми условиями, на простые и связанные между собой сущности. Также критически важно понимание основ теории множеств, потому что работа с таблицами в базе данных это по сути операции с наборами строк. Всё это вместе и позволяет оценивать сложность и эффективность будущих решений.
Какие ошибки чаще всего совершают новички при изучении баз данных и архитектуры?
Часто новички пренебрегают теорией и сразу начинают писать код, не разобравшись в нормальных формах, что приводит к избыточным и аномальным данным. Другая проблема это непонимание основ, например разницы между первичными и уникальными ключами, выбор неправильных типов данных из-за торопливости и поверхностного анализа задачи. Вредной привычкой является и преждевременная оптимизация, когда начинают искусственно дробить таблицы или добавлять индексы до того, как станут понятны реальные нагрузки и паттерны запросов. Опасным заблуждением становится игнорирование целостности данных, когда надеются контролировать её только на уровне приложения, вместо использования встроенных механизмов базы данных, таких как внешние ключи и ограничения. И наконец, слепое следование трендам, например попытка использовать базы данных другого типа для строго структурированной информации только потому, что это модно, часто создаёт больше проблем, чем решает.
Какие инструменты или технологии вы бы рекомендовали изучать в первую очередь начинающему специалисту?
Основной набор инструментов для старта довольно стандартен, но я могу поделиться тем, с чего начинал лично я. Для базы данных я бы рекомендовал взять одну из популярных реляционных СУБД, например, мощный и открытый PostgreSQL или более простой для первых шагов MySQL. Чтобы проектировать структуру визуально до написания кода, пригодятся инструменты для моделирования, такие как Draw.io или ли ERwin — чтобы визуализировать схему до написания кода. Для выполнения запросов и администрирования удобно использовать графические среды вроде DBeaver или pgAdmin. Обязательно нужно освоить систему контроля версий Git, ведь под версионный контроль берутся не только файлы приложения, но и все скрипты для изменения структуры базы. И конечно, основы командной строки для базовых операций с сервером и СУБД будут очень полезны уже на старте.
Как обычно выглядит рабочий процесс архитектора баз данных на проекте?
Рабочий процесс начинается с анализа бизнес-требований для выявления необходимых данных и их взаимосвязей. Следующий этап – это проектирование концептуальной и логической модели данных, которая затем обсуждается с разработчиками. После утверждения модель переносится в физическую реализацию: определяются типы данных, индексы и стратегии хранения, пишутся скрипты для развёртывания структуры. Финальная стадия включает непосредственное создание базы данных, организацию миграции существующей информации и сопровождение команды в процессе запуска системы.
С какими специалистами архитектор баз данных взаимодействует чаще всего и в каком формате?
В работе взаимодействие происходит с несколькими командами. Наиболее тесное и постоянное сотрудничество идет с backend разработчиками, оно включает совместное ревью запросов, обсуждение интерфейсов для работы с данными и планирование изменений схемы базы. В начале проекта ключевыми партнерами становятся бизнес аналитики и продакт менеджеры, с которыми ведутся интервью и рабочие сессии для сбора и уточнения требований к данным. Поскольку значительная часть проектов связана с интеграцией в инфраструктуру образовательных учреждений, важную роль играет взаимодействие с их IT отделами. Для обеспечения надежности системы также необходимо сотрудничество с DevOps и SRE инженерами, чтобы грамотно настроить репликацию, резервное копирование и отказоустойчивость базы данных.
Какие софт-навыки оказываются важными для успешной работы в этой профессии?
Коммуникация, чтобы объяснять бизнесу технические нюансы и понимать их задачи, а также системное мышление, чтобы видеть всю картину проекта. Нужно уметь работать с нечёткими требованиями, предлагая гибкие решения, и быть проактивным, чтобы отслеживать производительность системы на растущих данных. Мне очень помог собственный опыт самостоятельного поиска ответов, который развил любознательность и привычку мысленно визуализировать каждый процесс, что в шутку можно назвать здоровой дотошностью.
Как вы считаете, сколько времени в среднем нужно, чтобы освоить базовый уровень и начать двигаться в профессии?
Если у человека уже есть технический бэкграунд, как это было у меня с опытом разработки, то на то, чтобы сформировать фундаментальное понимание баз данных и уверенно освоить SQL, обычно уходит от трёх до шести месяцев активного обучения и практики на собственных небольших проектах. Чтобы вырасти до уровня начинающего специалиста, который уже может работать в команде под руководством, потребуется около года. Главный секрет не в простом изучении теории, а в её обязательном применении на реальных, пусть даже и учебных, задачах.
Интересно, что многие слышали про базы данных, но не все понимают, как они устроены внутри, а здесь как раз есть уникальная возможность разобраться в этом механизме. По моим наблюдениям за студентами, при грамотной практике и наглядных разборах конкретных кейсов они осваивают этот материал заметно быстрее, чем многие другие технологии в программировании, с гораздо большим вовлечением и интересом.
Что бы вы посоветовали человеку, который только рассматривает профессию архитектора баз данных и сомневается, стоит ли начинать?
Мой путь начался с вынужденной задачи, но продолжился благодаря искреннему интересу к этому порядку. Возьми любой свой проект, даже маленький, и попробуй спроектировать для него базу данных. Если тебя затянет процесс превращения хаоса в чёткую структуру, если ты почувствуешь, как всё встаёт на свои места, значит, это оно. Если нет, ты хотя бы исключишь один вариант и станешь на шаг ближе к своему делу. Не узнать, не попробовав.
Если у вас остались вопросы к Александру, вы можете задать их лично — https://t.me/alexshulgin7