Привет, Хабр! Меня зовут Азат Якупов, я работаю 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, то учитесь, ребят.
Это безумно интересно и очень востребовано :-) 

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

Комментарии (10)


  1. ramil_trinion
    10.02.2022 17:30
    +1

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

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

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

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


    1. azatyakupov Автор
      10.02.2022 17:52

      Добрый день! Это описание пирамиды данных и знаний, которая упоминается во многих книгах, например "DAMA-DMBOK. Data Management Body of Knowledge" и "Turning TEXT into GOLD. Taxonomies and Textual Analytics" . Могу вам их порекомендовать.


      1. ramil_trinion
        10.02.2022 17:54

        И? Ссылка на источник не добавляет смысла написанному вами. Кто то написал ерунду, а вы ее перепечатали.


        1. azatyakupov Автор
          10.02.2022 19:47
          +1

          Позвольте заметить, что, например, книга “Turning TEXT into GOLD. Taxonomies and Textual Analytics” написана Bill Inmon, он является отцом основателем классического Data WareHouse, и я не могу сказать, что он пишет «ерунду». Вот, пожалуйста, ссылки:
          https://www.amazon.com/DAMA-DMBOK-Data-Management-Body-Knowledge/dp/1634622340/
          https://www.amazon.com/Turning-Text-into-Gold-Taxonomies-ebook/dp/B01N7OK2SZ/


          1. ramil_trinion
            10.02.2022 20:19

            Называйте его как хотите, написана ерунда.


            1. azatyakupov Автор
              10.02.2022 20:44
              +1

              Подскажите, что именно в пирамиде данных вы считаете ерундой? Давайте обсудим? :)


  1. Mrk0jo
    11.02.2022 18:24

    Любопытное распределение ролей


    1. azatyakupov Автор
      12.02.2022 10:05

      Добрый день! Спасибо за внимание к статье :) 


  1. Xenia-Day
    11.02.2022 18:56

    Как раз изучаю DAMA DMBOK. Интересно было оценить реальный пример использования этого подхода. Спасибо за статью.


    1. azatyakupov Автор
      12.02.2022 10:05

      Добрый день! Спасибо, рад, что статья была вам полезна :) Успехов!