Data Engineering *

(версия статьи актуальна на 26 июня 2025 года)

OpenAI за несколько лет превратила ChatGPT из экспериментального проекта в полноценного цифрового помощника, который умеет не только писать тексты, но и думать, видеть, слышать и даже спорить. Это стало настоящим поворотным моментом в истории ИИ и индустрия вошла в новый цикл развития. Появились тысячи приложений на базе LLM, десятки компаний сменили стратегию, а работа с языковыми моделями стала повседневной реальностью.

Новые версии выходят регулярно, и если вы чувствуете себя потерянными в этом потоке, то вы не одиноки. Мы специально подготовили этот материал, чтобы рассказать обо всех ключевых GPT-моделях и сопутствующих инструментов OpenAI, чем они отличаются и какую из них выбрать для своих задач.

Привет, Хабр! Меня зовут Никита, я руководитель команды разработки умного поиска на основе генеративного AI в Just AI. В этой статье я расскажу о нашем опыте в умный поиск — как от mvp RAG-сервиса для Q&A бота нашей службы поддержки мы пришли к облачной платформе Jay Knowledge Hub (сокращенно KHUB), которая помогает нашим клиентам автоматизировать поиск по различным источникам знаний.

Недавно перед нашей командой встала непростая задача: объем данных для аналитики вырос до 300 миллионов строк в день. Прежние решения перестали справляться с такой нагрузкой, отчеты строились слишком медленно, а масштабировать существующую систему было дорого и сложно. Нужно было срочно находить новое решение для хранилища данных (DWH), способное глотать миллионы строк ежедневно и отдавать результат аналитических запросов практически мгновенно.

После оценки различных вариантов (классические СУБД, облачные DWH и др.) мы остановились на ClickHouse. Эта колоночная база данных открытого кода изначально создавалась для работы с большими объемами потока событий. ClickHouse славится впечатляющей скоростью агрегаций и фильтрации на терабайтах данных и отлично подходит для аналитики при больших нагрузках. В этой статье расскажем, как мы выбрали и внедрили ClickHouse в нашем проекте, построив систему сбора и анализа данных с нагрузкой сотни миллионов строк в сутки.

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

LLM-агенты — отстой. Я провёл последнюю неделю, разрабатывая LLM-агента с возможностью веб-краулинга, используя популярный Python-фреймворк, чтобы собирать информацию о потенциальных лидах из интернета. Результат оказался полным разочарованием.

Агент оказался медленным, нестабильным и с огромным числом багов (звучит знакомо? Передадим привет OpenAI!). Он постоянно делал ненужные вызовы функций, а иногда намертво застревал в бесконечных петлях "рассуждений", которые не имели никакого смысла. В итоге я на это забил и заменил его простым web-scraping скриптом, на написание кода которого у меня ушло 30 минут.

Привет Хабр! Меня зовут Кучеров Андрей и я Lead Data Engineer с более чем 7-летним опытом в области распределенной обработки данных. Я работал над оптимизацией высоконагруженных Spark-приложений в X5 Retail Group и билайн, где мы обрабатывали петабайтные объемы данных. Регулярно сталкиваясь с производительностью запросов, я убедился, что понимание работы Catalyst — необходимый навык для каждого Data Engineer, работающего со Spark.

Привет, Хабр! Я, Мадаров Артур, руководитель дирекции процессов эксплуатации и ИТ-услуг Страхового Дома ВСК. Недавно мы с командой произвели реинжиниринг процессов контроля качества ИТ поддержки. Хотим поделиться нашим опытом.

Предпосылки изменений

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

Если вчера процессы контроля качества в поддержках разного уровня, различных контактных центрах выстраивались вокруг выборки обращений до1–2% обращаемости, их оценке по критериям чек-листа и включению результирующей оценки в KPI, то сегодня фокус на оценке качества обслуживания клиентов требует глубокого анализа направлений поддержки, автоматизированных инструментов по оценке и контролю, внедрения технологий по анализу 100% обращаемости.

Хабр, привет! Современные высоконагруженные системы требуют точной настройки и регулярного мониторинга, чтобы обеспечить стабильную производительность в условиях постоянно растущих объёмов данных. Когда речь идёт о крупной аналитической базе данных, развёрнутой в облачной среде, оптимизация её работы становится критически важной задачей. В прошлой статье мы уже рассказывали о типичных ошибках при работе с Arenadata DB (ADB), о том, как их избежать и значительно повысить производительность кластера. Сегодня же поделимся реальным опытом на примере компании «Комус» — лидера в области B2B-ритейла, которая обратилась к Arenadata за проведением комплексного аудита своего кластера ADB.

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

Привет, Хабр! На связи Александр Бобряков, техлид команды МТС Аналитика. Это мой одиннадцатый пост про Apache Flink. В предыдущей части мы рассмотрели сериализацию данных во Flink, написали сериализатор, поддерживающий эволюцию схемы для Flink-состояния в операторе на основе Jackson.

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

