За счёт правильных, даже необязательно новых, а просто верно выбранных архитектурных подходов можно заставить работать не один конкретный запрос, а тысячу или даже  миллион. Это становится краеугольным камнем, потому что объёмы данных растут с такой скоростью, которую мы даже представить себе не могли ещё пять лет назад.

Привет, Хабр! Именно так считает наш сегодняшний гость – Дмитрий Немчин, руководитель направления эксплуатации инфраструктуры данных в Т-банке и по совместительству член программного комитета Data Internals, профессиональной конференции по инженерии, базам и системам хранения и обработки данных.

В беседе Дмитрий рассказал о своём пути в данные и программный комитет конференции, поделился интересными кейсами и проблемами, связанными с ростом объёмов данных и необходимостью управления ресурсами. А также объяснил, как дата-инженеру остаться востребованным в будущем, где ИИ может проникнуть абсолютно во все сферы жизни.

Путь в данные

Расскажи коротко о себе, как ты попал в данные, как вообще пришла идея заниматься этим направлением, почему нравится это делать?

В данные я пришёл довольно странной дорогой. Учился на проектирование интегральных схем, успел немного поработать в этой сфере, занимался микроэлектроникой. Но в какой-то момент мне пришлось ещё и администрировать локальную сетку, специфические приложения, помучиться с Linux.

Потом я сменил деятельность, уйдя в довольно специфическую компанию, «дочку» Газпрома. Там я опять воевал с Linux, учился дружить и сражаться с Oracle. Это продлилось полтора года, — писал в «кровавом» энтерпрайзе процедурки, обслуживал базы довольно большого интересного веб-приложения. Но с развитием и с деньгами, честно сказать, было туговато.

В этой компании было несколько Oracle-баз, в которых было много довольно специфических данных по меркам OLTP. Наверное, самый запомнившийся мне проект, который я фактически сделал с нуля и довёл до продакшена — синхронизация данных между множеством филиалов и центром.

Чтобы продолжить профессионально расти, нужно было искать что-то новое. И вот мне позвонили из тогда ещё Тинькофф банка и предложили администрировать Greenplum. Я загорелся, хотя не знал, что это такое, о чём честно и сказал. Буквально за день до интервью — тогда ещё не было системы с многоступенчатыми собеседованиями — прочитал пару статей о Greenplum. Оказалось, что одну из них написал человек, который меня в итоге и собеседовал.

Это были гигантские объёмы — на тот момент в продакшене было 20 ТБ данных. После моих баз, в которых было около 200 или 500 ГБ, это казалось невероятным: «А зачем вам столько? Что вы будете делать?» — «Мы тут аналитику строим, у нас Data Driven». Пообщались, сошлись во мнениях. Мне задали классный вопрос: какая проблема любой базы данных? Я сказал: пользователи, и меня взяли на работу. Конечно это была шутка, но на этом мы поняли, что по вайбу сходимся.

Примерно с тех пор я в этом всём и варюсь с переменным успехом. За годы моей работы в Тбанке мы выросли с 20 ТБ до примерно 1,5 ПБ в самом большом Greenplum, и продолжаем расти. Правда, от Greenplum постепенно уходим в сторону более современных подходов к хранению и обработке данных. За почти 10 лет число кластеров у нас выросло с двух до 15, а сотня аналитиков разрослась до 15 тысяч.

Как получилось, что данные тебя вообще увлекли? Ведь изначально ты работал в другой сфере.

Изначально я занимался подготовкой данных, но немножко в другом контексте, для изготовления микросхем. Проектировал и готовил спроектированные интегральные микросхемы к производству. На входе – слои топологии, на выходе – файлы для их изготовления со своими особенностями по каждому технологическому процессу. Меня привлекала интересная физика процессов, также там нужно было базовое программирование и построение пайпланов для прохождения данных через множество систем и серверов.

