Data Engineering *

Недавно мне удалось посетить Data + AI Summit в Сан-Франциско в качестве Databricks MVP. Крупнейшую конференцию Databricks, посвященную данным, искусственному интеллекту. На мероприятии собралось более 30 000 участников из более чем 160 стран.

Я много слышал и читал об этом саммите, но никогда не мог представить, что попаду на его.

Все началось с того, что всем Databricks MVP предоставил бесплатный билет на мероприятие (стоимость билета без скидок около 1000$). Звучит конечно, здорово, но чтобы попасть нужна еще виза, билеты на самолёт и проживание в гостиннице. Хорошо хоть питание было организовано на самом мероприятии.

На удивление записаться на визу в Кракове и получить её оказалось довольно просто, запись за неделю и через 2 дня уведомление, что виза одобрена, круто!

Далее покупка билетов на самолёт примерно 1000$ в одну сторону и проживание в гостиннице около 150$ в сутки. К счатью моя компания приняла решние частично компенсировать расходы. Большое ей спасибо, возможно на тот момент я бы не решился поехать и выложить несколько тысяч долларов за мероприятие.

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

v1.1.0: убрали HTTP-костыль для sink’ов, закрыли /metrics, Teams в UI, trusted clusters. Про v1.0.3 и типичный «pairing failed» на Docker — внутри. Продолжение серии.

Мы создаем софт для горно-геологических служб калийных рудников. Наши геологи и маркшейдеры каждый день превращают тысячи скважинных проб в карты: отметки кровли пласта, содержания KCl, мощности, газоопасность. Классический инструмент для этого - кригинг, и в QGIS он формально есть: SAGA, GRASS, Smart-Map, связки со SciPy. На практике же каждый вариант чем-то не устраивал, и год назад я начал писать свой плагин. Сейчас Isoliner - это 24 инструмента в официальном репозитории plugins.qgis.org: кригинг четырёх видов, вариограммный анализ, кросс-валидация с отчётами, изолинии с контурными полигонами, геологические разрезы и собственный 3D-просмотр. Вычислительное ядро - чистый NumPy, ни одной внешней зависимости.

Под катом - зачем понадобился ещё один кригинг, как выглядит система кригинга в двадцати строках NumPy, что такое вариограмма на пальцах и почему абсолютные единицы силла — главные грабли всех, кто впервые открывает такие инструменты.

В предыдущих статьях я рассказывал, как появился веб-дневник диабета на Django и как постепенно оптимизировалась его производительность. Проект начинался довольно типично: пользователь вводил показатели сахара, записывал приемы пищи и дозы инсулина, а система сохраняла их в базе данных и отображала на графиках.

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

Фонд Национальной технологической инициативы реализует проект технологических конкурсов Up Great — открытых соревнований для инженерных команд. Здесь преодолевают технологические барьеры России и мира, чтобы решать задачи, с которыми ещё никто не справлялся.

Один из текущих конкурсов — «Экспедиция. Data Science» с технологическим партнёром Phystech.Genesis, который предоставляет платформу и маркетинг события. В конкурсе участники работают над системами ИИ по распознаванию археологических объектов на поверхности земли и глубине до 5 метров. Пока такую работу археологи делают вручную, что требует много времени и специалистов. Конкурс призван ускорить процесс и исключить человеческие ошибки, чтобы дать исторической науке новые возможности, а учёным — время на экспедиции и раскопки.

В рамках «Экспедиция. Data Science» — 3 конкурса отдельных заданий (КОЗ), а также финальный конкурс. С каждым следующим этапом команды берутся за более сложные задачи и пробуют новые подходы. Недавно организаторы объявили победителей второго из них — «Сканирование». На этом этапе команды создавали нейросети, чтобы искать археологические объекты в рельефе и под поверхностью земли.

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

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

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

Именно поэтому архитектура проекта получилась такой.

Привет, Хабр! На связи команда Data Sapience. С последней публикации результатов тестирования MPP-движков прошло уже несколько месяцев. За этот период произошел ряд изменений в базовых версиях open source движков и фреймворков, а также наша команда разработки внесла ряд улучшений и доработок. Все это может повлиять расстановку сил в рейтинге.

В сегодняшней публикации мы представим максимальное число претендентов, среди которых: Spark 3.5.*, Spark 3.5.* + DataFusion Comet, Spark 4.0.1, Spark 4.0.1 + DataFusion Comet, StarRocks (core based 3.5+, 4.0+), Impala (core based 4.5), Trino (459, 476, 479) и новичок нашего рейтинга — Apache Doris.

