Big Data *

Разрабатывая AI-консультантов и ассистентов на базе RAG-архитектуры, работающих с корпоративными базами знаний на русском языке, мы столкнулись с вопросом: какие открытые эмбеддинг-модели дают лучший баланс качества семантического поиска на русском и скорости работы. Особенно это актуально, когда запросы и документы русскоязычные, но внутри часто попадаются фрагменты кода/SQL и англоязычной терминологии.

Мы прогнали 9 open-source эмбеддинг-моделей через несколько тестов, включающих проверки:

Это вторая часть серии «23 фичи Luxms BI, которыми мы гордимся». В первой (прочитать можно здесь) мы говорили о платформенности и архитектуре — о том, на чём держится система.

А сегодня расскажем о базе, о функционале классической BI-системы, который и делает систему BI-системой.

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

Практический гид по быстрому запуску StarRocks Lakehouse с Apache Paimon. Вы узнаете, как построить единую пакетную и потоковую обработку (batch/stream) на базе ACID-хранилища с поддержкой schema evolution и Time Travel, разберетесь в моделях таблиц (Primary Key, Append, Append Queue) и стратегиях compaction. Пошагово настроим Flink, Kafka, Paimon и StarRocks, создадим топик и генератор данных, соберем Flink SQL‑пайплайн и выполним запросы из StarRocks, включая Read-Optimized и инкрементальное чтение.

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

Со временем всё изменилось: объём данных вырос в десятки раз, появились новые команды, и вместе с этим начали звучать вопросы вроде «где лежат данные для этого дашборда?», «кому писать, если он упал?» и «можно ли этим данным доверять?». Так мы поняли, что пора взрослеть — и искать инструмент, который поможет масштабировать не только инфраструктуру, но и дата-культуру.

Мы выбрали DataHub — open-source каталог, обещавший прозрачность, автоматизацию и гибкость. Развернули, подключили источники, построили lineage, и даже порадовались, что всё заработало с первого раза. А потом стало ясно: DataHub не заменил наш DataPortal. Более того, оба инструмента отлично дополнили друг друга — инженерное ядро и удобное окно в данные для бизнеса.

Почему два дата-каталога оказались лучше одного, как это повлияло на культуру работы с данными и что нам дал DataHub помимо красивых графов lineage — рассказываем под катом.

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

В поисках золотого клиента. Часть 1

Как найти своего «золотого» покупателя и, не прикладывая особых усилий, регулярно продавать ему товар? Уверен, этот вопрос занимает всех маркетологов. В свое время я тоже его решал. Я изучил немало исследований в области психологии, которые могут помочь в маркетинге, если мы говорим о персонализированном маркетинге, построенном на данных. Теперь я оказался по другую сторону баррикад. Мне нужно продвинуть свой товар маркетологам, а именно убедить их что инструмент, созданной нашей компанией CleverData (входит в холдинг LANSOF), умеет находить правильных клиентов для любого бизнеса. А самим маркетологам останется только пить кофе. И иногда отправлять нужные рассылки. Разумеется, сейчас вы все подумали об ИИ. Но нет. Это топливо для ИИ - сбор и обогащение данных о клиентах.

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

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

Импорт терабайтов из S3 одним SQL: INSERT FROM FILES и PIPE. Партиционирование через date_trunc(), RANDOM‑бакетизация, трансформации с JOIN/UNNEST и гибкий ALTER TABLE.

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

Привет, Хабр. Меня зовут Алексей Белозерский. Я руководитель профессионального сервиса VK Data Platform, VK Tech. В этой статье я расскажу, что стало предпосылкой появления нового формата данных и что скрывает Iceberg «под толщей воды».

В сегодняшней, уже третьей по счету, публикации я продолжу делится результатами нагрузочных испытаний вычислительных технологий массивных параллельных вычислений (на Habr уже представлены мои материалы, посвященные сравнению Impala, Trino и Greenplum, в том числе по методике TPC-DS). В этот раз в список решений добавляется Spark, включая работающий с технологией нативных вычислений DataFusion Comet, и набирающий популярность StarRocks.

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

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

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

«Широкие» таблицы

Путь поиска баланса между простотой, производительностью и гибкостью начинался с «широких» (их также называют «плоских») таблиц, где вся информация хранится в единой структуре. Это была эпоха простоты: достаточно одного запроса — и все двести атрибутов пользователя оказывались у вас в руках. Процесс извлечения данных был быстрым и интуитивно понятным, поскольку обходился без сложных соединений и подзапросов.

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

Задача: быстро выполнять агрегирующие запросы (JOIN, GROUP BY, COUNT) по десяткам миллионов строк в офлайновых сценариях на Big Data‑платформе. Мы сравнили три подхода: Parquet + Impala в экосистеме CDH, MPP‑движок Greenplum и MPP‑СУБД StarRocks. В единой тестовой среде (SAD ~7 млн, ITEM ~3 млн записей) выполнили серию запросов JOIN + GROUP BY + ORDER BY и замерили суммарное время 10 прогонов. Показано, что внедрение MPP заметно ускоряет аналитику (типично 1–2 с на запрос), при этом StarRocks в среднем немного обходит Greenplum. В статье — методика, параметры развертывания, нюансы импорта из Oracle (CloudCanal) и сводные метрики.

