🚀 29 октября Arenadata проведёт техническую онлайн-конференцию ArenaTech
На ArenaTech инженеры Arenadata расскажут, как устроены продукты компании изнутри, поделятся опытом решения сложных инженерных задач и представят ключевые направления технологического развития.
🟢Основные темы конференции:
🔜СУБД: архитектура, развитие и эксплуатация. Обсудим планы развития Arenadata DB (ADB) и Greengage DB, новые возможности MPP-СУБД, включая hot standby, вопросы безопасности и устранения уязвимостей. Отдельное внимание уделим утилите ggrebalance, которая позволяет сокращать число сегментов кластера и заменять хосты с сохранением равномерного распределения данных.
🔜Платформа данных: безопасность и Kubernetes. Расскажем об управлении секретами и доступом в Arenadata Hyperwave (ADH) с использованием OpenBao. Разберём особенности переноса Impala, Trino и Spark в Kubernetes: интеграцию с Kerberos, разработку операторов, адаптацию Spark и использование Celeborn и YuniKorn.
🔜Техническая документация, поиск и ИИ. Поделимся опытом организации процессов разработки технической документации и расскажем, как создавались интеллектуальный поиск и ИИ-ассистент, упрощающие поиск информации в документации многокомпонентной платформы данных.
После каждого доклада участники смогут задать вопросы спикерам в рамках Q&A-сессии.
Конференция будет интересна разработчикам, дата-инженерам, администраторам СУБД, архитекторам, DevOps-инженерам и техническим руководителям.
Сегодня в редакции разбирали статью не про ИИ. Надо же иногда отдыхать. Хотя совсем без ИИ, как выяснилось, не обошлось.
Jane Street - одна из крупнейших трейдинговых компаний и маркет-мейкеров мира, известная ещё и тем, что почти весь стек пишет на OCaml. В блоге они рассказали, как переделывали индексацию во внутренней шине сообщений Aria. Через неё проходит несколько терабайт данных в день, клиенты подписываются на живой поток, а топиков в одном инстансе бывает около миллиона.
Задача по формулировке банальная: быстро отдавать клиенту только нужную ему часть потока, а не фильтровать всё подряд. Раньше Aria честно перебирала буфер линейно. И это было нормально: алгоритмически неэффективно, зато дружелюбно к кэшу процессора. Пока клиентов было мало. Потом серверы упёрлись в 100% CPU, а в одном инциденте восстановление клиента после перезапуска вместо 2,5 секунд заняло 13 минут: система читала в 10 раз больше данных, чем отдавала.
Что мы отметили для себя.
Первое. Лучшее решение даёт максимальная локализация задачи. Никто не искал «лучший алгоритм индексации вообще». Искали лучший алгоритм для конкретного профиля потребления. Индекс на каждый топик не взлетит - их миллион, поэтому индексируют группы топиков по двухуровневому префиксу. Отдельный ring buffer под каждый индекс съел бы память: при сообщениях по 32 байта худший случай даёт 2 ГБ на индекс, поэтому сделали общий пул блоков по 1024 записи. Хранилища на диске раньше резались по фиксированному правилу «первые три сегмента имени», теперь разбиение считается по реальному объёму: большой топик получает своё хранилище, мелочь складывается вместе. Каждое решение выведено из цифр своей нагрузки, а не из учебника. Итог: минус 30% CPU в реальных сценариях и исчезнувшие многосекундные хвосты задержек.
Второе. LLM здесь работал не как автор кода, а как ускоритель понимания. Когда узким местом оказалась min-heap, инженер не стал выбирать одну реализацию на глаз, а поручил агенту собрать пять вариантов и прогнать профилирование за ночь. Утром был ответ и двукратный прирост. Для выбора алгоритма разбиения он быстро навайбкодил веб-интерфейс, который показывал работу разных вариантов на реальных данных. То, что раньше означало недели чтения и ручных экспериментов, свелось к нескольким итерациям в удобной форме.
Вывод простой. ИИ не придумал за них архитектуру. Он сделал дешёвым то, на что раньше не хватало времени: перебрать варианты и увидеть их работу своими глазами. А архитектура по-прежнему рождается из точного понимания своей нагрузки.
Я думаю все обратили внимание на Jev и кажется что тема довольно перспективная для многих кейсов. Сам пока еще не добрался внимательно изучить, но вот кажется неплохая картинка с выжимкой.