Data Engineering *

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

В этой статье мы детально рассмотрим поведение аналитических движков при выполнении отдельного TPC-DS запроса на одном узле.

Это глубоко технический текст, в котором мы увидим, как (1) три родственных движка (Impala, StarRocks и Doris) с трудом справляются с конкурентной нагрузкой, (2) разработчики StarRocks и Doris затачивают дефолты своих движков под бенчмарки, (3) Trino реализует эффективный шедулер запросов, но имеет ряд дефектов, ухудшающих производительность, (4) Presto строит хорошие планы запросов, но демонстрирует катастрофически плохую производительность из-за отсутствия буквально одной фичи. Ну а победит, конечно, наш движок CedrusData.

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

Современные языковые модели (LLM) вроде GPT, LLaMA или Mistral обладают поразительной универсальностью. Они обучены на триллионах токенов из открытых источников и научились объяснять сложные вещи, поддерживать диалог в свободной форме и даже писать код. Однако при решении реальных бизнес-задач универсальность становится слабым местом: бизнесу нужны не «всезнающие ассистенты», а узкоспециализированные инструменты, хорошо понимающие внутренние процессы и терминологию.

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

Реальность такова: человеческие ревьюеры по-прежнему обеспечивают уровень контекстного понимания, которому ИИ пока не соответствует. Поэтому вместо того чтобы противопоставлять методы, многие в индустрии приходят к связке «LLM-судья + человеческая оценка» как к наиболее эффективной комбинации. В этой статье разберём, что такое LLM-судья, как он соотносится с человеческой оценкой и почему гибридный подход имеет наибольший смысл.

При пиковых нагрузках отчётные и аналитические системы сталкиваются с лавиной схожих агрегирующих запросов: растёт загрузка CPU и увеличиваются задержки. В StarRocks эту проблему решает Query Cache — кэширование промежуточных результатов агрегаций в памяти с их последующим переиспользованием. В реальных сценариях даёт 3–17× ускорение, работает для семантически эквивалентных запросов, перекрывающихся партиций и append-only данных. Внутри — лучшие практики, пример настройки и метрики диагностики.

Выпуск 448

Пределы космологии (The limits of cosmology)Authors: Joseph SilkComments: 23 pages, Gen Relativ Gravit 57, 127 (2025) 

Если вы думаете, что известный космолог-теоретик пишет про теорию, то вы ошибаетесь! Силк внезапно втопил за лунные проекты. И это не только низкочастотные радионаблюдения на другой стороне Луны, но и совершенно фантастические (очень дорого и сложно) проекты гравитационно-волновых детекторов (типа LIGO, Virgo) на Луне (там низкий сейсмический шум, и можно уйти на низкие частоты).

Радиопроекты могут быть реализованы в середине этого века. Гравволновые - точно нет. Но интересно, что Силк погружает все это в интересный и понятно описанный контекст космологических задач (отсюда и название статьи). Так что читать все равно интересно. Вот это и впрямь научная фантастика!

А еще… затронем ИИ и прочие захватывающие темы.

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

Представьте инженера по добыче на центральном объекте в Permian Basin (прим.перев. крупнейший нефтегазовый бассейн США), которому до рассвета нужно успеть десятки дел. Одна скважина работает ниже нормы. Для другой нужно принять решение о капитальном ремонте. Данные разбросаны по электронным таблицам, SAP, PDF‑документам и полевым логам. Знакомая ситуация? А теперь представьте, что у инженера есть помощник, который читает все файлы по скважинам, анализирует сигналы SCADA, понимает исторические тенденции добычи, проверяет наличие запчастей на складе, формирует рекомендацию и отправляет краткий отчет руководителю операций — ещё до второй чашки кофе.

В современных реалиях всё чаще встаёт вопрос о переходе с вендорских продуктов на open-source. Компании активно рассматривают DBT как стандарт для управления трансформациями данных, но сталкиваются с проблемами: существующие алгоритмы загрузки оказываются недостаточными, а адаптеры для СУБД - устаревшими.

В этой статье рассказываем о нашей доработке адаптера для DBT, который расширяет возможности работы с Greenplum и ClickHouse, добавляя новые стратегии загрузки, логирование и интеграцию с внешними источниками.

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

