CNews: Какие технологии для аналитики данных сейчас применяются на российском рынке? В чем их преимущества и недостатки?

Николай Голов: В России когда-то работали on-premise, open-source и облачные решения. Затем практически все западные вендоры аналитических решений ушли в облака, в то время как в России далеко не все компании готовы ими пользоваться. На фоне процессов последних лет многие западные on-premise решения ушли с рынка, а opensource либо свернулся, либо стал платным. Все это привело к тому, что в России не осталось развитых решений для аналитики данных.

Какое-то время в качестве варианта можно было рассматривать ClickHouse, но с 2023−2024 года на рынке возникло понимание, что он пригоден только как платформа для витрин данных, как ядро платформы данных он недостаточно функционален. Теперь у нас остался только Greenplum, но это довольно старое и не очень надежное решение.

Поэтому рабочих вариантов два. Или строить аналитику на старой классике — PostgreSQL, MySQL — со всеми ограничениями данных СУБД и вытекающими из этих ограничений последствиями. Либо пытаться самостоятельно собрать что-то на базе open-source решений — те же форки Greenplum (Cloudberry), Starrocks или компоненты OpenLakehouse: Trino, Spark, Impala, внедрение и интеграция которых занимает очень много времени. В общем, вариантов мало.

CNews: В чем ключевые отличия между российским и зарубежным рынками? Где российские разработчики отстают от зарубежных коллег, а где, возможно, опережают?

Николай Голов: Западный рынок существенно меньше боялся облаков, поэтому их решения в области аналитики развиваются с фокусом на удобство. Там заказчики не готовы иметь дело с техническими ограничениями или ждать настройки open-source решения в течение нескольких месяцев. Клиент хочет просто купить решение своей проблемы в два клика, и чтобы через час оно заработало. Это удобно, но легкий вход на рынок порождает беспорядок, обилие слабых решений и низкий уровень квалификации персонала. Красивый модный инструмент собирают специалисты с базовыми навыками. Получается так себе, но как-то с этим живут. При необходимости докупают еще инструменты.

Так что на Западе гораздо больше готовых решений, но в целом менее квалифицированный персонал. У нас гораздо больше технологически компетентных специалистов.

CNews: Вы сказали, что облаков не боялись раньше. А сейчас?

Николай Голов: На фоне событий последних лет и ряда громких кейсов пришлось как минимум призадуматься. Можно вспомнить историю крупнейшего испанского банка Santander, у которого вся аналитика была в облаках, и всю базу клиентов унесли из-за одной ошибки. Многие после этого осознали, как легко можно потерять все свои данные. В Индии, Индонезии, странах БРИКС это поняли гораздо раньше. А во многих странах Юго-Восточной и Средней Азии предприятиям ряда отраслей, например, банкам и телекому, законодательно запрещено хранить данные пользователей в облаках.

В России никогда и не было таких возможностей в облаках, как за рубежом, да и стремления к ним тоже. У нас предпочитают сохранять контроль над своими данными.

CNews: Как будет развиваться ситуация на нашем и зарубежном рынке в ближайшие годы?

Николай Голов: За рубежом сейчас классический «красный океан». Между несколькими решениями — Snowflake, Databricks, BigQuery — идет жесткая борьба, в которой выиграть можно, только что-то отобрав у конкурента. В основном соревнуются на поле ИИ, так как это единственное, что может дать какие-то отличия и преимущества.

У нас появляются OpenLakehouse-решения, такие, как наша аналитическая платформа Tengri Data. Сейчас она ориентирована на развертывание on-premise, потому что мы видим в этом наибольшую незакрытую потребность рынка. Но мы планируем запустить и SaaS-версию, чтобы Tengri Data была доступна в облаке. Прямо сейчас облачный вариант у нас работает в рамках пилота. Очень удобно: ввел логин, пароль, и можно пользоваться.

CNews: Что изменили в аналитике больших данных LLM- и ИИ-агенты?

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

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

CNews: Чего сейчас хотят заказчики для решения аналитических задач? Что вы назвали бы в числе самых критичных потребностей и запросов рынка?