Сначала писал простенькие SQL-запросы и делал маленькие pet-проекты ещё с SQLite и бесплатной версией Oracle Database Express Edition. Потом стал погружаться в Postgres и втянулся. Когда работал в «кровавом энтерпрайзе», писал много различных процедур, разбирался, как вообще работает СУБД. Дальше (тогда ещё в Тинькофф банке) работал с Postgres и Greenplum и меня это увлекло. Но я, как человек, пришедший из мира системных администраторов, гораздо больше разбирался в инфраструктуре, чем в алгоритмике и анализе данных. Мои навыки были скорее про то, как строить платформы, на которых другие люди настраивают потоки, ELT и т. д.

Интересные кейсы

Можешь вспомнить какой-то интересный кейс или проблему, которую ты решал при построении платформы?

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

Например, сначала у нас было классическое КХД — одна большая база, в которую ходит ETL, ночью считает, а днём результаты и отчёты доступны аналитикам. Потом этого стало не хватать.

Сделали второй кластер. В него данные перегоняются по мере подготовки. С его помощью разделяем ETL и пользовательскую нагрузку. Для этого разработали систему, которая направляет данные в кластер. Про неё, кстати, несколько раз рассказывали на разных митапах. Кластер поставили во втором ЦОДе. Мы немного параноики – любим защищаться от всего, ведь гипотетически в один из ЦОДов может попасть, например, ракета.

Потом поняли, что нам нужно ещё больше мощностей. Но бесконечно растить кластеры, нехорошо, потому что Greenplum, при всей моей любви к нему, всё-таки довольно архаичен в архитектуре. К сожалению, версии, которые у нас были (Greenplum v4, потом v5), просто не выдерживали больше ста одновременных запросов. Пытались что-то с этим сделать, поставили перед базой пулер соединений, но количество пользователей растёт, и этого тоже недостаточно.

Важный нюанс: изначально у нас в компании подход к получению доступа к данным был очень демократичным. Тебе не нужно быть аналитиком, чтобы пойти и что-то проанализировать. Естественно, процесс работы с ЧД — отдельная история. Но если тебе нужно проанализировать поведение клиентов на масштабе и там нет ничего секретного, иди и анализируй, пожалуйста.

Поэтому число пользователей постоянно росло, их стало уже не сто и не двести, а тысячи — и с этим надо было что-то делать. Мы строим несколько кластеров. Но чем их больше, тем чаще там ломается железо.

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

Следующий вызов — большой продакшен. Эту проблему точно характеризует не самая политкорректная фраза, которая мне очень нравится: только массовые расстрелы спасут большой продакшн. Такой гигантской платформе, как наша нужны правила игры. Чтобы как-то разграничить запросы, мы напилили маленьких скриптов. Один из них назывался «Сталин» (собственно, почему массовые расстрелы). Он был написан на Python и по определённым правилам «убивал» плохие запросы. Потом мы этот скрипт в пандемию показали на онлайн-митапе, но решили, что нарекать его «Сталиным» не очень хорошо и поменяли название на «Инквизитор».

«Инквизитор» вырос в довольно большой проект. Сейчас он умеет «отстреливать» запросы не только по очевидным параметрам: как долго работает реквест, как много генерирует spill-файлов или сколько «ест» CPU, но и по текстам и маскам запросов. Плюс мы отдали пользователям донастройку правил. Сделано так: есть базовые правила платформы, что запрос не должен работать больше какого-то времени, например, часа. При этом пользователь может настроить это время индивидуально. Например, чтобы у его команды запросы работали не больше 20 минут. Тогда он в API это настраивает, и запросы его сотрудников по определённым правилам работают лучше. И много кто так делает, для меня было удивительно, что у людей бывает такой уровень осознанности.

Поскольку пользователей много, но не настолько, чтобы целиком отдать кластер конкретной команде, у нас много «коммуналок». Соответственно, надо управлять ресурсами внутри кластеров, кому сколько и чего выдать. Это тоже есть в «Инквизиторе». Фактически пользователи API сами управляют ресурсами.

В Greenplum эта функция есть из коробки, но мы реализовали её иначе — через  управление профилями, то есть по времени. Ночью можно отдать ресурсы ETL, днём — пользователям, или ночью отдать одним пользователям, днём — другим, они сами между собой договариваются. Это работает, сейчас хотим экспортировать решение на новую платформу.

Классный опыт! На конференциях будете рассказывать об этом?

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

«Дима, давай, сделаем митап про Greenplum» — «Так к нам же никто не придёт!»

