Рынок вакансий для системных аналитиков меняется. Растет спрос н�� работу с данными, облачные технологии и инструменты ETL/ELT. Бизнесу нужны специалисты, которые понимают архитектуру хранения данных, знают процессы их преобразования и принципы управления. Но требования в таких вакансиях часто пугают — со стороны это выглядит как другой мир, требующий совершенно новых знаний.

На своем примере перехода из финтеха в data-платформу VK Tech покажу, что все не так страшно. Расскажу, что в профессии системного аналитика остается неизменным, какие есть ключевые концепции и инструменты Data-направления и что на самом деле нужно знать для перехода.

Почему я решилась на смену области

Как и многие системные аналитики, я столкнулась с тем, что задачи перестали быть вызовом, а работа стала предсказуемой. Хотелось большего: решать комплексные архитектурные проблемы, а не описывать функциональность очередного модуля.

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

Ядро системного аналитика

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

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

Второй важный блок — аналитическое мышление: умение разбирать запутанные процессы на понятные шаги, даже если предметная область для вас новая. 

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

И, наконец, четвертый — привычка к структурированию любой задачи: от разговора с бизнесом до описания интеграций. Когда аналитик приходит в data-проекты — миграцию DWH, внедрение системы управления метаданными или создание платформы с нуля, — ему по‑прежнему нужно ответить на те же три вопроса: что есть сейчас (AS‑IS), к чему мы хотим прийти (TO‑BE) и какой разрыв между текущим и целевым состоянием (GAP), который предстоит закрыть.

Кое-что про дата-платформу

Прежде чем переходить к практическому примеру, полезно договориться о терминах и на одном конкретном продукте разобрать, что вообще понимается под дата-платформой и зачем она бизнесу. В качестве ориентира возьмем VK Data Platform — это платформа для сквозной работы с большими объемами данных и задачами машинного обучения.

Ее основные компоненты:

• Каталог данных. Система управления метаданными для каталогизации, описания и поиска данных.

• Хранилище данных. Центральное место для хранения структурированных или неструктурированных данных и управления ими.

• Системы получения и обработки данных. Инструменты и процессы для сбора, интеграции и первичной обработки данных из различных источников.

• Оркестрация и трансформация данных. Инструменты для автоматизации потоков данных и управления ими, включая их очистку, преобразование, агрегацию и маршрутизацию между системами.

• Инструменты для анализа, построения отчетов, визуализации данных и создания моделей машинного обучения.

• Методологии управления данными. Стандарты, процессы и практики, обеспечивающие качество, безопасность, соответствие требованиям и эффективное использование данных.

Зачем бизнесу вся эта конструкция? Чтобы меньше спорить о том, «какие цифры правильные», не плодить разрозненные локальные решения, понимать, откуда берутся показатели в отчетах, и не тратить лишнее время на добычу данных. Хорошо выстроенная платформа делает доступ к данным предсказуемым и безопасным и позволяет принимать решения на основе актуальной информации, а не интуиции.

Подробнее про VK Data Platform можно узнать на странице продукта.

Когда общее устройство становится понятным, можно спускаться на уровень конкретной задачи. Допустим, заказчик приходит с запросом на систему управления метаданными, каталог данных. При этом он подчеркивает, что речь не про очередное хранилище, а именно про управление — описания, связи, ответственность, поиск.

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

Ответы на эти вопросы задают рамки проекта, помогают определить архитектурные решения и порядок внедрения. А вашей опорой здесь станут не какие-то таинственные знания из data-мира, а то самое профессиональное ядро: умение вытащить суть из разрозненных вводных, структурировать область и разложить путь от текущего состояния к целевому.

Ключевые концепции и инструменты data-направления

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

Архитектуры хранения: откуда берутся данные и куда они попадают

Начнем с того, как вообще устроено хранение. Есть несколько основных подходов, и у каждого своя логика.

Data Warehouse (DWH) — это хранилище с жесткими правилами. Данные туда попадают уже очищенными, приведенными к единой структуре и связанными между собой. Из такого хранилища строятся отчеты, дашборды, витрины для бизнес-аналитиков. Здесь важна предсказуемость: пользователь знает, где лежит нужная таблица, какие в ней поля и откуда они взялись.

