Big Data *

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

Согласно анонимному источнику, участвующему в проекте, Amazon почти завершил строительство «парка гуманоидов» в одном из своих офисов в Сан-Франциско. Этот испытательный полигон размером с небольшую кофейню включает полосу препятствий и один фургон Rivian для тренировок. Цель — научить гуманоидных роботов перемещаться в фургонах Amazon и оперативно доставлять посылки к месту назначения.

Этот проект сопровождается созданием новой команды Amazon по агентному ИИ, которая занимается разработкой технологий для управления роботами в распределительных и логистических центрах. В заявлении для Silicon Valley компания сообщила: «Вместо узкоспециализированных роботов мы создаем системы, способные понимать и выполнять команды на естественном языке, превращая складских роботов в универсальных помощников».

Amazon уже использует автономных роботов в своих складских операциях, включая тестирование гуманоида Digit от Agility Robotics. Этот робот изначально разрабатывался для задач вроде доставки посылок из фургона и других логистических функций. Новый тренировочный центр Amazon направлен на реализацию этой концепции. По данным The Information, в центре будут тестироваться различные модели гуманоидных роботов, включая модель стоимостью $16 000 от китайской компании Unitree.

Привет! Меня зовут Антон Моргунов, я академический руководитель программы онлайн-магистратуры Яндекса и МИФИ «Специалист по работе с данными и применению ИИ», которая стартует в сентябре 2025 года. В этой статье я расскажу об актуальных трендах, профессиях и навыках в сфере работы с данными.

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

В результате, около 65% организаций заявляют об использовании генеративного ИИ как минимум в одной бизнес-функции на регулярной основе — почти в два раза больше, чем десять месяцев назад.

Привет, Хабр! Я Станислав Габдулгазиев, архитектор департамента поддержки продаж Arenadata. В этой статье рассмотрим, как большое количество мелких файлов влияет на производительность различных систем хранения, таких как HDFS и объектные хранилища с S3 API.

Разберём, какие технологии хранения лучше всего подходят для работы с мелкими файлами в архитектурах Data Lake и Lakehouse. Сравним производительность HDFS и объектных хранилищ с S3 API. На конкретных тестах покажем, почему именно HDFS эффективнее справляется с большим количеством небольших файлов. Обсудим также случаи, когда мелкие файлы становятся не просто нежелательной ситуацией, а неизбежной необходимостью, например в подходах типа Change Data Capture (CDC).

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

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

Меня зовут Вадим Безбородов. Мы c Максимом Митрофановым в департаменте Data science & ML в Positive Technologies занимаемся исследованием и внедрением машинного обучения в продукты компании. В этой статье расскажем о наших исследованиях и внедрении ML в модуль поиска и классификации чувствительных данных в PT Data Security.

Как связаны скидки, пользовательские пути и огромные массивы данных в Яндекс Рекламе? 

Привет, Хабр! Меня зовут Максим Стаценко, я работаю с базами данных и яростно в них копаюсь с 2010 года, а в Big Data — с 2016. Сейчас работаю в Яндексе в DWH поиска и рекламы.

Мы работаем с ОЧЕНЬ большими данными. Каждый день миллионы пользователей видят рекламу Яндекса, а наши системы обрабатывают огромные объёмы данных. Чтобы реклама работала эффективно, нам нужно в каждый момент времени иметь максимально полную информацию об истории жизни рекламного объявления, а значит нужно каким-то образом передавать данные от одного события к другому внутри рекламной воронки. Расскажу, как мы решали эту проблему.

TL;DR: MCP стремительно набирает обороты. Сейчас уже существуют тысячи MCP-"серверов", и хотя эту концепцию изначально предложила Anthropic, всего несколько дней назад к ней присоединилась и OpenAI. Серверы — это что-то вроде "приложений" для ИИ, но, что важно, они гораздо более гибко сочетаются между собой. Мы наблюдаем зарождение полноценной AI-экосистемы — аналогично тому, как это происходило с мобильными платформами десять лет назад.

Подробности:

MCP (Model Context Protocol) был представлен Anthropic в ноябре 2024 года как открытый стандарт. Хотя поначалу реакция сообщества была сдержанной, за последние месяцы протокол стал развиваться. В конце марта даже OpenAI — главный конкурент Anthropic — официально внедрила его.

Но что это такое и почему это важно?

Упрощать и искать похожие детали, очень полезный навык! Предлагаю быстро пробежаться и попробовать найти ту самую серебряную пулю в RecSys !

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

В предыдущих сериях ( 1 • 2 • 3 • 4 • 5 • 6 • 7 • Ы ) рассмотрели, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL, заточенный на задачи подготовки и трансформации наборов данных, и работающий как тонкая прослойка поверх Spark RDD API.