Давай тогда перейдём к конференции. Как ты оказался членом ПК Data Internals? У всех из программного комитета истории разные и очень интересные, какая у тебя?

Начну чуть издалека. В 2015 году я пришёл в Тинькофф, и мы с тогдашним коллегой Димой Павловым (он сейчас в ClickHouse работает) повадились ходить на митапы про PostgreSQL. Про Greenplum ещё никто не знал, его использовали полторы калеки, а по PostgreSQL уже начинался хайп. В Яндекс тогда уже перевели почту на эту БД. У неё уже формировалось своё сообщество. Митапы собирали по 100 человек в вечер буднего дня И в какой-то момент меня прямо пробило: «Дима, давай тоже сделаем митап про Greenplum» — «Так к нам же никто не придёт!» — «Неважно, давай попробуем!”. 

С этой идеей пришли к HR (тогда ещё у нас даже выделенного DevRel) и попросили помочь: «Нам очень надо, мы очень хотим» — «ОК, а что вам нужно для этого?» — «Нам нужна переговорка, кофе-печеньки, чтобы кто-нибудь встретил гостей, какая-то техника в переговорке, те же проекторы. Остальное сделаем сами.» — «А может, мы это запишем?» — «Давайте запишем, мы только за!».

На первую встречу пришло человек 30, и это было феерически круто, потому что аналитикой мало кто тогда занимался, а про инфру для аналитики вообще никто не говорил. Мы сделали несколько митапов, всё развивалось то в плюс, то в минус. В какой-то момент у нас на мероприятии выступали ребята из Pivotal, основного вендора Greenplum в то время. Затем всё сошло на нет, но мы несколько раз возвращались к этой идее. Потом появилась компания Arenadata, которая сейчас самый большой российский вендор Greenplum. И Дима ушёл туда.

В 2018 году меня уже настолько захватила мысль сделать что-нибудь очень публичное, что я пошёл на HighLoad. Там рассказывал про то, в каком мы состоянии, куда идём, что делаем и так далее. Потом из доклада даже статейку сделали. К 2024-му я начал больше интересоваться тем, что происходит на других конференциях.

Долгое время единственной специализированной конференцией про данные в России была SmartData. В её программном комитете у меня есть знакомые, друзья и коллеги, и нынешние, и бывшие. В прошлом году я выступал там как эксперт и понял, что это всё-таки совсем другое. Highload — это классно. Он хорошо организован, интересный, это очень большая конференция, но ребята, работающие с данными, часто там сидят где-то в уголке. А на SmartData их несколько сотен человек и все друг друга понимают.

В прошлом декабре я выступал на HighLoad в Москве с докладом и узнал, что Онтико запускает новые форматы и новые конференции. И загорелся идеей ещё одной конференции про данные. Тем более, Онтико, что скрывать, умеет делать масштабные мероприятия.

Что можешь сказать про грядущую конференцию Data Iternals? Чем она отличается? Что на твой взгляд в ней интересного?

В целом, программный комитет конференции довольно интересный и опытный в разных направлениях. Есть люди, которые занимаются разработкой СУБД и инструментария, есть и те, у кого богатый опыт построения data-платформ и архитектуры данных в разном бизнесе. Кажется, что, по крайней мере, на заседаниях программного комитета мы говорим на одном языке.

Сейчас мы более-менее точечно целимся в то, чтобы в докладах разбирали конкретные проблемы или боли индустрии.

Можешь выделить в программе один или два доклада, которые тебе больше всего нравятся?

Есть очень интересный доклад о том, как ребята переезжали с больших энтерпрайзных коробок, которые стали недоступны, на другие решения. Этот опыт можно забирать и использовать. Интересно, что людям, как и многим сейчас, пришлось разбираться, что решение делает с данными внутри, потому что такие коробки устроены совсем непрозрачно для пользователя. Перевели в другую BI, она: «А я так не умею. Идите, посмотрите, что там внутри».

Боли дата-инженеров

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