Статья поможет вам ответить на вопросы: стоит ли переходить на Spark 4 в поисках производительности; Как нативные вычисления влияют на результаты Spark; Как улучшилась производительность Trino за последние полгода; нужно ли присмотреться к Apache Doris, если вы ищете альтернативу Impala и StarRocks, и как эти проекты связаны между собой; какие оптимизационные улучшения были добавлены нами в StarRocks и Impala за последнее время.

И на десерт мы покажем вам сравнение Greenplum, Cloudberry и StarRocks в режиме Shared-Nothing MPP.

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

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

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

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

Снаружи это уже выглядело рабочим слоем защиты: аналитики видели меньше мусора, инженеры получали более понятные issues, и продукт наконец увидел практическую пользу вместо очередного демо. Я примерно так и сказал: “смотрите, это уже не игрушка”. Плохая фраза, как оказалось.

Потому что как только защита начинает работать, даже чуть-чуть, вокруг сразу появляются нормальные взрослые вопросы. А давайте это в платежи? А в бонусный абьюз? А в L7? А в социнженерию? А в странные кейсы саппорта, где один тикет внезапно объясняет половину графика? Вопросы честные. Только дорогие.

И в системах с живым противником есть ещё одна неприятная деталь: рабочая защита становится сигналом для другой стороны.

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

Осенью 2024 года я не планировал начинать новый проект. Тем более связанный с медициной.

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

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

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

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

Привет Хабр!

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

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

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

Иногда legacy живёт в компании годами не потому, что он плох, а потому что «работает — не трогай». Но однажды появляется триггер, который заставляет переосмыслить подход. В нашем случае таким триггером стала миграция на Kafka 4.0.

Привет! Меня зовут Роман, я инженер данных в компании CDEK и занимаюсь разработкой платформы данных и внедрением self‑service инструментов. В этой статье расскажу, как мы обеспечиваем Event Sourcing подход в платформе больших данных, с какой болью столкнулись при переходе на Kafka 4.0 и как решились отказаться от JSON‑формата.

Это продолжение новых безопасных паттернов по работе с MCP, которые я для себя придумал, которые я описал в статье:

Основная задумка вместо того, чтобы строить очередной Data-lake возможно ли организовать взаимодействие через MCP так с данными, чтобы это было безопасно и эффективно

Небольшой обзор идей согласованности в DWH на основе книг Кимбалла.

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

- Кто такой Кимбалл и каков его подход
- Факты и измерения
- Согласованные факты
- Согласованные измерения
- SVOT, или single version of truth

Я сделал ContentCombine — мультинишевый контент-комбайн, который собирает материалы из RSS, Telegram, сайтов и других источников, нормализует их, считает скор, склеивает повторы в сюжеты, отделяет кейсы от шума и готовит ежедневный дайджест. Сначала движок работал на игровых новостях, потом я перенёс его на SEO и AI — без переписывания ядра, но с кучей неожиданных граблей: entity blobs, старые статьи под видом свежих, молчащие фиды, ложные тренды и LLM-недетерминизм в проде.

Практический эффект TAPe+ML v2 сейчас лучше всего видно в object detection. Так, TAPe+ML v2 на конкретной практической задаче рудозасорения (см главу про промышленный пилот), без COCO-головы, на новом backbone, основанном на данных клиента, дает точность детекции 96%, по mAP50 – точность  90% и по mAP50–95 – 85%. То есть TAPe‑детекция выходит на уровень RF‑DETR по mAP50 при числе параметров меньше 100 тысяч против порядка 127 миллионов у RF‑DETR 2XL.

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

Если в компании уже используются AI‑инструменты, она может быстрее и дешевле производить свой продукт и, следовательно, давать более конкурентные цены. Конечно же, потребитель выберет производителя с AI.

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

GenAI-ассистент может довольно быстро начать отвечать "по теме": находить релевантные фрагменты, собирать уверенный текст и создавать ощущение, что система уже работает.

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

Но для продуктового контура этого недостаточно.

Проблема не только в том, может ли модель сформировать релевантный ответ. Проблема в том, является ли поведение системы ожидаемым, проверяемым и управляемым.

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

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

Фокус будет не на том, как "улучшить prompt" или выбрать модель побольше, а на том, как система управляет ответом после retrieval:

Как устроен Data Mesh, какие требования подход предъявляет к бизнесу и почему большинству российских компаний сегодня зачастую важнее построить зрелое DWH, чем пытаться перейти к распределенной архитектуре данных