Big Data *

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

А при неинвазивном управлении уходят риски кровотечений, инфекций и отторжения. Устройство можно надеть и снять за минуту. Оно отлично подходит для реабилитации или когда операция противопоказана. Но при таком методе главным критерием становится четкость восприятия бионическим протезом сигнала от мозга. Все дело в шуме. Сигнал проходит через кости черепа и кожу, теряя силу. Датчики улавливают многочисленные помехи (моргание, напряжение мышц шеи). Есть потеря в скорости и точности: протез работает с небольшой задержкой, поэтому трудно выполнить задачу со сложной моторикой, например завязать шнурки.

Но есть хорошие новости для сторонников щадящего метода. Разберемся в них на примере одного из проектов, который усиливает сигнал с помощью интеграции в управляющую систему модуля компьютерного зрения, а также технологии дополненной реальности (AR).

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

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

Меня зовут Сергей Петриченко. Я продуктовый менеджер VK Data Platform. В этой статье разберем, почему каталог — это не первый шаг к порядку, а скорее мультипликатор уже существующей зрелости и что необходимо сделать, чтобы его внедрение принесло реальную пользу.

Меня зовут Александр Ларин, я руковожу центром обучения и технической поддержки в GlowByte. Мы постоянно внедряем FineBI у клиентов и регулярно слышим один и тот же вопрос: «а где почитать или посмотреть, чтобы разобраться самому?» Решил собрать ответ в одном месте.

Привет, Хабр! На связи команда 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 вышел на сцену с заявлением масштаба смены эпохи: отдельные быстрые базы под витрины больше не нужны, перекачка данных между системами умерла, а всё хозяйство теперь живёт в едином озере, готовом под ИИ-агентов. Звучит так, что хочется встать и поверить.

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

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

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

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

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

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

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

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

Я хотел написать маленький локальный RAG для научных статей: графы, hybrid search, HyDE, reranker, всё красиво. В итоге Full Pipeline проиграл почти всем простым baseline’ам, графы начали портить контекст, HyDE вредил, а локальная LLM уверенно делала вид, что всё хорошо. Потом я разобрался, что ломалось, выкинул лишние LLM‑вызовы, починил trimming и получил систему, которая, наконец, начала выигрывать там, где должна.

Я Игорь Юрченко, backend-разработчик Сбера, в этой статье расскажу о нашем опыте автоматизации деплоя потоков Apache NiFi.

Apache NiFi — инструмент для управления потоками данных между автоматизированными системами (реализует подход ETL — extract, transform, load). Документация: https://nifi.apache.org/documentation/v1 (на момент написания статьи актуальна версия 2.x, но тут речь про 1.x). Физически это Java-приложение с графическим web-интерфейсом, в котором настраивается поток — в общем случае набор процессоров, которые получают на вход какие-то данные от предыдущего процессора или из внешней системы, обрабатывают их определённым образом и передают следующему процессору или во внешнюю систему. Процессор — готовый модуль с параметрами интеграции и/или обработки данных (например, строка подключения к БД, или схема трансформации данных). То есть ETL настраивается графически, без написания кода. NiFi обладает возможностями горизонтального масштабирования (ноды кластера имеют одинаковую копию настроек потока, обрабатывают данные параллельно), и расширения (пользователь может писать custom процессоры и использовать их в потоках наравне со штатными). Из коробки поддерживается множество внешних систем и протоколов передачи данных.

Apache NiFi Registry — инструмент версионирования потоков, Java-приложение с web-интерфейсом, интегрировано с NiFi. Что-то вроде системы контроля версий исходного кода, но проще. Пользователь может сохранять в Registry, просматривать и восстанавливать старые версии потока. Документация: https://nifi.apache.org/docs/nifi-registry-docs.

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

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

MAGNIT TECH — это технологическое ядро крупнейшей розничной сети страны. Более 5 000 инженеров, аналитиков и продуктовых команд разрабатывают, поддерживают и масштабируют свыше 260 ИТ-продуктов и проектов, а также 800 информационных систем — от алгоритмов прогнозирования спроса в 33 000 магазинах до касс самообслуживания с собственным ПО. 

Мы ИТ-компания, создающая собственные продукты с высоким уровнем инженерной сложности, без зависимости от вендоров и системных интеграторов. В этой статье — честный рассказ о том, над чем мы работаем прямо сейчас и куда движемся в 2026 году.

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

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

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

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

Меня зовут Даниил Никольский, я бэкенд-инженер команды Trisigma. В создании статьи участвовали Искандер Мирмахмадов, руководитель продуктового направления, и Александр Кузнецов, старший аналитик. В этой статье я расскажу про Switchback-эксперименты, рассмотрим как они устроены, почему для него не подходит обычный t-тест, и какая инфраструктура нужна, чтобы проводить такие эксперименты в промышленном масштабе.

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

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

Но нам, маркетологам, хорошо бы понимать, почему очень часто попытка воздействовать на мотивацию клиента извне приводит к полному ее отказу.

Сегодня разберемся, что такое кросс-фильтрация в Apache Superset и какую неожиданную опасность она может нести.

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

В 1915 году Владимир Иванович Вернадский запустил проект, который сегодня назвали бы национальной базой данных ресурсов. Без компьютеров и цифровых технологий комиссия КЕПС собрала сведения о недрах, лесах, водах и энергии страны, заложив основы подхода «сначала данные, потом решения».

Всем привет. На связи Дмитрий Немчин из Т-Банка. Снова буду говорить про Greenplum, но в необычном контексте.

С 2015 года занимаюсь Greenplum: развитием, эксплуатацией, автоматизацией и всем, что обычно появляется вокруг большой аналитической платформы. Когда я пришел, у нас было два production-кластера Greenplum и десятки терабайтов данных. Сейчас production-кластеров около 20 и объемы данных измеряются петабайтами. За это время Greenplum прошел путь от небольшого DWH до центра крупной Дата Платформы. И сейчас это система, которая все еще держит большую часть нагрузки, но постепенно перестает быть точкой будущих инвестиций. 

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

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

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