Data Engineering *

Представьте инженера по добыче на центральном объекте в 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.

Привет! Меня зовут Влад, я DWH-инженер в Циан. Занимаюсь проектированием витрин и пайплайнов для доставки данных в корпоративное хранилище. В этой статье хочу поделиться опытом применения методологии Data Vault на Greenplum.

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

Запускаем на ноутбуке учебный кластер ClickHouse — шардированный (sharding) и реплицируемый (replication) — на Docker Compose.
Это не один сервер в контейнере, а стенд из 2 шардов × 2 реплики, с координацией через ZooKeeper и балансировкой HAProxy — поднимается за несколько минут.
Зачем: на практике разобрать репликацию и распределение по шардам, увидеть базовую отказоустойчивость и спокойно экспериментировать — всё в контейнерах, всегда можно снести и развернуть заново.
Кому: новичкам, кто хочет «пощупать» кластер; тем, кто знает базовый синтаксис ClickHouse, но не пробовал шардирование/репликацию; тем, кто готовится к собеседованию или приценивается к архитектуре перед продом.
В комплекте — готовые конфиги и docker-compose.yml в репозитории; всё, что нужно, — Docker и несколько команд.

В статье рассмотрен процесс предобработки текстов учебников для последующего анализа и обучения моделей машинного обучения. Показано, как из "сырого" текста, извлечённого из PDF, получить очищенный, структурированный и готовый к обработке набор данных. Основное внимание уделено этапам очистки текста от лишних символов, нормализации регистра, токенизации, лемматизации и удалению стоп-слов, а также POS-теггингу. Для каждого этапа приведены примеры с использованием Python и библиотек spaCy, re, а также альтернативные инструменты (NLTK, ftfy, clean-text). В качестве практического применения рассматривается проект EduText Analyzer, направленный на автоматизированный анализ учебников по иностранным языкам. Данные после предобработки сохраняются в форматах CSV и TXT, что обеспечивает дальнейшую обработку, анализ и обучение моделей. Статья предназначена для исследователей в области NLP, педагогов и разработчиков образовательных технологий.

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

Давайте признаемся: порог входа в Data Engineering довольно высок. И дело не только в знании SQL или Python. Настоящая боль начинается, когда ты пытаешься собрать на своей машине хотя бы простенький пайплайн.

Нужно поднять Kafka, рядом поставить Zookeeper (или обойтись Kraft, если ты хипстер), прикрутить Debezium для CDC, развернуть Spark для обработки, где-то хранить результат (привет, MinIO!), а потом всё это оркестрировать через Airflow и визуализировать в Superset. Каждый инструмент — это отдельный Docker-контейнер, своя конфигурация, свои порты и свои зависимости. Через пару часов борьбы с docker-compose.yml и сетевыми настройками желание учиться и экспериментировать улетучивается.

Знакомо? А что, если я скажу, что весь этот зоопарк можно поднять одной командой, и он просто... заработает?

Сегодня я хочу рассказать о проекте, который стал для меня настоящей находкой — Data Forge. Это готовая песочница для дата-инженера, или, как называет её автор, "Data Engineering Playground".

Наверняка многим знакома ситуация: у тебя есть куча данных, отчетов, KPI, а команда тонет в Excel‑таблицах и Jira‑тикетах. И вот тебе кажется, что решение простое: «Давайте посадим нейросеть на аналитику».

Я решил попробовать. И вот что из этого вышло.

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

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

Это был обычный понедельник. Я пил кофе, проверял почту, и вдруг — волна уведомлений в Slack. «Сайт не грузится!», «Отчеты зависли!», «Что происходит?».

Наш проект, который успешно работал с несколькими сотнями тысяч записей, перешагнул психологически важный рубеж — 10 миллионов строк в таблице заказов. И PostgreSQL, который раньше летал, внезапно начал ползти как улитка.

Всем привет! Сегодня рассмотрим, что из себя представляет Data Warehouse и зачем оно нужно вашему бизнесу.

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