Data Engineering *

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

Apache Kafka — один из самых популярных распределенных систем потоковой передачи данных. Исторически Kafka использовала Apache ZooKeeper для управления кластером, но с версии 2.8.0 появилась альтернатива — KRaft (Kafka Raft Metadata mode). 

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

И, чтобы статья была практико-ориентированной, мы рассмотрим примеры того, как можно поднять в Docker оба варианта кластера. 

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

В этой статье хочу поделиться нашим опытом интеграции с Kafka.

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

В какой-то момент в нашем КХД также появилась необходимость интеграции с Kafka.

При разработке первой интеграции мы пошли традиционным путем и использовали Kafka Connect для Confluent 6.0.1. Сообщения, читаемые коннектором, перекладывались в Hadoop. Далее в PySpark выполнялся парсинг нужных данных, и полученные пачки выгружались в Oracle Exadata.

Но на этапе опытно-промышленной эксплуатации у нас возникли проблемы с производительностью из-за большого объема читаемых данных: ~100-110 млн сообщений в час (поток со звонками абонентов). Также было требование от бизнеса - данные в конечной витрине должны появляться с задержкой не более часа. Оптимизация интеграции затянулась еще на пару месяцев.

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

Тем временем, перед нами встала задача разработки еще нескольких интеграций с Kafka.

Было очевидно, что требуется какое-то решение, которое не только ускоряло бы внедрение, исключая рутинную разработку, но и позволяло реализовать стандартную для таких интеграций батчевую выгрузку считанных сообщений в разные БД (Oracle/Hive/ClickHouse и в перспективе в Greenplum). И кроме того, умело выполнять предварительную обработку данных на лету (парсинг и трансформацию значений заданных атрибутов).

Привет, коллеги! Сегодня хочу поделиться с вами своими размышлениями о терминальном AI-агенте OpenCode и его сравнении с другими популярными решениями на рынке. После нескольких месяцев активного использования различных AI-инструментов для кодирования, могу с уверенностью сказать: OpenCode — это действительно что-то особенное.

TL;DR: Мы провели бенчмаркинг семи методов, направленных на предотвращение эмерджентного рассогласования и других форм некорректного обобщения с использованием ограниченного объёма alignment-данных. Мы демонстрируем устойчивый трейдофф между способностями модели и согласованием, подчеркивая необходимость более эффективных методов для снижения этого конфликта. Простое включение alignment-данных в микс обучающих данных оказывается недостаточным для предотвращения рассогласования, однако простое наложение KL Divergence penalty на alignment-данные показывает лучшие результаты, чем более сложные подходы.

Футбол больше не сводится лишь к интуиции и традициям. Теперь это соревнование за то, кто сможет эффективнее использовать данные. От продуманной трансферной стратегии «Брайтона» до работы Луиша Кампуша в ПСЖ — клубы всё активнее обращаются к продвинутой аналитике, чтобы опередить соперников. Это означает использование инструментов на базе искусственного интеллекта, машинного обучения и футбольных данных для более раннего поиска талантов, снижения рисков при трансферах и получения конкурентных преимуществ.

Компании активно внедряют у себя решения на основе больших языковых моделей: боты техподдержки, умный поиск по базе знаний, выявление мошенников в диалоге или HR-ассистенты.

Но самостоятельно вывести модель в полноценное продакшн-использование не так просто. К тому же для разных сценариев нужно тестировать разные модели. Это требует больших усилий. Чтобы уменьшить порог входа в эту технологию, мы создали собственную платформу — MWS GPT. Под капотом — наша инфраструктура с GPU.

О том, как тестировать разные LLM в MWS GPT и запускать ИИ-агентов без кода скоро расскажем на вебинаре — присоединяйтесь.

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

Сегодня делимся подборкой систем контроля качества ML-датасетов, проектом для автоматической категоризации и системой контроля версий для наборов данных.

