Привет, Хабр! Меня зовут Азат Якупов, я работаю Data Architect в Quadcode. Сегодня хочу рассказать о Data-специалистах и познакомить вас с нашей командой Data Platform. 

Какие Data-специалисты бывают

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

• Data Engineer,

• Data Analyst,

• Data Scientist,

• Data Architect,

• Data Solution Architect,

• Data Integration Manager,

• Big Data Engineer,

• Data Manager,

• Data Platform Team Lead,

• Data Officer,

• Data Steward.

Также у специалистов могут быть разные уровни: Junior / Middle / Senior. Что общего у этих ролей? Правильно — Data. Это слово указывает на принадлежность инженеров к отдельному «клубу» специалистов.

Примерно 20-25 лет назад специалистов, работающих с базами данных, называли просто DBA (Database Administrator). DBA совмещал сразу несколько ролей, он:  

• был разработчиком функционального кода в базе данных (Database Developer);

• занимался проектированием моделей данных (Database Modeler);

• оптимизировал SQL-запросы и работу СУБД в целом (Performance Tuning Engineer); 

• поддерживал репликации между вовлечёнными узлами топологии базы данных (Database Administrator);

• обслуживал кластера баз данных (Database Administrator);

• следил за индексами / табличными пространствами / статистикой / Data-файлами (Database Administrator); 

• собирал требования для новых фич проекта (Data Analyst);

• и наконец — писал сами SQL-запросы любой сложности (SQL Developer).

Словом, был таким «единорогом», который умеет всё. Затем на помощь реляционным пришли нереляционные базы данных, появилось понятие Big Data, всё усложнилось по ролям инженеров :-) 

Проще всего объяснять на примерах, поэтому расскажу, какие Data-специалисты и команды есть у нас в Quadcode.

Data-команды и специалисты в Quadcode

У нас есть команда Data Platform — отдельная группа инженеров. Роли в команде разные, но каждая дополняет другую так, чтобы мы могли выполнять любые задачи, связанные с данными.

Команда Data Platform обеспечивает функционирование нашего LakeHouse, который схематично нарисован ниже:

Команда состоит из 4 больших стеков:

1. Data Quality — специалисты, проверяющие качество данных, эта роль у нас в компании находится на границе между Data Engineering / Data Science (Data Mining) / Data Analytics. Это инженеры, у которых, с одной стороны, есть теоретические знания: что такое базы данных, запросы к данным, подходы к аналитике, к статистике данных, к паттерну MapReduce.

А с другой стороны — практические навыки. Например, они проводят автоматическое и ручное тестирование по проверке качества данных, делая кросс-проверки между источником и хранилищем холодного слоя в LakeHouse с использованием случайных выборок (data samples) и вероятностных структур семейства Bloom Filters. Покрытие тестами наших данных — уже жизненная необходимость, это нужно, чтобы, например, один из ежемесячных отчётов в регуляторные организации сводился к приемлемым числам и соответствовал требованиям.

Пример практической задачи: сравнить две таблицы. Одна находится в источнике  (например, в микросервисе digital-опционов), а вторая — у нас в вертикальной базе данных (например, в Greenplum), которая расположена в логическом слое Operational Data Store. Нужно сравнивать данные в двух этих таблицах практически непрерывно, чтобы не было потери высококритичной информации. Это особенно важно, если работаете в финтехе: потеря одной транзакции может вылиться в большие финансовые (а также репутационные) потери.

В случае несоответствия данных Data Quality Engineers находят причину и готовят план восстановления утерянного смысла данных (это может быть как физическая потеря данных, так и несогласованное изменение логики на стороне команды микросервиса). При необходимости привлекают к этой работе Data-специалистов, таких как Data Stewards, Data Owners, Data Engineers.

Но качество данных — это не только сравнение построчно (один в один). Иногда эта операция обходится слишком дорого из-за количества источников, объемов самих данных и периодических миграций моделей данных. Как одно из возможных решений — использование метрик по качеству в доверительном интервале, основанных на правилах «6 сигм» (Six Sigma Rules).

И затем привлечение всей необходимой математики для анализа Confidence Interval и false-positive срабатываний.

2. Data Engineers и Big Data Engineers — это специалисты команды Data Platform, которые работают с конкретными физическими движками баз данных, ETL-процессами (с учетом процесса Back-Filling), очередями сообщений, процессами по нормализации, трансформации, стандартизации, гармонизации, обфускации данных. Слово Big подразумевает, что у инженера есть глубокий практический опыт работы в экосистемах формата Hadoop. 

Вот один из примеров Data Pipeline, который «приводит» данные из источника в одно из хранилищ Operational Data Store слоя: 

