Привет, Хабр! Меня зовут Азат Якупов, я работаю 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 Engineer | Database Administrator | |
Цель должности | Предоставление быстрого доступа аналитикам к точным и своевременным данным. | Обеспечение процессинга и хранения данных: — предоставление быстрого доступа аналитикам к точным и своевременным данным; |
Основные задачи | — реализация батчевого обработчика для соблюдения 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 | — администрирование СУБД: 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, то учитесь, ребят.
Это безумно интересно и очень востребовано :-)
