Big Data *

В стремительно развивающемся мире искусственного интеллекта большие языковые модели (LLM) стали мощными инструментами, способными понимать и генерировать текст, близкий к человеческому. По мере роста их сложности и масштаба критичной становится эффективная организация путей обработки. Маршрутизация LLM — это стратегическое распределение и оптимизация вычислительных ресурсов внутри таких систем. По сути, это выбор того, каким путём проходит входной текст через различные компоненты/ветки, чтобы получить максимально точный и релевантный результат. Умно направляя промпты и балансируя нагрузку, маршрутизация повышает эффективность, отзывчивость и общую производительность языковых моделей.

Apache Iceberg — табличный формат для озёр данных с поддержкой ACID, Schema Evolution, Hidden Partition и версионирования, но при больших метаданных и работе через S3 страдает планирование запросов и латентность. В связке со StarRocks мы показываем, как распределённый Job Plan, Manifest Cache, CBO с гистограммами, Data Cache и материализованные представления выводят lakehouse‑аналитику на уровень DWH: снижают накладные расходы на метаданные, ускоряют планы и выполнение, а запись обратно в Iceberg сохраняет единый источник истины. Разбираем архитектуру Iceberg, типовые узкие места и практики оптимизации на StarRocks 3.2–3.3, включая кейс WeChat/Tencent.

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

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

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

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

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

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

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

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

По данным Gartner, до 70-80% BI-инициатив не достигают поставленных целей, доля активных пользователей не превышает 30-40% количества лицензий, а аналитики тратят половину своего времени не на инсайты, а на рутину. И главная причина этого фиаско кроется не в недостаточной производительности серверов, элегантности дашбордов и даже не в качестве данных. Проекты буксуют, а инвестиции не окупаются из-за людей: их привычек, страхов, устоявшихся ритуалов принятия решений и, как следствие, активного или пассивного сопротивления новым инструментам. В этой статье я расскажу о новом подходе, который позволяет системно подойти к вопросу работы с сопротивлением для CIO, CDO, руководители бизнес-функций, продакт-менеджеров BI и лидеров аналитики. В этой статье мы начнем знакомиться с системным, человекоцентричным подходом к преодолению сопротивления, который уже был неоднократно опробован на практике.

Разрабатывая 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) и сводные метрики.