Data Engineering *

This is a hands-on case study of migrating Trip’s UBT from ClickHouse to StarRocks with storage–compute separation. By redesigning partitioning, enabling DataCache and MergeCommit, and backfilling history via SparkLoad, we reduced average query latency from 1.4 s to 203 ms, P95 to 800 ms, cut storage from 2.6 PB to 1.2 PB, and decreased node count from 50 to 40. We detail Compaction tuning, partitioned materialized views, and second‑level elastic scaling without data migration, and compare gohangout vs. Flink in reliability and operability. The article targets data engineers and architects running high‑load real‑time OLAP workloads.

Статья объясняет, как StarRocks 4.0 делает запросы к JSON почти столь же быстрыми, как к нативным столбцам. FlatJSON на этапе загрузки «колоннизирует» частые поля и задействует индексы (включая ZoneMap), словарное кодирование и Global Dictionary, а также Late Materialization. В результате логовая, e‑commerce и IoT‑аналитика работает в реальном времени без тяжёлого ETL.

StarRocks 4.0: Real‑Time Intelligence on Lakehouse. Сквозная оптимизация конвейера в реальном времени, 3–15× ускорение JSON, SQL Plan Manager, Decimal256 и поддержка Apache Iceberg для нативной Lakehouse‑аналитики.

Вчера мой скрипт завис. Процессор горел на 100%. Я убил процесс.

Я Senior Developer с 10 годами опыта. Пишу на Python, знаю Java и много модных фреймворков. Но в этот момент я понял: я не умею программировать. Точнее, я умею использовать инструменты. Но я не понимаю природу вычислений.

Эта статья — о том, как одна математическая задача изменила моё понимание разработки.

И почему через пару лет, когда ИИ будет писать весь код за меня, это понимание станет единственным, что меня спасёт.

Возможно, и тебя тоже.

На SOC Forum у нас стоял гоночный симулятор Assetto Corsa — и мы решили сделать его не просто развлечением, а полноценным источником аналитики.

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

Рассказываю, как устроена телеметрия AC, как собрать её в режиме реального времени и зачем всё это понадобилось.

Недавно мои коллеги-разрабы в чате удивились: зачем в архитектуре агента (ENA) нужен слой SOMA, симулирующий соматику и ресурсность? Мол, это рудимент как аппендицит и неэффективно. Агент должен быть в always-on и постоянно на позитиве.

Давайте разберем, зачем.

Привет, Хабр! Я Дмитрий Смотров, тружусь бэкендером в Astra Linux в команде продукта ACM — микросервисной системе, разворачиваемой на клиентских мощностях. Мы позволяем удаленно управлять клиентской инфраструктурой. Сначала я разрабатывал функциональность снятия инвентаризации и удаленного выполнения команд установки и удаления ПО, но в один момент моя жизнь резко изменилась. На проекте возникла необходимость в функциональности красивой и настраиваемой отчетности, в чем я увидел возможность проверить себя в новой для себя области. Я вызвался разобраться и помочь продукту стать еще лучше.

Под катом расскажу о том, с какими трудностями столкнулся в процессе, как я их решал и что в итоге получилось. Приятного чтения :-)

Привет, сегодня я расскажу о том, как наша команда строила платформу обработки и хранения данных для обучения GenAI-моделей в Сбере, и как мы выросли до 70 ПБ сырых данных. Меня зовут Александр, я работаю в Сбере и два года занимался развитием этой платформы.

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

Как защитить свои данные и психику в сети

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

Команда Python for Devs подготовила перевод статьи Клауса Вилке о том, почему Python, несмотря на статус языка №1 в data science, вовсе не идеален для анализа данных. Автор показывает на реальных примерах из лабораторной практики, что многие операции в Python оказываются куда более громоздкими, чем в R, — и это не вина программистов, а архитектурные особенности инструментов.

Привет! Меня зовут Андрей, я Data Engineer в компании GRI. Мы занимаемся заказной разработкой, и один из наших ключевых клиентов — Sunlight. Я расскажу, как не тратить время на рутину в процессах и автоматизировать всё, что только можно. Это будет особенно актуально тем, кто в компании solo Data Engineer.
 

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

