Data Engineering *

Недавно стартовал необычный эксперимент — Alfa Arena, где шесть лучших LLM моделей (Claude 4.5 Sonnet, DeepSeek V3.1, Gemini 2.5 Pro, GPT-5, Grok 4 и Qwen 3 Max) соревнуются между собой в реальном трейдинге. Каждой модели дали по $10,000, и они торгуют криптой на бирже.

Что особенно интересно — это не просто шоу. Alfa Arena показывает принципиально новый подход в трейдинге. И хоть любопытно следить за тем, какая модель заработает больше денег или кто первый сольет, но настоящая ценность эксперимента совсем в другом.

MCP — это язык, на котором AI учится общаться с инструментами. Но если дать ему слишком много «слов», получится хаос. В статье можно узнать, почему MCP нужно курировать, где начинаются риски безопасности и как этот протокол помогает сделать взаимодействие с AI осмысленным и надёжным.

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

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

Взгляд с высоты птичьего полета

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

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

Рискуя прослыть занудой, хочу напомнить, что выражение «экономика данных», относительно недавно введенное в оборот скорее как мем, чем как строгое научное понятие, обозначает новый этап развития мировой экономики, следующий после аграрной экономики, промышленной экономики, постиндустриальной (сервисной) экономики, информационной экономики. И вот, настала очередь экономики данных. Также полезно будет держать в уме описание смены технологических переделов, которые характеризуются как революции. Все они называются промышленными революциями, только после каждой из них само понятие промышленности (индустрии) кардинально меняется. По этой шкале мы переживаем четвертую промышленную революцию, если все еще верить Клаусу Швабу, председателю Всемирного экономического форума в Давосе, который, после того, как прослыл изрядным женолюбом, покинул пост после полувека правления.

Эта статья была написана мной и опубликована в отраслевом научном журнале более четверти века назад, когда я работал в головном НИИ железнодорожной отрасли (ВНИИЖТ МПС) в должности заместителя заведующего лабораторией и занимался вопросами научно-методического обеспечения задач управления производственными процессами путевого хозяйства железных дорог России, автоматизацией функций и применением информационных технологий для нужд путевого хозяйства.

В статье рассматриваются вопросы управления техническим состоянием объектов путевого хозяйства с применением информационных технологий.

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

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

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

Электроэнцефалография (ЭЭГ) — это неинвазивный метод регистрации электрической активности мозга через электроды на поверхности головы. За последние годы ЭЭГ-данные перестали быть исключительно медицинской прерогативой и прочно вошли в мир data science. Сегодня их используют в нейромаркетинге для оценки реакций на рекламу, в когнитивных исследованиях для измерения внимания и памяти, в разработке Brain-Computer Interface (BCI) и даже в спортивной аналитике.

Автономный транспорт давно вышел за пределы закрытых полигонов и футуристичных историй. Он уже работает и приносит пользу бизнесу и людям. В России тягачи Navio два года возят реальные грузы коммерческих клиентов по трассе М-11 «Нева». А в США, Китае или Европе можно совершить поездку на роботакси. Тем не менее, восприятие технологии остается противоречивым. Видео, где автомобиль без водителя в салоне не может выехать с кольцевого перекрестка или воспринимает человека в майке с надписью STOP как команду к действию, усиливают скепсис и снижают доверие к результатам разработчиков. Почему компании, которые работают над технологией с 2009 года [больше 15 лет], не смогли добиться ее стабильной работы.

Классический подход в разработке автономного транспорта

Алгоритмический подход признан классическим в разработке автономного транспорта. Логическая архитектура построена на основе последовательности действий водителя за рулем:

восприятие окружающего мира — набор сенсоров (радары, лидары, камеры);

определение местоположения — карты, модуль позиционирования, сенсоры;

предсказывание действий других объектов вокруг — алгоритмы на базе кинематической составляющей и модели динамики объектов;

планирования пути — руководство к действию или свод правил, основанный на правилах дорожного движения (ПДД);

управление — модуль внутри автомобиля приводит его в движение. 

Этот код пишется 15 лет и никогда не будет завершен 

Несовершенность классического подхода обнаружилась на этапе планирования пути. При алгоритмическом подходе условия прописываются вручную (what-if сценарии). Автономное транспортное средство принимает решение на основе типа объекта (автомобиль, пешеход, др.), дальше добавляются такие условия, как состояние дорожного покрытия, погода, светофоры, другие объекты. Все это ведет к экспоненциальному росту проверок вложенных условий. Обладая достаточным парком автомобилей, за несколько лет разработчик может закрыть самые часто встречающиеся сценарии на дороге. Следующие несколько лет проездов выловят более редкие случаи и укрепят базу. Но остается открытым вопрос, что делать с уникальными ситуациями, как человек в футболке с надписью STOP или объездом препятствия в месте, где обгон запрещен разметкой. Невозможно вручную прописать все условия заранее, мир сегодня слишком непредсказуем. Такой подход не позволит масштабировать технологию и обеспечить ее стабильность на 100%, особенно в условиях города. Такая бесконечность сценариев называется Long Tail.

Практический гид по быстрому запуску 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 — рассказываем под катом.

Транзакции — не про «магическое ACID», а про конкретную механику согласованного доступа к данным под нагрузкой.

Эта статья объясняет как реально работают уровни изоляции и чем отличаются популярные СУБД на практике.

Мы разберём:

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

Привет, Хабр!

Четыре года назад, еще в институте, одним из моих первых серьезных проектов была простая LSTM-модель для прогноза погоды. Недавно, пересматривая старые наработки, я задался вопросом: насколько дальше можно зайти, применив накопленный за эти годы опыт и современные инженерные практики?

Эта статья — история такого "рефакторинга длиною в 4 года". Это рассказ о том, как простой академический проект был переосмыслен и превращен в полноценное End-to-End (E2E) решение. Цель — не просто снова предсказать погоду, а на практическом примере продемонстрировать системный подход к построению ML-пайплайна с нуля.

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

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

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

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

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

Импорт терабайтов из 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.

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

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

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

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