Вроде на рисунке всё логично и понятно. Но, например, одна из задач дата-инженерии — мутация / миграция / изменения схемы на источнике достаточно интересна. Уверен, все знают термин Schema Registry. Но возникает масса нюансов: как это организовать так, чтобы минимизировать человеческий фактор, быть проактивными, и LakeHouse функционировал в максимально автоматическом режиме (перестраивая необходимые трансформации данных на всех вовлечённых логических слоях автоматически). Скажу честно, мы на пути к такой автоматизации, уже есть план действий. В случае Schema Registry мы выбрали одновременно push- и pull-подходы, используя Kafka Confluent и метапауков (meta-crawlers), которые организованы в отдельном логическом слое MDM.

В отдельной статье на Хабре я планирую рассказать о технической реализации слоя MDM и его роли в нашем LakeHouse.

3. Data Architect — человек, который занимается проектированием каждого из логических слоев, пониманием текущей архитектуры и накопившейся истории по процессам. При этом Datа Architect немного программирует, делает MVP задач, изучает текущие решения на рынке, общается с командами и специалистами, может проводить обучение (у нас в Quadcode так). Цель его работы — максимально структурировать потоки данных в компании и стандартизировать подходы для построения (или изменения) модели данных, чтобы она удовлетворяла внутренним правилам и регламентам. Задача очень важная, особенно с учётом нашего пути к Data Governance (логических правил и процессов с данными) и Data Management (физических правил работы моделей на уровне микросервисов). Вот, например, одна из задач: создание компонентов Data Lineage и Data Catalogue, они используются для таких задач, как определение «родословной» набора данных, которая вовлечена в процесс по пересбору данных / автоматической перестройки моделей / приоритезации процесса восстановления данных / предоставлению формул перехода для атрибутов одной материализации к другой.

Ниже пример маппинга между атрибутами материализаций и формулами, который у нас уже есть.

Но вот другая сторона работы Data Architect — это роль Service Owner, которая подразумевает создание процессов работы с данными, привлечение необходимых инженеров и многое другое.

4. Database Administrator — инженер, который знает базы данных изнутри, подбирает правильные параметры хранения данных, физические диски, подсказывает, какой индекс лучше выбрать (возможно, индекс и вовсе не нужен), смотрит за распределением данных в узлах топологии, следит за метриками, мониторит базы данных, мигрирует legacy монолитные таблицы в партицированные и/или субпартицированные, оптимизирует запросы, интегрирует данные с холодным слоем данных и решает многие другие задачи. Вот пример части архитектуры, в рамках которой DBA-инженеры делают свою работу:

Для работы с OLAP-запросами мы в основном используем Greenplum (это часть ODS и DDS логических слоев), но также у нас есть инстансы PostgreSQL, ClickHouse, Hive. 

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

Data Analytics занимаются аналитикой, проводят различные эксперименты с данными, проверяют гипотезы и так далее. 

Команда Data Science занимается алгоритмами, изучением данных, поиском взаимосвязей, экспериментами, смотрит на результаты А/B-тестирования. Например, одна из задач — исследование аномалий / выбросов данных при выводе денежных средств (Outlier Detection).

У сотрудников Quadcode есть профили должности — документы, в которых зафиксированы цель, задачи, навыки, обязанности, hard- и soft-скиллы, управленческие и корпоративные компетенции для каждой конкретной роли. Вот, например, часть информации из профилей Data Engineer и Database Administrator. Прочитайте, эта информация поможет понять, что могут ждать работодатели от сотрудников на этих позициях.

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

Например, команда биллинга: у неё свои базы данных, администраторы и разработчики баз данных. Они работают с OLTP-трафиком (Online Transaction Processing). Это означает, что трафик очень быстрый (пришёл-ушёл). Он приходит в базу данных в формате «Дай мне данные за такой-то период», «Обнови эту котировку» или «Добавь заявку от клиента по digital-опционам» и так далее. OLTP-трафик характеризуется большим TPS и небольшим значением метрики latency. Чем быстрее — тем больше клиентов, больше клиентов — выше лояльность, выше лояльность — больше прибыли. Всё очень взаимосвязано. 

Data-команды и специалисты: как строится работа

Есть такой подход к работе с данными — Data Mesh. Смысл в том, что за данные отвечает не только одна команда Data Platform, а все команды, которые поставляют данные. Цель — работать с данными как с ценностью. Например: команда биллинга отправляет данные Data Platform и ответственна за их корректность. Следуя подходу Data Mesh: команды, вовлечённые в микросервисную архитектуру, должны отвечать за данные как за продукт, как за ценность. Не просто: «Я отдал данные Data-команде, на этом всё», а: «Я несу ответственность за данные, которые предоставляю, за то, в каком виде эти данные в итоге поступят конечному потребителю».На первый взгляд может показаться, что разработчиков «бросают в пекло», а Data-команды никак не помогают и ни за что не отвечают, но это не так. У нас есть множество концепций, регламентов и так далее, которые помогают выстроить процесс. Приведу несколько примеров. 