Привет, я Саид Джабаров, системный аналитик в Далее. Сегодня расскажу и покажу на артефактах, как построить event-driven систему с гарантией доставки и прозрачным мониторингом. Так, чтобы она действительно помогала бизнесу, а не усложняла его.

внутренняя структура, репликации и балансировка, бакетизация и партиционирование, восстановление и MVCC, загрузка данных (Stream Load). Разбираем типичные сценарии и даём рекомендации для Data Engineers и DBAs.

Первая часть - https://habr.com/ru/articles/970614/

Но это отдельная история. Когда ты пытаешься решить сложную задачу, ты придумываешь, как языковая модель становится из самой цели сделать модель побольше, становится инструментом для создания мультиагентной системы. И на самом деле тут много новых инструментов появляется, как раз связанных с тем, что необходимо действительно писать достаточно сложный код. И в мае этого года вышла статья Alpha Evolve от компании DeepMind, которая показала, что большая языковая модель может на самом деле сама писать код и решать задачи, если ты можешь проверить решение этой задачи.

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

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

Дальше применяешь достаточно хитрые подходы, связанные с эволюционными алгоритмами, где фактически в качестве оператора мутации выступает большая языковая модель. У нее есть опыт предыдущий, память. в виде программы результатов, есть некоторые инсайты, что она придумала, и ее задача состоит в том, чтобы эти инсайты, соответственно, объединять в новые программы. Собственно, первый автор статьи «Альфа Эволф» Саша Новиков – это мой аспирант, который уехал довольно давно, но тем не менее очень много не менее талантливых людей работают в институте.

Я распечатал доклад, стараясь не поломать авторскую речь и мысль. Но всё таки доклад не читался, а произносился по памяти и слайдам, поэтому несколько слов убрал или заменил. Доклад на полчаса, выложу в двух частях.

Представление - Доктор физико-математических наук, профессор РАН, генеральный директор института Айри, декан факультета искусственного интеллекта МГУ Иван Оселедец с докладом «Успехи и проблемы больших языковых моделей».

Дальше говорит Оселедец.

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

Если переходить к докладу, то недавно вышло интервью Андрея Карпаты. Очень интересный, кто не видел, посмотрите. Полтора часа, и не суммаризация . Много интересных мыслей. Одна из мыслей, за которую я так зацепился, которая была не очень очевидна.

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

Привет, Хабр! Недавно у меня появилась задача - собрать RAG-систему для интернет-энциклопедии. В поисках решения я вышел на новый подход к гибридному RAG - “DAT: Dynamic Alpha Tuning for Hybrid Retrieval in Retrieval-Augmented Generation” (Динамическая настройка Альфа-параметра для гибридного поиска в RAG). 

Поиск по Хабру и Рунету показал, про подход DAT на русском языке еще не рассказывали, поэтому спешу поделиться находкой с вами и обсудить преимущества и недостатки этого метода. Эта статья - упрощённый пересказ научной работы. Материал будет интересен как продвинутым, так и начинающим разработчикам RAG-систем.

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

А что на счет самих данных, если мы их рассматриваем как продукт? Как будем оценивать их ценность, как будем планировать их развитие?

В статье предлагаю экспериментальный набор UX‑метрик: они помогут увидеть, где ваш продукт реально теряет пользу для пользователя. Методика готова к тестированию — цифр пока нет, но каркас для расчётов уже работает.

Кейс Hello: миграция 100+ млрд строк с ClickHouse на StarRocks. Как ускорить аналитику в 5 раз, снизить расходы на инфраструктуру на 80% и построить real-time DWH. Разбор архитектуры, самописных инструментов валидации и подводных камней перехода.

Я пришел в Data Science не сразу. Учился в магистратуре по вечерам, работая в совершенно другой сфере (строительство). Осваивать машинное обучение и анализ данных было интересно, но один из самых неожиданных вопросов, который возник буквально сразу - в какой среде писать код?

На первый взгляд кажется, что Jupyter Notebook, Google Colab, Kaggle и сравнительно новая Marimo - это одно и то же, ноутбук с ячейками и Python (так же поддерживаются другие языки программирования). Но на практике каждая из этих сред подходит для разных задач, где-то удобнее учиться, а где-то работать командой.

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

Статья будет полезна: