Привет, Хабр! На связи группа экспертов по управлению данными из МТС.
А именно: Патрисия Кошман — руководитель группы (управление метаданными) и Аксинья Ласкова — эксперт по практикам качества данных.

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

Как это происходит у нас — рассказали под катом!

При работе с данными в хранилище мы используем одновременно несколько подходов:

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

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

В статье расскажем о первом подходе — работе с данными из хранилища Big Data. Поехали!

Дела давно минувших дней: с чего начиналось хранилище данных в МТС

Давным-давно в хранилище было интегрировано меньше 10 систем — источников данных. Все потоки данных поддерживались на устных договорённостях между командой поставщика и потребителями данных.

Постепенно источников стало более 100, а процессов загрузки более 3 000. Перед командой эксплуатации остро встал вопрос управляемости и поддержки интеграций как со стороны источника, так и со стороны хранилища. Система-источник не упускала возможности изменить тип или формат передаваемого поля и не предупредить об этом хранилище. Из-за этого интеграция падала, а команда эксплуатации вместо утренней чашки кофе бегала и искала причину.

Потребителей тоже стало много: хранилищем пользовалось всё больше продуктовых команд и групп аналитиков. И, если объект менялся (ещё и неожиданно), команде эксплуатации приходилось думать: «А не сломается ли что-то у коллег? Например, отчётность, модели, рекламные кампании?» А потом делать рассылку всем потребителям хранилища, так как потребителей изменённого объекта обычно не знали.

Кроме этого, команда Big Data самостоятельно проверяла качество данных, ведь ошибочные и некачественные данные могли повлиять на работу коллег.

Переход к Data Service

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

А значит, нам нужен Data Product, или Data Service, как мы его назвали. Подробнее о нём можно почитать тут и тут. Он будет помогать в создании и распространении данных в аналитических и операционных сценариях.

Для нас Data Service — это данные, которые:

• нужны более чем одному потребителю;

• расположены в хранилище или на интеграционной платформе;

• «упакованы» в соответствии с определёнными в Экосистеме стандартами, позволяющими обеспечить качество, доступность и простоту использования этих данных.

Создание Data Service подразумевает следование ключевым принципам работы с данными:

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

• Датацентричность
  Данные — это основной актив, на котором строятся продукты, сервисы и процессы. Они же его порождают.

• Использование платформ
  Создаваемые нами решения и продукты для всех типовых задач управления, разработки, доставки и эксплуатации используют XaaS-платформы категорий: PaaS, Product, DevOps, ArchOps, Integration, SRE/Monitoring Data, DataOps/MLOps, Security.

• Машиночитаемая документация
  Документация в целом и контракт по Data Service в частности должны оформляться в виде специальных манифестов и тому подобных документов с полуструктурированными данными стандартного формата.

• Партицируемость
  Решения разделяются вертикально на сочетание автономных и функциональных партиций на всех уровнях (Teams, Front-end, Back-end, Data, Infrastructure). Эти уровни состоят из наборов слабосвязанных компонентов и сервисов (UI/Service/Data-Mesh), поддерживаемых и развиваемых автономными кросс-функциональными командами.

• Zero trust
  Все пользователи (в периметре организации и за её пределами) должны проходить аутентификацию, авторизацию и постоянную проверку безопасности учётной записи, устройств и сетевого окружения. Без этого они не могут получить и сохранить доступ к приложениям и данным.

Это всё можно реализовать инструментами DataOps-платформы, про которую вы можете почитать в материале наших коллег.

Главное отличие от предыдущего подхода — стандартизация и продуктивизация. Data Service больше не «какая-то интеграция» или «мы отдаём данные в Big Data». Любой продукт МТС, например KION или Строки, может создать и опубликовать свой Data Service, чтобы другие продукты смогли легко и быстро им воспользоваться. Сейчас расскажем, как именно.

С чего мы начинали

До того как мы начали внедрять Data Service, стандартный процесс по разработке витрин данных в хранилище выглядел примерно так:

Единого подхода к тому, как проектируется Data Service, какие артефакты на каждом этапе его разработки должны появляться и каким требованиям они должны соответствовать, не было.

Наш первый Data Service

В компании все предлагаемые подходы принято пилотировать, что мы и сделали. Первым Data Service стал классификатор продуктов CVM и услуг, собираемый из трёх различных систем. Рассмотрим на примере сервиса работы с кешбэком. Он был выбран, так как многие смежные направления его используют для различных целей, например:

• для управления программами лояльности — начисления бонусов и кешбэка пользователям за определённые действия;