Концепция «Поездов». Не буду углубляться в фреймворк SAFe, объясню буквально на пальцах. Чтобы избежать хаоса, все команды, вовлечённые в данные, должны работать слаженно и помнить про общую ценность. Для решения этой задачи появляется множество концепций, фреймворков и инструментов. Один из них — «поезда». Суть: представители разных команд перемешиваются и составляют некую отдельную сущность (поезд). У каждого поезда есть все необходимые специалисты (архитекторы, разработчики, аналитики и так далее) и Product Owner. Это позволяет команде работать быстрее и уменьшить количество блокеров. То есть (возвращаясь к теме статьи) в каждой команде, которая работает с данными, появляются специалисты, которые могут написать запрос к базе данных в правильном формате. 

Data Governance. Это политика управления данными внутри компании: с выстраиванием корректных паттернов, с правильными документами, регуляторными принципами и сервисами. И главная цель всего этого — помочь разработчикам работать с данными и доносить их ценность. При этом команда Data Platform остается в качестве проверяющей и может либо отклонить запрос Merge Request, либо помочь разработчикам подготовить его. Но не делать это за них: это приведёт к хаосу, те же «поезда» замедлятся.

Регулятивная функция Data Governance заключается в том, что у всех команд есть нормативные документы в виде сценариев, которые говорят, что и как делать: возьми бизнес-ценность → пойми её суть → оформи её в SQL-запрос → подай заявку → защити свою заявку → выкатывай в прод.

Data Management. Это процесс управления данными. Максимально конкретный, например: когда берёшь SQL-запрос, используй, пожалуйста, такие-то ключевые слова, а такие-то не используй. Главная цель — разработать документы и инструменты, которые помогут разработчикам не просто отдавать корректные данные, а транслировать ценность. Ведь в конечном итоге нужно отдать Data-команде не просто данные, а готовую информацию, из которой они могут получить знания или мудрость. Пирамида данных такая:

• Данные — это основа, фундамент. 

• Информация — это очищенные данные, которые можно проанализировать.

• Знания: как поступать на основе алгоритмов Data Science, каким образом предугадывать тренды, предотвращать аномалии и ошибки.

• Мудрость — это уже не просто аналитика, это некая стратегия принятия решения.

Мы в Quadcode придерживаемся data-driven подхода. Это означает, что у нас не просто поток неуправляемых данных, которые «носятся» от одного микросервиса к другому. Мы можем в любой момент преобразовать, структурировать, обогатить данные. Это и есть data-driven подход — когда мы управляем данными не хаотично, а с пониманием того, что это за данные, откуда они к нам пришли, кто за них ответственный, какое у них качество, кто конечный потребитель, какую ценность они нам несут. 

Какой вывод можем сделать из всего этого? Всё зависит от процессов и регламентов, которые выставляет Data Platform. Ведь она — финальная точка принятия решения о том, что мы выкатываем что-то в прод. Все подходы и регламенты, которые я описал выше, призваны помочь разработчиками и Data-командам. Стоит помнить и про профит для самих разработчиков: они прокачивают технические скиллы (изучают Data Engineering) и больше погружаются в рабочий процесс: понимают, какую ценность несут их фичи. 

Подводя итог

Несмотря на то, что в компаниях есть разные Data-роли, они всё равно тесно переплетаются: скажем, Data Engineer нужны навыки Data Analyst — чтобы самостоятельно понять, например, что данные от какой-то команды некорректные, нужно их скорректировать. 

Конечно, на рынке есть и «единороги» — специалисты, которые умеют всё и сразу. Они бывают незаменимы в стартапах и компаниях, где на первое место выходит скорость поставки. Сам я больше за разделение, хотя в профессию пришёл именно в то время, когда всё выполнял один человек (DBA). Есть несколько причин, почему я думаю именно так: 

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

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

• Специалисты больше вовлечены в конкретные процессы и больше понимают ценность своей работы. 

Если вы только задумываетесь о профессии в области Data, то учитесь, ребят.
Это безумно интересно и очень востребовано :-) 

Пользуясь случаем, хочу пригласить вас на бесплатный онлайн-митап «Возможности Heap Table в PostgreSQL». На нём я расскажу о Heap Table, Table page, OIDS, CTID, TOAST table, отвечу на вопросы слушателей. Митап пройдёт 16 февраля (в среду) в 18:00. Регистрация по ссылке →