Data Engineering *

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

История других отраслей показывает, что происходит дальше. До Uber цену поездки знал только таксист, и пассажир зависел от его решения. Как только маршрут и стоимость стали видны на экране, преимущество водителя исчезло. Booking сделал прозрачными цены на отели, маркетплейсы - на товары, Google Maps - на логистику. Строительство пока остаётся одним из немногих крупных рынков, устроенных «как такси до Uber»: полной картиной по стоимости и срокам владеет только одна сторона, а вторая оплачивает эту асимметрию перерасходами.

Дальше в статье - нидерландский строительный картель с двойной бухгалтерией и 1300 оштрафованных фирм; алгоритмы, которые находят следы сговора прямо в цифрах торгов; два миллиарда долларов SoftBank, сгоревшие в «кнопке Uber для стройки»; и рынок жилья, который свою уберизацию уже прошёл. Через историю и паттерны видно, какими будут инструменты уберизации строительной отрасли в следующие десятилетия.

Два месяца назад я запустил повторный замер одних и тех же 20 промптов в двух ИИ-поисковых системах — хотел посчитать, с какой скоростью источники вымываются из цитируемой выдачи. Результат оказался неожиданно резким: за первый месяц ChatGPT перестаёт ссылаться примерно на три четверти доменов, которые цитировал в начале, Алиса AI — примерно на половину. А между первым и вторым месяцем распад почти останавливается. Ниже — как я это мерил, что получилось и почему на трёх точках во времени можно уверенно говорить про форму кривой, но нельзя — про точный коэффициент.

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

Архитектура — это не список функций. Это набор инженерных решений, которые определяют, где система выиграет, где проиграет и почему.

Большинство распределенных хранилищ при заполнении примерно на 95% начинают работать в 2-3 раза медленнее. В наших тестах производительность упала всего на 4–9%. Причина в архитектуре MIND uStor. В этой статье разберем, как устроена модель хранения данных, как организован ввод-вывод и за счет чего система сохраняет производительность даже при высокой утилизации дискового пространства.

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

Здесь разберем, как устроено размещение данных, каким образом кластер сохраняет производительность при заполнении свыше 90%, как работают RF- и EC-пулы, а также почему iSCSI-таргет реализован в пространстве пользователя. Отдельно остановимся на компромиссах, которых потребовала реализация этих решений.

Всем привет! Меня зовут Катерина Цаплина, я AI Architect и программный эксперт курса «MLOps для разработки и мониторинга моделей». Работаю на стыке ML, инфраструктуры и корпоративной архитектуры в крупной промышленной компании и на практике вижу, насколько непросто выстраивать такие процессы в реальной организации.  

Это четвёртая и финальная статья цикла о том, как компании реализуют MLOps. В предыдущих частях мы разобрали, как компании могут строить MLOps в целом, рассмотрели пример внутренней ML-платформы Uber Michelangelo и на примере Netflix Metaflow разобрались, как workflow-фреймворки помогают навести порядок в ML-разработке.

Сегодня разберём ещё одну альтернативу собственной платформе: managed-сервисы облачных провайдеров. На примерах Google Vertex AI, Yandex DataSphere и Yandex AI Studio рассмотрим, как они устроены и чем будут полезны команде и бизнесу. И, наконец, подведём итог всей серии статей.

Когда речь заходит про Lakehouse и федеративный доступ, многие вспоминают про Trino и… часто на этом все. Но федеративные запросы поддерживаются в том или ином виде довольно большим количеством СУБД, SQL-движков и систем для виртуализации данных.

В этой статье постараемся немного расширить кругозор читателей, которым интересна данная тема: рассмотрим федеративные запросы на примере набирающего популярность и активно развивающегося StarRocks. Из статьи вы узнаете: что такое федеративные запросы, как обстоят дела с реализацией гетерогенного федеративного доступа в этой СУБД и какие изменения команда решения Data Ocean Nova реализовала для оптимизации в StarRocks и Impala с целью улучшения функционала доступа к внешним данным.

Как мы провели проект через четыре «эпохи» — от ручных запусков на Windows‑планировщике до Spark + k8s на масштабе сети

Привет, Хабр! Меня зовут Имиль Валиуллин, я тимлид команды разработки платформы OSA. В предыдущих статьях цикла On Shelf Availability (OSA) уже разбирали с разных сторон: что такое OSA как продукт, как устроен алгоритм детекции аномалий и весь конвейер генерации сигналов — эвристики, ML‑модели, фильтры, обратная связь, A/B и оценка эффекта (ссылки на предыдущие статьи: 1, 2, 3). В этой статье мы раскрываем следующий слой — инженерный. Потому что всё перечисленное было бы невозможно без большой работы под капотом: данных, транспорта, оркестрации, SLA, мониторинга, качества данных, обратной связи, API и доставки сигналов в торговые точки. Многие забывают, что даже самая крутая ML‑модель — это только верхушка айсберга. Результат появляется только тогда, когда под ней есть надёжный фундамент: чистые данные, стабильный транспорт и бесперебойная доставка. Как говорится, garbage in — garbage out, и наоборот: качественный фундамент позволяет получить качественный результат.

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

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

Эта идея появилась у меня давно.

Когда мы внедряли BI в крупном банке, я заметил одну вещь: больше всего внедрению радовались руководители. У них появлялись дашборды, графики, показатели, визуальная картина происходящего.

А вот люди, которые каждый день работали с данными, не всегда были в таком же восторге.

BI хорошо показывает, что что-то изменилось: появилась аномалия, просел показатель, выросло значение, изменилась динамика. Но после этого почти всегда возникает следующий вопрос: почему так произошло?

И вот тут уже приходится разбираться не с графиком, а с данными.

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

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

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

Так появилась первая версия программы: она формировала отчёты в Excel и хранила на сервере историю выгрузок.

Всем привет! Меня зовут Катерина Цаплина, я AI Architect и программный эксперт курса «MLOps для разработки и мониторинга моделей». Работаю на стыке ML, инфраструктуры и корпоративной архитектуры в крупной промышленной компании и на практике вижу, насколько непросто выстраивать такие процессы в реальной организации.  

Это третья статья цикла о том, как компании реализуют MLOps. В предыдущих частях мы разобрали три архитектурных подхода и рассмотрели Uber Michelangelo — одну из самых известных внутренних ML-платформ. После знакомства с такой системой может возникнуть логичный вопрос: а обязательно ли строить собственную платформу?

На практике далеко не всегда. Для многих организаций более рациональным выбором становятся workflow-фреймворки для организации ML-разработки или managed-платформы облачных провайдеров. В этой статье разберём первый подход на примере Netflix Metaflow, а managed-платформы рассмотрим в следующей части.

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

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

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

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

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

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

В предыдущих статьях я рассказывал, как появился веб-дневник диабета на 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‑формата.