Николай Голов: Сегодня почти любой компании, нужны аналитики. А им, в свою очередь, нужен инструмент, с которым они могли бы работать. Первая критичная проблема состоит в том, что сейчас одного инструмента не существует. Для каждой отдельной задачи нужен свой, а задач — целый список. И получается, специалисту, чтобы делать простую вещь — проводить аналитику, требуется целый технологический мегаполис.

В какой-то мере эту задачу можно решить за счет open-source и платных решений. Но возникает следующая сложность — это небыстрый процесс. Реализация проекта даже при участии компетентных дата-инженеров (а их мало) может занимать годы. После внедрения встает еще один вопрос — как масштабироваться. Начиная с какого-то момента, кратный рост становится невозможным. Аналитическая инфраструктура целого ряда российских компаний дошла до точки, после которой вертикально (увеличивая сервер) масштабировать ее не получится, а добавлять сервера невозможно технологически.

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

CNews: А если говорить об опциональных, некритичных запросах? Чего хотят заказчики, когда главные проблемы решены?

Николай Голов: Из некритичных это обычно ИИ. Но технологии на основе ИИ очень сложные. И неочевидно, какие из них работают, какие пока еще нет. Когда компания пытается внедрить искусственный интеллект своими силами, часто возникает ситуация, когда ИИ — это не вишенка на торте, а вершина сложной платформы, где в основе — хранение данных, затем обработка и описание, следом простейшие рассуждающие агенты, дальше более сложные. И не построив эту пирамиду, нельзя получить верхушку, при том, что изначальный запрос именно на нее. Это одна из задач, которую решает Tengri Data, потому что у нас встроенные ИИ-агенты уже есть.

CNews: Какие еще запросы рынка закрывает платформа Tengri Data?

Николай Голов: Мысль о ее разработке возникла, когда, консультируя ряд крупных продуктовых сетей по теме построения хранилищ, я столкнулся с нехваткой инструментов на рынке БРИКС. Параллельно я работал с западными компаниями и видел, что весь мир в области аналитических инструментов идет в сторону двух решений: Snowflake или Databricks. И подумал: а можем ли мы сделать наши собственные Snowflake и Databricks, только не облачные, а те, которые можно разворачивать в своей инфраструктуре.

Tengri Data построена на парадигме разделения Compute и Storage. Этот подход изобрели десять лет назад, а сейчас мы приходим к пониманию, что аналитические платформы другим способом строить неразумно. Старые базы строились с совмещением Compute и Storage. И что же происходило? Больше данных или больше пользователей — нужно увеличивать всю систему, при том, что ее части принципиально не масштабируются. Любая потребность в мелком увеличении приводила к необходимости увеличивать все в совокупности. Разделение Compute и Storage позволяет делать очень простую вещь. Скажем, если нам нужно хранить вместо 10 терабайт, 50 терабайт, мы увеличиваем кластер хранения за счет нескольких машин с большими дисками. Часть Compute не меняется. Точно так же отдельно мы можем увеличивать вычислительную часть. Каждый компонент масштабируем независимо от другого. Это фантастически удобно, и именно поэтому с современными решениями так комфортно работать. Они расширяются бесшовно и без дополнительных усилий.

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

Помимо этого, в Tengri Data есть возможность выполнять код на Python, запускать оркестрации, визуализировать данные, напрямую обращаться к ним и скачивать их. Есть возможность применять модели машинного обучения. Все необходимые модули в Tengri Data уже интегрированы. Кроме этого инструмента, аналитикам больше ничего не нужно. Они могут поставить дополнительные, если захотят. А могут и не ставить.

Так мы закрываем проблемы с внедрением и масштабированием. Проблему с порядком в данных Tengri Data тоже решает. Во-первых, она во многом организационная. Тут мы можем помочь на уровне консалтинга. Технологические препятствия мы тоже по максимуму убираем: с Tengri Data нет необходимости собирать несколько технологических платформ в одну экосистему. За счёт того, что расчеты производятся в единой системе, она может анализировать зависимости SQL-расчетов друг от друга, строить граф зависимостей витрин с показателями и выполнять перерасчеты.

