Как мы покорили методы Big Data для данных любого размера
Всем привет! Меня зовут Саттар Гюльмамедов, и я работаю в команде ETL платформы DataOps в МТС. Марк Твен как-то написал: «Слухи о моей смерти сильно преувеличены», — про Big Data сейчас можно сказать то же самое. Волна хайпа, которую многие пытались оседлать, прошла. Но, как и значительная часть инженерных достижений, работа с большими данными стала рутиной, помогающей развиваться другим направлениям в ИТ.
В экосистеме МТС мы строим для Big Data отдельную платформу, где есть инструменты для хранения и оценки данных, анализа и построения отчетов. Но все начинается с их загрузки и обработки. Получение и преобразование данных — как раз задача библиотек и сервисов, которые делает моя команда. Многие знают мем о перекладывании JSON. А мы как раз делаем инструменты для тех случаев, когда такие задачи уже не столь тривиальны и нужно разобраться с разными типами данных, разными структурами, хранящимися к тому же в разных форматах, и все это нужно сделать в рамках одного процесса.
В этом материале я расскажу про наши решения и условия, лежащие в их основе. Одним наш опыт поможет спланировать эволюцию своих инструментов, другим — снять страх перед сложным стеком технологий Big Data, а третьи просто развлекутся.
Дисклеймер:
чтобы не отклоняться от темы, я не буду подробно описывать концепции ETL и ELT (они хорошо разобраны тут, тут и тут). Наши инструменты следуют парадигме »E[TL]+», т. е. позволяют выполнять трансформации данных как в процессе переноса, так и в целевом хранилище.
Про нашу платформу в общих чертах писал мой коллега Дмитрий Бодин в своей публикации »Customer Happiness: как не только разработать, но и внедрить новый продукт внутри крупной компании». Я продолжу начатый им рассказ и добавлю подробностей о компоненте ETL, его составляющих и нашей команде.
Это первый текст про наши инструменты. Примеры кода, диаграммы или другие артефакты, характерные для процесса разработки или проектирования ПО, будут в следующих материалах, где мы детальнее рассмотрим наши решения.
Почему нам нужны гибкие и адаптивные инструменты
Ключевое влияние на нас оказывает специфика МТС. В компании сформировалась среда, для которой характерны:
Больше двадцати видов хранилищ
Нашим пользователям нужно работать с данными из различных реляционных и нереляционных СУБД, MPP и файловых систем. Иногда они сочетаются в рамках одного процесса, иногда данные дополняют друг друга, последовательно поступая из разных мест. Так или иначе, наши инструменты должны работать с несколькими десятками видов источников, приводить данные из них к «единому знаменателю» и преобразовывать их, иногда прямо в процессе переноса.Широкий диапазон объемов данных — от Мб до Тб
У одних пользователей обрабатывается по несколько терабайт в день, у других — всего лишь десятки строк. Кому-то хватает таблицы с минимальным набором столбцов, а есть примеры с сотней колонок. Одни обрабатывают данные для тысяч таблиц, а другие — пару штук. Наши инструменты должны приспосабливаться к разным видам нагрузки, чтобы эффективно задействовать ресурсы, у большей части из которых может быть несколько пользователей.Множество решаемых задач — от самых простых до мегасложных
Наши компоненты в основном используют инженеры данных, аналитики (включая Data Science) и разработчики. У всех свои навыки и уровни знаний. Наши инструменты должны подходить для разных кейсов, быть простыми в освоении начинающими пользователями, но вместе с тем обладать мощью и гибкостью, достаточной для самых требовательных экспертов.Требование Quick Start (быстрого старта)
Пользователи должны легко получать, разворачивать и начинать работу с нашими инструментами. Еще бывают случаи, когда пользователи меняют специальность или продукт, но продолжают работать с данными. Наши решения должны давать возможность легко переключиться в новую роль или предметную область, фокусируясь на задачах, а не ковырянии в настройках.
Теперь, когда в общих чертах понятны условия, в которых применяются наши инструменты, давайте рассмотрим, что же лежит в их основе.
Собираем пазл
В МТС команды, работающие с Big Data, собраны в отдельный центр и разделены по сегментам: каждая помогает решать задачи в определенной сфере (банковский и страховой скоринг, рекламные технологии, антифрод и так далее). В начале времен они самостоятельно разрабатывали тулинг для своих пайплайнов, но довольно быстро пришло осознание, что от такого подхода больше вреда. Не самая лучшая ситуация, когда в каждой из 50+ команд свои стандарты и варианты решения одних и тех же задач. А если учесть, что команды появлялись в разное время и развивались с разной скоростью, то существовавший зоопарк может до глубины души поразить своим разнообразием.
В какой-то момент одних только ETL-фреймворков было штук пять. И это без учета остальных инструментов и сервисов. С одной стороны, такое обилие помогало находить подходящие решения, но с другой — взрывало мозг. Когда инженер для одинаковых задач переключается между кучей библиотек и языков, то такое разнообразие только мешает работе. Это все равно, что есть стейк, меняя обычную столовую вилку на десертную, а потом — на вилы ретиария.
На основе таких наработок, непосредственно используя кодовую базу или вдохновляясь ею как референсом, и появились общие инструменты с выделенными командами. Мы — как раз одна из них.
Что нужно большой экосистеме
Сначала мы ориентировались только на инженеров, которые собирали данные из различных источников, приводили их к одной форме, структурировали должным образом, обогащали или редуцировали, отбрасывая лишнее.
Затем стало понятно, что на базе реализованных инструментов можно создавать новые — вспомогательные или упрощающие работу. Тогда наша целевая аудитория расширилась и стала включать в себя специалистов по управлению данными, администраторов данных и даже бизнес-пользователей. Последним иногда нужно быстро получить справку, построить на скорую руку отчет или проверить какую-то гипотезу с применением ИИ.
Так в числе наших разработок появились:
onETL: библиотека с примитивами для ETL/ELT (GitHub, документация);
d-Van: внутреннийlow-code-инструмент для реализации простых процессов;
Data.SyncMaster: no-code-сервис для бизнес-пользователей (GitHub, документация);
Data.Horizon: вспомогательный сервис для организации инкрементальных процессов обработки данных (GitHub, документация);
Data.Rentgen: Data Motion Lineage (GitHub, документация).
Мы создали набор связанных между собой или использующих друг друга инструментов. Основная их часть — оболочка, скрывающая низкоуровневые интерфейсы и предоставляющая упрощенные API для стандартных ситуаций, требующих проверенных решений. Именно это и позволяет нам сохранять гибкость, но в то же время вовлекать пользователей и прививать им лучшие практики.
Выбор формы передачи данных
Мы разрабатываем инструменты пакетной обработки данных. С одной стороны, мы появились в Центре Big Data и исходили из его потребностей. В основе работы с большими данными был и все еще остается Hadoop, который ориентирован на батчи. С другой — несмотря на растущую популярность потоковой обработки, пакетные процессы не исчезают, и мы видим, что их число растет. В каких-то случаях потоковую обработку нельзя применить из-за окружения, ее может быть неудобно использовать или она вообще не имеет смысла. Возможно, эти два подхода даже и не нужно противопоставлять, поскольку глубоко под капотом потоковой обработки скрывается (микро)пакетная, а во множестве случаев они используются в комбинации.
Так или иначе, наша команда сейчас сфокусирована на инструментах пакетной обработки, и в основном мы будем говорить именно о ней. В дальнейшем мы можем рассмотреть оба подхода для сравнения или анализа их совместной работы. Готовы откликнуться и рассказать интересные для читателей кейсы.
Зачем это нужно?
Наши инструменты — попытка расширить сферу применения методов и приемов, характерных для Big Data. С помощью нашего DataRentgen разобраться, какой процесс год назад привозил данные из FTP в HDFS, теперь может не только бородатый «одмин» Hadoop, но и вежливая барышня из DG. А в три клика перенести данные из ClickHouse в S3 под силу свежеиспеченному джуну-второкурснику.
По сути мы даем коллегам возможность использовать мощь Apache Spark, который «укротили» и сделали более «дружелюбным». Но подробнее об этом — в следующих публикациях. В них мы расскажем о каждом инструменте, покажем примеры использования и обсудим спорные вопросы. Например, когда потоки полностью поглотят батчи, чем Polars лучше Spark и какие подходы лучше использовать при партиционировании таблиц.