Что с этим делать аналитику? Разбираться, какие метрики и справочники должны там оказаться, как бизнес будет ими пользоваться, какие связи между сущностями критичны. По сути, проектировать структуру так, чтобы она отвечала на реальные вопросы, а не просто красиво выглядела на схеме.

Data Lake — противоположность: сюда сваливается все подряд в том виде, в каком пришло. Логи, сырые файлы, видео, документы, выгрузки из систем. Никакой предварительной обработки. Идея в том, что когда-нибудь потом кто-то разберется, что с этим делать, и достанет нужное.

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

Часто используется комплексная архитектура — Data Lake + Data Warehouse. В ней структурированные, полуструктурированные и неструктурированные данные поступают через ELT/Streaming в объектное хранилище. Затем данные через ETL загружаются в МРР БД (массивно-параллельная база данных). А сверху работают BI, отчеты и машинное обучение/ИИ.

Преимущества такого метода:

• Все плюсы Data Warehouse на базе МРР БД.

• Возможность работать не только со структурированными данными.

• Доступность сырых данных для ML.

Недостатки:

• Дублирование данных и логики.

• Излишнее перемещение и раскрытие данных.

• Сложные технологии и реализация.

• Сложность комбинирования технологий.

Data Lakehouse — другая попытка взять лучшее из обоих миров. С одной стороны, гибкость озера: можно хранить данные в любом формате. С другой — управляемость хранилища: структура, версионирование, контроль качества. Это компромисс, когда компания хочет и накапливать сырье, и работать с ним как с чем-то осмысленным.

В Data Lakehouse структурированные, полуструктурированные и неструктурированные данные через ELT/ETL/Streaming попадают в объектное хранилище. Единый SQL-движок Data Lakehouse обеспечивает доступ к данным. А сверху работают BI, отчеты и машинное обучение, ИИ.

Преимущества:

• Любые форматы данных.

• Гибкость подключения источников.

• Удобство подключения потребителей: и BI, и ML.

• SQL и поддержка разных топологий построения хранилищ данных.

• Минимум дублирования, управляемые ETL/ELT-процессы.

• Ясные структура и происхождение данных.

• Низкий порог входа для инженеров и аналитиков.

• Раздельное масштабирование хранения и обработки.

Задача аналитика здесь — понимать, какие бизнес-сценарии требуют быстрого доступа к готовым данным, а какие глубокого анализа «сырья».

Системному аналитику не обязательно разбираться в технических деталях реализации этих архитектур. Важнее понимать, для каких задач они нужны:

• Какие процессы требуют готовых, структурированных данных?

• Какие сценарии нуждаются в анализе «сырой» информации?

• Где необходима гибкость хранения данных в любом формате?

Это позволит правильно формулировать требования и не предлагать решения наугад.

Процессы обработки данных (ETL/ELT)

Любая модель данных бесполезна, если информация в ней устаревшая, «грязная» или неполная. Поэтому нужны процессы, которые регулярно забирают данные из источников, приводят их в порядок и доставляют туда, где с ними будут работать. Это называется ETL или ELT — в зависимости от того, на каком этапе происходит обработка.

ETL (Extract, Transform, Load) — это когда данные сначала извлекаются из источника, потом трансформируются (очищаются, обогащаются, приводятся к нужному формату), а затем загружаются в хранилище. ELT — обратный порядок: сначала загрузка в сыром виде, а преобразования происходят уже внутри целевой системы. Выбор между ними зависит от того, где удобнее и быстрее обрабатывать данные.

Инструменты вроде Airflow или Apache NiFi играют роль диспетчеров. Они управляют цепочками задач: когда запустить выгрузку, в каком порядке выполнить преобразования, куда положить результат, что делать при ошибке. Это автоматизация того, что раньше делали вручную или через разрозненные скрипты.

Что с этим делать аналитику? Прежде всего — понимать путь данных. Откуда они пришли, через какие этапы прошли, где оказались в итоге. Это базовое знание, без которого невозможно разобраться, почему в отчете вдруг появились странные цифры или почему витрина не обновилась вовремя.

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

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