Привет, Habr! Меня зовут Катя, я продакт-менеджер BigData в «Группе Лента» и отвечаю за развитие цифровых продуктов в направлении монетизации данных. В статье расскажу, как нам удалось уйти от Excel-файлов и ручного согласования сегментов к автоматизированному порталу, с помощью которого рекламные агентства теперь сами собирают нужные им сегменты и выгружают их в MyTarget.

Не так давно в блоге компании Arenadata был опубликован материал тестирования поведения различных распределенных файловых систем при работе с маленькими файлами (~2 Мб). Краткий вывод: по результатам проверки оказалось, что лучше всего с задачей маленьких файлов справляется старый-добрый HDFS, деградируя в 1.5 раза, S3 на базе minIO не тянет, замедляясь в 8 раз, S3 API над Ozone деградирует в 4 раза, а наиболее предпочтительной системой в при работе с мелкими файлами, по утверждению коллег, является Greenplum, в том числе для компаний «экзабайтного клуба». Коллеги также выполнили огромную работу по поиску «Теоретических подтверждений неожиданных показателей».  

Результаты тестирования в части S3 minIO показались нашей команде неубедительными, и мы предположили, что они могут быть связаны с:

• недостаточным практическим опытом эксплуатации SQL compute over S3 и S3 в целом;

• отсутствием опыта работы с кластерами minIO. В частности в высоконагруженном продуктивном окружении на 200+ Тб сжатых колоночных данных Iceberg/parquet, особенно в сценариях, где проблема маленьких файлов быстро становится актуальной.

• особенностями сборок дистрибутивов;

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

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

Хотите сделать свои Python-скрипты для анализа данных быстрее без переписывания кода? NVIDIA предлагает 7 простых замен стандартных библиотек, которые позволяют значительно ускорить выполнение задач анализа данных без изменения кода. В статье рассматриваются готовые решения для замены Pandas, NumPy и других библиотек, использующие GPU для повышения производительности.

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

Маркетинг репортит высокую выручку и ROI, но почему-то чувствуется не эффект роста, а эффект потраченных денег? Тогда эта статья для вас. В ней я рассажу на примере OLX, крупнейшего классифайда в Европе, как измерять эффективность маркетинговых усилий максимально точно и это совсем не те цифры, которые вы видите в Google Analytics. К моему удивлению, мало компаний использует этот способ.

Привет, коллеги ML инженеры, Data scientist'ы и все, кто интересуется искусственным интеллектом, созданием нейросетей, машинным обучением и анализом данных! Принёс вам пачку вебинаров с интенсива трека Наука о данных курсов повышения квалификации Летней цифровой школы Сбера.

К нам обратился один из крупнейших строительных холдингов России (ГК компаний из 10+ юридических лиц) с потребностью в сборе всех данных с филиалом, анализе и визуализации на дашбордах.

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

Было решение выбрать архитектуру Data Lakehouse на open source стеке, основой которого стали — kafka, dagster, s3+iceberg, trino, clickhouse и DBT. В результате получилось более 1000 моделей DBT, 1 тб сжатых данных, и объем продолжает расти.

Из потребителей данных — бизнес системы, Power BI отчеты, аналитики и дата‑инженеры, веб‑приложения, MDX‑кубы.

Методология ведения проекта Scrum, команда DWH‑инженеров 11 человек и greenfield‑разработка.

Десять лет назад мы говорили о «данных–нефть». В 2025-м метафора смещается: нефть закончилась, а нужен устойчивый источник энергии. Синтетические данные перестали быть лабораторным трюком — к 2030-му они превращаются в топливо, на котором летят банки, медицина и индустриальный IoT. GAN-ы научились соблюдать дифференциальную приватность, диффузионные модели вытягивают сигнал из шума лучше, чем биржевые трейдеры, а причинные графы заставляют базы данных «думать» о бизнес-логике. Мы собрали всё — от свежих метрик PrivEval до реляционной магии SCM и агентных симуляций, — чтобы показать: синтетика уже не копия реальности, а песочница для инноваций. Если вы ищете способ ускорить ML-проекты, избавиться от юридических цепей и заглянуть в будущее генеративного ИИ, эта статья станет вашим порталом.