Весь разбираемый исходный код можно найти в репозитории AlexanderBobryakov/flink-spring. В master-ветке представлен итоговый проект по всей серии. Этот материал соответствует релизной ветке с названием release/10_test_JacksonStateSerializer.

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

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

Например, вопрос «Какое имя было дано сыну человека, который победил узурпатора Аллектуса?»

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

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

Для эффективной работы системы был использован современный технологический стек. Обработка данных осуществлялась с помощью MongoDB, что обеспечило хранение и управление большими объёмами неструктурированной информации. RabbitMQ организовал асинхронный обмен сообщениями между компонентами системы, а серверная часть приложения разрабатывалась на базе Spring Boot, что ускорило процесс разработки и упростило развертывание приложения. Контейнеризация с использованием Docker обеспечила удобное развертывание и масштабирование системы. Основными языками программирования стали Java 17 и Python: Java использовалась для серверной части и микросервисов, а Python — для анализа данных и построения алгоритмов обработки информации.

Для анализа данных применялись библиотеки Pandas, Seaborn и SciPy, которые обеспечили эффективную обработку данных и визуализацию результатов. В рамках анализа строились графики, отображающие популярность жанров, исследовалась корреляция оценок на Кинопоиске и IMDb, а также визуализировалась связь между бюджетами и кассовыми сборами. Для представления результатов применялись такие инструменты, как matplotlib и seaborn, позволяя визуализировать ключевые закономерности в виде графиков и диаграмм.

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

С появлением цифровых данных в 90-е годы строительная отрасль начала активно трансформироваться. Компьютерные технологии стали внедряться в процессы проектирования, управления и строительства, что привело к появлению таких концепций, как САПР (системы автоматизированного проектирования), PLM (управление жизненным циклом) и, позже, BIM (информационное моделирование зданий). 

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

Привет! Я Николай, аналитик во ВкусВилле, я запустил и поддерживаю проект по каталогу данных в ВВ. 

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

Сделали каталог своими руками, как подошли к этому вопросу и что получили в итоге —расскажу в этом материале. 

Наш заказчик столкнулся с реальной проблемой, когда из-за использования устаревшего ETL-инструмента StreamSets оказался в ситуации, в которой его система начала давать сбои, а это напрямую влияло на финансовые результаты. Мы решили помочь, организовав миграцию на более современное решение — Luxms Data Boring.

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

Тема преимуществ открытых табличных форматов при работе с озерами данных всё чаще поднимается в среде дата-инженеров. Предполагается, что их использование способно устранить недостатки популярного Apache Hive. Но так ли это на практике?

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

В этой статье я расскажу про личный опыт написания шахматной программы на языке TypeScript. С какими проблемами столкнулся и пути к их решению :-)

На исторических данных за 1991-2019 год покажем, как можно "увидеть" и "выцепить" признаки переворота.  С помощью машинного обучения и ансамблевых модели. Ансамбли (конечно, не музыкальные), как показывает практика, – более эффективны в таких делах, и самое главное -  хорошо "тюнятся" и "чипуются".

*Nota Bene (та Bene, что ни разу не гессерит). При всем негативном отношении к революциям, переворотам и прочим событиям в любой части мира, это – объективная реальность, которую можно не только изучать, но и предупреждать.

Привет всем!

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

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

P.S. Если автор что-то не разобрал и не написал, значит он посчитал это не обязательным в рамках этой статьи :-)

Будем разбирать примеры на такой небольшой таблице, где указана прибыль (net_profit) компании на каждый месяц в рамках одного года.

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

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

В самом начале проекта Manus перед нашей командой встал ключевой вопрос: обучать ли end-to-end агентную модель, используя open-source foundation-модели, или же строить агента поверх возможностей in-context learning у frontier models?

В моё первое десятилетие в NLP у нас и выбора-то такого не было. В далёкие времена BERT (да, прошло уже семь лет) модели приходилось fine-tune'ить и тестировать, прежде чем они могли переноситься на новую задачу. Этот процесс часто занимал недели на одну итерацию, даже при том, что тогдашние модели были крошечными по сравнению с сегодняшними LLM. Для быстроразвивающихся приложений, особенно на этапе до PMF, такие медленные циклы обратной связи — смертный приговор. Это был горький урок из моего прошлого стартапа, где я обучал модели с нуля для open information extraction и семантического поиска. А потом появились GPT-3 и Flan-T5, и мои внутренние модели стали не актуальны буквально за ночь. Ирония в том, что именно эти модели положили начало in-context learning — и открыли совершенно новый путь развития.

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

Тем не менее context engineering оказался далеко не тривиальным делом. Это экспериментальная наука — и мы перестраивали наш агентный фреймворк четыре раза, каждый раз находя более удачный способ формировать контекст. Мы с любовью называем этот ручной процесс перебора архитектур, подбора промптов и эмпирических догадок «Stochastic Graduate Descent». Это не изящно, но работает.

В этом посте я делюсь локальными оптимумами, к которым мы пришли через собственный «SGD». Если вы создаете своего AI-агента, надеюсь, эти принципы помогут вам сойтись к решению быстрее.