Аналитику не нужно становиться инженером данных и разбираться во всех технических деталях Airflow или других инструментов. Но важно понимать логику их работы и уметь читать диаграммы потоков данных. Именно они показывают, как устроены цепочки обработки, где какие зависимости, что от чего зависит. Это язык, на котором можно обсуждать требования с техническими командами, не теряясь в деталях реализации.

Data Governance и качество

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

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

Например, если речь о данных клиентов: что делать с записями, где не указан email? Отбрасывать, помечать как неполные или все равно загружать? Что считать корректным ИНН — только 12 цифр или допустимы другие форматы? Может ли дата рождения быть в будущем? Без явных договоренностей каждая команда решает эти вопросы по-своему, и данные начинают противоречить друг другу.

Метаданные. Это описания данных объясняют, что означает каждый показатель, откуда он взялся, кто за него отвечает, в каком формате хранится. Бизнес-глоссарий помогает разным командам говорить на одном языке.

Возьмем поле «Счет» в таблице клиентов. Кто-то может подумать, что это номер договора, кто-то — что это внутренний идентификатор системы. Если зафиксировать, что это уникальный идентификатор формата из 20 цифр, владелец данных — отдел обслуживания клиентов, и добавить пример значения, путаницы станет меньше.

Происхождение данных (Data Lineage). Нужно понимать полный путь данных от источника до конечного отчета. Это важно для аудита, для соответствия требованиям и для быстрого поиска проблем.

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

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

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

Автоматические DQ-проверки качества. Помимо описания правил, нужно участвовать в их внедрении. Это проверки на дубликаты, допустимость значений, соблюдение целостности данных. 

Например, системный аналитик участвует в настройке автоматических проверок качества данных (DQ-проверок) в ETL-процессах: настраивает проверку на отсутствие дубликатов по паспортным данным при загрузке новых клиентов или проверяет, чтобы сумма транзакции не была отрицательной.

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

Слой моделирования: проектирование структур данных

Работа с данными немыслима без модели данных — способа организовать информацию внутри хранилища так, чтобы с ней было удобно и быстро работать, а связи оставались непротиворечивыми. Для системного аналитика это зона ответственности: продумать, как устроены сущности, какие у них атрибуты и как они связаны, а затем зафиксировать это в понятном виде, схемами или текстом. Здесь в ход идут ER-диаграммы, описания объектов и их отношений.

Модель данных — это язык, на котором ведется разговор между бизнесом и разработчик��ми. Когда вы показываете схему, всем проще договориться, что такое «клиент», «счет», «продукт», какие бывают статусы и как одно связано с другим. На этом этапе удобно ловить противоречия: дублирующиеся сущности, лишние связи, неочевидные циклы. Лучше увидеть их на диаграмме, чем в проде.

Отдельная история — связь моделей данных с каталогом данных. Каталог хранит метаинформацию: описания таблиц, полей, связей, владельцев. На автоматическом импорте все не заканчивается: ошибки на этом шаге дают неполную или искаженную картину происхождения данных (Data Lineage). Аналитику важно уметь разобраться, что пошло не так: проблема в самом каталоге или в том, как была описана и загружена модель. Иногда это требует ручной правки — может понадобиться добавить недостающую связь, скорректировать направление, уточнить тип отношения.

От человека, переходящего в data-направление, ждут не глубокой теории, а понимания базовых вещей: что такое модель данных, какие бывают уровни моделирования, чем различаются логическая и физическая модель, какие форматы описания используются в команде. Со временем к этому добавляется знание методологий вроде Кимбалла или Data Vault.Тогда аналитик может сам спроектировать хранение так, чтобы оно выдерживало изменения и не ломалось от новых требований.

Важные компетенции системного аналитика в data-направлении

Работа с данными требует не только знания инструментов и архитектур, но и нескольких базовых умений.

Привычка мыслить данными. Когда бизнес формулирует общий запрос в духе «нужна аналитика продаж», аналитик сразу уточняет детали: какие именно показатели интересуют, за какой период, по каким срезам, с чем нужно сравнить. Требование разбивается на конкретные метрики, перечень источников и связи между ними. Так из расплывчатой формулировки получается набор гипотез, которые можно проверить на данных.