Мне приходится тратить много времени на мониторинг арбитража, госзакупок и других документов: PDF на сотни страниц, новости с «водой», RSS при этом отсутствует.

Поэтому я решил разработать open-source инструмент, который сам проверяет сайты, скачивает документы и с помощью локального ИИ (GPT4All / DeepSeek) делает краткую смысловую выжимку по YAML-шаблону.

Он должен работать как конвейер: источник → шаблон → интерпретация → результат. Локально, без облаков. И объединять всё в единую ленту новостей.

Сейчас я дорабатываю MVP — и я хочу понять, какие шаблоны наблюдения наиболее востребованы: законопроекты, торги, релизы, или что-то ещё?

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

Погрешность измерения — это отклонение измеренного значения величины от её истинного (действительного) значения. Погрешность измерения является характеристикой точности измерения. Выяснить с абсолютной точностью истинное значение измеряемой величины, как правило, невозможно, поэтому невозможно и указать величину отклонения измеренного значения от истинного. Это отклонение принято называть ошибкой измерения. Возможно лишь оценить величину этого отклонения, например, при помощи статистических методов. На практике вместо истинного значения используют действительное значение величины , то есть значение физической величины, полученное экспериментальным путём и настолько близкое к истинному значению, что в поставленной измерительной задаче может быть использовано вместо него. Такое значение обычно вычисляется как среднестатистическое значение, полученное при статистической обработке результатов серии измерений. Это полученное значение не является точным, а лишь наиболее вероятным. Поэтому при записи результатов измерений необходимо указывать их точность. Например, запись означает, что истинное значение величины лежит в интервале от 2.7 s до 2.9 s с доверительной вероятностью 95%. Количественная оценка величины погрешности измерения — мера сомнения в измеряемой величине — приводит к такому понятию, как неопределённость измерения. Синонимом термина "погрешность измерения" (англ. measurement error) является "неопределённость измерения" (англ. measurement uncertainty). Таким образом мы плавно и ненавязчиво подошли к названию модуля языка Питон, которому посвящён настоящий туториал - uncertainties (неопределённости).

Рассказываем про индивидуальный подход как основу успешного проекта DWH и делимся реальными кейсами внедрения:

✔️ Кейс 1. Свой коннектор к Oracle: когда Debezium подвел​
✔️ Кейс 2. Миграция с Qlik: DWH между командами (в условиях командной фрагментации)​
✔️ Кейс 3. Бюрократия против DWH: проект в около-госсекторе

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

Сегодня разберём RecBole — универсальный фреймворк на PyTorch, который отвечает на три насущных вопроса любого ML-инженера рекомендаций:

Как быстро обкатать десятки алгоритмов (от классического MF до SASRec и KGAT) на собственном датасете — без сотни скриптов?
Как хранить все настройки в одном YAML, а не в трёх сотнях аргументов CLI?
Как получить честное сравнение метрик и сразу вынести лучший чекпоинт в прод?

Рассмотрим подробнее под катом.

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

Я программирую уже больше шести лет. На самом деле существенно больше (на свой первый аутсорс на PHP я попал примерно в 2016 году), но осознанно подходить к своей карьере я начал не сразу. За это время я вполне успешно поработал в довольно разных местах, от маленьких стартапов до международных компаний.

Недавно я проходил очередное собеседование, и на мой взгляд я неплохо держался. Как минимум до вопроса о том, как я покрываю свой код тестами. После него я стыдливо пробормотал о том, что знаю, как работает assert в python, и даже слышал про pytest. И что я с радостью начну писать тесты как только попаду к ним на проект, просто в наших проектах их не требовали. После чего мы плавно перешли к следующей теме, а оффер я так и не получил.