Последние несколько лет я работаю в очень интересном проекте (как минимум, с программистской точки зрения). По правилам русского языка правильнее было бы сказать "работаю над проектом", но я не один, и даже не автор - просто разработчик, пусть и ключевой по некоторым модулям.

Итак, система бизнес-аналитики "Rapeed" (гуглибельно). Название небесспорное (у знающих наглицкий оно часто вызывает совсем не те ассоциации), но более подходящие были заняты, так что живём с этим.

История компании гуглибельна и весьма поучительна, я за процессом наблюдал изнутри (работал в "Полиматике" с 2012-го года, лично занимался внедрением в ФНС и в нескольких коммерческих структурах, позже у нас появились специально обученные внедренцы и за установкой в ПФР я приглялывал буквально одним глазком).

Как это выглядит снаружи - лучше почитать у других (на хабре есть пара статей). "Я пишу код" и на интерфейс мне смотреть тупо некогда.

Я пишу ядро. Тот самый "тензорный движок" или "распределённый in-memory OLAP", который не совсем олап и не чисто тензорный и совсем не обязательно "in memory".

У нас есть свой формат хранения данных на диске - вполне прямолинейный, но от этого не менее эффективный. За счёт столбчатой архитектуры (как у того же ClickHouse, например, и вообще это практически стандарт для любой бизнес-аналитики) и использования mmap() (отображение файла в память) получаем сравнительно высокие требования к дисковой системе, а в награду - прозрачную загрузку (нужные данные в оперативке, ненужные - на диске, но будут максимально быстро загружены немедленно, как понадобятся). За счёт очевидных оптимизаций получаем весьма компактное представление и высокую скорость работы.

У нас есть свой вычислительный движок. В отличие от "настоящих" СУБД (вроде того же ClickHouse, который используют под капотом очень многие другие системы бизнес-аналитики) у нас нет полноценной поддержки SQL - да практически вообще никакой нет. Зато у нас есть возможность напрямую вычислять всякие разные интересные штуки, которые через SQL пишутся довольно сложно, и всякие разные ОЧЕНЬ интересные штуки, которые через SQL не пишутся примерно никак. Собственно, именно поэтому в официальных презентациях движок и называется "тензорным", хотя на самом деле "всё не так однозначно" (тм).

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

Уже в "Полиматике" расчёты были очень быстрыми (порядка полуминуты-минуты на таблице в 400-500 миллионов строк), но она была монолитной, и уже 700-800 миллионов строк начинали тормозить (я сделал очень много для ускорения расчётов, но всё же время росло быстрее, чем линейно: может, то самое О(N*log(N)), может просто какая-то дробная степень чуть больше единицы - мы не замеряли и не анализировали), плюс требования к памяти росли тоже быстрее, чем линейно, и даже очень богатые сервера (2 Тб оперативки) рано или поздно переставали справляться. Очевидное решение - распределённые вычисления, несколько серверов в кластере, оркестрация, координация и много других страшных слов. Распределённые вычисления планировались к релизу в версии "Полиматики" 5.7, насколько я помню, но именно в тот момент всё и развалилось. Подробности я предпочитаю оставить за кадром, но сторону выбрал и из "Полиматики" ушёл (как и вообще практически вся команда разработчиков).

Возвращаясь к "Rapeed" - систему сразу проектировали как распределённую, от некоторых решений, хорошо себя показавших в "Полиматике", отказались, ибо они не масштабируются на распределённую систему, некоторые - творчески переработали. Что-то создали с нуля (тот самый кусок OLAP, на котором всё крутится). Разработка потребовала довольно много времени и огромного количества сил (и продолжает их отнимать). В результате, сейчас создана система, которая на большинстве операций сравнима по скорости с лучшими решениями на базе того же ClickHouse (что-то быстрее, что-то немного медленнее, но у нас есть кэширование, с самого начала заточенное под вычисления - и потому на повторных запросах мы оставляем ClickHouse далеко-далеко позади), при этом наша система умеет такое, что на базе классического SQL сделать нельзя (или совсем нельзя, или требует жесточайших ограничений на данные).

Буквально на прошлой неделе (середина октября 2026-го года - чтобы потом не путаться) была попытка провести прямое сравнение нескольких систем бизнес-аналитики, включая нашу, в "кругах Громова". К сожалению, полноценное сравнение провести не удалось - из-за хохлятских ударов дико вырос спрос на серверные мощности и многие наши конкуренты просто не успели прогнать полный сценарий. Мы - успели, так как "Rapeed" работает реально быстро, это было основной идеей с самого начала, ещё в С.М.А.Р.Т. (предшественник "Полиматики"). К сожалению, я (пока?) не могу озвучить точные результаты, но тезисно мы оказались кратно (в смысле, в разы) быстрее конкурентов, причём на некоторых операциях мы тратим меньше минут, чем они - часов.

Сейчас активно готовится релиз 2.0, основное направление - стабильность и совместная работа. Цель - одновременная работа 7000 пользователей (тысячу тянем уже давно и уверенно, но есть заметное пространство для оптимизации управления памятью). Сил всё это отнимает неимоверное количество, особенно, когда приходится переключаться между разными сложными задачами. Отдельный грустный момент лично для меня - довольно много всяких сравнительно небольших переделок, которые очень хочется все и сразу (ибо многие из них пересекаются тем или иным образом), но приходится по одной и по очереди, ибо времени на всё не хватает раз так в пять...

Отдельно хочу сказать про нейронки. Мы их используем в разработке весьма активно. При должной организации процесса получается кратное ускорение разработки. Ключевой момент - "чтобы задать правильный вопрос, необходимо знать половину ответа", то есть, чтобы правильно поставить задачу и потом проконтролировать результат необходимо хорошо представлять, о чём речь. Это сразу же и ответ на "да кому сейчас нужны эти программисты, я сейчас навайбкодю не хуже": ближайшие год-два - нет, не навайбкодишь, если не понимаешь, что там под капотом и как оно работает. MVP будет прям красивый-красивый, но на реальных объёмах данных всё очень быстро скатится ниже плинтуса (впрочем, если реальных данных реально мало, порядка единиц миллионов строк - то кое-как жужжать будет).

Не люблю разбрасываться словами "аналогов нет" или "лучший в мире". У "Rapeed" аналоги, безусловно, есть - это система бизнес-аналитики, их таких разных вагон и маленькая тележка (к слову, для некоторых людей почему-то стало сюрпризом, что OLAP-система является и системой бизнес-аналитики - а зачем ещё OLAP нужен?). Про "лучший в мире" - сложнее, ибо у каждого свои критерии и по-настоящему универсальные я не знаю (опять же, я смотрю на задачу исключительно с точки зрения кода, ибо, во-первых, в бизнес-аналитике не разбираюсь, во-вторых, мне некогда, мне хватает и кода), но у нас есть точные (никаких приближений даже близко нет!) и очень быстрые вычисления (как уже упоминал - в том числе, крайне сложные или вовсе невозможные на больших объёмах в терминах классического SQL).