Меня зовут Азат Якупов, я работаю 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.
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 Engineer
Цель должности — предоставление быстрого доступа аналитикам к точным и своевременным данным.
Основные задачи:
- реализация батчевого обработчика для соблюдения GDPR (очистка истории пользователя);
- реализация потокового компонента загрузки данных в ODD-слой хранения Greenplum;
- написание ETL-процедур сбора/очистки данных.
Hard Skills:
- владение одним или несколькими языками программирования для написания ETL-процедур (Python, Scala/Java, Golang);
- понимание принципов создания и работы распределённых систем;
- опыт разработки batch- и streaming-приложений;
- опыт работы с СУБД (Greenplum, PostgreSQL);
- навык оптимизации SQL-запросов;
- опыт работы c hadoop- экосистемой (HDFS, Hive, Flink);
- опыт работы с брокерами сообщений (Apache Kafka);
- опыт работы с NoSQL БД (Apache Cassandra);
- навыки работы с OS Linux на уровне уверенного пользователя.
Database Administrator
Цель должности — обеспечение процессинга и хранения данных:
- предоставление быстрого доступа аналитикам к точным и своевременным данным;
- поддержка инфраструктуры данных.
Основные задачи:
- организация хранения и процессинга данных;
- установка и поддержание аналитического софта;
- оптимизация работы баз данных.
Hard Skills:
- администрирование СУБД: Greenplum, PostgreSQL, MySQL, ClickHouse;
- навыки работы с ОС Linux на уровне уверенного пользователя;
- знание принципов работы сетевых протоколов (TCP/UDP, HTTP, ICMP и других);
- владение одним или несколькими языками программирования для написания инфраструктурных инструментов автоматизации работы (Python, Scala/Java, Golang);
- владение инструментами системы управления конфигурацией (Ansible/SALT/Chef/Puppet).
При этом у нас в компании микросервисная архитектура, а микросервисы работают со своими источниками данных. Поэтому, помимо команды 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, то учитесь, ребят. Это безумно интересно и очень востребовано :-)