SQL. Аналитику в data-проектах приходится писать запросы самому, и речь не о простых SELECT. Join'ы на несколько таблиц, подзапросы, агрегации, оконные функции — все это нужно для ежедневной работы. Иначе не получится проверить качество данных, поймать аномалии или убедиться, что трансформация отработала как надо. SQL становится не просто навыком, который был бы полезен, а обязательной компетенцией.

Умение работать с метриками. Бизнес редко формулирует запросы точно, скорее всего вам просто скажут «хотим видеть эффективность кампании». Аналитик должен выяснить, что конкретно имеется в виду. Эффективность — это конверсия, ROI, количество лидов или средний чек? Как измерять, с чем сравнивать, откуда брать данные? Чем детальнее удается разложить абстрактное требование на конкретные показатели, тем меньше вероятность, что на выходе окажется совсем не то, чего хотели.

Что почитать для погружения

Коллектив авторов, «DAMA-DMBOK. Свод знаний по управлению данными». Разработан Международной ассоциацией управления данными.

Соня Миццета, Principles of Data Fabric. Для понимания, что такое Data Fabric, какие принципы лежат в ее основе и как она помогает организациям строить гибкие, самообучающиеся и масштабируемые системы управления данными.

Джеймс Серра, Deciphering Data Architectures. Для понимания, как проектировать современные архитектуры данных для различных бизнес-задач. Книга объясняет основные паттерны, компоненты и принципы построения эффективных и масштабируемых дата-платформ, а также сравнивает разные подходы (Data Lake, DataWarehouse, Data Fabric и др.).

Уилл Гиртен, Building Modern Data Applications Using Databricks Lakehouse. Для понимания, как создаются современные приложения на базе архитектуры Lakehouse с помощью Databricks. В книге описывается, как объединить лучшие черты Data Lake и Data Warehouse, как строить масштабируемые аналитические решения, использовать облачные платформы и интегрировать разные источники данных для бизнеса.

Акцент для собеседования

Если вы переходите в область работы с данными, следует пересмотреть свое резюме. Здорово, если у вас есть опыт проработки сложных UI-сценариев, но для data-вакансии релевантнее говорить о том, как вы работали с ETL-процессами, интегрировали данные из разных источников или участвовали в проектах, связанных с построением DWH. Делайте упор на этом.

Меняет ли data-направление суть профессии системного аналитика

Это, пожалуй, главный вопрос, который возникает у системного аналитика, задумывающегося о переходе в data-направление. Здесь есть два лагеря мнений:

• Одни считают, что глубина погружения в технологии (DWH, ETL) и методологии (Data Governance) настолько велика, что это кардинально меняет содержание работы, приближая ее к роли data-инженера или архитектора.

• Другие уверены: системный аналитик был и оста��тся системным аналитиком. Меняется контекст, но не суть — выявить потребность, формализовать ее и убедиться, что результат решает проблему.

Лично я придерживаюсь второго мнения. Системный аналитик как был, так и остается связующим звеном между бизнесом и разработкой. Его ключевая задача — прояснять, структурировать и делать возможным реализацию требований. И она остается неизменной.

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

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

Заключение

Системный аналитик остается системным аналитиком. Но рынок не стоит на месте: появляются новые направления, такие как Data, а с ними — новые инструменты и подходы. Это не отменяет наши базовые навыки, то самое ядро. Системному аналитику требуется прокачивать специфические навыки.

Важно помнить несколько ключевых моментов:

• Не существует универсального рецепта или единого набора компетенций, который подошел бы всем. Каждая компания, каждое направление и даже каждая команда внутри одного проекта обладают своей уникальной спецификой. 

• Требования к системному аналитику в data-направлении варьируются от проекта к проекту и от компании к компании. Уровень погружения в инструменты и глубина владения технологиями будут разными от проекта к проекту. 

• Гибкость и способность к погружению — ваш главный навык.

Ключ к успешному переходу — это уверенность в своих универсальных компетенциях и готовность быстро и глубоко погружаться в новую предметную область. Если вы хотите сменить предметную область и понимаете, какие именно навыки требуются в Data, и знаете, как адаптировать под них свой опыт, — ваша ценность на рынке труда будет только расти.

Подписывайтесь на мой телеграм-канал, а также жду ваших вопросов в комментариях.