Разрабатывая Tengri Data, мы смотрели на этот инструмент не как дата-инженеры или разработчики баз данных, а прежде всего как аналитики. Я и ключевые люди в моей команде сами были аналитиками. Знаем, как они работают, что им нужно. Они не работают в таких базах, как Greenplum. Их привычная среда — это SQL и Python. Чтобы поддержать этот принцип, мы открыли пользователям нашего решения возможность писать SQL-код на PostgreSQL и Python стандартного формата. Но подумали: а что, если аналитики компании не очень хорошо знают SQL? Или Python? И тут приходит ответ в виде ИИ-агентов. Сейчас не обязательно знать SQL и Python досконально, чтобы писать их самостоятельно. С этим отлично справляются ИИ-агенты. И такой агент — не замена аналитика, а его младший коллега, с которым они в чате общаются и обмениваются результатами. ИИ-агент просто помогает аналитику продвигаться вперед быстрее, чем если бы он работал самостоятельно.

CNews: Есть ли у Tengri Data принципиальные отличия от других решений, представленных на рынке, и если да, то в чем они заключаются?

Николай Голов: В отличие от классических MPP-систем (ClickHouse, Greenplum и его различные форки), где вычисления и хранение неразрывны, мы полностью разделяем Compute и Storage. Это даёт беспрецедентную гибкость: позволяет масштабировать ресурсы независимо, снижать затраты и легко справляться с ростом количества аналитиков и данных.

Мы уходим от ограничений классических СУБД (PostgreSQL, Oracle, MySQL): Tengri Data не привязан к одной машине. Можно начать с одного узла — и безболезненно масштабироваться до десятков, когда данные вырастут.

В отличие от других решений в парадигме Lakehouse всё работает «из коробки». Никаких месяцев, потраченных на интеграцию open-source компонентов, не нужно — один пакет, одна установка, и можно анализировать данные.

Tengri Data опирается на новые парадигмы, которые позволяют многое делать легко и комфортно для пользователей.

CNews: Как планируете дальше развивать платформу?

Николай Голов: Мы сейчас на этапе, который называем третьей фазой. На первой мы полностью поддержали SQL. На второй — Python. Теперь завершаем реализацию платформы базовых агентов, помогающих писать SQL, работать с Python, поддерживать диалог с аналитиками в чате.

Дальше мы планируем двигаться в сторону стриминга, поставки данных в режиме реального времени прямо в Tengri Data, без шин. Также, как я уже упоминал, мы планируем предложить SaaS-версию с облачным развертыванием, которая будет удобна небольшим компаниям.

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

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

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

Подобные дата-сервисы актуальны в огромном количестве отраслей. Сейчас их реализация — это большая инженерная работа. Такого рода конструкции собирают из аналитической базы плюс Clickhouse, Redis, множество микросервисов на Python и так далее. Эту работу могут себе позволить только крупные компании. А внутри аналитической платформы это очень удобный инструмент, что мы и видим на примере ряда лидирующих облачных компаний на Западе, той же Databricks, которая пытается это реализовать с технологией Lakebase.

И здесь открываются перспективы в том числе с точки зрения развития технологий машинного обучения. Если дата-сервис пишет человек, он может решить технологические проблемы, о которых мы говорили. А что, если мы попросим ИИ сгенерировать дата-сервис по словесному описанию? Сможет ли он это сделать? Да, но не сможет его задеплоить.

Он напишет код, но дальше этот код нужно развернуть на базе, подключить, дать доступы. Снова начинается работа инженера, и мы снова теряем в скорости. А если дать ИИ написать код и автоматически запустить систему прямо в платформе, то возникнет возможность создания дата-сервисов агентами. Это позволяет очень быстро и гибко построить интеллектуальную систему.

Еще один пример. Дата-сервис может быть простейшей формой для ввода данных контрагентов. Обычно для этого используют Excel или Google-таблицы. ИИ отлично может писать такие приложения: и бэкенд, и фронтенд. Только не может их задеплоить. И если развернуть их внутри платформы, получится интегрированная форма, которая актуализирует определенные данные. Очень многие клиенты этого ждут и будут рады такими возможностями воспользоваться.