Штука получилась довольно продвинутая, с поддержкой императивщины типа циклов/ветвлений/переменных, и даже с поддержкой пользовательских процедур. И в плане этой самой императивщины расширяемая: может импортировать функции из Java classpath, равно как и операторы выражений. То есть, если необходимо, можно написать функцию на Java, или определить новый оператор, и использовать потом в любом выражении на SQL.

Круто? Ещё как круто. Но как-то однобоко. Если в языке у нас поддерживаются функции, то почему бы не дать нашим пользователям определять их самостоятельно? Вот прямо через CREATE FUNCTION? Тем более, что вся необходимая для этого инфраструктура уже вовсю присутствует. Да и процедуры на уровне интерпретатора у нас уже поддерживаются ведь…

Функция для затравки.

Пятый, юбилейный выпуск нашего исследования «Круги Громова» выходит в момент, когда рынок отечественных BI-платформ переживает волну бурного роста и трансформации. За два года, прошедшие с публикации предыдущего отчёта, импортозамещение перестало быть формальностью и стало стратегической необходимостью: доля внедрений российских BI-систем выросла почти в восемь раз, а зарубежных — упала до 23 %[1]. На этом фоне особенно важны объективные ориентиры, позволяющие ИТ-директорам и бизнес-пользователям выбрать платформу, которая останется актуальной на ближайшие несколько лет. Именно такую навигационную карту мы и предлагаем.

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

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

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

Привет, Хабр! Именно так считает наш сегодняшний гость – Дмитрий Немчин, руководитель направления эксплуатации инфраструктуры данных в Т-банке и по совместительству член программного комитета Data Internals, профессиональной конференции
по инженерии, базам и системам хранения и обработки данных.

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

Привет, Хабр! Мы команда ЖЦК, занимаемся машинным обучением в ВТБ. Сегодня расскажем про алгоритмическую магию, которая творится прямо у нас под носом. Авторами проекта этой магии в ВТБ стали дата-сайентисты Дмитрий Тимохин, Василий Сизов, Александр Лукашевич и Егор Суравейкин. Речь пойдет не о хитрых нейросетях с их миллионами параметров, а о простом подходе, который помог им и команде сэкономить много времени на решении задач, в которых раньше использовались классические методы тестирования. 

Представьте: ваш бизнес растет, а вместе с ним и количество данных. Но вместо ценной аналитики — хаос: отчеты готовятся месяцами, данные разбросаны по Excel-файлам, а команда DWH не успевает закрывать запросы. Знакомо? Мы прошли через это и решили внедрить Data Mesh. Ожидания были амбициозные, но что получилось на самом деле?

Эпиграф: Это хуже чем преступление. Это ошибка

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

При этом согласно дорожной карте по развитию общего искусственного интеллекта от OpenAI, состоящей из 5 уровней, мы сейчас находимся на 1 уровне, когда ИИ только советует, а решение и ответственность остаётся за человеком. На следующем уровне он сможет рассуждать на уровне и вместо человека, а на третьем сможет действовать.

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

Справедливо будет сказать, что все мы, согласно опросу ВЦИОМ, возлагаем на него большие надежды:

1. уменьшим затраты времени на рутину

2. повысим производительность труда

3. улучшим качество жизни

4. вырастет уровень безопасности

5. победит мировая революция

Одна из важных отраслей для применения ИИ - Здравоохранение.

В России принята Национальная стратегия в области искусственного интеллекта до 2030 года, в соответствии с которой, должны быть: "сняты отдельные административно-правовые барьеры, препятствовавшие внедрению технологий искусственного интеллекта в отдельных областях, включая здравоохранение, транспорт, государственно-частное партнёрство и другие области;"

Рассмотрим, как реализован SortMergeJoin в Apache Spark, и заодно заглянем в исходный код на GitHub. Spark написан на языке Scala, и вся логика работы оператора доступна в открытом репозитории проекта.

Всем привет! Меня зовут Дмитрий Третьяков, я ML Engineer в компании «Лента». Мы регулярно запускаем PySpark-приложения в Kubernetes-кластере, используя Airflow. Этот процесс важен для нашей ежедневной работы с данными, но в какой-то момент мы столкнулись с тем, что стандартный подход через SparkKubernetesOperator стал сдерживать развитие: не хватало гибкости, возникали сложности в сопровождении и процесс настройки был излишне сложным для разработчиков.

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

Apache Flink — это фреймворк и распределенный движок обработки данных, поддерживающий какпакетную (ограниченную), так и потоковую (неограниченную)обработку данных. Это значит, что с его помощью можно обрабатывать как статичные (неизменяемые) данные, так и данные, поступающие в реальном времени.