В данной статье я продемонстрирую подход к анализу и вычислению рекуррентных соотношений. В качестве примера будет представлена реализация на базе Apache Spark и Python метода экспоненциальной скользящей средней с использованием DataFrame API. Мы рассмотрим метод агрегации данных, совместимый со Spark Connect, который был добавлен в версию 3.1 (для Scala - начиная с версии фреймворка 3.0), а именно – функцию aggregate.

Привет! Меня зовут Стас, я занимаюсь R&D в компании ROGII.

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

Мы собрали 507 PDF‑файлов (всего 14 678 страниц) и выделили 23 типа отчётов по признаку компании и структуры.
Но традиционные подходы: ручной ввод, регулярки, rule‑based и классический NLP — оказались или неэффективными, или нежизнеспособными.
Тогда я обратился к LLM.

Эксперты Gartner дают краткие ответы на свежие вопросы клиентов о перспективных технологиях.

Фокус на принятии решений: когда инвестировать в агентный ИИ и DSLM, какие метрики измерять и как масштабировать без потери контроля.

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

Инструменты вроде OpenSearch, Elastic или Kibana давно стали стандартом для поиска и визуализации логов благодаря удобству и мощной поисковой системе. Однако, когда речь заходит о сложном анализе — агрегациях, парсинге, выявлении сложных закономерностей — их встроенные средства быстро достигают предела возможностей. Особенно сложно становится, если структура логов далека от идеала: например, как у нас — всё содержимое свалено в одно поле Message в формате JSON.

Меня зовут Игорь Щегловитов, я работаю экспертом по тестированию в QC облачной инфраструктуры и веб-порталов. Раньше наша команда решала такие задачи кастомными утилитами на C#, которые выгружали логи из ELK и анализировали их локально. Однако каждое новое требование превращалось в мини-проект: доработать код, написать новые парсеры, скрипты агрегации и фильтрации. Работа замедлялась, техдолг рос.

Я решил использовать связку AI-агентов с кастомными промптами, собственный сервисный слой (MCP) для доступа к логам и LLM-модель, чтобы превращать пользовательские запросы в автоматический алгоритм анализа. Так, кейсы вроде «Посчитай уникальных пользователей за сутки» или «Проанализируй ошибки за период» решаются без ручного кодинга.

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

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

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

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

Привет, Хабр! Я — Павел Лукьянов, системный архитектор и Deputy CTO в AGIMA. В этой статье по мотивам доклада с Saint HighLoad++  на примере одного из реальных кейсов с большим количеством внешних систем для сбора данных расскажу, как их собирать и обрабатывать, представлю готовые импортозамещённые инструменты для систематизации и хранения. Кроме того, покажу, почему не стоит заморачиваться из-за безопасности и по какой причине бизнесу важно следить за проектом в реальном времени и принимать решения.

Представьте: Один неоптимизированный запрос от неопытного коллеги - и вот уже 40 ТБ SPILL-файлов парализуют систему.

Срабатывает лимит на уровне Greenplum, запрос завершён. Никто ничего не знает.

Создаются заявки, пишутся письма, пользователь недоволен.

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

До сегодняшнего дня сборка и запуск AI-агентов напоминала джунгли. Разработчики метались между десятками несовместимых SDK, кастомных пайплайнов и ручных интеграций. Построить надёжного агента значило неделями клеить код, чинить баги в оркестрации и постоянно балансировать между скоростью и качеством. Теперь OpenAI предлагает другой путь — AgentKit, набор инструментов, который объединяет в себе всё, что раньше требовало десятков фреймворков и недель настройки.

Всем привет! Меня зовут Роман, и я хочу поделиться своим опытом сдачи экзамена AWS DEA-C01: Data Engineer Associate. Когда сам готовился, то много искал реальных отзывов и заметок о том, как проходит экзамен, как лучше всего готовиться и на что обращать внимание. Поэтому надеюсь, что мой опыт будет полезен.

Немного о себе: сейчас я учусь на дата-инженера, и уже через несколько месяцев завершаю программу обучения. Параллельно начал задумываться о будущем трудоустройстве и изучал доступные вакансии. Довольно быстро стало очевидно, что учебная программа и реальные ожидания компаний пересекаются не во всём: последние делают большой упор на облака.

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

Так у меня и появилась первая цель — подготовиться и успешно сдать экзамен DEA-C01.