Главная боль — часть традиционных решений стала недоступна. При этом довольно давно почти для всего существовали либо open-source, либо российские аналоги. Отечественные альтернативы, к сожалению, функциональностью и качеством долгое время не отличались. Но сейчас довольно много российских разработчиков получили хорошие стимулы, инвестиции, чтобы что-то делать. Уже есть решения, с которыми можно и нужно жить и дружить. Много людей обратило внимание на ClickHouse. Он сделал просто космический рывок. Ребята молодцы — из нишевой базы под конкретные задачи Яндекс.Метрики ClickHouse стал чуть ли не универсальным решением. Грубо говоря, в каждой третьей data-платформе под витринами работает ClickHouse. И он может делать не только это.

При этом там, где не работает ClickHouse, работает какая-нибудь MPP, например, Greenplum. Но тут двоякая ситуация. При всей моей любви к Greenplum, он всё-таки довольно старый, до седьмой ветки обновиться не все успели, в придачу он перестал быть опенсорсным ещё в прошлом году. Это была очень резонансная история.

Мы даже, кстати, про это осенью сделали большой митап. Там мы собрали тех, кто использует, делает или продаёт что-то большое вокруг Greenplum и обсуждали, как дальше жить. У меня ещё с прошлой весны была идея объединиться и разрешать ситуацию, но быстро выяснилось, что далеко не все к этому готовы. Это, кстати, большая проблема, и не только в России. Но в России она очень актуальна, потому что рынок не очень большой и честный, нормальный, общепринятый open source хотят не все. Одни хотят, другие делают, кто-то делает под свои задачи, но выкладывает в апстримы. В целом люди очень тяжело договариваются, надо кому-то поднимать флаг и вести их за собой.

При этом есть ещё второй вопрос: где всё это делать — не очень понятно, даже на GitHub всех банили какое-то время назад. В общем, всё довольно грустно. Даже банально инфраструктурно: куда это класть, как это всё делать?

С чем эта ситуация связана? Почему так инертны некоторые твои коллеги в этом вопросе?

Дело не в инертности. Open-source-сообщества исторически свободные, они всегда про то, чтобы договариваться, не контролировать, а делиться. Комитет основных контрибьюторов — это люди, у которых обычно нет задачи заработать, они делают деньги, например, на коммерческой поддержке или на фичах и закрытых продуктах. А у нас проблема в том, что если люди не видят денег завтра, а видят их послезавтра, то им это уже не так интересно. Это довольно специфический рынок, в том числе, потому что среди заказчиков очень много гос или около госкомпаний.

Может, это у меня такой взгляд, может быть, уже всё поменялось, но длительное время многие в гос и около-госкомпаниях транслировали позицию: «Какой open-source? Вы что, это же кто-то в гараже на коленке сделал?! А нам вендор что-то правильное принёс». Притом что «правильные» большие вендоры по своим core-продуктам часто взаимодействуют с open-source-сообществами. Это сложная история, нужен именно сдвиг сознания, очень не люблю это слово, но именно изменение mindset.

Ещё дело в том, что когда люди начинают договариваться, все хотят контроля. Даже те, кто готов идти в open-source, хотят контролировать и решать. Вы хотите делать для людей? — Вроде да. — Вы хотите зарабатывать? — Да. — Вам никто не мешает, зарабатывайте. 

А влиять можно и нужно через код. Будет больше твоего кода, больше твоих коммиттеров, больше твоей разработки — у тебя будет больше влияния. То есть механизмы есть, они прозрачны и понятны. Но к сожалению часто компаниям хочется больше контроля через формальные механизмы.

Всё же меня не покидает надежда, что когда-нибудь получится что-нибудь хорошее, это вполне возможно.

Что дальше будет с данными и как остаться востребованным

Давай дальше пофилософствуем о том, что ждёт работу с данными, инжиниринг данных в будущем? Как влияет ИИ, какое это влияние – плохое оно или хорошее?

Интерес к работе с данными за последние пять лет сильно вырос. Во-первых, это уже не только про большие компании, но и про компании поменьше. Во-вторых, не только мы (Яндекс, Сбер и ВК) поняли, что работа с данными и аналитика может дать большой буст экосистемным проектам. Теперь любой бизнес, который вы открываете рядом, может дать большой буст, если вы не относитесь к нему как к отдельному бизнесу, а развиваете экосистему вокруг клиента. Она даёт хорошую прибыль, но для этого надо находить тренды, работать с массивами информации и делать много чего ещё.

