Привет, Хабр! Меня зовут Алёна Катренко, и я уже больше 10 лет работаю с данными. Сейчас занимаю позицию руководителя платформы данных в Циане, но начинала как BigData-инженер в Неофлексе.
Можно сказать, что мой карьерный путь был достаточно фокусным, хотя я и успела поработать на разных проектах российских и зарубежных компаний.
На первый взгляд работа с данными может показаться скучной, состоящей из перетаскивания данных из одного хранилища в другое. В этом действительно есть часть правды :) но не вся правда… Если присмотреться, мы увидим, что дата-инженеры помогают компаниям сокращать время на поиск инсайтов, обучение моделей и понимание нужд пользователей. Данные — это новая нефть, поэтому важно понимать, как правильно их организовывать и какие сложности в работе могут повлиять на успешность бизнеса.
Сегодня расскажу, как мы приручали петабайты данных, искали призраков забытых таблиц и нашли инструмент, который сделал работу с метаданными понятной, безопасной и полезной для бизнеса. А ещё о том, как сейчас развиваться дату-инженеру, чтобы успевать за тенденциями на рынке.
Управление данными в масштабах петабайт
За время работы дата-инженером я успела поучаствовать в разных проектах. Одним из самых запоминающихся был проект по реализации near-realtime обработки данных для крупной международной компании. Основная деятельность компании была связана с контрактным производством электроники, но у них также было много IT-проектов. Есть что-то невероятное в том, чтобы быть частью команды, которая обеспечивает поступление данных через половину земного шара в режиме реального времени. Вот на заводе в операционном центре в Китае рабочий ввёл параметры, а через секунды уже меняются графики работы системы на мониторах в США.
Конечно, у каждой компании свои особенности процессов и запросы к данным. И то, что работает для одних проектов, может совсем не подходить другим. Но для меня этап первоначальной проработки системы, первые пробы и интеграция дата-решений с другими компонентами системы — самые интересные кейсы. А опыт работы с международными заказчиками (крупными ритейлерами и производствами) помог разобраться в сильных и слабых сторонах Cloud Native архитектуры.
Сейчас это особенно важно, так как с приходом на рынок Ai-ассистентов резко вырос спрос на Сompute ресурсы. Платформы конкурируют за более доступные и мощные процессоры, потому что для обработки данных нужны большие мощности. И компаниям, которые не могут позволить себе содержать собственные дата-центры, приходится пользоваться мощностями облачных провайдеров. Поэтому Cloud Native-подход и контейнеризация для снижения Vendor lock-in — уже давно не тренд, а устоявшаяся практика на рынке.
Ещё одним значимым трендом на рынке стал Data Governance. Специалисты, которые так или иначе работают с данными, наверняка сталкивались с этим понятием в своих компаниях. Крупные игроки на рынке давно внедряют основные принципы и начинают, как правило, с каталогизации данных.
В Циане мы тоже столкнулись с тем, что рост данных приводит к усложнению процессов в работе с ними. Там, где раньше самостоятельно справлялись DE, аналитики и DS, теперь необходим инструмент для хранения контекста о данных.
Сложности управления
В какой-то момент мы у себя поняли, что для внесения правок в существующие таблицы нам нужна неделя на поиск потребителей этих данных. Ведь перед тем, как что-то поменять, надо убедиться, что изменения не сломают существующие процессы. И больше всего от этого страдают старые таблицы, потому что найти человека, который бы помнил, зачем они вообще нужны, крайне сложно.
Когда объём данных начинает измеряться уже не терабайтами, а петабайтами и эксабайтами, компании сталкиваются с проблемами Data Ownership (владения данными и ответственностью за них). Внесение правок становится крайне рискованным и трудоёмким процессом. А все хотят сокращать издержки по хранению данных, а не увеличивать. Поэтому ищут новые подходы.
У нас эта проблема наиболее остро проявлялась в DataLake, организованном в s3. Основная сложность со сбором статистики в объектном хранилище была в том, что счета приходили ежемесячно за объём данных. Поэтому инструмент управления метаданными, в котором можно чётко определить владельца данных, увидеть полный Data Lineage и вывести статистику использования данных был просто необходим. А в качестве бонуса мы искали решение, которое позволило бы строить DQ-проверки, так как это бы стало основой для развития Data Governance-практик в компании.
Инструменты управления метаданными
На самом деле, у нас в компании уже существовал каталог данных на минималках — Amundsen. Хорошее Open Source решение, но, как и с любым инструментом с открытым исходным кодом, мы столкнулись с большими трудозатратами на его развитие. Многие компоненты приходилось допиливать самостоятельно, но приоритет у таких задач традиционно низкий. Всё ещё сложно убедить бизнес, что значительную часть capacity команды стоит потратить на развитие инструмента, в котором можно будет увидеть стрелочки потоков данных. Поэтому, прежде чем двигаться дальше, мы решили обновить информацию о готовых решениях на рынке.
К выбору инструмента подошли с учётом 3-х возможных сценариев развития событий:
Выбираем и внедряем инструмент, в котором есть все необходимые функции из коробки (очевидно это будет достаточно дорогое решение).
Развиваем Open Source инструмент.
Забываем всё, что было до этого, и стартуем разработку своего инструмента.
Для выбора инструмента мы взяли результаты аналитического отчёта по сравнению инструментов в области Data Governance. Фаворитами стали Arenadata Catalog и Data Ocean Enterprise Metadata Management.
Кандидатами для Open Source решений стали Open Metadata, DataHub и Amundsen. Из финального шорт-листа Open Metadata была исключена из-за методики наполнения Push, при которой каждый источник должен сам наполнять каталог, используя его APi.
Сравнивали инструменты по следующим критериям:
• наличие в каталоге:
◦ возможности создания разметки данных согласно их категориям
◦ возможности описания активов данных с гибко настраиваемой моделью страницы заполнения описания
◦ возможности назначать владельца данных и метрик
• наличие бизнес-глоссария и возможность настройки процесса согласования бизнес-терминов
• наличие дерева метрик
• возможность автоматического построения Data Lineage
• функционал создания DQ-проверок
• наличие механизма профилирования данных
• с точки зрения безопасности нас интересовали:
◦ возможность создания ролевой модели (интеграция с AD)
◦ интеграция SSO KeyCloak или Active Directory
◦ аудит действий пользователей
◦ маскирование в семплах данных
• также значительным преимуществом было бы наличие инструмента по сбору статистики внутри самого каталога.
По сравнению с собственной разработкой каталог от Arenadata выигрывал в простоте поддержки и развёртывания. У Open Source решений ожидаемо оказалось намного меньше функционала, встроенного в изначальную поставку. А дальнейшая доработка инструментов осложнила бы обновление версии приложения в будущем. Поэтому по результатам оценки инструментов и затрат на внедрение мы выбрали Arenadata Catalog.
Результаты внедрения инструментов
Сейчас мы активно работаем над развитием Data Lineage и определением правил для владельцев данных. Каталог используется в компании как справочник по данным, но у нас есть планы на встраивание его в общий пайплайн разработки, чтобы новые данные начинались с требований продукта или гипотез аналитиков и дата-инженеров. Мы также развиваем инструменты контроля за данными, так что выбранное решение соответствует нашим первоначальным запросам.
Несмотря на сложности, внедрение подобных инструментов — один из этапов развития любого бизнеса. Данные помогают управлять бизнесом, и нужны инструменты, чтобы делать это максимально прозрачно. Это уже не тренд, а реальность сегодняшнего дня.
Да, по ходу внедрения мы сталкивались с трудностями, ведь это новый фреймворк, который к тому же постоянно развивается.
Основная трудность — методологическая. Инженеры и аналитики не привыкли, что каталог — это часть рутины, и вопросы, с которыми они раньше приходили в чаты, можно решить с помощью нового инструмента. Однако мы были к этому готовы и постепенно вовлекали новые группы пользователей через обучение и периодические обновления каталога.
У нас были трудности с «зависающими» процессами, когда обновляемые по расписанию мета-данные не были готовы в срок из-за инфраструктурных проблем внутри сборки каталога. Из-за этого пришлось глубже изучать механизмы работы, разбираться с первопричинами и реализовывать дополнительные инструменты мониторинга.
Как и для любой новой технологии, нужно время, пока в команде не появится необходимая экспертиза, но пользователей снова нужно обучать. Тем более, что сейчас всё стремительно меняется, и поспевать за всеми изменениями самостоятельно, без стороннего опыта — довольно сложно.
Как развиваться дата-инженеру
Интересно, что в самом начале моего пути роль дата-инженера в компаниях выглядела иначе — нужно было больше писать на Scala и поддерживать инфраструктуру как Ops-инженеру. Однако с ростом индустрии изменилась и роль инженера по работе с данными. На рынке появилась потребность в платформенных инженерах, которые по-прежнему большую часть времени уделяют написанию кода для библиотек и различным инфраструктурным проблемам. Параллельно с этим растёт и спрос на дата-инженеров, которые могут выстраивать эффективные процессы обработки данных, опираясь на потребности бизнеса. При этом для них нет необходимости глубоко погружаться в работу тех или иных инструментов.
Конечно, это в первую очередь зависит от потребностей компании, но явная тенденция на такое разделение ответственности есть. Специалистам по работе с данными крайне важно отслеживать тенденции на рынке и иметь качественную базу. Глубокое понимание процессов распределённой (и не только) обработки данных и структур данных могут дать в вузе. Но это можно получить и вне университета, если развивать свои внутренние проекты, которые помогают разобраться, как работает нужный инструмент.
Есть список обязательной к прочтению литературы, который помогает определить для себя Best Practice и увереннее ориентироваться в мире данных. Но сейчас не все любят читать лонгриды, поэтому, к примеру, в Циане есть читательские клубы, чтобы поделиться впечатлениями после прочтения отдельных глав или интересных статей.
Знакомиться с трендами и общепринятыми практиками можно в IT-сообществе. Есть профильные конференции и митапы как в крупных городах, так и в регионах, но технических всё ещё недостаточно. Это особенно ощущается, когда уже есть опыт и стремишься его расширить, но не понимаешь, как. В такой момент многие инженеры начинают выступать на профильных мероприятиях. Это не только позволяет поделиться наработанным опытом, но и самому взглянуть на него с другой стороны, переосмыслить и сделать новые, иногда неожиданные выводы.
У меня, например, был опыт разнообразных выступлений и подготовки коллег к выступлениям, но я ещё никогда не была организатором. При этом мне всегда казалось, что крайне важно развивать и поддерживать сообщество, ведь в наше время любая компания не сможет долго оставаться конкурентоспособной на рынке без анализа данных. Поэтому я решила попробовать что-то новое: пообщалась с нашим DevRel, заполнила заявку и стала частью команды Data Internals X.
Это ещё более сильные эмоции, чем выступление. Как говорила разработчица первого компилятора для компьютерного языка A-0 System Грейс Хоппер:
«Помимо создания компилятора, самым важным своим достижением я считаю обучение молодых людей. Они подходят ко мне и спрашивают: «Как думаете, у нас получится?», а я отвечаю: «Пробуйте». И всегда их поддерживаю. Им это нужно. Я продолжаю следить за их успехами, когда они становятся старше, и время от времени слегка встряхиваю их, чтобы они не забывали рисковать».
Надо не забывать иногда встряхиваться и искать что-то новое или новое о старом. В общем, двигаться и развиваться. У нас на Data Internals всё это будет. Например, целая выделенная секция про базы данных, в которой мы поговорим о специфике различных движков. Мне кажется, это очень важная и полезная тема, потому что для дата-инженеров не существует работы без баз данных. Да и время сейчас подходящее, на отечественном рынке активно развиваются свои решения для работы с данными. Ещё будут интересные доклады про управление данными, потому что Data Governance — ещё один из больших трендов. И это очень здорово!
Ну и, конечно, общение. Такие мероприятия позволяют опытным специалистам поделиться опытом в различных кейсах построения платформ и инструментов для работы с данными. Так каждый инженер сможет не только прокачать свою насмотренность в технологиях, но и привнести в компанию проверенные решения из индустрии.
Заключение
Компании всё больше хотят знать о пользователях, их предпочтениях и потребностях. Как следствие, приложения становятся более клиентоориентированными.
В области данных главной сущностью становится пользователь, через его запросы строятся рекомендательные системы. Количество данных растёт вместе с ростом активности пользователей в сети, а это требует ускорения процессов обработки данных, развитие новых движков в системах хранения, а также real-time систем.
Потребность в Data Governance (это касается и других трендов) появилась не на пустом месте. Это ответ рынка на рост данных и появление Ai-ассистентов. Поэтому, если вы ещё не инвестируете время в развитие технологий в рамках компании или в своё собственное, есть повод задуматься — понадобятся ли эти навыки и технологии через 5 лет.
Для развития дата-инженера важно понимать, чем живёт индустрия, чтобы оставаться востребованным на рынке и развивать решения внутри компании. Отслеживание трендов и нетворкинг внутри комьюнити позволяет нам понимать, движемся ли мы по правильному треку развития или отстаём от стандартов на годы.
Легче всего отслеживать «пульс индустрии» на профессиональных мероприятиях, где эксперты делятся пережитым опытом и собственными наработанными навыками. Больше информации о профессиональной конференции по инженерии данных, базам данных и системам хранения и обработки данных можно посмотреть на официальном сайте.