• при расчёте эффективности управления маркетинговыми кампаниями и рекламными акциями (смотрим, какая кампания или акция достигла поставленной цели);

• при анализе вовлечения клиентов в пользование кешбэком;

• в отслеживании транзакций по бонусам и кешбэку для правильной классификации подключённых абонентам услуг (для корректного определения отклика абонентов).

Потребителей у классификатора много, но все они получали данные из него по запросу в виде таблицы Excel.

Ключевые свойства Data Service

Для перехода к Data Service мы решили выделить несколько ключевых свойств, и вот что получилось:

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

До: классификатор ранее создавался и хранился в центре маркетинга, и знали о нём лишь избранные.
После: классификатор стал доступен в каталоге данных, и любой пользователь может найти его. Метаданные классификатора описаны в соответствии с рекомендациями, принятыми в компании, что помогает будущим потребителям находить его в каталоге данных.

2. Адресуемость: сервис данных должен иметь уникальный нейминг и месторасположение в соответствии с определёнными нами правилами (naming convention). Это нужно, чтобы пользователи могли получить доступ, обратившись к определённому интерфейсу.

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

3. Качество данных: если данные не заслуживают доверия и не соответствуют действительности — они бесполезны. Владельцы сервисов должны взять на себя ответственность за качество данных и придерживаться утверждённого уровня обслуживания.

До: о качестве данных в классификаторе задумывались только при появлении проблемы ad hoс, когда потребители приходили и указывали на ошибку либо сами замечали её.
После: мы сформулировали и автоматизировали обязательные проверки (о них далее), которые своевременно найдут и подсветят найденные ошибки в данных.

Среди наших планов на будущее Data Service:

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

Итак, базовая архитектура Data Service выглядела примерно так:

Предлагаем только самые качественные данные

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

Чтобы отслеживать это свойство, мы сформулировали три требования, которые сейчас распространяем на все наши Data Services:

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

Например, в классификаторе CVM данные должны обновляться каждые сутки с 20:00 до 23:59. Проверка, запущенная в 05:00 следующего дня, должна в наборе данных обнаружить хотя бы одну запись за предыдущее число.

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

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

В этом примере бизнес-ключ — это ID_продукта и ID_услуги. Проверять технический ID записи в классификаторе нет смысла: он генерируется автоматически и ни при каких условиях не может задублироваться.

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

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

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

Одна из важных для нас целей — не увеличить нагрузку на продукты для создания Data Service по всем правилам.

Сейчас концепция Data Service ещё в процессе запуска, мы фиксируем требования и отрабатываем обратную связь. Вот несколько LESSONS LEARNED:

• работа с Data Service требует определённых навыков от наших коллег. Чтобы обучить всех быстро и безболезненно, мы проработали матрицу компетенций и подготовили курс для корпоративного университета;

• в ситуациях, когда Data Service нужен, а ресурсов нет (человеческих, технических, финансовых или всех сразу), для пилотирования мы предлагаем использовать коммунальные (общие, поддерживаемые третьей стороной) ресурсы. Чтобы попробовать решение, этого хватит, а на основе этих проб уже проще защитить развитие решения;

• автоматизация мониторинга требований качества данных может занимать много времени. Когда мы запускали первый Data Service, команда продукта потратила почти 3 часа на создание базовых проверок качества данных. Это было неприемлемо для нас. Чтобы сократить время реализации в DataOps Platform, мы создали шаблон проверок. Он помогает настроить все требования Data Quality за полчаса с помощью корпоративного инструмента DataOps.DQ. Владелец Data Service определяет параметры для каждого из требований и заполняет соответствующий раздел шаблона.

Пример заполнения параметров проверки:

{% set objects = [
  {
    "database": "data_service",
    "schema": "public",
    "table": "dm_product_service_link",
    "timeliness": true,
    "date_filter": "date_trunc('day',\"Date\")=current_date - 1",
    "uniqueness_columns": [],
    "complex_uniqueness_columns": [("product_id", "service_id")],
    "completeness_columns": ["product_name", "link_id", "product_category_name", "product_valid","product_id", "service_id", "link_base_connection", "link_status","service_global_code", "service_name", "service_source_id"],
  } ] %}

Параметры Data Service мы планируем фиксировать в Data Contract. Он представляет собой соглашение между источником, потребителем и платформой, на которой публикуется Data Service.

На этом всё — готовы ответить на ваши вопросы в комментариях! А о том, как продукту оформить Data Contract, мы расскажем в следующих статьях.