С инфраструктурной точки зрения это выражается в том, чтобы делать системы работы с данными максимально масштабируемыми. Может, конкретный запрос и будет работать не очень быстро, и можно быстрее и лучше. Но сейчас за счёт правильных, даже необязательно новых, а просто правильных архитектурных подходов ты можешь заставить работать не один конкретный запрос, а тысячу или миллион. Это становится краеугольным камнем, потому что объёмы данных растут с такой скоростью, которую мы даже представить себе не могли ещё пять лет назад.

Что касается ИИ, то с одной стороны, технология даёт большой буст любой разработке, и Data Engineering здесь не исключение. С другой стороны, нейросети порождают проблемы. Если использовать их с чувством, с толком, с расстановкой, ИИ помогает решать оперативные задачи, писать код. Пока ты продолжаешь его контролировать, хотя бы читать, то, что он пишет, всё хорошо. У тебя есть и буст, и при этом ты не теряешь контроль. Но, к сожалению, демократизация написания кода часто ведёт к тому, что появляется boilerplate. Например, в веб-разработке — дичь, когда у тебя фреймворки весом с нормальную базу данных. При этом никто не знает, как он внутри работает, и никогда уже не узнает, потому что в нём разбирается два инженера в мире.

В Data Engineering такое встречается пока в меньшей степени, поскольку отрасль в целом отстаёт от Software Engineering. Тем не менее такие опасения есть. Но при этом применение хорошо и правильно тренированных моделей даёт много интересных инсайтов с точки зрения инфраструктуры. Сейчас ИИ начинает проникать даже туда, где его никогда не было, уже на совсем другой уровень. Интересно посмотреть, во что всё это выльется.

А куда всё может прийти, как ты думаешь? Может ли появиться какой-то «чёрный лебедь»?

Возможно, внимание индустрии будет сосредоточено на том, чтобы размечать и переразмечать данные, сгенерированные нейросетями, и отделять их от контента сделанного человеком. Потому что это становится всё сложнее. Иногда это нужно и даже довольно критично, например, в плане антифрода. А сейчас это большая проблема, потому что распространились фейковые данные и дипфейки.

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

Мы сейчас говорили про будущее, давай поговорим о том, что нужно, чтобы в это будущее успешно встроиться? Как развиваться, чтобы быть актуальным, востребованным, что учить, читать, смотреть?

Хороший вопрос. Начинать, как обычно, с «кабанчика» — Designing Data-Intensive Application. Хотя, честно сказать, я не дочитал. Изучать в целом базы, алгоритмы обработки данных, опыт больших компаний. Но не использовать это как карго-культ, а вдохновляться. Очень классно, что Uber строит Hadoop на экзабайты, но, скорее всего, экзабайты вам не нужны. Meta строит свои ЦОДы на специфическом железе. С огромной вероятностью вам это специфическое железо не нужно, по крайней мере, пока. Но вдохновиться некоторыми подходами действительно стоит, и у больших компаний, в том числе у российского BigTech есть очень хорошая черта — им не жалко делиться информацией о том, что они уже прошли, и это очень круто.

В целом с какого-то момента стоит посещать или хотя бы смотреть записи с конференций, потому что там бывает действительно интересно. Ходить на митапы — это такие конференции на минималках. Вечером в будний день собрались, поговорили. Очень много информации можно почерпнуть, задать вопросы и получить на них хорошие ответы.

В целом — делать, делать, делать, ошибаться, падать, вставать, снова делать, идти на StackOverflow, снова делать, переписывать всё, что ты скопипастил со Stackoverflow, и снова делать.

Супер, очень вдохновляюще. Спасибо за разговор!

______________________________________________________________________________

? Data Internals X — уже скоро!

Самое свежее из мира инженерии данных: новые инструменты, живые демонстрации, сильные доклады от практиков.

? 23 сентября 2025

? Москва, Loft Hall #3

? https://datainternals.ru/2025/

? Больше идей. Больше решений. Больше смысла. Присоединяйся — посмотрим, как выглядит будущее data-инфраструктуры вместе!