Это перевод классной статьи с детальным обзором архитектур главных опенсорсных LLM: очень структурировано, доходчиво и с изумительными картиночками. И такой обзор просто обязан быть на русском языке. Поговорим про DeepSeek V3/R1, OLMo 2, Gemma 3, Mistral Small 3.1, Llama 4, Qwen3, SmolLM3, Kimi K2, GPT-OSS, Grok 2.5, GLM-4.5, Qwen3-Next.

Ну а дальше слово автору:

Прошло семь лет с момента разработки оригинальной архитектуры GPT. На первый взгляд, оглядываясь назад на GPT-2 (2019) и вперед на DeepSeek-V3 и Llama 4 (2024-2025), можно удивиться тому, насколько структурно похожими остаются эти модели.

Однако я считаю, что все еще есть большая ценность в изучении структурных изменений самих архитектур, чтобы увидеть, чем занимаются разработчики LLM в 2025 году.

Близкая планета вызывает вспышки на звезде (Close-in planet induces flares on its host star)Authors: Ekaterina Ilin et al.Comments: 23 pages, 7 figures, 3 tables. Submitted to Nature 

Наблюдения на TESS и CHEOPS показали, что у молодого G-карлика HIP 67522, вокруг которого обращаются две планеты на низких орбитах, происходят вспышки, вызванные магнитным взаимодействием с одной из планет.

Вертикальная структура и динамика диска Галактики (Vertical Structure and Dynamics of a Galactic Disk)Authors: Chanda J. Jog Comments: 223 pages, 35 figures, 379 references. Invited review for Physics Reports  Большой обзор по структуре и физике галактического диска. На удивление мало формул (с полсотни, и больше половины из них - в 4м разделе), зато много полезных графиков. Приведено много данных наблюдений и разъяснены основные процессы, отвечающие за формирование структуры диска.

Сравнение ClickHouse и StarRocks: архитектура и функциональность, типы join и модели данных (широкая таблица vs звезда), конкурентность, частые обновления (Primary Key, Merge‑on‑Read), администрирование и онлайн‑масштабирование. Приводим результаты бенчмарков SSB и TPC‑H, а также тесты загрузки (GitHub dataset). Все тестовые данные и конфигурации актуальны на 2022 год. Если вам интересно, воспроизведите эксперименты по актуальным инструкциям проектов и поделитесь результатами и замечаниями — это поможет уточнить выводы и обновить сравнение.

Говоря о серьезных кластерах в компаниях, нам часто приходится взаимодействовать со сторонними отделами и их данными. И зачастую, когда речь идет об ad-hoc, самый эффективный инструмент - Trino. Он удобен тем, что в платформе данных можно добавить каталог, который позволит по сути избежать настройки коннекшена для конечного пользователя. Просто в запросе указываешь название каталога данных и трино сам понимает, что нужно взять данные со сторонней базы данных. Но все меняется, когда выразительности SQL нам перестает хватать для выполнения поставленных задач и мы переходим в Spark. Точнее, менялось. С релизом Spark 3.0 появилась возможность взаимодействовать с внешними источниками так же просто, как в Trino.

Одним из самых важных навыков любого специалиста по данным или ML инженера является умение извлекать информативные признаки из исходного набора данных. Этот процесс называемый feature engineering (инженерия признаков), — одна из самых полезных техник при построении моделей машинного обучения.

Работа с данными требует значительных инженерных усилий. Хотя современные библиотеки вроде scikit-learn помогают нам с большей частью рутинных операций, по-прежнему критически важно понимать структуру данных и адаптировать её под задачу, которую вы решаете.

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

Разумеется, feature engineering — это времязатратный, креативный и нередко утомительный процесс, требующий экспериментов и опыта.

Недавно я наткнулся на интересный инструмент — Upgini. Следуя тренду на использование Large Language Models (LLM), Upgini применяет GPT от OpenAI, чтобы автоматизировать процесс feature engineering для ваших данных.

Подробнее о python библиотеке Upgini можно почитать на GitHub странице проекта. У проекта уже 345 звездных оценок, что является показателем востребованности и полезности функционала.

👉 GitHub - upgini/upgini: Data search library for Machine Learning

Привет! Этот пост — перевод очень хардовой статьи про внутренности vLLM и того, как устроен инференс LLM. Переводить было сложно из-за англицизмов и отсутствия устоявшегося перевода многих терминов, но это слишком классная статья, и она обязана быть на русском языке! А дальше — слово автору:

От paged attention, непрерывного батчинга, кэширования префиксов , specdec и т.д. — до мульти-GPU и мультинодового динамического сервинга LLM под нагрузкой.

В этом посте я постепенно представлю все основные системные компоненты и продвинутые функции, которые составляют современную систему инференса LLM с высокой пропускной способностью. И детально разберу, как внутри работает vLLM.

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

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